Análise de soluções para Grid Computing

Transcrição

1 Análise de soluções para Grid Computing Jones Bunilha Radtke 1, Carlos Vinícius Rasch Alves 2 1 Curso Superior de Redes de Computadores Faculdade de Tecnologia SENAC Pelotas (FATEC) Rua Gonçalves Chaves Pelotas RS Brazil jones.radtke@gmail.com,cvalves@senacrs.edu.br Abstract. This article presents a study of solutions that aims at the implementation of a computer system where its main feature is the parallel and distributed processing applications, also known as Grid Computing. In the tests performed will be presented and their results in order to determine the performance of the scheduling methods used for each solution. Keywords: grid computing, OAR, HTcondor, analysis, performance. Resumo. Este artigo apresenta um estudo de soluções que tem por objetivo a implantação de um sistema computacional onde a sua principal característica é o processamento paralelo e distribuído de aplicações, também conhecidos como Grid Computing. Neste será apresentado os testes efetuados e seus resultados, a fim de, determinar o desempenho dos métodos de escalonamento utilizados por cada solução. Palavras-Chave: grade computacional, OAR, HTcondor, análise, desempenho. 1. Introdução O crescimento do conhecimento científico está diretamente relacionado a evolução das tecnologias computacionais, visto que, cada vez mais são utilizados sistemas de alto desempenho computacional, como ferramenta, para a resolução de cálculos matemáticos complexos, criação de modelos de simulação e processamento de renderização de imagens e videos na produção cinematográfica. Ainda, pesquisas na área da Medicina, Biologia e das Ciências Exatas são altamente beneficiadas com o uso destes sistemas. A aquisição de sistemas computacionais que tem como característica principal um alto poder de processamento e armazenamento, também chamados de supercomputadores, requerem um alto investimento financeiro. Em conjunto à ideia de que recursos computacionais ociosos possam ser melhor aproveitados, o uso de sistemas de Grid Computing torna-se uma alternativa, onde por intermédio de um único ambiente, pesquisadores podem submeter, tarefas jobs e aplicações, para serem processados em algumas centenas de computadores, que dispõe de menor recurso de hardware, mas que atuam em conjunto de forma paralela e distribuída geograficamente. 2. Computação Paralela e Distribuída A Computação Paralela tem como objetivo a divisão de um problema ou tarefa, para que seja executada de forma concorrente, em processadores distintos, a fim de, obter-se resultados em menor tempo ou com maior eficiência, desta forma, aumentando o poder computacional da estrutura. Ainda, segundo [Dongarra et al. 2003], o ponto crítico de um processamento paralelo é manter todos processadores envolvidos ocupados de forma

2 balanceada, mantendo o nível de comunicação entre os mesmos, de forma harmônica com o meio de comunicação utilizado. Sistemas Distribuídos são um conjunto de computadores independentes, que se apresenta a seus usuários como um sistema único e coerente, desta forma, atua de forma transparente para o usuário, com componentes autônomos que colaboram entre si, e este é o principal desafio para os desenvolvedores desta área. Uma característica importante, do sistema, é estar sempre disponível, mesmo que alguns componentes encontram-se com problemas. Para os usuários ou tarefas, deve ser imperceptível que tais partes possam estar sendo substituídas, consertaras ou adicionadas ao sistema. Com a intenção de manter-se a organização e o controle, sistemas distribuídos são organizados por meio de uma camada de software, muitas vezes denominada de middleware [Tanenbaum and Steen 2007] Cluster Na década 90 novas pesquisas na área de Processamento Paralelo e Sistemas Distribuídos surgem com o intuito de solucionar os problemas de alto investimento para a aquisição de supercomputadores. Ainda nesta década, o cenário computacional começa a modificar-se, em virtude da maior facilidade à aquisição de computadores pessoais. Aliada ao aumento do poder computacional destes equipamentos e o avanço da tecnologia de Redes de Computadores, torna-se um estimulo para o início do desenvolvimento de sistemas que possuem como principal objetivo, interconectar computadores de menor capacidade de recursos de hardware através de um rede local de alta velocidade, com o uso de protocolos de comunicação, e efetuar o compartilhamento destes recursos entre si, de forma a distribuir a carga de processamento na execução de uma tarefa, tornando a capacidade computacional, deste conjunto, tão eficiente quanto ao desempenho de um supercomputador. Este é o conceito básico no qual operam os clusters computacionais [Kon and Goldman 2008] Grid Computing Com o avanço das tecnologias de Redes de Computadores, com conexões a Internet mais rápidas e mais estáveis, propiciou, inicialmente, que universidades norte-americanas e européias fossem capazes de interconectar seus supercomputadores e clusters computacionais, criando assim, organizações virtuais localizadas geograficamente distantes, e em instituições distintas, dando origem aos primeiros grids computacionais. Grid Computing são sistemas computacionais com uma plataforma heterogênea e distribuída geograficamente de forma dispersa, onde os recursos são compartilhados de forma transparente para seus usuários que a utilizam, por intermédio de um único ambiente. Ainda, segundo [Dantas 2005], um grid é um ambiente computacional distribuído paralelo que permite o compartilhamento, a seleção, a agregação de recursos autônomos e geograficamente distribuídos. Estas operações e recursos podem ser utilizados durante a execução de uma aplicação, dependendo de sua disponibilidade, capacidade, desempenho e custo. O objetivo é prover aos usuários serviços com os requisitos de qualidade corretos para o perfeito funcionamento de suas aplicações, através da habilidade de cooperação de compartilhamento e agregação de recursos computacionais distribuídos e disponibilizando-os como recursos e serviços. O nome Grid Computing, ou Computação em Grade, é originada de uma analogia com as malhas de distribuição de energia elétrica dos Estados Unidos, conhecido por

