EMC Symmetrix V-Max and Microsoft SQL Server

Transcription

1 EMC Symmetrix V-Max and Microsoft SQL Server Applied Technology Abstract This white paper examines deployment and integration of Microsoft SQL Server solutions on the EMC Symmetrix V-Max Series with Enginuity. Details of integration with new features provided by Symmetrix V-Max arrays are documented with practical examples for storage and database administrators. April 2009

2 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 h6206 Applied Technology 2

3 Table of Contents Executive summary...4 Introduction...4 Audience... 5 Technology overview...5 Connectivity recommendations...7 Autoprovisioning Groups for SQL Server...8 Autoprovisioning Groups and Microsoft Windows Server Failover Clusters Enhanced Virtual LUN Technology...11 Using Symmetrix Quality of Service to control migrations Additional Symmetrix V-Max with Enginuity features...15 TimeFinder/Clone cascaded clones TimeFinder/Snap recreate command Maximum hypervolume size Conclusion...20 References...20 Applied Technology 3

4 Executive summary The EMC Symmetrix V-Max Series with Enginuity is a new entry in the Symmetrix family. Built on the strategy of simple, intelligent, modular storage, it incorporates a new scalable fabric interconnect design that allows the storage array to seamlessly grow from an entry-level configuration into the world s largest storage system. Symmetrix V-Max arrays provide improved performance and scalability for demanding enterprise storage environments while maintaining support for EMC s broad portfolio of platform software offerings. The Enginuity operating environment for Symmetrix version 5874 is the new, feature-rich Enginuity release supporting Symmetrix V-Max arrays. With the release of Enginuity 5874, Symmetrix V-Max systems now deliver new software capabilities that improve capacity utilization, ease of use, business continuity, and security. Symmetrix V-Max arrays introduce new levels of scalability into the Symmetrix product portfolio, by providing a superior form of scale-out design, and support for a broad new range of drive technologies as detailed in Figure 1. Symmetrix V-Max offers the ultimate in scalability for host-based workloads, including the ability to incrementally increase back-end performance by adding V-Max Engines and storage bays. Each high-availability V-Max Engine controls eight redundant Fibre Channel loops that support up to either 240 or 360 drives depending upon configuration. Subsequently, each high-availability V-Max Engine provides front-end as well as back-end connectivity, providing enhanced scalability. Figure 1. Symmetrix V-Max hardware scalability The Symmetrix V-Max systems also maintain customer expectations for high-end storage in terms of availability. High-end availability is more than just redundancy; it means nondisruptive operations and upgrades, and being always online. Symmetrix V-Max arrays provide: Nondisruptive expansion of capacity and performance at a lower price point Sophisticated migration for multiple storage tiers within the array The power to maintain service levels and functionality as consolidation grows Simplified control for provisioning in complex environments Introduction Many of the new features provided by the new EMC Symmetrix V-Max platform can reduce operational costs for customers deploying SQL Server solutions, as well as enhance functionality to enable greater benefits. This white paper details those features that provide significant benefits to customers utilizing Microsoft SQL Server. Applied Technology 4

5 Audience This white paper is intended for Microsoft SQL Server administrators, storage administrators and architects, customers, and EMC field personnel who want to understand the implementation of new features and functions that can provide additional benefits in an EMC Symmetrix V-Max environment. Technology overview Symmetrix V-Max systems offer the ultimate in performance and storage scalability, including the ability to incrementally develop back-end and front-end performance by adding V-Max Engines and associated storage bays. Each highly available V-Max Engine controls eight redundant Fibre Channel back-end loops that support up to either 240 or 360 drives depending upon configuration. Additionally, each highly available V-Max Engine provides front-end module connectivity, which provides for incremental host or SRDF connectivity as necessary. An overview of a single V-Max Engine is shown in Figure 2, with its associated front-end and back-end connectivity. Figure 2. A single Symmetrix V-Max Engine A Symmetrix V-Max array is defined by up to eight V-Max Engines, which are integrated into a single system image through their fully redundant Virtual Matrix interfaces. This Virtual Matrix Architecture allows for the online addition of V-Max Engines, providing the exceptional scalability for a V-Max array. Figure 3 details the Virtual Matrix Architecture provided by a Symmetrix V-Max array comprised of eight V-Max Engines. Applied Technology 5

6 Figure 3. Virtual Matrix Architecture The Virtual Matrix Architecture ensures that any host connected to any V-Max Engine will be able to connect to the necessary storage, irrespective of which V-Max Engine the storage is connected to. All connectivity between V-Max Engines is fully redundant against single points of failure. When a V-Max system is configured with all eight highly available V-Max Engines and a full complement of 10 storage bays, a layout as shown in Figure 4 will be created. From the labels provided in Figure 4 and the associated V-Max Engine numbers listed in the system bay, it is possible to see the relationship between V-Max Engine and storage bay connectivity. The V-Max system must grow from the inside out. Figure 4. Fully configured V-Max with eight V-Max engines Extending the scalability provided by the hardware platform of the Symmetrix V-Max array, the Enginuity operating environment for Symmetrix provides new enhancements and features. This software functionality introduces significant benefits for a SQL Server environment and is detailed in the subsequent sections. Applied Technology 6

7 Connectivity recommendations Symmetrix V-Max arrays provide a highly flexible host connectivity environment, which allows for the creation of a scalable SQL Server configuration. It is recommended to configure at least two host bus adapters (HBA) per SQL Server host with the goal of presenting multiple unique paths to the Symmetrix V- Max system across multiple directors. The benefits of multiple paths extend beyond the performance improvements, and provide for the creation of a high-availability environment when coupled with appropriate switch and Symmetrix V-Max front-end director connectivity. To provide the highest levels of availability, all single points of failure need to be addressed. While not a regular occurrence, it may be necessary to occasionally perform director maintenance, including memory upgrades. These procedures may require the removal of the director and its associated connectivity from the V-Max system. As a result, each SQL Server host should have redundant paths to multiple front-end directors. Each SQL Server host should be connected to even and odd directors within a single V-Max Engine, or across directors within multiple V-Max Engines, when available. For each HBA port, at least one discrete Symmetrix front-end port should be configured. It is recommended that each HBA port be configured to two Symmetrix front-end ports. Connectivity to the Symmetrix front-end ports should consist of first connecting unique hosts to port 0 of the front-end directors before connecting additional hosts to port 1 of the same director and processor. This methodology for connectivity ensures all front-end directors and processors are utilized, providing maximum potential performance and load balancing for I/O-intensive SQL Server database environments. Figure 5 represents a logical view of a single V-Max Engine and connectivity to two physical SQL Server environments. The configuration implements a highly available, and scalable design where SQL Server hosts are dual-pathed, and each path connects to two separate front-end modules on different directors. Not shown in this graphic is any SAN fabric that should also be configured in a highly available manner. Figure 5. Highly available connectivity for SQL Server hosts Applied Technology 7

8 Configurations with multiple paths to storage LUNs will require a path management software solution on the Windows host. The recommended solution is EMC PowerPath, which is the industry-leading path management software with benefits including: Enhanced path failover and failure recovery logic Improved I/O throughput based on advanced algorithms such as the Symmetrix Optimization load balancing and failover policy Ease of management including a Microsoft Management Console (MMC) GUI snap-in and CLI utilities to control all PowerPath features. Value added functionality including Migration Enabler, to aid with online data migration, and LUN encryption utilizing RSA technology. Product maturity with proven reliability over years of development and use in the most demanding enterprise environments. While PowerPath is recommended, an alternative is the use of the Multipath I/O (MPIO) capabilities native to the Windows operating system. The MPIO framework has been available for Windows for many years; however, it was not until the release of Windows Server 2008 where a generic device specific module (DSM) from Microsoft was included to manage Fibre Channel devices. For more information regarding the Windows MPIO DSM implementation, please see the Multipath I/O Overview at Autoprovisioning Groups for SQL Server Symmetrix V-Max with Enginuity 5874 provides administrators with a simplified model for storage provisioning. This new storage provisioning model is referred to as Autoprovisioning Groups. Historically, administrators were required to provide somewhat static relationships between storage devices with the Symmetrix array, mappings of those devices to front-end directors for host connectivity, and additionally manage masking operations to ensure that hosts were able to access the requisite storage devices. This methodology served administrators well, and these were often only required to be made once. Increasingly, administrators need to deal with a dynamic environment, where the introduction of new servers and systems occurs on a regular basis. Deployments of clustered instances of SQL Server are much more commonplace, as is the adoption of technologies such as server virtualization. To assist administrators with the ability to deal with these business challenges, EMC Symmetrix V-Max with Enginuity introduces the new Autoprovisioning Groups functionality, which maps directly into the needs of SQL Server database and storage administrators. Administrators are now able to define relationships between storage objects and host connectivity, and allow the Enginuity functionality, within the Symmetrix V-Max array, to execute the appropriate changes. This ability to create logical relationships through views also helps to ensure that appropriate devices are automatically included in changes. For example, in a cluster configuration, only a single pool of storage devices needs to be defined. Views created based on this pool of devices ensures that any hosts included in those views will be able to access the required devices. This is in contrast to a manual process where administrators may have to manually ensure that mapping and masking entries have been created. Additionally, it is possible to define storage devices in the same manner to ensure that they are appropriately managed for a virtualized environment. Hosts may use N-port ID Virtualization (NPIV) to provide a more dynamic method for allocating storage to virtual machines. NPIV initiators are processed the same as for physical Fibre Channel controller addressing. The follow steps outline the requirements for implementing Autoprovisioning Groups functionality 1. Create the storage group, which defines the specific Symmetrix devices that will be presented to the host. In the example, a storage group named SQL_raid1_devs is created, and the respective devices that represent this logical grouping are added. Applied Technology 8

