Symmetrix DMX & VMAX Devices Description

iEMC APJ Sep 28, 2013 7:34 PM

Symmetrix DMX & VMAX Devices Description
Introduction
Symmetrix Devices are the LUN created on physical hard disks which present to Host or Symmetrix array
internal usage. There are various types of devices in Symmetrix DMX & VMAX array. This document
indicates the description of various types of Symm Devices for open system. The devices described in
this document are categorized into five functional parts. They are Regular Device, Data Replication
Devices, Virtual Devices, Device Pool Devices and System Devices.
Detailed Information

Regular Device:
Standard Devices:Standard
volumes (STD) are configured for normal production operations. STD Devices are
presented through SAN to Host for block level data R/W operation. There is no device type of Standard,
but if a Symmetrix device is not one of any of the other Symmetrix Device types then it is considered to be
a Standard device.

MetaDevice allows
individual devices to be concatenated to create larger devices. The devices assigned in a
meta sequence do not need to be adjacent. The metahead is the first device in the metadevice and is
responsible for receiving incoming commands. When an incoming command for the metahead is
processed, the Enginuity software determines which metadevice member should execute the command.
Addressing of data contained in a metadevice can be organized in two different ways: 1. Concatenated
devices: Concatenated devices are volume sets that are organized with the first byte of data at the
beginning of the first device. 2. Striped devices: Metadevice addressing by striping divides each
metamember device into a series of stripes, addressing a stripe from each device before advancing to the
next stripe on the first device

Data Replications Devices:

BCV Devices: Business Continuance Volumes (BCV) is configured for TimeFinder/Mirror replication.

R1 and R2 Devices are configured for remote replication (SRDF is Symmetrix Remote Data Facility). An SRDF device group is a user-defined device group comprised of SRDF devices from a
single Symmetrix array. At the time of creation, a device group must be defined as type REGULAR, RDF1, RDF2, RDF21, or ANY, and may contain various device lists for standard, BCV,
virtual (VDEV), and remote devices. If the group type is defined as RDF1, RDF2, or RDF21, the group is considered an SRDF device group.

Possible dual-mirrored device types include the following:

R11: A concurrent R1 device with 2 R1 SRDF mirrors.

R21: An SRDF device with 2 SRDF mirrors. One an R2 mirror and the other an R1 mirror.
R22: A concurrent R2 device with 2 R2 SRDF mirrors.
Diskless Devices (DLDEV): Diskless devices are used for cascaded R21s. They are cache only devices and do not consume disk space.

Virtual Devices:
Virtual Device (VDEV):Symmetrix virtual devices are configured as full-size devices, but use minimal disk
storage on the back-end. On Symmetrix DMX & VMAX arrays, VDEVs reside in cache only and are
depicted as having no back-end hypers. The format must be FBA. Virtual devices can also be used to
form a VDEV metadevice. Other Symmetrix devices cannot be converted to form virtual devices. To
configure a virtual device, set config=vdev in the device file.
Thin devices (TDEV) are devices that may or may not have storage allocated to them when they are created. To
a host operating system, they look like regular devices with their configured capacity. The host treats
 them as regular devices and writes and reads from these devices like regular devices. Thin devices are
bound to a thin pool (of DATA devices).

Device Pool Devices:

Following devices are contained in storage pool using virtualization technology. There are three types of
device pools, Snap pools (contain SAVE Device), SRDF/A DSE pools, and thin pools (contain DATA
Device)：
SAVE Device: The
device will become part of a pool of devices that are used with TimeFinder/Snap for virtual
device Snap operations and SRDF/A DSE pool to extend the available cache space for SRDF/A
sessions. Symmetrix SAVE devices work in conjunction with virtual devices and can be unprotected. To
configure a SAVE device, set attribute=savedev in the request to create a new device.

The device will become part of a pool of devices that are used with thin devices for virtual
DATA Device:
operations. The Data Devices are grouped together into a storage pool called a Thin Pool. A Thin Device
must be bound to a Thin Pool before it can be used. This Thin Pool provides the shared storage. The
storage capacity in the Thin Pool can be shared among multiple hosts and applications
SAVE devices and DATA devices are created following the same procedure as for standard protected
devices, with the additional specification of attribute=savedev or attribute=datadev.

