Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups

A Detailed Review

Abstract

The EMC Symmetrix V-Max with Auto-provisioning Groups introduces a new approach to the storage provisioning process, extending EMCs long history of improving ease of use with the Symmetrix platform. Auto-provisioning Groups reduce complexity by grouping related devices, ports, and initiators, and by performing mapping and masking operations in a single step. This greatly simplifies the provisioning process for storage administrators. However, data centers must reassess their current service delivery models for storage allocation and reclamation. This white paper discusses the considerations for planning a transition to the new Auto-provisioning Groups approach. September 2009

Copyright 2009 EMC Corporation. All rights reserved. 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. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part Number h6547 Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

Table of Contents
Executive summary ............................................................................................ 4 Introduction ......................................................................................................... 5
Audience ...................................................................................................................................... 5

Storage provisioning .......................................................................................... 5

Symmetrix DMX approach to storage provisioning...................................................................... 6 Symmetrix V-Max approach to storage provisioning ................................................................... 8 Auto-provisioning Groups concepts ......................................................................................... 8 Auto-provisioning Groups using Symmetrix Management Console .......................................... 10 Reprovisioning storage .............................................................................................................. 11 Symmetrix DMX approach to storage reprovisioning............................................................. 11 Symmetrix V-Max approach to storage reprovisioning .......................................................... 12

Storage reclamation ......................................................................................... 13

Symmetrix DMX approach to storage reclamation .................................................................... 13 Symmetrix V-Max approach to storage reclamation.................................................................. 14

Planning the transition to Auto-provisioning Groups ................................... 15

Review the relationships between objects................................................................................. 15 Dynamic LUN addressing .......................................................................................................... 16 Cascaded initiator groups .......................................................................................................... 17 Naming conventions .................................................................................................................. 17 Gatekeeper devices ................................................................................................................... 18 Zoning considerations................................................................................................................ 18

Limited compatibility mode ............................................................................. 18 Backing up masking information .................................................................... 20 Conclusion ........................................................................................................ 20 Reference .......................................................................................................... 21

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

Executive summary
In the enterprise data center, storage-provisioning tasks include allocating capacity to new servers or applications, as well as expanding capacity and reclaiming storage when an application or server is decommissioned. In fact, in most environments, the No. 1 job function of a storage administrator is the provisioning of storage devices to meet the changing requirements of essential business applications. While the process is not difficult, the multistep operation involves various relationships among the storage system, SAN fabric, and host operating system. If the process is performed incorrectly, application availability is impacted. Therefore, enterprise customers have stringent change control processes to ensure repeatable success. These include documented steps for planning, validation, scheduling, and execution of all provisioning tasks. Because of the frequency and importance of the provisioning operations, the processes for performing these steps are often implemented through scripting. Well-written scripts reduce execution time, remove complexity, and reduce risk in performing provisioning operations. Scripts can also assist in system verification and troubleshooting. These tools are developed and enhanced over time, and often fully integrated into change control and into problem and incident management processes. Scripts evolve into a proven set of tools that simplify a storage administrators job. The Symmetrix V-Max provides greater capacity, better performance, and more connectivity than alternatives in the market. In designing the V-Max, a major consideration was ease of use and simplified management. With the introduction of Symmetrix V-Max and the Auto-provisioning Groups feature, EMC offers a more simplified approach to storage provisioning. Auto-provisioning Groups make provisioning operations faster and easier by allowing the storage administrator to logically group HBAs (initiators), front-end ports, and devices together, and to build masking views that associate the devices with the ports and initiators. When a masking view is created, the necessary mapping and masking operations are performed automatically to provision storage. Once a masking view has been created, any changes to the grouping of initiators, ports, or storage devices are propagated throughout the view and the mapping and masking are automatically updated as required. Autoprovisioning Groups reduce complexity, execution time labor cost, and the risk of error. This new approach significantly decreases the number of steps needed to perform all aspects of provisioning including initial provisioning, adding or removing capacity, adding or removing front-end ports, and adding or removing HBAs to and from a host, or adding or removing hosts to and from a cluster. Reducing steps reduces the overall time and risk of error. The benefits are ideally suited for todays virtual data center where servers have multiple HBAs, and are often organized into databases, virtual servers, and high availability clusters. In addition, many application environments require the ability to isolate workloads to a specific set of HBAs and other storage resources. The flexibility of Auto-provisioning Groups allows an administrator to create the required masking views to easily accommodate these requirements. Symmetrix Management Console (SMC), a graphical tool, provides an intuitive interface for performing complex operations. SMC 7.0 includes a set of wizards, templates, and filters that greatly simplify storage management tasks such as provisioning. A combination of scripts and graphical tools such as SMC provides optimum utility for routine and ad hoc operations. Moving to this new and simpler Auto-provisioning Groups approach requires organizations to reassess current provision processes. Regardless of whether scripts or the GUI is used, storage provisioning using Auto-provisioning Groups changes how storage is provisioned, and to the data center, this means updating service delivery processes and scripts. Once storage administrators understand the basic concepts, they will be confident in how Auto-provisioning Groups reduce complexity and make their job easier.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

Introduction
This white paper will show that the general process for provisioning storage with Symmetrix V-Max is similar to how it is performed on the Enginuity 5773 and earlier microcode versions that run on the Symmetrix DMX series; however, the specific commands are different, operations have been combined, and the number of discrete steps reduced. The Auto-provisioning Groups approach simplifies how storage is provisioned, but familiar processes and scripts used to perform provisioning operations and troubleshoot storage connectivity issues may need to change. To achieve the full benefit of this new and flexible approach it is necessary for data centers to review and update their end-to-end storage allocation and deallocation processes. The benefits are compelling and worth the effort. This paper discusses the differences and compares the Symmetrix DMX approach to mapping and masking with the new approach using Auto-provisioning Groups. It also discusses considerations for planning and steps for transitioning to Auto-provisioning Groups.

Audience
This white paper is intended for storage professionals who are planning the implementation of a Symmetrix V-Max system. It is specifically targeted for existing Symmetrix customers who need to understand how storage is provisioned on a Symmetrix V-Max storage system and the implications of transitioning to the Auto-provisioning Groups approach.

Storage provisioning
Storage provisioning is the process of assigning storage devices to servers, either for the initial allocation, or when additional capacity is required to support business growth. Related is storage reclamation, which is the process of removing storage devices that are no longer needed by the application server. Both provisioning and reclamation involve multiple steps that must be performed in a specific order. While the focus of this paper is on the Symmetrix storage system, the full provisioning process involves changes to the SAN fabric zoning, and configuration changes to the host and application. The following are the general steps performed on the Symmetrix when storage is provisioned to a new server. 1. 2. 3. 4. 5. Identify and select appropriate devices based on configuration type and capacity. Create metadevices if appropriate. Identify and verify paths between storage and HBAs. Map devices to appropriate front-end director ports. Mask devices to specific HBAs through specific ports.

Requirement analysis, planning, and the first three steps of the provisioning process are the same for both the Symmetrix DMX and V-Max. The last two operations are the same for both Symmetrix DMX and VMax, but the approach is different. In the following section, we will compare the two approaches to mapping and masking for initial provisioning, allocating additional capacity, and reclaiming storage when a server or application is retired. With the Symmetrix V-Max, Auto-provisioning Groups greatly simplify the provisioning process. The core concept is the logical grouping of related initiators, front-end ports, and storage devices and the creation of views that associate storage devices to front-end ports and initiators by performing the necessary device mapping and masking in a single operation. Table 1 clearly summarizes the efficiency gained with the Auto-provisioning Groups approach to mapping and masking.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

Table 1. Summary of provisioning approaches

Operation

DMX symmask approach

1. Identify next available channel address for each front-end port 2. Map devices to each frontend port 3. For each initiator to front-end port connection, create a masking entry 1. Identify next available channel address for each front-end port 2. Map devices to each frontend port 3. For each initiator to front-end port connection, create a masking entry 1. For each initiator to front-end port connection, delete the masking entry 2. For each front-end port, unmap each device

Symmetrix V-Max Autoprovisioning Groups approach

1. Create storage, port, and initiator groups 2. Create a masking view all required mapping and masking are performed automatically

Initial storage provisioning to a server

Adding additional capacity to an existing server

1. Add additional devices to the storage group all required mapping and masking are performed automatically

Storage reclamation when a server or application is retired

1. Delete the masking view all required unmapping and unmasking are performed automatically

Symmetrix DMX approach to storage provisioning

With the Symmetrix DMX, devices first map to front-end director ports, and then multiple masking entries are created defining each port-initiator-device(s) relationship. These one-to-one relationships allow fine granularity of control by defining specific connections between HBA and director ports, but can be cumbersome as the number of HBAs and servers increase. Figure 1 illustrates a server configuration that might be part of a typical virtual data center environment where multiple servers work together as a cluster and share access to the same storage. In the following discussion, this environment will be used to illustrate the steps required to provision 10 devices to a cluster of four servers using the Symmetrix DMX approach and SYMCLI. In this example devices 0030 to 0039 will be allocated to all four servers using front-end ports 7E port 1 and 8E port 1 and both HBAs on all servers.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

Figure 1. Typical server cluster environment 1. Verify physical and logical connectivity and zoning by querying the login table to determine if all HBAs on all servers have performed port logins (PLOGI) to the appropriate front-end ports. The following is an example of a command that would verify if port logins have occurred, indicating correct zoning and connectivity. symmask 2. -sid 056 list logins

Determine if the devices are currently mapped to the required front-end director ports. If the devices are not mapped, they must be mapped before continuing. The following is an example of the commands that would verify if a device is mapped to a front-end port. symdev list -fa 7e -p 1 symdev list -fa 8e -p 1 If the devices are not currently mapped, they must be mapped using an available channel address. The following is an example of the commands that would identify available channel addresses. symcfg -sid 56 symcfg -sid 56 -dir 7e -p 1 list -address available -dir 8e -p 1 list -address available

