universidade federal do parÁ curso de sistemas de ... · universidade federal do parÁ curso de...

UNIVERSIDADE FEDERAL DO PARÁ CURSO DE SISTEMAS DE INFORMAÇÃO

Campus de Marabá

ESTUDO E IMPLEMENTAÇÃO DE TECNOLOGIAS DE CLUSTERING HPC (ALTA CAPACIDADE DE

PROCESSAMENTO): CLUSTER CLASSE BEOWULF E OPENMOSIX

Ericson Sarmento Costa Rogério Rômulo da Silva

Warley Murici Valente Junior

MARABÁ 2008

UNIVERSIDADE FEDERAL DO PARÁ CURSO DE SISTEMAS DE INFORMAÇÃO

Campus de Marabá





Trabalho de Conclusão de Curso apresentado à Universidade Federal do Pará, como parte dos requisitos necessários para obtenção do Título de Bacharel em Sistemas de Informação.

Orientadora: Prof.ª Msc. Alessandra Mariana dos Santos Oliveira Co-orientadora: Prof.ª Msc. Jasmine Priscyla Leite de Araújo

MARABÁ 2008





Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do grau de Bacharel em

Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação da

Universidade Federal do Pará.

Marabá-PA, 21 de dezembro de 2007.

______________________________________

Orientador(a): Profª. Msc. Alessandra Mariana dos Santos Oliveira UFPA

______________________________________

Co-orientador (a): Profª. Msc. Jasmine Priscyla Leite de Araújo UFPA

______________________________________

Prof. Msc. Leonardo Brasil Felipe UFPA

______________________________________

Profª. Esp. Rita Castro UFPA

MARABÁ 2008

IV

Agradecimentos

“Agradeço a Deus por me dar a oportunidade e

sabedoria, a minha família que me apoiaram nos momentos em

que eu mais precisava, as queridas amigas professoras do curso

de bacharelado em sistemas de informação e a minha Elen,

querida companheira, pela paciência e compreensão.”

Ericson Sarmento

“Agradeço a minha mãe pela paciência e apoio nos

momentos corridos e difíceis. A minha namorada pela

compreensão dos dias que não pude vê-la nem telefoná-la. Aos

amigos universitários que auxiliaram. A UFPA pela

oportunidade e bolsa para realização do presente trabalho. De

forma geral, a todos que colaboraram de forma de direta ou

indireta. E, em especial, a meu pai, em memória.”

Rogério Rômulo

“Agradeço primeiramente a Deus, aos meus pais e meus

avós por todo o apoio e orientação que me deram durante o

desenvolvimento deste trabalho. Agradeço também aos meus

amigos, irmãos e meu cunhado por estarem sempre ao meu lado.

A minha namorada Aline pela paciência e carinho que tem me

dado no decorrer do projeto. A UFPA pela oportunidade de ser

colaborador de modo a proporcionar melhor aquisição de acervo

bibliográfico para o referido trabalho.”

Warley Junior

V

Resumo

A globalização é um processo que acelera as inovações tecnológicas, influenciando diretamente o cotidiano de grandes empresas e profissionais, principalmente da área da informática. Nesse contexto encontra-se uma crescente demanda por um alto poder de processamento. Uma das alternativas aplicada é o processamento paralelo, onde a relação custo-benefício faz dos Clusters de computadores a melhor solução na maioria dos casos. Este projeto descreve a implementação de Clusters de alta performance Beowulf e OpenMosix, os tipos mais utilizados nos diversos setores do mercado, possibilitando entendimento, análise e réplica dos trabalhos realizados.

Palavras-chave: Cluster Beowulf, Cluster OpenMosix, Sistemas Distribuídos.

VI

Abstract Globalization is a process that speeds up the technologies innovations, influencing directly big enterprises and professionals daily, mainly of the informatics area. In this context, we found a crescent demand for a high processing power. One of the applied alternatives is parallel processing, where the coast-benefit relation do these of computers Clusters the best solution in the cases majority. This project describes the implementation of high performance Clusters Beowulf and OpenMosix, they are the most used types on several market sectors, enabling understanding, analysis and retort of the realized works.

Key Words: Cluster Beowulf, Cluster OpenMosix, Distributed Systems.

VII

Sumário

Agradecimentos ...................................................................................................................... IV

Resumo ..................................................................................................................................... V

Abstract ................................................................................................................................... VI

Lista de Figuras ....................................................................................................................... X

Lista de Tabelas .................................................................................................................... XII

CAPÍTULO 1 – Introdução ................................................................................................... 13

1.1 Considerações Iniciais .................................................................................................... 13

1.2 Justificativa ..................................................................................................................... 13

1.3 Objetivo .......................................................................................................................... 14

1.3.1 Objetivo Geral .......................................................................................................... 14

1.3.2 Objetivos Específicos ............................................................................................... 14

1.4 Metodologia .................................................................................................................... 15

1.5 Descrição do Trabalho .................................................................................................... 16

CAPÍTULO 2 – Introdução a Computação Paralela e Sistemas Distribuídos ................. 18


2.2 Histórico e Evolução dos Computadores ........................................................................ 20

2.3 Os Supercomputadores ................................................................................................... 22

2.4 Computadores de Arquitetura Paralela ........................................................................... 25

2.4.1 Tipos de Paralelismo ................................................................................................ 28

2.4.2 Níveis de Paralelismo ............................................................................................... 29

2.5 Modelos de Arquiteturas de Computadores .................................................................... 30

2.5.1 Arquitetura SISD (Single Instruction Single Data) .................................................. 31

2.5.2 Arquitetura SIMD (Single Instruction Multiple Data) ............................................. 31

2.5.3 Arquitetura MISD (Multiple Instruction Single Data) ............................................. 32

2.5.4 Arquitetura MIMD (Multiple Instruction Multiple Data) ........................................ 33

2.5.4.1 Arquitetura MIMD (Multiple Instruction Multiple Data) com memória compartilhada ................................................................................................................ 33

2.5.4.2 Arquitetura MIMD (Multiple Instruction Multiple Data) com memória distribuída ...................................................................................................................... 34

2.6 Sistemas Distribuídos ..................................................................................................... 35

2.6.1 Sistemas Distribuídos Síncronos .............................................................................. 36

VIII

2.6.2 Sistemas Distribuídos Assíncronos .......................................................................... 37

2.6.3 Sistemas Distribuídos: Software .............................................................................. 37

2.6.4 Exemplo de Sistemas Distribuídos ........................................................................... 38

2.7 Considerações Finais ...................................................................................................... 39

CAPÍTULO 3 – Cluster de Computadores .......................................................................... 40


3.2 Definição ......................................................................................................................... 41

3.3 Elementos e Funcionalidades de um Cluster .................................................................. 42

3.4 Classificação dos Clusters .............................................................................................. 43

3.5 Tipos de Cluster .............................................................................................................. 44

3.5.1 Cluster de Alto Desempenho ................................................................................... 45

3.5.1.1 Cluster Beowulf: Um Cluster de Alta Performance .......................................... 46

3.5.1.2 Cluster Openmosix: Um Cluster Flexível de Alto Desempenho ....................... 49

3.5.2 Cluster de Alta Disponibilidade ............................................................................... 53

3.5.3 Cluster de Balanceamento de Carga......................................................................... 55


CAPÍTULO 4 – Criando um Cluster Beowulf ..................................................................... 59


4.2 Elementos Necessários ................................................................................................... 59

4.3 Red Hat Linux 9.0 ........................................................................................................... 60

4.3.1 Instalando o Red Hat ................................................................................................ 60

4.3.2 Comandos Básicos do Linux .................................................................................... 63

4.4 Configuração ................................................................................................................... 64

4.4.1 Configurando os endereços lógicos.......................................................................... 65

4.4.2 Resolvendo o nome das máquinas ........................................................................... 66

4.4.3 Configurando um relacionamento de confiança....................................................... 66

4.4.4 Permitindo o uso de comandos remotos ................................................................... 67

4.4.5 Configurando o Servidor de Sistemas de Arquivos ................................................. 67

4.4.6 Configurando o Servidor de Tempo ......................................................................... 68


CAPÍTULO 5 – Gerenciando e Testando o Cluster Beowulf ............................................. 70


IX

5.2 Gerenciamento ................................................................................................................ 70

5.2.1 Beowulf Watch (bWatch)......................................................................................... 71

5.2.2 Instalação .................................................................................................................. 71

5.3 Paralelismo ...................................................................................................................... 73

5.3.1 MPICH ..................................................................................................................... 74

5.3.2 Instalação do MPICH ............................................................................................... 74

5.3.3 Utilizando o MPICH ................................................................................................ 75

5.4 Ferramentas de Análise de Performance ........................................................................ 75

5.4.1 Netpipe ..................................................................................................................... 76

5.4.2 LLCBench ................................................................................................................ 78

5.5 Testes e Resultados ......................................................................................................... 80

5.5.1 Instalação do PovRay ............................................................................................... 81

5.5.2 Utilizando o PovRay ................................................................................................ 81


CAPÍTULO 6 – Fundamentos do Cluster OpenMosix ....................................................... 87


6.2 Utilização do Cluster OpenMosix em Sistemas de Geoprocessamento ......................... 87

6.3 O Cluster OpenMosix ..................................................................................................... 88

6.4 A Ferramenta SPRING ................................................................................................... 89


CAPÍTULO 7 – Aplicação do Cluster OpenMosix ao Geoprocessamento ....................... 91

7.1 Considerações iniciais ..................................................................................................... 91

7.2 Implementação da infra - estrutura ................................................................................. 91

7.3 Configuração ................................................................................................................... 92

7.4 Instalação do SPRING .................................................................................................... 98

7.5 Resultados ....................................................................................................................... 99

7.6 Considerações Finais .................................................................................................... 102

CAPÍTULO 8 – Conclusão .................................................................................................. 104

Referências Bibliográficas ................................................................................................... 105

X

Lista de Figuras

Figura 2.1: Columbia, o novo (2004) cluster da NASA ......................................................... 19

Figura 2.2: Modelo de Von Neumann ..................................................................................... 21

Figura 2.3: Exemplo de um Supercomputador ....................................................................... 23

Figura 2.4: Paralelismo de Dados ........................................................................................... 28

Figura 2.5: Paralelismo Funcional .......................................................................................... 28

Figura 2.6: Paralelismo de Objetos ......................................................................................... 29

Figura 2.7: Modelo de Arquitetura SISD ................................................................................ 31

Figura 2.8: Modelo de Arquitetura SIMD ............................................................................... 32

Figura 2.9: Modelo de Arquitetura MISD ............................................................................... 32

Figura 2.10: Modelo de Arquitetura MIMD ........................................................................... 33

Figura 2.11: Modelo de Arquitetura MIMD com memória compartilhada ............................ 34

Figura 2.12: Modelo de Arquitetura MIMD com memória distribuída .................................. 35

Figura 2.13: Projeto Seti at home ............................................................................................ 39

Figura 3.1: The Borg, um cluster beowulf .............................................................................. 47

Figura 3.2: Estrutura física de um cluster beowulf ................................................................. 48

Figura 3.3: Migração de processos num cluster Openmosix .................................................. 52

Figura 3.4: Estrutura física de um cluster de alta disponibilidade .......................................... 54

Figura 3.5: Exemplo de arquitetura de um cluster de balanceamento de carga ...................... 57

Figura 4.1: Tela inicial da instalação ...................................................................................... 61

Figura 4.2: Configuração para habilitar a máquina a acessar a rede e a internet .................... 62

Figura 4.3: Iniciação do processo de instalação do Red Hat ................................................... 62

Figura 5.1: O bWatch adaptado para o Projeto Cluster Beowulf ............................................ 72

Figura 5.2: Gráfico do tempo de processamento pelo tamanho do bloco em bytes ................ 77

Figura 5.3: Gráfico da vazão pelo tamanho do bloco em bytes .............................................. 77

Figura 5.4: Teste de performance com BLAS......................................................................... 79

Figura 5.5: O vaso espacial skyvase.pov................................................................................. 82

XI

Figura 5.6: Resultado da renderização da imagem skyvase.pov utilizando 1 nó .................... 82

Figura 5.7: Resultado da renderização da imagem skyvase.pov utilizando 2 nós .................. 83

Figura 5.8: Resultado da renderização da imagem skyvase.pov utilizando 3 nós .................. 83

Figura 6.1: Interface principal do SPRING ............................................................................. 90

Figura 7.1: Tela principal do Cluster knoppix ........................................................................ 92

Figura 7.2: Carregador de boot do knoppix ............................................................................ 93

Figura 7.3: Interface do OpenMosix Migmon ........................................................................ 94

Figura 7.4: Interface do OpenMosix View.............................................................................. 95

Figura 7.5: Interface do OpenMosix Procs ............................................................................. 95

Figura 7.6: Interface do Mosmon ............................................................................................ 96

Figura 7.7: Imagem de satélite CIBERS, região da cidade de Marabá – PA .......................... 99

Figura 7.8: Interface do SPRING no processo de segmentação de imagens........................100

Figura 7.9: Tela do SPRING em processo de segmentação automática na sua finalização..101

Figura 7.10: Detalhe do balanceamento de carga utilizando-se o software SPRING ........... 102

XII

Lista de Tabelas

Tabela 1.1: Cronograma do projeto ......................................................................................... 16

Tabela 2.1: Relação dos dez maiores supercomputadores do mundo ..................................... 24

Tabela 2.2: Taxonomia de Flynn ............................................................................................. 31

Tabela 4.1: Comandos de manipulação de arquivos ............................................................... 63

Tabela 4.2: Comandos sobre processos do sistema ................................................................. 63

Tabela 4.3: Descompactar arquivos ........................................................................................ 64

Tabela 4.4: Compactar arquivos .............................................................................................. 64

Tabela 4.5: Resolução dos nomes das máquinas que compõem o cluster............................... 66

Tabela 5.1: Tempo de renderização das figuras determinado pelo número de nós ................. 84

Tabela 5.2: Avaliação do cluster baseado no arquivo skyvase.pov ........................................ 85

Capítulo 1 – Introdução

13

CAPÍTULO 1 – Introdução

1.1 Considerações Iniciais

Todo projeto em uma empresa, ou em uma universidade, acarreta custos e prazo. Estes

fatores são de suma importância para o sucesso ou fracasso destes e até mesmo para

determinar se são no mínimo viáveis. Custos muito altos podem inviabilizar algum projeto,

sendo este abandonado muito antes de ser começado. Por outro lado, o prazo é um fator

crítico, pois representa o compromisso do projeto com os seus financiadores e seus objetivos.

Nesse sentido, muitos projetos esbarram em um problema muito comum, que constantemente

faz parte das atividades: a possibilidade de resolver grandes problemas com baixo custo e

curtíssimo prazo. Desta forma, os sistemas de supercomputação são a melhor alternativa, nos

tempos atuais, para resolver o problema do prazo, onde é necessária a execução de tarefas em

pouco tempo. Já os sistemas distribuídos de supercomputação, em especial os clusters de

computadores, são uma alternativa barata para a supercomputação e, em conseqüência,

resolvem os problemas de prazo e custo, sendo esta a solução apresentada neste trabalho.

1.2 Justificativa

Atualmente, há um crescimento da demanda por supercomputação, devido ao fato do

crescente aumento da incorporação de tecnologia da informação pelas empresas e instituições,

como forma de melhorar seus processos internos e externos.

As utilizações de clusters vêm crescendo rapidamente como alternativa de escolha

para construção de sistemas de alto desempenho para computação paralela. O rápido avanço

no desenvolvimento de microprocessadores e de redes de altíssimas velocidades com

componentes de fácil disponibilidade no mercado favorece a construção deste ambiente

(PITANGA, 2004).

Esta mudança no método de trabalho acarreta altos custos, devido a esta tecnologia ser

importada, sendo este um verdadeiro impasse, pois se busca um equilíbrio entre custos e

prazo. Custos altos inviabilizam a troca, porém a necessidade por supercomputação aumenta,


14

e neste quadro é necessário realizar sacrifícios para que o trabalho seja terminado. Além

disso, muitas vezes esta tecnologia se defasa rapidamente, pois a demanda aumenta e estes

sistemas não são capazes de aumentar sua oferta e quando são os custos tornam o projeto

insustentável. Todos estes fatores levam a maiores custos ainda, pois desta forma é necessário

trocar o equipamento por um com maior capacidade e aumentar os investimentos nos

processos operacionais. Todos estes problemas seriam resolvidos com as arquiteturas

distribuídas, tais como os clusters de computadores.

Pitanga (2004) cita o grande potencial de escalabilidade destes clusters, uma vez que

trabalham com arquitetura aberta, independência de hardware, software livre, e, ainda, utiliza

tecnologias comuns e já consagradas como o protocolo TCP/IP, podendo se utilizar da

internet como suporte.

Nesse contexto, os clusters podem ser usados em uma infinidade de aplicações,

basicamente em qualquer uma que exija grandes capacidades de processamento, solucionando

problemas antigos da supercomputação, como o altíssimo custo de aquisição e manutenção

dos equipamentos, uso de softwares proprietários e caros, total dependência dos fornecedores,

bem como dificuldades de atualizações (PITANGA, 2004).

1.3 Objetivo

1.3.1 Objetivo Geral

O objetivo geral deste trabalho é a implementação da tecnologia de Cluster de

computadores classe Beowulf e Openmosix, inserindo conceitos de clusterização, suas

aplicações, a fim de prover as informações necessárias à construção de um multicomputador

de baixo custo e alto desempenho para utilização em ambientes acadêmicos e comerciais.

1.3.2 Objetivos Específicos

• Estudo sobre a tecnologia de cluster;

• Estudo sobre Alta Capacidade de Processamento;

• Implementação de Cluster Beowulf, com estudo de caso de aplicação;

• Implementação de Cluster Openmosix, com estudo de caso de aplicação.


15

1.4 Metodologia

A metodologia a ser seguida para o desenvolvimento deste projeto consiste em uma

pesquisa bibliográfica sobre Sistemas Distribuídos e Clusters de alto desempenho de

computação. Por fim são demonstrados dois estudos de caso de implementação: um cluster

classe Beowulf e outro OpenMosix. O cluster OpenMosix será aplicado ao processamento de

imagens em uma ferramenta de geoprocessamento (SPRING). O cluster Beowulf será

aplicado a renderização de imagens, onde serão utilizadas bibliotecas de álgebra linear

(LLCBench) para realizar testes de performance.

O sistema operacional usado na implementação do cluster Beowulf foi o Linux Red

Hat 9.0, no entanto quaisquer outras distribuições Linux poderiam ser utilizadas. E no cluster

OpenMosix será utilizada uma versão pré-compilada do kernel linux 2.4 com o OpenMosix

baseada na distribuição Knoppix, chamada Cluster-Knoppix.

Serão utilizados para o desenvolvimento do projeto três computadores pessoais com

256 de MB de RAM, HD de 40 GB, processador Athlon XP 2600+ 1.92 GHz, cada uma com

duas placas de rede on-board e off-board, Swicht Fast Ethernet D - Link de 16 portas. Todas

as máquinas estão presentes no Laboratório de Informática II do Curso de Bacharelado em

Sistemas de Informação da Universidade Federal do Pará (UFPA), Campus de Marabá,

Núcleo I.

As ferramentas utilizadas para a implementação do cluster Beowulf são todas Open-

Source, para gerência e análise de desempenho e otimizações do cluster, dentre elas podem

ser citadas: Mpich, BWacht, PovRay, LLCBench, etc. Para o Cluster OpenMosix será

utilizada somente a versão pré-compilada do Cluster-Knoppix 3.6. A Tabela 1.1 mostrada a

seguir, apresenta o cronograma do desenvolvimento do projeto, o qual teve período de

realização de 1 ano.


16

Tabela 1.1: Cronograma do projeto

Fonte: Elaboração própria

1.5 Descrição do Trabalho

Este trabalho está dividido em sete capítulos. Inicialmente, no Capítulo 1, são

demonstradas as considerações iniciais sobre o trabalho, apresentando-o de uma forma

sucinta, assim como sua justificativa de implementação e objetivos.

Logo a seguir, no Capítulo 2, é mostrado um breve histórico sobre a evolução dos

clusters de computadores, as classificações das arquiteturas computacionais e em seguida

conceitos sobre Sistema Distribuídos.

No Capítulo 3 serão descritos em detalhes os princípios que norteiam os clusters de

computadores, sua utilização, finalidades, histórico e características, mostrando também a

justificativa de serem inseridos na categoria de sistemas de alta capacidade de processamento.

Ao final deste capítulo, será possível compreender as diferenças que existem entre os

clusters de alta capacidade de processamento e os supercomputadores proprietários, e,

também, entender a diferença entres os clusters de balanceamento de carga e os de alta

disponibilidade.

Abr Mai Jun Jul Ago Set Out Nov Dez

Pesquisa Bibliográfica x X

Desenvolvimento do projeto x x

Instalação e configuração x x

Testes X

Análise dos resultados x x

Confecção do Trabalho de

Conclusão de Curso x


17

Na seqüência, no Capítulo 4, serão estudadas as ferramentas utilizadas, bem como sua

obtenção e sua função no cluster. Neste capítulo, haverá uma familiarização em relação ao

cluster de classe Beowulf.

No Capítulo 5, será abordada a implementação de um cluster de alto desempenho,

programável, baseado em sistema operacional e aplicativos abertos, independente de

hardware: o cluster Beowulf. Será mostrada passo a passo a implementação e um estudo de

caso da aplicação desta tecnologia. Por fim, será discutido o desempenho obtido nesta

arquitetura.

No Capítulo 6, será estudada a ferramenta de geoprocessamento utilizada no estudo de

caso da aplicação do cluster de balanceamento de carga OpenMosix, e, também, a origem

deste cluster e suas aplicações.

No Capítulo 7, será feito o estudo de caso, com a aplicação do cluster OpenMosix ao

geoprocessamento, de forma a explicitar, passo a passo, como configurá-lo e aplicá-lo e, por

fim, analisar os resultados obtidos.

No Capítulo 8, serão demonstradas as conclusões gerais do trabalho apresentado,

levando em consideração uma visão crítica sobre a aplicação desta tecnologia para a resolução

de problemas, bem como o quadro nacional observado sobre a utilização destas tecnologias.

Capítulo 2 – Introdução a Computação Paralela e Sistemas Distribuídos

18

CAPÍTULO 2 – Introdução a Computação Paralela e Sistemas Distribuídos


As aplicações de softwares utilizadas nas empresas atualmente exigem cada vez mais

poder de processamento, pois processar rápido e eficientemente é um recurso indispensável

para o bom andamento do negócio. Tarefas que exigem grande poder computacional, até

pouco tempo atrás, só podiam ser executadas por supercomputadores. No entanto, nos últimos

anos, a Tecnologia da Informação (TI) evoluiu rapidamente fazendo com que as organizações

usufruíssem dessa evolução. Com o avanço tecnológico dos computadores pessoais e das

estruturas de redes locais, cada vez mais velozes, surge a idéia de utilizar o poder individual

destes computadores, conectando-os através de um meio físico de comunicação e dotados de

softwares específicos para executarem aplicações paralelas e distribuídas, dando ao usuário

transparência de uma única máquina quanto ao seu funcionamento. Assim, quando se utiliza

dois ou mais computadores em conjunto para resolver um determinado problema, tem-se o

que é denominado de cluster que, do inglês, significa agrupamento, aglomerado ou

concentração (PITANGA, 2004).

Desta forma, um cluster, ou aglomerado de computadores, é formado por um

conjunto de computadores, que utiliza-se de um tipo especial de sistema operacional

classificado como sistema distribuído. É construído muitas vezes a partir de computadores

convencionais (personal computers), sendo que estes vários computadores são ligados em

rede e comunicam-se através do sistema de forma que trabalham como se fosse uma única

máquina de grande porte (PITANGA, 2004).

De uma maneira geral, os clusters podem ser formados por computadores dedicados

ou agrupados fisicamente em um ambiente. Outra maneira de formação é através de uma

conexão virtual de computadores espalhados em uma rede. Neste método, softwares

apropriados auxiliam as estações distribuídas ao longo da rede para que possam servir a


19

solicitações de terceiros como seus recursos computacionais (DANTAS, 2005). A Figura 2.1

a seguir, ilustra um exemplo de um cluster.

Figura 2.1: Columbia, o novo (2004) cluster da NASA executando Linux (10. 240 processadores)

Fonte: NASA, 2007.

Assim, os clusters podem ser divididos em três categorias básicas: Alta

Disponibilidade, Alto Desempenho e Balanceamento de Carga.

Segundo Alecrim (2004), a Alta Disponibilidade se refere a sistemas que praticamente

não param de funcionar. Usados em aplicações de missão crítica, eles costumam ter meios

eficientes de proteção e de detecção de falhas. Já um cluster de Alto Desempenho refere-se à

distribuição equilibrada de processamento aos nós (computadores) do cluster. O cluster de

Balanceamento de Carga controla a distribuição equilibrada do processamento para os nós

(computadores) envolvidos no cluster.

Nesse contexto, os clusters podem ser usados em uma infinidade de aplicações,

basicamente em qualquer uma que exija grandes capacidades de processamento, solucionando

problemas antigos da supercomputação, como o altíssimo custo de aquisição e manutenção

dos equipamentos, uso de softwares proprietários e caros, total dependência dos fornecedores,

bem como dificuldades de atualizações (PITANGA, 2004).

Os clusters de computadores apresentam diversas vantagens em relação aos

gigantescos supercomputadores multiprocessados de memória compartilhada. Entre outras

vantagens existentes, tem-se a alta escabilidade, onde é possível adicionar mais equipamentos


20

computacionais ao cluster; facilidade em obter equipamentos e manutenção; baixo custo na

aquisição tanto de software quanto de hardware, pois maior parte dos softwares é de

distribuição livre e os computadores desktops são de baixo custo.

O estudo da computação em cluster já gerou o desenvolvimento de diversos ambientes

de programação, com inúmeros testes de interconexão entre os nós, inclusive com a

reimplementação de bibliotecas já existentes. Adicionalmente, foram estabelecidos diversos

grupos de estudos ao redor do mundo e, conseqüentemente, muitos artigos, dissertações e

teses foram elaborados. O ponto negativo nesse sentido é que todo este conhecimento

adquirido está sendo difundido por vários tipos de fontes, dificultando geralmente, um

entendimento maior e atualizado dentro deste contexto.

2.2 Histórico e Evolução dos Computadores

A primeira geração de computadores, na década de 1940, estabeleceu os conceitos

básicos da organização dos computadores eletrônicos. Os computadores desta época

utilizavam válvulas eletrônicas e uma quantidade enorme de fios. Eram muito grandes e

lentos, além de esquentarem muito. Estes computadores possuíam somente dois níveis de

linguagem de programação: o nível da linguagem de máquina, onde toda a programação era

feita, através de zeros e uns, e o nível da lógica digital, local na qual os programas eram

efetivamente executados, sendo formado nesta geração por válvulas e depois por transistores,

circuitos integrados, etc. (BRASIL ESCOLA, 2007).

Em 1946, Von Neumann sugeriu um sistema binário, que viria a se tornar à base de

outros projetos de desenvolvimento computacional subseqüente. A máquina proposta por Von

Neumann era composta por uma unidade de processamento centralizado, responsável pela

execução de operações aritméticas e lógicas, uma unidade de controle de programa, na qual

determinava quais ações executar, uma unidade de memória principal e uma unidade de

entrada e saída de dados (WEBER, 2000).

De acordo com Pitanga (2004, p.01), "o modelo de Von Neumann é composto

basicamente por um processador, memória e dispositivos de entrada e saída de dados ou

periféricos. O processador executa as instruções seqüencialmente, de acordo com a ordem

estabelecida por uma unidade de controle". O modelo lógico de computador proposto por Von

Neumann pode ser descrito pela Figura 2.2 abaixo:

A segunda geração de computadores (1956

transistor que veio para substituir as válvulas eletrônicas e a troca dos fios de ligações por

circuitos impressos. Com estas trocas, os computadores não só ficaram mais rápidos, mas

tiveram também uma redução no tamanho dos equipamentos

energia. Além disso, com a troca das válvulas pelos transistores, não era mais necessário um

tempo para aquecimento antes do seu funcionamento. Nesse período surgem também alguns

dispositivos como impressoras, fitas magnéticas,

com cartão perfurado (RODRIGO, 2006).

A invenção dos CIs (Circuitos Integrados) proporcionou mais um grande avanço na

evolução da computação e com eles surgem os computadores de terceira geração (1964

1970). Os transistores foram substituídos por esta nova tecnologia e sua utilização tornou os

equipamentos mais compactos, rápidos e confiáveis, com baixo consumo de energia e, um

custo ainda menor que os das gerações anteriores. Nesta geração, também foram

desenvolvidas as linguagens de programação de alto nível orientada a procedimentos

(RODRIGO, 2006).

O período decorrente de 1970 até os dias de hoje, ficou caracterizado pelo

aperfeiçoamento das tecnologias já existentes, denominando


21

da por uma unidade de controle". O modelo lógico de computador proposto por Von

Neumann pode ser descrito pela Figura 2.2 abaixo:

Figura 2.2: Modelo de Von Neumann

Fonte: DANTAS, 2005.

A segunda geração de computadores (1956 – 1963) ficou marcad



tiveram também uma redução no tamanho dos equipamentos, nos custos e no consumo de



dispositivos como impressoras, fitas magnéticas, discos de armazenamento e computadores

com cartão perfurado (RODRIGO, 2006).


evolução da computação e com eles surgem os computadores de terceira geração (1964

Os transistores foram substituídos por esta nova tecnologia e sua utilização tornou os



nvolvidas as linguagens de programação de alto nível orientada a procedimentos


aperfeiçoamento das tecnologias já existentes, denominando-se os computadores da quar

Introdução a Computação Paralela e Sistemas Distribuídos

da por uma unidade de controle". O modelo lógico de computador proposto por Von

1963) ficou marcada pela invenção do



, nos custos e no consumo de



discos de armazenamento e computadores


evolução da computação e com eles surgem os computadores de terceira geração (1964 –

Os transistores foram substituídos por esta nova tecnologia e sua utilização tornou os



nvolvidas as linguagens de programação de alto nível orientada a procedimentos


se os computadores da quarta


22

geração. Tecnologias de integração dos CIs (Circuitos Integrados) foram sendo

desenvolvidas, abrigando milhões de componentes eletrônicos em um pequeno espaço ou

chip, denominados por escala de integração: Escala de integração grande (LSI - Large Scale

of Integration), escala de integração muito grande (VLSI - Very Large Scale of Integration) e

escala de integração ultragrande (ULSI - Ultra Large Scale of Integration). Assim, avanços

significativos com a otimização dos componentes e o surgimento dos microprocessadores e

microcomputadores fizeram com que houvesse uma explosão no mercado de computadores a

partir de 1980, sendo fabricados em escala comercial, uma vez que, computadores anteriores a

esta geração eram restritos a poucas empresas e universidades, devido a custos e tamanho dos

equipamentos. A partir daí, os avanços tecnológicos vem sendo cada vez maiores até chegar

nos microcomputadores atuais, com velocidades cada vez maiores e com custos muito mais

baixo, se comparados com as tecnologias anteriores (PITANGA, 2004).

Sendo assim, a indústria da computação é uma das indústrias que mais cresce e é

abastecida pelos desenvolvimentos tecnológicos rápidos na área de software e hardware. Os

avanços de tecnologias de hardware incluem o desenvolvimento e fabricação de chips e

processadores rápidos e baratos, com largura de banda elevada e baixa latência de

interconexão. Destacam-se recentemente avanços na tecnologia VLSI, que deram um dos

principais passos no desenvolvimento de computadores seqüenciais e paralelos. Assim como

o desenvolvimento de hardware teve grande evolução, o desenvolvimento de software

também evoluiu rapidamente. Softwares maduros como sistemas operacionais, linguagens de

programação e ferramentas de desenvolvimento estão disponíveis no mercado a fim de suprir

as necessidades comerciais (BUYYA, 1999).

2.3 Os Supercomputadores

Um Supercomputador é um computador com altíssima velocidade de processamento e

grande capacidade de memória, empregado em pesquisas científicas e militares (PITANGA,

2004).

Eles são construídos com base em praticamente os mesmos componentes que são

utilizados em micros pessoais, como memória, disco rígido (HD - Hard Disk) e

processadores. O que diferencia dos supercomputadores é que vários processadores, HDs e


23

módulos de memória são combinados para criar um sistema incrivelmente rápido (GUIA DO

HARDWARE, 2007). A Figura 2.3 a seguir demonstra um exemplo de um supercomputador:

Figura 2.3: Exemplo de um Supercomputador

Fonte: TOP500, 2007.

A supercomputação teve início quando, em meados da década de 70, Seymor Cray

fundou a companhia Cray Research, que tinha por objetivo utilizar todas as novas tecnologias

que envolviam semicondutores. O primeiro computador construído pela Cray Research foi o

Cray I. Este computador era mais rápido do que qualquer outro construído até então, daí

chamá-lo de supercomputador, tanto que, para mantê-lo ocupado em 100% do tempo, foi

utilizado outro computador, o CDC 6600. Esses supercomputadores atingiam velocidade de

até 100 megaflops, ou 100 milhões de cálculos de ponto flutuante por segundo. Devido às

suas qualidades, principalmente no tempo de processamento muito inferior ao dos outros

modelos, o Cray I foi adquirido rapidamente por várias companhias das mais diversas áreas,

estabelecendo assim um vasto mercado para os supercomputadores. Posteriormente, foi criado

o Cray-XMP que atingiu a marca de 1 Gigaflop, ou 1 bilhão de cálculos de ponto flutuante

por segundo. Tais computadores foram largamente utilizados no programa espacial norte-

americano para a realização de cálculos de lançamento de foguetes (LISBOA & AUGUSTO,

2002).

Atualmente, os supercomputadores são fabricados por empresas como CRAY, IBM,

DELL, HP, APPLE etc. A Tabela 2.1 a seguir mostra a relação dos dez mais rápidos

supercomputadores do mundo até 2007.


24

Tabela 2.1: Relação dos dez maiores supercomputadores do mundo

Rank Site Computador

1 DOE/NNSA/LLNL United States

BlueGene/L - eServer Blue Gene Solution

IBM

2 Forschungszentrum Juelich (FZJ) Germany

JUGENE - Blue Gene/P Solution IBM

3 SGI/New Mexico Computing Applications Center (NMCAC)

United States

SGI Altix ICE 8200, Xeon quad core 3.0 GHz SGI

4 Computational Research Laboratories, TATA SONS

Índia

EKA - Cluster Platform 3000 BL460c, Xeon 53xx 3GHz, Infiniband

Hewlett-Packard

5 Government Agency Sweden

Cluster Platform 3000 BL460c, Xeon 53xx 2.66GHz, Infiniband

Hewlett-Packard

6 NNSA/Sandia National Laboratories United States

Red Storm - Sandia/ Cray Red Storm, Opteron 2.4 GHz dual core

Cray Inc.

7 Oak Ridge National Laboratory United States

Jaguar - Cray XT4/XT3 Cray Inc.

8 IBM Thomas J. Watson Research Center United States

BGW - eServer Blue Gene Solution IBM

9 NERSC/LBNL United States

Franklin - Cray XT4, 2.6 GHz Cray Inc.

10 Stony Brook/BNL, New York Center for Computational Sciences

United States

New York Blue - eServer Blue Gene Solution

IBM

Fonte: TOP500, 2007.

Vale ressaltar o quanto foi rápida a evolução da computação, pois pode-se comparar os

supercomputadores mais antigos em relação aos PCs (Computadores Pessoais) atuais. Hoje

em dia, um simples computador pessoal oferece maior capacidade de processamento do que

um supercomputador de alguns anos atrás. De uma maneira geral, os computadores estão se

tornando cada vez mais rápidos, pequenos e eficientes. Desta forma, equipamentos que

atualmente são considerados supercomputadores podem perder seu lugar para os

computadores pessoais em um tempo relativamente pequeno.


25

2.4 Computadores de Arquitetura Paralela

Atualmente, grande parte dos computadores ainda descende da arquitetura de Von

Neumann, ou arquitetura serial, pois empregam um único processador. Essa arquitetura,

aliada aos avanços da microeletrônica, ofertou ao mercado atual computadores rápidos e

baratos. No entanto, o aumento da capacidade computacional dos dispositivos, depende

diretamente ao desenvolvimento tecnológico e enfrenta um limite de velocidade, que é ditado

pelas leis da física (RODRIGO, 2006).

Uma comparação entre o mundo real e o computacional é citada por Zelenovsky e

Mendonça (2001). Segundo eles, caso seja feita uma comparação entre o cérebro humano e

um processador, teremos a resposta de como obter maior velocidade de processamento nas

máquinas. Pela lógica computacional, o computador é muito mais rápido para executar tarefas

como operações numéricas, classificações e comparações, porém eles apenas seguem uma

seqüência de processos programados, sendo muito inferiores ao cérebro, pois não tem a

capacidade de pensar, inovar e aprender. Por meio desta comparação, surge uma grande

dúvida: Como será que o cérebro supera os processadores, sendo que a comunicação entre os

circuitos eletrônicos é muito maior que a comunicação entre os nossos neurônios? A resposta

é simples e óbvia. O nosso cérebro opera com bilhões de neurônios em paralelo. Partindo

desta premissa, chega-se a idéia básica do processamento computacional em paralelo, ou seja,

fazendo a divisão de tarefas entre vários processadores para resolver um determinado

problema (RODRIGO, 2006).

Sabendo-se que a utilização de vários processadores pode melhorar o desempenho

computacional, surgem novas questões a partir deste contexto. Como ter um controle destes

processos de forma que o resultado seja o desejado? A fim de responder esta questão, alguns

problemas existentes em computação paralela devem ser compreendidos (RODRIGO, 2006).

Desta forma, seguirá um exemplo do mundo real: Se um pedreiro constrói uma casa em um

ano, então dois pedreiros constroem a mesma casa em meio ano. Este é conceito básico do

processamento paralelo: a divisão das tarefas. É possível seguir adiante e concluir que cem

pedreiros gastam apenas 3,6 dias. Será isto um absurdo?


26

É claro que há um limite, pois o trabalho dos pedreiros só será eficiente se estiverem

perfeitamente sincronizados e equilibrados. Este ponto é importante: todos os pedreiros

devem ter a mesma carga de trabalho. Em termos técnicos, usa-se a expressão

“Balanceamento da Carga de Trabalho”. Esse balanceamento pode ser feito de dois modos:

No primeiro modo, o trabalho de cada pedreiro é idêntico, ou seja, cada um faz 1/100 da casa.

No outro modo é usada a especialização, ou seja, alguns pedreiros “viram” cimento enquanto

outros assentam tijolos e outros tratam do encanamento, e assim por diante.

Ao se imaginar todas as tarefas que devam ser executadas para a construção da casa,

fica claro que algumas delas não poderão ser paralelizadas. Imagine 100 pedreiros para

assentar uma porta, ou 100 pedreiros em cima da casa tentando montar o telhado. A casa

acabaria por cair! Além disso, deve haver um limite para a quantidade de pedreiros que

podem trabalhar em paralelo. A partir deste limite, quanto mais pedreiros são colocados, pior

o desempenho e em conseqüência, há um aumento do tempo de construção

(GUIADOHARDWARE, 2007).

Voltando ao mundo computacional, o uso de arquiteturas paralelas tem como

principais dificuldades o controle das tarefas que estão sendo executadas em paralelo, ou seja,

sincronizar estes processos de forma que um processo não seja repetido pelo outro, e a

determinação de quantos processadores devem ser alocados para solucionar o problema,

garantindo o balanceamento de carga (RODRIGO, 2006).

Segundo Zelenovsky e Mendonça (2001, p. 2):

As dificuldades presentes no projeto do hardware de

máquinas paralelas não são tão complexas quando comparados

com os problemas de sua programação. Diz-se que os

computadores estão sempre uma geração atrasada em relação

às nossas necessidades e os programas, duas gerações

atrasadas.

O paralelismo é o ato de dividir uma tarefa originalmente seqüencial em várias sub-tarefas

(também seqüenciais), a fim de diminuir o tempo que seria gasto na realização de uma única

tarefa seqüencial. Para que se entenda melhor o conceito de paralelismo pode-se utilizar a

taxonomia de Flynn (LISBOA E AUGUSTO, 2002).


27

A taxonomia de Flynn é baseada nas relações entre dados e instruções. Tal classificação é

composta basicamente por máquinas do tipo:

• SISD (Single Instruction Single Data – uma seqüência de instruções, uma seqüência de

dados);

• SIMD (Single Instruction Multiple Data – uma seqüência de instruções, múltiplas

seqüências de dados);

• MISD (Multiple Instruction Single Data – múltiplas seqüências de instruções, uma

seqüência de dados);

• MIMD (Multiple Instruction Multiple Data – múltiplas seqüência de instruções,

múltiplas seqüências de dados);

Para a computação, o paralelismo é uma estratégia computacional utilizada para obter,

mais rapidamente, resultados de tarefas de grande complexidade, que exigem um

processamento elevado. O paralelismo tem por objetivo dividir uma tarefa em várias tarefas

menores, e enviá-las para serem processadas por vários processadores diferentes de maneira

simultânea, diminuindo consideravelmente o tempo de processamento. Essa operação pode

ser realizada tanto em máquinas multiprocessadas, quanto utilizando um conjunto de

computadores (LISBOA E AUGUSTO, 2002).

Existem complexidades pertinentes ao próprio paralelismo. Os resultados

(desempenho) podem não corresponder ao esforço (programação) empregado. Depende do

programador a responsabilidade pelo algoritmo paralelo (válido para ferramentas não

automáticas). O paralelismo pode ser classificado de três maneiras: paralelismo de dados,

paralelismo funcional e paralelismo de objeto. Além de operar em dois níveis: paralelismo de

software e paralelismo de hardware (ROCHA, 2001).


28

2.4.1 Tipos de Paralelismo

Paralelismo de Dados - O sistema paralelo executa as mesmas instruções sobre dados

diferentes. É aplicado, por exemplo, em programas que utilizam matrizes imensas e para

cálculos de elementos finitos, como por exemplo, a resolução de sistemas de equações,

multiplicação de matrizes e integração numérica. Este tipo de paralelismo é representado na

Figura 2.4 mostrada abaixo.

Figura 2.4: Paralelismo de Dados

Fonte: ROCHA, 2001.

Paralelismo Funcional - O sistema paralelo executa instruções diferentes que podem

ou não operar sobre o mesmo conjunto de dados. É aplicado em programas dinâmicos e

modulares onde cada tarefa será um programa diferente. Este tipo de paralelismo é ilustrado

na Figura 2.5 abaixo.

Figura 2.5: Paralelismo Funcional Fonte: ROCHA, 2001.

Paralelismo de Objetos - Este é o modelo mais recente, que utiliza o conceito de

objetos distribuídos por uma rede (como a Internet), capazes de serem acessados por métodos

(funções) em diferentes processadores para uma determinada finalidade, como por exemplo, a

tecnologia baseada em CORBA (Common Object Resquest Broke) e EJB (Enterprise Java

Beans). A Figura 2.6 a seguir, ilustra a arquitetura do paralelismo de objetos.


29

Figura 2.6: Paralelismo de Objetos

Fonte: ROCHA, 2001.

2.4.2 Níveis de Paralelismo

Em termos de unidade de processamento, paralelismo de hardware trata de melhorar o

desempenho dos sub-componentes da unidade central de processamento (a memória cache,

pipeline e unidades de execução múltiplas), podendo acelerar seu código de execução. Outro

aspecto de paralelismo de hardware envolve Sistemas Multiprocessados SMP (Symmetric

Multi-Processor - Multiprocessamento simétrico) para que trabalhem em um problema

computacional de uma forma paralela (ROCHA, 2001).

Há duas características nas CPUs modernas que permitem que estas suportem

execuções múltiplas: o cache e Pipeline.

• O Cache é uma área de memória, onde são armazenadas porções grandes de

programas em antecipação a sua eventual execução pela CPU (Unidade Central de

Processamento). A memória cache é da ordem de microssegundos. Tirar instruções do

cache e colocá-las no pipeline de instrução só é ligeiramente mais lento que acessar

dados que estão dentro dos próprios registros da CPU (Unidade Central de

Processamento).

• O Pipeline é uma área pequena de memória dentro da CPU onde são armazenadas as

próximas instruções que serão executadas. Pipeline de instrução ajuda a manter o

trabalho fluindo pela CPU e, para um código aperfeiçoado, manterá a CPU ocupada

contanto que o código não tenha que saltar para executar algo que está armazenado

fora do cache.


30

Estes componentes permitem aumentos significativos no desempenho de CPU.

Também requerem muita “inteligência” por parte do compilador para organizar o código

executável de tal modo que a CPU tenha uma boa chance de poder executar instruções

múltiplas simultaneamente.

O paralelismo de software pode ser explicado como o ato de fragmentar um programa, ou

seja, dividir um programa em várias partes a fim de serem executadas simultaneamente (ROCHA,

2001).

Dependendo do tipo de memória utilizada para executar o programa paralelo, pode-se ter

paralelismo de software através do uso de bibliotecas de passagens de mensagens, quando há

memória distribuída, ou através do compartilhamento de informações globais, quando há memória

compartilhada (LISBOA E AUGUSTO, 2002).

Podem ser analisadas muitas classes de problemas para se obter o paralelismo inerente

dentro deles. Alguns dos problemas mais típicos incluem modelagem meteorológica, geração

de imagens 3-D e vários tipos de simulações. Estes são os tipos de problema que contêm

“sub-problemas” dentro deles. Por exemplo, modelagem meteorológica envolve resolver

problemas relativos ao aquecimento e esfriamento da atmosfera, a absorção de luz solar por

nuvens e cidades, como também o movimento de frentes de pressão (ROCHA, 2001).

Desta forma qualquer problema que for composto de sub-problemas menores que

podem ser quantificados independentemente pode ser dividido em problemas menores e

executado de forma paralela.

2.5 Modelos de Arquiteturas de Computadores

Em 1966, Michael Flynn classificou os computadores através da análise do fluxo de

instruções e do fluxo de dados, onde o fluxo de instruções é a seqüência de instruções que é

executada pelo computador e o fluxo de dados é a seqüência de dados que é manipulada pelas

instruções. Essa classificação ficou conhecida como Taxonomia de Flynn, que é dividida em

quatro arquiteturas. A Tabela 2.2 ilustra a divisão dessas quatro arquiteturas.


31

Tabela 2.2: Taxonomia de Flynn

Fonte: MARCELINO E PAULO, 2004.

2.5.1 Arquitetura SISD (Single Instruction Single Data)

Nesse tipo, existe somente uma unidade de controle interpretando uma seqüência de

instruções que serão utilizadas em uma seqüência de dados. Nesta arquitetura, vista na Figura

2.7, utiliza-se somente um processador. A arquitetura SISD equivale aos computadores

seqüenciais convencionais (LISBOA E AUGUSTO, 2002).

Figura 2.7: Modelo da Arquitetura SISD

Fonte: LISBOA E AUGUSTO, 2002.

2.5.2 Arquitetura SIMD (Single Instruction Multiple Data)

Neste tipo, utilizam-se vários processadores ligados à unidade de controle. A unidade

de controle interpreta a seqüência de instruções e envia para os processadores a instrução

interpretada. Os processadores executarão a instrução ao mesmo tempo, porém, cada

processador utilizará uma seqüência de dados (LISBOA E AUGUSTO, 2002).

Segundo Pitanga (2004, p. 12), a arquitetura SIMD equivale "ao paralelismo de dados,

onde uma simples instrução é executada paralelamente utilizando vários dados de forma


32

síncrona, em que se executa um único programa ao mesmo tempo". A Figura 2.8 mostra toda

a organização da arquitetura SIMD.

Figura 2.8: Modelo da Arquitetura SIMD


2.5.3 Arquitetura MISD (Multiple Instruction Single Data)

Nesse tipo, a unidade de controle interpretará várias seqüências de instruções,

utilizando somente uma seqüência de dados (LISBOA E AUGUSTO, 2002).

Na classe MISD, tem-se múltiplas unidades de processamento (P), tendo para cada

processador uma unidade de controle (C) própria, recebendo um fluxo diferente de instruções

(ROSE, 2001). A Figura 2.9 abaixo ilustra o funcionamento da arquitetura MISD.

Figura 2.9: Modelo da Arquitetura MISD



33

2.5.4 Arquitetura MIMD (Multiple Instruction Multiple Data)

Nesse tipo, cada unidade de controle interpreta uma seqüência de instruções e envia

para um processador ligado a ela. Havendo várias unidades de controle, cada uma com um

processador, nota-se que há vários fluxos de instruções e de dados. Esse tipo pode ainda ser

subdivido em outros dois: arquitetura MIMD com memória compartilhada e arquitetura

MIMD com memória distribuída (LISBOA E AUGUSTO, 2002). A arquitetura MIMD está

sendo ilustrada na Figura 2.10 abaixo.

Figura 2.10: Modelo da Arquitetura MIMD


2.5.4.1 Arquitetura MIMD (Multiple Instruction Multiple Data) com

memória compartilhada

Esse tipo caracteriza as máquinas paralelas propriamente ditas (máquinas com mais de

um processador) conforme a Figura 2.11, que ilustra sua organização funcional. Possui

algumas desvantagens, tais como difícil manutenção e pouca escalabilidade, podendo haver

situações em que um processador entra em conflito ao acessar áreas de memória que estão

sendo utilizadas por outros processadores. Essa arquitetura pode, também, subdividir-se em

outras duas categorias: UMA e NUMA (LISBOA E AUGUSTO, 2002).


34

Figura 2.11: Modelo da Arquitetura MIMD com memória compartilhada


• UMA (Uniform Memory Access – Acesso Uniforme à Memória): Todos os

processadores têm o mesmo tipo de acesso a toda à memória.

• NUMA (Non Uniform Memory Access – Acesso Não Uniforme à Memória):

Todos os processadores têm o mesmo tipo de acesso a toda a memória, porém o acesso torna-

se mais lento dependo da área da memória que está sendo acessada.

2.5.4.2 Arquitetura MIMD (Multiple Instruction Multiple Data) com

memória distribuída

Este tipo é composto por máquinas multiprocessadas, cada máquina com sua própria

memória, também chamados de multicomputadores. Para que seja feita a comunicação entre

os nós são utilizados dispositivos de entrada/saída (como placas de rede comuns utilizadas em

PC’s comuns, o que caracteriza o cluster). Essa arquitetura caracteriza um cluster, pois se tem

várias CPU’s e cada CPU possui sua própria memória (memória distribuída) (LISBOA E

AUGUSTO, 2002).

Segundo Pitanga (2004 p. 14,15):

As desvantagens da memória distribuída são

basicamente duas:

• A programação é mais complicada e o paralelismo

não é tão intuitivo. Isto porque existe a necessidade de tarefas

enviarem mensagens de forma explícita a outras que estão em


35

execução em algum outro processador, e também de forma

explícita, uma tarefa precisa receber esta mensagem;

• Se exigir muita comunicação, o desempenho acaba

sendo comprometido pelo alto custo envolvido na troca de

mensagens.

A Figura 2.12 mostra o modelo da arquitetura MIMD de modo a proporcionar um

entendimento mais contextualizado da mesma.

Figura 2.12: Modelo da Arquitetura MIMD com memória distribuída


2.6 Sistemas Distribuídos

Atualmente, a área dos sistemas distribuídos é a área de computação que mais tem se

destacado em relação aos sistemas computacionais de memória compartilhada. Desta forma,

um estudo sólido de seus princípios é de fundamental importância.

Um sistema distribuído segundo a definição de Tanenbaum (2003, p.20) "é uma

coleção de computadores independentes que se apresenta ao usuário como um sistema único e

consistente"; outra definição, Dantas (2005, p.34), diz: "coleção de computadores autônomos

interligados através de uma rede de computadores e equipados com software que permita o

compartilhamento dos recursos do sistema: hardware, software e dados".

A definição de sistemas distribuídos para Pitanga (2004, p.20) “é um conjunto de

elementos que se comunicam através de uma rede de interconexão e que utilizam software de

sistema distribuído. Cada elemento é composto por um ou mais processadores e uma ou mais

memórias”.


36

Assim, a computação distribuída consiste em adicionar o poder computacional de

diversos computadores interligados por uma rede de computadores ou mais de um

processador trabalhando em conjunto no mesmo computador, para processar

colaborativamente determinada tarefa de forma coerente e transparente, ou seja, como se

apenas um único e centralizado computador estivesse executando a tarefa. A união desses

diversos computadores com o objetivo de compartilhar a execução de tarefas complexas em

subtarefas menores é conhecida como sistema distribuído.

Conforme Pitanga (2004, p. 20):

Um sistema distribuído pode ser classificado

como um conjunto de computadores com seu próprio clock e

que não possuem memória compartilhada, e é visto pelos seus

usuários como um sistema de recurso único, também chamado

de imagem única do sistema (SSI - Single System Image), que

se comunicam através de um barramento por troca de

mensagens. Estes sistemas são considerados por meio destas

características como francamente acoplados, ou seja, um

cluster ou agregado de máquinas.

2.6.1 Sistemas Distribuídos Síncronos

Neste caso, todos os processadores do sistema funcionam segundo um relógio global

comum, onde todos têm acesso. O sincronismo é um atributo de modelos computacionais e

sistemas distribuídos que está relacionado ao comportamento tanto dos processos quanto da

própria rede. Este modelo é caracterizado basicamente por limites em latência de

comunicação e em prazos de processamento, ou seja, se o sistema é síncrono, uma informação

enviada no início de um ciclo (ou passo) do relógio global, chega ao seu destino antes do

início do próximo ciclo. Na prática, a implementação de modelos síncronos, quando possível,

envolve certa complexidade, impossibilitando na maioria das vezes a sua construção. Um

exemplo disso pode ser observado na Internet, onde é impossível prever limites máximos ou

mínimos para o atraso no envio de mensagens, pois a carga da rede e o caminho a ser

percorrido pelos pacotes no momento do envio nunca são iguais (BESSANI, 2002;

AMORIM, 1998).


37

2.6.2 Sistemas Distribuídos Assíncronos

Enquanto de um lado tem-se o modelo síncrono, onde todas as variáveis importantes

do ambiente são limitadas e conhecidas, do outro lado tem-se o modelo assíncrono, onde não

existe uma limitação para as variáveis do ambiente computacional. Neste modelo, a principal

característica é a ausência total de uma base de tempo comum a todos os processadores que

compõe o sistema, ou seja, cada processador possui então um relógio local e independente dos

demais, não sendo possível fazer uma previsão exata de quanto tempo uma determinada

informação irá chegar a seu destino (AMORIM, 1998).

2.6.3 Sistemas Distribuídos: Software

O software em sistemas distribuídos, seja aplicativo ou mesmo um sistema

operacional, tem que estar de acordo com as características dos sistemas distribuídos. Ao

contrário de um sistema mono-processado, neste ambiente existe a necessidade de

sincronismo, interação e controle entre os diferentes ambientes de software, ou diferentes

instâncias, que compõem o sistema na sua totalidade (GOULART, 2002).

Para Pitanga (2004), o software é considerado um pequeno problema no

desenvolvimento de um sistema distribuído, devido à elevada complexidade que os sistemas

distribuídos apresentam. Seu desenvolvimento exige um estudo bastante profundo dessa área

e a utilização de técnicas adequadas para concepção e projeto de sistemas. O software

distribuído deve permitir aos computadores coordenarem suas atividades através de

cooperação e interação, compartilhando recursos do sistema como o hardware, software e os

dados.

De acordo com Tanenbaum (2003), foi distinguido dois tipos de sistemas operacionais

para sistemas com vários processadores: os sistemas operacionais fracamente acoplados e os

fortemente acoplados. Sistemas fracamente acoplados são aqueles onde as estações

independentes estão ligadas por uma rede local. Sendo assim cada estação tem o seu sistema

operacional. Os nodos têm baixo grau de interação e interagem quando necessário. Se a rede

local cai, aplicações individuais em cada estação podem continuar. Já um sistema fortemente

acoplado é aquele onde o software integra fortemente cada nodo da rede. Se a interligação dos


38

processadores for interrompida, a aplicação também será descontinuada. Têm-se,

basicamente, três tipos de sistemas operacionais:

• Sistemas Operacionais de Rede – Software fracamente acoplado em hardware

fracamente acoplado;

• Sistemas Operacionais Distribuídos – Software fortemente acoplado em

hardware fracamente acoplado;

• Sistemas Operacionais de Multiprocessadores – Software fortemente acoplado

em hardware fortemente acoplado.

Sistemas Operacionais de Rede permitem compartilhar diferentes recursos de uma

determinada estação entre os demais membros da rede. Um dos recursos mais importantes

para ser compartilhado é o disco, permitindo que múltiplas estações possam acessar uma

única base de dados (GOULART, 2002).

Um sistema distribuído é aquele que roda em um conjunto de máquinas sem memória

compartilhada, máquinas estas que mesmo assim aparecem como um único computador para

seus usuários (TANENBAUM, 2003).

Sistemas Multiprocessadores de tempo compartilhado são voltados para

processamentos específicos. A característica fundamental desta classe de sistema é a

existência de uma única fila de processos prontos: uma lista de todos os processos do sistema

que não estão bloqueados, e que só não estão executando por falta de processador disponível

(GOULART, 2002).

2.6.4 Exemplo de Sistemas Distribuídos

Um exemplo clássico de computação distribuída é o projeto Seti at home que visa

procurar em sinais de rádio interplanetários algum vestígio de vida extraterrestre.

O projeto Seti at home (Search for Extraterrestrial Intelligence at Home) da

Universidade da Califórnia em Berkeley tem como principal objetivo utilizar a capacidade de

processamento de centenas de milhares de computadores conectados à Internet na procura de


39

inteligência extraterrestre. A Figura 2.13 ilustra a interface do software utilizado pelo projeto

Seti at home.

Figura 2.13: Projeto Seti at home

Fonte: SILBERSCHATZ, 2002.

2.7 Considerações Finais

Neste capítulo foi abordada toda a história da evolução dos computadores, os diversos

conceitos de supercomputadores, conceitos de computação paralela, assim como os tipos de

paralelismo, para que se possa haver uma compreensão da subdivisão de uma grande tarefa a

ser processada em pequenas tarefas a serem processadas simultaneamente. Os diferentes tipos

de arquitetura computacional foram tratados de maneira contextual. Também foram

abordados aspectos introdutórios de sistemas distribuídos e um respectivo exemplo. Todos

estes conceitos foram vistos com o objetivo de facilitar o entendimento para o próximo

capítulo que trata da definição, classificação e aplicação de cluster de computadores, mais

especificadamente sobre os clusters beowulf e openmosix.

Capítulo 3 – Cluster de Computadores

40

CAPÍTULO 3 – Cluster de Computadores


A idéia inicial que conduz ao cluster foi desenvolvida na década de 1960 pela IBM

como uma forma de interligar grandes mainframes, visando obter uma solução

comercialmente viável de paralelismo. Nesta época o sistema HASP (Houston Automatic

Spooling Priority) da IBM e seu sucessor, JES (Job Entry System) proviam uma maneira de

distribuir tarefas nos mainframes interligados. A IBM ainda hoje suporta o cluster de

mainframes através do Parallel Sysplex System, que permite ao hardware, sistema

operacional, middleware e software de gerenciamento do sistema prover uma melhora

dramática na performance e custo ao permitir que usuários de grandes mainframes continuem

utilizando suas aplicações existentes.

Entretanto, o cluster ganhou força até que três tendências convergiram nos anos 1980:

microprocessadores de alta performance, redes de alta velocidade, e ferramentas padronizadas

para computação distribuída de alto desempenho. Uma quarta tendência possível é a crescente

necessidade de poder de processamento para aplicações científicas e comerciais unida ao alto

custo e a baixa acessibilidade dos tradicionais supercomputadores (PITANGA, 2004).

Ao longo dos anos 90, o que se observou foi uma rápida multiplicação de arquiteturas

baseadas em clusters em diversos lugares. Diferentes grupos de pesquisas desenvolvem sua

arquitetura, empregando componentes de hardware diferentes e desenvolvendo software

básico e aplicações para eles (CARLA, 2004).

Diversas questões relativas à computação paralela e distribuída começaram a ser

investigadas nesse novo cenário, tais como a obtenção de altas taxas de desempenho, a

redução de latência de comunicação entre os nós, aspectos de tolerância a falhas e

confiabilidade (CARLA, 2004).


41

À medida que os clusters foram aumentando o seu número de nós, questões relativas

ao gerenciamento das arquiteturas e das aplicações tornaram-se igualmente importantes,

levando assim o desenvolvimento de ferramentas para instalação, configuração e

gerenciamento.

A crescente utilização de arquiteturas de clusters tem causado um forte impacto no

mercado de supercomputadores. Durante a segunda metade dos anos 90, principalmente, as

vendas de máquinas paralelas dedicadas sofreram algumas baixas, em virtude das conquistas

atingidas com clusters.

De forma geral a computação baseada em cluster já ocasionou o desenvolvimento de

dezenas de ambientes de programação e gerenciamento, o teste de várias tecnologias para

interconexão de nós, o desenvolvimento e até mesmo a reimplementação de bibliotecas e

aplicações já desenvolvidas, a produção de inúmeros artigos e o estabelecimento de grupos de

trabalhos ao redor do mundo (CARLA, 2004).

3.2 Definição

De uma maneira geral, um cluster computacional é constituído por um conjunto de

computadores, que trabalham de maneira cooperativa e transparente na execução de tarefas.

Esse trabalho é executado de forma transparente ao usuário, ou seja, sua implementação cria

uma ilusão de um único recurso ou computador virtual.

Conforme Pitanga (2004, p. 17):

[...] um cluster é composto por um conjunto de nós

processadores (PCs ou estações) autônomos e que interligados

comportam-se como um sistema de imagem única. O conceito de

imagem única dita que um sistema paralelo ou distribuído,

independentemente de ser composto por vários processadores ou

recursos geograficamente distribuídos, deve comportar-se com um

sistema centralizado do ponto de vista do usuário. Dessa forma,

todos os aspectos relativos à distribuição de dados e de tarefas,

comunicação e sincronização entre tarefas e a organização física do

sistema devem ser abstraídos do usuário, ou seja, devem ser

transparentes a ele.


42

Para Marcelino e Paulo (2004, p. 23):

Os Clusters são sistemas que compreendem dois ou mais

computadores (denominados nodos) interconectados através de uma

rede e trabalhando em conjunto para executar aplicações. A rede

precisa ser criada de uma forma que permita o acréscimo ou a

retirada de um nó (em casos de danos, por exemplo), porém sem

que se interrompa o funcionamento do cluster. Os computadores

trabalham em conjunto, de tal forma, que os usuários tenham a

impressão que somente um único sistema responde às

requisições, criando assim uma ilusão de um recurso único

(computador virtual).

3.3 Elementos e Funcionalidades de um Cluster

Os clusters compreendem um conjunto de nós que operam de maneira cooperativa e

transparente, disponibilizando serviços e/ou efetuando tarefas a fim de atender uma demanda

específica em aplicações específicas. A fim de atenderem tal demanda, os clusters apresentam

uma arquitetura específica e elementos constituintes, onde o entendimento de conceitos

chaves nesse cenário é de fundamental importância. De acordo com Buyya (1999) e Pitanga

(2004), seguem alguns conceitos:

• Nó: Consiste na unidade básica do cluster, ou seja, cada unidade de

processamento (pode ser composto por um simples PC ou poderosas estações de trabalho

SMP (Symmetric Multi-Processor - Multiprocessamento simétrico). A comunicação entre os

nós é efetuada por mensagens transmitidas através de uma rede;

• Recursos: Podem ser físicos (unidade de disco) assim como lógicos (softwares),

sendo que existe a possibilidade de migração de recursos entre os nós;

• Dependência de Recursos: Como o próprio nome sugere, este termo indica a

situação na qual um recurso depende da disponibilidade de um outro recurso. Por exemplo,

um servidor de e-mails depende da interface de rede on-line e de um sistema operacional em

execução para prover seus serviços;

• Grupo de Recursos: é usado para representar a unidade de recursos, de tal forma

que indique critérios no qual eles devem ser agrupados. Cabe ao administrador associar uma


43

quantidade de recursos independentes em um único grupo, garantindo assim a migração de

todos os recursos desejados;

• Middleware: Consiste em um ambiente que disponibiliza de forma simplificada

facilidades em tarefas como projetar, programar e gerenciar aplicações distribuídas,

fornecendo um ambiente simples, integrado e consistente, abstraindo através de uma camada

a heterogeneidade e a complexidade do cluster, fornecendo assim, uma imagem única do

sistema (SSI). Atualmente, existe uma grande discussão entre diversos grupos de trabalho em

criar uma forma padronizada para determinar quais serviços devem compor essa camada.

Entretanto, esse grupo de serviços é dividido de acordo com o tipo de aplicação na qual o

cluster é destinado, visto que cada classe de aplicações possui necessidades e serviços básicos

distintos.

3.4 Classificação dos Clusters

Segundo Rocha (2001), os clusters podem ser classificados de acordo com um

conjunto de características:

a) Aplicação:

• Clusters de Alto Desempenho - utilizados em cálculo científico;

• Clusters de Alta Disponibilidade - utilizados em tarefas críticas;

• Clusters de Balanceamento de Carga - utilizados em servidores web.

b) Utilização dos nós:

• Clusters Dedicados - os recursos do cluster são utilizados exclusivamente para

processamento paralelo;

• Clusters Não Dedicados – as máquinas que compõe o cluster são estações de

trabalho que durante o período em que não estão sendo utilizadas emprestam processamento

para o cluster da qual fazem parte.


44

c) Hardware:

