UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Sidnei Baron[1].pdf · UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE CLUSTER DE BAIXO CUSTO

Área de Sistemas Paralelos e Distribuídos

por

Sidnei Baron

Ademir Goulart, M.Sc. Orientador

Itajaí (SC), junho de 2005

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE CLUSTER DE BAIXO CUSTO

Área de Sistemas Paralelos e Distribuídos

por

Sidnei Baron Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Ademir Goulart, M.Sc.

Itajaí (SC), junho de 2005

SUMÁRIO

LISTA DE ABREVIATURAS.................................................................iv

LISTA DE FIGURAS ..............................................................................vi LISTA DE TABELAS.............................................................................vii LISTA DE EQUAÇÕES ........................................................................viii RESUMO ..................................................................................................ix

ABSTRACT ...............................................................................................x

1. INTRODUÇÃO.....................................................................................1 1.1. OBJETIVOS ........................................................................................................ 2 1.1.1. Objetivo Geral ................................................................................................... 2 1.1.2. Objetivos Específicos ........................................................................................ 2 1.2. METODOLOGIA................................................................................................ 3 1.3. ESTRUTURA DO TRABALHO ....................................................................... 3

2. FUNDAMENTAÇÃO TEÓRICA .......................................................5 2.1. CLASSIFICAÇÃO DE SISTEMAS PARALELOS......................................... 5 2.1.1. Classificação de Flynn ...................................................................................... 5 2.1.2. Multiprocessadores e multicomputadores...................................................... 8 2.2. CLUSTER DE COMPUTADORES ................................................................ 11 2.2.1. Arquitetura de Hardware .............................................................................. 14 2.2.2. Arquitetura de Software................................................................................. 18 2.3. PROGRAMAÇÃO PARALELA ..................................................................... 24 2.3.1. PVM.................................................................................................................. 25 2.3.2. MPI................................................................................................................... 26 2.3.3. PVM x MPI...................................................................................................... 27 2.3.4. OpenMP ........................................................................................................... 29 2.4. ANÁLISE DE DESEMPENHO ....................................................................... 29 2.4.1. Lei de Amdhal ................................................................................................. 32 2.4.2. Ferramentas de Análise de Desempenho e de Gerenciamento................... 33 2.5. TRABALHOS RELACIONADOS .................................................................. 37

3. PROJETO............................................................................................39 3.1. MODELAGEM.................................................................................................. 39 3.2. DESENVOLVIMENTO.................................................................................... 48 3.2.1. Apresentação do Sistema................................................................................ 48 3.2.2. Dificuldades Encontradas .............................................................................. 51 3.2.3. Resultados ........................................................................................................ 52

4. CONCLUSÕES...................................................................................60

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................62

iii

ANEXO I – RESUMO PUBLICADO NO CRICTE 2004 ...................65

APÊNDICE A – MODELAGEM UML.................................................66

APÊNDICE B – REMASTERIZAÇÃO DO KURUMIN ....................94

APÊNDICE C – ARQUIVOS DE SAÍDA DO PARPAC...................105

APÊNDICE D – ARTIGO CIENTÍFICO...........................................109

LISTA DE ABREVIATURAS

AFS Andrew File System API Aplication Program Interface ATLAS Automatically Tuned Linear Algebra Software ATM Asynchomous Transmission Mode ATOLL Atomic Low Latency Network BPROC Beowulf Distributed Process BPS Bits Per Second BWATCH Beowulf Watch CC-NUMA Cache-Coherent Non-Uniform Memory Access CMA Control and Monitoring Agent COMA Cache-Only Memory Architeture COW Cluster of Workstation CRICTE Congresso Regional de Iniciação Científica e Tecnológica em Engenharia DSM Distributed Shared Memory E/S Entrada e Saída FFTW Fast Fourier Transform FLOPS Floating Point Operation Per Second FTP File Transfer Protocol GFLOPS Gigaflops ou Billions of Floating Point Operation Per Second GV Ganho de Velocidade HA High Availability HD Hard Disk HIPPI High Performace Parallel Interface IEEE Institute of Electrical and Electronics Engineers ITWM Institut Techno – und Wirtschaftsmatematik KSIX Kasetstart System Interconnected eXecutive LAN Local Área Network LAPACK Linear Algebra Package LINPACK Linear Algebra Software Package LLCBENCH Low Level Characterization Benchmark LSED Laboratório de Sistemas Embarcados e Distribuídos NAG Numerical Algorithms Group NCC-NUMA Non-Cache-Coherent Non-Uniform Memory Access NETPERF Network Performance NETPIPE Network Protocol Independent Performace Evaluator NFS Network File System NORMA No Remote Memory Access NOW Network of Workstation NUMA Non Uniform Memory Access MFLOPS Millions of Floating Point Operation Per Second MIMD Multiple Instruction Multiple Data MIPS Millions of Instruction Per Second MISD Multiple Instruction Single Data MPI Message Passing Interface MPITH MPI Thin and High-Performace OPENPBS Open Portable Batch System

v

OPENSCE Open Scalable Cluster Enviroment OSCAR Open Source Cluster Application Resource PC Personal Computer PCI Peripheral Component Interconnect PFS Parallel File System PIOUS Parallel I/O System PPS Packets Per Second PVFS Parallel Virtual File System PVP Parallel Vector Processor PVM Parallel Virtual Machine RAM Random Access Memory RMI Resource Management Interface RPC Remote Procedure Call RSH Remote Shell SQMS Simple Queuing Management System SAN System Area Network SC-NUMA Software-Coherent Non-Uniform Memory Access SCALAPACK Scalable Linear Algebra Package SCI Scalable Coherent Interface SCMS Scalable Cluster Management System SIMD Single Instruction Multiple Data SISD Single Instruction Single Data SMA System Management Agent SMB Server Message Block SMP Simetric Multi Processor SO System Operation SSI Single System Image SSH Secure Shell TCC Trabalho de Conclusão de Curso TCP Transmission Control Protocol TCP/IP Transmission Control Protocol / Internet Protocol TPS Transactions Per Second UDP User Datagramer Protocol UMA Uniform Memory Access UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí

LISTA DE FIGURAS

Figura 1. Fluxo de instrução e de dados...............................................................................................5 Figura 2. Arquitetura SISD ..................................................................................................................6 Figura 3. Arquitetura MISD.................................................................................................................6 Figura 4. Arquitetura SIMD.................................................................................................................7 Figura 5. Arquitetura MIMD................................................................................................................7 Figura 6. Classificação segundo o compartilhamento de memória......................................................8 Figura 7. Arquitetura dos multiprocessadores......................................................................................9 Figura 8. Arquitetura dos multicomputadores....................................................................................10 Figura 9. Arquitetura típica de um cluster .........................................................................................12 Figura 10. Estrutura em camadas do NFS..........................................................................................24 Figura 11. As três possibilidades de saídas para uma requisição de serviço .....................................30 Figura 12. Influência do custo de paralelização.................................................................................32 Figura 13. Diagrama de Classe do cluster..........................................................................................40 Figura 14. Diagrama de Caso de Uso da inicialização do sistema.....................................................41 Figura 15. Diagrama de Caso de Uso da criação de um programa paralelo ......................................43 Figura 16. Diagrama de Estado da execução de um programa paralelo no nó escravo .....................43 Figura 17. Diagrama de Estado da execução de um programa paralelo no nó mestre.......................44 Figura 18. Diagrama de Seqüência da inicialização de um nó...........................................................45 Figura 19. Diagrama de Seqüência da entrada dos nodos e a execução de um programa paralelo ...46 Figura 20. Diagrama de Componentes do cluster ..............................................................................47 Figura 21. Tela de boot do Kcluster...................................................................................................49 Figura 22. Execução do KCluster no laboratório de ciência da computação da UNIVALI ..............53 Figura 23. Execução do benchmarck PARPAC.................................................................................54 Figura 24. Desempenho alcançado em Gflops...................................................................................56 Figura 25. Tempo total de execução do PARPAC com rede de 10 e 100 Mbits ...............................57 Figura 26. Comparativo do desempenho alcançado entre uma rede 10 e 100 Mbits.........................57 Figura 27. Resultados da multiplicação de matrizes. .........................................................................58 Figura 28. Speedup do cluster com a multiplicação de matrizes .......................................................59 Figura 29. Exemplo de gráficos gerados pela ferramenta CACTI.....................................................61

vii

LISTA DE TABELAS

Tabela 1: Diferenças entre PVM e MPI .............................................................................................28 Tabela 2. Critérios para a seleção de uma técnica de avaliação.........................................................29 Tabela 3. Resultados do PARPAC.....................................................................................................55 Tabela 4. Comparativo entre a execução do PARPAC com a rede a 10 Mbits e 100 Mbits .............56 Tabela 5. Resultados da multiplicação de matrizes............................................................................58 Tabela 6. Speedup do cluster na multiplicação de matrizes...............................................................59

LISTA DE EQUAÇÕES

Equação 1 ...........................................................................................................................................31 Equação 2 ...........................................................................................................................................33 Equação 3 ...........................................................................................................................................33

RESUMO

BARON, Sidnei. Cluster de Baixo Custo. Itajaí, 2005. 64 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005. Um cluster pode ser definido como um conjunto de nós processados autônomos e que, interligados, comportam-se como um sistema único. Clusters são utilizados quando os serviços devem ser processados o mais rápidos possível ou ter alta disponibilidade. Pesquisadores, organizações e empresas estão utilizando os cluster porque necessitam de desempenho escalável, gerenciamento de recursos, disponibilidade ou processamento em nível supercomputacional a um preço adequado. A aquisição de máquinas e de redes de alto desempenho é cara. Grandes organizações e universidades possuem equipamentos que ficam boa parte do tempo com processadores ociosos. A fim de oferecer um cluster de baixo custo que contribua para um maior aproveitamento dos recursos das organizações e universidades, este projeto apresenta a modelagem, montagem, instalação, validação e disponibilização de um ambiente para processamento paralelo baseado em um cluster de PCs (Personal Computers). O cluster deverá ser escalável e os seus nodos deverão ser de fácil inclusão com configuração em ambientes distribuídos, onde a configuração manual das máquinas deva ser evitada. Na primeira parte deste trabalho foram realizados estudos dos conceitos de cluster, os passos necessários para a montagem e gerenciamento, e programação paralela. Ainda nesta parte foi a de modelagem, a qual especificou e se criou o modelo conceitual do sistema. A segunda parte foi a de desenvolvimento e validação do cluster, apresentando os resultados obtidos. Palavras-chave: Cluster. Sistemas Distribuídos, Programação Paralela.

ABSTRACT

A cluster can be defined as a set of autonomous prossessing nodes, interconneted, which behave as a unique system. Clusters are used when the services have to be processed the fastest as possible or with high availability. Researchers, organizations and companies are using clusters because they need scalable performance, resources management, availability or processing at super computational level to the adequated price. The acquisition of machines and network of high performance is expensive. Large organizations and universities have equipaments that are the greatest part of time with idle processors. In order to offer a cluster of low price that contributes to the greatest utilization of the resources of the organizations and universities, this work discusses how to model, mount, install, validate and turn available an environment for the parallel processing based on a cluster of personal computer. The cluster should be scalable and their nodes should be of easy inclusion with configuration in distributed environments, where the manual configuration of machines should be avoided. In the first part of this work concepts studies of clusters, the necessary steps to the assembly and management and parallel programming were accomplished. Also in this first part, was made the modeling that specifies and creates the conceptuel model of the system.The second part was the implemantation and validation of the cluster showing the results collected. Keywords: Cluster, Distributed Systems, Parallel Programming.

1

1. INTRODUÇÃO

Um cluster (ou agregado) de computadores pode ser definido como um sistema de

computação paralela composta de um conjunto de nós processadores (PCs – Personal Computers –

ou estações de trabalho) autônomos e que, interligados, comportam-se como um recurso

computacional único (BUYYA, 1999).

Existem vários tipos de cluster com algumas diferenças entre si, quanto à topologia de rede,

configuração e objetivo, entre outras características. O Cluster of Workstation (COW) e o cluster

Beowulf são exemplos de tipos de cluster.

Segundo Patterson (2000), serviços que freqüentemente requerem alta disponibilidade e

balanceamento de carga de forma escalável são indicados para o ambiente de cluster. Exemplos

desses são os Internet Service Providers (provedores de Internet) e sites de comércio eletrônico.

Indústrias cinematográficas podem se utilizar desses recursos, pois necessitam de alto desempenho

para renderização de gráficos de altíssima qualidade e animações.

Os nós de um cluster tendem a ser mais complexos e possuirem um custo administrativo

mais alto do que os nós de uma rede LAN (Local Area Network – Rede local), os quais

correspondem, em sua maioria, a PCs ou estações de trabalho monoprocessadas. Os nós de um

cluster podem conter vários processadores, sendo de igual ou maior complexidade que máquinas

proprietárias de processamento, se considerando a presença de discos e sistemas operacionais

completos no primeiro, em relação à ausência de discos e sistemas operacionais baseados em

microkernel no segundo (PATTERSON, 2000).

Pesquisadores, organizações e empresas estão utilizando os clusters porque necessitam de

desempenho escalável, gerenciamento de recursos, disponibilidade ou processamento em nível

supercomputacional a um preço adequado.

A aquisição de máquinas e de redes de alto desempenho é cara. Além do custo do hardware,

os custos de instalação e de manutenção também são altos, pois são feitos por profissionais

capacitados e, geralmente, terceirizados.

O trabalho de manutenção, tanto de software como de hardware, aumenta conforme a

quantidade de nós no cluster. Porém, existem algumas técnicas que podem ser utilizadas para

2

reduzir a manutenção de software. Essas técnicas podem ser de diferentes formas, um exemplo são

os scripts que, a partir de um local centralizado, instalam, atualizam ou removem o software nas

máquinas. Outra técnica utilizada é a de criação de uma imagem a partir de uma máquina e a

replicação dessa imagem em todas as outras da rede. Quando for necessário fazer uma atualização

ou nova instalação de algum software, basta criar uma imagem com este software e replicar em

todos os nós.

Grandes organizações e universidades possuem laboratórios que ficam uma boa parte do

tempo com processadores ociosos, tais como muitos laboratórios de ensino, nas universidades, nos

finais de semana. Esses ambientes poderiam ser melhor aproveitados em horários que não estão

sendo utilizados localmente.

A fim de oferecer um cluster de baixo custo que contribua para um maior aproveitamento

dos recursos das organizações e universidades, este projeto propõe modelar, montar, instalar,

validar e disponibilizar um ambiente para processamento paralelo baseado em um cluster de

PCs.

1.1. OBJETIVOS

1.1.1. Objetivo Geral

Este projeto de pesquisa tem como objetivo geral modelar, montar, instalar, validar e

disponibilizar um ambiente para processamento paralelo baseado em um

cluster de PCs. O cluster deverá ser escalável e os seus os nodos deverão ser de fácil inclusão e

configuração em ambientes distribuídos onde a configuração manual das máquinas deva ser evitada.

1.1.2. Objetivos Específicos

Os objetivos específicos deste projeto de pesquisa são:

• Realizar estudo sobre cluster, configuração e gerenciamento;

• Determinar os passos necessários para montagem de um cluster;

• Realizar estudo sobre programação de sistemas paralelos e ferramentas de

gerenciamento;

• Realizar modelagem conceitual do ambiente de processamento paralelo;

3

• Montar e instalar o servidor (nó-mestre) do cluster;

• Instalar ferramentas necessárias para rodar sistemas paralelos;

• Montar e instalar o cliente (nó-escravo) do cluster;

• Desenvolver um mecanismo para automatizar a instalação e configuração do

servidor e do cliente no cluster;

• Selecionar programas paralelos para validação do cluster;

• Testar e validar o sistema no cluster;

• Documentar o desenvolvimento e os resultados do sistema.

1.2. METODOLOGIA

Foram realizadas várias etapas para alcançar o objetivo deste trabalho. Nesta primeira parte

do projeto (TCC I), a etapa inicial foi a de aprendizado, na qual foi realizado um estudo sobre

clusters, os passos necessários para montagem e gerenciamento de um cluster, e programação de

sistemas paralelos. A segunda etapa foi a de modelagem, a qual especificou o funcionamento e se

criou o modelo conceitual do sistema.

Na segunda parte deste projeto (TCCII), foi desenvolvido o sistema modelado,

disponibilizado programas paralelos, validando o cluster com programas paralelos e analisando seus

resultados. Em paralelo com essas atividades, foi realizado a documentação deste trabalho e

redigido um artigo científico.

1.3. ESTRUTURA DO TRABALHO

Este trabalho está dividido em quatro capítulos: introdução, fundamentação teórica, projeto e

considerações finais.

No capítulo de fundamentação teórica são descritos os conceitos que envolvem o ambiente

de cluster, como a classificação de máquinas paralelas, programação paralela, ferramentas de

gerenciamento e avaliação, e também as ferramentas (serviços) necessárias para a implementação

de um cluster.

4

No capítulo de projeto são apresentadas a modelagem UML (Unified Modeling Language)

do sistema, as dificuldades encontradas e as soluções adotadas. Neste capítulo também é

apresentado a funcionalidade do sistema e os resultados obtidos.

Por fim, são apresentadas as considerações finais a respeito do desenvolvimento de todo o

TCC.

2. FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os conceitos relevantes para o desenvolvimento deste

projeto, descrevendo a classificação dos sistemas paralelos, cluster, programação paralela e análise

de desempenho. No final deste capítulo são apresentados alguns trabalhos relacionados com este

projeto.

2.1. CLASSIFICAÇÃO DE SISTEMAS PARALELOS

2.1.1. Classificação de Flynn

Conforme Gualeve (2004), Michael Flynn, em 1972, caracterizou diversos modelos de

arquiteturas de computadores seguindo dois critérios, o número de fluxos de dados e de instruções.

A classificação foi feita em quatro classes de computadores, conforme a Figura 1.

Fluxo de Instrução

Único Múltiplo

Único SISD MISD Fluxo de

Dados Múltiplo SIMD MIMD

Figura 1. Fluxo de instrução e de dados

Fonte: Adaptado de Gualeve (2004).

Estas classes são:

• Arquitetura SISD (Single Instruction Single Data): As instruções são executadas

seqüencialmente sem qualquer paralelismo. São as máquinas Von Neuman

tradicionais. A Figura 2 apresenta esta arquitetura.

6

Figura 2. Arquitetura SISD

Fonte: (GUALEVE, 2004).

• Arquitetura MISD (Multiple Instruction Single Data): São máquinas que executam

várias instruções ao mesmo tempo sobre um único dado (Figura 3). Esta categoria

não possui nenhuma máquina como exemplo.

Figura 3. Arquitetura MISD


• Arquitetura SIMD (Single Instruction Multiple Data): São máquinas que executam

uma instrução paralelamente utilizando vários dados de forma síncrona (Figura 4).

Exemplos dessa categoria são os processadores atuais que possuem a tecnologia

MMX (MultiMedia eXtension).

7

Figura 4. Arquitetura SIMD


• Arquitetura MIMD (Multiple Instruction, Multiple Data): São máquinas que

possuem mútiplos fluxos de instruções e múltiplos dados e que cada processador age

independentemente (Figura 5).

Figura 5. Arquitetura MIMD


8

2.1.2. Multiprocessadores e multicomputadores

Dependendo de uma máquina paralela utilizar-se ou não de uma memória compartilhada por

todos os processadores, pode se diferenciar as máquinas paralelas em multiprocessadores (memória

compartilhada) e multicomputadores (memória distribuída). Esta classificação é apresentada na

Figura 6, e explicada nos tópicos seguintes.

Figura 6. Classificação segundo o compartilhamento de memória

Fonte: (ROSE e NAVAUX, 2002).

2.1.2.1. Multiprocessadores

Nesta classe, as máquinas são fortemente acopladas, pois possuem múltiplos processadores

que compartilham um espaço de endereçamento de memória comum (Figura 7).O uso de uma

memória cache em cada processador é adotado para evitar o gargalo gerado quando uma única área

de memória é acessada simultaneamente por diversos processadores. Para manter todos os cache

atualizados é utilizada uma técnica chamada write-trhough, onde toda a gravação é feita na

memória principal e a leitura na memória cache. Também todas as cache ficam monitorando o

barramento e se alguma alteração ocorrer na memória principal, cujo endereço também está na

cache de um processador, este também atualiza o conteúdo da cache (TANENBAUM, 1995).

MIMD

Multiprocessadores (espaço de endereçamento único)

Multicomputadores(múltiplos espaços de endereçamento)

UMA (memória central)

NUMA (memória distribuída)

NORMA

COMA

CC-NUMA

NCC-NUMA

SC-NUMA

9

Figura 7. Arquitetura dos multiprocessadores


A vantagem desta arquitetura é que o compartilhamento de dados entre os processos torna-se

muito mais rápido. As desvantagens são que os computadores são caros, possuem limitação física

para a quantidade de processadores e necessitam de técnicas de sincronização para a leitura e

gravação dos dados (PITANGA, 2004c).

Dependendo da interligação dos processadores com a memória, a classe de

multiprocessadores se enquadra em duas categorias principais:

• UMA (Uniform Memory Access): existe um espaço de endereçamento comum

acessível a todos os processadores através de uma rede de interconexão;

• NUMA (Non Uniform Memory Access): a memória utilizada é distribuída,

implementada em vários módulos que são associados a cada processador. O espaço

de endereçamento é único e cada processador pode acessar toda a memória do

sistema.

A categoria NUMA ainda pode ser subdividida dependendo da coerência de cache ter sido

tratado ou não, e se esse tratamento ter sido feito por hardware ou em software:

• NCC-NUMA (Non-Cache-Coherent Non-Uniform Memory Access): variação de

NUMA em que não há coerência de cache garantida em hardware;

• CC-NUMA (Cache-Coherent Non-Uniform Memory Access): variação de NUMA

em que há coerência de cache garantida em hardware.

10

• SC-NUMA (Software-Coherent Non-Uniform Memory Access): variação da NUMA

em que a coerência de cache é implementada em software, de forma transparente

