data center modeling and simulation using omnet++

Data Center Modeling and SimulationUsing OMNeT++Asad W. Malik and Samee U. Khan

Advances in cloud computing have rendered Service Oriented Architecture (SOA)eminent. In addition, SOA offers support for cloud computing solutions. Due tomaster worker paradigms, SOA is extensively adopted for cluster, grid and Cloudenvironment. The term Cloud computing is relatively new, compared to others. Cloudcomputing is define as; it is a pool of easily available, shared computing resources,including servers, services, storage and networks. Cloud comprises of computingservers arranged in racks and are connected with multiple tiers of switches to pro-vide redundancy; this arrangement of equipment is termed as data centers. A singleCloud may comprise of multiple data centers connected through high speed commu-nication links. Data centers have gained great publicity in recent years; however, theconcepts of data center simulation models, communication protocols and analysisof data center traffic flow, remain relatively been less explored. It is important tounderstand how these systems work. Given the complexity of these systems, mod-els and simulations are the best way to gain an insight into the workings of suchsystems. In this chapter, we provide a step by step tutorial for building traditionalthree tier data center simulation model using OMNeT++. The chapter is organizedas follows: Section I presents core modeling and simulation concepts. In section IIdifferent architectures of data centers are discussed in detail. A step by step guide tomodeling data center architectures in OMNeT++ is presented in Section III. Finally,Section IV concludes this chapter.

A. W. Malik (�)Department of Computing, NUST—School of Electrical Engineering andComputer Science, Islamabad, Pakistane-mail: [email protected]

S. U. KhanDepartment of Electrical and Computer Engineering,North Dekota State University—NDSU, Fargo, USAe-mail: [email protected]

© Springer Science+Business Media New York 2015 839S. U. Khan, A. Y. Zomaya (eds.), Handbook on Data Centers,DOI 10.1007/978-1-4939-2092-1_28

840 A. W. Malik and S. U. Khan

Time Stepped

Event Stepped

Simulation Time

Fig. 1 Simulation model

1 Introduction to Modeling and Simulation (M&S)Methodology

Modeling and simulation of systems has aided in the understanding of system be-havior since early 1990’s. These concepts of modeling and simulations are beingadopted in many fields, ranging from computing to architectural designs. Models areconsidered as abstractions of real entities; whereas simulation is used to analyze thebehavior of these entities under a set of conditions, which may be otherwise difficult[1]. Many crucial decisions are based on models or simulations, especially in timecritical applications. In addition, models prove to be cost effective and involve littleor no risk when analyzed. Over the last few decades, modeling and simulation hasbecome one of the most significant areas of research. Different techniques have beendeveloped not only to study real time systems but also to improve system.

Modeling and Simulation can be further categorized as continuous or discreteevent simulation. Within the simulation domain, continuous simulation is analyzingsystem response over a given time interval. These models are often used to computenumerical solutions of differential equations. Digital circuits are a common exampleof a continuous simulation models.

In discrete event simulation model, the system being simulated only changesstate at discrete points in simulated time and are presented in chronological orderingof events [2]. Discrete Event Simulation (DES) manages time dependent eventsand is further categorized into Time and Event step simulation models; Time StepSimulation (TSS) is employed for events that require monitoring under fixed timeintervals. The allocation of time interval depends on various factors, such as pendingevents in a process queue; whereas Event Step Simulation (EST) manages suchevents that are removed from the queue after having been processed according to thetime stamp on each of these. Event step simulation eliminates the need for time stepsimulation. Figure 1 shows the differences between time and event step simulations.The event step simulation models are used in communication networks and flownetworks [2, 3].

Data Center Modeling and Simulation Using OMNeT++ 841

1.1 Parallel Discrete Event Simulation—PDES

A Parallel simulation or a Parallel Distributed Simulation (PDS) is an execution of atask over multiple processors or distributed machines. This reduces execution timesubstantially compared to sequential execution. However, the results obtained fromparallel simulation must match against the results of sequential simulation. Withtheir inherent ability to distribute simulation tasks, PDS overcome the limitations oftraditional simulation techniques that employed a sequential process to execute anentire simulation with a single thread [4, 5]. Such technological advancements areleading towards more rapid adoption of parallel and distributed simulations and theemanated increased use of parallel simulation in engineering applications.

