Technical Notes: Emc Recoverpoint Deploying Recoverpoint With Santap and San-Os

EMC® RecoverPoint
Deploying RecoverPoint with SANTap

and SAN-OS
Technical Notes
P/N 300-004-387
Rev A11
April 19, 2010
This document describes how to deploy RecoverPoint with Cisco

Multilayer Director Switch SANTap services to deliver a complete data
replication solution without host-based agents.
The topics include:
◆ Introduction........................................................................................... 2
◆ Prerequisites .......................................................................................... 5
◆ Deploying SANTap using the command-line interface.................. 6
◆ Deploying SANTap using Fabric Manager..................................... 22
◆ Adding and Removing LUNs in the SANTap environment........ 41
◆ Moving a host HBA port to the back-end VSAN .......................... 44
◆ Planning, counting, and allocating SANTap resources................. 45
◆ Replacing a faulty host node host bus adapter .............................. 53
◆ Upgrading SANTap hardware and software ................................. 56
1
Introduction
Introduction
The purpose of this document is to provide the additional
instructions required to deploy RecoverPoint to take advantage of
SANTap services.
Scope This document is intended primarily for IT professionals with

responsibility for deploying RecoverPoint with SANTap services.
SANTap concepts SANTap is a service supported on Storage Services Modules running

on Cisco Multilayer Director Switches. SANTap taps the I/O flow
and sends a copy to a third-party appliance. The following concepts
related to SANTap entities are used in this document:
◆ VSAN layout
Switches that support SANTap services can be divided into two
logical partitions, each one running a virtual SAN (VSAN). A
SANTap solution incorporates two or more VSANs, one back end
and at least one front end. The back-end VSAN includes the
appliances (RPAs), storage targets, the control virtual target
(CVT), and the virtual initiator (VI).
The front-end VSAN contains the initiators (host HBA ports) and
data virtual targets (DVT).
A detailed explanation follows. Figure 1 on page 2 shows a
schematic of a completed RecoverPoint SANTap deployment. The
numbered zones are described in the course of this document.
Figure 1 Schematic of fully deployed SANTap solution
2 EMC RecoverPoint Deploying RecoverPoint with SANTap and SAN-OS Technical Notes
Introduction
◆ Data virtual target

The data virtual target (DVT) is a virtual representation of a
storage port created in the front-end VSAN that represents the
actual physical storage port residing in the back-end VSAN. It has
the same WWN as the actual storage port and behaves exactly the
same way. (This is possible because of the separation between the
front-end VSANs and the back-end VSAN.) As far as the initiator
(host) is concerned, it is writing to the real storage target.
A data virtual target should be created for each target. Data sent
to the data virtual target is sent to the actual target via the
SANTap service.
◆ Control virtual target
The same data is also tapped (at the CVT) for copying to the
appliance, thus enabling RecoverPoint replication. SANTap taps
the I/O and sends a copy of all data to replicate via the control
virtual target (CVT) to the RPA. The CVT has two functions:
• It is the interface used by the RPA to control the SANTap
service.
• It sends a copy of the I/O to the RPA.
◆ Virtual initiator
The virtual initiator (VI), created by SANTap in the back-end
VSAN, is a virtualization of the initiator using the same World
Wide Name as the real initiator. As far as the storage target is
concerned, the real host is writing to it.
SANTap I/O flow When an application writes to storage, the initiator (host port) sends
a write request over Fibre Channel to the data virtual target (DVT),
which is a virtual representation of the storage. SANTap internally
relays the write request to the virtual initiator (VI) in the back-end
VSAN. The VI then sends the write request over Fibre Channel to the
storage target. The control virtual target (CVT) taps the I/O flow and
sends a copy of the write request to a appliance (RPA). The RPA
replicates the write request to the replication target.
Limitations When deploying RecoverPoint deployment with SANTap services,

the following parameters should be considered:
◆ Hosts per DVT
◆ LUNs per host
EMC RecoverPoint Deploying RecoverPoint with SANTap and SAN-OS Technical Notes 3
Introduction
◆ LUNs per DVT

◆ DVTs per Storage Services Module (SSM)
◆ LUN ID address length
◆ ITLs per data path processor (DPP): the sum of all host ITLs,
reservation ITLs, discovery ITLs, and control ITLs on the DPP
◆ Replicated host ITLs: all ITLs that are to be replicated via the SSM
◆ ITLs per Storage Services Module (SSM): the sum of all host ITLs,
reservation ITLs, discovery ITLs, and control ITLs on the SSM
For the maximum value of these parameters, refer to the release notes
for your version of RecoverPoint.
◆ The maximum queue depth for Emulex and QLogic HBAs should
be set to 250.
Related documents The following documents provide additional information related to

the deployment of RecoverPoint with SANTap:
◆ Cisco MDS 9000 Family SANTap Design Guide
◆ Cisco MDS 9000 Family Fabric Manager Configuration Guide
◆ EMC RecoverPoint Installation Guide
◆ EMC RecoverPoint Administrator’s Guide
◆ Release Notes for EMC RecoverPoint and RecoverPoint/SE Release and
Service Pack Releases
◆ EMC RecoverPoint Deploying RecoverPoint with SANTap and NX-OS
Technical Notes
◆ Cisco MDS 9000 Family SANTap with EMC RecoverPoint Migration
Guide
RecoverPoint with After completing “Prerequisites” on page 5, RecoverPoint with

SANTap deployment SANTap can be deployed either using the SANTap switch CLI or the
process Fabric Manager (GUI). Procedures for both follow. Procedures for
both follow. “Deploying SANTap using the command-line interface”
starts on page page 6. “Deploying SANTap using Fabric Manager”
starts on page 22.
Prerequisites
Prerequisites
To configure RecoverPoint to take advantage of SANTap services, the
following are required:
Note: The following procedures are required for each fabric of a multi-fabric
installation.
◆ Cisco Multilayer Director Switch with Storage Service Module

and SANTap services installed at the primary site.
Cisco may decommission some of these models or replace them
with others. Please refer to Cisco’s publications for an updated
product list.
Hot migration to SANTap without application downtime is
possible only if the system contains at least two SANTap switches
supporting SANTap services.
◆ License for SANTap service for each Storage Services Module
(SSM).
◆ Port 23 between RPAs and the SAN switches must be available.
◆ RecoverPoint software loaded on all appliances (RPAs).
◆ All relevant hosts, storage ports, and RPA ports must be
connected via Fibre Channel to the same VSAN. In a multiswitch
environment, all connections must be made to the same VSAN on
every switch.
◆ Hosts and RPAs must be zoned so that each can see the storage it
must access. Zoning must be planned according to the business
needs of the organization. RPAs can be zoned only after the
RecoverPoint software has been loaded. For details, refer to
“Zoning” in Chapter 1, “Preparing for Installation” in the EMC
RecoverPoint Installation Guide.
◆ Hosts must be connected to all LUNs at all copies before the start
of replication. Afterwards, a host accessing a replica may be
powered off, but should remain available for future access to the
replica. Adding or changing a host bus adapter (registering host
initiators with DVTs and creating ITLs) in a working environment
triggers a volume sweep of all corresponding LUNs (full sweep of
the consistency group). In other words, changing a host or an
HBA should only be done during a maintenance window when a
full sweep is acceptable.
Deploying SANTap using the command-line interface
◆ For Emulex and Qlogic HBAs, set the maximum queue depth to
250.

This procedure describes how to use the SANTap switch
command-line interface to configure SANTap services for
deployment with RecoverPoint. At the end of this procedure, all I/O
activity from the host will be routed via SANTap to storage; and
writes to replicated volumes will be split by the SANTap services for
replication.
This procedure is identical to and interchangeable with “Deploying
SANTap using Fabric Manager” on page 22.
The SANTap switch’s command-line interface is described in detail in
Cisco MDS 9000 Family Configuration Guide available from Cisco
Systems, Inc. (www.cisco.com).
Before starting this procedure, make sure that you have completed all
the prerequisites (“Prerequisites” on page 5)
The process of deploying SANTap using the command line interface
include the following tasks:
1. “Identifying the SSM module” on page 7
2. “Verifying SANTap license” on page 7
3. “Enabling SANTap service” on page 7
4. “Creating the VSANs” on page 7
5. “Creating the CVT” on page 9
6. “Configuring persistent FC ID” on page 10
7. “Creating DVTs” on page 12
8. “Configuring zoning” on page 15
9. “Moving initiators to the front-end VSAN” on page 15
10. “Adding RecoverPoint” on page 18
11. “Creating AVTs” on page 21
12. “Attaching volumes” on page 22
Identifying the SSM ◆ Identify the Storage Services Module (SSM) slot number:
module switch# show module
The switch displays information in the following format:

Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ ------------
1 16 1/2 Gbps FC/Supervisor DS-X9216-K9-SUP active *
2 32 Storage Services Module DS-X9032-SSM ok
.
.
.
* this terminal session
In the above example, the Storage Services Module slot number

(column 1, Mod) is 2.
Verifying SANTap ◆ Verify that the SANTap license is installed:

license switch# show license usage
Make sure the STORAGE_SERVICES_ENABLER_PKG is

available (Ins = Yes, Lic Count = 1, Expiry = never).
Enabling SANTap ◆ Enable SANTap service on the Storage Services Module:

service switch (config)# ssm enable feature santap module
<SSM_module_number>
The SSM module number was obtained in “Identifying the SSM

module” on page 7.
Creating the VSANs SANTap uses two or more VSANs: a back-end VSAN and one or
more front-end VSANs. The back-end VSAN comprises all storage
targets, RPAs, and the control virtual target (CVT). A front-end VSAN
comprises host initiators and the data virtual target, which is a virtual
representation of a storage target. Figure 2 on page 8 shows a default
VSAN with the initial state of the environment.
Figure 2 Default VSAN configuration
The default VSAN, which currently contains all host initiator ports,
storage target ports, and RPA ports, will become the back-end VSAN.
In the examples in this document, the back-end VSAN is designated
by the number 100.
Use the following procedure to create VSANs:

1. At the switch command-line interface, enter switch configuration
mode:
switch# configure terminal
Enter VSAN data configuration mode:

switch(config)# vsan database
2. Create a front-end VSAN:

switch(config)#vsan <vsan_number> [name <vsan_name>]
Example:
switch(config-vsan-db)# vsan 200 name MyFrontEndVSAN
switch(config-vsan-db)# ^z
switch#
The example above creates a front-end VSAN with ID number

