Date: November 16, 2002
The basic rule for laying out LV's for maximum performance is to spread I/O activity over as many physical disks as possible. To this end, I've adopted a simple strategy that works well in almost all cases. I call the strategy SARS: Spread and Randomize Sequence.
When I started in this industry, I was taught to isolate I/O hot spots. For example, put database redo logs, indexes and hot files on their own disk drives. However, I found multiple problems with this approach. I rarely knew which files were going to be active. Isolation meant you lost I/O bandwidth. Some disks were busy, while other sat idle. And dedicated drives used disk space inefficiently.
The SARS methodology simplifies everything. It makes no assumptions on I/O activity. You simply spread and randomize the sequence of all LV's across all physical disk drives.
In AIX terms, I spread the LV's physical partitions across all hdisks. An hdisk can be JBOD or a RAID array. Doesn't matter. To insure the LV is spread across all hdisks, I use "smit mklv" to create the LV. I select all hdisks, and set the "Range of physical volumes" to "maximum".
Finally, I randomize the sequence of the LV's across the hdisks. If the first LV sequence is hdisk1, hdisk2, hdisk3, I might change the second LV sequence to hdisk2, hdisk1, hdisk3, and so on. Varying the sequence is extremely important, because it avoids bottlenecks with sequential I/O.
I've found this implementation utilizes both disk space and I/O bandwidth efficiently, I've used it in benchmarks and in production with excellent results. One comment, be sure the hdisks are on different physical drives, which may not be the case in a SAN environment.
References: I found an Oracle document that has come to the
same conclusion. They call their methodology SAME: Stripe
and Mirror Everything. It is conceptually similar to SARS. The
differences are that they do not discuss Raid 5 arrays, or randomizing
the LV sequence, and their implementation is more Solaris than AIX.