Cloner un système en production

Parfois, il arrive que l'on doive cloner un système qui est déjà en production. L'objectif peut être variable:

  • Le désir de sauvegarder à chaud l'intégralité du système.
  • Disposer d'une solution de secours en cas de panne matérielle.
  • Analyser les problèmes de configuration ou de comportement avec une machine de tests.
  • Réaliser des tests d'intégration
  • le fun ...

Dans cet article, je parlerai bien sûr de ce que je connais bien: les systèmes GNU/Linux, les autres ne m'intéréssant pas du tout, pour des raisons de temps, d'argent et d'éthique !

Une méthode simple

La méthode est simple. Elle repose sur un seul programme qui est assez connu: rsync. Ce petit programme est très astucieux et va nous permettre de parvenir à nos fins de manière assez simple. L'impératif est donc de pouvoir installer rsync sur les deux machines. Sans cela point de salut ! Il va nous falloir également un live CD avec rsync dessus pour la machine cible: je pars de l'hypothèse que le clone n'a pas de système d'exploitation (ou bien un qu'on peut supprimer).

De plus, n'oublions pas que nos deux machines peuvent être très différentes matériellement. En règle générale, les serveurs de production contiennent de la donnée (SGBD, fichiers , répertoires web, etc...). Leur capacité disque est donc souvent importante. Pour faire des tests, on n'a pas forcément besoin de récupérer tout ces fichiers et il est fort possible que nous disposions juste d'une vieille machine pour cloner un serveur en production à la pointe du dernier cri (de la mort qui tue).

Pour des raisons de clarté, les deux machines employées seront nommées de la manière suivante:

  • Source: la machine à cloner. Elle peut disposer d'une configuration matérielle très spécifique ainsi que de systèmes de fichiers exotiques.
  • Cible: le clone.

Faisons un peu le tour de la technique:

  • Installer rsync sur les deux machines
  • Lancer le liveCD sur la Cible.
  • Créer des partitions sur la cible, le système de fichiers importe peu pour le système, davantage pour les données (utilisation d'ACL, de quotas, d'attributs spécifiques, etc...).
  • Recopier l'ensemble des fichiers qui nous intéressent sur le serveur Source.
  • Modifier quelques paramètres pour permettre au noyau de la Cible de démarrer.

Rien de bien sorcier sauf la dernière étape qui est fonction de la machine Cible, bien entendu.

Un exemple concret

J'ai dû cloner un système en production sur mon lieu de travail. Le deal était de disposer d'une machine semblable du point de vue logiciel à un serveur bureautique en production que je ne pouvais forcément pas arrêter sous peine de tout casser et d'avoir une centaine de personnes privées de leur moyen de travailler.

Voici à quoi ressemble la bête Source:

  • Dell PowerEdge 800 de quelques années en Intel Xeon 32 bits avec 1,5 Go de RAM
  • Un disque système de 80Go bien partitionné dans la majorité des cas en ReiserFS (cher Hans, c'était avant que ta femme meure !): 8 partitions allant de root en passant par le swap, /var, /opt, /tmp, /usr et /home en une partition pour le cas où !
  • Un disque de data composé matériellement d'un RAID 5 sur 4 disques de 80Go en SATA, partitionné avec du LVM2 sur lequel vient se mettre une couche DRBD (pour la synchronisation sur une machine de spare) et enfin trois partitions en système de fichier XFS. L'ensemble pèse 220Go et les partitions sont montées à partir du répertoire /data
  • Les contrôleurs disques sont comme indiqués en SATA.
  • Il existe quelques cartes SCSI pour le lecteur de bandes pour les sauvegardes.
  • La machine est équipée de 2 cartes réseaux (1pour la production, 1 pour le spare réseau).
  • Le tout tourne bien entendu sous Debian GNU/Linux mais en Sarge !
  • Les services apportés par cette machine sont grosso-modo!: samba, openLDAP et CUPS.

Maintenant, passons à la machine de test Cible:

  • Pentium 4 2Ghz avec 512Mo de RAM
  • Un disque de 40Go en IDE
  • Une carte réseau !

Les configurations sont bien différentes, le matériel aussi. Comme le noyau utilisé par Debian est assez génériques, je devrai réussir à récupérer un système à peu près stable et qui peut tourner ! Appliquons la méthode:

Sur le serveur Source

  • Installer rsync: aptitude install rsync

Sur le serveur Cible:

  • Démarrer avec un CD de boot sysrescueCD
  • Paramétrer le réseau: dhclient eth0
  • Lancer fdisk et créer des partitions adaptées (un / sur /dev/sda1 et un swap sur /dev/sda2)
  • Créer un système de fichier extended3 sur la partition root: mkfs.ext3 /dev/hda1
  • mkdir /mnt/target
  • monter la partition root cible: mount /dev/sda1 /mnt/target
  • lancer la commande rsync: rsync -Sa --numeric-ids --exclude=/proc --exclude=/sys -e 'ssh -c blowfish -l root' Source:/ /mnt/target/
  • créer les répertoires /sys et /proc: mkdir /mnt/target/sys; mkdir /mnt/target/proc
  • Modifier le fichier /etc/fstab en fonction des éléments du nouveau serveur (/dev/hda1 est root)
  • Modifier le fichier de grub: /mnt/target/boot/grub/menu.lst et mettre la variable root à /dev/hda1.
  • Lancer grub-install pour installer le bootloader sur le disque dur: grub-install -root-directory=/mnt/target /dev/sda (ce n'est pas le le bootloader de la Debian Sarge mais bien celui de sysrescuecd ce qui ne nous gène pas).
  • Rebooter la machine

Quelques explications

SysRescueCD tourne avec un noyau 2.6.25 alors que Sarge est en 2.6.8 ! C'est là qu'on voit qu'il y a eu beaucoup d'évolutions dans le kernel en 3 ans: le pilote IDE est différent: les périphériques en /dev/sd sous le 2.6.25 sont encore reconnus comme des /dev/hd sous le 2.6.8. Rien que ça à gérer, c'est énorme surtout pour le processus de boot ! Sous le 2.6.8, l'image initrd est encore en CramFs alors que sous le 2.6.25, elle est en initramfs.

Tout cela nous oblige à effectuer quelques modifications (le fstab, la config de Grub). Toutefois, cela ne suffit pas ! Un système ainsi configuré ne peut pas booter..., le noyau se lance correctement mais init ne peut pas monter la racine. Pour régler le problème, l'astuce consiste à modifier l'image initrd du noyau de la machine clonée (là, on met vraiment les mains dans le camboui).

  • La manipulation suivante se fera sur une debian Etch ou Lenny ( la machine Cible ne fonctionne pas encore !).
  • Récupérer l'image initrd à modifier (celle du serveur Source ).
  • Sur une station de travail, récupérer les cramfsprogs: aptitude install cramfsprogs
  • Décompresser l'image avec la commande: cramfsck ./initrd.img -x répertoire_temporaire
  • Modifier le fichier ./répertoire_temporaire/script (contient root=/sda1, le changer en root=/dev/hda1).
  • Reconstruire l'image initrd: mkcramfs ./repertoire_temporaire/ ./initrd_mod.img
  • Mettre l'image initrd modifiée sur la machine Cible (avec SysRescueCD par exemple)
  • Rebooter: ça marche !

Conclusion

On a bien vu que le clonage d'une machine en production est assez facile avec cette méthode. On récupère tout, y compris les périphériques /dev. Rsync est assez intéressant de ce point de vue car la "perturbation" de la machine de production est assez faible :installation d'un seul paquet, un peu de bande passante pour faire passer les fichiers.

La méthode permet de s'affranchir des partitions (passage de 8 partitions à 2) ainsi que des systèmes de fichiers: le sysfs du système Source était en ReiserFS et notre système Cible était en ext3.

Ce qui reste complexe à gérer, c'est la différence de comportement du noyau sur la machine Cible avec tout ce que cela peut engendrer.

Références