iSCSI trying to be too clever

[gshaw]

Just setting up an iSCSI LUN to dump WSUS updates onto with our Storevault S500, got a dedicated HP Gigabit switch for the traffic and separate NIC in the servers when I'm making iSCSI connections. Made separate 172.16 addresses for the SAN and server NICs, so far so good.

 

Make the iSCSI connection, logon to target, bind volume no trouble. Then as a test I pulled out the network cable... yet everything still works

 

Seems that because the Storevault has SAN and NAS (and thus has a connection to the main network) the iSCSI initiator finds the other route to the SAN and then sends the traffic through that if the primary connection goes. Thing is once it's failed over I can't see a way to change it back unless I logoff the target and logon again.

 

Checked this with network monitor and I can see the iSCSI data going over the main network IP if the 172.16 NIC goes - by default it goes over the correct connection.

 

Is there a way to exclude certain NICs from iSCSI traffic as really I don't want that extra overhead on the network if the iSCSI NIC did do bang...

[webman]

I would recommend either a totally separate switch or VLANs on your current switch if possible.

[gshaw]

That's what we have...

 

StoreVault

l

HP ProCurve 2810 (dedicated for iSCSI)

l

l

dedicated NIC on each server for iSCSI as required

 

The StoreVault has...

- One NIC for the iSCSI into the 2810 (as above)

- One NIC for management \ Windows shares into the core network switch

 

Unless there's no need to have the 2nd NIC with an address on the main network but then surely the Shared folder functionality won't work as it won't be able to talk to the domain at that point...

[webman]

Aahh okay, I get it now. I'm not familiar with the StoreVault so can't think of anything to suggest on that device itself, sorry

[gshaw]

Seems to be more the iSCSI initiator doing it, if I go onto Targets > Details > Properties it shows 2 "Associated Network Portal Groups" - one for each NIC.

 

Normally in session properties there's 1 connection and 1 session (the 172.16 iSCSI NIC).

 

When I pull that cable out it plucks the other NIC out the air and then decides to reconnect with the 2nd connection... great for failover but without knowing that's happened the traffic goes over the main network

[torledo]

I would suggest you contact storevault tech support to either get an understanding of this behaviour and best practice for configuring dedicated iscsi and NAs interfaces and the associated configuration of the iscsi software initiator your using.

 

Might get this resolved a lot quicker that way.

[gshaw]

Sadly the support site is as much use as a chocolate teapot, support was purchased from Evesham but they went belly up so not sure if we ever got it supplied. Without the (rather pricey) support contract you can't get anything from the site.

 

As far as I can see it's a feature of the Microsoft Initiator that does multiple paths and failover trying to find that 2nd connection... got a feeling there must be a way to exclude paths but can't see it at the moment

[plexer]

How to install, configure and use Microsoft's iSCSI initiator : TechGuides : Enterprise Servers & Storage : ZDNet Asia

 

Have you enabled multi path on that target?

 

Ben

[gshaw]

Funny enough I'd just hit that link earlier when looking through the web for a solution! Multi path box left unticked in the setup.

 

Just attached where it lists the 192 address, IPs are usually full but blanked out for obvious reasons.

 

When the cable gets unplugged the iSCSI reconnects and where it's usually Target Portal Group: 1 it then becomes 2 and connects via the main network NIC...

 

(see attached pics)

targetproperties.bmp