Amazon EC2-Sicherungsstrategie mit Einschränkungen (es können nur wenige bis keine Schnappschüsse erstellt werden?)

Ähnliche Fragen wurden gestellt, aber ich muss wissen, was unter den gegebenen Umständen empfohlen wird, um zu wissen, ob mir etwas in meinem Verständnis der Verwendung von EC2 fehlt.

Ein kleines Startup betreibt sein Geschäft im EC2-Netzwerk und hat mich um Rat zu Sicherungsoptionen gebeten. Sie finanzieren sich derzeit selbst und tun alles, um Kosten zu sparen, wenn dies machbar ist. Ohne zu sehr auf die Konfiguration ihrer Systeme einzugehen, werde ich einen Webserver als Beispiel geben. Es ist ein einfacher Webserver mit einer Datenbank. Das Problem ist, dass sie nicht wollen, dass der Server heruntergefahren wird.

Die Person, die das Setup durchgeführt hat, ist der Ansicht, dass sie entweder nur regelmäßige Speicherauszüge der Datenbank erstellen und diese in S3 speichern oder Skripts erstellen sollte, die einen neuen Server bei Amazon neu erstellen, wenn sie benötigt werden, indem sie ausgewählte Ordner mit Konfigurationsinformationen sichern . Er schlug vor, dass das Erstellen von Snapshots des Servers verschwenderisch wäre, da sie viel Speicherplatz beanspruchen und im Wesentlichen Daten zwischen großen Datenabbildern verrotten würden, sodass der Snapshot schnell veraltet wäre.

Mein Gedanke war, einen Schnappschuss der VM zu machen und dann regelmäßige Speicherauszüge der Datenbank zu erstellen und in S3 zu speichern. Wenn sie die EC2-Instanz verlieren oder durch ein Update unbrauchbar werden, können sie den Snapshot verwenden, um den Server mit dem neuesten Datenbank-Dump relativ schnell wieder aufzubauen, anstatt von vorne zu beginnen und eine neue Instanz vollständig zu erstellen neuer AMI.

Meines Wissens nach erfordert die Erstellung eines Snapshots einer EC2-Instanz (oder eines EBS-Speichers) Ausfallzeiten, was sie nur zögerlich haben. Ich habe auch gelesen, dass Sie den Server herunterfahren sollten, um das Dateisystem beim Erstellen des Snapshots konsistent zu halten. Da sich hinter einem Balancer noch kein Cluster befindet, schränken diese die Optionen für Snapshots ein.

Das Erstellen von Skripten zum Erstellen von Servern erfordert das Erstellen eines Chef- oder Puppet-Servers, der neue Server mit den zugehörigen Rollen auf EC2 bereitstellen kann, sofern Amazon nicht etwas Besonderes kennt. Im Moment hat das Startup keine Mittel, um diese Art von Server in den Startlöchern zu halten, und im Moment müssen sie nicht wirklich so viele Server bereitstellen.

Im Idealfall verfügen sie über die Mittel, um eine Reihe von Servern hinter einem virtuellen Balancer oder dem Balancer-Service von Amazon zu erstellen und die Server dann einzeln herunterzufahren, um Updates oder Snapshots durchzuführen. Im Moment wäre ich nervös bei der Idee, Updates durchzuführen, denn wenn Sie Speicherauszüge der Datenbank erstellen, hilft dies nicht, wenn ein Systemupdate eine Bibliothek ändert, auf die sich ihre Anwendung stützt, und der Dienst ausfällt.

Ich nahm auch an, dass eine andere Option darin besteht, ein Skript auszuführen, das ein EBS-Volume erstellt, es bereitstellt und auf dem Server so etwas wie rsync ausführt, um die meisten Dateisysteminformationen auf dem EBS-Volume zu erfassen. Anschließend wird der Inhalt komprimiert und in S3 kopiert und das Volume getrennt und zerstören Sie es, um Speicherkosten zu sparen, und führen Sie dann einen Datenbank-Dump durch, um Daten während des Flugs abzufangen, die sonst inkonsistent wären. Für einige ihrer Server wird es höchstwahrscheinlich erforderlich sein, auf temporären EBS-Volumes zu speichern, wenn der Datenbankbedarf steigt.

