This post is more than 5 years old
22 Posts
0
1173
Basic questions for creating fabric with production switches
Hi.
I have two brocade switches ( The first thing is that both switches have the same Domain ID, I know that I need to change this before trying to make the ISL and so, but does this change affects production? It's an online change or is there any disruption?
I found this procedure to do the change, can anyone tell me if that is ok?
On the switch which I want to be secondary:
switch:admin> switchDisable
switch:admin> configure
Fabric parameters (yes, y, no, n): [no] y
Domain: (1..239) [1] 2
Ctrl-d
switch:admin> switchEnable
After this, there is the need to create a new Zone Config, as each enabled config on each switch is different and I want to merge them clean, so I really want to sincronize all configurations on both switches. I create the new Zone Config equally, same name and clone all zoning information independently, then I'm planning to use de Zone Merger to sincronize both configurations so I have the two switches exactly with the some config (clearing all conflicts - just found one).
The activation of this new Zone Config will disrupt communications with production hosts?
Is this the way to success?? hehehe I've reviewed all procedures and I'm think to be on the good road. Any suggestion will be appreciated.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
December 17th, 2009 08:00
i don't know of a non-disruptive way, whenever you change domain id the switch will tell you that it has to reboot but if you have two redundant fabrics and all systems will be setup with redundancy you should be fine. This is what i would do, others can correct me or add if i missed anything :
pre-work
1) On Fabric A - i would disable all ports to force all host I/O to go through fabric B
2) On Fabric A - delete zoneset config on both switches, set domain id to be unique on each switch
3) On Fabric A - load zoneset config you pre-created for fabric A on one switch, then connect ISL connections to the other switch. At this point fabrics should merge, verify by running "fabricshow". It should display both switches.
4) On Fabric A - re-enable switch ports. Go into each CX4 Connectivity status and verify all hosts are logged-in. Go to each host and run "powermt restore", and then "powermt display". At this point old paths should have come back, verify before proceeding. If you do not see old paths, go into diskpart and run "rescan" and then try "powermt restore/display" again. If you still do not see the old paths you might have to reboot the system.
Once everything looks good, proceed to fabric B. I always schedule this kind of work during maintenance window because no matter how much you plan, there are always one or two stubborn systems that have to be rebooted.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
December 17th, 2009 05:00
changing domain id could be very disruptive depending on what kind of hosts you have. HPUX and AIX rely on fcid (based on domain id) to discover their disk paths so any changes to domain id would result in disk paths change on the host that could lead to not so desirable results. If you have these type of hosts, prepare your system admins to do some LVM work (export, import). It would be an offline process for them. Also just the fact that you will run "switchdisable" before changing the domain id would bring this switch offline. Do you have two fabrics or just one ?
josevtome
22 Posts
0
December 17th, 2009 07:00
Thanks for the reply.
Actually I have two pair of switches, same models, to create two separate fabrics. We still have to solve some redundancy issues for a couple of hosts, but most of them have two redundant connections to the same-model switches and Powerpath installed. All of the hosts are Windows (exchange servers, domain server, file servers), connected to a couple of Clariion CX4.
Is there another way to change the Domain ID without disruptive configurations? Just to know, because if all redundancy is well configured I should have no problems of bringing a pair of switches down for a little time (if no other conflicts are generated like you mentioned).
Thanks!
josevtome
22 Posts
0
December 17th, 2009 23:00
Great! This info is perfect for me! Thank you very much Dynamox! The port-offline procedure will be perfect to test the redundancy and a good way to roll back fast in case of a host failure!
Thank you a lot for your time!