Architetture di bilanciamento del carico globale che utilizzano i criteri di routing DNS

Last reviewed 2023-01-04 UTC

Questo documento descrive come combinare più bilanciatori del carico regionali con i criteri di routing DNS di Google per creare architetture di bilanciamento del carico globale. Il documento è rivolto a tecnici di rete, architetti di soluzioni e professionisti delle operazioni. Si presuppone che tu abbia una conoscenza di base di Google Compute Engine e abbia familiarità con i concetti di networking come i bilanciatori del carico e le ricerche DNS.

Introduzione

Quando crei un servizio globale implementato come applicazione in esecuzione 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, crei un endpoint globale che instrada il traffico al servizio locale più vicino.

A seconda del tipo di bilanciatore del carico in uso, potresti riuscire a ottenere questo scenario con opzioni di bilanciamento del carico globale basato su proxy. Tuttavia, per alcuni casi d'uso, devi utilizzare prodotti di bilanciamento del carico a livello di regione, ad esempio se il tuo servizio gestisce traffico UDP. I criteri di routing DNS di geolocalizzazione possono anche essere utili per fornire un singolo endpoint DNS per le applicazioni ibride che utilizzano Google Cloud insieme ad altri fornitori 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 regionali in tre diverse regioni. Le regioni vengono combinate utilizzando i criteri di routing DNS.

Architettura in cui Cloud DNS instrada il traffico a un bilanciatore del carico interno a livello di regione in base a dove si trova il client.

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 del 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 regionali:

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 regionali mediante 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 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 tuo servizio è disponibile a livello globale. In questo caso, i backend possono trovarsi solo in una singola regione. Tuttavia, quando usi i criteri di routing DNS, puoi avere backend in più regioni.

Il seguente diagramma mostra questa architettura:

Architettura per i client interni in cui Cloud DNS invia il traffico all'istanza del bilanciatore del carico di rete passthrough interno che si trova nella regione in cui si trova il client.

Il diagramma precedente mostra come i client interni in più regioni risolvono service.corp.example.com utilizzando Cloud DNS. I client ricevono sempre una risposta che ha 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 questa non è una condizione necessaria. I client inviano il traffico dell'applicazione a un'istanza locale dell'applicazione, ma utilizzano tutti lo stesso endpoint DNS service.corp.example.com.

Per creare questa configurazione:

  1. Puoi 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.

  2. Devi creare un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il valore --routing-policy-data su 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 spesso i record DNS in caso di modifiche al 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 all'esterno 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 alla regione del bilanciatore del carico interno più vicina. Se più dell'80% dei backend in quella regione non è integro e se utilizzi la funzionalità di controllo di integrità con i criteri di routing del DNS geografico, il failover del traffico tra regioni diverse.

Se non è necessario il 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 regionali 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 alcuna opzione di bilanciamento del carico globale.

Per le applicazioni che utilizzano traffico TCP supportate dal bilanciatore del carico di rete proxy esterno o dal bilanciatore del carico delle applicazioni 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 tramite anycast, che fornisce un singolo indirizzo IP come frontend per tutte le tue 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 avviene senza modifiche 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 di Cloud DNS che sceglie una località di destinazione.
  • Bilanciamento del carico tra regioni. Il bilanciamento del carico globale di Google supporta il failover tra regioni. Al contrario, non è previsto il controllo di integrità con i criteri di routing DNS quando utilizzi un bilanciatore del carico di rete passthrough esterno.

Ti consigliamo quindi 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 utilizzando un endpoint DNS globale:

Architettura per client esterni in cui i client ottengono un indirizzo IP per l'istanza del bilanciatore del carico di rete passthrough interno che si trova nella regione in cui si trova il client.

Il diagramma precedente mostra come 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. Ogni 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:

  1. Crei i bilanciatori del carico TCP/UDP di rete in ogni regione.

  2. Devi creare un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il valore --routing-policy-data su 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 a quel client.

L'endpoint globale www.example.com non può essere utilizzato per eseguire automaticamente il failover per il traffico tra regioni, perché quando utilizzi un bilanciatore del carico di rete passthrough esterno, non viene eseguito il controllo di integrità. È tua responsabilità attivare manualmente il failover modificando i record DNS.

Un altro caso d'uso che puoi risolvere con questo approccio è la presenza di un'applicazione che utilizza HTTP(S) con requisiti di regione per i dati, ma vuoi comunque gestire i dati utilizzando un endpoint globale. Puoi implementare questo scenario combinando più istanze di Application Load Balancer esterno regionale utilizzando i criteri di routing del DNS di geolocalizzazione. Se non hai requisiti per la regione, puoi utilizzare un bilanciatore del carico delle applicazioni 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 del DNS di geolocalizzazione.

Il seguente diagramma mostra questa architettura:

Architettura per uno scenario ibrido in cui Cloud DNS invia il traffico all'istanza del bilanciatore del carico di rete passthrough interno per i client che si trovano in Asia e negli Stati Uniti e a un bilanciatore del carico on-premise per i client in Europa.

Il diagramma precedente mostra come 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. L'applicazione a cui punta il bilanciatore del carico è in esecuzione su GKE nella stessa regione. Per gli utenti di 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 Google Distributed Cloud. In questo esempio, le applicazioni vengono eseguite su Google Distributed Cloud e su GKE, ma questa non è una condizione necessaria.

Per creare questa configurazione:

  1. Puoi creare i bilanciatori del carico TCP/UDP di rete e il bilanciatore del carico on-premise in ogni regione.

  2. Tu crei un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il valore --routing-policy-data su 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"

Se imposti 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 alla regione geografica esatti del client. Nell'esempio precedente, la maggior parte degli utenti viene inviata a una regione o al data center on-premise che si trova nel proprio continente. Tuttavia, l'algoritmo utilizzato da Cloud DNS per determinare la regione Google Cloud più vicina potrebbe non essere in linea con i confini specifici del paese o dell'area geografica. Non puoi quindi usare i criteri di routing DNS di geolocalizzazione per i casi d'uso di conformità.

Con questo approccio ibrido non sono possibili altri casi d'uso che richiedono una maggiore granularità rispetto alla granularità a livello di continente mostrata in questo esempio. Ad esempio, nei casi in cui tu abbia un data center on-premise in un paese in cui non esiste alcuna regione Google Cloud, non è possibile inviare traffico on-premise per gli utenti del paese o della regione in questione. Puoi configurare il bilanciatore del carico solo in modo che restituisca indirizzi IP in base alla regione Google Cloud più vicina. Se vuoi limitare o instradare il traffico in base a posizione geografica o 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