Skip to main content

Multipathing Support in Windows Server 2008

Windows Server 2008 includes many enhancements for connecting to a Storage Network. One notable feature is inclusion of native multipathing (Microsoft MPIO) inbox. Microsoft MPIO in delivers high availability by establishing multiple sessions/connections from a Windows Server host to an external storage array through iSCSI, Fibre Channel, and SAS (Serial Attached SCSI). Microsoft MPIO use redundant physical path components–adapters, cables, and switches–to create logical "paths" between the server and the storage device. In the event that a device in the path fails, Microsoft MPIO automatically redirects IO to an alternate path for continued application availability. Each NIC (in the case of iSCSI Software Initiator) or HBA (in the case of Fibre Channel, SAS, iSCSI HBA) should be connected through redundant switch infrastructures to provide continued access to storage in the event of a failure in a storage fabric component.
Note: Failover times can vary by storage vendor and can be configured through timers in the Microsoft iSCSI Software Initiator driver and/or the Fibre Channel host bus adapter driver parameter settings. Most storage array vendors will automatically configure timers during installation of their DSM package optimized for their array.
Microsoft MPIO Components
· MPIO Framework - this consists of core multipathing support in the OS as well as configuration utilities. The MPIO framework is an extensible model allowing storage vendors to develop plug ins optimized for their hardware.
· Microsoft DSM - Microsoft provided Device Specific Module - the Microsoft MPIO DSM is provided inbox in Server 2008
Core storage components including MPIO.SYS, Classpnp and Storport are involved in handling of  multipath operations. The Microsoft DSM (MSDSM.SYS) and/or partner provided DSMs handle device-specific operations
Note: Microsoft also supports Microsoft MPIO for Server 2003 and Windows 2000 as a separately installed component redistributed by the storage array vendors or as provided with the e Microsoft iSCSI Software Initiator package (Microsoft iSCSI DSM)
New in Windows Server 2008 is support for ALUA with the Microsoft DSM designed to work with Asymmetric logical unit access (ALUA) as defined in SPC-3 as well as true Active/Active arrays. Asymmetric Logical Unit Access is defined in SPC-3. The following storage device types are supported by MSDSM
  • Explicit ALUA. This is preferred - if INQUIRY response indicates support for both Implicit and Explicit ALUA, MSDSM will disable Implicit ALUA
  • Implicit-only transition storages
  • Traditional Active/Active model
  • Symmetric Logical Unit Access using ALUA semantics
The Microsoft DSM provided as part of the complete solution in Windows Server 2008 includes support for the following policies:
· Failover
This policy represents the simplest form of multipathing to failover from one active path to a failover path in the case of loss of a failure of a device connecting the Windows Server to the storage array.
In this policy, no load balancing is performed. The DSM will specify a primary path and a set of standby paths. The primary path is used for processing device requests. If the primary path fails, one of the standby paths will be used. Any one of the available paths could be used as primary path, and the remaining paths will be used as standby paths.

  • Failback
This policy dedicates I/O to a designated preferred path whenever it is operational. If the preferred path fails, I/O will be directed to an alternate path, but will automatically switch back to the preferred path, with some DSM assistance when it becomes operational again.
  • Round Robin

This policy evenly distributes incoming requests across all available paths.
Round Robin Load balancing configures the DSM to use all available paths for I/O in a balanced, round robin fashion. This is the default policy chosen when the storage controller follows the true Active-Active model and the management application does not explicitly choose a load balancing policy.
  • Round Robin with subset
This policy executes Round robin on all paths on all optimized paths to route IO to a disk/ (LUN). A set of paths are configured as active and a set of paths are configured as standby. I/O is sent in a round robin fashion over the active paths. If all of the active paths fail then one of the standby paths is used. If any of the formerly active paths become available again then the formerly active paths are used and the standby path that was activated becomes a standby path again. The application will specify a set of paths to be use in Round Robin fashion, and a set of standby paths. The DSM will pick the paths from primary paths for processing requests as long as at least one of them is available, DSM will pick a standby path only when all the primary paths fail. Standby paths must be listed in decreasing order of preference (i.e. most preferred path first). If one or more of the primary paths become available, DSM will start using them standby paths in their order of preference. For example, say there are 4 paths – A, B, C, and D. A, B, and C are listed as primary paths and D is standby path. DSM will pick a path from A, B, and C in round robin fashion as long as at least one of them is available. If all three fail, DSM will start using D, the standby path. If A, B, or C become available, DSM will stop using D, and will instead switch to the available paths among A, B, and C.
  • Weighted Path
