Xen FAQ High Availability: Difference between revisions

From Xen
Jump to navigationJump to search
Line 39: Line 39:
</pre>
</pre>
The configuration file will need to have had the paths to the loopback images updated so that they point to the versions on the snapshot
The configuration file will need to have had the paths to the loopback images updated so that they point to the versions on the snapshot

5) After the machine has finished unmount and remove the snapshot volumes:
5) After the machine has finished unmount and remove the snapshot volumes:
<pre>
<pre>
Line 46: Line 47:
6) rinse and repeat
6) rinse and repeat


When you create a new snapshot its condition will of course be the original version of the virtual machine provided no changes have been made to it in the mean time.
When you create a new snapshot its condition will of course be the original version of the virtual machine provided no changes have been made to it in the mean time.


=== How do I back-up a Xen VM Environment? ===
=== How do I back-up a Xen VM Environment? ===

Revision as of 10:29, 28 November 2011

High Availability Questions

Services

What software exists for Xen to handle high availability?

A (HA1.0): Here are several tools that currently exist:

  • Remus provides transparent, comprehensive high availability to ordinary virtual machines running on the Xen virtual machine monitor. It does this by maintaining a completely up-to-date copy of a running VM on a backup server, which automatically activates if the primary server fails. Remus support is available from Xen 4, but full Category:PVOPS support wont't be available until Xen 4.2, see Remus for details.

Other projects / software:

How can I use LVM2 for snapshots to backup my domU's?

Copied from [1]

LVM2 is a set of tools which work with the device-mapper drivers of the linux kernel to provide volume management. They provide a convenient set of tools for creating, resizing and deleting volumes which can span or be striped over multiple disks. One of the convenient pieces of functionality provided by LVM is the ability to take a snapshot of an LVM volume and make it visible as another partition. This is typically useful when you want to take consistent backups. For example if you know your database is in a consistent state, you can lock it for a moment, create a volume snapshot which takes just a few seconds, and then unlock the database. You can then backup the snapshot volume to slow media or whatever.

What has this got to do with Xen? Well, it turns out that you can write to an LVM2 snapshot, and the original volume is unaffected. This means you can create a snapshot of a volume containing lvm loopback images in your desired state, then run the virtual machine on the snapshot images instead. To rollback, you simply power off the machine even with xm destroy unmount and remove the snapshot, and then recreate the snapshot and reboot the virtual machine. A process that takes only a few seconds. Here below is how its done in practice:

1) Create the snapshot of /dev/vga/domU with enough space for 6GB of alterations

lvcreate -L6G -s -n domU.S /dev/vga/domU 

(the snapshot doesnt have to be the same size as the original, it only has to have enough space to store the differences)

2) Create a mount point to mount the snapshot:

mkdir -p /workarea/xen/domains.S

3) mount the snapshot:

mount -t auto /dev/vga/domU.S /workarea/xen/domains.S/

4) Start the virtual machine

xm create -c /etc/xen/myvirtual-S.cfg 

The configuration file will need to have had the paths to the loopback images updated so that they point to the versions on the snapshot

5) After the machine has finished unmount and remove the snapshot volumes:

umount /workarea/xen/domains.S
lvremove -f /dev/mapper/vga-domU.S

6) rinse and repeat

When you create a new snapshot its condition will of course be the original version of the virtual machine provided no changes have been made to it in the mean time.

How do I back-up a Xen VM Environment?

My current environment is based on Xen 4.0.1 on Debian and virtual machines on files. The idea is to pause the machine and make copies of rsync the folders where the files reside on the disks. You through an example:

#!/bin/sh
# Script de copia para los svX hacia USB1TB
# Uso: svX_backup.sh <servidor> <nombre o id de vm> <origen> <destino>
# Los servidores destino tienen que tenen el par de claves ssh del que accede.

echo Sincronizando y pausando vm $2 del servidor $1 ...
/usr/bin/ssh $1 "xm sysrq $2 s ; xm pause $2 ; xm sysrq $2 s"

echo Backup de vm $2 [$3] a $4...
/usr/bin/rsync -avhrP $3 $4

echo Reactivando vm $2...
/usr/bin/ssh $1 "xm unpause $2"