FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI COMPUTAÇÃO EM GRADE: ANÁLISE DE DESEMPENHO UTILIZANDO O MIDDLEWARE OURGRID SÃO JOSÉ DOS CAMPOS 2010

FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS

RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI

COMPUTAÇÃO EM GRADE: ANÁLISE DE DESEMPENHO UTILIZANDO O MIDDLEWARE OURGRID

SÃO JOSÉ DOS CAMPOS 2010

i

RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI

COMPUTAÇÃO EM GRADE: ANÁLISE DE DESEMPENHO UTILIZANDO O MIDDLEWARE OURGRID

Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção de título de Tecnólogo em Banco de Dados. Orientador: Msc. Carlos Augusto Lombardi Garcia

SÃO JOSÉ DOS CAMPOS 2010

ii

RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI

COMPUTAÇÃO EM GRADE: ANÁLISE DE DESEMPENHO UTILIZANDO O MIDDLEWARE OURGRID

Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção de título de Tecnólogo em Banco de Dados.

________________________________ MSC. ADRIANA DA SILVA JACINTO ________________________________ MSC. ÉRICA FERREIRA DE SOUZA ________________________________ MSC. CARLOS AUGUSTO LOMBARDI GARCIA 05/07/2010 DATA DE APROVAÇÃO

iii

RESUMO

A Computação em Grade surge com o intuito de oferecer recursos computacionais remotamente. Similar ao funcionamento das companhias elétricas, em que o usuário não sabe como funciona a infraestrutura, mas sabe que, para a utilização do recurso eletricidade, basta usar uma tomada, da mesma forma a Computação em Grade, com o passar dos anos, fundamenta sua infraestrutura, por intermédio de Globus toolkit, alcançando o patamar que possibilita uma realidade próxima ao conceito apresentado. Seu propósito basicamente está em aglomerar recursos geograficamente dispersos formando uma malha, um sistema distribuído onde o usuário pode se beneficiar de todos os serviços agregados à malha, assim como promovê-los. Pode ser imaginada a complexidade de um sistema como este. Tal fato pode tornar receosa a migração de um sistema comum para um sistema em grid. Porém, grids como o Ourgrid, uma grid peer to peer voltada aplicações bag of tasks, procuram proporcionar mais acessibilidade ao uso da Computação em Grade, tanto no uso de sua rede geograficamente dispersa, como na criação de uma grid personalizada, onde equipamentos de uma instituição podem formar uma malha e apresentar um desempenho equivalente ao de um super computador. Este trabalho apresentou o conceito de Computação em Grade, assim como realizou, dentro de um cenário descrito no estudo, uma análise de desempenho comparativa entre uma grid departamental utilizando o middleware Ourgrid e um computador fora da grid com o objetivo de mensurar o ganho de desempenho ao se usufruir desta tecnologia.

Palavras-Chave: Ourgrid, Computação em Grade, grid, middleware.

iv

ABSTRACT

Grid computing emerges with the aim of providing computing resources remotely similar to the operation of utilities, user does not know how the infrastructure, but knows that to use the feature simply use an electric outlet. Likewise, the Grid computing, over the years, bases its infrastructure, through Globus toolkit mainly, reaching a level that enables a close reality to the concept presented. Its purpose is basically resources geographically dispersed clusters forming a grid, a distributed system where the user can benefit from all services added the mesh as well as promote them. It can be imagined the complexity of a system like this. This may become afraid to migrate to a common grid system. However Ourgrid grids as a peer to peer grid bag of tasks-oriented applications, seek to provide more accessibility to use grid computing, both in the use of its network geographically dispersed, as in creating a custom grid, where equipment can form an institution a mesh and present a performance equivalent to a super computer. This paper presented the concept of Grid Computing, and held within a scenario described in the study, a comparative performance analysis between a departmental grid middlerare Ourgrid and using a computer outside the grid in order to measure the performance gain to take advantage of this technology

Key-Words: Ourgrid, Grid Computing, grid, middleware.

v

LISTA DE FIGURAS

Figura 1 - Acesso transparente a serviços e recursos ............................................................... 19 Figura 2 - Arquitetura de Computação em Grade comparada à arquitetura de TCP/IP ........... 22 Figura 3 - Arquitetura em camadas e seus componentes .......................................................... 28 Figura 4 – Infraestrutura da Computação em Grade ................................................................ 29 Figura 5 - Arquitetura multiprocessadas ................................................................................... 33 Figura 6 - Arquitetura de um MPP ........................................................................................... 34 Figura 7 - Arquitetura de uma NOW ........................................................................................ 35 Figura 8 - Arquitetura de Condor ............................................................................................. 42 Figura 9 - Ligação entre Flock Condors ................................................................................... 43 Figura 10 - Componentes de Alchemi ...................................................................................... 45 Figura 11 - Implantação de rede multi nível e de plataforma cruzada ..................................... 47 Figura 12 - Ilustração da arquitetura de Ourgrid ...................................................................... 49 Figura 13 - Interface gráfica do Openfire Server com o Serviço Iniciado ............................... 55 Figura 14 - Interface gráfica do painel de Configurações iniciais do Openfire Server ............ 56 Figura 15 - Interface gráfica do painel administrativo do Openfire Server.............................. 57 Figura 16 - Interface gráfica do componente peer ................................................................... 60 Figura 17 - Janela com a interface gráfica do componente worker .......................................... 61 Figura 18 - Janela de interface gráfica do componente broker ................................................ 62 Figura 19 - Janela para integrar wokers manualmente a um peer ............................................ 64 Figura 20 - Arquivo SDF (Site Description File) ..................................................................... 65 Figura 21 - Janela Add User ..................................................................................................... 67 Figura 22 - Arquivo GDF (Grid Description File) ................................................................... 68 Figura 23 - Utilização das sub-propriedades da propriedade job ............................................. 70 Figura 24 - Exemplo de JDF utilizando suas propriedades e variáveis de ambiente ............... 71 Figura 25 - Fluxograma apresentando a lógica do algoritmo de execução em um computador fora da grid ............................................................................................................ 74 Figura 26 - Algoritmo para execução em um computador local .............................................. 75 Figura 27 - Fluxograma apresentando a lógica do algoritmo de execução em grid ................. 77 Figura 28 - Código para execução em grid .............................................................................. 78 Figura 29 - Comparação dos tempos de execução entre uma grid composta por um único nó e um computador local ............................................................................................. 80

vi

Figura 30 - Comparação dos tempos de execução entre uma grid composta por dois nós e um computador local ................................................................................................... 81 Figura 31 - Comparação dos tempos de execução entre uma grid composta por três nós e um computador local ................................................................................................... 82 Figura 32 - Comparação dos tempos de execução entre uma grid composta por quatro nós e um computador local ............................................................................................. 84 Figura 33 - Comparação dos tempos de execução entre uma grid composta por cinco nós e um computador local ................................................................................................... 85 Figura 34 - Demonstração de todos os tempos obtidos na execução dos testes em grid ......... 87 Figura 35 - Comparação do tempo de execução entre grids de 1 a 5 nós e um computador local........................................................................................................................ 89

vii

LISTA DE TABELAS

Tabela 1 - Comparação entre as plataformas de execução para aplicações paralelas .............. 36 Tabela 2 - Informações e pré-requisitos dos componentes do middleware Ourgrid ................ 54 Tabela 3 - Principais sub-propriedades do arquivo SDF .......................................................... 66 Tabela 4 - Descrição das sub-propriedades de um job ............................................................. 69 Tabela 5 - Fases e comandos da propriedade task .................................................................... 70 Tabela 6 - Operadores lógicos e aritméticos suportados pelo JDF ........................................... 72 Tabela 7 - Resultados da execução em um computador fora da grid ....................................... 79 Tabela 8 - Resultados da execução de uma grid composta por um nó ..................................... 79 Tabela 9 - Resultados da execução de uma grid composta por dois nós .................................. 81 Tabela 10 - Resultados da execução de uma grid composta por três nós ................................. 82 Tabela 11 - Resultados da execução de uma grid composta por quatro nós ............................ 83 Tabela 12 - Resultados da execução de uma grid composta por cinco nós .............................. 85

viii

LISTA DE ABREVIATURAS E SIGLAS

API: Application Program Interface ATM: Asynchronous Transfer Mode BIRN: Biomedical Informatics Research Network CPU: Central Processing Unit DAME: Distributed Aircraft Maintenance Environment DNS: Domain Name Service DoD: Department of Defense DoE: Department of Energy GDF: Grid Description File GPL: General Public Licence GSI: Grid Security Infrastructure HA: High Availability HCP: High Performance Computing HCP++ (High-Performance C++) HP: Hewlett-Packard HSQLDB: Hyper Structured Query Language Data Base INFI: Italian National Institute for Research in Nuclear and Subnuclear Physics INPE: Instituto de Pesquisas Espaciais IP: Internet Protocol JDF: Job Description File JRE: Java Runtime Environment JVM: Java Vitural Machine LAN: Local Area Network LSD/UFCG : Laboratório de Sistemas Distribuídos da Universidade Federal de Campina Grade MAN: Metropolitan Area Network MIT: Massachusetts Institute of Technology MPI (Message Passing Interface). MPP: Massively Parallel Processor NASA: National Aeronautics and Space Administration NEESgrid: Network for Earthquake Enginnering Simulation grid

ix

NIH: National Institutes of Health NoW: Network of Workstations NSF: National Science Foundation OSI: Open System Interconnection P2P: Peer To Peer PC: Personal Computer RMI: Remote Method Invocation SDF: Site Description File SMP: Symmetric Multiprocessing TCP: Transmition Control Protocol TCP/IP: Transmission Control Protocol / Internet Protocol TI: Tecnologia da Informação UFCG: Universidade Federal de Campina Grade WAN: Wide Area Network WCG: Word Community Grid XMPP: Extensible Messaging and Presence Protocol

x

SUMÁRIO

1. 1.1. 1.2. 1.2.1. 1.2.2. 1.3. 1.4. 2. 2.1. 2.2. 2.3. 2.3.1. 2.3.2. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.4.3.1. 2.4.3.2. 2.4.3.3. 2.4.3.4. 2.5. 2.6. 2.7. 3. 3.1. 3.1.1. 3.2. 3.2.1. 3.3. 3.3.1. 4. 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.1.7. 4.1.8. 4.1.9. 4.1.9.1. 4.1.9.2. 4.1.9.3.

INTRODUÇÃO ............................................................................................... 12 Motivação ......................................................................................................... 12 Objetivo............................................................................................................. 14 Objetivo Geral ................................................................................................... 14 Objetivo Específico ........................................................................................... 15 Metodologia ...................................................................................................... 15 Organização do Trabalho .................................................................................. 15 COMPUTAÇÃO EM GRADE ...................................................................... 16 Início da Tecnologia – Computação em Grade ................................................. 16 Definição de Computação em Grade ................................................................ 19 Modelo de Arquitetura da Computação em Grade ........................................... 21 Requisitos Necessários para uma Plataforma de Computação em Grade ......... 23 Componentes da Grid ....................................................................................... 26 Computação Paralela e Computação em Grade ................................................ 29 Clusters ............................................................................................................. 30 Distinção entre Cluster e Computação em Grade ............................................. 31 Plataformas de Execução Paralela .................................................................... 31 Plataforma SMPs .............................................................................................. 32 Plataforma MPPs .............................................................................................. 33 Plataforma NoWs .............................................................................................. 34 Plataforma de Computação em Grade .............................................................. 35 Distinção entre Computação em Grade e Cloud Computing ............................ 36 Usuários de Computação em Grade .................................................................. 37 Considerações Finais ........................................................................................ 39 TECNOLOGIAS DE COMPUTAÇÃO EM GRADE ................................. 40 Condor, Hing Troughput Computing ................................................................ 40 Case do Diagrid................................................................................................. 43 Alchemi - Plug & Play Desktop Computação em Grade .................................. 44 Case do CSIRO ................................................................................................. 47 Ourgrid: A Ferramenda Escolhida para o Estudo de Caso ................................ 47 Cases do OurGrid .............................................................................................. 50 TESTES DE DESEMPENHO PARA UMA GRID LOCAL UTILIZANDO O MIDDLEWARE OURGRID ....................................................................... 52 Apresentação do Cenário de Teste .................................................................... 52 Ambiente de Implantação ................................................................................. 52 Pré-Requisitos para Construção da Grid........................................................... 53 Openfire Server ................................................................................................. 54 OurGrid peer ..................................................................................................... 58 OurGrid worker ................................................................................................. 60 OurGrid broker ................................................................................................. 61 Integração entre Worker e Peer ......................................................................... 63 Integração entre Broker e Peer ......................................................................... 66 Construindo e Submetendo Jobs Para o Middleware Ourgrid .......................... 68 Criando Um Programa para Execução no Worker ............................................ 68 Criando o Arquivo JDF (Job Description File) ................................................ 69 Submetendo um Job para Execução no Middleware Ourgrid .......................... 72

xi

4.2. 4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6. 4.3.7. 5. 5.1. 5.2. 6.

Desenvolvimento dos Testes ............................................................................. 72 Algoritmo de Execução em Um Computador Local......................................... 73 Algoritmo de Execução em Grid ...................................................................... 76 Execução e Análise dos Testes .......................................................................... 78 Execução do Algoritmo em um Computador Local ......................................... 79 Execução e Análise do Primeiro Teste .............................................................. 79 Execução e Análise do Segundo Teste .............................................................. 80 Execução e Análise do Terceiro Teste ............................................................... 81 Execução e Análise do Quarto Teste ................................................................. 83 Execução e Análise do Quinto Teste ................................................................. 85 Conclusão das Análises ..................................................................................... 86 CONSIDERAÇÕES FINAIS ......................................................................... 90 Contribuições e Conclusões .............................................................................. 90 Trabalhos Futuros ............................................................................................. 91 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................... 92

12

1.

INTRODUÇÃO

1.1.

Motivação

Segundo FOSTER, (2004), a Computação em Grade pode ser considerada uma infraestrutura que evolui com o tempo, assim como aconteceu com a rede ferroviária, rede elétrica e de telefonia. Esta se propõe a agregar entidades, públicas e privadas, econômicas e científicas naturalmente em uma rede, grid, onde todos podem ser promotores ou consumidores de serviços, pois seu propósito geral está em oferecer recursos de TI (Tecnologia da Informação) diversos de modo hábil tal qual como quando se utiliza o recurso eletricidade de uma companhia elétrica, “bastando ligar a uma tomada”. A necessidade de entidades comerciais, onde membros em disputa que compõem o mercado almejam uma ferramenta, ou seja, software, sistema, arquitetura; que aumente sua escala de soluções ou traga novos shares, por exemplo: e-commerce. Para serem explorados (REZENDE, 2002). Em destaque, pode ser observada uma problemática: A disputa de pequenas e médias empresas, diretamente ou indiretamente envolvidas com TI, que visam um crescimento oportuno dentre as macros existentes no mercado. Observa-se que toda organização atualmente precisa de um ambiente computacional compatível com o volume de dados destinado aos fins de seu negócio (MORESI, 2000). Macro empresas podem usufruir de meios tecnológicos financeiramente inviáveis para organizações em crescimento, por exemplo, com upgrades ou compras de novos hardwares. Enquanto as pequenas e médias empresas ficam impossibilitadas de utilizarem sistemas de informação de maneira eficaz, que auxiliem a tomada de decisões estratégicas (INTEL, 2009). Outra problemática refere-se ao destino do lixo produzido por diversos países, que é um problema crônico e o lixo tecnológico que faz parte desta questão. Isso significa um acréscimo significativo ao problema do destino do lixo e, consequentemente, produtos como mercúrio e outras toxinas nocivas ao Homem, presentes na maioria dos dispositivos eletrônicos, continuarão a serem depositadas no meio-ambiente (REDE CULTURA, 2001). Data-centers são uns dos principais emissores de CO2 no ramo da informática. Só o consumo de seu arrefecimento pode compreender a 2/3 de seu consumo elétrico total.

13

