Using SRDF/A with Celerra - china.emc.com · Extension and EMC TimeFinder/FS, NearCopy, and...

1 of 96

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4User interface choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Related information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10SRDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11SRDF/A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14SRDF/A delta sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Differences between SRDF/A and SRDF/S . . . . . . . . . . . . . . . . . . . . 16Comparison of Celerra high-availability and replication products 17Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20SRDF/A task overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Configuring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Preinitialize the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Preinitialize from the source (first) Celerra . . . . . . . . . . . . . . . . . . . 32Preinitialize from the destination (second) Celerra . . . . . . . . . . . . . 33Verify the preinitialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Initialize the configuration (active/passive) . . . . . . . . . . . . . . . . . . . 34Initialize the source Celerra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Initialize the destination Celerra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Verify SRDF/A on the source Celerra (active/passive) . . . . . . . . . . 44Activate a failover (active/passive) . . . . . . . . . . . . . . . . . . . . . . . . . . 47Prepare for a graceful failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Activate a failover from the destination Celerra . . . . . . . . . . . . . . . 49Verify SRDF/A after failover activation . . . . . . . . . . . . . . . . . . . . . . . 53Ensure access after failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Restore the source Celerra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Prepare for the restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Restore from the destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Using SRDF/A with CelerraP/N 300-004-157

Rev A06

Version 5.6.48

March 2010

Using SRDF/A with CelerraVersion 5.6.48 2 of 96 Using SRDF/A with CelerraVersion 5.6.48 2 of 96

Troubleshooting SRDF/A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Where to get help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66EMC E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . .66Known problems and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86Training and Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . .86

Appendix: Portfolio of high-availability options . . . . . . . . . . . . . . . . . . . 87Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

3 of 96Version 5.6.48Using SRDF/A with Celerra

Introduction

EMC® Symmetrix Remote Data Facility/Asynchronous (SRDF®/A) is an extended-distance asynchronous replication facility. SRDF/A provides dependent write consistency for host writes from a source EMC Celerra®/Symmetrix DMX™ system pair to a destination Celerra/Symmetrix DMX system pair through predetermined time cycles (delta sets) for maintaining a restartable, point-in-time remote copy of data. "Concepts" on page 10 provides more details.

This document is part of the Celerra Network Server documentation set and is intended for system administrators responsible for installing and managing high-availability storage configurations. Your local EMC Customer Support Representative performs the EMC Symmetrix® backend administrative tasks, such as installation and configuration of the Symmetrix DMX and SRDF volumes required to support SRDF/A, and is available to help ensure proper SRDF/A functionality as needed.

System requirements

Table 1 on page 3 describes the Celerra Network Server software, hardware, network, and storage configurations.

Table 1 System requirements

Software

• Symmetrix Enginuity™ version 5670 or later microcode on the source and destination Symmetrix DMX systems with SRDF/A.

• Celerra Network Server version 5.6 or later on the source and destination servers.

Hardware

• Remote adapter (RA) for interconnecting the Symmetrix DMX systems. The connection can be over wide area channels using Fibre Channel (FC), Dense Wavelength Division Multiplexing (DWDM), or IP.

• Production and standby Data Movers on the Celerra Network Servers to support the SRDF/A active/passive configuration. The Control Station 0 (CS0) volume requires a separate RA and remote data facility (RDF) group.

• Similar source and destination Celerra Network Server models. For example, CNS-CNS, NS gateway-NS gateway, or NSX-NSX.

NetworkIP data network (required for multihop configurations) or dedicated SRDF/A channel (link) for communication between Control Stations of source and destination Celerra Network Servers.

Storage Two attached Celerra Network Server/Symmetrix DMX system pairs.

Using SRDF/A with Celerra4 of 96 Version 5.6.48

Restrictions

◆ SRDF/A requires a Symmetrix SRDF/A license.

◆ SRDF/A does not work with Symmetrix 3xxx, 5xxx, or 8xxx versions. Only Symmetrix DMX systems (5670 or later microcode) are supported.

Note: The Solutions Enabler Symmetrix SRDF family documentation, which includes the EMC Symmetrix Remote Data Facility (SRDF) Product Guide, provides additional restrictions that apply to the SRDF/A configuration with Symmetrix DMX. This documentation is available at http://Powerlink.EMC.com, the EMC Powerlink® website.

◆ The Symmetrix Enginuity version 5670 microcode supports only one SRDF/A group, which can be dedicated to either an open host or a Celerra, but not a mix of both. The 5671 release eases this restriction.

◆ SRDF/A source and destination sites support only one Celerra/Symmetrix system pair.

◆ SRDF/A does not support partial failovers. When a failover occurs, all file systems associated with SRDF-protected Data Movers fail over. To avoid failover issues, it is critical that SRDF-protected Data Movers mount only the file systems consisting of SRDF volumes mirrored at the destination. Local (STD, BCV) volumes should have dedicated, locally protected Data Movers and SRDF volumes should have dedicated, SRDF-protected Data Movers. "Troubleshooting SRDF/A" on page 66 provides information on potential failover and restore issues.

Management restrictions

◆ SRDF/A cannot be managed with Celerra Manager. SRDF/A can be managed only with the CLI by using the /nas/sbin/nas_rdf/nas_cel commands.

◆ For sites with redundant Control Stations, all SRDF management commands, including /nas/sbin/nas_rdf/nas_cel commands that perform initialization, activation, and restore operations, must be run from CS0. Control Station 1 (CS1) must be powered off at both sites before any activation or restore commands are run.

◆ For sites with CNS-14 cabinets, the CS0 Linux volume must be in a unique SRDF group, separate from the SRDF/A group.

◆ Solutions Enabler Symmetrix SYMCLI action commands are not invoked on a Celerra device group by using the Control Station host component, laptop service processor, or EMC ControlCenter®. However, you can run informational SYMCLI commands for the SRDF/A device group.

◆ When you run the nas_rdf restore command, ensure that no command is accessing the /nas/rdf/500 directory. NAS commands in rdfadmin environment may access the /nas/rdf/500 directory. If a command accesses /nas/rdf/500 during restore, the restore command will fail.

http://powerlink.emc.com


SnapSure checkpoints restrictions

◆ EMC SnapSure™ SavVol cannot be created on local storage if the Production File System (PFS) is mounted on a Data Mover configured with a remote standby. If you plan to create checkpoints of a PFS that resides on an SRDF LUN, ensure that the entire SnapSure SavVol with the checkpoints resides in the same pool of SRDF LUNs used to create the PFS. If any part of the SavVol is stored on a local volume rather than completely on the pool of SRDF LUNs, the checkpoints are not failed over, and are recoverable in the event of a failover. Evaluate the use of checkpoints carefully.

◆ After an SRDF/A failover is activated, checkpoint scheduling is not supported until a restore is performed.

◆ If SnapSure checkpoints are used in the rdfadmin environment, the SavVol volume can only be extended manually using the symm_std_rdf_tgt storage pool. If SavVol fills to capacity, writes to the PFS continue, while the oldest checkpoint is deactivated.

Celerra feature-specific restrictions

◆ Automatic File System Extension cannot be used for any file system that is part of an SRDF configuration, that is, file systems on Data Movers configured with an RDF standby. This includes EMC TimeFinder®/FS NearCopy and FarCopy implementations. Therefore, do not attempt to use the nas_fs command with the -auto_extend option for file systems associated with SRDF. Doing so generates the error message: “Error 13421842457: operation not supported for file systems of type SRDF.”

◆ SRDF/A is not implemented with configurations employing TimeFinder/FS NearCopy or FarCopy. NearCopy is not applicable because SRDF/A volumes cannot be source volumes for TimeFinder/FS NearCopy file system snapshots. In a configuration employing FarCopy, adaptive copy disk mode or write-pending mode can be used instead of SRDF/A.

◆ EMC Celerra Replicator™ (V2) works with disaster recovery replication products such as SRDF/Synchronous (SRDF/S) and SRDF/Asynchronous (SRDF/A) or EMC 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.

◆ Mixed backend configuration with SRDF and EMC MirrorView/S is not supported. In a mixed backend configuration, Symmetrix is the boot storage device, which prohibits use of MirrorView/S. MirrorView/S requires EMC CLARiiON® to be the boot storage device.

Note: MirrorView/S is currently available through the request for price quotation (RPQ) process. Contact the local EMC Sales Representative or the local EMC Service Provider for more information.


◆ In an SRDF/A environment involving iSCSI, features that are not supported by SRDF/A are also not supported by iSCSI. For example, Automatic File System Extension and EMC TimeFinder/FS, NearCopy, and FarCopy. "SRDF/A configuration with iSCSI" on page 23 provides more details.

◆ SRDF/A does not support Concurrent SRDF or Dynamic SRDF.

◆ SRDF/Automated Replication (SRDF/AR) does not support SRDF/A devices.

◆ SRDF/A does not support solid state disk (SSD) drives. If you attempt to configure an SSD drive with SRDF/A, Celerra health check operations reject the device as an unsupported storage.

◆ SRDF provides limited support for Celerra FileMover. Using EMC Celerra FileMover provides more information.

◆ SRDF provides limited support for MPFS. Contact the local EMC sales organization for information about using MPFS with SRDF.

"EMC E-Lab Interoperability Navigator" on page 66 provides information about product interoperability. "System requirements" on page 3 identifies the basic hardware and software requirements.

User interface choices

This document describes how to configure SRDF/A by using the command line interface (CLI). You cannot use other Celerra management applications to configure SRDF/A.

Terminology

The EMC Celerra Glossary provides a complete list of Celerra terminology.

Note: In this document, the terms source and destination are used to maintain consistency with other Celerra products. However, some output features Symmetrix-style terminology, which uses the term target instead of destination. Also, the term NS refers to the Celerra NS series gateway server models, such as the NS700 series gateway servers (for example, the NS702G with two Data Movers), CNS-14 refers to the Celerra Clustered 14-Data Mover cabinet configuration, and NSX refers to the Celerra NSX series gateway server, which can support between four and eight Data Movers.

active/active’: For Symmetrix Remote Data Facility (SRDF) or MirrorView/Synchronous configurations, a bidirectional configuration with two production sites, each acting as the standby for the other. Each Celerra Network Server has both production and standby Data Movers. If one site fails, the other site takes over and serves the clients of both sites. For SRDF, each Symmetrix storage system is partitioned into source (production) and remote destination volumes. For MirrorView/S, each CLARiiON storage system is configured to have source and destination LUNs as well as a consistency group.

Note: The apostrophe (’) after the second “active” in active/active’ indicates one volume/LUN at both sites is a source volume/LUN with a remote site mirror.

adaptive copy write-pending mode: SRDF mode of operation in which write tasks accumulate in global memory on the local system before being sent to the remote

../FileMover/index.htm


../../mergedprojects/Glossary/index.htm


system. This mode allows the primary and secondary volumes to be more than one I/O out of synchronization. The maximum number of I/Os that can be out of synchronization is defined using a maximum skew value.

Celerra FileMover: Policy-based system used to determine where files should be physically stored. In most cases, policies are based on file size or last access time (LAT) or both and are used to identify data that can be moved to slower, less-expensive storage.

Common Internet File System (CIFS): File-sharing protocol based on the Microsoft Server Message Block (SMB). It allows users to share file systems over the Internet and intranets.

delta set: For SRDF/Asynchronous (SRDF/A), a predetermined cycle of operation used for asynchronous host writes from a source to a destination. Each delta set contains groups of I/Os for processing; the ordering of these I/Os are managed for consistency. For Celerra Replicator, a set contains the block modifications made to the source file system that Celerra Replicator uses to update the destination file system (read-only, point-in-time, consistent replica of the source file system). The minimum delta-set size is 128 MB.

dependent write consistency: For SRDF/A, the maintenance of a consistent point-in-time replica of data between a source and destination through the processing and preservation of all writes to the destination in ordered, numbered delta sets.

destination Celerra: Term for the remote (secondary) Celerra Network Server in an SRDF or MirrorView/S configuration. The destination Celerra is typically the “standby” side of a disaster recovery configuration. Symmetrix configurations often call the destination Celerra the target Celerra.

local mirror: Symmetrix shadow volume that is a complete replica of a production volume within the same storage unit. If the production volume becomes unavailable, I/O continues to the local mirror transparent to the host. See also R1 volume.

metavolume: On a Celerra system, a concatenation of volumes, which can consist of disk, slice, or stripe volumes. Also called a hypervolume or hyper. Every file system must be created on top of a unique metavolume. See also disk volume, slice volume, stripe volume, and volume.

MirrorView/Synchronous (MirrorView/S): Software application that synchronously maintains copies of production images (source LUNs) at a separate location to provide disaster recovery capability. The copied images are continuously updated to be consistent with the source, and provide the ability for a standby Celerra to take over for a failed Celerra in the event of a disaster on the production site. Synchronous remote mirrors (source and destination LUNs) remain in synchronization with each other for every I/O. MirrorView/S requires CLARiiON backend storage.

Multi-Path File System (MPFS): Celerra Network Server feature that allows heterogeneous clients with MPFS client software to concurrently access, directly over Fibre Channel or iSCSI channels, shared data stored on a Symmetrix or CLARiiON storage array. MPFS adds a lightweight protocol called File Mapping Protocol (FMP) that controls metadata operations.


Production File System (PFS): Production file system on a Celerra Network Server. A PFS is built on Symmetrix volumes or CLARiiON LUNs and mounted on a Data Mover in the Celerra Network Server.

remote mirror: For SRDF, a remote mirror is a Symmetrix shadow volume physically located in a remote Symmetrix system. Using the EMC SRDF technology, the remote system is joined to a local system with a local mirror. If the local mirror becomes unavailable, the remote mirror is accessible. See also R2 Volume. For MirrorView/S, a remote mirror is a LUN mirrored on a different CLARiiON storage system. Each remote mirror contains a particular source LUN (primary image) and its equivalent destination LUN (secondary image). If the source site system fails, the destination LUN in the mirror can be promoted to take over, thus allowing access to data at a remote location.

R1 volume: SRDF term denoting the source (primary) Symmetrix volume. See also local mirror.

R2 volume: SRDF term denoting the destination (secondary) Symmetrix volume. See also remote mirror.

SnapSure: On a Celerra system, a feature providing point-in-time copies, also known as checkpoints, of a file system.

source Celerra: Term for the local (primary) Celerra Network Server. A source Celerra is typically the “production” side of a disaster recovery SRDF/S or MirrorView/S configuration.

Symmetrix Remote Data Facility (SRDF): EMC technology that allows two or more Symmetrix systems to maintain a remote mirror of data in more than one location. The systems can be located within the same facility, in a campus, or hundreds of miles apart using fibre or dedicated high-speed circuits. The SRDF family of replication software offers various levels of high-availability configurations, such as SRDF/Synchronous (SRDF/S) and SRDF/Asynchronous (SRDF/A).

SRDF/Asynchronous (SRDF/A): SRDF extended-distance replication facility providing a restartable, point-in-time remote replica that lags not far behind the source. Using SRDF/A with Celerra provides dependent write consistency for host writes from a source Celerra/Symmetrix DMX system pair to a destination Celerra/Symmetrix DMX system pair through predetermined time cycles (delta sets).

SRDF/Synchronous (SRDF/S): SRDF complete disaster recovery configuration option that provides synchronized, real-time mirroring of file system data between the source Symmetrix system and one or more remote Symmetrix systems at a limited distance (up to 200 km). SRDF/S can include TimeFinder/FS NearCopy in the configuration (active/passive; active/active’).

TimeFinder/FS: Business continuance configuration allowing customers to use Symmetrix business continuance volumes (BCVs) to provide a local or remote point-in-time copy of a Celerra file system.


Related information

Celerra disaster recovery that is SRDF/A related, but is beyond the scope of this document is included in:

◆ EMC Celerra Network Server Command Reference Manual

◆ EMC Celerra Network Server Error Messages Guide

◆ Online Celerra man pages

◆ EMC Celerra Glossary

◆ Problem Resolution Roadmap for EMC Celerra

◆ Using EMC Celerra FileMover

◆ EMC Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery

◆ Using TimeFinder/FS, NearCopy, and FarCopy with EMC Celerra

◆ Using SRDF/S with EMC Celerra for Disaster Recovery

Other related EMC publications, include:

◆ EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide

◆ EMC Symmetrix Remote Data Facility (SRDF) Product Guide

EMC Celerra Network Server Documentation CD

The EMC Celerra Network Server Documentation CD, supplied with your Celerra Network Server and also available on the EMC Powerlink website, provides the complete set of EMC Celerra customer publications. After logging in to Powerlink, go to Support > Technical Documentation and Advisories > Hardware/Platforms Documentation > Celerra Network Server. On this page, click Add to Favorites. The Favorites section on your Powerlink home page provides a link that takes you directly to this page.

To request an EMC Celerra Network Server Documentation CD, send an email request to [email protected].

Celerra Support Demos

Celerra Support Demos are available on Powerlink. Use these instructional videos to learn how to perform a variety of Celerra configuration and management tasks. After logging in to Powerlink, go to Support > Product and Diagnostic Tools > Celerra Tools > Celerra Support Demos.

Celerra wizards

Celerra wizards can be used to perform Celerra Manager tasks. Using Wizards to Configure EMC Celerra provides you with an overview of the steps required to configure a Celerra Network Server using the Set Up Celerra wizard in Celerra Manager.

../CommandReference/index.htm

../ErrorMsgs/index.htm

../ProblemResolutionRoadmap/index.htm


../MirrorView/index.htm

../TimeFinder/index.htm

../SRDFS/index.htm



Concepts

SRDF/A is an extended-distance asynchronous replication facility.

SRDF/A provides an economical and high-performance replication configuration for business continuity, enabling greater service levels than obtained with traditional asynchronous architectures. It is the optimal extended-distance replication option when service-level requirements dictate that economics and application performance are more critical than zero data exposure.

