Accelerare la creazione di AMI e ASG

Question

utilizzando Ansible Creo un'AMI di un'istanza di ubuntu quindi utilizzando questa AMI per creare una configurazione di avvio e quindi aggiornare e il gruppo di ridimensionamento automatico, ci sono scorciatoie da utilizzare per accelerare l'ASG e l'AMI passaggi, 10 minuti +

Answer 1

Utilizzare un AMI supportato EBS invece di un AMI supportato da Istanza Store. Dal AWS docs:

  Amazon EBS-Backed    Amazon Instance Store-Backed 
Boot time Usually less than 1 minute Usually less than 5 minutes 

- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

Answer 2

ho fatto una domanda simile tramite un biglietto di AWS di sostegno, qui non c'era risposta:

Il tempo principale processo che richiede tempo, quando l'avvio di una nuova istanza EC2 è il processo di avvio del sistema operativo all'interno dell'istanza: con più o meno gruppi di sicurezza /ACL di rete, diversa quantità di coppie di chiavi SSH e ruoli associati all'istanza non dovrebbero avere alcun impatto misurabile in il tempo necessario all'avvio. La maggior parte del tempo necessario per avviare un'istanza viene utilizzata dal sistema operativo stesso.

Con questo in mente, mi permetta di andare oltre alcuni degli elementi principali che potrebbe consumare la maggior parte del tempo quando un'istanza stivali - per tutti i punti al di sotto mi concentrerò esclusivamente su Linux da un punto EC2 di vista :

• monta filesystem locale: se l'istanza ha bisogno di montare una grande quantità di file system, questo aggiungerà un po 'di tempo al vostro processo di avvio . A seconda dei tipi di file system utilizzati, potrebbe essere necessario eseguire un controllo periodicamente ogni numero fisso di giorni, ad esempio, su Linux potrebbe essere necessario eseguire fsck su un filesystem ext4 ogni 90 giorni (questo periodo può variare in base a le impostazioni) e l'OS attiva automaticamente questo controllo quando il filesystem viene montato all'avvio se rileva che il periodo è stato superato. Una strategia per impedisce di eseguire questi controlli prima di creare l'AMI che verrà utilizzata per avviare le nuove istanze, in modo che tutte le istanze avviate da questa AMI abbiano i loro file system controllati di recente e non si incappano in esecuzioni di fsck inaspettate quando si lanciano le istanze per la prima volta. A seconda del tipo di filesystem utilizzato da , potrebbe essere possibile disabilitare questi controlli periodici del tutto, ma non lo consiglierei poiché sono necessari per mantenere l'integrità del file system nel tempo.

• monta filesystem remoto: Se l'istanza ha bisogno di montare qualsiasi file system remoto (ad esempio, una quota di EFS, o qualsiasi condivisione NFS convenzionali), il processo di avvio può essere ritardata a seconda della connettività di rete alla condivisione del server questo file system remoto. Nel peggiore scenario , se il server che condivide il filesystem non è in linea, il processo di avvio verrà interrotto fino a quando questa connessione scade e non riesce. Se per default si sta montando un filesystem remoto all'avvio di istanze, assicurarsi che i server che li condividono siano disponibili prima di avviare le istanze.

• Script di inizializzazione del sistema operativo regolare: la maggior parte del tempo impiegato dal processo di avvio verrà presa all'avvio dei servizi OS . Ci sono due tipi di modelli per questo in Linux: l'init SystemV tradizionale (che avvia i servizi in modo seriale, uno dopo l'altro) e il sistema relativamente nuovo (che è in grado di avviare i servizi in parallelo, e quindi diminuire il tempo di avvio in alcune circostanze ). Quale di questi usi dipenderà dalla distribuzione di Linux che esegui nelle tue istanze. Ad esempio, se hai bisogno di avviare un server DB che potrebbe richiedere molto tempo ogni volta che si avvia l'istanza , potrebbe essere utile considerare systemd in quanto consentirà il per il resto dei servizi non correlati da avviare in parallelo , come poiché non hanno questo server DB come prerequisito.

• Dati utente e script di inizializzazione cloud: questi vengono eseguiti dopo che gli script di avvio del normale OS sono terminati. Come per gli articoli precedenti, è possibile verificare che uno qualsiasi di questi script personalizzati eseguiti sia ottimizzato in modo che possano impiegare il tempo minimo necessario; è consigliabile testare singolarmente gli script di dati utente personalizzati su per misurare il tempo prima di aggiungerli a una nuova istanza di avvio in modo che l' possa avere un'idea migliore del loro impatto nel tempo complessivo dell'avvio dell'istanza . Se gli script recuperano file esterni a l'istanza (se si scarica qualcosa da un bucket S3, si esegue un aggiornamento automatico dei pacchetti installati, ecc.), Le stesse considerazioni di che ho menzionato su "Monta filesystem remoto" articolo menzionato sopra: accertarsi che non vi siano problemi di rete che potrebbe rallentare o impedire questa connessione, in quanto ciò aggiungerebbe più tempo al processo di avvio generale dell'istanza.

• Tipo di istanza: il tipo di istanza influisce sul tempo impiegato dal sistema operativo per completare l'avvio. Nelle stesse circostanze, un'istanza t2.large si avvierà più velocemente di un t2.nano semplicemente perché ha più RAM , vCPU e una quantità maggiore di crediti CPU - che consentono a il sistema operativo di eseguire il processo di avvio più velocemente . Inoltre, se è necessario richiamare grandi quantità di dati durante il processo di avvio dell'istanza, , è possibile utilizzare la modalità di rete avanzata e le istanze ottimizzate EBS per assicurarsi di disporre della larghezza di banda migliore disponibile per le proprie esigenze. ; vedere i collegamenti alla fine di questo messaggio per maggiori dettagli su questo.

• EBS Tipo di volume: proprio come con il tipo di istanza, anche le prestazioni dei volumi EBS possono influire sul tempo complessivo dei tempi di avvio dell'istanza. Se la tua istanza ha bisogno di leggere grandi quantità di dati durante il processo di avvio da un volume sc1 (un volume HDD con prestazioni ridotte progettate per dati con accesso non frequente), il processo di avvio sarà più lento rispetto a quando l'istanza legge gli stessi dati da un volume PIOPS con prestazioni molto più elevate - se il tuo caso è contiene uno scenario in cui sei interessato da questo, potresti voler testare diversi tipi di volume per scegliere quello che meglio si adatta alle tue esigenze. Allo stesso modo, il tipo di volume root della tua istanza avrà un impatto anche sulle prestazioni di avvio, poiché in tutti i casi sarà necessario leggere le informazioni da .Per la maggior parte dei casi, il valore predefinito "Generale SSD" a.k.a. gp2 I volumi EBS sono sufficienti per i volumi di root .

In ultima analisi, il tempo necessario per lanciare una nuova istanza sarà determinato eseguendo punti di riferimento per il vostro particolare caso d'uso; le considerazioni generali che ho menzionato sopra possono aiutarti a ridurre questo tempo, ma per determinare quali sono le impostazioni migliori per il tuo ambiente devi per testare e mettere a punto ogni parametro finché non raggiungi un punto dove il tempo di avvio si adatta alle tue esigenze

Allego un paio di collegamenti alla fine di questa risposta con ulteriori dettagli sugli articoli che ho menzionato in questa risposta.

Spero che questa informazione ti sia stata utile. Per favore fatemi sapere se avete domande su .

Grazie,

Link correlati: - tipi istanza EC2: https://aws.amazon.com/ec2/instance-types/ - tipi di volumi EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html - istanze EBS ottimizzato: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html - Suggerimenti per le prestazioni per i volumi EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html - modalità Migliorare networking su EC2 Istanze Linux: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html