EMC Symmetrix VMAX and Microsoft SQL Server · PDF fileEMC Symmetrix VMAX and Microsoft SQL...

EMC Symmetrix VMAX and Microsoft SQL Server

Applied Technology

Abstract

This white paper examines deployment and integration of Microsoft SQL Server solutions on the EMC® Symmetrix® VMAX™ Series with Enginuity™. Details of integration with new features provided by Symmetrix VMAX arrays are documented with practical examples for storage and database administrators.

May 2010

Copyright © 2009, 2010 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.1

EMC Symmetrix VMAX and Microsoft SQL Server Applied Technology 2

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

Audience ...................................................................................................................................... 5 Technology overview .........................................................................................5 Connectivity recommendations.........................................................................7 Auto-provisioning Groups for SQL Server .......................................................8

Auto-provisioning Groups and Microsoft Windows Server Failover Clusters ........................ 10 Enhanced Virtual LUN Technology .................................................................11

Using Symmetrix Quality of Service to control migrations ..................................................... 14 Additional Symmetrix VMAX with Enginuity features ...................................15

TimeFinder/Clone cascaded clones .......................................................................................... 15 TimeFinder/Snap recreate command ........................................................................................ 18 Maximum hypervolume size ...................................................................................................... 19

Conclusion ........................................................................................................20 References ........................................................................................................20


Executive summary The EMC® Symmetrix® VMAX™ Series with Enginuity™ is a new entry to 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 VMAX 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 VMAX arrays. With the release of Enginuity 5874, Symmetrix VMAX systems now deliver new software capabilities that improve capacity utilization, ease of use, business continuity, and security.

Symmetrix VMAX 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 VMAX offers the ultimate in scalability for host-based workloads, including the ability to incrementally increase back-end performance by adding VMAX Engines and storage bays. Each high-availability VMAX Engine controls eight redundant Fibre Channel loops that support up to either 240 or 360 drives depending upon configuration. Subsequently, each high-availability VMAX Engine provides front-end as well as back-end connectivity, providing enhanced scalability.

Figure 1. Symmetrix VMAX hardware scalability

The Symmetrix VMAX 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 VMAX 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 VMAX 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.


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 VMAX environment.

Technology overview Symmetrix VMAX systems offer the ultimate in performance and storage scalability, including the ability to incrementally develop back-end and front-end performance by adding VMAX Engines and associated storage bays. Each highly available VMAX 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 VMAX Engine provides front-end module connectivity, which provides for incremental host or SRDF® connectivity as necessary. An overview of a single VMAX Engine is shown in Figure 2, with its associated front-end and back-end connectivity.

Figure 2. A single Symmetrix VMAX Engine

A Symmetrix VMAX array is defined by up to eight VMAX 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 VMAX Engines, providing the exceptional scalability for a VMAX array. Figure 3 details the Virtual Matrix Architecture provided by a Symmetrix VMAX array comprised of eight VMAX Engines.


Figure 3. Virtual Matrix Architecture

The Virtual Matrix Architecture ensures that any host connected to any VMAX Engine will be able to connect to the necessary storage, irrespective of which VMAX Engine the storage is connected to. All connectivity between VMAX Engines is fully redundant against single points of failure.

When a VMAX system is configured with all eight highly available VMAX 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 VMAX Engine numbers listed in the system bay, it is possible to see the relationship between VMAX Engine and storage bay connectivity. The VMAX system must grow from the inside out.

Figure 4. Fully configured VMAX with eight VMAX engines

Extending the scalability provided by the hardware platform of the Symmetrix VMAX 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.


Connectivity recommendations Symmetrix VMAX 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 VMAX 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 VMAX 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 VMAX 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 VMAX Engine, or across directors within multiple VMAX 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 VMAX 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


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 http://technet.microsoft.com/en-us/library/cc725907.aspx.

Auto-provisioning Groups for SQL Server Symmetrix VMAX with Enginuity 5874 provides administrators with a simplified model for storage provisioning. This new storage provisioning model is referred to as Auto-provisioning 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 VMAX with Enginuity introduces the new Auto-provisioning 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 VMAX 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 Auto-provisioning 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.


http://technet.microsoft.com/en-us/library/cc725907.aspx

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 10000000c975c16b symaccess -sid 1194 add -name licoc213 -type initiator -wwn 10000000c975c16c

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 VMAX Auto-provisioning 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 VMAX array by executing the symaccess CLI as shown in Figure 7.


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 VMAX Auto-provisioning 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 210000c08b06fd83 -dirport 7f:0 devs 012:015

Auto-provisioning Groups and Microsoft Windows Server Failover Clusters The Auto-provisioning 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 10000000c9618bec symaccess -sid 1194 add -name licoc220 -type initiator -wwn 10000000c9704cb5

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.


Figure 8. Auto-provisioning 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 VMAX 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.


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.


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 VMAX 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 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.


Figure 13. Managing migration impact with Quality of Service controls

Additional Symmetrix VMAX with Enginuity features In addition to previously outlined functionality introduced by Symmetrix VMAX 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 VMAX 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.


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 1194 -file src2tgt.txt create -differential –precopy symclone -sid 1194 -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.


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.


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


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 59.99 GB. With Enginuity version 5874, a logical volume can be configured up to a maximum capacity of 262,668 cylinders, or approximately 240.48 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 5 7+1 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


Conclusion The Symmetrix VMAX architecture implements a new strategy in the Symmetrix scale-out solutions for applications such as Microsoft SQL Server. Additionally, the Symmetrix VMAX 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 VMAX Best Practices Technical Note • Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual LUN Technical Note • Storage Provisioning with EMC Symmetrix Auto-provisioning Groups Technical Note


EMC Symmetrix VMAX and Microsoft SQL Server · PDF fileEMC Symmetrix VMAX and Microsoft SQL...

Documents

Transcript of EMC Symmetrix VMAX and Microsoft SQL Server · PDF fileEMC Symmetrix VMAX and Microsoft SQL...