Map the devices to the front-end director ports. The following is an example of the commands that would map the devices to the front-end ports using the next available channel address identified in the previous step. symconfigure -sid 56 commit -cmd "map dev 030:039 to dir 7e:1 starting LUN=20;" symconfigure -sid 56 commit -cmd "map dev 030:039 to dir 8e:1 starting LUN=20;" 3. Mask the devices to each HBA. The following is an example of the commands that would perform the required masking. Note: Masking entries must be created for every HBA to front-end port connection.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask 4.

-sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid

56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56

add add add add add add add add add add add add add add add add

dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev

30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39 30:39

-wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn

10000000c9752325 10000000c9752325 10000000c9752326 10000000c9752326 10000000c97571F0 10000000c97571F0 10000000c97571F1 10000000c97571F1 10000000c97574F8 10000000c97574F8 10000000c97574F9 10000000c97574F9 10000000c93D02E6 10000000c93D02E6 10000000c93D02E7 10000000c93D02E7

-dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir

7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e

-p -p -p -p -p -p -p -p -p -p -p -p -p -p -p -p

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Refresh the VCM Masking Database. This notifies the front-end ports that the masking information has changed. symmask -sid 56 refresh

With the Symmetrix DMX, provisioning, mapping, and masking are performed as separate operations, and each logical connection from the host to storage is defined in a separate masking operation. While dynamic LUN addressing can be used with Symmetrix DMX, in this example the LUN address that is used by the host is the channel address that was assigned when the devices were mapped to the front-end port. In this case, Symmetrix device 30 is assigned the address of 20, device 31 would have the address of 21, and so on.

Symmetrix V-Max approach to storage provisioning

On the Symmetrix V-Max with Enginuity 5874, Auto-provisioning Groups are now the exclusive mechanism for storage provisioning. Auto-provisioning is implemented using the symaccess CLI command with Solutions Enabler 7.0 and later or using Symmetrix Management Console. With Auto-provisioning Groups, related initiators (HBAs) are grouped into an initiator group, related frontend ports are grouped into a port group, and related devices are grouped into a storage group. A masking view associates the groups together. At the time the masking view is created, all the required mapping and masking are performed automatically in a single operation. This approach dramatically reduces complexity and simplifies storage allocation.

Auto-provisioning Groups concepts

The fundamental concept of Auto-provisioning Groups is the logical grouping of related objects and the creation of a view that associates the related groups together. The following are definitions for these objects. An initiator group is a logical grouping of up to 32 Fibre Channel initiators or eight iSCSI names or a combination of both. An initiator group may also contain the name of another initiator group to allow the groups to be cascaded to a depth of one. The Cascaded initiator groups section provides more information. A port group is a logical grouping of Fibre Channel and/or iSCSI front-end director ports. The only limit on the number of ports in a port group is the number of ports in the Symmetrix V-Max; however it is likely that a port group will contain a subset of the available ports in order to isolate workloads to specific ports.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

A storage group is a logical grouping of up to 4,096 Symmetrix devices. LUN addresses are assigned to the devices in the storage group when the masking view is created using the dynamic LUN addressing feature. A masking view defines an association between one initiator group, one port group, and one storage groups. When a masking view is created, the devices in the storage group are mapped to the ports in the port group and masked to the initiators in the initiator group. Depending on the server and application requirements, each server or group of servers may have one or more masking views that associate a set of Symmetrix devices to an application, server, or cluster of servers.

Figure 2 takes the example in Figure 1 and overlays the Auto-provisioning Groups approach to storage allocation. The first step is to create the group objects: The WWNs for all HBAs are grouped together in an initiator group called App_X_Cluster_IG. The front-end ports 7e:1 and 8e:1 are grouped into a port group called App_X_Cluster_PG. The 10 devices are logically grouped into a storage group called Application_X_SG. Once the groups are created, a masking view called App_X_Cluster_View is created that associates the devices in the storage group to the ports in the port group and initiators in the initiator group. This association is what performs the mapping and masking, and does them in a single operation.

Figure 2. Auto-provisioning Groups in a cluster environment The following are the detailed steps used to implement storage provisioning for the scenario illustrated in Figure 2. 1. Verify physical and logical connectivity and zoning by verifying that all servers have performed port logins on the appropriate front-end ports. The following is an example of the command that is used to verify port logins have occurred, indicating correct zoning. The output is similar to the symmask list logins command. symaccess -sid 056 list logins 2. With Auto-provisioning Groups, there is no need to perform explicit mapping, as mapping is performed automatically when the masking view is created if the devices are not currently mapped. The following are the steps for creating the required group object used in Autoprovisioning Groups.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

a.

Create an initiator group that contains the WWNs of the HBAs for all servers in the cluster. This could be done one HBA at a time but the easiest way to do this is, using a text editor, create a file that contains WWNs of each HBA on all the servers in the cluster and specify the file when creating the initiator group. symaccess -sid 56 create -type initiator -name App_X_Cluster_IG -file .\initiator_list.txt

b.

Create a port group that contains the front-end ports that will be used by the application. In this example we are using ports 7e:1 and 8e:1. symaccess -sid 56 create -type port -name App_X_Cluster_PG -dirport 7e:1,8e:1

c.

Create a storage group that contains the devices that are used by the application. In this example, we are using devices 0030 through 0039. symaccess -sid 56 create -type storage Application_X_SG devs 0030:0039 -name

3.

Create a masking view. When this is created, the devices in the storage group will be masked to the initiators in the initiator group, and if the devices in the storage group are not currently mapped to the ports in the port group, they will be mapped using the next available channel address. Autoprovisioning uses the dynamic LUN addressing feature where each device is assigned the next available LUN address in the masking entry. This LUN address is the address seen by the host operating system and is used instead of the channel address that was assigned when the device was mapped to the front-end ports. As the masking view defines all paths to a device, using the dynamic LUN addressing feature ensures a device is assigned the same LUN address through each path to each server. symaccess -sid 56 create view -name App_X_Cluster_View -sg Application_X_SG -pg App_X_Cluster_PG -ig App_X_Cluster_IG

With the Auto-provisioning approach, mapping and masking are performed in a single operation. This approach leverages the logical grouping of objects to build many-to-many relationship between ports and initiators. Using the Symmetrix DMX approach, this took 23 separate commands. This same scenario using Auto-provisioning Groups is performed with four commands. Auto-provisioning Groups reduce complexity and saves time.

Auto-provisioning Groups using Symmetrix Management Console

Many large enterprise data centers have stringent change control processes that ensure reliable execution of any modification to their IT infrastructure. Often changes are implemented using scripts. These scripts are fully documented, reviewed, and consistently executed by all storage administrators. An alternative to scripted procedures is the Symmetrix Management Console (SMC), an intuitive graphical user interface for managing a Symmetrix. The steps using the previous CLI example can also be executed using SMC. Figure 3 summarizes the dialogs for configuring Auto-provisioning Groups using the intuitive SMC interface.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

10

Figure 3. Auto-provisioning Groups using SMC

Reprovisioning storage
Reprovisioning is the process of adding additional capacity to a host or to a cluster of hosts and involves similar steps as the initial provisioning. In many environments, reprovisioning is performed more frequently than initial provisioning. A major advantage of Auto-provisioning Groups is the ease that additional capacity is made available to a server or cluster of servers.

Symmetrix DMX approach to storage reprovisioning

Taking the previous example, if an additional 10 devices are needed to meet application requirements, the following steps would be required. 1. Determine if the required devices are currently mapped to the required front-end directors. If the devices are not mapped, they must be mapped. The following is an example of the commands that would verify if a device is mapped to a front-end director port. symdev list -fa 7e -p 1 symdev list -fa 8e -p 1 2. If the devices are not currently mapped, perform the following steps to map the devices. First, identify available channel addresses. The following is an example of the commands that would identify available channel address. symcfg -sid 56 symcfg -sid 56 3. -dir 7e -p 1 list -address available -dir 8e -p 1 list -address available

Map the devices to the front-end ports. The following is an example of the commands that would map the devices to the front-end ports.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

11

symconfigure -sid 56 commit -cmd "map dev 050:059 to dir 7e:1 starting LUN=2A;" symconfigure -sid 56 commit -cmd "map dev 050:059 to dir 8e:1 starting LUN=2A;" 4. Mask the additional devices to each HBA. The following is an example of the commands that would perform the device masking. Note: Masking entries must be created for every HBA to front-end port connection. symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask symmask 5. -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid -sid 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 add add add add add add add add add add add add add add add add dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 50:59 -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn -wwn 10000000c9752325 10000000c9752325 10000000c9752326 10000000c9752326 10000000c97571F0 10000000c97571F0 10000000c97571F1 10000000c97571F1 10000000c97574F8 10000000c97574F8 10000000c97574F9 10000000c97574F9 10000000c93D02E6 10000000c93D02E6 10000000c93D02E7 10000000c93D02E7 -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir -dir 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e 7e 8e -p -p -p -p -p -p -p -p -p -p -p -p -p -p -p -p 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Refresh the VCM Masking Database. This notifies the front-end ports that the masking information has changed. symmask -sid 56 refresh

From the example above, adding additional capacity to a host using the DMX approach requires the same steps as for initial provisioning. Again, the LUN address that is used by the host is the channel address that was assigned when the devices were mapped to the front-end port. Symmetrix device 50 would have the address of 2A; device 51 would have the address of 2B and so on.

Symmetrix V-Max approach to storage reprovisioning

On the Symmetrix V-Max, changes to the storage provisioning are made by simply updating the group membership and the changes are automatically propagated to the associated view. Following the previous example, to add 10 more devices to the cluster of servers using Auto-provisioning Groups, simply update the storage group by adding the additional devices. The following is an example of the command that would add the additional devices to the storage group. symaccess -sid 56 -name Application_X_SG -type storage add devs 0050:0059 When the storage group is modified, the changes are propagated to the masking view. If the devices that were added to the storage group are not currently mapped, they will be automatically mapped to the ports in the port group using the next available channel addresses, masked to the initiators in the initiator group, and assigned the next available dynamic LUN addresses. Similarly, changes to the port group to add or remove ports, or changes to the initiator group to add or remove HBAs are reflected in the masking view, and all the required mapping and masking operations are performed automatically. Again, Auto-provisioning Groups greatly simplify changes to storage allocation.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

