SQL Server on Virtual SAN Stretched Cluster – FTT1 versus RAID0 with AlwaysOn

Virtual SAN Stretched Cluster provides an option for users to build SQL Server application across two sites that are connected through a high bandwidth and low latency link, or makes active-active data centers possible.  Stretched Cluster enables automatic handling of either active/active site failure, or network failure link failing between the sites. If one site fails, data on the other site is up to date and continues to be served.

SQL Server, as one of the major products in the global DBMS market, also provides the function named AlwaysOn Availability Group which relies on the multiple database copies to serve the application continuously when the primary database service is interrupted.

Although the two business continuity technology can co-exist, implementing them together means more space usage: using FTT1 with AlwaysOn means 4x space usage for one database set.

We measured and compared the configuration of FTT1 over Virtual SAN Stretched Cluster and the configuration of RAI0 with AlwaysOn database availability group (AAG) across the two sites from the resource consumption, performance, serviceability on the site failure perspectives.

We deployed Virtual SAN Stretched Cluster with three sites: Site A and B has two ESXi hosts with 2ms inter-site delay and a witness appliance in a third site which has 200ms network latency to the two sites, for above measurement purpose.

Dell PowerEdge R630 VMware All-Flash Virtual SAN Specifications

• Dell PowerEdge R630
• CPUs: Two 24-core Intel(R) Xeon(R) CPU E5-2670 @ 2.3GHz v3
• Memory: 256GB DDR4 RDIMM
• SSD: 2 x 400GB Solid State Drive (SSDSC2BA40) as Cache SSD
• SSD: 8 x 400GB Solid State Drive (SSDSC2BX40) as Capacity SSD
• Networking: 2 x Intel 10 Gigabit X540-AT2, + I350 1Gb Ethernet
• Storage Raw Capacity: 11.88TB

SQL Server Testing Configuration (per VM)

• Windows Server 2012 R2
• SQL Server 2014 Enterprise Edition, SP1
  • Database Size: 20 scale
  • RAM: 80GB
  • Buffer Pool: 48GB
  • CPU: 24

Resource consumption

For a virtual machine with a single user database to be deployed on the Virtual SAN, if you want to deploy the VM with the single database with FTT1, the storage consumption is 2x; if you want to deploy AlwaysOn Availability Group (two replicas) with FTT0 or RAID0, the storage consumption is 2x too. But AlwaysOn Availability Group with FTT0 or RAID0 needs another virtual machine, generally having identical configuration (vCPU/Memory) to guarantee the performance be kept the same level after AlwaysON failover to the secondary replica.

Performance

We measured a 200GB TPC-E like database workload on the two configurations on the Virtual SAN Stretched Cluster. This test used SQL Server 2014 Enterprise Edition running on Windows Server 2012 R2 guest VMs, being stressed by Dell's Benchmark Factory for Databases. Each test used new restored database. The preconditioning duration is 15 minutes and the sampling duration was 45 minutes.

In FTT1 scenario, 4-node cluster is split into two sites and one site hosts the 200GB database, and in the RAID 0 & AlwaysOn scenario, 4-node cluster also is split into two sites with each site hosting one virtual machine and one database. The AlwaysOn Availability Group used the synchronous mode to allow automatic failover happened when the primary database virtual machine cannot work.

We measured 1958 TPS in the single database (FTT1) scenario, comparing with 1633 in the RAID 0 & AlwaysOn scenario. As for the response time, they are 6-7 milliseconds. But FTT1 can achieve better transaction time which was 34ms but in the RAID 0 & AlwaysOn scenario the Average transaction time was 42ms due to the log transferring and hardening on the secondary database.

The variable we pay the most attention to is average disk latency. We measured the average data and log disk write latency 4ms and 8ms in the FTT1 scenario and 15ms for data and log all in the RAID 0 & AlwaysOn scenario. For the most of the mission critical databases, using FTT1 can achieve better application response time and can satisfy the DBA’s requirement to the I/O subsystem.

Recovery duration from disaster on the production site

  Single database deployment (FTT1) cannot rely on the multiple database copies to recover the service of the database quickly. It needs the vSphere HA to reboot the virtual machine as well as the database service on another site.  The duration can often be a few minutes to finish, while AlwaysOn Availability Group needs 1-2 seconds to fail over the database (change the role of the secondary to primary)