Niveau :
Résumé : lvm snapshot
J'ai déjà fait des articles sur LVM. Aujourd'hui parlons de snapshot en ram et d'une nouveauté du noyau 2.6.33, le snapshot-merge.
Tout comme il est possible de faire un LV en RAM, il est possible de faire un snapshot en RAM.
Pour faire un LV (Logical Volume) en RAM : il suffit d'utiliser un ramdisk comme PV(Physical Volume).
$ pvcreate /dev/rd0 $ vgcreate myvg /dev/rd0 $ lvcreate -l 100%FREE -n mylv myvg
Pour faire un snapshot en RAM :
$ pvcreate /dev/rd0 $ vgextend myvg /dev/rd0 $ lvcreate -L 100M -s -n mysnapshot /dev/myvg/mylv
Mais pour quoi faire ? Pour la même chose qu'un livecd : transformer un périphérique en lecture seule en périphérique lecture-écriture qui perdra toutes ses modifications au prochain reboot.
Seul inconvénient, les ramdisk ont une taille prédéfinie au démarrage du noyau (ramdisk_size=).
Mais j'ai gardé le meilleur pour la suite.
Maintenant qu'une nouvelle fonctionnalité a été ajoutée au noyau vous allez enfin pouvoir faire les snapshot dont vous aviez toujours rêvé.
Avant il y avait le snapshot qu'on pouvait créer, puis détruire. Selon que l'on travaillait sur le snapshot ou sur la partition originale la destruction nous ramenait à la nouvelle version ou à l'ancienne sans possibilité de choisir entre les 2 une fois le premier octet écrit. Maintenant avec le snapshot merge, il est possible de supprimer un snapshot en réimportant les données qu'il contenait dans la partition originale. Ce qui veut dire qu'on peut choisir.
Prenons un exemple parce que là j'ai franchement mal expliqué.
Toto est un sysadmin prudent, il ne fait jamais de mise à jour du système sans être sûr que ça ne posera pas de problème. Aujourd'hui on lui demande de faire une mise à jour importante, mais il ne sait pas quelles en seront les conséquences. En bon sysadmin il a déjà un noyau à jour et par chance son système est tout en LVM. Hop une synchro (rsync), un snapshot (ou plusieurs, il a bien séparé ses partitions ...), on prévient que ca peut casser et c'est parti, upgrade !
Maintenant 2 choix sont possibles :
Et voilà ! Maintenant vous pouvez faire vos mises à jour en toute sérénité ! En fin presque : on parle de la racine et donc de nombreux fichiers en cours d'utilisation sur la partition en question, ce qui veut dire reboot pour pouvoir terminer le merge. Mais le merge peut quand même se faire en live (vous pouvez déjà utiliser la partition pendant que le merge se termine en arrière plan). Il est donc possible de lancer la commande de merge, modifier son fstab si besoin et de rebooter.
Enfin n'oubliez pas une chose, les snapshot lvm ne fonctionnent qu'au niveau block device, c'est-à-dire en dessous du système de fichiers. C'est comme si vous enleviez le disque sans éteindre la machine, il se peut que le système de fichier ne soit pas au mieux de sa forme au moment ou vous le lancez, ayez au moins un système journalisé pour éviter les surprises et jouez du sync pour un peu plus de garanties.
Rien ne vaudra jamais les snapshot au niveau du système de fichier comme chez ZFS ou le futur BTRFS.
Si vous avez aimé, il y a aussi :
Comments
Lorsque j’avais passé mercure (le serveur mail du ResEl) à Lenny, j’avais utilisé un snapshot, les volumes des LV étant stockés sur du LVM. Comme je n’étais pas au courant de la fonctionnalité de snapshot-merge, j’avais fait les snapshots dans l’autre sens, i.e. :
ssh mercure sudo halt
lvcreate -s –size 2G -n mercure_etch vg1/mercure
xmg create mercure-etch perceval
(où comme son nom l’indique mercure-etch utilise comme / le disque /dev/vg1/mercure_etch)
Je n’ai pas fouillé, mais les merges de snapshots doivent être une fonctionnalité récente ; en tout cas ce n’était pas mentionné dans les documents que j’avais utilisé. Ce snapshot à l’envers a deux inconvénients : on a un downtime de quelques secondes le temps de rebooter sur l’autre volume, et surtout, puisque la machine de production tourne sur un snapshot, cela ne peut être qu’une solution temporaire (le snapshot ayant une taille limitée pour ses modifications qu’on ne veut surtout pas atteindre).
Ensuite, il y a eu quelques autres problèmes pratiques. Avant de me lancer sur la MàJ de mercure suivant cette méthode, j’avais mis à jour echelon (une machine bien moins critique). Soucis constatés :
Pour me repérer entre echelon-etch et echelon-lenny, j’avais modifié /etc/hostname de echelon-lenny. Il y a un certain nombre de systèmes qui n’aiment pas ne pas pouvoir résoudre le hostname de la machine, au vu du nombre de mails (que j’ai droppé) contenant "can’t resolve
echelon-lenny".
echelon-lenny ne pouvait pas se connecter à maia (compte MySQL / pgSQL), puisqu’elle avait une autre IP. Donc, j’ai pas testé voir si somak continait à marcher, flemme de refaire un compte avec la nouvelle IP d’echelon-lenny. On aura le même souci avec la base MySQL de sympa (qui devra probablement être convertie…) -> les modifications faites sur la base MySQL de sympa le temps de la MàJ seront perdues.
Pour mercure, il y a eu un souci d’un autre ordre : la partition des mail et de sympa (le gestionnaire des listes de diffusion) est séparée de la partition racine. Je m’étais dit que chouette, les mails vont continuer à vivre leur vie, et lors du basculement sur la version de mercure mise à jour, on va récupérer la queue des mails, et les modifications faites par les lusers sur les fichiers de conf de sympa, tout ça. Le problème, c’est qu’il s’est passé avec les fichiers de conf ce que je craignais avec les base SQL de sympa : l’un des scripts post-upgrade de sympa a fait des modifications (une sombre histoire d’encodage des fichiers) sur les configurations des listes de diffusion. Lors du basculement sur la version de mercure mise à jour, sympa n’avait plus les fichiers dans le format qu’il attendait, et a refusé de redémarrer. Dans le même genre, les seuils des spams ont dû changer, et après le passage à mercure-lenny, plein de spams ont été acceptés.
En résumé, on a eu deux soucis : les modifications sur les fichiers de configuration des listes de diffusion par les scripts post-upgrade de Debian ont été perdues. L’alternative était de perdre les modifications faites sur ces fichiers par les lusers le temps de l’upgrade (et non, je ne me voyais pas faire le merge à la main). L’autre souci, c’est que certains effets de la màj ne peuvent être se manifester que lors du passage en production.
La mécanique des snapshots en elle-même a bien fonctionné ; j’ai pu tester, en étant serein, un certain nombre de services de mercure avant le basculement. Xen en permettant de lancer rapidement une copie d’une machine sur un snapshot a également été utile (pour une fois au ResEl ?).
Ouf ! J’espère que ça ne fait pas trop brain dump, mais je me suis dit que des gens qui ne sont pas sur gestion@ pouvaient être intéressés par les notes que j’avais prises pendant l’upgrade.
Récente oui, j’ai indiqué 2.6.33
Sinon en effet il faut faire gaffe aux upgrade avec snapshot, si on ne fait un snapshot que sur / il se peut que des modifications interviennent pendant l’upgrade sur d’autres partitions système. On pense à /var avec des formats de base de données qui peuvent être mis à jour, mais il ne faut pas oublier /home sur les desktop qui contiennent des fichiers de config utilisateur qui seront mis à jour.
> Récente oui, j’ai indiqué 2.6.33.
Ah, c’est marqué dans la première ligne de l’article. Il fallait lire jusque là ? :)
Sinon, pour les choses comme /var, quelle est alors la solution ? Si on fait un snapshot de tous les volumes, on va perdre les modifications qui ont été faites sur la machine de production sur la durée de la MàJ, et sinon on perd les modifications faites par les scripts de port-upgrade…
Une position est bien sûr de dire que ce n’est pas le rôle du gestionnaire de paquets de s’occuper de la mise à niveau des fichiers de conf mais à l’opérateur. Mais c’est de l’esquive ça…
Il n’y a pas vraiment de solution.
Pour la conf /etc est lié à la racine et aux versions donc tout va bien.
Pour les données qui vont évoluer pendant la mise à jour on ne peut que espérer que les problèmes ne seront pas trop difficiles à gérer.