What is NAS?
There are a lot of different varieties of network-attached storage (NAS) servers on the market. But generally, a NAS server is a simple server with an embedded operating system that contains a network card and a lot of disk space. Although there are single-disk NAS servers, most include multiple hard drives that can be configured to act as independent volumes or work together in a RAID array.
The benefits of NAS servers are that they are inexpensive and simple to deploy. I have seen NAS servers with two hard drives for under $400 U.S. Of course, a model like that is geared toward home users, but even NAS servers that are intended for corporations aren't very expensive.
I was recently looking at one particular model for my own network that included four 400 GB hard drives, a RAID controller, and a gigabit network interface. This server, with a total of 1.6 TB of disk space, only costs about $1,500 U.S.
Configuring a NAS server is typically easy. Configuration methods vary, but many NAS servers can be configured through a simple Web interface similar to those used in wireless access points.
Why doesn't everyone use NAS for Exchange Server storage?
My description of NAS in the section above probably makes it sound like NAS is the greatest thing since sliced bread (it is). So you may be wondering why you don't see more organizations using NAS as a storage solution for their Exchange servers.
To answer this question, you need a little bit of historical prospective. When Exchange 4.0 came out, there was no such thing as NAS (or SAN for that matter). Even if such technologies had existed, networks at that time were so slow that it would have been nearly impossible to store an Exchange Server database on anything other than the server that was running Exchange Server.
The latency involved in communicating with an external server would have made Exchange Server even more inefficient than it already was, and it would have made the data much more prone to corruption. As such, Microsoft made local database storage a requirement for Exchange Server.
Fast forward a few years and NAS and SAN were invented. Microsoft realized the potential of SAN and eventually approved it for use with Exchange Server. But for some reason, NAS remained unsupported until just a couple of years ago.
When I say that NAS was officially unsupported, that doesn't mean it didn't work with Exchange Server. It just means that Microsoft would not give you any technical support if you did choose to connect Exchange to a NAS server. (Microsoft will also not support NAS in Exchange Server 2007.)
In the year 2003 though, Microsoft decided to get into the NAS business and began producing a version of Windows Server 2003 that was specifically designed for NAS use. That version of Windows is called Windows Storage Server 2003. The following year, Microsoft created a feature pack for Windows Storage Server 2003 that would allow Exchange Server databases to be stored on volumes hosted by a Windows Storage Server 2003 based NAS box.
After the creation of this feature pack, Microsoft began to officially support Exchange Server's use of NAS, so long as the underlying NAS made use of Windows Storage Server 2003 and the Exchange Server feature pack.
NAS benefits for Exchange Server storage
Some organizations take advantage of the low cost of NAS servers by putting them into branch offices that would never be good candidates for SAN connectivity. It is also common for organizations to consolidate multiple Exchange servers onto a single NAS box.
In my opinion though, the biggest advantage to using NAS for Exchange Server is that it allows you to create a low-budget Exchange Server cluster. It is actually possible for the NAS server to be treated as a shared storage device for two-cluster nodes.
NAS disk configuration for Exchange Server storage
Since most NAS servers support various RAID configurations, it might be tempting to split a single RAID into two volumes -- one for the transaction logs and one for the databases. However, Microsoft recommends using a NAS server solely for Exchange Server database storage. Exchange Server transaction logs should still be stored on a local RAID array.
Keeping the Exchange Server transaction logs stored on a separate box from the Exchange Server database guarantees that the transaction logs will still be accessible, even if the volume containing the database fails.
Just as importantly though, all transactions are written to the transaction logs before they're committed to the Exchange Serve database. Committing transactions to the database is something that Exchange Server does during periods of low activity. Therefore, it makes sense to dedicate your fastest disk resources to the transaction logs.
Although the drives in your NAS server may very well be faster than the drives in the local server, you have to think about the speed of the network connection between the Exchange Server box and the NAS box. Unless you've got a direct Fibre Channel connection, Exchange Server is almost always going to be able to access local storage more quickly than NAS storage.
NAS can be an economical and reliable storage medium for Exchange Server storage. If you are thinking about implementing NAS-based storage for Exchange Server though, make sure the NAS server that you're considering is officially supported by Microsoft. Here is an excellent white paper on the subject.
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.