VPLEX 5.4 Product Guide

EMC VPLEX
GeoSynchrony
Version Number 5.4.1
Product Guide
P/N 302-001-064
REV 02
Copyright 2015 EMC Corporation. All rights reserved. Published in the USA.
Published February, 2015
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without
notice.
The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect
to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular
purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage
Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic
Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra,
Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation
Technology, Common Information Model, Configuration Intelligence, Connectrix, CopyCross, CopyPoint, CX, Dantz, Data Domain,
DatabaseXtender, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab,
EmailXaminer, EmailXtender, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File
Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, InputAccel, InputAccel Express, Invista,
Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, OnAlert, OpenScale, PixTools, Powerlink, PowerPath,
PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, SafeLine, SAN Advisor, SAN Copy, SAN
Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix,
Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, Viewlets, Virtual Matrix, Virtual Matrix
Architecture, Virtual Provisioning, VisualSAN, VisualSRM, VMAX, VNX, VNXe, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression,
xPresso, YottaYotta, the EMC logo, and the RSA logo, are registered trademarks or trademarks of EMC Corporation in the United States
and other countries. Vblock is a trademark of EMC Corporation in the United States.
All other trademarks used herein are the property of their respective owners.
For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section on the
EMC online support website.
EMC VPLEX Product Guide
CONTENTS
Preface
Chapter 1
Introducing VPLEX
VPLEX overview...........................................................................................
VPLEX product family ..................................................................................
Mobility ......................................................................................................
Availability..................................................................................................
Collaboration ..............................................................................................
Architecture highlights ................................................................................
Features and benefits .................................................................................
VPLEX Witness ............................................................................................
Non-disruptive upgrade (NDU) ....................................................................
New features in this release ........................................................................
Chapter 2
VS2 Hardware
The VPLEX cluster........................................................................................
The VPLEX engine and directors ..................................................................
VPLEX power supplies .................................................................................
Hardware failure management and best practices .......................................
Component IP addresses ............................................................................
Chapter 3
45
46
49
56
60
Integrity and Resiliency

About VPLEX resilience and integrity ...........................................................
Cluster ........................................................................................................
Path redundancy.........................................................................................
High Availability with VPLEX Witness ...........................................................
ALUA...........................................................................................................
Additional resilience features......................................................................
Performance monitoring and security features.............................................
Security features .........................................................................................
Chapter 5
27
32
34
35
41
VPLEX Software
GeoSynchrony.............................................................................................
Management interfaces...............................................................................
Provisioning with VPLEX ..............................................................................
Consistency groups.....................................................................................
Cache vaulting ............................................................................................
Chapter 4
13
15
17
19
20
20
22
22
24
25
63
64
65
69
76
76
79
81
VPLEX Use Cases

Technology refresh...................................................................................... 83
Mobility ...................................................................................................... 85
Collaboration .............................................................................................. 87
VPLEX Metro HA .......................................................................................... 88
Redundancy with RecoverPoint ................................................................... 96
MetroPoint................................................................................................ 106
EMC VPLEX GeoSynchrony Product Guide
Contents
................................................................................................................. 126
Appendix A
VS1 Hardware
VS1 cluster configurations ........................................................................
VS1 engine ...............................................................................................
VS1 IP addresses and component IDs .......................................................
VS1 Internal cabling ..................................................................................
Glossary
Index
127
130
130
132
FIGURES
Title
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Page
VPLEX active-active .....................................................................................................

VPLEX family: Local, Metro, and Geo............................................................................
Move data without disrupting service ..........................................................................
Data mobility with VPLEX Local, Metro, and Geo ..........................................................
High availability infrastructure example ......................................................................
Distributed data collaboration.....................................................................................
Architecture highlights ................................................................................................
How VPLEX Witness is deployed ..................................................................................
Management server - rear view....................................................................................
Fibre Channel switch - rear view ..................................................................................
VS2: Single-engine cluster ..........................................................................................
VS2: Dual-engine cluster .............................................................................................
VS2: Quad-engine cluster............................................................................................
Engine, rear view.........................................................................................................
VPLEX cluster independent power zones .....................................................................
Local mirrored volumes ...............................................................................................
Component IP addresses in cluster-1 ..........................................................................
Component IP addresses in cluster-2 ..........................................................................
Claim storage using the GUI ........................................................................................
Extents........................................................................................................................
Devices .......................................................................................................................
Distributed devices .....................................................................................................
Virtual volumes ...........................................................................................................
Local consistency groups with local visibility...............................................................
Local consistency group with global visibility ..............................................................
Path redundancy: different ports .................................................................................
Path redundancy: different directors ...........................................................................
Recommended fabric assignments for front-end and back-end ports...........................
Path redundancy: different engines.............................................................................
Path redundancy: different sites..................................................................................
High level VPLEX Witness architecture .........................................................................
Failure scenarios in VPLEX Metro configurations without VPLEX Witness......................
VPLEX Witness and VPLEX cluster connection failures .................................................
Performance monitoring - dashboard ..........................................................................
Performance monitoring - select information to view ...................................................
Performance monitoring - sample chart .......................................................................
Traditional view of storage arrays ................................................................................
VPLEX technology refresh ............................................................................................
Moving data with VPLEX ..............................................................................................
Mobility Central GUI ....................................................................................................
Collaborate over distance with AccessAnywhere .........................................................
VPLEX Metro HA ..........................................................................................................
VPLEX Metro HA (no cross-connect) cluster failure .......................................................
VPLEX Metro HA (no cross-connect) inter-cluster link failure ........................................
VPLEX Metro HA with cross-connect.............................................................................
VPLEX Metro HA with cross-connect - host failure ........................................................
VPLEX Metro HA with cross-connect - cluster failure.....................................................
VPLEX Metro HA with cross-connect - storage array failure ...........................................
VPLEX Metro HA with cross-connect - VPLEX Witness failure ........................................
VPLEX Metro HA with cross-connect - inter-cluster link failure ......................................
14
15
17
18
19
20
21
23
28
28
30
31
32
33
34
36
42
43
47
51
51
53
54
57
57
66
67
68
68
69
70
72
73
79
80
80
83
84
85
86
88
89
90
91
92
93
93
94
94
95
5
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
RecoverPoint architecture 97
RecoverPoint configurations 99
VPLEX Local and RecoverPoint 100
VPLEX Local and RecoverPoint Remote - remote site is independent VPLEX cluster
101
VPLEX Local and RecoverPoint remote - remote site is array-based splitter 101
VPLEX Metro and RecoverPoint local replication 102
VPLEX Metro and RecoverPoint local and remote replication- local site is located
at one cluster of the VPLEX. 102
VPLEX Metro and RecoverPoint local and remote replication- remote site is array-based splitter 103
Shared VPLEX splitter 104
Shared RecoverPoint RPA cluster 104
Replication with VPLEX Local and CLARiiON 105
Replication with VPLEX Metro and CLARiiON 105
Support for Site Recovery Manager 106
MetroPoint Two-site Topology 108
Basic MetroPoint Three-site Topology 109
RecoverPoint Local Replication for VPLEX Distributed Volumes at Site A and Site B
and RecoverPoint Remote Replication at Site C 110
Bi-directional replication for volumes in different consistency groups and local
volumes 111
Active Source Site A Failure 112
Remote Site C Failure 113
MetroPoint Four-Site Configuration 116
MetroPoint four-site configuration for a single consistency group 117
Site A and Site B failure showing failover to Site C 118
During failover, Site C and Site D become the production sites. 119
MetroPoint - two local copies 123
Source failover 124
Production failover to the remote copy 125
Recover production 126
VS1 single-engine cluster 127
VS1 dual-engine cluster 128
VS1 quad-engine cluster 129
VS1 engine 130
IP addresses in cluster-1 131
IP addresses in cluster-2 (VPLEX Metro or Geo) 132
Ethernet cabling - VS1 quad-engine cluster 134
Serial cabling - VS1 quad-engine cluster 135
Fibre Channel cabling - VS1 quad-engine cluster 136
AC power cabling - VS1 quad-engine cluster 137
Ethernet cabling - VS1 dual-engine cluster 138
Serial cabling - VS1 dual-engine cluster 139
Fibre Channel cabling- VS1 dual-engine cluster 140
AC power cabling - VS1 dual-engine cluster 141
Ethernet cabling - VS1 single-engine cluster 142
Serial cabling - VS1 single-engine cluster 142
Fibre Channel cabling - VS1 single-engine cluster 142
AC power cabling - VS1 single-engine cluster 143
Fibre Channel WAN COM connections - VS1 143
IP WAN COM connections - VS1 144
TABLES
Title
1
2
3
4
5
Page
VPLEX features and benefits........................................................................................

Hardware components ................................................................................................
GeoSynchrony AccessAnywhere features.....................................................................
Types of data mobility operations................................................................................
How VPLEX Metro HA recovers from failure ..................................................................
22
29
45
86
95
Tableses
PREFACE
As part of an effort to improve and enhance the performance and capabilities of its
product line, EMC from time to time releases revisions of its hardware and software.
Therefore, some functions described in this document may not be supported by all
revisions of the software or hardware currently in use. Your product release notes provide
the most up-to-date information on product features.
If a product does not function properly or does not function as described in this
document, please contact your EMC representative.
About this guide
Audience
This document provides a high level description of the VPLEX product and
GeoSynchrony 5.4 features.
This document is part of the VPLEX system documentation set and introduces the VPLEX
product and its features. This document provides information for customers and
prospective customers to understand VPLEX and how it supports their data storage
strategies.
Related documentation
Related documents (available on EMC Online Support) include:
EMC VPLEX Release Notes for GeoSynchrony Releases
EMC VPLEX Site Preparation Guide
EMC VPLEX Hardware Installation Guide
EMC VPLEX Configuration Worksheet
EMC VPLEX Configuration Guide
EMC VPLEX Security Configuration Guide
EMC VPLEX CLI Reference Guide
EMC VPLEX Administration Guide
VPLEX Management Console Help
EMC VPLEX Element Manager API Guide
EMC VPLEX Open-Source Licenses
EMC VPLEX GPL3 Open-Source Licenses
EMC Regulatory Statement for EMC VPLEX
Procedures provided through the Generator
EMC Host Connectivity Guides
Preface
Conventions used in this document

EMC uses the following conventions for special notices.
Note: A note presents information that is important, but not hazard-related.

A caution contains information essential to avoid data loss or damage to the system or
equipment.
IMPORTANT
An important notice contains information essential to operation of the software.
Typographical conventions
EMC uses the following type style conventions in this document:
Normal
Used in running (nonprocedural) text for:

Names of interface elements (such as names of windows, dialog boxes,
buttons, fields, and menus)
Names of resources, attributes, pools, Boolean expressions, buttons,
DQL statements, keywords, clauses, environment variables, functions,
utilities
URLs, pathnames, filenames, directory names, computer names,
filenames, links, groups, service keys, file systems, notifications
Bold
Used in running (nonprocedural) text for:

Names of commands, daemons, options, programs, processes,
services, applications, utilities, kernels, notifications, system call, man
pages
Used in procedures for:
Names of interface elements (such as names of windows, dialog boxes,
buttons, fields, and menus)
What user specifically selects, clicks, presses, or types
10
Italic
Used in all text (including procedures) for:

Full titles of publications referenced in text
Emphasis (for example a new term)
Variables
Courier
Used for:
System output, such as an error message or script
URLs, complete paths, filenames, prompts, and syntax when shown
outside of running text
Courier bold
Used for:
Specific user input (such as commands)
Courier italic
Used in procedures for:

Variables on command line
User input variables
[]
Square brackets enclose optional values
Vertical bar indicates alternate selections - the bar means or
{}
Braces indicate content that you must specify (that is, x or y or z)
...
Ellipses indicate nonessential information omitted from the example
Preface
Where to get help

EMC support and product information can be obtained as follows:
Product information For documentation, release notes, software updates, or information
about EMC products, go to EMC Online Support at:
https://support.emc.com
Technical support Go to EMC Online Support and click Service Center. You will see
several options for contacting EMC Technical Support. Note that to open a service request,
you must have a valid support agreement. Contact your EMC sales representative for
details about obtaining a valid support agreement or with questions about your account.
Online communities Visit EMC Community Network at https://community.EMC.com for
peer contacts, conversations, and content on product support and solutions. Interactively
engage online with customers, partners, and certified professionals for all EMC products.
Your comments
Your suggestions will help to improve the accuracy, organization, and overall quality of the
user publications. Send your opinions of this document to:
DPAD.Doc.Feedback@emc.com
11
Preface
12
CHAPTER 1
Introducing VPLEX
This chapter introduces the EMC VPLEX product family. Topics include:
VPLEX overview....................................................................................................... 13
VPLEX product family .............................................................................................. 15
Mobility .................................................................................................................. 17
Availability.............................................................................................................. 19
Collaboration .......................................................................................................... 20
VPLEX Witness ........................................................................................................ 22
Non-disruptive upgrade (NDU) ................................................................................ 24
New features in this release .................................................................................... 25
VPLEX overview
EMC VPLEX federates data that is located on heterogeneous storage arrays to create
dynamic, distributed and highly available data centers.
Use VPLEX to:
Move data nondisruptively between EMC and other third party storage arrays without
any downtime for the host.
VPLEX moves data transparently and the virtual volumes retain the same identities
and the same access points to the host. The is no need to reconfigure the host.
Collaborate over distance.

AccessAnywhere provides cache-consistent active-active access to data across VPLEX
clusters. Multiple users at different sites can work on the same data while maintaining
consistency of the dataset.
Protect data in the event of disasters or failure of components in your data centers.
With VPLEX, you can withstand failures of storage arrays, cluster components, an
entire site failure, or loss of communication between sites (when two clusters are
deployed) and still keep applications and data online and available.
Introducing VPLEX
13
Introducing VPLEX
With VPLEX, you can transform the delivery of IT to a flexible, efficient, reliable, and
resilient service.
Figure 1 VPLEX active-active
VPLEX addresses three primary IT needs:
Mobility: VPLEX moves applications and data between different storage installations:
Within the same data center or across a campus (VPLEX Local)
Within a geographical region (VPLEX Metro)
Across even greater distances (VPLEX Geo)
Availability: VPLEX creates high-availability storage infrastructure across these same

varied geographies with unmatched resiliency.
Collaboration: VPLEX provides efficient real-time data collaboration over distance for
Big Data applications.
VPLEX offers the following unique innovations and advantages:
VPLEX distributed/federated virtual storage enables new models of application and

Data Mobility.
VPLEX is optimized for virtual server platforms (VMware ESX, Hyper-V, Oracle Virtual
Machine, AIX VIOS).
VPLEX can streamline or accelerate transparent workload relocation over distances,
including moving virtual machines.
Size VPLEX to meet your current needs. Grow VPLEX as your needs grow.
A VPLEX cluster includes one, two, or four engines.
Add an engine to an operating VPLEX cluster without interrupting service.
Add a second cluster to an operating VPLEX cluster without interrupting service.
VPLEXs scalable architecture ensures maximum availability, fault tolerance, and
performance.
14
Every engine in a VPLEX cluster can access all the virtual volumes presented by VPLEX.
Introducing VPLEX
Every engine in a VPLEX cluster can access all the physical storage connected to
VPLEX.
In Metro and Geo configurations, VPLEX AccessAnywhere provides cache-consistent

active-active access to data across two VPLEX clusters.
VPLEX pools the storage resources in multiple data centers so that the data can be
accessed anywhere. With VPLEX, you can:
Provide continuous availability and workload mobility.
Replace your tedious data movement and technology refresh processes with VPLEXs
patented simple, frictionless two-way data exchange between locations.
Create an active-active configuration for the active use of resources at both sites.
Provide instant access to data between data centers. VPLEX allows simple, frictionless
two-way data exchange between locations.
Combine VPLEX with virtual servers to enable private and hybrid cloud computing.
VPLEX product family

The VPLEX product family includes:
VPLEX Local
VPLEX Metro
VPLEX Geo.
EMC VPLEX Local
EMC VPLEX Metro
EMC VPLEX Geo
Within a data center
AccessAnywhere at
synchronous
distances
AccessAnywhere at
asynchronous
distances
VPLX-000389
Figure 2 VPLEX family: Local, Metro, and Geo
VPLEX Local
VPLEX Local consists of a single cluster. VPLEX Local:
Federates EMC and non-EMC storage arrays.

Federation allows transparent data mobility between arrays for simple, fast data
movement and technology refreshes.
Standardizes LUN presentation and management using simple tools to provision and
allocate virtualized storage devices.
VPLEX product family
15
Introducing VPLEX
Improves storage utilization using pooling and capacity aggregation across multiple
arrays.
Increases protection and high availability for critical applications.

Mirrors storage across mixed platforms without host resources.
Leverage your existing storage resources to deliver increased protection and
availability for critical applications.
Deploy VPLEX Local within a single data center.
VPLEX Metro
VPLEX Metro consists of two VPLEX clusters connected by inter-cluster links with not more
than 5ms1 Round Trip Time (RTT). VPLEX Metro:
Transparently relocates data and applications over distance, protects your data center
against disaster, and enables efficient collaboration between sites.
Manage all of your storage in both data centers from one management interface.
Mirrors your data to a second site, with full access at near local speeds.
Deploy VPLEX Metro within a data center for:
Additional virtual storage capabilities beyond that of a VPLEX Local.
Higher availability.
Metro clusters can be placed up to 100 km apart, allowing them to be located at
opposite ends of an equipment room, on different floors, or in different fire
suppression zones; all of which might be the difference between riding through a local
fault or fire without an outage.
Deploy VPLEX Metro between data centers for:
Mobility: Redistribute application workloads between the two data centers.
Availability: Applications must keep running in the presence of data center failures.
Collaboration: Applications in one data center need to access data in the other data
center.
Distribution: One data center lacks space, power, or cooling.
Combine VPLEX Metro virtual storage and virtual servers to:
Transparently move virtual machines and storage across synchronous distances.
Improve utilization and availability across heterogeneous arrays and multiple sites.
Distance between clusters is limited by physical distance, by host and by application

requirements.
VPLEX Geo
VPLEX Geo consists of two VPLEX clusters connected by inter-cluster links with not more
than 50ms RTT. VPLEX Geo:
VPLEX Geo provides the same benefits as VPLEX Metro to data centers at asynchronous
distances:
1. Refer to VPLEX and vendor-specific white papers for confirmation of latency limitations.
16
Introducing VPLEX
Transparent application relocation
Increased resiliency
Efficient collaboration
Simplified management
As with any asynchronous transport media, bandwidth is critical to ensure optimal

performance.
Note: VPLEX Geo availability and performance are different than those of VPLEX Metro.
See Data caching on page 54 and Asynchronous consistency groups on page 58.
Grow your VPLEX

without disruption
Deploy VPLEX to meet your current high-availability and data mobility requirements.
Add engines or a second cluster to scale VPLEX as your requirements increase. You can do
all the following tasks without disrupting service:
Add engines to a VPLEX cluster.
Upgrade engine hardware from VS1 to VS2.
Convert a VPLEX Local to a VPLEX Metro or VPLEX Geo.
Upgrade GeoSynchrony.
Add or remove integration with RecoverPoint.
Mobility
VPLEX mobility allows you to move data located on either EMC or non-EMC storage arrays
simply and without disruption. Use VPLEX to simplify the management of your data center
and eliminate outages to migrate data or refresh technology.
Combine VPLEX with server virtualization to transparently move and relocate virtual
machines and their corresponding applications and data without downtime.
Figure 3 Move data without disrupting service
Mobility
17
Introducing VPLEX
Relocate, share, and balance resources between sites, within a campus or between data
centers.
In VPLEX Metro configurations, operations are synchronous and clusters can be

separated by up to 5 ms round trip time (RTT) latency.
In VPLEX Geo configurations, operations are asynchronous and clusters can be

separated by up to 50 ms RTT latency.
VPLEX Local
VPLEX Metro and Geo

Cluster A
ACCESS ANYWHERE
MOBILITY
Move data without impacting users

Heterogeneous nondisruptive
technology refreshes
Cluster B
Move data, VMs, and applications over distance

Active-Active data centers avoid disasters,
simplify migrations and workload balancing
Figure 4 Data mobility with VPLEX Local, Metro, and Geo
Use the storage and compute resources available at either of the VPLEX cluster locations
to automatically balance loads.
Move data between sites, over distance, while the data remains online and available
during the move. No outage or downtime is required.
VPLEX federates both EMC and non-EMC arrays, so even if you have a mixed storage
environment, VPLEX provides an easy solution.
Extent migrations move data between extents in the same cluster. Use extent migrations
to:
Move extents from a hot storage volume shared by other busy extents.
Defragment a storage volume to create more contiguous free space.
Migrate data between dissimilar arrays.
Device migrations move data between devices (RAID 0, RAID 1, or RAID C devices built on
extents or on other devices) on the same cluster or between devices on different clusters.
Use device migrations to:
Migrate data between dissimilar arrays.
Relocate a hot volume to a faster array.
Relocate devices to new arrays in a different cluster.
Use VPLEX to do an immediate migration between extents or devices, or create re-usable

migration plan files to automate routine tasks.
18
Introducing VPLEX
Note: Up to 25 local and 25 distributed migrations can be in progress at the same time.
Any migrations beyond those limits are queued until an ongoing migration completes.
Availability
VPLEX redundancy provides reduced Recovery Time Objective (RTO) and Recovery Point
Objective (RPO).
VPLEX features allow the highest possible resiliency in the event of an outage. Figure 5
shows a VPLEX Metro configuration where storage has become unavailable at one of the
cluster sites.
Cluster A
ACCESS ANYWHERE
Cluster B
Maintain availability and non - stop

access by mirroring across locations
Eliminate storage
operations from failover
Figure 5 High availability infrastructure example
Because VPLEXs GeoSynchrony AccessAnywhere mirrors all data, applications continue

without disruption using the back-end storage at the unaffected site.
Chapter 2, VS2 Hardware describes VPLEXs hardware redundancy.
Chapter 4, Integrity and Resiliency describes how VPLEX continues uninterrupted
service during unexpected failures.
Availability
19
Introducing VPLEX
Collaboration
Collaboration increases utilization of passive data recovery assets and provides
simultaneous access to data.
ACCESS ANYWHERE
Enable concurrent
read/write access to data
across locations
Figure 6 Distributed data collaboration
VPLEX AccessAnywhere enables multiple users at different sites to work on the same data
while maintaining consistency of the dataset.
Traditional solutions support collaboration across distance by shuttling entire files
between locations using FTP. This is slow and contributes to network congestion for large
files (or even small files that move regularly). One site may sit idle waiting to receive the
latest data. Independent work results in inconsistent data that must be synchronized, a
task that becomes more difficult and time-consuming as your data sets increase in size.
AccessAnywhere supports co-development that requires collaborative workflows such as
engineering, graphic arts, video, educational programs, design, and research.
VPLEX provides a scalable solution for collaboration.
Architecture highlights
A VPLEX cluster consists of:
One, two, or four VPLEX engines.

Each engine contains two directors.
Dual-engine or quad-engine clusters contain:
One pair of Fibre Channel switches for communication between directors.
Two Uninterruptible Power Sources (UPS) for battery power backup of the Fibre
Channel switches and the management server.
20
A management server.
Introducing VPLEX
The management server has a public Ethernet port, which provides cluster
management services when connected to the customer network.
HP, Oracle (Sun),
Microsoft, Linux, IBM Oracle, VMware, Microsoft
Brocade,
Cisco
VPLEX
Brocade,
Cisco
HP, Oracle (Sun), Hitachi, HP (3PAR), IBM, EMC
Figure 7 Architecture highlights
VPLEX conforms to established world wide naming (WWN) guidelines that can be used for
zoning.
VPLEX supports EMC storage and arrays from other storage vendors, such as HDS, HP, and
IBM.
VPLEX provides storage federation for operating systems and applications that support
clustered file systems, including both physical and virtual server environments with
VMware ESX and Microsoft Hyper-V.
VPLEX supports network fabrics from Brocade and Cisco.
Refer to the EMC Simple Support Matrix, EMC VPLEX and GeoSynchrony, available at
http://elabnavigator.EMC.com under the Simple Support Matrix tab.
Architecture highlights
21
Introducing VPLEX
Features and benefits

Table 1 summarizes VPLEX features and benefits.
Table 1 VPLEX features and benefits
Features
Benefits
Mobility
Migration: Move data and applications without impact on users.

Virtual Storage federation: Achieve transparent mobility and access within a
data center and between data centers.
Scale-out cluster architecture: Start small and grow larger with predictable
service levels.
Availability
Resiliency: Mirror across arrays within a single data center or between data
centers without host impact. This increases availability for critical
applications.
Distributed cache coherency: Automate sharing, balancing, and failover of I/O
across the cluster and between clusters whenever possible.
Advanced data caching: Improve I/O performance and reduce storage array
contention.
Collaboration
Distributed cache coherency: Automate sharing, balancing, and failover of I/O

