Symm CFG MGT 5.2

Module title, 1
Symmetrix Configuration Management

Revision 1.2 July 2004
EMC Global Education

2004 EMC Corporation. All rights reserved.
Copyright 2004 EMC Corporation. All Rights Reserved.
Module title, 2
Revision History
Rev Number
1.0 1.1 1.2
Course Date
July, 2002 December, 2003 July, 2004
Revisions
Complete
Complete

Copyright 2004 EMC Corporation. All rights reserved. These materials may not be copied without EMC's written consent. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC, Symmetrix, CLARiiON, Cellera, PowerPath, SRDF and TimeFinder are registered trademarks, and EMC ControlCenter, EMC Snap, Access Logix, and Connectrix are trademarks of EMC Corporation. All other trademarks used herein are the property of their respective owners.
Module title, 3
Symmetrix Configuration Management

After completing this course, you will be able to: State the fundamental concepts associated with Symmetrix configuration management Perform Symmetrix configuration changes using the command line interface Perform Symmetrix configuration changes using the ControlCenter GUI

Module title, 4
Module 1: Configuration Management Fundamentals

After completing this module, you will be able to: State the fundamental concepts associated with Symmetrix configuration management

Module title, 5
Configuration Manager Introduction

Storage requirements are never permanent. Your needs for storage are most likely to grow over time. Consequently, the ability to utilize free disk space on your Symmetrix unit to create new storage devices makes the SYMCLI Configuration Manager a practical tool in expanding your storage capabilities. You can add many different types of devices to your Symmetrix configuration, such as devices with various mirroring schemes, static RDF devices, dynamic RDF devices, meta devices, BCVs, and DRVs. You can also reserve physical disks as dynamic spares that can be invoked against a failed disk. The Configuration Manager also allows you change an existing device to a different type of device if you decide that a device needs to perform a different role, needs additional mirror protection, or needs to have RDF attributes added or removed. Being able to reconfigure existing devices is useful as your storage requirements and device protections continue to evolve. You can reserve a number of disks as dynamic spares. The dynamic spare disk is held in reserve to support the devices of a Symmetrix disk that fails. When a disk fails, the dynamic spare disk is invoked against the failed disk.
Module title, 6
Customer Value

In the past, an EMC customer could have waited several days for a bin file change. Using Configuration Manager, a customer can perform a configuration changes within several minutes to hours. The time needed to perform a configuration change depends on the type of change and the equipment being used. By creating new devices, you can also increase storage capabilities. Using the unmapping and mapping features, disk storage can be moved among hosts. Changing the device configuration of a BCV to a mirrored device is an example of the new ability to manipulate configurations.
Module title, 7
Capabilities

Using SYMCLI and the ControlCenter console, you can perform configuration control operations on Symmetrix devices, meta devices, BCV devices, standard devices, DRV devices, device groups, and director ports. For each type of configuration change operation, there are Symmetrix and host system impacts that you will need to consider. Therefore, using Configuration Manager is not as simple as learning new commands. To ensure effective configuration changes, you will need to plan for any of these functions.
Module title, 8
Requirements

The minimum requirements for Configuration Manager are Solutions Enabler 4.2 or greater, Symm 4, 4.8, 5, 5.5, DMX or later, Microcode 5x66 or greater, and at least one visible gatekeeper. A license key is required to use the symcli symconfigure command. The ControlCenter base license enables configuration changes via the ControlCenter console. The command line license is not required to make configuration changes via the GUI. It is important to note that the particular version of software, microcode, and even the Symmetrix model will influence the types of configuration changes available. When preparing for configuration changes one of the first steps is to ensure the versions of software and microcode will support they types of changes you plan to implement.
Module title, 9
Creating New HVEs

For the configuration change session, you must define a set of changes within a specified command file. Each type of Symmetrix configuration change is considered a Class of Change. Multiple changes can be made in one session, but all changes must fall into one operation class. Beginning with Enginuity version 5669, changes for multiple operation classes can be executed within the same session. Creation of certain device (configuration) types may require more than one class of command execution. The following is an overview of each class of change. All classes will be discussed in detail in the next module. The first class of change is creating new hyper volume extensions (HVEs) which creates new Symmetrix devices. There must be available, unconfigured disk space in the Symmetrix to create new HVEs.
Module title, 10
Deleting HVEs
0000 0014
Free Space
0020 00CB

10
You can delete one or more Symmetrix devices from the specified Symmetrix array. Deleting a device frees the space that it once occupied for future use.
Module title, 11
Mapping and Unmapping Devices

11
Mapping devices to ports assigns HVEs to Symmetrix front-end ports, making devices addressable to attached hosts (zoning and device masking must be done separately). A valid host address must be assigned to each device when mapping. Unmapping removes devices from front-end ports making devices unavailable to attached hosts.
Module title, 12
Manage Meta Devices

12
Meta device handling allows you to form and dissolve meta devices, add and remove meta members, convert concatenated meta devices to striped meta devices and vice versa, and modify stripe size of striped meta devices.
Module title, 13
Converting Devices

13
You can convert a devices configuration by adding or removing BCV or DRV attributes or convert an RDF device from static RDF to dynamic RDF.
Module title, 14
Increasing Mirroring

14
You can increase device protection by adding a mirror.
Module title, 15
Decreasing Mirroring

15
You can decrease device protection by removing a mirror.
Module title, 16
Setting Front-End Port Flags

16
Setting front-end port attributes allows you to set or reset SCSI or fibre port flags such as the fibre FA loop ID.
Module title, 17
Setting Device Emulation

17
Setting device emulation allows you to change the emulation of a HVE for example, changing a FBA device to a Celerra_FBA device.
Module title, 18
Setting Device Attributes

18
Setting device attributes allows you to change or set special attributes on existing HVEs. A common device attribute is the VCMDB attribute that is set on a single device in a Symmetrix utilizing device masking.
Module title, 19
Setting Symmetrix Metrics

19
Symmetrix metrics are special settings that apply to an entire Symmetrix cabinet. For example, setting the RAID_S_Support metric will allow you to control whether or not RAID S devices can be created on that Symmetrix.
Module title, 20
Spare Disk Management

20
Spare disk management allows you to add a new spare disk or remove an existing spare disk. To add a spare disk requires an available physical disk (with no HVEs configured).
Module title, 21
Swapping RDF Personalities within a RA Group

21
You can modify a RDF configuration by adding or removing RDF attributes and swapping RDF source/target attributes for an RA group.
Module title, 22
Symmetrix Architectural Overview

22
Channel adapters/directors are the first logical component of the Symmetrix. They are the interface between the host and the Symmetrix cache.
Module title, 23
SAO

23
Intelligent cache configurations allow the Symmetrix system to transfer data at electronic memory speeds that are much faster than physical disk speeds. Symmetrix products are based on the principle that the working set of data at any given time is relatively small when compared to the total subsystem storage capacity. When this working set of data is in cache, there is a significant improvement in performance. The performance improvement achieved depends on both of the following principles: Locality of Reference If a given piece of information is used, there is a high probability that a nearby piece of information will be used shortly thereafter. Data Reuse If a given piece of information is used, there is a high probability that it will be reused shortly thereafter.
Module title, 24
Logical Front-End

24
In a Symmetrix array, a front-end director is a Fibre Channel adapter (FA) card that occupies a slot on the Symmetrix backplane, or the DMX midplane. The FA card in DMX and older Symmetrix models provides the interface to a host via a fibre network. In older Symmetrix models, the host to Symmetrix interface connection could also be a SCSI bus that requires a SCSI adapter (SA) type front-end director.
Module title, 25
Front-End Addressing

25
Symmetrix can attach to ESCON channels, Fibre Channels, Ultra Fast-Wide Differential (FWD) SCSI or FWD SCSI, or a mix of channel types. The physical connection to a Symmetrix parallel channel interface occurs at the Bus and Tag connector panel. The physical connection to a Symmetrix serial, FWD SCSI or Ultra SCSI, or Fibre Channel interface occurs at the connectors on the channel adapters.
Module title, 26
Host Adapter Location

26
Symmetrix channel directors are single cards that occupy one slot on the Symmetrix backplane. All channel directors, except parallel channel directors, interface to host channels via interface adapter cards connected to the opposite side of the backplane. Parallel channel directors interface to hosts via block multiplexer channels through bus and tag connector panels in the bottom of the Symmetrix cabinet.
Module title, 27
Front-End Hardware Pathway

27
The front end hardware pathway includes the channel adapter number, the processor, and port number.
Module title, 28
Rule of 17

28
The front end rule of 17 is a recommendation for host cabling to eliminate single points of failure. Odd numbered and even numbered adapters are connected to different internal buses. In this example the UNIX host is connected to the odd numbered FA 01 and the even numbered FA 16 (1 + 16 = 17).
Module title, 29
Symmetrix Cache

29
Cache is the second logical component of a Symmetrix and is crucial because it processes all read/write operations. Symmetrix cache operations are based on intelligent cache algorithms allowing for optimal data speed and performance. Cache consists of memory cards that occupy two or four slots on the front of the backplane. Like the channel directors, cache cards are housed in the card cage and are easily accessible. Cache cards are available in 1, 2 , 4, 8 and 16 GB sizes. Depending on the particular model, a Symmetrix contains two to four cache cards. Total memory capacity per unit ranges from 2 to 64 GB. The Symmetrix DMX1000 system can support up to four slots in the midplane dedicated to global memory directors and a maximum of 128 GB of global memory. The Symmetrix DMX2000/3000 system can support up to eight slots in the midplane dedicated to global memory and 256 GB of global memory. Individual global memory directors are available in 2 GB, 4 GB, 8 GB, 16 GB, and 32 GB sizes.
Module title, 30
Cache

30
Cache memory resides on cards that occupy slots on a Symmetrix backplane. Cache memory buffers I/O transfers between the director channels and the storage devices. Cache memory is segmented into slots, which are allocated to specific tracks in your storage devices. Cache access can be managed via LRU (Least Recently Used) ring partitions. Multiple LRUs can be established on a specific Symmetrix array and allocated to a percentage of cache (LRUs do not need to be of equal size). This enables a specific device pool size and cache partition to be allocated to each LRU based upon prioritized business needs.
Module title, 31
Directory Tables

31
A Symmetrix always caches write operations. On a write request, the channel director writes data to cache. A disk director later destages this data from cache to the appropriate disk drive.
Module title, 32
Mailboxes

32
The Symmetrix system performs read operations from cache. Symmetrix always caches write operations. This cache operation is transparent to the host operating system. A read operation causes the channel director to scan the cache directory for the requested data. If the requested data is in cache, the channel director transfers this data immediately to the channel with a channel end and device end (or a SCSI good ending status). If the requested data is not in cache, the disk director transfers the data from the disk device to the cache and updates the mailbox of the requesting front-end director. The front-end director transfers the requested data from the cache to the channel.
Module title, 33
Data into Cache

33
A read miss is a read operation that occurs when data necessary to satisfy the host I/O request is not in cache and must be retrieved from a disk drive. In this case, the host channel is temporarily disconnected from the Symmetrix. The disk director reads the data from the disk drive then stores the data in cache and notifies the channel director. The channel director then reconnects with the host and transfers the data.
Module title, 34
Symmetrix Logical Back-End

34
A fibre-connected disk director (DF) or non-fibre disk director (DA) provide the back-end interface to disk arrays. The DF or DA is a card that occupies a slot on the Symmetrix backplane, or DMX midplane. The CPU chip on these director cards run the Symmetrix Enginuity operating system, which manages access to specific disk drives. These back-end directors transfer data from disk to cache and destage the write-bound data from cache to disk. Another CPU chip on the front-end director also runs the Symmetrix Enginuity operating system that handles I/O requests from the host. It maintains data in cache (based on data access patterns) and determines if a data request can be satisfied from this cached pattern. Front-end directors and disk directors share the cache area. On a write request, the front-end director writes data to cache. A disk director later destages this data from cache to the appropriate physical disk.
Module title, 35
Logical Back-End

35
The Symmetrix disk directors manage the interface to the physical disks, and are responsible for data movement between the disks and cache. The disks are connected to disk directors through industry-standard SCSI interfaces with two advanced microprocessors per disk director. The Symmetrix contains four disk directors.
Module title, 36
Back-End Addressing

36
The back end address includes the Disk Adapter number, the processor, and interface.
Module title, 37
DA Location

37
The disk directors are located in the card cage next to the channel directors and cache cards. Like the channel directors, the disk directors are easily accessible from the card cage. The functions of a disk director include retrieving data from disk, writing data to disk, and performing error verification.
Module title, 38
Dual Initiator Failover

38
Disk directors are placed in the card cage in pairs and are connected to a dual initiator adapter. Should the primary path to a disk fail, the Symmetrix accesses that same disk through the other disk director. The dual initiator feature is useful because it provides a way to replace a disk director without disruption.
Module title, 39
Symmetrix Disks

39
From the perspective of software running on a host system, a Symmetrix array appears to be a number of physical devices connected to one or more I/O controllers. A host application addresses each of these devices using a physical device name. Each physical device defined in the configuration database has specific set of attributes (such as vendor ID, product ID, revision level, and serial ID). A Symmetrix device can map to a part of a physical disk or to an entire disk. The part of a physical disk to which a Symmetrix device is mapped is called a hypervolume or a hyper. A Symmetrix device may map to multiple hypers (containing identical copies of data) depending on its mirror configuration.
Module title, 40
Disks

40
All host I/O transactions with the array of Symmetrix disk devices are managed by the Enginuity operating environment, running in the Symmetrix I/O subsystem (channel directors and disk directors). Because each of the physical disks are indirectly seen as part of the I/O protocol, Symmetrix devices are presented to the host with the following configuration or emulation attributes: Each device has N cylinders. The number is configurable (blocks 960). Each cylinder has 15 tracks (heads). Each device track in a fixed block architecture (FBA) has 64 blocks of 512 bytes.
Module title, 41
DMX Architecture
FA05
0 1 0 1 0 1 0 1
Cache
DF01
Disks
C D C D C D C D
D C B A
FA12
D C B A
DF16
PBC
0
C D C D C D C D
0 1 0 1 0 1 0 1
D C B A
D C B A
PBC

