Docu61175 VPLEX 5.5 Product Guide

EMC VPLEX
Version 5.5
Product Guide
P/N 302-002-366
REV 02
Copyright 2015-2016 EMC Corporation. All rights reserved. Published in the USA.
Published September 2016
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.
EMC, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other
countries. 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 EMC Online Support (https://support.emc.com).
EMC Corporation
Hopkinton, Massachusetts 01748-9103
1-508-435-1000 In North America 1-866-464-7381
www.EMC.com
2 EMC VPLEX 5.5 Product Guide

CONTENTS
Figures 7
Tables 9
Preface 11
Chapter 1 Introducing VPLEX 15

VPLEX overview............................................................................................. 16
VPLEX product family.....................................................................................17
VPLEX Local......................................................................................18
VPLEX Metro.....................................................................................18
Grow your VPLEX without disruption.................................................19
Mobility.........................................................................................................19
Availability.................................................................................................... 21
Collaboration................................................................................................ 21
Architecture highlights.................................................................................. 22
Features and benefits....................................................................................23
VPLEX Witness.............................................................................................. 24
High availability compared to disaster recovery................................25
Non-disruptive upgrade (NDU).......................................................................26
Storage, application, and host upgrades.......................................... 26
Increase engine count...................................................................... 26
Software upgrades........................................................................... 26
Simple support matrix......................................................................26
New features in this release.......................................................................... 27
Chapter 2 VS2 Hardware 29

The VPLEX cluster.......................................................................................... 30
Management server......................................................................... 30
Fibre Channel switches.................................................................... 30
1, 2, or 4 VPLEX engines...................................................................31
VS2 single-engine cluster.................................................................33
VS2 dual-engine cluster................................................................... 34
VS2 quad-engine cluster.................................................................. 35
The VPLEX engine and directors.....................................................................35
Front-end and back-end connectivity................................................36
WAN connectivity............................................................................. 36
Redundant I/O paths........................................................................37
VPLEX power supplies................................................................................... 37
AC power connection....................................................................... 37
Standby power supplies...................................................................38
Uninterruptible power supplies........................................................ 38
Power and environmental monitoring............................................................ 38
Hardware failure management and best practices......................................... 38
Storage array failures....................................................................... 38
Fibre Channel port failures............................................................... 39
I/O module failures.......................................................................... 40
EMC VPLEX 5.5 Product Guide 3

CONTENTS
Director failure................................................................................. 41
Intra-cluster IP management network failure.................................... 41
Intra-cluster Fibre Channel switch failure..........................................41
Inter-cluster WAN links..................................................................... 42
Power supply failures....................................................................... 42
SPS/UPS failures..............................................................................42
VPLEX Witness failure.......................................................................42
VPLEX management server failure.................................................... 43
Component IP addresses...............................................................................43
IP addresses cluster-1......................................................................44
IP addresses - cluster-2.................................................................... 45
Chapter 3 VPLEX Software 47

GeoSynchrony............................................................................................... 48
Management interfaces.................................................................................49
Web-based GUI................................................................................ 49
VPLEX CLI......................................................................................... 50
VPLEX Element Manager API............................................................. 50
SNMP...............................................................................................50
LDAP/AD.......................................................................................... 51
Call-home........................................................................................ 51
Provisioning with VPLEX................................................................................ 51
Integrated storage............................................................................51
Other storage................................................................................... 52
Distributed storage.......................................................................... 53
Thick and thin storage volumes........................................................53
About extents...................................................................................53
About devices.................................................................................. 54
About virtual volumes...................................................................... 57
Logging volumes.............................................................................. 58
Back-end load balancing..................................................................59
Consistency groups....................................................................................... 59
Synchronous consistency groups..................................................... 59
Detach rules.....................................................................................61
Chapter 4 Integrity and Resiliency 63

About VPLEX resilience and integrity............................................................. 64
Cluster.......................................................................................................... 64
Quorum............................................................................................65
Path redundancy........................................................................................... 66
Different ports..................................................................................66
Different directors............................................................................ 66
Different engines..............................................................................68
Site distribution............................................................................... 68
High Availability with VPLEX Witness............................................................. 69
Witness installation considerations................................................. 70
Failures in Metro systems: without VPLEX Witness............................71
Failures in Metro systems: with VPLEX Witness.................................72
Higher availability............................................................................ 74
ALUA............................................................................................................. 74
Additional resilience features........................................................................75
Metadata volumes........................................................................... 75
Logging volumes.............................................................................. 75
Global cache.................................................................................... 76

CONTENTS
Performance monitoring and security features...............................................76

Performance monitoring .................................................................. 77
Security features.............................................................................. 79
Chapter 5 VPLEX Use Cases 81

Technology refresh........................................................................................ 82
Mobility.........................................................................................................83
Mobility with the VPLEX migration wizard......................................... 84
How data mobility works.................................................................. 85
Collaboration................................................................................................ 86
Collaboration using local consistency groups...................................86
VPLEX Metro HA.............................................................................................87
Metro HA (without cross-connect).................................................... 87
Metro HA with cross-connect............................................................ 90
Redundancy with RecoverPoint......................................................................94
RecoverPoint Appliances..................................................................94
RecoverPoint configurations.............................................................96
RecoverPoint/VPLEX configurations..................................................97
VPLEX Local and Local Protection..................................................... 97
VPLEX Local and Local/Remote Protection........................................98
VPLEX Metro and RecoverPoint local at one site................................99
VPLEX Metro and RecoverPoint with both Local and Remote
Replication.......................................................................................99
Shared VPLEX splitter.....................................................................100
Shared RecoverPoint RPA cluster....................................................101
RecoverPoint replication with CLARiiON..........................................101
vCenter Site Recovery Manager support for VPLEX.......................... 102
MetroPoint.................................................................................................. 103
MetroPoint 2-site topology............................................................. 104
MetroPoint three-site topology....................................................... 104
MetroPoint four-site topology......................................................... 110
Upgrading to MetroPoint................................................................ 114
MetroPoint groups......................................................................... 114
Failover.......................................................................................... 116
Active source failover..................................................................... 116
Production failover to the remote copy........................................... 117
Production failover to the local copy...............................................118
Recover production........................................................................ 118
Appendix A VS1 Hardware 121

VS1 cluster configurations.......................................................................... 122
VS1 single-engine cluster...............................................................122
VS1 dual-engine cluster................................................................. 123
VS1 quad-engine cluster................................................................ 124
VS1 engine..................................................................................................124
VS1 IP addresses and component IDs......................................................... 125
VS1 component IP addresses (cluster-1)........................................ 126
VS1 component IP addresses (cluster-2)........................................ 127
VS1 Internal cabling.................................................................................... 127
VS1 cabling - single-engine cluster.................................................128
VS1 cabling - dual-engine cluster................................................... 131
VS1 cabling - quad-engine cluster.................................................. 135
WAN COM cabling - VPLEX Metro.................................................... 139

CONTENTS
Glossary 141
Index 149

FIGURES
1 VPLEX active-active........................................................................................................16
2 VPLEX family: Local and Metro....................................................................................... 18
3 Move data without disrupting service............................................................................ 20
4 Data mobility with VPLEX Local and Metro......................................................................20
5 High availability infrastructure example......................................................................... 21
6 Distributed data collaboration....................................................................................... 22
7 Architecture highlights...................................................................................................23
8 How VPLEX Witness is deployed.....................................................................................25
9 Management server - rear view...................................................................................... 30
10 Fibre Channel switch - rear view..................................................................................... 31
11 VS2: Single-engine cluster............................................................................................. 33
12 VS2: Dual-engine cluster............................................................................................... 34
13 VS2: Quad-engine cluster.............................................................................................. 35
14 Engine, rear view........................................................................................................... 36
15 VPLEX cluster independent power zones........................................................................37
16 Local mirrored volumes................................................................................................. 39
17 Component IP addresses in cluster-1.............................................................................44
18 Component IP addresses in cluster-2.............................................................................45
19 Claim storage using the GUI...........................................................................................49
20 Extents.......................................................................................................................... 54
21 Devices..........................................................................................................................55
22 Distributed devices........................................................................................................56
23 Virtual volumes............................................................................................................. 58
24 Local consistency groups with local visibility................................................................. 60
25 Local consistency group with global visibility.................................................................61
26 Path redundancy: different ports....................................................................................66
27 Path redundancy: different directors.............................................................................. 67
28 Recommended fabric assignments for front-end and back-end ports............................. 68
29 Path redundancy: different engines............................................................................... 68
30 Path redundancy: different sites.................................................................................... 69
31 High level VPLEX Witness architecture........................................................................... 70
32 Failure scenarios in VPLEX Metro configurations without VPLEX Witness........................ 71
33 VPLEX Witness and VPLEX cluster connection failures.................................................... 73
34 Unisphere Performance Monitoring Dashboard..............................................................77
35 Unisphere Performance Monitoring Dashboard - select information to view................... 78
36 Unisphere Performance Monitoring Dashboard - sample chart....................................... 78
37 Traditional view of storage arrays...................................................................................82
38 VPLEX technology refresh.............................................................................................. 83
39 Moving data with VPLEX.................................................................................................84
40 Mobility Central GUI.......................................................................................................84
41 Collaborate over distance with AccessAnywhere............................................................ 86
42 VPLEX Metro HA............................................................................................................. 88
43 VPLEX Metro HA (no cross-connect) cluster failure......................................................... 89
44 VPLEX Metro HA (no cross-connect) inter-cluster link failure...........................................89
45 VPLEX Metro HA with cross-connect............................................................................... 90
46 VPLEX Metro HA with cross-connect - host failure...........................................................91
47 VPLEX Metro HA with cross-connect - cluster failure....................................................... 91
48 VPLEX Metro HA with cross-connect - storage array failure..............................................92
49 VPLEX Metro HA with cross-connect - VPLEX Witness failure........................................... 92
50 VPLEX Metro HA with cross-connect - inter-cluster link failure........................................ 93
51 RecoverPoint architecture.............................................................................................. 94

FIGURES
52 RecoverPoint configurations.......................................................................................... 96
53 VPLEX Local and RecoverPoint....................................................................................... 98
54 VPLEX Local and RecoverPoint Remote - remote site is independent VPLEX cluster.........98
55 VPLEX Local and RecoverPoint remote - remote site is array-based splitter..................... 99
56 VPLEX Metro and RecoverPoint local replication.............................................................99
57 VPLEX Metro and RecoverPoint local and remote replication- local site is located at one
cluster of the VPLEX..................................................................................................... 100
58 VPLEX Metro and RecoverPoint local and remote replication- remote site is array-based
splitter.........................................................................................................................100
59 Shared VPLEX splitter.................................................................................................. 101
60 Shared RecoverPoint RPA cluster................................................................................. 101
61 Replication with VPLEX Local and CLARiiON................................................................. 102
62 Replication with VPLEX Metro and CLARiiON................................................................ 102
63 Support for Site Recovery Manager.............................................................................. 103
64 MetroPoint 2-site topology...........................................................................................104
65 MetroPoint three-site topology.....................................................................................105
66 RecoverPoint Local Replication for VPLEX Distributed Volumes at Site A and Site B and
RecoverPoint Remote Replication at Site C................................................................... 106
67 Bi-directional replication for volumes in different consistency groups and local volumes
....................................................................................................................................107
68 Active Source Site A Failure..........................................................................................108
69 Remote Site C Failure...................................................................................................109
70 MetroPoint four-site configuration............................................................................... 111
71 MetroPoint four-site configuration for a single consistency group................................ 112
72 Site A and Site B failure showing failover to Site C....................................................... 113
73 During failover, Site C and Site D become the production sites.................................... 113
74 MetroPoint - two local copies.......................................................................................116
75 Source failover............................................................................................................ 117
76 Production failover to the remote copy.........................................................................118
77 Recover production......................................................................................................119
78 VS1 single-engine cluster............................................................................................ 122
79 VS1 dual-engine cluster...............................................................................................123
80 VS1 quad-engine cluster..............................................................................................124
81 VS1 engine.................................................................................................................. 124
82 IP addresses in cluster-1..............................................................................................126
83 IP addresses in cluster-2 (VPLEX Metro)....................................................................... 127
84 Ethernet cabling - VS1 single-engine cluster................................................................ 128
85 Serial cabling - VS1 single-engine cluster.................................................................... 129
86 Fibre Channel cabling - VS1 single-engine cluster........................................................ 129
87 AC power cabling - VS1 single-engine cluster............................................................... 130
88 Ethernet cabling - VS1 dual engine cluster................................................................... 131
89 Serial cabling - VS1 dual-engine cluster....................................................................... 132
90 Fibre Channel cabling - VS1 dual-engine cluster...........................................................133
91 AC power cabling - VS1 dual-engine cluster................................................................. 134
92 Ethernet cabling - VS1 quad-engine cluster..................................................................135
93 Serial cabling - VS1 quad-engine cluster......................................................................136
94 Fibre Channel cabling - VS1 quad-engine cluster..........................................................137
95 AC power cabling - VS1 quad-engine cluster................................................................ 138
96 Fibre Channel WAN COM connections - VS1................................................................. 139
97 IP WAN COM connections - VS1................................................................................... 139

TABLES
1 Typographical conventions............................................................................................ 12
2 VPLEX features and benefits.......................................................................................... 23
3 Hardware components...................................................................................................31
4 GeoSynchrony AccessAnywhere features....................................................................... 48
5 Types of data mobility operations.................................................................................. 85
6 How VPLEX Metro HA recovers from failure.....................................................................93
7 Cabling within a VPLEX cabinet.................................................................................... 127

TABLES

Preface
As part of an effort to improve its product lines, EMC periodically releases revisions of its
software and hardware. Therefore, some functions described in this document might not
be supported by all versions of the software or hardware currently in use. The product
release notes provide the most up-to-date information on product features.
Contact your EMC technical support professional if a product does not function properly
or does not function as described in this document.
Note
This document was accurate at publication time. Go to EMC Online Support (https://
support.emc.com) to ensure that you are using the latest version of this document.
Purpose
This document is part of the VPLEX documentation set, and describes the VPLEX Restful
API.
Audience
This guide is intended for use by customers and service providers who use the Restful API
to configure and manage a storage environment.
Related documents (available on EMC Online Support) include:
l EMC VPLEX Release Notes for GeoSynchrony Releases
l EMC VPLEX Product Guide
l EMC VPLEX Site Preparation Guide
l EMC VPLEX Configuration Worksheet
l EMC VPLEX Configuration Guide
l EMC VPLEX Security Configuration Guide
l EMC VPLEX CLI Reference Guide
l EMC VPLEX Administration Guide
l Unisphere for VPLEX Help
l EMC VPLEX Element Manager API Guide
l EMC VPLEX Open-Source Licenses
l EMC VPLEX GPL3 Open-Source Licenses
l Procedures provided through the SolVe Desktop Generator
l EMC Host Connectivity Guides
l EMC VPLEX Hardware Installation Guide
l Various best practices technical notes available on EMC Online Support
Special notice conventions used in this document
EMC uses the following conventions for special notices:

Preface
DANGER
Indicates a hazardous situation which, if not avoided, will result in death or serious
injury.
WARNING
Indicates a hazardous situation which, if not avoided, could result in death or serious
injury.
CAUTION
Indicates a hazardous situation which, if not avoided, could result in minor or moderate
injury.
NOTICE
Addresses practices not related to personal injury.
Note
Presents information that is important, but not hazard-related.
Typographical conventions
EMC uses the following type style conventions in this document:
Table 1 Typographical conventions
Bold Used for names of interface elements, such as names of windows,

dialog boxes, buttons, fields, tab names, key names, and menu paths
(what the user specifically selects or clicks)
Italic Used for full titles of publications referenced in text

Monospace Used for:
l System code
l System output, such as an error message or script
l Pathnames, filenames, prompts, and syntax
l Commands and options
Monospace italic Used for variables

Monospace bold Used for user input
[] Square brackets enclose optional values
| Vertical bar indicates alternate selections - the bar means or
{} Braces enclose content that the user must specify, such as x or y or z
... Ellipses indicate nonessential information omitted from the example
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

Preface
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

Preface

CHAPTER 1
Introducing VPLEX
This chapter introduces the EMC VPLEX product family.
l VPLEX overview..................................................................................................... 16
l VPLEX product family.............................................................................................17
l Mobility.................................................................................................................19
l Availability............................................................................................................ 21
l Collaboration........................................................................................................ 21
l Architecture highlights.......................................................................................... 22
l Features and benefits............................................................................................23
l VPLEX Witness...................................................................................................... 24
l Non-disruptive upgrade (NDU)...............................................................................26
l New features in this release.................................................................................. 27
Introducing VPLEX 15
Introducing VPLEX
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:
l 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. There is no need to reconfigure the host.
l 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.
l 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.
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:

l Mobility:VPLEX moves applications and data between different storage installations:
n Within the same data center or across a campus (VPLEX Local)
n Within a geographical region (VPLEX Metro)
l Availability: VPLEX creates high-availability storage infrastructure across these same
varied geographies with unmatched resiliency.
l Collaboration: VPLEX provides efficient real-time data collaboration over distance for
Big Data applications.
VPLEX offers the following unique innovations and advantages:

Introducing VPLEX
l 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.
l 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.
l Every engine in a VPLEX cluster can access all the virtual volumes presented by
VPLEX.
Every engine in a VPLEX cluster can access all the physical storage connected to
VPLEX.
l In a Metro configuration, 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:
l Provide continuous availability and workload mobility.
l Replace your tedious data movement and technology refresh processes with VPLEXs
patented simple, frictionless two-way data exchange between locations.
l Create an active-active configuration for the active use of resources at both sites.
l Provide instant access to data between data centers. VPLEX allows simple,
frictionless two-way data exchange between locations.
l Combine VPLEX with virtual servers to enable private and hybrid cloud computing.
VPLEX product family

The VPLEX product family includes:
l VPLEX Local
l VPLEX Metro
VPLEX product family 17

Introducing VPLEX
Figure 2 VPLEX family: Local and Metro
EMC VPLEX Local EMC VPLEX Metro
Within a data center AccessAnywhere at

synchronous
distances
VPLX-000389
VPLEX Local
VPLEX Local consists of a single cluster. VPLEX Local:
l Federates EMC and non-EMC storage arrays.
Federation allows transparent data mobility between arrays for simple, fast data
movement and technology refreshes.
l Standardizes LUN presentation and management using simple tools to provision and
allocate virtualized storage devices.
l Improves storage utilization using pooling and capacity aggregation across multiple
arrays.
l 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 5ms Round Trip Time (RTT). VPLEX Metro:
l 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.
l Mirrors your data to a second site, with full access at near local speeds.
Deploy VPLEX Metro within a data center for:
l Additional virtual storage capabilities beyond that of a VPLEX Local.
l 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

Introducing VPLEX
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:
l Mobility: Redistribute application workloads between the two data centers.
l Availability: Applications must keep running in the presence of data center failures.
l Collaboration: Applications in one data center need to access data in the other data
center.
l Distribution: One data center lacks space, power, or cooling.
Combine VPLEX Metro virtual storage and virtual servers to:
l Transparently move virtual machines and storage across synchronous distances.
l Improve utilization and availability across heterogeneous arrays and multiple sites.
Distance between clusters is limited by physical distance, by host and by application
requirements.
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:
l Add engines to a VPLEX cluster.
l Upgrade engine hardware from VS1 to VS2.
l Convert a VPLEX Local to a VPLEX Metro.
l Upgrade GeoSynchrony.
l 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.
Grow your VPLEX without disruption 19

Introducing VPLEX
Figure 3 Move data without disrupting service
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.
Figure 4 Data mobility with VPLEX Local and Metro
VPLEX Local VPLEX Metro

Cluster A Cluster B
MOBILITY
OBILI ACCESS ANYWHERE
Move data without impacting users Move data, VMs, and applications over distance
Heterogeneous nondisruptive Active-Active data centers avoid disasters,
technology refreshes simplify migrations and workload balancing
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:
l Move extents from a hot storage volume shared by other busy extents.
l Defragment a storage volume to create more contiguous free space.

Introducing VPLEX
l 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:
l Migrate data between dissimilar arrays.
l Relocate a hot volume to a faster array.
l 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.
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. The
following figure shows a VPLEX Metro configuration where storage has become
unavailable at one of the cluster sites.
Figure 5 High availability infrastructure example
Cluster A Cluster B
ACCESS ANYWHERE
X
Maintain availability and non-stop access by mirroring across locations.
Eliminate storage operatios nfrom failover.
Because VPLEX GeoSynchrony AccessAnywhere mirrors all data, applications continue

without disruption using the back-end storage at the unaffected site.
Collaboration
Collaboration increases utilization of passive data recovery assets and provides
simultaneous access to data.
Availability 21
Introducing VPLEX
Figure 6 Distributed data collaboration
ACCESS ANYWHERE
Enable concurrent read/write access to data across locations
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:
l One, two, or four VPLEX engines.
Each engine contains two directors.
Dual-engine or quad-engine clusters contain:
n One pair of Fibre Channel switches for communication between directors.
n Two Uninterruptible Power Sources (UPS) for battery power backup of the Fibre
Channel switches and the management server.
l A management server.
The management server has a public Ethernet port, which provides cluster
management services when connected to the customer network.

Introducing VPLEX
Figure 7 Architecture highlights

HP, Oracle (Sun),
Microsoft, Linux, IBM Oracle, VMware, Microsoft
Brocade,
Cisco
VPLEX
Brocade,
Cisco
HP, Oracle (Sun), Hitachi, HP (3PAR), IBM, EMC
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.
Features and benefits

The following table summarizes VPLEX features and benefits.
Table 2 VPLEX features and benefits
Features Benefits
Mobility l Migration: Move data and applications without impact on users.
l Virtual Storage federation: Achieve transparent mobility and access within
a data center and between data centers.
l Scale-out cluster architecture: Start small and grow larger with predictable
service levels.
Features and benefits 23

Introducing VPLEX
Table 2 VPLEX features and benefits (continued)
Availability l Resiliency: Mirror across arrays within a single data center or between data
centers without host impact. This increases availability for critical
applications.
l Distributed cache coherency: Automate sharing, balancing, and failover of
I/O across the cluster and between clusters whenever possible.
l 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:

l Presents storage volumes from back-end arrays to VPLEX engines.
l Federates the storage volumes into hierarchies of VPLEX virtual volumes with user-
defined configuration and protection levels.
l Presents virtual volumes to production hosts in the SAN through the VPLEX front-end.
l For VPLEX Metro, 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.
CAUTION
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.
VPLEX Witness connects to both VPLEX clusters over the management IP network as
illustrated in the following figure:

Introducing VPLEX
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.
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.
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:
l Data center components operate in active/active mode (or active/passive with
automatic failover).
l 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.
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.
High availability compared to disaster recovery 25

Introducing VPLEX
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 VPLEX Metro 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:
l Ports
l Paths
l Directors
l 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.
Note
You must upgrade the VPLEX management server software before upgrading
GeoSynchrony. Management server upgrades are non-disruptive.
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

Introducing VPLEX
New features in this release

Release 6.0 includes the following new feature:
l Back-end path policy to improve throughput and latency
The path policy is set to the least number of outstanding commands to limit the
amount of degraded paths or slow I/Os. This policy throttles slower paths by
redirecting I/O commands to paths where the commands are being processed faster,
preferably paths that have less than five outstanding commands.
l Configuration limits
The health-check command now displays the configuration limits of your
configuration.
l Log splitting
This feature allows you to access the logs, as soon as they are created. Placement of
logs in tar file have been changed.
The smsLogs folder contains:
n smsDump tar files
n recoverpoint logs
n cluster witness logs
The directorLogs folder contains:
n Connectivity logs
n debug tower dump logs
n directorDump logs (the logs that were previously collected by appDump)
n The CPU and the memory information for all the directors
The configuration folder contains:
n Tar file containing the config dump of both the clusters
n Tar file generated by SyrCollect
l Log collection for a specific period
Collect-Diagnostics functionality has been extended to allow the user to collect only
the SMS and director logs that are relevant to a certain time period.
l Stuck IO detection
In Release 5.5, GeoSynchrony detects a stuck I/O and sends a firmware event
through Call Home if Call Home is enabled. The default time for an I/O to be declared
stuck is 10 minutes. This is used to ensure the VPLEX can distinguish between a
stuck IO and one that may be processed slowly on a highly loaded system. This value
can be tuned. To have this value tuned to your configuration, contact EMC support.
l REST API for performance statistics
A new REST enabled CLI command (monitor get-stats) has been added to allow you to
gather VPLEX statistics using the REST interface.
n Supports both perpetual monitors and virtual-volume monitors.
n By default, output is user-readable.
n Has an option for parser friendly output as well
The perpetual monitor stats are column based. The output of each monitor is a map
with stats name as the key.
New features in this release 27

Introducing VPLEX
Virtual Volume Monitor stats are row based. The CLI output of Virtual Volume Monitor
will be based on virtual volume name. The output of each monitor is a map with stats
name as the key.
l Quick vault and restore on power failure
VPLEX now reduces the amount of data at risk on power failure by starting a vault
immediately on power loss detection. It also reduces data unavailability by restarting
and allowing the VPLEX service on a director to run after the power has been restored
on it.
l Support for LDAPS server certificates
For LDAPS directories, you can now configure LDAPS server certificates for
authentication. These certificates are the files that come from the LDAPS server and
they are stored on VPLEX. These certificates create a trust mechanism between the
two systems.
l Ability to use a security certificate from a certification authority
Starting this release, you can use a security certificate, signed by a certification
authority (CA), with VPLEX. The certificates are applied for both VPN and the web
communication. A common certificate is maintained across the cluster.
l Storage volume latency monitoring
VPLEX monitors the latency for reads and writes that complete to a storage. VPLEX
samples the latency every five minutes by default and it is measured against a set
performance policy for a cluster. Storage volumes are marked degraded if the set
thresholds are exceeded. If auto-mirror isolation is enabled, VPLEX uses it to trigger
isolation on poorly performing RAID-1 mirrors.
l Resynchronization on a leg of RAID 1
The new device repair command allows you to identify and force a resynchronization
on a leg of a simple RAID 1 or a Distributed RAID 1 where one leg has been modified
on the BE storage, not through VPLEX.
l Deprecation of the ls command through the VPLEX REST API
Support for executing the ls command through the VPLEX REST API has been
deprecated. The equivalent functionality for retrieving context contents and attributes
has been provided through the VPLEX GET context URI method, which returns the
data in a structured format that is more efficiently parsed by clients of the REST API.
Ensure that you convert any existing usage of the ls command through the RESTful
API to use the VPLEX GET context URI method to avoid incompatibility. For more
information, refer to the EMC VPLEX Element Manager API Guide.
l VPLEX Cluster Witness support for VMware ESXi 6.0
You can now deploy VPLEX Cluster Witness Server on VMware ESXi 6.0.
l Enhancement to provisioning using VIAS
VPLEX release 5.5 has these enhancements for VIAS:
n VIAS now supports provisioning on VMAX3 and XtremeIO storage arrays. The
supported versions of XtremeIO are 4.0.1, 3.0.3, and 3.0.2.
n VIAS now supports Service Level Objective (SLO) and workload selection on EMC
VMAX3 storage arrays.
n Volumes and storage groups are exposed for provisioning in VIAS.
n If a provisioning job fails in VIAS, the new rollback feature brings the system to the
previous state.
n You can now specify storage groups for EMC VMAX2 arrays.

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.
l The VPLEX cluster.................................................................................................. 30

l The VPLEX engine and directors.............................................................................35
l VPLEX power supplies........................................................................................... 37
l Power and environmental monitoring.................................................................... 38
l Hardware failure management and best practices................................................. 38
l Component IP addresses.......................................................................................43
VS2 Hardware 29
VS2 Hardware
The VPLEX cluster

There are two generations of VS hardware: VS1 and VS2. A VPLEX cluster (either VS1 or
VS2) consists of:
l 1, 2, or 4 VPLEX engines
Each engine contains two directors.
Dual-engine or quad-engine clusters also contain:
n 1 pair of Fibre Channel switches for communication between directors.
n 2 uninterruptible power supplies (UPS) for battery power backup of the Fibre
Channel switches and the management server.
l A management server.
l Ethernet or Fibre Channel cabling and respective switching hardware that connects
the distributed VPLEX hardware components.
l I/O modules provide front-end and back-end connectivity between SANs and to
remote VPLEX clusters in VPLEX Metro configuration.
Note
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.
Management server
Each VPLEX cluster has one management server.
Figure 9 Management server - rear view
You can manage both clusters in a VPLEX Metro configuration from a single management
server.
The management server:
l Coordinates data collection, VPLEX software upgrades, configuration interfaces,

diagnostics, event notifications, and some director-to-director communication.
l 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.

VS2 Hardware
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.
l Figure 11 on page 33 shows a single-engine cluster for VS2.
l Figure 12 on page 34 shows a dual-engine cluster for VS2.
l Figure 13 on page 35 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.
The following table describes the major components of a VPLEX cluster and their
functions.
Table 3 Hardware components
Component Description
Engine Contains two directors, with each director providing front-end and back-
end I/O connections.
Director Contains:
l Five I/O modules (IOMs), as identified in Figure 14 on page 36
l Management module for intra-cluster communication
l Two redundant 400 W power supplies with built-in fans
l CPU
l Solid-state disk (SSD) that contains the GeoSynchrony operating
environment
l RAM
Management server Provides:

l Management interface to a public IP network
l Management interfaces to other VPLEX components in the cluster
l Event logging service
Fibre Channel COM Provides intra-cluster communication support among the directors. This
switches (Dual-engine is separate from the storage I/O.
or quad-engine cluster
only)
1, 2, or 4 VPLEX engines 31
VS2 Hardware
Table 3 Hardware components (continued)
Component Description
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 One SPS assembly (two SPS modules) provides backup power to each
(SPS) 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 One UPS provides battery backup for Fibre Channel switch A and the
Supply (UPS) (Dual- management server, and a second UPS provides battery backup for
engine or quad-engine Fibre Channel switch B. Each UPS module maintains power for two five-
cluster only) minute periods of AC loss while the engine shuts down.

VS2 Hardware
VS2 single-engine cluster

Figure 11 VS2: Single-engine cluster
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
Laptop tray
OFF OFF
O O
Management server
I I
ON ON
OFF OFF
O O
I I
ON ON
OFF OFF
O O
I I
ON ON
Engine 1, Director B Engine 1, Director A
SPS 1B SPS 1A
VPLX-000226
VS2 single-engine cluster 33

VS2 Hardware
VS2 dual-engine cluster

Figure 12 VS2: Dual-engine cluster
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
Laptop tray
Fibre Channel switch B
UPS B
Fibre Channel switch A
UPS A
OFF OFF
O O
I I
Management server
ON ON
Engine 2, Director B OFF

O
I
ON
OFF
O
I
ON
Engine 2, Director A
SPS 2B SPS 2A
OFF OFF
O O
I I
ON ON
SPS 1B SPS 1A
VPLX-000227

VS2 Hardware
VS2 quad-engine cluster

Figure 13 VS2: Quad-engine cluster
Engine 4, Director B ON
I
O
OFF
ON
I
O
OFF
SPS 4B SPS 4A
ON ON
I I
O O
OFF OFF

ON ON
I I
O O
OFF OFF
SPS 3B SPS 3A
Laptop tray
UPS B
UPS A
OFF OFF
O O
I I
Management server
ON ON
Engine 2, Director B OFF

O
I
ON
OFF
O
I
ON
SPS 2B SPS 2A
OFF OFF
O O
I I
ON ON
SPS 1B SPS 1A
VPLX-000228
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.
The following figure shows a VPLEX engine and its two directors: Director A and Director
B.
VS2 quad-engine cluster 35

VS2 Hardware
Figure 14 Engine, rear view
Management module B
Management module A
IOM B3 - Local COM
IOM A3 - Local COM

IOM B2 - WAN COM
IOM A2 - WAN COM

IOM B0 - Front end
IOM A0 - Front end

IOM B1 - Back end
IOM A1 - Back end

IOM B4 - reserved
IOM A4 - reserved
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 10 Gb/s Filler module
Fibre Channel Ethernet (VPLEX Local only)
VPLX-000229
The GeoSynchrony operating system runs on the VPLEX directors, and supports:
l I/O request processing
l Distributed cache management
l Virtual-to-physical translations
l Interaction with storage arrays
Front-end and back-end connectivity

Redundant I/O modules provide connectivity to the front-end and back-end ports:
l Four 8 Gb/s Fibre Channel I/O modules provide front-end connectivity.
l Four 8 Gb/s ports provide back-end connectivity.
l Industry-standard Fibre Channel ports connect to host initiators and storage devices.
WAN connectivity
For a VPLEX Metro configuration, 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).
For Fibre Channel connections, IOMs A2 and B2 contain four Fibre Channel ports.
For IP connections, IOMs A2 and B2 contain two Ethernet ports.

