Questo documento fa parte di una serie che descrive le architetture di rete e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro del data center a Google Cloud.
La serie è costituita dai seguenti documenti:
- Progettare reti per la migrazione dei carichi di lavoro aziendali: approcci architetturali
- Networking per l'accesso sicuro intra-cloud: architetture di riferimento
- Networking per la distribuzione di applicazioni esposte a internet: architetture di riferimento
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento (questo documento)
Questo documento descrive il networking 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 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 metro diversi e in domini di disponibilità edge 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 reti Google Cloud e le tue 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 della piattaforma aziendale.
Figura 1. Configurazione di connessioni Dedicated Interconnect ridondanti per una disponibilità del 99,99%.
Network Connectivity Center consente di utilizzare la rete Google per il trasferimento di dati tra più siti on-premise o ospitati sul cloud. Questo approccio ti consente di sfruttare la copertura e l'affidabilità della rete di Google quando devi spostare i dati. Puoi utilizzare le reti VPC, i router SD-WAN e le appliance Cloud VPN e Cloud Interconnect esistenti come spoke di Network Connectivity Center per supportare il trasferimento di dati tra le reti on-premise, le sedi delle filiali, altri provider cloud e le reti VPCGoogle Cloud come mostrato nella figura 2.
Figura 2. Configurazione di Network Connectivity Center che collega diverse reti aziendali on-premise e altre reti cloud esterne a Google Cloud utilizzando la rete di backbone di Google.
Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta la sezione Considerazioni nella documentazione di Network Connectivity Center.
Appliance SD-WAN
Network Connectivity Center ti consente di utilizzare un'appliance router 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 ti consente di scambiare route con l'istanza router Cloud. Queste soluzioni basate su appliance si aggiungono alle attuali opzioni di connettività da sito a cloud 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 un pattern comune utilizzare un'appliance virtuale di rete, in cui il traffico on-premise arriva in una rete VPC di transito e l'appliance stabilisce la connettività con la rete VPC del workload, come mostrato nella figura 4.
Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta la sezione Considerazioni nella documentazione di Network Connectivity Center.
Architettura dei 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à dalle tue sedi filiali e dalle reti on-premise a Google Cloud. Private Service Connect fornisce l'accesso privato ai servizi gestiti da Google o ti consente di utilizzare altri servizi creati e implementati nel cloud.
Puoi anche implementare la sicurezza di rete utilizzando una combinazione di Controlli di servizio VPCs, Google Cloud firewall e appliance virtuali di rete, come mostrato nella Figura 4.
Figura 4. Reti con un'architettura che utilizza sia un pattern 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 distribuite su diversi provider di servizi cloud e in ambienti on-premise. Puoi contribuire a proteggere la comunicazione tra i microservizi utilizzando mTLS (mutual Transport Layer Security) e criteri di autorizzazione. È una pratica comune per le aziende creare service mesh nel cloud ed estenderli all'ambiente 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. mTLS end-to-end tra i servizi è abilitato utilizzando il gateway east-west e il routing basato su SNI (Server Name Indication). Cloud Service Mesh ti aiuta a proteggere le comunicazioni tra servizi, consentendoti di configurare criteri di autorizzazione per i servizi e di distribuire certificati e chiavi forniti da un'autorità di certificazione gestita.
Gli ambienti ibridi in genere presentano più deployment di mesh, ad esempio più cluster GKE. Un componente importante di questo flusso è il routing SNI, che viene utilizzato nel gateway east-west di GKE per ogni cluster. Questa configurazione consente il routing mTLS diretto al workload da parte del gateway, mantenendo 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 sfide nella gestione di identità e certificati tra i provider di servizi cloud, Cloud Service Mesh fornisce workload identity e un'autorità di certificazione (CA) intermedia nel cluster, utilizzando CA Service. L'autorità di certificazione intermedia può essere concatenata a un'autorità di certificazione esterna o può essere ospitata in Google. Puoi personalizzare gli attributi CA, come la regione e l'algoritmo di firma, utilizzando sia HSM di proprietà dell'azienda sia Cloud HSM.
Workload Identity ti consente di assegnare l'autorizzazione e identità distinte e granulari per ogni microservizio nel tuo cluster. Cloud Service Mesh gestisce il processo di emissione dei certificati e di rotazione automatica delle chiavi e dei certificati, senza interrompere le comunicazioni. Fornisce inoltre una singola radice di attendibilità tra 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 servizi Google Cloud utilizzando la federazione delle identità per i workload. 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 alla mesh di servizi installata in altri provider di servizi cloud di accedere alle API Google Cloud.
Figura 6. Mesh di servizi zero-trust implementato su più cloud.
Puoi utilizzare Cloud Service Mesh per instradare il traffico dalla mesh all'ambiente 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 (NEG) con connettività ibrida
che hanno endpoint 10.1.0.1:80 e 10.2.0.1:80.
Cloud Service Mesh invia quindi il traffico ai suoi client, che sono 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
ispeziona la richiesta e la indirizza all'endpoint 10.2.0.1:80. La figura 7
illustra questa configurazione.
Figura 7. Traffico indirizzato da un mesh di servizi utilizzando Cloud Service Mesh.
Puoi anche incorporare funzionalità avanzate come la distribuzione del traffico in base al peso, come mostrato nella figura 8. Questa funzionalità ti consente di attivare esigenze aziendali critiche come la migrazione al cloud. Cloud Service Mesh funge da control plane versatile e gestito a livello globale per i tuoi service mesh.
Figura 8. Traffico ponderato indirizzato utilizzando Cloud Service Mesh.
Passaggi successivi
- Networking per l'accesso sicuro intra-cloud: architetture di riferimento.
- Networking per la distribuzione di applicazioni esposte a internet: architetture di riferimento
- Migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei tuoi carichi di lavoro a Google Cloud.
- Progettazione della zona di destinazione in Google Cloud fornisce indicazioni per la creazione di una rete della zona di destinazione.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.