CV / E = CM connections per member.

To clarify, the DSM makes session connections based on the number of members the volume is spread across times the # of NICs but we cap the session limit at 6.

E * N = CV per node OR

3 * 2 = 6 connections per node * 16 nodes = 96 connections

In this case each NIC would have 3 connections to the volume, one to each member.

In a two member pool the equation would look as follows:

2 * 2 = 4 connections per node yielding 2 connections per NIC to the volume.

The reason I chose 1 MPIO connection in my equation is the fact that I want redundancy on the network card level above MPIO.

PR. Persistent reservation per volume: 96
E. Volume is spread over members: 3
N. NIC’s per Hyper-V node: 2
S. Hyper-V Nodes: 16
CN. Connections per volume

PR / S = connections per node

96 / 16 = 6 connections per volume

CV / E =

6 / 3 = 2 connections per volume per node (MPIO)

Every node has 2 NIC’s so this means 1 connection per NIC.

If you take the default for the MPIO settings which is 2 then you will end up with 192 PR’s per volume. The 3 in my equastion is the spread over the members.

3 * N * M * S = ???

3 * 2 * 2 * 16 = 192

This would mean the CSV would fail. Or am I wrong. Please clarify how the PR’s are calculated in relation to number of NIC’s and MPIO.

First a slight correction, the max members per Group is 16 (8 per Pool). Now to the meat of the topic… There is some confusion on how the EQL DSM works. You’re equation is not entirely correct. You came about the maximum number of connections correctly but we make our session connection differently then what you’ve described here. The DSM defaults to 2 connections per member, 6 connections per volume and Least Queue Depth policy. This results in your 96 connections (with 5.x FW) per volume. The DSM sits on top of the Windows MPIO driver stack. We’ve just added more intelligence so that we know where the actual data is hosted and on which array hosts it.

The architecture of the DSM work as follows: we distribute the sessions over the NICs so each NIC would have a connection to each member hosting the volume. This allows us to quickly access data through any session depending on the array that hosts the data at the time of the request. This process is much more efficient then using the standard Windows MPIO driver.

For example if you’re using the standard Windows driver you first have to manually make each NIC session connection to the volume through the initiator, the DSM does this for you automatically. Next if your data request is accessing data across path 1 and that path is connected to array 2 then the data path goes through the switch – to array 1 – back through the switch to array 2 – retrieves the data then routes back through array 1 – to the host. Where the DSM will auto recognize that the data is located on array 2 and issue an iSCSI redirect through the appropriate session to connect directly to array 2 to retrieve the data.

It’s always a good idea to use MPIO where possible for performance and redundancy but you see the intelligence of the EQL DSM also adds efficiency and added performance benefits over the standard Windows MPIO driver.