Questo documento fa parte di una serie che descrive le architetture di rete e di sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro dei data center a Google Cloud.
La serie è composta dai seguenti documenti:
- Progettare reti per la migrazione dei carichi di lavoro aziendali: approcci architettonici
- Networking per l'accesso sicuro all'interno del cloud: architetture di riferimento
- Networking per l'implementazione di applicazioni rivolte a internet: architetture di riferimento
- Networking per i carichi di lavoro ibridi e multi-cloud: architetture di riferimento (questo documento)
Questo documento illustra la rete per uno scenario in cui i carichi di lavoro vengono eseguiti in più di un luogo, ad esempio on-premise e nel cloud o in più ambienti cloud.
Architettura lift and shift
Il primo scenario di accesso ai carichi di lavoro ibridi è un'architettura di tipo lift-and-shift.
Stabilire la connettività privata
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 Dedicated Interconnect in due metropoli diverse e in domini di disponibilità perimetrale diversi per ottenere una disponibilità del 99,99%. Puoi anche ottenere una disponibilità del 99,99% utilizzando Partner Interconnect.
Per la connettività tra le tue Google Cloud reti e le reti ospitate da un altro provider cloud, utilizza Cross-Cloud Interconnect.
Per ulteriori informazioni e consigli dettagliati, consulta Connettività ibrida tra un ambiente on-premise e Google Cloud nel progetto di base dell'azienda.
Figura 1. Configurazione di connessioni Dedicated Interconnect ridondanti per una disponibilità del 99,99%.
Network Connectivity Center ti consente di utilizzare la rete di Google per il trasferimento di dati tra più siti on-premise o ospitati su cloud. Questo approccio ti consente di sfruttare la copertura e l'affidabilità della rete di Google quando devi spostare i dati. Puoi utilizzare le appliance router SD-WAN, Cloud VPN e Cloud Interconnect esistenti e le reti VPC come spoke di Network Connectivity Center per supportare il trasferimento di dati tra le reti on-premise, i siti delle filiali, altri provider cloud e le reti VPCGoogle Cloud come mostrato nella figura 2.
Figura 2. Configurazione di Network Connectivity Center che connette diverse reti cloud e aziendali on-premise esterne a Google Google Cloud utilizzando la rete di 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 ti consente di utilizzare un'appliance router di terze parti come uno spoke di Network Connectivity Center per stabilire la connettività tra un sito esterno e le risorse di rete VPC. Un'appliance router può essere un router SD-WAN di terze parti supportato da uno dei nostri partner o un'altra appliance virtuale che ti consente di scambiare route con l' istanza router Cloud. Queste soluzioni basate su appliance si aggiungono alle opzioni di connettività site-to-cloud attualmente disponibili con Cloud VPN e Cloud Interconnect come spoke. La Figura 3 mostra una topologia che utilizza appliance SD-WAN.
Figura 3. Configurazione di Network Connectivity Center utilizzando l'appliance router per integrare l'implementazione SD-WAN con la rete di 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. È anche uno schema comune utilizzare un'appliance virtuale di rete, dove il traffico on-premise arriva in una rete VPC di transito, e l'appliance stabilisce la connettività con la rete VPC del carico di lavoro, come mostrato nella figura 4.
Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta Considerazioni nella documentazione di Network Connectivity Center.
Architettura di servizi ibridi
Come nel caso d'uso intra-cloud descritto in Networking per l'accesso intra-cloud sicuro: architetture di riferimento, Network Connectivity Center consente la connettività dai siti delle filiali e dalle reti on-premise a Google Cloud. Private Service Connect fornisce accesso privato ai servizi gestiti da Google o ti consente di utilizzare altri servizi creati e di cui è stato eseguito il deployment nel cloud.
Puoi anche implementare la sicurezza di rete utilizzando una combinazione di VPC Service Controls, Google Cloud firewall e appliance virtuali di rete, come mostrato nella figura 4.
Figura 4. Reti con un'architettura che utilizza sia un pattern di lift-and-shift sia un pattern 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 che vengono implementati su diversi provider cloud ed ambienti on-premise. Puoi contribuire a proteggere la comunicazione tra i microservizi utilizzando mTLS (mutual Transport Layer Security) e i criteri di autorizzazione. È prassi comune per le aziende creare mesh di servizi nel cloud ed estenderli on-premise. La Figura 5 mostra un esempio in cui i servizi di cui è stato eseguito il deployment on-premise accedono ai servizi nel cloud. Il protocollo mTLS end-to-end tra i servizi è abilitato utilizzando il gateway east-west e il routing basato sull'indicazione nome server (SNI). Cloud Service Mesh ti aiuta a proteggere le comunicazioni tra servizi, consentendoti di configurare i 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ù implementazioni di mesh, ad esempio più cluster GKE. Un componente importante di questo flusso è il routing SNI, che viene utilizzato nel gateway est-ovest GKE per ogni cluster. Questa configurazione consente il routing mTLS diretto al workload da parte del gateway, preservando al contempo la connettività mTLS end-to-end.
Figura 5. Mesh di servizi Zero Trust di cui è stato eseguito il deployment in un ambiente on-premise e Google Cloud.
Le aziende possono utilizzare Cloud Service Mesh per eseguire il deployment su più cloud. Per risolvere le difficoltà di gestione dell'identità e dei certificati tra i fornitori di servizi cloud, Cloud Service Mesh fornisce l'identità del workload e un'autorità di certificazione (CA) intermedia all'interno del cluster utilizzando CA Service. La CA intermedia può essere collegata a una CA esterna o essere ospitata in Google. Puoi personalizzare gli attributi della CA come la regione e l'algoritmo di firma utilizzando sia gli HSM di proprietà dell'azienda sia Cloud HSM.
Workload Identity ti consente di assegnare identità e autorizzazioni distinte e granulari per ogni microservizio nel tuo cluster. Cloud Service Mesh gestisce la procedura di emissione dei certificati e la rotazione automatica di chiavi e certificati, senza interrompere le comunicazioni. Fornisce inoltre un'unica radice di attendibilità per tutti i cluster GKE.
La Figura 6 mostra un'architettura che utilizza Cloud Service Mesh per gestire l'identità e l'autorizzazione.
I servizi nel mesh possono accedere ai Google Cloud servizi 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 invocano le API. Google Cloud La federazione delle identità per i carichi di lavoro consente inoltre al service mesh installato in altri provider cloud di accedere alle API Google Cloud.
Figura 6. Mesh di servizi zero trust di cui è stato eseguito il deployment in più cloud.
Puoi utilizzare Cloud Service Mesh per instradare il traffico dal mesh alle risorse on-premise o a qualsiasi altro cloud.
Ad esempio, puoi creare servizi in Cloud Service Mesh denominati on-prem-service
e other-cloud-service
e aggiungere gruppi di endpoint di rete (NEG) con connettività ibrida con gli 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 che vengono eseguiti insieme alle tue applicazioni. Pertanto, quando la tua applicazione invia una richiesta al servizio on-prem-service
, il client Cloud Service Mesh la ispeziona e la indirizza all'endpoint 10.2.0.1:80
. La Figura 7 illustra questa configurazione.
Figura 7. Traffico indirizzato da un service mesh utilizzando Cloud Service Mesh.
Puoi anche incorporare funzionalità avanzate come la gestione del traffico basata sul peso, come mostrato nella figura 8. Questa funzionalità ti consente di soddisfare le esigenze aziendali critiche come la migrazione al cloud. Cloud Service Mesh funge da piano di controllo versatile e gestito a livello globale per i tuoi mesh di servizi.
Figura 8. Traffico ponderato indirizzato utilizzando Cloud Service Mesh.
Passaggi successivi
- Networking per l'accesso sicuro all'interno del cloud: architetture di riferimento.
- Networking per l'implementazione di applicazioni rivolte a internet: architetture di riferimento
- La migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei carichi di lavoro in Google Cloud.
- La pagina Design della zona di destinazione in Google Cloud fornisce indicazioni per creare una rete della zona di destinazione.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.