Sie können NCP-Cluster und Foundations vom Manager-Modus zum Richtlinienmodus migrieren.

Nach dem NCP-Upgrade können NSX Manager-Modusressourcen zur NSX-Richtlinie migriert werden, sodass NCP im Richtlinienmodus ausgeführt werden kann. Die Migration wird in der Dokumentation auch als „Import“ bezeichnet. Beide Begriffe bedeuten dasselbe. Diese Funktion zum Migrieren von TAS Foundations ist ab NCP 4.1.2 verfügbar. Die Funktion zum Migrieren von TKGI-Clustern und Vanilla-Kubernetes-Clustern ist ab NCP 4.0 verfügbar.

Voraussetzungen

  1. Das Migrieren eines Kubernetes-Clusters oder einer TAS Foundation kann einige Zeit in Anspruch nehmen und erfordert Ausfallzeiten der Steuerungsebene (keine Erstellungs-, Aktualisierungs- oder Löschvorgänge zulässig) von NSX. Die Dauer der Ausfallzeit ist von der angewendeten Migrationsstrategie abhängig, von der es zwei gibt:
    1. Strategie 1: (empfohlen und erforderlich für TAS) Planen Sie eine Ausfallzeit der Steuerungsebene auf allen Clustern (Ausführung im Manager- oder Richtlinienmodus) gleichzeitig. Die Ausfallzeit dauert, bis alle Cluster zu der Richtlinie migriert wurden. Der Vorteil besteht darin, dass Sie damit während des Fehlers und der Wiederherstellung die Sicherungs- und Wiederherstellungsfunktion von NSX verwenden können.
    2. Strategie 2: Planen Sie für jeweils einen Cluster eine Ausfallzeit der Steuerungsebene. Nachdem ein Cluster migriert wurde, wird NCP auf diesem Cluster im Richtlinienmodus gestartet. Die Sicherung und Wiederherstellung von NSX kann bei dieser Strategie nicht verwendet werden, da andere Cluster neue Workloads auf NSX erstellen können, während der aktuelle Cluster migriert wird. Dieser Modus kann verwendet werden, wenn das Verwerfen des Clusters akzeptabel ist, falls sowohl die Migration als auch die Wiederherstellung fehlschlägt.
  2. NSX Manager können von mehreren Clustern oder Foundations gemeinsam genutzt werden. Es kann jeweils nur ein Cluster/eine Foundation zu der Richtlinie migriert werden, die dieselben NSX Manager verwendet.
  3. Alle manuell erstellten DFW-Abschnitte, die zwischen von NCP erstellten Abschnitten vorhanden sind, müssen außerhalb des Bereichs der von NCP erstellten DFW-Abschnitte verschoben werden. Siehe Umgang mit vom NSX-Administrator erstellten DFW-Abschnitten.
  4. Alle vom Benutzer erstellten Regeln in von NCP erstellten Abschnitten müssen aus den von NCP erstellten Abschnitten entfernt werden. Siehe Umgang mit vom NSX-Administrator erstellten DFW-Abschnitten.
  5. Von NCP erstellte virtuelle LoadBalancer-Server im Managermodus dürfen nicht mehr als 255 Regeln aufweisen. Dies bedeutet, dass Kubernetes nicht mehr als 255 Regeln für eingehenden Datenverkehr auf dem standardmäßigen LoadBalancer haben darf. Wenn mehr als 255 Regeln für eingehenden Datenverkehr vorhanden sind, müssen Sie den eingehenden Datenverkehr in mehrere LoadBalancer-CRDs aufteilen, während NCP im Managermodus ausgeführt wird.
  6. Wenn Sie den Load Balancer vor NSX UAs verwenden, müssen Sie ein Quell-IP-Persistenzprofil auf dem Load Balancer anhängen, damit alle API-Aufrufe, die während der Migration durch das Skript ausgeführt werden, dieselbe NSX Appliance erreichen. Dieses Persistenzprofil sollte entfernt werden, nachdem alle Foundations/Cluster zur Richtlinien-API migriert wurden.

Einschränkungen und Einschränkungen

  1. Szenarien, in denen NSX Manager von Produkten, TAS Foundations, TKGi und Vanilla Kubernetes-Clustern gemeinsam genutzt werden, werden noch nicht unterstützt. Dies ist beispielsweise der Fall, wenn dieselben NSX Manager-Knoten zum Ausführen von 1 oder mehr Foundation- und 1 oder mehreren TKGi-Clustern verwendet werden.
  2. Nach der Migration und dem Neustart von NCP im Richtlinienmodus gleicht NCP die vorhandene Arbeitslast im TAS Foundation- oder TKGI-Cluster mit NSX ab. Die Abgleichsdauer ist proportional zum Umfang der vorliegenden Arbeitslast. Während des Abgleichs können Vorgänge wie die Erstellung von Pod- oder App-Instanzen fehlschlagen. Zudem kann es zu erheblichen Verzögerungen beim Erstellen oder Löschen von NSX-Ressourcen kommen, die TAS- und TKGI-Einheiten zugeordnet sind. Für sehr große Cluster oder Foundations, bei denen die NCP-Ressourcennutzung nahe an den Skalierungsgrenzwerten liegt, wird empfohlen, mindestens 45 Minuten zum Wartungsfenster hinzuzufügen, damit NCP mit dem Back-End abgeglichen werden kann. NCP versucht automatisch, die fehlgeschlagenen Vorgänge nach Abschluss des Abgleichs zu synchronisieren.

