Hardware-level I/O isn't one of my areas of expertise, so I've shied away from discussing certain SAN-specific topics in the past. But recent experiences with SQL Server customers have led me to make the following observation: Contrary to popular belief, SANs aren't necessarily the best solution for a SQL Server system that must support high-end I/O on a budget.
It's true that SANs offer advanced features for I/O and storage management, and they can be configured to offer extremely high levels of availability and performance. But here's a dirty little secret: It's generally harder to configure a SAN correctly than it is to use DAS. And usually, the cost of a direct-attached I/O solution is much less than the cost of buying a SAN that has the same number of disks that offer comparable cache and performance levels.This means that you can often end up with more spindles for the same price by using DAS rather than a SAN.
Customers often assume that buying a SAN is a best practice. But many people don't need SAN's high-end data management and virtualization features. In most cases, you can get better performance by deploying more spindles through DAS.
Don't get me wrong—I'm not saying that you shouldn't use a SAN. I'm simply pointing out that you don't have to use a SAN to build solutions that support very large I/O environments for online transaction processing (OLTP) and data warehousing. In fact, you can expect to hear some interesting news on this topic from certain vendors in the not-too-distant future. I can't mention the vendors' names because I'm under a nondisclosure agreement (NDA), but soon you'll find that the pros and cons for using DAS instead of a SAN will be easier to understand, even if you're hardware challenged like I am.
