Migration Procedures


This chapter describes the migration procedures from the RecoverPoint environment to the new Cisco platform and includes the following sections:

Migration Guidelines

Software Upgrade

Hardware Upgrade

Migration Guidelines

Migration to the new platform involves both a software upgrade and a hardware upgrade. The software upgrade is a prerequisite for the hardware upgrade and has to be performed first.

As a best practice, RecoverPoint with SANTap should be deployed in a dual-fabric configuration. This deployment allows the upgrade procedure to be nondisruptive to the host application, and it can be performed on one fabric at a time. In a single fabric environment, when the hardware upgrade is performed, the application servers lose access to the target LUNs (which are in the second path). In a dual environment, the upgrade is performed on one path at a time. The application servers lose only the path being upgraded, and the traffic is routed on the other path with no disruption for the application. Once the software and hardware upgrade is complete, the upgraded path can be manually or automatically restored using the host multipathing software, and the upgrade on the second path can be performed.

Software Upgrade

This section describes the procedures for the software upgrade of MDS switches with the SSM running SANTap. The software upgrade is a prerequisite for the hardware upgrade in the migration to the MSM-18/4 and the MDS 9222i switch.


NoteThe MSM-18/4 and the MDS 9222i switch base module that is integrated in slot 1 can be used for provisioning SANTap only upon upgrading to NX-OS 4.x and equivalent SSI image.

To upgrade to NX-OS Release 4.1(1b) from SAN-OS Release 3.2(3a) or earlier, it is necessary to upgrade to SAN-OS Release 3.3(2) and then to NX-OS Release 4.1(1b).

The software upgrade is a three-step process; if you want to run SANTap on the MDS 9222i switch slot 1, an additional step is required. (Refer to Step 4)


Refer to the following links for more information:

http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/4_1/release/notes/17675_02.html#wp353739

http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/4_1/ssi/upgrade/guide/SSIupgd.html


Table 2-1 lists the comatibility matrix for Cisco MDS SAN-OS and Cisco NX-OS and the corresponding SSI image.

Table 2-1 Compatibilty Matrix

SAN-OS / NX-OS
Equivalent SSI Image

3.2.2c

3.2.3t

3.2.2

3.2.3t

4.1.1b

4.1.1x



NoteCurrently, 4.1(1x) can refer to either 4.1(1i) or 4.1(1j). Refer to the Cisco MDS NX-OS Release Compatibility Matrix for Storage Service Interface Images for the latest supported version at the following URL:

http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/4_1/ssi/matrix/SSImtx.html

RecoverPoint supported versions are from 3.1(1) (3.1, Service Pack 1) onwards (for example 3.1(2)). This guide documents the migration procedures using 3.1(1).


To complete the software upgrade process, follow these steps:


Step 1 Verify prerequisites. Ensure that you meet the following required prerequisites:

An operational dual fabric is required both at the production site and at the mirror site.

The RecoverPoint software has been upgraded at all sites. Refer to the EMC RecoverPoint Installation Guide for upgrading to the 3.2 RecoverPoint version.

The appropriate versions of the software have been downloaded. Refer to EMC RecoverPoint Release Notes for the RecoverPoint version you are using to determine the version of the system image, kickstart image, and software services interface image required (in this case, Cisco NX-OS Release 4.1(1b) with SSI 4.1(1i)). Download the required version of the files from this link:

www.cisco.com

or

http://powerlink.emc.com

At each RecoverPoint site, the switch hardware and software upgrade should be completed first on one fabric, then on the other fabric. In order to keep hosts and I/O operational, an I/O path to the second switch must be available when one switch is being upgraded.


Note From this point on, all instructions refer only to the fabric being upgraded.


