Systems Engineering Management Plan for Cloud Computing

This is the era of “Cloud Computing”. In the simplest terms, cloud computing means storing and accessing data and programs over the Internet instead of your computer’s hard drive. In the past companies used to run programs on physical computers or servers located on their premises. But today the same programs are run on software hosted on the internet.

Figure 1.1 Cloud Computing Architecture

Benefits of Cloud Computing

There are several benefits of clod computing over traditional on premise computing infrastructure. Some of them are listed below:

Flexibility: Today cloud providers like AWS (Amazon Web Services) are providing “free to join, pay only for what you use” model which is encouraging more and more companies, big and small to buy cloud services from them. Cloud-based services are ideal for businesses with growing or fluctuating bandwidth demands. If the needs of your company increase you can easily scale up your cloud capacity. Likewise, if you need to scale down again, the flexibility is built into the cloud service.[5]

Work from Anywhere: With cloud computing, if you have got an internet connection you can work from anywhere. And with most serious cloud services offering mobile apps, one is not restricted by which device one uses. The result is an increased amount of flexibility that a company can provide to its employees.[5]

Cost Saving on Infrastructure & Manpower: Companies do not need to invest in computing infrastructure like physical machines or servers or data centers anymore. They can lease computing resources from cloud providers in the form of virtual machines which have desired computing power and memory. Also companies do not need to worry about things like updating software etc. as those services are already provided by the cloud provider. Companies also do need to invest in manpower for keeping and maintain computing infrastructure. [5]

Cloud Computing Attacks

When it comes to Cloud Security, unfortunately vulnerabilities have been found in the Cloud environment which lead to attacks. Some of the well-known attacks in the cloud environment are as follows:

Denial of Service Attacks (DoS Attacks): It prevents users from accessing a service. However, in a Cloud environment, DoS attacks get nasty. Cloud by its design keeps on adding more computational power thus making the attack even more severe. [6]

Malware Injection Attack: In this attack the attacker adds a piece of malicious code or a malicious VM to the cloud environment. The main aim of the attacker here is to take control of the victim’s virtual machine’s sensitive data. The attacker uploads an image very similar to victim’s virtual machine. Then User requests start flowing to this newly added malicious VM. [6]

Side Channel Attack: This attack is directed to compromise IaaS by placing a virtual machine co-resident to the victim’s VM. By co-resident means that the VM has to be in the same host. This attack is done in 2 phases. The first phase is achieving co-residence with target VM. Second phase is to extract useful information from the target VM. Attacker has to be sure that he has placed a host VM as a co-resident to the target VM. There are ways in which in which co-residency can be checked [8]. We found a very interesting illustration in [9] about how a malicious attacker achieves co-residence with the victim’s VM in a host and derives sensitive information belonging to a victim using host’s cache. Figure 1.2.1 shows a malicious VM co-residing with the victim VM. We can see in the figure that both VMs share the hypervisor, cache and memory of the physical machine and it is possible for the attacker VM to use either of these three to penetrate into the Victim VM.

Figure 1.2.1 A host under attack from a malicious VM

Need Analysis

Infrastructure as a Service (IaaS) such as Amazon Web Services (AWS) has been attracting more and more customers due to the ability to perform virtual machine (VM) provisioning and thereby offering the highest level of flexibility and scalability. A key challenge of implementing IaaS is determining the placement of Virtual Machines, i.e., the assignment of each Virtual Machine to a physical machine in the provider’s cloud infrastructure. There have been several efforts on Virtual Machine placement strategies for IaaS based on several criteria for e.g. Energy Aware Virtual machine Placement Algorithms[3][4] or network aware VM Placement strategies.[1][2] But there are very few efforts that take security of the Virtual Machine into account. The cloud provider does not give the cloud user much say on where exactly user’s VM will be placed. There can be situations where a user’s VM resides in the same host as the VM of his competitor or enemy. The malicious user can use the host vulnerabilities to gain access to user’s sensitive data.[6] Also there can be high profile users who do not want to share physical machine space with any other users. Therefore there should be a provision for the user to be able to define placement constraints that should be considered while placing his virtual machines.

CHAPTER II

SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP)

The systems engineering management plan (SEMP) contains a detailed schedule for design and development of the system, along with a statement of work (SOW) and work breakdown structure (WBS).

The SOW typically contains a summary statement of the work to be accomplished, input requirements from other tasks upon which the system depends, reference specifications, and a summary of expected results to be achieved. For the proposed system, the work to be accomplished is the creation of a Security Aware Virtual Machine Algorithm and a simulator tool that implements it. This simulator tool helps users submit Virtual Machine requests with placement constraints they need and check the performance of Security Aware Virtual Machine Algorithm in terms of time taken to place a certain number of Virtual Machin requests . Input requirements are listed in the project management plan shown in figure 2.1

The WBS identifies the anticipated scope of work over the lifetime of the system, including design and development, deployment, maintenance, testing and retirement.  For the proposed system, the anticipated steps for design, development, testing and deployment are shown in the project management plan in figure 2.1.

The primary element of the SEMP is a detailed schedule of work to be done.  This schedule is shown in figure 3.1.  The SEMP is typically shown in a Gantt chart which lists the start, finish, and length of each project task, and lists each task in the order that it must be completed.  This design explicitly defines which tasks take precedence and must be completed before other dependent tasks can be started.  There are many tools available for creating a Gantt chart.  The plan shown in figure 3.1 was created with the ProjectLibre open source tool [11].

As shown in the Gantt chart in figure 2.1, 8 days are allocated for developing a formal SOW, 15 days are allocated for gathering requirements, 28 days for preliminary design of the system, 35 days for detailed design, programming, and implementation, and 25 days are allocated for testing and evaluation.

Figure 2.1 Systems Engineering Management Plan

CHAPTER III

BUSINESS MISSION ANALYSIS

Literature Review