9 symaccess -sid 1194 create -name SQL_raid1_devs -type storage devs 107,117,127,137,147,157,167,16F,177,17F 2. Create the director group, which defines the directors to which the devices are to be mapped, and through which the host will be able to access the devices as defined in the storage group. In this case, the group will be called SQL_Prod and will contain director ports 7e:0 and 10e:0. symaccess -sid 1194 create -name SQL_Prod -type port -dirport 7e:0,10e:0 3. Create the host initiator groups, which define the WWNs of the HBAs that are used by the host. In this instance, the host licoc213 has two HBA WWN ports, and these are configured into an initiator group that bears the hostname. symaccess -sid 1194 create -name licoc213 -type initiator -wwn c975c16b symaccess -sid 1194 add -name licoc213 -type initiator -wwn c975c16c 4. Finally, the definition of the view is created. This creates the necessary connectivity between the previously defined groups. The creation of the view will cause the Symmetrix to execute mapping and masking operations as necessary to facilitate the process. symaccess -sid 1194 create view -name 213_SQL_raid1 -storgrp SQL_raid1_devs - portgrp SQL_Prod -initgrp licoc213 Figure 6 outlines the logical connectivity that results from the preceding steps. In this example, connectivity is created between the two HBAs within server LICOC213, via the director ports defined, to the storage devices. As there are two host WWNs defined in the host group, the resulting configuration will provide the host with four paths to the defined storage. This occurs as a result of each host HBA port being able to connect to the two director ports. It will be necessary to have appropriate zoning configurations in place within any fabric to allow the respective HBAs to connect to the director ports. In the event that the storage devices have not been previously mapped to the specified directors, Symmetrix V-Max Autoprovisioning Groups functionality will add the necessary mapping, and provide a LUN ID value to the devices. Figure 6. Initiator Group implementation Once the view has been created, it is possible to list the defined views on the Symmetrix V-Max array by executing the symaccess CLI as shown in Figure 7. Applied Technology 9

10 Figure 7. Display of configured Initiator Group views In the example, two views are shown to exist within the environment. The 213_SQL_raid1 view has been created by using the initiator group licoc213 (which contains the two WWNs representing the HBAs within the host), the port group SQL_Prod (which defines the Symmetrix directors and ports to be used), and the storage group SQL_raid1_devs (which includes all the Symmetrix devices representing this storage allocation). The second entry, that of licoc140, was created from a single command line execution of a create view command. For example, it is possible to allow Symmetrix V-Max Autoprovisioning Groups to automatically define the initiator, port, and storage groups when defining the view. As an example of this functionality the following command would automatically create the necessary groups to facilitate the configuration of the view. symaccess create view licoc140 -wwn c08b06fd83 -dirport 7f:0 devs 012:015 Autoprovisioning Groups and Microsoft Windows Server Failover Clusters The Autoprovisioning Groups functionality provides significant value when storage administrators are building or deploying new Windows Servers to form a Windows Failover Cluster. If an existing set of storage and director groups has been defined, then it will only be necessary to provide information for any additional port group configuration. With the addition of the new port group defined for the new host, it is simply a matter of defining an additional view to represent the new host connectivity. Assuming that the steps defined for the initial initiator groups as outlined in the previous section have been completed, the steps required for defining storage to be used by a new server in a Windows Server Failover Cluster are outlined next. 1. Define a host initiator group for the new server, and add the relevant WWNs into the host initiator group. symaccess -sid 1194 create -name licoc220 -type initiator -wwn c9618bec symaccess -sid 1194 add -name licoc220 -type initiator -wwn c9704cb5 2. Create a new view, which encompasses the previously created storage and director groups, and includes the new initiator group for the host. symaccess -sid 1194 create view -name 220_SQL -storgrp SQL_raid1_devs -portgrp SQL_Prod -initgrp licoc220 The result of this process is shown in Figure 8. This process will significantly improve administrative processes, and should result in a reduction of errors caused by the requirement of a greater number of more complex operations. In the provided example, the same port group was utilized for both hosts; however, it is equally possible to define additional port groups if that is appropriate in the given configuration. Applied Technology 10

