EMC VNX Series - Dell EMC Korea · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 EMC® VNX™ Series Release 7.1 Using MirrorView

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-9103

1-508-435-1000www.EMC.com

EMC® VNX™ SeriesRelease 7.1

Using MirrorView™ Synchronous with VNX™ for Filefor Disaster Recovery

P/N 300-013-442 REV 01

Using MirrorView™ Synchronous with VNX™ for File forDisaster Recovery

2 of 146 Release 7.1

3 of 146Release 7.1Using MirrorView™ Synchronous with VNX™ for File for Disaster Recovery

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6User interface choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Related information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16MirrorView/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17MirrorView/S Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Comparison of VNX high-availability and replication products . . . .23Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Task overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Configure MirrorView/S (active/passive) . . . . . . . . . . . . . . . . . . . . . . . . . .40Preinitialize the configuration (active/passive) . . . . . . . . . . . . . . . . .40Initialize the configuration (active/passive) . . . . . . . . . . . . . . . . . . . .43Activate a failover (active/passive) . . . . . . . . . . . . . . . . . . . . . . . . . . .55Restore the source VNX for file (active/passive) . . . . . . . . . . . . . . . .65

Configure MirrorView/S (active/active’) . . . . . . . . . . . . . . . . . . . . . . . . . . .71Initialize the configuration (active/active’) . . . . . . . . . . . . . . . . . . . . .71Activate a failover (active/active') . . . . . . . . . . . . . . . . . . . . . . . . . . . .87Restore the source VNX for file (active/active’) . . . . . . . . . . . . . . . . .92

Managing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97Check cabinet-level MirrorView/S information. . . . . . . . . . . . . . . . . .97List device group information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99Get detailed device group information . . . . . . . . . . . . . . . . . . . . . . .100Suspend device group operations . . . . . . . . . . . . . . . . . . . . . . . . . .104Resume device group operations . . . . . . . . . . . . . . . . . . . . . . . . . . .105Ensure Data Mover eligibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106Change the Data Mover configuration . . . . . . . . . . . . . . . . . . . . . . .112Modify VNX for block security information after a failover. . . . . . .114Change file system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .115

Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118Where to get help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118EMC E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . .118Known problems and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . .118Error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138EMC Training and Professional Services . . . . . . . . . . . . . . . . . . . . .138

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141



Introduction

EMC® MirrorView™/Synchronous (MirrorView/S) is a limited-distance synchronous data mirroring facility that provides high-availability and disaster recovery for the CX Series, NS series, VNX™ series, and NS and VNX gateways. MirrorView/S maintains a synchronized remote mirror of production data between source and destination VNX system pairs at separate locations.

"Concepts" on page 16 provides more details.

This document describes how to use MirrorView/S with VNX for file version 7.0.

This document is part of the VNX documentation set and is intended for VNX for file administrators familiar with installing and managing high-availability storage configurations. The document also identifies administrative tasks, such as:

◆ Initial VNX for block storage system setup performed by your local EMC Service Provider.

◆ Initial VNX for file MirrorView/S setup and verification, including preinitialization, initialization, test failover, and test restore performed by your local EMC Service Provider.

◆ Troubleshooting procedures, including resolution or potentially complex change to the VNX for block systems performed by your local EMC Service Provider or EMC Customer Service.

System requirements

Table 1 on page 5 describes the VNX software, hardware, network, and storage configurations.


Table 1 System requirements (page 1 of 2)

Software

• VNX for block Operating Environment version 19 or later on the source and destination VNX series storage arrays, which must also have EMC Navisphere® Manager, MirrorView/S, and EMC Access Logix™ installed and enabled. VNX for block Operating Environment version 19 or later, on the source and destination, supports MirrorView consistency groups for VNX for file and VNX for block. VNX for file with MirrorView/S replicates at the VNX for file cabinet level. This includes system volumes and user file system volumes.The VNX for block remote mirrors and the consistency group must be set up by your local EMC Service Provider, as SAN administrator, through EMC Unisphere™ software or NaviCLI.

All storage arrays participating in the mirroring must be in the same domain so they can be managed through a single control console.

• The same VNX major version on both the source and destination Control Stations.

Hardware

• For VNX for block, minimum of two storage arrays, one at each site. Each VNX series storage array (VNX5100, VNX5300, VNX5500, VNX5700, and VNX7500) and CX series storage array (CX400, CX500, CX600, CX700, CX3-40, or CX3-80) requires a SAN personality card Fibre Channel (FC) connection to the remotely located VNX for block.

• MirrorView FC/IP link between the storage processors on the storage arrays (SPA-SPA and SPB-SPB). The MirrorView link is usually on the highest-numbered port (for CX700/600 and CX3-80, port 3; for CX500/400 and CX3-40, port 1). This port should not be shared with host I/O. For the VNX Series, the lowest numbered port (port 0) must be reserved for MirrorView during the installation of the Operating Environment. "MirrorView/S configuration through SP ports" on page 34 provides more information about these ports.

• For VNX for file, one consistency group with three LUNs as VNX Control LUNs and the remaining LUNs available as user data LUNs. Table 2 on page 6 provides more information about various LUN configurations.

Note: This requirement is array-based. All mirrors in a device group must be in the same array.

• For NS series gateway-NS gateway, NSX-NSX, or NS series gateway-NSX at the source and destination sites.MirrorView/S is supported on the FC-enabled integrated systems, NS series gateway and NSX series only, not the CNS cabinets or the pure integrated NS series, which do not have an available FC port. Use compatible models at both source and destination. Procedures might vary according to platform. The VNX systems require the appropriate production and standby Data Movers to support the MirrorView/S configuration.

Note: If you have multiple VNX for block storage systems, only the one device group on the boot VNX for block is available for failover to the remote site.

• For MirrorView/S, VNX for block source LUN and equivalent destination LUNs must be the same size, be owned by the same storage processor, and have the same RAID type and configuration. For example, both 4+1 RAID 5. MirrorView/S supports RAID 6.

Note: The EMC E-LabTM Interoperability Navigator provides the full set of VNX for block gateway configuration guidelines.



Restrictions

◆ In a MirrorView/S environment, you cannot cascade more than one VNX for file. A MirrorView/S configuration consists of an NS or NSX series gateway server with attached VNX for block storage system at one site and another VNX for file with attached VNX for block storage system at the other site. Dedicated MirrorView/S FC/IP links are established between the storage processors (SPs) of the source and destination VNX for block storage arrays (SPA-SPA and SPB-SPB). If the source SPB fails, then mirroring continues between the source and destination SPA.

◆ MirrorView/S is geared for new installations. However, existing configurations can be upgraded if the LUN requirements can be accommodated by various LUN configurations. Configuration is limited to 5, 13, 29, or 61 user data LUNs and 3 control data LUNs depending on the VNX for block backend. Table 2 on page 6 lists the various user data LUN configurations.

Network

• IP data network for the Control Station of the source VNX for file and the Control Station of the destination VNX for file to communicate with the storage arrays at each site.

• LAN or WAN links for communication between the Control Stations.• Dedicated FC links for connecting the storage arrays.

Note: Both storage arrays must be in the same management domain and therefore must be able to communicate over the IP network.

Storage Two attached VNX for file/VNX for block pairs.

Table 2 User LUN configuration details

Storage system User data LUNs

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

CX600/CX700/CX3-80/CX3-40

13 user data LUNs

CX4-120 13 user data LUNs

CX4-120

(/w version 5.6.47 or later)

29 user data LUNs

CX4-480/CX4-960 29 user data LUNs

VNX5100/VNX5300/VNX5500

(/w version 7.0

29 user data LUNs

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

61 user data LUNs

VNX5700/VNX7500

/w version 7.0

61 user data LUNs

Table 1 System requirements (page 2 of 2)


"Upgrade your VNX environment" on page 26 provides more information about upgrading existing configurations.

◆ LUN limits are based on VNX for block LUNs as per consistency group limitations. VNX for file requires three LUNs for system data. Special considerations must be made for the setup of the backend array configuration by configuring large LUN sizes (up to 2 TB) in systems with versions 5.5 through 5.6.43. In version 5.6.44, VNX for file backend array configurations support up to 16 TB LUNs.

◆ MirrorView/S integration with VNX for file does not support virtually provisioned VNX for block thin LUNs.

◆ MirrorView/S is different from EMC Symmetrix® Remote Data Facility (EMC SRDF®). With MirrorView/S, VNX for file does not see the mirrored LUNs at the destination site until a failover is activated. However with SRDF, the remote mirrors (R2 volumes) of the Control Station LUNs are visible to the Data Movers. With MirrorView/S, there is no access to the destination LUNs until a failover is activated. Therefore, the destination side of a MirrorView/S configuration cannot be used for tape backup or loadsharing prior to a failover activation. "Comparison of VNX high-availability and replication products" on page 23 provides a basic comparison of MirrorView/S and SRDF.

Note: MirrorView configurations are not suitable for backups from the destination.

◆ With MirrorView/S, in a link or device failure scenario, LUN sets always fracture as a group so that their destination images are maintained in a consistent, logically recoverable state. Source-site failures other than a single source storage processor failure, such as a source image LUN failure or source-site VNX for block failure, warrant a forced failover activation. "Troubleshooting" on page 118 provides more information.

◆ During the MirrorView/S restore, the storage restoration phase of the process waits until both sides are 100-percent synchronized to ensure that the source VNX for file gets the latest data. The length of the synchronization is based on the amount of data that has been updated since the destination system was activated. After that, the destination VNX for file fails back the Data Movers, and the restore process stops client access, fails back the storage system, and then restores the source VNX for file. For MirrorView/S configuration, the local file systems and MirrorView-protected file systems have their own, dedicated Data Movers. To avoid failover problems, Data Movers that are MirrorView-protected must contain only file systems that are intended to be protected by MirrorView/S, not local file systems. Also, make sure that the file systems do not span multiple storage systems.

◆ All Data Movers must use their default names, for example, server_2, server_3, and so on, when you configure them for MirrorView/S. If you change the default Data Mover names, it may cause MirrorView/S activation to stop responding when you add the NBS devices to the Operating Environment.



Initial setup

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

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

• NS-NS series gateway

• NSX-NSX

• NS series gateway-NSX

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

◆ MirrorView/S does not support CNS and CFS storage platforms. "MirrorView/S configuration through SP ports" on page 34 provides more information on SP port configurations.

◆ For gateway configurations, only single back-end VNX for block configurations are allowed.

◆ MirrorView/S cannot be used in mixed VNX for block and Symmetrix storage system configurations.

◆ The VNX for block source LUN and equivalent destination LUNs must have the same RAID type and configuration. For example, 4+1 RAID 5 on source and destination LUNs. Consult the EMC E-Lab Interoperability Navigator available on the EMC Online Support website for the complete set of VNX for block gateway configuration guidelines.

Note: "System requirements" on page 4 identifies the MirrorView/S with VNX for file basic hardware and software requirements. The MirrorView family documentation available on the EMC Online Support website provides information about the VNX for block MirrorView products.

Disk types and storage pools

◆ MirrorView/S requires:

• CMSTD — Represents mirrored CLSTD as the standard VNX for block disk volumes for use with MirrorView/S.

• CMATA — Represents mirrored CLATA as the VNX for block Advanced Technology-Attached (ATA) disk volumes for use with MirrorView/S.

◆ MirrorView/S uses the following system-defined Automatic Volume Management (AVM) storage pools:

http://support.emc.com



• cm_r1 — Designed for high performance and availability at low cost. This storage pool uses VNX for block CMSTD disk volumes created from RAID 1 mirrored-pair disk groups.

• cm_r5_performance — Designed for medium performance and availability at low cost. This storage pool uses VNX for block CMSTD disk volumes created from 4+1 RAID 5 disk groups.

• cm_r5_economy — Designed for medium performance and availability at lowest cost. This storage pool uses VNX for block CMSTD disk volumes created from 8+1 RAID 5 disk groups.

• cmata_archive — Designed for use with infrequently accessed data, such as archive retrieval. This storage pool uses VNX for block ATA CMATA disk drives in a RAID 5 configuration.

• cmata_r3 — Designed for archival performance and availability at lowest cost. This AVM storage pool uses VNX for block ATA CMATA disk drives in a RAID 3 configuration.

◆ You can view the MirrorView/S disk types and view or manipulate AVM storage pools by using the Unisphere software. Also, note that mirrored devices are converted automatically from CLSTD to CMSTD during the MirrorView/S initialization process.

Note: Disks in a storage pool must be all mirrored or all unmirrored. The /nas/sbin/nas_mview -init command fails if a mix of disk types is created by changing the storage system configuration.

Note: Managing Volumes and File Systems with VNX Automatic Volume Management describes how to manage volumes and file systems. Managing Volumes and File Systems for VNX Manually describes how to manage volumes and file systems.

Management interface and Control Station restrictions

◆ After initial setup, which involves steps performed by your local EMC Service Provider to establish the VNX for block storage system configuration, you should manage MirrorView/S disaster recovery only through the VNX CLI by using commands, such as /nas/sbin/nas_mview in the VNX environment from the primary Control Station, Control Station in slot 0 (CS0). Unisphere and the Navisphere CLI support a full suite of MirrorView functions, but VNX for file users should limit use of these VNX for block management interfaces to monitoring operations. VNX for file users should not routinely manage MirrorView/S by using the VNX for block management interfaces because it might lead to data inconsistency or the inability to boot VNX for file. After MirrorView/S initialization, changes affecting the configuration of the VNX for block storage system require use of Unisphere or Navisphere CLI commands. For example, to add or delete mirrored LUNs. These changes are typically made by your local EMC Service Provider.

◆ After a failover is activated at the destination VNX for file, you cannot use Unisphere to manage components of the original source site configuration from the destination. Use the CLI to manage the original source site configuration from the destination.

../AVM/index.htm

../VolFSManually/index.htm




◆ For sites with redundant Control Stations, run all MirrorView/S management commands from CS0, never Control Station in slot 1 (CS1). For example, /nas/sbin/nas_mview -init, -activate, and -restore, and nas_devicegroup. When running /nas/sbin/nas_mview -init, -activate or -restore commands, make sure CS1 is halted. However, for steady state non-MirrorView operations, CS1 can be operational.

◆ Initialization, failover activation, and initial restore operations are all performed from the designated destination VNX for file in the configuration.

◆ All procedures involving root user (su) privileges should be followed very carefully. Do not use su unless explicitly mentioned. See the man page for su for more information and usage of su.

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

◆ Do not activate a failover unless you have a valid MirrorView/S configuration in place. Ensure that the source Data Mover is configured with a remote standby Data Mover at the destination.

Account and password restrictions

◆ The global VNX for block account information, such as username and password, you supply during initialization must match the global VNX for block account information established for the VNX for block storage systems. The account must be established for the VNX for block administrator role. If you rerun initialization and the VNX for block account information is already known, you are not prompted for it again. If you change this account information, you must follow the guidelines summarized in "Guidelines for changing your VNX for block configuration" on page 29.

◆ The remote administration account you establish can have the same information for both the VNX for file systems in an active/active’ configuration. Again, during a rerun of the initialization process, you are not prompted for the information, but a message indicates that the established remote administration account is being used.

◆ You must log in to the remote administration account, for example, dradmin, to activate a failover or perform a restore of the source VNX for file.

◆ Output differs for informational commands, such as nas_server -info -all depending on how you run the command as nasadmin, root, or the established remote administration account. For example, after initialization of remote standby Data Movers, running nas_server -info -all as nasadmin does not display the Data Movers owned by the remote administration account, instead you view them when you run the command as root. Also, the information in the output’s acl field for owner= is the remote administration account when run as root. For example, owner=dradmin.

◆ To avoid potential configuration errors, use root access only when required, not for routine administration tasks, such as creating a file system, creating a checkpoint, or performing a manual local standby failover.


Failover restrictions

◆ MirrorView/S does not support partial failovers. When a failover occurs, all file systems associated with MirrorView-protected Data Movers fail over. To avoid failover problems, it is critical that mirrored file systems reside only on MirrorView-protected Data Movers. "Troubleshooting" on page 118 provides description of the potential failover and restore problems for MirrorView/S.

◆ Only one system in an active/active’ configuration can have a failover activated. You cannot have failovers activated on both systems at the same time.

MirrorView/S with VNX Usermapper

◆ If you want to continue using the Usermapper service after a MirrorView/S failover activation, make sure that the Internal Usermapper service is running on the source MirrorView-protected Data Mover.

◆ With External Usermapper, access to the Usermapper service is lost after a MirrorView/S failover activation.

MirrorView/S with SnapSure checkpoints

◆ 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 a MirrorView/S LUN, ensure that the entire SnapSure SavVol with the checkpoints resides in the same pool of MirrorView 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 MirrorView LUNs, the checkpoints are not failed over and therefore are not recoverable in the event of a failover. Evaluate the use of checkpoints carefully.

◆ After a failover is activated, checkpoint scheduling is not supported until a restore is performed.

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

SNMP or e-mail event notification

After a failover is activated, SNMP or e-mail for event notification is not supported.

Other VNX feature-specific restrictions

◆ EMC VNX Replicator™ works with disaster recovery replication products such as SRDF/Synchronous (SRDF/S) and SRDF/Asynchronous (SRDF/A) or MirrorView/Synchronous (MirrorView/S). You can run SRDF or MirrorView/S products and VNX Replicator on the same data. However, if there is an SRDF or MirrorView/S site failover, you cannot manage VNX Replicator sessions on the SRDF or MirrorView/S failover site. Existing VNX Replicator 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.

◆ Automatic File System Extension cannot be used for any file system that is part of a MirrorView/S configuration, that is, file systems on Data Movers configured with a remote standby. You cannot use the nas_fs command with the



auto_extend option for file systems associated with MirrorView/S. Doing so generates an error message indicating that the operation is not supported for mirrored file systems. The specified file system must be built on local storage, not mirrored storage, to enable Automatic File System Extension.

◆ MirrorView/S does not support Multi-Path File System (MPFS).

◆ Products that require Symmetrix storage, such as TimeFinder/FS, NearCopy, and FarCopy, do not work with MirrorView/S. There are no equivalent VNX products that work with MirrorView/S.

MirrorView/S error and informational messages help prevent configuration of unsupported features, such as Automatic File System Extension. "Error messages" on page 138 provides more information.

"EMC E-Lab Interoperability Navigator" on page 118 provides information about product interoperability. For example, VNX for block products such as EMC SnapView™ do not work in the VNX environment. Your local EMC sales organization can provide information about using products with MirrorView/S.

Note: The VNX 1.0 Release Notes, available at http://Support.EMC.com, contain the latest information about changes to documented restrictions.

User interface choices

This document describes how to configure MirrorView/S by using the command line interface (CLI). You cannot use other VNX management applications to configure MirrorView/S.

You can use the Unisphere software to view the storage pools and disk types used in the MirrorView/S configuration. For example, a disk associated with MirrorView/S appears with the disk type CMSTD or CMATA when viewing disk or volume properties after MirrorView/S initialization. The AVM storage pools for MirrorView/S are cm_r1, cm_r5_performance, cm_r5_economy, cmata_archive, or cmata_r3, depending on the disk configuration. While you cannot use Unisphere to configure MirrorView/S, you can use it to manage storage objects, such as file systems that reside on the source MirrorView-protected Data Mover.

Note: When creating new storage objects on this MirrorView-protected Data Mover, you are restricted to space in the MirrorView/S storage pools. Objects that require local storage must be created on local Data Movers.

In addition, when you use Unisphere to view information:

◆ You can view an alert that addresses MirrorView/S device group conditions. "Retrieve information from log files" on page 121 provides more information about the events that correspond to the Unisphere alerts.

◆ When you view Data Mover properties, note that the Standby For Movers field identifies the primary Data Movers for which the current Data Mover is a local standby and the Standby Movers field identifies the local standby Data Movers for the current primary Data Mover. The Standby Movers field are blank if no local standby Data Movers are configured.



Terminology

The VNX Glossary provides a complete list of VNX terminology.

Note: In this document, when referring to VNX for file configurations and how they function with MirrorView/S, the term NS refers to the NS series gateway server models, such as the NS40G or the NS700 series gateway servers. For example, the NS702G with two Data Movers. NSX refers to the NSX series gateway server, which can support between four and eight Data Movers. The VNX for file systems are considered front-ends and VNX for block storage systems are the back-ends.

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 VNX for file 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 VNX for block 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.

active/passive: For SRDF or MirrorView/S configurations, a unidirectional setup where one VNX for file, with its attached storage system, serves as the source (production) file server and another VNX for file, with its attached storage, serves as the destination (backup). This configuration provides failover capabilities in the event that the source site is unavailable. An SRDF configuration requires Symmetrix systems as backend storage. A MirrorView/S configuration requires specific VNX Series or CX series systems as backend storage.

VNX 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.

consistency group: VNX for block MirrorView feature to preserve application data consistency across multiple mirrored LUNs. A consistency group must contain all the remote mirrors created to represent the source LUNs and their equivalent destination LUNs. In a link or device failure scenario, the set of mirrored LUNs always fracture as a group so that their destination images are maintained in a consistent, logically recoverable state. On the VNX for file, all LUNs that are mirrored must be in one MirrorView consistency group, and the consistency group is managed as a VNX for file device group after initialization.

destination array: Array that contains the image copies of the source LUNs.

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

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



destination LUN: Mirrored copy of the data in the remote array. A destination LUN represents a secondary image.

FLARE: Embedded operating system in VNX for block disk arrays.

LUN (logical unit number): Identifying number of a SCSI or iSCSI object that processes SCSI commands. The LUN is the last part of the SCSI address for a SCSI object. The LUN is an ID for the logical unit, but the term is often used to refer to the logical unit itself. For MirrorView/S, a LUN is either a source LUN or a destination LUN. It is the equivalent of a VNX for file disk 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 VNX for file to take over for a failed VNX for file 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 VNX for block backend storage.

Multi-Path File System (MPFS): VNX 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 VNX for block storage array. MPFS adds a lightweight protocol called File Mapping Protocol (FMP) that controls metadata operations.

Navisphere: Centralized storage system management tool to discover, monitor, provision, and report on VNX for block storage systems from your web browser.

Production File System (PFS): Production file system on a VNX. A PFS is built on Symmetrix volumes or VNX for block LUNs and mounted on a Data Mover in the VNX.

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 VNX for block 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.

source array: Array that serves data to a production host from the source LUNs.

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

source LUN: LUN that is used by the production host. A source LUN represents a primary image.

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).


Related information

For specific information related to the features and functionality described in this document:

◆ Configuring Events and Notifications on VNX for File

◆ EMC VNX Command Line Interface Reference for File

◆ Celerra Error Messages Guide

◆ Parameters Guide for VNX

◆ Managing Volumes and File Systems for VNX Manually

◆ Managing Volumes and File Systems with VNX Automatic Volume Management

◆ Online VNX for File man pages

◆ Unisphere online help

◆ VNX Glossary

◆ Problem Resolution Roadmap for VNX

◆ Using VNX FileMover

◆ Using SRDF/S with VNX for Disaster Recovery

Other related EMC MirrorView-related publications, available on Online Support, include:

◆ EMC MirrorView/Synchronous for Navisphere Administrator’s Guide

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

◆ EMC Navisphere Command Line Interface (CLI) Reference

In addition, the following Customer Service technical note is available for the local EMC Service Provider configuring the back-end VNX for block storage system:

◆ MirrorView/Synchronous Setup on VNX for Block

EMC VNX Documentation on the EMC Online Support website

The complete set of EMC VNX series customer publications is available on the EMC Online Support website. To search for technical documentation, go to http://Support.EMC.com. After logging in to the website, click the VNX Support by Product page to locate information for the specific feature required.

VNX wizards

Unisphere software provides wizards for performing setup and configuration tasks. The Unisphere online help provides more details on the wizards.

../EventsandNotifications/index.htm

../CommandReference/index.htm

../AVM/index.htm


../SRDFS/index.htm

../FileMover/index.htm

../ErrorMsgs/index.htm

../Parameters/index.htm

../ProblemResolutionRoadmap/index.htm





Concepts

MirrorView/S is a limited-distance, synchronous remote mirroring facility that offers complete disaster recovery without data loss for NS series gateway and NSX series VNX for file configurations with VNX for block storage systems. MirrorView ensures that the MirrorView/S-protected file systems on a source VNX for file are recoverable, even if the source VNX for file is unavailable or not functioning. With MirrorView/S, users can continue to access file systems even if the source VNX for file or the VNX for block system becomes unavailable.

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

MirrorView/S is intended for disaster tolerance and recovery. As used by CX series storage arrays (CX700, CX600, CX500, CX400, CX3-40, or CX3-80) and VNX Series storage arrays (VNX5100, VNX5300, VNX5500, VNX5700, or VNX7500), the MirrorView software application offers disaster recovery by maintaining copies of production images at different locations. The remote copies are continually updated to ensure consistency with the source by using a MirrorView/S group. From the perspective of the VNX for block storage system, this MirrorView/S group is a consistency group. From the perspective of the VNX for file, this is a device group. Maintenance of the MirrorView/S group ensures that the destination site VNX for file/VNX for block pair can take over for a failed source site VNX for file/VNX for block pair. In a failure scenario, MirrorView/S enables you to perform a manual failover from a source site to a destination site, and then restore operations on the source site following a failover.

Note: All the data required for the destination to assume operation in the event of a manual failover must be located on the source VNX for file’s boot VNX for block storage system and synchronously mirrored, by using the MirrorView/S software, to the destination VNX for file’s boot VNX for block. Only one MirrorView group on the boot VNX for block storage system is available for failover to the destination site, even though multiple VNX for block storage systems are supported.

MirrorView/S is part of the VNX for block family of remote mirroring software, which offers high-availability configuration options.


MirrorView/S

MirrorView/S supports two types of configurations:

◆ Active/passive — Configuration with two environments, a production environment at one site and a disaster recovery (DR) environment at another site, which becomes active after a failover.

◆ Active/active — Configuration in which both sites are used for production data, and each production site acts as the DR site for its peer.

Communication between Control Stations

In a MirrorView/S configuration, the Control Stations associated with the source and destination site VNX for file/VNX for block pairs communicate through:

◆ IP data network

◆ MirrorView/S links (dedicated links that provide access to the source LUNs remotely mirrored with MirrorView/S)

Figure 1 on page 17 shows a MirrorView/S configuration with two sites, source Site A and destination Site B. Each site has an attached VNX for file and VNX for block pair or CX series storage array pairs. Dedicated MirrorView/S FC/IP links exist between the storage processors of the source and destination VNX for block storage arrays. Each VNX for file has a path to each storage processor through the switch fabric.

Figure 1 Sample VNX for file with VNX for block MirrorView/S configuration

Note: The line between the destination VNX for file and the destination VNX for block is dotted because the storage is not host-visible. VNX for file does not see the mirrored LUNs at the destination site until a failover is activated.

Dedicated MirrorView/S Link

VNX for fileHost

VNX for fileHost

VNX for block VNX for block

VNX-000061

Site B Destination

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

Site A Source

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 IPData Network

Connection

DestinationLUNs

SourceLUNs

Consistency group withmirrored LUNs



Each storage processor on a VNX for block storage array has a unique communication link. Each link has the possibility of failing independently. MirrorView/S uses the dedicated links to send data to the mirrored LUNs and pass state information between the storage arrays.

Note: The storage processor (SPA-SPA and SPB-SPB) connections usually use the lowest-numbered port for VNX Series systems and the highest-numbered port for CX series systems. For example, port 0 on VNX5100/VNX5300/VNX5500/VNX5700/VNX7500, port 1 on CX500/400 and CX3-40, and port 3 on CX700/600 and CX3-80. "MirrorView/S configuration through SP ports" on page 34 provides more information about this.

The two Control Stations and both storage arrays must be connected through IP. The Control Stations can communicate over LAN/WAN links. Each Control Station must also use the IP network to communicate with both storage processors on the Site A and Site B VNX for block systems. The same Control Station (CS0), which can promote the destination-site image should the source image become unavailable, must be able to manage the VNX for file/VNX for block pairs. All storage arrays that participate in the mirror must be in the same domain.

MirrorView/S LUNs

MirrorView/S configuration is based on logical units called LUNs, which can be considered the equivalent of VNX for file disk volumes. For MirrorView/S, a LUN is either a source LUN or a destination LUN. A source LUN represents the production or primary image that is mirrored and an equivalent destination LUN represents the secondary image at the destination. As part of the MirrorView/S configuration procedures for the VNX for block storage system, a remote mirror is created for each source LUN and the equivalent destination LUN is added to the mirror.

Each LUN, or logical volume defined in the VNX for file volume database consists of two physical disk volumes: one on the source VNX for block and one on the destination VNX for block. Any file system built on this source volume resides on both disks. The destination disk devices have the mirrored data LUNs. These destination devices are transparent to the source VNX for file host. They are only write-accessible when you activate them as a result of a manual failover operation.

For configuration purposes, a MirrorView/S source LUN is either a system control LUN or a user LUN. MirrorView/S requires three source control LUNs: dos, log, and nas, and their equivalent destination LUNs. Unlike user LUNs, these control LUNs have fixed host LUN ID mappings. The source control dos, log, and nas LUNs must have host LUN IDs of 0, 1, and 4, respectively, and the equivalent destination control dos, log, and nas LUNs must have host LUN IDs of 6, 7, and 9, respectively.

Note: The VNX for file system setup phase includes configuration of the LUNs on the attached source VNX for block array and the remote VNX for block array by your local EMC Service Provider. In addition, MirrorView/S software and EMC communications hardware are installed to enable the VNX for block storage systems to communicate with each other. Your local EMC Service Provider can ensure that the appropriate LUNs and dedicated MirrorView/S links are established. For MirrorView/S disaster recovery, the dedicated MirrorView/S links must be in synchronous mode. Because synchronous mode acknowledges every write request, this mode might delay write operations during normal remote-mirroring operations, but read operations are not impacted.


Consistency groups and device groups

A MirrorView/S consistency group represents a set of mirrored LUNs always managed as a group. After VNX for file MirrorView/S initialization, the MirrorView consistency group becomes available to VNX for file users as a device group and is thereafter managed as a device group. The use of a MirrorView/S group prevents the destination LUNs from becoming inconsistent with one another should one of the MirrorView links temporarily fail, or if a single device fails. In a link or device failure scenario, the set of LUNs always fracture as a group so that their destination images are maintained in a consistent, logically recoverable state. In general, the device group provides the ability to preserve application data in a consistent state across the multiple, mirrored LUNs.

A single MirrorView/S consistency group requires three LUNs as VNX for file Control LUNs. The remaining LUNs are available as user data LUNs. Table 2 on page 6 provides more information about various LUN configurations. All the mirrors in a group must be associated with the same storage array.

As part of the storage system setup procedures, a MirrorView/S consistency group is established on the source-site VNX for block. When the group is created, all mirror pairs between the source and destination storage systems must be added to the group. When the VNX for block mirror configuration is subsequently discovered by the VNX for file, several checks are performed to verify that only one MirrorView/S device group is visible to the source VNX for file, that all mirrored devices are members of the group, and that the VNX for file can see all members of the group.

Note: An initialized active/passive configuration has only one active device group. An initialized active/active’ configuration, in which each site serves as both source and destination, has two active device groups, one on each VNX for file that serves as a source.

VNX primary and standby system compatibility

All gateway and unified systems that support VNX version 7.0 and later are supported by MirrorView/S. It is possible to replicate VNX for File LUNs with MirrorView/S from different VNX systems and gateway models as per the failover rules outlined in Table 3 on page 19.

Table 3 VNX primary and standby system compatibility matrix (page 1 of 2)

Primary/ Standby

VNX5300 VNX5500 VNX5700 VNX7500Gateway VG2

Gateway VG8

VNX5300 Y Y1 Y1 Y1 Y1 Y1

VNX5500 Y Y Y1 Y1 Y1 Y1

VNX5700 Y Y Y Y1 Y1 Y1

VNX7500 Y Y Y Y Y1 Y1

Gateway VG2

Y1 Y Y1 Y1 Y Y1



1. To make the primary Data Mover compatible with the standby Data Mover (from six cge ports to four cge ports), two ports out of the six must be masked. Masking will be done by using the hidden_interfaces parameter. "Ensure Data Mover network device compatibility" on page 108 provides more information about the hidden_interfaces parameter.

It is recommended that the standby Data Mover be at least as performance and capacity capable as its primary Data Mover. These restrictions are not enforced by the code.

The nas_mview –init command validates and enforces standby compatibility. The compatibility rule is simple: the standby Data Mover must have the same or more network devices as the primary Data Mover.

Gateway VG8

Y1 Y1 Y1 Y1 Y Y

Table 3 VNX primary and standby system compatibility matrix (page 2 of 2)

Primary/ Standby

VNX5300 VNX5500 VNX5700 VNX7500Gateway VG2

Gateway VG8


MirrorView/S Configurations

MirrorView/S supports:

◆ "Active/passive configuration" on page 21

◆ "Active/active’ configuration" on page 22

Active/passive configuration

In an active/passive configuration, MirrorView/S provides a complete disaster recovery configuration by writing data to two VNX for block systems in separate locations, using mirrors of source LUNs and their equivalent destination LUNs, before allowing an application to continue. This ensures that a second copy of the data associated with the source LUNs, accurate up to the last transaction, is immediately available for use. All writes are handled in a serial fashion.

As shown in Figure 2 on page 21, in an active/passive MirrorView/S configuration:

1. Data is written to the source VNX for block system.

2. MirrorView/S copies the data to the destination VNX for block system.

3. The remote VNX for block system performs a cyclic redundancy check (CRC) on the data in cache and acknowledges the source VNX for block system.

4. The write-acknowledge signal is sent to the host/server that initiated the I/O request.

Note: The next write I/O is sent to the destination VNX for block storage system after the first write is acknowledged in step 3.

Figure 2 MirrorView/S active/passive configuration

VNX for blockDestination

DestinationLUNs

VNX-000062

Copy

Acknowledge

2

3Acknowledge

Write1

4

*LUNs are part of a MirrorView consistency group (VNX for file device group)

VNX for blockSource

SourceLUNs*



Active/active’ configuration

In an active/active’ configuration, each VNX for block system configured for MirrorView/S can be partitioned into both source LUNs and destination LUNs, and function both as the source system and the remote mirror. There are two communications links, each connecting the source disks with their remote counterparts on the other VNX for block system. Write requests to each source disk are mirrored on the corresponding backup destination disk.

As shown in Figure 3 on page 22, this configuration lets each VNX for block system be used as a production system and as a remote mirror. Based on the storage system configuration of a given VNX for block, one MirrorView/S consistency group (after VNX for file initialization, a device group) represents the source LUNs and a second group represents the destination LUNs, remote backup. You cannot have failovers activated at both sites at the same time.

Active/active’ also relies on the synchronous mode inherent with MirrorView/S, ensuring that all writes are handled in a serial fashion.

Figure 3 MirrorView/S active/active' configuration

SecondConsistencyGroup

FirstConsistencyGroup

VNX for block Source VNX for block Destination

Acknowledge

Acknowledge

Copy

Copy

VNX-000060

DestinationLUNs

SourceLUNs

DestinationLUNs

SourceLUNs


Comparison of VNX high-availability and replication products

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

Note: EMC recommends that all parts of a VNX 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. Therefore, file systems should not span multiple storage systems. "Restrictions" on page 6 provides more information about MirrorView/S restrictions.

Table 4 Comparison of VNX disaster recovery, high-availability, and replication products (page 1 of 3)

Product Storage platform What it does Restrictions

MirrorView/S VNX for block only (VNX5100/VNX5300/VNX5500/VNX5700/VNX7500), CX series (CX700/600/500/400, CX3-40, or CX3-80)

Using attached VNX for file and VNX for block storage system pairs, performs synchronized, remote mirroring to provide full disaster recovery without data loss at a limited distance.

This document provides more information about MirrorView/S.

Cannot be used in the same VNX for file configuration as SRDF.

Cannot be used with Symmetrix-based products, such as TimeFinder/FS.

Cannot be used with Automatic File System Extension.

Performs LUN (volume) cloning, not file system cloning.

Remote volumes are accessible only after a failover.

Note: With MirrorView/S, VNX for file 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.

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

Using attached VNX for file and Symmetrix pairs, performs synchronized, remote replication to provide full disaster recovery without data loss at a limited distance.

Using SRDF/S with VNX for Disaster Recovery provides more information about SRDF/S.

Cannot be used in the same VNX for file configuration as MirrorView/S.


Performs volume cloning, not file system cloning.


../SRDFS/index.htm

../SRDFS/index.htm



SRDF/A Symmetrix only, DMX series

Using attached VNX for file and Symmetrix pairs, performs asynchronous, point-in-time replication at an extended distance.

Using SRDF/A with VNX provides more information about SRDF/A.

Cannot be used in the same VNX for file configuration as MirrorView/S.


Performs volume cloning, not file system cloning.


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

A single file system occupies an entire STD volume.

Does not perform volume cloning.

TimeFinder/FS NearCopy and FarCopy

Symmetrix only Using a business continuance configuration with Symmetrix BCVs, provides remote file system cloning, creating a point-in-time copy (snapshot) of a VNX for file PFS. Using TimeFinder/FS, NearCopy, and FarCopy on VNX provides more information about TimeFinder/FS products.


Do not perform volume cloning.

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

VNX Replicator VNX-supported storage (one Symmetrix or VNX for block pair)

Produces a read-only, point-in-time copy of a source file system 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 VNX for file cabinet, or by a Data Mover at a remote site for content distribution, backup, and application testing.

Using VNX Replicator provides more information.

Business continuance volume (BCV) cannot be a source or a destination file system for TimeFinder/FS, NearCopy, or FarCopy for replication. You can replicate the underlying source file system, but cannot replicate the BCV.

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.



../SRDFA/index.htm

../TimeFinder/index.htm



../Replicator/index.htm


SnapSure VNX for file-supported storage

On a VNX for file system, provides point-in-time logical images (checkpoints) of a PFS.

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

In version 5.6, SnapSure supports 96 read-only and 16 writeable checkpoints.





Planning considerations

Before configuring MirrorView/S, consider the following:

◆ "Upgrade your VNX environment" on page 26

◆ "VNX file system recommendations" on page 27

◆ "VNX for file remote administration account recommendations" on page 28

◆ "VNX for block storage system configuration" on page 28

◆ "VNX volume and Data Mover decisions/flexibility" on page 30

◆ "VNX Data Mover configuration checklist" on page 32

◆ "MirrorView/S configuration sheet" on page 33

◆ "MirrorView/S configuration through SP ports" on page 34

Upgrade your VNX environment

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

◆ The VNX system LUN requirements can be accommodated by the current MirrorView LUN support guidelines. Table 2 on page 6 provides more information about LUN support guidelines.

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

With existing LUNs in place, you can work with your local EMC Service Provider to perform a subset of the VNX for block storage system configuration tasks, such as creating the remote mirrors and establishing the consistency group.

You cannot upgrade to a MirrorView/S configuration if your mirroring configuration requirements exceed the current consistency group capacity depending on the storage system, or if you would require a mix of mirrored and local storage to fit within current consistency group capacity. Table 2 on page 6 provides more information about the user LUN capacity of the consistency group for different storage systems.

Note: The introduction of the Secure NaviCLI feature on the system in version 5.5.27 changes the security file format. Therefore, if you have an earlier MirrorView/S configuration, make sure that you rerun the /nas/sbin/nas_mview -init command after performing the upgrade to re-create the security file.

If you perform an upgrade:

◆ Make sure that the source and destination VNX for file systems have the same version.

Note: Do not perform any MirrorView procedures until the upgrade of both the systems is completed.

◆ Check the EMC E-Lab Interoperability Navigator for information on supported software and hardware, such as Data Mover configurations based on VNX for file cabinet types.


◆ Upgrade depending on the configuration:

• For an active/passive configuration, upgrade the destination site first and then the source site.

• For an active/active’ configuration, perform the upgrade on one system and then the other, as soon as possible, so that the two systems have the same revision.

◆ Make sure a failover is not activated at a destination, because the upgrade procedure is not supported for an activated state.

◆ If you have only standby Data Movers on the destination side of an active/passive configuration, several warning messages might appear during the upgrade. Although no action is required for these warning messages in the situation where you have only standby Data Movers on the destination side, make sure that you see the following message at the end of the upgrade process:

The "emcnas" package upgrade Succeeded.

EMC Knowledgebase number emc138632 provides more information about the upgrade process.

VNX file system recommendations

◆ With a new installation of MirrorView/S on a VNX for file, perform a MirrorView/S initialization by using the /nas/sbin/nas_mview -init command before building the file systems. This avoids extra configuration steps associated with the conversion of disk types from unmirrored to mirrored during the initialization process.

◆ Make sure to mount the local file systems on local Data Movers and the mirrored file systems on MirrorView-protected Data Movers. "Ensure Data Mover eligibility" on page 106 describes the Data Mover configurations that are checked during MirrorView/S initialization. Also, "Troubleshooting" on page 118 describes MirrorView/S failure scenarios and errors.

Note: If the configuration includes a mirrored file system mounted on a local Data Mover, the mirrored file system is not protected in the event of a failover.

◆ For high-availability configurations such as MirrorView/S, do not span a file system across multiple storage systems.

◆ Automatic File System Extension cannot be used for any file system that is part of a MirrorView/S configuration. Therefore, you cannot use the nas_fs command with the auto_extend option for file systems associated with MirrorView/S. Doing so generates an error message indicating that the operation is not supported for mirrored file systems.

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



VNX for file remote administration account recommendations

In an active/active’ configuration, ensure that a different user ID (UID) for a remote administration account user is used for each MirrorView/S direction. For example, dradmin. Having different UIDs for the remote administration account user in each direction in the active/active’ configuration ensures that the correct Data Mover (server) information is always displayed for the appropriate VNX for file command when a failover is activated. "(Optional) Verify remote administration account" on page 73 provides details on how to create a remote administration account user.

VNX for block storage system configuration

The VNX for block storage system configuration setup tasks for MirrorView/S, performed by your local EMC Service Provider, ensure that the LUNs on the VNX for block storage arrays are properly configured in conformance with MirrorView requirements and that the MirrorView/S links are operational.

Summary of VNX for block storage system configuration steps

On each VNX for block storage system, the configuration steps performed by your local EMC Service Provider by using Unisphere (or NaviCLI) include:

Note: These are high-level procedures summarized for informational purposes only. Your local EMC Service Provider has additional documentation that describes these steps in detail. The VNX for block MirrorView/S documentation on Online Support provides background information on the MirrorView feature for VNX for block. Not all of these steps need to be performed for an existing configuration being migrated to a MirrorView/S configuration.

1. A single domain must be established to contain the source and destination arrays. All devices that are mirrored must be in the same domain.

2. A MirrorView/S connection between the source and destination arrays must be established before any data can be mirrored. The MirrorView links connecting the storage processors on the arrays usually use the lowest-numbered port for VNX Series systems and the highest-numbered port for CX series systems. For example, port 0 on VNX5100/VNX5300/VNX5500/VNX5700/VNX7500, port 1 on CX500/400 and CX3-40, and port 3 on CX700/600 and CX3-80. "MirrorView/S configuration through SP ports" on page 34 provides more information about this.

3. The write intent log LUNs must be established on both the source and destination. The write intent log is a record of recent changes to the source LUN and can be used for recovery after a link down error. This involves creating a MirrorView write intent LUN for storage processor A and storage processor B of 128 MB each on each storage system. Any existing LUN that is not part of a storage group and is not a hot spare can be selected, or a new LUN can be bound and selected.

4. Each source LUN, which represents a primary image, must be prepared. If a source LUN does not exist, it must be bound on the source storage system. Then, it is assigned to the primary VNX for file’s storage group. As part of the basic VNX for block setup, three source Control Station LUNs with host LUN IDs numbered 0,1, and 4 must exist for the dos, log, and nas LUNs, respectively.



5. For each source LUN, an equivalent destination LUN must be created on the destination storage system. A destination LUN represents a secondary image. The source and its destination LUN must be the same size, and the backup LUN must have the same RAID type and configuration as the source. For example, both 4+1 RAID 5. As part of this process, the destination LUN should finish binding, and the backup LUN should not be assigned to any storage group.

6. For each source data LUN on the source storage system, a remote mirror must be created, specifying use of the write intent log.

7. For each remote mirror, the destination LUN must be added as a secondary image to the mirror. As part of this process, the mirror state must change from fractured to out-of-sync, to synchronizing, to in-sync. Each source/destination LUN pair in a remote mirror must be synchronized before being added to a device group.

8. The destination LUNs must be assigned to the destination VNX for file’s storage group. Although these LUNs are not visible to the destination VNX for file until after being promoted, they can still be in a storage group after each is added to a mirror as a secondary image. This step requires fixed LUN mappings, the dos, log, and nas control LUNs must have host LUN IDs 0, 1, and 4 on the source and are mapped to 6, 7, and 9, respectively on the destination.

9. From the source site, a MirrorView/S consistency group must be created. You can see the assigned name of the group (the device group) during the MirrorView/S initialization procedure.

10. All synchronized remote mirrors (mirror pairs) must be added to the group. As part of this process, the three mirrors for the control LUNs (dos, log, and nas) must be added to the group.

Guidelines for changing your VNX for block configuration

◆ Storage system configuration changes can be performed by your local EMC Service Provider after initial configuration as long as a failover has not been activated. No storage system configuration changes should be made if a failover has been activated.

◆ Any VNX for block storage configuration change that affects any of the mirrors, storage groups, or device groups used by the VNX for file requires you to rerun the /nas/sbin/nas_mview -init command from the destination VNX for file. If you want to add storage or remote mirrors to the device group, consult your local EMC Service Provider.

◆ In general, the name of the consistency group should not be changed after initialization. If the name of the MirrorView/S consistency group is changed on the VNX for block storage system after initialization, your local EMC Service Provider or EMC Customer Service must perform the procedure described in EMC Knowledgebase emc138372 to correct the VNX device group information. This procedure involves a deletion of the device groups visible to each VNX for file and a rerun of initialization on the appropriate VNX for file.

◆ If the global VNX for block account password changes, the VNX for file storage security information on the Control Station must also be updated. After initialization, you can capture this change by rerunning the /nas/sbin/nas_mview



-init command. After a failover, you must use the nas_storage command with the modify option. "Modify VNX for block security information after a failover" on page 114 provides more information.

VNX volume and Data Mover decisions/flexibility

With either active/passive or active/active’ MirrorView/S configuration, you can choose which LUNs (disk volumes) and Data Movers to protect with remote mirroring. For example, a typical active/passive configuration provides a full backup of the source site, Data Mover for Data Mover. However, in general, you can remotely mirror some LUNs and Data Movers while others are only locally protected. You do not have to protect all volumes and Data Movers.

When planning the MirrorView/S Data Mover configuration:

◆ For each source Data Mover you choose to protect with a remote MirrorView/S 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 given source Data Mover that you choose to protect and a dedicated remote standby Data Mover at the destination site. In addition, the source Data Mover and its remote MirrorView standby must use the same slot number. For example, server_2 in slot 2 on the source and server_2 in slot 2 at the destination.

◆ If you want one or more source site MirrorView-protected Data Movers to also have a local standby Data Mover, the requirements for the local standby are:

• The local standby must serve only MirrorView-protected source Data Movers. The local standby cannot serve a mix of MirrorView-protected and non-MirrorView Data Movers.

• Any local standby that serves a MirrorView-protected source Data Mover must also have a dedicated remote MirrorView/S standby Data Mover. In addition, the local standby and its remote standby must use the same slot number. For example, local standby server_3 in slot 3 must have a remote standby that also uses server_3 in slot 3. Having multiple local standby Data Movers serving a given MirrorView-protected source Data Mover is also supported as long as each one of these local standby Data Movers has a remote standby Data Mover, and the remote standby uses the same slot number as the local standby.

Note: After you have established a MirrorView/S configuration, you should use the /nas/sbin/nas_mview -init command, not the server_standby -create command (run as root), to manage the remote standby Data Mover relationships and verify relationships after standby configuration. Using the nas_mview -init command helps prevent misconfiguration, because the initialization procedure checks Data Mover eligibility, and validates and enforces standby Data Mover compatibility with the source Data Mover. The possible Data Mover conditions that you might see during initialization are listed in "Ensure Data Mover eligibility" on page 106. It might be helpful to review these conditions in advance. You can use the server_standby command to change a local-only standby configuration and then use the nas_mview -init command to validate the configuration change.

◆ The network configuration of the MirrorView/S standby Data Mover must be a superset of the network configuration of the source Data Mover. The network devices of the standby Data Mover must match those of the source Data Mover


or be a superset. The MirrorView initialization procedure validates and enforces standby compatibility. If you have questions about Data Mover compatibility between source and standby Data Movers, consult the E-Lab Interoperability Navigator, which is available on Online Support.

◆ The network configuration of the MirrorView/S standby Data Mover must be able to access the destination data LUNs corresponding to the source Data Mover.

Table 5 on page 31 and Table 6 on page 31 list the Data Mover configurations you can have at the local and remote sites in active/passive and active/active’ MirrorView/S environments.

Table 5 Permissible active/passive Data Mover configurations

Source site Data Mover Direction of DR relationship

Destination site Data Mover

Local source Data Mover that will be MirrorView-protected

---------------------> MirrorView remote standby Data Mover

Local standby Data Mover for MirrorView-protected source Data Mover

--------------------> MirrorView remote standby Data Mover using same slot number as the source-site local standby

Local source Data Mover (non-MirrorView)

No relationship Local source Data Mover (non-MirrorView)

Local standby Data Mover (non-MirrorView)

No relationship Local standby Data Mover (non-MirrorView)

Table 6 Permissible active/active’ Data Mover configuration

Site A Data Mover Direction Site B Data Mover

Local source Data Mover that will be MirrorView-protected

---------------------> MirrorView remote standby Data Mover

Local standby Data Mover for MirrorView-protected source Data Mover

--------------------> MirrorView remote standby Data Mover using same slot number as the other source-site local standby

Local source Data Mover (non-MirrorView)

No relationship Local production Data Mover (non-MirrorView)

Local standby Data Mover (non-MirrorView)

No relationship Local standby Data Mover (non-MirrorView)

MirrorView remote standby Data Mover

<-------------------- Local source Data Mover that will be MirrorView-protected

MirrorView remote standby Data Mover using same slot number as the other source-site local standby

<-------------------- Local standby Data Mover for MirrorView-protected source Data Mover




VNX Data Mover configuration checklist

To ensure proper Data Mover configuration:

1. Decide and list which Data Movers to designate as MirrorView/S source and MirrorView/S remote standby Data Movers. This is a one-to-one failover relationship. A Data Mover can be a MirrorView/S standby for only one source Data Mover, and a MirrorView/S source Data Mover can only have one MirrorView/S standby. In the initialization procedure, these failover relationships are designated and assigned.

Note: By default, Data Movers are referred to as servers and are named server_n, starting with server_2.

2. On a given destination site, you cannot configure a local Data Mover as a MirrorView/S remote standby if that Data Mover is already configured as a local standby. If the source Data Mover with a remote MirrorView standby Data Mover also has a local standby Data Mover that local standby must have a remote MirrorView standby Data Mover at the destination site. This prevents problems with failover. For an NS series gateway server active/passive configuration with two Data Movers (established for high availability), you need to remove the default local standby status of the destination VNX for file server’s local Data Mover (for example, server_3) before you can configure that Data Mover as a MirrorView/S standby during the initialization process on the destination VNX for file server. For example:

server_standby server_2 -delete mover=server_3server_setup server_3 -type nas

"Initialize from the destination VNX for file (active/passive)" on page 45 provides more information about initialization.

3. Make sure each local standby Data Mover providing local standby coverage for a MirrorView/S-protected Data Mover has a corresponding remote MirrorView/S standby.

4. For source Data Mover and remote standby Data Mover compatibility, consult the EMC E-Lab Interoperability Navigator and make sure:

• The source Data Mover and its remote standby are of a similar model type, that is, the local MirrorView/S Data Mover and its corresponding remote standby Data Mover should be the same model, or the remote standby represents a superset of the source Data Mover’s network configuration.

• The remote standby Data Mover has the same performance and capacity as its source Data Mover.

5. If you see a Data Mover condition of not compatible during initialization, the source Data Mover has one or more network devices not available on the remote standby Data Mover. The network devices in the two cabinets do not have the same configuration. This might happen if you are mixing an NS series gateway cabinet with an NSX cabinet and you have a different number of network ports in use on both sides. For example, six cge ports on a source NS versus five on the destination NSX. "Ensure Data Mover network device compatibility" on page 108 provides more information about resolving this


compatibility problem with a Control Station parameter that hides (masks) unused network devices.

6. Make sure the source and destination cabinets are compatible NS series gateway or NSX model types. For example, two NS series gateway cabinets, a valid NS series gateway-NSX cabinet combination, or two NSX-NSX cabinets. "System requirements" on page 4 provides more information about supported hardware and software for MirrorView/S.

7. Consider IP data network connectivity problems when planning the Data Mover assignments.

8. Ensure network interfaces for the MirrorView/S source and MirrorView/S standby Data Movers are identical, and the same set of network clients can access the MirrorView/S source and corresponding remote standby Data Movers.

9. Be aware that a failover operation moves the network configuration associated with the source Data Mover to the destination Data Mover. For example, if cge0 on the source Data Mover is connected to subnet A on the source side, cge0 on the destination Data Mover must be connected to subnet A on the destination side. If the destination side has a different subnet network configuration, you must change the IP addresses on the destination Data Mover manually after the activation completes. "Ensure access after failover" on page 64 provides more information.

10. Evaluate the infrastructure of the destination site, such as its subnet addresses, the availability of NIS/DNS servers in the right UNIX domain, the availability of WINS/PDC/BDC/DC in the right Windows domain, and the availability of NTmigrate or Usermapper hosts. The CIFS environment requires more preparation to set up a MirrorView/S configuration because of the higher demands on its infrastructure than with the NFS environment. For example, authentication is handled by the infrastructure versus client OS. For the CIFS environment, you must perform mappings between usernames/groups and UIDs/GIDs.

11. Evaluate whether to establish network firewalls between the pair of source and destination VNX for file. If so, any firewalls between the sites must allow for the Control Station-to-Control Station communication across the IP network by using ports 80 and 8000 for HTTP, port 6389 for NaviCLI, and port 443 for Navisphere Secure CLI (naviseccli). Open ports 8000 and 9823, and enable ICMP for Control Station-to-Control Station communication over an IP link in general.

MirrorView/S configuration sheet

Table 7 on page 34 provides a tracking sheet for MirrorView/S configuration information. For an active/passive configuration, use one sheet and for an active/active’ configuration, use two sheets.



Note: For detailed information about the VNX for block storage system configuration for MirrorView/S, such as a list of VNX for block LUN mappings, consult the expanded configuration sheet put together by your local EMC Service Provider (as VNX for block system administrator) during the source and destination VNX for block setup. It is expected that the detailed configuration sheet is left at your site after initial setup.

MirrorView/S configuration through SP ports

MirrorView/A and MirrorView/S connections can be configured through SP Fibre Channel MirrorView ports only for CX3-20, CX3-20f, CX3-40, CX3-40f, CX3-80,

Table 7 Basic MirrorView/S configuration tracking sheet

What you specify Source-site information Destination-site information

Control Station name

Control Station IP address

Password specified with nas_cel

(must be the same for both)

Existing VNX for block storage information

Global VNX for block account username: __________

Global VNX for block password: __________

APM #: APM #:

Data Mover DR pair Source server:

Type:

Standby server:

Type:


Type:

Standby server:

Type:


Type:

Standby server:

Type:


Type:

Standby server:

Type:


Type:

Standby server:

Type:

Remote administration account and password

Created on destination during initialization:

Username:

Password:


CX400, CX500, CX600, CX700, AX4-5, VNX5100, VNX5300, VNX5500, VNX5700, or VNX7500 storage systems, and through SP Fibre Channel for CX4-120, CX4-240, CX4-480, CX4-960, CX3-10c, CX3-20c, or CX3-40c storage systems. Table 8 on page 35 and Table 9 on page 35 show the SP MirrorView ports for each storage system.

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

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

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

Table 8 SP MirrorView ports for the CX4 series

Storage system

MirrorView Fibre Channel FE ports

Logical port ID Physical slot and port number

CX4-120, CX4-240

A-1 slot A0 port 3

B-1 slot B0 port 3

CX4-480, CX4-960

A-3 slot A1 port 3

B-3 slot B1 port 3

Table 9 SP MirrorView ports for various storage systems

Storage system SP MirrorView port

Fibre Channel

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

Port 1

CX3-80, CX600, CX700 Port 3

CX3-10c Port 3

CX3-20c, CX3-40c Port 5

VNX5100/VNX5300/VNX5500/VNX5700/VNX7500

Port 0



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

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

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

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

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

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

While configuring Fibre Channel ports, remember that:

◆ A VNX for block system supports up to one FC-based MirrorView/S port (per SP).

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

• The MirrorView/S port is the lowest-numbered port for VNX Series systems and the highest-numbered port for CX series systems at that time.

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

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

Task overview

Table 10 on page 37 provides an overview of the basic tasks to establish a MirrorView/S active/passive or active/active’ configuration and their associated VNX for file commands.

Note: Before performing any of these tasks, review the requirements summarized in "Planning considerations" on page 26 to ensure that the VNX for block systems and VNX for file Data Movers are configured correctly. Your local EMC Service Provider establishes and


verifies the initial MirrorView/s configuration including preinitialization, initialization, test failover activation, and a test restore, and also manages VNX for block storage system configuration changes.

Table 10 MirrorView/S task overview (page 1 of 2)

Task summary Command used What it does

Preinitialize the relationship between the source and destination VNX for file.

From each VNX for file, using nasadmin, su to root:nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

• Establishes trusted communication between source and destination VNX for file systems as a prerequisite to MirrorView active/passive or active/active’ initialization. Must be performed on both systems by using the same passphrase (6–15 characters).

Initialize the MirrorView/S relationship between attached VNX for file/VNX for block pairs.

From the destination VNX for file, using nasadmin, su to root:

/nas/sbin/nas_mview -init <cel_name>}