200 and the (optional) name MyFrontEndVSAN.
You should also determine the back-end VSAN number (show
vsan command). It will be used in subsequent procedures.
3. Save the changes:
switch# copy running-config startup-config
Multiple VSANs You may separate systems by using multiple front-end VSANs. By
creating more VSANs, you can assign DVTs to different front-end
VSANs. In that way, different DVTs can be assigned to different
DPPs, enabling balancing the load on DPPs and allowing better
utilization of SANTap resources (“Creating DVTs” on page 12 and
“Strategies increasing available SANTap resources” on page 53). Plan
accordingly.
Multiple back-end VSANs are not supported in the standard
distribution of RecoverPoint.
Creating the CVT 1. Create the CVT in the back-end VSAN:

switch(config)# santap module <ssm_module_number>
appl-vsan <backend_vsan_number> cvt-name <My_CVT_Name>
Example:
cisco_switch(config)# santap module 2 appl-vsan 100
cvt-name MyCVT
Give the CVT a meaningful name.

Figure 3 on page 9 shows the back-end VSAN after creating the
CVT.
Figure 3 Back-end VSAN configuration after creating CVT
2. Display the Fibre Channel name server list to verify that the CVT
was created successfully:
cisco_switch(config)# do show fcns database vsan
<backend_vsan_number>

VSAN 100:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0xe70000 N 50:01:24:82:01:2e:63:9f scsi-fcp:both
0xe70001 N 50:01:24:82:01:2e:06:9e scsi-fcp:both
0xe70002 N 50:01:24:82:00:0e:06:9e scsi-fcp:both
0xe70003 N 50:01:24:82:00:0e:63:9f scsi-fcp:both
0xe70004 N 24:01:00:05:30:00:6c:e0 (Cisco) scsi-fcp:init vir..t
0xe7000a N 24:07:00:05:30:00:6c:e0 (Cisco) scsi-fcp:init vir..t
0xe7000b N 24:08:00:05:30:00:6c:e0 (Cisco) scsi-fcp:init vir..t
0xe7000c N 24:09:00:05:30:00:6c:e0 (Cisco) scsi-fcp:init vir..t
0xe7000f N 10:00:00:00:c9:2d:41:60 (Emulex) scsi-fcp:init vir..t
0xe70010 N 10:00:00:00:c9:39:c4:45 (Emulex) scsi-fcp:init vir..t
0xe70011 N 10:00:00:00:c9:41:bc:40 (Emulex) scsi-fcp:init vir..t
0xe70017 N 24:8d:00:05:30:00:6c:e0 (Cisco) scsi-fcp:target vi..
0xe7001b N 50:01:24:82:01:3e:49:cc scsi-fcp:both
0xe7001c N 10:00:00:00:c9:5e:f4:ab (Emulex) ipfc scsi-fcp:init
0xe7005b N 50:05:07:68:01:30:15:62 (IBM) scsi-fcp:target
0xe70100 N 50:06:0b:00:00:30:b2:30 (HP) scsi-fcp:init vir..t
The line whose FC4-Type = scsi-fcp:target vi.. is the CVT itself; the
remaining nine lines that list Cisco as the vendor are the WWNs
that are available for and comprise the CVT. In the example above
they are marked in bold.
The CVT consists of the 10 WWNs indicated above. When
referencing the CVT, use all 10 addresses.
3. Exit:
# ^z

Configuring 1. If your SANTap environment does not include either an AIX or an

persistent FC ID HP-UX host, skip to “Creating DVTs” on page 12.
If your SANTap environment includes an AIX or HP-UX host,

configure the same persistent Fibre Channel identifier for all
DVTs that have the same DomainID as the back-end VSAN.
Follow the procedure in this step.
A storage volume is identified by its LUN and the storage
pWWN from which it is accessed. The AIX and HP-UX operating
systems also use the Fibre Channel Identifier (FC ID) in the device
path to the storage. The FC ID is a 24-bit address whose three
octets represent three levels in the address hierarchy, where the
domain ID is the highest level of the hierarchy.
The switch assigns FC IDs to each device as it logs in to the fabric.
It also by default assigns different domain IDs to different
VSANs. The actual initiator (host port) and DVT are in the
front-end VSAN; the virtual initiators and actual storage targets
are in the back-end VSAN.
By default the front-end VSAN and the back-end VSAN have
different domain IDs. In consequence, under the AIX and HP-UX
operating systems, the host servers will lose access to the LUNs,
because the IDs of the actual storage ports in the back-end VSAN
will have different domain IDs and therefore different FC IDs
from their virtual representation in the front-end VSAN; and the
actual host ports in the front-end VSAN will have different IDs
from their virtual representation in the back-end VSAN.
To have the switch always assign the same FC ID to a device in
both the front-end and the back-end VSAN, a persistent FC ID
must be configured.
This procedure sets the domain ID of the specified VSAN and
then enables a persistent FC ID:
a. Log in to the switch.
b. Determine the domain ID for the back-end VSAN:
switch# show fcdomain domain-list vsan
The back-end VSAN FC ID will be displayed.

c. Enter configuration mode:
switch# conf t
d. Set the domain ID for the front-end VSAN to be identical to

that of the back-end VSAN from Step b on page 11:
switch(config)# fcdomain domain <domain ID_of_vsan>

static vsan <front_end_VSAN_number>
e. Restart the front-end VSAN:

switch(config)# fcdomain restart disruptive vsan
<front-end_vsan_number>
f. Enable the persistent FC ID:

switch(config)# fcdomain fcid persistent vsan
The switch responds:

FCID persistent feature is enabled
g. To make FC IDs of storage devices the same in the front-end

VSAN as in the back-end VSAN:
switch(config)# fcdomain fcid database
switch(config-fcid-db)# vsan
<front-end_vsan_number> wwn <storage_array_wwn>
fcid <storage_array_fcid> dynamic
Repeat this step for every DVT to be created in this VSAN.

h. Determine the domain ID for all front-end VSANs:
switch# show fcdomain domain-list vsan
<frontend_vsan_number>
The front-end VSAN FC ID will be displayed.

Compare the front-end VSAN domain ID to that of the back
end (from Step b on page 11). For any front-end VSAN that
has the same domain ID as the back-end VSAN, repeat Step c
on page 11 and Step e on page 12 to Step g on page 12.
i. Exit:
switch(config-fcid-db)# ^z
switch#

Creating DVTs You must create a DVT for each storage port that you want to
replicate to. You may create several DVTs in one front-end VSAN or
create DVTs in different VSANs. To balance I/O load on DPPs, assign

DVTs to different DPPs, where possible. The easiest way to assign
DVTs to different DPPs is to place them in different VSANs. The
switch will then use a round-robin algorithm to assign DVTs to DPPs.
Where two DVTs are accessed by the same host, they must be
assigned to the same DPP.
1. To create a DVT:
switch# config t
switch(config)# santap module <SSM_Module_Slot_Number>
dvt target-pwwn <Original_Storage_Port_WWN>
target-vsan <BackEnd_VSAN_Number> dvt-name
<DVT_Meaningful_Name> dvt-vsan <FrontEnd_VSAN_Number>
lun-size-handling 1
Example:
cisco_switch(config)# santap module 2 dvt target-pwwn
50:06:04:8a:d5:f0:59:ef target-vsan 100 dvt-name MyDVT
dvt-vsan 200 lun-size-handling 1
The above example creates a DVT with the name MyDVT in the
Storage Services Module in slot 2. The DVT was created in
front-end VSAN 200 and communicates with the CVT in
back-end VSAN 100. The lun_size_handling flag enables resizing
the LUN in the future. Assigning a DVT name is optional.
Create a DVT for each storage port, using the instructions in this
step. Figure 4 on page 13 shows the VSAN configuration after
creating the DVT.
Figure 4 System configuration after creation of DVT
2. Verify that the DVT was created correctly:

switch# show santap module <SSM_Module_Slot_Number>
dvt

DVT Information :
dvt pwwn = 50:06:04:8a:d5:f0:59:ef
dvt nwwn = 50:06:04:8a:d5:f0:59:ef
dvt id = 0x83fb69c
dvt mode = 3
dvt vsan = 200
dvt if_index = 0x108c000
dvt fp_port = 13
dvt name = MyDVT
dvt tgt-vsan = 100
dvt io timeout = 10 secs
dvt lun size handling = 1
dvt app iofail behaviour = 1
dvt quiesce behavior = 0
dvt tgt iofail behavior = 0
dvt appio failover time = 45 secs
dvt inq data behavior = 0
In the example given, the DVT in VSAN 200 is the virtual

representation of the target 50:06:04:8a:d5:f0:59:ef, which is
located in VSAN 100.
3. If your system includes an AIX or HP-UX host, check that the
persistent Fibre Channel identifier was created correctly.
Compare the front-end VSAN FC ID to the back-end VSAN:
a. To display the front-end VSAN FC ID:
switch# show fcns database vsan
b. To display the back-end VSAN FC ID:

switch# show fcns database vsan
c. Make sure the FC ID listed for the DVT in the front-end VSAN
is identical to the FC ID listed for the actual storage port in the
back end.
Configuring zoning The back-end VSAN is zoned using the WWNs of the host initiator
ports and the storage target ports. Those exact same WWNs will be
used in the front-end VSAN. In consequence, the back-end zoning
scheme may be used for the front-end VSAN.
1. Copy the back-end VSAN zoning database to the front end; or
create a new front-end zoning scheme that matches the back-end
zoning scheme. Create a front-end VSAN zoneset including all
host-to-storage (DVT) zones, and activate it.
2. Verify that the relevant back-end VSAN zones exist in the
front-end VSAN, and that the front-end zoneset is updated.
Figure 5 on page 15 shows the system configuration after copying
the back-end zoning to the front-end VSAN.
Figure 5 System configuration after copying back-end zoning to front-end