3 Power Grid. Ao utilizar a energia elétrica, o usuário não tem a percepção de onde está sendo gerada, da mesma forma que os recursos computacionais disponibilizados por um grid, irão se apresentar ao seu usuário. Anteriormente ao conceito de grid, os esforços da Computação de Alto Desempenho, eram voltados ao desenvolvimento na criação de algoritmos paralelos, novas arquiteturas para paralelização de hardware e no estudo de escalonamento de algoritmos para otimização de recursos. Máquinas paralelas com dezenas de processadores, conectados por barramentos de alta velocidade eram as plataformas utilizadas. A diferença entre estes sistemas e os grids, está na quantidade de canais de comunicação entre os elementos da estrutura. Supercomputadores paralelos possuem canais de comunicação de alta velocidade, baixa latência e alta confiabilidade, já os grids empregam tecnologias do mercado comum, como redes locais de padrão Ethernet [IETF 2015] e link de Internet, que apresentam baixa velocidade, maior latência e menor confiabilidade, com relação aos barramentos de um supercomputador, para a conexão de aglomerados de computadores. Devido a este aspecto, algoritmos paralelos que apresentavam grande desempenho em computadores dedicados, não necessariamente terão o mesmo desempenho nestas estruturas [Kon and Goldman 2008] Arquitetura Em busca de uma padronização, pesquisadores propõem uma arquitetura de Grid Computing, que permita a interoperabilidade entre organizações virtuais e que alguns módulos como autenticação, autorização, mecanismos de troca de mensagens, compartilhamentos de recursos, escalonamento e balanceamento de tarefas devam fazer parte do sistema [Dantas 2005]. Um modelo de estrutura de quatro camadas é apresentado na figura 1. Figura 1. Modelo de arquitetura de Grid Computing. A camada de Aplicações e Serviços é o nível mais elevado do modelo. Neste, inclui-se um conjunto de ferramentas de desenvolvimento de aplicações que podem variar de organização virtual para organização virtual. Os serviços são os responsáveis pelo gerenciamento dos recursos compartilhados entre diferentes usuários, departamentos e empresas. O Middleware é a camada que permite que múltiplos elementos, servidores, ambientes de armazenamento e redes, possam compor um ambiente de grid, por meio de protocolos dedicados. Este protocolos são os responsáveis por dar suporte aos elementos heterogêneos que irão compor a estrutura de grid. Os elementos de heterogeneidade podem ser diferentes sistemas operacionais, sistemas de arquivos e protocolos de comunicação de rede. A camada de Recursos é formada pelo conjunto de recursos dis-