Note: The /nas/sbin/nas_mview -init command should be run after any storage configuration change that affects any of the mirrors, storage groups, or device groups used by the VNX for file (for example, adding remote mirrors to the device group).

• Identifies the VNX for file that is paired with the current VNX for file in the configuration.

• Prompts for the VNX for block global user account information.

• Establishes the remote administration account used to manage the destination.

• Checks for Data Mover compatibility and establishes the Data Mover relationships from the source Data Mover to the standby.

• Checks the VNX for block storage system configuration to ensure proper LUN configuration and mapping, storage group information, and device group information.

Activate a MirrorView/S failover from a source VNX for file to a destination VNX for file.

From the destination VNX for file, using the remote administration account set up during initialization (for example, dradmin), su to root:

/nas/sbin/nas_mview -activate

• Performs a manual failover scenario (for example, a source VNX for file with attached VNX for block has become unavailable and requires a failover to the destination VNX for file/VNX for block).

• Attempts to shut down source services and Data Movers gracefully if they have not already been shut down.

• Promotes the destination LUNs, which become read/write. The source MirrorView-protected file systems are no longer available on the source.

• Enables each MirrorView/S standby Data Mover on the remote system to become active and 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 System/Common Internet File Service (NFS/CIFS) characteristics of the exported file system controlled by the failed Data Mover