Prozessdetails

Es gibt zwei Kategorien von NSX Ressourcen, die bei der Migration eines Kubernetes/TKGi-Clusters oder einer TAS Foundation zum Richtlinienmodus migriert werden:
  1. Freigegebene NSX-Ressourcen: Diese NSX-Ressourcen werden manuell vom Administrator erstellt und NCP über die Opsmanager-Benutzeroberfläche in TAS/TKGi oder über die Kubernetes-Konfigurationszuordnung „nsx-ncp-config“ in Vanilla-Kubernetes bereitgestellt. Sie können von Foundations und Clustern gemeinsam genutzt werden. Diese müssen manuell angegeben werden, bevor die Foundation/Cluster-Migration beginnt, in einer YAML-Datei mit der Bezeichnung „user spec“ (siehe Beispiel „user-spec.yaml“).
  2. Von NCP erstellte NSX-Ressourcen: Diese NSX-Ressourcen werden von NCP als Reaktion auf Foundation/Cluster-Arbeitslasten erstellt. Sie werden während der Migration automatisch abgeleitet.

HINWEIS: NCP-Pod kann nur dann im Managermodus ausgeführt werden, wenn sich alle von NCP erstellten NSX-Ressourcen im Managermodus befinden. Ebenso kann NCP-Pod nur dann im Richtlinienmodus ausgeführt werden, wenn sich alle von NCP erstellten NSX-Ressourcen im Richtlinienmodus befinden.

Die Migration von Vanilla-Kubernetes-Clustern wird durch den Kubernetes-Auftrag mit der Bezeichnung „nsx-ncp-migrate-mp2p“ gesteuert, und TKGi-Cluster und TAS-Foundations werden durch den Auftrag mit der Bezeichnung „migrate-mp2p“ gesteuert. Dieser Auftrag führt ein Python-Programm aus, um entweder die freigegebenen oder die von NCP-erstellten NSX-Ressourcen zu migrieren. Das Python-Programm kann in zwei Modi ausgeführt werden: Migration (siehe Abschnitt „Migrationsphasen“) und Wiederherstellung (siehe Abschnitt „Wiederherstellungsmodus“). Bevor der Auftrag ausgelöst wird, müssen Sie NCP zuerst in allen Clustern beenden, die das NSX-Netzwerk gemeinsam nutzen (Manager- und Richtlinien-Cluster). Anschließend müssen Sie eine NSX-Sicherung erstellen. Detaillierte Schritte werden bei der Migration eines Kubernetes-Clusters oder einer TAS Foundation angegeben.

Migrationsmodus

Der Migrationsmodus wird in 4 logisch getrennten Phasen ausgeführt.

Phase 1

Rufen Sie alle NSX-Ressourcen mithilfe der Such-API von der Manager-API ab. Filtern Sie die Ressourcen basierend auf Cluster-Tags (beim Migrieren der von NCP erstellten Ressourcen) oder freigegebenen Ressourcen, die in der Benutzerspezifikationsdatei angegeben sind (beim Migrieren freigegebener Ressourcen). Beginnen Sie mit dem Erstellen von Anforderungstexten, die an den Migrationsserver gesendet werden. Wenn keine Anforderung generiert werden kann, wird keine NSX-Ressource migriert.

Mögliche Probleme:
  • Konnektivitätsprobleme mit NSX
  • Der Kubernetes-API-Server enthält keine Ressource, die zum Migrieren einer NSX Manager-Ressource benötigt wird.

Phase 2

Beginnen Sie mit dem Senden der in Phase 1 erstellten Migrationsanforderungen an den Migrationskoordinatordienst, der in NSX ausgeführt wird. Sobald eine Anforderung von NSX erfolgreich verarbeitet wurde, speichern Sie die MP-IDs der über die Anforderung migrierten NSX-Ressourcen auf der lokalen Festplatte (diese werden als „Migrationsdatensätze“ bezeichnet). Wenn ein Problem auftritt, wird eine Wiederherstellung aller NSX-Ressourcen durchgeführt, die während der aktuellen Ausführung zum Managermodus migriert wurden, wobei die auf der lokalen Festplatte gespeicherten MP-IDs verwendet werden.

