For Line of Business (LoB) executives, IT backup is simply a means to achieving business continuity. Their focus is entirely on recovery, which needs to be performed with a minimal loss of data and in as short a time as possible. As a result, LoB executives expect CIOs to implement rigorous internal operations to minimize any disruptions in business processing.
To enhance Disaster Recovery (DR) operations, Vembu BDR v3.1.3 provides IT with two options for maintaining offsite copies of backups. BDR v3.0 introduced the option to enhance DR resilience by replicating backup data to a Vembu DR Cloud Service. Now with BDR v3.1.3, IT administrators are able to replicate data from multiple systems running BDR Backup to a system within their own data center. Specifically, OffsiteDR Server provides IT with physical control of an alternate system from which they can recover protected VMs and physical servers using the same GUI used when recovering data from a BDR Backup server.
IT’S ALL ABOUT CONTINUITY
LoB executives expect CIOs to agree to Service Level Agreements (SLAs) for key business applications. These SLAs establish explicit Recovery Point and Recovery Time Objectives (RPO and RTO) that limit the amount of data lost if processing is disrupted and limits the amount of time taken to resume business processing. For LoB executives, backup operations are simply a part of the underlying process of guaranteeing continuous business operations.
In a virtual environment based on VMware vSphere 6.0, Vembu BDR relies on a number of unique technologies, including a document-oriented backup repository, from which to recover applications and data rapidly and reliably. To meet a minimal RTO commitment, BDR clients include Vembu’s UltraBlaze™ technology, which automatically detects the optimal data transport mode to use during a client backup. The VMBackup client first attempts to run a VM backup with no host or client involvement by directly accessing datastores containing target VM data via a physical SAN connection and then a VMware hot-add SCSI connection. Only if both of these connections fail, will the VMBackup client invoke LAN-mode data transport.
To minimize data loss and maximize IT’s potential to create multiple, secure, recovery points, VMBackup utilizes VMware’s Changed Block Tracking (CBT) and extends VMware’s VMtools utility to provide detection of key VM applications, such as MS Exchange, SQL Server and SharePoint. As a result, VMBackup is able to run full and incremental backups that are fast and consistent. During a backup of a VM running any of those applications, the VMBackup client automatically invokes Microsoft’s VSS API to create Redirect on Write (RoW) database snapshots to quiesce the application and truncate database logs within the VM, while VMware creates a Copy on Write (CoW) snapshot of the entire VM.
To enhance the ability of IT to secure and restore backup recovery points created with Vembu BDR, Vembu’s OffsiteDR Server provides a repository containing copies of the most recent backups associated with every system protected on multiple BDR Backup servers. Once an IT administrator installs OffsiteDR Server on a system that is accessible over a LAN, an IT administrator can then easily configure the Offsite Copy Management on any BDR Backup server to utilize that newly installed OffsiteDR server.
On each BDR Backup server, an IT administrator configures Offsite Copy Management, which is a server-wide function. One setting covers all backups for all systems protected on the Backup server. In this process, an IT administrator specifies three critical specifications: which OffsiteDR Server to use, when to transfer a copy of a new backup from the Backup, and the maximum number of full backups, which includes all of the incremental backups chained to each full backup, to maintain on the OffsiteDR server.
BUILDING A TEST ENVIRONMENT
To explore the ability to enhance DR resilience in vSphere 6 and Hyper-V virtual environments with Vembu OffsiteDR Server, we utilized three Dell PowerEdge R710 servers with dual 6-core processors, and two Dell PowerEdge 1950 servers with dual 4-core processors. Primary storage for all servers was provisioned using two SANs: one based on an 8Gbps Fibre Channel (FC) fabric and the other on a 10GbE iSCSI fabric.
On each of the three Dell R710 servers, we installed VMware’s ESXi hypervisor for vSphere 6.0 update 1. We then created a VMware datacenter that consisted of the three ESXi hosts. Furthermore, all datastores utilized for storing logical VM disks were created on SAN-based volumes that were shared among all three datacenter hosts. This storage topology allowed us to utilize dedicated VMs to run VMBackup client and BDR server modules to cost-effectively optimize throughput during both backup and recovery operations.
With every host able to access every datastore, we had no need to provision physical servers with dedicated FC and iSCSI SAN connections—adding capital and operating costs—as VMBackup clients. Instead, we were able to use VMs that were leveraging Vembu’s UltraBlaze technology to make hot-add SCSI connections to every datastore of every VM. What’s more, by using VMs as BDR Backup servers, we were able to leverage vSphere networking optimizations between a VM and its ESXi host when transferring data during a recovery operation.
While running the VMBackup client and BDR server modules on VMs provides distinct advantages with respect to performance, there are a number of BDR recovery features that are only supported when a BDR Backup server is run on a physical system. Nonetheless, these limitations are made moot by the advent of OffsiteDR Server. With all backups copied to an OffsiteDR Server running on a physical server, we were able to invoke all of the features that BDR provides for recovery. What’s more, were able to invoke those features from the BDR server most optimally configured to perform the function.
To examine the BDR backup architecture, we set up a VM, dubbed “Vembu,” to run both the VMBackup client and BDR server on Windows Server 2012 R2. In addition, we set up a second VM, dubbed “Vembu2,” to run just the VMBackup client module. We then paired the VMBackup client on Vembu2 with the BDR server running on Vembu. Storage for both Vembu and Vembu2 was provisioned on a shared FC SAN-based datastores. To test this backup infrastructure, we focused on a VM, dubbed “oblSQL-1,” on which we deployed an instance of the TPC-E online transaction processing benchmark.
On our test VM, we ran SQL Server 2014 to support the TPC-E database, which models a schema for a stock-trading application. We configured oblSQL-1 with three logical disks using an iSCSI SAN-based datastore. In particular, we provisioned oblSQL-1’s first logical disk as the system volume (c:) with 100GB (36GB used), oblSQL-1’s second logical disk as the SQL Server deployment volume (d:) with 50GB (4GB used), and oblSQL-1’s third logical disk as the TPC-E database volume (e:) with 100GB (30GB used).
MAKING BACKUPS MORE RECOVERABLE
Outside of our VMware datacenter, we utilized two Dell PowerEdge 1900 servers that were running Windows 2012 R2 with Hyper-V to extend the BDR backup environment. We deployed Vembu OffsiteDR Server on one of these servers, which we dubbed “Dell1950A.” On the second server, dubbed “Dell1950B,” we deployed VMBackup client and BDR server modules to protect that server’s local Hyper-V environment.
We invoked the Offsite Copy Management function on each of our BDR Backup servers—Vembu and Dell1950B to use the same OffsiteDR Server on Dell1950A. In particular, we set up each BDR Backup server to immediately replicate and transfer a copy of any backup generated by one of its clients to the OffsiteDR Server. We also configured the OffsiteDR Server to maintain the most recent two full-backups, which included all incremental backups chained to the full backups.
To facilitate distributed backup management in a large enterprise environment, Vembu BDR Backup servers support multiple VMBackup clients. Moreover, all BDR Backup servers implement a client-centric hierarchy to present all recovery activities and backup reports sorted first by backup client and then by the backup process name used on that client.
To implement a client-centric hierarchy, the Vembu BDR service, which handles all backup and recovery operations, uses the network node name of systems running the VMBackup client and BDR server modules to identify those systems. When both the client and server run on the same system, the node name is used for the BDR Backup server and “client” is appended to the node name to identify the VMBackup client. As a result, recovery activities and backup reports on our two BDR Backup servers, Vembu and Dell1950B, were sorted by clients dubbed “vembuclient,” “vembu2,” and “dell1950bclient.”
To simplify operations management, an OffsiteDR Server implements a similar client-centric hierarchy. The client hierarchy on an OffsiteDR Server, however, must be capable of resolving ambiguities introduced when a VMBackup client creates backup plans run on different BDR Backup servers. To make each client name on an OffsiteDR Server unique with respect to the original BDR Backup server in our test environment, the Vembu BDR service on our OffsiteDR Server generated a unique server code for each of our two BDR Backup servers: “BS10001” for Vembu and “BS10004” for Dell1950B.
On each backup transferred to our OffsiteDR Server, the Vembu BDR service prepended the unique server code to the client name that was used on the originating BDR Backup server. As a result, the reporting hierarchy of virtual clients on our Offsite Backup Server included: “BS10001_vembuclient,” “BS10001_vembu2,” and “BS10004_dell1950client.”
What’s more, by installing OffsiteDR Server on a physical server supporting Hyper-V, we were able to leverage tight integration with that Hyper-V environment to instantly boot any VM recovery point as a local Hyper-V VM. Since Hyper-V requires a physical server and the integration with Hyper-V requires a local host, this capability is not available on a BDR Backup server or OffsiteDR Server running on a VM. More importantly, what makes Instant Boot (IB) and similar features possible on both BDR Backup servers and OffsiteDR Servers is VembuHIVETM, the BDR document-oriented repository for backups.
With respect to VembuHIVE, the Vembu BDR service handles all Vembu BDR backup and recovery functions performed on the server. During a backup, the Vembu BDR service removes file-system metadata related to the source machine, adds content-related metadata, and restructures the resulting data for storage in VembuHIVE as value-key pairs in a hypervisor-neutral format. In addition, before storing the value-key pairs, the Vembu BDR service compresses and de-duplicates all value-key pair data for a backup. What’s more, since VembuHIVE stores value-key data without a strict schema, Vembu scales repository performance linearly with additional storage resources and is able to virtualize the repository as a logical file system.
By storing all backup data in a hypervisor-neutral format, BDR is able to expose all backups in the native file system formats of multiple virtual environments, including vSphere, Hyper-V, and KVM. What’s more, an IT administrator can then perform a virtual mount command which first creates a virtual disk on the host server and then exposes the selected VM backup in all supported VM formats within that virtual disk.
What’s more, when a recovery point in VembuHIVE is utilized to boot a VM, the Vembu BDR service adds metadata to the recovery point to create a new persistent recovery point without the need for a special cache or redo logs to enable writes. As a result, both the original recovery point and the persistent synthetic backup point are available for use in VM recovery operations.
Without the tight integration with Hyper-V hypervisor that Vembu leverages running on the same physical server, a single-click Instant Boot recovery is not available for remote ESXi or Hyper-V hosts. Nonetheless, an IT administrator is able to invoke a Virtual Drive Management feature that instantly exposes the host BDR virtual drive to ESXi hosts via NFS. As a result, from an ESXi host, an IT administrator is able to import a BDR virtual drive as a virtual datastore that contains all of the logical disks associated with recovery points for one or more VMs.
To examine the BDR NFS mechanism for recovery, we once again turned to backups of oblSQL-1. We first enabled NFS sharing of the Virtual BDR Drive on Dell1950A, our physical Windows server running BDR OffsiteDR Server. Next, we mounted two VM backups that created on our VM-based VMBackup clients in our vSphere environment. From the ESXi host, DellVMR710C, we then imported the BDR Virtual Drive on the as datastore volume, which we named “NFS_OffsiteDR.”
Finally, on DellVMR710C we created a new VM, which we named “oblSQL-1NFS.” We located the configuration files for oblSQL-1NFS on the iSCSI volume ION_XENstor and provisioned the VM with the three existing
virtual disks in the datastore NFS_OffsiteDR that represented the new persistent backup recovery point for oblSQL-1 created by the NFS mount process.
When we booted the new VM, it immediately assumed the persona of the original VM, oblSQL-1. At this point, we had two very distinct recovery options. First we could change the name and address of oblSQL-1NFS in order to recover database objects and repair the production VM. Alternatively, we were able to leverage BDR OffsiteDR Server’s ability to preserve all changes to oblSQL-1NFS in the independent persistent recovery point associated with oblSQL-1 to make and save all critical changes directly on oblSQL-NFS1. As a result, an IT administrator is then able to perform a full recovery of oblSQL-1 into the production environment using the new persistent synthetic recovery point (+P).
In our test environment, the BDR and OffsiteDR Server was able to provide far greater functionality than just recovery resilience. With OffsiteDR Server installed on a physical server, we were able to optimally leverage VMs and physical servers to implement all of the functionality provided by BDR in the most cost-effective system configuration.
We encourage you to follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
