Gestrecktes VMware vSAN-Cluster erstellen

Wenn alle erforderlichen Konfigurationen abgeschlossen sind, können Sie jetzt mit dem Erstellen des gestreckten VMware vSAN-Clusters fortfahren. In diesem Schritt wird die Verbindung zwischen Hosts in OCI Dedicated Region A und OCI Dedicated Region B sowie dem in einer dritten Region bereitgestellten Witness-Knoten formalisiert.

Sie können den Schnellstartassistenten verwenden oder direkt zu Cluster, Konfigurieren, vSAN, Faultdomains und gestrecktes Cluster in der VMware vCenter-UI navigieren.

Konfigurieren Sie während dieses Prozesses Folgendes:

  • OCI Dedicated Region einer Faultdomain 1 zuweisen
  • OCI Dedicated Region B-Hosts zu Faultdomain 2 zuweisen
  • Geben Sie den Zeugenhost (zuvor hinzugefügt) für das Quorum an

Weitere Informationen finden Sie unter Stretched Cluster Requirements und VMware vSAN Stretched Cluster Guide.

Nachdem das gestreckte Cluster erstellt wurde:

  • Führen Sie die vSAN-Health Checks aus, um die Clusterintegrität zu validieren.
  • Beheben Sie netzwerkbezogene Fehler (z. B. nicht übereinstimmende MTU oder Routingprobleme).

Hinweis:

Möglicherweise treten veraltete vSAN-Objekte auf bestimmten Hosts aus ihren ursprünglichen Clustern auf. In dieser Dokumentation wird beschrieben, wie Sie sie entfernen: Unzugängliche Objekte in vSAN-Datenspeicher löschen

Wenn der Vorgang abgeschlossen ist, muss das Cluster einen vSAN-Zustandsscore im hohen 90s melden, der eine erfolgreiche gestreckte Konfiguration angibt.

NSX konfigurieren

Wenn das vSAN-Cluster VMware gestreckt ist, aktualisieren Sie VMware NSX, um das standortübergreifende Overlay-Networking zu unterstützen. Dieser Schritt stellt sicher, dass ESXi-Hosts aus beiden Regionen über NSX-Tunnel mit den jeweiligen Transportzonen kommunizieren können.

NSX TEP-Konfiguration klonen
  • Kopieren Sie den NSX TEP-IP-Pool aus dem B NSX-Manager der OCI Dedicated Region in den NSX-Manager der OCI Dedicated Region.
  • Um IP-Konflikte mit dem Managementhost ESXi zu vermeiden, der noch in OCI Dedicated Region B vorhanden ist, konfigurieren Sie den neuen IP-Pool in OCI Dedicated Region A, um mit .10 zu beginnen.

    Beispiel: Erstellen Sie in einem NSX-Manager in OCI Dedicated Region einen TEP-Pool mit einem Bereich von .10-.20 für Hosts der OCI Dedicated Region B, um sicherzustellen, dass sich keine Überschneidungen mit vorhandenen IPs ergeben.

Erstellen Sie ein Uplink-Profil für OCI Dedicated Region B in OCI Dedicated Region A
  • Definieren Sie in der OCI Dedicated Region einen NSX-Manager ein neues Uplink-Profil speziell für OCI Dedicated Region B-Hosts.
  • Verwenden Sie die korrekte VLAN-ID, und stellen Sie sicher, dass die Uplink-Reihenfolge mit der Konfiguration OCI Dedicated Region B übereinstimmt.
Hosts für NSX vorbereiten
  • Verwenden Sie OVERLAY-TZ und VLAN-TZ als Transportzonen.
  • Weisen Sie während der Hostvorbereitung das entsprechende Uplink-Profil zu, je nachdem, ob der Host aus OCI Dedicated Region A oder OCI Dedicated Region B stammt.

    Hinweis: In einigen Szenarios, insbesondere nach einem Failover-Ereignis, werden NSX-Tunnelschnittstellen möglicherweise nicht korrekt angezeigt. So beheben Sie den Fehler:

    • Starten Sie den betroffenen ESXi-Host oder neu
    • Führen Sie den Neustart von services.sh über SSH auf dem Host aus.

    Dadurch wird sichergestellt, dass alle NSX-Services in der richtigen Reihenfolge gestartet werden und die Tunnelstabilität wiederhergestellt wird.

NSX-Überlagerungssegmente erstellen
  • Erstellen Sie vier NSX-Überlagerungssegmente.
  • Stellen Sie sicher, dass diese Segmente über alle ESXi Hosts in beiden Sites sichtbar und synchronisiert sind.
