Erfahren Sie, wie Sie mit Oracle Cloud VMware Solution ein VMware vSAN Stretched Cluster über OCI-Regionen hinweg bereitstellen

Oracle Cloud Infrastructure (OCI) bietet High Availability und Fehlertoleranz für alle seine mehreren Availability-Domain-Regionen. Diese Regionen bieten von Natur aus eine Faultisolierung auf Data Center-Ebene, wobei jede Availability-Domain in mehrere Faultdomains unterteilt ist, um sich vor Ausfällen auf Rackebene zu schützen. Diese integrierte Architektur erfüllt die Resilienzanforderungen der meisten Unternehmens-Workloads.

Bei VMware-Workloads unterstützt Oracle Cloud VMware Solution mehrere Availability-Domain-Deployments in Regionen mit drei Availability-Domains. In diesem Fall können Sie nativ gestreckte VMware vSAN-Cluster in einer einzigen Region bereitstellen und VMware HA und VMware vSAN nutzen, ohne dass komplexe standortübergreifende Konfigurationen erforderlich sind.

In öffentlichen OCI-Regionen mit nur einer Availability-Domain oder in Oracle Cloud Infrastructure Dedicated Regions (OCI Dedicated Regions, früher als Oracle Dedicated Region Cloud@Customer bezeichnet) sind jedoch mehrere Availability-Domain-Konfigurationen nicht verfügbar. Für Kunden in diesen Umgebungen, die einen Schutz auf Regionsebene vor vollständigen Standortausfällen benötigen, ist ein anderer Ansatz erforderlich. In diesem Lösungs-Playbook wird eine validierte, vom Kunden verwaltete Architektur für die Bereitstellung von VMWare vSAN-gestreckten Clustern über mehrere OCI-Regionen hinweg vorgestellt, eine Lösung, die durch die Full-Stack-Kontrolle von Oracle Cloud VMware Solution ermöglicht wird.

Hinweis:

Dieses Deployment-Modell wurde erfolgreich in OCI Dedicated Regions getestet. Wenn die erforderlichen Anforderungen an Latenz, Hostausprägung und Netzwerkkonnektivität erfüllt sind, kann sie auch in öffentlichen OCI-Regionen repliziert werden.

OCI bietet zwar keine native oder automatisierte Methode für das Deployment eines regionsübergreifenden VMware vSAN-Stretchclusters, Oracle Cloud VMware Solution ermöglicht dies jedoch durch seine einzigartige Flexibilität. Kunden behalten die vollständige administrative Kontrolle über VMware vCenter-, VMware NSX- und VMware ESXi-Hosts, sodass sie erweiterte Konfigurationen entwerfen und implementieren können, die in weniger eingeschränkten verwalteten Cloud-Angeboten VMware sonst schwierig oder unmöglich wären.

Dieses Lösungs-Playbook bietet architektonische Anleitungen und detaillierte Schritte zum Erstellen dieser leistungsstarken Konfiguration mit Oracle Cloud VMware Solution.

Kernkonzepte verstehen

Was ist ein gestrecktes VMware vSAN-Cluster?

Ein gedehntes vSAN-Cluster ist eine VMware-Konfiguration, die einen einzelnen logischen VMware vSAN-Datenspeicher über zwei physisch getrennte Speicherorte erweitert. Beide Standorte werden als aktiv-aktive Standorte betrachtet, und die Konfiguration stellt eine kontinuierliche Verfügbarkeit sicher, falls ein Standort nicht verfügbar ist. Virtuelle Maschinen (VMs) können dank der nativen Funktionen von VMware vSphere HA automatisch ein Failover zwischen Sites durchführen. vSAN stellt die Speicherverfügbarkeit sicher, solange eine Site und der Zeugenknoten betriebsbereit bleiben.

Im Kontext von OCI ist diese Architektur gut auf OCI Dedicated Regions abgestimmt, die im Allgemeinen geografisch nahe genug liegen, um die strengen Anforderungen an niedrige Latenz von VMware vSAN-gestreckten Deployments zu erfüllen.

Weitere Informationen finden Sie in der offiziellen Dokumentation von Broadcom: Introduction to vSAN Stretched Clusters.

Erweiterung von gedehnten vSAN-Clustern auf OCI und Oracle Cloud VMware Solution

Während VMware-vSAN-gestreckte Cluster in der Regel zwei physisch getrennte Sites umfassen, kann Oracle Cloud VMware Solution ein VMware-Software-Defined Data Center (SDDC) standardmäßig in einer einzelnen Availability-Domain oder über mehrere Availability-Domains innerhalb derselben Region bereitstellen, wenn diese entsprechend konfiguriert werden. Dieses Deployment-Modell entspricht dem regionalen Geltungsbereich des zugrunde liegenden virtuellen Cloud-Netzwerks (VCN), das innerhalb, aber nicht über OCI-Regionen hinweg betrieben wird.