across the cluster and between clusters whenever possible.
For all VPLEX products, GeoSynchrony:
Presents storage volumes from back-end arrays to VPLEX engines.
Federates the storage volumes into hierarchies of VPLEX virtual volumes with
user-defined configuration and protection levels.
Presents virtual volumes to production hosts in the SAN through the VPLEX front-end.
For VPLEX Metro and VPLEX Geo products, presents a global, block-level directory for
distributed cache and I/O between VPLEX clusters.
VPLEX Witness
VPLEX Witness helps multi-cluster VPLEX configurations automate the response to cluster
failures and inter-cluster link outages.
VPLEX Witness is an optional component installed as a virtual machine on a customer
host.

The customer host must be deployed in a separate failure domain from either of the
VPLEX clusters to eliminate the possibility of a single fault affecting both a cluster and
VPLEX Witness.
22
Introducing VPLEX
VPLEX Witness connects to both VPLEX clusters over the management IP network as
illustrated in Figure 8:
Figure 8 How VPLEX Witness is deployed
VPLEX Witness observes the state of the clusters, and thus can distinguish between an
outage of the inter-cluster link and a cluster failure. VPLEX Witness uses this information
to guide the clusters to either resume or suspend I/O.
In VPLEX Metro configurations, VPLEX Witness provides seamless zero RTO fail-over for
synchronous consistency groups.
In VPLEX Geo configurations, VPLEX Witness can be useful for diagnostic purposes.
Note: VPLEX Witness works in conjunction with consistency groups. VPLEX Witness
guidance does not apply to local volumes and distributed volumes that are not members
of a consistency group. VPLEX Witness does not automate any fail-over decisions for
asynchronous consistency groups (VPLEX Geo configurations).
High availability
compared to
disaster recovery
Highly available (HA) designs are typically deployed within a data center and disaster
recovery (DR) functionality is typically deployed between data centers.
Traditionally:
Data center components operate in active/active mode (or active/passive with

automatic failover).
Legacy replication technologies use active/passive techniques and require manual

failover to use the passive component.
When VPLEX Metro active/active replication technology is used in conjunction with VPLEX
Witness, the line between local high availability and long-distance disaster recovery is not
clear. With VPLEX Metro and VPLEX Witness, high availability is stretched beyond the data
center walls.
VPLEX Witness
23
Introducing VPLEX
Note: VPLEX Witness has no effect on failure handling for distributed volumes that are
outside of consistency groups or for volumes that are in asynchronous consistency
groups. Witness also has no effect on distributed volumes in synchronous consistency
groups when the preference rule is set to no-automatic-winner.
See High Availability with VPLEX Witness on page 69 for more information on VPLEX
Witness including the differences in how VPLEX Witness handles failures and recovery.
Non-disruptive upgrade (NDU)

VPLEX management server software and GeoSynchrony can be upgraded without
disruption.
VPLEX hardware can be replaced, the engine count in a cluster increased, and a VPLEX
Local can be expanded to a VPLEX Metro or Geo without disruption.
VPLEX never has to be completely shut down.
Storage,
application, and
host upgrades
VPLEX enables the easy addition or removal of storage, applications, and hosts.
When VPLEX encapsulates back-end storage, the block-level nature of the coherent cache
allows the upgrade of storage, applications, and hosts.
You can configure VPLEX so that all devices within VPLEX have uniform access to all
storage blocks.
Increase engine
count
When capacity demands increase, VPLEX supports hardware upgrades for single-engine
VPLEX systems to dual-engine and dual-engine to quad-engine VPLEX systems.
These upgrades also increase the availability of front-end and back-end ports in the data
center.
Software upgrades
VPLEX is fully redundant for:
Ports
Paths
Directors
Engines
This redundancy allows GeoSynchrony on VPLEX Local and Metro to be upgraded without
interrupting host access to storage, it does not require service window or application
disruption.
On VPLEX Geo configurations, the upgrade script ensures that the application is
active/passive before allowing the upgrade.
Note: You must upgrade the VPLEX management server software before upgrading
GeoSynchrony. Management server upgrades are non-disruptive.
24
Introducing VPLEX
Simple support
matrix
EMC publishes storage array interoperability information in a Simple Support Matrix

available on EMC Online Support. This information details tested, compatible
combinations of storage hardware and applications that VPLEX supports. The Simple
Support Matrix can be located at:
https://support.emc.com/search
New features in this release

Release 5.4 includes the following new feature:
MetroPoint
MetroPoint provides the highest levels of protection and redundancy against full site
failures, regional-wide failures, data corruption, and other such events. It combines
the full value of VPLEX and RecoverPoint into a 3-site or 4-site topology for continuous
availability, disaster recovery, and continuous data protection. The MetroPoint
topology provides users full RecoverPoint protection for their VPLEX Metro
configuration, maintaining replication even when one site of the Metro is down.
MetroPoint protects customer applications and data from any failure scenario,
including:
Any single component failure
A complete site failure
A regional failure that affects two sites
Data unavailability due to user errors
Data corruption from viruses
In a MetroPoint two-site configuration, RecoverPoint Local Replication is added to both
sides of a VPLEX Metro to provide operational recovery for the same application.
Although this is not a typical MetroPoint configuration, it still requires the latest
software that supports MetroPoint on both VPLEX and RecoverPoint. The configuration
can be updated in future by adding a third remote site for full MetroPoint protection
and disaster recovery.
In a MetroPoint three-site configuration, data replication to the remote site continues
even if one of the local sites fails completely, and local replication is allowed on both
local sites at the same time for maximum protection.
In a MetroPoint four-site configuration, MetroPoint provides continuous availability for
production applications running in two separate regions. Each region provides
disaster recovery protection for the other region.
The VPLEX Administration Guide provides more information on configuring and
managing MetroPoint.
New features in this release
25
Introducing VPLEX
26
CHAPTER 2
VS2 Hardware
This chapter provides a high-level overview of the major hardware components in a VS2
VPLEX and how hardware failures are managed to support uninterrupted service.
Topics include:
The VPLEX cluster....................................................................................................

The VPLEX engine and directors ..............................................................................
VPLEX power supplies .............................................................................................
Power and environmental monitoring ......................................................................
Hardware failure management and best practices ...................................................
Component IP addresses ........................................................................................
27
32
34
35
35
41
Note: See Appendix A, VS1 Hardware. for information about VS1 hardware.
The VPLEX cluster

There are two generations of VS hardware: VS1 and VS2. A VPLEX cluster (either VS1 or
VS2) consists of:
1, 2, or 4 VPLEX engines
Each engine contains two directors.
Dual-engine or quad-engine clusters also contain:
1 pair of Fibre Channel switches for communication between directors.
2 uninterruptible power supplies (UPS) for battery power backup of the Fibre
Channel switches and the management server.
A management server.
Ethernet or Fibre Channel cabling and respective switching hardware that connects the
distributed VPLEX hardware components.
I/O modules provide front-end and back-end connectivity between SANs and to
remote VPLEX clusters in VPLEX Metro or VPLEX Geo configurations.
Note: In the current release of GeoSynchrony, VS1 and VS2 hardware cannot co-exist in a
cluster, except in a VPLEX Local cluster during a non disruptive hardware upgrade from
VS1 to VS2.
VS2 Hardware
27
VS2 Hardware
Management server
Each VPLEX cluster has one management server.
Figure 9 Management server - rear view
You can manage both clusters in VPLEX Metro and VPLEX Geo configurations from a single
management server.
The management server:
Coordinates data collection, VPLEX software upgrades, configuration interfaces,

diagnostics, event notifications, and some director-to-director communication.
Forwards VPLEX Witness traffic between directors in the local cluster and the remote
VPLEX Witness server.
Redundant internal network IP interfaces connect the management server to the public
network. Internally, the management server is on a dedicated management IP network
that provides accessibility to all major components in the cluster.
Fibre Channel switches

Fibre Channel switches provide high availability and redundant connectivity between
directors and engines in a dual-engine or quad-engine cluster.
Figure 10 Fibre Channel switch - rear view
Each Fibre Channel switch is powered by a UPS, and has redundant I/O ports for
intra-cluster communication.
The Fibre Channel switches do not connect to the front-end hosts or back-end storage.
1, 2, or 4 VPLEX engines
A VPLEX cluster can have 1 (single), 2 (dual), or 4 (quad) engines.
Figure 11 on page 30 shows a single-engine cluster for VS2.
Figure 12 on page 31 shows a dual-engine cluster for VS2.
Figure 13 on page 32 shows a quad-engine cluster for VS2.
Note: The placement of components shown for single-engine and dual-engine clusters
allows for non disruptive addition of engines to scale the cluster to a larger configuration.
Table 2 describes the major components of a VPLEX cluster and their functions.
28
VS2 Hardware
Table 2 Hardware components

Component
Description
Engine
Contains two directors, with each director providing front-end and

back-end I/O connections.
Director
Contains:
Five I/O modules (IOMs), as identified in Figure 14 on page 33
Management module for intra-cluster communication
Two redundant 400 W power supplies with built-in fans
CPU
Solid-state disk (SSD) that contains the GeoSynchrony operating
environment
RAM
Management server
Provides:
Management interface to a public IP network
Management interfaces to other VPLEX components in the cluster
Event logging service
Fibre Channel COM

switches (Dual-engine or
quad-engine cluster
only)
Provides intra-cluster communication support among the directors.

This is separate from the storage I/O.
Power subsystem
Power distribution panels (PDPs) connect to the AC power source of

the site and transfer power to the VPLEX components through power
distribution units (PDUs). This provides a centralized power interface
and distribution control for the power input lines.
The PDPs contain manual on/off power switches for their power
receptacles.
Standby Power Supply

(SPS)
One SPS assembly (two SPS modules) provides backup power to each
engine in the event of an AC power interruption. Each SPS module
maintains power for two five-minute periods of AC loss while the
engine shuts down.
Uninterruptible Power
Supply (UPS)
(Dual-engine or
quad-engine cluster
only)
One UPS provides battery backup for Fibre Channel switch A and the
management server, and a second UPS provides battery backup for
Fibre Channel switch B. Each UPS module maintains power for two
five-minute periods of AC loss while the engine shuts down.
The VPLEX cluster
29
VS2 Hardware
VS2 single-engine cluster
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
Laptop tray
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
Engine 1, Director B
SPS 1B
Management server
Engine 1, Director A
SPS 1A
VPLX-000226
Figure 11 VS2: Single-engine cluster
30
VS2 Hardware
VS2 dual-engine cluster
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
Laptop tray
Fibre Channel switch B

UPS B
Fibre Channel switch A

UPS A
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
SPS 2B
Management server
SPS 2A
O
OFF
O
OFF
ON
I
ON
I
SPS 1B
SPS 1A
VPLX-000227
Figure 12 VS2: Dual-engine cluster
The VPLEX cluster
31
VS2 Hardware
VS2 quad-engine cluster
ON
I
ON
I
O
OFF
O
OFF
SPS 4B
SPS 4A
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
SPS 3B
SPS 3A
Laptop tray

UPS B

UPS A
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
SPS 2B
Management server
SPS 2A
O
OFF
O
OFF
ON
I
ON
I
SPS 1B
SPS 1A
VPLX-000228
Figure 13 VS2: Quad-engine cluster
The VPLEX engine and directors

A VPLEX cluster can include 1, 2, or 4 engines.
Each VPLEX engine includes two directors.
Each director provides front-end and back-end I/O connections.
32
VS2 Hardware
Director B
IOM A4 - reserved
IOM A3 - Local COM
IOM A2 - WAN COM
IOM A1 - Back end
IOM A0 - Front end
Management module A
IOM B4 - reserved
IOM B3 - Local COM
IOM B2 - WAN COM
IOM B1 - Back end
IOM B0 - Front end
Management module B
Figure 14 shows a VPLEX engine and its two directors: Director A and Director B.
Director A
Depending on the cluster topology, slots A2 and B2 contain one of the following
I/O modules (IOMs) (both IOMs must be the same type):
8 Gb/s
Fibre Channel
10 Gb/s
Ethernet
Filler module
(VPLEX Local only)
VPLX-000229
Figure 14 Engine, rear view
The GeoSynchrony operating system runs on the VPLEX directors, and supports:
I/O request processing
Distributed cache management
Virtual-to-physical translations
Interaction with storage arrays
Front-end and back-end connectivity

Redundant I/O modules provide connectivity to the front-end and back-end ports:
Four 8 Gb/s Fibre Channel I/O modules provide front-end connectivity.
Four 8 Gb/s ports provide back-end connectivity.
Industry-standard Fibre Channel ports connect to host initiators and storage devices.
WAN connectivity
For VPLEX Metro and Geo configurations, dual inter-cluster WAN links connect the two
clusters.
Clusters in a VPLEX Metro can be connected by either Fibre Channel (8 Gbps) or

Gigabit Ethernet (10 GbE).
The VPLEX engine and directors
33
VS2 Hardware
Clusters in a VPLEX Geo are connected by Gigabit Ethernet.
For Fibre Channel connections, IOMs A2 and B2 contain four Fibre Channel ports.
For IP connections, IOMs A2 and B2 contain two Ethernet ports.

The inter cluster link carries unencrypted user data. To protect the security of the data,
secure connections are required between clusters.
Redundant I/O paths

Within an engine, a director is connected to its peer director over an internal
communication channel. Between engines, directors are connected over dual Fibre
Channel switches.
All VPLEX directors participate in intra-cluster communications.
When properly zoned and configured, the front-end and back-end connections provide
redundant I/O paths that can be serviced by any director.
VPLEX power supplies

The VPLEX cluster is connected to your AC power source. Each cluster is equipped with
standby and uninterruptible power supplies that enable the cluster to ride out power
disruptions.
AC power connection
Connect your VPLEX cluster to two independent power zones to assure a highly available
power distribution configuration.
Figure 15 shows AC power supplied from independent power distribution units (PDUs):
Customer
PDU 1
Circuit
breaker
off (0)
Circuit
breaker
off (0)
Circuit breakers - Numbers

27
Circuit breakers - Numbers
28
PDU 1
CB 28
29
30
10
...
11
PDU 2
CB 9
EMC
cabinet, rear
Labels on
customer
power lines
PDPs
Power Zone
Lower B Lower A
PDU#
Panel#
CB#(s)
PDU#
Panel#
28
Power
zone B
(black)
CB#(s)
Cabinet serial number
Figure 15 VPLEX cluster independent power zones

34
Customer
PDU 2
Power
zone A
(gray)
...
VS2 Hardware
This is a required configuration to assure high availability.

The power supply module is field-replaceable. When power supplies are replaced one at a
time, no disruption of service occurs.
VPLEX power distribution panels (PDPs) contain manual on/off power switches for their
power receptacles.
For additional information on power requirements and practices, see the EMC Best
Practices Guide for AC Power Connections in Two-PDP Bays.
Standby power
supplies
Each engine is connected to two standby power supplies (SPS) that provide battery
backup to each director.
SPSs have sufficient capacity to ride through transient site power failures or to vault their
cache when power is not restored within 30 seconds.
A single standby power supply provides enough power for the attached engine to ride
through two back-to-back 5-minute losses of power.
Refer to Protection from power failure on page 78.
Uninterruptible
power supplies
Dual and quad engine clusters include two uninterruptible power supplies, UPS-A and
UPS-B.
In the event of a power failure:
UPS-A provides power to the management server and Fibre Channel switch A.
UPS-B provides power to Fibre Channel switch B.
The two UPS units provide sufficient power to support the Fibre Channel switches and
management server for two back-to-back 5-minute power outages.
Power and
environmental
monitoring
GeoSynchrony monitors the overall health of the VPLEX cluster and the environment for
the VPLEX cluster hardware.
Power and environmental conditions are monitored at regular intervals. Any changes to
the VPLEX power or hardware health are logged.
Conditions that indicate a hardware or power fault generate a call-home event.
Hardware failure management and best practices

This section describes how VPLEX component failures are handled, and the best practices
that allow applications to tolerate these failures.
All critical processing components of a VPLEX system use pair-wise redundancy at a
minimum to maximize data availability.
Note: All VPLEX hardware component failures are reported to the EMC Service Center to
ensure timely response and repair of these fault conditions.
35
VS2 Hardware
Storage array
failures
VPLEX makes it easy to mirror the data of a virtual volume between two or more storage
volumes using a RAID 1 device.
When a mirror is configured, a failed array or planned outage does not interrupt service.
I/O continues on the healthy leg of the device. When the failed/removed array is restored,
the VPLEX system uses the information in logging volumes to synchronize the mirrors.
Only the changed blocks are synchronized, therefore minimizing the inter-cluster traffic.
Figure 16 shows a virtual volume mirrored between two arrays.
Figure 16 Local mirrored volumes
Best practices: local

mirrored volumes
Fibre Channel port

failures
For critical data, mirror data on two or more storage volumes that are located on
separate arrays.
For the best performance, storage volumes at each leg of the distributed device should
be the same size and hosted on arrays with the same performance characteristics.
VPLEX communications use redundant paths that allow communication to continue during
port failures. This redundancy allows multipathing software to redirect I/O around path
failures that occur as part of port failures.
VPLEX has its own multipathing logic that maintains redundant paths to back-end storage
from each director. This allows VPLEX to continue uninterrupted during failures of the
back-end ports, back-end fabric, and the array ports that connect the physical storage to
VPLEX.
The small form-factor pluggable (SFP) transceivers used for connectivity to VPLEX are field
replaceable units (FRUs).
Best practices: Fibre

Channel ports
To ensure the highest reliability of your configuration:

Front end:
36
Ensure that there is a path from each host to at least one front-end port on director A
and at least one front-end port on director B.
VS2 Hardware
When the VPLEX cluster has two or more engines, ensure that the host has at least one
A-side path on one engine and at least one B-side on a separate engine.
For maximum availability, each host can have a path to at least one front-end port on
every director.
Use multi-pathing software on the host servers to ensure timely response and
continuous I/O in the presence of path failures.
Ensure that each host has a path to each virtual volume through each fabric.
Ensure that the fabric zoning provides hosts redundant access to the VPLEX front-end
ports.
Back end:
Ensure that the logical unit number (LUN) mapping and masking for each storage
volume presented from a storage array to VPLEX presents the volumes out of at least
two ports from the array and on at least two different fabrics from different controllers.
Ensure that the LUN connects to at least two different back end ports of each director
within a VPLEX cluster.
Active/passive arrays must have one active and one passive port zoned to each
director, and zoning must provide VPLEX with the redundant access to the array ports.
Configure a maximum of four paths between a director and the LUN.

Note: On VS2 hardware, only 4 physical ports are available for back end connections
on each director. Refer to the VPLEX Configuration Guide for details on the hardware
configuration you are using.
I/O module failures
VPLEX I/O modules serve dedicated roles.

For VS2 hardware, each VPLEX director has:
One front-end I/O module and one back-end I/O module,
One COM I/O module used for intra-cluster and inter-cluster connectivity.
Each I/O module is a serviceable FRU. The following sections describe the behavior of the
system.
Front end I/O module
Failure of a front end I/O module causes all paths that are connected to the failed module
to fail. VPLEX automatically sends a call-home notification.
Follow the guideline described in Best practices: Fibre Channel ports on page 36 to
ensure that hosts have a redundant path to their data.
During the removal and replacement of an I/O module, the affected director resets.
Back end I/O module
Failure of a back end I/O module causes all paths that are connected to the failed module
to fail. VPLEX automatically sends a call-home notification.
Follow the guidelines described in Best practices: Fibre Channel ports on page 36 to
ensure that each director has a redundant path to each storage volume through a separate
I/O module.
During the removal and replacement of an I/O module, the affected director resets.
37
VS2 Hardware
COM I/O module
Failure of the local COM I/O module of a director causes the director to reset and stops all
service provided from that director.
ensure that each host has redundant access to its virtual storage through multiple
directors.
During the removal and replacement of a local I/O module, the affected director resets. If
best practices are followed, the reset of a single director does not cause the host to lose
access to its storage.
Director failure
Failure of a director causes the loss of all service from that director. The second director in
the engine continues to service I/O.
VPLEX clusters containing two or more engines benefit from the additional redundancy
provided by the additional directors.
Each director within a cluster is capable of presenting the same storage.
allow a host to ride through director failures by placing redundant paths to their virtual
storage through ports provided by different directors.
The combination of multipathing software on the hosts and redundant paths through
different directors of the VPLEX system allows the host to ride through the loss of a
director.
Each director is a serviceable FRU.
Intra-cluster IP
management
network failure
In Metro and Geo configurations, VPLEX clusters are connected by a pair of private local IP
subnets between directors and the management server. The subnets:
Carry management traffic
Protect against intra-cluster partitioning
Connect the VPLEX Witness server (if it is deployed) and the directors.
Failure on one of these subnets can result in the inability of some subnet members to
communicate with other members on that subnet.
Because the subnets are redundant, failure of one subnet results in no loss of service or
manageability.
Note: Failure of a single subnet may result in loss of connectivity between the director and
VPLEX Witness.
Intra-cluster Fibre
Channel switch
failure
Dual and quad engine clusters include a pair of dedicated Fibre Channel switches for
intra-cluster communication between the directors within the cluster.
Two redundant Fibre Channel fabrics are created. Each switch serves a different fabric.
Failure of a single Fibre Channel switch results in no loss of processing or service.
38
VS2 Hardware
Inter-cluster WAN
links
Best practices
In VPLEX Metro and VPLEX Geo configurations, the clusters are connected through
redundant WAN links that you provide.
When configuring the inter-cluster network:
Latency must be less than 5 milliseconds (ms) round trip time (RTT) for a VPLEX Metro,
and less than 50ms RTT for a VPLEX Geo.
Link speed must be a minimum of 45Mb/s of bandwidth.

The required bandwidth is dependent on the I/O pattern and must be high enough for
all writes to all distributed volumes to be exchanged between clusters.
Power supply failures
Switches supporting the WAN links must be configured with a battery backup UPS.
Have physically independent WAN links for redundancy.
Every WAN port on every director must be able to connect to a WAN port on every
director in the other cluster.
Logically isolate VPLEX Metro /Geo traffic from other WAN traffic using VSANs or
LSANs.
Use independent inter switch links (ISLs) for redundancy.
Deploy VPLEX Witness in an independent failure domain.
Each VPLEX cluster provides two zones of AC power.

If one zone loses power, the modules in the cluster continue to run using power from the
other zone.
If both zones lose power, the engines revert to power from their SPS modules.
In multi-engine clusters, the management server and intra cluster Fibre Channel switches
revert to the power supplied by the UPS.
SPS/UPS failures
Each standby power supply (SPS) is a field replaceable unit (FRU) and can be replaced with
no disruption.
SPS batteries support two sequential outages (not greater than 5 minutes) without data
loss. The recharge time for an SPS is up to 5.5 hours.
Each uninterruptible power supply (UPS) is a FRU and can be replaced with no disruption.
UPS modules support two sequential outages (not greater than 5 minutes) to the Fibre
Channel switches in a multi-engine cluster. The recharge time for a UPS to reach 90%
capacity is 6 hours.
Note: While the batteries can support two 5-minute power losses, the VPLEX Local, VPLEX
Metro, or VPLEX Geo cluster vaults after a 30 second power loss to ensure that there is
enough battery power to complete the cache vault.
39
VS2 Hardware
Power failures that cause vault

Note: Vaulting is a mechanism to prevent data loss when an external environmental
condition causes a cluster failure. For example, if a power failure lasts longer than 30
seconds in a VPLEX Geo configuration, then each VPLEX director copies its dirty cache
data to the local solid state storage devices (SSDs). Known as vaulting, this process
protects user data in cache if that data is at risk due to power loss. After each director
vaults its dirty cache pages, then VPLEX shuts down the directors firmware.
Vaulting is evolving rapidly with each release of GeoSynchrony. The events and/or
conditions that trigger cache vaulting vary depending on the release and are as follows:
Release 5.0.1:
Vaulting is introduced.
On all configurations, vaulting is triggered if all following conditions are met:

AC power is lost (due to power failure, faulty hardware, or power supply is not
present) in power zone A from engine X.
AC power is lost (due to power failure, faulty hardware, or power supply is not
present) in power zone B from engine Y.
(X and Y would be the same in a single engine configuration but they may or may
not be the same in dual or quad engine configurations).
Both conditions persist for more than 30 seconds.
Release 5.0.1 Patch:
On all configurations, vaulting is triggered if all the following conditions are met:
AC power is lost (due to power failure or faulty hardware) in power zone A from
engine X.
AC power is lost (due to power failure or faulty hardware) in power zone B from
engine Y.
Release 5.1:
In a VPLEX Geo configuration with asynchronous consistency groups, vaulting is