Um exemplo da grande necessidade de arrefecimento está no aproveitamento do calor gerado pelos servidores da IBM em Madri para aquecer seu edifício (AGUIAR, 2009). Grandes massas de dados são armazenadas e gerenciadas em ambientes computacionais de acordo com os meios disponíveis e objetivos da organização (REZENDE, 2002). Assim como a informatização gera um crescimento oportunista no mercado, torna-se uma necessidade o crescimento sustentável, visando também o meio ambiente. A tecnologia oferecida por Computação em Grade prega o aproveitamento de recursos, minimizando a aquisição de novos equipamentos e super computadores, consequentemente, minimizando custos e gastos com eletricidade (AGUIAR, 2009). Existem ainda organizações que dependam fundamentalmente do poder computacional para execução de suas aplicações. Recentemente, o INPE (Instituto de Pesquisa Espaciais) licitou um super computador de 15 Teraflops, estimado em quarenta e dois milhões de reais (IT WEB, 2009). Os custos de energia de sua produção, do seu funcionamento, do arrefecimento necessário e a produção de CO2, somados ao gasto para aquisição do equipamento podem sugerir a necessidade de uma alternativa menos onerosa como a Computação em Grade. Segundo a (ORACLE, 2005), o resultado de um estudo desenvolvido sobre Computação em Grade é apresentado por meio da comparação de duas pesquisas semelhantes, realizadas no espaço de um ano, mostra um crescente interesse por Computação em Grade, por parte da América do Norte, Europa e Ásia. Numa escala de 0 a 10, foi discriminado o interesse das empresas destas regiões pela Computação em Grade. A média apresentada anteriormente em setembro de 2004 foi de 3,1 contra 4,41 resultantes da pesquisa de 2005. Um resultado satisfatório segundo a própria ORACLE, (2005). Um interessante caso de sucesso apresenta o resultado de um grande grupo de empresas do ramo alimentício quando adotada a tecnologia de Computação em Grade. A GRSA, formada por sete empresas que fornecem uma base de 700 mil refeições por dia. Após um investimento de R$ 1 milhão em Computação em Grade, aumentou sua capacidade de processamento em 140%, mantendo seus equipamentos de hardware, quase sem novas aquisições (ORACLE, 2006). Outro case de destaque é o do Banco Wachovia. No final da década de noventa esta instituição decidiu adaptar um dos seus softwares para a operação de forma distribuída através da utilização da Computação em Grade. Em 2001, todo o departamento de trading de derivativas estava usando servidores e computadores pessoais de baixo custo em substituição dos grandes servidores SMPs (Multiprocessadores Simétricos) até aí utilizados. Os ganhos

14

registrados permitiram que a empresa reduzisse os tempos de cálculo de simulações de 15 horas para 15 minutos ao mesmo tempo em que os volumes de negócios cresciam entre 300% e 400%. (IT PEERS, 2005). Grandes

arquiteturas

como

Globus

Tookit

tornam

acessíveis

o

desenvolvimento de grids entre diversos domínios administrativos, porém esta acessibilidade pode se tornar onerosa devido à complexidade de implantação para atender de forma equiparada os objetivos de cada organização. Para um usuário autônomo, ou mesmo leigo, o uso de grids torna-se complexo (ANDRADE, 2003). Visando popularizar e facilitar o acesso a grid, o Ourgrid desenvolve uma rede peer to peer para conectar uma grid focada em aplicações bag of tasks, aplicações que são executadas através da construção de Jobs compostos por um conjunto de tarefas (tasks) que são executadas em paralelo, na plataforma distribuída da grid e não possuem comunicação entre os processos que as compõem durante a execução dos jobs, daí o nome aplicações bag of tasks. A ferramenta OurGrid facilita a criação de uma grid global, pois permite a utilização da rede distribuída do próprio OurGrid, e também possibilita o desenvolvimento de grids locais, onde os recursos computacionais de um usuário comum ou de instituições que utilizam uma rede TCP/IP podem ser aproveitados para a criação de uma grid que a qualquer momento podem ser integradas formando uma única plataforma de Computação em Grade. Outro ponto forte do OurGrid e que ele não necessita da instalação de uma grande infraestrutura, nem de permissões cabíveis somente aos administradores da rede, suas únicas premissas são: O acesso aos componentes do middlewae Ourgrid e seu correto manuseio (OURGRID, 2010).

1.2.

Objetivo

Realizar uma análise de desempenho comparativa entre uma grid departamental utilizando o middleware Ourgrid, e um computador fora da grid para mensuração do ganho de desempenho.

1.2.1.

Objetivo Geral

15

Apresentar os conceitos de Computação em Grade e realizar um estudo de caso com o middleware Ourgrid executando uma aplicação

bag of tasks demonstrando uma

análise no ganho de desempenho entre uma grid departamental e um computador fora da grid.

1.2.2.

Objetivo Específico

a)

Pesquisar a tecnologia de Computação em Grade;

b)

Pesquisar sobre ferramentas que auxiliem a adoção da Computação em

Grade; c)

Pesquisar os procedimentos para o desenvolvimento de uma grid

departamental. d)

Pesquisar sobre o desenvolvimento e submissão de aplicações para

execução em grid. e)

Analisar o ganho de desempenho de uma grid departamental, através do

reuso de recursos;

1.3.

Metodologia

Adaptar uma aplicação local, desenvolvida para realização do estudo, para uma aplicação que possa ser submetida para uma grid. Os resultados da análise de desempenho serão obtidos na execução da aplicação em ambas às plataformas: grid departamental e computador local.

1.4.

Organização do Trabalho

A seguir serão apresentados os demais capítulos deste trabalho:

16

a)

O Capítulo 2 apresenta um conceito sobre Computação em Grade e suas

principais aplicações; b)

O Capítulo 3 apresenta ferramentas para acesso a grids disponíveis para

a comunidade, bem como a ferramenta do estudo proposto, o middleware Ourgrid; c)

O Capítulo 4 apresenta os procedimentos executados para criação do

cenário dos testes comparativos, a realização dos testes, suas análises e resultados; d)

O Capítulo 5 apresenta a conclusão deste trabalho de graduação.

e)

O Capitulo 6 apresenta a bibliografia utilizada para realização deste

estudo de caso.

2.

COMPUTAÇÃO EM GRADE

Este capítulo apresentará o conceito de Computação em Grade baseada na literatura existente. O Capítulo está organizado como segue: a Seção 2.1 apresenta o cenário que motivou a Computação em Grade. A Seção 2.2 apresenta uma definição do conceito de grids. A Seção 2.3 apresenta um modelo de arquitetura da Computação em Grade. A Seção 2.4 apresenta as arquiteturas para execução de aplicativos distribuídos comparadas com a Computação em Grade. A Seção 2.5 descreve um comparativo entre Computação em Grade e Cloud Computing. A Seção 2.6 descreve a atuação de grid no mercado enquanto a Seção 2.7 apresenta a conclusão do estudo bibliográfico apresentado.

2.1.

Início da Tecnologia – Computação em Grade

Segundo INTEL, (2009), já em 1965, houve a proposta do desenvolvimento de um sistema capaz de oferecer computação como utilidade pública. A proposta era referente a um sistema chamado Multics (Multiplexed Information and Computing Service). Documentada no MIT (Massachusetts Institute of Technology) por Fernando J. Corbató, é proposto um sistema que seria implantado inicialmente em um computador GE 645, capaz de

17

fornecer serviços computacionais tais como o sistema de telefonia da época, utilizando dispositivos remotos e linguagens específicas, provendo a interação de Homem e máquina, e gerando a ambição de um crescimento instantâneo futuro de interesse industrial, governamental e científico (CORBATÓ, 1965). Na década de 90, o termo Computação em Grade ganha força com a proposta de executar aplicações distribuídas em uma grelha que aglomerasse e dispusesse recursos entre organizações dispersas geograficamente (FOSTER, 2004). Foster, (2004), especifica a proposta fazendo uma comparação com a rede elétrica. O usuário não tem conhecimento da infraestrutura por trás de uma companhia elétrica, o serviço é oferecido sob demanda ao usuário de forma transparente. A necessidade cada vez maior de gerar e armazenar conhecimento cria a necessidade de ferramentas com maior capacidade de processamento e armazenamento de dados. No caso de TI, todo computador, por maior que seja seu desempenho, se tornará obsoleto com o tempo. Visando este aspecto, em 1995 foi desenvolvida uma ferramenta chamada I-WAI, mais tarde, com agregação de novos componentes foi renomeado e passou a ser chamado de Globus Toolkit e, atualmente, é referência para as ferramentas de criação de plataformas de Computação em Grade. Esta integrava 17 universidades e seus supercomputadores em um único sistema de software, o acesso a este sistema era possível de qualquer uma das universidades, surgindo a primeira plataforma de Computação em Grade (GOLDCHLEGER, 2005). Em CIRNE, (2005) o interesse por grids pode ser subdividido em dois aspectos: a)

Uma plataforma de execução de aplicações distribuídas mais barata,

vantajosa, acima dos sistemas paralelos da época; b)

Propor uma fonte de recursos simplesmente impossível para um único

computador. Através da aglomeração de recursos dispersos para executar aplicações paralelas. Logo o conceito de Computação em Grade difunde-se, se tornando uma opção viável ao mercado. Atualmente, atinge o interesse de organizações como a Oracle, Intel, EMC e DELL que unem-se para desenvolver, testar e padronizar uma nova tendência para resolução de problemas computacionais envolvendo grande processamento a um custo menor do que o mercado geralmente oferece. Trata-se de um estudo sobre utilização de Computação em Grade, dentro do projeto denominado Megagrid. Este tem a pretensão de prover recursos

18

de TI de alto desempenho para pequenas, médias e grandes empresas a custo inferior a um upgrade ou substituição de novos hardwares (ORACLE, 2004). Com o conceito difundido, começam a surgirem diversas ferramentas para criação de plataformas de Computação em Grade, utilizadas para diversos fins e em diversos escopos, a INTEL, (2009) define um tipo de grid de acordo com o escopo que ela abrange. Os tipos de grid e seus respectivos escopos são apresentados como segue:  Grids departamentais: quando malha da grid é formada apenas por um grupo de potências computacionais, ou seja, clusters, desktops, ligado através de uma rede; de tamanho equivalente a um departamento de uma empresa ou laboratório de informática.  Grids empresariais: quando a grid se estende a uma instituição ou empresa, englobando o máximo de seus recursos computacionais.  Grids globais: quando a grid se estende geograficamente, abrangendo mais de um domínio administrativo. Em síntese, Computação em Grade pode ser vista como um aglomerado de recursos diversos, ou seja, softwares, hardwares, periféricos; oferecendo serviços diversos , ou seja: desempenho, armazenamento, acesso a periféricos remotos, etc. Unificados por um sistema de software entre vários domínios administrativos e transparente ao usuário (GOLDCHLEGER, 2005). A Figura 1 exemplifica de modo simples o que propõe uma estrutura em Computação em Grade:

19

Figura 1 - Acesso transparente a serviços e recursos Fonte: Adaptação de CIRNE, (2005).

Pode ser observado na Figura 1 que a malha da grid aglomera tanto recursos computacionais convencionais como não convencionais em um único sistema. Um laboratório de pesquisa poderia, por exemplo, acessar as informações de um microscópio localizado geograficamente em outro laboratório se ambos estivessem conectados a mesma grid (GOLDCHLEGER, 2005). A escalabilidade da grid e a heterogeneidade de recursos que podem ser adicionados a ela destacam-se como pontos fortes desta tecnologia.

2.2.

Definição de Computação em Grade

O conceito de Computação em Grade foi amplamente difundido no final da década de 90. Ian Foster (FOSTER, 2002) observou que o termo grid começa a se tornar ambíguo. Para uma definição mais clara, Foster escreve o artigo What is the Grid? A Three Point Checklist (FOSTER, 2002) define três pontos essenciais para que seja definida uma grid:

20

a)

Não existe um controle centralizado de recursos: Uma grid oferece um

controle democrático, ou seja, cada domínio administrativo controla seus recursos, provendo ou consumindo-os através da rede. Um computador desktop pertencente a um domínio da rede teria os mesmos deveres e direitos de um Cluster ou um servidor de alto desempenho, segundo as regras e políticas estabelecidas para divisão de recursos. b)

Tecnologia de conexão padronizada e disponível oferecendo interfaces

e protocolos para objetivos gerais, tal qual como: segurança, autenticação, possibilidade de acesso e disponibilização de recursos. c)

Entrega de serviços não triviais, ou seja, uma grid deve ser capaz de

disponibilizar diversos serviços com padrão de qualidade, por exemplo, tempo de resposta throughput, escalonamento de recursos, segurança e etc. BAKER, (2002), também apresenta as características fundamentais que um ambiente em grid deve apresentar e as denota como os princípios gerais inerentes à construção da infraestrutura da Computação em Grade. Os quatro principais princípios exigidos para que uma grid possa suprir os mais diversos cenários em seu desenvolvimento são apresentados como segue: a) Múltiplos domínios administrativos e de autonomia: Os recursos de uma grid podem distribuir-se geograficamente por vários domínios administrativos devem ser compartilhados por diversas organizações. A distribuição destes recursos precisa ser honrada por seus proprietários, juntamente como a igualdade das políticas de utilização. b) Heterogeneidade: Uma grid agrega uma infinidade de recursos que são de natureza heterogênea e que também deverá abranger uma vasta gama de tecnologias. c) Escalabilidade: Uma grid pode crescer a partir de poucos recursos integrados e alcançar o patamar de milhões. E problemas como a degradação potencial de desempenho com aumento do tamanho da grid devem ser previstos e gerenciados. d) Dinamismo e adaptabilidade: Em uma grid, a insuficiência de recursos é regra e não exceção. Com a dinamicidade heterogênea de cenários que uma grid deve abranger, faz com que a probabilidade de algum recurso ficar indisponível seja alta. O gerenciamento de recursos e aplicações deve adequar-se ao comportamento dinâmico da grid e os

21

recursos disponíveis devem ser utilizados de forma a suprir potenciais deficiências. É observada a necessidade da formalização de um padrão para que a partilha de recursos possa ser disponibilizada sem qualquer barreira tecnológica por falta de infraestrutura. Assim como houve a propagação da Internet com a padronização do TCP/IP (Transmission Control Protocol / Internet Protocol) nas redes, a Computação em Grade tem de evoluir seguindo o mesmo exemplo, ou seja, fazer com que a necessidade dos recursos disponibilizados, seja o grande propulsor de seu crescimento (FOSTER, 2002) (FOSTER, 2004).

2.3.

Modelo de Arquitetura da Computação em Grade

Não existe um padrão de modelo formalizado, como o modelo OSI para o desenvolvimento de redes, para embasar projetos de Computação em Grade. Diversas organizações já desenvolveram grids, mas um modelo de desenvolvimento possibilitaria a interação entre grids. Uma sugestão de modelo proposta consiste em cinco camadas sequenciais apresentadas a seguir (FOSTER, 2001): a)

Aplicação: Esta primeira fase está relacionada à interface para a

aplicação do usuário final, incluindo ferramentas de desenvolvimento, gerenciamento, compartilhamento, contabilidade e utilização de atendimento para vários usuários simultaneamente. A sequência das camadas visa possibilitar o atendimento aos recursos solicitados por estas aplicações. b)

Coletivo: Esta segunda etapa está relacionada aos middlewares,

responsáveis pela padronização do sistema possibilitando a comunicação entre sistemas heterogêneos. Opera definindo os protocolos e serviços responsáveis pelo gerenciamento desses recursos, esta é constituída em componentes: i.

Serviços de diretório;

ii.

Serviços de alocação conjunta e agendamento;

iii.

Serviços de monitoramento e diagnostico;

iv.

Serviços de pesquisa de software;

v.

Serviços colaborativos;

vi.

Sistema de programação;

22

c)

Recursos: Aqui estão os protocolos de utilização: i.

Protocolo de Informação: Informa a estrutura e o estado do recurso compartilhado;

ii.

Protocolo de Gerenciamento: Controla o acesso, gerenciando os recursos.

Esta camada também responde por recursos locais, desenvolvendo protocolos que chamam funções de ambiente, estas solicitam controle do recurso local. d)

Conectividade: Aqui é definida a autenticação e comunicação da grid.

Corresponde à sua parte física, é a rede que possibilitará a comunicação literal. e)

Ambiente: Esta camada controla os recursos locais disponíveis,

informando as possibilidades de utilização deste recurso implementando meios para seu monitoramento. Para uma melhor compreensão do que propõe as camadas deste modelo, pode-se observar uma comparação com a arquitetura de camadas TCP/IP, proposto por (FOSTER, 2001), conforme visto na Figura 2.

Figura 2 - Arquitetura de Computação em Grade comparada à arquitetura de TCP/IP Fonte: Adaptação de FOSTER, (2001).

23

a)

Aplicação: estabelece a comunicação do emissor externo, uma

aplicação, tratando as mensagens para que estas possam ser transferidas para os protocolos da camada posterior. b)

Transporte: divide a mensagem e cuida de seu fluxo, incluindo maior

ou menor segurança dependendo de seu protocolo. c)

Rede: contém protocolos para roteamento e detecção de falhas na rede.

d)

Link: corresponde-se diretamente com a conexão da estrutura física.