Note: The VNX for file continually monitors its internal hardware status and, if properly configured, initiates a CallHome event to report any problems that could require attention by your local EMC Service Provider or EMC Customer Service.

Restore a source VNX for file after a failover.

From the destination VNX for file, using the remote administration account and su to root, then use the absolute path:

/nas/sbin/nas_mview -restore

Typically scheduled and performed under the guidance of your local EMC Service Provider or EMC Customer Service to ensure continuity between the VNX for block systems. Restoration of a source VNX for file involves a complete check of the VNX for block system and MirrorView/S and verification of full connectivity to the restored file systems on the source VNX for file:

• Copies data from destination-site LUNs to the corresponding source-site LUNs on the source VNX for block system.

• Reboots MirrorView/S standby Data Movers into standby mode.

• Write-disables destination-site LUNs from the Data Movers.

• Synchronizes destination to source.• Resumes mirroring of the source devices.• Reboots each Data Mover on the source VNX

for file and reacquires the IP addresses and file system control from the MirrorView/S standby Data Movers.

Manage MirrorView/S. From the appropriate VNX for file, su to root:/nas/sbin/nas_mview -info

ornas_devicegroup-list-info {<name>|id=<id> |-all} [-sync [yes|no]]|-acl <acl_value>{<name>|id=<id>}|-suspend {<name>|id=<id>}|-resume {<name>|id=<id>}

• Shows cabinet-level MirrorView/S configuration (using /nas/sbin/nas_mview -info).

• Manages the MirrorView/S device group (lists group information or suspends/resumes device group operations).

Table 10 MirrorView/S task overview (page 2 of 2)

Task summary Command used What it does


Sample configuration

The MirrorView/S active/passive and active/active’ configuration tasks described in this document involve the following:

◆ new_york, which serves as the source VNX for file in the active/passive configuration and one source/destination in the active/active’ configuration. new_york is located at the production data center. The IP address of the source control station in slot 0 (CS0) is 1192.168.96.85.

◆ new_jersey, which serves as the destination VNX for file in the active/passive configuration and one source/destination VNX for file in the active/active’ configuration. new_jersey is located at a remote disaster-recovery data center. The IP address of the destination control station in slot 0 (CS0) is 192.168.96.87.

Note: The number of mirrors and file system output is unique to each configuration.



Configure MirrorView/S (active/passive)

The tasks to configure active/passive MirrorView/S are:

1. "Preinitialize the configuration (active/passive)" on page 40

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

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

4. "Restore the source VNX for file (active/passive)" on page 65

Preinitialize the configuration (active/passive)

Preinitializing the configuration establishes a trusted communication between the source and destination systems. The preinitialization tasks are performed by your local EMC Service Provider.

The tasks to preinitialize the configuration are:

1. "Preinitialize from the first (source) VNX for file" on page 41

2. "Preinitialize from the second (destination) VNX for file" on page 41

3. "Verify the preinitialization" on page 42

Prerequisites

◆ Preinitialization is a prerequisite to the MirrorView/S initialization.

◆ Preinitialization must be performed on the source and destination systems.

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

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

◆ To preinitialize, the user must log in to the VNX for file as nasadmin and then switch (su) to root.

◆ The nas_cel command must be run with the -create option as root user on both the VNX for file systems. Systems with versions prior to 5.6 use 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 systems become ready for the MirrorView/S initialization procedures.

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

Note: Before performing any of these tasks, review the requirements summarized in "Planning considerations" on page 26 to ensure that the VNX for block systems and VNX for file Data Movers are configured correctly. Your local EMC Service Provider establishes and verifies the initial MirrorView/s configuration, including preinitialization, initialization, test failover activation, and a test restore, and also manages VNX for block storage system configuration changes.


Preinitialize from the first (source) VNX for file

Preinitialize from the second (destination) VNX for file

Step Action

1. Log in to the source VNX for file (new_york) as nasadmin and switch (su) to root.

2. Preinitialize the connection from the source VNX for file to the destination VNX for file by using this command syntax:# nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

where:<cel_name> = name of the destination VNX for file<ip> = IP address of the destination Control Station in slot 0 (CS0)<passphrase> = 6–15 character password

Example:

To preinitialize connection from new_york to new_jersey with IP address 192.168.96.87 and passphrase nasadmin, type:# nas_cel -create new_jersey -ip 192.168.96.87 -passphrase nasadmin

Output:

operation in progress (not interruptible)...id = 1 name = new_jerseyowner = 0device = channel = net_path = 192.168.96.87celerra_id = APM000420008170000passphrase = nasadmin

3. Exit root by typing:# exit

exit

Step Action

1. Log in to the destination VNX for file (new_jersey) as nasadmin and switch (su) to root.



Verify the preinitialization

2. Preinitialize the connection from the destination VNX for file to the source VNX for file by using this command syntax:# nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

where:<cel_name> = name of the source VNX for file<ip> = IP address of the source Control Station in slot 0 (CS0)<passphrase> = 6–15 character password

Example:

To preinitialize the connection from new_jersey to new_york with IP address 192.168.96.85 and passphrase nasadmin, type:# nas_cel -create new_york -ip 192.168.96.85 -passphrase nasadmin

Output:

operation in progress (not interruptible)...id = 2 name = new_yorkowner = 0device = channel = net_path = 192.168.96.85celerra_id = APM000417005490000passphrase = nasadmin


exit

Step Action

1. Log in to the source VNX for file (new_york) as nasadmin.

Note: Root user privilege is not required to run the nas_cel -list (or nas_cel -info) command. However, you must be logged in as root to run the nas_cel command for create, modify, update, or delete operations.

2. Verify the preinitialization of new_york and new_jersey by typing:$ nas_cel -list

Output:

id name owner mount_dev channel net_path CMU0 new_york 0 192.168.96.85 APM0004170054900002 new_jersey 0 192.168.96.87 APM000420008170000

Note: The ID is 0 for the system from which you run the command.

Step Action


Initialize the configuration (active/passive)

Initializing the active/passive configuration prepares the designated destination VNX for file to provide full file system access and functionality in the event of a source-site failure. The initialization tasks are performed by your local EMC Service Provider from the destination VNX for file.

The tasks to initialize the active/passive configuration are:

1. "Initialize from the destination VNX for file (active/passive)" on page 45

2. "Verify the configuration (active/passive)" on page 49

Prerequisites

◆ VNX for file software must be installed on the source and destination VNX for file systems.

◆ MirrorView/S link must be operational between the source and destination VNX for file systems.

◆ The requirements summarized in "Planning considerations" on page 26 must be met to ensure that the VNX for block systems and VNX for file Data Movers are set up correctly.

◆ If there is a default local standby, evaluate which standby relationships are needed for the MirrorView/S configuration. For example, in a four-Data Mover configuration, where server_5 is the default local standby, remove the server_5 standby relationships on both VNX for file systems so that server_5 is not a local standby for server_2 and server_3. To remove the standby relationship, use the server_standby command, as described in "VNX Data Mover configuration checklist" on page 32. If you need to change the Data Mover type from standby to regular, use the server_setup command.

◆ Before running the /nas/sbin/nas_mview -init command to select an active Data Mover as a remote standby Data Mover, clean up any part of the configuration, such as the network configuration that no longer applies to that Data Mover.

◆ If you have a dual Control Station environment, halt CS1 before the initialization. You can perform MirrorView/S operations by using CS0 only. VNX System Operations describes how to halt a Control Station. After halting CS1, verify the halt by typing the /nas/sbin/getreason command, and checking for the line “0 - slot_1 powered off” in the output.



◆ Make sure that you have the global VNX for block account password established for the VNX for block storage system. This account must be associated with VNX for block Manager or higher privileges to manage all storage system settings in the domain.

Note: If the existing global VNX for block account password that you specify as part of the initialization procedure changes, but the VNX for file storage information has not been updated, you get an error. Step 4 of "Initialize from the destination VNX for file (active/passive)" on page 45 shows an example of setting the password. After initialization is complete, you can capture the change by rerunning the /nas/sbin/nas_mview -init command. However, after a failover, you must use the nas_storage command with the modify option to update the VNX for file storage security information on the Control Station. "Modify VNX for block security information after a failover" on page 114 provides more information.

◆ To avoid any path errors, always log in as nasadmin, switch (su) to root, and then run the nas_mview -init command from /nas/sbin.

Note: When using su, make sure that you follow the steps in the procedure exactly. Do not use su unless explicitly instructed.

◆ Initialization fails if errors, such as missing MirrorView/S device group configuration, remote mirror name, or ID are detected on the VNX for block storage array. "Resolve initialization failures" on page 122 describes failure scenarios associated with initialization.

◆ If the IP address of a Control Station changes after initialization, rerun the /nas/sbin/nas_mview -init command. If any hostnames or IP addresses change, edit and update the /etc/hosts file and ensure that each host can resolve its node name. Rerun the/nas/sbin/nas_mview -init command after any storage configuration change that affects any of the mirrors, storage groups, or device groups used by VNX for file.

◆ Verify the active/passive Data Mover configuration. Table 11 on page 44 shows the Data Mover configuration used in this section. The Data Movers configured for MirrorView/S are highlighted.

Table 11 Sample active/passive Data Mover configuration

Source site Data Mover (new_york)

Direction of DR relationship

Destination site Data Mover (new_jersey)

server_2

(source Data Mover)---------------------> server_2

(remote standby)

server_3

(local standby for server_2)--------------------> server_3

(remote standby)

server_4

(local Data Mover)No relationship server_4

(source Data Mover)

server_5

(local standby for server_4)No relationship server_5

(local standby for server_4)


In this configuration:

• new_jersey is the destination site VNX for file from which you run the commands to initialize the active/passive configuration. new_york is the source (active) VNX for file.

• Data Movers server_2 and server_3 on source VNX for file new_york are configured for remote disaster recovery with MirrorView/S. Also, server_3 is a local standby for server_2 and server_5 is a local standby for server_4.

• Data Movers server_2 and server_3 on new_jersey are configured as remote standbys. server_2 for source server_2 and server_3 for source server_3. Also, server_4 is a source Data Mover and has a local standby of server_5.

• Device group cg_new_york is created on both systems. This device group has nine mirrors. Before a failover, the destination does not see these mirrors. Therefore, the nas_devicegroup command output from the destination does not identify the mirrored disks.

Initialize from the destination VNX for file (active/passive)

Step Action


2. Start the active/passive initialization process on the destination VNX for file by using this command syntax: # /nas/sbin/nas_mview -init <cel_name> where:<cel_name> = name of the source (remote) VNX for file

Example:

To initialize new_york as the source site for destination site new_jersey, type:# /nas/sbin/nas_mview -init new_york

Output:

Celerra with MirrorView/Synchronous Disaster Recovery

Initializing new_york --> new_jersey

Contacting new_york for remote storage info

Local storage system: APM00042000817Remote storage system: APM00041700549



3. At the prompt, type the global VNX for block account (nasadmin) information, such as username and password established during VNX for block storage system configuration.

Note: The account must be associated with VNX for block Manager or higher privileges.

Example:

Enter the Global CLARiiON account informationUsername: nasadminPassword: ******** Retype your response to validatePassword: ********

Discovering storage on new_york (may take several minutes)Setting security information for APM00042000817 Discovering storage APM00041700549 (may take several minutes)

Discovering storage (may take several minutes)

Contacting new_york for remote storage infoGathering server information... Contacting new_york for server capabilities...Analyzing server information...

Step Action


4. At the prompt, configure each source Data Mover that is to be MirrorView-protected with a remote standby Data Mover. To configure the Data Mover relationships, type the appropriate selection:

Note: Review "VNX Data Mover configuration checklist" on page 32 to determine your Data Mover configuration. A destination site local standby cannot be paired with a source site local standby for disaster recovery. The initialization procedure validates and enforces standby Data Mover compatibility and DR eligibility for the Data Movers. "Ensure Data Mover eligibility" on page 106 provides more information.

• Type the selection number (not the server ID for a Data Mover) associated with the Data Mover to configure. For example, selection 1 for server_2.

• Type v to verify the current server configuration. You can verify the configuration after specifying each source Data Mover relationship. If there is an error, it is reported.

• Type q to quit the initialization process.• Type c to continue with the initialization process after specifying the Data Mover

relationships. • Type d to display more information if the selection menu indicates that a Data Mover is

ineligible for a remote disaster recovery configuration. In this case, the Data Mover is not selectable, and a not eligible for remote DR message appears in brackets after the server name, as shown in "Ensure Data Mover eligibility" on page 106.

• If you are rerunning the initialization to change your Data Mover configuration, type r after specifying a selection number to remove the configuration of a destination Data Mover currently serving as a remote standby. "Change the Data Mover configuration" on page 112 contains more information and steps.

• Type b to return to the previous selection screen after specifying a destination Data Mover.

Example:

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york2. server_3:new_york [ local standby ]3. server_4:new_york4. server_5:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 1

Destination servers available to act as remote standby--------------------------------------------------1. server_2:new_jersey2. server_3:new_jersey3. server_4:new_jersey server_5:new_jersey [ local standby ]b. BackSelect a new_jersey server: 1

Step Action



Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ local standby ]3. server_4:new_york 4. server_5:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 2

