Vm CPU Vertical Scalling

[Marios Avgeris]

Greetings,

following the VerticalVmScalingExample.java which allocates/deallocates RAM based on the Vm's current RAM utilisation, I'm trying to do something similar with the Vm's CPU. Although native methods exist for RAM & Bandwidth Vertical Scaling, like (Vm) setRamVerticalScaling & (Vm) setBwVerticalScaling, I can't locate any such method for Pe scaling. 

To be more precise, this is the method used in VerticalVmScalingExample.java:

private void createVerticalVmScaling(Vm vm) {

        VerticalVmScaling verticalScaling = new VerticalVmScalingSimple(Ram.class, 0.3);

        verticalScaling.setOverloadPredicate(this::isVmRamOverloaded);

        verticalScaling.setUnderloadPredicate(this::isVmRamUnderloaded);

        vm.setRamVerticalScaling(verticalScaling);

    }

and what I'm trying to achieve might look like this:

private void createVerticalVmScaling(Vm vm) {

        VerticalVmScaling verticalScaling = new VerticalVmScalingSimple(PeSimple.class, 0.3);

        verticalScaling.setOverloadPredicate(this::isVmCpuOverloaded);

        verticalScaling.setUnderloadPredicate(this::isVmCpuUnderloaded);

        vm.setPeVerticalScaling(verticalScaling); // Method Implementation Missing

    }

Is this even the correct way of thinking? Am I missing something?

Thanks in advance.

[Manoel Campos]

Hello Marios,

Vertical and Horizontal VM Scaling features are under development yet (planned for CloudSim Plus 1.2.0). The Horizontal scaling is performing upscaling but it is needed to implement downscaling yet. I have started to work on these features but I paused due to other commitments. 

The fact there isn't yet the method you are looking for is due to some questions that I raised in the Issue #7. But you are thinking correctly and the code should work exactly as you proposed. 

This week I'm finishing a paper and then I will restart to work on this feature. I hope to spend about one more week to finish it.

Please read the Issue #7. It would be great to discuss the implementation of this feature here. If you have any comments or suggestions, feel free to present them.

You said that you intend to use CloudSim Plus for you PhD. May I ask from which university you are?

I'm also a PhD student at the University of Beira Interior in Portugal.

Finally, we are kindly asking users to give a star in the GitHub's project page :)

Manoel Campos da Silva Filho Software Engineer

Computer Science and Engineering PhD Student at University of Beira Interior (Portugal)

Professor at Federal Institute of Education, Science and Technology of Tocantins (Brazil)

http://manoelcampos.com

 about.me

--
http://cloudsimplus.org
---
You received this message because you are subscribed to the Google Groups "CloudSim Plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plus+unsubscribe@googlegroups.com.
To post to this group, send email to clouds...@googlegroups.com.
Visit this group at https://groups.google.com/group/cloudsim-plus.
To view this discussion on the web visit https://groups.google.com/d/msgid/cloudsim-plus/5946cfac-be12-4746-9533-653c7901e797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marios Avgeris]

Hi Manoel,

I've already given a star, I think you're doing some great work implementing the missing functionality of the original CloudSim. Yes I am a PhD student as well, at National Technical University of Athens (NTUA) in Greece and I intend to try my hands on Cloud/Fog resource use optimisation, leveraging control theory.

Having read the concerns at Issue #7 I indeed believe that adding a whole new CPU core would be a sane scaling tactic. However, maybe scaling the MIPS of a VM might be an interesting approach too?

Also a have a rather technical question; will the eventual CPU scaling have any impact on the actual simulation? Like you said, will more Cloudlets be able to be executed inside an upscaled VM?

To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plu...@googlegroups.com.

[Manoel Campos]

Thank you for the star :D

Well, adding a new CPU is a way hypervisors support. I haven't seen a way for hypervisors to limit or increase the MIPS available for a VM, that may be translated into the CPU frequency in GHz. I know that current operating systems can control CPU frequency on a DVFS-enabled server. However, I haven't seen this capability in hypervisors. Thus, I think the first option is better by now.

About your question, Cloudlets can really benefit from new CPUs since that if we have more Cloudlets than CPUs inside a given VM, such cloudlets will compete for CPU. Adding new CPUs will reduce the competiton and, consequently, the performance of the Cloudlets, making them to finish earliear.

Even scaling the MIPS capacity of a CPU can bring benefits for running Cloudlets. Just doing that won't reduce competition, but will make a Cloudlet to execute more instructions per CPU timeslice than before, reducing their completion time.

The point is that, for real systems such as distributed web applications, there may be a limit to scale CPU capacity (in any of the discussed ways) that brings performance improvements. In this example, as the number of access to the web application increases, just scaling the CPU will not be enough. It will be required to create new VMs to balance the load. It's when VM Horizontal Scaling comes in handy.

CloudSim Plus accordingly provices both mechanisms to perform experiments.

I'll restart to work on this feature this week and I post updates here.

Manoel Campos da Silva Filho Software Engineer

Computer Science and Engineering Ph.D. Student at University of Beira Interior (Portugal)

Professor at Federal Institute of Education, Science and Technology of Tocantins (Brazil)

http://manoelcampos.com

 about.me

To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plus+unsubscribe@googlegroups.com.

To post to this group, send email to clouds...@googlegroups.com.
Visit this group at https://groups.google.com/group/cloudsim-plus.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudsim-plus/540a1f80-20d3-404b-b3c5-1d35e0509bc5%40googlegroups.com.

[Marios Avgeris]

I'm eagerly looking forward to seeing that kind of CPU scaling implemented. I don't think something similar exists in any cloud simulator.
I'll be the first to try it out and report back! :D

[Manoel Campos]

Hello Marios, 

As I finished a paper I was working on sooner than expected, I've been working on this feature and a new development version is available.

It's not finished or completely tested yet. The public interfaces may change yet.

I introduced a new VerticalVmCpuScalingExample and renamed the old one to VerticalVmRamScalingExample.

The Vm CPU vertical scaling works as follows:

1. A set of Cloudlets are created and submitted to a Vm, with no delay (they start running as soon as the simulation is started). Each one of these Cloudlets has increasing length and requires 2 PEs.
2. Other set of Cloudlets are created, but each one with a different arrival time (defined by the submissionDelay attribute), making them start executing in different times. That makes the CPU utilization to increase gradually. Each delayed Cloudlet requires just one 1.
3. At some point in time, the CPU usage will reach the upper threshold (currently defined as 80%) and a new Pe will be added to the Vm.
4. As new Cloudlets arrive, if the CPU usage is higher than the upper threshold, new PEs will be added to the VM.
5. As Cloudlets start to finish, the CPU usage will decrease. When it falls below the under utilization threshold, VM PEs starts to be removed.
6. The number of PEs to add or remove is defined in the VerticalVmScalingSimple constructor.
   

Please check the examples log to understand how it's working.

There are some questions to discuss yet. For instance, I have defined the scaling factor for PEs as an absolute value indicating the number of PEs to add or remove each time a threshold is reached. However, as you can see at the example, the pace in with PEs are removed, when a under utilization is detected, may not be fast enough to reduce SLA violation time.

Therefore I have to think the best way to implement the scale factor. Maybe using a percentage value (as it is working for other resources such as Ram and Bandwidth) may be better. For some situations, perhaps the developer wants to define the scaling as an absolute value, but for others, he/she may want the scaling object to automatically define the number of PEs to increase or decrease to move the VM from the under/overload state.

This is the best approach to reduce SLA violation time, but I have to think how to design it yet.

If you are concerned about implementation details, I have opened a new ticket that explains current issues with this implementation.

These issues don't affect users or the public interfaces provided. But there are some design issues that need to be improved further.

Anyway, I appreciate if you could test the new features and give me some feedback.

Thanks in advance.

Manoel Campos da Silva Filho Software Engineer

Computer Science and Engineering Ph.D. Student at University of Beira Interior (Portugal)

Professor at Federal Institute of Education, Science and Technology of Tocantins (Brazil)

http://manoelcampos.com

 about.me

To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plus+unsubscribe@googlegroups.com.

To post to this group, send email to clouds...@googlegroups.com.
Visit this group at https://groups.google.com/group/cloudsim-plus.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudsim-plus/83251b1a-d9f8-4ddd-b811-16cf2adfe0a4%40googlegroups.com.

[Manoel Campos]

Hello Marios,

I re-design the scaling features and I think the public interfaces are stable now.

The horizontal VM scaling example (LoadBalancerByHorizontalVmScalingExample) is working as before: you define the Predicates which indicates when a VM is under and overloaded and the example will create or destroy VMs as required to balance the load (currently, just VM creation is being performed).

The VerticalVmScaling went through a major re-design. Different from the HorizontalVmScaling, it doesn't accept Predicates to define if a VM is under or overloaded anymore. Instead, it requires two Functions to be set: one to define the lower resource utilization threshold and other for the upper threshold. 

In the original CloudSim, classes such as those ones implementing the VmAllocationPolicy, thresholds are defined as an attribute, imposing the threshold to be static. To define a dynamic threshold, other classes had to be created in CloudSim. 

These Functions in CloudSim Plus enable defining the resource usage threshold in a static or dynamic way, as the developer wish.

They also enabled to create different types of vertical resource scaling:

• Gradual: it will increase or decrease the resource capacity, according to the scalingFactor defined (that is a percentage of the current resource capacity). This kind of vertical scaling may need more time to move a VM from an over or underload state, maybe causing longer SLA violation times;
• Instantaneous: when an under or overload situation is detected, it will automatically compute the amount of resource that needs to be increased/decreased to move the VM from the under/overload state. This way, it reduces the SLA violation time compared to the gradual scaling.

To use these different kinds of vertical VM scaling you simply have to set a ResourceScalingType instance to the VerticalVmScaling object, such as:

verticalScaling.setResourceScalingType(new ResourceScalingInstantaneous());

This example uses the instantaneous scaling. The gradual scaling is the default one, so you don't have to set it.

I think the way these features are implemented give high flexibility for the developer.

If you need any help with these features, please let me know.

I need to perform more tests before releasing the new version 1.2.0 at Maven Central.

[Marios Avgeris]

Hi Manoel,

as it seems this is fantastic news! This week is spring break in Greece so I will go slow on my testing, but I will report back as soon as possible.

[Manoel Campos]

Thank you and don't worry.

I'm taking a break too.

--

http://cloudsimplus.org
---
You received this message because you are subscribed to the Google Groups "CloudSim Plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plus+unsubscribe@googlegroups.com.
To post to this group, send email to clouds...@googlegroups.com.
Visit this group at https://groups.google.com/group/cloudsim-plus.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudsim-plus/aa301c3f-128d-472d-94c1-7dc1d3fac50c%40googlegroups.com.

[Marios Avgeris]

Hi Manoel, 

hope your break was refreshing.

I'm currently working on creating some examples, following the VerticalVmCpuScalingExample.java. In this simulation, if I understand correctly, when the CPU utilization reaches an upper/lower threshold, the Vm's CPU is upscaled/downscaled respectively. Both of these thresholds are specified in the following methods:

...

private double lowerCpuUtilizationThreshold(Vm vm) {

        return 0.4;

    }

...

private double upperCpuUtilizationThreshold(Vm vm) {

        return 0.8;

    }

...

However, when I executed your code, I noticed that, while the Vm's CPU is downscaled (from 18 vCPUs to 17 vCPUs) when the CPU Usage drops from 44.44% to 35.29%, as expected, it doesn't downscale any further although the Usage continues to drop below the lower threshold. The log of the forementioned behavior:

