È possibile utilizzare più servizi di bilanciamento del carico per reindirizzare il traffico ai miei server applicazioni?

Sono nuovo nel bilanciamento del carico e mi chiedo se sia possibile utilizzare più bilanciatori del carico per reindirizzare il traffico verso i miei server delle applicazioni. Non capisco davvero come si possa fare. Un nome di dominio non dovrebbe corrispondere uno a uno con l'indirizzo IP di un determinato server (in questo caso l'IP di un bilanciamento del carico)? Se ciascun server di bilanciamento del carico ha un IP diverso, come può essere ricevuta la richiesta da entrambi i bilanciatori di carico (o da 10 bilanciatori di carico o 50 o 100)?

L'uso del DNS round robin non è eccezionale per l'alta disponibilità: se un server non è in linea, i client proveranno comunque a connettersi ad esso e aspetteranno un timeout.

Ci sono altri modi per raggiungere questo obiettivo.
1) Bilanciatori di carico attivi / passivi
Fondamentalmente un bilanciamento del carico gestisce tutto il traffico per un indirizzo IP.
Se quel bilanciamento scende, il nodo passivo si inserisce e assume l'IP.
Tieni presente che i bilanciamento del carico sono praticamente solo inoltri di traffico, quindi per i siti di piccole e medie dimensioni questo può funzionare bene.

2) Bilanciatori di carico attivo / attivo
Lo stesso IP di traffico è configurato su entrambi (o molti altri) bilanciatori di carico.
Il traffico in entrata viene inviato a tutti i servizi di bilanciamento del carico, ma un algoritmo sceglie quale bilanciamento deve rispondere, tutti gli altri eliminano tale traffico.
Un modo semplice di pensarci, hai due bilanciatori del carico:
quando l'IP richiedente termina con un numero pari, il bilanciamento del carico A risponde, altrimenti il ​​bilanciamento del carico B risponde.

Ovviamente la tua infrastruttura deve supportare questo e c'è un overhead dovuto al traffico che viene inviato ma scartato.
Maggiori informazioni, ad esempio qui: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

L'alta disponibilità con i servizi di bilanciamento del carico viene comunemente implementata utilizzando un protocollo di indirizzo IP virtuale (VIP) che consente a diversi host (ovvero sistemi di bilanciamento del carico) di rispondere a un indirizzo IP comune in uno dei diversi modi possibili (variazioni su attivo / passivo, attivo / attivo) .

Esistono un buon numero di questi protocolli, quelli che ho visto di più con i normali sistemi di bilanciamento del carico sono VRRP e NLB (così come molti protocolli blackbox anonimi negli apparecchi). Ad esempio, espandendosi a router e firewall si possono incontrare CARP , HRSP , GLSP .