4 poníveis em cada elemento da estrutura que compõe um grid. A Rede é a camada de nível mais baixo, e tem por objetivo fazer conectividade dos elementos do grid. Nesta camada estão switches, roteadores e a infra-estrutura das redes de comunicação [Dantas 2005] Diferenças entre Cluster e Grid Computing Com um ambiente de um único proprietário, configuração de hardware e software local e com o propósito de resolução de tarefas de uma única organização, é a forma como se caracteriza um cluster. Já um grid disponibiliza recursos e serviços de uma forma geograficamente distribuída, portanto, o gerenciamento destes recursos e serviços, dáse diferentemente. Em um cluster, há uma autoridade central e os elementos trabalham em conjunto com uma única entidade física, enquanto, que nas configurações de grid, o gerenciamento dos elementos é efetuado por cada organização virtual, sem ter uma visão única de sistema [Zem and Brito ]. 3. Soluções de Grid Computing Nesta seção serão apresentadas características, funcionalidades, arquitetura e o método de escalonamento de cada solução estudada OAR O OAR é um gerenciador de recursos para sistemas altamente distribuídos desenvolvido no Instituto Politécnico Nacional de Genoble na França. A filosofia do projeto é que seja possível desenvolver um sistema complexo para o gerenciamento de recursos, sem que a eficiência e escalabilidade seja comprometida. Trata-se de uma solução em código aberto, com licença GPL, implementado com ferramentas de alto nível como bancos de dados MySQL ou PostgreSQL, linguagem scripting Perl e mecanismos para trabalhar com CPUSET, módulo integrado ao kernel do Linux que tem por objetivo fornecer um mecanismo para atribuir um conjunto de recursos computacionais para um conjunto de tarefas. O OAR encontra-se em funcionamento no projeto Grid5000 [Grid ] e no projeto CIMENT [CIMENT 2015] sendo o responsável pelo gerenciamento de recursos e agendamento de tarefas destes grids [OAR 2015] Arquitetura Segundo os desenvolvedores do OAR, pelo fato do sistema possuir um banco de dados de propósito geral, seja a melhor forma de garantir uma interface amigável e um facilitador para a análise de dados com relação aos estados dos recursos e das execuções das aplicações. Portanto não há uma API para o seu uso, pois todo o sistema é definido de acordo com o banco de dados, possibilitando que cada módulo possa ser desenvolvido em qualquer linguagem que possua uma biblioteca de acesso a banco de dados [OAR 2015]. A figura 2, apresenta como é composto a arquitetura do OAR. O único meio de comunicação entre os módulos, é através de consultas SQL no banco de dados, responsável por armazenar as informações relacionados a procuras e ofertas de recursos utilizados. No OAR cada aplicação é representada por uma tabela SQL, o que caracteriza o OAR como uma solução robusta. Os demais módulos do sistemas

5 Figura 2. Arquitetura do OAR. são desenvolvidos em Perl responsáveis por iniciar e controlar a execução das tarefas e escalonar as mesmas [Capit et al. 2005]. Em sua arquitetura o Client ou Frontend, é o elemento que fornece os mecanismos para a submissão das tarefas ou aplicações, para ser processada na estrutura e efetuar a reserva de recursos do grid. O Server Node é o responsável por executar o OAR daemon e armazenar todas as informações relacionados a procuras e ofertas de recursos que poderão ser utilizados e os Nodes são os responsáveis por efetuar a execução das tarefas submetidas ao grid [OAR 2015] Escalonamento Como principal objetivo é apresentar uma solução em plataforma aberta para experimentos e pesquisas, o módulo de escalonamento implementado, no OAR, possui bastantes funcionalidades com algoritmos simples, ainda que as funcionalidades mais importantes são implementadas, como prioridades sobre tarefas, reservas de recursos e backfilling.o método de escalonamento basea-se que todas a aplicações submetidas para execução são ordenadas de acordo com a sua chegada na fila, First Come First Served, conforme o algoritmo padrão implementado no OAR. Gradativamente as aplicações são escalonadas, de uma vez que, não implique em atraso para as tarefas já em execução [Aliaga 2011] HTCondor O HTCondor é um sistema desenvolvido na universidade de Wisconsin-Madison, especializado em gerenciar aplicações de computação que necessitam de alto poder de processamento. Trata-se de um projeto em software livre com licença Apache 2.0 e um dos pioneiros na área da computação distribuída, lançado em Em busca de soluções que permita o uso de ciclos ociosos de recursos computacionais, o HTCondor foi o projeto que influenciou o meio acadêmico, na área da Computação em Alto Desempenho, a intensificar suas pesquisas para este propósito. Ainda a solução pode ser utilizada na construção de ambientes de Grid Computing. A tecnologia flocking permite que múltiplas instâncias trabalhem em conjunto. O HTCondor incorpora muitas das atuais implantações de grid e computação baseada em nuvem, em conjunto com os recursos administrativos do Globus ToolsKit [Globus 2015], torna-se interoperável [HTCondor 2015].