System Devices:
There are some devices which cannot be categorized to above four parts. They are only for Symmetrix
internal usage like configuration or data swapping:
DRV Device: Dynamic
Reallocation Volumes (DRV) devices are configured Symmetrix Optimizer and FAST
(Fully Automated Storage Tiering)

Gatekeeper are used for special communication that controls Symmetrix array, like
Gate Keeper Device (GK):
retrieving status, executing tasks.
============================================

eLicensing for Symmetrix VMAX and VMAXe.

created by Amita Wasson on May 9, 2012 5:38 AM, last modified by Amita Wasson on Oct 5, 2015 9:37 AM

Version 3

Product:
Symmetrix VMAX Series, Solutions Enabler 7.2, Solutions Enabler 7.3, Enginuity: 5874, Enginuity: 5875

Description:

eLicensing for Symmetrix VMAX and VMAXe.

Solution:
elicensing [“ELM”] is an end-to-end product/feature activation and management solution, delivered with Enginuity 5875 on Symmetrix VMAX systems that helps customers manage, track, and
comply with software license entitlement, leveraging embedded functions, and back-office IT systems and processes. This impacts all Customers installing new Symmetrix VMAX systems with
Enginuity 5875, or upgrading existing Symmetrix VMAX systems to 5875.

 Software purchased as part of a new VMAX system will result in creation of a license file that is posted on Powerlink for download by the customer. Processing of this license file (explained
below) is needed in order to activate titles for use. EMC personnel planning to install a new system must verify the existence and correctness of these files as part of the installation planning
process and should obtain them well ahead of the installation to avoid last minute problems.

 License files are updated for licensing of additional capacity, new titles, or for changes of circumstance such a move to an Enterprise License Agreement.

 Upgrading to Enginuity 5875 of existing Symmetrix VMAX Systems that already have licensed software titles in use, as part of the upgrade process, ‘grandfather’ those in-use features in order
to assure no operational disruption. However, such systems will not be reported as ‘entitled’ until the appropriate entitlements are obtained and applied via the elicensing process. For systems
upgrading from Enginuity 5874, the EMC account team must work with the LCT team in order to generate the file via Email. Send an email to LCT_admin@emc.com.
 EMC provides means for Customers to be fully capable of activating VMAX features via elicensing. However, if hardware installation is taking place, the appropriate EMC personnel may chose
A license key is not needed to increase capacity, the key is only needed
to activate any appropriate features or increases in entitlement capacity.
for proof of compliance and the upgrade can be purchased retrospectively. To add the additional disk storage physically in the system a
license file is not required by SymmWin.
 The elicensing process has been carefully designed to assure no impact to any existing Customer operational processes for any reason, including any maintenance or software
upgrades.

There are two means to generate a license file for a given Symmetrix VMAX:

 New purchase of a VMAX software was entered, either as part of a new system order or as some form of additional purchase to an existing system. – The EMC back office system produces a
single license file for that VMAX system. Note that there is always only one license file for a system, and that new products are added into an existing file.

 An upgrade of Enginuity from 5874 to 5875 is planned. In this case, the EMC account team should work with EMC Corporate to assure the generation of the appropriate license file.

A notification called a License Authorization Code (LAC) is sent via e-mail to entitled customers, one per array. This LAC letter contains the instructions on how to obtain the License
Activation file. If you do not have the LAC letter then the system Serial Number can be used in place of the LAC # on Powerlink.

For Solutions Enabler the following commands are used to apply/load a License file:

Symlmf add –type emclm –sid xxxx –file <Path_FileName> (for adding Symmetrix Array Based Licenses)

Symlmf add –type emclm –file <Path_FileName> (for adding Symmetrix Host Based Licenses)

Customers can see their license status using the Symmetrix Management Console (SMC) or using a Solutions Enabler CLI command. The report shows license type (raw capacity, registered
capacity, etc.), the amount of capacity licensed by disk drive type, and the amount of capacity in use by disk drive type.
To confirm the status via Command Line Interface, the following syntax is used:

