DSM Load Balance Options???

[tomb_2]

So I see in the documentation that you should be able to use Fail Over Only (which I gather is what Vendor Specific is...) and Round Robin. Whenever I try to change the LB Policy to Round Robin, however, I get a message box that says:

Set New MPIO Policy
The request is not supported.

This is with the 8.5 and 9.0 version of the DSM. I'll admit that I am new to HP SANs (just migrated from another Vendors' SAN solution) but I don't believe I am missing anything. Should I be able to do this?

It also appears you cannot enable the iSCSI HBA function of the ProLiant multifunction NICs with the HP solution. Could anyone verify that is true for me?

Thanks!

[Fred Blum · Accepted solution]

Hi,

I struggled with this also but have finally gotten it right with DSM MPIO 9.

Problem was that I was testing and experimenting with different settings and maybe not always cleaning up behind me, teamed nics, ALB (=TLB), flow control and package size, then MPIO, and DSM MPIO 8.5 and DSM MPIO 9.

For W2008 R2 Failover cluster service I need MPIO, as teamed nics is not supported per the Validate Cluster Wizard so I stuck with that and a clean install.

I configured two NICs for the SAN in Network Config, I only enabled IP4 and HP NC config components. Set different fixed IP adresses within the same subnet in IP4, named them iSCSI NIC1 and iSCSI NIC2. In HP Network Configurator I opened the properties of these NICs, clicked iSCSI device, leaving the IP adress empty. Optionally I set Jumbo Package size and Flow Control as I have set them in my SAN and switch also. Closed HP NC.

Installed MS MPIO feature. Installed the HP DSM MPIO Windows software solution.

In iSCSI initiator, TAB portal discovery, NEW, I entered the SAN Virtual IP adress, clicked advanced, adapter iSCSI initiator, source iSCSI NIC1 IP adress. Apply. Did it again now for iSCSI NIC2.

Went to first TAB saw my volumes, clicked connect, set add to favorites and MPIO, clicked Advanced. Again adapter iSCSI initiator, source iSCSI NIC1 IP adress, portal SAN VIP adress, closed advanced, clicked connect.
Click connect again to the same volume, enable remember and MPIO, advanced now with the iSCSI NIC2 adress, apply, connect.

Checked favorites tab to see if the two different NIC originators to the same volume are remembered when rebooting.
Did not touch any other setting, MCS and DSM MPIO do not work together.

I configured the disks and checked if everything was working. Went back to iSCSI initiator, first Tab, clicked device, MPIO, changed vendor specific to round robin. Apply. No more error messages!

[tomb_2]

I appreciate the detailed reply! I have done exactly as you did except for one step.

"In HP Network Configurator I opened the properties of these NICs, clicked iSCSI device, leaving the IP adress empty."

Maybe I don't understand how the multifunction NICs are configured. I assumed that they were either a regular NIC, or you checked the iSCSI device box and gave it an address to use it as an HBA. The way I was looking at it was that just checking the box wouldn't really do anything. Is that not correct? Perhaps that's my problem.

I have a server that is connecting to our old SAN and the new HP SAN. We are experimenting with using the Microsoft DSM. Maybe that will be easier to get configured the way we would like.

[tomb_2]

Just thought of something else. Would the SAN nodes play any part in this? We are still running 8.5 on the SAN. I am still working on getting all the servers with the DSM on them upgraded so I haven't done the SAN yet.

[Fred Blum]

"Maybe I don't understand how the multifunction NICs are configured. I assumed that they were either a regular NIC, or you checked the iSCSI device box and gave it an address to use it as an HBA. The way I was looking at it was that just checking the box wouldn't really do anything. Is that not correct? Perhaps that's my problem."

I found by trial and error that when enabling the iSCSI device setting (iSCSI accelerator) and an IP adress in HP NCU that it caused errors. Leaving it empty as the IP adress has already been entered in Windows Network components does not cause errors. If the HP iSCSI accelerator really works? That would be a matter of IOMeter/SQLIO testing with and without enabling the iSCSI device setting.

[Fred Blum]

"Just thought of something else. Would the SAN nodes play any part in this? We are still running 8.5 on the SAN. I am still working on getting all the servers with the DSM on them upgraded so I haven't done the SAN yet."

There is a HP warning against running mixed modes/different versions. Furthermore the MPIO load balancing round robin active/active is as I read a SANiQ 9 feature as it was still fail-over Active/passive in 8.5. So yes it contributes to errors.

[Fred Blum]

"The way I was looking at it was that just checking the box wouldn't really do anything. Is that not correct? Perhaps that's my problem."

It offloads TCP overhead on TCP connections, reducing CPU utilization.

http://h10032.www1.hp.com/ctg/Manual/c00577553.pdf

step 1 Select an NIC
step 2 enable iSCSI device setting

Optional steps
MAC adrass
IP Adress

[tomb_2]

"There is a HP warning against running mixed modes/different versions. Furthermore the MPIO load balancing round robin active/active is as I read a SANiQ 9 feature as it was still fail-over Active/passive in 8.5. So yes it contributes to errors."

Yeah, I can see about running different versions, but it will take me a while to get the DSM updated on all our servers so there's no way to avoid it.

I guess since the round robin setup was detailed in the DSM 9 doc I figured that was all you needed.

"It offloads TCP overhead on TCP connections, reducing CPU utilization.

http://h10032.www1.hp.com/ctg/Manual/c00577553.pdf

step 1 Select an NIC
step 2 enable iSCSI device setting

Optional steps
MAC adrass
IP Adress"

Thanks. I had read through that document.It still wasn't clear to me about the iSCSI configuration. They list configuring an address as one of the steps. If the doc had gone into a little more detail, or was written as clearly as you did, that would have gone along way in preventing confusion.