In yesterday’s EMO (Exchange Messaging Outlook eZine, subscribe at http://www.slipstick.com/emo) I had an article named It’s All About The IOPS, Silly! which discussed the impact of RAID-1 and RAID-5 arrays on total IOPS calculations.
However, space didn’t allow me to talk about SANs (Storage Area Networks) in regards to IOPS.
Where Exchange is concerned (and SQL Server as well, although that isn’t our focus here), you do not want to be sharing your “disk group” or “volume group” or “virtual array” (or whatever your SAN software calls it) with any other application – unless you’ve performance tested it in the worst case.
SANs allocate storage in terms of LUNs – Logical Unit Numbers. For a given server, a LUN is allocated to that server (note that in the case of clusters, quorum disk may be visible to multiple servers at one time) and only one server may have write access to that LUN at a time. A LUN may, or may not, be tied to a particular disk array or disk set contained within the physical hardware of the SAN.
Many types of SAN software support a concept known as “LUN Stacking”. In this case, an array (be it RAID-1, RAID-5, RAID-10, whatever) has multiple logical stripes of the disk where multiple LUNs are allocated on the same array. Arguably, this is what SANs are all about – allowing you to control storage logically instead of drive-by-drive. And, for many (perhaps most) applications this makes sense.
However, while the BEST CASE SCENARIO says that the IOPS available for a LUN is the maximum IOPS available for that disk set, the WORST CASE scenario says that the IOPS available for a LUN is equal to the number of accessors (servers) that are using that physical array.
So, for example, if you have five servers hitting a RAID-1 array via different LUNS, the best case performance scenario says that you can have the maxiumum IOPS available to the hardware available to each server. The worst case is IOPS / 5.
For example, if your RAID-1 group has a calculated IOPS of 250, one server could potentially benefit from having a total IOPS of 250 available to it. However, if all the servers are hitting the disk, the performance would be more like 50 IOPS. While for many small and medium businesses, an IOPS of 250 is probably sufficient to meet their Exchange needs – only the smallest of companies can get adequate performance on 50 IOPS total.
Another reason you want to avoid sharing LUNs is due to the usage profiles of the various Exchange needs.
Database access (which includes queues, mailbox stores, and public folder stores) is completely random. The creation of log files (transaction log files, message tracking logfiles, and protocol log files) is completely sequential. If you share LUNs between different usage profiles, then your performance will suffer (especially for those needs which are optimized for sequential access).
Conclusion: Just Say No! Don’t let your SAN guys tell you what kind of storage performance requirements Exchange has. You need to be prepared to tell them!
Until next time…
As always, if there are items you would like me to talk about, please drop me a line and let me know!
Follow me on twitter: @EssentialExch