API di auto scaling Amazon per i server di lavoro

Question

Ho letto praticamente l'intera documentazione anche oltre l'API di AWS AS per comprendere tutte le cose di AS.

Tuttavia, mi sto ancora chiedendo (senza aver effettivamente utilizzato l'API ancora da quando voglio scoprirlo prima da qualcuno) se il mio scenario è fattibile con AS.

Dire che ho un gruppo di server di lavoro di installazione all'interno di un gruppo AS che lavorano tutti su un lavoro ciascuno e improvvisamente arriva il momento (non so, AVG CPU è maggiore o in un altro caso inferiore all'80%) per scalare su o giù.

La mia preoccupazione principale è la perdita di un lavoro attualmente in corso. Forse questo sarebbe meglio spiegata con un esempio:

• ho startup 5 server di lavoro con 5 posti di lavoro su di loro
• Un lavoro finisce su uno e spara una scala verso il basso trigger nella API di Amazon
• Amazon tratta di scala giù
• perdo un server di lavoro che in realtà è attualmente in esecuzione di un lavoro (90% devo completa ricominciare)

Con questo in mente è meglio per me di utilizzare solo l'Amazzonia Spot istanza/EC2 API e solo gestire il mio ridimensionamento o c'è qualcosa che mi manca su come l'API Amazon giudica le terminazioni del server?

a dire il vero piuttosto scala per SQS attesa importo di una figura di salute sui server:

• per ogni 100 messaggi in attesa capacità di cluster aumento del 20%

Ma questo non lo fa sembrano essere anche fattibili con AS.

Quindi l'API AWS AS non è la soluzione giusta o mi mancano alcune informazioni vitali su come funziona?

Grazie,

Answer 1

Dopo alcune ricerche ho scoperto che ci sono due modi accettati da gestire come API o AS, in generale, per i lavori:

Un metodo è quello di manipolare la salute di un server direttamente dall'interno del lavoratore stesso. Questo è ciò che fanno alcuni siti ed è efficace, quando il tuo lavoratore non rileva più lavori o ridondanza nel sistema che segnala che il server è in stato non sano. In questo modo l'API AS arriva e automaticamente lo toglie dopo un periodo di tempo.

Quindi con questo metodo si avrebbe un criterio di ridimensionamento basato sulla dimensione della coda SQS per un periodo di tempo (ad esempio ogni 5 minuti di messaggi SQS oltre 100 aggiungere 2 server, ogni 10 minuti di messaggi SQS essere oltre 500 doppia capacità di rete del 50%). La scala verso il basso sarebbe gestita dal codice anziché da una politica attiva.

Questo metodo potrebbe funzionare anche con cluster zero in modo da poter ridurre il cluster fino a nessun server quando non viene utilizzato, rendendolo piuttosto conveniente.

Vantaggi:

• Facile da configurare
• utilizzando le funzioni API AWS
• Probabilmente il più veloce da installare
• Usando AWS è riuscito API per gestire la dimensione dei cluster per voi

Svantaggi:

• Difficile da gestire senza utilizzare l'API AWS completa, ad esempio quando si crea un nuovo server non è possibile recuperare l'istanza dell'istanza senza eseguire un comando API completo di restituzione di tutte le istanze. Ci sono altre occasioni in cui l'API di AWS AS si intromette e rende la vita un po 'più difficile se vuoi un elemento di autocontrollo sul tuo cluster
• Affidati ad Amazon per sapere cosa è meglio per il tuo portafoglio. Ti stai affidando all'API di Amazon per scalare correttamente, questo è un vantaggio per molti ma uno svantaggio per alcuni.
• Il worker deve contenere parte del codice del pool del server, il che significa che il worker non è generico e non può essere spostato immediatamente su un altro cluster senza alcune modifiche alla configurazione.

Con questo in mente c'è una seconda opzione, fai-da-te. Utilizza l'istanza Spot EC2 e l'istanza dell'istanza su richiesta per creare la tua API AS basata sulle tue regole personalizzate. Questo è abbastanza semplice da spiegare:

• Hai uno script CLI che quando si avvia l'esecuzione, diciamo, 10 server
• Si dispone di un cronjob che quando rileva un soddisfacente di certi bassi condizioni i server o gruppo di continuità più

Vantaggi:

• facile e pulita per gestire la vostra fine
• possono fare i lavoratori generici
• Il pool di server può iniziare a gestire molti cluster
• È possibile rendere le regole e ciò che non è molto complesso ottenere dati dalle metriche su AWS e utilizzarli con confronto e intervalli di tempo per capire se le cose dovrebbero cambiare.

Svantaggi:

• Difficile ottenere multi-regione (non così male per SQS dal SQS è sola regione)
• difficile da affrontare errori nella capacità di regione e il carico di lavoro
• È necessario fare affidamento sui tempi di attività del proprio server e sul proprio codice per assicurarsi che il cronjob sia eseguito come dovrebbe e provveda ai server come dovrebbe e li interrompe quando dovrebbe.

Quindi sembra davvero una battaglia di cui è più comodo per l'utente finale. Personalmente sto ancora meditando e ho creato un piccolo pooler server self-host che potrebbe funzionare per me, ma allo stesso tempo sono tentato di provare a farlo funzionare sulla propria API di AWS.

Spero che questo aiuti le persone,

EDIT: Nota con uno di questi metodi sarà ancora bisogno di una funzione al vostro fianco per prevedere come si dovrebbe fare un'offerta, in quanto tale, è necessario chiamare la storia API offerta sul tuo tipo di spot (tipo EC2) e calcolare come fare un'offerta.

Un'altra modifica: un altro modo per rilevare automaticamente la ridondanza in un sistema è controllare la metrica delle risposte vuote per la coda SQS. Questa è la quantità di volte in cui i tuoi dipendenti hanno eseguito il ping della coda e non hanno ricevuto risposta. Questo è abbastanza efficace se si utilizza un blocco esclusivo nella tua app per la durata del lavoratore.

Answer 2

Ho appena avuto lo stesso tipo di problema e ho parlato con un ragazzo di Amazon che mi ha parlato della protezione di terminazione. Infatti, se un'istanza ha la protezione di terminazione attivata, non è possibile terminare . Quando viene attivata una scala verso il basso, l'app verrà rimossa dal gruppo di ridimensionamento automatico, ma non verrà terminata. Per terminarlo, è necessario disabilitare la protezione di terminazione e quindi terminarla (è possibile farlo alla fine del lavoro, ad esempio).

In sintesi, quello che devi fare è:

• Aggiungere uno script di avvio nel vostro AMI per attivare la protezione terminazione
• Tenere le regole auto-scaling (scale-up e la scala-down)
• Sulle istanze in esecuzione, una volta che è sicuro di terminare un'istanza (fine di un lavoro, ...), disattivare la protezione di terminazione e terminare l'istanza

si può fare tutto questo utilizzando l'AWS API.