Questo documento fa parte di una serie che descrive le architetture di networking e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro dei data center a Google Cloud.
La serie è composta dai seguenti documenti:
- Progettazione di reti per la migrazione dei carichi di lavoro aziendali: approcci all'architettura
- Networking per l'accesso sicuro intra-cloud: architetture di riferimento
- Networking per la distribuzione di applicazioni per internet: architetture di riferimento
- Networking per carichi di lavoro ibridi e multi-cloud: architetture di riferimento (questo documento)
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, oppure in più ambienti cloud.
Architettura lift and shift
Il primo scenario di accesso ibrido ai carichi di lavoro è 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 di Interconnect in due diverse aree metropolitane e 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 degli elementi di base aziendali.
Figura 1. Configurazione delle connessioni Cloud 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 nel cloud. Questo approccio consente di sfruttare la copertura e l'affidabilità della rete di Google quando è necessario spostare 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.
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 backbone di Google.
Per ulteriori informazioni sulla configurazione di Network Connectivity Center, consulta le 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 può essere un router SD-WAN di terze parti supportato da uno dei nostri partner o un'altra appliance virtuale che consente di scambiare 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.
Figura 3. Configurazione del Network Connectivity Center con appliance router per l'integrazione dell'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 per utilizzare un'appliance virtuale di networking, in cui il traffico dall'ambiente on-premise arriva in una rete VPC in 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 le Considerazioni nella documentazione di Network Connectivity Center.
Architettura di servizi ibridi
Come nel caso d'uso intra-cloud discusso in Networking per l'accesso sicuro intra-cloud: architetture di riferimento, Network Connectivity Center consente la connettività a Google Cloud dalle tue filiali e dalle reti on-premise. Private Service Connect fornisce accesso privato ai servizi gestiti da Google o consente di utilizzare altri servizi creati e distribuiti nel cloud.
Puoi implementare la sicurezza della rete anche utilizzando una combinazione di Controlli di servizio VPC, firewall di Google Cloud e appliance virtuali di rete, come mostrato nella Figura 4.
Figura 4. Reti con un'architettura che utilizza sia un modello lift and shift sia un pattern di progettazione di servizi ibridi progettata per fornire un piano dati sicuro.
Architettura distribuita Zero Trust
In un ambiente ibrido, i microservizi vengono eseguiti in meglie di servizi di cui viene eseguito il deployment su diversi cloud provider e ambienti on-premise. Puoi proteggere le comunicazioni 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 tecnologia mTLS end-to-end tra i servizi viene abilitata utilizzando il gateway est-ovest e il routing basato su SNI. Anthos 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 prevedono deployment di più mesh, ad esempio più cluster GKE. Un componente importante di questo flusso è il routing SNI, che viene utilizzato al gateway est-ovest di GKE per ogni cluster. Questa configurazione consente il routing mTLS diretto al carico di lavoro da parte del gateway, preservando al contempo la connettività mTLS end-to-end.
Figura 5. Mesh di servizi Zero Trust distribuito in un ambiente on-premise e in Google Cloud.
Le aziende possono utilizzare Anthos Service Mesh per il deployment su più cloud. Per affrontare le problematiche di gestione di identità e certificati tra provider cloud, Anthos Service Mesh fornisce identità del carico di lavoro e un'autorità di certificazione (CA) intermedia in cluster utilizzando CA Service (CA Service). La CA intermedia può essere concatenata a una CA esterna oppure può essere ospitata in Google. Puoi personalizzare gli attributi della CA, come la regione e l'algoritmo di firma, utilizzando sia HSM di proprietà aziendale sia Cloud HSM.
Workload Identity consente di assegnare identità e autorizzazioni distinte e granulari per ciascun microservizio nel tuo cluster. Anthos 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à nei cluster GKE.
La Figura 6 mostra un'architettura che utilizza Anthos Service Mesh per gestire le identità e le autorizzazioni.
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 cloud di Google.
Figura 6. Mesh di servizi Zero Trust di cui è stato eseguito il deployment su più cloud.
Puoi utilizzare Traffic Director per instradare il traffico dal mesh all'ambiente on-premise o a qualsiasi altro cloud.
Ad esempio, puoi creare servizi in Traffic Director chiamati on-prem-service e other-cloud-service e aggiungere gruppi di endpoint di rete (NEG) con connettività ibrida con endpoint 10.1.0.1:80 e 10.2.0.1:80.
Traffic Director invia quindi il traffico ai propri client, che sono proxy collaterali mesh in esecuzione insieme alle tue applicazioni. Di conseguenza, quando l'applicazione invia una richiesta al servizio on-prem-service, il client Traffic Director controlla la richiesta e la indirizza all'endpoint 10.0.0.1:80. La Figura 7 illustra questa configurazione.
Figura 7. Traffico indirizzato da un mesh di servizi tramite Traffic Director.
È inoltre possibile incorporare funzionalità avanzate come il reindirizzamento del traffico in base al peso, come mostrato nella Figura 8. che consente di soddisfare esigenze aziendali critiche, come la migrazione al cloud. Traffic Director funge da piano di controllo versatile e gestito a livello globale per i tuoi mesh di servizi.
Figura 8. Traffico ponderato gestito tramite Traffic Director.
Passaggi successivi
- Networking per l'accesso sicuro intra-cloud: architetture di riferimento.
- Networking per la distribuzione di applicazioni per internet: architetture di riferimento
- La migrazione a Google Cloud può aiutarti a pianificare, progettare e implementare il processo di migrazione dei carichi di lavoro su Google Cloud.
- La progettazione delle zone di destinazione in Google Cloud offre indicazioni per la creazione di una rete con zone di destinazione.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.