11 Figure 8. Autoprovisioning Groups view for creating cluster configuration Enhanced Virtual LUN Technology Enhanced Virtual LUN Technology enables transparent, nondisruptive data mobility among storage tiers within the same array and across RAID protection schemes. Enhanced Virtual LUN Technology includes full support for metavolumes. This functionality allows SQL Server administrators to extend such functionality as Database Partitioning within SQL Server to implement complete solution offerings. Currently, customers may use SQL Server Database Partitioning to implement a logical structure mapped to a physical storage layout for segmenting data for a given databases. The goal of such a database partition scheme is typically defined such that most recent data may be placed on higher performing storage, as this may represent the most accessed data, and the older data may be located on more cost-effective storage configurations. However, Database Partitioning in SQL Server is a logical operation, and switching out older partitions does not effect the underlying storage configuration. Virtual LUN technology provided by Symmetrix V- Max provides the ability to implement a physical operation against the underlying storage to match the logical Database Partition operation so as to create a full ILM solution. Enhanced Virtual LUN Technology offers two types of data movement: migration to unconfigured space and migration to configured space. In each case, the migration provides administrators the ability to move data between high-performance disks and high-capacity disks, or to dynamically populate newly added disk drives. SQL Server administrators are able to utilize this functionality in a number of ways to either address inadvertent misplacement of data LUNs on underperforming devices, or to provide a mechanism to implement Information Lifecycle Management (ILM) for databases. In the former condition, a database administrator may identify that certain database files are not performing adequately due to an inappropriate selection of RAID type, or due to placement on physical drives that are suffering from high aggregate workloads. In this case, it is possible to identify devices or free storage areas that may be used to migrate the existing LUN. The migration of the LUN will subsequently migrate the data files that reside on that LUN, while providing continuous access to the data and therefore mitigating any loss of availability for the database. Solutions Enabler provides a command line interface (symmigrate) to define and execute the migration process. In the following example of this migration capability, the migration of a LUN containing a portion of a database is being undertaken. The source volume is a eight-way striped metavolume on RAID 5 devices, and the targets of the migration are pre-existing RAID 1 devices. Thus, the migration in this instance is between RAID levels, and may have included a migration between different tiers of storage. Applied Technology 11

12 For example, it would also have been possible to migrate from slower SATA devices to higher performing 15k rpm spindles if the target devices were located on such storage. In this example, the symmigrate operation will be executed by defining an input file that will contain the necessary devices. The definition of the devices in the file migrate.txt is shown in Figure 9. Figure 9. Input file for defined migration In this example, device 17F is the source metavolume comprised of eight hypervolumes where 17F is the metavolume head. The subsequent metavolume members do not have to be listed. The subsequent list of devices defines the target devices that will be ultimately be configured as the destination metavolume. To initiate the migration process, the symmigrate command is called with the necessary parameters, as shown in Figure 10. This command will begin the migration process, and will create a session named SQL_MIG. This session name can then be used to query the state of the migration process. Figure 10. Execution of a Virtual LUN migration Figure 11 displays a partial output of the symdev show command for the source device 17F. It is possible to see the metavolume configuration, including the fact that the source is a striped metavolume. As this view was taken after the start of the migration, it is also possible to see the nature of the migration in the Mirror Set Type field, where the first mirror position shows that the source device is a RAID 5 configuration, and the secondary mirror is a RAID 1 configuration. Applied Technology 12

