Requisiti di networking

Google Cloud VMware Engine offre un ambiente cloud privato accessibile a utenti e applicazioni da ambienti on-premise, dispositivi gestiti dall'azienda e servizi Google Cloud come Virtual Private Cloud (VPC). Per stabilire la connettività tra cloud privati VMware Engine e altre reti, utilizza servizi di networking come Cloud VPN e Cloud Interconnect.

Alcuni servizi di rete richiedono intervalli di indirizzi specificati dall'utente per abilitare la funzionalità. Per aiutarti a pianificare il deployment, in questa pagina sono elencati i requisiti di networking e le funzionalità associate.

Connettività cloud privato VMware Engine

La connessione dalla tua rete VPC a VMware Engine varia a seconda che utilizzi reti standard o legacy.

Reti VMware Engine standard

La connessione dalla tua rete VPC a una rete VMware Engine standard utilizza il peering di rete VPC.

Reti VMware Engine legacy

La connessione dalla tua rete VPC a una rete VMware Engine legacy utilizza l'accesso privato ai servizi. Per accedere alle macchine virtuali (VM) dei carichi di lavoro da una rete on-premise o dalla rete VPC, configura l'accesso privato ai servizi dalla rete VPC alla rete VMware Engine.

Risoluzione globale degli indirizzi mediante Cloud DNS

Se vuoi risolvere gli indirizzi globali utilizzando Cloud DNS, abilita l'API Cloud DNS. Devi completare la configurazione di Cloud DNS prima di creare il tuo cloud privato.

Requisiti e restrizioni CIDR

VMware Engine usa intervalli di indirizzi impostati per servizi come l'hosting di appliance di gestione e il deployment di reti HCX. Alcuni intervalli di indirizzi sono obbligatori, mentre altri dipendono dai servizi di cui prevedi di eseguire il deployment.

Devi prenotare intervalli di indirizzi in modo che non si sovrappongano a nessuna delle tue subnet on-premise, di reti VPC o di subnet dei carichi di lavoro pianificate.

Inoltre, le VM dei carichi di lavoro e l'intervallo CIDR della subnet vSphere/vSAN non devono sovrapporsi ad alcun indirizzo IP nei seguenti intervalli:

  • 127.0.0.0/8
  • 224.0.0.0/4
  • 0.0.0.0/8
  • 169.254.0.0/16
  • 198.18.0.0/15
  • 240.0.0.0/4

Intervallo CIDR subnet vSphere/vSAN

VMware Engine esegue il deployment dei componenti di gestione di un cloud privato nell'intervallo CIDR delle subnet vSphere/vSAN indicato durante la creazione del cloud privato. Gli indirizzi IP in questo intervallo sono riservati per l'infrastruttura cloud privato e non possono essere utilizzati per le VM dei carichi di lavoro. Il prefisso dell'intervallo CIDR deve essere compreso tra /24 e /20.

Versioni di divisione dell'intervallo CIDR delle subnet

I cloud privati creati dopo novembre 2022 rispettano le allocazioni di subnet del layout degli indirizzi IP (piano IP) 2.0. Quasi tutti i cloud privati creati prima di novembre 2022 rispettano le allocazioni di subnet del piano IP versione 1.0.

Per scoprire quale versione utilizza il tuo cloud privato, completa i seguenti passaggi:

  1. Accedi alla console Google Cloud.
  2. Nel menu principale, fai clic su Private cloud.
  3. Fai clic sul cloud privato che vuoi esaminare.
  4. Cerca Versione del piano IP per scoprire quale versione utilizza questo cloud privato.

Il numero di versione viene visualizzato nella sezione Versione del piano IP.

Dimensione dell'intervallo CIDR delle subnet vSphere/vSAN

Le dimensioni dell'intervallo CIDR delle subnet vSphere/vSAN influiscono sulla dimensione massima del cloud privato. La tabella seguente mostra il numero massimo di nodi che puoi avere, in base alle dimensioni dell'intervallo CIDR delle subnet vSphere/vSAN.

Prefisso CIDR delle subnet vSphere/vSAN specificato Numero massimo di nodi (piano IP versione 1.0) Numero massimo di nodi (piano IP versione 2.0)
/24 26 10
/23 58 20
/22 118 40
/21 220 90
/20 N/A 200

Quando selezioni il prefisso dell'intervallo CIDR, considera i limiti di nodi sulle risorse in un cloud privato. Ad esempio, i prefissi dell'intervallo CIDR di /24 e /23 non supportano il numero massimo di nodi disponibili per un cloud privato. In alternativa, i prefissi dell'intervallo CIDR di /20 supportano più dell'attuale numero massimo di nodi disponibili per un cloud privato.

Divisione dell'intervallo CIDR della rete di gestione di esempio

