DAS vs. SAN in Enterprise SharePoint Architecture

For those who attended my webcast earlier this week, a question came up regarding the performance of Directly Attached Storage (DAS) versus Storage Area Network (SAN) that I felt was not answered adequately. Specifically, the attendee was curious as to why I would recommend DAS over SAN in a highly-scalable environment. The answer isn’t as complex as it might seem but it does bear some further discussion. The most salient and important point – and the one SAN vendors don’t really like to talk about – is resource contention.

Shared resources are the biggest achilles heel of any SAN deployment (and, for that matter, SQL clusters). The investment for a highly scalable SAN configuration is HUGE; therefore, most organizations treat it as a shared environment for many enterprise applications. This means that all those mission-critical applications – including your MOSS farm – are sharing the same disk pool. Yes, I know that each has dedicated LUNS, but think about what is really going on under the covers. The network links, typically only one gigabit connection but sometimes several bonded connections, along with the physical disks themselves and the bus are all being utilized by numerous read/write requests. Is that the optimal configuration from the perspective of each application? No, it’s only optimal from a TCO perspective – sharing a big, flexible disk array across multiple apps saves money but it doesn’t guarantee optimal performance for any single application.

As Linchi Shea points out in this article, a SAN can be configured to outperform DAS and vice-versa. If you read the article carefully, you will notice that the only configuration in which SAN beats DAS is a very-expensive, highly-meshed setup that dedicates all the SAN resources to the tested application and doesn’t factor in any other resource contention (you’ll also notice that the DAS configuration used was suboptimal and doesn’t represent any type of true production scenario). This is an issue that doesn’t exist with DAS – the storage resources are controlled directly by the host with no other contention. And let’s not forget that most people these days aren’t even deploying *real* SAN’s – they’re actually deploying massive NAS (Network Attached Storage) arrays. I can’t tell you how many times I’ve walked into a data center and seen a big honking NetApp box plugged in by a single cable to the last available port on a gigabit switch. This is insanity – you cannot possible expect that much traffic across a shared network segment to product any kind of reasonable performance. And yet it happens more often than not.

The discussion shouldn’t be about pie-in-the-sky techie dream environments where everything automagically uses a megapipe and nothing is restricted by bandwidth, throughput or IOPS. Instead, it should focus on practical realities and the reality is that big SAN/NAS boxes get shared by everything and it’s brother. Is this bad? No, not necessarily, but if you’re architecting a large SharePoint deployment for optimal performance then that configuration is certainly not going to meet the requirements. I know DAS is hard to scale and maintain and that SAN has all kinds of operational benefits but we’re talking SharePoint performance here and optimal performance means dedicated – not shared – resources.

Naturally, the same can be said about SQL Server (and often is). Yes, SQL licenses are expensive. Yes, it’s very tempting to put all kinds of enterprise apps on a SQL cluster for optimal ROI. And yes, this will decrease the overall performance of your MOSS environment. It’s the same shared-resource issue; there are only so many CPU cycles and RAM to go around and you don’t want anything else contending for the resources that those oh-so-optimized (that’s heavy sarcasm, in case you missed it) SharePoint database queries are demanding. You want SharePoint to scream? Give it what it needs – dedicated SQL, dedicated disk, dedicated bandwidth and dedicated directory connections (or, even better, ADAM – no, not that Adam). Starve it of resources and you’ll be forever wondering why things just never seem to be quite fast enough.