Migrieren Sie das Raw-Disk-Image über das LAN

Hier ist meine Situation:

• Zwei dedizierte Server im selben Rechenzentrum mit Gigabit-Ethernet dazwischen.
• Beide dedizierten Server wurden in einer auf Debian Squeeze basierenden Rettungsumgebung mit zusätzlichen Tools und Dienstprogrammen gestartet. Außerdem viel tmp-Speicherplatz (32 GB RAM auf beiden Boxen) zum Herunterladen von Software, Installieren von Paketen und / oder Kompilieren nach Bedarf.
• Beide dedizierten Server verfügen über ca. 3 TB nutzbaren Speicherplatz.
• Der "Quell" -Server verfügt über 4 x 1,5 TB Festplatten in Hardware RAID-10 mit einem Adaptec 4-Port-Controller.
• Der "Ziel" -Server verfügt über 2 x 3 TB Festplatten in Hardware RAID-1 mit einem Adaptec 2-Port-Controller - dieselbe Generation wie der andere, jedoch unterschiedliche Anzahl von Ports.
• Die Anzahl der verwendbaren Blöcke /dev/sdaunterscheidet sich um weniger als 10 MB, aber das Array des Zielservers ist aus irgendeinem Grund einige Megabyte kleiner.
• Beide RAID-Arrays sind so konfiguriert, dass sie die gesamte Festplattenoberfläche aller einzelnen Festplatten verwenden, um ein einziges RAID-Volume zu erstellen.
• Das Betriebssystem startet im MBR-Modus. Es wird kein UEFI-Boot verwendet.

Was ich machen will; was ich vorhabe zu tun:

• Kopieren Sie auf Blockebene das gesamte Betriebssystem-Image (dieses besteht nur aus dem GRUB2-Bootloader in der GPT-Partitionstabelle, / boot partition und / partition) vom "Quell" -Server auf den "Ziel" -Server.
• Wenn möglich , sollte die Kopie "live" erfolgen: Dies bedeutet, dass ich nicht genügend Speicherplatz habe, um eine ordnungsgemäße Datei des Disk-Images auf der Zielseite zu speichern, es sei denn, ich entpacke das Disk-Image als Kopie auf die Festplatte findet statt . Die Gigabit-Ethernet-Verbindung zwischen den Servern ist zuverlässig genug, damit ich damit vertraut bin, und ich werde natürlich fsckan beiden Enden (Quelle und Ziel) ausgeführt, um zu überprüfen, ob das Dateisystem vor und nach der Übertragung in Ordnung ist.
• Übertragen Sie nach Möglichkeit keine Blöcke über das Netzwerk, die nicht von den einzelnen Dateisystemen in jeder Partition verwendet werden (alle Partitionen sind als ext4 formatiert). Dies liegt daran, dass mehr als 50% der "Quell" -Diskette freien Speicherplatz in der /Partition haben.
• Passen Sie die Größe der /Partition so an, dass beim Kopieren die Größe so geändert wird, dass sie in die gerade noch kleinere Größe der Zielfestplatte passt.
• Stellen Sie nach erfolgreichem Kopieren jedes Volume bereit und korrigieren Sie Verweise auf statische IPs, um die IPs des neuen Servers wiederzugeben. (Kann das ohne weitere Hilfe ganz gut machen)

Meine Fragen:

• Sollte ich zuerst die Differenz (in Bytes) zwischen der Größe /dev/sdajedes Servers berechnen und dann verwenden e2resize, um die Größe der /Partition auf der Quellseite zerstörungsfrei zu reduzieren , damit sie in den Bereich der Zielseite passt?
• Sollte ich ddauf dem Raw-Block-Gerät /dev/sdavon der Quelle bis zum Ziel (über ssh) ausgeführt werden oder sollte ich ein gleichwertiges Partitionslayout auf dem Ziel erstellen und ddauf jeder Partition ausführen ? Beachten Sie, dass beim gleichzeitigen Behandeln einer Partition das Problem des Bootloaders auftritt. Wenn ich jedoch keine Partition gleichzeitig ausführe, muss ich ddwissen, dass die Datenübertragung beendet werden muss, sobald so viele Bytes geschrieben wurden, wie das Ziel aufnehmen kann (wodurch hoffentlich das Ende der /Partition im letzten Block "geschlossen" wird , was logischerweise "rechts von" allen anderen Partitionen im Partitionslayout der Quelle liegt).

Ein paar verschiedene. Besonderheiten:

• Das Host-Betriebssystem auf der Quellbox ist Ubuntu Server 12.04, auf dem mehrere OpenVZ-Gäste ausgeführt werden
• Da beide Boxen zur Rettung gestartet werden, ist ein direkter Festplattenzugriff möglich, ohne dass das laufende Betriebssystem Änderungen an den zugrunde liegenden Daten erwartet.

Das ist chaotisch, aber machbar.

Ich nehme an, hier /ist das an /dev/sda3und das /bootist an /dev/sda1.

1. Verkleinern Sie das Dateisystem auf dem alten Server auf die minimal mögliche Größe.

   oldserver # resize2fs -M /dev/sda3
   