Benefits of SRDF/A include:

◆ Extended-distance data replication that supports longer distances than Symmetrix Remote Data Facility/Synchronous (SRDF/S).

◆ Potential performance increase over SRDF/S because source host activity is decoupled from remote copy activity.

◆ Efficient link utilization that results in lower link-bandwidth requirements because less data is transferred and the data is handled fewer times. By exploiting the locality of reference writes within an application, data that is updated multiple times in the same cycle is sent across the SRDF/A links only once, and does not have to be duplicated within the global memory of the sending control unit to preserve data consistency. The benefit of this approach might vary among applications.

◆ Minimal data loss potential because the destination side lags behind the source by minutes. Data could be out of date by twice the delta set time period or longer, depending on the write activity, and how fast the data can be transmitted across the link.

◆ Failover and failback capability between the source and destination sites. Destination volumes can be used if the source is unavailable.

◆ Facilities to invoke failover and restore operations manually.

SRDF/A is based on the Symmetrix Remote Data Facility (SRDF) technology for the EMC Symmetrix environment and is a part of the SRDF replication software family that offers high-availability configurations. SRDF/A recovery capability completely relies on the SRDF functionality.


SRDF

SRDF is a replication technology that allows two or more Symmetrix systems to maintain a mirror of data at multiple, remote locations.

SRDF supports two types of configurations:

◆ active/active’ — Bidirectional configuration with two production sites, each acting as the standby for the other. Each Celerra Network Server has production and standby Data Movers. If one site fails, the other site takes over and serves the clients of both sites.

◆ active/passive — Unidirectional setup where one Celerra, with its attached storage system, serves as the source (production) file server and another Celerra, with its attached storage, serves as the destination (backup). This configuration provides failover capabilities in the event that the source site is unavailable.

Communication between Control Stations

In an SRDF configuration, the Control Stations associated with the source and destination Celerra Network Servers can communicate using either:

◆ IP data network (optional)

or

◆ SRDF channel (dedicated link that provides access control volumes remotely mirrored with SRDF)

Figure 1 on page 11 shows a basic Celerra-with-SRDF configuration that illustrates the two means of communication.

Figure 1 Basic Celerra-with-SRDF configuration

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1

SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15

Dedicated link for SRDFSourceR1

TargetR2

Site A source Site B target

Celerrahost

Celerrahost

Symmetrix Symmetrix

CNS-000713

Optional IPdata network

connection


SRDF and logical volumes

To implement the Celerra Network Server with an SRDF configuration, the standard Celerra configuration is modified.

Each logical volume defined in the Celerra volume database consists of two physical volumes: one on the source Symmetrix and one on the destination Symmetrix system. For example, a typical Symmetrix volume, logical volume 001, consists of 001-R1 (the primary, or source, disk) and 001-R2 (the destination, or remote, disk).

The R2 devices mirror the data from the source R1 volume by using SRDF. The R2 devices are transparent to the source Celerra host and become write-accessible only when they are activated through a manual failover operation. However, if a source (R1) volume fails during normal operation, SRDF automatically uses the R2 volume instead of R1 and continues normal operation.

Figure 2 on page 12 provides a simplified view of a sample logical volume configuration. Note that Symmetrix volume IDs do not have to be identical (mapping 001 to 001 as shown in this view).

Figure 2 Celerra with SRDF logical volume

Note: In the Celerra Network Server system setup phase, your local EMC Customer Support Representative configures the volumes on the attached Symmetrix system (source) and the remote Symmetrix system (destination). In addition, SRDF software and EMC communications hardware are installed to enable the Symmetrix systems to communicate with each other. Local EMC personnel can ensure that the volumes are established on the dedicated SRDF link.


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15

Dedicated SRDF link

SourceR1

001-R1

TargetR2

001-R2


Celerrahost

Celerrahost

Symmetrix Symmetrix

CNS-000714

Logical volume 001


Celerra Network Server support for SRDF includes:

◆ Complete disaster recovery without data loss — The Celerra Network Server supports SRDF/S, which represents SRDF in synchronous mode. SRDF/S is a limited-distance replication facility established between a pair of Celerra/Symmetrix systems at a source site and a destination site. SRDF/S provides a synchronized, realtime remote mirror of data at more than one location.

To support a wide variety of business continuance requirements while maintaining a full disaster recovery environment employing Symmetrix storage, you can also use SRDF/S with the TimeFinder/FS NearCopy feature. TimeFinder/FS NearCopy enables you to create and manage snapshots of a Celerra file system onto dedicated Symmetrix BCVs. To create the NearCopy snapshot, the source volumes can be destination (R2) volumes, operating in SRDF/S mode. Using SRDF/S with EMC Celerra for Disaster Recovery and Using TimeFinder/FS, NearCopy, and FarCopy with EMC Celerra provide more information.

◆ Extended-distance replication — The Celerra Network Server supports SRDF/A, which represents SRDF in asynchronous mode. SRDF/A is an extended-distance replication facility established between a pair of Celerra/Symmetrix DMX systems at a source site and a destination site. SRDF/A provides a restartable, point-in-time remote mirror of data lagging not far behind the source.

Celerra also supports the use of TimeFinder/FS FarCopy with SRDF in adaptive copy write-pending mode, where you create the FarCopy snapshot using R2 volumes as the source volume.

Contact the local EMC sales organization for more information about these and other available configuration options.

../SRDFS/index.htm



SRDF/A

An SRDF/A configuration connects a local Celerra/Symmetrix DMX system pair with a remote Celerra/Symmetrix DMX system pair. This connection can be made over longer distances than the SRDF/Synchronous (SRDF/S) product. After the Celerra Network Server is configured, users can continue to access the SRDF-protected Celerra file systems should the local (source) Celerra Network Server, the Symmetrix DMX system, or both become unavailable.

This document describes how to use SRDF/A with Celerra in an active/passive configuration. In an active/passive configuration, data is replicated between two attached Symmetrix DMX systems connected through SRDF/A links. Normal mirroring between the Symmetrix DMX systems is carried out, while the destination (target) Celerra Network Server remains on standby. While functioning as a standby, the destination Celerra Network Server is powered up and its Control Station is fully operational. The destination Celerra Network Server configuration provides complete hardware redundancy for the source Celerra Network Server.

Note: For the purposes of SRDF/A configuration, it is assumed that the local volumes and SRDF-protected volumes have their own, dedicated Data Movers. To avoid failover issues, SRDF-protected Data Movers should contain only SRDF volumes, not local (STD, BCV) volumes. Also, ensure that the file systems do not span multiple storage systems.

Note: The Celerra Network Server continually monitors its internal hardware status and, if properly configured, initiates a CallHome event to report any problems that could require attention by local EMC personnel.

SRDF/A delta sets

SRDF/A processes asynchronous-mode host writes from the source (R1) to the destination (R2) by using predetermined cycles of operation called delta sets.

Delta-set logical cycles, which include capture, transmit or receive, and restore, provide dependent write consistency. Dependent write consistency refers to the maintenance of a consistent replica of data between the source and destination, achieved by processing and preserving all writes to the destination in ordered (sequential) numbered sets.

The following steps summarize the data processing in the delta set cycles:

1. Capture cycle N: An SRDF/A delta set (active cycle N) begins on the source (R1) to capture new writes, overwriting any duplicate tracks intended for transfer over the SRDF/A link. This cycle is active for a predetermined time period by default, using a cycle time of 30 seconds. Your local EMC Customer Support Representative can help you configure this on the Symmetrix DMX system.

2. Transmit cycle N-1: After the predetermined cycle time is reached, the delta-set data moves to the transmit cycle N-1, during which the delta-set data collected on the source is transmitted to the destination (R2) Symmetrix DMX system. This data is inactive during the N-1 cycle. A new cycle N starts to collect new writes in preparation for the next delta-set transfer.


3. Receive cycle N-1: During the N-1 cycle, the delta-set data is collected at the destination (R2) Symmetrix DMX system. When all N-1 cycle data is successfully transmitted by the source, and received by the destination, and the minimum cycle time elapses, the delta-set data moves to the next cycle.

4. Restore cycle N-2: During this cycle, writes are restored to the R2 destination (marked as device write pendings or destaged to disk). When all writes associated with delta set N-2 are committed to the R2 destination, the R1 source and R2 destination are considered to be in a consistent-pair state. A cycle switch occurs only after these conditions are met.

Figure 3 on page 15 illustrates how data is processed in delta set cycles.

A cycle switch occurs only after all these conditions are met:

1. The minimum cycle time elapses.

2. The N-1 cycle finishes transferring data, and the data is fully received at the destination site.

3. The N-2 cycle finishes restoring data at the destination.

Note: The cycle time is elongated if the write transfer or destaging exceeds the set cycle time. A new cycle cannot begin until all three conditions are met. It is possible a switch could take longer, for example, 20 minutes or more, depending on how quickly the data travels across the link.

Figure 3 SRDF/A active/passive configuration featuring delta sets (cycles) to transfer data


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


Celerrahost

Celerrahost

Symmetrix Symmetrix

SRDF/A device pairactive sessions

SRDF/A delta set begins

Dedicated SRDF link

1. Capture writes using default cycle time of 30 sec (active)

2. Transmit writes to R2 (inactive)

4. Writes restored to R2 target device (active)

3. Receive writes on R2 (inactive)

CNS-000712

SourceR1

device

TargetR2

device

CycleN-2

CycleN-1

CycleN-1

CycleN

I/O


Important resource considerations

◆ Over time, the SRDF/A facility might incur additional load due to increased levels of write activity. For example, increased write activity introduced by new applications or growth to existing applications.

◆ During periods of intense write activity, completion of the delta-set transfer could exceed 20 minutes, depending on how fast data can travel across the link.

◆ Depending on how often you see extended-length transfers (cycle times), you might need to increase the bandwidth capacity between sites. Local EMC personnel can help you determine the appropriate amount of bandwidth for your configuration. You can monitor the SRDF/A average cycle time and the time R2 is behind R1 by running a SYMCLI query command for your SRDF/A device group. For example, /nas/symcli/bin/symrdf -g <device_group> query -rdfa. A sample device group is 1R1_3.

Differences between SRDF/A and SRDF/S

Table 2 on page 16 summarizes the key differences between SRDF/A and SRDF/S on Celerra Network Servers with Symmetrix backend storage.

Table 2 Summary of differences between SRDF/A and SRDF/S (page 1 of 2)

SRDF/A SRDF/S

Requires Symmetrix DMX systems or later versions.

Works with Symmetrix 3xxx, 5xxx, 8xxx, or DMX systems.

Extended-distance replication facility. Complete disaster recovery configuration for systems within relatively short distances.

Provides manual failover and failback of backend devices and servers with minimal data loss.

Provides a complete disaster recovery configuration without data loss.

Provides system-wide points of consistency. Provides I/O level consistency.

Each write I/O to the source is immediately committed on the source image only and sent to the destination in predefined timed cycles (delta sets). The host is acknowledged of the write before the destination Symmetrix system receives the write.

Each write I/O to the source is synchronously replicated to the destination Symmetrix system. The host is acknowledged of the write after the destination Symmetrix system receives and CRC-checks the data.

Locality of reference provides more efficient use of network bandwidth. With data sent as cycles of dependent write-consistent data, less data needs to transfer to the destination. If the same track is written to more than once within an active set, SRDF/A sends the update over the link once.

Each I/O is sent to the destination Symmetrix system before an acknowledgment is sent to the host.

Currently supports active/passive configurations only.

Supports active/passive and active/active’ configurations.


"Appendix: Portfolio of high-availability options" on page 87 provides illustrations of various business continuance and high-availability configurations that EMC supports with the Celerra Network Server. Using SRDF/S with EMC Celerra for Disaster Recovery provides information about SRDF/S, which is the synchronous version of SRDF.

Comparison of Celerra high-availability and replication products

Table 3 on page 17 lists and compares the different Celerra product options for disaster recovery, high availability, and file system replication or copying. The local EMC sales organization can provide information about the other configuration options.

Note: EMC recommends that all parts of a Celerra file system use the same type of disk storage and be stored on a single storage system. A file system spanning more than one storage system increases the chance of data loss or data unavailability. Managing EMC Celerra Volumes and File Systems with Automatic Volume Management and Managing EMC Celerra Volumes and File Systems Manually provide more information.

Not implemented with configurations employing TimeFinder/FS NearCopy or FarCopy. NearCopy is not applicable because SRDF/A volumes cannot be source volumes for TimeFinder/FS NearCopy file system snapshots. In a configuration employing FarCopy, adaptive copy disk mode or write-pending mode can be used instead of SRDF/A.

Can be implemented with TimeFinder/FS NearCopy and FarCopy (adaptive copy disk or write-pending mode).

Table 2 Summary of differences between SRDF/A and SRDF/S (page 2 of 2)

SRDF/A SRDF/S

Table 3 Comparison of Celerra high-availability and replication products (page 1 of 3)

Product Storage platform What it does Restrictions

MirrorView/Synchronous

Note: This product is currently available through the RPQ process. Contact the local EMC Sales Representative or the local EMC Service Provider for more information.

CLARiiON only, CX series (CX700/600/500/400, CX3-40, or CX3-80)

Using attached Celerra and CLARiiON backend pairs, performs synchronized, remote mirroring to provide full disaster recovery without data loss at a limited distance.

EMC Using MirrorView/Synchronous with EMC Celerra for Disaster Recovery provides more information about MirrorView/S. RPQ process controls the access to this document.

Cannot be used in the same Celerra configuration as SRDF. Cannot be used with Symmetrix-based products such as TimeFinder/FS. Cannot be used with the Automatic File System Extension feature.

Performs LUN (volume) cloning, not file system cloning; remote volumes are accessible only after a failover.

With MirrorView/S, the Celerra does not see the mirrored LUNs at the destination site until a failover is activated. This is different from SRDF, in which the remote mirrors (R2 volumes) of the Control Station LUNs are visible to the Data Movers.

../AVM/index.htm

../AVM/index.htm

../VolFSManually/index.htm

../VolFSManually/index.htm



../SRDFS/index.htm

../SRDFS/index.htm


SRDF/Synchronous Symmetrix only (3xxx, 5xxx, 8xxx or DMX series)

Using attached Celerra and Symmetrix pairs, performs syn-chronized, remote replication to provide full disaster recovery without data loss at a limited distance. Using SRDF/S with EMC Celerra for Disaster Recovery provides more infor-mation about SRDF/S.

Cannot be used in the same Celerra con-figuration as MirrorView/S. Cannot be used with the Automatic File System Extension feature.

Performs volume cloning, not file system cloning; remote volumes are only accessi-ble after a failover.

SRDF/Asynchronous Symmetrix only, DMX series

Using attached Celerra and Symmetrix pairs, performs asynchronous, point-in-time replication at an extended distance. This technical module provides more information about SRDF/A.

Cannot be used in the same Celerra con-figuration as MirrorView/S. Cannot be used with the Automatic File System Extension feature.

Performs volume cloning, not file system cloning; remote volumes are only accessi-ble after a failover.

TimeFinder/FS Symmetrix only Using a business continuance configuration with Symmetrix business continuance volumes (BCVs), provides local file sys-tem cloning.

A single file system should occupy an entire STD volume. TimeFinder/FS does not perform volume cloning.

TimeFinder/FS Near-Copy and FarCopy

Symmetrix only Using a business continuance configuration with Symmetrix BCVs, provides remote file sys-tem cloning, creating a point-in-time copy (snapshot) of a Cel-erra production file system.

A remote file system can be mounted and used during normal operation (that is, it is generally accessible).

Using TimeFinder/FS, Near-Copy, and FarCopy with EMC Celerra provides more informa-tion about TimeFinder/FS prod-ucts.

These products do not perform volume cloning. NearCopy is limited to 200 km. FarCopy supports extended distances.

NearCopy relies on SRDF/S and FarCopy relies on SRDF adaptive copy disk or write-pending mode to manage file system snapshots.

TimeFinder/FS NearCopy and FarCopy do not work with Automatic File System Extension.

Celerra Replicator (V2) Celerra-supported storage (one Symme-trix or CLARiiON pair)

Produces a read-only, point-in-time copy of a source file sys-tem and periodically updates this copy, making it consistent with the source file system. The read-only copy can be used by a Data Mover in the same Cel-erra cabinet, or by a Data Mover at a remote site for con-tent distribution, backup, and application testing. Using EMC Celerra Replicator (V2) pro-vides more information.

For TimeFinder/FS, NearCopy, or Far-Copy, a business continuance volume (BCV) cannot be a source or a destination file system for replication. You can repli-cate the underlying source file system, but you cannot replicate the BCV.

You cannot use the TimeFinder/FS -Restore option for a replicated source file system. Replication is unaware of any changes because these changes occur at the volume level.



../SRDFS/index.htm

../SRDFS/index.htm

../SRDFS/index.htm




../Replicator/index.htm

../Replicator/index.htm


Celerra Replicator for iSCSI

Celerra-supported storage (one Symme-trix or CLARiiON pair)

Performs asynchronous repli-cation of a source iSCSI LUN (logical unit) to a read-only des-tination iSCSI LUN using snap-shots (point-in-time copies of the source LUN).

Multiple one-to-one replications are sup-ported, but not one-to-many. Multihop (cascading) restoration is not supported.

Data can be restored up to the latest replicated snapshot.

SnapSure Celerra-supported storage

On a Celerra system, provides read-only, point-in-time logical copies, also known as check-points, of a production file sys-tem.

Not intended to be a mirror, disaster recovery, or high-availability tool. Because it is partially derived from realtime PFS data, a checkpoint could become inacces-sible (not readable) if the PFS becomes inaccessible. Only checkpoints and a PFS saved to a tape or to an alternate storage location can be used to provide disaster recovery.

In version 5.6, SnapSure supports 112 checkpoints, 96 in 5.5, 64 in 5.4 and 32 prior to 5.4.




