Transcript
In this screencast, we will show how we are redefining sustainability in the cloud edge continuum through the Ipsi-Sys collaboration. The screencast illustrates how an advanced energy monitoring system supports orchestration techniques to minimize energy consumption in the edge cloud environment during the execution of benchmark workloads. Our joint integration features two powerhouse projects. One next-gen, the one that is building Europe's first open-source platform for the data center to edge continuum, and Emulate, a project by the Dortmund University of Applied Sciences and Arts dedicated to measuring and optimizing the edge service performance. Today, the vast majority of data centers are the black box. Facility managers can measure the total power at the wall, but tenants only see their own services. This disconnect makes it impossible to accurately attribute energy consumption or the CO2 footprints. With tenants demanding emission reports and new CRD regulations looming, standard monitoring of facility totals is no longer enough. Thus, we must move from a black box to a glass box. We validated the strategy in the Vertoro lab using OpenAbility 7.0 and the GreenShift component. In our demonstration, a server running three Kubernetes nodes manages two different applications, a multi-service webshop and the automotive app. The GreenShift agent captures the real-time data from the physical server and attributes it precisely. When a simulated sales event causes a power spike in the webshop, the system identifies the exact service that is responsible. Even with multiple applications active, energy is divided fairly and accurately. The solution lies in the real-time energy metrics. By pooling the facility signals directly from hardware and merging them with the runtime telemetry from virtual machines and Kubernetes, we can finally achieve the granular allocation. Our system provides advanced techniques to monitor energy during industrial workloads and packing a server load down to the joule per pod. Next in the following demonstration, we'll see the details of the GreenShift project and components, including the demonstration. Hello, my name is Mohsen and I welcome you on the practical demonstration of our idea which has been presented by my colleague Dan. So first of all, I would explain you a little bit about our setup and then I will go through the steps of the demonstration. So what we have is we have a server machine running in our premises where we have installed the Open Nebula Community Edition 7.0 on the hardware resources. And since this supports the KVM, so we also have a KVM installed over it. And then we have three different virtual machines installed on it. And each virtual machine is basically a node of Kubernetes cluster. So we have a Kubernetes cluster installed on these VMs. So this is kind of a multi-tenant architecture where multiple tenants can deploy their application on shared resources. For this demo, we have two different applications from two different tenants. One is the webshop application, which is basically a product store, which has different microservices in it. You can see different colors of those microservices and you will see these color scheme in the demo as well. And then we also have another test application, which is an automotive application running as a single service. In addition to this, we also have a power at the wall, which is basically a real physical power distribution unit attached to the server machine, which is measuring the actual power consumption of the whole machine. So what we are doing here is at the host level, we have a GreenShift agent, which is working there, which takes this power at the wall. And it also takes some energy metrics from the hardware sensor, for example, RAPEL sensor is being used here. So we combine these energy metrics and we export them. And we attribute this energy to each VM. And within each VM, we go to the process level and to the part level. And at the aggregation level, we combine everything and we give the energy footprints for each application and for each service within the application. So this is pretty much what we are doing. This is the setup, which I wanted to explain. And I want to mention another thing here about the open Nebula feature. We are going to utilize the open Nebula capability to pass custom KVM configurations. Specifically, we will be using VirtueFS device here, but currently we are not using it, but we are working on it and we will be using it in our future enhancement to share data between the hypervisor and within the guest VM. Now coming to the actual data. So this is basically the actual measurements coming from that machine. So first of all, what you see at the top graph is the power at the wall, which is basically the actual PDU measurements. We are getting the active power of the machine. On the right side, you'll see three virtual machines, which I discussed, and you can also see the attribution to these machines. So what we are currently doing here is that at the host level, we get the active dynamic power of each virtual machine and everything that PDU draws other than the power consumed by our virtual machine, we consider that as a background energy. So you see that in the second graph. So everything like the power of the cooling fan, power of the motherboard, power consumed by other like hard disk, even other processes on the host machine, even idle power of the CPU. So we combine everything which is not being consumed by our virtual machines into this background power. So what we are doing here is that we sum this background power with the active virtual machine power based on its computation. And then basically this sum is equivalent to the power at the wall. And then we are attributing this power to each virtual machine based on the compute time of virtual machine. So idea here is that if you see this, if you sum this, all these three VMs power, so this will be equivalent to the power at the wall. So idea here is that each watt drawn at the wall, there is a VM responsible for the consumption of that watt. So this is one of the idea we are presenting. And now if we go inside the shared cluster or shared resources or inside the VMs, we have two different applications. As I mentioned, so first one, you can see different colors. So these different colors represent different services. Within the application, there are many services in this application. I think there are 12, but we are just for the simplicity, we are just displaying three of them here. And the height of the bar is basically the energy consumption of these services or energy attribution to these services with our method. And you see the second application as well, which is basically an automotive application. And currently there are no clients attached to it, so they are like using a normal attribution has been used. And at the bottom, you can see the overall consumption of both of the application as well. So what I'm going to do now is create a small experiment. First of all, I will show you this web application, which is basically a product store. We can browse these different products, we can add them to cart, we can place orders. So these are different microservices serving these functionalities. And what I'm going to do is to create a sale event where many users will try to connect and do these activities on this product store. So there will be a hundred of users who will start connecting to this store. And now we will see the effect of this sale event in our dashboard, which will show us that how different application or which application is consuming most of the power. So you can see now that there is a spike in this application. So this is now taking most of the compute power of the machine. So most of the energy is attributed to this application. And if you see the other application, which remains quiet at the moment because it is not fighting for the compute, there is no client attached to it. And you can see that the power increase is directly attributed to this application and service within this application. Now, if we also start the other application, it will take a short while to start. But the idea here is that when the other application will also try to fight for the compute power, and it will take the computation, then this energy attribution will be divided to both of the applications. Let me see if it has run. OK, it will take a few seconds. OK, so basically, there is some, there seems to be some problem with that. The other application is not running or something crashing. I don't know. But the idea is that when this application is also trying to like take the compute power, then the attribution power attribution will be divided on both of the applications. So this was what I wanted to show. Now, if I just stop the sale event, then this application will eventually go to the normal use and the power attribution will go to the normal. So this is basically our idea to present, and we are working on its enhancement as well. But this is pretty much what we have for the demonstration. In conclusion, through this Eapside Sys collaboration, this transparency is the game changer. It provides the audit ready data for regulatory compliance, improves data center efficiency through smart virtual machine packing, and enables the true green workload orchestration. By optimizing software based on the energy and carbon data, we aren't just monitoring the future. We're building a more sustainable one. This screencast was developed in the scope of Eapside Sys project. Thank you for watching and see you in the next screencast.