This policy assigns a weight to each path; the weight indicates the relative priority of a given path. The larger the number the lower the priority. The DSM will choose a path, among the available paths, with least weight.
The Microsoft DSM will persist the Load Balance settings across reboots. When no policy has been set by a management application, the default policy that will be used by MSDSM DSM will be either Round Robin, in the case of non-ALUA support, or Fail Over Only in the case of ALUA support. In this case of Fail Over Only, any one of the available paths could be used as primary path, and the remaining paths will be used as standby paths.
The MSDSM Default Load Balance Policy used is determined by the type of Asymmetric Logical Unit Access
  • ALUA not supported = Failover Only
  • Symmetric LUA = Round-Robin
  • ALUA IMPLICIT = Round-Robin w/ Subset
  • ALUA EXPLICIT = Round-Robin w/Subset
  • ALUA EXPLICIT  &  IMPLICIT = Round-Robin w/Subset
Microsoft MPIO solutions are tested and qualified through the Certified for Windows Logo Program for compatibility and reliability with Windows.
How to add MPIO support in Windows Server 2008
Step 1: Add Microsoft MPIO optional feature
From Server Manager, select “Add Features”
clip_image002
Step 2: Select Multipath IO
clip_image004
and select Next
Step 3: Click Install
clip_image006
Step 4: Allow MS MPIO installation to complete and initialize
clip_image008
Step 5: Click Finish
clip_image010
Configuration and DSM installation
Additional connections through Microsoft MPIO can be configured through the control panel configuration tool or the command line interface, MPClaim.
MPIO configuration can be launched from the control panel (classic view):
clip_image011
MPIO Configuration can also be launched from Administrative Tools
clip_image013
Adding 3rd party Device Specific Modules
Typically, storage arrays which are active/active and SPC3 compliant will also work with the Microsoft MPIO DSM. Many storage array vendors also provide their own DSMs to use with the Microsoft MPIO framework.
These are delivered typically in 3 ways:
1) A self contained installation program which will install the DSM, configure any needed settings on the system including registry timer settings
2) A management suite which will install a Microsoft MPIO DSM as well as other SAN management components on a Windows Server host that will be connecting to the storage array
3) A flat package containing the DSM binary with an inf that can be installed through the MPIO DSM tab in control panel
To install the DSM from the Install tab in the MPIO properties control panel configuration utility.
clip_image014



Popular posts from this blog

HOW TO EDIT THE BCD REGISTRY FILE

The BCD registry file controls which operating system installation starts and how long the boot manager waits before starting Windows. Basically, it’s like the Boot.ini file in earlier versions of Windows. If you need to edit it, the easiest way is to use the Startup And Recovery tool from within Vista. Just follow these steps: 1. Click Start. Right-click Computer, and then click Properties. 2. Click Advanced System Settings. 3. On the Advanced tab, under Startup and Recovery, click Settings. 4. Click the Default Operating System list, and edit other startup settings. Then, click OK. Same as Windows XP, right? But you’re probably not here because you couldn’t find that dialog box. You’re probably here because Windows Vista won’t start. In that case, you shouldn’t even worry about editing the BCD. Just run Startup Repair, and let the tool do what it’s supposed to. If you’re an advanced user, like an IT guy, you might want to edit the BCD file yourself. You can do this

DNS Scavenging.

                        DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.  Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy.  Remember that old test server that you built two years ago that caught fire before it could be used?  Probably not.  DNS still remembers it though.  There are two big issues with DNS scavenging that seem to come up a lot: "I'm hitting this 'scavenge now' button like a snare drum and nothing is happening.  Why?" or "I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying.  What happened?" This post should help us figure out when the first issue will happen and completely avoid the second.  We'll go through how scavenging is setup then I'll give you my best practices.  Scavenging s

AD LDS – Syncronizing AD LDS with Active Directory

First, we will install the AD LDS Instance: 1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard. The Setup Wizard appears. 2. Click Next . The Setup Options dialog box appears. For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future. 3. Select A unique instance . 4. Click Next and the Instance Name dialog box appears. The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in. 5. Enter a unique instance name, for example IDG. 6. Click Next to display the Ports configuration dialog box. 7. Leave ports at their default values unless you have conflicts with the default values. 8. Click N