cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wei ZHOU <ustcweiz...@gmail.com>
Subject Re: Dynamic scaling support for KVM
Date Thu, 12 Sep 2019 19:51:35 GMT
Totally agree with Andrija.

-Wei

On Thu, 12 Sep 2019 at 17:41, Andrija Panic <andrija.panic@gmail.com> wrote:

> Guys,
>
> My 2 cents:
>
> I've played with dynamically increasing CPU number and RAM memory size
> across all 3 hypervisors (during my analysis of how currently cpu/ram
> overprovisioning works, in order to see the feasibility of dynamic
> overprovisioning i.e. do any changes (reductions in cpu/ram) that we
> already do after the VM is stopped and started - this dynamic apply of
> overprovisioning is not a subject atm, just mentioning it for sake of
> completeness.
>
> Balloning driver is officially an abandoned project (I explicitly pinged an
> RH engineer to confirm what they stated on the balooning driver home
> page...), so dynamically scalling down ram for KVM is not possible to be
> done in the graceful maner. That beings said, you can still just blindly
> reduce amount of ram (and cause kernel panics and such).
>
> Atm, we support dynamic scalling UP only, for XS and VMware - idea is that
> we support the same for KVM - to be able to change Compute Offering to a
> bigger one, on the fly.
> This is possible with minor changes in XML, ad Rohit stated already and a
> simple call to libvirt (i..e.virsh).
>
> From my point of view, we are not considering any special use cases etc, we
> simply want to allow upgrading Compute Offering on the fly.
>
> Does this makes sense, any feedback?
>
> Cheers
>
>
>
> On Thu, Sep 12, 2019, 02:16 Riepl, Gregor (SWISS TXT) <
> Gregor.Riepl@swisstxt.ch> wrote:
>
> > > Just to add some context, this was awhile back that I tried it,
> > > years. The idea was that we could just set max memory to some crazy
> > > high number and then “unlock” just the amount in the offering, and
> > > adjust on the fly. As mentioned I found it was trivial for VM users
> > > to unlock the full amount and get a “free” upgrade, so it was
> > > useless. There was also a non trivial amount of RAM overhead just
> > > lost to support balloon, if I recall.
> >
> > IMHO, supporting full dynamic scaling included shrinkage has a limited
> > number of use cases. If you want a workload to be dynamically scalable,
> > it would usually be much better to look into horizontal scaling, i.e.
> > deploying more instances as load increases. If your workload is too
> > small to make horizontal scaling effective, you should probably ask
> > yourself the question if you need scaling at all.
> >
> > Limiting scaling to memory increase only might have some merit and
> > should be much easier to implement by means of memory hotplug
> > emulation. Though, is it really worth the complexity when an offline
> > upgrade would normally only cause a very short downtime (or none at all
> > in a HA setup)?
> >
> >
>

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