para o usuário. Essa camada também é conhecida como DSM (Distributed Shared

Memory)

• COMA (Cache-Only Memory Architeture): variação da NUMA em que todas as

memórias locais estão estruturadas como memória cache, e todas as caches formam

um espaço de endereçamento global. São utilizados mecanismos em hardware para

garantir a coerência de cache.

2.1.2.2. Multicomputadores

Nesta classe as máquinas são formadas por várias unidades processadoras, cada uma

unidade (nó) é constituída por um processador, memória local e dispositivo de entrada/saída (Figura

8). Nesta classe a comunicação entre os diferentes nós do sistema é feita através de dispositivos

físicos de entrada/saída ligadas num barramento de interconexão, como uma rede local de

velocidade de 100 a 1000 Mbps (ROSE e NAVAUX, 2002). Devido a essas características os

multicomputadores são denominados fracamente acoplados.

Figura 8. Arquitetura dos multicomputadores


A vantagem desta classe é que é possível construir máquinas deste tipo com milhares de

unidades processadas. As desvantagens são que a programação é mais complicada e o paralelismo

11

não é tão intuitivo e que a troca de mensagem para a comunicação pode comprometer o

desempenho (PITANGA, 2004c).

Conforme Rose e Navaux (2002), conforme a interligação dos processadores com a

memória, estas máquinas podem ser classificadas como NORMA (No Remote Memory Access).

Nesta classificação, os processadores, conectados em rede de alto desempenho, possuem memórias

locais e a troca de dados é realizada através de troca de mensagens.

2.2. CLUSTER DE COMPUTADORES

Segundo Buyya (1999), um agregado, ou no inglês cluster, é um sistema de computação

paralela composto de um conjunto de elementos (nós) que se comunicam através de uma rede de

interconexão e utilizam softwares de sistemas distribuídos para resolver um problema. Cada

elemento é composto por um ou mais processadores e de uma ou mais memórias. Estes elementos

são visto pelos seus usuários como um sistema de recurso único, também chamado de sistema de

imagem única (SSI – Single System Image).

Goulart (2002), descreve de maneira mais ampla os principais componentes da arquitetura

de um cluster de computadores. Os componentes apontados por ele são:

• Nó ou node;

• Sistema Operacional;

• Rede Local;

• Protocolos;

• Camada de interface;

• Ferramentas de comunicação; e

• Sistemas de arquivos paralelo.

A Figura 9 mostra uma arquitetura típica de um cluster.

12

Figura 9. Arquitetura típica de um cluster

Fonte: (GOULART, 2002).

Segundo Pitanga (2004b) os clusters, dependendo da sua área e para qual função é utilizado,

podem ser divididos nos seguintes tipos:

• Alta Disponibilidade (High Availability (HA) and Failover): estes modelos de

clusters são construídos para prover uma disponibilidade de serviços e recursos de

forma ininterrupta através do uso da redundância implícita ao sistema. A idéia geral

é que se um nó do cluster vier a falhar (failover), aplicações ou serviços possam estar

disponíveis em outro nó. Estes tipos de cluster são utilizados para base de dados de

missões críticas, correio, servidores de arquivos e aplicações.

• Balanceamento de carga (Load Balancing): este modelo distribui o tráfego entrante

ou requisições de recursos provenientes dos nodos que executam os mesmos

programas entre as máquinas que compõem o cluster. Todos os nodos estão

responsáveis em controlar os pedidos. Se um nó falhar, as requisições são

redistribuídas entre os nós disponíveis no momento. Este tipo de solução é

normalmente utilizado em fazendas de servidores de web (web farms).

• Combinação HA & Load Balancing: este modelo combina as características dos dois

tipos de cluster, aumentando assim a disponibilidade e escalabilidade de serviços e

recursos. Este tipo de configuração de cluster é muito utilizado em servidores de

web, email ou FTP (File Transfer Protocol).

• Alto Desempenho (Processamento Distribuído ou Paralelo): este modelo de cluster

aumenta a disponibilidade e performance para as aplicações, particularmente as

13

grandes tarefas computacionais. Uma grande tarefa computacional pode ser dividida

em pequenas tarefas que são distribuídas pelas estações (nós), como se fosse um

supercomputador massivamente paralelo. Estes clusters são usados em tarefas que

exigem alto poder de processamento, como na computação científica ou em análise

financeiras.

Conforme a configuração e objetivos os clusters podem ser chamados de diferentes formas

entre diferentes grupos de pesquisa. A seguir são apresentados alguns deles:

• NOW (Network of Workstation): segundo a definição de Rose e Navaux (2002), e de

Bueno (2004), essas máquinas são sistemas constituídos por um conjunto de estações

de trabalho completos (com teclado, monitor, mouse) interligadas por uma

tecnologia tradicional de rede como Ethernet ou ATM (Asynchomous Transmission

Mode). Elas cumprem funções de uso diário, com diversos tipos de programas, e de

uso para processamento paralelo pesado no final do dia e/ou nos fins de semana.

• COW (Cluster of Workstation): são considerados uma evolução das máquinas NOW.

Como as NOW, também são constituídos por vários PCs interligados, mas com a

diferença de terem sido projetadas com o objetivo de executar aplicações paralelas.

Dessa forma, as máquinas podem ser otimizadas para este fim, retirando monitor,

teclado e o mouse. Mas as principais otimizações são feitas no software. Como essas

estações não vão ser usadas localmente, o sistema operacional pode ser “enxugado”,

desabilitando vários serviços e simplificando (ou mesmo eliminando) algumas

camadas de rede, já que as necessidades de comunicação das máquinas paralelas é

diferentes das redes locais. Estas máquinas resultantes são denominadas de headless

workstation ou de Pile-of-PC´s (ROSE e NAVAUX, 2002).

• Beowulf: desenvolvida pela NASA em 1994, é uma tecnologia de cluster que agrupa

computadores rodando o sistema operacional GNU/Linux para formar um

supercomputador virtual para o processamento paralelo (distribuído). Este tipo de

cluster requer o uso de uma biblioteca de troca de mensagens como PVM ou MPI,

ou o uso de múltiplos processos como o MOSIX (BUENO, 2004).

• OpenMosix: foi criado para manter os privilégios do projeto MOSIX em software de

código aberto. O MOSIX é uma extensão do núcleo do sistema operacional – no caso

do OpenMosix, o sistema operacional Linux, que faz com que um cluster de

14

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.

As aplicações que se beneficiam com o MOSIX são processos com longos tempos de

execução e baixo volume de comunicação (OPENMOSIX, 2005).

Goulart (2002) destaca entre as inúmeras vantagens em se utilizar cluster as seguintes: alta

performance; escalabilidade e facilidade de expansão; alta disponibilidade; baixo custo e;

independência de fornecedores.

2.2.1. Arquitetura de Hardware

2.2.1.1. Nó

O nó, ou node em inglês, é responsável por todas as atividades e capacidades associadas

com a execução de aplicações e suporte a ambientes sofisticados de software (STERLING, 2002).

Na arquitetura cluster o nó mestre, ou nó controlador, tem a função de gerenciar todos os

outros nós escravos que compõem o cluster. O nó mestre também pode funcionar como uma ponte

que liga a rede externa com o cluster.

Um cluster pode ser composto de simples PCs, poderosas estações de trabalho SMPs

(Symmetric Multi Processor) e até mesmo supercomputadores vetoriais (PITANGA, 2004c).

A escolha do hardware e a configuração dos computadores escravos podem ser baseadas

algumas vezes no tipo das aplicações que serão executadas no sistema. As características mais

importantes a serem consideradas são (PITANGA, 2004c):

• Tipo de processador;

• Tamanho e velocidade da memória cache L2;

• Número de processadores por nó;

• Capacidade, velocidade e tecnologia da memória RAM (Random Access Memory);

• Velocidade do barramento PCI (Peripheral Component Interconnect);

• Capacidade e velocidade dos discos rígidos;

• Placa de Vídeo;

15

• Chipset da placa mãe e;

• Placas de rede.

Um cluster pode ser caracterizado como heterogêneo ou homogêneo, e tem implicações

importantes no balanceamento de carga das aplicações conforme sua característica. Um cluster

homogêneo todos os nós do cluster tem as mesmas características e a mesma rede de comunicação.

Ao contrário dos homogêneos, os clusters heterogêneos possuem nós com características diferentes

ou diferentes redes de comunicação. (PITANGA, 2004c).

2.2.1.2. Rede

A habilidade de comunicação entre os nós do cluster é de extrema importância e pode ser

diferenciada de cluster para cluster. O hardware (a placa de rede, o switch e o cabeamento) de uma

rede local tem total influência na performance do cluster.

A rede de interconexão entre os nós pode levar a uma gama de diferentes topologias de rede

– topologias já existentes ou muitas delas ainda sendo pesquisadas e desenvolvidas. Segundo

Tanenbaum (1995), as topologias mais comuns para cluster são: árvore, hipercubo, barramento

cruzado (crossbar) e malha (mesh). Cada uma destas topologias possui vantagens e desvantagens

em termos de performance de comunicação ou de custo de implementação.

A primeira questão a ser levantada quando o cluster é exposto a Internet é em relação à

segurança, fator que não é primordial à sua implementação para um cluster isolado da Internet.

Alguns mecanismos podem aumentar a segurança desses clusters, como na utilização do SSH

(Secure Shell) ao invés do RSH (Remote Shell) e a utilização de firewalls para controlar os pacotes

que trafegam no cluster (PITANGA, 2004c).

Em contra partida, estes mecanismos podem diminuir consideravelmente o desempenho do

cluster. Uma outra solução para a questão de segurança é isolar o cluster da Internet e disponibilizar

somente um nó do cluster, o qual será uma ponte para o cluster e a partir dele disparar a aplicações

no cluster. Com esta solução é possível aplicar políticas de segurança, como firewalls, em cima

deste nó, facilitando a administração de segurança e não comprometendo o tráfego dentro do

cluster.

16

Segundo Sterling (2002), a mais popular e barata tecnologia de rede é a Ethernet,

particularmente a Fast Ethernet. Ela é a tecnologia mais utilizada para redes locais (LAN – Lan

Area Network).

A Ethernet foi desenvolvida pela Xerox PARC no início da década de 70 e se padronizou

pela IEEE (Institute of Electrical and Electronics Engineers) no início da década de 80. O padrão

Ethernet possui a largura de banda de 10 Mbps. Essa tecnologia continua se evoluindo, aumentando

a banda base (STERLING, 2002). Essas novas tecnologias são:

• Fast-Ethernet: possui largura de banda de 100 Mbps, mas pode operar em 10 Mbps e

tem um custo muito baixo.

• Gibabit-Ethernet: possui largura de banda de 1 Gbps e possui um custo mais elevado.

Ainda segundo Sterling, 2002, uma rede Ethernet-based não é a única escolha da tecnologia

para a comunicação entre os nós de um cluster. Outras soluções existentes podem ser consideradas

igual ou de melhor performance dependendo da aplicação. Sterling (2002) cita algumas destas

tecnologias:

• Myrinet: é uma tecnologia de rede local de sistema (SAN – System Area Network)

desenvolvidada pela Myricom, Inc. A largura da banda é, originalmente, de 640

Mbps e as mais recentes chegam a 2,4 Gbps e a latência é inferior a 10 µs. A grande

vantagem desta tecnologia é o protocolo personalizado designado para alta

perfomace e baixa latência. A desvantagem desta tecnologia é o alto custo.

• cLan: esta tecnologia implementa nativamente a VIA. A largura de banda é de 2,5

Gbps bidirecional e tem uma latência em torno de 0,5 µs. Por causa da sua

implementação VIA diretamente no hardware a latência é baixa e a largura de banda

é alta.

• SCI (Scalable Coherent Interface): é um padrão IEEE originalmente destinado a

prover uma interconexão para sistemas de memória compartilhada com coerência de

cache. Esta tecnologia foi desenvolvida pela Convex Exemplar SPP-1000 em 1994.

A largura de banda está entre 400 e 1000 Mbps e com uma latência menor que 10 µs.

Esta tecnologia tem um eficiente paradigma de programação, com memória

compartilhada ao nível de usuário, mas os preços dos componentes são relativamente

17

altos e possuem algumas restrições de implementação devido ao tipo de comutadores

existentes.

• QsNet: é uma tecnologia de rede de alta performance desenvolvida pela Quadrics.

Esta rede possui uma largura de banda de 340 Mbps e com uma latência em torno de

5 µs. Para prover alta performance a Quadrics usou muitas técnicas similares a

Myrinet.

• Infiniband: essa tecnologia combina muita das concepções da VIA com

detalhamento elétrico e especificação da interface que permitem vendedores

produzirem componentes interoperáveis.

• ServerNet: é um produto da Compaq Tandem Labs desde 1995. Essa tecnologia

oferece porte direto para o padrão VIA em hardware, switches com doze portas não-

bloqueantes e links grandes entre os switches.

• ATM (Asynchonous Transmission Mode): é um padrão internacional de rede

produzido pelo ATM Forum. ATM é projetado dentro do conceito de células ou

pequenos pacotes de tamanho fixo. É uma tecnologia baseada em switch que utiliza a

idéia de circuitos virtuais para obter um serviço de conexão orientada. Essa

tecnologia oferece largura de banda alta em comparação a outras tecnologias

similares que são relativamente caras.

• Fiber Channel: é uma tecnologia de conexão para transporte de dados de alto

desempenho, produzidos como um conjunto de padrões pela Fiber Channel Industry

Association. Esta tecnologia pode transportar muitos tipos de dados a velocidade

acima de 1 Gbps através de fios de cobre ou cabos de fibra ótica.

• HIPPI (High Performace Parallel Interface): é uma rede Gigabit produzida pelo High

Performace Networking Forum. Esta rede foi inicialmente projetada para

interconectar computadores paralelos de alto desempenho, com redes de dispositivos

de armazenamento fixos que seguem o padrão ANSI X3T11. Esta tecnologia possui

uma largura de banda de 800 Mbps ou 1,6 Gbps.

• Reflective Memory: essa tecnologia utiliza E/S com memória-mapeada para fornecer

a ilusão de uma memória com interconexão fixa e foi desenvolvida pela

Universidade de Ohio. Com essa tecnologia, os nós gravam em uma localização da

18

memória local na placa de rede e o dado é difundido automaticamente para a rede de

modo que fique disponível para todos os nós.

• ATOLL (Atomic Low Latency Network): é uma das mais novas tecnologias de

computação para cluster, produzida pela Universidade de Mannheim. Essa

tecnologia possui quatro interfaces de redes independentes, um switch com

barramento 8 x 8 cruzado, quatro interface de link em um único chip. A largura de

banda é próximo a 200 Mbps e a latência é menor que 4 µs.

2.2.2. Arquitetura de Software

2.2.2.1. Sistema Operacional

Segundo Toscani (2003), depois do surgimento das redes de computadores e dos sistemas

distribuídos, os sistemas operacionais (SO – System Operation) tiveram que ser adaptados para

realizar novas funções e solucionar problemas que antes não existiam. Além do atendimento aos

usuários locais, o SO passou a se preocupar com o atendimento de requisições de serviços

originadas em outro computador e permitir que os usuários locais também possam utilizar recursos

de outros computadores na rede.

Outra mudança que o SO teve que se adaptar foi em relação ao sistema de comunicação, o

qual deve ser mais sofisticado. Por exemplo, o sistema de comunicação deve garantir a correção na

transmissão das mensagens e recuperação automática em caso de falha de um computador na rede

(TOSCANI, 2003).

A possibilidade de organização para um sistema distribuído do ponto de vista de software

são inúmeras. Segundo Tanenbaum (1995), os sistemas operacionais para uma arquitetura

distribuída pode ser distinguida em dois tipos, levando em conta o grau de transparência na

utilização dos recursos do sistema. Os tipos são:

• SO para rede: é implementado por software considerado “fracamente acoplado”, no

qual os componentes do sistema em cada computador podem ser distintos. A

utilização dos recursos remotos deve ser indicada explicitamente através de algum

comando especial, como o telnet e FTP;

• SO distribuído: é implementado por software considerado “fortemente acoplado”, no

qual os componentes do sistema em cada computador são os mesmos. A utilização

19

dos recursos remotos é gerida pelo sistema, de forma transparente para o usuário.

Este tipo de SO também deve oferecer confiabilidade, desempenho e escalabilidade.

Também é desejável que este SO tenha mecanismos de balanceamento de carga e de

migração de processos.

Segundo Kreutz (2003 apud Rauber, 2003), a maioria dos clusters existentes tem como base

uma versão de um sistema do tipo Unix. Isto se deve a principalmente ao fato de as máquinas do

cluster são servidores, mesmo que dedicado ao processamento paralelo, e porque a maior parte dos

grandes clusters estão em instituições de ensino, que preferem softwares de código aberto. Por estes

e outros motivos, os softwares de gerencia de cluster são escritos para funcionar em sistemas do

tipo Unix.

Linux é o sistema operacional mais popular entre os clusters. A razão pela qual o Linux foi

escolhido para a utilização nos cluster é porque ele é monolítico, multitarefa, possui memória

virtual e pode ser baixado livremente da Internet sem nenhum custo. Além destas características, o

Linux ainda possui todo o código fonte e é a principal ferramenta de pesquisa em ciências da

computação (STERLING, 2002).

2.2.2.2. Protocolos

Tradicionalmente computadores paralelos utilizam protocolos específicos de comunicação

para a transmissão de dado entre os nós da rede. Em contraste, um cluster Beowulf utiliza-se dos

protocolos normais (TCP/IP - Transmission Control Protocol / Internet Protocol) de uma rede local,

mantendo o custo baixo (STERLING, 1999).

O TCP/IP, baseados nos protocolos padrões que foram desenvolvidos, podem organizar as

tarefas de comunicação em cinco níveis independentes: camada de aplicação; camada de transporte;

camada de Internet; camada de acesso à rede; camada física (GOULART, 2002).

Na camada de Internet, o protocolo IP prove um básico serviço de roteamento de pacotes

através de múltiplas redes. Na camada de transporte se encontram o protocolo TCP (Trassmission

Control Protocol) e UDP (User Datagramer Protocol), que são os protocolos mais importantes nesta

camada (HUNT, 1992).

O TCP é orientado a conexão e prove um serviço confiável de transferência seqüencial de

dados, fazendo a verificação de erros nos pacotes enviados e a verificação da integridade no final da

20

transmissão. Antes de iniciar uma transmissão de dados, uma informação de controle, chamado de

handshake, é enviada para estabelecer a conexão. O mesmo acontece para fechar uma conexão e

encerrar a transferência dos dados (HUNT, 1992).

Para Sterling (1999), o UDP, diferente do TCP, não controla a seqüência dos pacotes, ou

seja, não garante que o dado foi entregue corretamente ao seu destinatário. A vantagem de utilizar o

protocolo o UDP é que ele possui uma baixa latência, pois não causa um atraso inicial.

Um jeito de ganhar performance na rede é eliminar cópias desnecessárias de dados entre o

buffers no kernel ou entre o kernel e o espaço do usuário (user space). Esta técnica é chamada de

protocolo Zero-copy. Este protocolo da a aplicação direto de acesso ao hardware de rede, o qual

copia os dados diretamente para e dos buffers da aplicação (STERLING, 1999).

Outra estrutura comum para os sistemas distribuídos é a do cliente-servidor. A idéia por trás

deste modelo é a de estruturar o sistema operacional como um grupo de processos cooperantes

(servidores), que oferecem serviços a processos usuários (clientes). Para evitar o overhead

considerável dos protocolos orientado a conexão, o modelo cliente servidor é baseado em um

protocolo muito simples, sem conexão, do tipo solicitação/resposta. A vantagem deste modelo é a

simplicidade (GOULART, 2002).

Os Sockets são geralmente utilizados para implementação de uma função básica

cliente/servidor. Socket é uma interface (API – Aplication Program Interface) de baixo nível entre o

programa do usuário e o sistema operacional e a camada do hardware da rede. A idéia básica por de

trás da abstração do socket é que a comunicação na rede lembra um arquivo de E/S suficientemente

fechado que a mesma chamada ao sistema pode ser usada para ambos. Uma vez a comunicação de

rede é estabelecida entre dois processos, a transmissão e o recebimento dos dados é executado com

read e write (STERLING, 1999).

2.2.2.3. Sistema de Imagem Única

O sistema de imagem única (SSI – Single System Image), também chamados de midleware,

refere-se à forma como o usuário percebe a máquina paralela (cluster) como um todo, ou seja, como

um sistema único. O sistema de imagem única é bastante significante, pois facilita a utilização

desses sistemas pelos usuários (ROSE e NAVAUX, 2003).

21

Segundo Rose e Navaux (2003), os multiprocessadores, como o SMPs e PVPs (Parallel

Vector Processor), possuem uma visão única do sistema melhor do que os multicomputadores,

porque nos multiprocessadores, apenas o recurso processador foi replicado em uma arquitetura

convencional, enquanto que nos multicomputadores toda a arquitetura foi replicada.

O MPI, o PVM, o MOSIX e o BProc (Beowulf Distributed Process) são alguns exemplos de

sistema de imagem única.

2.2.2.4. Ferramentas de comunicação

Segundo Pitanga (2004c), o ambiente de programação pode oferecer portabilidade,

eficiência e ferramentas para o desenvolvimento de programas paralelos. Essas ferramentas incluem

ainda APIs, para criar um espaço único para os processos, compiladores e depuradores.

Segundo Barcellos e Gaspary (2002), existem basicamente quatro modelos de comunicação

entre os processos:

1. Troca de mensagem: este modelo é largamente utilizado em processamento de alto

desempenho e consiste em enviar (send) e receber (receive) uma área de memória de um

destinatário remoto. O modelo de mensagens pode ser utilizado através de APIs ou por

interface de programação de sockets. PVM (Parallel Virtual Machine) e o MPI (Message

Passing Interface) são exemplos deste modelo.

2. Chamada remota de procedimento: ou RPC (Remote Procedure Call), consiste em

chamar um procedimento localizado em um computador remoto. Para que esta chamada

seja possível, as estruturas de dados passadas como parâmetro dos procedimentos devem

