Você está na página 1de 8

Construa seu proprio Cluster Beowulf em casa.

No seguimento deste tópico encontra-se a "construção" de um super


computador, um cluster Beowulf.

Definição

Um cluster, ou aglomerado de computadores, é formado por um conjunto de


computadores que utiliza-se de um tipo especial de sistema operacional
classificado como sistema distribuído.

É construído muitas vezes a partir de computadores convencionais


(personal computers), sendo que estes vários computadores são ligados em
rede e comunicam-se através do sistema de forma que trabalham como se
fosse uma única máquina de grande porte. Há diversos tipos de cluster. Um
tipo famoso é o cluster da classe Beowulf, constituído por diversos nós
escravos gerenciados por um só computador.

História

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


pela IBM como uma forma de interligar grandes mainframes, visando obter
uma solução comercialmente viável de paralelismo.

Nesta época o sistema HASP (Houston Automatic Spooling Priority) da IBM e


seu sucessor, JES (Job Entry System) proviam uma maneira de distribuir
tarefas nos mainframes interligados. A IBM ainda hoje (2001) suporta o
cluster de mainframes através do Parallel Sysplex System, que permite ao
hardware, sistema operacional, middleware e software de gerenciamento do
sistema prover uma melhora dramática na performance e custo ao permitir
que usuários de grandes mainframes continuem utilizando suas aplicações
existentes.

Entretanto o cluster ganhou força até que três tendências convergiram nos
anos 1980: microprocessadores de alta performance, redes de alta
velocidade, e ferramentas padronizadas para computação distribuída de
alto desempenho. Uma quarta tendência possível é a crescente necessidade
de poder de processamento para aplicações científicas e comerciais unida
ao alto custo e a baixa acessibilidade dos tradicionais supercomputadores.

No final de 1993, Donald Becker e Thomas Sterling iniciaram um esboço de


um sistema de processamento distribuído construído a partir de hardware
convencional como uma medida de combate aos custos dos
supercomputadores. No início de 1994, trabalhando no CESDIS, com o
patrocínio do projecto HTPCC/ESS, criaram o primeiro cluster desse tipo, o
projeto Beowulf.

1
O protótipo inicial era um cluster de 16 processadores DX4 ligados por dois
canais Ethernet acoplados (Ethernet bonding). A máquina foi um sucesso
instantâneo e esta idéia rapidamente se espalhou pelos meios acadêmicos,
pela NASA e por outras comunidades de pesquisa.

Montagem física do Cluster

Para a confecção do cluster nós escolhemos utilizar quatro máquinas sendo


1 master e 3 slaves, para isso foram definidos os seguintes hardwares para
as máquinas:

Master
Athlon XP 2800 +, 1024 MB de RAM, HD 40 GB, PCI LAN Realtek pci 10/100

Slave1
Pentium II 350 Mhz, 192 MB de RAM, HD 6,2 GB, PCI LAN Realtek pci 10/100

Slave2
Pentium D 4 3,06 Ghz, 1024 MB de RAM, HD 80 GB, PCI LAN Realtek pci
10/100

Slave3
Athlon XP 1100+, 1024 MB de RAM, HD 80 GB, PCI LAN Realtek pci 10/100

Configurações básicas e principal

Durante a configuração e instalação do sistema operacional das máquinas


que iriam compor o cluster fora utilizado a distribuição Linux Fedora Core 4,
kernel 2.4.6, depois desse ponto começamos a configurar alguns arquivos
de grande importância.

O primeiro passo foi configurar a rede nas máquinas do cluster, que


estavam dispostas em uma topologia estrela utilizando de uma rede
Ethernet 100 Mbits/s, ligadas com cabo UTP categoria 5 padrão 568A,
ligadas a um switch 100/100 de oito portas. Segue abaixo a configuração
das máquinas.

Master
IP: 99.99.99.40/255.255.255.0

Slave1
IP: 99.99.99.41/255.255.255.0

Slave2
IP: 99.99.99.42/255.255.255.0

Slave3

2
IP: 99.99.99.43/255.255.255.0

Além de arquivos do tipo hosts que funcionam como servidor de DNS para
comunicação entre as máquinas.

/etc/hosts

Master master.linusbera
Slave1 slave1.linusbera
Slave2 slave2.linusbera
Slave3 slave3.linusbera

/etc/hosts.equiv (arquivo que define a confiança entre as máquinas)

Master
Slave
Slave1
Slave2
Slave3

/home/.rhosts

.rhosts
Master
Slave1
Slave2
Slave3

/root/.rhosts

.rhosts
Master
Slave1
Slave2
Slave3

/etc/securetty (arquivo indicado para comunicação entre as máquinas sem a


necessidade de senha)

rsh
ssh
rlogin

Configuração servidor de tempo (NTPD)

A configuração do servidor de tempo tem função vital no cluster, já que na


estrutura do cluster entre as máquinas não pode existir uma diferença de

3
sincronismo maior que vinte minutos, fazendo assim a configuração de um
servidor de tempo vital para o funcionamento do cluster, segue abaixo as
configurações utilizadas:

Master:

/etc/ntp.conf

server 127.0.0.1 prefer


fudge 127.0.0.1 stratum 0
driftfile /etc/ntp/drift
authenticate no

Slaves:

/etc/ntp.conf

server 99.99.99.40
driftfile /etc/ntp/drift
authenticate no

Servidor de NFS

Este serviço serve para fazer o espelhamento das pastas definidas entre as
máquina do cluster, fazendo um sincronismo entre as pastas afim de que
todas contenham os mesmo arquivos.

Master:

/etc/exports

/usr/local *(rw,no_root_squash)

Slaves:

