VMAX Meta Device Symmetrix and Device Attributes

Copyright 2012 EMC Corporation.
All rights reserved

Upon completion of this module, you should be able to:
Form and Dissolve Meta volumes
Set Port Characteristics
Set Device Attributes
Create Dynamic RDF Groups and Pairs
Set RDF Group Attributes
Manage Device Pools
1 Module 4: Symmetrix and Device Attributes
Copyright 2012 EMC Corporation. All rights reserved
Upon completion of this lesson, you should be able to:
Describe Concatenated and Striped Meta Volumes
Describe the Symmetrix Auto-Meta feature
Form and Dissolve Meta volumes
Module 4: Symmetrix and Device Attributes 2
A meta device is a Symmetrix mechanism for defining a device larger than the current
maximum hyper-volume size. You can concatenate existing devices to form a larger meta
device that is presented to the host as a single addressable device.
There are two kinds of meta devices - concatenated and striped:
On a concatenated meta device, the addressing of data continues to the end of a
device before any data on the next device is referenced.
On a striped meta device, data on meta members is addressed in user-defined stripes
or chunks instead of first filling an entire volume before addressing the next volume.
The meta head is the Symmetrix device that is recognized by the host and used for
performing I/O. By default, the stripe size of a striped meta is 1920 512 blocks or 960 KB.
Striped meta volumes perform better than concatenated meta volumes when there are
enough spindles to support them. However, if the striping leads to the same physical spindle
hosting two or more members of the meta volume, striping loses its effectiveness. In such a
case, using concatenated meta volumes is better.
It is not a good idea to stripe on top of a stripe. Thus, if host striping is planned and meta
volumes are being used, concatenated meta volumes are better.
Since Thin Devices are striped across the back-end, there is usually no need to use striped
metadevices with Virtual Provisioning. However, there may be certain situations where
better performance may be achieved using striped metas.
With Synchronous SRDF, Enginuity allows one outstanding write per Thin Device per path.
With concatenated metadevices, this could cause a performance problem by limiting the
concurrency of writes. This limit will not affect striped metadevices in the same way because
of the small size of the metavolume stripe (1 cylinder or 1920 blocks).
Symmetrix Enginuity has a logical volume write pending limit to prevent one volume from
monopolizing writeable cache. Because each meta member gets a small percentage of
cache, a striped meta is likely to offer more writable cache to the meta volume.

For a detailed description of the restrictions and other considerations, consult the Array
Control Guide.
Metadevices can be created using symconfigure or they can be automatically created using
Solutions Enabler 6.5.1 or higher. The syntax for forming metavolumes is:
form meta from dev SymDevName, config=MetaOption
[, stripe_size=<MetaStripeSize>[cyl]]
[, count=<member_count>];

The stripe size parameter is not used for Enginuity versions 5669 and later. It is always 1
cylinder or 1920 blocks.

The syntax for enabling automatic metadevice creation is:
set symmetrix [auto_meta = <ENABLE|DISABLE>]
[min_auto_meta_size = n [MB | GB | CYL]]
[auto_meta_member_size n [MB | GB | CYL]]
[auto_meta_config = [striped | concatenated | NONE]];
The first two settings are self explanatory. The auto_meta_member_size is the default
member size when metavolumes are automatically created. The min_auto_meta_size
specifies the size threshold that triggers auto_ meta creation. When users try to create a
device greater than min_auto_meta_size, and auto_meta is enabled, a meta will be created.
To enable automatic metadevice creation:
auto_meta parameter must be enabled;
auto_ meta_config must be set to striped or concatenated;
auto_meta_member_size must be changed from 0 to a valid size;
min_auto_meta_size should be set to a value chosen by the user.

This example shows how to enable the auto-meta feature for a Symmetrix. Both the SYMCLI
Syntax and the SMC dialog are shown.
Thin Devices can be formed into meta devices. Metadevices made from thin volumes are
created using the same syntax as metadevices from regular volumes. Thin metadevices must
be created before the Thin Devices are bound to a Thin Pool. If an attempt is made to form a
metadevice from bound metadevices, the command will fail.
Here we create a 2-member concatenated meta. As discussed earlier, thin concatenated
metadevices are more frequently used than thin striped metadevices.
Since Thin Devices are striped on the back-end, there is no reason for using striped
metadevices.
The output of symdev show on this and the next slide shows the properties of a thin meta
device. There is also no back-end information on the device.

