Replizieren Sie die Gruppe, nicht die Platte: Konsistenz in der Array-Replikation

Array-Replikation klingt nach der einfachsten Art von Disaster Recovery: Das Array kopiert Ihre Platten auf ein anderes Array in einem anderen Rechenzentrum, und in Ihren Servern muss sich nichts ändern. So einfach ist es tatsächlich, vorausgesetzt, Sie replizieren die richtigen Dinge zusammen. Replizieren Sie jedes Volume für sich, und Sie können mit einer perfekten Kopie jeder Platte und einer Datenbank enden, die sich weigert zu starten.

Eine Kopie jeder Platte ist keine Kopie der Anwendung

Die meisten ernsthaften Anwendungen schreiben auf mehr als ein Volume. Eine Datenbank hält ihre Datendateien auf einer Platte und ihr Transaktionslog auf einer anderen. Ein Mailserver trennt den Nachrichtenspeicher von seinen Logs. Eine virtuelle Maschine kann eine Systemplatte und eine Datenplatte haben, die nur zusammen Sinn ergeben.

Diese Anwendungen hängen von der Schreibreihenfolge ab. Die Datenbank schreibt zuerst den Logeintrag und später die Datenseite, und bei der Wiederherstellung spielt sie das Log nach, um die Datendateien auf einen konsistenten Stand zu bringen. Wenn die Kopie des Log-Volumes am entfernten Standort ein paar Sekunden älter ist als die Kopie des Daten-Volumes, hält der entfernte Standort Datenseiten, die auf Logeinträge verweisen, die dort nicht existieren. Die Datenbank sieht einen unmöglichen Zustand. Bestenfalls erholt sie sich mit Mühe. Schlimmstenfalls öffnet sie nicht.

Wenn jedes Volume unabhängig repliziert wird, bewegt sich jede Kopie in ihrem eigenen Tempo, sodass die entfernten Platten fast nie auf demselben Zeitpunkt stehen. Die Antwort ist eine Consistency Group: eine Menge von Volumes, die das Array als eine Einheit repliziert und dabei die Reihenfolge der Schreibvorgänge über alle hinweg bewahrt. Auf HPE 3PAR ist das eine Remote Copy group. Andere Arrays haben ihren eigenen Namen für dieselbe Idee. Wie auch immer sie heißt, die Regel ist dieselbe. Alles, was eine Anwendung zum Starten braucht, kommt in eine Gruppe.

Auswählen, was in eine Gruppe gehört

Beginnen Sie bei der Anwendung, nicht bei der Volume-Liste:

• Listen Sie jedes Volume auf, auf das die Anwendung schreibt, einschließlich derer, die leicht vergessen werden: das Volume mit dem Archiv des Binary Logs oder Write-Ahead Logs, ein separater temporärer Tablespace, eine Konfigurationsplatte.
• Legen Sie alle in eine Gruppe.
• Halten Sie nicht zusammenhängende Anwendungen in getrennten Gruppen, damit die eine umgeschaltet, getestet oder pausiert werden kann, ohne die andere zu berühren.

Dann entscheiden Sie, wie dicht die Kopie dem Original folgt.

Wie nah sollte die Kopie sein?

Es gibt zwei große Familien von Replikationsmodi, und die Wahl ist ebenso eine Frage der Physik wie der Vorliebe.

Synchron hält die Kopie aktuell, um den Preis eines Round Trips bei jedem Schreibvorgang, der auf Metro-Distanz klein und zwischen Ländern messbar ist. Asynchron läuft mit lokaler Geschwindigkeit, und der Rückstand ist Ihr Recovery Point.

Keiner ist generell richtig. Ein Transaktionssystem, dessen letzte Minute an Bestellungen Wert hat, kann die Schreiblatenz rechtfertigen. Eine Content-Plattform, die ein paar Minuten an Änderungen verlieren kann, in der Regel nicht. Die richtige Antwort ergibt sich, wenn Sie fragen, was der Verlust dieser Lücke das Unternehmen kosten würde, und dann messen, ob die Anwendung die Latenz des strengeren Modus verträgt.

Halten Sie die Replikation vom Produktionspfad fern

