IBM Cloud Docs
Architekturmuster für vCenter Server Implementierungstopologien mit mehreren Standorten

Architekturmuster für vCenter Server Implementierungstopologien mit mehreren Standorten

VMware Cloud Foundation for Classic – Automated Instanzen bieten eine anfängliche Standardtopologie mit einem einzelnen Management- oder konvergierten Cluster, der ein vCenter, drei VMware NSX™-Manager und eine Active Directory™-Bereitstellung umfasst. Diese Bereitstellungen laufen entweder auf einer einzelnen IBM Cloud Classic Virtual Server Instance oder auf zwei VMware Virtual Machines (VMs) in einer Hochverfügbarkeitsbereitstellung (HA). Die erste Bereitstellung umfasst auch eine Standard-NSX-Topologie.

Sie haben mehrere Möglichkeiten, die Kapazität für die Bereitstellung zu erweitern, indem Sie neue Hosts auf dem ursprünglichen Cluster bereitstellen oder neue Cluster hinzufügen. Dieses Muster enthält einige Beispiele dafür, wie Sie die ursprüngliche Bereitstellung für einige Anwendungsfälle erweitern und an Ihre Bedürfnisse anpassen können.

Um die NSX-Topologien anzupassen, siehe das Architekturmuster für Multisite-NSX-Topologien.

vCenter Serverbereitstellung mit mehreren Standorten

Die standortübergreifende Bereitstellung ist ein gängiger Anwendungsfall und ein gängiges Muster für die Netzwerkbereitstellung. Diese Topologie ist hochgradig skalierbar und lässt sich leichter verwalten und erweitern. Das Bereitstellungsmuster für mehrere Standorte basiert auf der vCenter Server Bereitstellungsoption für mehrere Standorte.

Das folgende Diagramm zeigt ein Beispiel für die Bereitstellung durch einen Kunden unter Verwendung dieser Topologie. Sie können weitere Hosts oder neue Cluster hinzufügen, um die Lösung zu skalieren.

Multisite Einsatztopologie
Multisite deployment topology

  1. Die vCenter Server-Automatisierung stellt einen anfänglichen vSphere-Cluster auf der primären Instanz bereit, der ein vCenter, drei NSX-Manager und eine Active Directory-Bereitstellung umfasst. Sie laufen entweder auf einer einzelnen IBM Cloud oder auf zwei VMware in einer HA-Bereitstellung. Dieser Fall umfasst eine vCenter,-Instanz mit drei NSX-Managern, eine Active Directory-Bereitstellung, die entweder auf einer einzelnen IBM Cloud Classic Virtual Server-Instanz oder auf zwei VMware-VMs in einer HA-Bereitstellung ausgeführt wird, sowie zwei NSX-Edge-Cluster, einen für Dienste und einen für Arbeitslasten.
  2. Die anfängliche VCF for Classic – Automated-Instanz kann mehrere vSphere-Cluster enthalten (siehe Einzelstandortbereitstellung). Sie werden normalerweise am ursprünglichen Standort des IBM Cloud Rechenzentrums bereitgestellt.
  3. Sie können eine sekundäre VCF for Classic – Automated-Instanz nach der primären Instanz bereitstellen, die bereitgestellt wird. Mit dieser Option wird automatisch eine sekundäre VCF for Classic – Automated Instanz in dem neuen IBM Cloud Rechenzentrumsstandort bereitgestellt. Diese Instanz ist dann mit der ersten primären vCenter Server Instanz verbunden, die in Schritt 1 bereitgestellt wurde. Sie können mehrere sekundäre Instanzen erstellen. Als primäre Instanz umfasst diese Instanz eine vCenter, drei NSX-Manager, eine Active Directory-Bereitstellung, die entweder auf einer einzelnen IBM Cloud Classic Virtual Server-Instanz oder zwei VMware VMs in einer HA-Bereitstellung ausgeführt wird, und zwei NSX-Edge-Cluster, einen für Dienste und einen für Arbeitslasten. Die zweite Site befindet sich unter derselben SSO und Rootdomäne wie die primäre Site.
  4. Wie die primäre kann auch die sekundäre VCF for Classic – Automated-Instanz mehrere vSphere-Cluster umfassen. Sie werden normalerweise an demselben Standort des IBM Cloud Rechenzentrums wie der sekundäre Standort bereitgestellt.
  5. Sie können NFS basierte IBM Cloud File Storage for Classic zu Ihren Clustern hinzufügen. Sie können eine oder mehrere Dateifreigaben hinzufügen und sie einzeln konfigurieren, indem Sie die Leistung (IOPS) und die Größe (GB) für jede auswählen. Jedes Rechenzentrum und jede Instanz verwendet seinen eigenen Speicher.
  6. Sie können vSAN auch mit Ihren vSphere Clustern verwenden. Wenn Sie vSAN, verwenden, müssen Sie aufgrund der Art des dedizierten lokalen Speichers bei der Bestellung des Clusters die Option vSAN auswählen. Jede Instanz verwendet ihren eigenen Speicher.
  7. Sowohl die primäre als auch die sekundäre Instanz haben ihre eigenen NSX-Manager und ihre eigenen NSX-Topologien. Jede Instanz verfügt über einen Workload Edge Cluster, der aus zwei Edge Transportknoten für Ihre Nutzung besteht.
  8. Die Hosts und NSX Tier-0 Gateways in einem bestimmten Rechenzentrum oder POD sind mit VLANs und Subnetzen verbunden, die für dieses IBM Cloud Rechenzentrum oder POD lokal sind. Diese VLANs und Teilnetze können nicht erweitert oder in andere IBM Cloud Rechenzentren verschoben werden. Diese Subnetze können jedoch mit Subnetzen kommunizieren, die einem anderen IBM Cloud Rechenzentrum über ein IBM Cloud privates Netz zur Verfügung gestellt werden.
  9. Wenn Sie einen optionalen Gateway Cluster auswählen, automatisiert vCenter Server zwei ESXi Hosts mithilfe von IBM Cloud Bare Metal Servern und bildet einen neuen vSphere Cluster in Ihrer Bereitstellung. Dies kann für jede Instanz separat erfolgen.