triggered if all the following conditions are met:
AC power is lost (due to power failure or faulty hardware) or becomes unknown
in a director from engine X.
in director from engine Y.
40
VS2 Hardware
In a VPLEX Local or VPLEX Metro configuration, vaulting is triggered if all the following
conditions are met:
in the minimum number of directors required for the cluster to be operational.
Condition persist for more than 30 seconds.
Note: UPS power conditions do not trigger any vaulting.
VPLEX Witness
failure
If VPLEX Witness is deployed, failure of the VPLEX Witness has no impact on I/O as long as
the two clusters stay connected with each other.
If a cluster fails or inter-cluster network partition occurs while VPLEX Witness is down, then
there will be data unavailability on all surviving clusters.
Best practice
Best practice is to disable VPLEX Witness (while the clusters are still connected) if its
outage is expected to be long, and then revert to using preconfigured detach rules.
Once VPLEX Witness recovers, re-enable VPLEX Witness.
Refer to the EMC VPLEX CLI Guide for information about the commands to disable and
enable VPLEX Witness.
VPLEX
management
server failure
I/O processing of the VPLEX directors does not depend on the management servers. Thus,
in most cases failure of a management server does not interrupt the I/O processing.
VPLEX Witness traffic traverses the management server. If the management server fails in
a configuration where VPLEX Witness is deployed, then the VPLEX Witness cannot
communicate with the cluster.
Failure of the remote VPLEX cluster results in data unavailability. Failure of only the
inter-cluster network has no effect. The remote cluster continues I/O processing
regardless of preference because it is still connected to VPLEX Witness1.
Best practice
Best practice is to disable VPLEX Witness (while the clusters are still connected) if its
outage is expected to be long, and then revert to using preconfigured detach rules.
When the management server is replaced or repaired, use the cluster-witness enable CLI
command to re-enable VPLEX Witness.
Refer to the EMC VPLEX CLI Guide for information about the commands to disable and
enable VPLEX Witness.
Component IP addresses
This section provides details about the IP addresses that are used to connect the
components within a VPLEX cluster.
1. This description applies only to synchronous consistency groups with a rule setting that identifies
a specific preference.
41
VS2 Hardware
IP addresses cluster-1
Cluster IP Seed = 1
Enclosure IDs = engine numbers
Engine 4:
Director 4B, A side: 128.221.252.42
Director 4B, B side: 128.221.253.42
Engine 4:
Director 4A, A side: 128.221.252.41
Director 4A, B side: 128.221.253.41
Engine 3:
Engine 3:
FC switch B 128.221.253.34
Service port
128.221.252.2
Public Ethernet port

Customer-assigned
FC switch A 128.221.252.34
Mgt B port
128.221.253.33
Mgt A port
128.221.252.33
Management server
Engine 2:
Engine 2:
Engine 1:
Engine 1:
VPLX-000242
Figure 17 Component IP addresses in cluster-1
42
VS2 Hardware
IP addresses - cluster-2
Cluster IP Seed = 2
Engine 4:
Engine 4:
Engine 3:
Engine 3:
FC switch B 128.221.253.66
Service port
128.221.252.2

Customer-assigned
FC switch A 128.221.252.66
Mgt B port
128.221.253.65
Mgt A port
128.221.252.65
Management server
Engine 2:
Engine 2:
Engine 1:
Engine 1:
VPLX-000243
Figure 18 Component IP addresses in cluster-2
43
VS2 Hardware
44
CHAPTER 3
VPLEX Software
This chapter describes the major components of VPLEX software. Topics include:
GeoSynchrony.........................................................................................................
Management interfaces...........................................................................................
Provisioning with VPLEX ..........................................................................................
Data caching ...........................................................................................................
Consistency groups .................................................................................................
Cache vaulting ........................................................................................................
45
46
49
54
56
60
GeoSynchrony
GeoSynchrony is the operating system that runs on the VPLEX directors. GeoSynchrony
runs on both VS1 and VS2 hardware.
GeoSynchrony is:
Designed for highly available, robust operation in geographically distributed

environments,
Driven by real-time I/O operations,
Intelligent about locality of access,
Designed to provide the global directory that supports AccessAnywhere.
Table 3 summarizes features provided by GeoSynchrony and AccessAnywhere:

Table 3 GeoSynchrony AccessAnywhere features
Feature
Description and considerations
Storage volume
encapsulation
LUNs on a back-end array can be imported into an instance of VPLEX and

used while keeping their data intact.
Considerations: The storage volume retains the existing data on the device
and leverages the media protection and device characteristics of the
back-end LUN.
RAID 0
VPLEX devices can be aggregated to create a RAID 0 striped device.

Considerations: Improves performance by striping I/Os across LUNs.
RAID-C
VPLEX devices can be concatenated to form a new larger device.

Considerations: A larger device can be created by combining two or more
smaller devices.
VPLEX Software
45
VPLEX Software
Table 3 GeoSynchrony AccessAnywhere features

Feature
Description and considerations
RAID 1
VPLEX devices can be mirrored within a site.

Considerations: Withstands a device failure within the mirrored pair.
A device rebuild is a simple copy from the remaining device to the newly
repaired device. Rebuilds are done in incremental fashion, whenever
possible.
The number of required devices is twice the amount required to store data
(actual storage capacity of a mirrored array is 50%).
The RAID 1 devices can come from different back-end array LUNs providing
the ability to tolerate the failure of a back-end array.
Distributed RAID
1
VPLEX devices can be mirrored between sites.
Extents
Storage volumes can be broken into extents and devices can be created from
these extents.
Considerations: Provides protection from site disasters and supports the

ability to move data between geographically separate locations.
Considerations: Use extents when LUNs from a back-end storage array are
larger than the desired LUN size for a host. This provides a convenient way of
allocating what is needed while taking advantage of the dynamic thin
allocation capabilities of the back-end array.
Migration
Volumes can be migrated non-disruptively to other storage systems.

Considerations: Use migration for changing the quality of service of a volume
or for performing technology refresh operations.
Global Visibility
The presentation of a volume from one VPLEX cluster where the physical
storage for the volume is provided by a remote VPLEX cluster.
Considerations: Use Global Visibility for AccessAnywhere collaboration
between locations. The cluster without local storage for the volume will use
its local cache to service I/O but non-cached operations incur remote
latencies to write or read the data.
Management interfaces
In VPLEX Metro and VPLEX Geo configurations, both clusters can be managed from either
management server.
Inside VPLEX clusters, management traffic traverses a TCP/IP based private management
network.
In VPLEX Metro and VPLEX Geo configurations, management traffic traverses a VPN tunnel
between the management servers on both clusters.
Web-based GUI
VPLEXs web-based graphical user interface (GUI) provides an easy-to-use point-and-click

management interface.
Figure 19 shows the screen to claim storage:
46
VPLEX Software
Figure 19 Claim storage using the GUI
The GUI supports most of the VPLEX operations, and includes EMC Unisphere for VPLEX
online help to assist new users in learning the interface.
VPLEX operations that are not available in the GUI, are supported by the Command Line
Interface (CLI), which supports full functionality.
VPLEX CLI
The VPLEX CLI supports all VPLEX operations.

The CLI is divided into command contexts:
Global commands are accessible from all contexts.
Other commands are arranged in a hierarchical context tree, and can be executed only
from the appropriate location in the context tree.
Example 1 shows a CLI session that performs the same tasks as shown in Figure 19.
Example 1 Claim storage using the CLI:
In the following example, the claimingwizard command finds unclaimed storage volumes,
claims them as thin storage, and assigns names from a CLARiiON hints file:
VPlexcli:/clusters/cluster-1/storage-elements/storage-vol
umes> claimingwizard --file /home/service/clar.txt
--thin-rebuild
Found unclaimed storage-volume
VPD83T3:6006016091c50e004f57534d0c17e011 vendor DGC:
claiming and naming clar_LUN82.
Found unclaimed storage-volume
VPD83T3:6006016091c50e005157534d0c17e011 vendor DGC:
claiming and naming clar_LUN84.
Claimed 2 storage-volumes in storage array car
Claimed 2 storage-volumes in total.
Management interfaces
47
VPLEX Software
VPlexcli:/clusters/cluster-1/storage-elements/storage-vol
umes>
The EMC VPLEX CLI Guide provides a comprehensive list of VPLEX commands and detailed
instructions on using those commands.
VPLEX Element
Manager API
VPLEX Element Manager API uses the Representational State Transfer (REST) software
architecture for distributed systems such as the World Wide Web. It allows software
developers and other users to use the API to create scripts to run VPLEX CLI commands.
VPLEX Element Manager API supports all VPLEX CLI commands that can be executed from
the root context.
The VPLEX SNMP agent:
SNMP
Supports retrieval of performance related statistics as published in the

VPLEX-MIB.mib.
Runs on the management server and fetches performance related data from individual
directors using a firmware specific interface.
Provides SNMP MIB data for directors (local cluster only).
Runs on Port 161 of the management server and uses the UDP protocol.
Supports the following SNMP commands:

SNMP Get
SNMP Get Next
SNMP get Bulk
VPLEX MIBs are located on the management server in the /opt/emc/VPlex/mibs directory.
LDAP/AD
VPLEX administrators can choose to configure their user accounts using either:
An external OpenLDAP or Active Directory server (which integrates with Unix using
Service for UNIX 3.5 or Identity Management for UNIX or other authentication service).
OpenLDAP and Active Directory users are authenticated by the server.
Usernames/passwords that are created on an external server are fetched from the
remote system onto the VPLEX system when they are used for the first time. They are
stored on the VPLEX system after the first use.
The VPLEX management server

Usernames/passwords are created locally on the VPLEX system and are stored on
VPLEX.
Customers who do not want to use an external LDAP server for maintaining user accounts
can create user accounts on the VPLEX system itself.
Call-home
48
Call-home is a leading technology that alerts EMC support personnel of warnings in

VPLEX.
VPLEX Software
When a fault is detected in a VPLEX configuration, VPLEX automatically sends a call-home

notification to EMC and optionally to your data center support personnel.
Call-home notifications enable EMC to pro-actively engage the relevant personnel, or use
a configured ESRS gateway to resolve the problem.
If the same event occurs repeatedly on the same component, a call-home notification is
generated only for the first instance of the event, and is not generated again for the next 8
hours.
You can customize the recipients, the severity, and the text of call-home notifications to
meet your specific requirements.
Provisioning with VPLEX

VPLEX allows easy storage provisioning among heterogeneous storage arrays. Use the
web-based GUI to simplify everyday provisioning or create complex devices.
There are three ways to provision storage in VPLEX:
Integrated storage provisioning (VIASVPLEX Integrated Array Services based

provisioning)
EZ provisioning
Advanced provisioning
All provisioning features are available in the Unisphere for VPLEX GUI.
Integrated storage
Integrated storage refers to storage created through the VPLEX Integrated Services feature.
This feature requires the use of Array Management Providers (AMPs) to leverage
functionality on the array, specifically on storage pools. If your array functionality includes
storage pools and the array is supported for use with VPLEX, you can integrate the array
with VPLEX and provision storage from pools on the array through VPLEX.
Before provisioning from storage pools, you must first register the AMP that manages the
array. Your VPLEX system can include AMPs that manage some or all of the arrays in your
environment. An array must be integrated with VPLEX in order to provision storage from
pools on the array. Note that you can provision from storage volumes and also on an
integrated array.
Note: In this release, VIAS uses the Storage Management Initiative - Specification (SMI-S)
provider to communicate with the arrays that support integrated services to enable
provisioning.
For more information about registering AMPs and provisioning from storage pools, refer to
the provisioning chapter of the VPLEX Administration Guide.
Other storage
Other storage refers to storage from arrays that are not integrated with VPLEX through
AMPs. Because VPLEX cannot access functionality on the array, you cannot use array
functionality such as storage pools. Therefore, you can only provision from storage
volumes discovered on the array. There are two ways to provision from storage volumes:
EZ-Provisioning and advanced provisioning.
49
VPLEX Software
EZ-Provisioning
EZ-Provisioning uses the Provision from Storage Volumes wizard to guide you through
provisioning from selected storage volumes on the array.
Use the provisioning wizard to:
Select or create a consistency group for the volumes
Select the type of volume to create (distributed or local)
Select mirroring options
Select or create storage
Optionally expose the virtual volumes to a host
The wizard eliminates the individual steps required to claim storage, create extents, create
devices, and then create virtual volumes on those devices. The wizard creates one volume
at a time which uses the full capacity of the selected storage volume. You can also use this
wizard to preserve existing data on a storage volume and make that data visible to a host
through a virtual volume.
Refer to Provision from storage volumes in the VPLEX Online Help for more information.
Advanced
provisioning
Advanced provisioning allows you to slice (use less than the entire capacity) storage
volumes into extents. You can then use one or more of these extents to create devices,
and then virtual volumes on these devices. Advanced provisioning requires you to perform
each of these steps individually, in the order listed in the step-by-step instructions. Use
this method when you want to slice storage volumes and perform other advanced
provisioning tasks such as creating complex devices. The GUI also provides wizards that
allow you to create each of the required storage objects.
For more information about types of devices, refer to About devices on page 51.
Distributed storage
Distributed storage refers to storage objects that are created by using storage from both
clusters.
To view distributed storage in the Unisphere for VPLEX GUI, hover over Provision Storage >
Distributed, and then select a distributed object to view. You can also access distributed
storage from the Distributed Storage section in the navigation pane on the left when an
individual object screen opens.
Thick and thin

storage volumes
Traditional (thick) provisioning anticipates future growth and thus allocates storage
capacity beyond the immediate requirement.
Traditional rebuilds copy all the data from the source to the target.
Thin provisioning allocates storage capacity only as the application needs it when it
writes. Thinly provisioned volumes:
Expand dynamically depending on the amount of data written to them.
Do not consume physical space until written to.
Thin provisioning optimizes the efficiency with which available storage space is used.
By default, VPLEX treats all storage volumes as thickly provisioned volumes. VPLEX can
claim arrays that are thinly provisioned using the thin-rebuild attribute.
50
VPLEX Software
If a target is thinly provisioned, VPLEX reads the storage volume, and does not write
unallocated blocks to the target, preserving the targets thin provisioning.
About extents
An extent is a portion of a disk.

With VPLEX, you can create an extent that uses the entire capacity of the underlying
storage volume, or just a portion of the volume.
Virtual volume
Top-level device
Devices
Extents
Storage volumes
Figure 20 Extents
You can create up to 128 extents for each storage volume.

Extents provide a convenient means of allocating what is needed while taking advantage
of the dynamic thin allocation capabilities of the back-end array.
Create custom-sized extents when LUNs from a back-end storage array are larger than the
desired LUN size for a host.
Combine one or more extents into devices.
About devices
Devices combine extents or other devices into a device with specific RAID techniques such
as mirroring or striping.
Virtual volume
Top-level device
Devices
Extents
Storage volumes
Figure 21 Devices
A simple device has only one underlying component - an extent.
51
VPLEX Software
A complex device has more than one component, combined by using a specific RAID
technique. The components can be extents or other devices (both simple and complex).
A top-level device consists of one or more child devices.
VPLEX supports the following RAID types:
RAID-0 - Stripes data across two or more storage volumes.

RAID-0 devices provide better performance since data is retrieved from several storage
volumes at the same time. RAID-0 devices do not include a mirror to provide data
redundancy.
Use RAID-0 for non-critical data that requires high speed and low cost of
implementation.
RAID-1 - Mirrors data using at least two devices to duplicate the data. RAID-1 does not
stripe.
RAID-1 improves read performance because either extent can be read at the same
time.
Use RAID-1 for applications that require high fault tolerance, without heavy emphasis
on performance.
RAID-C - Appends (concatenates) extents or devices into one larger device.
A device's storage capacity is not available until you create a virtual volume on the device
and export that virtual volume to a host. You can create only one virtual volume per device.
Device visibility
Visibility determines which clusters know about a device.

A device can be visible only to the local cluster (local visibility) or to both clusters (global
visibility).
All distributed devices have global visibility.
You can create a virtual volume from extents at one cluster and make them available for
I/O (visible) at the other cluster.
A virtual volume on a top-level device that has global visibility (or is a member of a
consistency group with global visibility) can be exported in storage views on either cluster.
More about consistency group in Consistency groups on page 56.
52
VPLEX Software
Distributed devices
Distributed devices have their underlying storage arrays located at both clusters in a
VPLEX Metro or VPLEX Geo:
Site A
Site B
Distributed Virtual Volume
Fibre Channel
VPLX-000433
Figure 22 Distributed devices
Distributed devices support virtual volumes that are presented to a host through a storage
view. From the host, the virtual volumes appear as single volumes located on a single
array.
Distributed devices are present at both clusters for simultaneous active/active read/write
access. VPLEX AccessAnywhere ensures consistency of the data between the clusters.
VPLEX distributed devices enable distributed data centers. Some of the benefits of
implementing a distributed data center include:
Increased availability - Both data centers can serve as production workloads while
providing high availability for the other data center.
Increased asset utilization - Passive data centers can have idle resources.
Increased performance/locality of data access - Data need not be read from the
production site as the same data is read/write accessible at both sites.
You can configure up to 8000 distributed devices in a VPLEX system. That is, the total
number of distributed virtual volumes plus the number of top level local devices must not
exceed 8000.
Mirroring
Mirroring writes data to two or more disks simultaneously.

If one leg of a mirrored devices fails, mirroring protects data by automatically leveraging
the other disks without losing data or service.
VPLEX mirrors transparently protect applications from back-end storage array failure and
maintenance operations.
53
VPLEX Software
RAID-1 data is mirrored using at least two extents to duplicate the data. Read performance
is improved because either extent can be read at the same time.
VPLEX manages mirroring between heterogenous storage arrays for both local and
distributed mirroring.
Local mirroring
Local mirroring (mirroring on VPLEX Local systems) protects RAID-1 virtual volumes within
a data center.
VPLEX RAID-1 devices provide a local full-copy RAID 1 mirror of a device independent of
the host and operating system, application, and database.
Remote mirroring
Distributed mirroring (VPLEX Metro and VPLEX Geo) protects distributed virtual volumes by
mirroring it between two VPLEX clusters.
About virtual
volumes
A virtual volume is created on a device or a distributed device, and is presented to a host

through a storage view. Virtual volumes are created on top-level devices only, and always
use the full capacity of the underlying device or distributed device.
Virtual volume
Top-level device
Devices
Extents
Storage volumes
Figure 23 Virtual volumes
If needed, you can expand the capacity of a virtual volume. The expansion method
supported are as follows:
Storage-volume
Concatenation
For more details on volume expansion, see the Administration Guide.

Data caching
VPLEX uses advanced data caching of EMC to improve I/O performance and reduce
storage array contention. The type of data caching used for distributed volumes depends
on the VPLEX configuration.
54
VPLEX Local and Metro configurations have round-trip latencies of 5 ms or less, and
use write-through caching.
VPLEX Software
VPLEX Geo configurations support round-trip latencies of greater than 5 ms, and use
write-back caching.
Write-through caching
In write-through caching, a director writes to the back-end storage in both clusters before
acknowledging the write to the host.
Write-through caching maintains a real-time synchronized mirror of a virtual volume
between the two VPLEX clusters providing a recovery point objective (RPO) of zero data
loss and concurrent access to the volume through either of the clusters.
In the VPLEX user interface, write-through caching is known as synchronous cache mode.
Write-back caching
In write-back caching, a director stores the data in its cache and also protects it at another
director in the local cluster before acknowledging the write to the host.
At a later time, the data is written to the back end storage. Write-back caching provides a
RPO that could be as short as few seconds.
This type of caching is performed on VPLEX Geo configurations, where the latency is
greater than 5 ms.
In the VPLEX user interface, write-back caching is known as asynchronous cache mode.
Logging volumes
Logging volumes keep track of blocks that are written:
During an inter-cluster link outage.
When one leg of a distributed device becomes temporarily unreachable (is

unreachable, but not permanently removed from the SAN).
After the inter-cluster link or leg is restored, the VPLEX system uses the information in the
logging volumes to synchronize the mirrors by sending only the changed blocks across the
link.
Logging volumes also track changes during loss of a volume when that volume is one of
the mirror in a distributed device.
For VPLEX Metro and Geo configurations, logging volumes are required at each cluster
before a distributed device can be created.
VPLEX Local configurations and systems that do not have distributed devices do not
require logging volumes.
Back-end load
balancing
VPLEX uses all paths to a LUN in a round-robin fashion thus balancing the load across all
paths.
Slower storage hardware can be dedicated for less frequently accessed data and
optimized hardware can be dedicated to applications that require the highest storage
response.
55
VPLEX Software
Consistency groups
VPLEX consistency groups aggregate volumes to enable the application of a common set
of properties to the entire group.
Consistency groups aggregate up to 1,000 virtual volumes into a single entity that can be
managed as easily as an individual volume.
If all storage for an application with rollback capabilities is in a single consistency group,
the application can recover from a complete cluster failure or inter-cluster link failure with
little or no data loss. Data loss, if any, is determined by the applications data access
pattern and the consistency groups cache-mode.
All consistency groups guarantee a crash-consistent image of their member virtual
volumes. In the event of a director, cluster, or inter-cluster link failure, consistency groups
prevent possible data corruption.
There are two types of consistency groups:
Synchronous consistency groups

Synchronous consistency groups aggregate local and distributed volumes on VPLEX
Local and VPLEX Metro systems separated by 5ms or less of latency.
Asynchronous consistency groups

Asynchronous consistency groups aggregate distributed volumes on VPLEX Geo
systems separated by 50ms or less of latency.
Synchronous
consistency groups
Synchronous consistency groups provide a convenient way to apply rule sets and other
properties to a group of volumes in a VPLEX Local or VPLEX Metro system.
Synchronous consistency groups simplify configuration and administration on large
systems. VPLEX supports up to 1024 synchronous consistency groups.
Synchronous consistency groups:
Synchronous
consistency groups:
visibility
Contain up to 1000 virtual volumes.
Contain either local or distributed volumes (not a combination of both).
Contain volumes with either global or local visibility.
Use write-through caching.
Synchronous consistency groups support either local or distributed volumes.

Local synchronous consistency groups can have the visibility property set to either:
Local visibility - The local volumes in the consistency group are visible only to the local
cluster.
Global visibility - The local volumes in the consistency group have storage at one
cluster, but are visible to both clusters.
Local visibility
Local consistency groups that have the visibility property set to the local cluster can read
and write only to their local cluster.
56
VPLEX Software
Figure 24 shows a local consistency group with local visibility.

Cluster - 1
1 w
4 A
Virtual Volume
2 w
3 A
VPLX-000375
Figure 24 Local consistency groups with local visibility
Global visibility
Global visibility allows both clusters to receive I/O from the cluster that does not have a
local copy.
Any reads that cannot be serviced from local cache are transferred across the link. This
allows the remote cluster to have instant on demand access to the consistency group.
Figure 25 shows a local consistency group with global visibility.
Cluster - 1
Cluster - 2
2
w
5
A
Virtual Volume
Storage
VPLX-000372
Figure 25 Local consistency group with global visibility
Consistency groups
57
VPLEX Software
Asynchronous
consistency groups
Asynchronous consistency groups provide a convenient way to apply rule sets and other
properties to distributed volumes in a VPLEX Geo.
VPLEX supports up to 16 asynchronous consistency groups. Asynchronous consistency
groups:
Contain up to 1000 virtual volumes.
Contain only distributed volumes.
Contain volumes with either global or local visibility.
Use write-back caching.
In asynchronous cache mode, write order fidelity is maintained by batching I/O between
clusters into packages called deltas that are exchanged between clusters.
Each delta contains a group of writes that were initiated in the same window of time.
Each asynchronous consistency group maintains its own queue of deltas. Before a delta is
exchanged between clusters, data within the delta can vary by cluster. After a delta is
exchanged and committed, data is the same on both clusters.
If access to the back end array is lost while the system is writing a delta, the data on the
disk is no longer consistent and requires automatic recovery when access is restored.
Asynchronous cache mode can give better performance, but there is a higher risk of losing
the data if:
Asynchronous
consistency groups:
active vs. passive
Multiple directors fail at the same time.
There is an inter-cluster link partition and both clusters are actively writing. Instead of
waiting for the link to be restored, the user chooses to accept a data rollback in order
to reduce the recovery time objective (RTO).
The cluster that is actively writing fails.
In VPLEX Geo systems, the configuration of asynchronous consistency groups changes

dynamically between active/passive and active/active depending on the write activity at
each cluster.
A cluster is active if it has data in cache that is yet to be written to the back-end storage
(also known as dirty data).
A cluster is passive if it has no data in cache that has not been written to the back-end.
A cluster is marked as passive if the next delta exchange completes without any new data
from that cluster. The cluster remains passive as long as it contributes no data.
A Geo configuration is active/passive if applications write to only one cluster.
A Geo configuration is active/active if applications write to both clusters.
Detach rules
Most I/O workloads require specific sets of virtual volumes to resume on one cluster and
remain suspended on the other cluster during failures.
VPLEX includes two levels of detach rules that determine which cluster continues I/O
during an inter-cluster link failure or cluster failure.
58
device-level detach rules determine which cluster continues for an individual device.
VPLEX Software
consistency group-level detach rules determine which cluster continues for all the
member volumes of a consistency group.
There are three consistency group detach rules:
no-automatic-winner - The consistency group does not select a winning cluster.
active-cluster-wins - Applicable only to asynchronous consistency groups. If one

cluster was active and one was passive at the time of the outage, the consistency
group selects the active cluster as the winner.
winner cluster-name delay seconds - Applicable only to synchronous consistency

groups. The cluster specified by cluster-name is declared the winner if an inter-cluster
link outage lasts more than the number of seconds specified by the delay.
If a consistency group has a detach-rule configured, the rule applies to all volumes in the
consistency group, and overrides any rule-sets applied to individual volumes.
In the event of connectivity loss with the remote cluster, the detach rule defined for each
consistency group identifies a preferred cluster (if there is one) that can resume I/O to the
volumes in the consistency group.
In a VPLEX Metro configuration, I/O proceeds on the preferred cluster and is suspended on
the non-preferred cluster.
In a VPLEX Geo configuration, I/O proceeds on the active cluster only when the remote
cluster has no dirty data in cache.

In cases where the configured winner of a detach (manual, rule, or VPLEX witness
direction) cannot present a consistent image for the consistency group at that cluster, the
detach will be prevented. A consistency group may not be able to present a consistent
image at a given cluster if one or more of its virtual volumes does not have a healthy leg
at that cluster.
Asynchronous
consistency groups:
active-cluster-wins
detach rule
The active-cluster-wins detach rule is applicable only to asynchronous consistency groups.

During a failure, I/O continues at the cluster where the application was actively writing last
(provided there was only one such cluster). The active cluster is the preferred cluster.
If both clusters were active during the failure, I/O must suspend at both clusters. I/O
suspends because the cache image is inconsistent on both clusters and must be rolled
back to a point where both clusters had a consistent image to continue I/O.
Application restart is required after roll back. If both clusters were passive and have no
dirty data at the time of the failure, the cluster that was the active cluster proceeds with
I/O after failure.
Regardless of the detach rules in asynchronous consistency groups, as long as the remote
cluster has dirty data, the local cluster suspends I/O if it observes loss of connectivity with
the remote cluster regardless of preference.
This is done to allow the administrator to stop or restart the application prior to exposing
the application to the rolled back time consistent data image (if roll-back is required).
Consistency groups
59
VPLEX Software
Note: VPLEX Witness does not guide failover behavior for asynchronous consistency
groups. In Geo configurations (asynchronous consistency groups), VPLEX Witness
observations can be used to diagnose problems, but not to automate failover.
Cache vaulting
VPLEX uses the individual director's memory systems to ensure durability of user data and
critical system configuration data.
If a power failure on a VPLEX Geo cluster (using write-back cache mode) occurs, then the
data in cache memory might be at risk. Each VPLEX director copies its dirty cache data to
the local solid state storage devices (SSDs) using a process known as cache vaulting.
Dirty cache pages are pages in a director's memory that have not been written to back-end
storage but were acknowledged to the host. Dirty cache pages include the copies
protected on a second director in the cluster. These pages must be preserved in the
presence of power outages to avoid loss of data that has already been acknowledged to
the host.
After each director vaults its dirty cache pages, VPLEX shuts down the directors firmware.
Note: Although there is no dirty cache data in VPLEX Local or VPLEX Metro configurations,
vaulting quiesces all I/O when data is at risk due to power failure. This minimizes risk of
metadata corruption.
When power is restored, VPLEX initializes the hardware and the environmental system,
checks the data validity of each vault, and unvaults the data. In VPLEX Geo configurations,
cache vaulting is necessary to safeguard the dirty cache data under emergency conditions.
Vaulting can be used in two scenarios:
Data at risk due to power failure: VPLEX monitors all components that provide power
to the VPLEX cluster. If VPLEX detects AC power loss that would put data at risk, it
takes a conservative approach and initiates a cluster wide vault if the power loss
exceeds 30 seconds.
Note: Power failure of the UPS (in dual and quad engine configurations) does not
currently trigger any vaulting actions on power failure.
Manual emergency cluster shutdown: When unforseen circumstances require an

unplanned and immediate shutdown, it is known as an emergency cluster shutdown.
You can use a CLI command to manually start vaulting if an emergency shutdown is
required.

When performing maintenance activities on a VPLEX Geo system, service personnel must
not remove the power in one or more engines that would result in the power loss of both
directors unless both directors in those engines have been shutdown and are no longer
monitoring power. Failure to do so, will lead to data unavailability in the affected cluster.
To avoid unintended vaults, always follow official maintenance procedures.
60
VPLEX Software
For information on distributed cache protection, refer to Global cache on page 78

For information on conditions that cause a vault see Power failures that cause vault on
page 40.
Cache vaulting
61
VPLEX Software
62
CHAPTER 4
This chapter describes how VPLEXs high availability and redundancy features provide
robust system integrity and resiliency. Topics include:
About VPLEX resilience and integrity .......................................................................

Cluster ....................................................................................................................
Path redundancy.....................................................................................................
High Availability with VPLEX Witness .......................................................................
ALUA.......................................................................................................................
Additional resilience features..................................................................................
Performance monitoring and security features.........................................................
Security features .....................................................................................................
63
64
65
69
76
76
79
81
About VPLEX resilience and integrity

With VPLEX, you get true high availability. Operations continue and data remains online
even when a failure occurs. Within synchronous distances (VPLEX Metro), think of VPLEX
as providing disaster avoidance instead of just disaster recovery.
VPLEX Metro and Geo give you shared data access between sites. The same data (not a
copy), exists at more than one location simultaneously.
VPLEX can withstand a component failure, a site failure, or loss of communication
between sites and still keep the application and data online and available.
VPLEX clusters are capable of surviving any single hardware failure in any subsystem
within the overall storage cluster, including host connectivity and memory subsystems.
A single failure in any subsystem does not affect the availability or integrity of the data.
VPLEX redundancy creates fault tolerance for devices and hardware components that
continue operation as long as one device or component survives. This highly available and
robust architecture can sustain multiple device and component failures without disrupting
service to I/O.
Failures and events that do not disrupt I/O include:
Unplanned and planned storage outages
SAN outages
VPLEX component failures
VPLEX cluster failures
Data center outages
To achieve high availability, you must create redundant host connections and supply
hosts with multi path drivers.
63
Note: In the event of a front-end port failure or a director failure, hosts without redundant
physical connectivity to a VPLEX cluster and without multipathing software installed could
be susceptible to data unavailability.
Cluster
VPLEX is a true cluster architecture. That is, all devices are always available and I/O that
enters the cluster from anywhere can be serviced by any node within the cluster, while
cache and coherency is maintained for all reads and writes.
As you add more devices to the cluster, you get the added benefits of more cache,
increased processing power, and more performance.
A VPLEX cluster provides N1 fault tolerance, which means any device failure, or any
component failure can be sustained, and the cluster will continue to operate as long as
one device survives.
This is a very highly available and robust architecture, capable of sustaining even multiple
failures while the cluster still continues to provide virtualization and storage services.
A VPLEX cluster (either VS1 or VS2) consists of redundant hardware components.
A single engine supports two directors. If one director in an engine fails, the second
director in the engine continues to service I/O. Similarly, if a VPLEX cluster contains
multiple engines, VPLEX can handle more than one failure without disrupting any services
as long as quorum (defined by set rules) is not lost. Quorum provides more information
on this.
All hardware resources (CPU cycles, I/O ports, and cache memory) are pooled.
Two-cluster configurations (Metro and Geo) offer true high availability. Operations
continue and data remains online even if an entire site fails.
VPLEX Metro configurations provide a high availability solution with zero recovery point
objective (RPO).
VPLEX Geo configurations enable near-zero RPO and the failover is still automated.
Quorum
Quorum refers to the minimum number of directors required for the cluster to service and
maintain operations.
There are different quorum rules for a cluster to become operational and start servicing
I/Os when it is booting up, also called gaining quorum. Different rules for an operational
cluster seeing director failures to either continue servicing operations and I/O after failure
handling is called maintaining quorum. Stopping servicing operations and I/O is called
losing quorum. These rules are described below:
64
Gaining quorum - A non-operational VPLEX cluster gains quorum and becomes

operational when more than half of the configured directors restart and come in
contact with each other. In a single engine cluster, it refers to all the directors.
Maintaining quorum - An operational VPLEX cluster seeing failures will continue

operating in the following scenarios:
Director failures
If less than half of the operational directors with quorum fail.
If half of the operational directors with quorum fail, then the remaining
directors will check the operational status of the failed directors over the
management network and remain alive.
After recovering from this failure, a cluster can tolerate further similar director
failures until only one director is remaining. In a single engine cluster, a maximum
of one director failure can be tolerated.
Intra-cluster communication failure
If there is a split in the middle, that is, half of the operational directors with
quorum lose communication with the other half of the directors, and both
halves are running, then the directors detect the operational status over the
management network and instruct half with the director with the lowest UUID to
keep running and the directors without the lowest UUID to operationally stop.
Quorum loss - An operational VPLEX cluster seeing failures stops operating in the
following scenarios:
If more than half of the operational directors with quorum fail.
If half of the operational directors with quorum fail, and the directors are unable to
determine the operation status of the other half of the directors (whose
membership includes a low UUID).
In a dual or quad engine cluster, if all of the directors loose contact with each
other.
Path redundancy
Path redundancy is critical for high availability. This section describes how VPLEX delivers
resilience using multiple paths:
Different ports
Front-end ports on all directors can provide access to any virtual volume in the cluster.
Include multiple front-end ports in each storage view to protect against port failures.
Path redundancy
65
When a director port fails, the host multipathing software seamlessly fails over to another
path through a different port, as shown in Figure 26.
Director A1
Director B1
Engine 1
Virtual Volume
VPLX-000376
Figure 26 Path redundancy: different ports
Combine multi-pathing software plus redundant volume presentation for continuous data
availability in the presence of port failures.
Back-end ports, local COM ports, and WAN COM ports provide similar redundancy for
additional resilience.
Different directors
Each VPLEX engine includes redundant directors. Each director can service I/O for any
other director in the cluster due to the redundant nature of the global directory and cache
coherency.
If one director in the engine fails, then other director immediately takes over the I/O
processing from the host.
66
In Figure 27, Director A has failed, but Director B services the host I/O that was previously
being serviced by Director A.
Director A1
Director B1
Engine 1
Virtual Volume
VPLX-000392
Figure 27 Path redundancy: different directors
Combine multi-pathing software with VPLEXs volume presentation on different directors

for continuous data availability in the presence of director failures.
Note: If a director loses access to a specific storage volume, but other directors at the
same cluster have access to that volume, VPLEX can forward back end I/O to another
director that still has access. This condition is known as asymmetric back end visibility.
When asymmetric back end visibility happens, VPLEX is considered to be in a degraded
state, and is unable provide high availability. Operations such as NDU are prevented.
Asymmetric back end visibility can also have a performance impact.
Best practices
For maximum availability:
Present the virtual volumes through each director so that all directors except one can
fail without causing data loss or unavailability.
Connect all directors to all storage.
Configure paths through both an director A and a director B to ensure continuous I/O
during non-disruptive upgrade of VPLEX.
Connect VPLEX directors to both Fibre Channel fabrics (if used) for the front-end
(host-side), and the back-end (storage array side). Isolate the fabrics.
Redundant connections from the directors to the fabrics and fabric isolation allows
VPLEX to ride through failures of an entire fabric with no disruption of service.
Connect hosts to both fabrics and use multi-pathing software to ensure continuous
data access during failures.
Connect I/O modules to redundant fabrics.

Path redundancy
67
FAB-A
FAB-B
VPLX-000432
Figure 28 Recommended fabric assignments for front-end and back-end ports
Different engines
In a dual-engine or quad-engine configuration, if one engine goes down, another engine

completes the host I/O processing as shown in Figure 29.
Director A1
Director B1
Director A1
Engine 1
Director B1
Engine 2
Virtual Volume
VPLX-000393
Figure 29 Path redundancy: different engines
In VPLEX Geo, directors in the same engine serve as protection targets for each other. If a
single director in an engine goes down, the remaining director uses another director in the
cluster as its protection pair. Simultaneously losing an engine in an active cluster, though
very rare, could result in loss of crash consistency. However, the loss of 2 directors in
different engines can be handled as long as other directors can serve as protection targets
for the failed director.
In a VPLEX Metro, multi-pathing software plus volume presentation on different engines
yields continuous data availability in the presence of engine failures.
Site distribution
When two VPLEX clusters are connected together with VPLEX Metro or Geo, VPLEX gives
you shared data access between sites. VPLEX can withstand a component failure, a site
failure, or loss of communication between sites and still keep the application and data
online and available.
VPLEX Metro ensures that if a data center goes down, or even if the link to that data center
goes down, the other site can continue processing the host I/O.
68
In Figure 30, despite a site failure at Data Center B, I/O continues without disruption in
Data Center A.
Data center A
Data center B
Cluster file system
Director B1
Director A1
Director A1
Director B1
Engine 1
Engine 1
Virtual Volume
Virtual Volume
VPLX-000394
Figure 30 Path redundancy: different sites
Install the optional VPLEX Witness on a server in a separate failure domain to provide
further fault tolerance in VPLEX Metro configurations.
See High Availability with VPLEX Witness on page 69.
High Availability with VPLEX Witness

VPLEX Witness helps multi-cluster VPLEX configurations automate the response to cluster
failures and inter-cluster link outages.
VPLEX Witness is an optional component installed as a virtual machine on a customer
host.
Note: The customer host must be deployed in a separate failure domain from either of the
VPLEX clusters to eliminate the possibility of a single fault affecting both a cluster and
VPLEX Witness.
Note: The VPLEX Witness server supports round trip time latency of 1 second over the
management IP network.
In Metro and Geo configurations, VPLEX uses rule sets to define how failures are handled.
If the clusters lose contact with one another or if one cluster fails, rule sets define which
cluster continues operation (the preferred cluster) and which suspends I/O (the
non-preferred cluster). This works for most link or cluster failures.
In the case where the preferred cluster fails, all I/O is suspended resulting in data
unavailability.
VPLEX Witness observes the state of the clusters, and thus can distinguish between a
outage of the inter-cluster link and a cluster failure. VPLEX Witness uses this information
to guide the clusters to either resume or suspend I/O.
69
VPLEX Witness works in conjunction with consistency groups. VPLEX Witness guidance
does not apply to local volumes and distributed volumes that are not members of a
consistency group.
VPLEX Witness capabilities vary depending on whether the VPLEX is a Metro (synchronous
consistency groups) or Geo (asynchronous consistency groups).
In Metro systems, VPLEX Witness provides seamless zero recovery time objective
(RTO) fail-over for storage volumes in synchronous consistency groups.
Combine VPLEX Witness and VPLEX Metro to provide the following features:
High availability for applications in a VPLEX Metro configuration leveraging
synchronous consistency groups (no single points of storage failure).
Fully automatic failure handling of synchronous consistency groups in a VPLEX
Metro configuration (provided these consistency groups are configured with a
specific preference).
Better resource utilization.
In Geo systems, VPLEX Witness automates fail-over for asynchronous consistency

groups and provides zero RTO and zero RPO fail-over in all cases that do not result in
data rollback.
Figure 31 on page 70 shows a high level architecture of VPLEX Witness. The VPLEX Witness
server must reside in a failure domain separate from cluster-1 and cluster-2.
Failure Domain #3
VPLEX Witness
Cluster 1
IP management
Network
Cluster 2
Inter-cluster
Network A
Inter-cluster
Network B
Failure Domain #1
Failure Domain #2
VPLX-000474
Figure 31 High level VPLEX Witness architecture
The VPLEX Witness server must be deployed in a separate failure domain to both of the
VPLEX clusters. This deployment enables VPLEX Witness to distinguish between a site
outage and a link and to provide the correct guidance.
70
Witness installation
considerations
It is important to deploy the VPLEX Witness server VM in a separate failure domain other
than either of the cluster domains.
A failure domain is a set of entities effected by the same set of faults. The scope of the
failure domain depends on the set of fault scenarios that can be tolerated in a given
environment. For example:
If the two clusters are deployed on different floors of the same data center, deploy the
VPLEX Witness Server VM on a separate floor.
If the two clusters are deployed in two different data centers, deploy the VPLEX
Witness Server VM in the third data center.
VPLEX Witness is deployed:
As a virtual machine running on a customers VMware ESX server.
In a failure domain separate from either of the VPLEX clusters, and
Protected by a firewall.
The VPLEX Witness software includes a client on each of the VPLEX clusters. VPLEX
Witness does not appear in the CLI until the client has been configured.
Failures in Metro
systems: without
VPLEX Witness
VPLEX Metro configurations (synchronous consistency groups) have two consistency

group level detach rules:
winner cluster-name delay seconds
no-automatic-winner
VPLEX Witness does not guide consistency groups with the no-automatic-winner detach
rule. This discussion applies only to synchronous consistency groups with the winner
cluster-name delay seconds detach rule.
Synchronous consistency groups use write-through caching. Host writes to a distributed
volume are acknowledged back to the host only after the data is written to the back-end
storage at both VPLEX clusters.
In Figure 32, the winner cluster-name delay seconds detach rule designates cluster-1 as
the preferred cluster. That is, during an inter-cluster link outage or a cluster failure, I/O to
the device leg at cluster-1 continues, and I/O to the device leg at cluster-2 is suspended.
71
Three common types of failures that illustrate how VPLEX responds without Cluster
Witness are described below:.
Scenario 1
Cluster 1
Scenario 2
Cluster 2
Cluster 1
Scenario 3
Cluster 2
Cluster 1
Cluster 2
VPLX-000434
Figure 32 Failure scenarios in VPLEX Metro configurations without VPLEX Witness
Scenario 1 - Inter-cluster link outage

Both of the dual links between the clusters have an outage. Also known as a cluster
partition.
The preferred cluster (cluster-1) continues I/O
Cluster-2 suspends I/O
The existing detach rules are sufficient to prevent data unavailability. Writes at
cluster-1 are logged. When the inter-cluster link is restored, a log rebuild copies only
the logged changes to resynchronize the clusters.
Scenario 2 - Cluster-2 fails
Cluster-1 (the preferred cluster) continues I/O.
The existing detach rules are sufficient to prevent data unavailability. Volumes are
accessible with no disruptions at cluster-1.
Writes at cluster-1 are logged. When cluster-2 is restored, and it rejoins cluster-1, a log
rebuild copies only the logged changes to resynchronize cluster-2.
Scenario 3 - Cluster-1 (the preferred cluster) fails
Cluster-2 suspends I/O (data unavailability)
VPLEX cannot automatically recover from this failure and suspends I/O at the
operating cluster.
When the failure is repaired, recovery may require manual intervention to re-enable
I/O on cluster-2.
VPLEX Witness addresses scenario 3, where the preferred cluster (Cluster -1) fails, and the
other cluster (Cluster-2) cannot continue I/O due to the configured detach rule-set.
Note: VPLEX Witness has no impact on distributed volumes that are in synchronous
consistency groups configured with the no-automatic-winner rule. In that case, manual
intervention is required in the presence of any failure scenario described above.
72
Failures in Metro
systems: with VPLEX
Witness
When VPLEX Witness is deployed in a VPLEX Metro configuration, failure of the preferred
cluster (Scenario 3) does not result in data unavailability for distributed devices that are
members of (synchronous) consistency groups.
Instead, VPLEX Witness guides the surviving cluster to continue I/O, despite its
designation as the non-preferred cluster. I/O continues to all distributed volumes in all
synchronous consistency groups that do not have the no-automatic-winner detach rule.
Host applications continue I/O on the surviving cluster without any manual intervention.
When the preferred cluster fails in a Metro configuration, VPLEX Witness provides
seamless zero RTO failover to the surviving cluster.
The VPLEX Witness Server VM connects to the VPLEX clusters over the management IP
network.
The deployment of VPLEX Witness adds a point of failure to the VPLEX deployment. This
section describes the impact of failures of the VPLEX Witness Server VM and the network
connections between the VM and the clusters.
Note: This discussion applies only to VPLEX Witness in VPLEX Metro configurations.
Failures of connections between the cluster and the VPLEX Witness VM are managed as
follows:
VPLEX
Witness
VPLEX
Witness
Cluster 2
I/
O
s
ue
in
nt
Co
ds
en
sp
Su
I/
O
O
I/
O
I/
Cluster 1
Su
sp
en
ds
Remote Cluster Isolation
Co
nt
in
ue
s
Local Cluster Isolation
Cluster 1
Cluster 2
VPLEX
Witness
Cluster 1
I/
O
s
ue
in
nt
Co
s
ue
in
nt
Co
Cluster 2
O
I/
O
I/
Cluster 1
Co
nt
in
ue
s
Loss of Contact with VPLEX Witness
VPLEX
Witness
Su
sp
en
ds
Inter Cluster Partition
I/
O
Witness and network

failures
Cluster 2
VPLX-000435
Figure 33 VPLEX Witness and VPLEX cluster connection failures
Local Cluster Isolation - The preferred cluster loses contact with both the remote cluster
and the VPLEX Witness.
The preferred cluster is unable to receive guidance from VPLEX Witness and
suspends I/O.
VPLEX Witness guides the non-preferred cluster to continue I/O.
73
Remote Cluster Isolation - The preferred cluster loses contact with the remote cluster and
the non-preferred cluster loses contact with the VPLEX Witness. The preferred cluster is
connected to VPLEX Witness.
The preferred cluster continues I/O as it is still in contact with the VPLEX Witness.
The non-preferred cluster suspends I/O, as it is neither in contact with the other
cluster, nor can it receive guidance from VPLEX Witness.
Inter-Cluster Partition - Both clusters lose contact with each other, but still have access to
VPLEX Witness. VPLEX Witness preserves the detach rule failure behaviors.
I/O continues on the preferred cluster.
If the preferred cluster cannot proceed because it has not fully synchronized, the
cluster suspends I/O.
Overriding the detach rule results in a zero RTO.
Loss of Contact with VPLEX Witness - The clusters are still in contact with each other, but
one or both of the clusters has lost contact with VPLEX Witness.
There is no change in I/O.
The cluster(s) that lost connectivity with VPLEX Witness sends a call-home
notification.
If either cluster fails or if the inter-cluster link fails when VPLEX Witness is down,
VPLEX experiences data unavailability in all surviving clusters.
When the VPLEX Witness observes a failure and provides guidance, it sticks to this
governance until both clusters report complete recovery. This is crucial in order to avoid
split-brain and data corruption.
As a result you may have a scenario where:
Cluster-1 is isolated
VPLEX Witness tells cluster-2 to continue I/O
Cluster-2 becomes isolated.
Because cluster-2 has previously received guidance to proceed from VPLEX Witness, it
proceeds even when it is isolated. In the meantime, if cluster-1 reconnects with the VPLEX
Witness server, the VPLEX Witness server tells cluster-1 to suspend. In this case, because
of event timing, cluster-1 is connected to VPLEX Witness but it is suspended, while
cluster-2 is isolated but it is proceeding.
VPLEX Witness in
VPLEX Geo
configurations
VPLEX Witness/
GeoSynchrony 5.0.1
The value of the VPLEX Witness is different in VPLEX Geo configurations than it is in VPLEX
Metro configurations. The value also varies depending on the release of GeoSynchrony.
For systems running GeoSynchrony 5.0.1, clusters in Geo configurations do not comply
with VPLEX Witness guidance. Instead the clusters operate according to the detach rules
applied to each asynchronous consistency group.
Information displayed in the VPLEX Witness CLI context helps to determine the nature of a
failure (cluster failure or inter-cluster link outage). Administrators can use this information
to make manual fail-over decisions.
74
VPLEX Witness/
GeoSynchrony 5.1
For VPLEX Geo systems, VPLEX Witness automates the response to failure scenarios that
do not require data rollback.
Manual intervention is required if data rollback is needed.
Preferred cluster fails

When the preferred cluster fails, the value of VPLEX Witness varies depending on whether
data rollback is required.
No data rollback is required - VPLEX Witness guides the surviving cluster to allow I/O
to all distributed volumes in all the asynchronous consistency groups configured with
the active-cluster-wins detach rule.
I/O continues at the non-preferred cluster.
If no rollback is required, VPLEX Witness automates failover with zero RTO and zero
RPO.
Rollback is required - If data rollback is required, all asynchronous consistency groups

