SAN Migration Guide

DATA CENTER
SAN Migration Guide:

Migrating from Cisco to Brocade
Guidelines and strategies for the migration of legacy Cisco MDS to the
industry-leading Brocade DCX and DCX 8510 SAN Fabric solutions that
deliver the highest performance and operational simplicity from any
network vendor today.
DATA CENTER MIGRATION GUIDE
CONTENTS

Introduction..........................................................................................................................................................................................................................................4
Audience and Scope.........................................................................................................................................................................................................................4
Migration Process ..............................................................................................................................................................................................................................5
Migration Qualification.....................................................................................................................................................................................................................6
Define Migration Goals ....................................................................................................................................................................................................................6
Fabric Consolidation ....................................................................................................................................................... 7
Building a Private Storage Cloud ................................................................................................................................... 8
Migration Assessment .....................................................................................................................................................................................................................8
Assess the Existing Fabric Topology............................................................................................................................................................................................9
Assessing the New Fabric............................................................................................................................................. 10
Logistic Planning of Hardware Installation .................................................................................................................. 10
Topology and Zone Planning ........................................................................................................................................ 10
Preliminary Migration Planning .................................................................................................................................... 10
Gather Infrastructure Information ............................................................................................................................................................................................ 11
Choose the Migration Strategy .................................................................................................................................................................................................. 12
Fabric Strategy .............................................................................................................................................................. 12
Online Redundant Fabric Migration ............................................................................................................................. 13
Offline Fabric Migration ................................................................................................................................................ 15
Migration Methods ........................................................................................................................................................ 15
Develop the Migration Plan......................................................................................................................................................................................................... 16
Prepare to Migrate ......................................................................................................................................................................................................................... 16
Perform the Migration and Validation..................................................................................................................................................................................... 17
Offline Migration............................................................................................................................................................ 17
Redundant Fabric Online Migration ............................................................................................................................. 17
Complete the Migration ................................................................................................................................................ 18
Appendix A: Migration Use Case Examples .......................................................................................................................................................................... 19
Migrating from a Cisco VSAN to Brocade Virtual Fabrics ........................................................................................... 19
Migration Overview ............................................................................................................................................... 19
Tools Required ...................................................................................................................................................... 19
Procedure for Use Case #1.................................................................................................................................. 20
Migration Procedure ............................................................................................................................................. 21
Capture and Migrate the Zone Database ........................................................................................................... 21
Survey the MDS Fabric and Prepare for the Migration ...................................................................................... 22
Enable and Configure Brocade Virtual Fabrics................................................................................................... 25
Create the Logical Switch .................................................................................................................................... 27
Import Brocade SAN Health Zone Configuration to Your Logical Switch .......................................................... 31
Cisco to Brocade SAN Migration Guide 2 of 41

Appendix B: Additional Considerations for Blade Servers Using NPIV......................................................................................................................... 34

Appendix C: Additional Considerations for the VMware Environment ........................................................................................................................ 35
Appendix D: Migration Planning Checklists .......................................................................................................................................................................... 36
Current Fabric Assessment .......................................................................................................................................... 36
Individual Fabric Details ............................................................................................................................................... 36
Device Details ............................................................................................................................................................... 36
Consolidated SAN Snapshot ........................................................................................................................................ 37
Device Mapping Details ................................................................................................................................................ 38
Application-Specific Details .......................................................................................................................................... 38
Appendix E: Terminology.............................................................................................................................................................................................................. 39
Appendix F: Reference Material ................................................................................................................................................................................................ 40
Software and Hardware Product Documentation ....................................................................................................... 40
Technical Briefs ............................................................................................................................................................. 40
Brocade Compatibility Matrix ....................................................................................................................................... 40
Brocade Scalability Guidelines .................................................................................................................................... 40
Brocade SAN Health Support Matrix ........................................................................................................................... 40
Brocade FOS Features .................................................................................................................................................. 40
Brocade Network Advisor ............................................................................................................................................. 40
Brocade Bookshelf ........................................................................................................................................................ 40
Other .............................................................................................................................................................................. 40

INTRODUCTION
This document provides guidelines and strategies to enable customers to migrate from the Cisco MDS-based fabric to
the high-performance 16-Gbps Brocade® DCX® 8510 Backbone Family and 8-Gbps Brocade DCX Backbone Director.
Migrating from an existing operational SAN (Storage Area Network) requires careful consideration to ensure a seamless
migration with minimum or no impact to ongoing SAN operations. It is crucial to obtain a clear understanding of the
existing SAN and application environment. This information is required to develop a successful migration strategy. With
proper planning, an existing fabric can be replaced or incrementally upgraded to the latest high-performance Brocade
16-Gbps or 8-Gbps DCX-based platforms.
This document provides sample strategies for the migration process, as well as a use case example that provides
specific migration details for a single VSAN (Virtual SAN) migration to a non-VSAN environment. Additional use case
examples will be provided in future revisions of this document.
Note: The procedures outlined within this document are guidelines only and are not intended to cover all use cases. The
goal is to help guide through the decisions that make for a successful SAN migration. Consult your Brocade Account
Team representative or documents referenced in Appendix F: Reference Material for details about the hardware and
software products and professional services.
AUDIENCE AND SCOPE

This guide has been written for technical lT architects, systems administrators, and technicians involved in migrating
from a Cisco MDS SAN to Brocade 16-Gbps or 8-Gbps DCX-based solutions. The migration procedures in this document
assume that the best practices as described in the Brocade SAN Design Best Practices Guide are followed, and the
infrastructure has been validated to be functional prior to migration. It is also assumed that those working on the
migration activity are familiar with Brocade hardware and software technologies.
Note: This document does not cover VSAN to Brocade Virtual Fabrics and single fabric migration. Refer to the Brocade
Fabric OS® Administrator’s Guide, Appendix F: Reference Material for Brocade Virtual Fabrics setup.