There is also no back-end information on the device because this is a Thin device.

The meta can be bound to a pool and made available for use by mapping and masking the
meta head (not shown here). While the initial meta creation had to be done before the Thin
Devices were bound, later additions to the meta can be done while the metadevice is bound.
Here we see that 24 tracks are allocated because device 251 is a meta volume with a total of
two members.
Here we extend the metadevice created earlier by two more members and doubling the
capacity. Since all the storage shows up under the meta head, which was already mapped
and masked, the additional storage can be made available to the host using the meta with a
minimum of disruption.
Note that the 4 member meta has an allocation of 48 tracks or 12 tracks per meta member.
To create FBA Meta Devices in SMC, right-click on a Symmetrix and choose FBA Meta Device
Configuration, then choose Form Meta.
On VMAXe arrays this dialog can be used to create Meta devices with thin devices. The Meta
Configuration can be Concatenated or Striped.
In this example, we are creating a Striped Thin meta device.
Highlight the devices that should form the meta from those listed in the unmapped devices
list and click Add. This moves the devices to the Meta members column. The meta head
can then be specified. As with all configuration tasks, click on the Add to Config Session List
button. The actual commit of this action is done from ConfigSession view.
When creating a meta, you can optionally use the Auto Select feature. This allows you to
specify only the number of metas, number of meta members per meta, and the meta heads;
the Symmetrix microcode automatically chooses the meta members from the available pool
of unmapped devices.

Dissolving metavolumes frees up the members and makes the data unavailable to hosts that
were accessing the data.
All the caveats discussed in the previous slide for dissolving meta devices also apply to SMC.
To dissolve a meta device, highlight the desired meta device or devices and then choose FBA
Meta Device Configuration > Dissolve Meta.
This will launch the dialog shown on the right of the screen.
Remember that all data on the meta device will be lost when the meta is dissolved.
Click Add to Config Session List. The task can be committed from the Config Session view.

Set Port Characteristics
Set Device Attributes
Setting front-end port flags allows the FA port to be compatible with different types of hosts
and fibre topologies. The Common Serial Numbers, SCSI3 and SPC2 Protocol version are used
across a variety of platforms. Volume set addressing is used by HP-UX hosts.
Front-end port flags can be overridden by the setting of HBA flags by using the symaccess
command.
To use auto provisioning groups on Symmetrix VMAX, the ACLX flag must be enabled on the
port.
Browse to E-lab navigator, which can be accessed through Powerlink. Select the tab titled
PDFs and Guides. There youll find PDF copies of the support matrix for each operating
system and for the Symmetrix VMAXe Series with Enginuity. In the section under Bit/Flag
information, you can find the recommended port settings.
The example here shows an excerpt from the E-lab Navigator Support Matrix for Microsoft
Windows 2003 [x86].
The output of the symcfg command shows the port settings for the port to which the
Windows host is connected.
SMC can be used to view the current port settings. The properties view of a front-end port
will show the attributes that are currently set. Many of these port attributes can be changed
by SMC.
To set Port Attributes in SMC:
Right-click on a Symmetrix Port, choose Port and Director Configuration and then Set Port
Attributes to launch the dialog shown. Make the desired change and click Add to Config
Session List. This will list the task in the Config Session view from where the action can be
committed.
Port flag setting can be set via SMC or SYMCLI.