L'intervallo CIDR delle subnet vSphere/vSAN specificato è diviso in più subnet. Le seguenti tabelle mostrano esempi dell'analisi per i prefissi consentiti. Il primo set di esempi utilizza 192.168.0.0 come intervallo CIDR per il piano IP versione 1.0, mentre il secondo set di esempi utilizza 10.0.0.0 per la versione 2.0 del piano IP.

Funzione Maschera subnet/prefisso (piano IP versione 1.0)
Intervallo CIDR subnet vSphere/vSAN 192.168.0.0/21 192.168.0.0/22 192.168.0.0/23 192.168.0.0/24
Gestione del sistema 192.168.0.0/24 192.168.0.0/24 192.168.0.0/25 192.168.0.0/26
vMotion 192.168.1.0/24 192.168.1.0/25 192.168.0.128/26 192.168.0.64/27
vSAN 192.168.2.0/24 192.168.1.128/25 192.168.0.192/26 192.168.0.96/27
Trasporto host NSX-T 192.168.4.0/23 192.168.2.0/24 192.168.1.0/25 192.168.0.128/26
Trasporto perimetrale NSX-T 192.168.7.208/28 192.168.3.208/28 192.168.1.208/28 192.168.0.208/28
Uplink1 edge NSX-T 192.168.7.224/28 192.168.3.224/28 192.168.1.224/28 192.168.0.224/28
Uplink2 edge NSX-T 192.168.7.240/28 192.168.3.240/28 192.168.1.240/28 192.168.0.240/28
Funzione Maschera subnet/prefisso (piano IP versione 2.0)
Intervallo CIDR subnet vSphere/vSAN 10.0.0.0/20 10.0.0.0/21 10.0.0.0/22 10.0.0.0/23 10.0.0.0/24
Gestione del sistema 10.0.0.0/22 10.0.0.0/23 10.0.0.0/24 10.0.0.0/25 10.0.0.0/26
vMotion 10.0.4.0/24 10.0.2.0/25 10.0.1.0/26 10.0.0.128/27 10.0.0.64/28
vSAN 10.0.5.0/24 10.0.2.128/25 10.0.1.64/26 10.0.0.160/27 10.0.0.80/28
Trasporto NSX-T 10.0.6.0/23 10.0.3.0/24 10.0.1.128/25 10.0.0.192/26 10.0.0.128/27
Uplink HCX 10.0.11.128/25 10.0.6.0/26 10.0.3.32/27 10.0.1.144/28 10.0.0.216/29
Uplink1 edge NSX-T 10.0.8.0/28 10.0.4.0/28 10.0.2.0/28 10.0.1.0/28 10.0.0.160/29
Uplink2 edge NSX-T 10.0.8.16/28 10.0.4.16/28 10.0.2.16/28 10.0.1.16/28 10.0.0.168/29
Uplink3 perimetrale NSX-T 10.0.8.32/28 10.0.4.32/28 10.0.2.32/28 10.0.1.32/28 10.0.0.176/29
Uplink4 NSX-T 10.0.8.48/28 10.0.4.48/28 10.0.2.48/28 10.0.1.48/28 10.0.0.184/29

Scalabilità perimetrale HCX e NSX-T (solo piano IP versione 2.0)

Prefisso CIDR delle subnet vSphere/vSAN specificato Numero massimo di siti HCX remoti Numero massimo di appliance HCX Network Extension Numero massimo di VM Edge NSX-T
/24 2 1 2
/23 4 2 4
/22 14 8 8
/21 25 32 8
/20 25 64 8

Intervallo CIDR rete di deployment HCX (solo piano IP versione 1.0)

Nella versione 1.0 del piano IP, HCX non era integrato nell'intervallo CIDR delle subnet vSphere/vSAN. Quando hai creato un cloud privato, facoltativamente, puoi chiedere a VMware Engine di installare HCX sul cloud privato specificando un intervallo CIDR di rete da utilizzare per i componenti HCX. Il prefisso dell'intervallo CIDR era /26 o /27.

VMware Engine ha diviso la rete che hai fornito in tre subnet:

  • Gestione HCX: utilizzata per l'installazione di HCX Manager.
  • HCX vMotion: utilizzato per vMotion delle VM tra l'ambiente on-premise e il cloud privato di VMware Engine.
  • HCX WANUplink: utilizzato per stabilire il tunnel tra l'ambiente on-premise e il cloud privato di VMware Engine.

Esempio di suddivisione dell'intervallo CIDR HCX

L'intervallo CIDR per il deployment di HCX specificato è diviso in più subnet. La tabella seguente mostra alcuni esempi di suddivisione dei prefissi consentiti. Gli esempi utilizzano 192.168.1.0 come intervallo CIDR.

Funzione Maschera subnet/prefisso
Intervallo CIDR rete di deployment HCX 192.168.1.0/26 192.168.1.64/26 192.168.1.0/27 192.168.1.32/27
HCX Manager 192.168.1.13 192.168.1.77 192.168.1.13 192.168.1.45

