Comparing Drive Technologies
A White Paper by Tim Warden
Overview
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.
PCI, PCI-X, PCIe
FC, SAS, SATA, SCSI
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.
|
