FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI

Tamanho: px
Começar a partir da página:

Download "FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS RAFAEL WILLWOHL SALGADO URIAS FERNANDES MATRIGRANI"

Transcrição

1 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

2 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

3 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

4 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.

5 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.

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

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

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

9 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

10 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

11 x SUMÁRIO 1. INTRODUÇÃO Motivação Objetivo Objetivo Geral Objetivo Específico Metodologia Organização do Trabalho COMPUTAÇÃO EM GRADE Início da Tecnologia Computação em Grade Definição de Computação em Grade Modelo de Arquitetura da Computação em Grade Requisitos Necessários para uma Plataforma de Computação em Grade Componentes da Grid Computação Paralela e Computação em Grade Clusters Distinção entre Cluster e Computação em Grade Plataformas de Execução Paralela Plataforma SMPs Plataforma MPPs Plataforma NoWs Plataforma de Computação em Grade Distinção entre Computação em Grade e Cloud Computing Usuários de Computação em Grade Considerações Finais TECNOLOGIAS DE COMPUTAÇÃO EM GRADE Condor, Hing Troughput Computing Case do Diagrid Alchemi - Plug & Play Desktop Computação em Grade Case do CSIRO Ourgrid: A Ferramenda Escolhida para o Estudo de Caso Cases do OurGrid TESTES DE DESEMPENHO PARA UMA GRID LOCAL UTILIZANDO O MIDDLEWARE OURGRID Apresentação do Cenário de Teste Ambiente de Implantação Pré-Requisitos para Construção da Grid Openfire Server OurGrid peer OurGrid worker OurGrid broker Integração entre Worker e Peer Integração entre Broker e Peer Construindo e Submetendo Jobs Para o Middleware Ourgrid Criando Um Programa para Execução no Worker Criando o Arquivo JDF (Job Description File) Submetendo um Job para Execução no Middleware Ourgrid... 72

12 4.2. Desenvolvimento dos Testes Algoritmo de Execução em Um Computador Local Algoritmo de Execução em Grid Execução e Análise dos Testes Execução do Algoritmo em um Computador Local Execução e Análise do Primeiro Teste Execução e Análise do Segundo Teste Execução e Análise do Terceiro Teste Execução e Análise do Quarto Teste Execução e Análise do Quinto Teste Conclusão das Análises CONSIDERAÇÕES FINAIS Contribuições e Conclusões Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS xi

13 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.

14 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 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

15 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) 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 Objetivo Geral

16 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 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 Organização do Trabalho A seguir serão apresentados os demais capítulos deste trabalho:

17 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 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

18 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

19 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:

20 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 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:

21 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

22 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) 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;

23 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).

24 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 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.

25 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

26 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.

27 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 apresenta os componentes de uma grid, independente das tecnologias usufruídas para sua realização Componentes da Grid uma grid como plataforma. Esta seção descreve de forma mais específica os componentes para criação de

28 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.

29 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.

30 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 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).

31 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.

32 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) 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) 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

33 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 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:

34 33 Figura 5 - Arquitetura multiprocessadas Fonte: Adaptado de CIRNE, (2005) 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:

35 34 Figura 6 - Arquitetura de um MPP Fonte: Adaptado de CIRNE, (2005) 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):

36 35 Figura 7 - Arquitetura de uma NOW Fonte: Adaptado de CIRNE, (2005) 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

37 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 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

38 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) 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

39 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).

40 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) 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.

41 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 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 c) Várias organizações acreditam nas perspectivas de crescimento deste projeto. Empresas comerciais como IBM, Intel, Microsoft, AT&T, entre outras.

42 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 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

43 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,

44 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) 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

45 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) 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.

46 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)

47 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):

48 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 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) 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.

49 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 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.

50 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.

51 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 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

52 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.

53 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 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 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:

54 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: ( 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:

55 54 SOFTWARE OPENFIRE SERVER PEER BROKER WORKER DESENVOLVEDOR Jive Sofware Ourgrid Community Ourgrid Community Ourgrid Community PLATAFORMAS SUPORTADAS Linux, Unix, Mac OS X ou Windows Linux ou Windows Linux ou Windows Linux ou Windows JAVA RUNTIME MACHINE Versão 1.5 ou superior Versão 1.5 ou superior Versão 1.5 ou superior Versão 1.5 ou superior REQUISITOS MÍNIMOS 512mb de memória RAM e 200mb de espaço em disco. 25mb de espaço em disco 25mb de espaço em disco 25mb de espaço em disco Tabela 2 - Informações e pré-requisitos dos componentes do middleware Ourgrid 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 ( 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 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 /.

56 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.

57 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 - <setup>true</setup> - 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:

58 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, 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

59 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 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

60 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 deve ser informado o 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.

61 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 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.

62 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 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:

63 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.

64 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.

65 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.

66 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:

67 66 PROPRIEDADE DESCRIÇÃO OBRIGATÓRIO? OS Utilizada para indicar o sistema operacional do worker. não SITE USERNAME SERVER NAME COPYTO REMEXEC COPYFROM Utilizada para informar o nome do site que o worker está localizado. Utilizada para informar o nome de usuário da conta do Openfire Server utilizada pelo worker. Utilizado para informar o nome ou o endereço IP do computador que possuí o Openfire Server instalado. 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. Utilizado para informar ao peer o valor padrão do comando para executar os arquivos de uma tarefa no worker 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. Tabela 3 - Principais sub-propriedades do arquivo SDF * sim sim não não não 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 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.

68 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.

69 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 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 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

70 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 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 LABEL REQUIREMENTS DESCRIÇÃO Identificação do job Requisitos necessários para a execução das tarefas Tabela 4 - Descrição das sub-propriedades de um job

71 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 DESCRIÇÃO COMANDO DESCRIÇÃO INIT Utilizada para indicar os arquivos que serão enviados ao nó trabalhador (worker) put store Indica quais arquivos precisam ser transferidos para o nó trabalhador (worker) antes da execução da tarefa Idêntico ao put, mas verifica se o arquivo já existe REMOTE Utilizada para definir e executar o comando que inicia a execução da tarefa no nó trabalhador (worker) Linha de comando do shell (Linux), prompt (windows) Utilizada para executar e passar os argumentos necessários do programa responsável pela tarefa FINAL Utilizada para indicar os arquivos que serão trazidos de volta a máquina local após a execução da tarefa get store Indica quais arquivos precisam ser trazidos de volta do nó trabalhador (worker) depois da execução. Idêntico ao put, mas verifica se o arquivo já existe Tabela 5 - Fases e comandos da propriedade task

72 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:

73 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 <300 > Maior que mem> 300 <= Menor que ou igual mem <= 64 >= Maior que ou igual playpensize>= 30 == Igual os == windows = Igual os = windows!= Diferente os!= linux Tabela 6 - Operadores lógicos e aritméticos suportados pelo JDF 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 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

74 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 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:

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

76 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.

77 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:

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

79 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

80 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 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 1º EXECUÇÃO 2º EXECUÇÃO 3º EXECUÇÃO 4º EXECUÇÃO 5º EXECUÇÃO TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS: Tabela 7 - Resultados da execução em um computador fora da grid 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 1º EXECUÇÃO 2º EXECUÇÃO 3º EXECUÇÃO 4º EXECUÇÃO 5º EXECUÇÃO TEMPO DA EXECUÇÃO: MÉDIA DOS TEMPOS OBTIDOS: Tabela 8 - Resultados da execução de uma grid composta por um nó

81 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 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 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.

82 81 RESULTADOS DO SEGUNDO TESTE 1º EXECUÇÃO 2º EXECUÇÃO 3º EXECUÇÃO 4º EXECUÇÃO 5º EXECUÇÃO TEMPO DA EXECUÇÃO: 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 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 Execução e Análise do Terceiro Teste

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE III: Infraestrutura de Tecnologia da Informação Atualmente, a infraestrutura de TI é composta por cinco elementos principais: hardware, software,

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

O que é Grid Computing

O que é Grid Computing Grid Computing Agenda O que é Grid Computing Grid vs Cluster Benefícios Tipos de Grid Aplicações Ferramentas e padrões Exemplos no mundo Exemplos no Brasil Grid no mundo dos negócios Futuro O que é Grid

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 1 Conceitos da Computação em Nuvem A computação em nuvem ou cloud computing

Leia mais

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO Intranets FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO As intranets são redes internas às organizações que usam as tecnologias utilizadas na rede mundial

Leia mais

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho vi http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Administração de Redes de Computadores Resumo de Serviços em Rede Linux Controlador de Domínio Servidor DNS

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor

Leia mais

Profs. Deja e Andrei

Profs. Deja e Andrei Disciplina Sistemas Distribuídos e de Tempo Real Profs. Deja e Andrei Sistemas Distribuídos 1 Conceitos e Projetos de Sistemas Distribuídos Objetivos: Apresentar uma visão geral de processamento distribuído,

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para

Leia mais

Proposta de Avaliação de Empresas para o uso do SAAS

Proposta de Avaliação de Empresas para o uso do SAAS 1 INSTITUTO DE EDUCAÇÃO TECNOLÓGICA PÓS-GRADUAÇÃO Gestão e Tecnologia da Informação/ IFTI 1402 Turma 25 09 de abril de 2015 Proposta de Avaliação de Empresas para o uso do SAAS Raphael Henrique Duarte

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais O que se espera de um sistema de computação? Execução de programas de usuários Permitir a solução de problemas Sistema Operacional (SO) é um programa colocado entre o hardware do

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Introdução Um sistema operacional é um programa que atua como intermediário entre o usuário e o hardware de um computador. O propósito

Leia mais

PARANÁ GOVERNO DO ESTADO

PARANÁ GOVERNO DO ESTADO A COMUNICAÇÃO NA INTERNET PROTOCOLO TCP/IP Para tentar facilitar o entendimento de como se dá a comunicação na Internet, vamos começar contando uma história para fazer uma analogia. Era uma vez, um estrangeiro

Leia mais

Arquitetura de Rede de Computadores

Arquitetura de Rede de Computadores TCP/IP Roteamento Arquitetura de Rede de Prof. Pedro Neto Aracaju Sergipe - 2011 Ementa da Disciplina 4. Roteamento i. Máscara de Rede ii. Sub-Redes iii. Números Binários e Máscara de Sub-Rede iv. O Roteador

Leia mais

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2) Definição de um Sistema Distribuído (1) Introdução Um sistema distribuído é: Uma coleção de computadores independentes que aparecem para o usuário como um único sistema coerente. Definição de um Sistema

Leia mais

INTRODUÇÃO A PORTAIS CORPORATIVOS

INTRODUÇÃO A PORTAIS CORPORATIVOS INTRODUÇÃO A PORTAIS CORPORATIVOS Conectt i3 Portais Corporativos Há cinco anos, as empresas vêm apostando em Intranet. Hoje estão na terceira geração, a mais interativa de todas. Souvenir Zalla Revista

Leia mais

O que é o Virto ERP? Onde sua empresa quer chegar? Apresentação. Modelo de funcionamento

O que é o Virto ERP? Onde sua empresa quer chegar? Apresentação. Modelo de funcionamento HOME O QUE É TOUR MÓDULOS POR QUE SOMOS DIFERENTES METODOLOGIA CLIENTES DÚVIDAS PREÇOS FALE CONOSCO Suporte Sou Cliente Onde sua empresa quer chegar? Sistemas de gestão precisam ajudar sua empresa a atingir

Leia mais

Núvem Pública, Privada ou Híbrida, qual adotar?

Núvem Pública, Privada ou Híbrida, qual adotar? Instituto de Educação Tecnológica Pós-graduação Gestão e Tecnologia da Informação - Turma 25 03/04/2015 Núvem Pública, Privada ou Híbrida, qual adotar? Paulo Fernando Martins Kreppel Analista de Sistemas

Leia mais

Supercomputadores dominavam o mercado

Supercomputadores dominavam o mercado Clusters e Grids Introdução Supercomputadores dominavam o mercado Alto custo Requerem mão de obra muito especializada Desenvolvimento de microprocessadores poderosos a um baixo custo Desenvolvimento de

Leia mais

Comparação SDs X Scs

Comparação SDs X Scs Prof. Alexandre Lima Sistemas Distribuídos Cap 9 1/7 Comparação SDs X Scs Distribuição inerente Economia Velocidade Confiabilidade Crescimento incremental Descrição Algumas aplicações envolvem máquinas

Leia mais

A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer

A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer lugar e independente da plataforma, bastando para isso

Leia mais

Redes de Computadores. Prof. Dr. Rogério Galante Negri

Redes de Computadores. Prof. Dr. Rogério Galante Negri Redes de Computadores Prof. Dr. Rogério Galante Negri Rede É uma combinação de hardware e software Envia dados de um local para outro Hardware: transporta sinais Software: instruções que regem os serviços

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Aula 03-04: Modelos de Sistemas Distribuídos

Aula 03-04: Modelos de Sistemas Distribuídos UNIVERSIDADE Computação Aula 03-04: Modelos de Sistemas Distribuídos 2o. Semestre / 2014 Prof. Jesus Principais questões no projeto de um sistema distribuído (SD) Questão de acesso (como sist. será acessado)

Leia mais

Multiplexador. Permitem que vários equipamentos compartilhem um único canal de comunicação

Multiplexador. Permitem que vários equipamentos compartilhem um único canal de comunicação Multiplexadores Permitem que vários equipamentos compartilhem um único canal de comunicação Transmissor 1 Receptor 1 Transmissor 2 Multiplexador Multiplexador Receptor 2 Transmissor 3 Receptor 3 Economia

Leia mais

Unidade 1. Conceitos Básicos

Unidade 1. Conceitos Básicos Unidade 1 Conceitos Básicos 11 U1 - Conceitos Básicos Comunicação Protocolo Definição de rede Rede Internet 12 Comunicação de dados Comunicação de dados comunicação de informação em estado binário entre

Leia mais

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 03 Tipos de Sistemas Operacionais Maxwell Anderson Prof. Maxwell Anderson www.maxwellanderson.com.br Tipos de Sistemas Operacionais Os tipos de sistemas operacionais e a sua

Leia mais

GT Computação Colaborativa (P2P)

GT Computação Colaborativa (P2P) GT Computação Colaborativa (P2P) Djamel Sadok Julho de 2003 Este documento tem como objetivo descrever o projeto de estruturação do grupo de trabalho GT Computação Colaborativa (P2P), responsável pelo

Leia mais

Desenvolvimento de uma Rede de Distribuição de Arquivos. Development of a File Distribution Network

Desenvolvimento de uma Rede de Distribuição de Arquivos. Development of a File Distribution Network Desenvolvimento de uma Rede de Distribuição de Arquivos Development of a File Distribution Network Desenvolvimento de uma Rede de Distribuição de Arquivos Development of a File Distribution Network Talles

Leia mais

Introdução ao Active Directory AD

Introdução ao Active Directory AD Introdução ao Active Directory AD Curso Técnico em Redes de Computadores SENAC - DF Professor Airton Ribeiro O Active Directory, ou simplesmente AD como é usualmente conhecido, é um serviço de diretórios

Leia mais

Figura 1 Taxas de transmissão entre as redes

Figura 1 Taxas de transmissão entre as redes Conceitos de Redes Locais A função básica de uma rede local (LAN) é permitir a distribuição da informação e a automatização das funções de negócio de uma organização. As principais aplicações que requerem

Leia mais

BlackBerry Mobile Voice System

BlackBerry Mobile Voice System BlackBerry Mobile Voice System Comunicações móveis unificadas O BlackBerry Mobile Voice System (BlackBerry MVS) leva os recursos do telefone do escritório aos smartphones BlackBerry. Você pode trabalhar

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 2. Cursos de Computação

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 2. Cursos de Computação Cursos de Computação Sistemas Operacionais Prof. M.Sc. Sérgio Teixeira Aula 05 Estrutura e arquitetura do SO Parte 2 Referência: MACHADO, F.B. ; MAIA, L.P. Arquitetura de Sistemas Operacionais. 4.ed. LTC,

Leia mais

Soluções Completas. Fundada em 1991, a.compos é pioneira na área de soluções em tecnologia, atuando nas áreas de:

Soluções Completas. Fundada em 1991, a.compos é pioneira na área de soluções em tecnologia, atuando nas áreas de: Soluções Completas Fundada em 1991, a.compos é pioneira na área de soluções em tecnologia, atuando nas áreas de: - Conexões compartilhada (.IP) e dedicada (.LINK); - Data Center com servidores virtuais

Leia mais

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS Quando falamos em arquitetura, normalmente utilizamos esse termo para referenciar a forma como os aplicativos computacionais são estruturados e os hardwares

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Anéis Ópticos em Backbone www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução Em 1980 foi formado o grupo de trabalho ANSI X3T9.5 com a finalidade de desenvolver

Leia mais

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos

Leia mais

PROJETO E IMPLANTAÇÃO DE INTRANETS

PROJETO E IMPLANTAÇÃO DE INTRANETS PROJETO E IMPLANTAÇÃO DE INTRANETS Aulas : Terças e Quintas Horário: AB Noite [18:30 20:20hs] PROJETO E IMPLANTAÇÃO DE INTRANETS 1 Conteúdo O que Rede? Conceito; Como Surgiu? Objetivo; Evolução Tipos de

Leia mais

Unidade 13: Paralelismo:

Unidade 13: Paralelismo: Arquitetura e Organização de Computadores 1 Unidade 13: Paralelismo: SMP e Processamento Vetorial Prof. Daniel Caetano Objetivo: Apresentar os conceitos fundamentais da arquitetura SMP e alguns detalhes

Leia mais

BlackBerry Mobile Voice System

BlackBerry Mobile Voice System BlackBerry Mobile Voice System BlackBerry Mobile Voice System Comunicações móveis unificadas O Mobile Voice System ( MVS) foi projetado para unificar os recursos do telefone fixo aos smartphones e às redes

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Guia de Conectividade Worldspan Go Res! A V A N Ç A D O

Guia de Conectividade Worldspan Go Res! A V A N Ç A D O Guia de Conectividade Worldspan Go Res! A V A N Ç A D O Í n d i c e Considerações Iniciais...2 Rede TCP/IP...3 Produtos para conectividade...5 Diagnosticando problemas na Rede...8 Firewall...10 Proxy...12

Leia mais

Rede de Computadores

Rede de Computadores Escola de Ciências e Tecnologia UFRN Rede de Computadores Prof. Aquiles Burlamaqui Nélio Cacho Luiz Eduardo Eduardo Aranha ECT1103 INFORMÁTICA FUNDAMENTAL Manter o telefone celular sempre desligado/silencioso

Leia mais

MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER

MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER TÁSSIO JOSÉ GONÇALVES GOMES tassiogoncalvesg@gmail.com MINICURSO WINDOWS SERVER 2008 TÁSSIO GONÇALVES - TASSIOGONCALVESG@GMAIL.COM 1 CONTEÚDO Arquitetura

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

Nível do Sistema Operacional

Nível do Sistema Operacional Nível do Sistema Operacional (Aula 14) Introdução a Sistemas Operacionais Roberta Lima Gomes - LPRM/DI/UFES Sistemas de Programação I Eng. Elétrica 2007/1 Introdução Hardware Provê os recursos básicos

Leia mais

Rede d s d e d Com o pu p t u ado d r o es Conceitos Básicos M d o e d los o de d Re R de d s:

Rede d s d e d Com o pu p t u ado d r o es Conceitos Básicos M d o e d los o de d Re R de d s: Tecnologia em Redes de Computadores Redes de Computadores Professor: André Sobral e-mail: alsobral@gmail.com Conceitos Básicos Modelos de Redes: O O conceito de camada é utilizado para descrever como ocorre

Leia mais

4 Um Exemplo de Implementação

4 Um Exemplo de Implementação 4 Um Exemplo de Implementação Neste capítulo será discutida uma implementação baseada na arquitetura proposta. Para tanto, será explicado como a arquitetura proposta se casa com as necessidades da aplicação

Leia mais

Processos Técnicos - Aulas 4 e 5

Processos Técnicos - Aulas 4 e 5 Processos Técnicos - Aulas 4 e 5 Trabalho / PEM Tema: Frameworks Públicos Grupo: equipe do TCC Entrega: versão digital, 1ª semana de Abril (de 31/03 a 04/04), no e-mail do professor (rodrigues.yuri@yahoo.com.br)

Leia mais

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Introdução O que é Protocolo? - Para que os pacotes de dados trafeguem de uma origem até um destino, através de uma rede, é importante

Leia mais

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling DIMENSIONANDO PROJETOS DE WEB-ENABLING Uma aplicação da Análise de Pontos de Função Dimensionando projetos de Web- Enabling Índice INTRODUÇÃO...3 FRONTEIRA DA APLICAÇÃO E TIPO DE CONTAGEM...3 ESCOPO DA

Leia mais

Entendendo como funciona o NAT

Entendendo como funciona o NAT Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços

Leia mais

Classificação de SO (Sistemas Operacionais) Técnico de Informática 2º. Módulo Profa. Madalena Pereira da Silva madalena.silva@ifsc.edu.

Classificação de SO (Sistemas Operacionais) Técnico de Informática 2º. Módulo Profa. Madalena Pereira da Silva madalena.silva@ifsc.edu. Classificação de SO (Sistemas Operacionais) Técnico de Informática 2º. Módulo Profa. Madalena Pereira da Silva madalena.silva@ifsc.edu.br Agenda Classificação de SO quanto a: Interface Processamento Tarefas

Leia mais

SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA

SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA Muitas organizações terceirizam o transporte das chamadas em seus call-centers, dependendo inteiramente

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS 1. Introdução a supercomputação 2. Visão geral de Mainframe 3. Cluster de computadores 4. Cluster Beowulf considerações de projeto 5. Cluster x Grid 6.

Leia mais

MSc Eliton Smith elitonsmith@gmail.com. Gerenciamento e Administração de Redes

MSc Eliton Smith elitonsmith@gmail.com. Gerenciamento e Administração de Redes MSc Eliton Smith elitonsmith@gmail.com Gerenciamento e Administração de Redes 2 Gerência de Redes ou Gerenciamento de Redes É o controle de qualquer objeto passível de ser monitorado numa estrutura de

Leia mais

Sistemas Operacionais. INTRODUÇÃO Prof. Rafael Alberto Vital Pinto FACSUL/CESUR

Sistemas Operacionais. INTRODUÇÃO Prof. Rafael Alberto Vital Pinto FACSUL/CESUR Sistemas Operacionais INTRODUÇÃO Prof. Rafael Alberto Vital Pinto FACSUL/CESUR 1 Introdução O que se espera de um sistema de computação? Execução de programas de usuários Permitir a solução de problemas

Leia mais

Um Driver NDIS Para Interceptação de Datagramas IP

Um Driver NDIS Para Interceptação de Datagramas IP Um Driver NDIS Para Interceptação de Datagramas IP Paulo Fernando da Silva psilva@senior.com.br Sérgio Stringari stringari@furb.br Resumo. Este artigo apresenta o desenvolvimento de um driver NDIS 1 para

Leia mais

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede Prof. Samuel Souza } Monolíticas Aplicações em um computador centralizado } Em Rede Aplicações com comunicação em rede } Distribuídas Comunicação e cooperação em rede } Aplicações que são funcionalmente