Accesso privato ai servizi a VMware Engine

La tabella seguente descrive i requisiti di intervallo di indirizzi per la connessione privata ai servizi Google Cloud.

Nome/scopo Descrizione Prefisso CIDR
Intervallo di indirizzi assegnati Intervallo di indirizzi da utilizzare per la connessione privata ai servizi Google Cloud, incluso VMware Engine. /24 o superiore

Servizi di networking perimetrale forniti da VMware Engine

La tabella seguente descrive i requisiti relativi all'intervallo di indirizzi per i servizi di networking perimetrale forniti da VMware Engine.

Nome/scopo Descrizione Prefisso CIDR
CIDR servizi perimetrali Obbligatorio se sono abilitati servizi periferici facoltativi come l'accesso a internet e l'IP pubblico per ogni regione. /26

Accesso alle API di Google private/limitate

Per impostazione predefinita, i CIDR privati 199.36.153.8/30 e 199.36.153.4/30 limitati vengono pubblicizzati nella rete VMware Engine per supportare l'accesso diretto ai servizi Google. Il CIDR privato 199.36.153.8/30 può essere ritirato al momento della configurazione dei Controlli di servizio VPC.

Requisiti delle porte del firewall

Puoi configurare una connessione dalla tua rete on-premise al cloud privato utilizzando la VPN site-to-site o Dedicated Interconnect. Utilizza la connessione per accedere al tuo VMware Private Cloud vCenter e a tutti i carichi di lavoro in esecuzione nel cloud privato.

Puoi controllare quali porte vengono aperte nella connessione utilizzando un firewall nella tua rete on-premise. Questa sezione elenca i requisiti comuni delle porte delle applicazioni. Per i requisiti delle porte di altre applicazioni, consulta la documentazione dell'applicazione.

Per ulteriori informazioni sulle porte utilizzate per i componenti VMware, consulta Porte e protocolli VMware.

Porte necessarie per accedere a vCenter

Per accedere a vCenter Server e a NSX-T Manager nel tuo cloud privato, apri le seguenti porte nel firewall on-premise:

Porta Origine Destinazione Finalità
53 (UDP) Server DNS on-premise Server DNS cloud privati Richiesto per inoltrare la ricerca DNS di gve.goog ai server Cloud DNS privati dalla rete on-premise.
53 (UDP) Server DNS cloud privati Server DNS on-premise Richiesto per inoltrare la ricerca DNS dei nomi di dominio on-premise dal cloud privato vCenter ai server DNS on-premise.
80 (TCP) Rete on-premise Rete di gestione del cloud privato Obbligatorio per reindirizzare l'URL vCenter da HTTP a HTTPS.
443 (TCP) Rete on-premise Rete di gestione del cloud privato Richiesto per accedere a vCenter e NSX-T Manager dalla rete on-premise.
8000 (TCP) Rete on-premise Rete di gestione del cloud privato Richiesto per vMotion di macchine virtuali (VM) da on-premise al cloud privato.
8000 (TCP) Rete di gestione del cloud privato Rete on-premise Richiesto per vMotion delle VM dal cloud privato a on-premise.

Porte comuni necessarie per accedere alle VM dei carichi di lavoro

Per accedere alle VM dei carichi di lavoro in esecuzione sul tuo cloud privato, devi aprire le porte sul firewall on-premise. Nella tabella seguente sono elencate le porte più comuni. Per eventuali requisiti delle porte specifici per le applicazioni, consulta la documentazione dell'applicazione.

Porta Origine Destinazione Finalità
22 (TCP) Rete on-premise Rete dei carichi di lavoro del cloud privato Accesso sicuro dalla shell alle VM Linux in esecuzione su un cloud privato.
3389 (TCP) Rete on-premise Rete dei carichi di lavoro del cloud privato Da desktop remoto a VM Windows Server in esecuzione su cloud privato.
80 (TCP) Rete on-premise Rete dei carichi di lavoro del cloud privato Accedi a qualsiasi server web di cui è stato eseguito il deployment su VM in esecuzione su cloud privato.
443 (TCP) Rete on-premise Rete dei carichi di lavoro del cloud privato Accedi a qualsiasi server web sicuro di cui è stato eseguito il deployment su VM in esecuzione sul cloud privato.
389 (TCP/UDP) Rete dei carichi di lavoro del cloud privato Rete Active Directory on-premise Unisci le VM dei carichi di lavoro di Windows Server al dominio Active Directory on-premise.
53 (UDP) Rete dei carichi di lavoro del cloud privato Rete Active Directory on-premise Accesso al servizio DNS per le VM dei carichi di lavoro ai server DNS on-premise.

Porte richieste per utilizzare Active Directory on-premise come origine identità

Per un elenco delle porte necessarie per configurare la tua Active Directory on-premise come origine identità nel cloud privato vCenter, consulta Configurazione dell'autenticazione mediante Active Directory.