41
The Symmetrix DMX features a high-performance, Direct Matrix Architecture (DMX) supporting up to 128 pointto-point serial connections in the DMX2000/3000 (up to 64 in the DMX1000). Symmetrix DMX technology is distributed across all channel directors, disk directors, and global memory directors in Symmetrix DMX systems. Enhanced global memory technology supports multiple regions and 16 connections on each global memory director. In the Direct Matrix Architecture, contention is minimized because control information and commands are transferred across a separate and dedicated message matrix. The major components of Symmetrix DMX architecture are the front-end channel directors (and their interface adapters), global memory directors, and backend disk directors (and their interface adapters). The matrix midplane provides configuration flexibility through the slot configuration. Each director slot port is hard-wired point-to-point to one port on each global memory director board. The Symmetrix DMX global memory director technology is one of the most crucial components of a Symmetrix system. All read and write operations transfer data to or from global memory. Any transfers between the host processor, channel directors, and global memory directors are achieved at much greater electronic speeds than transfers involving disks. Each Symmetrix DMX global memory director accommodates four separately addressable, simultaneously accessible memory regions, which greatly reduces the probability of contention for global memory access. Each global memory director is directly connected to each channel director and disk director through the direct matrix. The enhanced global memory capabilities of the Symmetrix DMX systems, as a part of the Direct Matrix architecture (DMX), allow the addition of more global memory directors to dramatically impact system bandwidth and performance compared to previous generations of Symmetrix systems. The DMX architecture ensures highest performance due to the following: Requests for global memory are expedited to reduce locking. Requests are intelligently arbitrated to optimize available resource usage.
Module title, 42
8 Port Adapters FA01

0
DF02
C
D
1 0
D
D C
C
1 0
C
D C
B
1 0
B
D C
A
1
A
D

42
All channel directors contain four high performance microprocessors. The channel directors process data from the host and manage access to global memory over a direct matrix (DMX) technology. Each channel director on the Symmetrix DMX system supports eight internal links to global memory. DMX technology is used across the Symmetrix system, as it is also designed on to each global memory director. In addition to DMX technology, each director board includes support for a separate message matrix for the transfer of control information.
Module title, 43
Hyper Volume Extensions

43
Hyper volumes are similar to disk drive partitions in that they provide more than 1 logical volume on a single disk, while making use of the volume's full formatted capacity. A single disk drive can be split into multiple logical volumes. The Symmetrix enhances disk system functionality by supporting up to 128 hyper volumes on 1 physical drive. A hyper volume may also be called a logical volume. Up to a maximum of 8,000 logical volumes are supported on a Symmetrix. Hyper volumes are the actual volumes with which a host communicates, and are configured upon initial Symmetrix setup. Additional volumes can be dynamically added as the customer requires more capacity.
Module title, 44
HVE Considerations

44
When a Symmetrix unit is set up initially, the maximum number of hyper volumes per disk is defined as a Symmetrix-wide parameter. As devices are configured, the Symmetrix configuration server creates up to the maximum hypers initially defined.
Module title, 45
HVE Considerations

45
Hyper volumes created can be of various sizes on a single disk drive. A hyper volume can range in size from 1 cylinder to approximately 32,510 cylinders (approximately 15 GB). Once megabyte is equal to 2.1333 cylinders.
Module title, 46
RAID 1 Protection

46
In the event of a data loss, a reliable backup medium is the best form of protection. Therefore, a Symmetrix uses enhanced RAID technology to ensure optimal protection of data. RAID 1, or Mirroring, is used for missioncritical data that requires the highest performance with continuous data availability. This data protection method stores identical data on another disk. The mirror is transparent to the host system. There are three main features of a mirror: Mirrored data automatically invoked if either disk fails Symmetrix calls home if a disk fails Automatic resynchronization after failed disk is replaced A dynamic spare is a disk drive that is reserved for use in the event that an active disk begins to fail. To be viable, a dynamic spare must be same size and geometry of the disk being replaced.
Module title, 47
RAID S Protection

47
RAID S (referred to as Parity RAID) is a Symmetrix feature that provides parity data protection on the device level using a physical parity device. RAID S involves groups and ranks. A RAID S group is a set of disk drives within a Symmetrix configuration that are interrelated for parity protection. Parity RAID devices must be created in multiples of 3 or 7. For example, a Parity RAID 3+1 protection group requires three devices for data and one for shared parity. Any requests to create parity devices outside of the 3 or 7 multiple factor will be denied. The Symmetrix maps each of devices data mirrors to the same mirror positions on a separate hyper and creates one parity device to be shared by the data devices. The number of Parity RAID (3 or 7 members) devices must be defined in the Symmetrix Attributes.
Module title, 48
RAID 5 Protection

48
Beginning with EMC Solutions Enabler version 5.4, you can create a RAID-5 device. You can do this the same way you create a mirrored device. For example, a 2-way-mirror device has two hypers. You create a RAID-5 device with either four or eight hypers. The difference is in how the data is written to the hypers. Prior to creating a RAID-S or a RAID-5 device, you need to set a Symmetrix parameter for the type of RAID protection you are configuring. You also need to set a parameter for the number of members (3 or 7) that you want in a RAID-S protection group, or the number of hypers (4 or 8) that you want to form a RAID-5 device
Module title, 49
Device Configurations

49
Gatekeepers, Business Continuance Volumes (BCVs), Dynamic Reallocation Volumes (DRVs), and meta devices each have unique configuration guidelines. Gatekeepers are normally 6 cylinder FBA volumes. Gatekeepers can be designated by default or active assignment. A BCV device contains a copy of data from a standard Symmetrix device which is online for regular I/O operation from the host. Each BCV device has its own address and needs to be configured as a stand-alone Symmetrix device. A BCV must be the same size as the data volumes that it will copy. For an Optimizer configuration, you will need to have two DRVs for each size logical volume that is configured on your Symmetrix.
Module title, 50
Gatekeepers

50
SCSI commands executed by SYMAPI are transferred to the Symmetrix array via a Symmetrix device that is designated as a gatekeeper device. The gatekeeper allows you to retrieve configuration and status information from the Symmetrix array without interfering with normal device I/O operations. By default, one of the available Symmetrix devices is designated as a gatekeeper. Alternatively, you can define specific devices to be used as gatekeepers.
Module title, 51
Standards (STD)

51
A Symmetrix system applies a high degree of virtualization between what the host sees and the actual disk drives. A Symmetrix device is not a physical disk. A Symmetrix device is a logical volume with a name that the host can address. From the perspective of the host, these logical volumes in a Symmetrix unit appear as physical devices connected to one or more I/O controllers. For a host to see the device, you need to define a path by mapping the device to a front-end director, and then you need to use host-specific utilities or the EMC I/O scan option (available with the symcfg command)2 to have the host recognize the device. From the perspective of the open systems host, these logical volumes appear as physical disk devices at addresses specified by a SCSI target ID and Logical Unit Number (LUN). However, when fibre is the addressing mechanism and peripheral device addressing is being used, the fibre switch and arbitrated loop generate an equivalent of the target ID, requiring you to specify only the LUN when mapping a device. Devices used for production data are considered standards (STD).
Module title, 52
Business Continuance Volume (BCV)

52
The Symmetrix TimeFinder is a business continuance solution that allows you to use special Symmetrix devices called Business Continuance Volumes (BCVs). A BCV device contains a copy of data from a standard Symmetrix device that is online for regular I/O operation from its host(s). Uses for the BCV copies can include backup, restore, decision support, and applications testing. Each BCV device has its own host address, and is configured as a stand-alone Symmetrix device. A business continuance sequence first involves establishing the BCV device as a mirror of a specific standard Symmetrix device. As a result, the BCV device becomes inaccessible via its original device address while it is in an established pair. Once the BCV device is synchronized, it may be separated (split) later from the standard device with which it is paired. Once split, the BCV device with the synchronized data becomes available for backup or other host processes through its original device address. Once host processing on the BCV device is complete, the BCV may again be mirrored to a standard Symmetrix device, which can either be the same device to which it was previously paired, or a different device.
Module title, 53
SRDF R1/R2 Volumes

53
The Symmetrix Remote Data Facility (SRDF) is a business continuance solution that maintains a mirror image of Symmetrix array data at the device level, which may be located in physically separate sites. SRDF provides a recovery solution for component or site failures using remotely mirrored devices. SRDF reduces backup and recovery costs and significantly reduces recovery time after a disaster. In an SRDF configuration, the individual Symmetrix devices are designated as either a source (R1) or a target (R2) to synchronize and coordinate SRDF activity. If the source (R1) device fails, the data on its corresponding target (R2) device can be accessed by the local host. Once the source (R1) device is replaced, it can be resynchronized. SRDF configurations have at least one source (R1) device mirrored to one target (R2) device. For concurrent RDF systems, there can be two R2 targets. A source (R1) device can only belong to an RDF1 device group, while a target (R2) device can only belong to an RDF2 device group. Since Enginuity 5568, devices can be configured to be Dynamic RDF-capable devices. Dynamic RDF functionality enables you to create, delete, and swap SRDF pairs while the Symmetrix array is in operation. Using Dynamic RDF technology, you can establish SRDF device pairs from non-SRDF devices, then synchronize and manage them in the same way as configured SRDF pairs. The Dynamic RDF configuration state of the Symmetrix array must be enabled in SymmWin or via the Configuration Manager and the devices must be designated as dynamic RDF-capable devices.
Module title, 54
Dynamic Reallocation Volume (DRV)

54
Symmetrix Optimizer is a tool that automatically balances hyper-volume loads across physical disks within a Symmetrix unit by running a process on the Symmetrix service processor that analyzes hyper-volume activity. You can create a DRV device (Dynamic Reallocation Volume) for use by Symmetrix Optimizer to temporarily hold user data while Optimizer reorganizes the devices. Optimizer uses DRVs in device swapping operations in a manner similar to BCV devices in TimeFinder operations. This reorganization takes place on the back end of the Symmetrix and is transparent to the host and end-users. The DRV device maintains the protection level for the device whose backend locations are being optimized.
Module title, 55
R1-BCV

55
A BCV device can be SRDF protected. This is commonly implemented to support SRDF Multi-Hop configurations.
Module title, 56
Meta Devices

56
Meta devices allow individual devices to be concatenated to create larger devices. For Enginuity levels below 5x66, meta devices must be adjacent Symmetrix devices and are formed by grouping physical devices that followed each other. For Enginuity 5x66 and above, the devices assigned in a meta sequence do not need to be adjacent. The meta head is the first device in the meta device and is responsible for receiving incoming commands. When an incoming command for the meta head is processed, the Enginuity software determines which meta device member should execute the command. Several operating systems, such as Windows NT and some open systems environments, can have larger volumes than are provided by standard Symmetrix physical disk devices. A meta device (volume) is a logical volume set created from individual Symmetrix hypers to define volumes larger than the current Symmetrix maximum hyper volume size of approximately 16 GB. Meta volumes (devices) are functionally the same as logical volume sets implemented with the host volume manager software. Physically, a meta device is two or more Symmetrix hyper volumes presented to a host as a single addressable device. It consists of a meta head device, some number of member devices (optional), and a meta tail device. Meta devices may contain as many as 255 members. The maximum size meta device that has been tested by EMC is 3.825 terabytes, which is the maximum size supported at this time. In Enginuity 5x66 and above, Meta devices can be composed of non-sequential and non-adjacent volumes.
Module title, 57
Forming Meta Devices

57
Meta devices may contain as many as 255 members. The maximum size meta device that has been tested by EMC is 3.825 terabytes, which is the maximum size supported at this time. In Enginuity 5x66 and above, Meta devices can be composed of non-sequential and non-adjacent volumes. By allowing individual physical disk devices to be grouped together into a meta device (volume) and the capability of meta device addressing, Symmetrix enhances disk system functionality. To increase throughput and further improve performance, Symmetrix provides multiple I/O drive queues for meta volumes. Addressing of data contained in a meta device can be organized in two different ways: Concatenated devices and Striped devices.
Module title, 58
Types of Meta Devices - Concatenated

58
Concatenated devices are volume sets that are organized with the first byte of data at the beginning of the first device. Addressing continues to the end of the first device before any data on the next device is referenced. When writing to a concatenated device, the first meta device member receives all the data until it is full, then data is directed to the next member and so on.
Module title, 59
Types of Meta Devices - Striped

59
A striped meta device is one that places data on meta members in user-defined stripes or chunks instead of filling an entire device first before addressing the next device. The stripe size (or chunk size) is the amount of data addressed on one device before moving on to the next device in the meta device. A stripe size of 1920 blocks (which can also be specified in cylinders as 2 cyl) is the recommended stripe size and the default when no size is specified.
Module title, 60
Virtual Devices
Virtual Device Production Device Save Device

60
Snapshot copies use virtual devices to support EMC Snap operations. A virtual device is a host accessible device containing track-level location information (pointers), which indicates where the copy session data is located in the physical storage. Virtual devices consume minimal physical disk storage, as they store only the address pointers to the data stored on the source device or a pool of save devices.
Module title, 61
Save Devices
Virtual Device Production Device Save Device

61
Symmetrix save devices are special devices (not mapped to the host) that provide physical storage space for preupdate images or changed tracks during a virtual snap copy session. Save devices are a predefined pool of storage devices and must be configured for this purpose. The save device pool acts as a group for storing data in striped form. Save devices are assigned a Symmetrix device number and can be unprotected, mirrored, or parity RAID. They cannot be part of a meta volume or grouped. Note: Configuring save devices as unprotected is not recommended and requires special approval by EMC.
Module title, 62
Tying Together the Four Logical Components

62
In Symmetrix systems, the channel directors and disk directors share cache memory. Symmetrix channel directors attach to the CPU channels as well as to cache memory. Symmetrix disk directors attach to cache as well as the disk drives. The Symmetrix directors perform the following functions: The channel director handles I/O requests from the host. It accesses the directory in cache to determine if the request can be satisfied within the cache. The directory contains information on each cache page and blocks within each page. The directors manage cache using various methods that generally result in the implementation of a Least Recently Used (LRU) algorithm. This usage model ensures that only pages of data that have been recently accessed remain in cache. Using the Prefetch Algorithm, the disk director dynamically detects sequential data access patterns to the disk devices. The directors improve the hit ratio of these accesses by promoting blocks from the disk devices to cache slots before that data has been requested. The disk director manages access to the disk drives. When a read miss occurs, the disk director also stages tracks into cache. It also performs a background operation that destages written-to blocks to disk.
Module title, 63
Configuration Manager

63
The symconfigure command allows you to perform powerful control operations that manage various types of configuration changes on devices in your Symmetrix environment. You can invoke symconfigure from the local host to make configuration changes to a locally-connected Symmetrix, or to an RDF-linked Symmetrix array. The SYMCLI Configuration Component extends the basic SYMCLI command set to include the symconfigure command on the following platforms: Sun Solaris Hewlett Packard HP-UX Windows NT and Windows 2000 Tru64 UNIX IBM AIX Linux AS/400 (via client/server) Linux S/390
Module title, 64
Configuration Manager with SRDF

