2

I've never come across a hosting company/cloud company that provides true vertical scaling without having to turn off the machine and/or copy the website or VM on to another machine. I've only seen services/dashboards that say they do vertical scaling but are actually just abstracting the process described in my previous sentence.

Is it currently not possible to add/remove RAM & CPU without shutting down the machine first? Or is it just not cost effective enough for hosting companies to offer this? (or I am wrong and there are companies that provide vertical scaling on the same machine without downtime)?

If it's not possible, then why? Is a restriction of what current processors are capable of?

2 Answers 2

1

It's possible depending on the platform, but still requires capacity panning ahead of time.

In many hypervisor platforms, there is a concept of "memory ballooning". This will allow you to specify a "current" amount of RAM, but also a "maximum" amount of RAM. The maximum is a hard limit that is defined ahead of time, but the ballooning mechanism allows a guest OS that has not fully allocated its maximum memory map on the hypervisor to extend what is allocated to it on-demand. This is mostly useful in lab environments, and for statically deployed workloads that you expect large and infrequent allocation spikes from (but not all at once if over-provisioning).

The same can apply to CPU resources, specifying a "max" amount of cores or core percentage, and allocating those from a "soft" value all the way up to a maximum "hard" value.

It's a trick of virtualization that can be seen as a direct parallel to hotswap hardware systems. We're pretending that the VM has extra memory slots that aren't populated, or extra CPUs that aren't populated. But we still have to define the slot count firmly.

You can typically add disk storage on the fly to nearly any kind of instance on most platforms without any of these worries.

However, cloud orchestration systems have generally well-implemented and automated deployment systems, making these kind of models much more useless (with the exception of adding storage, that's still almost always just as useful).

Consider than many providers charge per-capacity allocated, rather than capacity used. Implementing a dynamically vertically scaling instance model creates yet another layer of scheduling and resource allocation problems for providers - one is that any number of customers might want quite a few resources at the same time, but also that any one of those customers might make those instances bloat at any time.

The only way to properly plan from a cloud infrastructure perspective in that case would be to allocate instances by their maximum capacity, and rightfully charge for that allocation they could otherwise afford to another customer.

At that point, why not just use the maximum if you already have to pay for it? And if we're doing things by maximum capacity, then redefining instances becomes necessary again to accomplish vertical scaling.

0

Online vertical scaling is possible. But the hardware and software must support it, and possibly more importantly the service provider must be interested in providing you this feature.


For example, IBM Power Systems lash multiple nodes into one system. Features exist to hot add a node by physically racking and cabling another box of CPUs. CPUs and memory can then be hot added to running partitions (VMs).

Such a serviceability feature is expensive, enterprises will pay a premium for it. Also relatively complex.


Contrast to many commodity clouds, usually running x86. Your instance sizes are a fixed list, and switching to a different one is a reboot, but you can have as many as you want. Cost is generally less expensive due to less advanced RAS features and economy of scale.

These clouds would rather you scale out to multiple hosts. They have many more of the same size instances, allocated on hardware in some optimum way. Hot adding would be expensive just in rebalancing the load with different sized VMs. Why bother engineering that when you can convince architects and developers to scale out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .