AERODISK Engine: Katastrophenschutz. Teil 1

Hallo, liebe Leser von Habr! In diesem Artikel geht es um die Implementierung von Katastrophenschutz-Maßnahmen in den Speichersystemen des AERODISK Engines. Ursprünglich wollten wir in einem Beitrag sowohl über die Replikation als auch über Metro-Cluster berichten, jedoch wurde der Artikel zu umfangreich, weshalb wir ihn in zwei Teile aufgeteilt haben. Lassen Sie uns von einfachen zu komplexen Themen übergehen. In diesem Artikel werden wir die synchrone Replikation einrichten und testen – wir werden ein Rechenzentrum (RZ) ausfallen lassen und die Verbindung zwischen den RZ unterbrechen, um zu sehen, was passiert.

Unsere Kunden stellen uns häufig verschiedene Fragen zur Replikation. Daher möchten wir, bevor wir mit der Einrichtung und dem Test der Replikationsimplementierungen beginnen, kurz erläutern, was Replikation in Speichersystemen bedeutet.

Ein wenig Theorie

Die Replikation in Speichersystemen ist ein kontinuierlicher Prozess, der sicherstellt, dass die Daten gleichzeitig auf mehreren Speichersystemen identisch sind. Technisch gesehen wird die Replikation auf zwei Arten durchgeführt.

Synchrone Replikation – dies ist die Datenkopie von der primären Speichereinheit auf die Sicherungseinheit, gefolgt von der verbindlichen Bestätigung beider Speichereinheiten, dass die Daten geschrieben und bestätigt wurden. Erst nach der Bestätigung von beiden Seiten (von beiden Speichereinheiten) gelten die Daten als geschrieben und können bearbeitet werden. Damit wird die garantierte Identität der Daten auf allen an der Replikation beteiligten Speichereinheiten sichergestellt.

Vorteile dieser Methode:

• Daten sind immer identisch auf allen Speichereinheiten

Nachteile:

• Hohe Kosten der Lösung (schnelle Kommunikationskanäle, teure Glasfaser, Langwellen-Transceiver usw.)
• Entfernungseinschränkungen (innerhalb von einigen Dutzend Kilometern)
• Kein Schutz vor logischer Datenbeschädigung (wenn die Daten absichtlich oder versehentlich auf der primären Speichereinheit beschädigt werden, werden sie automatisch und sofort auch auf der Sicherungseinheit beschädigt, da die Daten immer identisch sind (so ein Paradoxon))

Asynchrone Replikation – dies ist ebenfalls eine Datenkopie von der primären zum sekundären Speicher, jedoch mit einer bestimmten Verzögerung und ohne die Notwendigkeit einer Bestätigung der Speicherung auf der anderen Seite. Mit den Daten kann sofort nach der Speicherung auf dem primären Speicher gearbeitet werden, während die Daten auf dem sekundären Speicher nach einiger Zeit verfügbar sind. In diesem Fall wird die Identität der Daten natürlich nicht vollständig gewährleistet. Die Daten auf dem sekundären Speicher befinden sich immer ein wenig "in der Vergangenheit".

Vorteile der asynchronen Replikation:

• Niedrige Kosten der Lösung (beliebige Kommunikationskanäle, Glasfaser optional)
• Keine Einschränkungen hinsichtlich der Entfernung
• Auf dem sekundären Speicher werden die Daten nicht beschädigt, falls sie auf dem primären beschädigt werden (zumindest für eine gewisse Zeit). Wenn die Daten beschädigt sind, kann die Replikation jederzeit gestoppt werden, um eine Beschädigung der Daten auf dem sekundären Speicher zu vermeiden.

Nachteile:

• Die Daten in verschiedenen Rechenzentren sind immer unidentisch.

Die Wahl des Replikationsmodus hängt von den geschäftlichen Anforderungen ab. Wenn es für Sie entscheidend ist, dass die Daten im Backup-Rechenzentrum identisch mit denen im Hauptrechenzentrum sind (d.h. das Geschäft fordert RPO=0), müssen Sie bereit sein, in eine synchrone Replikation zu investieren und deren Einschränkungen in Kauf zu nehmen. Ist eine gewisse Datenverzögerung akzeptabel oder einfach das Budget begrenzt, sollten Sie definitiv die asynchrone Methode wählen.