64
The Symmetrix Remote Data Facility (SRDF) is a business continuance solution that maintains a mirror image of data at the device level in Symmetrix systems located in physically separate sites. SRDF Devices SRDF configurations provide for either a uni-directional or a bi-directional data transfer over SRDF links between sites. Devices are designated as either R1 (source) or a R2 (target) devices to synchronize and coordinate SRDF transfer activity. A source R1 device is designated an RDF1 type, while a target R2 device is designated an RDF2 type. An R1 or an R2 device can also have associated mirror(s) (M1, M2) for increased protection. These are designated RDF1+Mir or RDF2+Mir as configuration types when using symconfigure.
Module title, 65
Configuration Manager and ControlCenter

65
Today, companies are storing ever-increasing amounts of information. As enterprise storage networks become more complex, and storage devices grow in number and size, companies are faced with the challenge of effectively managing their storage. An enterprise storage network is a collection of storage resources linked together to provide access to information from multiple platforms, operating systems, and applications across any combination of SCSI, ESCON, or Fibre Channel technologies. EMC ControlCenter is an integrated family of products that enable you to discover, monitor, automate, provision and report on networks, host resources, and storage resources across your entire information environment. From a single console, ControlCenter can monitor and manage: Connectivity components Fibre Channel switches and hubs. Host components Host operating systems, file systems, volume managers, databases, and backup applications. Storage arrays EMCs Symmetrix, CLARiiON, and other vendors storage arrays. ControlCenter shows a consolidated view of the storage environment, allowing you to monitor the health of, track the status of, report on, and control each object from a console anywhere on the network.
Module title, 66
ControlCenter Tiers - Console

66
The Console is the user interface through which you view and manage the storage environment. It is a Java-based application that is installed through a browser such as Microsoft Internet Explorer or Netscape, and launched from a desktop icon or from the command line. ControlCenter applications are implemented as plug-ins to the Console and use the common collection of services provided by the ECC Server. For an object to be displayed in the Console, it must have been discovered by an agent. Once discovered, the object appears in the Console, grouped into its appropriate folder, such as Storage Systems, Hosts, or Connectivity. Information about the object can be retrieved by the Console from the Repository or in real-time directly from the agent. It is presented to you through a series of views. Any command issued for the object is passed from the Console to the ECC Server and forwarded to the agent to be enacted.
Module title, 67
ControlCenter Tiers - Infrastructure

67
The Infrastructure Tier includes the Repository, ECC Server, and one or more Stores. The infrastructure components can reside on different Windows 2000 servers as in a distributed infrastructure or can reside on a single server, as is the case of a single host infrastructure. The size of the environment and performance considerations determines the appropriate infrastructure configuration. The ECC Server is the primary interface between the Console and the ControlCenter infrastructure. The ECC Server is a collection of services crafted for use by ControlCenter. It encompasses diverse areas including: Web server, which installs and starts the Console Security and access management, such as licensing, login, authentication, and authorization Communication with the Console SNMP collection Alert and event management Real-time statistics Object management to maintain a list of managed objects Agent management to maintain a list of available agents The ECC Server retrieves data from the Repository for display by the Console. It can also request real-time data directly from some agents, but the Console user must initiate the request and the information collected is transient (not stored). The Repository contains a relational database, based on Oracle 8i. Installation and maintenance of Oracle are fully embedded into ControlCenter. The Repository holds the current and historical data of both the storage environment and ControlCenter itself, with the exception of performance data. The ECC Server processes transactions from the Console for Repository data, such as checking user group permissions. The Store is a process that populates the Repository with persistent data from the agents. It provides a store and retrieve interface between the agents and the Repository.
Module title, 68
ControlCenter Tiers - Agent

68
ControlCenter manages every physical and logical element using intelligent agents. The agent collects data and monitors the health of the element. In addition, it can run user commands for configuring disk groups, volumes, and file systems, and for real-time explore. There are many types of agents for managing diverse domains, from storage arrays through to host applications. A different agent manages each type of object. For example, there is a Storage Agent for Symmetrix, a Host Agent for Windows, a Database Agent for Oracle, and so on. There can be more than one agent on a host. A single Master Agent controls all the agents on a host, starts and stops the agents, and facilitates remote installation and upgrade.
Module title, 69
Symmetrix Command Line Interface

69
SYMCLI resides on a host system to monitor and to perform control operations on Symmetrix arrays. SYMCLI commands are invoked from the host operating system command line (shell). The commands are linked with SYMAPI library functions. The library functions use system calls that generate low-level I/O SCSI commands to the Symmetrix arrays. To reduce the number of inquiries from the host to the Symmetrix arrays, configuration and status information is maintained in a Symmetrix host database file. On a UNIX system, when you run symcfg discover, the Symmetrix host database file, symapi_db.bin, is created in: /var/symapi/db. On Windows NT, the database file is found in: C:\Program Files\EMC\Symapi\db. On Open VMS, the database file is found in: SYMAPI$DB
Module title, 70
What is SYMCLI?

70
The Solutions Enabler (known as SYMCLI) is a specialized library or set of UNIX-formatted commands that can be invoked one at a time. The SYMCLI (Symmetrix Command Line Interface) is used in single command line entries and scripts to monitor and perform control operations on devices and data objects toward the management of your information storage complex. It also monitors the Symmetrix configuration and the status of devices that make up the information storage environment. The target storage environments managed by SYMCLI are typically Symmetrix-based but can be CLARiiON when you have a license and work with the SYMCLI Storage Resource Management (SRM) component. For base CLI commands to manage CLARiiON storage, see the EMC Solutions Enabler Open Storage Base Management CLI Product Guide.
Module title, 71
syminq

71
The syminq command can be used to issue SCSI INQUIRY, and optionally SCSI READ CAPACITY, on one or all devices. By default, the scope of the command is for all disk devices. You can limit the scope to Symmetrix, CLARiiON, StorageWorks, or HDS devices. In addition, it can be used to list the fibre and SCSI HBAs in the local host. This scope of this request can be limited to just fibre or just SCSI by specifying either the -fibre or -scsi options.
Module title, 72
syminq Command

72
EXAMPLES: To issue just a SCSI INQUIRY to all Symmetrix devices that are visible to this host, enter: syminq -sym -nocap To issue a SCSI INQUIRY and READ CAPACITY to a device, enter: syminq /dev/rdsk/c2t0d2s3 The following example issues a SCSI INQUIRY and READ CAPACITY command to a device and displays more detailed, verbose information: syminq -v /dev/rdsk/c2t0d2s3 The following example requests that the SCSI HBAs in the local host be listed: syminq hba -scsi
Module title, 73
Device Serial Number

73
For 5568 Enginuity microcode, since the support for number of logical devices per Symmetrix increased to 8000 devices, the output format returned by syminq has changed. The port number in the device serial number is now modified to handle this. The device serial number format (SSNNNDDP) remains, however, if the port number shown is greater than or equal to 8, the Symmetrix devices name is greater than FFF. To get the correct port number in these cases, subtract 8 from the P field. Example with 4 character Symmetrix Device Name, (names above FFF): Device Serial Number: 23035129 Symmetrix ID: 23 Symmetrix Device Name: 1035 Director: 12A Port: 1 Notice how 8 is added to the port to denote the Symmetrix Device Name is over FFF. It can then be assumed that the Symmetrix Device Name is 1035 not 035. Example (with 3 character Symmetrix Device Name): Device Serial Number: 23035121 Symmetrix ID: 23 Symmetrix Device Name: 035 Director: 12A Port: 1
Module title, 74
syminq -pdevfile

74
Use pdevfile (lists physical device names in a format for use as pdevfile entries) with the syminq command to view the information embedded in the serial number in an easy to read format. The display output can be redirected to a pdev file name for reference.
Module title, 75
symdev

75
The symdev command displays information about all or selected Symmetrix devices regardless of whether they are visible to the local host. You can release a Device External Lock (DEL) on one or more specified Symmetrix devices.
Module title, 76
symdev Command

76
EXAMPLES To list all Symmetrix devices that are configured in Symmetrix arrays connected to this host, enter: symdev list To show detailed information about Symmetrix device 000C in a Symmetrix array with the specified unique ID, enter: symdev -sid 870 show 000C To list the first 20 BCV devices starting at Symmetrix device 001F, that are configured in each Symmetrix array, enter: symdev list -BCV -RANGE 001F: -N 20 To list (verbose) a range of Symmetrix devices (0000 to 000A) that have a device external lock of 9, enter: symdev list -sid 870 -lock 9 -RANGE 0000:000A -v To release all Symmetrix devices in Symmetrix 870 that have a device external lock of 9, enter: symdev release -sid 870 -lock 9
Module title, 77
symdev list

77
There are many options and arguments that can be used with the symdev command. This list shows a few that are helpful when preparing for configuration changes. -noport Lists the Symmetrix devices that are not mapped to any front-end adapter ports. -multiport Lists the Symmetrix devices that are mapped to multiple front-end adapter ports. -DA Lists the Symmetrix devices that are mapped to a certain DA director number. The interface, disk, and hyper IDs can also be used to confine the list further, but defaults to ALL unless specified. -space Shows the available or unconfigured storage space for the specified listing of disks.
Module title, 78
symdev show

78
Symdev show: Displays detailed information about a Symmetrix device, given the Symmetrix device name, such as 000C.
Module title, 79
sympd

79
The sympd command performs operations on a device given the devices physical name, such as /dev/rdsk/c3t0d3s2, listing devices by Symmetrix ID and showing device-specific information. The export command stores the current list of physical device names that the host can see, as well as other information about the physical device, such as the Symmetrix ID, device number, and director/port to a file. The verify command compares the current list of physical device names to the ones stored in the file previously for any differences.
Module title, 80
sympd Command

80
EXAMPLES: To list all Symmetrix devices visible to this host, enter: sympd list To show detailed information about a Symmetrix device, enter: sympd show /dev/rdsk/c2t0d2s3 The following example lists only Symmetrix devices visible to this host that are mapped to all Fibre Channel directors, port 0: sympd -sa all -p 0 -fibre list
Module title, 81
sympd show

81
Sympd show: Displays status information about a Symmetrix device that is visible to this host.
Module title, 82
symdg

82
The symdg command performs operations specific to device groups such as, creating new device groups, importing ASCII group files, exporting groups to files, translating groups to/from Symmetrix Manager files, deleting groups, renaming groups, and listing and showing information about a device group.
Module title, 83
symdg command

83
The SolutionsEnabler Base product manages three types of device groups: REGULAR (non-RDF), RDF1 (RDF source device), and RDF2 (RDF target device). When you create a device group in an RDF configuration, you must specify the type of the device group (RDF1 or RDF2). Otherwise, the group type defaults to REGULAR when no type is specified. EXAMPLES: To create a Symmetrix device group, mydg_r1, of type RDF R1, enter: symdg -type RDF1 create mydg_r1 To list all Symmetrix device groups in detailed format, enter: symdg -v list To rename Symmetrix device group mydg_r1 to oradg_rdf1, enter: symdg rename mydg_r1 oradg_rdf1 To show information about device group oradg_rdf1, enter: symdg show oradg_rdf1 To delete Symmetrix device group oradg_rdf1, regardless of whether the group has members, an associated gatekeeper, or BCV devices, enter: symdg -force delete oradg_rdf1
Module title, 84
symdg Output

84
You can group SRDF (Symmetrix Remote Data Facility) standard devices in a device group subject to the following restrictions: You cannot mix SRDF and non-SRDF devices in the same device group. All SRDF devices in a given device group must be either all source (R1) or all target (R2) devices. All SRDF devices in a given device group must belong to the same Symmetrix RDF group1 or if concurrent RDF, then two RA groups. You can associate Business Continuance Volume (BCV) regular devices and RDF1 BCV devices with a device group. You can do BCV control operations on any BCV pair in the device group. Also, you can do RDF operations on just the associated RDF1 BCV devices. You can associate virtual devices (VDEV) paired with standard and BCV devices with any device group. In addition, TimeFinder/Snap control operations can be performed on any virtual device in a device group. You can associate one or more gatekeeper devices with a device group. SYMCLI will use the associated gatekeeper to issue requests to the Symmetrix for control operations on the devices within the specified device group. You can add a standard device to a device group. However, the gatekeeper cannot be added to the device group, only associated with a device group. Note: A BCV device or a RDF2 device cannot be assigned as a gatekeeper, nor can a device that is a member of a device group be defined as a gatekeeper. Symdg list: Lists all the device groups that have been created for this host.
Module title, 85
symld

85
The symld command performs operations specific to a device in a device group: adds a device to a device group, adds all available devices to a device group, lists all devices in a device group, removes/moves a device or all devices from a device group, renames a device in a device group, and shows detailed information about a device in a device group. The symld command is also used to write enable or write disable one or all devices, or front-end directors, in a device group. The symld command can also be used to break device reservations for one or more devices in a device group.
Module title, 86
symld Command

86
EXAMPLES: To add a Symmetrix host device to group prod and assign a logical device name temp1, enter: symld -g prod add pd c2t0d2s2 temp1 To add a Symmetrix device to group ProdDB and assign a logical device name temp2, enter: symld -g ProdDB add dev 001C temp2 To list all devices in device group ProdDB, enter: symld -g ProdDB list To rename device DEV001 to log1 in group ProdDB, enter: symld -g ProdDB rename DEV001 log1 To remove device log1 from device group ProdDB, enter: symld -g ProdDB remove log1 To write-disable devices DEV001, DEV005, and DEV016 in group ProdDB, enter: symld -g ProdDB write_disable DEV001 DEV005 DEV016
Module title, 87
symld Output

87
Device groups, as well as the devices in a device group, are assigned names that facilitate reference in a session. You assign a device group name at the time you create it. The name can have up to 31 characters and must be unique for a given configuration database. When you add a device to a device group, it is given a logical name. This name allows you to refer to the device independently of its physical device name or Symmetrix device name. The name can have up to 31 characters and must be unique within the device group. It is known only within the context of the device group to which the device belongs. You must use this logical name in any SYMCLI command that has the argument LdevName or ld.
Module title, 88
symcfg

88
The symcfg command is used to discover a Symmetrix configuration, refresh the Symmetrix configuration database file, and display configuration information about the Symmetrix arrays attached to the host and/or any of its directors. The symcfg command can be used to view whether the specified Symmetrix array(s) have an exclusive Symmetrix lock. You can release the lock if it is hanging. The symcfg command can be used to set one or all RDF RA or SA directors on a locally-attached Symmetrix array to either online or offline from the Symmetrix configuration database. The symcfg command can be used to display the LRU cache management configuration of a Symmetrix array. It can also be used to list the services entered in the network services file (netcnfg) or list all the UNIX gatekeeper, database, and lock file semaphores. It can display application and host registration, and port connection information. In addition, some arrays require authorization information to provide to access the array. The symcfg authorization command can be used to supply this information for use in subsequent discovery operations. The symcfg authorization command allows you to list, add, update or delete this connectivity information. Update allows you to update the password of an existing entry.
Module title, 89
symcfg Command

