Tuesday, January 26, 2016

XenServer VM continuous replication [feedly]



----
XenServer VM continuous replication
// Xen Orchestra

What about having a continuous replication system for your XenServer VMs without any storage vendor lock-in? We just did it in Xen Orchestra.

You can now replicate a VM every xx minutes/hours on a any storage repository. It could be on a distant XenServer host or just another local storage. Your copied VM is always ready to boot if necessary!

Objectives

This feature covers multiple objectives:

  • no storage vendor lock-in
  • no configuration (agent-less)
  • low Recovery Point Objective, from 10 minutes to 24 hours (or more)
  • flexibility
  • no intermediate storage needed
  • atomic replication
  • distant rollback
  • efficient DR (disaster recovery) process

All of this, with your existing XenServer infrastructure. No new hardware to buy!

No vendor lock-in

Because Xen Orchestra works on the hypervisor level, you don't need to have a specific storage backend to support this feature. It could be any existing storage in your infrastructure: local storage with SSDs, or NFS storage, whatever. Do not change anything on this side!

Agent-less

No agent to install on your hosts. Just use Xen Orchestra, that's all!

Low RPO

Low RPO (Recovery Point Objective) means you can recover from a sever outage without losing time, data and thus money. By configuring the replication for every 10 minutes (for example), you can boot a copy of your VM on another site (on just another server) even if you original infrastructure is completely lost.

Do you have only one server? No problem, protect the VM by using another local storage!

No intermediate storage

Thanks to our streaming technology, we'll send bits from the source to the destination host without storing anything between. And with our back-pressure capable software, don't worry of the host network speed.

Atomic replication

What about if something goes wrong during a replication? (e.g: losing your storage). Before validate a complete transfer, we'll save the previous copied VM state. If something bad happened during the transfer, you'll still have a working VM! That's like a double buffering.

Efficient disaster recovery

You can use this feature as an efficient Disaster Recovery process. In fact, after the initial VM copy, we only transfer the disks block difference: it's bandwidth friendly and very efficient.

Best effort

Your network can't handle the replication rhythm? E.g, you configured a replication every 10 minutes, but your network can't stream the delta in less than 10 minutes? No problem: if the previous scheduled operation is still running when we call a new one, it will be discarded. Until it's possible to do it at the next scheduled try!

Configure it

As you'll see, this is trivial to configure. Inside the "Backup" section, select "Continuous Replication":

Then:

  1. Select VMs you want to protect
  2. Schedule the replication interval
  3. Select the destination storage (could be any storage connected to any XenServer host!)

In this case, we'll replicate 2 VMs to "NFS" SR which is a pool called "Other Pool". Replication will happen every 20 minutes.

That's it! Your VMs are protected and replicated as requested.

To protect the replication, we removed the possibility to boot your copied VM directly, because if you do that, it will break the next delta. The solution is to clone it if you need it (a clone is really quick). You can do whatever you want with this clone!


----

Shared via my feedly reader


Sent from my iPhone