05-14-2016 09:34 AM
I was wondering if you can provide your input for the plan to migrate from Brocade DS-300B to Brocade DS-6510F-B in the following topology: there are two fabrics - fabric_1 and fabric_2, each has four switches - one Broace 300 and three Brocade 5480 HP blade switches. Switch IDs in fabric_1 are: Brocade 300 - DID 10, 5480s are 20, 30, 40. Switch IDs in fabric_2 are: Brocade 300 - DID 11, 5480s are 21, 31, 41. Three Brocades 5480s in the fabric are ISLed to one 300 via two ports. Brocade 300s are the Principle switches in both fabrics. 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, so that the new switches 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.
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.
05-20-2016 12:29 AM
05-24-2016 12:32 PM
Thank you. What bothers me is how to make a new switch a principle in the fabric. Is it something that I have to configure before joining it to the existing fabric? How does it assume a principle role? it has to have the priority lower than the current principle. Went through the CLI guide, but cannot find anything applicable there, except the 'fabricprinciple' command.
Also how would I be able to confirm that the new switch has succesfully merged with the fabric and the config has been copied to it?
05-25-2016 12:44 AM
06-18-2016 04:11 PM
I need to remove the 300s after the 6510 are joined to the fabric. 300s are the principal i nthe fabrics now, so I guess I would want to move this role the newer more powerful 6510s, rather than 5480s.
What are your thoughts on this:
What will happen if the switch priority on the new 6510 switch, that is being connected to the existing multi-switch fabric, is manually set to the same value as the priority on the existing principal switch? That is, what will happen if I run this command on the new switch before connecting it to the fabric: 'fabricprincipal --enable'? It sets the new switch as principal, but will it become a principal when joined to the fabric, or I will have major issues? I doubt that I can have more than one principle configured in a fabric.
What will be a better approach - set the new switch as principal before joining it to the fabric, or after, by increasing the priority of a current principal and decreasing the priority of the new switch and forcing a fabric rebuild? That is to do the following:
1). Join the new 6510 switch as subordinate.
2). Run this command on present Principal switch: 'fabricprincipal --enable -p 0xff –f'. It will now get the lowest priority.
3). Run this command on the switch that shall become Principal switch: fabricprincipal -f 1. It will get the highest priority and become principal. This will trigger a fabric rebuild.
4). Run this command on the former Principal 300 switch: 'fabricprincipal --disable'.
5). Remove 300 from the fabric after all the other connections are moved to 6510.
06-18-2016 11:47 PM
06-19-2016 02:54 AM - edited 06-19-2016 06:37 PM
Thanks for the reply, I just finished the migration, worked like a charm.
I followed these steps, in case somebody may be interested in the future:
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.