Der vCloud Networking and Security-Upgrade-Vorgang kann einige Zeit in Anspruch nehmen, insbesondere dann, wenn Upgrades für ESXi-Hosts durchgeführt werden, da die Hosts neu gestartet werden müssen. Es ist wichtig, den Betriebszustand von vCloud Networking and Security-Komponenten bei einem Upgrade zu kennen, z. B. wenn einige, aber nicht alle Hosts aktualisiert wurden oder wenn NSX Edges noch nicht aktualisiert wurden.

Für das Upgrade von vCloud Networking and Security auf NSX 6.2.x müssen Sie die NSX-Komponenten in der folgenden Reihenfolge aktualisieren:

  • vShield Manager

  • Host-Cluster und virtuelle Leitungen

  • vShield App

  • vShield Edge

  • vShield Endpoint

VMware empfiehlt, dass Sie das Upgrade in einem einzelnen Ausfallfenster durchführen, um die Ausfallzeit zu minimieren und Irritationen unter den vCloud Networking and Security-Benutzern zu vermeiden, die während des Upgrades nicht auf bestimmte vCloud Networking and Security-Verwaltungsfunktionen zugreifen können. Wenn Ihre Standortanforderungen Sie allerdings daran hindern, das Upgrade in einem einzelnen Ausfallfenster durchzuführen, können die nachfolgenden Informationen dazu beitragen, dass Ihre vCloud Networking and Security-Benutzer verstehen, welche Funktionen während des Upgrades zur Verfügung stehen.

vCenter-Upgrade

Wenn Sie das in vCenter eingebettete SSO verwenden und Sie ein Upgrade von vCenter 5.5 auf vCenter 6.0 durchführen, wird die Verbindung von vCenter zu vShield Manager möglicherweise getrennt. Dies geschieht, wenn vCenter 5.5 bei vShield unter Verwendung des Root-Benutzernamens registriert wurde. Ab der Version NSX 6.2 ist die vCenter-Registrierung mit Root veraltet. Als Problemumgehung registrieren Sie vCenter bei vShield mithilfe des Benutzernamens „administrator@vsphere.local“ anstelle von „root“ neu.

Wenn Sie externes SSO verwenden, sind keine Änderungen erforderlich. Sie können denselben Benutzernamen, z. B. „admin@mybusiness.mydomain“, beibehalten. Dann wird die vCenter-Verbindung nicht getrennt.

vShield Manager-Upgrade

Während des Vorgangs gilt Folgendes:

  • Die vShield Manager-Konfiguration ist gesperrt. Der vShield-API-Dienst ist nicht verfügbar. An der vShield-Konfiguration können keine Änderungen vorgenommen werden. Die vorhandene VM-Kommunikation funktioniert weiter einwandfrei. Die neue VM-Bereitstellung funktioniert weiter in vSphere, aber die neuen virtuellen Maschinen können während des vShield Manager-Upgrades nicht mit virtuellen vShield-Leitungen verbunden werden.

Nach dem Vorgang gilt Folgendes:

  • Alle vShield-Konfigurationsänderungen sind zulässig.

Host-Cluster-Upgrade und virtuelle Leitungen

In Verbindung mit dem Host-Cluster-Upgrade werden neue VIBs auf den Hosts installiert.

In NSX wurden virtuelle Leitungen in logische Switches umbenannt.

Während des Vorgangs gilt Folgendes:

  • Konfigurationsänderungen werden auf NSX Manager nicht blockiert.

  • Das Upgrade wird pro Cluster durchgeführt. Wenn DRS auf dem Cluster aktiviert ist, verwaltet DRS die Upgrade-Reihenfolge der Hosts.

Wenn einige NSX-Hosts eines Clusters aktualisiert werden und andere nicht:

  • Konfigurationsänderungen am NSX Manager werden nicht blockiert. Es können Elemente zu logischen Netzwerken hinzugefügt werden und Änderungen daran vorgenommen werden. Die Bereitstellung neuer virtueller Maschinen funktioniert weiter auf Hosts, die zurzeit nicht aktualisiert werden. Hosts, die zurzeit aktualisiert werden, werden in den Wartungsmodus versetzt. Dies bedeutet, dass virtuelle Maschinen ausgeschaltet oder auf andere Hosts evakuiert werden müssen. Dies kann mit DRS oder manuell durchgeführt werden.

Migration von vShield App auf NSX Distributed Firewall

In Verbindung mit dem Host-Cluster-Upgrade wird die vShield App-Konfiguration auf die Distributed Firewall migriert.

Während des Vorgangs gilt Folgendes:

  • Während der Durchführung der Migration werden vorhandene Filter weiter angewandt.

  • Fügen Sie während der Durchführung der Migration keine Filter hinzu und ändern Sie diese nicht.

Nach dem Vorgang gilt Folgendes:

  • Überprüfen Sie alle migrierten Bereiche, um sicherzustellen, dass sie wie vorgesehen funktionieren.

  • Nach der Migration entfernen Sie vShield App über die Seite „Dienstbereitstellung“ in NSX.

Upgrade von vShield Edge

vShield Edges können unabhängig von Host-Upgrades aktualisiert werden. Sie können eine vShield Edge selbst dann aktualisieren, wenn Sie die Hosts noch nicht aktualisiert haben.

ACHTUNG:

Wenn Sie eine vCloud Director-Version vor 8.10 verwenden, ist kein Upgrade von NSX Edge möglich. Siehe Prüfen eines Upgrades von vShield Edge in einer vCloud Director-Umgebung.

Während des Vorgangs gilt Folgendes:

  • Auf dem aktuell aktualisierten vShield Edge-Gerät werden Konfigurationsänderungen blockiert.

  • Die Paketweiterleitung ist vorübergehend unterbrochen.

  • Es können Elemente zu logischen Switches hinzugefügt werden und Änderungen daran vorgenommen werden.

  • Die Bereitstellung neuer virtueller Maschinen funktioniert weiterhin einwandfrei.

Nach dem Vorgang gilt Folgendes:

  • Konfigurationsänderungen werden nicht blockiert. Durch das Upgrade auf NSX eingeführte neue Funktionen sind erst dann konfigurierbar, wenn alle NSX Controller installiert und alle Host-Cluster auf NSX Version 6.2.x aktualisiert wurden.

  • L2 VPN muss nach dem Upgrade neu konfiguriert werden.

  • SSL-VPN-Clients müssen nach dem Upgrade neu installiert werden.

Migration von vShield Endpoint auf Guest Introspection

In NSX 6.x wurde vShield Endpoint in Guest Introspection umbenannt. Nach dem Upgrade von NSX Manager zeigt der Guest Introspection-Dienst einen Upgrade-Link an, wenn Sie zu Networking & Security > Installation > Dienstbereitstellungen wechseln. Wenn Sie ein Upgrade von vCloud Networking and Security auf NSX durchführen, werden die virtuelle Appliance Guest Introspection und der Hostagent für Guest Introspection auf jedem Host im Cluster bereitgestellt, auf dem Guest Introspection aktiviert ist.

Während des Vorgangs gilt Folgendes:

  • Die VMs im NSX-Cluster sind bei Änderungen, etwa bei VM-Hinzufügungen, vMotion-Vorgängen oder Löschvorgängen, nicht geschützt.

Nach dem Vorgang gilt Folgendes:

  • Die VMs sind bei VM-Hinzufügungen, vMotion-Vorgängen und Löschvorgängen geschützt.