There are many strategies for VM placement in a cloud. Some are focused on keeping the network costs low by optimizing data access latencies [1] and some are network aware VM allocation strategies which focus on reducing overall communication costs. There are algorithms which focus on energy conservation like [3, 4]. But there have been very few attempts to device a security aware virtual machine placement strategy.

Some authors propose a VM placement strategy based on incompatibilities between users [12]. In this strategy each cloud user can submit a list of adversary users with whom it does not want to share a Physical Machine. Then the lists of adversary users are merged to create incompatible groups that are taken into consideration when placing a VM on a PM. This work provides an interesting solution to improve the security of cloud computing by performing isolation between users. This placement algorithm does not take into account security threat caused by placing all of a user’s virtual machines on one or two physical machines. In this case all of a user’s VMs get compromised in case of an attack on one VM as they are residing on the same Physical Machine.

There is a research where authors take into account several user defined constraints but they do not take into account user’s necessity of not wanting to share a physical machine with a competitor [7].

There is a research which proposes an algorithm to use CVE vulnerabilities to segregate VMS based on their vulnerability to attacks [10]. But in this research authors do not take into account threats caused by sharing Physical Machines with known competitors who may want to launch attacks on user’s VMs.  There is also a research where authors develop VM migration techniques based on Markov chain analysis, which aims to minimizing the security risks considering the connections among virtual machines and improving the survivability of the whole cloud. However, the problem of initial VM placement problem is not considered in their effort [13].

There is also a system using security metrics specific to the cloud computing to develop virtual machines placement algorithms [14]. However, the security metrics ignore the security risks caused due to co-resident VMs. Saeed et. al. present a security-aware VM allocation strategy in clouds that allows for effective enforcement of defense-in-depth for cloud VMs [15]. They have modeled the cloud provider’s constraints and customer’s requirements as a constraint satisfaction problem (CSP), which can be solved using Satisfiability Modulo Theories (SMT) solvers to reduce risk and improve manageability in a cloud. However, the authors formulate the problem as a satisfiability problem and not as an optimization problem. When a solution is only focusing on satisfiability it just satisfies input constraints and is not optimal. But when a solution is focused on optimization it makes the most effective usage of the available resources.

System of Interest

The system of interest for this thesis is a software based system that can simulate Virtual Machine Placement on a Cloud. The system will allow multiple users to send requests for virtual machines. The users will be able to specify constraints based on which they want the software to place their virtual machines on Physical Machines. The System will basically deduce the execution time of placing all the virtual machines requested by multiple clients. It will internally implement the virtual machine placement scheme deduced in this research.

Problem Statement

Our problem statement can be briefly described as follows: ‘N’ virtual machines with requirements given in the form of memory, CPU and network bandwidth need to be placed on ‘M’ physical machines with resource capacities given in the form of memory, CPU and Network bandwidth provided that VM’s resource requirements and placement constraints are satisfied while minimizing the number of PMs used. While finding such a mapping, we have to take care that the total resource requirement of the VMs placed on a PM should not exceed its capacity.

Stakeholder Identification

Stakeholder identification is very important in a project. There are two types of Stakeholders. The primary stakeholders are the ones who are directly benefitted by a project. The secondary stakeholders are the ones who are indirectly affected by the outcome of the project. The primary stakeholders in this project are the consumers who use cloud services provided by various cloud providers. The researchers conducting researches in the area of cloud security are also primary stakeholders in this project.

Cloud providers are the secondary stakeholders in this project as they will benefit from a good virtual machine placement algorithm which provides security to their clients.

Feasibility Analysis

The feasibility of the system can be described by cost and complexity. The proposed system is estimated to be approximately $19,960 over the first year. Details of this estimate can be found in Table 10.1.1 System Development Costs. Maintenance costs for the first two years include expected enhancements to the system functionality in addition to system maintenance. Next, the complexity of the system must be examined Based on the related work mentioned above and the technologies that may be required, any 4 to 5 years experienced Software Engineer will have the skills necessary to finish this project. The software developer in this case will be responsible for designing the system, developing it and testing it.

System of Interest and Operational Concept

The primary goal of this research is to devise a security aware virtual machine placement algorithm which gives the capability to a cloud user to define placement constraints for the virtual machines he/she is requesting. While mapping requested virtual machines to the physical machines this placement strategy not only makes sure that total capacity of available physical machines while keeping the number of hosts to minimum.

This research aims at making a software based system to simulate this algorithm and also test its performance with various number of virtual machine requests.

Specifically, the proposed system will address the following issues:

It will have a GUI where users can enter virtual machine requests to be placed on a cloud environment.

The system allows User Define placement constraints based on which he wants his Virtual machines to be placed onto PMs

Develop a security aware VM placement algorithm which takes User- defined constraints into consideration while placing VMs on PMs.

Develop a system that simulates a network with predefined datacenters and hosts.

Develop a system which uses security aware VM placement algorithm to place VMs onto PMs

Develop a system that produces results in the form of time taken to place n virtual machine requests to a pre-defined set of Physical Machines in pre-defined datacenters.

The system also tells which VM was placed on which PM in the network

CHAPTER IV

REQUIREMENTS DEFINITION

Requirements definition is the phase where we identify the requirements of the primary stakeholders and secondary stakeholders. Then based on those requirements we identify System requirements.

Stakeholder Requirements

Primary Stakeholder Requirements

Primary stakeholders in this case are the cloud users. These are the people who consume cloud services either provided by a cloud provider like AWS or from a private cloud for. E.g. private cloud network of a lab or a university or a company. They are the ones who have a direct stake in this project as they benefit the most when the security of the resources rented or occupied by them on cloud is increased. The requirement of the primary stakeholder is that he or she should be allowed to specify the constraints based on which his virtual machines should be placed in cloud environment.

Secondary Stakeholder Requirements

Secondary Stake Holders in this case are Cloud Providers like AWS etc. There requirement is that the availability of resources they have should be kept in mind while allocating VMs to a physical machine. The constraints that a user can specify should be well defined.  There should also be a way to incentivize cloud provider for providing security to the cloud user.