• Clusters de PCs (CoPCs) ou Pilha de PCs (PoPC) - os nós são PCs;

• Clusters de Workstations (COW) - os nós são Workstations;

• Clusters de SMPs (CLUMPs) - os nós são computadores SMP.

d) Sistema Operacional:

• Clusters Linux;

• Clusters Solaris;

• Clusters NT;

• Clusters AIX.

e) Configuração dos nós:

• Clusters Homogêneos - todos os nós com a mesma arquitetura e sistema

operacional;

• Clusters Heterogêneos - nós possuem arquitetura e/ou sistema operacional

diferente.

Neste trabalho será abordado adiante, mais especificamente sobre a classificação dos

clusters no que se refere à sua aplicação.

3.5 Tipos de Cluster

De acordo com Pitanga (2004), existem vários tipos de cluster, no entanto há alguns

que são mais conhecidos, os quais são descritos a seguir:

• Cluster de Alto Desempenho: Também conhecido como cluster de alta

performance, ele funciona permitindo que ocorra uma grande carga de processamento com

um volume alto de gigaflops em computadores comuns e utilizando sistema operacional

gratuito, o que diminui seu custo.

• Cluster de Alta Disponibilidade: São clusters os quais seus sistemas conseguem

permanecer ativos por um longo período de tempo e em plena condição de uso. Sendo assim,


45

é possível dizer que eles nunca param seu funcionamento e, além disso, conseguem detectar

erros se protegendo de possíveis falhas.

• Cluster para Balanceamento de Carga: Esse tipo de cluster tem como função

controlar a distribuição equilibrada do processamento. Requer um monitoramento constante

na sua comunicação e em seus mecanismos de redundância, pois se ocorrer alguma falha

haverá uma interrupção no seu funcionamento.

3.5.1 Cluster de Alto Desempenho

Um cluster de alto desempenho ou de alta performance é um tipo de sistema para

processamento paralelo ou distribuído que consiste de uma coleção de computadores

interconectados, trabalhando juntos como um recurso de computação simples e integrado. Um

nó do cluster pode ser um simples desktop (computadores pessoais) com memória,

dispositivos de entrada/saída de dados e um sistema operacional. No entanto esse sistema

pode oferecer características e benefícios, encontrados somente em sistemas com memória

compartilhada, como os supercomputadores (PITANGA, 2004).

Conforme Rocha (2001, p. 25,26):

Cluster é uma área de computação que têm por objetivos a

emulação de supercomputadores baseado em estações de trabalho,

PCs e máquinas SMPs. O objetivo dos HPCs é diminuir o tempo de

para resolução de grandes problemas computacionais. Sistemas

HPCs podem existir em Computação distribuída e Computação

Paralela.

Computação Distribuída tem por objetivo compartilhar

recursos de computadores de maneira a otimizá-los. Esse sistema

funciona utilizando o conceito de SPMD – Single Program Multiple

Data, para cada computador que pertence ao projeto recebe um

programa e um conjunto de dados, e durante o período de

ociosidade do computador o programa passa a ser executado, como

se fosse uma proteção de tela.


46

Computação Paralela se refere à submissão de processos

para mais de um processador distribuindo assim o esforço

computacional para resolução de um problema. São um grupo de

computadores que compartilham recursos e estão interligados

através de uma rede de computadores, esses sistemas são chamados

Clusters, com um objetivo comum, resolver um problema que exige

uma grande quantidade de processamento. O sistema tem que

parecer, perante aos seus usuários, como um grande computador,

equivalente a soma de todos os recursos individuais de cada

computador pertencente ao cluster. Um exemplo deste tipo de

sistema são os Clusters Beowulf.

De uma maneira geral, quando se fala em processamento de alta performance, que

pode ser traduzido em processamento paralelo e distribuído, logo é associado a

supercomputadores, que tem um custo elevado e são difíceis de serem operados. No entanto,

atualmente, um ambiente de clusters com seus inúmeros processadores e memórias, pode ser

um local ideal para o uso destas aplicações. Neste tipo de cluster, é necessário que haja

monitoração constante da comunicação e mecanismos de redundância. Caso contrário,

qualquer falha pode interromper o funcionamento do cluster (ALECRIM, 2004).

3.5.1.1 Cluster Beowulf: Um Cluster de Alta Performance

O projeto Beowulf foi idealizado em 1994 pela National Aeronautics and Space

Administration, no Goddard Space Flight Center (NASA-GSFC) com a finalidade de suprir a

crescente e elevada capacidade de processamento encontrada na ciência espacial a um custo

mais acessível. A origem do nome Beowulf vem de um dos poemas épicos mais antigos da

língua inglesa, na qual "conta à história de um cavaleiro inglês, de grande força e valentia em

sua saga para derrotar o monstro de Grendel" (PITANGA, 2004).

Este projeto consistia na utilização de componentes de hardware comuns, tipo PCs, de

fácil aquisição e preço acessível, dotado de sistema operacional GNU/Linux, que já permitia o

uso de troca de mensagens (MPI) e gerenciamento de máquinas paralelas (PVM). Esse projeto

foi identificado como uma alternativa importante pela NASA em suas aplicações de missão

crítica, atendendo as expectativas da corporação em utilizar equipamentos "rápidos e baratos".

Na primeira versão do Beowulf, foi utilizada a distribuição Linux Slackware para


47

implementação da arquitetura. Atualmente, utilizam-se principalmente distribuições Linux

REDHAT ou similares, pois apresenta maiores facilidades para o gerenciamento de pacotes e

disponibilidade de atualizações, no entanto, pode ser usada sob qualquer distribuição ou

sistema operacional que gerencie aplicações paralelas (PITANGA, 2004). A Figura 3.1 ilustra

um exemplo de um cluster beowulf.

Figura 3.1: The Borg, um cluster beowulf Fonte: PITANGA, 2002.

Um cluster do tipo Beowulf é considerado especificamente dedicado ao

processamento paralelo e enquadra-se na taxonomia de Flynn como MIMD. Possuí uma

arquitetura de diversos computadores formados por um nó controlador (frontend) e nós

clientes (backends), interligados através de uma rede Ethernet ou outra tecnologia de rede

qualquer, dedicada exclusivamente para a passagem de mensagens, com um sistema

operacional que implemente estruturas PVM e/ou MPI, para realizar uma comunicação que

otimize o processamento paralelo. O nó controlador tem como função controlar, monitorar e

distribuir tarefas entre o cluster, além de atuar como um elo entre ele e os usuários. Existe a

possibilidade de ter mais de um nó controlador ou mestre no sistema. Já os nós clientes ou

escravos, têm como tarefa única e exclusiva processar as tarefas enviadas pelo nó controlador

e enviá-las de volta para que o nó controlador possa finalizar as mesmas. Neste cluster, não

existe a necessidade da utilização de teclados e monitores em todos os terminais, sendo

possível implementar inclusive terminais sem a utilização de discos rígidos. Neste caso, o

boot é efetuado a partir do nó mestre, que armazena informações sobre a configuração da rede

(PITANGA, 2004).


48

A Figura 3.2 mostra, de maneira ilustrativa, a arquitetura física de um cluster beowulf

tradicional.

Figura 3.2: Arquitetura física de um cluster beowulf Fonte: PITANGA, 2002.

Segundo Rocha (2001), arquitetura física dos clusters Beowulf possui os seguintes

componentes:

• Servidor: nó do sistema que controla o cluster efetua administração e distribuição

das tarefas, funciona como servidor de arquivos e efetua a interface com o exterior tanto ao

nível de interligação de redes como ao nível de usuário. Portanto, é responsável pela

segurança e pela imagem que o exterior tem do cluster. É também designado front-end do

sistema. Normalmente existe apenas um servidor por cluster, no entanto, alguns clusters de

elevada dimensão têm mais de uma máquina que pode funcionar como servidor. O servidor é

também vulgarmente a única máquina do cluster com periféricos que permitem a interface

com o usuário;

• Clientes: o restante dos nós do sistema é designado de clientes. São configurados

e controlados pelo servidor. Não podem ser acessados da rede externa ao cluster sem passar

pelo Servidor. São usualmente máquinas sem teclados nem monitores e eventualmente até

sem disco rígido acessadas por login remoto a partir do servidor, e que se encarregam do

processamento de tarefas atribuídas pelo servidor. Constituem a capacidade de processamento

dos dados do cluster;

• Rede dedicada: interliga todos os nós do cluster. Usualmente utiliza uma

tecnologia padrão, como a Fast Ethernet.


49

Várias vantagens podem ser colocadas neste tipo de filosofia de alto desempenho de

computação, são elas:

• Quanto mais computadores na rede, mais rápido fica sua estrutura;

• Componentes de fácil disponibilidade;

• Fácil manutenção;

• Independência de fornecedores de hardware;

• Custo muito baixo;

• Disponibilidade para criação de cursos de computação paralela;

• Se um computador do sistema parar não precisa esperar seu conserto para

recomeçar seu trabalho;

• É possível construir um para colocar em prática estudos em programação paralela

sem gastar muito dinheiro ou perder tempo deslocando-se para instituições de ensino

(normalmente universidades federais) para testar programas.

• Custo zero para o sistema operacional e ferramentas de apoio (podem ser baixados

da internet gratuitamente).

Mesmo que se tenha diversas vantagens, o cluster beowulf apresenta algumas

desvantagens:

• Nem todas as aplicações podem ser paralelizadas;

• Difícil programação;

• Ocorrência de gargalos tradicionais em comunicações, como latência e largura de

banda;

• É preciso experiência em ambientes de redes para a elaboração e configuração do

cluster.

3.5.1.2 Cluster Openmosix: Um Cluster Flexível de Alto Desempenho

O projeto Mosix - Multicomputer Operating System Unix - é um sistema operacional

distribuído, desenvolvido originalmente por Amnom Barak, na Universidade Hebrew em

Jerusalém, Israel. Foi utilizado nos anos 80 pela força área americana para a construção de um

cluster de computadores PDP11/45. O projeto foi desenvolvido em sete fases, para diferentes


50

versões de UNIX e arquiteturas de computadores. A primeira versão para PC foi desenvolvida

para o BSD/OS. A última versão foi para o sistema operacional Linux em plataforma Intel

(PITANGA, 2002).

O Openmosix é uma extensão do projeto Mosix, baseado no GPLv2, iniciado em 10

de fevereiro de 2002, coordenado pelo Ph.D Moshe Bar, para manter os privilégios desta

solução Linux para cluster disponível com software de código aberto (PITANGA, 2002).

O Openmosix é um software, ou uma extensão de Projeto Mosix (baseada em kernel

UNIX) para gerência de um sistema distribuído, e consiste basicamente de um algoritmo de

compartilhamento de recursos adaptáveis, onde o mesmo é sensível a variações no uso dos

recursos entre os nodos (CARLA, 2004).

Estes recursos são compartilhados através de migração de processos de maneira

transparente, provendo balanceamento de carga e prevenindo problemas com swap de

memória para o disco, ou seja, o Openmosix é uma extensão para os sistemas operacionais

baseados no UNIX que faz com que um cluster de computadores se comporte como um

grande e único supercomputador através da utilização de Migração Preemptiva de Processos e

Balanceamento Dinâmico de Carga (CARLA, 2004).

Este agrupamento de máquinas Linux é classificado como um verdadeiro sistema de

imagem simples (SSI - Single System Image), pois já é clara que a idéia de que não se têm um

cluster verdadeiro enquanto não existir um SSI. Pode-se ter como referência os primeiros

clusters SSI como o IBM SysPlex e o cluster DEC. Em um cluster DEC, executa-se o

comando telnet para um endereço no cluster, essa chamada será atendida por qualquer nó do

cluster, o usuário não precisa se preocupar com qual nó que irá atender esta chamada, e

qualquer programa iniciado pelo usuário será executado no nó que possuir maior

disponibilidade de recursos para atender ao programa (PITANGA, 2002).

A implementação da Migração Preemptiva de processos é capaz de migrar qualquer

processo do usuário, em qualquer instante e para qualquer nó disponível de maneira

transparente. Para atingir um melhor desempenho este é controlado por Algoritmos de

Balanceamento Dinâmico de Carga e de prevenção contra falta de memória. Estes algoritmos

são projetados para responder dinamicamente as variações da utilização dos recursos nos


51

diversos nós. Isto garante que o cluster se comporte muito bem, seja numa configuração com

poucas ou com muitas máquinas, propiciando uma maior escalabilidade (PITANGA,

2002).

Esse processo de migração pode ser feito por meio automático ou manual. No caso de

manual, o administrador indica qual processo deverá migrar para determinado nó, podendo

ainda indicar a capacidade máxima que um determinado nó deve tolerar antes de iniciar o

processo de migração para outro nó do cluster. Entretanto, existem muitos processos que

podem migrar para outros nós, todavia, isso não quer dizer que os mesmos se beneficiarão