Observa-se que o modelo desenvolvido por Foster é comparado com a arquitetura TCP/IP para que se apresente uma forma de se submeter uma aplicação para o ambiente em grid. Assim como a arquitetura TCP/IP prepara a informação a ser trafegada pela rede, camada a camada, até a submissão física da informação. O modelo de Foster apresenta um ambiente onde partes da aplicação distribuída possam ser encapsuladas, submetida à grid e consumir seus recursos, ou no caminho inverso, onde a necessidade de uma aplicação encontra um recurso em potencial, da camada méis baixa, Ambiente, até a camada de Aplicação.

2.3.1.

Requisitos Necessários para uma Plataforma de Computação em Grade

Na tentativa de facilitar a colaboração entre vários domínios administrativos que promovem e consomem recursos diversos em cenários heterogêneos, requisitos devem ser atendidos para que a grid consiga operar com eficácia. O acesso aos recursos disponíveis deve ocorrer sem qualquer risco de descontinuidades físicas, tais como as diferenças entre as plataformas, protocolos de rede ou as fronteiras administrativas. Em essência, o middleware grid deve transformar radicalmente um ambiente heterogêneo em um ambiente virtualmente homogêneo, proposto por FOSTER, (2001) e exemplificado por BACKER, (2002), os principais aspectos, as particularidades e as características que uma grid deve conter para oferecer total heterogeneidade e confiança, são apresentados como segue: a)

Hierarquia Administrativa: A hierarquia administrativa é o modo como

cada camada da grid divide-se para cooperar com o ambiente global. Ela também é responsável por determinar como as informações administrativas devem fluir através da grid.

24

b)

Serviços de Comunicação: As necessidades de comunicação de

aplicações que utilizam um ambiente de grid são diversas, vão desde P2P (peer to peer) até a comunicação multicast confiável. Os serviços de comunicação devem prover mecanismos para a comunicação entre os diversos nós da grid e as aplicações existentes neles. A infraestrutura de comunicação tem que suportar protocolos para transporte de massa de dados, streaming data (Fluxo de dados) e grupos de comunicação que são usados por objetos distribuídos. Os serviços de rede também são utilizados para prover aos usuários da grid informações sobre a rede, como sua latência, a largura de banda, segurança, tolerância a falhas e controle de instabilidade. c)

Serviços de Informação: Uma grid é um ambiente dinâmico no qual os

tipos de serviços disponíveis e/ou sua localização estão em constante mudança. O objetivo maior, inerente ao funcionamento da grid, é fazer com que todos os recursos mantenham-se acessíveis para qualquer nó do sistema, sem levar em conta a relação entre a localização do recurso e seu requisitante. Para isso é necessário fornecer mecanismos que permitam a existência de um ambiente rico em informações referentes à localização dos serviços e de fácil aquisição para o requisitante do serviço. Os serviços de informações da grid (Registro e diretório) fornecem mecanismos para registrar e requisitar informações sobre a estrutura da grid, recursos, serviços e seus respectivos estados. d)

Serviços de Nomeação: Em uma grid, como em quaisquer sistemas

distribuídos, nomes são utilizados para referenciar uma grande variedade de objetos que os compõem, tais como computadores, serviços ou objetos de dados. Os serviços de nomeação fornecem um padrão de espaço para nomes que é utilizado através do ambiente da grid. Tipicamente os serviços de nomeação são fornecidos pelo esquema internacional de nomes X.500 ou DNS (Domain System Names), o esquema da internet. e)

Sistema de Arquivos e Caching Distribuídos: Aplicações distribuídas

frequentemente requerem acesso para arquivos distribuídos através de seus servidores. Um sistema de arquivos distribuído é o componente chave de um sistema distribuído. Do ponto de vista das aplicações, a importância de um sistema de arquivos é fornecer um padrão de nomeação global, suportado por uma infinidade de protocolos de entrada e saída que requerem pouca ou nenhuma modificação para o programa que o utilizar, e permitir que

25

mecanismos para otimização do desempenho sejam implementados, como por exemplo, o uso de cache. f)

Segurança e Autorização: Qualquer sistema distribuído seguro necessita

possuir quatro aspectos fundamentais de segurança: confidencialidade, integridade, autenticação, e responsabilidade. Segurança em grid é uma questão complexa que necessita que diversos recursos autônomos interajam e sejam administrados de maneira que não causem impactos na usabilidade dos recursos ou falhas em sistemas individuais. A infraestrutura de segurança é a chave para o sucesso da implementação de uma grid. g)

Sistema de Status e Tolerância a Falhas: Para fornecer um ambiente

confiável e robusto é importante fornecer meios de monitorar os recursos e as aplicações existentes na grid. Para realizar essas tarefas, ferramentas de monitoramento de recursos e aplicações precisam ser implementadas. h)

Gerenciamento e Alocação de Recursos: O gerenciamento da utilização

do tempo de processamento, da memória, da rede, do armazenamento e outros componentes da grid são de grande importância. O objetivo geral deste requisito é fazer de forma eficiente e eficaz o agendamento da alocação dos recursos disponíveis na grid para as aplicações que necessitem utilizá-los. Do ponto de vista do usuário, o gerenciamento e alocação de recursos devem ser transparentes, sua interação deve ser restrita à requisição de recursos feita pela aplicação que deseja executar, mas é importante para uma grid que o middleware ofereça ferramentas para os usuários gerenciarem seus recursos locais oferecido para a grid. i)

Economia Computacional e Negociação de Recursos: Uma grid é

constituída através da junção de diversos recursos distribuídos por várias organizações e domínios administrativos que podem pertencer a organizações diferentes e, para que isso seja possível é essencial que a grid disponibilize mecanismos e políticas que ajudem a regular o suprimento de recursos e sua demanda. Em uma abordagem econômica, a grid deve dispor meios de gerir os recursos de forma complexa e descentralizada. Esta abordagem prevê incentivos para os proprietários de recursos e aos usuários que fazem parte da grid para desenvolver e fazer uso de estratégias que os ajudem a maximizar os seus objetivos.

26

j)

Ferramentas e Paradigmas de Programação: Aplicações para grid

(Aplicações multidisciplinares) combinam recursos que não podem ser replicados em um único local. Uma grid deve incluir interfaces, APIs, e ferramentas para prover um rico ambiente de desenvolvimento. Linguagens de uso científico tal como C, C++, e Fortran devem ser suportadas, como também interfaces em nível de aplicação. Uma variedade de paradigmas de programação deve ser suportada como passagem de mensagens ou compartilhamento distribuído de memória. Adicionalmente, um conjunto de tipos numéricos e outras bibliotecas comumente utilizadas devem também estar disponíveis. k)

Interfaces Gráficas para Administração: As interfaces para os serviços e

recursos disponíveis devem ser intuitivas e de fácil utilização. Adicionalmente, elas devem trabalhar em diversas plataformas e sistemas operacionais. Elas também precisam tirar vantagens da tecnologia web para oferecer a visualização de um portal web relativo à grid. Uma abordagem centrada no desenvolvimento web, para o acesso aos recursos da grid, permite que os usuários acessem qualquer recurso em qualquer lugar em qualquer horário. Isso significa que, os usuários devem ter a possibilidade de submeter seus jobs (trabalhos) aos recursos computacionais através de uma interface Web, a partir de qualquer uma das plataformas acessíveis, tais como PCs, laptops, ou PDAs (Assistente Pessoal Digital), permitindo assim o acesso heterogêneo à grid. O escopo deste trabalho limita-se a apresentação de um conceito sobre a Computação em Grade. A apresentação de uma grid pronta como referencia, seu funcionamento e o uso das tecnologias que a compreendem para que todos estes requisitos sejam sanados fogem ao escopo deste trabalho. A Seção 2.3.2 apresenta os componentes de uma grid, independente das tecnologias usufruídas para sua realização.

2.3.2.

Componentes da Grid

Esta seção descreve de forma mais específica os componentes para criação de uma grid como plataforma.

27

Aqui são apresentados os componentes do projeto Globus Toolkit, que é um conjunto de componentes para a implantação de uma plataforma de Computação em Grade, este projeto é o que mais se aproximou do conceito até o momento, ele aborda todas as exigências para integração individual de componentes heterogêneos de hardware e software, elementos para promover o acesso seguro a recursos e aplicação, assim como possibilitar o desenvolvimento de aplicações por parte dos usuários (BAKER, 2002): a)

Grid Applications e Portal (Aplicação): Geralmente grids são

desenvolvidas com grid-language livres. HCP++ ou MPI são exemplos de utilitários que devem ser oferecidos. Para programas específicos e de alto desempenho, por exemplo, seriam necessários acesso a recursos remotos, armazenamento

ou

interação

com

objetos

científicos

requisitados

remotamente. Portais WEB de informações da grid devem ser disponibilizados para que os usuários possam solicitar e conhecer seus serviços. b)

User-level grid Middleware (Nível de Usuário em Middleware): Aqui

estão inclusas ferramentas de desenvolvimento, gerentes de recursos e o escalonamento de acesso a recursos globais. c)

Core Grid Middleware (Cerne do Middleware): Este é o componente

presente em cada sistema computacional pertencente à grid, responsável pelo gerenciamento descentralizado de recursos. Este gerencia os recursos requisitados, disponíveis, buscas por recursos, provê segurança de acesso para utilização dos recursos locais e o escalonamento dos recursos. d)

Grid Fabric (Tela da grid): Aqui estão relacionados os utensílios

físicos para que haja a conexão da grid. Eles podem estar distribuídos geograficamente sendo PCs, Clusters, databases, roteadores, periféricos e instrumentos científicos específicos, interagindo com plataformas diversas, tais como UNIX, LINUX, Windows, etc. Para melhor compreensão da estrutura destes componentes, BAKER, (2002) faz uma representação gráfica de cada elemento, conforme Figura 3.

28

Figura 3 - Arquitetura em camadas e seus componentes Fonte: Adaptado de BAKER, (2002).

Nota-se, através das afirmações até o momento que um cenário propício para tal estrutura seria a WEB. Assim como na WEB, um usuário da grid possivelmente não vá se preocupar com quem está lhe oferecendo recursos, mas com a disponibilidade e segurança. Esta estrutura propõe uma plataforma transparente aos olhos do usuário. A Figura 4 demonstra um exemplo desta transparência.

29

Figura 4 – Infraestrutura da Computação em Grade Fonte: Adaptado de (BAKER. 2002)

Os usuários interagem com o gerenciador de recursos da grid para resolver seus problemas computacionais que, por sua vez, realiza a descoberta de recursos e propicia o agendamento e processamento de trabalhos (jobs) e de aplicações para utilização dos recursos distribuídos na malha.

2.4.

Computação Paralela e Computação em Grade

A computação paralela deve seu início à “Lei de Amdahl” de Gene Amdahl. Em um estudo matemático realizado em 1967, ele provou a eficácia no ganho de desempenho ao se paralelizar qualquer tarefa. Este foi o estudo que possibilitou o desenvolvimento da computação distribuída, e suas as plataformas: SMPs (Multiprocessadores Simétricos), MPPs (Processadores Massivamente Paralelos), NoWs (Rede de Estações de Trabalho) destinadas á criação de clusters; e a Computação em Grade (INTEL, 2009).

30

2.4.1.

Clusters

Os clusters difundiram-se como umas das primeiras alternativas de paralelismo. Pode ser visto como um aglomerado de máquinas semelhante que, interligadas, podem desempenhar em conjunto tarefas utilizando o paralelismo. Porém, um cluster também pode

ser

desenvolvido

sobre

uma

SMP,

(Multiprocessadores

Simétricos),

MPP

(Processadores Massivamente Paralelos) e NoWs (Rede de Estações de Trabalho) (BAKER, 1999). Para o usuário, o Cluster deve se comportar como um único sistema. De forma geral, pode-se definir clusters como computadores ligados por software que, em conjunto, podem resolver problemas. As características peculiares a um cluster são (BEWOUF, 2007): a) Sistema

fortemente

acoplado:

fundamentalmente

em

sistemas

distribuídos, fortemente acoplado significa a integração intensa de seus componentes, praticamente há interdependência entre eles, por exemplo, todos os servidores realizam as mesmas tarefas. b) Imagem única do sistema: não há heterogeneidade entre as plataformas que compõem a execução, ou seja, não são executados em sistemas operacionais diferentes. c) Gerenciamento centralizado: em geral, há um gerenciador único de recursos, computadores e componentes do sistema são submissos a este gerenciamento. Dentre suas funcionalidades destacam-se: a) HA (Alta disponibilidade): onde seu objetivo está em oferecer redundância e segurança na disponibilidade computacional, deve ser composto por no mínimo dois nós; b) HCP (Computação de Grande Performance): tem a finalidade de oferecer desempenho equivalente a de um supercomputador ou superior de forma que nenhum computador possa oferecer. c) Load-balancing

ou

Balanceamento

de

Carga:

onde

há

um

balanceamento da carga computacional. O ônus é distribuído à procura de um equilíbrio, funcionando como um computador virtual.

31

Essas são funcionalidades e não definem tipos de cluster. O objetivo desta organização é definir se uma ou mais funcionalidades podem ou não ser atribuídas para seu cluster. O cluster veio a se tornar uma alternativa para o mercado de alto desempenho. Softwares de desempenho paralelo, como o Parallel Virtual Machine, em 1989, popularizaram seu uso e, posteriormente, esta tecnologia tornou-se um padrão entre as organizações que necessitam de alto poder computacional (INTEL, 2009). O Problema com os Clusters está no custo e manutenção, pois todos os computadores pertencentes a ele devem ser semelhantes, ou seja, não se pode aproveitar qualquer computador. Geralmente os Clusters são constituídos onde todos os nós (computadores pertencentes ao sistema) estão sujeitos como “escravos” de um nó central que os gerencia, tornando esses nós obsoletos para outros fins (INTEL, 2009).

2.4.2.

Distinção entre Cluster e Computação em Grade

A maior distinção entre Cluster e grid está ligada à oposição das características de um cluster. Enquanto um sistema em cluster é fortemente acoplado, grids oferecem a descentralização de seu sistema, na qual recursos não são somente componentes da grid, são recursos independentes pertencentes ao usuário que os promove, permitindo sua desagregação ou agregação a qualquer momento. Grids são instituídas para funcionar em ambientes heterogêneos, não há uma visão única de sistema. O gerenciamento e o recurso cabem a quem os oferece, assim como a quem o consome, não há uma gestão centralizada para o sistema (BELL, 2009).

2.4.3.

Plataformas de Execução Paralela

A computação paralela surge com o intuito de reduzir o tempo de execução das aplicações. Basicamente paralelizam-se as tarefas de forma que estas possam ser distribuídas e executadas em mais de um processador. Porém, cada aplicação paralela pode ter melhor desempenho se observadas às características da plataforma. Pode-se unificar as plataformas

32

de execução de aplicações paralelas, classificando-as em quatro grupos distintos: SMPs (Symmetric Multi-Processing), MPPs (Massively Parallel Processors), NoWs (Network of Workstations) e grids. Estes grupos apresentam segundo sua finalidade, aspectos dos quais se destacam conectividade, heterogeneidade, compartilhamento, imagem do sistema e escala (CIRNE, 2005): Heterogeneidade: Está relacionada à diferença, por exemplo, arquitetura e/ou desempenho, dos processadores que contém a plataforma, pois cada tarefa pode exigir um tipo especifico de processador. Conectividade: São os meios de conexão entre os processadores, por exemplo, se há memória compartilhada a conectividade pode ser considerada excelente, se a comunicação for por RMIs (Remote Method Invocation) (Chamadas de Métodos Remotos), a conectividade vai depender da rede de comunicação. Atributos relacionados à conectividade são: topologia, latência, largura de banda e compartilhamento. Imagem do Sistema: Pode ser entendida como a visão do processador relacionada à sua plataforma de execução distribuída, isto é, cada processador pode enxergar um sistema operacional diferente, mas pertencer ao mesmo sistema distribuído. Escala: Apresenta a quantidade de processadores que pode conter uma plataforma. Em seguida será apresentada cada uma das plataformas de execução de aplicações distribuídas citadas, seu funcionamento e suas principais características.

2.4.3.1.

Plataforma SMPs

SMPs ou (Multiprocessadores Simétricos), refere-se a uma plataforma em que todos os processadores utilizam a mesma memória e enxergam um único sistema, eliminando o compartilhamento de recursos distribuídos devido ao último aspecto. Percebe-se que sua conectividade é excelente, pois há a memória como canal de comunicação. De heterogeneidade nula, uma vez que os processadores têm de ser de mesma arquitetura, é limitado a apenas algumas dezenas de processadores. Comuns no mercado, este tipo de máquina se dispõe desde PCs (Computadores Pessoais) bi-processados a mainframes com dezenas de processadores (CIRNE, 2005). Para melhor esclarecimento do leitor pode-se observar a Figura 5:

33

Figura 5 - Arquitetura multiprocessadas Fonte: Adaptado de CIRNE, (2005)

2.4.3.2.