ser conhecidas por ambas as partes (cliente e servidor). Isto é feito através do código

stub, o qual compila um trecho do programa junto ao programa cliente e servidor. Para

conseguir isto o stub prepara os dados, serializando os mesmos e colocando o resultado

em pacotes.

3. Invocação remota de método: este modelo é parecido com o RPC, mas para programas

escritos com a programação orientada a objetos. Neste modelo um objeto invoca a

execução de um método em objetos que se encontram distribuídos. Como argumento,

podem ser passados ao método valores por referência ou por cópia. Exemplos desta

implementação é o Java RMI e o CORBA.

22

4. Memória compartilhada distribuída: este modelo é o mesmo utilizado em

multiprocessadores, sendo que os processos de aplicações têm a impressão de uma

memória física global. Isto é feito fazendo com que os processos em diferentes máquinas

compartilhem um segmento de memória, cada um mapeando tal área em seu espaço de

endereçamento virtual.

2.2.2.5. Sistema de arquivos distribuídos

Um sistema de arquivos distribuídos permite compartilhar informações entre os usuários de

uma rede por meio de um sistema de arquivo comum. A descrição abaixo é uma síntese da descrita

por Pitanga (2004c).

Os sistemas de arquivos distribuídos são desenvolvidos em nível de espaço de usuário,

preocupando-se com tolerância a falhas, transparência e escalabilidade. Esse sistema deve fornecer

um serviço de armazenamento de arquivos em memória secundária e tratar da alocação e

administração desse espaço, devendo se preocupar com operações sobre arquivos de uma forma

individualizada. Além desses serviços, ele também deve disponibilizar um método de mapeamento

entre um nome textual de um arquivo para uma referência e prover um serviço de diretórios.

A tecnologia de cluster filesystem (sistema de arquivo para cluster) é um complemento do

sistema de arquivo distribuído, o qual permite uma visão unificada do mesmo filesystem dos

diversos computadores que pertencem ao cluster.

Existem sistemas de arquivos distribuídos para todos os tipos de aplicações e problemas que

se deseja resolver. Alguns são mais tradicionais e outros mais inovadores, criados para resolver

problemas específicos.

Dentre os diversos sistemas de arquivos distribuídos, podemos citar alguns mais conhecidos

na utilização em cluster:

• NFS (Network File Systems): foi desenvolvido pela SUN Microsystems, Inc. Com

este sistema é possível que um computador realize acesso a um arquivo residente em

outro computador de forma comum e transparente. Para realizar este acesso remoto,

o NFS faz uso de três protocolos cliente-servidor: o protocolo de montagem

(MOUNT), o protocolo de acesso (NFS) e o protocolo do gerenciador de lock

(NLM). A Figura 10 mostra a estrutura em camadas do NFS (REDHAT, 2004).

23

• AFS (Andrew File System): parecido com o NFS, o AFS prove um acesso remoto

transparente a arquivos compartilhados para programas rodando em estações UNIX.

Foi desenvolvido em Carnegie Mellon University em 1983. Para conseguir um bom

desempenho o AFS mantém o arquivo na cache do nó escravo, assim todas as

operações de leitura e escrita são realizadas como se fosse um arquivo local.

Somente quando o arquivo é fechado ele é transferido de volta para o servidor.

(COULOURIS, 2001).

• PIOUS (Parallel I/O System): é um completo sistema de E/S paralelo para o

ambiente de computação distribuída PVM 3. O PIOUS implementa um completo

sistema de arquivo paralelo em cima do PVM. As aplicações PVM acesso

transparente para compartilhar arquivos utilizando as funções da biblioteca PIOUS

(PIOUS, 2004).

• PFS (Parallel File System): é um sistema de arquivos paralelos que prove dados

distribuídos e acesso paralelo a todos os nós do cluster. Este sistema tem como

objetivo aumentar a performance de E/S existentes em aplicações paralelas no

armazenamento e recuperação de dados. Para isso, o PFS prove de um espaço de

nomes único em todo o cluster, e armazena os arquivos de dados entre vários nós

que compõem o cluster de forma distribuída (STERLING, 2002).

• PVFS (Parallel Virtual File System): é uma implementação open source do PFS

desenvolvido exclusivamente para cluster Beowulf e o sistema operacional Linux

(STERLING, 2002).

• MPI-IO: é uma interface para sistema paralelo de E/S específico para o MPI-2. Ele

permite que programas paralelos façam operações de leitura e escrita em vários n´so

para aumentar a eficiência. (ICC, 2004).

• SMB (Server Message Block): é um protocolo de comunicação usado pelo sistema

operacional Windows, da Microsoft, para suporte a compartilhamento de recursos

pela rede. O programa SAMBA incluiu este protocolo para os sistemas operacionais

Linux e Unix (REDHAT, 2004).

24

Figura 10. Estrutura em camadas do NFS

Fonte: GOULART (2002).

Para Pitanga (2004c), o NFS possui um acesso mais rápido nos arquivos pequenos do que o

PVFS. Já o PVFS possui o acesso mais rápido aos arquivos grandes, devido ao fato de que ele

divide os arquivos em várias partes entre os nós do cluster.

2.3. PROGRAMAÇÃO PARALELA

A programação paralela tem como objetivo reduzir o tempo de processamento,

transformando grandes algoritmos complexos em pequenas tarefas que possam ser executadas

simultaneamente por vários processadores (PITANGA, 2004c).

Escrever programas para sistemas distribuídos e paralelos é um pouco diferente do que

escrever programas seqüenciais. Pitanga (2004c), cita em seu livro os seguintes obstáculos para a

criação de programas distribuídos e paralelos:

• a memória é distribuída;

• os acessos aos dados devem estar sincronizados para evitar condições críticas;

• os programas paralelos devem ser escritos cuidadosamente para a obtenção de

desempenho aceitável;

25

• o programador deve aprender a utilizar técnicas de construções de algoritmos

paralelos;

• deve se ter um balanceamento adequado das tarefas no cluster e;

• o programa de aplicação fica mais complexo devido a distribuição do dados e das

funções.

Segundo Souza (2001 apud Rauber, 2003), é comum a utilização de bibliotecas de

programação que contenham rotinas de comunicação através de troca de mensagem, como por

exemplo, o MPI e o PVM, para o desenvolvimento de programas paralelos que executem em

sistemas distribuídos.

2.3.1. PVM

Segundo Sterling (2002), PVM (Parallel Virtual Machine) é uma integração de ferramentas

e bibliotecas que emulam o propósito geral, a flexibilidade e heterogeneidade da computação

paralela nos computadores interconectados de várias arquiteturas. PVM surgiu através de um

projeto de pesquisa em computação, envolvendo Oak Ridge National Laboratory, a Universidade de

Tenesse e Emory University. O objetivo do sistema de PVM é efetuar computação paralela

utilizando um conjunto de computadores interconectados como um recurso virtualmente único.

O sistema PVM é composto por duas partes. A primeira é um daemon, chamado pvmd3, que

reside em todos os computadores que compõe o cluster, formando uma máquina paralela virtual. A

outra parte do sistema é a biblioteca de rotinas PVM. Essa biblioteca (API) contém um repertorio

completo de funcionalidade das primitivas que são necessárias para cooperação entre tarefas de uma

aplicação, como a de enviar e receber mensagens (STERLING, 2002).

As características mais importantes do PVM são (PVM, 2005):

• Interoperabilidade;

• Abstração completa das máquinas;

• Controle de processos;

• Controle de recursos;

• Tolerância à falhas;

26

• Fácil de instalar e usar;

• Software de domínio público;

• Grande aceitação e utilização no mundo; e

• Suporte em várias linguagens, como o Java, Python, Perl, C, C++ e Fortran.

2.3.2. MPI

O MPI (Message Passing Interface) é uma biblioteca com funções para a troca de

mensagens, responsável pela comunicação e sincronização de processos em um cluster paralelo. O

principal objetivo do MPI é disponibilizar uma interface que seja utilizada no desenvolvimento de

programas que utilizem troca de mensagens (MPI-FORUM, 2005).

As funções do MPI são:

• Comunicação ponto-a-ponto;

• Comunicação coletiva;

• Suporte para grupo de processos;

• Suporte para contextos de comunicação;

• Suporte para topologia de processos.

Um padrão foi estabelecido para que muitas das implementações do MPI, sendo proprietária

ou de código livre, sigam o mesmo padrão de funcionamento e uso. Este padrão foi formulado por

um fórum em 1992, e foi chamado de MPI-1. O MPI-1.2 é uma extensão para o padrão MPI-1 e

uma terceira especificação chamada de MPI-2, que adiciona várias extensões à versão 1.2 (MPI-

FORUM, 2005).

Os comandos usados em programas que utilizam a biblioteca MPI podem ser divididos em

dois grupos. O primeiro grupo possui os comandos relacionados a inicialização, identificação e

finalização dos processos. O segundo grupo possui os comandos de comunicação.

As implementações do MPI mais conhecidas são:

• MPI-F: IBM Research;

27

• MPICH: ANL/MSU – Argonne National Laboratory e Mississipi State University;

• UNIFY: Mississipi State University;

• CHIMP: Edinburgh Parallel Computing Center;

• LAM: Ohio Supercomputer Center e;

• MPL: IBM Research

Geralmente, LAM e MPICH usam um protocolo de mensagens curtas e longas para

comunicação. Entretanto, a implementação é completamente diferente (ONG, 2004).

Em LAM, a mensagem curta consiste em um cabeçalho e o dado da mensagem é emitido ao

nó de destino em uma mensagem. E, a mensagem longa é segmentada em pacotes com o primeiro

pacote que consiste um cabeçalho e possivelmente alguns dados da mensagem emitidos para o nó

de destino. Então, o nó de emissão espera um reconhecimento do nó receptor antes de emitir o resto

dos dados. O nó de recepção emite o reconhecimento quando recebimento do combinado é postado

(ONG, 2004).

O MPICH implementa três protocolos para troca de dados. Para mensagens curtas, ele usa

um protocolo ansioso para emitir dados da mensagem ao nó de destino imediatamente, com a

possibilidade de armazenar (buffering) dados no nó de recepção quando o nó de recepção não está

esperando os dados. Para mensagens longas, dois protocolos são implementados - o protocolo

rendezvous e o protocolo get. No protocolo rendezvous, os dados são emitidos somente para o

destinatário quando o nó receptor pede os dados. No protocolo get, os dados são lidos diretamente

pelo receptor (ONG, 2004).

2.3.3. PVM x MPI

Zanatta (1999 apud Rauber, 2003), apresenta algumas diferenças entre PVM e MPI, que são

apresentadas na Tabela 1.

28

Tabela 1: Diferenças entre PVM e MPI

Característica PVM MPI

Portabilidade versus Interoperabilidade

Nível de Interoperabilidade: Os programas permitem interoperabilidade, tornando possível a execuções em arquiteturas distintas sem quaisquer modificações no código fonte.

Nível de Portabilidade: Programas escritos para uma arquitetura podem ser compilados para uma outra arquitetura, executados sem quaisquer modificações.

Abstração: O PVM permite que se veja a rede como uma coleção dinâmica de recursos computacionais (potencialmente heterogêneos), administrados como um computador paralelo único.

Abstração: O MPI. não possui o conceito da máquina virtual paralela, centralizando-se no conceito de message passing.

Controle de Recursos: Bastante dinâmico - permite abstração, devido ao conceito de máquina virtual paralela.

Controle de Recursos: Essencialmente estático – não tem suporte a qualquer nível de abstração.

Controle de Processos: Capacidade de iniciar, interromper e controlar processos, em tempo de execução.

Controle de Processos: Bastante restrito - permite somente o controle de grupos de tarefas.

Máquina Virtual

Topologia: O PVM exige que o programador arranje manualmente tarefas em grupos, segundo a organização desejada.

Topologia: O MPI provê um alto nível de abstração, em termos de topologia.

Tolerância a Falhas

Básico: Existem esquemas básicos de notificação de falha, para alguns casos. Porém, permite flexibilidade de forma que, ainda em certas situações onde não existe resposta de uma máquina, uma aplicação receba resultados das outras.

Rudimentar: As versões iniciais, não incluíam qualquer esquema de tolerância, mas a partir das últimas especificações, esquemas similares ao de PVM são providos.

Segurança e Comunicação

Existente: O daemon que mantém a máquina virtual pode ser usado para criar rótulos únicos de contexto. Processos podem se comunicar com grupos, permitindo recuperação de falhas. As novas versões pretendem fazer uso de communicators, como os do MPI.

Excelente: O conceito de communicators no MPI permite um elevado nível de segurança na comunicação, permitindo diferenciar mensagens de bibliotecas de mensagens de usuários.

Fonte: Adaptado de Zanatta (1999 apud Rauber, 2003).

29

2.3.4. OpenMP

O OpenMP é um modelo portável e escalável que da aos programas paralelos uma memória

compartilhada, através de uma simples e flexível interface para o desenvolvimento de aplicações

paralelas escritos em C/C++ e Fortran (OPENMP, 2004).

Segundo Zacharias (2004), o OpenMP possui a vantagem de ser de fácil utilização , pois as

diretivas são auto gerenciáveis. Por este motivo, este método não possibilita uma grande otimização

do processamento, se comparado com os outros métodos de paralelismo.

2.4. ANÁLISE DE DESEMPENHO

Os parágrafos descritos a seguir são uma síntese das descrições apresentadas pelo autor Jain

(1991) em seu livro.

As três técnicas para análise de desempenho são modelo analítico, simulação e medição.

Existem várias considerações para ajudar a decidir qual técnica usar. Estas considerações estão

listadas na Tabela 2 na ordem de maior para a de menor importância.

Tabela 2. Critérios para a seleção de uma técnica de avaliação Criterion Analytical Modeling Simulation Measurement 1. Stage Any Any Postprototype 2. Time required Small Medium Varies 3. Tools Analysts Computer languages Instrumentation 4. Accuracy Low Moderate Varies 5. Trade-off evaluation Easy Moderate Difficult 6. Cost Small Medium High 7. Saleability Low Medium High Fonte: JAIN (1991)

A escolha da melhor técnica de análise de desempenho depende do estágio o qual o sistema

está. Medição somente é possível se algum outro sistema similar já exista. Se for uma nova

concepção, o modelo analítico e a simulação são as únicas técnicas que podem ser utilizadas.

Para cada estudo de desempenho, um critério de desempenho ou métrica deve ser escolhido.

Uma maneira de preparar o estudo de desempenho é listando os serviços oferecidos pelo sistema.

Para cada requisição de serviço feita existem muitas possibilidades de saídas, como apresentado na

Figura 11. O sistema pode executar um serviço corretamente, incorretamente ou não executar o

serviço.

30

Figura 11. As três possibilidades de saídas para uma requisição de serviço

Fonte: JAIN (1991).

Quando o sistema executa o serviço corretamente (successful service), o desempenho é

medido pelo tempo que o serviço levou para executar, a taxa o qual o serviço executou e os recursos

consumidos enquanto executava o serviço. Estas três métricas são chamadas de tempo de resposta,

produtividade e utilização respectivamente.

Se o sistema executar incorretamente o serviço (error), classificar os erros e determinar a

probabilidade em que ocorre pode ser de grande ajuda para uma análise de desempenho.

Se o sistema não executar um serviço (unavailability), que seja por queda (down), falha

(failed) ou inviabilidade (unavaliable). Como no caso anterior, classificar os modos de falhas e

determinar a probabilidade de cada classe pode ser de enorme ajuda para a análise de desempenho.

As métricas associadas com as três saídas, nomeadas de successful service, error e

unavailability são chamadas de métricas speed, reliabiliy e availability respectivamente.

System

Request for service i

Done

Cannot do

Done correctly

Done incorrectly

Errorj

Time (response time)

Rate (throughput)

Resouce (Utilization)

Probability

Time between errors

Duration of the event

Time between events

Event k

31

As métricas mais utilizadas para a análise de desempenho são:

• Tempo de resposta: é definida pelo tempo entre a requisição de um serviço e a

resposta pelo sistema.

• Throughput: é definido como a taxa (requisição por unidade de tempo) com a qual a

requisição pode ser servida pelo sistema. Para sistemas interativos, o throughput é

medido em requisições por segundo. Para CPUs, o throughput é medido em milhões

de instruções por segundo (MIPS - Millions of Instruction Per Second), ou milhões

de operações pontos flutuantes por segundo (MFLOPS - Millions of Floating Point

Operation Per Second). Para redes, o throughput é medido em pacotes por segundo

(pps - Packets Per Second) ou bits por segundo (bps - Bits Per Second). Para sistema

de processamento de transações, o throughput é medido em transações por segundo

(TPS - Transactions Per Second).

• Utilização: é definido pela a utilização de um recurso e é medido pela fração de

tempo que o recurso está sendo utilizando pelo serviço.

• Confiabilidade: o sistema é usualmente medido pela probabilidade do erro ou pela

média de tempo entre os erros.

• Disponibilidade: o sistema é definido pela fração de tempo em que o sistema está

disponível para a requisição de serviço. O tempo de duração em que o sistema não

está disponível é chamado de downtime.

Para Zelenovsky e Mendonça (2004), uma boa solução para medir o desempenho de uma

máquina paralela é medir o ganho de velocidade (GV), speedup, verificando a relação entre os

tempos gastos para executar uma determinada tarefa em um computador serial e em um computador

paralelo. A expressão a seguir (Equação 1) apresenta o cálculo do GV.

Equação 1

O ganho de velocidade não é a mesma que a quantidade de elementos processados, pois

quando se escreve um programa para rodar em máquinas paralelas, é necessário colocar trechos de

código para sincronizar os diversos nós do cluster e para a troca de informações entre eles. Estes

32

trechos são chamados de custo da paralelização. Dependendo da tarefa a ser executada, pode haver

uma necessidade de sincronização e troca informações tão grandes que venha a inviabilizar o

processamento paralelo. O ideal é que um aumento no número de processadores traga um igual

aumento de desempenho (ZELENOVSKY E MENDONÇA, 2004).

A Figura 12 apresenta 4 casos, onde se calcula o Ganho de Processamento (GP) em função

do número de processadores. A primeira curva mostra o caso ideal, onde há um ganho linear em

função do número de processadores. As curvas abaixo dela mostram que o ganho não acompanha a

quantidade de processadores, ou seja, ao chegar em uma certa quantidade de processadores, não se

obtém um aumento no ganho de velocidade. A última curva apresenta um caso ainda pior, pois

qualquer processador que se adicione além do vigésimo quinto só atrasará o processamento.

Figura 12. Influência do custo de paralelização

Fonte: ZELENOVSKY e MENDONÇA (2004).

2.4.1. Lei de Amdhal

Segundo Zelenovsky e Mendonça (2004), existem tarefas que são eminentemente

seqüenciais e que não tiram proveito de um computador paralelo. Assim, é comum que as tarefas a

serem executadas possuam porções paralelizáveis e porções que precisam ser executadas de forma

seqüencial.

Abordando esse tema, Amdahl propôs uma expressão para esse problema, que ficou

conhecida como a Lei de Amdahl Esta expressão está representada na Equação 2, onde T é o tempo

para que uma tarefa execute em uma máquina seqüencial, o p representa as partes que são

obrigatoriamente executadas de forma seqüencial, pT representa tempo gasto com a execução serial,

33

(1-p) representa a porção paralelizável e o N é a quantidade de nós no cluster (ZELENOVSKY e

MENDONÇA, 2004).

