Wiederherstellen eines Amazon EBS RAID0-Arrays aus Snapshots, die mit ec2-Consistent-Snapshot erstellt wurden


8

Ich habe einen neuen MySQL-Server unter Amazon EC2 konfiguriert und beschlossen, meine Daten auf einem EBS RAID0-Array zu speichern. So weit so gut, und ich habe getestet, wie man Schnappschüsse dieser Geräte mit ec2-konsistenten Schnappschüssen macht, großartig.

Wie können Sie das Array auf einer neuen Instanz anhand dieser Snapshots schnell neu erstellen?

Wenn Sie einen ec2-konsistenten Snapshot verwenden, um einen Snapshot mehrerer Volumes zu erstellen, können Sie nicht feststellen, welches Volume für jedes Gerät im RAID verwendet wurde. Ich kann mich vielleicht völlig irren, aber da Sie Daten über die Volumes verteilen, liegt es nahe, dass Sie jedes NEUE Volume an derselben Stelle auf dem RAID ablegen müssen wie das Volume, von dem aus der Snapshot erstellt wurde.

Ein Beispiel:

  • 3x200 GB-Volumes in einer RAID0-Konfiguration.
  • vol-1 ist / dev / sdh Gerät 0 im RAID
  • vol-2 ist / dev / sdh1 Gerät 1 im RAID
  • vol-3 ist / dev / sdh2 Gerät 2 im RAID

Sie erstellen einen ec2-Snapshot mit : ec2-consistent-snapshot <options> vol-1 vol-2 vol-3.

Sie haben jetzt 3 Snapshots. Die einzige Möglichkeit, festzustellen, um welches Gerät es sich handelt, besteht darin, die Quell-Volume-ID zu überprüfen, dann zu überprüfen, auf welchem ​​Gerät die Quell-Volume-ID wie auf der Instanz bereitgestellt ist, und dann die Details des RAID zu überprüfen Konfiguration auf der Instanz des Quellvolumes.

