Getting Exchange to work with NAS
by: Alan Mclachlan
Issue: Mar 2002
Exchange 5.5 required some monkeying to work with network- attached storage (NAS), but Exchange 2000 presents different and more fundamental obstacles. Overcoming the mail server's storage limitations will require new approaches.
Storage managers have had to deal with uncertain support for NAS in key Microsoft applications in the past year. Changes in these applications have had the effect of banning or limiting the use of NAS with the Exchange 2000 mail server and the SQL Server 7.0 database management server.
In part, Microsoft seems to have banned NAS to avoid dealing with the particular problems that might occur when using low-end NAS boxes in business-critical situations. Yet there are also intrinsic design issues with Exchange and Windows 2000 that Microsoft has solved in a way that makes NAS use difficult with even the most sophisticated NAS boxes.
Microsoft itself has recently tried to soften at least the appearance of its stance by laying down certain ground rules under which it might support Exchange customers who use NAS. The bottom line, though, is that currently the only way to make NAS work with Exchange 2000 is by using add-on software or hardware.
What's the problem?
Special accommodations for Microsoft apps with NAS are not new.
With both SQL Server 6.5 and Exchange 5.5, the primary issue in using NAS is ensuring reliable unattended reboots. Both products address files using pathnames beginning with a drive letter. However, in the boot process the SQL or Exchange services could potentially fail to start if the network drive letter was not yet available. The workaround is to use either the AutoexecNT or srvany tool from the Windows NT Resource Kit to make the service startups dependent on the successful completion of a script that would map the drive letters. Many Network Appliance, Auspex, and EMC Celerra customers use this approach successfully.
In SQL Server 7, Microsoft introduced the option of using Universal Naming Convention (UNC) paths, which eliminates the drive letter issue. UNC paths are available very early in the boot process of Windows NT, Windows 2000, and Windows XP, which means that as long as the NAS device is operational, the SQL services will start successfully.
Exchange 2000's problem with NAS is more fundamental. Microsoft has implemented a special block mode driver in Exchange 2000 to improve messaging performance on locally-attached storage, and since the use of this driver is not optional, this effectively prevents the use of network-attached storage.
According to David Sirocky, product manager for Exchange, this architecture was the result of decisions taken several years ago to improve both performance and ease of application development. Those moves were made, says Sirocky, before NAS was as popular as it is now. Essentially, NAS was ignored in product design.
We have been unable to get a clear enough explanation of this technological approach from Microsoft to definitively evaluate the company's argument, despite repeated attempts. In any event, most of Microsoft's major database competitors have embraced NAS and certified some NAS vendors as storage platforms. Oracle, Sybase, and IBM have all certified particular NAS platforms for storing their databases, including the versions that run on Windows.
Both political and technical factors are apparently at work here. Storing business-critical messaging databases reliably on NAS requires technical skill on the part of the systems integrator to ensure that the architecture provides suitable data integrity guarantees. Microsoft is smart to insulate itself from support issues that may rely upon third-party expertise.
In recent discussions, Microsoft also tends to make much of the fact that disk writes to NAS boxes cannot be guaranteed in the event of hardware errors or power failures. That's a less than compelling argument against the kind of high-end boxes that are generally available from leading NAS vendors, replete with redundant power supplies and sophisticated journaling filesystems.
In recent weeks, Microsoft has been attempting to craft an approach that blesses NAS without requiring a rewrite of significant parts of the company's applications. While this attempt is still in progress, it would appear to have several components, such as: continuation of the policy of not blessing (with Hardware Compatibility List certification) NAS hardware; supporting problems unrelated to storage for users who do use non-HCL NAS hardware; and perhaps, ultimately, certifying iSCSI as the way to use networked storage on Ethernet. For now, a willingness to work with users who use higher-end NAS, and a decision to leave support of the storage to the storage vendor, may be the best users can expect from Microsoft.
NAS workarounds
As of this writing, the only NAS device with HCL listing is Procom's NetForce 3000 with Duet. In truth, Duet is a backend sharing system which needs a Fibre Channel switch.
NetApp has implemented a different approach, one that does not require adding Fibre Channel to your infrastructure. NetApp sells SnapManager for Exchange to install on Exchange 5.5 and Exchange 2000 servers to provide enhanced interoperability with some of the company's data protection features. In the case of Exchange 2000, the software provides a target driver that makes a file on the NAS device appear to be a local disk to Exchange . To support this particular application, NetApp has moved straight into the storage virtualization and block-over-IP business.
Some shops that want to centralize their storage on NAS but also need to use Exchange 2000 are adopting a hybrid hardware approach, using dedicated direct-attached RAID storage for the Exchange server and NAS for all other requirements. While many storage experts might see this as a step backward, such an approach can still be far cheaper to install and manage with existing skills than a move to a full-blown Fibre Channel SAN.
Alternatively, the "Ethernet SAN" - using a dedicated Gigabit Ethernet network to connect application servers to high-end NAS - is gaining popularity because it can provide many of the benefits of a Fibre Channel SAN without the overhead, while still leaving the door open for block-over-IP for those applications that need that kind of raw access.
Microsoft has started to learn about the impact of storage methods on applications and data integrity, and is starting to attempt to impose controls on storage architecture. Whether this is a good thing or not will depend on how openly the company works with other vendors to take advantage of the available technologies to improve performance and scalability while maintaining data integrity.
Microsoft is attempting to take on Oracle and IBM's DB2 in enterprise database environments. The vendors of both of these products, who have tremendous experience in managing direct-attached storage, have embraced enterprise NAS as a scalability-enabling technology. In a world where information has become the single most valuable commodity, integration with networked storage will be critical in how storage managers see Microsoft in tomorrow's architectures.
(Tuning NAS for block-oriented applications
Significant advances in both network interface card (NIC) and Ethernet technologies are reducing performance problems for block-oriented applications and NAS. Many new Gigabit Ethernet NICs from Alacritech, Intel, NetGear, Sysconnect, Broadcom (Dell and Compaq) and other vendors support offload features such as:
TCP Checksum Offloading. The NIC performs the required checksum in hardware.
DMA Bus Master Transfers. Data copies are performed by the NIC itself, not the host CPU.
Interrupt Coalescing. The NIC will accumulate associated transfers to reduce interrupts.
Jumbo Frames. Allows much larger raw packet sizes on Ethernet, up to 34KB.
Commonly, jumbo frame implementations by Intel, Hewlett-Packard, Cisco, Alteon, and other vendors use a 9KB maximum transmission unit size - much larger than the raw frame size of both standard Ethernet (1,500 bytes) and Fibre Channel (2,112 bytes). This serves to both improve streaming performance and reduce host CPU interrupts.
Some SCSI-over-IP approaches, including NetApp's SnapManager for Exchange product, use the 9KB packet size on Gigabit Ethernet allowed by jumbo frames to shift up to 2 by 4KB "virtual disk blocks" in one operation. Jumbo frames have the potential to enable very high performance for large object transfers on a standard IP network over Gigabit Ethernet.
Note that not all switches currently support jumbo frames, so their use should be restricted to dedicated storage networks.) |