89
To reduce the number of inquiries from the host to the storage arrays, configuration and status information is maintained in a Symmetrix host database file (called the Symmetrix configuration database). On a UNIX system, when you run symcfg discover, a Symmetrix configuration database file, symapi_db.bin, is created in: /usr/storapi/bin On Windows, the configuration database file is created in: c:\Program Files\EMC\WideSky\bin
Module title, 90
symcfg Output

90
EXAMPLES To discover all Symmetrix arrays connected to this host and to build/rebuild the Symmetrix configuration database file from information gathered, enter: symcfg discover To display information about the attached Symmetrix arrays, enter: symcfg list To display information about all front-end directors for the specified Symmetrix array, enter: symcfg list -SA ALL -sid 710 To list all gatekeeper and database semaphores, enter: symcfg list -semaphores To verify whether the Symmetrix 0098 configuration and the Symmetrix configuration database are in sync, enter: symcfg verify -sid 0098
Module title, 91
symcfg list Options

91
There are many options and arguments that can be used with the symcfg command. This list shows a few that are helpful when preparing for configuration changes. -v: Provides a more detailed, verbose listing. -SA: Confines the action to a front-end (SCSI or Fibre) director number. To select all front-end director numbers, specify ALL. -P: Identifies a specific (SCSI or Fibre) port of a front-end director. -available: Requests the next available Vbus, TID, or LUN address be appended to the output list. Used with the address option. -address: Lists the Vbus, TID, and LUN addresses associated with devices mapped to the front-end directors.
Module title, 92
symcfg ra all list

92
The symcfg ra all list command can be used to display RA group information.
Module title, 93
symbcv list

93
The symbcv list command can be used to verify which BCV devices are currently synchronized with standard devices.
Module title, 94
Module 1 Summary
Key Points covered in this module: Fundamental concepts associated with Symmetrix configuration management

94
Module title, 95
Module 2: Configuration Management CLI

After completing this module, you will be able to: Perform configuration changes using the command line interface

95
Module title, 96
Command Structure

96
The symconfigure command allows the advanced user more powerful control to manage various types of configuration changes affecting Symmetrix devices than otherwise provided by the SYMCLI set. Most SYMCLI commands, including the symconfigure command can operate on Symmetrix systems and devices that are either directly attached to the users host, or are accessible via an RDF link. This command allows you to modify Symmetrix devices, ports, RDF characteristics, host assignments, and create or delete Symmetrix devices. A lock on the Symmetrix configuration is engaged by the configuration server during the configuration change session. A session is processed in a series of progressive stages (preview, prepare, commit), which can be monitored using polling options. Not all stages are always executed. Use discretion when controlling which stages are to be completed to allow checking and debugging of the command files before the changes are implemented. The stages are: preview, prepare, and commit. SYNTAX symconfigure -h symconfigure list -sid SymmID [-v | -freespace [-units cylinders | MB]] symconfigure -sid SymmID [-noprompt][-noecho|-v] [-i Interval][-c Count] [-f[ile] Cmd_Filename | (redirect stdin)] preview prepare commit symconfigure verify -sid SymmID symconfigure query -sid SymmID [-i Interval][-c Count] [-v] symconfigure abort -sid SymmID symconfigure -version [-v] [-sid SymmID]
Module title, 97
Symmetrix Lock

97
The Symmetrix configuration server engages a configuration lock (known as lock 15 or lock F) on the Symmetrix during the change session, blocking others from attempting to change the configuration. The lock is released at the end of the session or if the session is aborted. The time held by the configuration lock and the lock itself can be viewed by entering the following command: symcfg list lockn 15 Symmetrix device locks are used to prevent other control operations (i.e., SRDF, TimeFinder) from performing on devices being modified by a configuration change session. Device locks are engaged by the SYMAPI during the preview stage. Device locks are retained until the configuration change session has completed and changes have been activated on the Symmetrix. To view a list of the locked devices on the Symmetrix, use the symdev list -lock command. Device locking is also engaged by the other Symmetrix control operations for blocking devices during control actions. EMCs TimeFinder Snap operations allow for devices to be marked as held, to be available for snap session copies. Devices are attached and detached as snap target devices using the symsnap attach or detach command. Held devices are set as Not Ready to the host and are not available for configuration changes. To view a list of devices currently held, use the symdev list -held command. When swapping the locations of Symmetrix device hyper volumes to produce optimum Symmetrix performance, the Symmetrix Optimizer uses the same configuration change mechanism used by symconfigure. Because only one application can be changing the Symmetrix configuration at a time, one application will fail. If you think contention may arise between Optimizer swapping and the Configuration Manager, you can disable the Optimizer during configuration change sessions using the symoptmz -sid SymmID disable command.
Module title, 98
symconfigure -h

98
Symconfigure h: Provides brief, online help information including definitions and syntax.
Module title, 99
symconfigure -version

99
Symconfigure version: Lists the SYMCLI, SYMAPI, and configuration server version information. Connects to the configuration server managing the Symmetrix configuration for version information. The sid option is required if the host is connected to more than one Symmetrix array.
Module title, 100
Verifying Communication

100
Symconfigure verify: Verifies that the configuration currently running in the specified Symmetrix array complies with the requirements for the host-based configuration changes.
Module title, 101
symconfigure verify

101
Configuration changes initiated by the symconfigure command should be performed only by advanced users or system administrators to avoid potential issues. As with any critical operation, planning plays an important role. Before making configuration changes, you should observe the following precautionary guidelines: Understand your current Symmetrix configuration and how the devices are being used by host systems. Determine your new requirements and thoroughly understand the proposed reconfiguration prior to making any changes. Document the proposed changes to the configuration. Ensure that your critical data is safely preserved. Do not store data on any device that is not mirrored. Verify that a configuration change session can be performed on the Symmetrix unit. This command makes sure that all the requirements for the host and the Symmetrix are correct. For example: symconfigure verify sid 120 If possible, stop I/O activity on all Symmetrix devices to be altered (by making the devices Not Ready or Write Disabled) before invoking the commit action. Heavy I/O activity on affected devices impacts the length of time it takes to commit changes. Determine if your configuration change is in a change class that requires unmapping the devices before the configuration change session is initiated.
Module title, 102
symconfigure query

102
Monitoring a change session can be useful in checking the status of a change session, especially during changes to SRDF environments where a change to a Symmetrix unit attached to the local host activates a change to a remote Symmetrix unit. The system administrator of a host connected to the remote Symmetrix unit can monitor the progress of the change. A query operation is also helpful at sites where Symmetrix Optimizer is used to modify the backend volume configuration. To monitor the configuration change session while the symconfigure commit operation is processing, you can issue the symconfigure query command or use the UNIX tail command (with the f option) to interactively monitor the SYMAPI log file from a second window. The following query checks the status of the change session on the Symmetrix unit (sid 120) twelve times at 10-second intervals. If you omit the c option, the query checks every 10 seconds until the processing completes. symconfigure sid 120 query i 10 c 12
Module title, 103
Aborting a Hung Session

103
You can attempt to abort a hung configuration change session. The abort action also releases the configuration session lock. To abort a change session on Symmetrix 000000012345, enter: symconfigure -sid 45 abort Since changes made in the RDF operations class will initiate actions on the local Symmetrix and on the remote Symmetrix, it might become necessary to abort processing on a remote Symmetrix. At some point during commit processing, a point of no return is reached. Any attempt to abort will be denied once processing has reached this point.
Module title, 104
symconfigure abort

104
You can attempt to abort a hung session. The abort action also releases the configuration session lock. To abort a change session on Symmetrix 000000012345, enter: symconfigure -sid 45 abort Since changes made in the RDF operations class will initiate actions on the local Symmetrix and on the remote Symmetrix, it might become necessary to abort processing on a remote Symmetrix.
Module title, 105
symconfigure Arguments - Preview

105
A session is processed in a series of progressive stages (preview, prepare, commit), which can be monitored using polling options. Not all stages are always executed. Use discretion when controlling which stages are to be completed to allow checking and debugging of the command files before the changes are implemented. The preview argument verifies the syntax and correctness of each individual change defined and then terminates the session without change execution.
Module title, 106
Preview Output

106
To preview a command file that references Symmetrix 000000012345, enter: symconfigure -sid 45 v -f Cmd_Filename preview
Module title, 107
Symconfigure Arguments - Prepare

107
The prepare argument will perform the preview checks and also verify the appropriateness of the resulting configuration definition against the current state of the Symmetrix; then terminates the session without change execution.
Module title, 108
Prepare Output

108
To prepare a command file that references Symmetrix 000000012345, enter: symconfigure -sid 45 v -f Cmd_Filename prepare
Module title, 109
symconfigure Arguments - Commit

109
The commit argument completes all stages and executes the changes in the specified Symmetrix array.
Module title, 110
Commit Output

110
No configuration change is activated in the Symmetrix system until you commit the action. Some classes of change operations may or may not impact current I/O. When possible, before you commit any action, stop I/O activity on the Symmetrix devices to be altered during a configuration change session. Consider the Impact on I/O statement for each class of operation before working on any online devices. The overall processing time for the changes can vary from 5 minutes to over an hour, depending on the class of changes. RDF changes will also be applied to the remote Symmetrix array. Even more time is needed if the devices are to be synchronized. Ensure that all your critical data is preserved and safe when creating new or changing device configurations. Do not store data on any device that is not mirrored. All final configurations and device attribute adjustments must meet certain Open Systems guidelines put forth in the tables of the EMC Symmetrix Support Matrix. You can find the EMC Symmetrix Support Matrix on the EMC Powerlink Web site at: http://powerlink.emc.com CAUTION: Contact the EMC Customer Support Center for assistance in reverting to your previous configuration should there be unforeseen problems with the new configuration.
Module title, 111
SYMAPI Log

111
SYMCLI and SYMAPI normally log significant events and actions to a daily log file. On UNIX, the log file has the following (default) pathname: /var/symapi/log/symapi-yyyymmdd.log On Windows NT, the log file has the following (default) pathname: C:\Program Files\EMC\Symapi\log\symapiyyyymmdd.log where: yyyy year, mm month, dd day The log displays the following items concerning each event: Time tag of the event occurrence Process ID (PID) Source of the event (application name) Related (internal) API function call Name of the specific operation or event Variable event field that describes in detail the event or error Note: Log files accumulate over time and can consume needed disk space. Periodically, you may need to purge the log files to conserve space.
Module title, 112
Command Files

112
For the configuration change session, you must define a set of changes within a specified command file. The symconfigure command file format contains various command entries terminated with a semicolon (;). Multiple changes can be made is one session, but all changes must fall into one operation class. Command file examples are provided with the actions described later in this module. Beginning with Enginuity version 5669, changes for multiple operation classes can be executed within the same session. However, the existing Symmetrix configuration must be valid for each change in the command file. A given change can not be dependant on a previous change in the same command file. For example, you can not create a new HVE and map that new HVE to a front-end port in the same command file. The command file is formatted uniquely for each type of configuration change. The following are command file guidelines: Hatch marks " # " are used for remarks for both UNIX and Windows. White space in the command file is ignored. Each statement must end with a semicolon " ; ". Commas " , " are optional. The command file is case insensitive. The elements which make up a statement must be in the appropriate order. Elements can be on the same or separate lines but never abbreviated. A single element can even be split between lines so long as it remains in order. There can be as many statements in one command file as desired.
Module title, 113
Command File Argument

113
Each class of change will have command file arguments that are specific to the type of configuration changes involved. This list illustrates the variety of command file arguments. Each of these will be discussed as they pertain to a specific class of change.
Module title, 114
Configuration Management Availability

114
The availability of configuration change operations will vary depending on the version of Symmetrix Enginuity and the version of Solutions Enabler. When planning configuration changes validate all potential configuration changes are supported by your current operating environment. The engineering white paper titled Using the SYMCLI Configuration Manager should be used as a reference when planning configuration changes.
Module title, 115
Creating HVEs - Considerations

115
Creating new hyper volume extensions is considered one class of change. Creation of certain device types may require more than one class of command execution (for example a RDF protected BCV). The Symmetrix must have enough unconfigured disk space in order to create new devices. There are restrictions on the use of unprotected standard devices created by symconfigure. Such devices cannot be mapped to hosts for data storage. If an unprotected device is intended for use as a gatekeeper, it should be created with 20 cylinders or less in order to be mapped to a host. When you make a request to create a new device, you are creating a Symmetrix device that the Symmetrix system maps to a physical disk on the back end. In applying a logical volume configuration to physical disks, the Symmetrix system applies the following rules: The number of hypers on all disks should be roughly the same. All the mirrors or hypers created as a result of the create dev command file entry must be on different physical disks with different access paths (memory bus, disk directors, disk interfaces). Consider the following guidelines when creating new hyper volume extensions: Creating new HVEs lowers the write pending ceiling per device. For mirrored HVEs to be created, free space must abide by the rule of 17 (pre DMX). If a hot spare is invoked or if a device is in a Not Ready state, a commit will not succeed. You cannot create or convert to SRDF device types: When Domino mode is enabled on any current SRDF pairs; when there are any invalid tracks on any of the current SRDF devices; or when concurrent RDF is enabled on a device. When creating devices in an z/OS environment, all new devices must have the same MVS SSID and any remote devices must also have the same remote MVS SSID within a single session. To create devices with different SSID values, you will need to run more than one session. Keep in mind that creating a new device is only one step in the multi-step process required to make the device ready for use. Some types of new devices require only the step that maps the device to one or more front-end directors. Other types require additional steps.
Module title, 116
Mirror Set Protection Schemes

116
After deciding on the logical device size, the next configuration consideration is the level of protection needed for the data. Using Configuration Manager, it is possible to create unprotected storage. Keep in mind that EMC considers having unprotected storage an unsupported configuration. Supported configurations with data locally unprotected include: BCV DRV Host Level Mirroring SRDF (with links up)
Module title, 117
Free Space Considerations

117
The symconfigure list -freespace command displays the Symmetrix units free physical disk space that you can use to create new devices. The Unformatted column shows free disk space available for any emulation mode. The Formatted column shows free space on disks that have been partially used for devices configured with the same emulation mode. The free space on formatted disks can be used only to create new devices of the same emulation mode. To display free space in megabytes rather than cylinders (the default), include the units MB option on the command line.
Module title, 118
Symconfigure freespace Output

