Download Microsoft SQL Server Native High Availability with XtremIO

Microsoft SQL Server Native High
Availability with XtremIO
Extending Microsoft SQL Server Functionality with
the EMC XtremIO Storage Array
ABSTRACT
This whitepaper examines the storage efficiency and performance of Microsoft SQL
Server when employing AlwaysOn features available with MS SQL Server 2012 &
2014 on EMC XtremIO Storage Array.
April 2015
EMC WHITE
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
Copyright © 2015 EMC Corporation. All Rights Reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without
notice.
The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with
respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a
particular purpose.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All trademarks used herein are the property of their respective owners.
Part Number H14148
2
TABLE OF CONTENTS
EXECUTIVE SUMMARY .......................................................................... 5
Audience ....................................................................................................... 5
INTRODUCTION .................................................................................... 5
Findings ........................................................................................................ 5
MS SQL SERVER HIGH AVAILABILITY ................................................... 6
AlwaysOn Failover Cluster instances (FCI) ......................................................... 6
AlwaysOn Availability Groups (AAG) ................................................................. 6
Availability Modes .......................................................................................... 6
Choosing a Protection Model ............................................................................ 7
XtremIO’s Ability to Change the Non-Shared Storage Model ................................ 8
ALWAYSON ARCHITECTURAL CONFIGURATIONS .................................. 9
AlwaysOn Failover Cluster Instances with XtremIO Writeable Snapshots ............... 9
AlwaysOn Bidirectional Replication Solutions with XtremIO Writeable Snapshots .. 10
AlwaysOn Failover Cluster Instance Combined with Availability Groups and XtremIO
Writeable Snapshots ..................................................................................... 13
VALIDATION ....................................................................................... 14
Validation Scenarios ..................................................................................... 14
Monitoring Performance Metrics ..................................................................... 14
Test Databases ............................................................................................ 15
Test Environment ......................................................................................... 15
SQL Server Configuration .............................................................................. 15
Storage Design ............................................................................................ 16
3
Seeding Database Copies .............................................................................. 17
Using XtremIO Snapshots for Secondary Replica Seeding .................................. 17
Deduplication Ratio of Primary and Secondary Database Copies ......................... 18
Monitoring Availability Groups........................................................................ 20
Maintaining Performance in Synchronous-Commit Mode .................................... 21
Multi-Database, Multi-AG Scenario with Writeable Snapshot Copy ...................... 23
Validation Summary ..................................................................................... 26
CONCLUSION ...................................................................................... 27
Findings ...................................................................................................... 27
REFERENCES ....................................................................................... 28
EMC Documentation ..................................................................................... 28
White Papers ............................................................................................... 28
Product Documentation................................................................................. 28
Microsoft Documentation............................................................................... 28
4
Executive Summary
Efficiency, performance and protection are paramount in today’s modern datacenters, where administrators are required to lower
storage costs while at the same time guarantee strict SLA agreements for their customers, including protecting latency sensitive
Online Transaction Processing (OLTP) database environments hosted on Microsoft SQL Server.
As a refinement to the native high-availability options for SQL Servers, Microsoft introduced the AlwaysOn offerings in SQL
Server 2012. These offerings include AlwaysOn Failover Cluster Instances (FCIs) that provide enhancements to SQL Server
clustered instances, and the AlwaysOn Availability Groups (AAG) feature, which provides a refinement to databases mirroring
and log shipping. AAG, in particular, provides a high-availability and disaster recovery solution which enables to maximize
availability for one or more user databases with a bidirectional replication solution, even across multiple sites and multiple
subnets.
The advantage of AlwaysOn Availability Groups over Microsoft’s HA offering of AlwaysOn Failover Cluster Instances (FCI) is the
ability to have accessible and readable secondary copies of production databases, rather than the active/passive databases
model of FCI. This can provide a more balanced use of datacenter hardware to enable a native bidirectional replication solution.
Using Availability Groups will however increase the storage requirement by a factor of the number of copies retained. As storage
costs are sensitive, this leads to practices where secondary copies may be stored on lower performant platforms, resulting in a
performance drop in failover scenarios. Moreover, secondary copies only service readable workloads. Therefore, if a writeable
(destructive) copy of the data is required, implementing brute force processes is required, which can further increase capacity
requirements and cost.
XtremIO’s always-on Inline Data Reduction feature solves these problems by consolidating databases copies, without capacity
penalties, while providing an SLA that can be expected from an all-flash platform. XtremIO’s instantaneous zero-copy snapshots
provide writable (destructive) database copies where test/dev, reporting and analytical workloads can be performed without
impact to the production environment.
Audience
This white paper is intended for storage and database solution architects currently working with, or considering deploying MS
SQL Server 2012/2014 on EMC’s XtremIO Storage Array. The document provides information on implementing high availability
solutions, while at the same time being able to extend MS SQL Server functionality to provide writeable destructive snapshots of
production data.
Introduction
This paper documents features of Microsoft’s SQL Server AlwaysOn offerings of AlwaysOn Failover Clustered Instance (FCI) and
Availability Groups (AG) to provide native high-availability (HA) for SQL Server 2012 and 2014, and highlights how XtremIO’s
efficiency advantages can further extend the functionality of SQL Server environments by providing writeable snapshots of
databases for test/dev and analytical workloads.
SQL Server Enterprise Edition is required to use the AlwaysOn HA features which may not be an option for some customers, in
which case XtremIO instantaneous zero-cost snapshots are still available to extend SQL Server Standard Editions functionality
and provide the same destructive writeable copies.
Since the document focuses on this topic, generic product information is kept to a minimum. For more details, see the
documents and information listed in References, on page 28, which are available on the XtremIO website.
Findings
•
SQL Server AlwaysOn Failover Cluster Instance and Availability Group technology bring significant improvements to the
levels of native SQL Server protection in terms of ease of use, monitoring and performance, compared to legacy native SQL
Server protection offerings.
•
XtremIO's ability to deduplicate secondary database copies, together with its compression feature, provides significant
capacity saving for AlwayOn Availability Groups deployments.
•
XtremIO Snapshots overcome the read-only secondary copies limitation and allow the creation of writeable snapshot copies
of production databases, even when these databases are protected in synchronous replication.
•
XtremIO Snapshots can extend the SQL Server functionality, even without the requirement to choose Enterprise licensing.
5
MS SQL Server High Availability
Microsoft provides a number of options for configuring high-availability solutions for SQL Server either at the application
database or at the instance level. This document focuses on the AlwaysOn offerings which are available in SQL Server
2012/2014:
•
AlwaysOn Failover Cluster Instances (FCI)
•
AlwaysOn Availability Groups (AAG)
Mirroring and Log Shipping are available options if your SQL Server edition is pre 2012. Microsoft advises that Database
Mirroring will be removed in future versions and recommends that users move to using AlwaysOn Availability Groups. If you are
using a version of SQL Server that does not support the AlwaysOn features, Log Shipping may be an option.
AlwaysOn Failover Cluster instances (FCI)
For AlwaysOn FCI configurations, a single SQL Server instance is installed across multiple Windows Server Failover Cluster
(WSFC) nodes. The WSFC functionality provides high availability at the instance level and access via the cluster name. This
model provides an active/passive solution across shared storage, as show in Figure 1.
Figure 1.
Microsoft SQL Server FCI
AlwaysOn Availability Groups (AAG)
AlwaysOn Availability Groups support a failover environment for a specific set of primary databases and 1 - 8 sets of
corresponding secondary databases, depending on the SQL Server version. Like AlwaysOn Failover Clustering, AlwaysOn
Availability Groups require that the SQL Server instances be configured on WSFC nodes, but with the instances remaining and
being presented to the network as separate computers with failover at the level of an availability replica. Storage requirements
employ a non-shared disk model. For an example of an availability group, see the “before” picture in Figure 2.
Availability Modes
Each availability group has one of the following availability mode settings that determine whether the primary replica has to wait
before committing a transaction on a database, until the corresponding secondary replica has written the transaction log to disk
(hardening the log):
•
Asynchronous-commit mode - The primary replica commits a transaction, without acknowledgment that an
asynchronous-commit replica has hardened the log. While an asynchronous-commit mode minimizes transaction latency,
allowing the secondary databases to lag behind the primary, it makes data loss possible.
•
Synchronous-commit mode - The primary replica waits for acknowledgment that a synchronous-commit secondary has
hardened the log, before committing a transaction. Although a synchronous-commit mode increases transaction latency, it
provides protection against data loss, meaning that as long as the secondary databases are in a synchronized state with the
primary database, committed transactions are fully protected.
6
For more information on AlwaysOn Availability Groups see msdn.microsoft.com.
Table 1
Comparison between AlwaysOn Failover Cluster Instance and Availability Groups
Feature
Nodes within an FCI
Replicas within an Availability Group
Uses WSFC cluster
Yes
Yes
Storage type
Shared
Non-shared
Performs a failover of storage
Yes
No
Protection level
Instance
Database
Standard: 2
SQL Server 2012 – 5 (including
primary)
Enterprise and Datacenter: 16
SQL Server 2014 – 9 (including
primary)
No
Yes
WSFC quorum
WSFC quorum
Availability group settings
Availability Group Settings
Number of nodes/replicas
Readable secondary copies
Applicable failover policy settings
FCI-specific
Failed over resources
Server, instance and database
Database only
Choosing a Protection Model
When choosing between AlwaysOn FCI and Availability Groups, the most important factor to consider (other than the user’s own
preferences and other factors), is the storage requirements of each model. While FCI provides a shared storage model, it leaves
the user with active/passive nodes and without access to the data via the passive node(s). Thus, the hardware hosting the
passive copies sits idle. On the other hand, the AG model enables configuring secondary replica copies to allow operations such
as read-only workloads, backup from secondary copies, etc., which increases both logical and physical storage requirements due
to a non-shared storage model.
Figure 2.
Micorosoft SQL Server AlwaysOn Availability Group
7
XtremIO’s Ability to Change the Non-Shared Storage Model
Hosting MS SQL Server environments on XtremIO is an obvious choice for hosting highly transactional workloads at incredibly
low latencies. However, users should learn about the XtremIO Storage Array’s unique features. XtremIO’s ability to compress
and deduplicate multiple copies of the same database eliminates the disadvantage of AAG and changes the capacity utilization of
the non-shared model used for availability groups. Figure 2 displays the before and after states to demonstrate how XtremIO
changes the storage footprint for Availability Groups.
While in the past there may have been concerns over hosting active/passive clusters volumes (or primary/secondary in the case
of AAG) on the same underlying disk structure, XtremIO Data Protection (XDP) allows the user to have confidence in this choice.
XDP is the world’s first flash-native data protection that delivers lower capacity overhead, superior data protection and better
flash endurance and performance compared to any RAID algorithm. This is due to the fact that each SQL Server instance in an
availability group requires its own set of array volumes to be provisioned as NTFS volumes.
Figure 3 provides a conceptual view of how XtremIO is able to deduplicate and compress these volumes to provide significant
space savings.
Figure 3.
XtremIO Volume Mapping to Windows NTFS Volumes
Figure 3 demonstrates how Secondary Copy NTFS Volumes of a database Primary Copy NTFS Volumes are effectively merged
into one, and how any snapshots taken of these volumes are actually free, being an in-memory metadata operation only. Only
data differences between the multiple copies are counted as additional space usage to the original deduplicated and compressed
data, and even then the unique data benefits from compression savings. For example, if a snapshot is taken of the primary copy
replica and provisioned as a writeable (destructive) copy, additional array storage space will only be consumed for the amount of
data which is changed and manipulated, and even then only for the lifetime of the snapshot.
Another important factor to consider is the additional functionality XtremIO brings to MS SQL Server, regardless of the SQL
Server version being used. Whereas Failover Cluster Instances provide a warm standby copy of the production data, Availability
Group secondary database copies can be configured as readable secondary replica copies. However, in many situations a
readable copy may prove inadequate. Therefore, the ability to have a writeable (destructive) copy of the data will often prove
more useful. As highlighted in the "After" section of Figure 2, XtremIO provides a greatly extended flexibility of SQL
environments. These free instantaneous zero-cost writeable snapshots only consume storage to record changes from the original
data, and only for the lifetime of the snapshot. For examples of incorporating this feature, see AlwaysOn Architectural
Configurations on page 9.
8
AlwaysOn Architectural Configurations
This section details the simpler configuration option available with AlwaysOn.
AlwaysOn Failover Cluster Instances with XtremIO Writeable Snapshots
Microsoft’s AlwaysOn Failover Cluster Instances enable multiple warm standby copies. However, accessing the data held in the
passive node is restricted. In this scenario, XtremIO can greatly extend functionality by providing access to writeable snapshot
copies.
Figure 4.
AlwaysOn Failover Cluster Instances with XtremIO Snapshots
Figure 4 demonstrates how a snapshot copy of the Active databases volumes can be repurposed, on a scheduled basis, as often
and as many times as required. As a result, the failover cluster can still provide protection, and the XtremIO snapshot provides
an independent copy of the data to be repurposed as required.
9
AlwaysOn Bidirectional Replication Solutions with XtremIO Writeable Snapshots
AlwaysOn Availability Groups can provide a more flexible environment over FCI. By allowing configuration of a bidirectional
replication solution, the user can balance hardware usage within and across datacenters.
Rather than maintaining up to 8 secondary copies, as is the limit in SQL Server 2014 (4 in SQL Server 2012), administrators can
dedicate hardware to maintain availability for production systems and either repurpose snapshot copies to independent hardware
or provision to secondary replica servers, in which the hardware may be underutilized.
Figure 5 provides an example of such a configuration for a single site.
Figure 5.
XtremIO and AlwaysOn Availability Groups
10
Figure 6 provides an example of the configuration across multi-sites.
Figure 6.
XtremIO and Multi-Site AlwaysOn Availability Groups
With the performance enabled by XtremIO, maintaining synchronous-commit replication across short distances is also possible,
as shown in Figure 6. Most multi-site replication solutions employing AlwaysOn Availability Groups are likely to be asynchronous,
with the ability of MS SQL Server itself maintaining the REDO process, at distance, being the limiting factor. But with XtremIO,
low latency, such low cost, and low bandwidth solutions are increasingly possible.
Figure 7 demonstrates an even more complex solution, in which a synchronous-commit mode is maintained for two secondary
copies (the limit for synchronous-commit) across a multi-site solution. The second Availability Group is configured as
Synchronous-commit mode at the local Site A level, and as Asynchronous-commit mode between Site A and Site B. The potential
of complexity for a given solution is limited by the computer hardware availability and by the ability of MS SQL Server to host
such complex solutions.
11
Figure 7.
XtremIO and Multi-Site AlwaysOn Availability Groups
12
AlwaysOn Failover Cluster Instance Combined with Availability Groups and XtremIO
Writeable Snapshots
The user is not limited to choosing AlwaysOn FCI over Availability Groups. A combination of the two can be chosen as
demonstrated in Figure 8. The only restriction for this configuration is that SQL Server Failover Cluster Instances (FCIs) do not
support automatic failover by Availability Groups. Therefore, any availability replica hosted by an FCI can only be configured for
manual failover.
Figure 8.
AlwaysOn FCI and Availability Groups with XtremIO Snapshots
These examples highlight how employing XtremIO’s snapshot functionality to provide writeable copies can provide a simpler and
far more practical solution than trying to provision multiple secondary readable copies within availability groups, or being left
with passive inaccessible copies within AlwaysOn FCI configurations.
13
Validation
Validation Scenarios
A series of scenarios were completed to assess the behavior and performance of the suggested deployments. As AlwaysOn
Failover Cluster Instances use a shared disk model, the validation tests concentrated on AlwaysOn Availability Groups.
Tested scenarios include:
•
Deduplication ratio for primary and secondary database copies
•
Maintaining performance in Synchronous-commit mode
•
Multi-database, multi-AG scenario with writeable snapshot copy
Monitoring Performance Metrics
When monitoring SQL Server performance, several host levels performance counters can be monitored. The most obvious
monitors – Avg. Disk/sec Read, Avg. Disk/Write – provide the average read/write latency seen at the host level. Additional
counters are Transfers/sec which provide insight with IOPS and Transactions/sec or TPS.
SQL Server Management Studio (SSMS) also provides a dashboard view, where a user can monitor AlwaysOn Availability
Groups. Additional counters, such as Estimated Recovery Time (seconds) and Redo Rate (KB/sec), can be added to the view, as
shown in Figure 9.
Figure 9.
SSMS Dashboard View for AlwaysOn Availability Group Replicas
For further details on monitoring AlwaysOn Availability Groups, refer to msdn.microsoft.com.
14
Test Databases
The test databases used simulated OLTP-like workloads running a 90/10 read/write workload. These databases are based on the
TPC-E standard, as defined by the Transaction Processing Council (TPC). The TPC-E schema simulates the OLTP workload of a
brokerage firm, providing a central database that executes transactions related to the firm’s customer accounts. Although the
underlying business model of TPC-E is a brokerage firm, the database schema, data population, transactions and implementation
rules have been designed to be broadly representative of modern OLTP systems.
Unique, 100,000 user databases were used, each equating a database of 824GB in size. In Windows, the implementation of the
schema is equal to a database whose files are 1.1TB in size. XtremIO’s ability to compress this unique data, resulting in a 1.6:1
compression ratio in this instance, equates around 544GB of Physical Space Usage on the array, as shown in Figure 10.
Figure 10. Storage Properties for Initial Database
Test Environment
Testing was performed, using industry standard Intel servers (with two 10 core Intel E5-2690 3.0GHz CPUs). Each server was
equipped with a single dual port Emulex LPe 16002 HBA, attached via a Brocade SAN to a single X-Brick cluster (note that the
term cluster can refer to a single XtremIO X-Brick or a multiple X-Bricks configuration).
SQL Server Configuration
Microsoft SQL Server 2014 Enterprise Edition was used for this solution, since the AlwaysOn high availability offerings are
available only in Enterprise editions.
The following configuration options were set:
•
Max. and Min. memory settings were configured to 128GB.
•
Lock Pages in Memory was set.
•
NTFS volumes were configured with 64KB allocation size.
•
Indirect Checking was set to 60s on test databases.
15
Storage Design
To configure the environment, storage was provisioned from a single X-Brick cluster. Table 2 shows the storage configuration
provisioned for each database. Mimicking the volumes, provisioned for each host, provides the storage for the primary and
secondary database copies. Volumes were provisioned to host system databases and TempDB, with a single 1TB volume
configured a seeding repository.
Table 2
Storage Provisioning from XtremIO to Windows Host Nodes
Xtremio Volume Name
Volume Size (GB)
Used (GB)
Host
Windows Volume Name
SQL1_SystemDB
5
SQL Srv 1
SQL1_SystemDB
SQL1_TempDB
256
SQL1_TempDB
SQL1_DB1_Data_1
512
DB1_Data_1
SQL1_DB1_Data_2
512
DB1_Data_2
SQL1_DB1_Data_3
512
DB1_Data_3
SQL1_DB1_Data_4
512
DB1_Data_4
SQL1_DB1_Log
512
DB1_Log
SQL_SystemDB
5
SQL2_TempDB
256
SQL2_TempDB
SQL2_DB1_Data_1
512
DB1_Data_1
SQL2_DB1_Data_2
512
DB1_Data_2
SQL2_DB1_Data_3
512
DB1_Data_3
SQL2_DB1_Data_4
512
DB1_Data_4
SQL2_DB1_Log
512
DB1_Log
SQL Srv 2
SQL2_SystemDB
For each Instance a single volume was provisioned to host the TempDB database, which consisted of four TempDB data files and
one transaction log. Although TempDB performance requirements vary, based on workloads, this configuration performed
adequately in these tests.
Each subsequent database was configured in a similar manner, so that the storage provisioned for the secondary replica copy
matched storage for the primary replica.
16
Seeding Database Copies
There are a number of available options for seeding Availability Group replicas:
•
Full
•
Join
•
Skip initial data synchronization
Figure 11 provides a view of the available options, displayed as part of the Availability Group creation wizard.
When performing a Full Initial Data Synchronization as part of Availability Group creation, a user can take advantage of
XtremIO’s performance to speed up the backup and recovery process. It is recommended that compression be used within the
backup scripting section of an Availability Group creation process, to help reduce the duration of the seeding and reseeding
process by decreasing the size of the backup files. Using multiple backup files can further assist performance by increasing
parallelism of access. Using The Skip initial data synchronization option enables to provision via SQL Server native
backup/restore operations, or use the XtremIO’s snapshot feature.
Figure 11. Storage Properties for Initial Database
As expected, a backup/restore process is a high bandwidth sequential write/read operation, requiring adequate space to be
reserved to accommodate reseeding all of the databases covered by Availability Groups. By simply deleting the backup files,
once the process is completed, consumption of unnecessary storage space is avoided and space reclamation enabled.
Using XtremIO Snapshots for Secondary Replica Seeding
XtremIO provides the ability to seed Availability Groups via Snapshots. A snapshot is effectively a free copy of the database and,
although administrators will not see the deduplication and compression benefits reported in the XtremIO XMS dashboard view, if
speed is a priority for the reseeding process, this is a useful option.
17
Deduplication Ratio of Primary and Secondary Database Copies
To showcase deduplication ratio for a primary and secondary replica database in Availability Groups, a secondary database
replica was seeded. As a result, the following data reduction ratios were observed:
•
Data Reduction Ratio 3.1:1
o
Deduplication 1.9:1
o
Compression 1.6:1
The resulting data reduction ratios are displayed in Figure 12.
Figure 12. Storage View Properties for Single Database AG
The 1.9:1 deduplication ratio is the result of TempDBs and System databases for the two SQL Server Instances hosted on the
single XtremIO X-Brick cluster. Repeating this test, using only the files pertaining to the two database copies hosted on the array
while all other files are removed, results in a 2.0:1 deduplication ratio, as shown in Figure 13.
Figure 13. XtremIO Array Hosting Only Single Database AG Files
18
Hosting the compressed SQL Server backup file, created during the AG creation process on the array, also affects the results, as
shown in Figure 14. It is recommended to delete these files post process, so that a clearer result can be observed.
Figure 14. XtremIO Array Hosting Single Database AG Files plus Backup File
Figure 15 shows the Physical Space Used following creation of the initial single database Availability Group. Only 543.14GB of
Physical Capacity is consumed on the array, against a reported Volume Capacity usage of 1.599TB. If viewed from the OS level,
windows reports 1.1TB of data existing on each SQL Server Instance.
Figure 15. Physical Capacity Used
These results demonstrate the ability of XtremIO to drastically reduce the storage footprint of AlwaysOn Availability Groups, and
to mask the non-shared storage model used by Availability Groups.
19
Monitoring Availability Groups
In SSMS, the Availability Groups are marked as either Primary or Secondary, dependent on the instance from which the
dashboard is viewed. From the server view, shown in Figure 16, the availability group AG1 contains a database named OLTP_1
and is marked as Primary, proving it is viewed from the primary replica server.
Figure 16. Server View
Once configured, Availability Groups can be monitored via the Dashboard view in SSMS. A dashboard view is available for each
Availability Group. Figure 17 shows the dashboard view for AG1, which hosts a single database. PSQL1 holds the primary role
and PSQL2 the secondary replica role. The database is marked as “Synchronized” on both SQL Server Instances, which indicates
that this database is running in a Synchronous mode.
Figure 17. SSMS Dashboard View for Single Database AG
20
As showed in Figure 18, a second Availability Group, AG2, is configured. PSQL2 holds the “Primary” Role and the databases on
this server are marked as “Synchronized”. PSQL1 is marked as “Secondary” and “Synchronizing”. This indicates that the
Availability Group is configured in Asynchronous mode.
Figure 18. SSMS Dashboard View for Single Database AG
Note that the Failover Mode is “Automatic” for AG1 and “Manual” for AG2, demonstrating that only Synchronous mode allows for
Automatic Failover with “No Data Loss”.
Maintaining Performance in Synchronous-Commit Mode
A test workload was run against the Primary replica database in AG1, which was configured in Synchronous commit mode. As
stated by Microsoft, the use of Synchronous commit mode can increase latency due to waiting for acknowledgement of the log
being hardened. The extreme performance capabilities of XtremIO, to service performance as low latency, eliminate this problem
when SQL Server is hosted on an XtremIO array.
As demonstrated in Figure 19 and Figure 20, running an OLTP-like workload generated 32,000+ IOPS on the array with array
latency well below 1ms.
Figure 19. Latency Performance View for Synchronous Commit Mode
21
XtremIO Storage Management Application allows a User Defined Monitor to monitor the latency of individual volumes for Write,
Read and Average latency measured in microseconds (usec), as shown in Figure 20.
Figure 20. XMS Dashboard – User Defined Monitor – Volume Latency
The results show that the XtremIO array can service this workload without any restriction. The maximum latency is 854 (usec)
for logs write latency, which is the particularly sensitive in synchronous replication scenarios.
The Transaction Log performance can often be a bottleneck for SQL Server workloads. However, XtremIO’s performance
capabilities solve this problem. Although the workload can be easily pushed harder, 10,000-15,000 IOPS is generally considered
as the maximum IOPS number for the largest SQL Server databases. In this case, the database is servicing around 27,000 IOPS
while maintaining latencies of well below the one millisecond (ms) threshold.
Figure 21 shows a breakdown of the workload across the two SQL Server instances. The Primary replica is servicing 26,806
IOPS, while the secondary services 5,800 IOPS. The workload on the secondary replica consists mainly of write I/Os generated
by the REDO process. Transactions/sec (TPS) on the primary and secondary replica copies differ greatly because the secondary
replica is simply keeping in sync with the primary copy of the OLTP_1 database, but there is some activity within TempDB for
each SQL Server instance.
Figure 21. IOPS and TPS between Primary and Secondary Copies
22
The SSMS dashboard for AG1, shown in Figure 22, demonstrates the Availability Group AG1, marked as “Healthy” and
“synchronized” with “no Data Loss” at a 1 second Estimated Recovery Time. The Redo rate is shown as 6,023KB/Sec.
Figure 22. SSMS Dashboard View for AG1
The demonstrated performance is impressive, considering it is achieved while running a high availability solution which, at the
same time, is maintaining a secondary copy in a synchronized state.
As the redo process is performed between primary and secondary replicas, the data reduction ratios must be considered. Looking
at the XMS dashboard view (Figure 23), it can be seen that there is no change in the reported figures, even over an extended
workload run.
Figure 23. Data Reduction Ratio Remaining Consistent
Multi-Database, Multi-AG Scenario with Writeable Snapshot Copy
To demonstrate a somewhat more complex scenario, a bidirectional replication solution was configured, consisting of two
Availability Groups protecting three databases. A snapshot of the primary replica database copy for OLTP_1 was taken and
provisioned to an additional SQL Server instance, and a full workload was driven against this XtremIO writeable snapshot, along
with a workload being driven against all other primary databases.
The scenario details are:
•
•
•
Availability Group ‘AG1’
o
PSQL1 hosting Primary Role, PSQL2 hosting secondary role
o
Protecting a single DB OLTP_1 in Synchronous Commit mode
Availability Group ‘AG2’
o
PSQL2 hosting Primary Role, PSQL1 hosting secondary role
o
Protecting two DBs OLTP_2 and OLTP_3 in Asynchronous Commit mode
Writeable snapshot of Primary replica OLTP_1 hosted by PSQL_3
23
Figure 24. Storage Properties Pane – Efficiency
As shown in Figure 24, two copies of the three databases, OLTP_1, OLTP_2 and OLTP_3 result in a deduplication ratio of 2.0:1
and a compression ratio of 1.6:1, giving a 3.1:1 overall Data Reduction Ratio.
Looking at the capacity figures, shown in Figure 25, 1.542TB of the Physical Space are used, versus 4.799TB of Volume Capacity
used and 16.51TB of volume capacity provisioned from the array. These conditions provide a Thin Provisioning Saving of 70%.
Figure 25. Storage Properties Pane – Capacity
24
The effect of mapping the snapshot volumes of the primary replica database OLTP_1 to the third server hosting is shown in
Figure 26.
Figure 26. Storage Properties Pane – with Zero Cost Snapshot
The Storage pane shows that taking the snapshot and mapping the volumes does not change the Physical Capacity Used value.
The only change is that the Volume Capacity provisioned is changed to 19.01TB and the Thin Provisioning saving increases to
74%.
At the next stage, individual workloads were run against all databases for several hours.
Figure 27. Performance Pane
Figure 27 shows the performance reported on the XtremIO Dashboard with 122,497 IOPS reported for the combined workload
across the four databases.
25
Figure 28. Average Total Read/Write IOPS Reported from Dashboard
A point in time breakdown of Read/Write IOPS (Figure 28) shows 104,881 Reads to 15,882 Writes. The average for latencies
across the array at this point, as shown in Figure 29, is 899 microseconds (usec).
Figure 29. Write, Read and Average Latency Reported from Dashboard
Validation Summary
The results of the validation tests confirm that XtremIO is an excellent platform for hosting latency sensitive MS SQL Server
environments. The ability of the XtremIO Storage Array to service multiple workloads in complex configurations, while
maintaining a mixed synchronous and asynchronous bidirectional replication solution servicing 120,000+ IOPS, is truly
impressive. This conclusion is further validated, considering that the results include servicing a full workload against a snapshot
of a database protected in an AlwaysOn Availability Group configured in synchronous-commit, especially with an average latency
of just 899(usec).
26
Conclusion
This white paper highlights the ability of EMC XtremIO Storage Array to host SQL Server environments protected by native SQL
Server AlwaysOn offerings. Possible configurations are demonstrated, using AlwaysOn Failover Cluster Instances and AlwaysOn
Availability Group feature, in both synchronous and asynchronous modes, as well as how to configure both.
In addition, this document highlights the ability of the XtremIO’s snapshot feature to overcome the limitation of read-only
secondary copies by providing the ability to create instantaneous zero-copy writeable snapshots of production databases for
destructive analytical or test workloads.
Findings
•
SQL Server AlwaysOn Failover Cluster Instance and Availability Group technology brings significant improvements to the
levels of native SQL Server protection in terms of ease of use, monitoring and performance, compared to legacy native SQL
Server protection offerings.
•
XtremIO's ability to deduplicate secondary database copies, along with its compression feature, provides significant capacity
saving for AlwaysOn Availability Groups deployments.
•
XtremIO Snapshots overcome the limitation of read-only secondary copies and allow the creation of writeable snapshot
copies of production databases, even when these databases are protected in synchronous replication.
•
XtremIO Snapshots can extend the functionality of SQL Server, even without the requirement to choose Enterprise licensing.
27
References
For more information, refer to the XtremIO website.
EMC Documentation
These documents are available from the EMC.com or EMC Online Support websites. Access to online support depends on your
login credentials. If you do not have access to a document, contact your EMC representative.
White Papers
For additional information, refer to the white papers listed below:
•
Introduction to the EMC XtremIO Storage Array
•
Introduction to XtremIO Snapshots
Product Documentation
For additional information, refer to the following product documents:
•
EMC XtremIO System Specifications
•
EMC XtremIO Storage Array User Guide
•
Introduction to the EMC XtremIO Storage Array (Ver 3.0)
Microsoft Documentation
For additional information specifically provided by Microsoft, check the latest documentation on the MSDN and TechNet sites at
Microsoft.com and refer to the following documents:
•
Pre-Configuration Database Optimizations
•
SQL Server Best Practices
•
MSDN: AlwaysOn Availability Groups (SQL Server)
28