Last reviewed 2023-03-01 UTC

Networking cloud privato per VMware Engine

Questo documento fornisce una panoramica di Google Cloud VMware Engine, illustra i concetti di networking, esamina i flussi di traffico più tipici e fornisce alcune considerazioni sull'utilizzo di VMware Engine per progettare un'architettura. Il documento spiega come funziona VMware Engine, quali sono le sue funzionalità e cosa considerare quando si sceglie la migliore architettura.

Questo documento è pertinente per te se sei network engineer, cloud engineer, architetto o operatore con il compito di progettare, gestire o risolvere i problemi relativi a sicurezza, connettività e disponibilità di applicazioni supportate da VMware e ospitate in Google Cloud.

Questo documento ti aiuta anche a saperne di più su VMware Engine e sui suoi requisiti e funzionalità. Man mano che approfondisci la tecnologia, o se ne eseguirai un progetto pilota o ne eseguirai il deployment in produzione, questo documento ti aiuta a capire come funziona VMware Engine e come integrarla con un ambiente Google Cloud nuovo o esistente. Questo documento esamina tutti gli aspetti del networking e ti aiuta a determinare la soluzione migliore per il tuo caso d'uso.

Il networking VMware Engine si integra con le reti Virtual Private Cloud (VPC) che dispongono di connettività esistente con le reti on-premise e con altri servizi Google Cloud. VMware Engine è basato su un'infrastruttura ad alte prestazioni, affidabile e ad alta capacità, per fornirti un'esperienza VMware economica ottimale.

Panoramica

VMware Engine è un servizio fornito da Google che ti aiuta a migrare ed eseguire i carichi di lavoro VMware su Google Cloud.

VMware Engine offre un data center software-defined VMware (SDDC) completamente gestito, costituito dai seguenti componenti: VMware vSphere, vCenter Server, vSAN e NSX-T. VMware Engine include HCX per la migrazione al cloud in un ambiente dedicato su Google Cloud per supportare i carichi di lavoro di produzione aziendali. Puoi utilizzare VMware Engine per eseguire la migrazione o estendere i carichi di lavoro on-premise a Google Cloud collegandoti a un ambiente VMware dedicato direttamente tramite la console Google Cloud. Questa funzionalità consente di eseguire la migrazione al cloud senza i costi o la complessità del refactoring delle applicazioni e consente di eseguire e gestire i carichi di lavoro in modo coerente con l'ambiente on-premise. Quando esegui i carichi di lavoro VMware su Google Cloud, riduci il carico operativo, beneficiando al contempo di scalabilità e agilità e mantieni la continuità con gli strumenti, i criteri e i processi esistenti.

VMware Engine è basato sull'infrastruttura scalabile e ad alte prestazioni di Google Cloud con un networking dedicato a 100 Gbps completamente ridondante, che fornisce una disponibilità fino al 99,99% per soddisfare le esigenze del tuo stack VMware. I servizi di networking Cloud come Cloud Interconnect e Cloud VPN ti consentono di accedere dal tuo ambiente on-premise al cloud. L'elevata larghezza di banda di queste connessioni ai servizi cloud è ottimizzata per prestazioni e flessibilità, riducendo al minimo i costi e l'overhead operativo. L'assistenza end-to-end e completa offre un'esperienza integrata e senza interruzioni in questo servizio e nel resto di Google Cloud.

Dopo aver spostato i carichi di lavoro, avrai accesso immediato ai servizi Google Cloud come BigQuery, Suite operativa di Google Cloud, Cloud Storage, Anthos e AI Cloud. Google Cloud offre inoltre fatturazione e gestione delle identità e controllo degli accessi completamente integrati per unificare la tua esperienza con altri prodotti e servizi Google Cloud.

Casi d'uso

Il seguente diagramma è un'architettura di riferimento rappresentativa che mostra come eseguire la migrazione o estendere l'ambiente VMware in Google Cloud sfruttando al contempo i servizi Google Cloud. VMware Engine offre soluzioni per i seguenti casi d'uso.

Requisiti per l'onboarding

Prima di iniziare il deployment di VMware Engine in Google Cloud, assicurati di aver letto i requisiti per l'onboarding.

Componenti di sistema

A livello generale, i componenti VMware Engine sono i seguenti:

• Google Cloud:
  • VMware Engine:
    • NSX-T
    • HCX
    • vCenter
    • VSAN (vSAN)
  • La tua organizzazione Google Cloud:
    • Il tuo progetto Google Cloud con una rete VPC
    • Cloud Interconnect tramite Partner Interconnect o la connessione Dedicated Interconnect o Cloud VPN ai sistemi on-premise
    • Connessione di accesso privato ai servizi alla regione di VMware Engine
  • Connessione di accesso privato ai servizi
  • Integrazione dei servizi gestiti Google
• (Facoltativo) Risorse on-premise:
  • Networking
  • Archiviazione
  • HCX (consigliato per connessioni di livello 2, noto anche come L2 stretch)
  • vCenter

Un cloud privato è uno stack VMware isolato composto da host ESXi, vCenter, vSAN, NSX-T e HCX. Questi componenti sono noti collettivamente come componenti di Google Cloud VMware Engine e vengono distribuiti quando l'amministratore del cloud crea un cloud privato. Gli utenti della tua organizzazione possono quindi accedere privatamente ai cloud privati di VMware Engine dalle loro reti VPC stabilendo una connessione di accesso privato ai servizi. Il seguente diagramma mostra questa architettura.

L'accesso privato ai servizi è una connessione privata tra la tua rete VPC e una rete di proprietà di Google o di una terza parte. Google o le entità di terze parti che offrono servizi sono noti anche come producer di servizi.

