RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.
↑ Back to the top
Consider the following scenario.� You have a Windows Server 2003 system running the Microsoft iSCSI Initiator.� You are using Microsoft�MPIO to connect to multipath iSCSI LUNs, and you are using the Microsoft Device Specific Module (DSM) for MPIO.� You are using the Round Robin MPIO load balance policy.� Your iSCSI sessions (paths) are set up as follows:
NIC 1 on Subnet 1 to Target Portal on Subnet 1 (active)
NIC 1 on Subnet 1 to Target Portal on Subnet 2 (active)
NIC 2 on Subnet 2 to Target Portal on Subnet�2 (active)
In this configuration, you may see degraded performance while reading from or writing to the iSCSI LUNs.
↑ Back to the top
For optimal performance, all iSCSI NICs should have an equal number of active iSCSI sessions while using the Round Robin load balance policy.� The configuration described in the Symptom section does not follow this practice, as there are two sessions on one NIC, and one session on the other NIC.
When there are more active sessions across a particular network interface than the rest of the interfaces in the system, the cost of transmitting data down a path on said interface is greater than the cost of transmitting over a path on one of the other interfaces in the system.� However, the network interface with more active sessions receives the highest proportion of data to transmit with the Round Robin load balance policy because it has the highest number of active sessions.
In high-throughput scenarios, this can have negative performance implications.� This is especially true when the application generating the I/O has a low limit on the maximum number of outstanding I/O requests, which can create a scenario where all�or most outstanding requests are on paths located on the NIC with a greater number of active sessions.� The queues for paths located on other NICs in the system (with fewer active sessions) may drain completely, and thus the other NICs may sit idle for a portion of the time waiting for work, decreasing performance.
↑ Back to the top
If you are observing suboptimal iSCSI performance, and your iSCSI infrastructure is configured as described in the Symptom section, ensure each iSCSI NIC has an equal number of active iSCSI sessions to ensure optimal performance.
Considering the scenario described in the Symptom section, redundancy and performance can both be increased by configuring the iSCSI sessions as follows:
NIC 1 on Subnet 1 to Target Portal on Subnet 1 (active)
NIC 1 on Subnet 1 to Target Portal on Subnet 2 (active)
NIC 2 on Subnet 2 to Target Portal on Subnet�1 (active)
NIC 2 on Subnet 2 to Target Portal on Subnet�2 (active)
Alternatively, the configuration could be simplified as follows to allow for increased performance at the cost of redundancy:
NIC 1 on Subnet 1 to Target Portal on Subnet 1 (active)
NIC 2 on Subnet 2 to Target Portal on Subnet�2 (active)
Finally, if the iSCSI infrastructure must be configured as described in the Symptom section (which is not recommended), the Round Robin with Subset MPIO load balance policy should be used, and one of the sessions on NIC 1 should be set to standby:
NIC 1 on Subnet 1 to Target Portal on Subnet 1 (active)
NIC 1 on Subnet 1 to Target Portal on Subnet 2 (standby)
NIC 2 on Subnet 2 to Target Portal on Subnet�2 (active)
This will ensure both NICs have one active session.� Note the active session on NIC 1 is connecting to the target portal located on the same subnet.� This will prevent any potential performance costs associated with the traffic crossing subnets.
↑ Back to the top
Similar performance degradation may be observed if you are using an equal number of sessions on all NICs, but certain paths have significantly increased I/O latency or significantly lower network link bandwidth.� If your environment is configured to use an equal number of active sessions across NICs but you are still observing suboptimal throughput, the network infrastructure should be investigated to determine the source of the increased I/O latency or decreased network link bandwidth.
↑ Back to the top