GAPTHEGURU

Geek with special skills

How to verify MPIO setup on the iSCSI Initiator

To verify all the disks have two paths, I opened the iSCSI Initiator control panel applet, and checked the device path:

clip_image003

As you can see each disk listed in the Devices pane had 2 paths associated with it, as well as the MPIO policy. You can change the policy by click the dropdown box on the Device details page.

There is also a report you can generate by:

  • Open Microsoft iSCSI Initiator, and then click the Configuration tab.
  • Click Report.
  • Enter the file name, and then click Save.

My report file looks like:

iSCSI Initiator Report
=======================
List of Discovered Targets, Sessions and devices
==================================================
Target #0
========
Target name = iqn.1991-05.com.microsoft:svr1-target
Session Details
===============
Session #1 <= first session to the target
===========
Number of Connections = 1
Connection #1
==============
Target Address = 10.10.0.51
Target Port = 3260
#0. Disk 2
========
Address:Port 3: Bus 0: Target 0: LUN 0
#1. Disk 4
========
Address:Port 3: Bus 0: Target 0: LUN 1
#2. Disk 5
========
Address:Port 3: Bus 0: Target 0: LUN 2
Session #2 <= second session to the target
===========
Number of Connections = 1
Connection #1
==============
Target Address = 10.10.0.51
Target Port = 3260
#0. Disk 2
========
Address:Port 3: Bus 0: Target 1: LUN 0
#1. Disk 4
========
Address:Port 3: Bus 0: Target 1: LUN 1
#2. Disk 5
========
Address:Port 3: Bus 0: Target 1: LUN 2

How to verify MPIO setup on the iSCSI Target

To view the session/connection information on the Target server, you need to use WMI. The easiest way to execute WMI queries is the WMIC.exe in the commandline window.

C:\>wmic /namespace:\\root\wmi Path WT_HOST where (hostname = “T2”) get /format:list

Where T2 is my target object name.

A sample output is listed below with minor formatting changes. Comments have been added to help understand the output and a prefixed with “<=”:

