INSTITUTO DE COMPUTAÇÃO
Cesar Giovanni Chaves Arroyave
Scheduling Applications with Software Requirements
in Grids and Private Clouds
Escalonamento de Aplicações com Requisitos de
Software em Grades e Nuvens Privadas
CAMPINAS
2016
Scheduling Applications with Software Requirements
in Grids and Private Clouds
Escalonamento de Aplicações com Requisitos de Software em
Grades e Nuvens Privadas
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação.
Thesis presented to the Institute of Computing of the University of Campinas in partial fulfillment of the requirements for the degree of Master in Computer Science.
Supervisor/Orientador: Prof. Dr. Nelson Luis Saldanha da Fonseca Co-supervisor/Coorientador: Prof. Dr. Daniel Macêdo Batista
Este exemplar corresponde à versão final da Dissertação defendida por Cesar Giovanni Chaves Arroyave e orientada pelo Prof. Dr. Nelson Luis Saldanha da Fonseca.
CAMPINAS
2016
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Chaves Arroyave, Cesar Giovanni,
C398s ChaScheduling applications with software requirements in grids and private clouds / Cesar Giovanni Chaves Arroyave. – Campinas, SP : [s.n.], 2016.
ChaOrientador: Nelson Luis Saldanha da Fonseca. ChaCoorientador: Daniel Macêdo Batista.
ChaDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.
Cha1. Computação em nuvem. 2. Computação em grade (Sistemas de computador). 3. Escalonamento de processos. 4. Algoritmos - Programação linear. 5. Máquinas virtuais. I. Fonseca, Nelson Luis Saldanha da,1961-. II. Batista, Daniel Macêdo. III. Universidade Estadual de Campinas. Instituto de Computação. IV. Título.
Informações para Biblioteca Digital
Título em outro idioma: Escalonamento de aplicações com requisitos de software em
grades e nuvens privadas
Palavras-chave em inglês:
Cloud computing
Computational grids (Computer systems) Process scheduling
Algorithms - Linear programming Virtual machines
Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:
Nelson Luis Saldanha da Fonseca [Orientador] Carlos Becker Westphall
Islene Calciolari Garcia
Data de defesa: 22-11-2016
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Cesar Giovanni Chaves Arroyave
Scheduling Applications with Software Requirements
in Grids and Private Clouds
Escalonamento de Aplicações com Requisitos de Software em
Grades e Nuvens Privadas
Banca Examinadora:
• Prof. Dr. Nelson Luis Saldanha da Fonseca Universidade Estadual de Campinas
• Prof. Dr. Carlos Becker Westphall Universidade Federal de Santa Catarina • Profa. Dra. Islene Calciolari Garcia
Universidade Estadual de Campinas
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
A computação em Grade e em Nuvem são dois importantes paradigmas da computação concebidos para lidar com a complexidade da execução de aplicações e com os requisitos exigentes das aplicações emergentes. Além do mais, ambos paradigmas fornecem infraes-truturas de execução compostas por equipamento heterogêneo, distribuído em diferentes pontos geográficos e ligado por enlaces de rede. Enquanto Grades proporcionam infor-mação sobre os recursos físicos disponíveis, Nuvens posicionam o usuário num nível de abstração maior, fornecendo aplicações, plataformas e infraestrutura em forma de serviços sob-demanda.
Em Grades e Nuvens, o tempo de execução de aplicações complexas pode ser reduzido através do bom uso dos recursos heterogêneos, isto é, através da escolha da combinação mais apropriada de recursos de rede e de processamento para a execução da aplicaçao. No entanto, este é um problema do tipo NP-difícil. Adicionalmente, tarefas que com-põem aplicações complexas podem ter demandas específicas de software, incorporando uma variável adicional à complexidade do problema de escalonamento. Além disso, para determinar a combinação mais apropriada de tais recursos, são implementados algoritmos de escalonamento. Assim, tais escalonadores podem ser implementados, visando produ-zir escalonamentos com o menor tempo de execução, mínimo uso de recurso ou menores custos de contratação de serviços, entre outros.
Esta dissertação propõe três novos escalonadores para Grade e Nuven baseados em Programação Linear Inteira que visam produzir escalonamentos com o menor tempo de execução. Tais escalonadores usam máquinas virtuais com o objetivo de preencher os requerimentos de software das tarefas que fazem parte das aplicações complexas. Adi-cionalmente, é proposta uma nova técnica de escalonamento com os mesmos objetivos, para redefinir escalonadores tradicionais que não consideram a instanciação de máquinas virtuais, a fim de que possam escalonar este tipo de aplicações. Resultados experimentais demonstram a eficiência de cada abordagem de escalonamento em diferentes cenários.
Grid and Cloud are important computing paradigms that cope with the complexity of the execution of emerging applications and requirements. Furthermore, both paradigms provide powerful infrastructure composed of heterogeneous equipment, which are located in different geographical points with fast network links connecting them. However, while Grids supply information regarding the available physical resources, Clouds place users in a higher level of abstraction, providing applications, platforms, and infrastructure as on-demand web services.
Even though, in grids and clouds, the execution time of complex applications can be reduced by using the powerful heterogeneous resources, choosing the most appropriate combination of processing and network resources to achieve it is an NP-Hard problem. Furthermore, tasks within complex applications may have specific software demands, in-corporating an additional variable to the complexity of the scheduling problem. Imple-mentations of scheduling algorithms, are used in order to determine appropriate combina-tions of such resources. These schedulers can be implemented with the aim of producing schedules with the lowest execution time, resources usage, and monetary cost, among others.
This dissertation proposes three new Grid/Cloud schedulers based on Integer Linear Programming that aim to produce schedules with the lowest execution time. Such sched-ulers use Virtual Machines with the objective of fulfilling the software requirements of the tasks that compose complex applications. An additional scheduling technique with the same purposes is also proposed, which enhances existing schedulers that do not consider Virtual Machines so that they can also be able to schedule this type of complex applica-tions. Experimental results showed the efficiency of each scheduling approach in diverse scenarios.
La Computación Grid y en Nube son dos importantes paradigmas con los cuales es posible hacerle frente a la compleja ejecución de aplicaciones emergentes y a sus requerimientos. Además, ambos paradigmas proporcionan una poderosa infraestructura heterogénea situa-da en diferentes puntos geográficos con enlaces de alta velocisitua-dad. Por otro lado, mientras las Grids proporcionan información sobre los recursos físicos disponibles, las Nubes situan al usuario en un nivel de abstracción más alto, proporcionando aplicaciones, plataformas e infraestructuras en forma de servicios web sobre demanda.
Aunque en Grids y Nubes el tiempo de ejecución de aplicaciones complejas puede ser reducido a través del uso de los recursos heterogéneos, el proceso de seleccionar la combinación más apropiada de recursos de procesamiento y de red es un problema NP-difícil. Por otro lado, las tareas que componen las aplicaciones complejas pueden tener demandas específicas de software, incluyendo una variable adicional a la complejidad del problema de planificación. También, para determinar la combinación mas apropiada de tales recursos, son implementados algoritmos de planificación con el objetivo de obtener el mínimo tiempo de ejecución así como la optimización del uso de los recursos e disminución de los costos de contratación de servicios, entre otros.
Esta tesis de maestría propone tres nuevos planificadores para Grid /Nube basados en programación lineal cuyo objetivo es producir planificaciones con el mínimo tiempo de ejecución. Estos algoritmos usan máquinas virtuales con el objetivo de suplir los requeri-mientos de software de las tareas que componen las aplicaciones complejas. También es propuesta una técnica adicional de planificación con el mismo propósito, la cual mejora los planificadores existentes que no consideran máquinas virtuales, de modo que les per-mita planificar este tipo de aplicaciones complejas. Resultados experimentales muestran la eficiencia de las propuestas de planificación en diversos escenarios.
2.1 Cloud computing architecture [54] . . . 18
2.2 Embarrassingly parallel application DAG with 8 tasks in level 2 . . . 21
2.3 Montage application DAG with 4 tasks in level 2 . . . 22
2.4 Montage application DAG with 10 tasks in level 2 . . . 22
2.5 Wien2k application DAG with 7 tasks in level 2 . . . 23
3.1 Cloud Infrastructure . . . 26
3.2 Embarrassingly parallel application DAG with 2 tasks in level 2 . . . 33
3.3 Illustrative example - infrastructure . . . 34
3.6 Embarrassingly parallel application DAG used for experiments . . . 38
3.7 Makespan vs number of hosts . . . 40
3.8 Makespan vs probability β . . . 40
3.4 Illustrative example - serial execution . . . 42
3.5 Illustrative example - optimum schedule . . . 43
3.9 Makespan vs probability α . . . 44
4.1 Montage application DAG used for experiments . . . 50
4.2 Wien2k application DAG used for experiments . . . 51
4.3 Makespans for the Montage DAG. . . 52
4.4 Execution time for the Montage DAG. . . 53
4.5 Makespans for the Wien2k DAG. . . 53
4.6 Execution time for the Wien2k DAG. . . 54
5.1 Example of a simple application DAG with software demanding tasks . . . 56
5.2 Possible DAG modifications . . . 56
5.3 CDF of possible makespans for the modified DAGs of the Montage DAG. . 57
5.4 Montero’s Method - DAG modification example . . . 58
5.5 Aggregate Method - DAG modification example . . . 59
5.6 SPA Method - DAG modification example 1 . . . 59
5.7 SPA Method - DAG modification example 2 . . . 60
5.8 Makespans for the RP case – Cloud network with 300 hosts. . . 62
5.9 Makespans for the RP case – Cloud network with 400 hosts. . . 63
5.10 Makespans for the BU-RL case – Cloud network with 300 hosts. . . 64
3.1 Number of equations per constraint . . . 33 3.2 Illustrative example - Number of equations per constraint . . . 34 5.1 Set partitions . . . 56
1 Introduction 13
1.1 Contributions . . . 14
1.2 Publications . . . 15
1.3 Organization of the dissertation . . . 16
2 Fundamental concepts 17 2.1 Grid computing . . . 17 2.2 Cloud computing . . . 17 2.2.1 Cloud Architecture . . . 18 2.2.2 Business Models . . . 19 2.2.3 Deployment Models . . . 19
2.3 Network topology generation methods . . . 19
2.3.1 The Doar-Leslie method . . . 20
2.3.2 The Barabási-Albert method . . . 20
2.3.3 The Barabási-Albert 2 method . . . 20
2.4 Tasks, Workflows, and Directed Acyclic Graphs . . . 21
2.5 Scheduling . . . 23
2.6 Virtualization . . . 23
2.6.1 Virtual machines . . . 24
3 TVM schedulers 25 3.1 Related work . . . 26
3.1.1 On-demand Virtual Execution Environments . . . 26
3.1.2 Bicriteria Service Scheduling . . . 27
3.1.3 Virtual Machine Grid . . . 27
3.1.4 Virtual Machine Sandboxes . . . 28
3.1.5 Job-Aware Workspace Service . . . 28
3.2 Integer linear program formulation . . . 28
3.3 Illustrative example . . . 33
3.4 TVM-INT . . . 35
3.5 TVM-RR . . . 37
3.6 Experiments . . . 38
3.6.1 Variation of the number of hosts in the grid/private cloud . . . 39
3.6.2 Variation of the probability value of paths between hosts . . . 39
4.2 The TVM-FUZZY scheduler . . . 46
4.3 Experiments . . . 49
4.3.1 Network uncertainties affecting the Montage application . . . 52
4.3.2 Network uncertainties affecting the Wien2k application . . . 53
5 The Same Path Aggregation method 55 5.1 Montero’s Method . . . 57
5.2 Aggregate Method . . . 58
5.3 Same Path Aggregation Method . . . 59
5.4 Experiments . . . 60
6 Conclusion and Future Work 66 6.1 Conclusion . . . 66
6.2 Future Work . . . 67
Bibliography 68 A Illustrative example files 73 A.1 Application . . . 73
A.2 Grid/Private Cloud . . . 74
A.3 Virtual machines repository . . . 74
Introduction
The world contains a huge amount of digital data that is permanently increasing. This data can help to spot business trends, prevent diseases, combat crime, provide fresh insights into science and so on [32]. Since the analysis of a big amount of data is a cumbersome process, it is usually divided into smaller tasks, usually with data dependency, and represented as a workflow [46].
Moreover, the continuous evolution of technology brings computers with greater pro-cessing power, memory and storage capacity, which would imply the execution of workflow-type applications on a single computer. However, the bandwidth of network links grows as well, enabling the creation of more powerful processing platforms able to process in parallel many tasks, thus making distributed executions a more attractive choice.
Distributed computing paradigms have also been evolving in order to provide better solutions. Starting with “Clusters", which are sets of homogeneous computers working together on a single geographical site. Followed by “Grids", that allowed the use of heterogeneous computers on different geographical sites, grouped as Virtual Organizations (VO) [26]. Leading to “Clouds", which refer to remote, virtual, flexible, and robust environments that supply software, platforms, and infrastructure as services based on Service Level Agreements (SLA) [16, 28].
In order to leverage the resources provided by distributed computing, specially in Grids and Clouds, a task scheduler is essential. A task scheduler orchestrates the execution of tasks, that compose an application, by specifying the time at which each of these tasks will be executed and the resources that will be required.
With the development of Grid and Cloud Computing, the initial application require-ments (i.e. processing power and network bandwidth) have been extended. Presently, each task may require a software library, operating system, version of other software and even a specific hardware for its execution. One way to meet these requirements is via virtualization [24, 42], thus increasing the complexity of the task scheduler, which now has to consider the instantiation of Virtual Machines (VMs) in their schedules.
Cloud computing can be classified into four different types: Private, Public, Hybrid and Virtual Private Clouds [54]. Private clouds are used by a single organization and can be managed by the same organization. Public clouds are those in which resources are available for the general public and may incur on a certain fee. Hybrid clouds combine these two, allowing organizations that use private clouds to occasional increment their
available resources. Finally, Virtual Private clouds run on the top of Public clouds, however, the network that links resources is also virtualized, by using Virtual Private Network (VPN) technology.
This dissertation introduces three task schedulers able to leverage resources of Grids and Private Clouds for distributed applications with software requirements. Additionally, a scheduling technique for meeting software requirements with traditional task schedulers is also detailed. All of these approaches map virtual machines onto shared hosts and tasks onto those virtual machines. Moreover, these approaches aim to minimize the execution time of applications, also known as makespan.
The first two task schedulers are based on the same integer linear programming formu-lation. The first scheduler implements the exact integer programming problem in order to generate schedules with the lowest makespan values. The second scheduler implements a relaxed version of the same problem and produces optimal schedules. Even though the first scheduler provides schedules with lower makespans than the second, it takes more time to produce them, trade off that is worth considering depending on the application that will be executed.
The quality of a produced schedule is bound to the accuracy of the information pro-vided by the tools used for monitoring the bandwidth of the grid/private cloud. However, when working in infrastructures with shared resources, the estimated bandwidth of the network can be affected by concurrent application executions done by other users. The third scheduler employs Fuzzy optimization techniques that make the scheduler robust under uncertain network bandwidth variations.
Moreover, the proposed scheduling technique enables schedulers that do not consider software requirements to meet software demand of applications with minor modifications. Simulations were executed in order to evaluate the performance of the schedulers in terms of the generated schedules and the time required to generate them. Different ap-plications and grid/private cloud infrastructures were considered in the simulations. The first two schedulers were tested varying the amount of hosts available in the network, the connection probability between those hosts, and the bandwidth of those connections. Re-sults showed that both schedulers provided schedules with shorter makespans than a serial execution, nonetheless, the first scheduler achieved the shortest schedules, but took longer to produce them than the second. The third and first schedulers were compared schedul-ing two common applications in an environment with network bandwidth uncertainties, where the third scheduler presented to be more robust. Moreover, the additional proposed scheduling technique was compared to two others considering two software requirement distributions in a common image processing application. The proposed technique was proven to be better or equal than the best of the two others for each of the distributions.
1.1
Contributions
The contributions of this dissertation are listed below:
• An Integer Linear Program for scheduling workflows that considers the instantiation of virtual machines for meeting software requirements of applications.
• An heuristic for obtaining integer solutions of the relaxed version of the Linear Integer Program.
• An Integer Linear Program for scheduling applications with software requirements under uncertain available bandwidth.
• A technique for scheduling applications with software requirements using traditional task schedulers.
• A performance evaluation of the proposed schedulers, based on the results obtained from simulations.
1.2
Publications
Results produced in this dissertation were published in the following papers:
Daniel M. Batista, Cesar G. Chaves, and Nelson L. S. da Fonseca. Scheduling virtual machines and grid tasks on clouds. In First Workshop on Network Virtualization and Intelligence for Future Internet (WNetVirt’10). Buzios, Brazil Apr. 2010.
Cesar G. Chaves, D. M. Batista, Nelson L. S. da Fonseca. Scheduling Grid Applica-tions on Clouds. In: IEEE Global TelecommunicaApplica-tions Conference (GLOBECOM) 2010, December 2010, Miami, USA. Proceedings of the IEEE Global Telecommunications Con-ference (GLOBECOM) 2010. New York : IEEE, 2010. p. 1–5. Digital Object Identifier: 10.1109/GLOCOM.2010.5683969
Cesar G. Chaves, D. M. Batista, Nelson L. S. da Fonseca. Scheduling Grid Appli-cations with Software Requirements. In: IEEE Latin America Conference on Commu-nications (LATINCOM), September 2010, Bogota, Colombia. Proceedings of the IEEE Latin America Conference on Communications. New York : IEEE, 2010. p. 1–6. Digital Object Identifier: 10.1109/LATINCOM.2010.5641116
D. M. Batista, Cesar G. Chaves, Nelson L. S. da Fonseca. Embedding Software Re-quirements in Grid Scheduling. In: IEEE International Conference on Communications (IEEE ICC), June 2011, Kyoto, Japan. Proceedings of the IEEE International Confer-ence on Communications. New York: IEEE, 2011. p.1–6. Digital Object Identifier: 10.1109/icc.2011.5962664
Cesar G. Chaves, D.M. Batista, and Nelson L.S. da Fonseca. Scheduling grid appli-cations with software requirements. Latin America Transactions, IEEE (Revista IEEE America Latina), Volume: 9, Issue: 4, p.578–585, July, 2011. Digital Object Identifier: 10.1109/TLA.2011.5993746
Cesar G. Chaves, D. M. Batista, Nelson L. S. da Fonseca. Scheduling Cloud Appli-cations Under Uncertain Available Bandwidth. In: IEEE International Conference on Communications (IEEE ICC), June 2013, Budapest, Hungary. Proceedings of the IEEE International Conference on Communications. New York: IEEE, 2013. p.3781–3786. Digital Object Identifier: 10.1109/ICC.2013.6655144
1.3
Organization of the dissertation
This dissertation presents task schedulers and a scheduling technique, which leverage shared resources of grids and private clouds to seek for a short execution time of distributed applications with software requirements. For such end, the remaining of this document is divided as follows: Chapter 2 provides basic concepts needed for a better understanding of the content of this dissertation. Chapter 3 presents two schedulers based on integer linear programming, one implements the exact integer linear problem and the other one a relaxed version of the problem. Chapter 4 presents a scheduler, which implements a modified version of the integer linear problem used by the previous schedulers, but in this case, applying fuzzy logic to consider network bandwidth estimation uncertainties. Chapter 5 presents a technique for scheduling applications with traditional grid schedulers, although, meeting the software requirements of applications. Finally, Chapter 6 concludes the dissertation.
Fundamental concepts
This chapter contains basic concepts and definitions required for a better understanding of the problems addressed in this dissertation. Section 2.1 contains a definition of Grid Computing. Section 2.2 details concepts regarding Cloud Computing. Section 2.3 presents some algorithms used for generating network topologies, which are useful for simulation purposes. Section 2.4 defines what the term “task" means in the context of scheduling, additionally, it defines what a “workflow" is and how it is represented. Section 2.6 refers to virtualization and virtual machines. Section 2.5 explains what scheduling is and presents the HEFT scheduler.
2.1
Grid computing
Since the mid-1990s, the term Grid has been used for referring to a distributed computing environment that allows the sharing of heterogeneous resources, located all over the world. Such sharing allows the deployment of large-scale and resource-intensive applications, and includes direct access to computers, software, and data. However, since it involves several organizations, it must have clearly and carefully defined policies regarding what it is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules is called a Virtual Organization (VO) [27]. Moreover, such shared resources enabled the development of areas such as physics, chemistry, and astronomy [5] [2] [51] [30], enabling the creation of “e-Science", where large scale simulations and data analytics is done for scientific discovery [3].
2.2
Cloud computing
Cloud computing is an evolving paradigm where hardware and software are provided as multi-purpose services to users among the Internet. Thanks to a virtualization layer, build over physical resources, it is possible to optimize the use of the physical infrastructure, as well as, to (virtually) offer different types of hardware and software to cloud users. However, it has led research groups to different perceptions of what it really is [48]. Among different perceptions, one can even find those which claim that cloud computing
is not something new, just an old model with a different presentation [49]. Consequently, in order to establish a baseline for discussion, the National Institute of Standards and Technology of the United States (NIST) defined cloud computing as:
“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, stor-age, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction." [34]
Furthermore, this cloud model is composed of four layers, provided as any combination between three business models, and can be classified according to the used deployment model [54]. This is detailed in the following subsections.
2.2.1
Cloud Architecture
Fig. 2.1 depicts the four layers in which the architecture of a cloud is divided. It also lists available application examples for each layer.
Figure 2.1: Cloud computing architecture [54]
• The hardware layer: This is the lowest layer of the cloud architecture, usually implemented in data centers, where all the physical resources are located. Such resources include physical servers, routers, and switches, as well as power and cooling systems.
• The infrastructure layer: This is the layer where virtualization takes place. Physical resources are partitioned, enabling dynamic resource assignments, delivered according to user requirements.
• The platforms layer: This layer provides web development tools, including pro-gramming language compilers along with execution and testing environments. • The application layer: Involves a variety of web applications that users can
2.2.2
Business Models
According to the provided service type, cloud computing is divided into three business models, such models are presented next:
• Software as a Service (SaaS): Access is granted only to the application layer, thus a user has restricted control, which may include configuration of the look and feel of applications.
• Platform as a Service (PaaS): Provides services for the development, testing and execution of applications. Even though this model supplies more features than SaaS, the underlying virtual resources are still not directly controlled, nonetheless, they can be accessed through Application Programming Interfaces (APIs).
• Infrastructure as a Service (IaaS): This is the furthest down in the cloud archi-tecture that a user can get. Users have total control over the virtual environment, such as the permission of upsizing or downsizing of virtual machines, as well as of installing and configure any desired operation system. However, a user can not control to which physical resources his/her virtual environment is mapped.
2.2.3
Deployment Models
Many users seek cloud computing in order to reduce costs, however, not all of them can neglect reliability and security requirements. In order to satisfy the different requirements of users, four types of cloud deployment models where created. Such models are explained next:
• Private cloud: Are implemented for the use of a single company, therefore, it offers the highest security, reliability and control among the other deployment models. However, infrastructure and maintenance costs have to be assumed by the company, thus, this model is often criticized for its similarity with computer grids.
• Community cloud: In this type of cloud, companies with equal interests share their resources with each other.
• Public cloud: Services are provided to the general public, and can be delivered either free of cost or in a pay-per-use manner. Furthermore, resources are highly scalable and the user does not need to worry about maintenance cost of the resources. • Hybrid cloud: Its a combination of the Private and Public models, which provides
the easy and temporary escalation that a private cloud cannot.
2.3
Network topology generation methods
The network topology generation methods correspond to mathematical approaches which receive a set of parameters for generating topologies that represent a network such as grids and clouds, usually expressed as graphs.
The type of parameters of a network generator can be divided into two different groups, i.e. the network parameters and the model parameters. The network parameters are related to the structure of the topology that will be created, such as the amount of nodes, link bandwidth, and link assignments, among others. The parameters of the model correspond to the input of the mathematical formulation, and can vary according to each method. Moreover, the model parameters affect the network parameters. In a network representation, the nodes of a graph represent computers, routers or any network equipment, while edges represent network links between them.
2.3.1
The Doar-Leslie method
The Doar-Leslie method [18] generates network topologies similar to those formed by resources on the Internet. The Doar-Leslie method receives three input parameters: m, the amount of computers in the network, β, the network connectivity (network degree) of the computers, and α, the relation between the amount of links with greatest availability and the amount of links with smallest availability. As the value of β gets close to 1, the probability of generating a complete graph increases. As the value of α gets close to 1, the probability that the mean and the median values of the available bandwidths be the same increases.
2.3.2
The Barabási-Albert method
The The Barabási-Albert network generation model was one of the first to be based on power laws. In this model, values such as the connection degree of a device vary as a power of one of the input parameters.
The Barabasi-Albert method [6] is well known and widely used since the Internet shows a power law behavior on the network node degree. This method has two main characteristics: the gradual growth of the network and the tendency of a node to be linked to popular nodes (i.e. the ones with higher degree).
When a node i is incorporated to the network, the probability of linking it to a node j (already in the topology) is given by the relation of the degree of j and the addition of the degrees of all the nodes contained in the network topology, as expressed by:
P (u, v) = P dj k∈V dk
(2.1)
2.3.3
The Barabási-Albert 2 method
The method presented in subsection 2.3.2 describes the general behavior of the Internet, however, it is too general, and therefore, it has been used as reference to other meth-ods that include some modifications or specifications to achieve behaviors that represent more closely that of the Internet. The Barabasi-Albert2 model was incorporated to the Brite topology generator software [33], and it considers local events such as network link exchange when adding a new node.
2.4
Tasks, Workflows, and Directed Acyclic Graphs
Applications executed in grids/clouds are usually complex. Therefore, in order to simplify their executions, applications are broken down into tasks. This tasks are a group of instructions that, when executed, lead to an intermediate result. Moreover, some of the tasks of an application require, for their execution, the results obtained by one ore more of the executions of other tasks, such tasks are called dependant tasks. Furthermore, the group of all the tasks within an application and their dependencies are referred as a workflow.
Knowing that a graph is basically a diagram that contains points called vertices linked by lines called edges, vertices represent elements and the edges a relation between them; A Directed Acyclic Graph (DAG) or strict digraph is a specific type of graph that does not only represent elements and their relations, but also the orientation of each edge, referred as arc. Additionally, there is no path that starts in a vertex and that after following a sequence of arcs, loops back to the same vertex [15].
Consequently, DAGs are useful for representing application workflows, in which the labeled vertices symbolize tasks and arcs the dependencies between them. Moreover, the orientation of the arcs indicates data dependencies between tasks, i. e., a task execution cannot begin until all its preceding tasks have finished and the resulting data is available for processing. Tasks can be classified on those that can be executed in parallel and those that need to be executed serially. The application DAGs used in this dissertation are presented next.
The Embarrassingly Parallel is the simplest distributable application found in litera-ture, it contains only one level of processing tasks that have no data dependencies between them [25]. Figure 2.2 illustrates this type of application with 8 tasks in the second level of the graph and 10 tasks in total. It has 16 arcs representing data dependencies among these tasks.
0
1 2 3 4 5 6 7 8
9
Figure 2.2: Embarrassingly parallel application DAG with 8 tasks in level 2 The Montage application was created by NASA to process various input images and stitch them together to make a mosaic of the sky [30]. Figures 2.3 and 2.4 illustrate two DAGs of the Montage application.
The DAG in Figure 2.3 contains 4 tasks in the second level and 26 tasks in total. Moreover, it has 39 task dependencies. On the other hand, the DAG in Figure 2.4 presents 10 tasks on its second level and 62 in total. Additionally, it has 99 task dependencies.
0 1 2 3 4 5 8 21 6 9 22 7 10 23 11 24 12 15 25 13 16 14 17 18 19 20
Figure 2.3: Montage application DAG with 4 tasks in level 2
0 1 2 3 4 5 6 7 8 9 10 11 20 51 12 21 52 13 22 53 14 23 54 15 24 55 16 25 56 17 26 57 18 27 58 19 28 59 29 60 30 39 61 31 40 41 32 33 42 34 43 44 35 45 36 37 46 38 47 48 49 50
Figure 2.4: Montage application DAG with 10 tasks in level 2
The Wien2k application was developed at the Vienna University of Technology for image processing in quantum chemistry [51]. Figure 2.5 illustrates the DAG of a Wien2k application with 7 tasks on the second level and 25 in total. It has 42 task dependencies.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Figure 2.5: Wien2k application DAG with 7 tasks in level 2
2.5
Scheduling
According to Pinedo in [36], Scheduling is a decision-making process that deals with the allocation of resources to tasks over a given time period. Moreover, scheduling algorithms are used in diverse scenarios, where their optimization goal varies, since resources and tasks refer to different things according to the scenario. Some scenario examples are: 1) an airport, where take-off and landing tasks must be scheduled to runways, in order to reduce waiting periods; 2) Teaching activities that must be assigned to teachers and classrooms to reduce gaps in teacher schedules and avoid them in students schedules; 3) Package deliveries assigned to mailmen, in order to reduce delivery delays and costs; 4) Workflow tasks mapped to computers in a network to reduce execution time, power consumption, or usage fees.
The Heterogeneous Earliest-Finish-Time (HEFT) scheduler [47] is a classical scheduler largely used to evaluate the performance of new grid scheduling approaches [55] [8]. It schedules tasks considering the criterion of the longest path leading to the final task in the DAG. The HEFT scheduler is used in Chapter 5 as a baseline for comparison, given its wide use in the literature.
2.6
Virtualization
Virtualization refers to a software layer abstraction of physical characteristics of hardware, providing virtual resources for high-level applications. The term virtualization is usually
used with relation to computer resources, but it may also make reference to network devices or links.
2.6.1
Virtual machines
Virtual Machines (VMs) are software elements that replicate the necessary environment required to run an operating system. Since the resources of a VM are much smaller than the ones from the physical computer hosting it, different applications that demand different hardware can be executed on the same physical machine. Moreover, once VMs are encapsulated and easy to instantiate systems that do not modify host resources, they can be used for executing untrusted-trusted applications, these environments are called sandboxes [45].
The use of VMs within grids and clouds makes efficient the provisioning of the required resources regardless the real physical resources. Furthermore, in case of a resource outage, job migration along with its execution context can be a straightforward procedure [45].
TVM schedulers
This chapter introduces the Task and Virtual Machine (TVM) schedulers, which schedule VMs in grid/private cloud resources and tasks on those VMs. By scheduling both, it is possible to define virtual computing systems that go beyond the limitations of existing hardware. Despite the existence of other approaches with VM support (Section 3.1), none of them schedule tasks and VMs dynamically, thing that the TVM schedulers do. More-over, the TVM schedulers consider the impact of the network bandwidth when generating a schedule, such consideration is not made by most of the other approaches.
The TVM schedulers are based on an integer linear programming (ILP) formulation. Two schedulers are presented in this chapter, the TVM-INT scheduler, which implements the exact integer programming problem; and the TVM-RR scheduler, that implements a relaxed version of the same problem. The former tends to generate the lowest makespan schedule, while the later to yield an optimal makespan, considering the required execution time to derive the schedule. These two characteristics should be taken into consideration given the heterogeneity of application requirements and grid/private cloud users. Users who can wait to have lower makespan schedules can use the TVM-INT scheduler, while users who need a quick return can use the TVM-RR scheduler. It is important to note that although the makespans of the schedules obtained with the TVM-RR scheduler are higher than those obtained with the TVM-INT, the gain in execution time compensates this drawback.
The proposed schedulers are intended to be executed in a scenario in which clients use a middleware to submit applications to a private cloud, as illustrated in Figure 3.1 (a common scenario in clouds). One of the TVM schedulers, then, maps tasks of this application to available hosts, scheduling also the instantiation of VMs, from the VMs repository (VMR), so that the application can be executed in the required environment and results sent back to the user.
The efficacy of the schedulers was evaluated by simulation, considering diverse net-work scenarios. Results showed that both schedulers are able to produce schedules that efficiently use the available infrastructure and produce schedules within short periods. As expected, the makespans of the schedules produced by the TVM-INT scheduler are lower than those produced by the TVM-RR scheduler, while the execution time of the former is higher than that of the latter.
This chapter is organized as follows, Section 3.1 summarizes some scheduling ap-25
Hosts TVM Scheduler User Virtual Machine Repository Application
Figure 3.1: Cloud Infrastructure
proaches found in the literature. Section 3.2 presents the formulation of the two TVM schedulers. Sections 3.4 and 3.5 present the TVM-INT and the TVM-RR, respectively. Section 3.6 explains the details of the experiments conducted in order to evaluate the performance of the proposed schedulers, as well as the numeric results obtained from the experiments.
3.1
Related work
It can be found in literature different approaches for scheduling tasks with software re-quirements and Virtual Machines (VMs), in grids as well as in clouds. The approaches presented in [45] [12] [53] [52] [29] are summarized in this section.
3.1.1
On-demand Virtual Execution Environments
The Nova grid architecture [45] is designed to address 4 main issues found when working with virtual machines in grid environments; i) to reduce the time required to get a working virtual machine (VM), ii) to ensure that the virtual machine allocated to the grid job has the necessary hardware and software resources, to perform the job, iii) to perform effective clean-up of the virtual machine once the job is complete, and iv) to ensure that the effect of a complete job does not spill over to another future job.
This approach addresses such issues by creating virtual machines in advance, thus avoiding a negative impact on the execution time of the applications. These virtual ma-chines, called "Tiny MVs", consume little resource from their host, due to configurations with 32MB of RAM, 5% of the available CPU and a basic mount partition.
Nova is composed by two agents, the p-agent that runs on the physical machine hosting the VMs and the g-agent that runs on the grid middleware. The p-agent creates the tiny VMs and announces to the g-agent the number of VMs available and its capabilities. Further on, the g-agent will schedule tasks to run in these VMs. The p-agent balloons1 the Tiny VM and indicates readiness for job execution. As soon as the job execution finishes and results have been sent, the p-agent tears down the VM, freeing resources and cleaning any future unnecessary information.
Although the use of pre-created VMs proposed by the Nova architecture reduces the time taken to have a VM ready to execute a job, and the amount of data transferred over the network, it consumes resources even when there is no demand. If a grid with a large availability of VMs were to be implemented, either every VM should be created on every host of the grid, or the use of a VMs with a specific software would be restricted to a specific set of hosts. Other architectures that use VM repositories such as the schedulers presented in this chapter, do not have these requirements, allowing the instantiation of any necessary VM on any host of the grid. This makes possible the execution of applications without the mandatory existence of idle VMs.
3.1.2
Bicriteria Service Scheduling
The Bicriteria Service Scheduling [12] proposes a grid scheduler for distributed application workflows. This scheduler considers that each of the task compounding the application requires a specific service to be executed, and that some computers on the grid may provide services that others do not, restricting task execution to specific hosts. To avoid the restriction of using only a subset of the hosts in the network, dynamic instantiation of services is suggested. Even though, instantiating many services may reduce the makespan, it could lead to expensive workflow executions and resources wastefulness. Therefore, it is considered a trade-off between the makespan of the generated schedule and the amount of services dynamically instantiated.
This scheduler creates new services, only when not creating them would delay the workflow execution. In other words, tasks in the critical path are scheduled on the best available resource at that time, and if the service needed does not exist, this service is then created. A task is in the critical path if its execution time directly affects the overall makespan. All the other tasks, are scheduled in an as late as possible (ALAP) manner.
The Bicriteria Service Scheduling is effective in many situations, although, the instan-tiation of services is not useful when a task execution of a workflow requires a software which in turn demands a specific operating system or kernel version. Such demands can be met with the instantiation of VMs.
3.1.3
Virtual Machine Grid
The Virtual Machine Grid (VMGrid) [53] is a grid middleware designed to allow users to create customized execution environments by specifying resource requirements and
software configuration. Such environments can be deployed in a grid, and controlled by starting, stopping or rebooting Virtual Machines (VMs).
VMGrid is composed by four layers: application layer, middleware layer, virtual layer, and physical resources layer. The application layer provides the VMGrid portal, which shows the configuration of each of the virtual machines in the grid and allows users to share their own computer by using a Virtual Machine Monitor (VMM), besides enabling them to construct virtual workspaces choosing VMs with different operating systems. The middleware layer is in charge of interpreting user demands so that the virtual layer can support them. The virtual layer is used to allocate and use resources. It includes virtual machines and operating systems running on the grid nodes. The physical resources layer contains the hosts shared in the grid, which have a VMM installed, and that will nest the VMs. All the services provided by VMGrid are implemented based on Secure Shell Host protocol (SSH).
Although VMGrid allows users to create customized execution environments, it nei-ther schedules tasks nor it considers the available bandwidth of network paths when transferring VM images to the hosts in the grid as the TVM schedulers do.
3.1.4
Virtual Machine Sandboxes
In [52], it is presented an architecture for designing VM sandboxes, showing that the use of VMs facilitates the development, deployment and management of distributed systems. Although the architecture in [52] enforces the use of VMs to execute tasks on required software, it does not specify how VMs and tasks are scheduled. In our approach, the sched-ulers are in charge of instantiating not only tasks, but also VMs on the appropriate hosts accordingly to task requirements and resources availability, maintaining transparency to the users.
3.1.5
Job-Aware Workspace Service
In [29], it is presented a batch computing service named JAWS (Job-Aware Workspace Service), which separates control over resource sharing from job execution and manage-ment, and delegates control over the workspace to the user. Even though JAWS manages job executions, it is not a job scheduler. In our approach, both schedulers take care of deciding how the workspace is to be build. In this way, a user will submit his/her application description and wait for the result.
3.2
Integer linear program formulation
The TVM schedulers are based on an ILP formulation which aims to minimize the makespan of an application composed by several tasks that may have data dependence among themselves, i.e. one task needs to finish transferring data in order for another one to start. The schedulers also consider that the tasks composing these applications have software requirements, which yields to the need of the instantiation of virtual machines on computational resources before tasks can be executed. Images of virtual machines are
stored in a remote repository and they need to be transported to a host to instantiate the virtual machine.
The two schedulers presented in this section differ by the relaxation technique applied on the TVM-RR scheduler. Relaxation techniques are commonly used, since they trans-form an NP-Hard integer linear problem into a related linear problem that can be solved in polynomial time. The decision of using ILP was taken due to the encouraging results obtained by this technique when applied to schedule grid applications without software requirements [9].The produced schedule establishes the appropriate mapping of tasks and VMs onto hosts and communication paths, in a way that VMs satisfy the software re-quirements of the applications. Tasks are mapped onto hosts in order to produce the most advantageous virtualization of both computational and communication resources.
The TVM schedulers receive as input two graphs. The first one is a DAG type graph that describes the application submitted to be executed in the grid/private cloud, as ex-plained in Section 2.4. Such description can be given by the user or calculated following an application profiling model [50]. The application DAG is represented using the following notation:
• n: number of tasks (n ∈ N);
• Ii: processing demand of the ith task, expressed as the number of instructions to be processed (Ii ∈ R+);
• Si: software demand of the ith task (Si ∈ N);
• Bi,j: number of data units transmitted between the ith task and the jth task (Bi,j ∈ R+);
• D: set of arcs {ij : i < j and there exists an arc from vertex i to vertex j in the DAG};
The second graph received by a TVM schedulers is a graph representing the topology of grid/private cloud resources (computing resources connected by network paths). These resources have the following characteristics:
• m: number of existing hosts (m ∈ N);
• Ck: number of processing cores of host k (Ck ∈ N);
• TIk: average time the kth host takes to execute one instruction (TIk∈ R+); • T Rk: average time for transmitting one data unit on the path connecting the virtual
machine repository and the kth host (TRk ∈ R+);
• TBk,l: average time for transmitting one data unit on the path connecting the kth host and the lth host (TBk,l ∈ R+);
• N : set {kl : host k is linked to host l}. In particular, kk ∈ N for any host k and if kl ∈ N then we also have lk ∈ N ;
• δ(k): set of hosts linked to the kth host in the network, including the host k itself. Data regarding the virtual environment is stored in the following variables:
• o: number of VMs existing in the repository (o ∈ N);
• SVv: software available on the vth virtual machine (SVv ∈ N);
• BVv: number of data units that have to be transmitted so that virtual machine v can run on a host (BVk ∈ R+);
• T Vv: time for booting virtual machine v (T Vv ∈ R+);
It is important to observe that the parallel execution of an application on a grid or private cloud must take less time than the serial execution on a single computer. Other-wise, there is no benefit in executing the application on a grid/private cloud. Moreover, a serial execution encompasses not only the execution of all the instructions of the applica-tion tasks, but also the download and boot of the required VM image files. Addiapplica-tionally, due to different repository-to-host link-bandwidths and core processing delays, the serial execution time of an application may vary from one computer to another. Therefore, a maximum parallel execution time, Tmax, is defined as the minimum time that any com-puter in the network would take to carry out a serial execution, expressed as follows:
vi= V M with the sof tware required by task i, V 0 =[ i∈J vi, Tmax= min X i∈J IiTIk + X v∈V 0 BVvT Rk+ X i∈J T Vvi ! , ∀ k ∈ H.
To facilitate the mathematical formulation of the problem, the following sets are de-fined: J = {1, . . . , n} is the set of existing tasks of an application, H = {1, . . . , m} is the set of hosts and V = {1, . . . , o} is the set of VMs available in the repository.
The following formulation considers discrete intervals of time and treat the scheduling problem as an ILP problem. Therefore, discrete timeline of the execution of the appli-cation is defined by: T = {1, . . . , Tmax}. Although the discretization of time introduces approximation and a consequent loss of precision, under certain circumstances, this loss may not be significant, and the saving of time can be quite attractive when compared to a corresponding scheduler which assumes time as a continuous variable.
The ILP solves the scheduling problem by finding the values of these decision variables: • xi,t,k: Binary variable that assumes a value of 1 if the ith task finishes at time t in
the host k; otherwise this variable assumes a value of 0;
• yv,t,k: Binary variable that assumes a value of 1 if the vth virtual machine is ready to be used at time t on the host k; otherwise this variable assumes a value of 0;
The ILP problem is formulated with the constraint groups from (CG1) to (CG10) as follows: Minimize X t∈T X k∈H txn,t,k such that : (CG1) X t∈T X k∈H xj,t,k = 1 ∀ j ∈ J ; (CG2) X j∈J X k∈H dIiT Ike X t=1 xj,t,k = 0; (CG3) X k∈δ(l) t−dIjTIl+Bi,jTBk,le X s=1 xi,s,k ≥ t X s=1 xj,s,l ∀ i, j ∈ J , ij ∈ D, l ∈ H, t ∈ T ; (CG4) X j∈J t+dIjTIke−1 X s=t:t≤Tmax−dIjTIke xj,s,k ≤ Ck ∀ k ∈ H, t ∈ T ; (CG5) X v∈V yv,t,k ≤ Ck ∀ k ∈ H, t ∈ T ; (CG6) X v∈V X k∈H dBVvT Rk+T Vve X t=1 yv,t,k= 0; (CG7) X t∈T X i∈J :Si=SVv (xi,t,k× Tmax) ≥ X t∈T yv,t,k ∀ k ∈ H, v ∈ V; (CG8) t X s=t−dIiTIke yv,s,k ≥ xi,t,k× (dIiTIke + 1) ∀ i ∈ J , v ∈ V, Si = SVv, k ∈ H, t ∈ {dIiTIke + 1, . . . , Tmax}; (CG9) xj,t,l∈ {0, 1} ∀ j ∈ J , t ∈ T , l ∈ H; (CG10) yv,t,k ∈ {0, 1} ∀ v ∈ V, t ∈ T , k ∈ H;
Moreover, these constraints can be classified according to their purpose: 1) for schedul-ing tasks on hosts, 2) for schedulschedul-ing VMs on hosts, 3) linkschedul-ing tasks to VM instances, and finally, 4) state that the variables of this ILP problem, x and y, are binary.
• Constraints for scheduling tasks on hosts:
– Constraint (CG1) specifies that a task must be executed once and on a single host. Knowing that xi,t,kassumes a value of 1 if the ithtask finishes its execution at time t in the host k, this constraint assures that among all the possible combinations of i, t, and k, xi,t,k will assume a value of 1 exactly once.
– Constraint (CG2) determines that a task j must execute all its instructions in order to consider that its execution has finished. This is done by setting to 0 all the index combinations of xi,t,k, for values of t smaller than the time required to execute all the instructions of j on the k host.
– Constraint (CG3) establishes that a task j cannot begin its execution until all preceding tasks have finished and the resulting data has arrived at the host on which task j will run.
– A processing core can only execute one process at a time, thus if assigning more than one, it will execute them serially or employ a technique such as multithreading, taking longer to execute than an actual parallel excecution. Therefore, constraint (CG4) determines that the number of tasks executing on a host k at any time t cannot exceed the number of processing cores of k (Ck). • Constraints for scheduling VMs on hosts:
– Equivalent to constraint (CG4), a processing core may only run a single VM at a time. Therefore, constraint (CG5) specifies that the number of VMs running on a host k at any time t cannot exceed the number of processing cores of k. – The schedulers presented in this dissertation use VMs to meet the software
requirements of application tasks, and such VMs are stored in a repository from which they can be instatiated. Constraint (CG6) determines that a virtual machine v cannot be used until it has been instantiated and booted on host k. • Constraints for linking tasks to VM instances:
– Constraint (CG7) establishes that a virtual machine can only be instantiated on a host if, and only if, that host will execute a task requiring such virtual machine.
– Constraint (CG8) states that a virtual machine must stay active while execut-ing the tasks that require it.
The following sections describe the two TVM schedulers. The TVM-INT scheduler implements the ILP described previously. The TVM-RR scheduler applies relaxation
techniques to reduce the execution time of the scheduler without significant loss of the quality of scheduling.
Each of the constraint group from the ILP formulation is composed by a set of equa-tions. Table 3.1 lists the number of equations that compose each constraint group.
Table 3.1: Number of equations per constraint Constraint Number of equations
CG1 n CG2 1 CG3 −→ij × m × Tmax CG4 m × Tmax CG5 m × Tmax CG6 1 CG7 m × o
CG8 n × m × (Tmax− min (dIiTIke) − 1)
CG9 n × m × Tmax
CG10 o × m × Tmax
The information registered in the previous table implies that as the number of available hosts, VMs or even tasks increments, so does the complexity of the problem. This was the reason for creating not only the strict TVM-INT from Section 3.4, but also a relaxed scheduler such as the TVM-RR (Section 3.5). The pros and cons of both schedulers will become more evident in the results section (Section 3.6).
3.3
Illustrative example
In order to achieve a better understanding of the ILP formulation from Section 3.2 and the purpose of the TVM schedulers, this section presents a simple Illustrative example. Figure 3.2 illustrates a simple Embarrassingly parallel application with 2 tasks in the second level of the graph, 4 tasks in total, and 4 arcs representing data dependencies among these tasks.
0 [1, 2] 1 [3, 1] [2] 2 [3, 2] [2] 3 [1, 1] [1] [1]
Since the application selected for this example has only four tasks with only two software dependencies, a simple network infrastructure with four hosts and a VMR with 4 VMs was adopted (Fig. 3.3). The performance values assign to processing power, network bandwidth, and VM sizes are illustrative in this time.
TI: 1.00 C: 1 TI: 1.00 C: 1 TI: 1.00 C: 1 TI: 1.00 C: 1 TR: 1 TB: 2 o: 4 BV: 4 TV: 2 Virtual Machine Repository TR: 1 TR: 1 TR: 1 TB: 2 TB: 2 TB: 2 TB: 2 TB: 2
Figure 3.3: Illustrative example - infrastructure
For the example proposed in this section, the constraints of the ILP formulation of the TVM schedulers are composed by a total of 1718 equations distributed among the 10 constraint groups as detailed in Table 3.2.
Table 3.2: Illustrative example - Number of equations per constraint Constraints Number of equations
CG1 4 CG2 1 CG3 384 CG4 96 CG5 96 CG6 1 CG7 16 CG8 352 CG9 384 CG10 384 Total 1718
Considering the grid/private cloud infrastructure and the application requirements presented in this section, the minimum serial execution time, also referenced as the
max-imum time for an acceptable parallel execution Tmax, resulted in a value of 24 time units. Fig. 3.4 presents a Gantt chart that illustrates the serial execution.
On the other hand, for the given example, the TVM-Scheduler achieves a makespan of 15 time units, which corresponds to 62.5% of Tmax, thus, obtaining a speedup of 1.6. Moreover, this makespan was achieved by using two of the four available hosts. The achieved schedule is illustrated by the Gantt chart in Fig. 3.5.
Data corresponding to the illustrative example scenario presented in this section can be found in Appendix A.
3.4
TVM-INT
The TVM-INT scheduler is based on the Integer Linear Program explained in Section 3.2, and it is presented in Algorithm 1. After being executed, the TVM-INT returns a schedule specifying the mapping of VMs to hosts and tasks to this VMs. A trade-off exists between the execution time of the scheduler and its accuracy. The last depends on the interval width used in the discretization of the time-line. The wider the interval, a faster execution can be achieved, however, a lower accuracy is obtained. Therefore, Algorithm 2 must be executed to recalculate time values after resources have been mapped to improve its accuracy.
Algorithm 1 TVM-INT Scheduler Require: IP: integer program formulation.
Ensure: Schedule of J in H along with the schedule of the necessary VMs from V in H.
1: Execute the IP
2: Let X be the solution schedule of J in H for the IP, where X=Xi,k and Xi,k =P
t∈T xi,t,k, ∀i ∈ J , k ∈ H
3: Execute Algorithm 2.
Algorithm 2 Schedule time value enhancer Require: xi: Host k that will execute task i.
fi: Discrete finishing time of task i according to actual mapping. yi: VM that will execute task i.
di: Delay caused by coping the image file of yi on the host xi. tvi: Time it takes to boot yi on the host xi.
Ensure: Continuous schedule of J in H along with the schedule of the necessary VMs from V in H.
fi0: Finishing time of each task on the continuous schedule. yai: Time at which yi becomes available.
yui: Time at which yi becomes unavailable
1: ya0 ← d0+ tv0
2: f00 ← ya0+ I0T Ix0
3: yu0 ← f00
4: while at least one task i in J remains to been scheduled do
5: Let s be a feasible starting time for task i, where s ← di+ tvi
6: for each task j ∈ J , j 6= i do
7: if xi= xj and (fj− IjT Ixj) < (fi− IiT Ixi) then 8: if task j has already been scheduled then
9: if yi= yj then 10: s ← fj0 11: else 12: s ← M AX(s, fj0+ tvi) 13: end if 14: else
15: Leave the scheduling of task i for later
16: end if
17: else if task i depends of task j then
18: if task j has already been scheduled then
19: s ← M AX(s, fj0 + Bj,iT Bxj,xi)
20: else
21: Leave the scheduling of task i for later
22: end if
23: end if
24: end for
25: if a starting time for task i was found then
26: fi0 ← s + IiT Ixi
27: yai← s
28: yui ← fi0
29: else
30: Leave the scheduling of task i for later
31: end if
32: end while
3.5
TVM-RR
The TVM-RR scheduler, presented in Algorithm 3, is based on a relaxed version of the ILP explained in Section 3.2. As a consequence of the relaxation, it demands lower execution time to derive a schedule than the TVM-INT scheduler, however, the TVM-INT scheduler produces better schedules in terms of shorter makespans. This trade-off should be taken into consideration given the heterogeneity of application requirements and grid/private cloud users. Users who can wait longer to have a more efficient schedule can use the TVM-INT scheduler, while users who have time constraints can use the TVM-RR scheduler. Although the quality of the schedules obtained with the TVM-RR scheduler is worst than those obtained with the TVM-INT, the gain in execution time can compensate such lower accuracy.
The two TVM schedulers mainly differ by the relaxation technique applied on the TVM-RR scheduler. Relaxation techniques are commonly used to solve ILP formulations since they transform an NP-Hard integer linear problem into a relaxed linear problem that can be solved in polynomial time. In this specific case, the relaxation of the discrete time formulation consists in modifying constraint groups (CG9) and (CG10) to allow the solution variables to assume values in the interval [0, 1] instead of the set {0,1}. Thus, producing a schedule that specifies the probability values of the appropriate mapping of tasks and VMs onto hosts and communication paths, in a way that VMs satisfy the soft-ware requirements of the applications. Furthermore, a randomized rounding algorithm is implemented to select a single mapping based on the obtained probability values. Finally, as the TVM-INT, the TVM-RR executes the timing enhancement from Algorithm 2. Algorithm 3 TVM-RR Scheduler
Require: IP: integer program formulation. P: Number of drawings.
Ensure: Schedule of J in H along with the schedule of the necessary VMs from V in H.
1: Execute the IP relaxed as a linear program
2: Let X be the solution schedule of J in H for the IP, where X=(Xi,k)
3: for P times do
4: for each task i ∈ J do
5: Let Xi,k be the probability of mapping the task i to the host k, consider only the hosts that are linked to the ones running the tasks to which task i depends on.
6: Randomly select a host where the task i should be executed, based on the previous mapping probability.
7: end for
8: Execute Algorithm 2.
9: Keep this schedule if it is the shortest one.
10: end for
3.6
Experiments
To assess the performance of the schedulers, the same scenarios in [9] were used with the addition of a virtual machine repository (VMR) and software requirements of the tasks, forming scenarios like the one illustrated in Figure 3.1. The simulated grid/private cloud scenarios were represented by graphs that describe the topology of the network composed by shared resources. Vertices of the graphs represent hosts and the edges represent communication paths. The topology of the graphs are given by the Doar-Leslie method presented in Subsection 2.3.1.
Moreover, the well known embarrassingly parallel application, presented in Subsec-tion 2.4, was employed for the experiments of this secSubsec-tion. However, as illustrated in Figure 3.6, software dependencies and other relevant information was added [38] [43]. As mentioned in Section 2.4, each node of the graph represents a task, which can be identi-fied by a number outside of the brackets. Additionally, the two numbers in the brackets represent, respectively, the amount of instructions that will be executed when running the task and the ID of the virtual machine that satisfies a task software requirement. The weight of the arcs represent the amount of data to be exchanged by the tasks.
0 [53, 8] 1 [50, 3] [5] 2 [49, 9] [4] 3 [47, 4] [5] 4 [48, 1] [4] 5 [45, 10] [5] 6 [53, 6] [4] 7 [50, 2] [4] [5] [4] [5] [4] [5]
Figure 3.6: Embarrassingly parallel application DAG used for experiments
The weights of the edges of the DAG in Figure 3.6 were in the interval [4,5], whereas the weight of the vertices in the interval [45,53]. Software requirements were generated randomly following a uniform distribution to match one of 10 VM images in the repository. It is the authors’ best knowledge that a statistic information that describes the distribution of software requirements of an application is not available in the literature. Information concerning the size of VM images were obtained from [11] [39]; varying from 50MB to 305MB, i.e., mean size of 108.5MB with a standard deviation of 79.46. When executing the TVM-RR, different values of P where tested and the value of 10 was selected due to the obtained results and the time taken to achieve them.
The schedulers were implemented in the C language using the Fico Xpress Optimiza-tion Suite 7 [23] to solve the ILP. All the programs were executed on a Dual Xeon 2GHz computer with 4MB of L2 CACHE, 4GB of RAM and Debian GNU/Linux 5.0 operating system.
Three sets of experiments were conducted, varying: i) the number of hosts in the network (m), ii) the connectivity of the network (probability β), and iii) the bandwidth distribution of the network (probability α). If not stated otherwise, the parameters used to generate the network graph were: m=50, α=0.9, and β=0.5. The processing rate of
the hosts follow a uniform probability distribution function in the interval (0.4,2]. The capacity of network paths varied in the interval (0,5], following the Doar-Leslie method.
Two metrics were evaluated, the makespan of the application when scheduled with one of the proposed schedulers and the execution time taken by the scheduler to generate the schedule. It is expected that the TVM-INT scheduler achieves shorter makespans but longer execution times, when compared with the TVM-RR scheduler.
This section presents a comparison between the makespans of the schedules produced by the two schedulers in each of the experiments and the execution time required by the schedulers to produce them. The makespan of the generated schedules was also compared to that of a serial execution (Tmax). The points in the graphic correspond to the mean value and a confidence interval with 95% confidence level (The confidence interval is needed because the TVM-RR scheduler was executed 5 times for each of the scenarios).
Results are summarized in Subsections 3.6.1 to 3.6.3. These three subsections in-clude graphs containing five curves each. The curve Tmax plots the serial execution of the application. The curves “Makespan (TVM-INT)” and “Makespan (TVM-RR)” plot, respectively, the makespan of the schedules produced by the schedulers TVM-INT and TVM-RR. The curves “Execution time (TVM-INT)” and “Execution time (TVM-RR)” plot, respectively, the Execution time of the schedulers TVM-INT and TVM-RR.
3.6.1
Variation of the number of hosts in the grid/private cloud
Figure 3.7 shows the makespan of the application as a function of the number of hosts. As the amount of hosts increases, a slight reduction of the makespan can be observed on both schedulers (the two curves in the center of the graph). The results obtained in the scenarios with 180 and 200 hosts show a high makespan value. This is explained by the fact that as the amount of hosts increases, more memory is necessary to solve the ILP. When the grid/private cloud infrastructure exceeds 170 hosts, the amount of memory of the computer used for the experiments is not sufficient to run the TVM schedulers. It’s important to observe that the TVM-INT scheduler demands more memory for a higher number of hosts than does the TVM-RR scheduler. This is a direct consequence of the relaxation.Figure 3.7 also shows the time needed to schedule the application as a function of the number of hosts (the two curves at the bottom of the graph). Both schedulers need more time to generate a schedule as the number of hosts increments, but for an amount of hosts smaller than 120, the TVM-RR scheduler takes less time, also due to the relaxation.
3.6.2
Variation of the probability value of paths between hosts
Figure 3.8 shows the makespan of the application as a function of probability β. As the grid/private cloud has more connections between hosts (large node connectivity), the chance of having adjacent computers with high processing power also increases. In this way, the makespan of both schedulers decreases. The makespan of the schedules generated by both schedulers are slightly different, but a greater difference can be observed when compared to the serial execution (The curve on the top of the graph).Figure 3.8 also shows the time needed to schedule the application as a function of probability β. For most scenarios, it is preferable to use the TVM-RR scheduler rather than the TVM-INT due to its notably shorter execution time.
0 50 100 150 200 250 300 350 400 450 500 550 0 20 40 60 80 100 120 140 160 180 200 Time (s) Amount of Hosts Tmax Makespan (TVM-INT) Makespan (TVM-RR) Execution Time (TVM-INT) Execution Time (TVM-RR)
Figure 3.7: Makespan vs number of hosts
0 50 100 150 200 250 300 350 400 450 500 550 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Time (s) β Tmax Makespan (TVM-INT) Makespan (TVM-RR) Execution Time (TVM-INT) Execution Time (TVM-RR)
3.6.3
Variation of the bandwidth in network paths
Figure 3.9 shows the makespan of the application as a function of probability α. Both schedulers obtain schedules with lower makespans than the serial execution. The TVM-INT obtains even smaller makespans than the TVM-RR, but this is compensated by the time needed to schedule the application, in which case, the TVM-INT takes longer.
It is possible to conclude that both TVM schedulers generate schedules with a makespan smaller than the serial execution. Additionally, even though the makespans obtained with the TVM-INT scheduler are shorter than the ones obtained with the TMV-RR, in some cases, it is more convenient to use the TVM-RR scheduler due to the shorter execution time demanded, which is a direct consequence of the use of the relaxation technique.
