Rev A01 September 02, 2010 - · PDF file2 EMC Celerra MirrorView/Synchronous Setup on CLARiiON...

These technical notes describe how to set up EMC MirrorView/Synchronous (MirrorView/S) in an NS gateway or NSX series Celerra Network Server environment by using CLARiiON CX Series back-end storage systems. Topics include:

◆ Overview ............................................................................................... 2◆ Restrictions ............................................................................................ 3◆ CLARiiON setup procedures............................................................ 17◆ Initial Celerra procedures.................................................................. 35

EMC®Celerra®

MirrorView™/Synchronous Setup onCLARiiON® Backends

Version 6.0

Technical NotesP/N 300-009-965

Rev A01

September 02, 2010

1

2

Overview

OverviewEMC® MirrorView™/Synchronous (MirrorView/S) is a limited-distance synchronous data mirroring facility that provides high-availability and disaster recovery for NS gateway and NSX series EMC Celerra® Network Servers with EMC CLARiiON® storage systems. MirrorView/S maintains a synchronized remote mirror of production data between source and destination Celerra/CLARiiON system pairs at separate locations.

Before the introduction of MirrorView/S in version 5.5.23, you had to use EMC Celerra Replicator™ for Celerra and CLARiiON MirrorView for open hosts. MirrorView/S support for Celerra now allows the use of a common replication technology for open hosts and Celerra, thereby reducing infrastructure and management costs by consolidating replication and by using a single replication tool.

MirrorView/S provides a complete disaster recovery configuration without data loss. It ensures that the MirrorView/S-protected file systems on an NS gateway or NSX series source Celerra Network Server are recoverable even if the source Celerra is unavailable or not functioning. MirrorView/S supports Celerra NS gateway and NSX series cabinet configurations only not integrated series or CNS cabinet configurations.

Note: The topology guide available on EMC Powerlink > Home > Support > Technical Documentation and Advisories > Topology Guide > Networked Storage Topology Guide contains additional information for configuring extended infrastructure.

This document describes the CLARiiON storage system configuration for MirrorView/S with Celerra. It identifies the key CLARiiON Navisphere® SecureCLI (naviseccli commands) and EMC Unisphere™ software tasks.

EMC Celerra MirrorView/Synchronous Setup on CLARiiON Backends Version 6.0 Technical Notes

Restrictions

The CLARiiON documentation available on the EMC Powerlink® website contain the most up-to-date information about the CLI or management interface options and MirrorView restrictions. The following documents provide more information on Navisphere CLI and Unisphere software:

◆ EMC Navisphere Command Line Interface (CLI) Reference

◆ EMC MirrorView/Synchronous Command Line Interface (CLI) Reference

◆ EMC Unisphere online help

The EMC NAS Support Matrix provides definitive information on supported software and hardware, such as backup software, Fibre Channel (FC) switches, and application support for Celerra network-attached (NAS) storage products.

Note: The EMC NAS Support Matrix is for EMC use only. Do not share this information with customers.

Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery describes the Celerra configuration tasks, such as initialization, failover activation, and restore operations, and as routine management for MirrorView/S. After establishing the CLARiiON storage systems, you, as an EMC Service Provider or EMC Customer Service, must establish the initial Celerra configuration for the customer, as described in “Initial Celerra procedures” on page 35.

RestrictionsThe following restrictions apply:

◆ You cannot upgrade to a MirrorView/S configuration if the mirroring configuration requirements exceed the current consistency group capacity depending on the back-end storage system. Table 1 on page 4 provides more information about various LUN configurations. Also, you cannot upgrade if you require a mix of mirrored and local storage to fit within current consistency group capacity.

◆ Although MirrorView/S is intended for new installations, you can upgrade the Celerra environment to a MirrorView/S configuration if:

3EMC Celerra MirrorView/Synchronous Setup on CLARiiON Backends Version 6.0 Technical Notes

4

Restrictions

• The Celerra system LUN requirements can be accommodated by various LUN configurations. Configuration is limited to 5, 13, 29, or 61 user data LUNs depending on the CLARiiON backend. Table 1 on page 4 lists the various user data LUN configurations.

• All Celerra system LUNs can be mirrored and fit in one MirrorView consistency group (device group) according to the group capacity.

◆ LUN limits are based on CLARiiON LUNs per consistency group limitations. Celerra requires three LUNs for system data. Special considerations must be made for the setup of the back-end array configuration by configuring large LUN sizes (up to 2 TB) in Celerra version 5.5 through version 5.6.43. In Celerra version 5.6.44, CLARiiON back-end array configurations support up to 16 TB LUNs.

◆ If existing LUNs are used, you must perform some of the CLARiiON storage system configuration tasks, such as creating the remote mirrors and establishing the MirrorView consistency group.

◆ The participating CLARiiONs must be CX Series storage systems with MirrorView/S consistency group support. This is available as of CLARiiON FLARE® release 19.

◆ The CLARiiONs must have Unisphere, MirrorView, and EMC Access Logix™ software installed and enabled.

Table 1 User LUN configuration details

Storage system User data LUNs

CX400/CX500/CX3-20/AX4-5 5 user data LUNs

CX600/CX700/CX3-80/CX3-40 13 user data LUNs

CX4-120 13 user data LUNs

CX4-120(/w Celerra version 5.6.47 or later)

29 user data LUNs

CX4-480/CX4-960 29 user data LUNs

CX4-480/CX4-960(/w Celerra version 5.6.47 or later)

61 user data LUNs


Restrictions

◆ EMC Solutions Enabler version 6.0.1 or later and the appropriate Celerra 5.6 release are required.

◆ All systems participating in the mirror must be in the same domain.

◆ Autoextend of checkpoint SavVol is not supported. If the SavVol fills to capacity, writes to the PFS continue and the oldest checkpoint gets deactivated.

◆ The MirrorView link established between the storage processors on the CLARiiON CX Series storage arrays (SPA-SPA, SPB-SPB) is usually on the highest-numbered port. Some examples are as follows:

• For CX700/600 or CX3-80, on port 3

• For CX500/400 or CX3-40, on port 1

Note: Do not share this port with host I/O. “MirrorView/S configuration through SP ports” on page 9 provides more information about these ports.

◆ MirrorView/S requires a CLARiiON MirrorView license. If the back-end array is licensed for MirrorView/S, there is no additional charge to replicate Celerra owned LUNs.

