Horizontal Scaling

[sarfraz sarwar]

how can achieve the down Scalling and how to detected the vm is free or no have any task

[Manoel Campos]

The horizontal down scale is not in fact being performed by a HorizontalVmScaling implementation,

despite there is a setUnderloadPredicate method in such an interface (which I've just removed). 

When a VM becomes underloaded, there is nothing to do with that VM until all its Cloudlets finish executing.

When the VM becomes idle, the DatacenterBroker can perform horizontal down scaling by destroing such VMs.

By default, the broker just destroys VMs just after:

• all submitted Cloudlets from all its VMs are finished and there are no waiting Cloudlets;
  
• or all running Cloudlets are finished and there are some of them waiting their VMs to be created.
  

Therefore, if you want to perform horizontal down scale you have to use the broker to do that,

by setting a Function which defines when VMs should be destroyed.

Check the DatacenterBroker.setVmDestructionDelayFunction documentation for more details.

The MultipleBrokers1 shows how to define a lambda expression to set the vmDestructionDelayFunction.

Basically, if you call broker.setVmDestructionDelayFunction(vm -> 2.0) you are defining that any VM 

will be destroyed after 2 seconds of idleness. 

Check the example documentation for more details.

Finally, if add the single line of code above before the simulation.start() in the LoadBalancerByHorizontalVmScalingExample,

you will enable the down scaling.

You don't need to manually check if a VM is idle, since the broker will do that.

But if you need that, you can call the Vm.getIdleInterval() to check for how long the VM has been idle.

That is exactly what the DatacenterBroker does when a vmDestructionDelayFunction is set.

I've just updated the documentation related to this features and performed some refactoring.

So, update your fork to get the latest version.

Please, tell us if it worked fine.

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

On Thu, Mar 29, 2018 at 10:59 AM, sarfraz sarwar <sarfra...@gmail.com> wrote:

how can achieve the down Scalling and how to detected the vm is free or no have any task

--
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/f9de3782-de60-4c88-830b-d85e0ac2157c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Manoel Campos]

In fact, I've just updated the LoadBalancerByHorizontalVmScalingExample to enable the horizontal down scaling.

Check the example documentation.

If you comment the line broker0.setVmDestructionDelayFunction(vm -> 10.0), you'll see that all VMs are just destroyed at the end of the simulation.

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

[sarfraz sarwar]

i want to destroy VM when Cpu usage is Less then 30% of Any Vm

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

[Manoel Campos]

But what would you do with the running Cloudlets?

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/8d27fb2d-2ce1-4c9a-a4d5-6ab9a21afc89%40googlegroups.com.

[Sarfraz Sarwar]

Thanks for your prompt answer and guidance, However on the basis of whatever we have discussed, I still have few queries, about which I would like to have your expert opinion with reference to CloudSim Plus.

1. How the cloudlets are distributed by the broker among the available VMs. Is there any load balancer module / function that is already incorporated in to CloudSim Plus which works some thing close to Elastic Load balancing / Load balancer of Amazon EC2 auto-scaling. If it is not there, then what is the default policy of CloudSim Plus in this regard, and how can we implement Elastic load balancer of Amazon EC2 in CloudSim Plus. Actually I want to simulate the scenario, in which the broker evenly distributes the cloudlets among the available VMs.
   
2. In LoadBalancerByHorizontalVmScalingExample, the function isVmOverloaded(Vm vm) checks the CPU usage of a single VM, or it checks the usage of all the VMs that have been created till now; to return True or False value.
   
3. How can we implement auto-scaling with a condition like Drop 01 VM, if CPU usage of any of the VM in the group is less than 30 %.  You are right (in your previous post) that down-scaling automatically happens, when the VM is idle at the end of simulation, but I want to implement down-scaling, once the CPU usage of VM is less than 30 or 20 % to make the auto-scaling approach more efficient. With regards to your question in previous post that what we would do with the cloudlets already running on the specific VM, that are required to be dropped; I have few suggestions, listed below in the order of realism (closer to what actually happens during auto-scaling in real cloud infrastructures). Please comment which is feasible / more appropriate to be implemented in CloudSim Plus and how it can be done.
1. The portion of Cloudlet / Cloudlet length, which is already executed should be determined and remaining part of the task / cloudlet should be transferred to another VM in a group, with a comparatively lesser workload. In this way, already executed portion of task would not be wasted and pending task would be continued in new VM. I suppose, it is the ideal way, it should work.
2. If it is not possible, then Cloudlet ID of the task may be noted, and should be shifted to another VM in full, where it is executed from the beginning. However, I think it is not the actual way the real auto-scaling actually behaves in real world. The approach can be simulated as a compromise, if the first approach can not be implemented.
4. How VM initiation / start-up delay can be incorporated in the CloudSim Plus. Is there any default function / parameter for this.
5. How any specific VM can be killed by user during the simulation on the basis of certain condition; to simulate different scenarios like fault tolerance etc.

Sorry for the long list of queries, but actually I am associated with a research task, in which we are reviewing / comparing different real (Openstack / Amazon EC2)  and simulated (CloudSim / CloudSim Plus) cloud infrastructure management tools to ascertain their significance / utility in designing and testing different auto-scaling approaches in vogue.

Thanks for your patience and time in this regard.

[Manoel Campos]

1. How the cloudlets are distributed by the broker among the available VMs.

The DatacenterBrokerSimple uses a Round-Robin algorithm to select a VM for a Cloudlet. The broker has a vmMapper attribute that you can set a Function that maps a Cloudlet to a VM. The DatacenterBrokerSimple uses the method selectVmForWaitingCloudlet as the default Round-Robin policy. Since CloudSim Plus introduced the vmMapper attribute, you can change this behaviour dynamically without requiring the creation of a new class. Check the feature 21 in the README for more details. There are other policies that can be changed in runtime too.

1. Is there any load balancer module / function that is already incorporated in to CloudSim Plus which works some thing close to Elastic Load balancing / Load balancer of Amazon EC2 auto-scaling.

The implementation of HorizontalScaling interface provides this feature so that you can implement such a load balancer for VMs. But there isn't a out-of-the-box AWS ELB-like component that you can use directly. 

1. If it is not there, then what is the default policy of CloudSim Plus in this regard, and how can we implement Elastic load balancer of Amazon EC2 in CloudSim Plus. Actually I want to simulate the scenario, in which the broker evenly distributes the cloudlets among the available VMs.
   

To create such a load balancer for Cloudlets, you have to define a vmMapper Function as I explained in the first topic above.

There isn't an example for this feature, but the way to use it is as follows:

//defines a new vmMapper for your broker (put this line inside the constructor of your simulation class)

//the mapper is set using a method reference (Java 8 feature for functional programming)

broker0.setVmMapper(this::myCloudletToVmMapperFunction);

//This will be a regular method inside your simulation class

private Vm myCloudletToVmMapperFunction(Cloudlet cloudlet){

   //your business logic goes here, that gets the Cloudlet,

  //look for a VM to place it, and return such a VM.

}

1. In LoadBalancerByHorizontalVmScalingExample, the function isVmOverloaded(Vm vm) checks the CPU usage of a single VM, or it checks the usage of all the VMs that have been created till now; to return True or False value.

It checks the usage of any VM linked to a horizontal scaler instance. In the case of the example, all created VMs are linked to a scaler and all scalers use the same function isVmOverloaded to check if the VM passed as parameter is overloaded or not. This way, we can use the same logic (the same method isVmOverloaded) for all VMs.

1. How can we implement auto-scaling with a condition like Drop 01 VM, if CPU usage of any of the VM in the group is less than 30 %. 

A broker represents a customer in the Cloud environement. If you consider the VMs belonging to a given broker as your VM group, you can use the Broker.setVmDestructionDelayFunction to define such a logic there. The way to set a destruction function is similar to the broker's vmMapperFunction.

Check the code snippet below. I have never implemented such a condition, so you have to try and let me know.

//sets the VM destruction using a method reference

broker0.setVmDestructionDelayFunction(this::myVmDestructionDelayFunction);

//This will be a regular method inside your simulation class

private double myVmDestructionDelayFunction(Vm vm){

   //your business logic that defines when the receive VM has to be destroyed goes here

   //the method must return the delay to destroy such a VM (return 0 to destroy it immediately)

}

1. You are right (in your previous post) that down-scaling automatically happens, when the VM is idle at the end of simulation, but I want to implement down-scaling, once the CPU usage of VM is less than 30 or 20 % to make the auto-scaling approach more efficient.

