Disaster Recovery is something that’s very near and dear to my heart all the way back to my years on the end-user side of the fence. The annual or semi-annual Disaster Recovery event is typically a very painful and long process with lots of lost sleep! Dating myself a bit, but BC/DR was even more of a challenge when we had to recover applications running on physical machines. System state restores to dislike hardware was never fun!
Virtualization’s changed the industry in many ways. One challenge IT Departments face is effectively protecting the business. What happens when we have that “smoking crater” or “How do we know we’re protected?” CIO’s around the world are asking these questions! So preparation is key.
For years Tintri customers have had the ability to efficiently replicate on premise VMs (yes, not LUNs or Volumes – individual VMs) off premise. VMs that have differing Recovery Point Objectives can be managed individually.
Tintri ReplicateVM with vCenter Site Recovery Manager (SRM)
Tintri OS 3.1 further integrates the ReplicateVM engine with vCenter Site Recovery Manager (SRM) to provide an automated orchestration and non-disruptive way to centralize recovery plans for every virtualized application! Let’s take a deeper look.
First off if you’re looking to implement Tintri VMstore with vCenter SRM you’ll want to check out the Best Practices Guide or watch the SRM Video above. These guides provide a step-by-step, soup to nuts explanation of exactly what’s required and how to get everything up and running without issue. Second, you’ll need to make sure you’ve got an appropriately setup infrastructure.
The requirements are rather basic. See illustration below.
- vCenter and SRM Primary and Recovery Sites with independent compute backed by Tintri VMstore datastore.
- Active Directory authentication at each location. Be sure to follow Microsoft Best Practice for replicating A/D. This is to utilize built-in replication and not host based or array based replication.
- Rather than using the Embedded PostgreSQL database, SRM 5.8 supports MS SQL Server 2005 – 2014 and this is the recommended route.
Now we’re all setup and you need to grab the Tintri Site Recovery Adapter (SRA) off of the Tintri Support Portal. After you download, install the SRA on both of the vCenter servers. Pretty straightforward install on your vCenter Server on both Protected and Recovery sides, next, next….finish.
Next go through the normal SRM steps of Creating Mappings, and Setting up Tintri Replication
Mount the Tintri VMstore to your ESX hosts as normal – 192.168.1.1/Tintri = However, you need to create a sub mount for each group of VMs you want to protect.
For instance my Gold RPO – 192.168.1.1/Tintri/Gold_RPO – You can create this by browsing the datastore within the vSphere console and creating a folder /Gold_RPO and then mounting 192.168.1.1/Tintri/Gold_RPO to your ESX hosts. Then sVmotion the Gold RPO VMs to the datastore.
On this datastore I now have all VMs that need recovered with the Gold Recovery Point Objective, now jump over to the VMstore UI and navigate to the Virtual Machines tab and click Service Groups. The easiest way to think of a Service Group is Service Group in Tintri = Protection Group in SRM.
For more granular RPO, 15 minutes – Click Custom, Hourly and then click in the Minutes field and choose the required RPO. Also, important to note is the ability to provide crash consistent OR VM Consistent snapshot.
VM Consistent will leverage the native VM Tools present inside of the Guest OS to quiesce applications like Sharepoint, SQL Server, Exchange, DB2, Active Directory…etc.
To wrap up the setup go through and create your Array Pair (Choosing Tintri SRA), Protection Group and Recovery Group. All of these steps are illustrated in great depth in the Video I created or in the Best Practices Guide.
One of the great parts of Tintri ReplicateVM + Tintri SRM is the ease of use and efficiency. ReplicateVM has always been extremely WAN friendly! Like many things on a Tintri VMstore, replication too is based on VM’s and snapshots. When replicating VM snapshots prior to even sending a block of data over the WAN we’ll send block fingerprints to check for which blocks are missing. Once identified we’ll send over those missing blocks in a compressed & deduplicated fashion to ensure that efficiency of the latency sensitive WAN is never over taxed with unneeded blocks of data!
With everything setup it’s pretty easy to go through and perform a test recovery of the protected VMs. Within the SRM Plugin drill into the Recovery Plan that’s been created and mapped to the Protection Group. It’s worth reiterating that the Protection Groups in SRM correlate directly to the Service Groups in Tintri.
Right click on the Recovery Group and choose Test. One of the options you’re asked with is “Do you want to replicate recent changes to the Recovery Site?” This will allow Tintri ReplicateVM to copy over the blocks of data that have changed since the last synch cycle. After the test you’ll want to right click and run the Cleanup task. During the test, since it’s not an actual failover – the Protected side still retains the authoritative copy of VMs, so Cleanup allows SRM to get everything back to the way it needs to be for normal replication to continue. Never go through and perform a Recovery, unless it’s a true failure situation. If you’re just looking to sanity check yourself, use test. Recovery moves all authoritative rights over to the Recovery side and you’ll have to re-replicate everything back to the Primary.
With that I’ll leave you with the 3 key pillars and differentiators.
- Simplicity of Configuration
- WAN Efficiency
- Visibility at a Per-VM level
So what’s the takeaway? Again Tintri continues to deliver disruptive technology that focuses on the largest and fast growing area of the Modern Data Center – Virtualization!