Planning considerations

Before configuring SRDF/A with the Celerra Network Server, consider the following planning information.

Note: Examine the configuration in terms of local volumes against the intended SRDF-protected volumes. For example, STD and BCV, not mirrored at the destination. Because SRDF/A does not support partial failovers, and all file systems associated with the SRDF-protected Data Movers are eligible for failover, ensure that different Data Movers support local volumes against SRDF volumes. Associate the local volumes with locally protected Data Movers, and associate the SRDF volumes with dedicated SRDF-protected Data Movers. To avoid SRDF failover issues, do not mount local volumes on a Data Mover that also mounts SRDF volumes. "Troubleshooting SRDF/A" on page 66 provides a description of the failover and restore issues for SRDF/A.

Symmetrix system configuration

The SRDF/A configuration setup tasks assume that the volumes on Symmetrix DMX systems are configured in conformance with SRDF requirements, and the SRDF link is operational, and in asynchronous mode. The local EMC Customer Support Representative can configure the volumes on the source and destination Symmetrix systems, and install SRDF software and communications hardware to enable the Symmetrix systems to communicate with each other.

The Solutions Enabler Symmetrix SRDF family documentation on the EMC Powerlink website, which includes the EMC Symmetrix Remote Data Facility (SRDF) Product Guide, provides details about SRDF requirements for Symmetrix systems.

Adding Symmetrix storage devices to the existing system configuration

After initial system configuration, if you want to add Symmetrix storage devices to the configuration, use the following procedure:

1. Run the server_devconfig -create -scsi -all command to search for newly added Symmetrix devices and create new logical disk volumes.

2. Depending on the SRDF configuration, run the /nas/sbin/nas_rdf -init command on the source and target Control Stations in the following manner:

• If the SRDF configuration is active/passive, run the /nas/sbin/nas_rdf -init command first on the source and then on the target.

• If the SRDF configuration is active/active’, run the /nas/sbin/nas_rdf -init command first on the source Control Station, then on the target Control Station and then again on the source Control Station.

In the active/active’ configuration, each Symmetrix system is partitioned into primary and remote volumes. There are two communication links, each connecting the primary volumes with their remote counterparts on the remote Symmetrix system. Because of this, when you run the /nas/sbin/nas_rdf -init command on the source Control Station for the first time, the device configuration database and R1 device groups on the primary side are updated, but the device configuration database and R2 device groups on the target side are not updated. When you run the /nas/sbin/nas_rdf -init command on the target Control Station, the device



configuration database for the other direction is updated. The R2 device groups are also updated based on the device configuration database of the source side. The R2 device groups on the source Symmetrix are updated based on the target side device configuration database when you run the /nas/sbin/nas_rdf -init command for the third time.

Celerra volume and Data Mover decisions/flexibility

A typical SRDF/A Celerra Network Server active/passive configuration provides a full backup of the source site, Data Mover for Data Mover. However, you can choose which volumes and Data Movers to protect with remote mirroring. For example, you can remotely mirror some volumes and Data Movers while others are only locally protected. You do not have to remotely protect all volumes and Data Movers.

When planning the Data Mover configuration:

◆ For every source (production) Data Mover that you choose to protect with a remote SRDF/A standby Data Mover, you must provide a dedicated standby Data Mover at the destination site. There must be a one-to-one relationship between a source Data Mover that you choose to protect, and a dedicated remote standby Data Mover at the destination site.

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

◆ An SRDF/A standby Data Mover at the destination can be paired only with one source Data Mover.

◆ The network configuration of the SRDF/A standby Data Mover must be a superset of the network configuration of the source Data Mover.

◆ The network configuration of the SRDF/A standby Data Mover must be able to access the R2 data volumes corresponding to the primary source Data Mover.

◆ Local Data Movers can be configured to have a local standby Data Mover, separate from the SRDF-protected Data Movers.

Data Mover configurations possible at the local and remote locations in active/passive SRDF/A environments include:

◆ On the local Celerra Network Server:

• Local production Data Mover paired with SRDF/A remote standby Data Mover

• Local standby Data Mover paired with SRDF/A remote standby Data Mover

• Local production Data Mover (non-SRDF/A)

• Local standby Data Mover (non-SRDF/A)

◆ On the remote (destination) Celerra Network Server:

• SRDF/A standby Data Mover

• Local production Data Mover (non-SRDF/A)

• Local standby Data Mover (non-SRDF/A)


Celerra Data Mover configuration checklist

Before performing any Celerra procedures to establish SRDF/A, to ensure proper Data Mover configuration:

◆ List which Data Movers to designate as SRDF/A primary and SRDF/A standby Data Movers. This is a one-to-one failover relationship. A Data Mover can be an SRDF/A standby for only one primary Data Mover, and an SRDF/A primary Data Mover can have only one SRDF/A standby. In the initialization procedure, you designate and assign these failover relationships. Note that by default, Data Movers are referred to as servers and are named server_n, starting with server_2.

◆ Do not attempt to configure a local Data Mover as an SRDF/A standby if that Data Mover is currently configured as a local standby. For a Celerra NS series gateway server active/passive configuration with two Data Movers established for high availability, remove the default local standby status of the destination Celerra server’s local Data Mover (for example, server_3) before configuring that Data Mover as an SRDF/A standby. Configure the Data Mover as an SRDF/A standby during the initialization process on the destination Celerra server, for example:

server_standby server_2 -delete mover=server_3

server_setup server_3 -type nas

In the CNS-14 (14-Data Mover) cabinet configuration shown in this technical module, there is no default local standby, so you can proceed with an SRDF/A standby assignment during the initialization process. "Initialize the destination Celerra" on page 39 provides more information about initialization.

◆ Ensure that the Data Movers on the source and destination Celerra Network Servers are of a similar model type, that is, the local SRDF/A Data Mover and its corresponding remote standby Data Mover should be the same model or a supported superset. In addition, the source and destination cabinets must be a similar model type. For example, they should both be NS series gateway cabinets or CNS-14 cabinets, but not a mix of NS series gateway and CNS-14 cabinets.

◆ Consider IP data-network connectivity issues when planning the Data Mover assignments.

◆ Ensure that network interfaces for the SRDF/A primary and SRDF/A standby Data Movers are identical, and the same set of network clients can access the SRDF/A primary and the SRDF/A standby Data Movers.

◆ Ensure that each local standby Data Mover, providing local standby coverage for an SRDF-protected Data Mover, has a corresponding remote SRDF/A standby. This is a requirement for active/passive configurations.

◆ Evaluate the destination site’s infrastructure: Subnet addresses as well as availability of NIS/DNS servers in the correct UNIX domain, WINS/PDC/BDC/DC in the correct Windows domain, and NTmigrate or usermapper hosts. The CIFS environment requires more preparation to set up an SRDF configuration, due to higher demands on its infrastructure than the NFS environment. For example, authentication is handled by the infrastructure


against client OS. For the CIFS environment, perform mappings between usernames/groups and UIDs/GIDs.

Note: If the Celerra Network Server environment is configured with SRDF protection, and you plan to create checkpoints of a production file system that resides on an SRDF volume, ensure that the entire SnapSure volume (the SavVol, which stores the checkpoints) resides in the same pool of SRDF volumes used to create the production file system. Otherwise, if any part of the SavVol is stored on a local standard (STD) volume rather than on an SRDF volume, the checkpoints are not failed over and not recoverable in the SRDF-failback process.

SRDF/A configuration with iSCSI

As of version 5.5.24, SRDF/A supports iSCSI operations involving file systems mounted on a Data Mover configured for SRDF/A. In general, the features that are not supported by SRDF/A are also not supported by iSCSI in the SRDF/A environment (for example, Automatic File System Extension and EMC TimeFinder/FS, NearCopy, and FarCopy).

The remote mirroring of source iSCSI LUNs using SRDF/A is transparent to Celerra iSCSI operations. Each iSCSI LUN is equivalent to a file within a file system on the Celerra, therefore, to establish remote mirroring of iSCSI LUNs, the appropriate file systems must be mounted on a source Data Mover configured for SRDF/A. The SRDF/A-protected Data Mover must provide the file system representing the iSCSI LUN and the root file system of the Data Mover managing LUN visibility.

For iSCSI configurations employing SRDF/A for remote mirroring, iSCSI behavior can be characterized as follows:

◆ During normal, steady-state operation, the destination-site copy of the source production data is inaccessible, even if it is read-only. Therefore, before a failover is activated, for example, in response to a disaster scenario, no iSCSI host can access the destination-site copy of the production data.

◆ When a failover is activated, the failover is cabinet-level, that is, the destination Celerra now provides the entire DR-protected environment of the source Celerra. You cannot activate a failover for a single LUN, file system, or Data Mover.

◆ Upon activation of the destination site, the iSCSI LUNs are crash-consistent, appearing as if the source disk went offline, without the host or application being able to shut down gracefully. For SRDF/A, the destination is expected to be crash-consistent and some amount of data loss occurs, because the destination is a period of time behind the source.

◆ Because this implementation is for disaster recovery, not continuous availability, regardless of whether a disaster affects the iSCSI host directly, the iSCSI host loses connectivity during the failover activation, and it needs to recover services:

• For example, if a disaster affects the source site including an iSCSI host logged in to an iSCSI target on the source-site Celerra only, the destination site needs to be activated. An iSCSI host at the source site should be expected to time out, and become inaccessible in the amount of time that it takes the administrator to detect the failure of the source site, and decide to activate a failover to the destination site.


• By default, a failover activation causes the destination site to assume the same resources, IP addresses, MAC addresses, and other metadata information as the source site:

– The administrator can decide to use either an iSCSI host located at the destination, or use the original iSCSI host at the source site, if it was unaffected by the disaster.

– Regardless of which iSCSI host is used, the iSCSI LUN on disk is power-fail or crash-consistent and might need to be recovered using utilities such as fsck and chkdsk before being utilized.

If you use iSCSI with SRDF/A, and plan to activate a failover or perform a restore operation, use the following procedure for the iSCSI hosts to prevent possible Windows NT File System (NTFS) inconsistency:

1. Stop all Windows applications that use the Celerra iSCSI LUNs on the iSCSI hosts.

2. From the iSCSI Initiator Properties dialog box, navigate to the target properties and log out from the iSCSI initiator session to clear the session information.

You can now proceed to activate a failover or perform a restore.

If you use iSCSI with SRDF/A and need to activate a failover in response to a disaster scenario, perform these steps, then use the Windows chkdsk utility to check NTFS-level file system consistency, after the failover activation is complete. Consult Microsoft for detailed information about recovering data and the chkdsk utility.

Upgrading the Celerra SRDF environment

Local EMC personnel can help you determine the upgrade option that best suits your environment, and perform the procedures to upgrade the Celerra Network Servers in an SRDF environment to version 5.6 software for SRDF/A.

Because you have remotely protected data, the procedure enables you to restore from the destination volumes as a backout option, if needed.

To upgrade SRDF/A (or SRDF/S):

1. Halt all source Data Movers and shut down the Control Station.

2. Ensure that the source and destination Symmetrix DMX Celerra volumes are synchronized.

3. Halt the SRDF links to ensure that the appropriate device groups are suspended.

4. Restart the source Control Station and Data Movers.

5. Perform the upgrade on the source site.

6. Test or verify the upgrade.

7. Resume the SRDF links. For SRDF/A, ensure that the devices in the appropriate device groups are in a Consistent state.

You can now upgrade the destination by using steps 1 through 7. You must upgrade the destination Celerra immediately after you upgrade the source Celerra.


Note: The appropriate device group state for SRDF/A is Consistent. If it is not, consult the local EMC personnel or local EMC Service Provider to ensure that the SRDF/A device groups are established and that the devices in those groups are in a Consistent state.

SRDF/A task overview

Table 4 on page 25 provides an overview of the basic SRDF/A tasks to establish active/passive SRDF/A on a source and destination Celerra Network Server and their associated Celerra commands. When the activate and restore tasks are run, automatic, internal SRDF health checks are performed before activating a failover and before restoring source and destination Celerras, respectively. Adding the –nocheck option to the activate and restore commands allows you to skip this health check. For example:

# /nas/sbin/nas_rdf –activate –nocheck

Or

# /nas/sbin/nas_rdf –restore -nocheck

Table 5 on page 29 provides details of the health checks run by each command. Prior to performing any of these tasks, review the requirements summarized in "Symmetrix system configuration" on page 20 to ensure that the Symmetrix DMX systems and Celerra Data Movers are configured correctly. In general, your local EMC Customer Support Representative is available to help you set up and manage the SRDF/A configuration. "Troubleshooting SRDF/A" on page 66 describes how to gather information and resolve problems associated with SRDF/A configurations.

Table 4 SRDF/A task overview (page 1 of 4)

Task Command used What it does

Preinitialize the rela-tionship between the source and destina-tion Celerra.

From each Celerra, using nasadmin, log in as root:

nas_cel -create <cel_name> -ip <ip> -passphrase <pass-phrase>

• Establishes trusted communication between source and destination Celerra Network Servers as a prerequisite to SRDF/A initialization. Must be performed on both Celerra, using the same pass-phrase (6–15 characters).

• The nas_cel command replaces one of the nas_rdf -init commands from the previous versions.


Initialize an SRDF/A relationship between attached Cel-erra/Symmetrix pairs.

From source and desti-nation, as root:

/nas/sbin/nas_rdf -init

• If all SRDF volumes are in a Consistent state, enables the designated destination Celerra Network Server to provide full file system access and functionality if a site failure occurs.

• Configures the Control Station to use SRDF/A.

• Identifies the remote destination Celerra Network Server paired with the source Celerra Network Server.

• Identifies the volume mapping on the Symmetrix DMX system, which maps R1 volumes to their R2 counterparts.

• Establishes the Data Mover relationships from the production Data Mover to the standby.

• Runs the SRDF session state check before initialization.

• Runs the SRDF standby Data Mover configuration check and the Symmetrix device state check after initialization.

• Runs the device group configuration check and the Data Mover mirrored device accessibility check for both R1 and R2 device groups after initialization.




Activate an SRDF/A failover from a source Celerra to a destina-tion Celerra Network Server.

From destination, as root:

/nas/sbin/nas_rdf -activate

• Performs a test failover or manual failover. For example, a source Celerra Network server attached to a source Symmetrix system becomes unavailable. After the failover, users have access to the same file systems using the same network addresses as they did on the source, pro-vided they have network access to the remote Celerra site.

• Sets each R1 volume on the source Cel-erra Network Server (the one failing over) as read-only. This only occurs if the source Symmetrix system is available.

• Sets each R2 volume on the remote Sym-metrix as read/write.

• Enables each SRDF/A standby Data Mover on the remote Symmetrix to acquire the following characteristics of its source counterpart:• Network identity: IP and MAC

addresses of all network interface cards (NICs) in the failed Data Mover.

• Service identity: Network File Sys-tem/Common Internet File Service (NFS/CIFS) characteristics of the exported file system controlled by the failed Data Mover.

• Runs the SRDF standby Data Mover configuration check, the SRDF session state check, and the Symmetrix device state check before activating a failover.

• Runs the device group configuration check and the Data Mover mirrored device accessibility check for R2 device groups before activating a failover.




Restore a source Cel-erra Network Server after a failover.

From destination, as root:

/nas/sbin/nas_rdf -restore

• Typically scheduled by and performed under the guidance of your local EMC Customer Support Representative to ensure continuity between the Symmetrix systems. Restoration of a source Celerra involves a complete check of the Symme-trix system and SRDF/A and verification of full connectivity to the restored file sys-tems on the source Celerra Network Server.

• Copies data from R2 volumes to the corre-sponding R1 volume on the source Sym-metrix system.

• Restarts SRDF standby Data Movers into standby mode.

• Write-disables R2 volumes from the Data Movers.

• Synchronizes R2 to R1.• Resumes mirroring of the R1 devices.• Restarts each Data Mover on the source

Celerra Network Server and reacquires the IP addresses and file system control from the SRDF standby Data Movers.

• Runs the SRDF session state check, the Symmetrix device state check, and the SRDF restored state check before restoring a destination Celerra.

• Runs the device group configuration check and the Data Mover mirrored device accessibility check for R2 device groups before restoring a destination Celerra.

• Runs the Symmetrix device state check before restoring a source Celerra.

• Runs the device group configuration check and the Data Mover mirrored device accessibility check for R1 device groups before restoring a source Celerra.




Table 5 Health check details

Health check Description

SRDF standby Data Mover configuration check

Lists all slot IDs of SRDF source Data Movers on the source side, and compares the list with the list of all slot IDs of SRDF standby Data Movers on the destination side. If a slot from the source side is not an RDF standby Data Mover on the destination side, a warning message with the slot ID is displayed.

SRDF session state check Checks if all devices are synchronized. If they are not synchronized, and if they are in various states, a warning message is displayed. If none of them is synchronized, but all of them are in the same state, for example, all of them are consistent or partitioned, and so on, no warning message is displayed. When the nas_rdf –init command is run, if all the devices are partitioned, a warning message is displayed.

Device group configuration check

Lists all mirrored devices of an RDF group on backend (symrdf list) and compares the list with the list of devices in a device group created by using the symdg (symrdf –g <device group> query) command. If there is a missing device in the device group, a warning message is displayed.

Data Mover mirrored device accessibility check

Lists all devices in a device group, and compares the list with the list of devices obtained by using the server_devconfig –probe –scsi –all command. If there is a device in the device group that is not present in the output of the probe command, a warning message is displayed. Some of control volumes do not have TID/LUN depending on their configuration, and these are ignored in the check.

Symmetrix device state check Checks if there is a degraded or failed state device on the back end by using the symdev list –service_state notnormal command. If there is a degraded or failed state device, a warning message is displayed. All degraded or failed devices on the Symmetrix, including the devices that are not used for Celerra, are listed in the message.