Ein spezieller Modus, den wir hervorheben möchten (genauer gesagt, eine Topologie), ist der Metro-Cluster. Im Metro-Cluster wird eine synchronisierte Replikation eingesetzt, jedoch ermöglicht der Metro-Cluster im Gegensatz zu einer herkömmlichen Replikation, dass beide Storage-Systeme aktiv betrieben werden. Es gibt also keine Unterscheidung zwischen aktiven und passiven Rechenzentren. Die Anwendungen arbeiten gleichzeitig mit zwei Storage-Systemen, die physisch in unterschiedlichen Rechenzentren untergebracht sind. Ausfallzeiten bei Störungen in dieser Topologie sind sehr gering (RTO liegt in der Regel bei Minuten). In diesem Artikel werden wir unsere Umsetzung des Metro-Clusters nicht behandeln, da dies ein sehr umfangreiches und tiefgehendes Thema ist, dem wir einen separaten, nächsten Artikel widmen werden.

Ganz oft, wenn wir über Replikation mittels Storage-Systemen sprechen, stellt sich vielen die berechtigte Frage: > „Viele Anwendungen verfügen über eigene Replikationsmethoden, warum also Replikation auf dem Storage-System nutzen? Ist das besser oder schlechter?“

Hier gibt es keine eindeutige Antwort, deshalb nennen wir die Argumente FÜR und GEGEN:

Argumente FÜR die Replikation auf dem Storage-System:

• Einfachheit der Lösung. Mit einem einzigen Tool können Sie das gesamte Datenvolumen replizieren, unabhängig von der Art der Last und den Anwendungen. Wenn die Replikation durch Anwendungen erfolgt, müssen Sie jede Anwendung einzeln einrichten. Bei mehr als zwei Anwendungen wird dies sehr mühsam und teuer (die Replikation von Anwendungen erfordert in der Regel eine separate und kostenpflichtige Lizenz für jede Anwendung. Aber dazu später mehr).
• Es können beliebige Dinge repliziert werden – beliebige Anwendungen, beliebige Daten – und sie sind immer konsistent. Viele (die meisten) Anwendungen haben keine eigenen Replikationsmethoden, und die Replikation vom Storage-System ist das einzige Mittel, um einen Katastrophenschutz zu gewährleisten.
• Zahlen Sie nicht zu viel für die Funktionalität der Anwendungsreplikation. In der Regel ist sie nicht günstig, ebenso wie die Lizenzen für die Replikation von Storage-Systemen. Aber für die Lizenz zur Replikation des Storage-Systems müssen Sie einmalig zahlen, während die Lizenz für die Anwendungsreplikation für jede Anwendung separat erworben werden muss. Wenn es viele solcher Anwendungen gibt, summieren sich die Kosten und die Lizenzkosten für die Replikation des Storage-Systems werden zur Nebensache.

Argumente GEGEN die Replikation von Storage-Systemen:

• Die Replikation mithilfe von Anwendungen bietet mehr Funktionalität aus Sicht der Anwendungen selbst, da die Anwendung ihre Daten besser kennt (was offensichtlich ist), gibt es daher mehr Optionen im Umgang mit den Daten.
• Hersteller bestimmter Anwendungen garantieren keine Konsistenz ihrer Daten, wenn die Replikation mit Drittanbieter-Tools erfolgt.*

* - umstrittener Punkt. Zum Beispiel hat ein bekannter Datenbankhersteller lange Zeit offiziell behauptet, dass ihre Datenbank nur mit ihren eigenen Mitteln ordnungsgemäß repliziert werden kann, und jede andere Replikation (einschließlich der von Storage-Systemen) sei „nicht wahr“. Aber die Realität hat gezeigt, dass das nicht stimmt. Höchstwahrscheinlich (aber das ist nicht sicher) handelt es sich hierbei einfach um einen nicht ganz fairen Versuch, Kunden weitere Lizenzen zu verkaufen.

In den meisten Fällen ist die Replikation von Storage-Systemen besser, da sie eine einfachere und kostengünstigere Lösung darstellt. Es gibt jedoch komplexe Szenarien, in denen spezifische Anwendungsfunktionen erforderlich sind und direkt auf die Anwendungsebene der Replikation eingegangen werden muss.

Theorie abgeschlossen, nun zur Praxis.

Wir werden die Replikation in unserem Labor einrichten. Unter Laborbedingungen haben wir zwei Rechenzentren emuliert (in Wirklichkeit sind es zwei nebeneinander stehende Racks, die so aussehen, als befänden sie sich in verschiedenen Gebäuden). Der Stand besteht aus zwei Engine N2 Storage-Systemen, die durch optische Kabel miteinander verbunden sind. An beide Storage-Systeme ist ein physischer Server mit Windows Server 2016 über 10Gb Ethernet angeschlossen. Der Stand ist ziemlich einfach, aber das ändert nichts an der Bedeutung.

