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 a livello di regione con Google Criteri di routing DNS per creare architetture di bilanciamento del carico globale. Il documento è rivolto alla rete ingegneri, architetti di soluzioni e professionisti delle operazioni. Si parte dal presupposto che hai una conoscenza di base di Google Compute Engine e conosci concetti di networking come i bilanciatori del carico e le ricerche DNS.

Introduzione

Quando crei un servizio globale implementato come applicazione. in più regioni, puoi utilizzare la geolocalizzazione Criteri di routing DNS per avere un endpoint DNS globale per i bilanciatori del carico a livello di regione. In questo viene creato un endpoint globale che instrada il traffico all'indirizzo completamente gestito di Google Cloud.

In base tipo di bilanciatore del carico che stai utilizzando, potresti riuscire a ottenere questo scenario con le applicazioni di bilanciamento del carico. Tuttavia, per alcuni casi d'uso, devi usare le regioni prodotti di bilanciamento del carico, ad esempio se il servizio gestisce traffico UDP. I criteri di routing dei DNS di geolocalizzazione possono anche aiutarti a fornire una singolo endpoint DNS per le applicazioni ibride che utilizzano Google Cloud insieme da altri provider di servizi cloud o insieme a un deployment on-premise.

Architettura

Il seguente diagramma mostra un'architettura di esempio che utilizza tre carichi regionali bilanciatori del carico in tre diverse regioni. Le regioni vengono combinate utilizzando Criteri di routing del 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 come i clienti in Oregon, Germania e Singapore eseguono il DNS esegue ricerche in Cloud DNS per www.example.com. Le richieste vengono indirizzate a bilanciatori del carico regionali vicini a ciascun client per raggiungere un'applicazione ospitato 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 della geolocalizzazione Criteri di routing DNS per creare un servizio globale da più carichi a livello di regione bilanciatori del carico:

Un servizio interno accessibile e distribuito a livello globale

Puoi creare un servizio interno accessibile e distribuito a livello globale combinando più bilanciatori del carico interni a livello di regione tramite la geolocalizzazione Criteri di routing del DNS. Puoi utilizzare uno dei seguenti bilanciatore del carico di rete passthrough interno o un bilanciatore del carico delle applicazioni interno. Senza i criteri di routing del DNS, un bilanciatore del carico delle applicazioni interno può utilizzare solo a livello di regione. Con un bilanciatore del carico di rete passthrough interno che utilizza accesso globale, puoi rendere disponibile il tuo servizio a livello globale; in questo caso, i backend possono trovarsi in una singola regione. Tuttavia, quando utilizzi 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 la risoluzione dei client interni in più regioni service.corp.example.com utilizzando Cloud DNS. I clienti ricevono sempre una risposta con un indirizzo IP che appartiene a un bilanciatore del carico di rete passthrough interno della regione del cliente. Il bilanciatore del carico punta a un'applicazione nella stessa regione. (in questo esempio, l'applicazione viene eseguita Google Kubernetes Engine (GKE), ma non è una condizione necessaria. I clienti inviano il traffico dell'applicazione verso un'istanza locale dell'applicazione, ma tutti utilizzano stesso endpoint DNS service.corp.example.com.

Per creare questa configurazione:

  1. Tu crea 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. Tu crea un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il parametro --routing-policy-data a un elenco di regioni target mappate al bilanciatore del carico interno corrispondente. Puoi creare la configurazione illustrato 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 assicura che i client aggiornino spesso i record DNS se il criterio modifiche.

Quando utilizzi i criteri di routing DNS, ciascun 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 del DNS instradano il traffico in base al bilanciatore del carico interno più vicino regione. Se più dell'80% dei backend in quella regione non è integro e se utilizzando la funzionalità di controllo di integrità con i criteri di routing DNS geografico, il failover del traffico tra regioni diverse.

Se non è necessario il failover tra regioni, puoi modificare il comando che segue:

  • Rimuovi il flag --enable-health-checking.
  • Sostituisci il nome di ogni regola di forwarding per il bilanciatore del carico interno con il suo 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 la geolocalizzazione Criteri di routing del DNS. Il caso d'uso più comune è l'utilizzo 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, poiché non è disponibili su Google Cloud per UDP.