MIGRATION PROCESS
The fabric migration process is outlined in “Figure 1. Migration Process.” This document outlines the process
and procedures to help you assess, plan, prepare, and proceed with the migration.
SAN Migration
Process Overview
·∙ Is this technically feasible? (custom

management tools, # of VSANs, etc.)
Migration ·∙ Are there facilities issues? (racking, cooling,
Qualification power & cabling)
·∙ Is application outage acceptable?
·∙ Is there organizational support?
Define Migration ·∙ Define project scope and success criteria

Goals ·∙ Define long-term SAN fabric goals:
·∙ Fabric consolidation
·∙ Special purpose SAN architecture
Migration ·∙ Existing topology

Assessment ·∙ Application failover
·∙ Storage failover
·∙ Zone planning and device placement
·∙ Infrastructure logistics
Revise migration Gather
goals, architecture, Infrastructure ·∙ Device, zoning, configuration information
and/or strategy. No
Information
Choose the ·∙ Fabric strategy: Online or Offline

Migration Strategy ·∙ Application strategy: Migrate by application
or device
Develop the ·∙ Includes: phases, dependencies, resources,

Migration Plan tracking, checkpoints, configurations,
procedures, and failback plans
Is the plan
·∙ Project sign off
accepted?
Yes
·∙ Build new SAN infrastructure

Yes Prepare to Migrate ·∙ Import/create zone database
Perform next ·∙ Validate SAN configurations and procedures
Migration phase ·∙ Back up existing configurations
·∙ Run Brocade SAN Health
·∙ Back up new SAN
configurations Perform the
Complete the More ·∙ Execute migration Plan and validate per
·∙ Sign-off on completed SAN No Migration and
Migration Migrations? phase
migration project Validation ·∙ Validate connectivity and applications
·∙ Back up old SAN configuration
·∙ Sign-off per project phase
·∙ Decommission Cisco SAN
infrastructure
Figure 1. Migration Process

MIGRATION QUALIFICATION
Prior to conducting a full-scale migration assessment, you should consider the high-level technical, business, and
political impact to determine the feasibility of the migration:
Technical: This is the easiest of the three considerations to address. From a design and migration perspective, you
should consider the following:
• Cisco VSANs/Brocade Virtual Fabrics: While there are benefits to creating VSANs for physical separation and
management isolation, overuse of VSANs can create management complexity. If there are more than seven VSANs
per switch, consult the Brocade scalability guidelines for migrations from VSANs to Brocade Virtual Fabrics.
• Management tools: There is no impact to migrating any Storage Management Initiative Specification (SMI-S)-based
management tools from Cisco to Brocade, but you will need to rewrite custom tools. Brocade Network Advisor reduces
the number of management tools needed by providing a single user interface that can manage both SAN and
Ethernet networks as well as adapters, embedded blade server switches, and convergence technologies.
Business: Most organizations require a 24/7 operating environment. As a result, seeking a downtime window during
which to migrate may be difficult or impossible for some applications.
• Application outage: Applications with multi-pathing are easier to migrate, which allows for minimal business
interruption. Migrating Tier 2 and Tier 3 applications first instills confidence in the organization, resulting in a
smoother migration of Tier 1 applications. Redundant SAN fabric implementations make the migration process much
less disruptive.
Political: Even though separate SAN and LAN environments continue to exist, there are challenges when selecting a
best-of-breed solution.
• Organizational acceptance: If the devices and switches in the Cisco fabric are from multiple vendors and are used by
multiple organizations within the company, gaining acceptance from all the key players is critical to a successful
assessment and migration.
• Training and support: Organizations may have invested money and time for training personnel, thus switching vendors
may seem difficult.
Note: Brocade offers extensive education and certification training for SANs.
Once business and political challenges are addressed, assessing the migration requirements, developing a plan, and
implementing the migration are simply a matter of careful execution.
DEFINE MIGRATION GOALS

It is important to clearly define the end goal(s) for the new Brocade SAN. These goals fall into two categories:
Fabric(s) Consolidation: Higher density and higher performing switches
• No virtual fabrics: If this is a single VSAN migration, then there is no need to create a single virtual fabric on the
Brocade DCX 8510 platform to replicate the VSAN. A simple port-port mapping between the two fabrics eases the
migration process. (Refer to Device Mapping Details in Appendix D: Migration Planning Checklists.)
• Multiple virtual fabrics: If there are multiple VSANs that address logical separation between different business
groups or applications, and there is a requirement to keep a similar mapping using virtual fabrics, then you should
refer to the Device Mapping Details table Appendix D: Migration Planning Checklists and add the VSAN to virtual
fabric mapping.
Special Purpose SAN Architectures
• There may be business requirements—or customer architectural preferences—that dictate the use of special-purpose
SANs. These SANs may be standalone, physically or logically, and may include distance extension for storage
replication, independent backup SANs, or enterprise FICON (fiber connectivity) SANs.

Fabric Consolidation
When consolidating single or multiple fabrics as part of a migration, consider the following:
• Do you need the same number of ports?

• Is there an opportunity to reduce the number of ISLs used when migrating to the Gen 5 Fibre Channel
Brocade DCX 8510 technology?
• If VSANs are deployed in the Cisco SAN architecture, is there a benefit to keeping the same number of VSANs?
• Which SAN design—core-edge, edge-core-edge, or mesh—addresses current and future growth?
The following 1000-port example shows the benefit of consolidating five Cisco MDS chassis into a Brocade DCX 8510
chassis solution using two chassis that can expand in the future as a core-edge or a mesh solution.
With 64-Gbps UltraScale Inter-Chassis Links (ICLs) and high-density 8-Gbps port blades, multiple racks of MDS switches
can be consolidated into a single rack using the Brocade DCX 8510 chassis. This solution offers lower oversubscription,
power usage, and cooling, as shown in “
Figure 2. Fabric Consolidation for a 1000-port SAN.”
Figure 2. Fabric Consolidation for a 1000-port SAN
If the existing Cisco MDS SAN is based on a single VSAN (that is, if at a minimum there is at least one VSAN for
each MDS fabric), there is no need to create a single virtual fabric on the new Brocade SAN; device ports can be
migrated over, according to the device connectivity mapping.
If there is more than one VSAN, and you would like to keep a similar logical separation, Brocade fabrics can be
carved up into logical fabrics. Refer to the Brocade Fabric OS Administrator’s Guide (see Appendix F: Reference
Material) for details.

Building a Private Storage Cloud

As organizations move to provide a secure and controlled infrastructure for a highly virtualized server farm, it is
important to deploy a scalable fabric that can support a shared storage SAN for all virtualized applications, such as for
private storage cloud services. Key characteristics of a private storage cloud are:
• Hyperscale fabrics in terms of ports and performance

• Secure data transfer between data centers
• Built-in infrastructure diagnostics and management tools
“Figure 3. Large-Scale Cloud Storage Architecture” provides an example of a 3000-port SAN infrastructure that collapses
13 Cisco MDS 9513 chassis into six Brocade DCX 8510 platforms in a core-edge configuration for building large-scale
private storage cloud architectures.
Figure 3. Large-Scale Cloud Storage Architecture
When designing for a cloud storage SAN, consider designing by using UltraScale ICLs to free up front-end ports for device
connectivity. With an UltraScale ICL-based design, you can create a scalable SAN that leverages up to a nine-chassis
core-edge or mesh design for any-any connectivity that supports more than 4500 ports per SAN.
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

• Assessing the new fabric topology
• Logistic planning for hardware installation
• Topology and zone planning
• Preliminary migration planning

ASSESS THE EXISTING FABRIC TOPOLOGY

Determine if the current environment is a single fabric or a redundant fabric. Figure 4 outlines single, single
resilient, and redundant fabric topologies. If the current environment uses a redundant fabric, a rolling
migration could be an option, where one fabric is active and the other fabric is migrated offline. Similarly, device
paths in a single resilient fabric can be failed over as devices are moved to the new fabric. Both methods can
minimize fabric downtime and I/O interruptions, if multi-pathing software is in use. Migrating a single non-
resilient fabric is certainly more complex and requires application interruption—or an outage, if the host has to
be rebooted.
Figure 4. Fabric Topologies
Some things to consider when assessing the migration activity include:
• Application failover considerations: If multi-pathing software such as Microsoft MPIO, AIX MPIO, Hitachi HiCommand
Dynamic Link Manager (HDLM), or EMC PowerPath is in use, collect metrics to determine how long it takes to fail over
and fail back in the existing SAN.
• Storage failover considerations: Move all the Logical Unit Numbers (LUNs) to a single controller if not dual-pathed.
Verify that the number of LUNs from a single port does not exceed the vendor recommendation.
• Topology change at the time of migration: Migrating to a new fabric is a good opportunity to address performance
bottlenecks, server and storage scalability, and general maintenance of the fabric, such as structured cable
management (refer to resources in Appendix F: Reference Material). High-density directors with UltraScale ICLs offer
an opportunity to simplify traditional SAN designs.
• Use of UltraScale ICLs: It is important to know if UltraScale ICLs are being utilized, in order to develop a
comprehensive migration and Director Consolidation plan. Please check the latest Brocade Fabric OS® (FOS) release
notes on supported UltraScale ICL cable distance.
• Zone configuration export/modify strategy: If some or all of the devices in the old fabric are being migrated to the
new fabric, the existing MDS zone database can be exported and then imported into the Brocade SAN to minimize the
migration timeframe.
• Server and storage device placement: While hop count is no longer an issue, keeping the number of hops between
server and storage to no more than two can minimize possible congestion issues as the SAN expands. Whatever
method is used for device placement, it is important to be consistent across switches and fabrics.

Assessing the New Fabric

Some things to consider when assessing the new fabric include:
• Brocade FOS upgrade requirements: Prior to connecting any devices, verify that the switches are running the
recommended Brocade FOS version.
• Capture configuration parameters of the existing switch: Capture Cisco MDS switch configuration and compare with
Brocade switch parameters. Even though the configuration formats are different, compare the standards-based fabric
parameter for any deltas.
• Zone import: Assess the size of the zone database of the existing fabric and use Brocade SAN Health® to capture the
MDS zone database. Clean the zone database by removing any zone members that are no longer part of the fabric.
• Trunking setup considerations: Compared to the Cisco PortChannel technology, Brocade Inter-Switch Link (ISL)
Trunking is a hardware-based stripping mechanism with predictable latencies for traffic flows. In a multi-switch
environment, you should have multiple trunks such that, in case of an entire trunk failure, the remaining trunks are
not congested.
• Future server or storage expansion: Planning for the future is key to ensuring that the architecture you put in place for
the new SAN will meet long-term requirements.
Logistic Planning of Hardware Installation

When planning a migration, taking the facilities and logistics into consideration is paramount to success. Consider the
following:
• Rack space requirements: Cisco MDS 95xx uses side-to-side airflow, whereas Brocade uses front-to-back. This allows
for a narrower rack and the implementation of hot/cold aisle cooling. With a Brocade DCX 8510 solution, you gain
additional data center space. In cases where additional racks are being utilized for new directors, ensure that enough
rack space is available.
• Power requirements: Brocade DCX 8510 and DCX use 70 to 80 percent less power than Cisco MDS, so power will not
be an issue during the facilities reconfiguration stage of the migration process. In cases where additional racks are
being utilized for new directors, ensure that power and cooling are available for the new racks.
• Cable requirements: Confirm that the cable plant is within the required specifications (for instance, OM-3), and use
structured cabling, when possible, to minimize device placement errors during the migration. (Note: MDS 95xx is
cabled side to side, and the Brocade DCX/DCX 8510 is cabled from bottom to top. This could have an impact on the
slack of the cables and must be assessed up front.) In addition, ensure that there is enough available cable length to
accommodate reconfigurations of the new target Brocade DCX/DCX 8510 directors.
Topology and Zone Planning

• You need to do an assessment of ports per fabric with the legacy MDS topology, including VSAN and zone
configurations. You should also dialogue with the end user to identify the presence of host types that will be impacted
by the changes. You also need to convert legacy MDS zoning to Brocade zoning, including consolidating multi-VSAN
zone sets to single zoning configuration and determining naming conventions (refer to tables in Appendix D: Migration
Planning Checklists for templates).
Preliminary Migration Planning

Develop a preliminary migration plan:
• To complete a successful migration, identify the personnel needed during the key phases of the project: facilities
management, network administration, SAN administration/engineering, server administration with knowledge of the
dual-pathing and failover software, storage administration with knowledge of redundant paths, and project
management.
• Identify and analyze key implemented features, and define equivalent solutions for Brocade SAN infrastructure.
• Identify and analyze advanced features that may need to be considered, such as FCIP, Encryption, or FICON for the
new SAN.

• Define move groups based on applications, storage ports, and zoned hosts. Brocade SAN Health provides the
capability to create device “migration group” information. This makes it easier to identify all the devices associated
with a device that is targeted for migration from Cisco to Brocade, so that all associated devices can be migrated
together.
• Identify and resolve any Service Level Agreement (SLA) conflicts within move groups.
• Create port maps for host/storage on the migrated SAN (see the Device Mapping table in Appendix D: Migration
Planning Checklists).
• Review the migration plan with the end user or business group and revise as needed.
• Complete the final migration plan.
Establish post-migration verification criteria:
• Total number of devices in the fabric

• Baseline performance metrics for ISL and UltraScale ICLs
• Baseline latency measurements for server and storage ports
Appendix D: Migration Planning Checklists provides a set of tables for use during the migration planning. These tables
provide a framework that you can follow and enhance to ensure a successful migration.
Note: Follow the best practices guidelines described in the Cable Management Best Practices Guide and SAN
Design Best Practices Guide for Brocade Fabric (see Appendix F: Reference Material).
To facilitate the migration planning, a sample migration use case is provided in Appendix A: Migration Use Case
Examples. The use case provided makes several technical assumptions:
• Hosts are dual-pathed to the fabric; the use of failover mechanisms minimizes the disruption to
production I/O.
• An existing Cisco Fabric Manager server manages the Cisco MDS environment. Note that as of Cisco NX-OS v5.2,
Cisco Fabric Manager and FMS are also known as Cisco Data Center Network Manager for SAN.
• The Brocade DCX or DCX 8510 Backbone basic setup and configuration has been performed in advance.
• All Brocade switch licenses, such as the ICL POD Kit, have been acquired and installed on the
Brocade DCX.
• If Brocade Network Advisor is being used, it has already been set up and is able to discover the Brocade fabric.
Regardless of the type of fabric, it is recommended that migration take place during non-peak business hours.
GATHER INFRASTRUCTURE INFORMATION
At a minimum, complete the following tables as listed in in Appendix D: Migration Planning:
• Individual Fabric Details

• Device Details
• Device Mapping Details
• Application-Specific Details
Proper planning simplifies and minimizes the time required for migration.

CHOOSE THE MIGRATION STRATEGY

Fabric Strategy
You can simplify the migration process by preparing a migration plan in advance. Besides cabling, rack space, and power
requirements, other factors such as scheduling downtime, personnel security, and application change windows—as well
as host and storage failover—may significantly affect the SAN operations. The current configuration and operational
requirements of a target SAN may impose additional constraints. The key to a successful migration is to minimize fabric
interruption or to completely eliminate downtime, whenever possible, by identifying issues in advance.
Effective planning provides the preliminary groundwork for the evaluation phase and sets the foundation for the
migration process. After reviewing the requirements that apply to your unique situation, the migration process will fall
into one of the following categories:
• Online Redundant Fabric Migration

• Offline Fabric Migration
The flowchart provided in Figure 5 assists you in determining which of these is the best migration strategy for your
environment. As you see from the flowchart, there may be more than one strategy that you need to plan for.
SAN Migration Strategy
Revisit the Migration Redundant Is there a SAN Revisit the Migration

Strategy. No No
Fabric? downtime window? Strategy.
No
Yes
Yes
Follow “Offline Downtime

acceptable for Redundant paths for Follow “Offline Fabric
Fabric Migration” for Yes No
single path all applications? Migration.”
single-path devices.
applications?
Yes
All dual-path devices Review the impact of Tier

have multi-path No 1, Tier 2 and Tier 3
This applies to both software? application outages.
servers and storage.
Yes No
Validate multi-path Yes

configurations and collect
failover metrics.
Are all the redundant

paths open to their No
devices?
Yes
Is performance Can the fabric be taken

Follow “Online Redundant
Yes degradation No offline?
Fabric Migration.”
acceptable?
Figure 5. SAN Migration Strategy

Online Redundant Fabric Migration

A redundant fabric provides the flexibility to upgrade one fabric by bringing it offline while redirecting active I/O to the
other fabric. Current I/O operations are not impacted as a result of the migration activity. With this strategy, the hosts
are operating in a degraded mode with no data path protection. Any failure on an active path completely ceases I/O.
With proper planning, any downtime or outage is minimized. Once the fabric upgrade has been completed and verified,
you can bring it back online by restoring the I/O paths. The migration process is repeated for the second fabric after all
I/O paths are successfully restored on the first fabric.
The flowchart in “Figure 6. Online Redundant Fabric Migration” provides a general flow as to how to approach this type
of migration.
Online Redundant Fabric

Migration
Follow the steps for “Offline

Fabric Migration” for single- Do all applications have
No
path devices. redundant paths?
Yes
Ensure that all paths are

open to the devices that must Are all redundant paths
No
remain online. open to their devices?
Yes
Select a fabric for migration,

re-direct all redundant active
I/O from this fabric to an
alternative Cisco fabric.
Follow the steps for “Offline

Fabric Migration.”
Restore the I/O paths on the

devices connected to the No
new Brocade fabric.
Repeat until all the
fabrics are migrated.
Verify that the fabric

is operational.
Conduct a final verification

prior to decommissioning Are all the fabrics
Yes
the Cisco fabric. migrated?
Figure 6. Online Redundant Fabric Migration

Though the flowchart above outlines the general migration decision process, an online migration is possible only if the
answer to all of the questions shown in Table 1 is Yes.
Table 1. Redundant Fabric Online Migration Guidelines
Task Status Notes
Is there a redundant fabric topology? Yes
Are redundant paths for each device Yes

configured via the fabric or, if the device
is single-pathed, downtime for that
device is acceptable?
Is multi-pathing software installed, active, Yes
and verified as operational on each
fabric’s devices that require it?
Are redundant paths open to devices that Yes
require multi-pathing?
Is performance degradation acceptable Yes
during the upgrade? This performance
degradation results from one path to the
fabric being temporarily unavailable and
where the host and storage implement
active/active pathing.
Is “no protection mode” acceptable for Yes
migration duration?
Is host reboot not required for LUN Yes
discovery?
Note: It is possible that some devices may be singly attached onto a redundant fabric. If it is permissible for these
devices to go offline, it is not necessary to have multi-pathing software and redundant paths for all devices. Also, if there
are any old servers with old operating systems that rely on PID binding, when changing the ports or domain ID the PID
will change. Old AIX and old HPUX will not automatically restore their paths. You must manually restore the paths (cfgmgr
or vgreduce/vgextend) or reboot.

Offline Fabric Migration

An offline fabric migration assumes that a fabric can be brought offline to perform the migration and that I/O has been
completely ceased for the duration of downtime. This is the safest and most convenient method for migration. Use
Table 2 as a guide for offline migration.
Table 2. Offline Fabric Migration Guidelines
Task Status Notes
Follow the steps in the “Develop the

Migration Plan” section.
Follow the steps in the “Prepare to
Migrate” section.
Identify an ideal time to migrate (a low
number of users or performance).
Migrate Tier 2 and 3 storage and
applications.
Verify migration by running the
application(s).
Migrate Tier 1 storage and applications.
Verify migration by running the

application(s).
Migration Methods
Infrastructure resiliency or redundancy of the fabric determines the primary migration strategy. As you prepare for the
development of a migration plan, identify which strategy to use and plan accordingly. The migration options are as
follows:
• Port-to-Port migration: This is a straightforward port-port migration from one fabric to another. This method requires
all logically grouped initiator/target pairs to be moved during a single migration activity. This strategy is generally
called migrating by “move groups.” For example, when a storage port is moved, all associated Host Bus Adapters
(HBAs) that are accessing LUNs through this port must also be moved.
• Application migration: This is possible if the physical infrastructure is not shared across application tiers. If the
application happens to run on a new server and storage infrastructure, you should validate that all the required data
has been migrated prior to the cutover. SANs tend to be logically identified as database, web services, backup, and
so on.
• Device migration: This is a logical approach to offline migration, since customers physically isolate servers and
storage devices in racks or sections of the data center. Migrating devices using this method provides a clear high-level
accounting, especially for the racks that are relocated as part of the migration.
• Greenfield migration: In this approach, a new “greenfield” server, storage, and SAN environment is created, and all
new workloads are implemented into this new environment. No new growth is added to the Cisco MDS environment.
This is a good migration approach if there is a long-term financial commitment to the Cisco MDS equipment.

DEVELOP THE MIGRATION PLAN

It goes without saying that having a plan is the foundation for a successful project—or, in this case, a SAN migration. The
best practices for such a plan can be derived from any number of formal methodologies and, as such, fall outside the
scope of this document. However, any good 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
• Signoff criteria
• Prepare to migrate
PREPARE TO MIGRATE
Performing the following steps ahead of time helps you to minimize the time required for migration. Use Table 3 as a
checklist, as well as the additional tables in Appendix D: Migration Planning Checklists to keep track of switch
configurations, zone information, and port mappings. Migration preparation falls into the following categories:
• Build the new SAN infrastructure
• Configure the SAN
• Validate the new SAN
Table 3. Prepare to Migrate Guidelines
Prepare to Migrate Status Notes
Rack, cable, and power on the destination fabric.
Install Brocade Network Advisor.
Install Brocade SAN Health and discover both Use the SAN assessment and zone import tool.
Brocade and Cisco fabrics.
Set up Ethernet and serial console for the Brocade Refer to individual fabric details.
switches.
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 (see re the Cisco
SAN infrastructure
Appendix A: Migration Use Case Examples).
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).