VSAN
Each zone contains the WWN address of the initiator, which is about
to be moved to the front-end VSAN.
Moving initiators to When the host initiator interfaces are moved from the back-end
the front-end VSAN VSAN, where they communicate directly with storage target ports, to
the front-end VSAN, where they communicate with storage via the
DVT and the virtual initiator, there will be a short SAN downtime. To
minimize the impact of this downtime, verify before moving the
interfaces that all zones are configured and that all zonesets have
been updated and activated.
When the initiator interfaces are moved to the front-end VSAN and
the initiator logs into the DVT, the following happens:
◆ SANTap creates a link for every path from a host initiator port to
a storage LUN. These links, which are specified by the initiator
(host port), target (storage port), and LUN, are called ITLs
(initiator-target-LUNs).
NOTICE: When an ITL is created, a host write to the LUN may
occur without RecoverPoint’s knowledge, corrupting the
replica. Therefore, creating ITLs triggers a volume sweep of
the corresponding storage LUNs, ensuring data consistency.
During deployment, this behavior has no adverse effect, since
a full sweep occurs anyway when a consistency group is
enabled for the first time. However, in a working
environment, registering a new host initiator with a DVT
creates new ITLs, triggers a volume sweep of the affected
LUNs (full sweep of the consistency group), and erases the
journal. Therefore, register all host initiators at all sites during
this deployment phase. If you need to add or change host
initiators after deployment, refer to “Replacing a faulty host
node host bus adapter” on page 53.
◆ Each Storage Services Module supports a maximum number of
ITLs. For more information, refer to Table 3 on page 46 and
“Planning ITLs” on page 45.
◆ A virtual initiator (VI), a virtual representation of a host interface,
is automatically created in the back-end VSAN when an initiator
logs in to the DVT.
SAN downtime can be avoided by working in a multifabric
environment. Then you can configure one switch while the
application runs via another switch. When you configure the second
switch, you can fail over the application to the configured switch.
1. Move the host initiator ports from the back-end VSAN to the
front-end VSAN:
switch# config t
switch(config-vsan-db)# vsan <FrontEnd_VSAN_Number>
interface <interface_id>
Example:
switch# config t

switch(config-vsan-db)# vsan 200 interface fc1/2
The above example moves the interface fc1/2 to the front-end

VSAN.
Figure 6 on page 17 shows the system configuration after moving
the host initiators to the front-end VSAN
Figure 6 System configuration after moving host initiators to the front-end VSAN
2. Verify that the move was successful, that the initiator logged into
the DVT, that ITLs were created, and that I/O traffic has resumed
correctly:
dvtlun
Example:
switch# show santap module 2 dvtlun

DVT LUN Information :
dvt pwwn = 50:06:04:8a:d5:f0:59:ef
dvt lun = 0x0
xmap id = 0x8400554
dvt id = 0x83fc2a4
dvt mode = 0
dvt vsan = 200
host pwwn = 10:00:00:00:c9:39:c4:45
tgt pwwn = 50:06:04:8a:d5:f0:59:ef
tgt lun = 0x0
tgt vsan = 100
DVT LUN Information :

dvt pwwn = 50:06:04:8a:d5:f0:59:ef
dvt lun = 0x1
xmap id = 0x83fb664
dvt id = 0x83fc2a4
dvt mode = 0
dvt vsan = 200
host pwwn = 10:00:00:00:c9:39:c4:45
tgt pwwn = 50:06:04:8a:d5:f0:59:ef
tgt lun = 0x1
tgt vsan = 100
host pwwn = initiator

tgt pwwn = target
tgt lun = LUN
Together, the host pwwn, tgt pwwn, and tgt LUN define an ITL.
If some or all DVT LUNs are not shown, do the following:
a. Confirm that the Virtual Target was created successfully
switch# show santap module <SSM_module_number> dvt
b. Confirm that zoning is correct and activated.

c. Confirm that the hosts logged in to the fabric successfully.
Adding At this point, all I/O activity between the host and the SAN is relayed
RecoverPoint by SANTap from the actual host port via the DVT in the front-end
VSAN to the VI in the back-end VSAN and from there to the actual
storage port. This relay mechanism is completely transparent to the
hosts and has no impact on them.
The RPA requests the CVT to open a splitting session. The I/O will
then be copied to the RPA, allowing the RPA to replicate data to the
other side.
Initiator and target RecoverPoint ports can simultaneously be initiators and targets. As
ports initiator ports, they initiate I/O traffic and SCSI commands, as any
other host accessing storage. As targets, RecoverPoint ports act as
storage processors, receiving I/O traffic and SCSI commands from

initiators writing to their ports.
All RecoverPoint systems up to and including RecoverPoint 2.4 ship
with the QLogic series 2300 2-Gbps Fibre Channel-to-PCI host bus
adapter (HBA), in which an HBA port may not be both an initiator
and a target. In consequence, ports must be separated, enforced by
configuring initiator zones and target zones for the appliance (RPA).
To ensure compatibility with RPA troubleshooting procedures,
designate odd-numbered ports as initiator ports and even-numbered
ports as targets.
RecoverPoint 3.0 and later ships with the QLogic QLE2400 4-Gbps
Fibre Channel-to-PCI host bus adapter (HBA), which supports using
the same HBA ports as both initiators and targets. In this case,
appliance HBA ports should be used as both initiators and targets.
Note: To zone RPA HBA ports as both initiators and targets, two conditions
are necessary:
• RecoverPoint version 3.0 or later
• QLogic series QLE2400 HBA ports present
To zone the ports, you will need to know their WWNs. To obtain
them, access the Installation Menu (default user: boxmgmt; default
password: boxmgmt) and select Diagnostics > Fibre Channel details
> View Fibre Channel details.
To create the initiator and target port zones, use the Cisco switch GUI
or its CLI:
a. Create a new zone that will contain all storage ports (of the
storage array) that the RPA must access.
RecoverPoint 3.0 and QLE2400: The RPA HBA ports to be
used must all be included in this zone.
RecoverPoint 2.4 (or earlier) or QLA2300: Zone the
odd-numbered RPA HBA ports in this zone.
b. Create a new zone that will contain the 10 pWWNs associated
with the CVT. Refer to Step 2 on page 9 in “Creating the CVT”
to identify the associated pWWNs.
RecoverPoint 3.0 and QLE2400: The RPA HBA ports to be
used must all be included in this zone.

even-numbered RPA HBA ports in this zone.
c. Add the new zones to the zoneset; reactivate the zoneset.
d. Save the changes:
Figure 7 on page 20 shows the completed RecoverPoint 2.4 with

SANTap deployment. Number 3 is the RPA target port zone; 4 is
the RPA initiator port zone. For a RecoverPoint 3.0 deployment
with QLE2400, zones 3 and 4 should include all RPA HBA ports
to be used.
Figure 7 Full SANTap solution with RecoverPoint
Completing 1. Complete the installation of the RPAs. Refer to the EMC

installation of RPAs RecoverPoint Installation Guide, Chapter 2, “Installation” for
instructions. Start from the step after booting up the RPA with the
new software and continue up to, but not including, attaching
splitters. Then continue to Step 2 on page 20.
2. Adding SANTap splitters: at the RecoverPoint management
application, add a new splitter. Select the CVT from each Storage
Services Module (listed as the name you assigned to the CVT in
Step 1 on page 9 in “Creating the CVT”) as the splitter. Once it is
added, verify that the status of the selected splitter is reported as
OK.
3. Ignore any warnings regarding AVTs. They will be created in the
next step.
Creating AVTs RecoverPoint appliance virtual targets (AVTs) mask the identity of
the appliance (RPA), allowing it to appear as the host. This masking is
necessary to allow the RPA to overcome SCSI reservation of storage
ports by the hosts and to get the same view of the SAN that the host
has.
1. At the RPA CLI, create AVT zones:
>config_santap_avt_zones user=<SANTap_switch_user>
password=<SANTap_switch_AdminPassword>
switches=<“splitter_name (without colons in pWWN)”>
Example:
>config_santap_avt_zones user=admin
password=kashya12345 switches="Cisco -
cvt_remote-248d000530006ce0"
The above command creates either one or two new zones in the
switch with the WWN 24:8d:00:05:30:00:6c:e0 (the WWN of the
CVT; refer to Step 2 on page 9 in “Creating the CVT”). The
following use cases explain when one and when two AVT zones
are created and which user actions are required.
RecoverPoint 2.4; or
RecoverPoint 3.0 and QLA2300:
Two new AVT zones are created: RPA-INI-<CVT WWN> and
RPA-TGT-<CVT WWN>. The two zones contain all required
AVTs, but no RPA ports. Manually add all RPA initiator ports
to RPA-INI-<CVT WWN> and RPA target ports to
RPA-TGT-<CVT WWN>.
RecoverPoint 3.0 and QLE2400:
One new AVT zone and all required AVTs are created. Add all
RPA HBA ports in use, both initiators and targets, to the AVT
zone.
One new AVT zone with all required AVTs is created. All RPA
HBA ports in use, both initiators and targets, are automatically
added to the AVT zone.
2. For the changes to take effect, add the new zone to the VSAN
zoneset and activate it.
3. Save the changes to the switch configuration:
Deploying SANTap using Fabric Manager
Attaching volumes 1. Every volume to be replicated must be attached to the

appropriate SANTap splitter. At the RecoverPoint Management
Application, click the Splitters tab, select the desired splitter, click
the Splitters properties button, select each volume you wish to
replicate, and click Attach.
2. Check that the number of ITLs (possible paths from the host
initiator to the attached storage volumes) is in accordance with
expectations. Refer to “Planning ITLs” on page 45 to calculate
how many ILTs to expect.
a. At the RPA CLI, run the command refresh_santap_view.
The command causes the RPA to update its view of
SANTap-related information.
b. Run the command get_santap_view.
The list of all ITLs seen by the RPA is displayed.
If the number of paths to a volume is less than expected, run
refresh_santap_view to see if more information can be
obtained about the paths that were expected but are missing.

This procedure describes how to use the SANTap switch Fabric
Manager (graphic user interface) to configure SANTap services for
deployment with RecoverPoint. At the end of this procedure, all I/O
activity from the host will be routed via SANTap to storage; and
writes to replicated volumes will be split by the SANTap services for
replication.
This procedure is parallel to and interchangeable with “Deploying
SANTap using the command-line interface” on page 6.
The SANTap switch’s graphical user interface, Fabric Manager, is
described in detail in Cisco MDS 9000 Family Fabric Manager
Configuration Guide available from Cisco Systems, Inc.
(www.cisco.com).
Before starting this procedure, make sure that you have completed all
the prerequisites (“Prerequisites” on page 5)
The process of deploying SANTap using Fabric Manager include the

following tasks:
1. “Identifying the SSM module” on page 26
2. “Verifying the SANTap license” on page 26
3. “Enabling the SANTap service” on page 26
4. “Creating VSANs” on page 26
5. “Creating the CVT” on page 27
6. “Configuring a persistent FC ID” on page 28
7. “Creating DVTs” on page 30
8. “Configuring zoning” on page 32
9. “Adding RecoverPoint” on page 33
10. “Creating AVTs” on page 36
11. “Moving initiators to the front-end VSAN” on page 38
12. “Attaching volumes” on page 40
Fabric Manager The Fabric Manager client interface is shown.