118
The output of the symconfigure fresspace command enables you to view how much available unformatted disk space is in the Symmetrix.
Module title, 119
Device Sizes

119
If creating BCVs for Timefinder or DRVs for Optimizer, ensure that these devices match the same size as the STDs that they will be paired with. EMC identifies device size in cylinder counts.
Module title, 120
Creating New HVEs Procedure

120
I/O activity occurring on a Symmetrix device before or during a commit action may cause the commit action to fail. At the very least, I/O activity on affected devices will impact the length of time that it takes to complete the configuration changes (for example, when adding a mirror). Some classes of configuration change operations, such as completely changing how a device will be used in the storage environment, require stopping I/O operations to that device (for example, before unmapping a device). If you need to stop I/O activity on any Symmetrix devices that will be altered by the change, shut down your application, unmount file systems, and suspend I/O before you issue a symconfigure commit command. In cases where there can be no I/O to a device prior to a change operation, the command will fail if this condition has not been satisfied.
Module title, 121
Creating New HVEs - Verify

121
Verify that you can open a session on the service processor. Example: symconfigure -sid 23 verify
Module title, 122
Identify Free Space

122
Identify free space location. Example: symdev list -da all space or symdisk list
Module title, 123
Create Command File

123
Create the command file. Example: create dev count=2 size=8000 emulation=fba config=2-way-mir;
Module title, 124
Command File Syntax

124
Beginning with Solutions Enabler version 5.3 and Enginuity version 5670, the Configuration Manager allows you to delete Symmetrix devices. However, a number of restrictions apply. The device to be deleted must be one of the following emulation types: FBA, CELERRA_FBA, VME_512_FBA, AS400_590, AS400_590R, AS400_6713_30, AS400_6713_50, AS400_6717_50, AS400_9337_5AA, AS400_9337_5AC. The device to be deleted cannot have an attached BCV or DRV and cannot have any snap sessions. Also the device cannot be: Mapped to a front end port Masked by VCM Held A virtual device that is in use A DRV device or BCV device (allowed with Solutions Enabler version 5.4 or higher) A meta head or a meta member WORM protected The VCM database device An SFS device Part of an RDF consistency enabled composite group A SAVE device or a COVD device
Module title, 125
Command File Parameters
Emulation Remote_config Cylinder Device_configuration Ra_group Count Size MVS_ssid Remote_MVS_ssid

125
This list represents common command file parameters when creating new hyper volumes. count = the number of devices to create. size = the size of the device needed in number of cylinders. emulation = the device emulation type config = the device configuration type. remote_config = the remote SRDF configuration ra_group = the RA group number in the SRDF environment. remote_mvs_ssid = When creating an RDF device in a remote Symmetrix array that also contains CKD devices, a z/OS (MVS) subsystem ID (remote_mvs_ssid) value may be provided. mvs_ssid = When creating a device in a Symmetrix array that also contains CKD devices, an z/OS (MVS) subsystem ID (mvs_ssid) value may be provided. ckd_meta = When creating a device with emulation type of CKD-3380 or CKD-3390, indicates that the device should be a striped meta device. savedev = When creating a device, this indicates that the device should be a save device. disk_group_num = When creating a device, this option allows you to specify a disk group. remote_disk_group_num = When creating a device, this option allows you to specify a remote disk group.
Module title, 126
Run symconfigure

126
Run the symconfigure command. Example: symconfigure sid 23 v f filename commit
Module title, 127
Update symapi_db.bin

127
Update the symapi_db.bin on all attached servers running Solutions Enabler. Example: symcfg discover
Module title, 128
Confirm New Devices

128
Confirm new devices were created. Example: symdev list
Module title, 129
Mapping and Unmapping - Considerations

129
To access a new device from a host system, you need to map the device to one or more front-end director ports and then update the host and the SYMAPI database. Front-end mapping is a Symmetrix mechanism for exporting the logical view of a device to a host system. After you map a device, the host is usually unaware of it until you run a host utility that allows the host to address the new device. To map a device, use the map command file entry to specify the front-end director number and port number. For FBA devices specify the logical unit number (LUN) for SCSI or fibre, the target ID for SCSI, the Virtual bus (vbus) address for mapping to a fibre adapter (FA) port if volume set addressing is being used (for HP-UX) or (if volume set addressing is not being used) only the LUN. For CKD devices specify the CKD device number (when mapping a CKD device to an OS/390 host). If also updating a device masking database specify the HBA identifier (WWN, AWWN, or ISCSI name). After mapping/unmapping devices update the server and then update the symapi_db.bin with the symcfg discover command. If the VCM_State bit is enabled make sure the mapped device is in the VCMDB and the VCMDB is refreshed to the channel directors. Alternately, this can be done by including the WWPN of the HBA as part of the mapping command file. When using a switch, be sure the mapped port is properly zoned. Remember the target, LUN and virtual bus emulated on the Symmetrix are always in hexadecimal format while the server is usually in decimal format.
Module title, 130
Device Addressing - SCSI

130
SCSI connections require each hyper volume to emulate a SCSI target ID and LUN when mapped to a front end port. The selected TIDs and LUNs must be available and supported on the host.
Module title, 131
Device Addressing - Peripheral

131
Peripheral addressing is used for fibre channel hosts (except HP-UX). In this case each HVE mapped to a FA port must emulate a LUN only. The FA will emulate the target ID.
Module title, 132
Device Addressing Volume Set

132
HP-UX currently uses only the Volume Set addressing method for accessing Fibre Channel devices. Volume Set addressing supports up to 16,384 addresses and up to 512 logical devices (depending on the type of host bus adapter used). In this case each HVE must emulate a target, LUN, and a virtual bus. The virtual bus number creates multiple logical controllers for each HBA thereby allowing for maximum possible addresses.
Module title, 133
Mapping Procedure

133
When mapping there is no restriction on I/O if you are adding a second path to a device that is already mapped. After committing a symconfigure mapping operation, you must update the device mapping information within the host system environment. Attempting host activity with a device after it has been removed or altered, but before you have updated the hosts device information, can cause host errors. To update your hosts, run the utilities specified for your platform. After the host environment is updated, I/O activity can resume with the Symmetrix device.
Module title, 134
Verify Session

134
Module title, 135
Select Devices to Map

135
Select the device(s) to map. Example: symdev list or symdev list noport
Module title, 136
Determine Available Host Addresses

136
Determine available host addresses. Example: symcfg list available addresses sa 5a p 0
Module title, 137
Create Command File

137
Create the command file. For peripheral device addressing (FC-SW or FC-AL) and to automatically update/refresh the VCMDB: Example: map dev 1f2 to dir 5b:0, lun=1f wwn=10000000c9224fa8; For SCSI: Example: map dev aa to dir 4a:1, target=a, lun=1d; For fibre FC-SW or FC-AL with using volume set addressing: Example: map dev c to dir 12a:1, vbus=1, target=5, lun=12;
Module title, 138
Command File Syntax

138
You can map or unmap devices to front-end directors and their ports. This is the Symmetrix Device Reallocation (SDR) feature. To map a Symmetrix device to a director and port, use the following command: map dev SymDevName to dir DirectorNum:PortNum [target=ScsiTarget,] lun=ScsiLun [, vbus=FibreVbus] [, device_number=ckd_device_number] [, awwn=awwn|wwn=wwn|iscsi=iscsi]; where: target = the SCSI target ID (hex value). lun = the SCSI logical unit number (hex value). vbus = the virtual bus (vbus) address for mapping to an FA port if using volume set addressing. device_number = the CKD device number, when mapping aCKD device to an OS/390 host. awwn = the user given name or alias WWN of a host HBA port, if updating a VCM database. wwn = the unique 64-bit World Wide Name (WWN) identifier for an HBA port, if updating a VCM database. iscsi = the iSCSI name, if updating a VCM database.
Module title, 139
Director_num Fibre_vbus Port_number SCSI_LUN SCSI_target Symdevname

139
This list represents common command file parameters when mapping or unmapping devices. Director_num = director and port number Symdevname = device to be mapped target = the SCSI target ID (hex value). lun = the SCSI logical unit number (hex value). vbus = the virtual bus (vbus) address for mapping to an FA port if using volume set addressing. These additional parameters may apply to some configurations. device_number = the CKD device number, when mapping a CKD device to an OS/390 host. awwn = the user given name or alias WWN of a host HBA port, if updating a VCM database. wwn = the unique 64-bit World Wide Name (WWN) identifier for an HBA port, if updating a VCM database. iscsi = the iSCSI name, if updating a VCM database.
Module title, 140
Run symconfigure

140
Module title, 141
Update the Server

141
Update the server: Solaris: HP: AIX: devfsadm cfgmgr reboot or rescan ioscan -FnC disk and insf e
Windows:
Module title, 142

142
Module title, 143
Verify Devices are Mapped

143
Verify devices are mapped. Example: symdev list sa 4a p 1
Module title, 144
Unmapping HVEs Procedure

144
Consider the following when unmapping devices: Never unmap a busy device. Once a device is unmapped on all ports it is automatically RW enabled. When unmapping a range of devices (if one device is already unmapped) the command will fail. Never unmap a gatekeeper youre using unless you already have another gatekeeper available to your host.
Module title, 145
Verify Session

145
Module title, 146
Select Devices to Unmap

146
Select the device(s) to unmap. symdev list If selecting device(s) on a specific port to unmap: symdev list sa xx p x If you need to see device(s) mapped to multiple ports: symdev list -multiport If you need see one device's mapping information: symdev show xxx Example: symdev show 35
Module title, 147
Stop I/O on Affected Devices

147
Stop I/O to devices that will be unmapped. (unmount, vary off, remove drive letter, etc.)
Module title, 148
Write Disable Devices

148
Place unmapping candidates in a device group if not already in one so they can be write disabled. To create a regular type of device group: symdg create unmapdg Add device(s) to device group: symld -g unmapdg add dev 55 To add a range of devices: symld -g unmapr1dg addall dev -range 34:3f To write-disable a device on all ports: symld -g unmapdg write_disable To write disable a device on a select port: symld -g unmapdg write_disable -sa 5a -p 1
Module title, 149
Create Command File

149
Create the command file: To unmap a range of devices: unmap dev ff:100 from dir 12a:0; To unmap a device: unmap dev 101 from dir 4a:0; To unmap devices from all directors: unmap dev ccd from dir all:all;
Module title, 150
Command File Syntax

150
You can map or unmap devices to front-end directors and their ports. This is the Symmetrix Device Reallocation (SDR) feature. To map a Symmetrix device to a director and port, use the following command: map dev SymDevName to dir DirectorNum:PortNum [target=ScsiTarget,] lun=ScsiLun [, vbus=FibreVbus] [, device_number=ckd_device_number] [, awwn=awwn|wwn=wwn|iscsi=iscsi]; where: target = the SCSI target ID (hex value). lun = the SCSI logical unit number (hex value). vbus = the virtual bus (vbus) address for mapping to an FA port if using volume set addressing. device_number = the CKD device number, when mapping a CKD device to an OS/390 host. awwn = the user given name or alias WWN of a host HBA port, if updating a VCM database. wwn = the unique 64-bit World Wide Name (WWN) identifier for an HBA port, if updating a VCM database. iscsi = the iSCSI name, if updating a VCM database.
Module title, 151
Director_num Fibre_vbus Port_number SCSI_LUN SCSI_target symdevname

151
This list represents common command file parameters when mapping or unmapping devices Director_num = director and port number Symdevname = device to be mapped target = the SCSI target ID (hex value). lun = the SCSI logical unit number (hex value). vbus = the virtual bus (vbus) address for mapping to an FA port if using volume set addressing. These additional parameters may apply to some configurations. device_number = the CKD device number, when mapping a CKD device to an OS/390 host. awwn = the user given name or alias WWN of a host HBA port, if updating a VCM database. wwn = the unique 64-bit World Wide Name (WWN) identifier for an HBA port, if updating a VCM database. iscsi = the iSCSI name, if updating a VCM database.
Module title, 152
Run symconfigure

152
Module title, 153
Update the Server

153
Update the server: Solaris: HP: AIX: devfsadm cfgmgr reboot or rescan ioscan -FnC disk and insf e
Windows:
Module title, 154

154
Module title, 155
Verify Devices are Unmapped

155
Verify the devices are unmapped. symdev list or symdev list noport
Module title, 156
Meta Device Considerations

156
A meta device is two or more Symmetrix hyper volumes presented to a host as a single addressable device. It consists of a meta head device, some number of member devices (optional), and a meta tail device. For Enginuity levels below 5x66, meta devices must be adjacent Symmetrix devices (formed from devices with sequential Symmetrix device numbers). For 5x66 microcode and above, the devices assigned in a meta sequence do not need to be adjacent. The meta head is the first device in the meta device and is responsible for receiving incoming commands. When an incoming command for the meta head is processed, the Symmetrix determines which meta device member should execute the command. Several operating systems, such as Windows NT and some open systems environments, can have larger volumes than are provided by standard Symmetrix devices. A meta device (volume) is a logical volume set created from individual Symmetrix hyper volumes to define volumes larger than the current Symmetrix maximum hyper volume size of approximately 15 GB. Meta devices are functionally the same as logical volume sets implemented with host volume manager software.
Module title, 157
Meta Device Types - Concatenated

157
Concatenated devices are volume sets that are organized with the first byte of data at the beginning of the first device. Addressing continues to the end of the first device before any data on the next device is referenced. When writing to a concatenated device, the first meta device member receives all the data until it is full, then data is directed to the next member and so on.
Module title, 158
Meta Device Types - Striped

158
With random I/O, striping data across multiple disk drives benefits random reads by avoiding the stacking of multiple reads to a single spindle and disk director. All patterns of I/O access are random across all members of the striped meta device. With sequential I/O, when there are many sequential I/Os pending, striping causes data to be uniformly spread out. All the Symmetrix disk spindles associated with members of the striped meta device are employed to improve I/O throughput. Striping is unrelated to data protection. Striping is simply a method of placing data on members of the meta device to enhance performance.
Module title, 159
Meta Stripe Size

159
This chart correlates stripe sizes and stripe capacity. When creating striped meta devices, you can specify stripe size either in blocks (the default) or in cylinders (you must specify cyl in the command file).
Module title, 160
Meta Device Guidelines

160
Creating meta devices is a multi-step process. For example, creating a meta RDF device requires three steps: creating devices, forming a meta device from these devices, and then converting the meta head device to an RDF device. This table shows the configuration change sessions required to form different types of meta devices: create, form, and convert.
Module title, 161
Data Preservation

