Panoramica della gestione del traffico per bilanciatori del carico HTTP(S) interni

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.
Il bilanciamento del carico HTTP(S) interno supporta una funzionalità avanzata di gestione del traffico che consente di utilizzare le seguenti funzionalità:
  • Guida al traffico. Indirizza in modo intelligente il traffico in base ai parametri HTTP(S), ad esempio host, percorso, intestazioni e altri parametri di richiesta.
  • Azioni sul traffico. Eseguire azioni basate sulle richieste e sulle risposte (ad esempio, reindirizzamenti e trasformazioni delle intestazioni).
  • Norme sul traffico. Ottimizzare il comportamento del bilanciamento del carico (ad esempio, algoritmi di bilanciamento del carico avanzati).

Puoi configurare queste funzionalità usando mappe URL e servizi di backend. Per ulteriori informazioni, consulta i seguenti argomenti:

Esempi di casi d'uso

La gestione del traffico gestisce molti casi d'uso. Questa sezione fornisce alcuni esempi di alto livello.

Indirizzamento del traffico: routing basato su intestazione

L'indirizzamento del traffico ti consente di indirizzare il traffico alle istanze di servizio in base a parametri HTTP come le intestazioni delle richieste. Ad esempio, se il dispositivo di un utente è un dispositivo mobile con user-agent:Mobile nell'intestazione della richiesta, il traffico sterzo può inviare tale traffico a istanze di servizio designate per gestire il traffico per dispositivi mobili e inviare traffico che non ha user-agent:Mobile alle istanze configurate per gestire il traffico da altri dispositivi.

Indirizzamento del traffico a Cloud Load Balancing
Figura 1. Indirizzamento del traffico a Cloud Load Balancing.

Azioni sul traffico: suddivisione del traffico basata sul peso

Il deployment di una nuova versione di un servizio di produzione esistente comporta solitamente dei rischi. Anche se i test superano la gestione temporanea, è probabile che tu non voglia sottoporre il 100% degli utenti alla nuova versione immediatamente. Con la gestione del traffico, puoi definire suddivisioni del traffico basate su percentuale in più servizi di backend.

Ad esempio, puoi inviare il 95% del traffico alla versione precedente e a quella nuova per il 5%. Dopo aver verificato che la nuova versione di produzione funzioni come previsto, puoi spostare gradualmente le percentuali fino a quando il 100% del traffico raggiunge la nuova versione del servizio. La suddivisione del traffico viene in genere utilizzata per il deployment di nuove versioni, test A/B, migrazione dei servizi e processi simili.

Suddivisione del traffico di Cloud Load Balancing
Figura 2. Suddivisione del traffico di Cloud Load Balancing.

Criteri di traffico: mirroring delle richieste

La tua organizzazione potrebbe avere requisiti di conformità specifici che obbligano il mirroring di tutto il traffico a un servizio aggiuntivo in grado, ad esempio, di registrare i dettagli della richiesta in un database per la riproduzione successiva.

Componenti di gestione del traffico

A livello generale, i bilanciatori del carico offrono la gestione del traffico sfruttando le risorse mappe URL a livello di regione e servizi di backend a livello di regione.

Puoi configurare la gestione del traffico e le azioni relative al traffico utilizzando le mappe URL. Le risorse Google Cloud associate alle mappe URL includono quanto segue:

  • Regola di route
  • Corrispondenza regola
  • Azione regola

Puoi configurare i criteri del traffico utilizzando i servizi di backend. Le risorse Google Cloud associate ai servizi di backend includono:

  • Interruttori di sicurezza
  • Criterio del bilanciatore del carico per le località
  • Impostazioni del bilanciatore del carico hash coerenti
  • Rilevamento outlier

Il seguente diagramma mostra le risorse utilizzate per implementare ciascuna funzionalità.

Indirizzamento al traffico in Cloud Load Balancing (fai clic per ingrandire)
Figura 3. Modello di dati di Cloud Load Balancing (fai clic per ingrandire).

Routing delle richieste ai backend