client interface
Figure 8 Frame Manager client interface
Table 1 Fabric Manager interface components
Number Description
1 Menu bar: provides access to menu options
2 Toolbar: icons that provide access to common menu options
3 Information pane: displays information about the option selected in the menu
tree
Table 1 Fabric Manager interface components
Number Description
4 Status bar: shows the last entry displayed by the discovery process, and
possibly error messages
5 Fabric pane: displays a map of the network fabric; also provides tabs for
displaying log and event data
6 Logical domains pane: displays a tree of configured SAN, fabrics, VSANs, and
zones
7 Physical attributes pane: displays a tree of available configuration tasks for the
selected logical domain; lists the switches and end devices in the selected logical
domain.
8 Status bar (left): displays messages about the current selection
For more information about the Fabric Manager interface, refer to

Cisco MDS 9000 Family Fabric Manager Configuration Guide available
from Cisco Systems, Inc. (www.cisco.com).
Opening Fabric 1. Double-click the Fabric Manager icon on the Windows or Linux
Manager desktop. In the Information pane, click the Discover button.
The Discover New Fabric dialog box appears.
2. In the Discover New Fabric dialog box, enter the following
information:
Table 2 Discover New Fabric options
Option Description
Seed switch IP address of the switch you wish Fabric Manager to use for discovery
on the fabric.
Use SNMPv3 Check to use SNMP. Uncheck f you need to use SNMPv2 (for
instance, if the switch does not support SNMPv3).
Click OK.
3. In the Information pane, click the name of the switch you wish to
open.
The Fabric Manager GUI for the selected switch appears.
Identifying the SSM ◆ Identify the Storage Services Module (SSM) slot number:
module In the Physical Attributes pane, select End Devices > SSM
Features. Click the SSM tab.
Verifying the ◆ Verify that the SANTap license is installed:

SANTap license From the Physical Attributes pane, select Switches > Licenses.
The license information will be displayed.
Make sure the STORAGE_SERVICES_ENABLER_PKG is
available (Ins = Yes, Lic Count = 1, Expiry = never).
Enabling the ◆ Enable SANTap service on the Storage Services Module:

SANTap service In the Physical Attributes pane, select Switches > Hardware. In
the Information pane, click the Card Module Status tab. Verify
that Power Admin = ON for the desired module. If you need to
make changes, afterwards click Apply Changes.
The SSM module number was obtained in “Identifying the SSM
module” on page 26.
Creating VSANs SANTap uses two or more VSANs: a back-end VSAN and one or
more front-end VSANs. The back-end VSAN comprises all storage
targets, RPAs, and the control virtual target (CVT). A front-end VSAN
comprises host initiators and the data virtual target, which is a virtual
representation of a storage target. Figure 2 on page 8 shows a default
VSAN with the initial state of the environment.
Figure 9 Default VSAN configuration
The default VSAN, which currently contains all host initiator ports,
storage target ports, and RPA ports, will become the back-end VSAN.
In the examples in this document, the back-end VSAN is designated
by the number 100.
Use the following procedure for creating VSANs:

1. In the Fabric Manager toolbar (Figure 8 on page 24), click the
Create VSAN button .
The Create VSAN dialog box appears.
2. Create at least one front-end and one back-end VSANs. You may
create more than one front-end VSAN, but more than one
back-end VSAN is not supported.
4. Determine the back-end VSAN number. It will be used in
subsequent procedures.
Multiple VSANs You may separate systems by using multiple front-end VSANs. By
creating more VSANs, you can assign DVTs to different front-end
VSANs. In that way, different DVTs can be assigned to different
DPPs, enabling balancing the load on DPPs and allowing better
utilization of SANTap resources (“Creating DVTs” on page 12 and
“Strategies increasing available SANTap resources” on page 53). Plan
accordingly.
Multiple back-end VSANs are not supported in the standard
distribution of RecoverPoint.
Creating the CVT 1. Create the CVT in the back-end VSAN:

a. In the Physical Attributes pane, select End Devices > SSM
Features.
b. In the Information pane, click the SANTap CVT tab. On the
toolbar, click Create Row ( )
c. Enter the VSAN ID and CVT name.
d. Click Create.
If the CVT is created successfully, the message “Success” will
appear at the bottom of the dialog box.
e. Press Close.
Figure 3 on page 9 shows the back-end VSAN after creating the

CVT.
Figure 10 Back-end VSAN configuration after creating CVT
2. Display the Fibre Channel name server list to verify that the CVT
was created successfully:
a. In the Physical Attributes pane, select End Devices > SSM
Features. Click the SSM tab.
b. In the Information pane, select the CVT tab.
c. Verify that CVT was created in the correct back-end VSAN.
a. In the Physical Attributes pane, select Switches > Copy
Configuration.
b. In the Information panel, select From = runningConfig, To =
fabricStartupConfig.
c. To save the changes, in the Information pane toolbar, click the
Apply Changes button .
Configuring a 1. If your SANTap environment does not include either an AIX or an

persistent FC ID HP-UX host, skip to “Creating DVTs” on page 12.
If your SANTap environment includes an AIX or HP-UX host,
configure the same persistent Fibre Channel identifier for all
DVTs that have the same DomainID as the back-end VSAN.
Follow the procedure in this step.
A storage volume is identified by its LUN and the storage

pWWN from which it is accessed. The AIX and HP-UX operating
systems also use the Fibre Channel Identifier (FC ID) in the device
path to the storage. The FC ID is a 24-bit address whose three
octets represent three levels in the address hierarchy, where the
domain ID is the highest level of the hierarchy.
The switch assigns FC IDs to each device as it logs in to the fabric.
It also by default assigns different domain IDs to different
VSANs. The actual initiator (host port) and DVT are in the
front-end VSAN; the virtual initiators and actual storage targets
are in the back-end VSAN.
By default the front-end VSAN and the back-end VSAN have
different domain IDs. In consequence, under the AIX and HP-UX
operating systems, the host servers will lose access to the LUNs,
because the IDs of the actual storage ports in the back-end VSAN
will have different domain IDs and therefore different FC IDs
from their virtual representation in the front-end VSAN; and the
actual host ports in the front-end VSAN will have different IDs
from their virtual representation in the back-end VSAN.
To have the switch always assign the same FC ID to a device in
both the front-end and the back-end VSAN, a persistent FC ID
must be configured.
This procedure sets the domain ID of the specified VSAN and
then enables a persistent FC ID:
a. Log in to the switch.
b. Determine the domain ID for the back-end VSAN:
1. In the Logical Domains pane, select the back-end VSAN.
2. Right-click and select Edit Local Full Zone Database.
In the Information pane, every port and FC ID in the VSAN
is listed. The FC ID is in the format 0xhhhhhhh; for instance,
0xce00d1. Record every port and its pWWN.
3. In the Logical Domain pane, select the back-end VSAN,
then select Domain Manager.
4. In the Information pane, click the Running tab.
5. Record the domain ID of the back-end VSAN. The domain
ID is a number from 1 to 239.
c. Set the domain ID for the front-end VSAN to be identical to
that of the back-end VSAN:
1. In the Logical Domains pane, select the front-end VSAN,

2. In the Information pane, click the Configuration tab. Set
the Running Domain ID to the value of the back-end
VSAN domain ID that you recorded.
3. Click the Apply Changes button.
d. Make FC IDs of storage devices in the front-end VSAN the
same as in the back-end VSAN and enable the persistent FC
ID:
1. In the Logical Domains pane, select the front-end VSAN,
2. In the Information pane, select the Persistent FC ID tab.
3. Click the Create Row button. For each port, enter the
pWWN and the FC ID that you recorded. Verify that the
Enabled checkbox is checked. Repeat for all relevant ports
in the VSAN.
e. Determine the domain ID for all front-end VSANs:
1. In the Logical Domains pane, select the front-end VSAN.
2. Right-click and select Edit Local Full Zone Database.
In the Information pane, every port and FC ID in the VSAN
is listed. The FC ID is in the format 0xhhhhhhh; for instance,
0xce00d1.
3. In the Logical Domain pane, select the front-end VSAN,
4. In the Information pane, click the Running tab.
Compare the front-end VSAN domain ID to that of the back
end (from Step b on page 11).
Configuration.
Creating DVTs You must create a DVT for each storage port that you want to
replicate to. You may create several DVTs in one front-end VSAN or
create DVTs in different VSANs. To balance I/O load on DPPs, assign

DVTs to different DPPs, where possible. The easiest way to assign
DVTs to different DPPs is to place them in different VSANs. The
switch will then use a round-robin algorithm to assign DVTs to DPPs.
Where two DVTs are accessed by the same host, they must be
assigned to the same DPP.
1. To create a DVT:
a. In the Physical Attributes pane, select SSM Features. In the
Information pane, select SANTap DVT. Click the Create New
Row button.
The Create DVT Database dialog box appears.
b. In the dialog box, enter the following values:
– Destination VSAN = <front-end VSAN #>
– VSAN ID = <back-end VSAN #>
– WWN = <pWWN of the storage port you are replicating to>
– Name = <meaningful name for the DVT>
– LUN-size handling = checked
The lun_size_handling flag enables resizing the LUN in the
future. Assigning a DVT name is optional.
Create a DVT for each storage port, using the instructions in this
step. Figure 4 on page 13 shows the VSAN configuration after
creating the DVT.
Figure 11 System configuration after creation of DVT
2. Verify that the DVT was created correctly:
a. In the Physical Attributes pane, select the front-end VSAN,

right-click, and select Edit Local Full Zone Database.
b. If your system includes an AIX or HP-UX host, check that the
persistent Fibre Channel identifier was created correctly. The
FC ID (DVT ID) should be identical to the one in the back-end.
Configuration.
Configuring zoning The back-end VSAN is zoned using the WWNs of the host initiator
ports and the storage target ports. Those exact same WWNs will be
used in the front-end VSAN. In consequence, the back-end zoning
scheme may be used for the front-end VSAN.
1. Copy the host initiators and storage port zones from the back-end
VSAN zoning database to the front end; or create a new front-end
zoning scheme that matches the back-end zoning scheme. Create
a front-end VSAN zoneset including all host-to-storage (DVT)
zones, and activate it.
2. Verify that the relevant back-end VSAN zones exist in the
front-end VSAN, and that the front-end zoneset is updated.
Figure 5 on page 15 shows the system configuration after copying

the back-end zoning to the front-end VSAN.
Figure 12 System configuration after copying back-end zoning to front-end

