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

Date: 2012-07-22 20:31
Author: jdn06
Category: Distributions
Tags: FreeBSD, jails, sauvegarde, snapshots, UFS2, ZFS

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/[email protected]
   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/[email protected] | ssh adresse.de.mon.serveur\
   zfs recv prison/jails

   zfs send -Ri prison/[email protected] prison/[email protected] |\
   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/[email protected] | gzip >\
   /media/backup/2012.MM.J1.zfs.gzip

   zfs send -Ri prison/[email protected] prison/[email protected] |\
   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.