suspend I/O regardless of VPLEX Witness guidance and the pre-configured rule set.
Manual intervention is required to force the rollback in order to change the current
data image to the last consistent image preserved on disk.
The application may need to be manually restarted to ensure that it does not use data
that is still in the applications cache, but has been discarded by VPLEX.
Inter-cluster link outage

In the event of an inter-cluster link outage, VPLEX Witness guides the preferred cluster to
continue I/O. Similar to failure of the preferred cluster, the value of VPLEX Witness varies
depending on whether data rollback is required.
No data rollback is required - VPLEX Witness guides the preferred cluster to continue
I/O to all distributed volumes in all asynchronous consistency groups configured with
the active-cluster-wins detach rule.
I/O is suspended at the non-preferred cluster.
VPLEX Witness automates failover with zero RTO and zero RPO.
Rollback is required - If data rollback is required, all asynchronous consistency groups

suspend I/O regardless of VPLEX Witness guidance, and their pre-configured rule set.
Manual intervention is required to force the rollback in order to change the current
data image to the last consistent image preserved on disk, and to restart I/O to the
suspended consistency groups.
You must manually restart the application to ensure that the application does not use
data that has been discarded by VPLEX, but available in the application cache.
Higher availability
Combine VPLEX Witness with VMware and cross cluster connection to create even higher
availability.
See Chapter 5 VPLEX Use Cases for more information on the use of VPLEX Witness with
VPLEX Metro and VPLEX Geo configurations.
75
ALUA
Asymmetric Logical Unit Access (ALUA) routes I/O of the LUN directed to non-active/failed
storage processor to the active storage processor without changing the ownership of the
LUN.
Each LUN has two types of paths:
Active/optimized paths are direct paths to the storage processor that owns the LUN.
Active/optimized paths are usually the optimal path and provide higher bandwidth
than active/non-optimized paths.
Active/non-optimized paths are indirect paths to the storage processor that does not
own the LUN through an interconnect bus.
I/Os that traverse through the active/non-optimized paths must be transferred to the
storage processor that owns the LUN. This transfer increases latency and has an
impact on the array.
VPLEX detects the different path types and performs round robin load balancing across
the active/optimized paths.
VPLEX supports all three flavors of ALUA:
Explicit ALUA - The storage processor changes the state of paths in response to
commands (for example, the Set Target Port Groups command) from the host (the
VPLEX backend).
The storage processor must be explicitly instructed to change a paths state.
If the active/optimized path fails, VPLEX issues the instruction to transition the
active/non-optimized path to active/optimized.
There is no need to failover the LUN.
Implicit ALUA - The storage processor can change the state of a path without any
command from the host (the VPLEX back end).
If the controller that owns the LUN fails, the array changes the state of the
active/non-optimized path to active/optimized and fails over the LUN from the failed
controller.
On the next I/O, after changing the paths state, the storage processor returns a Unit
Attention Asymmetric Access State Changed to the host (the VPLEX backend).
VPLEX then re-discovers all the paths to get the updated access states.
Implicit/explicit ALUA - Either the host or the array can initiate the access state
change.
Storage processors support implicit only, explicit only, or both.
Additional resilience features

This section describes additional VPLEX features that enable VPLEX to continue to service
I/O during inter-cluster network outages or cluster failures.
76
Metadata volumes
Meta-volumes store VPLEX metadata, including virtual-to-physical mappings, data about

devices, virtual volumes, and system configuration settings.
Metadata is stored in cache and backed up on specially designated external volumes
called meta-volumes.
After the meta-volume is configured, updates to the metadata are written to both the
cache and the meta-volume when the VPLEX configuration is modified.
Each VPLEX cluster maintains its own metadata, including:
The local configuration for the cluster.
Distributed configuration information shared between clusters.
At system startup, VPLEX reads the metadata and loads the configuration information onto
each director.
When you make changes to the system configuration, VPLEX writes these changes to the
metadata volume.
If VPLEX loses access to the metadata volume, the VPLEX directors continue
uninterrupted, using the in-memory copy of the configuration. VPLEX blocks changes to
the system until access is restored or the automatic backup meta-volume is activated.
Meta-volumes experience high I/O only during system startup and upgrade.
I/O activity during normal operations is minimal.
Best practices
Logging volumes
For best resilience:
Allocate storage volumes of 78Gb for the metadata volume.
Configure the metadata volume for each cluster with multiple back-end storage
volumes provided by different storage arrays of the same type.
Use the data protection capabilities provided by these storage arrays, such as RAID 1
to ensure the integrity of the system's metadata.
Create backup copies of the metadata whenever configuration changes are made to
the system.
Perform regular backups of the metadata volumes on storage arrays that are separate
from the arrays used for the metadata volume.
Logging volumes keep track of blocks written:
During an inter-cluster link outage.
When one leg of a DR1 becomes unreachable and then recovers.
After the inter-cluster link or leg is restored, the VPLEX system uses the information in
logging volumes to synchronize the mirrors by sending only changed blocks across the
link.
Logging volumes also track changes during loss of a volume when that volume is one
mirror in a distributed device.
Additional resilience features
77

If no logging volume is accessible, then the entire leg is marked as out-of-date. A full
re-synchronization is required once the leg is reattached.
The logging volumes on the continuing cluster experience high I/O during:
Network outages or cluster failures
Incremental synchronization
When the network or cluster is restored, VPLEX reads the logging volume to determine
what writes to synchronize to the reattached volume.
There is no I/O activity during normal operations.

Best practices
On a VPLEX Metro or VPLEX Geo configuration:
Place logging volumes on the fastest storage available.
Stripe logging volumes across several disks to accommodate the high level of I/O that
occurs during and after outages.
Configure at least 1 Gb of logging volume space for every 16 TB of distributed device

space.
Slightly more space is required if the 16 TB of distributed storage is composed of
multiple distributed devices, because a small amount of non-logging information is
also stored for each distributed device.
Global cache
Memory systems of individual directors ensure durability of user and critical system data.
The method used to protect user data depends on cache mode:
Synchronous systems (write-through cache mode) leverage the back-end array by

writing user data to the array. An acknowledgement for the written data must be
received before the write is acknowledged back to the host.
Asynchronous systems (write-back cache mode) ensure data durability by storing user
data into the cache memory of the director that received the I/O, and then placing a
protection copy of this data on another director in the local cluster before
acknowledging the write to the host.
This ensures that the data is protected in two independent memories. The data is later
destaged to back-end storage arrays that provide the physical storage media.
Protection from power

failure
If a power failure lasts longer than 30 seconds in a VPLEX Geo configuration, then each
VPLEX director copies its dirty cache data to the local solid state storage devices (SSDs).
Known as vaulting, this process protects user data in cache if that data is at risk due to
power loss. After each director vaults its dirty cache pages, VPLEX shuts down the
directors firmware.
When operations resume, if any condition is not safe, the system does not resume normal
status and calls home for diagnosis and repair.
EMC Customer Support communicate with the VPLEX system and restore normal system
operations.
78
Under normal conditions, the SPS batteries can support two consecutive vaults. This
ensures the system can resume I/O after the first power failure, and still vault a second
time if there is another power failure.
Performance monitoring and security features

VPLEXs performance monitoring enables you to monitor the overall health of your system,
identify bottlenecks, and resolve problems quickly.
VPLEX security features help keep your system safe from intruders.
Performance
monitoring
VPLEX performance monitoring provides a customized view into the performance of your
system. You decide which aspects of the system's performance to view and compare.
VPLEX supports four general categories of performance monitoring:
Current load monitoring allows administrators to watch CPU load during upgrades, I/O
load across the inter-cluster WAN link, and front-end against the back-end load during
data mining or back up.
Both the CLI and GUI support current load monitoring.
Long term load monitoring collects data for capacity planning and load balancing.
Both the CLI and GUI support long term load monitoring.
Object base monitoring collects data for the virtual volume.

Both the CLI and GUI support object base monitoring.
Troubleshooting monitoring helps identify bottlenecks and high resource

consumption.
Troubleshooting monitoring is supported by monitors that are created using the CLI
and/or perpetual monitors.
Performance
monitoring: GUI
The GUIs performance monitoring dashboard is a customized view into the performance
of the VPLEX system:
Figure 34 Performance monitoring - dashboard
Performance monitoring and security features
79
You decide which aspects of the system's performance to view and compare:
Figure 35 Performance monitoring - select information to view
Performance information is displayed as a set of charts. For example, Figure 36 shows

front-end throughput for a selected director:
Figure 36 Performance monitoring - sample chart
For additional information about the statistics available through the Performance
Dashboard, see the EMC Unisphere for VPLEX online help available in the VPLEX GUI.
Performance
monitoring: CLI
The CLI collects and displays performance statistics using:

monitors - Gather the specified statistic from the specified target at the specified interval.
monitor sinks - Direct the output to the desired destination. Monitor sinks include the
console, a file, or a combination of the two.
Use the three pre-configured monitors for each director to collect information to diagnose
common problems.
Use the CLI to create a toolbox of custom monitors to operate under varying conditions
including debugging, capacity planning, and workload characterization. For example:
Create a performance monitor to collect statistics for CompareAndWrite (CAW)

operations, miscompares, and latency for the specified virtual volume on
director-1-1-B.
Add a file sink to send output to the specified directory on the management server.
Note: SNMP statistics do not require a monitor or monitor sink. Use the snmp-agent
configure command to configure and start the SNMP agent. For more information about
monitoring with SNMP, refer to the EMC VPLEX Administration Guide.
80
Security features
The VPLEX management server operating system (OS) is based on a Novell SUSE Linux
Enterprise Server 11 distribution.
The operating system has been configured to meet EMC security standards by disabling or
removing unused services, and protecting access to network services through a firewall.
Security features include:
SSH Version 2 to access the management server shell
Customizable password policies
LDAP authentication using LDAP v3 protocol
IPv6 support
HTTPS to access the VPLEX GUI
IPSec VPN inter-cluster link in VPLEX Metro and VPLEX Geo configurations
IPSec VPN to connect each cluster of a VPLEX Metro or VPLEX Geo to the VPLEX
Witness server
SCP to copy files
Support for separate networks for all VPLEX cluster communication
Defined user accounts and roles
Defined port usage for cluster communication over management server
Certificate Authority (CA) certificate (default expiration 5 years)
Two host certificates (default expiration 2 years)
Third host certificate for optional VPLEX Witness
External directory server support

The WAN-COM inter-cluster link carries unencrypted user data. To ensure privacy of the
data, establish an encrypted VPN tunnel between the two sites.
For more information about security features and configuration see the EMC VPLEX
Security Configuration Guide.
Security features
81
82
CHAPTER 5
VPLEX Use Cases
This section describes examples of VPLEX configurations. Topics include:
Technology refresh.................................................................................................. 83
Mobility .................................................................................................................. 85
Collaboration .......................................................................................................... 87
VPLEX Metro HA ...................................................................................................... 88
Redundancy with RecoverPoint ............................................................................... 96
MetroPoint............................................................................................................ 106
Technology refresh
In typical IT environments, migrations to new storage arrays (technology refreshes) require
that the data that is being used by hosts be copied to a new volume on the new array. The
host must then be reconfigured to access the new storage. This process requires
downtime for the host.
Migrations between heterogeneous arrays can be complicated and may require additional
software or functionality. Integrating heterogeneous arrays in a single environment is
difficult and requires a staff with a diverse skill set.
Figure 37 shows the traditional view of storage arrays with servers attached to the
redundant front end and storage (Array 1 and Array 2) connected to a redundant fabric at
the back end.
Array 1
Server
No Federation
Server
Array 2
VPLX-000381
Figure 37 Traditional view of storage arrays
When VPLEX is inserted between the front-end and back-end redundant fabrics, VPLEX
appears as the target to hosts and as the initiator to storage.
This abstract view of storage is very helpful while replacing the physical array that is
providing storage to applications.
VPLEX Use Cases
83
VPLEX Use Cases
With VPLEX, because the data resides on virtual volumes, it can be copied nondisruptively
from one array to another without any downtime. There is no need to reconfigure the host;
the physical data relocation is performed by VPLEX transparently and the virtual volumes
retain the same identities and the same access points to the host.
In Figure 38, the virtual disk is made up of the disks of Array A and Array B. The site
administrator has determined that Array A has become obsolete and should be replaced
with a new array. Array C is the new storage array. Using Mobility Central, the
administrator:
Adds Array C array into the VPLEX cluster.
Assigns a target extent from the new array to each extent from the old array.
Instructs VPLEX to perform the migration.
VPLEX copies data from Array A to Array C while the host continues its access to the virtual
volume without disruption.
After the copy of Array A to Array C is complete, Array A can be decommissioned:
Virtual Volume
Array A
Array B
Array C
VPLX-000380
Figure 38 VPLEX technology refresh
Because the virtual machine is addressing its data to the abstracted virtual volume, its
data continues to flow to the virtual volume without any need to change the address of the
data store.
84
VPLEX Use Cases
Although this example uses virtual machines, the same is true for traditional hosts. Using
VPLEX, the administrator can move data used by an application to a different storage array
without the application or server being aware of the change.
This allows you to change the back-end storage arrays transparently, without interrupting
I/O.
VPLEX makes it easier to replace heterogeneous storage arrays on the back-end.
Mobility
Use VPLEX to move data between data centers, relocate a data center or consolidate data,
without disrupting host application access to the data.
MOBILITY
Cluster A
Cluster B
ACCESS ANYWHERE
Move and relocate VMs,

applications, and data
over distance
Figure 39 Moving data with VPLEX
The source and target arrays can be in the same data center (VPLEX Local) or in different
data centers separated by up to 5ms (VPLEX Metro) or 50ms (VPLEX Geo).
With VPLEX, source and target arrays can be heterogeneous.
When you use VPLEX to move data, the data retains its original VPLEX volume identifier
during and after the mobility operation. No change in volume identifiers eliminates
application cut over. The application continues to use the same storage, unaware that it
has moved.
There are many types and reasons to move data:
Move data from a hot storage device.
Move applications from one storage device to another.
Move operating system files from one storage device to another.
Consolidate data or database instances.
Move database instances.
Move storage infrastructure from one physical location to another.
With VPLEX, you no longer need to spend significant time and resources preparing to
move data and applications. You dont have to accept a forced outage and restart the
application after the move is completed.
Instead, a move can be made instantly between sites, over distance, and the data remains
online and available during the move without any outage or downtime.
Mobility
85
VPLEX Use Cases
Considerations before moving the data include the business impact, type of data to be
moved, site locations, total amount of data, and schedules.
Mobility with the

VPLEX migration
wizard
The VPLEX GUI helps you to easily move the physical location of virtual storage while
VPLEX provides continuous access to this storage by the host.
Figure 40 Mobility Central GUI
To move storage:
Display and select the extents (for extent mobility) or devices (for device mobility) to
move.
Display and select candidate storage volumes.
VPLEX moves the data to its new location.
Throughout the process, the volume retains its identity, and continuous access is
maintained to the data from the host.
There are three types of mobility jobs:
Table 4 Types of data mobility operations
Extent
Moves data from one extent to another extent (within a cluster).
Device
Moves data from one device to another device (within a cluster).
Batch
Moves data using a migration plan file. Create batch migrations to automate
routine tasks.
Use batched extent migrations to migrate arrays within the same cluster where
the source and destination have the same number of LUNs and identical
capacities.
Use batched device migrations to migrate to dissimilar arrays and to migrate
devices between clusters in a VPLEX Metro or Geo.
Up to 25 local and 25 distributed migrations can be in progress at the same time.

Best practices
All components of the system (virtual machine, software, volumes) must be available and
in a running state.
Data mobility can be used for disaster avoidance, planned upgrade, or physical movement
of facilities.
How data mobility

works
Mobility moves data from a source extent or device to a target extent or device.
When a mobility job is started, VPLEX creates a temporary RAID 1 device above each
source device or extent that is to be migrated.
The target extent or device becomes a mirror leg of the temporary device, and
synchronization between the source and the target begins.
86
VPLEX Use Cases
The data mobility operation is non-disruptive. Applications using the data continue to
write to the volumes during the mobility operation. New I/Os are written to both legs of the
device.
The following rules apply to mobility operations:
The target extent/device must be the same size or larger than the source
extent/device.
The target device cannot be in use (no virtual volumes created on it).
The target extent cannot be in use (no devices created on it).
You can control the transfer speed of the data mobility operation.
Higher transfer speeds complete the operation more quickly, but have a greater impact on
host I/O.
Slower transfer speeds have less impact on host I/O, but take longer to complete.
You can change the transfer speed of a job while the job is in the queue or in progress. The
change takes effect immediately.
Starting in GeoSynchrony 5.0, the thinness of a thinly provisioned storage volume is
retained through a mobility operation. Prior to 5.0, you must specify that rebuilds should
be thin at the time you provision the thin volume.
Refer to the EMC VPLEX CLI Guide or the online help for more information on thin
provisioning of volumes.
Collaboration
If you require distributed data collaboration, VPLEX can provide a significant advantage.
Traditional collaboration across distance required files to be saved at one location and
then sent to another site. This is slow, incurs bandwidth costs for large files or even small
files that move regularly. Also, it negatively impacts resource productivity as sites sit idle
while they wait to receive the latest changes. Independent work quickly leads to version
control problems as multiple people working at the same time are unaware of each others
most recent changes. Merging independent work is time-consuming, costly, and grows
more complicated as the dataset gets larger.
Current applications for information sharing over distance are not suitable for
collaboration in Big Data environments. Transfer of hundreds of Gb or TB of data across
WAN is inefficient, especially if you need to modify only a small portion of a huge data set,
or use it for analysis.
VPLEX enables multiple users at different sites to work on the same data, and maintain
consistency in the dataset when changes are made.
With VPLEX, the same data can be accessed by all users at all times, even if users are at
different sites. The data is shared and not copied, so that a change made in one site
shows up immediately at the other site.
VPLEX need not ship the entire file back and forth like other solutions. It only sends the
changed updates as they are made, greatly reducing bandwidth costs and offering
significant savings over other solutions.
Collaboration
87
VPLEX Use Cases
With VPLEXs Federated AccessAnywhere, the data remains consistent, online, and always
available.
ACCESS ANYWHERE
Enable concurrent
read/write access to data
across locations
Figure 41 Collaborate over distance with AccessAnywhere
Deploy VPLEX to enable real collaboration between teams located at different sites.
Collaboration using
local consistency
groups
A simple method to support distributed data collaboration is to configure local

consistency groups with global visibility. See Local consistency group with global
visibility on page 57.
Local consistency groups with global visibility allow the remote cluster to read and write to
the local consistency group. The remote cluster has instant on-demand access to the
consistency group.
Local consistency groups with global visibility might contain only local volumes and the
cache mode must be synchronous. Thus, latency between clusters for this configuration
cannot exceed 5ms RTT.
Collaboration over
asynchronous
distances
For distributed data collaboration over greater distances, configure VPLEX Geo
asynchronous consistency groups with member volumes mirrored at both clusters.
At asynchronous distances, latency between clusters can be up to 50ms RTT.
VPLEX Metro HA
VPLEX Metro High Availability (HA) configurations consist of a VPLEX Metro system
deployed in conjunction with VPLEX Witness. There are two types of Metro HA
configurations:
VPLEX Metro HA can be deployed in places where the clusters are separated by 5 ms
latency RTT or less.
VPLEX Metro HA combined with Cross Connect between the VPLEX clusters and hosts
can be deployed where the clusters are separated by 1 ms latency RTT or less.
This section describes the benefits of these two configurations.
88
VPLEX Use Cases
AccessAnywhere enables both clusters to provide simultaneous coherent read/write

access to the same virtual volume. Paths are up and the storage is available during normal
operation and not only after failover.
Metro HA (without
cross-connect)
Combine VPLEX Metro HA with host failover clustering technologies such as VMware HA to
create fully automatic application restart for any site-level disaster.
VPLEX Metro/VMware HA configurations:
Significantly reduce the Recovery Time Objective (RTO). In some cases, RTO can be
eliminated.
Ride through any single component failure (including the failure of an entire storage
array) without disruption.
When VMware Distributed Resource Scheduler (DRS) is enabled, distribute workload

spikes between data centers, alleviating the need to purchase more storage.
Eliminate the requirement to stretch the Fiber Channel fabric between sites. You can
maintain fabric isolation between the two sites.
Figure 42 VPLEX Metro HA
Note: The VPLEX clusters in VPLEX Metro HA configuration must be within 5 ms RTT
latency.
In this deployment, virtual machines can write to the same distributed device from either
cluster and move between two geographically disparate locations.
If you use VMware Distributed Resource Scheduler (DRS) to automate load distribution on
virtual machines across multiple ESX servers, you can move a virtual machine from an ESX
server attached to one VPLEX cluster to an ESX server attached to the second VPLEX
cluster, without losing access to the underlying storage.
VPLEX Metro HA
89
VPLEX Use Cases
Metro HA without
cross-connect failure
management
This section describes the failure scenarios for VPLEX Metro HA without cross-connect.
VPLEX cluster failure

In the event of a full VPLEX cluster outage at one site:
VPLEX Witness guides the surviving cluster to continue.
VMware at the surviving cluster is unaffected.
VMware restarts the virtual machines at the site where the outage occurred,
redirecting I/O to the surviving cluster.
VMware can restart because the second VPLEX cluster has continued I/O without
interruption.
Figure 43 VPLEX Metro HA (no cross-connect) cluster failure
Inter-cluster link failure - non-preferred site

If an inter-cluster link outage occurs, the preferred cluster continues, while the
non-preferred cluster suspends.
Note: The preferred cluster is determined by consistency group detach rules. See Detach
rules on page 58.
If a virtual machine is located at the preferred cluster, there is no interruption of

service.
If a virtual machine is located at the non-preferred cluster, the storage associated with
the virtual machine is suspended.
Most guest operating systems will fail. The virtual machine will be restarted at the
preferred cluster after a short disruption.
90
VPLEX Use Cases
Figure 44 VPLEX Metro HA (no cross-connect) inter-cluster link failure
If an inter-cluster link outage occurs:
VPLEX Witness guides the preferred cluster to continue.
VMware at the preferred cluster is unaffected.
VMware restarts the virtual machines at the non-preferred (suspended) cluster,

redirecting I/O to the preferred (uninterrupted) cluster.
VMware can restart because the second VPLEX cluster has continued I/O without
interruption.
Metro HA with
cross-connect
VPLEX Metro HA with cross-connect (VPLEXs front end ports are cross-connected) can be
deployed where the VPLEX clusters are separated by 1 ms latency RTT or less.
VPLEX Metro HA
91
VPLEX Use Cases
Figure 45 VPLEX Metro HA with cross-connect
VPLEX Metro HA combined with cross-connect eliminates RTO for most of the failure
scenarios.
Metro HA with
cross-connect failure
management
This section describes how VPLEX Metro HA with cross-connect rides through failures of
hosts, storage arrays, clusters, VPLEX Witness, and the inter-cluster link.
Host failure
If hosts at one site fail, then VMware HA restarts the virtual machines on the surviving
hosts. Since surviving hosts are connected to the same datastore, VMware can restart the
virtual machines on any of the surviving hosts.
92
VPLEX Use Cases
Figure 46 VPLEX Metro HA with cross-connect - host failure
Cluster failure
If a VPLEX cluster fails:
VPLEX Witness guides the surviving cluster to continue.
VMware re-routes I/O to the surviving cluster.
No disruption to I/O.
Figure 47 VPLEX Metro HA with cross-connect - cluster failure
Storage array failure

If one or more storage arrays at one site fail:
VPLEX Metro HA
93
VPLEX Use Cases
All distributed volumes continue I/O to the surviving leg.
No disruption to the VPLEX clusters or the virtual machines.
I/O is disrupted only to local virtual volumes on the VPLEX cluster attached to the
failed array.
Figure 48 VPLEX Metro HA with cross-connect - storage array failure
VPLEX Witness failure

If VPLEX Witness fails or becomes unreachable (link outage):
Both VPLEX clusters call home to report that VPLEX Witness is not reachable.
No disruption to I/O, VPLEX clusters, or the virtual machines.
Figure 49 VPLEX Metro HA with cross-connect - VPLEX Witness failure
94
VPLEX Use Cases

Although this failure causes no disruption to the clusters or the virtual machines, it
makes the configuration vulnerable to a second failure of a major component. If a cluster
or inter-cluster link failure occurs while VPLEX Witness is not available, distributed
devices are suspended at both clusters. Therefore, if VPLEX Witness will be unavailable
for an extended period, best practice is to disable the VPLEX Witness and allow the
devices to use their configured detach rules.
Inter-cluster link failure

If the inter-cluster link fails:
VPLEX Witness guides the preferred cluster to continue.
I/O suspends at the non-preferred cluster.
VMware re-routes I/O to the continuing cluster.
No disruption to I/O.
Figure 50 VPLEX Metro HA with cross-connect - inter-cluster link failure
Table 5 summarizes how VPLEX HA with cross-connect manages failures.