12

SMC makes adding additional capacity even easier using the intuitive GUI and templates.

Storage reclamation
Storage reclamation is the process used when an application or server is decommissioned and the storage is returned to the free pool for later reuse by other applications. May customers report that this is not a process that they do well and oftentimes storage gets lost. It also could be argued that reclamation involves more risk than initial provisioning because there is live data involved and if performed incorrectly, users could experience a disruption in service. As with provisioning, reclamation requires careful planning and involves multiple steps that are performed in a specific order. While the focus of this paper is on the Symmetrix storage system, reclamation may also involve changes to the fabric zoning and configuration changes to the host and application.

Symmetrix DMX approach to storage reclamation

When a server or application is decommissioned, the request to reclaim storage may include information such as the WWNs of all HBAs, and a list of affected devices. Once again, taking the previous example, the following are the steps required to reclaim storage when an application or server is decommissioned using the Symmetrix DMX mapping and masking approach. 1. Identify the relationship among devices, HBAs, and front-end ports. The following is an example of the commands that would show this relationship. symmaskdb sid 56 list assignments dev 0030:0039,0050:0059 2. Unmask the devices on each HBA. The following is an example of the commands that would remove the masking entries. Note: Every HBA to front-end port connection must be unmasked. symmask -sid 56 -wwn 10000000c9752325 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c9752325 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c9752326 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c9752326 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97571F0 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97571F0 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97571F1 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97571F1 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97574F8 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97574F8 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97574F9 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c97574F9 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c93D02E6 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c93D02E6 remove devs 0030:0039,0050:0059 -dir 7e p 1 -dir 8e p 1 -dir 7e -p 1 -dir 8e -p 1 -dir 7e -p 1 -dir 8e -p 1 -dir 7e -p 1 -dir 8e -p 1 -dir 7e -p 1 -dir 8e -p 1 -dir 7e -p 1 -dir 8e -p 1 -dir 7e -p 1 -dir 8e -p 1

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

13

symmask -sid 56 -wwn 10000000c93D02E7 -dir 7e -p 1 remove devs 0030:0039,0050:0059 symmask -sid 56 -wwn 10000000c93D02E7 -dir 7e -p 1 remove devs 0030:0039,0050:0059 3. Refresh the VCM Masking Database. This makes the masking information change effective immediately. symmask 4. -sid 56 refresh

Unmap the devices from the front-end director ports. The following is an example of the commands that could be used. symconfigure -sid 56 commit -cmd "unmap dev 0030:0039,050:059 from dir 7e:1;" symconfigure -sid 56 commit -cmd "unmap dev 0030:0039,050:059 from dir 8e:1;"

From this example, reclaiming capacity when a host or application is decommissioned requires similar steps as were used for the initial provisioning.

Symmetrix V-Max approach to storage reclamation

With Auto-provisioning Groups, the key to ease of management is descriptive names for all groups and views. A masking view name should identify the application and/or server names. Again, when a server or application is decommissioned, the request to reclaim storage may include the application name, hostnames of the affected servers, WWNs of all HBAs, and a list of devices. Using the previous example, the following are the steps required to reclaim storage on a Symmetrix V-Max when an application is decommissioned. Note: These steps can also be easily performed using SMC. 1. As with all changes, the first step is to verify that the information provided is valid. With Autoprovisioning Groups the displayed masking view shows all relationships, making it easy to verify the information. symaccess -sid 56 show view App_X_Cluster_View 2. Unmask and unmap the devices. With Auto-provisioning Groups, this is simply a matter of deleting the masking view and the devices will be unmapped and unmasked automatically. The following is an example of the command. symaccess -sid 56 delete view -name App_Cluster_view -unmap 3. Optionally, the storage, port, and initiator groups can be removed in a similar manner. If server, ports, and storage are to be redeployed for other applications, it may not be necessary to delete these groups. Note: If these group objects are currently part of other masking views, the delete operation will fail.
symaccess -sid 56 delete -name Application_SG -type storage -force symaccess -sid 56 delete -name Shared_PG -type port force symaccess -sid 56 delete -name App_Cluster_IG -type initiator force

With Auto-provisioning Groups storage reclamation is quick and easy by simply deleting the masking view. Devices are unmapped and unmasked in a single operation. Using descriptive group and view names that associate devices with applications and servers makes the process intuitive and eliminates risk of error.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

14

Planning the transition to Auto-provisioning Groups

