Implementação de um Cluster Beowulf

usando Conectiva Linux

André Ruiz
Conectiva S.A. (http://www.conectiva.com.br)
Diretoria de Serviços (http://suporte-corp.conectiva)

sup-corp@conectiva.com.br
Índice
1. Apresentação ........................................................................................................................................................................ 5

2. Argumentos de Venda........................................................................................................................................................ 10

3. Análise Técnica................................................................................................................................................................... 11

4. Implantação ........................................................................................................................................................................ 16

5. Referências.......................................................................................................................................................................... 16

6. Anexos ................................................................................................................................................................................. 18

3
4
Informações Gerais

Este documento define o conceito de um cluster Beowulf. Pretende-se um direcionamento para a montagem de um cluster
beowulf usando Conectiva Linux, assim como informações gerais sobre como utilizar outros conjuntos de softwares gerenci-
adores e bibliotecas diferentes das abordadas aqui. A intenção primária é prover dados técnicos suficientes para que se possa
montar um cluster com sucesso, mas como "beowulf" é mais uma classificação de clusters do que um modelo específico,
se faz necessário uma introdução teórica sobre o assunto, incluindo o porquê de sua criação e sua história em geral. Quem
estiver interessado apenas na parte técnica poderá pular a secção entitulada "História".
Este documento criado por André Ruiz (andre@conectiva.com.br), para uso interno na Conectiva S.A. (http://www.conectiva.com.br)
e faz parte do projeto de documentação e sistematização do setor de consultoria e suporte empresarial (suporte corporativo).
Este documento pode ser encontrado online em http://suporte-corp.conectiva/ (http://suporte-corp.conectiva/) na intranet da
empresa.
Comentários e críticas sobre este documento devem ser enviados diretamente para o autor (mailto:andre@conectiva.com.br)
ou então para a Diretoria de Serviços (mailto:sup-corp@conectiva.com.br)
Este documento é de uso interno da Conectiva S.A. (http://www.conectiva.com.br). Todo o conteúdo está direcionado para
as atividades da Rede Conectiva de Serviços . O uso por outros setores é permitido (e incentivado), entretanto sugestões e
críticas devem ser enviadas para o autor ou para a Diretoria de Serviços (http://suporte-corp.conectiva).
ATENÇÃO: Este documento está sob homologação e não deve ser tomado como uma descrição completa da solução, prin-
cipalmente devido sua complexidade, enquanto não houver massa critica suficiente para garantir que os principais pontos
foram adequadamente abordados. Sugestões serão bem vindas.
Agradecimentos a Jacques Mattheij (mailto:jam@truetech.com) por sua contribuição na parte prática deste material. Ele não
tem nenhuma relação profissional com a Conectiva S.A. (http://www.conectiva.com.br).

1. Apresentação
O projeto Beowulf começou no CESDIS (Center of Excellence in space Data and Information Sciences), que é operado para
a NASA pela USRA (Universities Space Research Association), no verão de 1994, com a construção de um cluster de 16 nós
desenvolvido para o projeto ESS (Eatch and space sciences) no GSFC (Goddard Space Fight Center). O projeto se espalhou
rapidamente para outras partes da NASA, para outros laboratórios de pesquisa e desenvolvimento por todo o mundo.
O escopo do projeto, bem como o numero de Beowulfs instalados tem crescido com o passar dos anos. Na verdade, eles
parecem estar se multiplicando a uma taxa crescente.
Qualquer cluster para processamento massivo e/ou paramétrico de alto desempenho que se enquadre em certas regras pode
ser considerado um cluster do tipo Beowulf. Apesar de softwares específicos serem indicados para montagem dos beowulfs,
o termo define mais um conceito do que uma plataforma ou um conjunto de softwares.
Alguns chamam de cluster beowulf apenas os clusters montados da mesma maneira que o original da NASA, outros cha-
mam de beowulf qualquer conjunto de estações que faça processamento paralelo. A definição correta de beowulf (segundo
mensagens que passaram pela lista de discussão) é algo entre estes dois extremos. Veremos mais adiante a definição oficial.

5
1.1. Introdução
No verão de 1994, Thomas Sterling e Don Becker, trabalhando no CESDIS sob o patrocínio do projeto ESS, construíram um
cluster de computadores consistindo de 16 processadores DX4 conectados por rede ethernet. Eles chamaram esta "maquina"
de Beowulf. A máquina foi um sucesso instantâneo, e a idéia deles de proporcionar sistemas baseados em máquinas COTS
(Commodity off the shelf – maquinas comuns, compradas diretamente da prateleira do mercado, sem nada especial e caro)
para satisfazer necessidades computacionais específicas rapidamente se espalhou por toda a NASA e pelas comunidades
acadêmicas e de pesquisa.
O esforço de desenvolvimento direcionado para esta primeira máquina rapidamente se tornou o que chamamos hoje de
"Projeto Beowulf". Veremos adiante os maiores pontos técnicos de um cluster beowulf, mas uma medida não técnica do seu
sucesso é o fato de os pesquisadores da comunidade "High Performance Computer" já estarem se referindo à máquinas desse
tipo como "Clusters de Computadores da Classe Beowulf". Ou seja, os clusters beowulf se tornaram um ponto de referência,
um modelo, uma classe. Dentro da comunidade HPC eles são definidos como um "gênero".

1.2. História (literal – retirado da página do projeto)

O CESDIS (Center of Excellence in Space Data and Information Sciences) é uma divisão do USRA (University Space
Research Association), localizado no GSFC (Goddard Space Flight Center) em Greenbelt Maryland. CESDIS é um dos
contratantes da NASA, patrocinado em parte pelo projeto ESS. O projeto ESS é um projeto de pesquisa dentro do Programa
HPCC (High Performance Computing and Communications). Um dos objetivos do projeto ESS é determinar a aplicabilidade
dos computadores massivamente paralelos nos problemas normalmente enfrentados pela comunidade de ciências espaciais.
O primeiro beowulf foi construído para lidar com os problemas associados a grandes quantidades de dados que estavam
freqüentemente envolvidos com as aplicações do projeto ESS.
Pode ser que apenas seja a hora certa de aparecerem os clusters da classe beowulf. Nos últimos dez anos nós vimos acontecer
um grande número de eventos que acabaram proporcionando mais do que o necessário para a criação do Projeto Beowulf.
A criação do mercado de computação casual (automação de escritórios e automação comercial, computação caseira, jogos e
entretenimento) agora provê o desenvolvedor de sistemas com um novo tipo de computador barato. A indústria dos compu-
tadores COTS agora fornece máquinas completamente montadas (microprocessadores, placas mãe, discos e placas de rede).
A dura competição do mercado fez com que os preços destas máquinas caíssem e que elas se tornassem melhores e mais
confiáveis. O desenvolvimento de softwares livres e publicamente disponíveis, em particular o sistema operacional Linux,
os compiladores GNU e as ferramentas de programação, também as bibliotecas de repasse de mensagens MPI e PVM, todos
juntos, provêem software independente de plataforma de hardware. Programas como o HPCC tem produzido muitos anos
de experiência trabalhando com algoritmos paralelos. A experiência nos ensinou que obter uma plataforma de alta perfor-
mance, mesmo que encomendada de um fornecedor, é um trabalho muito duro, e requer que os desenvolvedores adotem
uma política de "faça você mesmo". Um segundo aspecto desta história de trabalhar com plataformas paralelas é que hou-
ve um aumento da dependência da ciência computacional e conseqüentemente um aumento da necessidade de cálculos de
alta performance. poderia-se até dizer que a combinação destas condições (hardware, software, experiência e expectativa)
proporcionaram um ambiente que faz o desenvolvimento dos clusters beowulf parecerem um evento da evolução natural da
ciência da computação.
Nós somos constantemente lembrados da melhoria de performance dos microprocessadores, mas talvez mais importante
para o projeto beowulf seja o recente ganho no custo/performance da tecnologia de redes. A história guarda recordes de
muitos grupos acadêmicos e comerciais que desenvolveram máquinas com processadores baseados no "estado da arte" de
seu tempo, mas eles sempre precisaram de algum método que unisse os processadores ou algum esquema de interconexão.

6
Para a comunidade acadêmica isto levou a pesquisas interessantes e a exploração de novas idéias, mas geralmente resultando
em máquinas únicas. O ciclo de vida de uma dessas máquinas dependia do ciclo de vida das carreiras de graduação das
pessoas que estavam envolvidas em seu projeto.
Fabricantes geralmente escolhiam recursos especiais nos esquemas de interconexão para melhorar algumas características dos
seus equipamentos ou para criar uma máquina que ganhasse o mercado. Mas para explorar estes recursos os programadores
tinham que adotar um modelo específico de programação (o do fabricante). Isto freqüentemente levou a finais infelizes com
respeito ao desenvolvimento de software. O custo efetivo e o suporte do Linux para redes de alta velocidade para máquinas da
classe PC permitiu a construção de sistemas balanceados constituídos totalmente de máquinas COTS, o que tornou práticos
as arquiteturas genéricas e os modelos de programação.
O primeiro beowulf foi construído com máquinas que possuíam processadores DX4 e rede ethernet de 10 Mbp/s. Os compu-
tadores eram rápidos demais para uma única placa ethernet e os switchers ethernet ainda eram caros demais. Para balancear
o sistema Don Becker reescreveu seus drivers ethernet para linux e construiu também um driver para "channel bonded ether-
net" onde o tráfego ethernet pode ser distribuído por mais de uma placa de rede no mesmo micro. Como os custos das placas
de rede e dos switchers de 100 Mbp/s ethernet se tornaram viáveis, a necessidade para o "channel bonding" diminuiu (pelo
menos por enquanto). No final de 1997, uma boa escolha para um sistema de balanceamento eram 16 máquinas P6 200 Mhz
(pentium pro) conectadas por Fast Ethernet e um switcher também Fast Ethernet (100 Mbp/s). A configuração de rede exata
de um cluster assim irá sempre variar e estará sempre dependente do tamanho do cluster e da relação entre velocidade do
processador e largura de banda da rede que os interliga e do preço dos componentes necessários.
Uma característica interessante dos clusters beowulf é que nenhuma destas mudanças (tipo de processadores e velocidades,
velocidade da rede, custo relativo dos componentes) muda o modelo de programação. Então, os usuários destes sistemas
podem esperar mais compatibilidade (e por mais tempo) de seus softwares com os clusters em que eles rodam do que jamais
existiu no passado.
Outro ponto chave na compatibilidade futura é o software de sistema que é usado no beowulf. Com a robustez e maturidade do
linux, do software GNU e com a padronização das interfaces de passagem de mensagens via PVM e MPI, os programadores
agora tem a garantia de que os programas que eles escrevem irão rodar nos futuros clusters beowulf, independentemente de
quem vai fabricar os processadores ou as placas de rede. Uma conseqüência natural.
O primeiro beowulf foi montado para satisfazer uma necessidade especifica da comunidade do ESS. Foi construído pelos
e para os pesquisadores que tinham experiência em programação paralela. Muitos desses pesquisadores já tinham gasto
anos brigando com os fabricantes de plataformas MPP (Massive Parallel Processing) e administradores de sistemas sobre
informações detalhadas de performance e aturando ferramentas mal desenvolvidas e novos modelos de programação. Isto
os levou a tomar uma atitude do tipo "faça você mesmo". Outra realidade que eles encararam foi a de que acesso a uma
maquina grande e poderosa geralmente significava usar apenas uma pequena fração do poder da máquina, que estava sendo
dividida entre muitos usuários. Para estes usuários, construir um cluster que eles pudessem controlar completamente e utilizar
totalmente, significava uma plataforma computacional que daria resultados mais efetivos e maior performance. Uma atitude
que poderia resumir esta situação seria "porque comprar o que eu tenho poder para construir?". A realização é que aprender
a construir e usar um beowulf é um investimento. Aprender as peculiaridades de um fabricante específico apenas lhe deixaria
escravo daquele fabricante.
Aqueles programadores peso-pesado estavam finalmente excitados pela primeira vez com computação de alta performance
aplicada a problemas difíceis. Na Supercomputing’96 tanto a NASA quanto o DOE demonstraram clusters custando menos
de US$ 50,000 que obtinham mais do que um gigaflop/s de performance sustentada. Um ano depois, os pesquisadores da
NASA no Goddard Space Flight Center combinaram dois clusters em um total de 199 processadores P6 e rodaram uma
versão que usava PVM de um código de PPM (Piece-wise Parabolic Method) com uma taxa sustentada de 10.1 gigaflops/s.
Na mesma semana um cluster da Caltech de 140 nós rodou um problema N-body a uma taxa de 10.9 Gflops/s. Isto não
significa que os clusters beowulf são supercomputadores, significa apenas que qualquer um pode construir um beowulf que
é grande o suficiente para atrair a atenção de usuários de supercomputadores.

7
Além de programadores experientes, os clusters beowulf tem sido também utilizados por programadores com pouca ou
nenhuma experiência em programação paralela. Na verdade, os clusters beowulf proporcionaram uma excelente plataforma
de ensino de programação paralela e além de uma computação de baixo custo para os cientistas nas universidades geralmente
com baixo poder aquisitivo e recursos limitados.
Na taxonomia dos computadores paralelos, os clusters Beowulf estão entre os MPP (Massively Parallel Processors, como os
nCube, CM5, Convex SPP, Cray T3D, Cray T3E, etc.) e os NOWs (Network of Workstations). O projeto beowulf se beneficia
do desenvolvimento destas duas outras classes de arquiteturas. MPPs são tipicamente maiores e tem uma menor latência
na interconexão de rede do que um cluster beowulf. Programadores ainda são obrigados a se preocupar com localidade,
balanceamento de carga, granularidade e sobrecarga (overhead) de comunicações para poder obter a melhor performance
possível. Mesmo em máquinas com memória compartilhada alguns programadores desenvolvem seus programas em um
estilo de passagem de mensagens, assim programas que não requerem computação de baixa granularidade de processamento
e comunicação geralmente podem ser portados e rodar efetivamente em clusters beowulf. Programar uma NOW geralmente
quer dizer tentar utilizar os ciclos de processamentos desperdiçados em uma base de estações já instaladas e espalhadas por
um grande campus ou laboratório. Este ambiente requer algoritmos que sejam extremamente tolerantes aos problemas de
balanceamento de carga e alta latência na comunicação. Qualquer programa que rode em uma NOW irá rodar no mínimo tão
bem quanto em um cluster.
Um cluster da classe beowulf é distinguido de uma NOW por várias súbitas mas importantes características. Primeiro, todos
os nós são dedicados ao cluster. Isto ajuda muito no balanceamento de carga, porque as cargas individuais dos nós não
estarão sujeitos a fatores externos. Também, uma vez que as conexões de rede são isoladas do mundo externo, a carga
da rede será determinada apenas pela aplicação executada no cluster. Isto ajuda nos problemas associados aos tempos de
latência imprevisíveis que existem nas NOWs. Todos os nós do cluster estão dentro da jurisdição administrativa do cluster.
Por exemplo, a interconexão de rede do cluster não é visível a partir do mundo externo, então a única autenticação necessária
entre os processadores é a da integridade dos dados. Em uma NOW, deve-se tomar cuidado com a segurança da rede. Outro
exemplo é o software para beowulf que provê um ID único e global para o processo. Isto cria um mecanismo para que
um processo envie um sinal para outro processo em outro nó do cluster, tudo dentro do domínio do usuário. Isto não é
permitido em uma NOW. Finalmente, parâmetros do sistema operacional podem ser alterados para melhorar a performance.
Por exemplo uma estação de trabalho deve ser ajustada para prover a melhor interatividade possível (respostas instantâneas,
buffers pequenos, etc.), mas em um cluster os nós podem ser ajustados para se obter melhor performance e velocidade de
transferência de dados em tarefas com alta granularidade porque eles não interagem diretamente com o usuário.
O futuro do Projeto Beowulf será determinado coletivamente pelas organizações individuais que contribuem para o projeto
e pelo futuro do mercado dos COTS. Conforme a tecnologia dos processadores continua a se desenvolver, redes de alta
velocidade se tornam mais baratas e mais e mais desenvolvedores de aplicações se movem para as plataformas parelelas, o
Projeto Beowulf se desenvolverá mais e evoluirá até preencher seu nicho de mercado.

1.3. Definição
Beowulf é uma arquitetura que pode ser usada para processamento paralelo. É um sistema que geralmente consiste de um
nó central ou servidor e um ou mais nós clientes, interconectados através de ethernet ou algum outro tipo de rede de dados.
É um sistema montado a partir de hardware classificado como COTS (commodity of the shelf – equipamentos comuns
encontrados em qualquer loja, ou "direto da prateleira") assim como qualquer micro capaz de rodar linux, usa adaptadores
de ethernet padrões, e switchers para interconexão dos nós. Não contém hardware especial em nenhum ponto, e é facilmente
reproduzível. Outra característica muito importante é que ele usa software de fácil acesso, geralmente free, como por exemplo
o sistema operacional Linux, as bibliotecas de passagem PVM (parallel virtual machine) e MPI (message passing interface).
O nó central controla todo o cluster, e serve arquivos para os nós clientes. Também funciona como console do sistema, e
gateway para o mundo externo. Clusters beowulf particularmente grandes podem ter mais de um nó central ou servidor, e

8
possivelmente outros nós dedicados a certas tarefas como por exemplo consoles ou estações de monitoramento. Na maioria
dos casos, os nós clientes de um cluster beowulf são burros. Quando mais burros melhor. Estes nós são configurados e
controlados pelo nó central, e fazem apenas o que são ordenados a fazer. Em uma configuração com cliente disk-less, os
nós clientes nem mesmo sabem seu IP ou seu nome antes que o nó central os informe. Uma das maiores diferenças entre
os clusters beowulf e as COWs (cluster of workstations) é o fato de que os clusters beowulf se comportam como uma
única máquina ao invés de muitas máquinas. Em quase todos os casos os nós clientes não tem teclados nem monitores, e
são acessados apenas via login remoto (telnet, ssh, etc.) ou possivelmente via serial. Chegam ao ponto de não terem nem
gabinete, onde as placas mãe são montadas em um hack especial uma acima da outra, ocupando muito pouco espaço. Cada
nó cliente do cluster beowulf pode ser pensado como um pacote de CPU + memória que pode ser plugado no cluster assim
como se pluga módulos de memória em uma placa mãe.
Beowulf não é um pacote de software especial, nem uma nova topologia de rede, nem mesmo um hack especial para o kernel.
Beowulf é uma tecnologia para agrupar computadores rodando linux de modo a formar um supercomputador virtual paralelo.
Apesar de haver muitos pacotes de software, como por exemplo modificações no kernel, bibliotecas PVM e MPI, ferramentas
de configuração que fazem o cluster beowulf ficar mais rápido, fácil de configurar e muito mais usável, pode-se construir um
cluster beowulf usando distribuições padrões de linux sem nenhum software adicional. Se você tem duas máquinas linux em
rede que compartilham pelo menos o diretório /home por NFS, e confiam uma na outra o suficiente para permitir a execução
de remote shells (rsh ou similares), então poderia-se argumentar que você tem um cluster beowulf simples de dois nodes (na
realidade é necessário mais que isso, mas daria uma boa discussão).
Um conceito bastante importante na programação paralela é o conceito de granularidade, que consiste no “grau de divisão” do
dado de um problema entre as CPU’s que participarão da solução. Assim, a granularidade está diretamente relacionada com o
tempo de processamento total (quanto maior ela for, menor será o tempo de processamento) e com o tempo de comunicação
entre as CPU’s (uma vez que quanto mais CPU’s participarem da tarefa, maior será o tempo de comunicação).

1.4. Classificação
Os clusters beowulf tem sido construídos a partir de uma variedade de máquinas e marcas diferentes. Em prol da performance,
algumas vezes são adotados alguns hardwares específicos (por exemplo, tudo do mesmo fabricante). Para manter a ordem e
criar uma classificação dos diferentes tipos de sistemas e também para tornar as discussões sobre estas máquinas um pouco
mais fácil, existe a seguinte proposição de esquema de classificação:
BEOWULF CLASSE I
Esta classe de máquinas é composta inteiramente por máquinas COTS. Podemos usar o teste de certificação Computer
Shopper para definir quais são as marcas aplicáveis (Computer Shopper é uma revista americana mensal de quase três
centímetros de espessura com máquinas PC e componentes). O teste é o seguinte:
Um Beowulf Classe I é uma máquina que pode ser montada com peças encontradas em catálogos de propaganda de pelo
menos três grandes distribuidores nacionais ou globais
As vantagens de um sistema Classe I são:

• hardware é encontrado de múltiplos fornecedores (preços baixos e fácil manutenção)

• não se necessita depender de nem confiar em um único fornecedor

• suporte a drivers na comunidade linux

• geralmente baseado em padrões conhecidos (SCSI, IDE, Ethernet, etc.)

9
As desvantagens de um sistema de Classe I são:

• para se atingir melhor performance pode ser necessário passar para Classe II

BEOWULF CLASSE II
Um beowulf da classe II é simplesmente qualquer máquina que não passe no teste citado anteriormente. Isto não é necessa-
riamente mau, é apenas uma classificação.
As vantagens de um sistema classe II são:

• a performance pode ser ótima!

As desvantagens de um sistema classe II são:

• suporte a drivers pode variar

• dependência de um único vendedor

• são mais caros do que os classe I

Uma classe não é necessariamente melhor do que a outra. Tudo depende das suas necessidades e do seu orçamento. Esta
classificação pretende apenas tornar as discussões sobre beowulf um pouco mais sucintas.

1.5. Objetivos da Solução

O crescimento rápido na performance dos processadores para o mercado de massa (para micro-computadores) e a dispa-
ridade significante entre os preços de PCs comuns e estações de trabalho científicas abriu uma oportunidade para ganhos
substanciais na relação custo/benefício juntando-se PCs em paralelo para prover alta capacidade para aplicações científicas
e de engenharia. Recentemente um cluster beowulf com 16 nós custando menos de US$ 50,000 sustentou 1.25 Gigaflops
em uma simulação de um N-body gravitacional de 10 milhões de partículas com um algoritmo de código de árvore, usando
hardware comum e software livre.
O objetivo desta solução é criar uma "máquina" poderosa, capaz de cálculos pesados, gastando-se pouco, ou pelo menos com
hardware comum que se pode encontrar em qualquer fornecedor.

1.6. Abrangência da Solução

Um cluster beowulf tem um alto poder de processamento que pode ser necessário para se resolver cálculos muito complexos
em qualquer ramo de atividade, desde pesquisas até produção real. Qualquer um que necessite deste poder poderá montar o
cluster.

10
2. Argumentos de Venda
Quanto mais a performance dos microcomputadores e das redes crescem, e seus preços decrescem, mas fácil e prático fica
montar cluster para processamento paralelo usando equipamentos do tipo "COTS", ao invés de comprar tempo de processa-
mento em Supercomputadores caríssimos. Na verdade o custo/benefício de um cluster beowulf é de três a dez vezes melhor
do que o de um supercomputador. Tem uma alta escalabilidade, é fácil de construir e você só paga pelo hardware pois pode
ser montado com software free.

2.1. Vantagens e Desvantagens

Considerando-se que a performance de um cluster beowulf pode ser a mesma de (ou maior que a de) um supercomputador,
sem dúvidas a maior vantagem é o preço. Depois podemos citar manutenção barata e também o alto nível de experiência
que já foi atingido por cientistas que trabalham nesta área e estão dispostos a compartilhar este conhecimento com outras
pessoas. A internet está cheia de exemplos de clusters e softwares de administração para ajudar na montagem de um.

2.2. Complexidade
A complexidade técnica de um cluster beowulf não é grande se considerarmos apenas a estrutura do cluster em si. O trabalho
todo consiste em escolher as marcas de equipamentos, a topologia de rede, montar fisicamente os equipamentos e instalar os
softwares de gerenciamento. A parte realmente complicada de todo o processo de utilização de um cluster beowulf está em
fazer o software que rodará nele. Este documento não entra no problema de desenvolvimento de software para processamento
paralelo.

2.3. Custos
Esta secção ficará em aberto até que tenhamos coletado os dados exatos para apresentar aqui. Se você está precisando destes
dados, escreva para o autor; você pode estar com uma cópia antiga desde documento.

2.4. Prazos
Idem secção anterior.

3. Análise Técnica
Construir um beowulf não é uma tarefa trivial. Não é uma questão de demorar muito ou pouco, mas sim de ser uma tarefa

11
única, onde várias decisões devem ser tomadas e isto faz com que cada novo beowulf seja pelo menos um pouco diferente
do anterior. As características de um cluster beowulf também são muito facilmente afetadas pelo objetivo do cluster, e o tipo
de software que rodará nele.
Primeiro há um processo de seleção principal, que é guiado pelo objetivo principal – um cluster dedicado ou um cluster de
uso genérico. A diferença entre os dois é que um cluster dedicado terá sempre o mesmo software rodando nele 100% do
tempo, sempre com um mesmo e único objetivo; já um cluster genérico é um cluster construído para uso geral, para servir
de plataforma para qualquer projeto que precise de um cluster, como em uma universidade onde ele ficará à disposição dos
alunos por exemplo. No caso do cluster genérico não se sabe necessariamente com antecedência todos os tipos de softwares
que serão executados nele.
A seguir os itens que devem ser considerados:

• software de aplicação

• software de SSI (single system image)

• software de OS (sistema operacional)

• hardware dos nós

• topologia

• hardware de rede

• 100 BaseT ou 10 BaseT com switchers ou hubs

• outro tipo de conectividade

• modalidade de boot

• infraestrutura (energia, ventilação, espaço físico)

Sistemas dedicados geralmente são mais rápidos, menos flexíveis e mais baratos para uma certa configuração de processa-
dor/memória/disco. A geometria geral do sistema pode ser moldada de acordo com a tarefa que se quer realizar. A razão é
simples, sistemas dedicados podem deixar de lado uma série de detalhes sem importância para o caso específico.
No caso de Jacques Mattheij (mailto:jam@truetech.com) cujo projeto pode ser visto no endereço http://www.clustercompute.com/,
ele diz o seguinte: "No meu caso, em minha aplicação específica, existe um altíssimo tempo de boot por nó (mais de um mi-
nuto), mas em compensação depois que os nós estão de pé eles não precisam mais acessar qualquer tipo de disco; desta
maneira, qualquer tráfego que exista na rede será realmente tráfego da aplicação. Pude assim eliminar os discos das estações
e ler toda a informação necessária a partir de um filesystem NFS na hora do boot."
Alguns – ou todos – os ítens da lista anterior podem influenciam uns nos outros de alguma forma. Segue uma lista dos ítens
separados, mas é inevitável alguma superposição:

12
3.1. Software de Aplicação
As aplicações para um beowulf surgem de várias formas, por exemplo um aplicativo feito em casa ou um pacote comprado
pronto, com módulos opcionais (como por exemplo os pacotes prontos de análise de elementos finitos) ou alguma com-
binação destes dois modelos. A maior parte dos clusters roda sistemas caseiros. Alguns rodam por um tempo enorme até
concluir uma tarefa (dias ou meses) e outros são usados para tornar possíveis aplicações de tempo real, que se fossem exe-
cutadas em um sistema menos poderosos não dariam conta de ser de tempo real. Algumas vezes o meio de armazenamento
importa muito, mas isto geralmente não é um problema. Na maioria dos casos a única coisa que realmente importa é poder
de processador. Mas assim que se começa a pensar no resto do cluster, o próximo gargalo não está muito longe: a rede. A
comunicação entre os nós é fortemente relacionada com a aplicação em particular. O software de aplicação pode precisar
saber exatamente em que nó ele está rodando e quem são seus vizinhos diretos. Escrever um software para cluster está longe
de ser fácil. Pequenas mudanças tem impacto imensamente maior do que na programação linear (uma CPU). Por exemplo
uma coisa trivial como uma "barreira" (um ponto de sincronização que todos os nós tem que alcançar antes que qualquer um
deles prossiga além) pode ter um impacto tremendo na velocidade geral do processamento.

3.2. Software de SSI

Software de SSI (single system image) tenta fazer com que o operador/usuário do cluster veja apenas uma única máquina,
que é diferente das outras apenas por ter mais velocidade/memoria/disco, na verdade tornando o cluster uma única entidade
física, tomando conta de coisas como failover, possivelmente migração de processos, etc. Este é um campo atualmente muito
pouco explorado. Não existem ainda pacotes bons o suficiente para fazer tudo isto de forma automática e transparente. Caso
algum leitor encontre algum que julgue ser bom, por favor informe o autor. Quanto mais partes tem um cluster, mais rápido
alguma delas irá falhar. O MTBF de 10 máquinas onde o de cada uma é de 250.000 horas, será de apenas 25.000 horas.
Com 100 nós são 2.500 horas e com 1000 nós são apenas 250 horas antes que, estatisticamente falando, alguma coisa "frite"
(e alguma coisa irá fritar). Então, softwares de SSI, mesmo que pareçam uma luxúria em primeira vista, são realmente
necessários. Um nó deve poder ser retirado do cluster de maneira transparente, e o administrador deve ser avisado sobre o
fato de alguma parte ter falhado sem impacto no resto do cluster. É possível reduzir este problema drasticamente inserindo
"checkpoints" nos cálculos (informaçòes que são escritas no disco ou algum outro lugar, identificando o estado atual dos
cálculos, e permitindo que se reinicie a partir do último checkpoint gravado quando o sistema parar por alguma falha). O
software pode salvar estes checkpoints periodicamente, ou quando alguma fase particular dos calculos for atingida. Ainda
assim, a situação não é a ideal, você deveria poder continuar usando o cluster como uma máquina só (apesar de mais lenta)
até que a máquina defeituosa fosse substituída.

3.3. Software de OS
Existem diversas distribuições que podem ser usadas para construir um cluster beowulf. Pode-se usar desde uma distribuição
completa instalada em cada nó até uma distribuição pequena, lida de um disquete ou via boot remoto, montando filesystem
root remoto ou em ramdisk. A escolha é bastante dependente da aplicação. Para um cluster de uso genérico, provavelmente
o melhor seja tomar uma distribuição padrão e lapidá-la para ficar com o mínimo necessário, que contenha pelo menos todas
as bibliotecas padrões e mais as que a aplicação precisar. Tenha certeza de que todos os nodes são absolutamente iguais, caso
contrário você poderá ter alguns lindos pesadelos debugando seu programa mais tarde.

13
3.4. Hardware dos nós
Cluster dedicado x cluster genérico é um fator importante aqui. Para cada node você tem que decidir sobre colocar ou não
discos rígidos, quanta memória, afinar para maior capacidade de calcular ou maior capacidade de transferência de disco
(granularidade da aplicação); e assim por diante. Se você está planejando um sistema dedicado, estas decisões são mais
simples; para um sistema genérico a regra parece ser ethernet 100 BaseT (usando switchers, veja a seguir), discos rígidos em
todas as máquinas, toda a RAM que o dinheiro permitir, idem com a CPU. Tenha certeza que você está comprando tecnologia
avançada o suficiente – ninguém quer montar um cluster de 100 nós com 486/25, ele simplesmente não vale o quanto pesa.
Um modelo abaixo do topo de linha atual geralmente é uma boa aposta, os preços já não estão mais tão abusivos, e você
terá um bom retorno pelo dinheiro gasto. Use placas mãe multi-processadas caso sua aplicação possa tirar muito proveito
disto; não as use caso sua aplicação precise de muita memória ao invés de muita comunicação (alta granularidade), porque
a largura de banda média memória-processador é simplesmente horrível em um sistema dual, quando os dois processadores
estão fazendo acesso intensivo e simultâneo à memória principal. Pense em maquinas de dois processadores se você tiver
um conjunto limitado de dados – de preferência um que caiba no cache – que tenham que ser trocados entre os nós com
frequência, ou então uma aplicação do tipo "filtro" onde cada um dos nós executa uma fase diferente de um cálculo muito
pesado a partir de um buffer de dados que é repassado de um nó para o outro.

3.5. Hardware de rede

Um sistema dedicado pode ser interligado ponto a ponto, usando-se o conhecimento prévio que se tem sobre o fluxo dos dados
entre os nós. Um sistema genérico quase sempre terá uma configuração padrão, com todos os nos com interfaces ethernet
100BaseT plugados em um switcher. Uma máquina dedicada poderia ter links customizados entre as máquinas, possivelmente
até links "channel bonded" (já citado anteriormente). Com esta configuração você pode alcançar níveis impressionantes de
largura de banda, se precisar até usando gigabit ethernet. Mas fique de olho no uso da banda de cada nó, não faz sentido
ter 2 gigabits/s de banda entre dois nós e usar apenas uma fração disto. Também escolha uma placa de rede que tome conta
do máximo possível do overhead do protocolo por você, para que você possa salvar alguns ciclos de CPU para fazer mais
contas. Algumas tarefas são tão pesadas para a CPU que uma simples rede com barramento estrela será suficiente para aquele
caso. Outro problema pode acontecer se todos os nós chegarem ao resultado ao mesmo tempo, e tentarem usar o barramento
de comunicação ao mesmo tempo. Você terá imensos períodos de subutilização e alguns períodos onde haverá um surto tão
grande de informações tentando trafegar ao mesmo tempo que boa parte delas irá se perder, e precisará ser retransmitida (o
padrão ethernet cuidará disso, mas é importante que você saiba que isto está acontecendo).

3.6. Modalidade de boot

Modalidade de boot é uma escolha difícil. Uma boa escolha é a de boot completo por disquetes – isto permite que você tenhas
várias configurações diferentes sem ter que modificar nada nas máquinas para alternar entre elas. É possível testar uma nova
configuração e retornar para a antiga em alguns minutos se você não gostar do resultado. Troque o disquete, dê um reset, e
pronto. Isto é um enorme benefício para alguns, principalmente no caso de cluster genérico, mas a outras pessoas isso pode
não importar muito. A opção do floppy é realmente ótima para se fazer experimentações com diferentes kernels e diferentes
ferramentas na fase inicial da implantação do cluster.
As opções possíveis são as seguintes:

• Floppy (montando ramdisk e opcionalmente alguns diretorios via nfs)

14
• Disco rigido (instalação padrão)

• Boot remoto (nfs root, usando disquete ou EPROM)

• CD-ROM

• Disco ZIP

Algumas das modalidades são auto-suficientes, outras irão necessitar de um servidor de arquivos na rede. Outras ainda
podem mesclar um pouco dos dois. De qualquer forma, escolha muito bem a modalidade pois esta é uma decisão importante
na montagem de um cluster.

3.7. Intraestrutura
Clusters podem se tornar realmente espaçosos, e isto é um fator que geralmente é ignorado. Deve-se tentar ao máximo criar
um cluster compacto, pois isto facilitará outros pontos da manutenção. Por exemplo, ao invés de usar gabinetes padrões para
cada nó, pode-se usar aqueles gabinetes 1U, 2U ou 3U próprios para hack 19". É possível colocar de 24 a 42 nós dentro de um
hack padrão de altura máxima. Todas esas máquinas ligadas ao mesmo tempo irão gerar um calor tremendo, provavelmente
mais de 100 Watts por nó, por isso, distribuição de energia elétrica e ventilação são fatores muito importantes e devem ser
levados em consideração logo nas fases iniciais do planejamento do cluster. Você precisará de um sistema de ventilação
pesado, que seja capaz de dissipar todo o calo gerado pelo cluster e também o calor gerado por ele mesmo. Se você pretende
ter um UPS (nobreak) lembre-se que ele também gera calor.
Acomodar tudo isto pode ser um pouco complicado sem comprometer a facilidade de acesso e o espaço disponível. O fluxo
de ar dentro da sala deve ser seriamente considerado. Um "canto morto" sem circulação de ar pode mais tarde custar caro:
hardware de reposição, trabalho interrompido e quem sabe até micros tendo que ser comprados às pressas.

3.8. Pré-Requisitos
Não há nenhum pre-requisito especial para se montar um beowulf. Se você mesmo vai usá-lo (criar o software), provavelmen-
te um pré-requisito seria saber programação paralela. Será necessário também uma boa dose de paciência e experimentação
até que tudo esteja funcionando a contento.

3.9. Eficiência
A eficiência do beowulf está diretamente ligada à capacidade do software que está rodando nele de fazer uma boa divisão da
tarefa entre os nós. Esta é a parte mais complicada, mais ainda do que montar o cluster em si. E mesmo depois de tudo parecer
estar ok, pode ser que seja necessário alterar alguma coisa na estrutura do cluster para ajudar o software a se sair melhor. É
uma tarefa difícil, altamente experimental, onde cada caso é um caso. Não há uma regra que garanta que um beowulf não se
sairá pior do que se apenas um dos nós estivesse rodando uma versão não paralela do problema.

15
3.10. Implicações de Segurança
Os beowulfs por definição não tem contato com o mundo externo à sua própria rede. Isto os torna seguros por natureza. A
única preocupação seria entre o nó principal e o resto da rede, mas neste caso se aplicam as regras padrões de segurança
para qualquer rede normal. Como em geral eles são usados em ambientes de pesquisa e por poucas pessoas, segurança
normalmente não é uma preocupação. Em ambientes mais hostis onde possa ser necessário um controle mais severo, pode-se
limitar o acesso ao node principal (que na verdade representa todo o cluster para o mundo externo) da mesma maneira que
se limita o acesso a qualquer máquina em qualquer rede na internet.

4. Implantação
Este é um dos pontos mais problemáticos em um "howto" de beowulfs. Ninguém consegue definir na prática "como" se
monta um, porque as decisões são muitas e cada uma delas pode alterar radicalmente a forma final que o cluster irá tomar.
Acredito que já seja possível se ter uma boa idéia de como isto irá acontecer baseado em todas as informações já citadas,
mas todavia este documento será melhorado em suas próximas versões para tentar trazer algo de concreto nesta secção.
Deveremos identificar algum modelo de cluster genérico o suficiente para ser popular, e o descreveremos aqui.

5. Referências
Alguns sites importantes sobre o projeto beowulf:
Beowulf:
http://beowulf.org/
http://www.beowulf.org/software/software.html
http://beowulf-underground.org/
http://beowulf.gsfc.nasa.gov/
http://www.extremelinux.org/
http://www.xtreme-machines.com/x-links.html
http://smile.cpe.ku.ac.th/tools/
http://smile.cpe.ku.ac.th/tools/bwfaq2.htm
http://www.linuxdoc.org/HOWTO/Beowulf-HOWTO.html
http://www.mosix.cs.huji.ac.il/
http://noel.feld.cvut.cz/magi/soft.html
Bibliotecas:
http://www.epm.ornl.gov/pvm/

16
http://www.netlib.org/pvm3/book/pvm-book.html
http://www-unix.mcs.anl.gov/mpi/mpich/index.html
http://www.mpi.nd.edu/lam/
http://www.globus.org/
Compiladores e schedulers:
http://www.absoft.com/
http://www.pgroup.com/
http://www.nag.com/
http://egcs.cygnus.com/
http://www.scri.fsu.edu/~pasko/dqs.html
http://www.cs.utk.edu/~ghenry/distrib/archive.htm
http://w272.gsfc.nasa.gov/~udaya/Public/software/bview/bview.html
http://www.sci.usq.edu.au/staff/jacek/bWatch/
http://www.beowulf.org/software/bproc.html
http://www.sc.cs.tu-bs.de/pare/results/procps.html
http://smile.cpe.ku.ac.th/software/scms/index.html
http://ece.clemson.edu/parl/pvfs/
http://www.lsc-group.phys.uwm.edu/~www/docs/beowulf/os_updates/fastMath.html
ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils/disk-less/
ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils/misc_scripts/
http://www.plogic.com/bert.html
http://goof.com/pcg/
Documentos relacionados:
http://www.phy.duke.edu/brahma/#boilerplate
http://www.sci.usq.edu.au/staff/jacek/beowulf/BDP/HOWTO/
http://www.lsc-group.phys.uwm.edu/~www/docs/beowulf/Proto-slave/autoinstall.html
http://www.lsc-group.phys.uwm.edu/~www/docs/beowulf/Slave/Slave_build.html
http://beowulf.gsfc.nasa.gov/howto/howto.html
http://lcdx00.wm.lc.ehu.es/~svet/beowulf/howto.html
http://www.cacr.caltech.edu/research/beowulf/tutorial/beosoft/
http://smile.cpe.ku.ac.th/smile/beotalk/index.htm
http://smile.cpe.ku.ac.th/beowulf/index.html

17
http://www.sci.usq.edu.au/staff/jacek/beowulf/BDP/BIAA-HOWTO/
Livros:
How to build a Beowulf, MIT Press

6. Anexos

6.1. FAQ do Beowulf

1. Onde posso obter software para beowulf?

Não existe um pacote de software chamado "Beowulf". Existem, todavia, diversos pequenos softwares que muitas pes-
soas acharam úteis para montar os beowulfs. Nenhum deles é essencial. Eles incluem: MPICH, LAM, PVM, DIPC, o
kernel do linux, o patch de "channel bonding" para o kernel do linux e o patch de PID global para o kernel do linux.

2. Posso pegar meu software normal e colocá-lo no beowulf para que ele rode mais rápido?
Não. Talvez, se você trabalhar um pouco em cima dele. Você precisará modificá-lo para que ele trabalhe com tarefas
paralelas que se comunicam entre si usando uma das bibliotecas de passagem de mensagens (MPI ou PVM) ou então
sockets de network ou SysV IPC. Então você precisará recompilá-lo.
Sim, caso o seu programa rode repetidamente, cada vez com arquivos de dados diferentes (processamento paramétrico).
Neste caso pode ser que apenas alguns scripts resolvam seu caso, e seu software rode _muito_ mais rápido.
Mesmo softwares que já tem suporte a múlpliplas threads (que se utilizam de memória compartilhada em máquinas
multi-processadas) não haverá ganho automático de performance. Existem alguns pacotes de memória compartilhada
distribuída em desenvolvimento (DIPC, Mosix, ...), mas o padrão de acesso à memória em um software escrito para
máquinas multiprocessadas poderia potencialmente ocasionar em _perda_ de performance em uma máquina que esteja
usando memória compartilhada distribuída.

3. PVM? MPI? Hãã?

PVM (Parallel Virtual Machine) e MPI (Message Passing Interface) são softwares que permitem que você escreva
programas paralelos que passam mensagens entre si para poder rodar em um cluster, em Fortran ou C. PVM costumava
ser o padrão até que o MPI apareceu. Mas o PVM ainda é largamente usado e realmente bom. MPI é o padrão para
bibliotecas portáveis entre sistemas, padrinizado pelo Fórum MPI e disponível em uma série de arquiteturas diferentes.
Aos poucos está se tornando realmente o padrão sobre o PVM.

4. Existe um compilador que irá automaticamente paralelizar meu código para rodar em um beowulf?
Não. Existe uma ferrament chamada BERT, da "plogic.com" que irá ajudá-lo a paralelizar manualmente seu código
de Fortran. Os compiladores do Portland Group e do NAG irão compilar versões paralelas do seu código se você der
algumas dicas sobre a lógica do código. Mas não há nada que garanta que estas versões irão rodar mais rápido do que as
versões não paralelas do mesmo código.

5. Porque as pessoas usam Beowulfs?

18
 Ou porque elas acham que isso é legal ou porque elas obtém performance de supercomputador por um terço a um décimo
do preço de um supercomputador tradicional.

6. Alguém possui um database que irá rodar mais rápido em um Beowulf que em uma única máquina?
Não. A Oracle e a Informix tem databases que podem até fazer isto algum dia (databases distribuídos), mas eles ainda
não fazem isto em linux.

7. Os operadores de clusters beowulf usam switchers para teclado, mouse e vídeo para os nós?
A maioria deles não usa, porque eles não são necessários. Como os nós estão rodando linux, é possível abrir um shell
remoto para qualquer uma das máquinas, a menos que elas estejam com problemas. A maioria dos beowulfs não tem
nem mesmo placas de vídeo. O acesso físico ao nó (console) só é necessário quando o nó está tão problemático que ele
não irá nem mesmo dar o boot no sistema operacional.

8. Existe algum compilador para linux que reconheça partes de código que poderiam ser otimizadas usando-se extensões
como KNI, 3DNow! ou MMX?
Não. Bem... o compilador PentiumGCC tem algum suporte para isto.

9. Posso contruir um cluster com meus 100 386s?

Se para você não houver problemas em no fato de que ele vai ficar mais lento que um Celeron-333, vá em frente. Pelo
menos será uma ótima maneira de aprender.

10. Preciso rodar Conectiva Linux?

Não. O beowulf original rodava Slackware. Rode o que achar melhor.

11. Então posso usar o Extreme Linux CD?

Menos este!! Ele está desatualizado há muito tempo.

12. Um beowulf precisa da glibc?

Não. Mas sua aplicação vai precisar. Se ela está preparada para usar libc5, então você não precisará da glibc. Seja como
for, configure todos os nós da mesma forma, senão você poderá ter uma grande dor de cabeça.

13. Quais os compiladores existentes?

Família GCC, Portland Group, KAI, Fujitsu, Absoft, PentiumGCC, NAG, Compaq está liberando compiladores para
AlphaLinux (que são reconhecidamente excelentes), e outras pessoas já usam Digital Unix para compilar seus programas
e depois rodar no AlphaLinux.

14. O que é mais importante, velocidade da CPU, velocidade da memória, velocidade do disco, tamanho do disco ou largura
de banda da rede? Devo usar máquinas bi-processadas? Devo usar Alphas, PowerPCs, ARMs ou x86s? Devo usar Xeons?
Devo usar Fast Ethernet, Gigabit ethernet, Myrinet, SCI, FDDI? Devo usar hubs ou switchers?
DEPENDE DA SUA APLICAÇÃO!!!
Faça um benchmark, verifique tudo, ache aonde está o gargalo, conserte, e repita.
Algumas pessoas tem dito que máquinas bi-processadas tem escalam melhor do que as mono processadas porque um
processador por continuar fazendo os cálculos ininterruptamente enquanto o outro se preocupa em tratar todas as inter-
rupções de rede.

19
15. Posso fazer um beowulf com diferentes tipos de máquinas – mono-processadas e bi-processadas, 200mhz, 400mhz, etc.?
Claro que sim. Distribuir sua aplicação de forma ótima vai ser muito mais complicado, mas não é impossível.

20