This post is more than 5 years old
3 Posts
0
96858
February 3rd, 2016 20:00
SC4020 Multipathing help
Hi All,
Just recently setup a new SC4020 compellent and R730xd server. This will be part of a bigger network but at the moment I'm testing failover and redundancy and just trying to get my head around Virtual Ports and MP.
Current test environment comprises of a Compellent SAN, 2 Fibre Switches, Ethernet Switch and 1 x hypervisor. My cabling is identical to this minus second hypervisor (hopefully photo posts okay) - Page 39 of the Owners Manual "Two iSCSI networks with Dual 2 port storage controllers"
I wanted to verify our environment just to ensure I've correctly set it up. I have simulated a controller restart and switch failure and have successfully kept a datastore online which I am happy about, however there is some behaviour I am experiencing with the iSCSI mappings that I don't feel is consistent with the intended design.
ESXi 6.0 Server with 25GB iSCSI volume mapped in Storage Centre
iSCSI Initiators in vSphere: 10.1.1.4:3260 and 10.1.1.5:3260
Fault Domain 1 Controller IP: 10.1.1.4
Fault Domain 2 Controller IP: 10.1.1.5
VMKernel1: 10.1.1.2 (mapped to vmnic0)
VMKernel2: 10.1.1.3 (mapped to vmnic1)
-
We have 1 x 25GB iSCSI data volume mapped to a ESXi hypervisor. ESXi Hypervisor has 2 x NICS configured with 2 x VMkernel adapters and appropriate binding and iSCSI settings connected (as per VMware Best Practices). Physical cabling is identical to above.
-
iSCSI target set to 10.1.1.4 (FD1) and 10.1.1.5 (FD2). This gives paths of 10.1.1.10 and 10.1.1.11 which are the interfaces on the top controller. I browse to my test iSCSI datastore and upload a 5GB file and then disconnect power to Switch 1. The path still remains as 10.1.1.11 is on FD2 on Switch 2.
-
The copy continues, slows down for awhile but eventually finishes.
My questions:
- What should happen if I disconnect 10.1.1.11? At the moment if I disconnect 10.1.1.11 the iSCSI datastore drops connectivity. I would have thought the last port 10.1.1.13 (which is Bottom Controller Port 2 - Fault Domain 2) would pick up this path and continue to function?
- If I look at the multipathing paths in vSphere they all report as Dead and there is no mapping to 10.1.1.13 despite having both Fault Domains listed under the Dynamic Discovery tab . Further to this if I connect to the Compellent web management console and check my Hypervisor it lists the last controller port as active/available but if I change over to the Mapping tab it still only lists it doesn't list the controller port.
At the moment I'm trying to ascertain if I've set something up incorrectly? Or am I asking too much from the device, perhaps its not intended to be used like this? Multipathing is set to Round Robin in vSphere.
Any help would be really appreciated.
Kind Regards,
Cameron
mtanen
118 Posts
0
February 4th, 2016 18:00
Quick question - I happened to notice that your fault domains appear to be on the same subnet ; that wont work with Compellent multipathing on iSCSI. You have two ports per controller, all plugged into one switch? That would normally be just a single fault domain
Cam J C
3 Posts
0
February 4th, 2016 20:00
Hi Michael,
We have 2 x fibre switches (Dell N series). We've cabled as per the recommended diagram above for our controller type dual (2x10GB fibre iSCSI controllers). Controller 1 Port 1 goes into switch 1 and Controller 1 Port 2 goes into switch 2. Controller 2 Port 1 goes into Switch 1 and Controller 2 Port 2 goes into Switch 2.
If we have two switches are we still required to have each fault domain on a different subnet?
Kind Regards,
Cameron
Cam J C
3 Posts
0
February 7th, 2016 14:00
Figured out what was going on. Needed to perform a port rebalance after disconnecting the 10.1.1.11 path. After doing this the mapping/path became active. I realise in a production environment it would be exceptionally rare for a switch to fail and then a link on the second switch also, but the purpose of this was purely to test redundancy capabilities.
I've also changed the fault domains to be on separate subnets (10.1.1.X and 10.1.2.X) and this seems to be working well now.