The Symmetrix DMX approach to provisioning creates multiple masking entries that define one-to-one relationships between initiators and targets. This enables a fine level of granularity but can be cumbersome in large environments with hundreds to thousands of connections. However, if it is desired, it is possible to use the symaccess command to build one-to-one relationships. The following is an example of a command that could be used to build a one-to-one initiator to port masking relationship. symaccess sid 56 create view -name HBA0_FA_7e:0 wwn 10000000c97574f8 dirport 7e:1 devs 020:039 However, this approach does not reduce complexity. Transitioning to Auto-provisioning Groups provides an opportunity to reassess how provisioning services are deployed and move to a more efficient approach. The true benefits of Auto-provisioning Groups are realized through the logical grouping of ports, initiators, and storage devices. Transitioning to Auto-provisioning groups begins with an assessment of the server and application requirements and the relationships between HBAs, front-end ports, and devices.

Review the relationships between objects

Auto-provisioning Groups reduce complexity by grouping related objects, and effective grouping is the key to simplifying storage management. Typically, storage objects are grouped by application, subset of an application, server, or clusters of servers. Groupings determine how the masking view is created. Each masking view contains only one storage group, one port group, and one initiator group. It is likely that a server may have multiple masking views. For example, a server may have a masking view that includes its boot volumes and local storage and another masking view that it shares with other servers in a cluster relationship. The following are some considerations when planning Auto-provisioning Groups objects. Storage groups A storage group is a logical grouping of up to 4,096 Symmetrix devices. A Symmetrix device may be a member of multiple storage groups. The same storage group could be part of multiple masking views. A single Symmetrix V-Max can have up to 8,192 storage groups. When a masking view is created, or when additional devices are added to an existing storage group that is part of a masking view, each device in the storage group is assigned a LUN address using the dynamic LUN addressing feature. Dynamic LUN addresses are the device addresses used by the host and are independent of the channel address assigned when a device is mapped to a front-end port. The LUN address assigned to each device will be consistent across all paths. Storage groups are not only used for masking operations, they are also used for other operations that require grouping such as device migration and possibly for other usage in the future.

Port groups A port group is a logical grouping of Fibre Channel and/or iSCSI front-end director ports. A single Symmetrix V-Max may be configured with up to 8,192 port groups. The number of ports in a port group is limited by the number of ports in the Symmetrix V-Max. A port may be a member of multiple port groups. The same port group can be part of multiple masking views. Front-end ports can be segregated to isolate workloads by grouping one or more ports into separate port groups and using the different port groups for different masking views. For availability and performance, devices should be mapped to two or more front-end director ports. These ports should be on different directors, and if possible, different engines. With the exception of a single engine system, the Rule of 17 can still apply.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

15

Front-end ports are typically shared between multiple servers and HBAs. Reference E-Lab Navigator on Powerlink for supported fan-out ratios. Consider actual or estimated workloads to ensure front-end ports are not oversubscribed. Ports can be added or removed from a port group as workloads change and the view is updated automatically. This allows a storage administrator to easily balance the workload across front-end directors. To be a member of a port group the ACLX flag must be enabled on the port thought the Set Port Attributes dialog of SMC or the symconfigure command. When a masking view is created and the devices in the associated storage group are not currently mapped to the ports in the port group, they will automatically be mapped using the next available channel address. On the Symmetrix V-Max, the channel address assigned to the device on the port is not visible to the host. Instead, the assigned dynamic LUN address is what is visible to the host.

Initiator groups Initiator groups are the logical grouping of up to 32 Fibre Channel initiators or eight iSCSI names or a combination of both. A single Symmetrix V-Max may be configured with up to 8,192 initiator groups. An initiator may belong to only one initiator group. An initiator group may also contain the name of another initiator group to allow the groups to be cascaded to a depth of one. See the section Cascaded initiator groups. Port flags may be set on an initiator group basis, with one set of port flags applying to all initiators in the group. Generally the more paths in an initiator group, the greater the management efficiency. While it is possible to define an initiator group with a single HBA and create a view for each HBA, additional efficiency is gained by grouping related HBAs. An empty initiator group may be created as a placeholder and used to create a masking view. HBAs could be added to the initiator group later and the masking view would be updated and the required mapping and masking performed automatically. (This approach is useful when planning a new server installation and the actual WWNs are unknown, yet is desirable to build the groups and preallocate the storage.)

Dynamic LUN addressing

Starting with Enginuity 5772, the optional dynamic LUN addressing feature provides a more flexible approach to device addressing by eliminating the direct connection between the channel address that is assigned when a device is mapped to a front-end director port and the Logical Unit Number (LUN) that is visible to the host. Instead, when creating a masking entry, a storage administrator assigns either a specific LUN address or the next available LUN address is automatically assigned, and this LUN address is what is visible to the host system. Dynamic LUN addressing eliminates many host-addressing issues as it provides each host its own address space that is independent of the channel address on the front-end port. For example, many hosts are limited to 256 devices with addresses in the range of 00-FF (0-256). It also enables all hosts that share a FA port to have a LUN with an address that starts with 0. With Symmetrix DMX, dynamic LUN addressing is optional. On the Symmetrix V-Max with Autoprovisioning Groups, dynamic LUN addressing is an integral part of the provisioning process. With the DMX masking approach, a separate masking entry is configured for each path and potentially different LUN addresses could be applied to different paths to the same device. With Auto-provisioning Groups, the masking view defines all paths between the initiators and front-end ports and the dynamic LUN address associated with the view. This ensures the same address is assigned to the device for all paths. Many cluster applications such as VMware ESX require the same LUN address for all paths. The dynamic LUN address feature eliminates the potential of inconsistent LUN addresses for the same device on different paths and simplifies the provisioning process.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