SRDF restored state check Checks and displays an error message if the source volumes are R1 and ReadWrite, and if the destination volumes are R2 and ReadOnly. It does this by using the symdg show command.


Overview of the sample configuration

To illustrate these steps using a sample configuration, they are performed on the Celerra Network Servers as follows:

◆ cs100_src serves as the source Celerra Network Server. It resides in the production data center.

◆ cs110_dst serves as the destination Celerra Network Server. It resides in a remote disaster-recovery data center.

Note: In the example used for illustrating the configuration steps, cs100_src serves as the source Celerra Network Server that resides in the production data center, and cs110_dst serves as the destination Celerra Network Server that resides in a remote disaster-recovery data center.


Configuring

The tasks to configure SRDF/A are:

1. "Preinitialize the configuration" on page 31

2. "Initialize the configuration (active/passive)" on page 34

3. "Activate a failover (active/passive)" on page 47

4. "Restore the source Celerra" on page 60

Preinitialize the configuration

As part of establishing an SRDF/A configuration, the local EMC Service Provider preinitializes the Celerra Network Servers. Preinitialization establishes a trusted communication between the source and destination Celerra systems.

Prerequisites

◆ Preinitialization must be performed on both the Celerra systems.

◆ The source and destination Control Station system times must be within 10 minutes of each other.

◆ Preinitialization must be performed by using the same 6–15 character passphrase for both the Celerra. For example, nasadmin.

◆ The user must log in as nasadmin and then switch (su) to root.

◆ The nas_cel command must be run with the -create option as root on both the Celerra. Pre-5.6 versions of Celerra used the nas_rdf -init command for preinitialization. Versions 5.6 and later use the nas_cel -create command.

◆ The preinitialization tasks are performed only once, after which the servers become ready for the SRDF/A initialization procedures.

◆ The Celerra systems can be set up and in production prior to initialization.

◆ Preinitialization is a prerequisite to the SRDF/A initialization.

The tasks to preinitialize the configuration are:

1. "Preinitialize from the source (first) Celerra" on page 32

2. "Preinitialize from the destination (second) Celerra" on page 33

3. "Verify the preinitialization" on page 33


Preinitialize from the source (first) Celerra

Step Action

1. Log in to the source Celerra (cs100_src) as nasadmin and switch (su) to root.

2. Preinitialize the connection from the source (first) Celerra to the destination (second) Celerra in a Celerra/Symmetrix configuration for SRDF/A by using this command syntax:# nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

where:<cel_name> = name of the destination Celerra<ip> = IP address of the destination Control Station in slot 0 <passphrase> = 6–15 character password

Example:

To preinitialize the connection from cs100_src to cs110_dst with IP address 192.168.97.141 and passphrase nasadmin, type:# nas_cel -create cs110_dst -ip 192.168.97.141 -passphrase nasadminOutput:operation in progress (not interruptible)...id = 1 name = cs110_dstowner = 0device = channel = net_path = 192.168.97.141celerra_id = 0001901005570354passphrase = nasadmin

3. Exit root by typing:# exitexit


Preinitialize from the destination (second) Celerra

Verify the preinitialization

Step Action

1. Log in to the destination Celerra (cs100_dst) as nasadmin and switch (su) to root.

2. Preinitialize the connection from the destination (second) Celerra to the source (first) Celerra in a Celerra/Symmetrix configuration for SRDF/A by using this command syntax:# nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

where:<cel_name> = name of the source Celerra<ip> = IP address of the remote Control Station in slot 0<passphrase> = 6–15 character password

Example:

To preinitialize the connection from cs110_dst to cs100_src with IP address 192.168.97.140 and passphrase nasadmin, type:# nas_cel -create cs100_src -ip 192.168.97.140 -passphrase nasadminOutput:operation in progress (not interruptible)...id = 0 name = cs100_srcowner = 0device = channel = net_path = 192.168.97.140celerra_id = 000190100582034Dpassphrase = nasadmin


Step Action

1. Log in to the source Celerra (cs100_src) as nasadmin.

2. Verify preinitialization of cs100_src and cs110_dst by typing:$ nas_cel -listOutput:id name owner mount_dev channel net_path CMU0 cs100_src 0 192.168.97.140 000190100582034D1 cs110_dst 0 192.168.97.141 0001901005570354

Note: The id is always 0 for the system from which you are running the command.

Note: You do not have to run nas_cel -list as root (or nas_cel -info). You must run nas_cel as root for create, modify, update, or delete operations.


Initialize the configuration (active/passive)

Initializing an active/passive configuration establishes one Celerra Network Server to serve as the source (production) file server and another to serve as the destination.

Prerequisites

◆ Celerra software must be installed on the source and destination Celerra Network Servers.

◆ SRDF/A link must be operational between the source and destination Celerra Network Servers.

◆ The requirements summarized in "Symmetrix system configuration" on page 20 must be met to ensure that the Symmetrix systems and Celerra Data Movers are configured correctly.

◆ All SRDF/A volumes must be in a Consistent state. Your local EMC Customer Support Representative can help ensure volume consistency.

The tasks to initialize an active/passive configuration are:

1. "Initialize the source Celerra" on page 35

2. "Initialize the destination Celerra" on page 39

3. "Verify SRDF/A on the source Celerra (active/passive)" on page 44


Initialize the source Celerra

In an active/passive configuration, establish the source Celerra (active site) first.

Step Action


2. Verify the slots on the source Celerra by typing:# /nas/sbin/getreason

Output:

10 - slot_0 primary control station 5 - slot_2 contacted 5 - slot_3 contacted 5 - slot_4 contacted 5 - slot_5 contacted

3. List the Data Movers (servers) on the source Celerra by typing:# /nas/bin/nas_server -list

Output:

id type acl slot groupID state name1 1 1000 2 0 server_22 4 1000 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5


4. Get detailed information about the Data Movers on the source Celerra by typing:# nas_server -info -all

Output:

id = 1name = server_2acl = 1000, owner=nasadmin, ID=201type = nasslot = 2member_of =standby = server_3, policy=autostatus : defined = enabled actual = online, active

id = 2name = server_3acl = 1000, owner=nasadmin, ID=201type = standbyslot = 3member_of =standbyfor= server_2status : defined = enabled actual = online, ready

id = 3name = server_4acl = 1000, owner=nasadmin, ID=201type = nasslot = 4member_of =standby = server_5, policy=autostatus : defined = enabled actual = online, ready


5. Switch (su) to root by typing:$ suPassword:

Step Action


6. Start the active/passive SRDF/A initialization process on the source Celerra by typing:# /nas/sbin/nas_rdf -init Output:

Discover local storage devices ...

Discovering storage (may take several minutes)done

Start R2 dos client...doneStart R2 nas client...done

Contact cs110_dst... is alive

Step Action


7. At the prompt, assign the remote standby Data Mover on the destination Celerra for each source (primary) Data Mover on the source Celerra. For each source Data Mover on cs100_src, type the slot number of its corresponding standby on cs110_dst.

Note: The actual standby designation occurs later in the procedure. Review "Celerra Data Mover configuration checklist" on page 22 to determine which Data Movers to designate as standbys. Data Movers are referred to as servers, and named server_n, starting with server_2. In the example, server_2 (source Data Mover) and server_3 (local standby Data Mover) have remote SRDF/A standby Data Movers, that is, local server_2, slot 2, fails over to the remote server in slot 2, and local server_3, slot 3, fails over to the remote server in slot 3. Also, server_4 and server_5 are local Data Movers not protected by SRDF (not configured with SRDF/A standby Data Movers).

Example:Please create a rdf standby for each server listedserver server_2 in slot 2, remote standby in slot [2] (or none): 2

server_2 : doneid = 1name = server_2acl = 1000, owner=nasadmin, ID=201type = nasslot = 2member_of =standby = server_3, policy=autoRDFstandby= slot=2status : defined = enabled actual = online, active

server server_3 in slot 3, remote standby in slot [3] (or none): 3

server_3 : doneid = 2name = server_3acl = 1000, owner=nasadmin, ID=201type = standbyslot = 3member_of =standbyfor= server_2RDFstandby= slot=3status : defined = enabled actual = online, ready

server server_4 in slot 4, remote standby in slot [4] (or none):noneserver server_5 in slot 5, remote standby in slot [5] (or none):none

The slot [ 2 3 ] on the remote cs110_dst system must be an rdf standby Data Mover(s). Currently the slot [ 2 3 ] is not configured as an rdf standby Data Mover(s). Please run the nas_rdf -init command on the remote cs110_dst system.

Step Action


Initialize the destination Celerra

Step Action

1. Log in to the destination Celerra (cs110_dst) as nasadmin.

2. Verify the slots on the destination Celerra by typing:# /nas/sbin/getreason

Output:


3. List the Data Movers (servers) on the destination Celerra by typing:# /nas/bin/nas_server -list

Output:


Note: The output indicates that server_2 and server_3 are free to be configured as SRDF/A standbys for the source Celerra (cs100_src), because they are not local standbys.


4. Get detailed information about the destination Data Movers on the destination Celerra by typing:# nas_server -info -all

Output:

id = 1name = server_2acl = 1000, owner=nasadmin, ID=201type = nasslot = 2member_of =standby =status : defined = enabled actual = online, ready





Step Action


6. Initialize the destination Celerra for active/passive SRDF/A by typing:# /nas/sbin/nas_rdf -init

Discover local storage devices ...


Start R2 dos client...doneStart R2 nas client...done

Contact cs100_src ... is alive

7. At the prompt, create the RDF administrative account (rdfadmin) on the Control Station.

Note: Use the rdfadmin account to manage the destination SRDF/A standby Data Movers on cs110_dst that provide the failover capability for cs100_src. The RDF site passphrase must consist of 6–15 characters, and be the same for the source and destination Celerra systems.

Example:

Please create a new login account to manage RDF site cs100_srcNew login: rdfadminNew password:BAD PASSWORD: it is based on a dictionary wordRetype new password:Changing password for user rdfadminpasswd: all authentication tokens updated successfullydoneoperation in progress (not interruptible)...id = 1name = cs100_srcowner = 500device = /dev/ndj1channel = rdev=/dev/ndg, off_MB=391; wdev=/dev/nda, off_MB=391net_path = 192.168.97.140celerra_id = 000190100582034Dpassphrase = rdfadmin

Discover remote storage devices ...done

The following servers have been detected on the system:id type acl slot groupID state name1 1 1000 2 0 server_22 1 1000 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5

Note: The IDs of the Data Movers in the id column are used in the next step.

Step Action


8. At the prompt, designate the Data Movers on the destination Celerra as SRDF/A standby Data Movers for the source Celerra. To designate the standby Data Movers, type the ID number (not the slot number) of a single Data Mover or ID numbers for multiple servers, separated by spaces.

Note: For failover capability, each standby Data Mover previously assigned to a source (primary) Data Mover on cs100_src must be designated as a standby on cs110_dst. Review the Data Mover list created in "Celerra Data Mover configuration checklist" on page 22 to determine which servers to designate as standbys. Ensure that you review the checklist if you have a Celerra NS series gateway configuration with two Data Movers, and a default local standby Data Mover. During the source Celerra Network Server initialization process, the term slots identifies the remote SRDF/A standby Data Mover. During the destination Celerra Network Server initialization process, the term server_ids identifies the SRDF/A standby Data Mover.

CAUTION!Before you set up an SRDF standby Data Mover at the destination site, check the Data Mover configurations at the source and destination sites. Verify that the SRDF standby Data Mover is in the appropriate slot. Verify that the hardware, including network interface adapters, is the same for the source and SRDF standby Data Movers for failover purposes. Also, ensure that the destination Data Movers do not have any local standbys defined, as provided in the default installation, for example, server_5 is, by default, a standby for server_2, server_3, and server_4.

Example:

Please enter the id(s) of the server(s) you wish to reserve(separated by spaces) or "none" for no servers.Select server(s) to use as standby: 1 2

id = 1name = server_2acl = 2000, owner=rdfadmin, ID=500type = standbyslot = 2member_of =standbyfor=status : defined = enabled actual = boot_level=0

id = 2name = server_3acl = 2000, owner=rdfadmin, ID=500type = standbyslot = 3member_of =standbyfor=status : defined = enabled actual = boot_level=0

Step Action


operation in progress (not interruptible)...id = 1name = cs100_srcowner = 500device = /dev/ndj1channel = rdev=/dev/ndg, off_MB=391; wdev=/dev/nda, off_MB=391net_path = 192.168.97.140celerra_id = 000190100582034Dpassphrase = rdfadmin

Please create a rdf standby for each server listedserver server_5 in slot 5, remote standby in slot [5] (or none): noneserver server_4 in slot 4, remote standby in slot [4] (or none): none

Note: If you use the nas_server -list command to list the available Data Movers on the destination Celerra (cs110_dst), only server_4 and server_5 appear. Data Movers server_2 and server_3 are unavailable to the nasadmin account because they are now managed by the rdfadmin account.


Note: The initialization process is complete and the active/passive configuration is established. The destination Celerra Network Server is ready to provide full file system access and functionality if a source site failure occurs.

Note

If the IP address of the Control Station changes after the initialization process runs, rerun the /nas/sbin/nas_rdf -init command to accommodate the change. If you change any hostnames or IP addresses and want to accommodate the change before you run the initialization process, edit and update the /etc/hosts file and ensure that each host can resolve its node name.

Step Action


Verify SRDF/A on the source Celerra (active/passive)

After initialization, run Celerra CLI commands, informational Solutions Enabler Symmetrix CLI (SYMCLI) commands, or both to verify SRDF/A on the source Celerra Network Server.

Step Action


2. List the file systems on the source Celerra by typing:$ nas_fs -list

Output:

id inuse type acl volume name server1 n 1 0 74 root_fs_12 y 1 0 76 root_fs_2 13 y 1 0 78 root_fs_3 24 y 1 0 80 root_fs_4 35 y 1 0 82 root_fs_5 46 n 1 0 84 root_fs_67 n 1 0 86 root_fs_78 n 1 0 88 root_fs_89 n 1 0 90 root_fs_910 n 1 0 92 root_fs_1011 n 1 0 94 root_fs_1112 n 1 0 96 root_fs_1213 n 1 0 98 root_fs_1314 n 1 0 100 root_fs_1415 n 1 0 102 root_fs_1516 y 1 0 104 root_fs_common 2,1,317 n 5 0 137 root_fs_ufslog18 n 5 0 140 root_fs_d319 n 5 0 141 root_fs_d420 n 5 0 142 root_fs_d521 n 5 0 143 root_fs_d622 n 1 0 156 fs123 y 1 0 157 fs2 124 n 1 0 161 fs8k25 n 1 0 162 fs32k26 n 1 0 163 fs64k27 n 1 0 164 ufs128 n 5 0 165 root_panic_reserve29 n 1 0 229 ufs1_snap131 y 1 0 233 fs1a 132 y 1 0 234 fst1 135 y 1 0 292 fs5 3


3. List the device groups on the source Celerra by typing:$ /nas/symcli/bin/symdg list

Output:

D E V I C E G R O U P S

Number of Name Type Valid Symmetrix ID Devs GKs BCVs VDEVs TGTs

1R1_3 RDF1 Yes 000190100582 70 0 0 0 0 1REG REGULAR Yes 000190100582 48 0 64 0 0

Note: In the sample configuration, these device groups represent the following: 1R1_3 represents the SRDF/A-protected R1 data volumes and 1REG represents the local (non-SRDF/A) volumes. The device groups in the configuration might have different names.

Note: Use only Solutions Enabler Symmetrix SYMCLI informational commands on the Celerra device group; do not invoke any Solutions Enabler Symmetrix SYMCLI action commands using the Control Station host component, laptop service processor, or EMC ControlCenter. The Solutions Enabler Symmetrix SRDF family documentation on the EMC Powerlink website provides more information.

Step Action



4. View key SRDF/A information for the device group representing the R1 data volumes (for example, 1R1_3) by typing:$ /nas/symcli/bin/symrdf -g 1R1_3 query -rdfa

Note: Ensure that you provide the appropriate device group name with the command. Information you can monitor is highlighted in the output. Also, the output uses “...” to indicate a continuation of the device entries; not all entries are listed.

Output:

Device Group (DG) Name : 1R1_3DG's Type : RDF1DG's Symmetrix ID : 000190100582

RDFA Session Number : 2RDFA Cycle Number : 139RDFA Session Status : ActiveRDFA Minimum Cycle Time : 00:00:30RDFA Avg Cycle Time : 00:00:30Duration of Last cycle : 00:00:30RDFA Session Priority : 33Tracks not Committed to the R2 Side: 36Time that R2 is behind R1 : 00:00:36RDFA R1 Side Percent Cache In Use : 0RDFA R2 Side Percent Cache In Use : 0Transmit Idle Time : 00:00:00

Source (R1) View Target (R2) View MODES-------------------------------- ------------------------ ----- ------------ ST LI STStandard A N ALogical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF PairDevice Dev E Tracks Tracks S Dev E Tracks Tracks MDAC STATE-------------------------------- -- ------------------------ ----- ------------d1 034D RW 0 0 RW 034D WD 0 0 A... Consistentd2 034E RW 0 0 RW 034E WD 0 0 A... Consistentd3 034F RW 0 0 RW 034F WD 0 0 A... Consistentd4 0350 RW 0 0 RW 0350 WD 0 0 A... Consistentd5 0351 RW 0 0 RW 0351 WD 0 0 A... Consistentd6 0352 RW 0 0 RW 0352 WD 0 0 A... Consistentd7 035A RW 0 0 RW 035A WD 0 0 A... Consistentd8 035B RW 0 0 RW 035B WD 0 0 A... Consistentd9 035C RW 0 0 RW 035C WD 0 0 A... Consistentd10 035D RW 0 0 RW 035D WD 0 0 A... Consistent...d138 0397 RW 0 0 RW 0397 WD 0 0 A... Consistentd139 0398 RW 0 0 RW 0398 WD 0 0 A... Consistentd140 0399 RW 0 0 RW 0399 WD 0 0 A... Consistent

