> What the CPU is doing isn't really relevant, the EC2 machines are
> really just Xen instances, and you pay for every hour (or portion of
> an hour) that the instance is booted, regardless of whether it is
> working or not.
So it's not based upon CPU/hour, really instance/hour? Forgive me on
this issue as I haven't researched that much into this part of their
pricing.
So $72 for the full month (small) if an instance is kept running the
full time. Seems similar pricing for what would the CPU part of a
dedicated server would cost.
So it would then depend upon how much instances you have in the cloud
and the time for a developer to "auto scale" to actually save some
dough. If you are talking about a few instances then no, if in the
hundreds then you would have some real savings.
>
> In many applications, the new IP address is not an issue. For a web
> farm for example, I'll usually run something like Varnish on the front-
> end machines with the public IP addresses, and keep them running all
> the time, then bring up or shut down backend hosts behind varnish as
> needed, and have an init script that registers the new backends as
> being available as part of their boot up.
Yes agreed, depends upon what the instance is doing.
> when ( load is greater X for Y minutes ) {
> total=count_total_number_of_running_instances()
> recent=count_number_of_instances_started_in_the_last_hour()
> if ( total < MAX_TOTAL AND recent < MAX_RECENT ) {
> start_a_new_instance()
> } else {
> notify_administrator()
> }
>
This might be a fine script for simple auto-scaling, but using load as
a metric IMHO is a terrible method to determine scaling. Reasons:
- You don't know if your app is the cause of the load or some rogue/
foreign process (ie hacker who's taken over your instances) Is the
load legit or not?
- Can your existing code be written better since it became CPU and bus
bound? (remember unix load is a measure of cpu and bus IO.)
- Was this something that was already a known trend or was this an
unusual spike in activity?
- The load has already happened now you are reacting to the issue
instead of creating instances BEFORE they are needed. High Load is a
trailing indicator, not leading. Ideally with auto scaling it should
create instances just before they are needed, not after.
- I think metrics used are much more app specific than using just load
-L
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
