Betriebliche Auswirkungen des NSX-Upgrades

Die Dauer des NSX-Upgrade-Vorgang hängt von der Anzahl Komponenten ab, die Sie in Ihrer Infrastruktur aktualisieren müssen. Bei einem Upgrade ist die Kenntnis des Betriebszustands der NSX-Komponenten erforderlich.

Der Upgrade-Vorgang verläuft wie folgt:

NSX Edge Cluster > Hosts > Management Plane.

Ab NSX 4.0.1.1 haben Sie die Flexibilität, die Reihenfolge für das Upgrade für Ihre Edge-Cluster und -Hosts zu ändern. Sie können während des Upgrades zwischen Gruppen von Hosts und Gruppen von Edge-Knoten wechseln. Das Upgrade für NSX Manager erfolgt erst, nachdem alle Edges und Hosts aktualisiert wurden.

NSX Edge-Cluster-Upgrade

Während des Upgrades	Nach dem Upgrade
Während des NSX Edge-Upgrades tritt möglicherweise die folgende Unterbrechung des Datenverkehrs auf: Der Nord-Süd-Datenpfad wird beeinträchtigt, wenn NSX Edge Teil des Datenpfads ist. Der Ost-West-Datenverkehr zwischen Tier-1-Routern mithilfe der NSX Edge-Firewall, NAT oder Load Balancing. Temporäre Unterbrechung von Layer 2 und Layer 3. Konfigurationsänderungen werden in NSX Manager nicht blockiert, jedoch möglicherweise verzögert.	Konfigurationsänderungen sind zulässig. Der aktualisierte NSX Edge-Cluster ist kompatibel mit den älteren Versionen der Management Plane und der Hosts. Im Rahmen des Upgrades eingeführte neue Funktionen können erst nach einem Upgrade der Management Plane konfiguriert werden. Führen Sie Nachprüfungen aus, um sicherzustellen, dass die aktualisierten NSX Edge-Cluster und NSX keine Fehler aufweisen.

Während des Upgrades

Nach dem Upgrade

Während des NSX Edge-Upgrades tritt möglicherweise die folgende Unterbrechung des Datenverkehrs auf:
- Der Nord-Süd-Datenpfad wird beeinträchtigt, wenn NSX Edge Teil des Datenpfads ist.
- Der Ost-West-Datenverkehr zwischen Tier-1-Routern mithilfe der NSX Edge-Firewall, NAT oder Load Balancing.
- Temporäre Unterbrechung von Layer 2 und Layer 3.
Konfigurationsänderungen werden in NSX Manager nicht blockiert, jedoch möglicherweise verzögert.

Konfigurationsänderungen sind zulässig.
Der aktualisierte NSX Edge-Cluster ist kompatibel mit den älteren Versionen der Management Plane und der Hosts.
Im Rahmen des Upgrades eingeführte neue Funktionen können erst nach einem Upgrade der Management Plane konfiguriert werden.
Führen Sie Nachprüfungen aus, um sicherzustellen, dass die aktualisierten NSX Edge-Cluster und NSX keine Fehler aufweisen.

Aktualisieren von Hosts