Total -------- -------- -------- -------- Track(s) 0 0 0 0 MB(s) 0.0 0.0 0.0 0.0

Legend for MODES:

M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy D(omino) : X = Enabled, . = Disabled A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off C(onsistency State): X = Enabled, . = Disabled, - = N/A

Note: Check the session status, average cycle time, tracks not committed to R2, time R2 is behind R1 (in seconds), as well as the mode (A for asynchronous) and RDF pair state (Consistent).

Step Action


Activate a failover (active/passive)

Activating a failover enables the destination Celerra Network Server to assume the source (primary) role in the active/passive SRDF/A configuration.

Prerequisites

You might decide to perform a planned (graceful) failover for testing purposes, which involves preparation before the failover is activated, or you might need to activate an unplanned failover in response to a disaster scenario.

In an unplanned failover scenario, assume that the source Celerra Network Server attached to a source Symmetrix system is unavailable, and requires a failover to the destination Celerra Network Server. Regardless of the planned or unplanned failover scenario, you always activate a failover by running the /nas/sbin/nas_rdf -activate command from the destination Celerra Network Server.

The tasks to activate an active/passive SRDF/A failover are:

1. "Prepare for a graceful failover" on page 48

2. "Activate a failover from the destination Celerra" on page 49

3. "Verify SRDF/A after failover activation" on page 53

4. "Ensure access after failover" on page 59

!CAUTION!For sites with redundant Control Stations, ensure that all SRDF management commands including /nas/sbin/nas_rdf -init, -activate, and -restore are run from the primary Control Station located in slot 0 (CS0). Ensure that CS1 is powered off at both sites before you run any -activate or -restore commands. When the CS1 shutdown process completes, type /nas/sbin/getreason and check the output to verify the shutdown. The output should contain the line 0 - slot_1 powered off.


Prepare for a graceful failover

Step Action

1. Log in to the source Celerra (cs100_src) as nasadmin and switch (su) to root.

2. Halt all Data Movers and restart the source Control Station (CS0) for the source Celerra by typing:# /nas/sbin/nas_halt now

Note: As an alternative to nas_halt, you can run server_cpu ALL -halt now &, to halt all the Data Movers. However, this requires an explicit restart of the source Control Station (CS0) with -reboot -f -n. For an NS600, server_cpu is the recommended command.

Output:

************************** WARNING! ****************************

You are about to HALT this Celerra including all of its Control Stations and Data Movers.DATA will be UNAVAILABLE when the system is halted.Note that this command does *not* halt the storage array.

3. At the prompt, confirm the halting by typing yes.

Example:ARE YOU SURE YOU WANT TO CONTINUE? [ yes or no ] : yes

Sending the halt signal to the Master Control Daemon...: DoneFeb 7 18:39:35 cs100_src EMCServer: nas_mcd: Check and halt other CS...: DoneFeb 7 18:40:00 cs100_src get_datamover_status: Data Mover server_2: COMMAND doesnt match.Feb 7 18:40:00 cs100_src get_datamover_status: Data Mover server_5: COMMAND doesnt match.Feb 7 18:40:01 cs100_src get_datamover_status: Data Mover server_3: COMMAND doesnt match.Feb 7 18:40:01 cs100_src get_datamover_status: Data Mover server_4: COMMAND doesnt match.Feb 7 18:40:12 cs100_src setup_enclosure: Executing -dhcpd stop optionFeb 7 18:40:12 cs100_src snmptrapd[4743]: Stopping snmptrapdFeb 7 18:40:12 cs100_src EV_AGENT[7847]: Signal TERM receivedFeb 7 18:40:12 cs100_src EV_AGENT[7847]: Agent is going downFeb 7 18:40:24 cs100_src DHCPDMON: Starting DHCPD on CS 0Feb 7 18:40:26 cs100_src setup_enclosure: Executing -dhcpd start optionFeb 7 18:40:26 cs100_src dhcpd: Internet Software Consortium DHCP Server V3.0pl1Feb 7 18:40:26 cs100_src dhcpd: Copyright 1995-2001 Internet Software Consortium.Feb 7 18:40:26 cs100_src dhcpd: All rights reserved.Feb 7 18:40:26 cs100_src dhcpd: For info, please visit http://www.isc.org/products/DHCPFeb 7 18:40:26 cs100_src dhcpd: Wrote 0 deleted host decls to leases file.Feb 7 18:40:26 cs100_src dhcpd: Wrote 0 new dynamic host decls to leases file.Feb 7 18:40:26 cs100_src dhcpd: Wrote 0 leases to leases file.Feb 7 18:40:26 cs100_src dhcpd: Listening on LPF/eth2/00:00:f0:9c:1f:d5/128.221.253.0/24Feb 7 18:40:26 cs100_src dhcpd: Sending on LPF/eth2/00:00:f0:9c:1f:d5/128.221.253.0/24Feb 7 18:40:26 cs100_src dhcpd: Listening on LPF/eth0/00:00:f0:9d:00:e2/128.221.252.0/24Feb 7 18:40:26 cs100_src dhcpd: Sending on LPF/eth0/00:00:f0:9d:00:e2/128.221.252.0/24Feb 7 18:40:26 cs100_src dhcpd: Sending on Socket/fallback/fallback-netFeb 7 18:40:40 cs100_src mcd_helper: : Failed to umount /nas (0)Feb 7 18:40:40 cs100_src EMCServer: nas_mcd: Failed to gracefully shutdown MCD and haltservers. Forcing halt and reboot...Feb 7 18:40:40 cs100_src EMCServer: nas_mcd: Halting all servers...


Activate a failover from the destination Celerra

Step Action

1. Log in to the destination Celerra (cs110_dst) as nasadmin.

Note: The activation must always be performed from the destination Celerra.

2. List the device groups on the destination Celerra by typing: $ /nas/symcli/bin/symdg list

Output:

D E V I C E G R O U P S

Number of Name Type Valid Symmetrix ID Devs GKs BCVs VDEVs TGTs

1R1_4 RDF1 Yes 000190100557 6 0 0 0 0 1REG REGULAR Yes 000190100557 0 0 62 0 0 1R2_500_3 RDF2 Yes 000190100557 70 0 0 0 0

Note: In the sample cs110_dst configuration, these device groups represent the following: 1R1_4 represents the R1 volumes of the destination Control Station, 1REG represents the local (non-SRDF/A) volumes, and 1R2_500_3 represents the R2 data volumes. The device groups in the configuration might have different names.

Note: These steps apply to both types of failover scenarios (graceful or disaster recovery). However, the sample output is based on a graceful failover activation.


3. Query the destination’s SRDF/A information for the device group representing the R2 data volumes (on cs110_dst, 1R2_500_3) by typing:$ /nas/symcli/bin/symrdf -g 1R2_500_3 query -rdfa

Note: The output uses “...” to indicate a continuation of the device entries; not all device entries are listed.

Output:

Device Group (DG) Name : 1R2_500_3DG's Type : RDF2DG's Symmetrix ID : 000190100557

RDFA Session Number : 2RDFA Cycle Number : 41RDFA Session Status : ActiveRDFA Minimum Cycle Time : 00:00:30RDFA Avg Cycle Time : 00:00:30Duration of Last cycle : 00:00:30RDFA Session Priority : 33Tracks not Committed to the R2 Side: 1276Time that R2 is behind R1 : 00:00:32RDFA R1 Side Percent Cache In Use : 0RDFA R2 Side Percent Cache In Use : 0Transmit Idle Time : 00:00:00

Target (R2) View Source (R1) View MODES-------------------------------- ------------------------ ----- ------------ ST LI STStandard A N ALogical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF PairDevice Dev E Tracks Tracks S Dev E Tracks Tracks MDAC STATE-------------------------------- -- ------------------------ ----- ------------DEV001 034D WD 0 0 RW 034D RW 0 0 A... ConsistentDEV002 034E WD 0 0 RW 034E RW 0 0 A... ConsistentDEV003 034F WD 0 0 RW 034F RW 0 0 A... ConsistentDEV004 0350 WD 0 0 RW 0350 RW 0 0 A... ConsistentDEV005 0351 WD 0 0 RW 0351 RW 0 0 A... ConsistentDEV006 0352 WD 0 0 RW 0352 RW 0 0 A... ConsistentDEV007 035A WD 0 0 RW 035A RW 0 0 A... ConsistentDEV008 035B WD 0 0 RW 035B RW 0 0 A... ConsistentDEV009 035C WD 0 0 RW 035C RW 0 0 A... ConsistentDEV010 035D WD 0 0 RW 035D RW 0 0 A... Consistent...DEV067 0396 WD 0 0 RW 0396 RW 0 0 A... ConsistentDEV068 0397 WD 0 0 RW 0397 RW 0 0 A... ConsistentDEV069 0398 WD 0 0 RW 0398 RW 0 0 A... ConsistentDEV070 0399 WD 0 0 RW 0399 RW 0 0 A... Consistent

Total -------- -------- -------- -------- Track(s) 0 0 0 0 MB(s) 0.0 0.0 0.0 0.0

Legend for MODES:


Step Action


4. Switch (su) to rdfadmin by typing: $ su - rdfadminPassword:


6. Activate the failover by typing: # /nas/sbin/nas_rdf -activate

CAUTION!For sites with redundant Control Stations, the /nas/sbin/nas_rdf -activate command must be run from the primary Control Station located in slot 0 (CS0). Ensure that CS1 is powered off at both sites before you run the nas_rdf -activate command, and CS1 remains powered off for the duration of the activate and subsequent restore operations.

Note: Ensure that all Data Movers at the source are halted before proceeding. At the destination, do not shut down or restart any Data Movers, that is, SRDF-protected or non-SRDF Data Movers, while the nas_rdf -activate or nas_rdf -restore command is running. This might interrupt Celerra’s communication with the backend and cause the command to fail.

7. At the prompt, if this is a true disaster scenario, ensure that you have powered off the source Celerra:Is remote site cs100_src completely shut down (power OFF)?

Note: This prompt serves as a reminder to shut down the source site in a disaster scenario. If you are performing a graceful failover for testing purposes, the source Celerra can remain powered on.

Step Action


8. At the next prompt, confirm the SRDF/A activation by typing yes.

Example:Do you wish to continue [yes or no]: yesSuccessfully pinged (Remotely) Symmetrix ID: 000190100582

Note: The ping success message appears if the Symmetrix DMX system attached to the source Celerra is successfully contacted, indicating it is operational and ready on the SRDF/A link.

Note: Activating the destination Celerra write-enables the destination volumes and write-disables the source volumes, as long as SRDF/A and the source Symmetrix system are operational.

An RDF 'Failover' operation execution is in progress for device group '1R2_500_3'. Please wait...

Write Disable device(s) on SA at source (R1)..............Done. Suspend RDF link(s).......................................Started. Suspend RDF link(s).......................................Done. Suspend RDF link(s).......................................Started. Suspend RDF link(s).......................................Done. Read/Write Enable device(s) on RA at target (R2)..........Done. Suspend RDF link(s).......................................Started. Suspend RDF link(s).......................................Done.

The RDF 'Failover' operation successfully executed for device group '1R2_500_3'.

Note: A file system check is executed on the R2 control volumes of the source’s Control Station file systems.

Waiting for nbs clients to die ... done/net/500 /etc/auto.500 -t 1,ro/dev/ndj1: recovering journal/dev/ndj1: clean, 11591/231360 files, 204230/461860 blocksfsck 1.26 (3-Feb-2002)Waiting for nbs clients to die ... doneid type acl slot groupID state name1 1 1000 2 0 server_22 4 1000 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5

Note: The SRDF/A standby Data Movers now become active.

server_2 : server_2 : going offline rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_3 : server_3 : going offline rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configured

Step Action


Verify SRDF/A after failover activation

9. Exit root by typing:# exit

exit

Note: The failover is complete.

Note

In a true disaster scenario where the source Symmetrix DMX system is unavailable, contact your local EMC Customer Support Representative to coordinate restoration activities.

Step Action

Step Action

1. Log in to the destination Celerra (cs110_dst) as rdfadmin.

2. List the available Data Movers at the destination by typing:$ /nas/bin/nas_server -list

Output:

id type acl slot groupID state name1 1 0 2 0 server_22 4 0 3 0 server_3

Note: This command shows the Data Mover server table with the ID, type, access control list (ACL) value, slot number, group ID, state, and name of the Data Mover.

Note: You can run Celerra CLI commands, informational SYMCLI commands, or both to verify the SRDF/A configuration on the write-enabled destination Celerra.

3. List and manage the file systems mounted for the Data Movers now active at the destination by typing:$ /nas/bin/server_mount ALL

Output:

server_2 :root_fs_2 on / uxfs,perm,rwroot_fs_common on /.etc_common uxfs,perm,rofs2 on /fs2 uxfs,perm,rwfs1a on /fs1a uxfs,perm,rwfst1 on /fst1 uxfs,perm,rw

server_3 :root_fs_3 on / uxfs,perm,rw,<unmounted>root_fs_common on /.etc_common uxfs,perm,ro,<unmounted>

Note: The standby Data Movers activated at the destination acquire the IP and MAC addresses, file systems, and export tables of their counterparts on the source and have read/write access to all the R2 volumes on the destination.


4. List interface configuration information for Data Mover server_2 by typing:$ /nas/bin/server_ifconfig server_2 -all

Output:

server_2 :cge1 protocol=IP device=cge1 inet=192.168.97.147 netmask=255.255.255.0 broadcast=192.168.97.255 UP, ethernet, mtu=1500, vlan=0, macaddr=0:60:16:9:32:71loop protocol=IP device=loop inet=127.0.0.1 netmask=255.0.0.0 broadcast=127.255.255.255 UP, loopback, mtu=32768, vlan=0, macaddr=0:0:0:0:0:0 netname=localhostel31 protocol=IP device=mge1 inet=128.221.253.2 netmask=255.255.255.0 broadcast=128.221.253.255 UP, ethernet, mtu=1500, vlan=0, macaddr=0:60:16:5:5d:23 netname=localhostel30 protocol=IP device=mge0 inet=128.221.252.2 netmask=255.255.255.0 broadcast=128.221.252.255 UP, ethernet, mtu=1500, vlan=0, macaddr=0:60:16:5:5d:24 netname=localhost

Step Action


5. Display disk information after the failover activation by typing:$ nas_disk -list

Output:

id inuse sizeMB storageID-devID type name servers1 y 11619 000190300281-002C STD root_disk 1,22 y 11619 000190300281-002D STD root_ldisk 1,23 y 2077 000190300281-002E STD d3 1,24 y 2077 000190300281-002F STD d4 1,25 y 2077 000190300281-0030 STD d5 1,26 y 31874 000190300281-0031 STD d6 1,27 n 22999 000190300281-0083 STD d7 1,28 n 22999 000190300281-0084 STD d8 1,29 n 22999 000190300281-0085 STD d9 1,210 n 22999 000190300281-0086 STD d10 1,211 y 22999 000190300281-0087 STD d11 1,212 n 22999 000190300281-0088 STD d12 1,213 n 22999 000190300281-0089 STD d13 1,214 y 22999 000190300281-008A STD d14 1,215 y 22999 000190300281-008B STD d15 1,216 y 22999 000190300281-008C STD d16 1,217 y 22999 000190300281-008D STD d17 1,218 y 22999 000190300281-008E STD d18 1,219 n 22999 000190300281-008F STD d19 1,220 n 22999 000190300281-0090 STD d20 1,221 n 22999 000190300281-0091 STD d21 1,222 n 22999 000190300281-0092 STD d22 1,223 n 22999 000190300281-0093 STD d23 1,224 n 22999 000190300281-0094 STD d24 1,225 n 22999 000190300281-0095 STD d25 1,226 n 22999 000190300281-0096 STD d26 1,227 n 22999 000190300281-00AB BCV rootd27 1,228 n 22999 000190300281-00AC BCV rootd28 1,229 n 22999 000190300281-00AD BCV rootd29 1,230 n 22999 000190300281-00AE BCV rootd30 1,231 n 22999 000190300281-00AF BCV rootd31 1,232 y 61424 000190300281-00B6 ATA d32 1,233 y 61424 000190300281-00B7 ATA d33 1,234 y 61424 000190300281-00B8 ATA d34 1,235 y 61424 000190300281-00B9 ATA d35 1,236 y 61424 000190300281-00BA ATA d36 1,237 y 61424 000190300281-00BB ATA d37 1,238 y 61424 000190300281-00BC ATA d38 1,239 y 61424 000190300281-00BD ATA d39 1,240 y 61424 000190300281-00BE ATA d40 1,241 y 61424 000190300281-00BF ATA d41 1,242 y 61424 000190300281-00C0 ATA d42 1,243 y 61424 000190300281-00C1 ATA d43 1,244 n 61424 000190300281-00C2 ATA d44 1,245 y 61424 000190300281-00C3 ATA d45 1,246 y 61424 000190300281-00C4 ATA d46 1,2

Step Action


47 y 61424 000190300281-00C5 BCVA rootd47 1,248 y 61424 000190300281-00C6 BCVA rootd48 1,249 y 61424 000190300281-00C7 BCVA rootd49 1,250 y 61424 000190300281-00C8 BCVA rootd50 1,251 n 61424 000190300281-00C9 BCVA rootd51 1,252 n 61424 000190300281-00CA R1ATA d52 1,253 n 61424 000190300281-00CB R1ATA d53 1,254 y 61424 000190300281-00CC R1ATA d54 1,255 y 61424 000190300281-00CD R1ATA d55 1,256 y 61424 000190300281-00CE R1ATA d56 1,257 n 61424 000190300281-00D4 R1BCA rootd57 1,258 n 61424 000190300281-00D5 R1BCA rootd58 1,259 n 61424 000190300281-00D6 R1BCA rootd59 1,260 n 61424 000190300281-00D7 R1BCA rootd60 1,261 n 61424 000190300281-00D8 R1BCA rootd61 1,2