vCenter Serverbereitstellung mit zwei Standorten

Die Implementierung mit zwei Standorten ist in der Regel für die Anwendungsfälle Produktion und Disaster Recovery geeignet. Dieses Bereitstellungsmuster basiert auf zwei vCenter-Servern als einzelne Standortinstanz, wobei jede Instanz separat bereitgestellt wird und sie keine gemeinsame Verwaltung haben. Dieses Muster ist hoch skalierbar und jede Instanz wird separat verwaltet und erweitert. Die Integration zwischen diesen Umgebungen erfolgt normalerweise auf Netzebene und in Anwendungsfällen zur Disaster Recovery werden Produkte anderer Anbieter in der Regel zum Replizieren von Daten und VMs verwendet.

Das folgende Diagramm zeigt ein Beispiel für die Bereitstellung durch einen Kunden unter Verwendung dieser Topologie.

Einsatztopologie mit zwei Standorten
Dual-site deployment topology

  1. Die vCenter Server-Automatisierung stellt Instanz A und ihren Verwaltungs- oder konvergierten Cluster bereit, der ein vCenter, drei NSX-Manager und eine Active Directory-Bereitstellung umfasst. Sie laufen entweder auf einer einzelnen IBM Cloud oder auf zwei VMware in einer HA-Bereitstellung. Dieser Fall umfasst eine vCenter,-Instanz mit drei NSX-Managern, eine Active Directory-Bereitstellung, die entweder auf einer einzelnen IBM Cloud Classic Virtual Server-Instanz oder auf zwei VMware-VMs in einer HA-Bereitstellung ausgeführt wird, sowie zwei NSX-Edge-Cluster, einen für Dienste und einen für Arbeitslasten.
  2. Sie können eine weitere VCF for Classic – Automated-Instanz, Instanz B, zur gleichen Zeit oder später als die Instanz A bereitstellen. Mit dieser Option stellt die Automatisierung eine neue VCF for Classic – Automated Instanz im neuen IBM Cloud Rechenzentrumsstandort bereit. Als Instanz A umfasst diese Instanz eine vCenter,, drei NSX-Manager, eine Active Directory-Bereitstellung, die entweder auf einer einzelnen IBM Cloud Classic Virtual Server-Instanz oder auf zwei VMware-VMs in einer HA-Bereitstellung ausgeführt wird, sowie zwei NSX-Edge-Cluster, einen für Dienste und einen für Arbeitslasten.
  3. Beide VCF for Classic – Automated-Instanzen können mehrere vSphere-Cluster enthalten (siehe Einzelstandortbereitstellung).
  4. Wenn Sie einen optionalen Gateway Cluster auswählen, automatisiert vCenter Server zwei ESXi Hosts mithilfe von IBM Cloud Bare Metal Servern und bildet einen neuen vSphere Cluster in Ihrer Bereitstellung. Dies kann für jede Instanz separat erfolgen.
  5. Jede Instanz hat ihren eigenen Speicher, der NFS-basiert IBM Cloud File Storage for Classic oder vSAN sein kann. Sie können eine oder mehrere NFS Dateifreigaben hinzufügen und einzeln konfigurieren, indem Sie die Leistung (IOPS) und die Größe (GB) für jede Dateifreigabe auswählen. Wenn Sie vSAN, verwenden, müssen Sie aufgrund der Art des dedizierten lokalen Speichers bei der Bestellung des Clusters die Option vSAN auswählen.
  6. Beide Instanzen haben ihre eigenen NSX-Manager und ihre eigenen NSX-Topologien. Jede Instanz verfügt über einen Workload Edge Cluster, der aus zwei Edge Transportknoten für Ihre Nutzung besteht.
  7. Die Hosts und NSX Tier-0 Gateways in einem bestimmten Rechenzentrum oder POD sind mit VLANs und Subnetzen verbunden, die für dieses IBM Cloud Rechenzentrum oder POD lokal sind. Diese VLANs und Teilnetze können nicht erweitert oder in andere IBM Cloud Rechenzentren verschoben werden. Diese Subnetze können jedoch mit Subnetzen kommunizieren, die einem anderen IBM Cloud Rechenzentrum über ein IBM Cloud privates Netz zur Verfügung gestellt werden.

Aspekte von vCenter Server Implementierungstopologien mit mehreren Standorten

Wenn Sie dieses Architekturmuster entwerfen oder einsetzen, sollten Sie die folgenden Schritte beachten:

  • Sie haben mehrere Möglichkeiten, die Kapazität für die Bereitstellung zu erweitern, z. B. durch Bereitstellung neuer Hosts auf dem ursprünglichen Cluster oder durch Hinzufügen neuer Cluster.
  • Dieses Muster enthält einige Beispiele dafür, wie Sie die anfängliche Bereitstellung für einige Anwendungsfälle erweitern und an Ihre Bedürfnisse anpassen können, aber beachten Sie, dass dies nur Beispiele sind.
  • Sie müssen VMware Einschränkungen beachten.

Um die NSX-Overlay-Topologien anzupassen, siehe das Architekturmuster für Multisite-NSX-Topologien.