EMC WHITE

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

2

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

3

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

4

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

5

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.

6

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.

7

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

Number of nodes/replicas

Standard: 2 SQL Server 2012 – 5 (including primary)

Enterprise and Datacenter: 16 SQL Server 2014 – 9 (including primary)

Readable secondary copies No Yes

Applicable failover policy settings

WSFC quorum WSFC quorum

Availability group settings Availability Group 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

8

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.

9

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.

10

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

11

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.

12

Figure 7. XtremIO and Multi-Site AlwaysOn Availability Groups

13

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.

14

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.

15

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.

16

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 SQL Srv 2 SQL2_SystemDB

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

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.

17

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.

18

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

19

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.

20

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

21

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

22

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

23

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

24

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

25

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.

26

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

27

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.

28

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)