6 Arquitetura A arquitetura do HTCondor suporta que seja utilizado como um gerenciador de um grupo de computadores dedicados ou não, desta forma, através de mecanismos próprios aproveita-se o poder computacional ocioso dos recursos computacionais disponíveis no grid. A estrutura básica da solução é composta por um elemento chamado de gerenciador central (Central Manager), nós executores (Execution Machine) e nós submissores (Submit Machine), e este conjunto também é chamado de pool, conforme apresentado na figura 3. Figura 3. Arquitetura do HTCondor. O gerenciador central, em um pool, é o responsável por coletar informações, através do daemon condor collector, que irá compor as características dos recursos computacionais disponíveis e o seu uso, pertencentes a estrutura. De acordo com as informações coletadas, o gerenciador realizará a seleção dos recursos necessários para a execução de uma tarefa, com a utilização do daemon condor negotiator. O usuário poderá submeter as tarefas através dos nós submissores, e estes serão inseridos em uma fila com o uso do daemon schedd. Já a execução das tarefas são efetuadas nos nós executores com a utilização do daemon start [Aliaga 2011] Escalonamento O HTCondor utiliza um mecanismo de escalonamento conhecido como matchmaking [Raman et al. 1998], que consiste em determinar onde e quando será executada uma tarefa. No ato de submissão de uma tarefa, um componente denominado agente especifica os recursos computacionais necessários para a sua execução e o anuncia para às entidades de matchmaker, que por sua vez, encontra qual o recurso é o mais adequado para executar a tarefa. Após, há a notificação da tarefa e do recurso elegido, que por fim, negociam possíveis termos para iniciar a execução [Aliaga 2011]. 4. Testes Realizados Nesta seção serão apresentados os cenários e a metodologia utilizada nos testes de cada solução de Grid Computing.

7 4.1. Cenário de Testes Com o objetivo de verificar o desempenho, a performance dos métodos de escalonamento, a eficiência e mensurar a utilização de recursos consumidos por cada solução, foi estruturado um ambiente virtualizado, com a ferramenta XenServer versão 6.5, para a instalação dos grids. Ambas estruturas, OAR e HTCondor, foram compostos por um elemento de submissão de tarefas, um gerenciador e dez executores, com harware de uma CPU de 4 cores, 512MB de memória RAM e com sistema operacional Linux Ubuntu Server 14.04, totalizando 40 cores de processamento e 5,12GB de memória RAM de recursos disponíveis em cada estrutura. Com o propósito de comparativo dos resultados, testes realizados no ambiente desenvolvido exclusivamente para esse estudo, também foram efetuados na estrutura do Grid5000, na França. Foram utilizados dois frontends do Grid5000, o Grenoble, composto por 234 cores, divididos em 3 clusters e o frontend Lyon, composto por 106 cores, divididos em 4 clusters Metodologia de Testes Consistem na submissão de algoritmo para o grid, com a utilização da API própria de cada solução, por intermédio do elemento frontend (OAR) ou submit (HTCondor), gerando carga de processamento, uso de memória e recursos de redes em cada elemento que compõe a estrutura, desta forma, verifica-se o tempo de execução de cada tarefa. Para a execução de algoritmos com essa finalidade, é necessário que sejam desenvolvidos baseados em Sistemas Paralelos e que possuam métodos de escalonamento em seu código. Utilizou-se algoritmos de divisão de carga, síntese de códigos irregulares e otimização de memória hierárquica, disponível no projeto Galois [Galois 2015]. O foco principal desta análise é mensurar a eficiência com relação aos recursos utilizados de cada solução, com tudo, não será abordado os mecanismos de desenvolvimento do código utilizado. Figura 4. Gráfico de primeira execução do algoritmo. Os recursos de cada solução foram mensurados através da ferramenta de monitoramento Ganglia [Ganglia 2015], que é um sistema desenvolvido para ser utilizado em ambientes distribuídos e de alto desempenho, nos quais se enquadram os cluster e grid computacionais. As técnicas de engenharia de software e sua organização facilitam a busca de dados. O sistema tem sua origem na Universidade da Califórnia em Berkeley e é distribuído sobre licença open source. Utiliza-se de comunicação multicast para o monitoramento dos elementos do ambiente monitorado.