Nei bilanciatori del carico HTTP(S) interni, il backend per il traffico viene determinato utilizzando un approccio in due fasi:

  • Il bilanciatore del carico seleziona un servizio di backend con backend. I backend possono essere istanze di macchine virtuali (VM) di Compute Engine in un gruppo di istanze non gestite, VM di Compute Engine in un gruppo di istanze gestite (MIG) o container in base a un nodo di Google Kubernetes Engine (GKE) in un gruppo di endpoint di rete (NEG). Il bilanciatore del carico sceglie un servizio di backend in base alle regole definite in una mappa URL a livello di regione.
  • Il servizio di backend seleziona un'istanza di backend in base ai criteri definiti in un servizio di backend a livello di area geografica.

Quando configuri il routing, puoi scegliere tra le seguenti modalità:

  • Regola semplice per host e percorso
  • Regola avanzata per host, percorso e route

Le due modalità si escludono a vicenda. Ogni mappa URL può contenere solo una modalità o l'altra.

Regola semplice per host e percorso

In una regola semplice per host e percorso, le mappe URL funzionano come descritto nella panoramica della mappa URL.

Il seguente diagramma mostra il flusso logico di una semplice regola host e percorso.

Flusso della mappa URL con una semplice regola host e percorso.
Figura 4. Flusso della mappa URL con una semplice regola host e percorso.

Inizialmente una richiesta viene valutata utilizzando le regole host. Un host è il dominio specificato dalla richiesta. Se la richiesta host corrisponde a una delle voci nel campo hosts, viene utilizzato il matcher percorso associato.

Successivamente, la corrispondenza del percorso viene valutata. Le regole percorso vengono valutate in base al percorso più lungo-che corrisponde a prima e puoi specificare le regole del percorso in qualsiasi ordine. Dopo aver trovato la corrispondenza più specifica, la richiesta viene instradata al servizio di backend corrispondente. Se la richiesta non corrisponde, verrà utilizzato il servizio di backend predefinito.

Una tipica regola host e percorso semplice potrebbe avere il seguente aspetto, in cui il traffico video va a video-backend-service e tutto il resto a web-backend-service.

$ gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Regola avanzata per host, percorso e route

Le regole avanzate di host, percorso e route offrono opzioni di configurazione aggiuntive rispetto alle regole semplici di host e percorso. Queste opzioni consentono pattern di gestione del traffico più avanzati e modificano anche parte della semantica. Ad esempio, alle regole di routing è associato un valore di priorità e vengono interpretate in ordine di priorità (anziché utilizzare la semantica "long-path-matches-first").

Come nell'esempio precedente di semplici regole host e percorso, puoi configurare la gestione avanzata del traffico utilizzando una mappa URL. Ad esempio, la seguente mappa URL configura il routing in cui il 95% del traffico viene instradato a un servizio di backend, mentre il 5% viene indirizzato a un altro servizio di backend.

$ gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

Regole host

Quando una richiesta raggiunge il bilanciatore del carico, il campo host della richiesta viene valutato in base al valore hostRules definito nella mappa URL. Ogni regola host è costituita da un elenco di uno o più host e da un singolo matcher percorso (pathMatcher). Se non viene definito alcun hostRules, la richiesta viene instradata al defaultService.

Per saperne di più, consulta hostRules[] e defaultService nella documentazione relativa all'API della mappa URL a livello di regione.

Matcher percorso

Dopo che una richiesta corrisponde a una regola host, il bilanciatore del carico valuta il matcher percorso corrispondente all'host.

Un matcher percorso è costituito dai seguenti elementi:

  • Una o più regole di percorso (pathRules) o regole di percorso (routeRules).
  • Un servizio predefinito (defaultService), che è il servizio di backend predefinito utilizzato quando nessun altro servizio di backend corrisponde.

Per saperne di più, consulta pathMatchers[], pathMatchers[].pathRules[] e pathMatchers[].routeRules[] nella documentazione relativa all'API della mappa URL a livello di regione.

Regole del percorso

Le regole di percorso (pathRules) specificano uno o più percorsi di URL, ad esempio / o /video. Le regole per i percorsi sono di solito concepite per il tipo di host semplice e per il routing basato sul percorso descritto in precedenza.

Per ulteriori informazioni, consulta pathRules[] nella documentazione relativa all'API della mappa URL a livello di area geografica.

Regole di route

