View member feedback to this tip.
This tip is a continuation of Preparing for consolidation –Part 1
Once you decide upon a Domino server consolidation, you must choose a platform. Hardware and operating system choices play a role that is every bit as important as the role of Domino. There are many factors to consider, such as how many users you have, where your strengths lie as a company, and what you are willing to support.
While AIX on a twelve-way IBM server can scale to tens of thousands of users, it won't do you any good if you only have 2,500 users and no one at your company can maintain an AIX system. You also need to look at what will be on your servers. Many operating systems have issues with things like drive volume limits. Some can only address a volume of less than 1 TB. This may preclude you from collapsing everyone onto one server. The same goes for your backup solution. You cannot put so much data on a server that your backup solution cannot take a full backup within your allotted window. Do not blindly jump into the consolidation pool. Use your judgment to aid in deciding what the best course of action is.
An excellent method of distributing the load on a large piece of hardware is to use partitioning. Domino partitioning was designed to take advantage of the inherent 'domaining' and partitioning capabilities of UNIX based systems. Keep in mind that there are some inherent limits to Domino itself. At about 2,000 concurrent users on a Domino server, performance begins to wane. When planning your consolidation strategy you must account for this. A simple "show users" or a look at your admin client during peak times will give you the concurrent user count. My experiences have shown that a typical concurrency rate is in the 30%-40% range. You can derive your partitioning plans from this type of usage analysis. If you extrapolate this statistic, you can see that a server with a peak concurrency rate of 40% would allow you to put 5,000 total users on a partition. Remember that these 5,000 users must also not exceed any other limits we discussed earlier, such as addressable volume space and backup capabilities.
Make sure you properly size your servers to allow for growth. It is better to have horsepower and space to spare than to try to add it a year later (or sooner!). I have never heard complaints about too much power on the server; the alternate complaint of too little power on a server is all too common.
Proper planning is the key to a successful consolidation effort. If you approach the idea of a consolidation with an open mind and look to optimize your infrastructure across all of your resources (servers, network, support, licensing, etc.), you will help reduce the TCO of your messaging infrastructure as well as improve service levels. It's a winning combination that is difficult to beat in today's cost conscious work environment.
A key component we haven't touched on yet is the actual client. The client is often overlooked, but it is what will determine the overall success of your project. We touched on how network response is key to keeping your user base happy. Your consolidation cannot be successful if the end users are disappointed in the process and result. The network sizing is usually fairly straight forward and can be managed easily by traffic monitoring and determining the proper pipe sizes. Where you may run into problems is on the desktop. In a standard Domino 5 or 6 environments, AdminP will do a good job on most people's mail file moves. Icons will be updated for mail, directories, etc., and people will not notice much of a change. Where you might run into problems is with other databases and applications. Those icons and bookmarks will often fail to be updated by AdminP. The only solutions I know are to try and write your own program to change the icons, or to purchase a migration tool such as the ones offered by Binary Tree.
There is also a trick you can try to get icons to failover to the new server. You can put the old server and the new server into a cluster, so that when you shut the old server down, any clients trying to access the old icons will be redirected to the new server. After a month or so, most people will have tried to access the old server and therefore will have failed over to the new server for those databases. Everyone's icons should be pointing to the correct server. It's a simple, yet effective, way of making the client transition smoother for the end users.
You must also properly plan the migration and get buy in from all areas involved. You want the end users to feel that they are at least being listened to and considered when you undertake a plan such as this. Communicate well and often, and you can quell the rebellion. When you put together a great plan that maximizes the infrastructure and allows people to work more efficiently, your company will benefit in ways you never imagined. When everyone works towards that goal, only good can come of it. If you have any further questions or need to follow up on some topics in detail, please submit your queries to the Domino Administration Ask The Expert page here on SearchDomino. I'll get to them as quickly as possible.
MEMBER FEEDBACK TO THIS TIP
Although this was touched on with regards to the client, I am curious as to suggestions regarding the mail file unread marks. Unless one is in a 6.x cluster and uses the DB property to replicate unread marks, I have found that to be the largest issue when moving to a new server. The other aspects of the migration can be transparent but the sudden change in the unread marks causes an explosion of questions and concerns. Of course if the old server is on-line, the clients can synchronize unread marks.
I would be interested in other solutions to this problem.
—David P.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