6. Display information for the Data Movers and the file systems at the destination after the failover activation, including the available disk space for all Data Movers or file systems and how much of a file system’s total capacity has been used by typing:$ /nas/bin/server_df ALL

[server_2 :server_2 :Filesystem kbytes used avail capacity Mounted onfst1 28798424 600 28797824 0% /fst1fs1a 9224 600 8624 7% /fs1afs2 460787024 600 460786424 0% /fs2root_fs_common 13624 5264 8360 39% /.etc_commonroot_fs_2 114592 776 113816 1% /

server_3 :Error 2: server_3 : No such file or directoryno error message in response

Step Action


7. Query the key SRDF/A information now existing for the destination device group with the data volumes (on cs110_dst, 1R2_500_3) by using this command syntax: $ /nas/symcli/bin/symrdf -g <group> query -rdfawhere:<group> = name of the device group

Note: Use only Solutions Enabler Symmetrix SYMCLI informational commands on the Celerra device group; do not invoke any Solutions Enabler Symmetrix SYMCLI action commands using the Control Station host component, laptop service processor, or EMC ControlCenter. The Solutions Enabler Symmetrix SRDF family documentation on the EMC Powerlink website provides more information.

Note: The session state is now Inactive, the mode is A for asynchronous, and the RDF pair state is now Failed Over. Also, note the output uses “...” to indicate a continuation of the device entries, because not all device entries are listed.

Example:$ /nas/symcli/bin/symrdf -g 1R2_500_3 query -rdfa


RDFA Session Number : 2RDFA Cycle Number : 0RDFA Session Status : InactiveRDFA Minimum Cycle Time : 00:00:30RDFA Avg Cycle Time : 00:00:00Duration of Last cycle : 00:00:00RDFA Session Priority : 33Tracks not Committed to the R2 Side: 0Time that R2 is behind R1 : 00:00:00RDFA R1 Side Percent Cache In Use : 0RDFA R2 Side Percent Cache In Use : 0Transmit Idle Time : 00:00:00

Step Action



Target (R2) View Source (R1) View MODES-------------------------------- ------------------------ ----- ------------ ST LI STStandard A N ALogical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF PairDevice Dev E Tracks Tracks S Dev E Tracks Tracks MDAC STATE-------------------------------- -- ------------------------ ----- ------------

DEV001 034D RW 20 0 NR 034D WD 0 0 A... Failed OverDEV002 034E RW 2048 0 NR 034E WD 0 0 A... Failed OverDEV003 034F RW 0 0 NR 034F WD 0 0 A... Failed OverDEV004 0350 RW 0 0 NR 0350 WD 0 0 A... Failed OverDEV005 0351 RW 1204 0 NR 0351 WD 0 0 A... Failed OverDEV006 0352 RW 0 0 NR 0352 WD 0 0 A... Failed OverDEV007 035A RW 0 0 NR 035A WD 0 0 A... Failed OverDEV008 035B RW 0 0 NR 035B WD 0 0 A... Failed OverDEV009 035C RW 0 0 NR 035C WD 0 0 A... Failed OverDEV010 035D RW 0 0 NR 035D WD 0 0 A... Failed Over

...DEV060 038F RW 0 0 NR 038F WD 0 0 A... Failed OverDEV061 0390 RW 0 0 NR 0390 WD 0 0 A... Failed OverDEV062 0391 RW 0 0 NR 0391 WD 0 0 A... Failed OverDEV063 0392 RW 0 0 NR 0392 WD 0 0 A... Failed OverDEV064 0393 RW 0 0 NR 0393 WD 0 0 A... Failed OverDEV065 0394 RW 2 0 NR 0394 WD 0 0 A... Failed OverDEV066 0395 RW 2 0 NR 0395 WD 0 0 A... Failed OverDEV067 0396 RW 0 0 NR 0396 WD 0 0 A... Failed OverDEV068 0397 RW 0 0 NR 0397 WD 0 0 A... Failed OverDEV069 0398 RW 0 0 NR 0398 WD 0 0 A... Failed OverDEV070 0399 RW 0 0 NR 0399 WD 0 0 A... Failed Over

Total -------- -------- -------- -------- Track(s) 3280 0 0 0 MB(s) 102.5 0.0 0.0 0.0

Legend for MODES:


Step Action


Ensure access after failover

If you have not accounted for different IP subnets at the source and destination sites, perform these steps after a failover to ensure that users have access to the same file systems, using the same network addresses as they did on the source-site Celerra, provided they have network access to the destination-site Celerra.

Step Action

1. Halt CIFS.

2. Set IP addresses and default routes.

3. Adjust services such as WINs, DNS, NIS, and NTP.

4. Restart CIFS.

Note

You can perform these steps either manually or by creating and running a script. If you perform these steps at the destination site after activation, you must also perform these steps at the source site after the /nas/sbin/nas_rdf -restore command completes. These steps are required at the source to return everything to the original configuration. "Restore the source Celerra" on page 60 provides information about the restore procedures.


Restore the source Celerra

A restore of the source Celerra is a planned, scheduled event performed by or under the guidance of your local EMC Customer Support Representative to ensure continuity between the Symmetrix DMX systems.

The tasks to restore the source Celerra are:

1. "Prepare for the restore" on page 60

2. "Restore from the destination" on page 61

!CAUTION!For sites with redundant Control Stations, ensure that all SRDF management commands including nas_rdf -init, -activate, and -restore are run from the primary Control Station located in slot 0 (CS0). Always ensure that CS1 is powered off at both sites before you run any -activate or -restore commands. When the CS1 shutdown process completes, type /nas/sbin/getreason and check the output to verify the shutdown. The output should contain the line 0 - slot_1 powered off. Because this is a planned event, ensure that you keep CS1 powered off for the duration of the event.

Prepare for the restore

Perform these steps under the guidance of your local EMC Customer Support Representative.

Step Action

1. Verify proper SRDF/A operations by performing a complete system check of the Symmetrix system and SRDF/A.

CAUTION!If this is a true disaster scenario, keep the source Celerra (cs100_src) powered off until you are instructed to power it up by your local EMC Customer Support Representative. Your local EMC Customer Support Representative ensures proper operation of the Symmetrix system attached to the source Celerra Network Server.

CAUTION!Proceed only after confirmation from your EMC Customer Support Representative.

2. Power up the source Celerra, ensuring that the source Control Station restarts, and perform a restart by typing:# reboot -f -n

Note: You can now perform the restore from the destination Celerra.


Restore from the destination

The restoration process occurs in two phases:

◆ The device-group update phase provides network clients continued access to the destination Celerra Network Server while the destination Symmetrix system updates the source Symmetrix system. The length of the update phase is based on the amount of data changed since the destination system was activated.

◆ The device-group failback phase is typically short in duration, usually under 20 minutes, and network clients are suspended from file system access while the file systems fully synchronize from the destination to the source Symmetrix system.

Step Action

1. Log in to the destination Celerra (cs110_dst) as rdfadmin and switch (su) to root.

2. Start the restore of the source Celerra by typing:# /nas/sbin/nas_rdf -restore

CAUTION!For sites with redundant Control Stations, ensure that the nas_rdf -restore command is run from the primary Control Station located in slot 0 (CS0). Always ensure that CS1 is powered off at both sites before you run the -restore command. When the CS1 shutdown process completes, type /nas/sbin/getreason and check the output to verify the shutdown. The output should contain the line 0 - slot_1 powered off. Because this is a planned event, ensure that you keep CS1 powered off for the duration of the event.

CAUTION!Do not shut down or restart any Data Movers (SRDF-protected or non-SRDF Data Movers) while the nas_rdf-restore command is running. This might interrupt Celerra’s communication with the backend and cause the command to fail.

CAUTION!Proceed only after your EMC Customer Support Representative has verified that the source Symmetrix DMX system and SRDF/A link are operational.

3. At the prompt, to continue restoration and begin the device-group update phase, type yes.

Example:Is remote site cs100_src ready for Storage restoration?Do you wish to continue [yes or no]: yesContact cs100_src ... is alive


4. At the next prompt, to continue the restore process, type yes.

Example:Restore will now reboot the source side control station.Do you wish to continue? [yes or no]: yes

CAUTION!The source Symmetrix system must be operational and all volumes must be ready on the link.

Note: The system verifies that the Symmetrix devices are in proper condition to be restored at the source site. Note that the output uses “...” to indicate a continuation of the device entries, because not all device entries are listed.

Example:


Target (R2) View Source (R1) View MODES-------------------------------- ------------------------ ----- ------------ ST LI STStandard A N ALogical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF PairDevice Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE-------------------------------- -- ------------------------ ----- ------------

DEV001 034D RW 20 0 NR 034D WD 0 0 A.. Failed OverDEV002 034E RW 2048 0 NR 034E WD 0 0 A.. Failed OverDEV003 034F RW 0 0 NR 034F WD 0 0 A.. Failed OverDEV004 0350 RW 0 0 NR 0350 WD 0 0 A.. Failed OverDEV005 0351 RW 1204 0 NR 0351 WD 0 0 A.. Failed OverDEV006 0352 RW 0 0 NR 0352 WD 0 0 A.. Failed OverDEV007 035A RW 0 0 NR 035A WD 0 0 A.. Failed OverDEV008 035B RW 0 0 NR 035B WD 0 0 A.. Failed OverDEV009 035C RW 0 0 NR 035C WD 0 0 A.. Failed OverDEV010 035D RW 0 0 NR 035D WD 0 0 A.. Failed OverDEV011 035E RW 0 0 NR 035E WD 0 0 A.. Failed OverDEV012 035F RW 0 0 NR 035F WD 0 0 A.. Failed Over...DEV065 0394 RW 2 0 NR 0394 WD 0 0 A.. Failed OverDEV066 0395 RW 2 0 NR 0395 WD 0 0 A.. Failed OverDEV067 0396 RW 0 0 NR 0396 WD 0 0 A.. Failed OverDEV068 0397 RW 0 0 NR 0397 WD 0 0 A.. Failed OverDEV069 0398 RW 0 0 NR 0398 WD 0 0 A.. Failed OverDEV070 0399 RW 0 0 NR 0399 WD 0 0 A.. Failed Over

Total -------- -------- -------- -------- Track(s) 3280 0 0 0 MB(s) 102.5 0.0 0.0 0.0

Legend for MODES:

M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy D(omino) : X = Enabled, . = Disabled A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off

Step Action


Note: The update of the source Symmetrix system now begins by automatically setting the SRDF device group mode to SYNC (synchronous) for the update and failback.

Note: The file systems and shares are still available to the network clients during the update phase. Under certain conditions, volumes might not be in the proper state to fail back, in which case the restore command exits. If this occurs, "Troubleshooting SRDF/A" on page 66 can provide information about the errors that might occur. If necessary, contact your local EMC Customer Support Representative.

+++++ Setting RDF group 1R2_500_3 to SYNC mode.

An RDF 'Update R1' operation execution isin progress for device group '1R2_500_3'. Please wait...

Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 036B-037C in (0557,03).......................... Merged. Devices: 034D-0352, 035A-036A in (0557,03)............... Merged. Devices: 037D-038E in (0557,03).......................... Merged. Devices: 038F-0399 in (0557,03).......................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done.

The RDF 'Update R1' operation successfully initiated for device group '1R2_500_3'.

Note: The device-group update phase is now complete. The next step begins the device-group failback phase.

5. At the next prompt, to begin the network restoration phase, type yes.

Note: Ensure that the source CS0 is operational and on the data network.

Example:

Is remote site cs100_src ready for Network restoration?Do you wish to continue [yes or no]: yes

Note: The SRDF/A standby Data Movers are halted and the destination file systems and shares become unavailable to network clients while the Symmetrix DMX systems (source and destination) fully synchronize.

server_2 : doneserver_3 : doneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configured/dev/ndj1: clean, 11595/231360 files, 204256/461860 blocksfsck 1.26 (3-Feb-2002)Waiting for nbs clients to die ... doneWaiting for nbs clients to die ... done/net/500 /etc/auto.500 -t 0,rw,syncWaiting for 1R2_500_3 access ...done

Note: The R2 devices on the destination are set to read-only while the Symmetrix systems fully synchronize.

Step Action


Note: The failback operation now occurs.

An RDF 'Failback' operation execution is in progress for device group '1R2_500_3'.Please wait...

Write Disable device(s) on RA at target (R2)..............Done. Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 036B-037C in (0557,03).......................... Merged. Devices: 034D-0352, 035A-036A in (0557,03)............... Merged. Devices: 038F-0399 in (0557,03).......................... Merged. Devices: 037D-038E in (0557,03).......................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done. Read/Write Enable device(s) on SA at source (R1)..........Done.

The RDF 'Failback' operation successfully executed for device group '1R2_500_3'.

Waiting for 1R2_500_3 sync ....done

Note: The device-group failback phase is complete.

Step Action


6. At the prompt, set the device group to run in SRDF/A mode by typing yes.

Example:

Starting restore on remote site cs100_src ...Waiting for nbs clients to start ... doneWaiting for nbs clients to start ... done Suspend RDF link(s).......................................Done.server_2 : server_2 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_3 : server_3 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configured Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done.

If the RDF device groups were setup to operate in ASYNCHRONOUS ( SRDF/A ) mode, now would be a good time to set it back to that mode.

Would you like to set device group 1R2_500_3 to ASYNC Mode ? [yes or no]: yes

An RDF Set 'Asynchronous Mode' operation execution is in progress for device group '1R2_500_3'. Please wait...

The RDF Set 'Asynchronous Mode' operation successfully executed for device group '1R2_500_3'.

Starting Services on remote site cs100_src ...done


8. Exit rdfadmin by typing:$ exitlogout

Note: The restoration is complete.

Note

After the restore process completes, you should be able to log in to the source Celerra Network Server (cs100_src), and manage it directly from the source nasadmin account. "Troubleshooting SRDF/A" on page 66 provides information about what to do if an error occurs during the restore process, or if you encounter problems with the restored Celerra Network Server. If necessary, contact your local EMC Customer Support Representative.

Step Action


Troubleshooting SRDF/A

As part of an effort to continuously improve and enhance the performance and capabilities of its product lines, EMC periodically releases new versions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, please contact your EMC Customer Support Representative.

Where to get help

To obtain EMC support, product, and licensing information:

Product information – For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at http://Powerlink.EMC.com.

Troubleshooting – For troubleshooting information, go to Powerlink, search for Celerra Tools, and select Celerra Troubleshooting from the navigation panel on the left.

Technical support – For technical support, go to EMC Customer Service on Powerlink. After logging in to the EMC Powerlink website, go to Support > Request Support. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC Customer Support Representative for details about obtaining a valid support agreement or to answer any questions about your account.

Note: Do not request a specific support representative unless one has already been assigned to your particular system problem.

Problem Resolution Roadmap for EMC Celerra contains additional information about using Powerlink and resolving problems.

EMC E-Lab Interoperability Navigator

The EMC E-LabTM Interoperability Navigator is a searchable, web-based application that provides access to EMC interoperability support matrices. It is available at http://Powerlink.EMC.com. After logging in to Powerlink, go to Support > Interoperability and Product Lifecycle Information > E-Lab Interoperability Navigator.

Known problems and limitations

This section provides information on how to:

◆ "Retrieve information from log files" on page 67

◆ "Resolve initialization failures" on page 67

◆ "Resolve activation failures" on page 72

http://Powerlink.EMC.com




../ProblemResolutionRoadmap/index.htm




◆ "Resolve restore failures" on page 75

◆ "Resolve Data Mover failure after failover activation" on page 83

Retrieve information from log files

Normally, system messages are reported to the system log files. To retrieve information from log files:

◆ Check the system log (sys_log) by using the server_log command

◆ Check the command error log (cmd_log.err) for message information

To retrieve substantial SRDF/A logging information:

◆ Use the /nas/tools/collect_support_materials script, which collects data, such as disaster recovery information, from the following log files:

• /nas/log/dr_log.al

• /nas/log/dr_log.al.rll

• /nas/log/dr_log.al.err

• /nas/log/dr_log.al.trace*

• /nas/log/symapi.log*

These log files can also be viewed individually.

◆ To monitor these logs while the nas_rdf command is running, check the file in the /tmp directory. After the command completes, the logs appear in the /nas/log directory.

To gather more data after a failure, such as a failed restore, access the following sources:

◆ Disaster recovery (dr*) files — Provide state changes, as well as other key informational messages

◆ The symapi.log file — Logs storage-related errors

Resolve initialization failures

This section provides a sample failed initialization scenario in which two destination Data Movers (server_2 and server_3), intended to serve as SRDF/A standbys for two source production Data Movers, already have a local standby Data Mover (server_5). This results in an invalid configuration, that is, Data Movers serving as SRDF/A standbys cannot have a local standby Data Mover.

This section includes:

◆ "Example 1 for initialization failure" on page 68

◆ "Resolution for initialization failure example 1" on page 69

◆ "Example 2 for initialization failure" on page 71


Example 1 for initialization failure


[root@cs110_dst nasadmin]# /nas/sbin/nas_rdf -initDiscover local storage devices ...


Start R2 dos client ...doneStart R2 nas client ...done

Contact cs100_src ... is alive

Please create a new login account to manage RDF site cs100_src

New login: rdfadminNew password:BAD PASSWORD: it is based on a dictionary wordRetype new password:Changing password for user rdfadminpasswd: all authentication tokens updated successfullydone

Please enter the passphrase for RDF site cs100_src:

Passphrase:rdfadminRetype passphrase:rdfadminoperation in progress (not interruptible)...id = 1name = cs100_srcowner = 500device = /dev/ndj1channel = rdev=/dev/ndg, off_MB=391; wdev=/dev/nda, off_MB=391net_path = 192.168.97.140celerra_id = 000190100582034Dpassphrase = rdfadminDiscover remote storage devices ...doneThe following servers have been detected on the system (cs110_dst):id type acl slot groupID state name1 1 1000 2 0 server_22 1 1000 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5

Please enter the id(s) of the server(s) you wish to reserve(separated by spaces) or "none" for no servers.Select server(s) to use as standby: 1 2server_2 : Error 4031: server_2 : server_2 has a standby server: server_5server_3 : Error 4031: server_3 : server_3 has a standby server: server_5

operation in progress (not interruptible)...id = 1name = cs100_srcowner = 500device = /dev/ndj1channel = rdev=/dev/ndg, off_MB=391; wdev=/dev/nda, off_MB=391net_path = 192.168.97.140


Resolution for initialization failure example 1


celerra_id = 000190100582034Dpassphrase = rdfadminPlease create a rdf standby for each server listedserver server_2 in slot 2, remote standby in slot [2] (or none): noneserver server_3 in slot 3, remote standby in slot [3] (or none): noneserver server_4 in slot 4, remote standby in slot [4] (or none): noneserver server_5 in slot 5, remote standby in slot [5] (or none): none

Task Action

1. List and verify the servers by typing:# nas_server -list


2. Delete the local standby relationship by typing:# server_standby server_2 -delete mover=server_5server_2 : done

3. Delete the local standby relationship by typing:# server_standby server_3 -delete mover=server_5server_3 : done

4. Delete.....by typing:[root@cs110_dst nasadmin]# /nas/sbin/getreason


5. Delete the.....by typing:[root@cs110_dst nasadmin]# /nas/bin/nas_server -list



6. Delete.....by typing:[root@cs110_dst nasadmin]# /nas/bin/nas_server -info -all





Task Action



The following example highlights the error occurred when a file system is mounted on a local Data Mover, intended to serve as an RDF standby. The example shows new prompts for the user to change the configuration on another window before proceeding with the initialization.


[root@cs110_dst nasadmin]# /nas/sbin/nas_rdf -init Discover local storage devices ...


Please create a rdf standby for each server listedserver server_2 in slot 2, remote standby in slot [2] (or none): 2Error 3122: server_2 : filesystem is unreachable: rl64kServer server_2 has local file system mounted.Please unmount those file system in another window and try again.

Do you wish to continue? [yes or no]:********************$ nas_server -i server_2id = 1name = server_2acl = 1000, owner=nasadmin, ID=201type = nasslot = 2member_of =standby = server_3, policy=autoRDFstandby = slot=2status : defined = enabled actual = online, active$ server_mount server_2 rl64k /rl64kserver_2 : done

Warning 17716815751: server_2 :has a standby server: rdf, filesystem: rl64k is local, will not be able to failover[nasadmin@cs100_src ~]$ server_df server_2server_2 :Filesystem kbytes used avail capacity Mounted onrl64k 230393504 124697440 105696064 54% /rl64kmc1 230393504 45333944 185059560 20% /mc1mc2 460787024 327825496 132961528 71% /mc2mc1a_ckpt1 230393504 410408 229983096 0% /mc1a_ckpt1mc1a 230393504 410424 229983080 0% /mc1arl32krdf 230393504 696 230392808 0% /caddata/wdc1/32kroot_fs_common 13624 5288 8336 9% /.etc_commonroot_fs_2 231944 6152 225792 3% /


Resolve activation failures

This section provides a sample failed activation scenario in which a local file system is mounted on an SRDF-protected standby Data Mover. The error conditions are highlighted and the corrective commands are listed after the error.


◆ "Example for activation failure" on page 73

◆ "Resolution for activation failure" on page 74


Example for activation failure

Example of activation failure

[root@cs110_dst rdfadmin]# /nas/sbin/nas_rdf -activateIs remote site cs100_src completely shut down (power OFF)?Do you wish to continue? [yes or no]: yes

Successfully pinged (Remotely) Symmetrix ID: 000190100582

An RDF 'Failover' operation execution is in progress for device group '1R2_500_3'. Please wait...

Write Disable device(s) on SA at source (R1)..............Done. Suspend RDF link(s).......................................Done. Read/Write Enable device(s) on RA at target (R2)..........Done.

The RDF 'Failover' operation successfully executed fordevice group '1R2_500_3'.

Waiting for nbs clients to die ... done/net/500 /etc/auto.500 -t 1,ro/dev/ndj1: recovering journal/dev/ndj1: clean, 11587/231360 files, 204164/461860 blocksfsck 1.26 (3-Feb-2002)Waiting for nbs clients to die ... doneid type acl slot groupID state name1 1 1000 2 0 server_22 4 1000 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5

server_2 : server_2 : going offline rdf : going active replace in progress ...failed failover activity complete

replace_storage:replace_volume: volume is unreachabled141,d142,d143,d144,d145,d146,d147,d148

server_3 : server_3 : going offline rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configuredAn RDF 'Update R1' operation execution is in progress for device'DEV001' in group '1R2_500_3'. Please wait...

Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Device: 034D in (0557,03)................................ Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done.

The RDF 'Update R1' operation successfully initiated for device'DEV001' in group '1R2_500_3'.


Resolution for activation failure

Task Action

1. List and verify the servers by typing:# nas_server -list

id type acl slot groupID state name1 1 1000 2 2 server_2.faulted.rdf2 4 0 3 0 server_33 1 1000 4 0 server_44 4 1000 5 0 server_5

2. Unmount all non-SRDF (local) file systems from the Data Mover that failed to activate (in this case, server_2).

Example: [root@cs110_dst rdfadmin]# server_umount server_2.faulted.rdf -perm fs5server_2.faulted.rdf : done

3. Manually activate SRDF for the Data Mover that originally failed.

Example: [root@cs110_dst rdfadmin]# server_standby server_2.faulted.rdf -activaterdf

server_2.faulted.rdf : server_2.faulted.rdf : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedone

4. Verify the configuration using Celerra commands:[root@cs110_dst rdfadmin]# /nas/sbin/getreason


5. Delete.....by typing:[root@cs110_dst rdfadmin]# /nas/bin/nas_server -list



Resolve restore failures

This section provides sample restore failure scenarios.

Note: The source-side Control Station 0 must be operational for the restore, and Celerra services on the source site start only after the restore process successfully completes. A Waiting for Disaster Recovery to complete message appears in the /var/log/messages and the source remains in that state until the restore completes. This change, which involves use of a DR lock, ensures correct sequential operation, thereby ensuring that the source-site services come up correctly under RDF control and that no user commands run until the source site is completely restored. "Error messages" on page 86 provides more information about the associated errors.


◆ "Example 1 for restoration failure" on page 76

◆ "Resolution for restoration failure example 1" on page 79

◆ "Example 2 for restoration failure (NS series gateway)" on page 80


◆ "Example 3 for restoration failure (database lock error)" on page 81


6. Delete.....by typing:[root@cs110_dst rdfadmin]# /nas/bin/server_mount ALL

server_2 :root_fs_2 on / uxfs,perm,rwroot_fs_common on /.etc_common uxfs,perm,rofs2 on /fs2 uxfs,perm,rwfs1a on /fs1a uxfs,perm,rwfst1 on /fst1 uxfs,perm,rw


server_4 :root_fs_4 on / uxfs,perm,rwroot_fs_common on /.etc_common uxfs,perm,ro


Task Action


Example 1 for restoration failure

This example shows an active/passive restore operation started by root from rdfadmin on cs110_dst using the nas_rdf -restore command. The output shows the events leading up to the error message on the destination Celerra Network Server, followed by output from the source after taking corrective action.

Example 1 restore failure

[root@cs110_dst rdfadmin]# /nas/sbin/nas_rdf -restoreIs remote site cs100_src ready for Storage restoration?Do you wish to continue? [yes or no]: yesContact cs100_src ...Unable to contact node cs100_src at 192.168.96.58.Do you wish to continue? [yes or no]: yes


Target (R2) View Source (R1) View MODES-------------------------------- ------------------------ ----- ------------ ST LI STStandard A N ALogical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF PairDevice Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE-------------------------------- -- ------------------------ ----- ------------

DEV001 0000 RW 12 0 NR 0000 WD 0 0 A.. Failed OverDEV002 0001 RW 4096 0 NR 0001 WD 0 0 A.. Failed OverDEV003 000D RW 1 0 NR 000D WD 0 0 A.. Failed OverDEV004 000E RW 1 0 NR 000E WD 0 0 A.. Failed OverDEV005 000F RW 0 0 NR 000F WD 0 0 A.. Failed OverDEV006 0010 RW 0 0 NR 0010 WD 0 0 A.. Failed OverDEV007 0011 RW 0 0 NR 0011 WD 0 0 A.. Failed OverDEV008 0012 RW 0 0 NR 0012 WD 0 0 A.. Failed OverDEV009 0013 RW 0 0 NR 0013 WD 0 0 A.. Failed OverDEV010 0014 RW 0 0 NR 0014 WD 0 0 A.. Failed OverDEV011 0015 RW 1 0 NR 0015 WD 0 0 A.. Failed OverDEV012 0016 RW 1 0 NR 0016 WD 0 0 A.. Failed Over...DEV161 02D3 RW 0 0 NR 0253 WD 0 0 A.. Failed OverDEV162 02D7 RW 0 0 NR 0257 WD 0 0 A.. Failed OverDEV163 0003 RW 0 0 NR 0003 WD 0 0 A.. Failed OverDEV164 0004 RW 851 0 NR 0004 WD 0 0 A.. Failed OverDEV165 0005 RW 0 0 NR 0005 WD 0 0 A.. Failed Over

Total -------- -------- -------- -------- Track(s) 4965 0 0 0 MB(s) 155.2 0.0 0.0 0.0

Legend for MODES:


+++++ Setting RDF group 1R2_500_11 to SYNC mode.



An RDF 'Update R1' operation execution is in progress for device group '1R2_500_11'. Please wait...

Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 0000-0001 ...................................... Merged. Devices: 0003-0005 ...................................... Merged. Devices: 000D-0015 ...................................... Merged. Devices: 0016-001E ...................................... Merged. Devices: 001F-0027 ...................................... Merged. Devices: 0028-0030 ...................................... Merged. Devices: 0031-0039 ...................................... Merged. Devices: 003A-0042 ...................................... Merged. Devices: 0043-004B ...................................... Merged. Devices: 004C-0054 ...................................... Merged. Devices: 0055-005D ...................................... Merged. Devices: 005E-0066 ...................................... Merged. Devices: 0067-006F ...................................... Merged. Devices: 0070-0078 ...................................... Merged. Devices: 0079-0081 ...................................... Merged. Devices: 0082-008A ...................................... Merged. Devices: 008B-008C ...................................... Merged. Devices: 01DB-01E1 ...................................... Merged. Devices: 01E2-01E8 ...................................... Merged. Devices: 01E9-01EF ...................................... Merged. Devices: 01F0-01F6 ...................................... Merged. Devices: 01F7-01FD ...................................... Merged. Devices: 01FE-0204 ...................................... Merged. Devices: 0205-020B ...................................... Merged. Devices: 020C-0212 ...................................... Merged. Devices: 0213-0219 ...................................... Merged. Devices: 021A-0220 ...................................... Merged. Devices: 0221-0227 ...................................... Merged. Devices: 0228-022E ...................................... Merged. Devices: 022F-0235 ...................................... Merged. Devices: 0236-023C ...................................... Merged. Devices: 023D-0243 ...................................... Merged. Devices: 0244-024A ...................................... Merged. Devices: 024B-0251 ...................................... Merged. Devices: 0252-0258 ...................................... Merged. Devices: 0259-025A ...................................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Done.


Is remote site cs100_src ready for Network restoration?Do you wish to continue? [yes or no]: yesserver_2 : doneserver_3 : doneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configured/dev/sdj1: clean, 11464/231360 files, 164742/461860 blocksfsck 1.26 (3-Feb-2002)/net/500 /etc/auto.500 -t 0,rw,syncWaiting for 1R2_500_11 access ...done



An RDF 'Failback' operation execution is in progress for device group '1R2_500_11'. Please wait...

Write Disable device(s) on RA at target (R2)..............Done. Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 0000-0001 ...................................... Merged. Devices: 0003-0005 ...................................... Merged. Devices: 000D-0015 ...................................... Merged. Devices: 0016-001E ...................................... Merged. Devices: 001F-0027 ...................................... Merged. Devices: 0028-0030 ...................................... Merged. Devices: 0031-0039 ...................................... Merged. Devices: 003A-0042 ...................................... Merged. Devices: 0043-004B ...................................... Merged. Devices: 004C-0054 ...................................... Merged. Devices: 0055-005D ...................................... Merged. Devices: 005E-0066 ...................................... Merged. Devices: 0067-006F ...................................... Merged. Devices: 0070-0078 ...................................... Merged. Devices: 0079-0081 ...................................... Merged. Devices: 0082-008A ...................................... Merged. Devices: 008B-008C ...................................... Merged. Devices: 01DB-01E1 ...................................... Merged. Devices: 01E2-01E8 ...................................... Merged. Devices: 01E9-01EF ...................................... Merged. Devices: 01F0-01F6 ...................................... Merged. Devices: 01F7-01FD ...................................... Merged. Devices: 01FE-0204 ...................................... Merged. Devices: 0205-020B ...................................... Merged. Devices: 020C-0212 ...................................... Merged. Devices: 0213-0219 ...................................... Merged. Devices: 021A-0220 ...................................... Merged. Devices: 0221-0227 ...................................... Merged. Devices: 0228-022E ...................................... Merged. Devices: 022F-0235 ...................................... Merged. Devices: 0236-023C ...................................... Merged. Devices: 023D-0243 ...................................... Merged. Devices: 0244-024A ...................................... Merged. Devices: 024B-0251 ...................................... Merged. Devices: 0252-0258 ...................................... Merged. Devices: 0259-025A ...................................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Done. Read/Write Enable device(s) on SA at source (R1)..........Done.


Waiting for 1R2_500_11 sync ...done

Starting restore on remote site cs100_src ...failed----------------------------------------------------------------Please execute /nasmcd/sbin/nas_rdf -restore on remote site cs100_src----------------------------------------------------------------[root@cs100_src rdfadmin]#

Note: The failure (highlighted) occurs after the failback operation is executed for the device group, when the restore is set to begin on the source Celerra.


Resolution for restoration failure example 1

Task Action

1. Delete.....by typing:[root@cs100_src nasadmin]# /nasmcd/sbin/nas_rdf -restore

server_2 : rdf : reboot in progress ............ server_2 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_3 : rdf : reboot in progress ............ server_3 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_4 :Error 4003: server_4 : standby is not configuredserver_5 :Error 4003: server_5 : standby is not configured


Would you like to set device group 1R1_11 to ASYNC Mode ? [yes or no]: yes

An RDF Set 'Asynchronous Mode' operation execution is in progress for device group '1R1_11'. Please wait...

The RDF Set 'Asynchronous Mode' operation successfully executed for device group '1R1_11'.


Would you like to set device group 1R1_12 to ASYNC Mode ? [yes or no]: no

Starting Services ...done[root@cs100_src nasadmin]#

2. Exit as root. This concludes the device-group failback phase.

3. Log in to and manage the source Celerra Network Server directly from the nasadmin account on the source Celerra Network Server (cs100_src). If the restoration is still unsuccessful, gather SRDF/A logging information using the script /nas/tools/collect_support_materials.


Example 2 for restoration failure (NS series gateway)

The following example on a NS600G or NS700G shows a failed restore operation at the destination.



[root@Celerra2 nasadmin]# /nas/sbin/nas_rdf –restore ...Starting restore on remote site Celerra1 ...Waiting for nbs clients to start ... WARNING: Timed outWaiting for nbs clients to start ... doneCRITICAL FAULT:Unable to mount /nas/dosStarting Services on remote site Celerra1 ...done

Note: “...” indicates not all lines of the restore output are shown.

Task Action

1. Stop the services at the source as root by typing:[root@Celerra1 nasadmin]# /sbin/service nas stop

2. Perform a restore at the source as root by typing:[root@Celerra1 nasadmin]# /nasmcd/sbin/nas_rdf –restore...

Waiting for nbs clients to start ... doneWaiting for nbs clients to start ... doneSuspend RDF link(s).......................................Done.server_2 :replace in progress ...donecommit in progress (not interruptible)...donedoneserver_3 :Error 4003: server_3 : standby is not configuredResume RDFlink(s)........................................Done.Starting Services ...done


Example 3 for restoration failure (database lock error)

The following example shows a restore error that occurs when a server fails to acquire the database lock. The restore completes with the error, but resolving the error involves running the server_standby command at the source for the server involved in the lock contention. The error is highlighted.

Example 3 restore error

[root@cs0_dst rdfadmin]# /nas/sbin/nas_rdf –restore

Is remote site cs100_src ready for Storage restoration?Do you wish to continue? [yes or no]: yesContact cs0_src ... is alive

Target (R2) View Source (R1) View MODES -------------------------------- ------------------------ ----- --------- ST LI ST Standard A N A Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair

Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE -------------------------------- -- ------------------------ ----- -------

DEV001 08F2 RW 1 0 RW 37CD WD 0 0 C.D R1 Updated DEV002 08F3 RW 58 0 RW 37CE WD 0 0 C.D R1 Updated DEV003 08FA RW 0 0 RW 37D3 WD 0 0 C.D R1 Updated DEV004 08FB RW 0 0 RW 37D4 WD 0 0 C.D R1 Updated DEV005 08FC RW 12 0 RW 37D5 WD 0 0 C.D R1 Updated DEV006 08FD RW 0 0 RW 37D6 WD 0 0 C.D R1 Updated DEV007 092C RW 3546 0 RW 0629 WD 0 0 C.D R1 Updated DEV008 0930 RW 2562 0 RW 062D WD 0 0 C.D R1 Updated DEV009 06F5 RW 0 0 RW 0631 WD 0 0 C.D R1 Updated Total -------- -------- -------- -------- Track(s) 6179 0 0 0 MB(s) 193.1 0.0 0.0 0.0

Legend for MODES:


An RDF 'Update R1' operation execution is in progress for device group '1R2_500_4'. Please wait...

Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 37CD-37CE ...................................... Merged. Devices: 37D3-37D6 ...................................... Merged. Devices: 0629-0634 ...................................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done.




Is remote site cs0_src ready for Network restoration?Do you wish to continue? [yes or no]: yesserver_2 : doneserver_3 : doneserver_4 : Error 4003: server_4 : standby is not configuredserver_5 : Error 4003: server_5 : standby is not configured/dev/ndj1: clean, 10308/231360 files, 175874/461860 blocksfsck 1.26 (3-Feb-2002)Waiting for nbs clients to die ... done Waiting for nbs clients to die ... done /net/500 /etc/auto.500 -t 0,rw,syncWaiting for 1R2_500_4 access ...done

An RDF 'Failback' operation execution isin progress for device group '1R2_500_4'. Please wait...

Write Disable device(s) on RA at target (R2)..............Done. Suspend RDF link(s).......................................Done. Merge device track tables between source and target.......Started. Devices: 37CD-37CE ...................................... Merged. Devices: 37D3-37D6 ...................................... Merged. Devices: 0629-0634 ...................................... Merged. Merge device track tables between source and target.......Done. Resume RDF link(s)........................................Started. Resume RDF link(s)........................................Done. Read/Write Enable device(s) on SA at source (R1)..........Done.


Waiting for 1R2_500_4 sync ...done

Starting restore on remote site cs0_src ...Waiting for nbs clients to start ... done Waiting for nbs clients to start ... done server_2 : Error 2201: server_2 : unable to acquire lock(s), try laterserver_3 : server_3 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedoneserver_4 : Error 4003: server_4 : standby is not configuredserver_5 : Error 4003: server_5 : standby is not configured



Resolve Data Mover failure after failover activation

If a Data Mover develops hardware issues after activate, you can replace the affected Data Mover and update the hardware information. To update the hardware information, you must run the setup_slot command first as nasadmin switching (su) to root and then as rdfadmin switching (su) to root.


If the RDF device groups were setup to operate in ASYNCHRONOUS ( SRDF/A ) mode,now would be a good time to set it back to that mode.

Would you like to set device group 1R2_500_4 to ASYNC Mode ? [yes or no]: yes

Starting Services on remote site cs0_src ...[root@cs0_dst rdfadmin]# exit[rdfadmin@cs0_dst rdfadmin]$ exit[nasadmin@cs0_dst nasadmin]$ exit

Action

Run the server_standby command on the source Celerra for the server that had the lock contention (in this example, server_2).

Example:

[nasadmin@cs0_src nasadmin]$ server_standby server_2 -restore rdf

server_2 : server_2 : going standby rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...donedone

Output

server_2 : Nil

Step Action

1. Log in to the destination Celerra (cs110_dst) as nasadmin and switch (su) to root.


2. Initialize the Data Mover by using this command syntax:[root@cs110_dst nasadmin]# /nas/sbin/setup_slot -init <x>

where:<x> = Slot number of the new Data MoverExample:

To initialize the Data Mover for slot 2, type:[root@cs110_dst nasadmin]# /nas/sbin/setup_slot -init 2

Initializing server in slot 2 as server_2 ...

Starting PXE service...:doneReboot server in slot 2, waiting..... 0 0 0 0 0 0 1 1 1 3 3 3 3 3 3 3 4 (154 secs)Stopping PXE service...:donePing server in slot 2 on primary interface ...okPing server in slot 2 on backup interface ...okDiscover disks attached to server in slot 2 ...

Discovering storage (may take several minutes)server_2 : doneserver_2 : doneserver_2 : doneserver_2 : doneSynchronize date+time on server in slot 2 ...server_2 : Mon Aug 17 12:11:05 EDT 2009server_2 : Processor = Intel Pentium 4 Processor speed (MHz) = 2800 Total main memory (MB) = 4093 Mother board = CMB-Sledgehammer Bus speed (MHz) = 800 Bios Version = 03.80 Post Version = Rev. 01.59server_2 : reboot in progress 0.0.0.0.0.0.0.0.1.1.3.3.3.3.3.4.doneChecking to make sure slot 2 is ready........ 5 5 (63 secs)

Completed setup of server in slot 2 as server_2This Data Mover (also referred to as Blade) is a MirrorView or RDF standby Data Mover, log in to the system as rdfadmin and switch (su) to root, and, regardless of straight (for example, server 2 to server 2) or criss-cross (for example, server 2 to server 3) configuration, use the CLI command with the same slot id:/nas/sbin/setup_slot -i 2[root@cs110_dst nasadmin]#

3. Exit root by typing:[root@cs110_dst nasadmin]# exit

exit

4. Exit nasadmin by typing:[nasadmin@cs110_dst ~]$ exit

logout

5. Log in to the destination Celerra (cs110_dst) as rdfadmin and switch (su) to root.

Step Action


Handle additional error situations

If you shut down or restart any Data Movers (SRDF-protected or non-SRDF Data Movers) at the destination while the /nas/sbin/nas_rdf -activate or the nas/sbin/nas_rdf -restore command is running, the Control Station does not find a path to the backend. With Celerra’s communication to the backend interrupted, the command fails. Respond by doing the following:

1. Rerun the /nas/sbin/nas_rdf -activate or the /nas/sbin/nas_rdf -restore command after the Data Mover is operational.

2. Do not shut down or restart any Data Movers at the destination while these commands are running.

6. Initialize the Data Mover by using this command syntax:[root@cs110_dst rdfadmin]# /nas/sbin/setup_slot -init <x>

where:<x> = Slot number of the new Data Mover

Example:

To initialize the Data Mover for slot 2, type:[root@cs110_dst rdfadmin]# /nas/sbin/setup_slot -init 2The script will update only hardware related configuration such as the MAC addresses for the internal network and then reboot the Data Mover (also referred to as Blade).server_2 : reboot in progress 0.0.0.0.0.0.0.0.1.1.3.3.3.3.3.4.doneChecking to make sure slot 2 is ready........ 5 5 (64 secs)

Completed setup of server in slot 2 as server_2[root@cs110_dst rdfadmin]#

!CAUTION!Ensure that you run the setup_slot command first as nasadmin switching (su) to root and then as rdfadmin switching (su) to root.

If you run the command as rdfadmin before running it as nasadmin, you will get the following error message:

setup_slot has not been run as nasadmin before running it as rdfadmin user on this Data Mover (also referred to as Blade) The script will exit without changing the state of the system or rebooting it. Please do the following to set up this Data Mover correctly:1. Initialize the new Data Mover for the nasadmin database by logging in to the system as nasadmin, switching (su) to root,and using the CLI command:/nas/sbin/setup_slot -init 22. Initialize the new Data Mover for the rdfadmin database by logging in to the system as rdfadmin user, switching (su) to root, and using the CLI command:/nas/sbin/setup_slot -init 2

7. Exit root by typing:[root@cs110_dst rdfadmin]# exit

exit

8. Exit rdfadmin by typing:[rdfadmin@cs110_dst ~]$ exit

logout

Step Action


Error messages

As of version 5.6, all new event, alert, and status messages provide detailed information and recommended actions to help you troubleshoot the situation.

To view message details, use any of the these methods:

◆ Celerra Manager:

• Right-click an event, alert, or status message and select to view Event Details, Alert Details, or Status Details.

◆ Celerra CLI:

• Type nas_message -info <MessageID>, where MessageID is the message identification number.

◆ EMC Celerra Network Server Error Messages Guide:

• Use this guide to locate information about messages that are in the earlier-release message format.

◆ Powerlink:

• Use the text from the error message’s brief description or the message’s ID to search the Knowledgebase on Powerlink. After logging in to Powerlink, go to Support > Knowledgebase Search > Support Solutions Search.

Training and Professional Services

EMC Customer Education courses help you learn how EMC storage products work together within your environment in order to maximize your entire infrastructure investment. EMC Customer Education features online and hands-on training in state-of-the-art labs conveniently located throughout the world. EMC customer training courses are developed and delivered by EMC experts. Go to EMC Powerlink at http://Powerlink.EMC.com for course and registration information.

EMC Professional Services can help you implement your Celerra Network Server efficiently. Consultants evaluate your business, IT processes, and technology and recommend ways you can leverage your information for the most benefit. From business plan to implementation, you get the experience and expertise you need, without straining your IT staff or hiring and training new personnel. Contact your EMC representative for more information.





Appendix: Portfolio of high-availability options

This section illustrates the Celerra Network Server SRDF high-availability configuration options. Figure 4 on page 87 shows a configuration featuring active/passive SRDF in either asynchronous mode (SRDF/A) or synchronous mode (SRDF/S).

Figure 5 on page 88, Figure 6 on page 88, Figure 7 on page 89, Figure 8 on page 89, Figure 9 on page 90, and Figure 10 on page 91 show disaster recovery and business continuance configurations featuring SRDF/S only, SRDF links, or both, with TimeFinder/FS NearCopy, TimeFinder/FS FarCopy, or both, with adaptive copy mode (adaptive copy disk or write-pending mode).

Note: Prior to the introduction of SRDF/A, adaptive copy mode was referred to as asynchronous mode SRDF.

For more information on the configuration that best fits your business needs, contact the local EMC sales organization.

Figure 4 Celerra replication and recovery with active/passive synchronous SRDF (SRDF/S) or asynchronous SRDF (SRDF/A)


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15

Celerra

Celerra

Symmetrix

Symmetrix

DR mirror ofPFS

Production site

DR recovery site

SRDF

SRDF

SRDF

SRDF

Celerra DR oversynchronous SRDF

CNS-000704

Dedicated SRDF links(synchronous or

asynchronous mode)PFS

CelerraR1 datavolumes



Figure 5 Celerra disaster recovery active/passive SRDF/S only with TimeFinder/FS NearCopy

Figure 6 Celerra disaster recovery active/active’ SRDF/S only

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1S

B0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15



DR mirror ofPFS

SRDF


PFS

Celerra

Celerra

Symmetrix

Symmetrix

Production site

DR recovery +business

continuance site

SRDF

SRDF

SRDF

CNS-000705

Celerralocal BCVvolumes

NearCopysnapshot of

PFS

Dedicated SRDF links(synchronous mode only)


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15






PFS

PFS

DR mirror ofPFS

DR mirror ofPFS

CNS-000706

Dedicated SRDF links(synchronous mode only)

Celerra

Celerra

Symmetrix

Symmetrix

Production + DRRecovery site

Production + DRrecovery site

SRDF

SRDF

SRDF

SRDF


Figure 7 Celerra business continuance with TimeFinder/FS FarCopy (version 5.1)

Figure 8 Celerra business continuance with TimeFinder/FS FarCopy (version 5.3)


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15

CelerraR1 BCVvolumes


BCV snapshotof PFS

PFS

Celerra

Celerra

Symmetrix

Symmetrix

Imported FS

Production site

Businesscontinuancerecovery site

SRDF

SRDF

SRDF

SRDF

Adaptivecopy

CNS-000707

Celerralocal STDvolumes


FarCopy snapshotof PFS

Dedicated SRDF links(adaptive copy

write-pending mode)


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


write-pending mode)BCV snapshotof PFS