Schematically, it looks like this:

Logisch ist die Replikation wie folgt organisiert:

Nun betrachten wir die funktionalen Möglichkeiten der Replikation, die uns derzeit zur Verfügung stehen.
Es werden zwei Modi unterstützt: asynchron und synchron. Es ist logisch, dass der synchrone Modus durch die Distanz und die Verbindungskanäle begrenzt ist. Insbesondere für den synchronen Modus ist es erforderlich, Glasfaser als physische Grundlage und 10-Gigabit-Ethernet (oder schneller) zu verwenden.

Die unterstützte Entfernung für die synchronen Replikation beträgt 40 Kilometer, mit einer maximalen Verzögerung von 2 Millisekunden zwischen den Rechenzentren. Obwohl auch größere Verzögerungen funktionieren, wird es dabei zu erheblichen Schreibverzögerungen kommen, was nachvollziehbar ist. Daher sollten Sie, wenn Sie eine synchrone Replikation zwischen Rechenzentren planen, die Qualität der optischen Verbindung und die Verzögerungen überprüfen.

Für die asynchrone Replikation sind die Anforderungen nicht so streng. Genauer gesagt, es gibt überhaupt keine. Jede funktionierende Ethernet-Verbindung ist ausreichend.

Aktuell unterstützt das AERODISK ENGINE SAN die Replikation für blockbasierte Geräte (LUNs) über Ethernet (entweder über Kupfer oder Glasfaser). Für Projekte, bei denen eine Replikation über eine SAN-Switch-Architektur mit Fibre Channel erforderlich ist, arbeiten wir derzeit an einer entsprechenden Lösung, die jedoch noch nicht bereit ist. Daher bieten wir in diesem Fall nur Ethernet an.

Die Replikation kann zwischen beliebigen SANs der ENGINE-Serie (N1, N2, N4) von älteren auf neuere Systeme und umgekehrt funktionieren.

Die Funktionalität beider Replikationsmodi ist vollständig identisch. Im Folgenden finden Sie detaillierte Informationen dazu:

• Die Replikation erfolgt im „one-to-one“-Modus, also klassisch mit zwei Rechenzentren, einem primären und einem sekundären.
• Die „One-to-Many“-Replikation ermöglicht es, einen LUN gleichzeitig auf mehrere Storage-Systeme zu replizieren.
• Aktivierung, Deaktivierung und „Umdrehung“ der Replikation, entsprechend zum Ein- oder Ausschalten oder zur Änderung der Replikationsrichtung.
• Replikation ist sowohl für RDG-Pools (Raid Distributed Group) als auch für DDP (Dynamic Disk Pool) verfügbar. Hierbei kann ein LUN eines RDG-Pools nur in einen anderen RDG repliziert werden, bei DDP funktioniert es analog.

Es gibt noch viele weitere kleine Besonderheiten, jedoch macht es wenig Sinn, sie alle aufzuzählen; wir werden sie im Verlauf der Einrichtung erwähnen.

Einrichtung der Replikation

Der Einrichtungsprozess ist relativ einfach und besteht aus drei Phasen.

1. Netzwerkkonfiguration
2. Speicherkonfiguration
3. Einrichtung der Regeln (Beziehungen) und des Mappings

Ein wichtiger Punkt bei der Einrichtung der Replikation ist, dass die ersten beiden Phasen auf dem entfernten Storage-System wiederholt werden sollten, die dritte Phase jedoch nur auf dem Hauptsystem.

Einrichtung der Netzwerkressourcen

Zuerst müssen die Netzwerkports konfiguriert werden, über die der Replikationstraffic übertragen wird. Dazu müssen die Ports aktiviert und konfiguriert werden. IP-Adressen im Abschnitt Front-End-Adapter.

Anschließend müssen wir einen Pool (in unserem Fall RDG) und eine virtuelle IP-Adresse für die Replikation (VIP) erstellen. VIP ist eine schwebende IP-Adresse, die an zwei 'physische' Adressen der Storage-Controller (Ports, die wir gerade konfiguriert haben) gebunden ist. Sie wird die primäre Schnittstelle für die Replikation sein. Alternativ kann auch mit VLANs gearbeitet werden, wenn getaggter Verkehr erforderlich ist.