Per ciascuna delle tue reti VPC connesse a VMware Engine, esiste una rete VPC del producer di servizi che viene creata quando crei una connessione di accesso privato ai servizi in Google Cloud. Il progetto Google Cloud contiene una rete VPC condiviso che può essere utilizzata per la connessione ad altri servizi Google Cloud, come Memorystore e Cloud SQL. Ad esempio, puoi eseguire il lift and shift delle VM MySQL o PostgreSQL on-premise in VMware Engine, quindi eseguirne la migrazione in Cloud SQL utilizzando il Database Migration Service incorporato di Google Cloud, permettendo comunque ai carichi di lavoro VMware Engine di accedere a questi database.

VMware non richiede l'utilizzo di NSX-T on-premise. Inoltre, l'utilizzo di HCX non è obbligatorio per nessuno dei casi d'uso, perché è possibile utilizzare altri meccanismi per ottenere lo stretching di livello 2 (L2) e la migrazione dei carichi di lavoro. Tuttavia, ti consigliamo HCX per una migrazione efficiente dei carichi di lavoro e comodità, poiché il deployment di questa funzionalità viene eseguito automaticamente quando crei il tuo cloud privato se selezioni questa opzione.

Importante: prima di eseguire il deployment di un cloud privato, considera i requisiti di preparazione e onboarding descritti in Requisiti di rete.

Funzionalità di networking

Di seguito è riportato un riepilogo delle funzionalità di networking di VMware Engine:

• Connettività multi-VPC: VMware Engine consente di connettere lo stesso cloud privato a più reti VPC (fino a tre in totale o due se utilizzi il servizio internet regionale). Queste reti VPC possono essere reti VPC consumer o MPS (Managed Partner Services).
• Subnet: puoi creare subnet di gestione e dei carichi di lavoro nei tuoi cloud privati.
• Routing dinamico: le subnet VMware Engine amministrate da NSX vengono annunciate automaticamente nel resto della rete Google e nelle località on-premise tramite il protocollo BGP (Border Gateway Protocol).
• Funzionalità di routing globale e a livello di regione: puoi controllare se le reti VPC condiviso del producer di servizi che connettono i tuoi cloud privati possono instradare solo all'interno di una regione o a livello globale.
• Servizio IP pubblico e gateway Internet (in entrata e in uscita): VMware Engine dispone di un servizio IP pubblico per il traffico in entrata e in uscita da gateway Internet. Questo è un servizio regionale.
• Criteri firewall: VMware Engine consente di creare criteri firewall L4 e L7 utilizzando il firewall distribuito NSX (est-west) e il firewall del gateway NSX (nord-sud). Ad esempio, puoi applicare controlli granulari per accedere a carichi di lavoro con indirizzi IP pubblici, come i server web.
• Concatenamento di servizi per la sicurezza da est a ovest: offre la possibilità di registrare una soluzione di sicurezza dei partner (IDS, IPS o NGFW) per configurare i servizi di rete al fine di ispezionare il traffico da est a ovest che si sposta tra le VM.
• Protezione degli endpoint: le VM supportate da VMware Engine possono essere protette da malware e virus attraverso l'integrazione dei partner con terze parti supportate. Per ulteriori informazioni, consulta la documentazione ufficiale di VMware.
• Accesso privato ad altri servizi Google:VMware Engine si integra con altri servizi Google Cloud utilizzando l'accesso privato Google e l'accesso privato ai servizi. Per un elenco completo dei servizi supportati, vedi Opzioni di accesso privato per i servizi.
• Funzionalità DNS
  • DNS per l'accesso all'appliance di gestione: la risoluzione globale degli indirizzi delle appliance di gestione di VMware Engine (come vCenter e NSX Manager) mediante Cloud DNS consente di accedere alle appliance senza l'intervento dell'utente.
  • DNS per i carichi di lavoro: per ogni cloud privato, sei tu a decidere quale configurazione DNS è più adatta alle tue esigenze. Il servizio DNS NSX-T ti consente di inoltrare query DNS a determinati server DNS, di creare il tuo server DNS in VMware Engine o on-premise oppure di utilizzare Cloud DNS o Compute Engine.
• Server DHCP: è incluso il supporto del server DHCP per i segmenti NSX-T.
• Inoltro DHCP: l'inoltro DHCP consente alle organizzazioni, ad esempio, di integrarsi con un sistema di gestione degli indirizzi IP (IPAM) on-premise.
• VPN di livello 2 da sito a sito e VPN di livello 3:questi servizi sono configurati direttamente in NSX utilizzando rispettivamente VPN di livello 2 e VPN IPsec.
• Bilanciamento del carico: questo servizio utilizza le funzionalità di bilanciamento del carico integrate di NSX-T, che includono il supporto L4 e L7, nonché i controlli di integrità.
• Supporto del routing IP multicast parziale: è supportato il protocollo PIM ( Protocol Independent Multicast), come descritto nella documentazione di VMware.
• Supporto IPv6 parziale: questa funzionalità consente alle organizzazioni di sfruttare l'IPv6 per le proprie applicazioni supportate da VMware Engine, come descritto nella Guida alla progettazione di NSX-T 3.0.
• Migrazione delle VM a lunga distanza (vMotion): le migrazioni in tempo reale (le applicazioni continuano a essere eseguite) e a freddo (le applicazioni vengono spente) sono supportate tra ambienti on-premise e cloud oppure tra cloud e cloud all'interno di VMware Engine con ottimizzazione WAN, crittografia e mobilità supportata dalla replica. Ciò è possibile grazie a VMware HCX, che è incluso nel servizio.
• Operazioni di rete avanzate: puoi utilizzare strumenti e strumentazione integrati di NSX, tra cui mirroring delle porte, Traceflow, acquisizione di pacchetti edSNMP v1/v2/v3 con polling e trap, tra gli altri.

Reti e intervalli di indirizzi

Google Cloud VMware Engine crea una rete per ogni regione in cui viene eseguito il deployment del servizio VMware Engine. La rete è un singolo spazio di indirizzi di livello 3 con il routing abilitato per impostazione predefinita. Tutti i cloud privati e le subnet che crei in questa regione possono comunicare tra loro senza alcuna configurazione aggiuntiva. Puoi creare segmenti di rete (subnet) utilizzando NSX-T per le macchine virtuali dei tuoi carichi di lavoro. Puoi configurare qualsiasi intervallo di indirizzi RFC 1918 che non si sovrapponga a reti on-premise, alla rete di gestione del cloud privato o a qualsiasi subnet VPC. Sono supportati anche gli indirizzi IP pubblici (PUPI) utilizzati privatamente.

