Funzionamento di Elastic Load Balancing

Un sistema di bilanciamento del carico accetta il traffico in entrata dai client e indirizza le richieste verso le destinazioni registrate (ad esempio le EC2 istanze) in una o più zone di disponibilità. Il sistema di bilanciamento del carico monitora inoltre lo stato delle destinazioni registrate e garantisce che il traffico venga instradato solo verso quelle integre. Quando il sistema di bilanciamento del carico rileva una destinazione non integra, ne interrompe il traffico in entrata. Riprende quindi l'instradamento del traffico verso la destinazione quando ne rileva nuovamente l'integrità.

Puoi configurare il tuo sistema di bilanciamento del carico affinché accetti il traffico in entrata specificando uno o più listener. Si definisce listener il processo che verifica la presenza di richieste di connessione. È configurato con un protocollo e con un numero di porta per le connessioni dai client al sistema di bilanciamento del carico. Allo stesso modo, è configurato con un protocollo e con un numero di porta per le connessioni dal sistema di bilanciamento del carico alle destinazioni.

Elastic Load Balancing supporta i seguenti tipi di sistemi di bilanciamento del carico:

• Application Load Balancer

• Network Load Balancers

• Gateway Load Balancers

• Classic Load Balancer

Esiste una differenza fondamentale nel modo in cui i tipi di sistema di bilanciamento del carico vengono configurati. Con Application Load Balancer, Network Load Balancer e Gateway Load Balancer le istanze vengono registrate come destinazioni in gruppi di destinazioni verso i quali viene instradato il traffico. Con Classic Load Balancer le istanze vengono registrate direttamente nel sistema di bilanciamento del carico.

Zone di disponibilità e nodi del sistema di bilanciamento del carico

Quando si abilita una zona di disponibilità nel sistema di bilanciamento del carico, Elastic Load Balancing crea un nodo del sistema di bilanciamento del carico nella zona di disponibilità. Se registri le destinazioni in una zona di disponibilità, ma non abiliti la zona, queste destinazioni registrate non sono in grado di ricevere traffico. Il sistema di bilanciamento del carico è più efficace se ogni zona di disponibilità abilitata dispone di almeno una destinazione registrata.

Consigliamo di abilitare più zone di disponibilità per tutti i sistemi di bilanciamento del carico. Tuttavia, con un Application Load Balancer, è obbligatorio abilitare almeno due o più zone di disponibilità. Questa configurazione aiuta a verificare che il sistema di bilanciamento del carico possa continuare a instradare il traffico. Se una zona di disponibilità non è più disponibile o non ha destinazioni integre, il sistema di bilanciamento del carico è in grado di instradare il traffico verso le destinazioni integre in un'altra zona di disponibilità.

Dopo aver disabilitato un'area di disponibilità, le destinazioni in tale zona di disponibilità rimangono registrate con il sistema di bilanciamento del carico. Tuttavia, anche se rimangono registrate, il sistema di bilanciamento del carico non vi instrada alcun traffico.

Bilanciamento del carico su più zone

I nodi del sistema di bilanciamento del carico distribuiscono le richieste dei client alle destinazioni registrate. Se il bilanciamento del carico tra zone è abilitato, ogni nodo del sistema di bilanciamento del carico distribuisce il traffico tra le destinazioni registrate in tutte le zone di disponibilità abilitate. Se il bilanciamento del carico tra zone è disabilitato, ogni nodo del sistema di bilanciamento del carico distribuisce il traffico solo tra le destinazioni registrate nella sua zona di disponibilità.

I seguenti diagrammi illustrano l'effetto del bilanciamento del carico tra zone con round robin come algoritmo di instradamento predefinito. Sono presenti due zone di disponibilità abilitate, con due destinazioni nella zona A e otto nella zona B. I client inviano le richieste, a ciascuna delle quali Amazon Route 53 risponde con l'indirizzo IP di uno dei nodi del sistema di bilanciamento del carico. In base all'algoritmo di instradamento round robin, il traffico viene distribuito in modo tale che ciascun nodo del sistema di bilanciamento del carico riceva il 50% del traffico dai client. Ogni nodo del sistema di bilanciamento del carico distribuisce la sua parte di traffico tra le destinazioni registrate nel relativo ambito.