But if you define the vm destruction delay function (as in the new LoadBalancerByHorizontalVmScalingExample), the VMs will be destroyed on demand, as they become idle (and not only at the end of the simulation).

1. With regards to your question in previous post that what we would do with the cloudlets already running on the specific VM, that are required to be dropped; I have few suggestions, listed below in the order of realism (closer to what actually happens during auto-scaling in real cloud infrastructures). Please comment which is feasible / more appropriate to be implemented in CloudSim Plus and how it can be done.

1. The portion of Cloudlet / Cloudlet length, which is already executed should be determined and remaining part of the task / cloudlet should be transferred to another VM in a group, with a comparatively lesser workload. In this way, already executed portion of task would not be wasted and pending task would be continued in new VM. I suppose, it is the ideal way, it should work.

But that would require Cloudlet migration and as the documentation of the HorizontalVmScaling interface states, there is no such a feature in CloudSim Plus or CloudSim. In practice, you don't migrate apps because it's a complex task that cannot be done automatically. For real applications, how would you determine its dependencies and configurations that must be migrated to allow the app to execute in a new VM? There is no way you can determine that. If I have a VM, I can install any software and change any configuration for these softwares and/or OS that would be impossible to track automatically. The provider in fact may not even know which apps I have in my VM. The VM usually is seen as a black box to enable transparent VM migration.

If you use containers, it encapsulates all dependencies and configurations required to run an app, but I don't know if current technologies such as Docker enable to save app's state for container migration. Anyway, if container managers enable transferring app's state in the same way as VM migration does, it makes sense to migrate Cloudlets inside containers. 

However, CloudSim Plus doesn't support container abstration and it's not intended to support in the short or medium term. 

CloudSim 4 includes container support, but the way this feature was implemented (literally by copying and pasting entire packages of classes) made us to create CloudSim Plus as an independent fork.

1. If it is not possible, then Cloudlet ID of the task may be noted, and should be shifted to another VM in full, where it is executed from the beginning. However, I think it is not the actual way the real auto-scaling actually behaves in real world. The approach can be simulated as a compromise, if the first approach can not be implemented.

In real world you migrate entire VMs or containers, not apps. The only way I see to migrate apps from idle VMs is by supporting creation and migration of containers.

 

1. How VM initiation / start-up delay can be incorporated in the CloudSim Plus. Is there any default function / parameter for this.

This is already implemented. You can call Vm.setSubmissionDelay to delay the creation of a single VM or call broker.submitVmList(vmList, delay) to delay the creation of an entire list of VMs. Another way is to create VMs dynamically using a Listener. The new DynamicHostCreation example does exactly that. 

1. How any specific VM can be killed by user during the simulation on the basis of certain condition; to simulate different scenarios like fault tolerance etc.

Fault injection can be simulated for hosts in CloudSim Plus (check the feature #22), but for VMs there isn't anything implemented in CloudSim Plus or CloudSim. The fault for hosts was simulated at PEs level. A host fails completely when all its PEs are set to FAILED. But VMs doesn't have a List of PEs, possibly making the simulation of VM failures tricky. 

This entire fault inject and recovery mechanism was developed by a former member of our group when she was pursuing her master degree.

It took a couple of months to be implemented by this full-time member. Despite I supervised the development and reviewed the entire code, it required a lot of work. 

This way, VM fault injection isn't in our horizon. 

However, it would be a great contribution and I may try to help.

[Manoel Campos]

I was thinking about the VM fault injection and it may not be so difficult to implement.

The host fault injection was tricky because it enables individual PEs to fail, while VMs continue to run with limited CPU capacity. The VMs of a failed host are destroyed just after all PEs fail. The fault injection module also enables fault tolerance, by starting snapshots (clones) of failed VMs into new Hosts.

But if you define the fault at the VM level instead of the PE level, you could create a Status for the VM that can be set as FAILED.

If a VM is randomly set as failed, it is just destroyed (destroying all its running Cloudlets). 

The fault injection module already provides a mechanism to simulate the creation of a VM from a snapshot. 

That feature enables starting up a new VM when one fails.

The code of this module is well organized and documented. A VM fault injection mechanism would be another great contribution.

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

[Sarfraz Sarwar]

Thanks for your detailed reply. It gave me quite an insight into these issues.
I ll implement each one of the issue you guided above, individually and keep you posted on how I ended up with each one of them.

Thanks for your time in this regard !!!!