Während des Upgrades	Nach dem Upgrade
Für eigenständige ESXi-Hosts oder ESXi-Hosts, die Teil eines deaktivierten DRS-Clusters sind, versetzen Sie die Hosts in den Wartungsmodus. Wenn sich ein ESXi-Host, der Teil eines vollständig automatisierten DRS-Clusters ist, nicht im Wartungsmodus befindet, fordert der Upgrade-Koordinator den Wartungsmodus für den Host an. Das Tool vSphere-DRS-Tool migriert die VMs während des Upgrades zu einem anderen Host im selben Cluster und versetzt den Host in den Wartungsmodus. Bei einem direkten Upgrade müssen die Mandanten-VMs für einen ESXi-Host nicht ausgeschaltet werden. Während eines direkten Upgrades: Für VMs, die an einen logischen NSX-Switch angehängt sind, oder für VMs, die mit der verteilten Portgruppe einer VDS verbunden sind, die für NSX für vSphere vorbereitet sind, wird vMotion von VMs von und zu dem Host, auf dem ein Upgrade ausgeführt wird, nicht unterstützt. Das Erstellen neuer VMs wird auch auf den Hosts nicht unterstützt, auf denen gerade ein Upgrade durchgeführt wird. Konfigurationsänderungen für NSX Manager sind zulässig. Während eines direkten Upgrades der ESXi-Hosts kann es zu einer kurzen Unterbrechung des Datenverkehrs kommen. Für kritische Anwendungen, die Paketverlust nicht bewältigen können, wird ein Upgrade im Wartungsmodus empfohlen.	Schalten Sie die Mandanten-VMs von eigenständigen ESXi-Hosts oder ESXi-Hosts, die zu einem deaktivierten DRS-Clusters gehören und vor dem Upgrade abgeschaltet wurden, wieder ein oder aktivieren Sie sie erneut. Im Rahmen des Upgrades eingeführte neue Funktionen können erst nach einem Upgrade der Management Plane konfiguriert werden. Führen Sie Nachprüfungen aus, um sicherzustellen, dass die aktualisierten Hosts und NSX keine Fehler aufweisen.

Während des Upgrades

Nach dem Upgrade

Für eigenständige ESXi-Hosts oder ESXi-Hosts, die Teil eines deaktivierten DRS-Clusters sind, versetzen Sie die Hosts in den Wartungsmodus.
Wenn sich ein ESXi-Host, der Teil eines vollständig automatisierten DRS-Clusters ist, nicht im Wartungsmodus befindet, fordert der Upgrade-Koordinator den Wartungsmodus für den Host an. Das Tool vSphere-DRS-Tool migriert die VMs während des Upgrades zu einem anderen Host im selben Cluster und versetzt den Host in den Wartungsmodus.
Bei einem direkten Upgrade müssen die Mandanten-VMs für einen ESXi-Host nicht ausgeschaltet werden.
Während eines direkten Upgrades: Für VMs, die an einen logischen NSX-Switch angehängt sind, oder für VMs, die mit der verteilten Portgruppe einer VDS verbunden sind, die für NSX für vSphere vorbereitet sind, wird vMotion von VMs von und zu dem Host, auf dem ein Upgrade ausgeführt wird, nicht unterstützt. Das Erstellen neuer VMs wird auch auf den Hosts nicht unterstützt, auf denen gerade ein Upgrade durchgeführt wird.
Konfigurationsänderungen für NSX Manager sind zulässig.
Während eines direkten Upgrades der ESXi-Hosts kann es zu einer kurzen Unterbrechung des Datenverkehrs kommen. Für kritische Anwendungen, die Paketverlust nicht bewältigen können, wird ein Upgrade im Wartungsmodus empfohlen.

Schalten Sie die Mandanten-VMs von eigenständigen ESXi-Hosts oder ESXi-Hosts, die zu einem deaktivierten DRS-Clusters gehören und vor dem Upgrade abgeschaltet wurden, wieder ein oder aktivieren Sie sie erneut.
Im Rahmen des Upgrades eingeführte neue Funktionen können erst nach einem Upgrade der Management Plane konfiguriert werden.
Führen Sie Nachprüfungen aus, um sicherzustellen, dass die aktualisierten Hosts und NSX keine Fehler aufweisen.

Einschränkungen bei direktem Upgrade

Für ESXi Hosts mit Version 7.0 und höher wird das direkte Upgrade bei einem Upgrade von NSX 3.2 oder höher in den folgenden Szenarien nicht unterstützt:

Sie führen ein Upgrade eines vLCM-fähigen Clusters durch.
Auf dem ESXi-Host sind mehr als 1000 vNICs konfiguriert, und die vNICs der VM stellen eine Verbindung zu einem einzelnen VDS her. Wenn der Host über mehrere VDS für NSX verfügt, gilt dieser vNIC-Grenzwert pro VDS.
Layer 7-Firewallregeln oder Identitäts-Firewall-Regeln sind aktiviert.
Service Insertion wurde so konfiguriert, dass der Nord-Süd- oder der Ost-West-Datenverkehr umgeleitet wird. Informationen zum Deinstallieren von Service Insertion finden Sie unter Sicherheit im NSXAdministratorhandbuch.
Eine auf VProbe basierende Paketerfassung wird durchgeführt.
Der nsx-cfgagent-Dienst wird auf dem Host nicht ausgeführt.
IDS/IPS oder verteilter Malware-Schutz ist für Ihre NSX-Umgebung aktiviert.

