Storing exchange databases on NAS: is it safe to go back in the water?

From the early days of Exchange, Microsoft has insisted that it doesn't support its Exchange databases on network-attached storage (NAS) appliances. Note that "doesn't support" does not mean "doesn't work," and many companies store Exchange databases on their NAS appliances anyway. Network Appliance is particularly active in the Exchange-on-NAS area, since their filers are large and robust, and their built-in NTAP snapshot technology delivers high levels of data protection that other NAS appliances do not.

The situation hasn't changed. Microsoft still does not support Exchange 2000 on NAS, and Network Appliance still does a healthy business doing just that. Who's right and who's wrong? Neither--and both. Exchange can run successfully on a NAS box if users meet stringent technical requirements and are willing to live without Microsoft support for their Exchange databases. That constitutes are pretty big "if," and Microsoft is issuing accurate warnings. However, it's important to remember that Microsoft has a strong market push for its own NAS offerings in Windows Storage Server 2003, a direct competitor to NetApp's NAS fliers. This doesn't obliterate the technical issues, but it does cast a certain light on them.

Technical Issues

Many good-sized customers, including government, agencies, large corporations, and what's left of the SSPs, do host their Exchange databases on NAS. The most successful installations use fast networks and sophisticated NAS clusters from vendors like EMC and NetApp (though unlike NetApp, EMC does not push NAS for hosting Exchange databases). With customers experiencing 300% growth in message stores each year, there's no question that a robust and scalable NAS can be an attractive replacement for direct-attached storage (DAS For example, a clustered NAS with good storage management capabilities can reduce system management overhead by on half to two-thirds.

And databases can run successfully on NAS--Oracle has qualified EMC to host its databases since time out of mind, or what counts for that in the computer world. NAS fliers are easier to set up, modify and change than direct-attached storage can be, and in spite of high price tags on upper-end fliers they can lower total cost of ownership (TCO). And stacked up against storage area networks, NAS's IP connections generally cost much less than Fibre Channel (FC).

But NAS cannot safely host all databases, and (as Handel said) "therein lies the rub." Here's the heart of the matter: Exchange (and Lotus Notes/Domino, too) expect the reliability and error-resistance of a channel connection (DAS and SAN), which NAS's IP connections lack. A NAS system is a file-based storage system. It is attached to an Exchange 2000 server through a network redirector with a file sharing protocol (SMB, CIFS or NFS) using the Universal Naming Convention (UNC). This is a Perfectly good way to manage and store file system-based files, but messaging databases do not expect or enjoy this form of file redirection.

The consequences of accessing messaging database through the network stack, as opposed to accessing the storage system as a local or local-appearing device, can increase the risk of corrupting data and degrading performance. This risk gets worse as disk operations get busier and increase I/O a bandwidth requirements with resulting management complexity. Microsoft's conclusion (and Domino/Lotus Notes bears it out) is that the disk system that is used to store messaging data must have all the features of locally attached block storage (Microsoft will support NAS devices that handle both files and blocks, such as hybrid NAS appliances or NAS gateways, as long as the logical unit is exposed to the network using an FC or parallel SCSI interface instead of as a file system. Microsoft slaps on a "Designed for Windows" logo to identify qualifying configurations.)

To remain stable and uncorrupted, Exchange message stores demand a deterministic connection, where the requesting server waits for a response to its request before continuing. Channel connections in DAS and SAN fit this bill. But NAS with its IP connections are non-deterministic: the server issues its request, and other than tracking a time-out period does not wait for a response to its action. A transmission error in this environment can badly compromise the Exchange databases, and restoring corrupted Exchange servers can be an utter nightmare. (This is why NetApp is successful at hosting Exchange databases anyway: their NTAP technology provides a high level of data protection and recovery.) So can you run Exchange on NAS? Tom Joyce, senior director of NAS product marketing at EMC, said yes--maybe. "You can get it to work downhill, the wind at your back, the way that you want it to be. Can you get the .PST files on NAS? Yes, no problem. But NAS has expectations that Microsoft's operating systems do not meet. What if the connection goes away? In the channel world, connections don't go away. In the IP world the NAS connection does go away, and Exchange doesn't expect that. It's not built for it It's a bad thing."

When it comes to Exchange and NAS, Microsoft strongly recommends that users run Exchange on a channel connection, which means direct-attached or SAN. Even with NetApp's NTAP and third-party data protection software, Microsoft discourages Exchange administrators from running the risk of NAS data corruption, Actually, Microsoft does more than suggest: if customers run Exchange on a NAS and run into problems, Microsoft does a corporate version of "I told you so" and blithely ignores them. This means that for large corporate users, who are running huge message stores on NAS, they must decide to go without Microsoft support for their most critical enterprise application. With enterprise users' large expectations, this does not go over well at all.

Market Considerations

Although Microsoft's technical NAS concerns are genuine, some of their non supportive approach rises from their own forays into storage networking, Microsoft is pushing its NAS operating system and management software, especially its Windows Storage Server 2003, which adds enterprise feature to a Windows OS on NAS. Storage Server 2003, which replaces Microsoft's earlier Windows Powered NAS, has added features including server clustering, DFS (Distributed File System) and VSS (Volume Shadow Copy), which is in direct competition with NetApp's NTAR These features allow its OS-powered NAS boxes to support advanced data protection operations like snapshots, virtualization and multiple-pathing architectures, all important enterprise features. The capabilities are limited to certain configurations, but that may change--the software company has already signed up HP, Dell, EMC and Iomega to offer NAS products containing various Storage Server 2003 technology flavors.

According to Ashok Kumar, a senior research analyst at Piper Jaffray, VSS is not as streamlined or flexible a NTAP's snapshot technology but will be an attractive feature to Microsoft houses looking to upgrade to Storage Server 2003. The two companies have firmly entrenched positions--Microsoft in the mid-range server/storage space and NetApp in the enterprise--but Windows Storage Server may be Microsoft's ticket into high-end shops. Certainly HE EMC and IBM are firmly entrenched in the high end and may make significant inroads into NetApp's business. Kumar does not expect an immediate impact on NetApp's bottom line, because its respected technology is firmly in place and Microsoft is not exactly a storage giant. Yet.

But aren't these still NAS devices, and don't they still lack channel connections? Quite right. Every criticism leveled at NAS and Exchange is still true for any NAS, whether or not it's running a Windows operating system. But Microsoft is proclaiming that--amazingly enough--Exchange can safely run over NAS fliers using this OS because it is optimized for Exchange, and has high levels of data protection. (You can bet that NetApp is not sitting on its hands: it has been improving its management capabilities and ability to integrate with Microsoft's OS and file system demands.)

The real progress in this Exchange/NAS space is not really in Storage Server 2003 anyway, but may be in Microsoft's upcoming database-like file system, an add-on to their next-generation OS platform "Longhorn." Here's the background: DAS and SAN handle data on the block level, while IP-connected NAS manages it on the file level; and never the twain shall meet. But the add on, provisionally named Windows Future Storage (WinFS), will abstract physical file locations from data. Based on SQL Server 2003 technology, WinFS will initially be a desktop add-on, and will allow efficient data searches across a number of targets. A later major server release named "Blackcomb" will use the technology to change the way storage manages data: all storage targets running WinFS will be able to manage data on a fast and efficient block level, even if the blocks have file characteristics. The next few years will tell the tale: Microsoft is famous for missing shipping dates, but eventually they conic through.

An ending note: Wondering about these code names? Remember Microsoft's code name "Whistler" for Windows XP? Whistler and Blackcomb are the names of British Columbia ski areas that are not far from company headquarters, and Longhorn is a bar at the bottom of Whistler Mountain. No doubt Microsoft's overworked engineers are doing some wishful thinking.

www.emc.com

www.microsoft.com

www.networkappliance.com

www.pjc.com