8 O primeiro teste consiste na submissão do algoritmo para cada solução com sua estrutura de forma completa, com todos os elementos executores ativos. No teste seguinte haverá uma variação da quantidade de elementos executores ativos, em cada estrutura, e também no número de tarefas, job, submetidos, desta forma, será avaliado o desempenho do escalonador de cada grid nestas condições. O terceiro teste, tem por objetivo verificar os resultados na submissão de tarefas utilizando-se da funcionalidade de recursos desejados disponível na solução OAR. 5. Resultados A figura 4, apresenta um gráfico com os tempos de execução do algoritmo em cada solução. Observa-se que o HTCondor foi a solução com melhor desempenho, seguido pelo OAR e o Grid5000 para o teste de primeira execução. Ainda neste gráfico é possível verificar o quanto é eficiente um sistema de grid, em comparação a execução do mesmo algoritmo em um computador, localhost, que possui os mesmos recursos de hardware de um elemento executor do grid. Figura 5. Gráfico de execução do algoritmo em função da quantidade de tarefas submetidas. Os tempos de execução, nos testes seguintes, serão relativamente menores, pois o grid utilizará de recursos de otimização de memória, presente no código do algoritmo utilizado, aumentando a eficiência de execução das tarefas. Tal recurso do algoritmo provê paralelizar as tarefas com utilização de memória compartilhada dentro da estrutura do grid. Os resultados dos testes apresentados nos gráfico da figura 5, foram obtidos por meio da submissão de um conjunto de tarefas simultâneas, dividias em 50, 100, 500 e 2000 tarefas, para quatro ambientes com configurações distintas, onde a primeira foi composta por um executor, o segundo por três executores, o terceiro com cinco executores e o último com dez executores. A submissão de 50 tarefas também foi efetuada nos

9 dois frontend do Grid5000. Devido a uma política existe neste grid, o máximo de tarefas submetidas por único usuário não deve ultrapassar o valor de 50. O propósito desta sequencia de testes é avaliar o desempenho e a eficiência dos métodos de escalonamento de cada solução e o gerenciamento de recursos, quando há um volume de tarefas em fila de execução. Figura 6. Gráficos da utilização de CPU, memória e rede de cada elemento do grid OAR com 2000 tarefas e 10 executores ativos. O OAR foi a solução mais eficiente, pois executou em menor tempo todas as tarefas, em todos cenários testados, toda via, é a solução que utilizou mais recursos de hardware, conforme os dados apresentados na tabela 1, que encontra-se em anexo ao artigo. Os gráficos da figura 6 e 7, apresentam a utilização dos recursos de CPU, memória RAM e tráfego de rede de cada solução em função do tempo, na execução de 2000 tarefas submetidas a cada grid. Analisando-os, é possível constatar que no OAR, o elemento que possui maior carga de processamento é o Server Node, uma vez que é o servidor de banco de dados do sistema, responsável por armazenar todas as informações relacionadas a execução das tarefas e gerenciamento de recursos do grid. Já para o HTCondor, o elemento com maior carga de processamento é o Submit Machine, devido este ser o responsável por efetuar o agendamento das tarefas submetidas ao grid. Estes aspectos foram igualmente repetidos em todos os cenários testados e podem ser analisados nos demais gráficos em anexo ao artigo. O gráfico apresentado na figura 8, exibe o resultado da submissão de 50 tarefas simultâneas com a seleção de recurso desejado, funcionalidade presente no OAR, a ser executado em 12, 20 e 40 cores de processamento. Na estrutura desenvolvida para os testes, a cada 4 cores, representa um elemento executor, portanto, 12 cores condiz a 3 elementos executores. Observa-se que o melhor desempenho foi obtido pelo OAR

10 Figura 7. Gráficos da utilização de CPU, memória e rede de cada elemento do grid HTCondor com 2000 tarefas e 10 executores ativos. Figura 8. Gráfico de execução do algoritmo com seleção de recurso desejado. comparado ao Grid5000, mas a principal constatação é que quanto maior o recurso desejado, maior será o tempo de execução das tarefas concorrentes, pois o grid só iniciará a execução de uma tarefa, quando houver a disponibilidade do recurso desejado, consequentemente, acrescendo de tempo para o início de execução de cada tarefa. 6. Conclusões Conclui-se que ambas soluções estudas, OAR e HTCondor, desempenham de forma satisfatório o objetivo proposto. Fazem utilização de recursos ociosos, na execução das tarefas submetidas ao sistema, sem a oneração e prejuízos aos elementos que compõe o grid, indo de encontro com uma das premissas de um Grid Computing, portanto, são boas alternativas de implantação em ambientes que necessitam de sistemas com mais recursos computacionais. A diferença de eficiência comprovada, por meio dos resultados dos testes efe-

11 tuados, é diretamente relacionada aos métodos de escalonamento e gerenciamentos dos recursos utilizados por cada grid. O HTCondor mostrou-se mais eficiente na execução de algoritmo em primeira instância. Por sua vez o OAR mostrou-se mais eficiente no gerenciamento da fila de execução de tarefas, e paralelismo da tarefas, igualmente, foi a solução que utilizou mais recursos de hardware dos elementos executores e de rede. Ainda conclui-se que o desempenho na execução de tarefas em um grid, está diretamente relacionado aos requisitos necessários para a execução desta tarefa. Se determinado algoritmo necessite de mais recursos para ser executado, o grid utilizará dos métodos de gerenciamento de recursos para verificar quando haverá a viabilidade de sua execução, característica comprovada com a submissão de tarefas para o Grid5000, onde mesmo sendo uma estrutura que dispõe de mais recursos, apresentou maior tempo de execução, em virtude da concorrência pelos recursos disponíveis com as tarefas que já encontravam-se aguardando na fila de execução do sistema. Referências Aliaga, A. H. M. (2011). Estudo comparativo de técnicas de escalonamento de tarefas dependentes para grades computacionais. PhD thesis, Universidade de São Paulo. Capit, N., Da Costa, G., Georgiou, Y., Huard, G., Martin, C., Mounié, G., Neyron, P., and Richard, O. (2005). A batch scheduler with high level components. In Cluster Computing and the Grid, CCGrid IEEE International Symposium on, volume 2, pages IEEE. CIMENT (2015). Ciment. Disponível em: < Acesso em: maio Dantas, M. A. (2005). Computação distribuída de alto desempenho: redes, clusters e grids computacionais. Axcel books. Dongarra, J., Foster, I., Fox, G., Gropp, W., Kennedy, K., Torczon, L., and White, A. (2003). Sourcebook of parallel computing, volume Morgan Kaufmann Publishers San Francisco. Galois (2015). Galois. Disponível em: < Acesso em: maio Ganglia (2015). Ganglia. Disponível em: < Acesso em: abril Globus (2015). Globus toolkit. Disponível em: < Acesso em: março Grid5000 (2015). Grid5000. Disponível em: < Acesso em: maio HTCondor (2015). Htcondor. Disponível em: < Acesso em: maio IETF (2015). networks Rfc894 - a standard for the transmission of ip datagrams over ethernet Disponível em: < Acesso em: maio

12 Kon, F. and Goldman, A. (2008). Grades computacionais: Conceitos fundamentais e casos concretos. Proceedings of the Tomasz Kowaltowski e Karin Breitman (Org.) Atualizações em Informática, pages OAR (2015). Oar. Disponível em: < Acesso em: março Raman, R., Livny, M., and Solomon, M. (1998). Matchmaking: Distributed resource management for high throughput computing. In High Performance Distributed Computing, Proceedings. The Seventh International Symposium on, pages IEEE. Tanenbaum, A. S. and Steen, M. V. (2007). Princípios e paradigmas. 2 a edição. Zem, J. L. and Brito, S. H. B. Monitoramento distribuído de clusters e grids computacionais utilizando o ganglia. 7. Anexos Tabela 1. Tabela de recursos de hardware consumido por cada solução. Grid Nodes N o Job CPU % RAM (MB) kb/s rec. kb/s env. OAR ,3 466, ,9 HTCondor ,1 382,8 43,7 43,7 OAR ,1 274,7 286,5 HTCondor ,2 396,6 43,6 43,7 OAR , ,1 HTCondor ,2 456, OAR ,2 542,9 153,4 153,1 HTCondor ,1 632, ,9 OAR ,9 343,2 130,1 136 HTCondor ,1 609, ,4 OAR ,2 413,5 251,3 255 HTCondor , ,5 48,7 OAR ,7 829,9 127,9 152,2 HTCondor ,1 949,1 117,7 114,6 OAR ,6 585,7 215,8 217,7 HTCondor ,1 967,8 117,6 116 OAR ,4 976,4 497,3 529,2 HTCondor ,1 1000,9 117,7 114,4

13 Figura 9. Gráficos da utilização de CPU, memória e rede de cada elemento do grid OAR com 500 tarefas e 10 executores ativos. Figura 10. Gráficos da utilização de CPU, memória e rede de cada elemento do grid HTCondor com 500 tarefas e 10 executores ativos.

14 Figura 11. Gráficos da utilização de CPU, memória e rede de cada elemento do grid OAR com 2000 tarefas e 5 executores ativos. Figura 12. Gráficos da utilização de CPU, memória e rede de cada elemento do grid HTCondor com 2000 tarefas e 5 executores ativos.