Although application consistency is more often discussed in the context of virtual machine (VM) backups, it’s just as important to consider a strategy for fail over replicas. In fact, if you are both backing up and replicating the same VM(s) it becomes even more critical. With Veeam, the configuration for application consistency (and the GUI windows for doing so) are the same for replication as for backup. Therefore, much of the info here will be in reference to backups even though this is a post in a series about replication only.
Overall, this post touches on some of the options and strategies administrators have when planning to provide application consistency for both Windows and Linux VMs. Various links to KB articles, blog posts, and white papers are provided for additional reading.
The rest of this post is divided into 4 sections:
- Agentless options for Windows VMs
- Agentless options for Linux VMs
- VM Cluster nodes
- Should you truncate logs for a replication job?
A good download for starters
A few years ago Veeam presented Considerations for backing up Exchange and Oracle for a VMware User Group. These are popular applications, and I refer to this information in the rest of this post. The methods discussed for each provide a great example of the process and strategy involved in both Windows and Linux VMs. Download a copy here:
When Veeam introduced the new distributed architecture with v6.0 there were significant improvements to the replication engine in both speed and efficiency. There were also significant changes to the Veeam architecture that enabled the improvements. In my experience, many customers have misunderstood the deployment requirments and the various configuration options when first attempting new v6 jobs. The trouble is due partly to upgrades of in place Veeam v5.x jobs, but also the fact that the out-of-the-box automatic proxy selection settings would sometimes cause less than optimal results when configured for multiple site replication.
This post explains the new proxy architecture and requirements at a high level and offers some tips on making sure things work right. There are a few screen shots from the Replication and Proxy wizards, but If you need more technical details on Veeam Proxies and the actual features or job configs please be sure to check the Veeam User Guide and the Veeam Forum F.A.Q (linked below).
The easiest way to understand the Veeam v6 Proxy architecture is to realize the data flow of a Veeam replication job. That is explained very simply in the Veeam Forums Backup and Replication F.A.Q:
Q: What is the data flow in case of replication?
A: Disk > Source proxy > Network > Target proxy > Disk
Q: Can I use the same source and target proxy for replication?
A: Yes, but only when replicating locally (on-site replication).
“Danger Will Robinson!” Notice the last Q&A? You will need at least one Veeam Proxy at both the Source and Target sites if they are different locations. You may need to add more than one Veeam Proxy per site. More on why later in this post.
The basic Veeam replication architecture is illustrated in the following whiteboard diagram:
You don't really know your VMs until you try to backup or replicate them on a schedule. You may think you do, but you really don't. I'll even broaden the claim: You don't really know your virtual infrastructure (V.I.) until you start creating and committing snapshots on a schedule.
Fact is, if you want cost effective replicas of your VMs for disaster recovery fail-over using hypervisor based technologies you are about to ask your V.I. to “turn your head and cough”. Reliable, fast and efficient replication in a minimal window starts with providing good health in your storage, hosts, and virtual machines. You will probably have to make some changes to your architecture and design. As I've pointed out before, few planned and then actually built their virtual datacenter with a specific tool for disaster recovery in mind. The good news is that by optiizing snapshots you will probably fix many those nagging performance issues you've struggled with for a long time.
I know. I know. I and others have said in the past that snapshots in in your virtual datacenter are a bad idea. Well, the context of the discussion before was not to leave running snapshots open. That is not the context here. In fact, hypervisor based replication should never leave behind snapshots in your environment. Veeam Backup and Replication does not, nor do all of the other alternatives that I know about, leave behind snapshots. Sure, things can go wrong, but that is usually because of abnormal events in the environment (connectivity loss, Veeam architecture server reboots during jobs, etc). Things go wrong with snapshots without Veeam in the mix all the time. More on this later in the post.
BTW, Veeam is also smart enough to clean up left behind snaphots from previous jobs, and smart enough to leave a snapshot alone that Veeam did not create. There is never a “delete all” command issued to the hypervisor. If a snapshot already exists then Veeam does it thing with a new snapshot without touching the existing one.
The point is snapshots play a major role in hypervisor based replication and you can optimize their performance. An unhealthy snapshot process means that the replication job will take excessively long or will fail. This post explores what can be done.
Psst! Let me let you in on a little secret. Veeam Explorer for Exchange (VEX) is a little more versatile then you might think.
There's been some great coverage on the new public beta and VEX's awesome ability to crack open Exchange 2010 Veeam Backups like a piñata of messaging goodness, but the fiesta doesn't stop with just Veeam Backups.
The truth is, no matter how you backed up your Exchange 2010 server(s), all you have to do is recover your Exchange .edb files. You can then use VEX to browse to the restored location of the unmounted database file. That means that whether you snapped a LUN, backed up Exchange with an guest agent, or even have backups from alternative products, if you can restore the .edb files VEX can do it's thing! The first time you run VEX you will need access to an Exchange .ese file since Veeam is not allowed to distribute that file, but that's another simple file restore or you can always grab a copy from your Exchange server.
Yes, you will have to install the next version of Veeam Backup and Replication to use VEX, but VEX will be available in the free, trial, and licensed versions.
That's right, you will be able to eliminate the time, effort, space, and cost of brick level Exchange 2010 backups but still granularly recover the mailbox items. Even with Veeam's free version.
Here's the VEX Overview details from Veeam's current product page:
If you've got the time to do a readiness assessment or a environemnt health check then great, but, more times than not, a company needs to get the DR solution up and running and figure out the weakest links in the chain along the way. This post offers some suggestions for standing up hypervisor based replication jobs and then adjusting them as you go.
I suggest that you give yourself at least 30 -45 days to optimize and finalize your replication design and schedule. Breaking it down in phases, I would recommend an approach using Veeam v6.x as your solution like this:
- Phase 1 (2 weeks) – install, configure, and get jobs running
- Phase 2 (2 weeks) – The 80/20 VM(s) Adjustment
- Phase 3 (1 week) – Final Tweaks
- Ongoing monitoring (forever!)
I am not diving into the technical details in this series, but there are already many posts on installing Veeam v6 and creating Proxies, creating replication jobs, or you can follow the Evaluators Guides for vSphere or Hyper-V. I've also linked to various blogs and helpful info all throughout this post.
Let's expand on what to do and what to expect in each phase.