Entwerfen von vSAN Stretched Clustern

In diesem Artikel erfahren Sie, wie Sie einen vSAN Stretched Cluster für eine private Azure VMware Solution-Cloud entwerfen.

Hintergrund

Die globale Infrastruktur von Azure ist in Regionen unterteilt. Jede Region unterstützt die Dienste für eine bestimmte Geografie. Innerhalb jeder Region richtet Azure isolierte und redundante Infrastrukturinseln ein, die als Verfügbarkeitszonen (VZ) bezeichnet werden. Ein Verfügbarkeitszone fungiert als Grenze für die Ressourcenverwaltung. Die Computeressourcen und anderen Ressourcen, die einer Verfügbarkeitszone (VZ) zur Verfügung stehen, sind endlich und können durch die Kundenanforderungen erschöpft werden. Eine Verfügbarkeitszone ist so aufgebaut, dass sie unabhängig und resilient ist, d. h. Ausfälle in einer Verfügbarkeitszone haben keine Auswirkungen auf andere Verfügbarkeitszonen.

Bei Azure VMware Solution befinden sich ESXi-Hosts, die in einem vSphere-Standardcluster bereitgestellt werden, üblicherweise in einer einzigen Azure-Verfügbarkeitszone und sind durch vSphere High Availability (HA) geschützt. Allerdings schützt dies die Workloads nicht vor einem Ausfall einer Azure-Verfügbarkeitszone. Zum Schutz vor dem Ausfall einer Verfügbarkeitszone kann ein einzelner vSAN-Cluster aktiviert werden, der sich über zwei separate Verfügbarkeitszonen erstreckt, ein sogenannter vSAN Stretched Cluster.

Ein solcher Stretched Cluster ermöglicht es, vSAN-Fehlerdomänen über zwei Verfügbarkeitszonen hinweg zu konfigurieren, um vCenter Server über das Vorhandensein von Hosts in jeder Verfügbarkeitszone zu informieren. Zur besseren Übersichtlichkeit wird jede Fehlerdomäne nach der Verfügbarkeitszone benannt, in der sie sich befindet. Wenn Sie einen vSAN-Cluster über zwei Verfügbarkeitszonen innerhalb einer Region strecken, wird der Ausfall einer Verfügbarkeitszone als vSphere HA-Ereignis behandelt, und die VM wird in der anderen Verfügbarkeitszone neu gestartet.

Stretched Cluster: Vorteile

  • Verbesserte Verfügbarkeit von Anwendungen.
  • Erzielen eines Null-RPO-Werts (Recovery Point Objective) für Unternehmensanwendungen, ohne dass diese umgestaltet oder teure Notfallwiederherstellungslösungen bereitgestellt werden müssen.
  • Eine private Cloud, die Stretched Cluster enthält, ist so konzipiert, dass sie aufgrund ihrer Resilienz gegen Verfügbarkeitszonenausfälle eine Verfügbarkeit von 99,99 % bietet.
  • Kunden können sich auf die wichtigsten Anwendungsanforderungen und -funktionen konzentrieren, statt auf die Verfügbarkeit der Infrastruktur.

Zum Schutz vor Split-Brain-Szenarien und zur Messung der Standortintegrität wird ein verwalteter vSAN-Zeuge in einer dritten Verfügbarkeitszone erstellt. Da jede Verfügbarkeitszone über eine Kopie der Daten verfügt, versucht vSphere HA, jeden Ausfall durch einen einfachen Neustart der VM auszugleichen.

Die folgende Abbildung zeigt einen vSAN-Cluster, der sich über zwei Verfügbarkeitszonen erstreckt.

Abbildung: Ein verwalteter vSAN Stretched Cluster, der in einer dritten Verfügbarkeitszone erstellt wurde, wobei die Daten in alle drei Zonen kopiert wurden.

Zusammenfassend lässt sich sagen, dass Stretched Cluster eine einfachere Erfüllung von Schutzanforderungen ermöglichen, da sie zusätzlich zur Skalierbarkeit und Flexibilität der Azure-Infrastruktur die gleichen vertrauenswürdigen Steuerelemente und Funktionen bieten.

