Tous en prison - Harmonie entre jails et systèmes de fichiers - Épisode 2

Intéressons nous un peu à la manière dont on gère concrètement les transferts et les sauvegardes de jails sous FreeBSD. Il y a un avant et un après ZFS, mais dans les deux cas, j’utilise le très pratique ezjail pour créer et administrer les jails. Il contient même une option pour que les jails sous ZFS se créent automatiquement dans un nouveau système de fichiers séparé.

Sans ZFS

J’utilise une partition UFS2 avec les soft updates activés que je monte en /usr/jails. J’utilise ensuite le vieux mais très performant couple dump/restore sur un snapshot de cette partition. L’option -L de dump pourrait automatiser le snapshot, mais il se trouve que l’idée est de minimiser l’arrêt des jails et que dump n’indique pas de manière précise le moment où le snapshot est terminé. La séquence est donc la suivante :

ezjail-admin stop
time mksnap_ffs /usr/jails /usr/jails/.snap/2012.MM.JJ #(compter 4 à 20mn pour 10Go en fonction du nombre de snapshots déjà présents)
ezjail-admin start
mdconfig -a -t vnode -f /usr/jails/.snap/2012.MM.JJ -u 4
time dump -0auf /media/backup/2012.MM.JJ.dump /dev/md4 #(compter 1h30 pour 10Go)
mdconfig -d -u 4

Le mieux est de commencer par supprimer les snapshots précédents, car cela joue un rôle très important pour minimiser le temps d’arrêt des jails durant la création du snapshot.

Pour transférer les jails sur un autre serveur, il faut y copier le fichier, puis formater la partition où l’on placera les jails et la monter. Enfin, on lance :
cd /usr/jails restore -r -f /media/backup/2012.MM.JJ.dump

Si on veut ne restaurer qu’une jail, on utilise :
restore -f /media/backup/2012.MM.JJ.dump -x prison1 Specify volume? 1 Set owner mode? y

Ce qui est évidemment très appréciable est l’utilisation du snapshot : 4mn d’arrêt pour mon serveur domestique, cela reste vraiment très acceptable. Alors que si j’archivais directement avec tar ou dump, il faudrait plus d’une heure et demie d’arrêt des jails.

Ce qui est un peu pénible, c’est qu’il faut transférer ce gros fichier vers le serveur et le restaurer, mais les niveaux de dump permettent d’alléger l’opération et de faire des sauvegardes incrémentielles avec une commande de type :

time dump -1auf /media/backup/2012.MM.J1.dump /dev/md4
time dump -2auf /media/backup/2012.MM.J2.dump /dev/md4 etc. 

Il est vrai qu’il faut être bien organisé et méthodique pour ne pas faire de bêtises et mélanger les différents niveaux de dump sur le serveur de sauvegarde.

Avec ZFS

Le principe est un peu différent et encore plus performant. Mes jails sont dans un pool nommé prison. Elles se situent dans prison/jails et sont montées sur /usr/jails

  • Chaque jail est sur son propre système de fichiers : il n’est donc pas nécessaire de faire un snapshot de l’ensemble des jails ; on peut n’arrêter qu’une jail et la transférer. Ceci dit, vu la rapidité et la performance du système de fichiers, je n’utilise même pas cette possibilité pour l’instant.
  • Les snapshots sont réellement instantanés – quel que soit le nombre de snapshots déjà existants. Comme j’arrête quand même les jails (la cohérence des données est pour moi plus importante qu’une toute petite interruption de service), le temps d’arrêt des jails tient simplement au temps d’exécution du script d’arrêt et de démarrage d’ezjail.
  • L’envoi des données modifiées depuis la dernière sauvegarde vers un fichier ou vers un serveur est vraiment très rapide et facile.

Cela donne concrètement la séquence suivante :

ezjail-admin stop
zfs snapshot -r prison/jails@2012.MM.J1
ezjail-admin start

On peut envoyer vers un serveur via ssh un flux complet ou les modifications effectuées depuis la dernière sauvegarde : dans ce dernier cas, l’avantage par rapport aux niveaux de dump des snapshots d’UFS2, c’est que le système signalera toute erreur dans l’ordre des snapshots importés.

zfs send -R prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv prison/jails
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv -F prison/jails

On peut aussi envoyer les données – complètes ou incrémentielles – vers des fichiers de sauvegarde. Vu la rapidité de l’opération, je les compresse systématiquement :

zfs send -R prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1.zfs.gzip
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1-diff-2012.MM.J0.zfs.gzip

Quelques chiffres pour donner une idée des choses, toujours avec des jails d’environ 10Go en tout :

  • 0.013s pour créer le snapshot – à comparer aux 4mn sous UFS2
  • 20mn pour créer un fichier de sauvegarde complète sans compression – à comparer à 1h30 sous UFS2
  • 40mn pour créer le même fichier compressé en gzip
  • 5 à 8 mn pour une sauvegarde incrémentielle d’environ 450Mo, que ce soit vers un serveur ou vers un fichier

Par sa souplesse et sa rapidité, ZFS est donc remarquablement bien adapté à la sauvegarde et au transfert des jails et permet d’optimiser encore ce qui marchait déjà bien sous UFS2.

links

social