Per impostazione predefinita, tutte le subnet possono comunicare tra loro, riducendo l'overhead di configurazione per il routing tra i cloud privati. Il traffico di dati attraverso i cloud privati nella stessa regione rimane nella stessa rete di livello 3 e viene trasferito sull'infrastruttura di rete locale all'interno della regione, quindi non è necessario il traffico in uscita per la comunicazione tra questi cloud privati. Questo approccio elimina qualsiasi penalizzazione per le prestazioni WAN o in uscita quando esegui il deployment di carichi di lavoro diversi in cloud privati diversi.

Concettualmente, un cloud privato viene creato come ambiente stack VMware isolato (host ESXi, vCenter, vSAN e NSX) gestito da un server vCenter. Il deployment dei componenti di gestione viene eseguito nella rete selezionata per l'intervallo CIDR delle subnet vSphere/vSAN. L'intervallo CIDR di rete è diviso in diverse subnet durante il deployment.

Subnet di gestione in VMware Engine

VMware Engine utilizza diversi intervalli di indirizzi IP. Alcuni intervalli di indirizzi IP sono obbligatori, mentre altri dipendono dai servizi di cui prevedi di eseguire il deployment. Lo spazio di indirizzi IP non deve sovrapporsi ad alcuna subnet on-premise, a una subnet VPC o a una subnet dei carichi di lavoro pianificata. Le seguenti sezioni descrivono l'insieme di intervalli di indirizzi e i servizi corrispondenti che utilizzano tali intervalli.

Importante: è possibile avere subnet sovrapposte in VMware Engine e creare voci NAT nei router NSX per connetterti al resto del mondo. Questa configurazione consente alcuni casi d'uso in cui sono necessari gli stessi intervalli CIDR in due o più ambienti (ad esempio per simulare ambienti di produzione e non di produzione nello stesso cloud privato). Configura attentamente routing e NAT per evitare conflitti derivati dall'implementazione di intervalli di indirizzi IP sovrapposti.

Il seguente diagramma offre una panoramica delle subnet di gestione per i servizi spiegati nelle sezioni seguenti:

CIDR vSphere/vSAN

I seguenti intervalli di indirizzi IP sono necessari per inizializzare e creare un cloud privato:

Nome	Descrizione	intervallo di indirizzi
CIDR vSphere/vSAN	Obbligatorio per le reti di gestione VMware. Deve essere specificato durante la creazione del cloud privato. Necessario anche per vMotion.	/21, /22, /23 o /24

Nota: non puoi modificare l'intervallo CIDR in un secondo momento, quindi assicurati di impostarlo correttamente quando esegui il deployment del cloud privato.

Quando crei un cloud privato, vengono create automaticamente diverse subnet di gestione. Le subnet di gestione utilizzano l'allocazione CIDR vSphere/vSAN richiesta descritta in precedenza in questo documento. Di seguito è riportata un'architettura di esempio e una descrizione delle diverse subnet create utilizzando questo intervallo CIDR:

• Gestione del sistema: VLAN e subnet per la rete di gestione degli host ESXi, il server DNS e il server vCenter.
• vMotion: VLAN e subnet per la rete vMotion degli host ESXi.
• vSAN: VLAN e subnet per la rete vSAN degli host ESXi.
• NsxtEdgeUplink1: VLAN e subnet per uplink VLAN a una rete esterna.
• NsxtEdgeUplink2: VLAN e subnet per uplink VLAN a una rete esterna.
• NsxtEdgeTransport: VLAN e subnet per zone di trasporto che controllano la copertura delle reti di livello 2 in NSX-T.
• NsxtHostTransport:VLAN e subnet per la zona di trasporto dell'host.

Esempio:

L'intervallo CIDR delle subnet vSphere/vSAN specificato è diviso in più subnet. La tabella seguente fornisce un esempio di suddivisione dei prefissi consentiti (da /21 a /24) utilizzando 192.168.0.0 come intervallo CIDR.