Note: You should complete the tables defined in Appendix D: Migration Planning Checklists. Even though the fabric build
mechanism assigns Domain IDs (DIDs) to each switch in the fabric, it is a good practice to predefine a DID for each
switch. In the case of migration, it might make sense to use the same DID as the VSAN. If not all of the servers are in
place, and you plan on using Brocade HBAs, use Dynamic Fabric Provisioning (DFP) to create the zones. Refer to the
Brocade Fabric OS 7.0.x Administrator’s Guide; see Appendix F: Reference Material for details. All the servers should be
running with appropriate OS patch levels and applications installed and tested for functionality. On the storage arrays,
LUNs should be created and provisioned according to a storage allocation plan.
PERFORM THE MIGRATION AND VALIDATION

• Execute the migration plan.
• Validate migration per phase.
• Validate application operations per phase.
• Sign off on the SAN migration phase.
When the migration assessment, qualification, and preparation are complete, the SAN can be migrated. Based on the
criteria listed in the previous sections, select the primary migration strategy:
• Offline migration
• Redundant fabric online migration
• Single fabric online migration
Offline Migration
While this requires the fabric to be offline, it is also the safest option for migration. Migrate based on the options
provided in the section on “Migration Methods.” Follow the checklist in Table 4 to minimize the downtime during the
migration.
Table 4. Offline Migration Guidelines
Task Status Notes
Application outage is acceptable.