Step 2 Upgrade from SAN -OS Release 3.2(2x) (for example, Release 3.2(2c) to Release 3.3(2), by following these steps:

a. In the RecoverPoint Management Application, select each SANTap splitter on the fabric you are upgrading, detach all volumes from the splitter, then remove the splitter. Repeat these steps for all the SANTap splitters on the fabric being upgraded. If the splitter is not removed initially, RecoverPoint displays a warning message and checks for the old Cisco Virtual Initiators entries (9 Cisco Virtual Initiators) even after rezoning the RecoverPoint target ports with the new Cisco Virtual Initiators entries (3 Cisco Virtual Initiators).

b. Stop all the firewall programs on the management workstation.

c. Start an FTP server on the management workstation connected to the switch.

d. Make a backup copy of the running configuration file (<file_name> on the bootflash) at an FTP or TFTP location.

e. Copy the the system, kickstart, and SSI files that you wish to install. Use the following commands to check the space available, clean up unused files (if required) and copy the new ones:

switch# dir bootflash:
switch# delete bootflash:filename
switch# copy ftp://ftp server IP address/ source filename bootflash:destination 
filename
switch# dir bootflash: 

f. Use the following command to keep track of the CVT pWWN and nWWN information at the SANTap command line interface:

switch# show santap module # of slot running SANTap cvt


The output of this command should be in the following format:

CVT Information :

cvt pwwn     = 23:4b:33:33:33:33:33:36
cvt nwwn     = 23:4b:33:33:33:33:34:36
cvt id       = 0x89e909c
cvt xmap_id  = 0x89f1f74
cvt vsan     = 2
cvt name     = CENV4_PROD_CVT 

g. Record the CVT pWWN and the CVT nWWN.

h. Keep track of the WWNs in each VSAN and store them for future reference. Capture the output of the following command:

switch# show fcs database 

i. Use the install all command to upgrade from SAN-OS Release 3.2(2x) to Release 3.3(2)

switch# install all system bootflash:m9200-s2ek9-mz.3.3.2.bin kickstart 
bootflash:m9200-s2ek9-kickstart-mz.3.3.2.bin ssi bootflash:m9000-ek9-ssi-mz.3.2.3t.bin

j. Verify if the installation is successful by entering the commands shown in the following examples:

switch# show install all status
switch# show version internal build-identifier 
Kickstart image file: bootflash:///m9200-s2ek9-kickstart-mz.3.3.2.bin :  S12
System image file: bootflash:///m9200-s2ek9-mz.3.3.2.bin :  S12
Linecard1 image build-id:  S12
Linecard2 image build-id:  S12
Linecard IPS addon image build-id:  S12
Module 1 SSI SAN-OS packaged image build-id:  S12
Module 2 SSI image file: modflash://2-1/m9000-ek9-ssi-mz.3.2.3t.bin :  S13

switch# show module
Mod      Application Image Description       Application Image Version
-------- -----------------------------       -------------------------
2        SSI linecard image                  3.2.3t                  

Step 3 Upgrade from SAN-OS Release 3.3(2) to NX-OS Release 4.1(1b) by following these steps:

a. Use the install all command to upgrade from SAN-OS Release 3.2(2) to NX-OS Release 4.1(1b).

switch# install all system bootflash:m9200-s2ek9-mz.4.1.1b.bin kickstart 
bootflash:m9200-s2ek9-kickstart-mz.4.1.1b.bin ssi 
bootflash:m9000-ek9-ssi-mz.4.1.1i.bin

b. Verify if the installation is successful by entering the commands shown in the following examples:

switch# show install all status

switch# show version internal build-identifier 
Kickstart image file: bootflash:///m9200-s2ek9-kickstart-mz.4.1.1b.bin :  S1
System image file: bootflash:///m9200-s2ek9-mz.4.1.1b.bin :  S1
Linecard1 image build-id:  S1
Linecard2 image build-id:  S1
Linecard IPS addon image build-id:  S1
Module 1 SSI SAN-OS packaged image build-id:  S1
Module 2 SSI image file: modflash://2-1/m9000-ek9-ssi-mz.4.1.1i.bin :  S24

switch# show module
Mod      Application Image Description       Application Image Version
-------- -----------------------------       -------------------------
2        SSI linecard image                  4.1(1i)

Step 4 Upgrade the base module of the MDS 9222i switch from NX-OS Release 4.1(1b) to NX-OS 4.1(1i) by following these steps:


Note Step 4 applies only to the MDS 9222i switch and SANTap must be provisioned on slot 1.


a. Use install all command to upgrade the base MDS 9222i switch module without the other extended option of the command.

switch# install all ssi bootflash:m9000-ek9-ssi-mz.4.1.1i.bin

b. Verify if the installation is successful by entering the commands shown in the following examples:

switch# show version internal build-identifier 
Kickstart image file: bootflash:///m9200-s2ek9-kickstart-mz.4.1.1b.bin :  S1
System image file: bootflash:///m9200-s2ek9-mz.4.1.1b.bin :  S1
Linecard1 image build-id:  S1
Linecard2 image build-id:  S1
Linecard IPS addon image build-id:  S1
Module 1 SSI image file: modflash://1-1/m9000-ek9-ssi-mz.4.1.1i.bin :  S24
Module 2 SSI image file: modflash://2-1/m9000-ek9-ssi-mz.4.1.1i.bin :  S24

switch# show module
Mod      Application Image Description       Application Image Version
-------- -----------------------------       -------------------------
1        SSI linecard image                  4.1(1i)                         
2        SSI linecard image                  4.1(1i) 


Hardware Upgrade

The MSM-18/4 and the MDS 9222i switch have only one virtualization engine (one data path processor [DPP]), while the SSM has eight DPPs. Therefore, it is not required to partition the hosts in different VSANs to use all the DPPs. You may want to merge all the hosts in one single front end VSAN and remove the others if not required.

Refer to the commands listed in Appendix A, "Licensing and Commands" or refer the configuration guide at the following URL:

http://cisco.com/en/US/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/cli_4_1/clibook.html

This section includes the following topics:

Upgrading SANTap from SSM to MSM-18/4 for Same Slot in the Same Chassis

Upgrading SANTap from SSM to MSM-18/4 for Different Slot in the Same Chassis

Upgrading SANTap from SSM to Base 9222i on the Same Chassis

Upgrading SANTap from SSM to MSM-18/4 or 9222i for Chassis to Chassis

Upgrading SANTap from SSM to MSM-18/4 for Same Slot in the Same Chassis

To complete the hardware upgrade of SANTap from the SSM to the MSM-18/4, follow these steps:


Step 1 Verify that the NX-OS version is Release 4.1(1b) and SSI version is Release 4.1(1i) on the switch where the SSM is currently provisioned with SANTap and is fully configured with EMC RecoverPoint.

switch# show version internal build-identifier 

Step 2 Verify that the installed version of RecoverPoint is compatible with the proposed upgrade. The current upgrade example requires RecoverPoint 3.1.1 (3.1, Service Pack 1). There are two options to verify the RecoverPoint version:

In the RecoverPoint Management Application, go to the menu bar, select Help > About RecoverPoint Management Application. A dialog window appears.

Verify that the RecoverPoint version is 3.1 and Service Pack 1 is displayed in the dialog window.

At the RecoverPoint command-line interface, enter the following command:

switch# get_version

Note In the RecoverPoint Management Application, verify that RecoverPoint is replicating without errors.


Step 3 Save the running configuration (ASCII format) from the MDS switch provisioned with SANTap to the switch bootflash. Make a backup of the running configuration (<file_name> on the bootflash) to an FTP or TFTP location.

switch# copy running-config startup-config 
[########################################] 100%
switch# copy running-config  bootflash:run-0430

Step 4 Copy the information related to SANTap configuration from the ASCII configuration to restore the same configuration on the MSM-18/4 later.

a. Enabling SANTap on the module

switch# show file bootflash:run-0430 | i ssm 
ssm enable feature santap module 5

b. CVT information (with WWNs)

switch# show file bootflash:run-0430 | i cvt
santap module 5 appl-vsan 40 cvt-name CVT-MOD5-ST2 cvt-nwwn 22:81:00:0d:ec:3c:7e:02 
cvt-pwwn 22:7e:00:0d:ec:3c:7e:02
santap module 5 appl-vsan 41 cvt-name CVT2-MOD5-ST2 cvt-nwwn 22:95:00:0d:ec:3c:7e:02 
cvt-pwwn 22:94:00:0d:ec:3c:7e:02

c. DVT information (with WWNs)

switch# show file bootflash:run-0430 | i dvt
santap module 5 dvt target-pwwn 50:06:04:82:ca:fd:a0:93 target-vsan 40 dvt-name 
DVT-4BA dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:04:82:ca:fd:a0:b3 target-vsan 40 dvt-name 
DVT-4BB dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:0e:80:04:5a:0e:1a target-vsan 40 dvt-name DVT-2L 
dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:0e:80:04:5a:0e:5a target-vsan 41 dvt-name DVT-6L 
dvt-vsan 31


NoteIf the CVTs were created without providing a cvt-name during initial configuration, then the cvt-nwwn and the cvt-pwwn will not be a part of the running configuration. In such cases, the cvt-wwn and cvt-pwwn must be copied from the CLI output of show santap module x cvt command.

Even if the DVTs were created without a dvt-name during the initial configuration, the dvt-name will still be a part of the running configuration. In such cases, the dvt-name needs to be edited or removed from the command syntax before applying the command.


Step 5 Remove the SSM from the chassis (slot 5).

At this point, the RecoverPoint Appliance will lose its connection to the splitter. The hosts will also lose its path to the target port because the SANTap process is removed along with the SSM from the chassis.

Step 6 Insert the new MSM-18/4 to the same slot (slot 5) in the chassis and verify the new module comes up with module status OK.


Note If the MSM-18/4 is inserted in the same slot (slot 5), then all SANTap pertinent information will be automatically removed from the switch.


Step 7 Load the supported SSI image Release 4.1(1i) on the newly inserted MSM-18/4 module and verify that the installation has been successful.

switch# install all ssi bootflash:m9000-ek9-ssi-mz.4.1.1i.bin

Verify the install is successful:

switch# show module


Note The install all ssi command will install the SSI image on all the intelligent modules (SSM, MSM 18/4) that are present in the switch and in addition the module that was replaced. You can verify the installations by entering the show install all status command.


Step 8 Install the new license file for enabling and restoring SANTap services on the MSM-18/4. By default, a 120- day grace period for the SANTap process will be enabled in the absence of a SANTap license for the MSM-18/4 module.

switch# install license bootflash:SSE_licensefile

Restore the SANTap configuration from the saved running configuration. (ASCII format)

For more information on licensing, refer to Appendix A, "Licensing and Commands."

Copy and paste the following configuration commands saved from Step 4:

switch(config)# show ssm provisioning 
switch(config)# show santap module 5 cvt brief
switch# show santap module 5 dvt brief


Verify that the command is executed after every step before proceeding to the next step:

Enabling SANTap on the module

CVT information (with WWNs)

DVT information (with WWNs)


Note At this point, SANTap is fully provisioned and functional. All the hosts regain access to the target LUNs on this path. However, the RecoverPoint communication is still not established. The communication is established only when the new Cisco Virtual Initiators are able to access the RecoverPoint target ports.


Step 9 Add the new Cisco Virtual Initiators to the RecoverPoint target zone and reactivate the zoneset.

Remove the old Cisco Virtual Initiators (9 entries) from the RecoverPoint target zone and add the new Cisco Virtual Initiators (3 entries) to the same zone and reactivate the zoneset.

Step 10 Verify that the RecoverPoint cluster recognizes and reconfigures the splitter.

RecoverPoint cluster should automatically recognize the splitter and reconfigure the splitter after the zoneset activation from previous step.

Event ID: 5003 - RPA access to splitter is restored
Event ID: 14001- Splitter is up and version is supported 

Step 11 Verify that all SANTap sessions are created after the splitter reconfiguration by the RecoverPoint Appliances.

switch# show santap module 5 session brief 

Step 12 Save the current configuration to preserve all the changes made to the fabric.

switch# copy running-config startup-config 
[########################################] 100% 

Step 13 Repeat the same steps (1 to 13) to migrate the other fabrics after the system is stable.

The hardware upgrade of SANTap from SSM to MSM-18/4 for both fabrics is complete.


Upgrading SANTap from SSM to MSM-18/4 for Different Slot in the Same Chassis


Note This procedure is applicable only for MDS 9500 switches.


To complete the hardware upgrade of SANTap from SSM to MSM-18/4 for different slots in the same chassis, follow these steps:


Step 1 Verify that the NX-OS version is Release 4.1(1b) and SSI version is Release 4.1(1i) on the switch where the SSM is currently provisioned with SANTap and is fully configured with EMC RecoverPoint.

switch# show version internal build-identifier

Step 2 Verify that the installed version of RecoverPoint is compatible with the proposed upgrade. The current upgrade example requires RecoverPoint SAN-OS Release 3.1(1) (3.1, Service Pack 1). There are two options to verify the RecoverPoint version:

In the RecoverPoint Management Application, go to the menu bar, select Help > About RecoverPoint Management Application. A dialog window appears.

Verify that the RecoverPoint version is 3.1 and Service Pack 1 is displayed in the dialog window.

At the RecoverPoint command-line interface, enter the following command:

switch# get_version

Note In the RecoverPoint Management Application, verify that RecoverPoint is replicating without errors.


Step 3 Save the running configuration (ASCII format) from the MDS switch provisioned with SANTap to the switch bootflash. Make a backup copy of the running configuration file (<file_name> on the bootflash) at an FTP or TFTP location.

switch# copy running-config startup-config 
[########################################] 100%
switch# copy running-config  bootflash:run-0430

Step 4 Copy the information related to the SANTap configuration from the ASCII configuration for restoring the same configuration on the MSM-18/4 later.

a. Enabling SANTap on the module

switch# show file bootflash:run-0430 | i ssm 
ssm enable feature santap module 5

b. CVT information (with WWNs)

switch# show file bootflash:run-0430 | i cvt
santap module 5 appl-vsan 40 cvt-name CVT-MOD5-ST2 cvt-nwwn 22:81:00:0d:ec:3c:7e:02 
cvt-pwwn 22:7e:00:0d:ec:3c:7e:02
santap module 5 appl-vsan 41 cvt-name CVT2-MOD5-ST2 cvt-nwwn 22:95:00:0d:ec:3c:7e:02 
cvt-pwwn 22:94:00:0d:ec:3c:7e:02 

c. DVT information (with WWNs)

switch# show file bootflash:run-0430 | i dvt
santap module 5 dvt target-pwwn 50:06:04:82:ca:fd:a0:93 target-vsan 40 dvt-name 
DVT-4BA dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:04:82:ca:fd:a0:b3 target-vsan 40 dvt-name 
DVT-4BB dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:0e:80:04:5a:0e:1a target-vsan 40 dvt-name DVT-2L 
dvt-vsan 30
santap module 5 dvt target-pwwn 50:06:0e:80:04:5a:0e:5a target-vsan 41 	dvt-name DVT-6L 
dvt-vsan 31

NoteIf the CVTs were created without providing a cvt-name during the initial configuration, then the cvt-nwwn and the cvt-pwwn will not be a part of the running configuration. In such cases, the cvt-wwn and cvt-pwwn must be copied from the CLI output of show santap module x cvt command.

Even if the DVTs were created without a dvt-name during the initial configuration, the dvt-name will still be a part of the running configuration. In such cases, the dvt-name need to be edited or removed from the command syntax before applying the command.


Step 5 Unprovision SANTap from the current SSM module in slot 5.

This will erase all SANTap-related information from that particular SSM in slot 5. At this point, the RecoverPoint Appliance will lose its connection to the splitter. The host will also lose its path to the target port (second path) because the SANTap process is unprovisioned.

switch(config)# no ssm enable feature santap module 5
switch(config)# show ssm provisioning 

RecoverPoint Event-ID: 12001 - splitter is down

Step 6 Insert the new MSM-18/4 module in any slot (for example slot 13) in the chassis and verify that the new module displays the module status as OK.


Note If the MSM-18/4 module is inserted in a different slot within the chassis, then SANTap needs to be unprovisioned from the SSM module, and the new MSM-18/4 module needs to be reconfigured for SANTap.


Step 7 Load the supported SSI image Release 4.1(1i) to the newly inserted MSM-18/4 module and verify that the installation process is successful.

switch# install all ssi bootflash:m9000-ek9-ssi-mz.4.1.1i.bin

Verify if the installation process is successful:

switch# show module

Note The install all ssi command will install the SSI image on all intelligent modules (SSM, MSM-18/4) that are present in the switch and not just the module that was replaced. You can verify the installations by entering show install all status command.


Step 8 Install the new license file for enabling and restoring SANTap services on the MSM-18/4 module. By default, a 120-day grace period for the SANTap process will be enabled in the absence of a SANTap license for MSM-18/4 line card.

switch# install license bootflash:SSE_licensefile 

For more information on licensing, refer to Appendix A, "Licensing and Commands."

Step 9 Edit and restore the SANTap configuration from the saved running configuration. (ASCII format)

Copy the ASCII configuration (saved in Step 4) to a notepad, edit the module information, and paste the configuration commands back. All the new configuration commands should reflect the new module number.

Verify that the command is executed after every step before proceeding to the next step.

a. Enabling SANTap on the module

b. CVT information (with WWNs)

c. DVT information (with WWNs)

Verification commands:

switch(config)# show ssm provisioning 
switch(config)# show santap module 13 cvt brief
switch# show santap module 13 dvt brief

Note At this point, SANTap is fully provisioned and functional. All the hosts should now regain access to the target LUNs on this path as well. However, the RecoverPoint communication is still not established. The communication is established only when the new Cisco Virtual Initiators (VIs) are able to access the RecoverPoint target ports.


Step 10 Add the new Cisco Virtual Initiators to the RecoverPoint target zone and reactivate the zoneset.

Remove the old Cisco Virtual Initiators (9 entries) from the RecoverPoint target zone and add the new Cisco Virtual Initiators (3 entries) to the same zone and reactivate the zoneset.

Step 11 Verify that the RecoverPoint cluster recognizes and reconfigures the splitter.

The RecoverPoint cluster should automatically recognize the splitter and reconfigure the splitter after the zoneset activation from the previous step.

Event ID: 5003 - RPA access to splitter is restored
Event ID: 14001- Splitter is up and version is supported

Step 12 Verify that all SANTap sessions are created after the splitter reconfiguration by the RecoverPoint Appliances.

switch# show santap module 5 session brief

Step 13 Save the current configuration to preserve all the changes made to the fabric.

switch# copy running-config startup-config 
[########################################] 100%

Step 14 Repeat the same steps (1 to 13) to migrate the other fabrics after the system is stable.

The hardware upgrade of SANTap from SSM to MSM-18/4 module for both fabrics is complete.


Upgrading SANTap from SSM to Base 9222i on the Same Chassis

This hardware upgrade is performed from a MDS 9222i switch with an SSM in the second slot running SANTap to the base module of the MDS 9222i switch.


Note If there are any hosts or storage or RecoverPoint devices connected to the front panel ports of the SSM, you need to reconfigure the connectivity of these devices before proceeding with the hardware upgrade procedures.


If you want to retain the SSM after the hardware upgrade to the base MDS 9222i switch, then the SSM will operate as a regular Fibre Channel.

If you want to remove the SSM after the hardware migration, then the connections need to be moved to other Fibre Channel ports in the fabric.

To complete the hardware upgrade of SANTap from SSM to the base MDS 9222i switch, follow these steps:


Step 1 Verify that the NX-OS version is Release 4.1(1b) and SSI version is Release 4.1(1i) on the switch where the SSM is currently provisioned with SANTap and is fully configured with EMC RecoverPoint. The same release should be running on the base module (fixed slot - module 1) of the MDS 9222i switch as well.

switch# show version internal build-identifier

Step 2 Verify that the installed version of RecoverPoint is compatible with the proposed upgrade. The current upgrade example requires RecoverPoint SAN-OS Release 3.1(1) (3.1, Service Pack 1). There are two options to verify the RecoverPoint version:

In the RecoverPoint Management Application, go to the menu bar, select Help > About RecoverPoint Management Application. A dialog windown appears.

Verify that the RecoverPoint version is 3.1 and Service Pack 1 is displayed in the dialog window.

At the RecoverPoint command-line interface, enter the following command:

switch# get_version

Step 3 Save the running configuration (ASCII format) from the MDS switch provisioned with SANTap to the switch bootflash. Make a backup copy of the running configuration file (<file_name> on the bootflash) on an FTP or TFTP location.

switch# copy running-config startup-config 
[########################################] 100%
switch# copy running-config  bootflash:run-0430

Step 4 Copy the information related to the SANTap configuration from the ASCII configuration for restoring the same configuration on the base 9222i switch (fixed slot - module 1).

a. Enabling SANTap on the module

switch# show file bootflash:run-0430 | i ssm 
ssm enable feature santap module 2

b. CVT information (with WWNs)

switch# show file bootflash:run-0430 | i cvt
santap module 2 appl-vsan 40 cvt-name CVT-MOD5-ST2 cvt-nwwn 22:81:00:0d:ec:3c:7e:02 
cvt-pwwn 22:7e:00:0d:ec:3c:7e:02
santap module 2 appl-vsan 41 cvt-name CVT2-MOD5-ST2 cvt-nwwn 22:95:00:0d:ec:3c:7e:02 
cvt-pwwn 22:94:00:0d:ec:3c:7e:02

c. DVT information (with WWNs)

switch# show file bootflash:run-0430 | i dvt
santap module 2 dvt target-pwwn 50:06:04:82:ca:fd:a0:93 target-vsan 40 dvt-name 
DVT-4BA dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:04:82:ca:fd:a0:b3 target-vsan 40 dvt-name 
DVT-4BB dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:0e:80:04:5a:0e:1a target-vsan 40 dvt-name DVT-2L 
dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:0e:80:04:5a:0e:5a target-vsan 41 	dvt-name DVT-6L 
dvt-vsan 31

NoteIf the CVTs were created without providing a cvt-name during the initial configuration, then the cvt-nwwn and the cvt-pwwn will not be a part of the running configuration. In such cases, the cvt-wwn and cvt-pwwn must be copied from the CLI output of show santap module x cvt command.

Even if the DVTs were created without a dvt-name during the initial configuration, the dvt-name will still be a part of the running configuration. In such cases, the dvt-name need to be edited or removed from the command syntax before applying the command.


Step 5 Unprovision SANTap from the current SSM module in slot 2.

This will erase all the SANTap-related information from that particular SSM in slot 2. At this point, the RecoverPoint Appliance will lose its connection to the splitter. The host will also lose its path to the target port (second path) because the SANTap process is unprovisioned.

switch(config)# no ssm enable feature santap module 2
switch(config)# show ssm provisioning 

RecoverPoint Event-ID: 12001 - splitter is down

Step 6 Install the new license file for enabling or restoring SANTap services on the MSM-18/4 module. By default, a 120-day grace period for the SANTap process will be enabled in the absence of the SANTap license for the base MDS 9222i switch.

switch# install license bootflash:SSE_licensefile


For more information on licensing, refer to the Appendix A, "Licensing and Commands."

Step 7 Edit and restore the SANTap configuration from the saved running configuration. (ASCII format)

Copy the ASCII configuration (saved from Step 4) to a notepad, edit the module information, and paste the configuration commands back. All the new configuration commands should reflect the new module number (fixed slot - module 1).

Verify that the command is executed after every step before proceeding to the next step.

a. Enabling SANTap on the module

b. CVT information (with WWNs)

c. DVT information (with WWNs)

Verification commands:

switch(config)# show ssm provisioning 
switch(config)# show santap module 1 cvt brief
switch# show santap module 1 dvt brief

Note At this point, SANTap is fully provisioned and functional. All the hosts regain access to the target LUNs on this path. However, the RecoverPoint communication is still not established. The communication is established only when the new Cisco Virtual Initiators are able to access the RecoverPoint target ports.


Step 8 Add the new Cisco Virtual Initiators to the RecoverPoint target zone and reactivate the zoneset.

Remove the old Cisco Virtual Initiators (9 entries) from the RecoverPoint target zone and add the new Cisco Virtual Initiators (3 entries) to the same zone and reactivate the zoneset.

Step 9 Verify that the RecoverPoint cluster recognizes and reconfigures the splitter.

The RecoverPoint cluster should automatically recognize the splitter and reconfigure the splitter after the zoneset activation from previous step.

Event ID: 5003 - RPA access to splitter is restored
Event ID: 14001- Splitter is up and version is supported

Step 10 Verify all SANTap sessions are created upon splitter reconfiguration by the RecoverPoint Appliances.

switch# show santap module 1 session brief

Step 11 Save the current configuration to preserve all the changes made to the fabric.

switch# copy running-config startup-config 
[########################################] 100%

Step 12 Repeat the same steps (1 to 11) to migrate the other fabrics after the system is stable.

The hardware upgrade of SANTap from the SSM to MSM-18/4 module for both fabrics is complete.


Upgrading SANTap from SSM to MSM-18/4 or 9222i for Chassis to Chassis

This hardware upgrade is performed from a 9216i (chassis-1) with an SSM in the second slot running SANTap to a MDS 9222i switch (chassis-2) and SSM in slot 2 running SANTap.


NoteThe same procedure can be used for any chassis-to-chassis migration. You can have different environments, and you may want to move to different configurations. This procedure addresses the following combinations:
- From 92xx to 9222i native (SANTap in slot 1) or with 18/4 (SANTap in slot 2)
- From 95xx to 9222i native (SANTap in slot 1) or with 18/4 (SANTap in slot 2)

If there any hosts or storage or RecoverPoint devices connected to the front panel ports of the SSM, it is necessary to reconfigure the connectivity of these devices before proceeding with the hardware upgrade procedures.


To complete the hardware upgrade of SANTap from SSM to MSM-18/4 or the MDS 9222i switch for chassis to chassis, follow these steps:


Step 1 Verify that the NX-OS version is Release 4.1(1b) and SSI version is Release 4.1(1i) on the switch where the SSM is currently provisioned with SANTap and is fully configured with EMC RecoverPoint.

switch# show version internal build-identifier

Step 2 Verify that the installed version of RecoverPoint is compatible with the proposed upgrade. The current upgrade example requires RecoverPoint Release 3.1(1) (3.1, Service Pack 1). There are two options to verify the RecoverPoint version:

In the RecoverPoint Management Application, go to the menu bar, select Help > About RecoverPoint Management Application. A dialog window appears.

Verify that the RecoverPoint version is 3.1 and Service Pack 1 is displayed in the dialog window.

At the RecoverPoint command-line interface, run the following command:

switch# get_version

Step 3 Save the running configuration (ASCII format) from the chassis-1 switch provisioned with SANTap to the switch bootflash. Make a backup copy of the running configuration file (<file_name> on the bootflash) at an FTP or TFTP location.

switch# copy running-config startup-config 
[########################################] 100%
switch# copy running-config  bootflash:run-0430

Step 4 Copy the information related to SANTap configuration from the ASCII configuration for restoring the same configuration on to the new switch.

a. Enabling SANTap on the module

switch# show file bootflash:run-0430 | i ssm 
ssm enable feature santap module 2 

b. CVT information (with WWNs)

switch# show file bootflash:run-0430 | i cvt
santap module 2 appl-vsan 40 cvt-name CVT-MOD5-ST2 cvt-nwwn 22:81:00:0d:ec:3c:7e:02 
cvt-pwwn 22:7e:00:0d:ec:3c:7e:02
santap module 2 appl-vsan 41 cvt-name CVT2-MOD5-ST2 cvt-nwwn 22:95:00:0d:ec:3c:7e:02 
cvt-pwwn 22:94:00:0d:ec:3c:7e:02

c. DVT information (with WWNs)

switch# show file bootflash:run-0430 | i dvt
santap module 2 dvt target-pwwn 50:06:04:82:ca:fd:a0:93 target-vsan 40 dvt-name 
DVT-4BA dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:04:82:ca:fd:a0:b3 target-vsan 40 dvt-name 
DVT-4BB dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:0e:80:04:5a:0e:1a target-vsan 40 dvt-name DVT-2L 
dvt-vsan 30
santap module 2 dvt target-pwwn 50:06:0e:80:04:5a:0e:5a target-vsan 41 	dvt-name DVT-6L 
dvt-vsan 31

NoteIf the CVTs were created without providing a cvt-name during initial configuration, then the cvt-nwwn and the cvt-pwwn will not be a part of the running configuration. In such cases, the cvt-wwn and cvt-pwwn must be copied from the CLI output of the show santap module x cvt command.

Even if the DVTs were created without a dvt-name during the initial configuration, the dvt-name will still be a part of the running configuration. In such cases, the dvt-name needs to be edited or removed from the command syntax before applying the command.


Step 5 Unprovision SANTap from the current chassis-1.

This will erase all the SANTap-related information from the SSM in chassis-1. At this point, the RecoverPoint Appliance will lose its connection to the splitter. The hosts will also lose their path to the target port (second path) as the SANTap process is unprovisioned.

switch(config)# no ssm enable feature santap module 2
switch(config)# show ssm provisioning 

RecoverPoint Event-ID: 12001 - splitter is down

Step 6 Complete configuration of the new hardware (chassis-2 with SSM or MSM-18/4 in slot 2).

Refer to the Cisco MDS 9000 Family SANTap Deployment guide for more information:

http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/4_1/santap/configuration/guide/SANTap.html

Verify the chassis-2 is running the supported SAN-OS/SSI image.

switch-chassis-2# show version internal build-identifier

Note Depending on your specific topology, the necessary connections and configuration rearrangements must be performed. For example, you may have to remove certain devices from the old chassis and connect them to the new one (or to other ports available in the fabric), and you may need to reconfigure the VSANs. In general, the network administrator must restore the hosts, storage, and RecoverPoint device connections before proceeding with SANTap provisioning.


Step 7 Install the new license file for enabling and restoring SANTap services on the MSM-18/4. By default, a 120-day grace period for the SANTap process will be enabled in the absence of SANTap license for the base MDS 9222i switch.

switch# install license bootflash:SSE_licensefile

For more information on licensing, refer to Appendix A, "Licensing and Commands."


Note At this point, all hosts and storage connections are restored to the appropriate VSANs and is extended to the new hardware as well.


Step 8 Edit and restore the SANTap configuration from the saved running configuration. (ASCII format)

Copy the ASCII configuration (saved from Step 4) to a notepad, edit the module information if necessary, and paste the configuration commands back. All the new configuration commands should reflect the new SSM module in chassis-2.

Verify that the command is executed after every step before proceeding to the next step.

a. Enabling SANTap on the module

b. CVT information (with WWNs)

c. DVT information (with WWNs)

Verification commands:

switch-chassis-2(config)# show ssm provisioning 
switch-chassis-2(config)# show santap module 2 cvt brief
switch-chassis-2# show santap module 2 dvt brief

Note At this point SANTap is fully provisioned and functional. All the hosts regain access to the target LUNs on this path. However, the RecoverPoint communication is still not established. The communication is established only when the new Cisco Virtual Initiators are able to access the RecoverPoint target ports.


Step 9 Complete the remaining steps of the RecoverPoint configuration on the new chassis-2.


Note Refer to the latest EMC Technical notes: EMC® RecoverPoint Deploying RecoverPoint with SANTap.


Step 10 Verify that all SANTap sessions are created after the splitter is recognized by the RecoverPoint cluster.

switch-chassis-2# show santap module 2 session brief

Step 11 Save the current configuration to preserve all the changes made to the fabric.

switch-chassis-2# copy running-config startup-config 
[########################################] 100% 

Step 12 In the RecoverPoint Management Application, add splitters and attach volumes to splitter. A full resynchronization of all replicated volumes in the fabric will occur. You need not wait for the full synchronization to be completed, you can proceed to the next step.

Step 13 Repeat the same steps (1 to 12) to migrate the other fabric.

The hardware upgrade of SANTap from chassis to chassis on both fabrics is complete.