13 Figure 11. Display of metavolume information for migration Once the LUN migration is initiated, a copy operation begins between the source device and the target device (or free space) as defined in the command line. As a result of the copy operation, the source and target volumes are required to process the block copy operations as well as service user workloads. The extent to which the migration impacts user activity will depend on the underlying configuration and how much user activity is being generated at the same time. In Figure 12 a migration is executed while a user workload is in place. The result causes a drop in the I/O rate and also generates an increase in latency of around 2 ms. Figure 12. User workload during migration initiation In certain circumstances, administrators may want to mitigate the impact to the user workload from the migration process. Symmetrix V-Max with Enginuity allows for the dynamic modification of the migration rate through Quality of Service (QoS) functionality. Although it is important to note that reducing the migration rate, while having the effect of mitigating the impact to the user workload, will cause the Applied Technology 13

14 migration process to take longer. Administrators may modify the QoS settings as necessary during the course of operations to find the best balance of migration rates and mitigation of user performance impact. When the migration is complete, it is necessary to execute the terminate command against the session, by utilizing the session name. The current state of the migration can be queried by using the appropriate symmigrate query command. The symmigrate command can be used to show the copy rate and other attributes of the migration by using the detail option, and the iteration parameter (-i). symmigrate sid 1194 name SQL_MIG query The final step required for the migration is to execute the terminate option. Termination of the migration process is executed by calling the symmigrate command and providing the necessary options as follows. symmigrate sid 1194 name SQL_MIG terminate Upon successful termination, the original devices will be disconnected, the target volumes will now assume the primary volume status, and the original source volumes may be left disconnected or removed depending on the nature of the migration that was defined. Using Symmetrix Quality of Service to control migrations It is possible to mitigate the impact of the migration by using the Symmetrix Quality of Service mechanisms through the usage of the symqos command line interface. By default, migrations execute a mirror copy process, and will therefore proceed at the default mirror rate. This default rate, may, in certain cases, impact user workloads. It is possible to modify the mirroring pace so as to dynamically adjust this impact during the migration. To control the copy rate for the migration, a device group may be used to define the devices. In the case where no pre-existing device groups existed, it may be necessary to define a new device group that contains the LUN under migration, as defined by the following steps. 1. Create the temporary device group if one does not already exist. symdg create SQL_Mig_dev -type REGULAR 2. Add the source device under migration. symld -g SQL_Mig_dev -sid 1194 add dev 17F Once the device group has been created with the necessary devices, it is possible to utilize the symqos command to control the mirror operation. As an example, to reduce the copy operation to a copy rate of 8 (copy rates range from 0, the default, to 16), the following command may be used. symqos -g SQL_Mig_dev set MIR pace 8 Figure 13 demonstrates the impact to both the latency for read requests and the overall read I/O rate to the device being migrated, when certain QoS settings were issued. After the initialization of the migration, the copy process proceeded at the default mirror rate (0), and it is possible to see the impact to the Reads/sec rate as well as the latency as shown by sec/read. After the migration had proceeded for a period of time, the symqos command was executed to lower the priority of the mirror operation and it can be noted that the read I/O rate increased with a reduction in the latency for the read operations. Finally, the symqos command was used to return the mirror pace back to the default value for the remainder of the migration. Thus we can see the dynamic nature of the QoS mechanism for the mirroring of the migration process. Applied Technology 14

15 Figure 13. Managing migration impact with Quality of Service controls Additional Symmetrix V-Max with Enginuity features In addition to previously outlined functionality introduced by Symmetrix V-Max with Enginuity, several additional features provide value add in SQL Server environments. To extend the ability to create replicas, and provide business value, Enginuity introduces cascading TimeFinder /Clone functionality. The increased size of Symmetrix hypervolume sizes in Enginuity 5874 allows for a more scalable implementation in certain configurations. TimeFinder/Clone cascaded clones SQL Server customers often have expressed the desire to be able to create multiple replicas of a given database instance. Requirements may include the necessity to create a backup image of the given database and be able to retain that image, but then also be able to repurpose that image for a long-term reporting instance. In certain scenarios, it may be appropriate to use TimeFinder/Snap functionality, although there are cases where the length of time, or the rate of change, may make snapshot offerings a less compelling solution. TimeFinder/Clone can scale to thousands of devices and can create up to 16 targets to each source device. It also provides the flexibility of synchronizing the target volumes before the clone session (replica) is activated, also referred to as precopy, after the clone session is activate, also referred to as background copy, or let the clone devices synchronize only when data is accessed, also referred to as no-copy, which can be used, for example, for short-term gold copies. Administrators are therefore able to determine the most efficient means of executing a TimeFinder/Clone operation to meet business requirements. In cases where there is a necessity to maintain multiple full replicas, Symmetrix V-Max with Enginuity systems now provide the ability to create cascaded TimeFinder/Clone copies. These configurations allow for a TimeFinder/Clone replica to be made, and then subsequently allow for a subsequent TimeFinder/Clone replica made from the previous TimeFinder/Clone target. Such configurations allow for the production volumes to be returned to production use, while subsequent clone sessions are able to be processed. Applied Technology 15