Leia mais

Everson Scherrer Borges João Paulo de Brito Gonçalves

Everson Scherrer Borges João Paulo de Brito Gonçalves Everson Scherrer Borges João Paulo de Brito Gonçalves 1 Tipos de Sistemas Operacionais Os tipos de sistemas operacionais e sua evolução estão relacionados diretamente com a evolução do hardware e das

Leia mais

Noções de. Microsoft SQL Server. Microsoft SQL Server

Noções de. Microsoft SQL Server. Microsoft SQL Server Noções de 1 Considerações Iniciais Basicamente existem dois tipos de usuários do SQL Server: Implementadores Administradores 2 1 Implementadores Utilizam o SQL Server para criar e alterar base de dados

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Software em Sistemas Distribuídos Aplicativo ou Sistema Operacional Sincronismo Interação Controles Um sistema operacional moderno provê dois serviços fundamentais para o usuário

Leia mais

Meio Físico. Mensagem. Protocolo. Emissor e Receptor. Data Terminal Equipment Data Communications Equipment

Meio Físico. Mensagem. Protocolo. Emissor e Receptor. Data Terminal Equipment Data Communications Equipment Emissor Receptor Meio Físico Mensagem Protocolo Emissor e Receptor Data Terminal Equipment Data Communications Equipment (DTE) + (DCE) Meio Físico Mensagem ( pacote ) O meio físico É o elemento que transmite

