EMC VNX Series Release 7.0

Transcription

1 EMC VNX Series Using MirrorView Synchronous with VNX for File for P/N REV A01 EMC Corporation Corporate Headquarters: Hopkinton, MA

2 2 of 144

3 Contents Introduction System requirements Restrictions User interface choices Terminology Related information Concepts MirrorView/S MirrorView/S Configurations Comparison of VNX high-availability and replication products Planning considerations Task overview Configure MirrorView/S (active/passive) Preinitialize the configuration (active/passive) Initialize the configuration (active/passive) Activate a failover (active/passive) Restore the source VNX for file (active/passive) Configure MirrorView/S (active/active ) Initialize the configuration (active/active ) Activate a failover (active/active') Restore the source VNX for file (active/active ) Managing Check cabinet-level MirrorView/S information List device group information Get detailed device group information Suspend device group operations Resume device group operations Ensure Data Mover eligibility Change the Data Mover configuration Modify VNX for block security information after a failover Change file system configuration Troubleshooting Where to get help EMC E-Lab Interoperability Navigator Known problems and limitations Error messages EMC Training and Professional Services Index of 144

4 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. 4 of 144

5 Table 1 System requirements (page 1 of 2) Software Hardware VNX for block Operating Environment version 19 or later on the source and destination CX 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. For VNX for block, minimum of two storage arrays, one at each site. Each 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. "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. Note: The EMC E-Lab TM Interoperability Navigator provides the full set of VNX for block gateway configuration guidelines. 5 of 144

6 Table 1 System requirements (page 2 of 2) Network Storage 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. Two attached VNX for file/vnx for block pairs. 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 depending on the VNX for block backend. Table 2 on page 6 lists the various user data LUN configurations. Table 2 User LUN configuration details Storage system CX400/CX500/CX3-20/AX4-5 CX600/CX700/CX3-80/CX3-40 CX4-120 CX4-120 (/w version or later) CX4-480/CX4-960 CX4-480/CX4-960 (/w version or later) User data LUNs 5 user data LUNs 13 user data LUNs 13 user data LUNs 29 user data LUNs 29 user data LUNs 61 user data LUNs "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 6 of 144

7 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 In version , 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. 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: 7 of 144

8 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. Only CX series and AX4-5 storage systems are permitted for MirrorView/S. 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: 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. 8 of 144

9 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. 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. 9 of 144

10 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. 10 of 144

11 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 event notification After a failover is activated, SNMP or 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. 11 of 144

12 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 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. 12 of 144

13 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 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, lessexpensive 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. 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. 13 of 144

14 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). 14 of 144

15 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 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 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. 15 of 144

16 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 , 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), 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. 16 of 144

17 SB8 SB6 SB4 SB2 SB0 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB9 SB7 SB5 SB3 SB1 SB8 SB6 SB4 SB2 SB0 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB9 SB7 SB5 SB3 SB1 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 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. Site A Source Site B Destination VNX for file Host SB14 SB12 SB10 SB15 SB13 SB11 IP Data Network Connection SB14 SB12 SB10 SB15 SB13 SB11 VNX for file Host Source LUNs Consistency group with mirrored LUNs Destination LUNs Dedicated MirrorView/S Link VNX for block VNX for block VNX 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. 17 of 144

18 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 highest-numbered port. 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 these ports. 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. 18 of 144

19 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 VNX7500 Gateway VG2 Gateway VG8 VNX5300 Y Y 1 Y 1 Y 1 Y 1 Y 1 VNX5500 Y Y Y 1 Y 1 Y 1 Y 1 VNX5700 Y Y Y Y 1 Y 1 Y 1 VNX7500 Y Y Y Y Y 1 Y 1 Gateway VG2 Y 1 Y Y 1 Y 1 Y Y 1 19 of 144

20 Table 3 VNX primary and standby system compatibility matrix (page 2 of 2) Primary/ Standby VNX5300 VNX5500 VNX5700 VNX7500 Gateway VG2 Gateway VG8 Gateway VG8 Y 1 Y 1 Y 1 Y 1 Y Y 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. 20 of 144

21 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. 1 Write 2 Copy 4 Acknowledge Source LUNs* VNX for block Source 3 Acknowledge Destination LUNs VNX for block Destination *LUNs are part of a MirrorView consistency group (VNX for file device group) Figure 2 MirrorView/S active/passive configuration VNX of 144

22 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. First Consistency Group Source LUNs Copy Acknowledge Destination LUNs Copy Second Consistency Group Destination LUNs Acknowledge Source LUNs VNX for block Source VNX for block Destination VNX Figure 3 MirrorView/S active/active' configuration 22 of 144

23 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, 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 provides more information about SRDF/S. Cannot be used in the same VNX for file configuration as MirrorView/S. Cannot be used with Automatic File System Extension. Performs volume cloning, not file system cloning. Remote volumes are accessible only after a failover. 23 of 144

24 Table 4 Comparison of VNX disaster recovery, high-availability, and replication products (page 2 of 3) Product Storage platform What it does Restrictions 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. Cannot be used with Automatic File System Extension. Performs volume cloning, not file system cloning. Remote volumes are accessible only after a failover. 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. Cannot be used with Automatic File System Extension. 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, pointin-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. 24 of 144