Symlmf show –type emclm –sid xxxx (This command displays the license file that was last used for installation of licenses)

Symlmf query –type emclm –sid xxxx (This command displays the state of all licenses for a Symmetrix that were activated by the license file or were deemed "in-use" at the time of upgrade
from Enginuity 5874. In addition, it displays the current usage by license by the Symmetrix.

Symlmf list –type host (This command displays the Host Based Licenses)

In the SMC version released in June, 2011, the activation process for SMC was changed. This version no longer requires a Solutions Enabler key; it is eLicense activated.

 First, when using SMC versions released prior to V7.3, a ‘Solutions Enabler key’ (SE Key) must be applied to the Solutions Enabler installation for proper SMC operation. The format of the SE
Key is xxxx-xxxx-xxxx-xxxx.
With Solutions Enabler enter Symlmf and press return. Answer 'Y' to enter a License Key. Then enter the License Key for SMC.

 SMC 7.3, used with SE V7.3 (an SMC requirement), is used to manage Symmetrix running pre-5875.198.148, it works with or without the old “SE Key” for SMC (and without elicensing
activation).

 To activate specific array entitlements to be managed by SMC V7.3:

1. With a license file obtained before June, 2011, it will not have the SMC activation component required to enable an array running Enginuity 5875.198.148 to be managed by SMC 7.3. An
updated license file can be obtained by contacting EMC License Operations.
2. With a license file obtained after June 7, 2011, an updated license file is needed. The file will contain an SMC activation (if SMC was purchased). Version 7.2 of Solutions Enabler will not
process a License file with an SMC or ProSphere activation. The SMC and ProSphere component within the file must be manually deleted out of the file for successful processing. Do not edit
any other parts of the license file; activation errors will result.

Today all SRDF/DM functionality is available when SRDF/S or SRDF/A elicensing entitlements are sold. If a customer did NOT purchase an SRDF/S or SRDF/A entitlement and if they wish to
use SRDF/DM, the EMC personnel performing the migration need to know the following:
SRDF/DM is a physical configuration of SRDF that uses adaptive copy. An EMC technical person must be on site to configure the RDF Director to use during the migration. The act of creating
the RDF Director will cause SymmWin to indicate that there is no SRDF elicensing entitlement, and the EMC person must perform an override for the SYMM_SRDF license only (from within
SymmWin). Once the override is in place, the SRDF/DM functionality will be available. If SRDF was enabled for strictly SRDF-DM the override will be removed when the RDF directors are
removed from the configuration.

To add the additional disk storage physically in the system a license file is not required by SymmWin, but for the customer to use the additional storage capacity a new license file needs to
retrieve from Powerlink and loaded onto the system via SMC or Solutions Enabler.

Software license moves are not allowed between product generations. This includes DMX-3 to DMX-4, DMX to VMAX and VMAX to the next generation, etc. Customers cannot receive credit
on old licenses for new licenses.

=====================

These could appear to be quite basic questions, however taking into account that EMC does its best to cover its mechanisms with a shroud of magic, such questions become
quite understandable.

BCV is not RAID-1, right? Is it kind of a local synchronous replication mechanism from a source device (STD) onto a target device (BCV)?
What happens if a source device fails? Does BCV automatically replace anyhow the broken STD with itself? If not, what do we need to do with the BCV to replace the broken
STD with it? Or do we need to restore a BCV onto another STD in order to get a properly functioning STD?
Could you bring any handy examples of using BCV?
Why does a BCV device still have a logical BCV name (BCV001, for example) even after the split operation has been performed? Isn't it already a regular device and should be
treated as a regular device?

2-Way-Mirror is RAID-1 in terms of EMC? How data on a 2-Way-Mirror is redistributed across physical drives? Couldn't it happen that one physical drive stores blocks from both
parts of our mirror (the same blocks needed to provide data redundancy)?

What is 2-Way-BCV-Mir?
Can we use 2-Way-Mirrors and BCVs in a completely thin provisioned environment? Does Enginuity have
mechanisms ensuring that mirrored blocks of our hypothetical 2-Way-Mir+TDEV and BCV+TDEV do not reside on
the same physical drive? If so, how it can be useful and what are the steps of creating such devices?

Correct, RAID1, RAID5, etc are methods for providing basic protection for a data volume by spreading
elements of the data over multiple physical disks.

BCV (Business Continuity Volume) is a method for making a byte for byte copy of a running data volume
that can be mounted on another host and used independently of the source volume.

A BCV is a specific implementation of a "Local Copy". A long time ago the implementation of BCV was
bound up with mirroring protection; this is no longer the case although the terminology is often still mixed.
Nowadays the local mirror can be a complete standalone copy of the original on its own disk, a clone, or it
can be a snap copy only recording differences as changes are made to the source and the copy (target)
volume.

Typical uses of local snap and clone copies are to make copies of real databases for application testing
or for off-line backup.

For application testing with real world data a local copy is made and mounted on a test host during
testing, after testing the content of the copy is refreshed from the real database ready for the next series
of tests. A modern Symmetrix array will make the refresh appear instantaneous. The actual refresh is
incremental, only changed areas of the volume will be updated.

For backup a mirror copy of the production system is made and the backup is made from the copy later at
some appropriate time. If a backup is made directly from a production system it can slow the production
system for hours. The mirror takes a moment to refresh and the production system can continue its work
unimpeded. The backup made from the mirror disks can also be faster than a standard production backup
because the mirror volumes are not impeded by having to support production.

Gold Copy I: For creating a repeatable testing environment a mirror copy (gold copy) could be made of a
production database at a given point in time. Subsequently a work copy of the gold copy could be made
to run testing and, at the end of each test session the test copy could be refreshed from the "gold" copy
so that tests always begin from the same logical point in time.

Gold Copy II: before making changes/updates to a system make a local “Gold” copy. If the system fails
after the update for any reason, simply restore the original state of the system back from the gold copy.

Typically clones are to be preferred if the copy will be used intensively as the clone is independent of the
source volume.

Snaps make use of the real source volume to provide data that are not changed and their use has a
performance impact on the source and copy volumes. The benefit of the snap is that it saves disk space.

> What happens if a source device fails? Does BCV automatically replace anyhow the broken STD with
itself? If not, what do we need to do with the BCV to replace the broken STD with it? Or do we need to
restore a BCV onto another STD in order to get a properly functioning STD?

Typically the source device is protected by its own RAID protection, and the local copy will not be
required to provide low level protection against disk failure.

On the other hand, local mirrors are important as a rapid recovery mechanism for logical problems that
may occur in an application’s data.
If you make a local copy say four times a day and keep all four copies available in the array then, if an
event occurs in the application say due to a programming or other data corruption, then you will have four
backups that can be almost instantly brought on line to roll the system back to a previous point in time.

> Could you bring any handy examples of using BCV?

See examples above.

> 2-Way-Mirror is RAID-1 in terms of EMC? How data on a 2-Way-Mirror is redistributed across physical
drives?

Yes a 2-Way Mirror is another way of saying RAID1. When say a 10GB volume is created a 10GB volume
is created on one disk and another 10GB from another disk is linked to it to provide the full RAID1
protected volume.

> Couldn't it happen that one physical drive stores blocks from both parts of our mirror (the same blocks
needed to provide data redundancy)?