NTppT )1( −+

Equação 2

Somente o trecho paralelizável tira proveito dos N processadores, sendo assim, o Ganho de

Processamento é dado pela expressão da Equação 3.

NPp

GP)1(

1−

+=

Equação 3

2.4.2. Ferramentas de Análise de Desempenho e de Gerenciamento

Segundo Rose e Navaux (2003), alguns pensam que a forma mais adequada para medir o

desempenho de uma máquina paralela é medir o número de instruções executadas num determinado

intervalo de tempo. Para medir a velocidade das máquinas paralelas, foi estabelecida uma unidade,

chamada FLOPS (Floating Point Operations Per Second), que mede o número de operações em

ponto flutuantes executadas por segundo.

Essa medida não é muito precisa, pois o poder das instruções varia de máquina para

máquina. Portanto a forma mais correta de medir o desempenho entre máquinas é empregar

programas padrão que são rodados nas máquinas em comparação, essa técnica é chamada de

benchmark (ROSE e NAVAUX, 2003).

ICH (2004), define benchmark como uma medida (um padrão) que serve como ponto de

referencia para medir a performance de um sistema computacional.

Segundo Jain (1991), os benchmark são compostos por uma serie de testes ordenados a fim

de se obter um resultado pré-arranjado não disponíveis em sistemas concorrentes.

Os benchmarks podem ser classificados de acordo com a classe de aplicação para o qual são

voltados como, por exemplo, para computação cientifica, serviços de rede, etc. Também podem ser

divididos em macrobenchmarks, que medem o desempenho de um sistema como um todo, e

34

microbenchmarks, que medem aspectos específicos de um sistema, como o desempenho do

processador, da memória, da E/S, e do sistema operacional (ROSE e NAVAUX, 2003).

Existem ferramentas benchmarks ao nível de software e ferramentas benchmarks ao nível de

hardware. A seguir são listadas algumas delas:

• LINPACK (Linear Algebra Software Package): criada no ínicio dos anos 80 por Jack

Dongarra, é um conjunto de rotinas em Fortran usadas como benchmark para

supercomputadores. O LINPACK analisa e resolve sistemas de equações lineares e

problemas de mínimos quadrados. A biblioteca LINPACK possui quatro fatorações

matriciais: fatoração LU, fatoração de Cholesky, fatoração QR e decomposição

singular de valores. Ela usa algoritmos orientados a array como colunas para

aumentar a eficiência, preservando a localidade (LAPACK, 2004).

Atualmente a implementação portável do benchmark LINPACK se chama High

Performance LINPACK (HPL). Ela é a principal ferramenta de avaliação de performance em

supercomputadores na lista da Top500, que lista os 500 computadores mais rápidos do planeta

(TOP500, 2004).

• LAPACK (Linear Algebra Package): é uma biblioteca em Fortran 77 para Álgebra

Linear constituída de rotinas para resolução de sistemas de equações lineares,

problemas de mínimos quadrados, de autovalores e autovetores. O LAPACK utiliza

as rotinas do EISPACK e LINPACK de forma eficiente em computadores vetoriais

ou de memória compartilhada (LAPACK, 2004).

O LAPACK supera o LINPACK e o EISPACK em alguns quesitos, como em velocidade,

precisão, robustez e funcionamento, além de possuir um número maior de rotinas para operações de

Álgebra Linear (LAPACK, 2004).

• ScaLAPACK (Scalable Linear Algebra Package): é uma biblioteca de rotinas de alta

performance para álgebra linear, utilizada em computadores MIMD de forma

distribuída por passagem de mensagem e estações de trabalho que suportam as APIs

MPI e/ou PVM. Essa biblioteca é utilizada por diversas aplicações científicas

(SCALAPACK, 2004).

35

• PARPAC: é um programa de benchmark, desenvolvido pela Fraunhofer ITWM

(Institut Techno – und Wirtschaftsmatematik), que visa solucionar o problema do

complexo do fluxo em base tridimensional utilizando o método de generalização

lattice Boltzmann. A idéia básica é descrever a equação de Navier-Stokes por

simulação simplificada de partículas dinâmicas. Assim, o fenômeno físico do

complexo pode ser explicado por uma maneira natural e elegante. O código é escrito

em C++ usando muitas características de programação orientando a objetos. Este

benchmark é totalmente paralelizável e possui balanceamento de carga com

otimizações de comunicação entre os nodos. Devido a uma completa paralelização,

PARPAC é um código de alta eficiência para grandes e complexas aplicações

(FRAUNHOFER, 2005).

• NETPIPE (Network Protocol Independent Performace Evaluator): é um medidor de

performance de desempenho para uma rede local desenvolvido pela Iowa State

University Research Fundation. Sua independência de protocolo permite

visualização da sobrecarga (overhead) proveniente da camada de protocolo superior

(NETPIPE, 2004).

• LLCBench (Low Level Characterization Benchmark): é um programa muito

utilizado para se medir a performance de operações essenciais em implementações

dos modelos de passagem de mensagens, como MPI e PVM. Ele permite fazer as

seguintes avaliações: (i) largura de banda; (ii) tempo necessário para emitir uma

mensagem e continuar a transmissão; (iii) tempo de ida e volta da mensagem; (iv)

broadcast (LLCBENCH, 2004).

• Netperf (Network Performance): é uma aplicação que mede a performance na

transferência de dados com requisição/resposta para os protocolos TCP/UDP e com

interface de sockets de Berkley (NETPERF, 2004).

Existem alguns programas muito úteis para o gerenciamento. A seguir são mostrados alguns

programas utilizados em clusters que aumentam o grau de gerenciamento dos recursos e da rede:

• ATLAS (Automatically Tuned Linear Algebra Software): é um gerador de código

que cria diferentes modos de ordenação, a fim de construir uma determinada

operação para uma arquitetura específica. Esta ferramenta é um projeto de pesquisa

36

focalizado em aplicar técnicas empíricas para prover portabilidade e desempenho

(ATLAS, 2004).

• NAG (Numerical Algorithms Group): é uma biblioteca que utiliza BLACS e rotinas

de MPI para cálculos de Álgebra Linear, equações diferencias parciais, funções

estatísticas e operações padrões de matemática (NAG, 2004).

• FFTW (Fast Fourier Transform): desenvolvido por pesquisadores do MIT (Matteo

Frigo e Steven G. Jonhson) é um conjunto de bibliotecas escrito em linguagem C

para computação de transformadas discretas de Fourier (DFT), em uma ou mais

dimensões de dados complexos e reais, e de tamanho de entrada arbitrários (FFTW,

2004).

• bWatch (Beowulf Watch): é um script escrito na linguagem interpretada gráfica tcl

(Tool Command Language) que monitora todos os nós do cluster, ou, basicamente a

carga do sistema nos nós, assim como o uso da memória, usuários (FERREIRA,

2003).

• SCMS (Smile Cluster Management System): é uma ferramenta gráfica de

gerenciamento de cluster baseados no Beowulf. Ela foi desenvolvida pela

Universidade Kasestat da Tailândia. Este aplicativo compõe uma série de

ferramentas e sistemas de suporte, que auxilia o administrador de cluster

(FERREIRA, 2003). Suas principais características são:

1. Monitoramento em tempo real: um subsistema que monitora cada atividade

do nó periodicamente, utilizando RMI (Resource Management Interface)

para coletar as informações;

2. Serviço de alarme do sistema: este serviço monitora alguns parâmetros do

sistema como CPU, memória, E/S e notifica o usuário quando da ocorrência

de alguma falha ou problema.

3. Comandos UNIX paralelos: provê recursos para execução de comandos

remotos nos equipamentos que compõe o cluster;

4. Ferramentas adicionais: painel de controle para o acesso aos nós, acesso via

FTP, Telnet aos nós, informações sobre espaço em disco nos nós, desligar ou

reiniciar um nó, gerenciamento de pacotes através do RPM, entre outros;

37

5. CMA (Control and Monitoring Agent): Agente de monitoramento e controle.

Esse software pega as informações nos nós;

6. SMA (System Management Agent): Agente de monitoramento do sistema.

Esse software é responsável pela coleta das informações enviadas pelo CMA.

7. RMI (Resource Management Interface): Interface de gerenciamento de

recursos. Biblioteca que provê o funcionamento do SMA;

• OpenPBS (Open Portable Batch System): é um subsistema em rede para submeter,

monitorar e controlar a carga de processamento de jobs em um sistema distribuído

heterogênio, desenvolvido pela Veridian System para a NASA. O OpenPBS faz um

planejamento de execução de acordo com uma política predefinida pelo

administrador e com os recursos disponíveis no sistema (OPENPBS, 2004).

2.5. TRABALHOS RELACIONADOS

O ClusterKnoppix é uma versão customizada do Knoppix que vem com um servidor

OpenMosix. Ele roda direto do CD-ROM, como no Knoppix original. Esta distribuição ainda

possibilita os demais PCs darem o boot via rede. A página do ClusterKnoppix

é:http://bofh.be/clusterknoppix/ (MORIMOTO, 2004).

O Dynebolic GNU/Linux também é uma distribuição que inclui o servidor

openMosix para montar um clusters. O Dynebolic é um sistema de código aberto e traz uma série

de aplicações voltadas para a área de multimídia: programas para editar

som, imagens estáticas e vídeo (MACHADO, 2004).

OSCAR (Open Source Cluster Application Resources) é um método para construir,

programar, e utilizar um cluster. Ele consiste de um caminho completo e fácil para instalar um

pacote de software designado para alta performance (OSCAR, 2004).

Outro kit de ferramentas de implementação de cluster é o Warewulf , que facilita o processo

de instalação do cluster e a sua administração. Ele faz com que todos os arquivos de sistema dos

nós escravos serem gerenciados de um único ponto, e automatiza a distribuição dos arquivos de

sistema durante o boot. Ele permite um modelo central de administração para todos os nós escravos

e inclui ferramentas necessárias para construir arquivos de configuração, monitoramento, e controle

38

dos nós. Ele é totalmente personalizável e pode ser adaptado para qualquer tipo de cluster

(WAREWULF, 2004).

Similar a ferramenta OSCAR e o Warewulf, o OpenSCE (Open Scalable Cluster

Environment) é um sistema de código aberto que cria um escalar e extensivo para um ambiente de

cluster. O OpenSCE consiste em várias ferramentas integradas que interagem umas com as outras.

As ferramentas são (OPENSCE, 2004):

• SCMS (Scalable Cluster Management System): Ferramenta de monitoramento e de

gerenciamento;

• SCMSWeb: Ferramenta de monitoramento e de gerenciamento via Web;

• SQMS (Simple Queuing Management System): Sistema de gerencia de filas do

sistema;

• KSIX (Kasetsart System Interconnected eXecutive): camada middleware do

OpenSCE

• MPITH (MPI Thin and High-Performance): Implementação leve do MPI.

3. PROJETO

Neste capítulo é apresentada a modelagem realizada do sistema, a metodologia adotada, o

desenvolvimento, as dificuldades encontradas, o funcionamento e os resultados obtidos do projeto.

3.1. MODELAGEM

Para a modelagem UML foi utilizada a ferramenta Enterprise Architect Trial v4.10.739. A

modelagem foi realizada utilizando o diagrama de caso de uso, seqüência, classe, estado e diagrama

de componente, focalizando o ambiente de programação paralela MPI.

O diagrama de Classe, apresentado na Figura 13, representa as classes que compõe o cluster.

40

Figura 13. Diagrama de Classe do cluster

No diagrama de caso de uso, o ator, chamado de usuário, é o utilizador do cluster para

realizar programas paralelos. A seguir são apresentados Caso de Uso da inicialização dos nodos no

sistema e da criação de um programa paralelo.

A Figura 14 mostra o caso de uso da inicialização do nó no sistema. O cenário principal do

processo “Boot do sistema” é realizado pelos passos descritos abaixo:

1. A BIOS do nodo inicializa o dispositivo de boot (CD-ROM);

2. O dispositivo do nodo lê a mídia e carrega o boot loader na memória;

3. O boot loader carrega o kernel da mídia;

41

4. O boot loader passa o controle para o kernel.

5. O kernel inicializa as entradas do sistema;

6. O kernel monta o diretório raiz (/);

7. O kernel executa os scripts de inicialização (sysinit);

8. O kernel aloca um espaço na memória

9. O kernel mapeia o espaço alocado na memória em /ramdisk

10. O kernel monta o /proc

11. O kernel monta o /home em /ramdisk;

12. O kernel carrega o /home/kurumin da mídia;

13. O kernel monta o swap;

14. O kernel inicializa o dispositivo de rede;

15. O dispositivo de rede faz uma requisição DHCP

16. O kernel configura a rede com o IP recebido via DHCP;

17. O kernel inicializa o runlevel 5.

Figura 14. Diagrama de Caso de Uso da inicialização do sistema

O caso de uso criação de programas paralelos (Figura 15), apresenta os quatro processos

apresentados na seqüência. Para executar os processos “Escreve programa”, “Compila programa” e

“Executa programa” o usuário deve estar autenticado no sistema, o processo que se encarrega dessa

autenticação é o processo “Efetua login no sistema”.

O processo “Escreve programa” tem o cenário principal definido como:

1. O usuário abre um editor de texto no nó mestre;

42

2. O usuário digita o código fonte do sistema;

3. O usuário salva o código fonte em seu diretório (homedir);

No passo 1 do cenário apresentado acima, se o usuário já possuir o código fonte, o cenário

alternativo foi definido como:

1. Transfere o arquivo com o código fonte para o nó mestre (via FTP, SSH, PenDrive

USB);

2. Volta ao passo 3 do cenário principal;

O processo “Compila programa” tem como cenário principal o seguinte:

1. O usuário utiliza o compilador disponível para compilar o programa;

2. O compilador verifica sintaticamente e semanticamente o código fonte;

3. Se a sintática e a semântica estiverem corretas o compilador gera o arquivo binário,

salvando no homedir do usuário.

Como no processo “Escreve programa”, se o usuário já possuir o código binário do

programa ele passará pelo cenário alternativo abaixo:

1. O usuário transfere (via FTP, SSH, ou PenDrive USB) o arquivo para o nó mestre;

2. Volta ao passo 2 do fluxo normal.

No processo “Executa programa”, o cenário principal foi descrito como apresentado a

seguir:

1. O usuário inicia o programa executável;

2. O nó mestre distribuí o programa entre os nós escravos;

3. Os nós escravos executam o programa;

4. Os nós enviam ao nó mestre o resultado da execução;

5. O nó mestre apresenta o resultado final.

43

ud Criacao programa paralelo10 Unregistered Trial Version EA 4.10 Unregistered Trial Version E

10 Unregistered Trial Version EA 4.10 Unregistered Trial Version E









Usuário

Escrev e programa

Compila programa

Executa programa

Efetua login no sistema«include»

«include»

«include»

«use»

«use»

«use»

Figura 15. Diagrama de Caso de Uso da criação de um programa paralelo

Maiores detalhes sobre os Casos de Uso podem ser visto no Apêndice A, onde está o

relatório completo gerado pela ferramenta case.

No diagrama de Estado foi modelada a execução de um programa no nó-escravo e no nó

mestre. Estes diagramas podem ser vistos pela Figura 16 e Figura 17 respectivamente.

sm Diagrama de Estado - Nó Escrav oEA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr

EA 4 10 Unregistered Trial Version EA 4 10 Unregistered Trial Version EA 4 10 Unr

Inicio

Recebe um trecho de código

Executa o trecho de código

Env ia o resultado da execucao para o

nó mestreFinal

Figura 16. Diagrama de Estado da execução de um programa paralelo no nó escravo

44

Figura 17. Diagrama de Estado da execução de um programa paralelo no nó mestre

O diagrama de seqüência foi dividido em dois diagramas. No primeiro (Figura 18) foi

modelado a inicialização de um nó no sistema. No segundo diagrama (Figura 19) foi modelado a

entrada do nó mestre e dos nós escravos no cluster e a execução de um programa paralelo.

45

Figura 18. Diagrama de Seqüência da inicialização de um nó

46

Figura 19. Diagrama de Seqüência da entrada dos nodos e a execução de um programa paralelo

No diagrama de componente, Figura 20, foi realizada a modelagem dos componentes do

cluster e suas interligações.

47

id Componente

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.


















Node

SSI

Rede

Recursos

Sistema Operacional

Sistema de arquiv o paralelo Ferramenta de comunicação

Protocolo

Programa paralelo

Placa de redeMemória Processador

Switch

0..*

1..*

Figura 20. Diagrama de Componentes do cluster

3.2. DESENVOLVIMENTO

Para o desenvolvimento deste trabalho foi adotada a distribuição Linux Kurumin (versão

3.31), por ela possuir um sistema LIVE-CD, ou seja, o sistema roda somente utilizando o CD-

ROM. Desta forma não é necessária a instalação do sistema operacional no HD (Hard Disk),

preservando a configuração existente no equipamento. Esta distribuição tem ampla compatibilidade

com diferentes hardwares, e ainda é um sistema operacional configurado por brasileiros.

3.2.1. Apresentação do Sistema

O cluster desenvolvido foi batizado pelos autores deste trabalho de KCluster (Kurumin

Cluster). Ele foi desenvolvido a partir de uma remasterização do Kurumin, incluindo novos pacotes.

Esta remasterização foi documentada e está no Apêndice B. Todas as propriedades do Kurumin

foram mantidas, como detecção de hardware, KDE como interface gráfica padrão e os ícones

mágicos.

Utilizando a mesma idéia dos ícones mágicos, foram criados alguns scripts para automatizar

as configurações do cluster. Eles estão localizados no diretório /usr/bin. Os scripts podem ser

executados ou pela linha de comando ou pelos ícones localizados no desktop.

Para a utilização do cluster foi criado um usuário chamado mpiuser com a senha “cluster”.

O home do usuário está localizado em /var/home/mpiuser. Este usuário possui todas as variáveis de

ambiente necessárias para a inicialização do ambiente paralelo MPI e para a execução de programas

paralelos em MPI.

Na remasterização a senha do usuário kurumin e a do superusuário (root) foram trocadas

pela senha “cluster”, a mesma que a do usuário mpiuser.

Para colocar em funcionamento o cluster, vários passos são necessários. O primeiro passo é

iniciar o nó mestre do cluster, utilizando a mídia do Kcluster (Figura 21). O motivo do nó mestre

ser a primeira máquina a ser iniciada é que ela poderá ser o servidor de DHCP da rede, que

obrigatoriamente deverá estar ativo antes do boot dos outros nodos, para que eles adquiram um IP e

ingressem na mesma rede.

49

Figura 21. Tela de boot do Kcluster

O script que configura o nó mestre como servidor DHCP altera o IP para 10.1.1.3 e

disponibiliza a faixa de IPs de 10.1.1.100 a 10.1.1.200 para as requisições DHCP. O comando para

iniciá-lo é “kcluster_start_dhcp.sh” ou pelo ícone “Servidor DHCP” no desktop.

Caso a rede já possuir um servidor DHCP, não faz diferença na ordem que são iniciadas as

máquinas, já que todas possuem o mesmo sistema operacional e as mesmas configurações, mas o

script que configura uma máquina como nó mestre deve ser iniciado antes que os scripts dos nós

escravos.

O script do nó mestre libera a conexão do diretório /mpi via NFS e cria o arquivo “lamhost”,

onde ficarão todos os IPs dos nodos do cluster, inclusive o seu IP. No final do script é apresentado

o IP do servidor, que servirá para configurar os nós escravos. O script pode ser executado com o

comando “kcluster_start_server.sh” ou pelo ícone “Nó mestre” no desktop.

O próximo passo é iniciar os nós escravos e executar o script “kcluster_start_client.sh”, ou o

ícone “Nó escravo” no desktop. O script pedirá para informar o IP do nó mestre para mapear o /mpi

via NFS e inclui seu IP no arquivo lamhost.

50

Com todos os nodos prontos já é possível iniciar o ambiente paralelo MPI. Tanto para iniciar

o ambiente paralelo como para rodar os programas paralelos é necessário utilizar o usuário mpiuser

no nó mestre. O comando “lamboot –v /mpi/lamhost” inicia o ambiente MPI.

O MPI utiliza a troca de mensagens entre os nodos pelo SSH. Na primeira vez em que é feita

uma requisição SSH para algum nodo, uma chave criptografada é salva na máquina. Para esta chave

ser salva é apresentada uma mensagem para o usuário, que deve ser aceita (respondendo “yes”).

Este processo pode ser feito na primeira vez que é executado o comando lamboot, ou executando o

script chamado kcluster_test_ssh.sh. O scritpt kcluster_test_ssh.sh detecta se o serviço SSH está

funcionando nos nós do cluster fazendo uma conexão SSH para cada nó relacionado no arquivo

/mpi/lamboot. Este script também pode ser executado pelo ícone “Testar Serviço SSH” no desktop.

Com o cluster em funcionamento, os programas paralelos já podem ser executados. Existem

alguns programas de exemplo disponíveis em /var/home/mpi/exemplos. Também é possível criar

novos programas utilizando um editor de texto, como o vi (modo texto) ou o kedit (modo gráfico).

Como alternativa é possível copiar um programa já escrito através de FTP, SSH ou utilizando um

PenDrive USB.

Para facilitar a cópia dos arquivos para o cluster e para salvar os resultados após uma

execução de um programa paralelo, um script foi criado para automatizar a montagem do PenDrive

USB. O script “kcluster_mount_usb.sh” monta o dispositivo em /mnt/usb. Para remover o

dispositivo é importante desmontá-lo primeiro para garantir que todos os dados foram realmente

salvos. O comando para desmontar é “kcluster_umount /mnt/usb”. A montagem e desmontagem do

PenDrive USB também pode ser executada pelo ícones “Montar Storage USB” e “Desmontar

Storage USB” localizado no desktop.

Para compilar o programa podem ser usados os comandos mpicc para a linguagem C,

mpiCC ou mpic++ para a linguagem C++ e mpif77 para a linguagem Fortran. Um exemplo da

sintaxe do comando para compilar um programa escrito em c é: mpicc –o <programa_binario>

<programa_codigo_fonte.c>

Após compilar o programa, o binário do programa deve ser disponibilizado na mesma área

para todos os nodos do cluster. Devido às dificuldades encontradas para realizar esta operação com

o NFS, foi contornada a situação criando um script (kcluster_cp2cluster) que copia o binário para o

51

/ramdisk de todos os nodos. A sintaxe do comando para fazer está cópia é: kcluster_cp2cluster

<programa_binário>

Um programa paralelo deve ser executado no cluster com o usuário mpiuser pelo comando:

mpirun –np <numero_de_processos> <programa_binario>. Os resultados e os programas escritos

em MPI podem ser salvos da mesma forma feita para copiar os programas paralelos para o cluster.

Para rodar outros programas paralelos é recomendado utilizar o comando “lamclean” antes

para limpar as variáveis do ambiente MPI. Para encerrar o ambiente MPI pode ser utilizado o

comando “lamhalt -v”, ou “wipe /mpi/lamhost” para forçar a finalização.

No final das execuções, para desligar todo o sistema, ao invés de entrar máquina por

máquina e desligá-las, o comando “shutdown_cluster.sh” pode ser executado para desligar todas as

máquinas de uma só vez.

3.2.2. Dificuldades Encontradas

No decorrer do desenvolvimento do sistema foram encontradas várias dificuldades. Algumas

facilmente contornadas, mas para outras a solução adotada alterou a forma original prevista para o

funcionamento do cluster. Os problemas encontrados estão relacionados a seguir.

3.2.2.1. Boot por Disquete

Por motivos técnicos, a idéia original de boot dos nodos pelo disquete e a utilização do

sistema de arquivo localizando no nó mestre foi mudada para o boot via CD-ROM e utilizando o

sistema de arquivo local. O maior problema encontrado foi na troca do sistema root do disquete

para o root compartilhado no servidor pelo NFS.

Com a utilização do CD-ROM foi possível incluir todo o sistema necessário para rodar o

ambiente do cluster, como os serviços de DHCP, MPI e NFS. Com esse novo modelo obteve-se as

seguintes vantagens:

• Tráfego de rede: como o sistema está todo localmente no CD-ROM, não haverá

tráfego de rede para obtenção dos arquivos de sistema e de configurações; e

• Confiabilidade do CD: um CD possui uma durabilidade e confiabilidade muito maior

que os tradicionais disquetes.

52

Hoje os CD-Rs são facilmente encontrados por um preço bem mais acessível e, se comprado

em quantidade, o valor de cada CD-R pode chegar ao valor dos tradicionais disquetes. Também

ficou cada vez mais comum encontrar máquinas com unidades de CDs, como é o caso do ambiente

utilizado neste estudo (os laboratórios de ciência da computação da UNIVALI) para os testes e para

a validação. Estes laboratórios são dotados de equipamentos potentes o suficiente para rodar o

sistema e a maioria das máquinas já possuem o driver de CD-ROM.

3.2.2.2. Compartilhamente via NFS

Outro problema encontrado durante a implementação do sistema foi o compartilhamento do

servidor via NFS. Quando várias máquinas se conectavam no servidor, as últimas não conseguiam

conectar, apresentando o erro de “Mount: RPC: timeout”. Para resolver este problema foram

adicionado os parâmetros “rsize=8192,wsize=8192,timeo=14,intr” na conexão NFS no nó escravo.

Com o aumento do tráfego da rede estes parâmetros aumentam o timeout e os buffers de leitura e

gravação.

3.2.2.3. Disponibilização dos programas em MPI

Como o sistema operacional roda inteiramente pelo CD-ROM, não é possível gravar

nenhum arquivo no sistema de arquivo. O Kurumin possui um mecanismo que mapeia uma área da

memória como um sistema de arquivo onde é possível ler e gravar. Este mapeamento é chamado de

ramdisk e se encontra em /ramdisk. Nesta área estão todos os arquivos que são alterados no boot do

sistema e os arquivos do usuário kurumin.

A dificuldade encontrada foi no exportar um diretório do CD via NFS, pois não onde não é

possível gravar nenhum arquivo, impossibilitando a disponibilização dos programas compilados

para todos os nodos. Uma solução seria exportar um diretório dentro do /ramdisk, que está na

memória, mas o NFS não permite exportar tal área. Para contornar esta situação foi criado um

script, chamado de kcluster_cp2cluster, que copia via SSH o programa para a área /ramdisk de

todos os nós listados no arquivo /mpi/lamhost.

3.2.3. Resultados

Com o objetivo de validar o cluster desenvolvido, foram executadas duas aplicações: o

benchmark PARPAC e uma multiplicação de matrizes. As aplicações foram executadas no

laboratório de computação da UNIVALI (Figura 22). As máquinas utilizadas são da fabricante

53

DELL e possuem um processador Pentium IV 2.40 Ghz, 512Mb de memória RAM e placa de rede

10/100 Mbits. A rede deste laboratório opera em 100 Mbits, mas também foi utilizado um HUB de

10 Mbits para os testes.

O benchmark PARPAC (descrito na seção 2.4.2) foi escolhido por este ser de interesse e

estar mais relacionado com outros projetos de pesquisa do laboratório de pesquisa LSED na

UNIVALI, e trata da simulação de fluídos através de técnicas de lattice Boltzmann.

O programa PARPAC foi disponibilizando dentro da pasta /var/home/mpiuser/exemplos/

parpac_ipacs-1.0. Para executar este programa, o comando “mpirun –v –np <numero_de_nodos>

PARPACBench” deve ser utilizado com o usuário mpiuser, trocando <numero_de_nodos> pelo

número de nodos que o cluster possui. A Figura 23 apresenta a execução do benchmarch PARPAC

no Kcluster.

Figura 22. Execução do KCluster no laboratório de ciência da computação da UNIVALI

54

Figura 23. Execução do benchmarck PARPAC

O PARPAC gera três arquivos de resultado e são salvos em /var/home/mpiuser/

exemplos/parpac_ipacs-1.0/results, que está apontado para /ramdisk. Os arquivos são:

parpacbench_xcpu_10lbu.out, performance_10lbu.dat, permeability.dat. Um exemplo destes

arquivos está no Apêndice C.

O arquivo permeability.dat possui a permeabilidade final da simulação. O arquivo

performance_10lbu.dat contém dois números: um é o número de processos utilizados na execução

e o outro é o desempenho em GFlops (Gigaflops ou Billions of Floating Point Operation Per

Second). Se uma nova execução ocorrer, o PARPAC adiciona os novos resultados a este arquivo,

mantendo assim um histórico das execuções.

O arquivo parpacbench_Xcpu_10lbu.out, onde X é o número de processos executados, é o

arquivo que contém maiores informações sobre a sua execução. Ele possui a descrição do

benchmark, informações do sistema, parâmetros do fluido, parâmetros do benchmark e os

resultados do benchmark.

A execução do PARPAC foi realizada utilizando 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 e 13

máquinas com a rede a 100 Mbits. Os resultados estão apresentados pela Tabela 3, onde lista o total

55

de pontos por grade, total de pontos no fluídos, a porosidade do material, a permeabilidade do

material, o tempo de simulação, a taxa de cálculos de pontos no fluído na grade, e o desempenho

alcançado. A Figura 24 apresenta o gráfico do desempenho alcançado por número de máquinas no

cluster. Como os parâmetros usados em cada execução no PARPAC variam conforme o número de

nodos no cluster, desta forma não é possível calcular o speedup, pois a carga de trabalho não é

constante.

Tabela 3. Resultados do PARPAC

Nodos Total de pontos

da grade

Total de

pontos do

fluído

Porosidade do

material

Permeabilidade calculada do

material

Tempo total de

simulação

Taxa de cálculo de pontos na grade do

fluído

Desempenho (GFlops)

1 343000 300125 8,750E-01 1,992E-07 296,80 0,506 0,3018 2 729000 654912 8,984E-01 3,222E-07 674,36 0,486 0,2899 3 1000000 882351 8,824E-01 2,234E-07 743,05 0,594 0,3545 4 1331000 1173536 8,817E-01 2,049E-07 600,44 0,977 0,5834 5 1728000 1542807 8,928E-01 2,258E-07 927,37 0,832 0,4966 6 2197000 1946953 8,862E-01 2,454E-07 1012,98 0,961 0,5737 7 2197000 1946953 8,862E-01 2,454E-07 805,52 1,209 0,7215 8 2744000 2401000 8,750E-01 1,992E-07 720,26 1,667 0,9951 9 3375000 2985983 8,847E-01 2,089E-07 1164,36 1,282 0,7655

10 3375000 2985983 8,847E-01 2,089E-07 1093,85 1,365 0,8149 11 4096000 3639467 8,885E-01 2,671E-07 1128,45 1,613 0,9628 12 4096000 3639467 8,885E-01 2,671E-07 1070,36 1,700 1,0150 13 4096000 3639467 8,885E-01 2,671E-07 1037,94 1,753 1,0470

56

PARPAC

0,0000

0,2000

0,4000

0,6000

0,8000

1,0000

1,2000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

GFl

ops

Desempenho

Figura 24. Desempenho alcançado em Gflops

O PARPAC também foi executado utilizando 1, 2 e 3 máquinas numa rede de 10 Mbits. Os

resultados foram comparados com os resultados da execução na rede operando a 100 Mbits. A

Tabela 4 apresenta estes números, comparando o tempo total de simulação e o desempenho

alcançado. A Figura 25 e a Figura 26 apresentam os gráficos de tempo total de execução e o

desempenho alcançado, respectivamente. O comparativo de execução utilizando um nodo com a

rede de 10 Mbits e de 100 Mbits estão apresentados somente como referência, já que não há

utilização da rede. Com estes resultados pode se observar claramente o impacto da rede na execução

do PARPAC.

Tabela 4. Comparativo entre a execução do PARPAC com a rede a 10 Mbits e 100 Mbits

Nodos Tempo total (s) (10 Mbits)

Tempo total (s) (100 Mbits)

Desempenho (Gflops) (10 Mbits)

Desempenho (Gflops) (100 Mbits)

1 296,80 296,80 0,3018 0,30182 2090,48 674,36 0,0935 0,28993 5270,44 743,05 0,0499 0,3545

57

PARPAC

0

1000

2000

3000

4000

5000

6000

1 2 3Nodos

Segu

ndos

Tempo total (10 Mbits)Tempo total (100 Mbits)

Figura 25. Tempo total de execução do PARPAC com rede de 10 e 100 Mbits

PARPAC

0,00000,05000,10000,15000,20000,25000,30000,35000,4000

1 2 3Nodos

GFl

ops

Desempenho (10 Mbits)Desempenho (100 Mbits)

Figura 26. Comparativo do desempenho alcançado entre uma rede 10 e 100 Mbits

Outro teste realizado com o cluster desenvolvido foi a de multiplicação de matrizes. Neste

teste foi calculado uma matriz quadrada de 3000 linhas. Para fim de teste, os dados populados

58

foram de 2 na matriz A e de 3 na matriz B. O tempo de execução está relacionado na Tabela 5 e

apresentado graficamente na Figura 27.

Tabela 5. Resultados da multiplicação de matrizes.

Nodos Segundos Minutos 1 1832,474 30,5412 976,178 16,2703 621,897 10,3654 555,209 9,2535 384,528 6,4096 387,309 6,4557 322,782 5,3808 271,825 4,5309 247,584 4,126

10 272,989 4,55011 327,897 5,46512 292,801 4,88013 276,504 4,608

Multiplicação de Matrizes

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

Segu

ndos

Tempo de execução

Figura 27. Resultados da multiplicação de matrizes.

Com os resultados obtidos na multiplicação de matrizes também foi calculado o speedup do

cluster, apresentados a seguir na Tabela 6. No gráfico da Figura 28 é apresentado o speedup onde

pode ser notado o aumento de desempenho e a queda após a inclusão do nono nodo no cluster.

59

Tabela 6. Speedup do cluster na multiplicação de matrizes.

Nodos Speedup 1 1,0002 1,8773 2,9474 3,3015 4,7666 4,7317 5,6778 6,7419 7,401

10 6,71311 5,58912 6,25813 6,627


0,0001,0002,0003,0004,0005,0006,0007,0008,000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

Spee

dup

Speedup

Figura 28. Speedup do cluster com a multiplicação de matrizes

60

4. CONCLUSÕES

Este trabalho se propôs a construir disponibilizar um ambiente para processamento paralelo

escalável e de fácil inclusão e configuração, baseado em um cluster de PCs.

Foram encontradas diversas dificuldades durante a fase de desenvolvimento do cluster,

algumas facilmente contornadas e outras, as quais, mudaram a proposta inicial modelada, que era da

utilização de disquetes para inicializar dos nós escravos. Mesmo com estas alterações o objetivo

deste projeto foi alcançado.

A solução adotada com o Linux Kurumim permitiu mobilidade e portabilidade ao cluster,

preservando a integridade do ambiente existente.

Com a validação do cluster no laboratório de Ciência da Computação da UNIVALI pode se

observar o ganho de desempenho (speedup) e o impacto da rede no cluster utilizando o benchmarck

PARPAC, após uma série de tomadas de tempo durante as execuções. Rodando a aplicação de

multiplicação de matrizes, pode se observar o aumento do desempenho com a inclusão gradativa

das máquinas no cluster e a queda no desempenho após a inclusão de um determinado número de

máquinas.

Com o custo dos microcomputadores e dos equipamentos de rede cada vez menores e a

facilidade de comunicação entre máquinas, junto com a utilização do software livre foi possível

criar um cluster de baixo custo.

Para trabalhos futuros, sugere-se que seja montada uma forma de coleta de uso de cada nó

do cluster. Uma ferramenta que serve para este fim seria o CACTI (Figura 29). Esta ferramenta

coleta as informações de CPU, memória, disco e da rede através do protocolo SNMP e armazena

num banco de dados para futuras apresentações em gráficos por uma página web. Ela também

permite a criação de novos scripts para a coleta de informações personalizadas (CACTI, 2005).

61

Figura 29. Exemplo de gráficos gerados pela ferramenta CACTI

Fonte: CACTI (2005).

O cluster desenvolvido já tem configurado o serviço de SNMP, sendo necessário somente

uma ferramenta que colete estes dados durante a execução de uma aplicação que processe por um

longo período de tempo.

Também para trabalhos futuros, sugere-se a inclusão de ferramentas de depuração, como o

XMPI, e ferramentas de programação paralela, como o PVM. Os benchmark LINPACK e o

LAPACK também poderiam ser incluídos para trabalhos futuros em cima de análise de desempenho

deste cluster.

Um resumo deste trabalho, Anexo I, foi publicado nos anais do XIX Congresso Regional de

Iniciação Científica e Tecnológica em Engenharia (CRICTE), evento ocorrido nos dias 13, 14 e 15

de novembro de 2004.

REFERÊNCIAS BIBLIOGRÁFICAS

ATLAS. Automatically Tuned Linear Algebra Software (ATLAS). Documento disponível on-line na URL: <http://math-atlas.sourceforge.net/> Acessado em novembro, 2004.

BARCELLOS, M. P.; GASPARY, L. P. Tecnologias de Rede para Processamento de Alto Desempenho. ERADE 2002. São Leopoldo, RS. Editora Sagra Luzzatto. Jan. 2002.

BUENO, A. D. Introdução ao processamento paralelo e ao uso de cluster de workstations em sistemas GNU/LINUX. Parte I: Filosofia. Disponível em: <http://www.rau-tu.unicamp.br/nou-rau/softwarelivre/document/?view=83>. Acesso em maio 2004.

BUYYA, R. High Performance Cluster Computing: Architecture and Systems, vol 1. pags 3-45, New Jersey: Prentice Hall, 1999.

CACTI. Cacti: The Complete RRDTool-based Graphing Solution. Documento disponível on-line na URL: <http://www.cacti.net> Acessado em junho, 2005.

COULOURIS, George.; et al. Distributed System. Concepts and Design. 3ª ed. Addison-Wesley, 2001. 772 p.

FFTW. FFTW. Documento disponível on-line na URL: <http://www.fftw.org/> Acessado em novembro, 2004.

FERREIRA, José Alexandre. Estudo de modelos de agrupamento de computadores para computação de alta performance utilizando clientes leves. 2003. 42 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação). Curso de Graduação em Ciência da Computação, Universidade Federal de Alagoas, Maceió, 2003.