Se il bilanciamento del carico tra zone è abilitato, ciascuna delle 10 destinazioni riceve il 10% del traffico. Questo perché ogni nodo del sistema di bilanciamento del carico è in grado di instradare il 50% del traffico dei client verso tutte e 10 le destinazioni.

Se il bilanciamento del carico tra zone è disabilitato:

• Ciascuna delle due destinazioni nella zona di disponibilità A riceve il 25% del traffico.

• Ciascuna delle otto destinazioni nella zona di disponibilità B riceve il 6.25% del traffico.

Questo perché ogni nodo del sistema di bilanciamento del carico è in grado di instradare il 50% del traffico dei client solo verso le destinazioni nella sua zona di disponibilità.

Con gli Application Load Balancer, il bilanciamento del carico tra zone è sempre abilitato a livello di sistema di bilanciamento del carico. A livello di gruppo di destinazioni, il bilanciamento del carico tra zone può essere disabilitato. Per ulteriori informazioni, consulta Disattivazione del bilanciamento del carico tra zone nella Guida per l'utente dei sistemi Application Load Balancer.

Con i Network Load Balancer e i Gateway Load Balancer, il bilanciamento del carico tra zone è disabilitato per impostazione predefinita. Dopo aver creato il sistema di bilanciamento del carico, è possibile abilitare o disabilitare il bilanciamento del carico tra zone in qualsiasi momento. Per ulteriori informazioni, consulta Bilanciamento del carico tra zone nella Guida per l'utente di Network Load Balancers.

Quando si crea un Classic Load Balancer, l'impostazione predefinita per il load balancer tra zone dipende dal modo in cui crei il load balancer. Con API oCLI, il bilanciamento del carico tra zone è disabilitato per impostazione predefinita. Con AWS Management Console, l'opzione per abilitare il bilanciamento del carico tra zone è selezionata per impostazione predefinita. Dopo aver creato un Classic Load Balancer, è possibile abilitare o disabilitare il load balancer tra zone in qualsiasi momento. Per ulteriori informazioni, consulta Abilita il bilanciamento del carico tra zone nella Guida per l'utente dei sistemi Classic Load Balancer.

Spostamento zonale

Lo spostamento di zona è una funzionalità di Amazon Application Recovery Controller (ARC) (ARC). Con lo spostamento zonale, è possibile spostare una risorsa di un sistema di bilanciamento del carico da una zona di disponibilità danneggiata con una singola operazione. In questo modo è possibile continuare a operare da altre zone di disponibilità integre in una Regione AWS.

Quando si avvia uno spostamento zonale, il sistema di bilanciamento del carico interrompe l'invio di traffico per la risorsa alla zona di disponibilità danneggiata. ARCcrea immediatamente lo spostamento zonale. Tuttavia, il completamento delle connessioni esistenti e in corso nella zona di disponibilità danneggiata può richiedere un po' di tempo, generalmente fino a qualche minuto. Per ulteriori informazioni, consulta How a zonal shift: controlli di integrità e indirizzi IP zonali nella Amazon Application Recovery Controller (ARC) Developer Guide.

Prima di utilizzare uno spostamento zonale, consulta le seguenti informazioni:

• Lo spostamento di zona non è supportato quando si utilizza un Application Load Balancer con il bilanciamento del carico tra zone attivato. Lo spostamento zonale è supportato quando si utilizza un Network Load Balancer con il bilanciamento del carico tra zone attivato o disattivato.

• Lo spostamento zonale non è supportato quando si utilizza un Application Load Balancer come endpoint per l'acceleratore in AWS Global Accelerator.

• È possibile avviare uno spostamento zonale per uno specifico sistema di bilanciamento del carico solo per una singola zona di disponibilità. Non è possibile avviare uno spostamento zonale per più zone di disponibilità.