◆ MirrorView/S cannot be used in mixed CLARiiON storage system configurations. Only CLARiiON CX series and AX4-5 storage systems are permitted for MirrorView/S.

◆ MirrorView/S supports the Celerra Network Server NS series gateway and NSX series configurations only. It does not support the non FC-enabled NS integrated platforms or CNS cabinet configurations. The NS integrated platform cannot be used for MirrorView/S because it does not provide a FC port. Valid cabinet configurations include:

• NS-NS series gateway

• NSX-NSX

• NS series gateway-NSX

◆ MirrorView/S supports NS gateways storage platforms and FC-enabled Celerra platforms (for example, the NX4, NS20FC, NS40FC, NS80FC, NS-120, NS-480, NS-960, and NS-G8 platforms). Platforms with the Fibre Channel option must have the Fibre Channel option activated initially because there is no way to reassign the MirrorView port after initial persistent scan.


6

Restrictions

◆ A single MirrorView/S consistency group requires three LUNs as Celerra Control LUNs. The remaining LUNs are available as user data LUNs. Table 1 on page 4 provides more information about various LUN configurations. The LUN limit is per direction, or per consistency group, and is array-based. All mirrors in a consistency group must be in the same array.

◆ You must manually assign the LUN number (LUN ID) for any new LUNs. For user LUNs, the LUN ID must be 16 or greater. LUN IDs in the range 0 to 15 are reserved.

◆ MirrorView integration with Celerra does not support Virtually Provisioned CLARiiON Thin LUNs.

◆ For gateway configurations, only single back-end CLARiiON configurations are allowed.

◆ The distance between source and destination Control Station systems is limited to 60 km/36 miles or, with DWDM, up to 200 km.

◆ To optimize capacity, try to establish one LUN per RAID group, and when possible, try to avoid mixing source and destination LUNs in the same RAID group. “RAID restrictions for write intent log LUNs” on page 23 and “Restrictions for equivalent destination LUNs” on page 27 provide more information about RAID group and LUN requirements.

◆ Some of the configuration procedures require you to supply the host LUN ID or HLU, which is a virtual LUN number that the storage-system server sees, as well as the actual LUN number or ALU, which is the number assigned when binding the LUN. Pay careful attention to the control (system) HLU ID mapping requirements identified in the configuration steps. Source HLU IDs 0, 1, and 4 for the three source Control Station LUNs (dos, log, and nas LUNs, respectively) must be mapped to destination control LUNs with HLU IDs 6, 7, and 9, respectively. Table 2 on


Restrictions

page 7 summarizes these required HLU ID mappings for the three control LUNs. There are no such restrictions for the ALU IDs.

◆ For MirrorView/S with Celerra, CLARiiON source LUNs and equivalent destination LUNs must be the same size, be owned by the same storage processor, and have the same RAID type and configuration (for example, both 4+1 RAID 5).

◆ You can set up only global user accounts (scope 0) for MirrorView/S, not local accounts.

◆ Celerra Replicator (V2) works with disaster recovery replication products such as EMC SRDF®/Synchronous (SRDF/S) and SRDF/Asynchronous (SRDF/A) or MirrorView/Synchronous (MirrorView/S). You can run SRDF or MirrorView/S products and Celerra Replicator (V2) on the same data. However, if there is an SRDF or MirrorView/S site failover, you cannot manage Replicator (V2) sessions on the SRDF or MirrorView/S failover site. Existing Replicator (V2) sessions will continue to run on the failed-over Data Mover and data will still be replicated. On the primary site, you can continue to manage your SRDF or MirrorView/S replication sessions after the restore.

◆ Basic hardware and software requirements as well as the Celerra MirrorView procedures for initialization, failover activation, and restoration are described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery. For general MirrorView family information, see the CLARiiON MirrorView documentation available on EMC Powerlink, including the EMC MirrorView Command Line Interface (CLI) Reference.

Table 2 Required host LUN ID mapping for control (system) LUNs

Control LUN Source HLU ID Destination HLU ID

dos 0 6

log 1 7

nas 4 9


8

Restrictions

Note: MirrorView/S with Celerra is associated with the disk types CMSTD and CMATA and the following AVM storage pools: cm_r1, cm_r5_performance, cm_r5_economy, cmata_archive, and cmata_r3. These are visible from the Unisphere software or from NAS commands such as nas_disk and nas_pool.

Planning considerations and conventions

While performing back-end setup procedures, you need to track key configuration information:

◆ Celerra Control Station information, such as the source and destination names and IP addresses.

◆ CLARiiON storage names at the source and destination sites.

◆ Consistency group name (for example, cg_new_york).

◆ HLU IDs and ALU IDs (meeting the HLU ID requirements outlined in Table 2 on page 7).

◆ RAID group IDs, following the restrictions described in “RAID restrictions for write intent log LUNs” on page 23 and “Restrictions for equivalent destination LUNs” on page 27.

◆ Mirror names.

◆ Data Mover names and types at both the source and destination, with compatible Data Movers and compatible number of used network interface ports used on both sides. If you need to mask an unused network port, use the procedure summarized in “Making the Data Mover network device configuration compatible” on page 14.

In addition, keep track of the following accounts and passwords:

◆ The global CLARiiON back-end storage account and password (for example nasadmin), which must be associated with CLARiiON Manager or higher privileges (to manage all storage-system settings in the domain). After this global account information is set up, you can view it in the Unisphere software by selecting the local domain, then right-click Properties. The username and password display as domain properties.

◆ The password you plan to provide with the nas_cel -create command on each Celerra (for example, nasadmin), as part of the preinitialization procedures, as described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery. This password must be the same on both Celerra.


Restrictions

◆ The remote administration account and password (for example, dradmin) you plan to provide with the /nas/sbin/nas_mview -init command as part of the MirrorView initialization procedures, as described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery.

MirrorView/Sconfiguration through

SP ports

MirrorView/A and MirrorView/S connections can be configured through SP Fibre Channel MirrorView ports only for CX3-20, CX3-20f, CX3-40, CX3-40f, CX3-80, CX400, CX500, CX600, CX700, or AX4-5 storage systems, and through SP Fibre Channel and/or iSCSI MirrorView ports for CX4-120, CX4-240, CX4-480, CX4-960, CX3-10c, CX3-20c, or CX3-40c storage systems. Table 3 and Table 4 on page 9 show the SP MirrorView ports for each storage system.