...

20.10: DatacenterBrokerSimple2: CloudletSimple 6 received

Time   20.1: Vm 0 CPU Usage:  44.44% (18 vCPUs. Running Cloudlets: #5)

21.10: DatacenterBrokerSimple2: CloudletSimple 1 received

Time   21.1: Vm 0 CPU Usage:  35.29% (17 vCPUs. Running Cloudlets: #4)

22.10: DatacenterBrokerSimple2: CloudletSimple 2 received

Time   22.1: Vm 0 CPU Usage:  23.53% (17 vCPUs. Running Cloudlets: #3)

23.10: DatacenterBrokerSimple2: CloudletSimple 3 received

Time   23.1: Vm 0 CPU Usage:  11.76% (17 vCPUs. Running Cloudlets: #2)

24.10: DatacenterBrokerSimple2: CloudletSimple 5 received

Time   24.1: Vm 0 CPU Usage:   5.88% (17 vCPUs. Running Cloudlets: #1)

Time   25.1: Vm 0 CPU Usage:   5.88% (17 vCPUs. Running Cloudlets: #1)

Time   26.1: Vm 0 CPU Usage:   5.88% (17 vCPUs. Running Cloudlets: #1)

...

I don't think that this is meant to be the expected behavior as it leads to resource overutilization. Is there a problem with the ResourceScaling used in this particular example, or maybe with the Listener regarding the Vm Scaling procedure?

Otherwise great work so far!

Have a nice afternoon

[Manoel Campos]

Hello Marios,

Thanks for asking. It was really refreshing. Staying time with family is always good.

And I hope you had a great time too.

About the example, it's really an issue that I haven't realized. I guess the problem is with the ResourceScaling implementation.

I'm working on a presentation of the CloudSim Plus paper, accepted to the IEEE IM 2017 conference, and I'll check it tomorrow. 

Thanks for the help.

Manoel Campos da Silva Filho Software Engineer

Computer Science and Engineering Ph.D. Student at University of Beira Interior (Portugal)

Professor at Federal Institute of Education, Science and Technology of Tocantins (Brazil)

http://manoelcampos.com

 about.me

--

http://cloudsimplus.org
---
You received this message because you are subscribed to the Google Groups "CloudSim Plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudsim-plus+unsubscribe@googlegroups.com.
To post to this group, send email to clouds...@googlegroups.com.
Visit this group at https://groups.google.com/group/cloudsim-plus.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudsim-plus/d14df023-59a4-405f-b1ad-0d9a73495602%40googlegroups.com.

[Manoel Campos]

Hello Marios,

The issue was caused by a conversion from double to long, into the lambda expression used by the verticalCpuScaling.setResourceScaling(), inside the VerticalVmCpuScalingExample. The example sets a custom ResourceScaling object using that lambda expression (different from using the RsourceScalingGradual or ResourceScalingInstantaneous classes provided). This ResourceScaling computes the absolute amount of resource to scale up or down as twice the value defined by the scalingFactor attribute. 

As VM CPU usage falls too much, the value returned by such a lambda expression starts to be lower than 1.0, which converting to long resulted in 0. This way, no scaling was performed after that point.

I changed the method to double and internally it calls a Math.ceil() to round the value up. I also performed some refactoring and improved documentation.

The comments show the differences of using: (i) a ResourceScaling such as the ResourceScalingInstantaneous; (ii)  a custom one such as the defined by the lambda expression; or (iii) not setting a ResourceScaling at all (which means the ResourceScalingGradual will be used as default).

Check the commit message for more details. If you need something, feel free to keep in touch.

Thank you for collaborating.

Manoel Campos da Silva Filho Software Engineer

Computer Science and Engineering Ph.D. Student at University of Beira Interior (Portugal)

Professor at Federal Institute of Education, Science and Technology of Tocantins (Brazil)

http://manoelcampos.com

 about.me