Brian Gupta wrote: > > Mostly we want the ability, to leverage the micro-accounting EC2 > offers us. (To lower operational costs). > > Since EC2 bills by the hour, wouldn't it be prudent to be able to spin > down idling webservers during the evening, and spin up extra ones when > you know there are upcoming high traffic website events? Currently we > have this ability. For now it is still a manual process, in that we > have to say "please spin up X webserver nodes now in the xyz > environment", but they do autoconfigure themselves, update DNS, and > even adjust the load balancer config. We are still working on the > scheduling ability, but our puppet code and ec2 glue are all complete, > if should be fairly straightforward to throw something together. (We > might even leverage the OS scheduler.) > Hmm this brings up an interesting discussion.
It depends... if a no-op CPU command is billable to EC2 and they are truly sitting idle does Amazon charge for it? Obliviously a running instance will have CPU cycles, but not much if idle. Also the build process of a new instance I suspect has a decent amount of CPU time (obviously less if you are using binaries) I'm sure there is some point where it makes more sense to leave the instance running for X amount of hours, instead of regening it. (meaning it costs more to build a new EC2 instance, than just leave an existing one active) The other issues related to re-gening is new IP address and the time for EC2 to have your new instance ready (ie 10 min) Have you done any investigation on the cost benefits? If so what were the results? I'm obviously all for the automating the build of a new instance, and also automatically adding it to the pool of resources. I'm not so sure the next level of automation. Auto-scaling without any human interaction. The issue I have with most auto-scaling is the very basic metrics used to measure when to add/remove resources. I believe the issues are very customer/app specific and while with one customer X metric might be valid, with another you need X, Y and Z in some formula to determine when to go to the next level. The other issue related to this is the application itself. What may have allowed a customer app to scale to one level, may require code changes to scale effectively at a much higher level. This is something auto-scaling could never do. Vertical scaling is ALWAYS easier than going horizontal. Puppet is great at the automation of administration. To me auto-scaling could be a different tool and write high level rules on when to scale and what part to scale. Do I hear another tool in the making? :-) -L > Our eventual goal has always been *being able* to autoscale. > Realistically though, since unexpected load is fairly uncommon, we > still want a human in the scaling feedback loop. (So basically we want > autoscaling with a "Human! Press this button!" step in the autoscaling > process.) > > Cheers, > Brian > > >>>> -L >>>> >>>> -- >>>> Larry Ludwig >>>> Empowering Media >>>> 1-866-792-0489 x600 >>>> Managed and Unmanaged Xen VPSes >>>> http://www.hostcube.com/ >>>> >>>> >>>> >>>> >> -L >> >> -- >> Larry Ludwig >> Empowering Media >> 1-866-792-0489 x600 >> Managed and Unmanaged Xen VPSes >> http://www.hostcube.com/ >> >> >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