• AWS rimuove in modo proattivo gli indirizzi IP del sistema di bilanciamento del carico zonale quando più problemi di infrastruttura influiscono sui serviziDNS. Verificare sempre l'attuale capacità della zona di disponibilità prima di avviare uno spostamento zonale. Se i sistemi di bilanciamento del carico hanno il bilanciamento del carico tra zone disattivato e si utilizza uno spostamento zonale per rimuovere l'indirizzo IP zonale di un sistema di bilanciamento del carico, anche la zona di disponibilità coinvolta nello spostamento zonale perderà capacità di destinazione.

• Quando un Application Load Balancer è una destinazione di un Network Load Balancer, avviare sempre lo spostamento zonale dal Network Load Balancer. Se si avvia uno spostamento zonale dall'Application Load Balancer, il Network Load Balancer non riconoscerà lo spostamento e continuerà a inviare traffico all'Application Load Balancer.

Per ulteriori indicazioni e informazioni, consulta la sezione Best practice with Route 53 ARC zonal shift nella Amazon Application Recovery Controller (ARC) Developer Guide.

Instradamento della richiesta

Prima che un client invii una richiesta al sistema di bilanciamento del carico, risolve il nome di dominio del sistema di bilanciamento del carico utilizzando un server Domain Name System (). DNS L'DNSaccesso è controllato da Amazon, poiché i tuoi sistemi di bilanciamento del carico sono nel amazonaws.com dominio. I DNS server Amazon restituiscono uno o più indirizzi IP al client. Questi sono gli indirizzi IP dei nodi del tuo sistema di bilanciamento del carico. Con i Network Load Balancer, Elastic Load Balancing crea un'interfaccia di rete per ogni zona di disponibilità abilitata e la utilizza per ottenere un indirizzo IP statico. Puoi scegliere di associare un indirizzo IP elastico a ogni interfaccia di rete quando crei il Network Load Balancer.

Man mano che il traffico verso l'applicazione cambia nel tempo, Elastic Load Balancing ridimensiona il sistema di bilanciamento del carico e aggiorna la voce. DNS La DNS voce specifica anche il valore time-to-live (TTL) di 60 secondi. Ciò aiuta a verificare che gli indirizzi IP possano essere rimappati rapidamente in risposta ai cambiamenti del traffico.

Il client determina quale indirizzo IP utilizzare per inviare le richieste al sistema di bilanciamento del carico. Il nodo del sistema di bilanciamento del carico che riceve la richiesta seleziona una destinazione registrata integra e invia la richiesta alla destinazione tramite il proprio indirizzo IP privato.

Per ulteriori informazioni, consulta Routing del traffico verso un ELB load balancer nella Amazon Route 53 Developer Guide.

Algoritmo di instradamento

Con gli Application Load Balancer, il nodo del sistema di bilanciamento del carico che riceve la richiesta utilizza la procedura seguente:

1. Valuta le regole del listener in ordine di priorità per determinare quale regola applicare.

2. Seleziona una destinazione dal gruppo di destinazioni per l'operazione della regola utilizzando l'algoritmo di instradamento configurato per il gruppo di destinazioni. L'algoritmo di instradamento predefinito è quello round robin. L'instradamento avviene in maniera indipendente per ogni gruppo di destinazioni, anche nel caso in cui una destinazione sia registrata con più gruppi.

Con i Network Load Balancer, il nodo del sistema di bilanciamento del carico che riceve la connessione utilizza la procedura seguente:

1. Seleziona una destinazione dal gruppo di destinazioni per la regola predefinita utilizzando un algoritmo hash di flusso. Basa l'algoritmo su:

   • Il protocollo

   • L'indirizzo IP di origine e la porta di origine

   • L'indirizzo IP di destinazione e la porta di destinazione

   • Il numero di sequenza TCP

2. Indirizza ogni singola TCP connessione verso una singola destinazione per tutta la durata della connessione. Le TCP connessioni provenienti da un client hanno porte di origine e numeri di sequenza diversi e possono essere instradate verso destinazioni diverse.

