Stretchingcluster: Übersicht

  • Artikel

Gilt für: Azure Stack HCI, Versionen 22H2 und 21H2

Eine Azure Stack HCI-Clusterlösung für die Notfallwiederherstellung bietet ein automatisches Failover, um die Produktion schnell und ohne manuellen Eingriff wiederherzustellen. Speicherreplikation bietet die standortübergreifende Replikation von Volumes zur Notfallwiederherstellung, wobei alle Server synchron bleiben.

Speicherreplikation unterstützt sowohl synchrone als auch asynchrone Replikation:

  • Bei der synchronen Replikation werden Daten von absturzkonsistenten Volumes standortübergreifend in einem Netzwerk mit geringer Latenz gespiegelt, um während eines Ausfalls Datenverlust auf der Dateisystemebene auszuschließen.
  • Die asynchrone Replikation spiegelt Daten über Netzwerkverbindungen mit höheren Latenzen hinweg standortübergreifend, aber ohne Garantie, dass beide Standorte zum Zeitpunkt eines Fehlers identische Kopien der Daten aufweisen. Wenn die Replikation vor dem Fehler abgeschlossen ist, wird das Zielvolume nach dem Failover automatisch online geschaltet. Wenn die Replikation zum Zeitpunkt des Fehlers in Bearbeitung ist, müssen Sie das Zielvolume manuell online schalten.

Es gibt zwei Arten von Stretchingclustern, aktiv-passiv und aktiv-aktiv. Sie können eine aktiv-passive Standortreplikation einrichten, bei der es einen bevorzugten Standort und eine Replikationsrichtung gibt. Die aktiv-aktive Replikation kann bidirektional von beiden Standorten aus erfolgen. In diesem Artikel wird nur die aktiv/passive Konfiguration behandelt.

Einfach ausgedrückt ist ein aktiver Standort einer, der über Ressourcen und Workloads verfügt, mit denen Clients Verbindungen herstellen können. Ein passiver Standort stellt keine Rollen oder Workloads für Clients bereit und wartet für die Notfallwiederherstellung auf ein Failover vom aktiven Standort.

Die Standorte können in zwei verschiedenen Staaten, verschiedenen Ländern, auf verschiedenen Etagen oder in verschiedenen Räumen liegen. Gestreckte Cluster, die zwei Standorte verwenden, bieten Notfallwiederherstellung und Geschäftskontinuität, falls ein Standort ausfällt oder ausfällt.

Nehmen Sie sich einige Minuten Zeit, um sich das Video zum Verwenden von Stretched Clustern mit Azure Stack HCI anzusehen:

Aktiv-passiver Stretchingcluster

Im folgenden Diagramm ist Standort 1 als der aktive Standort mit Replikation zu Standort 2 dargestellt, also einer unidirektionalen Replikation.

Szenario für aktiv/passiv gestreckte Cluster.

Aktiv-aktiver Stretchingcluster

Im folgenden Diagramm sind sowohl Standort 1 als auch Standort 2 als aktive Standorte mit bidirektionaler Replikation zum anderen Standort dargestellt.

Szenario mit einem aktiv-aktiven Stretchingcluster

Überlegungen zum Gast-IP-Failover

Im Zusammenhang mit Stretchclustering müssen u. a. die verwendeten VMs und IP-Adressen berücksichtigt werden. Rechenzentren, die sich an unterschiedlichen Standorten befinden, verfügen in der Regel über unterschiedliche IP-Subnetze. Die von den VMs verwendeten IP-Adressen sind in diesen Fällen für ein Rechenzentrum geeignet, in einem anderen aber nicht erreichbar. Daher muss der Umgang mit IP-Adressänderungen geplant werden. Im Allgemeinen gibt es vier verschiedene Möglichkeiten, wie die Änderung der IP-Adresse auf der VM bei einem Failover gehandhabt werden kann. Unter Umständen gibt es weitere Möglichkeiten, in diesem Dokument werden jedoch nur die vier wichtigsten Optionen behandelt.

Die erste und einfachste Option ist die Verwendung von DHCP. Wenn eine VM von einem Standort an einen anderen verschoben wird, fordert sie eine DHCP-Adresse an. Dadurch wird die richtige IP-Adresse für den jeweiligen Standort abgerufen, sofern ein DHCP-Server verfügbar ist.

Die nächste Option ist die Verwendung einer statischen Adresse. Anders als beim Hyper-V-Replikat ist es jedoch nicht möglich, eine alternative IP-Adresse anzugeben. Daher muss ein Skript erstellt werden, um je nach Standort die richtige IP-Adresse für die VM zuzuweisen. Angenommen, Standort A verwendet ein 1.x-Netzwerk und Standort B ein 156.x-Netzwerk. Das Skript muss das Netzwerk der VM erkennen und ein 1.x-IP-Adressschema festlegen, wenn sich die VM an Standort A befindet, oder ein 156.x-IP-Adressschema, wenn sie sich an Standort B befindet. Die Domain Name Services (DNS) müssen ebenfalls über die Änderung benachrichtigt und zwischen den Standorten repliziert werden.

Eine weitere Option ist die Verwendung eines zwischengeschalteten Netzwerkgeräts, das für die Clientkonnektivität eine einzelne IP-Adresse für die VM bereitstellt und den Datenverkehr an die VM an den Standort weiterleiten kann, an dem diese sich derzeit befindet. Clients und DNS verfügen immer über die gleiche Adresse für die VM, und das zwischengeschaltete Gerät muss die tatsächliche IP-Adresse und den Standort der VM nachverfolgen, damit Clients entsprechend an die VM weitergeleitet werden.

Die letzte Option ist die Verwendung eines Stretching-VLAN. Bei einem Stretching-VLAN können VMs unabhängig vom Standort die gleiche IP-Adresse behalten. Da die Konfiguration und Wartung eines Stretching-VLAN recht komplex ist, wird diese Option jedoch nicht von Microsoft empfohlen.

Bei jeder der obigen Optionen müssen zusätzliche Überlegungen hinsichtlich der Clientkonnektivität (DNS, ARP-Caches, TTL usw.) gründlich durchdacht werden. Ermitteln Sie zusammen mit Ihrem Netzwerkteam die beste Option für Ihre Anforderungen.

Nächste Schritte