Simulating Virtualization in Cloudsim

Virtualization technology is not new, If you ever read about mainframes like IBM CP/CMS, these were first of it a kind of computer that implemented the virtualization at the hardware level. Back then in the early 1970s, the cost of computing resources was very high they were supposed to be shared for various operational purposes with application backward compatibility.

Then over the period of time, as the cost of computing decreased it become distributed to personal. This change helped virtualization to diversify its role in storage, network, application execution environment and has become a well-matured technology.

Also, since 1990 when the internet becomes public, within 15-20 years there has been exponential growth in the websites and applications hosted across the internet. This growth has intense stress on the service providers in terms of workload, operational, and maintenance costs. Apart from this increased use of computation required intense cooling measures which leads to indirect contribution of greenhouse gas emissions as most of the electricity is produced through burning the natural resources.

The service providers like Google, Microsoft, AWS worked around this problem and used virtualization technology as a great tool to have a sustained comprehensive computing practice by integrating Virtualization in cloud computing.

This is how virtualization becomes a fundamental component of a cloud computing stack because it allows the creation of a secure, customizable, and isolated abstract execution environment for running the application. This abstract execution environment completely separates the underlined host through the inception of hypervisor which is basically virtual machine managers. There have been various types of Virtualization in cloud computing, based on the type of resource is involved.

Apart from this, virtualization provides a great opportunity to build elastically scalable systems, which are capable of provisioning additional capacity with minimum cost as the underlying host machines are shared among various virtual machines. Ultimately leading to the Infrastructure as a service that can be offered on a pay as you go model.

Even though this technology has brought a huge difference to the real computing paradigm but as a cloud computing researcher it is really difficult to leverage such a commercial system, as its usage for testing the research hypothesis will cost you based on what resources require for how long. So without funding, it is not possible to test on a real cloud.

To address this problem Dr, Raj Kumar Buyya and his team worked presented the cloudsim which basically supports the modeling and simulation of large-scale Cloud computing data centers. This tool is basically an API developed using a java programming language.

The interesting point of this tool is that the various components of this real-world virtualization were modeled in the form of java classes and during the simulation, these classes produce similar behavior using the logical and mathematical models.

Let’s take an example of AWS EC2 instance “t4g.micro” the configuration that it defines is vCPU 2 with consistent baseline compute availability of 10%, 1 GB RAM, up to 10 GB of EBS, and up to 5 Gbps of network bandwidth.

Just like above the virtual machine configuration can be defined using a few lines of java code. The Virtual machine model behavior is implemented in Vm.java class. This class defines all the attributes like processing elements, RAM, Storage Size, Bandwidth, computation capacity, etc. The following snippet demonstrates how these attributes are initialized before the simulation process.

// VM description
int vmid = 0;
int mips = 1000;
long size = 10000; // image size (MB)
int ram = 512; // vm memory (MB)
long bw = 1000;
int pesNumber = 1; // number of cpus
String vmm = "Xen"; // VMM name

// create VM
Vm vm = new Vm(vmid, brokerId, mips, pesNumber, ram, bw, size, vmm, new CloudletSchedulerTimeShared());

Here, it is important to mention that just like a real cloud, cloudsim supports the allocation of more than one CPU to Vm through the attribute pesNumber. But the allocation is only possible if the underlined simulating host has enough resources to support the requested resources.

Now in the real-world cloud-based system, every virtual machine contains an execution environment to accommodate the application processing, where the number of processes run on this abstract virtual machine and based on the execution of these process the output/ response is either displayed to the user or sent back to the requesting entity. These process executions are intern managed through schedulers like Round-robin/ shortest job first etc.

On a similar note to support the simulation of virtualization in the cloudsim simulation toolkit, there exist four classes CloudletScheduler.java, CloudletSchedulerTimeshared.java, CloudletSchedulerSpaceShared.java, CloudletSchedulerDynamicWorkload.java.

These class models facilitate the cloudsim simulation engine to imitate the real-life scheduling process and are by far the state of the art.

The real cloud-based virtual machine allocation engine takes care of allocating the create a virtual machine to a suitable host, similarly, the cloudsim virtualization simulation engine has a model implementation in VmAllocationPolicy.java and VmAllocationPolicySimple.java. These classes are used by the datacenter class to find the right mapping of VM to Host. This task of mapping is performed through the processVmCreate() method of Datacenter.java class the logic is as follows:

protected void processVmCreate(SimEvent ev, boolean ack) {
		Vm vm = (Vm) ev.getData();

boolean result = getVmAllocationPolicy().allocateHostForVm(vm);

if (ack) {
	int[] data = new int[3];
	data[0] = getId();
	data[1] = vm.getId();

	if (result) {
		data[2] = CloudSimTags.TRUE;
	} else {
		data[2] = CloudSimTags.FALSE;
		}
	send(vm.getUserId(), CloudSim.getMinTimeBetweenEvents(), CloudSimTags.VM_CREATE_ACK, data);

	}

	if (result) {
		getVmList().add(vm);
		if (vm.isBeingInstantiated()) {
			vm.setBeingInstantiated(false);
			}

		vm.updateVmProcessing(CloudSim.clock(), getVmAllocationPolicy().getHost(vm).getVmScheduler()
					.getAllocatedMipsForVm(vm));
	}

}

Also, we know the real cloud-based virtual machines are just an abstract machine it requires a host to fulfill its resource request. Also, a single host may manage more than one virtual machine. So to support the scheduling of Virtual machine there exist a VM Scheduler policy.

To support the same in simulation, the cloudsim simulation toolkit implements a VmScheduler.java, VmSchedulerTimeshare.java, VmSchedulerspaceShared.java, and VmSchedulerTimesharedoversubscription.java. These VmScheduler classes are called every time the VM processing is updated means that whenever the cloudsim simulation engine is progressing the cloudlet/task processing intern updates the VM processing using the updateVmsProcessing() method available in Host.java class.

So every individual action that is required to be performed by the virtual machine manager is modeled within the cloudsim simulation toolkit and this allows the cloud computing researcher to test all the possible hypothesis and benchmark it on a state of the art tool.

iFogsim Entities

What is an Entity? and what is it’s Role?

Entities are the building blocks for the Cloudsim as well as iFogsim simulation toolkit.

The iFogsim simulation toolkit is basically used for simulating the scenarios based on Fog computing, where the workload is supposed to be submitted to the nearest available computing resource, if not possible only then it will be moved to connected cloud for the further processing.

Now to simulate the behavior of the real world Fog computing, iFogsim simulation toolkit, provides a set of API’s which contains a set of classes representing the components available in the real world Fog setup. All these set of classes are known as the Entities, because they actively take part in the simulation process by initiating the process events and passing the messages to share their work with other entities or status of work under processing.

As the iFogsim uses the simulation engine from cloudsim all these entity classes are ultimately derived from the simentity.java class and implements the processEvent() or processOtherEvent() method to support the actions required during the simulation process.

Entities in iFogsim simulation toolkit

There are eight entities available in iFogsim:

  1. FogDevice: This class simulates the computing resource, responsible for the actual computation of the tasks/jobs submitted to the network. The jobs are being shared through the Tuples class instance contains the signature for its sensor & corresponding actuator.
  2. FogBorker: This class simulates the broker/agent node, primarily responsible for the load(job/task) distribution of the computing devices available on the network.
  3. Sensor: This class is the end node and is going to simulate the working of some sort of Hardware, like a camera, temperature measuring device, etc. This is the source from where the tuples are generated representing the job/task and propagate them to the network for their computation
  4. Actuator: This class is again simulating the end node which is again representing some sort of hardware device which will be activated based on the processing of the tuple produced by the sensor class. This can be a storage device, motor, furnace, etc.
  5. EndDevice: This class models the device other than the sensor or actuator and is generally used for the purpose of additional network device simulations.
  6. Switch: This class represents a model of a real-life switch, whose primary role is to propagate the data among the network nodes. Here, in iFogsim, it propagates the tuples across the topology
  7. Link: This class is one of the most important classes as this defines the model of communication medium and defines the connections between the Sensor, FogDevice, FogBroker, Actuator, etc.
  8. Controller: This class is responsible for the simulation of allocation of application modules which are basically simulating over the fog devices and are in-turn processing the tuples through modules. Primarily controller class is going to do the scheduling of AppModules to the network nodes and manage their working.

Entity Class Hierarchy

Here in the above diagram, you can clearly see that SimEntity is the parent class for all the entities. Also in the case of FogBroker, the hierarchy proceeds through the PowerDatacenterBroker followed by DatacenterBroker as well as FogDevice, hierarchy proceeds through PowerDatacenter followed by Datacenter class. So the FogBroker and FogDevice inherits the majority of their features from the basic cloudsim simulation toolkit classes and then extends more features to support the iFogsim based Fog simulation scenarios.

Why SimEntity is inherited?

SimEntity is a class from the basic Cloudsim simulation toolkit and it has an abstract implementation of Cloneable class. This class includes the implementation of core methods used for scheduling events through an entity which are overloaded as schedule() method, startEntity(), shutdowEntity() & processEvent() methods define the default behaviors for the individual entities through overriding in the child classes, the run() method is used to process the events by the entities during the simulation runtime. So using this class as the parent reduces the redundancy of the code required by each individual entity and allows the developers to put up abstraction for the underlying simulation engine.

How does individual entity process events?

Every individual Entity is responsible for its execution of a particular event, whenever its call is made by the other entity through the simulation engine. These events processing are initiated through the inherited run() method from SimEntity class, which ultimately sends a call to the processEvent() method with event instance as a parameter, which inturn sends a call to processOtherEvents() method. These events are unique and defined inside the FogEvents.java class. Now based on the FogEvent the further method/procedure is called to process the desired action corresponding to the specified event. For example: The FogDevice() is supposed to process an event “FogDevice.TUPLE_ARRIVAL” then in this case the method processTupleArrival(ev) will be called for further processing.

Code Snippet of procesOtherEvent() method of FogDevice.java

Therefore, all the FogEvents are associated with procedures and the simulation engine periodically sends the call to individual entities with event details and the further simulation proceedings are done through the entities itself. Once the processing is over the result is sent back to the simulation engine based on which there may be further scheduling of new events to other entities.

Here, we have a video explaining all the details about the entities, this video will help you have a better understanding on how these entities are processing the individual FogEvents.

In case you are interested to learn more about iFogsim simulation scenario implementations. Feel free to have a look at a Unique course prepared to accelerate the learning for the researchers at https://www.superwitsacademy.online/essential-ifogsim-tutorials