In this section, a detailed description of the CloudSim tool is presented, including the entities elements, the simulation life cycle, the core events passing operation and the dynamic characteristic of CloudSim.
2.3.1 Entities
CloudSim is a framework for modeling and simulation of Cloud Computing infras-tructures and services. Figure 11 shows the high level modeling of CloudSim where components with continuous border lines are called "entities" (see 2.3.3). An entity has the ability to send and to receive events to each other (see 2.3.3), and also to interact with the other components (dash lines).
One major component of CloudSim is the Datacenter entity which aims to model a real Datacenter: it houses a list of Hosts (physical servers machines) and a list of storage (physical storage devices), both with dened hardware specications (RAM, Bandwidth, Capacity, CPUs for the Host; Capacity, SeekTime, Latency and maxi-mum Transfer Rate for Storage).
CloudSim supports server virtualization so each host runs one or more Virtual Ma-chines (VMs). Each VM is assigned to a Host according to specic VM Allocation Policies dened for a particular Datacenter. Further, each host allocates resources to VMs according to specic VM Scheduler Policies dened for a particular host.
Then, Cloud application jobs are managed internally by VMs according to various Cloudlet Scheduler Policies dened for each particular VM.
A Cloudlet models the Cloud-based application services in CloudSim. It represents a job, a request or a task to be executed. The Datacenter Broker models the
inter-Figure 11. CloudSim high level modeling.
mediary layer between end users and cloud providers responsible to meet the user application's Quality of Services (QoS) needs. Thus this component supervises the cloudlet arrival rate for a specic data center.
Finally, CloudSim core simulation implements automatically two entities: the Cloud-InformationService (CIS) entity, responsible for resource registration, indexing and discovery, and the CloudSimShutdown entity, responsible to signal the end of the simulation to the CIS entity. These entities should not be created by the user himself since the core simulation does it.
2.3.2 Life Cycle
In CloudSim, each simulation is following a specic life cycle (see Figure 12) that needs to be chronologically followed in order for the simulation to work properly.
Figure 12. CloudSim Life Cycle.
Firstly, CloudSim common attributes such as "trace ag", "calendar" and "number of user" are initialized. CouldInformationService and CloudSimShutdown entities are created. This has to be done before creating any other entities.
Secondly, Broker and Datacenter(s) entities are created. As explained in 2.3.1, Datacenter is composed of Hosts machines. Thus, a hosts List is also created and passed as parameter in the Datacenter constructor. Similarly, a VMs List and Cloudlets List is created and sent to the Broker entity before the simulation starts.
Thirdly, all the entities threads are switched to running state and the core simulation of CloudSim is executed (see 2.3.4). The simulation can be either stopped if there is not more events in the queue or if the simulation reached a specic terminationTime or if an abruptTerminate event appeared due to an unexpected problem.
Fourthly, once the simulation is nished, the nal result is printed. Note that the nal result can be formatted in a dierent way depending on the scenarios executed.
Also, intermediary results can be printed during previous phases of the life cycle.
2.3.3 Events Passing
CloudSim is an event-based simulator, so each step of the simulation is triggered by an event. Events are the heartbeat of CloudSim simulation environment: if no more events are generated, it is the end of the simulation.
All communication between the main CloudSim components are accomplished by the events passing activity. Each event can be seen as messages with a source ID and a destinations ID: only an entity can send or receive an event. There are four dier-ent dier-entities: CloudSimShutDown, CloudInformationService, Datacdier-enter(s), and the Broker. Their IDs are assigned consistently (Table 2) according to the CloudSim Life Cycle (see 2.3.2).
Each event stores a unique Tag number corresponding to a specic happening (Ex-ample: VM_DATACENTER_EVENT, END_OF_SIMULATION) or indicating the type of ac-tion to perform by the recipient (Example: VM_CREATE, CLOUDLET_SUBMIT). Hence, the recipient of an event has to implement a method which executes this particular tag number. The execution can be a simple "print out" for the user or a more com-plex sequence of sub methods which will eventually generate new events. Finally, an event have a data parameter of type Object used to carry a Cloudlet or datacenter characteristics or any other information that need to be transfer with the event.
2.3.4 Future Queue and Deferred Queue
Unlike GridSim [76], the core simulation of CloudSim framework is a dynamic en-vironment by reason of two event queues: Future Queue and Deferred Queue (see Figure 13). All events generated by entities during the runtime are added to the Future Queue and sorted by their time parameter (tX ), "time at which the event should be delivered to its destination entity [for execution]" [43]. As explained in 2.3.3, the execution of an event can result in the creation of new events, with similar or dierent "Time" parameter. In other word, events generation numbers (Event X ) do not determine the order in Future Queue. Afterwards, the "top of the queue"
event in Future Queue is moved to the Deferred Queue and will be processed at the next clock tick. If next event in the Future Queue has the same time, it will be moved as well, and so on.
Figure 13. Example of queue management during three clock ticks.
In the example diagrammed in Figure 13, Event1 is executed rst and generates
Event3. Then Event2, having the same Time parameter, is executed too and gen-erates Event4 and Event5. No more events are in the Deferred Queue at this time.
Afterwards, Event4 being at the "top of the queue" in Future Queue is moved to the Deferred Queue. A new event is in Deferred Queue so it is executed during the next tick and it generates Event7. No more events are in the Deferred Queue so the Event5 being at the "top of the queue" in Future Queue is moved to the Deferred Queue. Also, Event6 has the same time parameter so it is moved as well in Deferred Queue. The next step would be to execute Event4, then Event5 which will eventually generate new events.