Completed tasks are defined in the
“Prepare to Migrate” section.
Determine the migration strategy.
Validate device-switch and switch-
switch connection.
Do VSAN to Brocade Virtual Fabric See in Appendix D: Migration Planning
mapping. Checklists
Validate each application.
Redundant Fabric Online Migration

This strategy involves migrating devices by keeping the applications online. This is challenging to facilitate and requires a
great deal of planning. However, if planned properly, and if the key applications that need to remain online are
architected to support high availability and redundancy, then this can be a very effective approach. Migrate based on the
options provided in the section on “Migration Methods.” Follow the checklist provided Table 5 to guide your decisions

about which applications—all, some, or none—are to be migrated online, as desired. The key to this approach is setting
the right expectations in advance.
Table 5. Redundant Fabric Online Migration Guidelines
Task Status Notes
Review Redundant Fabric Online

Migration (“Figure 6. Online Redundant
Fabric Migration”).
Complete the tasks defined in the
“Prepare to Migrate” section.
Determine the migration strategy.
Validate device-switch and switch-
switch connection.
Verify that each fabric is configured to
provide an alternate path to all fabric-
attached devices.
Verify that all paths are open to each
device that must remain online during
the migration.
Select one of the two fabrics for Redirect I/O by performing a failover
migration. to an alternate fabric path.
Close all active paths on the selected
fabric, and prepare single-attached
devices for downtime.
Verify that the selected devices (servers
and storage) are free from I/O activity.
Restore I/O operations on the new
fabric.
Validate that each application and all
the paths are active.
Repeat for all devices or applications.
Complete the Migration

