[ libresys ]

A présent que la base de la création et de la gestion de serveurs virtuels OpenVZ est posée, nous allons nous pencher sur une possibilité très intéressante offerte par OpenVZ : le checkpointing. Nous verrons également comment cette fonctionnalité peut aider l’administrateur système à gérer des aspects qu’il ne doit pas négliger, à savoir, la sauvegarde et la restauration des serveurs, et le déplacement des services logiciels d’un serveur physique à un autre, par exemple lors du remplacement d’un matériel vieillissant.

Checkpointing de serveur virtuel

Dans la terminologie OpenVZ, le checkpointing consiste à demander, depuis le serveur physique, à figer l’état d’un serveur virtuel et à stocker cet état dans un fichier. Ce fichier contient ainsi les processus qu’exécutait le serveur virtuel et l’état de leur mémoire au moment du checkpoint. En revanche, il ne contient pas les fichiers de l’arborescence du serveur virtuel, ce qui rend le checkpoint rapide à réaliser (à peine quelques secondes).

Lorsque qu’un serveur a subi un checkpoint, il est retiré de la liste des serveurs en cours d’exécution : la commande vzlist ne le montre plus.

Ce fichier de checkpoint peut par la suite être utilisé pour restaurer le serveur exactement dans l’état dans lequel il avait été figé. Du point de vue du serveur virtuel restauré, c’est comme s’il ne s’était rien passé hormis un bond en avant dans le temps puisque les processus n’auront pas « vu passer » les secondes pendant lesquelles le serveur était figé. Si des clients étaient connectés par le réseau au serveur, et que le temps pendant lequel le serveur est figé est inférieur aux durées de timeout des connexion tcp, alors les clients ne s’apercevront de rien, ou guère plus que si le cordon réseau avait été débranché pendant quelques secondes.

Pour réaliser un checkpoint du serveur virtuel n° 123 (supposé démarré), il suffit de taper la commande suivante (en précisant le chemin vers le fichier qui devra contenir le dump) :

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump

Vous pouvez contrôler avec vzlist qu’une fois le checkpoint réalisé le serveur n’est plus en fonctionnement.

Pour restaurer le serveur dans l’état dans lequel il était au moment du checkpoint, il suffit ensuite de taper la commande suivante :

vzctl restore 123  --dumpfile /chemin/vers/123.dump

Vous pouvez contrôler avec vzlist qu’une fois le checkpoint restauré le serveur est à nouveau en fonctionnement.

Vous pouvez faire le test en ayant pris soin au préalable de vous connecter par le réseau au serveur virtuel au moyen d’un client quelconque (par exemple un client ssh), et vous pourrez constater que votre connexion perdure jusqu’après la restauration du serveur virtuel.

(Live) Migration de serveur virtuel

Là où le checkpointing devient carrément magique, c’est qu’on peut faire un checkpoint d’un serveur virtuel sur un serveur physique et restaurer l’état de ce serveur sur un autre serveur physique !

Alors évidemment il faut prendre soin au préalable de s’assurer que l’autre serveur physique dispose des fichiers qui constituent l’arborescence du serveur virtuel, ainsi que du fichier de configuration openvz pour le serveur virtuel (dans /etc/vz/conf) avant de le relancer. En effet, comme je disais plus haut, le dump ne contient que l’état de la mémoire, et le simple transfert du dump d’un serveur à un autre n’est pas suffisant. Cependant, OpenVZ vient avec un outil intéressant qui permet d’automatiser la « migration » d’un serveur virtuel d’un serveur physique à un autre. Cet outil s’appelle vzmigrate.

vzmigrate permet de déplacer des serveurs virtuels d’un serveur physique à un autre. Il prend en charge la recopie vers le serveur cible de tout ce qui est nécessaire au serveur virtuel (arborescence et fichier de configuration) et peut déplacer les serveurs virtuels soit arrêtés, soit sans interruption de service, en utilisant le mécanisme de checkpointing décrit ci-dessus. Dans ce second cas vzmigrate déplace aussi le fichier de checkpointing réalisé sur le serveur d’origine.

vzmigrate s’appuie sur ssh et rsync pour transférer les données d’un serveur vers l’autre, et il faut au préalable avoir configuré le serveur cible pour qu’il accepte une connexion depuis le serveur source sans mot de passe.

Admettons que vous disposiez de deux serveurs physiques, nommés host1 et host2 capables d’exécuter des serveurs virtuels, installés, par exemple, comme décrit dans un précédent article, et que sur le serveur host1 s’exécute le serveur virtuel 123. Pour déplacer le serveur virtuel 123 du serveur host1 vers le serveur host2, il faut faire ceci :

• une bonne fois pour toutes, on créé une paire de clés sur le serveur host1 et on informe le serveur host2 qu’il doit accepter les connexions avec cette clé sans mot de passe  (c’est à faire sur host1 en tant que root)

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub root@host2

• ensuite, pour réaliser la migration du serveur virtuel 123 de host1 vers host2, il suffit de taper ceci pour faire la migration avec une interruption de service (arrêt sur host1 et marche sur host2)

vzmigrate host2 123

• ou ceci pour faire une migration « live », avec checkpointing sur host1 et reprise sur host2

vzmigrate --online host2 123

A noter qu’il est possible de passer d’autres options à vzmigrate, comme –remove-area=yes|no qui indique s’il faut supprimer les fichiers du serveur virtuel sur le serveur source en cas de succès, ou –keep-dst qui indique qu’il ne faut pas supprimer les fichiers du serveur cible en cas de problème pendant la migration. Cette dernière option permet de gagner du temps au moment d’une nouvelle tentative puisque certains fichiers auront déjà été transmis lors de la première.

Sauvegarde et restauration de serveur virtuel

Il est essentiel de savoir sauvegarder et restaurer un serveur et les des données qu’il contient, autant pour pouvoir répondre aux utilisateurs qui demandent régulièrement de récupérer le travail qu’ils ont perdu (oui je sais, c’est pas eux qui ont perdu les fichiers, ce sont les fichiers qui ont disparus tout seuls) que pour pouvoir récupérer un service perdu suite une panne ou un sinistre. Je vous propose plusieurs méthodes.

Méthode n°1 : avec un agent de sauvegarde

Bien entendu vous avez la possibilité de sauvegarder un serveur virtuel de la même manière que vous sauvegarderiez un serveur physique, par exemple, en y installant l’agent de sauvegarde de votre logiciel préféré. A titre d’exemple, j’utilise souvent le couple ssh et rsync pour exécuter des travaux sur les serveurs à sauvegarder et pour répliquer les données sur un serveur de sauvegarde. J’utilise aussi le logiciel bacula, qui fera l’objet d’un autre article.

Je ne détaillerai pas cette méthode car d’une part elle dépend du logiciel de sauvegarde et d’autre part c’est un peu hors sujet cela ne diffère pas de ce que l’on pourrait faire sans OpenVZ, pour sauvegarder un serveur physique. Sachez toutefois que vous devez exclure les répertoires /proc et /sys de votre sauvegarde puisqu’ils correspondent à des points de montage dans lesquels le noyau présente des informations relatives au système et aux processus en cours de fonctionnement.

Pour l’anecdote, les utilisateurs du logiciel de sauvegarde Time Navigator risquent d’être déçus car il refuse de fonctionner dans un serveur virtuel OpenVZ (au moins la version que j’avais). La faute en revient à la conception capricieuse du logiciel qui résulte, à mon avis, de la volonté de l’éditeur d’implanter dans son code des dispositifs de contrôle de licence. Le fait est que j’avais déjà eu toutes les peines du monde à faire fonctionner des agents de sauvegarde Time Navigator sur les serveurs physiques d’un cluster Red Hat malgré le support technique de l’éditeur, alors après quelques essais infructueux pour le faire tourner dans OpenVZ, j’ai préféré abandonner Time Navigator pour une autre solution : Bacula. Plus simple, moins pachydermique, et de mon point de vue, plus sûr en cas de pépin. Et, en prime ça fonctionne ! Mais j’y reviendrai dans un autre article.

Pour restaurer un serveur virtuel complet, à moins que votre logiciel de sauvegarde ne vous propose une autre solution, vous devrez recréer une nouvelle instance d’un serveur virtuel minimal, avec la même distribution qu’avant, installer l’agent de sauvegarde, et restaurer votre serveur virtuel par dessus via l’agent de sauvegarde.

Selon moi, cette méthode présente un avantage et un inconvénient majeurs :