com esta migração. De acordo com Pitanga (2002), existem certas aplicações que podem se

beneficiar e aumentar sua performance com a aplicação desta solução. Porém, por outro lado,

existem aquelas que não são recomendadas para este ambiente, pois em alguns casos, existem

aplicações que não exigem muito do poder de processamento e acabam diminuindo o

desempenho do cluster (RODRIGO, 2006).

Se um determinado programa que está sendo executado em uma máquina consumir

muitos recursos dela, o sistema faz uma busca em toda a rede e procura uma máquina mais

"disponível no momento" em termos de memória e CPU, e desloca seu "programa" ou

instâncias do programa para ser executado remotamente. Desta forma, o sistema ganha

desempenho (PITANGA, 2002).

O cluster openmosix trabalha de maneira descentralizada, ou seja, não existe a

configuração de Controlador Mestre e nós escravos como ocorre no Cluster Beowulf para

computação paralela. Cada nó é um mestre para os processos que são criados localmente, e

um servidor para processos remotos, migrados de outros nós do cluster. Isto significa que

podem acrescentadas ou removidas máquinas ao cluster em qualquer momento, com um

mínimo de distúrbio no sistema. Este cluster possui também algoritmos de monitoramento

que identificam a velocidade de cada nó, a carga da CPU e a memória livre disponível, em

qual situação está a comunicação interprocessos e a velocidade de acesso de cada processo

(PITANGA, 2002).

A Figura 3.3 mostra a maneira como funciona a migração de processos de

máquina para outra em um cluster openmosix.

Figura 3.3: Migração de processos num Cluster Openmosix

Como o Openmosix opera de forma silenciosa e as operações são transparentes para as

aplicações, ou seja, pode-se executar aplicações seqüenciais e paralelas como se fosse um

único computador SMP (Symmetric Multi

necessário conhecer onde os

outros usuários estão fazendo na rede. O que ele faz é, pouco tempo depois de iniciar os

processos, enviá-los para um melhor computador da rede, continua

processos e os demais, e pode

trabalho maximizando o trabalho e melhorando o

Dentre as vantagens que o

• Escalabilidade: completamente transparente

sem software ou requisitos adicionais

• Adaptatividade: a

versão do Openmosix seja igual entre

(Symmetric Multi-Processor

• Não necessita recompilação das aplicações: qualquer aplicação poderá beneficiar

deste sistema sem alterações ao


52

A Figura 3.3 mostra a maneira como funciona a migração de processos de

máquina para outra em um cluster openmosix.

Figura 3.3: Migração de processos num Cluster OpenmosixFonte: PITANGA, 2002.


se executar aplicações seqüenciais e paralelas como se fosse um

único computador SMP (Symmetric Multi-Processor - Multiprocessamento simétrico).

os processos estão sendo executados, nem se preocupar com que os


os para um melhor computador da rede, continuando

podendo movimentá-los pelos computadores com pouca carga de

izando o trabalho e melhorando o desempenho (PITANGA, 2002)

Dentre as vantagens que o OpenMosix oferece para as aplicações destacam

: completamente transparente, bastando lançar um novo nó na rede

sem software ou requisitos adicionais e será automaticamente adaptado pelo cluster como nó;

: a arquitetura de cada nó é completamente indiferente, desde que a

versão do Openmosix seja igual entre os nós. Com efeito, é possível

Processor) a co-existir com sistemas UP (Uni-Processor);

Não necessita recompilação das aplicações: qualquer aplicação poderá beneficiar

deste sistema sem alterações ao código;

Cluster de Computadores

A Figura 3.3 mostra a maneira como funciona a migração de processos de uma

Figura 3.3: Migração de processos num Cluster Openmosix


se executar aplicações seqüenciais e paralelas como se fosse um

Multiprocessamento simétrico). Não é

processos estão sendo executados, nem se preocupar com que os


ndo a monitorar os novos

los pelos computadores com pouca carga de

(PITANGA, 2002).

oferece para as aplicações destacam-se:

lançar um novo nó na rede

e será automaticamente adaptado pelo cluster como nó;

de cada nó é completamente indiferente, desde que a

nós. Com efeito, é possível ter sistemas SMP

Processor);

Não necessita recompilação das aplicações: qualquer aplicação poderá beneficiar


53

• Aplicações cujos processos requerem longos tempos de execução e baixo volume

de comunicação, como aplicações científicas, engenharia entre outras, se beneficiarão com o

Openmosix;

• Grandes compilações;

• Banco de dados que não usam memória compartilhada;

• Processos na qual é possível fazer migração manualmente.

Existem aplicações que podem não obter vantagens utilizando o cluster Openmosix, entre elas:

• Processos com baixa computação, como aplicativos com alta comunicação

interprocessos.

• Aplicações que fazem uso de memória compartilhada.

• Aplicações dependentes do hardware que necessitam de acesso a um periférico de

um nó em especial.

• Aplicações composta de muitas threads não ganham desempenho.

• Não se ganha desempenho quando um único processo é executado, tal como um

browser.

3.5.2 Cluster de Alta Disponibilidade

Com o avanço das atividades que dependem de recursos computacionais, é cada vez

maior o transtorno causado pela eventual falha desses sistemas.

A alta disponibilidade está ligada diretamente à crescente dependência humana com os

computadores, pois atualmente eles possuem um papel crítico, principalmente em empresas

cuja maior funcionalidade é exatamente a oferta de algum serviço computacional, como e-

business, notícias, site Web dentre outros (CARLA, 2004).

Esse tipo de cluster é ideal para trabalhar com grandes quantidades de tarefas que

exigem pequenas ou médias capacidades de processamento (CARLA, 2004).

O Cluster de Alta Disponibilidade (HA – High Availability) é usado para aumentar a

confiabilidade de serviços como: servidor WEB, servidor DNS, servidor e-comerce, servidor

de e-bussines e banco de dados críticos, ou seja, fazer com que esses serviços sempre estejam


54

disponível a qualquer hora em qualquer situação. Para isso o seu conceito é bastante simples:

caso um servidor falhe outro assume seu lugar imediatamente sem que o usuário perceba.

Essa filosofia de cluster é utilizada em sistemas cujos serviços não podem parar, isto é,

precisem ficar 24h ininterruptas no ar (OLIVEIRA E LEITE, 2004).

Para isso é implementado um sistema onde se faz de um espelhamento entre os

computadores parecido com o sistema RAID de HDs, porém espelha-se via rede, ou seja, o

software do computador “espelho” é responsável por monitorar o computador espelhado e

verificar todas as operações que são gravadas em seu disco. Então este programa copia as

informações mudadas para o HD do computador “espelho”, tornando-os sempre idênticos de

modo que quando o servidor principal falhar, o servidor espelho assume o seu lugar sem

perda de informações e de maneira imperceptível para o usuário (OLIVEIRA E LEITE,

2004). A Figura 3.4 mostra a arquitetura física de um cluster de alta disponibilidade.

Figura 3.4: Arquitetura física de um cluster de alta disponibilidade

Fonte: PITANGA, 2004.

Para muitas empresas, isso é satisfatório. Mas alguns sistemas de missão crítica (como

transações bancárias, bolsas de valores, algumas aplicações médicas e monitoramento militar

ou controle de tráfego aéreo) exigem um grau mais elevado de disponibilidade. Nesses casos,

99, 999% de disponibilidade significa uma indisponibilidade de cerca de 5 minutos por ano

(CARLA, 2004).


55

A complexidade do sistema deve estar no software que deve se preocupar em

monitorar outras máquinas de uma rede, saber que serviços estão sendo executados, quem os

está executando, e como proceder em caso de uma falha. Perdas no desempenho ou na

capacidade de processamento são normalmente aceitáveis; o objetivo principal é não parar.

Existem algumas exceções, como sistemas de tempo real e de missão crítica (OLIVEIRA E

LEITE, 2004).

A tolerância a falhas é conseguida através de hardware, como sistemas RAID, fontes e

placas redundantes, sistemas de rede totalmente ligados para prover caminhos alternativos na

quebra de um link (OLIVEIRA E LEITE, 2004).

Como referência serão citados alguns trabalhos em Linux open source sobre alta

disponibilidade:

• LVS - Linux Virtual Server: O objetivo neste projeto é o balanceamento de carga e

alta disponibilidade em um cluster de servidores, criando a imagem de um único servidor

virtual;

• Eddiware: Atua com escalabilidade de servidores web, consistindo em um servidor

de balanceamento HTTP, um servidor DNS aperfeiçoado, usa técnicas de duas camadas com

o frontend e backend, fazendo roteamento de tráfego;

• TurboLinux Cluster: Baseado na solução da distribuição asiática TuboLinux,

provê alta disponibilidade para roteadores e servidores, e é baseado no LVS, inserções no

kernel (patch), tunneling, ferramentas de instalação e configuração.

3.5.3 Cluster de Balanceamento de Carga

Uma empresa fictícia decide oferecer novos serviços em seu site via web. O novo

serviço consiste em fazer conversões on-line de documentos dos mais variados formatos

(*.doc, *.xls, *.txt) em arquivos *.pdf. Entretanto, para que o serviço seja de qualidade, é

necessário que o tempo de conversão seja o menor possível. Supondo que a empresa disponha

do mais recente e melhor sistema multiprocessador e, tudo está funcionando perfeitamente

nos primeiros dias do lançamento. No entanto, devido ao sucesso do novo serviço, o número

de acessos ao sistema aumenta exponencialmente, sobrecarregando o servidor, de modo que o

acesso ao sistema fica impossibilitado ou muito lento, não atendendo as expectativas da


56

direção da empresa. Então, o que fazer para resolver este problema? Uma solução neste caso

seria fazer uma redistribuição dos serviços para mais de um servidor, através de um cluster de

balanceamento de carga, evitando que apenas um servidor responda a todas as solicitações

(RODRIGO, 2006).

Em linhas gerais, balanceamento de carga consiste em dividir aplicativos ou

processamentos através da rede para outras unidades de processamento. "Ainda que a maioria

dos aplicativos de equilíbrio de carga gerencie servidores web, o equilíbrio de carga pode

distribuir praticamente qualquer serviço através de qualquer quantidade de computadores e

localizações geográficas" (BOOKMAN, 2003).

Quando se colocam dois computadores com a mesma capacidade de resposta para

atender uma mesma requisição, sem fazer o balanceamento de cargas, pode acontecer de os

dois computadores responderem a mesma requisição, prejudicando assim a conexão. Para

evitar isso, coloca-se um software de balanceamento de carga que fará o gerenciamento entre

os servidores e o cliente (CARLA, 2004).

O balanceamento de carga é mais que um simples re-direcionamento do tráfego dos

clientes para outros servidores. Para implementação correta, o equipamento que fará o

balanceamento precisa ter características como verificação permanente da comunicação,

checagem dos servidores e redundância. Todos esses itens são necessários para que não

venham a se tornar um gargalo ou um ponto único de falha (CARLA, 2004).

A tarefa de pegar a entrada de carga e distribuí-la através do cluster é apenas a

primeira etapa. A questão que surge é como fazer para distribuir as tarefas a serem

processadas através dos diferentes servidores. De acordo com Bookman (2003, p. 105), a

maneira na qual será feita a distribuição da carga de trabalho "[...] depende do tipo de serviço

que é oferecido, do tamanho da rede e do número de computadores no cluster". Dependendo

da topologia do cluster, existem diversos algoritmos capazes de fazer a melhor distribuição

das tarefas.


57

A Figura 3.5 demonstra um exemplo de arquitetura física de um cluster de

balanceamento de carga.

Figura 3.5: Exemplo de arquitetura de um cluster de balanceamento de carga

Fonte: DANTAS, 2005.

De acordo com Carla (2004), os algoritmos para balanceamento de carga são um dos

fatores de maior importância neste contexto, abaixo estão três métodos básicos:

• Least Connections: esta técnica redireciona as requisições para o servidor baseado

no menor número de requisições/conexões. Por exemplo, se o servidor 1 está controlando

atualmente 50 requisições/conexões, e o servidor 2 controla 25 requisições/conexões, a

próxima requisição/conexão será automaticamente direcionado para o servidor 2, desde que

atualmente o servidor tenha um número menor de requisições/conexões ativas.

• Round Robin: ele sempre irá direcionar as requisições para o próximo servidor

disponível de uma forma circular. Por exemplo, as conexões de entrada são dirigidas para o

servidor 1, depois servidor 2 e finalmente servidor 3 e depois retorna ao servidor 1.

• Weighted Fair: dirige os pedidos para os servidores baseados na carga de

requisições de cada um e na capacidade de resposta dos mesmos (performance). Por exemplo,

se o servidor 1 é quatro vezes mais rápido no atendimento aos pedidos do que o servidor 2, o

administrador coloca um peso maior de trabalho para o servidor 1 do que o servidor 2.


58


Neste capítulo foram vistas as possíveis definições de cluster de computadores,

conceituado como um conjunto de computadores que trabalham de maneira cooperativa e

transparente para o usuário por meio de um sistema distribuído; os elementos e

funcionalidades que os compõem; sua classificação segundo alguns critérios; os três

principais tipos de clusters mais utilizados por diversas entidades no mundo inteiro e mais

especificadamente sobre os clusters beowulf e openmosix caracterizados como

implementações de cluster de alta performance, pois são os principais objetos de estudo deste

trabalho. Todo o embasamento teórico foi abordado para que se possa facilitar o entendimento

do próximo capítulo que visa implementar passo a passo um cluster beowulf e posteriores

resultados de testes feitos com e sem o uso do mesmo, aplicando-o ao processo de

renderização de imagens.

Capítulo 4 – Criando um Cluster Beowulf

59

CAPÍTULO 4 – Criando um Cluster Beowulf


Clusters da classe Beowulf trabalham em um ambiente de processamento paralelo,

tendo por finalidade ganho de performance. Esta idéia, aliada às suas diversas vantagens,

quando comparado com as demais soluções para processamento pesado, tais como baixo

custo e ferramentas gratuitas, fazem do Cluster Beowulf o de maior crescimento em

Universidades e grandes empresas de alguns setores do mercado. Este capítulo tem por

finalidade expor, de forma clara e precisa, todos os passos para desenvolver este tipo de

ambiente, independente do número de máquinas utilizadas.

4.2 Elementos Necessários

Para implementação de um Cluster Beowulf são necessários 2 ou mais computadores,

onde um é chamado de nó mestre ou controlador (com duas placas de rede, uma on board e

outra off board) e os demais nós escravos – sendo todos ligados em rede através de um switch

e utilizando sistema operacional Linux.

Os seguintes componentes foram envolvidos no desenvolvimento deste estudo de

caso:

• Rede Fast Ethernet 100 Mbits;

• Switch DLink 24 portas;

• Sistema Operacional: Red Hat Linux 9.0 com kernel 2.4.20-8;

Computador mestre:

• Processador AMD Athlon ™ XP 2600 +;

• 128 MB de memória RAM;

• Gravadora de CD LG 8527B;

• Placa de rede on-board VIA PCI 10/100Mb Fast Ethernet Adapter;


60

• Placa de rede off-board Realtek RTL 8139 Family PCI Fast Ethernet NIC;

• Disco rígido de 40Gb (somente 30Gb foram utilizados para o projeto);

• Monitor de 15” VGA;

• Mouse Microsoft PS/2;

• Teclado de 120 teclas.

Computadores escravos:

• Quantidade: 02 (dois)

• 256 MB de memória RAM;

• Placa de rede on-board VIA PCI 10/100Mb Fast Ethernet Adapter;

• Placa de rede off-board Realtek RTL 8139 Family PCI Fast Ethernet NIC;

• Disco rígido de 40Gb (somente 30Gb foram utilizados para o projeto).

4.3 Red Hat Linux 9.0

O Red Hat Linux 9, assim como todos os sistemas operacionais de distribuição Linux,

é um sistema operacional livre, com código aberto, o que proporciona a liberdade de

configuração e edição da forma que se achar necessária.

Além da característica apresentada, sua escolha foi feita pelo fato de apresentar uma

parte de configuração bastante robusta e conter a maioria dos pacotes necessários para

configuração, gerenciamento e manutenção do cluster pré-compilado, ou seja, precisando

apenas ser executado, caso estes fossem necessários.

Segue um passo a passo de sua instalação e principais comandos para melhor

compreensão deste projeto.

4.3.1 Instalando o Red Hat

Para efetuar a instalação, são utilizados os 3 (três) Cds do Red Hat Linux 9. Inserido o

primeiro Cd – a tela inicial da instalação é mostrada, conforme ilustra a Figura 4.1 – e

iniciado o processo de Boot do Red Hat Linux 9, os seguintes procedimentos são necessários

para instalação do sistema em modo texto para uma estação de trabalho:


61

Figura 4.1: Tela inicial da instalação

Fonte: Elaboração própria.

- Iniciar o processo de instalação, digitando linux text, na frente da palavra boot (após

isso, inicia-se o processo de carregamento do instalador do Red Hat Linux, conhecido como

Anaconda e o reconhecimento do hardware do computador);

- Escolher o idioma de instalação do sistema Red Hat Linux (possui suporte ao

português);

- Escolher o tipo de teclado (geralmente br-abnt 2);

- Escolher o tipo de mouse;

- Escolher o tipo de instalação que será usado (é recomendável escolher estação de

trabalho);

- Particionar o disco rígido (Hard Disc, HD ou Winchester), de forma a criar a partição

Raiz (o Red Hat Linux possui três formas de particionamento, sendo duas formas da própria

distribuição e uma de uso comum, que é o fdisk. Por se tratar de uma instalação para uso

pessoal, deve ser usado o Disk druid que é um particionador em modo gráfico);

- Definir o gerenciador de boot para o sistema Linux – lembrando que o gerenciador

de boot é responsável pela tela exibida ao iniciar o sistema Red Hat Linux pela primeira vez,

após a instalação, o mesmo pode ser usado para iniciar também outros sistemas operacionais;

- Definir os parâmetros que devem ser especificados no carregamento do sistema

como suporte a dispositivo SCSI, Vídeo, etc.;

- Configurar a rede, definindo as configurações para que a máquina possa acessar a

rede e a internet, conforme mostra a

Figura 4.2: Configuração para habilitar a máquina a acessar a rede e a internet

- Definir o nome da m

- Definir o fuso horário do país/região;

- Definir a senha do usuário root;

- Instalar o sistema, lembrando daqui para frente o processo segue por conta do

sistema, com exceção da troca de mídias, durante o processo.

início efetivo da instalação do Red Hat Linux 9.0.

Figura 4.3: Iniciação do processo de instalação do Red Hat


62

Configurar a rede, definindo as configurações para que a máquina possa acessar a

, conforme mostra a Figura 4.2;



Definir o nome da máquina, lembrando que o nome não pode existir na rede;

Definir o fuso horário do país/região;

a senha do usuário root;

Instalar o sistema, lembrando daqui para frente o processo segue por conta do

sistema, com exceção da troca de mídias, durante o processo. A Figura 4.3 apresenta a tela de

cio efetivo da instalação do Red Hat Linux 9.0.



Criando um Cluster Beowulf

Configurar a rede, definindo as configurações para que a máquina possa acessar a


quina, lembrando que o nome não pode existir na rede;

Instalar o sistema, lembrando daqui para frente o processo segue por conta do

igura 4.3 apresenta a tela de



63

Após a instalação de todos os pacotes, o sistema solicitará a criação de um disco de

boot, o que é recomendável, mas é possível optar por não utilizá-lo, logo após o sistema

apresentará uma tela informando a finalização do processo de instalação e será solicitado o

reboot do sistema.

4.3.2 Comandos Básicos do Linux

Para melhor compreensão dos futuros procedimentos para a configuração e

ferramentas utilizadas, a seguir são mostrados nas Tabelas 4.1, 4.2, 4.3 e 4.4 os comandos

