Um die NSX Application Platform erfolgreich zu installieren und die NSX-Funktionen zu aktivieren, die sie hostet, müssen Sie die Bereitstellungsumgebung so vorbereiten, dass sie die erforderlichen Mindestressourcen erfüllt.

Sie müssen die in den folgenden Abschnitten aufgeführten Voraussetzungen erfüllen, bevor Sie mit der Bereitstellung der NSX Application Platform beginnen.

Anforderung: NSX-Version

Bestätigen Sie, dass die verwendete NSX-Produktversion mit der NSX Application Platform-Version kompatibel ist, die Sie zusammen mit den zugehörigen NSX-Funktionen (NSX Intelligence, NSX Network Detection and Response, NSX Malware-Schutz und NSX Metrics) bereitstellen möchten.

Die Versionierung der NSX-Funktionen, die auf NSX Application Platform gehostet sind, stimmt mit der NSX Application Platform-Versionsnummer und nicht mit der NSX-Produktversionsnummer überein.

Wichtig:

In einer NSX-Verbund-Umgebung können Sie die NSX Application Platform nur auf Lokaler Managers bereitstellen. Sie können die NSX Application Platform nicht mithilfe von Globaler Managers bereitstellen. Sie können nur mithilfe eines Lokaler Manager auf die NSX Application Platform zugreifen.

Um zu ermitteln, welche NSX Application Platform-Version Sie mit welcher NSX-Version bereitstellen können, verwenden Sie die folgende Kompatibilitätsmatrix.

NSX-Version

Kompatible NSX Application Platform-Version

3.2.x

3.2.0, 3.2.1, 4.0.1, 4.1.1

4.0.0.1

3.2.1, 4.0.1, 4.1.1

4.0.1, 4.1.0

4.0.1, 4.1.1

4.1.1, 4.1.2 4.1.1
Verwenden Sie die folgenden Informationen, um zu bestimmen, welche Dokumentation für Ihren spezifischen NSX Application Platform-Aktivierungsworkflow verwendet werden soll.
  • Wenn Sie eine vollständig neue NSX-Installation durchführen müssen, lesen Sie die Installationsanweisungen im Installationshandbuch für NSX für Version 3.2.x oder höher, die Sie in der Dokumentation zu VMware NSX finden.
  • Wenn Sie ein Upgrade von Version 3.2 oder höher der NSX Application Platform zu Version 4.1.1 durchführen, finden Sie weitere Informationen unter Aktualisieren der NSX Application Platform.
  • Wenn Sie ein Upgrade von NSX 3.1.x oder früher durchführen, ohne NSX Intelligence installiert zu haben, finden Sie weitere Informationen im Upgrade-Handbuch für NSX in der Dokumentation zu VMware NSX.
  • Wenn Sie ein Upgrade von NSX 3.1.x oder früher mit einer Installation von NSX Intelligence 1.2.x oder früher durchführen, müssen Sie ihre aktuelle NSX Intelligence-Installation vorbereiten, bevor Sie ein Upgrade auf NSX Intelligence 3.2 oder höher und auf NSX 3.2 oder höher durchführen. Weitere Informationen finden Sie in derAktivieren und Aktualisieren von VMware NSX Intelligence-Dokumentation für Version 3.2 oder höher in der Dokumentation zu VMware NSX Intelligence.

Anforderung: gültige NSX- oder NSX Data Center-Lizenz

Für die Bereitstellung von NSX Application Platform muss die aktuell verwendete NSX Manager-Sitzung während der NSX Application Platform-Bereitstellung über eine gültige Lizenz verfügen.

Eine Liste gültiger Lizenzen finden Sie unter Lizenzanforderung für NSX Application Platform-Bereitstellung.

Gültige NSX-Benutzerrolle

Um die NSX Application Platform bereitzustellen, müssen Sie über die Rollenberechtigungen Unternehmensadministrator verfügen.

Gültige, von einer Zertifizierungsstelle signierte Zertifikate

  • Wenn Ihre NSX Manager-Appliance von einer Zertifizierungsstelle signierte Zertifikate mit einer Teilkette auf dem NSX Manager Unified Appliance-Cluster verwendet, müssen Sie das Zertifikat durch eine vollständige Zertifikatskette ersetzen. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 78317.

  • Wenn Sie mehrere NSX Manager-Appliances verwenden, muss Ihre Umgebung eine der folgenden Zertifikatvoraussetzungen erfüllen.

    • Alle -Appliances müssen dasselbe SSL-Zertifikat verwenden.

    • Für jede Appliance muss ein dediziertes SSL-Zertifikat ausgestellt werden, wobei der allgemeine Name (CN) des Zertifikats für alle Knoten eindeutig sein muss.

    • Darüber hinaus muss bei der Verwendung einer virtuellen IP (VIP) das Cluster-Zertifikat entweder dasselbe sein, das von allen einzelnen Appliances verwendet wird, oder es muss für alle Knoten eindeutig sein.