Es ist wichtig zu verstehen, dass eine private Cloud mit einem Stretched Cluster nur eine zusätzliche Resilienzebene darstellt und nicht alle Ausfallszenarien abdeckt. Beispiel: private Cloud mit Stretched Cluster

  • Bietet keinen Schutz vor Ausfällen auf Regionsebene innerhalb von Azure oder gegen Datenverluste, die durch Anwendungsprobleme oder unzureichend geplante Speicherrichtlinien verursacht werden.
  • Bietet Schutz beim Ausfall einer einzelnen Zone, ist aber nicht für den Schutz bei doppelten oder progressiven Ausfällen ausgelegt. Beispiel:
    • Trotz verschiedener in das Fabric integrierter Redundanzebenen beginnt vSphere HA mit dem Abschalten der Workload-VMs am sekundären Standort, wenn ein Ausfall zwischen den Verfügbarkeitszonen zu einer Partitionierung des sekundären Standorts führt.

      Die folgende Abbildung zeigt das Szenario der Partitionierung des sekundären Standorts.

      Abbildung: vSphere HA schaltet die Workload-VMs am sekundären Standort ab.

    • Wenn die Partitionierung des sekundären Standorts stattdessen zum Ausfall des primären Standorts oder zu einer vollständigen Partitionierung führt, würde vSphere HA versuchen, die Workload-VMs auf dem sekundären Standort neu zu starten. Der Versuch von vSphere HA, die Workload-VMs am sekundären Standort neu zu starten, würde die Workload-VMs in einen instabilen Zustand versetzen.

      Die folgenden Diagramme zeigen die bevorzugten Szenarien für einen Standortausfall oder eine vollständige Netzwerkpartitionierung.

      Das Diagramm zeigt, dass die vSphere-Hochverfügbarkeit versucht, die Workload-VMs am sekundären Standort neu zu starten, wenn der bevorzugte Standort ausfällt.

      Das Diagramm zeigt, dass die vSphere-Hochverfügbarkeit versucht, die Workload-VMs am sekundären Standort neu zu starten, wenn eine vollständige Netzwerkisolation auftritt.

Diese Art von Ausfällen ist zwar selten, liegt jedoch außerhalb des Schutzes, den eine private Cloud mit einem Stretched Cluster bietet. Aufgrund dieser seltenen Ausfallarten sollte eine Stretched Cluster-Lösung als eine Hochverfügbarkeitslösung mit mehreren Verfügbarkeitszonen betrachtet werden, die auf vSphere HA angewiesen ist. Es ist wichtig zu beachten, dass eine Stretched Cluster-Lösung nicht dazu gedacht ist, eine umfassende Notfallwiederherstellungsstrategie für mehrere Regionen zu ersetzen, die zur Gewährleistung der Anwendungsverfügbarkeit eingesetzt werden kann. Dies liegt daran, dass eine Lösung für die Notfallwiederherstellung in der Regel über getrennte Verwaltungs- und Steuerungsebenen in separaten Azure-Regionen verfügt. Azure VMware Solution Stretched Cluster nutzen eine einzige Verwaltungs- und Steuerungsebene, die sich über zwei Verfügbarkeitszonen innerhalb derselben Azure-Region erstreckt. Beispiel: eine vCenter Server-Instanz, ein NSX Manager-Cluster, ein NSX Edge-VM-Paar.

Regionen, in denen Stretched Cluster verfügbar sind

Azure VMware Solution Stretched Cluster sind in den folgenden Regionen verfügbar:

  • Vereinigtes Königreich, Süden (für AV36 und AV36P)
  • Europa, Westen (für AV36 und AV36P)
  • Deutschland, Westen-Mitte (für AV36 und AV36P)
  • Australien, Osten (für AV36P)
  • USA, Osten (auf AV36P)

Unterstützte Speicherrichtlinien

Es werden folgende SPBM-Richtlinien unterstützt, wobei als Standardrichtlinien für den Cluster die PFTT-Einstellung „Duale Standortspiegelung“ und die SFTT-Einstellung „RAID 1 (Spiegelung)“ aktiviert sind:

  • Toleranzeinstellungen bei Standortnotfall (PFTT):
    • Duale Standortspiegelung
    • Keine: Daten am bevorzugten Standort beibehalten
    • Keine: Daten am nicht bevorzugten Standort beibehalten
  • Lokal tolerierbare Ausfälle (SFTT):
    • 1 Ausfall: RAID 1 (Spiegelung)
    • Ein Ausfall: RAID 5 (Erasure Coding), erfordert mindestens vier Hosts in jeder VZ
    • 2 Ausfälle: RAID 1 (Spiegelung)
    • Zwei Ausfälle: RAID 6 (Erasure Coding), erfordert mindestens sechs Hosts in jeder VZ
    • 3 Ausfälle: RAID 1 (Spiegelung)

Häufig gestellte Fragen

Sind weitere Regionen geplant?

Derzeit werden für Stretched Cluster vier Regionen unterstützt.

Welche Art von Vereinbarung zum Servicelevel (Service Level Agreement, SLA) bietet Azure VMware Solution für Stretched Cluster?

Eine private Cloud, die mit einem vSAN Stretched Cluster erstellt wurde, ist so konzipiert, dass sie unter den folgenden Bedingungen eine Infrastrukturverfügbarkeit von 99,99 % gewährleistet:

  • Es werden mindestens sechs Knoten im Cluster bereitgestellt (drei in jeder Verfügbarkeitszone).
  • Für die Workload-VMs werden eine VM-Speicherrichtlinie mit der PFTT-Einstellung „Duale Standortspiegelung“ und der SFTT-Wert 1 verwendet.
  • Zum Erreichen der Verfügbarkeitsziele müssen die zusätzlichen Anforderungen in den SLA-Details zu Azure VMware Solution eingehalten werden.