16 Administrators may choose to create the initial TimeFinder/Clone replica to be created using products such as EMC Replication Manager or the TimeFinder Integration Utilities, such that the initial TimeFinder/Clone copy represents a valid backup environment. After the initial clone copy is created, it is possible to utilize symcli commands to execute a subsequent TimeFinder/Clone copy to be created from the initial clone environment. To create a cascaded clone environment, it is possible to utilize a single device group that contains clone target devices defined as BCVs, as the initial clone targets, and also a TGTs, which represent the secondary targets. Optionally, it is possible to simply use device files to represent the source and target definitions. For example, Figure 14 details the contents of two device files that will represent a cascaded clone relationship. SRC2TGT.TXT defines the original sources, and their initial clone targets. File TGT2TGT.TXT includes the targets of the original clone relationship and their subsequent targets. It is therefore possible to see that, for example, that the relationship for device 167 is 167! 16F! 177. Figure 14. Device files used for managing cascaded clone relationships To execute a process utilizing the device file relationships, the following steps may be executed. 1. Create TimeFinder/Clone sessions between all devices. In the example, the -precopy and -incremental options are requested. These parameters are optional, but they will ensure that the target devices will be fully copied prior to the activation of the clone, and that it is possible to incrementally re-establish the relationship when necessary. symclone -sid file src2tgt.txt create -differential precopy symclone -sid file tgt2tgt.txt create differential precopy It is possible to check the status of the -precopy operation using a query parameter as shown in Figure 15. Applied Technology 16

17 Figure 15. Clone precopy query 2. In this instance, is it assumed that the SQL Server database located on the original devices (167 and 1EF) has been shut down, the precopy process has fully completed, and the intent is to create a restartable environment from the data and log files located on those devices. If a backup image is required for recovery purposes, administrators will need to utilize the relevant Replication Manager processes of TimeFinder Integration Utility CLIs. symclone sid 1194 file src2tgt.txt activate consistent While it is not necessary to use the consistent option in the example, as the SQL Server database has been shut down, the option is presented for completeness. 3. After the initial clone targets have been activated, it is possible to activate the secondary targets. symclone sid 1194 file tgt2tgt.txt activate In this case, the consistent option is not used as it is not required. The initial clone targets are not in use at this point, and subsequently are not generating any change. After the conclusion of the process, the device states will be similar to that displayed in Figure 16. Note that the State will change to a Copied status at the end of the activate. At this point, the clone targets for both the primary and secondary clones are fully copied, and available to be utilized for business purposes. Depending on the state of the SQL Server database located on the devices, it would then be possible to attach or restore the SQL Server database on the target host. Restore operations would only be applicable, if the initial clone was created using a backup process through Replication Manager, TimeFinder Integration Utilities, or another application that can integrate with SQL Server using either VSS or VDI processing. Applied Technology 17