CIDR/prefisso subnet vSphere/vSAN specificati	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 (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 di NSX-T	192.168.7.224/28	192.168.3.224/28	192.168.1.224/28	192.168.0.224/28
Uplink2 NSX-T edge	192.168.7.240/28	192.168.3.240/28	192.168.1.240/28	192.168.0.240/28

A seconda dell'intervallo CIDR selezionato, la subnet mask di ogni subnet cambia. Ad esempio, se selezioni un CIDR vSphere/vSAN di /21, vengono create le seguenti subnet: una subnet di gestione del sistema /24, una subnet vMotion /24, una subnet vSAN /24, una subnet di trasporto host /23 NSX-T, una subnet di trasporto per perimetro NSX-T /28, un uplink1 perimetrale /28 NSX-T e un edge uplink NS2 /28 di NSX-T.

Nota: l'unico intervallo CIDR richiesto per creare la tua infrastruttura cloud privata è l'intervallo CIDR vSphere/vSAN. Gli intervalli CIDR aggiuntivi sono necessari solo se vuoi aggiungere funzionalità aggiuntive, ad esempio HCX per la migrazione delle VM o Servizi Edge per l'accesso a Internet pubblico. Tieni presente che gli intervalli CIDR per le subnet dei carichi di lavoro sono configurati direttamente in NSX.

Intervallo CIDR deployment HCX

I seguenti intervalli di indirizzi IP sono obbligatori per HCX sul tuo cloud privato:

Nome	Descrizione	intervallo di indirizzi
Intervallo CIDR deployment HCX	Richiesto per il deployment di reti HCX. Facoltativo durante la creazione di cloud privato.	/27 o più grande

Intervallo di indirizzi assegnati

Per l'accesso privato ai servizi a VMware Engine sono richiesti i seguenti indirizzi IP:

Nome	Descrizione	intervallo di indirizzi
Intervallo di indirizzi assegnati	Intervallo di indirizzi da utilizzare per la connessione privata ai servizi ai servizi Google Cloud, incluso VMware Engine.	/24 o più grande

Servizi perimetrali e subnet client

I seguenti intervalli di indirizzi IP sono richiesti per abilitare i servizi di networking perimetrale forniti da VMware Engine:

Nome	Descrizione	intervallo di indirizzi
Intervallo CIDR servizi perimetrali	Obbligatorio se sono abilitati servizi periferici facoltativi, come VPN point-to-site, accesso a internet e indirizzo IP pubblico. Gli intervalli sono determinati in base alla regione.	/26
Subnet client	Obbligatorio per la VPN da punto a sito. Gli indirizzi DHCP vengono forniti alla connessione VPN dalla subnet client.	/24

Opzioni di accesso privato di Google per i servizi

Google Cloud offre diverse opzioni di accesso privato per i carichi di lavoro in esecuzione in VMware Engine o nelle tue reti VPC Google. L'accesso privato ai servizi fornisce una connessione privata tra la tua rete VPC e il servizio VMware Engine. Quando utilizzi l'accesso privato Google, i tuoi carichi di lavoro VMware possono accedere ad altre API e servizi Google Cloud senza uscire dalla rete Google Cloud.

Accesso privato ai servizi

VMware Engine utilizza l'accesso privato ai servizi per connettere la tua rete VPC a una rete VPC del producer di servizi in una cartella tenant della tua organizzazione Google utilizzando l'indirizzo IP privato.

Per informazioni su come configurare l'accesso privato ai servizi, consulta Configurazione dell'accesso privato ai servizi. L'accesso privato ai servizi crea una connessione in peering di rete VPC, quindi è importante importare ed esportare le route.

Google e terze parti (collettivamente noti come producer di servizi) possono offrire servizi con indirizzi IP interni ospitati in una rete VPC. L'accesso privato ai servizi ti consente di raggiungere quegli indirizzi IP interni. La connessione privata consente la seguente funzionalità:

• Le istanze VM nella rete VPC e le VM VMware comunicano esclusivamente utilizzando indirizzi IP interni. Le istanze VM non hanno bisogno dell'accesso a internet o di indirizzi IP esterni per raggiungere i servizi disponibili tramite l'accesso privato ai servizi.

• Comunicazione tra le VM VMware e i servizi supportati Google Cloud che supportano l'accesso privato ai servizi tramite indirizzi IP interni.

• Se disponi di connettività on-premise mediante Cloud VPN o Cloud Interconnect alla tua rete VPC, puoi utilizzare le connessioni on-premise esistenti per connetterti al cloud privato di VMware Engine.

Se utilizzi una rete VPC condiviso nel tuo progetto, l'intervallo di indirizzi IP e la connessione privata allocati devono essere creati nel progetto host per consentire alle istanze VM nei progetti di servizio di essere connesse con l'ambiente.

Puoi configurare l'accesso privato ai servizi indipendentemente dalla creazione del cloud privato di VMware Engine. Puoi anche creare una connessione privata prima o dopo aver creato il cloud privato a cui vuoi connettere la tua rete VPC.

Di conseguenza, quando configuri l'accesso privato ai servizi, devi allocare un intervallo di indirizzi IP interni e creare una connessione privata come descritto nella sezione precedente. Questo intervallo allocato è un blocco CIDR riservato utilizzato per la connessione di accesso privato ai servizi e non può essere utilizzato nella rete VPC locale. Questo intervallo è riservato solo ai producer di servizi e impedisce la sovrapposizione tra la rete VPC e la rete VPC del producer di servizi. Quando crei una connessione privata ai servizi, devi specificare un'allocazione. Per informazioni sul lato producer di servizi, consulta Abilitazione dell'accesso privato ai servizi.

Per evitare sovrapposizioni di indirizzi IP, ti consigliamo di allocare tutte le subnet VMware Engine nella connessione ai servizi privati. Nello screenshot seguente, il blocco CIDR di VMware Engine viene utilizzato per la connessione privata ai servizi e il blocco CIDR gcve-2 è allocato per evitare sovrapposizioni degli indirizzi IP:

Service Networking non controlla la presenza di indirizzi sovrapposti sulle route dinamiche ricevute, quindi devi associare l'accesso privato ai servizi con prefissi riservati ai servizi non VMware. In questo modo si evitano problemi causati dalla sovrapposizione degli indirizzi IP, perché stai prenotando intervalli CIDR e non potrai utilizzarli nella rete VPC.

Quando configuri l'accesso privato ai servizi, assicurati che la connessione in peering VPC sia configurata correttamente per importare ed esportare tutte le route sulla connessione privata servicenetworking-googleapis-com. Devi anche prendere nota dell'ID progetto in peering in modo da poterlo utilizzare quando configuri una connessione privata in VMware Engine.

La rete VPC del producer di servizi viene connessa automaticamente al servizio VMware Engine, che contiene il tuo cloud privato (un vCenter privato e una singola installazione NSX-T).

VMware Engine utilizza la stessa connessione a più servizi Google Cloud di cui è stato eseguito il provisioning all'interno della rete VPC del producer di servizi che utilizzano l'accesso a servizi privati come Cloud SQL, Memorystore for Redis, Memorystore for Memcached, AI Platform Training e cluster privati GKE. Se vuoi utilizzare questi servizi, puoi selezionare l'intervallo CIDR utilizzato per stabilire la connessione privata ai servizi con VMware Engine.

Nel portale di servizio VMware Engine, quando lo stato della regione è connesso, puoi esaminare la connessione privata utilizzando l'ID progetto tenant per la regione corrispondente. I dettagli della connessione privata mostrano le route apprese tramite il peering di rete VPC. Le route esportate mostrano i cloud privati appresi dalla regione ed esportati tramite peering VPC.

Un cloud privato rappresenta un singolo vCenter e una singola installazione NSX-T con un massimo di 64 nodi. Puoi eseguire il deployment di più cloud privati e, se raggiungi il limite di 64 nodi per un cloud privato, puoi creare un altro cloud privato. Ciò significa che puoi gestire due cloud privati, due installazioni vCenter e due installazioni NSX-T.

A seconda del tuo caso d'uso, puoi eseguire il deployment di un singolo cloud privato o di più cloud privati senza raggiungere il limite di 64 nodi. Ad esempio, puoi eseguire il deployment di un cloud privato con carichi di lavoro di database e un cloud privato separato per un caso d'uso VDI oppure un cloud privato per i carichi di lavoro delle Americhe e un altro cloud privato per i carichi di lavoro EMEA. In alternativa, puoi separare i carichi di lavoro in più cluster all'interno dello stesso cloud privato, a seconda del caso d'uso.

Accesso privato Google

L'accesso privato Google ti consente di connetterti alle API e ai servizi Google senza assegnare indirizzi IP esterni alle VM VMware Engine. Dopo aver configurato l'accesso privato Google, il traffico viene instradato al gateway Internet e quindi al servizio richiesto senza uscire dalla rete Google.

Per ulteriori informazioni, consulta Accesso privato Google: un'occhiata più da vicino.

Flussi di traffico chiave

Questa sezione esamina alcuni flussi di traffico chiave e descrive l'architettura utilizzata per coprire tutti i diversi flussi di networking.

Di seguito sono riportati alcuni esempi di aspetti da considerare quando crei un progetto per VMware Engine.

Connettività utenti remoti e on-premise di VMware Engine

Di seguito sono riportate le opzioni che puoi utilizzare per accedere all'ambiente VMware Engine da un data center on-premise o da una località remota:

• Connettività utente remoto:
  • Gateway VPN (VPN point-to-site)
• Connettività on-premise:
  • Cloud VPN
    • Classica (deprecato, passaggio dalla VPN classica alla VPN ad alta disponibilità)
    • Alta disponibilità
  • Cloud Interconnect
    • Partner Interconnect
    • Dedicated Interconnect
  • VPN IPSec NSX-T
  • VPN di livello 2 NSX-T
  • VPN livello 2 HCX

Importante: tutte le opzioni VPN in VMware Engine (con NSX o HCX) comportano un ulteriore overhead di incapsulamento. Come best practice, assicurati che le reti e le interconnessioni VPC siano configurate per una MTU a 1500 byte in modo da ridurre al minimo la necessità di frammentazione.

I gateway VPN forniscono connettività sicura tra più siti, ad esempio on-premise, reti VPC e cloud privati. Queste connessioni VPN criptate attraversano Internet e vengono terminate in un gateway VPN. Quando crei più connessioni allo stesso gateway VPN, tutti i tunnel VPN condividono la larghezza di banda del gateway disponibile.

I gateway VPN point-to-site consentono agli utenti di connettersi da remoto a VMware Engine dai loro computer. Tieni presente che puoi creare un solo gateway VPN point-to-site per regione.

Il gateway VPN point-to-site consente connessioni TCP e UDP e puoi scegliere il protocollo da utilizzare per la connessione dal computer. Inoltre, la subnet client configurata viene utilizzata sia per i client TCP sia per quelli UDP e l'intervallo definito dal blocco CIDR è diviso in due subnet, una per i client TCP e una per i client UDP.

La VPN point-to-site invia il traffico criptato tra una rete della regione VMware Engine e un computer client. Puoi utilizzare la VPN point-to-site per accedere alla tua rete cloud privata, inclusi il tuo vCenter su cloud privato e le VM dei carichi di lavoro. Per informazioni sulla configurazione del gateway VPN point-to-site, consulta Configurazione di gateway VPN sulla rete VMware Engine.

Puoi anche utilizzare Cloud VPN per la connettività VPN site-to-site o Cloud Interconnect per stabilire connessioni tra la tua rete on-premise e il cloud privato VMware Engine. Esegui il provisioning di Cloud VPN e Cloud Interconnect nella tua rete VPC. Per ulteriori informazioni, consulta la documentazione su Cloud VPN e Cloud Interconnect.

Nota: Google sta ritirando alcune funzionalità della VPN classica. Per saperne di più, consulta la pagina relativa al ritiro parziale della VPN classica.

Le opzioni per la connettività VPN sono NSX-T IPsec VPN, NSX-T Layer 2 VPN e HCX Layer 2 VPN, ad esempio per configurare uno stretching di livello 2. Un caso d'uso della VPN IPsec di NSX-T è la crittografia end-to-end con terminazione VPN direttamente nel cloud privato di VMware Engine. Per ulteriori informazioni sulle funzionalità VPN NSX-T, consulta la documentazione di VMware sulla Virtual Private Network.

Ti consigliamo di configurare l'accesso privato ai servizi nella rete VPC in cui si trova il router Cloud o Cloud VPN (e dove esistono i collegamenti VLAN nel caso in cui venga utilizzato il protocollo BGP (Border Gateway Protocol); in caso contrario, è necessario configurare le route VPC. Se l'architettura contiene più connessioni in peering VPC, ricorda che il peering VPC non è transitivo.

Le route on-premise pubblicizzate su Interconnect o VPN vengono propagate automaticamente tramite l'accesso privato ai servizi se sono configurate l'importazione e l'esportazione delle route. Ciò richiede la modifica manuale delle route di importazione ed esportazione nella connessione in peering VPC.

Inoltre, tieni presente che le route apprese tramite l'accesso ai servizi privati non vengono automaticamente propagate ai sistemi on-premise, perché il peering di rete VPC non supporta il routing transitivo; le route importate da altre reti non vengono annunciate automaticamente dai router Cloud nella rete VPC. Tuttavia, puoi utilizzare annunci di intervalli IP personalizzati dai router Cloud nella tua rete VPC per condividere le route verso le destinazioni nella rete peer. Per i tunnel Cloud VPN che utilizzano il routing statico, devi configurare route statiche per gli intervalli di destinazione della rete peer nella rete on-premise.

Ingress in VMware Engine

Questa sezione descrive le seguenti opzioni per il traffico in entrata in VMware Engine:

• Ingress con il servizio IP pubblico di VMware Engine
• Ingress dalla rete VPC
• Ingress da un data center on-premise

L'opzione che selezioni dipende da dove vuoi eseguire la connessione in peering della tua infrastruttura Google Cloud con Internet. Il seguente diagramma mostra queste opzioni di traffico in entrata.

Nelle sezioni seguenti sono descritte in dettaglio ogni opzione.

Ingress con VMware Engine

Quando utilizzi il gateway Internet VMware Engine, è possibile creare ed eliminare gli indirizzi IP pubblici on demand per le risorse all'interno del cloud privato del portale VMware Engine. In questo scenario, ogni indirizzo IP pubblico corrisponde a un indirizzo IP del cloud privato configurato univoco.

Il traffico in entrata pubblico può essere fornito tramite il gateway IP pubblico, che è anche responsabile del NAT, in modo che gli utenti provenienti dalla rete Internet pubblica si connettano all'indirizzo IP pubblico di Google. L'indirizzo IP pubblico di Google viene convertito in un indirizzo IP privato di una macchina virtuale in VMware Engine (supportato dai segmenti NSX-T).

Importante: il servizio di indirizzi IP pubblici di VMware Engine non supporta l'utilizzo del tuo IP (BYOIP). Gli indirizzi IP pubblici vengono allocati da un intervallo gestito da Google in ogni regione. Se BYOIP è un requisito, valuta l'utilizzo della rete VPC consumer come punto di entrata.

Quando crei regole firewall per consentire le connessioni in entrata dall'esterno a un IP pubblico esposto, le regole firewall vengono applicate a un gateway IP pubblico e deve essere eseguito il provisioning di queste regole sul portale VMware Engine.

In genere, il router logico livello 0 viene utilizzato per il routing da nord a sud, ad esempio una macchina virtuale che si connette a internet. Per il routing da est a ovest viene utilizzato un router logico di livello 1 ed è possibile configurare più subnet per il livello 1.

Un indirizzo IP pubblico consente alle risorse Internet di comunicare in entrata con le risorse cloud private a un indirizzo IP privato. L'indirizzo IP privato è una macchina virtuale o un bilanciatore del carico software sul tuo vCenter cloud privato. L'indirizzo IP pubblico ti consente di esporre su internet i servizi in esecuzione sul tuo cloud privato.

Una risorsa associata a un indirizzo IP pubblico utilizza sempre l'indirizzo IP pubblico per l'accesso a internet. Per impostazione predefinita, solo l'accesso a Internet in uscita è consentito su un indirizzo IP pubblico, mentre il traffico in entrata sull'indirizzo IP pubblico viene negato. Per consentire il traffico in entrata, crea una regola firewall per l'indirizzo IP pubblico con la porta specifica.

Gli utenti della tua organizzazione possono esporre e allocare IP pubblici a nodi specifici nel proprio cloud privato, ad esempio i carichi di lavoro delle VM. L'indirizzo IP pubblico può essere assegnato a un solo indirizzo IP privato. L'indirizzo IP pubblico è dedicato a quell'indirizzo IP privato finché non annulli l'assegnazione. Ti consigliamo di non esporre gli host ESXi o vCenter.

Se vuoi allocare un IP pubblico, devi fornire un nome, una località o una regione, nonché l'indirizzo locale associato.

Traffico in entrata utilizzando la rete VPC

Puoi fornire il traffico in entrata in VMware Engine tramite la rete VPC utilizzando Cloud Load Balancing. Quando selezioni il bilanciatore del carico che preferisci in base alle funzionalità richieste, puoi creare un gruppo di istanze gestite o un gruppo di istanze non gestite come backend per il bilanciatore del carico in modo da indirizzare il traffico tramite proxy sulla connessione in peering VPC. In questo scenario, puoi anche utilizzare un'appliance di rete virtuale di terze parti da Google Cloud Marketplace.

Puoi combinare Cloud Load Balancing con la funzionalità Bring your own IP (BYOIP) se vuoi utilizzare il tuo spazio IP pubblico per Google, nonché con Google Cloud Armor per proteggere le tue applicazioni e i tuoi siti web dagli attacchi DDoS (Distributed Denial of Service) e web come SQL injection o cross-site scripting.

Traffico in entrata utilizzando la rete on-premise

Per fornire il traffico in entrata on-premise, ti consigliamo di utilizzare Cloud Interconnect. Per il proof of concept o nel caso in cui tu abbia una velocità effettiva bassa e nessun requisito di latenza, puoi utilizzare Cloud VPN.

Importante: le estensioni HCX di livello 2 su Cloud VPN non sono ufficialmente supportate.

In uscita da VMware Engine

Sono disponibili più opzioni per il traffico in uscita da VMware Engine:

• In uscita attraverso il gateway Internet VMware Engine
• In uscita attraverso la rete VPC
• In uscita attraverso un data center on-premise

Nella seguente architettura puoi vedere queste opzioni per un flusso in uscita dal punto di vista di VMware Engine.

Traffico in uscita pubblico tramite VMware Engine

Puoi configurare l'accesso a internet e i servizi IP pubblici per i tuoi carichi di lavoro separatamente per ogni regione. Puoi indirizzare il traffico legato a internet dai tuoi carichi di lavoro VMware utilizzando il perimetro internet di Google Cloud o una connessione on-premise.

Il traffico da una macchina virtuale ospitata in un cloud privato VMware Engine destinato al traffico Internet pubblico in uscita attraverso il gateway di livello 0. Il gateway di livello 0 inoltra il traffico al gateway Internet. Il gateway Internet esegue la traduzione degli indirizzi della porta di origine (PAT). Il servizio internet è a livello di regione, il che significa che è abilitato per ogni regione separatamente.

Nota: attualmente Google Cloud non supporta ICMP per il bilanciatore del carico interno. Se vuoi eseguire un ping per verificare la connettività, usa tcp ping.

Traffico in uscita pubblico tramite la rete VPC

In alternativa, dal portale di servizio VMware Engine, puoi disabilitare i servizi Internet e IP pubblici e fornire il traffico in uscita pubblico dalla rete VPC. In questo caso, l'accesso a Internet avviene tramite la rete VPC, se hai pubblicizzato una route 0.0.0.0/0 predefinita. Se vuoi utilizzare questo flusso di pacchetti, disabilita l'accesso a internet per la regione VMware Engine e inserisci una route 0.0.0.0/0 predefinita.

Devi inoltre rimuovere tutti gli indirizzi IP pubblici allocati e i gateway VPN point-to-site prima di poter inviare il traffico in uscita attraverso la rete VPC.

La route predefinita deve essere visibile nella rete VPC e verrà poi propagata automaticamente a VMware Engine. Un prerequisito è abilitare i Controlli di servizio VPC sulla connessione in peering VPC tra la tua rete VPC e VMware Engine.

Per eseguire Network Address Translation (NAT), puoi eseguire il deployment di un'istanza Compute Engine o avere una route predefinita 0.0.0.0/0 che punta a un bilanciatore del carico interno abbinato a un cluster dell'appliance di rete virtuale centralizzata di terze parti (disponibile su Cloud Marketplace) ed eseguire NAT di origine nell'istanza verso il traffico in uscita dalla tua rete VPC verso la rete internet pubblica. Per ulteriori informazioni, consulta Come utilizzare le route nella rete VPC.

Traffico in uscita pubblico mediante un data center on-premise

Puoi utilizzare il traffico in uscita attraverso il data center on-premise se disattivi i servizi Internet e IP pubblici e fornisci il traffico pubblico in uscita dall'ambiente on-premise. In questo caso, l'accesso a Internet passa attraverso la rete VPC prima di raggiungere il data center on-premise mediante Cloud VPN o Cloud Interconnect.

Per implementare il traffico in uscita pubblico tramite il tuo data center on-premise, pubblicizzi una route 0.0.0.0/0 predefinita e poi abiliti Controlli di servizio VPC sulla connessione in peering in modo che la route predefinita venga importata correttamente, come descritto qui. Per ulteriori informazioni sui Controlli di servizio VPC, consulta la documentazione sui Controlli di servizio VPC.

Se i Controlli di servizio VPC sono disabilitati nella connessione in peering VPC, viene disabilitato anche l'accesso a internet tramite una connessione on-premise, anche se una route predefinita (0.0.0.0/0) viene pubblicizzata e propagata nella connessione in peering VPC.

Panoramica del servizio: da cloud privato a cloud privato

I cloud privati vengono gestiti tramite il portale di servizio VMware Engine. I cloud privati hanno un proprio server vCenter all'interno del proprio dominio di gestione. Lo stack VMware viene eseguito su nodi hardware bare metal dedicati e isolati nelle località Google Cloud. L'ambiente cloud privato è progettato per eliminare i single point of failure.

Il seguente diagramma mostra due percorsi di rete per la comunicazione tra cloud privati in VMware Engine. Il percorso dipende dal fatto che i cloud privati si trovino nella stessa regione o in regioni diverse:

1. La comunicazione tra due cloud privati nella stessa regione all'interno del servizio VMware Engine avviene tramite connettività diretta. Puoi eseguire il deployment di più cloud privati nella stessa regione, in modo che la comunicazione tra questi cloud privati avvenga localmente.
2. Se i cloud privati si trovano in regioni diverse, la connettività passa attraverso la rete VPC del producer di servizi, che è gestita e di proprietà di Google. Questo avviene a condizione che la modalità di routing sia impostata su globale.

Panoramica del servizio: da cloud privato a VPC

Questa sezione esamina la connettività tra la rete VPC e il cloud privato. La rete VPC utilizza il modello di accesso privato ai servizi per stabilire una connessione in peering con la rete VPC del producer di servizi, quindi estende la connettività alla regione VMware Engine. Il routing globale è abilitato sulla rete VPC del producer di servizi e tutte le reti che crei nel portale di servizio VMware Engine vengono annunciate automaticamente dal router di livello 0 in NSX-T. Assicurati che nella connessione in peering sia abilitato il flag di importazione ed esportazione per le route di scambio e che la connettività tra VMware Engine e il tuo VPC.

Il seguente diagramma mostra il flusso di traffico in questo caso.

Panoramica del servizio: da cloud privato a VPC condiviso

Quando utilizzi una rete VPC condiviso, la connettività è simile all'esempio precedente di connessione di un cloud privato a una rete VPC. La differenza è che, quando connetti un cloud privato alla rete VPC condiviso, i carichi di lavoro risiedono nel progetto di servizio e utilizzano lo spazio di indirizzi IP nella rete VPC condiviso del progetto host. Per questo motivo, devi configurare l'accesso privato ai servizi nel progetto host in cui sono configurate la rete VPC condiviso e l'interconnessione o la VPN.

Ad esempio, se vuoi includere il cloud privato, IAM e fatturazione in un progetto di servizio, assicurati che la connessione di accesso privato ai servizi sia stabilita nella rete VPC condiviso del progetto host.

Panoramica del servizio: da cloud privato a on-premise

Nel caso del cloud privato e on-premise, hai una rete VPC nel progetto e nell'organizzazione e la connettività è tra il cloud privato e il data center on-premise.

Come accennato in precedenza, quando configuri VMware Engine, devi allocare una subnet (e idealmente anche le subnet per VMware Engine per evitare conflitti futuri) per la connessione di accesso ai servizi privati. Durante l'allocazione di questa subnet, crei una rete VPC del producer di servizi che la connette alla regione VMware Engine in cui si trova il cloud privato.

Dopo la creazione e il provisioning della connessione in peering VPC, la rete VPC del producer di servizi viene connessa alla rete VPC. In questo modo tutte le subnet e gli indirizzi IP all'interno della tua rete VPC sono raggiungibili dal cloud privato. Assicurati di abilitare l'importazione e l'esportazione di route nella connessione in peering VPC quando configuri l'accesso privato ai servizi.

Il seguente diagramma mostra la connettività end-to-end tra un cloud privato in VMware Engine e un data center on-premise.

Accesso privato Google: un'occhiata più da vicino

Come accennato in precedenza, puoi utilizzare l'accesso privato Google per connetterti alle API e ai servizi Google senza fornire indirizzi IP esterni alle risorse Google Cloud, in modo che il servizio VMware Engine possa sfruttare questo vantaggio e utilizzare il gateway Internet per raggiungere le API di Google.

Le istanze VM che hanno solo indirizzi IP interni possono sfruttare l'accesso privato Google per raggiungere gli indirizzi IP esterni delle API e dei servizi Google. Quando l'accesso privato Google è configurato, il traffico viene instradato al gateway Internet e quindi al servizio richiesto.

Per abilitare l'accesso privato Google per VMware Engine, devi configurare il server DNS nel tuo ambiente VMware Engine in modo che utilizzi l'indirizzo IP virtuale privato. Per ulteriori informazioni, consulta Accesso privato Google per gli host on-premise e Configurazione dell'accesso privato Google per gli host on-premise. Il dominio private.googleapis.com utilizza 199.36.153.8/30.

Per gestire la risoluzione DNS, puoi utilizzare il servizio DNS fornito in NSX-T per inoltrare le richieste a un server DNS specificato. Il server DNS può essere una VM in VMware Engine, Cloud DNS o un server DNS on-premise. A seconda della modalità di accesso a Internet, come descritto in una sezione precedente, verrà utilizzata una di queste opzioni.

L'accesso privato Google supporta la maggior parte delle API e dei servizi Google, come Cloud Storage, Cloud Spanner e BigQuery. L'accesso privato Google non supporta App Engine, Memorystore o Filestore. Per ulteriori informazioni sulle opzioni di accesso privato, vedi Opzioni di accesso privato per i servizi.

Di seguito sono riportati alcuni esempi di come utilizzare VMware Engine con i servizi Google Cloud:

• Accedi a Cloud Storage dalle VM VMware per esportare i dati o come target di archiviazione esteso.
• Monitorare tutte le applicazioni pubbliche, private e ibride con Cloud Monitoring.
• Importa i dati dai database in BigQuery per l'analisi.
• Esegui il deployment di Anthos per deployment di applicazioni containerizzate e private ad alte prestazioni.

Il seguente diagramma mostra due percorsi di rete per la comunicazione con le API e i servizi di Google. La configurazione dell'accesso privato Google dipende dall'accesso a internet abilitato per VMware Engine:

1. Se l'accesso a Internet viene fornito tramite VMware Engine ed è abilitato per la regione, l'accesso privato Google e l'accesso a internet utilizzano il gateway Internet.
2. Se fornisci l'accesso a internet (promuovendo una route 0.0.0.0/0) dall'ambiente on-premise o tramite la rete VPC, la comunicazione utilizza il gateway internet di rete VPC del producer di servizi. L'accesso tramite il servizio internet VMware Engine viene ignorato.

Opzione 1: accesso privato Google con accesso a Internet fornito da VMware Engine

Se fornisci l'accesso a internet tramite VMware Engine per una regione, l'accesso privato Google e Internet utilizzano il gateway Internet ed esegue il PAT. In questo caso, non è necessaria alcuna configurazione aggiuntiva, fatta eccezione per la risoluzione DNS per l'accesso privato Google.

Opzione 2: accesso privato Google con accesso a internet fornito da VPC on-premise o del cliente

Se fornisci l'accesso a Internet on-premise o tramite la rete VPC, devi configurare il servizio VMware Engine per instradare i pacchetti alle API di Google tramite il gateway Internet nella rete VPC tenant dell'organizzazione. Devi configurare il servizio VMware Engine in modo che instrada i pacchetti per l'altro traffico attraverso la rete VPC in modo da raggiungere on-premise tramite VPN o Interconnect oppure attraverso la rete VPC.

Per tutto il traffico, disabilita l'accesso a internet e i servizi IP pubblici per la regione VMware Engine e inserisci una route 0.0.0.0/0 predefinita tramite on-premise.

Se fornisci l'accesso a Internet on-premise o tramite la tua rete VPC, rimuovi gli eventuali indirizzi IP pubblici allocati e gateway VPN point-to-site prima di disabilitare il servizio IP pubblico. Assicurati che la route sia visibile nella rete VPC e che venga esportata nella rete VPC tenant.

Inoltre, devi abilitare i Controlli di servizio VPC sulla connessione in peering VPC tra la tua rete VPC e VMware Engine.

Infine, l'accesso alle API di Google utilizza l'indirizzo IP virtuale limitato, pertanto il DNS deve essere configurato di conseguenza con i record CNAME e A richiesti. L'accesso alle API di Google avviene tramite l'organizzazione Google, non tramite la tua rete VPC.

Da cloud privato a Managed Partner Services

I servizi per partner gestiti (MPS) ti consentono di fornire offerte Software as a Service (SaaS) mission-critical ai clienti di Google Cloud da hardware e software ospitati in una struttura di colocation MPS.

Per il flusso di traffico tra un cloud privato e MPS, VMware Engine utilizza una connettività multi-VPC. Questa funzionalità consente di stabilire la connettività non solo alle reti VPC consumer aggiuntive, ma anche a MPS di Google. Il seguente diagramma è una versione semplificata della connettività tra un cloud privato e MPS, nonché altre reti VPC consumer.

Risorse aggiuntive: VMware

Per ulteriori informazioni sullo stack VMware, consulta Versioni dei componenti VMware e NSX 3.0 Design Guide.