• avantage : la sauvegarde peut souvent se faire sans interruption de service ; rien de spécial à faire pour sauvegarder un serveur de fichiers, on assure le coup pour un serveur de base de données en faisant un export des bases, et voila
• inconvénient : cette méthode ne suffit pas à garantir que la sauvegarde contient bien un serveur dans un état cohérent, et du coup la restauration d’un serveur physique peut avoir des effets inattendus. Par exemple, imaginons une application qui indexe des documents en s’appuyant sur une base de données, dans laquelle on trouve des enregistrements qui contiennent les noms des fichiers indexés. Imaginons que, pendant la durée de la sauvegarde, l’application reçoive un nouveau document à indéxer. Il est tout à fait possible que, dans ce cas, la base de données soit sauvegardée avant l’arrivée du nouveau document, et les fichiers après l’arrivée du nouveau document et que par conséquent, les fichiers de la sauvegarde contiennent un document de plus que ce qui est référencé dans la base. En cas de restauration de cette sauvegarde, le fait que le contenu de la base ne soit pas cohérent avec les fichiers peut poser un problème à l’application.

Lorsqu’on travaille sur un serveur physique, éviter ce type de problème suppose habituellement d’arrêter les applications/les services pendant la durée des sauvegardes. Cependant, cela provoque une interruption de service avec laquelle il est parfois difficile de composer.

Notez que ce problème est lié au fait que la sauvegarde est assurée par un agent de sauvegarde intégré au serveur sauvegardé, et qu’il se pose aussi bien pour un serveur physique qu’un serveur virtuel. Les autres méthodes de sauvegarde que je présente ci-après s’appuient sur OpenVZ et exploitent  les moyens de contrôle que le serveur physique peut exercer sur les serveurs virtuels qu’il héberge pour faciliter leur sauvegarde et leur restauration et éviter le problème d’incohérence de la sauvegarde.

Méthode n°2 : sauvegarde à froid

Je ne m’attarderai pas sur cette méthode. Il s’agit de procéder ainsi :

• arrêter le serveur virtuel,

• sauvegarder le serveur virtuel arrêté,

• redémarrer le serveur virtuel,

par exemple :

vzctl stop 123
tar cf backup_123.tar /var/lib/vz/private/123
vzctl start 123

Evidemment, on peut faire la sauvegarde par n’importe quel autre moyen qu’un tar, mais le principe serait le même. Cette méthode présente quelques avantages par rapport à la méthode n° 1 :

• méthode uniforme : le serveur physique peut appliquer cette méthode pour tous les serveurs virtuels qu’il héberge, et il n’est pas nécessaire d’installer un agent de sauvegarde dans ces derniers
• garantie de cohérence : puisqu’il est arrêté, il ne peut rien se passer dans le serveur virtuel, durant la sauvegarde, qui rendrait cette dernière incohérente

cependant, il n’est pas toujours possible ou souhaitable d’arrêter les services que le serveur virtuel héberge, et même dans le cas ou cet arrêt est acceptable, la durée d’indisponibilité du service peut se révéler assez importante, puisqu’elle cumule la durée de l’arrêt, de la sauvegarde, et de la relance.

La restauration des fichiers se fait par un simple tar,

Méthode n°3 : sauvegarde à chaud avec durée d’indisponibilité réduite

Il s’agit d’une variante de la méthode n° 2, qui utilise le checkpointing afin de gagner du temps sur les opérations d’arrêt et de relance. Cela consiste à :

• faire un « checkpoint » du serveur virtuel,

• sauvegarder le serveur virtuel arrêté ainsi que le fichier de checkpoint,

• faire un « resume » du serveur virtuel,

par exemple :

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump
tar cf backup_123.tar /var/lib/vz/private/123 /chemin/vers/123.dump
vzctl restore 123  --dumpfile /chemin/vers/123.dump

Cette méthode présente l’avantage, par rapport à la méthode n° 2, d’éviter le temps nécessaire à l’arrêt et à la relance des processus du serveur virtuel, mais ne dispense pas de la durée de la sauvegarde. En outre, si le temps de sauvegarde est long, il est probable que les clients qui seraient toujours connectés pendant la sauvegarde se fasse déconnecter en raison des timeouts, puisque dans cet état figé, le serveur ne répond plus jusqu’à la fin de la sauvegarde.

Pour restaurer une telle sauvegarde, il faut donc extraire le contenu du tar, c’est à dire :

• les fichiers du serveur virtuel à remettre dans /var/lib/vz/private/123
• le fichier du checkpoint 123.dump

Et relancer le serveur virtuel dans le même état qu’au moment de la sauvegarde, avec la commande vzctl restore ci-dessus.