Mögliche Probleme:
  • Konnektivitätsprobleme mit NSX
  • Migrations-API gibt einen Fehler zurück

Phase 3

Leiten Sie die Aktualisierungen ab, die auf den migrierten NSX-Ressourcen in der aktuellen Ausführung vorgenommen werden sollen. Dazu gehören nur Aktualisierungen in Tags und/oder Anzeigenamen der NSX-Ressourcen. Wenn keine Aktualisierung abgeleitet werden kann (weil beispielsweise eine entsprechende Kubernetes-Ressource fehlt), wird für alle NSX-Ressourcen eine Wiederherstellung ausgeführt.

Mögliche Probleme:
  • Konnektivitätsprobleme mit NSX.
  • Der Kubernetes-API-Server enthält keine Ressource, die zum Aktualisieren einer NSX-Richtlinienressource erforderlich ist.

Phase 4

Aktualisieren Sie die NSX-Richtlinienressourcen mit den in Phase 3 abgeleiteten Informationen. Wenn eine NSX-Ressource zu diesem Zeitpunkt nicht aktualisiert werden kann, speichern Sie den aktualisierten Richtlinienressourcentext und die URL der Richtlinienressource auf der lokalen Festplatte.

Mögliche Probleme:
  • Konnektivitätsprobleme mit NSX.

Informationen zu Problemen, die während der Migration auftreten, finden Sie im Abschnitt „Fehler und Wiederherstellung“.

Wiederherstellungsmodus

In diesem Modus versucht das Python-Programm, eine Wiederherstellung aller NSX-Ressourcen durchzuführen, deren MP-IDs in den Migrationsdatensätzen im lokalen Speicher vorhanden sind (siehe Migrationsphase 2). Die Migrationsdatensätze von NSX-Ressourcen werden gelöscht, sobald die Wiederherstellung erfolgreich war. Wenn während der Wiederherstellung ein Fehler auftritt, wird die Ausführung angehalten, und der Auftrag muss erneut ausgeführt werden.

Beim Starten des Programms wird es automatisch im Wiederherstellungsmodus ausgeführt, wenn es Migrationsdatensätze im lokalen Speicher findet (siehe Migrationsphase 2).

Fehler und Wiederherstellung

Möglicherweise kann der Migrationsvorgang nicht erfolgreich abgeschlossen werden, da externe Probleme wie ein Stromausfall, unzureichender Festplattenspeicher, Konnektivitätsprobleme usw. auftreten. In solchen Szenarien gibt es Möglichkeiten zur Wiederherstellung.

Es wird empfohlen, zuerst die Protokolle des Migrationsauftrags zu überprüfen. Sie enthalten wahrscheinlich einen Hinweis auf die nächste zu ergreifende Aktion. Die Aktion kann wie folgt lauten:
  • (Standardauflösung, wenn die Protokolle keine Angabe enthalten) Führen Sie den Migrationsauftrag erneut aus.
    • Wenn der vorherige Fehler in Phase 1, 2 oder 3 aufgetreten ist, wird der Migrationsauftrag versuchen, eine Wiederherstellung der NSX-Ressourcen mithilfe der Migrationsdatensätze durchzuführen (siehe Phase 2). Dies muss so lange erfolgen, bis für alle NSX-Ressourcen eine Wiederherstellung durchgeführt wurde.
    • Wenn der vorherige Fehler in Phase 4 aufgetreten ist, versucht der Migrationsauftrag, die NSX-Ressourcen im Richtlinienmodus erneut zu aktualisieren. Dies muss so lange erfolgen, bis alle NSX Ressourcen erfolgreich aktualisiert wurden.
  • Führen Sie NCP im Manager-Modus aus und versuchen Sie dann erneut, die Migration durchzuführen. Wenn der Migrationsauftrag den Cluster nicht migrieren kann, muss NCP erneut in diesem Cluster/dieser Foundation im Managermodus ausgeführt werden. Dadurch wird die NSX-Sicherung jedoch ungültig. Überspringen Sie daher vorübergehend die Migration dieses Clusters. Sobald alle anderen Cluster zum Richtlinienmodus migriert wurden, starten Sie NCP im Managermodus in diesem Cluster und den Richtlinienmodus darin. Warten Sie mindestens 60 Minuten und führen Sie dann die Migrationsschritte von Anfang an erneut aus, um die Clustermigration zu wiederholen.

In dem seltenen Fall, dass die Wiederherstellung mit den oben genannten Schritten nicht möglich ist, stellen Sie den NSX Manager mit dem vorherigen Sicherungspunkt wieder her, der vor der Migration eines Clusters zur Richtlinie erstellt wurde. Starten Sie NCP in allen Clustern in dem Modus neu, in dem die NSX-Sicherung durchgeführt wurde, und unternehmen Sie einen erneuten Migrationsversuch.