DHCP konfigurieren (optional)
  • Konfigurieren Sie optional DHCP-Einstellungen für die neuen Overlay-Segmente.
  • DNS-Einstellungen wurden bereits früher in dieser Anleitung konfiguriert und müssen hier nicht wiederholt werden.
End-to-End-Überlagerungskonnektivität validieren
  • Stellen Sie vier VMs bereit und platzieren Sie eine auf jedem Host in beiden Regionen.
  • Weisen Sie jeder VM eine statische IP-Adresse innerhalb des jeweiligen Segmentbereichs zu.
  • Pingen Sie die Segmentgateways und zwischen VMs, um die L3-Overlay-Konnektivität in der gedehnten Umgebung zu validieren.

Externe Konnektivität für Overlay-VMs aktivieren

Damit VMware NSX-Overlay-VMs auf externe Netzwerke zugreifen können, konfigurieren Sie NAT-Regeln und Routing für die relevanten VLANs.

Aktualisieren Sie in VCN-MGMT-Active und VCN-MGMT-Failover die NAT-Konfiguration für das NSX Edge-Uplink-1-VLAN:

  • Verwenden Sie dieselben externen Zugriffs-IPs in beiden Regionen, die mit denen übereinstimmen, die während des Deployments der dedizierten OCI-Region verwendet werden.
  • Bestätigen Sie, dass die verwendete IP die HA-VIP für die NSX-Edge-Knoten ist, die in NSX Manager angezeigt werden.

Aktualisieren Sie außerdem externe Zugriffsregeln für die vSphere-VLANs:

  • Konfigurieren Sie NAT-Regeln für vcenter-vip, nsxt-manager-vip und HCX-manager-vip (wenn HCX verwendet wird) in beiden VCNs.

DNS-Weiterleitungsunterstützung

Overlay-VMs verwenden in der Regel einen DNS-Weiterleiter (z.B. 192.168.253.253), der in NSX-T definiert ist. So leiten Sie diese DNS-Abfragen weiter:

  1. Erstellen Sie eine dedizierte Routentabelle für das NAT-Gateway.
  2. Statische Route definieren:
    • Ziel: 10.x.x.x (VM-Subnetze überlagern)
    • Ziel: NAT-Gateway
    • DNS-Weiterleitungs-IP: 192.168.253.253

Diese Konfiguration muss an beiden Standorten repliziert werden. Verknüpfen Sie die neue Routentabelle mit dem NAT-Gateway, um ein konsistentes Verhalten zu erzielen.

ESXi-Host-VLANs dem variablen VCN neu zuweisen

Im aktuellen Setup wird jedem ESXi-Host zwei physische NICs bereitgestellt, die jeweils mit einem Standardset von VLANs verknüpft sind, das über VNIC-Anhänge an VCN-Primary (OCI Dedicated Region A) und VCN-Secondary (OCI Dedicated Region B) konfiguriert wurde. Diese VNICs werden mit dem sekundären CIDR-Block (172.45.0.0/16) konfiguriert, der an die jeweiligen VCNs angehängt ist.

Um den Übergang zu einer gestreckten Konfiguration abzuschließen, müssen alle VLANs mit Tags 200 und höher (z.B. für vSphere, HCX, NSX Edge usw.) zu den unverankerten VCNs migriert werden:
  • VCN-MGMT-Active in OCI Dedicated Region A
  • VCN-MGMT-Failover in OCI Dedicated Region B

VNICs in das variable VCN migrieren