Méthode n°4 : sauvegarde à chaud instantanée

Il s’agit d’une variante de la méthode n° 3 qui permet :

• d’utiliser le checkpointing pour faire un instantané de l’état de la mémoire du serveur virtuel
• d’utiliser un  snapshot  de volume LVM pour faire une instantané de l’état des fichiers du serveur virtuel
• et de sauvegarder tout ça, en garantissant la cohérence, et sans arrêter le serveur.

En effet, nous avons vu que la méthode n° 3 nécessite un temps de sauvegarde qui peut se révéler relativement long et induire une interruption de service et/ou la déconnexion des clients. Avec cette méthode, il est possible de faire une sauvegarde « instantanée ».

En revanche, contrairement aux autres méthodes, cela suppose que le serveur virtuel soit installé dans un volume LVM. Je ne détaillerai pas dans cet article la façon de créer une partition LVM, vous trouverez des infos sur LVM à cette adresse.

Voici comment réaliser une telle sauvegarde. D’abord, on fige l’état du serveur virtuel par un checkpoint. Je vous recommande de placer le fichier du checkpoint dans le même volume lvm que celui ou se trouve le serveur virtuel.

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump

Ensuite, on fait un snapshot du système de fichiers :

sync ; sleep 1 ; sync
echo 3 > /proc/sys/vm/drop_caches
lvcreate -L 1G -s -n backup_snap /dev/xxx_vg/xxx_lv

La commande qui créé le snapshot est la ligne lvcreate. Cependant, j’ai souvent eu des difficultés à créer le snapshot si je n’exécutais pas les autres commandes juste avant. Vous devrez remplacer les paramètres de la commande lvcreate par des valeurs qui vous conviennent, en particulier la taille maximale du snapshot (-L), qui est fonction de la quantité de modifications susceptibles d’être apportées au système de fichiers pendant tout le temps ou vous conserverez le snapshot (c’est à dire, dans le cas présent, pour la durée de la sauvegarde), le nom du snapshot (-n) , et le chemin du volume logique lvm qui contient le serveur virtuel. Note : il faut qu’il reste assez de place dans le volume group pour créer un volume pour le snapshot.

La création du snapshot est quasiment instantanée, et une fois qu’il est fait, vous pouvez tout de suite relancer le serveur virtuel :

vzctl restore 123  --dumpfile /chemin/vers/123.dump

Nous disposons à présent d’un checkpoint du serveur virtuel et d’un snapshot du système de fichiers, qui à eux deux contiennent une « photo » du serveur virtuel. Pour faire cette « photo », cela n’aura pris que quelques secondes, même si le serveur virtuel contient des centaines de Go de données.  Ces quelques secondes, sont presque imperceptibles du point de vue des clients. Il ne reste plus qu’à faire la sauvegarde proprement dite. Pour cela, il faut d’abord monter le snapshot (là encore, adaptez le chemin vers le volume lvm du snapshot), afin de lire son contenu (contenu qui ne changera pas, quelles que soient l’activité du serveur virtuel relancé et la durée de la sauvegarde), puis faire la sauvegarde :

mkdir /mnt/backup_snap
mount -o ro /dev/xxx_vg/backup_snap /mnt/backup_snap
tar cf backup_123.tar /mnt/backup_snap/var/lib/vz/private/123 /mnt/backup_snap/chemin/vers/123.dump
umount /mnt/backup_snap

Et quand la sauvegarde est finie, il faut supprimer le snapshot (adaptez le chemin vers le volume du snapshot) :

lvremove -f /dev/xxx_vg/backup_snap

La restauration d’une sauvegarde se passera ici comme dans la méthode n° 3.

Conclusion

Nous avons vu dans cet article comment réaliser des checkpoints de serveurs virtuels, ainsi que des applicatiosn intéressantes de ces checkpoints pour déplacer des serveurs virtuels ou les sauvegarder.

En matière de sauvegarde, je vous recommande surtout de choisir une méthode qui soit adaptée à vos besoins. Inutile, par exemple, de monter une solution un peu compliquée avec snapshot du système de fichiers si vous n’avez pas besoin de garantir la cohérence du serveur.  Et surtout, entrainez vous à restaurer vos sauvegardes, car ce n’est généralement pas le moment ou on en a besoin qu’on souhaite découvrir qu’on est pas très au point pour restaurer ses données.