Le 21 janv. 2014 à 12:45, seb astien <[email protected]> a écrit : > Hello, > > > Le 21 janvier 2014 12:38, Alexandre <[email protected]> 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-scale/
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 -- Frédéric de Villamil / @fdevillamil I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