Um Resilienz auf Regionsebene zu erreichen und vor regionalen Ausfällen zu schützen, können Kunden, die OCI Dedicated Region verwenden, zwei separate Oracle Cloud VMware Solution-SDDCs in verschiedenen OCI Dedicated Regions bereitstellen. Diese SDDCs sind über das private Backbone-Netzwerk von OCI miteinander verbunden und ermöglichen eine sichere Kommunikation mit geringer Latenz. Der erforderliche VMware vSAN-Zeugeknoten wird in einer dritten Region in geografischer Nähe (wie einer öffentlichen OCI-Region) bereitgestellt, um die gestreckte Clusterkonfiguration abzuschließen.

Dieses Design ermöglicht die Verfügbarkeit von Active/Active-Standorten innerhalb der VMware-Umgebung und stellt einen kontinuierlichen Betrieb auch bei einem regionalen Ausfall sicher. Es entspricht sowohl den Best Practices von VMware als auch von Oracle für High Availability und Disaster Recovery.

Architektur

Diese Architektur zeigt, wie Sie benutzerdefinierte VMware vSAN-gestreckte Cluster über mehrere OCI-Regionen hinweg bereitstellen können.

Die Topologie der obersten Ebene besteht aus:

  • Primäre Site: Oracle Cloud VMware Solution-SDDC in OCI Dedicated Region A bereitgestellt.
  • Sekundäre Site: Oracle Cloud VMware Solution-SDDC in OCI Dedicated Region B bereitgestellt.
  • Zeugenstandort: Ein regional separater Speicherort für das Deployment der VMware vSAN Witness Appliance.

Die Kommunikation über diese Sites erfolgt über das private Backbone von OCI und OCI FastConnect, die beide obligatorisch sind, um die Anforderungen an niedrige Latenz und hohe Bandbreite eines stabilen VMware vSAN-gestreckten Clusters zu erfüllen.

Hinweis:

IPSec VPN wird für diese Konfiguration nicht unterstützt.

Das folgende Diagramm veranschaulicht diese Architektur.


Beschreibung von ocvs-vsan-stretched-cluster.png folgt
Beschreibung der Abbildung ocvs-vsan-stretched-cluster.png

ocvs-vsan-stretched-cluster-oracle.zip

In den folgenden Abschnitten werden die wichtigsten technischen Überlegungen beschrieben, die eine erfolgreiche Bereitstellung eines VMware vSAN-Stretched Clusters in Oracle Cloud VMware Solution in OCI Dedicated Region beeinflussen.

Überlegungen zum Networking

Ein wesentlicher Faktor dieser Architektur ist das robuste OCI-Backbone-Netzwerk, das OCI Dedicated Regions innerhalb eines Kundenmandanten verbindet. Dieses Backbone gewährleistet die schnelle Kommunikation mit geringer Latenz, die für den VMware vSAN-Replikationstraffic und die Heartbeat-Signalisierung zwischen Sites erforderlich ist.

Wichtige Faktoren für die Planung:

  • Richten Sie Remote-Peering-Verbindungen (RPCs) zwischen den VCNs in OCI Dedicated Region A und OCI Dedicated Region B mit Dynamic Routing Gateways (DRGs) ein. Dadurch wird die vollständige Mesh-Konnektivität über alle VMware ESXi-Hosts hinweg aktiviert.
  • Verwenden Sie OCI FastConnect (nicht IPSec VPN), um beide OCI Dedicated Region mit der öffentlichen OCI-Region zu verbinden, in der der der Zeuge gehostet wird. Dies gewährleistet eine konsistente niedrige Latenz und einen zuverlässigen Durchsatz, um die Zeugenkommunikation zu unterstützen.
  • Referenzdokumentation: Remote-Peering, DRGs verwalten, OCI FastConnect

Compute- und Speicherressourcen – Überlegungen

Die Infrastrukturplanung in allen drei Regionen umfasst mehrere Entscheidungen:

  1. Regionsauswahl
    • Wählen Sie zwei OCI Dedicated Regions mit einer Latenz von < 5 ms RTT zwischen ihnen aus.
    • Wählen Sie eine öffentliche OCI-Region mit einer Latenz von < 200 ms RTT für beide OCI Dedicated Regions für das Witness-Deployment aus.
  2. Ausprägungsauswahl
    • Verwenden Sie Dense Bare Metal-Ausprägungen (z.B. BM.DenseIO.E5.128) mit lokalem NVMe-Speicher für VMware vSAN.
    • Vermeiden Sie Standardausprägungen, die Block-Volumes verwenden, da sie nicht für gestreckte vSAN-Deployments geeignet sind.
  3. Mindestanforderungen an den Host
    • Primäre Region: Mindestens drei Dense-Bare Metal-Hosts
    • Sekundäre Region: Mindestens drei Dense-Bare Metal-Hosts
    • Zeugenregion: Ein Bare-Metal-Host
  4. Richtlinien für Zeugengeräte