VSAN
Each zone contains the WWN address of the initiator, which is about
to be moved to the front-end VSAN.
Adding At this point, all I/O activity between the host and the SAN is relayed
RecoverPoint by SANTap from the actual host port via the DVT in the front-end
VSAN to the VI in the back-end VSAN and from there to the actual
storage port. This relay mechanism is completely transparent to the
hosts and has no impact on them.
The RPA requests the CVT to open a splitting session. The I/O will
then be copied to the RPA, allowing the RPA to replicate data to the
other side.
Initiator and target RecoverPoint ports can simultaneously be initiators and targets. As
ports initiator ports, they initiate I/O traffic and SCSI commands, as any
other host accessing storage. As targets, RecoverPoint ports act as
storage processors, receiving I/O traffic and SCSI commands from
initiators writing to their ports.
All RecoverPoint systems up to and including RecoverPoint 2.4 ship
with the QLogic series 2300 2-Gbps Fibre Channel-to-PCI host bus
adapter (HBA), in which an HBA port may not be both an initiator
and a target. In consequence, ports must be separated, enforced by
configuring initiator zones and target zones for the appliance (RPA).
To ensure compatibility with RPA troubleshooting procedures,
designate odd-numbered ports as initiator ports and even-numbered

ports as targets.
RecoverPoint 3.0 ships with the QLogic QLE2400 4-Gbps Fibre
Channel-to-PCI host bus adapter (HBA), which supports using the
same HBA ports as both initiators and targets. In this case, appliance
HBA ports should be used as both initiators and targets.
Note: To zone RPA HBA ports as both initiators and targets, two conditions
are necessary:
• RecoverPoint version 3.0 or later
• QLogic series QLE2400 HBA ports present
To zone the ports, you will need to know their WWNs. To obtain
them, access the Installation Menu (default user: boxmgmt; default
password: boxmgmt) and select Diagnostics > Fibre Channel details
> View Fibre Channel details.
To create the initiator and target port zones, the following steps are
required:
1. Create a new zone that will contain all storage ports (of the
storage array) that the RPA must access.
RecoverPoint 3.0 and QLE2400: The RPA HBA ports to be used
must all be included in this zone.
odd-numbered RPA HBA ports in this zone.
To create and populate a new zone:
a. In the Logical Domains pane, select the back-end VSAN.
Right-click and select Edit Local Full Zone Database.
b. In the Information pane, select Zone > Insert. Create the new
zone and give it a meaningful name.
c. Right-click on the new zone and select Insert.
d. Select the pWWNs to add to the zone.
e. Click Add. Then click Close.
2. Create a new zone that will contain the 10 pWWNs associated
with the CVT. Refer to Step 2 on page 9 in “Creating the CVT” to
identify the associated pWWNs.
RecoverPoint 3.0 and QLE2400: The RPA HBA ports to be used

must all be included in this zone.
even-numbered RPA HBA ports in this zone.
To create and populate a new zone:
b. In the Information pane, select Zone > Insert. Create the new
zone and give it a meaningful name.
c. Right-click on the new zone and select Insert.
d. Select the pWWNs to add to the zone.
e. Click Add. Then click Close.
3. Add the new zones to the zoneset; reactivate the zoneset:
b. In the Information pane, select Zoneset > Insert. Create the
new zoneset and give it a meaningful name.
c. Right-click on the new zoneset and select Insert.
d. Select the new zones to add to the zoneset.
e. Click Add. Then click Activate.
Configuration.
Figure 7 on page 20 shows the completed RecoverPoint 2.4 with

SANTap deployment. Number 3 is the RPA target port zone; 4 is
the RPA initiator port zone. For a RecoverPoint 3.0 deployment
with QLE2400, zones 3 and 4 should include all RPA HBA ports
to be used.
Figure 13 Full SANTap solution with RecoverPoint
Completing 1. Complete the installation of the RPAs. Refer to the EMC

installation of RPAs RecoverPoint Installation Guide, Chapter 2, “Installation” for
instructions. Start from the step after booting up the RPA with the
new software and continue up to, but not including, attaching
splitters. Then continue to Step 2 on page 20.
2. Adding SANTap splitters: at the RecoverPoint management
application, add a new splitter. Select the CVT from each Storage
Services Module (listed as the name you assigned to the CVT in
Step 1 on page 9 in “Creating the CVT”) as the splitter. Once it is
added, verify that the status of the selected splitter is reported as
OK.
3. Ignore any warnings regarding AVTs. They will be created in the
next step.
Creating AVTs RecoverPoint appliance virtual targets (AVTs) mask the identity of
the appliance (RPA), allowing it to appear as the host. This masking is
necessary to allow the RPA to overcome SCSI reservation of storage
ports by the hosts and to get the same view of the SAN that the host
has.
1. At the RPA CLI, create AVT zones:
>config_santap_avt_zones user=<SANTap_switch_user>
password=<SANTap_switch_AdminPassword>
switches=<“splitter_name (without colons in pWWN)”>
Example:
>config_santap_avt_zones user=admin
password=kashya12345 switches="Cisco -
cvt_remote-248d000530006ce0"
The above command will create either one or two new zones in
the switch with the WWN 24:8d:00:05:30:00:6c:e0 (the WWN of the
CVT; refer to Step 2 on page 9 in “Creating the CVT”).
RecoverPoint 2.4;
RecoverPoint 3.0 and QLA2300:
Two new AVT zones will be created: RPA-INI-<CVT WWN> and
RPA-TGT-<CVT WWN>. The two zones will contain all required
AVTs, but no RPA ports. Manually add all RPA initiator ports to
RPA-INI-<CVT WWN> and RPA target ports to RPA-TGT-<CVT
WWN>.
One new AVT zone with all required AVTs will be created. All
RPA HBA ports in use, both initiators and targets, must added to
the AVT zone.
One new AVT zone with all required AVTs will be created. All
RPA HBA ports in use, both initiators and targets, will
automatically be added to the AVT zone.
2. For the changes to take effect, add the new zone to the VSAN
zoneset and activate it:
b. In the Information pane, select Zoneset > Insert. Create the
new zoneset and give it a meaningful name.
c. Right-click on the new zoneset and select Insert.
d. Select the new zones to add to the zoneset.
e. Click Add. Then click Activate.
3. Save the changes to the switch configuration:

Configuration.
Moving initiators to When the host initiator interfaces are moved from the back-end
the front-end VSAN VSAN, where they communicate directly with storage target ports, to
the front-end VSAN, where they communicate with storage via the
DVT and the virtual initiator, there will be a short SAN downtime. To
minimize the impact of this downtime, verify before moving the
interfaces that all zones are configured and that all zonesets have
been updated and activated.
When the initiator interfaces are moved to the front-end VSAN and
the initiator logs into the DVT, the following happens:
◆ SANTap creates a link for every path from a host initiator port to
a storage LUN. These links, which are specified by the initiator
(host port), target (storage port), and LUN, are called ITLs
(initiator-target-LUNs).
NOTICE: When an ITL is created, a host write to the LUN may
occur without RecoverPoint’s knowledge, corrupting the
replica. Therefore, creating ITLs triggers a volume sweep of
the corresponding storage LUNs, ensuring data consistency.
During deployment, this behavior has no adverse effect, since
a full sweep occurs anyway when a consistency group is
enabled for the first time. However, in a working
environment, registering a new host initiator with a DVT
creates new ITLs, triggers a volume sweep of the affected
LUNs (full sweep of the consistency group), and erases the
journal. Therefore, register all host initiators at all sites during
this deployment phase. If you need to add or change host
initiators after deployment, refer to “Replacing a faulty host
node host bus adapter” on page 53.
◆ Each Storage Services Module supports a maximum number of
ITLs. For more information, refer to Table 3 on page 46 and
“Planning ITLs” on page 45.
◆ A virtual initiator (VI), a virtual representation of a host interface,

is automatically created in the back-end VSAN when an initiator
logs in to the DVT.
SAN downtime can be avoided by working in a multifabric
environment. Then you can configure one switch while the
application runs via another switch. When you configure the second
switch, you can fail over the application to the configured switch.
1. Move the host initiator ports from the back-end VSAN to the
front-end VSAN:
a. In the Physical Attributes pane, select the back-end VSAN,
and right-click on it.
b. Select Copy Full Zone Database. Enter the following search
parameters:
Copy Database = full
Source VSAN = <back-end VSAN>
Destination VSAN = <front-end VSAN>
c. Press the Copy button.
d. In the Physical Attributes pane, select the back-end VSAN,
and right-click on it.
e. Select Edit Full Zone Database.
f. In the Information pane, select Zoneset. Press the Activate
button.
g. In the Logical Devices pane, select the back-end VSAN.
h. In the Physical Interfaces pane, select Interfaces > FC
Physical.
i. In the Information pane, edit each initiator port to associate it
with the front-end VSAN.
j. Click Apply changes.
Figure 6 on page 17 shows the system configuration after moving

the host initiators to the front-end VSAN.
Figure 14 System configuration after moving host initiators to the front-end VSAN
2. Verify that the WWNs of hosts (virtual initiators) appear in the

back-end VSAN:
a. In the Logical Devices pane, select the back-end VSAN.
b. In the Information pane, click the Hosts tab.
Check that the WWNs of the hosts appear with the ID of the
back-end VSAN.
c. Check on the host that I/O traffic to storage exists.
Configuration.
Attaching volumes 1. Every volume to be replicated must be attached to the

appropriate SANTap splitter. At the RecoverPoint Management
Application, click the Splitters tab, select the desired splitter, click
the Splitters properties button, select each volume you wish to
replicate, and click Attach.
Adding and Removing LUNs in the SANTap environment
The list of all ITLs seen by the RPA will be displayed.
If the number of paths to a volume is less than expected, run
refresh_santap_view to see if more information can be
obtained about the paths that were expected but are missing.

This section describes to the procedure for adding a LUN to be
replicated or removing a replicated LUN in the SANTap
environment.
Adding a LUN To add a LUN for replication, you must add a LUN at the production
site and at each copy site (local or remote or both).
1. From the storage array, perform LUN masking so that only one
host and only one RPA cluster can see the LUN.
2. Add the LUN to the SANTap environment.
3. To see the ITLs for the new LUN, rescan the SAN from the host.
Use the following commands:
On Windows:
Click Start > Run. Run compmgmt.msc. In the displayed
components tree, right-click on Disk Management, and click
Rescan Disks.
On AIX:
• At the system prompt, use the following command:
# cfgmgr -v
On Solaris:
At the system prompt, use the following command:
# devfsadm -c disk
4. To verify that the ITL was created and that the switch sees it, use
SSH to connect to the switch as follows:
$ ssh admin@<IP address of the switch>
At the switch prompt:

switch# show santap module <module #> dvtlun brief
A table will appear, with the following data:

