If you're a Windows administrator who has dealt with storage for a while, you've probably lamented how poorly Windows handles multiple paths to storage resources. You might have spent a lot of time and money (e.g., investing in RAID, clustering, and third-party solutions) trying to ensure that your storage is highly available only to find that you still had a point of failure: the paths from the server to the storage device. Because the path to a storage device can encompass many components (e.g., buses, cabling, switches, controllers, connectors, host bus adapters--HBAs), ensuring that each link in that chain is strong can be difficult at best. If you've employed a specific vendor's multipathing technology to ensure that your systems can use multiple I/O paths to storage devices, you might also have been frustrated by the fact that the solution provided neither redundancy nor load balancing particularly well.

The problem with early versions of Windows was that the Windows storage I/O subsystem didn't natively support multipath failover or I/O load balancing. Windows was simply ignorant of more than one path to a storage device. Storage vendors eager to differentiate their platform from competitors' products in the Windows space quickly (and inadequately) filled this functionality gap. However, every vendor did so uniquely and with varying degrees of success. For example, EMC's and HP's multipathing solutions worked differently and wouldn't interoperate.

From Microsoft's viewpoint, such third-party solutions generated endless support calls when they didn't work. In addition, keeping all the solutions in sync with Windows releases became a nightmare--and one that IT shops ultimately paid the price for.

Enter Microsoft Multipath I/O (MPIO). With MPIO, Microsoft provides native OS drivers and support for multipathing. Each storage vendor must then develop what Microsoft calls a device-specific module (DSM) to integrate MPIO with the specifics of the vendor's hardware solution. Microsoft requires the products to meet standards (i.e., through the Windows Logo program) that ensure compatibility and functionality.

MPIO starts with the base OS and relies on the Windows Plug and Play (PnP) facilities to dynamically detect and configure storage devices. By seamlessly working with the PnP architecture, the MPIO driver can detect and configure storage devices and the I/O paths to those devices.

Another key to the MPIO solution is the successful enumeration of storage devices as they are detected. For enumeration to work, each device must have a unique identifier. Rather than using disk signatures (the traditional means of unique identification), MPIO uses hardware information available from the vendor, such as a device serial number. Each device must be identified by vendor and type--is the device unique, or is it one that PnP has already identified and accounted for through another path? Because not all vendors enumerate and uniquely identify devices the same way, the MPIO drive and the vendor DSM work together to identify devices in a way that's compatible with the MPIO architecture.

MPIO also supports load balancing of the I/O paths to storage transparently and without administrator intervention. MPIO does this by maintaining an understanding of which paths are active and available based on policies and information that the vendor's DSM provides. If, after receiving an I/O request, MPIO determines that a path is inactive, MPIO can automatically initiate a transparent failover and ensure that paths to storage devices are available.

Microsoft put a lot of effort into MPIO to address a myriad of past concerns and frustrations. MPIO is really a two-part solution, consisting of MPIO drivers provided by Microsoft and DSMs provided by vendors. The result is a common framework for multipath I/O that's independent of the storage vendor. The MPIO approach should make the storage vendor's work easier and substantially reduce Microsoft's support burden for multipath solutions. Ultimately, IT customers will reap the benefits of being able to deploy storage infrastructures with robust support for multipath redundancy and scalability.

Reader Comments

Mr. Cochran: Good article, you simplified things well. I was wondering if you had any documentation or knew or anybody that has had any integration problems with MPIO. Now that the driver has been out for a while I was hoping you had heard something. Any feedback would be greatly appreciated. Thanks, FC_Man

Excellent article! Clear, concise... down to the point. All I needed to know to get me started, and then some more. It has been a while since I've seen an article this good. Seriously!

I'm curious- why would HP, or another vendor, create a DSM to work with MPIO, which is free? This would mean loss of business for their product, which runs in the thousands of dollars.

HP, EMC and other SAN vendors create DSM's to work with MPIO for several reasons: 1) Customers want it. If it's in Windows Server, customers ask their vendors why they don't support it, and as a major vendor, it's rather embarrassing to not support a well-written component like Microsoft MPIO when it's clearly in the customer's best interest. 2) It's more stable. Vendors of SAN's haven't historically rock stars when writing their own solutions for MPIO. It's simply easier to write a DSM which is relatively easy and let Microsoft handle the dirty work - especially for the small/medium business segment which might buy a small SAN but the vendor doesn't want to have to support them. This way the SMB doesn't buy the expesive MPIO solution from the vendor, stays with Microsoft's solution, and that's one less support headache for the SAN vendor. 3) Everyone else is doing it. If you assume that every other vendor's going to build a DSM, you have to conclude that the best way to differentiate yourself is to simply build the BEST DSM and provide the most well supported solution possible for Microsoft MPIO. This is precisely the tact that EMC took and consequently, they were the first to support MPIO and Microsoft's VDS technology.