Eine VMWare-Sandbox wird erstellt, um ihre Netzwerksysteme in einer Umgebung neu zu erstellen, in der Aktualisierungen vorab getestet werden können, bevor sie auf die Produktionssysteme bei Amazon angewendet werden. Ich hoffe, dass dies die Möglichkeit minimieren würde, dass ein Systemupdate ihre Anwendung beendet.

Angesichts der Einschränkungen beim Ausführen eines Servers mit Datenbank- und Anwendungsserver auf dem System, bei dem möglichst wenig Ausfallzeiten angestrebt werden (Einschränkung der Verwendung von Snapshots und möglichst "heißer" Sicherungsprozess (). Live erstellt, ohne den Server herunterzufahren), bin ich auf dem falschen Weg, einen Zeitplan für die Erstellung eines Snapshots der EC2-Instanz in ihrem Arbeitszustand vorzuschlagen und von dort aus Datenbank-Dumps zum Kopieren nach S3 durchzuführen? Gibt es eine bessere Strategie, die verfolgt werden kann? Wenn Snapshots beim Erstellen einer Live-Sicherung eines Servers Ausfallzeiten verursachen?

Diese Frage hat etwas Interessantes - insbesondere im Hinblick auf die Idee von Ausfallzeiten. Ein Teil der Idee ist, dass, wenn eine Anwendung empfindlich auf Ausfallzeiten reagiert, auch die Wiederherstellungszeit berücksichtigt werden muss. (Als extremes Argument erfordern keine Sicherungen keine Ausfallzeiten, es sei denn, Sie benötigen diese Sicherungen. In diesem Fall kann die Ausfallzeit gegen unendlich gehen ).

Ein bisschen über EBS

EBS-Volumes und Snapshots werden auf Blockebene ausgeführt. Infolgedessen können Snapshots erstellt werden, während eine Instanz ausgeführt wird, selbst wenn das EBS-Volume verwendet wird. Der Snapshot enthält jedoch nur Daten, die sich tatsächlich auf der Festplatte befinden (dh nicht in einem Dateicache). Aus letzterem Grund entsteht die Idee konsistenter Schnappschüsse.

• Die empfohlene Methode besteht darin, das Volume abzunehmen, einen Schnappschuss zu erstellen und es erneut anzuschließen - normalerweise nicht praktikabel.
• Die nächstbeste Option besteht darin, die Schreibcaches auf die Festplatte zu leeren, das Dateisystem einzufrieren und Ihren Snapshot zu erstellen

Ein interessanter Punkt hierbei ist, dass Sie in beiden oben genannten Fällen nicht warten müssen, bis der Snapshot fertig ist, um ihn wieder anzuhängen / freizugeben und das Schreiben auf die Festplatte fortzusetzen. Sobald der Snapshot initiiert wurde, sind Ihre Daten bis zu diesem Zeitpunkt konsistent. In der Regel dauert dies nur einige Sekunden, in denen Ihre Festplatte schreibgeschützt ist. Da die meisten Datenbanken ihre Dateien auf der Festplatte in angemessener Weise strukturieren - es besteht eine gute Chance, dass Einfügungen die vorhandenen Blöcke nur minimal beeinflussen -, wodurch die dem Snapshot hinzugefügten Daten minimiert werden.

Betrachten Sie den Punkt der Sicherung

EBS-Volumes werden bereits innerhalb einer Verfügbarkeitszone repliziert. Daher ist ein gewisser Grad an Redundanz integriert. Wenn Ihre Instanz beendet wird, können Sie das EBS-Volume einfach an eine neue Instanz anhängen und (nachdem Sie die mangelnde Konsistenz überwunden haben) dort weitermachen, wo Sie sich befinden aufgehört. In vielerlei Hinsicht ähnelt das EBS-Volume einem inkonsistenten Snapshot, sofern Sie darauf zugreifen können. Die meisten EC2-Benutzer erinnern sich jedoch wahrscheinlich an die kaskadierenden Ausfälle von EBS-Volumes von Anfang 2011 - auf Volumes war mehrere Tage lang nicht zugegriffen, und einige Benutzer verloren auch Daten.