Erforderliche Ressourcen für den Kubernetes-Cluster

  • VMware unterstützt eine NSX Application Platform-Bereitstellung auf einem Tanzu Kubernetes Grid (TKG)-Cluster in Supervisor oder einem Upstream-Kubernetes-Cluster.
    Wichtig: Upstream-Kubernetes bezieht sich auf das ursprüngliche Open-Source-Kubernetes, das von der Cloud Native Computing Foundation verwaltet wird, und deckt keine Distributionen oder Versionen von Kubernetes ab, die nicht explizit in der folgenden Tabelle aufgeführt sind.

    Informationen zur Installation und Konfiguration von TKG-Clustern auf Supervisor finden Sie unter Installieren und Konfigurieren von vSphere with Tanzu (Version 8.0) oder auf der Website der VMware vSphere-Dokumentation für andere Versionen.

    VMware hat die folgenden Versionen getestet und unterstützt diese.

    NSX Application Platform-Version

    TKG-Cluster auf Supervisor-Version

    Upstream-Kubernetes-Cluster-Version

    3.2.0, 3.2.1

    1.17–1.21

    1.17–1.21

    4.0.1

    1.20–1.22

    1.20–1.24

    4.1.1 1.21–1.24 1.21–1.24
  • Ihr Infrastrukturadministrator muss den Kubernetes-Cluster konfigurieren, auf dem Sie die NSX Application Platform und die NSX-Funktionen bereitstellen können, die die Plattform hostet. Dem verwendeten Kubernetes-Cluster müssen ausreichend Ressourcen zugeteilt werden, um die NSX Application Platform-Pods bereitzustellen. Da jede unterstützte NSX-Funktion bestimmte Ressourcenanforderungen hat, legen Sie fest, welche der gehosteten NSX-Funktionen Sie verwenden möchten.

    Im Thema Systemanforderungen für NSX Application Platform finden Sie Details zu den unterstützten Formfaktoren und deren Ressourcenanforderungen.

  • Wichtig: Der Kubernetes-Gastcluster, der für die NSX Application Platform verwendet wird, muss eine Standarddienstdomäne von cluster.local verwenden. Dies ist der Standardwert und wird in der Clusterkonfiguration definiert:
    settings: network: serviceDomain: cluster.local 
    Ändern Sie diesen Wert für NSX Application Platform nicht und legen Sie keine nicht standardmäßige Dienstdomäne fest.
  • Ihr Infrastrukturadministrator muss auch die folgenden Infrastrukturen im Voraus installieren und konfigurieren.

    • Container-Netzwerkschnittstelle (CNI), wie z. B. Antrea, Calico oder Flannel.

    • Container-Speicherschnittstelle (CSI). Damit Sie dynamische Volumes bereitstellen können, muss im verwendeten Kubernetes-Cluster eine verfügbare Speicherklasse vorhanden sein. Um das Datenspeichervolume vertikal hochzuskalieren, muss die Speicherklasse die Größenänderung von Volumes unterstützen.

Anforderung Internetzugriff

Stellen Sie sicher, dass Ihr NSX-System auf die öffentliche VMware-gehostete Registrierung und das Repository zugreifen kann, in der Sie die gepackte NSX Application Platform als Helm Chart oder Docker-Images abrufen können. Der direkte Internetzugriff ist nur während der Installations- und Upgrade-Vorgänge erforderlich. Dieser Zugriff ist auf den ausgehenden Zugriff auf TCP-Port 443 (HTTPS) auf https://projects.registry.vmware.com beschränkt. Das dient dem Zweck, auf die Helm-Diagramme und Docker-Images der NSX Application Platform zuzugreifen. Es ist kein eingehender oder dauerhafter ausgehender Zugriff erforderlich.

Ausgehender Internetzugriff ist sowohl für die NSX Unified Appliance-VMs als auch für die Worker-Knoten des Gastclusters der NSX Application Platform erforderlich.

Wenn Sie Ihre NSX-Umgebung über die Registerkarte System > Allgemeine Einstellungen > Internet-Proxy-Server für die Verwendung eines Internet-Proxy-Servers konfiguriert haben, sollten Sie beachten, dass die NSX Application Platform nicht unter Verwendung eines Internet-Proxy-Servers bereitgestellt werden kann. Wenn Ihr Kubernetes-Cluster keinen Zugriff auf das Internet hat oder Sie über Sicherheitseinschränkungen verfügen, sehen Sie sich die nächste optionale Anforderung für eine optionale private Containerregistrierung mit Diagramm-Repository-Dienst an.

(Optionale Anforderung) Private Container-Registrierung mit Diagramm-Repository-Dienst

Zum vereinfachen des NSX Application Platform-Bereitstellungsvorgangs verwenden Sie die von VMware gehostete Registrierung und das Repository. Dieser Bereitstellungsvorgang verwendet nur eine ausgehende Verbindung und behält keine Kundendaten bei.

(Optional) Wenn Ihr Kubernetes-Cluster keinen Zugriff auf das Internet hat oder Sie über Sicherheitseinschränkungen verfügen, muss Ihr Infrastrukturadministrator eine private Containerregistrierung mit einem Diagramm-Repository-Dienst einrichten. Verwenden Sie diese private Containerregistrierung, um die NSX Application Platform Helm-Diagramme und Docker-Images hochzuladen, die für die Bereitstellung der NSX Application Platform erforderlich sind. VMware verwendet Harbor, um den Bereitstellungsprozess zu validieren, der eine private Containerregistrierung verwendet. Die NSX Application Platform-Bereitstellung basiert jedoch auf Standards. Weitere Informationen finden Sie unter Hochladen der NSX Application Platform-Docker-Images und Helm-Diagramme in eine private Container-Registrierung.