• DVT WWN
• DVT LUN
• Host WWN
• Host LUN
• Target LUN
Look for a new ITL with your Host WWN and DVT WWN (same
as storage target WWN). The Host LUN number should be new.
Note: When entering the command on a Supervisor 2 module, the
DVT LUNs may not show in the output. To display the complete
DVT LUN information, use the following commands:
switch# show santap vttbl dvt <dvt-pwwn>
To display information for the DVT and the host:

switch# show santap vttbl dvt <dvt-pwwn> <host-pwwn>
5. Follow the instructions in the EMC RecoverPoint Administrator’s

Guide for your release of RecoverPoint for adding a replication set
(replication pair) to a consistency group, and attaching it to the
appropriate splitter. The following is a quick overview of the
process in RecoverPoint 3.0:
a. In the RecoverPoint Management Application, in the
Navigation pane, click on the consistency group.
b. In the Components pane, click on the Volumes tab.
c. Click Replication Sets, then click Add New Replication Set.
d. At each copy, add the appropriate volume.
e. In the RecoverPoint Management Application, in the

Navigation pane, click Splitters. In the Components pane,
double-click on the splitter for the new replication set.
The Splitter Properties pane opens.
f. Press Rescan and verify that the new replication volume
appears. Click the replication volume, and click Attach. Click
the volume to attach and click OK. Each volume undergoes a
volume sweep as you attach it to the splitter.
Repeat this step for all volumes of the replication set.
6. To verify that a session was created for the new volumes. At the
switch command-line interface, use the following command:
switch# show santap module <module number> session
brief
The output will show the following for every current session:
• Session ID
• Host WWN
• DVT WWN
• DVT LUN
Verify that there is a line with the LUN number and WWN of the
host of each added volume. If your host is multipathing, verify
that you have a session for each path to the host.
Note: SANTap running on Storage Services Interface 3.1.2 or earlier has bug
that for each removed LUN, you must add two LUNs in order to see new
LUNs. If you add only one LUN, the switch will not see the LUN.
Removing a LUN Use the following procedure to remove replicated LUNs from the
SANTap environment.
1. From the RecoverPoint command-line interface, run the
command:
> get_santap_view
Record the ITLs of the LUN you wish to remove.

2. Detach the volume from its splitter.
3. Delete the replication set containing the volume to remove.
Moving a host HBA port to the back-end VSAN
4. If you are removing the last replication set in a consistency group,

disable the consistency group.
5. Remove LUN masking from the LUN to be removed.
6. Allow enough time for the changes to be updated on the switch
(about one minute).
7. Refresh the SANTap view for the relevant splitter. To do so, at the
RecoverPoint command-line interface, run the command:
> refresh_santap_view
8. At the RecoverPoint command-line interface, run the command:

> get_santap_view
Verify that the ITLs that you recorded in step 1 on page 43 no

longer appear.
Moving a host HBA port to the back-end VSAN

If you need to move a host HBA port to the back-end VSAN, use the
following procedure.
Note: A host HBA port should not be moved to the back-end VSAN unless
there is a compelling reason to do so. When this procedure is performed, it
must be performed on both fabrics. The volumes accessed by the HBA port
will no longer be replicated. Those volumes must be detached from their
splitters on both fabrics, and then removed from their configuration group.
1. Stop the applications writing to the host HBA port.

2. Shut down the host HBA port.
3. Detach from the splitter all volumes that are being accessed via
that host HBA port.
4. Remove the ITLs associated with the host HBA port:
# clear santap module <SSM_slot_number> itl target-pwwn

<target-pWWN> host-pwwn <host_pWWN>
Repeat this step for each storage target pWWN that the host HBA
port logs in to. This step deletes ITLs that are using the host HBA
port and deletes the Virtual Initiator. This step must be performed
before pWWNs can be moved to the back-end VSAN.
Planning, counting, and allocating SANTap resources
5. Verify that the host Virtual Initiator was removed from the
back-end VSAN. Use the following command:
# show fcns database vsan <backend_VSAN_ID>
Verify that the host HBA port WWN does not appear in the
output.
6. Allow enough time for the changes to be updated on the switch
(about one minute).
8. Move the host HBA port to the back-end VSAN. At the switch,
run the following commands:
# config t
(config) # vsan database
(config-vsan-db) # vsan <backend_VSAN_ID> interface
fc<SSM_slot_number>/<port_number>
These commands move the specified interface and device to the

specified VSAN.
9. Bring up the host HBA port.

When deploying RecoverPoint with SANTap switches, plan the
deployment to make efficient use of the switch resources.
The following sections discuss how to count ITLs, how to allocate
ITLs to DPPs, and strategies for deploying within the limits of the
available resources.
Planning ITLs SANTap creates a link, or ITL (initiator-target-LUN), for every path
from a host initiator port to a storage LUN. An ITL is specified by the
combination of three elements: an initiator (host port), target (storage
port), and LUN.
Each data path processor (DPP) and each Storage Services Module
(SSM) supports a maximum number of ITLs. This section describes
how to estimate the number of ITLs required.
The SANTap service creates the following types of ITLs:
◆ host ITLs
◆ reservation ITLs
◆ discovery ITLs
◆ control ITLs
Predicting host ITLs A host ITL is a unique path from an initiator via a target to a LUN. To
count the total number of host ITLs consumed, every path via which
a host can access a LUN must be counted. The number of host ITLs
consumed is given by:
where:
I = every initiator (host HBA port WWN) that can access LUNs via a
target
T = every target (DVT) through which an initiator can access LUNs
L = number of LUNs on target T that the initiator I can access.
The total number of ITLs is the number of distinct (initiator WWN,
target WWN, LUN) combinations that are in use.
Which LUNs an initiator can access is determined by zoning and
LUN masking. The storage network administrator should be able to
inform you which LUNs can be accessed from which initiators and
through which targets.
For example, in a system with four initiator ports, three target ports,
and a large number of LUNs, we might have the situation shown in
Table 3 on page 46 (also see Figure 15 on page 47):
Table 3 Example of counting host ITLs
Initiator Target LUNs
I1 T1 L11, L13, L15, L17, L19
I1 T2 L11, L13, L15, L17, L19
I2 T2 L11, L13, L15, L17, L19
Table 3 Example of counting host ITLs
I3 T3 L12, L14, L16, L18
I4 T1 L12, L14, L16, L18
I4 T3 L12, L14, L16, L18
In all, 27 host ITLs are consumed in this configuration.
Figure 15 Example of counting host ITLs
Predicting reservation When a LUN is reserved by SCSI reservations, special techniques are
ITLs required to allow the host and the appliance both to have the same
view of the reserved LUN. For details, refer to “Creating AVTs” on
page 21. It makes no difference whether the SCSI reservation is
initiated by the operating system (for instance, as for AIX) or by the
application or host cluster (for instance, Microsoft Cluster Server).
The following systems implement SCSI reservation:
◆ AIX and HP-UX hosts
◆ Host clusters, including Microsoft Cluster Servers
◆ VMware servers
Reservation ITLs are created for each available path to a reserved

LUN. The number of reservation ITLs is given by:
where:
I = every initiator (HBA port WWN) used to access a reserved LUN
T = every target (DVT WWN) used to access a reserved LUN
Lr= number of reserved LUNs the initiator can access
HBA = number of HBA port WWNs on an RPA that are zoned as
initiator ports able to access reserved LUNs. It is assumed that, in
accordance with best practice, each RPA in the cluster is zoned with
the same number of initiator ports. Only when deploying
RecoverPoint 3.0 and QLE2400, all RPA HBA ports in use are
initiator ports.
RPAs = is the number of RPAs in the RPA cluster.
The number of reservation ITLs is the number of distinct (initiator
WWN, target WWN, reserved LUN) combinations that are in use.
For example, for RecoverPoint 2.4 or QLA2300, consider the
configuration shown in Figure 15 on page 47. Let there be four RPAs,
each with four HBA ports, two zoned as initiators and two as targets
in a single fabric. Assume that the blue server (left) implements
reservations and the orange server (right) does not. The number of
host ITLs that access reserved LUNs is shown in Table 4 on page 48.
Table 4 Example of counting reservation ITLs
I1 T1 L11, L13, L15, L17, L19
I1 T2 L11, L13, L15, L17, L19
I2 T2 L11, L13, L15, L17, L19
The total number of host ITLs accessing reserved LUNs is 15. Since
there are four RPA with two initiator HBA ports each, the total
number of reservation ITLs =
15 host ITLs that see reserved LUNs * 4 RPAs * 2 HBA ports per RPA
=120 reservation LUNs.
The reservation LUNs are in addition to the 27 host LUNs already

counted.
Discovery ITLs Discovery ITLs are created when the RPA carries out discovery on the
SAN and when there are changes in the SAN configuration. For each
discovery, an AVT with 26 virtual LUNs is created dynamically. The
number of ITLs consumed by the AVTs is:
# discovery ITLs = 26 x HBA x RPA

where
HBA =
RecoverPoint 3.0 and QLE2400: The number of RPA HBA
ports to be used in one RPA.
RecoverPoint 2.4 (or earlier) or QLA2300: number of HBA
ports zoned as initiators in one RPA.
RPA = number of RPAs per RPA cluster.
By design, discovery is performed by only one RPA in the cluster. If
the RPA has two HBA ports, 52 ITLs are consumed during discovery.
In exceptional situations, however, every RPA in the cluster may
perform a discovery. Therefore, use the following formula to
determine how many ITLs you should leave available for discovery:
26 * (number of HBA ports in use) * (number of RPAs in cluster)
RecoverPoint 2.4 (or earlier) or QLA2300:
26*(number of HBA initiator ports)*(number of RPAs in cluster)
There must always be enough unused ITLs to allow discovery to
occur on all RPAs. In our example with 4 HBA ports and 4 RPAs per
cluster in one fabric,
26 * 2 (HBA ports in use) * 4 RPAs = 208 discovery ITLs
RecoverPoint 2.4 (or earlier) or QLA2300:
26 * 2 (HBA initiator ports) * 4 RPAs = 208 discovery ITLs
Discovery ITLs are created on each DPP that has a DVT. After
discovery is completed, discovery ITLs are discarded.
Counting control The number of control ITLs created is:

ITLs
# control ITLs = HBA x RPA x CVT
where
HBA = number of HBA ports in one RPA
RPA = number of RPAs per RPA cluster
CVT = the number of CVTs (normally there will be one per back-end
VSAN; that is, one per fabric switch that supports SANTap services)
The control ITLs are created once and continue to reside on the same
DPP for their entire lifetime. To find on which DPP control ITLs were
created, at the switch command line:
# attach module <number of SSM module>
module-<SSM module number># show santap dpp vt-wwn <dpp
number>
If control ITLs were created on this DPP, a port WWN of type

