SATA and RAID 6 – the perfect match!
Posted in General, Storage Applications, Storage Interconnects & RAID, Application Environments, Advisor - Joe by Joe DisherTalk about a technology that has needed some help for Enterprise acceptance. SATA certainly has had its problems getting any sort of acceptance in the Enterprise – and rightfully so when compared to the other more reliable and more expensive drive alternatives such as SCSI, FC and now SAS.
Now with RAID 6 (explained in more detail by a fellow blogger) those poor little SATA drives can join the Enterprise party – albeit still in limited environments. Never-the-less, it’s a great alternative for customers that are looking for high capacity drives and Enterprise reliability. You lose some on performance, but if the customer is looking for ‘deep’, low-cost, reliable storage – they will probably be willing to give a little on performance. Such is life – you can never have it all - not yet anyway!
Finally these “third class citizens” (SATA drives) can get a little respect with a little help from RAID 6. For applications that are hungry for disk space, but don’t need the highest performance levels this seems like the perfect solution. Applications such as Exchange and some SQL databases can get a real capacity boost with great reliability and “good enough” performance.
Would you use SATA drives with RAID 6 in your data center? If so, what applications do you think fit best?
Blog ya later!
Joe
November 3rd, 2005 at 10:02 pm
Hi Joe,
I respectfully disagree that an application such as Exchange requiring IOPS and low latency (sub 15msec) will benefit from SATA drives. In a lot of cases the exact opposite is true. You really have to pick your spots with SATA deployments and you really have to look at the application very closely. What I’ve found is that vendors pushing SATA tend to size by capacity rather than the app’s performance requirements so they can drive the cost even lower. So you end up with small size raid groups, in terms of spindle count, and huge capacities, most of which remain dormant. Almost always the latency will kill you from such configs. When people complain about performance in Exchange or any random I/O app, in reality it’s latency they are complaining about.
Slap RAID 6 on top of that and the possibility for a mess is real.
I recently saw an iSCSI deployment with SATA to support 1500 users with a 500MB mailbox size. The array was configured with RAID 10 and 10 SATA drives. Assuming you have medium access users (1 IOP per) then you need 1500 IOPs to suport them assuming 100% user concurrency. There’s no way you’ll get these many IOPs from this config. Heck even with FC drives and assuming 95-100 IOPs per drive with under 10msec latency than you still don’t have enough drives. Even if the number of concurrent users was at 80% you still can’t do it.
To make a long story short, my prospect says…”iSCSI sucks. Exchange’s not performing well at all and people are bitching. I think I’ll move to Fibre Channel”…Hm…As if FC would make a difference with the config he had.
What I don’t like is that there are vendors out there that push iSCSI with a SATA combination and put inappropriate configurations on their customer’s floor. Given that iSCSI is relatively a new protocol, people always tend to point the finger to it as soon as performance problems occur. It’s the easy way out…
Anyway, SATA drives are ok for large sequential I/O. With a block size above 64k they can derive around 60-70% of the equivalent configuration of Fibre Channel drives. On random I/O they provide around 25%-30% of the service of an equivalent FC configuration. SAS drives appear as if they are more of a fit to provide good service to apps requiring IOPS and acceptable latency. I’d deploy SATA for Exchange for no more than 500-800 users. After that it’s a training exersice.
I like iSCSI a lot. I think it’s disruptive, it has certainly been an enabler for SMBs to rip the benefits of networked storage at lower entry points than FC (in most cases) and it has also pushed Fibre Channel vendors to do the unthinkable…Attempt to simplify FC installation and mgmt as well lower FC entry costs in an attempt to keep iSCSI from proliferating. Thus far from where I’m standing the majority of SMB’s that have gigE infrastructures opt for iSCSI. In particular, windows shops make up over 85%-90% of iSCSI deployments with Linux starting to crop up. I believe Linux is the next platform iSCSI will be getting deployed. FC drivers for Linux suck anyway…
I’d also like to tip my hat to Microsoft because they’ve done a teriffic job with their initiator and in general they have stood behind the protocol and made it safe for people to use.
I also see it starting to get deployed in large Datacanters to support Business critical (i.e Exchange) and non-business critical apps. I also see it as a DR protocol for remote Datacenters as well as the protocol of choice for remote offices. Makes sense. The Education sector has also gone for iSCSI big time. VMware’s also a very interesting platform for iSCSI as well. Especially now that they have released a native iSCSI initiator (HW or SW).
Keep up the good work
Cheers
November 3rd, 2005 at 11:38 pm
NickT - what a timely comment! I was just running a quick spell check on a new entry (When is fast, fast enough?) on the very topic of performance - not specific to drive interconnect, RAID, iSCSI or any of the other topics I’ve been talking about lately.
You bring up some great points, especially on Exchange. I was eluding to smaller deployments for the SME market segment (sub 500 employees)Remember I said “good enough” performance - You’ll rarely hear a large Enterprise say “good enough” when talking about performance unless thier talking about their end users desktops! I should have been more specific - good catch. (Hmmm - I’m an end user now! No wonder my laptop is so slow!)
Now to rant some more on another point you made: Why is it that some customers are so ready to blame a technology that they aren’t familiar with for a performance problem? I’ve often found that the problems with performance usually come from a bottleneck in the host server or simply a bad storage configuration as you so eloquently described.
Keep the comments coming - I like your insight on this topic!
Blog ya later!
Joe