save yourself headaches and future outages, buy some LC-LC cables and connect additional CX ports to each switch
Switch 1:
SPA0
SPB1
Switch 2:
SPB0
SPA1
at least something like that, fabrics will NOT merge, CX is not an FC router . If your system admins do not buy Powerpath they can still use native multi-pathing. Your zones would look something like this:
But in the event we can't get the cables in the short term.. would that cut off some LUNs?
If so, I can use that information to pressure the powers to be to expedite the cable order.
Some of the servers they multipath; once the migration is complete and the Scalar tape libary is bought over to the new SAN, I expect more of their servers will go multipath, but there's always a few test servers they set up without it.
if servers have multiple HBAs, there is no reason not to use multipath, win2k8/win2k12/Linux/HPUX/AIX all have native multi-pathing software available, just needs to be configured.
today since you are not using multipathing software (and failover mode is 1 or 0) , even if you are zoned to multiple SPs, the minute your "primary" path becomes unavailable server will lose access to storage. On systems where you are using multipathing and failover mode is set to 4 you "should" be able to survive with one SP going away as your server requests should be serviced through the CMI bus from another SP. Honestly i have never tested this, i always have at least two paths, one going to each SP.
Maybe after everything is squared away, and hosts aren't straddling two SANs, we can go all multipath.
However, they seem to prefer MPIO to Powerpath, but from the documentation I've read, AULA doesn't play that nicely with Linux MPIO, It can load balance and autorestore but won't detect a non responding or hung SP.
(h2890-emc-clarion-asymm-active-wp.pdf page 17)
To make it worse, I think they ran into issues trying to get Powerpath to even run on the OracleOS one of their servers is running on.
Also, just last week I added a new host /initiator record for them, accidentally set with AULA, where as the other servers in the storage group were using PNR ; they said this server couldn't see one of the LUNs in the storage group that the other servers could see; I saw and edited the problem host for PNR, immediately it saw the LUN.
ALUA works just fine as long as you meet host side requirements. My physical window environment is dwindling so the few physical hosts that are left are using Microsoft MPIO and ALUA on VNX. Everything is working just fine, they survive Cisco FI reboots, VNX Flare upgrades. On the linux side (RHEL 5,6) we are using PowerPath, system admins like emcpower device persistence versus "flakiness" of DM-MPIO.
It just occurred to me.. if I do this, as you recommended: (I made a diagram too)
Switch 1:
SPA0
SPB1
Switch 2:
SPB0
SPA1
without any multipath software, I still shouldn't have any "ghost" duplicates of the LUN showing up on the host, right. because only one SP controls it..? (We would definitely have that issue with our old Symmetrix, but that was a different set up)
Now, what if, say, SPA fails, will the CX-4 at least be smart enough to trespass all it's LUNs to SPB regardless of host failover or software settings? That's what the connections to SP1 and SB1 would do for us?
The way our old Symmetrix used to be hooked up was very straightforward, the way I had originally planned to do our CX-4, but with the different SP model,it's become apparent that won't work, or at least, not unless I check every LUN to see which SP controls it, and manually trespass as necessary.
without multipathing you will see "ghost" entries if your HBA is zoned to multiple ports, it could be the same SP ..doesn't have to be another SP.
Ah, I see what you mean. So, SPA0 and SPA1, going to both HBAs ultimately, would create ghosts. Darn. Good point.
LUN trespass is initiator by host multipathing software, unless SP becomes unavailable (panic or NDU upgrade)
Is the keyword here, "unless"? Meaning, if it's not the HBA or switch at fault, but one of the SPs, will the CX-4 automatically trespass everything over to the other SP?
It should be simple for me to read the docs and glean this kind of info, but they throw so much at you it gets confusing. I had no training on this stuff.
You still need to multipath if you are zoned/masked to multiple FAs.
without multipathing you will see "ghost" entries if your HBA is zoned to multiple ports, it could be the same SP ..doesn't have to be another SP. LUN trespass is initiator by host multipathing software, unless SP becomes unavailable (panic or NDU upgrade), just because your host lost connectivity on one HBA will not trigger LUN trespass (again, without multipathing software). You don't have this issue with a Symm, every path is active so there no such thing as trespass. You still need to multipath if you are zoned/masked to multiple FAs.
LUN trespass is initiator by host multipathing software, unless SP becomes unavailable (panic or NDU upgrade)
Is the keyword here, "unless"? Meaning, if it's not the HBA or switch at fault, but one of the SPs, will the CX-4 automatically trespass everything over to the other SP?
yes, for example if SPB encounters hardware issues (say a memory module goes bad), it will panic and may or may not come back online. As soon as it panics, all LUNs get trespassed to SPA. If host uses multipathing software it simply marks paths to SPB as dead and continues to use paths to SPA without any disruption to storage access. That's why you need to re-emphasize to your sysadmin admins how important it is to use and properly configure multipathing. If they are having configuration issues you can always engage EMC support for assistance (granted you have an active support contract for EMC array).
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2014 07:00
Paul,
save yourself headaches and future outages, buy some LC-LC cables and connect additional CX ports to each switch
Switch 1:
SPA0
SPB1
Switch 2:
SPB0
SPA1
at least something like that, fabrics will NOT merge, CX is not an FC router
. If your system admins do not buy Powerpath they can still use native multi-pathing. Your zones would look something like this:
Switch 1:
host1-hba1-SPA0
host1-hba1-SPB1
Switch 2:
host1-hba2-SPB0
host1-hba2-SPA1
lpphiggp
1 Rookie
•
55 Posts
0
April 3rd, 2014 07:00
That is the best case scenario, definitely!
But in the event we can't get the cables in the short term.. would that cut off some LUNs?
If so, I can use that information to pressure the powers to be to expedite the cable order.
Some of the servers they multipath; once the migration is complete and the Scalar tape libary is bought over to the new SAN, I expect more of their servers will go multipath, but there's always a few test servers they set up without it.
dynamox
9 Legend
•
20.4K Posts
1
April 3rd, 2014 09:00
if servers have multiple HBAs, there is no reason not to use multipath, win2k8/win2k12/Linux/HPUX/AIX all have native multi-pathing software available, just needs to be configured.
today since you are not using multipathing software (and failover mode is 1 or 0) , even if you are zoned to multiple SPs, the minute your "primary" path becomes unavailable server will lose access to storage. On systems where you are using multipathing and failover mode is set to 4 you "should" be able to survive with one SP going away as your server requests should be serviced through the CMI bus from another SP. Honestly i have never tested this, i always have at least two paths, one going to each SP.
lpphiggp
1 Rookie
•
55 Posts
1
April 3rd, 2014 10:00
Maybe after everything is squared away, and hosts aren't straddling two SANs, we can go all multipath.
However, they seem to prefer MPIO to Powerpath, but from the documentation I've read, AULA doesn't play that nicely with Linux MPIO, It can load balance and autorestore but won't detect a non responding or hung SP.
(h2890-emc-clarion-asymm-active-wp.pdf page 17)
To make it worse, I think they ran into issues trying to get Powerpath to even run on the OracleOS one of their servers is running on.
Also, just last week I added a new host /initiator record for them, accidentally set with AULA, where as the other servers in the storage group were using PNR ; they said this server couldn't see one of the LUNs in the storage group that the other servers could see; I saw and edited the problem host for PNR, immediately it saw the LUN.
So AULA actually appears to break things?
The two path option is our saving grace.
dynamox
9 Legend
•
20.4K Posts
1
April 3rd, 2014 11:00
ALUA works just fine as long as you meet host side requirements. My physical window environment is dwindling so the few physical hosts that are left are using Microsoft MPIO and ALUA on VNX. Everything is working just fine, they survive Cisco FI reboots, VNX Flare upgrades. On the linux side (RHEL 5,6) we are using PowerPath, system admins like emcpower device persistence versus "flakiness" of DM-MPIO.
lpphiggp
1 Rookie
•
55 Posts
0
April 4th, 2014 07:00
It just occurred to me.. if I do this, as you recommended: (I made a diagram too)
Switch 1:
SPA0
SPB1
Switch 2:
SPB0
SPA1
without any multipath software, I still shouldn't have any "ghost" duplicates of the LUN showing up on the host, right. because only one SP controls it..? (We would definitely have that issue with our old Symmetrix, but that was a different set up)
Now, what if, say, SPA fails, will the CX-4 at least be smart enough to trespass all it's LUNs to SPB regardless of host failover or software settings? That's what the connections to SP1 and SB1 would do for us?
The way our old Symmetrix used to be hooked up was very straightforward, the way I had originally planned to do our CX-4, but with the different SP model,it's become apparent that won't work, or at least, not unless I check every LUN to see which SP controls it, and manually trespass as necessary.
lpphiggp
1 Rookie
•
55 Posts
0
April 4th, 2014 08:00
Ah, I see what you mean. So, SPA0 and SPA1, going to both HBAs ultimately, would create ghosts. Darn. Good point.
Is the keyword here, "unless"? Meaning, if it's not the HBA or switch at fault, but one of the SPs, will the CX-4 automatically trespass everything over to the other SP?
It should be simple for me to read the docs and glean this kind of info, but they throw so much at you it gets confusing. I had no training on this stuff.
Got 'cha. Understood.
Thank you for all your help.
dynamox
9 Legend
•
20.4K Posts
1
April 4th, 2014 08:00
without multipathing you will see "ghost" entries if your HBA is zoned to multiple ports, it could be the same SP ..doesn't have to be another SP. LUN trespass is initiator by host multipathing software, unless SP becomes unavailable (panic or NDU upgrade), just because your host lost connectivity on one HBA will not trigger LUN trespass (again, without multipathing software). You don't have this issue with a Symm, every path is active so there no such thing as trespass. You still need to multipath if you are zoned/masked to multiple FAs.
dynamox
9 Legend
•
20.4K Posts
0
April 4th, 2014 11:00
yes, for example if SPB encounters hardware issues (say a memory module goes bad), it will panic and may or may not come back online. As soon as it panics, all LUNs get trespassed to SPA. If host uses multipathing software it simply marks paths to SPB as dead and continues to use paths to SPA without any disruption to storage access. That's why you need to re-emphasize to your sysadmin admins how important it is to use and properly configure multipathing. If they are having configuration issues you can always engage EMC support for assistance (granted you have an active support contract for EMC array).