Freigeben über

Stretchingcluster: Übersicht

  • Artikel

Gilt für: Azure Local, Version 22H2

Wichtig

Azure Stack HCI ist jetzt Teil von Azure Local. Die Umbenennung der Produktdokumentation wird ausgeführt. Ältere Versionen von Azure Stack HCI, z. B. 22H2, verweisen jedoch weiterhin auf Azure Stack HCI und spiegeln die Namensänderung nicht wider. Weitere Informationen

Wichtig

Gestreckte Cluster werden in Azure Local, Version 23H2, nicht unterstützt.

Eine gestreckte Clusterlösung für Azure Stack HCI für die Notfallwiederherstellung bietet automatisches Failover, um die Produktion schnell und ohne manuelle Eingriffe 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 Standorte außerhalb der Metropolbereiche über Netzwerkverbindungen mit höheren Latenzen hinweg, ohne jedoch zu gewährleisten, dass beide Standorte zum Zeitpunkt eines Ausfalls identische Kopien der Daten aufweisen. Wenn die Replikation vor dem Fehler abgeschlossen ist, wird das Zielvolume automatisch nach einem Failover online. Wenn die Replikation zum Zeitpunkt des Ausfalls ausgeführt wird, 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 mit zwei Standorten bieten Notfallwiederherstellung und Geschäftskontinuität, wenn ein Standort einen Ausfall oder Einen Fehler verursacht.

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 des aktiven/passiven gestreckten Clusters.

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. In der Regel gibt es vier verschiedene Möglichkeiten zum Ändern der IP-Adresse auf dem virtuellen Computer beim Failover. Möglicherweise gibt es andere, aber in diesem Artikel werden die ersten vier behandelt.

Die erste und einfachste Option ist die Verwendung von DHCP. Beim Verschieben eines virtuellen Computers von einem Standort zu einem anderen fordert die VM eine DHCP-Adresse an. Dadurch wird die richtige IP-Adresse für den Standort abgerufen, auf dem er sich befindet, solange 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 die richtige IP-Adresse für den virtuellen Computer zuzuweisen, je nachdem, auf welcher Website es sich befindet. Angenommen, Standort A verwendet ein 1.x-Netzwerk und Standort B ein 156.x-Netzwerk. Dieses Skript muss das Netzwerk erkennen, auf dem der virtuelle Computer aktiviert ist, und ein 1.x-IP-Adressschema festlegen, wenn es sich in SiteA oder einem 156.x-IP-Adressschema befindet, wenn es sich in SiteB befindet. Die Domänennamendienste (Domain Name Services, DNS) müssen auch auf die Änderung hingewiesen und zwischen den Websites repliziert werden.

Eine weitere Option ist die Verwendung eines zwischengeschalteten Netzwerkgeräts, das eine einzelne IP-Adresse für den virtuellen Computer für die Clientkonnektivität bereitstellt, die den Datenverkehr an den virtuellen Computer weiterleiten kann. Clients und DNS verfügen immer über dieselbe Adresse für den virtuellen Computer, und das zwischengeschaltete Gerät muss die tatsächliche IP-Adresse und den Standort des virtuellen Computers nachverfolgen, sodass Clients entsprechend an den virtuellen Computer 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