Hallo, Habr-Leser! In unserem letzten Artikel haben wir ein einfaches Mittel zur Katastrophensicherung in Speichersystemen vorgestellt – die Replikation. In diesem Artikel tauchen wir in ein komplexeres und spannenderes Thema ein – den Metrocluster, also ein automatisiertes Mittel zum Schutz vor Katastrophen für zwei Rechenzentren, das es diesen ermöglicht, im Active-Active-Modus zu arbeiten. Wir werden erklären, demonstrieren, kaputt machen und reparieren.
Wie gewohnt, beginnen wir mit der Theorie.
Ein Metrocluster ist ein Cluster, das auf mehrere Standorte innerhalb einer Stadt oder Region verteilt ist. Das Wort „Cluster“ deutet eindeutig darauf hin, dass das System automatisiert ist, das heißt, die Umschaltung der Knoten im Cluster im Falle von Störungen (Failover) erfolgt automatisch.
Hier liegt der Hauptunterschied zwischen einem Metrocluster und herkömmlicher Replikation. Automatisierung der Vorgänge. Das bedeutet, im Falle bestimmter Vorfälle (Ausfall des Rechenzentrums, Unterbrechung von Verbindungen usw.) wird das Speichersystem eigenständig die notwendigen Maßnahmen ergreifen, um die Verfügbarkeit der Daten sicherzustellen. Bei der Verwendung herkömmlicher Replikate hingegen werden diese Schritte vollständig oder teilweise manuell vom Administrator durchgeführt.
Wozu ist das gut?
Das Hauptziel, das Unternehmen mit verschiedenen Implementierungen eines Metroclusters verfolgen, ist die Minimierung der RTO (Recovery Time Objective). Das heißt, die Wiederherstellungszeit der IT-Dienste nach einem Ausfall soll möglichst kurz gehalten werden. Bei herkömmlicher Replikation ist die Wiederherstellungszeit stets länger als bei einem Metrocluster. Warum? Ganz einfach. Der Administrator muss persönlich am Arbeitsplatz sein, um die Replikation manuell umzuschalten, während ein Metrocluster dies automatisch erledigt.
Wenn Sie keinen dedizierten Bereitschaftsadmin haben, der nie schläft, nicht isst, nicht raucht und nicht krank wird, sondern rund um die Uhr den Zustand des Speichers überwacht, können Sie nicht garantieren, dass ein Administrator während eines Ausfalls für das manuelle Umschalten verfügbar ist.
Folglich beträgt die RTO im Falle eines fehlenden Metroclusters oder eines unsterblichen Admins der 99. Ebene der Bereitschaftsadmins die Summe der Umschaltzeiten aller Systeme und den maximalen Zeitraum, nach dem der Administrator garantiert mit dem Speicher und den angrenzenden Systemen beginnen wird.
Daraus ergibt sich die offensichtliche Schlussfolgerung, dass ein Metro-Cluster eingesetzt werden muss, wenn die RTO-Anforderung in Minuten und nicht in Stunden oder Tagen besteht. Das bedeutet, dass das IT-Team im Falle eines gravierendsten Ausfalls des Rechenzentrums sicherstellen muss, dass der Zugang zu IT-Diensten innerhalb von Minuten oder sogar Sekunden wiederhergestellt wird.
Wie funktioniert das?
Auf der untersten Ebene nutzt der Metro-Cluster einen Mechanismus zur synchronen Datenreplikation, den wir im vorherigen Artikel beschrieben haben (siehe ). Da die Replikation synchron ist, gelten auch die entsprechenden Anforderungen:
- Glasfaser als physikalisches Medium, 10-Gigabit-Ethernet (oder höher);
- Abstand zwischen den Rechenzentren von maximal 40 Kilometern;
- Latenz des optischen Kanals zwischen den Rechenzentren (zwischen den Speichersystemen) von bis zu 5 Millisekunden (optimal 2).
All diese Anforderungen sind empfehlend, das heißt, der Metro-Cluster wird auch funktionieren, wenn diese Anforderungen nicht erfüllt sind, aber man muss verstehen, dass die Folgen der Nichteinhaltung dieser Anforderungen einer Verlangsamung der Leistung beider Speichersysteme im Metro-Cluster gleichkommen.
Für den Datenaustausch zwischen den Speichersystemen kommt eine synchrone Replikation zum Einsatz. Doch wie erfolgt der automatische Wechsel der Replikate, und wie kann man das Risiko eines Split-Brain vermeiden? Dazu wird eine zusätzliche Komponente auf einer höheren Ebene verwendet – der Schiedsrichter.
Wie funktioniert der Schiedsrichter und was ist seine Aufgabe?
Der Schiedsrichter ist eine kleine virtuelle Maschine oder ein Hardware-Cluster, der an einem dritten Standort (zum Beispiel im Büro) betrieben werden muss. Zudem muss der Zugang zu den Speichersystemen über ICMP und SSH gewährleistet sein. Nach dem Start sollte der Schiedsrichter eine IP-Adresse erhalten, die dann von den Speichersystemen als Adresse sowie den Adressen der entfernten Controller, die am Metro-Cluster beteiligt sind, eingetragen wird. Danach ist der Schiedsrichter betriebsbereit.
Der Schiedsrichter überwacht kontinuierlich alle Speichersysteme im Metro-Cluster. Sollte ein Speichersystem nicht erreichbar sein, trifft der Schiedsrichter nach Bestätigung der Nichterreichbarkeit durch ein weiteres aktives Cluster-Mitglied (eines der 'lebenden' Speichersysteme) die Entscheidung zur Aktivierung des Wechsels der Replikationsregeln und zum Mapping.
Ein sehr wichtiger Punkt. Der Schiedsrichter sollte sich immer in einem Standort befinden, der sich von den Speicherlösungen unterscheidet, also weder im Rechenzentrum 1, wo Speicherlösung 1 steht, noch im Rechenzentrum 2, wo Speicherlösung 2 installiert ist.
Warum? Weil nur so der Schiedsrichter mithilfe einer der überlebenden Speicherlösungen eindeutig und fehlerfrei den Ausfall einer der beiden Standorte, an denen die Speicherlösungen installiert sind, feststellen kann. Jede andere Art der Positionierung des Schiedsrichters könnte zu einem Split-Brain führen.
Jetzt tauchen wir in die Details der Schiedsrichterfunktion ein.
Auf dem Schiedsrichter sind mehrere Dienste aktiv, die ständig alle Controller der Speicherlösungen abfragen. Wenn das Ergebnis einer Abfrage von dem vorherigen abweicht (verfügbar/nicht verfügbar), wird dies in einer kleinen Datenbank aufgezeichnet, die ebenfalls auf dem Schiedsrichter läuft.
Lassen Sie uns die Logik der Schiedsrichterfunktion etwas detaillierter betrachten.
Schritt 1. Feststellung der Nichterreichbarkeit. Ein Signalereignis für den Ausfall einer Speicherlösung ist das Fehlen von Pings von beiden Controllern einer Speicherlösung für 5 Sekunden.
Schritt 2. Einleitung des Umschaltvorgangs. Nachdem der Schiedsrichter erkannt hat, dass eine der Speicherlösungen nicht erreichbar ist, sendet er eine Anfrage an die "lebendige" Speicherlösung, um sicherzustellen, dass die "tote" Speicherlösung tatsächlich ausgefallen ist.
Nachdem der Schiedsrichter diesen Befehl erhalten hat, überprüft der zweite (aktive) Storage-Controller zusätzlich die Verfügbarkeit des ausgefallenen ersten Storage-Controllers. Wenn dieser nicht verfügbar ist, sendet er eine Bestätigung an den Schiedsrichter, dass seine Vermutung korrekt war. Der Storage-Controller ist tatsächlich nicht erreichbar.
Nach Erhalt dieser Bestätigung startet der Schiedsrichter das Remote-Verfahren zur Umstellung der Replikation und zum Aktivieren des Mappings auf den Replikaten, die aktiv (primär) auf dem ausgefallenen Storage-Controller waren, und sendet den Befehl an den zweiten Storage-Controller, diese Replikate von sekundär auf primär zu ändern und das Mapping zu aktivieren. Der zweite Storage-Controller führt entsprechend diese Verfahren durch und stellt den Zugriff auf die verlorenen LUNs wieder her.
Warum ist eine zusätzliche Überprüfung notwendig? Für das Quorum. Das heißt, die Mehrheit der insgesamt ungeraden (3) Teilnehmer des Clusters müssen den Ausfall eines der Knoten im Cluster bestätigen. Nur dann wird die Entscheidung als definitiv korrekt angesehen. Dies ist erforderlich, um ein fehlerhaftes Umschalten und entsprechend ein Split-Brain zu vermeiden.
Schritt 2 dauert etwa 5 bis 10 Sekunden. Daher sind LUNs mit einer ausgefallenen SAN, die nach einem Ausfall für den Zugriff auf die aktive SAN benötigt werden, innerhalb von 10 bis 15 Sekunden nach der Unzugänglichkeit automatisch verfügbar.
Es ist klar, dass, um eine Unterbrechung der Verbindung zu den Hosts zu vermeiden, auch auf die korrekte Konfiguration der Timeouts auf den Hosts geachtet werden muss. Die empfohlene Timeout-Dauer beträgt mindestens 30 Sekunden. Dies verhindert, dass der Host die Verbindung zur SAN während der Lastumteilung im Falle eines Ausfalls trennt und gewährleistet eine unterbrechungsfreie Ein- und Ausgabe.
Moment mal, wenn mit dem Metrocluster alles so gut ist, wozu braucht man dann überhaupt gewöhnliche Replikationen?
In Wirklichkeit ist es nicht ganz so einfach.
Lassen Sie uns die Vor- und Nachteile des Metroclusters betrachten.
Wir haben also festgestellt, dass die offensichtlichen Vorteile des Metroclusters im Vergleich zu herkömmlichen Replikationen folgende sind:
- Vollständige Automatisierung, die eine minimale Wiederherstellungszeit im Falle einer Katastrophe gewährleistet;
- Und das war's :-).
Und jetzt, Achtung, die Nachteile:
- Kosten des Systems. Obwohl der Metrocluster in Aerodisk-Systemen keine zusätzliche Lizenzierung benötigt (es wird dieselbe Lizenz wie für die Replikation verwendet), werden die Kosten für die Lösung dennoch höher sein als bei der Verwendung der synchronen Replikation. Es müssen alle Anforderungen für die synchrone Replikation sowie die Anforderungen für den Metrocluster, die mit zusätzlicher Verkabelung und einer zusätzlichen Site verbunden sind (siehe Planung des Metroclusters), umgesetzt werden.
- Komplexität der Lösung. Der Metrocluster ist erheblich komplexer aufgebaut als eine herkömmliche Replikation und erfordert deutlich mehr Aufmerksamkeit und Aufwand bei Planung, Einrichtung und Dokumentation.
Fazit. Der Metrocluster ist zweifellos eine hochgradig technologische und gute Lösung, wenn Sie tatsächlich eine RTO von Sekunden oder Minuten gewährleisten müssen. Wenn dies jedoch nicht der Fall ist und eine RTO von Stunden für das Geschäft in Ordnung ist, gibt es keinen Grund, mit Kanonen auf Spatzen zu schießen. Eine herkömmliche Replikation reicht aus, da der Metrocluster zusätzliche Kosten und Komplexität in der IT-Infrastruktur verursachen wird.
Planung des Metroclusters
Dieser Abschnitt erhebt nicht den Anspruch, ein umfassendes Handbuch zur Gestaltung eines Metroclusters zu sein, sondern zeigt lediglich die grundlegenden Richtungen auf, die Sie berücksichtigen sollten, wenn Sie ein solches System aufbauen möchten. Daher ist es bei der tatsächlichen Implementierung eines Metroclusters unerlässlich, den Hersteller der Speichersysteme (also uns) sowie andere angrenzende Systeme zurate zu ziehen.
Standorte
Wie bereits erwähnt, sind für ein Metrocluster mindestens drei Standorte erforderlich. Zwei Rechenzentren, in denen die Speichersysteme und verwandte Systeme betrieben werden, sowie ein dritter Standort, an dem der Schiedsrichter arbeitet.
Die empfohlene Entfernung zwischen den Rechenzentren beträgt maximal 40 Kilometer. Eine größere Entfernung wird mit hoher Wahrscheinlichkeit zusätzliche Verzögerungen verursachen, die im Falle eines Metroclusters äußerst unerwünscht sind. Wir erinnern daran, dass die Latenzzeiten unter 5 Millisekunden liegen sollten, wobei es ideal wäre, innerhalb von 2 Millisekunden zu bleiben.
Es wird empfohlen, die Latenzen auch im Planungsprozess zu überprüfen. Jeder halbwegs seriöse Anbieter, der Glasfaserverbindungen zwischen den Rechenzentren bereitstellt, kann eine qualitativ hochwertige Überprüfung recht schnell organisieren.
Was die Latenzen zu den Schiedsrichtern betrifft (also zwischen der dritten Plattform und den ersten beiden), so beträgt die empfohlene Latenzschwelle 200 Millisekunden, sodass eine herkömmliche Unternehmens-VPN-Verbindung über das Internet geeignet ist.
Switching und Netzwerk
Im Gegensatz zum Replikationsschema, bei dem es ausreicht, die Speichersysteme (SCSI) zwischen verschiedenen Standorten zu verbinden, erfordert das Metroklysterschema eine Verbindung der Hosts zu beiden Speichersystemen an unterschiedlichen Standorten. Um den Unterschied klarer zu machen, sind beide Schemas unten aufgeführt.
Wie aus dem Diagramm ersichtlich, sehen die Hosts des Standorts 1 sowohl auf das Speichersystem 1 als auch auf das Speichersystem 2. Umgekehrt sehen die Hosts des Standorts 2 sowohl auf das Speichersystem 2 als auch auf das Speichersystem 1. Das bedeutet, dass jeder Host beide Speichersysteme sieht. Dies ist eine Voraussetzung für die Funktion eines Metroklysters.
Es ist selbstverständlich nicht notwendig, jeden Host mit einem Glasfaserkabel in ein anderes Rechenzentrum zu ziehen; es wären nicht genügend Ports und Kabel vorhanden. All diese Verbindungen sollten über 10G+ Ethernet-Switches oder 8G+ FibreChannel hergestellt werden (FC nur für die Verbindung zwischen Hosts und Speichersystemen für IO; der Replikationskanal ist vorerst nur über IP (Ethernet 10G+) verfügbar).
Jetzt ein paar Worte zur Netzwerk-Topologie. Ein wichtiger Punkt ist die korrekte Konfiguration der Subnetze. Es müssen von Anfang an mehrere Subnetze für die folgenden Traffic-Typen definiert werden:
- Subnetz für die Replikation, über das die Daten zwischen den Speichersystemen synchronisiert werden. Es kann mehrere davon geben; in diesem Fall ist es unerheblich, da alles von der aktuellen (bereits implementierten) Netzwerk-Topologie abhängt. Wenn es zwei gibt, muss offensichtlich die Routing zwischen ihnen eingerichtet werden;
- Subnetze für Datenspeicherung, über die Hosts auf die Ressourcen des Speichersystems zugreifen (wenn es iSCSI ist). Solche Subnetze sollten in jedem Rechenzentrum vorhanden sein;
- Verwaltungs-Subnetze, das heißt drei routbare Subnetze an drei Standorten, von denen aus die Verwaltung des Speichersystems erfolgt, und dort befindet sich auch der Schiedsrichter.
Subnetze für den Zugriff auf die Ressourcen der Hosts werden hier nicht betrachtet, da sie stark von den Aufgaben abhängen.
Die Trennung verschiedener Datenströme in unterschiedliche Subnetze ist äußerst wichtig (insbesondere ist es wichtig, die Replikation vom Ein- und Ausgang zu trennen). Wenn allen Datenverkehr in ein einziges "dickes" Subnetz gemischt wird, wird es unmöglich, diesen Verkehr zu verwalten, und unter den Bedingungen zweier Rechenzentren kann dies auch zu verschiedenen Arten von Netzwerk-Kollisionen führen. Wir werden nicht tief in dieses Thema einsteigen, da die Planung eines Netzwerks, das sich zwischen den Rechenzentren erstreckt, auf den Ressourcen der Netzwerkausrüstungshersteller sehr detailliert beschrieben ist.
Konfiguration des Schiedsrichters
Der Schiedsrichter muss Zugang zu allen Verwaltungsoberflächen des SAN über die Protokolle ICMP und SSH gewähren. Auch sollte über die Hochverfügbarkeit des Schiedsrichters nachgedacht werden. Hier gibt es einen Punkt zu beachten.
Die Hochverfügbarkeit des Schiedsrichters ist sehr wünschenswert, aber nicht zwingend erforderlich. Was passiert, wenn der Schiedsrichter nicht rechtzeitig ausfällt?
- Der Betrieb des Metroclusters im regulären Modus wird sich nicht ändern, da der Schiedsrichter keinen Einfluss auf den regulären Betrieb des Metroclusters hat (seine Aufgabe ist es, die Last rechtzeitig zwischen den Rechenzentren umzuschalten).
- Wenn der Schiedsrichter aus irgendeinem Grund ausfällt und im Rechenzentrum die Ereignisse verschläft, findet kein Umschalten statt, da niemand die erforderlichen Befehle für den Wechsel geben und ein Quorum organisieren kann. In diesem Fall verwandelt sich das Metro-Cluster in ein normales Replikationsschema, das während einer Katastrophe manuell umgeschaltet werden muss, was sich negativ auf die RTO auswirkt.
Was folgt daraus? Wenn tatsächlich ein minimaler RTO-Wert sichergestellt werden muss, ist die Redundanz des Schiedsrichters erforderlich. Dafür gibt es zwei Optionen:
- Eine virtuelle Maschine mit einem Redundanz-Schiedsrichter auf einem ausfallsicheren Hypervisor zu starten, da alle gängigen Hypervisoren Redundanz unterstützen;
- Falls an einem dritten Standort (zum Beispiel im Büro) kein normaler Cluster vorhanden ist und es keine bestehenden Hypervisor-Cluster gibt, haben wir eine hardwarebasierte Variante des Schiedsrichters vorgesehen, die in einem 2U-Rack untergebracht ist, in dem zwei Standard-x86-Server laufen und der lokale Ausfälle überstehen kann.
Wir empfehlen dringend, die Ausfallsicherheit des Arbiters sicherzustellen, auch wenn er im Normalbetrieb für das Metrocluster nicht erforderlich ist. Doch wie sowohl Theorie als auch Praxis zeigen, ist es besser, eine wirklich zuverlässige katastrophensichere Infrastruktur aufzubauen und auf Nummer sicher zu gehen. Schützen Sie sich und Ihr Unternehmen vor dem „Gesetz der Schikane“, d.h. vor dem gleichzeitigen Ausfall sowohl des Arbiters als auch einer der Plattformen, auf denen das SAN steht.
Architektur der Lösung
Unter Berücksichtigung der oben genannten Anforderungen erhalten wir die folgende Gesamtarchitektur der Lösung.
LUNs sollten gleichmäßig auf zwei Standorte verteilt werden, um eine starke Überlastung zu vermeiden. Dabei sollte bei der Dimensionierung in beiden Rechenzentren nicht nur das doppelte Volumen (notwendig für die gleichzeitige Speicherung von Daten auf zwei SANs) eingeplant werden, sondern auch die doppelte Leistung in IOPS und MB/s, um eine Degradierung der Anwendungen im Falle eines Ausfalls eines der Rechenzentren zu verhindern.
Es ist wichtig zu betonen, dass bei einer angemessenen Herangehensweise an das Sizing (das heißt, vorausgesetzt, wir haben die notwendigen Obergrenzen für IOPS und MB/s sowie die erforderlichen Ressourcen für CPU und RAM berücksichtigt) bei einem Ausfall einer der Storage-Systeme in einem Metro-Cluster keine signifikanten Leistungseinbußen auftreten werden, während wir vorübergehend nur auf einem Storage-System arbeiten.
Dies ist darauf zurückzuführen, dass die gleichzeitige Arbeit an zwei Standorten mit einer funktionierenden synchronen Replikation die Hälfte der Schreibleistung in Anspruch nimmt, da jede Transaktion auf zwei Storage-Systemen aufgezeichnet werden muss (ähnlich wie bei RAID-1/10). Bei einem Ausfall eines der Storage-Systeme entfällt vorübergehend (bis das ausgefallene Storage-System wieder betriebsbereit ist) der Einfluss der Replikation, was zu einer Verdopplung der Schreibleistung führt. Nachdem die LUNs des ausgefallenen Storage-Systems auf dem funktionierenden Storage-System neu gestartet wurden, geht dieser Leistungszuwachs verloren, da die Last von den LUNs des anderen Storage-Systems zurückkehrt und wir wieder das gleiche Leistungsniveau erreichen, das wir vor dem "Ausfall" hatten, jedoch jetzt innerhalb eines einzigen Standorts.
Durch eine durchdachte Größenanpassung kann sichergestellt werden, dass die Benutzer den Ausfall eines gesamten Speichersystems nicht einmal bemerken. Doch nochmals, dies erfordert ein äußerst präzises Sizing, bei dem Sie sich gerne kostenlos an uns wenden können :-).
Einrichtung des Metro-Clusters
Die Einrichtung des Metro-Clusters ähnelt stark der Einrichtung einer normalen Replikation, die wir in beschrieben haben. Daher konzentrieren wir uns nur auf die Unterschiede. Wir haben in unserem Labor eine Testumgebung eingerichtet, die auf der oben genannten Architektur basiert, jedoch in einer minimalen Variante: zwei Speichersysteme, die über 10G Ethernet miteinander verbunden sind, zwei 10G Switches und ein Host, der über die Switches auf beide Speichersysteme mit 10G-Ports zugreift. Der Schlichter läuft auf einer virtuellen Maschine.
Bei der Einrichtung von virtuellen IP-Adressen (VIP) für die Replikation sollte der VIP-Typ – für das Metro-Cluster – ausgewählt werden.
Wir haben zwei Replikationsverbindungen für zwei LUNs erstellt und sie auf zwei Speichersysteme verteilt: LUN TEST Primary auf Speichersystem 1 (Verbindung METRO), LUN TEST2 Primary für Speichersystem 2 (Verbindung METRO2).
Für diese haben wir zwei identische Targets eingerichtet (in unserem Fall iSCSI, aber auch FC wird unterstützt, die Logik der Einrichtung bleibt gleich).
Speichersystem 1:
Speichersystem 2:
Für die Replikationsverbindungen haben wir Mappings auf jedem Speichersystem vorgenommen.
Speichersystem 1:
Speichersystem 2:
Wir haben Multipath konfiguriert und auf dem Host demonstriert.
Wir konfigurieren den Arbiter.
Mit dem Arbiter selbst muss nicht viel gemacht werden, er muss einfach an dem dritten Standort aktiviert, mit einer IP konfiguriert und der Zugriff über ICMP und SSH eingerichtet werden. Die eigentliche Konfiguration erfolgt direkt von den Storage Arrays. Dabei genügt es, die Konfiguration des Arbiters einmalig an einem der Controller im Metrocluster vorzunehmen; diese Einstellungen werden automatisch auf alle Controller übertragen.
Im Abschnitt Remote-Replikation >> Metrocluster (an einem beliebigen Controller) >> die Schaltfläche „Konfigurieren“.
Geben Sie die IP des Arbiters sowie die Verwaltungs-Schnittstellen der beiden Controller des Remote-Speichers ein.
Danach müssen alle Dienste aktiviert werden (Schaltfläche „Alle neu starten“). Bei einer zukünftigen Umkonfiguration müssen die Dienste unbedingt neu gestartet werden, damit die Einstellungen wirksam werden.
Überprüfen Sie, ob alle Dienste ausgeführt werden.
Damit ist die Konfiguration des Metroclusters abgeschlossen.
Stresstest
Der Stresstest wird in unserem Fall relativ einfach und schnell sein, da die Funktionalität der Replikation (Failover, Konsistenz usw.) bereits behandelt wurde. . Daher reicht es für die Prüfung der Zuverlässigkeit des Metroclusters aus, die Automatisierung der Störfallentdeckung, des Switchings und das Fehlen von Verlusten beim Schreiben (Halt der E/A) zu überprüfen.
Zu diesem Zweck emulieren wir einen vollständigen Ausfall eines der Speicher-Systeme, indem wir beide Controller physisch ausschalten und zuvor eine große Datei auf das LUN kopieren, das auf dem anderen Speicher-System aktiviert werden soll.
Wir trennen ein Speicher-System. Auf dem zweiten Speicher-System sehen wir Warnungen und Meldungen in den Protokollen über den Verlust der Verbindung zum benachbarten System. Falls SMTP- oder SNMP-Überwachungen konfiguriert sind, erhält der Admin entsprechende Benachrichtigungen.
Genau nach 10 Sekunden (sichtbar auf beiden Screenshots) wurde die Replikationsverbindung METRO (die zuvor auf dem ausgefallenen Speicher-System als Primär galt) automatisch auf dem funktionierenden Speicher-System zur Primärverbindung. Durch die Aktivierung des bestehenden Mappings blieb LUN TEST für den Host verfügbar, die Schreibgeschwindigkeit verringerte sich leicht (im Rahmen der versprochenen 10 Prozent), aber wurde nicht unterbrochen.
Der Test wurde erfolgreich abgeschlossen.
Zusammenfassung
Die aktuelle Implementierung des Metroclusters in den AERODISK Engine N-Serie Storage-Systemen ermöglicht es vollständig, Aufgaben zu bewältigen, bei denen Ausfallzeiten der IT-Dienste ausgeschlossen oder minimiert werden müssen, und bietet einen Betrieb im 24/7/365-Modus mit minimalem Arbeitsaufwand.
Natürlich könnte man sagen, dass das alles Theorie ist, ideale Laborbedingungen und so weiter… ABER wir haben eine Reihe von Projekten realisiert, in denen wir die Funktionalität der Katastrophenresistenz implementiert haben, und die Systeme arbeiten hervorragend. Einer unserer recht bekannten Kunden, der genau zwei Speichersysteme in einer katastrophenresistenten Konfiguration nutzt, hat bereits seine Zustimmung zur Veröffentlichung von Informationen über das Projekt gegeben. Daher werden wir im nächsten Teil über die praktische Implementierung berichten.
Vielen Dank, wir freuen uns auf eine produktive Diskussion.
Quelle: habr.com
