h6206 Symmetrix v Max Microsoft SQL Server Wp

8/13/2019 h6206 Symmetrix v Max Microsoft SQL Server Wp

http://slidepdf.com/reader/full/h6206-symmetrix-v-max-microsoft-sql-server-wp 1/20

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



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 THEINFORMATION 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

EMC Symmetrix V-Max and Microsoft SQL ServerApplied Technology 2



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.......................... 10 Enhanced Virtual LUN Technology .................................................................11

Using Symmetrix Quality of Service to control migrations ..................................................... 14 Additional Symmetrix V-Max with Enginuity features ...................................15

TimeFinder/Clone cascaded clones .......................................................................................... 15

TimeFinder/Snap recreate command ........................................................................................ 18

Maximum hypervolume size ...................................................................................................... 19

Conclusion ........................................................................................................20

References ........................................................................................................20




Executive summaryThe 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 andscalability 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 ofEnginuity 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-availabilityV-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 andupgrades, 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

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




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 overviewSymmetrix 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 associatedstorage 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 orSRDF® 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 singlesystem 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.




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 andthe 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 softwarefunctionality introduces significant benefits for a SQL Server environment and is detailed in the subsequent

sections.




Connectivity recommendationsSymmetrix 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 performanceimprovements, 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 aregular 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 methodologyfor 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. Notshown 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 demandingenterprise 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.

Autoprovisioning Groups for SQL ServerSymmetrix 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 deviceswith 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 muchmore 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 ofSQL 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 areautomatically 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.


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

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, andthrough 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 thisinstance, 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 10000000c975c16

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, tothe 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.




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 beencreated 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 acreate 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 210000c08b06fd83 -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 beencompleted, 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 10000000c9618be

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. Autoprovisioning Groups view for creating cluster configuration

Enhanced Virtual LUN TechnologyEnhanced 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 mostrecent 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 thelogical 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 databaseadministrator 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 migratethe 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 5devices, 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, asshown 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 tosee 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, andthe 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 andtarget 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 ofaround 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




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 otherattributes 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 Servicemechanisms 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 anew 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, thecopy 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 tothe 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 V-Max with Enginuity featuresIn 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 scalableimplementation in certain configurations.

TimeFinder/Clone cascaded clon es

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 reportinginstance. 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) isactivated, 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, whichcan be used, for example, for short-term gold copies. Administrators are therefore able to determine themost 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.




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 secondarytargets. 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 Figure15.




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 isrequired 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. Notethat 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, TimeFinderIntegration 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 theclone 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 facilitaterapid 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 trackchanged data.

Any update to source target devices after the snap session is activated causes the pre-updated data to becopied 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’trequire 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 toterminate 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 h ypervolume 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 configuredup 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 supportthe 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 provisionedenvironment.

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 thesame 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 dependenton 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 logvolume, 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




ConclusionThe 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 atiered 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 forstandard next-generation Symmetrix system volumes.

ReferencesThe 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

EMC Symmetrix V-Max and Microsoft SQL Server

Documents

h6206 Symmetrix v Max Microsoft SQL Server Wp