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


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=[cyl]]

[, 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 = ]

[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

Documents