RAID1

Wenn Sie versuchen, sich vor dem Ausfall einer EBS-Festplatte zu schützen (dies geschieht), können Sie ein RAID1-Setup in Betracht ziehen. Da es sich bei EBS-Volumes um Blockgeräte handelt, können Sie sie mit mdadm problemlos in der gewünschten Konfiguration einrichten. Wenn eines Ihrer EBS-Volumes nicht den Spezifikationen entspricht, ist es einfach genug, es manuell zu versagen (und es später durch ein anderes EBS-Volume zu ersetzen). Dies hat natürlich Nachteile - längere Zeit für jeden Schreibvorgang, größere Anfälligkeit für variable Leistung, doppelte E / A-Kosten (monetär, nicht leistungsmäßig), kein wirklicher Schutz vor einem weiter verbreiteten AWS-Fehler (ein häufiges Problem im letzten Jahr) die Unfähigkeit, EBS-Volumes zu trennen, die sich in einem gesperrten Zustand befanden) und natürlich der inkonsistente Zustand der Festplatte bei einem Fehler.

S3FS

Eine Option für bestimmte Anwendungen (definitiv NICHT für Datenbanken) besteht darin, S3 als lokales Dateisystem bereitzustellen (z. B. über s3fs). Dies ist langsam, es fehlen einige der Funktionen, die man von einem Dateisystem erwarten würde, und es verhält sich möglicherweise nicht wie erwartet (eventuelle Konsistenz). Für einen einfachen Zweck wie das Bereitstellen hochgeladener Dateien über Instanzen hinweg kann dies jedoch sinnvoll sein. Offensichtlich ist es nichts, was eine gute Lese- / Schreibleistung erfordert.

MySQL bin-log

Eine weitere für MySQL spezifische Option kann die Verwendung des bin-log sein. Sie können ein zweites EBS-Volume einrichten, in dem Ihr Bin-Protokoll gespeichert wird (um die Auswirkung der hinzugefügten Schreibvorgänge auf Ihre Datenbank zu minimieren), und dieses in Verbindung mit den von Ihnen verwendeten Datenbank-Dumps verwenden. Möglicherweise können Sie dies sogar mit s3fs tun, was tatsächlich von Nutzen sein kann, wenn die Leistung tolerierbar ist (ein rsync wäre jedoch wahrscheinlich besser als der Versuch, s3fs direkt zu verwenden, und Sie möchten auf jeden Fall komprimieren, was Sie können).

Wir kommen jedoch noch einmal auf die Idee des Zwecks zurück. Überlegen Sie, was mit den obigen Vorschlägen passieren würde:

• EBS-Volumes nicht zugänglich:
  • RAID1 - nutzlos, da Sie nicht an die Daten gelangen können
  • bin-log - nutzlos, es sei denn, Sie haben es nach S3 exportiert - wahrscheinlich eine Verzögerung, wenn Sie das getan haben
• Instanz wird unerwartet beendet:
  • RAID1 - Ihre Festplatten sind verfügbar, aber nicht konsistent. Ihre Datenbank kann sich möglicherweise selbst von der Inkonsistenz erholen
  • bin-log - Ihre Daten sollten zugänglich sein, obwohl Sie möglicherweise die letzten Ereignisse überprüfen müssen
• Jemand führt DROP DATABASE als root aus:
  • RAID1 - Sie haben zwei perfekte Kopien einer nicht vorhandenen Datenbank
  • bin-log - Sie sollten in der Lage sein, die Ereignisse bis kurz vor dem Befehl wiederzugeben, also sollten Sie in Ordnung sein

RAID1 ist also wirklich meistens nutzlos und das Bin-Log dauert zu lange - beide haben unter bestimmten Umständen Vorteile, sind aber weit von der Idee entfernt.

Schnappschüsse

