Le 21 janv. 2014 à 12:45, seb astien krionux@gmail.com a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre infos@opendoc.net a écrit : Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...]
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Bonjour,
AWS propose un service d’auto scaling pas trop mal foutu. J’en use et j’en abuse parce qu’il me facilite pas mal la vie pour :
- gérer la montée en charge (entre 2 et X VMs par type de node), avec des seuils d’upscale et downscale (genre « si le CPU est à plus de 90% pendant 5 minutes, ajoute une machine, et recheck 2 minutes plus tard, si il est à moins de 50% pendant 15 minutes tu en retires une et tu checks à nouveau au bout de 5 minutes, et je veux bien deux sucres dans mon thé, merci » ) - m’assurer qu’un nombre fixe d’instance tourne bien, en mode « je dors bien la nuit » : si une machine tombe, elle est immédiatement remplacée - faire les mises à jour de mon infra : une nouvelle AMI avec le code à jour, un nouvel auto scaling group qui me monte toutes les machines dans mes ELB, en les répartissant par AZ. Autant dire du bonheur.
Les trucs intéressants : - on peut changer le « launch group » (donc l’AMI) au sein d’un même groupe d’auto scaling, il faut en revanche tuer les instances une par une pour les remplacer. - le fait de donner une limite haute permet d’éviter d’auto scaler ta facture en cas de passage en première page sur HN. - tu peux brancher ton check d’auto scaling sur le check ELB. C’est vraiment pas mal, parce que si ton appli est en carafe mais que ta machine ping, elle est remplacée quand même. En revanche, si le check échoue parce que ta DB est en carafe, attends toi à du kill / spawn en infinite loop.
Le truc pénible : mon workflow de remplacement lors des mises à jour n’est pas encore parfait.
Hope it helps