Accélération du lancement des instances Windows Amazon EC2

Je travaille sur un service Web hébergé sur EC2 et doit avoir un nombre variable d'instances en cours d'exécution, en fonction de la charge. Nous avons le service de base opérationnel, mais l'une des choses avec lesquelles nous nous débattons est le temps qu'il faut pour provisionner et lancer une instance Windows (nous utilisons des outils tiers qui ne fonctionnent que sur Windows). J'ai vu cela prendre de 10 minutes à 45 minutes assez stupéfiantes.

Quelqu'un a-t-il des conseils pour accélérer le lancement d'une instance EC2? Étant donné que les AMI pour les serveurs Windows sont grandes par rapport aux AMI Linux, par exemple, je me demande si une chose pourrait être de s'assurer que le compartiment S3 contenant l'AMI se trouve dans la même zone où l'instance est lancée, ce qui serait vraisemblablement accélérer le provisionnement de la nouvelle instance.

J'ai installé 3 instances hier soir d'un serveur Windows 2003 vanille. Les deux premiers ont pris environ 45 minutes, le 3ème, environ une heure plus tard, a pris 2 heures complètes avant qu'il ne soit prêt!

Ceux-ci n'avaient rien du tout, sans aucune utilisation de S3. Je doute qu'il existe un moyen d'accélérer cette étape fondamentale en plus d'attendre qu'Amazon améliore la vitesse de déploiement au fil du temps. Donc, je conclurais qu'un certain retard est à prévoir et le conseil de Kurt est bon, qui est de garder 1 ou 2 en réserve déjà préparés.

Vous pouvez également créer plusieurs fois une nouvelle instance de votre type AMI et la chronométrer. Essayez ensuite plusieurs fois avec votre stockage S3 et voyez combien de temps cela y ajoute. Je suppose que la zone de disponibilité doit correspondre entre l'image et S3, bien que je ne sache pas combien de différence de temps cela fera.

Une fois que vous avez déterminé le temps maximum à approvisionner, gardez une longueur d'avance sur la charge / utilisation.

Les instances d'Amazon Windows redémarrent au démarrage car la configuration par défaut du service Windows "EC2 Config" consiste à renommer votre hôte en nom DNS interne de l'instance. Renommer les hôtes nécessite un redémarrage sur Windows. Si vous n'avez pas besoin d'utiliser le nom DNS interne de votre instance, vous pouvez en bénéficier en désactivant la fonction SetComputerName. Les instances Windows ont également l'avantage de ne pas avoir à initialiser les lecteurs de démarrage où vous avez peut-être déjà regroupé votre configuration, ce qui vous fait gagner un peu plus de temps au démarrage de l'instance. Tout cela est possible via le service de configuration Windows EC2.

Service de configuration Windows: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/appendix-windows-config.html

Mes petites instances Windows prennent normalement 15 à 18 minutes pour démarrer (les plus grandes sont plus rapides). Selon vos besoins, vous pourrez peut-être regrouper tous vos logiciels dans l'AMI et pouvoir tout démarrer et fonctionner pendant cette période. Je comprends les réserves de ne pas tout regrouper dans une AMI, mais cela pourrait valoir la peine d'améliorer le temps de démarrage pour avoir des AMI de production avec tout ce qu'il contient. Gardez les scripts de build séparés si vous le souhaitez dans vos environnements de build.

En outre, maintenant qu'Amazon a publié des volumes racine EBS par opposition aux volumes racine de stockage d'instance. Les petites images Windows exécutées sur un volume EBS démarrent en près de 5 minutes contre près de 20 minutes auparavant. De plus, vous n'avez pas besoin de terminer - vous pouvez les arrêter / les démarrer - selon votre configuration, cela réduit potentiellement quelques minutes de plus dans certains scripts de démarrage.

La personnalisation de votre service Windows EC2 Config, votre AMI et éventuellement l'utilisation d'un volume de démarrage EBS devraient réduire les temps de démarrage à près de 5 minutes. Vous pouvez éviter le sysprep qui s'exécute au démarrage d'une instance ec2 en fonction de votre application, en particulier à des fins de développement. Une image m1.large non préparée par Sys qui évite un changement de nom d'hôte au démarrage peut démarrer en environ 2 minutes, ce qui n'est pas mal du tout.

Pour le moment, si je comprends bien, c'est le mieux que vous puissiez faire avec Windows sur Amazon EC2, mais ce n'est vraiment pas trop mal. Si vous êtes en mesure de prévoir près de 10 minutes dans le futur en fonction des modèles d'utilisation moyens, vous devriez être en mesure de générer des instances supplémentaires et de gérer la charge supplémentaire.

Avoir un système minimal, garder autant que possible dans EBS pourrait aider? Ou peut-être adopter une approche de style Apache et en exécuter un ou deux en réserve?

Nous avons rencontré ce problème exact, mais de manière très sérieuse - notre nouveau démarrage étend Amazon EC2 dans un environnement de laboratoire virtuel (multi-utilisateurs, politiques, partage, etc.) et nous avons donc dû accélérer l'heure de début de Machines Windows. Notre plus grande décision a été de ne prendre en charge que les volumes basés sur EBS dans notre application, car ce sont les seuls qui peuvent démarrer en 5 à 10 minutes. Lors de nos tests, nous avons constaté que les temps de démarrage des magasins d'instances varient considérablement et prennent parfois trop de temps, ce qui les rend inutiles pour nous.

Simon @ LabSlice Virtual Lab Management sur EC2