Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento

Last reviewed 2023-11-13 UTC

Questo documento fa parte di una serie che descrive le architetture di networking e sicurezza per le aziende che stanno eseguendo la migrazione dei carichi di lavoro dei data center a Google Cloud.

La serie è costituita dai seguenti documenti:

Questo documento illustra il networking per uno scenario in cui i carichi di lavoro vengono eseguiti in più luoghi, ad esempio on-premise e nel cloud, o in più ambienti cloud.

Architettura lift and shift

Il primo scenario di accesso al carico di lavoro ibrido è un'architettura lift and shift.

Creazione di una connettività privata in corso...

Puoi stabilire la connettività alle reti on-premise utilizzando Dedicated Interconnect o Partner Interconnect. La topologia illustrata nella Figura 1 mostra come utilizzare quattro connessioni Interconnect in due diverse aree metropolitane e in diversi domini di disponibilità perimetrale per ottenere una disponibilità del 99,99% utilizzando Dedicated Interconnect. Per ulteriori informazioni e suggerimenti dettagliati, consulta Connettività ibrida tra un ambiente on-premise e Google Cloud nel progetto delle basi aziendali.

Configurazione di connessioni Cloud Interconnect ridondanti per una disponibilità del 99,99%.

Figura 1. e configurazione di connessioni Cloud Interconnect ridondanti per una disponibilità del 99,99%.

Network Connectivity Center consente di utilizzare la rete di Google per il trasferimento di dati tra più siti on-premise o con hosting su cloud. Questo approccio ti consente di sfruttare la copertura e l'affidabilità della rete Google quando devi trasferire i dati. Puoi utilizzare le appliance router Cloud VPN, Cloud Interconnect e SD-WAN esistenti come spoke di Network Connectivity Center per supportare il trasferimento di dati tra reti on-premise e filiali, come mostrato nella Figura 2.

Configurazione di Network Connectivity Center che connette diverse reti aziendali on-premise al di fuori di Google Cloud utilizzando la rete backbone di Google.

Figura 2. Configurazione di Network Connectivity Center che collega diverse reti aziendali on-premise e altre reti cloud al di fuori di Google Cloud utilizzando la rete backbone di Google.

Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta Considerazioni nella documentazione di Network Connectivity Center.

Appliance SD-WAN

Network Connectivity Center consente di utilizzare un'appliance virtuale di rete di terze parti come spoke di Network Connectivity Center per stabilire la connettività tra un sito esterno e le risorse di rete VPC. Un'appliance router potrebbe essere un router SD-WAN di terze parti supportato da uno dei nostri partner o un'altra appliance virtuale che consente di scambiare le route con l'istanza del router Cloud. Queste soluzioni basate su appliance si aggiungono alle attuali opzioni di connettività site-to-cloud disponibili con Cloud VPN e Cloud Interconnect come spoke. La figura 3 mostra una topologia che utilizza appliance SD-WAN.

Configurazione di Network Connectivity Center utilizzando l'appliance router per integrare l'implementazione SD-WAN con la rete Google.

Figura 3. Configurazione del Network Connectivity Center utilizzando l'appliance router per integrare l'implementazione SD-WAN con la rete Google.

Puoi utilizzare appliance di terze parti per eseguire funzioni di sicurezza. Le funzionalità di sicurezza dell'appliance possono essere integrate nell'appliance router come mostrato nella figura 3. È inoltre un modello comune l'utilizzo di un'appliance virtuale di networking, in cui il traffico proveniente da reti on-premise arriva a una rete VPC di transito e l'appliance stabilisce la connettività con la rete VPC del carico di lavoro, come illustrato nella Figura 4.

Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta Considerazioni nella documentazione di Network Connectivity Center.

Architettura dei servizi ibridi

Come nel caso d'uso intra-cloud discusso in Networking per l'accesso intra-cloud sicuro: architetture di riferimento, il Network Connectivity Center consente la connettività dalle tue filiali e dalle reti on-premise a Google Cloud. Private Service Connect fornisce l'accesso privato ai servizi gestiti da Google o consente di utilizzare altri servizi creati e di cui è stato eseguito il deployment nel cloud.

Puoi implementare la sicurezza di rete anche utilizzando una combinazione di Controlli di servizio VPC, firewall Google Cloud e appliance virtuali di rete, come mostrato nella Figura 4.

Reti con un'architettura che utilizza sia un pattern lift and shift sia un modello di progettazione di servizi ibridi, progettato per fornire un piano dati sicuro.

Figura 4. Reti con un'architettura che utilizza sia un pattern lift and shift sia un modello di progettazione di servizi ibridi, progettato per fornire un piano dati sicuro.

