incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Tue, 18 Dec 2012 17:05:12 GMT
The FS looks good and addresses the things I'd want it to (scaling should
be limited to within cluster, use offerings).

As you mention, there's a real problem surrounding no support for scaling
down CPU, and it's just as much a problem with the guests as it is with
hvms at the moment, it seems. This makes it hard to just set a VM as a
dynamic one, since at some point you'll likely trigger it to scale up and
have to reboot to get back down. My suggestion if this goes
through however is that instead of marking a vm for auto scale, we can
either attach multiple compute offerings (with a priority or "level") to a
VM, along with triggers (we can't really trigger on memory, but perhaps cpu
utilization over a specific time, e.g. if cpu is at 80% for x time, fall
back to the next offering), or we can create a specific single compute
offering that allows you to specify a min and max memory, cpu, and a
trigger at which it scales (this latter one is my preference).

The whole thing is problematic though, because people can inadvertently
trigger their VM to scale up when they're installing updates or compiling
or something and then have to reboot to come back down. If we can't take
away resources without manual intervention, we shouldn't add them. For this
reason I'd like to see the focus (at least initially) on simply being able
to change to larger compute offerings while the VM is up. With this in
place, if someone really wants to autoscale, they can use the api in a
combination of fetching the VM stats and the existing
changeServiceForVirtualMachine. Or we can put that in, but I think any
implementation will be a poor experience without being able to go both ways.

I don't know, maybe I'm off in left field here, I'd be interested in
hearing the thoughts of others.

You mention  'upgradeVirtualMachine', which should be mentioned on the
customer facing API is called 'changeServiceForVirtualMachine', just to
reduce confusion.


On Tue, Dec 18, 2012 at 9:18 AM, Koushik Das <koushik.das@citrix.com> wrote:

> Created first draft of the FS
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM
> Also created jira issue
> https://issues.apache.org/jira/browse/CLOUDSTACK-658
>
> Comments? There is an 'open issue' section where I have mentioned some
> issues that needs to be closed
>
> Thanks,
> Koushik
>
> > -----Original Message-----
> > From: Koushik Das [mailto:koushik.das@citrix.com]
> > Sent: Saturday, December 15, 2012 11:14 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: [DISCUSS] Scaling up CPU and RAM for running VMs
> >
> > Currently CS supports changing CPU and RAM for stopped VM. This is
> > achieved by changing compute offering of the VM (with new CPU and RAM
> > values) and then starting it. I am planning to extend the same for
> running VM
> > as well. Initially planning to do it for Vmware where CPU and RAM can be
> > dynamically increased. Support of other HVs can also be added if they
> > support increasing CPU/RAM.
> >
> > Assuming that in the updated compute offering only CPU and RAM has
> > changed, the deployment planner can either select the same host in which
> > case the values are dynamically scaled up OR a different one in which
> case
> > the operation fails. In future if there is support for live migration
> (provided
> > HV supports it) then another option in the latter case could be to
> migrate the
> > VM first and then scale it up.
> >
> > I will start working on the FS and share it out sometime next week.
> >
> > Comments/suggestions?
> >
> > Thanks,
> > Koushik
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message