UNIVERSIDADE FEDERAL DO RIO GRANDE - FURG

CENTRO DE CIÊNCIAS COMPUTACIONAIS

CURSO BACHAREL EM ENGENHARIA DE COMPUTAÇÃO

Configuração e Análise de Desempenho de um Aglomerado

Computacional do tipo Beowulf

Daniel Dias da Silva

Orientador: Prof. Dr. Odorico Machado Mendizabal.

Rio Grande, 2017

 UNIVERSIDADE FEDERAL DO RIO GRANDE - FURG
CENTRO DE CIÊNCIAS COMPUTACIONAIS
CURSO BACHAREL EM ENGENHARIA DE COMPUTAÇÃO

Configuração e Análise de Desempenho de um Aglomerado

Computacional do tipo Beowulf

Daniel Dias da Silva

Monografia apresentada ao curso de

Engenharia de Computação da Uni-
versidade Federal do Rio Grande -
FURG, como requisito parcial para a
para obtenção do Grau de Engenheiro de
Computação.

Orientador: Prof. Dr. Odorico Machado Mendizabal.

Rio Grande, 2017

"A felicidade só é real quando compartilhada"
Christopher McCandless
 Resumo

Devido à crescente demanda por processamento e armazenamento de grandes volumes de dados,

faz-se necessário o processamento paralelo em sistemas de alto desempenho. Baseado neste as-
pecto, este trabalho teve como objetivo montar, configurar e gerenciar um cluster do tipo Beowulf
em plataforma Linux, e analisar o desempenho dessa infraestrutura. A topologia implementada foi
voltada para o alto desempenho e um conjunto de boas práticas foi observado. Para teste de desem-
penho foram utilizados o ordenamento de vetores Bubble Sort e o benchmark HPL. Os resultados
do trabalho incluem a revisão bibliográfica sobre o tema, a documentação e criação em produção
do cluster educacional do C3 da FURG, a criação de manual de instalação e configuração do clus-
ter, a identificação de boas práticas de construção de clusters, além da analise de desempenho. As
métricas de avaliação tiveram como resultado o tempo de execução de ordenamento de vetores e
a capacidade de processamento de ponto flutuante no HPL, que permitiu observar como o sistema
escala com acréscimo de nodos de processamento.

Palavras-Chaves: aglomerado, cluster, HPL, MPI, Rocks Cluster, Beowulf.

 Abstract

Due to the increasing demand for processing and storing large volume of data, parallel processing
in high performance computing systems becomes necessary. Based on this aspect,the present study
aimed to assemble, configure and manage a cluster Beowulf type on Linux platforms. The imple-
mented topology was focused on high performance and a set of best practices. Benchmarks such
as HPL were used for performance testing. The benchmark which implements a matrix program
that solves a system of dense linear equations in double precision arithmetic.The results obtained
allowed to observe how the system scales with the addition of processing nodes.

Keywords: aglomerado, cluster, HPL, MPI, Rocks Cluster, Beowulf.

Sumário

Lista de Figuras iv

Lista de Tabelas vi

1 Introdução 1
1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Arquiteturas Paralelas 4
2.1 Taxonomia de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Classificação Segundo Processadores e Compartilhamento de Memória Principal . 5
2.2.1 Multiprocessadores e Sistemas Multiprocessados . . . . . . . . . . . . . . 6
2.2.2 Multicomputadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Interfaces de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Classificação de Arquiteturas Paralelas Quanto ao Barramento . . . . . . . . . . . 13
2.4.1 Processadores Vetoriais Paralelos (PVP) . . . . . . . . . . . . . . . . . . . 13
2.4.2 Multiprocessadores Simétricos (SMP) . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Máquinas Massivamente Paralelas (MPP) . . . . . . . . . . . . . . . . . . 14
2.4.4 Máquinas com Memória Compartilhada Distribuída (DSM) . . . . . . . . 14
2.4.5 Redes de Estações de Trabalho (NOW) . . . . . . . . . . . . . . . . . . . 14
2.4.6 Máquinas agregadas (COW) . . . . . . . . . . . . . . . . . . . . . . . . . 15

i
 2.4.7 Redes de Interconexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Aglomerados Computacionais 17
3.1 Tipos de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Cluster de Alto Desempenho - High Performance Computing (HPC) . . . . 18
3.1.2 Cluster de Alta Disponibilidade - High Availability Computing (HAC) . . . 18
3.1.3 Cluster de Balanceamento de Carga - Load Balancing . . . . . . . . . . . 19
3.2 Soluções em Softares para Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 MOSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 OpenSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Kerrighed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Aglomerados BEOWULF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Implementação de um Cluster Beowulf 24

4.1 Rocks Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Hardware Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Infraestrutura da Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Software Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Instalação do Sistema Rocks Cluster . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Message Passing Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Sistema de compartilhamento NFS . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Análise de Desempenho 34
5.1 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1 Ordenamento de Vetores . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Speedup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.3 Benchmark HPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Resultados do Ordenamento de Vetor . . . . . . . . . . . . . . . . . . . . 38

ii
 5.2.2 Resultados HPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Conclusão 44

Referências Bibliográficas 46

A Tutorial de Configuração Rocks Cluster 48

A.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

B Arquivo de Configuração do HPL 58

C Arquivo Contendo o hostname do nodos 64

D Bubble Sort Paralelo 65

E Bubble Sort Sequencial 70

F Script NFS 73

G Arquivo replace-partition.xml 74

H Arquivo grub 78

iii
Lista de Figuras

