È possibile eseguire la migrazione delle basi e dei cluster NCP dalla modalità Manager alla modalità Criterio.

Al momento dell'aggiornamento di NCP, è possibile eseguire la migrazione delle risorse della modalità NSX Manager alla modalità Criterio di NSX, consentendo a NCP di funzionare in modalità Criterio. La migrazione è anche denominata "importazione" nella documentazione. Significano la stessa cosa. Questa funzionalità che consente di eseguire la migrazione delle basi TAS è disponibile a partire da NCP 4.1.2. La funzionalità per eseguire la migrazione dei cluster TKGI e dei cluster Vanilla Kubernetes è disponibile a partire da NCP 4.0.

Prerequisiti

  1. La migrazione di un cluster Kubernetes o di una base TAS richiede un po' di tempo e l'interruzione delle attività del piano di controllo (non sono consentite operazioni di creazione, aggiornamento o eliminazione) in NSX. La durata del tempo di inattività dipende dalla strategia di migrazione utilizzata, tra le due seguenti:
    1. Strategia 1: (consigliata e necessaria per TAS) pianificare un tempo di inattività del piano di controllo in tutti i cluster (in esecuzione in modalità Manager o in modalità Criterio) contemporaneamente. Il tempo di inattività durerà finché tutti i cluster non verranno migrati alla modalità Criterio. Il vantaggio di questa strategia sta nel fatto che consente di utilizzare la funzionalità Backup e ripristino di NSX durante l'errore e il ripristino.
    2. Strategia 2: pianificare il tempo di inattività del piano di controllo in un cluster alla volta. Dopo la migrazione di un cluster, NCP viene avviato in modalità Criterio in tale cluster. Con questa strategia non è possibile utilizzare la funzionalità Backup e ripristino di NSX perché altri cluster potrebbero creare nuovi carichi di lavoro in NSX durante la migrazione del cluster corrente. Questa modalità può essere utilizzata se è accettabile rimuovere il cluster quando la migrazione e il rollback non riescono.
  2. Gli NSX Manager possono essere condivisi da più cluster o basi rispettivamente. È possibile migrare alla modalità Criterio un solo cluster e una sola base alla volta che condividono gli stessi NSX Manager.
  3. Tutte le sezioni DFW create manualmente presenti tra tutte le sezioni create da NCP devono essere spostate al di fuori dell'intervallo delle sezioni DFW create da NCP. Vedere Gestione delle sezioni DFW create dall'amministratore di NSX.
  4. Tutte le regole create dall'utente nelle sezioni create da NCP devono essere spostate fuori dalle sezioni create da NCP. Vedere Gestione delle sezioni DFW create dall'amministratore di NSX.
  5. I server virtuali LoadBalancer creati da NCP in modalità Manager non devono includere più di 255 regole. Questo significa che Kubernetes non deve disporre di più di 255 regole di ingresso nel LoadBalancer predefinito. Se sono presenti più di 255 regole di ingresso, è necessario dividere l'ingresso in più CRD di LoadBalancer mentre NCP è in esecuzione in modalità Manager.
  6. Se si utilizza il bilanciamento del carico davanti alle UA NSX, è necessario collegare un profilo di persistenza dell'IP di origine nel bilanciamento del carico in modo che tutte le chiamate API effettuate durante la migrazione dallo script raggiungano la stessa appliance NSX. Questo profilo di persistenza deve essere rimosso dopo la migrazione di tutte le basi/cluster nell'API di Criterio