16

Cascaded initiator groups

A HBA can only belong to a single initiator group. However, cascaded initiator groups can be configured to allow an initiator group to be a member of another initiator group. A cluster is a good example of where cascaded initiator groups might be appropriate. Figure 4 illustrates an example of cascaded initiator groups. Here, initiator groups are created for each server containing all HBAs for that server. These initiator groups are used to create a masking view that contains all devices that are used exclusively by that server. For example, it may contain the boot device, dedicated gatekeeper devices, and devices used for non-clustered applications. Next, a cascaded initiator group is created that contains the initiator groups for each server in a cascaded configuration. Using the cascading initiator group, another masking view is created that contains a storage group with all devices that are shared by all servers in the cluster.

Figure 4. Cascaded initiator groups Cascading of initiator groups is only allowed to a depth of one that is, an initiator can be part of an initiator group, which in turn can be part of another initiator group. An initiator group can be a member of only one masking view; however, an initiator group can be a member of multiple cascaded initiator groups and each cascaded initiator group can be associated with different masking views. A cascaded initiator group can have a maximum of 1,024 initiators total. When configuring cascaded initiator groups in a cluster environment, it is possible to have a different number of devices assigned to each host. When a view is created that spans multiple servers, a consistent dynamic LUN address will be applied but this may result in non-consecutive addresses and holes in the address range.

Naming conventions
One of the advantages of Auto-provisioning Groups is when well-thought-out naming conventions are applied for all group objects and views. These conventions help document the system. Initiative naming is particularly useful postimplementation when supporting and troubleshooting connectivity issues. A best practice is to adopt standard naming conventions for storage, port, and initiator groups, and masking views. A name can be up to 64 alphanumeric characters in length and may include the hyphen (-) and underscore (_) special characters. While the maximum name length is 64 characters, some CLI command output will truncate names longer than 20 characters. Group names are not case-sensitive, and Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

17

groups of different types may share a common name. The guidelines are flexible to meet the unique requirements of any organization; however, a combination of server and or application names may be appropriate for many environments. To be effective, naming standards must be consistently utilized and understood by all administrators.

Gatekeeper devices
Gatekeepers are small devices used by Solutions Enabler for communications between a management host and Symmetrix. In the past, the best practice was not to multipath gatekeeper devices; instead gatekeepers were configured with only a single path. Today, multipathing gatekeeper devices is an accepted practice and gatekeepers can be part of the same masking view as a production data device. However, it is still a best practice not to share gatekeeper devices between servers.

Zoning considerations
Fabric zoning provides logical connectivity between a HBA and a Symmetrix front-end port. Fabric zoning is independent of the mapping and masking that are performed using Auto-provisioning Groups. The best practice of only mapping and masking devices to initiators and ports that are zoned no longer applies with Auto-provisioning Groups. A proper SAN design includes full redundancy and in many cases this means two independent fabrics.

Limited compatibility mode

Storage provisioning for both Symmetrix DMX and Symmetrix V-Max involves mapping and masking operations; however, the approach and the specific commands are very different. Many customers have proven scripted procedures for storage allocation and deallocation. To allow customers to use their familiar symmask-based approach to provisioning as they update their existing procedures to Auto-provisioning Groups, EMC provides a limited compatibility mode. Supported are the ability to use the symmask command to create, modify, and delete masking entries, and the ability to perform basic queries of the masking database using the symmaskdb list database command. It is not the intention to provide the full capability of the symmask and symmaskdb commands on the Symmetrix V-Max, rather enough capability to use familiar processes to initially deploy a Symmetrix V-Max. Before getting into the details of compatibility mode, it is important to review the fundamental differences between the two provisioning approaches. The DMX approach for masking is based on one-to-one relationships between one initiator and one port. When using the symmask command separate masking entries are created for each connection defining the specific initiator and port relationship. When masking devices for a server, every initiator-to-port relationship must be defined separately. With Auto-provisioning Groups, the underlying masking principle is based on many-to-many relationship. That is, multiple initiators are associated with multiple ports. When a masking view is created, the relationship between all initiators in the initiator group and all ports in the port group is formed. This difference is reflected in the format and structure of the masking database. With compatibility mode, the symmask command can be used to create masking entries; however the result is the creation of a storage, port, and initiator group, and an associated masking view. These group objects are created with one-to-one relationships. That is, one masking view is created for each initiator to front-end port relationship. The view consists of an initiator group with a single initiator, a port group with a single port, and a storage group with all the devices. Using the command below as an example: symmask -sid 56 add dev 30:39 -wwn 10000000c9752325 -dir 7e -p 1 The following groups and masking view are created automatically: An initiator group with the name 10000000c9752325 that includes one HBA A port group with the name 10000000c9752325_7E_1 that includes the single port 7E:1 A storage group with the name 10000000c9752325_7E_1 that includes devices 0030:0039

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