VS2 Hardware
CAUTION
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.
The following figure shows AC power supplied from independent power distribution units
(PDUs):
Figure 15 VPLEX cluster independent power zones
Circuit Customer
breaker PDU 1 Circuit Customer
off (0) breaker PDU 2
Circuit breakers - Numbers
27
off (0)
Circuit breakers - Numbers
28
8
29 9
30 10
PDU 1 ...
11
CB 28 PDU 2 ...
EMC CB 9
cabinet, rear
Labels on
customer
power lines
PDPs
Power Zone
Lower B Lower A
Power Power
PDU# 1 2 PDU#
zone B zone A
Panel# Panel# (black) (gray)
CB#(s) 28 9 CB#(s)
Cabinet serial number
This is a required configuration to assure high availability.
Redundant I/O paths 37

VS2 Hardware
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.
A single standby power supply provides enough power for the attached engine to support
two back-to-back 5-minute losses of power.
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:
l UPS-A provides power to the management server and Fibre Channel switch A.
l 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.
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.

VS2 Hardware
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.
The following figure shows a virtual volume mirrored between two arrays.
Figure 16 Local mirrored volumes
Best practices: local mirrored volumes

l For critical data, mirror data on two or more storage volumes that are located on
separate arrays.
l 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.
Fibre Channel port failures

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:
l 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.
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.
Fibre Channel port failures 39

