Cloner un système en production🔗

Posted by Médéric Ribreux 🗓 In blog/ Sysadmin/

#sysadmin #debian

Introduction

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

Dans cet article, je parlerai bien sûr de ce que je connais bien: les systèmes GNU/Linux, les autres ne m'intéressent 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 tous 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:

Faisons un peu le tour de la technique:

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:

Maintenant, passons à la machine de test Cible:

Les configurations sont bien différentes, le matériel aussi. Comme le noyau utilisé par Debian est assez générique, 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

 
aptitude install rsync

Sur le serveur Cible:

 
dhclient eth0

mkfs.ext3 /dev/hda1
mkdir /mnt/target
mount /dev/sda1 /mnt/target

rsync -Sa --numeric-ids --exclude=/proc --exclude=/sys -e 'ssh -c blowfish -l root' Source:/ /mnt/target/

mkdir /mnt/target/sys; mkdir /mnt/target/proc

grub-install -root-directory=/mnt/target /dev/sda

(ce n'est pas 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 cambouis).

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