18 Figure 16. Clone state after activate Due to the use of the incremental option during the create process for the clone devices, it would be possible to do incremental resynchronization of the clone device to its associated source device. Administrators need to be aware that the flow of data from source to secondary target will only occur via the intermediate clone devices. Thus, it will be necessary to establish and resynchronize changes to the clone devices associated to the primary for them to be subsequently propagated to the secondary clone target. TimeFinder/Snap recreate command SQL Server customers often use TimeFinder/Snap functionality as a space-efficient mechanism to retain a point-in-time view of a source SQL Server database. Administrators utilize this functionality to facilitate rapid restore and backup of a production database system using products like EMC Replication Manager and the TimeFinder Integration Utilities, which allow for integration with VSS and/or VDI. TimeFinder/Snap software allows users to create, refresh, or restore multiple read/writeable, space-saving copies of data. TimeFinder/Snap allows data to be copied from each source device to as many as 128 target devices where the source devices can be either a (STD) device or a BCV. The target devices are Symmetrix virtual devices (VDEV) that consume negligible physical storage through the use of pointers to track changed data. Any update to source target devices after the snap session is activated causes the pre-updated data to be copied in the background to a designated shared storage pool called a save device pool. The virtual device s pointer is then updated to that location. Any subsequent updates after the first data modification won t require any further background copy. Since copy operations happen in the background, performance overhead of using TimeFinder/Snap is minimal, and the process is known as asynchronous copy on first write (ACOFW). New in Enginuity 5874 is the ability to refresh TimeFinder snapshots. Previously it was necessary to terminate an older snap session in order to create a new one. With the TimeFinder recreate command it is now more efficient to refresh old snaps without having to redefine the source and target devices Applied Technology 18

19 relationships again. This allows administrators to implement a much more timely execution of TimeFinder/Snap operations. Maximum hypervolume size Prior to Enginuity 5874, the largest single logical volume that could be created on a Symmetrix was 65,520 cylinders, or approximately GB. With Enginuity version 5874, a logical volume can be configured up to a maximum capacity of 262,668 cylinders, or approximately GB. This represents a four-fold increase as compared with Enginuity version 5773 or earlier. This simplifies storage management and provides additional flexibility, by reducing the required number of volumes to meet a given space requirement. From a performance perspective, large logical volumes should be used only when there is a strong understanding of the performance requirements for a given SQL Server workload. For example, to assign a single large logical volume that is RAID 1 protected would only allow for two physical spindles to support the workload intended for that LUN. Should the RAID protection be RAID for instance, then this concern is lessened as eight disks would be available to service the workload. To ensure the best possible performance experience, large volumes should be carefully considered in a traditional, fully provisioned environment. Large volume support provides the most value in Virtual Provisioning environments. In these environments, customers may strive to overprovision the thin pool as a means to improve storage utilization. Furthermore, Virtual Provisioning deals with the performance needs by utilizing a striping mechanism across all data devices allocated to the thin pool. Performance limits can be mitigated by the total number of spindles allocated to the thin pool (as opposed to multiple data devices allocated from the same set of spindles). Given the desire to overprovision the pool storage, it was previously required to create additional thin devices (presented to the host). With the ability to decouple the performance requirements from the storage requirements, large volume configurations provide significant value. The implication of utilizing a smaller number of large volumes extends to features such as SRDF. Using a smaller number of larger volumes, as compared to a larger number of smaller volumes, would limit the synchronous write workload capable of running in parallel to the remote site. Such configurations may create additional latency during concurrent database file writes, for example. With these considerations in mind, it is recommended to use striped metavolumes for SQL Server database file LUNs when configured from non-thin devices. The number of members in the meta will be dependent on the specific configuration, however, the goal should be to spread the metavolume and subsequently the host workload against the assigned disk group as widely as possible. For the SQL Server transaction log volume, considering that the I/O to that LUN will be serial and sequential, a striped metavolume with a large number of metamembers is not as critical. However, a striped metavolume that meets the required space requirements is still recommended. Should Virtual Provisioning be used in the environment, the wide striping inherent to this technology mitigates the need to use striped metavolumes in most environments Applied Technology 19

20 Conclusion The Symmetrix V-Max architecture implements a new strategy in the Symmetrix scale-out solutions for applications such as Microsoft SQL Server. Additionally, the Symmetrix V-Max platform provides flexible data protection options to meet different performance, availability, functionality, and economic requirements. The ability to support a wide range of service levels with a single storage infrastructure provides a key building block to implementing Information Lifecycle Management (ILM) by deploying a tiered storage strategy. These new technologies provide an easier and more reliable way to provision storage in Microsoft SQL Server environments, while enabling transparent, nondisruptive data mobility between storage tiers for standard next-generation Symmetrix system volumes. References The following can be found on Powerlink, EMC s customer- and partner-only extranet: EMC Symmetrix V-Max Best Practices Technical Note Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual LUN Technical Note Storage Provisioning with EMC Symmetrix Autoprovisioning Groups Technical Note Applied Technology 20