VS2 Hardware
For maximum availability, each host can have a path to at least one front-end port on
every director.
l Use multipathing software on the host servers to ensure timely response and
continuous I/O in the presence of path failures.
l Ensure that each host has a path to each virtual volume through each fabric.
l Ensure that the fabric zoning provides hosts redundant access to the VPLEX front-end
ports.
Back end:
l 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.
l Ensure that the LUN connects to at least two different back end ports of each director
within a VPLEX cluster.
l 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.
l 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:
l One front-end I/O module and one back-end I/O module,
l 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 39 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 39 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.

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 a Metro configuration, VPLEX clusters are connected by a pair of private local IP
subnets between directors and the management server. The subnets:
l Carry management traffic
l Protect against intra-cluster partitioning
l 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.
Director failure 41
VS2 Hardware
Inter-cluster WAN links

In a VPLEX Metro configuration, the clusters are connected through redundant WAN links
that you provide.
Best practices
When configuring the inter-cluster network:
l Latency must be less than 5 milliseconds (ms) round trip time (RTT) for a VPLEX
Metro.
l 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.
l Switches supporting the WAN links must be configured with a battery backup UPS.
l Have physically independent WAN links for redundancy.
l Every WAN port on every director must be able to connect to a WAN port on every
director in the other cluster.
l Logically isolate the VPLEX Metro traffic from other WAN traffic using VSANs or LSANs.
l Use independent inter switch links (ISLs) for redundancy.
l Deploy VPLEX Witness in an independent failure domain.
Power supply failures

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

VS2 Hardware
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 Witness11.
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.
VPLEX management server failure 43

VS2 Hardware
IP addresses cluster-1
Figure 17 Component IP addresses in cluster-1
Cluster IP Seed = 1
Enclosure IDs = engine numbers
Engine 4: Engine 4:
Director 4B, A side: 128.221.252.42 Director 4A, A side: 128.221.252.41
Director 4B, B side: 128.221.253.42 Director 4A, B side: 128.221.253.41
Engine 3: Engine 3:
FC switch B 128.221.253.34
Service port
Public Ethernet port
128.221.252.2
Customer-assigned
FC switch A 128.221.252.34
Mgt B port Mgt A port

