This article can also be found in the Premium Editorial Download "Storage magazine: Backup overhaul: From a mainframe to an open-systems environment."
Download it now to read this article plus other related content.
Let the host share the load
Another thing to keep in mind is stripe size. It's common knowledge that stripes (not concatenations) are generally good for performance. Stripes give you the ability to have a higher number of spindles acting in your favor. However, there's a sweet spot beyond which too many spindles might not be such a good thing. The number of spindles depends on the read and write requests on the host, as well as alignment to the stripe column width and size. Even a slight misalignment in these can cause problems such as disk crossings (i.e., the array perceives a single write as two sequential writes). This results in suboptimal performance. The use of host-based volume managers can nicely complement striping in the array with striping on the host and minimize the impact of a large stripe all on the array side.
So how do you make sure all of this translates into pairing the workload profile with the correct RAID type? Divide and conquer. By ensuring that no single system or component bears the onus of meeting the I/O requirements of the application, you can minimize the impact the application workload has on any single component in the I/O chain. In other words, the more horizontally you spread the I/O (within reason), the better the performance. A well-balanced system consists of host-based components bearing equal responsibility with those in the storage array. Host-based components include multipath software,
Analyze the app
You should also examine the application environment itself. Do all components need to reside on the same file system or volume? Can they be segregated based on the I/O profile of each component? Determining an application workload profile isn't an easy task. Database administrators will tell you that not all components of a database have a random write profile--only the data components do. So mixing all kinds of profiles on the same file system isn't the best approach. Instead, create different file systems on disparate spindles (or RAID groups) so that one file system doesn't affect performance on the other.
All this is fine and dandy when you're planning from scratch, but that's often not the case. You may have performance problems in your existing environment. First, try to gather as much data on the symptoms as possible, and then find out where the problem truly lies or what's introducing it. For example, if you see high write-pending utilization in cache, find out if it's being caused by an imbalance on the host or array. If the host has volume management and all volumes are striped, you're probably not spreading the stripe across all the back-end resources or you have an improperly matched RAID type. Most storage vendors provide tools that allow you to move data from one LUN to another transparently, so you can use them to move from RAID-5 to RAID-10 or vice versa.
If the host lacks volume management, and you have a single large file system that's pounding away on a single large LUN, you may have to convince your systems folks to implement volume management and spread your I/O. The other option is to use array-based "striping" features that allow you to take that single large LUN and put it on a stripe consisting of multiple smaller LUNs that go to different RAID groups. The key thing is to explore all of your options. And one final word that always works in your favor: Patience.
This was first published in April 2007