Once the migration activity is complete, it is critical to execute a post-migration plan. There are several steps
to ensuring that all the work you just completed is protected and validated. Some of the post-migration
activities include:
• Run Brocade SAN Health

• Validate new SAN configurations
• Validate application operations
• Back up new SAN configurations
• Sign off on SAN migration
• Retire the Cisco SAN infrastructure

APPENDIX A: MIGRATION USE CASE EXAMPLES

Migrating from a Cisco VSAN to Brocade Virtual Fabrics
Migration Overview
The following procedure describes how to migrate a Cisco VSAN to a Brocade Virtual Fabric (VF). This procedure is
provided to demonstrate the basic setup and configuration of Brocade VF. In this example, all devices from an existing
Cisco VSAN are migrated to a Brocade environment. This is a simple configuration, in which all devices are assumed to
be in the same VSAN fabric and moved to the same Brocade Logical Fabric. There is no device communication between
logical switches.
Figure 7. How to migrate a Cisco VSAN to a Brocade Virtual Fabric.
Tools Required
• Brocade SAN Health, which can be downloaded from www.brocade.com/sanhealth. Brocade SAN Health provides the
capability to generate the zoning statements required to implement zoning in the new Brocade target SAN fabric.
Brocade SAN Health also provides the capability to identify: the VSANs used in each Cisco MDS chassis, the number
of ports in each VSAN, and the specific physical ports assigned to each VSAN. In addition, Brocade SAN Health
provides the capability to create device “migration group” information. This makes it easier to identify all of the
devices associated with a device that is targeted for migration from Cisco to Brocade, so that all associated devices
can be migrated together.
• Brocade Network Advisor, which can be downloaded from the following location: http://my.brocade.com. On the
MyBrocade site, login using your MyBrocade account, navigate to “Downloads,” then “Product Downloads,” and
choose “Brocade Network Advisor” from the pick list. Brocade Network Advisor is the industry's first unified network
management solution for data, storage, application delivery, wireless, and converged networks. It supports Fibre
Channel SANs, Fibre Channel over Ethernet (FCoE), IP switching and routing (including Ethernet fabrics), and Multi-
Protocol Label Switching (MPLS) networks—providing end-to-end visibility across different network types through a
seamless and unified user experience.
• Console connection(s) to the serial ports on the Brocade DCX 8510.

Procedure for Use Case #1

1. To minimize host I/O disruption, migrate one host path at a time. Migrate one of the host and storage paths first
(refer to the device mapping table in in Appendix D: Migration Planning Checklists.
2. Once the first host and storage paths have been migrated to the Brocade logical switch, verify that the host path is
coming up properly by using a multi-path I/O application.
After the first host path has been verified in the Brocade logical switch, start moving the first path for all other host
servers by repeating Steps 1 and 2.
3. After the first paths have been verified for all hosts, start moving the second path.

During the first host and storage path migration to the Brocade logical switch, other hosts still residing in the Cisco
VSAN fabric see a lost path to storage. However, the host path will fail over properly, and all LUNs will still be
available during the migration.
4. Use a multi-path I/O application on each host to verify that all paths are operating normally (EMC PowerPath is
shown here as an example).
Migration Procedure
In the use case below, you will see how to migrate from a redundant online Cisco fabric with VSANs to a Brocade SAN
with Brocade Virtual Fabrics. Though neither single-fabric online nor offline migrations are covered in this example, the
steps below describe how to install and capture the Cisco zone database using Brocade SAN Health and how to create
Brocade Virtual Fabrics, if needed, to reduce the time for migration. It is recommended that no zoning is done when the
migration process is initiated.
The following steps show how to capture the zone database of a Cisco environment and migrate it to a Brocade
environment.
Capture and Migrate the Zone Database

You will need Brocade SAN Health v3.2.6c or later, which can be downloaded from the following location:
www.brocade.com/sanhealth.

Enhancements to Brocade SAN Health v3.2.6c include the following:
• Brocade SAN Health provides the capability to generate the zoning statements required to implement zoning in the
new Brocade target SAN fabric.
• Brocade SAN Health provides the capability to identify the VSANs used in each Cisco MDS chassis, the number of
ports in each VSAN, and the specific physical ports assigned to each VSAN.
• Brocade SAN Health provides the capability to create device “migration group” information. This makes it easier to
identify all of the devices associated with a device that is targeted for migration from Cisco to Brocade, so that all
associated devices can be migrated together.
Survey the MDS Fabric and Prepare for the Migration

1. From a server with Cisco Fabric Manager installed, launch Fabric Manager and open the fabric to manage.
2. Select the fabric to be managed and click Open.
3. To survey the VSAN configuration on a particular MDS switch, using the Device Manager application, choose VSANs
from the FC.

4. Note: The Cisco MDS Device Manager is similar to Brocade Web Tools, in that it is accessed from the switch.
Depending on the version of code running on the MDS switch, you can install Device Manager simply by pointing
your web browser to the IP address of the MDS switch to install the application. You need the login and password for
the MDS switch in question. Brocade Network Advisor provides comprehensive management of data center fabrics.
From the VSAN window, click the Membership tab to view the list of ports belonging to each VSAN configuration.
5. After verifying the VSAN fabric information, view VSAN device zoning. Record the zoning of all devices in the
VSAN so that you can accurately replicate them after the migration. From the main menu, choose
Zone > Edit Local Full Zone Database.
6. Select a different VSAN from the Select VSAN drop-down menu.

7. The device zoning information is displayed in the Cisco Fabric Manager.
8. Verify VSAN host connectivity. Before the migration, it is strongly recommended that the host have dual LUN
paths for redundancy. Use a failover application (for example, EMC PowerPath) to verify each LUN path.
9. Run Brocade SAN Health v3.2.6c or later on the Cisco MDS Fabric.
Once all the basic information is gathered from the VSAN environment, go to the Brocade web site to download
the Brocade SAN Health tool (http://www.brocade.com/services-support/drivers-downloads/san-health-
diagnostics/index.page), and run an audit on the VSAN fabric. This report is very useful in generating new
Brocade device zoning information, especially in a large environment.

10. Define and upload the zone database.

Get zoning sets from Brocade SAN Health, shown in the Brocade SAN Health zoning report.
Submit the Brocade SAN Health auditing data to the Brocade SAN Health team to generate a zoning script for
the Brocade DCX platform.
The MDS VSAN configuration and device information gathered are used to create zoning in the Brocade DCX
environment, with the help of Brocade SAN Health. The device information and zoning script syntax generated
from Brocade SAN Health are compared to the original VSAN environment. The zoning script generated from
Brocade SAN Health is ready to use without modification. The modification step in this section is optional, and it
is added to make the zoning name a little cleaner.
Please note that the zoning aliases generated may contain VSAN names. Zoning script can be modified to
remove any VSAN reference in the zoning name. The administrator may decide to clean up the zones of
redundancy or non-existence of devices before implementing the zones; the goal would be to implement the
zoning definitions for the devices that are to be moved.
The migration can be accomplished either in single or multiple zones, using a phased approach. If the device to
be moved exists only in the zones that are identified, you can proceed with migrating the zones to the new
Brocade SAN fabric. If the devices to be moved happen to belong to zones other than the zone that is migrated,
then you have to expand the migration list.
Enable and Configure Brocade Virtual Fabrics

1. Install and launch Brocade Network Advisor 11.x, which can be downloaded from the following location:
http://my.brocade.com. On the MyBrocade site, login using your MyBrocade account, navigate to “Downloads,”
then “Product Downloads,” and choose “Brocade Network Advisor” from the pick list.
2. Verify that Brocade Virtual Fabrics (VF) is enabled. If VF is not enabled, you can enable this feature via either the
fosconfig cli command or through Brocade Network Advisor, which is used in this example.
3. Note: This reboots the switch, so you should pre-enable VF.
4. Have console connection(s) to the serial ports on the Brocade DCX.
Note: if Brocade FOS 7.0.x or Gen 5 Fibre Channel Brocade DCX 8510 is involved with your MDS migration, you
will need Brocade Network Advisor, as Brocade Data Center Fabric Manager (DCFM®) does not support either
of these.

5. Launch Brocade Network Advisor.
6. After bringing up Brocade Network Advisor, you need to discover the Brocade DCX. From there, if Brocade Virtual
Fabrics is not enabled by default, right-click the Brocade DCX icon and choose Enable Virtual Fabric from the
right-click menu.
7. If your Brocade DCX does not have VF enabled, you will see the following pop-up window from Brocade Network
Advisor 11.x:

If this is a “greenfield” installation, and there are no EX ports, then click OK at this time. As you can see, all
ports are placed into the default logical switch. For this reason, as part of best practice, you should run the
fosconfig –show command beforehand or enable VF, with no devices attached at this point.
8. When the Brocade DCX reboots, VF is enabled. If you logged into this DCX, you see that the default FID of 128 is
part of the switch name. From Brocade Network Advisor, you see that above the DCX there is a “V,” as shown
below.
Create the Logical Switch

For the migration, you can certainly use the Brocade VF Default Switch, but this you should have decided this as part
of the planning process for the VF configuration. Here is the process of creating a logical switch on a Brocade DCX.
1. Right-click on the logical switch within Brocade Network Advisor, and then select Configuration -> logical
switches. You are presented with the following window.
2. In the logical switches dialog box, select Undiscovered Logical Switches and click New Switches.

3. In the New logical switch dialog box, uncheck the Base Fabric for Transport checkbox, enter 127 in the Logical
Fabric ID text box, and make sure that Brocade Native is chosen from the Interoperability Mode drop-down menu
at the bottom left. Here, with Brocade FOS v7, it is grayed out.
4. To assign ports to the newly created logical switch, from the left panel, select the ports and click the right arrow
to assign them.
5. After the ports have been assigned to this logical switch, as shown below, click OK.

6. In the confirmation dialog box, check Re-Enable ports after moving them and QoS disable the ports while
moving them (these are the defaults). Click Start.
Note: In the “Progress” box, you see a message saying “In Progress.”
7. Logical switch 127 has been created successfully, as shown below.
Click Close.

8. The newly created logical switch is discovered by Brocade Network Advisor (Discover > Fabrics> Add button).
Enter the appropriate information to discover the newly configured logical switch, as shown below.
Click OK and then click Close, and you will see logical switch 127 from the Discover Setup and main Brocade
Network Advisor windows.

Note: If Brocade Virtual Fabrics is not enabled by default for the Brocade DCX, it can be done from Brocade
Network Advisor or the Brocade FOS 7.x command line. As the warning message indicates, this is disruptive—
the Brocade DCX is rebooted and all ports are persistently disabled. Once Brocade Virtual Fabrics is enabled, the
default logical switch can be created with FID = 128 and all ports in the chassis initially assigned to it. Other
logical switches can be created from Brocade Network Advisor, and ports can be moved from the default logical
switch to other logical switches.
As part of an MDS–DCX migration, it is suggested that you assign the logical switch FID with the same number as the
MDS VSAN that is being migrated.
9. As part of a migration best practice, it is good to save the existing configuration on your newly created logical
switch 127. From Brocade Network Advisor, right-click on the logical switch, and choose Configuration > Save to
get the following window.
Highlight the logical switch and click OK.
Import Brocade SAN Health Zone Configuration to Your Logical Switch

1. To import Brocade SAN Health zoning information, open a telnet session to a Brocade DCX, and verify the
information for logical switches using the lsCfg command.

2. From the default logical switch 128, execute the following commands to change to logical switch 127 and verify
the zoning configuration.
3. From logical switch 127, copy and paste the SAN Health zoning script in the Brocade DCX CLI (Command-Line
Interface).
Create the zone aliases.
sw1:FID127:root> alicreate "DMX4_16CB", "50:06:04:8a:d5:f0:c5:af"
sw1:FID127:root> alicreate "DMX4_1CB", "50:06:04:8a:d5:f0:c5:a0"
sw1:FID127:root> alicreate "Host2_A", "10:00:00:05:1e:7e:9e:ab"
sw1:FID127:root> alicreate "Host2_B", "10:00:00:05:1e:7e:9e:ac"
sw1:FID127:root> alicreate "Host3_A", "10:00:00:00:c9:69:c2:ba"
sw1:FID127:root> alicreate "Host3_B", "10:00:00:00:c9:69:c2:bb"
Create and populate the zones with the devices that will be migrated.
sw1:FID127:root> zoneCreate "Zone1", "DMX4_16CB; Host2_B"
sw1:FID127:root> zoneCreate "Zone2", "DMX4_1CB; Host2_A"
sw1:FID127:root> zoneCreate "Zone3", "DMX4_16CB; Host3_B"
sw1:FID127:root> zoneCreate "Zone4", "DMX4_1CB; Host3_A"
Create and populate the zoneset.sw1:FID127:root> cfgCreate "Zoneset1", "Zone1; Zone2; Zone3; Zone4"
Enable the zoneset on your logical switch.
sw1:FID127:root> cfgEnable "Zoneset1"
You are about to enable a new zoning configuration.
This action will replace the old zoning configuration with the current
configuration selected. If the update includes changes to one or more traffic
isolation zones, the update may result in localized disruption to traffic on ports
associated with the traffic isolation zone changes.
Do you want to enable 'Zoneset1' configuration (yes, y, no, n): [no] y zone
config "Zoneset1" is in effect
Updating flash ... sw1:FID127:root>

Note: Zones, WWNs (World Wide Names), and aliases are for reference only and will be different for your
environment.
After the zoning script has been run, verify that the Brocade DCX zoning configuration has been enabled, and
that zoning configuration data for the new Brocade SAN fabric is accurate, with the cfgShow command.
You can also verify the zoning configuration through Brocade Network Advisor. Right-click Logical Switch 127 in
the topology view, and choose Zoning from the right-click menu.
In the Zoning window, choose LS127 from the Zoning Scope drop-down menu to display zoning information.
Note: Brocade SAN Health can audit a Cisco MDS environment to generate a report. With that report, a zoning
script is generated, which can then be copied and pasted in the Brocade DCX CLI. This is extremely useful if a
large zoning database needs to be imported. Zoning information can then be verified using either the CLI or
Brocade Network Advisor.

APPENDIX B: ADDITIONAL CONSIDERATIONS FOR BLADE SERVERS USING NPIV

This section provides guidance on blade servers using an embedded N_Port ID Virtualization (NPIV) switch for
SAN connectivity.
Blade servers are comprised of multiple servers in a single blade server chassis. Blade server form factors using a
modular design are easier to manage and are optimized to use minimal space and energy. These servers are
typically connected to SAN fabrics using SAN switches embedded into the chassis using NPIV technology. The use of
embedded switches in NPIV mode multiplexes host connections to the fabric and allows seamless server
connectivity to any vendor’s SAN fabric. Thus, blade server embedded switch modules operating in NPIV mode can
interoperate seamlessly with a new and different SAN. The switch presents its downlink as an F_Port to the host and
as an uplink N_Port to an edge fabric switch. Multiple F_Ports can be mapped to an uplink N_Port, and the servers
use the mapped N_Ports to connect to the SAN.
The high level-steps required for this type of migration are as follows:
1. As with the process of migrating standalone servers, capture the zoning information from the Cisco MDS SAN
and propagate the appropriate zoning information in the target Brocade SAN.
2. Reconfigure the mapping within the NPIV embedded switch to group the servers that will be migrated to the
uplink N_Port(s) that are connected (or will be connected) to the Brocade SAN.
3. Place these N_Port(s) into a port group to ensure that failover for the servers assigned to this N_Port cannot
occur back to any of the other N_Ports that are connected to an older SAN fabric. As a policy, all the uplinks in
this port group should be connected to the new SAN fabric, so that failback/failover within the port group occurs
within the same new fabric.
4. Connect unused uplink N_Ports (or N_Ports being migrated) from the NPIV embedded switch to the new Brocade
SAN fabric switch. Note that reconfiguring uplinks may be disruptive if those uplinks are being utilized by online
applications. Moving a cable associated with a specific N_Port on the blade server switch module connects all
server blades associated with that N_Port to the new SAN.
5. You can now relocate the N_Port to the new Brocade SAN, with its target storage.
6. You can relocate the secondary path from the blade server following the sequence of steps noted here.
7. You should use “port grouping” and “disabled failover” to prevent the hosts from connecting back to the old
fabric due to a connection failure on the N_Port during reconfiguration.

APPENDIX C: ADDITIONAL CONSIDERATIONS FOR THE VMWARE ENVIRONMENT

This section provides guidance on using VMware to implement migration.
Figure 8. Migrating Applications and VMs to a Brocade SAN using VMware.
You can use VMware ESX tools such as vMotion and Storage vMotion to migrate applications and virtual machines to
the servers that are connected to Brocade SAN. The high-level steps required for this type of migration are as follows:
1. Add a new ESX server to the ESX cluster.
2. Connect the new ESX server to the new Brocade SAN fabrics.
3. Follow the steps in Appendix A to migrate zones and configure Brocade SAN fabrics.
4. Using open fiber adapters on the disk array, connect the new Brocade SAN to the existing disk array that
contains the virtual machine data stores. You can use Storage vMotion in this type of migration, if new disk
arrays are being deployed with Brocade SAN fabrics.
5. Use vMotion to migrate virtual machines to the ESX servers that are connected to the new Brocade SAN.

APPENDIX D: MIGRATION PLANNING CHECKLISTS

This section provides example checklists and tables you can use to identify dominant factors, including facilities that
have an impact on the SAN migration.
Current Fabric Assessment

# of
# of Type of Total # of Storage
SAN/Fabric Switches Switches Ports Domains Servers Devices Location Notes
Fabric 1
Fabric 2
Fabric n
Individual Fabric Details

Brocade
Domain Serial IP FOS
SAN/Fabric Number Number Model Speed WWN Address Version Notes
Switch 1
Switch 2
Switch 3
Switch n
Device Details
Servers & OS Fabric/
Storage Vendor Model WWN Alias Zone Version Application Switch Notes
Server 1
Server 2
Server n
Storage 1
Storage 2
Storage n

Consolidated SAN Snapshot

SAN Requirements Data (Complete for Each SAN)
Fabric Information
Target # of user ports per fabric

Target # of total ports per fabric
Target # of switches per fabric (# switches/switch
type, total switches)
# of fabrics
# of sites in environment
Topology (core/edge, ring, mesh, other)
Maximum hop count
Expected growth rate (port count)
Fabric licenses
SAN Device Information
#/types of hosts and OS platforms

