Come realizzare bilanciatori di carico ridondanti?

Comprendo che lo scopo dei sistemi di bilanciamento del carico è di bilanciare il carico tra i server e tenere traccia dell'integrità dell'istanza, ecc. Ma cosa succede se il bilanciamento del carico stesso fallisce? Come si impostano i sistemi di bilanciamento del carico ridondanti? (bilanciamento del carico bilanciamento del carico?)

Potrei vedere come i controlli di integrità del DNS potrebbero essere utili, ma ci sono ovviamente importanti problemi di latenza, non è vero?

Ciò presuppone che non si stiano utilizzando servizi di terze parti come AWS ELB o simili. Cosa fare se stai usando solo dire Nginx?

Esistono un paio di modi per ottenere l'HA (elevata disponibilità) di un servizio di bilanciamento del carico - o per quanto riguarda qualsiasi servizio. Supponiamo che tu abbia due macchine, con indirizzi IP:

• 192.168.100.101
• 192.168.100.102

Gli utenti si connettono a un IP, quindi quello che vuoi fare è separare l'IP dalla casella specifica, ad esempio creare un IP virtuale. Tale IP sarà 192.168.100.100.

Ora puoi scegliere il servizio HA che si occuperà del failover / failback automatico dell'indirizzo IP. Alcuni dei servizi più semplici per unix sono (u) carpe e keepalived, alcuni dei più complessi sono ad esempio RedHat Cluster Suite o Pacemaker.

Prendiamo come esempio keepalived - due servizi keepalived - ciascuno in esecuzione sulla propria casella - e comunicano insieme. Quella comunicazione è spesso chiamata battito cardiaco.

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

Se un keepalived smette di rispondere (uno dei servizi si interrompe per qualsiasi motivo o la casella rimbalza o si spegne) - keepalived su un'altra casella noterà battiti cardiaci persi e presumerà che l'altro nodo sia morto e intraprenderà azioni di failover. Quell'azione nel nostro caso farà apparire l'IP mobile.

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

Il caso peggiore che può accadere in questo caso è la perdita di sessioni per i client, ma saranno in grado di riconnettersi. Se si desidera evitare ciò, due bilanciatori del carico devono essere in grado di sincronizzare i dati della sessione tra loro e, se possono farlo, gli utenti non noteranno nulla, tranne forse un breve ritardo.

Un altro inconveniente di questa configurazione è split brain: quando entrambe le caselle sono online ma il collegamento è interrotto ed entrambe le caselle visualizzano lo stesso IP. Questo problema viene spesso risolto tramite un qualche tipo di meccanismo di recinzione (prenotazione SCSI, riavvio IPMI, interruzione dell'alimentazione della PDU intelligente, ...) o un numero dispari di nodi che richiedono la maggior parte dei membri del cluster per essere attivi per l'avvio del servizio.

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

Software di gestione dei cluster più complessi (come Pacemaker) possono spostare l'intero servizio (ad es .: fermarlo su un nodo e avviarlo su un altro) - e questo è il modo in cui è possibile ottenere HA per servizi come database.

Un altro modo possibile - se si controllano i router vicino ai sistemi di bilanciamento del carico, è utilizzare ECMP. Questo approccio consente inoltre di ridimensionare in modo orizzontale i bilanciatori di carico. Funziona con ciascuna delle due caselle che parlano BGP con il / i router / i. Ogni casella deve pubblicizzare l'IP virtuale (192.168.100.100) e il router caricherà il traffico di bilanciamento tramite ECMP. Se una macchina muore, interromperà la pubblicità di VIP, che a sua volta impedirà ai router di inviare traffico ad essa. L'unica cosa di cui devi occuparti in questa configurazione è interrompere la pubblicità IP se il bilanciamento del carico stesso muore.

L'uso di Nginx come bilanciamento del carico dovrebbe consentire di seguire il reindirizzamento dettagliato in questo post modificando la configurazione per rilevare un timeout di mancata risposta:

Bilanciamento del carico con failover automatico nginx

In teoria, se si dispone di un ambiente HA, più bilanciatori del carico in cluster dovrebbero consentire la manutenzione del servizio in caso di guasto.

Spero che sia di aiuto.

I sistemi di bilanciamento del carico hardware supportano da anni configurazioni "attivo / passivo" o "attivo / attivo", in entrambi i casi vengono quindi impostati in parallelo da una prospettiva di livello 1/2 ... attivo / passivo utilizza meccanismi di monitoraggio / keepalive come descritto , attivo / attivo può essere implementato in numerosi modi. Per apparire come un singolo IP sul frontend, due o più bilanciatori potrebbero, purché siano tutti / entrambi in linea, fare cose come:

• rispondere selettivamente alle richieste ARP all'IP condiviso in base a un indirizzo MAC o IP di origine quando i client si trovano sulla stessa rete
• negoziare tra loro chi gestisce il traffico di una determinata nuova connessione TCP
• lasciare che il traffico di livello 3-7 duplicato o errato avvenga in modo incosciente e fare affidamento sugli stack TCP client / router per risolverlo

Quindi cambia la modalità per accettare tutto o più traffico quando si perde la comunicazione con il dispositivo / a partner.

sul lato backend:

• ciascuno dei bilanciatori potrebbe, durante il normale funzionamento, utilizzare solo un determinato sotto-pool di server applicazioni
• oppure, richieste duplicate potrebbero essere semplicemente generate anche qui ...
• oppure, la negoziazione tra bilanciatori potrebbe essere fatta