PFS

Celerra

Celerra

Symmetrix

Symmetrix

Imported FS

Production site


SRDF

SRDF

SRDF

SRDF

Adaptive copy

CNS-000708

FarCopy snapshotof PFS

BCV snapshot ofPFS

IP WAN

Control Station IP

Control Station IP






Figure 9 Celerra business continuance with redundant FarCopy sites


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15

CelerraSymmetrix Businesscontinuance

recovery site 1

Businesscontinuance

recoverysite 2

IP WAN

Control Station IP

ControlStation IP



write-pending mode)

FarCopysnapshot of

PFS

CelerraSymmetrix

Imported FS

Imported FS

SRDF

SRDF

SRDF

SRDF

SRDFSRDF


FarCopysnapshot of

PFS

ControlStation IP

Production site

CelerraR2 BCVvolumesCelerraSymmetrix

PFS

CNS-000709


BCV snapshot ofPFS

BCV snapshot ofPFS

Celerra FarCopy overadaptive copy






Figure 10 Celerra business continuance using TimeFinder/FS FarCopy with many sites


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15


SB

0

SB

1

SB

2

SB

3

SB

4

SB

5

SB

6

SB

7

SB

8

SB

9

SB

10

SB

11

SB

12

SB

13

SB

14

SB

15




PFS