instance of WT_Host
{
    CHAPSecret = "";
    CHAPUserName = "";
    Description = "";
    Enable = TRUE;
    EnableCHAP = FALSE;
    EnableReverseCHAP = FALSE;
    EnforceIdleTimeoutDetection = TRUE;
    HostName = "T2";
    LastLogIn = "20110502094448.082000-420";
    NumRecvBuffers = 10;
    ResourceGroup = "";
    ResourceName = "";
    ResourceState = -1;
    ReverseCHAPSecret = "";
    ReverseCHAPUserName = "";
    Sessions = {
instance of WT_Session    <= First session information from initiator 10.10.2.77
{
    Connections = {
instance of WT_Connection    <= First connection information from initiator 10.10.2.77, since the iSCSI Target supports only one connection per session, you will see each session contains one connection.
{
    CID = 1;
    DataDigestEnabled = FALSE;
    HeaderDigestEnabled = FALSE;
    InitiatorIPAddress = "10.10.2.77";
    InitiatorPort = 63042;
    TargetIPAddress = "10.10.2.73";
    TargetPort = 3260;
    TSIH = 5;
}};
    HostName = "T2";
    InitiatorIQN = "iqn.1991-05.com.microsoft:svr.contoso.com";
    ISID = "1100434440256";
    SessionType = 1;
    TSIH = 5;
}, 
instance of WT_Session    <=  Second session information from initiator 10.10.2.77 (multiple sessions from the same initiator as above
{
    Connections = {
instance of WT_Connection
{
    CID = 1;
    DataDigestEnabled = FALSE;
    HeaderDigestEnabled = FALSE;
    InitiatorIPAddress = "10.10.2.77";
    InitiatorPort = 63043;
    TargetIPAddress = "10.10.2.73";
    TargetPort = 3260;
    TSIH = 6;
}};
    HostName = "T2";
    InitiatorIQN = "iqn.1991-05.com.microsoft:svr.contoso.com";
    ISID = "3299457695808";
    SessionType = 1;
    TSIH = 6;
}, 
instance of WT_Session    <= First session information from initiator 10.10.2.69
{
    Connections = {
instance of WT_Connection
{
    CID = 1;
    DataDigestEnabled = FALSE;
    HeaderDigestEnabled = FALSE;
    InitiatorIPAddress = "10.10.2.69";
    InitiatorPort = 60063;
    TargetIPAddress = "10.10.2.73";
    TargetPort = 3260;
    TSIH = 10;
}};
    HostName = "T2";
    InitiatorIQN = "iqn.1991-05.com.microsoft:svr2.contoso.com";
    ISID = "2199946068032";
    SessionType = 1;
    TSIH = 10;
}, 
instance of WT_Session    <= Second session information from initiator 10.10.2.69

{
    Connections = {
instance of WT_Connection
{
    CID = 1;
    DataDigestEnabled = FALSE;
    HeaderDigestEnabled = FALSE;
    InitiatorIPAddress = "10.10.2.69";
    InitiatorPort = 60062;
    TargetIPAddress = "10.10.2.73";
    TargetPort = 3260;
    TSIH = 11;
}};
    HostName = "T2";
    InitiatorIQN = "iqn.1991-05.com.microsoft:svr2.contoso.com";
    ISID = "922812480";
    SessionType = 1;
    TSIH = 11;
}};
    Status = 1;
    TargetFirstBurstLength = 65536;
    TargetIQN = "iqn.1991-05.com.microsoft:cluster-yan03-t2-target";
    TargetMaxBurstLength = 262144;
    TargetMaxRecvDataSegmentLength = 65536;
};

As you can see in the above session information, each node (as the iSCSI initiator) has connected to the target with 2 sessions. You may have also noticed both sessions are using the same network path. This is because, when you configure iSCSI initiator, by default, it will pick the connection path for you. In the case of one path failure, another path will be used for the session reconnection. This configuration is easy to setup, and you don’t need to worry about the IP address assignment. It is good for failover MPIO policy.

image

If you want to use specific network paths, or want to use both network paths, you will need to specify the settings when you connect the initiators. You can do this by going to the “Advanced” setting page.

clip_image002

This configuration allows you to use specific IPs, and can utilize multiple paths at the same time with different MPIO load balancing policies.

A word of caution on using the specific IP for Initiator and Target, if you are using DHCP in the environment, and if the IP address changes after the reboot, the initiator may not be able to reconnect. From the initiator UI, you will see the initiator is trying to “Reconnect” to the target after reboot. You will need to reconfigure the connection to get it out of this state:

  1. Remove the iSCSI Target Portal
  2. Add the iSCSI Target Portal back
  3. Connect to the discovered iSCSI Targets
Advertisements

05/10/2012 Posted by | Clustering, iSCSI, MPIO | Leave a comment

Configuring iSCSI MPIO on Windows Server 2008 R2

I have recently gone through the process of wiping out one of my lab environment and rebuilding it from scratch on Windows Server 2008 R2 Enterprise.  During this process, I recorded the steps I used to configure MPIO with the iSCSI initiator in R2.  Just to make life more complex, my servers only have 2 NICs, so I am balancing the host traffic, virtual machine traffic, and MPIO across those two NIC devices.  Is this supported?  I seriously doubt it.  🙂  In the real world you would separate out iSCSI traffic on dedicated NICs, cables, and separate switch paths.  The following step-by-step process should be relatively the same though.

Foundation

The workflow I am following assumes that when starting out one NIC is configured for host traffic and the other for a VM network.  On the WSS the secondary NIC was already configured not to register in DNS.  Also, since I am using WSS and the built-in iSCSI Target I don’t have to configure a DSM for the storage device.  If your configuration is different than that, you may have to ignore or add to a few parts of the below instructions.  Sorry about that.  I can only document what I have available for testing…

First I just want to show a screenshot of the iSCSI target on our Windows Storage Server, to indicate that it does have two IPs.  Once again, I am cheating the system here.  These are not dedicated TOE adapters for iSCSI on a separate network.  This is a poor man’s environment with 1 VLAN and minimal network hardware.  My highly available environment is anything but!  To view this information on your own WSS, right-click on the words “Microsoft iSCSI Software Target” and click Properties.

image

Enable the MPIO Feature on the initiating servers

Next I needed to enable MPIO on the servers making the iSCSI connections.  MPIO is a Feature in Server 2008 R2 listed as Multipath I/O.  Adding the Feature did not require a reboot on any of my servers.

image

Configuring MPIO to work with iSCSI was simple.  Click Start and type “MPIO”, launch the control panel applet, and you should see the window below.  Click on the Discover Multi-Paths tab, check the box for “Add support for iSCSI devices”, and click Add.  You should immediately be prompted to reboot.  This was consistent across 4 servers where I followed this process.

image

image

After rebooting, if you open the MPIO Control Panel applet again, you should see the iSCSI bus listed as a device.  Note on my servers, the Discover Multi-Paths page becomes grayed out.

image image

Check the IP of the existing connection path

Now click Start and type “iSCSI”.  Launch the iSCSI Initiator applet.  Add your iSNS server or Target portal.  There is plenty of documentation on how to do this on TechNet if you need assistance. I want to stay focused on the MPIO configuration.

Once you are connected to the target, click the button labeled “Devices…”.  You should see each of the volumes you have connected listed in the top pane.  Select a Disk and click the MPIO button.  In the Device Details pane you should see information on the current path and session.  If you click the Details button, you can verify the local and remote IPs the current connection is using.  It should be the IPs that resolve from the hostnames of each server.  See my remedial diagram below.

I recommend taking note of this IP, to make life easier later on!

image

So everything is setup for MPIO but you are only using a single path and that’s not really going to accomplish much now is it?  Since I only have 2 NICs in my test server I need my host to share the second NIC with the VM network.  This is not ideal but again I am using what I have and this is only a test box.

Setting a second IP on my hosts

In R2 the host does not communicate by default on a NIC where a virtual network is assigned.  To change this, open the Hyper-V console and click “Virtual Network Manager…”.  Check the box “Allow management operating system to share this network adapter”.

image

This will create a third device in the network console (to get there click Start, type “ncpa.cpl”, and launch the applet).  You should see the name of the new device matches your Virtual Network name.  In my case Local Area Connection 4 has a device name “External1”.  Right click on the connection and then click Properties.  Select “Internet Protocal Version 4 (TCP/IPv4)” and click the Properties button.  Configure your address and subnet but not the gateway as it should already be assigned on the first adapter.  You also shouldn’t need to set the DNS addresses in the new adapter.  You will however, want to click the “Advanced…” button followed by the DNS tab and uncheck the box next to “Register this connection’s address in DNS”.  This really should be the job of your primary adapter, no need to have multiple addresses for the same hostname registering and causing confusion unless you have a unique demand for it.

image

Add a second path

Back in the iSCSI Initiator Applet, click the Connect button.  I know you already have a connection.  In this step we are adding an additional connection to the Target to provide a second path.

In the subsequent dialogue make sure you check the box next to “Enable multi-path” and then click the Advanced… button.  In the Advanced Settings dialogue you will need to choose the IP for your second path.  In the drop-down menu next to “Local adapter:” select Microsoft iSCSI Initiator”.  In the drop-down next to “Initiator IP:” select the IP on your local server you would like the Initiator to use when making a connection for the secondary path.  In the third drop-down, next to “Target portal IP:” select the IP of the iSCSI Target server you would like to connect to.  This should be the opposite IP of the session we observed a few steps back when I mentioned you should take note of the IP.

image

Check your work

Just one more step.  Let’s verify that you now have 2 connections available for each disk, that they are using separate paths, and have the opportunity to choose the types of load balancing available.  Once you have hit OK out of each of the open dialogues from the step above, click on the Devices… button again and check out the top pane.  On each of my servers I see each disk listed twice, once per Target 0 and once per Target 1, as seen below.  If you follow my remedial diagrams one more time and select a disk, then the MPIO button, you should now see two paths.  Select the first path and click the Details button.  It should be using the local and remote IPs we took note of earlier.  Click OK.  Now select the second path and then the Details… button.  You should see it using the other adapter’s IP on BOTH the local and remote hosts.

image

05/10/2012 Posted by | Clustering, iSCSI, MPIO, Windows Server | , , | Leave a comment

   

%d bloggers like this: