EMC
®
VNX
™
Series
Release 7.0
Using MirrorView
™
Synchronous with VNX
™
for File
for Disaster Recovery
P/N 300-011-859
Contents
Introduction . . . .4
System requirements . . . .4
Restrictions . . . .6
User interface choices . . . .12
Terminology . . . .12
Related information . . . .15
Concepts. . . .16
MirrorView/S . . . .17
MirrorView/S Configurations . . . .21
Comparison of VNX high-availability and replication products . . . .23
Planning considerations . . . .26
Task overview . . . .36
Configure MirrorView/S (active/passive) . . . .40
Preinitialize the configuration (active/passive) . . . .40
Initialize the configuration (active/passive) . . . .43
Activate a failover (active/passive) . . . .55
Restore the source VNX for file (active/passive) . . . .65
Configure MirrorView/S (active/active’) . . . .71
Initialize the configuration (active/active’) . . . .71
Activate a failover (active/active') . . . .87
Restore the source VNX for file (active/active’) . . . .92
Managing . . . .97
Check cabinet-level MirrorView/S information. . . .97
List device group information . . . .99
Get detailed device group information . . . .100
Suspend device group operations . . . .104
Resume device group operations . . . .105
Ensure Data Mover eligibility. . . .106
Change the Data Mover configuration . . . .112
Modify VNX for block security information after a failover. . . .114
Change file system configuration . . . .115
Troubleshooting. . . .118
Where to get help . . . .118
EMC E-Lab Interoperability Navigator . . . .118
Known problems and limitations . . . .118
Error messages. . . .138
EMC Training and Professional Services . . . .138
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 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.
Hardware
• 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.
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.
"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
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 CX4-480/CX4-960
(/w version 5.6.47 or later)
61 user data LUNs
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.
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.
•
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, 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.
•
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,
◆
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,
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 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.
destination LUN:
Mirrored copy of the data in the remote array. A destination LUN
represents a secondary image.
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: L
UN 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.
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), 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
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.
Dedicated MirrorView/S Link VNX for file
Host
VNX for file Host
VNX for block VNX for block Site B Destination PS0PS1PS2PS3PS4SMB0 SMB1 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 SB14 SB15 Site A Source PS0PS1PS2PS3PS4SMB0 SMB1 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 SB14 SB15 IP Data Network Connection Destination LUNs Source LUNs
Consistency group with mirrored 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
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.
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 Y1 Y1 Y1 Y1 Y1 VNX5500 Y Y Y1 Y1 Y1 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 VNX7500 Gateway 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 block Destination Destination LUNs VNX-000062 Copy Acknowledge 2 3 Acknowledge Write 1 4
*LUNs are part of a MirrorView consistency group (VNX for file device group) VNX for block
Source Source LUNs*
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
'
configurationSecond Consistency Group First Consistency Group
VNX for block Source VNX for block Destination Acknowledge Acknowledge Copy Copy VNX-000060 Destination LUNs Source LUNs Destination LUNs Source LUNs
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 Disaster Recovery 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.
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, 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.
Table 4 Comparison of VNX disaster recovery, high-availability, and replication products (page 2 of 3)
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.
Table 4 Comparison of VNX disaster recovery, high-availability, and replication products (page 3 of 3)
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.
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 highest-numbered port.
For example, port 3 for CX700/600 and CX3-80, and port 1 for CX500/400 and
CX3-40.
"MirrorView/S configuration through SP ports" on page 34
provides
more information about these ports.
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.
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.
◆
