Upload
others
View
64
Download
1
Embed Size (px)
Citation preview
MICROSOFT SQL SERVER HIGH AVAILABILITY USING VMAX AND SRDF/METRO
VMAX® Engineering White Paper
ABSTRACT
With the introduction of the VMAX All Flash and VMAX SRDF/Metro remote high
availability, aadministrators have a new way to protect their applications effectively and
efficiently with unprecedented scale, data protection and high availability This white
paper discusses VMAX®
SRDF/Metro functionality in the context of deploying, planning,
and protecting Microsoft SQL Server.
November 2016
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.
EMC2, EMC, the EMC logo, AppSync, HYPERMAX, PowerPath, SnapVX, SRDF, Unisphere, VMAX, and VMAX3 are registered
trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the
property of their respective owners. © Copyright 2016 EMC Corporation. All rights reserved. Published in the USA. 11/16 White Paper
H15529
EMC believes the information in this document is accurate as of its publication date. The information is subject to change without
notice.
EMC is now part of the Dell group of companies.
Part Number H15529
TABLE OF CONTENTS
EXECUTIVE SUMMARY ...........................................................................................................4
VMAX3 AND VMAX ALL FLASH OVERVIEW .........................................................................4
VMAX SRDF REMOTE REPLICATIONS OVERVIEW .............................................................6
SRDF/METRO OVERVIEW .......................................................................................................7
SQL SERVER FAILOVER CLUSTER USING SRDF/METRO TEST CASES ....................... 11
CONCLUSION ........................................................................................................................ 14
REFERENCES ........................................................................................................................ 14
APPENDIX .............................................................................................................................. 14
EXECUTIVE SUMMARY
The EMC® VMAX
® family of storage systems is built on the strategy of simple, intelligent, modular storage, and incorporates a Dynamic
Virtual Matrix interface that connects and shares resources across all VMAX engines. The EMC VMAX3™ family encompasses three
new array models: VMAX 100K, VMAX 200K, and VMAX 400K.The VMAX3 family offers hybrid storage arrays with pre-defined service
levels for diverse application workloads that use Fully Automated Storage Tiering (FAST) to place the most active data in the flash tier.
FAST places the least active data in lower performance tiers according to the user-provided service levels. The VMAX family offers the
highest levels of performance, scale, availability, and disaster recovery (DR) with new hardware and software capabilities.
In 2016, Dell EMC announced brand new VMAX All Flash products: VMAX 250F1, VMAX 450F, and VMAX 850F The new VMAX
architecture is designed to take advantage of the latest, most cost-efficient 3D NAND Flash drive technology. It features multi-
dimensional scale, large write-cache buffering, back-end write aggregation, high bandwidth, and low latency.
VMAX uses Symmetrix Remote Data Facility (SRDF) for remote replications. SRDF offers many DR topologies for Microsoft SQL
Server databases, including two, three, and four site replication. SRDF can replicate in the following modes:
Synchronous mode
Asynchronous mode
Cascaded mode
Zero-data-loss at any distance with SRDF/Star
SRDF/Metro (SRDF/M) (creates an active/active clustered topology across metro distances)
With SRDF/M, reads are serviced from the local VMAX cache, and writes are sent synchronously to the remote array cache. As VMAX
cache is persistent, writes are acknowledged immediately upon being received in the remote cache, making SRDF/M an extremely fast
and performant solution for SQL Server databases running at either location, and allowing them to fail back and forth without any
changes to the storage layer. If there is true cluster partitioning, SRDF/M uses both bias (winner) and Witness to determine the actual
surviving location and automatically resume I/O operations there without compromising data integrity or availability.
SQL Server applications can run on either side of the SRDF/M configuration in clustered or standalone configurations, offering the
highest level of scale, lower recovery time objective (RTO), and efficient resource utilization. Microsoft Windows Server Failover
Clustering (WSFC) can benefit from SRDF/M by having storage readily available for both reads and writes and in sync on all cluster
nodes at both active and stand by sites. This improves the RTO for cluster resources in the event of failover. In addition, when using
SRDF/M for SQL Server with WSFC, active cluster nodes can have storage accessed from either side of the VMAX SRDF/M
configuration, which offers better utilization of resources and load balancing for SQL Server databases.
This white paper explains SRDF/M deployment and use cases with SQL Server failover clusters to offer improved RTO and ease of
management for cluster-based failover for SQL Server databases with active storage visibility for all cluster nodes.
AUDIENCE
This white paper is intended for database and system administrators, storage administrators, and system architects who are
responsible for implementing, managing, and maintaining SQL Server databases and VMAX storage systems. Readers should have
some familiarity with SQL Server and the VMAX family of storage arrays, and be interested in achieving higher database availability,
performance, and ease of storage management.
VMAX3 AND VMAX ALL FLASH OVERVIEW
All VMAX All Flash systems provide great simplicity for planning, ordering, and management and enable scale out using V-Bricks. V-
Bricks are composed of a VMAX engine and 53 TBu of capacity. You can scale V-Bricks with Flash Capacity Packs in increments of 13
TBu. VMAX All Flash systems can be ordered with a pre-packaged software bundle using the entry “F” package or the more
encompassing “FX” package. They also come standard with embedded EMC Unisphere® for VMAX management and monitoring.
VMAX All Flash systems provide better total cost ownership (TCO) because they use less floor space with high-capacity solid-state
drives (SSD). VMAX All Flash systems uses less power than hard disk drives. Flash storage also provides consistent performance
whether the I/O profile is random, sequential, intermittent, or continuous. SQL Server databases can greatly benefit from both server-
side cache and flash storage. As large as the server-side cache is, database capacity is often larger. While frequently accessed data
1 VMAX 450F and 850F were introduced in Q1 2016, and VMAX 250F was introduced in Q4 2016.
fits in the database cache, there are always queries for less-frequently needed data. Finally, in a cluster, server-side cache is not
cumulative and each cluster node caches its own data regardless of others. VMAX All Flash is even faster, due to the high-capacity
VMAX cache. When the requested data is not in cache, flash storage enables I/O to complete quickly. VMAX All Flash compliments the
use of database cache with faster I/O requests for blocks that are not already in cache. VMAX All Flash also provides a storage system
that allows for high performance, consolidation, ease of data replications for backup, for HA or DR.
The VMAX All Flash systems also provide automatic, scheduled, and application consistent snapshots for SQL Server and other
applications for creating point-in-time copies for backup, reporting, or test/dev natively using EMC SnapVX™. EMC AppSync™
provides single, pane of glass management of application snapshots with tighter integration between VMAX SnapVX and Microsoft
Volume Shadowcopy Services (VSS) and SQL Server Virtual Device Interface (VDI).
Figure 1 shows the VMAX All Flash multi-dimensional scalability.
Figure 1. VMAX All Flash multi-dimensional scalability
Key VMAX All Flash and VMAX3 family of storage system benefits for SQL Server databases include:
Large, dynamic random-access memory (DRAM)-based cache enables all writes, including SQL Server writes, check points, or
batch-loads, to complete extremely fast. The VMAX cache is large and mirrored, which allows for write buffering. As a result, writes
to VMAX are faster than writes to other flash arrays that write directly to SSD.
The Write Folding feature of VMAX reduces the number of writes to the SSDs, which helps to extend the life of these drives. This
feature also helps to improve I/O performance on database updates, as the data is still resident in cache.
The FlashBoost feature helps to improve the response time on random read misses. With FlashBoost, small-block read I/Os
bypass the VMAX cache as the data is transferred directly from back-end (SSD) to front-end (host ports). The I/O is then staged in
the VMAX cache for future access.
TimeFinder® SnapVX provides storage-consistent snapshots. SnapVX offers new levels of scale, efficiency, and simplicity. It uses
redirect-on-write for added performance and pointer-based management for dedup-like data reduction. In addition, snapshots have
names, versions, dates, and automatic expirations. Snapshots are protected, so they can be re-used regardless of changes by the
application. They can also cascade any number of times. With SnapVX SQL Server, database replicas can be created for
purposes such as gold copies, test/dev environments creation, or backups. Snapshots can be restored in seconds, and read/write
access to their data is always immediate.
SRDF offers many DR topologies for SQL Server databases, including two, three, and four sites. SRDF can replicate in different
modes to offer a variety of HA and DR solutions, including fast recovery from a remote copy, backup offload, and more.
SRDF/Metro (SRDF/M) extends core SRDF functionality to offer active/active access of storage devices by presenting devices on
local and remote VMAX systems with the same identity to the clustered hosts for active/active data access at synchronous
distances. Cluster aware applications can leverage SRDF/M for HA and load balancing. This also improves the application
recovery point objective (RPO) in the event of failover as storage is readily available on the surviving site.
With AppSync, you can manage the protection, replication, and cloning of applications and databases. AppSync automatically
discovers application databases, learns the database structure, and maps it through the virtualization layer to the underlying
storage LUN. Application owners and database administrators can ensure they get the right copies to the right stakeholders like
analytics, test, and development without worrying about underlying storage intricacies.
T10-DIF (Data Integrity Field) is a core feature of VMAX that benefits all user data from the moment it enters the storage system.
T10-DIF offers data integrity checks as user data travels between frontend, cache, back end, or disk. T10-DIF is also used by
SnapVX and SRDF replications. T10-DIF does not have a performance overhead as it is part of the VMAX architecture.
Note: Unless explicitly stated, the use cases described in this paper are applicable to both VMAX All Flash and VMAX3
storage systems. From this point forward, this paper uses “VMAX family” to refer to both VMAX All Flash and VMAX3
storage systems.
VMAX SRDF REMOTE REPLICATIONS OVERVIEW
The SRDF family of software is the gold standard for remote replications in mission-critical environments. Built for the industry leading,
high-end VMAX storage array, the SRDF family is trusted for DR and business continuity (BC). SRDF offers a variety of replication
modes that can be combined in different topologies, including two, three, and even four sites. SRDF and TimeFinder are closely
integrated to offer a combined solution for local and remote replications.
Built on an industry standard, data protection solution, SRDF/M extends the performance and scale of VMAX storage systems to the
remote site by offering active/active device access to clustered or non-clustered hosts. SRDF/M does this by presenting the remote
devices with the same identity – geometry and world wide names (WWN) to hosts and keeping them synchronized for HA. Applications
can access storage from either site simultaneously for load balancing, active availability, and quick RPO in the event of a failover.
WSFC and SQL Server failover cluster work well with SRDF/M for HA and quick RTO for clustered resources.
Some of the main SRDF capabilities include:
SRDF modes of operation:
o SRDF Synchronous (SRDF/S) mode, which is used to create a no-data-loss of committed transactions solution. The
target devices are an exact copy of the source devices (Production).
o SRDF Asynchronous (SRDF/A) mode, which is used to create consistent replicas at unlimited distances without write
response time penalty to the application. The target devices are typically seconds to minutes behind the source devices
(Production), though consistent (“restartable”).
o 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 where 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 the 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 VMAX storage systems together with the SRDF ports 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.
o SRDF operations are performed on a group of devices contained in the SRDF group. This group is defined by using
either a text file specifying the list of devices, a device group (DG), a composite/consistency group (CG), or a storage
group (SG). The recommended way is to use a storage group.
SRDF consistency:
o The SRDF GC is an SRDF group to which consistency was enabled.
o Consistency can be enabled for either synchronous or asynchronous replication mode.
o An SRDF CG always maintains write-order fidelity (also called dependent-write consistency) to ensure 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 is in the sync-
in-progress state. This happens when SRDF initial synchronization happens before SRDF enters a consistent
replication state.
o SRDF consistency also implies that if a single device in a GC cannot replicate, then the whole group stops replicating to
preserve the target device’s consistency.
o 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 participating SRDF groups.
SRDF sessions:
o An SRDF session is created when replication starts between R1 and R2 devices in an SRDF group.
o The SRDF session can establish replication between R1 to R2 devices. Only on first establish do R1 and R2 devices need
a full copy. Any subsequent establish (for example, after SRDF split or suspend) is incremental, only passing changed
data.
o The SRDF session can restore the content of R2 devices back to R1. Restore is incremental, moving only changed data
across the links. TimeFinder and SRDF can restore in parallel (for example, bring back a remote backup image).
o During replications, the devices to which data is replicated are write-disabled (read-only).
o The SRDF session can be suspended, temporarily halting replication until a resume command is issued.
o The SRDF session can be split, which not only suspends the replication, but also makes the R2 devices read-writable.
o An SRDF checkpoint command does not return the prompt until the content of the R1 devices has reached the R2
devices. This option helps create remote database backups in SRDF/A mode.
o An SRDF swap changes R1 and R2 personality, and the replication direction for the session.
o An SRDF failover makes the R2 devices writable. R1 devices, if still accessible, change to Write_Disabled (read-only).
The SRDF session is suspended and application operations can go on the R2 devices.
o An SRDF failback copies changed data from R2 devices back to R1, and makes the R1 devices writable. R2 devices are
made Write_Disabled (read-only).
o SRDF replication sessions can go in either direction (bi-directional) between the two arrays, where different SRDF groups
can replicate in different directions.
o For more information about SRDF, refer to VMAX Product Guide.
SRDF/METRO OVERVIEW
SRDF/Metro (SRDF/M) is available on the VMAX All Flash and VMAX3 storage systems. SRDF/M provides active/active access to the
R1 and R2 devices in an SRDF configuration. In traditional SRDF configurations, R1 devices are read/write accessible, while R2
devices are read only/ write disabled. In SRDF/M configurations, both the R1 and R2 devices are read/write accessible. The R2 device
takes on the personality of the R1 device in terms of geometry, and most importantly, the WWN. By sharing a WWN, the R1 and R2
devices appear as a shared virtual device across the two VMAX storage systems for host presentation. A host or typically multiple hosts
in a cluster can read and write to both devices. SRDF/M ensures that each copy remains current and consistent and addresses any
write conflicts that might arise. A diagram of the feature is shown in Figure 2.
Figure 2. SRDF/Metro Overview
SRDF/M for Microsoft failover clusters is supported on VMAX storage systems running HYPERMAX OS 5977 Q1 2016 SR2. This
feature provides the following benefits:
An HA solution at Metro distances by using and extending SRDF/S functionality.
The R2 device is read/write accessible to the host, and both sides of the SRDF device pair appear to one or more hosts as the
same device.
Active/active replication capabilities on both the source and target sites.
Witness support to enable full HA, resiliency, and seamless failover.
SRDF/METRO RESILIENCY
SRDF/M maintains consistency between the R1 and R2 devices during normal operation. If, however, a device or devices move to the
not ready (NR) state or connectivity is lost between the arrays, SRDF/M selects one side of the environment, known as the “winner,”
and makes the other side inaccessible to one or more hosts. There are two ways that SRDF/M can determine a winner: bias or
Witness. The bias or Witness prevents any data inconsistencies that might result from the two arrays being unable to communicate.
SRDF/Metro bias
With or without Witness, bias is a required component of SRDF/M. Witness builds on the bias functionality; in essence; bias becomes
the failsafe if Witness is unavailable or fails. The initial createpair operation of SRDF/M assigns bias to the R1 site, though it is possible
to change it to the R2 site after initial synchronization. Note that changing the bias turns the R2 site into the R1 site. In the event of a
failure, SRDF/M makes the non-biased side inaccessible to one or more hosts, while the bias site (R1) survives. Bias is denoted by the
state of ActiveBias on a device pair or SRDF group, as shown in Figure 3. Note that the bias location is Local, meaning this is the R1
site.
If the bias site (R1) experiences the failure, the entire SRDF/M cluster becomes unavailable to the hosts and requires user intervention
to rectify. To avoid these types of failures, EMC offers the Witness.
2 See E-Lab™ for the currently supported hosts and multi-pathing software, along with any additional ePacks required on top of the Q3 2105 SR release.
The E-Lab Interoperability Navigator can be found at: https://elabnavigator.emc.com.
Figure 3. SRDF/Metro ActiveBias configuration
Alternatively, if the groups are added after synchronization, at the next re-establish, the Witness takes effect. It is also possible to
configure multiple Witnesses if multiple arrays are available. In such cases, SRDF/M handles the use of multiple Witnesses so that if
the initial one fails, no user intervention is required to enable a secondary one.
Note: As this white paper does not detail all failure scenarios of an SRDF/M configuration, refer to EMC VMAX3
SRDF/Metro Overview and Best Practices for more information.
SRDF/Metro Witness
As noted in the previous paragraph, SRDF/M by default uses site bias to define how a site or link failure should be handled in an
SRDF/M configuration. If two clusters lose contact, the bias defines which cluster continues operation and which suspends I/O. Bias is
defined at the SRDF group level. The use of bias to control which site is a winner, however, adds unnecessary complexity in case of a
site failure since it may be necessary to manually intervene to resume I/O to the surviving site. SRDF/M has the capability to use a
Witness, instead of bias. The Witness is an external arbiter running on a separate VMAX or VMAX3 for physical witness configuration.
The Witness can also be VMware virtual machine (vWitness) with the same functionality as physical witness except that it is packaged
to run in a virtual appliance. The use of the Witness supersedes the bias functionality. If the SRDF groups to the Witness are present
before the createpair command is executed, one or more device pairs automatically enter a Witness Protected state upon
synchronization and the state is ActiveActive.
Multiple virtual witnesses can be configured. The VMAX can reside in a physically separate failure domain to either VMAX storage
system in the metro configuration if desired. The Array Witness, if configured, takes precedence for arbitration for the surviving site.
Witness provides the following features:
Active/active use of both data centers
HA for applications (no single points of storage failure, auto-restart)
Fully automatic failure handling
Load balancing and better resource utilization
Lower capital expenditures and lower operational expenditures as a result
Note: Fault domain is decided by the customer and can range from different racks in the same data center all the way up to a 5
ms of distance away from each SRDF/M cluster (5 ms measured latency or typical synchronous distance).
A configuration that uses SRDF/M with Witness allows both sides to provide coherent read/write access to the same volume. This
means that on the remote site, the paths are up and the storage is available even before any failover happens. SRDF/M combined with
host failover clustering technologies such as WSFC provides fully automatic application restart for any site-level disaster. The system
rides through component failures within a site, including the failure of an entire array.
In the event of a complete site failure, as shown in Figure 4, Witness automatically assigns the R2 array as the winner, rather than
following the R1 site bias. VMware HA detects the failure of the virtual machines and restarts the virtual machines automatically at the
surviving site with no user intervention.
Figure 4. SC with SRDF/Metro Witness
SRDF/METRO AND SRDF WITNESS FAILURE HANDLING
There are EMC documents available that cover all the various failure scenarios that can impact an SRDF/M environment. As this paper
does not specifically address those scenarios, see the References section for more information.
SRDF/METRO SUPPORT MATRIX
The SRDF/M (active mode) support matrix is actively updated with new host environments, qualifications, inter-operability, and
information regarding enhancements to base products. Refer to SRDF/Metro simple support matrix for the most up-to-date information
pertaining to your environment. This matrix also discusses some specific requirements for SRDF/M configuration with WSFC services.
SRDF/METRO STORAGE CONFIGURATION
SRDF/M can be configured using Solutions Enabler CLI (SE CLI) or Unisphere for VMAX. EMC recommends using Unisphere to
configure and manage SRDF/M. The Appendix describes configuring SRDF/M using Unisphere in more detail along with corresponding
screen shots. The Appendix also covers SRDF/M configuration using Solutions Enabler CLI (SE CLI).
To set up the SRDF/M configuration:
1. Set up the SRDF connection between R1 and R2 arrays.
2. Create storage groups on R1 and R2 sites.
3. Create SRDF groups and use them to create SRDF device pairs across those storage groups.
4. Establish SRDF/M relationships and synchronize both R1 and R2 storage groups.
5. Incorporate Witness as needed using Witness or vWitness capabilities.
SRDF/METRO CONFIGURATION FOR SQL SERVER FAIL OVER CLUSTERS
WSFC is a group of independent servers that work together to increase the availability of applications and services. SQL Server 2016
takes advantage of WSFC services and capabilities to support SQL Server failover cluster.
SRDF/M enables Read/Write storage access for all nodes of WSFC to improve RTO for the SQL Server failover cluster, even prior to
actual failover. Active cluster nodes can also access either side of the SRDF/M configuration, which offers better utilization of resources
and load balancing for SQL Server databases.
To configure SQL Server failover cluster using SRDF/M:
1. Set up WSFC using multi-path enabled nodes.
2. Provision VMAX devices for fail over cluster needs on both R1 and R2 sites and set up SRDF/M using the storage groups and full synchronization
of both storage groups.
3. Use multi-pathing solutions like Windows MPIO or EMC PowerPath® to support cross connect. This ensures storage visibility to all failover cluster
nodes from both SRDF/M managed storage groups. Multi-pathing solutions should use configurations that allow load balancing across all available
paths for optimal performance. Refer to Windows MPIO KB article for more information about Windows MPIO configuration. When using
PowerPath, the default VMAX path policy is suitable for most configurations.
4. Set up Witness or vWitness to detect cluster split-brain situations.
5. Discover the disks using Windows disk manager. Bring the disks online and format them.
6. Add the disks as the cluster resource.
7. Set up SQL Server failover cluster on the clustered disks.
Note: The example here shows WSFC, but SRDF/M can also be used for SQL Server nodes running on either side of the
configuration for load balancing and better utilization of resources.
Figure 5 shows the configuration.
Figure 5. SQL Server Failover Cluster using SRDF/Metro
SQL SERVER FAILOVER CLUSTER USING SRDF/METRO TEST CASES
This section presents the SQL Server failover cluster using SRDF/M test cases.
HARDWARE AND SOFTWARE CONFIGURATION
The test environment consists of two Cisco C240M3 servers in WSFC configuration with storage provisioned from two VMAX 850F
arrays. SDRF/M is configured between SQL Server failover cluster storage groups. The online transaction processing (OLTP) workload
is run on the active cluster node before and after failover.
Table 1. Test case configuration
Category Type Quantity/Size Version/Release
Storage system EMC VMAX 850F 2 x V-Brick (R1: 572 R2: 569) HYPERMAX OS 5977
Database server UCS C240-M3 2 – Servers supporting Microsoft Windows Failover Cluster
Microsoft Windows Server 2012
SQL Servers Two SQL Server failover cluster instances on stand-alone servers
2 – SQL Servers Microsoft SQL Server 2016
TEST CASES
TEST 1: RUNNING SQL SERVER WORKLOAD ON R1 SIDE OF SRDF/METRO CONFIGURATION
TEST OBJECTIVES
This test shows a scenario with SQL Server database OLTP workload running on SRDF/M R1 side with consistent low latency and a
high transaction rate while maintaining remote HA with active availability of the storage.
TEST CONFIGURATION
We ran a single SQL Server database OLTP workload running on 128 GB C240-M3 server with SQL buffer pool size of 4 GB. SRDF/M
HA for VMAX storage devices was maintained to ensure low RTO in the event of failover.
TEST RESULTS
As shown in Figure 6, SRDF/M maintained consistent IOPS for the application at <1 ms latency. At the same time, SQL Server
maintained a consistent transaction rate of 540K while maintaing HA of storage devices at the remote site, as shown in Figure 7.
Figure 6. VMAX Performance Profile for SQL Server workload running on R1 side before failover
Figure 7. SQL Server transaction rate for workload running on R1 side before failover
TEST 2: RUNNING SQL SERVER WORKLOAD ON REMOTE SIDE OF SRDF/METRO CONFIGURATION
TEST OBJECTIVES
This test shows a scenario with SQL Server database OLTP workload running SRDF/M remote side (R2) after cluster failover with
consistent low latency and a high transaction rate while maintaining HA with active availability of the storage.
TEST CONFIGURATION
The SQL Server resource group on WSFC failed over to another node using a move operation on WSFC Manager, and the application
was restarted. The workload identical to the workload in Test Case 1 was run on a new owner node and performance metrics were
collected.
TEST RESULTS
As shown in Figure 8Error! Reference source not found., VMAX SRDF/M supported the workload on the remote site after cluster
failover with <1 ms latency and similar IOPS. At the same time, SQL Server maintained a consistent transaction rate of 540K on the
new owner node, as shown in Figure 9.
Figure 8. VMAX Performance Profile for SQL Server workload running on R2 side after failover
Figure 9. SQL Server transaction rate for workload running on R2 side after failover
CONCLUSION
SRDF/M running HYPERMAX OS is an enterprise-class technology that dissolves distance by providing active/active access to
dispersed VMAX All Flash and VMAX3 storage systems, enhancing availability and mobility. Using SRDF/M with WSFC and SQL
Server failover cluster technologies provides new levels of availability suitable for the most mission-critical environments without
compromise.
These technologies provide the basis by which a customer can ensure HA at both the hardware and software level – through the nature
of SRDF/M and WSFC. With active storage availability from both sites on SRDF/M clusters, applications can run on local and remote
sites, simultaneously improving the resource utilization and offering load balancing across the distance.
REFERENCES
The following documentation provides additional and relevant information. Access to these documents depends on your login
credentials. If you do not have access to a document, contact your EMC representative.
VMAX and SRDF Product Guide
EMC Simple Support Matrix (includes SRDF and requirements for Microsoft failover clusters
APPENDIX
CONFIGURATION OF SRDF/METRO USING UNISPHERE
This section covers the configuration of SRDF/M using Unisphere. The following objects are assumed to exist as their creation is
independent of SRDF/M:
Devices on each site created and placed in a single SG on each array
Initiator groups for each WSFC node on each site
Port groups for each site
Masking views for cluster nodes on each site
SETTING UP SRDF CONNECTION AND CREATING SRDF GROUP
If both R1 and R2 VMAX systems are not visible to Unisphere, which is the case when VMAX eManagement guest is used as the
Unisphere server, the SRDF connection must be established between local and remote VMAX systems. It is expected that SAN
connectivity between both VMAX systems is established prior to running this task to help discover the remote VMAX system.
To set up the SRDF connection:
1. From Replication Groups and Pools, select SRDF and choose Create SRDF Connection, as shown in Figure 10.
2. Enter SRDF group label and number and select local VMAX RDF ports.
3. Scan for the remote SRDF VMAX system, enter the SRDF group number, and choose SRDF ports on that VMAX system, as shown in Figure 11
and Figure 12.
Figure 10. Setting up SRDF connection
Figure 11. SRDF connection R1 side
Figure 12. SRDF connection R2 side
CREATING SRDF/METRO GROUP OR WITNESS GROUP
Once the SRDF connection is established between R1 and R2 VMAX systems, the SRDF group can be created using the wizard.
To configure the SRDF/M groups:
1. Select the local and remote VMAX systems and corresponding SRDF ports, as shown in Figure 13.
2. Type the SRDF group label and number for both VMAX systems.
The Witness group can also be created using the same wizard by selecting the checkbox for SRDF/Metro witness group.
Figure 13. SRDF/Metro group creation wizard
CREATING SRDF/METRO DEVICE PAIRS
Once the SRDF/M group is created, devices can be added to the group.
To configure SRDF/M device pairs:
1. Select the SRDF group and select Create Pairs, as shown in Figure 14.
2. Identify the R1 side of SRDF mirror to use as the source device for SRDF replication. Select Active for the SRDF Mode.
3. Specify the start device IDs for the R1 and R2 sides and the number of volumes to be included in the SRDF/M group. Additional devices or non -
sequential devices can also be added separately.
4. If the devices are not already in the storage group, choose R1 and R2 storage groups to add the devices for application provisioning. By default, a
subsequent SRDF/M storage group establish operation invalidates R2 devices. This can be changed using the Advanced option. Devices can also
be formatted to delete existing data prior to application provisioning.
Figure 14. SRDF/Metro device pair creation
SYNCHRONIZING SRDF/METRO DEVICES PAIRS FOR ACTIVE/ACTIVE AVAILABILITY
Once SRDF/M device pairs are created, the SRDF/M group remains in the Suspended state.
To establish SRDF/M groups for active availability:
1. Select the SRDF/Metro storage group and choose Establish, as shown in Figure 15.
2. Choose Incremental or Full to synchronize device tracks from R1 to R2, which invalidates all existing tracks on R2. The Establish complete storage
group is now actively available on both sides for the SRDF/M group, as shown in Figure 16.
Figure 15. SRDF/Metro storage group establish for active availability
Figure 16. SRDF/Metro storage group with active availability
SRDF/METRO WITNESS CONFIGURATION
This section covers the Witness configuration for the SRDF/M group.
SETTING UP SRDF/METRO WITNESS CONFIGURATION
Witness configuration requires creating an SRDF group with R1 and R2 VMAX systems with a VMAX on a separate failure domain.
Complete the steps in the SRDF Metro group creation section and select the SRDF/Metro Witness group checkbox to designate the
new group as a Witness group.
SETTING UP SRDF/METRO VWITNESS CONFIGURATION
To configure SRDF/M vWitness:
1. Select the SRDF Virtual Witnesses configuration wizard, as shown in Figure 17.
2. Add vWitness by providing the name, IP address, or DNS-based hostname information for the virtual machine, as shown in Figure 18.
3. Review the vWitness configuration and state, as shown in Figure 19.
Figure 17. Configuration of vWitness
Figure 18. vWitness IP configuration
Figure 19. vWitness configuration and state
WINDOWS SERVER FAILOVER CLUSTER SETUP USING SRDF/METRO
To configure WSFC using SRDF/M active availability after the SRDF/M group is created:
1. Set up cross connect for SRDF/Group device visibility to all cluster nodes by creating masking views on R1 and R2 arrays, as shown in Figure 20
and Figure 21.
2. Scan the disks from Windows Disk Manager and bring them online, as shown in Figure 22.
3. On WSFC manager, browse to Storage and add disks discovered to the cluster, as shown in Figure 23.
4. On disk manager, partition the disks and assign the drive letters or mount the volumes, as shown in Figure 24.
5. Install SQL Server failover cluster using clustered disks and set up the SQL server role, as shown in Figure 25.
CROSS CONNECT CONFIGURATION FOR VISIBILITY TO ALL SRDF/METRO STORAGE GROUP DEVICES
WSFC requires visibility to all the devices to detect split/brain situations. SRDF/M storage groups on both R1 and R2 devices should be
provisioned to all nodes of the cluster. As shown in Figure 20 and Figure 21, masking views are created for both cluster nodes to have
devices visible to them.
Figure 20. SRDF/Metro cross connect R1 site setup
Figure 21. SRDF/Metro cross connect R2 site setup
Figure 22. Windows server disk management for cluster disks
Figure 23. Add disks to cluster using Windows server failover cluster manager
Figure 24. Partition the disks and assign drive letter or mount the volume
Figure 25. SQL Server failover role created using cluster disks
SQL SERVER FAILOVER MANAGEMENT
This section covers various operations for SQL Server failover management using WSFC management. As the storage is accessible to
all cluster nodes, planned failover management simply requires moving the ownership of the cluster. In the event of unplanned failover,
cluster resources are restarted on the surviving site.
1. As shown in Figure 26, ensure that the SQL Server role has proper node ownership identifying nodes on the R1 and R2 site.
2. As shown in Figure 27, select the node to move the cluster to.
Figure 26. SQL server role ownership for SRDF/Metro
Figure 27. Moving the cluster role
CONFIGURATION OF SRDF/METRO USING SOLUTIONS ENABLER CLI
SAN DISCOVERY FOR AVAILABLE VMAX ARRAYS
# symsan list -sanrdf -sid 569 -dir ALL
Symmetrix ID: 000197200569
Flags Remote
------ ----------- ------------------------------------
Dir Prt Lnk
Dir:P CS S S Symmetrix ID Dir:P WWN
------ --- --- --- ------------ ------ ----------------
01F:08 GO O C 000197200572 01F:08 500009737808F008
01F:08 GO O C 000197200572 02F:08 500009737808F048
01F:09 GO - I - - 0000000000000000
Legend:
Director:
(C)onfig : S = Fibre-Switched, H = Fibre-Hub
G = GIGE, - = N/A
(S)tatus : O = Online, F = Offline, D = Dead, - = N/A
Port:
(S)tatus : O = Online, F = Offline, - = N/A
Link:
(S)tatus : C = Connected, P = ConnectInProg
D = Disconnected, I = Incomplete, - = N/A
CREATING SRDF/METRO GROUP OR WITNESS GROUP
# symrdf -sid 572 addgrp -label SQL_M -rdfg 100 -dir 1F:08,2F:08 -remote_rdfg 100 -remote_sid 569 -
remote_dir 1F:08,2F:08 –nop {-witness}
Successfully Added Dynamic RDF Group 'SQL_M' for Symm: 000197200572
CREATING SRDF/METRO DEVICE PAIRS USING THE STORAGE GROUPS
# symrdf -sid 572 -sg DSIB1118_9_SQLFC_SG__RAC_DB -rdfg 200 createpair -type R1 -remote_sg
DSIB1118_9_SQLFC_SG -rdf_metro -invalidate R2 –nop
An RDF 'Create Pair' operation execution is
in progress for storage group 'DSIB1118_9_SQLFC_SG'. Please wait...
Create RDF Pair in (0572,100)....................................Started.
Create RDF Pair in (0572,100)....................................Done.
Mark target device(s) in (0572,100) for full copy from source....Started.
Devices: 0059-0064 in (0572,100).................................Marked.
Mark target device(s) in (0572,100) for full copy from source....Done.
The RDF 'Create Pair' operation successfully executed for
storage group 'DSIB1118_9_SQLFC_SG'.
ESTABLISHING SRDF/METRO GROUP
# symrdf -sid 572 -sg DSIB1118_9_SQLFC_SG -rdfg 100 establish –nop
An RDF 'Incremental Establish' operation execution is
in progress for storage group 'DSIB1118_9_SQLFC_SG'. Please wait...
CHECKING STATE OF SRDF/METRO GROUP
# symrdf -sid 572 list -rdf_metro
Symmetrix ID: 000197200572
Local Device View
---------------------------------------------------------------------------
STATUS MODES RDF S T A T E S
Sym Sym RDF --------- ----- R1 Inv R2 Inv ----------------------
Dev RDev Typ:G SA RA LNK MDATE Tracks Tracks Dev RDev Pair
----- ----- -------- --------- ----- ------- ------- --- ---- -------------
00064 0009C R1:100 RW RW RW T..1. 0 0 RW RW ActiveBias
00065 0009D R1:100 RW RW RW T..1. 0 0 RW RW ActiveBias
Total ------- -------
Track(s) 0 0
MB(s) 0.0 0.0
Legend for MODES:
M(ode of Operation) : A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
: M = Mixed, T = Active
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