Virtualization technology is not new; If you have ever read about mainframes like IBM CP/CMS, these were the first computers that implemented virtualization at the hardware level. 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 a period of time, as the cost of computing decreased, it became distributed to personnel. This change helped virtualization to diversify its role in storage, network, and application execution environment and has become a well-matured technology.

Internet Accelerated Growth

Since 1990 the Internet became 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 regarding workload and operational and maintenance costs. Apart from this, increased use of computation requires intense cooling measures, leading to the indirect contribution of greenhouse gas emissions as most electricity is produced through burning natural resources.

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

Adoption of Virtualization

Virtualization technology 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 the hypervisor, also known as virtual machine managers. There have been various types of Virtualization in cloud computing based on the type of resource involved.

Additionally, virtualization provides a great opportunity to build elastically scalable systems 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, testing on a real cloud is impossible.

Cloud Computing Simulation using Cloudsim

Dr, Raj Kumar Buyya and his team presented the cloudsim and addressed this problem, which supports the modeling and simulation of large-scale Cloud computing data centers.

This tool is an API developed using 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.

These classes produce similar behavior during the simulation using 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.

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 allocating 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.

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 processes, 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 state-of-the-art.

Virtual Machine Allocation Policy in Cloudsim

The real cloud-based virtual machine allocation engine allocates the created virtual machine to a suitable host.

Similarly, the cloudsim virtualization simulation engine has a model implementation in VmAllocationPolicy.java and VmAllocationPolicySimple.java.

The datacenter class uses these classes to find the right mapping of the VM to the 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 that real cloud-based virtual machines are just abstract machines requiring a host to fulfill their resource request. Also, a single host may manage more than one virtual machine. So to support the scheduling of Virtual machines, a VM Scheduler policy exists.

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.

Conclusion

Every individual action the real-world virtual machine manager requires is modeled within the cloudsim simulation toolkit using Java classes. These classes are exposed as an API and are highly extensible.

This allows the cloud computing researcher to test and benchmark all possible hypotheses on a state-of-the-art tool.

As a researcher in edge and fog computing, I know how crucial it is to have the right tools to simulate complex scenarios.

That’s why I highly recommend iFogSim, a powerful simulation toolkit designed specifically for our field.

With iFogSim, you can easily model and test various edge and fog computing scenarios, helping you optimize your research and gain a deeper understanding of this rapidly evolving domain.

Trust me, iFogSim will be a game-changer for your research projects!

In this blog, I will discuss the Model Entities that ifogsim integrates to support the simulation of fog computing scenarios.

so let’s get started…

What is an Entity? and what is its 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 the connected cloud for further processing.

Now to simulate the behavior of real-world Fog computing, the iFogsim simulation toolkit provides a set of APIs that contains a set of classes representing the components available in the real-world Fog setup. All these sets 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 the 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 implement 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:

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 containing the signature for its sensor & corresponding actuator.
FogBorker: This class simulates the broker/agent node, primarily responsible for the load(job/task) distribution of the computing devices available on the network.
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 propagated to the network for their computation
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.
EndDevice: This class models the device other than the sensor or actuator and is generally used for the purpose of additional network device simulations.
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
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.
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, the hierarchy proceeds through PowerDatacenter followed by the Datacenter class. So the FogBroker and FogDevice inherit the majority of their features from the basic cloudsim simulation toolkit classes and then extend more features to support the iFogsim-based Fog simulation scenarios.

Why is SimEntity inherited?

SimEntity is a class from the basic Cloudsim simulation toolkit and it has an abstract implementation of the Cloneable class. This class includes the implementation of core methods used for scheduling events through an entity which are overloaded as the schedule() method, startEntity(), shutdowEntity() & processEvent() methods define the default behaviors for the individual entities by overriding 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 in turn 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 further simulation proceedings are done through the entities themselves. 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 of 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 published as “Essential iFogsim Tutorials“

Cloudsim Tutorials

Simulating Virtualization in Cloudsim