Plataforma MPPs

Os MPPs ou (Processadores Massivamente Paralelos) é uma plataforma que se difere dos SMPs por não compartilhar a mesma memória. Cada processador usufrui de sua própria memória de acesso e a comunicação se estabelece através de um canal dedicado, podendo até mesmo ser implementado por um usuário que agregue vários hosts para formar um pequeno Cluster. Sua conectividade é muito boa, pois o canal é dedicado, sua heterogeneidade é baixa uma vez que os processadores não enxergam um sistema único, mas sim, um sistema comum. Cada processador executa uma copia do sistema e a divisão de tarefas é realizada por um escalonador que define qual aplicação será alocado a qual processador. Sua escala chega próxima a mil processadores, tornando-se uma plataforma de maior capacidade. Porém, se o escalonador não encontrar nós suficientes para executar determinada aplicação, esta terá de aguardar em uma fila até que se desocupe um nó. Existe, também, a possibilidade da execução de aplicações cada qual em um nó, conseqüentemente eliminando o compartilhamento de recursos entre elas. Dentre vários supercomputadores que usam este sistema pode-se citar o IBM SP2 e o Cray T3E (CIRNE, 2005). A Figura 6 exibe a estrutura da plataforma MPP:

34

Figura 6 - Arquitetura de um MPP Fonte: Adaptado de CIRNE, (2005)

2.4.3.3.

Plataforma NoWs

NoWs (Network of Workstations) ou (Rede de Estações de Trabalho) é similar a MPPs. Ambas possuem processadores, cada qual com sua memória, porém NoWs não possuem um sistema centralizado de escalonamento. Cada nó tem seu escalonamento próprio para suprir a demanda de aplicações no sistema distribuído. O problema conseguinte está na atribuição de uma aplicação para mais de um nó, já que o escalonamento é distinto. Outra diferença está na conectividade. Em geral, NoWs não tem uma comunicação dedicada às aplicações, ou seja, sua conectividade tende a ser menor que a de uma MPP. Como em MPPs, uma NoWs pode integrar nós através de EThernet ou ATM (Modo Assíncrono de Transferência). Apesar de NoWs também oferecerem uma imagem comum do sistema, o compartilhamento de recursos entre outras aplicações já existe uma vez que uma aplicação em execução já pode disponibilizar recursos. A Figura 7 apresenta um esquema da estrutura da plataforma NoWs (CIRNE, 2005):

35

Figura 7 - Arquitetura de uma NOW Fonte: Adaptado de CIRNE, (2005)

2.4.3.4. Plataforma de Computação em Grade

Observa-se por meio dos textos anteriores que cada plataforma de computação distribuída, apesar de apresentar suas características favoráveis, dependendo do tipo da aplicação a ser executada, evolui quanto à da heterogeneidade de seus componentes, além de possuir as seguintes características: escala de nós agregados, imagem do sistema passa de única para comum e a possibilidade do compartilhamento de recursos de uma aplicação para outra, contando como única desvantagem desta evolução a conectividade, uma vez que foi apresentada uma conectividade excelente para uma SMP por meio do compartilhamento da mesma memória entre os processadores e boa conectividade para a plataforma NoW, uma vez que a comunicação é realizada por meio de uma rede geralmente não dedicada. A Computação em Grade apresenta uma sequência na evolução destas plataformas. Um grid pode agregar recursos diversos à sua plataforma, não se limita a arquitetura do processador. A escala de um grid pode ser exponencial, agregando inclusive SMPs, MPPs, NoWs ou quaisquer componentes que ofereçam recursos computacionais, acrescentando dezenas de milhares de nós à sua plataforma. O escopo de um grid pode abranger a WEB como rede de comunicação, o que compromete a conectividade. A estrutura de uma grid pode ser vista como um emaranhado de recursos e serviços heterogêneos diversos, providos por entidades oferecendo e consumindo recursos da grid de forma

36

transparente ao usuário final. Uma comparação entre todas as plataformas citadas pode ser observada na Tabela 1 (CIRNE, 2005):

SMP

MPP

NOW

GRID

CONECTIVIDADE

EXELENTE

MUITO BOA

BOA

REGULAR/RUIM

HETEROGENEIDADE

NULA

BAIXA

MÉDIA

ALTA

COMPARTILHAMENTO

NÃO

NÃO

SIM

SIM

IMAGEM DO SISTEMA

ÚNICA

COMUM

COMUM

MÚLTIPLA

ESCALA

10

1000

1000

100.000

Tabela 1 - Comparação entre as plataformas de execução para aplicações paralelas Fonte: Adaptado de (CIRNE, 2005)

2.5.

Distinção entre Computação em Grade e Cloud Computing

Um paradigma computacional que vem ganhando grande espaço no mercado da Informática é o Cloud Computing. Este causa certa confusão com Computação em Grade devido às similaridades de suas perspectivas de serviço. Esta similaridade pode ser atribuída observando as definições destas perspectivas. FOSTER, (2004), define grid através da comparação deste serviço com a malha de distribuição de energia elétrica. A mesma facilidade com que usamos a energia elétrica seria análoga ao uso da grid. FOSTER, (2008), define cloud como um serviço de alta disponibilidade e usufruído de acordo com a demanda dos usuários. Em BARBOSA, (2009) é observada que a primeira definição se assemelha com à segunda nos aspectos da alta disponibilidade de serviços sob demanda e economia, porém o conceito de cloud ganha espaço uma vez que oferece seus serviços com mais facilidade, o usuário não precisa especificar quais os recursos computacionais ele precisa, basta usar os serviços oferecidos. No caso do grid este conhecimento é necessário, deve haver uma especificação de quais recursos o usuário precisa e este os usa de acordo com as necessidades de sua aplicação. Outra diferença está relacionada à segurança, enquanto nas tecnologias cloud existentes basta um cadastro, com login e uma senha para autenticação, como nos serviços

37

oferecidos pela Amazon AS, grids geralmente usam o protocolo GSI (Grid Security Infrastructure), com o qual se deve programar as regras de autenticação, autorização e proteção dos dados que a grid irá oferecer (FOSTER. 2008). Ambas as tecnologias oferecerem um nível de segurança satisfatório, porém o conceito de grid é mais criterioso neste quesito, pois possuí regras para que o compartilhamento de recursos possa ocorrer em mais de um domínio administrativo. Outra vantagem está no poder computacional que ela oferece, superior aos serviços

tradicionalmente

oferecidos

por

cloud.

Em

ultima

análise,

aplicações

demasiadamente específicas são mais adequadas para as grids, uma vez que exige uma especificação maior do que se precisa, oferecendo um acesso minucioso a seus recursos. Por este motivo, grid torna-se uma opção viável para comunidades de pesquisa científicas e uma alternativa atraente para data-centers que exijam alto desempenho. Como as tecnologias de cloud estão focadas em oferecer serviços: recursos de hardware, armazenamento, desenvolvimento ou distribuição de aplicações on-line, independente dos aspectos relacionados à arquitetura tecnológica que os disponibiliza (LIZHE, 2008), este se torna uma opção mais atrativa para o mercado. Porém, atualmente pesquisas relacionadas às grids crescem contundentemente, pois promete uma distribuição de recursos mais democrática, integração escalável de recursos compartilhados, aproveitamento de hardwares quando o escopo se restringe a organizações particulares e desempenho superior, ou seja, o interesse por Computação em Grade ainda existe no mercado quando a idéia central do escopo de uma grid deixa de ser global e passa a ser organizacional ou departamental (LUCCHESE, 2006).

2.6.

Usuários de Computação em Grade

Atualmente as grids apresentam soluções para os mais diversos problemas, principalmente para áreas relacionadas à pesquisa acadêmica e de ciências humanas. Este fato justifica-se observando que o início do desenvolvimento desta tecnologia foi focado em suprir a demanda de processamento, apresentada pelas universidades e centros de pesquisa, por objetos de estudos que exigiam grande desempenho computacional e, consequentemente, apresentavam um quadro ideal para o uso da Computação em Grade (INTEL, 2009). Atualmente diversos projetos atuam usando grid. A área comercial ainda reluta diante de

38

tantas outras opções que aparentemente oferecem os mesmos benefícios, como o conceito de Cloud Computing, por exemplo, porém grid veio a se tornar uma opção de grande viabilidade, atuando em diversas áreas, as quais serão apresentadas nesta seção (BARBOSA, 2009). A vantagem do uso da grid está na possibilidade de crescimento em escala, quanto mais nós são agregados à grid, maior seu poder computacional (INTEL, 2009). Nas ciências biológicas, grids são utilizadas nos estudos relacionados ao genoma humano, Bioinformática, Neurociência, Biologia Computacional, entre outras. De modo mais específico, grids são utilizadas em projetos como WCG (Word Community Grid) (IBM, 2004), atuando na resolução de problemas pesquisa do vírus influenza, cura da distrofia muscular, estudo do câncer; BIRN (Biomedical Informatics Research Network) (BIRN, 2010), voltada a Biomedicina e Genética, é uma iniciativa européia que utiliza a grid para ligar vários pontos de pesquisa integrando bases de dados e instrumentos remotos; Medgrid (Medical Grid) estuda a possibilidade de ressonância magnética em tempo real, etc. (MEDICAL GRID, 2004). As grids também desempenham um papel importante na coleta de dados de instrumentos distintos e, geograficamente, distribuídos, integrando-os de forma a passar para o usuário a sensação de utilizar um único sistema. Essa possibilidade de integração inclui as grids na perspectiva do rol de áreas como o campo de transporte, médico, engenharia, meteorologia entre outras. Todas as áreas das quais essencialmente instrumentos de coleta de dados fazem parte de seu processo. DAME (Distributed Aircraft Maintenance Environment) desenvolve um projeto cujo objetivo está no pedido da manutenção da Aviação Civil, integrando recursos de sistemas de acesso remoto, dentro de um sistema estratégico de apoio a decisão (DAME, 2003). Pesquisas relacionadas à Física Quântica e Nuclear, entre outras, tendem a gerar grandes massas de dados no meio acadêmico. Recursos de grande poder computacional são necessários para o andamento deste processo. Grids, como já citado, possibilitam a integração de sistemas heterogêneos, incluindo os geograficamente distribuídos, podendo prover um desempenho computacional de magnitude viável a estes problemas. Vários projetos buscam integração nacional e internacional através das grids buscando um poder computacional suficiente para resolução de seus problemas. Desta forma, projetos como INFI (Italian National Institute for Research in Nuclear and Subnuclear Physics), focado em pesquisa da Física Nuclear, integram nacionalmente uma grid com o objetivo de processar informações e de seus instrumentos, como colisores atônicos, entre outros, estudando os constituintes fundamentais da matéria (INFI, 2008).

39

Dentro da Engenharia, devido às vantagens que uma grid pode oferecer, diversos projetos, utilizando grids despontam nesta área. Como exemplo, Neesgrid (Network for Earthquake Enginnering Simulation Grid). Possuindo uma rede colaborativa, esta infraestrutura integra diversos centros de engenharia responsáveis por pesquisas relacionadas a tremores de terra. Tanto os instrumentos de monitoramento quanto as bases de dados são integrados através da grid NEESgrid, provendo alto desempenho (NEESGRID, 2005). Soluções como data-warehouse, mineração de dados para conhecimento e controle do share de mercado, controle de expedição e aquisição de produtos, entre outros, auxiliam as empresas e demandam alto poder computacional (ORACLE, 2004). Uma estimativa diz que em 2006 o gasto do mercado neste setor foi de 1,8 bilhões de dólares, a perspectiva aponta para um crescimento exponencial de 24,5 bilhões de dólares em 2011 (INTEL, 2009).

2.7.

Considerações Finais

Essa revisão bibliográfica apresentou os conceitos da Computação em Grade abordando os fatos e as necessidades que motivaram o seu surgimento, mostrando o modelo de arquitetura proposta por seus idealizadores e alguns dos projetos de software no mercado beneficiados por esta tecnologia. No próximo capítulo serão apresentadas algumas ferramentas para acesso a grids disponíveis para a comunidade, bem como a ferramenta do estudo proposto, Ourgrid.

40

3.

TECNOLOGIAS DE COMPUTAÇÃO EM GRADE

Este capítulo descreve alguns projetos de Computação em Grade que empiricamente demonstraram uma facilidade de uso promovendo o acesso para comunidade. Pelo fato dos projetos apresentados abaixo buscarem promover a utilização da Computação em Grade, para tal, estes também simplificam sua implementação e utilização, conseqüentemente, implementam apenas requisitos do conceito de Computação em Grade que os projetos se propõem a atender, ou seja, diferentemente do projeto Globus Toolkit que buscou tornar o conceito realidade, estes se propõem a fazer da Computação em Grade uma alternativa para a computação de auto desempenho, sem grandes investimentos para dentro da realidade de infraestrutura de TI que a maioria das organizações possuem atualmente, sem grandes alterações nos seus paradigmas de desenvolvimento de aplicações e disponibilização de recursos. Este capítulo está organizado da seguinte forma: Seção 3.1 descreve a ferramenta Condor, Seção 3.2 apresenta a ferramenta Alchemi e a Seção 3.3 apresenta a ferramenta usada neste trabalho, Ourgrid.

3.1.

Condor, Hing Troughput Computing

Uma das alternativas para utilização de uma grade computacional está nos serviços oferecidos pelo projeto Condor. As vantagens que salientam este projeto estão pautadas como segue (CONDOR, 2009): a)

Condor se trata de uma arquitetura que disponibiliza a integração com

sistemas de Computação em Grade, oferece recursos como: Distribuição de tarefas, esquema de prioridade, escalonamento, controle de disponibilidade de recursos e mecanismos de tolerância a falhas. b)

Desenvolvido pela Universidade de Wiscolsin Madison EUA, a atuação

em cima deste projeto perdura desde 1988, sem interrupções desde então. A última versão de sua série estável data de nove de novembro de 2009. c)

Várias organizações acreditam nas perspectivas de crescimento deste

projeto. Empresas comerciais como IBM, Intel, Microsoft, AT&T, entre outras.

41

O projeto, também, conta com o apoio do governo norte americano (DoD, DoE, NASA, NSF, NIH). d)

Condor disponibiliza sua tecnologia, open sources, para quaisquer fins,

desde que reconhecida sua fonte. Atuando desde 1988, Condor é um sistema que oferece alto poder computacional. Atualmente, o projeto oferece seus serviços trabalhando num sistema de gestão de carga de trabalho, fornecendo mecanismos de filas de jobs, política de agendamento, gerenciamento de recursos, regime de prioridade e acompanhamento (ANDRADE, 2002). O projeto Condor está focado resolução de ambientes HTC (High Throughput Computing), estes são ambientes onde o poder computacional está fortemente ligado a qualidade

de

pesquisas

acadêmicas.

Condor

trabalha

com

grande

flexibilidade,

disponibilizando recursos para suprir diversas necessidades computacionais, ele gerencia facilmente os trabalhos requisitados como os ofertados, possibilitando respostas em tempo hábil (CONDOR, 2009) (ANDRADE, 2002). Atualmente, o projeto conta com a participação de 28 integrantes. O principal pesquisador do projeto é Miron Livni, presente desde o início do desenvolvimento, doutor em Ciência da Computação do Instituto de Ciência Weizmann e professor de Ciência da Computação da Universidade de Winsconsin Madison (CONDOR, 2009). Diversas versões do software Condor foram desenvolvidas tentando abranger todas as plataformas possíveis. Os maiores focos estavam nas distribuições de Linux e Unix, por ser um sistema operacional free e amplamente usado na área acadêmica, porém, há uma forte pesquisa para oferecer suporte para Windows, agregando todas as funcionalidades comportadas pela versão UNIX. Para Windows ainda há muitas limitações, por exemplo: chamadas de sistema remoto, acesso de arquivo através de compartilhamento de rede, entre outras (CONDOR, 2009). Apesar de haver portabilidade para MAC OS, a própria organização Condor não disponibiliza muitas informações sobre o uso em cima desta plataforma. O manual de instalação da versão mais recente só está disponível para as plataformas UNIX e Windows, referente à última versão lançada, Condor Software v7.2 (CONDOR, 2009). A arquitetura de Condor é uma evolução de um sistema ainda mais antigo, o Remoteunix, desenvolvido em 1986. O Remoteunix já trabalhava com o objetivo de compartilhar recursos remotos. A criação de Condor datada em 1988, e a idéia de compartilhamento de recursos vieram antes da grande difusão dos conceitos da Computação

42