Replikationsverkehr konkurriert mit dem I/O der Hosts, wenn Sie ihn lassen. Geben Sie ihm dedizierte Array-Ports, halten Sie diese Ports getrennt von denen, die die Hosts nutzen, und beschränken Sie jeden Replikationslink auf einen Partner. Beobachten Sie den Replikationsrückstand, nicht nur den Zustand des Links. Ein Link, der up ist, während die Kopie mit jeder Stunde weiter zurückfällt, ist das Fehlerbild, das einen Disaster-Recovery-Plan in eine Überraschung verwandelt.

Testen Sie das Replikat, ohne es zu beschädigen

Ein Replikat, das nie gestartet wurde, ist eine Hoffnung. Die gute Nachricht ist, dass Sie es testen können, ohne die Replikation zu unterbrechen:

1. Nehmen Sie einen Point-in-Time-Snapshot der sekundären Volumes der Gruppe auf dem entfernten Array. Snapshotten Sie die ganze Gruppe auf einmal, damit die Testkopie so konsistent ist wie das Replikat.
2. Präsentieren Sie die Snapshots einem isolierten Test-Host am entfernten Standort. Halten Sie diesen Host vom Produktionsnetzwerk fern, damit die Kopie keinen echten Verkehr beantworten, keine echten E-Mails senden und keine geplanten Jobs gegen echte Systeme ausführen kann.
3. Starten Sie die Anwendung genau so, wie Sie es im Katastrophenfall tun würden, mit Ihrem schriftlichen Runbook und sonst nichts.
4. Prüfen Sie sie auf Anwendungsebene: Die Datenbank öffnet und besteht ihre eigene Konsistenzprüfung, Zeilenzahlen und die neuesten Datensätze sind dort, wo der Recovery Point sie erwarten lässt, und eine Anmeldung in der Anwendung funktioniert.
5. Stoppen Sie die Zeit, von der Entscheidung zum Failover bis zur ersten erfolgreichen Transaktion. Diese Zahl ist Ihre tatsächliche Wiederherstellungszeit, was auch immer der Plan sagt.
6. Entfernen Sie die Snapshots und halten Sie das Ergebnis fest, einschließlich allem, was Sie überrascht hat.

Führen Sie den Test nach jeder Änderung an der Gruppe durch, und nach regelmäßigem Plan auch dann, wenn sich nichts geändert hat, denn Anwendungen fügen still und leise Volumes hinzu.

Replikation ist kein Backup

Replikation kopiert Änderungen getreu, und dazu gehören eine gelöschte Tabelle, ein Verschlüsselungslauf durch Ransomware und ein schlechtes Deployment. Innerhalb von Sekunden oder Minuten ist der Fehler an beiden Orten. Ein Replikat schützt Sie vor dem Verlust eines Standorts. Backups mit Historie schützen Sie vor Ihren eigenen Daten. Sie brauchen beides, und die Backups sollten von einem System geholt werden, das die Produktionsseite nicht erreichen kann.

Wie wir es machen

Zwischen unseren Rechenzentren in Athen und Amsterdam können Kunden-Volumes Array zu Array auf HPE 3PAR repliziert werden, wobei zusammengehörige Volumes in dieselbe Remote Copy group gelegt werden, damit sie untereinander konsistent bleiben. Der Replikationsmodus wird pro Dienst vereinbart, die Replikation läuft über dedizierte Ports, ein Partner pro Port-Paar, über unsere eigene private Verbindung zwischen den Standorten, und Replikate von in der EU gehosteten Daten bleiben innerhalb unserer EU-Infrastruktur. Innerhalb jedes Standorts sind die Arrays in Federation, sodass Volumes auch online zwischen Arrays wandern. Die Backups stehen daneben, getrennt und pull-only.

Wenn Sie nicht sicher sind, ob Ihre entfernte Kopie an dem Tag starten würde, an dem Sie sie brauchen, lohnt es sich, das an einem ruhigen Tag herauszufinden. Wir helfen gern beim Entwurf der Gruppen und des Tests.

cta: Mit einem Ingenieur sprechen

Related

• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/enterprise-san-storage/