Management server
128.221.253.33 128.221.252.33
Engine 2: Engine 2:
Engine 1: Engine 1:
VPLX-000242

VS2 Hardware
IP addresses - cluster-2
Figure 18 Component IP addresses in 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

Management server
128.221.253.65 128.221.252.65
Engine 2: Engine 2:
Engine 1: Engine 1:
VPLX-000243
IP addresses - cluster-2 45
VS2 Hardware

CHAPTER 3
VPLEX Software
This chapter describes the major components of VPLEX software.
l GeoSynchrony....................................................................................................... 48
l Management interfaces.........................................................................................49
l Provisioning with VPLEX........................................................................................ 51
l Consistency groups............................................................................................... 59
VPLEX Software 47
VPLEX Software
GeoSynchrony
GeoSynchrony is the operating system that runs on the VPLEX directors. GeoSynchrony
runs on both VS1 and VS2 hardware.
GeoSynchrony is:
l Designed for highly available, robust operation in geographically distributed
environments
l Driven by real-time I/O operations
l Intelligent about locality of access
l Designed to provide the global directory that supports AccessAnywhere
The following table summarizes features provided by GeoSynchrony and
AccessAnywhere:
Table 4 GeoSynchrony AccessAnywhere features
Feature Description and considerations

Storage volume LUNs on a back-end array can be imported into an instance of VPLEX and
encapsulation 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.
RAID 1 VPLEX devices can be mirrored within a site.
Considerations: Withstands a device failure within the mirrored pair.

l A device rebuild is a simple copy from the remaining device to the
newly repaired device. Rebuilds are done in incremental fashion,
whenever possible.
l The number of required devices is twice the amount required to store
data (actual storage capacity of a mirrored array is 50%).
l 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.
Considerations: Provides protection from site disasters and supports the

ability to move data between geographically separate locations.
Extents Storage volumes can be broken into extents and devices can be created
from these extents.
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

VPLEX Software
Table 4 GeoSynchrony AccessAnywhere features (continued)
Feature Description and considerations

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 a VPLEX Metro configuration, both clusters can be managed from either management
server.
Inside VPLEX clusters, management traffic traverses a TCP/IP based private management
network.
In a VPLEX Metro configuration, 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.
The following figure shows the screen to claim storage:
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.
Management interfaces 49
VPLEX Software
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:
l Global commands are accessible from all contexts.
l Other commands are arranged in a hierarchical context tree, and can be executed
only from the appropriate location in the context tree.
The following example shows a CLI session that performs the same tasks as shown in
Figure 19 on page 49.
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.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.
SNMP
The VPLEX SNMP agent:
l Supports retrieval of performance related statistics as published in the VPLEX-
MIB.mib.
l Runs on the management server and fetches performance related data from
individual directors using a firmware specific interface.
l Provides SNMP MIB data for directors (local cluster only).
l Runs on Port 161 of the management server and uses the UDP protocol.
l Supports the following SNMP commands:
n SNMP Get

VPLEX Software
n SNMP Get Next

n 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:
l 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.
l 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
Call-home is a leading technology that alerts EMC support personnel of warnings in
VPLEX.
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:
l Integrated storage provisioning (VIASVPLEX Integrated Array Services based
provisioning)
l EZ provisioning
l 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
LDAP/AD 51
VPLEX Software
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.
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:
l Select or create a consistency group for the volumes
l Select the type of volume to create (distributed or local)
l Select mirroring options
l Select or create storage
l 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.

VPLEX Software
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:
l Expand dynamically depending on the amount of data written to them.
l 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.
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.
Distributed storage 53
VPLEX Software
Figure 20 Extents
Virtual Volume
Top-level Device
Devices
Extents
Storage Volumes
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.

VPLEX Software
Figure 21 Devices
Virtual Volume
Top-level Device
Devices
Extents
Storage Volumes
A simple device has only one underlying component - an extent.

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:
l 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.
l 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.
l 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.
About devices 55
VPLEX Software
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.
Distributed devices
Distributed devices have their underlying storage arrays located at both clusters in VPLEX
Metro:
Figure 22 Distributed devices
Site A Site B
Distributed Virtual Volume
Fibre Channel
VPLX-000433
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:
l Increased availability - Both data centers can serve as production workloads while
providing high availability for the other data center.
l Increased asset utilization - Passive data centers can have idle resources.
l 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.

VPLEX Software
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.
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) 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.
About virtual volumes 57

VPLEX Software
Figure 23 Virtual volumes
Virtual Volume
Top-level Device
Devices
Extents
Storage Volumes
If needed, you can expand the capacity of a virtual volume. The expansion method
supported are as follows:
l Storage-volume
l Concatenation
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. VPLEX Local and Metro configurations have round-trip
latencies of 5 ms or less, and use write-through 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.
Logging volumes
Logging volumes keep track of blocks that are written:
l During an inter-cluster link outage.
l When one leg of a distributed device becomes temporarily unreachable (is
unreachable, but not permanently removed from the SAN).

VPLEX Software
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 a VPLEX Metro configuration, 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.
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.
Synchronous consistency groups aggregate local and distributed volumes on VPLEX Local
and VPLEX Metro systems separated by 5ms 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:
l Contain up to 1000 virtual volumes.
l Contain either local or distributed volumes (not a combination of both).
l Contain volumes with either global or local visibility.
l Use write-through caching.
Synchronous consistency groups: visibility

Synchronous consistency groups support either local or distributed volumes.
Local synchronous consistency groups can have the visibility property set to either:
Back-end load balancing 59

VPLEX Software
l Local visibility - The local volumes in the consistency group are visible only to the
local cluster.
l 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.
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.

VPLEX Software
Figure 25 Local consistency group with global visibility
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.
l device-level detach rules determine which cluster continues for an individual device.
l 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:
l no-automatic-winner - The consistency group does not select a winning cluster.
l 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.
l 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.
Detach rules 61
VPLEX Software
WARNING
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.

CHAPTER 4
Integrity and Resiliency
This chapter describes how VPLEXs high availability and redundancy features provide
robust system integrity and resiliency.
l About VPLEX resilience and integrity......................................................................64

l Cluster.................................................................................................................. 64
l Path redundancy................................................................................................... 66
l High Availability with VPLEX Witness..................................................................... 69
l ALUA..................................................................................................................... 74
l Additional resilience features................................................................................75
l Performance monitoring and security features.......................................................76
Integrity and Resiliency 63

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 provides 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:
l Unplanned and planned storage outages
l SAN outages
l VPLEX component failures
l VPLEX cluster failures
l Data center outages
To achieve high availability, you must create redundant host connections and supply
hosts with multi path drivers.
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 multi-pathing 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.
All hardware resources (CPU cycles, I/O ports, and cache memory) are pooled.
A two-cluster configuration (Metro) offers true high availability. Operations continue and
data remains online even if an entire site fails. It also provides a high availability solution
with zero recovery point objective (RPO).
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:
l 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.
l Maintaining quorum - An operational VPLEX cluster seeing failures will continue
operating in the following scenarios:
n 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.
n 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.
l Quorum loss - An operational VPLEX cluster seeing failures stops operating in the
following scenarios:
n If more than half of the operational directors with quorum fail.
n 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).
n In a dual or quad engine cluster, if all of the directors loose contact with each
other.
Quorum 65
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.
When a director port fails, the host multi-pathing software seamlessly fails over to
another path through a different port, as shown in the following figure.
Figure 26 Path redundancy: different ports
Director A1 Director B1
Engine 1
Virtual Volume
VPLX-000376
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.
In the following figure, Director A has failed, but Director B services the host I/O that was
previously being serviced by Director A.

Figure 27 Path redundancy: different directors
Director A1 Director B1
Engine 1
Virtual Volume
VPLX-000392
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:
l Present the virtual volumes through each director so that all directors except one can
fail without causing data loss or unavailability.
l Connect all directors to all storage.
l Configure paths through both an director A and a director B to ensure continuous I/O
during non-disruptive upgrade of VPLEX.
l 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.
l Connect hosts to both fabrics and use multi-pathing software to ensure continuous
data access during failures.
l Connect I/O modules to redundant fabrics.
Different directors 67
Figure 28 Recommended fabric assignments for front-end and back-end ports
FAB-B FAB-A
VPLX-000432
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 the following figure.
Figure 29 Path redundancy: different engines
Director A1 Director B1 Director A1 Director B1
Engine 1 Engine 2
Virtual Volume
VPLX-000393
In a VPLEX Metro configuration, 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, 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.
In the following figure, despite a site failure at Data Center B, I/O continues without
disruption in Data Center A.

Figure 30 Path redundancy: different sites
Data center A Data center B
Cluster file system
Director A1 Director B1 Director A1 Director B1
Engine 1 Engine 1
Virtual Volume Virtual Volume
VPLX-000394
Install the optional VPLEX Witness on a server in a separate failure domain to provide
further fault tolerance in VPLEX Metro configurations.
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
l 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.
l The VPLEX Witness server supports round trip time latency of 1 second over the
management IP network.
In a Metro configuration, 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.
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.
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 with VPLEX Witness 69

l High availability for applications in a VPLEX Metro configuration leveraging

synchronous consistency groups (no single points of storage failure).
l Fully automatic failure handling of synchronous consistency groups in a VPLEX Metro
configuration (provided these consistency groups are configured with a specific
preference).
l Better resource utilization.
The following figure 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.
Figure 31 High level VPLEX Witness architecture
Failure Domain #3
VPLEX Witness
Cluster 1 IP management Cluster 2

Network
Inter-cluster
Network A
Inter-cluster
Network B
Failure Domain #1 Failure Domain #2

VPLX-000474
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.
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:
l If the two clusters are deployed on different floors of the same data center, deploy the
VPLEX Witness Server VM on a separate floor.
l 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:
l As a virtual machine running on a customers VMware ESX server.
l In a failure domain separate from either of the VPLEX clusters, and
l 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:
l winner cluster-name delay seconds
l 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 the following figure , 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.
Three common types of failures that illustrate how VPLEX responds without Cluster
Witness are described below:.
Figure 32 Failure scenarios in VPLEX Metro configurations without VPLEX Witness
Scenario 1 Scenario 2 Scenario 3
Cluster 1 Cluster 2 Cluster 1 Cluster 2 Cluster 1 Cluster 2
VPLX-000434
Scenario 1 - Inter-cluster link outage

Both of the dual links between the clusters have an outage. Also known as a cluster
partition.
l The preferred cluster (cluster-1) continues I/O
l 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
l 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.
Failures in Metro systems: without VPLEX Witness 71

Scenario 3 - Cluster-1 (the preferred cluster) fails

l 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.
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.
Witness and network failures

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:

Figure 33 VPLEX Witness and VPLEX cluster connection failures
Local Cluster Isolation Remote Cluster Isolation
VPLEX VPLEX
Witness Witness
s
I/
I/
ue
nd
O
O
tin
e
Co
Su
sp
n
n
sp
Su
Co
tin
e nd
O
O
ue
I/
I/
s
s
Cluster 1 Cluster 2 Cluster 1 Cluster 2
Inter Cluster Partition Loss of Contact with VPLEX Witness
VPLEX VPLEX
Witness Witness
s
I/
nd
I/
ue
O
O
in
Co
sp
Co
nt
nt
Su
n
Co
tin
in
O
O
ue
ue
I/
I/
s
s
Cluster 1 Cluster 2 Cluster 1 Cluster 2
VPLX-000435
Local Cluster Isolation