161
When using the symconfigure command to manage meta devices, the data on the devices is not impacted. However, due to the reconfiguration of the changed meta device, the host may be unable to access the original data. Therefore, it is the responsibility of the attached host to handle the change to the physical geometry of the device. In general, it is wise to assume that any meta device configuration operation will affect the integrity of the data on the devices involved in that operation. When you issue a command to create a meta device, the meta members lose their independent identities and are no longer addressable by the host. In particular, you should ensure that critical data that exists on devices that will be formed into meta devices is preserved before the meta device is created. Take care to ensure that configuring a meta device does not risk any critical data on the devices that you use to form the meta device. This table shows how meta device operations impact the preservation of stored data on the devices that become meta members. The engineering white paper titled Using the SYMCLI Configuration Manager should be used as a reference when planning configuration changes.
Module title, 162
Forming Meta Devices

162
Devices must be unmapped before configuring them as either meta heads or meta members. If not, the form command for meta devices will be rejected. If you want to form SRDF-meta devices, you will need to perform several steps. SRDF devices cannot be converted into meta devices in one step. First, SRDF devices must first be converted to non-RDF devices. Next, the local devices must be converted into meta devices, separately on both Symmetrix systems in the SRDF configuration. Finally, convert the meta head on one Symmetrix to an RDF1 device, and specify the meta device on the remote Symmetrix as the RDF2 pair.
Module title, 163
Forming Meta Devices Procedure

163
When you initially create a meta device, you must form the head and add the members in the same command file. If using the count option, no members need to be specified. The configuration server will automatically select members from the pool of unmapped devices that match the meta head in size, emulation and configuration type. The following are restrictions when configuring meta devices: When configuring meta devices, the devices must be unmapped. Meta members cannot be removed from a striped meta device. To create a striped meta device, all members must be the same size and have the same mirror protection. To remove a member from a concatenated meta device, the member must be the tail. You cannot remove inner members. Only the head of a meta may have its type converted. Only the head of a meta is mapped or assigned to the host. All metas must contain at least one meta member. When a meta is formed, at least one member must be added. All meta devices must be composed of devices of the same BCV type (you must convert from RDF devices in order to change metas). Meta devices must be composed of devices that are all of the same FBA emulation type. You must create CKD meta devices using the create dev command, not the form dev command. VDEV meta devices must be composed of virtual devices that are of the same capacity, stripe size, count, and emulation type as the standard devices with which they will be used.
Module title, 164
Verify Session

164
Module title, 165
Select Devices to Form Meta

165
Select the devices to form the meta. symdev list noport
Module title, 166
Split BCV Pairs

166
Split standards and BCVs if they are used to form a meta. Example: symmir -g dgname split
Module title, 167
Remove From Device Groups

167
Remove meta member candidates from device groups Example: symld -g dgname remove DEV001 DEV006
Module title, 168
Create Command File

168
Create command file. To create a concatenated meta (manually selecting all members): form meta from dev 0b8 config=concatenated; add dev 015:016 to meta 0b8; To create a striped meta (letting the software automatically select the members): form meta from dev 011 config=striped stripe_size=1920 count=3;
Module title, 169
Command File Syntax

169
To form a meta device, use the following command: form meta from dev SymDevName, config=MetaOption [, stripe_size=<MetaStripeSize>[cyl]] [, count=<member_count>]; where: config = the meta configuration type. Possible values are concatenated or striped. stripe_size = the size of the striped meta device. This value can be expressed in blocks or cylinders. Possible sizes in 512 byte blocks are 1920, 3840, 7680, 15360, 30720, and 61440. cyl = if the stripe_size is expressed in cylinders, include cyl with the MetaStripeSize value. The size of a cylinder for FBA emulation is 960 512-byte blocks. count = the total number of devices for the configuration server to add to the new meta device, including the head. This option may be omitted if you want to specify the members using the add dev command. Next, proceed to add the command specifying the new members. Note: Omit this step if the count option was used previously with the form meta command. add dev SymDevName[:SymDevName] to meta SymDevName;
Module title, 170
BCV_meta_head Protect_Data Meta_option Meta_stripe_size Symdevname

170
This list represents common command file parameters when creating meta devices. BCV_meta_head: When adding new members to an existing, striped meta device, or when re-configuring a meta device, if the data on the meta device is to be protected, you must specify the name of a bcv_meta that matches the original meta device in capacity, stripe count, and, stripe size. Protect_data: When adding members to an existing, striped meta, you must specify whether the data on the existing meta device needs to be protected. Valid settings are TRUE and FALSE. If this option is not specified, a setting of TRUE is the default. Meta_option: The meta type configuration. Possible values are: CONCATENATED or STRIPED Meta_stripe_size: Size of a striped meta device. Stripe size can be specified in 512 byte blocks, or cylinders. If specifying cylinders, the keyword cyl must follow the size field. Recommended stripe size is 1920 (2 cylinders). Note: If no stripe size is specified when creating a striped meta, a default of 2 cylinders will be assigned. Possible sizes in 512 byte blocks are: 1920 (2 cyl), 3840 (4 cyl), 7680 (8 cyl), 15360 (16 cyl), 30720 (32 cyl), 61440 (64 cyl). Note: 1 cylinder = 960 512-byte blocks. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 171
Run symconfigure

171
Module title, 172

172
Module title, 173
Display Meta Devices

173
Display the meta device. symdev show xxx (where xxx is the meta head) or symdev list -meta
Module title, 174
Adding to a Concatenated Meta

174
Once you have successfully formed an initial meta with meta members, you can add additional meta members as necessary.
Module title, 175
Add to Concatenated Meta Procedure

175
To add additional members to an existing concatenated meta device, use the following form: add dev SymDevName[:SymDevName] to meta SymDevName;
Module title, 176
Verify Session

176
Module title, 177
Split BCV Pairs

177
Split standards and BCVs before adding to a meta device. Example: symmir -g dgname split
Module title, 178
Create Command File

178
Create the command file. To add to a concatenated meta: add dev 0b9 to meta 0b8;
Module title, 179
Run symconfigure

179
Module title, 180

180
Module title, 181
Display Meta Devices

181
Module title, 182
Removing From a Concatenated Meta Device

182
To remove a member from a concatenated meta device, the member must be the tail. You cannot remove inner members.
Module title, 183
Removing From a Concatenated Meta Procedure

183
To remove a meta member or members from the tail of a concatenated meta device, use the following form: remove dev SymDevName[:SymDevName] from meta SymDevName; Removing concatenated members will lose access to the data on the removed member. Use these commands with great caution.
Module title, 184
Verify Session

184
Module title, 185
Split BCV Pairs

185
Split meta device from BCV meta before removing member. Example: symmir -g dgname split
Module title, 186
Create Command File

186
Create the command file. To remove from a concatenated meta: remove dev 0b9 from meta 0b8;
Module title, 187
Command File Syntax

187
To remove a meta member or members from the tail of a concatenated meta device, use the following form: remove dev SymDevName[:SymDevName] from meta SymDevName;
Module title, 188
Run symconfigure

188
Module title, 189

189
Module title, 190
Display Meta Device

190
Module title, 191
Adding to a Striped Meta Device

1

191
To add additional members to an existing striped meta device, use the following form: add dev SymDevName[:SymDevName] to meta SymDevName [, protect_data=[TRUE | FALSE], bcv_meta_head=SymDevName]; where: protect_data = Possible values are TRUE or FALSE. The protect_data option is only for striped metas. When set to true, the configuration manager automatically creates a protective copy to the BCV meta of the original device striping. Because this occurs automatically, there is no need to perform a BCV establish. When enabling protection via the protect_data option, you must specify a BCV meta identical to the existing (original) striped meta. bcv_meta_head = When adding new members to an existing, striped meta device, if the data on the meta device is to be protected, you must specify the name of a bcv_meta that matches the original meta device in capacity, stripe count, and stripe size.
Module title, 192
Adding to a Striped Meta Device Procedure

192
Module title, 193
Verify Session

193
Module title, 194
Split BCV Pairs

194
Split standards and BCVs before adding them to a meta device. symmir -g xxx split symmir g dgname split
Module title, 195
Create Command File

195
Create command file. To add a device to a striped meta: add dev 444 to meta 443, protect_data=true, bcv_meta_head=333;
Module title, 196
Command File Syntax

196
To add additional members to an existing striped meta device, use the following form: add dev SymDevName[:SymDevName] to meta SymDevName [, protect_data=[TRUE | FALSE], bcv_meta_head=SymDevName]; where: protect_data = Possible values are TRUE or FALSE. The protect_data option is only for striped metas. When set to true, the configuration manager automatically creates a protective copy to the BCV meta of the original device striping. Because this occurs automatically, there is no need to perform a BCV establish. When enabling protection via the protect_data option, you must specify a BCV meta identical to the existing (original) striped meta. bcv_meta_head = When adding new members to an existing, striped meta device, if the data on the meta device is to be protected, you must specify the name of a bcv_meta that matches the original meta device in capacity, stripe count, and stripe size.
Module title, 197
BCV_meta_head Protect_Data Meta_option Meta_stripe_size Symdevname

197
This list represents common command file parameters when working with meta devices. BCV_meta_head: When adding new members to an existing, striped meta device, or when re-configuring a meta device, if the data on the meta device is to be protected, you must specify the name of a bcv_meta that matches the original meta device in capacity, stripe count, and, stripe size. Protect_data: When adding members to an existing, striped meta, you must specify whether the data on the existing meta device needs to be protected. Valid settings are TRUE and FALSE. If this option is not specified, a setting of TRUE is the default. Meta_option: The meta type configuration. Possible values are: CONCATENATED or STRIPED Meta_stripe_size: Size of a striped meta device. Stripe size can be specified in 512 byte blocks, or cylinders. If specifying cylinders, the keyword cyl must follow the size field. Recommended stripe size is 1920 (2 cylinders). Note: If no stripe size is specified when creating a striped meta, a default of 2 cylinders will be assigned. Possible sizes in 512 byte blocks are: 1920 (2 cyl), 3840 (4 cyl), 7680 (8 cyl), 15360 (16 cyl), 30720 (32 cyl), 61440 (64 cyl). Note: 1 cylinder = 960 512-byte blocks. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 198
Run symconfigure

198
Module title, 199

199
Module title, 200
Display Meta Device

200
Module title, 201
Dissolving Meta Devices

201
You can dissolve a specified meta device, which subsequently releases all its members for normal use as stand alone devices.
Module title, 202
Dissolving Meta Devices Procedure

202
A dissolve action removes the meta head and all its members. Data is not preserved. Dissolving striped or concatenated devices will lose access to data.
Module title, 203
Verify Session

203
Module title, 204
Split BCV Pairs

204
Split meta device from meta BCV before dissolving. Example: symmir -g dgname split
Module title, 205
Create Command File

205
Create the command file. To dissolve a meta: dissolve meta dev 0b8;
Module title, 206
Command File Syntax

206
To dissolve a meta device, use the following form: dissolve meta dev SymDevName; To dissolve meta device 0010, enter: dissolve meta dev 0010; A dissolve action removes the meta head and all its members.
Module title, 207
Run symconfigure

207
Module title, 208

208
Module title, 209
Display Devices

209
Verify that meta device is dissolved. symdev show xxx (where xxx is the meta head) or symdev list -meta
Module title, 210
Converting Devices

210
Users can convert an existing hyper volume from one device type to another. This class of change allows customers to make much better use of the existing capacity in the Symmetrix. The Configuration Manager allows you to reconfigure an existing device. You can: Change a devices configuration type so that the device can perform a different role. Increase or decrease device protection by adding or removing mirrors (a separate class of change). Add or remove RDF attributes. Convert a RAID-S group to a set of unprotected devices (beginning with EMC Solutions Enabler version 5.4 and Enginuity version 5670)
Module title, 211

211
When converting a devices type, you retain the same number of mirror positions. This table shows a listing of device configurations and the number of mirror positions they maintain.
Module title, 212
Converting Devices - Considerations

212
When converting devices that are currently in a device group, some groups will be declared invalid after particular operations. One example would be if you are performing TimeFinder operations and have placed in a group, one standard (STD) device and one TimeFinder (BCV) device. You now have the ability with symconfigure to change the BCV device to a non BCV device. This conversion would leave the group in an invalid state. There are two ways to handle this situation: Remove the TimeFinder (BCV) device from the group before you begin the conversion process. Or, after the device has been converted: export (symdg export) the device group and remove from the file symdg.txt the invalid device and import (symdg import) the device group.
Module title, 213
Impact on I/O

213
The following are restrictions/conditions to avoid impact on I/O activity: When adding/removing DRV attributesdevices must be unmapped. When adding/removing RDF attributesno restriction on I/O. The RDF pair must be split or failed over. If failed over, the R1 device must be unmapped. When adding/removing BCV attributesno restriction on I/O. The standard/BCV pair must be split.
Module title, 214
SRDF Device Considerations

214
Reconfiguring devices as RDF devices requires a corresponding configuration change on the remote Symmetrix unit. The symconfigure command attempts to perform local and remote changes in parallel, but if another user is executing a configuration change on the remote Symmetrix unit, then your RDF change will not be applied to either the local or remote Symmetrix unit. You can reconfigure existing devices to form an SRDF pair in which the R2 device is larger than the R1 device. This configuration can be useful if you need to migrate data from smaller devices to larger devices. Beginning with Solutions Enabler version 5.3, you can convert a static RDF device to a dynamic RDF device. You can also use a convert dev command to remove the RDF attributes from a device. When creating RDF devices, all conversions within a session must have DeviceConfig settings that reflect the same destination RDF type (RDF1 or RDF2), the same ra_group number, the same invalidate option, and the same start_copy option.
Module title, 215
Converting Devices Procedure

215
The convert command can be used for three different classes of device configuration changes, as long as the class types are performed in separate sessions. Beginning with Enginuity version 5669, changes for multiple operation classes can be executed within the same session. The three class types that cannot be used in the same session are: Add/remove BCV/DRV attributes Add/remove RDF attributes Increase/decrease mirroring Only the head of a meta device can have its type changed. The meta member(s) will automatically have the changes applied.
Module title, 216
Verify Session

216
Module title, 217
Backup Data

217
Backup data on devices to be converted.
Module title, 218
Split BCV Pairs

218
Split standards and BCVs to be converted. Remove the TimeFinder (BCV) device from the group before you begin the conversion process. Or, after the device has been converted export (symdg export) the device group and remove from the file symdg.txt the invalid device and import (symdg import) the device group.
Module title, 219
Create Command File

219
Create the command file To convert a single device: convert dev xxx to 2-way-mir; To convert a range of devices: convert dev xxx:xxx to 2-way-mir; To convert to rdf device(s): convert dev xxx to xxxxxxxx, ra_group=x, remote_dev=xxx, invalidate=xx, start_copy=xxx;
Module title, 220
Command File Syntax

