Migrer l'image du disque brut sur le LAN

Voici ma situation:

• Deux serveurs dédiés dans le même centre de données avec Ethernet gigabit entre eux.
• Les deux serveurs dédiés ont démarré dans un environnement de secours basé sur Debian Squeeze avec des outils et des utilitaires supplémentaires ajoutés. Aussi beaucoup d'espace tmp (32 Go de RAM sur les deux boîtiers) pour télécharger des logiciels, installer des packages et / ou compiler au besoin.
• Les deux serveurs dédiés ont environ 3 To d'espace utilisable.
• Le serveur "source" dispose de 4 disques de 1,5 To en matériel RAID-10 avec un contrôleur de port Adaptec 4.
• Le serveur «de destination» dispose de 2 disques de 3 To en matériel RAID-1 avec un contrôleur de port Adaptec 2 - même génération que l'autre, mais nombre de ports différent.
• Le nombre de blocs utilisables sur /dev/sdadiffère de moins de 10 Mo, mais la baie du serveur de destination est pour une raison quelconque de quelques mégaoctets plus petite.
• Les deux matrices RAID sont configurées pour utiliser toute la surface du disque de tous les disques constitutifs pour créer un seul volume RAID.
• Le système d'exploitation démarre en mode MBR; aucun démarrage UEFI n'est utilisé.

Ce que je veux faire:

• Copiez, au niveau de la couche de bloc, la totalité de l'image du système d'exploitation (il ne s'agit que du chargeur de démarrage GRUB2 dans la table de partition GPT, la partition / boot et / partition) du serveur "source" vers le serveur "destination".
• Si possible , la copie doit avoir lieu "en direct": cela signifie que je n'ai pas assez d'espace pour stocker un fichier approprié de l'image disque du côté destination, à moins que je ne déballe l'image disque sur le disque dur en tant que copie. a lieu . La connexion Ethernet gigabit entre les serveurs est suffisamment fiable pour que je sois à l'aise avec cela, et je vais bien sûr courir fsckaux deux extrémités (source et destination) pour vérifier que le système de fichiers est OK avant et après le transfert.
• Si possible , ne transférez pas de blocs sur le réseau, qui ne sont pas utilisés par les systèmes de fichiers constitutifs de chaque partition (toutes les partitions sont formatées en ext4). En effet, plus de 50% du disque "source" est de l'espace libre dans la /partition.
• Ajustez la taille de la /partition de sorte que lorsqu'elle est copiée, elle soit redimensionnée pour s'adapter à la taille à peine plus petite du disque de destination.
• Une fois la copie réussie, montez chaque volume et corrigez les références aux adresses IP statiques pour refléter les adresses IP du nouveau serveur. (Peut le faire très bien sans autre aide)

Mes questions:

• Dois-je d' abord calculer la différence (en octets) entre la taille de /dev/sdasur chaque serveur, puis l'utiliser e2resizepour réduire de façon non destructive la taille de la /partition côté source afin qu'elle tienne dans l'espace du côté destination?
• Dois-je exécuter ddsur le périphérique de bloc brut, /dev/sdade la source à la destination (sur ssh), ou dois-je créer une disposition de partition équivalente sur la destination et l'exécuter ddsur chaque partition ? Notez que la gestion d'une partition à la fois me laisse le problème du chargeur de démarrage, mais si je ne le fais pas une partition à la fois, il ddfaut savoir arrêter de transférer les données une fois qu'il a écrit autant d'octets que la destination peut contenir (qui, espérons-le, "fermera" la toute fin de la /partition sur le dernier bloc, qui est logiquement "à droite de" toutes les autres partitions dans la disposition des partitions de la source).

Quelques misc. détails:

• Le système d'exploitation hôte sur la boîte source est Ubuntu Server 12.04 exécutant plusieurs invités OpenVZ
• Étant donné que les deux boîtiers sont démarrés en mode de secours, l'accès direct au disque est possible sans attendre de modification des données sous-jacentes par le système d'exploitation en cours d'exécution.

C'est désordonné, mais faisable.

Je suppose que /c'est le cas /dev/sda3et que /bootc'est le cas /dev/sda1.

1. Réduisez le système de fichiers sur l'ancien serveur à sa taille minimale possible.

   oldserver # resize2fs -M /dev/sda3
   

2. Partitionnez le disque du nouveau serveur avec un /bootespace d'échange de taille identique et une nouvelle /partition (et tout ce dont vous avez besoin).

   newserver # parted /dev/sda
   

3. Copiez les systèmes de fichiers /et /boot.

   oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
   oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
   

   Parce que la partition sur le nouveau serveur sera légèrement plus petite que celle sur l'ancien serveur, vous recevrez un faux No space left on devicemessage à la fin de cela. Cependant, puisque vous avez réduit le système de fichiers à l'étape 1, cela n'a pas d'importance.

4. Redimensionnez le système de fichiers sur le nouveau serveur à la taille de la partition.

   newserver # resize2fs /dev/sda3
   

5. Installez GRUB sur le nouveau disque.

   newserver # mount /dev/sda3 /mnt
   newserver # mount /dev/sda1 /mnt/boot
   newserver # mount -o bind /dev /mnt/dev
   newserver # mount -o proc proc /mnt/proc
   newserver # chroot /mnt /bin/bash
   
   newserver(chroot) # grub-install /dev/sda
   newserver(chroot) # exit
   

6. Terminez le reste de vos corrections (adresse IP, etc.).

Vous pouvez probablement trouver un moyen d'éviter de copier l'espace libre de la partition, mais cela vous prendra probablement plus de temps à rechercher qu'à simplement tout copier ...

J'aurais mkfsdes systèmes de fichiers frais sur le nouveau serveur, puis rsyncceux de l'ancien serveur. Cela peut être redémarré, cohérent et chaque fichier est facilement vérifiable individuellement. Lorsque vous jetez des sections inutilisées du système de fichiers (pas une copie médico-légale), je ne vois aucune raison de ne pas utiliser cette méthode. Il faudrait relancer GRUB, mais cela ne devrait pas être un défi.

Expliquer une copie brute qui est consciente du système de fichiers me prendrait du temps, donc à moins que vous ne commentiez pourquoi ma solution rsync ne fonctionne pas, je m'épargnerai la saisie.

Si vous voulez VRAIMENT transférer des données au niveau d'un périphérique de bloc, je peux penser à une astuce assez utile que j'utilisais pour migrer des serveurs avec un temps d'arrêt minimal impliqué.

Le fait est que vous pouvez créer un miroir dégradé sur le serveur source avec votre partition de données étant la seule moitié active du miroir, puis exporter la partition de destination du deuxième serveur via AOE (je suppose que vos deux serveurs sont dans le même domaine de diffusion). Sur le serveur source, vous connectez ensuite le périphérique de blocage de réseau à votre miroir dégradé pour qu'il commence la reconstruction. Attendez que la reconstruction soit terminée, arrêtez votre miroir, supprimez le périphérique exporté AOE et vous êtes OK.

Un peu plus de détails suivent (je vais essayer d'être bref).

Composants:

• mdadmavec son mode de construction (miroir ad-hoc sans métadonnées);
• vblade pour exporter le périphérique de bloc en tant que périphérique réseau AOE;
• aoe-tools pour importer un périphérique de bloc réseau AOE.

Vous devez créer une table de partition sur votre serveur de destination, puis réduire la partition source pour qu'elle corresponde à la destination. Vous pouvez facilement installer GRUB sur votre nouveau MBR; synchroniser uniquement les partitions sur la table de partition nouvellement créée est un peu moins sujet aux erreurs.

Du côté de la réception, vous devez exporter votre partition avec l' vbladeoutil, sur le serveur source, vous pouvez voir les périphériques exportés après l'installation aoe-tools(exécutez aoe-discoverpuis recherchez les /dev/ether/périphériques).

Ensuite, vous devez créer un périphérique raid1 sur le serveur source avec votre lecteur source :

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

Après cela, vous pouvez examiner le nouveau miroir:

mdadm --detail /dev/md0
cat /proc/mdstat

À ce stade, vous pouvez attacher en toute sécurité la partition de destination exportée à ce miroir:

mdadm /dev/md0 --add /dev/ether/eX.Y

Ensuite, surveillez simplement la progression de la synchronisation:

watch -n5 cat /proc/mdstat

Une fois la synchronisation terminée, arrêtez simplement le miroir: mdadm --stop /dev/md0sur le serveur source, terminez le vbladeprocessus sur le serveur de destination, installez GRUB sur le deuxième serveur, modifiez vos adresses IP, etc.

En fait, avec cette astuce, il est possible de déplacer le serveur entre des boîtes presque en direct, avec un temps d'arrêt uniquement pour redémarrer les boîtes synchronisées.

Pour des raisons de performances, je vous suggère également d'augmenter le MTU de votre lien (ou de configurer un VLAN séparé avec des trames jumbo activées, si possible).

Remarque, vous pouvez également utiliser quelque chose comme nbd-server/ nbd-client(ou même iSCSI, si vous le souhaitez) comme alternative à AOE, mais AOE ( vblade+ aoe-tools) a une interface très simple et de grandes performances (pas de surcharge TCP / IP),