Architettura distribuita Zero Trust

In un ambiente ibrido, i microservizi vengono eseguiti in mesh di servizi di cui viene eseguito il deployment su diversi provider cloud e ambienti on-premise. Puoi proteggere la comunicazione tra i microservizi utilizzando mTLS e i criteri di autorizzazione. È prassi comune per le aziende creare mesh di servizi nel cloud ed estenderli agli ambienti on-premise. La figura 5 mostra un esempio in cui i servizi di cui viene eseguito il deployment on-premise accedono ai servizi nel cloud. La crittografia mTLS end-to-end tra i servizi viene attivata utilizzando il gateway est-ovest e il routing basato su SNI. Cloud Service Mesh ti aiuta a proteggere le comunicazioni tra servizi, consentendoti di configurare criteri di autorizzazione per i servizi ed eseguire il deployment di certificati e chiavi forniti da un'autorità di certificazione gestita.

Gli ambienti ibridi in genere presentano più deployment mesh, ad esempio più cluster GKE. Un componente importante di questo flusso è il routing SNI, utilizzato a livello del gateway GKE est-ovest per ogni cluster. Questa configurazione consente il routing mTLS diretto al carico di lavoro da parte del gateway, preservando la connettività mTLS end-to-end.

Mesh di servizi Zero Trust di cui è stato eseguito il deployment in un ambiente on-premise e in Google Cloud.

Figura 5. Mesh di servizi Zero Trust con deployment in un ambiente on-premise e in Google Cloud.

Le aziende possono utilizzare Cloud Service Mesh per eseguire il deployment in più cloud. Per affrontare le problematiche legate alla gestione di identità e certificati tra cloud provider, Cloud Service Mesh fornisce identità per i carichi di lavoro e un'autorità di certificazione (CA) nel cluster intermedia utilizzando CA Service (CA Service). La CA intermedia può essere concatenata a una CA esterna o può essere ospitata in Google. Puoi personalizzare gli attributi CA, come la regione e l'algoritmo di firma, utilizzando sia gli HSM di proprietà aziendale che Cloud HSM.

Workload Identity consente di assegnare identità e autorizzazioni distinte e granulari per ciascun microservizio nel cluster. Cloud Service Mesh gestisce il processo di emissione dei certificati e di rotazione automatica di chiavi e certificati, senza interrompere le comunicazioni. Fornisce inoltre un'unica radice di attendibilità tra i cluster GKE.

La figura 6 mostra un'architettura che utilizza Cloud Service Mesh per gestire identità e autorizzazione.

I servizi nel mesh possono accedere ai servizi Google Cloud utilizzando la federazione delle identità per i carichi di lavoro. Questa funzionalità consente ai servizi di agire con l'autorità di un account di servizio Google quando richiamano le API Google Cloud. La federazione delle identità per i carichi di lavoro consente inoltre al mesh di servizi installato in altri cloud provider di accedere alle API Google Cloud.

Mesh di servizi Zero Trust di cui è stato eseguito il deployment nei cloud.

Figura 6. Mesh di servizi Zero Trust di cui è stato eseguito il deployment nei cloud.

Puoi utilizzare Cloud Service Mesh per instradare il traffico dal mesh agli ambienti on-premise o a qualsiasi altro cloud.

Ad esempio, puoi creare servizi in Cloud Service Mesh chiamati on-prem-service e other-cloud-service e aggiungere gruppi di endpoint di rete a connettività ibrida (NEG) che hanno endpoint 10.1.0.1:80 e 10.2.0.1:80. Cloud Service Mesh invia quindi il traffico ai propri client, ovvero proxy sidecar mesh in esecuzione insieme alle tue applicazioni. Di conseguenza, quando l'applicazione invia una richiesta al servizio on-prem-service, il client Cloud Service Mesh ispeziona la richiesta e la indirizza all'endpoint 10.0.0.1:80. La Figura 7 illustra questa configurazione.

Traffico indirizzato da un mesh di servizi mediante Cloud Service Mesh.

Figura 7. Traffico indirizzato da un mesh di servizi mediante Cloud Service Mesh.

Puoi anche incorporare funzionalità avanzate come l'indirizzamento del traffico basato sul peso, come mostrato nella Figura 8. Questa funzionalità consente di soddisfare esigenze aziendali critiche come la migrazione al cloud. Cloud Service Mesh è un piano di controllo versatile e gestito a livello globale per i tuoi mesh di servizi.

Traffico ponderato indirizzato tramite Cloud Service Mesh.

Figura 8. Traffico ponderato indirizzato tramite Cloud Service Mesh.

Passaggi successivi