A Symmetrix device can have a number of attributes that can be set at device creation time.
The attributes described here are documented in Chapter 1 of the Array Controls Guide.
CKD_META volumes are the equivalent of striped meta volumes in the Mainframe
world. Not applicable to VMAXe Arrays.
Save devices provide the storage for TimeFinder Snap. When an application writes to
a TF/Snap Virtual device, the data is stored on the save device. Save devices are also
used as temporary storage to handle overflow data when an RDF/A delta set runs out
of space in cache memory.
Datadevs are the repository for data written to Thin Devices.
The SCSI_3 persistent reservation attribute, sometimes called the PER bit, is used by a
number of Unix cluster products such as Veritas and Sun.
The ACLX flag is set on a device, which acts as a gatekeeper to the auto provisioning
information that resides on the Symmetrix file system. There is only one ACLX device
per Symmetrix. In addition, ports have to have the ACLX flag enabled to participate in
autoprovisioning.
The dynamic RDF attributes allow a device to be configured as a dynamic R1 only
(dyn_rdf1), dynamic R2 only (dyn_rdf2), or dynamic RDF1 or RDF2 device (dyn_rdf).
Except under special circumstances, most devices are assigned the dyn_rdf flag.
The attributes shown here can be assigned to a device after device creation.
There are a number of other attributes that can be set on DMX devices but have been
discontinued in 5874.
To change device attributes in SMC, highlight the desired device or devices, right-click, and
then choose Device Configuration >Set Device Attributes. This will launch the Device
Configuration Set Device Attributes dialog.
The following devices attributes can be changed:
Emulation: Only allowed for FBA devices (change between supported FBA types)
SCSI 3 Persistent Reservation
Click the Show Current Values button to see the attributes that are currently set on the
devices.
Set the desired attribute and then click Add to Config Session List. The task can be
committed from the Config Session view.

Note that if a Symmetrix VMAXe is setup for SRDFe all thin devices are automatically
Dynamic RDF capable.

Create Dynamic RDF Groups and Pairs
Set RDF Group Attributes
Dynamic RDF groups can be created between two Symmetrix arrays that are zoned together
through a fiber or Gig-e switch. Creation and removal of the groups can be done quickly
through the use of the symrdf command and do not require intervention from an EMC
customer services engineer.
Dynamic RDF Configuration State is Enabled by default for Symmetrix VMAX/VMAXe arrays.
Symmetrix devices can have an attribute set on them which enables them to become a R1,
or a R2.
The combination of the ability to dynamically create SRDF groups and the dynamic device
attribute enables one to create, delete, and swap SRDF R1-R2 pairs.
SRDF groups define the relationships between the local Symmetrix SRDF director/ports and
the corresponding remote Symmetrix SRDF director/ports.
Any Symmetrix device that has been configured as an SRDF device must be assigned to an
SRDF group. It would be convenient if the SRDF group numbers on the local and the remote
Symmetrix are identical, however, this is not a requirement.
Static SRDF groups can be explicitly configured in the Symmetrix bin file. Storage
Administrators can dynamically create SRDF groups and assign them to Fibre Channel
directors or GigE directors.
Dynamic SRDF group information is not written to the Symmetrix bin file, but they are
persistent through power cycle and IMPL. Symmetrix SRDF groups are also referenced as RA
groups or RDF groups.
Before creating a new SRDF group, some information needs to be gathered. First we need to
know SRDF directors that are configured on the Symmetrix. We also need to know the
number of SRDF groups (RA groups) currently configured and their corresponding group
numbers. Symmetrix VMAXe arrays with Enginuity 5875 can support up to 32 SRDF groups.
The symrdf addgrp command creates an empty Dynamic SRDF group on the source and the
target Symmetrix and logically links them.
Note: that the physical link connectivity and communication between the two Symmetrix
must exist for this command to succeed.
Note: that the SRDF group number in the command is in decimal. In the Symmetrix it is
converted to hexadecimal. The decimal group numbers start at 01 but the hexadecimal group
numbers start at 00. Hence the hexadecimal group numbers will be off by one.

