Come automatizzare il failover su EC2?


13

Delle persone che gestiscono i propri cluster (ovvero non utilizzano / pagano per Amazon Autoscale, Rightscale, Scalr, ecc.), Come gestite le vostre istanze su EC2 e gestite (es.) Il failover? Mi chiedo se la maggior parte delle persone finisca per scrivere i propri carichi di script contro l'API EC2, come sospetto.

Questo è certamente il nostro approccio: montare il nostro demone di monitoraggio / riavvio basato su Python Boto che viene eseguito fuori sede, ascoltando i keep-alive UDP dalle nostre istanze. In caso di errore, eseguiamo l'istantanea dei volumi, registriamo le immagini, avviamo nuove istanze, eliminiamo i vecchi volumi e così via.

Ogni tanto, quando hackero i nostri script, penso che ci debbano essere alcuni strumenti open source là fuori che affrontano già questi problemi e che non hanno i vincoli di (diciamo) Scalr, ma torno sempre da Google a mani vuote. (Cose come Scalr sono piuttosto limitate nei set / versioni / configurazioni supportate del software e hanno modi specializzati e ingombranti per manipolare queste configurazioni.)

Inoltre, l'ecosistema Linux-HA / Pacemaker (Heartbeat, ldirectord, ecc.) Suona come se non fosse davvero adatto per EC2 . (Ma poi ho trovato questo - anche se non sono sicuro che questo è davvero una soluzione di alta qualità).

Risposte:


5

Bene, non intendo solo affermare l'ovvio, ma l'idea generale è quella di spingere questa complessità nei servizi gestiti da Amazon.

Quindi sul frontend, useresti Amazon Elastic Load Balancing (ELB) per fornire un bilanciamento del carico altamente disponibile. Sul retro, usi Amazon Relational Database Service (ospitato MySQL), SimpleDB e S3 per l'archiviazione. Tutti questi sono gestiti da Amazon e contengono una sorta di elevata disponibilità / gestione del failover.

Questo in genere lascia i server delle applicazioni Web e tutti i tipi di server meno comuni che potresti utilizzare (rendering server, archivi di dati NoSQL autoinstallati, ecc.).

I server Webapp sono generalmente gestiti abbastanza bene con i controlli di integrità integrati in ELB. Puoi accettare un piccolo peggioramento delle prestazioni quando un server webapp è inattivo o fornire costantemente un server +1 in più del necessario. O se la tua configurazione è semplice, quando un server webapp fallisce, ELB insieme a Cloudwatch può generare automaticamente un nuovo server webapp per te.

I tuoi server personalizzati sono un'altra questione. Per questi è vero, sei da solo e dovrai accontentarti dei metodi integrati nell'applicazione o canalizzare insieme qualcosa con script personalizzati / strumenti HA open source.

L'acquisto della soluzione di Rightscale potrebbe essere troppo costoso. Ma gli strumenti Amazon meno costosi come ELB, gli avvisi di base CloudWatch (ora gratuiti per una risoluzione di 5 minuti) o AutoScale valgono la pena se hai bisogno di alta disponibilità.


3
Conosciamo il set di funzionalità di AWS e i loro limiti. Per fare il tuo primo esempio, si accede a ELB tramite RR CNAME, che non possono coesistere con RR SOA, e quindi non possono servire TLD, inoltre non è possibile accedere tramite IP statici - frustrazioni ampiamente echeggiate nei forum. Per prendere il tuo secondo esempio, sì, RDS è MySQL, che è la limitazione gigante. Sì, siamo interessati all'automazione del failover dei nostri tipi di macchine. Sì, l'implementazione del cloud privato è rilevante per noi. Sì, sono solo curioso. Ecc.
Yang,

2
@Yang: Avresti dovuto formulare più attentamente la tua domanda e risparmiarmi il problema di scrivere la mia risposta. Non esiste una soluzione unica per tutti gli HA; dipende dal servizio in questione, da come viene mantenuto lo stato, dalle proprietà di failover del protocollo, ecc. Hai ragione sui limiti / difficoltà nell'uso dei tipici strumenti HA di livello IP su EC2. Ma non esiste una risposta unica che si applica universalmente a "HA su AWS".
Jesper M,

0

RightScale ha alcuni fantastici articoli su come automatizzare il failover su EC2. Mentre la maggior parte di loro ti mostra come farlo usando RightScale stesso, i principi sono generali e probabilmente utili a chiunque pensi a come impostare un'architettura di failover su EC2.


0

I problemi che descrivi (HA, monitoraggio di server personalizzati, servizi di "duct taping") sono generalmente gestiti da un fornitore PaaS. Rightscale e Scalr erano già stati menzionati in una risposta precedente e ci sono altre buone opzioni (vedi qui per alcune opzioni PaaS:

/programming/9542784/looking-for-paas-providers-recommendations )

Dovresti considerare quale dei provider si adatta meglio a ciò di cui hai bisogno.

Avviso dovuto: lavoro per cloudify, un provider PaaS open source.


0

Di recente ho scritto un post sul nostro blog di ingegneria su come utilizzare ELB in combinazione con il ridimensionamento automatico per ottenere il failover automatico per qualsiasi tipo di app. Descrive in che modo è possibile utilizzare i controlli di integrità ELB per eseguire il ping dello stato dell'app e attivare azioni di ridimensionamento automatico.


0

Si installa heartbeat su entrambi i server Si collega un IP elastico al server "attivo" Si configura uno script per eseguire il failover avviando una richiesta API per ottenere l'IP elastico Non appena il server "stand-by" ha ottenuto l'IP elastico ( richiede circa 30-60 secondi) può essere il master / attivo.

Non ho le specifiche da fornire qui.


-1

Amazon fornisce già il bilanciamento del carico elastico ... Perché reinventare la ruota?


3
A causa delle varie limitazioni di ELB? Perché richiede CNAME e non può servire sia foo.com che www.foo.com? Perché voglio implementare una logica di pianificazione personalizzata? Perché sono solo curioso di sapere come implementeresti ELB in un cluster di VM non affidabili? Fai la tua scelta.
Yang,

@Yang, lo fai come faresti se fossero server nel tuo datacenter. Non c'è alcuna differenza fondamentale, nessuna salsa magica che lo rende un ambiente cloud.
Chris S,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.