As discussed earlier, the simulators may be categorized as event based simulatorsas their time progression is based on pending events PDES events are generated atdiscrete time intervals depending on the nature of simulation. PDES is normallydefined as a three step process: (i) receive events, (ii) process and perform operationson events (iii) update its local time and generate events for (other/own) processes ornodes. Each process must execute events in the order of the timestamps on them [5].

Rapid advancement in technology is increasing the necessity for simulators, sincesimulators are fast and cost effective tools to analyze systems, such as complexlarge scale distributed systems and cloud computing solutions. Cloud computinghas become more renowned given its architecture and benefits for the end user [6].A Cloud comprises of data centers, consisting of tens of thousands of computingservers and switches or routers connected via high speed networks with specializedcooling equipments. Multinational companies, such as Google, Facebook, Amazonand Microsoft, host their own distributed data centers [7]. These companies providecomputational services and promote web based services. Clouds exclusively provideservices such as infrastructures, platforms, and software [8]. User demand has leadthe evolution of data center architecture. However, since efficient use of data centersin terms of computing power and heat energy dissipation, remains less explored; themaintenance costs of data centers remain high [9].

There has been a massive increase in the number of users switching to Cloud com-puting to host their data and applications [10, 11]. Due to this tremendous growth inthe number of Cloud computing users, critical issues such as scalability, efficiencyand security arise; researchers are developing different types of simulators to analyzeand overcome these issues [7]. In this chapter, we demonstrate how to build a datacenter model using a discrete event simulator i.e. OMNeT++. OMNeT++ is anopen source, discrete event simulator, developed by Andre Vergas [12]. The dex-terity of OMNeT++ lies in its powerful graphical interface that makes the internalmodels completely visible to the end user. It uses packet transmission for communi-cation between modules and nodes that is visible on the GUI. OMNeT++ simulationmodels are based on modules which can further be nested within other modules toform a complex network or system models.

OMNeT++ was developed in 2003, written in C++ and supported windows,Linux, UNIX and Mac OS X. OMNeT++ allows the use of existing modules and


frameworks that can easily be imported into other simulations, this further facilitatesCloud data center simulation. OMNeT++ provides features, such as plotting (plove),debugging through Valgrind utility [13]. Other network simulators commonly usedfor academic research are: NS-2 and NS-3. NS-2 was developed in 1996, written inC++ and mainly used for UNIX operating systems; whereas NS-3 was developed in2008, written in C++, supported simulation models in C++ or Python languages.NS-3 was also targeted for UNIX based operating system.

In the next section, we briefly describe the traditional data center models.It is important to develop an understanding about these models before actualimplementation.

2 Data Center Architectures

Over the last few decades, Cloud computing has become the most popular comput-ing paradigm used all over the world. Clouds provide on demand computing accessthrough networks. The basic objective of Cloud is to provide computing resourcesthrough its server pools. This approach is similar to master and worker example,where the master assigns scientific tasks to his workers. Furthermore, Cloud intro-duces a concept of virtualization that enables the sharing of resources among theusers [14].

Cloud services are generally categorized as, Software as a Service (SaaS); Infras-tructure as a Service (IaaS); and Platform as a Service (PaaS). For SaaS, applicationservices are delivered over the network on demand basis. Microsoft, Google andSalesforce are some of the SaaS providers [15, 16]; whereas for IaaS, computationservices and storage are provided over a network. For PaaS, software developmentis provided in the form of Application Programming Interfaces (API) [14].

The architecture of Cloud computing has evolved remarkably with the increasein its usage. Initially a two tier architecture were used to connect computing serverswith other external networks. Figure 2 shows the two tier architecture connectedwith switches to provide mesh network connectivity. In data centers, computingservers are arranged in racks and connected with switches; these switches are furtherconnected with layer L3 switches to provide complete redundant connectivity amongcomputing servers and external networks. Two tier architecture designs only supporta limited number of computing servers. Typically a two tier data center can hold upto 5500 nodes, depending on the types of switches being used [17].

The three tier architecture is employed to address scalability issues by supportingan additional layer of switches and routers. The three layers of switches are referredto as access, aggregate and core, shown in Fig. 3. BCube [18] and DCell [19] aretwo other advanced Cloud computing architectures. Dcell is designed for efficientinterconnection and handling of exponential increase in the number of servers. InDcell, computing servers are also used for routing purposes, thus providing faulttolerance mechanism and eliminates rack level failure. A four degree Dcell cansupport millions of servers without using any expensive core switches or routers.


Fig. 2 Two tier architecture

Fig. 3 Three tier architecture


Similarly, Bcube is based on a server centric architecture, where servers performcomputational tasks and act as a relay to other servers. In this chapter, we focus onbuilding traditional three tier data center simulation model.

In the next section, we discuss a step by step formulation of data center architecturemodel using OMNeT++.

3 Data Center Modeling Using OMNeT++

OMNeT++1 is a discrete event simulator based on event step technique. OMNeT++is chosen for this tutorial given its popularity among researchers, since it is opensource, provides a rich graphical user interface and its cross-platform support. InOMNeT++ every simulation consists of modules and networks. These modulesare interconnected using various communication links. Developers can model com-munication channels by varying its data rate, delay and bit error rate. OMNeT++provides an extensive framework developed in C++ to build simulation models.

In OMNeT++, each simulation model consists of either simple or compoundmodules. Each simple module is supported by its own C++ class; whereas com-pound modules are collections of simple modules grouped together to achieve therequired goals. We must first develop a simple two node simulation and then extendthis simulation model to a more complex design based on compound modules thatsimulate three tier data center architectures.

3.1 Simple Two Node Simulation

We start with building a simple two node simulation, where each node sends amessage to the other.

Open OMNeT++ editor, and select File → New → OMNeT++ Project: typethe project name: “demo”. Click next and choose an empty project then press thefinish button.

Step-1: Add a simple module definition. Right click on “demo” (OMNeT++project) and add a file with an extension “.ned” and name it “node.ned”. Write thefollowing lines of code (given in Table 1) in node.ned file.

Step-2: Create another “.ned” file that contains the definition of a network. Thenetwork consists of one or more communication nodes. The communication linksbetween nodes must be defined within this file. Different properties for each com-munication link can also be specified. We name this file “NetSim.ned” and add thefollowing lines of code (see Table 2).

In the code above, we have created a network named SIMULATION, consistingof two nodes (i.e. NodeA and NodeB) inherited from the simple module i.e. node.

1 www.omnetpp.org.


Table 1 Simple moduledefinition

Line No. Code

1 simple node

2 {

3 gates:

4 input in;

5 output out;

6 }

Table 2 Network definition Line No. Code

1 Network SIMULATION

2 {

3 submodules:

4 NodeA: node;

5 NodeB: node;

6 connections:

7 NodeA.out → NodeB.in;

8 NodeA.in ← NodeB.out;

9 }

The communication link is established inside connection label, the output port ofnodeA is connected with input port of node B, similarly the output port of node Bis connected with input port of node A (arrow heads show the communication pathbetween the nodes).

Step-3: Add a programming logic for each module. As discussed earlier, a networkconsists of simple modules which are connected via communication channels. Aprogramming logic, or a behavior description of a node, must be implemented foreach of the modules. This logic is implemented in C++ classes.

Now add a C++ class to model the desired functionality of the node. Right clickon the OMNeT++ framework, select New → OMNeT++ class and add name as“node”. This generates a header and a source file under the “src” directory. Thisclass must be inherited from cSimpleModule and must provide definitions for thetwo virtual functions, initialize() and handleMessage(). These functions are invokedby OMNeT++ simulation kernel. Function initialize() is invoked only once andis used to set the initial values while handleMessage() is invoked every time themessage is received at a node’s gate or port. Prototypes of these functions are givenin Table 3.

The node.cpp file contains the definition of the functions defined in a header filei.e. node.h. Write the following code (given in Table 4) in node.cpp file.

The Define_Module() macro function registers the “node” class by taking theclass name as an argument (Table 4: line 2). OMNeT++ provides a built-in message


Table 3 Basic functionsprototypes in node header file Line No. Code

1 Class node: public cSimpleModule

2 {

3 Protected:

4 virtual void initialize();

5 virtual void handleMessage(cMessage *msg);

6 }

Table 4 Basic functiondefinition in node source file

Line No. Code

1 #include “node.h”

2 Define_Module(node);

3 void node::initialize()

4 {

5 cMessage *msg= new cMessage("Message");

6 send(msg, "out");

7 }

8 void node::handleMessage(cMessage *msg)

9 {

10 send(msg, "out");

11 }

Table 5 Networkconfiguration Line No. Code

1 [General]

2 network=NetSim

class for communication. The messages can be exchanged between the nodes bycreating a pointer to this class (Table 4: line 5). The send() function is called inorder to exchange packets or messages between the nodes. This function takes twoarguments; first, the message to be sent, and second, the output gate name (Table 4:line 10.). When a message is received at a node, function handleMessage() is called.

Step-4: The next step is to add the “.ini” file. This file is used to tell the simulationkernel which networks it should simulate. Go to → New → Initialization File (ini)and name the file “omnetpp.ini”. Write the code given in Table 5 in this file:

“omnetpp.ini” file is used for configuration and to instruct the kernel to loadthe network simulation model i.e. “NetSim” (Table 5: line 2).

Step-5: To build a simulation, right click on project → Build Project. On suc-cessful compilation, run the simulation by right clicking on project → RunAs →OMNeT++ Simulation. Figure 4 shows the simulation GUI containing the two


Fig. 4 Simulation GUI

nodes, nodeA and nodeB, connected through a bidirectional link. You can run thissimulation model by pressing the RUN button on the toolbar.

We have now successfully created a two node simulation, where each nodegenerates and exchanges messages with the other.

3.2 Advance Level Simulation

In realistic network simulation, each node is assigned an IP address and connectedwith routers or a switch. To model this scenario, we need to alter our demo project.OMNeT++ provides built-in modules that simulate networks with dynamic IPassignment. INET2 is an open source module that can be used for this purpose.Download the INET project and import it into the OMNeT++ framework.

Step-1: A reference to INET project must be added to our “demo” simulationproject to reuse its built-in functionality. Right click on the “demo” project andselect Project References. This displays the list of open projects in OMNeT++framework. Click on the INET project and press the OK button.

Step-2: The required changes in the “NetSim.ned” file are shown in Table 6.INET contains protocol implementations that can be used in other simulation

models. In Sect. 3.1, we connected NodeA and NodeB directly through definedgates or ports. Since we have now assigned IP addresses to the nodes, a routermust be added to handle routing mechanism In addition, there may be inevitablecommunication delays between nodes that can be addressed through link propertiesavailable in INET project.

Step 1: Add an import statement at the top of “.ned” file to use built-in modulesof INET (Table 6: lines 1–4).

Step 2: There are existing modules that implement the required network layerson the host and the router. Therefore nodes, nodeA and nodeB, are inherited from

2 INET Module: http://inet.omnetpp.org.


Table 6 Network definition

Line No. Code

1 import inet.nodes.inet.StandardHost;

2 import inet.nodes.inet.Router;

3 import inet.networklayer.autorouting.ipv4.FlatNetworkonfigurator;

4 import inet.nodes.ethernet.Eth10M

5 network NetSim

6 {

7 submodules:

8 NodeA: StandardHost

9 NodeB: StandardHost;

10 RouterC: Router;

11 Configurator: FlatNetworkConfigurator;

12 connections:

13 NodeA.ethg++ <−−> Eth10M <−−> RouterC.ethg++;

14 NodeB.ethg++ <−−> Eth10M <−−> RouterC.ethg++;

15 }

StandardHost (Table 6: lines 8–9). The StandardHost module is responsible foracquiring an IP address, resolving ARP (address resolution protocol) requests, andhandles multiple applications at the top layer.

Step 3: Add a router to connect multiple nodes. To do this, add a new sub-module,RouterC, which is inherited from Router, an existing module in INET framework(Table 6: line 10). A separate module, FlatNetworkConfigurator, is available in theINET framework, which is responsible for assigning IP addresses to hosts and routersthrough its own sub-module Configurator (Table 6: line 11). This is the simplest IPassignment module implemented in INET.

Step 4: The links are defined under the connections tag with the “ethg” suffix,NodeA.ethg and NodeB.ethg; since the nodes are now inherited from StandardHost(Table 6: lines 13–14). In StandardHost and Router classes, the ports or gates aredefined as bidirectional vectors. The import of inet.nodes.ethernet.Eth10M allowsthe following physical channel properties to be included:

• datarate= 1e07

• delay= 5e−08

• ber= 0

In addition to other modules similar to Eth10M, user defined modules may also beused (channel or link properties are assigned to each link, Table 6, lines 13–14)

Step 5: To build this simulation, the “omnetpp.ini” file must be altered. Thechanges are shown in Table 7.


Table 7 Advance networkconfiguration Line No. Code

1 [General]

2 network=NetSim

3 **.nodeA.numUdpApps= 1

4 **.nodeA.udpApp[*].typename=UDPBasicApp

5 **.nodeB.numUdpApps= 1

6 **.nodeA.udpApp[*].typename=UDPSink

The UDP application, running on the nodes generates UDP packets for thedestination node. An explanation for the code given in Table 7:

**.nodeA.numUdpApps= 1

Only one UDP application is executed at the top of the application layer. This line of code declaresthe number of UDP applications that run at nodeA. Similarly we can use TCP applications

**.nodeA.udpApp[*].typename=UDPBasicApp

The UDPBasicApp is the class that runs the UDP application and contains the definitions of virtualfunctions declared in cSimpleModule. This class generates messages at regular time intervalsto randomly selected destinations. The INET project contains the implementation of UDP (i.e.UDPBasicApp) and TCP (i.e. TCPBasicApp) classes

**.nodeB.numUdpApps= 1

This line of code declares the number of UDP applications that run at nodeB

**.nodeB.udpApp[*].typename=UDPSink

The UDPSink class contains the definitions of virtual functions declared in cSimpleModule. Thisclass only receives messages from other nodes

Step 6: Compile the simulation, right click on demo project and select → BuildProject. On successful compilation, run the simulation. Right click on demo projectand select → RunAs → OMNeT++ Simulation. Certain parameters are required byUDPBasicApp and UDPSink class at this stage, such as local port, destination port,send interval time and message length. When prompted by OMNeT++, provide thevalues given in Table 8.

Figure 5 shows the complete network design using existing modules. IP addressesfor each module are clearly shown on the GUI. These IP’s are generated using theexisting module “FlatNetworkConfigurator”, as discussed earlier. Figure 6 shows

Table 8 Required parametersof UDP application

Parameters Values

Local port 100

Destination port 100

Send interval (seconds) 10s

Message length (bytes) 10B


Fig. 5 Two node real networksimulation model

the TCP/IP stack implementation within “StandardHost”. These modules can beoverwritten by the user.

3.3 Data Center Simulation Model

In the previous sections, we have discussed all the necessary steps to be followed tobuild simple and advance level simulations. In this section, we focus on building datacenter simulations using built-in modules available inside INET project. We requirethe INET framework for IP assignment, a TCP/IP stack at each node, and a router.

Fig. 6 Internal view of nodes and router


Table 9 Three tier networkmodule definition Line No. Code

1 Module Rack

2 {

3 Parameter:

4 int N @prompt(“Nodes per rack”);

5 gates:

6 inout iogate[];

7 Submodules:

8 ComputingServer[N]: StandardHost;

9 AccessRouter: Router;

10 Connections:

11 for i= 0.. N-1{

12 AccessRouter.ethg++ < – –>Eth10M< – –>ComputingServer[i].ethg++; }

13 AccessRouter.ethg++ < – –> iogate++;

14 }

Step 1: The first step is to model the three tier simulation network in the “.ned” file,which is more complicated than the previously discussed examples. Simple modulesare supported by a single class while compound modules are collections of severalsimple modules, as discussed earlier. Compound modules allow communication withother simple or compound modules through communication gates.

Create a new project and name it “ThreeTierDC”. Add a new “.ned” file andname it “NetworkDefination.ned”. As discussed in Sect. 2, three tier data centersconsist of racks that hold servers and routers i.e. access, aggregate and core routers.In this simulation model, we build a compound module of racks that connects withaggregate and core routers through access router. Add the following lines of code(given in Table 9) in NetworkDefination.ned file:

Module on line 1 indicates that Rack is a compound module. The number ofservers can vary on the racks and this number can either be fixed or provided by theuser at run time.

Line 4, prompts the user to enter an integer value for variable ‘N’. The code on(Table 9) line 8, uses this ‘N’ to declare the number of servers on each of the racks.The compound module defines bidirectional, vector in-out gates, shown on Table 9,line 6 of the code. The racks accommodate the servers and access routers (Table 9:lines 8–9).

The computation servers must be connected with access routers which in turn mustbe connected with compound module gates. The connection between the servers andaccess routers is established under the connection tab, with a loop (Table 9: lines 11).


Table 10 Three tier networkdefinition Line No. Code

1 network ThreeTierDatacenter

2 {

3 Parameter:

4 int N= default(4);

5 int AGR= default(4);

6 int CR= default(2);

7 Submodules:

8 AGRouters[AGR]: Router;

9 CRouter[CR]: Router;

10 Racks[N]: Rack;

11 Configurator: FlatNetworkConfigurator;

12 Connections allowunconnected:

13 for i= 0..CR-1, for j= 0.. AGR-1{

14 CRouter[i].ethg++ < – –>Eth100M< – –>AGRouter[j].ethg++ ; }

15 for i= 0..1, for j= 0..1{

16 AGRouter[i].ethg++ < – –>Eth100M< – –>AGRouter[j].ethg++; }

17 for i= 2..3, for j= 2..3{

18 AGRouter[i].ethg++ < – –>Eth100M< – –>Racks[j].iogate++; }

19 }

The code on (Table 9) line 13, connects the access router to the compound modulegates for external communication.

Step 2: Create a three tier data center model, with racks, and routers bothaggregate and core. Add the following lines of code (see Table 10) to the“NetworkDefination.ned” file:

At this stage a network that connects all the modules together has been defined.For the sake of simplicity, the default number of racks and aggregate routers ishard-coded at four and two for the core switches (Table 10: lines 4–6).

The required modules, i.e. routers, racks and network configurator, are definedunder the Submodules section (Table 10: lines 7–11).

In Table 10, line 12 of code, Connections allowunconnected, instructs the sim-ulation kernel to allow this simulation model with unconnected gates to avoid theOMNeT++ kernel throwing an exception in case a gate was not connected.

Connections are established between the racks and routers, with nested loops(Table 10: lines 15–18). Code on line 18, connects the aggregate routers to thecompound module rack through communication gates.


Table 11 Three tier networkconfiguration settings Line No. Code

1 [General]

2 network=ThreeTierDatacenter

3 **.Racks[*].ComputingServer[*].numUdpApps= 1

4 **.Racks[*].ComputingServer[*].typename=UDPBasicApp

5 **.udpApp[*].localPort= 100

6 **.udpApp[*].destPort= 100

7 **.udpApp[*].messageLength= 1024B

8 **.udpApp[*].sendInterval= 1s

Step 3: The final step is to amend the “omnetpp.ini” file and specify the numberof UDP applications and C++ source files (see Table 11).

In the previous example, “omnetpp.ini” file held the simulation network model.Modifying this file, lines 3–4, declare the number of UDP applications to run oneach of the servers. In previous examples the user entered the values for local anddestination ports, message length and send intervals. However, the default values forthese variables are hard-coded in this example (Table 11: lines 5–8).

This model allows for the servers to generate tasks for a randomly selected destina-tion node. This random node selection process is implemented in the UDPBasicAppclass available in INET framework. Figure 7 and 8 shows the three tier simula-tion model and rack view within the OMNeT++ framework, the green colored

Fig. 7 Three tier data center simulation model


Fig. 8 Internal view of rack and computing server

overlapping texts depicts dynamically assigned IP’s. The user can change the func-tionality of UDPBasicApp by defining its own class. Keeping parameters within the“omnetpp.ini” file allows the code to be used without recompilation.

4 Wrap Up

Cloud computing is a fascinating area of research. The importance of cloud com-puting has been highlighted with a sharp increase in its use. Technological advancesand current user requirements are rendering cloud computing more desirable and in-evitable to adopt. Along with these benefits, Cloud computing introduces intriguingresearch areas, including scalability, energy optimization and task scheduling.

It is important to understand how complex systems work. Given the complexityof these systems, models and simulations are the best way to gain an insight into theworkings of such systems. Agile technology expansion is increasing the necessity forsimulators, since simulators are fast and cost effective tools to analyze systems. In thischapter, we focused on modeling of data center architecture to facilitate researchersto perform in depth analysis on core issues instead of building basic modules. Theaim of this chapter has been to provide an insight of building data center simulationmodels using OMNeT++ and served as a platform for researchers to build advancelevel data center architectures models using available components.

Acknowledgement The authors would like to thank Miss Maham Fatima Nasir (SCME-NUST)for her valuable support during write-up process.

References

1. A. Buss, and L. Jackson, Distributed simulation modeling: a comparison of HLA, CORBA, andRMI. Winter Simulation Conference (WSC’98), Washington, DC, USA, 1998, pp. 819–825.

2. R. M. Fujimoto, Parallel discrete event simulation. Communications of the ACM archive vol.33 (1990) pp. 30–52.


3. A. Park, and R. M. Fujimoto, Efficient Master/Worker Parallel Discrete Event Simulation.ACM/IEEE/SCS 23rd Workshop on Principles of Advanced and Distributed Simulation, 2009.PADS ’09, pp. 145–152.

4. R.M. Fujimoto, Parallel and Distributed Simulation Systems, Wiley interscience Publication,New York, 2000.

5. R.M. Fujimoto, A.W. Malik, and A.J. Park, Parallel and Distributed Simulation in the CloudMagazine of the society for Modeling and Simulation (M&S), July 2010, pp. 1–10.

6. M.B. Mollah, K.R. Islam, and S.S. Islam, Next generation of computing through cloud com-puting technology. 25th IEEE Canadian Conference on Electrical & Computer Engineering(CCECE), 2012, pp. 1–6.

7. A. Vahdat, M. Al-Fares, N. Farrington, R.N. Mysore, G. Porter, and S. Radhakrishnan, Scale-Out Networking in the Data Center. Micro, IEEE vol. 30 (2010) pp. 29–41.

8. S. Akioka, and Y. Muraoka, HPC Benchmarks on Amazon EC2. 24th IEEE InternationalConference on Advanced Information Networking and Applications Workshops (WAINA),2010, pp. 1029–1034.

9. B. Aksanli, J. Venkatesh, and T.S. Rosing, Using Datacenter Simulation to Evaluate GreenEnergy Integration. The Computer Journal vol. 45, pp. 56–64.

10. T. Ercan, Effective use of cloud computing in educational institutions. The Journal ofProcedia—Social and Behavioral Sciences vol. 2 (2010) pp. 938–942.

11. P. Gupta, A. Seetharaman, and J.R. Raj, The usage and adoption of cloud computing by smalland medium businesses. International Journal of Information Management vol. 33 (2013) pp.861–874.

12. A. Varga, Using the OMNeT++Discrete Event Simulation System in Education. IEEETransactions on Education vol. 42 Issue 4. (1999) p. 372.

13. P. Vilhan, and J. Gajdos, ADEUS: Tool for Rapid Acceleration of Network Simulation inOMNeT++. 14th International Conference on Computer Modelling and Simulation (UKSim),2012, pp. 591–595.

14. K. Bakshi, Considerations for cloud data centers: Framework, architecture and adoption.Aerospace Conference, 2011 IEEE, pp. 1–7.

15. S. Ming-Chien, Let’s Walk Out of the Cloud. Fifth IEEE International Symposium on ServiceOriented System Engineering (SOSE), 2010, pp. 5–5.

16. Y. Bo-Wen, T. Wen-Chih, C. An-Pin, and S. Ramandeep, Cloud Computing Architecture forSocial Computing—A Comparison Study of Facebook and Google. International Conferenceon Advances in Social Networks Analysis and Mining (ASONAM), 2011, pp. 741–745.

17. Dzmitry Kliazovich, Pascal Bouvry, and S.U. Khan, GreenCloud: a packet-level simulator ofenergy-aware cloud computing data centers. The Journal of Supercomputing vol. 62 (2012)pp. 1263–1283.

18. C. Guo, G. Lu, D. Li, H. Wu, X. Zhang, Y. Shi, C. Tian, Y. Zhang, and S. Lu, BCube: ahigh performance, server-centric network architecture for modular data centers. SIGCOMMComput. Commun. Rev. vol. 39 (2009) pp. 63–74.

19. C. Guo, H. Wu, K. Tan, L. Shi, Y. Zhang, and S. Lu, Dcell: a scalable and fault-tolerantnetwork structure for data centers. Proceedings of ACM SIGCOMM conference on Datacommunication, ACM, Seattle, WA, USA, 2008.

data center modeling and simulation using omnet++

Documents