Con i Classic Load Balancer, il nodo del sistema di bilanciamento del carico che riceve la richiesta seleziona un'istanza registrata come segue:

• Utilizza l'algoritmo di routing round robin per gli ascoltatori TCP

• Utilizza l'algoritmo di routing delle richieste meno in sospeso per gli ascoltatori e HTTP HTTPS

HTTPconnessioni

I Classic Load Balancer utilizzano le connessioni pre-aperte, ma gli Application Load Balancer non le utilizzano. Sia i Classic Load Balancer che gli Application Load Balancer utilizzano la connessione a multiplexing. Ciò significa che le richieste di più client su più connessioni front-end possono essere instradate a una determinata destinazione tramite una singola connessione back-end. La connessione a multiplexing migliora la latenza e riduce il carico per le tue applicazioni. Per evitare il multiplexing delle connessioni, disattiva le HTTP keep-alive intestazioni impostando l'Connection: closeintestazione nelle risposte. HTTP

Application Load Balancer e Classic Load Balancer supportano connessioni pipeline su connessioni front-end. HTTP Non supportano connessioni pipeline su backend. HTTP

Gli Application Load Balancer supportano i seguenti metodi di HTTP richiesta:GET,,,HEAD, POSTPUT, DELETE e. OPTIONS PATCH

Gli Application Load Balancer supportano i seguenti protocolli sulle connessioni front-end: HTTP /0.9, /1.0, /1.1 e /2. HTTP HTTP HTTP È possibile utilizzare HTTP /2 solo con i HTTPS listener e inviare fino a 128 richieste in parallelo utilizzando una connessione HTTP /2. Gli Application Load Balancer supportano anche gli aggiornamenti delle connessioni da a. HTTP WebSockets Tuttavia, in caso di aggiornamento della connessione, le regole e le AWS WAF integrazioni di routing del listener Application Load Balancer non sono più valide.

Per impostazione predefinita, gli Application Load Balancer utilizzano HTTP /1.1 sulle connessioni di backend (bilanciamento del carico verso la destinazione registrata). Tuttavia, è possibile utilizzare la versione del protocollo per inviare la richiesta alle destinazioni utilizzando /2 o g. HTTP RPC Per ulteriori informazioni, consulta Versioni del protocollo. L'intestazione keep-alive è supportata per le connessioni back-end per impostazione predefinita. Per le richieste HTTP /1.0 provenienti da client che non dispongono di un'intestazione host, il load balancer genera un'intestazione host per le richieste HTTP /1.1 inviate sulle connessioni di backend. L'intestazione host contiene il nome del load balancer. DNS

I sistemi Classic Load Balancer supportano i seguenti protocolli sulle connessioni front-end (da client a load balancer): /0.9, /1.0 e /1.1. HTTP HTTP HTTP Utilizzano HTTP /1.1 sulle connessioni di backend (bilanciamento del carico rispetto alla destinazione registrata). L'intestazione keep-alive è supportata per le connessioni back-end per impostazione predefinita. Per le richieste HTTP /1.0 provenienti da client che non dispongono di un'intestazione host, il load balancer genera un'intestazione host per le richieste HTTP /1.1 inviate sulle connessioni di backend. L'intestazione host contiene l'indirizzo IP del nodo del sistema di bilanciamento del carico.

HTTPintestazioni

Application Load Balancer e Classic Load Balancer aggiungono automaticamente intestazioni X-Forwarded-For, X-Forwarded-Proto e X-Forwarded-Port alla richiesta.

Gli Application Load Balancer convertono i nomi host nelle intestazioni degli HTTP host in lettere minuscole prima di inviarli alle destinazioni.

Per le connessioni front-end che utilizzano HTTP /2, i nomi delle intestazioni sono in minuscolo. Prima che la richiesta venga inviata alla destinazione utilizzando HTTP /1.1, i seguenti nomi di intestazione vengono convertiti in maiuscole e minuscole: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade e Connection. Tutti gli altri nomi di intestazione sono in lettere minuscole.

