Partager via


Some more thoughts on SAN v DAS. Is it actually time to consider DAS?

Ok so here's my thoughts on the whole SAN (Storage Area Network) versus DAS (Direct Attached Storage) argument...

No-one's surprised to learn that storage is still one of the main topics of conversation when architecting an Exchange infrastructure ..but the discussions are definitely now a bit different. With Exchange 2003 the decision as to what type of storage to deploy was always settled quite quickly. For small deployments it was DAS because unless you were sharing a SAN with a lot of other applications it wasn't cost effective. For enterprise deployments, particularly if you had to meet aggressive availability and performance SLA's, and provide this for multiple applications, a SAN was the only viable choice and so architects focused their efforts on getting the design of that storage right. Generally discussions are now different. The decision over what type of storage to deploy is now not settled nearly so quickly. What we have now is a lot more choice and achieving high levels of resilience and performance is not dependant on a SAN infrastructure. Essentially this means that more deployments can be architected to meet aggressive SLA's but critically can fit within a wider range of budgets.

Getting the design of your storage right with Exchange 2003 was always absolutely vital to the success of a solution ..cache ratio's, aligning tracks, RAID 5 or 10, spindle counts, short stroking, jetstress etc, etc, etc... Even if you invested in a high end SAN solution there were no guarantees that you would get anywhere near the performance you required or expected for your Exchange Server - you still had to get the configuration right. ..and let's be honest SAN's can be a bit of a dark art, especially to an Exchange administrator. So in my experience the Exchange administrator was presented with some LUN's and got on with it. There was always a bit of a gulf between the storage guys, who might be providing storage for a number of applications to a number of teams, and the messaging team. Getting the storage configuration wrong was often catastrophic.

For Exchange 2007 things have changed because we now have a much greater choice of options to achieve the same or similar levels of resilience and performance. Of course no-one is arguing that you don't have to be so concerned with your storage architecture if you choose to deploy Exchange 2007, because you absolutely do. It is critical to get your storage configuration right, but the decision has moved on to what type of storage to choose and discussions normally begin with whether to deploy SAN or DAS.

Performance
E2K7 is 64bit. We can use more memory, more efficiently and when we do write to disk we have things like I\O coalescence which means we can write to disk more efficiently and quickly. What this means in practise is that we are no longer so dependent on the performance of our storage subsystem and subsequently we have more choice about what storage we can deploy to provide the performance to our clients that they require. It also means that we can get away with fewer spindles and still provide larger mailboxes to our clients.  If performance is your main focus then I would strongly suggest evaluating a range of storage solutions.  A well designed SAS (serial attached SCSI) solution should provide the performance that you require.

Resilience
E2K7 also gives us continuous replication. When deploying Exchange 2003 many enterprise customers in particular had little choice but to deploy SANs, regardless of their performance requirements. They had to have a SAN to meet their SLA's. SANs can provide a variety of mechanisms to guarantee no data loss in the event of data centre failure, for example, and also fast, hardware based methods for backup and restore. But now we have other options. DPM can provide fast backup and restore using VSS and deploying continuous replication means that we no longer have such a reliance on backup and restore times. I know of at least one major customer of ours that, after exhaustive risk analysis, chose to deploy E2K7 continuous replication and no backup solution but that's another discussion... Exchange 2007 can provide similar levels of resilience to server, storage and site failure natively to that offered by SAN vendors.

Of course one of the major focus points is data loss. Deploying standby continuous replication to provide site resilience is a very viable and cost effective solution for many companies but losing a site will lead to data loss. The data loss is likely to be minimal and well within the Recovery Point Objective of most companies. However it can not compare to a high end SAN solution where no data loss would be a guarantee. (I do want to add a caveat to this in that even the best solution needs to be deployed, monitored and managed correctly. I have been involved in a number of situations where there has been data loss as a result of a problems with the SAN infrastructure because either it had not been deployed and configured correctly or the right processes were not in place to recover the SAN quickly and correctly. I think that Microsoft even suffered a major outage which was one of a number of reasons which led them towards their current storage solution.)

Cost
..of course one thing that all designs have to take account of is cost. There are numerous different types of SAN and DAS solutions and so to make sweeping statements can be dangerous but generally the initial cost of a DAS solution is going to be markedly less than an equivalent SAN solution - I believe Microsoft calculated their proposed DAS solution to be a third of the cost of the equivalent SAN based proposition. That is significant by any measure. I should also point out here that storage vendors have been working hard to produce 'lower end' storage solutions that complement rather than compete with replication technologies within Exchange Server 2007.  This certainly muddies the waters somewhat on the whole SAN versus DAS debate and I would strongly recommend speaking to storage vendors regarding the SAN solutions that they have available.