Limitazioni e avvertenze

  1. Gli scenari in cui gli NSX Manager sono condivisi tra basi TAS, cluster TKGi e cluster Vanilla Kubernetes dei prodotti non sono ancora supportati. Ad esempio, quando gli stessi nodi NSX Manager vengono utilizzati per eseguire 1 o più basi e 1 o più cluster TKGi.
  2. Dopo la migrazione e il riavvio di NCP in modalità Criterio, NCP riconcilia il carico di lavoro esistente nella base TAS o nel cluster TKGI con NSX. Il tempo di riconciliazione è proporzionale alle dimensioni del carico di lavoro esistente. Durante la riconciliazione, le operazioni come la creazione dell'istanza di pod o app potrebbero non riuscire e potrebbero verificarsi notevoli ritardi nella creazione o nell'eliminazione delle risorse NSX mappate alle entità TAS e TKGI. Per cluster o basi di grandi dimensioni, in cui l'utilizzo delle risorse NCP è prossimo ai limiti di scalabilità, è consigliabile aggiungere almeno 45 minuti alla finestra di manutenzione per consentire a NCP di riconciliarsi con il back-end. Al termine della riconciliazione, NCP ritenta automaticamente di sincronizzare le operazioni non riuscite.

Dettagli del processo

Esistono due categorie di risorse NSX che vengono migrate quando si esegue la migrazione di un cluster Kubernetes/TKGi o di una base TAS alla modalità Criterio:
  1. Risorse NSX condivise: queste risorse NSX vengono create manualmente dall'amministratore e fornite a NCP tramite l'interfaccia utente di Opsmanager in TAS/TKGi o la mappa di configurazione Kubernetes nsx-ncp-config in Vanilla Kubernetes. Possono essere condivise tra basi e cluster. Tali risorse devono essere specificate manualmente prima dell'inizio della migrazione delle basi o dei cluster in un file YAML denominato user spec (fare riferimento a File user-spec.yaml di esempio)
  2. Risorse NSX create da NCP: queste risorse NSX vengono create da NCP in risposta ai carichi di lavoro delle basi o dei cluster. Queste risorse vengono dedotte automaticamente durante la migrazione

NOTA: il pod NCP può funzionare in modalità Manager solo quando tutte le risorse NSX create da NCP sono in modalità Manager. Allo stesso modo, il pod NCP può funzionare in modalità Criterio solo quando tutte le risorse NSX create da NCP sono in modalità Criterio.

La migrazione dei cluster Vanilla Kubernetes viene eseguita dal processo Kubernetes denominato "nsx-ncp-migrate-mp2p" mentre la migrazione dei cluster TKGi e delle basi TAS viene eseguita dal processo denominato "migrate-mp2p". Questo processo esegue un programma Python per la migrazione delle risorse NSX condivise o create da NCP. Il programma Python viene eseguito in due modalità: migrazione (sezione di riferimento "Fasi della migrazione") e rollback (sezione di riferimento "Modalità di rollback"). Prima di attivare il processo, è innanzitutto necessario arrestare NCP in tutti i cluster che condividono la rete NSX (cluster Manager e Criterio) e quindi creare un backup di NSX. Durante la migrazione di un cluster Kubernetes o una base TAS, vengono forniti i passaggi dettagliati.

Modalità di migrazione

La modalità di migrazione viene eseguita in 4 fasi separate logicamente.

Fase 1

Recuperare tutte le risorse NSX dall'API di Manager utilizzando l'API di ricerca. Filtrare le risorse in base al tag del cluster (durante la migrazione delle risorse create da NCP) o alle risorse condivise specificate nel file delle specifiche utente (durante la migrazione delle risorse condivise). Iniziare a creare corpi di richiesta da inviare al server di migrazione. Se non è possibile generare alcuna richiesta, non viene migrata alcuna risorsa NSX.

Possibili problemi:
  • Problemi di connettività con NSX
  • Il server dell'API Kubernetes non contiene una risorsa necessaria per eseguire la migrazione di una risorsa NSX Manager

Fase 2

Iniziare a inviare le richieste di migrazione create nella fase 1 al servizio del coordinatore della migrazione in esecuzione in NSX. Una volta che una richiesta è stata elaborata correttamente da NSX, archiviare nel disco locale gli ID MP delle risorse NSX migrate tramite la richiesta (tali ID sono denominati "record di migrazione"). Se si verifica un problema, il programma esegue il rollback di tutte le risorse NSX migrate durante l'esecuzione corrente alla modalità Manager utilizzando i rispettivi ID MP archiviati nel disco locale.

