Beruflich Dokumente
Kultur Dokumente
July, 2015
To learn more about how EMC products, services, and solutions can help solve your business and IT challenges, contact your local
representative or authorized reseller, visit www.emc.com, or explore and compare products in the EMC Store.
TABLE OF CONTENTS
EXECUTIVE SUMMARY .............................................................................. 5
AUDIENCE ......................................................................................................... 5
CONCLUSION .......................................................................................... 33
APPENDIXES........................................................................................... 34
Appendix I - Configuring SQL Server database storage groups for replication .......... 34
Appendix II SRDF modes and topologies .......................................................... 36
Appendix III Solutions Enabler CLI commands for TimeFinder SnapVX
management ................................................................................................... 38
Appendix IV Solutions Enabler CLI commands for SRDF Management .................. 40
APPENDIX V - Symntctl VMAX integration utility for windows disk management ....... 41
APPENDIX VI Scripting attach or detach FOR a SQL Server database using
WINDOWS POWERSHELL .................................................................................. 43
Appendix VII Example outputs ........................................................................ 44
EXECUTIVE SUMMARY
Many applications are required to be fully operational 24x7x365 and the data for these applications continues to grow. At the same
time, their RPO and RTO requirements are becoming more stringent. As a result, there is a large gap between the requirements for
fast and efficient protection and replication, and the ability to meet these requirements without overhead or operation disruption.
These requirements include the ability to create local and remote database replicas in seconds without disruption of Production host
CPU or I/O activity for purposes such as patch testing, running reports, creating development sandbox environments, publishing data
to analytic systems, offloading backups from Production, Disaster Recovery (DR) strategy, and more.
Traditional solutions rely on host-based replication. The disadvantages of these solutions are the additional host I/O and CPU cycles
consumed by the need to create such replicas, the complexity of monitoring and maintaining them across multiple servers, and the
elongated time and complexity associated with their recovery.
TimeFinder local replication values to Microsoft SQL Server include1:
The ability to create instant and consistent database replicas for repurposing, across a single database or multiple databases,
including external data or message queues, and across multiple VMAX3 storage systems.
TimeFinder replica creation or restore time takes seconds, regardless of the database size. The target devices (in case of a
replica) or source devices (in case of a restore) are available immediately with their data, even as incremental data changes are
copied in the background.
VMAX3 TimeFinder SnapVX snapshots are consistent by default. Each source device can have up to 256 space-efficient
snapshots that can be created or restored at any time. Snapshots can be further linked to up to 1024 target devices,
maintaining incremental refresh relationships. The linked targets can remain space-efficient, or a background copy of all the data
can take place, making it a full copy. In this way, SnapVX allows unlimited number of cascaded snapshots. 1
Synchronous and Asynchronous consistent replication of a single database or multiple databases, including external data or
message queues, and across multiple VMAX3 storage array systems if necessary. The point of consistency is created before a
disaster strikes, rather than taking hours to achieve afterwards when using replications that are not consistent across
applications and databases.
Disaster Recovery (DR) protection for two or three sites, including cascaded or triangular relationships, where SRDF always
maintains incremental updates between source and target devices.
SRDF and TimeFinder are integrated. While SRDF replicates the data remotely, TimeFinder can be used on the remote site to
create writable snapshots or backup images of the database. This allows DBAs to perform remote backup operations or create
remote database copies.
SRDF and TimeFinder can work in parallel to restore remote backups. While a remote TimeFinder backup is being restored to the
remote SRDF devices, in parallel SRDF copies the restored data to the local site. This parallel restore capability provides DBAs
with faster accessibility to remote backups and shortens recovery times.
AUDIENCE
This white paper is intended for database administrators, storage administrators, and system architects who are responsible for
implementing, managing, and maintaining SQL Server databases and EMC VMAX3 storage systems. It is assumed that readers have
some familiarity with Microsoft SQL Server and the VMAX3 family of storage arrays, and are interested in achieving higher database
availability, performance, and ease of storage management.
1
EMC AppSync has been updated to include support for SnapVX and allow for SQL Server integration through the use of VDI at the application and
operating system level. Please check the latest release notes and support matrix for AppSync to ensure support for SnapVX. One of the benefits of
TimeFinder SnapVX in the context of EMC AppSync will be the ability for application administrators to be able to manage application-consistent copies of
SQL Server databases.
Description
SQL Server distinguishes between a restartable and recoverable database. A restartable state
database
requires all log data to be consistent (see Storage consistent replications). SQL Server can be
simply started and perform automatic crash/instance recovery without user intervention. A
recoverable state requires a database media recovery, rolling forward transaction log to achieve
data consistency before the database can be opened.
Recovery Time Objective (RTO) refers to the time it takes to recover a database after a failure.
Recovery Point Objective (RPO) refers to any amount of data loss after the recovery completes,
where RPO=0 means no data loss of committed transactions.
Storage consistent
Storage consistent replication refers to storage replication operations (local or remote) that
replication
maintain write-order fidelity at the target devices, even while the application is running. To the
SQL Server database the snapshot data looks as it does after a host reboot, allowing the database
to perform crash/instance recovery when starting.
VMAX3 HYPERMAX OS
HYPERMAX OS is the industrys first open converged storage hypervisor and operating system. It
enables VMAX3 to embed storage infrastructure services like cloud access, data mobility, and data
protection directly on the array. This delivers new levels of data center efficiency and
consolidation by reducing footprint and energy requirements. In addition, HYPERMAX OS delivers
the ability to perform real-time and non-disruptive data services.
A collection of host addressable VMAX3 devices. A Storage Group can be used to (a) present
devices to host (LUN masking), (b) specify FAST Service Levels (SLOs) to a group of devices, and
(c) manage grouping of devices for replication software such as SnapVX and SRDF.
Storage Groups can be cascaded. For example, the child storage groups can be used for setting
FAST Service Level Objectives (SLOs) and the parent used for LUN masking of all the database
devices to the host.
TimeFinder SnapVX is the latest development in TimeFinder local replication software, offering a
higher scale and wider feature set, yet maintaining the ability to emulate legacy behavior.
reads even further, it can also ship as hybrid, multi-tier storage that excels in providing FAST 2 (Fully Automated Storage Tiering)
enabled performance management based on Service Level Objectives (SLO). The new VMAX3 hardware architecture comes with
more CPU power, larger persistent cache, and a new Dynamic Virtual Matrix dual InfiniBand fabric interconnect that creates an
extremely fast internal memory-to-memory and data-copy fabric.
Figure 1 shows possible VMAX3 components. Refer to EMC documentation and release notes to find the most up to date supported
components.
Figure 1.
Up to 4 PB usable capacity
Up to 5,760 drives
To learn more about VMAX3 and FAST best practices with SQL Server databases refer to the white paper: Deployment Best Practice
for SQL Server with VMAX3 Service Level Object Management.
With SnapVX, snapshots are natively targetless. They only relate to a source devices and cant be otherwise accessed directly.
Instead, snapshots can be restored back to the source devices or linked to another set of target devices which can be made
host-accessible.
Each source device can have up to 256 snapshots and can be linked to up to 1024 targets.
Snapshot operations are performed on a group of devices. This group is defined by using a text file specifying the list of devices:
a device-group (DG), composite-group (CG), or a storage group (SG). The recommended way is to use a storage group.
Snapshots are taken using the establish command. When a snapshot is established, a snapshot name is provided with an
optional expiration date. The snapshot time is saved with the snapshot and can be listed. Snapshots also get a generation
number (starting with 0). The snapshot generation is incremented with each new snapshot even if the snapshot name remains
the same.
Fully Automated Storage Tiering (FAST) allows VMAX3 storage to automatically and dynamically manage performance service level goals across the
available storage resources to meet the application I/O demand, even as new data is added, and access patterns continue to change over time.
3
Additional drive types and capacities may be available. Contact your EMC representative for more details.
SnapVX provides the ability to create either space-efficient or full-copy replicas when linking snapshots to target devices.
Use the -copy option to copy the full snapshot point-in-time data to the target devices during link. This will make the target
devices a stand-alone copy. If the -copy option is not used, the target devices provide the exact snapshot point-in-time data
only until the link relationship is terminated, saving capacity and resources by providing space-efficient replicas.
SnapVX snapshots themselves are always space-efficient as they are simply a set of pointers pointing to the original data when
it is unmodified, or to the original version of the data when it is modified. Multiple snapshots of the same data utilize both
storage and memory savings by pointing to the same location and consuming very little metadata.
SnapVX snapshots are always consistent. That means that snapshot creation always maintains write-order fidelity. This allows
easy creation of restartable database copies. Snapshot operations such as establish and restore are also consistent; the
operation either succeeds or fails for all the devices as a unit.
Linked-target devices cannot restore any changes directly to the source devices. Instead, a new snapshot can be taken from
the target devices and linked back to the original source devices. In this way, SnapVX allows an unlimited number of cascaded
snapshots.
FAST Service Levels apply to either the source devices or to snapshot linked targets, but not to the snapshots themselves.
SnapVX snapshot data resides in the same Storage Resource Pool (SRP) as the source devices, and acquire an Optimized FAST
Service Level Objective (SLO) by default.
SRDF Synchronous (SRDF/S) mode which is used to create a no-data-loss of committed transactions solution. The
SRDF Asynchronous (SRDF/A) mode which is used to create consistent replicas at unlimited distances without write
SRDF Adaptive Copy (SRDF/ACP) mode which allows bulk transfers of data between source and target devices
without write-order fidelity and without write performance impact to source devices. SRDF/ACP is typically used for data
migrations as a Point-in-Time data transfer. It is also used to catch up after a long period that replication was
suspended and many changes are owed to the remote site. SRDF/ACP can be set to continuously send changes in bulk
until the delta between source and target is reduced to a specified skew. At this time SRDF/S or SRDF/A mode can
resume.
SRDF groups:
o
An SRDF group is a collection of matching devices in two VMAX3 storage arrays together with the SRDF ports that are
used to replicate these devices between the arrays. HYPERMAX OS allows up to 250 SRDF groups per SRDF director.
The source devices in the SRDF group are called R1 devices, and the target devices are called R2 devices.
SRDF operations are performed on a group of devices contained in an SRDF group. This group is defined by using a text
file specifying the list of devices: a device-group (DG), composite/consistency-group (CG), or a storage group (SG).
The recommended way is to use a storage group.
SRDF consistency:
o
An SRDF consistency group always maintains write-order fidelity (also called dependent-write consistency) to make sure
that the target devices always provide a restartable replica of the source application.
Note: Even when consistency is enabled the remote devices may not yet be consistent while SRDF state is sync-inprogress. This happens when SRDF initial synchronization is taking place before it enters a consistent replication state.
o
o
SRDF consistency also implies that if a single device in a consistency group cannot replicate, then the whole group will
stop replicating to preserve target devices consistency.
Multiple SRDF groups set in SRDF/A mode can be combined within a single array, or across arrays. Such grouping of
consistency groups is called multi-session consistency (MSC). MSC maintains dependent-write consistent
replications across all the participating SRDF groups.
SRDF sessions:
o
An SRDF session is created when replication starts between R1 and R2 devices in an SRDF group.
An SRDF session can establish replication between R1 and R2 devices. R1 and R2 devices will need full copy for the
first establish only. Any subsequent establish (for example, after SRDF split or suspend) will be incremental, only
passing changed data.
An SRDF session can restore the content of R2 devices back to R1. Restores are incremental, moving only changed
data across the links. TimeFinder and SRDF can restore in parallel (for example, bring back a remote backup image).
During replication, the devices to which data is replicated are write-disabled (read-only).
An SRDF session can be suspended, temporarily halting replication until a resume command is issued
An SRDF session can be split, which not only suspends the replication but also makes the R2 devices read-writable.
An SRDF checkpoint command does not return the prompt until the content of the R1 devices has reached the R2
An SRDF swap changes R1 and R2 personality and the replication direction for the session.
devices. This option helps in creating remote database backups when SRDF/A is used.
An SRDF failover makes the R2 devices writable. R1 devices, if still accessible, will change to Write_Disabled (readonly). The SRDF session is suspended and application operations proceed on the R2 devices.
An SRDF failback copies changed data from R2 devices back to R1 and makes the R1 devices writable. R2 devices are
SRDF replication sessions can go in either direction (bi-directional) between the two arrays, where different SRDF
For more information, see SRDF Modes and Topologies and SRDF CLI commands.
For a restart solution where no roll-forward is planned, snapshots taken at very short intervals (seconds or minutes) ensure
that RPO is limited to that interval. For example, if a snapshot is taken every 30 seconds, if it is needed to restore the database
without recovery there will be no more than 30 seconds of data loss.
For a recovery solution, frequent snapshots ensure that RTO is short as less data will need recovery during roll-forward of logs
to the current time. For example, if snapshots are taken every 30 seconds, rolling the data forward from the last snapshot will
be much faster than rolling forward from nightly backup or hourly snapshots.
Because snapshots consume storage capacity based on the database change rate, when no longer used, old snapshots should be
terminated to release their consumed storage capacity.
10
During the restart of SQL Server database from such copies, the following occurs:
1. All transactions that were recorded as committed and written to the transaction log, but which may not have had corresponding
data pages written to the data files, are rolled forward. This is the redo phase.
2. When the redo phase is complete, the SQL Server enters the undo phase where it looks for database changes that were recorded
(for example, a dirty page flushed by a lazy write) but which were never actually committed by a transaction. These changes are
rolled back or undone. The state attained is often referred to as a transactionally consistent point in time. It is essentially the
same process that the SQL Server would undergo should the server have suffered an unanticipated interruption such as a power
failure. Roll-forward recovery using incremental transaction log backups to a point in time after the database copy was created is
not supported on a Microsoft SQL Server restartable database copy. Hence, VMAX consistent split creates crash-consistent and
write-order-consistent, point-in-time copies of the database.
EMC AppSync can create and manage application-consistent copies of Microsoft SQL Server databases, including support for
advanced SQL features, such as AlwaysOn Availability Groups, protection for standalone and clustered production SQL Server
instances, and support for databases on physical hosts, RDMs, and virtual disks on virtual hosts. It uses Microsoft SQL Server's VDI
snapshot feature to create Full and Copy SQL Server backup types. Full backup type protects the database, and the active part of the
transaction log. This copy type is typically used when the copy will be considered a backup of the database or when the copy will be
mounted in order to use a third-party product to create a backup of the database. This type of copy allows you to restore transaction
logs to bring the database forward to a point in time that is newer than the copy, assuming you have backed up those transaction
logs. Copy backup type protects the database and the active part of the transaction log without affecting the sequence of the
backups. This provides SQL Server DBAs with a way to create a copy without interfering with third-party backup applications that
may be creating full and/or differential backups of the SQL Server databases
11
point-in-time of the snapshot. If the data on the linked target needs to be reset to the original point-in-time snapshot, it can be
relinked to that snapshot. SnapVX management Solutions Enabler CLI commands on how to create a SnapVX snapshot (Figure 2),
link it (Figure 3), relink to it and restore from it (Figure 4) are provided in Appendix III.
Figure 2 shows SnapVX sessions being created for a SQL Server Production OLTP database at the parent storage group level. It
shows various snapshots being created at certain intervals for protection and future use. These snapshots include both data and log,
and by default inherit the SLO set on the production storage group.
Figure 2.
Figure 3 illustrates one of the SnapVX sessions being linked, to create a target replica SQL storage group on the mount host. Note
that the mount host storage group can be relinked to the same SnapVX session or a different session, based on need.
Figure 3.
12
13
performed on a linked target need to be restored to production; more of these restore modes are discussed in later sections. Figure
4 shows an example of a direct SnapVX restore.
Figure 4.
Unmounting the file systems containing the database data and log files.
Refer to SQL Server Books OnLine for complete documentation on this Transact-SQL stored procedure, and Appendix VI on how to
automate it using Windows PowerShell. There are two ways to restore a SQL Server SnapVX snapshot, direct and indirect.
Direct restore is restoring directly from the snapshot itself, as shown in Figure 4.
Indirect restore is via the linked targets, which have undergone a surgical repair or modification. The restore from linked targets
is possible by first creating a snapshot of the linked target, and then link that snapshot back to the original production devices,
as shown in Figure 5.
Restores are possible from snapshots from any point-in-time, and will not affect or invalidate any other snapshot used previously.
Effected entities during SnapVX snapshot restore is another key consideration. An effected entity is data that resides on the
Production SQL database host that have unintentionally become part of a SQL Server SnapVX snapshot replica and can be restored
in addition to the ones that are needed. To prevent effected entity situations, proper planning of the database layout base on restore
granularity should be taken. The steps needed to execute direct restore are as follows.
1. Detach the SQL server database.
2. Unmount the database volumes.
3. Execute SnapVX restore.
4. Rescan and remount the volumes.
5. Attach the SQL server database.
Once background restore is completed, it can be terminated.
The SnapVX steps necessary to do a direct restore are shown in the following example:
14
15
Figure 5.
Create a SnapVX replica of surgically repaired mount SQL database storage group
Link the SnapVX replica back to the production SQL database in copy mode
The next few steps illustrate the actual step-by-step process of executing an in-direct SnapVX restore:
1. Execute a SnapVX establish (See Part A-Figure 6)
2. Link to mount (See Part B-Figure 7)
3. Re-snap (See Part C-Figure 8)
4. Re-link to production (See Part D-Figure 9)
5. Execute cleanup for participating SnapVX sessions that are no longer needed
16
Figure 6.
Figure 7.
Indirect SnapVX restore (Part B), linking SnapVx replica to target SQL storage group
Figure 8.
Indirect SnapVX restore (Part C), establish a SnapVx replica of the mount host storage group
17
Figure 9.
Link the SnapVX replica (Part D) of the Mount SQL database storage group
The equivalent symsnapvx steps for Figure 6 (Part A), Figure 7(Part B) are listed below.
Indirect SnapVX restore of modified linked target back to Production SQL database (Part A & Part B)
1. Create SnapVX on Production SQL database storage group.
symsnapvx sid 536 sg PROD_SQL_SG name PROD_SQL_SnapVX establish ttl delta 2 nop
2. Verify SnapVX details.
symsnapvx sid 536 sg PROD_SQL_SG snapshot_name PROD_SQL_SnapVX verify -summary
symsnapvx sid 536 sg PROD_SQL_SG list v
symsnapvx sid 536 sg PROD_SQL_SG list -detail
3. Link SnapVX to Mount SQL database storage group in copy mode.
symsnapvx sid 536 sg PROD_SQL_SG lnsg MOUNT_SQL_SG snapshot_name PROD_SQL_SnapVX link copy nop
4. Verify link.
symsnapvx sid 536 sg PROD_SQL_SG snapshot_name PROD_SQL_SnapVX verify -summary
symsnapvx sid 536 sg PROD_SQL_SG list v
symsnapvx sid 536 sg PROD_SQL_SG list -detail
symsnapvx sid 536 sg PROD_SQL_SG list detail -linked
The equivalent symsnapvx steps for Figure 8 (Part C), Figure 9(Part D) are listed below.
Indirect SnapVX restore of modified linked target back to Production SQL database (Part C & Part D)
1. Make surgical repairs or modifications on the Mounted SQL database, and then create a SnapVX replica of this Mount SQL
database storage group (cascaded).
symsnapvx sid 536 sg MOUNT_SQL_SG name MOUNT_SQL_SnapVX establish ttl delta 2 nop
symsnapvx sid 536 sg MOUNT_SQL_SG snapshot_name MOUNT_SQL_SnapVX verify -summary
symsnapvx sid 536 sg MOUNT_SQL_SG list v
symsnapvx sid 536 sg MOUNT_SQL_SG list -detail
2. Link the SnapVX replica of the Mount SQL database storage group back to the Production SQL database in copy mode.
symsnapvx sid 536 sg MOUNT_SQL_SG lnsg PROD_SQL_SG snapshot_name MOUNT_SQL_SnapVX link copy nop
18
19
Figure 10.
The typical steps for restore back to R1 SQL production database are shown below.
Note: This example chooses a snapshot name MOUNT_R2_SnapVX for restore. R1 VMAX is 535 and R2 VMAX is 536.
1. Detach the R1 site SQL Server database.
2. Split SRDF link to initiate the restore operation.
symrdf sid 535 sg PROD_R1_SG rdfg 20 split
3. If DR from a point-in-time snapshot is desired, identify R2 Snap and restore that to R2 devices.
symsnapvx sid 536 sg MOUNT_R2_SG snapshot_name MOUNT_R2_SnapVX restore
4. Verify the completion of the restore.
symsnapvx sid 536 sg MOUNT_R2_SG snapshot_name MOUNT_R2_SnapVX verify -summary
5. Terminate once restore completes.
symsnapvx sid 536 sg MOUNT_R2_SG snapshot_name MOUNT_R2_SnapVX terminate -restored
6. As soon as the restore from snap is initiated, SRDF restore can be started. SRDF will start performing incremental restore from
R2 to R1. The devices will show SyncInProg to indicate that the restore is going on. The state of Synchronized will indicate
completion of the restore.
symrdf sid 535 sg MOUNT_R2_SG rdfg 20 restore
7. Attach the R1 site SQL Server database.
20
Figure 11.
TimeFinder SnapVX technical notes for more details on non-shared capacity. Non-shared capacity is the most important value
because non-shared snapshot deltas will be discarded when the snapshot is terminated, which will free space in the SRP. The nonshared capacity can also be viewed from Unisphere for VMAX.
Figure 12 shows less than 2% of Storage Resource Pool (SRP) being utilized to capture and track 256 unique SnapVX snapshots
taken at 30 second intervals, with a 60 MB/sec change rate on a 1.2 TB SQL OLTP workload. It shows SRP space usage percentages
for SnapVX increments of 5, 10, 25, 50, 75, 100, 125, 150,175, 200, and 250. The allocations were minimal, efficient, and space
saving for all these snapshots. A smaller RTO is enabled by using less than two percent of the entire SRP to track these snapshots
that had a time to live of 2 days (TTL). This sample data capture of track allocation was observed in a lab environment where the
21
SQL server OLTP database storage group was on Platinum SLO. Different results may be observed, depending on factors like
retention time, number of snaps, change rate, competing workloads run on the linked targets, and so forth.
Figure 12.
<2%
SRP utlilized
600
400
200
0
Figure 13.
Windows Server 2012 supports the ability to detect thinly provisioned storage and issue T10 standard UNMAP or TRIM based reclaim
commands against the storage. Reclaim operations are performed in the following situations:
When the target linked volumes are no longer in use and the volumes are formatted with the quick option. The quick option
requests that the entire size of the volume be reclaimed in real-time. Figure 14 shows an example track allocation layout before
22
and after a quick formatted set of Windows volumes 00020 through 00024. The unlinked target volumes after quick format are
reduced to 702 total written tracks.
Figure 14.
When the optimize options is selected for a volume as part of a regularly scheduled operation, or when optimize-volume
Windows PowerShell is used with the retrim option, or selected from the Defragment and Optimize Drives GUI. Figure 15
shows an example.
Figure 15.
23
When a group of SQL Server database files are deleted from the target file system, Windows automatically issues reclaim
commands for the area of the file system that was freed based on the file deletion. Figure 16 shows the effect of reclamation on
Device ID 00023.
Figure 16.
Reclaimed tracks after SQL server database files were deleted on target FS
24
Figure 17.
Table 1
Configuration aspect
Description
Storage array
HYPERMAX OS
5977.596
25
Table 2
Configuration aspect
Description
Windows
Multipathing
Hosts
Table 3
Database
Production OLTP1
Size: 1.1 TB
Mount OLTP1
Size: 1.1 TB
Table 4
LUN layout
SQL_PRODB_SG
SQL_MOUNTDB_SG
SRP
Start SLO
Default
Gold
Default
Gold
Default
Bronze
Default
Bronze
Database
Mount point
C:\OLTP1_Data1
C:\OLTP1_Data2
OLTP1
(Production
& Mount)
FIXED_FG,
GROWING_FG,
SCALING_FG
C:\OLTP1_Data3
C:\OLTP1_Data4
C:\OLTP1_Logs
287G
287G
287G
OLTP1_log.ldf
TEST OVERVIEW
General test notes:
OLTP1 was configured to run a 90/10 read/write ratio OLTP workload derived from an industry standard. No special database
tuning was done as the focus of the test was not on achieving maximum performance and rather comparative differences of a
standard database workload.
All the tests maintained a steady OLTP workload on production SQL Server database with a variable OLTP change rate in the
range of 30-60MB/sec on a 1.1 TB SQL dataset, even when running the SnapVX replications.
Most of the SnapVX snapshots were taken at an aggressive 30 sec interval, to minimize RTO and RPO, and show the role
SnapVX replications play in continuous data protection (CDP).
DATA and LOG Storage Groups were cascaded into a common parent storage group for ease of provisioning, replication and
performance management.
26
Data collection included storage performance metrics using Solutions Enabler and Unisphere for VMAX, host performance
statistics using Windows Perfmon, and EMC PowerPath statistics.
Impact of taking 256 SnapVX snapshots on Production workload database with a steady SLO Gold (Usecase-1A), and varying
SLO Gold -> SLO Platinum (Usecase-1B)
Impact of No-Copy vs Copy mode linked target snapshots on production workload, without an OLTP workload on mount host
(Usecase-2A), and then introduce an OLTP workload on mount host and observe the impact (Usecase-2B).
Table 5
27
Figure 18.
28
3. Continue to run the OLTP workload on Gold for the next 3 hours.
4. Terminate the previously created SnapVX snapshots at 30 second intervals.
5. Repeat the above steps; however, during the SnapVX creation phase, transition the SQL storage group to Platinum SLO, and
create 256 SnapVX snapshots at 30 second intervals.
6. Continue to run the OLTP workload load at steady state and with the SQL storage group set at Platinum SLO for the next 3
hours.
Test results:
Table 6 and Figure 19 for Use Case 1B show the database transaction rate in SQL Batch Requests/sec and the SQL Response time
(ms), for both Steady State, and SnapVX for each SLO. With Gold SLO, SnapVX showed the SQL transaction rate at 2366 Batch
requests/sec, while a similar run with Platinum workload improved to 3260 Batch requests/sec. The SQL response times remained in
the range of 1.44 ms to 2.28 ms for Platinum and Gold respectively. SLO rules of compliance and objectives were met.
Table 6
Figure 19.
Use Case 1B SQL Batch Request changes, SQL Reponse time with Gold to Platinum changes
29
USE CASE 2A IMPACT OF NO-COPY VS COPY MODE LINKED TARGET SNAPSHOTS ON WITH
WORKLOAD ON PRODUCTION
Objectives:
This use case shows the impact of SnapVX linked targets in No-Copy mode and in Copy mode. In the No-Copy mode test, the 256
Snaps were created and linked in No-Copy mode with targets, while an OLTP workload is running on the production SQL Server for 3
hours. In the Copy mode test, the 256 SnapVX snaps were created and linked to a target storage group 5 in Copy mode every 30
seconds. The Copy mode tracks were allocated and created asynchronously in the background for new changes being generated for
the OLTP workload. This test case used Gold SLO for SQL Server Data files and Bronze SLO for SQL Server transaction LOG storage
group. Note: There was no workload run on the target mount SQL Server.
Test case execution steps:
1. Run OLTP workload at steady state for 1 hour without SnapVX involved.
2. Continue running OLTP workload, but run SnapVX with link to target storage group in no-copy mode and gather performance
statistics. This test run is for 3 hours.
3. Repeat the above steps, but this time with SnapVX snapshots created and linked to target storage group in copy mode. Gather
SQL performance statistics; this run is for 3 hours as well.
Test results:
Table 7 and Figure 20 show that the Average Batch Requests/sec for SQL Server is slightly higher for Copy mode test at 1710
compared to No-Copy LINK at 1684. The response times were slightly lower at 3.23 ms for COPY LINK compared to 3.62 ms for NOCOPY LINK. As we can see from the Figure 20 graphs, No-Copy linked snaps and Copy linked snaps are almost identical in behavior
when there is no intensive workload run on the mount SQL storage group. The very slight differences between COPY and NO-COPY
SQL stats can be attributed to the ROW (Redirect-on-Write) technology in VMAX3, to align with Gold SLO compliance latency range.
Refer to the EMC VMAX3 TM Local Replication technical notes for further details on ROW.
Table 7
5
The target storage groups contain the linked-target devices of Productions snapshots. They should be added to a masking view to make the target
devices accessible to the Mount host.
30
Figure 20.
Use Case 2A results, for No-Copy versus Copy linked SQL target storage groups
USE CASE 2B IMPACT OF NO-COPY VS COPY MODE LINKED TARGET SNAPSHOTS WITH
WORKLOAD ON BOTH PRODUCTION AND MOUNT HOSTS
Objectives:
This use case is different from Use Case 2A in that only 30 SnapVX replicas were created, instead of 256 SnapVX replicas, but an
OLTP workload was run on the linked storage group that belongs to the target host set with the Bronze SLO. The workload was
kicked off on 30th relinked snap in both cases. Also note that the 30 Snaps with COPY mode linked targets were created after at least
the first SnapVX replica was linked and fully defined, and copied over to the target storage group 6. All subsequent relinks were to the
newly created snaps. The mount host was running a similar OLTP workload on bronze SLO compared to similar OLTP workload on the
production host running Gold SLO.
Hence this test shows the impact of running workload on the linked target replica in No-copy mode and Copy-mode replica, with
different SLOs set on the storage groups. Both in No-Copy mode and Copy mode tests, the 30 Snaps were created and linked to
target storage group every 30 seconds, while an OLTP workload was running on the production SQL Server and target mount SQL
Server for 3 hours. The copy-mode tracks were allocated and created asynchronously in the background for new changes being
generated for the OLTP workload. This test case used the Bronze SLO for SQL Server transaction LOG storage group.
Test case execution steps:
1. Run OLTP workload on Production SQL database for 3 hours, with 30 SnapVX snapshots created every 30 seconds.
2. Run parallel OLTP workload on Mount SQL database on linked target storage group in no-copy mode.
3. Gather SQL performance statistics.
4. Repeat the above steps, but this time with new set of 30 SnapVX snapshots created and linked to target storage group in copy
mode.
6
The target storage groups contain the linked-target devices of Productions snapshots. They should be added to a masking view to make the target
devices accessible to the Mount host.
31
Note before creating the 30 SnapVX snapshots in copy mode, one initial full copy of the production volumes were defined and
copied (defined) over to the target volumes. This creates a situation, where following copy-mode SnapVX snapshots when
recreated and relinked had fewer tracks to be asynchronously copied over.
5. Gather SQL performance statistics for this 3 hour run as well.
Results
Table 8 and Figure 21 show SQL Server Batch Requests/sec and SQL Response time for this test. As seen from Figure 21, the SQL
database on the mount host met the expectations of the Bronze SLO. Note that the Average SQL Batch Requests/sec for Target (NO
COPY) in the Bronze SLO is 1976 while that of Target (COPY) in Bronze SLO is 1453. The reason is that the mount volumes in the
NO COPY state still share tracks with the production SnapVX snapshots and production volumes in the Gold SLO.
Table 8
Figure 21.
SQL Server stats for Production and Mount for Copy and No-Copy (OLTP on Mount Host)
32
CONCLUSION
VMAX3 SnapVX local replication technology enables SQL administrators to meet their protection and backup needs with scale, speed,
and ease of use. SnapVX capability reduces host I/O and CPU overhead, allowing the database host to focus on servicing database
transactions. It not only helps reduce RPO and RTO, but also enables multiple copies of the production database for
test/development/reporting purposes, with the added benefits of reduced array space usage.
REFERENCES
Deployment Best Practice for Microsoft SQL Server with VMAX3 SLO Management
33
APPENDIXES
APPENDIX I - CONFIGURING SQL SERVER DATABASE STORAGE GROUPS FOR REPLICATION
VMAX3 TimeFinder SnapVX and SRDF allow the use of VMAX3 Auto-Provisioning Groups Storage Groups to provision storage for
SQL Server database and also to create Enginuity Consistent Assist based write-order-consistent snapshots. Any changes to SQL
Server database provisioning using these storage groups will also be reflected into any new snapshots created after that, making it
very easy to manage database growth. This simplifies configuration and provisioning SQL Server database storage for data
protection, availability and recoverability.
Cascading DATA and LOG into a parent SG allows the creation of restartable copies of the database. Separating transaction logs from
this group allows independent management of data protection for transactions logs, while providing desired control over SLO
management. Figure 22 shows how to provision storage for SQL Server DATA and transaction logs to ensure database recover SLAs
are achievable. Following this provisioning model along with the use cases described earlier provides proper deployment guidelines
for SQL Server databases on VMAX3 to database and storage administrators.
Figure 22.
Figure 23.
34
Figure 24.
Figure 25.
35
Figure 26.
SRDF Modes define SRDF replication behavior. These basic modes can be combined to create different replication topologies.
In SRDF/S, each host write to an R1 device gets acknowledged only after the I/O was copied to the R2 storage system
SRDF/S makes sure that data on both the source and target devices is exactly the same.
Host I/O latency will be affected by the distance between the storage arrays.
persistent cache.
It is recommended to have SRDF Consistency Enabled even in an SRDF/S mode to ensure that if any single device
cannot replicate its data, then all the devices in the group will cease replications, preserving target consistency.
SRDF Asynchronous (SRDF/A) is used to create consistent replicas at unlimited distances, without write response time
penalty to the application.
o
o
In SRDF/A, each host write to an R1 device gets acknowledged immediately after it registered with the local VMAX3
persistent cache, preventing any write response time penalty to the application.
Writes to the R1 devices are grouped into cycles. The capture cycle is the cycle that accepts new writes to R1 devices
while it is open. The transmit cycle is a cycle that was closed for updates and its data is being sent from the local to
the remote array. The receive cycle on the remote array receives the data from the transmit cycle. The destaged
cycle on the remote array destages the data to the R2 devices. SRDF software makes sure to only destage full cycles to
the R2 devices.
-
The default time for the capture cycle to remain open for writes is 15 seconds, though it can be set differently.
36
In legacy mode (at least one of the arrays is not a VMAX3) cycle time can increase during peak workloads as
more data needs to be transferred over the links. After the peak, the cycle time will go back to its set time (default
of 15 seconds).
In multi-cycle mode (both arrays are VMAX3) cycle time remains the same, though during peak workload more
than one cycle can be waiting on the R1 array to be transmitted.
While the capture cycle is open, only the latest update to the same storage location will be sent to the R2, saving
bandwidth. This feature is called write-folding.
Write-order fidelity is maintained between cycles. For example, two dependent I/Os will always be in the same
cycle, or the first of the I/Os in one cycle and the dependent I/O in the next.
To limit VMAX3 cache usage by capture cycle during peak workload time and to avoid stopping replication due to
too many outstanding I/Os, VMAX3 offers a Delta Set Extension (DSE) pool which is local storage on the source
side that can help buffer outstanding data to target during peak times.
The R2 target devices maintain a consistent replica of the R1 devices, though slightly behind, depend on how fast the
links can transmit the cycles and the cycle time. For example, when cycles are received every 15 seconds at the remote
storage array its data will be 15 seconds behind production (if transmit cycle was fully received), or 30 seconds behind
(if transmit cycle was not fully received it will be discarded during failover to maintain R2 consistency).
Consistency should always be enabled when protecting databases and applications with SRDF/A to make sure the R2
devices create a consistent restartable replica.
SRDF Adaptive Copy (SRDF/ACP) mode allows bulk transfers of data between source and target devices without maintaining
write-order fidelity and without write performance impact to source devices.
o
While SRDF/ACP is not valid for ongoing consistent replications, it is a good way to transfer changed data in bulk
between source and target devices after replications were suspended for an elongated period of time, accumulating
many changes on the source. ACP mode can be maintained until a certain skew of leftover changes to transmit is
achieved. Once the amount of changed data has been reduced, the SRDF mode can be changed to Sync or Async as
appropriate.
SRDF/ACP is also good for migrations (also referred to as SRDF Data Mobility) as it allows a point-in-time data push
between source and target devices.
SRDF Topologies
A two-site SRDF topology includes SRDF sessions in SRDF/S, SRDF/A, and/or SRDF/ACP between two storage arrays, where each
RDF group can be set in a different mode, and each array may contain R1 and R2 devices of different groups.
Three-site SRDF topologies include:
Concurrent SRDF: Concurrent SRDF is a three-site topology in which replication take place from site A simultaneously to site B
and site C. Source R1 devices are replicated simultaneously to two different sets of R2 target devices on two different remote
arrays. For example, one SRDF group can be set as SRDF/S replicating to a near site and the other as SRDF/A replicating to a
far site.
Cascaded SRDF: Cascaded SRDF is a three-site topology in which replication take place from site A to site B, and from there to
site C. R1 devices in site A replicate to site B to a set of devices called R21. R21 devices behave as R2 to site A, and as R1 to
site C. Site C has the R2 devices. In this topology, site B holds the full capacity of the replicated data and if site A fails and
Production operations continue on site C, site B can turn into the DR site for site C.
SRDF/EDP: Extended data protection SRDF topology is similar to cascaded SRDF. Site A replicates to site B, and from there to
site C. However, in EDP, site B does not hold R21 devices with real capacity. This topology offers capacity and cost savings, as
site B only uses cache to receive the replicated data from site A and transfer it to site C.
SRDF/Star: SRDF/Star offers an intelligent three-site topology similar to concurrent SRDF, where site A replicates
simultaneously to site B and site C. However, if site A fails, site B and site C can communicate to merge the changes and resume
DR. For example, SRDF/Star replication between site A and B uses SRDF/S and replication between site A and C uses SRDF/A. If
37
site A fails, site B can send the remaining changes to site C for a no-data-loss solution at any distance. Site B can become a DR
site for site C afterwards, until site A can come back.
SRDF/AR: SRDF Automatic Replication can be set as either a two or a three-site replication topology. It offers slower replication
when network bandwidth is limited and without performance overhead. In two-site topology, SRDF/AR uses TimeFinder to create
a PiT replica of production on site A, then uses SRDF to replicate it to site B, where another TimeFinder replica is created as a
gold copy. Then the process repeats. In a three-site topology site A replicates to Site B using SRDF/S. In site B TimeFinder is
used to create a replica which is then replicated to site C. In site C the gold copy replica is created and the process repeats itself.
There are also 4-site topologies, though they are beyond the scope of this paper. For full details on SRDF modes, topologies, and
other details refer to the VMAX3 Family with HYPERMAX OS Product Guide.
Establish operation execution is in progress for the storage group SQLDB_SG. Please wait...
Polling for Establish.............................................Started.
Polling for Establish.............................................Done.
Polling for Activate..............................................Started.
Polling for Activate..............................................Done.
Establish operation successfully executed for the storage group SQLDB_SG
: SQLDB_SG
: 000196700536
Total
Sym
Flgs
Deltas
Non-Shared
Dev
Snapshot Name
Gen FLRG Snapshot Timestamp
(Tracks)
(Tracks)
Expiration Date
----- ---------------------- ---- ---- ------------------------ ---------- ---------- -----------------------000BC SQLDB_Snap_1
0 .... Tue Mar 31 10:12:51 2015
3
3 Wed Apr 1 10:12:51 2015
Establish operation successfully executed for the storage group SQLDB_SG
Flgs:
(F)ailed
(L)ink
(R)estore
(G)CM
:
:
:
:
X
X
X
X
=
=
=
=
Failed, . = No Failure
Link Exists, . = No Link Exists
Restore Active, . = No Restore Active
GCM, . = Non-GCM
7
The target storage groups contain the linked-target devices of Productions snapshots. They should be added to a masking view to make the target
devices accessible to the Mount host.
38
The target storage groups contain the linked-target devices of Productions snapshots. They should be added to a masking view to make the target
devices accessible to the Mount host.
39
C T O R S
Status
Dir
Port
--------------Online Online
Online Online
40
Total
------- ------Track(s)
0 13141430
MB(s)
0 1642679
Legend for MODES:
M(ode of Operation)
: A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
: M = Mixed
D(omino)
: X = Enabled, . = Disabled
A(daptive Copy)
: D = Disk Mode, W = WP Mode, . = ACp off
(Mirror) T(ype)
: 1 = R1, 2 = R2
(Consistency) E(xempt): X = Enabled, . = Disabled, M = Mixed, - = N/A
View the physical disk, volume or mount points for every database file and log location
41
Scan the drive connections and discover new disks available to the system
Figure 27 shows symntctl flush and umount usage for a mount path
Figure 27.
42
Figure 28.
Figure 29.
43
Figure 30.
Example 2 in Figure 31 shows a listing of allocations and tracks allocations for a range of devices (0020-0024) that are part of an
SQL database storage group.
Figure 31.
44
Example 3 in Figure 32 shows how to create a TimeFinder SnapVX snapshot for an entire storage group. In cases where the SQL
server database is the entire storage group, SnapVX has the ability to perform SnapVX operations at the storage group level itself.
This simplifies the task for an SQL server admin to perform replication for a group of devices.
Figure 32.
Example 4 in Figure 33 shows a SnapVX listing details for storage group snapsource.
Figure 33.
SnapVX listing
Example 5 in Figure 34 illustrates linking a TimeFinder SnapVX snapshot in default no-copy mode to a target SQL storage group.
Figure 34.
45
Example 6 in Figure 35 lists the output of a linked TimeFinder SnapVX snapshot in copy mode to a target SQL storage group.
Figure 35.
Example 7 in Figure 36 illustrates re-linking a target SQL storage group to a TimeFinder SnapVX snapshot. Re-linking provides
incremental refreshes of a linked target storage group from a different SnapVX snapshot with a different PiT.
Figure 36.
Re-linking a target
46
Example 8 in Figure 37 shows a TimeFinder SnapVX snapshot list of a linked no-copy storage group.
Figure 37.
Example 9 in Figure 38 shows a copied and de-staged linked storage group output with -detail.
Figure 38.
Example 10 in Figure 39 shows source volumes (500GB each) which will be participating in a TimeFinder SnapVX linked session in
copy mode. The linked target volumes (1TB each) are larger than the source volumes, as shown in Example 11. Example 10 and
Example 11 together show how linked target volumes in copy mode that are larger than the source volume can be mounted back to
the original host.
47
Figure 39.
Example 11 in Figure 40 shows linked target windows volumes of size 1TB that are targets of source volumes of smaller size (500GB
each), see above. The targets can be extended using Windows disk management to realize their full capacity. This helps meet
capacity growth needs (although not seamless) with LUN expansion to the database and might involve production I/O downtime
during switch-over to larger sized volumes.
Figure 40.
48
Example 12 in Figure 41 demonstrates the Symdev free all command. This command frees all allocations on unlinked target
windows volumes. The Symdev free all command provides the ability to wipe volumes of all data. The sleep mentioned in the
script is an arbitrary value. In this example, device ranges 00020 through 00024 are freed of all allocations, and the allocations are
reclaimed into the storage resource pool (SRP). The free all command should be used with utmost caution in production
environments and only with the knowledge of administrators. The example highlights the end result of free all in Pool allocated
tracks % for the range of devices to be at zero.
Figure 41.
49