Una regola di route (routeRules) crea una corrispondenza con le informazioni in una richiesta in arrivo e prende una decisione di routing basata sulla corrispondenza.

Le regole di route possono contenere una serie di regole di corrispondenza (matchRules) e diverse azioni di route (routeAction).

Una regola di corrispondenza valuta la richiesta in entrata in base al percorso, alle intestazioni e ai parametri di ricerca della richiesta HTTP(S). Le regole di corrispondenza supportano vari tipi di corrispondenze (ad es. corrispondenza di prefisso) e modificatori (ad es. distinzione tra maiuscole e minuscole). Ciò consente, ad esempio, di inviare richieste HTTP(S) a un insieme di backend in base alla presenza di un'intestazione HTTP personalizzata.

Nota: le opzioni di corrispondenza e la semantica variano a seconda della porzione di richiesta che corrispondono. Per ulteriori informazioni, consulta matchRules[] nella documentazione relativa all'API della mappa URL a livello di area geografica.

Se hai più regole di route, il bilanciatore del carico le esegue in ordine di priorità (in base al campo priority), in modo da poter specificare una logica personalizzata per la corrispondenza, il routing e altre azioni.

All'interno di una determinata regola di route, quando viene effettuata la prima corrispondenza, il bilanciatore del carico smette di valutare le regole di corrispondenza e le eventuali regole di corrispondenza rimanenti vengono ignorate.

Google Cloud esegue le seguenti azioni:

  1. Cerca la prima regola di corrispondenza che corrisponde alla richiesta.
  2. Non guarda più le altre regole di corrispondenza.
  3. Applica le azioni nelle azioni corrispondenti del percorso.

Le regole di route hanno diversi componenti, come descritto nella tabella seguente.

Componente regola di route (API field name) Descrizione
Priorità (priority) Un numero compreso tra 0 e 2.147.483.647 (ovvero (2^31)-1) assegnato a una regola di route all'interno di un determinato matcher percorso.

La priorità determina l'ordine della valutazione delle regole di route. La priorità di una regola diminuisce all'aumentare del suo numero, in modo che una regola con priorità 4 venga valutata prima di una regola con priorità 25. Viene applicata la prima regola che corrisponde alla richiesta.

I numeri di priorità possono presentare lacune. Non puoi creare più di una regola con la stessa priorità.
Descrizione (description) Una descrizione facoltativa di massimo 1024 caratteri.
Servizio (service) L'URL completo o parziale della risorsa del servizio di backend a cui viene indirizzato il traffico se questa regola viene abbinata.
Regole di corrispondenza (matchRules) Una o più regole valutate in base alla richiesta. Questi matchRules possono corrispondere a tutti o a un sottoinsieme degli attributi HTTP della richiesta, come percorso, intestazioni HTTP e parametri di query (GET).

All'interno di un matchRule, tutti i criteri corrispondenti devono essere soddisfatti affinché la routeActions di routeRule venga applicata. Se un routeRule ha più matchRules, routeActions di routeRule hanno effetto quando una richiesta corrisponde a una qualsiasi di matchRules di routeRule.
Azione route (routeAction) Consente di specificare le azioni da eseguire quando vengono soddisfatti i criteri della regola di corrispondenza. Queste azioni includono la suddivisione del traffico, le scritture degli URL, i nuovi tentativi e il mirroring, l'inserimento di errori e i criteri CORS.
Azione di reindirizzamento (urlRedirect) Puoi configurare un'azione per rispondere con un reindirizzamento HTTP quando vengono soddisfatti i criteri della regola di corrispondenza. Questo campo non può essere utilizzato insieme a un'azione di route.
Azione intestazione (headerAction) Puoi configurare le regole di trasformazione delle intestazioni delle richieste e delle risposte quando vengono soddisfatti i criteri all'interno di matchRules.

Per ulteriori informazioni, consulta i seguenti campi nella documentazione relativa all'API della mappa URL a livello di regione:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

Regole delle corrispondenze