#/types of storage devices
#/types of tapes
#/types of HBAs
Other devices (VTL/deduplication appliance)
Total # of SAN devices per fabric
Customer requirements for failover/redundancy,
reliability of SAN (multi-pathing software utilized)
Application Details
SAN Application (storage consolidation, backup
and restore, business continuance)
Fabric management application(s)
Performance
Maximum latency (ms)
Targeted ISL oversubscription ratio (3:1, 7:1,
15:1, other)

Device Mapping Details

Application Cisco Brocade
Device Domain Port Zone Host Domain Port Zone
Host
Application Storage Array
Name
Backup
(Tape/VTL)
Comments:
Application-Specific Details
Backup/Restore infrastructure
Servers
System OS Version, Patch Level HBA Driver Version
Server 1/HBA
Server 2/HBA
Server 3/HBA
Backup Software
Vendor Version Patch

FC Switch
Vendor Model Firmware
Brocade
Storage
Array 1
Array 2
Tape Library

Library
Note: It is helpful to keep a similar table for each application.

APPENDIX E: TERMINOLOGY
Term Brief Description
48K Brocade 48000 Director, 8-slot modular chassis

Base Switch Base switch of an enabled Brocade Virtual Fabrics mode switch
DCX Brocade DCX Backbone, 8-slot modular chassis
DCX-4S Brocade DCX-4S Backbone, 4-slot modular chassis
DCX 8510 Brocade DCX 8510 Backbone with Gen 5 Fibre Channel, 8- or 4-slot modular chassis
Default switch Default switch of an enabled Brocade Virtual Fabrics mode switch
E_Port A standard Fibre Channel mechanism that enables switches to network with each other
Edge-Hold-Time Enables the switch to time out frames for F_Ports sooner than for E_Ports
EX_Port A type of E_Port that connects a Fibre Channel router to an edge fabric
F_Port A fabric port to which an N_Port is attached
FC-IP Fibre Channel over IP, which enables Fibre Channel traffic to flow over an IP link
FCR Fibre Channel Routing, which enables multiple fabrics to share devices without having
to merge the fabrics
IFL Inter-Fabric Link, a link between fabrics in a routed topology
ISL Inter-Switch Link, used for connecting fixed port and modular switches
LS Logical switch of an enabled Brocade Virtual Fabrics mode switch
Oversubscription A condition in which more devices might need to access a resource than that resource
can fully support
Port group A set of sequential ports defined (for example, ports 0–3)
QoS Quality of Service traffic shaping feature that allows the prioritization of data traffic
based on the SID/DID of each frame
Redundant Duplication of components, including an entire fabric, to avoid a single point of failure in
the network (Fabrics A & B are identical)
Resilient Ability of a fabric to recover from failure, could be in a degraded state but functional (for
example, ISL failure in a trunk group)
TI Zone Traffic Isolation Zone, which controls the flow of interswitch traffic by creating a
dedicated path for traffic flowing from a specific set of source ports
Trunk Trunking, allowing a group of ISLs to merge into a single logical link enabling traffic to be
distributed dynamically at the frame level
UltraScale ICL UltraScale Inter-Chassis Link, used for connecting modular switches without using front-
end device ports
VC Virtual Channel, which creates multiple logical data paths across a single physical link or
connection
VF Brocade Virtual Fabrics, a suite of related features that enable customers to create a
logical switch, a Logical Fabric, or share devices in a Brocade Fibre Channel SAN