Table 5 How VPLEX Metro HA recovers from failure
Failure description
Failure handling
Host failure (Site 1)
VMware HA software automatically restarts the affected applications

at Site 2.
VPLEX cluster failure

(Site 1)
VPLEX Witness detects the failure and enables all volumes on the
surviving cluster.
VPLEX Metro HA
95
VPLEX Use Cases
Table 5 How VPLEX Metro HA recovers from failure

Failure description
Failure handling
Inter-cluster link
failure
If the cross-connects use different physical links from those used

to connect the VPLEX clusters, applications are unaffected. Every
volume continues to be available in one data center or the other.
If the cross-connect links use the same physical links as those
used to connect the VPLEX clusters, an application restart is
required.
Storage array failure
Applications are unaffected. VPLEX dynamically redirects I/O to the

mirrored copy on the surviving array.
Note: This example assumes that all distributed volumes are also
mirrored on the local cluster. If not, then the application remains
available because the data can be fetched or sent from or to the
remote cluster. However, each read/write operation now incurs a
performance cost.
Failure of
VPLEX Witness
Both clusters call home.

As long as both clusters continue to operate and there is no
inter-cluster link partition, applications are unaffected.
CAUTION: If either cluster fails or if there is an inter-cluster link
partition, the system is at a risk of data unavailability. If the VPLEX
Witness outage is expected to be long, disable the VPLEX Witness
functionality to prevent the possible data unavailability.
Redundancy with RecoverPoint

EMC RecoverPoint provides comprehensive data protection by continuous replication of
host writes. With RecoverPoint, applications can be recovered to any point in time.
Replicated writes can be written to:
Local volumes, to provide recovery from operational disasters.
Remote volumes, to provide recovery from site disasters.
Both local and remote volumes.
VPLEX GeoSynchrony includes a RecoverPoint splitter. A splitter is software that duplicates

application writes so that they are sent to their normally designated volumes and RPAs
simultaneously. The splitter is built into VPLEX such that the VPLEX volumes can have their
I/O replicated by RecoverPoint Appliances (RPAs) to volumes that are located in VPLEX on
one or more heterogeneous storage arrays.
Note: RecoverPoint integration is offered for VPLEX Local and VPLEX Metro configurations
(not for VPLEX Geo).
96
VPLEX Use Cases
The VPLEX splitter works with a RecoverPoint Appliance (RPA) to orchestrate the
replication of data either remotely or locally, or both.
Figure 51 RecoverPoint architecture
The VPLEX splitter enables VPLEX volumes in a VPLEX Local or VPLEX Metro to mirror I/O to
a RecoverPoint Appliance.
RecoverPoint Appliances
The RecoverPoint Appliance manages all aspects of data protection. One RPA can manage
multiple replication sets (production volume and one or more replica volumes to which it
replicates), each with differing policies.
For redundancy, a minimum of two RPAs are installed at each site, located in the same
facility as the host and storage. Each site can have as many as eight RPAs.
The set of RPAs installed at each site is referred to as an RPA cluster. If one RPA in a cluster
fails, the functions provided by the failed RPA are automatically moved to one or more of
the remaining RPAs.
In the case of remote replication or mixed local and remote replication, RPAs are required
at both sites. The RPAs at the production site transfer the split I/O to the replica site.
The RPAs at the replica site distribute the data to the replica storage.
In the event of a failover, these roles can be reversed. The same RPA can serve as the
production RPA for one RecoverPoint consistency group and as the replica RPA for another.
RecoverPoint Volumes
RecoverPoint requires volumes to act as repository volumes, journal volumes, and

production volumes. All RecoverPoint volumes can be hosted on VPLEX. In practice, some
volumes can be hosted on VPLEX and others can be hosted on non-VPLEX storage. For
example, the repository volume for an existing RPA cluster cannot be moved. If you are
installing VPLEX into an existing RecoverPoint configuration, the repository volume is
already configured on non-VPLEX storage.
Note: Starting in GeoSynchrony 5.2 and RecoverPoint 4.0, the RecoverPoint supports 8K
volumes.
The following types of volumes are required in all RecoverPoint configurations:
97
VPLEX Use Cases
Recovery/Failover
Repository volume - A volume that is dedicated to RecoverPoint for each RPA cluster.
The repository volume serves all RPAs of the particular RPA cluster and the splitter
associated with that cluster. The repository volume stores configuration information
about the RPAs and RecoverPoint consistency groups. There is one repository volume
per RPA cluster.
Production volumes - Volumes that are written to by the host applications. Writes to
production volumes are split such that they are sent to both the normally designated
volumes and RPAs simultaneously. Each production volume must be exactly the same
size as the replica volume to which it replicates.
Replica volumes - Volumes to which production volumes replicate. In prior releases,

the replica volume must be exactly the same size as its production volume. In
RecoverPoint 4.0 and GeoSynchrony release 5.2, RecoverPoint supports a feature
called Fake Size, where the replica volume size can be higher than the production
volume.
Journal volumes - Volumes that contain data waiting to be distributed to target replica
volumes and copies of the data previously distributed to the target volumes. Journal
volumes allow convenient rollback to any point in time, enabling instantaneous
recovery for application environments.
RecoverPoint provides several image access methods on a replica journal to enable

read/write access to a selected point-in-time at a replica. There are four image access
modes:
Logged (physical) access - Used for production recovery, failover, testing, and cloning
a replica.
Virtual (instant) access - Used for single file recovery or light testing. Used to gain
access to the replica data immediately, or when I/O performance is not important.
Virtual (instant) access with roll - Used for production recovery, failover, or processing
with a high write-rate. Used when the point-in-time image is far from the current
point-in-time (and would take too long to access in logged access mode).
Direct access - This access mode can only be enabled after logged access, or virtual
access with roll, are enabled. Used for extensive processing with a high write-rate,
when image access is needed for a long period of time (and may not have the journal
space to support all of the data written to the image access log in this time), and when
it is not required to save the history in the replica journal (the replica journal is lost
after direct access).
Note: In the current release, virtual (instant) access and virtual (instant) access with roll
are not supported by the VPLEX splitter.
A bookmark is a label applied to a snapshot so that the snapshot can be explicitly called
(identified) during the recovery processes (during image access).
Bookmarks are created through the RecoverPoint GUI and can be created manually, by the
user, or automatically, by the system. Bookmarks created automatically can be created at
pre-defined intervals or in response to specific system events. Parallel bookmarks are
bookmarks that are created simultaneously across multiple consistency groups.
98
VPLEX Use Cases
RecoverPoint configurations
RecoverPoint supports three replication configurations:
Figure 52 RecoverPoint configurations
Local Replication
In a Local Replication, RecoverPoint continuously replicates data within the same site.
Every write is kept in the journal volume, allowing recovery to any point in time. By default,
snapshot granularity is set to per second, so the exact data size and contents are
determined by the number of writes made by the host application per second. If
necessary, the snapshot granularity can be set to per write.
Remote Replication
In these configurations, data is transferred between a local and a remote site over Fibre
Channel or a WAN. The RPAs, storage, and splitters are located at both the local and the
remote site.
By default, the replication mode is set to asynchronous, and the snapshot granularity is
set to dynamic, so the exact data size and contents are determined by the policies set by
the user and system performance. This provides application consistency for specific
points in time.
Synchronous replication is supported when the local and remote sites are connected
using Fibre Channel or IP.
Local and Remote Data Protection
In this configuration RecoverPoint replicates data to both a local and a remote site
simultaneously, providing concurrent local and remote data protection.
The local copy is normally used for operational recovery, while the remote copy is used for
disaster recovery.
RecoverPoint/VPLEX configurations
RecoverPoint can be configured on VPLEX Local or Metro systems as follows:
VPLEX Local and Local Protection
VPLEX Local and Local/Remote Protection

99
VPLEX Use Cases
VPLEX Metro and RecoverPoint local at one site
VPLEX Metro and RecoverPoint with both Local and Remote Replication
In VPLEX Local systems, RecoverPoint can replicate local volumes.

In VPLEX Metro systems, RecoverPoint can replicate local volumes and distributed RAID 1
volumes.
Virtual volumes can be replicated locally, remotely, or both.
Distances between production sources and replication volumes vary based on the
recovery objectives, inter-site bandwidth, latency, and other limitations outlined in the
EMC Simple Support Matrix (ESSM) for RecoverPoint.
VPLEX Local and Local Protection

In VPLEX Local with local protection configurations, I/O is split to replica volumes that are
located at the same site.
RPAs are deployed with the VPLEX cluster.
This configuration supports unlimited points in time, with granularity up to a single write
for local VPLEX virtual volumes. The replica volume can be a VPLEX virtual volume or any
other heterogeneous storage supported by RecoverPoint.
Application event aware based rollback is supported for Microsoft SQL, Microsoft
Exchange, and Oracle database applications.
Users can quickly return to any point-in-time, to recover from operational disasters.
Figure 53 VPLEX Local and RecoverPoint
VPLEX Local and Local/Remote Protection

In VPLEX Local with local/remote protection configurations, I/O is split to replica volumes
located both at the site where the VPLEX cluster is located and a remote site.
100
VPLEX Use Cases
RPAs are deployed at both sites.

If the local replication site fails, you can recover to any point in time at the remote site.
Recovery can be automated through integration with MSCE and VMware SRM.
This configuration can simulate a disaster at the local site to test RecoverPoint disaster
recovery features at the remote site.
Application event aware based rollback is supported for Microsoft SQL, Microsoft
Exchange, and Oracle database applications.
The remote site can be an independent VPLEX cluster:
Figure 54 VPLEX Local and RecoverPoint Remote - remote site is independent VPLEX cluster
or, the remote site can be an array-based splitter:
Figure 55 VPLEX Local and RecoverPoint remote - remote site is array-based splitter
VPLEX Metro and RecoverPoint local at one site

In VPLEX Metro/RecoverPoint local replication configurations, I/O is split to replica
volumes located at only one VPLEX cluster.
101
VPLEX Use Cases
RPAs are deployed at one VPLEX cluster:
Figure 56 VPLEX Metro and RecoverPoint local replication
VPLEX Metro/RecoverPoint local replication configurations support unlimited points in

time on VPLEX distributed and local virtual volumes.
Users can quickly return to any point-in-time, in order to recover from operational
disasters.
VPLEX Metro and RecoverPoint with both Local and Remote Replication
In VPLEX Metro/RecoverPoint with both local and remote replication configurations, I/O is:
Written to both VPLEX clusters (as part of normal VPLEX operations).
Split on one VPLEX cluster to replica volumes located both at the cluster and at a
remote site.
RPAs are deployed at one VPLEX cluster and at a third site.

The third site can be an independent VPLEX cluster:
Figure 57 VPLEX Metro and RecoverPoint local and remote replication- local site is located at one
cluster of the VPLEX.
102
VPLEX Use Cases
or, the remote site can be an array-based splitter:
Figure 58 VPLEX Metro and RecoverPoint local and remote replication- remote site is array-based
splitter
This configuration supports unlimited points in time, with granularity up to a single write,
for local and distributed VPLEX virtual volumes.
RecoverPoint Appliances can (and for MetroPoint must) be deployed at each VPLEX
cluster in a Metro system. For MetroPoint replication, a different RecoverPoint cluster
must be viewing each exposed leg of the VPLEX distributed volume. The two
RecoverPoint clusters become the active and standby sites for the MetroPoint group.
All RecoverPoint protected volumes must be on the preferred cluster, as designated by

VPLEX consistency group-level detach rules.
Customers can recover from operational disasters by quickly returning to any

point-in-time on the VPLEX cluster where the RPAs are deployed or at the third site.
Application event aware based rollback is supported on VPLEX Metro distributed/local

virtual volumes for Microsoft SQL, Microsoft Exchange, and Oracle database
applications.
If the VPLEX cluster fails, then the customers can recover to any point in time at the
remote replication site. Recovery at the remote site to any point in time can be
automated through integration with MSCE and VMware Site Recovery Manager (SRM).
See vCenter Site Recovery Manager support for VPLEX on page 106.
This configuration can simulate a disaster at the VPLEX cluster to test RecoverPoint
disaster recovery features at the remote site.
103
VPLEX Use Cases
Shared VPLEX splitter

The VPLEX splitter can be shared by multiple RecoverPoint clusters. This allows data to be
replicated from a production VPLEX cluster to multiple RecoverPoint clusters.
Figure 59 Shared VPLEX splitter
Up to four RecoverPoint clusters can share a VPLEX splitter.
Shared RecoverPoint RPA cluster

The RecoverPoint cluster can be shared by multiple VPLEX sites:
Figure 60 Shared RecoverPoint RPA cluster
RecoverPoint replication with CLARiiON

VPLEX and RecoverPoint can be deployed in conjunction with CLARiiON based
RecoverPoint splitters, in both VPLEX Local and VPLEX Metro environments.
104
VPLEX Use Cases
In the configuration depicted below, a host writes to VPLEX Local. Virtual volumes are
written to both legs of RAID 1 devices. The VPLEX splitter sends one copy to the usual
back-end storage, and one copy across a WAN to a CLARiiON array at a remote disaster
recovery site.
Figure 61
Replication with VPLEX Local and CLARiiON
In the configuration depicted below, host writes to the distributed virtual volumes are
written to the both legs of the distributed RAID 1 volume. Additionally, a copy of the I/O is
sent to the RPA. RPA then distributes to the replica on the CLARiiON array at a remote
disaster recovery site:
Figure 62
Replication with VPLEX Metro and CLARiiON
105
VPLEX Use Cases
vCenter Site Recovery Manager support for VPLEX

With RecoverPoint replication, you can add Site Recovery Manager support to VPLEX.
Figure 63 Support for Site Recovery Manager
When an outage occurs in VPLEX Local or VPLEX Metro configurations, the virtual
machines can be restarted at the replication site with automatic synchronization to the
VPLEX configuration when the outage is over.
MetroPoint
VPLEX GeoSynchrony 5.4 along with RecoverPoint 4.1 SP1 supports a new topology for
VPLEX Metro with RecoverPoint protection. This MetroPoint topology provides a 3-site or
4-site solution for continuous availability, operational and disaster recovery, and
continuous data protection. MetroPoint also supports a 2-site topology with the ability to
expand to a third remote site in future.
The MetroPoint topology provides full RecoverPoint protection of both sides of a VPLEX
distributed volume across both sides of a VPLEX Metro configuration, maintaining
replication and protection at a consistency group level, even when a link from one side of
the VPLEX Metro to the replication site is down.
In MetroPoint, VPLEX Metro and RecoverPoint replication are combined in a fully
redundant manner to provide data protection at both sides of the VPLEX Metro and at the
replication site. With this solution, data is replicated only once from the active source site
to the replication site. The standby source site is ready to pick up and continue replication
even under a complete failure of the active source site.
MetroPoint combines the high availability of the VPLEX Metro with redundant replication
and data protection of RecoverPoint. MetroPoint protection allows for one production copy
of a distributed volume on each Metro site, one local copy at each Metro site, and one
remote copy for each MetroPoint consistency group. Each production copy can have
multiple distributed volumes.
MetroPoint offers the following benefits:
106
Full high availability for data access and protection.
VPLEX Use Cases
Continuous data protection and disaster recovery.
Operational recovery at all three sites for redundancy.
Efficient data transfer between VPLEX Metro sites and to the remote site.
Load balancing across replication links and bi-directional replication.
Out of region data protection with asynchronous replication.
Any-Point-in-Time operational recovery in the remote site and optionally in each of the
local sites. RecoverPoint provides continuous data protection with any-point-in-time
recovery.
Full support for all operating systems and clusters normally supported with VPLEX
Metro.
Support for a large variety of EMC and third-party storage arrays.
Two-site topology
RecoverPoint Local Replication can now be added to both sides of a VPLEX Metro to
provide redundant operational recovery for the same application. To achieve this, all of the
volumes associated with an application must be placed in a MetroPoint group, even
though a third site is not configured.
This two-site configuration still requires GeoSynchrony 5.4 and RecoverPoint 4.1 SP1 that
supports MetroPoint on both VPLEX and RecoverPoint. In the two-site topology,
distributed devices are protected with an independent local copy at both Metro sites that
allows for independent replication at either side of a VPLEX Metro for a distributed
volume. Replication continues at one site if an outage occurs at the other site.
With VPLEX Metro, production continues to be available from one site after a WAN COM
failure or a VPLEX cluster failure when configured with VPLEX Witness. To access copy
data, the administrator decides which copy to use. When two VPLEX clusters are not in
contact, administrators are recommended to use the copy from the site where the
production volume is accessible by the host. Regardless of which copy is used for
recovery, replication history is maintained.
If recovery is done on the losing site during a VPLEX WAN partition, manual intervention is
required to select the sites data to use after the WAN link is restored. The losing site will
not be able to create bookmarks while the volumes rebuild, but replication history will not
be lost.
MetroPoint
107
VPLEX Use Cases
The MetroPoint two-site configuration can be upgraded non-disruptively in future by

adding a third remote site for full MetroPoint protection and disaster recovery.
Figure 64 MetroPoint Two-site Topology
Three-site topology
The MetroPoint three-site topology provides continuous availability between both sides of
the VPLEX Metro, with operational and disaster recovery to a third remote site.
This solution provides full RecoverPoint protection to the VPLEX Metro configuration,
maintaining replication even when one site of the Metro is down. RecoverPoint protects
distributed RAID 1 devices on both sides of the Metro. If there is a site failure, replication
automatically continues at a consistency group level from the surviving site, without
losing replication history.
Journal and repository volumes are local, not distributed. This enhances performance and
reduces load on the inter-cluster link resulting from high I/O traffic needed for journals.
The three-site MetroPoint topology features a VPLEX Metro (Site A and Site B) and a
remote Site C. Site C can be any valid array based splitter option including:
108
VPLEX Local
VPLEX Metro
VNX
VNX2
VPLEX Use Cases
VMAX
Figure 65 Basic MetroPoint Three-site Topology
The above figure illustrates the basic MetroPoint topology, with a VPLEX Metro system
consisting of VPLEX sites A and B, and a remote Site C. Each site is protected by a
RecoverPoint cluster. In this example, both production copies of the VPLEX distributed
volume are protected by RecoverPoint clusters at sites A and B. The remote replicating
RecoverPoint cluster is Site C.
One RecoverPoint cluster at Metro Site A is configured as the active source of remote
replication, while the other RecoverPoint cluster at Metro Site B is the standby source.
Both active and standby source sites maintain up-to-date journals. If the active source
cluster fails, the standby source site instantly switches over and becomes the active
source of remote replication after a short initialization period.
MetroPoint also allows for local copies of the distributed volume at each site in addition to
the remote copy. The local copies are independent of one another.
For each volume protected, a single consistency group spans the three related sites.
MetroPoint consistency groups are referred to as MetroPoint groups. The MetroPoint group
has a production copy on both Metro sites. The production copy at the active source site is
the only one that replicates to the remote site.
MetroPoint
109
VPLEX Use Cases
Figure 66 RecoverPoint Local Replication for VPLEX Distributed Volumes at Site A and Site B and
RecoverPoint Remote Replication at Site C
MetroPoint configurations must adhere to both VPLEX and RecoverPoint best practices for
the distances between sites. In a VPLEX Metro, the production copies should be within
synchronous distance. For RecoverPoint, the site for the remote copy can be within
synchronous or asynchronous distance.
Note: See the document, Implementation and Planning Best Practices for EMC VPLEX:
VS2 Hardware and GeoSynchrony v5.x Technical Note for best practices information.
Distributed volumes
RecoverPoint protects VPLEX distributed volumes on both Metro Sites A and B for
redundancy, and protects copies on the remote site.
Local (non-distributed) volumes
VPLEX local (non-distributed) volumes can be replicated by RecoverPoint from any Site A,
B, or C, and are protected by RecoverPoint Local Replication.
Local volumes can be replicated from Site C to Site A or Site B if the volumes are
independent from the VPLEX volumes that are distributed from Sites A and B.
110
VPLEX Use Cases
Figure 67 Bi-directional replication for volumes in different consistency groups and local volumes
Distributed RAID 1 volumes in MetroPoint groups from Site A and Site B replicate to
remote Site C.
Local volumes on Site A, B, or C can replicate to a target volume on a site other than their
local site. For example, a local volume on Site C can replicate to Site B, or a local volume in
a different VPLEX consistency group in Site A can replicate to Site C. RecoverPoint
supports bi-directional replication for volumes in different consistency groups.
Failure scenarios
MetroPoint protects applications and data from any failure scenario including:
Any single component failure
A complete site failure
A regional failure that affects two sites
Data unavailability due to user errors
Data corruption
For disaster recovery, when creating MetroPoint groups, the best practice is to set the
group policy for the preferred source of remote replication to the default Follow VPLEX
bias rules. This provides added protection in that RecoverPoint will select the side that
the VPLEX consistency group will declare as the winner site in the event of link failures in
the VPLEX Metro system and prevent unnecessary swapping of the source of replication.
MetroPoint
111
VPLEX Use Cases
If a disaster occurs with either the RecoverPoint cluster or the VPLEX Metro which prevents
the active source site from replicating, it can select the other site for the remote replication
to continue.
Figure 68 Active Source Site A Failure
If Site A failed, operations would continue uninterrupted at Site B. Replication from Site A
would switch over to replicate from Site B to remote Site C without losing replication
history. Site B would now be the active source site until Site A is restored on a consistency
group level.
When recovering from a local copy after a switchover, the remote copy is temporarily
disabled. Both local copies are initialized when one is restored, and the remote copy will
be updated after recovery and a short initialization.
Asynchronous WAN replication load balancing is done using VPLEX bias rules. By default,
the active and standby source sites are based on VPLEX bias rules that are configured at
the consistency group level. Using this method, the active source site is the site that has
bias. Using the bias rules, replication traffic can be load balanced across the links at a
consistency group level. Load balancing between the two source sites improves resource
distribution and provides better high availability.
112
VPLEX Use Cases
Figure 69 Remote Site C Failure
If the RecoverPoint cluster fails at the remote site (Site C), local replication continues on
distributed RAID 1 volumes on both sides of the Metro (Site A and Site B). There is no
copy, no replication, and no image access at Site C.
When the remote RecoverPoint cluster is restored, RecoverPoint automatically
resynchronizes and replication resumes at the remote site.
The MetroPoint topology is specifically designed to provide protection in the following
scenarios:
VPLEX site departure, inter-cluster link failure
VPLEX site failure on the RecoverPoint active production copy
RecoverPoint failure (active source)
Data corruption
VPLEX site departure, inter-cluster link failure

A site departure occurs when the communication link between two VPLEX Metro sites is
down. When this occurs:
Replication continues through the VPLEX winner site.
The preferred RecoverPoint cluster can be chosen manually in RecoverPoint.

Alternatively, the preferred RecoverPoint cluster can be set to follow VPLEX bias rules
for the VPLEX consistency group.
MetroPoint
113
VPLEX Use Cases
If the preferred RecoverPoint cluster is not at the VPLEX winning site, a production
switchover occurs. During the site departure, RecoverPoint at the VPLEX winning site
continues to replicate to the remote site.
The losing site does not receive any I/Os during the site departure and does not
maintain an up-to-date journal.
A local copy at the losing site will not be updated.
A local copy at the winning site continues to be updated.
Recovery and Restoration procedures
Restore the VPLEX inter-cluster link.
Once communication between the two VPLEX sites is restored, VPLEX automatically
resynchronizes both clusters according to the I/Os that occurred during the fracture.
RecoverPoint replication continues during the synchronizing process.
When the VPLEX clusters are fully synchronized, if there is a local copy at the losing
site, RecoverPoint synchronizes the local copy with the winning site, then resumes
replicating to it.
VPLEX site failure on the RecoverPoint active production copy

When the active VPLEX site with active RecoverPoint production fails to write to storage or
its storage production fails, it notifies RecoverPoint that a source production switchover is
needed. When this occurs:
The standby production copy becomes the active production copy and continues
replicating to the remote cluster.
Recovery and Restoration procedure
When the failed VPLEX site resumes writing to storage and if it is set as the preferred
site, there is a production switchback and RecoverPoint at that cluster resumes
RecoverPoint failure at active source

When the RecoverPoint active production fails to write to the remote cluster from the
active site, a production switchover occurs. When this occurs:
The standby production copy becomes the active production copy and continues
114
When communication between the previously active production RecoverPoint cluster