Table 3 SP MirrorView ports for the CX4 series

Storagesystem

MirrorView Fibre Channel FEports MirrorView iSCSI FE ports

Logical port ID Physical slot andport number

Logical port ID Physical slot andport number

CX4-120,CX4-240

A-1 slot A0 port 3 A-3 slot A1 port 1

B-1 slot B0 port 3 B-3 slot B1 port 1

CX4-480,CX4-960

A-3 slot A1 port 3 A-5 slot A4 port 1

B-3 slot B1 port 3 B-5 slot B4 port 1

Table 4 SP MirrorView ports for various storage systems

Storage system SP MirrorView port

Fibre Channel iSCSI

CX3-20, CX3-20f, CX3-40, CX3-40f, CX400, CX500,AX4-5

Port 1 N/A

CX3-80, CX600, CX700

Port 3 N/A

CX3-10c Port 3 Port 1

CX3-20c, CX3-40c Port 5 Port 3


10

Restrictions

Note: CX3-10c, CX3-20c, or CX3-40c storage systems must run FLARE 03.26.xxx.5.yyy or later.

For Fibre Channel MirrorView connections, the SP A and SP B Fibre Channel MirrorView ports (listed in table) on both the primary and secondary storage systems must run at the same Fibre Channel link speed.

You may use the same SP port for server data and MirrorView/A or MirrorView/S. Users should be cautious about sharing ports between MirrorView and server traffic when an IP distance connection is used because sharing the MirrorView port with server traffic may cause a degradation in both replication and server application performance. SP port Fibre Channel connections are of the following two types:

◆ SP port Fibre Channel direct connections — Direct Fibre Channel connection between the SP A MirrorView ports on the primary and secondary storage systems and between the SP B MirrorView ports on the primary and secondary storage systems.

◆ SP port Fibre Channel switch connections — These have two Fibre Channel switch zones:

• One zone with SP A MirrorView ports on both the primary and secondary storage systems

• One zone with SP B MirrorView ports on both the primary and secondary storage systems

If a server HBA port uses an SP MirrorView port for server I/O, it should be included in a separate zone.

◆ SP port iSCSI connections — iSCSI connections between the SP A MirrorView ports on the primary and secondary storage systems and between the SP B MirrorView ports on the primary and secondary storage systems.

Note: A storage system can have mirroring connections to a maximum of four other storage systems concurrently.

While configuring Fibre Channel ports, remember the following:

◆ A CLARiiON CX4 supports up to one Fibre Channel-based MirrorView/S port and up to one iSCSI-based MirrorView/S port (per SP).


Restrictions

◆ A CLARiiON Fibre Channel MirrorView/S port number is designated at the time the first set of Fibre Channel front-end ports are persisted, whether or not a MirrorView/S enabler is present:

• The MirrorView/S port is usually the highest-numbered port at that time.

• The CLARiiON Fibre Channel MirrorView/S port will not be active until a MirrorView/S-related enabler is installed.

◆ The CLARiiON Fibre Channel MirrorView/S port number never changes even when more Fibre Channel front-end ports are persisted with later.

While configuring iSCSI ports, remember the following:

◆ The iSCSI MirrorView/S port is designated at the time the first set of iSCSI ports are configured.

◆ It is usually the highest-numbered iSCSI front-end port at that time.

◆ The CLARiiON iSCSI MirrorView/S port will not be active until a MirrorView/S-related enabler is installed.

◆ You cannot actively mirror from one array to another array over both iSCSI and Fibre Channel MirrorView/S connections on the same system and at the same time.

You can switch connectivity between Fibre Channel and iSCSI without having to change or destroy the mirror (it will be fractured while the connectivity type is changed).

If you have three arrays, you can have a mirror with two secondary images—one mirroring over iSCSI and the other mirroring over Fibre Channel.

Configuration planning sheet

The configuration planning sheet in Table 5 on page 12 can help you keep track of the key MirrorView configuration information. Refer to the related tasks for information about selecting LUNs and associated RAID group IDs.

Note: For an active/active’ configuration, use a second configuration planning sheet to track your information.


12

Restrictions

Table 5 MirrorView/S configuration planning sheet (page 1 of 3)

Control Station information

Src Control Station Name:

Src IP: Dest. Control Station Name:

Dest. IP:

CLARiiON storage

