EMC VPLEX Architecture

.

The diagram displays the VS 2 engines released with VPLEX 5.0. The example shows a Quad-Engine VPLEX configuration. Notice the VPLEX numbering starts from the bottom up. Every engine contains a standard power supply. The difference between a quad and a dual engine is that other than having half the engines, a Dual engine also has one fewer SPS. A single engine implementation contains a Management Server, Engine, and SPS only

All supported VPLEX configurations ship in a standard, single rack. The shipped rack contains the selected number of engines, one Management Server, redundant Standby Power Supplies (SPS) for each engine, and any other needed internal components. The pair of SPS units provides DC power to the engines in case there is a loss of AC power. The batteries in the SPSs can hold a charge up to 10 minutes. However, the maximum hold time is 5 minutes.
The dual and quad configurations include redundant internal FC switches for LCOM connection between the directors. In addition, dual and quad configurations contain redundant Uninterruptible Power Supplies (UPS) that service the FC switches and the Management Server. GeoSynchrony is pre-installed on the VPLEX hardware and the system is pre-cabled, and also pretested.
Engines are numbered 1-4 from the bottom to the top. Any spare space in the shipped rack is to be preserved for potential engine upgrades in the future. Since the engine number dictates its physical position in the rack, numbering will remain intact as engines are added during a cluster upgrade.

VPLEX engines can be deployed as a single, dual, or quad cluster configuration depending upon the number of front-end and back-end connections required. The VPLEX’s advanced data caching algorithms are able to detect sequential reads to disk. As a result, VPLEX engines are able to fetch
data from disk to cache in order to improve host read performance.
VPLEX engines are the brains of a VPLEX system, they contain two directors, each providing frontend and back-end I/O connectivity.
They also contain two directors, redundant power supplies, fans, I/O modules, and management modules. The directors are the workhorse components of the system and are responsible for processing I/O requests from the hosts, serving and maintaining data in the distributed cache, providing the virtual-to-physical I/O translations, and interacting with the storage arrays to service I/O.
A VPLEX VS2 Engine has 10 I/O modules, with five allocated to each director. Each director has
one four-port 8 Gb/s Fibre Channel I/O module used for front-end SAN (host) connectivity and
one four-port 8 Gb/s Fibre Channel I/O module used for back-end SAN (storage array) connectivity. Each of these modules has 40 Gb/s effective PCI bandwidth to the CPUs of their
corresponding director. A third I/O module, called the WAN COM module, is used for inter-cluster
communication. Two variants of this module are offered, one four-port 8 Gb/s Fibre Channel
module and one two-port 10 Gb/s Ethernet module. The fourth I/O module provides two ports of
8 Gb/s Fibre Channel connectivity for intra-cluster communication. The fifth I/O module for each
director is reserved for future use.

The VPLEX product family has currently released three configuration options: VPLEX Local, Metro,
and Geo.
VPLEX Local provides seamless, non-disruptive data mobility and the ability to manage and mirror
data between multiple heterogeneous arrays from a single interface within a data center. VPLEX
Local consists of a single VPLEX cluster. It contains a next-generation architecture that allows
increased availability, simplified management, and improved utilization and availability across
multiple arrays.
VPLEX Metro enables active/active, block level access to data between two sites within
synchronous distances. The distance is limited not only by physical distance but also by host and
application requirements. Depending on the application, VPLEX clusters should be installed with
inter-cluster links that can support not more than 5ms1 round trip delay (RTT). The combination
of virtual storage with VPLEX Metro and virtual servers enables the transparent movement of
virtual machines and storage across synchronous distances. This technology provides improved
utilization and availability across heterogeneous arrays and multiple sites.
VPLEX Geo enables active/active, block level access to data between two sites within
asynchronous distances. VPLEX Geo enables more cost-effective use of resources and power.
VPLEX Geo extends the distance for distributed devices up to and within 50ms RTT. As with any
asynchronous transport media, you must also consider bandwidth to ensure optimal performance.
Due to the asynchronous nature of distributed writes, VPLEX Geo has different availability and
performance characteristics than Metro.

EMC VPLEX is a next generation architecture for data mobility and information access.
It is based on unique technology that combines scale out clustering and advanced data caching,
with the unique distributed cache coherence intelligence to deliver radically new and improved
approaches to storage management.
This architecture allows data to be accessed and shared between locations over distance via a
distributed federation of storage resources

Internal management of the VPLEX is performed with a dedicated IP network. This is a high-level
architectural view of the management connections between the Management Server and
directors. In this picture there are NO internal VPLEX IP switches. The directors are daisy chained
together via two redundant Ethernet connections.
The Management Server also connects via two redundant Ethernet connections to the directors in
the cluster. The Management Server is the only VPLEX component that gets configured with a
“public” IP on the data center network. From the data center IP network, the Management Server
can be accessed via SSH or HTTPS.

Cache coherence creates a consistent global view of a volume.
Distributed cache coherence is maintained using a directory. There is one directory per user
volume and each directory is split into chunks (4096 directory entries within each). These chunks
exist only if they are populated. There is one directory entry per global cache page, with
responsibility for:
• Tracking page owner(s) and remembering the last writer
• Locking and queuing

.