Temporary Nimble iSCSI cabling Config

[CadenLange]

Hello

We are undergoing a major network refresh which will result in a big port reduction whilst the networking is being worked on. At the moment our Nimble AF40 has four iSCSI connections (tg3a & b on both controllers) to two different iSCSI subnets. For the duration of the network reconfiguration we will only have 1 iSCSI connection available on each subnet for the Nimble.

I want to unplug 1 iSCSI connection from each controller so that controller A has 1 connection to iSCSI subnet 1 (tg3a) and controller B has 1 connection to iSCSI subnet 2 (tg3b). I think this will then allow the Nimble to failover if a Nimble controller or path fails on iSCSI subnet 1?

Is it OK for the Nimble to run (in for a temporary time) with only tg3a connected on controller A (tg3b will be unplugged) and tg3b connected on controller B (tg3a will be unplugged) ?

thanks

[support_s]

System recommended content:

1. HPE 3PAR StoreServ iSCSI Best Practices Configuring iSCSI with DCB

2. HPE Nimble Storage HF-Series - Parts Support Guide | Controller

Please click on "Thumbs Up/Kudo" icon to give a "Kudo".

Thank you for being a HPE valuable community member.

[Mahesh202]

Hi CadenLange
Thank you for coming to HPE Community Forums

If controller A has 1 connection to iSCSI subnet 1 (tg3a) and controller B has 1 connection to iSCSI subnet 2 (tg3b).
then the status would be
Name Link
Status
A/B
Tg3a Up/Down
Tg3b down/Up

The above will work with data flow but give you an error while failover. Please perform a software --precheck to check if the array can failover

On HPE Nimble Storage arrays that have iSCSI enabled for use, at least one subnet must be configured to allow iSCSI data. The array configuration must have one physical interface per iSCSI target IP address

The disadvantage of having a single interface per data subnet Increases the chances of failover caused by infrastructure events such as switch
maintenance (reboots) or similar link failures.

Hope this helps.!!

Regards
Mahesh

[CadenLange]

Hi Mahesh

Thanks for the prompt reply - can I just ask you to elaborate a little more with your thoughts. Are you saying that things will work fine so long as the controllers don't need to failover - at which time it's a little unknown what will happen?

Or that controller failover will succeed it will just give an error?

I've not run a 'software --precheck' command before. Is it just    $software --precheck    from the command line? What would I expect to see if the array can't failover? Is it something obvious like "This array cannot failover to the standby controller!"

Is there a minimum OS version that the software --precheck requires to run?

many thanks

[Mahesh202]

Hi CadenLange

It will work fine, I mean you will be able to access the data but you will not be able to failover the controllers

Software -- Precheck Will give you the status of whether the array has the ability to failover or not.
This command is non-disruptive and you can run it on any Nimble OS

When you test the network connections, I suggest you run software --precheck to check the failover ability

Hope this helps.!!

Regards
Mahesh.

[CadenLange]

Hi Mahesh

Many thanks again - I will run that command as suggested

Sorry - but just one more point of clarification please.  I assume the inability to failover the controllers doesn't just relate to making the standby controller active from the GUI?   When you say the controller won't fail over you also mean that if the single iSCSI path running on the active controller were to fail (eg Conytoller A or the switch carrying iSCSI subnet 1 dies)  the standby controller won't take over and there will be a service outage?

thanks

[Sheldon Smith]

Correct. While you are doing the network refresh you will have a Single Point of Failure.

1. (Your current planned temporary configuration)
Ctrlr A tg3a iSCSI subnet 1
Ctrlr B tg3b iSCSI subnet 2
One subnet active. If subnet is interrupted, the other controller will not be able to failover. Outage.

2.
Ctrlr A tg3a iSCSI subnet 1
Ctrlr B tg3b iSCSI subnet 1
One subnet active. If port link is interrupted, the other controller should be able to failover. Do the 'software -precheck' anyway.
If the switch carrying the subnet dies, outage.

Either way only one iSCSI subnet is active. Either way there are still conditions that will cause an outage.
With "2", there should be one less issue that woulc cause an outage. 

[CadenLange]

Thank you for clarifying that Sheldon

I follow the benefits of option 2 you've suggested, but, as you say, that would mean they would both need to be plugged into the same physical switch (that's unfortunately due to our temporary network reconfiguration work). So whereas that would allow us to survive a controller failure, it would give us a single point of failure in the switch - so moving the problem rather than resolving it.

I was hoping we could get the best of both worlds by having one port of each controller plugged into each of the different iSCSI switches. But i know understand that won't work from a Nimble failover perspective - that's fine, I just need to communicate the risks back to the business.

But, you're right, if the Nimble controllers won't failover anyway then we may as well cable in a manner that would just cuase an outage if the switch fails.

kind regards

[Sheldon Smith · Accepted solution]

With your temporary situation, you can't resolve it.

With your idea, you have either iSCSI subnet 1 working or iSCSI subnet 2 working. Not both. With only one connection from each controller, you can't have both iSCSI subnets working.