The preferred cluster loses contact with both the remote cluster and the VPLEX Witness.
l The preferred cluster is unable to receive guidance from VPLEX Witness and suspends
I/O.
l VPLEX Witness guides the non-preferred cluster to continue I/O.
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.
l The preferred cluster continues I/O as it is still in contact with the VPLEX Witness.
l 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.
l I/O continues on the preferred cluster.
l If the preferred cluster cannot proceed because it has not fully synchronized, the
cluster suspends I/O.
l 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.
l There is no change in I/O.
l The cluster(s) that lost connectivity with VPLEX Witness sends a call-home
notification.
l If either cluster fails or if the inter-cluster link fails when VPLEX Witness is down,
VPLEX experiences data unavailability in all surviving clusters.
Failures in Metro systems: with VPLEX Witness 73

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:
l Cluster-1 is isolated
l VPLEX Witness tells cluster-2 to continue I/O
l 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.
Higher availability
Combine VPLEX Witness with VMware and cross cluster connection to create even higher
availability.
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:
l 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.
l 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:
l 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.
l 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.
l 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.
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:
l The local configuration for the cluster.
l 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
For best resilience:
l Allocate storage volumes of 78Gb for the metadata volume.
l Configure the metadata volume for each cluster with multiple back-end storage
volumes provided by different storage arrays of the same type.
l Use the data protection capabilities provided by these storage arrays, such as RAID 1
to ensure the integrity of the system's metadata.
l Create backup copies of the metadata whenever configuration changes are made to
the system.
l Perform regular backups of the metadata volumes on storage arrays that are separate
from the arrays used for the metadata volume.
Logging volumes
Logging volumes keep track of blocks written:
l During an inter-cluster link outage.
Additional resilience features 75

l 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.
CAUTION
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:
l Network outages or cluster failures
l 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 configuration:
l Place logging volumes on the fastest storage available.
l Stripe logging volumes across several disks to accommodate the high level of I/O
that occurs during and after outages.
l 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.
Synchronous systems (write-through cache mode) leverage the back-end array by writing
user data to the array. An acknowledgment for the written data must be received before
the write is acknowledged back to the host.
Protection from power failure

A system vaults immediately when power loss is detected. The VPLEX service on the
director is restarted immediately after vaulting but does not service IOs until cluster-wide
power restores to normal. If power does not restore within 5 minutes, the VPLEX system
shuts down.
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.
You can view and assess the VPLEX performance using these methods:
l Unisphere Performance Monitoring Dashboard, which shows real-time performance
monitoring data for up to one hour of history.
l Performance statistics collection using the CLI and the API. These methods let you
collect and view the statistics, and export them to an external application for
analysis.
l Monitoring with Simple Networking Management Protocol (SNMP).
Unisphere Performance Monitoring Dashboard

The Unisphere Performance Monitoring Dashboard supports these general categories of
performance monitoring:
l Current load monitoring that 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.
l Long term load monitoring that collects data for capacity planning and load
balancing.
l Object base monitoring that collects data for the virtual volume.
The Unisphere Performance Monitoring Dashboard is a customized view into the
performance of the VPLEX system:
Figure 34 Unisphere Performance Monitoring Dashboard
You decide which aspects of the system's performance to view and compare:
Performance monitoring 77
Figure 35 Unisphere Performance Monitoring Dashboard - select information to view
Performance information is displayed as a set of charts. For example, the following figure
shows front-end throughput for a selected director:
Figure 36 Unisphere Performance Monitoring Dashboard - sample chart
For additional information about the statistics available through the Performance
Monitoring Dashboard, see the EMC Unisphere for VPLEX online help available in the
VPLEX GUI.
Performance monitoring using the CLI

The CLI supports current load monitoring, long term load monitoring, object base
monitoring, and troubleshooting monitoring. 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:
l Create a performance monitor to collect statistics for CompareAndWrite (CAW)
operations, miscompares, and latency for the specified virtual volume on
director-1-1-B.
l Add a file sink to send output to the specified directory on the management server.
The EMC VPLEX Administration Guide describes the procedure for monitoring VPLEX
performance using the CLI.

Monitoring with SNMP

You can monitor the VPLEX performance using SNMP, a protocol designed to manage and
monitor network-attached devices.
VPLEX has an SNMP agent that runs on the management server. It uses a firmware-
specific interface to fetch the performance data from individual directors. The VPLEX
SNMP agent retrieves the performance-related statistics that are published in the
VPLEX-MIB.mib database. It provides the SNMP MIB data only for the local cluster. To
use SNMP monitoring, configure and start the SNMP agent on the VPLEX cluster.
You can aslo configure an SNMP trap for the VPLEX call-home events. After you do that,
when a call-home event is generated and sent from VPLEX, a corresponding SNMP trap is
sent from all configured SNMP trap services that have been started on the VPLEX cluster.
The version of SNMP supported in VPLEX is SNMPv2. The EMC VPLEX Administration Guide
describes the procedures for configuring the SNMP agent and configuring SNMP trap in
call-home.
Monitoring with VPLEX Element Manager API

VPLEX Element Manager API allows you to collect, display, and export the VPLEX
performance-related statistics. It supports a set of Python scripts and VPLEX CLI
commands.
Using the API, you can collect the performance statistics related to the directors in a
cluster. These statistics include the performance of the storage volumes, virtual volumes,
and ports used by the directors. The EMC VPLEX Element Manager API Guide describes the
commands that are used to collect performance statistics using the VPLEX Element
Manager API.
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:
l SSH Version 2 to access the management server shell
l Customizable password policies
l LDAP authentication using LDAP v3 protocol
l IPv6 support
l HTTPS to access the VPLEX GUI
l IPSec VPN inter-cluster link in a VPLEX Metro configuration
l IPSec VPN to connect each cluster of a VPLEX Metro to the VPLEX Witness server
l SCP to copy files
l Support for separate networks for all VPLEX cluster communication
l Defined user accounts and roles
l Defined port usage for cluster communication over management server
l Certificate Authority (CA) certificate (default expiration 5 years)
l Two host certificates (default expiration 2 years)
Security features 79
l Third host certificate for optional VPLEX Witness

l External directory server support
CAUTION
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.

CHAPTER 5
VPLEX Use Cases
This section describes examples of VPLEX configurations.
l Technology refresh................................................................................................ 82
l Mobility.................................................................................................................83
l Collaboration........................................................................................................ 86
l VPLEX Metro HA.....................................................................................................87
l Redundancy with RecoverPoint..............................................................................94
l MetroPoint.......................................................................................................... 103
VPLEX Use Cases 81

VPLEX Use Cases
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.
The following figure 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.
Figure 37 Traditional view of storage arrays
Array 1
Server
No Federation
Server
Array 2
VPLX-000381
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.
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 the following figure, 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:
l Adds Array C into the VPLEX cluster.
l Assigns a target extent from the new array to each extent from the old array.
l 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:

VPLEX Use Cases
Figure 38 VPLEX technology refresh
Virtual Volume
Array A Array B Array C
VPLX-000380
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.
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 83
VPLEX Use Cases
Figure 39 Moving data with VPLEX
MOBILITY
Cluster A Cluster B
ACCESS ANYWHERE
Move and relocate VMs, application,

and data over distance
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).
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:
l Move data from a hot storage device.
l Move applications from one storage device to another.
l Move operating system files from one storage device to another.
l Consolidate data or database instances.
l Move database instances.
l 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 do not 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.
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:
l Display and select the extents (for extent mobility) or devices (for device mobility) to
move.

VPLEX Use Cases
l Display and select candidate storage volumes.

l 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 5 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.
l 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.
l Use batched device migrations to migrate to dissimilar arrays and to migrate devices
between clusters in a VPLEX Metro.
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.
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:
l The target extent/device must be the same size or larger than the source extent/
device.
l The target device cannot be in use (no virtual volumes created on it).
l 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.
How data mobility works 85

VPLEX Use Cases
The thinness of a thinly provisioned storage volume is retained through a mobility

operation.
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.
With VPLEXs Federated AccessAnywhere, the data remains consistent, online, and
always available.
Figure 41 Collaborate over distance with AccessAnywhere
ACCESS ANYWHERE
Enable concurrent read/write access to data across locations
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 #unique_90/
unique_90_Connect_42_GUID-059DD4B7-9386-45DF-9443-2D0FE1C1D14B on page 59.

VPLEX Use Cases
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.
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:
l VPLEX Metro HA can be deployed in places where the clusters are separated by 5 ms
latency RTT or less.
l 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.
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:
l Significantly reduce the Recovery Time Objective (RTO). In some cases, RTO can be
eliminated.
l Ride through any single component failure (including the failure of an entire storage
array) without disruption.
l When VMware Distributed Resource Scheduler (DRS) is enabled, distribute workload
spikes between data centers, alleviating the need to purchase more storage.
l Eliminate the requirement to stretch the Fiber Channel fabric between sites. You can
maintain fabric isolation between the two sites.
VPLEX Metro HA 87
VPLEX Use Cases
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.
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:
l VPLEX Witness guides the surviving cluster to continue.
l VMware at the surviving cluster is unaffected.
l 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.

VPLEX Use Cases
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.

l If a virtual machine is located at the preferred cluster, there is no interruption of
service.
l 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.
Figure 44 VPLEX Metro HA (no cross-connect) inter-cluster link failure
If an inter-cluster link outage occurs:

l VPLEX Witness guides the preferred cluster to continue.
Metro HA (without cross-connect) 89

VPLEX Use Cases
l VMware at the preferred cluster is unaffected.

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

VPLEX Use Cases
Figure 46 VPLEX Metro HA with cross-connect - host failure
Cluster failure
If a VPLEX cluster fails:
l VPLEX Witness guides the surviving cluster to continue.
l VMware re-routes I/O to the surviving cluster.
l 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:
l All distributed volumes continue I/O to the surviving leg.
l No disruption to the VPLEX clusters or the virtual machines.
l I/O is disrupted only to local virtual volumes on the VPLEX cluster attached to the
failed array.
Metro HA with cross-connect 91

VPLEX Use Cases
Figure 48 VPLEX Metro HA with cross-connect - storage array failure
VPLEX Witness failure

If VPLEX Witness fails or becomes unreachable (link outage):
l Both VPLEX clusters call home to report that VPLEX Witness is not reachable.
l No disruption to I/O, VPLEX clusters, or the virtual machines.
Figure 49 VPLEX Metro HA with cross-connect - VPLEX Witness failure
WARNING
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:
l VPLEX Witness guides the preferred cluster to continue.

VPLEX Use Cases
l I/O suspends at the non-preferred cluster.

l VMware re-routes I/O to the continuing cluster.
l No disruption to I/O.
Figure 50 VPLEX Metro HA with cross-connect - inter-cluster link failure
The following table summarizes how VPLEX HA with cross-connect manages failures.
Table 6 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 VPLEX Witness detects the failure and enables all volumes on the surviving
(Site 1) cluster.
Inter-cluster link l If the cross-connects use different physical links from those used to
failure connect the VPLEX clusters, applications are unaffected. Every volume
continues to be available in one data center or the other.
l 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 Both clusters call home. As long as both clusters continue to operate and
VPLEX Witness 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.
Metro HA with cross-connect 93

VPLEX Use Cases
Table 6 How VPLEX Metro HA recovers from failure (continued)
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:
l Local volumes, to provide recovery from operational disasters.
l Remote volumes, to provide recovery from site disasters.
l 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.
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.

VPLEX Use Cases
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:

l 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.
l 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.
l 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.
l 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.
Recovery/Failover
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:
l Logged (physical) access - Used for production recovery, failover, testing, and cloning
a replica.
l 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.
l 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).
l 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,
RecoverPoint Appliances 95
VPLEX Use Cases
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.
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.

VPLEX Use Cases
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:
l
l VPLEX Local and local protection

l VPLEX Local and local/remote protection
l VPLEX Metro and RecoverPoint local at one site
l VPLEX Metro and RecoverPoint with both local and remote replications
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.
RecoverPoint/VPLEX configurations 97
VPLEX Use Cases
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.
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:

VPLEX Use Cases
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.
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:
l Written to both VPLEX clusters (as part of normal VPLEX operations).
l 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:
VPLEX Metro and RecoverPoint local at one site 99

VPLEX Use Cases
Figure 57 VPLEX Metro and RecoverPoint local and remote replication- local site is located at one
cluster of the VPLEX.
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.
l 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.
l All RecoverPoint protected volumes must be on the preferred cluster, as designated
by VPLEX consistency group-level detach rules.
l 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.
l Application event aware based rollback is supported on VPLEX Metro distributed/
local virtual volumes for Microsoft SQL, Microsoft Exchange, and Oracle database
applications.
l 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).
l This configuration can simulate a disaster at the VPLEX cluster to test RecoverPoint
disaster recovery features at the remote site.
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.