2.1 Memória compartilhada em uma arquitetura de multiprocessadores (ROSE; NA-

VAUX, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Memória compartilhada centralizada (ROSE; NAVAUX, 2004). . . . . . . . . . . . 7
2.3 Memória compartilhada distribuída (ROSE; NAVAUX, 2004). . . . . . . . . . . . 8
2.4 Memória compartilhada estruturada em cache (ROSE; NAVAUX, 2004). . . . . . . 9
2.5 Memória compartilhada em uma arquitetura de multicomputadores (ROSE; NA-
VAUX, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Visão geral da classificação segundo o compartilhamento de memória de máquinas
MIMD (ROSE; NAVAUX, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Exemplares de interface de rede InfiniBand (NETWORK, 2017) (DATANAMI,
2017). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Exemplar de placa switch Myrinet (HEALTH, 2017). . . . . . . . . . . . . . . . . 12
2.9 Arquitetura NOW (ROSE; NAVAUX, 2004). . . . . . . . . . . . . . . . . . . . . . 15

3.1 Exemplo de um cluster do tipo Beowulf (ALECRIM, 2013). . . . . . . . . . . . . 22

4.1 Estrutura física do cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Estrutura de ligação entre o sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Arquitetura NFS (JONES, 2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Tempo de Execução Bubble sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Speedup Ordenamento de Vetor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv
5.3 Execução HPL com N=15000 em função do tempo. . . . . . . . . . . . . . . . . . 41
5.4 Execução HPL com N=15000 em função de GFlops. . . . . . . . . . . . . . . . . 42
5.5 Execução HPL com N variável. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A.1 Logo Rocks Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.2 Tela inicial do Anaconda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.3 Tela de seleção das ferramentas disponibilizadas. . . . . . . . . . . . . . . . . . . 51
A.4 Tela de para preenchimento de dados do cluster. . . . . . . . . . . . . . . . . . . . 52
A.5 Tela de configuração de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.6 Utilitário kickstart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.7 Tela de reconhecimento do MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.8 Carregamento da imagem de instalação. . . . . . . . . . . . . . . . . . . . . . . . 56
A.9 Instalação do Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

v
Lista de Tabelas

2.1 Relação entre instruções e dados na taxonomia de Flynn. . . . . . . . . . . . . . . 5

4.1 Especificações dos nodos do cluster. . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Resultados do Ordenamento da Matriz 600 x 5000. . . . . . . . . . . . . . . . . . 39

5.2 Resultados do HPL para uma matriz de tamanho fixo. . . . . . . . . . . . . . . . . 41
5.3 Resultados do HPL para uma matriz de tamanho variável. . . . . . . . . . . . . . . 41

vi
 Lista de Abreviaturas
API Application Programming Interface
C3 Centro de Ciências Computacionais
CC-NUMA Cache-Coherence Non-Uniform Memory Acess
COMA Cache-Only Memory Architecture
COW Cluster of Workstations
CPAN Comprehensive Perl Archive Network
CPU Central Processing Unit
CRT Cathodic Ray Tube
CSMA/CD Carrier Sense Multiple Access with Collision Detection
DSM Distributed Shared Memory
FURG Fundação Universidade Federal do Rio Grande
HAC High Availability Computing
HD Hard Disk
HPC High Performance Computing
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
MAC Media Access Control
MI Multiple Instruction
MIMD Multiple Instruction Multiple Data
MISD Multiple Instruction Single Data
MOSIX Multicomputer Operating System for Unix
MPI Message Passing Interface
MPP Massively Parallel Processors
NCC-NUMA Non-Cache-Coherent Non Uniform Memory Acess
NFS Network File System
NORMA Non-Remote Memory Access
NOW Network of Workstations
NUMA Non-Uniform Memory Access
OPENMPI Open source Message Passing Interface
PVM Parallel Virtual Machine
PVP Parallel Vector Processors
RPC Remote Procedure Call
SC-NUMA Software-Coherence Non-Uniform Memory Acess
SI Single Instruction
SIMD Single Instruction Multiple Data
SISD Single Instruction Single Data
SMP Symmetric Multiprocessors
SSI Single System Image
UMA Uniform Memory Access
XDR eXternal Data Representation

vii
Capítulo 1

Introdução

Na era da informação, a qual vivemos, percebe-se a necessidade de processar e armazenar um

grande volume de dados e informações. O campo de aplicações que demandam manipulação e
processamento intenso de dados é amplo. Por exemplo, pode-se citar as seguintes áreas: mete-
orologia (FOURNIER; TAYLOR; TRIBBIA, 2004), astrofísica (FONSECA et al., 2008), mode-
lagem computacional, otimização, pesquisa operacional, biotecnologia (SCHATZ; LANGMEAD;
SALZBERG, 2010), simulações de mercado financeiro (ROCHA; MACHADO, 2011), tratamento
de imagens, inteligência artificial (SANTOS et al., 2010), jogos e renderização de efeitos visuais
para o cinema.
Devido a grande demanda por processamento de alto desempenho, surgem algumas alternativas,
como a adoção de computadores com alta capacidade de processamento. Por exemplo, centros de
processamento de dados podem adotar em suas infraestruturas supercomputadores com múltiplos
núcleos de processamento, capazes de processar e executar quantias elevadas de dados em paralelo,
reduzindo o tempo de execução de tarefas complexas. No entanto, a construção e aquisição desses
tipos de equipamento torna-se muito custoso (SPAINHOWER; GREGG, 1999).
Diante desse desafio, no final de 1993, Donald Becker e Thomas Sterling, funcionários da
NASA1 , iniciaram o projeto de um sistema de processamento distribuído construído a partir de
hardware convencional, como uma medida de combate aos custosos supercomputadores da época.
1 NASA (National Aeronautics and Space Administration) agência aeroespacial dos Estados Unidos da América

1
Então no início de 1994, criaram o primeiro aglomerado computacional (cluster2 ), batizando o
projeto com o nome Beowulf 3 (BECKER et al., 1995). O protótipo inicial era um cluster de 16
processadores DX4 ligados por dois canais Ethernet acoplados (Ethernet bonding).
Os clusters Beowulf popularizaram-se por utilizar hardware de uso doméstico, com baixo custo,
os chamados “of-the-shelf ” - direto das prateleiras (TONIDANTEL, 2008). De forma geral, Be-
owulf caracteriza-se ainda por utilizar sistemas Linux, bibliotecas de código aberto de troca de
mensagem, como o MPI.
Um cluster pode ser definido como um conjunto de computadores interconectados através de
uma mesma rede, apresentando-se para o usuário como um único sistema, e que possui o intuito
de executar e processar tarefas em paralelo. Para permitir a comunicação entre processos em um
cluster, os nós são interconectados por uma interface de rede. Cada computador que faz parte
do cluster recebe o nome de nó (ou nodo). Geralmente existe um nó denominado mestre, que é
responsável pelo gerenciamento dos demais.
Para este trabalho, foi desenvolvido uma topologia voltada para o alto desempenho em um
cluster Beowulf com plataforma linux.
Um dos objetivos do trabalho foi identificar boas práticas comuns para a configuração de cluster
do tipo Beowulf, através de estudos de construção de cluster e com experiências adquiridas no
desenvolvimento de topologias.
Os resultados obtidos incluem a revisão bibliográfica sobre o tema, a documentação e criação
em produção do cluster educacional do C3 da FURG, a criação de manual de instalação e con-
figuração do cluster, a identificação de boas práticas de construção de clusters, além da analise
de desempenho com a utilização de ordenamento de vetores com a técnica Bubble Sort, e com o
benchmark HPL. Com análise dos resultados de desempenho obtidos foi possível observar a esca-
labilidade do cluster.
2 Devido a popularização do termo cluster na área de computação de alto desempenho, os termos aglomerado
computacional e cluster são utilizados como sinônimos neste manuscrito.
3 Referência ao poema épico anglo-saxã, passado na Escandinávia. Conta a história de um guerreiro que luta sozinho

contra feras bestiais.

2
1.1 Metodologia

Para o desenvolvimento desse trabalho foi utilizado um um conjunto de máquinas com uma
infraestrutura para construção de cluster, disponibilizado pelo Centro de Ciências Computacionais
(C3) da FURG.
O sistema utilizado escolhido foi toolkit Rocks Cluster para configurações das máquinas. O
Rocks Cluster é um conjunto de ferramentas que auxiliam na configuração e gerenciamento de
clusters.
Algoritmos de ordenamento de vetores foram desenvolvidos com o intuito de validar o funcio-
namento do cluster.
Para análise de desempenho, configurações específicas foram realizadas e submetidas a teste de
carga com o ordenamento de vetores Bubble sort e benchmark HPL. O funcionamento do algoritmo
Bubble sort tem como princípio o método por força-bruta, ele percorre diversas vezes um vetor, e
a cada passagem armazena em uma variável o elemento de maior valor da sequência. O HPL é um
programa matricial que resolve um sistema de equações lineares densas, geradas aleatoriamente,
em aritmética de precisão dupla (64 bits) (SILVA et al., 2004).

1.2 Estrutura do Trabalho

Para realizar o trabalho, foi feito um levantamento bibliográfico apresentado no Capítulo 2 ,

visando compreender arquiteturas e técnicas associadas à computação paralela. No Capítulo 3, são
descritos o funcionamento e alguns tipos de estruturas de cluster encontrados no mercado. É apre-
sentado no Capítulo 4, a implementação e instalação do cluster do tipo Beowulf na infraestrutura
disponibilizada. No Capítulo 5 são descritos os benchmarks utilizados para teste de desempenho,
e os dados coletados para análise. Por fim, no Capítulo 6 são feitas as considerações finais. O
anexo A relata, na forma de tutorial a instalação do Rocks Cluster. Os códigos utilizados para
configurações e teste de funcionalidade, aparecem nos anexos B à E.

3
Capítulo 2

Arquiteturas Paralelas

Com o avanço da microeletrônica, e a construção de transistores cada vez menores, na casa

dos 40, 35 nanômetros (caso de comparação, o diâmetro de um fio de cabelo possui em média
30 mil nanômetros), os engenheiros começaram a projetar vários núcleos em uma mesma pastilha
do processador. Além disso, a significante latência de comunicação entre computadores em rede
também viabiliza a distribuição de tarefas em um sistema distribuído para execução em arquiteturas
paralelas.
O paralelismo computacional pode ser definido pela execução de múltiplas instruções em pa-
ralelo ou pela manipulação de múltiplos dados paralelamente. Neste capítulo são apresentados
diferentes formas de paralelismo, de instruções de dados, e arquiteturas paralelas

2.1 Taxonomia de Flynn

A taxonomia de Flynn (FLYNN, 1972) apud (ROSE; NAVAUX, 2004) descreve com maior
detalhamento os aspectos do paralelismo computacional. Apesar de ter sua origem nos anos 70, é
ainda válida e usual. Baseando-se em dois aspectos, sequência de instruções e sequência de dados.
Através da combinação das possibilidades, Flynn propôs quatro classes, apresentado na Tabela 2.1
(ROSE; NAVAUX, 2004).
Na categoria SISD (Single Instruction Single Data) um único fluxo de instrução atua sobre um

4
 Tabela 2.1: Relação entre instruções e dados na taxonomia de Flynn.

SD (Único Dado) MD (Múltiplos Dados)

SI (Única Instrução) SISD SIMD
MI (Múltiplas Instruções) MISD MIMD

único fluxo de dados. Nessa classe, enquadram-se máquinas de Von Neumann tradicionais com
apenas um processador.
Na categoria MISD (Multiple Instruction Single Data), múltiplos fluxos de instruções atuariam
sobre um único fluxo de dados. Na prática, diferentes instruções operariam na mesma posição de
memória simultaneamente, executando instruções diferentes. Essa classe é considerada vazia, por
não possuir aplicação prática (HOCKNEY, 1988) apud (ROSE; NAVAUX, 2004).
Nas máquinas paralelas SIMD (Single Instruction Multiple Data), uma única instrução é execu-
tada em um conjunto de dados. Os processadores executam suas instruções de forma paralela sobre
diferentes fluxos de dados, a partir de uma única unidade de controle. É importante ressaltar que,
para que o processamento das diferentes posições de memória possa ocorrer em paralelo, a unidade
de memória não pode ser implementada como um único módulo de memória, o que permitiria só
uma operação por vez. Nessa classe, são enquadradas as máquinas vetoriais (ROSE; NAVAUX,
2004).
Já nas máquinas MIMD (Multiple Instruction Multiple Data) cada processador executa seu
programas sobre seus próprios fluxos de dados. Neste caso enquadram-se servidores com múltiplos
processadores e estações de trabalho com múltiplos computadores interligados (clusters).

2.2 Classificação Segundo Processadores e Compartilhamento

de Memória Principal

Pode-se distinguir máquinas MIMD em sistemas multiprocessados, sistemas com multiproces-

sadores e sistemas com multicomputadores. Nos sistemas multiprocessados, trata-se de dois ou
mais núcleos de processamento em uma única pastilha de silício ou vários processadores inde-

5
pendentes em um mesmo computador, enquanto sistemas com multicomputadores compostos por
vários computadores interconectados, podendo estes ser multiprocessados.
Outro critério para a classificação de máquinas paralelas MIMD é de acordo com o comparti-
lhamento da memória. Em sistemas com memória compartilhada (shared memory) existe um único
espaço de endereçamento, que será usado de forma implícita para comunicação entre processado-
res, com primitivas operações de load e store (ROSE; NAVAUX, 2004).
A memória distribuída (distributed memory), refere-se à localização física da memória. Se a
memória é implementada com vários módulos, e cada módulo foi colocado próximo de um proces-
sador, então a memória é considerada distribuída (ROSE; NAVAUX, 2004). Sistemas com memória
distribuidas utilizam o paradigma de troca de mensagens (message passing), com o uso de primiti-
vas send e receive.

2.2.1 Multiprocessadores e Sistemas Multiprocessados

Os processadores acessam, através de uma rede de interconexão (barramento), uma memória

compartilhada. Esse tipo de máquina possui apenas um espaço de endereçamento, de forma que
todos os processadores são capazes de endereçar todas as memórias, conforme mostra a Figura
2.1. A comunicação entre processos é feita através da memória compartilhada de forma bastante
eficiente com operações do tipo load e store (ROSE; NAVAUX, 2004).

Figura 2.1: Memória compartilhada em uma arquitetura de multiprocessadores (ROSE; NAVAUX,

2004).

6
Conforme o acesso a memória, os sistemas podem ser classificados:

• UMA (Uniform Memory Access): Multiprocessadores são interconectados por meio de um

barramento (ver Figura 2.2), acessando uma memória global com tempo de acesso uniforme
(mesma latência). Outras máquinas com outras redes de interconexão e com memórias entre-
laçadas (implementadas com múltiplos módulos e, dessa forma, permitindo acesso paralelo a
diferentes módulos) também se enquadram nessa categoria se mantiverem o tempo de acesso
à memória uniforme para todos os processadores do sistema (HWANG, 1993) apud (ROSE;
NAVAUX, 2004).

Figura 2.2: Memória compartilhada centralizada (ROSE; NAVAUX, 2004).

Para reduzir o tráfego na rede e amenizar a diferença de velocidade entre o processador e a

memória principal, esses processadores são dotados de memória cache (ROSE; NAVAUX,
2004). Cada processador mantém uma cópia da última consulta feita na memória principal,
na cache. Utiliza-se esse artifício a fim de acelerar a busca por dados ou instruções e au-
mentar o desempenho do sistema, já que a memória cache está na mesma pastilha da CPU,
operando em frequência maior que a memória principal, o que torna seu acesso muito mais
rápido. Como todos os processadores podem endereçar toda a memória do sistema, em um
determinado momento, várias cópias da mesma posição da memória principal podem existir
em caches diferentes. Isso é um problema que precisa ser tratado, pois um processador pode
trabalhar com sua cópia local, e essa pode não refletir mais o estado atual da mesma posição

7
 na memória principal. Esse problema é chamado de coerência de cache (cache coherence)
(CULLER; SINGH; GUPTA, 1999) apud (ROSE; NAVAUX, 2004) e a maioria dos mul-
tiprocessadores UMA implementa protocolos de coerência de cache em hardware (ROSE;
NAVAUX, 2004).

• NUMA (Non-Uniform Memory Access): Cada processador possui uma memória local, a
qual é agregada ao espaço de endereçamento global da máquina (ver Figura 2.3). Cada
processador tem acesso com menor latência ao módulo de memória a si destinado, porém um
processador pode acessar um endereço de memória que faça parte do módulo de memória de
outro processador através de uma interconexão ou barramento.

Figura 2.3: Memória compartilhada distribuída (ROSE; NAVAUX, 2004).

Em virtude da coerência de cache, esse grupo de máquinas ainda pode ser subdividido em:

- NCC-NUMA (Non-Cache-Coherent Non Uniform Memory Acess): acesso não uni-

forme à memória e sem coerência de cache.

- CC-NUMA (Cache-Coherence Non-Uniform Memory Acess): acesso não uniforme

à memória, com coerência de cache implementado em hardware.

- SC-NUMA (Software-Coherence Non-Uniform Memory Acess): acesso não uni-

forme à memória com coerência de cache implementado em software.

- COMA (Cache-Only Memory Architecture): Máquinas COMA (ver Figura 2.4), cons-
tituem um caso particular das arquiteturas NUMA, onde as memórias locais dos processado-

8
 res são convertidas em caches. Todas as caches formam o espaço de endereçamento global
e o acesso às caches remotas é auxiliado por meio de diretórios distribuídos. A memória
principal dessas máquinas é composta pelas caches COMA e o hardware de suporte tem que
integrar a gerência das cache e a gerência de memória (ROSE; NAVAUX, 2004).

Figura 2.4: Memória compartilhada estruturada em cache (ROSE; NAVAUX, 2004).

2.2.2 Multicomputadores

Nos multicomputadores, cada processador possui uma memória local à qual só ele tem acesso.
As memórias dos outros processadores são consideradas memórias remotas e possuem espaços de
endereçamento distintos. Como não é possível o uso de variáveis compartilhadas nesse ambiente,
as trocas de informações entre processos é feita por envio de troca de mensagens pela interface de
rede, servindo de barramento, como mostra a Figura 2.5 (ROSE; NAVAUX, 2004).
Em relação ao tipo de acesso às memórias do sistema, multicomputadores podem ser classifi-
cados como:

• NORMA (Non-Remote Memory Access): sem acesso a variáveis remotas. Os registradores

de endereçamento de cada nó só conseguem endereçar a sua memória local.

9
Figura 2.5: Memória compartilhada em uma arquitetura de multicomputadores (ROSE; NAVAUX,
2004).

Na Figura 2.6 é apresentado um resumo das máquinas MIMD conforme o compartilhamento

de memória.

Figura 2.6: Visão geral da classificação segundo o compartilhamento de memória de máquinas

MIMD (ROSE; NAVAUX, 2004).

Os cluster do tipo Beowulf, objetivo de estudo deste trabalho, são classificados como máquinas
MIMD do tipo NORMA, pois possuem multiprocessadores com capacidade de endereçamento
somente para memória local de cada nó.

2.3 Interfaces de Rede

Em sistemas aglomerados, a interface de comunicação de rede exerce o papel do barramento,

interconectando nodos distribuídos. Por isso, no projeto de estruturação de um cluster, a interface
de rede será responsável pela taxa de vazão de dados.

10
 Os padrões Ethernet (Gigabit Ethernet, Fast Ethernet) são de uso comum e baixo custo, porém
de desempenho inferior, que os protocolos destinados a baixa latência, como Myrinet e InfiniBand.

• Ethernet: a família Ethernet como um todo limita o tamanho de carga do quadro a 1500
bytes. Gigabit Ethernet (1000 Mbps) é uma extensão dos padrões de rede Ethernet (10
Mbps) e Fast Ethernet (100 Mbps), tendo sido padronizado em junho de 1998 pelo IEEE
(Institute of Electrical and Electronics Engineers).

A interface utiliza o protocolo CSMA/CD 1 para controlar o acesso ao meio, onde apenas um
computador pode transmitir por vez. Essa compatibilidade permite uma transição gradual de
redes da família Ethernet.

Conforme definido no padrão IEEE 802.3x, dois nós conectados por um caminho full-duplex2
podem simultaneamente enviar e receber pacotes. Para operar no modo half-duplex3 , utiliza-
se uma versão aprimorada do protocolo CSMA/CD. Quando operado no padrão full-duplex,
utiliza-se buffers para armazenar os quadros que chegam a interface ou que são enviados
(BARCELLOS; GASPARY, 2006).

O desempenho de redes Ethernet é comprometido pelo uso do protocolo CSMA/CD, que

é sensível ao tamanho do quadro. Os meios de transmissão podem ser por fibra ótica, par
trançado ou cabo coaxial.

• InfiniBand: é uma interface de rede apoiada por fabricantes como Intel, IBM, Sun, HP e Mi-
crosoft, e que especifica uma arquitetura de hardware para interligação de alto desempenho
(BARCELLOS; GASPARY, 2006).

O InfiniBand é um barramento serial que pode oferecer até 2.5 Gigabits por segundo, por
par de cabos, onde um envia e outro recebe dados (full duplex). Como a comunicação é
1 Carrier Sense Medium Acess with Collision Detection.
2 fullduplex, ou apenas duplex, comunicação onde transmissor e receptador transmitem dados simultaneamente em
ambos os sentidos (bidirecional).
3 half-duplex, ou semi-duplex, comunicação onde transmissor e receptor transmitem dados em ambos os sentidos,

porém não simultaneamente.

11
 bidirecional, contabiliza-se um total de 5 Gigabits de transmissão de dados no barramento
(MORIMOTO, 2005). Na Figura 2.7 vemos exemplares desse tipo de interface de rede.

Figura 2.7: Exemplares de interface de rede InfiniBand (NETWORK, 2017) (DATANAMI, 2017).

• Myrinet: é uma tecnologia de rede comutada, de alta velocidade, de propriedade original da

empresa Myricom, adquirida pela empresa CSPI 4 . O padrão Myrinet (BODEN et al., 1995) é
definido no nível de enlace e caracteriza-se por possuir pacotes de tamanho variável, controle
de erro e de fluxo em cada canal, e estações com interfaces programáveis. Myrinet tam-
bém utiliza canais full-duplex, atingindo teóricos 2 + 2 Gbps de transmissão (BARCELLOS;
GASPARY, 2006).

Sendo tecnologia proprietária, torna-se difícil a integração com outras tecnologias de interli-
gação disponíveis, além de possuir custo elevado se comparada com Gigabit Ethernet. A API
oferecida pelo fabricante proporciona baixa latência e alta vazão (BARCELLOS; GASPARY,
2006). A Figura 2.8 mostra um exemplo de interface de rede Myrinet.

Figura 2.8: Exemplar de placa switch Myrinet (HEALTH, 2017).

4 <http://www.cspi.com>

12
2.4 Classificação de Arquiteturas Paralelas Quanto ao Barra-

mento

A seguir são apresentados modelos de máquinas paralelas, baseado em máquinas MIMD da

classificação de Flynn.

2.4.1 Processadores Vetoriais Paralelos (PVP)

Processadores vetoriais paralelos (PVP - Parallel Vector Processors) são máquinas constituídas
de processadores vetoriais. A interconexão entre os processadores e a memória é feita por um
barramento que utiliza uma matriz de chaveamento chamada de crossbar. Processadores vetoriais
implementam um conjunto de instruções, ao invés de processos individuais como em máquinas
convencionais (ROSE; NAVAUX, 2004).
A comunicação entre os processadores é feita através da memória compartilhada, que possui
apenas um espaço de endereçamento englobando todos os módulos de memória. O tempo de acesso
à memória compartilhada é uniforme, o que caracteriza essas máquinas como multiprocessadores
UMA. Esse tipo de máquina normalmente não se utiliza de memórias cache, usando para essa
função um grande número de registradores vetoriais e um buffer de instrução (ROSE; NAVAUX,
2004).

2.4.2 Multiprocessadores Simétricos (SMP)

Multiprocessadores simétricos (SMP - Symmetric Multiprocessors) são máquinas constituídas

por processadores comerciais comuns, conectados a uma memória compartilhada comum. O nome
simétrico vem do fato que todos os processadores possuem igual acesso ao barramento e a memória,
sem privilégios a nenhum dos processadores. Esse sistema caracteriza-se como sendo máquina
UMA, por possuir acesso a memória compartilhada (ROSE; NAVAUX, 2004).
A escalabilidade desse sistema é comprometida pelo barramento ser usado como rede de inter-
conexão. O barramento impede a implementação de um numeroso conjunto de processadores por

13
permitir somente uma transação no canal de comunicação.

2.4.3 Máquinas Massivamente Paralelas (MPP)

Máquinas maciçamente paralelas (MPP - Massively Parallel Processors) são multicomputado-

res construídos com vários processadores comerciais, conectados por uma rede particular de alta
velocidade. São uma alternativa as máquinas PVP’s por possuírem baixo custo, suportam vários
processadores, sendo altamente escaláveis (onde surge a expressão maciçamente). Cada processa-
dor possui acesso a sua própria memória, não sendo possível acessar a memória vinculada a outro
processador. Utiliza o paradigma de troca de mensagens para comunicação entre os processos
(ROSE; NAVAUX, 2004).

2.4.4 Máquinas com Memória Compartilhada Distribuída (DSM)

Máquinas com memória compartilhada distribuída (DSM – Distributed Shared Memory) são
sistemas que apresentam memória fisicamente distribuída e acessível a todos os processadores,
sendo estes capazes de endereçar todas as memórias do sistema. A distribuição da memória, por sua
vez, pode ser resultado da escolha de uma arquitetura multiprocessada com memória entrelaçada
distribuída (máquinas NUMA) ou de uma arquitetura de multicomputador com memórias locais
(máquina NORMA). Em ambos os casos, a máquina resultante é considerada CC-NUMA se tiver
coerência de cache implementada em hardware ou SC-NUMA se a implementação for em software
(ROSE; NAVAUX, 2004).

2.4.5 Redes de Estações de Trabalho (NOW)

Redes de estações de trabalho (NOW - Network of Workstations) são sistemas baseados em

máquinas NORMA, constituídas por várias estações de trabalho interligadas por tecnologia tradi-
cional de interface de rede Ethernet. Geralmente máquinas dessa classe já possuem uma rede pré
existente, o que torna suas construção de baixo custo (ROSE; NAVAUX, 2004).

14
 NOW (ver Figura 2.9) é caracterizada por possuir um disco local nos nós. Seus nós podem ser
utilizados como propósito geral. Um usuário pode utilizar uma estação de trabalho, ou nó, para uso
pessoal, como uso de web, editor de texto, compartilhamento de arquivos, uso de periféricos etc.,
enquanto ao mesmo tempo este mesmo nó faz parte da rede de processamento paralelo.

Figura 2.9: Arquitetura NOW (ROSE; NAVAUX, 2004).

Na prática, máquinas NOW são empregadas em ambientes de ensino de processamento paralelo

e distribuído, ou na execução de aplicações que demandam pouca comunicação entre os nós, isto
devido ao seu baixo desempenho.

2.4.6 Máquinas agregadas (COW)

Máquinas Agregadas (COW - Cluster of Workstations), são semelhantes as Máquinas NOW,

porém máquinas COW são construídas para uso dedicado de processamento paralelo. Podemos
aqui dar como exemplo os clusters Beowulf. Os nós são otimizados para esse fim, e na maioria
dos casos, os hosts que servem como nós não possuem monitor, teclado e mouse, sendo denomi-
nados estações de trabalho “sem cabeça” (headless workstations), ou também chamado de “pilha
de computadores pessoais” (Pile-of-PC’s). As principais otimizações são feitas em software, e

15
pode-se então dizer que as máquinas COW são máquinas NOW construídas de modo dedicado,
aproveitando o baixo custo do sistema NOW (ROSE; NAVAUX, 2004).

2.4.7 Redes de Interconexão

A interconexão entre os processadores não pode ser feita de forma direta. Deve-se ser levado
em conta um padrão para a construção das redes de interconexão. A forma como os processadores
de uma arquitetura são ligados entre si pode ser denominado como topologia de rede. Dentro da
topologia de rede destacam-se três características:

• largura de Banda: quantidade de tráfego de mensagens que a rede de comunicação suporta.

• Diâmetro: distância máxima entre dois hosts quaisquer. Indica qual o menor número de hosts
intermediários que precisam serem envolvidos para que dois processadores se comuniquem.
Quanto menor o diâmetro, melhor desempenho para o aglomerado.

• Grau: número de ligações de cada host da rede. Pode ser entendido como o número má-
ximo de rotas possíveis entre qualquer par de nós do cluster. Também pode ser chamado de
conectividade.

Pode-se dividir a topologia de redes em dois grandes grupos: estática e dinâmica.

As redes estáticas são caracterizadas por possuírem ligações diretas e fixas (ponto-a-ponto).
Redes do tipo estática são comumente usadas em multicomputadores, ou aglomerados, onde o
roteamento das mensagens transferidas são de ordem menos complexa.
Redes dinâmicas permitem conexões feitas por demanda. Não existe ligações fixas entre os
hosts. Quando uma conexão entre dois hosts faz-se necessário, a rede de interconexões adapta-se
dinamicamente (ROSE; NAVAUX, 2004).

16
Capítulo 3

Aglomerados Computacionais

Os clusters podem ser classificados de acordo com o seu hardware e sistema operacional em
dois tipos: cluster heterogêneo e homogêneo. Um cluster heterogêneo possui diferentes tipos de
hardware entre seus nós e ou diferentes tipos de interface de comunicação de rede. Já clusters
homogêneos possuem hardware e interface de rede idêntico entre os nós que o compõe.
Os nós dos clusters podem ser máquinas construídas especificadamente para compor cluster
(máquinas dedicadas), ou pode-se também utilizar máquinas “convencionais” como os desktops.
Do ponto de vista do software, o sistema operacional dos nós, deve ser o mesmo, afim de di-
minuir a complexidade de configuração e manutenção do sistema, e garantir que os procedimentos
rotineiros ao cluster, como monitorização, distribuição de tarefas e controle de recursos sejam exe-
cutados de maneira uniforme. Um exemplo que reforça estes aspectos, são sistemas operacionais
preparados especialmente para a montagem de clusters (ALECRIM, 2013).
A comunicação entre os nós é feita a partir da tecnologia de interface de rede. Os padrões
Ethernet (Gigabit Ethernet, Fast Ethernet) são bastante utilizados justamente por serem mais co-
muns e menos custosos, porém com desempenho inferior. Mas há outras opções viáveis, como o
Myrinet e o InfiniBand, ambos com características bastante apropriadas para aglomerados de alto
desempenho.

17
3.1 Tipos de Cluster

Os clusters podem ser diferenciados e classificados, de modo geral, em três grupos: Cluster de
Alto Desempenho, Cluster de Alta Disponibilidade, Cluster de Balanceamento de Carga.

3.1.1 Cluster de Alto Desempenho - High Performance Computing (HPC)

Clusters de alto desempenho são direcionados a aplicações bastante exigentes no que diz res-
peito ao processamento. Sistemas utilizados em computação científicas, por exemplo, podem se be-
neficiar deste tipo de cluster por necessitarem analisar uma grande variedade de dados rapidamente
e realizar cálculos bastante complexos (ALECRIM, 2013). Uma grande tarefa computacional pode
ser dividida em pequenas tarefas que são distribuídas entre nodos de processamento, como se fosse
um supercomputador massivamente paralelo.
Outras características são importantes na concepção de aglomerados de alto desempenho:

• Escalabilidade: possibilidade de acréscimo de dispositivos, ou hosts, sem a necessidade de

grandes alterações nas configurações do cluster e da rede;

• Desempenho: está relacionado com as distâncias entre os hosts, envolvendo largura de banda
(taxa de transferência de bytes por pulso de clock), latência, sobrecarga da CPU;

• Custo: relação entre desempenho e número de hosts existentes;

• Confiabilidade: capacidade de comunicação e tolerância a falhas do sistema. Associados a

caminhos redundantes e replicação de hosts;

3.1.2 Cluster de Alta Disponibilidade - High Availability Computing (HAC)

Clusters de alta disponibilidade são clusters baseados em redundância, onde o enfoque está em
sempre manter a aplicação em pleno funcionamento. Existem nós que podem realizar a mesma
tarefa para assegurar o correto comportamento do sistema em caso de falhas (ALECRIM, 2013).

18
 Para atender a esta exigência, os clusters de alta disponibilidade podem contar com diversos
recursos: ferramentas de monitoramento que identificam nós defeituosos ou falhas na conexão,
replicação (redundância) de serviços e computadores para substituição imediata de máquinas com
problemas, uso de geradores para garantir o funcionamento em caso de queda de energia, entre
outros (ALECRIM, 2013). Estes tipos de cluster são geralmente utilizados para base de dados de
missões críticas, servidores de arquivos e servidores web.

3.1.3 Cluster de Balanceamento de Carga - Load Balancing

Clusters de balanceamento de carga tem como objetivo distribuir tarefas para processamento o
mais uniformemente possível entre os nós. O balanceamento de carga pode ser utilizado em vários
tipos de aplicações, mas o seu uso é bastante comum na Internet, já que soluções do tipo têm maior
tolerância ao aumento instantâneo do número de requisições, justamente por causa do equilíbrio
oriundo da distribuição de tarefas (ALECRIM, 2013).
Alguns algoritmos de balanceamento de carga são apresentados a seguir:
Least Connections: Esta técnica redireciona as requisições para o servidor baseado no menor
número de requisições/conexões. Por exemplo, se o servidor 1 está controlando atualmente 50
requisições/conexões, e o servidor 2 controla 25 requisições/conexões, a próxima requisição/cone-
xão será direcionada para o servidor 2, desde que atualmente o servidor tenha um número menor
de requisições/conexões ativas (HARDWARE, 2003).
Round Robin: Este método usa a técnica de sempre direcionar as requisições para o próximo
servidor disponível de uma forma circular. Assumindo uma configuração com 3 servidores, as
conexões de entrada são dirigidas para o servidor 1, depois servidor 2 e finalmente servidor 3 e
depois retorna ao servidor 1 (HARDWARE, 2003).
Weighted Fair: Esta técnica dirige os pedidos para os servidores baseados na carga de requisi-
ções de cada um e na capacidade de resposta dos mesmo. Por exemplo, se o servidor 1 é quatro
vezes mais rápido no atendimento aos pedidos do que o servidor 2, o administrador coloca um peso

19
maior de trabalho para o servidor 1 do que para o servidor 2 (HARDWARE, 2003).

3.2 Soluções em Softares para Clusters

Existem diferentes soluções de softwares para cada tipo de cluster. As soluções que se desta-
cam, são aquelas baseadas em sistemas Unix. A seguir são apresentadas algumas soluções comer-
ciais para aglomerados.

3.2.1 MOSIX

O MOSIX (Multicomputer Operating System for Unix) é uma das opções mais tradicionais
para implementação de aglomerados. Trata-se de um conjunto de ferramentas que permitem a
configuração de clusters em sistemas baseados no Unix, tendo forte ênfase em balanceamento de
carga e alto desempenho (ALECRIM, 2013).
Entre as suas principais características estão: possibilidade de trabalhar com nós dedicados e
não dedicados; suporte não apenas a CPUs, mas também a GPUs; migração dinâmica de processos
(um nó mais apto pode assumir determinada tarefa para evitar sobrecarga em outro); e possibilidade
de remoção e inclusão de nós sem interromper a execução do cluster (ALECRIM, 2013).
Como o MOSIX também trabalha com nós não dedicados, é possível fazer com que as máquinas
de um escritório passem a trabalhar no cluster após o horário do expediente, por exemplo. Mas,
mesmo se houver usuários utilizando os nós, é possível manter o cluster em funcionamento, já que
as atividades do MOSIX são totalmente “transparentes”, ou seja, seu trabalho no computador não é
perceptível (ALECRIM, 2013).
O MOSIX possui algumas limitações relacionados a hardware e algumas aplicações não podem
ser migradas. Não há uma solução gratuita disponível, embora uma versão sua de código aberto
chamada OpenMosix tenha existido, porém, foi descontinuado.

20
3.2.2 OpenSSI

O OpenSSI é uma solução aberta para clusters voltada a ambientes Linux. O nome tem como
base o conceito de SSI (Single System Image), ou seja, um sistema que considera vários nós, mas
se parece, no ponto de vista do usuário, apenas como um único computador (ALECRIM, 2013).
A “visão” de apenas uma única máquina também é válida para os softwares: este não precisam
ser alterados para “enxergar” cada nó e assim rodar no cluster, facilitando a implementação de
aplicações.
O OpenSSI pode lidar tanto com alto desempenho quanto com alta disponibilidade, além de
possuir recursos para balanceamento de carga. Por implementar uma única unidade lógica, este
modelo possui algumas limitações, tais como: número máximo de nós por agrupamento; número
máximo de sockets; número máximo de processos.

3.2.3 Kerrighed

O Kerrighed é outra opção SSI aberta para clusters que tem como base o Linux. Esta solução
se destaca principalmente por fazer uso do conceito de Distributed Shared Memory (DSM), onde a
memória de cada nó se “soma” à dos demais, como se formassem um volume único à disposição
de todo o cluster (ALECRIM, 2013).
Esta abordagem oferece vários benefícios: parte da memória pode ser disponibilizada para
todos os clientes da aplicação; sistemas desenvolvidos para rodar de maneira centralizada podem
ser executados de maneira distribuída de forma transparente ao programador; o cluster pode se
comportar como se fosse uma máquina com múltiplos processadores.

3.3 Aglomerados BEOWULF

A principal característica de um cluster Beowulf é de ser um sistema de baixo custo em relação

aos super computadores. Por essa razão tem como vantagem o fato de suportarem processadores
de famílias e arquiteturas diferentes. Sua arquitetura baseia-se em uma rede de computadores

21
interconectados por switches através de uma interface de rede. A Figura 3.1 mostra um esquema
simples da arquitetura de um cluster Beowulf.

Figura 3.1: Exemplo de um cluster do tipo Beowulf (ALECRIM, 2013).

O princípio de funcionamento de um Cluster Beowulf é feito da seguinte forma. Há um nó

mestre (front-end) que gerencia e coordena a divisão das tarefas entre os escravos (back-end) por
intermédio de bibliotecas de troca de mensagens, como a MPI, instaladas previamente nos nodos
mestre e escravos. Em clusters desse tipo, é possível processar grandes quantidades de dados, mas
apenas ao utilizar aplicativos escritos com suporte à arquitetura, pois em cada programa precisam
estar incluídas bibliotecas específicas para troca de mensagens, necessárias para a comunicação e
reconhecimento das arquiteturas presentes no sistema (TONIDANTEL, 2008).
A arquitetura Beowulf caracteriza-se por ser versátil e poder ser um sistema de alto desempenho
ou de alta disponibilidade, ou ambos ao mesmo tempo. Tudo dependerá de como o sistema será
montado e configurado. No caso de usar-se apenas um nodo mestre, esse sistema pode ser caracte-
rizado como um sistema de alto desempenho. Se forem utilizados dois nodos mestres, para caso de
um venha a falhar, esse sistema seria caracterizado como um sistema de alta disponibilidade, po-
rém também de alto desempenho de acordo com a configuração do sistema. O sistema operacional

22
utilizado nos aglomerados Beowulf podem ser tanto sistemas baseados em Unix/Linux, Windows
ou Macs, sendo o mais comumente utilizado o sistema Linux. O cluster Beowulf ainda pode contar
com conectividade com a Internet para acesso remoto de usuário que desejam utilizar o serviço do
cluster.

23
Capítulo 4

Implementação de um Cluster Beowulf

Neste capítulo é abordada a topologia, equipamentos utilizados e instalação de um cluster Be-

owulf utilizando o sistema Rocks (JUNIOR, 2013) no cluster educacional disponibilizado pelo
Centro de Ciências Computacionais (C3) da FURG. Inicialmente foi feito um levantamento dos
nodos funcionais do cluster e posteriormente dada manutenção prévia para a utilização do mesmo.
Alguns dispositivos encontram-se inoperantes, porém o cluster pode ser usado para estudos. Du-
rante os testes, um nodo parou de funcionar, limitando a análise da escalabilidade do sistema.
A seguir é feita uma descrição sobre o sistema Rocks Cluster, protocolos de troca de mensa-
gens (MPI), sistema de compartilhamento de dados, e aspectos sobre hardware, software e rede de
comunicação utilizados no cluster.

4.1 Rocks Cluster

Para a configuração do cluster Beowulf foi utilizado o toolkit conhecido como Rocks Cluster1 .
O Rocks Cluster possui uma série de ferramentas que visam facilitar a configuração e instalação,
bem como manter o bom funcionamento e gerenciamento do sistema. Algumas das ferramentas:
auxilio na configuração inicial do nodo mestre, bem como na instalação dos nodos escravos a partir
do nodo mestre; gerenciamento de processos e filas; pacote de bibliotecas de comunicação para
1 http://www.rocksclusters.org

24
HPC; monitoramento dos nodos; etc.
No ano de 2000, um grupo de pesquisadores da National Partnership for Advanced Computatio-
nal Infrastructure e a San Diego Supercomputer Center (SDSC) 2 , com patrocínio da fundação NFS
(National Science Foundation)3 começaram a desenvolver o Rocks Cluster (Open-Source Toolkit
for Real and Virtual Clusters), a fim de oferecer um sistema de fácil instalação e gerenciamento.
O nicho de usuários destinados a utilização do sistema eram usuários ligadas a áreas de pesquisa e
desenvolvido, visando o potencial do processamento paralelo (JUNIOR, 2013).
O Rocks Cluster possui uma série de ferramentas que visam facilitar a configuração e instalação,
bem como manter o bom funcionamento e gerenciamento do sistema. Algumas das ferramentas:
auxilio na configuração inicial do nodo mestre, bem como na instalação dos nodos escravos a partir
do nodo mestre; gerenciamento de processos e filas; pacote de bibliotecas de comunicação para
HPC; monitoramento dos nodos; etc.

4.2 Hardware Utilizado

O hardware utilizado para implementação do cluster é composto por quatro nós, sendo um
denominado mestre e os demais nós escravos. Os nós escravos recebem a nomenclatura usada pelo
Rocks, sendo compute-0-0 o primeiro nodo, avançando sucessivamente até compute-0-2. Todos os
nós possuem a mesma configuração de hardware, caracterizando assim um sistema homogêneo. A
seguir são listados as especificação do sistema:
O sistema ainda conta com um monitor de 14 polegadas CRT, mouse, teclado, um switch KVM
(keyboard, video, mouse) que é um chaveador que tem como função selecionar um nó específico
para interação com os periféricos: teclado, mouse e monitor de video.
A interconexão de rede é feita utilizando cabos de par trançado categoria 5e, um switch com 24
portas RJ-45 gigabit, modelo Linksys SRW2024, com taxas de transmissão de 10/100/1000Mbps.
O cluster não conta com nobreaks e encontra-se em um ambiente climatizado com ar condicionado
2 Unidade de pesquisa da University of California San Diego.
3 Agência governamental dos Estados Unidos que apoia pesquisas nas áreas de ciências e engenharia.

25
 Tabela 4.1: Especificações dos nodos do cluster.

Mestre Escravos
Processador 2 x Opteron 265 dual core 1,8Ghz 2 x Opteron 265 dual core 1,8Ghz
cache L2 2x1Mb cache L2 2x1Mb
Memória RAM 3Gb de memória RAM DDR 3Gb de memória RAM DDR
400Mhz 400Mhz
Armazenamento 80Gb de HD 80Gb de HD
Rede 3 placas de rede Gigabit ethernet 2 placas de rede Gigabit ethernet
Leitores Gravador e leitor de DVD Gravador e leitor de CD

e montado em um rack conforme visto na Figura 4.1.

(a) Visão frontal (b) Visão traseira

Figura 4.1: Estrutura física do cluster.

Na Figura 4.1a pode observar-se de cima para baixo a presença do monitor, teclado, mouse,
KVM, switch e de 8 nodos presos ao rack. Sendo dos 8 nodos, apenas 4 sendo utilizados. Na
Figura 4.1b observa-se as saídas de video VGA de cada um dos conectores do KVM, além dos
cabos amarelos e azuis de cada interface de rede ethernet.

26
4.2.1 Infraestrutura da Rede

A Infraestrutura da rede foi montada conforme a Figura 4.2. Como pode ser observado, o nó
mestre possui 3 placas de rede. A interface eth2 é utilizada para acesso externo ao sistema, através
da Internet, permitindo que usuários acessem o sistema à distância. Já as outras duas interfaces
(eth0 e eth1), são utilizadas para transmissão e fluxo de dados. Sendo cada interface capaz de
transmitir 1000Mbps, tem-se teoricamente neste sistema uma taxa de transmissão de 2Gbps ou
256MB/s.
Os nós escravos possuem 2 placas de rede e conectam-se ao switch através das interfaces eth0
e eth1. Junto com o mestre, formam uma rede exclusiva do sistema. Os cabos para a conexão dos
computadores são do tipo par de fios trançado categoria 5e e conectores padrão RJ45.

Figura 4.2: Estrutura de ligação entre o sistema.

27
4.3 Software Utilizado

O sistema operacional utilizado na implementação do cluster é o Rocks Cluter 6.2, baseado

na distribuição CentOS 6.6. O Rocks é um tookit que possui uma série de ferramenta e utilitário
chamados de Rolls. Segundo (JUNIOR, 2013) e (SCHEPKE et al., 2005) será descrito com maior
detalhamento a lista de rolls instalados no sistema:
Base, OS, Kernel: São os pacotes básicos para o funcionamento adequado do sistema, com-
preende uma série de comandos básicos de gerenciamento e instalação do cluster, sendo o OS o
sistema operacional CentOS 6.6.
Kickstart: Permite colocar todas as seleções que seriam feitas na instalação manual (seleção
de linguagem, partições, etc) em um arquivo de configuração, eliminando assim toda interação com
o usuário.
HPC: Conjunto de ferramentas para execução de aplicações paralelas. Neste Roll estão os
aplicativos MPI, PVM (Parallel Virtual Machine) e benchmarks.
Área 51: Responsável pela segurança do cluster, é composto por dois aplicativos: o Tripware,
que consiste em um software de segurança e integridade de dados que verifica a alteração de arqui-
vos específicos do sistema.
HTCondor: Oferece um ambiente computacional com altas taxas de transferência, efetuando
o gerenciamento de carga, mecanismos de gerenciamento de filas, agendamento, regime de priori-
dade, monitoramento e gerenciamento de recursos. Seu funcionamento se assemelha a um sistema
de filas de lotes.
Ganglia: É um sistema de monitoramento de recursos do cluster. Ele gera gráficos e monitora
as atividades dos nós e núcleos dos processadores e sua utilização em processos paralelos.
SGE: Chamado atualmente de Oracle Grid Engine, gerencia a carga de tarefas dentro de um
cluster, oferecendo uma grande escalabilidade e adaptação a vários ambientes de trabalho. O SGE
também auxilia no gerenciamento de filas.
ZFS: Sistema de arquivo de dados e gerenciamento de volumes lógicos. Incluem proteção
contra corrupção de dados, suporte para altas capacidades de armazenamento, eficiente compressão

28
de dados, integração de conceitos de sistemas de arquivos. Apesar de fazer parte da instalação, foi
utilizado o sistema de compartilhamento de arquivos NFS.
Perl: Instala a linguagem de programação Perl.
Python: Este roll instala a linguagem de programação Python atualmente utilizada por uma
grande variedade de aplicações, principalmente em estudos científicos.

4.4 Instalação do Sistema Rocks Cluster

Primeiramente, deve-se adquirir a imagem do sistema operacional Rocks Cluster. Para isso,
deve-se acessar o site do Rocks em <http://www.rocksclusters.org>. O site do Rocks oferece dois
tipos de download, uma chamada Jumbo, que oferece todos os rolls em uma única imagem de DVD,
ou em CD’s distribuindo os rolls em imagens menores. O Apêndice A apresenta detalhadamente
todo o processo de instalação no mestre e nos nodos escravos. Tendo o nodo mestre um drive de
DVD, foi escolhido para a instalação do sistema a distribuição Jumbo.
Algumas observações sobre a instalação do Rocks são pertinentes a serem feitas.
Multi-Boot
Nas primeiras instalações do sistema Rocks, foram feitas tentativas de criar múltiplas entidades
de boot tanto no mestre quanto nos nós escravos, a fim de possibilitar o carregamento de diferentes
configurações feitas no sistema. Devido a algumas inflexibilidades do sistema Rocks não consegui-
se a criação de múltiplos boots.
Todavia, de acordo com o manual do Rocks é possível criar múltiplos boots no sistema. É es-
clarecido que para o particionamento automático durante a instalação dos nodos escravos, o arquivo
replace-partition.xml (disponível no apêndice G) deve ser criado dentro do diretório /export/rocks/install/site-
profiles/6.1.1/nodes, conter as instruções de particionamento lógico das HD’s dos nodos, possibili-
tando a criação de mais de um boot.
Feita a criação do arquivo, deve-se entrar com o comando rocks create distro pelo terminal
dentro do diretório /export/rocks/install para a criação atualizada da imagem a ser gravada nos nós

29
escravos.
Lembrando que é possível gerenciar o particionamento manual do nó mestre durante sua ins-
talação para a criação de multi-boots. Em seguida é necessário editar o grub dentro do diretório
/boot/grub para que seja possível acessar os sistemas instalados em cada partição.

Boot PXE
Após dado o comando insert-ethers no terminal, o utilitário kickstart gera um IP automático
para o nó através do seu MAC. Esse IP é transformado em um valor hexadecimal ao qual um
arquivo de identificação do protocolo PXE no diretório /tffpboot é nomeado. Este arquivo fica,
portanto, no mestre e possui as instruções de boot do nodo.

No caso de algum erro na instalação do nó durante o kickstart, deve-se proceder da seguinte

maneira:

1. Verificar através do comando # rocks list host se o nó em questão faz parte da lista de hosts
do sistema;

2. Em caso de resposta positiva, deve-se retirar o nó da listagem do sistema com o comando

#rocks remove host "nome do nó";

3. Deve-se, então, iniciar novamente a instalação do nó com o comando insert-ethers;

4.5 Message Passing Interface

Umas das principais características envolvendo os clusters Beowulf é o paradigma de troca de

mensagens. Define-se o modelo de passagem de mensagens por um conjunto de processos que
possuem acesso a memória local e comunicam-se com outros processos, efetuando operações em
ambos os processos para envio e recebimento de dados da memória local de um processo para outro
(JUNIOR, 2013).

30
 O MPI (Message Passing Interface) é um conjunto de especificações de protocolos de comuni-
cação paralela. Ele permite que processos troquem mensagens provendo maior grau de abstração
do que as primitivas oferecidas por sockets.
O MPI surgiu da necessidade de se patronizar e disponibilizar um interface bem definida de
troca de mensagens, de modo a oferecer a portabilidade para qualquer arquitetura e aplicações
para diferentes máquinas (KOPP, 2012). O MPI possui suporte linguagens FORTRAN, C, C++ e,
atualmente, a Java. Sua primeira versão foi publicada em 1994 e atualizada em junho de 1995.
Neste trabalho foi utilizado o OPENMPI4 (Open Source High Performance Computing) por ser
o padrão da instalação, e que é uma variante open source do MPI.

4.6 Sistema de compartilhamento NFS

O sistema de arquivos NFS (Network File System) é um sistema que permite o compartilha-
mento de arquivos em uma rede de computadores, independente de máquina, sistema operacional
e protocolo de transporte. Foi desenvolvido pela Sun Microsystems5 .
O NFS funciona como um espelhamento de arquivos na rede de intercomunicação, estando os
arquivos hospedados em um único host. A Figura 4.3 ilustra o compartilhamento de dados através
de uma rede de comunicação, estando no exemplo, os dados hospedados em um servidor NFS.

Figura 4.3: Arquitetura NFS (JONES, 2010).

4 www.open-mpi.org
5 Empresa adquiria pela Oracle Corporation

31
 A portabilidade do sistema NFS existe devido ao uso de RPC (Remote Procedure Call), me-
canismo que providencia uma interface orientada a procedimentos para serviços remotos, e ao uso
de XDR (eXternal Data Representation) que é uma especificação padrão de representação de um
conjunto de tipos de dados em uma rede, o que resolve o tipo de representação de dados na comu-
nicação entre diferentes computadores (NOTLOADED, 2010).
Segundo (NOTLOADED, 2010) os principais elementos do NFS são:

• nfsd: daemon6 NFS, que atende requisições dos clientes NFS;

• mountd: daemon de montagem NFS, que executa as solicitações que o nfsd lhe passa;

• portmap: daemon portmapper permite que clientes NFS descubram qual porta o servidor
NFS está utilizando.

Na configuração do cluster do C3 foi utilizado esse sistema, por ser de fácil entendimento e
implementação.
Frond–End
Estando o NFS instalado corretamente no mestre, para poder criar o sistema de compartilha-
mento, é necessário editar o arquivo /etc/exports para definir a pasta a ser compartilhada com as
permissões de acesso. A sintaxe é feita da seguinte forma:

(Diretório) (IP’s de acesso) (Permissões)

onde:

• Diretório = caminho do diretório a ser compartilhado;

• IP’s de acesso = são os IPs clientes que terão acesso a pasta compartilhada;

• Permissões = permissões de acesso ao compartilhamento.

6 Programa que é executa de forma oculta ao usuário, em segundo plano.

32
 As principais permissões são:

• ro: somente leitura;

• rw: leitura e escrita;

• no_root_squash: por padrão, o nível de acesso dos clientes ao servidor é mesmo que o root.

Por fim entrar como o comando

# exportfs -a
para liberar acesso de compartilhamento.
Exemplo de como foi editado o arquivo /etc/exports:

1 / export 10.1.0.0/24 (rw , no_root_squash , sync )

Nós Escravos
Ainda é necessário configurar os nós escravos para que recebam os diretórios compartilhados
pelo mestre. Para isto é necessária a correta instalação dos pacotes do NFS, e a edição os pontos
de montagem do sistema pelo arquivo /etc/fstab nos nodos escravos. A sintaxe é feita da seguinte
forma:
(Caminho do mestre):(Caminho do Diretório) (Ponto de Montagem) (Sistema de Arquivos)
(Opções)
Exemplo de como foi editado o arquivo editado /etc/fstab:

1 10.1.1.1:/ expot / export / nfs auto 0 0

Foi criado um script visando a automatização desse processo. Ele pode ser visto no Anexo F.

33
Capítulo 5

Análise de Desempenho

Para teste de desempenho e análise de implementação do cluster apresentado, foram realizados

testes de cargas utilizando ordenamento de vetores e o benchmark HPL. Ao longo do Capítulo
serão descritas essas ferramentas de avaliação, e os resultados obtidos.

5.1 Benchmarks

A seguir serão descritos os algoritmos, ferramentas e métodos de avaliação de desempenho.

5.1.1 Ordenamento de Vetores

Para testes de funcionalidade, foi implementado uma versão paralela do algoritmo de ordena-
mento, Bubble sort, utilizando MPI. Para averiguar a implementação do cluster e análise de desem-
penho. O funcionamento do algoritmo Bubble sort tem como princípio o método por força-bruta,
ele percorre diversas vezes um vetor, e a cada passagem armazena em uma variável o elemento de
maior valor da sequência. Este algoritmo possui complexidade de pior caso O(n2 ).
Esse tipo de aplicação pode ser útil na análise de desempenho do Cluster Beowulf. Encaixam-
se na categoria dos “toy benchmarks”, programas de 10 a 100 linhas de código que geram um
resultado previamente conhecido (TONIDANTEL, 2008).

34
 O programa paralelo utilizado pode ser vistos no Anexo D. O programa funciona da seguinte
forma: o nodo mestre (Front–End) que possui Rank zero, envia para os outros núcleos de pro-
cessamento um vetor da matriz, por esse motivo o Rank zero não realiza nenhuma operação de
ordenamento, ele apenas encaminha os vetores para cada unidade de processamento. Os vetores
enviados estão relacionados com o Rank de cada processo.
Foi criado também um programa sequencial utilizado para comparação de desempenho, que
pode ser visto no Anexo E.

5.1.2 Speedup

O cálculo de speedup é uma medida de comparação de desempenho, que foi definido primei-
ramente pela lei de Amdahl (AMDAHL, 1967). O speedup pode ser definido como a razão entre
o tempo gasto para executar uma tarefa em modo sequencial, e o tempo gasto para executar essa
mesma tarefa em modo paralelo. A fórmula do speedup pode ser vista na Equação 5.1.

Tsequencial
Speedup = (5.1)
Tparalelo

Dessa forma, obtém-se uma quantificação de quanto mais rápida é a execução de um algoritmo
paralelo em comparação com o sequencial.

5.1.3 Benchmark HPL

A principal ferramenta de avaliação de desempenho utilizado neste trabalho é o benchmark

HPL (GODÓI, 2015). O HPL é utilizado como ferramente de avaliação para compor a lista do
top 500 1 , que relaciona a cada 6 meses os supercomputadores mais rápidos do planeta. O HPL
implementa um programa matricial que resolve um sistema de equações lineares densas (geradas
aleatoriamente) em aritmética de precisão dupla (64 bits).
O HPL mede o desempenho de um sistema através do calculo de ponto flutuante (Gflops) assim
1 Top 500 Supercomputer <http://www.top500.org>

35
como o tempo gasto para executá-lo. O benchmark calcula a solução de um sistema e equações
lineares do tipo A.x = b, onde: A é uma matriz aleatória de ordem N; x e b são vetores também
de ordem N. A matriz A é então fatorada como produto A = L.U onde L e U representam as
matrizes triangulares inferior e superior respectivamente. A solução é realizada através de um
pivotamento de linha, por questões de estabilidade numérica. A solução x é então encontrada
através de aplicações sucessivas e passos da solução triangular L.z = b e U.x = z. (SILVA et al.,
2004).
Os dados que compõe a matriz A são distribuídos por uma grade bidimensional de tamanho PxQ
de maneira cíclica em bloco. A matriz de coeficientes, de dimensão N x N+1, é então particionada
logicamente em blocos NB x NB, que são distribuídos na grade de processos. Isto é feito em ambas
as dimensões da matriz, para garantir um bom balanceamento de carga, assim como a escalabilidade
do algoritmo (SILVA et al., 2004).

Instalação do HPL

Por padrão todos os arquivos foram salvos no diretório /opt/. Primeiramente devem ser baixados
os arquivos da biblioteca GotoBLAS2 que são disponibilizados no site <https://www.tacc.utexas.
edu/research-development/tacc-software/gotoblas2>. Em um terminal, entrar com o comando:
# make
O HPL utilizado para testes de benchmark foi a versão 2.2. Ele pode ser obtido no site <http:
//www.netlib.org/benchmark/hpl/>. Feito o download do arquivo, descompactar o HPL no diretório
citado anteriormente com o comando:
# tar -vzxf hpl-2.2.tar.gz
Em seguida copiar o arquivo Make.Linux_ATHLON_CBLAS que esta dentro do diretório ../hpl-
2.2/setup/ para a raiz onde foi descompactado o benchmark. O Make.Linux_ATHLON_CBLAS é
um arquivo de configuração genérico que serve para qualquer sistema, por isso recomendado seu
uso. As configurações utilizadas no aglomerado podem ser vistas no Anexo B . Entre no terminal
com o comando:

36
 # make arch=Linux_ATHLON_CBLAS
Dentro do diretório /opt/hpl-2.2/bin/Linux_ATHLON_CBLAS/ encontram-se dois arquivos, o
xhpl para execução do benchmark e o HPL.dat utilizado para modificar as variáveis da equação
linear utilizado pelo HPL.

Rodando HPL

Para iniciar o HPL é necessário criar um arquivo com os nodos que compõem o sistema. Foi
criado um arquivo com nome máquinas contendo o nome dos nodos em número de processadores
de cada host, que pode ser visto no Anexo C.
Os arquivos xhpl, HPL.dat e maquinas devem estar no diretório compartilhado para que todos
os nodos tenham acesso. No HPL.dat deve ser descrito o valor da ordem Ns da matriz, o valor de
Ps e Qs, que devem ser dois números cujo produto resulte na quantidade total de processadores
utilizados, e NBS que é o valor da subdivisão da matriz. Esses parâmetros, dependendo da configu-
ração, podem ser calculados através do seguinte site <http://hpl-calculator.sourceforge.net>. Um
exemplo do arquivo HPL.dat ficou da seguinte forma:

1 HPLinpack benchmark input file

2 Innovative Computing Laboratory , University of Tennessee

3 HPL . out output file name ( if any )

4 6 device out (6= stdout ,7= stderr , file )

5 1 # of problems sizes (N)

6 15000 Ns

7 1 # of NBs

8 254 NBs

9 0 PMAP process mapping (0= Row - ,1= Column - major )

10 1 # of process grids (P x Q)

11 2 Ps

12 6 Qs

13 16.0 threshold

37
14 3 # of panel fact

15 0 1 2 PFACTs (0= left , 1= Crout , 2= Right )

16 2 # of recursive stopping criterium

17 2 4 NBMINs ( >= 1)

18 1 # of panels in recursion

19 2 NDIVs

20 3 # of recursive panel fact .

21 0 1 2 RFACTs (0= left , 1= Crout , 2= Right )

22 1 # of broadcast

23 0 BCASTs (0=1 rg ,1=1 rM ,2=2 rg ,3=2 rM ,4= Lng ,5= LnM )

24 1 # of lookahead depth

25 0 DEPTHs ( >=0)

26 2 SWAP (0= bin - exch ,1= long ,2= mix )

27 64 swapping threshold

28 0 L1 in (0= transposed ,1= no - transposed ) form

29 0 U in (0= transposed ,1= no - transposed ) form

30 1 Equilibration (0= no ,1= yes )

31 8 memory alignment in double (> 0)

Então para iniciar os testes deve-se entrar em um terminal com o comando:

# mpirun -machinefile maquinas xhpl

5.2 Resultados

A seguir serão expostos os resultados obtidos com o uso dos benchmarks.

5.2.1 Resultados do Ordenamento de Vetor

Os testes de ordenamento de vetor foram feitos com um tamanho fixo de uma matriz 600x5000,
onde pode-se representar 600 vetores de 5000 posições, com valores aleatórios de 0 à 99, aplicando-

38
se o algoritmo Bubble Sort. Foi utilizado uma variação da quantidade de nodos a fim de verificar-se
ganho de desempenho. Para rodar os programas é necessário acrescentar no arquivo C o nome do
mestre uma única vez. Para análise, foram excluídos o pior e o melhor tempo, e feita uma média
com os valores restantes.
Na Tabela 5.1 pode ser visto os tempos em segundos, encontrados e o tempo médio, onde ’T’
representa o tempo total de processamento e ’Tm’o tempo médio de cada processamento.

Tabela 5.1: Resultados do Ordenamento da Matriz 600 x 5000.

Nodos T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 Tm
seq. 163 163 163 163 163 163 163 163 163 163 163
1 138 105 137 137 138 137 137 137 138 137 137,25
2 104 109 109 106 109 108 109 106 107 112 107,87
3 82 84 82 81 82 82 82 83 82 81 82

O gráfico abaixo representam os dados das Tabela 5.1.

Figura 5.1: Tempo de Execução Bubble sort.

Observando os dados apresentados do ordenamento de vetor, conforme se divide o problema em

vários nodos, e por conseguinte vários cores, obtém-se um menor tempo de processamento, o que
comprova o quanto o processamento paralelo otimiza o tempo gasto para a resolução de problemas.

39
O processamento com 3 nodos obteve um tempo de processamento 21.2% menor que com 2 nodos,
40, 25% menor que o processamento com 1 nodo e 49, 69% menor que o processamento sequencial.

Tempo Speedup

Abaixo, o gráfico 5.2, do Speedup.

Figura 5.2: Speedup Ordenamento de Vetor.

Conclui-se que conforme utiliza-se mais nodos do aglomerado, melhor será o desempenho.

5.2.2 Resultados HPL

Os experimentos realizados foram reduzidos devido a limitações da infraestrutura que contam

apenas com 3 nodos de processamento. Foram feitos testes de carga de modo a avaliar o desempe-
nho do cluster.
Em uma primeira análise , conforme visto na Tabela (5.2) foram feitos testes de carga com o
HPL utilizando uma matriz de tamanho N=1500, tendo como objetivo avaliar o tempo de proces-
samento variando o número de nodos.
Na Tabela, “N” representa o tamanho do problema executado, ou seja, o tamanho da matriz,
“NB” é o número de blocos, a subdivisão do problema, ’P’ e ’Q’ o número de linhas e colunas,
referente ao número de processadores utilizados para a execução do problema.

40
 Tabela 5.2: Resultados do HPL para uma matriz de tamanho fixo.

Nodos N NB P Q tempo(s) GFlops

1 15000 254 1 4 232.41 9.683
2 15000 254 2 4 300.05 7.500
3 15000 254 2 6 270.72 8.312

Em segunda instância (5.3) uma análise de poder máximo de processamento de pontos flutu-
antes do sistema foi obtido variando-se o número de nodos utilizado e o tamanho da matriz. Vale
frisar que o tamanho da matriz esta ligado diretamente a capacidade de endereçamento de memória,
portanto em uma matriz com muitos pontos não é possível rodar o experimento do HPL sequencial.

Tabela 5.3: Resultados do HPL para uma matriz de tamanho variável.

Nodos N NB P Q tempo(s) GFlops

1 15000 254 1 4 323.41 9.683
2 20000 254 2 4 540.13 9.978
3 25000 254 2 6 741.43 14.05

As medidas de tempo e vazão são mostradas nas Figuras 5.2 e 5.3.

Figura 5.3: Execução HPL com N=15000 em função do tempo.

41
 Figura 5.4: Execução HPL com N=15000 em função de GFlops.

Figura 5.5: Execução HPL com N variável.

Observando os resultados do benchmark HPL para uma matriz de tamanho fixo, nas Figuras 5.3
e 5.4, nota-se a questão da granulosidade da divisão do problema. Para um problema relativamente
pequeno, mais nodos processando, não necessariamente terá-se um ganho de desempenho, em
virtude da divisão de tarefas que num resultado final tornam-se um “gargalo” para o sistema. Pode-

42
se citar outros problemas como o balanceamento de carga e a rede de conexões como fator agravante
desse resultado.
Numa segunda análise, conforme mostrado na Figura 5.5, observa-se que o processamento com
3 nodos obteve um processamento 40.8% maior que com 2 nodos e 45, 05% maior que o processa-
mento com 1 nodo. Fica evidente o aumento de processamento utilizando 3 nodos comparado com
os demais. Conclui-se que quando maior o problema, maior será a capacidade de processamento
do aglomerado, devido a granulosidade do problema executado, havendo menos troca de contexto
entre nó mestre e nó escravo e com isso maior período de processamento. Quanto maior é a divisão
do tamanho do problema maior será o poder de processamento paralelo.
Conclui-se que a maneira de correta avaliação do HPL é em função de quando maior o número
de nodos utilizados maior poderá ser o problema resolvido.

43
Capítulo 6

Conclusão

A construção e configuração de um cluster Beowulf apesar de apresentar alguma complexidade,

torna-se algo relativamente mais simples com a utilização de ferramentas que ajudam no manejo de
construção de aglomerados computacionais de alto desempenho, como o utilizado nesse projeto,
o tollkit Rocks Cluster. Após o estudo de funcionamento do Rocks Cluster, observa-se que uma
das ferramentas mais básicas e importantes, que contribui para uma boa prática de configuração de
aglomerados, é o Kickstart. Com ele tem-se a facilidade de construção da rede do aglomerado.
A partir da implementação do projeto proposto, observa-se que a construção de aglomerados
computacionais está dividida em três etapas básicas:

1. Configuração da rede de comunicação (IP’s, hostname);

2. Sistema de compartilhamento de arquivos;

3. Implementação do protocolo de sistemas de troca de mensagem (MPI), que é a chave da

divisão das tarefas;

Apesar da correta funcionalidade do sistema Rocks Cluster, sua última atualização foi no ano de
2015, o que caracteriza uma certa defasagem. A falta de suporte é um problema a ser considerado
na implementação dos aglomerados de alto desempenho. Muitos dos atuais aglomerados possuem

44
sistema e ferramentas próprias de uso restrito, o que leva ao entendimento da necessidade de criação
de um sistema com ferramentas próprias, para futuros projetos de construção de clusters.
Para análise do desempenho do cluster proposto, foram utilizados benchmarks como o HPL,
e ordenamento de vetores com bubble sort. A medição do HPL mostrou que quanto mais nodos
disponíveis maior pode ser o problema resolvido e maior será a taxa de processamentos de dados
de ponto flutuante. No ordenamento de vetores se vê claramente o ganho em tempo de execução
conforme se paraleliza um problema.
Com os resultados obtidos e expostos, conclui-se que o aglomerado computacional se compor-
tou de maneira esperada, comprovando a correta configuração e instalação do mesmo.

45
Referências Bibliográficas

ALECRIM, E. Cluster: conceitos e características. 2013. <http://www.infowester.com/cluster.

php>. Acessado em abril de 2017.

AMDAHL, G. M. Validity of the single processor approach to achieving large scale computing
capabilities. In: ACM. Proceedings of the April 18-20, 1967, spring joint computer conference.
[S.l.], 1967. p. 483–485.

BARCELLOS, M. P.; GASPARY, L. P. Tecnologias de rede para processamento de alto

desempenho. Anais da 3a Escola Regional de Alto Desempenho (ERAD). Santa Maria, RS:
UFRGS, 2006.

BECKER, D. J. et al. Beowulf: A parallel workstation for scientific computation. In: Proceedings,
International Conference on Parallel Processing. [S.l.: s.n.], 1995. v. 95, p. 11–14.

BODEN, N. J. et al. Myrinet: A gigabit-per-second local area network. IEEE micro, IEEE, v. 15,
n. 1, p. 29–36, 1995.

CULLER, D. E.; SINGH, J. P.; GUPTA, A. Parallel computer architecture: a hardware/software

approach. [S.l.]: Gulf Professional Publishing, 1999.

DATANAMI. Does InfiniBand Have a Future on Hadoop? 2017. <https://www.datanami.com/

2015/08/04/does-infiniband-have-a-future-on-hadoop/>. Acessado em junho de 2017.

FLYNN, M. J. Some computer organizations and their effectiveness. IEEE transactions on

computers, IEEE, v. 100, n. 9, p. 948–960, 1972.

FONSECA, R. et al. One-to-one direct modeling of experiments and astrophysical scenarios:

pushing the envelope on kinetic plasma simulations. Plasma Physics and Controlled Fusion, IOP
Publishing, v. 50, n. 12, p. 124034, 2008.

FOURNIER, A.; TAYLOR, M. A.; TRIBBIA, J. J. The spectral element atmosphere model
(seam): High-resolution parallel computation and localized resolution of regional dynamics.
Monthly Weather Review, v. 132, n. 3, p. 726–748, 2004.

GODÓI, F. N. d. Estudo comparativo entre clusters de computadores desktop e de dispositivos

ARM. Dissertação (B.S. thesis) — Universidade Tecnológica Federal do Paraná, 2015.

HARDWARE, C. do. Computação em Cluster. 2003. <http://www.clubedohardware.com.br/

artigos/redes/computa%C3%A7%C3%A3o-em-cluster-r33711/>. Acessado em abril de 2017.

46
HEALTH, N. N. I. of. High Performance Computing Section. 2017. <https://www.lobos.nih.gov/
LoBoS-versions.shtml>. Acessado em junho de 2017.
HOCKNEY, R. Cr jesshope parallel computers 2. Adam Hilger, p. 491–524, 1988.
HWANG, K. Advanced computer architecture: Parallelism, scalability, programmability:,
mcgraw-hill book co. international edition. 1993.
JONES, M. Sistemas de arquivos de rede e Linux. 2010. <https://www.ibm.com/developerworks/
br/library/l-network-filesystems/index.html>. Acessado em outubro de 2017.
JUNIOR, E. E. Estudo de tecnologias para computação paralela e distribuída: Implementação de
um cluster beowulf. 2013.
KOPP, E. M. Construção de um cluster hpc para simulações de cfd. Universidade Tecnológica
Federal do Paraná, 2012.
MORIMOTO, C. E. InfiniBand. 2005. <http://www.hardware.com.br/termos/infiniband>.
Acessado em junho de 2017.
NETWORK, M. Introduction to Infiniband. Pt1. 2017. <https://monsternetwork.wordpress.com/
2014/01/25/introduction-to-infiniband-pt1/>. Acessado em junho de 2017.
NOTLOADED. NFS – Network File System. 2010. <https://notloaded.wordpress.com/>. Acessado
em outubro de 2011.
ROCHA, M. L.; MACHADO, G. B. R. Uma proposta de aumento de desempenho na simulação
de árvores trinomiais para precificação de opções. 2011.
ROSE, C. A. F. D.; NAVAUX, P. O. A. Fundamentos de processamento de alto desempenho. In:
ERAD. [S.l.: s.n.], 2004. p. 26.
SANTOS, C. H. da S. et al. Computação bio-inspirada e paralela para a analise de estruturas
metamateriais em microondas e fotonica. Campinas, SP, 2010.
SCHATZ, M. C.; LANGMEAD, B.; SALZBERG, S. L. Cloud computing and the dna data race.
Nature biotechnology, Nature Research, v. 28, n. 7, p. 691–693, 2010.
SCHEPKE, C. et al. Panorama de ferramentas para gerenciamento de clusters. Porto Alegre:
Instituto de Informática, UFRGS, 2005.
SILVA, V. et al. Arquitetura e avaliação do cluster de alto desempenho netuno. In: ERAD. [S.l.:
s.n.], 2004.
SPAINHOWER, L.; GREGG, T. A. Ibm s/390 parallel enterprise server g5 fault tolerance: A
historical perspective. IBM Journal of Research and Development, IBM, v. 43, n. 5.6, p. 863–873,
1999.
TONIDANTEL, D. A. V. MANUAL DE MONTAGEM DE UM CLUSTER BEOWULF SOB A
PLATAFORMA GNU/LINUX. 2008.

47
Anexo A

Tutorial de Configuração Rocks Cluster

Figura A.1: Logo Rocks Cluster.

O Sistema Operacional escolhido para a instalação no cluster foi o Rocks Cluster 6.2 (<http:
//www.rocksclusters.org>). O Rocks Cluster é uma distribuição baseada no CentOS 6.6 com toolkit
que são ferramentas destinadas a gerenciamento de cluster embutidas.
O CentOS é uma distribuição Linux conhecida pelo seu alto nível de estabilidade, previsibi-
lidade e pela possibilidade de ser configurada de múltiplas maneiras. Feita a partir do Red Hat
Enterprise Linux (RHEL), ela é mantida em um modelo simples, com alto nível de transparência e
abertura.

48
A.1 Ferramentas

Anaconda: É um instalador do Red Hat Enterprise Linux e Fedora. Auxilia na instalação do

nó mestre do cluster.

HPC: Conjunto de aplicativos instalados em um Roll para fornecer ferramentas para execu-
ção de aplicações paralelas. Neste Roll inclui os aplicativos MPI - Message Passing Interface
(OPENMPI, MPICH, MPICH2), PVM - Parallel Virtual Machine e benchmarks (Stream, iperf,
IOZone).

Área 51: Responsável pela segurança do Cluster, instalando dois aplicativos: o Tripware que
consiste em um software de segurança e integridade de dados que verifica a alteração de arquivos
específicos do sistema, sendo seu código fonte aberto. Também disponibiliza o Chkrootkit que
identifica infecções por um rootkit.

HTCondor: Oferece ao Cluster Rocks um ambiente computacional com altas taxas de transfe-
rência, efetuando o gerenciamento de carga, mecanismos de gerenciamento de filas, agendamento,
regime de prioridade, monitoramento e gerenciamento de recursos. Seu funcionamento se asseme-
lha a um sistema de filas de lotes.

Ganglia: É um sistema de monitoramento de Cluster que gera gráficos e monitora as atividades

dos nós e núcleos dos processadores e sua utilização em processos paralelos. Utiliza a tecnologia
XML, XDR e RRDtoll para a representação, compactação, armazenamento e visualização dos da-
dos e gráficos.

SGE: O Roll SGE instala e configura o software Sun Grid Engine, que agora chama-se Oracle
Grid Engine devido a incorporação da Sun pela empresa Oracle, é uma solução que gerencia a
carga de tarefas dentro de um Cluster, oferecendo uma grande escalabilidade e adaptação a vários

49
ambientes de trabalho, incluindo computação em nuvem.

ZFS: ZFS é uma combinação de sistema de arquivos e volume de manipulação lógica dese-
nhado pela Sun Microsystems. As propriedades do ZFS incluem proteção contra corrupção de
dados, suporte para altas capacidades de armazenamento, eficiente compressão de dados, integra-
ção de conceitos de sistemas de arquivos e volumes lógicos, suporte a snapshots e clones com cópia
quando escreve.

A.2 Instalação

Nó mestre

Primeiro configurar o nó mestre. Na interface inicial do Anaconda (figura A.2), entrar com o
comando:

# build.
Em local Rools, selecionar cd/dvd Rools.
Em seguida selecione as seguintes ferramentas que serão utilizadas na configuração do cluster
conforme a figura A.3.

• Área 51

• Base

• Ganglia

• HPC

• HtCondor

50
 Figura A.2: Tela inicial do Anaconda.

Figura A.3: Tela de seleção das ferramentas disponibilizadas.

• Java

51
 • kernel

• OS

• Perl

• Phyton

• SGE

• ZFS-Linux

O Base, OS e Kernel são os pacotes básicos para o funcionamento adequado do sistema.

Na próxima tela (figura A.4), preencha conforme conveniência, salientando que o campo Full-
Quallfield Host Name é obrigatório.

Figura A.4: Tela de para preenchimento de dados do cluster.

Na interface de configuração de rede (figura A.5) coloque o ip da interface eth0 que terá acesso
a rede interna do cluster, e eth1 com acesso a rede externa.

52
 Figura A.5: Tela de configuração de rede.

Para o acesso inicial digite o usuário como root e a senha estabelecidos.

Já dentro do sistema instalado, abra um terminal e entre com o comando

# insert-ethers

A janela da figura A.6 será exibida.

53
 Figura A.6: Utilitário kickstart.

para iniciar a instalação do sistema nos nós escravos a partir do nó mestre. Selecione a opção
compute. O utilitário kickstart faz uma varredura de endereços mac’s que estejam conectados ao
emphswitch que faz a interconexão da rede interna.
Detalhe: talvez seja necessário retirar o cabo que possui conexão externa a rede, devido ao
script insert-ethers procurar por portas eterneth’s que fazem roteamento externo.

Nós escravos

A instalação dos nós escravos será feita por PXE pela rede local. Portanto deve-se configurar o
boot dos nós para rede local.
Ligue uma máquina escrava de cada vez, e espere pela instalação (imagens A.8 e A.9).

54
Nó mestre

Após identificar o nó escravo, a janela A.7 será exibida. Será gerado um nó com o nome
compute-0-X, onde X indica o número do nó correspondente e começará a instalação nos nós
escravos.

Figura A.7: Tela de reconhecimento do MAC.

Espere pela instalação no nós escravos (A.8 e A.9) e tecle F8 para sair

55
 Figura A.8: Carregamento da imagem de instalação.

Figura A.9: Instalação do Sistema.

Para verificar os nós que fazem parte do cluster entre com o comando

# rocks list host.

Pode-se verificar também os nós com os ip’s gerados no arquivo /etc/dhpc/dhpcd.conf.

56
 Para ter acesso a um nó entre com o comando

# ssh compute-0-x.

onde x corresponde ao nó para acesso.

57
 Anexo B

Arquivo de Configuração do HPL

Abaixo o arquivo Make.Linux_ATHLON_CBLAS utilizado na configuração do HPL.

1 # ------------------------------------------------------

2 # - shell ----------------------------------------------

3 # ------------------------------------------------------

4 #

5 SHELL = / bin / sh

6 #

7 CD = cd

8 CP = cp

9 LN_S = ln -s

10 MKDIR = mkdir

11 RM = / bin / rm -f

12 TOUCH = touch

13 #

14 # ------------------------------------------------------

15 # - Platform identifier --------------------------------

16 # ------------------------------------------------------

17 #

58
18 ARCH = Linux_ATHLON_CBLAS

19 #

20 # ------------------------------------------------------

21 # - HPL Directory Structure / HPL library --------------

22 # ------------------------------------------------------

23 #

24 TOPdir = / opt /hpl -2.2

25 INCdir = $( TOPdir )/ include

26 BINdir = $( TOPdir )/ bin /$( ARCH )

27 LIBdir = $( TOPdir )/ lib /$( ARCH )

28 #

29 HPLlib = $( LIBdir )/ libhpl .a

30 #

31 # ------------------------------------------------------

32 # - MPI directories - library --------------------------

33 # ------------------------------------------------------

34 # MPinc tells the C compiler where to find the Message Passing

library

35 # header files , MPlib is defined to be the name of the library to

be

36 # used . The variable MPdir is only used for defining MPinc and MPlib .

37 #

38 # MPdir = / usr / local / mpi

39 MPdir = / opt / openmpi

40 MPinc = -I$ ( MPdir )/ include

41 # MPlib = $( MPdir )/ lib / libmpich . so

42 MPlib = $( MPdir )/ lib / libmpi .a

43 #

44 # ------------------------------------------------------

59
45 # - Linear Algebra library ( BLAS or VSIPL ) -------------

46 # ------------------------------------------------------

47 # LAinc tells the C compiler where to find the Linear Algebra

library

48 # header files , LAlib is defined to be the name of the library to

be

49 # used . The variable LAdir is only used for defining LAinc and LAlib .

50 #

51 # LAdir = $( HOME )/ netlib / ARCHIVES / Linux_ATHLON

52 LAdir = / opt / GotoBLAS2

53 LAinc =

54 # LAlib = $( LAdir )/ libcblas .a $( LAdir )/ libatlas .a

55 LAlib = $( LAdir )/ libgoto2 .a

56 #

57 # ------------------------------------------------------

58 # - F77 / C interface ----------------------------------

59 # ------------------------------------------------------

60 # You can skip this section if and only if you are not planning to

use

61 # a BLAS library featuring a Fortran 77 interface . Otherwise , it

is

62 # necessary to fill out the F2CDEFS variable with the

appropriate

63 # options . ** One and only one ** option should be chosen in ** each **

of

64 # the 3 following categories :

65 #

66 # 1) name space ( How C calls a Fortran 77 routine )

67 #

60
68 # - DAdd_ : all lower case and a suffixed underscore ( Suns

69 # Intel , ...) , [ default

70 # - DNoChange : all lower case ( IBM RS6000 ) ,

71 # - DUpCase : all upper case ( Cray ) ,

72 # - DAdd__ : the FORTRAN compiler in use is f2c .

73 #

74 # 2) C and Fortran 77 integer mapping

75 #

76 # - DF77_INTEGER = int : Fortran 77 INTEGER is a C int , [ default

77 # - DF77_INTEGER = long : Fortran 77 INTEGER is a C long ,

78 # - DF77_INTEGER = short : Fortran 77 INTEGER is a C short .

79 #

80 # 3) Fortran 77 string handling

81 #

82 # - DStringSunStyle : The string address is passed at the string loca

83 # tion on the stack , and the string length is

then

84 # passed as an F77_INTEGER after all

explicit

85 # stack arguments , [ default

86 # - DStringStructPtr : The address of a structure is passed by

87 # Fortran 77 string , and the structure is of

the

61
 88 # form : struct { char * cp ; F77_INTEGER len ;} ,

89 # - DStringStructVal : A structure is passed by value for each

Fortran

90 # 77 string , and the structure is of the form

91 # struct { char * cp ; F77_INTEGER len ;} ,

92 # - DStringCrayStyle : Special option for Cray machines , which

uses

93 # Cray fcd ( fortran character descriptor )

for

94 # interoperation .

95 #

96 F2CDEFS =

97 #

98 # ------------------------------------------------------

99 # - HPL includes / libraries / specifics ---------------

100 # ------------------------------------------------------

101 #

102 HPL_INCLUDES = -I$ ( INCdir ) -I$ ( INCdir )/$( ARCH ) $( LAinc ) $( MPinc )

103 HPL_LIBS = $( HPLlib ) $( LAlib ) $( MPlib )

104 #

105 # - Compile time options -------------------------------

106 #

107 # - DHPL_COPY_L force the copy of the panel L before bcast ;

108 # - DHPL_CALL_CBLAS call the cblas interface ;

109 # - DHPL_CALL_VSIPL call the vsip library ;

110 # - DHPL_DETAILED_TIMING enable detailed timers ;

111 #

112 # By default HPL will :

62
113 # *) not copy L before broadcast ,

114 # *) call the Fortran 77 BLAS interface

115 # *) not display detailed timing information .

116 #

117 HPL_OPTS = - DHPL_CALL_CBLAS

118 #

119 # ------------------------------------------------------

120 #

121 HPL_DEFS = $( F2CDEFS ) $( HPL_OPTS ) $( HPL_INCLUDES )

122 #

123 # ------------------------------------------------------

124 # - Compilers / linkers - Optimization flags -----------

125 # ------------------------------------------------------

126 #

127 # CC = / usr / bin / gcc

128 CC = $( MPdir )/ bin / mpicc

129 CCNOOPT = $( HPL_DEFS )

130 CCFLAGS = $( HPL_DEFS ) -fomit - frame - pointer -O3 - funroll - loops -W -

Wall

131 #

132 # LINKER = / usr / bin / gcc

133 LINKER = $( MPdir )/ bin / mpicc

134 LINKFLAGS = $( CCFLAGS )

135 #

136 ARCHIVER = ar

137 ARFLAGS = r

138 RANLIB = echo

139 #

140 # -------------------------------------------------------

63
 Anexo C

Arquivo Contendo o hostname do nodos

Exemplo do arquivo machinefile maquinas utilizado.

1 compute -0 -0

2 compute -0 -0

3 compute -0 -0

4 compute -0 -0

5 compute -0 -1

6 compute -0 -1

7 compute -0 -1

8 compute -0 -1

9 compute -0 -2

10 compute -0 -2

11 compute -0 -2

12 compute -0 -2

64
 Anexo D

Bubble Sort Paralelo

Abaixo o programa feito para o ordenamento de vetores com a tecnica bubble sort, utilizando
MPI.

1 // ######################################################

2 // # #

3 // # PROGRAMA DE ORDENAMENTO DE VETORES UTILIZANDO MPI #

4 // # BUBBLE SORT #

5 // # #

6 // # Daniel Dias da Silva #

7 // # outubro de 2017 #

8 // ######################################################

10 # include <mpi .h >

11 # include < stdio .h >

12 # include < stdlib .h >

13 # include < time .h >

14

15 # define max_l 600

16 # define max_c 5000

65
17

18 # define N 100

19

20 // #########################################################

21 // ############# FUNCAO BUBBLE SORT #####################

22 // #########################################################

23 void bubble ( int vet []) {

24

25 int key , i , j , n;

26

27 for (j= max_c -1; j >=1; j - -){

28 for (i =0; i <j; i ++) {

29 if ( vet [i]> vet [i +1]) {

30 key = vet [i ];

31 vet [i ]= vet [i +1];

32 vet [i +1]= key ;

33 }

34 }

35 }

36 }

37

38 // #########################################################

39 // ############### FUNCAO PRINCIPAL #####################

40 // #########################################################

41

42 int main ( int argc , char ** argv ) {

43 int l , c , destinatario ;

44 int matriz [ max_l ][ max_c ];

45 int vetor [ max_c ];

66
46

47 int m;

48 int i;

49

50 time_t tempo ; // variavel que guarda um tempo

51 struct tm * sTempo ; // estrutura que guarda um tempo

52

53 for (l =0; l < max_l ; l ++)

54 for (c =0; c < max_c ; c ++) {

55 int num = rand () % N;

56 matriz [l ][ c] = num ;

57 // printf ("% d \n", num );

58 }

59

60 // Inicializa variaveis de ambiente MPI

61 MPI_Init ( NULL , NULL );

62 // Find out rank , size

63 int world_rank ;

64 MPI_Comm_rank ( MPI_COMM_WORLD , & world_rank );

65 int world_size ;

66 MPI_Comm_size ( MPI_COMM_WORLD , & world_size );

67 if ( world_rank == 0) {

68

69 tempo = time ( NULL ); // recebe tempo

70 sTempo = localtime ( & tempo );

71

72 printf (" world size : %d\n" , world_size );

73 printf ( "%d :% d :% d\n" , sTempo -> tm_hour , sTempo -> tm_min , sTempo ->

tm_sec );

67
74

75

76 for ( destinatario =1; destinatario < world_size ; destinatario ++) {

77 for (m= destinatario -1;m < max_l ;m=m+ world_size -1) {

78 for (c =0; c < max_c ; c ++) {

79 vetor [c] = matriz [m ][ c ];

80 }

81

82 MPI_Send (& vetor , max_c , MPI_INT , destinatario , 0,

MPI_COMM_WORLD );

83 }

84

85 }

86 }

87

88 else if ( world_rank != 0) {

89 for (i =0;i < max_l /( world_size -1) ;i ++) {

90 MPI_Recv (& vetor , max_c , MPI_INT , 0, 0, MPI_COMM_WORLD ,

MPI_STATUS_IGNORE );

91

92 bubble ( vetor );

93 }

94

95 tempo = time ( NULL ); // recebe tempo

96 sTempo = localtime ( & tempo );

97 printf (" escravo :% d %d :% d :% d\n" , world_rank , sTempo -> tm_hour , sTempo

-> tm_min , sTempo -> tm_sec );

98 }

99

68
100 MPI_Finalize () ;

101 return (0) ;

102 }

69
 Anexo E

Bubble Sort Sequencial

Abaixo o programa feito para o ordenamento de vetores com a tecnica bubble sort, de forma
sequencial.

1 // ######################################################

2 // # #

3 // # PROGRAMA DE ORDENAMENTO DE VETORES SEQUENCIAL #

4 // # BUBBLE SORT #

5 // # #

6 // # Daniel Dias da Silva #

7 // # outubro de 2017 #

8 // ######################################################

10 # include < stdio .h >

11 # include < stdlib .h >

12 # include < time .h >

13 # include < sys / time .h >

14

15 # define N 5000 // numero elementos

16 # define M 600 // numero vetores

70
17 # define num 10 // valores para o vetor

18 # define pausa 1

19

20 // #####################################################################

21 // ################# FUNCAO BUBBLESORT SEQUENCIAL ######################

22 // #####################################################################

23

24 void bubble_seq ( int vet []) {

25

26 int key , i , j , n;

27

28 for (j=N -1; j >=1; j - -){

29 for (i =0; i <j; i ++) {

30 if ( vet [i]> vet [i +1]) {

31 key = vet [i ];

32 vet [i ]= vet [i +1];

33 vet [i +1]= key ;

34 }

35 }

36 }

37 }

38 // #####################################################################

39 // ######################### FUNCAO PRINCIPAL ##########################

40 // #####################################################################

41 int main () {

42

43 int i , j , c;

44 int matriz [M ][ N ];

45 int vet [N ];

71
46 float tempo ;

47 clock_t t_inicio , t_fim ;

48

49

50 for (i =0;i <M;i ++) {

51 for (j =0;j <N;j ++)

52 matriz [i ][ j] = rand () % num ; // valores aleatorios para a lista de

vetores

53 }

54

55 t_inicio = clock () ;

56

57 for (c =0;c <M;c ++) {

58 for (j =0;j <N;j ++) {

59 vet [j] = matriz [c ][ j ];

60 }

61 bubble_seq ( vet );

62 }

63

64 t_fim = clock () ;

65 tempo = difftime ( t_fim , t_inicio )/ CLOCKS_PER_SEC ;

66 printf (" Tempo de execucao : %f segundos \n\n" , tempo );

67

68 return (0) ;

69 }

72
 Anexo F

Script NFS

Script de automatização do compartilhamento de arquivos utilizando NFS.

1 # !/ bin / bash

3 user = root ;

5 echo " Quantidade de nodos :";

6 read num ;

8 for (( i =1;i < $num ;i ++) ) do {

10 ssh compute -0 - $i " mkdir / export "

11 ssh compute -0 - $i " echo " 10.1.1.1:/ export / export nfs auto 0 0" >> \ etc \

fstab "

12 ssh compute -0 - $i " mount -a"

13

14 exit ;

15 }

16 done ;

73
 Anexo G

Arquivo replace-partition.xml

A seguir é mostrado o que deve conter o arquivo replace-partition.xml para o particionamento

dos nodos escravos durante a execução do utilitário kickstart no Font–End.

1 <? xml version =" 1.0 " standalone =" no "?>

2 < kickstart >

3 < description >

4 A skeleton XML node file . This file is a template and is

intended

5 as an example of how to customize your Rocks cluster . Kickstart

XML

6 nodes such as this describe packages and " post installation "

shell

7 scripts for your cluster .

8 XML files in the site - nodes / directory should be named either

9 " extend -[ name ]. xml " or " replace -[ name ]. xml " , where [ name ] is

10 the name of an existing xml node .

11 If your node is prefixed with replace , its instructions will be

used

74
12 instead of the official node ’s. If it is named extend , its

directives

13 will be concatenated to the end of the official node .

14 </ description >

15

16 < changelog >

17 </ changelog >

18

19 <main >

20 <!-- kickstart ’ main ’ commands go here --> # COMANDOS PARA O

AUTO - PARTICIONAMENTO

21 </ main >

22

23 <pre >

24 <!-- partitioning commands go here -->

25 echo " rocks manual " > / tmp / user_partition_info # PARA

PARTICIONAMENTO MANUAL

26 </pre >

27

28 <!-- There may be as many packages as needed here . Just make sure you

only

29 uncomment as many package lines as you need . Any empty < package > </

package >

30 tags are going to confuse rocks and kill the installation

procedure

31 -->

32 <!-- <package > insert 1 st package name here and uncomment the line </

package > -->

75
33 <!-- <package > insert 2 nd package name here and uncomment the line </

package > -->

34 <!-- <package > insert 3 rd package name here and uncomment the line </

package > -->

35

36 <post >

37 <!-- Insert your post installation script here . This

38 code will be executed on the destination node after the

39 packages have been installed . Typically configuration files

40 are built and services setup in this section . -->

41 <!-- WARNING : Watch out for special XML chars like ampersand ,

42 greater / less than and quotes . A stray ampersand will cause the

43 kickstart file building process to fail , thus , you won ’t be

able

44 to reinstall any nodes . It is recommended that after you create

an

45 XML node file , that you run :

46 xmllint - noout file . xml

47 -->

48 < eval shell =" python " >

49 <!-- This is python code that will be executed on the

50 frontend node during kickstart file generation . You may

contact

51 the database , make network queries , etc . These

sections are

52 generally used to help build more complex configuration

53 files . The ’ shell ’ attribute is optional and may point

to any

76
54 language interpreter such as " bash " , " perl " , " ruby " ,

etc .

55 By default shell =" bash ". -->

56 </ eval >

57 </ post >

58 </ kickstart >

77
 Anexo H

Arquivo grub

Exemplo de como deve ser o arquivo grub editado.

2 # grub . conf generated by anaconda

3 #

4 # Note that you do not have to rerun grub after making changes to this

file

5 # NOTICE : You do not have a / boot partition . This means that

6 # all kernel and initrd paths are relative to /, eg .

7 # root (hd0 ,0)

8 # kernel / boot / vmlinuz - version ro root =/ dev / sda1

9 # initrd / boot / initrd -[ generic -] version . img

10 # boot =/ dev / sda

11 default =0

12 timeout =5

13 hiddenmenu

14 title Rocks 6 sis1 (2.6.32 -504.16.2. el6 . x86_64 )

15 root (hd0 ,0)

78
16 kernel / boot / vmlinuz -2.6.32 -504.16.2. el6 . x86_64 ro root =/ dev /

sda1 rd_NO_LUKS rd_NO_LVM LANG = en_US .UTF -8 rd_NO_MD SYSFONT =

latarcyrheb - sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM rhgb

quiet

17 initrd / boot / initramfs -2.6.32 -504.16.2. el6 . x86_64 . img

18

19 title Rocks 6 sis2 (2.6.32 -504.16.2. el6 . x86_64 )

20 root (hd0 ,1)

21 kernel / boot / vmlinuz -2.6.32 -504.16.2. el6 . x86_64 ro root =/ dev /

sda2 rd_NO_LUKS rd_NO_LVM LANG = en_US .UTF -8 rd_NO_MD SYSFONT =

latarcyrheb - sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM rhgb

quiet

22 initrd / boot / initramfs -2.6.32 -504.16.2. el6 . x86_64 . img

79