Questo documento descrive come combinare più bilanciatori del carico a livello di regione con i criteri di routing DNS di Google per creare architetture di bilanciamento del carico globali. Il documento è rivolto a ingegneri di rete, Solution Architect e professionisti delle operazioni. Si presume che tu abbia una conoscenza di base di Google Compute Engine e abbia dimestichezza con i concetti di networking come i bilanciatori del carico e le ricerche DNS.
Introduzione
Quando crei un servizio globale che viene implementato come un'applicazione eseguita in più regioni, puoi utilizzare i criteri di routing DNS di geolocalizzazione per avere un endpoint DNS globale per i bilanciatori del carico a livello di regione. In questo approccio, devi creare un endpoint globale che instrada il traffico al servizio locale più vicino.
A seconda del tipo di bilanciatore del carico utilizzato, potresti riuscire a ottenere questo scenario con opzioni di bilanciamento del carico globali basate su proxy. Tuttavia, per alcuni casi d'uso, è necessario utilizzare prodotti di bilanciamento del carico a livello di regione, ad esempio se il servizio gestisce traffico UDP. I criteri di routing DNS di geolocalizzazione possono anche aiutare a fornire un singolo endpoint DNS per le applicazioni ibride che utilizzano Google Cloud insieme ad altri provider di servizi cloud o insieme a un deployment on-premise.
Architettura
Il seguente diagramma mostra un'architettura di esempio che utilizza tre bilanciatori del carico a livello di regione in tre diverse regioni. Le regioni vengono combinate utilizzando i criteri di routing DNS.
Il diagramma precedente mostra in che modo i client in Oregon, Germania e Singapore eseguono ricerche DNS in Cloud DNS per www.example.com. Le richieste vengono instradate a bilanciatori del carico a livello di regione vicini a ciascun client per raggiungere un'applicazione ospitata in tre diverse regioni.
Casi d'uso per i criteri di routing DNS di geolocalizzazione
Questa sezione illustra i seguenti casi d'uso per l'utilizzo dei criteri di routing DNS di geolocalizzazione per creare un servizio globale da più bilanciatori del carico a livello di regione:
- Un servizio interno accessibile e distribuito a livello globale
- Un endpoint DNS globale per un servizio esterno che supporta TCP e UDP
- Un endpoint DNS globale per un servizio ibrido
Un servizio interno accessibile e distribuito a livello globale
Puoi creare un servizio interno accessibile a livello globale e distribuito a livello globale combinando più bilanciatori del carico interni a livello di regione utilizzando i criteri di routing DNS di geolocalizzazione. Puoi utilizzare un bilanciatore del carico di rete passthrough interno o un bilanciatore del carico delle applicazioni interno. Senza i criteri di routing DNS, un bilanciatore del carico delle applicazioni interno può utilizzare solo endpoint a livello di regione. Con un bilanciatore del carico di rete passthrough interno che utilizza l'accesso globale, il servizio è disponibile a livello globale; in questo caso, i backend possono trovarsi in una sola regione. Tuttavia, quando utilizzi i criteri di routing DNS, puoi avere backend in più regioni.
Il seguente diagramma mostra questa architettura:
Il diagramma precedente mostra in che modo i client interni in più regioni risolvono
service.corp.example.com utilizzando Cloud DNS. I client ricevono sempre una risposta con un indirizzo IP che appartiene a un bilanciatore del carico di rete passthrough interno che si trova nella regione del client. Il bilanciatore del carico punta a un'applicazione che si trova nella stessa regione. In questo esempio, l'applicazione viene eseguita su Google Kubernetes Engine (GKE), ma non è una condizione necessaria. I client inviano il traffico delle applicazioni a un'istanza locale dell'applicazione, ma utilizzano tutti lo stesso endpoint DNS service.corp.example.com.
Per creare questa configurazione, segui questi passaggi:
- Devi creare i bilanciatori del carico interni in ogni regione. Se utilizzi un bilanciatore del carico di rete passthrough interno, devi abilitare l'accesso globale per garantire che i client di altre regioni possano connettersi al servizio.
Devi creare un criterio di routing DNS. Nel criterio, imposti il tipo su
GEOe il valore--routing-policy-datasu un elenco di regioni di destinazione mappate al bilanciatore del carico interno corrispondente. Puoi creare la configurazione illustrata nel diagramma utilizzando il seguente comando:gcloud beta dns record-sets create service.corp.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \ --enable-health-checking
Nell'esempio, viene creato un record con un valore TTL di 30 secondi per garantire che i client aggiornino frequentemente i record DNS in caso di modifica del criterio.
Quando utilizzi i criteri di routing DNS, ogni client riceve una risposta DNS che contiene l'indirizzo IP del bilanciatore del carico interno nella regione. Se il client si trova al di fuori di una regione in cui sono definiti i bilanciatori del carico interni, riceve l'indirizzo IP del bilanciatore del carico interno che si trova nella regione più vicina.
I criteri di routing DNS instradano il traffico in base all'area geografica del bilanciatore del carico interno più vicina. Se oltre l'80% dei backend in quella regione non è integro e utilizzi la funzionalità di controllo di integrità con i criteri di routing del DNS geografico, il traffico ha esito negativo tra le regioni.
Se non hai bisogno del failover tra regioni, puoi modificare il comando come segue:
- Rimuovi il flag
--enable-health-checking. - Sostituisci il nome di ogni regola di forwarding per il bilanciatore del carico interno con il relativo indirizzo IP.
Un endpoint globale per un servizio esterno che supporta TCP e UDP
Puoi anche creare un endpoint DNS globale per un servizio esterno combinando più bilanciatori del carico esterni a livello di regione utilizzando i criteri di routing DNS di geolocalizzazione. Il caso d'uso più comune è l'utilizzo di un bilanciatore del carico di rete passthrough esterno per qualsiasi applicazione basata su TCP o UDP. Questo approccio è particolarmente utile per le applicazioni che utilizzano UDP, perché su Google Cloud per UDP non è disponibile un'opzione di bilanciamento del carico globale.
Per le applicazioni che utilizzano il traffico TCP supportate dal bilanciatore del carico di rete proxy esterno o dall'Application Load Balancer esterno, potresti essere in grado di utilizzare le istanze di questi bilanciatori del carico globali anziché un endpoint DNS. Questi bilanciatori del carico forniscono il bilanciamento del carico tra regioni utilizzando anycast, che fornisce un singolo indirizzo IP come frontend per tutte le istanze di backend.
I vantaggi dell'utilizzo delle opzioni di bilanciamento del carico globale rispetto all'endpoint DNS sono i seguenti:
- Il failover è immediato. Il failover si verifica senza variazioni visibili nel flusso di traffico dal lato utente.
- Il routing Internet determina la destinazione del bilanciamento del carico. I protocolli di routing internet inoltrano il traffico in base al percorso più breve, invece che Cloud DNS sceglie una località di destinazione.
- Bilanciamento del carico tra regioni. Il bilanciamento del carico globale di Google supporta il failover tra regioni. Al contrario, quando utilizzi un bilanciatore del carico di rete passthrough esterno, non è previsto alcun controllo di integrità con i criteri di routing DNS.
Pertanto, ti consigliamo di utilizzare l'opzione di bilanciamento del carico globale di Google quando la tua applicazione è basata su TCP ed è supportata da questi prodotti.
Il seguente diagramma mostra l'architettura che utilizza un endpoint DNS globale:
Il diagramma precedente mostra in che modo i client esterni in più regioni risolvono
www.example.com utilizzando Cloud DNS. I client ricevono una risposta con un indirizzo IP che appartiene a un bilanciatore del carico TCP/UDP di rete che si trova nella regione del client. Il client può quindi connettersi a un'applicazione in esecuzione nella stessa regione. Ciascun client invia il traffico dell'applicazione a un'istanza locale del servizio, ma tutti utilizzano lo stesso endpoint DNS www.example.com.
Per creare questa configurazione, segui questi passaggi:
- Devi creare i bilanciatori del carico TCP/UDP di rete in ogni area geografica.
Devi creare un criterio di routing DNS. Nel criterio, imposti il tipo su
GEOe il valore--routing-policy-datasu un elenco di regioni di destinazione mappate al bilanciatore del carico TCP/UDP di rete corrispondente. Puoi creare la configurazione illustrata nel diagramma utilizzando il seguente comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Dopo aver applicato questo criterio, quando i client effettuano richieste DNS, ogni client riceve una risposta DNS contenente l'indirizzo IP del bilanciatore del carico di rete passthrough esterno che si trova nella regione più vicina al client.
Non è possibile utilizzare l'endpoint globale www.example.com per eseguire automaticamente il failover del traffico tra regioni perché, quando utilizzi un bilanciatore del carico di rete passthrough esterno, non è previsto alcun controllo di integrità. È tua responsabilità attivare manualmente il failover modificando i record DNS.
Un altro caso d'uso che puoi risolvere con questo approccio è che hai un'applicazione che utilizza HTTP(S) con requisiti di regione per i tuoi dati, ma vuoi comunque gestire i dati utilizzando un endpoint globale. Puoi implementare questo scenario combinando più istanze dell'Application Load Balancer esterno regionale utilizzando i criteri di routing DNS di geolocalizzazione. Se non hai requisiti di regione, puoi utilizzare un Application Load Balancer esterno globale.
Un endpoint DNS globale per un servizio ibrido
In alcuni casi, puoi fornire un singolo endpoint per un'applicazione ibrida utilizzando i criteri di routing DNS di geolocalizzazione.
Il seguente diagramma mostra questa architettura:
Il diagramma precedente mostra in che modo i client esterni in più regioni risolvono
www.example.com utilizzando Cloud DNS. Cloud DNS indirizza gli utenti internet in Asia e negli Stati Uniti a un indirizzo IP che appartiene a un bilanciatore del carico TCP/UDP di rete che si trova in una regione vicina a loro. L'applicazione a cui punta il bilanciatore del carico è in esecuzione su GKE nella stessa regione. Per gli utenti internet in Europa, Cloud DNS restituisce un indirizzo IP che punta a un bilanciatore del carico in un data center on-premise europeo, con l'applicazione ospitata su GKE su VMware. (In questo esempio, le applicazioni vengono eseguite su GKE su VMware e su GKE, ma non è una condizione necessaria.)
Per creare questa configurazione, segui questi passaggi:
- Creerai i bilanciatori del carico TCP/UDP di rete e il bilanciatore del carico on-premise in ogni regione.
Crei un criterio di routing DNS. Nel criterio, imposti il tipo su
GEOe il valore--routing-policy-datasu un elenco di regioni di destinazione mappate al bilanciatore del carico TCP/UDP di rete corrispondente. Puoi creare la configurazione illustrata nel diagramma utilizzando il seguente comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Impostando il flag --routing-policy-data, puoi fare in modo che Cloud DNS restituisca indirizzi IP diversi in base alla regione Google Cloud più vicina.
Tuttavia, non puoi instradare il traffico in base al paese o all'area geografica esatti del client. Nell'esempio precedente, la maggior parte degli utenti viene inviata in una regione o al data center on-premise che si trova nel loro continente. Tuttavia, l'algoritmo utilizzato da Cloud DNS per determinare la regione Google Cloud più vicina potrebbe non essere in linea con i confini geografici o di paesi specifici. Pertanto, non puoi utilizzare i criteri di routing DNS di geolocalizzazione per casi d'uso di conformità.
Con questo approccio ibrido non sono possibili altri casi d'uso che richiedono maggiore granularità rispetto alla granularità a livello di continente mostrata in questo esempio. Ad esempio, nei casi in cui tu possieda un data center on-premise in un paese in cui non esiste alcuna regione Google Cloud, non puoi inviare traffico on-premise per gli utenti di quel paese o di quella regione. Puoi configurare il bilanciatore del carico solo in modo che restituisca gli indirizzi IP basati sulla regione Google Cloud più vicina. Se vuoi limitare o instradare il traffico in base alla posizione geografica o al paese esatti, puoi utilizzare un provider di terze parti che offre un servizio di bilanciamento del carico del server globale (GSLB) basato su DNS.
Passaggi successivi
- Gestire i criteri di routing DNS.
- Best practice per il DNS.
- Funzionalità del bilanciatore del carico.
- Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.