em Grade, adotando uma arquitetura semelhante. Com a evolução da Computação em Grade, Condor se adéqua-se à arquitetura, mas não perde suas peculiaridades. O projeto Condor já agrega em sua história diversas resoluções envolvendo a problemática do alcance do alto desempenho usufruindo de computação paralela remota, oferecendo grande contribuição, não só na disponibilidade de suas tecnologias e serviços, mas também em suas descobertas contribuindo de maneira relevante aos estudos referentes à Computação em Grade (CONDOR, 2009). Condor é um middleware que aproveita os recursos de computadores em idle (Ociosos), em comunhão com um conjunto de estações de trabalho institucional, denota-se Condor Pool. Uma visão básica da arquitetura de um Condor Pool pode ser entendida através da Figura 8 (ANDRADE, 2002):

Figura 8 - Arquitetura de Condor Fonte: Adaptado de ANDRADE, (2002)

Analisando a Figura 8, pode-se observar a presença de um user, este submete suas aplicações através do problem solver para os agentes que, por sua vez, armazena os jobs das aplicações até que se encontre resources (recurso computacional), adequados para executá-los. Os estados dos resources são informados ao matchmaker, responsável por apresentar os resources adequados, requisitados pelo agente. Os matchmaker descobrem resource ociosos, computadores em idle, por exemplo, e os orienta para os jobs adequados. A execução dos jobs dá-se relacionando os resources um shadow, comunicação entre agente e shadow, provendo os detalhes essenciais para a execução dos jobs com eficácia. Um sandbox,

43

comunicação entre resource e sandbox, garante a proteção para que a execução de um job não seja maléfica ao recurso (ANDRADE, 2002). A formação de vários Condors Pool forma um Flock Condor Figura 9:

Figura 9 - Ligação entre Flock Condors

Em Flock Condors são agregados vários Condors Pool, por exemplo, A, B, C, D, E e F, ligados através de dois gateways, um para cada estação institucional. Apesar da possibilidade da agregação de vários Condors Pool, a comunicação é feita sempre dois a dois, considerando o Condor Pool A, suas regras de comunicação seriam estabelecidas ou para B ou para F. Se requisitado um recurso de A para C a comunicação se realizaria de A para B e se as regras de negócio permitissem, seguiria de B para A, ou seja, cada Condor Pool estabelece suas regras para seu par, caso haja a necessidade da busca de um recurso em um Condor Pool mais distante, a solicitação acontece par-a-par até o destino final aonde se encontra o recurso adequado (ANDRADE, 2002).

3.1.1.

Case do Diagrid

Diagrid corresponde a um sistema de Computação em Grade desenvolvido através do sistema Condor. Programado pelas universidades de Winsconsin e CycloServer, o

44

sistema atualmente conta com a participação de nove campus universitários que, até o final de 2008, incluiu mais de vinte mil processadores. Atualmente gerenciado pela Universidade Purdue, Indiana, EUA, este sistema foi eleito como um dos cem projetos de maior destaque do ano de 2009 (INFOWORD, 2009). O motivo está no grande desempenho alcançado por esta grid, aumentando seu potencial total para 177 Teraflops. Através da ferramenta Condor Render, cuja sua finalidade é enviar arquivos de cena do software Maya para reproduzi-los em cima da arquitetura Condor, Hamid Eghbalnia, pesquisador do centro de Biotecnologia da Faculdade Wisconsin, desenvolve estudos em cima de modelos computacionais de poliptídeos. O objetivo é encontrar conformidades estáveis através da renderização destas proteínas. O elevado custo de desempenho para estas renderizações torna a utilização de Condor essencial para o projeto (CONDOR, 2009).

3.2.

Alchemi - Plug & Play Desktop Computação em Grade

Alchemi é um framework open source desenvolvido com o objetivo de agregar o poder computacional de máquinas ligadas em rede para formar, na visão do usuário, um único sistema, ou seja, um supercomputador virtual (ALCHEMI, 2006). Desenvolvido através do projeto GRIDBUS, criado pelo GRIDS Lab (Computação em Grade and Distributed Systems Laboratory), Alchemi é um dos resultados dos estudos relacionados à geração de novas tecnologias de Computação em Grade. Foca não só a área acadêmica, mas facilitar o usufruto da tecnologia para o mercado (LUTHER, 2004). O destaque dado a Alchemi justifica-se nas vantagens descritas a seguir (ALCHEMI, 2006). a)

Para abranger um maior número de usuários, o Alchemi foi

desenvolvido focando facilidade de uso. Possui um executável de instalação e interface gráfica, minimizando a execução de scripts de implantação. b)

Desenvolvido especificamente para plataforma Windows, diferente da

maioria

das

ferramentas

de

Computação

em

Grade,

originalmente

desenvolvidas para Unix e/ou Linux. c)

Suporta integração com Grades Computacionais de outras plataformas

através do componente Cross Platform Manager.

45

d)

Possui interface gráfica para maioria de suas funcionalidades,

apresentando, de maneira clara, informações tais como: monitoramento dos recursos disponíveis e consumidos ou andamento dos jobs em execução. e)

É uma ferramenta gratuita. Sua licença de uso isenta o usuário de

qualquer custo adicional, basta reconhecer sua origem. Originalmente o Alchemi, desenvolvido para DotNet 1.1, é compatível com todas as plataformas Windows que comportem está versão. O projeto Gridbus desenvolveu o Alchemi com o intuito de não preocupar o usuário com configurações complexas, o usuário deve se preocupar com seu negócio, adotando um sistema desktop application de implantação e gerenciamento (LUTHER, 2005). Basicamente a implantação de um sistema de grid institucional em Alchemi dá-se em duas etapas: instalação do componente Alchemi Maneger, instalado como Desktop Appllication ou Windows Service. Este é o gerenciador da grid, os Alchemi Executors, instalado em cada máquina, agrega os nós à grid (ALCHEMI, 2006). Uma visão mais detalhada destes componentes, assim como a arquitetura funcional de Alchemi é apresentada como segue. A Figura 10 mostra os componentes básicos da arquitetura funcional de Alchemi, apresentando interação entre os componentes (ALCHEMI, 2006):

Figura 10 - Componentes de Alchemi Fonte: ALCHEMI, (2006)

46

a)

Alchemi API: Implementada pela biblioteca Alchemi. Core.dll, esta API

é composta de dois tipos de objetos: a. Grid Application: gerencia a aplicação e envia seu jobs aos recursos remotos; b. Grid thread: São os jobs que se comportam como uma thread, porém não existe a possibilidade da comunicação entre eles. b)

Alchemi Tools: São ferramentas de desenvolvimento de aplicações para

que sejam executadas em grid. São as ferramentas que compõem o framework com o objetivo de proporcionar ao usuário, o controle e monitoramento de um nó pertencente à grid; c)

Alchemi User: Implicitamente criado pela API, fornece serviços

associados a uma aplicação; d)

Alchemi Manager: Responsável por gerenciar os recursos e jobs,

relacionando-os para execução do trabalho; e)

Alchemi executors: Este é o componente responsável por agregar nós à

Alchemi Grid. Deve ser instalado em cada máquina e configurado para conectar-se a um Alchemi Manager. O Alchemi Executor fornece serviços associados a threads. Como citado, para a formação de uma Alchemi Grid, instala-se componentes Executor em cada nó, pertencente à grid, a um Manager, porém há a possibilidade de conectar diversas Grades Alchemi, sem limite de extensão, como apresentado na Figura 11 (ALCHEMI, 2006):

47

Figura 11 - Implantação de rede multi nível e de plataforma cruzada

O framework Alchemi oferece suporte para acoplar-se a outras tecnologias de grids, este serviço é oferecido pelo componente Cross Plataform Manager.

3.2.1.

Case do CSIRO

CSIRO Austrália: Modelação de Recursos Naturais. Desenvolvido na plataforma Microsoft DotNET, CSIRO Land ans Water, instituição focada a conservação da água na Austrália, desenvolveu um sistema chamado TEMPO. Esta é uma aplicação com o propósito de criar modelos de ambiente, no caso, referentes às hidrografias do país. Para execução desta aplicação o Alchemi foi à solução para a implantação de uma grade computacional com condições de suprir a demanda computacional do sistema (CSIRO, 2009).

3.3.

Ourgrid: A Ferramenda Escolhida para o Estudo de Caso

A escolha da ferramenta Ourgrid dá-se ao conhecimento prévio empírico dos autores do trabalho, o escopo deste trabalho não abrange o julgamento da melhor ferramenta para o uso de Computação em Grade.

48

O Ourgrid é um projeto de uma grid comunitária open-source (distribuído sob a GPL (General Public License), desenvolvido e atualizado pelo LSD/UFCG (Laboratório de Sistemas Distribuídos da Universidade Federal de Campina Grande, Brasil) e apoiado pela HP (Hewlett-Packard). O projeto consiste no desenvolvimento de um middleware o Mygrid, agora denotado como broker, e um conjunto de componentes que lhe proporcione acesso a rede e segurança para a criação de uma grade computacional (OURGRID, 2010). A construção do middlware Ourgrid foi motivada pelo fato de que, embora bastante pesquisa tenha sido realizada para o desenvolvimento das Grades Computacionais, poucos usuários desenvolviam suas aplicações paralelas para esse paradigma devido à grande a complexidade dos projetos até então existentes, como o caso Globus Toolkit . Com o intuíto de simplificar a utilização deste paradigma, o projeto focou apenas a execução segura de aplicações

bag of tasks, que são aplicações cujas tarefas são independentes, e podem ser

executadas em qualquer ordem. A grande aposta em aplicações bag of tasks é devido a sua alta compatibilidade, a ampla distribuição, heterogeneidade e dinamicidade, proporcionados pelo ambiente de uma grade computacional (ANDRADE, 2003). Desde o seu lançamento, em dezembro de 2004, o Ourgrid tem sido usado por centenas de usuários para acelerar a execução de tarefas que demandam alta capacidade de processamento. O modelo de aplicação que é possível executar no Ourgrid resolve várias problemas atuais, tais como, mineração de dados, processamento genômico, pesquisa massiva (como quebra de chaves criptográficas), algoritmos de otimização, computação de fractais (como Mandelbrot), e manipulação de imagem (como tomografia). O Ourgrid é um projeto de implementação de uma grade computacional desenvolvido em Java, permitindo que ele seja implantado em qualquer plataforma que a Java Virtual Machine 1.5.0 ou superior tenha suporte (OURGRID, 2010). A ferramenta Ourgrid é composta por quatro principais componentes: Mygrid ou atualmente conhecido como Broker, Ourgrid Peer, o Worker e o sistema de segurança SWAN. A Figura 12 ilustra como esses componentes interagem entre si.

49

Figura 12 - Ilustração da arquitetura de Ourgrid Fonte: OURGRID, (2010)

O Ourgrid Broker é o componente central do Ourgrid. Ele é responsável por permitir que os usuários da grid gerenciem os recursos que estão disponibilizando para grid e fornece todo o suporte necessário para os usuários da grade submeterem, descreverem, executarem e acompanharem as aplicações submetidas à grid por seus usuários. Por ter um papel central na grid, por disponibilizar ferramentas para que a máquina local realize as tarefas de busca de recursos, monitoramento e execução das aplicações, ele também é responsável por prover um ambiente descentralizado à grid permitindo que esta execute diversos jobs simultaneamente (OURGRID, 2010). O Ourgrid Peer trabalha como um servidor de acesso a recursos externos da grid, ele funciona como uma espécie de gateway de rede, que é responsável por agrupar recursos de uma LAN, e disponibilizá-los a usuários ligados a outros Peer’s, como também dar acesso a recursos agrupados por outros Peer’s a seus usuários. O componente de segurança SWAN é uma solução baseada em máquinas virtuais Xen (CIRNE, 2005) que funciona como um sandbox (zona de segurança) que protege uma máquina provedora de recursos contra execução de códigos maliciosos, isolando os códigos desconhecidos dentro da sandbox. Desta forma, as tarefas da grid, que são executadas em uma máquina, não podem danificá-la ou utilizar sua conexão de rede de maneira indevida.

50

O Ourgrid Worker é o executor dos job submetidos á grid, ele é gerenciado por um OurGrid Peer e possui informações sobre a plataforma em que está operando, desta forma quando um OurGrid Peer recebe um conjunto de tasks (tarefas), de um job, para serem executadas, o OurGrid Peer avalia as informações dos workers que gerencia e atribui a estes as tasks que lhe cabem, os workers por sua vez executam as tasks que recebem e retornam o resultado obtido.

3.3.1.

Cases do OurGrid

Um projeto interessante que utiliza o Ourgrid visa à construção de um sistema de apoio sustentável para os recursos hídricos no Nordeste do Brasil. O Ourgrid foi usado para fornecer uma infraestrutura de grade computacional para execução de um conjunto de aplicações necessárias para a previsão da quantidade de água que estará disponível na região, e um plano de como usá-la. As pessoas que apoiam o projeto estão construindo um portal na WEB para tornar essas aplicações facilmente disponíveis aos profissionais da área e acadêmicos. Instituições interdisciplinares governamentais e profissionais acadêmicos estão empenhadas em trazer o projeto SegHidro para a realidade (OURGRID, 2010). O projeto usa a grid para ajudar os usuários a simular uma cascata de modelos meteorológicos e hidrológicos. Estes modelos são utilizados para ajudar o governo a tomar melhores decisões para o desenvolvimento sustentável do país. Desta forma, será possível, por exemplo, decidir que tipo de método agrícola se adequada melhor ao clima da região, e que quantidade de água estará disponível no ano seguinte. Isso é fundamental em regiões do Brasil atingidas pela seca, nas quais a falta de planejamento trouxe sofrimento desnecessário a um número enorme de pessoas. O projeto é financiado pelo ministério brasileiro de Ciência e Tecnologia. Outro case de sucesso é a aplicação GerPav usada em Porto Alegre, no sul do Brasil. Com a finalidade de melhorar a gestão da manutenção e planejamento de investimentos no sistema viário da cidade. O Ourgrid foi utilizado para criar uma grade computacional que permitisse a execução do software. A otimização de estratégias diversas foram desenvolvidas no ponto de aplicações seqüenciais para resolver os gargalos de desempenho e facilitar a distribuição de tarefas dentro da grid. A tecnologia de Computação em Grade trouxe ganhos substanciais de desempenho para a versão distribuída do projeto

51

Gerpav, mostrando que uma infraestrutura de rede simples com utilização da grid pode proporcionar um ambiente com um poder computacional atrativo para execução de aplicações deste tipo (STORCH, 2006). Outro projeto interessante que utiliza o Ourgrid é o GridUnit, que visa utilizar a grid para ampliar e agilizar a execução de rotinas para teste de software. Com a concorrência no mercado de desenvolvimento de software aumentando cada vez mais atualmente, e o tempo de entrega do software sendo um grande diferencial para as empresas do ramo, como resultado, o tempo necessário para executar as rotinas de testes necessárias tornam-se um problema para as empresas desenvolvedoras de software, sendo extremamente importante a rapidez e eficácia dos testes, pois esses projetos exigem um breve desenvolvimento e ciclo de testes. Além disso, devido à crescente complexidade dos sistemas, não é suficiente testar o software somente no ambiente de desenvolvimento, é preciso testálos em uma variedade de ambientes. O projeto GridUnit representa a primeira tentativa de explorar o paradigma da Computação em Grade para acelerar o processo de teste de software (OURGRID, 2010). Este capítulo explanou sobre alguns projetos de Computação em Grade que têm o compromisso de trazer para nossa realidade, de infraestrutura de TI, esta plataforma como uma opção viável e mais econômica, para a computação de alto desempenho. Foram apresentadas as principais características das ferramentas Condor, Alchemi e a usada neste trabalho, o OurGrid.

52

4.

TESTES DE DESEMPENHO PARA UMA GRID LOCAL UTILIZANDO O MIDDLEWARE OURGRID

Neste capítulo será apresentada a execução de uma aplicação

bag of tasks,

comparando os desempenhos entre uma grid departamental utilizando o middlerare Ourgrid e um computador fora da grid. O objetivo está em determinar um número de nós agregados à grid que execute a aplicação, com um desempenho satisfatoriamente superior ao resultado da execução da mesma aplicação em um computador local, assim como também analisar o comportamento da grid a cada nó agregado à sua malha. O capítulo está organizado como segue: a Seção 4.1 apresenta o cenário construído para execução do teste, assim como a implantação da grid departamental. A Seção 4.2 apresenta o desenvolvimento do teste enquanto a Seção 4.3 apresenta a execução e a análise dos testes.

4.1.

Apresentação do Cenário de Teste

Esta seção apresentará as fases para formalização do ambiente de testes. Serão apresentadas as seguintes etapas: pré-requisitos para instalação, instalação e as configurações necessárias para a implantação de uma grid departamental utilizando o middleware Ourgrid. As informações estão de acordo com as descritas na comunidade do OURGRID, (2010), apresentando todas as peculiaridades da construção do cenário de teste.

4.1.1.

Ambiente de Implantação

Para composição do ambiente de teste foram escolhidos seis computadores do laboratório de informática da FATEC-SJC (Faculdade de Tecnologia de São José dos Campos). Estes computadores são interligados por uma rede local em um grupo de trabalho configurado no Windows XP Professional SP2. A configuração dos computadores e as especificações da rede são:

53

a)

