Las Solanas Consulting

Storage Virtualization | FAQs & Discussions

Comparing Drive Technologies

A White Paper by Tim Warden


This Is Work In Progress! Pardon the mess, hopefully you can gleen some useful info from the scribblings below.

10K vs 15K

10K RPM drives spin 2/3's the speed of 15K RPM drives. What does that mean in terms of performance? A lot! It means the rotational latency is significantly lower on 15K RPM drives. Each time a read or write request is processed by the drive, the actuator must be moved in order to place the head over the appropriate track to read or write the associated sector or sectors. Once the head has been positioned, the I/O operation must wait until the sector spins into place. The time required for the disk to spin into place and then to read or write the data as the disk spins beneath the head is known as "Rotational Latency". The more random the activity on the drive, the more rotational latency will play into performance. Rotational latency will also show up on highly sequential I/O as the heads can only read or write the sectors as fast as they can spin under the head.

The effect of rotational latency on performance is most easily observed in a single-spindle environment, such as your desktop computer. For a given sector layout, booting your system from a 7200 RPM drive will be noticably faster than booting from a 5400 RPM drive. And if your server environment is based no DAS (Direct Attached Storage) using a standard RAID controller with its limited (128MB or 256MB) cache, you will also notice a difference in performance with faster spinning drives. And obviously enough, in a shared or virtualized storage environment where multiple volumes can occupy space on the same physical spindles, reducing rotational latency can make a big difference.

Is this important to you? Only if you are currently experiencing performance problems that you've isolated to the physical spindles.

The mechanical disk drive is by far the slowest device in the data path for your applications. If you are encountering performance problems, the drives are ultimately the culprit, but there are a number of things you can do to improve performance without necessarily spinning the drives faster.

Before you swap out all your 10K drives for 15K drives, look for more cost effective solutions.

  • Consider moving from RAID-5 or RAID-6 to RAID-1 or RAID-10 for your write-intensive volumes, such as transaction logs, etc.
  • Separate volumes that have the highest traffic onto separate spindles, separate controllers.
  • Are your RAID groups optimal? The more spindles spinning the problem, the better. This will take a bit of effort, because you are attempting to avoid contention for the spindles by having concurrent I/Os on separate RAID groups, but maximizing the spindles working on any particular problem. I.e. if you have 1 LUN that is a performance hog, throw spindles at the problem; if you have 2 performance hogs, split 'em between RAID groups and controllers to facilitate concurrency.
  • How much cache do you have? Beef up the cache. Cache always helps, even in so-called "totally random OLTP" type applications. Many of those applications Select before they Update: that means a Read before a Write. A good caching engine will prioritize the most recent reads/writes and can take advantage of the extra cache to improve performance.
  • Consider examining the I/O subsystem. How long are the queues? If they are Windows servers, try UpTempo from DataCore. Many times, the bottleneck on the storage server can be alliviated by improving the caching and I/O handling of the client server.

If you've analyzed all these factors and are still running up against a performance bottleneck and have indeed isolated the problem to the storage array, then indeed 15K RPM disks will make a difference.

Shopping For A SAN Storage Array and Worried About Performance?

I've spoken with many customers who, understandably, don't have prior experience with shared storage and are justifiably worried about performance and reliability. I'll write more about my experiences on this here, but in the meantime, read a few of my other white papers (click the FAQ link above) and be assured, it's not as big an issue as you may think.

I've been involved in several sales calls for DataCore's SANmelody product where the performance question was frequently raised; after installing the product, the customers fears were put to rest. Not only were there no performance problems, the customers typically ranted about how performance had improved over their previous storage environment.

Try SANmaestro from DataCore for measuring performance before you decide on your SAN technology if you are really worried. It's a simple install, doesn't require a reboot, and your SQL Admins won't even notice it's running. Let it run for a week or two and you'll have the I/O metrics required to shop for your SAN.

iSCSI vs Fibre Channel

FC today: 4Gbps, $1000 per port.

iSCSI today: 1Gbps for as low as $20 if you shop around. 10Gbps for prices far more affordable than 4Gbps FC. Many of the newer NICs today have an Offload Engine on them. And you can team them. iSCSI is definitely an attractive and viable alternative to Fibre Channel.



Ah... this is going to be a long discussion about things like MTBFs, manufacturing lines, bus speeds, "teaming" spindles in RAID groups, number of drives on a bus or loop, economies of scale, writes vs. reads, etc. I'll get around to this eventually, but ultimately, there's not THAT much difference between the drive technologies.

FC at 4Gbps is going to prove marginaly faster in the average SAN storage array than a 3.2Gbps SAS drive. So use more SAS drives in RAID-10 instead of your FC drives in RAID-5 and enjoy higher performance and lower cost.

Another point worth considering: how many spindles are on the bus or loop? Nine 15K RPM spindles on an Ultra320 SCSI bus won't out-perform nine 15K RPM 4Gb FC spindles, but they will outperform, say, two shelves worth of 15K RPM 4Gb FC spindles attached to the same FCAL. If those same FC drives are Dual-Ported, there will be an additional penalty in contention from two active storage processors.

If you're the typical shop (meaning, if you're implementing server virtualization because most of your servers aren't that I/O or CPU intensive), then you should probably concern yourself more with how much cache your SAN storage processor has and worry less about FC vs. U320.

Hope this helps...

If you don't want to wait for me to finish this article, feel free to contact me by using the contact form or call (see the "CONTACT" button above). P.S. I'm not a reseller; my fulltime employment is with DataCore Software, and I'll be happy to answer your questions and, of course, tell you about how DataCore's SANmelody, SANsymphony and UpTempo products can radically improve performance in your shop and/or allow you to build a high-performance SAN on a restricted budget.