Today’s SAN administrators are faced with the need for more storage capacity and speed. They require high-performance and redundant SAN networks that can both meet their current demands and scale for growth in the future. To accommodate these new requirements, SAN administrators often need to migrate or upgrade from their existing storage networks.

      Migrating SANs from one vendor to another requires a specific plan that includes design, configuration, and implementation processes along with post migration analysis. This document helps you evaluate appropriate options for SAN conversion between Cisco MDS and Brocade switches.

SAN Migration Preparation

1.     Migration Concepts

      Generally, you can choose among three migration methods for SAN migration:

·         Rip and Replace: As the name suggests, with this approach you simply replace the old switches with new preconfigured switches.

·         Cap and Grow: New switches are connected in a parallel topology to an existing third-party SAN. New and existing servers and targets are attached to new switches. The old switches are removed one by one while both SANs are running and serving traffic simultaneously and independently during the migration.

·         Interoperate: New switches are connected to old switches using interoperate mode. Both vendors work together for a period of time before the old switches are removed in phases.

2.     Migration Process

      These are the main steps:

·         Prepare: Analyze the current storage infrastructure, business requirements, and risks. Identify critical servers, storage subsystems, and applications. Prepare a rollback procedure in case rollback is required. Prepare or update the SAN and storage diagram to meet new requirements. Prepare all device configurations (zone conversion, VSAN configuration, etc.) in advance and have them ready during the change window. Depending on migration method used, most of the configuration can be completed ahead of time.

·         Plan and design: Identify migration options and create a migration strategy. Identify any new additions and future requirements for the SAN fabric at this stage. This step will help the new SAN environment have enough flexibility to meet your needs longer.

·         Operate and optimize: Perform the actual migration, move cables and chassis, and configure the new setup. After migration is complete, you can implement continuous monitoring and optimization to identify and mitigate risk and tune the infrastructure to accommodate new projects and applications as the need arises.

3.     Prepare

      The process of SAN migration starts with preparation. This step helps you define, scale, and meet your migration goals:

·         Inventory your network

·         Verify compatibility

·         Upgrade components (To meet the requirements of the support matrices)

·         Assess the SAN

·         Validation

4.     Physical Planning

      The planning and design phase involves both physical and architectural elements.

Architectural Planning

      Architectural planning includes all design-related details, including network topology, cable diagrams, cabling techniques, power-plug connections and positions, cabling mechanisms for different chassis, PDU placement, and air conditioning and air circulation requirements.

Software Interoperability Planning

      For migration, switch interoperability is an important consideration. Switches from different vendors should be able to communicate with each other, and software interoperability plays a major role in helping ensure that they can.

   5.   Licensing

      Before SAN switch migration, it is important to obtain the correct license set for your switches. Most software features are included in the base license. However, some features are logically grouped into add-on packages that must be licensed separately.

Cisco MDS

1.     Software Interoperability Planning

    The following table summarizes the Cisco interoperability modes and their compatibility with third-party switches.

   

·         Default or Cisco MDS native mode: This is the default mode or behavior for a VSAN that is communicating with a Cisco MDS switch-based SAN.

·         Interoperability mode 1: This mode interoperates with Brocade switches that have been configured with Brocade interoperability mode.

·         Interoperability mode 2: This mode, also known as the interoperability mode for existing Brocade switches, allows transparent integration with Brocade switches running in native mode with the core value of PID = 0.

·         Interoperability mode 3: This mode was introduced for Brocade switches that contained more than 16 ports. With this interoperability mode, Cisco switches will interoperate with Brocade switches in their native mode and operating with a core value of PID = 1.

·         Interoperability mode 4: This mode, also known as interoperability mode 4 for existing switches, provides interoperability between Cisco MDS switches and McDataswitches operating in native mode. This mode supports only domain IDs 1 through 31.

          Cisco Interoperability Mode and Feature Limitations with Third-Party Switches

   

2.     Licensing

    The following table provides a comparison of Brocade and Cisco licenses.

   

