1. National College of Ireland
Project Submission Sheet – 2015
School of Computing
Student Name: JYOTI TYAGI
Student ID: X01318374
Programme: M.Sc Cloud Computing Year: 2015
Module: Research Dessertation
Lecturer: Dr. ARGHIR MOLDOVAN
Submission Due
Date: 31/08/2015
Project Title: Modification in the behavior of Nova Filter Scheduler to enhance the
performance in OpenStack cloud.
Word Count: 9400
I hereby certify that the information contained in this (my submission) is information pertaining to
research I conducted for this project. All information other than my own contribution will be fully
referenced and listed in the relevant bibliography section at the rear of the project.
ALL internet material must be referenced in the bibliography section. Students are encouraged to use
the Harvard Referencing Standard supplied by the Library. To use other author's written or electronic
work is illegal (plagiarism) and may result in disciplinary action. Students may be required to undergo
a viva (oral examination) if there is suspicion about the validity of their submitted work.
Signature: Jyoti Tyagi
Date: 31-08-2015
PLEASE READ THE FOLLOWING INSTRUCTIONS:
1. Please attach a completed copy of this sheet to each project (including multiple copies).
2. You must ensure that you retain a HARD COPY of ALL projects, both for your own reference and in
case a project is lost or mislaid. It is not sufficient to keep a copy on computer. Please do not bind
projects or place in covers unless specifically requested.
3. Assignments that are submitted to the Programme Coordinator office must be placed into the
assignment box located outside the office.
Office Use Only
Signature:
Date:
Penalty Applied (if applicable):
2. Modification in the behavior of nova
Filter Scheduler to enhance the
performance by reducing latency in
the OpenStack.
Jyoti Tyagi
Submitted as part of the requirements for the degree
of MSc in Cloud Computing
at the School of Computing,
National College of Ireland
Dublin, Ireland.
September 2015
Supervisor Dr. Arghir Moldovan
3. Abstract
Cloud computing emerged as a promising solution to IT industry as it offers on-demand
application services, IT infrastructure & virtualized computing resources over the in-
ternet as utility to cloud users in pay-as-you-go manner. Consequently, it also reduces
the cost associated with open source cloud computing platforms like OpenStack.
But in this field, dynamic, scalable and efficient provision of virtualized resources is
one of the most challenging research area. So, we explore the dynamic resource man-
agement issues of OpenStack because the flexible and efficient resource allocation is
an important aspect. Our research basically focus on the scheduler component which
plays an important role in determining how to dispatch the virtual machine launching
requests to compute node and assigning host to instances on particular node through
some predefined rules.
The main objective of this dissertation is to assess the behavior of nova scheduler in
Openstack with an aim of reducing latency in placing VMs by finding relation between
scheduling and several factors such as number of cores, amount of memory and disk
allocated to physical as well as virtual machines. In this work, critical analysis of
existing scheduling functionality of the nova scheduler has been done to understand
the research problem. We aim to find the limitations in the default filters of the nova
scheduler and attempt to ultimately improve the performance & resource allocation
process.
The main contribution of this work is to enhance performance of OpenStack platform by
changing the default behavior of scheduler. Further, an experiment has been performed
to prove the novelty into this research through modifying the essential filters in the
Scheduler. Various scheduling filters have been analyzed to check their impact on the
performance by changing their default values in various metrics. Thus, the solution
incorporates the modified filters which efficiently and quickly allocate the resources.
In this research, we also discuss on efficient & flexible ways of managing resources
through nova-scheduler. Thereafter, experiment has been benchmarked by a tool called
ii
4. Rally, to evaluate the performance of OpenStack scheduler by comparing the default
scenario against the modified one.
Towards the end, the results shows the significant effect on the response time of launch-
ing VM due to changed parameters like number of CPU cores present on nodes &
amount of memory assigned to VMs etc. Further, improvement in the Openstack
scheduler has been specified.
Keywords: Open source cloud, OpenStack, Nova Scheduler, Virtual machine place-
ment, Filters, Benchmarking tool- Rally.
iii
5. Acknowledgement
This thesis Modification in the behavior of Nova Filter Scheduler to enhance the perfor-
mance in OpenStack cloud for Masters in Science degree, was carried out in the Cloud
Competency Center, National College of Ireland, Dublin.
I would like to express my sincere gratitude to my supervisor, Dr. Arghir Moldovan
for the continuous support in completing this research, for his patience, motivation
and sharing immense knowledge. I am grateful for his efforts, valuable discussions
and guidance. Each meeting with him lifts up my confidence level and broadened the
perspective on the issues and added new aspects to the implementation. Besides, I
would like to thank with sincere gratitude to Dr. Horacio Gonzalez-Velez, Dr. Pramod
Pathak and Robert Duncan for helping in successful completion of this course. I am
thankful to NCI staff, IT support, NCI online resources and especially Keith Brittle
for improving my writing and referencing skills. I thank all the people, who helped me
directly or indirectly in finishing my thesis work.
I would like to thank all my classmates and friends who supported me in difficult time.
Their help and care is appreciable which helped me to focus on my studies. I am
grateful to them for supporting and encouraging me in a new country.
I express my deep love and gratitude to my parents and family for their continuous
love, support and encouragement. This work is especially dedicated to mom and Dad
because without their support, I couldnt reach here.
iv
6. Declaration
I confirm that the work contained in this MSc project report has been composed solely
by myself and has not been accepted in any previous application for a degree. All
sources of information have been properly acknowledged.
Signed .........Jyoti Tyagi................................... Date .......30/08/2015...............
v
12. Chapter 1
Introduction
Cloud services are growing immensely as CSP (cloud service provider) promise cus-
tomers to provide cost efficiency, high availability, dynamic provisioning and great
scalability. In order to fulfill such promises, cloud providers use virtualization tech-
nologies to share physical infrastructure and resources among multiple tenant within a
same cloud platform. This means, cloud computing relies on the sharing of resources.
Therefore, cloud computing also present a critical and researchable issues which must
be considered during dynamic resource scheduling in cloud environment. The research
question arises for this dissertation is as follows:
Research Question: Modification in the behavior of nova Filter Scheduler to enhance
the performance by reducing latency in the OpenStack.
Before we proceed, it is important to understand the cloud computing concepts, im-
portance of resource sharing & resource allocation.
Rosado, T. & Bernardino, J. (2014), Nasim, R. & Kassler, A.J. (2014) and Litvinski, O.
& Gherbi, A (2013) define cloud computing as a model which deliver ubiquitous, infras-
tructure, platforms development tools, software applications and on-demand virtualized
resources like compute, network & storage over the internet with essential character-
istics as broad access network, elasticity, resource pooling, reliability and scalability.
In simple words, Litvinski, O. & Gherbi, A. (2013) defines cloud as a huge distributed
system used for providing resources as a service. It can categorized into two parts, pub-
lic cloud in which users can consume such services from external vendors called cloud
service providers like Amazon, Azure etc. and the second is private cloud in which
enterprises can follow this model inside their companies. So, resource management is
a vital aspect in cloud computing. The main purpose of efficient resource allocating
1
13. strategy is to utilize the available resources to reduce the operational cost, According
to Nasim, R. & Kassler, A.J. (2014).
Rosado, T. & Bernardino, J. (2014) belive that Cloud computing is recently gaining
lot of attention especially open source cloud solution. Litvinski, O. & Gherbi, A.
(2013) explains the reason that they are open source & easily available nowadays.
Litvinski, O. & Gherbi, A (2013) mention few open source cloud projects such as
Eucalyptus, Open Nebula and OpenStack which can be used to deploy private, public
and hybrid IaaS cloud. Zhang, Y. et al (2014) IaaS refers to the provisioning of on-
demand virtualized resources like compute, network and storage. Zhang, Y. et al (2014)
state that OpenStack is widely open source and robust IaaS project (Bist, M. et al.
2012) The main reason for using open source cloud is to avoid vender lock-in.
According to Rosado, T. & Bernardino, J. (2014) , OpenStack cloud has been proved as
performant, scalable, and highly adaptive open source architecture for both public and
private cloud solution in the market. Huanle, Y. et al (2013) justify this by specifying
the low-cost characteristics of OpenStack as one of the biggest reason for adoption
because the cost related to cloud development, operating and maintenance is reduced
heavily. As result of growing popularity, we use OpenStack and discuss its architecture
in the coming sections.
In the opinion of Huanle, Y. et al (2013), maximizing the utilization of shared resources
is an important aspect of any infrastructure management system. Few metrics such
as CPU utilization, memory utilization, disk I/O, network I/O etc. can be measured
to check proper resource usage. However, Huanle, Y. et al (2013) mention that in
OpenStack, initially scheduling policies are used to maintain balance load among re-
sources when a new VM is created but further this balance could be hindered due to
several other factors like adding, removing or updating hypervisor. As a consequent
result, such scheduling policies are no longer valid due to their negative impact on cloud
platform performance and user experience.
So, Rai, R.H. et al (2012) stress on the dynamic resource allocation as an important
issue faced by management of data center in which we have to concentrate more on VM
placements and resource scheduling. In addition, Zhong, H. et al (2010) explain that
resource scheduling is key concept implemented in IaaS clouds. Further their work
focus on improving the resource allocation algorithms. In our work, we introduce a
novelty of improving default Filter Scheduler of our OpenStack cloud to specifically
target the resource allocation problems.
In order to undertake our research, we used OpenStack as a private cloud in which
2
14. scheduling is done through Filter Scheduler. We specifically focus on the various fil-
ters present in scheduler of OpenStack, their equation with amount of memory, core,
disks or other physical resources requested by launched VMs. We also study about
how scheduler’s decision to place VM affects performance. We proposed a solution of
changing the default behavior of filters present in nova-scheduler of OpenStack. In this
dissertation, we claim that our solution will address the most significant problem of
idle resource wastage as this solution will schedule instances and allocates resources in
a way that enhance the performance of our cloud. In order to execute this, we alter the
existing filters such as Ram Filter, Disk Filter and Core Filter etc. The filters mainly
focuses on resource and host allocation as per user request.
Furthermore, the modified filters are now capable of launching the users instance quickly
on the best host out of available host. In the end, we benchmark the performance of
Openstack cloud using the Rally tool.
The document is structured as follows: Chapter 2 discusses the background of the re-
search problem which includes the detailed overview of OpenStack Background, Open-
Stack Architecture and Its Services, virtualization and Scheduling in OpenStack. The
next chapter will discuss the design of all the OpenStack, hardware set up and software
required for experiment. The following chapter gives the clear picture of implementa-
tion of our private cloud and the proposed solution. Chapter 5 present the execution &
benchmarking of all the test cases discussed and the evaluation of the discuss metrics
at the end of the experiment to examine the performance. In the last chapter, we
conclude the outcome and outline the significant future work that needs to be done.
3
15. Chapter 2
Background
This chapter evaluates the literature review in order to identify the research gap. The
background is formulated as follows: This chapter begins with the detailed explanation
of basic OpenStack architecture and its various services in section 2.1. Further, the
next section 2.2 put an emphasis on the importance of virtualization in cloud. The
following section 2.3 describes the scheduling functionality of nova scheduler. In addi-
tion, different filters have been studied and analyzed under section 2.4 to understand
the working of scheduler while assigning VM to hosts.
2.1 OpenStack Background
In this section, we study the basic concepts, principles and terminologies which are nec-
essary to understand the open source cloud computing platform and scheduling process.
Subsequently, we explain the main elements in the following sections. In cloud comput-
ing, services are classified into three groups such as Infrastructure-as-a-Service (IaaS),
Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS),According to Litvinski,
O. & Gherbi, A. (2013). The virtualization is the key technology of cloud computing
which helps us to achieve efficient resources management.
Rosado, T. & Bernardino, J. (2014) , (Bist, M. et al. 2012) and Nasim, R. & Kassler,
A.J. (2014)state that OpenStack is a completely open source cloud computing plat-
form, developed by NASA and Rackspace. Khan, R.H. et al (2011) further state that
out of all the open source projects such as CloudStack, Eucalyptus, and OpenNebula
etc., OpenStack is the most prominent project. It is so far gaining lot of popularity
by providing robustness, trustworthiness and high availability in IaaS platform for im-
plementing both public and private cloud. Cloud computing experts from all over the
4
16. world are making contribution to this project.
Huanle, Y. et al (2013) assert that OpenStack is one of the largest IaaS management
platform which has released 7 editions of it since October 2010. Moreover, Nasim, R. &
Kassler, A.J. (2014) confer that more than 170 leading companies including Rackspace,
Citrix, VMware, HP, Dell etc. are investing their money & time in this project. So,
OpenStack is gradually developing and improving with time. Rosado, T. & Bernardino,
J. (2014) and Nasim, R. & Kassler, A.J. (2014) claim that as a result of ongoing studies
on open source cloud solutions, OpenStack has been emerged as the most adoptable
and promising open source platform which aims for providing massively scalable infras-
tructure and rich features. As per Wuhib, F. et al. (2012), OpenStack is flexible as
it is designed in way that user can customize it according to their objectives. It uses
python as the programming language.
Nasim, R. & Kassler, A.J. (2014) and Litvinski, O. & Gherbi, A. (2013) mention the
main factors that make OpenStack an interesting candidate for competition in market
are massive scalability, high flexibility( like support for various hypervisors) and open
source solution. Code is easily available from github site and can be modified according
to the requirements, Github (2015). Sahasrabudhe, S.S & Sonwani, S.S (2014), fur-
ther explain the main components of OpenStack infrastructure as storage, network and
compute. Sahasrabudhe, S.S & Sonwani, S.S (2014) put emphasis on the efficient allo-
cation of the resource in such a way that benefits both cloud user and provider. Nasim,
R. & Kassler, A.J. (2014) perform an experiment to prove that performance of Open-
Stack cloud over dedicated hardware is way better than OpenStack over virtualized
environment. According to Litvinski, O. & Gherbi, A (2013) and Sahasrabudhe, S.S &
Sonwani, S.S (2014), the main goal of OpenStack is to create elasticity, highly scalable
cloud operating system and simple implementation. Further, OpenStack is combina-
tion of major seven services like Nova, keystone, Neutron, Cinder, Swift, Glance and
Horizon. Litvinski, O. & Gherbi, A (2013) , (Bist, M. et al. 2012)and Nasim, R. &
Kassler, A.J. (2014) explain the purpose of only few services of OpenStack whereas
OpenStackConfiguration Reference (2015) explain the complete implementation of pri-
vate cloud through configuring variety of services as each service provides an API which
makes the integration possible. The following table 2.1 describes the list of all current
OpenStack services:
5
17. Figure 2.1: Table OpenStack Services
In this research, we mainly focus on the compute service and understand how it is
related to other services and scheduling resources. Nova is the one of the core service
for building cloud platform. It is composed of six main component which are, Nova-API
for providing interface, Nova compute for managing VM, message queue for interaction
between various services, Nova-scheduler for taking decision about instance placement
and nova network for handling the networks and IP addresses in the cloud.
In the next section, we study the architecture of OpenStack in detail to resolve the
above research problem.
6
18. 2.2 OpenStack Architecture and Its Services
Normally, the process of launching instances require many interactions to occur among
services. The figure 2.2 below illustrates the architecture of OpenStack along the in-
teraction of compute service with existing services.
Figure 2.2: Conceptual architecture of OpenStack
Zhang, Y. et al (2014) describe the roles, tokens and projects in OpenStack. Projects
are defined by assigning domain to it. Each user in domain will be assigned a project
and particular role. Each role has significant access privileges to the cloud services and
to the project. For instance, by assigning admin role to the user will provide the admin
permissions over the project.
Rosado, T. & Bernardino, J. (2014) assert that the highly configurable and flexible
architecture of OpenStack allow users to implement this solution for every kind of
project. As a result, Enterprises can select from a pool of complementary services
in order to fulfill their need and requirements of computing, storage, networks etc.
7
19. Therefore, its not mandatory to configure all services.
Both Rosado, T. & Bernardino, J. (2014) and Sahasrabudhe, S.S & Sonwani, S.S
(2014) describe the major five components groups based on essential characteristics like
computing, storage, networking, shared and supporting services. These components are
described in the following sections:
2.2.1 Computing Service
Nova: This service is one of the most indispensable service for basic cloud implemen-
tation which provides on-demand virtual servers with multiple supporting hypervisors
such as KVM (kernel based virtual machine), Xen, VMware or hyper-V. Users can eas-
ily create, delete and manage Virtual machines. OpenStack has wide range of software
for resource management through APIs and are proficient in orchestrating running in-
stances, network and access contro, according tol Rosado, T. & Bernardino, J. (2014).
In addition, (Bist, M. et al. 2012)and Datt, A. et al (2015) confer that nova is an open
source cloud platform for provisioning VMs and manages overall virtual machines in
the cloud. The compute node require large amount of physical resources to provide vir-
tual CPUs, resources and other services. It includes services such as instance creation,
deletion, migration, snapshot creation and instance termination. However, nova has no
virtualization capabilities but is uses libvert APIs to communicate to hypervisors.
Important functions and features of nova areas follows:
• Life cycle management of instance.
• Compute resource management.
• Networking and authorization.
• REST based APIs.
• Asynchronous communication.
• Hypervisor support such as KVM, VMware, Hyper-V, XenServer/XCP etc.
Major components of nova are
• API Server (nova-api): It is an end point for user interaction.
• Message Queue (rabit-mq server): central communication point for services. Rab-
bitMQ is the standard message queue.
8
20. • Compute (nova-compute): responsible for creating and deleting instances through
Hypervisor APIs.
• Nova-db: Its a database used to store and maintain the information about cloud.
• Nova-conductor: It act as a mediator between nova-compute and the nova-db. It
eliminates the direct access to avoid security risks.
• Scheduler (nova-scheduler): Its main task is to schedule the virtual machines. It will
accept the request for launching instance through queue and select the appropriate
host after applying scheduling algorithms.
Glance: It is also an essential service for implementing basic OpenStack cloud archi-
tecture. This image service act a system for determining, registering and retrieving
virtual machine images from database through APIs. This access VM images meta-
data, keystone authentication and handles large libraries of servers image.
2.2.2 Networking
Neutron: Network connectivity as a service is provided between interfaces of other
OpenStack services like nova through this neutron service. It manages DHCP (dynamic
host configuration protocol), IPs (static internet protocols), VLANs (virtual area net-
work) and advanced policies with network topologies. This permit user to build tenant
specific networks. In addition to this, users are leveraged to use frameworks (intrusion
detection & load balancing) from other vendors.
2.2.3 Storage
Swift: Biswas, P. et al (2015) state that it is a highly available, distributed storage for
object which permit users to store and retrieve data kept in the form of distributed
object/blob. It is a highly deployed solution with unlimited capacity used to store all
size of objects efficiently, safely and cheaply using redundant storage system.
Unlike conventional storage architectures where data is managed as files and block,
Swift manages data as objects.
Cinder: Also known as OpenStack block storage, assigns a persistent storage in a form
of block or volume to guest virtual machine. In fact, it can be used to provide back up
to VMs volumes. Rosado, T. & Bernardino, J. (2014) state that cinder was an integral
9
21. part of Nova in the initial release of OpenStack. Moreover, cinder provides volumes to
the nova instances and define each volume type and volume snapshots.
2.2.4 Shared Services
Keystone: OpenStack Identity service is essential service for OpenStack cloud imple-
mentation provides interaction among services through token authentication. Its a
single point where all services, policies & catalog integrate. So, there would be no
intermediate between services and cloud services wont be able to reach end users if the
keystone is not present.
Horizon: This provides easy access to services through dashboard for managing cloud
infrastructure through modular web application interface where services interact with
each other through public APIs.
Ceilometer: It delivers a new unique system added for billing and metering OpenStack
services in terms of CPU, network & storage consumption.
2.2.5 Supporting Services
Databases: By default, core services of OpenStack uses MySQL relational database to
store configuration and management information. Database is installed on the main
node i.e. controller node. It is a critical service for cloud implementation.
Advanced Message Queue protocol: AMQP is an essential service used in OpenStack
for services to communicate to each other. By default, OpenStack uses Rabit-mq but
it supports other messaging technology like Quid, ZeroMQ. This provides a common
platform between various services to send and receive messages.
2.3 Virtualization
Virtualization is the core technology in cloud computing to distribute the computational
resources like CPU, network and memory to users in a cost effective manner. The
crucial benefits of this technology is dynamic resource allocation and flexibility. To
prove the benefits of virtualization, (meng 2013) mention an example of Amazon’s
EC2( Elastic Compute Cloud) which allows multiple tenants to create VM instances
on the same physical hardware and manages entire software stack over the OS kernel.
10
22. Users pay precisely as per usage of resources. Hence, efficient use of virtualization
allows cloud providers to gain huge profit by multiplexing many customers’ VM across
shared hardware resources and drastically reduce the capital investment and cost of
maintenance.
In this paragraph, we explain basic concepts of VM and hypervisors. A virtual machine
is an emulation of a particular computer and provides a substitute for a real machine
in a computing environment. Moreover, users can scale up and scale down according
to requirements. Furthermore Nasim, R. & Kassler, A.J. (2014), (Liu, Weng, Li & Luo
2010) and (Yu, Gui & Lin 2013) define VMM (Virtual Machine Monitor) also known
as hypervisor, lying between host operating system and hardware enables the multiple
virtual machines(guest VM) to run on top of single physical machine(host VM). Nasim,
R.& Kassler, A.J. (2014) discuss the division of it into three types: full virtualization,
para-virtualization and operating system level virtualization. We will only discuss para-
virtualization. In para-virtualization, performance is high due to extending host OS
with hypervisor and the guest OS is aware of virtualized environment. Xen and KVM
(kernel based virtual machines) are good techniques of para-virtualization. Nowadays,
server virtualization is one of the most common type of one-level virtualization that
provides flexible resource allocation and improves failure recovery.
Our choice of using KVM as hypervisor is motivated by that fact that Linux kernel is
serving as a hypervisor in OpenStack. Nasim, R. & Kassler, A.J. (2014) give details
of the wide range of hypervisors which can be supported by OpenStack but selecting
hypervisor is a critical task as cloud’s performance vary with different hypervisors.
Nasim, R. & Kassler, A.J. (2014)clearly state that KVM and QEMU are the two
hypervisors present in OpenStack with almost same feature but still performance of
KVM is better as compared to QEMU.
Nasim, R. & Kassler, A.J. (2014) and Xu, J. & Fortes, A.B. (2010) both explain
that virtualization offers the opportunity of deploying the multiple virtual machines
of different tenant on the single infrastructure which increase resource utilization and
thus reduce the cost and power consumption. On the other hand, Goiri et al (2010)
point out the additional overheads occurs due to virtualization such as virtual machine
creation and migration etc. However, Goiri et al (2010) also discusses how extensive
utilization of virtualization in data center helps in reducing the power consumption
by allocating resources through a dynamic job scheduling policy. Moreover, Xu, J. &
Fortes, A.B. (2010) agrees with Goiri et al (2010) in terms of improvement in efficiency
due to virtualization as multiple independent virtual machines can run on one physical
server. Nevertheless, Xu, J.& Fortes, A.B. (2010) also highlight the new challenge of
VM placement problem introduced as a result of resource, cost and power optimization.
11
23. Hence, scheduling is a very important research area to overcome this problem.
2.4 Scheduling In OpenStack
This dissertation puts emphasis on efficient resource allocation and OpenStack sched-
uler and its various types. Further this section gives an overview of Nova Scheduler
and various filters.
2.4.1 Scheduler and Its Types
When a user requests for launching one or more number of virtual machines on de-
mand, then it’s important to understand how instance placement decisions take place.
Although, various placement algorithms are usually adopted for this, but will discuss
about OpenStack Scheduler.
Huanle, Y. et al (2013) and Khan, R.H. et al (2011) explain that OpenStack Scheduler
simply return a list of compute nodes on which VM instances can be launched if there
is a need for creating instance. The main purpose of filters in scheduler is to find out
the list of all relevant hosts and the weighing algorithm calculates the weight of each
host and then chooses the best suitable host.
Sahasrabudhe, S.S & Sonwani, S.S (2014) point out the main objective of scheduler
is to achieve high utilization and to meet performance requirement of user. Infact,
Sahasrabudhe, S.S & Sonwani, S.S (2014) state that nova-scheduler is responsible for
task scheduling in OpenStack. It handles the request according to resource availability.
The placement strategies in scheduler should achieve performance and security with
minimum latency.
Huanle, Y. et al (2013) describe the earlier OpenStack ’s scheduling architecture in
detail. Earlier, resource scheduling process runs in the background as a daemon pro-
cess where a compute node is picked up on the basis of some algorithm if there is a
requirement to create new instance of a virtual machine. If a request comes for creat-
ing virtual machine instance, message queue sends a message to scheduler to fulfill the
request. Further, scheduler forwards the creation request to nova compute to launch
instance after calling hypervisor driver API and update the database with correct re-
source consumption.
Litvinski, O. & Gherbi, A. (2013) specify the three types of Scheduler, listed below:
12
24. 1. Filter Scheduler
2. Chance Schedule
3. Simple Scheduler
Litvinski, O. & Gherbi, A (2013) and Sahasrabudhe, S.S & Sonwani, S.S (2014) also
explain the types of schedulers: first is the filter (two staged process) which has been
further divided into two parts: filtering and weighing. Filtering provides a list of
hosts which satisfy the user requirement and weighing process will finally decide where
to launch instance according to the weighted cost score associated with each host,
calculated by applying cost functions. Second is the Chance which randomly selects
from the list of available compute host regardless of its characteristics and last is the
Simple which finds out the node with least load. Litvinski, O. & Gherbi, A. (2013)
analyze that behavior of Simple and Filter Scheduler is almost same if we have large
amount of RAM.
However, Litvinski, O.& Gherbi, A (2013) focus more on request generator, sched-
uler observer and load generator which basically considers only limited parameters for
scheduling instances like amount of memory and number of CPU cores requested by
user. Moreover, Litvinski, O. & Gherbi, A (2013) explains that scheduler informs the
compute controller node to deploy instance after checking the user requirements. Im-
portant point here is to note that there are others factors as well which effects scheduling
process except filters.
Whereas, Huanle, Y. et al (2013) proposed a very intelligent solution of creating a
multi-resource pool optimization framework to meet the new requirements. The new
framework replaced the existing policies and divide the new scheduling policy into two
parts: initializing policy and on-going optimizing policy. The initial policy works when
the instance launches. The latter monitors the on-going requirements and helps in
locating the new target host for virtual machine migration if the virtual machine’s
threshold is reached and unbalanced. Although the solution seems good but there has
been no clue of where and how these policies can be defined in OpenStack.
2.4.2 Nova Scheduler
Datt, A. et al (2015) explain the process which runs on nova node to provide the com-
pute services. The Nova Scheduler carry out two staged process Filtering and Weighing
for scheduling an instance on the host.
Figure 2.3 explains the flow of request for creating instance on node. In OpenStack,
13
25. when user submits a request for launching VM requests through Nova- API or dash-
board, the request is either accepted or rejected according to the availability but in case
of acceptance, the decision of placing an instance over node is taken by Nova Scheduler
service using metrics such as available resources (amount of free ram and number of
CPUs on node). This requires both filter and cost function to find a suitable server for
VM. Wuhib, F. et al. (2012) After getting request, scheduler creates the disk image
for VM and call the hypervisor to boot the VM. This call may contain few parameters
like virtual CPU type, number of cores, location to boot hard disk image from and
amount of memory required. Nasim, R. & Kassler, A.J. (2014) explain that Rabit-mq
establishes the communication between nova scheduler and compute controller. After
launching VM, metadata of VM is stored on MySQL.
Datt, A. et al (2015) state that if the Nova Scheduler is unable to launch instances and
cannot find host for scheduling, that implies that there is no suitable host available
fulfilling desired parameters of filters.
Figure 2.3: Flow of Request in Nova Scheduler
Scheduler can be configured through many ways or can be modified in /etc/no-
va/nova.conf file present on compute node. The figure given below show that nova.conf
contains the list of all the default filter in scheduler default filters and all available filters
in scheduler available filters.
14
26. Figure 2.4: nova.conf file
2.4.3 Limitations of Nova Scheduler
Normally, IaaS providers define the rules according to which compute, network and
storage are allocated to customers. Wuhib, F. et al. (2012) put emphasis in altering
the resource allocation process to achieve management objectives. This means that
system should continuously monitor the resource utilization and dynamic resource al-
locations. Sahasrabudhe, S.S & Sonwani, S.S (2014) listed few limitations of scheduler,
nova-scheduler is not capable of load balancing and power management as it can take
decision based on static information about the compute resources. Sahasrabudhe, S.S
& Sonwani, S.S (2014) criticizes nova-scheduler by saying that it do not take current
utilizations of compute resources into account before scheduling.
Therefore, it can be concluded that Nova Scheduler lacks load balancing, dynamic
placement and specific host selection Functionality by user. Thus, the literature iden-
tifies that VM placement decisions and resource allocation as critical research area.
Hence, OpenStack Scheduler needs an improvement and other modifications to enhance
the performance.
2.4.4 Filter Scheduler and its Type
In our research, we mainly study the Filter Scheduler, its working and various types.
Both Redhat Configuration Reference Guide (2015) and OpenStack Configuration Ref-
erence (2015), explain that Filter Scheduler is the default scheduler in OpenStack. It
has numerous number of filters such as Ram Filter, Core Filter etc. It consists of two
staged process called, filtering and weighing which decides the host for VM placement.
The Filter Scheduler only select out those hosts which meets the requirements of the
15
27. all filters mentioned in default configuration.
Filters are present on host node where nova-compute service is running. They are
binary in nature, so either they accept the request for launching VM or they reject it.
Hosts which satisfy the requirements of filters which are further processed by weighting
algorithms to take out the best host.
The figure given below explains how Filter Scheduler can choose the best host.
Figure 2.5: Filter Scheduler in OpenStack
In this figure 2.5, we have 4 available hosts. If there a request for launching instance,
then Filter Scheduler will take out list of hosts which meet filters requirements. In the
next step of weighting, a weighting algorithm runs to find out the best and worst host.
Default filters:
• Retry Filter: host have not been involved in scheduling purpose.
• AvailabilityZoneFilter: requested availability zone is present for launching VM.
• RamFilter: host have enough RAM available.
• ComputeFilter: capable of fulfilling the request
• ComputeCapabilitesFilter: host satisfy the extra specs linked with instance type.
16
28. • ImagePropertiesFilter: satisfy the properties like architecture, hypervisor type and
VM mode
Custom Filters: New filters, for instance MyFilter can be implemented in python and
specified in nova.conf file on compute. Any user can make their own filters according
to the requirement of scheduling process. The picture below shows how we can add
new filters to available filters.
Figure 2.6: Custom filters in nova.conf
17
29. Chapter 3
Design
This chapter provides the design of the infrastructure to perform the experiment. The
analysis of the research problem has been done in literature review. Therefore, this
chapter will describe the design of OpenStack architecture with nova networking, Ser-
vice layout of OpenStack, hardware requirement for configuring private OpenStack
cloud and essential terminologies.
3.1 Minimal OpenStack architecture with legacy net-
working
The architecture of the OpenStack has been depicted in figure 3.1. We will discuss
each and every components of it in detail. The minimal architecture of OpenStack
require two nodes namely Controller and Compute. Therefore, we implement the two-
node architecture with legacy networking which is called nova-network. We configured
Horizon, keystone, Glance, nova and legacy network as per our requirement.
• On the controller node, we configured the keystone (Identity service), Glance (Image
service) and management portion of nova (Compute) and the Horizon (dash-
board). Other significant supporting services such as NTP (network time proto-
col), message queue, and SQL database also run on this node. Optionally, other
services like cinder, swift, Sahara, Trove, Ceilometer and heat could also run on
this node but we do not require these for carrying out this research.
• On the compute node, basically all the components associated with hypervisor runs
which operates the launched virtual machines. By default, KVM is the hypervisor
on compute node. In addition, we can have more than one compute node.
18
30. Figure 3.1: Minimal OpenStack Architecture with Legacy Network
We built this test environment on our virtual machines of VMware workstation. The
main benefit of using this set up is that only one physical server can support multi-
ple virtual nodes with any number of network interfaces. The controller contains one
network interface for management network. The compute node requires two network
interface, one for management network and other for external network. Each node
is connected to each other through management network and interface 2 on compute
node is responsible for providing internet or external network. So, the network on the
compute node requires gateway to access internet through interface 2 for installing pack-
ages, running security updates and DNS. Object storage nodes are optional. Normally,
interface uses eth keyword followed by the sequential network number. Also each node
must resolve the DNS of other node. For example, in our case the controller name is
resolved to 192.168.203.135, IP address of management network on the controller node.
3.2 Service layout legacy network
The figure 3.2 explains the various services configured on each node. We have studied
the purpose of each service in section 2.2.
19
31. Figure 3.2: Service Layout
Network Time Protocol (NTP) is used to synchronize the service timings among node.
SQL database is installed on controller node to store the information and metadata
of services. We will use MySQL as our database. Further, we use RabbitMQ as our
message queue service, configured on the controller node to coordinate operations and
send messages to different services. Identity service is for authenticating users and
control the amount of access given to user according to given role and rights.
3.3 Minimal hardware requirement for legacy networking
This diagram gives a clear picture of hardware required to implement our proposed
solution.
20
32. Figure 3.3: Hardware requirement for implementing OpenStack.
3.4 Key Terminologies
To understand the OpenStack, its essential to understand the following concepts:
1. Service: It includes all OpenStack services like Nova, Glance etc.
2. API Endpoints: It is usually a URL address or network-accessible address of service
to access the service.
3. Role: A user with defined set of rights and permission privileges to perform any
function.
4. KVM: (Kernel based virtual machine) It is a hypervisor supported by OpenStack.
It provides full virtualization solution for Linux Operating system.
5. QEMU: (Quick emulator) is a open source and generic machine emulator.
In the next section, we will implement our OpenStack set up, configure the controller
& compute node and modify the Filter Scheduler.
21
33. Chapter 4
Implementation
This chapter describes the implementation of two nodes architecture of OpenStack with
legacy-network to build a test environment for our experiment. We also changed the
default behavior of filters present in Filter Scheduler.
4.1 Set up
We built our own private OpenStack cloud to carry out this experiment using the
following setting: Our cloud is composed of two node called Controller and Compute.
We assign 2GB of RAM & 1 NIC to controller and 4 GB of RAM & 2 NIC to compute.
Both the nodes have 25GB hard drive. First interface card is for management purpose
and second is for external network. We deployed Ubuntu 12.04 Server LTS on both the
nodes with Linux kernel and KVM as a hypervisor kvm-kmod-3.2. After that, required
services are configured on the nodes through command line. The main motive behind
conducting this experiment is to observe the Filter Scheduler behavior. Further, we
followed the OpenStack Configuration Reference (2015) for configuring
4.2 Basic Environment
(a)Installing operating system:
We deployed Ubuntu 12.04 Server LTS as host OS on both controller and compute
node.
(b) Legacy Networking(nova network)
We configure the network interfaces on both nodes and manually edit the configuration
22
34. files like /etc/hosts.
Controller node has only one NIC configured for management network and compute
node has two network interface, one for management network and one for external
network. Nodes can access internet access through management network (eth0) for
package installation, DNS, NTP and security updates whereas external network pro-
vide internet access to instances on OpenStack environment.
(c)Network time protocol
NTP is installed on both nodes to synchronize the time between the nodes.
(d)OpenStack packages
Required OpenStack packages and repository are downloaded and installed on both the
nodes.
(e)SQL database
We choose MYSQL as our database and installed only on controller node to store all
the data related to services.
(f)Message Queue
We implement RabbitMQ service only on controller node which helps services to coor-
dinate operations & communicate.
4.3 Controller Node Configuration
(a) Keystone (Identity service): Each service and user will be registered in this
service. Steps are as follows:
• Before installing and configuring this service, we create the Keystone database with
root and Keystone user.
• Install the keystone packages, edit the default, database, and memcache, token
and revoke section in /etc/keystone/keystone.conf file and update the keystone
database.
• Configure the apache HTTP server for handling requests and restart the apache2
server.
• Create service entity and API endpoints for the catalog.
• Create admin, service & demo project and create admin user with admin role, demo
user with demo role and add them to the respective projects. Keystone provides
a catalog of services and their locations. Every configured services require service
entity and API endpoints.
23
35. • Create and load the scripts that contains client environment variables for admin
admin-openrc.sh and demo project demo-openrc.sh.
• Verify the Identity service by performing operations through commands.
(b) Glance (Image service): Following step describes the glance configuration. This
registers, stores and retrieve virtual machine images in glance database.
• Create a glance database with glance user with admin privileges in service project.
• Create glance user.
• Add admin role to glance user.
• Create Glance service entity and API endpoints.
• Install glance package python-glanceclient and manually configure the textitGlance-
api.conf & textitglance-registry.conf file. Alter the [Database], [Keystone auth],
[glance store], [Default] and [paste deploy] section in this file.
• Update the glance database and run the service.
• Restart the image service..
• Download image and upload it to the image service.
• Verify the functioning of glance service.
(c) Nova (compute service)
• Create nova database in nova user. Grant all the privileges to the nova user.
• Source admin-openrc.sh file to gain admin access.
• Create nova user and add admin role to it in admin project.
• Create nova service entities and define its API end points.
• Install the nova packages and edit the /etc/nova/nova.conf file. Edit the [database],
[default], [oslo messaging rabbit] and [keystone authtoken].
• Populate the nova database and restart all the nova services.
(d) Legacy networking (nova-network)
• Edit the default section in /etc/nova/nova.conf file to configure the network.
• Restart the nova-api, nova-scheduler and nova-conductor services of compute.
24
36. Horizon (Dashboard)
• Install the dashboard components and configure the /etc/OpenStack -
dashboard/local settings.py file.
• Reload the Apache2 server.
4.4 Compute Node Configuration
(a) Nova
This section describes how nova service is configured on the node. We use QEMU
hypervisor with the KVM extension. Follow the steps mentioned below:
• Install the required nova package and edit the various sections in nova.conf file.
• Restart the textitnova-network and nova-api-metadata of compute service.
• Verify the nova service list, endpoints and image list through command line.
Legacy network:
This deployment of network will provide IP address to the launched instances through
DHCP.
• Edit the /etc/nova/nova.conf and restart the nova services.
After performing all the steps on the specified node, the infrastructure will ready for
experiment. Access the local host dashboard with URL http://controller/horizon and
authenticate using credentials. The picture depicted below shows the dashboard of our
cloud.
25
37. Figure 4.1: OpenStack Dashboard
4.5 Filter Scheduler
In this section, we will work on modifying the filters. OpenStack Configuration Ref-
erence (2015), mention the numerous filters which are available in OpenStack but in
this dissertation, we will work on few filters which we altered or modified. Available
Filters: In nova.conf, the scheduler available filter option will provide the list of all the
filters available on the compute node. The picture given below all the available filters.
26
38. Figure 4.2: List of available Filters
List of Filters which we studied and altered:
1.Core Filter: The scheduler launches only instance on hosts if sufficient amount of CPU
cores are available. Sometimes, it could create problem if the virtual core available on
hosts exceeds the physical number of cores.
Therefore, we configured this filter to avoid vcpu over commitment by changing the
cpu allocation ratio. The default value is 16.0, which means, for instance, if 5vcpus are
on a node A then scheduler permits the instances up to 16*5 = 80 vcpu to run on that
node.
All filters are present in /usr/lib/python2.7/dist-packages/nova/scheduler/filters direc-
tory, so we modified the Core filter.py file as shown below:
27
39. Figure 4.3: Modified Core Filter
2.ImagePropertiesFilter: It passes the hosts which can support the specific image prop-
erties such as architecture, hypervisor type and virtual machine mode in the instances.
As shown below, we specified the hypervisor type in image props filter.py file of the
image that can launch on host.
Figure 4.4: Image Property Filter
3.RamFilter: It only schedules the instance if the host have sufficient RAM available.
It could be possible that host may be over provisioned on the basis of RAM if the
filter is not set, this means the RAM allocated by virtual host may exceed the actual
physical RAM machine. The default value of ram allocation ratio is 1.5, which allows
1.5GB instance to run with at least 1GB free RAM.
28
40. We modify the ram filter.py file and the default values.
Figure 4.5: RAM Filter
4.Retry Filter: This filter removes all host which have already been tried for scheduling
purposes. For instance, if the host chosen by scheduler failed to serve the request, then
this filter will further prevent scheduler to send request to that host.
We modified the utils.py file present in /usr/lib/python2.7/dist-
packages/nova/schedulers directory. We make the scheduler max attempts to 5,
which means scheduler will try five times to launch an instance onto a particular host
before moving on to another.
29
41. Figure 4.6: Modified Retry Filter
5.DiskFilter The scheduler launches instances on those hosts which have sufficient disk
space available. The filter avoids the over commitment of disk as this considers the value
of disk available least property, not the free disk gb. As shown below, the default value
of disk allocation ratio is 1.0 and changed it to 2.0
Figure 4.7: List of available Filters
6.Default Filter Scheduler: In Host manager.py file, it can be seen below that we have
several filters defined in default section.
30
42. Figure 4.8: Default Configuration
To enhance the performance we modified the section where we define the default filters
in Host manager.py file.
Figure 4.9: Modified Configuration
31
43. In the next section, we will benchmark the performance of Openstack.
32
44. Chapter 5
Evaluation
This chapter evaluates the improvement in the OpenStack performance after modifying
the various filters in Nova Filter scheduler. We also compares the performance of default
environment and modified environment. In the end, we benchmarked the performance
by running multiple test case scenarios and derive the conclusion of test cases.
5.1 Rally:
According to Rally (2015), Rally is a basic tool for benchmarking OpenStack. It checks
whether OpenStack is working properly or not and try to continuously improve its SLA
(Service Level Agreement), stability and performance. To achieve this, rally automates
and unifies the multiple node for deployment, verifies cloud, benchmark and generate
reports it. The figure 5.1 below describe the various components of Rally to show how
it works.
33
45. Figure 5.1: How Rally Works
Components of Rally
Deploy Engine: It is simply a pluggable mechanism which helps in unifying and
works with various deployers like DevStack etc.
Verification: It runs tempest to examine the performance of deployed cloud.
Benchmark Engine: It allows the testers to create different workloads on the cloud
by combining multiple tasks scenarios present in benchmark repositories.
Rally Steps:
1. Rally installation
In the first step, we installed the rally packages on new virtual machine by following
command written below:
wget -q -O https://raw.githubusercontent.com/openstack/rally/master/install rally.sh
— bash # or using curl:
curl https://raw.githubusercontent.com/openstack/rally/master/install rally.sh — bash
2. Setting up the environment variables
We provided the Rally with deployment where benchmark will happen and put the
information related to credentials into a JSON configuration file. After that, we
registered the deployment with deployment create command. Figure 5.2 shows how to
register deployment.
34
46. Figure 5.2: Rally Deployment Command
After that, the next figure 5.3 shows how to check whether the current deployment is
working properly and can be used further to benchmark.
Figure 5.3: Deployment Check
3. Run multiple benchmark samples
We are now ready to benchmark, so will run some benchmark task configuration file like
boot.json(either in YAML or JSON format). In our benchmarking we run benchmark
35
47. samples such as boot.json and multiplescenarios.json for different parameters. These
files are available in samples/tasks/scenarios/nova directory. The figure 5.4 below
shows boot.json file.
Figure 5.4: Boot.Json Scenario
The next figure 5.5 shows how to start tasks in Rally. After finishing the task, it will
generate a table which contains response time for different tasks.
Figure 5.5: Task Start
36
48. 4. Generate Html reports In rally, report generation has been considered as one of the
useful mechanism which enable user to create illustrative HTML reports according to
the benchmarking data. We run the command given below to create and open HTML
report showed in figure 5.6 for running task. $ ./bin/rally task report –out=output.html
–open
Figure 5.6: Output.Html Report
5.2 Test Cases
5.2.1 Test Scenario 1: Default Filters
First, the default behavior of Filter Scheduler is analyzed on the OpenStack cloud
with multiple VM running on it. The response time are obtained as below:
Ram allocation ratio= 1.5
Core allocation ratio=16.0
Disk allocation ratio=1.0
schedule max attempts=3
(a) This shows the response time in seconds when we boot 5 VM with default values
of filters.
37
49. action min median 90ile 95ile max avg success count
nova.boot
server
9.898 11.086 14.349 15.178 16.007 11.764 100.0 5
total 9.898 11.086 14.349 15.178 16.007 11.764 100.0 5
Table 5.1: Response Time
(b) This shows the response time in seconds when we boot 7 VM with default values
of filters. The response time increase as the number of VMs increase.
action min median 90ile 95ile max avg success count
nova.boot
server
7.17 12.111 14.373 14.466 14.559 11.69 100.0 7
total 7.171 12.111 14.373 14.466 14.559 11.69 100.0 7
Table 5.2: Response Time
(c) This shows the response time in seconds when we boot and delete 5 VM with default
values of filters.
action min median 90ile 95ile max avg success count
nova.boot
server
6.652 8.831 16.515 18.987 21.46 10.654 100.0 5
nova delete
server
2.313 2.63 4.579 4.588 4.596 3.298 100.0 5
total 8.965 11.83 19.668 21.763 23.857 13.953 100.0 5
Table 5.3: Response Time
(d) This shows the response time in seconds when we create and delete 5 keystone users
with default values of filters.
action min median 90ile 95ile max avg success count
keystone.create
user
0.213 0.243 0.543 0.645 0.747 0.332 100.0 5
keystone.delete
user
0.088 0.107 0.145 0.147 0.148 0.117 100.0 5
total 0.313 0.369 0.655 0.745 0.835 0.449 100.0 5
Table 5.4: Response Time
38
50. 5.2.2 Test Scenario 2: Only Ram Filter Modified
Ram allocation ratio= 2.0
Second, we modified the Ram filter by changing the Ram allocation ratio from 1.5 to
2.0 (a) We record the response time in seconds when we boot 5 VM with modified Ram
filter.
action min median 90ile 95ile max avg success count
nova.boot
server
6.633 12.075 13.21 13.456 13.701 11.164 100.0 5
total 6.633 12.075 13.21 13.456 13.701 11.164 100.0 5
Table 5.5: Response Time
(b) This shows the response time in seconds when we boot 7 VM with modified Ram
filter. Overall timings increase with number of VMs.
action min median 90ile 95ile max avg success count
nova.boot
server
9.508 12.263 14.581 14.949 15.316 12.225 100.0 7
total 9.508 12.263 14.581 14.949 15.316 12.225 100.0 7
Table 5.6: Response Time
(c)This shows the response time in seconds when we boot and delete 5 VM simultane-
ously with modified Ram filter.
action min median 90ile 95ile max avg success count
nova.boot
server
7.121 8.689 10.813 11.336 11.859 9.058 100.0 5
nova delete
server
2.258 4.489 4.646 4.651 4.657 3.713 100.0 5
total 10.636 13.347 14.128 14.26 14.392 12.771 100.0 5
Table 5.7: Response Time
(d) This shows the response time in seconds when we create and delete 5 keystone users
simultaneously with modified Ram filter. We observed that creation time is greater than
deletion time.
39
51. action min median 90ile 95ile max avg success count
keystone.create
user
0.218 0.23 0.851 1.055 1.259 0.434 100.0 5
keystone.delete
user
0.084 0.105 0.137 0.139 0.141 0.113 100.0 5
total 0.331 0.349 0.953 1.148 1.343 0.547 100.0 5
Table 5.8: Response Time
Ram allocation ratio= 3.0 with other default values
(a) This shows the response time in seconds when we boot 5 VM with modified Ram
filter. Compared from above values, it can observed that for 5 instances, booting time
increase as we increase the value.
action min median 90ile 95ile max avg success count
nova.boot
server
9.081 11.922 15.796 16.607 17.418 12.62 100.0 5
total 9.081 11.922 15.796 16.607 17.418 12.62 100.0 5
Table 5.9: Response Time
(b) This shows the response time in seconds when we boot 5 VMs together with mod-
ified Ram filter. However, for 7 instances, booting time decreases as we increase the
ram allocation ratio value to 3.0.
action min median 90ile 95ile max avg success count
nova.boot
server
7.898 12.617 14.484 14.537 14.59 12.096 100.0 7
total 7.898 12.617 14.484 14.537 14.59 12.096 100.0 7
Table 5.10: Response Time
(c) This shows the response time in seconds when we boot and delete 5 VM after
increasing ram allocation ratio value.
(d) This shows the response time in seconds when we create and delete 5 keystone
users after increasing ram allocation ratio value. Compared from above scenario, both
creation and deletion time also increase after changing value.
40
52. action min median 90ile 95ile max avg success count
nova.boot
server
5.543 7.125 9.513 9.556 9.598 7.726 100.0 5
nova delete
server
2.241 2.473 4.633 4.644 4.655 3.313 100.0 5
total 7.969 11.781 11.961 12.016 12.071 11.039 100.0 5
Table 5.11: Response Time
action min median 90ile 95ile max avg success count
keystone.create
user
0.232 0.26 0.726 0.86 0.994 0.412 100.0 5
keystone.delete
user
0.124 0.128 0.209 0.232 0.255 0.154 100.0 5
total 0.356 0.464 0.875 0.999 1.122 0.567 100.0 5
Table 5.12: Response Time
5.2.3 Test Scenario 3: Both Ram Filter and Core Filter modified
In third test, After setting the Ram allocation ratio= 3.0, we changed the Core Filter.
The value of Core allocation ratio has been changed from 16.0 to 1.0 .
Now, Core allocation ratio=1.0
(a) we record the response time when we boot 3 VMs.
action min median 90ile 95ile max avg success count
nova.boot
server
6.893 9.16 9.596 9.651 9.705 8.586 100.0 3
total 6.893 9.16 9.596 9.651 9.705 8.586 100.0 3
Table 5.13: Response Time
(b) We record the response time when we boot 5 VMs.
action min median 90ile 95ile max avg success count
nova.boot
server
7.015 11.919 13.911 14.339 14.766 11.257 100.0 5
total 7.015 11.919 13.911 14.339 14.766 11.257 100.0 5
Table 5.14: Response Time
(c) We record the response time when we boot 7 VMs.
41
53. action min median 90ile 95ile max avg success count
nova.boot
server
9.617 13.079 15.234 15.94 16.646 12.622 100.0 7
total 9.617 13.079 15.234 15.94 16.646 12.622 100.0 7
Table 5.15: Response Time
5.2.4 Test Scenario 4: All Modified Filter
In the last test case, we modified RamFilter.py, CoreFilter.py, DiskFil-
ter.py and utils.py. Ram allocation ratio= 3.0 Core allocation ratio=1.0
Disk allocation ratio=3.0 scheduler max attempts=5
(a) We record the response time when we boot 3 VMs in modified configuration of
OpenStack.
action min median 90ile 95ile max avg success count
nova.boot
server
8.234 9.979 10.746 10.841 10.937 9.717 100.0 3
total 8.234 9.979 10.746 10.841 10.937 9.717 100.0 3
Table 5.16: Response Time
(b) We measured the response time when we boot 5 VMs.
action min median 90ile 95ile max avg success count
nova.boot
server
6.783 12.004 13.793 14.381 14.97 11.035 100.0 5
total 6.784 12.004 13.793 14.381 14.97 11.035 100.0 5
Table 5.17: Response Time
(c) We observed the response time in seconds when we boot 7 VMs.
action min median 90ile 95ile max avg success count
nova.boot
server
7.164 13.126 15.279 15.336 15.394 12.451 100.0 7
total 7.164 13.126 15.279 15.336 15.394 12.451 100.0 7
Table 5.18: Response Time
Thus, it is proved that average response time increase with increase in number of VMs.
42
54. 5.3 Conclusion from Results
We run a task boot.json in rally and record the response time of launching 5 virtual
machine together in the default as well as modified environment. The improved perfor-
mance was shown by the last test scenario which is modified Filter environment. Table
5.19 Comparison between test case 1 and 4 in terms of response time.
Test Case action min 95ile max avg success count
Default Filters Nova.boot
server
9.898 15.178 16.007 11.764 100.0 5
Modified Fil-
ters
Nova.boot
server
6.783 14.381 14.97 11.035 100 5
Table 5.19: Response Time
The above two sets of response times are graphically represented as below Fig 5.7
Figure 5.7: Comparison of performance between default and modified filters where
count=5.
Fig.5.7, represents the response times taken by the task scenario of rally for launching
5 numbers of VMs with the default and modified configuration of filters. As per the
graph, the performance of OpenStack with modified filters increases as compared to
default values. Therefore, instances are scheduled quickly in the latter environment as
43
55. the minimum response time is approximately 3 seconds less. Likewise, the boot.json in
rally has been executed for calculating response time for launching 7 instances together
in both default and modified environment. The response times are recorded below in
Table 5.20:
Table 5.20 Comparison between test case1 and 4 in terms of response time
Test Case action min 95ile max avg success count
Default Filters Nova.boot
server
7.171 14.466 14.559 11.69 100.0 7
Modified Fil-
ters
Nova.boot
server
7.164 14.126 14.232 11.01 100 7
Table 5.20: Response Time
For comparing both the scenario, the Figure 5.8 is described:
Figure 5.8: Comparison in performance between default and modified filters where
count= 7.
In Fig.5.8, It is clear that the performance of OpenStack improves after altering the
filters. However, the difference between the response times in this environments are
not much, but still scheduling affects the performance.
Hence, it can be assured that the OpenStack environment is showing improvements due
44
56. to proposed changes in filters. Although, the maximum number of lunched instance are
restricted to 7 due to resource constraint in our physical set up. Therefore, evaluation
cannot be possible for more number of memory, core and number of instances.
To conclude, after benchmarking and critically analyzing both cases, it can be seen
that there is undoubtedly a certain level of performance enhancement due to proposed
solution.
45
57. Chapter 6
Conclusion
Cloud computing can be perceived as platform which brings all technologies like vir-
tualization, web services and grid computing together to provide on-demand computa-
tional resources as a services to users. Moreover, virtualization enables resource sharing
which causes rapid decrease in hardware cost and simultaneous increase in computing
power. Allocation of shared resources have been an important research area in IaaS
cloud. Thus, we tried to allocate resources to the virtual machines in a flexible way to
maximize the physical resource utilization.
This thesis proposed a solution of modifying the default behavior of Filter Scheduler
in OpenStack environment. In this research, we studied the behavior of various Filters
which are responsible for scheduling in OpenStack cloud. Moreover, we analyzed the
impact on scheduling and allocating process due to various factors like the number of
CPUs, disks and amount of memory allocated to the physical and virtual machines.
Thus, we implement our private cloud and changed the working of Filter Scheduler.
Furthermore, test case scenarios are created and the performance is benchmarked using
a tool called Rally which automatically generates the illustrative Html reports.
In the evaluation chapter, the main outcomes of this thesis suggest that the response
time in scheduling the instances has reduced after changing the default values of disk,
core and ram filter. As observed from the performance graphs that the proposed
solution eliminates the latency in scheduling and enhance the performance by quickly
allocating the suitable host to launch instances.
To conclude, Openstack is an interesting cloud computing research community. It will
be very motivating to research on various VM placement strategies with combination
of different inbuilt and custom filters to resolve the performance issues.
46
58. Bibliography
Analysis of Infrastructure Monitoring Requirements for OpenStack Nova (2015), Pro-
cedia Computer Science 54, 127 136. Eleventh International Conference on Com-
munication Networks, fICCNg 2015, August 21-23, 2015, Bangalore, India Eleventh
International Conference on Data Mining and Warehousing, fICDMWg 2015, August
21-23, 2015, Bangalore, India Eleventh International Conference on Image and Signal
Processing, fICISPg 2015, August 21-23, 2015, Bangalore, India.
Bist, M., Wariya, M. & Agarwal, A. (2013), Comparing delta, open stack and xen cloud
platforms: A survey on open source iaas, in ‘Advance Computing Conference (IACC),
2013 IEEE 3rd Interna- tional’, pp. 96100.
Biswas, P., Patwa, F. & Sandhu, R. (2015), Content level access control for openstack
swift storage, in ‘Proceedings of the 5th ACM Conference on Data and Application
Security and Privacy’, CODASPY ’15, pp. 123126.
Experimental Evaluation of OpenStack Compute Scheduler (2013), Procedia Computer
Science 19, 116 123. The 4th International Conference on Ambient Systems, Networks
and Technologies (ANT 2013), the 3rd International Conference on Sustainable Energy
Information Technology (SEIT- 2013).
Github (2015). [online]. from https://github.com/openstack/nova[Accessed 20 August
2015]
Goiri, I., Juliaa, F., Nou, R., Berral, J., Guitart, J. & Torres, J. (2010), Energy-aware
scheduling in virtualized datacenters, in ‘Cluster Computing (CLUSTER), 2010 IEEE
International Conference on’, pp. 5867.
Huanle, Y., Weifeng, S. & Tingting, B. (2013), An openstack-based resource optimiza-
tion scheduling framework, in ‘Computational Intelligence and Design (ISCID), 2013
Sixth International Sympo- sium on’, Vol. 1, pp. 261264.
47
59. Khan, R., Ylitalo, J. & Ahmed, A. (2011), Openid authentication as a service in open-
stack, in ‘Infor- mation Assurance and Security (IAS), 2011 7th International Confer-
ence on’, pp. 372377.
Litvinski, O. & Gherbi, A. (2013), Openstack scheduler evaluation using design of
experiment approach, in ‘Object/Component/Service-Oriented Real-Time Distributed
Computing (ISORC), 2013 IEEE 16th International Symposium on’, pp. 17.
Mills, K., Filliben, J. & Dabrowski, C. (2011), Comparing vm-placement algorithms
for on-demand clouds, in ‘Cloud Computing Technology and Science (CloudCom), 2011
IEEE Third International Conference on’, pp. 9198.
Nasim, R. & Kassler, A. J. (2014), Deploying openstack: Virtual infrastructure or
dedicated hard- ware, in ‘Proceedings of the 2014 IEEE 38th International Computer
Software and Applications Conference Workshops’, COMPSACW ’14, pp. 8489.
OpenStack Configuration Reference (2015). [online]. Available from
http://docs.openstack.org/kilo/config-reference/content/index.html[Accessed 17
August 2015]
Rosado, T. & Bernardino, J. (2014), An overview of openstack architecture, in ‘Pro-
ceedings of the 18th International Database Engineering & Applications Symposium’,
IDEAS ’14, pp. 366367.
Rally (2015). [online]. Available from https://wiki.openstack.org/wiki/Rally#What is Rally.3F[Acces
20 August 2015]
Redhat Configuration Reference Guide (2015). [on-
line].Availble from https://access.redhat.com/documentation/en-
US/Red Hat Enterprise Linux OpenStack Platform/5/html/Configuration Reference Guide/section c
scheduler.html [Accessed 3 August 2015]
Sahasrabudhe, S. & Sonawani, S. (2014), Comparing openstack and vmware, in ‘Ad-
vances in Electron- ics, Computers and Communications (ICAECC), 2014 International
Conference on’, pp. 14.
Wuhib, F., Stadler, R. & Lindgren, H. (2012), Dynamic resource allocation with man-
agement objectives 2014;implementation for an openstack cloud, in ‘Network and ser-
vice management (cnsm), 2012 8th international conference and 2012 workshop on
systems virtualiztion management (svm)’, pp. 309315.
Xu, J. & Fortes, J. (2010), Multi-objective virtual machine placement in virtualized
data center environ- ments, in ‘Green Computing and Communications (GreenCom),
48
60. 2010 IEEE/ACM Int’l Conference on Int’l Conference on Cyber, Physical and Social
Computing (CPSCom)’, pp. 179188.
Zhang, Y., Krishnan, R. & Sandhu, R. (2014), Secure information and resource sharing
in cloud infrastructure as a service, in ‘Proceedings of the 2014 ACM Workshop on
Information Sharing & Collaborative Security’, WISCS ’14, pp. 8190.
Zhong, H., Tao, K. & Zhang, X. (2010), An approach to optimized resource scheduling
algorithm for open-source cloud systems, in ‘ChinaGrid Conference (ChinaGrid), 2010
Fifth Annual’, pp. 124 129.
49