PFS

Imported FS

Celerra

Celerra

Symmetrix

CelerraSymmetrix

Symmetrix

Imported FS

Production site 1

Production site 2


SRDF(adaptive copy

write-pending mode)

SRDF(adaptive copy

write-pending mode)

CNS-000710





FarCopysnapshot of

PFS

FarCopysnapshot of

PFS

IP WANControl Station IP

Control Station IP

Control Station IP


BCV snapshot ofPFS

BCV snapshot ofPFS




Index

Aactivating SRDF/A failover 27, 47, 49active/passive

configuration 11, 34definition 6failover, activating 49initializing 14, 34restoring 60SRDF/A use of 14

adaptive copy write-pending mode 6

Bbusiness continuance configurations 17

Ccapture cycle 14cautions 42, 47, 51, 60, 61Celerra FileMover 6, 7Celerra Manager 4CIFS (Common Internet File System) 7CLI 4CNS-14 configuration 6, 22command

nas_rdf -activate 51nas_rdf -init 37SYMCLI 4

commandsfs_copy restriction 18nas_rdf 30, 31

comparison of related Celerra features 17configuring

active/passive 14, 34Data Movers 21

Control Stationcommunication 11preinitialization 31, 32

Control Station communication 11control volumes 12CS0 requirement 4cycle time 15cycles of SRDF/A 14

DData Movers

checklist for 22configuring 21destination configuration 42halting before activating destination 51mirroring 21source configuration 38

delta setdefinition 7description 14

dependent write consistency

definition 7description 14

destination Celerra 28destination Celerra Network Server 7, 49

activating 51initializing 41running restore operation on 61

device groupslisting 45querying 50, 57

differences between NS series gateway and CNS-14 6, 22differences between SRDF/A and SRDF/S 16

Eediting the /etc/hosts file 43error messages

database lock error 81local file system on SRDF Data Mover 72local standby for SRDF standbys 67restore on NS series gateway 80starting restore...failed 78

Ffailover 4

initiating active/passive 27, 47, 49initiating SRDF/A 27restoring Celerra after a 28, 60

FileMover 6, 7fs_copy command, no support for 18

Ggraceful failover 48

Hhalting Data Movers 24, 48, 51health check 25, 29high-availability and replication products

Celerra Replicator (V2) 18Celerra Replicator for iSCSI 19MirrorView/Synchronous 17restrictions 17SnapSure 19SRDF/Asynchronous 18SRDF/Synchronous 18storage platform 17TimeFinder/FS 18TimeFinder/FS NearCopy and FarCopy 18

HTTP communication 41

Iinitializing

active/passive 14, 34active/passive failover 27, 47SRDF relationship 26, 30, 31

IP data network 11IP subnets 59iSCSI LUNs, support for mirroring of 23

94 of 96 Using SRDF/A with CelerraVersion 5.6.48

Llicense 4limits

nas_cel passphrase 31Linux 4local mirror 7logical volumes 12login account 41LUNs

support for iSCSI 23

Mmapping Symmetrix volumes 12metavolume 7mirroring Data Movers 21mirrors, local and remote 7MirrorView/S 7MPFS 6, 7

Nnas_rdf -activate 27nas_rdf -init 26, 30, 31nas_rdf -restore 28NS series gateway configuration 6

Data Movers 22error messages 80

Ppassphrase 41

for nas_cel preinitialization 31physical volumes 12postactivation script 59preinitializing MirrorView/S relationship 31production file system (PFS) 8

RR1 and R2 volumes 8receive cycle 15remote mirror 8Replicator 5restore cycle 15restoring

active/passive 60Celerra post-failover 28steps on destination 61

SSnapSure 8, 23SnapSure, restriction 5solid state disk 6source Celerra Network Server 8

initializing 37restoring 61

SRDF 8asynchronous mode (SRDF/A) 8configuration types 11definitions 8

synchronous mode (SRDF/S) 8SRDF/A

comparison to SRDF/S 16overview 14

starting restore...failed message 78Symmetrix DMX systems 4Symmetrix system configuration 12Symmetrix volume IDs 12synchronous mode (SRDF/S) 16

TTimeFinder/FS 8transmit cycle 14

Uupgrade options 24user interface 6

Vverifying

initialization 44operation after activation 53

volumesconfiguring 21R1 and R2 8


Notes

About this document

As part of its effort to continuously improve and enhance the performance and capabilities of the Celerra Network Server product line, EMC periodically releases new versions of Celerra hardware and software. Therefore, some functions described in this document may not be supported by all versions of Celerra software or hardware presently in use. For the most up-to-date information on product features, see your product release notes. If your Celerra system does not offer a function described in this document, contact your EMC Customer Support Representative for a hardware upgrade or software update.

Comments and suggestions about documentation

Your suggestions will help us improve the accuracy, organization, and overall quality of the user documentation. Send a message to [email protected] with your opinions of this document.

Copyright © 1998-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.

Version 5.6.48 96 of 96

Using SRDF/A with Celerra - china.emc.com · Extension and EMC TimeFinder/FS, NearCopy, and...

Documents

Transcript of Using SRDF/A with Celerra - china.emc.com · Extension and EMC TimeFinder/FS, NearCopy, and...