Years ago the suggestion that an Exchange server, or any Windows-based server for that matter, should store its operating system data on a storage area network (SAN) would have been absurd. Now, the idea that this is not credible is no longer accepted.
In corporate environments, even in small and medium-sized businesses, the issues associated with storing Exchange Server data on a SAN are both environmental and commercial. Why should companies spend money on a RAID 1 pair of 144 GB disks?
- It's difficult to obtain smaller disks from vendors to host what will probably be no more than 20 or 30 GB of Exchange Server data. That's approximately 110 GB of wasted storage capacity.
- Two spinning disks use up electricity and generate heat that needs to be dealt with somehow. Put into a storage array, those two disks -- still in their RAID1 configuration -- could cope with four or more servers.
This saves the cost of six disks, not to mention the fact that it uses a lot less heat and electricity.
What about the idea that the SAN fabric isn't up to the job of processing that much constant information? A few years ago, the fabric bandwidth to the servers was 1 Gb (gigabit); large Exchange databases still managed to serve up random read and sequential write operations without too much difficulty. Current speeds are greater than 10 Gb and, more importantly, latency is reduced due to additional fast disks in a networked storage array.
Why are there so many spinning disks inside individual servers? A reduction in disk space is only part of the story. Take a look at a typical intelligent networked storage array and how it handles space. Companies running several Exchange servers might use a form of thin provisioning to further optimize the amount of space taken up on the SAN by the various Windows servers.
SAN vendors differ in how they define thin provisioning and what it means in various scenarios. Some vendors define it as telling the server it has a certain amount of disk space when, in reality, the amount that each server has is much less than what it thinks is contained within the SAN.
As it applies to boot images, the thin provisioning process works by taking a single "gold image," which is created by loading an operating system in the usual way, and then configuring it with basic information. The storage administrator then "clones" that image and presents it to a physical server as a new LUN, or logical disk.
The cloned image initially takes up virtually zero space on the storage array. However, when the new Exchange server is booted up and the administrator starts to make configuration changes, information is then written back to the cloned disk. For example, if a single 30 GB image is cloned several times, each clone takes up about 1 GB of space instead of 30 GB of space.
Here is the point where some SAN configurations start to experience problems. Storage arrays that do not manage thin provisioning properly start to suffer from a phenomenon known as "hot spots." This occurs when too many read operations are carried out at the disk location of the original "gold" image. Any storage vendor that promotes thin provisioning will tell you how they avoid the problem of hot spots. Although SAN vendors split disks and form RAID arrays differently, most have innovative solutions to ensure that disk load is spread evenly across the storage array.
That covers the environmental and commercial reasons for implementing an Exchange Server boot from a SAN infrastructure, but what about Exchange data protection? What does the SAN offer that a backup tape or backup to disk doesn't? The answer is replication.
The operating system is now simply a LUN on the SAN, which means that the LUN can be replicated anywhere. The LUN can be replicated to a remote data center where several Exchange servers are ready to assume the identity of the original server.
Using the same thin provisioning steps that initially got the Exchange server up and running can be beneficial. The LUN, along with any network-based data, can be cloned to test upgrades, service packs and patches in a true, yet completely isolated, manner. This makes it possible to generate and test more than a dozen copies of your entire Exchange environment, which takes up virtually zero space. You'll also be able to create or tear down these copies whenever you want to test or troubleshoot applications on Exchange servers.
Implementing a boot-from-SAN technology represents a major leap in the capability of an Exchange administrator to provide resiliency and, at the same time, reduce complexity. It provides the ability to test against a true copy of live data in a space-efficient manner, without disturbing any running live data.
About the author: Mark Arnold, MCSE+M and Microsoft MVP, is Principal Consultant with LMA Consulting LLC, a private messaging and storage consultancy based in Philadelphia, Penn. Mark assists customers in designs of SAN-based Exchange Server implementations. He has been a Microsoft MVP in the Exchange discipline since 2001, contributes to various Microsoft-focused technology websites, and can be found in the Exchange newsgroups and other Exchange forums.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