Destination servers available to act as remote standby-------------------------------------------------- server_2:new_jersey [ is remote standby for server_2:new_york ]2. server_3:new_jersey 3. server_4:new_jersey server_5:new_jersey [ local standby ]b. BackSelect a new_jersey server: 2

Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ remote standby is server_3:new_jersey ]3. server_4:new_jersey 4. server_5:new_jersey [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: c

Standby configuration validated OK

5. At the prompt, create the remote administration account (dradmin) to manage the remote (new_york) site.

Example:

Enter user information for managing remote site new_yorkUsername: dradmin Password: ********* Retype your response to validatePassword: *********

Note: Keep track of the username and password. You need to specify them when you activate a failover. This is a Linux-governed password on the Control Station and is covered in the Linux man pages for account passwords, such as man passwd.

Step Action


Verify the configuration (active/passive)

After initialization, you can verify elements of the active/passive MirrorView/S configuration by using the nas_server -list, nas_server -info -all, nas_devicegroup -list, nas_devicegroup -info <name>, nas/sbin/nas_mview -info, server_df ALL, nas_fs -info, and nas_disk -list commands.

6. At the prompt, continue with the initialization by typing yes.

Note: If you type no, the initialization aborts with an informational message. Note that both systems are informed about the device group creation.

Example:

Initializing Active-->Passive (new_york-->new_jersey)

Do you wish to continue? [yes or no] yes

Updating MirrorView configuration cacheSetting up server_3 on new_yorkRebooting server_3 on new_jersey as standby ... doneSetting up server_2 on new_yorkRebooting server_2 on new_jersey as standby ... doneCreating user account dradminSetting acl for server_3 on new_jerseySetting acl for server_2 on new_jerseyUpdating the Celerra domain informationCreating device group cg_new_york on new_jerseyCreating device group cg_new_york on new_yorkdone


exit

Note: Initialization of the active/passive MirrorView/S configuration is complete.

Step Action

Step Action


2. List all Data Movers by typing:$ /nas/bin/nas_server -list

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

Note: Data Movers server_3 and server_5 have type 4 to identify them as standbys. server_3 is a local standby for server_2 and both have remote MirrorView standbys. server_5 is a local standby for server_4. If you run the command from the destination side as nasadmin, only server_4 and server_5 would appear in the list because server_2 and server_3 are managed by the dradmin account.



3. Switch (su) to root by typing: $ su

Password:

4. List all information for all Data Movers by typing:$ nas_server -info -all

Output:

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

id = 2name = server_3acl = 1000, owner=nasadmin, ID=201type = standbyslot = 3member_of =standbyfor= server_2RDFstandby= slot=3status : 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, active

id = 4name = server_5acl = 1000, owner=nasadmin, ID=201type = standbyslot = 5member_of =standbyfor= server_4status : defined = enabled actual = online, ready

Note: When run from the source side, the output identifies Data Movers that have remote standbys (in the RDFstandby= field) and local standbys (standby=), and also indicates a Data Mover serving as a local standby (standbyfor=). When run from the destination, the output indicates which Data Movers are owned by dradmin and serve as remote standbys (in the acl= field and the type= field), and also indicates if a Data Mover serves as a local standby (standbyfor=). The standbyfor= has a value only if the Data Mover serves as a local standby.

Step Action



exit

6. Verify the creation of the device group on the source VNX for file after initialization by typing: $ nas_devicegroup -list

Output:

ID name owner storage ID acl type1 cg_new_york 0 APM00041700549 0 MVIEW

Note: cg_new_york represents the MirrorView/S-protected data LUNs in the device group. The group in your configuration might have a different name, which is assigned when the device group is created as part of the storage system configuration process. If you run this command on the source system, the device group cg_new_york has an owner of 0 because new_york is the source system in the active/passive configuration. Manipulation of the device group is done from the source system. If you run this command from the destination, the owner for device group cg_new_york is 500 because the group is owned by the remote administration account (in this case, dradmin). "Activate a failover from the destination VNX for file (active/passive)" on page 56 shows an example of detailed device group information prior to failover activation.

7. Get detailed information about the device group on the source VNX for file by using this command syntax:# nas_devicegroup -info {<name>|id=<id>}

where:<name> = name of the device group<id> = ID assigned to the device group

Example:

To get detailed information about the device group on the source VNX for file, type:$ nas_devicegroup -info cg_new_york

Sync with CLARiiON backend ...... donename = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:90:60:7:30:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d8,d9,d10,d12,d13,d14,local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local -> remote

8. Switch (su) to root by typing: $ su

Password:

Step Action



9. Get information about the MirrorView/S configuration from the source VNX for file by typing:# /nas/sbin/nas_mview -info

Output:

***** Device Group Configuration *****name = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:90:60:7:30:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d8,d9,d10,d12,d13,d14,local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local -> remote

***** Servers configured with RDFstandby ***** id = 1name = server_2acl = 1000, owner=nasadmin, ID=201type = nasslot = 2member_of =standby = server_3, policy=manualRDFstandby= slot=2status : defined = enabled actual = online, active

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

***** Servers configured as standby *****


Note: On the source VNX for file new_york, source server_2 and local standby server_3 have remote standbys, and server_5 is a local standby for server_4.

Step Action



exit

11. Display information about the file systems associated with Data Movers on the source VNX for file by typing:$ /nas/bin/server_df ALL

Output:

server_2 :Filesystem kbytes used avail capacity Mounted onufs4 413030384 576 413029808 0% /ufs4ufs3 413030384 576 413029808 0% /ufs3ufs2 413030384 576 413029808 0% /ufs2ufs1 413030384 576 413029808 0% /ufs1root_fs_common 13624 5256 8368 39% /.etc_commonroot_fs_2 114592 728 113864 1% /

server_3 :Error 2: server_3 : No such file or directoryfailed to complete commandserver_4 :Filesystem kbytes used avail capacity Mounted onroot_fs_common 13624 5256 8368 39% /.etc_commonufslocal3 206515184 576 206514608 0% /ufslocal3ufslocal2 413030384 576 413029808 0% /ufslocal2ufslocal1 413030384 576 413029808 0% /ufslocal1root_fs_4 114592 712 113880 1% /

server_5 :Error 2: server_5 : No such file or directoryfailed to complete command

Note: No information is reported for the standby Data Movers as nasadmin. Information is only reported for the two source Data Movers; server_2 is MirrorView-protected.

Step Action



12. Display information for one of the file systems from the source VNX for file by using this command syntax:$ nas_fs -info <fs_name>

where:<fs_name> = name of a specific file system

Example:

To view the information for mirrored file system ufs1 on server_2 on new_york, type:$ nas_fs -info ufs1

Output:

id = 27name = ufs1acl = 0in_use = Truetype = uxfsworm = offvolume = v202pool = cm_r5_performancemember_of = root_avm_fs_group_14rw_servers= server_2ro_servers=rw_vdms =ro_vdms =auto_ext = no,virtual_provision=nostor_devs = APM00041700549-0017,APM00041700549-0014,APM00041700549-0013disks = d14,d9,d12 disk=d14 stor_dev=APM00041700549-0017 addr=c16t1l7 server=server_2 disk=d14 stor_dev=APM00041700549-0017 addr=c32t1l7 server=server_2 disk=d14 stor_dev=APM00041700549-0017 addr=c0t1l7 server=server_2 disk=d14 stor_dev=APM00041700549-0017 addr=c48t1l7 server=server_2 disk=d9 stor_dev=APM00041700549-0014 addr=c0t1l4 server=server_2 disk=d9 stor_dev=APM00041700549-0014 addr=c48t1l4 server=server_2 disk=d9 stor_dev=APM00041700549-0014 addr=c16t1l4 server=server_2 disk=d9 stor_dev=APM00041700549-0014 addr=c32t1l4 server=server_2 disk=d12 stor_dev=APM00041700549-0013 addr=c16t1l3 server=server_2 disk=d12 stor_dev=APM00041700549-0013 addr=c32t1l3 server=server_2 disk=d12 stor_dev=APM00041700549-0013 addr=c0t1l3 server=server_2 disk=d12 stor_dev=APM00041700549-0013 addr=c48t1l3 server=server_2

Note: In the output, the pool reflects a MirrorView pool type. In this example, cm_r5_performance.

Step Action


Activate a failover (active/passive)

Activating a failover enables each MirrorView/S standby Data Mover on the remote system to become active. After a successful failover, users have access to the same file systems by using the same network addresses as on the source VNX for file.

The tasks to activate an active/passive MirrorView/S failover are as follows:

◆ "Activate a failover from the destination VNX for file (active/passive)" on page 56

◆ "Verify active/passive operations after failover" on page 60

◆ "Ensure access after failover" on page 64

Prerequisites

◆ After a failover has been activated, do not make any storage system configuration changes.

◆ Prior to a failover, storage system configuration changes affecting the initialized configuration can be captured by rerunning the /nas/sbin/nas_mview -init command. A change to the existing global VNX for block password requires an update of the VNX for file storage security information on the Control Station. After initialization is complete, this change can be captured by rerunning the /nas/sbin/nas_mview -init command. However, after a failover, you must use the

13. List the disks on the source VNX for file and view the mirrored and local-only disks by typing: $ nas_disk -list

Output:

id inuse sizeMB storageID-devID type name servers1 y 11263 APM00041700549-0000 CMSTD root_disk 1,2,3,42 y 11263 APM00041700549-0001 CMSTD root_ldisk 1,2,3,43 y 2047 APM00041700549-0002 CLSTD d3 1,2,3,44 y 2047 APM00041700549-0003 CLSTD d4 1,2,3,45 y 2047 APM00041700549-0004 CMSTD d5 1,2,3,46 y 2047 APM00041700549-0005 CLSTD d6 1,2,3,47 y 549623 APM00041700549-0010 CLSTD d7 1,3,4,28 y 549623 APM00041700549-0012 CMSTD d8 1,3,4,29 y 549623 APM00041700549-0014 CMSTD d9 1,3,4,210 y 549623 APM00041700549-0016 CMSTD d10 1,3,4,211 y 549623 APM00041700549-0011 CLSTD d11 1,3,4,212 y 549623 APM00041700549-0013 CMSTD d12 1,3,4,213 y 549623 APM00041700549-0015 CMSTD d13 1,3,4,214 y 549623 APM00041700549-0017 CMSTD d14 1,3,4,215 n 608270 APM00041700549-0018 CLATA d15 2,1,3,416 n 608270 APM00041700549-0019 CLATA d16 2,1,3,417 n 608270 APM00041700549-001C CLATA d17 2,1,3,418 n 608270 APM00041700549-001D CLATA d18 2,1,3,419 n 608270 APM00041700549-001A CLATA d19 2,1,3,420 n 608270 APM00041700549-001B CLATA d20 2,1,3,4

Note: The output highlights the mirrored disks associated with file system ufs1 in the pool cm_r5_performance. These disks have the disk type CMSTD.

Step Action



nas_storage command with the -modify option. "Modify VNX for block security information after a failover" on page 114 provides more information.

Note: It is strongly recommended that your local EMC Service Provider performs a test failover and restore as part of the initial MirrorView/S setup and verification process.

Activate a failover from the destination VNX for file (active/passive)

Failover is activated from the destination VNX for file by using the remote administration account (dradmin). In the sample scenario, the source VNX for file (new_york) is assumed to have become unavailable and requires a failover to the destination VNX for file server.

To activate a test failover when no real disaster scenario exists, use the following guidelines, based on whether the goal is to perform a graceful failover or to simulate a true disaster scenario:

◆ To simply perform a graceful test failover, perform the following before activating the failover:

• Make sure the MirrorView links and the IP data network connections between Control Stations are up. You can also keep the source VNX for file powered up during the activation.

• Check the device group information to verify that the group condition is in the appropriate state for the failover activation. The condition should be Active and the state should be Synchronized or Consistent.

Note: If you activate a test failover with the links down, or the device group is not in a proper state to activate a failover, a full synchronization is performed automatically as part of the restore to reconstruct the device group and mirrors, which is time-consuming and undesirable for a test scenario. If you activate the failover when the device group is not in the proper state to fail over, a warning message appears. In this case, abort the failover activation, make sure the device group is resynchronized, and then retry the failover activation. "Resolve activation failures" on page 125 provides a sample of this warning message.

◆ Verify that the data at the destination is in a proper state before activating the failover. If not, the data might be in an unknown condition, requiring one or more file system checks by using fsck as well as a full synchronization.

◆ If you are without IP connectivity between the Control Stations prior to the failover activation, you can manually shut down the source Data Movers by using the /nas/sbin/nas_halt now command. VNX System Operations addresses the nas_halt command and the platform-specific recommendations for components during shutdown procedures.

◆ After a test failover activation, you should reboot the source-site Control Station.

◆ You must have a valid MirrorView/S configuration with a remote standby configured before you activate a failover.

◆ If any VNX for block storage system configuration changes have been made after initial configuration, these changes should be reflected by the VNX for file configuration prior to a failover activation. Although the MirrorView/S


consistency group name should not be changed on the VNX for block storage system, if it is, your local EMC Service Provider or EMC Customer Service must perform the procedure described in EMC Knowledgebase emc138372 to correct the VNX device group configuration before a failover can be successfully activated.

◆ When using su, make sure that you follow the steps in the procedure exactly. Do not use su unless explicitly instructed.

!CAUTION!For sites with redundant Control Stations, ensure that all MirrorView management commands, including /nas/sbin/nas_mview -init, -activate, and -restore, are run from CS0. Ensure that CS1 is halted at both sites before you run the activate or restore commands. VNX System Operations describes how to halt a Control Station. After halting CS1, verify the halt by typing the /nas/sbin/getreason command, and checking for the line “0 - slot_1 powered off” in the output.

Step Action

1. Log in to the destination VNX for file (new_jersey) as nasadmin.

2. List information for the device group and check the state of the device group prior to activating the failover by typing:$ nas_devicegroup -info -all

Output:

Sync with CLARiiON backend ...... done

name = cg_new_yorkdescription = First_CG_ny_as_sourceuid = 50:6:1:60:B0:60:3:73:0:0:0:0:0:0:0:0state = Consistent role = Secondary condition = Active recovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 500mirrored disks = local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local <- remote

Note: As run from new_jersey in the active/passive configuration, the device group information reflects that this system is the secondary or destination system and the group represents a collection of mirrors. The mirrored disks are not visible to hosts from the destination prior to a failover.

3. Switch (su) to dradmin by typing: $ su - dradmin

Password:

Note: The password is the same as specified during the initialization procedure, as shown in step 5 of "Initialize from the destination VNX for file (active/passive)" on page 45.



4. Switch (su) to root by typing:$ su

Password:

5. Activate the failover from the source to the destination by typing:# /nas/sbin/nas_mview -activate

Output:

Sync with CLARiiON backend ...... doneValidating mirror group configuration ...... done

Note: As part of this process, all Data Movers at the source are halted. At the destination, do not shut down or reboot any Data Movers during a failover activation or a restore. "Resolve activation failures" on page 125 provides more information about errors that can occur during a failover.

Step Action


6. At the prompt, verify the readiness of the source VNX for file for shutdown and continue with the failover activation process by typing yes.

If you type no, the failover aborts with an informational message.

Note: This process can take 10–20 minutes, depending on your configuration.

Example:

Is source site new_york ready for complete shut down (power OFF)? [yes or no] yes

Contacting source site new_york, please wait... done

Shutting down remote site new_york ......................... done


Note: Next, the failover begins. Activating the destination VNX for file write-enables the destination LUNs and write-disables the source LUNs, provided that MirrorView/S and the source VNX for block system are operational.

STARTING an MV 'FAILOVER' operation.Device group: cg_new_york ............ doneThe MV 'FAILOVER' operation SUCCEEDED.

Failing over Devices ... done

Adding NBS access to local server server_2 ........ doneAdding NBS access to local server server_3 ........ doneAdding NBS access to local server server_4 ........ doneAdding NBS access to local server server_5 ........ done

Activating the target environment ... done

Note: The MirrorView/S standby Data Movers become active.

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

server_3 : going offline rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...done commit in progress (not interruptible)...done commit in progress (not interruptible)...done commit in progress (not interruptible)...done

done

Note: The activation is complete.


exit

Note: After a failover has been activated, do not make any storage system configuration changes. In the event of a true disaster where the source VNX for block is unavailable, contact your local EMC Service Provider or EMC Customer Service to coordinate restoration activities.

Step Action



Verify active/passive operations after failover

Step Action

1. Log in to the destination VNX for file (new_jersey) as dradmin.

2. Display information about the Data Movers after the failover activation 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

3. Display information about the activated MirrorView/S standby Data Movers on the destination VNX for file by typing:$ /nas/bin/server_df ALL

Output:



Note: From dradmin, no information is reported for server_3 because it is a local standby.

4. List information for the device group after the failover by using this command syntax:# nas_devicegroup -info {<name>|id=<id>} where:<name> = name of the device group<id> = ID assigned to the device group (shown with nas_devicegroup -list)

Example:

To list information for the device group after the failover, type:$ nas_devicegroup -info cg_new_york

Sync with CLARiiON backend ...... donename = cg_new_yorkdescription = First_CG_ny_as_sourceuid = 50:6:1:60:B0:60:3:73:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 500mirrored disks = root_disk,root_ldisk,d5,d8,d9,d10,d12,d13,d14,local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local -> remote


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

Step Action



6. List cabinet-level MirrorView information after the failover by typing:

# /nas/sbin/nas_mview -info

***** Device Group Configuration *****

name = cg_new_yorkdescription = First_CG_ny_as_sourceuid = 50:6:1:60:B0:60:3:73:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 500mirrored disks = root_disk,root_ldisk,d5,d8,d9,d10,d12,d13,d14,local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local -> remote

***** Servers configured with RDFstandby *****

id = 1name = server_2acl = 0type = nasslot = 2member_of =standby = server_3, policy=manualRDFstandby= slot=2status : defined = enabled actual = online, active

id = 2name = server_3acl = 0type = standbyslot = 3member_of =standbyfor= server_2RDFstandby= slot=3status : defined = enabled actual = online, ready



Step Action


7. Get a list of the source site file systems available at the destination after the failover activation by typing:# nas_fs -list

Output:

id inuse type acl volume name server1 n 1 0 10 root_fs_12 y 1 0 12 root_fs_2 13 y 1 0 14 root_fs_3 24 y 1 0 16 root_fs_4 35 y 1 0 18 root_fs_5 46 n 1 0 20 root_fs_67 n 1 0 22 root_fs_78 n 1 0 24 root_fs_89 n 1 0 26 root_fs_910 n 1 0 28 root_fs_1011 n 1 0 30 root_fs_1112 n 1 0 32 root_fs_1213 n 1 0 34 root_fs_1314 n 1 0 36 root_fs_1415 n 1 0 38 root_fs_1516 y 1 0 40 root_fs_common 4,2,3,117 n 5 0 73 root_fs_ufslog18 n 5 0 76 root_panic_reserve19 n 5 0 77 root_fs_d320 n 5 0 78 root_fs_d421 n 5 0 79 root_fs_d522 n 5 0 80 root_fs_d627 y 1 0 202 ufs1 129 y 1 0 205 ufs2 130 y 1 0 207 ufs3 131 y 1 0 209 ufs4 132 n 1 0 211 ufs533 n 1 0 213 ufs634 y 1 0 217 ufslocal1 336 y 1 0 220 ufslocal2 340 y 1 0 230 ufslocal3 3

Step Action



Ensure access after failover

If you have not accounted for different IP subnets at the source and destination sites, perform these steps, either manually, or by creating and running a script, after MirrorView/S activation to ensure access to the same file systems by using the same network addresses as on the source site, provided network access to the destination site VNX for file exists.

8. Get a list of the disks available after the failover activation by typing:# nas_disk -list

Output:

id inuse sizeMB storageID-devID type name servers1 y 11263 APM00042000817-0006 CMSTD root_disk 1,2,3,42 y 11263 APM00042000817-0007 CMSTD root_ldisk 1,2,3,43 y 2047 APM00041700549-0002 CLSTD d3 1,2,3,44 y 2047 APM00041700549-0003 CLSTD d4 1,2,3,45 y 2047 APM00042000817-0009 CMSTD d5 1,2,3,46 y 2047 APM00041700549-0005 CLSTD d6 1,2,3,47 y 549623 APM00041700549-0010 CLSTD d7 1,3,4,28 y 549623 APM00042000817-0012 CMSTD d8 1,3,4,29 y 549623 APM00042000817-0014 CMSTD d9 1,3,4,210 y 549623 APM00042000817-0016 CMSTD d10 1,3,4,211 y 549623 APM00041700549-0011 CLSTD d11 1,3,4,212 y 549623 APM00042000817-0013 CMSTD d12 1,3,4,213 y 549623 APM00042000817-0015 CMSTD d13 1,3,4,214 y 549623 APM00042000817-0017 CMSTD d14 1,3,4,215 n 608270 APM00041700549-0018 CLATA d15 2,1,3,416 n 608270 APM00041700549-0019 CLATA d16 2,1,3,417 n 608270 APM00041700549-001C CLATA d17 2,1,3,418 n 608270 APM00041700549-001D CLATA d18 2,1,3,419 n 608270 APM00041700549-001A CLATA d19 2,1,3,420 n 608270 APM00041700549-001B CLATA d20 2,1,3,4

Note: The mirrored disks have the disk type CMSTD.

Step Action

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

If you perform these steps at the destination after a failover, perform these steps again at the source after a restore to return everything to the original configuration.


Restore the source VNX for file (active/passive)

Restoring the source VNX for file involves restoring full connectivity to the file systems on the source VNX for file. The tasks to restore the source VNX for file are:

◆ "Prepare for the restore (active/passive)" on page 65

◆ "Restore the source VNX for file from the destination (active/passive)" on page 66

◆ "Verify operations after a restore (active/passive)" on page 69

Prerequisites

Restoration of the source VNX for file includes two phases:

◆ The storage restoration phase provides network access to the destination VNX for file while the destination and source VNX for block systems synchronize. The length of the synchronization is based on the amount of data that has been updated since the destination system was activated.

◆ The network restoration phase suspends network clients from file system access. Note that with active write I/O it could take some time to perform the synchronization.


Prepare for the restore (active/passive)

Under the guidance of your local EMC Service Provider or EMC Customer Service, prepare for the restore before proceeding with the restore procedures on the destination VNX for file (new_jersey).

Step Action

1. Request a complete system check of the VNX for block storage system and MirrorView/S. This is required to verify proper MirrorView/S operations.

CAUTION!If this is a true disaster scenario, keep the source VNX for file (new_york) and its VNX for block storage system powered off until you are instructed to power them up by your local EMC Service Provider or EMC Customer Service.

2. Power up the VNX for block storage system after you have been told that it is safe to proceed, and then continue with the restore procedure on the destination VNX for file.

CAUTION!Do not attempt to restart the source VNX for file (new_york).



Restore the source VNX for file from the destination (active/passive)

Use the remote administration account (dradmin) on the destination VNX for file to restore the source VNX for file.

Step Action

1. Log in to the destination VNX for file (new_jersey) as dradmin and switch (su) to root.

2. Start the restoration of the source VNX for file by typing: # /nas/sbin/nas_mview -restore

Note: Use the absolute path. If you do not use the absolute path, the command fails with a general command error. If the command fails, rerun the command with the absolute path. Also, ensure that no VNX for file command is running and using dradmin when the /nas/sbin/nas_mview -restore command is running. During the restore, do not shut down or reboot any Data Movers.

3. At the prompt, proceed with the restoration after confirmation from your local EMC Service Provider or EMC Customer Service by typing yes.

This step performs a synchronization of the VNX for file’s view of the backend with the actual backend, validates the device group configuration, and then requests a shutdown of the source.

If you type no, the restore aborts with an informational message.




Running restore requires shutting down source site new_york.Do you wish to continue? [yes or no] yes

Shutting down remote site new_york ....... done


4. At the prompt, continue with the restoration after your local EMC Service Provider or EMC Customer Service has helped to verify that the source VNX for block system and MirrorView/S LUNs are ready (operational) by typing yes.

Example:Is source site new_york ready for storage restoration ? [yes or no] yes

CAUTION!The source VNX for block storage system and the MirrorView/S link must be operational. At this point, do not restart the source VNX for file.

Note: Next, synchronization with the VNX for block storage system is performed. After the synchronization, the resume operation begins. As part of this process, the device group (cg_new_york) is synchronized and updated. The file systems and shares are still available to the network clients until the storage system synchronization nears completion.

Sync with CLARiiON backend ...... done STARTING an MV 'RESUME' operation. Device group: cg_new_york ............ done The MV 'RESUME' operation SUCCEEDED.

Synchronized: 100% (**************************************************) Updating device group ... done

Note: Under certain conditions, LUNs might not be in the proper state to fail back, in which case the storage system synchronization does not complete and the restore command exits. If this occurs, "Resolve restore failures" on page 133 provides information. If necessary, contact your local EMC Service Provider or EMC Customer Service for assistance.

Step Action



5. At the prompt, proceed with the restoration after you ensure the source VNX for file is powered on and its Control Station (CS0) is operational and on the data network by typing yes.

Note: Make sure that CS1 is halted.

Example:

Is source site ready for network restoration ? [yes or no] yes

Note: At this point, the standby Data Movers are halted and the destination file systems and shares become unavailable to network clients for a certain amount of time, depending on the total amount of mirrored data. The destination devices are set to read-only while the source and destination VNX for block systems fully synchronize.

Restoring local servers ...... done Waiting for local servers to reboot ...... done

Removing NBS access from local server server_2 .. done Removing NBS access from local server server_3 .. done Waiting for device group ready to failback ... done


Note: Next, the device-group failback occurs. If it is successful, the source site again becomes the production site.

STARTING an MV 'FAILBACK' operation. Device group: cg_new_york ............ done The MV 'FAILBACK' operation SUCCEEDED.

Note: The remainder of the restore can take up to 15 minutes, depending on the Data Mover configuration. The source site system and Data Movers are rebooted and restored.

Restoring remote site new_york, please wait... done

done

Note: The network restoration phase is over and the restore is complete.


exit

7. Exit dradmin by typing:$ exit

logout

Note

After the restore process completes, wait 5–10 minutes for CS0 to come back up before logging in to the source VNX for file (new_york) and managing it directly from the source nasadmin account. If you have a dual Control Station environment, keep CS1 powered off after the restore. Also, if a Data Mover was replaced after a failover activation at the destination, the setup procedure performed for the hardware at the destination must also be performed at the source site after the restore process completes by your local EMC Service Provider or EMC Customer Service, as described in EMC Knowledgebase emc139199. "Resolve restore failures" on page 133 describes error scenarios that might occur during the restore process. If you have problems with the restored system, contact your EMC Service Provider or EMC Customer Service.

Step Action


Verify operations after a restore (active/passive)

Step Action


2. Verify that the device group on the source VNX for file has returned to the primary role after the restore by using this command syntax:# nas_devicegroup -info {<name>|id=<id>}

where:<name> = name of the device group<id> = ID assigned to the device group

Example:

To verify that the device group on new_york has returned to the primary role after the restore, type:$ nas_devicegroup -info cg_new_york

Sync with CLARiiON backend ...... donename = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:90:60:7:30:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d8,d9,d10,d12,d13,d14,local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local -> remote



3. Display information about the file systems associated with Data Movers on restored new_york by typing:$ /nas/bin/server_df ALL

Output:


server_3 :Error 2: server_3 : No such file or directoryfailed to complete commandserver_4 :Filesystem kbytes used avail capacity Mounted onroot_fs_common 13624 5256 8368 39% /.etc_commonufslocal3 206515184 576 206514608 0% /ufslocal3ufslocal2 413030384 576 413029808 0% /ufslocal2ufslocal1 413030384 576 413029808 0% /ufslocal1root_fs_4 114592 712 113880 1% /


Note: No information is reported for the standby Data Movers as nasadmin. Information is only reported for the two source Data Movers; server_2 is MirrorView-protected.

Step Action


Configure MirrorView/S (active/active’)

The tasks to configure active/active’ MirrorView/S are:

1. "Preinitialize the configuration (active/passive)" on page 40

2. "Initialize the configuration (active/active’)" on page 71

3. "Activate a failover (active/active')" on page 87

4. "Activate a failover from one destination VNX for file" on page 88

5. "Verify active/active’ operations after activation" on page 91

6. "Restore the source VNX for file (active/active’)" on page 92

7. "Restore the source VNX for file (active/active’)" on page 92

Initialize the configuration (active/active’)

Initializing an active/active’ configuration, which is bidirectional, involves initializing the source and destination systems. The initialization tasks are performed by your local EMC Service Provider.

The tasks to initialize the configuration are:

◆ "(Optional) Verify remote administration account" on page 73

◆ "Initialize one VNX for file (active/active’)" on page 75

◆ "Initialize the second VNX for file (active/active’)" on page 79

◆ "Verify the active/active’ configuration" on page 84

Prerequisites

◆ VNX for file software must be installed on the source and destination VNX for file systems.

◆ MirrorView/S link must be operational between the source and destination VNX for file systems.

◆ The requirements summarized in "Planning considerations" on page 26 must be met to ensure that the VNX for block systems and VNX for file Data Movers are set up correctly.

◆ If there is a default local standby, evaluate which standby relationships are needed for the MirrorView/S configuration. For example, in a four-Data Mover configuration, where server_5 is the default local standby, remove the local standby relationship on new_york between server_5 and server_4 and set the server_5 type to nas. To remove the standby relationship, use the server_standby command, as described in "VNX Data Mover configuration checklist" on page 32. If you need to change the Data Mover type from standby to regular, use the server_setup command.

◆ Before running /nas/sbin/nas_mview -init to select an active Data Mover as a remote standby Data Mover, clean up any part of the configuration, such as the network configuration that no longer applies to that Data Mover.



◆ If you have a dual Control Station environment, halt CS1 before the initialization. You can perform MirrorView/S operations by using CS0 only. VNX System Operations describes how to halt a Control Station. After halting CS1, verify the halt by typing the /nas/sbin/getreason command, and checking for the line “0 - slot_1 powered off” in the output.

◆ Make sure that you have the global VNX for block account password established for the VNX for block storage system. This account must be associated with VNX for block Manager or higher privileges to manage all storage-system settings in the domain.

Note: If the existing global VNX for block account password that you specify as part of the initialization procedure changes, but the VNX for file storage information has not been updated, you get an error. Step 4 of "Initialize from the destination VNX for file (active/passive)" on page 45 shows an example of setting the password. After initialization is complete, you can capture the change by rerunning the /nas/sbin/nas_mview -init command. However, after a failover, you must use the nas_storage command with the modify option to update the VNX for file storage security information on the Control Station. "Modify VNX for block security information after a failover" on page 114 provides more information.

◆ In an active/active’ configuration, ensure that a different UID for a remote administration account user (for example, dradmin) is used for each MirrorView/S direction. "VNX for file remote administration account recommendations" on page 28 provides the steps needed to perform this task.

◆ To avoid any path errors, always log in as nasadmin, switch (su) to root, and then run the nas_mview -init command from /nas/sbin.

Note: When using su, make sure that you follow the steps in the procedure exactly. Do not use su unless explicitly instructed.

◆ Initialization fails if errors, such as missing MirrorView/S device group configuration, remote mirror name, or ID are detected on the VNX for block storage array. "Resolve initialization failures" on page 122 describes failure scenarios associated with initialization.

◆ If the IP address of a Control Station changes after initialization, rerun the /nas/sbin/nas_mview -init command. If any hostnames or IP addresses change, edit and update the /etc/hosts file and ensure that each host can resolve its node name. Rerun the /nas/sbin/nas_mview -init command after any storage configuration change that affects any of the mirrors, storage groups, or device groups used by VNX for file.


◆ Verify the active/active’ Data Mover configuration. Table 12 on page 73 shows the four-Data Mover configuration used in this section.

In this configuration:

• Initialization is performed on new_york, where new_york serves as the destination for source new_jersey. Data Movers server_4 and server_5 on source new_jersey have MirrorView/S standbys server_4 and server_5 on new_york. Here, server_5 on new_jersey is also a local standby for server_4. Device group cg_new_jersey is created on both VNX for file systems.

• Initialization is performed on new_jersey, where new_jersey serves as the destination for source new_york. Data Movers server_2 and server_3 on source VNX for file new_york have MirrorView/S standbys server_2 and server_3 on new_jersey. Device group cg_new_york is created on both VNX for file systems.

Note: For the purpose of example, assume that this active/active’ configuration is newly configured, not changed from an active/passive configuration.

(Optional) Verify remote administration account

Ensure that a different user ID (UID) for a remote administration account user (dradmin) is used for each MirrorView/S direction. Having different UIDs for the remote administration account user in each direction in the active/active’ configuration ensures that the correct Data Mover (server) information is always displayed for the appropriate VNX for file command when a failover is activated.

Prerequisites:

◆ If the user ID for a MirrorView/S remote administration account (for example, dradmin) user in both directions is the same, delete the user ID and then the remote administration account on one Control Station (not both).

Table 12 Sample active/active’ Data Mover configuration

new_york Data Mover Direction new_jersey Data Mover

server_2

(source Data Mover)

---------------------> server_2

(remote standby for source Data Mover on new_york)

server_3


--------------------> server_3

(remote standby for new_york source Data Mover’s local standby)

server_4

(remote standby for source Data Mover on new_jersey)

<-------------------- server_4

(source Data Mover)

server_5

(remote standby for new_jersey source Data Mover’s local standby)

<-------------------- server_5




◆ To list the user ID, use the nas_acl -list command. You do not need root privileges to list information, but you do need root privileges to delete the ID.

◆ For a new installation, perform steps 3 and 5 only. If the same UID is already used for a dradmin user in both MirrorView/S directions, perform steps 1–5.

Step Action

1. Delete the user ID associated with the remote administration account (for example, 500) from one Control Station by using this command syntax: # nas_acl -delete -user <numerical_id>

where:<numerical_id> = user ID of the remote administration account to delete

Example:

To delete a user with ID 500, type:# nas_acl -delete -user 500

2. Delete the remote administration account on one Control Station (not both) by using this path and Linux userdel command syntax: # /usr/sbin/userdel <login_account_name>

where:<login_account_name> = name of the remote administration account to delete

Note: The Linux man pages on the Control Station provide the complete Linux syntax.

Example:

To delete the remote administration account dradmin, type:# /usr/sbin/userdel -r dradmin

3. Create a ghost account on one Control Station for the sole purpose of ensuring that a unique user ID is selected for a remote administration account user in each MirrorView/S direction, assigning a UID that matches the UID of the remote administration account on the other Control Station, which guarantees that another UID is selected upon initialization by using this path and Linux useradd command syntax: # /usr/sbin/useradd <login_ghost_user_name> -u <uid>

where:<login_ghost_user_name> = name of the ghost remote administration account<uid> = user ID of the remote administration account on the other Control Station

Example:

To create a ghost account with a unique user ID, type:

# /usr/sbin/useradd dradmin_ghost -u 500


Password:

5. Delete the relationship with the remote VNX for file by using this command syntax:# nas_cel -delete <cel_name>

where:<cel_name> = current name of the remote VNX for file in the configuration

Example:

To delete the relationship with the remote VNX for file, type:# nas_cel -delete new_jersey


Initialize one VNX for file (active/active’)

Initialize one of the VNX for file systems (new_york) that serve as a destination in the active/active’ configuration.

6. Recreate the relationship with the remote VNX for file by using this command syntax:# nas_cel -create <cel_name> -ip <ip> -passphrase <passphrase>

where:<ip> = current IP address of the remote Control Station in slot 0 (CS0)<passphrase> = current 6–15 character password

Example:

To recreate the relationship with the remote VNX for file, type:# nas_cel -create new_jersey -ip 192.168.96.87 -passphrase nasadmin

Note: Make sure you use the current VNX for file name, IP address, and passphrase configuration when the relationship is reestablished.

Note

After the relationship between the VNX for file systems is established by nas_cel as described in "Preinitialize the configuration (active/passive)" on page 40, run /nas/sbin/nas_mview -init, following the instructions in "Initialize the configuration (active/active’)" on page 71. This ensures that the unique user IDs can be selected for each remote administration account user during MirrorView initialization.

Step Action

1. Log in to the VNX for file (new_york) that is to serve as a destination as nasadmin and switch (su) to root.

2. Start the active/active’ initialization process and identify the other VNX for file by using this command syntax: # /nas/sbin/nas_mview -init <cel_name>

where:<cel_name> = name of a source VNX for file

Example:

To initialize new_jersey as the source site to communicate with new_york, type:# /nas/sbin/nas_mview -init new_jersey

Output:


Initializing new_jersey --> new_york

Contacting new_jersey for remote storage info


Step Action



3. At the prompt, type the global VNX for block account (nasadmin) information (username and password) established during VNX for block storage system configuration.


Example:


Discovering storage on new_jersey (may take several minutes)Setting security information for APM00041700549Discovering storage APM00042000817 (may take several minutes


Contacting new_jersey for remote storage info Gathering server information...Contacting new_jersey for server capabilities...Analyzing server information...

Note: The initialization process queries information from both systems and can determine if the underlying storage configuration supports an active/active’ configuration. If the storage configuration is set up for active/passive from new_york to new_jersey, a message reports that the initialization must be run from the new_jersey Control Station.

Step Action


4. At the prompt, configure each source Data Mover that is to be MirrorView-protected with a remote standby Data Mover. To specify the Data Mover relationships, type the appropriate selection:






ineligible for a remote disaster recovery configuration. In this case, the Data Mover is not selectable, and is not eligible for remote DR message appears in brackets after the server name, as shown in "Ensure Data Mover eligibility" on page 106.



Example:

Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_jersey 2. server_3:new_jersey 3. server_4:new_jersey 4. server_5:new_jersey [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_jersey server: 3

Destination servers available to act as remote standby--------------------------------------------------1. server_2:new_york server_3:new_york [ local standby ]3. server_4:new_york 4. server_5:new_york b. BackSelect a new_york server: 3

Step Action



Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_jersey 2. server_3:new_jersey 3. server_4:new_jersey [ remote standby is server_4:new_york ]4. server_5:new_jersey [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_jersey server: 4

Destination servers available to act as remote standby--------------------------------------------------1. server_2:new_york server_3:new_york [ local standby ] server_4:new_york [ is remote standby is server_4:new_jersey ]4. server_5:new_york b. BackSelect a new_york server: 4

Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_jersey 2. server_3:new_jersey 3. server_4:new_jersey [ remote standby is server_4:new_york ]4. server_5:new_jersey [ remote standby is server_5:new_york ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_jersey server: c


5. At the prompt, create the remote administration account (dradmin) to manage the remote (new_jersey) site.

Example: Enter user information for managing remote site new_jerseyUsername: dradmin Password: ********* Retype your response to validatePassword: *********

Note: Keep track of the username and password. You need to specify them when you activate a failover. The remote administration account passwords are different on each VNX for file in an active/active’ configuration. This is a Linux-governed password on the Control Station and is covered in the Linux man pages for account passwords, such as man passwd.

Step Action


Initialize the second VNX for file (active/active’)

Initialize the other VNX for file (new_jersey) that serves as a destination.

6. At the prompt, continue with the initialization when the initialization sequence begins by typing yes.

Note: If you type no, the initialization aborts with an informational message.

Example:

Active/Active configurationInitializing (new_jersey-->new_york)Do you wish to continue? [yes or no] yes

Updating MirrorView configuration cacheSetting up server_5 on new_jersey Rebooting server_5 on new_york as standby ... doneSetting up server_4 on new_jersey Rebooting server_4 on new_york as standby ... doneCreating user account dradmin Setting acl for server_5 on new_york Setting acl for server_4 on new_york Updating the Celerra domain information Creating device group cg_new_jersey on new_york Creating device group cg_new_jersey on new_jersey done


exit

Step Action

1. Log in to the VNX for file (new_jersey) that is the destination for the other source VNX for file, as nasadmin and switch (su) to root.

2. Start the active/active’ initialization process and identify the other VNX for file by using this command syntax: # /nas/sbin/nas_mview -init <cel_name> where:<cel_name> = name of the other source VNX for file

Example:

To make the configuration bidirectional and initialize new_york as the source site for destination site new_jersey, type:# /nas/sbin/nas_mview -init new_york

Output:





Step Action



3. If you are prompted, enter the global VNX for block account (nasadmin) information (username and password) established during VNX for block storage system configuration.


Note: If you are adapting an original active/passive storage system setup to add active/active’, instead of configuring the entire active/active’ storage system setup at one time, you are not prompted for the global VNX for block account information, and you can skip to the next step.

Example:




Contacting new_york for remote storage infoGathering server information... Contacting new_york for server capabilities...Analyzing server information...

Note: The initialization process can determine if the underlying storage configuration supports an active/active’ configuration. If the storage is set up for active/passive instead, a message reports that initialization must be run from the expected destination Control Station.

Step Action


4. At the prompt, configure each source Data Mover that is to be MirrorView-protected with a remote standby Data Mover. To specify the Data Mover relationships, type the appropriate selection:






ineligible for a remote disaster recovery configuration. In this case, the Data Mover is not selectable, and is not eligible for remote DR message appears in brackets after the server name, as shown in "Ensure Data Mover eligibility" on page 106.



Example:

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york2. server_3:new_york [ local standby ] server_4:new_york [ is remote standby for server_4:new_jersey ] server_5:new_york [ is remote standby for server_5:new_jersey ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 1

Step Action



Destination servers available to act as remote standby--------------------------------------------------1. server_2:new_jersey2. server_3:new_jersey server_4:new_jersey [ remote standby is server_4:new_york ] server_5:new_jersey [ remote standby is server_5:new_york ]b. BackSelect a new_jersey server: 1

Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ local standby ] server_4:new_york [ is remote standby for server_4:new_jersey ] server_5:new_york [ is remote standby for server_5:new_jersey ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 2

Destination servers available to act as remote standby-------------------------------------------------- server_2:new_jersey [ is remote standby for server_2:new_york ]2. server_3:new_jersey server_4:new_jersey [ remote standby is server_4:new_york ] server_5:new_jersey [ remote standby is server_5:new_york ]b. BackSelect a new_jersey server: 2

Source servers available to be configured for remote DR----------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ remote standby is server_3:new_jersey ] server_4:new_jersey [ remote standby is server_4:new_york ] server_5:new_jersey [ remote standby is server_5:new_york ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: c


5. At the prompt, create the remote administration account (dradmin) to manage the remote (new_york) site.

Example: Enter user information for managing remote site new_yorkUsername: dradmin Password: ********* Retype your response to validatePassword: *********

Note: Keep track of the username and password. You need to specify them when you activate a failover. The remote administration account passwords are different on each VNX for file in an active/active’ configuration.This is a Linux-governed password on the Control Station and is covered in the Linux man pages for account passwords, such as man passwd.

Step Action


6. At the prompt, continue with the initialization when the initialization sequence begins by typing yes.

Note: If you type no, the initialization aborts with an informational message. Note that both systems are informed about the device group creation.

Example:

Active/Active configurationInitializing (new_york --> new_jersey)


Updating MirrorView configuration cache Setting up server_3 on new_york Rebooting server_3 on new_jersey as standby ... doneSetting up server_2 on new_york Rebooting server_2 on new_jersey as standby ... doneCreating user account dradmin Setting acl for server_3 on new_jersey Setting acl for server_2 on jersey Updating the Celerra domain informationCreating device group cg_new_york on new_jerseyCreating device group cg_new_york on new_yorkdone

Note: The active/active’ configuration process is complete.

Note

Prior to a failover, any storage system configuration changes affecting the initialized configuration can be captured by rerunning /nas/sbin/nas_mview -init.

Step Action



Verify the active/active’ configuration

You can verify active/active’ MirrorView/S after initialization on either VNX for file in the configuration.

Step Action

1. Log in to one of the VNX for file systems (new_jersey) as nasadmin and switch (su) to root.

2. List all information for all Data Movers by typing: # nas_server -info -all

Note: The output indicates which Data Movers are owned by dradmin and serve as remote standbys (in the acl= field and the type= field), as well as which Data Movers have remote standbys (in the RDFstandby= field). The output also identifies a Data Mover that has a local standby (standby=), and a Data Mover that serves as a local standby (standbyfor=). The standbyfor= has a value only if a Data Mover serves as a local standby.

id = 1name = server_2acl = 2000, owner=dradmin, ID=500type = standbyslot = 2member_of = standbyfor= status : defined = enabled actual = online, ready


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

id = 4name = server_5acl = 1000, owner=nasadmin, ID=201type = standbyslot = 5member_of = standbyfor= server_4RDFstandby= slot=5status : defined = enabled actual = online, ready


3. List all Data Movers, including the ones owned by dradmin as remote standbys by typing:# nas_server -list

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

Note: If you run the command as nasadmin, only server_4 and server_5 would appear in the list. server_2 and server_3 are not available to the nasadmin account because they are now managed by the dradmin account.

4. List the device groups on the VNX for file by typing: # nas_devicegroup -list

Output:

ID name owner storage ID acl type1 cg_new_york 500 APM00042000817 0 MVIEW2 cg_new_jersey 0 APM00042000817 0 MVIEW

5. List all information for both device groups by typing: # nas_devicegroup -info -all

Output:


name = cg_new_york description = uid = 50:6:1:60:B0:60:21:ED:0:0:0:0:0:0:0:0state = Consistentrole = Secondarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 500mirrored disks = local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local <- remote

name = cg_new_jerseydescription = uid = 50:6:1:60:B0:60:21:ED:1:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d73,d74,d79,d80,d81,d82,local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local -> remote

Note: In this example, new_york has two device groups, one for which it is the source, and one for which it is the destination. The entry for cg_new_york identifies the role as Primary and provides the list of mirrored disks. The entry for cg_new_jersey identifies the role as Secondary and does not provide the list of mirrored disks.

Step Action



6. Get information about the MirrorView/S configuration from new_jersey by typing: # /nas/sbin/nas_mview -info

Output:


name = cg_new_jerseydescription = uid = 50:6:1:60:B0:60:21:ED:1:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 9mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d73,d74,d79,d80,d81,d82,local clarid = APM00042000817remote clarid = APM00041700549mirror direction = local -> remote


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

id = 4

name = server_5acl = 1000, owner=nasadmin, ID=201type = standbyslot = 5member_of = standbyfor= server_4,server_3RDFstandby= slot=5status : defined = enabled actual = online, ready

Step Action


Activate a failover (active/active')

You activate a MirrorView/S failover in an active/active’ configuration from one of the VNX for file systems. In this example, the failover is performed on new_jersey, which serves as the destination for the source VNX for file (new_york). Therefore, the failover places new_jersey in the active role.

The tasks to activate an active/active’ MirrorView/S failover are:

◆ "Activate a failover from one destination VNX for file" on page 88

◆ "Verify active/active’ operations after activation" on page 91

Prerequisites

◆ After a failover has been activated, do not make any storage system configuration changes.

◆ Prior to a failover, storage system configuration changes affecting the initialized configuration can be captured by rerunning the /nas/sbin/nas_mview -init command. A change to the existing global VNX for block password requires an update of the VNX for file storage security information on the Control Station. After initialization is complete, this change can be captured by rerunning the /nas/sbin/nas_mview -init command. However, after a failover, you must use the nas_storage command with the -modify option. "Modify VNX for block security information after a failover" on page 114 provides more information.





Step Action



Activate a failover from one destination VNX for file

Activate the failover from a destination VNX for file by using the remote administration account (dradmin). In an unplanned failover scenario, one of the source VNX for file systems (new_york) attached to a remote VNX for block system is assumed to have become unavailable and requires a failover to its destination VNX for file (new_jersey).

To activate a test failover when no real disaster scenario exists, use the following guidelines, based on whether the goal is to perform a graceful failover or to simulate a true disaster scenario.

◆ To simply perform a graceful test failover, do the following before activating the failover:

• Make sure the MirrorView links and the IP data network connections between Control Stations are up. You can also keep the source VNX for file powered up during the activation.

• Check your device group information to verify that the group condition is in the appropriate state for the failover activation. The condition should be Active and the state should be Synchronized or Consistent.

Note: If you activate a test failover with the links down, or the device group is not in a proper state to activate a failover, a full synchronization is performed automatically during the restore to reconstruct the device group and mirrors, which is time-consuming and undesirable for a test scenario. If you activate the failover when the device group is not in the proper state to fail over, a warning message appears. In this case, abort the failover activation, make sure the device group is resynchronized, and then retry the failover activation. "Resolve activation failures" on page 125 provides a sample of this warning message.

◆ Verify that the data at the destination is in a proper state before activating the failover. If not, the data might be in an unknown condition, requiring one or more file system checks by using fsck as well as a full synchronization.

◆ If you are without IP connectivity between the Control Stations prior to the failover activation, you can manually shut down the source Data Movers by using the /nas/sbin/nas_halt now command. VNX System Operations addresses the nas_halt command and the platform-specific recommendations for components during shutdown procedures.

◆ After a test failover activation, you should reboot the source-site Control Station.

◆ You must have a valid MirrorView/S configuration with a remote standby configured before you activate a failover.

◆ If any VNX for block storage system configuration changes have been made after initial configuration, these changes should be reflected by the VNX for file configuration prior to a failover activation. Although the MirrorView/S consistency group name should not be changed on the VNX for block storage system, if it is, then your local EMC Service Provider or EMC Customer Service must perform the procedure described in the EMC Knowledgebase article emc138372 to correct the VNX for file device group configuration before a failover can be successfully activated.


!CAUTION!For sites with redundant Control Stations, ensure that all MirrorView management commands, including /nas/sbin/nas_mview -init, -activate, and -restore, are run from CS0. Ensure that CS1 is halted at both sites before you run the activate or restore commands. VNX System Operations describes how to halt a Control Station. After halting CS1, verify the halt by typing the /nas/sbin/getreason command, and checking for the line “0 - slot_1 powered off” in the output.

Step Action

1. Log in to the destination VNX for file (new_jersey) from which you must perform a failover as dradmin.

Note: The password you supply is the same one specified during initialization, as shown in "Initialize the second VNX for file (active/active’)" on page 79.


Password:

3. Activate the failover from the source VNX for file to the destination VNX for file by typing:# /nas/sbin/nas_mview -activate

Note: This initiates synchronization with the VNX for block storage system.

Output:


Note: As part of this process, all Data Movers at the source are halted. At the destination, do not shut down or reboot any Data Movers during a failover activation or a restore. "Resolve activation failures" on page 125 provides more information about errors that can occur during a failover.



4. At the prompt, continue with the activation process after verifying the source VNX for file is ready for shutdown by typing yes.

Note: If you type no, the activation aborts with an informational message.


Example:

Is source site new_york ready for complete shut down (power OFF)? [yes or no] yes

Contacting source site new_york, please wait... doneShutting down remote site new_york ......................... done

Sync with CLARiiON backend ...... doneNext, the failover begins. Activating the destination Celerra write-enables the destination LUNs and write-disables the source LUNs, provided that MirrorView/S and the source CLARiiON system are operational. STARTING an MV 'FAILOVER' operation.Device group: cg_new_york ............ doneThe MV 'FAILOVER' operation SUCCEEDED.

Failing over Devices ... done

Adding NBS access to local server server_2 ....... done Adding NBS access to local server server_3 ....... done Adding NBS access to local server server_4 ....... done Adding NBS access to local server server_5 ....... done Activating the target environment ... done

Note: At this point, the MirrorView/S remote standby Data Movers become active.

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

server_3 : going offline rdf : going active replace in progress ...done failover activity complete commit in progress (not interruptible)...done commit in progress (not interruptible)...done commit in progress (not interruptible)...done commit in progress (not interruptible)...done

done

Note: The activation is now complete.


exit

Note

After a failover has been activated, do not perform any storage system configuration changes. In the event of a true disaster where the source VNX for block is unavailable, contact your local EMC Customer Support Representative to coordinate restoration activities.

Step Action


Verify active/active’ operations after activation

Step Action


2. Display detailed information for the Data Movers by typing:# nas_server -info -all

Note: This step can be done as nasadmin or root.

Output:

id = 1name = server_2acl = 0type = nasslot = 2member_of = standby = server_3, policy=autoRDFstandby= slot=2status : defined = enabled actual = online, ready

id = 2name = server_3acl = 0type = standbyslot = 3member_of = standbyfor= server_2RDFstandby= slot=3status : defined = enabled actual = online, ready

id = 3name = server_4acl = 2000, owner=rdf, ID=500type = standbyslot = 4member_of = standbyfor= status : defined = enabled actual = online, ready

id = 4name = server_5acl = 2000, owner=rdf, ID=500type = standbyslot = 5member_of = standbyfor= status : defined = enabled actual = online, ready



Restore the source VNX for file (active/active’)

Restoring the source VNX for file involves restoring full connectivity to the file systems on the source VNX for file.

Prerequisites

Restoration of the source VNX for file includes two phases:

◆ The storage restoration phase provides network access to the destination VNX for file while the destination and source VNX for block systems synchronize. The length of the synchronization is based on the amount of data that has been updated since the destination system was activated.

◆ The network restoration phase suspends network clients from file system access. Note that with active write I/O it could take some time to perform the synchronization.

The tasks to restore the source VNX for file are:

◆ "Prepare for the restore (active/active’)" on page 93

◆ "Restore one source VNX for file from its destination (active/active’)" on page 93

Note: It is strongly recommended that your EMC Service Provider performs a test failover and restore as part of the initial MirrorView/S setup and verification process.

3. Display information about the activated MirrorView/S standby Data Movers on new_jersey by typing:# server_df ALL

Output:

server_2 : Filesystem kbytes used avail capacity Mounted onroot_fs_common 13624 5256 8368 39% /.etc_commonroot_fs_2 114592 728 113864 1% /

server_3 : Error 2: server_3 : No such file or directoryfailed to complete commandserver_4 : Filesystem kbytes used avail capacity Mounted onroot_fs_common 13624 5256 8368 39% /.etc_commonroot_fs_4 114592 688 113904 1% /

server_5 : Error 2: server_5 : No such file or directoryfailed to complete command

Note: From dradmin, no information is reported for local standbys. For example, server_3, which is a local standby.

Step Action


Prepare for the restore (active/active’)

Under the guidance of your EMC Customer Support Representative, prepare for the restore before proceeding with the restore procedures on the destination VNX for file (new_jersey).

Restore one source VNX for file from its destination (active/active’)

Use the remote administration account (dradmin) on the destination VNX for file (new_jersey) to restore the source VNX for file.

Step Action

1. Request a complete system check of the VNX for block system and MirrorView/S. This is required to verify proper MirrorView/S operations.

CAUTION!If this is a true disaster scenario, keep the source VNX for file (new_york) and its VNX for block storage system powered off until you are instructed to power them up by your EMC Customer Support Representative.

2. Power up the VNX for block storage system after you have been told that it is safe to proceed, and then continue with the restore procedure on the destination VNX for file.

CAUTION!Do not attempt to restart the source VNX for file (new_york).

Step Action

1. Log in to the destination VNX for file (new_jersey) as dradmin and switch (su) to root.

2. Start the restoration of the source VNX for file from the destination VNX for file by typing:# /nas/sbin/nas_mview -restore

Note: Use the absolute path. If you do not use the absolute path, the command fails with a general command error. If the command fails, rerun the command with the absolute path. Also, ensure that no VNX for file command is running and using dradmin when the /nas/sbin/nas_mview -restore command is running. During the restore, do not shut down or reboot any Data Movers.



3. At the prompt, shut down the source after ensuring that the synchronization is successful and after your local EMC Customer Support Representative has verified that you can proceed with a restore. Shut down the source-site VNX for file by typing yes.

Note: If you type no, the restore aborts with an informational message.

This step performs a synchronization of the VNX for file’s view of the storage system with the actual storage system, validates the device group configuration, and then requests a shutdown of the source.






4. At the prompt, continue with the restoration after your local EMC Customer Support Representative has helped verify that the source VNX for block system and MirrorView/S LUNs are ready (operational) by typing yes.

Example:

Is source site new_york ready for storage restoration ? [yes or no] yes

CAUTION!The source VNX for block storage system and the MirrorView/S link must be operational. At this point, do not restart the source VNX for file.

Note: Next, synchronization with the VNX for block storage system is performed. After the synchronization, a resume operation begins. As part of this process, the device group (cg_new_york) is synchronized and updated. The file systems and shares are still available to the network clients until the storage system synchronization nears completion.

Sync with CLARiiON backend ...... done STARTING an MV 'RESUME' operation. Device group: cg_new_york ............ done The MV 'RESUME' operation SUCCEEDED.


Note: Under certain conditions, LUNs might not be in the proper state to fail back, in which case the storage system synchronization does not complete and the restore command exits. If this occurs, "Resolve restore failures" on page 133 provides more information. If necessary, contact your local EMC Service Provider or EMC Customer Support Representative for assistance.

Step Action


5. At the prompt, proceed with the restoration after you ensure the source VNX for file is powered on and its Control Station (CS0) is operational and on the data network by typing yes.

Note: Make sure that CS1 is halted.

Example:

Is source site ready for network restoration ? [yes or no] yes

Note: At this point, the standby Data Movers are halted and the destination file systems and shares become unavailable to network clients for a certain amount of time, depending on the total amount of mirrored data. The destination devices are set read-only while the source and destination VNX for block systems fully synchronize.


Removing NBS access from local server server_2 .. done Removing NBS access from local server server_3 .. done Removing NBS access from local server server_4 .. done Removing NBS access from local server server_5 .. done

Waiting for device group ready to failback ... done


Note: Next, the device-group failback occurs. If it is successful, the source site again becomes the production site.


Note: The remainder of the restore can take up to 15 minutes, depending on the Data Mover configuration. The source site system and Data Movers are rebooted and restored.

Restoring remote site new_york, please wait... done

done

Note: The network restoration phase is over and the restore is complete.

6. Exit root by typing:# exitexit

7. Exit rdfadmin by typing:$ exitlogout

Step Action



Note

After the restore process completes, wait 5–10 minutes for CS0 to come back up before logging in to the source VNX for file (new_york) and managing it directly from the source nasadmin account. If you have a dual Control Station environment, keep CS1 powered off after the restore. Also, if a Data Mover was replaced after a failover activation at the destination, the setup procedure performed for the hardware at the destination must also be performed at the source site after the restore process completes by your local EMC Service Provider or EMC Customer Service, as described in EMC Knowledgebase emc139199. "Resolve restore failures" on page 133 describes error scenarios that might occur during the restore process. If you have problems with the restored system, contact your local EMC Customer Support Representative.


Managing

The tasks to manage MirrorView/S are:

1. "Check cabinet-level MirrorView/S information" on page 97

2. "List device group information" on page 99

3. "Get detailed device group information" on page 100

4. "Suspend device group operations" on page 104

5. "Resume device group operations" on page 105

6. "Ensure Data Mover eligibility" on page 106

7. "Change the Data Mover configuration" on page 112

8. "Modify VNX for block security information after a failover" on page 114

9. "Change file system configuration" on page 115

Note: Perform MirrorView/S management tasks by using either the /nas/sbin/nas_mview -info or nas_devicegroup command. In a dual Control Station environment, run these commands only from CS0, the primary Control Station in slot 0.

If the IP address of a Control Station changes after initialization, rerun the /nas/sbin/nas_mview -init command. To change a VNX for file hostname or IP address, follow the procedures described in Configuring and Managing Networking on VNX. Also, rerun the /nas/sbin/nas_mview -init command after any storage configuration change that affects any of the mirrors, storage groups, or device groups used by VNX for file. After a failover has been activated, however, do not perform any storage system configuration changes.

Check cabinet-level MirrorView/S information

Cabinet-level MirrorView/S information includes:

◆ Information about the active device (consistency) group that is eligible for failover, including the group state, condition, and number of mirrors. This is the same information displayed with the nas_devicegroup -info command for the active device group.

◆ Information about the Data Movers (servers) that have been configured with standbys or as a local standby, and if active/active’, the Data Movers that are configured as RDF standbys, as well as the Data Mover status.

Step Action

1. Log in to the VNX for file (new_york) as nasadmin and switch (su) to root.



2. List general information about MirrorView/S by typing:

# /nas/sbin/nas_mview -info

Output:



name = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:B0:60:14:27:2:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 3mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,local clarid = APM00044700306remote clarid = APM00050601161mirror direction = local -> remote


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


Step Action


List device group information

Device group information for the MirrorView/S configuration includes basic information, such as the group name, owner, VNX for block storage ID, owner (ACL ID) of the group, and type.

id = 3name = server_4acl = 2000, owner=dradmin, ID=500type = standbyslot = 4member_of =standbyfor=status : defined = enabled actual = online, readyid = 4name = server_5acl = 2000, owner=dradmin, ID=500type = standbyslot = 5member_of =standbyfor=status : defined = enabled actual = online, ready

Step Action

1. Log in to VNX for file (new_jersey) as nasadmin.

Note: The -list and -info options do not require root permission. However, you must switch (su) to root on the source VNX for file to manipulate device group operations with options such as suspend and resume.

2. List general information about the MirrorView/S device group by typing:$ nas_devicegroup -list

Output:

ID name owner storage ID acl type1 cg_new_york 500 APM00042000817 0 MVIEW2 cg_new_jersey 0 APM00042000817 0 MVIEW

Note: In this active/active’ example, cg_new_york is owned by dradmin (500) because new_jersey serves as the destination system for cg_new_york. For cg_new_jersey, new_jersey is the source, so the owner is 0.

Step Action



Get detailed device group information

Detailed MirrorView/S device group information includes information for one group using the group name or group ID, or information for all groups on the system.

Prerequisites

For either one group or all groups, you can control whether the command synchronizes the Control Station’s view with that of the VNX for block storage system before displaying the information. By default, the command performs the synchronization.

The detailed information is from the perspective of the system on which it is run and includes the device group role of primary (source) or secondary (destination), group state, condition, number of mirrors, mirrored disks, mode (always SYNC for this release), owner, and mirror direction. The state and condition are useful for monitoring group operations. In general, the owner (ACL value) of a device group should not be changed from the default.

Summary of device group states and conditions

Table 13 on page 100 summarizes the device group states.

Table 13 Device group states

Device group state Description

Synchronized All the destination (secondary) images are in the Synchronized state.

Consistent All the destination (secondary) images are either in the Synchronized or Consistent state, and at least one is in the Consistent state.

Synchronizing At least one mirror in the group is in the Synchronizing state, and no member is in the Out-of-Sync state.

Out-of-Sync The group might be fractured, waiting for synchronization either automatic or through the administrator, or in the synchronization queue. Administrative action might be required to return the device group to having a recoverable secondary group.

Scrambled There is a mixture of primary and secondary images in the device group.

Empty The device group has no members.

Incomplete Some, but not all secondary images are missing, or mirrors are missing. This is usually due to a failure during group promotion. The group might also be scrambled.

Local Only The device group contains only primary images. No mirrors in the group have a secondary image.


Table 14 on page 101 summarizes the device group conditions.

Table 14 Device group conditions (page 1 of 2)

Device group condition Description

Active The normal processing state.

Inactive The group is not accepting I/O. This is normal during group promotion.

Admin Fractured An administrator has fractured the group, or a media failure, such as a failed sector or a bad block has occurred. An administrator must initiate a group synchronization.

System Fractured Some or all MirrorView/S device group members are associated with a failure causing a fracture of the entire device group:

• If there is a temporary link down failure, the group can recover automatically as long as the recovery policy for the group is set to Automatic, the default when the group is created as part of storage system configuration, and not Manual. If the recovery policy for the group is set to Manual, you must run the nas_devicegroup -resume command to recover from a link down failure.

• If one source storage processor is down and the device group stays in System Fractured condition, run the nas_devicegroup command to suspend the device group operations and resume device group operations. As part of the suspend/resume, the LUNs are automatically trespassed to the other storage processor.

• If both source storage processors are down, you must perform a forced failover activation. "Activation failure scenario when VNX for block storage system is unreachable" on page 126 shows a forced failover activation.

• If one destination storage processor is down, try to repair the failure and see if the group automatically recovers. If not, then use the nas_devicegroup -resume command to perform a manual, incremental synchronization of the destination with the source. If you discover this problem after you attempt to perform a failover, perform the procedures in "Activation failure scenario due to failure of one destination storage processor (SP)" on page 129.

• If there is a combined failure of both source storage processors and one destination storage processor, perform the procedures in "Resolution for activation failure scenario due to combined failure of both source SPs and destination SPA" on page 131.

Waiting on Sync The group is no longer System Fractured. It is a temporary condition for automatic recovery groups. For manual recovery groups, the administrator can now initiate the group synchronization.



The tasks to get detailed device group information are:

◆ "Display information for one group" on page 102

◆ "Display information for all groups" on page 103

Display information for one group

Unknown Temporary condition while a group fracture is in progress. The group is partially fractured. If the state is incomplete, the condition is irrelevant and is thus set to Unknown.

Step Action

1. Log in to VNX for file (new_york) as nasadmin.

2. List general information about a specific MirrorView/S device group by using this command syntax:# nas_devicegroup -info {<name>|id=<id>}

where:<name> = name of the device group<id> = ID assigned to the device group (shown with nas_devicegroup -list)

Note: To get information without synchronization, use the sync no option. For example, nas_devicegroup -info cg_new_york -sync no.

Example:

To get general information about a specific MirrorView/S device group with synchronization on, type:$ nas_devicegroup -info cg_new_york

Output:


name = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:B0:60:14:27:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 5mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d7,d8,local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local -> remote

Note: In the example, the group state is Consistent and the condition is Active. In the event of a link down failure, the condition would show as System Fractured. The group can recover automatically from the link down failure as long as the recovery policy for the group is set to Automatic, the default when the group is created as part of storage system configuration, and not Manual.

Table 14 Device group conditions (page 2 of 2)

Device group condition Description


Display information for all groups

Step Action

1. Log in to VNX for file (new_york) as nasadmin.

2. List all information about all MirrorView/S device groups recognized by the VNX for file by typing:$ nas_devicegroup -info -all

Note: To display a list of the mirrored disks, run the nas_devicegroup command from the source VNX for file. The mirrored disks are not visible to hosts from the destination.

Note: To get information without synchronization, use the sync no option. For example, nas_devicegroup -info -all -sync no.

Output:


name = cg_new_yorkdescription = new_york_as_sourceuid = 50:6:1:60:90:60:7:30:0:0:0:0:0:0:0:0state = Consistentrole = Primarycondition = Activerecovery policy = Automaticnumber of mirrors = 5mode = SYNCowner = 0mirrored disks = root_disk,root_ldisk,d5,d7,d8,local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local -> remote

name = cg_new_jerseydescription = new_jersey_as_sourceuid = 50:6:1:60:90:60:7:30:1:0:0:0:0:0:0:0state = Consistentrole = Secondarycondition = Activerecovery policy = Automaticnumber of mirrors = 5mode = SYNCowner = 500mirrored disks =local clarid = APM00041700549remote clarid = APM00042000817mirror direction = local <- remote

Note: In the example, new_york has two device groups, one for which it is the source, and one for which it is the destination. Therefore, the entry for cg_new_york identifies the role as Primary and provides the list of mirrored disks. The entry for cg_new_jersey identifies the role as Secondary and does not provide the list of mirrored disks.



Suspend device group operations

Temporarily halting the mirroring from the source to the destination suspends the link.

Prerequisites

When suspending device group operations:

◆ Changes can still be made to the source LUNs, but they are not applied to the destination LUNs (that is, secondary images) until you resume operations.

◆ Suspending a device group causes an administrative fracture and the group’s condition field changes to Admin Fractured.

As defined in the MirrorView/Synchronous for Navisphere Administrator’s Guide, available on Online Support, a fracture stops mirroring operations from the primary (source) image to a secondary (destination) mirror image. A fracture can occur either automatically, because of a failure in the path to the destination image’s storage processors, or manually, by an administrative action, or both. In some cases, you might want to fracture the destination mirror image from the remote mirror. You might administratively fracture an image to perform preventive maintenance.

It is appropriate to suspend device group operations to recover from a single source storage processor failure. In this case, run the nas_devicegroup -suspend command from the source to halt device group operations and then use the nas_devicegroup -resume command to restart device group operations. As part of the suspend/resume, the LUNs are automatically trespassed to the other storage processor.

◆ You suspend device group operations only from the source VNX for block.

◆ You must switch (su) su to root on the source VNX for file to run the suspend option.

Step Action

1. Log in to VNX for file (new_york) as nasadmin and switch (su) to root.

2. Suspend MirrorView/S device group operations by using this command syntax:# nas_devicegroup -suspend <name>

where:<name> = name of the device group

Example:To suspend MirrorView/S device group operations, type:# nas_devicegroup -suspend cg_new_york


STARTING an MV 'SUSPEND' operation. Device group: cg_new_york ........... done The MV 'SUSPEND' operation SUCCEEDED.done



Resume device group operations

On the source VNX for file, resume device group operations and restart mirroring operations.

Prerequisites

When the device group resumes operations, the destination LUNs are synchronized with the source LUNs. You can use this option after you suspend operations, or when the device group is in the Waiting on Sync condition or Out-of-Sync state.

When the nas_devicegroup -resume command is run from the source VNX for file in response to a MirrorView/S device group fracture, the command resumes operations of the MirrorView device group by performing a manual, incremental synchronization of the group’s mirror pairs, the source LUNs and their equivalent destination LUNs. The resume option can be used to recover from a destination site failure such as a MirrorView link down or storage processor failure.

Note: As long as the group recovery policy for the group is set to Automatic, the default when the group is created as part of storage system configuration, the group should be able to recover automatically from a link down error. However, if the recovery policy for the group is set to Manual during storage system configuration, then you must run the nas_devicegroup -resume command to recover from the link down failure.

If you perform the resume from the destination VNX for file after a failover has been activated, a full synchronization is performed to reconstruct the device group and mirrors.

Note: You must be logged in as a root user to run the resume option.

Step Action

1. Log in to VNX for file (new_york) as nasadmin and switch (su) to root.

2. Resume device group operations and perform a manual synchronization by using this command syntax:# nas_devicegroup -resume <name>

where:<name> = name of the device group

Example:

To resume device group operations and perform a manual synchronization, type: # nas_devicegroup -resume cg_new_york

Output:


STARTING an MV 'RESUME' operation. Device group: cg_new_york .......... done The MV 'RESUME' operation SUCCEEDED.done



Ensure Data Mover eligibility

This section describes:

◆ Data Mover conditions that apply during MirrorView/S initialization.

◆ How to gather additional information when a Data Mover is not eligible to participate in a remote DR configuration.

◆ How to verify the Data Mover relationships during initialization.

To ensure Data Mover eligibility and conditions, you must:

◆ "Ensure Data Mover network device compatibility" on page 108

◆ "Get additional information during initialization" on page 109

◆ "Verify configuration during initialization" on page 109

Table 15 on page 106 summarizes the source Data Mover conditions that appear when you initialize MirrorView/S.

Table 15 Source Data Mover conditions during initialization

ConditionCan you select it?

Description

[ not eligible for remote DR ]

No This Data Mover is not eligible to participate in a remote disaster recovery configuration. If you see this condition during the initialization process, type the d option to get more information about why the Data Mover is ineligible.

[ is remote standby for server_x ]

No This Data Mover is configured as a remote standby. This applies to an active/active’ configuration.

[ remote standby is server_x ]

Yes This Data Mover is configured with a remote standby.

[ local standby ] Yes This Data Mover is configured as a local standby; remote standby can be configured to activate in a disaster recovery situation.

[ unconfigured standby ] Yes This Data Mover is configured as a standby; however, no primary Data Movers are configured to use it.


Table 16 on page 107 summarizes the destination Data Mover conditions that appear when you initialize MirrorView/S.

Table 16 Destination Data Mover conditions during initialization

ConditionCan you select it?

Description

[ is remote standby for server_x ]

No This Data Mover is configured as a remote standby.

[ remote standby is server_x ]

No This Data Mover is configured with a remote standby. Applies to an active/active’ configuration.

[ remote standby ] No This Data Mover is configured as a remote standby but the source Data Mover cannot be determined.

[ local standby ] No One or more of the Data Movers configured to use this local standby are not remote standbys.

[ unconfigured standby ] Yes This Data Mover is configured as a standby; however, no source Data Movers are configured to use it.

[ local standby for remote standbys ]

Yes This Data Mover is configured as a local standby. All Data Movers configured to use this local standby are remote standbys.

[ non-root file system mounted ]

No This Data Mover has one or more user file systems mounted and cannot be a standby.

[ not compatible ] No The source Data Mover has one or more network devices not available on this Data Mover. If you see this as a Data Mover condition, the network devices in the two cabinets do not have the same configuration. This could happen if you are mixing an NS series gateway cabinet with an NSX cabinet and you have a different number of network ports in use on both sides (for example, 6 cge ports on a source NS versus 5 on the destination NSX). "Ensure Data Mover network device compatibility" on page 108 provides more information about resolving Data Mover network device incompatibility.



Ensure Data Mover network device compatibility

The MirrorView/S initialization procedures check for and enforce Data Mover compatibility (including network device configuration compatibility) between the source Data Movers configured for disaster recovery and the standby Data Movers at the destination. A source Data Mover and remote standby Data Mover must appear to have the same network device configuration. To ensure network device compatibility and prevent a destination Data Mover condition of not compatible during initialization, you can edit the file /nas/site/nas_param to specify a system parameter called hidden_interfaces. This parameter enables you to specify a list of device names that need to be masked to make the Data Movers in each cabinet appear to have the same network device configuration.

The E-Lab Interoperability Navigator, available on Online Support, provides detailed information about Data Mover compatibility based on the different types of cabinets. Consult this tool before attempting to resolve Data Mover incompatibility problems.

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

Step Action

1. Log in to the source Control Station.

2. Open the file /nas/site/nas_param with a text editor.

A short list of configuration lines appears.

3. Edit the file to specify the hidden_interfaces parameter with a list of devices to be hidden. If you need to specify multiple devices, use a comma-separated list (for example, cge6, cge5). The list you supply applies to all Data Movers in the system.

For example, with a source NS702G, which has six cge (copper-wire Ethernet) ports, and a destination NSX, which has five cge ports, the hidden_interfaces parameter can be specified to mask (hide) cge6, if it is unused on all source Data Movers: hidden_interfaces:cge6:

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

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

4. Save and close the file.

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



Get additional information during initialization

If a Data Mover is not selectable during the initialization process, and you see the condition [not eligible for remote DR], you can display additional information about why the Data Mover is ineligible.

The following sample excerpt from the initialization of source new_york from destination new_jersey shows ineligible Data Movers.

Verify configuration during initialization

During the initialization process, you can verify the Data Mover configuration as follows:

◆ You can perform the verification after each MirrorView/S source-to-destination Data Mover relationship that you define.

◆ You can perform the verification after defining all the relationships but before you type c to continue and complete the initialization.

◆ You can rely on the software to perform the verification automatically after you type c to continue and complete the initialization.

Action

[root@new_jersey nasadmin]# /nas/sbin/nas_mview -init new_york

Output for getting information about an ineligible Data Mover

...Contacting new_york for remote storage infoGathering server information...Contacting new_york for server capabilities...Analyzing server information...

Source servers available to be configured for remote DR------------------------------------------------------- server_2:new_york [ not eligible for remote DR ] server_3:new_york [ not eligible for remote DR ]d. Display details for servers not eligible for remote DRv. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: d

Info 26306805889: server_2:new_york file system "local_fs" is utilizing storage which is not mirrored to new_jersey.Info 26306805891: server_2:new_york file system "pfs" is involved in an IP Replicator environment.Info 26306805888: server_2:new_york file system "local_fs" has Automatic File System Extension enabled.Info 26306805891: server_3:new_york file system "sfs" is involved in an IP Replicator environment.

Press <Enter> continue



The following excerpt from the initialization of source new_york from destination new_jersey shows how Data Mover verification can help clarify configuration requirements.

Action


Output for Data Mover verification

...Contacting new_york for remote storage infoGathering server information...Contacting new_york for server capabilities...Analyzing server information...

Source servers available to be configured for remote DR -------------------------------------------------------1. server_2:new_york2. server_3:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: v

Warning 17716871681: No remote standby servers specified Press <Enter> continue

Note: The warning indicates that you have not configured any remote standby Data Movers yet.

The following shows the initialization process for configuring the Data Mover relationship between source server_2 and remote server_2:

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york2. server_3:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 1

Destination servers available to act as remote standby------------------------------------------------------1. server_2:new_jersey2. server_3:new_jerseyb. BackSelect a new_jersey server: 1

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: v


Output for Data Mover verification (continued)

Error 13421904938: new_york:server_2 has slot 3 configured as a local standby. new_jersey:server_3 slot 3 is not configured as a standby, therefore local failover for new_york:server_2 will not be available after activation

Error 13421904936: new_york:server_2 has a local standby, new_york:server_3, which does not have a remote standby configured.

Press <Enter> continue

Note: The first error reports that the source server_2 is configured with slot 3 (server_3) as its local standby but the destination slot 3 is not a standby. Therefore, local failover is not available after activation. The second error reports that because source server_2 has slot 3 (server_3) as a local standby, server_3 should have a remote standby configured. For either error, you must either resolve the problem or quit. You cannot complete the initialization.

The following configures and validates the relationship between source server_3 and remote server_3:Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ local standby ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 2Destination servers available to act as remote standby------------------------------------------------------ server_2:new_jersey [ is remote standby for server_2:new_york ]2. server_3:new_jerseyb. BackSelect a new_jersey server: 2

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ remote standby is server_3:new_jersey ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: v


Press <Enter> continueSource servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_york [ remote standby is server_3:new_jersey ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: c




Change the Data Mover configuration

This section describes how to change a Data Mover configuration by rerunning the /nas/sbin/nas_mview -init command as root at the destination.

The basic steps for changing the configuration are as follows:

Second example of verification with local standby error

In this example of an invalid configuration, server_5 is configured as a local standby for server_3 (intended MirrorView-protected Data Mover) and server_4 (local-only Data Mover). Both cannot share server_5, because server_3 would be owned by the remote administration account and server_4 is local-only and owned by nasadmin.

Source servers available to be configured for remote DR------------------------------------------------------- server_2:new_york [ is remote standby for server_2:new_jersey ]2. server_3:new_york [ remote standby is server_3:new_jersey]3. server_4:new_york4. server_5:new_york [ remote standby is server_5:new_jersey ]v. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: v

Error 13421904926: new_york:server_5 is a local standby for a mix of local-only and remote standby Data Movers.

Step Action

1. To rerun the initialization and change the remote standby Data Mover configuration, run the nas/sbin/nas_mview -init from the destination, as root.

Example:[root@new_jersey nasadmin]# /nas/sbin/nas_mview -init new_york







Contacting new_york for remote storage infoGathering server information...Contacting new_york for server capabilities...Analyzing server information...

Note: If the global VNX for block account information is already known, you are not prompted for it.


2. From the source server side, specify the selection number of the source Data Mover for which you want to change the configuration.

Example:

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_2:new_jersey ]2. server_3:new_yorkv. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 1

3. From the destination server side, type r to remove the remote standby relationship of a destination Data Mover currently serving as the remote standby for the source Data Mover.

Example:

Destination servers available to act as remote standby------------------------------------------------------r. -> Remove server_2:new_jersey [ is remote standby for server_2:new_york ]2. server_3:new_jersey [ unconfigured standby ]b. BackSelect a new_jersey server: r

4. From the source side, specify the selection number of the source Data Mover for which you want to define the remote standby.

Example: Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york2. server_3:new_yorkv. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: 1

5. From the destination server side, specify the selection number of the destination Data Mover to serve as the remote standby for the source Data Mover.

Example:

Destination servers available to act as remote standby------------------------------------------------------1. server_2:new_jersey [ unconfigured standby ]2. server_3:new_jersey [ unconfigured standby ]b. BackSelect a new_jersey server: 2

Step Action



Modify VNX for block security information after a failover

To perform MirrorView/S operations, the VNX for file relies on a VNX for block username and password to access a global administrative VNX for block account. You specify this global VNX for block account information as part of the initialization procedure. A change to the existing global VNX for block password, for example, requires an update of the VNX for file storage security information on the Control Station. After initialization, this change can be captured by rerunning /nas/sbin/nas_mview -init; however, if a failover is activated (and the source system is unavailable), you must capture the change by issuing the nas_storage command with the -modify option, followed by the security (username and password) information.

Note: Make sure that you perform this procedure when logged in as nasadmin, and su to root.

6. When you are done making changes, type c to continue with the initialization. If the change is valid, a message confirms the configuration is OK.

Example:

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:new_york [ remote standby is server_3:new_jersey ]2. server_3:new_yorkv. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a new_york server: c


Note: To abort the initialization instead, type q and verify that you want to quit. A message then confirms that you have aborted the operation.

7. After the remote administration account information is detected, type yes to continue with the initialization. You then see messages reporting the update.

Example:

Using administrative user "dradmin"

Initializing Active-->Passive (new_york-->new_jersey)


Updating MirrorView configuration cacheSetting up server_2 on new_yorkSetting acl for server_3 on new_jerseyCreating device group cg new_york on new_yorkdone

Note: The remote administrative account you defined with the first initialization is used, so you are not prompted for the information.

Step Action


If a failover is activated, perform this procedure from the destination VNX for file to set the VNX for block global account security information.

Change file system configuration

In the course of managing the MirrorView/S configuration, you might need to change a local file system to a mirrored file system, or to change a file system from mirrored to an unmirrored local file system. This section addresses both scenarios:

◆ "Change a local file system to a mirrored file system" on page 116

◆ "Change a file system from mirrored to unmirrored (local)" on page 117

Note: When you perform this kind of change, you will notice that the associated disk types change. When a disk is mirrored, it has the disk type CMSTD or CMATA. When a disk is not mirrored, it has the disk type CLSTD or CLATA. All disks in a storage pool must be all mirrored or all unmirrored, but you cannot have a mix of both. If a mix exists based on a storage system configuration change, the /nas/sbin/nas_mview -init command fails.

Action

To modify the VNX for block account security information, log in as nasadmin, su to root, and use the following syntax:# nas_storage -modify {<name>|id=<storage_id>} -security [-username <username> -password <password>]

where:<name> = name of the device group<storage_id> = ID assigned to the storage <username> = username for the global VNX for block administrative account<password> = password for the global VNX for block administrative account

Example (with recommended commands to get information and validate the storage):

[root@new_york nasadmin]# nas_storage -listid acl name serial_number 1 0 APM00041700549 APM000417005492 0 APM00042000817 APM00042000817

[root@new_york nasadmin]# nas_storage -sync -all

done

[root@new_york nasadmin]# nas_storage -modify id=2 -security -username nasadmin -password nasadmin

Output

Setting security information for APM00042000817 id = 2serial_number = APM00042000817name = APM00042000817acl = 0



Change a local file system to a mirrored file system

Use the following procedure to change a local file system to a mirrored file system:

Step Action

1. Work with your local EMC Customer Support Representative to configure mirroring on the VNX for block storage system.

2. Run the nas_storage -sync command on the source VNX for file and the destination VNX for file using the following syntax:nas_storage -sync {-all | <name> | id=<storage_id>}

Example:

To synchronize the Control Station's view with that of the storage, run the following command on both the source and destination VNX for file systems:$ nas_storage -sync -all

3. Unmount the file system associated with the local disk changed to mirrored from the local Data Mover, if you keep the Data Mover as local. Use the following syntax: $ server_umount <movername> -perm <fs_name> [<mount_point>]

where:<movername> = name of the local Data Mover<fs_name> = name of the file system<mount_point> = mount point, optional

Example:$ server_umount server_3 -perm ufs3

4. Run the /nas/sbin/nas_mview -init command from the destination VNX for file.

Example:


5. Mount the new mirrored file system on the mirrored Data Mover, if needed, using the following syntax:$ server_mount <movername> <fs_name> [<mount_point>]

where:<movername> = name of the local Data Mover<fs_name> = name of the file system<mount_point> = mount point

Example:$ server_mount server_3 ufs3 /ufs3


Change a file system from mirrored to unmirrored (local)

Use the following procedure to change a mirrored file system to a local file system:

Step Action

1. Work with your local EMC Customer Support Representative to do the following:

Note: Make sure that you stop all I/O before proceeding. Also, if you intend to change the configuration of disks in a storage pool, all disks in the storage pool must be either mirrored or unmirrored, but you cannot have a mix. A mix of disks in a storage pool causes /nas/sbin/nas_mview -init to fail.

• Remove the mirrored volume from the device group defined on your VNX for block storage system. This involves using Unisphere or NaviCLI.

• Delete the mirrored relationship using Unisphere or NaviCLI.• Delete the secondary image using Unisphere or NaviCLI.

2. Unmount the file system from the mirrored Data Mover on the source VNX for file using the following syntax: $ server_umount <movername> -perm <fs_name> [<mount_point>]

where:<movername> = name of the local Data Mover<fs_name> = name of the file system<mount_point> = mount point, optional

Example:$ server_umount server_2 -perm ufs1

3. Run the server_devconfig ALL -create -scsi -all command.

Example:

To save the device configuration into the Data Mover’s database:$ server_devconfig ALL -create -scsi -all

4. Mount the file system on the local Data Mover on the source VNX for file, if needed, using the following syntax:$ server_mount <movername> <fs_name> [<mount_point>]

where:<movername> = name of the local Data Mover<fs_name> = name of the file system<mount_point> = mount point

Example:$ server_mount server_2 ufs1 /ufs1

5. Run the nas_storage -sync command on the source VNX for file and the destination VNX for file using the following syntax:nas_storage -sync {-all | <name> | id=<storage_id>}

Example:

To synchronize the Control Station's view with that of the storage, run the following command on both the source and destination VNX for file systems:$ nas_storage -sync -all

6. Run the /nas/sbin/nas_mview -init command from the destination VNX for file.

Example:




Troubleshooting

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, contact your EMC Customer Support Representative.

Where to get help

EMC support, product, and licensing information can be obtained as follows:

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

Troubleshooting – For troubleshooting information, go to the EMC Online Support website. After logging in, locate the applicable Support by Product page.

Technical support – For technical support, go to EMC Customer Service on the EMC Online Support website. After logging in, locate the applicable Support by Product page, and choose either Live Chat or Create a service request. To open a service request through EMC Online Support, you must have a valid support agreement. 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.

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://Support.EMC.com. After logging in to the EMC Online Support website, locate the applicable Support by Product page, find Tools, and click E-Lab Interoperability Navigator.

Known problems and limitations

Table 17 on page 119 summarizes common troubleshooting scenarios for MirrorView/S.

This section provides information on how to:

◆ "Retrieve information from log files" on page 121

◆ "Resolve initialization failures" on page 122

◆ "Resolve activation failures" on page 125

http://Support.EMC.com


../ProblemResolutionRoadmap/index.htm

http://powerlink.emc.com



http://powerlink.emc.com


◆ "Resolve restore failures" on page 133

◆ "Additional situations involving Data Movers" on page 137

Overview of MirrorView/S troubleshooting scenarios

Table 17 MirrorView/S troubleshooting scenarios (page 1 of 3)

Scenario Description Actions

Planned testing, maintenance failover activated and then failback

Handles routine maintenance for testing purposes only; the device group and mirrors are functioning properly.

Check the MirrorView device group information, then activate a manual failover to the destination site VNX for file/VNX for block pair while the source site is still operational. Then, perform a restore to test failback. When the activate occurs, the destination site assumes the primary role for all mirrors in the device group and the source takes the backup role.

Note: For testing purposes, make sure that the source VNX for block and MirrorView links are up when you do a test failover. If you perform a test failover with the links down, a full synchronization is automatically performed as part of the restore to reconstruct the device group and mirrors, which is time-consuming.

Temporary loss of one or both MirrorView links

A loss of one or both MirrorView/S links causes a device group condition of System Fractured. Link recovery is needed so that the device group can return to a Sync or Consistent state and the Active condition.

In this scenario, the sys_log or the VNX for file status in Unisphere contains the alert/event generated for a link down error. "Retrieve information from log files" on page 121 provides more information.

As long as the group recovery policy for the group is set to Automatic (the default when the group is created as part of storage system configuration), the device group should be able to recover automatically from a temporary link down error.

However, if the recovery policy for the group is set to Manual, then you must run nas_devicegroup -resume to recover from the link down failure.

As long as the images are still in sync, you can avoid a forced activation. Activating a failover with one or both links down would cause a full synchronization on the restore and any writes occurring after the forced promote would be lost during the restore.



Source-site failure A source-site failure causes a device group condition of System Fractured, and could indicate any of the following:

• Primary image LUN failure• Source storage array failure• Failure of both storage

processors• MirrorView link failure (link

down for extended period)

Note: If a single source storage processor fails, use the nas_devicegroup command to suspend and resume device group operations. If you want to perform a failover activation at this point, it is a normal failover, not a forced failover. "Suspend device group operations" on page 104 provides more information.

For source-site failures other than a single source storage processor failure, perform a forced failover activation. (A forced failover of the backup images is required to make them visible to the destination VNX for file.) The source images cannot be converted to backup images. Fix the source-site problem and then perform the restore, which automatically reconstructs the device group and mirrors with a full synchronization.

Destination-site failure

Recovery is needed from a destination-site failure that prevents the source from accessing the destination and causes a device group condition of System Fractured. A destination-site failure could be caused by any of the following:

• Destination image LUN failure

• Destination storage array failure

• Failure of one or both destination storage processors

The source marks the destination as unreachable and stops write attempts to the destination.

Repair the failure at the destination and see if the group automatically recovers from the failure. If not, then use the nas_devicegroup -resume command to perform a manual, incremental synchronization of the destination with the source.

To recover from a failure of one destination SP after you have tried to activate a failover, follow the procedure in "Activation failure scenario due to failure of one destination storage processor (SP)" on page 129.




Retrieve information from log files

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 MirrorView/S 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/sbin/nas_mview command is running, check the file in the /tmp directory. After the command completes, the logs appear in the /nas/log directory. When a failover is activated and the destination system is in an activated state, the log files reside in the /nas/rdf/500/log directory. Although the/nas/rdf/500/log/cmd_log file currently points to /nas/log/nas_log.al in an activated state, view the cmd_log file for the remote administration account using /nas/rdf/500/log/nas_log.al.

The disaster recovery (dr*) files provide state changes as well as other key informational messages. The /nas/log/symapi.log file logs storage-related errors.

Note: In the /nas/log/dr_log.al file, if you see a “Clearing orphaned inode” message, which is associated with a file system check (fsck), do not be concerned. The clearing of orphaned inodes is considered harmless.

In general, the log files can help you gather additional information after a failure (for example, a failed restore).

Combined source and destination-site failure

If both source storage processors and one destination storage processor are down, it is possible to recover from the failure. This combined failure causes a device group condition of System Fractured.

For other combined source and destination failures, you must address the individual problems at the sites.

To recover from this combined failure after a failover activation, follow the procedure in "Resolution for activation failure scenario due to combined failure of both source SPs and destination SPA" on page 131.





To alert you to device group condition changes on the source VNX for file, NaviEventMonitor events (ID 200) are generated and the state changes are logged in the sys_log. For example:

Mar 9 09:11:00 2006 NaviEventMonitor:3:200 Device group cg_new_york on APM00042000817 is System Fractured

Mar 9 10:30:59 2006 NaviEventMonitor:5:200 Device group cg_new_york on APM00042000817 is Active

Table 18 on page 122 identifies these events, which are associated with the NaviEventMonitor facility (facility ID138). Configuring Events and Notifications on VNX for File provides more information about viewing and managing the handling of events and notifications.

In Unisphere, the link-down event appears as an alert under the Status for a severity of Warning or higher. Unisphere online help provides more information about Unisphere elements.

Resolve initialization failures

To resolve initialization failures, consider:

◆ "Initialization failure due to storage system configuration error (no write intent log configured)" on page 123

◆ "Resolution for initialization failure due to storage system configuration error (no write intent log configured)" on page 124

◆ "Initialization failure due loss of communication with source Control Station" on page 125

Table 18 NaviEventMonitor facility events for MirrorView/S

Event ID EventEvent description/corrective action

200 Device group <group> on <system> is System Fractured

For a severity of Warning or higher, indicates that the MirrorView/S device group is in the condition System Fractured (for example, because a MirrorView/S link is down).

200 Device group <group> on <system> is Active

As an informational event, indicates that the MirrorView/S device group is Active, indicating that communication has resumed on the MirrorView/S link.




Initialization failure due to storage system configuration error (no write intent log configured)

In this initialization failure scenario, which uses a source called aviator and a destination called element, initialization fails due to a storage system configuration error (lack of write intent log LUN configuration). The error conditions are highlighted.

Initialization failure scenario

# /nas/sbin/nas_mview -init aviator


Initializing aviator --> element

Contacting aviator for remote storage info


Discovering storage on aviator (may take several minutes)Setting security information for APM00055105668Discovering storage APM00055003968 (may take several minutes)


Contacting aviator for remote storage infoError 13421904911: Mirror aviator_m17 is not configured to use the write intent log.



Resolution for initialization failure due to storage system configuration error (no write intent log configured)

The following shows the rerun of the initialization after the error has been fixed.


# /nas/sbin/nas_mview -init aviator


Initializing aviator --> element

Contacting aviator for remote storage info


Discovering storage on aviator (may take several minutes)Setting security information for APM00055105668Discovering storage APM00055003968 (may take several minutes)


Contacting aviator for remote storage infoGathering server information...Contacting aviator for server capabilities...Analyzing server information...

Source servers available to be configured for remote DR-------------------------------------------------------1. server_2:aviator [ remote standby is server_2:element ] server_3:aviator [ not eligible for remote DR ]d. Display details for servers not eligible for remote DRv. Verify standby server configurationq. Quit initialization processc. Continue initializationSelect a aviator server: c


Using administrative user "dradmin"

Initializing Active-->Passive (aviator-->element)

Do you wish to continue? [yes or no] y

Updating MirrorView configuration cacheSetting up server_2 on aviatorSetting acl for server_2 on elementCreating device group cg_aviator on aviatordone


Initialization failure due loss of communication with source Control Station

In this initialization failure scenario, which uses a source called HH_CSO and a destination called NS704G_CS0, communication to the source Control Station is lost during initialization. The error conditions are highlighted. To resolve the error, address the Control Station problem (check IP network connectivity, make sure services are running on the Control Station, and so on) to make sure the source Control Station is available, then retry the initialization.

Resolve activation failures

Use the following guidelines to recover from various activation failures:

◆ If the VNX for block storage system is unreachable and the synchronization with the storage system fails during the failover, check the source VNX for block storage system and review the information in "Activation failure scenario when VNX for block storage system is unreachable" on page 126:

• If both source storage processors are down, you need to continue with a forced failover activation.

• If one source storage processor is down, do not continue with the failover. Instead, run the nas_devicegroup -suspend command from the source to halt device group operations and use the nas_devicegroup -resume command to restart device group operations. This suspend/resume trespasses the LUNs to the other storage processor automatically and you can perform a normal failover activation after the resume.

◆ If one destination storage processor is down, follow the steps outlined in "Activation failure scenario due to failure of one destination storage processor (SP)" on page 129, which involves trespassing the affected LUNs to the other storage processor before rerunning the failover activation.

◆ If a MirrorView link is down, do not proceed with the failover until the link problem is resolved. The device group can recover automatically from a temporary link down failure as long as the recovery policy for the group is set to Automatic (the default when the group is created as part of storage system configuration), not Manual. If the recovery policy for the group is set to Manual,


# /nas/sbin/nas_mview -init HH_CS0


Initializing HH_CS0 --> NS704G_CS0

Contacting HH_CS0 for remote storage info


Discovering storage on HH_CS0 (may take several minutes)Error 5008: Error discovering storage on src siteRemote command failed:remote celerra = HH_CS0remote exit status = 0remote error = 0remote message = HTTP Error 408: Request Timeout



you must run the nas_devicegroup -resume command to recover from a link down failure.

◆ If both source storage processors and one destination storage processor are down, perform the forced failover activation before trespassing the affected LUNs, then complete the server failover using the steps outlined in "Resolution for activation failure scenario due to combined failure of both source SPs and destination SPA" on page 131.

◆ If the name of the MirrorView/S consistency group has been changed on the VNX for block storage system after initialization, make sure your local EMC Service Provider or EMC Customer Service performs the procedure described in EMC Knowledgebase emc138372 to correct the VNX for file device group configuration before you attempt to activate a failover. "Additional activation failure after a storage system group name change" on page 132 provides more information.

◆ If the device group configuration cannot be validated during failover activation, the activation fails. If there has been a storage system configuration change, follow the corrective action listed for error 13421904948. In a source-site failure scenario in which the storage system is damaged and storage processors A and B booted up with no configuration information, contact your local EMC Service Provider or EMC Customer Service to shut down the source storage processors or hide the source VNX for file from the destination side completely (that is, put the MirrorView link down, and shut down the IP network to the source side to simulate a power-off activate scenario) before retrying the activation. After successful activation, your local EMC Service Provider or EMC Customer Service can rebuild the configuration (which involves rebuilding the LUNs) and then run restore.

To resolve activation failures, consider:

◆ "Activation failure scenario when VNX for block storage system is unreachable" on page 126

◆ "Resolution for activation failure scenario when VNX for block storage system is unreachable" on page 128

◆ "Activation failure scenario due to failure of one destination storage processor (SP)" on page 129

◆ "Resolution for activation failure scenario due to failure of one destination storage processor (SP)" on page 129

◆ "Resolution for activation failure scenario due to combined failure of both source SPs and destination SPA" on page 131

◆ "Additional activation failure after a storage system group name change" on page 132

Activation failure scenario when VNX for block storage system is unreachable

In this activation failure scenario, the failure occurs during failover activation when the VNX for block storage system is unreachable. You are instructed to check the VNX for block storage system. Also, a warning message notifies you that the device group is not in a proper state for failover and continuing forces a full synchronization


of the source from the destination. If you see this message, you must evaluate whether it is appropriate to continue with the failover activation. If this is a test scenario, make sure the source side VNX for block and the links are operational before proceeding with the failover to avoid a full synchronization. If this is a true disaster scenario and the source is down, a full synchronization is automatically performed as part of the restore.

Activation failure scenario

# /nas/sbin/nas_mview -activate

Sync with CLARiiON backend ...... failed Validating mirror group configuration ...... doneRemote CLARiiON backend is not reachableCheck remote CLARiiON backend.

********** WARNING: **********

The MirrorView/S device group is not in a proper state for failover activation. If you continue while the device group is in this state and force the failover, a full synchronization of the source from the destination will automatically occur during the restore to reconstruct the group and mirrors, which is time-consuming.

1. If you are activating this failover for maintenance or test purposes, it is recommended that you abort this activation.

2. From the source system, use the nas_devicegroup -info command to verify the device group condition is Active, and the state has reached Synchronized or Consistent.

3. Retry the activation from the destination system.

******************************Do you wish to continue? [yes or no] yesIs source site aviator ready for complete shut down (power OFF)? [yes or no] yes

Contacting source site aviator, please wait... done

Shutting down remote site aviator .................................................................. Unable to get shutdown status from remote site. Trying force shutdown, please wait... done

Sync with CLARiiON backend ...... failedSTARTING an MV 'FAILOVER' operation. Device group: cg_aviator ............ done The MV 'FAILOVER' operation SUCCEEDED. Failing over Devices ... done

Adding NBS access to local server server_2 ........ done Adding NBS access to local server server_3 ........ done Activating the target environment ... done

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

done



Resolution for activation failure scenario when VNX for block storage system is unreachable

The following shows the restore (run from the destination) after the source-side storage system hardware problem is resolved and the storage system is back to normal operation.

Activation failure scenario

# /nas/sbin/nas_mview -restore

Sync with CLARiiON backend ...... done Validating mirror group configuration ...... done

Contacting source site aviator, please wait... done

Running restore requires shutting down source site aviator. Do you wish to continue? [yes or no] yes

Shutting down remote site aviator ....... done

Is source site aviator ready for storage restoration ? [yes or no] yes


STARTING an MV 'rebuild' operation. This may take several minutes, please be patient. Device group: cg_aviator ............ done The MV 'rebuild' operation SUCCEEDED.

Synchronized: 100% (**************************************************) Updating device group ... done Is source site ready for network restoration ? [yes or no] yes


Removing NBS access from local server server_2 .. done Removing NBS access from local server server_3 .. done

Waiting for device group ready to failback ... doneSync with CLARiiON backend ...... done

STARTING an MV 'FAILBACK' operation. Device group: cg_aviator ............ done The MV 'FAILBACK' operation SUCCEEDED.

Restoring remote site aviator, please wait... done

done

Note: After this restore process completes, you should wait 5–10 minutes for Control Station 0 to come back up before logging in to the source VNX for file (new_york) and managing it directly from the source nasadmin account. If you have a dual Control Station environment, keep in mind that CS1 remains powered off after the restore. "Additional situations involving Data Movers" on page 137 describes what to do after the restore if a Data Mover was replaced after failover activation at the destination.


Activation failure scenario due to failure of one destination storage processor (SP)

In this activation failure scenario, the activation fails because one destination storage processor A (SPA) is down.

Note: If the problem is with the MirrorView links instead of a storage processor, the synchronization with the storage system reports done instead of failed. The device group condition in either case is System Fractured.

Resolution for activation failure scenario due to failure of one destination storage processor (SP)

EMC strongly recommends that the hardware problem addressed before proceeding with a test failover and restore. As a workaround, you can perform this procedure. If you cannot successfully perform this procedure, contact EMC Customer Service.

Use the following procedure to resolve a single destination SPA failure.

Output for failed synchronization upon activation

# /nas/sbin/nas_mview -activateSync with CLARiiON backend ...... failedValidating mirror group configuration ...... doneThe device group is System Fractured. Check the MirrorView links between the two CLARiiON backends, and check the backend storage processors.

********** WARNING: **********

The MirrorView/S device group is not in a proper state for failover activation. If you continue while the device group is in this state and force the failover, a full synchronization of the source from the destination will automatically occur during the restore to reconstruct the group and mirrors, which is time-consuming.

1. If you are activating this failover for maintenance or test purposes, it is recommended that you abort this activation.

2. From the source system, use the nas_devicegroup -info command to verify the device group condition is Active, and the state has reached Synchronized or Consistent.

3. Retry the activation from the destination system.

******************************Do you wish to continue? [yes or no] no

Error 13421904897: The device group is System Fractured.

Step Action

1. Refer to the LUN information on the detailed configuration planning sheet created during storage system setup to determine the source actual LUN numbers (ALUs) in the consistency (device) group. For all mirrors in the MirrorView/S consistency group, find their source ALU number from the configuration planning sheet.



2. Run the navicli (or naviseccli) command to trespass each affected source LUN in the consistency (device) group to source storage processor B (SPB). Destination LUNs are automatically trespassed.

From a Control Station, use the following syntax to trespass a source LUN to SPB: # /nas/sbin/navicli -h <IP_address_of_source_SPB> trespass lun <ALU-number>

where:<IP_address_of_source_SPB> = IP address for source storage processor B<ALU-number> = actual LUN number associated with the source LUN to be trespassed

Examples (showing three control LUNs and two user LUNs):

# /nas/sbin/navicli -h 192.168.96.82 trespass lun 0





Note: Remember to include all source LUNs in the consistency group.

3. From the destination VNX for file, rerun the failover activation.

Example:# /nas/sbin/nas_mview -activate

4. From the destination VNX for file, perform the restore.

Example: # /nas/sbin/nas_mview -restore

5. After the destination storage processor A (SPA) is successfully restored, trespass all source LUNs in the consistency (device) group originally owned by source SPA back to SPA.

From a Control Station, use the following syntax to trespass a source LUN back to SPA: $ /nas/sbin/navicli -h <IP_address_of_source_SPA> trespass lun <ALU-number>

where:<IP_address_of_source_SPA> = IP address for source storage processor A<ALU-number> = actual LUN number associated with the source LUN to be trespassed back to SPA

Examples (showing three control LUNs and two user LUNs):







Step Action


Resolution for activation failure scenario due to combined failure of both source SPs and destination SPA

In this activation failure scenario, both source storage processors and the destination storage processor A (SPA) are down. Use the following procedure to recover from this combined failure.

Note: This procedure includes the server_standby -activate rdf command. Use of this command is appropriate when you need to recover from a failure scenario in which the MirrorView/S activate fails to complete the activation of a remote standby. To recover from a failed MirrorView restore scenario, you can also use the server_standby -restore rdf command to restore a source Data Mover.

Step Action

1. From the destination VNX for file, perform a forced failover.

Example:# /nas/sbin/nas_mview -activate

Note: Although the activation fails at the end because the standby servers cannot be activated, the VNX for block storage system failover did occur and the destination side has the MirrorView source LUNs.

2. Refer to the LUN information on the detailed configuration planning sheet created during storage system setup to determine the actual LUN numbers (ALUs) are affected for the consistency group’s original destination LUNs (which are the current source LUNs after the activate), then run the navicli (or naviseccli) trespass command for each affected LUN that needs to be trespassed to the original destination storage processor B (SPB).

From a Control Station, use the following syntax to trespass a LUN to SPB: # /nas/sbin/navicli -h <IP_address_of_current_source_SPB> trespass lun <ALU-number>

where:<IP_address_of_current_source_SPB> = IP address for current source storage processor B<ALU-number> = actual LUN number associated with the current source LUN (original destination LUN) to be trespassed

Examples (for the three control LUN ALUs and two user LUNs):






Note: Remember to include all current source LUNs (original destination LUNs) in the consistency group.



Additional activation failure after a storage system group name change

In general, the name of the MirrorView/S consistency group should not be changed after initial configuration. However, if it is changed on the VNX for block storage system after initialization, your local EMC Service Provider or EMC Customer Service must perform the procedure described in EMC Knowledgebase emc138372 to correct the VNX for file device group configuration before a failover can be successfully activated. If the failover is activated and this procedure has not been performed, the activation fails, and you must contact your local EMC Service Provider or EMC Customer Service to perform the procedure described in the EMC Knowledgebase article emc138372.

3. From the destination VNX for file, run the server_standby command to complete the activation of the remote standby servers. Use the following syntax:# server_standby <movername> -activate rdf

where:<movername> = Name of the Data Mover (faulted server) on which to activate a failover

Example:[root@eng17373 dradmin]# server_standby server_3.faulted.rdf -activate rdf

4. After you resolve the storage processor failures at the source site, perform the restore from the destination VNX for file.

Example: # /nas/sbin/nas_mview -restore

5. When you are ready, trespass the source LUNs originally owned by source SPA back to SPA.

From a Control Station, use the following syntax to trespass a source LUN back to SPA: $ /nas/sbin/navicli -h <IP_address_of_source_SPA> trespass lun <ALU-number>

where:<IP_address_of_source_SPA> = IP address for source storage processor A<ALU-number> = actual LUN number associated with the source LUN to be trespassed back to SPA

Examples (for the three original source control LUNs and two user LUNs):







Step Action


Resolve restore failures

This section provides sample restore failure scenarios. "Additional situations involving Data Movers" on page 137 describes how to handle problems involving a reboot or replacement of a Data Mover.

To resolve restore failures, consider:

◆ "Failed restore from destination" on page 133

◆ "Failed restore caused by state of source Data Movers" on page 136

◆ "Restoration failure during fsck" on page 137

Failed restore from destination

In this restore failure scenario, an active/passive restore operation started by root from dradmin on destination new_jersey by using the /nas/sbin/nas_mview -restore command fails. The output shows the events leading to the error message on the destination VNX for file, followed by the output from the source after taking corrective action (that is, completion of the restore from the source).

Note: When you perform a source-side restore from the source Control Station, you must use the local VNX for file administration account and perform the restore using the path /nasmcd/sbin/nas_mview restore (not the path used for a routine destination-side restore). If you use the incorrect path and the command completes but the VNX for file service does not start, you can remove the /nasmcd/lock/dr.lck file and then make sure that the Control Station reboots.



Restore failure scenario

nas/sbin/nas_mview -restore Sync with CLARiiON backend ...... doneValidating mirror group configuration ...... done




Is source site new_york ready for storage restoration ? [yes or no] yes Sync with CLARiiON backend ...... done

STARTING an MV 'RESUME' operation. Device group: cg_new_york ............ done The MV 'RESUME' operation SUCCEEDED.


Is source site ready for network restoration ? [yes or no] yes Restoring local servers ...... done Waiting for local servers to reboot ...... done

Removing NBS access from local server server_2 .. done Removing NBS access from local server server_3 .. done Removing NBS access from local server server_4 .. done Removing NBS access from local server server_5 .. doneWaiting for device group ready to failback ... done



Note: The failure message below occurs after the failback operation is run for the device group when the restore is set to begin on the source VNX for file.

Restoring remote site new_york ...... failed

Warning 17716871682: Cannot restore new_york. Please run restore on site new_york.


Restore failure scenario

Note: The following shows sample output from the restore operation performed on the source VNX for file (new_york) after the failure.

[root@new_york nasadmin]# /nasmcd/sbin/nas_mview -restore

Stopping NAS services. Please wait...

Powering on servers ( please wait ) ...... done


STARTING an MV 'SUSPEND' operation. Device group: cg_new_york ............ done The MV 'SUSPEND' operation SUCCEEDED.

server_2 : going standby rdf : going active replace in progress ...done failover activity complete

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

Sync with CLARiiON backend ...... .done

STARTING an MV 'RESUME' operation. Device group: cg_new_york............ done The MV 'RESUME' operation SUCCEEDED.

Restarting NAS services ...... done commit in progress (not interruptible)...done commit in progress (not interruptible)...done

done[root@new_york nasadmin]# exit

Note: After the restore process completes, you should wait 5–10 minutes for Control Station 0 to come back up before logging in to the source VNX for file (new_york) and managing it directly from the source nasadmin account. If you have a dual Control Station environment, keep in mind that CS1 remains powered off after the restore. If the restoration is still not successful, collect the following log files listed in "Retrieve information from log files" on page 121. "Additional situations involving Data Movers" on page 137 describes what to do after the restore if a Data Mover was replaced after failover activation at the destination.



Failed restore caused by state of source Data Movers

A restore operation can fail because of the source Data Mover state. Table 19 on page 136 summarizes the source Data Mover states and requirements for a restore.

Table 19 Source Data Mover requirements during a restore

Source Data Mover State Description

Minimally, one source MirrorView-protected Data Mover

Up (reason code 4 or 5) To prevent an error, at least one source MirrorView-protected Data Mover must be available during the restore.

An additional source MirrorView-protected Data Mover whose remote standby use the same slot number

Does not matter As long as at least one source MirrorView-protected Data Mover is available, any another source MirrorView-protected Data Mover can be down if both it and its remote standby use the same slot number (for example, server_2 in slot 2 at both source and destination).

Any source MirrorView-protected Data Mover whose remote standby uses a different slot number

Up (reason code 4 or 5) A mismatch of slot numbers between a source MirrorView-protected Data Mover and its remote standby mandates a state of Up for that source Data Mover. For example, if source Data Mover server_2 is in slot 2 and remote standby server_4 is in slot 4, then server_2 must be Up.

Any local source Data Mover (non-MirrorView protected)

Does not matter A local source Data Mover can be down during the restore; you can reboot it on the source VNX for file after the restore completes.


Restoration failure during fsck

If the command nas_mview -restore fails or does not respond during fsck, perform the following steps to recover.

Additional situations involving Data Movers

The following summarizes additional situations concerning the management of Data Movers during or after a MirrorView failover activation or restore:

◆ If you shut down or reboot any Data Movers (MirrorView-protected or non-protected Data Movers) at the destination while the /nas/sbin/nas_mview -activate or the /nas/sbin/nas_mview -restore command is running, the Control Station does not find a path to the storage system. With the VNX for file’s communication to the storage system interrupted, the command fails. You must then rerun the /nas/sbin/nas_mview -activate or the -restore command after the Data Mover is operational. Do not shut down or reboot any Data Movers at the destination while these commands are running.

◆ If a Data Mover needs to be replaced after a successful failover activation at the destination, the setup procedure performed for the hardware at the destination must also be performed at the source site after a successful MirrorView/S restore. Contact your local EMC Service Provider or EMC Customer Service to perform the hardware setup procedures at the destination and source, as described in EMC Knowledgebase emc139199. These procedures update the local hardware information in the VNX for file database and prevent a subsequent initialization failure when you need to change the MirrorView Data Mover configuration.

◆ If a failover is activated at the destination and you reboot a local Data Mover using the wrong account (that is, you are logged in using the remote administration account instead of the VNX for file administration account at the destination and you su to root to perform the reboot), a subsequent MirrorView/S restore might appear suspended while attempting to reboot the local servers, and associated fsck log messages might appear in /tmp/dr_log.al. In this situation, contact your local EMC Service Provider or EMC Customer Service to perform the procedures described in EMC Knowledgebase emc139200. These procedures involve stopping the MirrorView restore

Step Action

1. Log in to the Control Station with an appropriate administrator account.

2. Check each Data Mover to determine whether it has remote device access permission set to read/write (rw). Use the command syntax:.server_config <mover_name> -v “nbs_list”

where:<mover_name> = name of the Data Mover

3. If none of the Data Movers has remote device permission set to rw, use the server_cpu command to reboot at least one Data Mover that is owned by the administrator account.

4. If the restore operation was stopped, restart it by using the nas_mview -restore command.



processes, rebooting the local Data Mover using the correct VNX for file administration account, and rerunning the restore as usual from the remote administration account.

◆ When you run the –init command, it changes the ACL for the local Data Movers to 1000. This prevents DR administrators from inadvertently accessing the local Data Movers in the failed over state. However, this also prevents Global Users in Unisphere from accessing this Data Mover in the normal state.

To resolve this problem, the ACL for the local Data Movers is no longer changed when you run the –init command. Instead, the ACL is changed to 1111 during failover when you run the –activate command. This prevents DR administrators from accessing the Data Movers after failover and allows Global Users to access them in the normal state.During failback, when you run the –restore command, the ACL is changed to 0. If you intentionally initially use ACL 1111 for the local Data Movers on the source side, ensure that you change the ACL from 0 back to 1111 after failback. Alternately, you can change the ACL for the local Data Movers on the source side to some other value, for example, 1000, to avoid this manual change.

◆ If an fsck error occurs on the source, waiting for a Data Mover to boot as part of the restore, the restore fails, and the fsck read block error appears in dr_log.al. In this situation, perform the restore from the source side, as shown by the sample output in "Failed restore from destination" on page 133.

Error messages

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 following methods:

◆ Unisphere software:

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

◆ CLI:

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

◆ Celerra Error Messages Guide:

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

◆ EMC Online Support:

• Use the text from the error message’s brief description or the message’s ID to search the Knowledgebase on the EMC Online Support website. After logging in to EMC Online Support, click either Search or Support by Product.

EMC 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 Online Support at http://Support.EMC.com for course and registration information.

EMC Professional Services can help you implement your VNX series 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.





Index

Aabsolute path requirement 66, 93accounts

establishing remote DR 48, 78, 82global VNX for block 10specifying remote DR for failover 57, 89

ACL and remote admin account 74activating MirrorView/S failover 37, 55, 56, 87, 89active/active’

failover 87, 88initializing 71, 79overview of 22recommendations for remote admin account 28, 74restoring 92

active/passiveconfiguration 43definition 13failover, activating 56overview of 21restoring 65upgrade guidelines 27

Admin Fractured condition 101, 104Automatic File System Extension, restriction 11, 27

Bbackend configuration 17

rules about changing 29, 45, 90, 97summary of 28

backend unreachable 126

Ccautions 57, 89changing

backend configuration 90Control Station IP address 97Data Mover configuration 113

checking cabinet-level MirrorView/S information 97checklist for Data Mover configuration 32CIFS (Common Internet File System) 13CIFS See Common Internet File System 13command

nas_cel -create 40, 41nas_rdf -init 40

commandsfor managing MirrorView/S 97nas_cel -create 37nas_devicegroup 51, 85nas_mview 38, 97nas_rdf 40nas_storage 114, 116

Common Internet File System 13comparison of related VNX features 23compatibility, Data Mover network device 108conditions of device group 100

Admin Fractured 104

System Fractured 101, 119Waiting on Sync 101

configuration tracking sheet 33configuring

Data Movers 30, 31consistency group 19

creation 29getting information about 97managing 97resuming 105states and conditions 100suspending 104

Consistent state 100control LUNs 18Control Station

after a restore 128communication 17preinitialization 40, 41rules for redundant 9, 57system time 10

CX-series storage arrays 17

DData Movers

changing configuration 112, 113checking configuration 97checklist for 32, 33conditions during initialization 106ensuring network device compatibility 108failure scenarios after failover and/or restore 137mirroring 30, 31replacement at destination after activation 96rules for configuring 30, 31source DM state causing restore failure 136validating compatibility 106validating during initialization 109

dedicated MirrorView/S links 17delays, write 18destination LUNs 18

backend configuration of 28destination VNX for file 13

activating failover from 56performing restore from 66running restore operation on 105tasks performed on 38

destination-site failure 120device group 19

conditions 101, 104getting information about 97listing 51, 85name 126resuming 105states 100suspending 104

different IP subnets 64disk types for MirrorView 115DR administrative account 48, 57, 78, 82, 89DR, Data Mover not eligible for 106dr_log files 121

142 of 146 Using MirrorView™ Synchronous with VNX™ for File forDisaster Recovery

Release 7.1

Eediting the /etc/hosts file 44, 72EMC Knowledgebase articles

Data Mover replacement after failover 68, 137group name change 29, 57, 88, 126, 132upgrade process 27

error scenarios 119errors

restore 133, 136events 121

Ffailover

initiating active/active’ 88initiating active/passive 37, 56initiating MirrorView/S 37, 55, 56, 87, 89initiating SRDF/S 55, 87requirement to use remote admin account 10restoring VNX for file after a 38, 65, 66, 93restrictions 10SNMP or email for event notification after 11testing active/active’ 88

failure scenariosoverview of 119restore 133, 136

fibre channel links 5, 6file system configuration, changing 115, 117FileMover 12, 13files

log 121firewalls 33fixed LUN mapping for control LUNs 18fracture of device group 101, 104, 119fracture, system 119

Ggetting information

with nas_devicegroup 100with nas_mview 97

graceful failover 88group, consistency 19guidelines

for change backend configuration 29for file systems 27for local standbys 30for remote admin account 28, 74for upgrading 26

Hhalting Data Movers 58, 89hidden_interfaces parameter 108host visibility of destination storage at promotion 17HTTP communication 48, 78, 82

Iimportant notes 47, 77, 81-info argument of nas_mview command 97

initializingactive/active’ 71, 79active/active’ failover 88active/passive failover 37, 56MirrorView/S relationship 37, 45, 46, 75, 76, 79, 80SRDF relationship 40to capture changes 29, 112, 114

IP data network connections 17IP subnets 64

Llicense, VNX MirrorView/CE 7limits

LUN 5nas_cel passphrase 37, 40, 41

link down error 119, 126links, MirrorView/S 17listing

consistency group information 100device groups 51, 85

local file systems versus DR-protected file systems 27local standby configuration guidelines 30log files 121logical volumes 18login account 48, 78, 82LUNs

backend configuration of 28control LUN mapping 29mapping 18mirrored 17number of supported 5, 19overview of MirrorView/S 18

Mmanaging MirrorView/S 97mirroring Data Movers 30, 31MirrorView/S

basic configuration 17conceptual overview 16consistency groups 19disk types 115links 17, 119LUNs 18restrictions 7terminology 12tracking sheet 33troubleshooting 119

mixed configurations, restriction against 8modifying VNX for block security information 30, 114MPFS 14

restriction for 11

Nnames

device group 126nas_acl command 74nas_cel -create command 37nas_devicegroup command


-info 100-resume 105-suspend 104

nas_fs commandlisting snapshot information 54

nas_mview command 38-activate 37, 58-info 97-init 37, 45, 46, 75, 76, 79, 80-restore 38, 66, 93

nas_storage command-modify 114-sync 116

nasmcd restore 135network restoration phase 92not eligible for remote DR condition 106, 109NS series gateway configuration 8, 12

cabinets 33NSX gateway configuration 8, 12, 33

OOut-of-Sync state 100

Ppassphrase 48, 78, 82

for nas_cel preinitialization 41remote administrative 57, 89VNX for block administrative 45

physical volumes 18port requirements for MirrorView/S link 5ports, IP network 33postactivation script 64preinitializing MirrorView/S relationship 37

RRAID type requirement 5remote administration account

creating 48, 78, 82recommendations for active/active’ 28, 74specifying for failover 57, 89

remote mirror 14Replicator 11Replicator, restriction for IP and iSCSI replication 11, 27restoring

active/active 92active/active’ 92active/passive 65path requirement for 66, 93phases for 92VNX for file postfailover 38, 66, 93

restrictions for MirrorView/S 7resuming consistency group operation 105

Ssetup, initial 7SnapSure, restriction 11, 27source LUNs 18

backend configuration of 28

source VNX for file 45, 75, 79source-site failure 120source-site restore 135standby Data Movers 30, 31

sample configuration for active/active’ 73sample configuration for active/passive 45

state of source Data Movers during restore 136states of device group 100, 105storage configuration 17, 97storage processor failure 120, 125, 129

combined with source failure 121, 131recovering from single destination SPA 130

storage restoration phase 92su to root, care when using 10suspending consistency group operation 104symapi.log file 121Synchronized state 100synchronous MirrorView (MirrorView/S) 18System Fractured condition 101, 119, 121

Tterminology 12testing

active/active’ failover 88testing a failover 119trespassing LUNs 130, 131troubleshooting MirrorView/S 119

UUnisphere

restriction after failover 9viewing MirrorView disk types and storage pools 9, 12

upgrade options and guidelines 26use cases, summary of 17user interface 12user LUNs versus control LUNs 18

Vverifying

active/active’ MirrorView/S 84, 92active/passive MirrorView/S 60, 69

VNX cabinet configurations supported 5, 8, 12VNX FileMover 12, 13VNX for block account information 10VNX for block configuration 17, 18, 45VNX for block security information 30, 114volumes, configuring sites 30, 31

WWaiting on Sync condition 101write delays 18

144 of 146 Using MirrorView™ Synchronous with VNX™ for File forDisaster Recovery

Release 7.1


Notes

About this document

As part of its effort to continuously improve and enhance the performance and capabilities of the VNX product line, EMC periodically releases new versions of VNX hardware and software. Therefore, some functions described in this document may not be supported by all versions of VNX software or hardware presently in use. For the most up-to-date information on product features, see your product release notes. If your VNX 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-2012 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 Online Support.

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.

Release 7.1 146 of 146

Documents

EMC VNX Series - Dell EMC Korea · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 EMC® VNX™ Series Release 7.1 Using MirrorView