220
In the command file, you can convert the configuration type of an existing device or devices using the following command: convert dev SymDevName[:SymDevName] to DeviceConfig [ ra_group=n, remote_dev=SymDevName, invalidate=R1|R2|NONE, start_copy=YES|NO ], [mvs_ssid=nnn] [raidset = TRUE]; where: SymDevName = the Symmetrix device name of the device targeted for change. To target more than one device, indicate the first and last devices in a series separated by a colon (:). DeviceConfig = the desired device configuration type. ra_group = the RA group number in the SRDF environment. remote_dev = the remote Symmetrix device name of the particular device targeted for change. If you specify a range of SymDevNames in the first line of the convert statement, the remote SymDevName value will be increased incrementally to arrive at the corresponding device number. invalidate = Specifies which RDF device (R1 source or R2 target) to invalidate. An invalidated copy requires a full refresh (synchronization of all racks) at some point. If NONE is selected, the RDF device must be specified later using the symrdf command. start_copy = Indicates whether an RDF pair should be synchronized after the configuration change is committed. mvs_ssid = Specifies the z/OS (MVS) subsystem ID that will be assigned to any device created as a result of removing any mirror(s). If not provided, the original MVS SSID will be assigned when available. raidset = When requesting to convert a RAID-S group to unprotected devices, set raidset equal to TRUE and list the first RAID-S member. It is not necessary to list the other members.
Module title, 221
Invalidate Start_copy Device_configuration Ra_group Symdevname

221
This list represents common command file parameters when converting devices. Invalidate: Specifies which RDF device (R1 source or R2 target) to invalidate. At some point, this device will need a full refresh (by synchronizing all tracks from the remote mirror). Start_copy: Indicates whether an RDF pair should be synchronized after the configuration change is committed. Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration. When this parameter is being used to apply or remove the BCV, DRV, or RDF attribute, the change will be denied if the device configuration result would change the devices mirroring. Also, cannot be used to convert RDF1 devices to RDF2 devices, which must be done using the swap ra group command. Ra_group: Integer (non-negative) specifying the SRDF device group. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 222
Run symconfigure

222
Module title, 223

223
Module title, 224
Verify Conversion

224
Verify the conversion. Example: symdev list
Module title, 225
Increasing Device Mirroring

225
The mirroring protection of a device can be increased using a separate session from BCV, DRV, and RDF change sessions. Device configuration changes to apply or remove the BCV, DRV, or RDF attribute that results in a change to the device's mirroring, will be denied. For example, converting a 2-Way-BCV to an unprotected device will be denied. This involves two changes being made to a device, removing a mirror and removing the BCV attribute. For this type of configuration, you can only remove a mirror to form a BCV device or remove the BCV attribute to form a 2-Way-MIR device. The mirroring protection of a device can also be decreased, and this too must be done via a separate session from the BCV, DRV, and RDF change sessions. As a result of removing mirrors from a device, a new device is created from the discarded mirrors, resulting in a new Symmetrix device. If the original or new device is unprotected, it cannot be mapped to a host. You cannot change a devices mirroring by converting it to other device types (i.e., from 2-Way mirror to RDF1).
Module title, 226
Mirror Positions

226
The Symmetrix unit allows you to configure up to four mirrors for each Symmetrix device. The mirror positions are designated M1, M2, M3, and M4. When a BCV device is established with a standard device as a mirror, it becomes the next available mirror. Therefore, a single BCV device can be the second, third, or fourth mirror of the standard device.
Module title, 227

227
This table shows a listing of device configurations and the number of mirror positions they maintain.
Module title, 228
Free Space Considerations

228
Before increasing device mirroring, determine the amount of unconfigured space for the new mirrors. Use the following command: symdev list da all space or symdisk list
Module title, 229
symdisk list

229
This is a sample output of the symdisk list command. Notice the two columns under Capacity. Use this information to determine if there is enough free space to support the configuration change.
Module title, 230
Increase Mirror Protection Procedure

230
Increasing mirroring adds mirror(s) to an existing device. Example: convert 2-Way-Mir to 3-Way-Mir or convert RDF1 to RDF1+Mir.
Module title, 231
Verify Session

231
Module title, 232
Select Devices

232
Select the device to which you want to add mirroring Example: symdev list
Module title, 233
Check for Unconfigured Free Space

233
Check for unconfigured free space. symdev list da all space or symdisk list
Module title, 234
Create Command File

234
Create the command file. To convert a single device: convert dev 0ba to 2-way-mir; To convert a range of devices: convert dev 02d:02e to 3-way-mir;
Module title, 235
Command File Syntax

235
In the command file, you can convert the configuration type of an existing device or devices using the following command: convert dev SymDevName[:SymDevName] to DeviceConfig [ ra_group=n, remote_dev=SymDevName, invalidate=R1|R2|NONE, start_copy=YES|NO ], [mvs_ssid=nnn] [raidset = TRUE];
Module title, 236
Device_configuration
Symdevname

236
This list represents common command file parameters when working with device mirroring. Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 237
Run symconfigure

237
Module title, 238

238
Module title, 239
Verify New Mirror Devices

239
Verify that new mirror is created. Example: symdev show xxx
Module title, 240
Decreasing Device Mirroring

240
Decreasing device mirroring could be used to make better use of the space within your Symmetrix. A good example of this class of change would be to convert some unused mirrored devices into unprotected devices, and then convert these devices to BCVs for use with Timefinder, or DRVs for use with Optimizer.
Module title, 241
Decreasing Mirroring Procedure

241
The mirroring protection of a device can also be decreased, and this must be done via a separate session from device type conversion sessions. As a result of removing mirrors from a device, a new device is created from the discarded mirrors, resulting in a new Symmetrix device.
Module title, 242
Verify Session

242
Module title, 243
Select Devices

243
Select the device from which you want to remove mirror. Example: symdev list
Module title, 244
Create Command File

244
Create the command file To convert a single device: convert dev 0b1 to unprotected; To convert a range of devices: convert dev 02b:02e to bcv;
Module title, 245
Device_configuration
Symdevname

245
This list represents common command file parameters when working with device mirroring. Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 246
Run symconfigure

246
Module title, 247

247
Module title, 248
Verify Mirror is Removed

248
Verify mirror is removed. Example: symdev list
Module title, 249
Setting Front-End Port Flags

249
There are a handful of reasons why you would want to change a front-end port flags: Changing or updating a host type on a particular port (SUN to HP) Changing fibre-channel topology (FC-AL to FC-SW) Implementing certain types of software (for example clustering software) Incorrectly changing the port flags can render your storage system inaccessible. Be sure of your needs before resetting these flags.
Module title, 250
Guidelines

250
Follow these guidelines when setting front-end port flags. Backup the symapi_db.bin to another directory. If the commit fails, it sometimes corrupts the database. Ensure there are at least two connections from the host to the Symmetrix if you will be changing port flags on the port where you are running symconfigure commands. If possible, move impacted ports offline.
Module title, 251
Setting Front-End Port Flags Procedure

251
When setting port flags, it is recommended that you temporarily suspend I/O activity to the affected ports. You can display the possible port flags and their current status with the following command: symcfg -SA all -p x -v list
Module title, 252
Verify Session

252
Module title, 253
Verify Current Flag Settings

253
Determine current flags set for the impacted port. Example: symcfg -sa xx -p x -v list
Module title, 254
Check Support Matrix

254
Check flag settings at www.emc.com, search for the support matrix. http://www.emc.com/horizontal/interoperability/interop_support_matrices.jsp
Module title, 255
Set Impacted Port Offline

255
Move the impacted port offline. Example: symcfg -sid 23 -sa xx -p x offline To verify if a port is online or offline: symcfg -sid 23 -sa all port list Confirm port(s) are offline. symcfg list sa all -port
Module title, 256
Create Command File

256
Create the command file. Example: set port xx:x flag_name=enable|disable set port 12b:0, common_serial_number=enable;
Module title, 257
Command File Syntax

257
You can set the port characteristics of a specified director using the following command: set port DirectorNum:PortNum [FlagName=enable|disable [,FlagName=enable|disable]] [fa_loop_id=integer] [hostname=HostName]; where: FlagName = A SCSI or fibre port flag. fa_loop_id = the FA director loop ID (arbitrated loop physical address). (0 - 125) (Hard Addressing must be enabled.) hostname = 12-character host name. Incorrectly changing the port flags can render your storage system inaccessible. Be sure of your needs before resetting these flags.
Module title, 258
Director_num Fa_loop_id Flag_name Hostname Port_number

258
This list represents common command file parameters when setting port flags. Director_num: The director identity number, such as 16A. Fa_loop_id: Specifies the FA director loop ID (arbitrated loop physical address). Possible integer values are from 0 to 125. Flag_name: A SCSI or fibre port flag. Hostname: 12-character host name. Port_number: Specifies the port number.
Module title, 259
Run symconfigure

259
Module title, 260
Verify Flags are Set

260
Verify flag has been changed on impacted port. Example: symcfg sa xx p x v list
Module title, 261
Set Port Online

261
Move impacted port back online. Example: symcfg sa xx p x online Confirm port(s) are online. Example: symcfg list sa all port
Module title, 262

262
Module title, 263

263
You can set the device attributes or emulation of a number of devices in a range using the following command: set device SymDevName[:SymDevName] [emulation=EmulationType] [attribute=[NO] device_attr]; where: emulation = the device emulation type, which can be fixed block architecture selections: FBA, CELERRA FBA or VME512 FBA. attribute = A device attribute that restricts how a device can be accessed. Note: When changing a devices emulation, changes can only be among FBA emulation types.
Module title, 264

264
When setting device emulations, the devices must be unmapped. There can be no I/O to the devices.
Module title, 265
Verify Session

265
Module title, 266
Select Devices

266
Select devices to set emulation. symdev list -noport or symdev show XXX
Module title, 267
Create Command File

267
Create command file: To set device emulation to Celerra_FBA: set device 0b6:0b8, emulation=CELERRA_FBA;
Module title, 268
Command File Syntax

268
You can set the device attributes or emulation of a number of devices in a range using the following command: set device SymDevName[:SymDevName] [emulation=EmulationType] [attribute=[NO] device_attr]; where: emulation = the device emulation type, which can be fixed block architecture selections: FBA, CELERRA FBA or VME512 FBA.
Module title, 269
Emulation
Symdevname

269
This list represents common command file parameters when setting device emulation. Emulation: The device emulation type, which can be fixed block architecture selections: FBA, CELERRA FBA or VME512 FBA. Symdevname: Defines the Symmetrix device name (such as 001C).
Module title, 270
Run symconfigure

270
Module title, 271
Verify Emulation is Set

271
Verify that the emulation for the device has been changed. Example: symdev show xxx
Module title, 272

272
Module title, 273
Setting Device Attributes

273
You can set a device attribute and change the device emulation type for a device or range of devices by using the set device command file entry. The following device attributes restrict how a device can be accessed: RAD, RDB_Cksum, VCMdb (only one device per Symmetrix unit can be established as a VCMdb device. It should be a mirrored device of at least 16 cylinders), Worm (Write Once Read Many). The Configuration Manager does not allow you to disable the Worm attribute. This protection is required to maintain the integrity of a true WORM environment. However, once a device has a track that is WORM protected, you can contact EMC to disable the Worm attribute if doing so becomes your requirement. Beginning with EMC Solutions Enabler version 5.1, you can also set the SCSI3_persist_reserv attribute (persistent group reservation) if you have a Sun Cluster 3.0 environment where more than two channels access the device. Three device attributes apply to non-RDF devices that you want to use as dynamic RDF devices. The dyn_rdf attribute allows a device to be either an R1 or an R2 device, providing the most flexibility in performing dynamic RDF operations. Only the dyn_rdf attribute allows you to use these devices to perform RDF swaps. The other dynamic RDF attributes, dyn_rdf1_only and dyn_rdf2_only, allow a device to be only an R1 or an R2 device, respectively. Their restriction prevents them from taking part in RDF swaps.
Module title, 274
Setting Device Attributes Procedure

274
When setting the attribute type to a mapped device, it is recommended that you minimize the I/O activity to the affected devices.
Module title, 275
Verify Session

275
Module title, 276
Select Devices

276
Select devices to which attributes will be set. symdev list or symdev show xxx
Module title, 277
Create Command File

277
Create the command file. To set the device attribute to vcmdb: set device 000 attribute=vcmdb;
Module title, 278
Command File Syntax

278
You can set the device attributes or emulation of a number of devices in a range using the following command: set device SymDevName[:SymDevName] [emulation=EmulationType] [attribute=[NO] device_attr]; where: attribute = A device attribute that restricts how a device can be accessed. Possible values include: RAD RDB_Cksum VCMdb (for Device Masking) Worm (can be enabled only) SCSI3_persist_reserv (persistent group reservation) dyn_rdf (This option provides the most flexibility in performing dynamic RDF operations) dyn_rdf1_only dyn_rdf2_only
Module title, 279
Symdevname
Attributes

279
This list represents common command file parameters when setting device attributes. Symdevname: Defines the Symmetrix device name (such as 001C). Attribute: A device attribute that restricts how a device can be accessed.
Module title, 280
Run symconfigure

280
Module title, 281
Verify Attributes are Set

281
Verify that the attribute for the device has been changed. Example: symdev show xxx
Module title, 282

282
Module title, 283
Symmetrix Metrics Max Hypers per Disk

283
You can set a limited number of Symmetrix-wide configuration parameters to allow the use of specific Symmetrix features such as creating dynamic RDF devices or Parity RAID devices. max_hypers_per_disk Specifies the maximum number of hyper volumes that can be created on physical disks in a Symmetrix unit. Possible values are from 1 to 32 or higher, based on the Enginuity version that you are running on your Symmetrix unit (beginning with Enginuity version 5568, this value can be up to 128). You cannot set this parameter to a value that is lower than the number of hypers currently existing on any device. To determine the current setting for maximum hypers, use the symconfigure list command with the verbose (v) option.
Module title, 284
Symmetrix Metrics Dynamic RDF

284
dynamic_rdf (beginning with EMC Solutions Enabler version 5.0) Enables the creation of a pool of devices that are RDF-capable, (can be dynamically assigned as RDF1 or RDF2 devices). The possible MetricValue is ENABLE or DISABLE.
Module title, 285
Symmetrix Metrics FBA Multi Access Cache

285
fba_multi_access_cache Determines whether an FBA read request can share cache slots under some conditions. It must be enabled to create Celerra FBA devices. You can set its value to ENABLE or DISABLE.
Module title, 286
Symmetrix Metrics RAID S Support