Configuração dos computadores: i. Placa mãe: Barramento de 800GHZ; ii. Processador: Intel core 2 duo E7400; iii. Memória cache: 2MB L2; iv. Memória RAM: Dois pentes de 1GB DDR2 533MHZ; v. Sistema Operacional: Windows XP Service Pack dois;

b)

Especificações da rede: i. Placa de rede: Fast Enthernet; ii. Switch: 24 portas; iii. Cabos: Par trançado sem blindagem categoria seis; iv. Conectores: RJ45; v. Velocidade de 100MB / 1GB

Para atender a um dos pré-requisitos do middleware Ourgrid, foi instalado em cada computador a virtual machine JVM (Java Runtime Machine 1.6). Informações sobre a instalação e configuração da JVM podem ser encontradas em: (http://www.java.com/pt_BR/).

4.1.2.

Pré-Requisitos para Construção da Grid

Para a implantação de uma grid departamental utilizando o middleware Ourgrid faz-se necessário a aquisição dos componentes de software que compões o middleware: O OurGrid broker, OurGrid peer e OurGrid worker. Estes componentes podem ser adquiridos em OURGRID, (2010), e o servidor XMPP OpenFire que permite a comunicação entre os componente da grid. Para o desenvolvimento de uma grid departamental, utilizando o middleware OurGrid, primeiramente foi analisado quais eram os elementos básicos para sua utilização, os requisitos míninos necessários para execução de cada componente, assim como as plataformas suportadas pelos componentes. A Tabela 2 apresenta os resultados da análise das especificações de cada um dos componentes necessários para compor o middleware OurGrid:

54

DESENVOLVEDOR

PLATAFORMAS SUPORTADAS

OPENFIRE SERVER

Jive Sofware

Linux, Unix, Mac OS X ou Windows

Versão 1.5 ou superior

PEER

Ourgrid Community

Linux ou Windows

Versão 1.5 ou superior

512mb de memória RAM e 200mb de espaço em disco. 25mb de espaço em disco

BROKER

Ourgrid Community

Linux ou Windows

Versão 1.5 ou superior

25mb de espaço em disco

WORKER

Ourgrid Community

Linux ou Windows

Versão 1.5 ou superior

25mb de espaço em disco

SOFTWARE

JAVA RUNTIME MACHINE

REQUISITOS MÍNIMOS

Tabela 2 - Informações e pré-requisitos dos componentes do middleware Ourgrid

4.1.3.

Openfire Server

Para estabelecer a comunicação entre os componentes do Ourgrid a partir da versão 4.0 faz se necessário a utilização de um servidor XMPP (Extensible Messaging and Presence Protocol), nas versões anteriores a comunicação entre os componentes era efetuada através de RMI (Remote Method Invocation). Existem diversos servidores XMPP open source na internet. Para execução deste teste foi escolhido o servidor Openfire (http://www.igniterealtime.org) em sua versão 3.6.4, utilizado um pacote de instalação executável que inclui também a JRE (Java Runtime Environment). O servidor Openfire foi instalado em um dos computadores descritos na Seção 4.1.1, que assumiu o papel de servidor de comunicação. As portas liberadas para o uso deste serviço foram as 5222, 5223 e 5269. Para execução do OpenFire Server, após iniciado o arquivo de instalação, deve-se aguardar até o momento em que o servidor seja iniciado, Figura 13. A opção Launch Admin acessa o painel administrativo, usado para a configuração do servidor. O painel administrativo também pode ser acessado via browser através do endereço http://127.0.0.1: 9090/.

55

Figura 13 - Interface gráfica do Openfire Server com o Serviço Iniciado

O primeiro acesso ao painel administrativo do Openfire Server exibe uma página de configurações iniciais conforme visto na Figura 14. As configurações são executadas na sequência apresentada como segue: a)

Language settings: Nesta etapa foi definido o idioma de preferência,

escolhido o idioma English, idioma recomendado para o middleware Ourgrid; b)

Server settings: Nesta etapa foi definido o computador de domínio. Foi

inserido no campo descrito como Domain o endereço IP (Internet Protocol) do computador, porém poderia ser fornecido simplesmente o nome pelo qual o computador é reconhecido na rede; c)

Database settings: Nesta etapa foi definido se será utilizado o banco de

dados HSQLDB (Hyper Structured Language Query Database), incluído no pacote de instalação, ou outro database. Habilitou-se a opção Embedded database, e determinado como banco de dados o HSQLDB; d)

Profile settings: Nesta etapa definiram-se as configurações de perfil.

Neste caso a opção habilitada foi a Default; e)

Administrator account: Nesta etapa definiu-se o usuário administrador

do sistema, este terá acesso exclusivo ao painel administrativo do servidor.

56

Figura 14 - Interface gráfica do painel de Configurações iniciais do Openfire Server

Ao término destas atividades, fecha-se a janela do browser com o painel de configurações iniciais e o servidor deve ser reiniciado. Para reiniciá-lo, basta cancelar sua execução com o botão Stop, na janela Openfire Figura 13 e reiniciar sua execução clicando no botão Start. Abre-se novamente o painel administrativo do servidor. Agora será exibida a página de acesso solicitando um nome de usuário e uma senha. No campo login deve-se inserir o nome de usuário padrão „admin‟, no campo senha, deve-se informar a senha que foi cadastrada na etapa Admin Account, na página de configurações iniciais do servidor. Caso ocorra algum problema nas configurações iniciais do servidor e seja necessário repeti-las, o diretório de instalação do Openfire Server deve ser acessado, e localizado na pasta Openfire> Conf o arquivo openfire.xml é usado para reiniciar as configurações iniciais. Dentro deste arquivo o texto - true - deverá ser apagado, o servidor reiniciado e é apresentada novamente a página de configurações iniciais do painel administrativo. As seguintes atividades deverão ser executadas no painel administrativo do servidor Openfire Figura 15, para que este possibilite a comunicação entre os componentes do middleware Ourgrid:

57

Figura 15 - Interface gráfica do painel administrativo do Openfire Server

a)

Na opção System Propertie’s da aba Server Manager menu Server:

Adicionou-se uma nova propriedade: Para o campo Property Name foi adicionado o seguinte texto: “xmpp.server.certificate.verify”. Em seguida, no campo Property Value, foi adicionado o texto: „false‟. Para confirmar a adição desta propriedade, bastou selecionar o botão Save Property. b)

Na opção Server to Server da aba Server Settings menu Server: Foi

assegurada a habilitação do serviço. Em Service Enable, opção Enabled, foi inserido o valor padrão de porta utilizado para a comunicação entre os servidores, 5269. O botão Save Settings confirma estas configurações. c)

Na opção Registration & Login da aba Server Settings menu Server: É

recomendado que a opção Inband Account Registration seja desabilitada após a instalação dos componentes do middleware Ourgrid, pois ela permite que qualquer usuário do servidor possa criar contas automaticamente. Caso esta opção seja desabilitada, a criação dos usuários para cada componente do middleware Ourgrid deverá ser efetuada manualmente por meio da opção Create New User na aba Users menu Users/Groups. Em Change Password, foi

58

selecionada a opção Disabled, assim como em Anonymous Login. O botão Save Settings efetua estas configurações. d)

Na opção Resource policy da aba Server Manager menu Server: Na

seção Resource Policy foi selecionada Never kick e ativado novamente Save Settings para salvar as configurações efetuadas. e)

Na opção Offline messages da aba Server Manager menu Server: Na

seção Offline Messages foi escolhida a opção „Drop’. O botão Save Settings foi confirmado para salvar esta configuração. f)

Na opção Security Settings na aba Server Settings menu Server: Na

seção Client Connection Security foi selecionada a opção Custom e nas duas subseções marcada a opção Not Available. Em Server Connection Security a opção Optional foi selecionada. O botão Save Settings efetua estas configurações. g)

No restante das opções de configuração foram utilizados os valores

padrão. Finalizadas estas configurações, o Openfire Server está pronto para ser utilizado pelos componentes do middleware Ourgrid.

4.1.4.

OurGrid peer

Nesta seção serão apresentados os passos para instalação e configuração do componente peer do middleware Ourgrid. Uma vez de posse do arquivo correspondente ao componente peer, basta executá-lo. Este pode ser executado em qualquer pasta conforme a preferência do usuário. Neste caso, o arquivo peer.bat foi executado na raiz – C:\. Exibida a janela com interface gráfica do peer, Figura 16, utilizada para a configuração do componente; os passos a serem seguidos para configuração do OurGrid peer são: a)

Configurações da aba „XMPP Configuration’: Nos campos „XMPP

User Name’ e „XMPP User Password’ devem ser informados o nome de usuário e senha utilizados pelo componente peer para a conexão com o Openfire Server. Caso a opção de configuração „Inband Account Registration’ do Openfire Sever esteja desabilitada é necessário criar um usuário e uma

59

senha para que o componente peer possa se comunicar com o restante dos componentes do Ourgrid. Caso contrário, o usuário e a senha informados serão utilizados para efetuar o cadastro no servidor automaticamente na primeira tentativa de conexão com o Openfire Server. Na seção „XMPP Server‟ no campo „XMPP Server Name’ deve ser informado o nome do computador ou endereço de IP (Internet Protocol) do computador com o Openfire Server instalado, nos campos Server Port e Secury Port devem ser informadas as portas de comunicação do sistema operacional, utilizadas para comunicação de rede do Openfire Server, caso não tenham ocorrido mudanças, das portas na instalação do servidor, o valor padrão do componente peer não precisa ser alterado. Um teste de conexão pode ser feito clicando no botão Test Connection, se conectado, será exibida uma mensagem informando que o peer foi conectado com sucesso, e clique no botão Save para salvar as configurações efetuadas. b)

Configurações da aba peer Configuration: Na aba Basic na seção Basic

Settings no campo Label deve ser informado o nome do seu peer, no campo Description deve ser informada uma pequena descrição do peer, por exemplo, peer Fatec-Sjc utilizado para TG do Urias e Rafael Salgado, no campo Adm. No campo email deve ser informado o email do responsável pela administração do peer e para finalizar estas ações basta acionar o botão Save para salvar as configurações. A seção Discovery Service Settings é utilizada para a integração do site a um ou mais sites existentes do middleware Ourgrid, não abordada neste estudo de caso.

60

Figura 16 - Interface gráfica do componente peer

No restante das opções de configuração são utilizados os valores padrões. Finalizadas as configurações citadas, o peer será integrado ao site do middleware Ourgrid.

4.1.5.

OurGrid worker

Nesta Seção apresentaremos os passos para instalação e configuração do componente worker do middlewear Ourgrid. O arquivo worker.bat pode ser executado em qualquer local do computador. Neste caso, ele foi executado na raiz do sistema. A seguir são descrito os passos para a configuração do componente worker do middlewear Ourgrid: Configurações da aba „XMPP Configuration’: As configurações desta aba são idênticas às configurações da aba homônima do componente peer, só deve ser atentado ao fato da criação de uma conta, nome de usuário e senha, para cada um dos workers utilizados no site, Figura 17.

61

Figura 17 - Janela com a interface gráfica do componente worker

No restante das opções de configuração são utilizados os valores padrões. Ao término das atividades, o componente worker está pronto ser integrado ao site do middleware Ourgrid.

4.1.6.

OurGrid broker

Nesta Seção são apresentados os passos para instalação e configuração do componente broker do middleware Ourgrid. O arquivo broker.bat pode ser executado em qualquer local do computador e por meio de sua execução e possível acessar a janela com a interface gráfica do componente broker, Figura 18. Neste caso, ele foi executado na raiz do sistema. A seguir são descrito os passos para a configuração do componente broker. A seguir são descritos os passos para a configuração do componente broker:

62

Configurações da aba Settings, na aba Basic, às configurações são idênticas as configurações da aba XMPP Configuration do componente peer, atentando-se ao fato de que é recomendada a criação de uma conta, nome de usuário e senha, no Openfire Server específica para cada usuário que for utilizar o componente broker.

Figura 18 - Janela de interface gráfica do componente broker

No restante das opções de configuração são utilizados os valores padrões. Ao término das atividades o componente broker está pronto ser integrado ao site do middleware Ourgrid.

63

4.1.7.

Integração entre Worker e Peer

Para que workers possam ser integrados a um peer, é necessário informar ao worker o peer que o gerenciará e vice-versa. Para informar a um worker o peer que o gerenciará, é necessário utilizar a chave pública do peer. Esta deve ser informada na seção Keys Settings no campo Peer Public Key da janela com de interface gráfica do worker. A chave pode ser importada clicando no Load. Será exibida uma janela de diálogo utilizada para navegar entre os diretórios do computador e da rede, por ela deve se navegar até o diretório em que o componente peer do Ourgrid instalado. Posteriormente, deve ser selecionado o arquivo peer.properties e ativado o botão Open ou Abrir, dependendo da língua utilizada pelo seu sistema operacional, que chave será preenchida no campo. Outra opção é informar manualmente a chave no campo e acionar o botão Save para salvar as alterações efetuadas. Existem duas maneiras para informar a um peer os workers que ele gerenciará, uma destas é adicioná-los um a um pela interface gráfica do peer e a outra é por meio da criação de um arquivo SDF (Site Descriptor File) que, após ser criado, deve ser importado pela interface gráfica do peer. Mas para ambas as possibilidades é necessário iniciar o peer clicando no link start na seção Control da janela que contém a interface gráfica do peer Figura 16. Para integrar workers um a um utilizando a interface gráfica do peer, clicar no link Add worker, localizado na seção workers à esquerda da janela. É exibida a janela Add worker mostrada na Figura 19, na qual deve-se informar o nome de usuário utilizado pelo worker, no campo User, e o nome ou o endereço IP do computador que possui o Openfire Server instalado, no campo Server, clicar no botão Ok para confirmar a integração do worker.

64

Figura 19 - Janela para integrar wokers manualmente a um peer

Para integrar workers a um peer utilizando o arquivo SDF, é necessário criar um arquivo, como o exemplo mostrado na Figura 20, em um editor de texto qualquer e salválo com a extensão „sdf‟.

65

Figura 20 - Arquivo SDF (Site Description File)

A estrutura principal do arquivo consiste na propriedade workerdefaults, utilizada para adicionar sub-propriedades padrões para todos os workers , e na propriedade worker, utilizada para informar as sub-propriedades específicas de cada worker. A Tabela 3 mostra as principais sub-propriedades utilizadas no arquivo, uma pequena descrição delas e se elas são obrigatórias no arquivo:

66

PROPRIEDADE

DESCRIÇÃO

OBRIGATÓRIO?

OS

Utilizada para indicar o sistema operacional do worker.

não

SITE

Utilizada para informar o nome do site que o worker está localizado.

*

USERNAME

Utilizada para informar o nome de usuário da conta do Openfire Server utilizada pelo worker.

sim

SERVER NAME

Utilizado para informar o nome ou o endereço IP do computador que possuí o Openfire Server instalado.

sim

COPYTO

Utilizado para informar ao peer o local e com que nome os arquivos que serão usados pelo worker para execução das tarefas devem ser copiados.

não

REMEXEC

Utilizado para informar ao peer o valor padrão do comando para executar os arquivos de uma tarefa no worker

não

COPYFROM

Utilizado para informar ao peer o local e com que nome os arquivos de resultados da execução das tarefas submetidas ao worker devem ser copiados.

não

Tabela 3 - Principais sub-propriedades do arquivo SDF

Criando o arquivo SDF, é necessário importá-lo para que o peer integre os workers descritos no arquivo. Na interface gráfica do peer conforme Figura 16, seção workers, clicar no link Import workes from file, será exibida uma janela de diálogo utilizada para navegar entre os diretórios do computador e da rede, por ela deve se navegar até o arquivo SDF, selecioná-lo e clicar no botão Open. Os workers descritos no arquivo serão integrados ao peer. Para visualizar os workers que estão integrados ao peer, clicar na aba Workes da interface gráfica do peer.

4.1.8.

Integração entre Broker e Peer

Para se integrar um broker a um peer, é necessário informar os usuários do broker que poderão acessar o peer e informar ao broker os peers que ele tem acesso por meio do arquivo GDF (Grid Description File). Essas tarefas são possíveis apenas após o peer e broker serem inicializados clicando-se no link start na seção Control da janela que contém a interface gráfica do peer, conforme Figura 16, e na seção Main Action da janela que contém a interface gráfica do broker.

67

