Versão do arquivo anexado / Version of attached file:
Versão do Editor / Published Version
Mais informações no site da editora / Further information on publisher's website:
https://ieeexplore.ieee.org/document/5993746
DOI: 10.1109/TLA.2011.5993746
Direitos autorais / Publisher's copyright statement:
©2011 by Institute of Electrical and Electronics Engineers. All rights reserved.
DIRETORIA DE TRATAMENTO DA INFORMAÇÃO Cidade Universitária Zeferino Vaz Barão Geraldo
CEP 13083-970 – Campinas SP Fone: (19) 3521-6493 http://www.repositorio.unicamp.br
Abstract—The aim of task scheduling is to minimize the
makespan of applications, exploiting the best possible way to use
shared resources. Applications have requirements which call for customized environments for their execution. One way to provide such environments is to use virtualization on demand. This paper presents two schedulers based on integer linear programming which schedule virtual machines (VMs) in grid resources and tasks on these VMs. The schedulers differ from previous work by the joint scheduling of tasks and VMs and by considering the impact of the available bandwidth on the quality of the schedule. Experiments show the efficacy of the schedulers in scenarios with different network configurations.
Keywords— Grid Computing; Scheduling; Virtualization
I. INTRODUÇÃO
AUMENTO na capacidade dos enlaces de rede, associado ao crescimento no número de computadores ociosos conectados à Internet, motivou o desenvolvimento de soluções distribuídas para tirar proveito da disponibilidade de todo esse poder computacional, o que levou à criação da “Computação em Grade” [1], um paradigma de computação que permitiu uma nova classe de aplicações e serviços, tais como aquelas da e-Science [2].
Com a evolução da computação em grade, foram facilitados outros requisitos além de poder de processamento e conectividade de rede, tais como sistemas operacionais, bibliotecas de software e até mesmo versões específicas de software, ou seja, as aplicações passaram a exigir ambientes personalizados para sua execução. Uma forma de disponibilizar esses ambientes é através de virtualização de hardware e software. Nesse cenário, os escalonadores de grade instanciam máquinas virtuais (MVs) que correspondem aos requisitos das aplicações no momento em que elas são submetidas [3]. 1
O escalonador de tarefas é responsável por definir os recursos a serem utilizados por uma aplicação e o momento em que esses recursos serão utilizados. Com a adição de requisitos de software, o escalonador tem que satisfazer os requisitos, por exemplo,instanciando MVs que contenham o software requisitado. Se um escalonador que não considere esses requisitos for utilizado, escalonamentos subótimos são obtidos.
Este artigo apresenta escalonadores de Tarefas e Máquinas Virtuais (TVM), que escalonam MVs nos recursos da grade e tarefas nestas MVs. Assim, é possível definir sistemas virtuais
C. G. Chaves, Universidade Estadual de Campinas (Unicamp), cesarchaves1@gmail.com
D. M. Batista, Universidade de São Paulo (IME-USP), batista@ime.usp.br N. L. S. da Fonseca, Universidade Estadual de Campinas (Unicamp), nfonseca@ic.unicamp.br
de computação que vão além das limitações do software impostas pelos recursos reais disponíveis. Apesar da existência de outras abordagens para gerenciamento de recursos em grades com suporte à MVs [4] [5] [6] [7] [8], nenhum deles escalona tarefas e máquinas virtuais conjuntamente como os escalonadores TVM. A maioria destas abordagens ignora também o impacto que a disponibilidade de banda passante causa no escalonamento, um aspecto considerado pelos escalonadores TVM.
Os escalonadores TVM são baseados numa formulação de programação linear inteira. Dois escalonadores são propostos: o escalonador TVM-INT, que implementa o problema de programação inteira exata; e o escalonador TVM-RR, que implementa uma versão relaxada do problema de programação inteira. O primeiro tende a gerar soluções com melhor qualidade, enquanto o segundo tende a reduzir o tempo de execução para se obter um escalonamento. Essas duas características devem ser levadas em consideração, dada a heterogeneidade de requisitos das aplicações e de usuários na grade. Os usuários que podem esperar para ter um melhor escalonamento irão usar o escalonador TVM-INT, enquanto os usuários que precisam de um retorno rápido irão usar o escalonador TVM-RR. É importante observar que, embora a qualidade dos escalonamentos obtidos com o escalonador TVM-RR seja pior do que aquela obtida com o TVM-INT, o ganho em tempo de execução compensa essa desvantagem.
Os escalonadores propostos destinam-se a um cenário no qual o usuário acessa um middleware para submeter a aplicação que deseja executar. Um dos escalonadores TVM, então, mapeia as tarefas da aplicação nos recursos computacionais disponíveis, escalonando, também, a instanciação de MVs, a partir do repositório de MVs (VMR), de tal modo que a aplicação possa ser executada no ambiente necessário e os resultados sejam enviados de volta para o usuário. Este cenário é apresentado na Fig. 1.
A eficácia dos escalonadores é avaliada por simulação, considerando-se diversos cenários de rede. Os resultados mostraram que os dois escalonadores são capazes de produzir escalonamentos que usam eficientemente a infra-estrutura disponível e que estes escalonamentos são produzidos dentro de um prazo de execução curto. Como esperado, os makespans produzidos pelo escalonador TVM-INT são menores que os produzidos pelo escalonador TVM-RR, enquanto o tempo de execução do primeiro é maior do que o do último.
O restante do artigo está organizado da seguinte forma. A Seção II resume trabalhos relacionados, a Seção III apresenta os dois escalonadores TVM, a Seção IV explica a configuração dos experimentos realizados para avaliar o desempenho dos escalonadores, a Seção V apresenta os
O
C. G. Chaves, Student IEEE, D. M. Batista, N. L. S. da Fonseca, Senior Member IEEE
Scheduling Grid Applications with
Software Requirements
resultados obtidos, e a Seção VI conclui o artigo.
Figura 1. Infraestrutura do escalonador TVM
II. TRABALHOS RELACIONADOS
Recentemente, o escalonamento de máquinas virtuais e o escalonamento de tarefas com requisitos de software tem sido foco de interesse, principalmente devido ao surgimento da computação em nuvem [4] [5] [6] [7] [8].
Na arquitetura de grade Nova [4], as máquinas virtuais são criadas com antecedência para evitar um impacto negativo sobre o tempo de execução das aplicações. Embora o uso de MVs pré-instanciadas reduza tanto o tempo necessário para ter uma MV pronta para executar uma tarefa quanto a quantidade de dados transferidos através da rede, tal prática consome recursos. Se uma grade com uma grande disponibilidade de MVs for implementada, cada MV deverá ser instanciada em cada computador da rede, ou a utilização de cada MV seria restrita a um determinado conjunto de computadores. Outras arquiteturas, que usam repositórios de MVs, como os escalonadores apresentados neste trabalho, não têm estes requisitos, permitindo a instanciação de qualquer MV requisitada, em qualquer computador da grade. Isso possibilita a execução de aplicações sem a existência obrigatória de MVs ociosas.
O Serviço de Escalonamento Bicriteria [5] propõe um escalonador de grade para workflows de aplicações distribuídas, sugerindo a instanciação dinâmica de serviços para atender as necessidades da aplicação. Ele considera o compromisso entre o makespan do escalonamento e a quantidade de serviços dinamicamente instanciados. Embora o Serviço de Escalonamento Bicriteria seja eficaz em muitas situações, ele não é útil quando as tarefas de um workflow têm demandas de software de baixo nível, tais como um sistema operacional específico ou uma versão do kernel. Os dois escalonadores apresentados, neste trabalho, evitam esse problema usando MVs que oferecem ambientes de trabalho isolados e personalizáveis.
A VMGrid (Virtual Machine Grid) [6] é um middleware de grade que permite que os usuários criem ambientes de execução personalizados, especificando a necessidade de recursos e a configuração de software. Tais ambientes podem ser implantados em uma grade e ser controlados, iniciando, parando ou reiniciando as MVs. Embora VMGrid permita aos usuários a criação de ambientes de execução personalizados,
ele não escalona tarefas, nem considera a largura de banda disponível nos enlaces da rede ao transferir imagens de MVs para os computadores da grade, como fazem os escalonadores TVM.
Em [7], apresenta-se uma arquitetura para projetar sandboxes de MVs. Mostra-se que o uso de MVs facilita o desenvolvimento, a implementação e o gerenciamento de sistemas distribuídos. Embora a arquitetura em [7] reforce o uso de MVs para executar tarefas com requisitos de software, ela não especifica como as MVs ou as tarefas são escalonadas. Em nossa abordagem, os escalonadores têm a responsabilidade de escalonar as tarefas, e instanciar as MVs nos computadores apropriados conforme os requisitos das tarefas e a disponibilidade de recursos, mantendo a transparência para os usuários.
Em [8], apresenta-se um serviço de computação em batch chamado JAWS (Job-Aware Workspace Service), que separa o controle sobre o compartilhamento de recursos da execução de tarefas e gestão, enquanto delega o controle sobre o ambiente de trabalho para o usuário. Apesar de JAWS gerenciar a execução de tarefas, ele não as escalona. Em nossa abordagem, o escalonador se encarrega de decidir como será criado o ambiente de trabalho. Desta forma, o usuário apresenta a descrição da sua aplicação e aguarda o resultado especificado no escalonamento.
III. ESCALONADORES PROPOSTOS
O objetivo dos dois escalonadores TVM é minimizar o makespan de uma aplicação de grade. As aplicações de grade para as quais os escalonadores TVM foram projetados são aquelas compostas por tarefas dependentes, e com as dependências descritas por Grafos Acíclicos Orientados (DAGs).
Qualquer dos dois escalonadores instancia no máximo uma máquina virtual por tarefa, garantindo que, em um determinado momento, cada núcleo de processamento executa no máximo uma instância da máquina virtual e cada máquina virtual executa só uma tarefa. O compartilhamento de um núcleo de processamento por várias MVs não é considerado porque se mais de uma MV for executada simultaneamente no mesmo núcleo de processamento, o poder de processamento será dividido por elas [9], fazendo com que o tempo de execução individual seja maior.
Os dois escalonadores TVM são projetados para receber informações sobre a disponibilidade de computadores e de enlaces da grade. Esta informação é obtida por ferramentas de monitoramento de recursos tais como as apresentadas em [10] e [11]. Recursos incluem computadores, enlaces de rede, e disponibilidade de MVs no repositório. A descrição das aplicações que serão escalonadas é fornecida pelo usuário, como descrito em [12].
As informações que descrevem as aplicações são compostas pelas demandas específicas de processamento, comunicação e software das tarefas.
Os escalonadores TVM foram implementados como programas lineares inteiros. Os dois escalonadores diferem pela técnica de relaxação utilizada pelo escalonador TVM-RR. As técnicas de relaxação são usadas comumente porque transformam um problema linear inteiro NP-difícil em um problema linear equivalente que pode ser resolvido em tempo
polinomial. A decisão de utilizar programação linear inteira foi tomada devido aos bons resultados obtidos por essa técnica quando usada para escalonar aplicações de grade sem demandas de software [13]. O escalonamento gerado estabelece o mapeamento de tarefas e máquinas virtuais em computadores e enlaces de rede, de forma que as MVs satisfaçam os requisitos de software das aplicações. As tarefas são mapeadas, a fim de se ter a melhor virtualização possível, tanto dos recursos computacionais quanto dos recursos de comunicação, minimizando o makespan da aplicação.
A. Formulação do programa linear inteiro
A seguinte notação é utilizada na formulação matemática dos problemas. Em primeiro lugar são definidas as informações referentes à aplicação submetida sob a representação de um DAG:
• n: número de tarefas ( ∈ ℕ);
• : demanda de processamento da tarefa i, expressa como o número de instruções a serem processadas ( ∈ ℝ ); • : identificador da MV que contém o software requerido
pela tarefa i ( ∈ ℕ);
• , : quantidade de dados transmitidos entre a tarefa i e a
tarefa j ( , ∈ ℝ );
• : conjunto de arcos {ij : i < j e existe um arco do vértice i ao vértice j no DAG};
Os recursos da grade composta por máquinas e enlaces de rede têm as seguintes características:
• m: número de computadores ( ∈ ℕ);
• : número de núcleos de processamento do computador k ( ∈ ℕ);
• : tempo que o computador k leva para executar 1 instrução, expresso em segundos ( ∈ ℝ );
• : tempo necessário para transmitir uma unidade de dados sobre o enlace que conecta o repositório de MVs e o computador k, expresso em segundos ( ∈ ℝ ); • ,: tempo necessário para transmitir uma unidade de
dados pelo enlace que conecta o computador k e o computador l, expresso em segundos ( , ∈ ℝ );
• Ɲ: conjunto {kl: o computador k está conectado ao computador l}. Em particular, kk ∈ Ɲ para todo computador k e se kl ∈ Ɲ então lk ∈ Ɲ;
• δ(k): conjunto de computadores conectados ao computador k na grade, incluindo o próprio computador k.
Os dados relacionados ao ambiente virtual são armazenados nas seguintes variáveis:
• o: número de máquinas virtuais existentes no repositório ( ∈ ℕ);
• : software disponível na máquina virtual v ( ∈ ℕ); • : tamanho da maquina virtual v em Megabytes
( ∈ ℝ );
• : tempo de inicialização da maquina virtual v, expresso em segundos ( ∈ ℝ );
É importante considerar que a execução paralela de uma aplicação de grade deve demorar menos tempo do que a execução serial em um único computador. Caso contrário, não há benefício na execução da aplicação na grade. Para evitar isso, o tempo máximo de execução de uma aplicação ( ) deve ser establecido. Por isso, é definido como o menor tempo que
levaria um computador da rede para executar sequencialmente todas as tarefas da aplicação. Considerando-se, também, o tempo necessário para descarregar do repositório o arquivo da imagem das máquinas virtuais necessárias e inicializar estas MVs para executar as tarefas, i.e.:
= ′ = ∈ = ∈ + ∈ + ∈ ∀ ∈ℋ
Para facilitar a formulação matemática do problema, são definidos os seguintes conjuntos: = {1, … , } é o conjunto de tarefas da aplicação; ℋ = {1, … , } é o conjunto de computadores da nuvem e = {1, … , } é o conjunto de máquinas virtuais no repositório.
A formulação dos escalonadores TVM considera intervalos discretos de tempo e trata o escalonamento como um problema de programação linear inteira. Por isso, a linha temporal discreta da execução da aplicação é definida por = {1, … , }. Embora a discretização de tempo implique em aproximação e, consequente perda de precisão, em algumas circunstâncias, isto pode não ser significativo e a diminuição no tempo de execução pode compensar essa perda, quando comparado com um escalonador correspondente que assuma uma linha de tempo contínua. O problema de programação inteira fornece o escalonamento através das seguintes variáveis:
• , , : Variável binária que assume o valor 1 se a tarefa i
termina sua execução no instante de tempo t no computador k; caso contrário, assume o valor 0;
• , , : Variável binária que assume o valor de 1 se a
máquina virtual v está pronta para ser utilizada no tempo t no computador k; caso contrário esta variável assume o valor 0;
O problema de programação linear inteira foi formulado da seguinte maneira: : , , ∈ℋ ∈ , : ( 1) , , = 1 ∈ℋ ∈ ∀ ∈ ; ( 2) , , = 0; ∈ℋ ∈ ( 3) , , ≥ , , , , ∈ ( ) ∀ , ∈ , ∈ , ∈ ℋ, ∈ ;
( 4) , , ≥ : ∈ ∀ ∈ ℋ, ∈ ; ( 5) , , ≥ ∈ ∀ ∈ ℋ, ∈ ; ( 6) , , = 0; ∈ℋ ∈ ( 7) ( , , × ) ≥ , , ∈ ∈ : ∈ ∀ ∈ ℋ, ∈ ; ( 8) , , [ ] ≥ , , × ( + 1) ∀ ∈ , ∈ , = , ∈ ℋ, ∈ { + 1, … , }; ( 9) , , ∈ {0,1} ∀ ∈ , ∈ ℋ, ∈ ; ( 10) , , ∈ {0,1} ∀ ∈ , ∈ ℋ, ∈ ;
Os grupos de restrições de (C1) até (C4) estão relacionados com o escalonamento de tarefas em computadores. As restrições em (C1) especificam que toda tarefa deve ser executada em algum momento e em um único computador. A restrição em (C2) determina que a tarefa j não pode terminar até que todas suas instruções tenham sido executadas no computador k. As restrições em (C3) estabelecem que uma tarefa j não pode iniciar a sua execução até que todas as tarefas que a precedem tenham terminado e os dados resultantes tenham chegado ao computador onde será executada a tarefa j. As restrições em (C4) estipulam que o número de tarefas em execução em um computador k em um tempo t não pode exceder o número de núcleos de processamento de k. Os grupos de restrições (C5) e (C6) são relacionadas ao escalonamento de máquinas virtuais em computadores. As restrições em (C5) especificam que o número de máquinas virtuais rodando em um computador k em um tempo t não pode exceder o número de núcleos de processamento de k. A restrição em (C6) determina que uma máquina virtual v não pode ser utilizada até que tenha sido instanciada no computador k, e tenha sido iniciada.
Os grupos de restrições de (C7) até (C8) referem-se à relação entre tarefas e máquinas virtuais. As restrições em (C7) estabelecem que uma máquina virtual só pode ser instanciada em um computador se, e somente se, o computador irá executar uma tarefa que requer essa máquina virtual. As restrições em (C8) estipulam que uma máquina virtual deve permanecer ativa por um período não inferior ao tempo de execução das tarefas que vão usá-la. Os grupos de restrições (C9) e (C10) especificam que
as variáveis do problema de programação inteira, x e y, assumem unicamente valores binários.
B. O escalonador TVM-INT
O escalonador TVM-INT é apresentado no Algoritmo 1. O programa linear inteiro é executado e retorna um escalonamento exato em que cada tarefa está mapeada em um único computador.
A precisão dos resultados obtidos utilizando uma formulação de programação linear inteira depende da largura do intervalo utilizado na discretização nesse da linha do tempo. Quanto maior o intervalo, mais rápida a execução, porém, menor é a precisão do resultado. A fim de recalcular os valores de tempo para que a precisão do escalonamento seja melhorada, o Algoritmo 2 é executado, ajustando os valores de tempo do escalonamento inicial.
C. O escalonador TVM-RR
O escalonador TVM-RR é apresentado no Algoritmo 3. Em primeiro lugar, executa-se o programa linear inteiro com um relaxamento das variáveis de decisão. A relaxação de uma formulação de tempo discreto consiste em alterar o conjunto {0,1} das restrições em (C9) e (C10) para o intervalo [0, 1]. Por conseguinte, ao invés de retornar o escalonamento da aplicação, o programa linear inteiro relaxado retorna a probabilidade de que cada tarefa seja mapeada em cada computador da grade. Conseqüentemente, os valores das probabilidades são utilizados para guiar os sorteios que definem se um computador deve ou não instanciar uma MV e executar a tarefa que a requer. Assim como no escalonador TVM-INT, o escalonador TVM-RR executa o Algoritmo 2, para recalcular os valores de tempo de modo que a precisão do escalonamento seja melhorada. Os sorteios e o Algoritmo 2 são executados P vezes e o escalonamento com o menor makespan é escolhido. P deve ser definido de forma a aumentar as chances de obter um bom escalonamento. O tempo de execução do escalonador TVM-RR aumenta proporcionalmente ao valor de P.
Algoritmo 1 Escalonador TVM-INT
Entrada: IP: formulação do programa linear inteiro.
Saída: O escalonamento de em e o escalonamento das MVs
necessarias de em .
1: Execute a IP
2: Seja o escalonamento resultante de em para a IP, onde =
, e , = ∑∈ , , , ∀ ∈ , ∈
3: Execute o Algoritmo 2. 4: Retorne o escalonamento
Algoritmo 2 Aprimorador de escalonamentos
Entrada: : Computador que executará a tarefa .
: Tempo discreto da conclusão ta execução da tarefa de acordo com o mapamento atual.
: MV que executará a tarefa .
: Tempo requerido para transferir o arquivo de imagem da MV para o computador .
: Tempo requerido para iniciar no computador .
Saída: Escalonamento continuo de em alem do escalonamento
das MVs necessarias de em .
: Tempo no qual torna-se disponível. : Tempo no qual torna-se indisponível.
1: ← +
2: ′ ← +
3: ← ′
4: enquanto exista uma tarefa em que ainda não tenha sido escalonada faça
5: Seja um tempo de inicio viável para a tarefa , onde ← +
6: para cada tarefa ∈ , faça
7: se = and ( ) ( ) então
8: se a tarefa já tem sido escalonada então 9: se = então 10: ← ′ 11: senão 12: ← ( , ′, ) 13: fim se 14: senão
15: Deixe o escalonamento da tarefa para depois 16: fim se
17: senão se a tarefa depende da tarefa então 18: se a tarefa já foi escalonada então
19: ← ( , ′+
, , )
20: senão
21: Deixe o escalonamento da tarefa para depois 22: fim se
23: fim se 24: fim para
25: se foi encontrado um tempo de inicio para a tarefa então
26: ′← +
27: ←
28: ← ′
29: senão
30: Deixe o escalonamento da tarefa para depois 31: fim se
32: fim enquanto
33: Retorne o escalonamento
Algoritmo 3 Escalonador TVM-RR
Entrada: IP: formulação do programa linear inteiro.
: quantidade de sorteios.
Saída: O escalonamento de em e o escalonamento das MVs
necessárias de em .
1: Execute a IP relaxada como um programa linear
2: Seja o escalonamento resultante de em para a IP, onde
= ,
3: para vezes faça
4: para cada tarefa ∈ ∈ faça
5: Seja , a probabilidade de mapear a tarefa no
computador , considere somente os computadores vizinhos dos que estão executando as tarefas das quais a tarefa tem dependência.
6: Aleatoriamente selecione um computador para executar a tarefa , se basando na probabilidade de mapeamento. 7: fim para
8: Execute o Algoritmo 2.
9: Salve o escalonamento se ele tem um menor que
os anteriores. 10: fim para
11: Retorne o escalonamento encontrado.
IV. AVALIAÇÃO DE DESEMPENHO
Para avaliar o desempenho dos escalonadores, os mesmos cenários de [13] foram utilizados, adicionando um repositório de máquinas virtuais (RMV) e dependência de software para as tarefas. As grades simuladas foram representadas por grafos que descrevem a topologia da rede composta pelos recursos compartilhados. Os vértices dos grafos representam os computadores e as arestas representam os enlaces de rede. A topologia de rede das grades foi gerada utilizando o método de Doar-Leslie [14], um método para gerar topologias de rede similares àquelas formadas por recursos na Internet. O método Doar-Leslie recebe três parâmetros de entrada: m, a quantidade de computadores na rede, β, a conectividade de rede (o grau da rede) dos computadores, e α, a relação entre a quantidade de enlaces com a maior largura de banda e a quantidade de enlaces com a menor largura de banda. Na medida em que o valor de α se aproxima de 1, aumenta a probabilidade de que os valores da média e a mediana da largura de banda sejam iguais.
Para avaliar o desempenho dos escalonadores propostos foi utilizada uma aplicação de processamento de imagens normalmente executada em grades, conforme ilustrado na Fig. 2 [12] [15]. Cada nó do grafo representa uma tarefa, identificada por um número fora dos colchetes. Os dois números entre colchetes representam, respectivamente, a quantidade de instruções que serão executadas quando a tarefa for executada e a identificação da máquina virtual que satisfaz os requisitos de software da tarefa. O peso dos arcos representa a quantidade de dados a serem trocados pelas tarefas.
Figura 2. Aplicação para processamento de imagens de 8 tarefas.
Os pesos das arestas do DAG na Fig. 2 foram sorteados no intervalo [4,5], enquanto o peso dos vértices no intervalo [45,53]. Os requisitos de software foram gerados aleatoriamente, seguindo uma distribuição uniforme para coincidir com uma das 10 imagens de MV no repositório. É do conhecimento dos autores que uma informação estatística que descreva a distribuição de requisitos de software de uma aplicação não está disponível na literatura. Informações relativas ao tamanho das imagens das MVs foram obtidas a partir de [16], variando de 50MB a 305MB, ou seja, uma média de tamanho de 108.5MB com um desvio padrão de 79,46. Ao avaliar o TVM-RR, diferentes valores de P foram testados e o valor 10 foi escolhido devido aos resultados preliminares obtidos e ao tempo necessário para adquirí-los.
Os escalonadores foram implementados na linguagem C utilizando o software Fico Xpress Otimization Suite 7 [17] para resolver o problema de programação linear inteira. Todos
os programas foram executados em um computador equipado com um processador Dual Xeon de 2GHz com 4MB de cache L2, 4GB de RAM e o sistema operacional Debian GNU/Linux 5.0.
Foram realizados três conjuntos de experimentos, variando: i) o número de computadores na grade (m), ii) a conectividade da rede (probabilidade β), e iii) a distribuição da largura de banda da rede (probabilidade α). Se não estiver indicado de outra forma, os parâmetros utilizados para gerar o grafos da grade são: m=50, α=0.9 e β=0.5. A taxa de processamento dos computadores segue uma função de distribuição de probabilidade uniforme no intervalo (0.4,2]. A capacidade dos enlaces da rede foi variada no intervalo (0,5], de acordo com o método Doar-Leslie.
Duas métricas foram avaliadas, o makespan da aplicação quando escalonada com um dos escalonadores propostos e o tempo de execução requerido pelo escalonador para gerar o escalonamento. É esperado que o escalonador TVM-INT consiga makespans melhores, porém, tempos de execução maiores, quando comparado com o escalonador TVM-RR.
V. RESULTADOS NUMÉRICOS
Nesta seção, são comparados os makespans dos escalonamentos produzidos pelos dois escalonadores utilizando os experimentos explicados na secção IV, bem como o tempo de execução requerido pelos escalonadores para produzí-los. O makespan dos escalonamentos gerados também foi comparado com a de uma execução serial ( ). Os pontos no gráfico correspondem a um valor médio de execuções e um intervalo de confiança de 95% (o intervalo de confiança é necessário porque o escalonador TVM-RR foi executado 10 vezes para cada um dos cenários).
Os resultados são resumidos nos gráficos das Fig. 3 à Fig. 8, correspondendo dois para cada um dos três conjuntos de experimentos, um dos gráficos com três curvas ilustrando os makespans e outro com duas representando os tempos de execução. A curva representa ao tempo de execução serial da aplicação. As curvas "Makespan (TVM-INT)" e "Makespan (TVM-RR)" mostram, respectivamente, o makespan dos escalonamentos produzidos pelos escalonadores TVM-INT e TVM-RR. As curvas "Tempo de execução (TVM-INT)" e "Tempo de execução (TVM-RR)" mostram, respectivamente, o tempo de execução dos escalonadores TVM-INT e TVM-RR.
A Fig. 3 mostra o makespan da aplicação em função do número de computadores. Conforme aumenta a quantidade de computadores, as chances de se ter computadores mais adequados para execução das tarefas aumenta, portanto, uma ligeira redução do makespan pode ser observada para ambos os escalonadores (as duas curvas inferiores do gráfico). Os resultados obtidos nos cenários com 180 e 200 hosts mostram uma makespan alto. Isso é explicado pelo fato de que como a quantidade de computadores é incrementada, mais memória é necessária para resolver o programa linear inteiro. Quando a grade tem mais que 170 hosts, a memória do computador utilizado para os experimentos é insuficiente. É importante observar que a falta de memória para executar o escalonador TVM-INT apresenta falta de memória ocorre para um número maior de cenários do que o escalonador TVM-RR, devido ao relaxamento das restrições.
Figura 3. Makespan vs quantidade de computadores.
A Fig. 4 mostra o tempo necessário para escalonar a aplicação em função da quantidade de computadores. Ambos os escalonadores precisam de um tempo maior para gerar um escalonamento proporcional ao aumento da quantidade de computadores na grade. Para uma quantidade de máquinas inferior a 120, o escalonador TVM-RR leva menos tempo, isto é devido ao relaxamento das restrições.
Figura 4. Tempo de execução vs quantidade de computadores. A Fig. 5 mostra o makespan da aplicação em função da probabilidade β. Na medida em que a rede tem mais conexões entre os computadores, a chance de ter melhores computadores adjacentes também aumenta. Desta forma, o makespan dos dois escalonadores diminui. Os makespans gerados pelos escalonadores TVM diferem pouco, porém, uma diferença maior pode ser observada quando são comparados com uma execução serial (A curva na parte superior do gráfico).
A Fig. 6 mostra o tempo necessário para escalonar a aplicação em função da probabilidade β. Para a maioria das situações, é preferível usar o escalonador TVM-RR, ao invés do TVM-INT devido ao menor tempo de execução.
Figura 5. Makespan vs β.
Figura 6. Tempo de execução vs β.
A Fig. 7 mostra o makespan em função da probabilidade α. Os dois escalonadores obtêm escalonamentos com makespans inferiores ao da execução serial. O TVM-INT obtém makespans ainda menores do que o TVM-RR, o que é compensado pelo tempo necessário para escalonar a aplicação, como é mostrado na Fig. 8.
Figura 7. Makespan vs α.
Figura 8. Tempo de execução vs α.
É possível concluir que ambos, o escalonador TVM-INT e o TVM-RR, geram escalonamentos com um makespan menor que o da execução serial. Mesmo que os makespans obtidos com o escalonador TVM-INT sejam menores que os obtidos pelo TMV-RR. Em alguns casos, é mais conveniente usar o escalonador TVM-RR, devido ao menor tempo de execução requerido.
VI. CONCLUSÕES
Máquinas virtuais podem ser usadas para construir ambientes de trabalho personalizados para satisfazer os requisitos de software de aplicações. Um dos maiores desafios é escalonar tarefas em computadores e alocar as MVs necessárias neste computador, de forma que a aplicação possa ser executada com um makespan pequeno. Este trabalho apresenta dois escalonadores, o TVM-INT e o TVM-RR, que são capazes de lidar com este desafio. O escalonador TVM-INT procura um escalonamento com o menor makespan, enquanto o TVM-RR procura um escalonamento ideal em um menor tempo de execução.
Trabalhos futuros envolvem a implementação de uma interface que recebe um DAG de aplicação e a disponibilidade de recursos da grade e modifica o DAG da aplicação, adicionando tarefas que representam a instanciação de MVs, criando, assim, um DAG que pode ser escalonado por escalonadores de tarefas tradicionais.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] Foster, “What is the Grid? A Three Point Checklist,” GRIDToday, vol. 1, no. 6, July 2002.
[2] D. P. Anderson, D. Werthimer, E. Korpela, J. Cobb, M. Lebofsky, R. Bankay, and K. Douglas, “Seti@home,” University of California, Berkley, http://setiathome.berkeley.edu/ Accessed at 30 Jul 2010. [3] R. J. O. Figueiredo, P. A. Dinda, and J. A. B. Fortes, “A Case For
Grid Computing On Virtual Machines,” in ICDCS, 2003, pp. 550– 559.
[4] S. Sundarrajan, H. Nellitheertha, S. Bhattacharya, and N. Arurkar, “Nova: An Approach to On-Demand Virtual Execution Environments for Grids,” in 6th IEEE CCGRID, May 2006, pp. 544–547.
[5] L. F. Bittencourt, C. R. Senna, and E. R. M. Madeira, “Bicriteria Service Scheduling with Dynamic Instantiation for Workflow Execution on Grids,” in 4th GPC, May 2009, pp. 177–188.
[6] S. Wu, W. Zhu, W. Jiang, and H. Jin, “VMGrid: A Virtual Machine Supported Grid Middleware,” in IEEE GrC, Aug. 2008, pp. 676– 679.
[7] D. Wolinsky, A. Agrawal, P. Boykin, J. Davis, A. Ganguly, V. Paramygin, Y. Sheng, and R. Figueiredo, “On the Design of Virtual Machine Sandboxes for Distributed Computing in Wide-area Overlays of Virtual Workstations,” in VTDC, Nov. 2006, pp. 8–8. [8] L. Grit, D. Irwin, V. Marupadi, P. Shivam, A. Yumerefendi, J.
Chase, and J. Albrecht, “Harnessing Virtual Machine Resource Control for Job Management,” in VTDC, 2007.
[9] B. Lin and P. A. Dinda, “Towards Scheduling Virtual Machines Based On Direct User Input,” in VTDC. IEEE Computer Society, 2006, p. 6.
[10] M. L. Massie, B. N. Chun, and D. E. Culler, “The Ganglia Distributed Monitoring System: Design, Implementation, and Experience,” Parallel Computing, vol. 30, no. 7, pp. 817–840, 2004. [11] X.-H. Sun and M. Wu, “Grid Harvest Service: A System for
Long-Term, Application-Level Task Scheduling,” IEEE IPDPS, p. 25a, 2003.
[12] L. Renambot, T. van der Schaaf, H. E. Bal, D. Germans, and H. J. W. Spoelder, “Griz: Experience with Remote Visualization over an Optical Grid,” FGCS, vol. 19, no. 6, pp. 871–882, Aug 2003. [13] D. M. Batista, N. L. S. da Fonseca, F. K. Miyazawa, and F. Granelli,
“Self-Adjustment of Resource Allocation for Grid Applications,” Com. Net., vol. 52, pp. 1762–, 2008.
[14] M. Doar and I. M. Leslie, “How Bad is Na¨ıve Multicast Routing?” in IEEE INFOCOM’93, Mar 1993, pp. 82–89.
[15] C. R. Senna, L. F. Bittencourt, and E. Madeira, “Execution of Service Workflows in Grid Environments,” in TridentCom, Apr 2009, pp. 1–10.
[16] S. Bellwood, “Some VMWare Images,” http://www.thoughtpolice.co.uk/vmware/ Accessed at 30 Jul 2010. [17] “Fico Xpress Optimization Suite 7,” FICO, 2010,
http://www.fico.com/en/Products/DMTools/Pages/FICO-Xpress Optimization-Suite.aspx Accessed at 30 Jul 2010.
Cesar Giovanni Chaves Arroyave (GSM’10) nasceu
em Popayán, Colômbia, em 30 de novembro de 1982. Possui graduação em engenharia de sistemas pela Universidad Cooperativa de Colombia (UCC) da mesma cidade em 2004. Ele é atualmente estudante de mestrado em ciência da computação no Instituto de Computação da Universidade Estadual de Campinas (UNICAMP), Brasil e tem afiliação com o Laboratório de Redes de Computadores (LRC) na mesma universidade. Seus interesses de pesquisa são computação em nuvem, computação em grade, virtualização e escalonamento de tarefas e máquinas virtuais.
Daniel Macêdo Batista possui graduação em Ciência
da Computação pela Universidade Federal da Bahia (2004), mestrado em Ciência da Computação pela Universidade Estadual de Campinas (2006) e doutorado em Ciência da Computação também pela Universidade Estadual de Campinas (2010). Em 2007 teve a sua dissertação de mestrado premiada com a segunda colocação no XIV Concurso Latinoamericano de Teses de Mestrado, organizado pelo Centro Latinoamericano de Estudios En Informatica. Desde fevereiro de 2011 é professor doutor do Departamento de Ciência da Computação da Universidade de São Paulo (USP). Sua área de pesquisa é Redes de Computadores e os principais temas de pesquisa são análise de desempenho, engenharia de tráfego, grades, nuvens e virtualização.
Nelson Luis Saldanha da Fonseca possui graduação
em Engenharia Elétrica com ênfase em sistemas pela Pontifícia Universidade Católica do Rio de Janeiro (1984), mestrado em Ciência da Computação pela PUC-Rio (1987), Master In Computer Engineering - University of Southern California (1993) e PhD in Computer Engineering - University of Southern California (1994). Obteve o título de Livre Docente em Redes de Computadores pela Universidade Estadual de Campinas (Unicamp) em 1999. É professor titular da
Universidade Estadual de Campinas, onde, é, atualmente, chefe do departamento de Sistemas de Computação. Exerce o cargo de Editor-in-Chief do periódico IEEE Communications Surveys and Tutorials. Foi EiC do IEEE Communications Society Newsletter e do Global Communications Newsletter. Exerceu o cargo de Director for Latin America Region da IEEE Communications Society e é membro eleito do Board of Governors desta Sociedade. Foi também Director for On-Line Service da ComSoc e Chair de dois comitês técnicos. Criou a conferência IEEE Latin America Conference on Communications e iniciou a série de simpósios em Multimedia Services and Apllications nas conferências IEEE Globecom e IEEE ICC. Atua em diversas sub-áreas em redes de computadores, tais como: controle e modelagem de tráfego, redes ópticas, redes sem fio e video streaming.