VPLEX Use Cases
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.
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.
Shared RecoverPoint RPA cluster 101

VPLEX Use Cases
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
vCenter Site Recovery Manager support for VPLEX

With RecoverPoint replication, you can add Site Recovery Manager support to VPLEX.

VPLEX Use Cases
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 configured with RecoverPoint in a VPLEX Metro provides the
MetroPoint topology. 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:
l Full high availability for data access and protection.
l Continuous data protection and disaster recovery.
l Operational recovery at all three sites for redundancy.
l Efficient data transfer between VPLEX Metro sites and to the remote site.
l Load balancing across replication links and bi-directional replication.
l Out of region data protection with asynchronous replication.
l 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.
MetroPoint 103
VPLEX Use Cases
l Full support for all operating systems and clusters normally supported with VPLEX
Metro.
l Support for a large variety of EMC and third-party storage arrays.
MetroPoint 2-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
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.
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 2-site topology
MetroPoint 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.

VPLEX Use Cases
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:
l VPLEX Local
l VPLEX Metro
l VNX
l VNX2
l VMAX
Figure 65 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 three-site topology 105

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

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:
l Any single component failure
l A complete site failure
l A regional failure that affects two sites
l Data unavailability due to user errors
l 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.
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.

VPLEX Use Cases
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.

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:
l VPLEX fracture, inter-cluster link failure
l VPLEX site failure on the RecoverPoint active production copy
l RecoverPoint failure (active source)
l Data corruption
VPLEX fracture, inter-cluster link failure
A fracture occurs when the communication link between two VPLEX Metro sites is down.
When this occurs:
l Replication continues through the VPLEX winner site.
l 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.
l 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.
l The losing site does not receive any I/Os during the site departure and does not
maintain an up-to-date journal.
l A local copy at the losing site will not be updated.

VPLEX Use Cases
l A local copy at the winning site continues to be updated.

Recovery and Restoration procedures
l Restore the VPLEX inter-cluster link.
l Once communication between the two VPLEX sites is restored, VPLEX automatically
resynchronizes both clusters according to the I/Os that occurred during the fracture.
l RecoverPoint replication continues during the synchronizing process.
l 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:
l The standby production copy becomes the active production copy and continues
replicating to the remote cluster.
Recovery and Restoration procedure
l 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:
l The standby production copy becomes the active production copy and continues
l 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.
Data corruption
Data corruption can occur for various reasons. When data becomes corrupted:
l Halt applications.
l In RecoverPoint, find the last uncorrupted image.
l In RecoverPoint, restore production from the last uncorrupted image at copy.
MetroPoint 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

VPLEX Use Cases
executed, active-active access to the volume on both Metro sites becomes available
immediately, as the remote copy is now the production copy.
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.
MetroPoint four-site topology 111

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.

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.
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
MetroPoint four-site topology 113

VPLEX Use Cases
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.
Note
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 Simple Support Matrix for VPLEX for
specific details.
The following MetroPoint deployments are available:
l New MetroPoint installation- Install VPLEX Metro and RecoverPoint and create
MetroPoint groups.
l 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.
l 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.
l 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:
l One production copy at the active source site
l One production copy at the standby source site
l Zero, one, or two local copies
l One remote copy

VPLEX Use Cases
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.
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:
l Replicate from Metro Site A
l Replicate from Metro Site B
l 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:
l In Unisphere for VPLEX, ensure you have provisioned storage and created the
distributed devices you want to use.
l Create VPLEX consistency groups that are RecoverPoint enabled.
l Expose the storage in the VPLEX consistency groups to RecoverPoint and expose the
hosts through the storage views.
l 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:
l Take a RecoverPoint consistency group that is already using distributed RAID 1
volumes for production volumes and convert it to a MetroPoint group.
l 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 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
MetroPoint groups 115

VPLEX Use Cases
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:
l 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.
l 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 the following figure, 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.
Figure 74 MetroPoint - two local copies
The following figure 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.

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 to either a specific
RecoverPoint cluster, or to follow VPLEX bias rules.
l 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.
l 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. The following
figure 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).
Production failover to the remote copy 117

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 to the active source site only. 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 distributed RAID 1 volume is selected as a local copy, then that distributed RAID 1
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 distributed RAID 1 and is not distributed to the other leg
of the distributed RAID 1 copy. However, after production failover to the distributed RAID
1 local copy, the host can access the distributed RAID 1 from both VPLEX sites and VPLEX
rebuilds the distributed RAID 1 legs to synchronize both legs of the distributed RAID 1
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.
The following figure 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 (distributed RAID 1

VPLEX Use Cases
fracture). In this state, only replication I/O from RPA is allowed on the Distrubuted RAID 1
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. An 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 distributed RAID 1 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
Recover production 119

VPLEX Use Cases

APPENDIX A
VS1 Hardware
l VS1 cluster configurations.................................................................................. 122

l VS1 engine..........................................................................................................124
l VS1 IP addresses and component IDs................................................................. 125
l VS1 Internal cabling............................................................................................ 127
VS1 Hardware 121

VS1 Hardware
VS1 cluster configurations

This section illustrates the components in VS1 clusters.
VS1 single-engine cluster

Figure 78 VS1 single-engine cluster
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
Management server OFF

O
I
ON
OFF
O
I
ON
OFF OFF
O O
I I
ON ON
OFF OFF
Director 1B
O O
I I
ON ON
Engine 1
Director 1A
SPS 1
VPLX-000215

VS1 Hardware
VS1 dual-engine cluster

Figure 79 VS1 dual-engine cluster
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF
ON ON
I I
O O
OFF OFF

UPS B
UPS A
O
I
ON
OFF
O
I
ON
Director 2B
Engine 2
OFF
O
I
ON
OFF
O
I
ON
Director 2A
SPS 2
OFF OFF
Director 1B
O O
I I
ON ON
Engine 1
Director 1A
SPS 1
VPLX-000214
VS1 dual-engine cluster 123

VS1 Hardware
VS1 quad-engine cluster

Figure 80 VS1 quad-engine cluster
Director 4B
Engine 4 Director 4A
ON ON
I I
O O
OFF OFF
SPS 4
ON
I
ON
I
Director 3B
Engine 3
O O
OFF OFF
Director 3A
SPS 3 ON
I
O
OFF
ON
I
O
OFF

UPS B
UPS A
O
I
ON
OFF
O
I
ON
Director 2B
Engine 2
OFF
O
I
ON
OFF
O
I
ON
Director 2A
SPS 2
OFF OFF
Director 1B
O O
I I
ON ON
Engine 1
Director 1A
SPS 1
VPLX-000213
VS1 engine
Figure 81 VS1 engine
IOM B0 IOM B1 IOM B2 IOM B3 Director B

0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
F F F F F F F F B B B B B B B B
Power supply B Power supply A
IOM A0 IOM A1 IOM A2 IOM A3 Director A
0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
F F F F F F F F B B B B B B B B
Side B
mgmt. module Side A mgmt. module
IOM B4 IOM B5 IOM A4 IOM A5
0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
L L WF WF WI WI n n L L WF WF WI WI n n I/O module carrier
IOM = I/O module L = Local COM port
F = Front-end SAN port WF = WAN COM port for Fibre Channel
B = Back-end SAN port WI = WAN COM port for IP
n = not currently used VPLX-000343

VS1 Hardware
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.
In the above figure, IOMs A2 and B2 each contain four Fibre Channel ports for VPLEX
Metro WAN connection.
VPLEX Metro also supports IP WAN connections, in which case these IOMs each contain
two Ethernet ports.
In a VPLEX Local configuration, these IOMs contain no ports.
VS1 IP addresses and component IDs

The IP addresses of the VPLEX hardware components are determined by:
l The internal management network (A or B)
l The Cluster IP Seed
l The Enclosure ID (which matches the engine number)
Cluster IP Seed is the same as the Cluster ID:
l For VPLEX Local - Cluster ID is always 1.
l For VPLEX Metro - Cluster ID for the first cluster that is set up is 1, and the second
cluster is 2.
VS1 IP addresses and component IDs 125

VS1 Hardware
VS1 component IP addresses (cluster-1)

Figure 82 IP addresses in cluster-1
Cluster IP Seed = 1
Management network B addresses Management network A addresses
Engine 4: Engine 4:
Director 4B 128.221.253.42 Director 4B 128.221.252.42
Director 4A 128.221.253.41 Director 4A 128.221.252.41
Engine 3: Engine 3:
FC switch B 128.221.253.34
Service port
128.221.252.2
Customer-assigned
FC switch A 128.221.252.34

Management server
128.221.253.33 128.221.252.33
Engine 2: Engine 2:
Engine 1: Engine 1:
VPLX-000107

VS1 Hardware
VS1 component IP addresses (cluster-2)

Figure 83 IP addresses in cluster-2 (VPLEX Metro)
Cluster IP Seed = 2
Management network B addresses Management network A addresses
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

Management server
128.221.253.65 128.221.252.65
Engine 2: Engine 2:
Engine 1: Engine 1:
VPLX-000108
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
only) are installed before the unit ships from EMC.
This section includes the following figures:
Table 7 Cabling within a VPLEX cabinet
Cluster size Cable type Figure

Single-engine Ethernet Figure 84 on page 128
Serial Figure 85 on page 129
Fibre Channel Figure 86 on page 129
AC power Figure 87 on page 130
Dual-engine Ethernet Figure 88 on page 131
VS1 component IP addresses (cluster-2) 127

VS1 Hardware
Table 7 Cabling within a VPLEX cabinet (continued)
Cluster size Cable type Figure

Quad-engine Ethernet Figure 92 on page 135
All cluster sizes, VPLEX Metro only Fibre Channel WAN Figure 96 on page 139
COM
IP WAN COM Figure 97 on page 139
VS1 cabling - single-engine cluster

Figure 84 Ethernet cabling - VS1 single-engine cluster
Management server
Purple, 71 in.
Green, 37 in.
Engine 1
VPLX-000052

VS1 Hardware
Figure 85 Serial cabling - VS1 single-engine cluster
Engine 1
12 in. 12 in.
VPLX-000069
Figure 86 Fibre Channel cabling - VS1 single-engine cluster
Engine 1
39 in.
(2 cables)
VPLX-000063
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.
VS1 cabling - single-engine cluster 129

VS1 Hardware
Figure 87 AC power cabling - VS1 single-engine cluster
OFF
O
OFF
O
Management server
I I
ON ON
OFF OFF
O O
I I
ON ON
OFF OFF
O O
I I
ON ON
Engine 1
SPS
VPLX-000041

VS1 Hardware
VS1 cabling - dual-engine cluster

Figure 88 Ethernet cabling - VS1 dual engine cluster
Green, 48 in.
Purple, 71 in.
Management server
Purple, 71 in.
Green, 37 in.
Engine 2
Green, 20 in.
Purple, 20 in.
Engine 1
VPLX-000043
VS1 cabling - dual-engine cluster 131

VS1 Hardware
Figure 89 Serial cabling - VS1 dual-engine cluster
UPS B
UPS A
40 in.
40 in.
Engine 2
12 in. 12 in.
Engine1
12 in. 12 in.
VPLX-000067

VS1 Hardware
Figure 90 Fibre Channel cabling - VS1 dual-engine cluster

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
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.
VS1 cabling - dual-engine cluster 133

VS1 Hardware
Figure 91 AC power cabling - VS1 dual-engine cluster
UPS B
UPS A
Management server
I I
Engine 2
O
I O
I
SPS 2
O
I O
I
Engine 1
SPS 1
VPLX-000042

VS1 Hardware
VS1 cabling - quad-engine cluster

Figure 92 Ethernet cabling - VS1 quad-engine cluster
Engine 4
Green, 20 in.
Purple, 20 in.
Green, 48 in.
Engine 3
Purple, 71 in.

Purple, 37 in.
Green, 37 in. Fibre Channel switch A
Management server
Green, 37 in.
Engine 2
Purple, 71 in.
Green, 20 in.
Purple, 20 in.
Engine 1
VPLX-000044
VS1 cabling - quad-engine cluster 135