Src (APM #): Dest. (APM #)

Consistency group

Group name:

Write intent log LUNs

Src Write Intent Log LUN on SPA and unique RAID group ID (RG ID) Example: 4094, RG ID 2

Src Write Intent Log LUN on SPB and unique RG ID Example: 4095, RG ID 3

Dest. Write Intent Log LUN on SPA and RAID group ID (RG ID)

Dest. Write Intent Log LUN on SPB and RG ID

Mirrors in group (CX400/500, up to 8)

RAID group ID (RG ID):

HLU: ALU: Mirror Name:

RG ID (for the equiv. dest.

control LUNs, don’t use RG ID for dest.

system’s own control LUNs)

ALU: HLU:

1. 0 6

2. 1 7

3. 4 9

4.

5.

6.

7.

8.


Restrictions

Mirrors 9-16 apply to CX600/700, CX3-40, CX3-80

9.

10.

11.

12.

13.

14.

15.

16.

Data Movers Source: Type: Dest: Type:

----> ---->

----> ---->

----> ---->

----> ---->

----> ---->

Accounts and Passwords

Username (or Celerra name for nas_cel):

Password:



14

Restrictions

Making the Data Mover network device configuration compatible

The MirrorView/S initialization procedures check for and enforce Data Mover compatibility (including network device configuration compatibility) between the source Data Movers configured for disaster recovery and the standby Data Movers at the destination.

Note: The EMC NAS Support Matrix contains detailed information about Data Mover compatibility.

If the source Data Mover with a remote MirrorView standby Data Mover also has a local standby Data Mover, that local standby must have a remote MirrorView standby Data Mover at the destination site. This prevents issues with failover.

A source Data Mover and remote standby Data Mover must appear to have the same network device configuration. To ensure network device compatibility and prevent users from seeing a destination Data Mover condition of not compatible during initialization, you can edit the file /nas/site/nas_param to specify a system parameter called hidden_interfaces. This parameter enables you to specify a list of device names that need to be masked in order to make the Data Movers in each cabinet appear to have the same network device configuration.

Global CLARiiON account (Manager or higher privileges)

Control Station- to-Control Station setup with nas_cel (must be same on both sides)

Remote Administration account with /nas/sbin/ nas_mview -init



Restrictions

Use the procedure in Table 6 on page 15 to use the hidden_interfaces parameter.

Note: Ensure that you do not edit anything in /nas/sys.

Table 6 Using the hidden_interfaces parameter in nas_param

Step Action

1. Log in to the source Control Station.

2. Open the file/nas/site/nas_param with a text editor.A short list of configuration lines appears.

3. Edit the file to specify the hidden_interfaces parameter with a list of devices to be hidden. If you need to specify multiple devices, use a comma-separated list (for example, cge6, cge5). The list you supply applies to all Data Movers in the system. For example, with a source NS702G, which has six cge (copper-wire Ethernet) ports, and a destination NSX, which has five cge ports, the hidden_interfaces parameter can be specified to mask (hide) cge6, if it is unused on all of the source Data Movers:hidden_interfaces:cge6:

Note: Ensure you do not add a blank line to this file.

In the /nas/site/nas_param file on the NS702G, this logically hides the cge6 network port on all Data Movers from all Celerra user interfaces, including Unisphere and the Celerra command server_sysconfig server_x –pci <device>.

4. Save and close the file.

Note: Changing this value does not require a Data Mover or Control Station restart.


16

Restrictions

To help troubleshoot a Data Mover condition of not compatible, you can set the NAS_DB_DEBUG=1 variable. Then, when the /nas/sbin/nas_mview –init command runs and you see not compatible on the destination server menu, you also see the names of the device that the incompatible Data Mover is missing. You can also use the hidden_interfaces parameter to test the not compatible state on your systems.

In addition, you can have the /nas/log/symapi.log file capture verbose debug logs for MirrorView/S consistency group operations (by setting CLARAPI_DEBUG=1).

Configuration change guidelines

If you need to change your CLARiiON storage configuration after initial configuration, observe the following guidelines:

◆ After initial setup, if you want to perform configuration changes such as adding remote mirrors to the consistency group, you must rerun the /nas/sbin/nas_mview -init command after the change. Any storage configuration change that affects any of the mirrors, storage groups, or consistency groups used by the Celerra Network Server requires you to rerun the /nas/sbin/nas_mview -init command.

◆ If you change the global CLARiiON account password, you must update the NAS storage security information on the Control Station. After initialization, you can capture this change by rerunning /nas/sbin/nas_mview -init; after a failover, you must use the nas_storage command with the -modify option. Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery provides more information.

◆ Prior to a failover, you can make back-end configuration changes and simply rerun /nas/sbin/nas_mview -init from the destination Celerra to capture the changes. However, if a failover has been activated, do not make any back-end configuration changes that affect any of the mirrors, storage groups, or consistency groups used by the Celerra Network Server.

◆ In general, the name of the MirrorView/S consistency group should not be changed after initial configuration. If you do change the name of the MirrorView consistency group on the CLARiiON backend after initialization on the Celerra, you must perform a procedure to correct the Celerra device group configuration before performing any MirrorView/S operations. This procedure, which is described in EMC Knowledgebase emc138372, involves


CLARiiON setup procedures

special nas_devicegroup command usage to delete the device groups visible to each Celerra, followed by a rerun of initialization on the appropriate Celerra to pick up the correct device group name information. For an active/active’ configuration, initialization is rerun on both the Celerra after the device groups are deleted.

Note: If you do not perform this procedure and a failover is subsequently activated, the activation fails and you must perform the procedure to recover.

CLARiiON setup proceduresTo configure your CLARiiON back-end systems for MirrorView/S with Celerra, you can perform a set of procedures by using either the Navisphere command line interface (CLI) or Unisphere software. Table 7 on page 18 summarizes the configuration tasks that must be performed on the source and destination CLARiiON backends. Each section that follows describes a particular step.

The steps and examples use the following conventions:

◆ The source CLARiiON is APM00055003968_src, which uses aviator-spa as Storage Processor A (SPA) with an IP address of 10.6.4.225 and aviator-spb as Storage Processor B (SPB) with an IP address of 10.6.4.226. Therefore, the source storage system is represented by the hostname aviator-spa in many CLI examples.

◆ The destination CLARiiON is APM00055105668_dst, which uses element-spa as SPA with an IP address 10.6.1.112 and element-spb as SPB with an IP address 10.6.1.115. The destination storage system is represented by the hostname element-spa in many CLI examples.

◆ A global account is set up for both back-end systems with the username as nasadmin and the password as nasadmin. When you run the naviseccli command, as shown in the examples throughout this document, the command uses this global account (not a Celerra user account), and you can run the command as a regular Linux user as long as you have execute access to naviseccli (all users).

Note: For every standard Unisphere software configuration, many of the steps have pop-up messages that prompt you to confirm your configuration.


18


Active/passive versus active/active’ configuration

Perform the setup procedures based on whether you are building an active/passive (unidirectional) or active/active’ (bidirectional mirroring) configuration, as follows:

Note: An active/active’ configuration, in which two production sites serve as the standby for the other, can be viewed as two separate active/passive configurations. In an active/active’ configuration, each source provides access to its source images; each source’s equivalent secondary images are only accessible after a failover.

◆ For an active/passive (unidirectional) configuration, perform steps 1–10, as listed in Table 7 on page 18. This completes the back-end setup for an active/passive configuration.

◆ For an active/active’ (bidirectional) configuration:

• Perform steps 1–10 with one CLARiiON as the source and another as the destination.

• Perform steps 4–10 again, but this time with the previous destination as the source and the previous source as the destination. (You do not have to perform steps 1–3 again.)

Note: When you create the second consistency group, ensure to give it a unique name (for example, cg_new_jersey).

Table 7 Overview of back-end configuration tasks for MirrorView/S (page 1 of 2)

Task Action Procedure

1. Establish a single domain with the source and destination arrays.

“Task 1: Establish a domain with the source and destination arrays” on page 19

2. Establish the MirrorView/S connection between the source and destination arrays.

“Task 2: Establish the MirrorView/S connection (perform on either system)” on page 21

3. Allocate LUNs for the write intent logs. “Task 3: Allocate LUNs for the write intent logs (perform on source, then destination)” on page 22

4. Prepare the source LUNs. “Task 4: Prepare the source LUNs (perform on source)” on page 25



Task 1: Establish a domain with the source and destination arrays

To start the back-end configuration process, you must have a single domain with the source and destination storage arrays. You perform this procedure only once.

Note: If you already have a domain, you do not have to create one. However, ensure that all devices participating in the mirror are in the same domain.

As part of this task, perform these steps:

1. Set up a domain and establish the destination storage system SP as the master storage system in the domain (using a global user account). Selecting the destination system as the master ensures that you can continue to manage the configuration if the source becomes unavailable.

2. Add the other storage system to the domain. (In essence, you are adding components to the local domain.)

5. Prepare the equivalent destination LUNs. “Task 5: Create equivalent destination LUNs (in Unisphere, perform on source)” on page 27

6. For each source LUN on the source-site storage system, create a remote mirror.

“Task 6: Create a remote mirror for each source LUN (perform on source)” on page 29

7. To each remote mirror, add the appropriate destination LUN.

“Task 7: Add the destination LUNs to the appropriate mirrors (perform on source)” on page 30

8. Assign the destination LUNs to the destination Celerra’s storage group.

“Task 8: Assign destination LUNs to the destination Celerra storage group (perform on destination)” on page 31

9. From the source site, create a MirrorView/S consistency group. (In an active/active’ configuration, there are two consistency groups.)

“Task 9: Create the MirrorView/S consistency group (perform on source)” on page 32

10. Add all of the synchronized remote mirrors (mirror pairs) to the group, including the three mirrors for the Control Station LUNs (dos, log, and nas).

“Task 10: Add all remote mirrors to the consistency group (perform on source)” on page 34

Table 7 Overview of back-end configuration tasks for MirrorView/S (page 2 of 2)

Task Action Procedure


20


Using Unisphere To create a domain with the source and destination arrays:

1. On the main Unisphere page, from the All Systems > Domains task list, select Select Domain Master.

2. From the Select Master dialog box, select the storage system storage processor that should be the master, the destination system SPA. A master is identified by its IP address (in this case, SPA 10.6.4.112 on the destination system). Selecting the destination system SP as the master enables you to continue Unisphere management if the source system becomes unavailable.

3. From All Systems > Domains, in the Local Domain task list, click Add/Remove Systems, and then click Add in the dialog box.

4. Type the IP address of the system you want to add.

Note: You should supply the IP address in this step instead of scanning for a subnet. If you scan for a subnet, and the destination is already in a local domain, you must remove it from that domain before continuing.

Using Navisphere CLI(naviseccli)

To create a domain with the source and destination arrays (which enables you to add components to a local domain):

1. To set the master storage system in the new domain with a global user account, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 domain -setmaster <IPAddr>

Note: You must use a -scope value of 0 for the global user account. You can alternatively specify -address <address> instead of -h with <hostname>.

2. To add the other storage system to the domain, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 domain -add <IPAddr>

Example (executed with the destination system’s SPA, element-spa, as the master and adding the source to the domain by using its SPA IP address):

$ /nas/opt/Navisphere/bin/naviseccli -h element-spa -user nasadmin -password nasadmin -scope 0 domain -setmaster 10.6.1.112



$ /nas/opt/Navisphere/bin/naviseccli -h element-spa -user nasadmin -password nasadmin -scope 0 domain -add 10.6.4.225

Task 2: Establish the MirrorView/S connection (perform on either system)

You must establish the MirrorView/S logical connection between the source and destination storage arrays before any data can be mirrored. You perform this procedure only once.

Note: The MirrorView links connecting the storage processors on the arrays usually use the highest-numbered port (port 3 for CX700/600 and CX-3-80; port 1 for CX500/400 and CX3-40). “MirrorView/S configuration through SP ports” on page 9 provides more information about these ports.

This procedure creates paths for both storage processors in both storage systems (source SPA to destination SPA and destination SPA to source SPA, source SPB to destination SPB and destination SPB to source SPB). This assumes that both SPAs are physically connected and both SPBs are physically connected.

Using Unisphere To establish the MirrorView/S connection:

1. In the systems drop-down list, select the storage system for which you want to manage MirrorView connections (in this example, the destination, APM00055105668_dst). For this procedure, it does not matter whether you select the source or the destination storage system.

2. Select Replicas > Mirrors.

3. From the task list, under Configuration and Settings select Manage Mirror Connections.

4. In the Manage MirrorView Connections dialog box, select and enable the connection to the other storage system in the MirrorView/S pair.


To establish the MirrorView connection (path), type the following naviseccli command:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 mirror -enablepath <IPAddr>

Note: You must use a -scope value of 0 (for global users) for MirrorView/S.

Example (executed from the destination system to the source, by using the source SPA IP address to enable the path):


22


$ /nas/opt/Navisphere/bin/naviseccli -h element-spa -user nasadmin -Password nasadmin -scope 0 mirror -enablepath 10.6.4.225

Task 3: Allocate LUNs for the write intent logs (perform on source, then destination)

As part of your MirrorView/S configuration, you must allocate LUNs for the write intent logs, first on the source, and then on the destination. The write intent log is a record of recent changes to the source LUN, stored in persistent memory on a private LUN. If the source storage system fails (not catastrophically), the write intent log can be used to synchronize the destination LUNs when the source becomes available.

Note: Write intent logs are not part of the mirrored configuration.

This procedure involves creating a MirrorView write intent LUN for Storage Processor A and Storage Processor B (128 MB each) on each storage system. You can specify any existing LUN that is not part of a storage group and is not a hot spare, or you can bind a new LUN.

Note: If the storage system supports RAID groups, you must create the RAID group before you can create a LUN. To help you plan the use of RAID groups, ensure that you read “RAID restrictions for write intent log LUNs” on page 23 to learn about the RAID group restrictions for write intent log LUNs and “Restrictions for equivalent destination LUNs” on page 27 to learn about the restrictions associated with the equivalent destination LUNs of the source LUNs.

As part of this procedure, you perform the following steps, first on the source storage system and then on the destination storage system:

1. First on the source system and then on the destination system, bind a LUN on Storage Processor A and another LUN on Storage Processor B (for example, LUNs 4094 and 4095).

Note: Skip this step if you are using an existing LUN on each system.

2. On the source system, allocate LUNs for the SPA and SPB write intent logs (for example, LUN 4094 for SPA and LUN 4095 for SPB).

3. On the destination system, allocate LUNs for the SPA and SPB write intent logs.



RAID restrictions forwrite intent log LUNs

The restrictions to select the RAID group of a given type for a write intent log LUN are as follows:

◆ Do not put the write intent log LUNs in the system RAID group (that is the group with the system’s control LUNs, such as RAID group 0). For example, if the source CLARiiON uses RAID group 0 for the control LUNs 0, 1 and 4, select a unique RAID group ID other than 0 for a write intent log LUN, such as 2.

❑ Check this box to indicate that your SPA and SPB write intent logs do not use the same RAID group ID as the system’s control LUNs.

◆ Ensure the write intent log LUNs for SPA and SPB on the given system are in different RAID groups. For example, the write intent log LUN for source SPA could be in RAID group 2 and the write intent log LUN for source SPB could be in RAID group 3. This prevents a RAID group on a system from containing the other SP’s write intent LUN.

❑ Check this box to indicate that your SPA and SPB write intent logs use different RAID group IDs.

Additional guidelinesfor RAID groups

The guidelines to select the best RAID group of a given type for a write intent log LUN are as follows:

◆ Select a RAID group that contains the fewest server-visible LUNs (including clones and mirror images that are not yet in any storage group).

◆ Select a RAID group that contains the most free space.

◆ Select a RAID group that contains the least LUNs.

◆ Select a RAID group that contains the most LUNs whose default owning SP matches the one for which this write intent LUN is being created.

Using Unisphere To bind a LUN and allocate the write intent logs, do the following on the source system and then on the destination system:

1. In the systems drop-down list, select the storage system for which you want to bind a LUN.

2. Select Storage > LUNS. From the task list, under LUNs, select Create LUN.

3. In the General tab, under Storage Pool Properties, select RAID Group.


24


4. In the Create LUN dialog box, specify the RAID type, the RAID Group ID, and LUN properties. Ensure that you select a LUN size of 128 MB. When you are done, click Apply.

The first write intent log uses LUN 4094 in a RAID group ID of 2. Then a second write intent log uses LUN 4095 and a different RAID group ID (RAID group ID 3).

5. In the systems drop-down list, select the storage system with MirrorView installed and for which you want to configure the Write Intent Log.


7. From the task list, under Configuration and Settings, select Configure Mirror Write Intent Log.

8. The Allocate Write Intent Log dialog box appears.

Note: If the write intent log is already allocated, Allocate Write Intent Log changes to Deallocate Write Intent Log, you can select if you need to move the write intent log to a different LUN.

9. Allocate a LUN for the write intent log by moving a LUN from the Available LUNs list to the LUNs Selected to Allocate for Write Intent Log list by selecting the LUN, and clicking Add. For example, you could select LUNs 4094 and 4095.

Note: Remember to perform similar procedures to allocate the write intent log LUNs on the destination system.



Using Navisphere CLI To bind a LUN, perform the following on both the source system and on the destination:

1. Type the following Navisphere CLI command to bind a LUN, thereby enabling the read cache and write cache, setting the size qualifier to MB, and setting the capacity to 128 MB:

$ /nas/opt/Navisphere/bin/naviseccli -h

<IP_address_or_hostname_of_SP A> -user <username>

-password <password> -scope 0 bind <raid-type

[lun-number]> -rg <rgID> -rc 1 -wc 1 -sp <a|b> -sq mb -cap 128

2. Type the following naviseccli command to allocate the write intent logs (for example, using LUN numbers 4094 and 4095):

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username>

-password <password> -scope 0 mirror -sync

-allocatelog -spA 4094 -spB 4095

Example (on the source storage system):

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 bind r5 4094 -rg 2 -rc 1 -wc 1 -sp a -sq mb -cap 128

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 bind r5 4095 -rg 3 -rc 1 -wc 1 -sp b -sq mb -cap 128

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 mirror -sync -allocatelog -spA 4094 -spB 4095

Remember to execute similar commands to allocate the write intent log LUNs on the destination system.

Task 4: Prepare the source LUNs (perform on source)

To prepare a source LUN, you must perform the following steps on the source storage system:

Note: A source LUN represents a primary image.

1. If a source LUN does not exist, bind it on the source storage system.

2. Assign the LUN to the source Celerra storage group. You can skip this step if the LUN is already in the source Celerra storage group.


26


Note: As part of the basic CLARiiON setup procedures, you should already have three source Control Station LUNs numbered 0, 1, and 4 for the dos (Microsoft DOS partition), log, and nas LUNs, respectively. For this back-end procedure, you must prepare your user data LUNs. Table 1 on page 4 provides more information about various LUN configurations. Available (unreserved) LUN numbers start at 16.

Using Unisphere To bind and assign a LUN to the source Control Station’s storage group, perform the following:

1. In the systems drop-down list, select the source storage system for which you want to bind a LUN.

2. Select Storage > LUNS. From the task list, under LUNs, select Create LUN.

3. In the General tab, under Storage Pool Properties, select RAID Group.

4. In the Create LUN dialog box, specify the RAID type, the RAID Group ID (for example, 1), and LUN properties. When you are done, click Apply.

5. In the systems drop-down list on the menu bar, select the source storage system.

6. Click Storage > Storage Groups to navigate to the source system’s Storage Groups, then navigate to the source Control Station's storage group:

a. Right-click the source Control Station’s storage group and select Select LUNs.

b. In the Storage Group Properties dialog box, select the appropriate LUNs by moving them from the Available LUNs list to the Selected LUNs list.

Using Navisphere CLI To bind a LUN and assign the LUN to the source Celerra’s storage group, perform the following:

1. Type the following command to bind a LUN:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 bind <raid-type [lun-number]> -rg <rgID> -rc <0|1> -wc <0|1> -sp <a|b> -sq <mb|gb> -cap <size>



2. Type the following command to assign the source image LUN to the source Celerra's storage group. This command specifies a host LUN number (the number that the storage-system server sees, a virtual LUN number) as well as the actual LUN number (the number assigned when the LUN was bound):

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 storagegroup -addhlu -gname <group-name> -hlu <hlu-number> -alu <alu-number>

Example (for user LUNs 16 and 17 on the source system):

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 bind r5 16 -rg 1 -rc 1 -wc 1 -sp a -sq gb -cap 1

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 bind r5 17 -rg 1 -rc 1 -wc 1 -sp a -sq gb -cap 1

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 storagegroup -addhlu -gname Celerra_aviator -hlu 16 -alu 16

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 storagegroup -addhlu -gname Celerra_aviator -hlu 17 -alu 17

Task 5: Create equivalent destination LUNs (in Unisphere, perform on source)

For each source LUN on the source storage system, you must create an equivalent destination LUN on the destination storage system. You perform this task from the source system.

A destination LUN represents a secondary image.

Note: As part of this process, wait for the destination LUN to finish binding, and do not assign the destination LUN to any storage group until task 8.

Restrictions forequivalent destination

LUNs

Observe the following restrictions when selecting the RAID group and/or HLU IDs for an equivalent destination LUN:

◆ A source LUN and its equivalent destination LUN must be the same size, owned by the same storage processor, and have the same RAID type and configuration as the source (for example, both 4+1 RAID 5). If you use the Unisphere software, the destination LUN created is of the same size as its source LUN.


28


◆ For control LUNs: Ensure that the equivalent destination control LUNs (with HLU IDs 6, 7, and 9 to represent the secondary images of the source control LUNs 0, 1, and 4), reside in a RAID group other than the one used for the destination system’s own control LUNs. For example, if the destination system’s own control LUNs are already using RAID group 0, you can use a RAID group such as 3 for the equivalent destination control LUNs.

❑ Check this box to indicate your equivalent destination control LUNs reside in a different RAID group from the destination system’s own control LUNs and the HLU IDs are 6, 7, and 9.

◆ For user data LUNs: There are no specific restrictions for RAID group IDs, but use an HLU ID of 16 or higher (0–15 are reserved) based on what is available. In a new install, you might want to make the ALU match the HLU ID for simplicity.

❑ Check this box to verify that the user LUNs use an HLU ID of 16 or higher.

Guidelines forselecting the best

RAID group

The guidelines to select the best RAID group of a given type are as follows:

◆ Select a RAID group that contains the fewest server-visible LUNs (including clones and mirror images that are not yet in any storage group).

◆ Select a RAID group that uses the same number of drives as the source mirror image LUN’s RAID group.

◆ Select a RAID group that contains the most free space.

◆ Select a RAID group that contains the fewest LUNs.

◆ Select a RAID group that contains the most LUNs whose default owning SP matches the default owner of the source mirror image LUN.

Using Unisphere To create each destination LUN:

1. In the systems drop-down list, select the source storage system.

2. Click Storage > LUNs to navigate to the LUN for which you want to create the secondary image.

3. Right-click the LUN and select MirrorView > Create Secondary Image LUN.



4. The Create Secondary Image LUN dialog box that appears enables you to automatically create a destination LUN that is the same size as the source LUN (for example, the dos control LUN on both systems). Select an existing RAID group or create a new one based on your configuration and planning sheet.

Using Navisphere CLI To create the equivalent destination LUN of a source LUN, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 bind <raid-type [lun-number]> -rg <rgID> -rc <0|1> -wc <0|1> -sp <a|b> -sq <mb|gb> -cap <same-size-as-primary>

Example (equivalent destination control dos LUN ALU ID 17 the same size as source dos control LUN 0, and in RAID group 3):

$ /nas/opt/Navisphere/bin/naviseccli -h element-spa -user nasadmin -password nasadmin -scope 0 bind r5 17 -rg 3 -rc 1 -wc 1 -sp a -sq gb -cap 11

Task 6: Create a remote mirror for each source LUN (perform on source)

For each source LUN on the source storage system (for example, source control LUNs 0, 1, and 4, as well as the user data LUNs), you must create a remote mirror.

Note: Ensure that you use the write intent log for each remote mirror that you create.

Using Unisphere To create a remote mirror for a source LUN:


1. Navigate to the source LUN for which you want to create a remote mirror (for example, dos LUN0).

2. Right-click the LUN and select MirrorView > Create Remote Mirror.

3. In the Create Remote Mirror dialog box, ensure that the mirror type is Synchronous, specify information such as the mirror name for the remote mirror, and ensure that you select the Use Write Intent Log checkbox.

Note: Do not use a colon (:) in the mirror name. This is a NAS restriction. Also, ensure that the mirror name is unique.

4. When you are done, click Apply.


30



To create a remote mirror of a source LUN (for example, the designated source control dos LUN 0), type the following naviseccli command:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 mirror -sync -create -name <name> -lun <lun> -description <description> -usewriteintentlog


Example showing creation of remote mirror aviator_m0 for the source control dos LUN 0:

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 mirror -sync -create -name aviator_m0 -lun 0 -description "mirror for src LUN 0" -usewriteintentlog

Remember to create remote mirrors for the other source control LUNs as well as each user LUN.

Task 7: Add the destination LUNs to the appropriate mirrors (perform on source)

To each remote mirror created for a source LUN, add the equivalent destination LUN (added as a secondary image). This process creates a mirror pair consisting of a source LUN and its equivalent destination LUN. Remember to add the equivalent destination LUNs of the three source Control Station LUNs to the appropriate mirrors.

As part of this process, the remote mirror state must change from fractured to out-of-sync, to synchronizing, to in-sync.

Note: When you perform this procedure, the destination LUN must be the same size as the corresponding source LUN, and the destination LUN cannot already belong to a storage group. After a destination LUN is added to a mirror, however, it can be added to the destination storage group in order to expedite failover.

Using Unisphere To add the destination LUN (image) to the mirror:





2. From the Mirrors and Consistency Groups view, right-click the mirror to which you want to add a secondary mirror and click Add Secondary.

3. The Add Secondary Image dialog box appears.

4. In the Add Secondary Image dialog box, specify information such as the target storage system for the secondary mirror image and the LUN that composes the secondary mirror image.

Note: Even for newly created user LUNs, you must perform the initial synchronization, as set by default in the Initial Sync Required option for Advanced Parameters. Initial synchronization is required for MirrorView/S. Also, in general, keep the synchronization rate default of Medium; if you change the synchronization rate to High, there is an impact on performance for any host connected to the array.


To add the destination LUN (image) to the mirror, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 mirror -sync -addimage -name <name> -arrayhost <IPAddr> -lun <lun-number>

Example (to add destination LUN 17 as a secondary image to the remote mirror aviator_m0, which has the source dos control LUN):

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 mirror -sync -addimage -name aviator_m0 -arrayhost 10.6.1.112 -lun 17

Use similar commands to add the other two destination control LUNs as well as each user LUN to the corresponding remote mirror.

Task 8: Assign destination LUNs to the destination Celerra storage group (perform on destination)

After they are added to a remote mirror, you can assign the destination LUNs to the destination Celerra’s storage group. Although these destination LUNs are not host-visible until they are promoted, they can still be part of a storage group after they are added to a remote mirror.

Note: Remember to observe the fixed control (system) LUN mapping (source control LUNs with HLU IDs 0, 1, and 4 must be mapped to destination LUNs with HLU IDs 6, 7, and 9, respectively). The ALU values are not restricted (for example, LUN 17 has an ALU of 17 but uses an HLU ID of 6). User LUNs do not require the fixed mapping, but they must have an HLU ID of 16 or higher (0–15 are reserved) based on what is available.


32


Using Unisphere To assign the backup LUNs to the destination Celerra’s storage group:

1. In the systems drop-down list, select the destination storage system.

2. Select Storage > LUNs.

3. In the LUNs view, right-click the LUNs you want to add to the storage group, and select Add to Storage Group. The Storage Group Properties - LUNs tab open.

4. Move the appropriate LUNs from the Available Storage Group list to the Selected Storage Group list.

5. Ensure that you specify the correct system host LUN IDs (HLU ID) for the associated LUN IDs.

6. When you are done, click OK.

7. Click Yes to confirm.

Using Navisphere CLI To assign the destination LUNs to the destination Celerra’s storage group, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 storagegroup -addhlu -gname <group-name> -hlu <hlu-number> -alu <alu-number>

Examples for the three equivalent control station LUNs, which use the required HLU IDs 6, 7, and 9 (the ALU values are not restricted):

$ /nas/opt/Navisphere/bin/naviseccli -h element-spa -user nasadmin -password nasadmin -scope 0 storagegroup -addhlu -gname Celerra_element -hlu 6 -alu 17



Task 9: Create the MirrorView/S consistency group (perform on source)

From the source site, you must create a MirrorView/S consistency group that contains all of the mirror pairs. This process enables all of the mirrors to function as a unit.



The LUNs in a MirrorView/S consistency group must all reside on the same storage system, unlike the volumes in a Symmetrix consistency group, which can reside on multiple storage systems. Also, the secondary image state must be Synchronized or Consistent before a mirror can be added to a consistency group. Since this is a full copy of the underlying storage, it may take some time to become synchronized. You can check the remote mirrors to ensure that they are in Sync and Active. You can click the plus sign to drill down within each mirror and verify that the mirror is in the Consistent state.

Using Unisphere To create the MirrorView/S consistency group:

1. In the systems drop-down list, select the source storage system for which you want to create the consistency group.


3. From the task list, under Mirrors select Create Consistency Group.

4. In the Create Group dialog box, specify consistency group parameters, such as the Mirror Type (Synchronous), group name, and a description. In the Advanced Parameters section, keep the default value of Automatic for Recovery Policy.

In the Unisphere software, you can continue to add remote mirrors, which means that you can technically skip to step 3 of Task 10. In the CLI, defining the consistency group and adding the mirrors requires two steps.

Note: The consistency group’s recovery policy should always be Automatic (the default) to ensure that the group can recover automatically after a link down failure (when the condition is System Fractured). If it is set to Manual instead, you have to execute the Celerra command nas_devicegroup -resume to restart group operations after a link down failure. Also, if this is the second group for an active/active’ configuration, ensure the consistency group name is unique.


To create the MirrorView/S consistency group on the source storage system, type:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 mirror -sync -creategroup -name <name> -description <description>


34



Example (to create consistency group cg_aviator on the source system):

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 mirror -sync -creategroup -name cg_aviator -description "consistency group from src to dst"

Task 10: Add all remote mirrors to the consistency group (perform on source)

After you create the consistency group, you must add all of the synchronized remote mirror pairs to the group. For example, you must add the three mirror pairs representing the control LUNs (dos, log, and nas).

Note: The mirror pairs must be synchronized before they can be added to a MirrorView/S consistency group.

Using Unisphere To add the remote mirrors (that is, the mirror pairs) to the consistency group:

1. In the systems drop-down list, select the source storage system for which you want to create the consistency group.


3. From the Mirrors and Consistency Groups view, select the consistency group to which you want to add the remote mirrors.

4. Right-click and select Properties.

5. In the Group Properties dialog box, move the appropriate remote mirrors from the Available Remote Mirrors list to the Selected Remote Mirrors list.

6. When you are done, click Apply.


Type the following naviseccli command to add a remote mirror to the group on the source system:

$ /nas/opt/Navisphere/bin/naviseccli -h <IP_address_or_hostname_of_SP A> -user <username> -password <password> -scope 0 mirror -sync -addtogroup -name <name> -mirrorname <name>


Initial Celerra procedures

Example (adding the remote mirrors to cg_aviator on the source system):

$ /nas/opt/Navisphere/bin/naviseccli -h aviator-spa -user nasadmin -password nasadmin -scope 0 mirror -sync -addtogroup -name cg_aviator -mirrorname aviator_m17





This completes the back-end configuration process.

Note: If you want to get detailed information about the back-end configuration, you can use Navisphere MirrorView/S informational commands, such as mirror -sync -info or mirror -sync -list. See Powerlink for the latest Navisphere MirrorView documentation and official command syntax.

Initial Celerra proceduresAfter you have completed the back-end configuration process, you can begin the Celerra configuration process on behalf of the customer as follows:

1. Review the Celerra planning considerations and work with the customer to determine the appropriate Data Mover configuration, as described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery.

2. Using the procedures described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery, perform the MirrorView/S preinitialization and initialization procedures (issuing the nas_cel


36


command with the -create option from both the Celerra, followed by the /nas/sbin/nas_mview -init command from the destination Celerra).

3. Using the procedures described in Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery, perform a test failover activation and restore to ensure proper functioning before leaving the customer site.

Note: If you later decide to add remote mirrors to the consistency group used by the Celerra Network Server, you must rerun the /nas/sbin/nas_mview -init command after the change. Any back-end configuration change made after initialization is permitted as long as a failover has not been activated. After a failover has been activated, however, do not make any back-end configuration changes.



Copyright © 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 regulatory document for your product line, go to the Technical Documentation and Advisories section on EMC Powerlink.

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.


Rev A01 September 02, 2010 - · PDF file2 EMC Celerra MirrorView/Synchronous Setup on CLARiiON...

Documents

Transcript of Rev A01 September 02, 2010 - · PDF file2 EMC Celerra MirrorView/Synchronous Setup on CLARiiON...