3.     Migration Tools: Zone Migration Wizard

      To migratea third-party SAN to a Cisco MDS SAN, Cisco provides a Zone Migration Wizard in the Cisco Prime DCNM for SAN module. The wizard collects and automatically converts third-party zones into Cisco MDS 9000 Family zones. This GUI-based tool helps migrate the zoning configuration to Cisco SAN switches.

   
   

4.     Operate and Optimize

      After the migration process is complete, perform the following actions to verify that the migration was successful:

·         Run a Cisco Prime DCNM for SAN health report to verify that all hosts and storage devices have redundant paths.

·         Check application performance levels checks and check servers for path redundancy to verify that defined and expected SLAs are being met.

·         Back up new SAN configurations so that they are available in the event of a failure.

·         Back up switch configurations regularly to protect against unexpected outages. You can run a script at a scheduled time to back up configurations to a SFTP server, or you can use Cisco Prime DCNM to back up configurations in the Cisco Prime DCNM database.

·         Start retiring the old SAN infrastructure.

·         Perform multipath host verification by running the host path redundancy check tool on all hosts after migration is complete.

Brocade

1.     Migration Assessment

      It is important to understand the current application environment and the new SAN requirements before attempting a migration. There is more than one way to proceed with the migration process, depending on the current SAN architecture, fabric topology, size, and number of active devices attached.

      A SAN fabric migration can be done both offline or online, depending on the application or project requirements. An offline migration is the simpler of the two approaches, though careful planning is required. However, in many environments where planned downtime is not possible, then the migration must be performed online. An online migration in a single or redundant fabric requires careful evaluation of the application availability and currently deployed topology, in order to plan for a methodical migration path.

      There are several factors to consider, regardless of the migration approach:

·         Assessing the existing fabric topology

o    Application failover considerations

o    Storage failover considerations

o    Topology change at the time of migration (Address any performance bottlenecks, server and storage scalability, and general maintenance of the fabric)

o    Zone configuration export/modify strategy

o    Server and storage device placement

·         Assessing the new fabric topology

o    Brocade Fabric OS upgrade requirements

o    Capture configuration parameters of the existing switch

o    Zone import

o    Trunking setup considerations

o    Future server or storage expansion

·         Logistic planning for hardware installation

o    Rack space requirements

o    Power requirements

o    Cable requirements

·         Topology and zone planning

·         Preliminary migration planning

   

2.     Develop The Migration Plan

      A good migration plan should include at least the following steps:

·         Project scope and success criteria

·         Phases, tasks, and subtasks

·         Resource definitions

·         Timelines

·         Task dependencies

·         Tracking criteria

·         Checkpoints

·         Deliverables for procedures, designs, and configurations

·         Fallback plans and signoff criteria

      Performing the following steps ahead of time helps you to minimize the time required for migration.

                             

Prepare to Migrate	Status	Notes
Rack, cable, and power on the destination fabric.
Install Brocade Network Advisor.
Install Brocade SAN Health and discover both Brocade and Cisco fabrics.		Use the SAN assessment and zone import  tool.
Set up Ethernet and serial console for the Brocade switches.		Refer   to individual fabric details.
Install recommended Brocade FOS.
Create the baseline configuration for all switches in the fabric.
Import zoning sets from Cisco MDS SAN.		Use Brocade SAN Health
Install any fabric licenses.
Purge any zonesets that are no longer in use.
Create zones for new devices.		Dynamic Fabric Provisioning is an option for Brocade   HBAs.
Validate the ISLs.		Spinfab  and D-Port (16-Gbps platform)

3.     Perform The Migration And Validation

      Once the migration activity is complete, it is critical to execute a post-migration plan. There are several steps to ensure that all the work you just completed is protected and validated.

·         Run Brocade SAN Health.

·         Validate new SAN configurations.

·         Validate application operations.

·         Back up new SAN configurations.

·         Sign off on SAN migration.

·         Retire the old SAN infrastructure.