2. Partitionieren Sie die Festplatte des neuen Servers mit einer identischen Größe /boot, einem Swapspace und einer neuen /Partition (und allem, was Sie sonst noch benötigen).

   newserver # parted /dev/sda
   

3. Kopieren Sie das /und /bootDateisystem.

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

   Da die Partition auf dem neuen Server etwas kleiner ist als die auf dem alten Server, erhalten Sie No space left on deviceam Ende eine falsche Nachricht. Da Sie das Dateisystem jedoch in Schritt 1 verkleinert haben, spielt dies keine Rolle.

4. Ändern Sie die Größe des Dateisystems auf dem neuen Server auf die Größe der Partition.

   newserver # resize2fs /dev/sda3
   

5. Installieren Sie GRUB auf der neuen Festplatte.

   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. Beenden Sie den Rest Ihrer Reparaturen (IP-Adresse usw.).

Sie können wahrscheinlich einen Weg finden, um das Kopieren des freien Speicherplatzes der Partition zu vermeiden, aber es wird wahrscheinlich länger dauern, bis Sie recherchiert haben, als nur alles zu kopieren ...

Ich würde mkfsneue Dateisysteme auf dem neuen Server haben, dann rsyncsie vom alten Server. Das ist neu startbar, konsistent und jede Datei kann leicht einzeln überprüft werden. Wenn Sie nicht verwendete Abschnitte des Dateisystems verwerfen (keine forensische Kopie), sehe ich keinen Grund, diese Methode nicht zu verwenden. Sie müssten GRUB erneut ausführen, aber das sollte keine Herausforderung sein.

Es würde eine Weile dauern, eine rohe Kopie zu erklären, die für das Dateisystem geeignet ist. Wenn Sie also nicht kommentieren, warum meine rsync-Lösung nicht funktioniert, erspare ich mir die Eingabe.

Wenn Sie WIRKLICH Daten auf Blockgeräteebene übertragen möchten, kann ich mir einen ziemlich nützlichen Trick vorstellen, mit dem ich Server mit minimalen Ausfallzeiten migriert habe.

Die Sache ist, Sie können einen verschlechterten Spiegel auf dem Quellserver erstellen, wobei Ihre Datenpartition die einzige aktive Hälfte des Spiegels ist, und dann die Zielpartition vom zweiten Server über AOE exportieren (ich nehme an, beide Server befinden sich in derselben Broadcast-Domäne). Auf dem Quellserver verbinden Sie dann das Netzwerkblockgerät mit Ihrem verschlechterten Spiegel, damit es neu erstellt wird. Warten Sie, bis die Wiederherstellung abgeschlossen ist, stoppen Sie den Spiegel, entfernen Sie das exportierte AOE-Gerät und Sie sind in Ordnung.

Ein bisschen mehr Details folgen (ich werde versuchen, es kurz zu halten).

Komponenten:

• mdadmmit seinem Erstellungsmodus (Ad-hoc-Spiegel ohne Metadaten);
• vblade zum Exportieren eines Blockgeräts als AOE-Netzwerkgerät;
• aoe-tools zum Importieren eines AOE-Netzwerkblockgeräts.

Sie müssen eine Partitionstabelle auf Ihrem Zielserver erstellen und dann die Quellpartition verkleinern, damit sie zum Ziel passt. Sie können GRUB einfach auf Ihrem neuen MBR installieren. Das Synchronisieren nur von Partitionen über eine neu erstellte Partitionstabelle ist etwas weniger fehleranfällig.

Auf der Empfangsseite müssen Sie Ihre Partition mit dem vbladeTool exportieren. Auf dem Quellserver können Sie nach der Installation exportierte Geräte sehen aoe-tools(ausführen und aoe-discoverdann nach /dev/ether/Geräten suchen ).

Dann sollten Sie das raid1-Gerät auf dem Quellserver mit Ihrem Quelllaufwerk erstellen :

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

Danach können Sie den neu gebauten Spiegel untersuchen:

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

Zu diesem Zeitpunkt können Sie die exportierte Zielpartition sicher an diesen Spiegel anhängen:

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

Dann beobachten Sie einfach den Fortschritt der Synchronisation:

watch -n5 cat /proc/mdstat

Stoppen Sie nach Abschluss der Synchronisierung einfach den Spiegel: mdadm --stop /dev/md0Beenden Sie vbladeauf dem Quellserver den Prozess auf dem Zielserver, installieren Sie GRUB auf dem zweiten Server, ändern Sie Ihre IP-Adressen usw.

Mit diesem Trick ist es tatsächlich möglich, den Server fast live zwischen Boxen zu verschieben, mit Ausfallzeiten, nur um synchronisierte Boxen neu zu starten.

Aus Leistungsgründen empfehle ich außerdem, die MTU Ihres Links zu erhöhen (oder wenn möglich ein separates VLAN mit aktivierten Jumbo-Frames einzurichten).

Beachten Sie, dass Sie auch etwas wie nbd-server/ nbd-client(oder sogar iSCSI, wenn Sie es grob wollen) als Alternative zu AOE verwenden können, aber AOE ( vblade+ aoe-tools) hat eine sehr einfache Schnittstelle und eine großartige Leistung (kein TCP / IP-Overhead).