Vorbereitungen oder DR unter Nutanix: Asynchrone Replikation



    Das Thema des Aufbaus fehlertoleranter Rechenzentren mit hyperkonvergenten Nutanix-Systemen ist sehr umfangreich. Um nicht nach oben zu springen und nicht langweilig zu werden, werden wir es in zwei Teile aufteilen. In der ersten gehen wir auf die Theorie und die "klassischen" Replikationsmethoden ein, in der zweiten auf unsere neue Funktion, die sogenannte Metro Availability, die Fähigkeit, einen synchron replizierten Metro-Cluster (Ballungsraum, Großstadt usw.) in einer Entfernung von bis zu 400 Kilometern zwischen Rechenzentren aufzubauen.

    Schon heute ist es sehr selten, „von vorne anzufangen“ und zu erklären, warum überhaupt ein Backup-Rechenzentrum benötigt wird. Wenn zum einen das Volumen und der Wert der in Rechenzentren gespeicherten Informationen gestiegen sind und zum anderen viele Lösungen zur Organisation der verteilten Datenspeicherung und -verarbeitung kostengünstiger und umfassender geworden sind, müssen Sie in der Regel nicht mehr erklären, warum ein Unternehmen ein Backup-Rechenzentrum benötigt. Aber Sie müssen sich immer noch ansehen, wie es ist und wie es gebraucht wird.


    Als junges Unternehmen, das "an der Spitze" auftaucht, hat sich Nutanix sofort auf die Notwendigkeit eines modernen Rechenzentrums konzentriert, das über ein Backup-Rechenzentrum und die richtige, multifunktionale Replikation verfügt. Deshalb auch in der jüngsten Lizenz, das mit jedem Nutanix-System geliefert wird und im Preis enthalten ist (wir nennen es Starter), verfügt bereits über umfassende Replikationstools. Dies unterscheidet Nutanix von vielen herkömmlichen Systemen, bei denen die Replikation häufig als Option angeboten wird und zusätzliche, oftmals erhebliche Kosten verursacht.
    Nicht so bei uns. Nutanix verfügt bereits über eine bidirektionale asynchrone Replikation. Die Bidirektionalität, mit der Sie beide Rechenzentren im Aktiv-Aktiv-Modus (und nicht wie üblich im Aktiv-Reserve-Modus) verwenden können, ist übrigens nicht bei allen Anbietern vorhanden.

    In der Welt der Replikationsmethoden ist es üblich, zwei Grundprinzipien ihrer Arbeit zu unterscheiden, die sogenannte „synchrone“ und die „asynchrone“ Replikation.
    Die synchrone Replikation ist einfach. Jeder Plattenschreibvorgang gilt erst dann als abgeschlossen, wenn derselbe Schreibvorgang auf den Platten des fernen Systems übertragen und abgeschlossen wurde. Der Datenblock ist angekommen, der Block hat auf die Datenträger des lokalen Speichergeräts geschrieben, aber die Anwendung hat noch keine Antwort "Bereit, Aufgezeichnet!" Erhalten. In der Zwischenzeit wurde der Datenblock auf das ferne System übertragen und der Aufzeichnungsprozess für diesen Block darauf gestartet. Und erst nachdem der Block auf dem fernen System aufgezeichnet wurde, meldet er den Erfolg, und dann informiert das System die Anwendung, deren Block aufgezeichnet wurde, das lokale erste System über den Abschluss der Aufzeichnung.



    Die Vorteile der synchronen Replikation liegen auf der Hand. Daten werden so sicher wie möglich auf die lokalen und fernen Systeme geschrieben: Die Kopie im Backup-Rechenzentrum ist immer vollständig identisch mit der Kopie in Ihrem lokalen Rechenzentrum. Es gibt jedoch ein Minus, obwohl es eines ist, es ist riesig.
    Wenn zwei Systeme durch synchrone Replikation verbunden sind, entspricht die Geschwindigkeit des aktiven lokalen Systems für Ihre Anwendung der Geschwindigkeit des Datenkanals zwischen dem lokalen und dem fernen System. Denn bis das ferne System einen Datenblock zum Schreiben empfängt und schreibt, steht Ihr lokales System und wartet. Und wenn Sie von der Anwendung auf die Festplatten des lokalen Systems 16G FC und vom lokalen System auf das entfernte - 1 GB Ethernet über den Kanal des Anbieters über mehrere Router - haben, überschreitet das Schreiben auf lokale Festplatten nicht die Geschwindigkeit dieses Gigabit-Ethernet-Kanals.

    Wenn diese Option nicht zu Ihnen passt, sollten Sie sich die asynchrone Replikation ansehen.
    Die asynchrone Replikation weist im Gegensatz dazu viele Nachteile auf, jedoch ein Plus. Aber groß. :)
    Bei der asynchronen Replikation erfolgt die Aufzeichnung auf den Laufwerken des lokalen Geräts unabhängig vom Status des fernen Systems. Anschließend werden sie mit der festgelegten Häufigkeit auf dieses ferne System übertragen und kopieren nicht die Vorgänge, sondern lediglich den Status der Laufwerke des lokalen Datenquellensystems. Dies ist vorteilhafter in Bezug auf die Leistung und die Kanalauslastung. Wenn beispielsweise die Anwendung den aktiven Datenbereich ständig liest und ändert, ist es häufig viel einfacher, das Ergebnis einmal zu übertragen, als Hunderte und Tausende aufeinanderfolgender Änderungen. Leider ist dies ein großes Plus, das mit der Tatsache einhergeht, dass eine asynchrone Kopie streng genommen nie vollständig mit den Daten des aktiven Systems übereinstimmt und immer die wenigen Minuten nachhängt, die für einen Replikationszyklus erforderlich sind.

    In der Praxis ist die asynchrone Replikation jedoch weit verbreitet. Was tun mit der "Ungenauigkeit der Kopie"? Zunächst können Sie sich vorstellen und beurteilen, dass die Schreibleistung und die niedrigen Latenzwerte des Systems für Sie wichtiger sind als der mögliche Verlust von 15 Minuten Datenänderungen (und das kommt häufig vor). Verwenden Sie neben der allgemeinen asynchronen Replikation für alle Anwendungen auch eine Datenschutzmaßnahme auf der Ebene bestimmter Anwendungen und nicht die Datenspeicherung im Allgemeinen (z. B. verschiedene Tools von Microsoft-Produkten, Verfügbarkeitsgruppen in MS Exchange oder ähnliche Tools) MS SQL Server).

    Grundsätzlich hat Nutanix hier nichts Neues erfunden. Auf Nutanix-Systemen gibt es sowohl eine synchrone Replikation, mit deren Hilfe die sogenannte Metro Availability implementiert wird, als auch eine asynchrone Replikation von einem Nutanix-Cluster in einem DC zu einem anderen, normalerweise in einem anderen DC. Die asynchrone Replikation wird durch die Übertragung von "Snapshots" des Festplattenspeichers durchgeführt, während die synchrone Replikation etwas komplizierter und kurioser ist.

    Ein paar Worte zu einigen terminologischen Zitaten.
    Das Wort „Cluster“, das heute von allen in einer Reihe verwendet wird, kann zu Schwierigkeiten führen, wenn nicht sogar zu falschen Vorstellungen. Tatsache ist, dass in der heutigen IT-Branche das Wort „Cluster“ nicht nur für sehr unterschiedliche Dinge in der Natur verwendet wird, sondern hauptsächlich für eine Struktur, die eine hohe Verfügbarkeit bietet. Und so oft bedeutet das Wort "Cluster" genau und nur "HA-Cluster", dass viele den Eindruck haben, dass "Cluster" = "ausfallsicherer Cluster", das ist alles.
    Dies ist nicht immer der Fall.

    Was ist ein Cluster?
    Ein Cluster ist eine Kombination einiger Elemente zu einer bestimmten allgemeinen Einheit höherer Ordnung, die als unabhängige Einheit besteht und verwaltet wird. Wie Sie sehen, hat diese Definition nichts mit Fehlertoleranz zu tun. Es kann vorhanden sein oder nicht, und ein Cluster ist nicht immer ein „HA-Cluster“.

    Ich muss oft die Frage beantworten: „Ist es uns möglich, die Knoten des Nutanix-Clusters auf verschiedene Standorte zu verteilen, damit wir zuverlässig sind?“ Die
    Antwort lautet hier: Theoretisch können Sie (natürlich nicht vergessen, dass Sie die Standorte dehnen müssen) Auch ein 10G-Kanalpaar für die Cluster-interne Kommunikation (auch dies ist heute noch möglich). In der Praxis wird dies jedoch nicht empfohlen, und im Allgemeinen möchten Sie dies nicht. Warum?

    Stellen wir uns der Analogie halber vor, dass ein Nutanix-Cluster eine Gruppe von Festplatten in einem mit einem FC-Array verbundenen Array ist. Hier haben wir Standort A und darauf befindet sich ein JBOD-Shelf und darin befinden sich ein Dutzend Laufwerke auf der FC und Standort B mit demselben Shelf und einem Dutzend Laufwerken, die alle zum gemeinsam genutzten FC-Netzwerk gehören. Und wir beschließen, eine RAID-Gruppe aus all diesen zwanzig Festplatten in eine RAID-5 oder 6 zu verwandeln. Theoretisch können wir das, warum nicht. Wir sehen, dass jeder JBOD als separates FC-Gerät zusammengeführt wird. Aber dann ist die Frage, was mit dem RAID passiert, wenn ein Bagger durch uns fährt, passiert etwas mit dem Netzwerk zwischen den Standorten?
    Nichts Gutes. Verluste von der Hälfte oder sogar von mindestens einem Drittel der Teilnehmer auf einmal halten höchstwahrscheinlich weder dem RAID noch in einer ähnlichen Situation dem Nutanix-Cluster stand.

    Aus diesem Grund müssen wir bei Gesprächen mit Benutzern über Cluster und Nutanix die Verwirrung minimieren und klarstellen, dass hier „Nutanix-Cluster“ und hier mit „Cluster“ „VMware HA-Cluster“ und hier „Real Application Cluster“ (RAC) gemeint sind ) Oracle-Datenbanken. Und das sind alles verschiedene Cluster, die oft hierarchisch übereinander angeordnet sind, und das ist völlig normal.

    Daher können wir die Knoten eines Nutanix-Clusters nicht auf Standorte verteilen , um Fehlertoleranz zu gewährleisten. Sie können jedoch die Knoten eines „Nutanix-Clusters“ an einem Standort und die Knoten des anderen („Nutanix-Clusters“) an einem anderen Standort anordnen und sie dann zu replizierten Beziehungen in der erforderlichen Richtung kombinieren, z. B. vom Haupt-DC zum Backup, von der Zentrale zu den Zweigstellen (und umgekehrt) oder sogar komplett in beide Richtungen.

    Причем, если это будет «синхронный» метрокластер, то поверх такой синхронно реплицируемой пары кластеров, которые, напомню, могут располагаться на расстоянии, в идеальном случае, до 400 километров (или, говоря техническим языком, нам надо, чтобы между сайтами roundtrip IP-пакета не превышал 5ms), а потом поверх этой метро-пары мы можем создать один кластер VMware, внутри которого виртуальные машины будут перезапускаться и мигрировать как на общем, едином дисковом хранилище, согласно политикам DRS, которые мы напишем. Но об этом я детальнее расскажу в следующей серии.

    Für die asynchrone Datenreplikation von einem Standort zu einem anderen verwendet Nutanix den internen Vmcaliber-Snapshot-Mechanismus. Wenn sie verwendet werden, wird nur der Differenzteil, eine Art Differenz des Inhalts des Plattencontainervolumens, über den Datenkanal zwischen den beiden Standorten übertragen. Der Unterschied zur vorherigen Übertragung wird vom Quellsystem übernommen, dann an den Remotereplikationsempfängerstandort gesendet und dort ausgeführt. Derzeit beträgt das Übertragungsintervall für die asynchrone Replikation von Nutanix 15 Minuten. Das heißt, im schlimmsten Fall können Sie nur 15 Minuten an Daten verlieren, während der Prozess im Gegensatz zur synchronen Replikation die Leistung nicht verringert und die Latenz bei der Arbeit mit Daten nicht erhöht.



    So verlässt alle 15 Minuten am DR-Standort das Diff der Festplatten des Hauptsystems, und dort dehnt es sich automatisch aus und rollt, wobei seine Relevanz erhalten bleibt. Wenn Sie das System im Haupt-DC verlieren, gehen im schlimmsten Fall die Datenänderungen innerhalb von 15 Minuten verloren.
    Aber was ist, wenn die Verzögerung von 15 Minuten zu groß ist und eine synchrone Replikation erforderlich ist?
    Dazu können Sie unsere Technologie Metro Availability verwenden. Dies ist der nächste Beitrag.

    Jetzt auch beliebt: