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: (http://www.java.com/pt_br/) 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 (http://www.igniterealtime.org) em sua versão 3.6.4, utilizado um pacote de instalação executável que inclui também a JRE (Java Runtime Environment). O servidor Openfire foi instalado em um dos computadores descritos na Seção 4.1.1, que assumiu o papel de servidor de comunicação. As portas liberadas para o uso deste serviço foram as 5222, 5223 e 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 9090/.

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

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

4 Computação Paralela 4.1. Introdução

4 Computação Paralela 4.1. Introdução 4 Computação Paralela 4.1. Introdução Nos últimos anos observa-se uma tendência cada vez maior do aumento da demanda computacional na resolução de grandes problemas. Exemplos de aplicações que exigem alto

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Computação em Grid e em Nuvem

Computação em Grid e em Nuvem Computação em Grid e em Nuvem Computação em Nuvem Molos 1 Definição Um grid computacional é uma coleção recursos computacionais e comunicação utilizados para execução aplicações Usuário vê o grid como

Leia mais

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução Cluster Resumo Introdução Cluster Cluster Beowulf Curiosidades Conclução Introdução Sua empresa esta precisando fazer um grande processamento; As Nuvens existentes não são suficientes para sua empresa;

Leia mais

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

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

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

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

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

Introdução. Nível do Sistema Operacional. Introdução. Um Sistema Operacional... Introdução a Sistemas Operacionais

Introdução. Nível do Sistema Operacional. Introdução. Um Sistema Operacional... Introdução a Sistemas Operacionais Introdução Nível do Sistema Operacional (Aula 14) Introdução a Sistemas Operacionais Hardware Provê os recursos básicos de computação (CPU, memória, E/S,etc.) Programas (aplicações) Definem as maneiras

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

Grades Computacionais: Uma Introdução Prática

Grades Computacionais: Uma Introdução Prática Grades Computacionais: Uma Introdução Prática Raphael Y. de Camargo Ricardo Andrade Departamento de Ciência da Computação Instituto de Matemática e Estatística Universidade de São Paulo, Brasil São Paulo,

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

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

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

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s):

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s): Professor(es): Fernando Pirkel Descrição da(s) atividade(s): Definir as tecnologias de redes necessárias e adequadas para conexão e compartilhamento dos dados que fazem parte da automatização dos procedimentos

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

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Computação Aula 01-02: Introdução 2o. Semestre / 2014 Prof. Jesus Agenda da Apresentação Definição e surgimento de Sistemas Distribuídos Principais aspectos de Sistemas Distribuídos

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

Thin Clients : aumentando o potencial dos sistemas SCADA

Thin Clients : aumentando o potencial dos sistemas SCADA Artigos Técnicos Thin Clients : aumentando o potencial dos sistemas SCADA Tarcísio Romero de Oliveira, Engenheiro de Vendas e Aplicações da Intellution/Aquarius Automação Industrial Ltda. Um diagnóstico

Leia mais

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 -

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 - - 1 - - 2 - - 3 - Segundo (Garg, 2004), são sistemas compostos por múltiplos processadores conectados por uma rede de comunicação, sendo a rede de comunicação uma LAN (Ethernet) ou WAN (Internet). - 4

Leia mais

Cluster HPC High Performance Computing.

Cluster HPC High Performance Computing. Faculdade de Tecnologia de Guaratinguetá. doze, março de 2009. Cluster HPC High Performance Computing. Diogo Salles, Thiago Pirro, Camilo Bernardes, Paulo Roberto, Ricardo Godoi, Douglas, Fauzer. Sistemas

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

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

OCEL001 Comércio Eletrônico Módulo 9_1: Clusters. Prof. Charles Christian Miers. e-mail: charles.miers@udesc.br

OCEL001 Comércio Eletrônico Módulo 9_1: Clusters. Prof. Charles Christian Miers. e-mail: charles.miers@udesc.br OCEL001 Comércio Eletrônico Módulo 9_1: Clusters Prof. Charles Christian Miers e-mail: charles.miers@udesc.br Redundância e Alta Disponibilidade Redundância: Duplicação de um elemento da infraestrutura

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

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais

Grids Computacionais. Marcelo Musci. musci@terra.com.br. Computação de Alto Desempenho. Jun/2004. Profa. DSc. Cristiana Bentes

Grids Computacionais. Marcelo Musci. musci@terra.com.br. Computação de Alto Desempenho. Jun/2004. Profa. DSc. Cristiana Bentes Grids Computacionais Marcelo Musci musci@terra.com.br Computação de Alto Desempenho Jun/2004 Profa. DSc. Cristiana Bentes Roteiro Conceituação Características de Grids Aspectos da Computação em Grid Soluções

