Controllare i requisiti di sistema per l'abilitazione di un Supervisore in tre cluster vSphere mappati alle zone vSphere tramite lo stack di rete di NSX e NSX Advanced Load Balancer.
Posizionamento di zone vSphere tra siti fisici
È possibile distribuire le zone vSphere tra siti fisici diversi purché la latenza tra i siti non superi 100 ms. Ad esempio, è possibile distribuire le zone vSphere in due siti fisici, una zona vSphere nel primo sito e due zone vSphere nel secondo sito.
Opzioni di distribuzione di NSX
Per ulteriori informazioni sulle procedure consigliate per la distribuzione di NSX, vedere la NSX Reference Design Guide (in lingua inglese).
Requisiti minimi di elaborazione per un cluster Edge e di gestione
Sistema | Dimensioni minime della distribuzione | CPU | Memoria | Storage |
---|---|---|---|---|
vCenter Server 8 | Piccolo | 2 | 21 GB | 290 GB |
Host ESXi 8 | 2 host ESXi | 8 | 64 GB per host | Non applicabile |
NSX Manager | Media | 6 | 24 GB | 300 GB |
NSX Edge 1 | Grande | 8 | 32 GB | 200 GB |
NSX Edge 2 | Grande | 8 | 32 GB | 200 GB |
Macchine virtuali del motore di servizio | Per ogni Supervisore vengono distribuite almeno due macchine virtuali del motore di servizio | 1 | 2 GB | N/D |
Definizione della capacità di sistema del controller
È possibile specificare la capacità di sistema del controller durante la distribuzione. La capacità di sistema si basa sulle allocazioni delle risorse di sistema come CPU, RAM e disco. La quantità di risorse allocate influisce sulle prestazioni del controller.
Tipo di distribuzione | Numero di nodi | Allocazioni consigliate - CPU | Allocazioni consigliate - Memoria | Allocazioni consigliate - Disco |
---|---|---|---|---|
Demo/Valutazione cliente | 1 | 6 | 24 GB | 128 GB |
Nelle distribuzioni dimostrative, un singolo controller è sufficiente e viene utilizzato per tutte le attività e i workflow del piano di controllo, nonché per le funzionalità di analisi.
In una distribuzione di produzione, è consigliabile utilizzare un cluster a tre nodi.
Per ulteriori informazioni, vedere Dimensioni di NSX Advanced Load Balancer.
Requisiti minimi di elaborazione per i cluster del dominio del carico di lavoro
Sistema | Dimensioni minime della distribuzione | CPU | Memoria | Storage |
---|---|---|---|---|
Cluster vSphere |
|
Non applicabile | Non applicabile | Non applicabile |
Host ESXi 8 |
Per ogni cluster di vSphere:
Nota: Assicurarsi che per i nomi degli host che vengono aggiunti al cluster vengano utilizzate lettere minuscole. In caso contrario, l' attivazione del
Supervisore potrebbe non riuscire.
|
8 | 64 GB per host | Non applicabile |
Macchine virtuali del piano di controllo Kubernetes | 3 | 4 | 16 GB | 16 GB |
Requisiti di rete
Controllare la matrice di interoperabilità dei prodotti VMware per verificare le versioni di NSX supportate.
Componente | Quantità minima | Configurazione richiesta |
---|---|---|
Dispositivo di livello 2 | 1 | La rete di gestione che gestirà il traffico del Supervisore deve trovarsi nello stesso dispositivo di livello 2. Almeno una NIC fisica per host che si occupa della gestione del traffico deve essere connessa allo stesso dispositivo di livello 2. |
MTU della rete fisica | 1700 | La dimensione MTU deve essere 1700 o superiore su qualsiasi gruppo di porte del vSphere Distributed Switch. |
NIC fisica | Almeno 2 NIC fisiche per host, se si utilizza vSAN | Per utilizzare la CNI di Antrea e per prestazioni NSX ottimali, ogni NIC fisica su ciascun host ESXi partecipante deve supportare l'incapsulamento GENEVE e averlo abilitato. |
Componente | Quantità minima | Configurazione richiesta |
---|---|---|
Latenza | 100 ms | Latenza massima consigliata tra ogni cluster che fa parte di una zona vSphere unita in un Supervisore. |
Server NTP e DNS | 1 | Un server DNS e un server NTP che possono essere utilizzati con il vCenter Server.
Nota: Configurare NTP su tutti gli host ESXi e il
vCenter Server.
|
DHCP Server | 1 | Facoltativo. Configurare un server DHCP per acquisire automaticamente gli indirizzi IP per le reti di gestione e del carico di lavoro, nonché gli IP mobili. Il server DHCP deve supportare gli identificatori client e fornire server DNS compatibili, domini di ricerca DNS e un server NTP. Per la rete di gestione, tutti gli indirizzi IP, ad esempio gli IP della macchina virtuale del piano di controllo, un IP mobile, server DNS, DNS, domini di ricerca e server NTP vengono acquisiti automaticamente dal server DHCP. La configurazione DHCP viene utilizzata dal Supervisore. I bilanciamenti del carico potrebbero richiedere indirizzi IP statici per la gestione. Gli ambiti DHCP non devono sovrapporsi a questi IP statici. Il server DHCP non viene utilizzato per gli IP virtuali (VIP) |
Registro immagini | 1 | Consente di accedere a un registro per il servizio. |
Componente | Quantità minima | Configurazione richiesta |
---|---|---|
IP statici per le macchine virtuali del piano di controllo Kubernetes | Blocco di 5 | Un blocco di 5 indirizzi IP statici consecutivi da assegnare dalla rete di gestione alle macchine virtuali del piano di controllo Kubernetes in Supervisore. |
Rete traffico di gestione | 1 | Una rete di gestione instradabile verso gli host ESXi, il vCenter Server, il Supervisore e il bilanciamento del carico. |
Subnet della rete di gestione | 1 |
La subnet utilizzata per il traffico di gestione tra gli host ESXi e il
vCenter Server, le appliance NSX e il piano di controllo Kubernetes. Le dimensioni della subnet devono essere le seguenti:
Nota: La rete di gestione e la rete del carico di lavoro devono trovarsi in subnet diverse. L'assegnazione della stessa subnet alla rete di gestione e del carico di lavoro non è supportata e può causare problemi ed errori di sistema.
|
VLAN della rete di gestione | 1 | ID VLAN della subnet della rete di gestione. |
Componente | Quantità minima | Configurazione richiesta |
---|---|---|
Intervallo CIDR Pod vSphere | /23 indirizzi IP privati | Intervallo CIDR privato che fornisce gli indirizzi IP per lPod vSphere. Questi indirizzi vengono utilizzati anche per i nodi del cluster Tanzu Kubernetes Grid.
È necessario specificare un intervallo CIDR
Pod vSphere univoco per ogni cluster.
Nota: L'intervallo CIDR
Pod vSphere e l'intervallo CIDR per gli indirizzi del servizio Kubernetes non devono sovrapporsi.
|
Intervallo CIDR dei servizi Kubernetes | /16 indirizzi IP privati | Un intervallo CIDR privato per l'assegnazione di indirizzi IP ai servizi Kubernetes. È necessario specificare un intervallo CIDR dei servizi Kubernetes univoco per ogni Supervisore. |
Intervallo CIDR in uscita | /27 indirizzi IP statici | Annotazione CIDR privata per determinare l'IP in uscita per i servizi Kubernetes. Per ogni spazio dei nomi nel Supervisore viene assegnato un solo indirizzo IP di uscita. L'IP in uscita è l'indirizzo utilizzato dalle entità esterne per comunicare con i servizi nello spazio dei nomi. Il numero di indirizzi IP in uscita limita il numero di criteri in uscita che può avere il Supervisore.
Il valore minimo è un CIDR di /27 o superiore. Ad esempio,
10.174.4.96/27 .
Nota: Gli indirizzi IP in uscita e gli indirizzi IP in entrata non devono sovrapporsi.
|
CIDR in entrata | /27 indirizzi IP statici | Intervallo CIDR privato da utilizzare per gli indirizzi IP degli ingressi. L'ingresso consente di applicare criteri di traffico alle richieste inserendo il Supervisore da reti esterne. Il numero di indirizzi IP in ingresso limita il numero di ingressi che può avere il cluster.
Il valore minimo è un CIDR di /27 o superiore.
Nota: Gli indirizzi IP in uscita e gli indirizzi IP in entrata non devono sovrapporsi.
|
Intervallo di reti spazio dei nomi | 1 | Uno o più CIDR IP per creare subnet/segmenti e assegnare indirizzi IP ai carichi di lavoro. |
Prefisso subnet spazio dei nomi | 1 | Prefisso della subnet che specifica la dimensione della subnet riservata per i segmenti degli spazi dei nomi. Il valore predefinito è 28. |
Componente | Quantità minima | V |
---|---|---|
VLAN | 3 | Questi IP VLAN sono gli indirizzi IP per gli endpoint del tunnel (TEP). I TEP dell'host ESXi e i TEP Edge devono essere instradabili.
Gli indirizzi IP VLAN sono necessari per i seguenti elementi:
Nota: Il VTEP dell'host ESXi e il VTEP Edge devono avere dimensioni di MTU superiori a 1600.
Gli host ESXi e i nodi Edge NSX-T fungono da endpoint del tunnel e a ogni host e nodo Edge viene assegnato un IP dell'endpoint del tunnel (TEP). Poiché gli IP del TEP per gli host ESXi creano un tunnel overlay con IP TEP nei nodi Edge, gli IP della VLAN devono essere instradabili. È necessaria una VLAN aggiuntiva per fornire connettività nord-sud al gateway di livello 0. I pool di IP possono essere condivisi tra cluster. La VLAN/il pool di IP di overlay dell'host non devono invece essere condivisi con la VLAN/il pool di IP o di overlay Edge.
Nota: Se il TEP host e il TEP Edge utilizzano schede NIC fisiche diverse, possono utilizzare la stessa VLAN.
|
IP uplink di livello 0 | /24 indirizzi IP privati | La subnet IP utilizzata per l'uplink di livello 0. I requisiti per l'indirizzo IP dell'uplink di livello 0 sono i seguenti:
L'IP di gestione Edge, la subnet, il gateway, l'IP di uplink e il gateway devono essere univoci. |
Server NTP e DNS | 1 | L'IP del server DNS è necessario per consentire al controller NSX Advanced Load Balancer di risolvere correttamente vCenter Server e i nomi host ESXi. NTP è facoltativo perché per impostazione predefinita vengono utilizzati server NTP pubblici. |
Subnet rete dati | 1 | L'interfaccia dati dei motori di servizio, denominati anche motori di servizio, si connette a questa rete. Configurare un pool di indirizzi IP per i motori di servizio. Gli IP virtuali (VIP) del bilanciamento del carico vengono assegnati da questa rete. |
IP del controller NSX Advanced Load Balancer | 1 o 4 | Se si distribuisce il controller NSX Advanced Load Balancer come nodo singolo, è necessario un IP statico per la relativa interfaccia di gestione. Per un cluster a 3 nodi, sono necessari 4 indirizzi IP. Uno per ogni macchina virtuale del controller e uno per il VIP del cluster. Questi IP devono provenire dalla subnet della rete di gestione. |
Intervallo IPAM VIP | - | Un intervallo CIDR privato per l'assegnazione di indirizzi IP ai servizi Kubernetes. Gli IP devono provenire dalla subnet della rete dati. È necessario specificare un intervallo CIDR dei servizi Kubernetes univoco per ogni cluster supervisore. |
Porte e protocolli
In questa tabella sono elencati i protocolli e le porte necessari per la gestione della connettività IP tra NSX Advanced Load Balancer, vCenter Server e gli altri componenti di vSphere IaaS control plane.
Origine | Destinazione | Protocollo e porte |
---|---|---|
Controller NSX Advanced Load Balancer | Controller NSX Advanced Load Balancer (nel cluster) | TCP 22 (SSH) TCP 443 (HTTPS) TCP 8443 (HTTPS) |
Motore di servizio | Motore di servizio in HA | TCP 9001 per cloud VMware, LSC e NSX-T |
Motore di servizio | Controller NSX Advanced Load Balancer | TCP 22 (SSH) TCP 8443 (HTTPS) UDP 123 (NTP) |
Controller NSX Advanced Load Balancer | vCenter Server, ESXi, NSX-T Manager | TCP 443 (HTTPS) |
Nodi del piano di controllo supervisore (AKO) | Controller NSX Advanced Load Balancer | TCP 443 (HTTPS) |
Per ulteriori informazioni sulle porte e i protocolli per NSX Advanced Load Balancer, vedere https://ports.esp.vmware.com/home/NSX-Advanced-Load-Balancer.