and the remote RecoverPoint cluster resumes, and if it is the preferred site, then there
is a production switchback and RecoverPoint at that cluster resumes replicating to the
remote cluster.
VPLEX Use Cases
Data corruption
Data corruption can occur for various reasons. When data becomes corrupted:
Halt applications.
In RecoverPoint, find the last uncorrupted image.
In RecoverPoint, restore production from the last uncorrupted image at copy.
Note: See a complete list of production and copy disaster/failure scenarios in EMC
RecoverPoint: Deploying with VPLEX Technical Notes.
Four-site topology
The four-site MetroPoint topology is an advanced configuration that features two VPLEX
Metro systems in different regions. This protects applications running in separate regions
and allows for cross-regional and bi-directional replication. As with the three-site
MetroPoint topology, each consistency group in a region is configured to have an active
source production and a standby source production.
The target replication device for the consistency group must be a VPLEX Metro in the case
of four-site topology. Third party devices are supported if they are behind VPLEX. The
target volume can be either a local or distributed volume. If the target volume is a
distributed volume, it will be fractured. However, when a switchover to the remote copy is
executed, active-active access to the volume on both Metro sites becomes available
immediately, as the remote copy is now the production copy.
MetroPoint
115
VPLEX Use Cases
Figure 70 MetroPoint Four-Site Configuration
Data is not replicated to all four sites, at a consistency group level it is replicated to a
single target. If the target replica is a distributed RAID 1, it will be in a fractured state.
If production fails over from across regions, the target fractured volume will automatically
start rebuilding the mirror leg. This provides continuous availability between the two sites,
once the distributed volume is rebuilt and synchronized.
The four-site MetroPoint topology provides regional replication protection for two regions
or two VPLEX Metro systems.
116
VPLEX Use Cases
Figure 71 MetroPoint four-site configuration for a single consistency group
In the four-site configuration, production applications running in Site A and Site B are
replicated to Site C for disaster protection. Distributed volumes at VPLEX Metro Site C and
Site D can be replicated to a single target volume at remote Site A or Site B (but not both).
Different applications, with volumes in different consistency groups, can run in Site C and
Site D as active and standby source sites and be protected in one remote site, Site A or
Site B.
Note: Data is not replicated to all four sites. Each MetroPoint group is replicated to a single
target. Different MetroPoint groups can have different targets.
Four-site Failure and Recovery

In a regional disaster, such as a tornado or flood, Site A and Site B fail and applications fail
over to remote Site C.
MetroPoint
117
VPLEX Use Cases
Figure 72 Site A and Site B failure showing failover to Site C
If a regional disaster causes both sides of the Metro to fail, operations can fail over to the
disaster recovery Site C.
When the MetroPoint group fails over to Site C, the replication will be from Site C to Metro
Site A or Site B, whichever is currently defined as the winner site in VPLEX.
The production source is now in the remote site and one of the Metro sites becomes the
replica. The mirrored leg of the fractured DR1 is rebuilt at the remote site.
118
VPLEX Use Cases
Figure 73 During failover, Site C and Site D become the production sites.
This figure illustrates that production sites (A and B) have failed over to the remote Site C,
which is now the production site with Site D. The fractured distributed RAID 1 volume on
Site C changes from a replica volume to a production volume, so Site D is rebuilt. The DR1
volume on Site A and Site B becomes fractured during the failover, as it is now the replica
copy at the remote site for production sites C and D.
In a recovery following Site A and Site B failure, Site C will restore the last active site, Site A
or Site B, which will automatically become the winner site and be restored. VPLEX rebuilds
the non-winner site. Site A and Site B are restored as the production sites and the DR1
volume at Site C becomes fractured again, as it is now the replica copy.
Upgrading to MetroPoint
Install a new MetroPoint configuration, or upgrade from existing VPLEX and/or
RecoverPoint configurations easily and non-disruptively.
MetroPoint
119
VPLEX Use Cases
IMPORTANT
Note that MetroPoint is a property that is specific to a configured consistency group.
Simply having a VPLEX Metro system with multiple RecoverPoint clusters configured for
protection does not provide MetroPoint protection to the system. For MetroPoint
protection, the MetroPoint property must be configured for each consistency group to be
protected.
All operating system platforms and clusters normally supported with VPLEX are fully
supported with MetroPoint. See the latest copy of VPLEX ESSM for specific details.
The following MetroPoint deployments are available:
New MetroPoint installation - Install VPLEX Metro and RecoverPoint and create
MetroPoint groups.
Upgrade from RecoverPoint - Non-disruptively upgrade from RecoverPoint to a

MetroPoint topology by installing VPLEX into an existing RecoverPoint environment.
Attach RecoverPoint to both VPLEX clusters.
Upgrade from VPLEX - Non-disruptively upgrade to a MetroPoint topology from an

existing VPLEX Local or Metro configuration. This adds a third site to provide
RecoverPoint local protection on both local sites and provides remote protection at
the distant site. Attach RecoverPoint at the second VPLEX Metro site.
Upgrade from an existing VPLEX and RecoverPoint configuration - Non-disruptively

upgrade to MetroPoint from an existing VPLEX and RecoverPoint configuration that is
currently using remote replication to a third site. Attach RecoverPoint at the second
VPLEX Metro site and convert existing RecoverPoint consistency groups to MetroPoint
groups.
See the VPLEX procedures in the EMC SolVe Desktop for more information about installing
and upgrading to MetroPoint.
MetroPoint groups
After MetroPoint has been enabled on the system, create new MetroPoint groups or
convert existing RecoverPoint consistency groups to MetroPoint groups to enable
MetroPoint protection. All MetroPoint groups are protected at both sides of the VPLEX
Metro by RecoverPoint.
A MetroPoint group can contain the following copies:
One production copy at the active source site
One production copy at the standby source site
Zero, one, or two local copies
One remote copy
A MetroPoint group, when configured with two local copies, will contain the maximum of
five copies.
MetroPoint groups and regular RecoverPoint consistency groups can co-exist in the same
system. However, regular RecoverPoint consistency groups are protected on one side only,
at the VPLEX preferred site.
120
VPLEX Use Cases
A MetroPoint group consists of distributed volumes or local volumes. They cannot be

combined in the same MetroPoint group. One MetroPoint group can replicate to a remote
site and another MetroPoint group can replicate to a different remote site.
Each MetroPoint group can be configured to:
Replicate from Metro Site A
Replicate from Metro Site B
Follow VPLEX bias rules
The best practice is to select the default "Follow VPLEX bias rules" which provides added
protection in RecoverPoint that will select the side that the VPLEX consistency group will
declare as the winner in the instance of link failures in the VPLEX Metro system and
prevent any unnecessary swapping of the source of replication.
See the EMC RecoverPoint Administration Guide and VPLEX procedures in the SolVe
Desktop for more information on creating or converting a consistency group to a
MetroPoint group.
Creating a MetroPoint group

A MetroPoint group protects distributed RAID 1 volumes on both sides of the VPLEX Metro.
To create a new MetroPoint group:
In Unisphere for VPLEX, ensure you have provisioned storage and created the
distributed devices you want to use.
Create VPLEX consistency groups that are RecoverPoint enabled.
Expose the storage in the VPLEX consistency groups to RecoverPoint and expose the
hosts through the storage views.
In Unisphere for RecoverPoint, ensure that the distributed device is exposed to the
RecoverPoint cluster local to each VPLEX Metro cluster and it belongs to a storage view
on VPLEX Metro Site A and Metro Site B. RecoverPoint will see the same volume on
both Metro sites and use it to filter distributed volumes.
Converting to a MetroPoint group

An existing consistency group can be converted to a MetroPoint group.
There are two ways to convert existing consistency groups:
Take a RecoverPoint consistency group that is already using distributed RAID 1

volumes for production volumes and convert it to a MetroPoint group.
Upgrade from a consistency group that is using local volumes by converting the local
volumes to VPLEX distributed volumes and creating a MetroPoint group.
Currently, upgrading local volumes is disruptive to RecoverPoint replication. The volumes

that are to be converted from local devices to distributed devices must be removed from
RecoverPoint replication sets and VPLEX consistency groups. Host I/O continues. Currently
VPLEX architecture constraints prevent adding mirror legs to volumes that are splitting I/O
to RecoverPoint, and VPLEX also does not allow different volume topologies to exist in the
same consistency group.
The local volumes are removed from the RecoverPoint replication set, then from the VPLEX
MetroPoint
121
VPLEX Use Cases
consistency group. A mirror leg is added to create a VPLEX distributed device, which is
then placed back in a RecoverPoint enabled consistency group. Create replication sets for
the volumes in the RecoverPoint consistency group in the Unisphere for RecoverPoint user
interface, then create the MetroPoint group using the Protect Volumes Wizard in the same
user interface.
Failover
The following are the two types of failover:
Production failover - This failover refers to the act of reversing replication. In a

production failover, the original production source becomes the replica target and the
earlier replica target becomes the replication source.
Active source failover - This failover is unique to MetroPoint groups having two
production sources, one active and one standby for a given remote replication target.
During active source failover, the active source and standby source will exchange their
roles, that is, the active source becomes the standby source and the standby source
becomes the active source.
The VPLEX SolVe Desktop provides more information on performing a failover.
Active source failover

Active source failover is a failover between the active and standby source sites. The best
site mechanism determines if a failover is required. A failover between the source and
standby requires only a short initialization using the delta marker information from the
standby site.
In Figure 74, Site A is the active source site and Site B is the standby source site. I/Os are
replicated to the local copies regardless of the active source site. However, the remote
copy receives I/Os only from the active source site.
122
VPLEX Use Cases
Figure 74 MetroPoint - two local copies
Figure 75 illustrates source failover. If the active source site (Site A) fails, the best site
mechanism initiates a source failover. The delta marker information from the standby site
(Site B) is resynchronized to the remote site (Site C). Site B becomes the active source site.
MetroPoint
123
VPLEX Use Cases
Figure 75 Source failover
You can also manually failover the active source site. Manually failing over the active
source of production depends upon the group policy of the RecoverPoint consistency
group and the set preferred cluster. The preferred cluster can be set either to a specific
RecoverPoint cluster, or to follow VPLEX bias rules.
If the preferred cluster is set to Follow VPLEX bias rules, then the active source site
follows the VPLEX winner rules set for the consistency group. If you want to swap from
Site A to Site B, you must change the VPLEX winner rules to specify that Site B wins
instead of Site A and the RecoverPoint active source automatically swaps to the other
VPLEX site.
If the preferred cluster in RecoverPoint is set to a specific RecoverPoint cluster, the

active source of replication can be swapped to the other site by selecting the opposite
RecoverPoint cluster.
The VPLEX SolVe Desktop provides more information on performing a manual switch over
of the active site.
Production failover to the remote copy

In the case of failover to a remote copy, the active source is changed to be the remote copy
and all the other copies are removed from the consistency group. Figure 76 illustrates a
production failover to remote copy.
For example, if a MetroPoint group has two local copies, one on each Metro site and one
copy at a remote location, production failover from the active source site (Site A) to the
remote site (Site C) causes replication direction to reverse from Site C to Site A. All other
replication links are removed (if Site A is up and running).
124
VPLEX Use Cases
Figure 76 Production failover to the remote copy
Production failover to the local copy

Failover to a local copy is not very different from failover to a remote copy. However, it is
limited only to the active source site. If a site disaster forces you to shift over to the
standby source site, you must first change the active source site and then perform a
failover to the local copy.
If the failed over local copy is also a distributed device, hosts can have active/active
access to the failed over copy (now acting as the replication source) from both the VPLEX
Metro sites.
Note: If a DR1 volume is selected as a local copy, then that DR1 volume must have its
configured bias set to the site where it will be a local copy. I/O is replicated to only one leg
of the DR1 and is not distributed to the other leg of the DR1 copy. However, after
production failover to the DR1 local copy, the host can access DR1 from both VPLEX sites,
and VPLEX rebuilds DR1 legs to synchronize both legs of the DR1 volume.
Recover Production
The MetroPoint topology enables you to perform recover production from each of the
copies (either remote or local on any site) without losing the journal on either of the Metro
sites.
MetroPoint
125
VPLEX Use Cases
Figure 77 illustrates the recover production flow. In this example, the recover production
happens from the remote copy. The remote copy is moved to the image access state. The
active source site (Site A) is moved to FAIL-ALL, which stops host I/O and VPLEX I/O
synchronous distribution between Site A and Site B (DR1 fracture). In this state, only
replication I/O from RPA is allowed on DR1 leg at Site A. The replication to the local copy is
paused. The splitters in Site B are in the Marking On Hosts (MOH) state because of a
mirror fracture. A init is performed from the remote copy to Site A. Then the replication
direction is reversed back and Site A is out of FAIL-ALL. Mirror recovery of Site B starts with
VPLEX DR1 rebuild using Site A as the source. When mirror recovery ends, the local copy is
initialized. Finally, the sync-peer-splitter removes the redundant information and
information from Site B to Site C is synchronized.
Figure 77 Recover production
126
APPENDIX A
VS1 Hardware
This appendix describes VPLEX VS1 hardware, IP addressing, and internal cabling. Topics
include:
VS1 cluster configurations ....................................................................................

VS1 engine ...........................................................................................................
VS1 IP addresses and component IDs ...................................................................
VS1 Internal cabling ..............................................................................................
127
130
130
132
VS1 cluster configurations

This section illustrates the components in VS1 clusters.
VS1 single-engine cluster
ON
I
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
Management server
ON
I
O
OFF
Engine 1
Director 1B
Director 1A
SPS 1
VPLX-000215
Figure 78 VS1 single-engine cluster

VS1 Hardware
127
VS1 Hardware
VS1 dual-engine cluster
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF

UPS B
UPS A
O
OFF
O
OFF
ON
I
ON
I
Management server
Engine 2
Director 2B
Director 2A
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
SPS 2
Engine 1
Director 1B
Director 1A
SPS 1
VPL
Figure 79 VS1 dual-engine cluster
128
VS1 Hardware
VS1 quad-engine cluster
Director 4B
Director 4A
Engine 4
ON
I
ON
I
O
OFF
O
OFF
SPS 4
Engine 3
SPS 3
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
Director 3B
Director 3A

UPS B
UPS A
O
OFF
O
OFF
ON
I
ON
I
Management server
Engine 2
Director 2B
Director 2A
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
SPS 2
Engine 1
Director 1B
Director 1A
SPS 1
VPL
Figure 80 VS1 quad-engine cluster
VS1 cluster configurations
129
VS1 Hardware
VS1 engine
IOM B0
1
2
F
F
0
F
3
F
0
F
IOM B1
1
2
F
F
3
F
0
B
IOM B2
1
2
B B
3
B
0
B
IOM B3
1
2
B B
3
B
Power supply B
Director B
Power supply A
Side B
mgmt. module
0
F
IOM A0
1
2
F
F
0
L
IOM B4
IOM B5
1
2
3
0 1
2
L WF WF WI WI n
3
F
0
F
IOM A1
1
2
F
F
3
F
0
B
IOM A2
1
2
B B
0
L
IOM A4
IOM A5
1
2
3
0 1
2
L WF WF WI WI n
3
B
0
B
IOM A3
1
2
B B
3
B
Director A
Side A mgmt. module
IOM = I/O module

F
= Front-end SAN port
B
= Back-end SAN port
3
n
L
WF
WI
n
3
n
I/O module carrier
= Local COM port

= WAN COM port for Fibre Channel
= WAN COM port for IP
= not currently used
VPLX-000343
Figure 81 VS1 engine
Note: The WAN COM ports on IOMs A4 and B4 are used if the inter cluster connections are
over Fibre Channel, and the WAN COM ports on IOMs A5 and B5 are used if the inter
cluster connections are over IP.
VS1 IP addresses and component IDs

The IP addresses of the VPLEX hardware components are determined by:
The internal management network (A or B)
The Cluster IP Seed
The Enclosure ID (which matches the engine number)
Figure 82 shows the IP addresses in a cluster with a Cluster IP Seed of 1.

Figure 83 shows the IP addresses in a cluster with a Cluster IP Seed of 2.
Cluster IP Seed is the same as the Cluster ID:
130
For VPLEX Local - Cluster ID is always 1.
For VPLEX Metro and Geo - Cluster ID for the first cluster that is set up is 1, and the
second cluster is 2.
VS1 Hardware
VS1 component IP addresses (cluster-1)

Cluster IP Seed = 1
Management network A addresses
Management network B addresses
Engine 4:
Director 4B
Director 4A
128.221.253.42
128.221.253.41
Engine 4:
Director 4B
Director 4A
128.221.252.42
128.221.252.41
Engine 3:
Director 3B
Director 3A
128.221.253.40
128.221.253.39
Engine 3:
Director 3B
Director 3A
128.221.252.40
128.221.252.39
FC switch B 128.221.253.34
Service port
128.221.252.2

Customer-assigned
FC switch A 128.221.252.34
Mgt B port
128.221.253.33
Mgt A port
128.221.252.33
Management server
Engine 2:
Director 2B
Director 2A
128.221.253.38
128.221.253.37
Engine 2:
Director 2B
Director 2A
128.221.252.38
128.221.252.37
Engine 1:
Director 1B
Director 1A
128.221.253.36
128.221.253.35
Engine 1:
Director 1B
Director 1A
128.221.252.36
128.221.252.35
VPLX-000107
Figure 82 IP addresses in cluster-1
VS1 IP addresses and component IDs
131
VS1 Hardware
VS1 component IP addresses (cluster-2)

Cluster IP Seed = 2
Management network B addresses
Management network A addresses
Engine 4:
Director 4B
Director 4A
128.221.253.74
128.221.253.73
Engine 4:
Director 4B
Director 4A
128.221.252.74
128.221.252.73
Engine 3:
Director 3B
Director 3A
128.221.253.72
128.221.253.71
Engine 3:
Director 3B
Director 3A
128.221.252.72
128.221.252.71
FC switch B 128.221.253.66
Service port
128.221.252.2

Customer-assigned
FC switch A 128.221.252.66
Mgt B port
128.221.253.65
Mgt A port
128.221.252.65
Management server
Engine 2:
Director 2B
Director 2A
128.221.253.70
128.221.253.69
Engine 2:
Director 2B
Director 2A
128.221.252.70
128.221.252.69
Engine 1:
Director 1B
Director 1A
128.221.253.68
128.221.253.67
Engine 1:
Director 1B
Director 1A
128.221.252.68
128.221.252.67
VPLX-000108
Figure 83 IP addresses in cluster-2 (VPLEX Metro or Geo)
VS1 Internal cabling

The figures in this section show the various cabling inside a VPLEX cabinet.
All the cables shown in this section except inter-cluster WAN COM cables (VPLEX Metro
and VPLEX Geo only) are installed before the unit ships from EMC.
This section includes the following figures:
132
Cluster size
Cable type
Figure
Quad-engine
Ethernet
Figure 84 on page 134
Serial
Fibre Channel
AC power
VS1 Hardware
Cluster size
Cable type
Figure
Dual-engine
Ethernet
Serial
Fibre Channel
AC power
Ethernet
Serial
Fibre Channel
AC power
Fibre Channel WAN

COM
IP WAN COM
Single-engine
All cluster sizes,

VPLEX Metro or
VPLEX Geo only
133
VS1 Hardware
VS1 cabling - quad-engine cluster

Ethernet cabling
Engine 4
Purple, 71 in.
Green, 48 in.
Purple, 20 in.
Green, 20 in.
Engine 3
Green, 37 in.
Purple, 37 in.
Purple, 20 in.
Green, 37 in.
Green, 20 in.
Purple, 71 in.
Management server
Engine 2
Engine 1
VPLX-000044
Figure 84 Ethernet cabling - VS1 quad-engine cluster
134
VS1 Hardware
Serial cabling
Engine 4
12 in.
12 in.
Engine 3
12 in.
12 in.
UPS B
UPS A
40 in.
40 in.
Engine 2
12 in.
12 in.
Engine1
12 in.
12 in.
VPLX-000065
Figure 85 Serial cabling - VS1 quad-engine cluster
135
VS1 Hardware
Fibre Channel cabling
Engine 4
Engine 3
79 in.
(all 16 cables)
Engine 2
Engine 1
VPLX-000055
Figure 86 Fibre Channel cabling - VS1 quad-engine cluster
Note: All 16 Fibre Channel cables are light blue. However, the cables connected to Fibre
Channel switch A have blue labels, and the cables connected to switch B have orange
labels.
136
VS1 Hardware
AC power cabling
ON
I
ON
I
O
OFF
O
OFF
Engine 4
SPS 4
ON
I
ON
I
O
OFF
O
OFF
Engine 3
ON
I
ON
I
O
OFF
O
OFF
SPS 3

UPS B

UPS A
Management server
Engine 2
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
SPS 2
O
OFF
O
OFF
ON
I
ON
I
Engine 1
SPS 1
Figure 87 AC power cabling - VS1 quad-engine cluster
137
VS1 Hardware
VS1 cabling - dual-engine cluster

Ethernet cabling
Green, 20 in.
Green, 37 in.
Purple, 71 in.
Management server
Purple, 20 in.
Purple, 71 in.
Green, 48 in.
Engine 2
Engine 1
VPLX-000043
Figure 88 Ethernet cabling - VS1 dual-engine cluster
138
VS1 Hardware
Serial cabling
UPS B
UPS A
40 in.
40 in.
Engine 2
12 in.
12 in.
Engine1
12 in.
12 in.
VPLX-000067
Figure 89 Serial cabling - VS1 dual-engine cluster
139
VS1 Hardware
Fibre-channel cabling
79 in. (all 16 cables)
Eight cables for a quad-engine configuration are included for
ease of upgrading, and are tied to the cabinet sidewalls
Engine 2
Engine 1
VPLX-000057
Figure 90 Fibre Channel cabling- VS1 dual-engine cluster
Note: All 16 Fibre Channel cables are light blue. However, the cables connected to Fibre
Channel switch A have blue labels, and the cables connected to switch B have orange
labels.
140
VS1 Hardware
AC power cabling

UPS B

UPS A
Management server
I
Engine 2
I
O
I
I
O
SPS 2
I
O
I
O
Engine 1
SPS 1
VPLX-000042
Figure 91 AC power cabling - VS1 dual-engine cluster
141
VS1 Hardware
VS1 cabling - single-engine cluster
Green, 37 in.
Purple, 71 in.
Management server
Engine 1
VPLX-000052
Figure 92 Ethernet cabling - VS1 single-engine cluster
Engine 1
12 in.
12 in.
VPLX-000069
Figure 93 Serial cabling - VS1 single-engine cluster
Engine 1
39 in.
(2 cables)
VPLX-000063
Figure 94 Fibre Channel cabling - VS1 single-engine cluster
Note: Both Fibre Channel cables are light blue. However, the A side cable has a blue
label, and the B side cable has an orange label.
142
VS1 Hardware
Management server
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
O
OFF
O
OFF
ON
I
ON
I
Engine 1
SPS
VPLX-000041
Figure 95 AC power cabling - VS1 single-engine cluster
WAN COM cabling - VPLEX Metro and Geo

Figure 96 and Figure 97 show the WAN COM connection options for VS1 hardware.
Cluster 1 (same connections from each engine in cluster)
B4-FC02
B4-FC03
A4-FC02
B4-FC02
A4-FC03
Intercluster
COM SAN
switch 1A
Intercluster
COM SAN
switch 1B
Cluster 2 (same connections from each engine in cluster)
ISL 1
ISL 2
Intercluster
COM SAN
switch 2A
B4-FC03
A4-FC02
A4-FC03
NOTE: ISL is
inter-switch link
Intercluster
COM SAN
switch 2B
VPLX-000317
Figure 96 Fibre Channel WAN COM connections - VS1
143
VS1 Hardware
Cluster 1
(same connections from each engine in cluster)
B5-GE00
B5-GE01
A5-GE00
A5-GE01
Cluster 2
(same connections from each engine in cluster)
IP
subnet A
B5-GE00
B5-GE01
A5-GE00
A5-GE01
IP
subnet B
VPLX-000368
Figure 97 IP WAN COM connections - VS1
144
GLOSSARY
This glossary contains terms related to VPLEX federated storage systems. Many of these
terms are used in the manuals.
A
AccessAnywhere
The breakthrough technology that enables VPLEX clusters to provide access to information
between clusters that are separated by distance.
active/active
A cluster with no primary or standby servers, because all servers can run applications and
interchangeably act as backup for one another.
Active Directory
A directory service included in most Windows Server operating systems. AD authenticates

and authorizes users and computers in a network of Windows domain type.
active mirror
active/passive
array
asynchronous
A copy of data that is part of a local or remote mirroring service.

A powered component that is ready to operate upon the failure of a primary component.
A collection of disk drives where user data and parity data may be stored. Devices can
consist of some or all of the drives within an array.
Describes objects or events that are not coordinated in time. A process operates
independently of other processes, being initiated and left for another task before being
acknowledged.
For example, a host writes data to the blades and then begins other work while the data is
transferred to a local disk asynchronously across the WAN.
B
bandwidth
backend port
bias
bit
block
block size
The range of transmission frequencies a network can accommodate, expressed as the

