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.
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.
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.)
..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.
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…