(Optionale Anforderung) URL für eine private Containerregistrierung

Wenn Sie eine private Containerregistrierung verwenden, rufen Sie von Ihrem Infrastrukturadministrator die URL für diese Registrierung ab. Sie verwenden diese URL während des Bereitstellungsvorgangs.

Anforderung: Kubernetes-Konfigurationsdatei

Sie müssen auch die Kubernetes-Konfigurationsdatei von Ihrem Infrastrukturadministrator beziehen. Für den sicheren Zugriff auf den Kubernetes-Cluster benötigen Sie die Datei kubeconfig während der NSX Application Platform-Bereitstellung für den NSX Manager. Damit Sie auf alle Ressourcen des genutzten Kubernetes-Clusters zugreifen können, muss die Datei kubeconfig über alle Berechtigungen verfügen.

Wichtig:

Die standardmäßige Datei kubeconfig in einem VMware vSphere®-with Tanzu Kubernetes-Cluster mit Gastzugriff enthält ein Token, das standardmäßig nach zehn Stunden abläuft. Obwohl sich dieses abgelaufene Token nicht auf die Funktionalität auswirkt, führt es zu einer Warnmeldung bezüglich veralteter Anmeldedaten. Um die Warnung zu vermeiden, erstellen Sie vor der Bereitstellung der NSX Application Platform auf einem TKG-Cluster in Supervisor mit Ihrem Infrastrukturadministrator ein langlebiges Token, das Sie während der NSX Application Platform-Bereitstellung verwenden können. Weitere Informationen zum Extrahieren des Tokens finden Sie unter Generieren einer Konfigurationsdatei für einen TKG-Cluster in Supervisor mit einem nicht ablaufenden Token.

Anforderung: Dienstname oder Schnittstellendienstname (FQDN)

Geben Sie während der NSX Application Platform-Bereitstellung einen vollqualifizierten Domänennamen (FQDN) in das Textfeld Dienstname einer NSX 3.2.0-Bereitstellung bzw. in das Textfeld Schnittstellendienstname einer Bereitstellung mit NSX 3.2.1 oder höher ein.

Der Wert für Dienstname oder Schnittstellendienstname wird als HTTPS-Endpoint für die Verbindung mit der NSX Application Platform verwendet.

Verwenden Sie einen der folgenden Workflows, um den FQDN-Wert abzurufen.

  • Sie müssen den FQDN vor der NSX Application Platform-Bereitstellung mit einer statischen IP-Adresse im DNS-Server konfigurieren. Die verwendete Kubernetes-Cluster-Infrastruktur muss statische IP-Adressen zuweisen können. Im Folgenden sind die unterstützten Kubernetes-Umgebungen aufgeführt.

    • MetalLB – ein externer Lastausgleichsdienst für Upstream-Kubernetes-Cluster.

    • VMware Tanzu® Kubernetes für VMware vSphere® 7.0 U2 und VMware vSphere 7.0 U3 mit NSX.

    • VMware vSphere with Tanzu mit vSphere-Netzwerk. Weitere Informationen finden Sie im VMware vSphere-Dokument Aktivieren der Arbeitslastverwaltung mit vSphere-Netzwerk.

  • Wenn Sie das externe DNS installiert haben (sehen Sie hierzu die WebseiteKubernetes SIGs - External DNS), müssen Sie nur den FQDN angeben, wenn Sie zur Eingabe eines Dienstnamens aufgefordert werden. Ihre Kubernetes-Infrastruktur konfiguriert den FQDN automatisch mit einer dynamischen IP-Adresse im DNS-Server.

    Die Arbeitslast-Steuerungsebene (Workload Control Plane, WCP) mit installierter externem DNS ist die unterstützte Kubernetes-Umgebung.

Anforderung: Nachrichtendienstname (für Bereitstellungen mit NSX 3.2.1 oder höher)

Der Wert für Nachrichtendienstname ist ein FQDN für den HTTPS-Endpoint, der zum Empfangen der optimierten Daten von den NSX-Datenquellen verwendet wird.

Erforderliche Ports und Protokolle

Stellen Sie sicher, dass die erforderlichen Ports auf Ihrem Kubernetes-Clusterhost für den Zugriff auf die NSX Application Platform geöffnet sind. Weitere Informationen finden Sie auf der Webseite zu VMware Ports and Protocols.

Erforderliche Kommunikation von Ihren Kubernetes-Clusterknoten

Stellen Sie sicher, dass die von Ihnen verwendeten Kubernetes-Clusterknoten die NSX Manager-Appliance erreichen können.

Anforderung: Systemzeitsynchronisierung

Synchronisieren Sie die Systemzeiten auf den Kubernetes-Clusterknoten und der von Ihnen verwendeten NSX Manager-Appliance.