No - The software in the array ensures that the different copies of the data land on different physical
volumes.

Can we use 2-Way-Mirrors and BCVs in a completely thin provisioned environment? Does Enginuity have
mechanisms ensuring that mirrored blocks of our hypothetical 2-Way-Mir+TDEV and BCV+TDEV do not
reside on the same physical drive? If so, how it can be useful and what are the steps of creating such
devices?

In a modern Symmetrix system and certainly in the Thin environment forget about BCVs, the Local
Mirrors are simply thin volumes (TDEVs) used as local mirror devices, you don't need to think about 2-
way-mirrors and BCVs, etc.

The primary volumes and the local mirror volumes are protected by the underlying RAID protection in the
Thin Pool, R1, R5, and R6. The device level protection is determined by the RAID type chosen for the
TDATs, the Data Devices on which the Thin Pools are created.

As with creation of thick devices the array itself ensures that provisioning rules for creation of TDATs are
obeyed and that the data elements of a given device cannot be created on the same physical disk.

Before VMAX, a BCV could become a true mirror of a volume, and would occupy one of the 4 mirror
positions of the source volumes.

With the introduction of VMAX, we dropped the support for true BCVs in favor of TF Clones.

In a VP (thin) environment, the devices that are the source and the target don't have protection directly,
the pools they are allocation on have the protection, and in a FAST VP configuration, they could be on
more than one tier, and all could have different protections.