Dies ist offensichtlich unglaublich manuell ... und nicht schnell (was es offensichtlich schwierig macht, eine neue MySQL-Instanz schnell aufzurufen, wenn die andere fehlschlägt. Ganz zu schweigen davon, dass Sie die Gerätepositionen zu diesem Zeitpunkt auf dem RAID aufzeichnen müssen von Snapshot, da Sie bei einem Absturz der Quellvolume-Instanz keine Möglichkeit haben, zur RAID-Konfiguration zu gelangen.

Also abschließend:

  • Vermisse ich etwas mit der Funktionsweise von ec2-konsistenten Snapshots und einem Software-RAID0-Array?
  • Wenn nicht, gibt es bekannte Lösungen / Best Practices für das Problem, nicht zu wissen, zu welchem ​​Gerät / welcher Position im RAID-Array ein Snapshot gehört?

Ich hoffe das war klar und danke für deine Hilfe!

Antworten:


5

Da Sie Daten über die Volumes verteilen, liegt es nahe, dass Sie jedes NEUE Volume an derselben Stelle auf dem RAID ablegen müssen wie das Volume, von dem aus der Snapshot erstellt wurde.

Ich habe Ihre Prämisse getestet, und so logisch es auch scheinen mag, die Beobachtung ist anders.

Lassen Sie mich das näher erläutern:
Ich habe genau die gleichen Anforderungen wie Sie. Das von mir verwendete RAID0 hat jedoch nur 2 Volumes.

Ich verwende Ubuntu 10 und habe 2 EBS-Geräte, die ein mit XFS formatiertes RAID0-Gerät bilden.

Das raid0-Gerät wurde mit dem folgenden Befehl erstellt:
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

Ich habe MYSQL und eine Reihe anderer Software installiert, die so konfiguriert sind, dass sie / dev / md0 zum Speichern ihrer Datendateien verwenden.

Verwenden der gleichen Volumes : Sobald dies erledigt ist, stelle ich alles um, stoppe den Raid und setze ihn wie sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg folgt wieder zusammen: Unabhängig von der Reihenfolge /dev/sdg /dev/sghstellt sich das RAID korrekt wieder her.

Verwenden von Snapshots : Veröffentlichen Sie dies, ec2-consistent-snapshotum Snapshots der beiden EBS-Festplatten zusammen zu erstellen. Ich erstelle dann Volumes von dieser Festplatte, hänge sie an eine neue Instanz an (die bereits für die Software konfiguriert wurde), setze das RAID wieder zusammen (ich habe auch versucht, die Reihenfolge der EBS-Volumes zu ändern), mounte es und bin bereit gehen.

Klingt seltsam, funktioniert aber.


Wenn Sie das Array neu erstellen, spielt es im Grunde keine Rolle, in welcher Reihenfolge Sie es überhaupt erstellen. Ich denke, das liegt an den Superblock-Daten, die auf die Festplatten geschrieben wurden, sodass der RAID-Controller weiß, wie er sie wieder zusammensetzt. Das ist fantastisch! Vielen Dank für Ihre Antwort, es ist ziemlich genau das, was ich brauchte!
Jim Rubenstein

4

Ich habe eine ähnliche Konfiguration ausgeführt ( RAID0 über 4 EBS-Volumes ) und hatte daher die gleichen Bedenken, das RAID-Array aus Snapshots wiederherzustellen, die mit ec2-Consistent-Snapshot erstellt wurden .

Glücklicherweise enthält jedes Gerät in einem RAID-Array Metadaten (in einem Superblock), die seine Position im Array, die UUID des Arrays und die Ebene des Arrays (z. B. RAID0) aufzeichnen. Um diesen Superblock auf einem beliebigen Gerät abzufragen, führen Sie den folgenden Befehl aus (die Zeilenübereinstimmung '^ this' beschreibt das abgefragte Gerät):

$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 2ca96b4a:9a1f1fbd:2f3c176d:b2b9da7c
  Creation Time : Mon Mar 28 23:31:41 2011
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Mon Mar 28 23:31:41 2011
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : ed10058a - correct
         Events : 1

     Chunk Size : 256K

      Number   Major   Minor   RaidDevice State
this     0     202       17        0      active sync   /dev/sdb1

   0     0     202       17        0      active sync   /dev/sdb1
   1     1     202       18        1      active sync   /dev/sdb2
   2     2     202       19        2      active sync   /dev/sdb3
   3     3     202       20        3      active sync   /dev/sdb4

Wenn Sie dieselbe Abfrage auf einem Gerät ausführen, das nicht Teil eines Arrays ist, erhalten Sie:

$ sudo mdadm --examine /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

Dies beweist, dass dieser Befehl wirklich auf Informationen basiert, die auf dem Gerät selbst gespeichert sind, und nicht auf einer Konfigurationsdatei.

Man kann auch die Geräte eines RAID-Arrays ausgehend vom RAID-Gerät untersuchen und ähnliche Informationen abrufen:

$ sudo mdadm --detail /dev/md0

Ich verwende das spätere zusammen mit ec2-description-volume , um die Liste der Volumes für ec2-compatible-snaptshot zu erstellen ( -n und --debug ermöglichen es, diesen Befehl zu testen, ohne Snapshots zu erstellen). Der folgende Befehl setzt voraus, dass das Verzeichnis / mysql der Einhängepunkt für das Volume ist und dass die AWS-Region us-west-1 ist :

$ sudo -E ec2-consistent-snapshot --region us-west-1 --mysql --freeze-filesystem /mysql --mysql-master-status-file /mysql/master-info --description "$(date +'%Y/%m/%d %H:%M:%S') - ASR2 RAID0 (4 volumes) Snapshot" --debug -n $(ec2-describe-volumes --region us-west-1 | grep $(wget http://169.254.169.254/latest/meta-data/instance-id -O - -q) | egrep $(sudo mdadm --detail $(awk '{if($2=="/mysql") print $1}' /etc/fstab) | awk '/ \/dev\//{printf "%s ", $7}' | sed -e 's# /#|/#g') | awk '{printf "%s ", $2}')

0

Ich weiß, dass dies Ihre Frage nicht beantwortet, aber ich mache etwas Ähnliches, aber mit dem Basis-Tool ec2-create-snapshot von Amazon und einem Cron-Skript. Es ist nicht so schnell wie ein ec2-konsistenter Snapshot, aber ich bekomme die zusätzliche Kontrolle, die ich brauche: fsync, Schreibvorgänge sperren und vor allem die Snapshots entsprechend benennen, damit sie in der richtigen Reihenfolge wiederhergestellt werden können.


Ich verwende eigentlich XFS, also friere ich das Dateisystem ein, während ich einen Schnappschuss mache. In Kombination mit FLUSH und LOCK in MySQL (ec2-Consistent-Snapshot erledigt dies alles) sollte ich jedes Mal einen konsistenten Snapshot haben. Das Problem ist die Benennung, für die ich gerade eine temporäre Lösung entwickelt habe, indem ich vorerst das Perl-Skript für ec2-konsistente Snapshots geändert habe.
Jim Rubenstein
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.