Per le applicazioni che utilizzano traffico TCP supportato dal bilanciatore del carico di rete proxy esterno o dal bilanciatore del carico delle applicazioni esterno, potresti essere in grado di utilizzare istanze di questi bilanciatori del carico globali anziché utilizzare un endpoint DNS. Questi bilanciatori del carico forniscono il bilanciamento del carico anycast che fornisce un singolo indirizzo IP come frontend per tutto il backend di Compute Engine.

I vantaggi dell'utilizzo di opzioni di bilanciamento del carico globale rispetto all'endpoint DNS sono le seguenti:

  • Il failover è immediato. Il failover avviene senza modifiche visibili di traffico proveniente dal lato utente.
  • Il routing internet determina la destinazione del bilanciamento del carico. I protocolli di routing internet inoltrano il traffico in base invece di Cloud DNS a scegliere una località di destinazione.
  • Bilanciamento del carico tra regioni. Il bilanciamento del carico globale di Google supporta tra regioni diverse. Al contrario, DNS non prevede il controllo di integrità i criteri di routing 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 l'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 si risolvono i client esterni in più regioni www.example.com utilizzando Cloud DNS. I client ricevono una risposta con un IP che appartiene a un bilanciatore del carico TCP/UDP di rete che si trova regione. 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 ma usano tutti lo stesso endpoint DNS www.example.com.

Per creare questa configurazione:

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

  2. Tu crea un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il parametro --routing-policy-data a un elenco di regioni target mappate al bilanciatore del carico TCP/UDP di rete corrispondente. Puoi creare il cluster illustrata nel diagramma mediante 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 che contiene l'indirizzo IP del bilanciatore del carico di rete passthrough esterno nella regione più vicina a quel cliente.

Impossibile utilizzare l'endpoint globale www.example.com per eseguire automaticamente per il traffico tra regioni, perché quando usi un bilanciatore del carico di rete passthrough esterno, non c'è alcun controllo di integrità. È la tua di attivare manualmente il failover modificando i record DNS.

Un altro caso d'uso che puoi risolvere con questo approccio è la presenza di una che utilizza HTTP(S) con requisiti di regione per i dati, ma vogliono comunque gestire i dati utilizzando un endpoint globale. Puoi implementare questo scenario combinando Bilanciatore del carico delle applicazioni esterno regionale utilizzando criteri di routing DNS di geolocalizzazione. Se non disponi regionali, 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 mediante i criteri di routing 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 si risolvono i client esterni in più regioni www.example.com utilizzando Cloud DNS. Punti internet Cloud DNS a un indirizzo IP che appartiene a una rete TCP/UDP, in una regione vicina. L'applicazione che carica i punti del bilanciatore del carico sono in esecuzione su GKE nella stessa regione. Per per gli utenti internet europei, Cloud DNS restituisce un indirizzo IP che punta su un bilanciatore del carico in un data center on-premise europeo, con l'applicazione ospitato su Google Distributed Cloud. (In questo esempio, eseguite su Google Distributed Cloud e su GKE, non è una condizione necessaria).

Per creare questa configurazione:

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

  2. Tu crei un criterio di routing DNS. Nel criterio, imposti il tipo su GEO e il parametro --routing-policy-data a un elenco di regioni target mappate al bilanciatore del carico TCP/UDP di rete corrispondente. Puoi creare la configurazione illustrato 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 ottenere Cloud DNS restituiscono indirizzi IP diversi in base alla regione Google Cloud più vicina. Tuttavia, non puoi indirizzare il traffico in base al paese o all'area geografica esatti regione 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 loro continente. Tuttavia, utilizzato da Cloud DNS per determinare l'algoritmo più vicino La regione Google Cloud potrebbe non allinearsi a un paese o un'area geografica specifici confini. Di conseguenza non puoi utilizzare i criteri di routing del DNS di geolocalizzazione per i casi d'uso di conformità.

Altri casi d'uso che richiedono più granularità rispetto a quelli a livello di continente. la granularità mostrata in questo esempio non è possibile con questo approccio ibrido. Per Ad esempio, nei casi in cui tu abbia un data center on-premise in un paese se non esiste una regione Google Cloud, non è possibile inviare traffico on-premise per gli utenti di quel paese o di quella regione: puoi configurare con il bilanciatore del carico Google Cloud più vicino per restituire gli indirizzi IP regione. Se vuoi limitare o indirizzare il traffico in base a una posizione geografica esatta località o paese, puoi utilizzare un provider di terze parti che offra un servizio di il servizio di bilanciamento del carico del server globale (GSLB).

Passaggi successivi