Es ist wichtig zu beachten, dass Snapshots unterschiedlich sind und nur die tatsächlichen Blöcke speichern, die Daten enthalten (und komprimiert sind). Anders als bei einem EBS-Volume, bei dem Sie ein 20-GB-Volume haben, aber nur 1 GB verwenden, wird Ihnen der bereitgestellte Speicher (20 GB) weiterhin in Rechnung gestellt. Bei einem Schnappschuss wird Ihnen nur das berechnet, was Sie verwenden. Wenn sich zwischen den Schnappschüssen keine Daten ändern, fallen (theoretisch) keine Gebühren an. (Schnappschüsse werden für PUTS / GETS und gebrauchten Speicher berechnet).

Abgesehen davon würde ich dringend empfehlen, dass Ihre Anwendungsdaten (einschließlich Datenbanken) nicht auf Ihrem Root-Volume gespeichert werden (das Sie möglicherweise bereits eingerichtet haben). Einer der Vorteile besteht darin, dass Ihr Root-Volume hoffentlich nur ein Minimum an Änderungen aufweist. Dies bedeutet, dass die Snapshots weniger häufig sind (oder nur ein Minimum an Änderungen aufweisen), wodurch Kosten und Benutzerfreundlichkeit reduziert werden.

Es ist auch wichtig zu erwähnen, dass Sie alte Schnappschüsse jederzeit löschen können - obwohl sie unterschiedlich sind, wirken sie sich nicht auf die anderen Schnappschüsse aus. Allerdings wird jeder einem Snapshot zugewiesene Block erst dann freigegeben, wenn kein Snapshot vorhanden ist, der noch auf diesen Block verweist.

Das Problem bei periodischen Dumps ist zum einen die Zeit zwischen den Dumps (möglicherweise mithilfe des Bin-Logs von MySQL behoben) und auch die Schwierigkeit der Wiederherstellung. Es dauert einige Zeit, einen großen Speicherauszug zu importieren und alle Ereignisse aus einem Bin-Protokoll wiederzugeben. Das Erstellen eines Speicherauszugs ist auch nicht ohne Auswirkungen auf die Leistung. Solche Dumps erfordern wahrscheinlich viel mehr Speicher als ein Schnappschuss. Das Einrichten eines EBS-Volumes ausschließlich für die Datenbanken und Snapshots, die in den meisten Fällen vorzuziehen wären (das Erstellen eines Snapshots hat jedoch auch einige Auswirkungen auf die Leistung).

Das Schöne an Snapshots und EBS-Volumes ist, dass sie in anderen Instanzen verwendet werden können. Wenn Ihre Instanz nicht gestartet werden kann, können Sie das Root-Volume an eine andere Instanz anhängen, um das Problem zu diagnostizieren und zu beheben - oder nur um Ihre Daten davon zu kopieren - und das Root-Volume mit nur wenigen Minuten Ausfallzeit wechseln (Instanz stoppen, trennen) das Root-Volume, ein neues Root-Volume anhängen, die Instanz starten). Dieselbe Idee gilt für Ihre Daten auf einem zweiten EBS-Volume. Im Wesentlichen starten Sie einfach eine neue Instanz von Ihrem benutzerdefinierten AMI und hängen Ihr aktuelles EBS-Volume daran an - dies hilft, Ausfallzeiten zu minimieren.

(Man könnte argumentieren (und ich würde es wahrscheinlich nicht empfehlen), dass Sie zwei Kopien von MySQL auf demselben Server (Master-Slave) mit zwei EBS-Volumes einrichten und dann Ihren Slave herunterfahren könnten, um einen Snapshot davon zu erstellen EBS-Volumen - es wird konsistent sein, ohne Ausfallzeiten - aber die Leistungskosten sind es wahrscheinlich nicht wert).

AWS verfügt über eine automatische Skalierung, mit der eine konstante Anzahl von Instanzen verwaltet werden kann (selbst wenn diese Anzahl 1 ist). Sie würden sie jedoch von einem Snapshot aus bereitstellen. Wenn Ihr Snapshot also nicht nützlich ist, ist die Prämisse nicht von großem Nutzen .