18

A masking view with the name 10000000c9752325_7E_1 that associates these three groups

Using the environment previously discussed as an example, and configuring all masking using compatibility mode would result in the automatic creation of the groups and views as displayed using SMC in Figure 5.

Figure 5. Group object created using compatibility mode Notice initiator groups are created for each HBA, and port groups, storage groups, and masking views for each initiator and port connection. While compatibility mode results in the correct masking, it does not reduce complexity. Compatibility mode is provided to ease the transition to Auto-provisioning Groups. EMC recommends that customers update their storage provisioning process to use the more efficient Auto-provisioning Groups structures. If it is not possible to transition immediately to Auto-provisioning Groups, compatibility mode can be used, but it is critical that storage architects and administrators understand the limitations before proceeding. Some of the limitations of compatibility mode are listed next. Compatibility mode offers no control on naming of groups and views. The automatically generated groups are based on the WWN or iSCSI name of the initiator. With Auto-provisioning Groups, descriptive naming conventions can be specified and this is a cornerstone for ease of management. Masking entries can be created only by using the symaccess CLI. SMC does not support compatibility mode. However, SMC can be used to display the resulting group and view objects. SMC should not be used to modify any of the groups or views created using compatibility mode. Only one approach for masking is allowed. A system cannot have masking entries that were created using symmask compatibility mode and other entries using symaccess and Auto-provisioning Groups. If masking entries are created using compatibility mode and then a masking entry is created using the symaccess command, subsequent execution of the symmask command will error, but the

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

19

symmask masking entries will continue to be valid yet must be updated going forward using only the symaccess command. Using symmask commands on Symmetrix V-Max produces some differences in behavior. For example, a dynamic LUN address is always used, and the symmask command will automatically map devices if they are not mapped. Compatibility mode provides limited ability to query masking information using the symmaskdb command. The symmaskdb list database command is available but the output will be in a slightly different format. This is because the masking databases have fundamentally different structures. Limitations include no direct equivalent symmaskdb list assignments or symmaskdb list capacity commands. However, similar information can be derived from displaying the masking view details using the command symaccess show view. If compatibility mode is deployed and later decided to move to a more efficient grouping, the process will require multiple steps and could compromise high availability as merging masking views requires dissolving one of the view, which would take a path offline.

Backing up masking information

Similar to the Volume Logix (VCM) database in Symmetrix DMX, the Access Logix (ACLX) database used with Auto-provisioning Groups on the Symmetrix V-Max resides in the internal Symmetrix file system and is not directly accessible by an administrator. As with other critical configuration information, it is a best practice to back up the ACLX database periodically to provide protection against corruption or accidental or malicious deletion of masking information. Using the symaccess command, you can back up the ACLX database to a specific file on the local management server. The following is an example of this command: symaccess -sid 1234 backup -f backup_090909 The backup file can be used to restore the masking information. A restore will overwrite the current masking information with the masking views contained in the backup file. This must be performed with extreme caution, since other configuration changes could have occurred since the backup, making some or all of the masking information invalid. A restore is limited by the following considerations. Ports will be returned to port groups only if they have the ACLX attribute set. Devices will be returned to storage groups if they are devices that can be masked. Views will be restored only if the port and storage groups contain valid entries LUN information will be restored if valid for port settings.

The backup file can also be used with the symaccess commands to query masking information by using the -file option instead of sid.

Conclusion
With Symmetrix V-Max, Auto-provisioning Groups greatly simplify the provisioning process. The core concept is the logical grouping of related initiators, front-end ports, and storage devices and the creation of views that associate storage devices to front-end ports and initiators by performing the necessary device mapping and masking in a single operation. Transitioning from the symmask approach to storage provisioning to Auto-provisioning Groups simplifies storage provisioning but changes how an organization allocates and deallocates storage. There are differences with the commands used, but also people and process impacts. Existing processes and procedures need to be updated, and changes made to proven scripts and utilities that storage administrators use on a daily basis. Knowledge is the key to success. Understanding the principles of Auto-provisioning Groups is the first step to successful deployment and is necessary to achieve the full benefits of the most efficient and flexible storage provisioning process. Formal or Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

20

informal training is recommended for all storage administrators and architects who are involved in the planning, implementation, and ongoing support of the provisioning process. Finally, while provisioning processes are often implemented using custom scripts, Symmetrix Management Console with its filters, templates, and wizards further simplifies the process of storage provisioning and should be considered when revising the provisioning process.

Reference
For more examples on using the symaccess command, the Storage Provisioning with EMC Symmetrix Autoprovisioning Groups Technical Note available on Powerlink is highly recommended.

Storage Provisioning: Transitioning to EMC Symmetrix V-Max Auto-provisioning Groups A Detailed Review

21