My April best practices column apparently touched a nerve (see Windows and storage--debunking the myths). That month, I presented an overview of some of the most important storage capabilities available with Windows servers, especially the often-overlooked built-in volume manager. Reader response was tremendous--it turns out that most sites have Windows servers and many are plagued by the myth that Windows is unfriendly to storage administrators.
That discussion was only the tip of the iceberg, however. Microsoft claims to be focused on making Windows "the best storage platform" by integrating enterprise-class features.
In addition to the built-in volume manager, server versions of the Windows operating system include a Multipath I/O (MPIO) driver and the Volume Shadow Copy Service (VSS). The former provides high availability for storage, while the latter allows integrated file system and storage array snapshots. These two features can be used with many of the storage arrays commonly found in today's data centers to improve the stability and recoverability of Windows systems.
Storage isn't very forgiving. If a server loses access to its storage, even for a short time, applications and the operating system can freeze up. This problem was exacerbated by the unreliability of early external SCSI storage systems. The solution was simple, however. By providing multiple channels to the same storage space, a system can continue working even if one link in the storage chain fails.
The task of managing these multiple paths fell to host-resident drivers. Some, like physical volume links (PVLinks) on HP-UX, were basic failover tools integrated into the operating system. Others, like EMC's PowerPath and Hitachi Data Systems' Dynamic Link Manager, were more advanced; they're tuned to work with a specific storage array and to provide high performance with the addition of load-balancing techniques.
Microsoft included a full-featured MPIO driver in the server versions of Windows 2000 and 2003. This driver is extensible through device-specific modules to function with many existing storage arrays using SCSI or Fibre Channel. Depending on the array type, MPIO can support a number of load-balancing techniques in addition to providing high availability through failover.
With Microsoft's release of Version 2 of the iSCSI initiator for Windows, MPIO is also available for the rapidly expanding iSCSI-based storage array market. This allows an iSCSI SAN to meet the criteria for high availability through the use of redundant Ethernet switches and host bus adapters.
Note that Windows MPIO doesn't use disk signatures to detect multiple paths. Instead, it relies on whatever SCSI INQUIRY data a vendor chooses to key on. For many systems, this is a unique serial number, though others might use a combination of other INQUIRY elements.
Every server running Windows and using a compatible array should use this critical technology. Failures due to storage path failures are still quite common, and will likely increase with the use of commodity hardware in iSCSI environments. Plus, the ability to balance I/O over multiple paths will increase throughput for high-end servers.
Volume Shadow Copy Service
While MPIO can improve the availability and performance of Windows storage, the Volume Shadow Copy Service (one of two different Microsoft products called "VSS") can recover affected data in the event of an outage. But it also offers another critical benefit--its so-called "transportable snapshots" work with many backup applications and storage arrays to provide server-free backups.
Again, Microsoft is following the lead of other software vendors with VSS. Most volume managers, and even some RAID drivers, have the ability to take a snapshot of a volume for later use.
These software-based snapshots are limited, however. Creating a snapshot using a volume manager entails a large amount of CPU time, which can impact performance. And many so-called "delta" snapshots read unchanged data from the original disk, resulting in another performance hit. Finally, making a server-created snapshot of a volume available to another server requires additional technology.
Storage hardware vendors responded to the shortcomings of software-based snapshots with the introduction of business-continuance volumes (BCVs). BCVs are array-based snapshots that minimize the impact on attached servers and allow the transportation of a snapshot from one server to another. While these BCVs quickly became a fixture in the enterprise data center, using them traditionally required careful mapping of file systems to LUNs and complicated scripting (see "Avoid the pitfalls of business-continuance volumes," Storage, April 2002, p. 66 and "BCVs: Planning for performance," Storage, June 2002, p. 64).
Microsoft's VSS promises to combine these two approaches under a single interface. With VSS in place, the interface for creating a software snapshot is the same as that for an array-based BCV. When a user requests a snapshot of a Windows drive, the software will create an array-based copy if capable hardware is in use. Otherwise, it will snap off a copy using software. All of this is controlled by a graphical interface.
VSS for backup
VSS wouldn't be terribly interesting if it was simply a better snapshot tool. Backup is the killer app for BCVs, and Microsoft surprised many by introducing a backup API for VSS. The API--called transportable snapshots--allows a backup application to seamlessly request a snapshot of data on a SAN-attached storage array and then mount that drive on a different server to perform the backup. This backup technique can reduce application-impacting backup windows and eliminate performance issues. But transportable snapshots may not be appropriate for every environment.
For starters, you need a backup application that supports transportable snapshots, which means you must be using CommVault 5.5 or higher, Computer Associates' BrightStor 11.1 or Veritas' Backup Exec 10. Next, your data must be on a storage array that supports VSS. But it's the presentation of the VSS LUNs on Fibre Channel SANs that's the trickiest part--you have to configure zoning and LUN masking to make the snapshots visible to your backup server.
The SAN configuration problem is much simpler with iSCSI. Because Ethernet SANs handle LUN access inside the storage array instead of in the SAN fabric, an iSCSI array that supports VSS can configure the backup snapshot to be correctly presented without any extra steps. The use of transportable snapshots on iSCSI is cutting-edge technology, however, and hardware support is still sparse.
As a longtime Unix administrator, I have to admit that I'm skeptical of Windows in the data center. When I first heard of VSS, I wasn't impressed--I thought it was a
simple software snapshot technology for Windows. But seeing these technologies in action allayed many of my concerns. MPIO and VSS work very well, and their integration with enterprise storage arrays is impressive. In fact, VSS has proved so popular that many users report switching from Windows 2000 to Windows Server 2003 solely to gain this functionality.