broadcom/qlogic npar isoe and MPIO policy on Windows 2012R2

Are you using HIT/Microsoft MPIO DSM?

Are you using single-port 10 GB arrays? 

If so, connections can default to 1 per member, and this can be modified in the MPIO DSM config on the Windows host.

Also, are you approaching the group/pool limitations for iscsi connection count? If so, connections could potentially be automatically scaled down - to allow other potentially at-risk volumes to remain online.

Hi,

Yes, HIT KIT version 4.9 is installed. 

There are 2 x10GbE -eth0&1 on 6210 and both are active. There is only 1 member in the group and couple of hosts (3 servers) are connecting to the array. 

MPIO connection settings are default on HIT KIT which are; max sessions per entire volume 6 , max sessions per volume slice 2

I'll go through the documents to see if I miss anything before simulating network/nic failure. I'll post my findings as well.

thanks,

Hi Michael,

Each CNA on the server is configured like 

• partition 0 ; iscsi enabled, ethernet and fcoe disabled
• partition 1; ethernet enabled, iscsi and fcoe disabled
• partition 2 and 3 all disabled

So I dont use nic teaming for partiton 0 and as this partition is listed as storage hba can only be configured through BASP/Qlogic Control Suite. So I've just enabled jumbo frame (9600 as recommended) and assigned ip address from the storage network.

Partition 1 however is configured with Microsoft Teaming (2012r2 builtin) with dynamic + switch independent mode for LAN/Server ( non-storage) traffic. 

On the hit kit, I've already excluded all other subnet as you mentioned.

"ensure that the Server's SAN interfaces are appropriately included in the MPIO DSM configuration."  I'm not quite sure if you are asking this, storage subnet is already included on Dell ASM/HIT kit and both partition 0 interfaces are in the same subnet. Please let me know if you need more details.

Thanks,

If after making those changes, you're still having issues, I'd recommend that you open a Support case.  Best of luck.

Small footnote about not noticing a performance difference.. This is especially true since you are partitioning your NIC cards. For best iSCSI performance, the SAN should be on its own subnet, with dedicated switches and NICs.  

Right now your environment is small should it grow much larger over time, this could become more of an issue. 

 Don 

Hi Don,

" A cable or switch failure will not bring down your volume.   If the load goes up another connection will be established. " 

Thanks for details that you provided however I've noticed losing active path actually causes operating system lost disk/lun connection as the second path never reestablishes/reconnects.

The whole idea using NIC partition and enabling isoe was to make sure DCB is configured all the way through (storage-switches-server). Based on my research the easiest way to configure DCB on the operating system (windows 2012r2) is to let CNA deal with it through enabling isoe.

 Unfortunately I've been told;

1. this is not very common setup even though is published in one of the best practice guide
2. having 2 (isoe adapter) initiator adapter accessing to same group ip (discover portal on MS initiator) somehow is not working well with EQL MPIO. 

As you mentioned, EQL MPIO will not bring much difference in terms of performance so I'll try with MS native MPIO to see if both paths are active and survive during the network/switch outage.

Thanks,

Hello, 

 Re: DCB.  I think there's some confusion here.  DCB is not a suggested or best practice configuration. If you are in a DCB environment the array will properly operate.  It's more expensive, more complicated to implement but in very large scale environments, like a Data Center it offers priority handling of iSCSI traffic.  Potentially at the cost of all other traffic.  As there are only two classes, lossless and lossy.    These are among the reasons support does not often get calls where DCB is being used. 

 In smaller environments using dedicated NICs and switches for iSCSI means that iSCSI traffic is prioritized and the other switches can be configured to properly handle other traffic.  I.e. VoIP can have its own priority level set.  

 The Broadcom firmware should be updated to current version, along with the drivers.  

  I strongly suggest you open a support case.  They can review the configuration and possibly determine why failover isn't working properly.   This should work fine regardess of DCB, etc..  As it occurs at the physical layer level. 

 Regards,

Don