Leia mais

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com Cloud Computing Andrêza Leite andreza.lba@gmail.com Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing O

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

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões FACSENAC ECOFROTA Documento de Projeto Lógico de Rede Versão:1.5 Data: 21/11/2013 Identificador do documento: Projeto Lógico de Redes Versão do Template Utilizada na Confecção: 1.0 Localização: FacSenac

Leia mais

Desenvolvimento de um Cluster de Alto Desempenho com PVM

Desenvolvimento de um Cluster de Alto Desempenho com PVM Desenvolvimento de um Cluster de Alto Desempenho com PVM Daniel Cândido de Oliveira 1, Yzaac Gonçalves da Silva 1, Madianita Bogo 1 1 Centro Universitário Luterano de Palmas Universidade Luterana do Brasil

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Laboratório I 2012. Prof. Hélder Sato MSc. 2/14/12 Laboratório I 1

Laboratório I 2012. Prof. Hélder Sato MSc. 2/14/12 Laboratório I 1 Laboratório I 2012 Prof. Hélder Sato MSc 2/14/12 Laboratório I 1 Apresentação Prof Hélder Sato MSc Bacharel Informática Universidade Positivo Especialista em Redes PUC-PR Mestrado em Informática Aplicada

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

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

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Introdução às arquiteturas paralelas e taxonomia de Flynn

Introdução às arquiteturas paralelas e taxonomia de Flynn Introdução às arquiteturas paralelas e taxonomia de Flynn OBJETIVO: definir computação paralela; o modelo de computação paralela desempenhada por computadores paralelos; e exemplos de uso da arquitetura

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Documento de Requisitos de Rede (DRP)

Documento de Requisitos de Rede (DRP) Documento de Requisitos de Rede (DRP) Versão 1.2 SysTrack - Grupo 1 1 Histórico de revisões do modelo Versão Data Autor Descrição 1.0 30/04/2011 João Ricardo Versão inicial 1.1 1/05/2011 André Ricardo

Leia mais

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc. Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web

Leia mais

Virtualização. O conceito de VIRTUALIZAÇÃO

Virtualização. O conceito de VIRTUALIZAÇÃO Virtualização A virtualização está presente tanto no desktop de um entusiasta pelo assunto quanto no ambiente de TI de uma infinidade de empresas das mais variadas áreas. Não se trata de "moda" ou mero

Leia mais

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Sistemas Paralelos e Distribuídos Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Conceitos preliminares Paralelismo refere-se a ocorrência simultânea de eventos em um computador Processamento

Leia mais

Disciplina : Transmissão de Dados

Disciplina : Transmissão de Dados Disciplina : Transmissão de Dados Paulo Henrique Teixeira Overwiew Conceitos Básicos de Rede Visão geral do modelo OSI Visão geral do conjunto de protocolos TCP/IP 1 Conceitos básicos de Rede A largura

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com O que veremos hoje... Evolução Histórica Motivação Conceitos Características

Leia mais

1.2 Tipos de Sistemas Operacionais

1.2 Tipos de Sistemas Operacionais 1.2 Tipos de Operacionais Tipos de Operacionais Monoprogramáveis/ Monotarefa Multiprogramáveis/ Multitarefa Com Múltiplos Processadores 1.2.1 Monoprogramáveis/Monotarefa Os primeiros sistemas operacionais

Leia mais

TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação

TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação Disciplina A Disciplina B Código Disciplina C/H Curso Disciplina C/H Código Curso Ano do Currículo 66303 ESTRUTURA DE DADOS I 68/0 ENG. DE

Leia mais

Camadas de Serviço de Hardware e Software em Sistemas Distribuídos. Introdução. Um Serviço Provido por Múltiplos Servidores

Camadas de Serviço de Hardware e Software em Sistemas Distribuídos. Introdução. Um Serviço Provido por Múltiplos Servidores Camadas de Serviço de Hardware e Software em Sistemas Distribuídos Arquiteutra de Sistemas Distribuídos Introdução Applications, services Adaptação do conjunto de slides do livro Distributed Systems, Tanembaum,

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

BANCO POSTAL - Plataforma Tecnológica

BANCO POSTAL - Plataforma Tecnológica BANCO POSTAL - Plataforma Tecnológica 1. Arquitetura da Aplicação 1.1. O Banco Postal utiliza uma arquitetura cliente/servidor WEB em n camadas: 1.1.1. Camada de Apresentação estações de atendimento, nas

Leia mais

UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE BACHARELADO EM INFORMÁTICA

UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE BACHARELADO EM INFORMÁTICA UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE BACHARELADO EM INFORMÁTICA Tutorial de Instalação da Grade Computacional Gustavo Mantovani Orlando Luiz Pelosi

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

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

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

Sistemas MIMD. CES-25 Arquiteturas para Alto Desmpenho. Paulo André Castro

Sistemas MIMD. CES-25 Arquiteturas para Alto Desmpenho. Paulo André Castro Sistemas MIMD Arquiteturas para Alto Desmpenho Prof. pauloac@ita.br Sala 110 Prédio da Computação www.comp.ita.br/~pauloac Arquiteturas Paralelas (SISD) Single Instruction Stream, Single Data Stream: Monoprocessador

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

Claudivan C. Lopes claudivan@ifpb.edu.br

Claudivan C. Lopes claudivan@ifpb.edu.br Claudivan C. Lopes claudivan@ifpb.edu.br Por que redes de computadores? Tipos de redes Componentes de uma rede IFPB/Patos - Prof. Claudivan 2 Quando o assunto é informática, é impossível não pensar em

Leia mais

ARQUITETURA TRADICIONAL

ARQUITETURA TRADICIONAL INTRODUÇÃO Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da informação seu bem mais precioso. Nos dias de hoje,

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente

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

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

UTILIZAÇÃO DO SOFTWARE LIVRE CACTI PARA GERENCIAMENTO DE REDES LOCAIS DE COMPUTADORES

UTILIZAÇÃO DO SOFTWARE LIVRE CACTI PARA GERENCIAMENTO DE REDES LOCAIS DE COMPUTADORES UTILIZAÇÃO DO SOFTWARE LIVRE CACTI PARA GERENCIAMENTO DE REDES LOCAIS DE COMPUTADORES Filipe Herbert da Silva 1, Marco Aurélio G. de Almeida 1, Jonhson de Tarso Silva 1, Karina Buttignon 1 1 Fatec Guaratinguetá,

Leia mais

Arquitetura de Computadores. Professor: Vilson Heck Junior

Arquitetura de Computadores. Professor: Vilson Heck Junior Arquitetura de Computadores Professor: Vilson Heck Junior Agenda Conceitos Estrutura Funcionamento Arquitetura Tipos Atividades Barramentos Conceitos Como já discutimos, os principais componentes de um

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Classificação de Sistemas Distribuídos e Middleware

Sistemas Distribuídos: Conceitos e Projeto Classificação de Sistemas Distribuídos e Middleware Sistemas Distribuídos: Conceitos e Projeto Classificação de Sistemas Distribuídos e Middleware Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA

Leia mais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais Computação em Nuvem Computação em nuvem: gerenciamento de dados Computação em nuvem (Cloud Computing) é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação

Leia mais

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa.

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa. CLUSTERS Pode-se pegar uma certa quantidade de servidores e juntá-los para formar um cluster. O serviço então é distribuído entre esses servidores como se eles fossem uma máquina só. Um cluster de servidores

Leia mais

Redes de Computadores e suas classificações. Maurício Severich

Redes de Computadores e suas classificações. Maurício Severich Redes de Computadores e suas classificações Maurício Severich Sumário O computador pessoal e a demanda Redes e suas classificações Conectividade Cliente/Servidor Topologia Distância O computador pessoal

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Phil Maynard UNIDADE DE SOLUÇÕES DE GERENCIAMENTO DE DADOS PARA O CLIENTE FEVEREIRO DE 2012 Introdução Em todos os lugares, o volume de

Leia mais

Sistemas de Lotes (2) Sistemas de Lotes (3) Layout da MP em Sistemas de Lotes. Minimizar o tempo de resposta

Sistemas de Lotes (2) Sistemas de Lotes (3) Layout da MP em Sistemas de Lotes. Minimizar o tempo de resposta 1 Mono e multiprogramação Introdução Classificação (Aula 2) Recap Sistemas Máquina Profa. Patrícia Gerenciador D. CostaLPRM/DI/UFES Provê Fornece Compartilhamento programador máquina justa recursos Operacionais

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

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

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Capítulo VI Telecomunicações: Redes e Aplicativos

Capítulo VI Telecomunicações: Redes e Aplicativos Capítulo VI Telecomunicações: Redes e Aplicativos Uma rede nada mais é do que máquinas que se comunicam. Estas máquinas podem ser computadores, impressoras, telefones, aparelhos de fax, etc. Se interligarmos

Leia mais

CSGrid: um Sistema para Integração de Aplicações em Grades Computacionais

CSGrid: um Sistema para Integração de Aplicações em Grades Computacionais CSGrid: um Sistema para Integração de Aplicações em Grades Computacionais Maria Julia de Lima, Taciana Melcop, Renato Cerqueira, Carlos Cassino, Bruno Silvestre, Marcelo Nery, Cristina Ururahy 1 Grupo

Leia mais

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior Arquitetura de SGBD Prof. Antonio Almeida de Barros Junior Agenda Caracterização de SGBDs SGBDs Centralizados SGBDs Cliente-Servidor SGBDs Distribuídos Homogêneos Multi-SGBDs Heterogêneos SGBDs Paralelos

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