System Requirements

These are the requirements which are laid down for the system of Interest so that it can satisfy the requirements of Stake holders. They are divided into two categories Functional Requirements of the System and Operational Requirements of the system.

Functional Requirements of the System

In order to design and build the system of interest, a minimum of two subsystems required.  There must be a client subsystem that users can use to submit virtual machine requests. There must be a system that simulates cloud-computing framework that users can use to allocate Virtual Machines.

High-Level functional requirements for the system include the following:

• The system shall provide graphical user interface (GUI) for user to requests virtual machines. This interface shall be in English and must be able to run on any desired operating system.

• The system shall be able to give the capability to the users to specify the virtual machine placement constraints that they want to be considered while placing virtual machine.

• The system shall be able to compute the execution time required to place all the virtual machines in a request using the Security aware virtual machine placement scheme described in this thesis.

• The system shall be able to specify in its output total power consumed by the datacenter after the requested virtual machines are placed

Operational Requirements of the System

The operational requirements focus on how the system will be operated by the users, including interfaces and interoperability with other systems. The requirements establish how well and under what conditions the system must perform.

The system shall be able to be connected over the private network.

The client facing system shall not be dependent upon a unique hardware and/or operating system environment.  For example, the selected operating system must be in common use, such as Microsoft Windows, or common flavor of Linux, and it must be able to run on readily available and standard hardware.

The system shall be easy to deploy. This means the user should be able to start and open the application without any instructions. This includes mainly the client facing components, such as the front-end GUI application.

The selected hardware and operating systems for the subsystems shall be robust enough to run all of the required applications.

Maintenance Requirements of the System

Maintenance requirements for the system are expected to consist of, but not limited, to bug fixes and feature enhancements, primarily in the first two years of initial production use. Rolling maintenance will predominantly include the hardware and operating system environment, and will also include installation of vendor-provided patches and updates.

Technical Performance Measures of the System

Technical performance measures include response time for the simulator to place all the virtual machines requested.  Response time would essentially be the time it takes from when the user submits the virtual machine requests until the user receives an output response from Simulator. In this research we are comparing the performance of Security Aware Virtual Machine placement algorithm with Worst Fit Decreasing algorithm which is one of the very popular Virtual Machine Placement algorithms.

CHAPTER V

ARCHITECTURE DEFINITION

Since the era of cloud computing began researchers have been trying to devise various virtual machine placement algorithms. There can be several ways to test the performance and efficiency of a VM placement algorithm. This research explored the option of implementing its virtual machine algorithm on OpenStack or a cloud simulator tool.

Architecture Identification

The basic architecture of the proposed System needs to have a VM request system which will allow users to place requests for Virtual Machines and a VM placement Subsystem to implement the Security Aware Placement Algorithm as described by this research. We have explored 2 architectures here. Architecture A uses OpenStack Software to create Virtual Machine Subsystem and Virtual Machine Placement and a real datacenter. Whereas Architecture B uses Cloud Simulation Technologies to implement the Security Aware Virtual Machine Placement Algorithm

Architecture A

OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.

To simulate a virtual machine placement in Openstack one needs to have the physical resources like hosts and a datacenter which is not financially viable for a researcher. Also the implementation of a virtual machine Placement Algorithm on Openstack can be very complex.

Architecture B

It is not possible for systems administrators, cloud specialists and even researchers to have actual cloud infrastructure to perform real-time experiments and implement new algorithms and methodologies. Before a real-time virtual machine placement algorithm is implemented in a cloud environment, it is important to first measure performance and investigate all possible security issues. There are several cloud simulation technologies that are available to help researchers with these issues. A cloud computing simulator helps us witness an implementation scenario in real-time. Cloud simulators are inevitable in reducing the complexity of the infrastructure, in executing new algorithms, analyzing security threats and measuring the overall quality and performance of the cloud infrastructure.

Several cloud computing simulators for E.g. CloudSim, CloudAnalyst, GreenCloud are available for users. Some simulators are free and open source, while others are commercial. It’s common to use the free and open source simulators as they facilitate deep experimentation.

Architecture Selection

The proposed approach for this system is one which is least complex for a user to implement. It is also the one which is more economically viable and is scalable to experiments with datasets big or small.

We used System alternatives decision matrix to decide which approach should be taken to create our system. It is one of the procedures in Systems Engineering to pick the most suitable approach towards building a system. Each approach is rated based on its importance to the developers of the system and prospective users.

Complexity of the approach was the most important criteria for us due to time constraints. Taking a complex approach was not feasible in the limited time available, so complexity was given an importance of 90 versus Cost and scalability which were given an importance rating of 70 each

Table 5.2.1 System Alternatives

Openstack Framework Cloud Simulation Tools

Cost

User needs to have real time cloud Infrastructure to conduct experiments which is very expensive.              Users do not need  real-time Cloud Infrastructure as most of cloud simulators simulate real-time cloud architecture

Complexity It very complex to configure Openstack to manage that datacenter Most Cloud Simulators have various network architectures inbuilt in them.

Scalability Able to scale to unlimited number of hosts Able to scale to unlimited number of hosts

Table 5.2.2 System alternatives decision matrix

Openstack Framework  Cloud Simulation Tools

Criteria  Importance  Weight Rating  W*R  Rating  W*R

Cost  70  0.30  75  22.5  75  22.5

Complexity 90  0.40  60  24  95  38

Scalability  70  0.30  95  28.5  90  27

Total  230  1.00    75    87.5

Score            75  87.5

From table 5.2.2, the Cloud Simulator Tools approach with an overall score of 87.5 appears to be the most appropriate model to meet the requirements of the system.

Conceptual Design Using Proposed Architecture

The proposed system design includes 2 separate subsystems for the client, the VM request system, and VM Placement system. Note that these subsystems must be independent of each another but able to communicate with each other.   Figure 5.3.1 shows a simplified overview of this system. On the top left of the diagram is the VM Request System. This is the piece that will contain the GUI where VM requests can be submitted for simulation. The second piece is VM Placement system which simulates the virtual machine placement algorithm and calculates its performance in terms of time consumed in placing every virtual machine requested

Figure 5.3.1 Proposed Conceptual System Design

CHAPTER VI

DESIGN DEFINITION

Requirements for Virtual Machine Request Subsystem

In this section we will discuss preliminary design of Virtual Machine Request Subsystem and Virtual Machine Placement Subsystem. We will describe the functional and operational requirements for both these subsystems and we will discuss design alternatives to satisfy those requirements.

Operational Requirements for VM Request Subsystem

The System shall permit the users to enter virtual machine requests .

The System shall allow users to enter Virtual Machine Requests in the form of a CSV File.

The Virtual Machine Request CSV File shall have following details :

User Id: User Id of the User on behalf of whom the virtual machine requests are being sent

VMid: The VM id of each VM being submitted.

VM CPU: It will be CPU requirement of each VM request.

VM memory: Memory Requirement of each VM request.

VM constraints: Placement constraints required by the User for this VM for e.g. ANTI_SHARING (AS) or ANTI_CORESIDENCE (AC).

The System shall permit the view the results of VM placement in the form of:

Datacenter Chosen: Which VM was placed in which Datacenter.

Physical Machine Chosen: Which VM was placed in which Physical machine?

Number of VMS placed: How many VM were actually placed.

Placement time: The amount of time spent in placement.

Operational Requirements for VM Request Subsystem

The system shall utilize a standard set of APIs and libraries, according to the underlying operating system. This includes APIs for providing a graphical interface.

The system shall have a standard network interface and be able to communicate over the network using the standard TCP/IP protocol.

Design Alternatives for VM Request Subsystem

The VM request subsystem has the task of receiving the input in the form of several VM requests with details about every VM request. It was possible to make a UI where a User could enter specifications for each VM attribute for e.g. its CPU, Memory, placement constraints etc. The other approach was to submit the entire experiment set which is a set of VM requests.

Approach A

This approach was to submit the entire experiment set which is a set of VM requests as a CSV file. Then the VM Placement Subsystem could read all of those VM requests and place them according to the placement scheme.

Approach B

The other approach was to submit the entire experiment set which is a set of VM requests as an XML file or an XML file. Then the VM Placement Subsystem could read all of those VM requests and place them according to the placement scheme.

Design Alternatives for VM Request Subsystem

Though for very complex form of data where there are relationships between data to be considered XML is definitely a better format to send input data. But for a scenario like this where data is a flat schema, it is better to Use CSV. CSV is also easier to parse than an XML input. We gave Simplicity an importance of 90 and ease of implementation an importance of 70.

XML Format  CSV Format

Criteria  Importance  Weight  Rating  W*R  Rating  W*R

Simplicity 90  0.56  80  44.8  80  44.8

Ease of Implementation  70  0.43  80  34.4  90  38.7

Total  160  1.00    79.2    83.5

Score           79.2

Table 6.3.1 Decision Matrix for VM Request Subsystem

After putting this through a decision matrix we chose to go ahead with Approach A using CSV format as the matrix here clearly shows that CSV getting a score of 83.5 is definitely a better choice. Figure 5.1.1.1 Screenshot of VM Request Subsystem shows a screen shot of VM request subsystem. It has a button to submit VM requests in CSV format and a button ‘Simulate’ to run the security aware VM placement simulation on the VM requests submitted by the user.

Requirements for VM Placement Subsystem

Virtual Machine Placement Subsystem is required to place the Virtual machines requested by the user using Security Aware VM placement algorithm as discussed in Chapter III

Functional Requirements for VM Placement Subsystem

The system shall be able to take the input from the VM Request Subsystem.

The system shall be able to simulate a datacenter with number of hosts desired by the user.

The user shall be able to specify the type of hosts he wants in datacenter in terms of CPU and memory.

The user shall be able to specify how many datacenters user wants.

The system shall be able to allocate VMs to PMs based on the Security Aware VM Placement Algorithm.

The results given y the system will be returned to the VM Request Subsystem.

The system shall give results in the form of:

Number Of virtual machines placed.

Which VM was placed on which Physical Machine?

How much time was needed in doing the placement?

Which VM was placed in which Data Center?

Functional Requirements for VM Placement Subsystem

The system shall utilize a standard set of APIs and libraries, according to the underlying operating system. This includes the APIs needed to connect to the cloud framework over the network.

The system shall have a standard network interface and be able to communicate over the network using the standard TCP/IP protocol.

Design Alternatives for VM Placement Subsystem

The Virtual Machine Placement Subsystem is the part of the system which will implement the Security Aware VM Placement discussed in this research. It will receive the inputs from the VM Request subsystem and place those virtual machines in the cloud network simulated by it. We needed a cloud simulation tool which was capable of simulating small to large scale networks an also a system which had built in libraries for us to be able to implement our VM placement algorithm. We needed a Cloud simulation tool which gave the capability to request heterogeneous nature of today’s cloud network in terms of different variety of virtual machines requested by a cloud user. We were also looking for ease of implementation therefore we were looking for a simulation software which had most of the code already in place of cloud related simulations.

Approach A

This approach was using a Cloud Simulation Tool called Green Cloud. It is an open source cloud simulation tool which requires the user to have good knowledge of C++. The typical simulation time for a VM placement job in Green cloud is in minutes. [21]

Approach B

This approach was using CloudSim which is also an open source cloud simulation tool which requires the user to know basic Java. The simulation time for this tool is in seconds. [19][20] [21]

Approach C

This approach was using MIDCSim which is also a commercial cloud simulation tool which requires the user to know basic Java and C++. The simulation time for this tool is in seconds. [21]

Green Cloud Cloud Sim MIDCSim

Performance Simulation time is in minutes Simulation time is in seconds Simulation time is in seconds

Ease of Use Good knowledge of C++ and OTCL scripts Only basic knowledge of Java is required              Knowledge of Java and C++ is required

Availability Open Source Open Source Commercial

Table 6.5.3.1 System Alternatives

GreenCloud  CloudSim  MIDCSim

Criteria  Weight  Rating  W*R  Rating  W*R  Rating  W*R

Performance  0.3  50  15  60  18  60  18

Complexity  0.3  40  12  60  18  40  12

Availability  0.4  80  32  80  32  30  12

Score      59   68    42

Table 6.5.3.2 Decision Matrix

CHAPTER VII

DETAILED DESIGN, IMPLEMENTATION AND INTEGRATION

This chapter describes detailed design of both subsystems of VM request Subsystem and VM Placement subsystem

Design & Implementation of VM Request Subsystem

We decided to use csv files to upload virtual machine requests. The CSV files will have five columns

VM id which will be Virtual Machine ID

RAM which is Random Access Memory

BW which is Bandwidth

Placement Constraint

We decided to use Java Swing to make the UI of VM Request subsystem as this is desktop based system we did not need to use Web technologies like HTML or JSP. This System needed to have a button to upload the CSV file and a button o view Simulation results. The output of VM Placement Subsystem was displayed on click of “Run Simulation” Button

Figure 7.1.1 VM Request Sub System

Design & Implementation of VM Placement Subsystem

User-Defined Constraints for VM placement

The system shall be able to take the input from the VM

We decided to use csv files to upload virtual machine

Anti-sharing constraint

There are users which carry highly sensitive data in their Virtual Machines. Such Users are highly averse to renting virtual machines in a cloud network. There needs to be way for these type of users to specify that they do not want to share their physical machine with any other user. The ANTI-SHARING Constraint is where a user says that all virtual machines present in his request will not share a physical machine with VMs of any other User. We are denoting this constraint as ANTI-SHARE. It means that PM i can only be assigned VMs v_j^k from the same requestv_j . These type of requests are denoted by v_AS.

Anti-sharing constraint

It is not unusual for two competitor companies or Users to rent VMs from the same cloud provider. There can be a case where an attacker from the competitor of a user can try to achieve co-residence in the same PM as user’s VM. The ANTI-COMPETITOR constraint gives the User an ability to say that he does not want his VMs to share VMs with VMs of a his competitor. We are denoting this constraint as ANTI-COMP constraint. These types of requests arev_(AC  ).

Anti-co-residence constraint

There are scenarios when multiple VMs of a particular user reside in one Physical machine and in the event of an Attack on that physical machine all the information on those VMs is lost. ANTI-CORESIDENCE constraint allows a user to say that All VMs in his request should be placed on Separate PMs. All v_j^k  ∈v_j must be placed on different PMs [7]. These types of requests arev_AR.

Definition of VM Placement Problem

We are assuming that each PM I has a D-dimensional vector associated with it which is g_i={ g_i^(1   ),g_i^2……………..,g_i^D  } representing the capacities of PM’s D resource types for CPU, memory, network bandwidth etc. which can be assigned to VMs. Let d= 1,…..D denote an arbitrary PM resource type. Let each v_j^k  ∈v_j have an associated D dimensional resource requirement r_j^k={r_1^k,r_2^k,…  r_D^k} Let x^i (v_j^k ) denote virtual machine placement x^i (v_j^k )=1 when a virtual machine is placed and x^i (v_j^k )=0  when it is not placed. The goal of the heuristics discussed in this research is to place maximum number of virtual machines subject to resource capacity constraints and placement constraints.

Solution for VM Placement Problem

We devise the Solution for this VM Placement combining the Worst Fit Decreasing algorithm and User Defined Constraints.

Worst Fit Decreasing Algorithm: All Virtual Machine Placement problems can be seen as Bin Packing Problems In the bin packing problem, objects of different volumes must be packed into a finite number of bins or containers each of volume V in a way that minimizes the number of bins used. In Worst Fit Decreasing Algorithm we

We order each object in decreasing order of volume

Then we put each Object into the emptiest bin among those with something in them [17]

The objects in our case are Virtual Machines and the bins are Hosts. We first order Virtual Machines in decreasing order of their CPU requirement and then we place them into the host which has most amount of available CPU.

VM Placement Strategy:

We divide the placement constraints into three categories. They are ANTI-SHARING, ANTI-COMPETITOR, ANTI-CORESIDENCE. The first type of requests that are processed are the ANTI-SHARING requests as they need a PM entirely for themselves and therefore are most restricting in nature and hardest to satisfy. Then we fulfil the requests with ANTI-COMPETITOR constraint as they need PMs which do not contain VMs of their competitor. The third category to be processed is the one with ANTI-CORESIDENCE. The last category is that of unconstrained requests or the requests which do not have any constraints added to them.

The heuristic algorithm is outlined in Alg. 1. The inputs to the algorithm are the set of PMs i and vAS ⊆ {vj}, vAC ⊆ {vj}, vAR ⊆ {vj} denoting the subset of the J requests to which the ANTI-SHARING, ANTI-COMPETITOR, ANTI-CORESIDENCE respectively apply, together with vU ⊆ {vj}, denoting the subset of unconstrained requests. We initially sort the requests in each of these subsets in descending order of the number of VMs specified in each request.

For each category of requests, different allocation strategies are used to generate PM groups, where a PM group is the smallest number of PMs needed to place interdependent VMs. We denote a PM group as p and use P = {p} to denote a set of PM groups. In the algorithm we initially set P = ∅ (line 2) and use it to accumulate PM groups for the final placement plan. The size of the PM group depends on the request’s constraint (if any). For example, for requests with ANTI-SHARING constraints the size of PM group is 1, because a minimum of 1 PM is needed to satisfy this constraint. In contrast, for requests with the ANTI-CORESIDENCE constraint the size of the PM group is the number of VMs specified in the request, as all must be placed on different PMs. For ANTI-SHARING requests, we execute the Worst Fit Decreasing algorithm to obtain the allocation mapping from VMs to the PMs for each request. For each request, we start with new empty PMs for allocating the VMs in this request. Then we process requests which are unconstrained requests, can co-exist on PMs, so we process them together (lines 14-33). In the algorithm we use M ∈ NI×n to denote an I by n matrix, where I is the number of PMs and n = |v_AR  ∪ v_U| is the number of requests with ANTI-CORESIDENCE and unconstrained requests. If a VM belonging to a request with ANTI-CORESIDENCE and  unconstrained placement constraints is allocated to a PM, then the corresponding element of M is set to 1, which indicates that the PM is not available for placement of any other VMs for the same request. All VMs in each request are sorted in decreasing order based on the length of the VM resource vector, where the resource vector is the vector sum of the normalized resource requirements of the VM. For each request, all the VMs specified in the request are checked to see if they can be allocated to available PMs, which are ordered in descending order in terms of residual resource capacity. If the

Input: {i}, v_(AS,)  v_AC,v_AR

Output: placement plan

1: Sort v_(AS,)  v_AC,v_AR  in descending order of number of VM specifications included in the requests.

2: Set P = ∅

3: Process ANTI_SHARING requests

4: for each request v_j∈v_AS do

5:     Run WFD algorithm to obtain the allocation

6:     Set where is any PM to which VMs have been allocated

7:     Set P = P ∪ p

8: end for

Process ANTI_COMPETITOR requests

9: for each request v_j∈v_AC do

10:     Run WFD algorithm to obtain the allocation

11:     Set where is the PM Group to which all VMs in request vj have been allocated

12:     Set P = P ∪ p

13: end for

Process all other requests

14: M = ∅

15: for each request v_j∈v_AR  ∪ v_Udo

16:     for k = (1,…,|vj|) do

17:          for i = (1,…,|{i}|) do

18:               if  v_k^jfits in PM i and v_j∈v_AR  ∪ v_U  and

19:   M(v_k^j,i) = 0 then

20:                    Allocate VM vjk to PM i

21:                  Set M(v_k^j,i) = 1

24:           end if

25:       end for

26:     end for

27:     if request v_j∈v_AR  ∪ v_U is not fully allocated then

28:        Reset M, the allocation mapping and residual PM capacities.

29:     else

30:          Recalculate the PM residual capacities

31:          Rank PMs in descending order of residual capacities

32:     end if

33: end for

How CloudSim is used

Download CloudSim installable files from https://code.google.com/p/cloudsim/downloads/list and unzip [19][20]

Open Eclipse

Create a new Java Project: File -> New

Import an unpacked CloudSim project into the new Java Project

The first step is to initialize the CloudSim package by initializing the CloudSim library, as follows:

CloudSim.init(num_user, calendar, trace_flag)

Data centers are the resource providers in CloudSim; hence, creation of data centers is a second step. To create Datacenter, you need the Datacenter Characteristics object that stores the properties of a data Centre such as architecture, OS, list of machines, allocation policy that covers the time or space shared, the time zone and its price:

Datacenter datacenter9883 = new Datacenter(name, characteristics, new VmAllocationPolicySimple(hostList), storageList, 0);

The third step is to create a broker:

DatacenterBroker broker = createBroker();

The fourth step is to create one virtual machine unique ID of the VM, userId ID of the VM’s owner, mips, number Of Pes amount of CPUs, amount of RAM, amount of bandwidth, amount of storage, virtual machine monitor, and cloudlet Scheduler policy for cloudlets:

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

Submit the VM list to the broker:

broker.submitVmList(vmlist)

Create a cloudlet with length, file size, output size, and utilization model:

Cloudlet cloudlet = new Cloudlet(id, length, pesNumber, fileSize, outputSize, utilizationModel, utilization

Submit the cloudlet list to the broker:

broker.submitCloudletList(cloudletList)

12. Start the simulation:

Changes in Cloudsim to Implement Security Aware VM Placement

We changed cloudsim to create our VM Placement subsystem. The changes we added are as follows:

Changes in VM class of CloudSim

VM class originally has following characteristics:

VM id – unique ID of the VM

User ID – User ID of the VM’s requester

MIPS – million instructions per second

Number of Pes – Number of CPUs

Bandwidth – Bandwidth of the VM

Size – Storage capacity

VMM – Virtual machine monitor

Cloudlet Scheduler – Cloudlet scheduler policy

We added these characteristics:

Constraints – this property stores VM placement constraints.

Changes in Host class of CloudSim

Host executes actions related to management of virtual machines (e.g., creation and destruction).

* A host has a defined policy for provisioning memory and bw, as well as an allocation policy for

* Pe’s to virtual machines. A host is associated to a datacenter. It can host virtual machines.

We have added a new member method called hasVMs which takes array of users checks if any user has VMs in the host. [19][20]

public Vm hasVMs(int[] user) {

for (Vm vm : getVmList()) {

for (int i = 0; i < user.length; i++) {

if (vm.getUser() == user[i]) {

return vm;

}

}

}

return null;

}

Changes in VMAllocationPolicy class of CloudSim

This class chooses the appropriate host for a VM. The algorithm to choose a host is below:

1. Get constraints and user IDs

2. A (Anti-competitor, 0) – not sharing with competitors but can share with others

– get the competitor’s ID from the VM request

– check if the host has any VM with the competitor’s ID

– if yes go the next host, otherwise create the VM

3. S (Anti-sharing, 2) – No sharing at all. Only a user’s VMs can be on a host

– check the host to see if it has any VM with the user of the requested VM.

– If it has VM on this host by any other, then check another host. Otherwise, create VM.

4. F (Anti-co-residence, 1) – No more than one can be on a VM for this user.

– Check if this user’s VM exist on this host.

– If it does then go to the next host. Otherwise, create VM.

5. X (No constraints, 3 & 4) – No constraints.

– run anti-competitor and anti-sharing check. If check is passed create the VM otherwise go to                                    the next host. [19][20]

1. Get constraints and user IDs

2. A (Anti-competitor, 0) – not sharing with competitors but can share with others

– get the competitor’s ID from the VM request

– check if the host has any VM with the competitor’s ID

– if yes go the next host, otherwise create the VM

3. S (Anti-sharing, 2) – No sharing at all. Only a user’s VMs can be on a host

– check the host to see if it has any VM with the user of the requested VM.

– If it has VM on this host by any other, then check another host. Otherwise, create VM.

4. F (Anti-co-residence, 1) – No more than one can be on a VM for this user.

– Check if this user’s VM exist on this host.

– If it does then go to the next host. Otherwise, create VM.

5. X (No constraints, 3 & 4) – No constraints.

– run anti-competitor and anti-sharing check. If check is passed create the VM otherwise go to                                    the next host.

The following figure depicts the flowchart of the VM allocation policy which internally implements the security aware virtual machine placement.

Figure 7.2.5.3.1 Screenshot of VM Placement Sub System

Subsystem integration

The multiple subsystems described above require integration in order to work properly. Integration of the Virtual Machine Request Subsystem and Virtual Machine Placement Subsystem is fairly simple as they both reside in a Single machine. The VM request Subsystem is made using JAVA Swing. It is a Java Stand Alone application which interacts with the VM Placement Subsystem.

CHAPTER VIII

VERIFICATION

VM Request Subsystem Verification

The Verification of VM request subsystem simply means testing that VM requests are getting uploaded in the form of a CSV file. The other test is whether results are getting displayed on press of input button. The scenarios that need to be tested are:

The System is permitting the users to enter virtual machine requests,

The System is allowing users to enter Virtual Machine Requests in the form of a CSV File,

The Virtual Machine Request CSV File has VMid, CPU, Memory, VM Constraints,

The System is permitting user to view the results of VM placement.

Figure 8.1.1 a screenshot of VM Request Subsystem Verification test

VM Placement system Verification

To test the VM placement subsystem we need to test whether VM requests are getting accepted by the VM Placement subsystem and are getting placed. We need to verify whether this subsystem is returning results in the format required. The tests that need to be conducted are

Number Of virtual machines placed

Which VM was placed on which Physical Machine

How much time was needed in doing the placement

Which VM was placed in which Data Center

System Integration testing

To do the system Integration testing we simply need to submit a csv with VM requests on VM Request Subsystem and see that the data from the same CSV is used as an input by VM Placement subsystem. We also need to check that VM placement subsystem is returning the data in the same format as desired y VM Request subsystem which in this case is the execution time of Security Aware VM Placement scheme in milliseconds for a particular set of VM Requests.

CHAPTER IX

VALIDATION

We do the validation testing of our Security Aware VM Placement System by conducting experiments with 3 datasets, analyze them and draw conclusions. We wanted our experiments to every close to real-life cloud scenarios therefore the VM types we have taken are directly from Amazon Web Services (AWS) VM types and its simulated over 20 hosts with 48 CPU with every CPU equal to 1 Amazon ECU.

Table 9.1 Amazon EC2 Instance Types

Type Of Instance RAM No Of ECUs Bandwidth

T1 Micro 0.613 GB 1 vCPUs  Up to 100 Mbps

T2 Nano 0.5 GB 1 vCPUs Up to 100 Mbps

T2 Micro 1.0 GB 1 vCPUs Up to 100 Mbps

T2 Small 2.0 GB 1 vCPUs Up to 100 Mbps

T2 Medium 4.0 GB 2 vCPUs Up to 100 Mbps

T2 Large 8.0 GB 2 vCPUs Up to 100 Mbps

T2 Extra Large 16.0 GB 4 vCPUs Up to 100 Mbps

T2 Double Extra Large 32.0 GB 8 vCPUs Up to 100 Mbps

Performance Comparison

One of the primary objectives of this research is to compare performance of our Security Aware VM Placement algorithm versus a commonly used VM placement algorithm. We compared our algorithm with Worst Fit Decreasing Algorithm as it is one of the most commonly used VM Placement algorithms. Also as our algorithm is a modification of Worst Fit Decreasing, so this analysis would give us an opportunity to see the performance of our algorithm Vis a vis WFD.

We created three test cases with homogenous VM Requests across all users and computed VM Placement execution time i.e. the time between the request getting received by VM Placement Subsystem to the time all VMs were placed The idea was to compare the difference in the execution time between our algorithm vs WFD algorithm:

Figure 9.1.1 Test 1 – Performance comparison between security aware and WFD

Table 9.1.1 Table of Performance comparison – Test 1

Time taken in milliseconds

No. Of VM Requests Security Aware VM Placement Worst Fit Decreasing

25-30 105 99

50-60 97 94

75-85 93 88

Figure 9.1.2 Test 2 – Performance comparison between security aware and WFD

Table 9.1.2 Table of Performance comparison – Test 2

Time taken in milliseconds

No. Of VM Requests Security Aware VM Placement Worst Fit Decreasing

100 – 110 171 140

200 – 215 147 125

300 – 307 116 106

Figure 9.1.3 Test 3 – Performance comparison between security aware and WFD

Table 9.1.3 Table of Performance comparison – Test 3

Time taken in milliseconds

No. Of VM Requests Security Aware VM Placement Worst Fit Decreasing

500 – 510 280 180

1000 – 1015 663 313

1500 – 1520 1089 357

.

Comparison of Host Utilization

The    power  consumption  by  a  server  grows  linearly  with  the  growth  of  CPU  utilization  from  the  value  of  power  consumption   in   the   idle   state   up   to   the   power  consumed  when  the  server  is  fully  utilized.  This relationship can be expressed as.

P(u)=P_idle+(P_busy- P_idle )*u

Where  P(u)  is  the  estimated  power  consumption  for  the current CPU utilization u. P_idle is  the  power  consumption  by  an  idle  server, P_busy is  the  power  consumed  by  the  server  when it is fully utilized[22].Therefore in order to reduce the power consumption at a datacenter it is important that idle servers are shut down. In this test scenario we compare how many hosts are required to satisfy n number of VM requests.  As our Security aware VM placement algorithm is based on placement constraints it does put constraints on using hosts which are either hosting VMs with ANTI_SHARING constraint or ANTI-COMPETITOR Constraint. Therefore it is important to see the impact of our algorithm on host utilization Vis a Vis Worst Fit Decreasing VM placement algorithm.

Here also we have created three test scenarios:

Figure 9.2.1 Test 1 – Comparison of host consolidation between security aware and WFDs

Table 9.2.1 Table of Host Consolidation – Test 2

Number of Hosts Utilized

No. Of VM Requests Security Aware VM Placement Worst Fit Decreasing

25-30 8 4

50-60 9 6

75-85 10 7

Figure 9.2.2 Test 2 – Comparison of host consolidation between security aware and WFDs

Table 9.2.2 Table of Host Consolidation – Test 2

Number of Hosts Utilized

No. Of VM Requests Security Aware VM Placement Worst Fit Decreasing

100 – 110 9 7

200 – 215 16 12

300 – 307 20 15

Analysis & Conclusion

The comparison of performance of our Security Aware Virtual Machine Algorithm versus Worst Fit decreasing algorithm shows very promising results. The difference of time taken to place virtual machines using our algorithm versus Worst Fit Decreasing is very less in Test case 1 and Test case 2. It shows that our algorithm will perform very well for small and mid-sized networks. Also if we compare Host Utilization we do not see a significant difference between both algorithms. The results show that The Security Aware Virtual machine Placement Algorithm can have can have a dramatic effect on VM placements, but interestingly, relatively little effect on performance of virtual machine placement at cloud provider’s end. That is, such complicated scenarios present operational difficulties, but are not critical when the cloud provider prepares a business model. The business model needs to be such that cloud provider is incentivized for allowing users to specify placement constraints for security reasons.

CHAPTER X

LIFE-CYCLE ANALYSIS

System Development

This system is primarily developed using CloudSim which is an open source tool so the cost of buying software is definitely saved. But the cost of hiring a systems analyst for requirements gathering, software engineer for design and implementation and quality assurance engineer for system validation and testing still needs to be taken into account.

Task Resource Cost/hour Estimated Man hours cost

Requirements gathering Systems Analyst $30/hour 120 3600

Preliminary design Software Engineer $35/hour 96 3360

Detailed design & development Software engineer $35/hour 200 7000

System verification & testing Quality Assurance Engineer $30/hour 200 6000

Total    19960

Table 10.1.1 System Development Cost

System Utilization

The utilization cost of this system will be almost negligible with the only cost being that of software maintenance on yearly basis. It is because CloudSim gets a new version every year. The installation of the system will only take two hours and the system requirement is only a system with Java Virtual Machine running on it.

System Support

Maintenance and support during the first year is expected to consist primary of bug fixes and minor enhancements as determined when the system is placed in production.  After four years the system should be phased out, although, if it is still useful it might be considered for reuse in a newly designed system.  Similar to the development costs above, the maintenance cost will consist primarily of the labor.

Task  Resource  Cost/Hour

r  Est’d

Manhour s  Cost  Est’d

Manhour s  Cost  Est’d

Manhour s  Cost  Est’d

Manhour s  Cost  Est’d

Manhour s  Cost

Bug Fixes

Write code changes  Software Engineer $35   16   $560  8   $280  8   $280                8                $280                8                $280

Testing  Quality Assurance Specialist  $30   8   $240  8   $240  8   $240   5                $150                5                $150

Review changes  Software Engineer  $35   8   $280   4   $140  4   $140                4               $140                4                $140

Total           $1080      $1,18

0      $660      $660     $660

Table 10.3.1 System Support Costs

System Retiring

The lifecycle of this system is estimated to be 5 years as after that newer cloud simulation technologies will make this system obsolete. The phase out of this system will only mean uninstalling it from a system. So the cost will be negligible here.

Total Cost of System

This system is very useful for researchers who cannot afford large scale cloud infrastructure to test their Virtual Machine Placement algorithms. There is only a system development cost associated with it. But System Utilization cost is almost negligible.

Task  Year 1 Cost  Year 2 Cost  Year 3 Cost  Year 4 Cost  Year 5 Cost

System Development  $19960

System Utilization  $30 $30 $30 $30 $30

System Maintenance  $1,080 $1040 $660 $660 $660

Total Per Year  $21070  $1070 $690  $690 $690

TOTAL    $24210

Table 10.5.1 Total Cost Of System

CHAPTER XII

CONCLUSIONS AND FUTURE WORK

Conclusion

The results show that The Security Aware Virtual machine Placement Algorithm can have can have a dramatic effect on VM placements, but interestingly, relatively little effect on performance of virtual machine placement at cloud provider’s end. That is, such complicated scenarios present operational difficulties, but are not critical when the cloud provider prepares a business model. The business model needs to be such that cloud provider is incentivized for allowing users to specify placement constraints for security reasons. The cloud provider could define 3 levels of security where level 1 is least expensive and level 3 is most expensive. Level 1 could be the default level of security. Level two could be where all virtual machines belonging to a user are kept on separate physical machines. Level 3 or topmost level of Security could be where a user does not have to share his Physical Machine with any other user. Level 3 should be made the most expensive level of security the cloud provider gives. Cloud provider could be thus be incentivized for the operational overhead caused by implementing the algorithm.

Future Work

The future work could focus on further improving the performance of our algorithm. It would be interesting to apply the method to more general VM allocation scenarios that include reallocation of VMs across physical machines to increase costs and save power. Second if reallocation costs are included in the objective function, It is also possible to consider trade-offs between obtaining the optimal allocation at a given instant and obtaining a temporally sub-optimal solution that increases profit in the long run.