Leia mais

Desculpe, mas este serviço (jogo) encontra se em manutenção.

Desculpe, mas este serviço (jogo) encontra se em manutenção. Estrutura de servidor e banco de dados para multijogadores massivos Marcelo Henrique dos Santos marcelosantos@outlook.com Desculpe, mas este serviço (jogo) encontra se em manutenção. São Paulo SP, Fevereiro/2013

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Agenda Introdução Exemplos de Sistemas Distribuídos Compartilhamento de Recursos e a Web Principais Desafios para a Implementação

Leia mais

CENTRAL DE SERVIÇOS APOIADA EM SOFTWARE LIVRE

CENTRAL DE SERVIÇOS APOIADA EM SOFTWARE LIVRE CENTRAL DE SERVIÇOS APOIADA EM SOFTWARE LIVRE Juliano Flores Prof. Wagner Walter Lehmann Centro Universitário Leonardo da Vinci - UNIASSELVI Gestão de Tecnologia da Informação (GTI0034) Prática do Módulo

Leia mais

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB Calculando a capacidade de disco: Capacidade = (# bytes/setor) x (méd. # setores/trilha) x (# trilhas/superfície) x (# superfícies/prato) x (# pratos/disco) Exemplo 01: 512 bytes/setor 300 setores/trilha

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I Prof. MSc. Hugo Souza Como já vimos, os sistemas distribuídos são apresentados considerando um planejamento bem mais complexo relacionado aos

Leia mais

INTERNET HOST CONNECTOR

INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR IHC: INTEGRAÇÃO TOTAL COM PRESERVAÇÃO DE INVESTIMENTOS Ao longo das últimas décadas, as organizações investiram milhões de reais em sistemas e aplicativos

Leia mais

FTIN Formação Técnica em Informática Módulo de Administração de Servidores de Rede AULA 02. Prof. Gabriel Silva

FTIN Formação Técnica em Informática Módulo de Administração de Servidores de Rede AULA 02. Prof. Gabriel Silva FTIN Formação Técnica em Informática Módulo de Administração de Servidores de Rede AULA 02 Prof. Gabriel Silva Temas da Aula de Hoje: Revisão da Aula 1. Redes LAN e WAN. Aprofundamento nos Serviços de

Leia mais

ISEP. Instituto Superior de Engenharia do Porto. Análise de Sistemas Informáticos

ISEP. Instituto Superior de Engenharia do Porto. Análise de Sistemas Informáticos ISEP Instituto Superior de Engenharia do Porto Análise de Sistemas Informáticos Armazenamento de Dados em Rede A Revolução do Armazenamento Partilhado A crise económica e a crescente necessidade de armazenamento

Leia mais

Relatorio do trabalho pratico 2

Relatorio do trabalho pratico 2 UNIVERSIDADE FEDERAL DE SANTA CATARINA INE5414 REDES I Aluno: Ramon Dutra Miranda Matricula: 07232120 Relatorio do trabalho pratico 2 O protocolo SNMP (do inglês Simple Network Management Protocol - Protocolo

Leia mais

EVOLUÇÃO DOS SIST. DE COMPUTAÇÃO DÉC. DE 50 E 60

EVOLUÇÃO DOS SIST. DE COMPUTAÇÃO DÉC. DE 50 E 60 INTRODUÇÃO REDES EVOLUÇÃO DOS SIST. DE COMPUTAÇÃO DÉC. DE 50 E 60 Computadores eram máquinas grandes e complexas, operadas por pessoas altamente especializadas; Não havia interação direta entre usuários

Leia mais

CONCEITOS INICIAIS. Agenda A diferença entre páginas Web, Home Page e apresentação Web;

CONCEITOS INICIAIS. Agenda A diferença entre páginas Web, Home Page e apresentação Web; CONCEITOS INICIAIS Agenda A diferença entre páginas Web, Home Page e apresentação Web; O que é necessário para se criar páginas para a Web; Navegadores; O que é site, Host, Provedor e Servidor Web; Protocolos.

Leia mais

GESTÃO DE SISTEMAS OPERACIONAIS II

GESTÃO DE SISTEMAS OPERACIONAIS II GESTÃO DE SISTEMAS OPERACIONAIS II Servidores Definição Servidores História Servidores Tipos Servidores Hardware Servidores Software Evolução do Windows Server Windows Server 2003 Introdução Windows Server

Leia mais

Material 5 Administração de Recursos de HW e SW. Prof. Edson Ceroni

Material 5 Administração de Recursos de HW e SW. Prof. Edson Ceroni Material 5 Administração de Recursos de HW e SW Prof. Edson Ceroni Desafios para a Administração Centralização X Descentralização Operação interna x Outsourcing Hardware Hardware de um Computador Armazenamento

Leia mais

Evolução na Comunicação de

Evolução na Comunicação de Evolução na Comunicação de Dados Invenção do telégrafo em 1838 Código Morse. 1º Telégrafo Código Morse Evolução na Comunicação de Dados A evolução da comunicação através de sinais elétricos deu origem

Leia mais

ALTERNATIVA PARA CONEXÃO VIA INTERNET DE IP MASCARADO A IP REAL

ALTERNATIVA PARA CONEXÃO VIA INTERNET DE IP MASCARADO A IP REAL Documento: Tutorial Autor: Iuri Sonego Cardoso Data: 27/05/2005 E-mail: iuri@scripthome.cjb.net Home Page: http://www.scripthome.cjb.net ALTERNATIVA PARA CONEXÃO VIA INTERNET DE IP MASCARADO A IP REAL

Leia mais

Gestão de Relacionamento com o Cliente CRM

Gestão de Relacionamento com o Cliente CRM Gestão de Relacionamento com o Cliente CRM Fábio Pires 1, Wyllian Fressatti 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil pires_fabin@hotmail.com wyllian@unipar.br RESUMO. O projeto destaca-se

Leia mais

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido Arquitetura Roteiro Arquitetura Tipos de Arquitetura Centralizado Descentralizado Hibrido Questionário 2 Arquitetura Figura 1: Planta baixa de uma casa 3 Arquitetura Engenharia de Software A arquitetura

Leia mais

Universidade de Brasília

Universidade de Brasília Universidade de Brasília Introdução a Microinformática Turma H Redes e Internet Giordane Lima Porque ligar computadores em Rede? Compartilhamento de arquivos; Compartilhamento de periféricos; Mensagens

Leia mais

Sistemas Operacionais Introdução. Professora: Michelle Nery

Sistemas Operacionais Introdução. Professora: Michelle Nery Sistemas Operacionais Introdução Professora: Michelle Nery Área de Atuação do Sistema Operacional Composto de dois ou mais níveis: Tipo de Sistemas Operacionais Sistemas Operacionais Monotarefas Sistemas

Leia mais

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM Rogério Schueroff Vandresen¹, Willian Barbosa Magalhães¹ ¹Universidade Paranaense(UNIPAR) Paranavaí-PR-Brasil rogeriovandresen@gmail.com, wmagalhaes@unipar.br

Leia mais

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa ACESSE Informações corporativas a partir de qualquer ponto de Internet baseado na configuração

Leia mais