Come posso distribuire un cluster haproxy scalabile e affidabile su Amazon EC2?

Abbiamo bisogno di alcune funzionalità più avanzate di quelle fornite da ELB (principalmente l'ispezione L7), ma non è ovvio come gestire cose come il battito cardiaco e l'alta disponibilità con qualcosa come haproxy usando EC2. C'è un'alta probabilità che avremmo bisogno di 3 o più nodi haproxy nel cluster, quindi il semplice battito cardiaco tra due nodi non funzionerà.

Sembra che avere un livello di battito cardiaco di fronte ai nodi haproxy sarebbe la strada da percorrere, possibilmente usando IPVS, ma gestendo le modifiche alla configurazione mentre cambia il cluster EC2 (o tramite modifiche intenzionali, come l'espansione o involontario, come perdere un Nodo EC2) sembra non banale.

Preferibilmente la soluzione si estenderebbe su almeno due zone di disponibilità.

In risposta a Qs: No, le sessioni non sono appiccicose. E sì, avremo bisogno di SSL, ma in teoria potrebbe essere gestito completamente da un'altra configurazione: siamo in grado di indirizzare il traffico SSL verso una posizione diversa rispetto al traffico non SSL.

OK, non ho mai creato una soluzione di bilanciamento del carico AWS con traffico sui livelli di SmugMug da solo, ma solo pensando alla teoria e ai servizi di AWS, mi vengono in mente un paio di idee.

Alla domanda originale mancano alcune cose che tendono a influire sul design del bilanciamento del carico:

1. Sessioni appiccicose o no? È molto preferibile non usare la sessione appiccicosa e lasciare che tutti i bilanciatori del carico (LB) utilizzino il round robin (RR) o la selezione casuale del backend. Le selezioni RR o di backend casuali sono semplici, scalabili e forniscono una distribuzione uniforme del carico in tutte le circostanze.
2. SSL o no? Se SSL è in uso o meno e su quale percentuale di richieste, generalmente ha un impatto sulla progettazione del bilanciamento del carico. Spesso è preferibile terminare SSL il più presto possibile, per semplificare la gestione dei certificati e mantenere il carico della CPU SSL lontano dai server delle applicazioni web.

Sto rispondendo dal punto di vista di come mantenere lo strato di bilanciamento del carico stesso altamente disponibile. Mantenere i server delle applicazioni HA è appena fatto con i controlli di integrità integrati nei sistemi di bilanciamento del carico L7.

OK, un paio di idee che dovrebbero funzionare:

1) "Il modo AWS":

• Il primo strato, nella parte anteriore, utilizza ELB in modalità L4 (TCP / IP).
• Secondo livello, utilizzare le istanze EC2 con il bilanciamento del carico L7 scelto (nginx, HAProxy, Apache ecc.).

Vantaggi / idea: i bilanciatori di carico L7 possono essere AMI EC2 abbastanza semplici, tutti clonati dalla stessa AMI e utilizzando la stessa configurazione. Pertanto, gli strumenti di Amazon sono in grado di gestire tutte le esigenze di HA: ELB monitora i sistemi di bilanciamento del carico L7. Se un L7 LB muore o non risponde, ELB e Cloudwatch generano insieme automaticamente una nuova istanza e la portano nel pool ELB.

2) "Il round robin DNS con modalità di monitoraggio:"

• Utilizzare il round robin DNS di base per ottenere una distribuzione del carico a grana grossa su un paio di indirizzi IP. Diciamo solo che pubblichi 3 indirizzi IP per il tuo sito.
• Ognuno di questi 3 IP è un indirizzo IP elastico AWS (EIA), associato a un'istanza EC2, con un bilanciamento del carico L7 a scelta.
• Se un LB EC7 L7 si spegne, un agente utente (browser) conforme dovrebbe semplicemente utilizzare uno degli altri IP .
• Configurare un server di monitoraggio esterno. Monitorare ciascuno dei 3 EIP. Se uno non risponde, utilizzare gli strumenti della riga di comando di AWS e alcuni script per spostare l'EIP su un'altra istanza EC2.

Vantaggi / idea: gli user agent conformi dovrebbero passare automaticamente a un altro indirizzo IP se uno non risponde. Pertanto, in caso di guasto, solo 1/3 dei tuoi utenti dovrebbero essere interessati, e la maggior parte di questi non dovrebbe notare nulla dal momento che il loro UA fallisce silenziosamente su un altro IP. E la tua scatola di monitoraggio esterna noterà che un PEI non risponde e correggerà la situazione in un paio di minuti.

3) DNS RR a coppie di server HA:

Fondamentalmente questo è il suggerimento di Don del semplice battito cardiaco tra una coppia di server, ma semplificato per più indirizzi IP.

• Utilizzando DNS RR, pubblicare un numero di indirizzi IP per il servizio. Seguendo l'esempio sopra, diciamo solo che pubblichi 3 IP.
• Ognuno di questi IP va su una coppia di server EC2, quindi in totale 6 istanze EC2.
• Ognuna di queste coppie utilizza Heartbeat o un'altra soluzione HA insieme agli strumenti AWS per mantenere attivo 1 indirizzo IP, in una configurazione attiva / passiva.
• Su ogni istanza EC2 è installato il bilanciamento del carico L7 scelto.

Vantaggi / idea: nell'ambiente completamente virtualizzato di AWS non è in realtà facile ragionare sui servizi L4 e sulle modalità di failover. Semplificando su una coppia di server identici mantenendo attivo solo 1 indirizzo IP, diventa più semplice ragionare e testare.

Conclusione: Ancora una volta, in realtà non ho provato nulla di tutto questo in produzione. Proprio dal mio istinto, l'opzione 1 con ELB in modalità L4 e istanze EC2 autogestite come L7 LBs sembrano più in linea con lo spirito della piattaforma AWS e dove Amazon ha maggiori probabilità di investire ed espandersi in seguito. Questa sarebbe probabilmente la mia prima scelta.

Se non stai facendo sessioni appiccicose, o se stai usando lo stile tomcat / apache (aggiungi l'ID nodo a sessionid, al contrario dello stato di memorizzazione nell'LB), allora userei ELB davanti a un gruppo di haproxies. ELB ha un controllo di salute integrato, quindi puoi farlo monitorare i problemi e eliminare quelli fuori dal pool. Molto meno da configurare rispetto al failover del battito cardiaco.

Per quanto riguarda la propagazione dei cambiamenti, non ho un'ottima risposta. Puppet è ottimo per la configurazione iniziale e l'implementazione delle modifiche, ma per l'aggiunta / rimozione di nodi si tende a desiderare una risposta più rapida rispetto al suo intervallo di polling di 30 minuti.

Non l'ho usato da solo, ma ho visto molte persone menzionare l'uso di marionette per gestire questo tipo di problemi su EC2