Gli Application Load Balancer e i Classic Load Balancer accettano l'intestazione della connessione della richiesta in entrata del client dopo avere eseguito il proxy della risposta di nuovo al client.

Quando Application Load Balancer e Classic Load Balancer che utilizzano HTTP /1.1 ricevono un'intestazione Expect: 100-Continue, rispondono immediatamente con HTTP/1.1 100 Continue senza testare l'intestazione della lunghezza del contenuto. L'intestazione della richiesta Expect: 100-Continue non viene inoltrata alle destinazioni.

Quando si utilizza HTTP /2, Application Load Balancers non supporta l'intestazione Expect: 100-Continue delle richieste dei client. L'Application Load Balancer non risponderà con HTTP/2 100 Continue né inoltrerà questa intestazione alle sue destinazioni.

HTTPlimiti di intestazione

I seguenti limiti di dimensione per gli Application Load Balancer sono limiti rigidi che non possono essere modificati:

• Riga di richiesta: 16 K

• Intestazione singola: 16 K

• Intestazione della risposta intera: 32 K

• Intestazione della richiesta intera: 64 K

Schema del sistema di bilanciamento del carico

Quando crei un sistema di bilanciamento del carico, devi scegliere se renderlo un sistema di bilanciamento del carico interno o connesso a Internet.

I nodi di un load balancer con connessione Internet dispongono di indirizzi IP pubblici. Il DNS nome di un sistema di bilanciamento del carico connesso a Internet è risolvibile pubblicamente negli indirizzi IP pubblici dei nodi. Di conseguenza, i bilanciatori del carico connessi a Internet possono instradare le richieste dai client tramite Internet.

I nodi di un load balancer interno dispongono solo di indirizzi IP privati. Il DNS nome di un load balancer interno è risolvibile pubblicamente negli indirizzi IP privati dei nodi. Pertanto, i sistemi di bilanciamento del carico interni possono inoltrare solo le richieste provenienti dai client con accesso al sistema di bilanciamento del carico per il VPC sistema.

Entrambi i sistemi di bilanciamento del carico interni e connessi a Internet instradano le richieste alle destinazioni tramite indirizzi IP privati. Pertanto, le tue destinazioni non necessitano di indirizzi IP pubblici per ricevere le richieste da un sistema di bilanciamento del carico interno o connesso a Internet.

Se la tua applicazione dispone di più livelli, puoi progettare un'architettura che utilizzi sia i bilanciamenti del carico interni che quelli connessi a Internet. Ad esempio, questo vale se l'applicazione utilizza server Web che devono essere connessi a Internet e server di applicazioni connessi solo ai server Web. Crea un load balancer connesso a Internet e registra il server Web insieme ad esso. Crea un sistema di bilanciamento del carico interno e registra il server di applicazioni insieme ad esso. I server Web ricevono le richieste dal sistema di bilanciamento del carico connesso a Internet e inviano le richieste per i server di applicazioni al sistema di bilanciamento del carico interno. I server di applicazioni ricevono le richieste dal sistema di bilanciamento del carico interno.

Tipi di indirizzi IP

Il tipo di indirizzo IP specificato per il sistema di bilanciamento del carico determina il modo in cui i client possono comunicare con il sistema di bilanciamento del carico.

• IPv4solo: i client comunicano utilizzando indirizzi pubblici e privatiIPv4. Le sottoreti selezionate per il sistema di bilanciamento del carico devono avere IPv4 intervalli di indirizzi.

• Dualstack: i client comunicano utilizzando indirizzi e indirizzi pubblici e privati. IPv4 IPv6 Le sottoreti selezionate per il sistema di bilanciamento del carico devono avere intervalli di indirizzi. IPv4 IPv6

• Dualstack senza pubblicoIPv4: i client comunicano utilizzando indirizzi pubblici e privati e indirizzi privati. IPv6 IPv4 Le sottoreti selezionate per il sistema di bilanciamento del carico devono avere intervalli di indirizzi. IPv4 IPv6 Questa opzione non è supportata dallo schema di internal bilanciamento del carico.