Anforderungen für gestreckte Cluster

  • RTT-Latenz < 5 ms zwischen primären und sekundären Regionen
  • RTT-Latenz < 200 ms zwischen Standort und Witness-Knoten
  • Alle Hosts (einschließlich Witness) müssen zum selben VMware vSAN-Cluster gehören
  • Hosthardware und -konfiguration müssen regionsübergreifend identisch sein
  • Zeuge muss sich an einem dritten, separaten Ort befinden

Betriebliche Überlegungen

Kunden sind für den manuellen Abschluss der Vorgänge am 2. Tag verantwortlich. Wichtige Hinweise:

  • Oracle Cloud VMware Solution-Umgebungen werden in jeder OCI Dedicated Region separat bereitgestellt. Die sekundären Sites VMware vCenter und VMware NSX Manager müssen manuell getrennt und in das primäre Cluster integriert werden.
  • Bei einem Sitefehler sind manuelle Failover- und Routingupdates erforderlich.
  • VMware Das NSX Tier-0-Gateway ist nur an einer Site aktiv, was ein Active/Passive-Modell für das Nord-Süd-Trafficrouting impliziert.

Designüberblick

Aufbauend auf den vorherigen Abschnitten, die Architektur und Anforderungen für eine gestreckte vSAN-Konfiguration mit Oracle Cloud VMware Solution abdeckten, wird in diesem Abschnitt erläutert, wie Sie ein hochverfügbares Design implementieren, das dem Ausfall einer OCI Dedicated Region standhält.

In diesem Design werden zwei VCNs pro Site verwendet, sodass insgesamt vier VCNs vorhanden sind:

OCI Dedicated Region A

  • VCN Primary mit zwei CIDR-Blöcken. Beispiel: 10.16.0.0/16 als primäre und 172.45.0.0/16 als sekundäres CIDR (nach der VCN-Erstellung hinzugefügt). Das sekundäre CIDR ist nur für das anfängliche SDDC-Deployment erforderlich.

    Da ein Oracle Cloud VMware Solution-SDDC nicht mehrere VCNs umfassen kann, wird ein sekundärer CIDR-Block (172.45.0.0/16) innerhalb von OCI Dedicated Region A an das primäre VCN angehängt. Dadurch werden VLAN-Definitionen für Management- und Servicesubnetze aktiviert, während diese logisch in einem einzelnen VCN gruppiert bleiben.

  • VCN MGMT Active, mit demselben CIDR-Block wie das sekundäre CIDR, das an VCN Primary angehängt ist, d.h. 172.45.0.0/16.

OCI Dedicated Region B

  • VCN Secondary mit einem CIDR-Block, der sich von VCN Primary unterscheidet und sich nicht überschneidet. Beispiel: 10.17.0.0/16.
  • VCN MGMT Failover, wobei der gleiche CIDR-Block wie VCN MGMT Active verwendet wird, d. h. 172.45.0.0/16.

Oracle Cloud VMware Solution bietet Flexibilität bei der Netzwerkbereitstellung. Während der SDDC-Erstellung können Benutzer:

  • Geben Sie einen CIDR-Block an, und ermöglichen Sie der Oracle Cloud VMware Solution-Automatisierung das Erstellen erforderlicher Netzwerkkomponenten, oder
  • Erstellen Sie zuvor manuell VCNs, Subnetze, VLANs, Routentabellen und NSGs, und wählen Sie diese vorhandenen Ressourcen während des Deployments aus.

Für dieses gestreckte vSAN-Design ist der letztgenannte Ansatz notwendig. Um die Netzwerksegmentierung über mehrere VCNs und Regionen genau steuern zu können, müssen Routentabellen, NSGs und VLANs vorab erstellt werden. Diese Trennung unterstützt klare Zuständigkeiten zwischen VCNs und ermöglicht ein nahtloses Failover-Verhalten.

Ein wichtiger Aspekt ist, dass das Managementsubnetz (172.45.0.0/16) in beiden OCI Dedicated Regions zugänglich sein muss. Zur Unterstützung von Failover ermöglicht das Design, dass dieses VCN-MGMT-Netzwerk während Failover-Ereignissen über manuelle Netzwerkupdates zwischen den beiden Sites "float" kann, z.B. Routentabellen ändern und das Subnetz über DRG-Anhänge erneut vertreiben.

Die DNS-Auflösung ist für Failover und Serviceverfügbarkeit von entscheidender Bedeutung. Daher wird ein dediziertes Servicesubnetz in jedem VCN erstellt, um DNS und unterstützende Infrastruktur zu hosten.

Für einfache VLAN-Tagging:

  • VLAN-Tags im 100-Bereich sind regionsspezifisch und auf die jeweiligen Sites beschränkt.
  • VLAN-Tags im 200-Bereich sind mit dem Subnetz 172.45.0.0/16 verknüpft und schwimmen zwischen Sites.

Mit dem definierten High-Level-Design gehen wir nun in die praktische Konfiguration jedes Standorts ein, beginnend mit dem primären Bereich.