Relatório de Pesquisa

Relatório de Pesquisa Relatório de Pesquisa A Vantagem da Virtualização de Mainframe: Como Economizar Milhões de Dólares Utilizando um IBM System z como um Servidor em Nuvem Linux Sumário Executivo Os executivos de TI (Tecnologia

Leia mais

Infra estrutura da Tecnologia da Informação

Infra estrutura da Tecnologia da Informação Infra estrutura da Tecnologia da Informação Capítulo 3 Adaptado do material de apoio ao Livro Sistemas de Informação Gerenciais, 7ª ed., de K. Laudon e J. Laudon, Prentice Hall, 2005 CEA460 Gestão da Informação

Leia mais

Universidade Federal do Acre. Centro de Ciências Exatas e Tecnológicas

Universidade Federal do Acre. Centro de Ciências Exatas e Tecnológicas Universidade Federal do Acre Centro de Ciências Exatas e Tecnológicas Universidade Federal do Acre Centro de Ciências Exatas e Tecnológicas Pós-graduação Lato Sensu em Desenvolvimento de Software e Infraestrutura

Leia mais

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores DOCUMENTAÇÃO TÉCNICA Setembro de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft para monitoramento de servidores sumário CA Nimsoft Monitor para servidores 3 visão geral da solução

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

EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA

EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA QUALQUER TIPO DE USUÁRIO Gustavo Henrique Rodrigues Pinto Tomas 317624 AGENDA Introdução: Cloud Computing Modelos de Implementação Modelos de Serviço Eucalyptus

Leia mais

MANUAL CLIENTE TODA A

MANUAL CLIENTE TODA A MANUAL CLIENTE TODA A Qualidade GVT AOS OLHOS DOS CLIENTES. TODA A QUALIDADE GVT AOS SEUS OLHOS O Serviço de Gerência é uma ferramenta fundamental para garantir o melhor desempenho dos serviços de telecomunicações

Leia mais

SISTEMA DISTRIBUÍDO DE MONITORAMENTO/DETERMINAÇÃO DE SERVIÇOS E RECURSOS DIPONÍVEIS DE UM AMBIENTE DE GRID COMPUTACIONAL

SISTEMA DISTRIBUÍDO DE MONITORAMENTO/DETERMINAÇÃO DE SERVIÇOS E RECURSOS DIPONÍVEIS DE UM AMBIENTE DE GRID COMPUTACIONAL SISTEMA DISTRIBUÍDO DE MONITORAMENTO/DETERMINAÇÃO DE SERVIÇOS E RECURSOS DIPONÍVEIS DE UM AMBIENTE DE GRID COMPUTACIONAL Thais Cabral de Mello, Bruno Schulze, Luis Rodrigo de Oliveira Gonçalves 1 Laboratório

Leia mais

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br FACULDADE PITÁGORAS DISCIPLINA FUNDAMENTOS DE REDES REDES DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br Material elaborado com base nas apresentações

Leia mais

REDE DE COMPUTADORES

REDE DE COMPUTADORES REDE DE COMPUTADORES Evolução histórica das redes de computadores Prof. Airton Ribeiro de Sousa E-mail: airton.ribeiros@gmail.com 1 Objetivos de Aprendizagem Ao final deste módulo você estará apto a conceituar

Leia mais

Universidade de Brasília

Universidade de Brasília Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Lista de exercícios Gerência de Redes,Turma A, 01/2010 Marcelo Vale Asari 06/90708 Thiago Melo Stuckert do Amaral

Leia mais

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Professora: Sheila Cáceres Computador Dispositivo eletrônico usado para processar guardar e tornar acessível informação. Tópicos de Ambiente

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

Revisão. Karine Peralta karine.peralta@pucrs.br

Revisão. Karine Peralta karine.peralta@pucrs.br Revisão Karine Peralta Agenda Revisão Evolução Conceitos Básicos Modelos de Comunicação Cliente/Servidor Peer-to-peer Arquitetura em Camadas Modelo OSI Modelo TCP/IP Equipamentos Evolução... 50 60 1969-70

Leia mais

Sistemas de Informação

Sistemas de Informação Sistemas de Informação Prof. M.Sc. Diego Fernandes Emiliano Silva diego.femiliano@gmail.com Agenda Infraestrutura de TI Infraestrutura de TI: hardware Infraestrutura de TI: software Administração dos recursos

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Capítulo 1 Introdução Material de suporte às aulas de Sistemas Distribuídos de Nuno Preguiça Copyright DI FCT/ UNL / 1 NOTA PRÉVIA A apresentação utiliza algumas das figuras do livro

Leia mais