Führen Sie die folgenden Schritte für jeden ESXi-Host in beiden SDDCs aus:
  1. Zugriff auf ESXi-Hostdetails: Gehen Sie in der OCI-Konsole zu Compute, ESXi-Hosts.
  2. Vorhandene VNIC-Anhänge löschen: Löschen Sie für jeden Host die VNICs, die mit VLANs 201 und höher verknüpft sind, aus VCN-Primär oder VCN-Sekundär.

    Hinweis:

    Dieser Schritt ist erforderlich, da keine neue VNIC für dasselbe VLAN erstellt werden kann, während die alte VNIC vorhanden ist.
  3. Erstellen Sie VNICs im variablen VCN neu:
    • Erstellen Sie eine neue VNIC für jedes VLAN im entsprechenden Floating-VCN:
      • Verwenden Sie VCN-MGMT-Active in OCI Dedicated Region A
      • VCN-MGMT-Failover in OCI Dedicated Region verwenden B
    • Wählen Sie das VLAN aus, das mit dem entsprechenden Suffix -NEW getaggt ist, um es vom Original zu unterscheiden.

    Wiederholen Sie diesen Vorgang für beide VNICs pro Host. Wir empfehlen einen systematischen Ansatz: Beginnen Sie mit vnic0 und vnic1 für VLAN 201, schließen Sie die Ersetzungen ab, und fahren Sie dann mit dem nächsten VLAN fort.

    Besondere Überlegungen für sekundäre Sitehosts

    Wiederholen Sie nach der Migration der VNICs für Hosts in der Primären Site den Prozess für alle Hosts in der Sekundären Site. Beachten Sie jedoch ein wichtiges Detail:

    • Die Managementkomponenten vSphere in der sekundären Site wurden zunächst in einem temporären VLAN bereitgestellt (z.B. VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Dieses temporäre VLAN kann während des Übergangs an Ort und Stelle bleiben. Sie wirkt sich nicht auf die erweiterte vSAN-Funktionalität aus und bietet bei Bedarf Fallback-Zugriff auf vCenter- und NSX-Komponenten.

    Durch die Beibehaltung dieses temporären VLANs wird ein unterbrechungsfreier Verwaltungszugriff während des VNIC- und Netzwerkmigrationsworkflows sichergestellt.

    Konnektivitätsauswirkung und -wiederherstellung

    Bei VNIC-Updates wird ein vorübergehender Verbindungsausfall mit vCenter-, NSX Manager- oder ESXi-Hosts erwartet. So stellen Sie die Wiederherstellung sicher:

    1. DRG-Anhänge prüfen: Stellen Sie sicher, dass die entsprechenden Management-VCNs (sowohl Active als auch Failover) an die jeweiligen Dynamischen Routinggateways (DRGs) angehängt sind.
    2. Routentabellen aktualisieren:
      • Aktualisieren Sie die Masterroutentabelle in jedem Management-VCN so, dass sie auf das DRG verweist.
      • Aktualisieren Sie die Routentabellen des Bastionsubnetzes, um sicherzustellen, dass der Managementtraffic ordnungsgemäß zwischen VCNs und regionsübergreifend weitergeleitet wird.
    3. Zugriff validieren:
      • Nach der Aktualisierung der Routen muss der Zugriff auf alle Managementschnittstellen vom Bastionhost wiederhergestellt werden.
      • Wenn Ressourcen weiterhin nicht erreichbar sind, prüfen Sie NSG-Regeln erneut, und leiten Sie die Propagierung zwischen VCNs weiter.

    Bereinigung nach vNIC-Migration

    Sobald die VNIC-Migration abgeschlossen ist:

    • Entfernen Sie alle nicht verwendeten VLANs aus VCN-Primary und VCN-Secondary, die zum CIDR-Block 172.45.0.0/16 gehören.
    • Trennen Sie das sekundäre CIDR (172.45.0.0/16) von VCN-Primary, da es nicht mehr verwendet wird.

    OCI lässt das CIDR-Trennzeichen nur zu, wenn keine aktiven Ressourcen (VNICs, Subnetze oder VLANs) es verwenden.

    • Sie können Warnindikatoren auf der Seite "SDDC-Ressource" in der OCI-Konsole beobachten. Dies wird erwartet, da der Oracle Cloud VMware Solution-Service Komponenten nicht mehr verfolgt, die ursprünglich in VCN-Primary bereitgestellt wurden.

    Routing für neue VCN-Anhänge aktualisieren

    1. Hängen Sie VCN-MGMT-Active an das DRG in OCI Dedicated Region A an.
    2. Routentabellen aktualisieren:
      • Für VCN-MGMT-Active: Zeigen Sie die Standardroute (0.0.0.0/0) auf das DRG.
      • Aktualisieren Sie für das Bastionssubnetz in VCN-Primary die Routentabelle so, dass sie auf das DRG verweist, um sicherzustellen, dass es weiterhin auf VMware vCenter und VMware NSX Manager zugreifen kann.

    Nachdem diese Änderungen vorgenommen wurden, sollten VMware vCenter und VMware NSX Manager in OCI Dedicated Region A vom Bastionhost aus erreichbar sein, obwohl sich ihre zugrunde liegenden Schnittstellen jetzt in einem anderen VCN befinden.

DRS-Affinitätsregeln, HA und vSAN-Speicher-Policy VMware konfigurieren

Sobald das gestreckte Cluster voll funktionsfähig ist und das Netzwerk über beide Standorte hinweg stabil ist, konfigurieren Sie Distributed Resource Scheduler (DRS), High Availability (HA) und weisen der Workload und den virtuellen Maschinen (VMs) des Managements eine standortbezogene VMware vSAN-Speicher-Policy zu.

Diese Konfigurationen stellen eine optimale Platzierung von VMs über Faultdomains hinweg sicher und ermöglichen das automatische Recovery bei Sitefehlern.

VMs in das gestreckte Cluster migrieren

Migrieren Sie zunächst alle Management-VMs und Test-Workload-VMs in das neu erstellte gestreckte Cluster:

  • Mit vMotion können Sie die VMs aus ihren ursprünglichen standortspezifischen Clustern in das gestreckte Cluster verschieben.
  • Wenn alles korrekt konfiguriert ist (Networking, Speicher, Portgruppen), sollte die VM-Migration ohne Probleme abgeschlossen werden.

Wenn Standardregeln für NSX DRS vorhanden sind und auf MÜSSEN gesetzt sind, entfernen Sie sie. Diese können HA-Vorgänge beeinträchtigen und Failover von NSX Edge-Knoten und NSX Manager-VMs verhindern.

VM und Hostgruppen erstellen

Definieren Sie Affinitätsgruppen für die Workload-Platzierung:

  1. Hostgruppen erstellen:
    • Gruppieren Sie Hosts, die zur primären Site gehören.
    • Gruppenhosts, die zur Sekundären Site gehören.
  2. VM-Gruppen erstellen
    • Gruppenverwaltungs-VMs, die sich auf Hosts innerhalb jeder Site befinden müssen (z.B. vCenter, NSX-Manager, NSX-Edge-Knoten, HCX-Manager und andere, falls zutreffend).
    • Ebenso gruppieren Sie alle Workload-VMs (in unserem Fall alle Test-VMs).

Affinitätsregeln für VM/Host definieren

Nachdem Gruppen definiert wurden:

  • Erstellen Sie VM-zu-Host-Affinitätsregeln, um VMs auf Hosts in der gewünschten Site zu speichern.
  • Verwenden Sie Regeln zum Ausführen von VMs auf Hosts, um HA-Flexibilität in Failover-Szenarios zu ermöglichen.
  • Erstellen Sie solche Regeln sowohl für die Management-VM- als auch für die Workload-VM-Gruppen.

Dieses Setup stellt sicher, dass jede Site während des normalen Betriebs die beabsichtigten Workloads hostet, ermöglicht jedoch ein automatisches Recovery bei einem Host- oder Sitefehler.

High-Availability (HA) aktivieren
  • Stellen Sie sicher, dass HA auf Clusterebene aktiviert ist, nachdem Affinitätsregeln eingerichtet wurden.
  • Die Standardoption zum Neustart von VMs bei einem Hostfehlerereignis stellt einen VM-Neustart bei unerwarteten Fehlern sicher, einschließlich vollständiger Siteausfälle.

Gestreckte vSAN-Speicher-Policy erstellen und anwenden

Um Datenredundanz über beide Standorte hinweg in einer gestreckten Konfiguration sicherzustellen, definieren Sie eine neue vSAN Storage-Based Policy Management (SBPM)-Richtlinie. Diese Policy steuert, wie VM-Daten über die Faultdomains und die Zeugensite verteilt werden.

Konfigurieren Sie die folgenden Ersatzregeln innerhalb der Policy:

  • Speichertyp: vSAN
  • Site-Disaster-Toleranz: Site-Spiegelung - gestrecktes Cluster
  • Fehler bei Toleranz: Keine Datenredundanz
  • Anzahl Datenträger-Stripes pro Objekt: 1
  • IOPS-Grenzwert für Objekt: 0

Behalten Sie alle anderen Optionen bei.

Nach Erstellung der Policy:

  1. Wenden Sie die Policy auf alle Test- und Management-VMs im gestreckten Cluster an.
  2. Navigieren Sie zu Überwachen, vSAN, Objekte neu synchronisieren, um den Neusynchronisierungsprozess zu beobachten und zu verfolgen.
  3. Prüfen Sie nach Abschluss der Neusynchronisierung die Objektplatzierung, um zu bestätigen, dass die Policy wie erwartet funktioniert:
    • Ein Replikatobjekt befindet sich auf der primären Site
    • Ein zweites Replikatobjekt befindet sich auf der Sekundären Site
    • Die Zeugenkomponente befindet sich in der Remoteregion "Zeuge"

Alle VMs werden zunächst als nicht konform angezeigt. Wählen Sie jede VM oder eine Gruppe von VMs aus, und weisen Sie die neu erstellte gestreckte Policy manuell zu, um sie in Compliance zu bringen.

Navigieren Sie außerdem zu Überwachen, vSAN, Objekte und virtuelle Objekte neu synchronisieren. Sobald der Neusynchronisierungsprozess abgeschlossen ist, sollten Sie feststellen, dass die virtuellen Objekte jeder VM korrekt über den Knoten "Primäre Site", "Sekundäre Site" und "Zeuge" verteilt sind, um die vollständige Einhaltung des gestreckten Clusterdesigns zu überprüfen.