This post is more than 5 years old
236 Posts
0
6782
Migrating from Brocade DS-300B to Brocade DS-6510F-B
Hi All,
I was wondering if you can provide your input for the plan to migrate from Brocade DS-300B (IDs 10 and 11) to Brocade DS-6510F-B in the below topology. Each Brocade 300 is ISLed to three 5480 (HP blade switches) via two ports. Brocade 300s are the Principle switches in the fabric. Blade servers are running various OSs: Windows, Linux, VMware. All hosts are connected to both fabrics via one HBA, all hosts have multipathing software configured. I want to do migration with everything online by migrating one fabric at a time.
This is my plan for migration:
1. Initialize the new 6510s, assign the switch IDs that are lower than the existing principal switches - for fabric one - ID 8, for fabric two - ID 9, set the new switches priority lower than the existing 300, so that 6510 will become the principle switches once they are ISLed to the 300s.
Are there are any other configuration parameters on the 6510 that I have to set, so that I could successfully ISL it to the 300 switch?
2. Make sure the new 6510s are running the same FOS version as all the switches in the fabric.
3. Apply all required licenses.
4. Backup the config on both fabrics.
5. Ensure that all the hosts have four paths on VNX5500.
6. Start with Fabric_1 - connect a two port ISL between 300 and 6510. If the ISL does not come up right away the speed of ISL ports might have to be adjusted manually to match the on both switches.
7. Ensure that the new switch - 6510 - becomes a principle in the fabric. Make sure that all the zoning info gets transferred to the new switch. Check flogi to make sure that all the hosts are logged in to the fabric. Are there any other configuration parameters that I will need to check to verify that the ISL is successful and the fabric configuration is copied (merged) to the 6510?
8. Moving switch ISLs.
I have two scenarios for this task. Not sure which will be the best way. In Scenario One, I am planning to completely break the ISL between the existing 5480 and 300, and recreate the ISL once it is connected to 6510, not sure if all the config will stay on the switches.
In Scenario Two, I will not completely break the ISL, because I will be moving one cable at a time for each ISL, therefore I think all the switches should retain the config and stay connected in the Fabric. However by moving one cable at a time for each ISL I will be creating a loop, not sure if it will be an issue. I am leaning more towards the second method, because I will not be disconnecting the 5480s completely, but still not 100% sure, therefore, looking for recommendations on this one.
-
- Scenario One
- Move ISLs from each 5480 one at a time, that is I will disconnect both ISL cables for 5480 with DID 20 first, and reconnect them to the new 6510. Then I will make sure the hosts connectivity, zoning, flogi, etc. are still in place. Repeat the same step for switches with DID 30 and 40.
- Scenario Two
- Move one ISL connection (marked RED in the diagram) from each 5480 in Fabric_1 to 6510. Make sure the hosts connectivity, zoning, flogi, etc. are still in place.
- Move the second ISL connection (marked YELLOW in the diagram) from each 5480 to the new 6510 in Fabric_1. Again make sure the hosts connectivity, zoning, flogi, etc. are still in place.
- Scenario One
9. Move storage ports one at a time to 6510 on Fabric_1.
10. Move the host ports.
11. Verify all the configuration has merged, check flogi, zoning, and verify that all the hosts have four paths on VNX5500.
12. Remove the ISL connection from 6500 to 300. Repeat step 11.
I appreciate everybody's input.
victory_is_mine
236 Posts
0
June 28th, 2016 09:00
In case anyone is interested, this is what I have followed. Worked like a charm, no downtime at all:
1. Initialize the new 6510s.
2. Assign the switch IDs that are lower than the existing principal switches - e.g., for fabric one - ID 9, for fabric two - ID 10.
3. Make sure the new 6510s are running compatible FOS version.
4. Apply all required licenses.
5. Backup the config on both fabrics - 'configUpload'.
6. Ensure that all the hosts have at least four paths on VNX (depends on how many storage ports are connected to the switch and on the zoning), and the hosts are running multipathing software.
7. Check all of the fabric parameters (configshow and look at fabric.xxxx parameters) and they should be identical. Verify default zone access is set to 'All Access' on all switches: 'defzone --show'.
8. Disable both new 6510 switches before connecting the first ISL.
9. Start with Fabric_1 - connect a two port ISL between 300 and 6510.
10. Enable the new switch.
11. Make sure that all the zoning info gets transferred to the new switch - 'fabricshow, islshow, and cfgshow'. Check to make sure that all the hosts are logged in to the fabric.
12. Ensure that the new switch - 6510 - becomes a principle in the fabric, by setting the high switch priority on the 6510 (lower number is higher priority):
a. Run this command on present Principal switch: 'fabricprincipal --enable -p 0xff –f'. It will now get the lowest priority.
b. Run this command on the switch that shall become Principal switch: 'fabricprincipal -f 1'. It will get the highest priority. It will trigger Fabric rebuild.
c. Verify with 'fabricshow' and 'fabricprincipal --show' that the 6510 is the principal in the fabric now.
d. Run this command on former Principal 300 switch: 'fabricprincipal --disable'.
13. Check the configuration with fabricshow, islshow, and cfgshow.
14. Move one ISL connection from each 5480 in Fabric_1 to 6510. Make sure the hosts connectivity, zoning, etc. are still in place.
15. Move storage ports one at a time to 6510 on Fabric_1.
16. Move the second ISL connection from each 5480 to the new 6510 in Fabric_1. Again make sure the hosts connectivity, zoning, etc. are still in place.
17. Verify all the configuration has merged, check host logins, zoning, and verify that all the hosts have at least four paths on VNX.
18. Remove the ISL connection from 6510 to 300.
19. Repeat steps 9 through 18 for Fabric_2.
ZaphodB
195 Posts
0
May 17th, 2016 17:00
I wanted to throw a reply on this:
When, in step 9, you are moving the storage ports I recommend that you trespass the LUNs from SP to SP in such a fashion that the ports that you move are not the 'active' paths at the time that you move them.
Failover works, but in order for it to work something has to fail. If you trespass first, then the hosts will see the path go away and come back, but they will not need to have I/O time out and trigger the MPIO driver to re-drive on the stand-by paths.
As an anecdote I recently moved off of a pair of FC switches and onto a different pair in an data center that had two good sized (20+ host) ESX clusters attached to over a dozen VNX & VNX2 arrays.
By doing the trespasses, the hosts logs 'light up' as the paths disappear and reappear, but the clusters don't even flicker as far as latencies etc.. But on the single port that we 'oopsed' and pulled before the trespass had been done everything survived, but the two clusters spent 3-5 minutes'wobbling' and a number of hosts exhibited dramatically amplified latencies. These are busy clusters, so you may not experience the same impact, but I think that it is good practice.
As a second piece of advice, I make a habit of checking the SFP signal levels and error counts (using Brocade Network Advisor in my case) at the switch after any cabling work. It is not a complete test, but if I see a loss of signal strength, or an error bucket rolling up it is far easier to stop and work it out then rather than have it catch up with me later.