Showing results for 
Search instead for 
Did you mean: 
Field Notice 70545

UCS/NetApp iSCSI connectivity

I've been working with iSCSI/MPIO for 15 years but I'm new to UCS and some of the configurations is foreign to me and I'm failing to fully understand how HA and failover works here.

So in more of the traditional setup with rack mounted server I would have multiple NICs for storage configured with different IP ranges (vlans) connected to multiple switches, same on the other side of the switch - storage (in this case NetApp) has multiple NICs configured to match server side vlans, this setup with MPIO enabled on windows OS takes care of HA and any failures.

biggest difference between above and UCS is that no matter how many NICs and paths I have there is only one IQN representing Windows server OS

Now, I have UCS configured, service profile created with two paths to boot from storage, biggest difference at this point is TWO IQNs representing blade in UCS, I created LUN on NetApp allowed one of the IQN (primary) to connect to it, boot, installed OS enabled MPIO, now I can allow secondary boot path (second IQN)

all is good from Windows OS perspective it boots file from LUN but here is my concern and what I think I fail to understand.

Within windows OS under iSCSI Target there is only one NetApp controller visible where in my none UCS deployment I can see both netapp controllers, under configuration tab I see primary blade IQN obviously there is no place in windows iscsi initiator for secondary initiator name

So how does this work in case of failure? if Windows OS that is booting from storage LUN cannot see (have no knowledge) in iscsi initiator configuration secondary netapp controller how this should successfully fail?

I want to do netapp controllers software/firmware upgrade and will need to reboot one controller at the time and other controller will takeover. I'm just afraid I will crash those server that are running of UCS? what am I missing here?

Content for Community-Ad