Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

January 12, 2004 12:00 AM

Why Windows Administrators Should Care About MPIO

Windows IT Pro
InstantDoc ID #41471
Rating: (4)

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.

Related Content:

ARTICLE TOOLS

Comments
  • Kurt
    6 years ago
    Jan 16, 2006

    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.

  • Anonymous User
    7 years ago
    Jun 06, 2005

    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.

  • Anonymous User
    7 years ago
    May 17, 2005

    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!

  • John
    7 years ago
    Jan 27, 2005

    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

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.