básicos do Linux utilizados, assim como suas respectivas funções.

Tabela 4.1: Comandos de manipulação de arquivos

Cd Navegando entre diretórios

Ls Listar arquivos

mkdir Cria um diretório

rmdir Remove um diretório vazio

Cp Cópia de arquivos e diretórios

Mv Move arquivos e diretórios

Rm Deleta arquivos e diretórios

Ln Linkando arquivos

Cat Exibe o conteúdo de um arquivo ou direciona-o para outro

File Indicando tipo de arquivo


Tabela 4.2: Comandos sobre processos do sistema

ps Listando processos

kill Matando um processo

killall Matando processos pelo nome

w Lista os usuários logados



64

Tabela 4.3: Descompactar arquivos

Extensão .tar.gz tar zxpvf arquivo.tar.gz

Extensão .tar tar xpvf arquivo.tar

Extensão .gz Gunzip arquivo.gz

Extensão .tar.bz2 Bunzip2 arquivo.tar.bz2 ; tar xpvf arquivo.tar

Extensão .bz2 Bunzip2 arquivo.bz2

Extensão .zip unzip arquivo.zip


Tabela 4.4: Compactar arquivos

Empacotar um diretório em .tar tar cvf diretório/

Empacotar um diretório em .tar.gz tar zcvf diretorio/

Compacta um arquivo para .gz gzip arquivo

Compacta um arquivo para .bz2 bzip2 arquivo


4.4 Configuração

A configuração é a parte crucial da implementação deste projeto, pois é a partir dela

que todos os processadores envolvidos passarão a trabalhar de forma paralela em cada tarefa

solicitada.

A configuração é feita a partir dos seguintes passos:

1. Configurar os endereços lógicos (IP) para o controlador mestre e os nós escravos;

2. Projetar um ambiente de resolução de nomes;

3. Criar um relacionamento de confiança entre as máquinas;

4. Permitir o uso de comandos remotos para colocar as aplicações em execução nos

nós;

5. Configurar o servidor do Sistema de Arquivos (NFS - Network File System);

6. Promover a sincronização dos relógios dos nós através do NTP (Network Time

Protocol).


65

4.4.1 Configurando os endereços lógicos

É comum que se adote o endereço de rede 192.168.0.X com máscara de rede

255.255.255.0, mas nada impede o desenvolvedor de escolher outro tipo de endereço, para

atribuição das máquinas, que podem ser feitas de forma estática ou distribuída pelo protocolo

DHCP (Dynamic Host Configuration Protocol).

Para configuração dos endereços lógicos, deve ser criado um arquivo padrão

dhcpd.conf com o seguinte conteúdo:

ddns-update-style none;

default-lease-time 600;

max-lease-time 7200;

authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {

range 192.168.0.2 192.168.0.253;

option routers 192.168.0.221;

option domain-name “cluster.ufpa.br”;

option domain-name-servers 192.168.0.221;

option broadcast-address 192.168.0.255;

}

host escravo1 {

hardware ether 00:D0:B7:B0:FC:47;

fixed-address 192.168.0.219;

}

host escravo2 {

hardware Ethernet 00:D0:C7:B0:Fd:48;

fixed-address 192.168.0.225;

}

Como pode ser observado, neste caso, os computadores foram denominados como

mestre, escravo1 e escravo2 para os endereços 192.168.0.221, 192.168.0.219 e 192.168.0.225,

respectivamente, mas estes nomes e endereços são facultativos, é recomendável somente

prezar pela organização para melhor compreensão.


66

4.4.2 Resolvendo o nome das máquinas

Para resolver os nomes das máquinas, é necessário criar um domínio, onde todos

respeitem o mesmo padrão. Neste estudo de caso, no controlador mestre foi usado o domínio

totalmente qualificado denominado mestre.cluster.ufpa.br, assim como nos nós escravos

foram utilizados os nomes escravo1.cluster.ufpa.br e escravo2.cluster.ufpa.br,

respectivamente.

A resolução dos nomes das máquinas nos endereços lógicos de rede (IP) é feita através

da edição do arquivo /etc/hosts em todas as máquinas do cluster. Este deve ser editado de

forma semelhante à exibida na Tabela 4.5, indicando o endereço IP, o nome da máquina e seu

domínio, respectivamente:

Tabela 4.5: Resolução de nomes das máquinas que compõem o cluster

127.0.0.1 Localhost localhost.localdomain

192.168.0.221 Mestre Mestre.cluster.ufpa.br

192.168.0.219 escravo1 Escravo1.cluster.ufpa.br

192.168.0.225 escravo2 Escravo2.cluster.ufpa.br


4.4.3 Configurando um relacionamento de confiança

O relacionamento de confiança entre os nós do cluster é configurada através do

arquivo /etc/hosts.equiv, que define a relação de confiança entre os hosts através de

equivalência, sem necessidade de autenticação por senha, uma necessidade do protocolo de

acesso remoto RSH (Remote Shell) para ser capaz de acessar todas as máquinas no cluster.

Este arquivo é editado em todos os nós do cluster com o seguinte padrão:

mestre

escravo1

escravo2


67

4.4.4 Permitindo o uso de comandos remotos

A permissão para uso de comandos remotos pelo protocolo RSH e por algumas

aplicações de monitoramento é concedida através do arquivo .rhost, localizado no diretório

/root.

Seguindo o formato:

mestre

escravo1

escravo2

O funcionamento ideal deste arquivo só ocorre com a liberação e habilitação do uso do

rsh, rlogin e rcp ao usuário. Isto é feito através da adição das seguintes linhas no arquivo

/etc/securetty:

rsh

rlogin

Em seguida, os serviços rsh, rlogin e rcp devem ser habilitados através do comando

ntsysv, no terminal, e o xinetd deve ser reiniciado com o comando ./xinetd restart.

Estes procedimentos são feitos em todas as máquinas.

4.4.5 Configurando o Servidor de Sistemas de Arquivos

A utilidade dessa configuração diz respeito a necessidade de acesso a diretórios e

arquivos localizados em computadores remotos como se fossem locais por parte dos nós do

cluster. Este trabalho é função do serviço NFS (Network File System).

Para isso, no computador mestre, adiciona-se ao final do arquivo /etc/exports o

seguinte conteúdo:

/home *(rw,no_root_squash)

/usr/local *(rw,no_root_squash)


68

Onde: rw � escrita e leitura; no_root_squash � privilégios de superusuário.

Nos nós escravos, ao fim do arquivo /etc/fstab devem ser adicionadas as linhas:

192.168.0.221:/home /home nfs exec,dev,suid,rw 1 1

192.168.0.221:/home /home nfs exec,dev,suid,rw 1 1

Para finalização desta tarefa, é necessária a reiniciação do serviço NFS em todos os

nós do cluster, primeiramente no mestre. No terminal, deve ser executado:

cd /etc/rc.d/init.d

./nfs stop

./nfs start

ntsysv (Habilitação do servidor NFS automaticamente)

4.4.6 Configurando o Servidor de Tempo

A importância da sincronização dos relógios dos nós do cluster se deve ao fato de que

os sistemas distribuídos usam algoritmos distribuídos onde as informações estão espalhadas

pelos nós, os processos executam suas funções no nó em que está alocado e não existe uma

fonte de relógio globalizado.

Este serviço é realizado pelo NTP (Network Time Protocol) a partir de uma referência

padrão chamada UTC (Universal Time Coordinated).

A não sincronização pode acarretar em condições de ocorrência de deadlocks e até

mesmo na perda de mensagens no sistema.

Para esta configuração, em todos os nós é executado no terminal:

touch /etc/ntp.drift

No nó mestre, o arquivo /etc/ntp.conf é editado de forma a seguir o seguinte padrão:

server 127.127.1.0 prefer

fudge 127.127.1.0 stratum 0


69

driftfile /etc/ntp/drift

authenticate no

Enquanto nos nós escravos esse mesmo arquivo, /etc/ntp.conf segue como:

server 192.168.0.221

driftfile /etc/ntp/drift

authenticate no

E deve ser executado no terminal:

ntpdate 192.168.0.221

E por fim, em todos os nós, primeiramente no mestre, o daemon ntpd deve ser ativado

executando no terminal o comando:

service ntpd start


Este capítulo abordou todos os passos necessários para implementação de um Cluster

da classe Beowulf utilizando o sistema Operacional Red Hat Linux 9.0.

Convém lembrar que essa configuração se aplica a todas as versões do Red Hat e que

alguns arquivos podem ter nomes diferentes caso seja utilizada outra distribuição Linux. No

capítulo seguinte, serão exibidas e analisadas as ferramentas necessárias para gerenciamento,

paralelismo dos processos entre as máquinas, análise de performance e testes de renderização

de imagens.

Capítulo 5 – Gerenciando e Testando o Cluster Beowulf

70

CAPÍTULO 5 – Gerenciando e Testando o Cluster Beowulf


Através deste estudo de caso, tentou-se analisar o potencial do cluster através de

softwares livres e cálculos matemáticos, de forma que trabalhos futuros possam seguir os

procedimentos realizados e comparar os resultados obtidos. Para isto, este capítulo mostra as

ferramentas mais utilizadas para gerenciamento de um cluster, paralelismo dos processos

(distribuição entre as máquinas), análise de velocidade e desempenho da rede e do cluster e

testes de renderização de imagens, proporcionando uma comparação com os demais trabalhos

realizados por universidades e empresas do Brasil e do mundo.

5.2 Gerenciamento

Todo projeto necessita de uma tática eficaz de gerenciamento para que seja possível

verificar o funcionamento das partes em relação ao todo, de modo a identificar as falhas

existentes e prevenir as futuras.

Clusters de computadores não são diferentes, a decisão da adoção de uma ferramenta

de gerenciamento pode revelar um conjunto de aprimoramentos antes ocultos para qualquer

profissional da área.

Dentre as ferramentas voltadas para gerenciamento, destacam-se: bWatch, TinaWatch,

Scalable Cluster Management System, Ganglia, Parmon e Supermon.

Devido a sua simplicidade e facilidade de configuração, além de ser uma ferramenta

leve, foi feito uso do bWatch no presente projeto, cuja instalação, configuração e

funcionalidades são descritas a seguir.


71

5.2.1 Beowulf Watch (bWatch)

Desenvolvido por Jacek Radajewski, o bWatch é um script escrito em uma linguagem

interpretada gráfica (Tcl/Tk).

Assumindo que, na máquina na qual esteja sendo executado, possa fazer uso do rsh

(remote shell) em todos os computadores listados em $listOfHosts e que seu interpretador

wish esteja em /usr/bin/wish, sua principal tarefa é monitorar a carga e uso da memória em

todos os nós do cluster.

Qualquer usuário cadastrado no sistema que tenha permissão de executar comandos

remotos pelo protocolo rsh para outras máquinas pode executar o bWatch, tirando a

obrigatoriedade de se registrar como usuário root observada nas demais ferramentas.

5.2.2 Instalação

Primeiramente faz-se download do arquivo bWatch-1.1.0a tar.gz disponível no site da

UK Mirror Service, colocando-o no diretório /usr/local, preferencialmente.

Em seguida, o arquivo deve ser descompactado utilizando o terminal. Por exemplo:

cd /usr/local/

tar –zxvf bWatch-1.1.0a.tar.gz

cd bWatch-1.1.0a

O arquivo Makefile deve ser aberto com um editor de texto para verificar se o

caminho para o wish está correto (/usr/bin/wish).

Conferido o caminho, deve ser digitado:

make bwatch

Será criado o arquivo bWatch.tcl.

É aconselhável instalá-lo em /usr/local/bin. Então, deve ser digitado no terminal:

make install

Feito isso, é necessária a

diretório pessoal (/home para usuário comum ou /root para usuário máximo). No diretório

onde o arquivo estiver, deve ser

cat .bWatchrc.tcl

A seguinte linha deve ser editada

set listOfHosts {mestre}

Ela deve ser completada

neste projeto a mesma foi editada como

set listOfHosts {mestre escravo1

Para iniciar o gerenciamento dos nós do cluster,

através da execução dos seguintes comandos

cd /root (ou /home se não for superusuário)

./bWatchrc.tcl

Na Figura 5.1, observa

Figura 5.1: O bWatch adaptado para o Projeto Cluster Beowulf


72

é necessária a execução do bWatch.tcl. Isto criará o arquivo .bWatch.tcl no


deve ser executado o comando:

deve ser editada:

set listOfHosts {mestre}

Ela deve ser completada com os nomes de todas as máquinas que deseja monitorar,

neste projeto a mesma foi editada como:

set listOfHosts {mestre escravo1 escravo2}

iniciar o gerenciamento dos nós do cluster, é necessário

através da execução dos seguintes comandos no terminal:

cd /root (ou /home se não for superusuário)

observa-se o bWatch modificado para o Projeto Cluster Beowulf.



Gerenciando e Testando o Cluster Beowulf

o bWatch.tcl. Isto criará o arquivo .bWatch.tcl no


com os nomes de todas as máquinas que deseja monitorar,

é necessário executar a aplicação

ra o Projeto Cluster Beowulf.



73

Sempre que um dos nós escravos é desligado ou simplesmente pará de operar no

cluster, a aplicação coloca uma tarja vermelha para identificá-lo.

Através do bWatch é possível: verificar se o serviço NTP está funcionando

corretamente (através da variável “Time”, dizendo que os relógios estão em sincronia), o

número de processos em execução em cada nó (Num procs), a quanto tempo estes estão em

operação (Uptime), o tempo de resposta de cada nó (Load 1 min Average, Load 5 min

Average, Load 15 min Average), entre outras funções.

5.3 Paralelismo

Fazer com que todas as máquinas processem em paralelo e em sincronia um mesmo

programa é o grande trunfo de um cluster do tipo Beowulf. Contudo, nem sempre é uma

tarefa simples para o programador.

Já existem ferramentas que auxiliam na programação paralela (algumas resolvendo

definitivamente o problema do paralelismo), tais como: Vampir, Cluster Development Kit,

TotalView, Paragraph, dentre outras. Porém, o fato de serem aplicações Shareware, algumas

de alto custo, restringe um desenvolvimento ainda maior dessa sub-área da computação.

Os programadores atuais podem optar por dois tipos de bibliotecas que proporcionam

o paralelismo dos programas, sendo elas a PVM (Máquina Virtual Paralela) e MPI (Interface

de Passagem de Mensagens).

A decisão pela biblioteca MPI nesse projeto foi feita pelos seguintes motivos:

• Eficiência tanto para sistemas em cluster quanto para arquiteturas MPP (Massively

Parallel Processors);

• Possui diversas implementações livres disponíveis;

• Possui uma comunicação totalmente assíncrona;

• Eficiência no gerenciamento dos buffers das mensagens;

• Facilidade de instalação e usabilidade.


74

A implementação do padrão MPI escolhido foi o MPICH, por sua facilidade de

execução, se comparado com as demais implementações, e por ser a mais difundida e aceita

internacionalmente.

5.3.1 MPICH

O MPICH é uma implementação do padrão MPI-2 disponibilizada livremente que

pode ser executada sobre ambiente Unix e seus derivados.

Sua primeira distribuição foi publicada em 1993 e atualmente encontra-se na versão

1.2.7 (a mesma utilizada neste projeto).

Mesmo tendo um grande tamanho (cerca de 10,2 MB), se comparada com outras

bibliotecas similares, a instalação e configuração dessa biblioteca é muito simples e não é

necessário estar registrado como superusuário (root).

5.3.2 Instalação do MPICH

Para instalá-lo, é necessário baixar o arquivo mpich-1.2.7p1.tar.gz (disponível no site

da T-Systems SFR Fresh), colocando-o no diretório /usr/local.

Em seguida, devem ser executados os seguintes procedimentos no terminal:

cd /usr/local (entrar no diretório onde se localiza o arquivo)

tar –zxvf mpich-1.2.7p1 (desempacotar o arquivo)

cd ./mpich-1.2.7p1 (entrar no novo diretório criado)

./configure –prefix=/usr/local

make

make install

Para sua configuração são editados o arquivo machines.LINUX, localizado em

/usr/local/mpich-1.2.7p1/útil/machines, como:

mestre

escravo1

escravo2


75

E o arquivo .bash_profile, localizado no diretório /root, deve-se acrescentar as linhas:

PATH:$PATH=/usr/local/mpich-1.2.7p1/bin

Export MPIR_HOME=/usr/local/mpich-1.2.7p1

Feito isso, a instalação estará completa.

5.3.3 Utilizando o MPICH

Para garantir que todos os passos tenham sido realizados com êxito, a biblioteca deve

ser testada com alguns dos programas para exemplo que acompanha o MPICH, como o

cálculo do número PI, para isso, devem ser executados no terminal os seguintes comandos:

cd /usr/local/mpich-1.2.7p1/examples (entrar no diretório do programa)

mpicc cpi.c –o cpi (compilá-lo)

mpirun –np 4 cpi (executá-lo, onde “-np 4” indica o número de processos em que

o programa é dividido)

O resultado é sempre algo próximo de:

Processs 0 on mestre.cluster.br

Process 1 on escravo1.cluster.br

Process 2 on escravo2.cluster.br

Process 3 on mestre.cluster.br

pi is approximately 3.14159832964054, Error is 0,000002666666627

wall clock time =0,000978

Comprovando que os processos foram distribuídos entre os nós do cluster.

5.4 Ferramentas de Análise de Performance

Para ter uma melhor visão a respeito da eficiência do cluster, ganho de velocidade e

performance de pico (máxima), foram instaladas duas ferramentas para essa análise: Netpipe e

Blasbench (um dos pacotes do LLCBench).


76

5.4.1 Netpipe

Desenvolvido pela Iowa State Universitity Research Fundation, o Netpipe é uma

ferramenta essencial para estudo do impacto de uma rede local nos clusters.

Sua instalação é feita a partir do pacote netpipe-2.4.tar.gz, disponível no site da

Scalable Computing Laboratory, seção NetPipe, no diretório /usr/local.

No terminal, os seguintes procedimentos devem ser seguidos:

cd /usr/local

tar –zxvf netpipe-2.4.tar.gz

cd netpipe-2.4

make TCP

Em seguida, devem ser editadas as seguintes linhas do arquivo Makefile localizado em

/usr/local/netpipe-2.4:

MPI_HOME=/usr/local/mpich-1.2.7p1

MPI_ARCH=LINUX

MPI_DEVICE=ch_p4

E na linha antes do $(EXTRA_LIBS) deve ser trocado o ‘lmpi’ por ‘-lmpich’.

Depois, os comandos abaixo devem ser executados:

cd /usr/local/netpipe-2.4

make MPI

./NPtcp –r (nos nós escravos)

mpirun –np 2 ./Npmpi


77

A partir do arquivo Netpipe.out obtido (um conjunto de quatro colunas com os dados:

tempo/vazão/tamanho dos blocos (bits)/tamanho dos bloco (bytes)/distorção), os seguintes

gráficos mostrados nas Figuras 5.2 e 5.3 foram gerados:

Figura 5.2: Gráfico do tempo de processamento pelo tamanho do bloco em bytes


Figura 5.3 Gráfico da vazão pelo tamanho do bloco em bytes


Tempo X Tamanho do Bloco

-0,0005

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

1 12 27 51 99 195

387

771

1539

3075

6147

1229

1

2457

9

4915

5

9830

7

Bloco (Bytes)

Tem

po (segundos)

Vazão X Tamanho do Bloco

0

500

1000

1500

2000

2500

3000

3500

1

12

27

51

99

195

387

771

1539

3075

6147

12291

24579

49155

98307

Bloco (Bytes)

Thro

ughput (B

PS

)

BPS


78

5.4.2 LLCBench

O LLCBench (Low Level Characterization) é um conjunto de ferramentas de análise

de desempenho composto pelos pacotes MPBench, BLASBench e CacheBench.

Neste projeto foi utilizado o BLASBench (Basic Linear Algebra System Benchmark)

para descobrir a velocidade em Mflops/seg do cluster implementado. Este é uma biblioteca de

operações em álgebra linear destinada a testes de desempenho em ambientes paralelos.

Isto foi possível através dos seguintes procedimentos:

Deve ser feito o download do arquivo llcbench.tar.gz no diretório /usr/local

(disponível no site da LLCbench Home Page).

No terminal devem ser executados os comandos:

cd /usr/local

tar zxvf llcbench.tar.gz

cd ./llcbench/conf

cp sys.linux-mpich /usr/local/llcbench/sys.def

make

E, finalmente, para conseguir o gráfico de desempenho do BLASBench:

cd /usr/local/llcbench/blasbench

make

make run

make graphs


79

A Figura 5.4 exibe o gráfico adquirido neste estudo de caso:

Figura 5.4 Teste de performance com BLAS


Percebe-se que o cluster implementado possui velocidade de aproximadamente 545

Mflops/seg. (leia-se: 545 milhões de instruções por segundo).

O gráfico ilustrado na figura 5.4 mostra o desempenho do cluster baseado em três

tipos diferentes de manipulação de matrizes e vetores indicados pela legenda na parte superior

a direita do gráfico: daxpy (Multiplicação do vetor x pelo vetor y), dgemv (Multiplicação da

matriz m pelo vetor v) e dgemm (Multiplicação da matriz m pela matriz m).

Segundo os resultados do teste daxpy, o computador mestre ao analisar a tarefa a ser

executada, ou seja, a necessidade de se efetuar cálculos de multiplicação simples entre

vetores, não fez uso da biblioteca MPI (Interface de passagem de mensagens) para distribuir

processos, pois se encarregou de executar todos os processos individualmente.

Acompanhando a progressão da linha referente ao teste daxpy, pode-se observar que o ganho

de performance vai crescendo gradualmente de acordo com o tamanho do problema a ser

solucionado.


80

No teste dgemv, o computador mestre ao analisar que a tarefa a ser executada se trata

de efetuar cálculos de multiplicação entre matrizes e vetores, fez o uso da biblioteca MPI

(Interface de passagem de mensagens) para distribuir alguns processos para os dois nós

escravos processarem e em seguida enviar o resultado obtido de volta ao computador mestre.

De acordo com a progressão da linha referente ao teste dgemv, pode-se observar que o cluster

teve um baixo rendimento de performance, pois o tempo gasto para a distribuição

desnecessária de poucos processos para os demais nós do cluster, acarretou no atraso da

velocidade de processamento para o resultado final do problema a ser resolvido.

No teste dgemm, o computador mestre ao analisar que a tarefa a ser executada se trata

de efetuar cálculos complexos de multiplicação entre matrizes, fez o uso da biblioteca MPI

(Interface de passagem de mensagens) para distribuir grande quantidade de processos para os

dois nós escravos processarem e em seguida enviar o resultado obtido de volta ao nó mestre.

Baseando-se na progressão da linha referente ao teste dgemm, observa-se que o cluster deve

um ganho de performance satisfatório chegando a atingir a velocidade de 545 Mflops/seg.;

pois quando se trata de um problema que exige uma grande quantidade de processamento, é

de bastante necessidade a distribuição de processos para proporcionar o paralelismo de tarefas

complexas em sub-tarefas menores.

5.5 Testes e Resultados

A abordagem mais adotada para obtenção de resultados e cálculos de ganho de

performance é a renderização de imagens.

Trata-se de uma forma popular de testar esta classe de cluster, tendo a oportunidade de

comparar os resultados com diversos clusters implementados em todo o mundo.

A renderização de imagens utilizando clusters beowulf é uma tendência nas grandes

empresas de produções cinematográficas, tais como: Digital Domain, Pixar Animation

Studios, Industrial Light & Magic. E, seguindo essas referências, é utilizado o PovRay

(Persistence of Vision Ray Tracer) para execução dos testes.


81

5.5.1 Instalação do PovRay

Primeiramente, baixam-se os arquivos povuni_s.tgz, povuni_d.tgz e mpi-povray-

1.0.patch.gz no diretório /usr/local, disponíveis na seção FTP da Etsimo:

Então, no terminal, é executado:

cd /usr/local

tar zxvf povuni_s.tgz

tar zxvf pouni_d.tgz

cd ./povray

Em seguida o arquivo mpi-povray-1.0.patch.gz deve ser movido para o diretório

/usr/local/povray. E voltando ao terminal, digita-se:

gunzip mpi-povray-1.0.patch.gz

cat mpi-povray-1.0.patch | patch –p1

cd ./source/mpi-unix

make newxwin

Para conclusão da instalação.

5.5.2 Utilizando o PovRay

Para os testes, recomenda-se que todos os arquivos dos diretórios

/usr/local/povray31/scenes/advanced e /usr/local/povray31/scenes/basic sejam copiados para o

diretório /home, ou outro diretório compartilhado.

Uma das imagens mais populares é o vaso espacial skyvase.pov. Para renderizá-lo,

deve ser executado o seguinte comando no terminal:

Mpirun –np 4 /usr/local/povray31/source/mpi-unix/mpi-x-povray –I /home/skyvase.pov

+v1 +ft –x +mb25 +a0.300 +j1.000 +r3 –q9 –w640 –H480 –S1 –E480 –k0.000 –mv2.0

+b1000 +L/usr/local/povray31/include +NH128 +NW128

Onde “-np 4” significa que foi dividido em 4 processos,

(process 0) é utilizado somente na distribuição de carga,

utilizados os 3 nós do cluster.

A Figura 5.5 ilustra o vaso esp

mostram os resultados utilizando 1, 2 e 3 nós do cluster deste estudo de caso,

respectivamente:

Figura 5.5

Figura 5.6 Resultado da renderização da imagem skyvase.pov utilizando 1 nó


82

significa que foi dividido em 4 processos, sendo que

(process 0) é utilizado somente na distribuição de carga, significa

utilizados os 3 nós do cluster.

igura 5.5 ilustra o vaso espacial skyvase.pov, enquanto as F

os resultados utilizando 1, 2 e 3 nós do cluster deste estudo de caso,

Figura 5.5 O vaso espacial skyvase.pov





sendo que o primeiro processo

significando então que serão

acial skyvase.pov, enquanto as Figuras 5.6, 5.7 e 5.8

os resultados utilizando 1, 2 e 3 nós do cluster deste estudo de caso,


Figura 5.7 Resultado da renderização da imagem skyvase.pov utilizando 2 nós



83









84

Além da Figura skyvase.pov, devem ser renderizadas as imagens chess2.pov e

lamppost.pov utilizando os mesmos procedimentos, a Tabela 5.1 mostra os resultados obtidos

por este projeto:

Tabela 5.1 Tempo de renderização das figuras determinado pelo número de nós utilizados

Tempo de Renderização

Nº de nós

Figura

1 2 3

Skyvase.pov 16 segundos 9 segundos 6 segundos

Chess2.pov 272 segundos 138 segundos 93 segundos

Lamppost.pov 34 segundos 19 segundos 13 segundos


A partir destes resultados é possível o cálculo do ganho de velocidade, onde:

p

s

T

T

ParaleloComputadoremExecuçãodeTempo

SerialComputadoremExecuçãodeTempoGV ==

Dessa forma:

Para skyvase.pov: 2,6676

161 ≈==

p

s

T

TGV

Para chess2.pov: 2,92593

2722 ≈==

p

s

T

TGV

Para lamppost.pov: 2,61513

343 ≈==

p

s

T

TGV

Fazendo uma média entre os valores:

2,7363

207,8

3

615,2925,2667,2

3321

≈=++

=

++

=

GVGVGVGVm


85

Conclui-se que o ganho de velocidade médio do cluster foi de aproximadamente

2,736, o que significa que o ganho de desempenho foi de aproximadamente 173,6%.

Como foram utilizados 3 nós, o ganho de velocidade ideal é de 3, significando ganho

de desempenho de 200%. Na realidade esse valor nunca acontece, pois sempre há uma perda

de desempenho em todas as trocas de mensagens entre os nós.

Para efeito de comparação, na Tabela 5.2 segue resultados de outros clusters na

renderização da imagem skyvase.pov, possibilitando a observação do seguinte resultado:

Tabela 5.2. Avaliação do cluster baseado no arquivo skyvase.pov

Tempo Projeto Número de nós

00:00:02 MK-81 96

00:00:03 Cray T3E-900-AC64 48

00:00:03 IBM Netfinity PVM Cluster 17

00:00:06 Projeto Cluster Beowulf 3

00:00:06 Gravitor I 62

00:00:14 Projeto Multipinguim 4

00:00:17 Projeto Vitara 9

00:00:19 2 Onyx Racks with PVM 8

00:00:26 PVM cluster (ALPHA) 4

Fonte: PITANGA (Modificado), 2004


As Tabelas 5.1 e 5.2 mostradas neste capítulo comprovam o grande desempenho do

presente projeto frente a grandes empresas e outros trabalhos acadêmicos desenvolvidos, onde

apenas clusters com, no mínimo, o quíntuplo da quantidade de nós foram capazes de obter

resultados mais satisfatórios.

Pode-se constatar também a grande vantagem na utilização de clusters quando

comparados a uma única máquina, comprovando o ótimo desempenho dessa solução para

processamento pesado.


86

Devido à facilidade de escalabilidade, melhores resultados podem ser obtidos pela

simples adição de nós ao cluster, proporcionando desempenho igual ou superior ao de

supercomputadores com um custo inferior.

Um importante fator para a diminuição do tempo de processamento é quantidade de

memória RAM das máquinas, onde se observa que os resultados são melhores quando a

máquina com menos memória é utilizada como mestre, pois tende a trabalhar menos que as

demais. No capítulo seguinte, são apresentados fundamentos do Cluster OpenMosix e o

software SPRING, para auxiliar a compreensão do estudo de caso referente a implementação

deste tipo de cluster.

Capítulo 6 – Fundamentos do Cluster Openmosix

87

CAPÍTULO 6 – Fundamentos do Cluster OpenMosix


O Cluster OpenMosix é um dos clusters de distribuição de carga mais utilizados no

comércio e nas instituições, tendo ampla documentação, independência de hardware e é de

domínio público. Sua escolha para este projeto visa justamente estas características, e mais

ainda a possibilidade de executar aplicativos seqüenciais, obtendo, em alguns casos, ganho de

desempenho. Vale ressaltar que aumentar o desempenho de uma única aplicação não é o forte

deste cluster, pois este por definição visa o balanceamento da carga de trabalho em todos os

nós que compõem o sistema, tendo, então o objetivo de alcançar o melhor desempenho global.

No entanto, um dos desafios deste projeto era aumentar a performance de uma aplicação

seqüencial utilizando-se de uma arquitetura distribuída e, por este motivo, o cluster

OpenMosix foi a melhor solução encontrada.

6.2 Utilização do Cluster OpenMosix em Sistemas de Geoprocessamento

A Universidade Federal do Pará, Campus de Marabá, possui um laboratório utilizado

nos cursos de Agronomia e Geologia, em que os professores destes cursos realizam pesquisas

em SIGs (Sistemas de Informação Geográfica). Estas ferramentas demandam uma alta

capacidade de processamento dos sistemas de computação, e por tal fato há dificuldade de

utilizá-las em sistemas simples como os computadores pessoais (PC).

Além disso, muitas aplicações realizadas na Universidade, relacionadas às áreas de

física e engenharia têm o mesmo problema, em relação grande tempo de processamento, que

aquelas realizadas pelos SIGs.

Outra informação relevante para este estudo é a de que todas estas aplicações

utilizadas são seqüenciais, ou seja, foram projetadas para um ambiente de processamento

serial. Desta forma, duas possíveis soluções com a tecnologia de clusterização são apontadas:

o reprojeto destas aplicações para serem portadas para a arquitetura paralela, mais


88

especificamente para um ambiente de processamento paralelo por passagem de mensagens

como os clusters de classe Beowulf. Porém, neste sentido, encontra-se outro problema, pois

estas aplicações são complexas e a importação delas para este ambiente seria muito

trabalhoso, e por tal, os resultados não poderiam ser apresentados ao término deste projeto. De

outra forma, no decorrer do projeto tentamos obter versões destes softwares para o ambiente

paralelo, através de pesquisa. No entanto, constatou-se que não há nenhum projeto conhecido

em desenvolvimento pelo governo para este tipo de plataforma, e que somente as

universidades desenvolvem este tipo de aplicação, ficando, então, esta possibilidade como

proposta para trabalhos futuros. Outra solução seria executar estas aplicações em um cluster

de distribuição de carga, visando distribuir o trabalho entre diversas estações e assim obter

ganho de desempenho. Neste sentido, utilizar-se-á de um cluster de computadores

OpenMosix, como ferramenta neste estudo de caso.

6.3 O Cluster OpenMosix

Muitas das aplicações utilizadas nos cursos da UFPA, em Marabá, são nativas da

plataforma Windows. No entanto, este projeto visa a implementação de um cluster,

apresentando como característica principal o baixo custo relativo aos supercomputadores

atuais. Assim, implementar um cluster WINDOWS seria ir contra este princípio, uma vez que

é uma plataforma fechada e o seu uso acarretaria maiores custos ao projeto. Neste sentido, foi

escolhido o cluster OpenMosix, um conhecido cluster de distribuição de carga, desenvolvido

para diversas plataformas, que possui a característica de ter sua licença aberta. Como exemplo

de aplicação deste tipo de cluster, utilizou-se uma ferramenta de geoprocessamento

desenvolvida pelo Instituto de Pesquisas Espaciais (INPE), que será apresentada a seguir na

seção 6.4. Esta é uma ferramenta já utilizada na plataforma Windows pelos professores dos

cursos, tendo sua versão para Linux, com todas as suas funcionalidades, possibilitando

também a sua aplicação em cluster Linux.

O OpenMosix é uma camada de software adicional ao kernel do sistema operacional

desenvolvida para prover qualidade de SSI (Single System Image) a um conjunto de sistemas

de computadores em rede.


89

6.4 A Ferramenta SPRING

O produto SPRING (Sistema de Processamento de Informações

Georreferenciadas) é um banco de dados geográfico de segunda geração, para ambientes

UNIX e Windows com as seguintes características:

• Opera como um banco de dados geográfico sem fronteiras e suporta grande volume

de dados (sem limitações de escala, projeção e fuso), mantendo a identidade dos objetos

geográficos ao longo de todo banco;

• Administra tanto dados vetoriais como dados matriciais (“raster”), realizando a

integração de dados de Sensoriamento Remoto em um SIG;

• Provê um ambiente de trabalho amigável e poderoso, através da combinação de

menus e janelas com uma linguagem espacial facilmente programável (LEGAL - Linguagem

Espaço-Geográfico baseada em Álgebra).;

• Consegue escalonabilidade completa, ou seja, é capaz de operar com toda sua

funcionalidade em ambientes que variam desde microcomputadores a estações de trabalho

RISC de alto desempenho.

O SPRING é baseado em um modelo de dados orientado a objetos, do qual são

derivadas sua interface de menus e a linguagem espacial LEGAL. Algoritmos inovadores,

como os utilizados para indexação espacial, segmentação de imagens e geração de grades

triangulares, garantem o desempenho adequado para as mais variadas aplicações. Projetado

para a plataforma RISC e interface gráfica padrão OSF Motif, o SPRING apresenta interface

altamente interativa e amigável, além de documentação on-line, ambas escritas em português,

facilitando extremamente sua utilização e suporte.

Outra característica, considerada extremamente importante, é que a base de dados é

única, isto é, a estrutura de dados é a mesma quando se trabalha em um micro computador

(IBM-PC) e em uma máquina RISC (Estações de Trabalho UNIX), não havendo necessidade

alguma de conversão de dados. O mesmo ocorre com a interface, que é exatamente a mesma,

não existindo diferença no modo de operar o produto SPRING.

Baseado nessas características o SPRING tem se mostrado uma opção altamente

atrativa na área de geoprocessamento, pois passa a ser considerado um software de domínio


90

público, podendo ser adquirido pela Internet, bastando efetuar um cadastro. O SPRING é um

produto desenvolvido com tecnologia totalmente nacional, feito pelo Instituto Nacional de

Pesquisas Espaciais - INPE, em São José dos Campos/SP, cidade que se destaca no cenário

nacional pelas empresas e institutos ligados a área de tecnologia principalmente no setor

aeroespacial. Abaixo têm-se a interface principal do SPRING na Figura 6.1.

Figura 6.1: Interface principal do SPRING



Neste capítulo vê-se que devido ao fato de o cluster OpenMosix ser de baixo custo, e,

ainda, existir ferramentas de domínio público para a utilização, e, também, por este sistema

executar aplicações seqüenciais, foi a melhor solução encontrada para este tipo de aplicação.

No próximo capítulo, tem-se uma abordagem prática sobre a configuração e aplicação

do cluster de distribuição de carga Openmosix, em um estudo de caso para a segmentação de

imagens.

Capítulo 7 – Aplicação do Cluster OpenMosix ao Geoprocessamento

91

CAPÍTULO 7 – Aplicação do Cluster OpenMosix ao Geoprocessamento

7.1 Considerações iniciais

Neste capítulo, abordar-se-á a implementação e o estudo de caso do cluster

OpenMosix, passo a passo, da forma mais breve e objetiva, portanto, omitindo alguns

pormenores, podendo estes ser consultados na vasta bibliografia sobre o assunto.

7.2 Implementação da infra - estrutura

Para a implementação do cluster OpenMosix há duas possibilidades:

1. Fazer download do pacote OpenMosix, dos códigos-fonte do kernel linux,

compilar o kernel com o OpenMosix e posteriormente configurá-lo. O pacote OpenMosix

pode ser obtido em: Open Source Linux Cluster Project. O Kernel do Linux pode ser obtido

em: The Linux Home Page at Linux Online.

2. Baixar uma versão pré-compilada do kernel Linux com o OpenMosix e configura -

lá. Essa versão pode ser obtida em: Cluster knoppix.

A opção escolhida neste projeto foi utilizar uma versão pré-compilada do kernel linux

com o OpenMosix., porque o foco do projeto é a avaliação desta tecnologia na aplicação das

resoluções de problemas de supercomputação em aplicações seqüenciais, e utilizar uma

versão pronta favorece o cumprimento do prazo do projeto.

Há diversas distribuições de compilações do kernel com o OpenMosix, utilizar-se-á

uma distribuição denominada ClusterKnoppix, que é uma distribuição da distribuição linux

Knoppix compilado com o OpenMosix. Esta distribuição foi interessante por ser da forma de

“live CD”, podendo ser utilizada sem a necessidade de instalação no Hard Drive. A Figura 7.1

ilustra a interface principal do Clusterknoppix.


92

Figura 7.1: Tela principal do Clusterknoppix


7.3 Configuração

O Processo de configuração do Clusterknoppix é muito simples, levando apenas

alguns minutos para isso.

Pode-se dividi-la em partes:

1. Boot pelo CD-ROM:

Nesta etapa é necessário escolher se a distribuição será utilizada a partir do CD-ROM

ou se será instalado no Hard Drive.

Para utiliza - lá a partir do CD-ROM, basta configurar o SETUP da BIOS do

computador para realizar a primeira procura por arquivos de boot na unidade de CD-ROM.

Em seguida, pode-se prosseguir a instalação a partir do CD-ROM com a distribuição

Cluster Knoppix. Na Figura 7.2 a seguir, têm-se a tela inicial do carregamento da distribuição

Cluster Knoppix.


93

Figura 7.2: Carregador de boot do knoppix


O sistema se carregará automaticamente, detectando todos os dispositivos presentes no

computador e ativando o daemon do OpenMosix, detectando também os daemons do

OpenMosix que estiverem em execução em outras máquinas na mesma rede.

2. Inicializar o sistema:

Após o boot, caso o sistema não ative o daemon do OpenMosix automaticamente,

pode ser utilizado o seguinte comando no prompt de comando:

root@knoppix# /etc/init.d/openmosix start

De outra maneira, para parar a execução do Daemon do openmosix utiliza-se a mesma

linha de comando com o parâmetro “stop” no lugar de “start”, ou para atualizar os dados de

trabalho do Daemon utiliza-se o parâmetro “refresh”.

Para ativar o mapa dinâmico de computadores que pertencem ao cluster na rede, pode-

se utilizar o comando:

root@Knoppix# omdiscd

Caso o cluster seja composto somente por unidades

(SO) a partir do “live cd”, após o boot de todos os sistemas, o cluster já deverá estar

funcionando, e todas as m

SSI (sistema de imagem única).

3. Monitorar o cluster:

Para monitorar o sistema

� OpenMosix Migmon;

� OpenMosix View;

� OpenMosix Procs;

� OpenMosix Collector;

� Entre outras ferramentas, como o gerador de gráfico Mosmon.

O OpenMosix Migmon é um aplicativo que cria um gráfico em tempo real sobre a

migração dos processos nos diversos nó

interface em tempo de execução

Figura 7.3: Interface do OpenMosix Migmon


94

composto somente por unidades executando o Sistema Operacional

“live cd”, após o boot de todos os sistemas, o cluster já deverá estar

funcionando, e todas as máquinas executando o sistema já devem pertencer

istema de imagem única).