VS1 Hardware
Figure 93 Serial cabling - VS1 quad-engine cluster
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

VS1 Hardware
Figure 94 Fibre Channel cabling - VS1 quad-engine cluster
Engine 4
Engine 3
79 in.
(all 16 cables) Fibre Channel switch B
Engine 2
Engine 1
VPLX-000055
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.
VS1 cabling - quad-engine cluster 137

VS1 Hardware
Figure 95 AC power cabling - VS1 quad-engine cluster
ON
I
ON
I
Engine 4
O O
OFF OFF
SPS 4
ON ON
I I
O O
OFF OFF
Engine 3
ON
I
O
OFF
ON
I
O
OFF
SPS 3
UPS B
UPS A
OFF
O
OFF
O
Management server
I I
ON ON
OFF OFF
Engine 2
O O
I I
ON ON
SPS 2
OFF OFF
O O
I I
ON ON
Engine 1
SPS 1
VPLX-000211

VS1 Hardware
WAN COM cabling - VPLEX Metro

The following figures show the WAN COM connection options for VS1 hardware.
Figure 96 Fibre Channel WAN COM connections - VS1
Cluster 1 (same connections from each engine in cluster) Cluster 2 (same connections from each engine in cluster)
B4-FC02 B4-FC03 A4-FC03 B4-FC02 B4-FC03 A4-FC03

A4-FC02 A4-FC02
Intercluster Intercluster
ISL 1
COM SAN COM SAN NOTE: ISL is
switch 1A switch 2A inter-switch link
Intercluster Intercluster
ISL 2
COM SAN COM SAN
switch 1B switch 2B
VPLX-000317
Figure 97 IP WAN COM connections - VS1

Cluster 1 Cluster 2
(same connections from each engine in cluster) (same connections from each engine in cluster)
B5-GE00 B5-GE01 A5-GE01 IP B5-GE00 B5-GE01 A5-GE01

A5-GE00 subnet A A5-GE00
IP
subnet B
VPLX-000368
WAN COM cabling - VPLEX Metro 139

VS1 Hardware

GLOSSARY
AccessAnywhere The technology that enables VPLEX/VE sites to provide access to information between
sites that are separated by distance.
alarm (vSphere) - A vSphere alarm is an entity that monitors one or more properties of a virtual machine,
such as CPU load. Alarms send notifications as directed by the configurable alarm
definition.
array A collection of disk drives where user data and parity data may be stored.
back-end IP SAN (Array- The IP network that connects physical storage from the iSCSI storage arrays to the
facing) vDirectors. The vDirectors consume the physical storage from the array and produce
distributed virtual volumes.
backend port The virtual adapter port used by the vDirector to connect to the back-end (Array-facing) IP
SAN. This port acts as an iSCSI initiator.
cache 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.
cache coherency Managing the cache so 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 the data blocks.
disaster recovery (DR) The ability to restart system operations after an error, preventing data loss.
distributed datastore A virtual storage volume that is backed by physical storage from two sites within a vSphere
stretched cluster. The distributed virtual volumes is the backing device for a distributed
datastores.
distributed virtual The globally visible storage volumes in VPLEX/VE. The distributed virtual volumes provide
volumes the storage for creating distributed datastores.

Glossary
front-end IP SAN (ESXi- The IP network that presents distributed virtual storage from the vDirectors to ESXi hosts.
facing) Distributed virtual storage is used to provision vSphere distributed datastores.
front end port - The virtual adapter port used by the vDirector to connect to the front-end (ESXi-facing) IP
SAN. This port acts as an iSCSI target.
input/output (I/O) Any operation, program, or device that transfers data to or from a computer.
Inter-Site Management The virtual private network (VPN) tunnel between the management servers across sites. For
Network high availability, there are two such networks between sites.
iSCSI The internet small computer system interface (iSCSI) protocol that allows commands to
travel through IP networks, which carries data from storage units to servers anywhere in a
computer network.
LAN A local area network (LAN) is 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.
latency Amount of time it requires to fulfill an I/O request.
load balancing Distributing the processing and communications activity evenly across a system or
network so no single device is overwhelmed. Load balancing is especially important when
the number of I/O requests issued is unpredictable.
local COM - Communication between vDirectors within a site; note that Local COM and Management
COM share the Local COM (Intra-Site) Network.
Local COM Network (Intra- The private IP networks connecting all VPLEX/VE virtual machines within one site. For high
Site Network) availability, there are two such networks at each site. This is a private network. The virtual
switches for this network are selected during installation, but the IP addresses are static
and cannot be controlled by the installer.
logging volume Logging volumes keep track of blocks written during an inter-site link outage or when one
leg of a DR1 becomes unreachable. After the inter-site link or leg is restored, the VPLEX/VE
system uses the information in the logging volumes to synchronize the mirrors by sending
only the changed blocks across the link.
logical unit number (LUN) 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, connected to a computer. Each device is assigned a LUN number
which serves as the unique address of the device.

Glossary
management COM Communication between the vManagementServer and the vDirectors. Management COM
and Local COM share transport on the Local COM (Intra-site) Network.
meta volume 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 site.
meta-volume backup A meta-volume backup contains the backup copies of the metadata files of a VPLEX/VE
system. You can specify a schedule for running a meta-volume backup. There is one
metadata volume per site.
migration (VPLEX/VE) Migrate one of the backing devices for a distributed datastore to a new storage device with
no application downtime. See the action menu for a distributed datastore in the vCenter
Inventory. Also called device migration.
migration (vSphere) For vSphere, migration is the process of moving a virtual machine between hosts. Unless
vMotion is used, the virtual machine must be powered off when you migrate it. See also
migration with vMotion.
migration with vMotion For vSphere, this is the process of moving a virtual machine that is powered on and meets
(vSphere) selected requirements, including the activation of vMotion on both the source and target
hosts. When you migrate a virtual machine using vMotion, the operations of the virtual
machine can continue without interruption.
open virtual appliance A packaging format for virtual machines that allows virtual machine templates to be
(OVA) distributed, customized, and instantiated on any OVA supporting host. VPLEX/VE is
distributed as an OVA file.
Open Virtualization - A distribution format for virtual appliances that uses existing packaging tools to combine
Format (OVF) one or more virtual machines with a standards-based XML wrapper. OVF gives the
virtualization platform a portable package containing all required installation and
configuration parameters for virtual machines. This format allows any virtualization
platform that implements the standard to correctly install and run virtual machines.
VPLEX/VE uses the OVF standard packaging format.
physical network A network of physical machines (plus cabling, switches, routers, and so on) that are
connected so that they can send data to and receive data from each other. See also virtual
network.
port group (vSphere) A construct for configuring virtual network options such as bandwidth limitations and VLAN
tagging policies for each member port. Virtual networks that are connected to the same
port group share network policy configuration. See also virtual network, VLAN (virtual local
area network).
provisioned storage Maximum amount of storage an entity can use.

Glossary
provisioning Virtual The process of creating a functioning virtual machine by assigning resources such as CPU,
Machines memory, and virtual hardware and then deploying a system image.
RAID The use of two or more storage volumes to provide better performance, error recovery, and
fault tolerance.
rebuild The VPLEX/VE 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.
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.
Site A set of vDirectors and a vManagementServer forming a single fault-tolerant domain.
Site-bias Site at which I/O will continue during an inter-site failure. Each datastore must have
separate site bias settings.
subnet A logical grouping of connected network devices. The devices that are part of a subnet
normally belong to a local area network.
vDS (vNetwork A vSphere virtual switch with an abstract representation of multiple hosts sharing the
Distributed Switch) same vSwitch (same name, same network policy) and port group. The vDS configuration
resides on the vCenter Server, instead of residing on an individual ESXi host. This
abstraction allows virtual machines to vMotion among multiple hosts with no concern for
the switch configuration.
virtual appliance - A software solution that is composed of one or more virtual machines. A virtual appliance
is packaged as a unit by an appliance vendor and is deployed, managed, and maintained
as a unit.
virtual application (vApp) A VMware specific term for a virtual appliance delivered in an OVF package and deployed
to a vCenter Server. The VMware vApp is a self-describing software package composed of
one or more virtual machine.
virtual director (vDirector) The core component in a VPLEX/VE system. A VPLEX/VE vDirector is responsible for
providing the virtual-to-physical I/O translations for vSphere distributed datastores. There
number vDirectors in each VPLEX/VE site is determined by the license.
virtual local area network A logical group of workstations, servers and network devices that appear to be on the
(VLAN) same local area network (LAN) even though they are geographically distributed. A VLAN
allows a network of computers and users to communicate in a simulated environment as if
they exist in a single LAN and are sharing a single broadcast and multicast domain.

Glossary
virtual machine A virtual machine is a software computer that, like a physical computer, runs an operating
system and applications. Multiple virtual machines can operate on the same host system
concurrently.
virtual machine A file containing a virtual machine configuration; a specification of which virtual devices,
configuration file (vmx such as disks and memory, are present in a virtual machine and how they are mapped to
file) host files and devices. This .vmx file is created when you create the virtual machine. It is
used to identify and run a specific virtual machine.
virtual management The management server virtual machine that contains the interface to manage the virtual
server directors and site-level controls for a VPLEX/VE system.
(vManagementServer)
virtual network A network connecting virtual machines that does not depend on physical hardware
connections. For example, you can create a virtual network between a virtual machine and
a host that has no external network connections.
virtual switch A virtualized network switch used by ESXi to manage traffic between virtual machines and
the physical network adapters on the ESXi host.
VLAN (virtual local area A software-managed logical segmentation of a physical LAN. Network traffic within each
network) segment is isolated from traffic in all other segments.
VLAN ID A unique identifier for a VLAN.
VMFS (Virtual Machine A file system that is optimized for storing virtual machines. One VMFS partition is
File System) supported for each SCSI storage device or LUN.
VMkernel In vSphere ESXi, a high-performance operating system that occupies the virtualization
layer and manages most of the physical resources on the hardware, including memory,
physical processors, storage, and networking controllers.
VMware ESXi A virtualization layer run on physical servers that abstracts processor, memory, storage,
and resources into multiple virtual machines. A VMware vSphere feature.
VMware ESXi cluster An ESXi cluster is a group of ESXi hosts. A cluster is an entity that manages the resources
of all the hosts in it. To deploy VPLEX/VE, you must have an ESXi cluster with vSphere High
Availability (HA) and vSphere Distributed Resource Scheduler (DRS) features enabled.
VMware ESXi host An ESXi host is a computer that uses the VMware ESXi virtualization software. The hosts
provide the physical resources such as the CPU and memory that the virtual machines use
to connect to the storage and the network.
VMware ESXi host An ESXi host is a computer that uses the VMware ESXi virtualization software. The hosts
provide the physical resources such as the CPU and memory that the virtual machines use
to connect to the storage and the network.
VMware vCenter Server The central point for configuring, provisioning, and managing virtualized IT environments.
It provides essential datacenter services such as access control, performance monitoring,
and alarm management. VPLEX/VE runs on vCenter Server version 5.1 or later.
VMware vCenter Server The vCenter Server is the centralized management tool for the VMware vSphere suite. As a
single management application, the vCenter Server manages and monitors the multiple
ESXi servers and virtual machines that are part of different ESXi servers. To deploy and
configure VPLEX/VE, you must use the vCenter Server version 5.1 or later.