One of the other factors which can sometimes get lost is that most companies will already have invested in some sort of storage technology.  This investment will extend far beyond the actual hardware to training and experience of their staff, hardware and software support contracts, datacentre management etc etc.. DAS will be more expensive to deploy if it means replacing an established SAN infrastructure which supports multiple applications.  The minor flip side to this is that in my experience most administrators will find the management of a DAS infrastructure straightforward particularly when compared to the step up required when moving the other way, and attempting to manage a large SAN solution for the first time.

Management
One of the arguments that I feel stands out in the real world is that of the management of the SAN infrastructure.  Rightly or wrongly not many Exchange administrators have a lot of experience of managing a SAN solution.  This is generally because most SANs in my experience are managed by a separate team providing a storage infrastructure to a number of different applications across a business.  Essentially this team has responsibility for providing a service to a number of teams with very different requirements and expectations and needs to have control.  Deploying a DAS solution would ordinarily bring the management of the storage back to the Exchange administrators.  If I was an Exchange administrator I'd like that.  If I was in IT management I would like the fact that only one team is responsible for each application.  If a hard disk failure caused a physical corruption of my database I like the fact that the resolution involves only one team regardless of the recovery method.  (I have argued the same for deploying DPM on DAS for protecting your Exchange data.)   I think this could be a critical factor in discussions.

Is it right to put such a definite line between SAN and DAS?
There is actually no black and white choice here. The lines that define SAN over DAS are increasingly blurred.  SAN vendors are reacting to these discussions and several offer 'entry-level' SAN solutions which could compare favourably with equivalent DAS solutions in all areas including price.  One of the obvious advantages is that you can purchase an 'entry-level' SAN and add some of the management, backup, replication type functionality to suit your needs ...at a cost of course.

I'm glad to say though that this is great for those choosing to deploy Exchange 2007 because all of this really just means that there is now a lot more choice. I can see that shifting some of the focus of any Exchange design towards an understanding of exactly what levels of performance and resilience that you require, and therefore what the appropriate storage solution for your organisation is, will increase the chances of a successful deployment.

Get your requirements nailed down early on...
The major change I believe is that Exchange 2007 now gives more companies the ability to achieve greater resilience, better performance and generally a better service to their user community because it's now much more cost effective to do so. What hasn't changed though for Exchange architects is that the key to all of this is getting your requirements right, and agreed. If you know exactly what you've got, and exactly what you are designing for, it's going to be much easier to come up with a storage solution that works.

Easier said than done of course...

Comments

  • Anonymous
    April 20, 2008
    PingBack from http://microsoftnews.askpcdoc.com/?p=3430

  • Anonymous
    May 01, 2008
    Good points, but you are still heavily on the "DAS side" - customers need an objective view of the total cost of ownership of an environment in terms of managing performance, scalability, backups, DR, archiving, and cost. In many cases, CCR/SCR environments require more servers/licenses and more disk (more floor/rack space too) than traditional SAN-based solutions. I work at EMC so my viewpoint will be taken with a grain of salt, but I have yet to see a true objective comparison from anyone who is not Microsoft or a SAN vendor.

  • Anonymous
    May 01, 2008
    Thanks for your comments - I do always try and be as objective as possible and will hopefully be spending some time with EMC to improve my own knowledge and hopefully objectivity..  It's a huge subject.  My concern is really just having as much information as possible to hand to design a solution that is right for the customer...

  • Anonymous
    May 01, 2008
    Thanks for publishing my comments... and I fully agree. As with anything, the extremists get us in trouble. The DAS people saying "do it all on DAS you'll save money" and the SAN people saying "SAN is the best why would you want anything else." I think companies (that I've spoken to at least) are simply looking for solutions to their problems and the majority of large Exchange storage deployments tend to go with SAN and the smaller ones are big fans of DAS.  The companies in the middle are just plain confused :) I do think the cost piece is a bit oversold, especially if the company already has a SAN.

  • Anonymous
    November 27, 2008
    Have been tracking a few internal discussions concerning dynamic disk provisioning – the idea of being

  • Anonymous
    December 23, 2008
    The comment has been removed

  • Anonymous
    December 28, 2008
    This is the first place to start 'http://technet.microsoft.com/en-us/library/cc500980.aspx'..  The situation you are describing is very typical. It is a bit of a change of direction not to place what is perceived to be a tier 1 app on tier 1 or tier 2 storage.  If you don't properly understand Exchange 2007 then DAS would seem to be a very strange and risky decision.  Have a look at the whitepaper above.  DAS works for Microsoft and has worked out to be faster, easier to manage and much more cost effective and the document describes why..?  Hope this helps.

  • Anonymous
    January 07, 2009
    The comment has been removed

  • Anonymous
    January 07, 2009
    The comment has been removed