Single Point of Failure sul ridimensionamento delle applicazioni su AWS

Question

Abbiamo un'applicazione basata-Rails , infrastucture distribuzione si lega a AWS. schema corrente inclusi i seguenti livelli:

• di bilanciamento del carico (HAProxy)
• Rails-applicazione (EC2) x2
banca dati
• mysqld (EC2 master-slave)
• Redis, DelayedJob processi in background
• Wowza Media Server (EC2)
• S3 risorse di storage (dati condivisi)

Esistono 3 SPF: bilanciamento del carico, database, media server.

Le mie domande sono sulla ridondanza, come posso ridurre SPF:

1. di bilanciamento del carico. Abbiamo un piano per impostare il bilanciamento del carico secondario, ma il nome di dominio è sempre lo stesso. DNS A/AAAA roundrobin failover buona soluzione in tal caso? Il bilanciamento del carico AWS è buono da usare?
2. È MMM (Multi-Master Replication Manager) affidabile? Come funziona con Rails (leggi/scrivi su host indipendenti)?
3. Wowza media server, esistono soluzioni HA ben note con cui lavorare?

Answer 1

Mi piacciono queste domande perché sembrano sempre così semplici da rispondere quando in realtà non lo sono.

Per i principianti, il tuo SP2 BIGGEST è che tutto è su Amazon. Adoro AWS per molte ragioni, ma in tutte le situazioni in cui hai bisogno di reale disponibilità, ti stai essenzialmente prendendo in giro facendo affidamento su di loro al 100%. Quindi il tuo primo piano dovrebbe essere quello di distribuire i tuoi servizi a più di 1 fornitore (cloud, VPS o dedicato).

Voglio farti una domanda: se AWS va giù, quanto tempo/può/vorrà farti notare e poi fare qualcosa al riguardo, e quanto velocemente hai bisogno che i tuoi servizi siano di nuovo attivi e funzionanti ?

Il motivo che mi chiedo è questo: DNS bilanciamento del carico di record/AAAA A è una soluzione meravigliosa, purtroppo non è possibile impostare i pesi o priorità, come si può con i record SRV/MX. Ciò significa che se AWS diventa completamente non disponibile, dovrai effettuare rapidamente una modifica DNS per rimuovere l'IP. Che CAN essere automatizzato se il provider DNS ha un'API che lo consente. D'altra parte, il caching DNS viene eseguito in così tanti posti che potrebbe non valere la pena di effettuare il cambio DNS, il che significa che avrai una disponibilità dal 50% al 100% se 1 IP non è disponibile (supponendo che tu abbia 2 record A), perché alcuni browser sono in grado di provare il 2 ° IP se il primo non funziona.

A mio parere, considerando l'eccellente tempo di attività di AWS, non sarà impeccabile assegnare 2 diversi IP (su 2 provider diversi) al dominio. Penso che sia meglio che avere una disponibilità dello 0% quando 1 IP non funziona, ma non c'è ancora gioia nel perdere il 50% delle richieste.

È possibile disporre di 2 bilanciatori di carico su ciascun provider e inoltrare richieste all'altra provider se determinate istanze/server non sono disponibili. In altre parole, sono necessari solo load balancer funzionali presso ENTRAMBI i provider e server/istanze funzionali presso UN provider. Assicurati di selezionare un provider alternativo che non abbia troppa latenza in AWS;)

MMM è anche un ottimo strumento, ma non è correlato a Rails in alcun modo. Personalmente preferisco posizionare un bilanciatore del carico di fronte a tutti i miei server Database e lasciare che gestiscano chi riceve richieste ecc. Dal momento che i dati su un server di database sono così importanti, di solito è meglio avere un aspetto umano e assicurarci tutto è OK quando c'è un problema, invece di lasciare che uno strumento gestisca la sua disponibilità, configurazione, ecc. MMM funziona in molte situazioni, forse dovresti provarlo e vedere se risponde alle tue esigenze. Non posso dire niente di male a riguardo.

Non ho alcuna familiarità con il server multimediale Wowza, ma una rapida ricerca ha spiegato alcune cose. Poiché Wowza utilizza RTSP (UDP e TCP), HAProxy è NON una soluzione come solo TCP. Al contrario, Keepalived può eseguire il bilanciamento del carico UDP (utilizza IVPS/LVS). In effetti, Keepalived dovrebbe essere utilizzato anche per il bilanciamento del carico dello slave del database se si hanno richieste lunghe.

Un'ultima nota, ci sono molti modi per "roll your own" servizi simili a AWS come l'archiviazione S3. Se vuoi evitare di avere SPF ma hai ancora bisogno delle stesse funzionalità dei tuoi servizi AWS, dovresti controllare le varianti open source, come Eucalyptus/Cloud.com/Openstack/GlusterFS. C'è un sacco di lavoro nella creazione di tutte queste cose, ma sarai felice il giorno in cui puoi dire: "quindi, cosa succederebbe se il fornitore X fosse inattivo, che Y potesse subentrare".

Answer 2

Ecco alcuni suggerimenti:

1) di bilanciamento del carico: creare due istanze ha_proxy con il vostro livello di applicazione della conoscenza bilanciamento del carico e la possibilità di creare automaticamente una nuova istanza su richiesta. Collega Amazon Elastic Load Balancing di fronte a loro con i controlli di integrità per aggirare un singolo errore ha_proxy. Mescolare dinamicamente in nuove istanze ha_proxy quando si fallisce.

2) Database: non penso che ci sia un modo per gestire il failover automatico del tuo primario in MySQL, ma se si introduce un livello per leggere da repliche e scrivere sul primario si può essere in grado di mantenere la sola lettura funzionalità su se un Primario è inattivo.

3) Wowza: Si dovrebbe essere in grado di bilanciare il carico del più istanze Wowza dietro il vostro livello di ha_proxy w/controlli sanitari in modo da un singolo guasto Wowza non disabilitare streaming media

Answer 3

A Scalarium abbiamo una soluzione che riduce SPF drammaticamente, si può vedere un grafico a informazioni Rails in the Cloud a pagina 12.

1. si utilizza l'Amazon Elastic Load Balancer per instradare tra le istanze ha_proxy. Per avere ancora più sicurezza puoi dividere la tua applicazione in più zone di disponibilità.

2. MySQL replica padrone padrone non è la cosa più facile. È possibile avere una singola istanza master e avere più slave in più zone di disponibilità. Quindi puoi supportare le azioni di lettura anche se il tuo master se n'è andato.Penso che un vero maestro con failover non sia possibile.

3. ha_proxy dovrebbe essere in grado di bilanciare il carico delle istanze di Wowza.