Glossary
VMware vMotion VMware vMotion enables the live migration of running virtual machines from one physical
server to another with zero downtime, continuous VMware availability, and complete
transaction integrity. VMotion is a key enabling technology for creating the dynamic,
automated, and self-optimizing datacenter.
VMware vMotion - VMware VMotion enables the live migration of running virtual machines from one physical
server to another with zero downtime, continuous VMware availability, and complete
transaction integrity. VMotion is a key enabling technology for creating the dynamic,
automated, and self-optimizing datacenter.
VMware vSphere client The vSphere client communicates to vCenter Server and enables you to perform the actions
that you want to do on your vSphere environment. You can either download this client from
the VMware website or configure the vSphere web client on the vCenter Server.
VMware vSphere Client An interface that enables users to connect remotely to vCenter Server or ESXi from any
(for Windows) Windows PC. Also known as vSphere Desktop Client or '.Net' client. The VPLEX/VE
Management Extension (plug-in) modules are available only in the vSphere Web Client, not
in the vSphere Windows Client.
VMware vSphere Platform Platform for virtualization which manages large collections of infrastructure objects, such
as compute, storage and networking, as a seamless and dynamic operating environment.
The VMware vSphere platform includes:
l VMware ESXi
l VMware vCenter Server
l VMware vSphere Web Client
l vSphere Virtual Machine File System (VMFS)
l vSphere vMotion
l vSphere Storage vMotion
l vSphere High Availability (HA)
l vSphere Distribute Resource Scheduler (DRS)
l vSphere Distributed Switch (VDS)
VMware vSphere Web A Web interface that enables users to connect remotely to vCenter Server from a variety of
Client Web browsers and operating systems.
vNIC A virtual network interface card that is configured on top of a system's physical Network
adapter. See also NIC (network interface card).
VPLEX/VE Manager The name for the vSphere management extension for VPLEX/VE.
VPLEX/VE Manager for The name for the vSphere management extension for VPLEX/VE.
vSphere
vSphere cluster A group of hosts in the virtual environment.
vSphere cluster A vSphere cluster is a group of ESXi hosts. A cluster is an entity that manages the
resources of all the hosts in it. To deploy VPLEX/VE, you must have an vSphere cluster with
vSphere High Availability (HA) and vSphere Distributed Resource Scheduler (DRS) features
enabled.

Glossary
vSphere Distributed A virtual switch that can span multiple ESXi hosts, enabling significant reduction of on-
Switch (VDS) going network maintenance activities and increasing network capacity. This increased
efficiency enables virtual machines to maintain consistent network configuration as they
migrate across multiple hosts.
vSphere Distribute Allocates and balances computing capacity dynamically across collections of hardware
Resource Scheduler (DRS) resources for virtual machines.
vSphere High Availability A feature that provides high availability for virtual machines. If a server fails, affected
(HA) virtual machines are restarted on other available servers that have spare capacity.
vSphere Storage vMotion Enables the migration of virtual machine files from one datastore to another without
service interruption. You can place the virtual machine and all its disks in a single location,
or select separate locations for the virtual machine configuration file and each virtual disk.
The virtual machine remains on the same host during Storage vMotion. Migration with
Storage vMotion lets you move the virtual disks or configuration file of a virtual machine to
a new datastore while the virtual machine is running. Migration with Storage vMotion
enables you to move a virtual machine's storage without any interruption in the availability
of the virtual machine.
vSphere stretched cluster A vSphere stretched cluster contains compute, network and storage resources at two
different physical locations called sites. The sites may be in the same building or different
physical locations with synchronous distances. The sites act as fault domains; a
component failure in one site cannot affect the other site. The stretched cluster ensures
high availability and disaster recovery capabilities of the sites.
VPLEX/VE must be deployed on a vSphere stretched cluster.
Also called ESXi stretched cluster or Metro Stretched Cluster (vMSC).
vSphere Virtual Machine A high performance cluster file system for ESXi virtual machines.
File System (VMFS)
vSphere vMotion Enables the migration of powered-on virtual machines from one physical server to another
with zero down time, continuous service availability, and complete transaction integrity.
Migration with vMotion cannot be used to move virtual machines from one datacenter to
another.
vSS (vNetwork Standard - A virtual switch that is configured on an individual ESXi host. To ensure operations like
Switch or vSwitch) vMotion across ESXi hosts, an administrator must manually maintain consistency of the
vSwitch configuration across the ESXi hosts.
WAN COM (Inter-Site The IP network connecting the vDirectors across sites. As a best practice, this should be a
Network) private network. For high availability, there are two such networks at each site.
zoning Provides access control in the SAN topology. Zoning defines which HBAs can connect to
which storage processors. You can have multiple ports to the same storage processor in
different zones to reduce the number of presented paths.

Glossary

INDEX
2-site topology 104 CPU Load 77

3-site topology 104 cross-connect 88, 90
4-site topology 110
D
A data protection 96
AC power connection 37 detach rules 71
access control 51 devices 54
AccessAnywhere 21, 56, 86, 87 direct access 95
active production copy 114 director 37, 41
active source 116 director failure 41
active source ite 117 disaster recovery 98, 101
active source site 116 distributed data 21
active-active 110 distributed devices 56
active/active access 118 distributed storage 53
ALUA 74 DRS 87
API 50 dual-engine cluster 31, 34
architecture 22
array management providers 51
audience 11
E
availability 21, 24, 56, 6769 Element Manager API 50
engine 37
environmental monitoring 38
B Ethernet connectivity 36
back-end load 77 extents 53
back-end paths 59, 67 EZ provisioning 52
backup metadata 75
batteries
failure 76
F
bias 118 fabric assignments 67
bias rules 114 failed array 38
Big Data 86 failover 94, 116118
bookmarks 95 Failover 116
failures 38, 40, 51, 64, 66, 68, 71, 72, 90
Failures 88
C fake size 95
call home 38, 40, 41, 51, 76 faults 64
CAW 78 Fibre Channel 36, 41
certificates 79 Fibre Channel ports 39
CLI 50 Fibre Channel switches 30, 38
cluster 22, 30, 31, 3335, 64, 100, 101 front-end I/O 40
cluster failure 42 front-end load 77
cluster isolation 72 front-end ports 67
cluster partition 72
cluster power 37
clusters 49, 68, 72
G
collaboration 21, 86 GeoSynchrony 48
command line management 50 global cache 76
comments 11 global visibility 60
communication redundancy 39
communications 41 H
configuration management 75 historical monitoring 27
connectivity HTTPS 79
back-end 36
front-end 36
consistency groups 59, 69, 71, 86, 95 I
conventions for publication 11 I/O best practices 40

Index
I/O failure 41 O
I/O failures 40 outages 64
I/O module failures 40
I/O paths 37
integrated storage 51 P
integrity 64 passwords 79
intra-cluster IP 41 path optimization 74
IPsec 79 performance 27, 56, 59, 77, 78
port failures 39
port usage 79
J power 37, 38
journal volume 95 power failure 76
preface 11
L production copy 114
latency 86 production failover 116
LDAP 51, 79 production site 94
limits 59 production volume 95
link failure 42 provisioning 52, 53
load balancing 59, 77 provisioning storage 51
local and remote protection 98 provisioning wizard 52
local copies 114
local copy 118 Q
local mirrors 57 quad-engine cluster 31, 35
local protection 9799 quorum 65
local replication 96, 97, 99
local visibility 60
log splitting 27 R
logged access 95 recover production 118
logging volumes 38, 58, 75, 76 Recover production 118
LUN mapping 39 RecoverPoint 94, 9799, 102
LUN masking 39 RecoverPoint appliance 95
RecoverPoint Appliance 94, 99, 101, 118
RecoverPoint cluster 100, 101
M RecoverPoint configurations 96
management from clusters 49 RecoverPoint consistency group 94, 95, 116
Management GUI 49 RecoverPoint failover 95
management server 30, 43 RecoverPoint splitter 94, 100
management server failure 43 RecoverPoint Volumes 95
metadata volumes 75 recovery 104
Metro HA 87, 88, 90 redundancy 3743, 56, 57, 64, 6668, 94
MetroPoint 103, 114, 116118 redundant connections 67
MetroPoint consistency group 117 redundant directors 66
MetroPoint group 117 redundant fabrics 67
MetroPoint groups 114 redundant paths 66, 68
MetroPoint upgrade 114 related documentation 11
migration 82, 84 reliability 39, 42, 43, 53, 58
mirror recovery 118 remote copies 114
mirroring 57 remote copy 117
mirrors 21, 38, 39, 58, 75 remote mirrors 57
mobility 19, 8285 remote protection 97
monitoring 38, 50, 51, 7779 remote replication 96, 99
monitoring CLI 78 replica site 94
monitors 78 replica volume 95
MSCE 98 replica volumes
multi-pathing 64, 67, 68 rollback 97
multipathing replication 94, 99, 101104, 110
SFP 39 repository volume 95
resiliancy 59
N resilience 21, 24, 41, 75
network failures 72 resiliency 72
non-disruptive upgrade 26 resilliance 68
REST 50

Index
rollback 95 U
RPA 99 uninterupted power supply 38
RPO 69 Unisphere for VPLEX 49
RTO 69, 72, 87, 90 Unisphere GUI 49
RTT 87 Unisphere monitoring tool 77
rule sets 69 upgrade 26, 114
UPS 38
S user roles 79
scalability 21
security 51, 79 V
single-engine cluster 31, 33 vault 76
site distribution 68 vCenter 102
site recovery 102 VIAS 51
Site Recovery Manager 102 virtual access 95
SMI-S 51 virtual volumes 57, 67
SNMP 50 visibility 55, 59, 60, 86
splitter 100 VMware cross-cluster connection 74
SPS 38 VMware HA 87
SRM 102 VPLEX Metro failures 72
standby power 38 VPLEX Witness 24, 42, 6872, 74, 87, 88, 90
standby production copy 114
statistics 78
storage 51 W
storage arrays 56 WAN connectivity 36
subnets 41 WAN link load 77
support information 11 WWN 22
synchronous consistency groups 59
Z
T zoning 37
technology refresh 82
thick rebuilds 53
thin rebuilds 53

Index

Docu61175 VPLEX 5.5 Product Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Docu61175 VPLEX 5.5 Product Guide

Transféré par

Droits d'auteur :

Formats disponibles

EMC VPLEX

Published September 2016

2 EMC VPLEX 5.5 Product Guide

Chapter 1 Introducing VPLEX 15

Chapter 2 VS2 Hardware 29

EMC VPLEX 5.5 Product Guide 3

Chapter 3 VPLEX Software 47

Chapter 4 Integrity and Resiliency 63

4 EMC VPLEX 5.5 Product Guide

Performance monitoring and security features...............................................76

Chapter 5 VPLEX Use Cases 81

Appendix A VS1 Hardware 121

EMC VPLEX 5.5 Product Guide 5

6 EMC VPLEX 5.5 Product Guide

EMC VPLEX 5.5 Product Guide 7

8 EMC VPLEX 5.5 Product Guide

EMC VPLEX 5.5 Product Guide 9

10 EMC VPLEX 5.5 Product Guide

EMC VPLEX 5.5 Product Guide 11

Addresses practices not related to personal injury.

Presents information that is important, but not hazard-related.

Table 1 Typographical conventions

Bold Used for names of interface elements, such as names of windows,

Italic Used for full titles of publications referenced in text

Monospace italic Used for variables

[] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means or

{} Braces enclose content that the user must specify, such as x or y or z

... Ellipses indicate nonessential information omitted from the example

Where to get help

12 EMC VPLEX 5.5 Product Guide

EMC VPLEX 5.5 Product Guide 13

14 EMC VPLEX 5.5 Product Guide

This chapter introduces the EMC VPLEX product family.

VPLEX addresses three primary IT needs:

16 EMC VPLEX 5.5 Product Guide

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

VPLEX product family

VPLEX product family 17

Figure 2 VPLEX family: Local and Metro

EMC VPLEX Local EMC VPLEX Metro

Within a data center AccessAnywhere at

18 EMC VPLEX 5.5 Product Guide

Grow your VPLEX without disruption

Grow your VPLEX without disruption 19

Figure 3 Move data without disrupting service

VPLEX Local VPLEX Metro

20 EMC VPLEX 5.5 Product Guide

l Migrate data between dissimilar arrays.

Because VPLEX GeoSynchrony AccessAnywhere mirrors all data, applications continue

Figure 6 Distributed data collaboration

Enable concurrent read/write access to data across locations

22 EMC VPLEX 5.5 Product Guide

Figure 7 Architecture highlights

HP, Oracle (Sun), Hitachi, HP (3PAR), IBM, EMC

Features and benefits

Table 2 VPLEX features and benefits

Features and benefits 23

Table 2 VPLEX features and benefits (continued)

For all VPLEX products, GeoSynchrony:

24 EMC VPLEX 5.5 Product Guide

Figure 8 How VPLEX Witness is deployed

High availability compared to disaster recovery

High availability compared to disaster recovery 25