CVT will appear.
Allocating ITLs to The data path processor (DPP) processes I/O traffic between the
DPPs front-end and back-end VSANs. A Storage Services Module (SSM)
contains 8 DPPs. Since each DPP can handle a limited amount of
traffic, it is useful to understand how traffic is allocated to DPPs.
When you create a data virtual target, the SAN switch allocates it to
the default DPP. To balance DPP load, it is necessary to create several
front-end VSANs and place DVTs in different VSANs (“Creating
DVTs” on page 12).
Each DVT is associated with one and only one storage target. When a
host initiator writes to storage, it accesses the DVT. The first time an
initiator accesses the DVT, the switch creates a virtual initiator
representing the host initiator and allocates it to the same DPP as the
DVT. If you wish the same host initiator to access a second DVT, that
DVT must also reside on the same front-end VSAN. It will then use
the same virtual initiator.
On the other hand, if you place a DVT on a different front-end VSAN,
the first host initiator will not be able to access it. You will need to
access it with a different host initiator.
To check allocation to DPPs, at the switch command line:

# show isapi virtual-nport database
Virtual ports will be listed with their DPP and VSAN. Find the Virtual
Targets (listed as VT) and note which DPP they run on.
Planning ITL resources Understanding the capabilities and limitations of the various parts of
on a DPP your solution is an important part of designing a successful and
reliable replication system. One of the most important parts of
planning a solution is to make sure that you remain within the limits
of ITLs per DPP.
The maximum number of ITLs consumed by one DPP is as follows:
◆ host ITLs: all host ITLs for the hosts and targets of the DVTs on
that DPP
◆ reservation ITLs: all reservation ITLs for the hosts and targets of
the DVT on that DPP
◆ all discovery ITLs
◆ all control ITLs (unless you know for sure that the control ITLs
were not created on this DPP; to discover on which DPP the
control ITLs reside, refer to “Counting control ITLs” on page 50)
This total number of ITLs must not exceed the maximum allowed per
DPP. If it does, the switch may behave unexpectedly or fail to create
the additional ITLs.
Counting ITLs on a DPP A data path processor (DPP) supports four Storage Services Module
ports. This section explains how to count the number of ITLs actually
used on one DPP. Remember that you must always leave enough
unused ITLs for discovery.
Reservation ITLs reside on the same DPP as the DVT and Virtual
Initiator associated with the host ITLs. In other words, host ITLs and
the corresponding reservation ITLs reside on the same DPP.
To count the ITLs on a DPP, at the switch command line:
# show isapi dpp <number of the DPP> queue | include LUN
| count
The number of ITLs running on this DPP will be displayed. DPPs are
numbered from 0–7.
Counting ITLs on an To count the ITLs on an SSM, at the switch command line:
SSM

# show isapi dpp all queue | include LUN | count
The number of ITLs running on the SSM will be displayed.
Identifying the initiator At times, you may need to know which host created specific ITLs; for
that created an ITL instance, when a host cannot see any LUNs (perhaps the ITLs could
not be created).
To determine the ITLs created by a specified host:
1. At the switch command line:
# show fcns database VSAN <VSAN number>
Note the initiator FC ID.

# show isapi virtual-nport database
Virtual ports will be listed with their DPP and VSAN. Find the
Virtual Targets (listed as VT) and note which DPP they run on.
# show isapi dpp <dpp number> queue | include vsan
For each host port, its FC ID and Virtual Target are shown. If there
are no entries, the host did not create any ITLs.
4. Repeat Step 2 on page 52 and Step 3 on page 52 to discover ITLs
associated with another Virtual Target on the same initiator.
5. Repeat Step 1 on page 52 through Step 4 on page 52 to discover
ITLs on another host.
Replacing a faulty host node host bus adapter
Strategies The strategies in Table 5 may be useful to increase the available

increasing available SANTap resources or decrease the number of SANTap resources
SANTap resources consumed.
Table 5 Strategies for increasing available SANTap resources
Strategy Effect
Adding a SANTap Greatly increases available SANTap resources.

switch
Reducing number of Whether by zoning, LUN masking, reducing number of initiators, or

paths reducing number of targets, reduces the number of host and
reservation ITLs.
Reducing the Reduces number of reservation and discovery ITLs.

number of RPA ports
Reducing the Reduces number of reservation and discovery ITLs.

number of RPAs.
Dividing RPAs into Zoning fewer initiator ports on the RPA.

zones

Use this procedure to replace a faulty host bus adapter (HBA) in a
host node and to reconfigure the SANTap and RecoverPoint
environments after the replacement. This procedure can also be used
to replace the entire host node.
NOTICE: Registering a new host initiator with a DVT creates new
ITLs. When an ITL is created, a host write to the LUN may occur
without RecoverPoint’s knowledge, corrupting the replica. In
consequence, creating ITLs triggers a volume sweep of the
corresponding storage LUNs (full sweep of the consistency
group), ensuring data consistency. As a result of the full sweep,
the journal is deleted. Replacing a host bus adapter should,
therefore, be done during a maintenance window when a full
sweep of a consistency group is acceptable.
1. Obtain the WWN of the faulty HBA from your system

administrator or by using the following command at the switch:
switch# show fcs database
2. Stop the applications writing to the host HBA port.

3. Shut down the faulty HBA port. Use the following commands at
the SANTap switch:
switch# config t
switch(config)# interface fc<SSM_slot_number>/<port_number>
switch(config-if)# shutdown
4. Verify that the faulty port has been shut down:

switch# show interface
fc<SSM_slot_number>/<port_number>

fc1/1 is down (Administratively down)
Hardware is Fibre Channel, 20:01:ac:16:5e:4a:00:00
vsan is 1
Port mode is E
Speed is 1 Gbps
Beacon is turned off
FCID is 0x0b0100
0 frames input, 0 bytes, 0 discards
0 runts, 0 jabber, 0 too long, 0 too short
0 input errors, 0 CRC, 0 invalid transmission words
0 address id, 0 delimiter
0 EOF abort, 0 fragmented, 0 unknown class
0 frames output, 0 bytes, 0 discards
Received 0 OLS, 0 LRR, 0 NOS, 0 loop inits
Transmitted 0 OLS, 0 LRR, 0 NOS, 0 loop inits
The interface should be listed, but marked “(Administratively

down)”.
5. Detach from the splitter all volumes that are being accessed via
that host HBA port.
6. Remove the ITLs associated with the host HBA port:
# clear santap module <SSM_slot_number> itl target-pwwn

<target-pWWN> host-pwwn <host_pWWN>
Repeat this step for each storage target pWWN that the host HBA
port logs in to. This step deletes ITLs that are the same as those of
the host HBA port and deletes the Virtual Initiator.
7. At the switch, make sure all initiators associated with the faulty
HBA have been removed:
switch# show fcns database VSAN <backend_VSAN_#> | inc

<faulty HBA WWN>
The switch response should be empty.

8. Allow enough time for the changes to be updated in the switch.
10. Verify that the ITLs of the faulty host HBA have been discarded
and no longer appear.
dvtlun | inc <faulty_host_HBA_pWWWN>
The switch should display an empty list.

11. Replace the faulty HBA card.
12. At the storage array:
a. Delete the WWNs of the faulty HBA.
b. Remove the LUN masking of the host initiators associated
with the faulty HBA.
c. Mask those LUNs to the host initiators associated with the
new HBA.
13. Enable the new host HBA port:
switch# config t
switch(config)# interface fc <module#/port#>
switch(config-if)# no shutdown
14. Verify that the switch sees the WWNs of the new HBA:
switch# show fcs database
15. Rezone the back-end and the front-end VSANs by replacing the
WWNs of the faulty HBA port with the WWNs of the new HBA
port. Follow the instructions in “Configuring zoning” on page 15.
16. Move the new host initiators to the back-end VSAN:

switch# config t
switch(config-vsan-db)# vsan <BackEnd_VSAN_Number>
interface fc <module#/port#>
Upgrading SANTap hardware and software
17. Reactivate the back-end and front-end zonesets:

switch# config t
switch(config)# zoneset activate name <zoneset_name>
vsan <vsan #>
switch(config)# exit
18. Verify that the host can access the LUNs via the new host HBA
port.
19. Move the new host initiator WWN to the front-end VSAN:
switch# config t
switch(config-vsan-db)# vsan <FrontEnd_VSAN_Number> interface fc <module#/port#>
20. Verify that the host can access all its volumes via the new host
HBA port.
21. After you have verified that all changes were successful, save the
changes:
22. At the RecoverPoint Management appliance, in the Navigation

pane, click Splitters. Double-click the splitter from which you
detached the volumes in Step 5 on page 54. Reattach all volumes
to the splitter.
The list of all ITLs seen by the RPA will be displayed.

The Cisco MDS 9000 Family SANTap with EMC RecoverPoint Migration
Guide and Cisco MDS 9000 NX-OS Release 4.1(x) and SAN-OS 3.3(x)
Software Upgrade and Downgrade Guide (available from

www.cisco.com) describe how to upgrade SANTap hardware and
software components used in the RecoverPoint environment. These
should be your first references for upgrading SANTap hardware and
software. This section includes a few specific procedures with slightly
more detail about the relevant procedures. The procedures in this
section are:
◆ Upgrading the Storage Services Interface....................................... 57
◆ Replacing a Storage Services Module.............................................. 60
◆ Storage Service Module replacement procedure ........................... 61
Upgrading the Use the following procedure to update the Storage Services Interface
Storage Services (SSI) of the SANTap switch.
Interface 1. The following procedure will cause a full resynchronization. If,
for business reasons, full synchronization is not acceptable, please
contact EMC Customer Service for alternative procedures.
2. Log in to the switch.
3. Determine whether the Storage Services Interface is running on
the bootflash or on the modflash of your Storage Services
Module. Use the following command:
switch# show run | include boot

boot kickstart bootflash://module-1/m9200-ek9-kickstart-mz.3.1.2.bin
boot system bootflash://module-1/m9200-ek9-mz.3.1.2.bin
boot ssi bootflash:/m9000-ek9-ssi-mz.3.1.2b.bin module 2
The last line indicates in this case that the Storage Services
Interface is running on the bootflash of Storage Services Module
#2.
4. Determine the version of the system and kickstart images
currently running on the switch:
switch# show version

Cisco Storage Area Networking Operating System (SAN-OS) Software
Software
BIOS: version 1.0.8
loader: version unavailable [last: 1.0(0.267c)]
kickstart: version 2.1(2) [build 2.1(2.47)] [gdb]

system: version 2.1(2) [build 2.1(2.47)] [gdb]
5. Check the release notes of your version of RecoverPoint to

determine the version of the system image, the kickstart image,
and the Software Services Interface image are required. You may
need to update the system image and the kickstart image (refer to
the configuration guide for your switch) before updating the
Storage Services Interface image.
6. Download the required version of the Storage Services Interface
image from Powerlink (powerlink.emc.com). If you need to
update the system image or the kickstart image, download also
those from Powerlink.
7. If connecting from an EMC service laptop, stop the BlackICE
firewall service.
8. Start an FTP server on the EMC service laptop connected to the
switch.
9. Use one of the following commands to determine if you have
enough space to install the required files (Storage Services
Interface image, and if required, kickstart and system image):
For bootflash:
switch# dir bootflash
For modflash:
switch# dir modflash//<SSM module #>-1/

12288 Jan 01 00:01:06 1980 lost+found/
14765056 Mar 21 15:35:06 2005 m9500-sf1ek9-kickstart-mz.2.1.1.bin
15944704 Apr 06 16:46:04 2005 m9500-sf1ek9-kickstart-mz.2.1.1a.bin
48063243 Mar 21 15:34:46 2005 m9500-sf1ek9-mz.2.1.1.bin
48036239 Apr 06 16:45:41 2005 m9500-sf1ek9-mz.2.1.1a.bin
Usage for bootflash://sup-local
141066240 bytes used
43493376 bytes free
184559616 bytes total
If you need to delete files to make room for the files that you need
to install, use the appropriate one of the following commands:
switch# delete bootflash:<filename>
switch# delete modflash:<filename>
10. Copy the files you wish to install. Use the appropriate one of the
following commands:
switch# copy ftp://<ftp server IP address>/<source
filename> bootflash:<destination filename>
switch# copy ftp://<ftp server IP

address>/<path>/<source filename>
modflash:<destination filename>
11. Verify that the installation images were copied successfully. Use
the appropriate one of the following commands:
switch# dir bootflash:
switch# dir modflash:
12. Modify the Storage Services Interface boot variable to install the
new image. Use the appropriate one of the following commands.
switch# install ssi bootflash:<filename>
switch# install ssi modflash:<filename>
13. Reload the module:

switch# reload module <SSM_Module_Number>
The reload command powers the SSM off and then on. Allow
approximately a minute to pass to give the switch GUI time to
update.
14. Verify that the new image is running:
switch# show module <SSM_slot_number>

--- ----- -------------------------------- ------------------ ------------
Mod Sw Hw World-Wide-Name(s) (WWN)

--- ----------- ------ --------------------------------------------------
2 3.0(2a) 5.0 20:41:00:0d:ec:18:b0:c0 to 20:60:00:0d:ec:18:b0:c0
Mod Application Image Description Application Image Version

-------- ----------------------------- -------------------------
2 SSI linecard image 3.0(2m)
Mod MAC-Address(es) Serial-Num
--- ------------------------------------- ----------

2 00-0d-ec-0e-d1-82 to 00-0d-ec-0e-d1-86 JAB090601GS
Verify that under Application Image Version, the new image of
the Storage Services Interface version is listed.
Replacing a Storage Use this procedure to replace a Storage Services Module in a SANTap
Services Module switch. The procedure is only valid if the replacement Storage
Services Module is in the same slot as the original one. Note the
following before attempting to replace a Storage Services Module:
◆ Replacing a Storage Services Module causes path failover.
◆ Replacing a Storage Services Module may cause full
resynchronization of storage replica volumes.
◆ If the replacement Storage Services Module has the same card ID
and goes into the same slot as the previous one, you may not need
to do anything except to check the SSI boot variable is correct.
Follow the procedure “Storage Service Module replacement
procedure” on page 61.
◆ Various types of Storage Services Modules exist for switches that
support SANTap services. These various types are
indistinguishable from each other visually and by the features
they support. The different types have, however, different card
IDs. When the replacement card ID is different from the original
one, control virtual targets, data virtual targets, and appliance
virtual targets will need to be recreated; that is, the procedures
“Deploying SANTap using the command-line interface” on
page 6 and “Creating the CVT” on page 9 must be performed
again after replacing the Storage Services Module card (“Storage
Service Module replacement procedure” on page 61). In addition,
the running-config for that slot will be deleted.
To determine the card ID, use one of the following commands:
switch# module internal info module <SSM slot #>
switch# platform internal info
The card ID is in the following format: 0x3 or 0x14.

◆ It is best practice to prepare a script to replace data virtual targets
(DVTs) before replacing a Storage Services Module.
If you replace a faulty (dead) Storage Services Module, you may

lose the NVRAM content (including the startup-config). The
reason this occurs is when the Storage Services Module is not
operating, its configuration is deleted. When you save the
configuration (switch# copy running-config start-config), you
are overwriting the start-config with an empty configuration. The
configuration contains, among other things, the data virtual
targets (DVTs) and the ITLs. By preparing a script in advance, you
can recreate these in seconds. The command to create DVTs is:
switch# config t
switch(config)# santap module <SSM slot #> dvt
target-pwwn <Storage_Port_WWN> target-vsan
<BackEnd_VSAN_#> dvt-name <DVT_Name> dvt-vsan
<FrontEnd_VSAN_#> lun-size-handling 1
Example:
cisco_switch(config)# santap module 2 dvt target-pwwn
50:06:04:8a:d5:f0:59:ef target-vsan 100 dvt-name MyDVT
dvt-vsan 200 lun-size-handling 1
Write the commands for creating the DVTs to a text file and save.
◆ If you have more than one Storage Services Module in the same
SANTap switch and it is running an older Storage Services
Interface, the Storage Services Module in an adjacent slot may
lose its configuration. If this occurs, use the script described in the
previous topic to restore the configuration. This issue was fixed in
later versions of the Storage Services Interface.
Storage Service 1. Determine whether the Storage Services Interface is on the

Module bootflash or on the modflash:
replacement switch# show run | include boot
procedure
boot kickstart bootflash://module-1/m9200-ek9-kickstart-mz.3.1.2.bin
boot system bootflash://module-1/m9200-ek9-mz.3.1.2.bin
boot ssi bootflash:/m9000-ek9-ssi-mz.3.1.2b.bin module 2
The last line indicates that in this case that the Storage Services
Interface is running on the bootflash of Storage Services Module
#2.
2. Power off the module to replace:
switch# config t
switch(config)# poweroff module <slot #>
3. Verify that the module is powered off:

switch(config)# do show module <slot #>
4. Replace the Storage Services Module. Do not turn off power to

the switch.
5. Power up the replaced module:
switch# config t
switch(config)# no poweroff module <slot #>
6. After the replaced module is powered up, verify that its status =
OK:
switch# config t
switch(config)# do show module <slot #>

--- ----- -------------------------------- ------------------
7. Check that the DVTs still exist:

switch# show santap module <slot #> dvt
DVT Information :
dvt pwwn = 22:00:00:20:37:88:20:ef
dvt nwwn = 20:00:00:20:37:88:20:ef
dvt id = 3
dvt mode = 3
dvt vsan = 3
dvt fp_port = 0
dvt if_index = 0x1080000
dvt name = MYDVT
8. If the DVTs no longer exist, use the script you created to restore
DVTs and the following procedure:
switch# config t
switch(config)#
Paste the script at the switch(config) command line. Use the

following command to verify that the DVTs were created
correctly:
switch# show santap module <slot #> dvt
Copyright © April 15, 2010 EMC Corporation. All rights reserved.
EMC believes the information in this publication is accurate as of its publication date.
The information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC

CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY
KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND
SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication
requires an applicable software license.
For the most up-to-date listing of EMC product names, see EMC Corporation
Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.

Technical Notes: Emc Recoverpoint Deploying Recoverpoint With Santap and San-Os

Uploaded by

Copyright:

Available Formats

You might also like

Technical Notes: Emc Recoverpoint Deploying Recoverpoint With Santap and San-Os

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technical Notes: Emc Recoverpoint Deploying Recoverpoint With Santap and San-Os

Uploaded by

Copyright:

Available Formats

EMC® RecoverPoint

Deploying RecoverPoint with SANTap

April 19, 2010

This document describes how to deploy RecoverPoint with Cisco

Scope This document is intended primarily for IT professionals with

SANTap concepts SANTap is a service supported on Storage Services Modules running

Figure 1 Schematic of fully deployed SANTap solution

◆ Data virtual target

Limitations When deploying RecoverPoint deployment with SANTap services,

◆ LUNs per DVT

Related documents The following documents provide additional information related to

RecoverPoint with After completing “Prerequisites” on page 5, RecoverPoint with

◆ Cisco Multilayer Director Switch with Storage Service Module

Deploying SANTap using the command-line interface

The switch displays information in the following format:

In the above example, the Storage Services Module slot number

Verifying SANTap ◆ Verify that the SANTap license is installed:

Make sure the STORAGE_SERVICES_ENABLER_PKG is

Enabling SANTap ◆ Enable SANTap service on the Storage Services Module:

The SSM module number was obtained in “Identifying the SSM

Figure 2 Default VSAN configuration

Use the following procedure to create VSANs:

Enter VSAN data configuration mode:

2. Create a front-end VSAN:

The example above creates a front-end VSAN with ID number

Creating the CVT 1. Create the CVT in the back-end VSAN:

Give the CVT a meaningful name.

Figure 3 Back-end VSAN configuration after creating CVT

The switch displays information in the following format:

4. Save the changes:

Configuring 1. If your SANTap environment does not include either an AIX or an

If your SANTap environment includes an AIX or HP-UX host,

The back-end VSAN FC ID will be displayed.

d. Set the domain ID for the front-end VSAN to be identical to

switch(config)# fcdomain domain <domain ID_of_vsan>

e. Restart the front-end VSAN:

f. Enable the persistent FC ID:

The switch responds:

g. To make FC IDs of storage devices the same in the front-end

Repeat this step for every DVT to be created in this VSAN.

The front-end VSAN FC ID will be displayed.

2. Save the changes:

create DVTs in different VSANs. To balance I/O load on DPPs, assign

Figure 4 System configuration after creation of DVT

2. Verify that the DVT was created correctly:

The switch displays information in the following format:

In the example given, the DVT in VSAN 200 is the virtual

b. To display the back-end VSAN FC ID:

Figure 5 System configuration after copying back-end zoning to front-end

switch(config)# vsan database

The above example moves the interface fc1/2 to the front-end

The switch displays information in the following format:

tgt vsan = 100

DVT LUN Information :

host pwwn = initiator

b. Confirm that zoning is correct and activated.

storage processors, receiving I/O traffic and SCSI commands from