Versionshinweise
Hochverfügbarkeitspaare in AWS
Änderungen vorschlagen
PDFs
Eine Cloud Volumes ONTAP HA-Konfiguration (High Availability) bietet unterbrechungsfreien Betrieb und Fehlertoleranz. In AWS werden die Daten zwischen den beiden Nodes synchron gespiegelt.
HA-Komponenten
In AWS umfassen die Cloud Volumes ONTAP HA-Konfigurationen die folgenden Komponenten:
-
Zwei Cloud Volumes ONTAP Nodes, deren Daten synchron gespiegelt werden.
-
Eine Mediatorinstanz, die einen Kommunikationskanal zwischen den Nodes bereitstellt, um die Storage-Übernahme und die Giveback-Prozesse zu unterstützen.
Mediator
Hier einige wichtige Details zur Mediator-Instanz in AWS:
- Instanztyp
-
t3-Micro
- Festplatten
-
Zwei st1-Festplatten mit 8 gib und 4 gib
- Betriebssystem
-
Debian 11
Für Cloud Volumes ONTAP 9.10.0 und früher wurde Debian 10 auf dem Mediator installiert. - Upgrades
-
Bei einem Upgrade von Cloud Volumes ONTAP aktualisiert BlueXP auch die Mediator-Instanz nach Bedarf.
- Zugriff auf die Instanz
-
Wenn Sie ein Cloud Volumes ONTAP HA-Paar aus BlueXP erstellen, werden Sie aufgefordert, ein Schlüsselpaar für die Instanz des Mediators bereitzustellen. Sie können dieses Schlüsselpaar für SSH-Zugriff mit verwenden
adminBenutzer: - Agenten von Drittanbietern
-
Agents von Drittanbietern oder VM-Erweiterungen werden auf der Mediator-Instanz nicht unterstützt.
Storage-Übernahme und -Giveback
Wenn ein Node ausfällt, kann der andere Node Daten für seinen Partner bereitstellen, um einen kontinuierlichen Datenservice bereitzustellen. Clients können vom Partner-Node aus auf dieselben Daten zugreifen, da die Daten synchron zum Partner gespiegelt wurden.
Nachdem der Node neu gestartet wurde, muss der Partner die Daten neu synchronisieren, bevor er den Storage zurückgeben kann. Die Zeit, die für die Neusynchronisierung von Daten benötigt wird, hängt davon ab, wie viele Daten während des Herunterfahrens des Node geändert wurden.
Storage-Übernahme, -Resynchronisierung und -Rückgabe sind standardmäßig automatisch erfolgt. Es ist keine Benutzeraktion erforderlich.
RPO und RTO
Eine HA-Konfiguration sorgt wie folgt für die Hochverfügbarkeit Ihrer Daten:
-
Das Recovery Point Objective (RPO) beträgt 0 Sekunden. Ihre Daten sind transaktionskonsistent und ohne Datenverlust.
-
Die Recovery-Zeitvorgabe (RTO) beträgt 120 Sekunden. Bei einem Ausfall sollten die Daten in maximal 120 Sekunden verfügbar sein.
Ha-Bereitstellungsmodelle
Sie können die Hochverfügbarkeit Ihrer Daten sicherstellen, indem Sie eine HA-Konfiguration über mehrere Verfügbarkeitszonen hinweg oder in einer einzelnen Verfügbarkeitszone (AZ) bereitstellen. Sie sollten weitere Details zu jeder Konfiguration durchgehen, um zu entscheiden, welche für Ihre Anforderungen am besten geeignet ist.
Verfügbarkeitszonen
Durch die Implementierung einer HA-Konfiguration in mehreren Verfügbarkeitszonen (AZS) werden Ihre Daten bei einem Ausfall mit einer Verfügbarkeitszone oder einer Instanz, auf der ein Cloud Volumes ONTAP-Node ausgeführt wird, Hochverfügbarkeit sichergestellt. Sie sollten wissen, wie sich NAS-IP-Adressen auf den Datenzugriff und das Storage-Failover auswirken.
NFS- und CIFS-Datenzugriff
Wenn eine HA-Konfiguration über mehrere Verfügbarkeitszonen verteilt ist, aktivieren fließende IP-Adressen den NAS-Client-Zugriff. Die unverankerten IP-Adressen, die für alle VPCs in der Region außerhalb der CIDR-Blöcke liegen müssen, können bei Ausfällen zwischen Nodes migrieren. Für Clients außerhalb der VPC sind sie nicht nativ zugänglich, es sei denn, Sie "AWS Transit Gateway einrichten".
Wenn Sie kein Transit-Gateway einrichten können, sind private IP-Adressen für NAS-Clients außerhalb der VPC verfügbar. Diese IP-Adressen sind jedoch statisch und können nicht zwischen Nodes ein Failover ausführen.
Sie sollten die Anforderungen für fließende IP-Adressen und Routingtabellen überprüfen, bevor Sie eine HA-Konfiguration über mehrere Verfügbarkeitszonen hinweg implementieren. Sie müssen die unverankerten IP-Adressen angeben, wenn Sie die Konfiguration bereitstellen. Die privaten IP-Adressen werden automatisch von BlueXP erstellt.
Weitere Informationen finden Sie unter "AWS Netzwerkanforderungen für Cloud Volumes ONTAP HA in mehreren AZS".
ISCSI-Datenzugriff
VPC-übergreifende Datenkommunikation ist kein Problem, da iSCSI keine Floating-IP-Adressen verwendet.
Takeover und Giveback für iSCSI
Für iSCSI verwendet Cloud Volumes ONTAP Multipath I/O (MPIO) und Asymmetric Logical Unit Access (ALUA), um das Pfad-Failover zwischen den Aktiv- und Nicht-optimierten Pfaden zu managen.
|
|
Informationen darüber, welche spezifischen Host-Konfigurationen ALUA unterstützen, finden Sie im "NetApp Interoperabilitäts-Matrix-Tool" und im "Leitfaden für SAN-Hosts und Cloud-Clients" für Ihr Host-Betriebssystem. |
Takeover und Giveback für NAS
Wenn die Übernahme in einer NAS-Konfiguration mithilfe von Floating IPs erfolgt, stellt die fließende IP-Adresse des Node dar, über die Clients auf die zu verschiebenden Daten auf den anderen Node zugreifen. Die folgende Abbildung zeigt die Storage-Übernahme in einer NAS-Konfiguration mit Floating-IPs. Wenn Node 2 ausfällt, wird die unverankerte IP-Adresse für Node 2 zu Node 1 verschoben.
NAS-Daten-IPs, die für den externen VPC-Zugriff verwendet werden, können nicht zwischen Nodes migriert werden, wenn Fehler auftreten. Wenn ein Node offline geht, müssen Sie Volumes manuell über die IP-Adresse auf dem anderen Node auf Clients außerhalb des VPC neu mounten.
Nachdem der ausgefallene Node wieder online ist, mounten Sie Clients mit der ursprünglichen IP-Adresse erneut auf Volumes. Dieser Schritt ist erforderlich, um die Übertragung unnötiger Daten zwischen zwei HA-Nodes zu vermeiden, was erhebliche Auswirkungen auf die Performance und Stabilität haben kann.
Sie können die richtige IP-Adresse von BlueXP leicht erkennen, indem Sie die Lautstärke auswählen und auf Mount Command klicken.
Einzelne Verfügbarkeitszone
Die Implementierung einer HA-Konfiguration in einer einzelnen Verfügbarkeitszone (AZ) kann die Hochverfügbarkeit Ihrer Daten gewährleisten, wenn eine Instanz, auf der ein Cloud Volumes ONTAP Node ausgeführt wird, ausfällt. Alle Daten sind nativ von außerhalb des VPC zugänglich.
|
|
BlueXP erstellt eine "AWS Spread-Platzierungsgruppe" Und startet die beiden HA-Nodes in dieser Platzierungsgruppe. Die Platzierungsgruppe verringert das Risiko gleichzeitiger Ausfälle, indem sie die Instanzen auf unterschiedliche zugrunde liegende Hardware verteilt. Diese Funktion verbessert die Redundanz aus Sicht des Computing und nicht aus Sicht des Festplattenausfalls. |
Datenzugriff
Da sich diese Konfiguration in einer einzigen AZ befindet, sind keine gleitenden IP-Adressen erforderlich. Sie können dieselbe IP-Adresse für den Datenzugriff innerhalb des VPC und außerhalb des VPC verwenden.
Die folgende Abbildung zeigt eine HA-Konfiguration in einer einzigen AZ. Der Zugriff auf die Daten erfolgt innerhalb des VPC und außerhalb des VPC.
Takeover und Giveback
Für iSCSI verwendet Cloud Volumes ONTAP Multipath I/O (MPIO) und Asymmetric Logical Unit Access (ALUA), um das Pfad-Failover zwischen den Aktiv- und Nicht-optimierten Pfaden zu managen.
|
|
Informationen darüber, welche spezifischen Host-Konfigurationen ALUA unterstützen, finden Sie im "NetApp Interoperabilitäts-Matrix-Tool" und im "Leitfaden für SAN-Hosts und Cloud-Clients" für Ihr Host-Betriebssystem. |
Bei NAS-Konfigurationen können die Daten-IP-Adressen zwischen HA-Nodes migriert werden, wenn Fehler auftreten. Dadurch wird der Client-Zugriff auf Storage gewährleistet.
AWS lokale Zonen
AWS Local Zones sind eine Infrastrukturimplementierung, bei der Storage, Computing, Datenbanken und andere ausgewählte AWS Services in der Nähe von großen Städten und Branchenbereichen liegen. Mit AWS Local Zones bringen Sie AWS Services näher und verbessern so die Latenz Ihrer Workloads und pflegen Datenbanken lokal.
Sie können eine einzelne AZ- oder mehrere AZ-Konfiguration in AWS Local Zones implementieren.
|
|
AWS Local Zones werden beim Einsatz von BlueXP im Standardmodus unterstützt. Derzeit werden AWS Lokale Zonen nicht unterstützt, wenn BlueXP im eingeschränkten Modus oder im privaten Modus verwendet wird. |
Beispielkonfigurationen für die AWS Local Zone
Im Folgenden sind Beispielkonfigurationen aufgeführt:
-
Einzelne Verfügbarkeitszone: Beide Clusterknoten und der Mediator befinden sich in derselben lokalen Zone.
-
Verfügbarkeitszonen
In Konfigurationen mit mehreren Verfügbarkeitszonen gibt es drei Instanzen, zwei Nodes und einen Mediator. Eine der drei Instanzen muss sich in einer separaten Zone befinden. Sie können wählen, wie Sie dies einrichten.Hier sind drei Beispielkonfigurationen:
-
Jeder Clusterknoten befindet sich in einer anderen lokalen Zone und der Mediator befindet sich in einer öffentlichen Verfügbarkeitszone.
-
Ein Clusterknoten in einer lokalen Zone, der Mediator in einer lokalen Zone und der zweite Clusterknoten befinden sich in einer Verfügbarkeitszone.
-
Jeder Clusterknoten und der Mediator befinden sich in separaten lokalen Zonen.
-
Unterstützte Festplatten- und Instanztypen
Der einzige unterstützte Festplattentyp ist GP2.
Die folgenden EC2 Instanztypen mit den Größen xlarge bis 4xlarge werden derzeit unterstützt:
-
M5
-
C5
-
C5d
-
R5
-
R5d
Die neuesten und vollständigen Details zum unterstützten finden Sie in der AWS-Dokumentation"EC2-Instanztypen in lokalen Zonen".
Funktionsweise von Storage in einem HA-Paar
Im Gegensatz zu einem ONTAP Cluster wird Storage in einem Cloud Volumes ONTAP HA Paar nicht zwischen Nodes geteilt. Stattdessen werden die Daten synchron zwischen den Nodes gespiegelt, sodass sie im Falle eines Ausfalls verfügbar sind.
Storage-Zuweisung
Wenn Sie ein neues Volume erstellen und zusätzliche Festplatten erforderlich sind, weist BlueXP beiden Nodes die gleiche Anzahl an Festplatten zu, erstellt ein gespiegeltes Aggregat und erstellt dann das neue Volume. Wenn zum Beispiel zwei Festplatten für das Volume benötigt werden, weist BlueXP zwei Festplatten pro Node zu insgesamt vier Festplatten zu.
Storage-Konfigurationen
Sie können ein HA-Paar als Aktiv/Aktiv-Konfiguration verwenden, in der beide Nodes Daten an Clients bereitstellen, oder als Aktiv/Passiv-Konfiguration, bei der der passive Node nur dann auf Datenanforderungen reagiert, wenn er Storage für den aktiven Node übernommen hat.
|
|
Sie können eine aktiv/aktiv-Konfiguration nur einrichten, wenn Sie BlueXP in der Storage System-Ansicht verwenden. |
Leistungserwartungen
Eine Cloud Volumes ONTAP HA-Konfiguration repliziert Daten synchron zwischen Nodes, wodurch Netzwerkbandbreite verbraucht wird. Daher können Sie im Vergleich zu einer Single Node Cloud Volumes ONTAP Konfiguration folgende Performance erwarten:
-
Bei HA-Konfigurationen, die Daten von nur einem Node bereitstellen, ist die Lese-Performance mit der Lese-Performance einer Single-Node-Konfiguration vergleichbar, während die Schreib-Performance geringer ist.
-
Bei HA-Konfigurationen, die Daten von beiden Nodes verarbeiten, ist die Lese-Performance höher als die Lese-Performance einer Single-Node-Konfiguration, und die Schreib-Performance ist gleich oder höher.
Weitere Informationen zur Performance von Cloud Volumes ONTAP finden Sie unter "Leistung".
Client-Zugriff auf Storage
Clients sollten über die Daten-IP-Adresse des Node, auf dem sich das Volume befindet, auf NFS- und CIFS-Volumes zugreifen. Wenn NAS-Clients über die IP-Adresse des Partner-Node auf ein Volume zugreifen, wird der Datenverkehr zwischen beiden Nodes geleitet, wodurch die Performance verringert wird.
|
Wenn Sie ein Volume zwischen Nodes in einem HA-Paar verschieben, sollten Sie das Volume mithilfe der IP-Adresse des anderen Node neu mounten. Andernfalls kann die Performance beeinträchtigt werden. Wenn Clients NFSv4-Verweise oder Ordnerumleitung für CIFS unterstützen, können Sie diese Funktionen auf den Cloud Volumes ONTAP Systemen aktivieren, um ein erneutes Mounten des Volumes zu vermeiden. Details hierzu finden Sie in der ONTAP-Dokumentation. |
Sie können die richtige IP-Adresse einfach über die Option „Mount Command“ im Bereich „Volumes verwalten“ in BlueXP identifizieren.