Symmetrix will not allow devices that protect each other on the drives to be on the same disk, or directors
where any single component failure will stop access to the volume.

BCV is an attribute placed on a device. So it could be RAID1 or RAID 5, or even unprotected. As quincy states, the
BCV mirror technology does not apply to VMAX. Since you are talking TDEV, TimeFiinder Mirror does not apply
to your situation. If you are still interested in the technology, you will find some good documentation in:
The EMC Solutions Enabler Symmetrix Timefinder Family CLI Product guide.

There are such words in the chapter 5 "Performing TimeFinder/Mirror Operations" (page 108):
 Once a BCV device is established as a mirror of a standard device, those two devices together are
referred to as a BCV pair. The pair consists of two types of mirrors: the standard device mirror(s) and the
BCV mirror.
The standard device mirrors contain copies of the data contained in their associated standard devices.
There can be up to three standard device mirrors (M1, M2, M3).
A BCV mirror is a standard device mirror. It can be a two-way mirror (M1, M2) that is assigned upon
creation of the BCV pair.

I can't get the idea. How come the source device becomes a mirror and contains copies of the data
contained in their associated standard device? I thought as a replication/clone source it should be just a
source with original blocks of data (not some sort of copies of the original blocks).
Also why a 1-Way-Mirror is called "Unprotected"? For me it looks like data is replicated from one source
(STD) onto one target (BCV). Appears to be quite protected.
3-Way-Mirror is one STD and 3 BCV devs, right?

When a BCV Establish is performed in a Timefinder mirror operation, a mirror position of the BCV moves
into one of the available mirrors of the standard device. Data will then flow to the BCV mirror from the
standard until they are in synch. A Timefinder SPLIT will remove the BCV mirror from the STD device.
If the BCV was created as unprotected,if there is a drive failure where the BCV mirror lives (when the
BCV is in SPLIT state), you just lost your data.
If the BCV was created as 2-way-mir though, once the SPLIT is done, the BCV then starts to mirror the
mirror position that was attached to the STD, over to the second BCV mirror. When this is complete, you
have a protected BCV. i.e. a single drive failure will not cause you to loose your BCV image.
While devices have 4 mirror positions available, not every mirror position needs to be occupied. Any 3 of
the 4 mirror positions can be used as 'floating mirrors'. That is, they can be occupied dynamically, such as
in a BCV establish. This is why it talks about 3 mirror positions in the graphic.

====================

Monitoring Symmetrix Performance using symstatCLI

Introduction
This article describes how to use the Solutions Enabler command symstat to view the performance
statistics of Symmetrix Array. The symstatcommand captures, in real-time, statistics information about a
Symmetrix array.
Detailed Information
The symstat command performs the following features:
 Retrieves the performance counts for the Symmetrix array as a whole
 Retrieves the performance counts for a Director or Director Ports
 Retrieves the performance counts for Symmetrix devices
 Retrieves the performance counts for Device Group, Composite Group, RDF Group

The symstat command provides different types of performance display options:

 REQUESTS - Reports I/O requests and throughput for selected devices, directors, or SRDF/A sessions.
(This is the default type; if no type is specified, REQUESTS is used.)
 BACKEND - Reports back-end I/O requests and throughput for selected devices.
 PORT - Reports performance statistics for a director port.
 ISCSI - Reports GigE network statistics.
 CACHE - Reports cache activity for selected front-end or remote link directors, or SRDF/A sessions
 MEMIO - Reports cache memory to disk activity for selected devices.
 CYCLE - Reports cycle summary information for SRDF-A sessions
 DISK - Reports back-end I/O requests and throughput for selected disks.
 PREFETCH - Reports track prefetch disk activity for selected back-end directors only.
 RDF - Reports SRDF statistics from the perspective of RA groups, devices, or directors.
 DMSP - Reports dynamic mirroring service policy (DMSP) statistics for the selected device(s).