Para informar ao peer os usuários do broker que poderão acessá-lo clique no link Add peer user na janela com a interface gráfica do peer, será exibida a janela Add User Figura 21, na qual devemos informar o nome de usuário utilizado pelo usuário do broker, no campo Name, a senha, no campo Password e Retype Password, o nome ou o endereço IP do computador que possuí o Openfire Server instalado, no campo Server, e clicar no botão Add para salvar as informações do usuário.

Figura 21 - Janela Add User

Para informar ao broker os peers que ele acessa é necessário criar o arquivo GDF como o exemplo mostrado na Figura 22 em um editor de texto qualquer e salvá-lo com a extensão „gdf‟. Um arquivo GDF pode conter um ou mais peers, as propriedades „username‟ e „servername’ do arquivo devem ter os mesmos dados da conta criada para o peer no Openfire Server.

68

Figura 22 - Arquivo GDF (Grid Description File)

Criado o arquivo GDF com os peers que serão integrados ao broker, é necessário importá-lo. Na janela com a interface gráfica do broker clicar no link Set grid, será exibida uma janela de diálogo utilizada para navegar entre os diretórios do computador e da rede, por ela deve se navegar até o arquivo GDF, selecioná-lo e clicar no botão Open. Os peers descritos no arquivo serão integrados ao broker. Para visualizar os peers integrados ao broker clique na peers na janela com a interface gráfica do broker. Depois de efetuada a integração dos componentes como descrito acima, a grid está pronta para ser utilizada.

4.1.9.

Construindo e Submetendo Jobs Para o Middleware Ourgrid

Nesta seção será apresentado como construir e submeter jobs ao middleware Ourgrid. Para construir um job, é necessário criar um programa em uma linguagem suportada pelo nó trabalhador (worker), criar seu arquivo de descrição JDF (Job Description File) e depois importá-lo para a grid. Nas seguintes subseções será detalhada cada uma destas etapas.

4.1.9.1.

Criando Um Programa para Execução no Worker

O programa criado para ser executado no Ourgrid pode ser escrito em qualquer linguagem desde que essa linguagem seja suportada pelo nó trabalhador, como o próprio middleware Ourgrid é desenvolvido em Java, qualquer programa escrito em Java e compilado

69

em uma versão da JRE compatível com a versão necessária para usar o componente worker será executado. O programa pode utilizar como fonte de dados arquivos de entrada, de saída, argumentos passados via linha de comando e até mesmo um servidor de banco de dados, desde que o nó trabalhador tenha como estabelecer uma conexão com o banco.

4.1.9.2.

Criando o Arquivo JDF (Job Description File)

O middleware Ourgrid recebe informações através de um arquivo de descrição de um job, o JDF. Um job possui um conjunto de tarefas (tasks), estas que serão executadas de forma distribuída nos workers da grid. Cada arquivo JDF descreve um único job. Pode-se editar um JDF em um editor de texto qualquer e o arquivo gerado deve ser salvo como a extensão “jdf”. Um arquivo JDF tem duas principais propriedades na sua estrutura: A propriedade job e a propriedade task. A primeira é usada para especificar os atributos comuns de todas as tasks do job e outra para especificar atributos específicos e os comandos das tarefas que compõem a sua aplicação grid-enable. A propriedade job contém uma lista (pode ser vazia) de sub-propriedades. Essas sub-propriedades incluem a lista de requisitos que precisam ser preenchidas por um nó trabalhador worker, de modo que ele pode ser selecionado para executar as tarefas tasks do trabalho, e um nome para o job. Esta sub-propriedade é útil para monitorar a execução do trabalho e também para associar o nome dos arquivos de saída com o job que os gerou. A Tabela 4 a seguir apresenta as principais sub-propriedades da propriedade job. A Figura 23 ilustra a utilização destas sub-propriedades em um arquivo JDF:

SUB-PROPRIEDADE

DESCRIÇÃO

LABEL

Identificação do job Requisitos necessários para a execução das tarefas

REQUIREMENTS

Tabela 4 - Descrição das sub-propriedades de um job

70

Figura 23 - Utilização das sub-propriedades da propriedade job

As sub-propriedades para execução das tarefas, como remote, Figura 23, podem ser utilizadas na propriedade job caso essas sejam idênticas em todas as tarefas de um job. No arquivo de descrição de um job há uma propriedade task para cada tarefa, consequentemente, o número de tarefas em um job é determinado pelo número de propriedades task no arquivo JDF. A propriedade task descreve todas as fases de uma tarefa. Uma tarefa é divida em três fases - init, remote e final - e cada uma delas possui seus próprios comandos. A Figura 24 ilustra um exemplo de uma JDF com a utilização das propriedade task e a Tabela 5 descreve as três fases de uma tarefa e apresenta os possíveis comandos de cada uma destas fases.

FASE

INIT

DESCRIÇÃO

Utilizada para indicar os arquivos que serão enviados ao nó trabalhador (worker)

REMOTE

Utilizada para definir e executar o comando que inicia a execução da tarefa no nó trabalhador (worker)

FINAL

Utilizada para indicar os arquivos que serão trazidos de volta a máquina local após a execução da tarefa

COMANDO

DESCRIÇÃO

put

Indica quais arquivos precisam ser transferidos para o nó trabalhador (worker) antes da execução da tarefa

store

Idêntico ao put, mas verifica se o arquivo já existe

Linha de comando do shell (Linux), prompt (windows)

Utilizada para executar e passar os argumentos necessários do programa responsável pela tarefa

get

Indica quais arquivos precisam ser trazidos de volta do nó trabalhador (worker) depois da execução.

store

Idêntico ao put, mas verifica se o arquivo já existe

Tabela 5 - Fases e comandos da propriedade task

71

O middleware Ourgrid automaticamente define variáveis de ambiente $JOB, $TASK, $PROC, $PLAYPEN e $STORAGE e elas respectivamente possuem um único número de um job, um único número para uma task, o nó trabalhador selecionado para executar a task, o nome do diretório criado para execução da task e o nome do diretório criado para armazenamento dos arquivos das tarefas. Essas variáveis são comumente utilizadas para definir nomes únicos para os arquivos de entrada e saída da task, Figura 24.

Figura 24 - Exemplo de JDF utilizando suas propriedades e variáveis de ambiente

Com um grande número de tarefas em um arquivo, a utilização das variáveis de ambiente é útil para evitar que as tarefas que compõem o trabalho produzam uma saída com o mesmo nome. Propriedades do nó trabalhador são definidas no arquivo SDF pelo usuário que expressam as características do nó trabalhador. Eles podem ser usados para definir os requisitos de trabalho. E os requisitos que uma task necessita para executar em um nó trabalhador são testados de acordo com tais propriedades de expressões. No arquivo de descrição de um job a criação do teste que envolve essas propriedades pode utilizar as expressões aritméticas mais comuns e operadores lógicos. Operadores com maior precedência são avaliados antes dos operadores com menor precedência. Avaliação dos operadores com a mesma precedência é da esquerda para a direita. Esta ordem de avaliação pode ser alterada usando parênteses. A Tabela 6 mostra os operadores lógicos e aritméticos suportados pelo JDF para o teste de requisitos e execução de uma tarefa em um worker:

72

OPERADOR

DESCRIÇÃO

EXEMPLO

!

Negação lógica

!(os = linux)

NOT

Negação lógica

NOT(site = lsd)

&&

E lógico

(os = windows && site = Fatec)

AND

E lógico

(os = windows AND mem> 200)

||

Ou lógico

(os = window || os = linux)

OR

Ou lógico

(site = fatec OR site = lsd)

<

Menor que

mem

Maior que

mem> 300

= 30

==

Igual

os == windows

=

Igual

os = windows

!=

Diferente

os != linux

Tabela 6 - Operadores lógicos e aritméticos suportados pelo JDF

4.1.9.3.

Submetendo um Job para Execução no Middleware Ourgrid

Para submeter um job à grid é utilizada a janela com a interface gráfica do broker. Na seção Job Actions clique no link Add job, será exibida uma janela de dialogo utilizada para navegar entre os diretórios do computador e da rede, por ela deve se navegar até a pasta que possui os arquivos de cada tarefa e o arquivo JDF, selecionar o JDF e clicar no botão Open e o job será carregado para execução no middleware Ourgrid.

4.2.

Desenvolvimento dos Testes

Primeiramente foi desenvolvida uma aplicação que calcula os números primos de um (01) até um número limite passado pelo usuário. Este cálculo é realizado cinco vezes. Esta funcionalidade torna-se secundaria uma vez que o objetivo desta aplicação esta simplesmente no consumo de ciclos de CPU e demonstrar, de forma menos complexa, a divisão de um algoritmo em tasks (tarefas), para melhor compreensão do leitor. Os métodos para um cálculo mais preciso referente à funcionalidade cujo trabalho discrimina como secundaria foge ao escopo deste estudo de caso. O objetivo da análise está em observar o

73

ganho de desempenho a cada nó inserido a grid, executando a aplicação de forma adaptada para este ambiente, em comparação com os resultados obtidos na execução da aplicação em um computador local, fora da grid. A aplicação desenvolvida para execução em um computador local foi denominada PrimosLocal. Posteriormente a aplicação foi desmembrada em uma nova aplicação, correspondente a uma tarefa. Em seguida desenvolveu-se um job para execução em grid, agregando cada uma destas tarefas, cada tarefa executa um dos cinco cálculos. Em seguida foi analisado o desempenho da grid agregando-lhe de um a cinco nós, realizando uma nova execução do job para cada nó adicionado a grid. O objetivo foi analisar o ganho de desempenho no acréscimo de nós a grid. Por fim foi realizado um comparativo entre os resultados obtidos nos testes a cada nó acrescido a grid com o tempo de execução da aplicação PrimosLocal no computador local. Esta análise teve por objetivo constatar quantos nós seriam necessários a grid para um ganho de desempenho satisfatório relacionado a um único computador fora da grid. Para o cálculo dos dados obtidos foi usada à ferramenta Microsoft Excel, presente no pacote Microsoft Office 2007.

4.2.1.

Algoritmo de Execução em Um Computador Local

Esta Seção apresenta a lógica do algoritmo desenvolvido para aplicação executada em um computador local. Este algoritmo efetua o calculo dos números primos encontrados no escopo de um (1) a um número passado pelo usuário. Para execução do estudo foi passado o valor de vinte e cinco milhões foi denominado, no caso, todas as execuções serão realizadas no escopo de um (1) a vinte e cinco milhões. Este algoritmo, assim como sua aplicação resultante foi denotado como PrimosLocal. Para desenvolvimento da aplicação PrimosLocal foi usada a ferramenta de desenvolvimento Eclipse IDE for Java EE Developers, utilizando a linguagem Java. Para melhor compreensão o leitor pode observar o fluxograma que apresenta a lógica do algoritmo de execução em um computador local na Figura 25 e em seguida o algoritmo que resultou a aplicação teste, Figura 26:

74

Figura 25 - Fluxograma apresentando a lógica do algoritmo de execução em um computador fora da grid

75

Figura 26 - Algoritmo para execução em um computador local

Como citado, a primeira modificação observada faz com que o cálculo se repita cinco vezes, a inclusão de um laço, linha 7, realiza tal feito. A variável all, iniciada em zero no próprio laço, seria interada até o valor quatro, realizando cinco iterações. O overhead da grid não foi adicionado ao algoritmo, pois a constatação está na análise comparativa do desempenho do uso de um computador local com o uso de um sistema em grid para aplicações bag of tasks. Este overhead conta como parte do tempo obtido nos resultados da execução em uma grid departamental.

76

4.2.2.

Algoritmo de Execução em Grid

O algoritmo desenvolvido para execução em grid corresponde a uma parte do algoritmo de execução local, no caso, somente o laço inicial responsável por repetir o calculo cinco vezes foi extraído, isolando somente a tarefa, ou seja, o calculo em si a ser compilado e agregado pelo job. Este algoritmo foi denominado. Para seu desenvolvimento, foi usada a ferramenta de desenvolvimento Eclipse IDE for Java EE Developers, utilizando a linguagem Java. Para melhor compreensão o leitor pode observar o fluxograma que apresenta a lógica do algoritmo de execução em grid na Figura 27 e o algoritmo que resultou na aplicação teste, Figura 28:

77

Figura 27 - Fluxograma apresentando a lógica do algoritmo de execução em grid

78

Figura 28 - Código para execução em grid

4.3.

Execução e Análise dos Testes

Todos os testes foram realizados cinco vezes para maior precisão dos resultados. Foram exibidos todos os resultados obtidos, assim como suas respectivas médias. Todos os testes apresentarão respectivamente: texto introdutório, apresentação dos resultados das cinco execuções e um gráfico para ilustrar a comparação do tempo de execução da aplicação em grid com um determinado numero de nós, denotado no gráfico com a letra “G” (grid) seguido do que a agrega número de nós agregados a ela “G-n” e o tempo de execução

79

da aplicação executada em um computador local, denotada nos gráficos como “CL”. Os testes foram realizados dentro do cenário descrito na Seção 4.1.

4.3.1.

Execução do Algoritmo em um Computador Local

Este primeiro teste foi à base para as comparações de desempenho a cada nó agregado a grid. Os resultados obtidos estão presentes na Tabela 7, onde é apresentado o tempo final de cada execução do algoritmo PrimosLocal e a média dos tempos obtidos.

RESULTADOS DA EXECUÇÃO EM UM COMPUTADOR FORA DA GRID

TEMPO DA EXECUÇÃO:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

761894

764125

762893 761894

759754

760589

MÉDIA DOS TEMPOS OBTIDOS:

Tabela 7 - Resultados da execução em um computador fora da grid

4.3.2.

Execução e Análise do Primeiro Teste

Este primeiro teste teve por objetivo obter o tempo de execução de um job em uma grid com apenas um nó. Os resultados obtidos podem ser observados na Tabela 8 e Figura 29.

RESULTADOS DO PRIMEIRO TESTE

TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

855781

855664

855887 855792

855792

855801

Tabela 8 - Resultados da execução de uma grid composta por um nó

80

Figura 29 - Comparação dos tempos de execução entre uma grid composta por um único nó e um computador local A média dos tempos obtidos ao final de cada execução apresentou, comparada a média dos tempos de execução em um computador local, uma diferença de 93898 milissegundos, perda aproximada de 10,97%. Também foi observado que nenhuma das execuções em grid superaram o tempo de qualquer uma das execuções realizadas no computador local. O observado na execução em grid foi o tempo adicional na atribuição de cada tarefa para o worker. O motivo provável está no sistema de comunicação entre os componentes do middleware para a atribuição da tarefa para o worker. Já para a execução local as tarefas eram executadas uma após a outra, a adição do tempo entre uma tarefa e outra foi ínfima, comparada ao tempo da procura de recursos para execução das tarefas na grid

4.3.3.

Execução e Análise do Segundo Teste

Para o segundo teste foi adicionado mais um nó a malha da grid, permitindo uma divisão de tarefas paralela. A Tabela 9, assim como a Figura 30 apresenta os resultados de cada uma das cindo execuções realizadas, assim como a média de todos os resultados obtidos de cada execução.

81

RESULTADOS DO SEGUNDO TESTE TEMPO DA EXECUÇÃO:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

506578

509719

508656 508656

509011

507998

MÉDIA DOS TEMPOS OBTIDOS:

Tabela 9 - Resultados da execução de uma grid composta por dois nós

Figura 30 - Comparação dos tempos de execução entre uma grid composta por dois nós e um computador local

A adição de um segundo nó a malha da grid já demonstrou um desempenho superior ao tempo da execução do algoritmo de simulação de job em um computador local. A diferença entre a média dos resultados obtidos na grid comparada à média dos tempos em execução local foi de -253238 milissegundos, apresentando para a grid um desempenho superior de 33,24%. Nenhuma das execuções em um computador local superaram qualquer um dos tempos de execução em grid. Enquanto as tarefas em um computador local eram executadas uma a uma, a grid executava-as duas a duas, distribuindo em paralelo as tarefas para seus workers.

4.3.4.

Execução e Análise do Terceiro Teste

82

Para o terceiro teste foi agregado mais um nó a grid, totalizando três nós. Os resultados de cada execução, assim como a média das execuções podem ser observadas na Tabela 10 e Figura 31:

RESULTADOS DO TERCEIRO TESTE TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

339125

339172

338334 339011

339011

338994

Tabela 10 - Resultados da execução de uma grid composta por três nós

Figura 31 - Comparação dos tempos de execução entre uma grid composta por três nós e um computador local

Foi observado que, para cada nó ocioso, a grid lhe atribui uma das tarefas do job. Ao término de cada tarefa era atribuída uma nova ao worker até o termino das cinco. A diferença entre a média dos resultados obtidos na grid comparada à média dos tempos em execução local foi de -422883 milissegundos, apresentando para a grid um desempenho superior de 55,5%. O tempo do término de cada tarefa por nó foi quase o