difference between the highest and lowest frequencies of a transmission cycle. High
bandwidth allows fast or high volume transmissions.
VPLEX director port connected to storage arrays (acts as an initiator).
When a cluster has the bias for a given DR1, it continues to service I/O to volumes on that
cluster if connectivity to the remote cluster is lost (due to cluster partition or cluster
failure). The bias for a specific volume is determined by the detach rules for the volume,
the detach rules for the consistency group (if the volume is a member of a consistency
group) and VPLEX Witness (if VPLEX Witness is deployed).
A unit of information that has a binary digit value of either 0 or 1.
The smallest amount of data that can be transferred following SCSI standards, which is
traditionally 512 bytes. Virtual volumes are presented to users as a contiguous lists of
blocks.
The actual size of a block on a device.
145
Glossary
Bookmark
A label applied to a snapshot so that the snapshot can be explicitly called (identified)
during recovery processes (during image access).
Bookmarks are created through the CLI or GUI and can be created manually, by the user, or
automatically, by the system. Bookmarks created automatically can be created at
pre-defined intervals or in response to specific system events. Parallel bookmarks are
bookmarks that are created simultaneously across multiple consistency groups.
byte
Memory space used to store eight bits of data.
C
cache
cache coherency
cluster
cluster ID
Managing the cache so that data is not lost, corrupted, or overwritten. With multiple
processors, data blocks may have several copies, one in the main memory and one in
each of the cache memories. Cache coherency propagates the blocks of multiple users
throughout the system in a timely fashion, ensuring that the data blocks do not have
inconsistent versions in the different processors caches.
Two or more VPLEX directors forming a single fault-tolerant cluster, deployed as one to four
engines.
The identifier for each cluster in a multi-cluster deployment. The ID is assigned during
installation.
cluster deployment ID
A numerical cluster identifier, unique within a VPLEX cluster. By default, VPLEX clusters
have a cluster deployment ID of 1. For multi-cluster deployments, all but one cluster must
be reconfigured to have different cluster deployment IDs.
cluster IP seed
The VPLEX IP seed is used to generate the IP addresses used by the internal components
of the VPLEX. For more information about components and their IP addresses, refer to EMC
VPLEX Installation and Setup Guide. Cluster ID is used by the virtualization software (inter
director messaging, cluster identification).
clustering
Using two or more computers to function together as a single entity. Benefits include fault
tolerance and load balancing, which increases reliability and up time.
COM
command line interface

(CLI)
consistency group
146
Temporary storage for recent writes and recently accessed data. Disk data is read through
the cache so that subsequent read references are found in the cache.
The intra-cluster communication (Fibre Channel). The communication used for cache
coherency and replication traffic.
An interface that supports the use of typed commands to execute specific tasks.
A VPLEX structure that groups together virtual volumes and applies the same detach and
failover rules to all member volumes. Consistency groups ensures the common
application of a set of properties to the entire group. Create consistency groups for sets of
volumes that require the same I/O behavior in the event of a link failure. There are two
types of consistency groups:
Glossary
continuity of operations
(COOP)
controller
Synchronous Consistency Groups - Use write-through (synchronous) cache mode to

write data to the underlying storage before an acknowledgment is sent to the host.
This is dependent on the latency between clusters and the application's tolerance of
the latency.
Asynchronous Consistency Groups - Use write-back (asynchronous) cache mode to

write protect data by mirroring it to the memory of another director in the cluster. Data
is destaged asynchronously to the back-end storage arrays. Writes are acknowledged
once the data has been committed to disk in write order.
The goal of establishing policies and procedures to be used during an emergency,

including the ability to process, store, and transmit data before and after.
A device that controls the transfer of data to and from a computer and a peripheral device.
D
data sharing
The ability to share access to the same data with multiple servers regardless of time and
location.
detach rule
Predefined rules that determine which cluster continues I/O when connectivity between
clusters is lost. A cluster loses connectivity to its peer cluster due to cluster partition or
cluster failure.
Detach rules are applied at two levels; to individual volumes, and to consistency groups. If
a volume is a member of a consistency group, the group detach rule overrides the rule set
for the individual volumes. Note that all detach rules may be overridden by VPLEX Witness,
if VPLEX Witness is deployed.
device
director
dirty data
disaster recovery (DR)
discovered array
A combination of one or more extents to which you add specific RAID properties. Local
devices use storage from only one cluster. In VPLEX Metro and Geo configurations,
distributed devices use storage from both clusters.
A CPU module that runs GeoSynchrony, the core VPLEX software. There are two directors (A
and B) in each engine, and each has dedicated resources and is capable of functioning
independently.
The write-specific data stored in the cache memory that is yet to be written to disk.
The ability to restart system operations after an error, preventing data loss.
An array that is connected to the SAN and discovered by VPLEX.
disk cache
A section of RAM that provides cache between the disk and the CPU. RAMs access time is
significantly faster than disk access time. Therefore, a disk-caching program enables the
computer to operate faster by placing recently accessed data in the disk cache.
Distributed consistency
groups
The RecoverPoint consistency group is divided into four segments. Each segment runs on
one primary RPA and one to three secondary RPAs.
Distributed consistency groups enable a much higher throughput and IOPS rate,
regardless of the amount of data being replicated.
distributed device
A RAID 1 device whose mirrors are in different VPLEX clusters.
147
Glossary
distributed file system

(DFS)
distributed RAID1 device
(DR1)
Supports the sharing of files and resources in the form of persistent storage over a
network.
Distributed devices have physical volumes at both clusters in a VPLEX Metro or VPLEX Geo
configuration for simultaneous active/active and read/write access using
AccessAnywhere
E
engine
Consists of two directors, management modules, and redundant power. Unit of scale for
VPLEX configurations. Single = 1 engine, dual = 2 engines, Quad = 4 engines per cluster.
Ethernet
A Local Area Network (LAN) protocol. Ethernet uses a bus topology, meaning all devices
are connected to a central cable, and supports data transfer rates of between 10 megabits
per second and 10 gigabits per second. For example, 100 Base-T supports data transfer
rates of 100 Mb/s.
event
extent
A log message that results from a significant action initiated by a user or the system.
All or a portion (range of blocks) of a storage volume.
F
failover
Automatically switching to a redundant or standby device, system, or data path upon the
failure or abnormal termination of the currently active device, system, or data path.
fault domain
A set of components that share a single point of failure. For VPLEX, the concept that every
component of a highly available system is separated, so that if a fault occurs in one
domain, it will not result in failure in other domains to which it is connected.
fault tolerance
Fibre Channel (FC)
Ability of a system to keep working in the event of hardware or software failure, usually
achieved by duplicating key system components.
A protocol for transmitting data between computer devices. Longer distance requires the
use of optical fiber. However, FC also works using coaxial cable and ordinary telephone
twisted pair media. Fibre channel offers point-to-point, switched, and loop interfaces.
Used within a SAN to carry SCSI traffic.
Fibre Channel over IP

(FCIP)
Combines Fibre Channel and Internet protocol features to connect SANs in geographically
distributed systems.
field replaceable unit

(FRU)
A unit or component of a system that can be replaced on site as opposed to returning the
system to the manufacturer for repair.
firmware
front end port
Software that is loaded on and runs from the flash ROM on the VPLEX directors.
VPLEX director port connected to host initiators (acts as a target).
G
geographically
distributed system
148
A system that is physically distributed across two or more geographically separated sites.
The degree of distribution can vary widely, from different locations on a campus or in a city
to different continents.
Glossary
gigabit (Gb or Gbit)

gigabit Ethernet
gigabyte (GB)
global file system (GFS)
1,073,741,824 (2^30) bits. Often rounded to 10^9.

The version of Ethernet that supports data transfer rates of 1 gigabit per second.
1,073,741,824 (2^30) bytes. Often rounded to 10^9.
A shared-storage cluster or distributed file system.
H
hold provisioning
An attribute of a registered array that allows you to set the array as unavailable for further
provisioning of new storage.
host bus adapter (HBA)
An I/O adapter that manages the transfer of information between the host computers bus
and memory system. The adapter performs many low-level interface functions
automatically or with minimal processor involvement to minimize the impact on the host
processors performance.
I
input/output (I/O)
internet Fibre Channel
protocol (iFCP)
intranet
internet small computer

system interface (iSCSI)
Any operation, program, or device that transfers data to or from a computer.

Connects Fibre Channel storage devices to SANs or the Internet in geographically
distributed systems using TCP.
A network operating like the World Wide Web but with access restricted to a limited group
of authorized users.
A protocol that allows commands to travel through IP networks, which carries data from
storage units to servers anywhere in a computer network.
J
Journal volumes
Volumes that contain data waiting to be distributed to target replica volumes and copies
of the data previously distributed to the target volumes. Journal volumes allow convenient
rollback to any point in time, enabling instantaneous recovery for application
environments.
K
kilobit (Kb)
kilobyte (KB)
1,024 (2^10) bits. Often rounded to 10^3.

1,024 (2^10) bytes. Often rounded to 10^3.
L
latency
LDAP
load balancing
Amount of time required to fulfill an I/O request.

Lightweight Directory Access Protocol, an application protocol that accesses and
maintains distributed directory information services over an IP network.
Distributing the processing and communications activity evenly across a system or
network so that no single device is overwhelmed. Load balancing is especially important
when the number of I/O requests issued is unpredictable.
149
Glossary
local area network (LAN)
local device
logical unit number (LUN)
A group of computers and associated devices that share a common communications line
and typically share the resources of a single processor or server within a small geographic
area.
A combination of one or more extents to which you add specific RAID properties. Local
devices use storage from only one cluster.
Virtual storage to which a given server with a physical connection to the underlying
storage device may be granted or denied access. LUNs are used to identify SCSI devices,
such as external hard drives that are connected to a computer. Each device is assigned a
LUN number which serves as the device's unique address.
M
megabit (Mb)
megabyte (MB)
metadata
metavolume
MetroPoint consistency
group (Metro group)
1,048,576 (2^20) bits. Often rounded to 10^6.

1,048,576 (2^20) bytes. Often rounded to 10^6.
Information about data, such as data quality, content, and condition.
A storage volume used by the system that contains the metadata for all the virtual
volumes managed by the system. There is one metadata storage volume per cluster.
A consistency group that is protecting a DR1 volume in a MetroPoint topology.
Metro-Plex
Two VPLEX Metro clusters connected within Metro (synchronous) distances, approximately
60 miles or 100 kilometers.
mirroring
The writing of data to two or more disks simultaneously. If one of the disk drives fails, the
system can instantly switch to one of the other disks without losing data or service. RAID 1
provides mirroring.
mirroring services
miss
move data across

profiles
Mirroring features provided through a storage service profile.

An operation where the cache is searched but does not contain the data, so the data
instead must be accessed from disk.
This is a new menu option under Mobility Central.
N
namespace
network
network architecture
150
A set of names recognized by a file system in which all names are unique.
System of computers, terminals, and databases connected by communication lines.
Design of a network, including hardware, software, method of connection, and the
protocol used.
network-attached
storage (NAS)
Storage elements connected directly to a network.
network partition
When one site loses contact or communication with another site.
Glossary
Non-distributed
consistency groups
Transfer data through one primary RPA that is designated by the user during group
creation. The policies applied by the consistency group can be modified at any time.
In the event of RPA failure, groups that transfer data through the failed RPA will move to
other RPAs in the cluster.
O
Open LDAP
Open source implementation of the Lightweight Directory Access Protocol (LDAP).
P
parity checking
partition
Production journal
volumes
Production volumes
Checking for errors in binary data. Depending on whether the byte has an even or odd
number of bits, an extra 0 or 1 bit, called a parity bit, is added to each byte in a
transmission. The sender and receiver agree on odd parity, even parity, or no parity. If they
agree on even parity, a parity bit is added that makes each byte even. If they agree on odd
parity, a parity bit is added that makes each byte odd. If the data is transmitted incorrectly,
the change in parity will reveal the error.
A subdivision of a physical or virtual disk, which is a logical entity only visible to the end
user and not to any of the devices.
Volumes that hold system delta marking information.
Volumes that are written to by the host applications. Writes to production volumes are
split such that they are sent to both the normally designated volumes and RPAs
simultaneously.
Each production volume must be exactly the same size as the replica volume to which it
replicates.
point-in-time (PIT)
See the description for Snapshot/PIT.
R
RAID
The use of two or more storage volumes to provide better performance, error recovery, and
fault tolerance.
RAID 0
A performance orientated striped or dispersed data mapping technique. Uniformly sized

blocks of storage are assigned in regular sequence to all of the arrays disks. Provides high
I/O performance at low inherent cost. No additional disks are required. The advantages of
RAID 0 are a very simple design and an ease of implementation.
RAID 1
Also called mirroring, this has been used longer than any other form of RAID. It remains
popular because of simplicity and a high level of data availability. A mirrored array
consists of two or more disks. Each disk in a mirrored array holds an identical image of the
user data. RAID 1 has no striping. Read performance is improved since either disk can be
read at the same time. Write performance is lower than single disk storage. Writes must be
performed on all disks, or mirrors, in the RAID 1. RAID 1 provides very good data reliability
for read-intensive applications.
RAID leg
A copy of data, called a mirror, that is located at a user's current location.
151
Glossary
rebuild
The process of reconstructing data onto a spare or replacement drive after a drive failure.
Data is reconstructed from the data on the surviving disks, assuming mirroring has been
employed.
RecoverPoint Appliance
(RPA)
Hardware that manages all aspects of data protection for a storage group, including
capturing changes, maintaining the images in the journal volumes, and performing image
recovery.
RecoverPoint cluster
RecoverPoint
consistency groups
All connected RecoverPoint Appliances on both sides of the replication.

A logical entity consisting of a collection of replication sets grouped together to ensure
write order consistency across all the primary volumes of the replication sets.
RecoverPoint consistency groups are used to configure protection policies and set RPO
and RTO policies. Consistency group policies determine behavior during failover and
recovery. An operation on a RecoverPoint consistency group applies to all of the
replication sets within the consistency group, and their associated production, replica,
and journal volumes.
RecoverPoint consistency groups monitor their member volumes to ensure consistency
and write-order fidelity. If two data sets are dependent on one another (a database and a
database log), they should be part of the same RecoverPoint consistency group.
There are three types of RecoverPoint consistency groups:
RecoverPoint site
RecoverPoint volumes
Non-distributed consistency groups
Distributed consistency groups
MetroPoint consistency groups
All RecoverPoint entities that are on one side of the replication.

The volumes used for RecoverPoint Replication.
The following types of volumes are required in all RecoverPoint configurations:
Repository volumes
Production volumes
Replica volumes
Journal volumes
Recovery Point Objective
See RPO on page 153.
Recovery Time Objective
See RTO on page 153.
redundancy
The duplication of hardware and software components. In a redundant system, if a

component fails then a redundant component takes over, allowing operations to continue
without interruption.
registered array
An array that is registered with VPLEX. Registration is required to make the array available
for services-based provisioning. Registration includes connecting to and creating
awareness of the arrays intelligent features. Only VMAX and VNX arrays can be registered.
reliability
152
The ability of a system to recover lost data.
Glossary
Remote Direct Memory

Access (RDMA)
Allows computers within a network to exchange data using their main memories and
without using the processor, cache, or operating system of either computer.
replication set
When RecoverPoint is deployed, a production source volume and one or more replica
volumes to which it replicates.
Replica journal volumes
Volumes that hold:
Snapshots that are either waiting to be replicated or already distributed to the replica
Metadata for each image
Bookmarks
Each replica journal holds as many snapshots as its capacity allows.

After distribution, the oldest snapshot is discarded to make room for the newest
snapshot. The number of snapshots in the journal depends on the size of the snapshots
and the capacity of the volumes.
replica volumes
Volumes to which production volumes replicate. In prior releases, the replica volume must
be exactly the same size as its production volume. In RecoverPoint (RP) 4.0 and
GeoSynchrony release 5.2, RecoverPoint supports a feature called Fake Size, where the
replica volume size can be higher than the production volume.
repository volume
A volume dedicated to RecoverPoint for each RPA cluster. The repository volume serves all
RPAs of the particular RPA cluster and the splitter associated with that cluster. The
repository volume stores configuration information about the RPAs and RecoverPoint
consistency groups. There is one repository volume per RPA cluster.
restore source
This operation restores the source consistency group from data on the copy target.
RPO
Recovery Point Objective. The time interval between the point of failure of a storage
system and the expected point in the past at which the storage system is capable of
recovering customer data. Informally, RPO is maximum amount of data loss that can be
tolerated by the application after a failure. The value of the RPO is highly dependent upon
the recovery technique used. For example, RPO for backups is typically days, for
asynchronous replication minutes, and for mirroring or synchronous replication seconds
or instantaneous.
RTO
Recovery Time Objective. Not to be confused with RPO, RTO is the time duration within
which a storage solution is expected to recover from failure and begin servicing
application requests. Informally, RTO is the longest tolerable application outage due to a
failure of a storage system. RTO is a function of the storage technology. It may measure in
hours for backup systems, minutes for a remote replication, and seconds (or less) for a
mirroring.
S
scalability
simple network
management protocol
(SNMP)
Ability to easily change a system in size or configuration to suit changing conditions, to

grow with your needs.
Monitors systems and devices in a network.
153
Glossary
site ID
The identifier for each cluster in a multi-cluster VPLEX. By default, in a non-geographically

distributed system the ID is 0. In a geographically distributed system, the ID of the first
cluster is 1, the next is 2, and so on, each number identifying a physically separate cluster.
These identifiers are assigned during installation.
SLES
SUSE Linux Enterprise Server is a Linux distribution supplied by SUSE and targeted at the
business market.
small computer system

interface (SCSI)
A set of evolving ANSI standard electronic interfaces that allow personal computers to
communicate faster and more flexibly than previous interfaces with peripheral hardware
such as disk drives, tape drives, CD-ROM drives, printers, and scanners.
Snapshot/PIT
A point-in-time copy that preserves the state of data at an instant in time, by storing only
those blocks that are different from an already existing full copy of the data.
Snapshots are also referred to as point-in-time (PIT). Snapshots stored at a replica journal
represent the data that has changed on the production storage since the closing of the
previous snapshot.
splitter
storage area network
(SAN)
storage view
storage volume
stripe depth
EMC RecoverPoint write-splitting technology built into GeoSynchrony starting in 5.1.

A high-speed special purpose network or subnetwork that interconnects different kinds of
data storage devices with associated data servers on behalf of a larger network of users.
A combination of registered initiators (hosts), front-end ports, and virtual volumes, used
to control a hosts access to storage.
A Logical Unit Number (LUN) or unit of storage presented by the back end array.
The number of blocks of data stored contiguously on each storage volume in a RAID 0
device.
striping
A technique for spreading data over multiple disk drives. Disk striping can speed up
operations that retrieve data from disk storage. Data is divided into units and distributed
across the available disks. RAID 0 provides disk striping.
synchronous
Describes objects or events that are coordinated in time. A process is initiated and must
be completed before another task is allowed to begin.
For example, in banking, two withdrawals from a checking account that started at the
same time must not overlap; therefore, they are processed synchronously.
throughput
1. The number of bits, characters, or blocks passing through a data communication

system or portion of that system.
2. The maximum capacity of a communications channel or system.
3. A measure of the amount of work performed by a system over a period of time. For
example, the number of I/Os per day.
tool command language

(TCL)
154
A scripting language often used for rapid prototypes and scripted applications.
Glossary
transfer size
The size of the region in cache used to service data migration. The area is globally locked,
read at the source, and written at the target. Transfer size can be as small as 40 K, as large
as 128 M, and must be a multiple of 4 K. The default value is 128 K.
A larger transfer size results in higher performance for the migration, but may negatively
impact front-end I/O. This is especially true for VPLEX Metro migrations. Set a large
transfer-size for migrations when the priority is data protection or migration performance.
A smaller transfer size results in lower performance for the migration, but creates less
impact on front-end I/O and response times for hosts. Set a smaller transfer-size for
migrations when the priority is front-end storage response time.
transmission control
protocol/Internet
protocol (TCP/IP)
The basic communication language or protocol used for traffic on a private network and
the Internet.
U
uninterruptible power
supply (UPS)
A power supply that includes a battery to maintain power in the event of a power failure.
universal unique
identifier (UUID)
A 64-bit number used to uniquely identify each VPLEX director. This number is based on
the hardware serial number assigned to each director.
V
virtualization
A layer of abstraction that is implemented in software that servers use to divide available
physical storage into storage volumes or virtual volumes.
virtual volume
Unit of storage presented by the VPLEX front end ports to hosts. A virtual volume looks like
a contiguous volume, but can be distributed over two or more storage volumes.
W
wide area network (WAN)
world wide name (WWN)
A geographically dispersed telecommunications network. This term distinguishes a

broader telecommunication structure from a local area network (LAN).
A specific Fibre Channel Name Identifier that is unique worldwide and represented by a
64-bit unsigned binary value.
write-back mode
A caching technique where the completion of a write request is communicated as soon as

the data is in cache, with writes to disk occurring at different times. Write-back is faster
than write-through, but risks a system failure before the data is safely written to disk.
write-through mode
A caching technique in which the completion of a write request is communicated only after
data is written to disk. This is almost equivalent to non-cached systems, but with data
protection.
155
Glossary
156
INDEX
A
addresses of hardware components 130
C
cabling, internal
VPLEX VS1 dual-engine configuration 138
VPLEX VS1 quad-engine configuration 134
VPLEX VS1 single-engine configuration 142
consistency groups
asynchronous 58
synchronous 56
global visibility 57
local visibility 56
I
IP addresses 130
M
MetroPoint 106
Four-site topology 115
Three-site topology 108
Two-site topology 107
MetroPoint groups 120
Converting to a MetroPoint group 121
Creating a MetroPoint group 121
MetroPoint upgrades
Upgrading to MetroPoint 119
R
RecoverPoint
configurations 99
VPLEX Local and Local Protection 100
VPLEX Local and Local/Remote Protection 100
VPLEX Metro and RecoverPoint Local 101
VPLEX Metro and RecoverPoint with Local and Remote
Replication 102
V
VPLEX Witness
deploment 23
Index

VPLEX 5.4 Product Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VPLEX 5.4 Product Guide

Uploaded by

Copyright:

Available Formats

EMC VPLEX

EMC VPLEX Product Guide

Integrity and Resiliency

VPLEX Use Cases

EMC VPLEX GeoSynchrony Product Guide

EMC VPLEX GeoSynchrony Product Guide

VPLEX active-active .....................................................................................................

EMC VPLEX GeoSynchrony Product Guide

VPLEX features and benefits........................................................................................

EMC VPLEX GeoSynchrony Product Guide

EMC VPLEX GeoSynchrony Product Guide

EMC VPLEX Release Notes for GeoSynchrony Releases

EMC VPLEX Product Guide

EMC VPLEX Site Preparation Guide

EMC VPLEX Hardware Installation Guide

EMC VPLEX Configuration Worksheet

EMC VPLEX Configuration Guide

EMC VPLEX Security Configuration Guide

EMC VPLEX CLI Reference Guide

EMC VPLEX Administration Guide

VPLEX Management Console Help

EMC VPLEX Element Manager API Guide

EMC VPLEX Open-Source Licenses

EMC VPLEX GPL3 Open-Source Licenses

EMC Regulatory Statement for EMC VPLEX

Procedures provided through the Generator

EMC Host Connectivity Guides

EMC VPLEX Product Guide

Conventions used in this document

Used in running (nonprocedural) text for:

Used in running (nonprocedural) text for:

Used in all text (including procedures) for:

Used in procedures for:

Square brackets enclose optional values

Vertical bar indicates alternate selections - the bar means or

Braces indicate content that you must specify (that is, x or y or z)

Ellipses indicate nonessential information omitted from the example

EMC VPLEX Product Guide

Where to get help

EMC VPLEX Product Guide

EMC VPLEX Product Guide

Collaborate over distance.

Figure 1 VPLEX active-active

VPLEX addresses three primary IT needs:

Availability: VPLEX creates high-availability storage infrastructure across these same

VPLEX offers the following unique innovations and advantages:

VPLEX distributed/federated virtual storage enables new models of application and

EMC VPLEX Product Guide

In Metro and Geo configurations, VPLEX AccessAnywhere provides cache-consistent

Provide continuous availability and workload mobility.

VPLEX product family

EMC VPLEX Local

EMC VPLEX Metro

EMC VPLEX Geo

Within a data center

Figure 2 VPLEX family: Local, Metro, and Geo

VPLEX Local consists of a single cluster. VPLEX Local:

Federates EMC and non-EMC storage arrays.

VPLEX product family

Increases protection and high availability for critical applications.

Deploy VPLEX Local within a single data center.

Deploy VPLEX Metro within a data center for:

Additional virtual storage capabilities beyond that of a VPLEX Local.

Deploy VPLEX Metro between data centers for: