Migrer l'image du disque brut sur le LAN


8

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.

Avez-vous exactement besoin de copier les blocs utilisés à partir des périphériques, ou simplement les systèmes de fichiers OS?
Andrew

Réponses:


6

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 ...


Impressionnant! Je suis d'accord pour copier l'espace libre de la partition, car ces instructions répondent à tous mes autres critères. Bien que, ne serait pas juste redimensionner le système de fichiers et la partition elle - même sur oldserveréliminer le besoin de copier tout l'espace libre? Je m'en fiche /bootparce que c'est si petit, mais pour /au moins, je pourrais faire ça, non? Il suffit de définir le secteur final de la partition pour qu'il soit égal à quel secteur resize2fsdéfinit la fin du secteur FS. Eh bien, secteur, bloc ... probablement bloc . Mais merci pour ça! C'est bien!
allquixotic

Oui, si vous réduisez également la taille de la partition, vous éviterez un tas de copies. Cela pourrait vous faire économiser quelques heures ... Je laisserais un peu de mou, juste au cas où mes calculs seraient légèrement décalés.
Michael Hampton

Cela éliminerait également le faux / effrayant "Aucun espace laissé sur l'appareil", car il va se redimensionner /dev/sda3à environ 1,3 To et le copiera dans une partition sur la destination qui devrait contenir environ 2,9 To.
allquixotic

Ça va prendre du temps . J'ai réalisé que j'avais un port gigabit avec une allocation de 100 Mbit / s. Merde.
allquixotic

5

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.


Je pense que partimagepeut faire des copies brutes qui sont conscientes du système de fichiers, mais cela ne prend pas en charge ext4. Il y a donc cela en option ... rsyncest plus joli en tant qu'option, tant qu'il conserve tous les contrôles d'accès discrétionnaires (à la chmod) et peut copier proprement sur les liens symboliques et les fichiers de l'appareil ...
allquixotic

J'appuie la réponse de Jeff. Vous pouvez transférer la disposition de la partition avec sfdisk -d / dev / sda | destination ssh "sfdisk / dev / sdb". Faites vos systèmes de fichiers et transférez avec 'rsync -a -e "ssh -c arcfour" / mnt / root @ destination: / mnt /'. Après, suivez l'étape 5 de la réponse de Michael Hampton pour rendre la destination amorçable.
Tim Haegele

1

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),


J'ajouterais également que la synchronisation au niveau du périphérique de bloc peut parfois être VRAIMENT plus rapide que de passer d'un fichier à l'autre avec rsync, en particulier lorsque vous avez des millions (littéralement) de fichiers relativement petits sur le système de fichiers.
artyom

mdadm? J'utilise un RAID matériel. Et je n'ai aucune idée de ce qu'est l'AOE, et je n'ai jamais utilisé iSCSI. Je ne pense pas que mes serveurs se trouvent dans le même domaine de diffusion, juste dans le même centre de données. Il y a au moins un ou deux commutateurs entre les serveurs.
allquixotic

Je pense que c'est une excellente idée! Mais comment gère-t-il les différentes tailles de disques?
Tim Haegele

@allquixotic, néanmoins, vous pouvez essayer le schéma suivant en remplaçant AOE par nbd (périphérique de bloc réseau, fourni par nbd-serveret nbd-clientpackages). mdadmest utilisé uniquement pour synchroniser deux périphériques de bloc, aucune métadonnée n'est écrite en buildmode, vous pouvez donc l'utiliser au-dessus de tout périphérique de bloc (il doit d'abord être démonté). Le fait est que j'installe généralement un nouveau système sur un raid mdadm dégradé1 même si j'ai un raid matériel sous-jacent, de cette façon je peux appliquer la technique décrite sans avoir à démonter les partitions, ce qui réduit les temps d'arrêt de la migration à un seul redémarrage.
artyom
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.