Noch ein paar Punkte: Sie können so viele Instanzen aus einem einzelnen Snapshot bereitstellen, wie Sie möchten (im Gegensatz zu einem EBS-Volume, das jeweils nur an eine einzelne Instanz angehängt werden kann). Außerdem können EBS-Volumes nur innerhalb einer Verfügbarkeitszone verwendet werden, während Snapshots innerhalb einer Region verwendet werden können.

Im Idealfall können Sie bei einem Snapshot, wenn Ihr Server ausfällt, einfach einen neuen mit dem letzten Snapshot starten. Insbesondere wenn Sie Ihr Root-Volume von Ihren Daten trennen, sollte ein fehlerhaftes Update zu einem Minimum an Ausfallzeiten führen (da Sie dies nur tun würden) Übertragen Sie das EBS-Volume, das Ihre Daten enthält, und machen Sie einen Schnappschuss davon, um alles zu erhalten, was aufgrund von Inkonsistenzen beschädigt werden könnte.

Nebenbei bemerkt, Amazon gibt an, dass die Ausfallrate von EBS-Volumes mit der Datenmenge steigt, die seit dem letzten Snapshot auf ihnen geändert wurde.

Abschließende Empfehlungen

• Verwenden Sie Schnappschüsse - sie sind großartig - sie reduzieren Ausfallzeiten viel mehr als sie verursachen
• Trennen Sie Daten und das Root-Volume, und stellen Sie die Datenbanken möglicherweise sogar auf ein eigenes Volume. Bei Bedarf wird vor den Aktualisierungen ein Snapshot erstellt
• Verwenden Sie das Bin-Protokoll, um so heiß wie möglich zu bleiben - laden Sie dieses (komprimiert) in S3 hoch
• Stellen Sie sicher, dass Sie die Daten tatsächlich von der Instanz erhalten (selbst wenn die Daten auf einem EBS-Volume intakt sind, kann auf das Volume selbst vorübergehend nicht zugegriffen werden).

Literatur-Empfehlungen:

• Amazon Seite auf EBS
• EBS FAQs

(Ich glaube, ich habe zu viel geschrieben, aber nicht genug gesagt - aber hoffentlich finden Sie etwas, das es wert ist, gelesen zu werden).

Es ist möglich, einen Snapshot eines Live-EBS-Volumes zu erstellen. Sie müssen jedoch sicherstellen, dass sich das Dateisystem in einem konsistenten Zustand befindet und dann eingefroren wird, während der Snapshot gestartet wird. Nicht alle Dateisysteme erlauben dies, obwohl dies definitiv möglich ist und die Grundlage unserer eigenen Backup-Lösung darstellt.

EBS-Snapshots sind auch ziemlich billig, da sie nur für geänderte Daten berechnet werden und die Datengebühren an und für sich sehr vernünftig sind. Beachten Sie jedoch, dass dies auf Änderungen der Blockebene basiert und sich daher recht schnell ändern kann. Dies gilt auch für Snapshots. Es werden nur Daten berechnet, die zwischen Snapshots geändert wurden. Um Ihnen eine Vorstellung von den Kosten zu geben, zahlen wir <10 US-Dollar pro Monat für die Speicherung von Schnappschüssen. Wir machen tägliche Schnappschüsse, behalten die wöchentlichen Schnappschüsse der letzten 7 Tageszeitungen und letzten Monate bei und haben 2 Server, die diesem Schema folgen (~ 20 Schnappschüsse, 20 GB Festplatten).

Wie wäre es mit einer billigen, kostengünstigen Backup-Lösung wie Zmanda Cloud Backup? Wir verwenden es, um ungefähr 6 Server und 1 SQL Server zu sichern, und es sind nur ungefähr 10 US-Dollar pro Monat. Sie können Ihre Daten mit einem selbstsignierten Zertifikat verschlüsseln und sie verwenden s3 zum Speichern der Daten (daher fallen keine Datenübertragungsgebühren an, wenn Sie von EC2 sichern).