Criteri load balancer

Applica i criteri del load balancer per controllare la distribuzione del traffico ai server backend.

Dopo aver creato un load balancer, puoi applicare i criteri per controllare la distribuzione del traffico ai tuoi server backend. Il servizio Load balancer supporta tre tipi di criteri principali:

Quando il carico o la capacità di elaborazione varia tra i server backend, puoi perfezionare ciascuno di questi tipi di criteri con la ponderazione del server backend. La ponderazione influisce sulla proporzione di richieste indirizzate a ciascun server. Ad esempio, un server con ponderazione '3' riceve un numero di connessioni tre volte superiore a quello di un server con ponderazione '1'. I pesi vengono assegnati in base ai criteri scelti, ad esempio la capacità di gestione del traffico di ciascun server. I valori del peso devono essere compresi tra 1 e 100.

Le decisioni relative ai criteri del load balancer si applicano in modo diverso ai load balancer TCP, alle richieste HTTP persistenti (richieste persistenti) di sessione basate su cookie e alle richieste HTTP non persistenti.

  • Un load balancer TCP prende in considerazione i criteri e il peso per indirizzare una richiesta in entrata iniziale a un server backend. Tutti i pacchetti successivi su questa connessione vanno allo stesso endpoint.
  • Un load balancer HTTP configurato per gestire la persistenza delle sessioni basata su cookie inoltra le richieste al server backend specificato dalle informazioni di sessione del cookie.
  • Per le richieste HTTP non persistenti, il load balancer applica i criteri e il peso a ogni richiesta in entrata e specifica un server backend appropriato. Più richieste dallo stesso client potrebbero essere indirizzate a server diversi.
Nota

Per creare un load balancer con un IP riservato, aggiungere questo criterio:
Allow group group_name to manage floating-ips in tenancy

Per informazioni generali sui criteri, consulta la Guida introduttiva ai criteri.

Instradamento sequenziale

Round Robin è il criterio del load balancer predefinito. Questo criterio distribuisce sequenzialmente il traffico in entrata a ciascun server di un elenco di set backend. Dopo che ogni server ha ricevuto una connessione, il load balancer ripete la lista nello stesso ordine.

Round Robin è un semplice algoritmo di bilanciamento del carico. Funziona meglio quando tutti i server backend hanno una capacità simile e il carico di elaborazione richiesto da ogni richiesta non varia.

Numero minimo connessioni

Il criterio Least Connections indirizza il traffico delle richieste non persistenti in entrata verso il server backend con il minor numero di connessioni attive. Questo criterio consente di mantenere una distribuzione uguale delle connessioni attive con i server backend. Come con il criterio round robin, puoi assegnare un peso a ogni server backend e controllare ulteriormente la distribuzione del traffico.

Nota

Nei casi d'uso TCP, una connessione può essere attiva ma non dispone di traffico corrente. Tali connessioni non servono come una buona metrica di carico.

Hash IP

Il criterio hash IP utilizza l'indirizzo IP di origine di una richiesta in entrata come chiave di hashing per instradare il traffico non persistente allo stesso server backend. Il load balancer instrada le richieste dallo stesso client allo stesso server backend a condizione che tale server sia disponibile. Questo criterio rispetta le impostazioni relative al peso del server quando si stabilisce la connessione iniziale.

L'hash IP garantisce che le richieste provenienti da un client particolare vengano sempre indirizzate allo stesso server backend, a condizione che il server backend sia disponibile.

Non è possibile aggiungere un server backend contrassegnato come Backup a un set backend che utilizza il criterio hash IP.

Importante

Più client che si connettono al load balancer tramite un proxy o un router NAT sembrano avere lo stesso indirizzo IP. Se applichi il criterio hash IP al tuo set backend, il load balancer instrada il traffico in base all'indirizzo IP in entrata e invia queste richieste client con proxy allo stesso server backend. Se il pool di client proxy è di grandi dimensioni, le richieste potrebbero inondare un server backend.