Der Prozess zur Erstellung einer VIP für die Replikation unterscheidet sich kaum von der Erstellung einer VIP für Ein- und Ausgaben (NFS, SMB, iSCSI). In diesem Fall erstellen wir die VIP gewöhnlich (ohne VLAN), geben jedoch zwingend an, dass sie für die Replikation gedacht ist (ohne diesen Verweis können wir die VIP im nächsten Schritt nicht zu den Regeln hinzufügen).

Die VIP muss sich im selben Subnetz wie die IP-Adressen der Ports befinden, zwischen denen sie 'schwebt'.

Wir wiederholen diese Einstellungen auf dem entfernten Storage-System mit einer anderen IP-Adresse, selbstverständlich.
VIPs von verschiedenen Storage-Systemen können sich in unterschiedlichen Subnetzen befinden, Hauptsache, zwischen ihnen gibt es Routing. In unserem Fall ist genau dieses Beispiel gezeigt (192.168.3.XX und 192.168.2.XX).

Damit ist die Vorbereitung des Netzwerkteils abgeschlossen.

Wir konfigurieren die Speicher.

Die Einrichtung des Speichers für die Replikation unterscheidet sich nur darin, dass die Zuordnung über das spezielle Menü „Replikationszuordnung“ erfolgt. Ansonsten bleibt alles wie bei der normalen Einrichtung.

Im zuvor erstellten Pool R02 muss ein LUN erstellt werden. Wir erstellen ihn und nennen ihn LUN1.

Außerdem müssen wir ein identisches LUN auf dem entfernten Speichersystem mit demselben Volumen erstellen. Wir tun dies. Um Verwirrungen zu vermeiden, nennen wir das entfernte LUN LUN1R.

Falls wir ein bereits existentes LUN verwenden müssten, müsste während der Einrichtung der Replikation dieses produktive LUN vorübergehend vom Host abgemeldet werden, und auf dem entfernten Speichersystem müsste einfach ein leeres LUN mit demselben Volumen erstellt werden.

Die Einrichtung des Speichers ist abgeschlossen, jetzt gehen wir zur Erstellung der Replikationsregel über.

Einrichtung von Replikationsregeln oder Replikationsbeziehungen

Nachdem die LUNs auf dem derzeit primären Speichersystem (Primary) erstellt wurden, richten wir die Replikationsregel von LUN1 auf LUN1R auf Speichersystem 2 ein.

Die Einrichtung erfolgt im Menü „Remote-Replikation“

Wir erstellen eine Regel. Dazu müssen wir den Empfänger der Replikation angeben. Dort geben wir auch den Namen der Beziehung und den Replikationstyp (synchron oder asynchron) an.

Im Feld „entfernte Systeme“ fügen wir unser SAN2 hinzu. Für die Hinzufügung müssen die Verwaltungs-IP des SAN (MGR) und der Name des entfernten LUN verwendet werden, auf dem wir die Replikation durchführen werden (in unserem Fall LUN1R). Die Verwaltungs-IP wird nur während der Verbindungserstellung benötigt, der Replikationsverkehr wird darüber nicht übertragen; dafür wird die zuvor konfigurierte VIP verwendet.

Bereits auf dieser Stufe können wir mehr als ein entferntes System für die „one to many“-Topologie hinzufügen: Klicken Sie auf die Schaltfläche „Knoten hinzufügen“, wie im Bild unten gezeigt.

In unserem Fall gibt es nur ein entferntes System, daher beschränken wir uns darauf.

Die Regel ist bereit. Beachten Sie, dass sie automatisch auf allen Replikationsbeteiligten hinzugefügt wird (in unserem Fall sind das zwei). So viele Regeln können erstellt werden, wie gewünscht, für beliebig viele LUNs und in beide Richtungen. Zum Beispiel können wir zur Lastverteilung einige LUNs von SAN1 auf SAN2 replizieren und andere hingegen von SAN2 auf SAN1.

SAN1. Unmittelbar nach der Erstellung begann die Synchronisierung.

SAN2. Wir sehen dieselbe Regel, aber die Synchronisierung ist bereits abgeschlossen.

LUN1 auf SCD1 ist als Primär konfiguriert, das heißt, er ist aktiv. LUN1R auf SCD2 wird als Sekundär bezeichnet, was bedeutet, dass er im Bereitschaftsmodus ist, falls SCD1 ausfällt.
Jetzt können wir unser LUN mit dem Host verbinden.

