SAN, SAN, SAN, Gurupalooza and Domino

Darren Duke  January 25 2010 10:01:48 AM

At the gurupalooza session at the end of Lotusphere a question was asked about SANs. I think I answered this as best I could at the time, but here is a more thoughtful version.....

Most of the "performance" issues I encounter with Domino are to do with mis-configured storage, SANs being the major culprit lately, mainly, as with VMware, it is they way enterprise IT is moving. This is not due to SANs being any more or less bad than any other storage, but due to the fact that most organizations do not treat Domino as a true enterprise application. They neglect to design, manage and implement storage that can, and usually will, be beneficial to Domino in a production environment.

For Domino to be successful and for it to give you the performance you expect you need to really work on the storage layer. Domino is no different to MS-SQL or Oracle in this respect, but rarely does it get more then a nod from a storage administrator. Time and time again, we are given pre-configured servers and storage and asked to install on, or migrate to, Domino as-is. Any issues with storage on stand-alone servers that are re-created on a SAN will likely have the same issues. For some reason every SAN I see is configured with huge RAID 5 arrays. For the love of all things right, stop doing this! Then several key business applications, like Domino, SQL, etc, are then set up to use the exact same storage (aka LUN). Performance will be atrocious. Period. "Domino sucks" comments ensure. No, your storage admin or SAN reseller suck, not Domino.

The main reason I dislike SANs is because I have no visibility into them, so I am at the whim of the SAN administrator (or more likely the person who originally set up the SAN). Trying to get the SAN LUNs changed is difficult at best, and all but impossible most of the time. Now, I'm not saying anyone lies on purpose, but there have been a number of times I have been told that I have one or more dedicated LUNs only to later find out that was not the case.

So, regardless of SAN, VMware or stand-alone servers, your storage needs to be configured correctly so that Domino will be allowed to perform at the best possible level. You can do this in a number of ways:

• Read Stephan Wissel's excellent Build a high performance Domino server article
• Put transaction logs on a separate drive, even on VMware
• Understand Transaction Logging

If all of this is too much reading then depending on the number of drives you have available then this is a general rule of thumb:

12 Drives (12 2.5 SAS bays are available on an IBM x-Series 3650M2)
Drive 1 and 2, OS and applications - 146GB each - RAID 1
Drive 3 and 4, Domino TX Logs, - 146GB each - RAID 1 *
Drive 5 and 6, OS Page file - 73GB each - RAID 1
Drive 7 and 8, Domino view rebuild drive - 146GB each -RAID 1
Drive 9 thru 12, Domino Data - As large as possible - RAID 10

* - usually IBM likes to recommend housing TX Logs on their own RAID controller, good luck on getting a spec for that can be cabled.

You can, should you wish, reduce the number of mirrored drives and expand the Domino Data drives out for more space. As usual YMMV and this can be considered risky. Even if you use a SAN, the above drive configurations still hold true. The exception with a SAN is transaction logs, as I would pull these local to the server (blade or otherwise). Each of the above should really be on its own LUN. Yes, I know, the SAN administrator will have a fit, but so will your CEO when the Domino server is slow. Who has more power?

Another possible option with 12 drives (and this layout is far less fault tolerant):

Drive 1, OS - 146GB
Drive 2, Applications - 146GB
Drive 3 and 4, Domino TX Logs, - 146GB each - RAID 1 *
Drive 5, OS Page file - 73GB each
Drive 6, Domino view rebuild drive - 146GB
Drive 7 thru 12, Domino Data - As large as possible - RAID 10, RAID 5 (if you must) or RAID 50

Remember, most OS page files (on Windows) is 2 x RAM, so if you have 16GB RAM your page file could be as high as 32GB. Make sure you take that into account when ordering the drives.

Other SAN recommendations are to make sure your blade to SAN connectivity can handle the throughput (again, I would not put TX logs on a SAN if I had a choice). Will a 1Gbps iSCSI connection work? Depends on your throughput. Fiber Channel is usually best, as fast as you can afford.

For further VMware recommendations see my GLUG presentation : VMware on Domino

Other than that, use 64 bit Windows servers with 64 bit Domino if you can. With x64 16GB of RAM can make quite the difference too.

• Comments [1]