FRAUNHOFER. Institut Techno – und Wirtschaftsmatematik. . Disponível em: <http://www.itwm.fhg.de/en/sks__projects__sks_algorithms__parpac/parpac>. Acesso em maio 2005.

GUALEVE, J. A. F. Arquitetura de Computadores II. Disponível on-line na URL: <http://www.ucb.br/prg/professores/josef/ac3/Aula01-02.ppt>. Acessado em novembro de 2004.

GOULART, Ademir. Avaliação de mecanismos de comunicação em grupo para ambiente WAN. 2002. 169 f. Dissertação (Mestrado) – Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis. 2002.

ICC. Integreted Computing & Communications. Documento disponível on-line na URL: <http://www.llnl.gov/icc/lc/siop/mpiio.html> Acessado em novembro, 2004.

ICH GLOSSARY. Interoperability Clearinghouse Glossary of Terms. Documento disponível on-line na URL: <http://www.ichnet.org/glossary.html> Acessado em outubro, 2004.

JAIN, R. The Art of Computer System Performance Analysis. Techniques for Experimental Design, Measurement, Simulation, and Modeling. 1ª ed. Massachusetts: John Wiley & Sons, Inc. 1991. 685p.

63

LAPACK. Linear Algebra PACKage. Documento disponível on-line na URL: <http://www.netlib.org/lapack/> Acessado em novembro, 2004.

LLCBENCH. LLCbench - Low Level Architectural Characterization Benchmark Suite. Documento disponível on-line na URL: <http://icl.cs.utk.edu/projects/llcbench/> Acessado em novembro, 2004.

NAG. Numerical Algorithms Group. Documento disponível on-line na URL: <http://www.nag.co.uk/numeric/numerical_libraries.asp> Acessado em novembro, 2004.

NETPIPE. NetPIPE: A Network Protocol Independent Performance Evaluator. Documento disponível on-line na URL: <http://www.scl.ameslab.gov/netpipe/paper/full.html> Acessado em novembro, 2004.

NETPERF. Netperf. Documento disponível on-line na URL: <http://www.netperf.org/netperf/NetperfPage.html> Acessado em novembro, 2004.

MACHADO, C; ROBERTI, B. Cluster com linux na mão. Info Exame. a. 19, n. 222, p. 104-106, set. 2004.

MORIMOTO, C. E. Brincando de cluster. Disponível on-line na URL: <http://www.guiadohardware.net/artigos/260/>. Acessado em novembro de 2004.

MPI-FORUM. Message Passing Interface Forum. Disponível on-line na URL: <http://www.mpi-forum.org/>. Acessado em abril de 2005.

ONG, H; FARRELL, P. A. Performance Comparison of LAM/MPI, MPICH, and MVICH on a Linux Cluster connected by a Gigabit Ethernet Network. Documento disponível on-line na URL: <http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_pap ers/ong/ong_html/> Acessado em maio, 2004.

OPENMP. OpenMP Architecture Review Board. Disponível em: <http://www.openmp.org/>. Acesso em novembro 2004.

OPENSCE. OPENSCE. Disponível on-line na URL: <http://www.opensce.org/>. Acessado em novembro de 2004.

OPENPBS. About OpenPBS. Disponível on-line na URL: <http://www.openpbs.org/about.html>. Acessado em novembro de 2004.

OPENMOSIX. The OpenMosix Project.. Disponível on-line na URL: <http:// http://openmosix.sourceforge.net/ >. Acessado em maio de 2005.

OSCAR. Open Source Cluster Application Resources. Disponível on-line na URL: <http://oscar.openclustergroup.org/tiki-index.php>. Acessado em novembro de 2004.

PITANGA, Marcos. Supercomputadores caseiros: construindo cluster com o Linux. Disponível em: <http://www.clubedohardware.com.br/super2.html>. Acessado em: 10 abr. 2004a.

PITANGA, Marcos. Computação em Cluster. Documento disponível on-line na URL: <www.clubedohardware.com.br/cluster.html>. Acessado em maio de 2004b.

64

PITANGA, Marcos. Construindo Supercomputadores em Linux. 2ª ed. Rio de Janeiro: Brasport, 2004c. 316 p.

PIOUS. PIOUS for PVM. Documento disponível on-line na URL: <http://www.mathcs.emory.edu/pious/> Acessado em novembro, 2004.

PVM. Index for PVM3 Library. Disponível em: < http://www.netlib.org/pvm3>. Acesso em abril 2005.

RAUBER, Marcelo. Avaliação de Ferramentas de Gerenciamento de Sistemas Distribuídos. Universidade do Vale do Itajaí – UNIVALI, Itajaí – SC, 2003.

REDHAT. Red Hat Linux 7.0: The Official Red Hat Linux Getting Started Guide. Documento disponível on-line na URL: <http://www.europe.redhat.com/documentation/rhl7/gsg-en/ch-glossary.php3>. Acessado em novembro, 2004.

PATTERSON, D. A.; HENNESSY, J. L. Organização e projeto de computadores. A interface HARDWARE/SOFTWARE. 2 ª ed. Rio de Janeiro, RJ. LTC – Livros Técnicos e Científicos Editora S.A. 2000. 550p.

ROSE, C. A. F.; NAVAUX, P. O. A. Arquiteturas Paralelas. Série Livros Didáticos, n. 15. 1ª ed. Porto Alegre: Instituto de Informática da UFRGS: Sagra Luzzatto. 2003. 152 p.

ROSE, C. A. F.; NAVAUX, P. O. A. Fundamentos de Processamento de Alto desempenho. ERADE 2002. São Leopoldo, RS. Editora Sagra Luzzatto. Jan. 2002.

SCALAPACK. The ScaLAPACK Project. Documento disponível on-line na URL: <http://www.netlib.org/scalapack/> Acessado em novembro, 2004.

STERLING, T. Beowulf Cluster Computing with Linux. The MIT Press, 2002. 496 p.

STERLING, T. et al.. How to Build a Beowulf. Massachusetts: MIT Press, 1999. 261 p.

TANENBAUM, A. S. Sistemas Operacionais Modernos, Rio de Janeiro: Prentice-Hall do Brasil Ltda, 1995.

TOP500. TOP 500. List for November 2003. Disponível on-line na URL: <http://www.top500.org/ list/2003/11/>. Acessado em junho de 2004.

TOSCANI, S. S.; Oliveira, R. S.; Carissimi, A. S. Sistemas Operacionais e Programação Concorrente. Série Livros Didáticos, n. 14. 1ª ed. Porto Alegre: Instituto de Informática da UFRGS: Sagra Luzzatto. 2003. 247 p.

ZACHARIAS, D. C.. Funcionamento de um cluster Linux: Parte II - A revanche. Disponível em: <http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=840/>. Acesso em novembro 2004.

ZELENOVSKY, R.; MENDONÇA A. Processadores para o próximo milênio. Disponível em: < http://www.clubedohardware.com.br/milenio2.html >. Acesso em novembro 2004.

WAREWULF. The Warewulf Cluster Project. The Distributed Linux Distribution. Disponível on-line na URL: <http://warewulf-cluster.org/>. Acessado em outubro de 2004.

ANEXO I – RESUMO PUBLICADO NO CRICTE 2004

CLUSTER DE BAIXO CUSTO

Sidnei Baron, Ademir GoulartUniversidade do Vale do Itajaí – UNIVALI

Curso de Ciência da Computação – CTTMarRua Uruguai, 456 – CEP 88302-202 Itajaí[email protected] , [email protected]

Um cluster (ou agregado) de computadores pode ser definido como um conjunto denós processadores (PCs – Personal Computers – ou estações de trabalho) autônomos e que,interligados, comportam-se como um sistema de imagem única1.

Os clusters são usados quando os conteúdos são críticos ou quando os serviços têmque estar disponíveis e/ou processados o quanto mais rápido possível. Exemplos desses são osInternet Service Providers (provedores de Internet) e sites de comércio eletrônico. Indústriascinematográficas podem se utilizar desses recursos, pois necessitam de alto desempenho pararenderização de gráficos de altíssima qualidade e animações1.

Pesquisadores, organizações e empresas estão utilizando os clusters porque necessitamde desempenho escalável, gerenciamento de recursos, disponibilidade ou processamento emnível supercomputacional a um preço adequado.

A aquisição de máquinas e de redes de alto desempenho é cara. Além do custo dohardware, os custos de instalação e de manutenção também são altos, pois são feitos porprofissionais capacitados e, geralmente, terceirizados.

