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 di VMware Engine e altre reti, puoi utilizzare 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.
Per ulteriori informazioni sui concetti di networking e considerazioni sull'utilizzo di VMware Engine per la progettazione di un'architettura di networking, consulta il white paper "Private Cloud Networking per VMware Engine".
Connettività al cloud privato di VMware Engine
Per connettere una rete VPC a un cloud privato VMware Engine, devi configurare l'accesso privato ai servizi. Questo processo è necessario anche per la connessione al tuo ambiente on-premise da VMware Engine.
Per accedere al cloud privato VMware Engine da on-premise o da un sito remoto, utilizza Cloud VPN o Cloud Interconnect. Scegli e segui le istruzioni di configurazione appropriate per Cloud VPN e Cloud Interconnect in base alle tue esigenze.
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 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 subnet on-premise, subnet di rete VPC o 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 negli intervalli seguenti:
- 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 fornito 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 seguono le allocazioni di subnet del layout degli indirizzi IP (piano IP) versione 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 a quale versione del cloud privato è conforme, completa i seguenti passaggi:
- Accedi al portale Google Cloud VMware Engine.
- Nella pagina Risorse, fai clic su Riepilogo.
Il numero di versione viene visualizzato sotto Versione piano IP.
Dimensione dell'intervallo CIDR delle subnet vSphere/vSAN
La dimensione dell'intervallo CIDR delle subnet vSphere/vSAN influisce sulla dimensione massima del cloud privato. La tabella seguente mostra il numero massimo di nodi possibile, in base alle dimensioni dell'intervallo CIDR delle subnet vSphere/vSAN.
| Prefisso CIDR delle subnet vSphere/vSAN specificati | 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 dei nodi per le 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 un numero di nodi superiore a quello massimo attuale disponibile per un cloud privato.
Esempio di divisione dell'intervallo CIDR della rete di gestione
L'intervallo CIDR delle subnet vSphere/vSAN specificato è suddiviso in più subnet. Le seguenti tabelle mostrano esempi di suddivisione per i prefissi consentiti. Il primo insieme di esempi utilizza 192.168.0.0 come intervallo CIDR per il piano IP versione 1.0 e il secondo insieme utilizza 10.0.0.0 per il piano IP versione 2.0.
| Funzione | Subnet mask/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 perimetrale NSX-T | 192.168.7.240/28 | 192.168.3.240/28 | 192.168.1.240/28 | 192.168.0.240/28 |
| Funzione | Subnet mask/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 perimetrale 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 perimetrale | 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 specificati | Numero massimo di siti HCX remoti | Numero massimo di appliance di estensione di rete HCX | Numero massimo di VM NSX-T Edge |
|---|---|---|---|
| /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, puoi facoltativamente chiedere a VMware Engine di installare HCX sul cloud privato specificando un intervallo CIDR di rete per l'utilizzo da parte dei 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:per l'installazione di HCX Manager.
- HCX vMotion: utilizzato per la vMotion di VM tra l'ambiente on-premise e il cloud privato 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 del deployment HCX specificato è diviso in più subnet. La seguente tabella mostra esempi della suddivisione per i prefissi consentiti. Gli esempi utilizzano 192.168.1.0 come intervallo CIDR.
| Funzione | Subnet mask/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 il requisito dell'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, tra cui VMware Engine. | /24 o più grande |
Servizi di networking perimetrale forniti da VMware Engine
La tabella seguente descrive il requisito dell'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 perimetrali facoltativi, come l'accesso a internet e l'IP pubblico, in base alla regione. | /26 |
Requisiti delle porte del firewall
Puoi configurare una connessione dalla rete on-premise al cloud privato utilizzando la VPN site-to-site o Dedicated Interconnect. Utilizza la connessione per accedere al tuo vCenter nel cloud privato VMware e ai carichi di lavoro eseguiti nel cloud privato.
Puoi controllare quali porte vengono aperte nella connessione utilizzando un firewall nella rete on-premise. Questa sezione elenca i requisiti comuni per le porte delle applicazioni. Per i requisiti delle porte di qualsiasi altra applicazione, consulta la documentazione dell'applicazione.
Per ulteriori informazioni sulle porte utilizzate per i componenti VMware, consulta Porte e protocolli VMware.
Porte richieste per accedere a vCenter
Per accedere a vCenter Server e 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 DNS del cloud privato 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 da vCenter nel cloud privato 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 | Obbligatorio 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 a cloud privato. |
| 8000 (TCP) | Rete di gestione del cloud privato | Rete on-premise | Obbligatorio per vMotion delle VM dal cloud privato a on-premise. |
Porte comuni necessarie per l'accesso alle VM dei carichi di lavoro
Per accedere alle VM dei carichi di lavoro in esecuzione sul tuo cloud privato, devi aprire le porte nel firewall on-premise. Nella tabella seguente sono elencate le porte più comuni. Per eventuali requisiti delle porte specifici per l'applicazione, consulta la documentazione dell'applicazione.
| Porta | Origine | Destinazione | Finalità |
|---|---|---|---|
| 22 (TCP) | Rete on-premise | Rete di carichi di lavoro cloud privati | Accesso sicuro alla shell alle VM Linux in esecuzione su cloud privato. |
| 3389 (TCP) | Rete on-premise | Rete di carichi di lavoro cloud privati | Da desktop remoto a VM Windows Server in esecuzione sul cloud privato. |
| 80 (TCP) | Rete on-premise | Rete di carichi di lavoro cloud privati | Accedi a qualsiasi server web di cui è stato eseguito il deployment su VM in esecuzione sul cloud privato. |
| 443 (TCP) | Rete on-premise | Rete di carichi di lavoro cloud privati | Accedi a qualsiasi server web sicuro di cui è stato eseguito il deployment su VM in esecuzione nel cloud privato. |
| 389 (TCP/UDP) | Rete di carichi di lavoro cloud privati | Rete Active Directory on-premise | Unisci le VM dei carichi di lavoro di Windows Server al dominio Active Directory on-premise. |
| 53 (UDP) | Rete di carichi di lavoro cloud privati | Rete Active Directory on-premise | Accesso al servizio DNS per le VM dei carichi di lavoro nei server DNS on-premise. |
Porte richieste per utilizzare Active Directory on-premise come origine identità
Per un elenco delle porte necessarie per configurare Active Directory on-premise come origine identità nel cloud privato vCenter, consulta Configurazione dell'autenticazione utilizzando Active Directory.