Possibili problemi:
  • Problemi di connettività con NSX
  • L'API di migrazione restituisce un errore

Fase 3

Dedurre gli aggiornamenti che devono essere apportati nelle risorse NSX migrate nell'esecuzione corrente. Questi includono solo gli aggiornamenti dei tag e/o dei nomi visualizzati delle risorse NSX. Se non è possibile dedurre un aggiornamento (ad esempio perché la risorsa Kubernetes corrispondente non è disponibile), viene eseguito il rollback di tutte le risorse NSX.

Possibili problemi:
  • Problemi di connettività con NSX.
  • Il server dell'API Kubernetes non contiene una risorsa necessaria per aggiornare una risorsa del Criterio NSX.

Fase 4

Aggiornare le risorse del Criterio NSX con le informazioni dedotte nella fase 3. Se al momento non è possibile aggiornare una risorsa NSX, archiviare il corpo della risorsa di Criterio aggiornato e l'URL della risorsa di Criterio nel disco locale.

Possibili problemi:
  • Problemi di connettività con NSX.

Se si verifica un problema durante la migrazione, vedere la sezione "Errore e ripristino".

Modalità di rollback

In questa modalità, il programma Python tenta di eseguire il rollback di tutte le risorse NSX i cui ID MP sono presenti nei record di migrazione nello storage locale (vedere Fase 2 della migrazione). I record di migrazione delle risorse NSX verranno eliminati una volta completato correttamente il rollback. Se si verifica un errore durante il rollback, l'esecuzione viene interrotta e il processo deve essere eseguito di nuovo.

Non appena il programma inizia, viene eseguito automaticamente in modalità di rollback se trova eventuali record di migrazione nello storage locale (vedere Fase 2 della migrazione).

Errore e ripristino

È possibile che il processo di importazione non venga completato correttamente a causa di un problema esterno, ad esempio un'interruzione dell'alimentazione, l'esaurimento del disco, problemi di connettività e così via. In questi scenari esistono diversi modi per eseguire il ripristino.

È consigliabile controllare innanzitutto i registri del processo di migrazione. È possibile che indichino l'azione successiva da eseguire. Può essere una dei seguenti:
  • (Soluzione predefinita se i registri non ne indicano una) Eseguire nuovamente il processo di migrazione.
    • Se l'errore precedente si è verificato nella Fase 1, 2 o 3, il processo di migrazione tenterà di eseguire il rollback delle risorse NSX utilizzando i record di migrazione (vedere Fase 2). Questa operazione deve essere eseguita finché non viene eseguito il rollback di tutte le risorse NSX.
    • Se l'errore precedente si è verificato nella Fase 4, il processo di migrazione tenterà di aggiornare nuovamente le risorse NSX in modalità Criterio. Questa operazione deve essere eseguita finché tutte le risorse NSX non verranno aggiornate correttamente.
  • Eseguire NCP in modalità Manager e quindi riprovare la migrazione. Se il processo di migrazione non riesce a eseguire la migrazione del cluster, è necessario eseguire nuovamente NCP nel cluster o nella base in modalità Manager. Tuttavia, ciò renderà nullo il backup di NSX. Pertanto, ignorare temporaneamente la migrazione di questo cluster. Una volta migrati tutti gli altri cluster alla modalità Criterio, avviare NCP in modalità Manager in questo cluster e in modalità Criterio negli altri cluster. Attendere almeno 60 minuti, quindi eseguire di nuovo i passaggi della migrazione dall'inizio per riprovare la migrazione del cluster.

Nel caso raro in cui il ripristino non sia possibile tramite i passaggi della migrazione, ripristinare NSX Manager al punto di backup precedente creato prima della migrazione di qualsiasi cluster a Criterio, riavviare NCP in tutti i cluster nella stessa modalità utilizzata quando è stato eseguito il backup di NSX e tentare nuovamente la migrazione.