Command Examples:

1. Array Performance Statistics. I/O and throughput statistics can be returned for all devices on a
specific array by specifying the Symmetrix ID by -sid, specifying the interval by –iand the number of
samples (counts) by –C. ( Symmetrix ID = 250, counts = 100, interval = 60 in following example)
symstat-type REQUEST -sid 250 -i60 -c 100
In command output, IO/Sec READ/WRITE are Read/Write IOPS, KB/Sec READ/WRITE are Throughput per
second.

2. Device Performance Statistics. symstat can display performance statistics such as I/O requests via
front-end adapters and throughput on devices. For example, for sample intervals of 120 seconds and
a sample count of 3 on logical device DEV001 in device group prod_r1, use command:
symstat -i 250 -c 3 -g prod_r1 -ld DEV001

3. Device BACKEND Statistics. Using symstat with the BACKEND type specified,you can display
performance statistics such as I/O requests using a DA (back-end director) and throughput on a
device.
symstat-type BACKEND -i 60 -c 3 -g prod_r1 -ld DEV001

4. Director I/O requests. symstat can display the I/O requests and throughput activity performance
statistics on any or all directors.
symstat-type REQUESTS -sid 250 -dir ALL -i60 -c 100
Specifying single director, use following command:
symstat-type REQUESTS -dir 7b -sid 250 -i10 -c 100
In command output, IO/sec is IOPS which summarize Host to Front-end directors, disk to Back-end
directors, local to Remote link directors. RW is Total read/write cache request rate.

5. Director ports performance statistics. Using symstat with the PORT type specified, you can display
performance statistics such as I/O requests (IO/Sec) and throughput (Kbytes/Sec) of director ports for a
specific Symmetrix array. For example, for sample intervals of 60 seconds, and a sample count of 3
(for I/O requests and throughput) on Symmetrix 250 all director ports:
symstat -i 60 -c 5 -type PORT -sid 250 -dir ALL
Specifying single director port, use following command:
symstat-type REQUESTS -dir 7b -sid 250 -i10 -c 100

6. MEMIO performance statistics. Using symstat, you can display performance statistics, such as cache
memory to disk I/O on particular device group. For example, enter
symstat-type MEMIO -sid 250 -i 60 -c 100
In command output, WP Tracks are the count not yet destaged to disk.Prefchd/DestgdTracks/SecareTracks per
second pre-fetched from disk to cache upon detection of a sequential read stream and
Tracks per second saved into disks. %Dev WPmax is Write-pending device limit percentage which
defined on VMAX system level.

7. Disk performance statistics. Using symstat with the DISK type specified, you can display performance
statistics, such as I/O requests and throughput on a physical disk. For example, for sample intervals
of 60 seconds and a sample count of 3 on disk 02A:C5, enter:
symstat-type disk -i 60 -c 3 -sid250 -disk 2a,C,5
For all SCSI IDs on DA 02A, interface C, use command:
symstat-type disk -i 60 -c 3 -sid250 -disk 2a,C,ALL

8. SRDF performance statistics. The SRDF type statistics extend the statistical information provided
by the SRDF director to external applications providing greater visibility into the performance and
behavior of Symmetrix arrays in the field. These statistics can be used to monitor on-going activity
and to analyze problematic behavior.
To return statistics for all RA group numbers, specify all, use command:
symstat -sid 250 -i 60 -c 2 -type RDF -rdfg 11
For example, to return SRDF device-level statistics for device 37, use command:
symstat -sid 250 -i 60 -c 2 -type RDF -dev 37
To return SRDF director level statistics, use command:
symstat -sid 250 -i 60 -c 2 -type RDF -dir 1d
To return link-level details, specify the -rdflink option as shown in the example below command.
symstat -sid 250 -i 60 -c 2 -type RDF -dir 2c –rdflink
For more command symstatcommand example, you can refer EMC Solutions Enabler Symmetrix Array
Management CLI Product Guide on support.emc.com