Le regole di corrispondenza (matchRules) soddisfano uno o più attributi di una richiesta e intraprendono azioni specificate nella regola di route. Di seguito sono riportati alcuni esempi di attributi di richiesta che possono essere abbinati mediante le regole di corrispondenza:

  • Host: un nome host è la parte del nome di dominio di un URL, ad esempio la parte del nome host dell'URL http://example.net/video/hd è example.net. Nella richiesta, il nome host proviene dall'intestazione Host, come mostrato in questo comando curl di esempio, dove 10.1.2.9 è l'indirizzo IP con bilanciamento del carico:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • I percorsi seguono il nome host, ad esempio /images. La regola può specificare se l'intero percorso o solo la parte iniziale del percorso deve corrispondere.

  • Altri parametri di richiesta HTTP, come le intestazioni HTTP, che consentono la corrispondenza dei cookie e la corrispondenza in base ai parametri di ricerca (variabili GET).

Per un elenco completo delle regole di corrispondenza supportate, consulta pathMatchers[].routeRules[].matchRules[] nella documentazione relativa all'API della mappa URL a livello di regione.

Azioni route

Le azioni route sono azioni specifiche da eseguire quando una regola di route corrisponde agli attributi di una richiesta.

Azione route (API field name) Descrizione
Reindirizzamenti (urlRedirect) Restituisce un codice di risposta 3xx configurabile. Imposta anche l'intestazione della risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
Riscrittura URL (urlRewrite) Riscrive la parte del nome host dell'URL, la parte del percorso dell'URL o entrambe prima di inviare una richiesta al servizio di backend selezionato.
Trasformazioni dell'intestazione (headerAction) Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Può anche aggiungere o rimuovere le intestazioni delle risposte dopo aver ricevuto una risposta dal servizio di backend.
Mirroring del traffico (requestMirrorPolicy)

Oltre a inoltrare la richiesta al servizio di backend selezionato, invia una richiesta identica al servizio di backend mirroring in base all'opzione Attiva e dimentica. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta sottoposta a mirroring.

Mirroring è utile per testare una nuova versione di un servizio di backend. Puoi anche utilizzarla per eseguire il debug degli errori di produzione in una versione di debug del tuo servizio di backend, anziché nella versione di produzione.

Suddivisione del traffico ponderata (weightedBackendServices) Consente al traffico di una regola corrispondente di essere distribuito a più servizi di backend, proporzionale a una ponderazione definita dall'utente assegnata al singolo servizio di backend.

Questa funzionalità è utile per la configurazione di deployment graduale o test A/B. Ad esempio, l'azione route può essere configurata in modo tale che il 99% del traffico venga inviato a un servizio che esegue una versione stabile di un'applicazione, mentre l'1% del traffico viene inviato a un servizio separato che esegue una versione più recente dell'applicazione.
Nuovi tentativi (retryPolicy) Configura le condizioni in cui il bilanciatore del carico tenta di eseguire nuove richieste, il tempo di attesa prima di riprovare e il numero massimo di nuovi tentativi consentiti.
Timeout (timeout) Specifica il timeout per il percorso selezionato. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui viene completata l'elaborazione della risposta. Il timeout include tutti i tentativi.
Iniezione di guasti (faultInjectionPolicy) Introduce errori durante la gestione delle richieste per simulare errori, tra cui alta latenza, sovraccarico di servizi, errori di servizio e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio agli errori simulati.
Iniezione ritardata (faultInjectionPolicy) Introduce ritardi per una parte delle richieste definite dall'utente prima di inviare la richiesta al servizio di backend selezionato.
Interrompi iniezione (faultInjectionPolicy) Risponde direttamente a una parte delle richieste con codici di stato HTTP definiti dall'utente invece di inoltrarle al servizio di backend.
Criteri di sicurezza (corsPolicy) I criteri di condivisione delle risorse tra origini (CORS) gestiscono le impostazioni per l'applicazione forzata delle richieste CORS.

Puoi specificare una delle seguenti azioni per il percorso:

  • Instrada il traffico a un singolo servizio (service).
  • Suddividi traffico fra più servizi (weightedBackendServices weight:x, dove x < 100).
  • URL di reindirizzamento (urlRedirect).

