In the previous blog about LUN Creation and Size Expansion we talked about one of the don’ts for creating large LUNs. So the next question thrown at me is what are the alternatives to SAN concatenantion (LUSE) for volume expansion and what is the performance difference (SAN concatenation vs. Disk Interleaving vs. Host and Sofware Striping)? Well let’s first take into consideration that a disk drive today 2.5 inch form factor can deliver up to 200 I/O per second (IOPS). In reality this is much lower, but this is just an example. That means that in a concatenated configuration using two LDEVs from two 7D +1P Array Groups, only 1600 IOPS can be achieved because we are limited to one Array Group for current read/write operations (review first blog regarding concatenation). Take away the additional drive for parity and you have 1400 IOPs. Now take a disk interleave configuration using two LDEVs and you double the amount of IOPs achievable, because we now have the ability to strip the data across both LDEVs instead of being limited to one as with concatenation. Sounds pretty simple right! Well sounds that way, but I should probably explain disk interleaving. Disk interleaving is a SAN Based Striping method available on the HP XP and Hitachi Tagamastore platforms. For older models of the XP and the Tagmastore a certain firmware and microcode level must exist and disk interleaving was originally only available for usage with RAID 5 configurations on those models. In order to upgrade to this version downtime might be required. On the new SAN releases this is a built in feature and can also be accomplished with RAID 1 configurations also. So what can you do if your customer runs on the previously mentioned monolithic SAN version and does not have the right firmware or microcode to accomplish this? Consider host based striping as an option for improving performance.
Host based striping has always been a “no no” in the performance world due to the overhead management required by the operating system. However, when it comes to combating the usage of concatenation for the creation and expansion of a LUN, it is an excellent alternative. In the host based scenario, you would still have the SAN administrator create the LDEVs at the SAN level, but not perform any type of concatenation to create a large LUN. Instead the LDEVs are presented to the Windows operating system as basic disk and stripped together as dynamic disk. Keep in mind that I stated “stripped” which is an option for creating Dynamic Disk and crucial to the performance of this configuration. This configuration allows data be striped (e.g. RAID 0) across multiple LDEVs instead of concatenating the LDEVs together as in a LUSE volume. The chart in the figure below shows IO comparison between a 2D+ 2D (RAID 10), 3D+1P (RAID 5) using 64 disk and 7D+1P utilizing 128 disk.
For cluster configurations customers must use VERITAS Volume Manager. The reason for this is that Dynamic Disk is not support for MSCS. In order to implement host based striping for a cluster environment the customer must Volume Manager (KB816307). As can be seen below, using Volume Manager also yields good performance gains over using concatenation.
An excellent source for more information on host based striping performance can be found in the HP StorageWorks XP12000 Disk Array Configuration Guidelines for Microsoft Exchange Server 2003.
As you can see for the high end performance systems, there are better alternatives than the use of concatenation and they vary from SAN based to Host based configurations. I have only named all three striping methodologies in this blog (SAN, Host and Software Based Striping). This covers the LUN creation and best practice configuration part of the discussion. My next blog I will discuss growing those LUNs as the database grows. This is an area that has serious performance implications if done incorrectly. As always consult your customer’s storage vendor regarding the previously stated striping options and what is available for your customers today.
Note: All Pics in this document comes from published HP documents.