Kann ich die Verfügbarkeitszone auswählen, in der eine private Cloud bereitgestellt wird?

Nein Ein Stretched Cluster wird zwischen zwei Verfügbarkeitszonen erstellt, während die dritte Zone für die Bereitstellung des Zeugenknotens verwendet wird. Da alle Zonen für die Bereitstellung einer Stretched Cluster-Umgebung verwendet werden, hat der Kunde keine Auswahlmöglichkeit. Stattdessen entscheidet der Kunde während der Erstellung der privaten Cloud über die Bereitstellung von Hosts in mehreren Verfügbarkeitszonen.

Welche Einschränkungen muss ich beachten?

  • Sobald eine private Cloud mit einem Stretched Cluster erstellt wurde, kann sie nicht mehr in eine private Cloud mit Standardcluster umgewandelt werden. Ebenso kann eine private Cloud aus einem Standardcluster nach der Erstellung nicht in eine private Cloud mit einem Stretched Cluster geändert werden.
  • Stretched Cluster können nur paarweise auf- und abskaliert werden. In einer Stretched Cluster-Umgebung werden mindestens sechs Knoten und maximal 16 Knoten unterstützt. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements, -Dienste und -Kontingente sowie allgemeine Beschränkungen.
  • Die Workload-VMs des Kunden werden mit mittlerer vSphere HA-Priorität neu gestartet. Verwaltungs-VMs haben die höchste Neustartpriorität.
  • Die Lösung stützt sich für Neustarts und Replikation auf vSphere HA und vSAN. Der RTO-Wert (Recovery Time Objective) richtet sich nach der Zeit, die vSphere HA benötigt, um nach dem Ausfall einer einzelnen Verfügbarkeitszone eine VM in der verbliebenen VZ neu zu starten.
  • Folgendes wird in einer Stretched Cluster-Umgebung derzeit nicht unterstützt:
    • Kürzlich veröffentlichte Features wie das Herstellen einer Verbindung über eine öffentliche IP-Adresse mit NSX Edge und externer Speicher (z. B. ANF-Datenspeicher)
    • Notfallwiederherstellungs-Add-Ons wie VMware SRM, Zerto und JetStream
  • Öffnen Sie für die folgenden Szenarien im Azure-Portal ein Supportticket (wählen Sie Stretched Cluster als Problemtyp aus):
    • Verbinden einer privaten Cloud mit einer privaten Cloud mit Stretched Cluster
    • Verbinden von zwei privaten Clouds mit Stretched Cluster in einer einzelnen Region

Mit welchen Latenzzeiten zwischen den Verfügbarkeitszonen muss ich rechnen?

Ein vSAN Stretched Cluster arbeitet mit einem RTT-Wert (Round Trip Time) von 5 Millisekunden und einer Bandbreite von 10 Gbit/s oder mehr zwischen den Verfügbarkeitszonen, die die Workload-VMs hosten. Die Azure VMware Solution Stretched Cluster-Bereitstellung folgt diesem Leitprinzip. Berücksichtigen Sie diese Informationen bei der Bereitstellung von Anwendungen (mit der SFTT-Einstellung „Duale Standortspiegelung“, die synchrone Schreibvorgänge nutzt), die hohe Anforderungen an die Latenzzeit stellen.

Kann ich Stretched Cluster und Standardcluster in meiner privaten Cloud kombinieren?

Nein Stretched Cluster und Standardcluster innerhalb derselben privaten Cloud werden nicht unterstützt. Die Auswahl einer Stretched Cluster- oder Standardclusterumgebung erfolgt beim Erstellen der privaten Cloud. Sobald eine private Cloud mit einem Stretched Cluster erstellt wurde, wird vorausgesetzt, dass alle in dieser privaten Cloud erstellten Cluster ebenfalls Stretched Cluster sind.

Wie viel kostet die Lösung?

Die Kosten für Kunden richten sich danach, wie viele Knoten in der privaten Cloud bereitgestellt werden.

Werden mir Gebühren für den Zeugenknoten und für den Datenverkehr zwischen den Verfügbarkeitszonen in Rechnung gestellt?

Nein Kunden werden keine Gebühren für den Zeugenknoten und den Datenverkehr zwischen den Verfügbarkeitszonen in Rechnung gestellt. Der Zeugenknoten wird vollständig über den Dienst verwaltet, und Azure VMware Solution übernimmt die erforderliche Lebenszyklusverwaltung für den Zeugenknoten. Da die gesamte Lösung über einen Dienst verwaltet wird, muss der Kunde lediglich die geeignete SPBM-Richtlinie für die Workload-VMs festlegen. Alle weiteren Verwaltungsaufgaben übernimmt Microsoft.