As I #Work4Dell I see a lot of discussions on energy-efficiency from our portfolio of products. Rest assured we are doing all we can to optimize power consumption on our entire portfolio… Related to this I sometimes find myself in discussions on how the use of cloud-native is so much more energy efficient as there is no longer a need for those big virtual machines and workloads can run much more efficient on a container platform instead.
The most obvious place to optimize: Servers and Storage
A lot of people tend to think that the infrastructure is the main and only place where you can optimize on power consumption. There is a lot of pressure to come up with more energy efficient hardware as this is the layer that is so very visible. If you can make a server more power efficient, you save a little. If you have 1000 servers you save 1000x that. Simple math.
A similar story for storage platforms: If you can optimize dedupe and compression, you can store the same amount of data in a smaller footprint. If you can get to a data reduction of 4x, you need to power only a quarter of the drives. Simple math as well 🤓
These are the most obvious places where you can save on power and cooling.
Other abstraction levels where energy efficiency can be optimized
But when you look further you’ll see that EVERY layer in a platform running workloads adds to power consumption and can (should!) be a target for optimization. What if I could run the same workload not on 1000 servers, but on 500? Or maybe just 50? This may sound impossible, but it is exactly what VMware once did with their ESX(i) hypervisor: Today you can run hundreds of virtual machines on a single physical one. But it does not end there.
Hypervisor layer under k8s: Yay or nay?
As each virtual machine includes lots of overhead from the Operating System sitting in each and every one of them, you can optimize further by stripping out the Operating System from the VM. When you do you basically end up with a container; we simply move the abstraction layer one step up:
The next discussion you could have is whether a container platform should remove the hypervisor layer and run the container platform “bare metal”. This seems to be a discussion not really sorted yet. Having seen the efficiency a modern hypervisor like VMware ESXi can bring, I would lean towards leaving the hypervisor in container environments when we are purely looking at energy efficiency; in a bare-metal environment there is a much bigger chance of resources being wasted. As a (not so obvious) example: VMware ESXi is VERY efficient when it comes to scheduling workloads on a physical server. It will actually try to optimize mapping memory pages to the same CPU socket as where the VM gets scheduled to run. This in turn means that an ESXi environment can function properly north of 90% CPU usage, where a bare-metal Linux installed server usually tops off at like 50% CPU load before starting to show crumbling performance.
Another upshot of hanging onto the hypervisor layer is the efficiency you can get when you use many smaller container clusters; in the world of virtual machines you can simply layer lots of containers clusters onto a limited set of physical servers, even running different flavors of Linux all on the same physical boxes.
If people will go as far as to optimize to this extend, the next layer awaits: The application itself.
The layer people tend to forget: The app itself
How can the app itself help to conserve energy? You may think this isn’t much of a factor, but in fact it might the biggest one yet.
Read all about it in part two of this blog post!
One thought on “Energy efficiency: Not just about infrastructure (part 1/2)”