Acrescentar ao final do arquivo /etc/fstab a seguinte linha:

99.99.99.40:/usr/local /usr/local nfs exec,dev,suid,rw 1 1

Protocolos de comunicação

Para comunicação entre as máquinas foram utilizados os pacotes de RSH,


RLOGIN e SSH.

Programação Paralela (MPI, MPICH)

O MPI (Message Passing Interface) é constituído por um padrão de troca de

4
mensagens com sintaxe definida, mas preservando características
exclusivas de cada arquitetura, inclusive para arquiteturas de memória
compartilhada.

O principal objetivo do MPI é otimizar a comunicação e aumentar o


desempenho computacional das máquinas, não possuindo dessa forma
gerenciamento dinâmico de processos e processadores.

Embora exista a restrição citada acima, os programas escritos em MPI


tendem a serem mais eficientes pelo fato de não haver overhead na carga
de processos em tempo de execução.

Funcionamento do MPICH

O MPI funciona da seguinte forma: cada máquina (node) recebe uma copia
do código fonte e um nome. Cada node começa a executar o programa a
partir da primeira linha de comando utilizando as seguintes diretrizes:

Executar todas as linhas de comando não nomeadas;

Executar as linhas de comando nomeadas com o mesmo nome do node;

Não executar as linhas de comando com o nome de outro node.

Para que o programa siga essas diretrizes, o que é feito é a inclusão de


vários comandos if, com a seguinte estrutura:

"Se eu sou o nodo tal, faço isso... Se não faço aquilo...". (FONTE: Pitanga,
2004)

A grande dificuldade que esse sistema acarreta é a necessidade de manter


os diversos processos de troca de informações em sincronismo, para que
uma máquina não perca muito tempo aguardando que as outras máquinas
enviem informações.

Instalando o MPI/MPICH

Salvar o arquivo mpich.tar.gz na pasta /usr/local. Execute as seguinte linha


de comando:

# tar -zxvf mpich.tar.gz


# cd /usr/local/mpich-1.2.7
# ./configure --prefix=/usr/local
# make
# make install

Testando aplicação em MPI

5
# cd /usr/local/examples

Código em C:

O código fonte utilizado em nossa aplicação foi o cpi.c, que calcula o valor
aproximado de Pi. O mesmo é incluso no pacote mpich.tar.gz, localizado em
#usr/local/mpich-1.2.7/examples/basic.

#include "mpi.h"
#include <stdio.h>
#include <math.h>

double f( double );
double f( double a )
{
return (4.0 / (1.0 + a*a));
}

int main( int argc, char *argv[])


{
int done = 0, n, myid, numprocs, i;
double PI25DT = 3.141592653589793238462643;
double mypi, pi, h, sum, x;
double startwtime = 0.0, endwtime;
int namelen;
char processor_name[MPI_MAX_PROCESSOR_NAME];

MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
MPI_Get_processor_name(processor_name,&namelen);

fprintf(stderr,"Process %d on %s\n",
myid, processor_name);

n = 0;
while (!done)
{
if (myid == 0)
{
/*
printf("Enter the number of intervals: (0 quits) ");
scanf("%d",&n);
*/
if (n==0) n=100; else n=0;

startwtime = MPI_Wtime();

6
}
MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);
if (n == 0)
done = 1;
else
{
h = 1.0 / (double) n;
sum = 0.0;
for (i = myid + 1; i <= n; i += numprocs)
{
x = h * ((double)i - 0.5);
sum += f(x);
}
mypi = h * sum;

MPI_Reduce(&mypi, π, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD);

if (myid == 0)
{
printf("pi is approximately %.16f, Error is %.16f\n",
pi, fabs(pi - PI25DT));
endwtime = MPI_Wtime();
printf("wall clock time = %f\n",
endwtime-startwtime);
}
}
}
MPI_Finalize();

return 0;
}

Compilando código em mpi C:

# mpicc cpi.c -o cpi

Executando o código, observando que o atributo do comando "-np" indica o


número de processos que serão distribuídos no cluster.

# mpirun -np 4 cpi


pi is approximately 3.1416009869231254, Error is 0.0000083333333323
wall clock time = 0.000238

Monitoramento cluster

Para monitorar o cluster foi utilizado uma ferramenta chamada bWatch, para
instalar esta ferramenta faça:

7
Copie o arquivo bWatch.tar.gz para a pasta /usr/local. Execute os comandos:

# tar -zxvf bWatch.tar.gz


# cd bWatch-1.1.0
# make bWatch
# bWatch.tcl

Resultados e conclusões

Problemas encontrados

Durante o desenvolvimento das atividades do cluster o primeiro grande


problema foi encontrar um material que nos desse base em cima de como
montar o cluster, apesar de conseguir um livro dirigido a confecção do
cluster e alguns artigos na internet, mas nenhum deles continham o que
fazer corretamente, mas em todos eles faltavam alguns pontos, mas no fim
tudo deu certo e o cluster funcionou.

Outro problema que foi identificado no cluster é que os algoritmos que


executamos quando apesar realizados na máquina master era mais rápido
que distribuído no cluster, mas quando procuramos saber o porquê desse
fato, foi que descobrimos que o delay na rede era maior que o tempo de
processamento, ou seja, para que isso não aconteça o algoritmo a ser
rodado no cluster tem de ser grande e pesado, pois senão não será visível o
ganho de processamento no cluster.

Considerações finais

Com este projeto concluímos que ainda a utilização dos clusters tem apenas
fins educacionais e/ou de pesquisas, como grandes cálculos,
comercialmente ainda o cluster não tem grande utilização nem oferece
grandes vantagens, mas com o crescimento das informações logo serão
necessários clusters em qualquer lugar.