Back in the good old days of physical…

Back in the good old days of physical servers, you basically had two choices to increase the performance of your application: you either “scaled up”, by migrating to a beefier server with more RAM, CPUs/MHz, or you “scaled out”, by distributing your application load across multiple individual servers.

Interestingly, I still observe customers applying this way of thinking to virtual environments, using multiple VMs behind a virtual load balancer for scaling out application load.

Does this approach really make sense anymore? I think that it puts more load on a hypervisor to schedule multiple VMs for handling the workload than it would if the same load would be handled by one single powerful VM instance (with more vCPUs, more vRAM).

Does “Scale Out” still make any sense in a virtual environment? It probably also depends on the application and if it can effectively scale with more CPUs and memory, but in general I don’t think it is a valid approach.

3 replies on “Back in the good old days of physical…”

  1. I think it can make sense:

    think of scaling out beyond the limits of physical server
    by combining this with a placement policy to more than one availability zone, so you even would achieve HA with this
    performance wise it could be beneficial on a NUMA host to use VMs that are bound to one NUMA Zone. That could be more performant than crossing all NUMA Zones with one VM.

    just my 0.02 €,
    greets, Ingo

    1. Hi Ingo, thanks for your comment!

      Good points, I agree that from an HA perspective there is a valid reason for this kind of setup, but you need to have more than one physical host/hypervisor for this. Also more on the HA side of things is using scale out to be able to perform maintenance tasks one one node, without having to take down the service.

      With regards to NUMA zones, I have no experience about the performance impact of this. My gut feeling is that it actually might be more performant to schedule two VMs in different NUMA zones than having one big VM that crosses NUMA boundaries. I need to do some research about this, to educate myself 🙂

      Thanks,

      Lenz

      1. even if there isn’t any performance gain on NUMA (while I’m pretty confident that there IS w/o having any backing numbers on it, either 😉 ) from a Hypervisor perspective it’s still more efficient for it to handle e.g. two 1vCPU vs. one 2vCPU guests – as the VM is only able to demand “I need my CPU ressource” which then would the Hypervisor have to schedule for two physical Cores available to give the 2vCPU VM it’s ressource – even if there was only a single thread task within the VM that asked for it..
        So keep your VMs as small as possible and rather spread single tasks among multiple of those small VMs..

Comments are closed.