Per installare correttamente NSX Application Platform e attivare le funzionalità ospitate da NSX, è necessario preparare l'ambiente di distribuzione in modo che soddisfi le risorse minime richieste.

Prima di iniziare a distribuire NSX Application Platform, è necessario soddisfare i prerequisiti elencati nelle sezioni seguenti.

Requisito della versione di NSX-T Data Center

Verificare che la versione del prodotto NSX-T Data Center in uso sia compatibile con la versione di NSX Application Platform che si intende distribuire, insieme alle relative funzionalità di NSX-T Data Center (NSX Intelligence, NSX Network Detection and Response, Prevenzione malware NSX e Metriche NSX).

Il controllo delle versioni delle funzionalità di NSX-T Data Center ospitate in NSX Application Platform corrisponde al numero di versione di NSX Application Platform e non al numero di versione del prodotto NSX-T Data Center.

Importante:

In un ambiente di NSX Federation, è possibile distribuire NSX Application Platform solo in Local Manager. Non è possibile distribuire NSX Application Platform tramite Global Manager. È possibile accedere a NSX Application Platform solo utilizzando un Local Manager.

Per determinare quale versione di NSX Application Platform è possibile distribuire con una determinata versione di NSX-T Data Center, utilizzare la seguente matrice di compatibilità.

Versione di NSX-T Data Center

Versione di NSX Application Platform compatibile

3.2.x

3.2.0, 3.2.1
Utilizzare le informazioni seguenti per decidere quale documentazione utilizzare per il workflow di attivazione di NSX Application Platform specifico.
  • Se si desidera eseguire una nuova installazione di NSX-T Data Center, vedere Guida all'installazione di NSX-T Data Center per le versioni 3.2.x e successive nel set della documentazione di VMware NSX per le istruzioni di installazione.
  • Per informazioni sull'aggiornamento da un'installazione di NSX Application Platform precedente alla versione 3.2.x, vedere Aggiornamento dell' NSX Application Platform.
  • Se si esegue l'aggiornamento da NSX-T Data Center 3.1.x o versioni precedenti senza NSX Intelligence installato, vedere Guida all'aggiornamento di NSX-T Data Center nel set della documentazione di VMware NSX.
  • Se si esegue l'aggiornamento da NSX-T Data Center 3.1.x o versioni precedenti con un'installazione di NSX Intelligence 1.2.x o versioni precedenti, è necessario preparare l'installazione corrente di NSX Intelligence prima di eseguire l'aggiornamento a NSX Intelligence 3.2.x e NSX-T Data Center 3.2.x. Vedere la documentazione Attivazione e aggiornamento di VMware NSX Intelligence per la versione 3.2 nel set della documentazione di VMware NSX Intelligence.

Requisito della licenza di NSX-T o NSX Data Center valida

Per distribuire NSX Application Platform, la sessione di NSX Manager corrente in uso deve disporre di una licenza valida durante la distribuzione di NSX Application Platform.

Per l'elenco delle licenze valide, vedere Requisiti di licenza per la distribuzione di NSX Application Platform.

Ruolo utente di NSX-T Data Center valido

Per distribuire NSX Application Platform, è necessario disporre dei privilegi del ruolo di amministratore aziendale.

Certificati firmati dalla CA validi

  • Se l'appliance NSX Manager utilizza certificati firmati da un'autorità di certificazione con catena parziale nel cluster NSX Manager Unified Appliance, è necessario sostituire il certificato con una catena di certificati completa. Per ulteriori informazioni, vedere l'articolo della Knowledge Base VMware 78317.

  • Quando si utilizzano più appliance NSX Manager, l'ambiente deve soddisfare uno dei seguenti prerequisiti del certificato.

    • Tutte le appliance devono condividere lo stesso certificato SSL.

    • Per ogni appliance, è necessario emettere un certificato SSL dedicato, dove il nome comune del certificato (CN) deve essere univoco in tutti i nodi.

    • Quando si utilizza un IP virtuale (VIP), il certificato del cluster deve essere uguale a quello condiviso da tutte le singole appliance o deve essere univoco da tutti i nodi.

Risorse richieste per il cluster Kubernetes

  • VMware supporta una distribuzione di NSX Application Platform in un cluster Tanzu Kubernetes Grid (TKG) nel supervisore o in un cluster Kubernetes upstream.
    Importante: Kubernetes upstream si riferisce al Kubernetes open source vanilla gestito da Cloud Native Computing Foundation e non riguarda alcuna distribuzione o versione di Kubernetes che non sono esplicitamente elencate nella tabella seguente.

    Per informazioni sull'installazione e la configurazione del cluster TKG nel supervisore, vedere Installazione e configurazione di vSphere with Tanzu (versione 8.0) o il sito Web della documentazione di VMware vSphere per le altre versioni.

    VMware ha testato e supporta le versioni seguenti.

    Versione di NSX Application Platform

    Versione del cluster TKG nel supervisore

    Versione del cluster Kubernetes upstream
    3.2.0, 3.2.1

    • 1.17.17, 1.18.19 (vedere la nota seguente)

    • 1.19.11, 1.20.7, 1.21.2, 1.21.6

    1.17, 1.18, 1.19, 1.20, 1.21
    Nota:

    L'operazione NSX Application Platform Scala verticalmente non è supportata nelle versioni 1.17.x e 1.18.x del cluster TKG nel supervisore. Per dettagli, vedere Impossibile aumentare le dimensioni del volume del disco di archiviazione dei dati.

  • L'amministratore dell'infrastruttura deve configurare il cluster TKG nel supervisore o Kubernetes upstream in cui è possibile distribuire NSX Application Platform e le funzionalità NSX che la piattaforma ospita. È necessario allocare risorse sufficienti al cluster TKG nel supervisore o Kubernetes upstream per distribuire i pod di NSX Application Platform. Poiché ciascuna funzionalità di NSX supportata ha requisiti di risorse specifici, decidere quale delle funzionalità di NSX ospitate si intende utilizzare.

    Vedere l'argomento Requisiti di sistema di NSX Application Platform per dettagli sui fattori modulo supportati e sui relativi requisiti delle risorse.

  • Importante: Il cluster guest Kubernetes utilizzato per la NSX Application Platform deve utilizzare un dominio del servizio predefinito cluster.local. Questo è il valore predefinito ed è definito nella configurazione del cluster: 
    settings: network: serviceDomain: cluster.local
    Per la NSX Application Platform, non modificare questo valore o impostare un dominio del servizio non predefinito.

  • L'amministratore dell'infrastruttura deve anche installare e configurare in anticipo le seguenti infrastrutture.

    • Container Network Interface (CNI), ad esempio Antrea, Calico e Flannel.

    • Container Storage Interface (CSI). Per eseguire il provisioning dei volumi dinamici, è necessario disporre di una classe di archiviazione nel cluster TKG nel supervisore o nel cluster Kubernetes upstream. Per aumentare il volume dell'archiviazione di dati, la classe di archiviazione deve supportare il ridimensionamento del volume.

Requisito di accesso a Internet

Assicurarsi che il sistema NSX-T Data Center possa accedere al registro e al repository pubblici ospitati in VMware in cui è possibile ottenere il grafico Helm e le immagini Docker del pacchetto di NSX Application Platform. L'accesso diretto a Internet è necessario solo durante le operazioni di installazione e aggiornamento. Questo accesso è limitato all'accesso in uscita tramite la porta TCP 443 (HTTPS) verso https://projects.registry.vmware.com per accedere ai grafici Helm e alle immagini Docker dell'installazione di NSX Application Platform. Non è necessario alcun accesso in entrata o accesso in uscita permanente.

L'accesso a Internet in uscita è necessario sia per le macchine virtuali di NSX-T Data Center Unified Appliance sia per i nodi worker del cluster guest NSX Application Platform.

Se l'ambiente di NSX-T Data Center è stato configurato per l'utilizzo di un server proxy Internet tramite la scheda Sistema > Impostazioni generali > Server proxy Internet, si tenga presente che NSX Application Platform non può essere distribuito tramite un server proxy Internet. Se il cluster Kubernetes non dispone di accesso a Internet o sono presenti limitazioni di sicurezza, vedere il requisito facoltativo successivo per un registro di container privato con un servizio di repository dei grafici.

(Requisito facoltativo) Registro di container privato con servizio di repository dei grafici

Per semplificare il processo di distribuzione di NSX Application Platform, utilizzare il registro e il repository ospitati in VMware. Questo processo di distribuzione utilizza solo una connessione in uscita e non conserva i dati del cliente.

(Facoltativo) Se il cluster Kubernetes non dispone di accesso a Internet o sono presenti restrizioni di sicurezza, l'amministratore dell'infrastruttura deve configurare un registro di container privato con un servizio di repository dei grafici. Utilizzare questo registro di container privato per caricare i grafici di Helm e le immagini Docker di NSX Application Platform necessarie per distribuire NSX Application Platform. VMware utilizzava Harbor per convalidare il processo di distribuzione che utilizzava un registro di container privato, ma la distribuzione di NSX Application Platform era basata su standard. Per dettagli, consultare Caricamento delle immagini Docker e dei grafici di Helm di NSX Application Platform su un registro di container privato.

(Requisito facoltativo) URL di un registro di container privato

Se si utilizza un registro di container privato, ottenere dall'amministratore dell'infrastruttura l'URL di tale registro. Questo URL viene utilizzato durante il processo di distribuzione.

File di configurazione di Kubernetes necessario

È inoltre necessario ottenere il file di configurazione di Kubernetes dall'amministratore dell'infrastruttura. È necessario il file kubeconfig durante la distribuzione di NSX Application Platform in modo che NSX Manager acceda in modo sicuro al cluster TKG nel supervisore o Kubernetes upstream. Il file kubeconfig deve disporre di tutti i privilegi per accedere a tutte le risorse del cluster TKG nel supervisore o nel cluster Kubernetes upstream.

Importante:

Il file kubeconfig predefinito in un cluster guest VMware vSphere® with Tanzu Kubernetes contiene un token che, per impostazione predefinita, scade dopo dieci ore. Se questo token scaduto non influisce sulla funzionalità, genera un messaggio di avviso relativo alle credenziali non aggiornate. Per evitare l'avviso, prima di distribuire NSX Application Platform in un cluster TKG nel supervisore, collaborare con l'amministratore dell'infrastruttura per creare un token di lunga durata che è possibile utilizzare durante la distribuzione della piattaforma. Vedere Generazione di un file di configurazione del cluster TKG nel supervisore con un token senza scadenza per dettagli su come estrarre il token.

Nome del servizio o nome del servizio dell'interfaccia (FQDN)

Durante la distribuzione di NSX Application Platform viene specificato un nome di dominio completo (FQDN) per la casella di testo Nome servizio in una distribuzione NSX-T Data Center 3.2.0 o per la casella di testo Nome servizio interfaccia in una distribuzione NSX-T Data Center 3.2.1 o versioni successive.

Il valore Nome servizio o Nome servizio interfaccia viene utilizzato come endpoint HTTPS per connettersi all'NSX Application Platform.

Per ottenere il valore del FQDN, utilizzare uno dei seguenti workflow.

  • Prima della distribuzione di NSX Application Platform, è necessario configurare l'FQDN con un indirizzo IP statico nel server DNS. L'infrastruttura del cluster TKG nel supervisore o Kubernetes upstream deve essere in grado di assegnare un indirizzo IP statico. Gli ambienti Kubernetes supportati sono i seguenti.

    • MetalLB: un bilanciamento del carico esterno per il cluster Kubernetes upstream.

    • VMware Tanzu® Kubernetes per VMware vSphere® 7.0 U2 e VMware vSphere 7.0 U3 con NSX-T Data Center.

    • VMware vSphere with Tanzu che utilizza vSphere Networking. Per ulteriori informazioni, vedere il documento di VMware vSphere relativo all'abilitazione della gestione dei carichi di lavoro con vSphere Networking.

  • Se è installato il DNS esterno (vedere la pagina Web Kubernetes SIGs - External DNS), è necessario specificare solo il nome di dominio completo quando viene richiesto un nome di servizio. L'infrastruttura Kubernetes configura automaticamente l'FQDN con un indirizzo IP dinamico nel server DNS.

    Il piano di controllo del carico di lavoro (WCP) con DNS esterno installato è l'ambiente Kubernetes supportato.

Nome del servizio di messaggistica necessario (per le distribuzioni di NSX-T Data Center 3.2.1 o versioni successive)

Il valore Nome servizio di messaggistica è un nome di dominio completo (FQDN) per l'endpoint HTTPS utilizzato per ricevere i dati semplificati dalle origini dati di NSX-T Data Center.

Porte e protocolli necessari

Verificare che le porte necessarie nell'host del cluster Kubernetes siano aperte per l'accesso di NSX Application Platform. Vedere la pagina Web VMware Ports and Protocols.

Comunicazione richiesta dai nodi del cluster Kubernetes

Verificare che i nodi del cluster Kubernetes in uso possano raggiungere l'appliance di NSX Manager.

Requisito di sincronizzazione degli orari dei sistemi

Sincronizzare l'ora del sistema nei nodi del cluster TKG nel supervisore o Kubernetes upstream nell'appliance NSX Manager.