83

mesmo, ou seja, o tempo de cinco execuções caiu para praticamente o tempo de duas, porém ao compararmos a porcentagem do ganho do desempenho da grid com o número de execuções constatou-se uma redução de 2.775 execuções.

4.3.5.

Execução e Análise do Quarto Teste

O objetivo de um quarto nó adicionado a grid era constatar a possível equivalência do tempo de execução da grid com três nós. Um quarto nó adicionado a grid aparentemente reduziria o tempo de cinco execuções para o tempo de duas, pois seriam atribuídos aos quatro nós quatro tarefas do job, porém restaria uma, apresentando possivelmente um tempo aproximado da execução de um job com oito tarefas. A Tabela 11, assim como a Figura 32 apresenta os resultados do tempo de término de cada uma das cinco execuções e a média dos tempos obtidos

RESULTADOS DO QUARTO TESTE TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

336406

338859

336813 337898

337898

338667

Tabela 11 - Resultados da execução de uma grid composta por quatro nós

84

Figura 32 - Comparação dos tempos de execução entre uma grid composta por quatro nós e um computador local

Como esperado a média do tempo de execução do job para uma grid com quatro nós foi equivalente ao tempo de execução de um grid com três nós. Foi observado que esta equivalência deu-se ao fato da disponibilidade de nós a grid e o número de tarefas a serem executadas. Como a grid atribui uma tarefa a cada nó ocioso da malha, enquanto eram executadas as quatro tarefas uma das cinco contidas no job teve que esperar na fila, por conseqüência houve a equivalência do tempo citado. A diferença entre a média dos resultados obtidos na grid comparada à média dos tempos em execução local foi de -423996 milissegundos, apresentando para a grid um desempenho superior de 55,65%. Nenhuma das execuções em um computador local superaram qualquer um dos tempos de execução em grid. O ganho em números de execuções foi de aproximadamente 2.782, relacionado ao número de execuções realizadas pelo computador local.

85

4.3.6.

Execução e Análise do Quinto Teste

O objetivo da adição de mais um nó a grid, totalizando uma malha com cinco, esteve em reduzir ao máximo o tempo da execução do job. As tarefas seriam distribuídas uma para cada nó, portanto neste contexto a adição de um sexto nó à grid não faria diferença. Os resultados obtidos de cada uma das execuções estão presentes na Tabela 12 e na Figura 33, assim como a média destas execuções.

RESULTADOS DO QUINTO TESTE TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS:

1º EXECUÇÃO

2º EXECUÇÃO

3º EXECUÇÃO

4º EXECUÇÃO

5º EXECUÇÃO

171610

167641

164344 167641

178391

166578

Tabela 12 - Resultados da execução de uma grid composta por cinco nós

Figura 33 - Comparação dos tempos de execução entre uma grid composta por cinco nós e um computador local

O comportamento observado para uma grid com cinco nós em sua malha foi a distribuição de uma tarefa por nó, abrangendo as cinco contidas no job, uma redução de aproximadamente 1/5, se comparado ao Tempo das execuções no computador local para o

86

término do algoritmo de simulação de job PrimosLocal. A diferença entre a média dos resultados obtidos na grid comparada à média dos tempos em execução local foi de -594253 milissegundos, apresentando para a grid um desempenho superior de 78%. O ganho em números de execuções foi de aproximadamente 3.9, relacionado ao número de execuções realizadas pelo computador local.

4.3.7.

Conclusão das Análises

Observando as análises obtidas pode-se constatar na Figura 34 que, neste caso, o ganho no tempo para execução deste job, ao se agregar nós à grid, não foi exponencial. Pode ser observado um decréscimo de tempo para cada nó agregado a grid, porém praticamente não houve ganho de desempenho entre as grids compostas de três e quatro nós, só é observado novamente um ganho satisfatório de desempenho entre as grids de quatro a cinco nós. O motivo observado está no ganho de desempenho relacionado à quantidade de nós que foram disponibilizados para executar as tarefas do job. Para maior esclarecimento pode-se observar uma breve análise do comportamento de cada um dos testes em um gráfico comparativo na Figura 34:

87

Figura 34 - Demonstração de todos os tempos obtidos na execução dos testes em grid

A primeira grid, composta por um nó, só podia executar uma tarefa de cada vez, as outras aguardavam na fila. Não houve redução de tempo. A segunda grid, composta por dois nós, podia atribuir duas tarefas por vez a seus worker. Houve três aguardos na fila correspondente a duas e, posteriormente, uma tarefa a espera do término da execução de um de dois worker disponíveis na grid, apesar de um dos nós se manter ocioso na execução da ultima tarefa, foi apresentado uma redução de 33,24% no tempo de execução do job. A terceira grid, composta por três nós, podia atribuir três tarefas por vez a seus worker. Houve apenas um aguardo na fila correspondente a duas tarefas a espera do termino da execução de um de três worker. Foi apresentada uma redução de 55,5% no tempo de execução do job. A quarta grid, composta por quatro nós, podia atribuir quatro tarefas por vez a seus worker. Esta também apresentou apenas um aguardo na fila correspondente a uma tarefa a espera do término da execução de um dos quatro worker. Houve uma redução de tempo aproximado ao tempo de execução apresentado por uma grid com três nós: 55,5% contra no 55,65% no tempo de execução do job para a grid com quatro agregados a sua malha, como pode ser observado na Figura 35.

88

Figura 35 - Comparação entre os tempos de execução de uma grid com quatro nós e uma grid com três nós e a execução em um computador local

A quinta grid, composta por cinco nós demonstrou eficácia na divisão de tarefas, reduzindo o tempo em 78%, uma vez que cada tarefa foi atribuída a um worker, abrangendo todas as tarefas do job e eliminando a espera na fila. Uma análise das médias do tempo de execução dos cinco testes comparado a execução do algoritmo em um computador local pode ser vista observando a Figura 36:

89

Figura 36 - Comparação do tempo de execução entre grids de 1 a 5 nós e um computador local

Uma performance satisfatória relacionada à grid para execução da aplicação teste foi observada em dois casos: O primeiro caso, para uma grid com cinco nós, uma vez que o acréscimo de nós não influiria no aumento de desempenho, pois o job construído fora dividido somente em cinco tarefas. Para um ganho de performance no acréscimo de nós a grids seria necessário dividir a aplicação em mais tarefas. O segundo caso está em uma grid com três nós, pois houve uma redução de praticamente metade do tempo da execução em um computador local, o acréscimo do quarto nó não trouxe ganho significativo de performance, como observado na Seção 4.3.5.

90

5.

CONSIDERAÇÕES FINAIS

Este trabalho apresentou os conceitos de Computação em Grade e realizou um estudo de caso utilizando o middleware Ourgrid através de uma análise de desempenho comparativa entre uma grid departamental, utilizando o middleware e um Computador local.

5.1.

Contribuições e Conclusões

As contribuições deste trabalho são: a)

Este trabalho apresentou a tecnologia de Computação em Grade desde

sua origem como pretensão de reunir recursos dispersos geograficamente até sua realidade no mundo moderno como recurso de TI. Foi demonstrado o conceito de sistemas distribuídos alavancando grid como um vantajoso sistema devido a sua escalabilidade e propriedade de agregar recursos de ambientes heterogêneo. Apresentou também que o uso da computação em grade permite a criação de sistemas dos quais um supercomputador jamais poderia agregar. É eficaz no aproveitamento e reuso de recursos já disponíveis, uma possível alternativa de realce econômico se comparada com a aquisição de supercomputadores. b) Foram apresentadas ferramentas que auxiliam a adoção da Computação em Grade, demonstrando a arquitetura e cases dos middlewares: Condor, Alchemi e Ourgrid; c)

Foram demonstrados os procedimentos para o desenvolvimento e uma

grid departamental para efetivar a análise, demonstrando todas as etapas sua para implantação, desde seus pré-requisitos até a execução da aplicação distribuída. d) Foi demonstrado o processo de submissão de aplicações para execução em grid apresentando um exemplo da transformação de uma aplicação local em uma aplicação bag of tasks, aplicação suportada pelo middleware Ougrid.

91

e)

Foi apresentada uma análise comparativa entre uma grid departamental,

utilizando o middleware Ourgrid, e um computador fora da grade. As constatações das análises, dentro do cenário descrito, apontaram um ganho de desempenho de praticamente um 78% quanto ao teste efetuado com uma grid composta de cinco nós. Não houve custo de implantação uma vez que o middleware Ourgrid é de utilização pública, fornecido pela UFCG (Universidade Federal de Campina Grande).

5.2.

Trabalhos Futuros

Este trabalho proporcionou a seus autores algumas premissas de projetos: Elaboração de uma análise mais profunda sobre middleware Ourgrid, envolvendo sua rede geograficamente dispersa. Neste trabalho seriam comparados a utilização do middleware Ourgrid em diversas escalas de tamanho, bem como: a integração entre grids locais e a rede da comunidade Ourgrid, a integração de plataformas diversificadas, por exemplo, MPPs, NoWs, Clusters de execução distribuída a grid, aumentar o número de replicação das tarefas dos jobs, diversificar o numero de peer em computadores de desempenhos distintos, entre outros. O objetivo é divulgar a ferramenta com a conclusão destes estudos e, consequentemente, divulgar a tecnologia dando de forma concreta os créditos que se deve a plataforma de Computação em Grade. Os autores deste trabalho acreditam que basta uma quebra de paradigma para que usuários comuns, por exemplo, de desktop, pequenas empresas e instituições educacionais, usufruam de grids tanto como usufruam da WEB, formando uma massa de recursos computacionais que favoreçam a todos em um equilíbrio natural através do colaborativismo. Desenvolver ferramentas que torne o uso de grids mais intenso, permitindo maior acesso e utilização de usuários leigos as grids existentes.

92

6.

REFERÊNCIAS BIBLIOGRÁFICAS

AGUIAR, M. M. H.; AFONSO, P. M. B. A Contribuição da Informática para o Desenvolvimento Sustentável: O Exemplo do Conceito de Grid Computing. Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa - FCT-UNL, 2009. Disponível em: . Acesso em: 2 de agosto de 2009. ANDRADE, N.; Acesso em Grids Computacionais: Estado da Are e Perspectivas. Laboratório de Sistemas Distríbuidos - LSD, 2002. Disponível em: . Acesso em: 7 de janeiro de 2010. ANDRADE, N.; CIRNE, W.; et al. Ourgrid: An Approach To Easily Assemble Grids With Equitable Resource Sharing. Springer Berlin, Heidelberg, Vol. 2862, ISSN 0302-9743 (Print) 1611-3349 (Online), 2003. Disponível em: . Acesso em: 17 de maio de 2010. BAKER, M.; BUYYA, R.; et al. Grids And Grid Technologies For Wide-Area Distributed Computing. Software: Practice and Experience - Softw. Pract. Exper, Vol. 32, p. 1437 - 1466, 2002. Disponível em: . Acesso em: 9 de outubro de 2009. BARBOSA, F. P.: Charão A.S. Grid Computing e Cloud Computing – Uma Relação de Diferenças, Semelhanças, Aplicabilidade e Possibilidades de Cooperação entre os dois Paradigmas. Universidade Federal de Santa Maria - UFSM, 2009. BELL, S. Grid or cluster: What's the difference?. Computerword, 2007. Disponível em: . Acesso em: 03 de fevereiro de 2010. BEWOUF, 2007 Disponível em: . Acesso em: 7 de janeiro de 2010. BIRN 2007 Disponível em: . Acesso em: 1 de junho de 2010. CIRNE, W.; NETO, E. S. Grids Computacionais: da Computacão de Alto Desempenho a Serviços Sob Demanda. Laboratório de Sistemas Distribuídos - LSD, 2005. Disponível em: . Acesso em: 14 de agosto de

93

2009. CONDOR 2009 Disponível em: . Acesso em: 1 de junho de 2010. CORBATÓ, F. J.; VISSOTISKY V. A. Introduction and overview of the multics system. ACM, New York, p. 185-196, 1965. Disponível em: < http://portal.acm.org/citation.cfm?id=1463891.1463912>. Acesso em: 12 de fevereiro de 2010. CSIRO 2009. Disponível em: . Acesso em: 14 de agosto de 2009. DAME, 2003 Disponível em: . Acesso em: 12 de fevereiro de 2010. DREHER, F. CPTEC/INPE Licita Supercomputador de R$ 42 Milhões. 2009. Disponível em: . Acesso em: 19 de outubro de 2009. DUARTE, J. Grid Computing – A Nova Arquitectura para o Sector Financeiro. 2005. Disponível em: . Acesso em: 5 de dezembro de 2009. FOSTER, I. What Is The Grid? A Three Point Checklist. Argonne National Laboratory & University of Chicago, 2002. Disponível em: . Acesso em: 1 de fevereiro de 2010. FOSTER, I.; KESSELMAN, C.; et al. The Anatomy Of The Grid Enabling Scalable Virtual Organizations. Springer Berlin, Heidelberg, 2001. Disponível em: < http://www.springerlink.com/content/flddyth66lrqdk36/>. Acesso em: 17 de novembro de 2009. FOSTER, I.; KESSELMAN, C. The Grid: Blueprint for a New Computing Infrastructure. Elsevier, 2º Edição, 2004. ISBN: 1558609334. FOSTER, I.; ZHAO, Y.; et al. Cloud Computing And Grid Computing 360-Degree Compared. Grid Computing Environments Workshop - IEEE, 2008. Disponível em: . Acesso em: 22 de setembro de 2009. GOLDCHLEGER, A. InteGrade: Um Sistema de Middleware para Computação em Grade Oportunista. Instituto de Matemática e Estatística da Universidade de São Paulo –IME/USP, 2005. Disponível em:<

94

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.7417&rep=rep1&type=pdf >. Acesso em: 20 de janeiro de 2010. GRIDBUS. Alchemi Documentação V0.6.1. 2006. Disponível em: . Acesso em: 26 de fevereiro de 2010. INFI. Disponível em: . Acesso em: 14 de novembro de 2009. INFOWORD. The top 100 IT projects of 2009. 2009. Disponível em: . Acesso em: 26 de janeiro de 2010. INTEL. Grid Computing. 2009. Disponível em: . Acesso em: 16 de maio de 2010. LUCCHESE, F. Princípios de Grid Computing - Sparsi Informática Ltda. 2006. Disponível em: . Acesso em: 3 de setembro de 2009. LUTHER, A.; BUYYA, R.; et al. Alchemi: A.Net-Based Enterprise Grid Computing System. 6th International Conference on Internet Computing -ICOMP'05, Las Vegas, 2005. Disponível em: . Acesso em: 2 de novembro de 2009. LUTHER, A.; BUYYA, R.; et al. Alchemi: A.Net-Based Grid Computing Framework And Its Integration Into Global Grids. 2004. Disponível em: . Acesso em: 6 de maio de 2010. MEDICAL GRID 2010 Disponível em: . Acesso em: 13 de maio de 2010. MORESI, E. A. D. Inteligência Organizacional: um referencial integrado, Ciência da Informação, Brasília, Vol. 30, n. 2, p. 35-46, 2001. Disponível em: . Acesso em: 3 de janeiro de 2010. NEESGRID. Disponível em: . Acesso em: 3 de janeiro de 2010.

95

NOVAES, W. Desafio do Lixo. TV Cultura, 2001. ORACLE. Oracle® Grid Index Demonstra o Progresso Global Na Direcção do Grid Computing. Oracle Press Release, 2005. Disponível em: . Acesso em: 9 de janeiro de 2010. ORACLE. DELL, EMC, INTEL And ORACLE Launch Project Megagrid To Develop Enterprise Grid Computing Best Practices. Oracle Press Release, 2004. Disponível em: . Acesso em: 18 de dezembro de 2009. ORACLE. "GRSA investe cerca de R$ 1 milhão em grid computing e aumenta em 140% sua capacidade de processamento”. Oracle Press Release, 2006. Disponível em: . Acesso em: 2 de setembro de 2009. OURGRID 2010 Disponível em: . Acesso em: 2 de abril de 2010. REZENDE, Y. Informação para negócios: os novos agentes do conhecimento e a gestão do capital intelectual. Ciência da Informação, Brasília, Vol. 31, p. 120-128, Disponível em: . Acesso em: 20 de março de 2010. STORCH, M.; GARCIA, R. Estudo de Uma Aplicação Distribuída em Grade. Caso: Gerpavgrid, 2006. Disponível em: . Acesso em: 6 de fevereiro de 2010. WANG, L.: LASZEWSKI, G.V. Cloud Computing: a Perspective Study. International Workshop on Grid Computing Environments--Open Access 2008. Disponível em: . Acesso em: 14 de novembro de 2009. WCG. Disponível em: . Acesso em: 19 de maio de 2010.