Escolar Documentos
Profissional Documentos
Cultura Documentos
These technical notes describe various EMC VPLEX configurations and the
recommended best practices for each configuration.
Summary..................................................................................................116
Appendix A: VS1 ....................................................................................117
Glossary....................................................................................................121
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Data Mobility: The ability to move applications and data across different storage
installationswithin the same data center, across a campus, or within a
geographical region
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
For access to all VPLEX related collateral, interaction and information from EMC
please visit the customer accessible:
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Data Mobility
EMC VPLEX enables the connectivity to heterogeneous storage arrays providing
seamless data mobility and the ability to manage storage provisioned from multiple
heterogeneous arrays from a single interface within a data center. Data Mobility and
Mirroring are supported across different array types and vendors.
VPLEX Metro or Geo configurations enable migrations between locations over
synchronous/asynchronous distances. In combination with, for example, VMware
and Distance vMotion or Microsoft Hyper-V, it allows you to transparently relocate
Virtual Machines and their corresponding applications and data over synchronous
distance. This provides you with the ability to relocate, share and balance
infrastructure resources between data centers. Geo is currently supported with
Microsoft Hyper-V only.
The EMC Simple Support Matrix (ESSM) Simplified version of the ELab Navigator
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Continuous Availability
Virtualization Architecture
Built on a foundation of scalable and continuously available multi processor engines,
EMC VPLEX is designed to seamlessly scale from small to large configurations.
VPLEX resides between the servers and heterogeneous storage assets, and uses a
unique clustering architecture that allows servers at multiple data centers to have
read/write access to shared block storage devices.
Unique characteristics of this new architecture include:
Scale-out clustering hardware lets you start small and grow big with
predictable service levels
Consistent view of one or more LUNs across VPLEX clusters (within a data
center or across synchronous distances) enabling new models of continuous
availability and workload relocation
With a unique scale-up and scale-out architecture, VPLEX advanced data caching and
distributed cache coherency provide workload resiliency, automatic sharing,
balancing, and failover of storage domains, and enables both local and remote data
access with predictable service levels.
EMC VPLEX has been architected for multi-site virtualization enabling federation
across VPLEX Clusters. VPLEX Metro supports max 5ms RTT, FC or 10 GigE
connectivity. VPLEX Geo supports max 50ms RTT, and 10GigE. The nature of the
architecture will enable more than two sites to be connected in the future.
EMC VPLEX uses a VMware Virtual machine located within a separate failure domain
to provide a VPLEX Witness between VPLEX Clusters that are part of a
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Storage/Service Availability
Each VPLEX site has a local VPLEX Cluster and physical storage and hosts are
connected to that VPLEX Cluster. The VPLEX Clusters themselves are interconnected
across the sites to enable federation. A device is taken from each of the VPLEX
Clusters to create a distributed RAID 1 virtual volume. Hosts connected in Site A
actively use the storage I/O capability of the storage in Site A, Hosts in Site B actively
use the storage I/O capability of the storage in Site B.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPLEX distributed volumes are available from either VPLEX cluster and have the
same LUN and storage identifiers when exposed from each cluster, enabling true
concurrent read/write access across sites.
When using a distributed virtual volume across two VPLEX Clusters, if the storage in
one of the sites is lost, all hosts continue to have access to the distributed virtual
volume, with no disruption. VPLEX services all read/write traffic through the remote
mirror leg at the other site.
10
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPLEX Components
VPLEX Components
VPLEX Engine VS2
VS2 refers to the second version of hardware for the VPLEX cluster. The VS2
hardware is on 2U engines and will be detailed below. For information on VS1
hardware please see the appendix.
The following figures show the front and rear views of the VPLEX VS2 Engine.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
11
VPLEX Components
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPLEX Components
ports on one cluster must see all of the directors WAN COM ports within the same
port group on the other cluster across two different pipes. This applies in both
directions.
When configuring the VPLEX Cluster cabling and zoning, the general rule is to use a
configuration that provides the best combination of simplicity and redundancy. In
many instances connectivity can be configured to varying degrees of redundancy.
However, there are some minimal requirements that must be adhered to for support
of features like NDU. Various requirements and recommendations are outlined below
for connectivity with a VPLEX Cluster.
Frontend (FE) ports provide connectivity to the host adapters also known as host
initiator ports. Backend (BE) ports provide connectivity to storage arrays ports known
as target ports or FAs.
Do not confuse the usage of ports and initiator ports within documentation. Any
general reference to a port should be a port on a VPLEX director. All references to
HBA ports on a host should use the term initiator port. VPLEX Metro and VPLEX
Geo sections have a more specific discussion of cluster-to-cluster connectivity.
General information (applies to both FE and BE)
Official documents as may be found in the VPLEX Procedure Generator refer to a
minimal config and describe how to connect it to bring up the least possible host
connectivity. While this is adequate to demonstrate the features within VPLEX for the
purpose of a Proof of Concept or use within a Test/Dev environment it should not be
implemented in a full production environment. As clearly stated within the
documentation for minimal config this is not a Continuously Available solution.
Solutions should not be introduced into production environments that are not HA.
Also, this minimal config documentation is specific to host connectivity. Please do
not try to apply this concept to backend array connectivity. The requirements for
backend must allow for connectivity to both fabrics for dual path connectivity to all
backend storage volumes from each director.
The following are recommended:
Each VPLEX director will physically connect to both fabrics for both host
(front-end) and storage (back-end) connectivity. Hosts will connect to both an
A director and B director from both fabrics and across engines for the
supported HA level of connectivity as required with the NDU pre-checks.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
13
VPLEX Components
14
Back-end connectivity checks verify that there are two paths to each LUN
from each director. This assures that the number of combined active and
passive paths (reported by the ndu pre-check command) for the LUN is
greater than or equal to two. This check assures that there are at least two
unique initiators and two unique targets in the set of paths to a LUN from
each director. These backend paths must be configured across both fabrics as
well. No volume is to be presented over a single fabric to any director as this
is a single point of failure.
Fabric zoning should consist of a set of zones, each with a single initiator and
up to 16 targets.
Avoid incorrect FC port speed between the fabric and VPLEX. Use highest
possible bandwidth to match the VPLEX maximum port speed and use
dedicated port speeds i.e. do not use oversubscribed ports on SAN switches.
Each VPLEX director has the capability of connecting both FE and BE I/O
modules to both fabrics with multiple ports. The ports connected to on the
SAN should be on different blades or switches so a single blade or switch
failure wont cause loss of access on that fabric overall. A good design will
group VPLEX BE ports with Array ports that will be provisioning groups of
devices to those VPLEX BE ports in such a way as to minimize traffic across
blades.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Dual Fabric
Dual HBA
Required
Required
Initiator connected to
both an A and B
Director
Required
Recommended
Recommended
Required
Required
Not Supported
Not Supported
Arrays direct
connected to VPLEX
Directors
Supported
Not Supported
Not Supported
Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
15
It is required that
metadata and metadata
backups are configured
across arrays at the local
site if more than one
array is present. A
standard test during a
POC is to perform an
NDU. It would be
undesirable to have to use
the --skip option if not
needed.
Host Cross-Cluster
Connect
Array Cross-Cluster
Connect
VPLEX Witness
16
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Note: Direct connect applies only to backend connectivity. Frontend direct connect is
not supported.
Active/Active Arrays
Each director in a VPLEX cluster must have a minimum of two I/O paths to every
local back-end storage array and to every storage volume presented to that cluster
(required). This is referred to as an ITL or Initiator/Target/LUN.
Each director will have redundant physical connections to the back-end storage across
dual fabrics (required) Each director is required to have redundant paths to every
back-end storage array across both fabrics.
Each storage array should have redundant controllers connected to dual fabrics, with
each VPLEX Director having a minimum of two ports connected to the back-end
storage arrays through the dual fabrics (required).
VPLEX recommends a maximum of 4 active paths per director to a given LUN
(Optimal). This is considered optimal because each director will load balance across
the four active paths to the storage volume.
High quantities of storage volumes or entire arrays provisioned to VPLEX should be
divided up into appropriately sized groups (i.e. masking views or storage groups) and
presented from the array to VPLEX via groups of four array ports per VPLEX director
so as not to exceed the four active paths per VPLEX director limitation. As an example,
following the rule of four active paths per storage volume per director (also referred to
as ITLs), a four engine VPLEX cluster could have each director connected to four array
ports dedicated to that director. In other words, a quad engine VPLEX cluster would
have the ability to connect to 32 ports on a single array for access to a single device
presented through all 32 ports and still meet the connectivity rules of 4 ITLs per
director. This can be accomplished using only two ports per backend I/O module
leaving the other two ports for access to another set of volumes over the same or
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
17
18
1.
2.
3.
4.
Create a separate port group within the array for each of these logical path
groups.
5.
Spread each group of four ports across array engines for redundancy.
6.
Mask devices to allow access to the appropriate VPLEX initiators for both port
groups.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
19
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
21
22
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPlexcli:/ll **/hardware/ports
As an example:
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
23
24
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
array port
WWN
VPLEX
Backend port
WWN
From the storage-volumes context you can select a sample volume and cd to that
context. Running the ll --full command will show the ITLs.
In this example we have sixteen entries for this volume. This is a single engine VPLEX
cluster connected to a VNX array. Even though this gives us eight paths per director
for this volume only four paths go to the array SP that owns the volume. In either
mode 1 or mode 4 (ALUA), the paths going to the other SP will not be used for I/O.
Only in the case of a trespass will they become active.
Note: All paths, whether active or not, will perform device discovery during
an array rediscover. Over allocating the number of paths beyond the
supported limits will have detrimental effects on performance and/or
backend LUN provisioning.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
25
26
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
27
Significant Bit
The above two illustrations show the significant bit but there are other bit
considerations for identifying all possible ports. The following will help explain the
bit positions as they apply to the various modules on a CLARiiON / VNX.
The CLARiiON CX4 Series supports many more SP ports. As such the original method
of specifying the Ports would cause an overlap between SP A high end ports and SP B
low end ports.
That is, SPA9 would have the significant byte pair as 69, which is SPB1.
The new method is as follows :
SPA0-7 and SPB0-7 are the same as the old method.
Port
28
SP A
SP B
00
50:06:01:60:BB:20:02:07
50:06:01:68:BB:20:02:07
01
50:06:01:61:BB:20:02:07
50:06:01:69:BB:20:02:07
02
50:06:01:62:BB:20:02:07
50:06:01:6A:BB:20:02:07
03
50:06:01:63:BB:20:02:07
50:06:01:6B:BB:20:02:07
04
50:06:01:64:BB:20:02:07
50:06:01:6C:BB:20:02:07
05
50:06:01:65:BB:20:02:07
50:06:01:6D:BB:20:02:07
06
50:06:01:66:BB:20:02:07
50:06:01:6E:BB:20:02:07
07
50:06:01:67:BB:20:02:07
50:06:01:6F:BB:20:02:07
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
SP A
SP B
08
50:06:01:60:BB:24:02:07
50:06:01:68:BB:24:02:07
09
50:06:01:61:BB:24:02:07
50:06:01:69:BB:24:02:07
10
50:06:01:62:BB:24:02:07
50:06:01:6A:BB:24:02:07
11
50:06:01:63:BB:24:02:07
50:06:01:6B:BB:24:02:07
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
29
Host Connectivity
Host Connectivity
Front-end/host initiator port connectivity
Dual fabric designs are considered a best practice
The front-end I/O modules on each director should have a minimum of two physical
connections one to each fabric (required).
Each host should have at least one path to an A director and one path to a B director on each
fabric for a total of four logical paths (required for NDU).
Multipathing or path failover software is required at the host for access across the dual fabrics
Each host should have fabric zoning that provides redundant access to each LUN from a
minimum of an A and B director from each fabric.
Four paths are required for NDU
Observe Director CPU utilization and schedule NDU for times when average directory CPU
utilization is below 50%
GUI Performance Dashboard in GeoSynchrony 5.1 or newer
Skipping the NDU pre-checks would be required for host connectivity with less than four paths
and is not considered a best practice
NOTE: An RPQ will be required for single attached hosts and/or
environments that do not have redundant dual fabric configurations.
More information is available in the
30
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Host Connectivity
Export Considerations section.
Note: Each Initiator / Target connection is called an IT Nexus. Each VPLEX frontend port supports up to 400 IT nexuses and, on VS2, each engine has a total of 8
front-end target ports. Dual and quad-engine clusters provide additional
redundancy but do not increase the total number of initiator ports supported on a
per-cluster basis. For that matter, all listed limits in the Release Notes apply to all
VPLEX Cluster configurations equally regardless whether it is a single, dual or
quad engine configuration.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
31
Host Connectivity
Additional recommendations
If more than one engine is available, spread I/O paths across engines as well as
directors.
Note: For cluster upgrades when going from a single engine to a dual
engine cluster or from a dual to a quad engine cluster you must rebalance
the host connectivity across the newly added engines. Adding additional
engines and then not connecting host paths to them is of no benefit.
Additionally until further notice, the NDU pre-check will now flag any
host connectivity as a configuration issue if they have not been
rebalanced. Dual to Quad upgrade will not flag an issue provided there
were no issues prior to the upgrade. You may choose to rebalance the
workload across the new engines or add additional hosts to the pair of
new engines.
Complete physical connections to the VPLEX before commissioning/setup.
Use the same FE/BE ports on each director to avoid confusion, that is, B0-FC00 and
A0-FC00. Please refer to hardware diagrams for port layout.
32
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Host Connectivity
Figure 15 Host connectivity for Single Engine Cluster meeting NDU pre-check requirements
This illustration shows dual HBAs connected to two Fabrics with each connecting to
two VPLEX directors on the same engine in the single engine cluster. This is the
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
33
Host Connectivity
minimum configuration that would meet NDU requirements.
This configuration increases the chance of a read cache hit increasing performance.
Please refer to the Release Notes for the total FE port IT Nexus limit.
34
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Host Connectivity
Figure 16 Host connectivity for HA requirements for NDU pre-checks dual or quad engine
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
35
Host Connectivity
The previous illustration shows host connectivity with dual HBAs connected to four
VPLEX directors. This configuration offers increased levels of HA as required by the
NDU pre-checks. This configuration could be expanded to additional ports on the
VPLEX directors or additional directors for the quad-engine configuration. This
configuration still only counts as four IT Nexus against the limit as identified in the
Release Notes for that version of GeoSynchrony.
Pros:
Good design for hosts using load balancing multipath instead of path failover
software
Cons:
36
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Host Connectivity
The previous illustration shows host connectivity with dual HBAs connected to four
VPLEX engines (eight directors). This configuration counts as eight IT Nexuses
against the total limit as defined in the Release Notes for that version of
GeoSynchrony. Hosts using active/passive path failover software should connect a
path to all available directors and manual load balance by selecting a different director
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
37
Host Connectivity
for the active path with different hosts.
Most host connectivity for hosts running load balancing software should follow the
recommendations for a dual engine cluster. The hosts should be configured across
two engines and the hosts should alternate between pairs of engines effectively
load balancing the I/O across all engines.
Pros:
Offers highest level of Continuous Availability for hosts running load balancing
software
Allows for N-1 director failures while always providing access to data as long as 1
director stays online
Cons:
Consumes double the IT Nexus count against the system limit identified in the
Release Notes as compared to the dual engine configuration
o
38
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Host multipathing software can be configured for active path/passive path with
active path going to the local VPLEX cluster. When feasible, configure the
multipathing driver to prefer all local cluster paths over remote cluster paths.
Separate HBA ports should be use for the remote cluster connection to avoid
merging of the local and remote fabrics
At least one backend storage array is required at each site with redundant
connection to the VPLEX cluster at that site. Arrays are not cross connected to
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
39
All Consistency Groups used in a Cluster cross-connect are required to have the
auto-resume attribute set to true
The unique solution provided by Cluster cross-connect requires hosts have access to
both datacenters. The latency requirements for Cluster cross-connect can be achieved
using an extended fabric or fabrics that span both datacenters. The use of backbone
fabrics and LSAN zones may introduce additional latency preventing a viable use of
Cluster cross-connect. The rtt for Cluster cross-connect must be within 1ms.
PowerPath supports auto-standby on PPVE 5.8 its documented in the release notes
and CLI guide.
Windows
Solaris
HP-UX
The only thing that the customer has to do is enable the autostandby feature:
#powermt set autostandby=on trigger=prox host=xxx
PowerPath will take care of setting to autostandby those paths associated with the
remote/non-preferred VPLEX cluster.
PP groups the paths by VPLEX cluster and the one with the lowest minimum path
latency is designated as the local/preferred cluster.
HP-UX MPIO
HP-UX MPIO policy least-command-load is better performing than simple roundrobin.
40
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Applies to vSphere 4.1 and newer and VPLEX Metro Spanned SAN configuration
HA/DRS cluster is stretched across the sites. This is a single HA/DRS cluster with
ESXi hosts at each site
The HA/VM /Service console/vMotion networks should use multiple NIC cards
on each ESX for redundancy
The ESXi servers should use internal disks or local SAN disks for booting. The
Distributed Device should not be used as a boot disk
VPLEX Witness must be installed at a third location isolating it from failures that
could affect VPLEX clusters at either site
In case of a Storage Volume failure or a BE array failure at one site, the VPLEX
will continue to operated with the site that is healthy. Furthermore if a full VPLEX
failure or WAN COM failure occurs and the cluster cross-connect is operational
then these failures will be transparent to the host
Create a common storage view for ESX nodes on site 1 on VPLEX cluster-1
Create a common storage view for ESX nodes on site 2 on VPLEX cluster-2
All Distributed Devices common to the same set of VMs should be in one
consistency group
All VMs associated with one consistency group should be collocated at the same
site with the bias set on the consistency group to that site
If using ESX Native Multi-Pathing (NMP) make sure to use the fixed policy and
make sure the path(s) to the local VPLEX is the primary path(s) and the path(s) to
the remote VPLEX is only stand-by
For additional information please refer to White Paper: Using VMware vSphere with
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
41
42
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
43
http://www.vmware.com/files/pdf/techpaper/vSPHR-CS-MTROSTOR-CLSTR-USLET-102-HI-RES.pdf
Note: vSphere and ESXi 5.1 introduces a new feature called APD timeout.
This feature is automatically enabled in ESXi 5.1 deployments and while not
to be confused with PDL states does carry an advantage whereby if both
fabrics to the ESXi host or an entire VPLEX cluster fails, the host (which
would normally hang (also known as a VM zombie state)) would now be able
to respond to non-storage requests since "hostd" will effectively disconnect
the unreachable storage, however this feature does not cause the affected VM
to die. Please see this article for further details:
http://www.vmware.com/files/pdf/techpaper/Whats-New44
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
2. On every ESXi server, vi /etc/vmware/settings with the content below, then reboot
the ESXi server.
The following output shows the correct setting applied in the file:
~ # cat /etc/vmware/settings
disk.terminateVMOnPDLDefault=TRUE
Refer to the ESX documentation for further details.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
45
Engine 1
A
B
1,2,3,4,5,6,7,8 1,2,3,4,5,6,7,8
Dual Engine
Engine #
Director
Cluster #
A
1,3,5,7
Quad Engine
Engine #
Director
Cluster#
A
1,5
Engine 1
Engine 2
B
2,4,6,8
A
2,4,6,8
B
2,6
A
3,7
Engine 1
B
1,3,5,7
Engine 2
Engine 3
B
4,8
A
4,8
Engine 4
B
3,7
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
A
2,6
B
1,3
4. Pathing policy
a. Non cross connected configurations recommend to use adaptive pathing policy in all
cases. Round robin should be avoided especially for dual and quad systems.
b. For cross connected configurations, fixed pathing should be used and preferred
paths set per Datastore to the local VPLEX path only taking care to alternate and
balance over the whole VPLEX front end (i.e. so that all datastores are not all
sending IO to a single VPLEX director).
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
47
Virtual Volumes
2.
3.
Host Initiators
The combination of each of the VPLEX Frontend Ports and the Host Initiators are
called IT Nexus (Initiator/Target Nexus). An IT Nexus can only access a single
Storage View. If a Host requires access to another Storage View with the same set of
Initiators then the Initiators must be zoned to other VPLEX frontend ports and those
IT Nexus combinations would be used for access to the new Storage View. The NDU
requirements must be met for each Storage View independently even if the Host
Initiator and frontend connectivity meet the requirements for a different Storage View.
Virtual Volumes can be placed in multiple Storage Views which offer additional
options to architecting different solutions based on unique customer needs.
Create a separate storage view for each host and then add the volumes for that host to
only that view
For redundancy, at least two initiators from a host must be added to the storage view
Clustered Hosts
Create a separate storage view for each node for private volumes such as boot volume
Create new pairs of IT Nexus for node HBA Initiators on different VPLEX Frontend
Ports
Create a Storage View for the Cluster that contains the shared Virtual Volumes and
add IT Nexus pairs that are different than those for the private volume Storage Views
As Mentioned above, there are additional options for Clustered Hosts. This specific
option may consume more IT Nexuses against the system limits but it allows for a
single Storage View for shared volumes. This minimizes the possibility of user error
when adding or removing shared volumes.
48
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Note: ESX Initiators apply to the physical server, not the individual
VMs.
Note: It is very important not to exceed the 4 paths per Storage Volume per Director as this
would cause a DU event under certain Fabric failures as VPLEX tries to timeout the paths.
Host platforms would weather the storm if connectivity was within supported limits but
could cause extreme timeouts on the host if an excessive number of paths per Storage
Volume per Director were configured causing the host to fail the device resulting in a DU
event.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
49
Note: The IT nexus limit was increased to 400 with GeoSynchrony 5.1 patch 2
for frontend port connectivity in conjunction with increasing the IT nexus
limit to 3,200 for the VPLEX Local and VPLEX Metro solutions. Please refer to
Release Notes for specific support limits.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Having a host utilize more than the required number of directors can increases cache
update traffic among the directors
High fabric latencies increase the chance that the host will fail
51
52
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Management network
Note: VPLEX Metro supports 10 GigE WAN COM connectivity but will
continue to follow all current limits of latency and redundancy for synchronous
write through mode.
53
VPLEX Local
The only network requirements for a VPLEX Local are for management access. Access
requires configuring the IP Address for eth3 on the management server and
connecting the management server to the customer network.
The eth3 port on the management server is configured for Auto Negotiate and is 1
GigE capable. Even though the primary use is for management, file transfer is very
important and proper speed and duplex connectivity is imperative for transferring
collect-diagnostics or performing NDU package transfers. If file transfer appear
extremely slow then it would be prudent to check the network switch to make sure
that the port connected to isnt set to 100/full duplex as no auto negotiations would
happen and the network connectivity would default to 100/half duplex. This
situation would cause file transfers to take possibly hours to transfer. Please dont
assume that you wont use this port for file transfer as it will be used in a Metro or
Geo NDU as well as the possibility of performing the NDU via ESRS remotely.
For some very specific installations such as government dark sites, it may be required
that the VPLEX Cluster not be connected to the network for security reasons. In this
situation, it is still required to configure an IP Address for eth3 but a non-routable
address such as 192.168.x.x can be used in order to proceed with the installation. The
IP Address can be changed at a later date if necessary but a specific procedure is
required to reconfigure ipsec when attempting to change the IP Address.
Management of the cluster can be performed via the service port. This only applies to
the VPLEX Local solution as both VPLEX Metro and VPLEX Geo require VPN
connectivity between clusters over the management servers eth3 port.
Note: VPLEX only supports IPv4 for GeoSynchrony releases 5.2 and older. IPv6 is
available with GeoSynchrony 5.3 and newer.
54
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
The best practice for configuring the VPN is to follow the installation guide and run
the automated VPN configuration script.
Network QoS requires that the link latency does not exceed 1 second (not millisecond)
for management server to VPLEX Witness server
Network QoS must be able to handle file transfers during the NDU procedure
Static IP addresses must be assigned to the public ports on each Management Server
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
55
NOTE: The IP Management network must not be able to route to the following
reserved VPLEX subnets: 128.221.252.0/24, 128.221.253.0/24, and 128.221.254.0/24.
The following protocols need to be allowed on the firewall (both in the outbound and
inbound filters):
56
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Function
Service
Log in to management
server OS, copy files to
and from the management
server using the SCP subservice and establish SSH
tunnels
SSH
IPsec VPN
ESP
ISAKMP
Time synchronization
service
NTP
SNMP
Https
Localhost TCP/5901
VNC
Localhost TCP/49500
Telnet
Lightweight Directory
Access Protocol
LDAP
ldaps
Protocol for
communicating with the
RecoverPoint functional
API
RecoverPoint
Public Port 80
Http
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
57
58
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPLEX Metro
Cluster connectivity
VPLEX Metro connectivity is defined as the communication between clusters in a
VPLEX Metro. The two key components of VPLEX Metro communication are FC
(FCIP, DWDM) or 10 GigE and VPN between management servers. Please refer to
the VPN section for details. FC WAN is the Fibre Channel connectivity and 10 GigE is
the Ethernet connectivity options between directors of each cluster. Choose one or the
other but not both.
Each directors FC WAN ports must be able to see at least one FC WAN port on every
other remote director (required).
The directors local com port is used for communications between directors within the
cluster.
Each director has two FC WAN ports that should be configured on separate fabrics (or
FC/IP external hardware) to maximize redundancy and fault tolerance so that s single
external VPLEX failure does not cause a full WAN communications failure to a single
director
Configure FC WAN links between clusters like ISLs between FC switches. This does
not require a merged fabric between locations.
Logically isolate VPLEX Metro traffic from other traffic using zoning, VSANs or LSAN
zones. Additionally, physical isolation from the SAN can be achieved by connecting
to separate switches used to connect the data centers without requiring connection to
the local SAN.
Must follow all the network requirements outlined in the Geo section
Configured and monitored using the same tools as the Geo solution
59
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
At Site-2:
Place ISLs between switch-1A and switch-2A and between switch-1B and switch-2B.
The best practice is to have your ISL traffic travel through independent links (and/or
carrier) between your sites.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
61
62
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Though this requires more setup than a single zone, it is worth the effort and should
not be considered out of the norm for a SAN administrator.
Assuming two fabrics and dual-engine systems for Cluster A and Cluster B, each
fabric would be zoned as follows:
Key:
Director-1-1-A = cluster 1 engine director A1 : D11A
Director-2-1-B = cluster 2 engine 1 director B: D21B
WAN COM ports are FC00 or FC01
All combined (example): D11A:FC00
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
63
64
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
An example is as follows :
VPlexcli:/> connectivity director --director director-1-1-A/
Device VPD83T3:50060160bce00a99 is a default LUN_0.
StorageVolumes discovered - sorted by: name
StorageVolume Name
WWN
---------------------------------------- -----------------VPD83T3:60000970000192601707533031353237 0x50000972081aadd4
0x50000972081aadd5
VPD83T3:60000970000192601707533031353238 0x50000972081aadd4
0x50000972081aadd5
Initiators discovered
Node WWN
Port WWN
------------------ -----------------0x20000000c98ce6cd 0x10000000c98ce6cd
0x20000000c98ce6cc 0x10000000c98ce6cc
LUN
-----------------0x0000000000000000
0x0000000000000000
0x0001000000000000
0x0001000000000000
Ports
------A2-FC00
A2-FC00
A2-FC00
A2-FC00
Ports
------A0-FC00
A0-FC00
In the Directors discovered by section, check to make sure that the director has
connectivity to the remote directors using the ports A4-FC02 and A4-FC03.
Repeat this process for all the remaining directors in your system and check to make
sure that they can reach the remote directors using both the FC WAN ports.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
65
IP WAN connectivity
Each directors IP WAN ports must be able to see at least one WAN port on every
other remote director (required).
The directors local com port is used for communications between directors within the
cluster.
Each director has two WAN ports that should be configured on separate hardware to
maximize redundancy and fault tolerance.
Configure WAN links between clusters on network components that offer the same
Quality of Service (QoS).
VPLEX uses round-robin load balancing and is at the mercy of the slowest pipe
66
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
67
VPlexcli:/> ll /clusters/<cluster_name>/consistency-groups/<cg_name>/advanced
/clusters/<cluster_name>/consistency-groups/<cg_name>/advanced:
Name
Value
-------------------------- -------auto-resume-at-loser
false
current-queue-depth
1
current-rollback-data
0B
default-closeout-time
0.5min
delta-size
16M
local-read-override
true
max-possible-rollback-data 992M
maximum-queue-depth
6
potential-winner
write-pacing
inactive
The default value for queue depth is 6 which may be adjusted as high as 64.
Decreasing the maximum-queue-depth will decrease the maximum RPO in the event
of link and/or cluster failures. Increasing the maximum-queue-depth will enhance
the ability of the vplex system to handle bursts of traffic.
NOTE: Increasing the maximum-queue-depth will increase the amount data
that must roll-back in the case of a cluster failure or a link outage.
68
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
rebuild
------full
full
full
full
full
rebuilder
--------s2_0908_spa
s2_0908_spa
s1_0a69_spb
s2_0908_spb
s1_0a69_spa
rebuilt/total
------------5.59G/10.1G
5.59G/10.1G
3.87G/10.1G
620M/10.1G
7.99G/10.1G
% finished
---------55.47%
55.47%
38.40%
6.01%
79.32%
throughput
---------31.8M/s
31.8M/s
42.4M/s
16.8M/s
34.5M/s
ETA
--------2.4min
2.4min
2.48min
9.58min
61sec
69
In order to use jumbo frames, you need to set each and every hop along the path to
jumbo frames enabled.
The VPlexCLI command director tracepath will help here. When you set the end
points to 9000 mtu, run the tracepath command, it will tell you what it thinks each
point on the path can support. You have to set the end points to something large in
order to find the biggest mtu size, unfortunately you cant just find out with the end
points set to 1500. From the CLI Guide, it will look something like this:
Also, in the firmware log (in /var/log/VPlex/cli/ on the management station), you
can look for specific messages regarding what a director thinks the MTU size on the
path:
ipc/36 example path MTU from B2-XG00 (slic2eth0 mtu 1500) to 153.7.45.24 is
likely to be 128 or slightly higher.
Be sure to check the firmware log for ipc and comUdt related messages when you
are trying jumbo frames this will give a clue as to why the connection isnt working.
You may see things like accepted or losing connection. Tail the firmware log when
you make the MTU changes.
After determining the maximum MTU prior to setting that value on the VPLEX port
groups, you must determine if there will be any WAN optimization/acceleration gear
that will also be added inline. Optimization typically adds a slight overhead to the
packet during transmission. An example of this would be the RapidPath nodes. If
you set them to use UDP optimization and Multihoming then the overhead added has
a value of 124. This value must be subtracted from the maximum MTU value i.e. 1500
-124=1376. The MTU value that would be set on VPLEX in this case would be 1376.
Likewise, if you determined that the MTU size should be 9000 then you would apply a
value of 8876 on VPLEX. 8876 + 124 = 9000.
Note: Only modify one port group at a time, as to not lose connectivity
between clusters.
70
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPlexcli:/>connectivity validate-wan-com
VPlexcli:/>cd /clusters/cluster-1/cluster-connectivity/port-groups/port-group-0
VPlexcli:/>cd /clusters/cluster-2/cluster-connectivity/port-groups/port-group-0
VPlexcli:/> cd /clusters/cluster-1/cluster-connectivity/subnets/cluster-1-SN00
VPlexcli:/clusters/Cluster-1/cluster-connectivity/subnets/cluster-1-SN00> set mtu 9000
VPlexcli:/> cd /clusters/cluster-2/cluster-connectivity/subnets/cluster-2-SN00
VPlexcli:/clusters/cluster-2/cluster-connectivity/subnets/cluster-1-SN00> set mtu 9000
Note:
mtu
VPlexcli:/> cd /clusters/cluster-1/cluster-connectivity/port-groups/port-group-0
VPlexcli:/clusters/cluster-1/cluster-connectivity/port-groups/port-group-0/
set enabled all-enabled
VPlexcli:/> cd /clusters/cluster-2/cluster-connectivity/port-groups/port-group-0
VPlexcli:/clusters/Cluster-2/cluster-connectivity/port-groups/port-group-0/
set enabled all-enabled
Validate connectivity:
VPlexcli:/>cd /clusters/cluster-1/cluster-connectivity/port-groups/port-group-1
VPlexcli:/>cd /clusters/cluster-2/cluster-connectivity/port-groups/port-group-1
VPlexcli:/> cd /clusters/cluster-1/cluster-connectivity/subnets/cluster-1-SN01
VPlexcli:/clusters/Cluster-1/cluster-connectivity/subnets/Cluster-1-SN01> set mtu 9000
VPlexcli:/> cd /clusters/cluster-2/cluster-connectivity/subnets/cluster-2-SN01
VPlexcli:/clusters/Cluster-2/cluster-connectivity/subnets/Cluster-1-SN01> set mtu 9000
VPlexcli:/> cd /clusters/cluster-1/cluster-connectivity/port-groups/port-group-1
VPlexcli:/clusters/Cluster-1/cluster-connectivity/port-groups/port-group-1/
set enabled all-enabled
VPlexcli:/> cd /clusters/cluster-2/cluster-connectivity/port-groups/port-group-1
VPlexcli:/clusters/Cluster-2/cluster-connectivity/port-groups/port-group-1/
set enabled all-enabled
Validate connectivity:
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
71
Make sure that you set the Maximum Transmission Unit (MTU) and the Socket
Buffers according to your anticipated workloads. Figures 19 and 20 offer some
suggested values to start your base lining process:
72
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
73
74
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
VPLEX Witness
VPLEX Witness
Note: If VPLEX Witness fails and will be down for an extended period of time
then it is very important that it is disabled within vplexcli so that VPLEX will
respond to additional failures based on the detach rules. Failure to do so will
cause a dual failure resulting in cluster isolation and suspension of all devices
on both clusters.
Please reference the TechBook: EMC VPLEX Metro Witness Technology and High
Availability for additional details.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
75
Consistency Groups
Consistency Groups
There are three types of consistency groups: asynchronous, synchronous and
RecoverPoint. Asynchronous consistency groups are used for distributed volumes in
a VPLEX Geo to ensure that I/O to all volumes in the group is coordinated across both
clusters, and all directors in each cluster. All volumes in an asynchronous group share
the same detach rule and cache mode, and behave the same way in the event of an
inter-cluster link failure. Only distributed volumes can be included in an
asynchronous consistency group.
Synchronous consistency groups, on the other hand, simply provide a convenient way
to apply rule sets and other properties to a group of volumes at a time, simplifying
system configuration and administration on large systems. Volumes in a synchronous
group behave as volumes in a VPLEX Local or Metro, and can have global or local
visibility. Synchronous groups can contain local, global, or distributed volumes.
RecoverPoint consistency Groups contain the Journal and Replica volumes for the
corresponding data volumes found in a RecoverPoint enabled consistency group.
VPLEX Witness controls rule sets for consistency groups only. Distributed volumes
not placed within consistency groups will simply apply the detach rules without
guidance from VPLEX Witness.
Note: VPLEX Witness will not provide guidance for Consistency Groups that do not
have the detach rule set to make one of the clusters the winner.
For additional information, please refer to VPLEX with GeoSynchrony CLI Guide
found on support.emc.com or the online help found within the GUI.
76
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Rule Sets
Rule Sets
As a minimum, set the detach timer to 5 seconds. Setting the detach delay lower than 5
seconds can result in unnecessary or numerous storage detaches during periods of
network instability. Multiple detaches in a short period of time can also result in many
unnecessary data rebuilds and subsequently in reduced performance.
Configure detach rules based on the cluster/site that you expect to continue I/O
during any network outage.
Avoid conflicting detach situations. Each distributed device (or group of devices)
must have a rule set assigned to it. When a clusters distributed device detaches
during a link outage or other communications issue with the other members of a
distributed device, the detached device can resume I/O. Therefore, it is important to
understand the nature of the outage and which cluster is set to automatically detach.
It is a recommendation that the rule set configuration for each distributed device or
group of devices be documented as well as plans for how to handle various outage
types.
It is important to note that rule sets are applied on a distributed device basis or to a
number of devices within a consistency group. It is within normal parameters for
different distributed devices to resume I/O on different clusters during an outage.
However, if a host application uses more than one distributed device, most likely all of
the distributed devices for that application should have the same rule set to resume
I/O on the same cluster.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
77
System Volumes
System Volumes
There are two types of system volumes. Each cluster must have a metadata volume.
Each VPLEX Metro or Geo cluster must also have sufficient logging volumes to
support its distributed devices.
Metadata volume
Metadata volumes consistency should be periodically checked using
the meta-volume verify-on-disk-consistency style short -c
<cluster>
A metadata volume contains information specific to a VPLEX Cluster such as virtualto-physical mapping information, data about the devices and virtual volumes, system
configuration settings, and other system information. Metadata volumes are created
during system installation. However, you may need to create a metadata volume if,
for example, you are migrating to a new array.
Note the following:
78
A metadata volume is the only object you create on a storage volume without claiming
it first
You create metadata volumes directly on storage volumes, not extents or devices
Metadata volumes must be mirrored between different storage arrays whenever more
than one array is configured to a VPLEX Cluster NDU requirement
Two Metadata volume backups must be configured for every VPLEX Cluster and
must be placed on different arrays whenever more than one array is configured to a
VPLEX Cluster NDU requirement
Installations that were initially configured with a single array per VPLEX cluster must
move a Metadata mirror leg and a backup copy to the second array once provisioned
Metadata volumes are written to at the time of a configuration change and read from
only during the boot of each director
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
System Volumes
Note: Metadata volumes are required to be zeroed out. Follow the procedure
outlined in VPLEX Procedure Generator to zero the disks to be used for the
Metadata Volumes and Metadata volume backups. Additionally, writing
zeros to thin devices will force them to be fully allocated which is necessary
for VPLEX supportability with both Metadata volumes and logging volumes.
Spare volumes for each cluster to hold backups You need to rotate a minimum of
two backups per VPLEX Cluster
A system-wide scheduled backup done at regular times A single cluster backup for
a VPLEX Metro or VPLEX Geo is not useful
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
79
System Volumes
Logging volumes
Note: Single-cluster systems (VPLEX Local) and systems that do not have
distributed devices do not require logging volumes.
The first bitmap log is used if the clusters partition, for writes on the winning
site. You will use this log to send the blocks for the log rebuild
2.
The 2nd bitmap log is used if your local array fails. Since writes to the local
leg will fail, you mark the 2nd bitmap log. You then use this in a log rebuild
to pull data from the remote cluster.
If a logging volume is not created, every inter-cluster link-failure could cause a full
resynchronization of every distributed device in the system. The logging volume
must be large enough to contain one bit for every page of distributed storage space.
The calculation for determining logging volume size is: 10 GB protects 320TB/N [n is
the number of clusters] Consequently, you need approximately 10 GB of logging
volume space for every 160 TB of distributed devices in both a VPLEX Metro and
VPLEX Geo. Logging volumes are not used for VPLEX Local configurations and are
not used for local mirrors.
The logging volume receives a large amount of I/O during and after link outages.
Consequently, it must be able to handle I/O quickly and efficiently. EMC
recommends that you stripe it across several disks to accommodate the I/O volume,
and that you also mirror it, since this is important data. EMC also recommends
placing the logging volume on separate physical spindles than the storage volumes
that it is logging against.
Because logging volumes are critical to the functioning of the system, the best practice
is to mirror them across two or more back-end arrays to eliminate the possibility of
data loss on these volumes. In addition, they can be striped internally on the back-end
arrays. The RAID level within the array should be considered for high performance.
When a failure happens that invoke the use of the logging volume then they will
experience very high read/write I/O activity during the outage. During normal
healthy system activity, logging volumes are not used.
80
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
System Volumes
If one array's data may, in the future, be migrated to another array, then the arrays
used to mirror the logging volumes should be chosen such that they will not be
required to migrate at the same time.
You can have more than one logging volume, and can select which logging volume is
used for which distributed device.
Logging volumes are supported on thin devices however it is a requirement that the
thin device be fully allocated. For similar reasons as the metadata volume
requirement, logging volumes are active during critical times and must have the
highest level of availability during that time.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
81
System Volumes
Migration by application and/or volume. This way any necessary driver updates can
happen on a host-by-host basis
Select back-end ports for specific arrays/initiator groups (on those arrays)
Note: Please refer to the VPLEX Procedure Generator for various step by step
host and clustered host encapsulation procedures. Please note that work is
being done to get away from the use of the --appc flag. Some of the newer
procedures have already removed this step in favor of performing the
encapsulation via the GUI. The 1:1 Virtual Volume creation within the GUI
Wizard avoids the problems that were being protected against which required
the --appc flag.
You must create a single extent across the entire capacity of each storage volume
82
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
System Volumes
VPLEX Non-Disruptive Insertion (NDI) Options
Overview
Because VPLEX changes the addressing that hosts use to access storage, there is a
common misconception that inserting a VPLEX into a running environment must be a
disruptive process. In fact, the vast majority of IT environments already have the tool
sets for enabling VPLEX to be inserted without ANY downtime for the end user
community. This document outlines the wide variety of processes that users can use
to insert a VPLEX non-disruptively. For additional details, or if you have questions,
please contact the VPLEX Deal Support Desk.
Background
In the process of virtualizing back end storage LUNs, VPLEX creates new WWNs /
Volume IDs to present to the hosts. These WWNs / Volume IDs are usually mapped
one-to-one with the LUN(s) of the storage behind the VPLEX. Because the WWN /
Volume ID is different than what the host originally was using, the traditional
assumption has been that the host must be re-booted to recognize the new WWNs.
This re-boot downtime is often a minor objection to adopting VPLEX technology.
Avoiding these disruptions is possible using a number of common alternatives. Tools
already existing in typical IT environments which can be leveraged to nondisruptively migrate any number of user data sets whether the whole environment,
or a subset of applications that make up the most mission-critical suite. The option of
choosing which servers to move non-disruptively is totally up to the IT administrative
team.
VPLEX Non-Disruptive Insertion (NDI) supported environments include:
83
System Volumes
Prerequisites
The following sections outline the process of NDI for each of these mainstream use
cases. In each example, it is assumed that the user has:
Verified support of each of the targeted hosts by VPLEX and remediated any that are
not currently on the VPLEX ESM
With VPLEX, created a one-to-one mapping of the existing LUNs to new VPLEX
LUNs for each of the targeted hosts LUNs
Associated the targeted hosts with their respective new VPLEX LUNs
VMware:
1) Perform a Storage vMotion from the original LUN to the new VPLEX LUN
2) Perform a vMotion to the VPLEX LUN
3) Repeat as necessary; multiple Storage vMotions and vMotions can be executed
simultaneously (just not the SAME LUN)
4) OPERATION COMPLETE
MS Hyper V
1) Perform a Quick Storage Migration from the original LUN to the new VPLEX LUN (Hyper V will
suspend the VM during this time)
2) Perform a Live Migration to the VPLEX LUN
3) Repeat as necessary; multiple Quick Storage Migrations and Live Migrations can be executed
simultaneously (just not the SAME LUN)
4) OPERATION COMPLETE
84
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
System Volumes
Create mirrored relationship between the existing host-based LUNs and the new VPLEX LUNs
Initiate mirroring
Transition primary access to the VPLEX LUNs and dis-associate the two sets of LUNs
OPERATION COMPLETE
Create mirrored relationship between the existing host-based LUNs and the new VPLEX LUNs
Initiate mirroring
Transition primary access to the VPLEX LUNs and dis-associate the two sets of LUNs
OPERATION COMPLETE
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
85
System Volumes
NDI with PowerPath Migration Enabler
Any host running PPME can perform a VPLEX NDI. Process is equivalent to hostbased mirroring processes
1)
2)
3)
4)
Create mirrored relationship between the existing host-based LUNs and the new VPLEX LUNs
Initiate mirroring
Transition primary access to the VPLEX LUNs and dis-associate the two sets of LUNs
OPERATION COMPLETE
FAQ:
Q: To encapsulate one LUN on an ESX cluster do we need to stop only VMs on that
LUN or do we need to shutdown the servers? The procedure Encapsulate arrays on
ESX without boot from SAN generates by procedure generator says that we must
stop the ESX server for an encapsulation (its not a cluster).
A: You would need to stop access by all VMs to the Datastore (Lun), remove access
by the ESX cluster to the lun (masking/zoning on native array), rescan/refresh the
ESX storage, present encapsulated lun via VPLEX, rescan/refresh the ESX storage,
persistently mount the Datastore (choose keep signature while mounting as new
signature will for virtual volume will be different), restart your VMs.
86
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
87
Note: VPLEX only supports block-based storage devices which uses 512-byte sector
for allocation or addressing, hence ensure the storage array connecting to VPLEX
supports or emulates the same. The storage devices which doesn't use 512-byte sector
may be discovered by VPLEX but cannot be claimed for use within VPLEX and cannot
be used to create meta-volume. When a user tries to utilize the discovered storage
volumes having unsupported block size within VPLEX either by claiming them or for
creating meta-volume using appropriate VPLEX CLI commands, the command fails
with this error - "the disks has an unsupported disk block size and thus can't be
moved to a non-default spare pool". Also the storage device having capacity not
divisible by 4KB (4096B) may be discovered by VPLEX but cannot be claimed for use
within VPLEX. When a user tries to utilize a discovered storage volume having
unsupported aligned capacity within VPLEX by claiming them using appropriate
VPLEX CLI commands, the command fails with this error "The storage-volume
<StorageVolumeName> does not have a capacity divisible by the system block size
(4K and cannot be claimed.)"
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Extent sizing
Extents should be sized to match the desired virtual volume's capacity. If the storage
volume you want to use for an extent is larger than the desired virtual volume, create
an extent the size of the desired virtual volume. Do not create smaller extents and then
use devices to concatenate or stripe the extents.
Creating smaller extents on the same storage volume and using devices to concatenate
or stripe these extents may create spindle contention on the underlying storage
volume and not provide any protection from storage volume failure. Creating smaller
extents on different storage volumes and using devices to concatenate or stripe these
extents will distribute the virtual volume's I/O over multiple storage volumes, which
may be beneficial for throughput and responsiveness in some cases, but it also creates
additional management complexity. You should only do this when you know the I/O
pattern will benefit from this.
When disk capacities are smaller than desired volume capacities, best practice is to
create a single slice per disk, and use RAID structures to concatenate or stripe these
slices into a larger RAID.
Volume Expansion
Volume Expansion refers to the expansion operation performed from within VPLEX.
Volume Expansion is now supported with GeoSynchrony 5.2 and later nondisruptively when performed from the back-end array.
This discussion has no bearing on Thin Provisioned device expansion as just like a
host, VPLEX is already projecting the full capacity regardless of the actual used
capacity. Further expansion beyond the original full capacity does apply though.
Volume Expansion is supported in GeoSynchrony 4.2 on up.
You can non-disruptively expand the capacity of a virtual volume by entering the
capacity needed, and then selecting from a list of storage volumes with available
capacity. The virtual volume you are expanding can be created on a RAID-0, RAID-C
or RAID-1 device. When you expand a volume, VPLEX automatically creates the
extent and concatenates the additional capacity to the virtual volume. These
components are visible when you view the component map.
You can expand a virtual volume as many times as necessary. The Expandable column
on the Virtual Volumes screen indicates whether a volume can be expanded.
89
You can select only one storage volume. This storage volume can be the same storage
volume from which the virtual volume is created, or it can be a different storage
volume
You must select two or more storage volumes. We recommend that you select a
number of storage volumes greater than or equal to the number of components (legs)
in the device. At a minimum, you should have the same redundancy as the original
RAID-1 device on which the virtual volume is created
Although you can select the same storage volumes on which the virtual volume was
created, we recommend that you select storage volumes from different arrays to avoid
any single point of failure
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Databases should be aligned to the beginning of VPLEX's virtual volumes (or some
integral number of database blocks from LBA 0).
The device boundaries must be at a multiple of 64 KB. For RAID 0 this means
a stripe depth that is a multiple of 64 KB. For RAID-C this means
concatenating devices whose total size is a multiple of 64 KB
Use smaller extents to virtualize a large storage volume into a smaller virtual volume
Remember that you can create one to 128 extents on a single storage volume. The
default is one extent comprised of the whole storage volume
Avoid creating RAID 0 structures on storage volumes that are constructed from
stripes in the storage array. This could create hot spots in the array
Stacking of RAID 0s
When creating a device the underlying storage should be taken into account. If the
underlying storage volume has RAID 0 or stripe properties from the storage array, the
VPLEX administrator should use that storage in a device with RAID 1 or RAID-C
properties (not RAID 0 properties). This is to avoid reverse mapping of RAID 0 or
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
91
92
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Export Considerations
Export Considerations
Host multipathing drivers, OS, application considerations
Avoid multipathing software that does excessive round-robin and/or splits I/O
Make sure host I/O paths include redundancy across the first and second upgraders
(director A and B) as required by NDU pre-checks
Avoid connecting to multiple A directors and multiple B directors with a single host
or host cluster. This increases the chance of a read cache hit improving performance
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
93
LUN Expansion
LUN Expansion
New to GeoSynchrony 5.2:
Note: In Release 5.2, VPLEX supports the OS2007 bit on Symmetrix arrays. This setting is
vital to detect LUN swap situations and storage volume expansion automatically on a
Symmetrix array. The Symmetrix section of the Configuring Arrays procedure in the
generator contains instructions on setting the OS2007 bit.
Storage array based volume expansion enables storage administrators to expand the
size of any virtual volume by expanding the underlying storage-volume.
The supported device geometries include virtual volumes mapped 1:1 to storage
volumes, virtual volumes on multi-legged RAID-1, and distributed RAID-1, RAID-0,
and RAID-C devices under certain conditions. The expansion operation is supported
through expanding the corresponding Logical Unit Numbers (LUNs) on the back-end
(BE) array.
Storage array based volume expansion might require that you increase the capacity of
the LUN on the back-end array.
Procedures for doing this on supported third-party luns are availble with the storage
array based volume expansion procedures in the generator.
94
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
LUN Expansion
Pre GeoSynchrony 5.2
VPLEX Distributed Volume Expansion
This document will walk the user through the steps of expanding a VPLEX distributed
volume. This is online process that can be done either primarily through the GUI or
the VPLEXcli. Both GUI and CLI procedures are shown. Utilizing the PowerPath
"standby" option for stopping I/O is discussed in the Appendix.
http://one.emc.com/clearspace/docs/DOC-57694
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
95
Data Migration
Data Migration
Extent migration
Extent migration is the process of non-disruptively moving an extent from one storage
volume to another. An extent migration should be used when:
Relocating an extent from a hot storage volume shared by other busy extents
Source and target arrays have a similar configuration, that is, the same number of
storage volumes, identical capacities, and so on
Device migration
Device migration is the process of non-disruptively moving a device from one set of
extents to another. A device migration should be used when:
Migrating data between dissimilar arrays. For example, a storage administrator might
need to slice or combine extents on a target arrays storage volumes to create devices
that match the capacities of existing devices on the source array
Relocating a device from an array behind one VPLEX in a VPLEX Metro cluster to an
array behind a different VPLEX Cluster (a VPLEX exclusive)
Batch migration
A batch migration is a group of extent or device migrations that are executed as a
single migration job. A batch migration should be used for:
Non-disruptive cross VPLEX Metro device migration, that is, moving data to an array
at a different site (a VPLEX exclusive)
Migration jobs
The best practice is to monitor the migration's effect on the host application and to
adjust down the transfer size if it is too high.
Consider pausing migrations during the day and resuming them at night or during
off-peak hours to reduce the potential performance impact.
Consider committing migration jobs shortly after they complete to avoid double
writes to both the source and target RAIDs, which could potentially affect
performance.
96
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Data Migration
Performance notes
Migration and front-end performance will primarily depend on:
Rebuild-type setting
Other migrations will be queued and started once a rebuild slot opens up
Array's write limit to the durable media/disk (not the deferred write speed!)
PCI port bandwidth configured for backend and frontend I/O on VPLEX
Best case (no FE or BE bottlenecks) a VS2 Engine can do upwards of 3 GB/s seq reads
and 4 GB/s seq writes. Say at 3 GB/s, that would be over 5 TB/hour to do a
producer/consumer read/write stream. Of course, that assumes all things optimal...
What is transfer size? (as referenced in the vplexcli)
Transfer size is the region of a source element that is temporarily locked, read, and
written on the target. The default value is 128 KB. It can be as small as 4 KB (the block
size of devices) and as large as 32 MB although not recommend to exceed 2 MB. The
size can be changed during a migration, will take effect immediately, and is persistent
for future migrations.
How does transfer size affect performance?
A larger transfer size:
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
97
Data Migration
Results in a higher-performance migration but the tradeoff is that there will be more
performance impact on FE I/O, especially for VPLEX Metro migrations
Is set for devices where the priorities are data protection or migration performance
A smaller transfer size:
Results in the migration taking longer but will have lower impact on FE I/O in terms
of the response time to the host
It is advisable to avoid the use of higher transfer speeds during times of heavy
application activity.
98
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Scale Up Recommendations
Note: For Dual or Quad engine clusters the NDU requirements require spreading the
host initiators across engines. This may pose a problem when upgrading from a single
engine to a dual as the customer would be required to reconfigure host connectivity.
The NDU pre-check requirements for host connectivity can be mitigated under these
circumstances by using the --skip-group-fe-checks. This will Skip all NDU pre-checks
related to front-end validation. This includes the unhealthy storage views and storage
view configuration pre-checks. If choosing this option, the recommended best
practice would be to run the normal pre-check first which would flag all the unhealthy
Storage Views allowing the customer to verify host connectivity for those Storage
Views. The recommendation would be to correct connectivity issues for all hosts
running critical apps. Customers may also wish to perform an NDU after upgrading
but havent had the opportunity to reconfigure all the host connectivity yet.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
99
Hardware Upgrades
The hardware upgrade procedure will be found in the VPLEX Procedure Generator.
This is a complicated procedure and requires a significant amount of preparation. The
best practice recommendation is to review the online training just prior to going to a
customer site to perform the procedure. Opening a proactive SR is also required prior
to performing the procedure.
100
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
101
102
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
103
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
textoutputcollector-vplex.xml
Parse the collected virtual volume .csv files, adding additional metrics
calling them FeReadLat and FeWriteLat :
<value-list name="FeReadLat" leaf="fe-lu.read-lat .*recent.*"
unit="us"/>
<value-list name="FeWriteLat" leaf="fe-lu.write-lat .*recent.*"
unit="us"/>
b. vplex-create-w4n-collection.py
Add following text to add latency metrics in the monitor creation
script:
cli.make_monitor(director, "W4N_VIRTUAL", "felu.read-lat,fe-lu.write-lat,fe-lu.ops,fe-lu.read,fe-lu.write,virtualvolume.dirty,virtual-volume.ops,virtual-volume.read,virtualvolume.write", "/clusters/" + cluster + "/virtual-volumes/*", logdir +
"/virt-volumes/" + cluster + "_" + director + ".volumes.csv")
2- Restart collector /opt/APG/bin/manage-modules service
<collector_instance_name> restart
3- Run Import DB Properties Task under Centralized Management to add new
properties in the DB
4- Log out and log back in to have an up to date reports display
5- Do a search to make sure you have new properties in the DB filter on parttype is VDisk
Expand On device part na
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
105
9- Do not be surprised when you see multiple lines in the graph. Ultimately the latency
that the host would see depends upon which director its accessing, but generally the
latency is the average across all directors. The latency is affected by the I/O load on the
106
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
107
Naming conventions
For device/volume naming, users should decide early on whether they will name
volumes after underlying storage or prefer to have volumes named after the data they
contain. This is because it will become important on their first migration when they
have to decide whether to rename the volume after the target device or keep the
current name.
During the course of managing your virtualized environment you will create various
virtual storage objects (extents, devices, virtual volumes, storage views, and so on).
Each of these objects has a name. Some commands create default names. The
following name rules are enforced for all names:
Names can consist of:
Digits
Underscores
Dashes
108
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Storage volumes - Indicate the storage array and other identifying info
Devices - May reference information from the storage volume, but it is more important
to make some reference to the host/application/purpose
Virtual volumes The default is named after the top-level device, appending _vol
Additionally, try not to load names with too much information.
Accountability/Auditing
Note taking
Support calls
Capture sessions can also be used to document best practices and procedures that you
develop specifically to your environment.
It is highly recommended that you start a capture session before any important admin
tasks, especially before NDU.
Captured sessions may also be the proof needed to show you didnt cause a problem.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
109
Note: Later versions of the GUI allow for changing the GUI Timeout
Value via the gear shaped icon in the upper right corner of the interface.
110
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
111
Monitoring VPLEX
The EMC VPLEX CLI Guide has more information monitoring VPLEX.
Make regular use of summary and reporting commands to monitor the VPLEX. These
commands can provide a quick overview of how the system is configured and its
general health. It is recommended that you become familiar with and develop your
own set of routine commands to do a quick check of the system.
The following commands are used to monitor clusters and system health:
health-check:
Displays a report indicating overall hardware/software health.
If no arguments are given, it performs a high level check for major subcomponents
with error conditions. Warnings are ignored. It is used for instantaneous, high level
view of the health of the VPLEX.
Please refer to the CLI Guide for additional information about specific arguments and
their behaviors.
NDU pre-check
The ndu pre-check command should be run before you run a non-disruptive upgrade
on a system to upgrade GeoSynchrony. This command runs through a number of
checks to see if the non-disruptive upgrade would run into any errors in upgrading
GeoSynchrony. The checks performed by ndu pre-check are listed in the Upgrade
procedure for each software release. This procedure can be found in the generator.
Validate commands:
Connectivity validate-be
This provides a summary analysis of the back-end connectivity information displayed
by connectivity director if connectivity director was executed for every director in the
system. It checks the following:
112
The number of active paths from each director to a storage volume does not
exceed 4.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
In GeoSynchrony 5.0 and later, the perpetual monitors are kicked off and controlled
by the CLI. These are rolled to ensure they dont get too big. They contain a standard
set of categories that engineering is interested in. Do not delete these files! Users can
still create their own monitors if they like
Once the monitors start and are periodically updating, the process is to go to the
VPLEX management station and grab the CSV files, which are one per director, and
are typically stored in /var/log/VPlex/cli/. Import the CSV data into Excel, but this
is very manual. This data is usually collected in response to a perceived performance
problem and would normally be requested by engineering. Engineering has
developed a series of tools that help in the analysis of the performance data.
For the command report create-monitors, this grabs only port, virtual-volume, and
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
113
114
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
115
Summary
Summary
VPLEX provides an abstraction layer between the host and the storage array. VPLEX
inherently adds HA attributes, but it also requires careful planning to take full
advantage. The VPLEX best practices weve reviewed along with traditional SAN
architecture and planning best practices must be observed to fully leverage the
availability, mobility, and collaboration capabilities of the EMC VPLEX platform.
116
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Appendix A: VS1
Appendix A: VS1
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
117
Appendix A: VS1
118
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Appendix A: VS1
Director A and Director B each have four I/O modules for SAN connectivity. The
IOM carriers are for inter-director communications over Local com or WAN com.
Two of the four I/O modules on each director are configured for host connectivity and
are identified as front end while the other two modules are configured for array
connectivity identified as back end. The frontend ports will log in to the fabrics and
present themselves as targets for zoning to the host initiators and the backend port
will log in to the fabrics as initiators to be used for zoning to the array targets.
Each director will connect to both fabrics with both frontend and backend ports.
Those connections should span both I/O modules for both the front end and back end
so that failure of a single I/O module wont create unnecessary Data Unavailability
events.
VPLEX offers separate port connectivity for WAN COM (Director to Director
communications between clusters). FC WAN COM ports will be connected to
separate backbone fabrics that span the two sites. This allows for data flow between
the two VPLEX clusters without requiring a merged fabric between the two sites.
Dual fabrics that currently span the two sites are also supported but not required. All
A4-FC02 and B4-FC02 ports from both clusters will connect to one fabric and all A4FC03 and B4-FC03 ports will connect to the other fabric. This provides a redundant
network capability where all directors communicate with all the directors on the other
site even in the event of a fabric failure.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
119
Appendix A: VS1
For GigE, all A5-GE00 and B5-GE00 ports will be connected through one Ethernet
network and all A5-GE01 and B5-GE01 ports will be connected through a second
Ethernet network over a different geographical path to prevent a single environmental
problem from taking out both networks.
120
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Glossary
Glossary
This glossary contains terms related to VPLEX federated storage systems. Many of
these terms are used in this manual.
A
AccessAnywhere The breakthrough technology that enables VPLEX clusters to
provide access to information between clusters that are separated by distance.
active/active A cluster with no primary or standby servers, because all servers can
run applications and interchangeably act as backup for one another.
active/passive A powered component that is ready to operate upon the failure of a
primary component.
array A collection of disk drives where user data and parity data may be stored.
Devices can consist of some or all of the drives within an array.
asynchronous Describes objects or events that are not coordinated in time. A process
operates independently of other processes, being initiated and left for another task
before being acknowledged. For example, a host writes data to the blades and then
begins other work while the data is transferred to a local disk and across the WAN
asynchronously. See also synchronous.
B
bandwidth The range of transmission frequencies a network can accommodate,
expressed as the difference between the highest and lowest frequencies of a
transmission cycle. High bandwidth allows fast or high-volume transmissions.
bias When a cluster has the for a given DR1 it will remain online if connectivity is lost
to the remote cluster (in some cases this may get over ruled by VPLEX Cluster
Witness). This is now known as preference.
bit A unit of information that has a binary digit value of either 0 or 1.
block The smallest amount of data that can be transferred following SCSI standards,
which is traditionally 512 bytes. Virtual volumes are presented to users as a
contiguous lists of blocks.
block size The actual size of a block on a device.
byte Memory space used to store eight bits of data.
C
cache Temporary storage for recent writes and recently accessed data. Disk data is
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
121
Glossary
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 do not have inconsistent versions in the different processors caches.
cluster Two or more VPLEX directors forming a single fault-tolerant cluster,
deployed as one to four engines.
cluster ID The identifier for each cluster in a multi-cluster deployment. The ID is
assigned during installation.
cluster deployment ID A numerical cluster identifier, unique within a VPLEX cluster.
By default, VPLEX clusters have a cluster deployment ID of 1. For multi-cluster
deployments, all but one cluster must be reconfigured to have different cluster
deployment IDs.
clustering Using two or more computers to function together as a single entity.
Benefits include fault tolerance and load balancing, which increases reliability and up
time.
COM The intra-cluster communication (Fibre Channel). The communication used for
cache coherency and replication traffic.
command line interface (CLI) A way to interact with a computer operating system or
software by typing commands to perform specific tasks.
continuity of operations (COOP) The goal of establishing policies and procedures to
be used during an emergency, including the ability to process, store, and transmit data
before and after.
Controller A device that controls the transfer of data to and from a computer and a
peripheral device.
D
data sharing The ability to share access to the same data with multiple servers
regardless of time and location.
detach rule A rule set applied to a DR1 to declare a winning and a losing cluster in
the event of a failure.
device A combination of one or more extents to which you add specific RAID
properties. Devices use storage from one cluster only; distributed devices use storage
from both clusters in a multi-cluster plex. See also distributed device.
122
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Glossary
director A CPU module that runs GeoSynchrony, the core VPLEX software. There
are two directors in each engine, and each has dedicated resources and is capable of
functioning independently.
dirty data The write-specific data stored in the cache memory that has yet to be
written to disk.
disaster recovery (DR) The ability to restart system operations after an error,
preventing data loss.
disk cache A section of RAM that provides cache between the disk and the CPU.
RAMs access time is significantly faster than disk access time; therefore, a diskcaching program enables the computer to operate faster by placing recently accessed
data in the disk cache.
distributed device A RAID 1 device whose mirrors are in Geographically separate
locations.
distributed file system (DFS) Supports the sharing of files and resources in the form
of persistent storage over a network.
Distributed RAID1 device (DR1) A cache coherent VPLEX Metro or Geo volume that
is distributed between two VPLEX Clusters
E
engine Enclosure that contains two directors, management modules, and redundant
power.
Ethernet A Local Area Network (LAN) protocol. Ethernet uses a bus topology,
meaning all devices are connected to a central cable, and supports data transfer rates
of between 10 megabits per second and 10 gigabits per second. For example, 100 BaseT supports data transfer rates of 100 Mb/s.
event A log message that results from a significant action initiated by a user or the
system.
extent A slice (range of blocks) of a storage volume.
F
failover Automatically switching to a redundant or standby device, system, or data
path upon the failure or abnormal termination of the currently active device, system,
or data path.
fault domain A concept where each component of a HA solution is separated by a
logical or physical boundary so if a fault happens in one domain it will not transfer to
the other. The boundary can represent any item which could fail (i.e., a separate
power domain would mean that is power would remain in the second domain if it
failed in the first domain).
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
123
Glossary
fault tolerance Ability of a system to keep working in the event of hardware or
software failure, usually achieved by duplicating key system components.
Fibre Channel (FC) A protocol for transmitting data between computer devices
Longer distance requires the use of optical fiber; however, FC also works using coaxial
cable and ordinary telephone twisted pair media. Fibre channel offers point-to-point,
switched, and loop interfaces. Used within a SAN to carry SCSI traffic.
field replaceable unit (FRU) A unit or component of a system that can be replaced on
site as opposed to returning the system to the manufacturer for repair.
firmware Software that is loaded on and runs from the flash ROM on the VPLEX
directors.
G
Geographically distributed system A system physically distributed across two or
more Geographically separated sites. The degree of distribution can vary widely,
from different locations on a campus or in a city to different continents.
Geoplex A DR1 device configured for VPLEX Geo
gigabit (Gb or Gbit) 1,073,741,824 (2^30) bits. Often rounded to 10^9.
gigabit Ethernet The version of Ethernet that supports data transfer rates of 1 Gigabit
per second.
gigabyte (GB) 1,073,741,824 (2^30) bytes. Often rounded to 10^9.
global file system (GFS) A shared-storage cluster or distributed file system.
H
host bus adapter (HBA) An I/O adapter that manages the transfer of information
between the host computers bus and memory system. The adapter performs many
low-level interface functions automatically or with minimal processor involvement to
minimize the impact on the host processors performance.
I
input/output (I/O) Any operation, program, or device that transfers data to or from a
computer.
internet Fibre Channel protocol (iFCP) Connects Fibre Channel storage devices to
SANs or the Internet in Geographically distributed systems using TCP.
intranet A network operating like the World Wide Web but with access restricted to a
limited group of authorized users.
124
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Glossary
internet small computer system interface (iSCSI) A protocol that allows commands
to travel through IP networks, which carries data from storage units to servers
anywhere in a computer network.
I/O (input/output) The transfer of data to or from a computer.
K
kilobit (Kb) 1,024 (2^10) bits. Often rounded to 10^3.
kilobyte (K or KB) 1,024 (2^10) bytes. Often rounded to 10^3.
L
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 area network (LAN) 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.
logical unit number (LUN) 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 device's unique address.
M
megabit (Mb) 1,048,576 (2^20) bits. Often rounded to 10^6.
megabyte (MB) 1,048,576 (2^20) bytes. Often rounded to 10^6.
metadata Data about data, such as data quality, content, and condition.
metavolume A storage volume used by the system that contains the metadata for all
the virtual volumes managed by the system. There is one metadata storage volume
per cluster.
Metro-Plex Two VPLEX Metro clusters connected within metro (synchronous)
distances, approximately 60 miles or 100 kilometers.
metroplex A DR1 device configured for VPLEX Metro
mirroring The writing of data to two or more disks simultaneously. If one of the disk
drives fails, the system can instantly switch to one of the other disks without losing
data or service. RAID 1 provides mirroring.
miss An operation where the cache is searched but does not contain the data, so the
data instead must be accessed from disk.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
125
Glossary
N
namespace A set of names recognized by a file system in which all names are unique.
network System of computers, terminals, and databases connected by communication
lines.
network architecture Design of a network, including hardware, software, method of
connection, and the protocol used.
network-attached storage (NAS) Storage elements connected directly to a network.
network partition When one site loses contact or communication with another site.
P
parity The even or odd number of 0s and 1s in binary code.
parity checking Checking for errors in binary data. Depending on whether the byte
has an even or odd number of bits, an extra 0 or 1 bit, called a parity bit, is added to
each byte in a transmission. The sender and receiver agree on odd parity, even parity,
or no parity. If they agree on even parity, a parity bit is added that makes each byte
even. If they agree on odd parity, a parity bit is added that makes each byte odd. If
the data is transmitted incorrectly, the change in parity will reveal the error.
partition A subdivision of a physical or virtual disk, which is a logical entity only
visible to the end user, not any of the devices.
plex A VPLEX single cluster.
preference When a cluster has bias the for a given DR1 it will remain online if
connectivity is lost to the remote cluster (in some cases this may get over ruled by
VPLEX Cluster Witness).
R
RAID (Redundant Array of Independent Disks) The use of two or more storage
volumes to provide better performance, error recovery, and fault tolerance.
RAID 0 A performance-orientated striped or dispersed data mapping technique.
Uniformly sized blocks of storage are assigned in regular sequence to all of the arrays
disks. Provides high I/O performance at low inherent cost. No additional disks are
required. The advantages of RAID 0 are a very simple design and an ease of
implementation.
RAID 1 Also called mirroring; this has been used longer than any other form of
RAID. It remains popular because of simplicity and a high level of data availability.
A mirrored array consists of two or more disks. Each disk in a mirrored array holds
an identical image of the user data. RAID 1 has no striping. Read performance is
improved since either disk can be read at the same time. Write performance is lower
126
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Glossary
than single disk storage. Writes must be performed on all disks, or mirrors, in the
RAID 1. RAID 1 provides very good data reliability for read-intensive applications.
RAID leg A copy of data, called a mirror, that is located at a user's current location.
rebuild The process of reconstructing data onto a spare or replacement drive after a
drive failure. Data is reconstructed from the data on the surviving disks, assuming
mirroring has been employed.
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.
reliability The ability of a system to recover lost data.
remote direct memory access (RDMA) Allows computers within a network to
exchange data using their main memories and without using the processor, cache, or
operating system of either computer.
Recovery Point Objective (RPO) The amount of data that can be lost before a given
failure event.
Recovery Time Objective (RTO) The amount of time the service takes to fully
recover after a failure event.
S
scalability Ability to easily change a system in size or configuration to suit changing
conditions, to grow with your needs.
simple network management protocol (SNMP) Monitors systems and devices in a
network.
site ID The identifier for each cluster in a multi-cluster plex. In a Geographically
distributed system, one clusters ID is 1, the next is 2, and so on, each number
identifying a physically separate cluster. These identifiers are assigned during
installation.
small computer system interface (SCSI) A set of evolving ANSI standard electronic
interfaces that allow personal computers to communicate faster and more flexibly than
previous interfaces with peripheral hardware such as disk drives, tape drives, CDROM drives, printers, and scanners.
split brain Condition when a partitioned DR1 accepts writes from both clusters. This
is also known as a conflicting detach.
storage RTO The amount of time taken for the storage to be available after a failure
event (In all cases this will be a smaller time interval than the RTO since the storage is
a pre-requisite).
stripe depth The number of blocks of data stored contiguously on each storage
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
127
Glossary
volume in a RAID 0 device.
striping A technique for spreading data over multiple disk drives. Disk striping can
speed up operations that retrieve data from disk storage. Data is divided into units
and distributed across the available disks. RAID 0 provides disk striping.
storage area network (SAN) A high-speed special purpose network or subnetwork
that interconnects different kinds of data storage devices with associated data servers
on behalf of a larger network of users.
storage view A combination of registered initiators (hosts), front-end ports, and
virtual volumes, used to control a hosts access to storage.
storage volume A LUN exported from an array.
synchronous Describes objects or events that are coordinated in time. A process is
initiated and must be completed before another task is allowed to begin. For example,
in banking two withdrawals from a checking account that are started at the same time
must not overlap; therefore, they are processed synchronously. See also
asynchronous.
T
throughput:
1.
2.
3.
tool command language (TCL) A scripting language often used for rapid prototypes
and scripted applications.
transmission control protocol/Internet protocol (TCP/IP) The basic communication
language or protocol used for traffic on a private network and the Internet.
U
uninterruptible power supply (UPS) A power supply that includes a battery to
maintain power in the event of a power failure.
universal unique identifier (UUID)
A 64-bit number used to uniquely identify each VPLEX director. This number is
based on the hardware serial number assigned to each director.
128
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
Glossary
virtualization A layer of abstraction implemented in software that servers use to
divide available physical storage into storage volumes or virtual volumes.
virtual volume A virtual volume looks like a contiguous volume, but can be
distributed over two or more storage volumes. Virtual volumes are presented to
hosts.
VPLEX Cluster Witness A feature in VPLEX V5.x that can augment and improve
upon the failure handling semantics of Static Bias Rules.
W
wide area network (WAN) A Geographically dispersed telecommunications network.
This term distinguishes a broader telecommunication structure from a local area
network (LAN).
world wide name (WWN) A specific Fibre Channel Name Identifier that is unique
worldwide and represented by a 64-bit unsigned binary value.
write-through mode A caching technique in which the completion of a write request
is communicated only after data is written to disk. This is almost equivalent to noncached systems, but with data protection.
Implementation and Planning Best Practices for EMC VPLEX Technical Notes
129
Glossary
130
Implementation and Planning Best Practices for EMC VPLEX Technical Notes