Questa strategia ha una serie di vantaggi rispetto al bilanciamento del carico DNS, che è una strategia più semplice (e che viene trattata in un'altra risposta).

Il bilanciamento del carico DNS è gravato, ad esempio, da:

• il lento turnover dei meccanismi di memorizzazione nella cache DNS
• algoritmi di bilanciamento del carico limitato (in genere solo round robin)
• l'outsourcing della decisione di bilanciamento del carico al cliente (mediante memorizzazione nella cache del record DNS)
• Drenaggio lento delle code di servizio quando un server (ovvero un bilanciamento del carico) viene rimosso dalla rotazione (basato su TTL di record DNS gestiti da ISP e client )
• Failover lento in caso di errore del bilanciamento del carico

Utilizzando un protocollo IP virtuale per HA si può scegliere di ottenere ad esempio:

• Scelta dell'algoritmo di bilanciamento del carico tra i bilanciatori di carico
• Decisioni di bilanciamento del carico incentrate sul server (affascinanti per esempio misure e routing basati sull'integrità del servizio)
• Svuotamento più rapido delle code di servizio quando un bilanciamento del carico viene tolto dalla rotazione.
• Failover istantaneo in caso di errore del bilanciamento del carico

Solo tu sai quale strategia e protocollo si adattano meglio al tuo scenario.

I requisiti: avere una soluzione pratica che funzioni per il cloud o qualsiasi tipo di ambiente in cui nessun accesso ai bilanciatori del carico hardware, ai protocolli BGP e tutto il resto.

Il numero di richiesta di reddito di un'applicazione non è noto ma dovrebbe essere abbastanza elevato da soddisfare una maggiore aspettativa di carico senza timori.

Troviamo un'applicazione con natura simile di carico, ad esempio archivio di registrazione e app di ricerca. Ne ho trovato uno .

Ciò che vogliono:

1. Bilanciare il carico tra i collettori
2. Offri tolleranza agli errori, permettendoci di continuare a inserire dati se uno dei collezionisti muore o riscontra problemi
3. Ridimensiona orizzontalmente con la crescita dei nostri volumi di log

Cosa hanno provato e imparato su ELB:

1. Non funziona come previsto
2. Problemi di latenza dovuti all'aumento del carico
3. Funzione di monitoraggio insufficiente
4. Troppe limitazioni (numero di porte e protocolli aperti)

Perché hanno scelto con Route53:

1. "Il round robin è un bilanciamento del carico piuttosto semplice, ma funziona bene per noi dal punto di vista dell'efficienza"
2. "Sfruttiamo i controlli di integrità del failover di Route 53".
3. "Se c'è un problema con un collezionista, Route 53 lo mette automaticamente fuori servizio; i nostri clienti non vedranno alcun impatto."
4. Nessun pre-riscaldamento necessario con Route 53

La Route 53 si è rivelata il modo migliore per Loggly di sfruttare i nostri collezionisti ad alte prestazioni dati i nostri enormi volumi di tronchi, le variazioni imprevedibili e la costante crescita della nostra attività. Si allinea con gli scopi principali dei collezionisti: raccogliere dati alla velocità della linea di rete senza perdite e ci consente di beneficiare dell'elasticità di tutti i servizi AWS che utilizziamo in Loggly.

Questo esempio particolare mostra che in alcuni scenari (raccoglitore di registri, servizio di annunci o simili) il bilanciamento del carico è ridondante e la "soluzione di round robin per il controllo dello stato del DNS" svolge egregiamente il suo lavoro.

Vediamo cosa dice AWS in merito al failover DNS:

Con il failover DNS, Route 53 può rilevare un'interruzione del sito Web e reindirizzare gli utenti finali verso posizioni alternative o di backup specificate. Il failover DNS di Route 53 si basa su controlli di integrità, che effettuano regolarmente richieste Internet agli endpoint delle applicazioni da più posizioni in tutto il mondo per determinare se ciascun endpoint dell'applicazione è attivo o inattivo.

Questa tecnica rende anche ELB (non richiesto, solo per una nota) più robusto, ancora una volta si basa su RR + Health Check:

Il failover DNS di Route 53 gestisce tutti questi scenari di errore integrandosi con ELB dietro le quinte. Una volta abilitato, Route 53 configura e gestisce automaticamente i controlli di integrità per i singoli nodi ELB.

Vediamo ora come funziona dietro la scena. La domanda ovvia è come gestire la memorizzazione nella cache DNS:

Tuttavia, la memorizzazione nella cache DNS può ancora essere un problema qui (vedere il nostro post precedente in cui è trattato il problema della "coda lunga") se TTL non è rispettato da tutti i livelli tra il client e Route 53. È quindi possibile applicare una tecnica di "busting della cache": invia una richiesta a un dominio univoco

("http://<unique-id>.<your-domain>") 

e definire una risorsa jolly

Record "*.<your-domain>" to match it.

L'Algolia ha introdotto la "strategia di riprova del cliente" che funziona abbastanza bene se il tuo cliente (JS nel tuo caso) è in grado di gestirlo:

Abbiamo finito per implementare una strategia di riprova di base nei nostri client API. Ogni client API è stato sviluppato per poter accedere a tre macchine diverse. Tre diversi record DNS rappresentavano ciascun utente: USERIDID-1.algolia.io, USERID-2.algolia.io eUSERID-3.algolia.io. La nostra prima implementazione è stata quella di selezionare casualmente uno dei record e quindi riprovare con uno diverso in caso di errore.