Grandes organizações e universidades possuem laboratórios que ficam uma boa partedo tempo com processadores ociosos, como muitos laboratórios de ensino, nas universidades,nos finais de semana. Esses ambientes poderiam ser utilizados em horários que não estão sendoutilizados localmente.

Este projeto de pesquisa tem como objetivo geral modelar, montar, instalar, validar edisponibilizar um ambiente para processamento paralelo baseado em umcluster de PCs. O cluster deverá ser escalável e os seus os nodos deverão ser de fácil inclusãoe configuração em ambientes distribuídos onde a configuração manual das máquinas deva serevitada.

Serão realizadas várias etapas para alcançar esse objetivo. A etapa inicial será a deestudo, na qual será realizado um estudo sobre clusters, sobre os passos necessários paramontagem e gerenciamento de um cluster, e sobre programação de sistemas paralelos. Asegunda etapa será a de modelagem, a qual especificará o funcionamento e criará o modeloconceitual do sistema. A terceira etapa será de desenvolvimento, na qual será montado ocluster conforme a etapa anterior (modelagem) e serão disponibilizados alguns programas deteste para que, na etapa seguinte (validação), seja validado todo o cluster.

1 PITANGA, Marcos. Supercomputadores caseiros: construindo cluster com o Linux. Disponível em:<http://www.clubedohardware.com.br/super2.html>. Acessado em: 10 abr. 2004

XIX Congresso Regional de Iniciação Científica e Tecnológica em Engenharia – CRICTE2004 13 a 15 de Novembro de 2004 – Curitiba – Paraná _________________________________________________________________________________________

66

APÊNDICE A – MODELAGEM UML

Views

Componente

67

Figure 1 : Componente

Internal Links Component diagram :: Componente

Package :: Componente.

68

Programa paralelo Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:20:13. Modified on 8/11/2004 21:29:46.


Recursos Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:16:03. Modified on 8/11/2004 21:29:27.

Connections Realize link to component Sistema Operacional Realize link from component Sistema Operacional

Rede Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:15:50. Modified on 8/11/2004 21:30:47.

Connections Realize link to object Placa de Rede Realize link from object Placa de Rede

Node Type: public Node Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:57:33. Modified on 9/11/2004 01:14:28.

Ferramenta de comunicação Type: public Component Status: Proposed. Version 1.0. Phase 1.0.

69

Package: Componente Details: Created on 8/11/2004 21:18:05. Modified on 9/11/2004 01:14:28.

Connections Association link to component Sistema Operacional


Connections Association link to package SSI

Protocolo Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:18:29. Modified on 9/11/2004 01:14:28.

Connections Association link to node Placa de rede Association link from component Sistema Operacional Realize link from object Placa de Rede Realize link to object Placa de Rede

Sistema de arquivo paralelo Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:17:42. Modified on 9/11/2004 01:14:28.


Sistema Operacional Type: public Component

70

Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:16:23. Modified on 9/11/2004 01:14:28.

Connections Association link from node Memória Association link from component Ferramenta de comunicação Association link from component Sistema de arquivo paralelo Association link to component Protocolo Association link from node Processador Realize link from component Recursos Realize link to component Recursos

Memória Type: public Node Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:52:36. Modified on 9/11/2004 01:14:28.


Placa de rede Type: public Node Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:51:58. Modified on 9/11/2004 01:14:28.

Connections Association link from component Protocolo Association link to node Switch

Processador Type: public Node Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:52:52. Modified on 9/11/2004 01:14:28.

71


Switch Type: public Node Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:53:28. Modified on 9/11/2004 01:15:09.

Connections Association link from node Placa de rede

Placa de Rede Type: public Object Status: Proposed. Version 1.0. Phase 1.0. Package: Componente Details: Created on 8/11/2004 21:29:46. Modified on 8/11/2004 21:30:36.

Connections Realize link from component Rede Realize link to component Rede Realize link to component Protocolo Realize link from component Protocolo

72

Diagrama de Classe

Figure 2 : Diagrama de Classe

CD-ROM Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 5/6/2005 11:38:32. Modified on 5/6/2005 11:40:36.

Connections Aggregation link to class Computador

73

CD-ROM Attributes Attribute Type Notes Velocidade

private : int

Cluster Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:40:34. Modified on 9/11/2004 01:31:14.

Connections Aggregation link from class Switch Aggregation link from class Escravo Aggregation link from class Mestre

Computador Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 9/11/2004 01:18:34. Modified on 9/12/2004 21:46:40.

Connections Aggregation link from class CD-ROM Aggregation link from class Sistema_Operacional Aggregation link from class Processador Aggregation link from class Memória Generalization link from class Escravo Generalization link from class Mestre

Computador Attributes Attribute

Type Notes

nome private : string

Escravo Type: public Class Extends: Computador. Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe

74

Details: Created on 8/11/2004 20:40:05. Modified on 9/12/2004 21:45:16.

Connections Aggregation link from class Placa de Rede Aggregation link to class Cluster Generalization link to class Computador

Escravo Methods Method Type Notes MPI_Client () public: void DHCP_Client ()

public: void

NFS_Client () public: void

Memória Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:39:21. Modified on 9/12/2004 21:47:16.


Memória Attributes Attribute

Type Notes

tamanho private : int

Mestre Type: public Class Extends: Computador. Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:38:58. Modified on 9/11/2004 01:31:14.

Connections Aggregation link from class Placa de Rede Aggregation link to class Cluster Generalization link to class Computador

75

Mestre Methods Method Type Notes MPI_Server () public: void DHCP_Server ()

public: void

TFTP_Server () public: void NFS_Server () public: void SSH_Server () public: void

Placa de Rede Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:39:40. Modified on 9/12/2004 21:46:58.

Connections Aggregation link to class Escravo Aggregation link to class Mestre

Placa de Rede Attributes Attribute Type Notes velocidade

private : int

mac private : string

ip private : string

subrede private : string

Processador Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:39:13. Modified on 9/11/2004 01:31:14.


Processador Attributes

76

Attribute Type Notes velocidade

private : int

fabricante private : string

Sistema_Operacional Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 9/11/2004 01:15:34. Modified on 9/11/2004 01:31:14.


Sistema_Operacional Attributes Attribute Type Notes kernel private :

string

distribuicao

private : string

Switch Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 8/11/2004 20:40:44. Modified on 9/12/2004 21:43:24.

Connections Aggregation link to class Cluster

Switch Attributes Attribute Type Notes qtde_portas

private : int

velocidade private :int

77

Diagrama de estado

Figure 3 : Diagrama de estado

Internal Links Package diagram :: Diagrama de estado

Package :: Diagrama de estado. Package diagram :: Diagrama de estado

Package :: Diagrama de estado.

78

Diagrama de Estado - Nó Escravo

Figure 4 : Diagrama de Estado - Nó Escravo

Envia o resultado da execucao para o nó mestre Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Estado - Nó Escravo Details: Created on 9/11/2004 01:57:03. Modified on 9/11/2004 01:57:44.

Connections Stateflow link to statenode Final Stateflow link from state Executa o trecho de código

Executa o trecho de código Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Estado - Nó Escravo Details: Created on 9/11/2004 01:56:43. Modified on 9/11/2004 01:57:44.

Connections Stateflow link to state Envia o resultado da execucao para o nó mestre Stateflow link from state Recebe um trecho de código

Recebe um trecho de código Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Estado - Nó Escravo Details: Created on 9/11/2004 01:56:10. Modified on 9/11/2004 01:57:44.

Connections Stateflow link to state Executa o trecho de código Stateflow link from statenode Inicio

79

Diagrama de estado - Nó Mestre

Figure 5 : Diagrama de estado - Nó mestre

Apresenta os dados Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de estado - Nó Mestre Details: Created on 9/11/2004 01:49:30. Modified on 9/11/2004 12:53:25.

Connections Não link from statenode Possui partes do programa que não foi distribuida ? Stateflow link to statenode Final

Distribui o programa para um nó ocioso Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de estado - Nó Mestre Details: Created on 9/11/2004 01:44:28. Modified on 9/11/2004 12:53:25.

Connections Stateflow link to state Espera pelo resultado do processamento Sim link from statenode Possui partes do programa que não foi distribuida ?

80

Dividi o programa para distribuir pelos nós do cluster Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de estado - Nó Mestre Details: Created on 9/11/2004 01:42:06. Modified on 9/11/2004 12:53:25.

Connections Stateflow link to statenode Possui partes do programa que não foi distribuida ? Stateflow link from statenode Inicio

Espera pelo resultado do processamento Type: public State Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de estado - Nó Mestre Details: Created on 9/11/2004 01:48:17. Modified on 9/11/2004 12:53:25.

Connections Stateflow link from state Distribui o programa para um nó ocioso Stateflow link to statenode Possui partes do programa que não foi distribuida ?

81

Diagrama de sequencia - cdrom

Figure 6 : Diagrama de sequencia - cdrom

Diagrama de sequencia - cdrom Messages ID Message From

Object To Object

Notes

1 Boot BIOS CD-ROM 2 Carrega o Boot CD-ROM Memória 3 Carrega o Kernel Memória CD-ROM

82

4 Passo o controle para o Kernel Memória Kernel 5 Inicaliza as entradas do sistema Kernel Kernel 6 Monta o diretório raiz Kernel CD-ROM 7 Executa os scripts de inicialização

(sysinit) Kernel Kernel

8 Monta o ramdisk em /ramdisk Kernel Ramdisk 9 Aloca memóra Ramdisk Memória 10 Monta o /proc Kernel Ramdisk 11 Monta o /home Kernel Ramdisk 12 Carrega o /home Ramdisk CD-ROM 13 Monta swap Kernel Memória 14 Inicia o dispositivo de rede Kernel Rede 15 Faz requisição DHCP Kernel Rede 16 Configura a rede Kernel Kernel 17 Runlevel 5 é iniciado Kernel Kernel

BIOS Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:42:37. Modified on 5/6/2005 11:51:06.

BIOS Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:46:30. Modified on 5/6/2005 11:51:06.

CD-ROM Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:42:50. Modified on 5/6/2005 11:44:40.

CD-ROM Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom

83

Details: Created on 5/6/2005 11:46:17. Modified on 5/6/2005 11:51:06.

Memória Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:44:14. Modified on 5/6/2005 11:53:55.

Memória Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:45:46. Modified on 5/6/2005 11:51:06.

Ramdisk Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 11:59:11. Modified on 5/6/2005 12:50:02.

Rede Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - cdrom Details: Created on 5/6/2005 12:47:12. Modified on 5/6/2005 12:47:15.

84

Diagrama de sequencia - MPI

Figure 7 : Diagrama de sequencia - MPI

Diagrama de sequencia - MPI Messages ID Message From

Object To Object Notes

1 Cria a pasta /mpi Kernel Filesystem

2 Cria o arquivo /mpi/lamhost Kernel Filesystem

3 Exporta /mpi Kernel NFS

85

Server 4 Cria a pasta /mpi Kernel Filesyste

m

5 Mapeia o diretório /mpi via NFS Kernel NFS Server

6 Mapeia em /mpi Kernel Filesystem

7 Inclui o IP no arquivo lamhost Kernel Filesystem

8 Kernel Filesystem

9 Inicia o Cluster com as entradas de /mpi/lamhost

Kernel MPI

10 Compila programa Kernel MPI 11 Copia o binario do programa para

/ramdisk Kernel Filesyste

m

12 Executa o programa Kernel MPI 13 Executa o programa MPI MPI 14 Executa o programa MPI MPI 15 Devolve o resultado MPI MPI 16 Devolve o resultado MPI Kernel 17 Salva o resultado em /ramdisk Kernel Filesyste

m

Internal Links Sequence diagram :: Diagrama de sequencia - MPI

Package :: Diagrama de sequencia - MPI. Sequence diagram :: Diagrama de sequencia - MPI

Package :: Diagrama de sequencia - MPI.

Actor1 Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 12:51:03. Modified on 5/6/2005 12:51:03.

Filesystem Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 12:50:55. Modified on 5/6/2005 13:12:36.

86

Filesystem Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 13:07:20. Modified on 5/6/2005 13:13:02.

Kernel Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 12:50:37. Modified on 5/6/2005 13:12:36.

Kernel Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 13:05:24. Modified on 5/6/2005 13:06:27.

MPI Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 12:56:28. Modified on 5/6/2005 13:05:36.

Nó mestre Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 13:12:00. Modified on 5/6/2005 13:12:36.

Nós escravos Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de sequencia - MPI Details: Created on 5/6/2005 13:12:36. Modified on 5/6/2005 13:13:02.

87

Use Case

Figure 8 : Use Case

Internal Links Package diagram :: Use Case

Package :: Use Case. Package diagram :: Use Case

Package :: Use Case.

88

Criação de programa paralelo

Figure 9 : Criacao programa paralelo

Usuário Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Criação de programa paralelo Details: Created on 8/11/2004 19:45:20. Modified on 8/11/2004 22:19:02.

Connections Use link to usecase Boot do sistema<Inicialização do sistema> Use link to usecase Executa programa Use link to usecase Compila programa Use link to usecase Escreve programa

89

Compila programa Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Criação de programa paralelo Details: Created on 8/11/2004 19:45:46. Modified on 9/12/2004 21:53:53.

Constraints Approved Pre-condition . Deve existir um arquivo com código fonte. Approved Post-condition . O arquivo fonte foi compilado.

Connections Include link to usecase Efetua login no sistema Use link from actor Usuário

Scenarios

Compila Programa {Basic Path}. 1) O usuário utiliza o compilador disponível para compilar o programa 2) O compilador verifica sintáticamente e semanticamente o código fonte 3) Se a sintática e a semantica estiverem corretas o compilador gera o arquivo binário, salvando no homedir do usuário Erro na compilação {Alternate}. Se no passo 2 ocorrer um erro de compilação 1) O usuário volta ao caso de uso "Escreve programa" para corrigir o código Já possui o programa executável {Alternate}. No passo 1, se o usuário já possuir o código binário do programa 1) O usuário transfere (via ftp, ssh) o arquivo para o nó mestre 2) Volta ao passo 2 do fluxo normal

Efetua login no sistema Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Criação de programa paralelo Details: Created on 8/11/2004 19:46:17. Modified on 11/11/2004 18:25:59.

Connections Include link from usecase Compila programa Include link from usecase Executa programa Include link from usecase Escreve programa

Scenarios

Efetua login {Basic Path}.

90

1) O usuário informa o login e a senha 2) O nó mestre verifica se o login existe no sistema 3) O nó mestre verifica se a senha é correta para o usuário 4) O usuário é autenticado, permitindo a utilização do sistema Login inválido {Alternate}. Se no passo 2 o login do usuário não existir 1) O sistema apresenta a mensagem: "Login inválido" 2) Volta ao passo 1 do fluxo principal Senha inválida {Alternate}. Se no passo 3 a senha não for igual a senha do login do usuário 1) O sistema apresenta a mensagem: "Senha inválida!" 2) Volta ao passo 1 do fluxo principal

Escreve programa Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Criação de programa paralelo Details: Created on 8/11/2004 19:45:34. Modified on 9/12/2004 21:53:53.


Scenarios

Escreve programa {Basic Path}. 1) O usuário abre um editor de texto no nó mestre 2) O usuário digita o código fonte do sistema 3) O usuário salva o código fonte em seu diretório (homedir) Programa pronto {Alternate}. No passo 1 se o usuário já possuir o código fonte: 1) Transfere o arquivo com o código fonte para o nó mestre(via ftp, ssh) 2) Volta o passo 3 do cenário principal

Executa programa Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Criação de programa paralelo Details: Created on 8/11/2004 19:46:00. Modified on 9/12/2004 21:53:53.

Constraints

91

Approved Pre-condition . Deve ter o programa compilado. Approved Post-condition . Programa é executado.


Scenarios

Erro na executar do programa {Alternate}. Se no decorrer da execução do programa ocorrer um erro 1) O usuário volta ao caso de uso "Escreve programa" para arrumar o código Executa o programa {Basic Path}. 1) O usuário inicia o programa executável 2) O nó mestre distribuí o programa entre os nós escravos 3) Os nós escravos executam o programa 4) Os nós enviam ao nó mestre o resultado da execução 5) O nó mestre apresenta o resultado final

92

Inicialização do sistema

Figure 10 : Inicialização do sistema

Boot do sistema Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Inicialização do sistema Details: Created on 8/11/2004 22:19:02. Modified on 16/6/2005 01:39:15.

Constraints Approved Pre-condition . O nó mestre deve estar funcionando. Approved Post-condition . Sistema pronto para rodar aplicações paralelas escritas em

MPI. Connections Use link from actor Usuário <Criação de programa paralelo>

Scenarios

Boot do sistema {Basic Path}. 1) A BIOS do nodo inicializa o dispositivo de boot (CD-ROM); 2) O dispositivo do nodo lê a mídia e carrega o boot loader na memória; 3) O boot loader carrega o kernel da mídia; 4) O boot loader passa o controle para o kernel. 5) O kernel inicializa as entradas do sistema; 6) O kernel monta o diretório raiz (/); 7) O kernel executa os scripts de inicialização (sysinit); 8) O kernel aloca um espaço na memória 9) O kernel mapeia o espaço alocado na memória em /ramdisk 10) O kernel monta o /proc 11) O kernel monta o /home em /ramdisk; 12) O kernel carrega o /home/kurumin da mídia; 13) O kernel monta o swap; 14) O kernel inicializa o dispositivo de rede;

93

15) O dispositivo de rede faz uma requisição DHCP 16) O kernel configura a rede com o IP recebido via DHCP; 17) O kernel inicializa o runlevel 5; MAC Address não confere {Alternate}. Se no passo 15, o MAC Address não constar na lista 1) O nó mestre não responde a requisição de DHCP

94

APÊNDICE B – REMASTERIZAÇÃO DO KURUMIN

95

Remasterizando o Kurumin para criar um cluster

Autor: Sidnei Baron Data: 09/02/05

Sumário

1. Pré-requisito ........................................................................................96 2. Primeiros passos..................................................................................96 3. Abrindo o CD ......................................................................................96 4. Alterações realizadas ..........................................................................97 1.1. SNMP.................................................................................................................. 97 1.2. COMPILADORES ............................................................................................ 97 1.3. DHCP.................................................................................................................. 97 1.4. MPI...................................................................................................................... 98 1.5. USUÁRIO MPIUSER ....................................................................................... 98 1.6. SSH SEM SENHA ............................................................................................. 99 1.7. SCRIPTS ............................................................................................................ 99 1.1.1. start_server.sh ................................................................................................. 99 1.1.2. start_client.sh................................................................................................... 99 1.1.3. start_dhcp_server.sh..................................................................................... 100 1.1.4. mount_usb.sh................................................................................................. 101 1.1.5. test_ssh.sh....................................................................................................... 101 1.1.6. cp2cluster.sh .................................................................................................. 102 1.1.7. shutdown_cluster.sh...................................................................................... 102

5. Finalizando a remasterização. .........................................................103 6. Criando a ISO ...................................................................................104

96

Pré-requisito Para remasterizar o kurumin é necessário dar boot pelo CD do kurumin e ter uma partição onde possa colocar os arquivos do CD para alterá-los. Está partição deverá ter no mínimo 1,5Gb, mas é recomendado ter mais para gerar as ISOs do kcluster.

Primeiros passos Para fazer as alterações deve se estar logado como root. Para logar-se como root é necessário alterar a senha.

$ sudo passwd # troca a senha do root

$ su -

Montar a partição que vai ficar a imagem do Kurumin. Montar sem opção de "nodev", pois senão dá erros. Por exemplo: mount -t ext2 /dev/hda4 /mnt/hda4 -o users,exec,dev

# mount -t ext2 /dev/hda4 /mnt/hda6

Para a remasterização é necessário muita memória (mais de 1Gb). Pode se aumentar a memória criando mais espaço de swap. Esta sendo montado no /mnt/hda6, pois o script k-extract utiliza este caminho.

# mkdir /mnt/hda6

# dd if=/dev/zero of=/mnt/hda6/swap bs=1024 count=1000000

# mkswap /mnt/hda6/swap

# swapon /mnt/hda6/swap

Abrindo o CD Extrair o CD do Kurumin para o HD. O script irá extrair para /mnt/hda6 e criará dois diretórios: knxsource e knxmaster. O knxsource tem todos o conteúdo do CD descompactado e o knxmaster é o CD compactado.

# k-extract

A nova imagem do Kurumin pode ser editada diretamente pela pasta knxsource, mas utilizando o chroot é possível instalar pacotes via apt-get e abrir o ambiente gráfico para facilitar configuração.

# chroot /mnt/hda6/knxsource/KNOPPIX

# mount -t proc /proc proc

Para abrir o ambiente gráfico, deve se executar em outro terminal os comandos $ xhost +

$ Xnest :1

Para abrir o ambiente gráfico e começar a editar a nova remasterização execute no terminal do chroot os seguintes comandos:

# k-home1

$ k-home2 # depois da execução do k-home1 ele abre o usuário kurumin

97

Alterações realizadas Agora vem a alteração do sistema, os passos a seguir foram usados para remasterizar o Kurumin para o Kcluster. Foi alterado a senha do usuario kurumim e do root para "cluster"

$ passwd # alteração da senha do kurumin

$ sudo passwd # alteração da senha do root

Antes de começar a instalar algum pacote via apt-get é necessário entrar como root e atualizar a lista do apt-get

$ su -

# apt-get update

Agora podem ser instalados os pacotes necessários.

SNMP Instalar o SNMP.

# apt-get install snmpd

A configuração do SNMP está no arquivo /etc/snmp/snmpd.conf # cat /etc/snmp/snmpd.conf

com2sec notConfigUser default public

group notConfigGroup v1 notConfigUser

group notConfigGroup v2c notConfigUser

view systemview included .1

view systemview included .1.3.6.1.2.1.25.1.1

access notConfigGroup "" any noauth exact systemview none none

syslocation KCluster

syscontact Sidnei Baron <[email protected]>

load 12 14 14

pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat

Compiladores Instalar os compiladores pelo script:

# instalar-compiladores

DHCP Instalar o DHCP.

#apt-get install dhcp3-common\stable

#apt-get install dhcp3-server\stable

Agora vem a configurações do DHCP. Ela é feita pelo arquivo /etc/dhcp3/dhcpd.conf. # cat /etc/dhcp3/dhcpd.conf