286
raid_s_support (beginning with EMC Solutions Enabler version 5.0) Supports the creation of Parity RAID-S devices on a Symmetrix unit. You can set its value to ENABLE or DISABLE (the default).
Module title, 287
Symmetrix Metrics VCMDB Restricted Access

287
VCMDB_access_restricted (beginning with EMC Solutions Enabler version 5.1) Enables you to restrict access to the device masking database to hosts that have a database entry that includes the VCMDB device. By default, all Host Bus Adapters (HBAs) that log in to the FA port to which the VCMDB device is mapped can access the database. By setting this parameter value to ENABLE, you deny database access to all hosts except those whose HBAs have added the VCMDB device through the symmask add devs command. (You can display the VCMDB device on a Symmetrix unit using the sympd list vcm command.) Prior to enabling this parameter, you should ensure that at least one host HBA has a valid database entry that includes the VCMDB device. (It is recommended that you have two HBA entries that include this device, in case of an HBA failure.) Without this VCMDB entry, no hosts can access the database. To gain access to the database again, you would need to reset this parameter to DISABLE.
Module title, 288
Symmetrix Metrics RAID S Members
RAID_S_members=3 or 7

288
raid_s_members RAID-S requires version 5.1 or higher; RAID-5, version 5.4 or higher) Specifies the number of members required when you create Parity RAID-S groups or sets, or the number of hypers (4 or 8) used to form a RAID-5 device. For RAID-S, specify a value of 3 for Parity RAID 3+1 protection, or a value of 7 for Parity RAID 7+1. If you do not set this parameter for RAIDS, the default is 3. All RAID protection groups (RAID-S or RAID-5) on a Symmetrix unit must have the same number of members.
Module title, 289
Symmetrix Metrics RAID 5 Support
RAID_S_members=4 or 8

289
raid_5_support - (beginning with EMC Solutions Enabler version 5.4) Supports the creation of RAID-5 devices on a Symmetrix unit. You can set its value to ENABLE or DISABLE (the default). Raid_s_members (RAID-S requires version 5.1 or higher; RAID-5, version 5.4 or higher) Specifies the number of members required when you create Parity RAID-S groups or sets, or the number of hypers (4 or 8) used to form a RAID-5 device. For RAID-S, specify a value of 3 for Parity RAID 3+1 protection, or a value of 7 for Parity RAID 7+1. If you do not set this parameter for RAIDS, the default is 3. All RAID protection groups (RAID-S or RAID-5) on a Symmetrix unit must have the same number of members.
Module title, 290
Setting Symmetrix Metrics Procedure

290
Setting Symmetrix configuration parameters has no impact on I/O activity.
Module title, 291
Verify Session

291
Module title, 292
Display Current Metrics

292
Determine the current metric values: Example: symconfigure -sid xx -v list
Module title, 293
Validate Max Hypers per Disk

293
If changing max hypers per disk check current highest number of HVEs per disk: symdev list -da all space or symdisk list
Module title, 294
Create Command File

294
Create the command file: To set the ceiling for the number of HVEs to be formed on any given disk: set symmetrix max_hypers_per_disk=64; To set whether read slots can be shared: set symmetrix fba_multi_access_cache=enable;
Module title, 295
Command File Syntax

295
You can set some attributes to gain access to new Symmetrix features using the following command: set Symmetrix MetricName=MetricValue [, MetricName=MetricValue]; where: MetricName = the Symmetrix metric to be set. Possible name values are: max_hypers_per_disk The maximum number of hypers that can be created on a physical disk. The possible MetricValue is from 1 to 32, or higher, based on the Enginuity version you are running. dynamic_rdf Enables the creation of a pool of devices that are RDF-capable, (can be dynamically assigned as RDF1 or RDF2 devices). The possible MetricValue is ENABLE or DISABLE. fba_multi_access_cache Determines whether a read request can share cache slots in some conditions. The possible MetricValue is ENABLE or DISABLE. raid_s_support Allows the creation and use of Parity RAID devices. The possible MetricValue is ENABLE or DISABLE. VCMDB_access_restricted Restricts access to the device masking database (VCMDB) to hosts that have a database record that includes a VCMDB device. When ENABLED, database access is restricted to all hosts except those in which the host bus adapters (HBAs) have added a VCMDB device through the symmask add devs command. The possible MetricValue is ENABLE or DISABLE. For device masking information, see the EMC Solutions Enabler Symmetrix Device Masking CLI Product Guide. raid_s_members Used to set the number of members in a Parity RAID set (RAID-S). The possible MetricValue is 3 or 7, or else set to SYMAPI_C_NA. raid_5_support Enables the ability to create RAID-5 devices in the Symmetrix. The possible MetricValue is ENABLE or DISABLE.
Module title, 296
MetricName

296
The command file parameter for setting metrics is MetricName.
Module title, 297
Run symconfigure

297
Module title, 298
Verify Metrics are Set

298
Verify that the settings have been changed. Example: symconfigure sid xx v list
Module title, 299

299
Module title, 300
Spare Disk Management

300
Beginning with EMC Solutions Enabler version 5.0, you can reserve a certain number of disks as dynamic (hot) spares. When a physical disk is reserved as a dynamic spare, it cannot be used to hold any devices. The dynamic spare disk is held in reserve to support the hypers of a Symmetrix disk that fails. When a disk fails, the dynamic spare disk is invoked against the failed disk. The Symmetrix system creates a spare disk only from a disk containing no hypers. Values for the recording format to be used on a spare disk can be either 512 or 520. You should select a format based on the type of disk that the dynamic spare will replace: For the Symmetrix 8000-series and all DMX models, use 512 for CKD and FBA type disks, and 520 for AS/400 and Tandem types. For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with selective LLF (Low-Level Format) enabled, use 512 for CKD and FBA, and 520 for AS/400 and Tandem. For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with no AS/400 or Tandem devices, use 512 for CKD and FBA type disks. For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with AS/400 or Tandem devices, use 512 for CKD, and 520 for FBA, AS/400, and Tandem.
Module title, 301
Viewing Existing Spares

301
To view the set of existing spares, use the following command: symdisk list hotspare
Module title, 302
Spare Disk Management Procedure

302
A spare disk can only be created from a new disk containing no hypers.The following are restrictions/conditions for working with hot spares: When adding or removing Symmetrix sparesno restriction on I/O. A spare cannot be removed while in use.
Module title, 303
Verify Session

303
Module title, 304
Identify Unconfigured Disks

304
Identify unconfigured disks within the Symmetrix. Example: symdisk list
Module title, 305
Create Command File

305
Create the command file. To create a hot spare: Create spare count=1, Format=512; To delete a hot spare: Delete spare disk=[2a,c,1];
Module title, 306
Command File Syntax

306
A spare disk can only be created from a new disk containing no hypers. To reserve a disk as a dynamic spare, use the following command: create spare count=n[, format = [512 | 520]]; where: count = a positive integer the defines the number of disks to be set aside as spares. format = The recording format to be used on a spare disk. Values are 512 or 520. Select a format based on the type of disk it should be able to replace.
Module title, 307
Count Format DirectorNum Da_interface Scsi_id

307
This list represents common command file parameters when working with hot spares. Count: a positive integer the defines the number of disks to be set aside as spares. Format: The recording format to be used on a spare disk. Values are 512 or 520. Select a format based on the type of disk it should be able to replace. DirectorNum: The director identity number, such as 16A. Da_interface: The DA SCSI path (c, d, e, or f). Scsi_id: The SCSI target ID (hex value).
Module title, 308
Run symconfigure

308
Module title, 309
Verify Spare Disk Configuration

309
Verify creation or deletion of spare disk. Example: symdisk list -hotspare
Module title, 310

310
Module title, 311
Swapping RDF Personalities in a RA Group

311
When you swap the devices in an RA group, you convert the personality of all the SRDF devices in the RA group and swap the polarity of any ESCON RA directors in the RA group. Source R1 devices become target R2 devices, and vice versa. The swap ra group command file entry allows you to specify the RA group, which side of RDF devices (R1 source or R2 target) to refresh from any changed data on the other side, and whether the SRDF pairs should be synchronized immediately after the configuration change is committed. For example, the following command file entry swaps the devices of RA group 1 and refreshes the R1 devices from the R2 devices (copying data from the R2 devices to the R1 devices). The start_copy option causes the synchronizing of the SRDF pairs to begin immediately after the configuration change is committed. swap ra group 1, refresh=r1, start_copy=yes; The refresh action identifies which devices do not hold a valid copy of the data before the swap operation begins. For example, after a failover from source to target, the R1 devices will no longer hold a valid copy of the data if processing continues on the R2 side. Also, after a failover, R2 writes are not propagated back to the R1 devices. If you decide not to fail back to the original host after a failover situation is corrected (there may be no reason to shut down the processing of data on the backup target system then to perform a failback operation), swapping the devices in the RA group is a useful operation. Your original target system becomes the new source system, and the original source becomes the new target. The SYMCLI command symrdf swap provides a similar swap capability, but at the device-pair level rather than the RA-group level11. If you add SRDF devices to a device group, you can use the symrdf swap command to swap the R1/R2 personality of one or more SRDF pairs that you have included in the device group. However, symrdf swap does not swap the RA director polarity as swap ra group does, and in cases where bi-directional communication is absent, swapping the director polarity and all SRDF devices in the RA group is required.
Module title, 312
Swapping RDF Personalities Procedure

312
The following are restrictions on swapping RA groups: All the devices in the RA group must be of the same type (RDF1 or RDF2) if FarPoint is enabled. Only one RA group may be swapped per configuration session. When swapping source and target attributesno restriction on I/O to R2, but no I/O allowed to the R1 device. When swapping the RA group personalities that engage ESCON directors in a FarPoint connection, be aware that FarPoint buffer settings cannot be adjusted using symconfigure. If your FarPoint buffers are set to customized parameters other than default values, an EMC representative will need to be called to adjust the buffer settings after the swap has taken place. Swapping the devices in an RA group requires a corresponding configuration change on the remote Symmetrix unit. The symconfigure command attempts to perform local and remote changes in parallel, but if another user is executing a configuration change on the remote Symmetrix unit, then your RA group swap will not be applied to either the local or remote Symmetrix unit.
Module title, 313
Verify Session

313
Module title, 314
Select RA Group to Swap

314
Select RA group to swap: Example: symrdf list
Module title, 315
Backup Data on Affected Disks

315
It is recommended to back up data on all affected devices.
Module title, 316
Create Command File

316
Create the command file: To swap rdf personalities: swap ra group=1, refresh=r2, start_copy=yes;
Module title, 317
Command File Syntax

317
Use the following form to perform an R1/R2 swap: symrdf -g DgName [-force][-symforce] [-bcv|-all] [-bypass] [-v|-noecho][-noprompt] [-i Interval] [-c Count] swap [-refresh R1|R2]
Module title, 318
Refresh Start_copy Ra_group

318
This list represents common command file parameters when swapping RDF personalities. Refresh: Specifies which RDF device (R1 source or R2 target) to refresh. Possible values are R1 or R2. Start_copy: indicates whether an RDF pair should be synchronized after the configuration change is committed. Ra_group: Specifies an integer (positive) for the RA group.
Module title, 319
Run symconfigure

319
Module title, 320

320
Module title, 321
Verify New Configuration

321
Verify new configuration symrdf list or symdev list
Module title, 322
Module 2 Summary
Key Points covered in this module: Performing configuration changes using the command line interface

322
Module title, 323
Module 3: Configuration Management GUI

After completing this module, you will be able to: Perform configuration changes using the ControlCenter GUI

323
Module title, 324
ControlCenter Console

324
Today, companies are storing ever-increasing amounts of information. As enterprise storage networks become more complex, and storage devices grow in number and size, companies are faced with the challenge of effectively managing their storage. An enterprise storage network is a collection of storage resources linked together to provide access to information from multiple platforms, operating systems, and applications across any combination of SCSI, ESCON, or Fibre Channel technologies. EMC ControlCenter is an integrated family of products that enable you to discover, monitor, automate, provision and report on networks, host resources, and storage resources across your entire information environment. From a single console, ControlCenter can monitor and manage: Connectivity components Fibre Channel switches and hubs. Host components Host operating systems, file systems, volume managers, databases, and backup applications. Storage arrays EMCs Symmetrix, CLARiiON, and other vendors storage arrays. ControlCenter shows a consolidated view of the storage environment, allowing you to monitor the health of, track the status of, report on, and control each object from a console anywhere on the network.
Module title, 325
Available Options
Delete Logical Device
New!

325
Some functions available in the command line are not available in the GUI. However, new functions are added with each ControlCenter release.
Module title, 326
Logical Device Configuration

326
Module title, 327
Logical Device Configuration

327
Module title, 328

328
Module title, 329

329
Module title, 330
SDR Device Mapping

330
Module title, 331
SDR Device Mapping

331
Module title, 332
Meta Device Configuration

332
Module title, 333
Meta Device Configuration

333
Module title, 334
Device Protection Definition

334
Module title, 335
Device Protection Definition

335
Module title, 336
Device Type Definition

336
Module title, 337
Device Type Definition

337
Module title, 338
Device Attribute Definition

338
Module title, 339
Device Attribute Definition

339
Module title, 340
Port Flag Settings

340
Module title, 341
Port Flag Settings

341
Module title, 342
SRDF Device Definition

342
Module title, 343
SRDF Device Definition

343
Module title, 344
Module 3 Summary
Key Points covered in this module: Performing configuration changes using the ControlCenter GUI

344
Module title, 345
Closing Slide

345
Module title, 346
Course Summary
Key Points covered in this course: State the fundamental concepts associated with Symmetrix configuration management Perform Symmetrix configuration changes using the command line interface Perform Symmetrix configuration changes using the ControlCenter GUI

346

Symm CFG MGT 5.2

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Symm CFG MGT 5.2

Загружено:

Авторское право:

Доступные форматы

Module title, 1

Symmetrix Configuration Management

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Symmetrix Configuration Management

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Module 1: Configuration Management Fundamentals

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Configuration Manager Introduction

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Creating New HVEs

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Mapping and Unmapping Devices

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Manage Meta Devices

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

You can increase device protection by adding a mirror.

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education

You can decrease device protection by removing a mirror.

Copyright 2004 EMC Corporation. All Rights Reserved.

Setting Front-End Port Flags

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Setting Device Emulation

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Setting Device Attributes

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Setting Symmetrix Metrics

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Spare Disk Management

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Swapping RDF Personalities within a RA Group

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

Symmetrix Architectural Overview

EMC Global Education

Copyright 2004 EMC Corporation. All Rights Reserved.

EMC Global Education