Wir werden die Verbindung über iSCSI herstellen, obwohl auch FC möglich ist. Die Konfiguration des Mappings für das iSCSI-LUN in der Replikation unterscheidet sich praktisch nicht von einem gewöhnlichen Szenario, daher werden wir dies hier nicht im Detail betrachten. Falls erforderlich, wird dieser Prozess im Artikel „Schnelle Einrichtung».

Der einzige Unterschied – das Mapping erfolgt im Menü „Replikationsmapping“

Wir haben das Mapping konfiguriert und das LUN dem Host zugewiesen. Der Host hat das LUN erkannt.

Wir formatieren es im lokalen Dateisystem.

Das war's, die Einrichtung ist abgeschlossen. Jetzt folgen die Tests.

Testen

Wir werden drei Hauptszenarien testen.

1. Regulärer Rollenwechsel von Sekundär > Primär. Der reguläre Rollenwechsel ist notwendig, falls wir im Hauptrechenzentrum präventive Wartungsarbeiten durchführen müssen und diese Zeit, um Daten verfügbar zu halten, die Last in das Backup-Rechenzentrum übertragen wird.
2. Failover von Secondary zu Primary (Ausfall des Rechenzentrums). Dies ist das Hauptszenario, für das die Replikation existiert, und es hilft, einen vollständigen Ausfall des Rechenzentrums zu überstehen, ohne den Geschäftsbetrieb über längere Zeiträume zu unterbrechen.
3. Unterbrechungen der Kommunikationskanäle zwischen den Rechenzentren. Überprüfung des korrekten Verhaltens beider SANs unter Bedingungen, unter denen aus bestimmten Gründen der Kommunikationskanal zwischen den Rechenzentren nicht verfügbar ist (z. B. wenn ein Bagger versehentlich das dunkle Glasfaserkabel beschädigt hat).

Zunächst beginnen wir, Daten auf unser LUN zu schreiben (wir schreiben Dateien mit zufälligen Daten). Sofort beobachten wir, dass die Verbindung zwischen den SANs ausgelastet ist. Das lässt sich leicht erkennen, wenn man die Überwachung der Portlasten öffnet, die für die Replikation verantwortlich sind.

Auf beiden SANs befinden sich jetzt „nützliche“ Daten, wir können mit dem Test beginnen.

Zur Sicherheit schauen wir uns die Hash-Werte einer der Dateien an und notieren sie.

Regulärer Rollenwechsel

Die Rollenwechseloperation (Änderung der Replikationsrichtung) kann von jedem SAN durchgeführt werden, aber es muss dennoch auf beide zugegriffen werden, da das Mapping auf dem Primary deaktiviert und auf dem Secondary (das zum Primary wird) aktiviert werden muss.

Es stellt sich vielleicht die berechtigte Frage: Warum sollte man das nicht automatisieren? Die Antwort ist einfach: Replikation ist ein einfaches Mittel zur Katastrophensicherung, das nur auf manuellen Vorgängen beruht. Um diese Vorgänge zu automatisieren, gibt es den Metro-Clustermodus, der vollständig automatisiert ist, jedoch ist seine Einrichtung deutlich komplizierter. In einem zukünftigen Artikel werden wir über die Konfiguration des Metro-Clusters berichten.

Auf dem primären Speichersystem deaktivieren wir das Mapping, um sicherzustellen, dass keine Aufzeichnungen mehr erfolgen.

Dann wählen wir auf einem der Speichersysteme (ob primär oder sekundär ist unwichtig) im Menü „Remote-Replikation“ unsere Verbindung REPL1 aus und klicken auf „Rolle ändern“.

Nach ein paar Sekunden wird LUN1R (das sekundäre Speichersystem) zum Primary.

Wir machen das Mapping von LUN1R mit Speichersystem 2.

Daraufhin wird automatisch unser Laufwerk E: auf dem Host angebunden, und diesmal ist es „herangekommen“ von LUN1R.

Zur Sicherheit vergleichen wir die Hash-Werte.

Identisch. Test bestanden.

Notfallumschaltung. Ausfall des Rechenzentrums.

Im Moment ist das primäre Speichersystem nach der regulären Umschaltung Speichersystem 2 und LUN1R, entsprechend. Um einen Ausfall zu simulieren, schalten wir die Stromversorgung beider Controller von Speichersystem 2 ab.
Der Zugriff darauf ist nicht mehr möglich.

Wir beobachten, was mit dem SAN 1 (aktuell im Standby) passiert.

Wir sehen, dass das Primary LUN (LUN1R) nicht verfügbar ist. Es gab eine Fehlermeldung in den Protokollen, im Info-Dashboard sowie in der Replikationsregel. Daher sind die Daten vom Host derzeit nicht verfügbar.