option option-128 code 128 = string;

option option-129 code 129 = text;

98

default-lease-time 21600;

max-lease-time 21600;

option subnet-mask 255.0.0.0;

option broadcast-address 10.0.0.255;

option routers 10.1.1.1;

option domain-name-servers 10.1.1.3;

option domain-name "kcluster.com.br";

option log-servers 10.1.1.3;

use-host-decl-names on;

subnet 10.0.0.0 netmask 255.0.0.0 {

range 10.1.1.100 10.1.1.200;

}

MPI Para instalar o MPI é necessário fazer o download do Pacote “lam”.

# wget http://www.lam-mpi.org/download/files/lam-7.1.1.tar.gz

Descompactar o pacote. # tar xfzv lam-7.1.1.tar.gz

# cd lam-7.1.1

Setar as variáveis dos compiladores C, C++, and Fortran # CC=cc

# CXX=c++

# FC=g77

# export CC CXX FC

Agora é só compilar e instalar o pacote # ./configure --prefix=/usr/local/mpi

# make

# make install

Também podem ser instalados os exemplos (opcional). # make examples

Usuário mpiuser Para executar o MPI foi criado o usuário mpiuser. Os comandos para o criar o usuário e seus arquivos é:

# groupadd mpigroup

# adduser -g mpigroup mpiuser

# passwd mpiuser # Foi colocado a senha “cluster”

# rm -rf /var/home/mpiuser # Remover para limpar as “sujeiras” iniciais

# mkdir /var/home/mpiuser

# mkdir /var/home/mpiuser/.ssh

99

# cp /etc/skel/.bash* /var/home/mpiuser

Adicionar o PATH dos binários do MPI para o usuário mpiuser # echo export PATH=\$PATH=/usr/local/mpi/bin > /var/home/mpiuser/.bashrc

# chown mpiuser:mpigroup /var/home/mpiuser -R

SSH sem senha Para a troca de mensagens pelo MPI os nodos utilizam o SSH. Por questão de segurança a conexão a uma outra máquina é exigida uma senha. Para que o usuário não fique sempre digitando a senha para todos os nodos foi configurado o login remoto sem senha. Para isso foi executado os seguintes passos com o usuário mpiuser.

# su - mpiuser

$ ssh-keygen -t dsa -f /var/home/mpiuser/.ssh/id_dsa

$ cat ~mpiuser/.ssh/id_dsa.pub >> ~mpiuser /.ssh/authorized_keys

$ exit

# echo ALL : ALL > /etc/hosts.allow

Scripts A seguir são criados os scripts que automatizaram as configurações do cluster.

start_server.sh O script start_server.sh configura o nodo para ser o nó escravo e possui o seguinte conteúdo:

# cat /usr/bin/start_server.sh

#!/bin/sh

echo Iniciando NFS-Server

mkdir /mpi

chown mpiuser:mpigroup /mpi

service nfs-kernel-server stop

service nfs-kernel-server start

## (Re)Cria o arquivo lamhost e adiciona o IP

#

#Pega o IP

#

export MEU_IP=`ip addr |grep inet |grep -v 127.0.0.1|awk '{print $2}'|awk -F/ '{print $1}'`

echo Adicionando o ip $MEU_IP no arquivo /ramdisk/mpi/lamhost

echo $MEU_IP > /mpi/lamhost

## Servico SSH

echo Iniciando SSH

/usr/sbin/sshd > /dev/null 2>&1 &

100

#

dialog --msgbox "IP: $MEU_IP" 0 0

start_client.sh O script start_client.sh configura o nodo para ser o nó escravo do cluster e possui o seguinte conteúdo:

# cat /usr/bin/start_client.sh

#!/bin/sh

IP_NO_MESTRE=$( dialog --title 'No escravo' --stdout --inputbox 'Digite o IP do Servidor.' 0 0 )

if [ "$IP_NO_MESTRE" == '' ]; then

IP_NO_MESTRE=10.1.1.3

fi;

echo IP do No Mestre: $IP_NO_MESTRE

## Montar a particao NFS

#

mkdir /mpi

chown mpiuser:mpigroup /mpi

echo Montando o Diretorio /mpi do servidor.

mount -t nfs $IP_NO_MESTRE:/mpi /mpi -o rsize=8192,wsize=8192,timeo=14,intr

## Adicionar o IP no lamhost no servidor

#

#Pega o IP

export MEU_IP=`ip addr |grep inet |grep -v 127.0.0.1|awk '{print $2}'|awk -F/ '{print $1}'`

#

#Adiciona o IP da maquina no lamhost

echo Adicionando o ip $MEU_IP no lamhost do servidor.

echo $MEU_IP >> /mpi/lamhost

## Servico SSH

#

echo Iniciando SSH.

/usr/sbin/sshd > /dev/null 2>&1 &

#

echo Concluido! Pressione qualquer tecla para continuar.

read

101

start_dhcp.sh O script start_dhcp.sh configura o nodo para ser o servidor DHCP do cluster e possui o seguinte conteúdo:

# cat /usr/bin/start_dhcp.sh

#!/bin/sh

# Configuracao da Rede

#

echo Configurando a rede para o IP 10.1.1.3

ifconfig eth0 10.1.1.3 netmask 255.0.0.0 broadcast 10.0.0.255

#

echo Configurando o Gateway para o IP 10.1.1.1

route add default gw 10.1.1.1

#

echo Configurando DNS para o IP 10.1.1.1

echo nameserver 10.1.1.1 > /etc/resolv.conf

## Servico DHCP

#

echo Iniciando DHCP-Server

service dhcp3-server stop

service dhcp3-server start

#

echo Concluido! Pressione qualquer tecla para sair.

read

mount_usb.sh O script mount_usb.sh monta o Pendrive USB no diretório /mnt/usb. O script possui o seguinte conteúdo:

# cat /usr/bin/mount_usb.sh

#!/bin/sh

echo Criando diretorio /mnt/usb.

mkdir /mnt/usb

echo Habilitando o kernel a montar USB

# usbcore - Habilita o usb e monta a pasta /proc/bus/usb, onde os perifericos USB ficam.

modprobe usbcore

mount -t usbfs none /proc/bus/usb

# usb-ohci e usb-uhci - Habilita o controlador USB.

modprobe usb-ohci

102

modprobe usb-uhci

# usb-storage - Habilita Storage USB (USB de armazenamento).

modprobe usb-storage

# Monta o Storage USB.

echo Montado o Storage USB em /mn/usb.

mount /dev/sda1 /mnt/usb/

echo Concluido! Pressione qualquer tecla para continuar.

read

test_ssh.sh O script test_ssh.sh faz uma conexão SSH com todos os nodos relacionados em /mpi/lamhosts para adicionar a chave criptografada. O script possui o seguinte conteúdo:

# cat /usr/bin/test_ssh.sh

#!/bin/sh

for i in `cat /mpi/lamhost |grep -v ^#`;

do

echo Testando Host $i;

ssh mpiuser@$i echo Ok > /dev/null 2>&1;

if [ $? == 0 ];

then echo [OK]: SSH in Host $i is started.

else

echo [ERROR]: SSH in Host $i is stoped.

fi;

done;

cp2cluster.sh O script cp2cluster.sh copia um arquivo, passado por parâmetro, para a área /ramdisk de todos os nodos relacionados em /mpi/lamhosts. O script possui o seguinte conteúdo:

# cat /usr/bin/cp2cluster.sh

#!/bin/sh

for i in `cat /mpi/lamhost |grep -v ^#`;

do

echo Copiando o arquivo $1 para o host $i;

scp $1 mpiuser@$i:/ramdisk > /dev/null 2>&1;

if [ $? == 0 ];

103

then echo [OK]: Arquivo $1 copiado para o host $i.

else

echo [ERROR]: Não foi possível copiar o arquivo $1 para o host $i.

fi;

done;

shutdown_cluster.sh O script shutdown_cluster.sh desliga todas os nodos relacionados em /mpi/lamhosts, executando o comando “halt” via SSH. O script possui o seguinte conteúdo:

# cat /usr/bin/shutdown_cluster.sh

#!/bin/sh

for i in `tac /mpi/lamhost |grep -v ^#`;

do

echo Tentando Desligar Host $i;

ssh mpiuser@$i sudo halt > /dev/null 2>&1;

if [ $? == 0 ];

then echo [OK]: Host $i está sendo desligado;

else

echo [ERROR]: Host $i não pode ser desligado;

fi;

done;

Finalizando a remasterização. Após fazer todas as alterações é necessário fechar o KDE (no Xnest) e executar no terminal do chroot. Localizar os pacotes órfãos (deborphan) e remover com o comando "apt-get remove nome_do_pacote".

# deborphan

Limpar o cache do do apt-get para libera espaço. # apt-get clean

# k-clean-apt-get

Remover históricos de comandos. # rm -f /home/root/.bash_history

# rm -rf /.rr_moved

Para finalizar é preciso desmontar o /proc e executar o k-home3. # umount /proc

# k-home3

Agora deve ser fechado o chroot (CTRL+D). # exit

104

Criando a ISO Agora que as alterações foram feitas é necessário compactar toda a imagem do novo Sistema.

# mkisofs -R -V "Kcluster" \

| -hide-rr-moved -pad /mnt/hda6/knxsource/KNOPPIX \

| /usr/bin/create_compressed_fs - 65536 > \

/mnt/hda6/knxmaster/KNOPPIX/KNOPPIX

E finalmente criar a ISO do novo CD. # cd /mnt/hda6/knxmaster

# mkisofs -pad -l -r -J -v -V "KCluster" \

-b KNOPPIX/boot.img -c KNOPPIX/boot.cat \

-hide-rr-moved -o /mnt/hda6/kcluster.iso /mnt/hda6/knxmaster

105

APÊNDICE C – ARQUIVOS DE SAÍDA DO PARPAC

106

performance_10lbu.dat 013 1.047e+00 012 1.015e+00 011 9.628e-01 010 8.149e-01 009 7.655e-01 008 9.951e-01 007 7.215e-01 006 5.737e-01 005 4.966e-01 004 5.834e-01 003 3.545e-01 002 3.978e-01 001 3.018e-01

107

parpacbench_13cpu_10lbu.out ========================================================= ParPac Application Benchmark BGK Lattice Boltzmann simulation of a viscous fluid streaming through a porous media Fraunhofer ITWM - Germany ========================================================= Benchmark description: ---------------------- Simulation of the dynamical behaviour of a # # # # # viscous fluid streaming through a regular -----------> porous media under the influence of a # # # # # driving pressure gradient and calculation -----------> of the permeability of the porous media. # # # # # System information: ------------------- Date______: Sat Jun 11 09:06:20 2005 Machine___: i686 System____: Linux Release___: 2.4.25-klg Version___: #1 SMP Ter Abr 6 09:28:24 BRT 2004 Processors: 13 Fluid parameters: ----------------- mass density___________________________: 1.260e+03 kg/m^3 kinematic viscosity____________________: 1.167e-03 m^2/s pressure gradient______________________: 7.000e+06 Pa/m Benchmark parameters: --------------------- total no. of grid points______________: 4096000 total no. of fluid points______________: 3639467 material porosity______________________: 8.885e-01 size of each load balance unit_________: 1000 Benchmark results: ------------------ calculated permeability of the material_: 2.671e-07 m^2 total simulation time___________________: 1037.94 s fluid grid point calculation rate_______: 1.753 millions/s floating point operation rate___________: 1.047e+00 Gflops End of benchmark =========================================================

108

permeability.dat 4.76190e-06 4.44571e-08 1.26000e+03 2.11640e-01 9.52381e-06 1.17080e-07 1.26000e+03 5.57365e-01 1.42857e-05 1.68190e-07 1.26000e+03 8.00674e-01 1.90476e-05 2.03148e-07 1.26000e+03 9.67095e-01 2.38095e-05 2.27211e-07 1.26000e+03 1.08165e+00 2.85714e-05 2.42935e-07 1.26000e+03 1.15650e+00 3.33333e-05 2.53172e-07 1.26000e+03 1.20524e+00 3.80952e-05 2.59091e-07 1.26000e+03 1.23341e+00 . . . . <várias linhas> . . . . 2.35238e-03 1.99192e-07 1.26000e+03 9.48262e-01 2.35714e-03 1.99235e-07 1.26000e+03 9.48466e-01 2.36190e-03 1.99192e-07 1.26000e+03 9.48262e-01 2.36667e-03 1.99235e-07 1.26000e+03 9.48465e-01 2.37143e-03 1.99192e-07 1.26000e+03 9.48262e-01 2.37619e-03 1.99235e-07 1.26000e+03 9.48465e-01 2.38095e-03 1.99192e-07 1.26000e+03 9.48262e-01 2.38571e-03 1.99235e-07 1.26000e+03 9.48465e-01

109

APÊNDICE D – ARTIGO CIENTÍFICO

110

CLUSTER DE BAIXO CUSTO Sidnei Baron Ademir Goulart

[email protected] [email protected]

Universidade do Vale do Itajaí – UNIVALI

Centro de Ensino Superior de Ciências Tecnológicas da Terra e do Mar - CTTMar

Curso de Ciência da Computação

Rua Uruguai, 458 Bairro: Centro

Itajaí/SC CEP:88302-202

RESUMO

Um cluster pode ser definido como um conjunto de nós processados autônomos e que, interligados, comportam-se

como um sistema único. Clusters são utilizados quando os serviços devem ser processados o mais rápidos possível ou

ter alta disponibilidade. Pesquisadores, organizações e empresas estão utilizando os cluster porque necessitam de

desempenho escalável, gerenciamento de recursos, disponibilidade ou processamento em nível supercomputacional a

um preço adequado. A aquisição de máquinas e de redes de alto desempenho é cara. Grandes organizações e

universidades possuem equipamentos que ficam boa parte do tempo com processadores ociosos. A fim de oferecer um

cluster de baixo custo que contribua para um maior aproveitamento dos recursos das organizações e universidades, este

projeto apresenta a modelagem, montagem, instalação, validação e disponibilização de um ambiente para

processamento paralelo baseado em um cluster de PCs (Personal Computers). O cluster deverá ser escalável e os seus

nodos deverão ser de fácil inclusão com configuração em ambientes distribuídos, onde a configuração manual das

máquinas deva ser evitada. Na primeira parte deste trabalho foram realizados estudos dos conceitos de cluster, os passos

necessários para a montagem e gerenciamento, e programação paralela. Ainda nesta parte foi a de modelagem, a qual

especificou e se criou o modelo conceitual do sistema. A segunda parte foi a de desenvolvimento e validação do cluster,

apresentando os resultados obtidos.

Palavras-chave: Cluster. Sistemas Distribuídos, Programação Paralela.

ABSTRACT

A cluster can be defined as a set of autonomous prossessing nodes, interconneted, which behave as a unique system.

Clusters are used when the services have to be processed the fastest as possible or with high availability. Researchers,

organizations and companies are using clusters because they need scalable performance, resources management,

availability or processing at super computational level to the adequated price. The acquisition of machines and

network of high performance is expensive. Large organizations and universities have equipaments that are the greatest

part of time with idle processors. In order to offer a cluster of low price that contributes to the greatest utilization of the

resources of the organizations and universities, this work discusses how to model, mount, install, validate and turn

111

available an environment for the parallel processing based on a cluster of personal computer. The cluster should be

scalable and their nodes should be of easy inclusion with configuration in distributed environments, where the manual

configuration of machines should be avoided. In the first part of this work concepts studies of clusters, the necessary

steps to the assembly and management and parallel programming were accomplished. Also in this first part, was made

the modeling that specifies and creates the conceptuel model of the system.The second part was the implemantation and

validation of the cluster showing the results collected.

Keywords: Cluster, Distributed Systems, Parallel Programming.

1. Introdução

Um cluster (ou agregado) de computadores pode ser definido como um sistema de

computação paralela composta de um conjunto de nós processadores (PCs – Personal Computers –

ou estações de trabalho) autônomos e que, interligados, comportam-se como um recurso

computacional único (BUYYA, 1999).

Segundo Patterson (2000), serviços que freqüentemente requerem alta disponibilidade e

balanceamento de carga de forma escalável são indicados para o ambiente de cluster. Exemplos

desses são os Internet Service Providers (provedores de Internet) e sites de comércio eletrônico.

Indústrias cinematográficas podem se utilizar desses recursos, pois necessitam de alto desempenho

para renderização de gráficos de altíssima qualidade e animações.

Pesquisadores, organizações e empresas estão utilizando os clusters porque necessitam de

desempenho escalável, gerenciamento de recursos, disponibilidade ou processamento em nível

supercomputacional a um preço adequado.

A aquisição de máquinas e de redes de alto desempenho é cara. Além do custo do hardware,

os custos de instalação e de manutenção também são altos, pois são feitos por profissionais

capacitados e, geralmente, terceirizados.

Grandes organizações e universidades possuem laboratórios que ficam uma boa parte do

tempo com processadores ociosos, tais como muitos laboratórios de ensino, nas universidades, nos

finais de semana. Esses ambientes poderiam ser melhor aproveitados em horários que não estão

sendo utilizados localmente.

A fim de oferecer um cluster de baixo custo que contribua para um maior aproveitamento

dos recursos das organizações e universidades, este projeto propõe modelar, montar, instalar,

validar e disponibilizar um ambiente para processamento paralelo baseado em um cluster de

PCs.

112

2. Objetivo

Este projeto de pesquisa tem como objetivo geral modelar, montar, instalar, validar e

disponibilizar um ambiente para processamento paralelo baseado em um

cluster de PCs. O cluster deverá ser escalável e os seus os nodos deverão ser de fácil inclusão e

configuração em ambientes distribuídos onde a configuração manual das máquinas deva ser evitada

3. Metodologia

Foram realizadas várias etapas para alcançar o objetivo deste trabalho. Nesta primeira parte

do projeto, a etapa inicial foi a de aprendizado, na qual foi realizado um estudo sobre clusters, os

passos necessários para montagem e gerenciamento de um cluster, e programação de sistemas

paralelos. A segunda etapa foi a de modelagem, a qual especificou o funcionamento e se criou o

modelo conceitual do sistema.

Na segunda parte deste projeto, foi desenvolvido o sistema modelado, disponibilizado

programas paralelos, validando o cluster com programas paralelos e analisando seus resultados. Em

paralelo com essas atividades, foi realizado a documentação deste trabalho e redigido um artigo

científico.

4. Fundamentação teórica

Neste capítulo são apresentados os conceitos relevantes para o desenvolvimento deste

projeto, descrevendo a classificação dos sistemas paralelos, cluster, programação paralela e análise

de desempenho.

4.1. Classificação de Sistemas Paralelos

Conforme Gualeve (2004), Michael Flynn em 1972 caracterizou diversos modelos de

arquiteturas de computadores seguindo dois critérios, o número de fluxos de dados e de instruções.

A classificação foi feita em quatro classes de computadores. Estas classes são:

• Arquitetura SISD (Single Instruction Single Data): As instruções são executadas

seqüencialmente sem qualquer paralelismo.

• Arquitetura MISD (Multiple Instruction Single Data): São máquinas que executam

várias instruções ao mesmo tempo sobre um único dado.

• Arquitetura SIMD (Single Instruction Multiple Data): São máquinas que executam uma

instrução paralelamente utilizando vários dados de forma síncrona.

113

• Arquitetura MIMD (Multiple Instruction, Multiple Data): São máquinas que possuem

mútiplos fluxos de instruções e múltiplos dados e que cada processador age

independentemente.

Dependendo de uma máquina paralela utilizar-se ou não de uma memória compartilhada por

todos os processadores, pode se diferenciar essas máquinas paralelas em multiprocessadores

(memória compartilhada) e multicomputadores (memória distribuída).

Nos multiprocessadores as máquinas são fortemente acopladas, pois possuem múltiplos

processadores que compartilham um espaço de endereçamento de memória comum.O uso de uma

memória cache em cada processador é adotado para evitar o gargalo gerado quando uma única área

de memória é acessada simultaneamente por diversos processadores. Para manter todos os cache

atualizados é utilizada uma técnica chamada write-trhough, onde toda a gravação é feita na

memória principal e a leitura na memória cache. Também todas as cache ficam monitorando o

barramento e se alguma alteração ocorrer na memória principal, cujo endereço também está na

cache de um processador, este também atualiza o conteúdo da cache (TANENBAUM, 1995).

Dependendo da interligação dos processadores com a memória, a classe de

multiprocessadores se enquadra em duas categorias principais: UMA (Uniform Memory Access) e

NUMA (Non Uniform Memory Access).

A categoria NUMA ainda pode ser subdividida dependendo da coerência de cache ter sido

tratado ou não, e se esse tratamento ter sido feito por hardware ou em sofware: NCC-NUMA (Non-

Cache-Coherent Non-Uniform Memory Access), CC-NUMA (Cache-Coherent Non-Uniform

Memory Access) e SC-NUMA (Software-Coherent Non-Uniform Memory Access), COMA

(Cache-Only Memory Architeture).

Nos multicomputadores as máquinas são formadas por várias unidades processadoras, cada

uma unidade (nó) é constituída por um processador, memória local e dispositivo de entrada/saída.

Nesta classe a comunicação entre os diferentes nós do sistema é feita através de dispositivos físicos

de entrada/saída ligadas num barramento de interconexão, como uma rede local de velocidade de

100 a 1000 Mbps. Devido a essas características os multicomputadores são denominados

fracamente acoplados (ROSE e NAVAUX, 2002).

Ainda segundo Rose e Navaux (2003), conforme a interligação dos processadores com a

memória, estas máquinas podem ser classificadas como NORMA (No Remote Memory Access).

Nesta classificação, os processadores, conectados em rede de alto desempenho, possuem memórias

locais e a troca de dados é realizada através de troca de mensagens.

4.2. Cluster de Computadores

114

Segundo Buyya (1999), um agregado, ou no inglês cluster, é um sistema de computação

paralela composto de um conjunto de elementos (nós) que se comunicam através de uma rede de

interconexão e utilizam softwares de sistemas distribuídos para resolver um problema. Cada

