Accelerare il lancio di istanze di Windows Amazon EC2

Sto lavorando a un servizio Web che è ospitato su EC2 e deve disporre di un numero variabile di istanze in esecuzione, a seconda del carico. Abbiamo il servizio di base attivo e funzionante, ma una delle cose con cui stiamo lottando è il tempo necessario per il provisioning e l'avvio di un'istanza di Windows (stiamo usando alcuni strumenti prty che funzionano solo su Windows). Ho visto questo prendere da 10 minuti fino a 45 minuti abbastanza sbalorditivi.

Qualcuno ha qualche consiglio su come velocizzare il lancio di un'istanza EC2? Dal momento che le AMI per server Windows sono grandi rispetto alle AMI Linux, ad esempio, mi chiedo se una cosa potrebbe essere quella di assicurarsi che il bucket S3 contenente l'AMI si trovi nella stessa zona in cui viene avviata l'istanza, che presumibilmente velocizzare il provisioning della nuova istanza.

Ieri sera ho installato 3 istanze di un server Windows 2003 vaniglia. I primi due impiegarono circa 45 minuti, il terzo, circa un'ora dopo, impiegò 2 ore intere prima che fosse pronto!

Quelli non contenevano nulla, senza l'utilizzo di S3. Dubito che ci sia un modo per accelerare quel passaggio fondamentale oltre ad aspettare che Amazon apporti miglioramenti della velocità di implementazione nel tempo. Quindi, concluderei che ci si aspetta un certo ritardo e che il consiglio di Kurt è buono, che è di mantenere 1 o 2 in riserva già preparati.

Un'altra cosa che potresti fare è creare una nuova istanza del tuo tipo AMI più volte e più volte. Quindi prova alcune volte con il tuo spazio di archiviazione S3 e vedi quanto tempo ci si aggiunge. Presumo che la zona di disponibilità dovrebbe corrispondere tra l'immagine e S3, anche se non so quanta differenza di tempo farà.

Dopo aver determinato il tempo massimo per il provisioning, tieni il carico / l'utilizzo in anticipo di molti minuti.

Le istanze di Windows di Amazon vengono riavviate all'avvio perché la configurazione predefinita del servizio Windows "Configurazione EC2" consiste nel rinominare l'host con il nome DNS interno dell'istanza. La ridenominazione degli host richiede un riavvio su Windows. Se non è necessario utilizzare il nome DNS interno dell'istanza, è possibile che si disabiliti la funzione SetComputerName. Le istanze di Windows hanno anche il vantaggio di non dover inizializzare le unità di avvio in cui potresti aver già raggruppato di nuovo la configurazione risparmiando ancora un po 'di tempo all'avvio dell'istanza. Tutto ciò è possibile tramite il servizio di configurazione Windows EC2.

Servizio di configurazione di Windows: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/appendix-windows-config.html

Le mie piccole istanze di Windows normalmente impiegano 15-18 minuti per avviarsi (quelle più grandi sono più veloci). A seconda delle tue esigenze, potresti essere in grado di raggruppare tutto il tuo software all'interno dell'AMI ed essere in grado di avviare e far funzionare tutto in quel periodo. Comprendo le riserve per non raggruppare tutto in un AMI, ma potrebbe valere la pena migliorare in fase di avvio avere AMI di produzione con tutto ciò che è raggruppato in esse. Tieni separati gli script di compilazione se lo desideri negli ambienti di compilazione.

Inoltre, ora che Amazon aveva rilasciato i volumi root EBS anziché i volumi root del negozio di istanze. Le piccole immagini di Windows in esecuzione su un volume EBS si avviano in quasi 5 minuti rispetto ai quasi 20 minuti necessari in precedenza. Inoltre, non è necessario terminare - è possibile arrestarli / avviarli - a seconda della configurazione, ciò potrebbe radere qualche altro minuto in alcuni script di avvio.

Essenzialmente personalizzando il servizio di configurazione di Windows EC2, l'AMI e potenzialmente utilizzando un volume di avvio EBS dovrebbero ridurre i tempi di avvio a quasi 5 minuti. Puoi evitare il sysprep che viene eseguito all'avvio di un'istanza ec2 a seconda della tua app, in particolare per scopi di sviluppo. Un'immagine m1.large non sysprepped che evita una modifica del nome host all'avvio può avviarsi in circa 2 minuti, il che non è affatto male.

Al momento, per quanto ne so, è il massimo che puoi fare con Windows su Amazon EC2, ma non è poi così male. Se riesci a prevedere in futuro quasi 10 minuti in base a modelli di utilizzo medi, dovresti essere in grado di eseguire il rollup di istanze extra e gestire il carico aggiuntivo.

Hai un sistema minimo, mantenere il più possibile in EBS potrebbe essere d'aiuto? O forse adottare un approccio in stile Apache ed eseguirne uno o due in riserva?

Abbiamo riscontrato questo esatto problema, ma in modo molto serio: la nostra nuova startup estende Amazon EC2 in un ambiente Virtual Lab (multiutente, criteri, condivisione ecc.) E quindi abbiamo dovuto accelerare l'ora di inizio di Macchine Windows. La nostra più grande decisione è stata quella di supportare solo volumi basati su EBS nella nostra applicazione, perché sono gli unici che possono avviarsi in 5-10 minuti. Nei nostri test abbiamo riscontrato che i tempi di avvio del negozio di istanze variano notevolmente e talvolta impiegano una quantità eccessiva di tempo, il che li ha resi inutili per noi.

Simon @ LabSlice Virtual Lab Management su EC2