Inoltre, puoi combinare una qualsiasi delle azioni di percorso menzionate in precedenza con una o più delle seguenti azioni di percorso:

  • Mirroring del traffico (requestMirrorPolicy).
  • Riscrivi host/percorso dell'URL (urlRewrite).
  • Riprova richieste non riuscite (retryPolicy).
  • Imposta timeout (timeout).
  • Introduci errori in una percentuale del traffico (faultInjectionPolicy).
  • Aggiungi il criterio CORS (corsPolicy).
  • Manipola le intestazioni della richiesta/risposta (headerAction).

Per ulteriori informazioni sulla configurazione e sulla semantica delle azioni route, consulta quanto segue nella documentazione relativa all'API della mappa URL a livello di regione:

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Reindirizzamenti da HTTP a HTTPS

Se devi reindirizzare il traffico HTTP a HTTPS, puoi creare due regole di forwarding con un indirizzo IP comune.

Affinché due regole di forwarding condividono un indirizzo IP interno comune, devi prenotare l'indirizzo IP e includere il flag --purpose=SHARED_LOADBALANCER_VIP:

gcloud compute addresses create NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP
Per un esempio completo, consulta Configurazione del reindirizzamento da HTTP a HTTPS per i bilanciatori del carico HTTP(S) interni.

Criteri di traffico

Utilizzando le risorse del servizio di backend, puoi configurare i criteri del traffico per ottimizzare il bilanciamento del carico all'interno di un gruppo di istanze o di un gruppo di endpoint di rete (NEG). Questi criteri vengono applicati solo dopo che un servizio di backend è stato selezionato utilizzando la mappa URL (come descritto in precedenza).

I criteri di traffico consentono di:

  • Controlla l'algoritmo di bilanciamento del carico tra le istanze all'interno del servizio di backend.
  • Controlla il volume delle connessioni a un servizio a monte.
  • Controlla l'eliminazione degli host con problemi di integrità da un servizio di backend.
Le seguenti funzionalità dei criteri di traffico sono configurate nel servizio di backend a livello di area geografica.
Criterio di traffico (API field name) Descrizione
Criterio di località del bilanciamento del carico (LocalityLbPolicy)

Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento del carico e su un criterio di località del bilanciamento del carico.

La modalità di bilanciamento determina la ponderazione/frazione del traffico che deve essere inviata a ogni backend (gruppo di istanze o NEG GCE_VM_IP_PORT). Il criterio di bilanciamento del carico (LocalityLbPolicy) determina il modo in cui i backend all'interno della zona di o nel gruppo vengono bilanciati del carico. Quando un servizio di backend riceve il traffico, lo indirizza innanzitutto a un backend (gruppo di istanze o NEG GCE_VM_IP_PORT) in base alla modalità di bilanciamento del backend. Dopo la selezione di un backend, il traffico viene quindi distribuito tra le istanze o gli endpoint all'interno di ciascuna zona in base al criterio della località. Per i gruppi di istanze gestite a livello di regione, il criterio della località si applica a ogni zona costitutiva.

Per le modalità di bilanciamento supportate, consulta la sezione Modalità di bilanciamento.

Per gli algoritmi dei criteri di bilanciamento del carico supportati, consulta localityLbPolicy nella documentazione dell'API del servizio di backend a livello di area geografica.

Affinità sessione (consistentHash)

Include affinità basata su cookie HTTP, affinità basata su intestazioni HTTP, affinità indirizzo IP client e affinità cookie generata. Affinità sessione offre un tentativo ottimale di inviare richieste da un determinato client allo stesso backend, purché la parte posteriore sia in stato integro e abbia capacità.

Per ulteriori informazioni sull'affinità sessione, consulta consistentHash nella documentazione relativa all'API del servizio di backend della regione.

Rilevamento outlier (outlierDetection)

Un insieme di criteri che specifica i criteri per l'eliminazione delle VM o degli endpoint di backend in stato non integro nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato abbastanza integro da ricevere nuovamente traffico.

Per ulteriori informazioni sul rilevamento dei valori anomali, consulta outlierDetection nella documentazione relativa all'API del servizio di backend a livello di regione.

Interruttore di sicurezza (circuitBreakers)

Imposta limiti superiori sul volume di connessioni e richieste per connessione a un servizio di backend.

Per saperne di più sull'interruzione del circuito, vedi circuitBreakers nella documentazione relativa all'API del servizio di backend a livello di area geografica.

Passaggi successivi