APPENDIX F: REFERENCE MATERIAL

Software and Hardware Product Documentation
• Brocade Fabric OS v7.1.0x Release Notes
• Brocade Fabric OS Administrator’s Guide, supporting Brocade FOS v7.1.0
• Brocade Fabric OS Command Reference Manual, supporting Brocade FOS v7.1.0
• Brocade Fabric Watch Administrator’s Guide, supporting Brocade FOS v7.1.0
• Brocade Access Gateway Administrator’s Guide, supporting Brocade FOS v7.1.0
• Brocade Fabric OS Troubleshooting and Diagnostics Guide, supporting Brocade FOS v7.1.0
• Hardware Reference Guides and QuickStart Guides for backbone, director, switch, and blade platforms
Technical Briefs
• www.brocade.com/data-center-best-practices/resource-center/index.page
• www.brocade.com/products/all/san-backbones/product-details/dcx8510-backbone/specifications.page
• www.brocade.com/solutions-technology/technology/platforms/fabric-os/virtual_fabrics.page
Brocade Compatibility Matrix

• www.brocade.com/forms/getFile?p=documents/matrices/compatibility-matrix-fos-7x-mx.pdf
Brocade Scalability Guidelines

• www.brocade.com/forms/getFile?p=documents/matrices/compatibility-matrix-fos-7x-mx.pdf
Brocade SAN Health Support Matrix

• www.brocade.com/forms/getFile?p=documents/matrices/SANHealthSupportMatrix.xls
Brocade FOS Features

• www.brocade.com/forms/getFile?p=documents/brochures/FabricOS_Guide.pdf
Brocade Network Advisor

• www.brocade.com/products/all/management-software/product-details/network-advisor/index.page
Brocade Bookshelf
• Principles of SAN Design (updated in 2007) by Josh Judd
• Strategies for Data Protection by Tom Clark
• Securing Fibre Channel Fabrics by Roger Bouchard
• The New Data Center by Tom Clark
Other
• www.brocade.com/solutions-technology/enterprise/migration/index.page?
• www.snia.org/education/dictionary
• www.vmware.com/files/pdf/techpaper/SAN_Design_and_Deployment_Guide.pdf
• www.vmware.com/files/pdf/vcb_best_practices.pdf

© 2013 Brocade Communications Systems, Inc. All Rights Reserved. 07/13 GA-TB-408-02
ADX, AnyIO, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, ICX, MLX, MyBrocade, OpenScript, VCS, VDX, and Vyatta are
registered trademarks, and HyperEdge, The Effortless Network, and The On-Demand Data Center are trademarks of Brocade
Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may
be trademarks of their respective owners.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any
equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this
document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may
not be currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data
contained in this document may require an export license from the United States government.

SAN Migration Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SAN Migration Guide

Caricato da

Copyright:

Formati disponibili

DATA CENTER

SAN Migration Guide:

Cisco to Brocade SAN Migration Guide 2 of 41

Appendix B: Additional Considerations for Blade Servers Using NPIV......................................................................................................................... 34

Cisco to Brocade SAN Migration Guide 3 of 41

AUDIENCE AND SCOPE

Cisco to Brocade SAN Migration Guide 4 of 41

·∙ Is this technically feasible? (custom

Define Migration ·∙ Define project scope and success criteria

Migration ·∙ Existing topology

Choose the ·∙ Fabric strategy: Online or Offline

Develop the ·∙ Includes: phases, dependencies, resources,

·∙ Build new SAN infrastructure

Figure 1. Migration Process

Cisco to Brocade SAN Migration Guide 5 of 41

DEFINE MIGRATION GOALS

Fabric(s) Consolidation: Higher density and higher performing switches

Special Purpose SAN Architectures

Cisco to Brocade SAN Migration Guide 6 of 41

• Do you need the same number of ports?

Figure 2. Fabric Consolidation for a 1000-port SAN

Cisco to Brocade SAN Migration Guide 7 of 41

Building a Private Storage Cloud

• Hyperscale fabrics in terms of ports and performance

Figure 3. Large-Scale Cloud Storage Architecture

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

• Assessing the existing fabric topology

Cisco to Brocade SAN Migration Guide 8 of 41

ASSESS THE EXISTING FABRIC TOPOLOGY

Figure 4. Fabric Topologies

Some things to consider when assessing the migration activity include:

Cisco to Brocade SAN Migration Guide 9 of 41

Assessing the New Fabric

Logistic Planning of Hardware Installation

Topology and Zone Planning

Preliminary Migration Planning

Cisco to Brocade SAN Migration Guide 10 of 41

Establish post-migration verification criteria:

• Total number of devices in the fabric

GATHER INFRASTRUCTURE INFORMATION

At a minimum, complete the following tables as listed in in Appendix D: Migration Planning:

• Individual Fabric Details

Cisco to Brocade SAN Migration Guide 11 of 41

CHOOSE THE MIGRATION STRATEGY

• Online Redundant Fabric Migration

SAN Migration Strategy

Revisit the Migration Redundant Is there a SAN Revisit the Migration

Follow “Offline Downtime

All dual-path devices Review the impact of Tier

Validate multi-path Yes

Are all the redundant

Is performance Can the fabric be taken

Figure 5. SAN Migration Strategy

Cisco to Brocade SAN Migration Guide 12 of 41

Online Redundant Fabric Migration

Online Redundant Fabric

Follow the steps for “Offline

Ensure that all paths are

Select a fabric for migration,

Follow the steps for “Offline

Restore the I/O paths on the

Verify that the fabric

Conduct a final verification

Figure 6. Online Redundant Fabric Migration