This post is more than 5 years old
6 Operator
•
5.7K Posts
0
2141
October 29th, 2007 06:00
split existing fabric into 2 fabrics - best practice please
A customer of ours has implemented a single fabric. We need to break this up into two separate fabrics because of HA reasons (if 1 fabric has an issue, at least the other fabric is up).
What if I simply unplug the ISLs that caused the merge in the first place and then afterwards clean up the zoneset of unneeded zoning, aliases and switches. Would that be a good idea ?
Any idea how to remove a switch that no longer is part of a fabric ?
What if I simply unplug the ISLs that caused the merge in the first place and then afterwards clean up the zoneset of unneeded zoning, aliases and switches. Would that be a good idea ?
Any idea how to remove a switch that no longer is part of a fabric ?
No Events found!


GlenH
141 Posts
0
October 30th, 2007 15:00
If there no devices zoned between the existing switches and therefore nothing is using the existing ISL's, then you can simply just remove them and clean up the zoning as you descibed earlier.
You shouldn't need to change the domain ID of the switches - it's just a number - as long as each switch in the fabric has a unique domain (which it must already have given its one fabric) then leave it alone.
You should be aware that the FCID will change if you change the domain ID as the switch domain ID is the first component of an FCID.
Good Luck,
Glen.
Kiran3
410 Posts
0
October 29th, 2007 08:00
afterwards clean up the zoneset of unneeded zoning, aliases and switches.
Would that be a good idea ?
i am not switch expert but i guess not, it would need major downtime.
i would rather start building another fabric using unused swtich and then migrate hosts one by one.
do you have aix hosts? i heard the fabric changes are not easy on those...
waiting on the thread...
RRR
6 Operator
•
5.7K Posts
0
October 29th, 2007 09:00
I expect this to be a major change indeed. This customer really had some weird ideas about high avalibility....
Oh well, this is an opportunity for us to make it right again. Unfortunately we don't have any spare switches...
I hope more people will add valuable comments in this thread. Let's wait what everybody else has to say about this
RRR
6 Operator
•
5.7K Posts
0
October 29th, 2007 09:00
GlenH
141 Posts
1
October 29th, 2007 19:00
Both HP-UX and AIX use the FCID of each target (ie: storage port) to create the hardware path in the OS. This means that it's only if you have to relocate storage ports that you'll find the path changes in the OS. Moving the HBA should not cause you a problem. Can you do the fabric split without moving any Storage ports ?? If you can, then you shouldn't see any changes at the host.
With AIX, you have no option but to use the emcpower (hdiskpower) devices however with HP-UX, most people use the native device name "/dev/dsk/cXtXdX" when configuring the volume groups, so if you have done the same, then you will have to reconfigure the VG if you relocate the storage port during the change.
Good Luck,
Glen.
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
1
October 29th, 2007 19:00
RRR
6 Operator
•
5.7K Posts
0
October 30th, 2007 05:00
It's good to know that PPath should mask possible fcid changes.
RRR
6 Operator
•
5.7K Posts
0
October 30th, 2007 05:00
What if I need to change domain ids ? Does the fcid change when I do that ?
I prefer to leave the fabric intact and split it up into 2 smaller fabrics and clean up unneeded switches and zones afterwards. Only if really really needed, I have to change domain ids as well, so therefor my question about the fcid.
RRR
6 Operator
•
5.7K Posts
0
October 31st, 2007 01:00
All of you actually !!!!
I've got the answers I need.