Über den Einsatz von Cookies auf dieser Website Unsere Websites benötigen einige Cookies, um ordnungsgemäß zu funktionieren (erforderlich). Darüber hinaus können mit Ihrer Zustimmung weitere Cookies verwendet werden, um die Nutzung der Website zu analysieren, die Benutzerfreundlichkeit zu verbessern und Werbung zu schalten. Weitere Informationen finden Sie in Ihren. Durch den Besuch unserer Website erklären Sie sich mit der Verarbeitung von Informationen einverstanden, wie in der IBMDatenschutzbestimmung beschrieben. Um eine reibungslose Navigation zu ermöglichen, werden Ihre Cookie-Präferenzen über die hier aufgeführten IBM Web-Domains hinweg gemeinsam genutzt.
Beispieltopologien für die NSX-T-Zielumgebung
VMware VMware Cloud Foundation for Classic – Automated instanzen bieten eine standardmäßige VMware NSX-T™-Topologie mit einem einzelnen NSX-T-Edge-Cluster, der ein einzelnes Tier-0 ( T0 ) und Tier-1 ( T1 )-Gateway umfasst. Sie haben mehrere Optionen zum Erstellen und Anpassen der Overlay-Topologie. Sie können auch neue NSX-T-Edge-Cluster bereitstellen und neue Gateways für Tier-0 (T0) und Tier-1 (T1) bereitstellen.
Die folgenden Beispiele zeigen, wie diese Topologien an Ihre Anforderungen angepasst werden können.
Die automatisierte Bereitstellung bietet einen einzelnen NSX-T-Workload-Edge-Cluster mit zwei Edge-Transportknoten. Erweiterte Topologien können zusätzliche NSX-T-Edge-Transportknoten und -Cluster erfordern.
Einzelstandort mit Einzelmieter
Der häufigste Anwendungsfall und das häufigste Muster für die Netzwerkbereitstellung ist die Einzelplatzlösung mit nur einem Mandanten. Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt eine Beispieltopologie nach diesem Modell bereit, die einzelne Tier-0 und Tier-1 Gateways und einige NSX-T Overlay-Segmente als Ausgangspunkt enthält. Diese Topologie ist hoch skalierbar und kann automatisiert werden.
Diese Optionen eignen sich für Kunden mit Workloads, die in einem einzigen Rechenzentrum und mit einem einzigen Mieter ausgeführt werden und keine überlappenden IP-Adressen innerhalb ihrer eigenen Workloads haben.
Überlappende IP-Adressen beziehen sich auf Overlay-Segmente zwischen Kundenumgebungen, die auf der Instanz VMware Cloud Foundation for Classic – Automated laufen.
Das folgende Diagramm zeigt ein Beispiel für eine Kundenimplementierung, die die Standardtopologie verwendet, wenn die Segmente dem Tier-1-Gateway zugeordnet sind. Bei Bedarf können Sie dem vorhandenen Tier-1-Gateway weitere Segmente hinzufügen oder weitere Tier-1-Gateways in denselben NSX-T-Edge-Clustern hinzufügen.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung setzt eine beispielhafte Single-Site-Topologie ein, die den Prinzipien folgt, die in diesem Modell vorgestellt werden. Die Bereitstellung umfasst ein einzelnes vCenter und drei NSX-T-Manager, die im Cluster am ursprünglichen Standort des IBM Cloud-Rechenzentrums bereitgestellt werden.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt zwei Edge-Cluster-Transportknoten und einen einzelnen Edge-Cluster für Ihre Tier-0 und Tier-1 Gateways bereit.
- Das Tier-0-Gateway stellt Funktionen für Nord-Süd-Routing bereit und der Zugriff auf das private IBM Cloud-Netz wird über seine Uplinks bereitgestellt.
- Der Zugang zum privaten Netz erfolgt über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN des privaten Netzes IBM Cloud verbunden sind. Die Weiterleitung an IBM Cloud-Services verwendet diese Uplinks. IP-Adressen für die Uplinks werden durch Automatisierung des von IBM Cloud verwalteten 10/8-Adressraums bereitgestellt.
- Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, wird der Zugang zum öffentlichen Netz über öffentliche Uplinks bereitgestellt. Sie sind einem portierbaren Teilnetz in einem öffentlichen VLAN im öffentlichen IBM Cloud-Netz zugeordnet. Das Routing zum Internet nutzt diese Uplinks, und die öffentlichen IP-Adressen für die Uplinks werden von der Automatisierung bereitgestellt.
- Ein einzelnes Tier-1-Gateway wird von der Automatisierung für die Workloads bereitgestellt. Sie können diese Topologie verwenden oder anpassen, indem Sie neue Tier-1-Gateways bereitstellen.
- Sie können die Standardtopologie erweitern, indem Sie dem vorhandenen Tier-1-Gateway (oder den von Ihnen bereitgestellten neuen Tier-1-Gateways) neue Segmente hinzufügen. Die Routenanzeigen zwischen T1 und T0-Gateways können von Ihnen vollständig angepasst und von NSX-T ausgeführt werden. Es ist kein Routing-Protokoll erforderlich oder wird zwischen T1- und T0-Anzeigen verwendet.
Das folgende Diagramm zeigt ein Beispiel einer Kundenimplementierung unter Verwendung der Standardtopologie. Beachten Sie, dass die Segmente direkt an das Tier-0-Gateway angehängt sind. Bei Bedarf können Sie weitere Segmente zum Tier-0-Gateway hinzufügen oder das Tier-1-Gateway löschen, das von der Automatisierung bereitgestellt wird.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung setzt eine beispielhafte Single-Site-Topologie ein, die den Prinzipien folgt, die in diesem Modell vorgestellt werden. Die Bereitstellung umfasst ein einzelnes vCenter und drei NSX-T-Manager, die im Cluster am ursprünglichen Standort des IBM Cloud-Rechenzentrums bereitgestellt werden.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt zwei Edge-Cluster-Transportknoten und einen einzelnen Edge-Cluster für Ihre Tier-0 und Tier-1 Gateways bereit.
- Das Tier-0-Gateway stellt Funktionen für Nord-Süd-Routing bereit und der Zugriff auf das private IBM Cloud-Netz wird über seine Uplinks bereitgestellt.
- Der Zugang zum privaten Netz erfolgt über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN des privaten Netzes IBM Cloud verbunden sind. Die Weiterleitung an IBM Cloud-Services verwendet diese Uplinks. IP-Adressen für die Uplinks werden durch Automatisierung des von IBM Cloud verwalteten 10/8-Adressraums bereitgestellt.
- Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, wird der Zugang zum öffentlichen Netz über öffentliche Uplinks bereitgestellt. Sie sind einem portierbaren Teilnetz in einem öffentlichen VLAN im öffentlichen IBM Cloud-Netz zugeordnet. Das Routing zum Internet nutzt diese Uplinks, und die öffentlichen IP-Adressen für die Uplinks werden von der Automatisierung bereitgestellt.
- Sie können die Standardtopologie erweitern, indem Sie dem vorhandenen Tier-0-Gateway neue Segmente hinzufügen. Sie können das Tier-1-Gateway löschen, das von der Automatisierung bereitgestellt wird, wenn es in Ihrer Topologie nicht benötigt wird.
Multi-Tenant mit einzelnem Standort
Das Single-Site-Multitenant-Muster bietet ein einfaches, hoch skalierbares Muster, wenn Sie mehrere Mandanten benötigen. Beispiel: Verschiedene Unternehmensbereiche, die eine Routentabellenisolation erfordern oder in Konflikt stehende IP-Adressräume haben. Dieses Bereitstellungsmuster verwendet die Basistopologie, die von IBM Cloud VMware Cloud Foundation for Classic – Automated automation bereitgestellt wird. Dies schließt einzelne Tier-0- und Tier-1-Gateways und einige NSX-T-Overlay-Segmente als Ausgangspunkt ein. Wenn Sie mehrere Tenants haben, können Sie sie aufteilen, indem Sie mehrere Tier-1-Gateways verwenden und Routing-Anzeigen steuern und NAT (Network Address Translation) verwenden.
Diese Option eignet sich für Kunden mit Workloads, die in mehreren Rechenzentren auf einem einzelnen Tenant ausgeführt werden und sich überschneidende IP-Adressen in ihren eigenen Workloads haben.
Überlappende IP-Adressen beziehen sich auf Overlay-Segmente zwischen Kundenumgebungen, die auf der Instanz VMware Cloud Foundation for Classic – Automated laufen.
Das folgende Diagramm zeigt ein Beispiel für eine Multi-Tenant-Implementierung unter Verwendung der Standardtopologie. Außerdem sehen Sie, wie Sie diese für ein einfaches Multi-Tenant-Muster erweitern können. Sie können mehrere Tier-1-Gateways manuell über NSX-T implementieren und jedes Tenantsegment zu seinem eigenen Tier-1-Gateway hinzufügen.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung setzt eine beispielhafte Single-Site-Topologie ein, die den in diesem Modell vorgestellten Prinzipien folgt. Die Bereitstellung umfasst ein einzelnes vCenter und drei NSX-T-Manager, die im Cluster am ursprünglichen Standort des IBM Cloud-Rechenzentrums bereitgestellt werden.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt zwei Edge-Cluster-Transportknoten und einen einzelnen Edge-Cluster für Ihre Tier-0 und Tier-1 Gateways bereit.
- Das Tier-0-Gateway stellt Funktionen für Nord-Süd-Routing bereit und der Zugriff auf das private IBM Cloud-Netz wird über seine Uplinks bereitgestellt.
- Der Zugang zum privaten Netz erfolgt über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN des privaten Netzes IBM Cloud verbunden sind. Die Weiterleitung an IBM Cloud-Services verwendet diese Uplinks. IP-Adressen für die Uplinks werden durch Automatisierung des von IBM Cloud verwalteten 10/8-Adressraums bereitgestellt.
- Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, wird der Zugang zum öffentlichen Netz über öffentliche Uplinks bereitgestellt. Sie sind einem portierbaren Teilnetz in einem öffentlichen VLAN im öffentlichen IBM Cloud-Netz zugeordnet. Das Routing zum Internet nutzt diese Uplinks, und die öffentlichen IP-Adressen für die Uplinks werden von der Automatisierung bereitgestellt.
- Ein einzelnes Tier-1-Gateway wird von der Automatisierung für die Workloads bereitgestellt. Sie können diese Topologie verwenden und erweitern, indem Sie neue Tier-1-Gateways hinzufügen.
- Sie können dem vorhandenen Tier-1-Gateway (oder den anderen von Ihnen bereitgestellten Tier-1-Gateways) neue Tenantsegmente hinzufügen. Die Routenanzeigen zwischen T1 und T0-Gateways können von Ihnen vollständig angepasst und von NSX-T ausgeführt werden. Es ist kein Routing-Protokoll erforderlich oder wird zwischen T1- und T0-Anzeigen verwendet. Sie können steuern, welche Routen dem Tier-0 zugänglich gemacht werden. Sie können auch NAT verwenden. Jedes Tier-1-Gateway kann beispielsweise über eine oder mehrere öffentliche IP-Adressen für eingehenden oder abgehenden öffentlichen Datenverkehr verfügen, die für NAT verwendet werden sollen.
Sie können Edge-Knoten im ursprünglichen Cluster für die Skalierbarkeit bei Bedarf manuell bereitstellen. Sie können auch neue Edge-Cluster bereitstellen, um neue Tier-1-Gateways manuell zu hosten.
Tier-0-Gateways unterstützen VRF Lite, das bei Bedarf verwendet werden kann, um komplexere Topologien zur Isolierung von Routingtabellen auf Tier-0-Ebene zu unterstützen. Weitere Einzelheiten zu den Möglichkeiten und Einschränkungen finden Sie in der Dokumentation VMware®.
Multisite Einzelmieter
Multisite Single-Tenant ist ein gängiger Anwendungsfall und ein gängiges Muster für die Netzwerkbereitstellung. Diese Topologie ermöglicht eine nahtlose Standortwiederherstellung mithilfe von Protokollen für dynamisches Routing, wie z. B. BGP. Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt die Multisite-Topologie nicht automatisch bereit. Sie können jedoch die standardmäßige Single-Site-Topologie nach der ersten Bereitstellung von VMware Cloud Foundation for Classic – Automated anpassen. Wenn die Rechenkapazität im erforderlichen Rechenzentrum ausreicht, können Sie die erforderlichen zusätzlichen Edge-Knoten manuell implementieren. Anschließend können Sie über NSX-T einen neuen Edge-Cluster für die Tier-0- und Tier-1-Gateways erstellen. Diese Overlay-Topologie ist hoch skalierbar und kann automatisiert werden, z. B. mithilfe von Ansible und Terraform.
Diese Option eignet sich für Kunden mit Workloads, die in mehreren Rechenzentren auf einem einzelnen Tenant ausgeführt werden und keine sich überschneidende IP-Adressen innerhalb ihrer eigenen Workloads haben.
Überlappende IP-Adressen beziehen sich auf Overlay-Segmente zwischen Kundenumgebungen, die auf der Instanz VMware Cloud Foundation for Classic – Automated laufen.
Das folgende Diagramm zeigt ein Beispiel für eine Multisite-Single-Tenant-Netzwerktopologie. Es besteht aus einem zweischichtigen Tier-0 Design mit drei Randclustern. Ziehen Sie hierbei zwei Edge-Cluster in den beiden Rechenzentren oder Zonen in einer Mehrzonenregion in Betracht. Außerdem ein Edge-Cluster, der in der Mehrzonenregion mit Edge-Knoten in jeder teilnehmenden Zone oder jedem teilnehmenden Rechenzentrum bereitgestellt wird.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt eine Einzelstandortlösung bereit, die manuell erweitert werden kann, um die angestrebte Multisite-Topologie zu unterstützen. Die Bereitstellung umfasst ein einzelnes vCenter und drei NSX-T-Manager, die im Cluster am ursprünglichen Standort des IBM Cloud-Rechenzentrums bereitgestellt werden. Sie müssen die Rechenkapazität erweitern, damit Ressourcen im anderen IBM Cloud-Rechenzentrum oder in der Zone in der jeweiligen IBM Cloud-Region mit mehreren Zonen verfügbar sind.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt zwei Edge-Cluster-Transportknoten und einen einzelnen Edge-Cluster für Ihre Tier-0 und Tier-1 Gateways bereit. Sie benötigen das Tier-1-Standardgateway nicht und es kann entfernt werden.
- Im anfänglichen Rechenzentrum IBM Cloud erfolgt der Zugang zum privaten Netzwerk über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN im privaten Netzwerk IBM Cloud verbunden sind. Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, wird der Zugang zum öffentlichen Netz über öffentliche Uplinks bereitgestellt. Sie sind einem portierbaren Teilnetz in einem öffentlichen VLAN im öffentlichen IBM Cloud-Netz zugeordnet. Die Uplinks verfügen über bestimmte IP-Adressen für dieses Rechenzentrum und können nicht zwischen den Rechenzentren verschoben werden.
- Sie müssen zwei zusätzliche Edge-Cluster-Transportknoten manuell einrichten. Außerdem müssen Sie einen neuen Edge-Cluster für Ihre Tier-0- und Tier-1-Gateways in den zweiten IBM Cloud-Rechenzentrumshosts erstellen.
- Im zweiten Rechenzentrum IBM Cloud erfolgt der Zugriff auf das private Netzwerk über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN im privaten Netzwerk IBM Cloud verbunden sind. Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, erfolgt der Zugang zum öffentlichen Netz über öffentliche Uplinks, die mit einem portablen Subnetz in einem öffentlichen VLAN im öffentlichen Netz IBM Cloud verbunden sind. Die Uplinks verfügen über bestimmte IP-Adressen für dieses Rechenzentrum und können nicht zwischen den Rechenzentren verschoben werden.
- Sie müssen mindestens zwei Edge-Cluster-Transportknoten im regionalen Edge-Cluster manuell bereitstellen. Ziehen Sie mindestens einen in jeder Zone oder jedem Rechenzentrum in Betracht, um eine hohe Verfügbarkeit (HA) zu gewährleisten. Erstellen Sie anschließend mithilfe dieser Edge-Transportknoten einen neuen Edge-Cluster und erstellen Sie Ihr regionales Tier-0 in diesem Cluster. Sie können auswählen, welches Rechenzentrum (oder welcher Edge-Knoten) Ihr bevorzugter Tier-0-Pfad im regionalen Cluster ist.
- Erstellen Sie ein Overlay-Transit und erstellen Sie Uplinks in Tier-0-Gateways im Transitsegment. Richten Sie dynamisches Routing zwischen den Tier-0-Gateways ein. BGP ist das bevorzugte Routing-Protokoll.
- Erstellen Sie Ihre Tier-1-Gateways im regionalen Edge-Cluster. Sie können auswählen, welches Rechenzentrum (oder welcher Edge-Knoten) Ihr bevorzugter Tier-1-Pfad im regionalen Cluster ist.
- Sie können Ihre Segmente an diese Ebene von Tier-1-Gateways anhängen. Sie können mehrere Segmente erstellen und diese über das Tier-1-Gateway für die Northbound-Tier-0-Gateways zugänglich machen.
Dieses Netztopologiebeispiel berücksichtigt die Management- und Steuerebene (vCenter und NSX-Manager) nicht. Die Steuerungsebene von HA wird in einem anderen Verfügbarkeitsmuster behandelt.
Der Hauptgrund, warum Sie zwei Ebenen benötigen, ist die physische Nord-Süd-Konnektivität in den Rechenzentren. Jedes Rechenzentrum muss über eigene private und öffentliche VLANs und IP-Adressen für die Uplinks verfügen. Diese IP-Adressen können nicht zwischen den Rechenzentren verschoben werden. Wenn Sie öffentliche Konnektivität in dieser Topologie verwenden, ist beim Routing und der Netzadressumsetzung deshalb Ihre Aufmerksamkeit gefragt.
Multi-Tenant mit mehreren Standorten
Multisite Single-Tenant ist auch ein Anwendungsfall und ein Netzwerkeinsatzmuster, bei dem die Mieter eine Lösung mit konkurrierenden IP-Räumen und vollständiger Isolierung der Routingtabelle benötigen. Diese Topologie ermöglicht eine nahtlose Standortwiederherstellung mithilfe von Protokollen für dynamisches Routing, wie z. B. BGP. Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt die Multisite-Topologie nicht automatisch bereit. Sie können jedoch die standardmäßige Single-Site-Topologie nach der ersten Bereitstellung von VMware Cloud Foundation for Classic – Automated anpassen. Wenn die Rechenkapazität im erforderlichen Rechenzentrum ausreicht, können Sie die erforderlichen zusätzlichen Edge-Knoten manuell implementieren. Anschließend können Sie einen neuen Edge-Cluster für die Tier-0- und Tier-1-Gateways über NSX-T erstellen. Diese Overlay-Topologie ist hoch skalierbar und kann automatisiert werden, z. B. mithilfe von Ansible und Terraform.
Diese Option eignet sich für Kunden mit Workloads, die in mehreren Rechenzentren auf einem einzelnen Tenant ausgeführt werden und sich überschneidende IP-Adressen in ihren eigenen Workloads haben.
Überlappende IP-Adressen beziehen sich auf Overlay-Segmente zwischen Kundenumgebungen, die auf der Instanz VMware Cloud Foundation for Classic – Automated laufen.
Das folgende Diagramm zeigt ein Beispiel einer Multi-Tenant-Topologie mit mehreren Standorten. Es besteht aus einem zweischichtigen Tier-0 Design mit drei Randclustern. Die Trennung der Routing-Tabelle erfolgt auf Tier-1 und optional auch auf regionaler Tier-0-Ebene. Ziehen Sie hierbei zwei Edge-Cluster in den beiden Rechenzentren oder Zonen in einer Mehrzonenregion in Betracht. Außerdem ein Edge-Cluster, der in der Mehrzonenregion mit Edge-Knoten in jeder teilnehmenden Zone oder jedem teilnehmenden Rechenzentrum bereitgestellt wird.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt eine Einzelstandortlösung bereit, die manuell erweitert werden kann, um die angestrebte Multisite-Topologie zu unterstützen. Die Bereitstellung umfasst ein einzelnes vCenter und drei NSX-T-Manager, die im Cluster am ursprünglichen Standort des IBM Cloud-Rechenzentrums bereitgestellt werden. Sie müssen die Rechenkapazität erweitern, damit Ressourcen im anderen IBM Cloud-Rechenzentrum oder in der Zone in der jeweiligen IBM Cloud-Region mit mehreren Zonen verfügbar sind.
- Die VMware Cloud Foundation for Classic – Automated Automatisierung stellt zwei Edge-Cluster-Transportknoten und einen einzelnen Edge-Cluster für Ihre Tier-0 und Tier-1 Gateways bereit. Das standardmäßige Tier-1-Gateway ist nicht erforderlich und kann entfernt werden.
- Im anfänglichen Rechenzentrum IBM Cloud erfolgt der Zugang zum privaten Netzwerk über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN im privaten Netzwerk IBM Cloud verbunden sind. Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, erfolgt der Zugang zum öffentlichen Netz über öffentliche Uplinks, die mit einem portablen Subnetz in einem öffentlichen VLAN im öffentlichen Netz IBM Cloud verbunden sind. Die Uplinks verfügen über bestimmte IP-Adressen für dieses Rechenzentrum und können nicht zwischen den Rechenzentren verschoben werden.
- Sie müssen zwei zusätzliche Edge-Cluster-Transportknoten manuell einrichten. Außerdem müssen Sie einen neuen Edge-Cluster für Ihre Tier-0- und Tier-1-Gateways in den zweiten IBM Cloud-Rechenzentrumshosts erstellen.
- Im zweiten Rechenzentrum IBM Cloud erfolgt der Zugriff auf das private Netzwerk über private Uplinks, die mit einem portablen Subnetz in einem privaten primären VLAN im privaten Netzwerk IBM Cloud verbunden sind. Wenn Sie Ihre Instanz mit öffentlichen Schnittstellen bereitstellen, erfolgt der Zugang zum öffentlichen Netz über öffentliche Uplinks, die mit einem portablen Subnetz in einem öffentlichen VLAN im öffentlichen Netz IBM Cloud verbunden sind. Die Uplinks verfügen über bestimmte IP-Adressen für dieses Rechenzentrum und können nicht zwischen den Rechenzentren verschoben werden.
- Sie müssen mindestens zwei Edge-Cluster-Transportknoten im regionalen Edge-Cluster manuell bereitstellen. Ziehen Sie mindestens einen in jeder Zone oder jedem Rechenzentrum für HA in Betracht. Erstellen Sie anschließend mithilfe dieser Edge-Transportknoten einen neuen Edge-Cluster und erstellen Sie Ihr regionales Tier-0 in diesem Cluster. Sie können auswählen, welches Rechenzentrum (oder welcher Edge-Knoten) Ihr bevorzugter Tier-0-Pfad im regionalen Cluster ist. Sie können Routing-Tabellen auf dieser Ebene mithilfe der VRF-Lite-Funktion im Tier-0-Gateway trennen. Weitere Einzelheiten finden Sie in der Broadcom®-Dokumentation.
- Erstellen Sie manuell ein Overlay-Transitsegment und erstellen Sie Uplinks in Tier-0-Gateways im Transitsegment. Richten Sie dynamisches Routing zwischen den Tier-0-Gateways ein. BGP ist das bevorzugte Routing-Protokoll. Wenn Sie VRF Lite-Funktionalität im Tier-0-Gateway verwenden, können Sie je nach Design mehrere Transitsegmente verwenden.
- Erstellen Sie anschließend Ihre Tier-1-Gateways im regionalen Edge-Cluster. Sie können auswählen, welches Rechenzentrum (oder welcher Edge-Knoten) Ihr bevorzugter Tier-1-Pfad im regionalen Cluster ist. Sie können Routing-Tabellen auf dieser Ebene trennen und entscheiden, welche Routen für das Northbound-Tier-0 zugänglich gemacht werden. Wie in den anderen Multi-Tenant-Mustern können Sie auch NAT verwenden.
- Sie können Ihre Segmente an diese Ebene von Tier-1-Gateways anhängen. Sie können mehrere Segmente erstellen und diese über das Tier-1-Gateway für die Northbound-Tier-0-Gateways zugänglich machen.
Dieses Netztopologiebeispiel berücksichtigt die Management- und Steuerebene (vCenter und NSX-Manager) nicht. Die Steuerungsebene von HA wird in einem anderen Verfügbarkeitsmuster behandelt.
Tier-0-Gateways unterstützen VRF Lite, das bei Bedarf zur Unterstützung komplexerer Topologien zum Isolieren von Routing-Tabellen auch auf Tier-0-Ebene verwendet werden kann. Weitere Informationen zu den Möglichkeiten und Einschränkungen finden Sie in der Broadcom-Dokumentation.
Der Hauptgrund, warum Sie zwei Ebenen benötigen, ist die physische Nord-Süd-Konnektivität in den Rechenzentren. Jedes Rechenzentrum muss über eigene private und öffentliche VLANs und IP-Adressen für die Uplinks verfügen. Diese IP-Adressen können nicht zwischen den Rechenzentren verschoben werden. Wenn Sie öffentliche Konnektivität in dieser Topologie verwenden, ist beim Routing und der Netzadressumsetzung deshalb Ihre Aufmerksamkeit gefragt.
Überlegungen zur Auswahl einer Overlay-Netztopologie
VMware NSX-T bietet viele Möglichkeiten zum Aufbau von Netzwerktopologien, und die Standard-Netzwerktopologie ist für viele Anwendungsfälle nützlich. Sie können in der Regel damit beginnen und die Standardtopologie erweitern, wenn sich Ihre Anforderungen ändern. Sobald die Erstimplementierung abgeschlossen ist, verwendet die IBM Cloud-Automatisierung keine Workload-Overlay-Topologie und Sie können die Beispieltopologie Ihren Anforderungen entsprechend ändern. Wenn Sie die Konfiguration ändern, bieten die Standard-Uplinks eine Basis-Routing-Konnektivität zu IBM Cloud privaten und öffentlichen Netzwerken. Wenn Sie die IP-Adressen oder das Routing ändern, verlieren Ihre Overlay-Workloads möglicherweise die Konnektivität.
IBM Cloud bietet eine flexible Methode zum Erstellen der benötigten NSX-T-Topologie. Wenn Sie Ihre eigene Overlay-Netzlösung entwerfen, ist es wichtig zu wissen, dass Sie möglicherweise neue NSX-T-Edge-Knoten und neue NSX-T-Edge-Cluster manuell bereitstellen. Oder verwenden Sie Ansible und Terraform, um Ihre Anforderungen zu erfüllen. Sie können dies tun, indem Sie die Broadcom-Dokumentation und die Design-Richtlinien nach der ersten Bereitstellung befolgen.
Die meisten Inhalte in den VMware NSX-T-Design-Richtlinien und der Dokumentation können auf IBM Cloud angewendet werden. Besondere Aufmerksamkeit ist erforderlich, wenn Sie z. B. die Anzahl der erforderlichen VLANs und die Verwendung von gestreckten VLANs im Underlay zwischen Rechenzentren in Regionen mit mehreren Zonen berücksichtigen. Außerdem darf das private IBM Cloud-Netz nicht als ToR-Switch (Top of the Rack) betrachtet werden. Der Back-End-Kundenrouter (BCR) bietet standardmäßig keine Unterstützung für dynamisches Routing (BGP).