With the introduction of vSphere v6.0, virtual environments have advanced significantly in leveraging high-performance I/O resources. In particular, a growing trend has begun in the use of solid state drives (SSDs) as data caches to boost SAN throughput and counter the I/O blender effect which randomizes I/O requests by combining requests from multiple VMs on a host. By using an SSD-based cache, IT is able to deploy more VMs, including VMs running mission-critical transaction processing (TP) applications.
More importantly for IT operations, this increases the pressure on CIOs to provide Line of Business (LoB) executives with Service Level Agreements (SLAs) for business continuity that comply with rigorous Recovery Time and Recovery Point Objectives (RTO and RPO). In particular, IT operations must be able to implement a backup process that can handle VM snapshots at the hypervisor level, application snapshots at the guest-OS level, and rapidly move snapshot data from the VM datastore to the backup repository, without degrading transaction processing on the VM application.
To test this challenging agenda, openBench Labs configured a 10GbE iSCSI SAN environment that included an SSD-based I/O caching appliance to accelerate I/O throughput. We used a Dell R710 server running Windows Server 2012 R2 to host both the client and server modules of Vembu BDR along with iSCSI initiator software to export local SAS arrays as iSCSI volumes. All of the iSCSI volumes intended for use as datastores were imported on an 8TB iSCSI Cloudistics, caching appliance. Cached volumes on the Cloudistics appliance were then imported on the vSphere hosts and the Windows 2012 R2 BDR server for direct SAN-mode backups.
We then configured a VM running Windows Server 2012 R2 and SQL Server 2014 with 36GB of memory and 12 logical CPUs as our test system. To simulate a mission critical application, we ran a 30GB instance of the TPC-E benchmark, which simulates online stock trading at a brokerage firm. Using separate system and a database logical disks, our VM consumed 129GB of active storage resources.
We began testing by running an initial full backup of our VM. Vembu BDR’s UltraBlaze™ technology automatically discovered that the Vembu BDR server shared direct access to the VM iSCSI datastore and enabled direct SAN-Mode backup. As a result, all potential VM and host overhead associated with moving snapshot data from the datastore to the backup repository was eliminated and backup throughput rapidly accelerated to 1.8Gbps, about 5X faster than a LAN-based backup process.
During our SQL Server backup, reads ran at about 250MB per second and writes proceeded at 100MB per second. The difference in read and write throughput rates reflected the effects of Vembu’s compression, data encryption and deduplication which reduced the size of our initial full backup to 60GB.
Nonetheless, the key metrics for a business continuity SLA for an active TP application are RTO and RPO, which are dependent on successful incremental backups, while the application is running in a production environment. In particular, we used a separate quad-processor VM on another host to initiate TPC-E queries at a rate of 1,000 TPS for processing on our SQL Server test VM.
Our transactions were based on a weighted set of ten fundamental queries. We made all of our queries unique via a random number generator. From an LoB business continuity perspective, our 1,000TPS SQL load added or changed enough VM data every 30 minutes to generate a 10GB incremental backup—20percent of the entire VM. More importantly from an IT operations perspective, The SQL transaction load resulted in over 1,200 write IOPS to the database disk, while SQL Server cached nearly all read operations.
While this intense write IOPS load would be highly problematic for a VM backup using Copy on Write (CoW) for Windows VSS snapshots to quiesce SQL Server. This strategy nests CoW VSS snapshots within the CoW VM snapshot created by the ESXi hypervisor. With upwards of 1,200 writes to disk taking place while CoW snapshots within COW snapshots are released, the process can become glacial and degrade processing on the VM.
In contrast, Vembu utilizes Redirect on Write snapshots with VSS. As a result, we were able to create, backup, and release snapshots in about 4 minutes.
What’s more, during these fast incremental snapshots, maximum I/O wait times were typically remained under 25ms, while the average query response time remained about 5ms.