elemento é composto por um ou mais processadores e de uma ou mais memórias. Estes elementos

são visto pelos seus usuários como um sistema de recurso único, também chamado de sistema de

imagem única (SSI – Single System Image).

Conforme a configuração e objetivos os clusters podem ser chamados de diferentes formas

entre diferentes grupos de pesquisa, como NOW (Network of Workstation), COW (Cluster of

Workstation), Beowulf e OpenMosix.

Goulart (2002), destaca entre as inúmeras vantagens em se utilizar cluster as seguintes: alta

performace; escalabilidade e facilidade de expansão; alta disponibilidade; baixo Custo e;

independência fornecedores.

4.3. Programação Paralela

Segundo Souza (apud Rauber, 2003), é comum a utilização de bibliotecas de programação

que contenham rotinas de comunicação através de troca de mensagem para o desenvolvimento de

programas paralelos que executem em sistemas distribuídos. Alguns exemplos destas bibliotecas

são o PVM, o MPI e o OpenMP.

Segundo Sterling (2002), PVM (Parallel Virtual Machine) é uma integração de ferramentas

e bibliotecas que emulam o propósito geral, a flexibilidade e heterogeneidade da computação

paralela nos computadores interconectados de várias arquiteturas.

O MPI (Message Passing Interface) é uma biblioteca com funções para a troca de

mensagens, responsável pela comunicação e sincronização de processos em um cluster paralelo. O

principal objetivo do MPI é disponibilizar uma interface que seja utilizada no desenvolvimento de

programas que utilizem troca de mensagens (MPI-FORUM, 2005).

O OpenMP é um modelo portável e escalável que da aos programas paralelos uma memória

compartilhada, através de uma simples e flexível interface para o desenvolvimento de aplicações

paralelas escritos em C/C++ e Fortran (OPENMP, 2004).

4.4. Análise de Desempenho

As três técnicas para análise de desempenho são modelo analítico, simulação e medição. A

escolha da melhor técnica de análise de desempenho depende do estágio o qual o sistema está.

Medição somente é possível se algum outro sistema similar já exista. Se for uma nova concepção, o

modelo analítico e a simulação são as únicas técnicas que podem ser utilizadas (JAIN, 1991).

115

Segundo Jain (1991), para cada estudo de desempenho, um critério de desempenho ou

métrica deve ser escolhido. Uma maneira de preparar o estudo de desempenho é listando os serviços

oferecidos pelo sistema. Para cada requisição de serviço feita existem muitas possibilidades de

saídas. O sistema pode executar um serviço corretamente, incorretamente ou não executar o serviço.

As métricas mais utilizadas para a análise de desempenho são o tempo de resposta, o

throughput, utilização, confiabilidade e disponibilidade.

Para Zelenovsky e Mendonça (2004), uma boa solução para medir o desempenho de uma

máquina paralela é medir o ganho de velocidade (GV), speedup, verificando a relação entre os

tempos gastos para executar uma determinada tarefa em um computador serial e em um computador

paralelo. A expressão a seguir (Equação 1) apresenta o cálculo do GV.

Equação 4

O ganho de velocidade não é a mesma que a quantidade de elementos processados, pois

quando se escreve um programa para rodar em máquinas paralelas, é necessário colocar trechos de

código para sincronizar os diversos nós do cluster e para a troca de informações entre eles. Estes

trechos são chamados de custo da paralelização. Dependendo da tarefa a ser executada, pode haver

uma necessidade de sincronização e troca informações tão grandes que venha a inviabilizar o

processamento paralelo. O ideal é que um aumento no número de processadores traga um igual

aumento de desempenho (ZELENOVSKY E MENDONÇA, 2004).

Segundo Zelenovsky e Mendonça (2004), existem tarefas que são eminentemente

seqüenciais e que não tiram proveito de um computador paralelo. Assim, é comum que as tarefas a

serem executadas possuam porções paralelizáveis e porções que precisam ser executadas de forma

seqüencial.

Abordando esse tema, Amdahl propôs uma expressão para esse problema, que ficou

conhecida como a Lei de Amdahl Esta expressão está representada na Equação 2, onde T é o tempo

para que uma tarefa execute em uma máquina seqüencial, o p representa as partes que são

obrigatoriamente executadas de forma seqüencial, pT representa tempo gasto com a execução serial,

(1-p) representa a porção paralelizável e o N é a quantidade de nós no cluster (ZELENOVSKY E

MENDONÇA, 2004).

116

NTppT )1( −+

Equação 5

Somente o trecho paralelizável tira proveito dos N processadores, sendo assim, o Ganho de

Processamento é dado pela expressão da Equação 3.

NPp

GP)1(

1−

+=

Equação 6

Segundo Rose e Navaux (2003), alguns pensam que a forma mais adequada para medir o

desempenho de uma máquina paralela é medir o número de instruções executadas num determinado

intervalo de tempo. Para medir a velocidade das máquinas paralelas, foi estabelecida uma unidade,

chamada FLOPS (Floating Point Operations Per Second), que mede o número de operações em

ponto flutuantes executadas por segundo.

Essa medida não é muito precisa, pois o poder das instruções varia de máquina para

máquina. Portanto a forma mais correta de medir o desempenho entre máquinas é empregar

programas padrão que são rodados nas máquinas em comparação, essa técnica é chamada de

benchmark (ROSE e NAVAUX, 2003).

Segundo Jain (1991), os benchmark são compostos por uma serie de testes ordenados a fim

de se obter um resultado pré-arranjado não disponíveis em sistemas concorrentes. As ferramentas

benchmarks mais conhecidas são: LINPACK, LAPACK, ScaLAPACK e PARPAC.

O LINPACK (Linear Algebra Software Package) é um conjunto de rotinas em Fortran

usadas como benchmark para supercomputadores. O LINPACK analisa e resolve sistemas de

equações lineares e problemas de mínimos quadrados. Ela usa algoritmos orientados a array como

colunas para aumentar a eficiência, preservando a localidade (LAPACK, 2004).

O LAPACK (Linear Algebra Package) é uma biblioteca em Fortran 77 para Álgebra Linear

constituída de rotinas para resolução de sistemas de equações lineares, problemas de mínimos

quadrados, de autovalores e autovetores. O LAPACK utiliza as rotinas do EISPACK e LINPACK

de forma eficiente em computadores vetoriais ou de memória compartilhada (LAPACK, 2004).

O ScaLAPACK (Scalable Linear Algebra Package) é uma biblioteca de rotinas de alta

performance para álgebra linear, utilizada em computadores MIMD de forma distribuída por

passagem de mensagem e estações de trabalho que suportam as APIs MPI e/ou PVM. Essa

biblioteca é utilizada por diversas aplicações científicas (SCALAPACK, 2004).

117

O PARPAC é um programa de benchmark, desenvolvido pela Fraunhofer ITWM (Institut

Techno – und Wirtschaftsmatematik), que visa solucionar o problema do complexo do fluxo em

base tridimensional utilizando o método de generalização lattice Boltzmann. A idéia básica é

descrever a equação de Navier-Stokes por simulação simplificada de partículas dinâmicas. Assim, o

fenômeno físico do complexo pode ser explicado por uma maneira natural e elegante. . O código é

escrito em C++ usando muitas características de programação orientando a objetos. Este benchmark

é totalmente paralelizável e possui balanceamento de carga com otimizações de comunicação entre

os nodos. Devido a uma completa paralelização, PARPAC é um código de alta eficiência para

grandes e complexas aplicações (FRAUNHOFER, 2005).

5. Projeto

Neste capítulo é apresentada à modelagem realizada do sistema, a metodologia adotada, o

desenvolvimento e os resultados obtidos do projeto.

5.1. Modelagem

A modelagem foi realizada utilizando o diagrama de caso de uso, seqüência, classe, estado e

diagrama de componente, focalizando o ambiente de programação paralela MPI. A ferramenta

utilizada para modelar foi a Enterprise Architect Trial v4.10.739.

5.2. Desenvolvimento

Para o desenvolvimento deste trabalho foi adotada a distribuição linux Kurumin (versão

3.31), por ela possuir um sistema LIVE-CD, ou seja, o sistema roda somente utilizando o CD-

ROM. Desta forma não é necessário a instalação do sistema operacional no HD (Hard Disk),

preservando a configuração existente no equipamento. Esta distribuição tem ampla compatibilidade

com diferentes hardwares, e ainda é um sistema operacional configurado por brasileiros.

5.3. Apresentação do Sistema

Este cluster desenvolvido foi batizado pelos autores deste projeto de KCluster (Kurumin

Cluster). Ele foi desenvolvido a partir de uma remasterização do Kurumin, incluindo novos pacotes.

Todas as propriedades do Kurumin foram mantidas, como detecção de hardware, KDE como

interface gráfica padrão e os ícones mágicos.

Utilizando a mesma idéia dos ícones mágicos, foram criados alguns scripts para automatizar

as configurações do cluster, eles estão localizados no diretório /usr/bin. Os scripts podem ser

executados ou pela linha de comando ou pelos ícones localizados no desktop.

118

Para a utilização do cluster foi criado um usuário chamado mpiuser. O home do usuário está

localizado em /var/home/mpiuser. Este usuário possui todas as variáveis de ambiente necessárias

para a inicialização do ambiente paralelo MPI e para a execução de programas paralelos em MPI.

Para colocar em funcionamento o cluster, vários passos são necessários. O primeiro passo é

iniciar o nó mestre do cluster, utilizando a mídia do Kcluster. O motivo do nó mestre ser a primeira

máquina a ser iniciada é que ela poderá ser o servidor de DHCP da rede, que obrigatoriamente

deverá estar ativo antes do boot dos outros nodos, para que eles adquiram um IP e ingressem na

mesma rede.

O script que configura o nó mestre como servidor DHCP altera o IP para 10.1.1.3 e

disponibiliza a faixa de IPs de 10.1.1.100 a 10.1.1.200 para as requisições DHCP. O comando para

iniciá-lo é “kcluster_start_dhcp” ou pelo ícone “Servidor DHCP” no desktop.

Caso a rede já possuir um servidor DHCP, não faz diferença na ordem que são iniciadas as

máquinas, já que todas possuem o mesmo sistema operacional e as mesmas configurações, mas o

script que configura o uma máquina como nó mestre deve ser iniciado antes que os scripts dos nós

escravos.

Com todos os nodos disponíveis já é possível iniciar o ambiente paralelo MPI e rodar os

programas paralelos. Existem alguns programas de exemplo disponíveis em

/var/home/mpi/exemplos.

Para compilar o programa podem ser usados os comandos mpicc, mpiCC ou mpic++ e

mpif77, dependendo da linguagem utilizada para escrever o programa. Um exemplo da sintaxe do

comando para compilar um programa escrito em c é: mpicc <programa_codigo_fonte.c> –o

<programa_binario>.

Após compilar o programa, o binário do programa deve ser disponibilizado na mesma área

para todos os nodos do cluster. Devido às dificuldades encontradas para realizar está operação com

o NFS, foi contornada a situação criando um script (kcluster_cp2cluster) que copia o binário para o

/ramdisk de todos os nodos. A sintaxe do comando para fazer está cópia é: kcluster_cp2cluster

<programa_binario>

Um programa paralelo deve ser executado no cluster com o usuário mpiuser pelo comando:

mpirun –np <numero_de_processos> <programa_binario>. Os resultados e os programas escritos

em MPI podem ser salvos da mesma forma feita para copiar os programas paralelos para o cluster.

Para encerrar o ambiente MPI pode ser utilizado o comando “lamhalt”, ou “wipe

/mpi/lamhost” para forçar a finalização.

119

No final das execuções, para desligar todo o sistema, ao invés de entrar máquina por

máquina e desligá-las, o comando “kcluster_shutdown” pode ser executado para desligar todas as

máquinas de uma só vez.

5.4. Dificuldades Encontradas

No decorrer do desenvolvimento do sistema foram encontradas várias dificuldades. Algumas

facilmente contornadas, mas para outras a solução adotada alterou a forma original prevista para o

funcionamento do cluster.

O maior problema encontrado foi na troca do sistema root que estava no disquete para o root

compartilhado no servidor pelo NFS, que foi resolvido aumentando os parâmetros de timeout e de

buffers de leitura e gravação.

Por motivos técnicos, a idéia original de boot do sistema utilizando o disquete foi mudada

para boot utilizando o CD-ROM. Com a utilização do CD-ROM foi possível incluir todo o sistema

necessário para rodar o ambiente do cluster, como os serviços de DHCP, MPI e NFS.

Como o sistema operacional roda inteiramente pelo CD-ROM, não é possível gravar

nenhum arquivo no sistema de arquivo. O Kurumin possui um mecanismo que mapeia uma área da

memória no sistema de arquivo do sistema, chamado de ramdisk. Nesta área é possível ler e gravar,

mas não é possível compartilhar via NFS. Para contornar esta situação foi criado um script,

chamado de kcluster_cp2cluster, que copia via SSH o programa para a área ramdisk de todos os nós

do cluster.

5.5. Resultados

Com o objetivo de validar o cluster desenvolvido, foram executadas duas aplicações: o

benchemarck PARPAC e uma multiplicação de matrizes. As aplicações foram executadas no

laboratório de ciência da computação da UNIVALI. As máquinas utilizadas são da fabricante DELL

e possuem um processador Pentium IV 2.40 Ghz, 512Mb de memória RAM e placa de rede 10/100

Mbits. A rede deste laboratório opera em 100 Mbits, mas também foi utilizado um HUB de 10

Mbits para os testes.

O benchmark PARPAC foi escolhido por este ser de interesse e estar mais relacionado com

outros projetos de pesquisa do laboratório de pesquisa LSED na UNIVALI, e trata da simulação de

fluídos através de técnicas de lattice Boltzmann.

A execução do PARPAC foi realizada utilizando 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 e 13

máquinas com a rede a 100 Mbits. Como os parâmetros usados em cada execução no PARPAC

variam conforme o número de nodos no cluster, desta forma não é possível calcular o speedup, pois

120

a carga de trabalho não é constante. Os resultados estão apresentados pela tabela (Tabela 3) e pelo

gráfico (Figura 24) a seguir.

Tabela 7. Resultados do PARPAC

Nodos Total de pontos

da grade

Total de

pontos do

fluído

Porosidade do

material

Tempo total de

simulação

Taxa de cálculo de pontos na grade do

fluído

Desempenho (GFlops)

1 343000 300125 8,750E-01 296,80 0,506 3,018E-01 2 729000 654912 8,984E-01 674,36 0,486 2,899E-01 3 1000000 882351 8,824E-01 743,05 0,594 3,545E-01 4 1331000 1173536 8,817E-01 600,44 0,977 5,834E-01 5 1728000 1542807 8,928E-01 927,37 0,832 4,966E-01 6 2197000 1946953 8,862E-01 1012,98 0,961 5,737E-01 7 2197000 1946953 8,862E-01 805,52 1,209 7,215E-01 8 2744000 2401000 8,750E-01 720,26 1,667 9,951E-01 9 3375000 2985983 8,847E-01 1164,36 1,282 7,655E-01

10 3375000 2985983 8,847E-01 1093,85 1,365 8,149E-01 11 4096000 3639467 8,885E-01 1128,45 1,613 9,628E-01 12 4096000 3639467 8,885E-01 1070,36 1,700 1,015E+00 13 4096000 3639467 8,885E-01 1037,94 1,753 1,047E+00

PARPAC

0,0000

0,2000

0,4000

0,6000

0,8000

1,0000

1,2000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

GFl

ops

Desempenho

Figura 30. Desempenho alcançado em Gflops.

O PARPAC também foi executado utilizando 1, 2 e 3 máquinas numa rede de 10 mbits. Os

resultados foram comparados com os resultados da execução na rede operando a 100 mbits (Figura

121

26). O comparativo de execução utilizando um nodo com a rede de 10 Mbits e de 100 Mbits estão

apresentados somente como referência, já que não há utilização da rede. Com estes resultados pode

se observar claramente o impacto da rede na execução do PARPAC.

PARPAC

0,00000,05000,10000,15000,20000,25000,30000,35000,4000

1 2 3Nodos

GFl

ops

Desempenho (10 Mbits)Desempenho (100 Mbits)

Figura 31. Comparativo do desempenho alcançado entre uma rede 10 e 100 Mbits.

Outro teste realizado com o cluster desenvolvido foi a de multiplicação de matrizes. Neste

teste foi calculado uma matriz quadrada de 3000 linhas. Para fim de teste, os dados populados

foram de 2 na matriz A e de 3 na matriz B. O resultado está apresentado no gráfico (Figura 27) a

seguir.


0

500

1000

1500

2000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

Segu

ndos

Tempo de execução

Figura 32. Resultados da multiplicação de matrizes.

122

Com os resultados obtidos na multiplicação de matrizes também foi calculado o speedup do

cluster, apresentados a seguir pelo gráfico na Figura 28. Neste gráfico pode ser notado o aumento de

desempenho e a queda após a inclusão do nono nodo no cluster.


0,0001,0002,0003,0004,0005,0006,0007,0008,000

1 2 3 4 5 6 7 8 9 10 11 12 13

Nodos

Spee

dup

Speedup

Figura 33. Speedup do cluster com a multiplicação de matrizes.

6. Conclusão

Este trabalho se propôs a construir disponibilizar um ambiente para processamento paralelo

escalável e de fácil inclusão e configuração, baseado em um cluster de PCs.

Foram encontradas diversas dificuldades durante a fase de desenvolvimento do cluster,

algumas facilmente contornadas e outras, as quais, mudaram a proposta inicial modelada, que era da

utilização de disquetes para inicializar dos nós escravos. Mesmo com estas alterações o objetivo

deste projeto foi alcançado.

A solução adotada com o Linux Kurumim permitiu mobilidade e portabilidade ao cluster,

preservando a integridade do ambiente existente.

Com a validação do cluster no laboratório de Ciência da Computação da UNIVALI pode se

observar o ganho de desempenho (speedup) e o impacto da rede no cluster utilizando o benchmarck

PARPAC, após uma série de tomadas de tempo durante as execuções. Rodando a aplicação de

123

multiplicação de matrizes, pode se observar o aumento do desempenho com a inclusão gradativa

das máquinas no cluster e a queda no desempenho após a inclusão de um determinado número de

máquinas.

Com o custo dos microcomputadores e dos equipamentos de rede cada vez menores e a

facilidade de comunicação entre máquinas, junto com a utilização do software livre foi possível

criar um cluster de baixo custo.

Para trabalhos futuros, sugere-se que seja montada uma forma de coleta de uso de cada nó

do cluster. Uma ferramenta que serve para este fim seria o CACTI. Esta ferramenta coleta as

informações de CPU, memória, disco e da rede através do protocolo SNMP e armazena num banco

de dados para futuras apresentações em gráficos por uma página web. Ela também permite a criação

de novos scripts para a coleta de informações personalizadas. O cluster desenvolvido já tem

configurado o serviço de SNMP, sendo necessário somente uma ferramenta que colete estes dados

durante a execução de uma aplicação que processe por um longo período de tempo.

Também para trabalhos futuros, sugere-se a inclusão de ferramentas de depuração, como o

XMPI, e ferramentas de programação paralela, como o PVM. Os benchmark LINPACK e o

LAPACK também poderiam ser incluídos para trabalhos futuros em cima de análise de desempenho

deste cluster.

7. Referências Bibliográficas

BUYYA, R. High Performance Cluster Computing: Architecture and Systems, vol 1. pags 3-45, New Jersey: Prentice Hall, 1999.

FRAUNHOFER. Institut Techno – und Wirtschaftsmatematik. . Disponível em: <http://www.itwm.fhg.de/en/sks__projects__sks_algorithms__parpac/parpac>. Acesso em maio 2005.

GOULART, Ademir. Avaliação de mecanismos de comunicação em grupo para ambiente WAN. 2002. 169 f. Dissertação (Mestrado) – Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis. 2002.

GUALEVE, J. A. F. Arquitetura de Computadores II. Disponível on-line na URL: <http://www.ucb.br/prg/professores/josef/ac3/Aula01-02.ppt>. Acessado em novembro de 2004.

JAIN, R. The Art of Computer System Performance Analysis. Techniques for Experimental Design, Measurement, Simulation, and Modeling. 1ª ed. Massachusetts: John Wiley & Sons, Inc. 1991. 685p.

124

LAPACK. Linear Algebra PACKage. Documento disponível on-line na URL: <http://www.netlib.org/lapack/> Acessado em novembro, 2004.

MPI-FORUM. Message Passing Interface Forum. Disponível on-line na URL: <http://www.mpi-forum.org/>. Acessado em abril de 2005.

OPENMP. OpenMP Architecture Review Board. Disponível em: <http://www.openmp.org/>. Acesso em novembro 2004.

PATTERSON, D. A.; HENNESSY, J. L. Organização e projeto de computadores. A interface HARDWARE/SOFTWARE. 2 ª ed. Rio de Janeiro, RJ. LTC – Livros Técnicos e Científicos Editora S.A. 2000. 550p.

RAUBER, Marcelo. Avaliação de Ferramentas de Gerenciamento de Sistemas Distribuídos. Universidade do Vale do Itajaí – UNIVALI, Itajaí – SC, 2003.

ROSE, C. A. F.; NAVAUX, P. O. A. Fundamentos de Processamento de Alto desempenho. ERADE 2002. São Leopoldo, RS. Editora Sagra Luzzatto. Jan. 2003.

SCALAPACK. The ScaLAPACK Project. Documento disponível on-line na URL: <http://www.netlib.org/scalapack/> Acessado em novembro, 2004.

STERLING, T. Beowulf Cluster Computing with Linux. The MIT Press, 2002. 496 p.

TANENBAUM, A. S. Sistemas Operacionais Modernos, Rio de Janeiro: Prentice-Hall do Brasil Ltda, 1995.

ZELENOVSKY, R.; MENDONÇA A. Processadores para o próximo milênio. Disponível em: < http://www.clubedohardware.com.br/milenio2.html >. Acesso em novembro 2004.

Documents

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Sidnei Baron[1].pdf · UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E