To create a Dynamic RDF Group via SMC, right click on a Symmetrix and then choose
Replication > SRDF Configuration > Create SRDF Group.
This will launch the dialog shown on the slide. Choose the desired Communication protocol
Fibre Channel or GigE, and enter an RDF group label. Choose a Remote Symmetrix ID, enter
the desired RDF group number for both the source and remote Symmetrix arrays. Choose the
RDF directors that will be part of this group and then click on OK to create the RDF Group.
The new RDF group will appear in the tree panel under the Symmetrix array as shown on the
slide.
The attributes assignable to RDF groups are shown here. We will discuss some of these
attributes in more detail in the SRDF lecture modules.
1. minimum_cycle_time The minimum time to wait before attempting an SRDF/A cycle
switch. Values range from 5 to 59 seconds.
2. rdf_hw_compression Specifies whether the hardware compression feature is enabled.
RDF hardware compression is only supported on RDF groups that are defined on GIGE
directors. Although you can enable/disable RDF hardware compression on the R2 side, the
setting of RDF hardware compression on the R1 side is what enables or disables the feature.
3. rdf_sw_compression Specifies whether the software compression feature is enabled.
This feature can be enabled for Asynchronous and Adaptive Copy mode.
4. rdfa_devpace_autostartSpecifies whether the SRDF/A device-level pacing feature is
automatically enabled when an SRDF/A session is activated for the RDF group.
5. rdfa_dse_autostart Specifies whether SRDF/A Delta Set Extension (DSE) is automatically
activated when SRDF/A session is activated for the group. Valid values are ENABLE or
DISABLE. DISABLE is the default.
6. rdfa_dse_pool The name of a collection of SAVE devices used for SRDF/A DSE.
1. rdfa_dse_threshold Specifies the percentage of the Symmetrix arrays write pending
limit. Once the cache usage of all active groups in the Symmetrix array exceeds this limit,
data tracks for this group start to spill over to disks. Valid values are from 20 to 100. The
default value is 50.
2. rdfa_transmit_idle Indicates whether this group has transmit idle support enabled.
3. rdfa_wpace_delay Specifies the maximum host I/O delay that the SRDF/A write pacing
feature will cause. The value is specified in microseconds; the allowable values are from 1 to
1000000 (1 sec). The default value is 50000 usecs (50 ms).
4. rdfa_wpace_threshold Specifies the minimum percentage of the system write pending
cache at which the Symmetrix array will start pacing host write I/Os for this RDF group. The
allowable values are from 1 to 99 percent. The default value is 60%.
5. rdfa_wpace_autostart Specifies whether the SRDF/A write pacing feature is
automatically enabled when an SRDF/A session is activated for the RDF group.
6. session_priorityThe priority used to determine which SRDF/A sessions to drop if cache
becomes full. Values range from 1 to 64, with 1 being the highest priority (last to be
dropped).
For more information on these parameters, and those seen in the SRDF displays, consult the
SRDF Connectivity Guide P/N 300-003-885 REV A07.
Above are a few examples of setting RDF attributes using the symconfigure command. For
the complete syntax on setting RDF attributes, refer to Chapter 1 of the Array Controls Guide.
To set SRDF Group Attributes in SMC, right click on the SRDF Group and choose Replication >
SRDF Configuration > Set SRDF Group Attributes.
Make the necessary changes and then click OK.
Dynamic RDF devices can only exist in a Symmetrix that has the Dynamic RDF feature
enabled. They can be created to be RDF1 capable, RDF2 capable, or RDF1 or RDF2 capable.
On VMAXe arrays all thin devices are R1 and R2 capable by default.
Dynamic RDF pairs can be created or deleted using the symrdf command. They can belong to
static or dynamic RDF groups.
Dynamic RDF pairs can also be created using SMC. The SRDF modules will cover these topics
in more detail.
The symdev show command will display the field shown below for Dynamic capable devices:

Dynamic RDF Capability : RDF1_OR_RDF2_Capable
The symrdf createpair command takes the dynamic capable device pairs listed in a text file
and makes them R1-R2 pairs.

Creating dynamic SRDF pairs with establish - Optionally, you can include the establish
operation in the createpair command line by replacing the -invalidate r2 option described
earlier with the establish option, where the default copy path is R1 to R2 for all the device
pairs:
symrdf createpair -file pairs.txt -sid 80 -type RDF1 -rdfg 5 -establish

Creating dynamic SRDF pairs with restore - One can perform a restore operation to copy
data back to the R1 source devices by including the -restore option in the createpair
command line as follows:
symrdf createpair -file pairs.txt -sid 80 -type RDF1 -rdfg 5 -restore

Creating dynamic SRDF pairs and not bring up the SRDF links - Invalidate, allows creation of
dynamic SRDF pairs, but does not bring up the SRDF links and initiate data copy:
symrdf createpair -file pairs.txt -sid 80 -type RDF1 -rdfg 5 invalidate
The symrdf createpair command takes the dynamic capable device pairs listed in the text file
(pairs.txt) and makes them R1-R2 pairs.
The newly created R2 devices are synchronized with the data from the newly created R1
devices. In this example, the file contains the following entries:
pairs.txt
55 55
56 56