La tabella seguente descrive i tipi di indirizzi IP supportati per ogni tipo di bilanciamento del carico.

Nuovo tipo di load balancer	IPv4solo	Dualstack	Dualstack senza pubblico IPv4
Application Load Balancer	Sì	Sì	Sì
Network Load Balancer	Sì	Sì	No
Gateway Load Balancer	Sì	Sì	No
Classic Load Balancer	Sì	No	No

Il tipo di indirizzo IP specificato per il gruppo target determina il modo in cui il sistema di bilanciamento del carico può comunicare con le destinazioni.

• IPv4solo: il load balancer comunica utilizzando indirizzi privati. IPv4 È necessario registrare destinazioni con IPv4 indirizzi appartenenti a un gruppo IPv4 target.

• IPv6solo: il sistema di bilanciamento del carico comunica tramite IPv6 indirizzi. È necessario registrare destinazioni con IPv6 indirizzi appartenenti a un gruppo IPv6 target. Il gruppo target deve essere utilizzato con un sistema di bilanciamento del carico dualstack.

La tabella seguente descrive i tipi di indirizzi IP supportati per ogni protocollo del gruppo di destinazione.

Protocollo del gruppo di destinazione	IPv4solo	IPv6solo
HTTPe HTTPS	Sì	Sì
TCP	Sì	Sì
TLS	Sì	Sì
UDPe TCP _ UDP	Sì	Sì
GENEVE	-	-

Rete MTU per il tuo sistema di bilanciamento del carico

L'unità di trasmissione massima (MTU) determina la dimensione, in byte, del pacchetto più grande che può essere inviato sulla rete. Maggiore è la dimensione MTU di una connessione, maggiore è la quantità di dati che possono essere trasmessi in un singolo pacchetto. I pacchetti Ethernet sono costituiti dal pacchetto o dai dati effettivi che invii e le informazioni sul sovraccarico della rete circostante. Il traffico inviato tramite un gateway Internet ha un valore MTU di 1500. Questo significa che, se un pacchetto ha una dimensione superiore a 1.500 byte, viene frammentato per essere inviato in più pacchetti, oppure viene eliminato se nell'intestazione IP è impostato Don't Fragment.

La MTU dimensione dei nodi di bilanciamento del carico non è configurabile. I jumbo frame (9001MTU) sono standard tra i nodi di bilanciamento del carico per Application Load Balancer, Network Load Balancer e Classic Load Balancer. MTUI Gateway Load Balancer supportano 8500. Per ulteriori informazioni, consulta Maximum transmission unit (MTU) nella Guida per l'utente dei Gateway Load Balancers.

Il percorso MTU è la dimensione massima del pacchetto supportata nel percorso tra l'host di origine e l'host ricevente. Path MTU Discovery (PMTUD) viene utilizzato per determinare il percorso MTU tra due dispositivi. Path MTU Discovery è particolarmente importante se il client o la destinazione non supportano i jumbo frame.

Quando un host invia un pacchetto più grande di quello MTU dell'host ricevente o più grande di quello MTU di un dispositivo lungo il percorso, l'host o il dispositivo ricevente elimina il pacchetto, e quindi restituisce il seguente ICMP messaggio:. Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4) Questo indica all'host trasmittente di dividere il payload in più pacchetti più piccoli e di trasmetterli di nuovo.

Se i pacchetti più grandi delle MTU dimensioni dell'interfaccia client o di destinazione continuano a essere eliminati, è probabile che Path MTU Discovery (PMTUD) non funzioni. Per evitare ciò, assicuratevi che Path MTU Discovery funzioni dall'inizio alla fine e di aver abilitato i jumbo frame su client e target. Per ulteriori informazioni su Path MTU Discovery e sull'abilitazione dei jumbo frame, consulta Path MTU Discovery nella Amazon EC2 User Guide.