Wir ändern die Rolle von LUN1 auf Primary.

Wir nehmen das Mapping zum Host vor.

Wir stellen sicher, dass die Festplatte E auf dem Host erscheint.

Wir überprüfen den Hash.

Alles in Ordnung. Der Ausfall des aktiven Rechenzentrums hat das SAN erfolgreich überstanden. Die ungefähre Zeit, die wir für die Konfiguration der Replikationsumstellung und die Anbindung des LUN aus dem Standby-Rechenzentrum benötigt haben, betrug etwa 3 Minuten. Es ist klar, dass es in einer realen Produktionsumgebung viel komplizierter ist und neben den Maßnahmen am SAN noch viele weitere Operationen im Netzwerk, auf den Hosts und in den Anwendungen durchgeführt werden müssen. In der Realität wird dieser Zeitraum deutlich länger sein.

Hier möchte ich schreiben, dass alles gut ist, der Test wurde erfolgreich abgeschlossen, aber wir wollen uns nicht zu früh freuen. Das Haupt-SAN ist 'down' und wir wissen, dass es in der Rolle 'Primary' war, als es ausgefallen ist. Was passiert, wenn es plötzlich wieder einschaltet? Es wären zwei Primary-Rollen vorhanden, was zu Datenverlust führen würde. Das überprüfen wir jetzt.
Wir gehen jetzt dazu über, das ausgefallene SAN wieder zu aktivieren.

Es startet einige Minuten und kehrt dann nach kurzer Synchronisation wieder in Betrieb, allerdings in der Rolle Secondary.

Alles in Ordnung. Es gab keinen Split-Brain. Wir haben daran gedacht, dass nach einem Ausfall des Speichersystems immer in der Rolle Secondary gestartet wird, unabhängig davon, in welcher Rolle es zuvor aktiv war. Nun können wir definitiv sagen, dass der Test für den Ausfall des Rechenzentrums erfolgreich war.

Ausfall der Kommunikationskanäle zwischen den Rechenzentren

Die Hauptaufgabe dieses Tests besteht darin, sicherzustellen, dass das Speichersystem nichts Ungewöhnliches macht, wenn es temporär den Kontakt zwischen zwei Speichersystemen verliert, der dann wiederhergestellt wird.
Also, wir trennen die Kabel zwischen den Speichersystemen (nehmen wir an, ein Bagger hat sie durchtrennt).

Auf dem Primary sehen wir, dass keine Verbindung zum Secondary besteht.

Auf dem Secondary sehen wir, dass keine Verbindung zum Primary besteht.

Alles funktioniert normal, und wir fahren fort, Daten auf das primäre Speichersystem zu schreiben, das heißt, sie unterscheiden sich jetzt garantiert von der Backup-Version, also sind sie 'auseinandergegangen'.

Nach ein paar Minuten 'reparieren' wir den Kommunikationskanal. Sobald sich die Speichersysteme wieder sehen, wird die Datensynchronisation automatisch aktiviert. Hierfür sind keine Eingriffe des Administrators erforderlich.

Nach einiger Zeit ist die Synchronisation abgeschlossen.

Die Verbindung wurde wiederhergestellt, es gab keine außergewöhnlichen Situationen, die zu einem Ausfall der Kommunikationskanäle geführt hätten, und nach dem Aktivieren fand automatisch eine Synchronisation statt.

Fazit

Wir haben die Theorie durchgenommen – was und warum es benötigt wird, wo die Vorteile und wo die Nachteile liegen. Danach haben wir die synchronisierte Replikation zwischen zwei Speichersystemen eingerichtet.

Anschließend wurden die Haupttests für den normalen Umschaltvorgang, den Ausfall des Rechenzentrums und den Ausfall der Kommunikationskanäle durchgeführt. In allen Fällen hat das Speichersystem gut funktioniert. Es gab keinen Datenverlust, die administrativen Operationen wurden auf ein Minimum für manuelle Szenarien reduziert.

Beim nächsten Mal werden wir die Situation komplizierter gestalten und zeigen, wie diese gesamte Logik in einem automatisierten Metrocluster im Active-Active-Betrieb funktioniert, das heißt, wenn beide Speichersysteme aktiv sind und das Verhalten im Falle eines Ausfalls vollständig automatisiert ist.

Bitte schreiben Sie Kommentare, wir freuen uns über konstruktive Kritik und nützliche Ratschläge.

Bis zum nächsten Mal.

Quelle: habr.com