The file contains the listing of the pairs of devices that should be changed to R1-R2 pairs. The
first column lists the devices on array with sid 265 and the second column lists the
corresponding devices on the remote array. In the examples shown, the type is specified as
RDF1, devices 55 & 56 on sid 265 and become R1s and devices 55 & 56 on the remote array
becomes R2s.

The delete SRDF pairs command cancels SRDF pairs in the device file specified. For example,
to delete the SRDF pairs in an RDF group 5, enter:
c:\symrdf suspend -sid 97 -file grp5.txt -rdfg 5
c:\symrdf deletepair -sid 97 -file grp5.txt -rdfg 5
Before the delete pair can be invoked the pair must be suspended first.
To create Dynamic RDF pairs in SMC, right click on a Symmetrix and then choose Replication
> SRDF Configuration > Add SRDF Mirror.
In the Add SRDF Mirror dialog, choose the RDF Mirror Type (R1 or R2), RDF Mode, RDF
Group. Then choose the devices that will form the RDF pairs.
Starting the RDF data copy in also an option.
Manage Device Pools
There are two kinds of Device Pools supported by Symmetrix VMAXe. DSE Pools contain Save
Devices. Thin Pools contain Data Devices, which cannot be used in RDF DSE pools.
Thin Pools were covered in more detail in the section on Virtual Provisioning.
The maximum number of pools a Symmetrix can support is 512.
Please note that TimeFinder/Snap is not applicable to VMAXe arrays. Hence snap pools are
not supported in VMAXe arrays.

Since SRDF devices can belong to a variety of operating systems with different emulations,
the DSE pools used with SRDF can contain any one of four kinds of device emulations. Each
DSE pool can hold only one kind of device emulation.
The new pool name must adhere to the same naming restrictions as when creating a pool.
Only one pool can be operated on in a session (or command file). Therefore, only one pool
can be re-named in a session.
In a single command file that includes operations on a pool and a pool re-name, you can:
Use the old pool name for the pool operations and re-name the pool as the last
operation.
Re-name the pool as the first operation and use the new name for the subsequent
pool operations.
Thin and DSE pools can be renamed; however, the default pool name (DEFAULT_POOL) for
snap cannot be changed.
Note that VMAXe does not support the use of Snap pools, because TimeFinder/Snap is not
supported on VMAXe arrays.
You cannot create and re-name a pool in the same session.
SMC can be used to create Snap (Not applicable to VMAXe), SRDF/A DSE and Thin Pools.
Right click on a Symmetrix (or the Pools folder under a Symmetrix) and choose Device Pool
Management > Create Device Pool. This will launch the Device Pool Management Create
Device Pool dialog shown on the slide.
Enter a name, choose the pool type (Snap, SRDF/A DSE or Thin). For Thin Pools the maximum
subscription limit can set. Optionally one can add Save or Thin Devices (based on the Pool
Type) to the pool and enable them. To add devices to the pool, pick the devices from the
Available column and click the Add button to move them the Target column. The Available
column will show Save or Data devices based on the Pool Type. Only disabled Save/Data
devices will be shown.
In addition to creating device pools, SMC can also be used to execute the pool management
tasks listed on the slide.
Devices have to be disabled before they can be removed from a pool. To execute any of
these activities. right click the specific Device Pool and then choose Device Pool
Management > then choose one of the tasks listed on the slide.
Many of the tasks listed here are relevant to Virtual Provisioning. Some which were covered
in Module 3 and others which will be covered in Module 6.
Key points covered in this module:
Meta Devices
Port Characteristics
Device Attributes
Dynamic RDF Groups and Pairs
RDF Group Attributes
Device Pools
1. See slide 3-5
2. See slides 7-9
3. See slides 21-22
4. See slides 26, 27
5. See slide 27
6. See slide 30
7. See slides 30, 32
8. See slide 41
9. See slide 46
10. See slide 46

VMAX Meta Device Symmetrix and Device Attributes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VMAX Meta Device Symmetrix and Device Attributes

Uploaded by

Copyright:

Available Formats

Copyright 2012 EMC Corporation.

All rights reserved

You might also like