Für ESXi-Hosts mit Versionen vor 7.0 wird in den folgenden Szenarien kein direktes Upgrade eines Hosts unterstützt:

Sie führen ein Upgrade eines vLCM-fähigen Clusters durch.
Auf dem Host sind mehrere N-VDS-Switches konfiguriert.
Auf dem ESXi-Host sind mehr als 1000 vNICs konfiguriert, und die vNICs der VM stellen eine Verbindung zu einem einzelnen VDS her. Wenn der Host über mehrere VDS für NSX verfügt, gilt dieser vNIC-Grenzwert pro VDS.
ENS ist auf dem Host-N-VDS-Switch konfiguriert.
vSAN (mit LACP) ist auf dem Host-N-VDS-Switch konfiguriert.
Layer 7-Firewallregeln oder Identitäts-Firewall-Regeln sind aktiviert.
Die VMkernel-Schnittstelle ist auf dem Overlay-Netzwerk konfiguriert.
Service Insertion wurde so konfiguriert, dass der Nord-Süd- oder der Ost-West-Datenverkehr umgeleitet wird. Informationen zum Deinstallieren von Service Insertion finden Sie unter Sicherheit im NSXAdministratorhandbuch.
Eine auf VProbe basierende Paketerfassung wird durchgeführt.
IDS/IPS oder verteilter Malware-Schutz ist für Ihre NSX-Umgebung aktiviert.

Für vSAN-Cluster:

Bei einem direkten NSX-Upgrade wird der vSAN-Zustand nicht geprüft. Dass keine Prüfung erfolgt, bedeutet für Sie, dass bei einem Fehler ein Verstoß gegen vSAN FTT und/oder Datenverlust auftreten kann.
Bei einem direkten Upgrade auf NSX 4.1.0 empfiehlt sich ein serielles Upgrade innerhalb des Clusters.
Bei einem direkten Upgrade auf NSX 4.1.1 und höher ist ein serielles Upgrade innerhalb des Clusters erforderlich.

Upgrade der Management Plane

Während des Upgrades	Nach dem Upgrade
Bei einem Upgrade von NSX 3.2 oder 3.2.0.1: Nehmen Sie während des Upgrades der Management Plane keine Konfigurationsänderungen vor. Der API-Dienst ist momentan nicht verfügbar. Die Benutzeroberfläche ist kurzzeitig nicht verfügbar.	Konfigurationsänderungen sind zulässig. Im Rahmen des Upgrades eingeführte neue Funktionen sind konfigurierbar. Sie benötigen eine gültige Lizenz, um lizenzierte Funktionen wie T0, T1, Segmente und NSX Intelligence zu verwenden. Stellen Sie im Upgrade-Koordinator sicher, dass der Upgrade-Prozess abgeschlossen ist. Führen Sie erst nach Abschluss des Upgrade-Prozesses Konfigurationsaufgaben durch.

Während des Upgrades

Nach dem Upgrade

Bei einem Upgrade von NSX 3.2 oder 3.2.0.1:

Nehmen Sie während des Upgrades der Management Plane keine Konfigurationsänderungen vor.
Der API-Dienst ist momentan nicht verfügbar.
Die Benutzeroberfläche ist kurzzeitig nicht verfügbar.

Konfigurationsänderungen sind zulässig.
Im Rahmen des Upgrades eingeführte neue Funktionen sind konfigurierbar.
Sie benötigen eine gültige Lizenz, um lizenzierte Funktionen wie T0, T1, Segmente und NSX Intelligence zu verwenden.
Stellen Sie im Upgrade-Koordinator sicher, dass der Upgrade-Prozess abgeschlossen ist. Führen Sie erst nach Abschluss des Upgrade-Prozesses Konfigurationsaufgaben durch.