What is a SAN?
Typically, the connections between the various storage devices within a SAN are based on Fibre Channel. A server can access data from a SAN more quickly than it could from local- or direct-attached storage, because of the combination of the Fibre Channel connection and the way the disks are striped.
SANs are also designed to be very fault tolerant. Not only are disk arrays within the SAN designed for fault tolerance, but the connections between those disks are also fault tolerant. SANs implement multiple data paths, so if one path fails, there is always another one available.
Although there is plenty of hardware involved in a SAN, the software is just as important. Since the whole premise of a SAN is centralizing storage resources, a SAN must be able to share multiple storage resources with multiple servers.
Furthermore, it is not uncommon for servers connecting to a SAN to be running different operating systems. As such, SANs depend on specialized software for configuration, resource allocation, and monitoring.
At the present time, there is no such thing as a universally compatible SAN software package. SAN software is proprietary in nature and almost always tied to specific products or vendors.
The advantages of using a SAN for Exchange Server storage
- SANs are an excellent storage solution for Exchange Server because of their high performance and fault tolerance.
- You can achieve an extremely high data throughput with a SAN. This is important since Exchange Server is so disk I/O intensive.
- A SAN meets Exchange Server's local drive requirement. Exchange Server requires that mailbox and public folder stores exist on a local hard drive (or array). A SAN is anything but local to an Exchange Server, but it doesn't matter. You can create a direct Fibre Channel connection from the Exchange Server to the SAN, which allows Exchange Server to recognize the SAN as local storage.
- The biggest advantage to using a SAN for Exchange Server storage is scalability. You have to assume that your organization's data storage needs are going to increase in the future. SANs make it relatively easy to expand the size of a volume by adding additional disks (although, this expansion usually isn't an automated process).
Likewise, if you add more Exchange Servers to your network in the future, they can share the SAN as well, so a SAN can grow with your Exchange Server organization.. (Keep in mind though that I am talking about having the servers share physical storage devices, not the data on those devices.)
The disadvantages of using a SAN for Exchange Server storage
SANs are not cheap. There is a good chance that your boss is going to get a bad case of sticker shock when you tell him or her what it's going to cost to deploy one. At the same time though, the high initial deployment cost can sometimes be offset by a lower cost of future maintenance.
Another disadvantage to a SAN deployment is its complexity. SANs are a science in and of themselves. Even though many of the larger computer manufacturers sell SAN packages that are ready to go, there is still going to be a significant learning curve associated with deploying and maintaining one.
In spite of its complexity, SAN-based Exchange Server storage is usually the way to go -- if your budget and staffing resources allows for it.
If you would like to learn more about the basics of SAN, here is an excellent SAN tutorial.
CRASH COURSE: EXCHANGE SERVER 2003 STORAGE MANAGEMENT
Part 1: Microsoft's Exchange Server storage recommendations
Part 2: RAID configuration options for Exchange Server storage
Part 3: Using a SAN for Exchange Server storage
Part 4: Using NAS for Exchange Server storage
Part 5: Using DAS for Exchange Server storage
Part 6: Related resources on Exchange Server storage management
|ABOUT THE AUTHOR:|
Brien M. Posey, MCSE|
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
This was first published in October 2006