Monitorar o cluster:

Para monitorar o sistema, utiliza-se seus aplicativos de gerência, que são:

OpenMosix Migmon;

OpenMosix View;

OpenMosix Procs;

OpenMosix Collector;

ferramentas, como o gerador de gráfico Mosmon.


ão dos processos nos diversos nós do cluster. Na Figura 7.3 têm

interface em tempo de execução.

Figura 7.3: Interface do OpenMosix Migmon


Aplicação do Cluster OpenMosix ao Geoprocessamento

executando o Sistema Operacional

“live cd”, após o boot de todos os sistemas, o cluster já deverá estar

pertencer ao conjunto do

se seus aplicativos de gerência, que são:

ferramentas, como o gerador de gráfico Mosmon.


m-se uma amostra desta

O OpenMosix View é um aplicativo que gera um gr

de cada nó do cluster e dados relativos ao sistema

sistemas, quantidade de processadores do sistemas.

interface do OpenMosix View

Figura 7.4: Interface do OpenMosix View

O OpenMosix Procs é um aplicativo utilizado para melhor gerenciar os processos

migrados de um nó ou os residentes, possibilita

migrando, sua localização,

a interface deste aplicativo.

Figura 7.5: Interface do OpenMos


95

OpenMosix View é um aplicativo que gera um gráfico em tempo real sobre a carga

r e dados relativos ao sistema como um todo, como memória RAM do

de processadores do sistemas. Na Figura 7.4 abaixo pode

interface do OpenMosix View.

Figura 7.4: Interface do OpenMosix View



migrados de um nó ou os residentes, possibilitando ainda identificar qua

seu PID (process identificator), etc. Abaixo, na F

a interface deste aplicativo.

Figura 7.5: Interface do OpenMosix Procs


Aplicação do Cluster OpenMosix ao Geoprocessamento

em tempo real sobre a carga

como um todo, como memória RAM do

abaixo pode-se notar a


identificar quais processos estão

Abaixo, na Figura 7.5, têm-se


96

O OpenMosix Collector é um aplicativo que possibilita a captura de dados para a

geração de estatísticas sobre o cluster. Este aplicativo não possui interface.

Para ativar estes aplicativos basta digitar os seus respectivos nomes no prompt sem

espaços:

root@Knoppix# openmosixmigmon

root@Knoppix# openmosixview

root@Knoppix# openmosixprocs

root@Knoppix# openmosixcollector

Esses comandos não são executados para os aplicativos que não pertencem ao pacote

do OpenMosix, como o Mosmon, que é um gerador de gráficos em modo texto para a

monitoria da distribuição de carga no sistema:

root@Knoppix# mosmon

Na Figura 7.6 abaixo, pode-se ver a interface do Mosmon em tempo de execução.

Figura 7.6: Interface do Mosmon



97

A instalação via CD-ROM é interessante, pois possibilita a economia ainda maior de

recursos e simplicidade de instalação, visto ao fato de as máquinas não precisarem de Hard

drive e de não precisar instalar o sistema em todas elas, pois este processo seria bem mais

demorado. Porém, a instalação do CD não permite a instalação de novas aplicações, o que é

necessário para que se possa utilizar outras aplicações alem da que já existem no “live CD”,

como é o caso da aplicação de geoprocessamento utilizada neste projeto. Para isso, então, é

preciso instalar a distribuição no Hard drive em uma das Máquinas.

4. Instalação no Hard drive:

Para a Instalação no Hard drive, procede-se o boot pelo CD-ROM. Após o

carregamento do sistema, basta executar um script de instalação no prompt:

root@knoppix# sudo knoppix-installer

É importante ressaltar que este script só pode ser executado a partir do terminal “root”.

Após a execução do script, será apresentada uma tela para o assistente de instalação.

O primeiro passo é formatar o Hard Drive e criar as partições de instalação do sistema.

Devem ser criadas pelo menos duas partições: Uma Reiserfs, na qual serão copiados e

configurados os arquivos do sistema, e outra Swap, a qual será utilizada pelo arquivo de troca.

O tamanho da partição Reiserfs é arbitrário, devendo ter no mínimo 1GB, que é o tamanho

exigido pelo sistema. A partição Swap deve ter o tamanho em MB igual ao dobro da

quantidade de memória RAM da estação.

Após estas especificações, o script instalará automaticamente o sistema, somente

pedindo algumas vezes especificações sobre data, hora, etc.

Para a ativação e configuração do cluster, após a instalação deste nó no hard drive,

devem ser utilizados todos os comando citados acima na configuração a partir do CD-ROM.

Após instalar o sistema no Hard drive, procede-se a instalação do software de

geoprocessamento utilizado neste estudo de caso: o SPRING.


98

7.4 Instalação do SPRING

Para instalar este aplicativo é necessário executar os seguintes passos:

Fazer o download da versão do sistema de geoprocessamento que está disponível em:

Spring – Download (Obs.: recomenda-se a instalação a partir de um arquivo compactado com

a extensão: “.tar.gz”).

A instalação pode ser feita a partir de um diretório onde se deseja instalar o sistema.

Deve-se executar a linha de comando a seguir:

root@knoppix# tar xzvf spring4.3-Port.tar

Em seguida, deve-se executar o aplicativo a partir do diretório em que foi

descompactado, para isto executa-se o seguinte comando:

root@knoppix# cd /<diretório>

Então executa-se o aplicativo, com o seguinte comando:

root@knoppix# csh

root@knoppix# ./spring

É preferível que se crie um atalho para a execução do aplicativo no KDE.

Outra forma é executar estas operações utilizando um navegador padrão e dar um

duplo clique no aplicativo:

root@knoppix# Konqueror /<diretório>

Após este comando, o navegador abrirá no diretório em que o pacote foi

descompactado, então pode-se executar o aplicativo.


99

7.5 Resultados

Primeiramente foi realizado um teste de desempenho em uma máquina

individualmente e depois no cluster.

A rotina de Geoprocessamento utilizada foi a de classificação automática de

segmentação.

Foram escolhidas 50 classes de segmentação, por uma área mínima de 25 pixels em

uma imagem do satélite CIBERS 2.

Na Figura 7.7, tem-se a interface do SPRING exibindo a imagem carregada obtida do

satélite CIBERS 2.

Figura 7.7: Imagem de satélite CIBERS, região da cidade de Marabá-PA


O primeiro teste foi realizado em uma máquina com sistema operacional Linux.

A configuração de hardware é a seguinte:

� Processador Athlon XP 2066+, 2.3 GHz;

� 128 MB de memória RAM;


100

� A aplicação foi executada do Hard Drive.

A rotina de Geoprocessamento utilizada foi a mesma do teste anterior. O processo

demorou 80 minutos para ser completado totalmente.

Abaixo se tem na Figura 7.8, a interface do SPRING no momento de execução do

processo de segmentação automática.

Figura 7.8: Interface do Spring no processo de segmentação automática em andamento


No segundo teste foi utilizado o cluster OpenMosix com apenas duas máquinas, uma

com a configuração de hardware anterior e a distribuição do ClusterKnoppix e a outra com a

mesma configuração de hardware e sistemas operacional, exceto memória RAM que era 128

MB superior, ou seja, 256 MB. O processo demorou 60 minutos para terminar totalmente.


101

Abaixo têm-se, na Figura 7.9, a interface do SPRING em tempo de execução.

Figura 7.9: Tela do Spring em processo de segmentação automática na sua finalização


Acrescentando mais uma máquina com as mesmas configurações de hardware e

sistema operacional (256 MB de RAM):

O processo demorou 45 minutos para terminar totalmente. Abaixo têm-se na Figura

7.10 a demonstração das ferramentas de gerência do cluster; na direita, a interface do

OpenMosix Procs indicando a migração de processos.


102

Figura 7.10: Detalhe do balanceamento de carga entre os nós e a migração do software

SPRING, como é mostrado no Openmosix Procs


Com base no maior tempo gasto e menor tempo, tem-se um ganho de desempenho de:

p

s

T

T

ParaleloComputadoremExecuçãodeTempo

SerialComputadoremExecuçãodeTempoGV ==

77,145

80==GV OU 177%

Ou seja, o cluster proporcionou um ganho de tempo, fazendo com que a aplicação

fosse executada até 77% mais rapidamente do que em uma só máquina. Este fato se deve a

distribuição do trabalho entre os nós que compõem o cluster através da migração de

processos.


Pode-se observar neste capítulo a fácil configuração e aplicação do cluster OpenMosix

a partir de uma versão pré-compilada, de domínio aberto e de fácil obtenção. O seu alto poder

de distribuição de carga e de processamento em aplicativos complexos foram estudados e


103

comprovados de maneira satisfatória. Este já é em si um bom motivo para a adoção desta

ferramenta em trabalhos que necessitem deste tipo de infra – estrutura e que pretendem

otimizar o tempo de processamento de suas aplicações.

Capítulo 8 – Conclusão

104

CAPÍTULO 8 – Conclusão

No decorrer deste projeto, realizou-se a pesquisa e a implementação das tecnologias de

clustering de alta capacidade de processamento (HPC - High Processor Computing), de onde

se conclui que esta é uma solução ótima para os problemas de prazo e custos da maioria dos

projetos. Dentre estas características, vale ressaltar a grande facilidade de montagem desta

infraestrutura, o custo baixíssimo e uma excelente documentação existente.

Utilizou-se esta tecnologia para a solução prática de problemas presentes nesta

instituição de ensino, pesquisa e extensão (UFPA, Campus de Marabá), como o problema da

pesquisa em SIGs (Sistemas de Informação Geograficos) nos laboratórios dos cursos de

Geologia e Agronomia e criou-se infra-estrutura para realização de tarefas de

supercomputação e qualificação de profissionais para esta finalidade.

As principais restrições, de acordo com a prática realizada, à supercomputação de

baixo custo (clustering), são: muitos problemas não podem ser paralelizados, e muitos

projetos de pesquisa e desenvolvimento não utilizam esta infra-estrutura, porque há falta de

mão de obra especializada para este fim, preferindo a supercomputação convencional de alto

custo, como foi o caso encontrado na ferramenta de geoprocessamento produzida pelo INPE,

o SPRING, onde em comunicação com a equipe de desenvolvimento desta ferramenta foi

explicado que não há projetos para a importação desta ferramenta para a plataforma

distribuída.

Assim, uma proposta para trabalho futuro seria o desenvolvimento de um código

paralelo para a aplicação da ferramenta de geoprocessamento utilizada (SPRING), a partir do

código seqüencial já escrito na linguagem “C”. Desta forma, o tempo de processamento seria

ainda menor, obtendo-se ganhos consideráveis neste sentido.

105

Referências Bibliográficas

ALECRIM, Emerson. Cluster: Principais conceitos. Info Wester, 2004. Disponível em: <www.infowester.com/cluster. php>. Acesso em: 06 ago. 2007.

AMORIM, Cláudio Luiz; BARBOSA, Valmir Carneiro; FERNANDES, Edil Severiano Tarares. Uma introdução à computação paralela e distribuída. Campinas: UNICAMP, IMECC, 1998. 256p.

BEOWULF, 2004. Disponível em: http://www.beowulf.org. Acesso em 18 ago. 2007.

BESSANI, A. N. O padrão Umiop como base para comunicação de grupo confiável em sistemas distribuídos de larga escala. Florianópolis: Dissertação (Mestre em engenharia elétrica) – Centro de Pós Graduação em Engenharia Elétrica, Universidade Federal de Santa Catarina, 2002. 105 p.

BOOKMAN, Charles. Agrupamento de computadores em Linux: aprenda a construir e manter grupos de computadores com Linux. Rio de Janeiro: Ciência Moderna, 2003. 240p.

BUYYA, Rajkumar: High Performance Cluster Computing: Architectures and Systems. Volume 1. New Jersey: Prentice-Hall, 1999. 849p.

BRASIL ESCOLA. Revolução do Computador: Os primeiros computadores. [S.1: Brasil Escola], 2007. Disponível em: http://www.brasilescola.com/informatica/revolucao-do-computador.htm. Acesso em: 13 ago. 2007.

CARLA, A. B. A., 2004 Cluster Híbrido. Trabalho de conclusão de Curso, UNASP, São Paulo, SP, Brasil.

CLUSTER KNOPPIX. [Online] kulnet. [Citado em: 07 de 11 de 2007.] Site de download da distribuição Linux Cluster Knoppix disponível em: ftp://kulnet.kuleuven.ac.be/pub/mirror/ clusterknoppix/.

DANTAS, Mario. Computação Distribuída de Alto Desempenho: Redes, Clusters e Grids Computacionais. Rio de Janeiro: Axcel Books, 2005. 262p.

ETSIMO. [Online] Etsimo. [Citado em: 25 de 10 de 2007.] Site de download da ferramenta Povray disponível em: ftp://etsimo.uniovi.es/pub/raytrace/povray/Official/Linux/.

GOULART, A. Sistemas Distribuídos e Comunicação em Grupo. Itajaí: 2002. 67p. Disciplina Tópicos Especiais em Computação, UNIVALI, 2002. Disponível em: http://www.din.uem.br/~cfmoro/download/APOSTILA_AdemirGoulart_SD_CGv10.PDF. Acesso em 25 abr. 2007.

106

GUIA DO HARDWARE. Supercomputador.[S.1: Guia do Hardware], 2007. Disponível em: http://www.guiadohardware.net/termos/supercomputador Acesso em: 09 fev. 2007.

LISBOA, D., AUGUSTO, L., 2002, Projeto, configuração e utilização de um cluster Beowulf: um estudo de caso. Trabalho de Conclusão de Curso, UNAMA, Belém, PA, Brasil.

LLCBENCH HOME PAGE. [Online] LLCBENCH. [Citado em: 24 de 10 de 2007.] Site de download da ferramenta LLCBench disponível em: http://icl.cs.utk.edu/projects/llcbench.

MARCELINO, B., PAULO, M., 2004 Cluster de Computadores: Estudo e Implementação de Ferramenta de Acesso via WEB. Trabalho de conclusão de Curso, UNAMA, Pará, PA, Brasil

MPIBENCH Home Page, 2007. Disponível em: http://icl.cs.utk.edu/projects/llcbench/ mpbench.html. Acesso em 22 jun. 2007.

NAS COMPUTING RESOURCES. NAS Computing Resources - Columbia Supercomputer.

[Online] [Citado em: 08 de 11 de 2007.] Disponível em: http://www.nas.nasa.gov/Resources/ Systems/columbia.html.

OLIVEIRA, H., LEITE, I., 2004 Construindo Cluster Beowulf com Software Livre. Trabalho de conclusão de Curso, UNAMA, Pará, PA, Brasil.

OPEN SOURCE LINUX CLUSTER PROJECT. [Online] Open Source Linux. [Citado em: 06 de 11 de 2007.] Site de download do pacote OpenMosix disponível em: http://openmosix.sourceforge.net/.

PITANGA, Marcos. Computação em Cluster, Rio de Janeiro, Nov. 2002. Disponível em: http://www.clubedohardware.com.br/artigos/153. Acessado em: 11/05/2007.

PITANGA, Marcos. Construindo supercomputadores com linux. 2ª edição. Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2004. 292 p.

ROCHA, J. M. G., 2001. Clusters Beowulf: Aspectos de Projeto e Implementação. Dissertação de Mestrado, UFPA, Belém, PA, Brasil.

RODRIGO, L., 2006. Avaliação da Implementação de Clusters de Computadores Usando Tecnologias Livres, v. 1, Junho de 2006, 52 p.

ROSE, C. A. F. Arquiteturas Paralelas. In: Escola Regional de Alto Desempenho, ERAD, 1ª, 2001. Anais... Gramado: SBC/ Instituto de informática da UFRGS/ Faculdade de Informática da PUCRS/UNISINOS, 2001. p.3-33

SCALABLE COMPUTING LABORATORY. [Online] Scalable Computing. [Citado em: 22 de 10 de 2007.] Site de download da ferramenta Netpipe disponível em: http://www.scl.ameslab.gov/netpipe/code/.

SILBERSCHATZ, G. G. Fundamentos de Sistemas Operacionais, 6a Edição, Editora LTC, 2002. 250 p.

107

SPRING. [Online] INPE. [Citado em: 25 de 09 de 2007.] Site de download do software de geoprocessamento spring disponível em:. http://www.dpi.inpe.br/spring/portugues/download/.

TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 2 ed. Editora Prentice-Hall, 2003. 362 p.

THE LINUX HOME PAGE AT LINUX [Online] The Linux Home Page [Citado em: 29 de 07 de 2007.] Site de download do código-fonte do kernel do sistema operacional Linux disponível em: http://www.linux.org/.

TOP500 SuperComputer Site, 2007. Disponível em: http://www.top500.org/lists/2007/11. Acesso em: 29 ago. 2007.

T-SYSTEM SFR FRESH [Online] T-System. [Citado em: 12 de 10 de 2007.] Site de download da ferramenta MPICH disponível em: http://fresh.t-systems-sfr.com/unix/src/misc/mpich-1.2.7p1.tar.gz/.

UK MIRROR SERVICE. [Online] UK Mirror. [Citado em: 09 de 05 de 2007.] Site de download da ferramenta BWATCH disponível em: http://www.mirrorservice.org/sites/ downloadsourceforge.net/ pub/sourceforge/b/bw/bwatch/.

VARGAS, E. High Availability Fundamentals. Sun Microsystems, San Antonio, 2000. Disponível em: http://www.sun.com/blueprints/1100/HAFund.pdf. Acessado em: 12/05/2007.

XPVM, 2006. Disponível em: http://www.netlib.org/utk/icl/xpvm/xpvm.html. Acesso em 16 set. 2007.

ZELENOVSKY, R.; MENDONÇA, A. Processadores para o próximo milênio. 2º parte. [S.1: Clube do Hardware], 2001. Disponível em: http://www.clubedohardware.com.br. Acesso em: 14 dez. 2007.

WEBER, R. F. Fundamentos de arquitetura de computadores: Série livros didáticos, número 8. Porto Alegre: Instituto de informática da UFRGS, Editora Sagra Luzzatto, 2000. 262 p.

universidade federal do parÁ curso de sistemas de ... · universidade federal do parÁ curso de...

Documents