Brincando de cluster 

Carlos E. Morimoto criou 7/jul/2007 às 23h16

Introdução

Você pode ter um cluster em casa. A utilidade seria questionável na maioria do tempo, mas você pode
configurá-lo em menos de 5 minutos usando alguns micros ligados em rede.

Por mais estranha que esta afirmação possa parecer, é a mais pura verdade. É possível ter um cluster
configurado em menos de 5 minutos utilizando o ClusterKnoppix, uma distribuição baseada no Knoppix
(irmãozinho do Kurumin :-) que vem com um servidor OpenMosix configurado para rodar direto do CD.

Em primeiro lugar, de que tipo de cluster estamos falando? Esta palavra é um tanto quanto genérica é
usada em várias situações onde temos um conjunto de aparelhos trabalhando em conjunto. Por
exemplo, uma outra forma de clustering é suportada por alguns no-breaks destinados a servidores, onde
dois aparelhos podem ser ligados para combinar suas capacidades. Dois no-breaks de 2 KVA podem
formar um no-break de 4 KVA e assim por diante.

Mas, sendo um pouco mais específico, existem basicamente três aplicações para um cluster de micros
PCs. A primeira e provavelmente a mais usada é a tolerância a falhas, onde temos dois ou mais PCs
ligados entre sí. O primeiro PC faz todo o trabalho enquanto o segundo se limita a manter seus dados
atualizados em relação ao primeiro e a monitorá-lo constantemente. Se o primeiro PC sair do ar por
qualquer motivo, o segundo imediatamente assume suas funções. Esta tecnologia é muito usada em
servidores Web e servidores de banco de dados em Intranets.

A segunda aplicação é o balanceamento de carga, usada principalmente em servidores Web. Neste caso
temos pelo menos três PCs, onde o primeiro recebe todas as requisições e se encarrega de dividí-las
entre os demais PCs. Ao invés de ter apenas um super-servidor caríssimo, você pode usar vários PCs
baratos para fazer o mesmo trabalho.

A terceira aplicação é o processamento paralelo, onde brilham os famosos clusters Beowulf. Este tipo de
cluster é muito útil em aplicações científicas, assim como animações e efeitos destinados a filmes onde
existe um gigantesco volume de dados a ser processado. O trabalho é dividido em pequenas partes,
processado de forma distribuída e depois o quebra cabeças é montado, gerando o trabalho final.

Os clusters Beowulf são muito famosos pelo seu uso na NASA, em várias universidades, na renderização
das cenas de filmes como StarWars ep. 2, Final Fantasy (entre muitos outros) e assim por diante.
Configurar um cluster Beowulf não é nenhum bicho papão, você poderia configurar um se quisesse, mas
existe um pequeno detalhe que os torna pouco úteis em ambientes domésticos: é possível processar
quantidades fabulosas de dados, mas apenas ao utilizar aplicativos escritos com suporte à arquitetura.
Isto não é um grande problema para as universidades ou grandes estúdios, que geralmente cuidam de
grande parte do desenvolvimento dos programas e podem portá-los, mas não é uma alternativa viável
na maioria dos casos.

Os clusters OpenMosix seguem uma idéia diferente, que os torna mais adequados para o uso geral. Ao
invés de dividir processamento dentro de um mesmo programa (o que exigiria que o programa seja
portado e otimizado) vários programas diferentes, ou várias instâncias do mesmo programa migram
para os outros nós do cluster e são executados em paralelo de uma forma transparente para o usuário.
A vantagem é que o sistema funciona com os programas que você já usa no dia a dia, não é preciso sair
caçando aplicativos especiais. Imagine que você tente comprimir dois vídeos em Divx ao mesmo tempo,
abrindo duas instâncias do mesmo programa de compressão. A primeira instância continuará rodando no
seu PC, mas a segunda migrará para o outro nó da rede. Se os dois PCs tiverem mais ou menos o
mesmo desempenho você terá os dois vídeos compactados quase que no tempo de um.

O sistema envia uma cópia do programa para o segundo nó, e em seguida passará a alimentá-lo com os
dados necessários. Ao invés de ter todo o trabalho de comprimir o segundo vídeo, o seu PC receberá
apenas os resultados mastigados. Veja que para comprimir um vídeo em divx é necessário uma
quantidade absurda de processamento, um DVD de duas horas demora cerca de 11 horas num Athlon
de 1.0 GHz.

Em compensação, temos uma quantidade relativamente pequena de dados, cerca de 4 GB para a

imagem do DVD (os dados são transmitidos ao longo das 11 horas, o que daria uma média de 103 KB/s)
e no final temos gerado um arquivo menor ainda, que pode ser transmitido facilmente através da rede.
O mesmo acontece se você estiver comprimindo audio, renderizando cenas 3D ou outras tarefas onde
seja necessária uma grande quantidade de processamento.

Você não precisa fazer nada para que os processos migrem. Cada micro roda uma distribuição Linux
completa, com um pequeno cliente OpenMosix que monitora o nível de carregamento dos demais nós da
rede. O software inclui um conjunto de funções que "decidem" quais programas são bons candidatos a
serem migrados, baseado no nível de carregamento do sistema e no tipo e quantidade de dados
manipulados por eles. Outra coisa que é levada em conta é o desempenho de cada micro disponível na
rede: o software sempre procura o micro onde a tarefa possa ser processada mais rapidamente.

Se você está usando um Celeron 366 mas existe um Athlon XP 2200+ disponível do lado, ele é quem
acabará recebendo a maior parte do trabalho, fazendo com que além de realizar as tarefas muito mais
rápido, o seu Celeron fique bem mais leve :-)

Mas, por outro lado, tarefas que envolvem uma carga muito grande de I/O, como por exemplo assistir
um vídeo em Divx ou um DVD ou rodar um servidor de banco de dados por exemplo nunca são
migradas automaticamente. Mesmo que você forçasse a tarefa a migrar para outro nó manualmente, o
desempenho provavelmente acabaria sendo inferior ao original.

Vamos imaginar o que aconteceria se você tentasse migrar um processo do mPlayer ou do Xine que está
exibindo aquele filme em divx que você baixou ontem. Normalmente o filme é descomprimido cena por
cena, gerando bitmaps que são exibidos pela placa de vídeo. Num filme com resolução de 640x480 por
exemplo temos 614 KB por quadro (se forem usados 16 bits de cor) e geralmente 25 quadros por
segundo o que vai dar uma transmissão de pouco mais de 15 MB/s para o vídeo e mais 88 KB/s para o
áudio. Se o vídeo estiver sendo processado localmente os dados vão direto para a placa de vídeo e a
quatidade de dados não é problema, já que o barramento PCI transmite a 133 MB/s e o AGP atinge
muito mais.

Mas, se você migrar o processo para outro máquina da rede os cálculos já ficam mais apertados. Uma
rede de 100 megabits permite uma taxa de transmissão teórica de 12.5 MB/s mas na prática sempre
temos um pouco menos. É preciso ao mesmo tempo enviar os dados a serem descomprimidos junto com
outras informações e receber os quadros e áudio prontos para serem exibidos. No final você acabará
com uma utilização muito alta da rede, atrapalhando o trabalho dos outros micros e ainda por cima um
vídeo falhado. Com uma conexão full-duplex (100 Mb de upload e 100 Mb de download simultâneos) o
cenário já seria mais confortável, mas ainda assim seria difícil ver o vídeo com qualidade.

Embora não seja a solução pra tudo, o OpenMosix é uma solução interessante pois não é necessário ter
nós dedicados. Você pode manter o cliente OpenMosix (que é ao mesmo tempo um servidor) nas
máquinas da sua rede, de forma que os ciclos livres de uma sejam usados para processar dados
enviados por outras máquinas. O OpenMosix não ajuda muito nas tarefas do dia a dia, como editar um
arquivo no OpenOffice, jogar Unreall 2003 ou abrir um monte de páginas no Mozilla, mas pode ajudar
bastante em tarefas mais pesadas, que são afinal onde você realmente precisa de mais desempenho.
A página oficial do OpenMosix é a:

http://www.openmosix.org​ ou ​http://openmosix.sourceforge.net/

Para funcionar é preciso um módulo compilado no Kernel. Em muitos casos as distribuições já vem com
o modulo pronto na forma de um pacote instalável mas em outros é preciso recompilar o Kernel
adicionando o patch do OpenMosix. Existe um arquivo muito bom sobre a instalação do OpenMosix em
várias distribuições disponível aqui: ​http://howto.ipng.be/openMosix-HOWTO/​.

O ClusterKnoppix é uma versão customizada do Knoppix que inclui uma instalação do OpenMosix pronta
pra usar. Ele é tão plug-and-play quanto o Knoppix original, basta dar boot em alguns PCs ligados em
rede, abrir o programa monitor e os nós começarão a se comunicar e trocar processos entre sí. Se você
só tiver um CD, existe ainda a possibilidade de dar boot nos demais PCs via rede, via PXE.

A página do ClusterKnoppix é: ​http://bofh.be/clusterknoppix/​. A imagem do CD tem quase 700, o

mesmo tamanho do Knoppix original e por enquanto está disponível apenas via bittorrent. Se você
nunca usou, dê uma olhada no meu artigo aqui: ​http://www.guiadohardware.info/artigos/259/

Depois de dar boot com o CD em todos os micros, use o ping para verificar se a rede está funcionando.
O Knoppix configura a rede via DHCP durante o boot. Se não houver nenhum servidor disponível você
pode configurar a rede manualmente em cada micro no Iniciar > Knoppix > Network/Internet > Network
card configuration.

Assim que a rede estiver configurada, o cluster é formado automaticamente. Abra um terminal, use o
"su" para virar root e chame o comando "​openmosixmigmon​". A janela mostra os nós do cluster, junto
com seus respectivos endereços IP. O que está no centro é o seu micro, os pontos pretos em volta dele
são os processos que estão sendo executados e os pontos verdes mostram os processos que migraram
para outros nós do cluster:

Se você arrastar um dos pontos para outro nó, o programa tentará migrá-lo, mas você logo vai perceber
que a maioria dos processos de sistema não pode ser migrada. Por outro lado, muitos dos programas
que você abrir serão imediatamente migrados, mesmo sem a sua intervenção.
Um outro programa útil é o "​openmosixview​". Ele mostra o nível de carregamento de cada um dos nós
do cluster. O "13667" na linha do nó 234 mostra seu índice de desempenho (não muito apurado) que é
usado para determinar quais nós devem receber trabalho primeiro. O nó 250 aparece em vermelho pois
ele já fez parte do cluster, mas está no momento desligado ou desconectado da rede.

Se você estiver usando o micro mais rápido do cluster vai perceber que os processos demoram a migrar,
mesmo que os outros PCs estejam livres. A idéia básica é executar as tarefas o mais rápido possível,
então se o seu micro é o mais rápido é normal que elas sejam executadas nele. Mas, você pode alterar o
índice de desempenho do seu micro, fazendo com que o monitor passe a considerá-lo mais lento que os
demais e migre o máximo de processos possível.

Experimente usar o comando:

mosctl setspeed 1000

Existe um outro programa mais simples chamado "​mosmon​", que mostra um gráfico simples, em modo
texto indicando o nível de carregamento

de cada nó. Aqui estou rodando duas instâncias do ​kandel​, um programa gerador de factrais que faz
parte da distribuição. Ele é um bom exemplo de programa que se beneficia do cluster pois seu trabalho
envolve um quase nada de dados e um mundo de processamento. Abrindo duas instâncias do Kandel
cada um dos nós do cluster fica com uma:

De volta ao ​openmosixview​, abra o openmosixcollector em Collector > openMosixCollector > Start. Ele
é um daemon que monitora a atividade do cluster e gera um log que depois pode ser examinado usando
as outras ferramentas do openmosixview.

Clicando sobre o botão com o endereço IP de qualquer um dos nós você tem acesso a um menu de
configuração, onde você pode desabilitar a migração automática de processos para um determinado nó
da rede (uma máquina lenta por exemplo) entre outras opções. Esta configuração pode ser salva, mas
isso só será útil se você estiver usando o ClusterKnoppix instalado no HD (a instalação é idêntica à do
Knoppix normal) caso contrário você perde tudo ao reiniciar a máquina.

Obs: Embora o sistema de arquivos apareça como opção durante a instalação do ClusterKnoppix, a
instalação vai falhar se você escolhê-lo. Versões antigas do ClusterKnoppix também tinham problemas
com o Ext3 (bug que já foi corrigido segundo o chage-log), por isso o ideal é que ao instalar no HD você
escolha o sistema de arquivos ReiserFS.

Ainda no openmosixview, clique no File > Run Program e escolha um executável qualquer (a maioria dos
programas está na pasta /usr/bin ou /usr/share). Você cairá no menu de execução avançada, onde você
pode definir em qual nó do cluster o programa será executado (opção "run on") especificar que o
programa utiliza muito processamento e por isso é um candidato a ser migrado rapidamente ("cpu job")
ou que ele executa principalmente tarefas que envolvem grandes quantidades de dados ("io job") e que
por isso não deve ser migrado:
Outro programa interessante é o "​openmosixprocs​" que mostra uma lista dos processos que estão
rodando e permite gerenciar os processos que migraram para outras máquinas:
Clicando sobre um processo qualquer na lista principal você tem a opção de envia-lo para outra máquina
ou mesmo fechá-lo:
Se você tiver apenas um CD do cluster Knoppix, ou não tiver drive de CD em todas as máquinas, é
possivel configurar o micro com o CD-ROM para atuar como um servidor de boot remoto para os demais
micros da rede, via PXE. O atalho está em: Iniciar > Knoppix > Services > Start Knoppix OpenMosix
Terminal Server.

O Wizard configurará o servidor para atender os chamados dos clientes e fornecer a eles os arquivos do
CD (via NFS) para que eles possam dar boot através da rede. Este sistema é basicamente o mesmo
utilizado pelo LTSP e pelo Kurumin Terminal Server, a diferença é que os clientes carregam todo o
sistema do servidor e rodam os aplicativos localmente ao invés de passarem a atuar como terminais
burros do servidor.

A configuração é bem simples. Ele pergunta a faixa de endereços IP que será reservada para os clientes
remotos e em seguida pede que você escolha os módulos das placas de rede usadas nos clientes. Você
pode marcar quantos módulos achar necessário (em caso de dúvida por exemplo), o único inconveniente
é que com muitos módulos ativos o servidor consumirá um pouco a mais de memória RAM.

A seguir você terá a opção de ativar mais alguns recursos:

A opção "textmode" faz com que os clientes não careguem o modo gráfico durante o boot, deixando
mais memória RAM disponível para rodar os aplicativos. Esta opção é interessante apenas caso você
queira deixar os outros clientes disponíveis para receber processos, sem que ninguém os use.

As opções Masq, DNS e Squid cache/Proxy ativam o compartilhamento da conexão com a Intenret para
os clientes. Estas opções são necessárias apenas caso o servidor esteja acessando diretamente a
internet. Se todos os micros, incluindo o servidor estiverem atrás de um outro micro que compartilha a
conexão ou caso você não pretenda acessar a Internet, as três podem ficar desativadas.

A última tela permite que você passe parâmetros de boot para as máquinas clientes, aquelas mesmas
opções que podem ser usadas na tela de boot do Knoppix para ativar a rodinha do mouse (whellmouse),
forçar uma determinada resolução de tela (screen=1024x768) e assim por diante.

A maioria das placas mãe atuais, sobretudo as com rede onboard (PC-chips incluídas) suportam boot via
rede utilizando o protocolo PXE. Você precisa apenas configurar a sequência de boot no Setup ou
pressionar F8 (ou F12, dependendo da placa) durante a contagem de memória. O isso fará o cliente
enviar um pacote de broadcast pela rede, que será respondido pelo servidor, dando sequência ao
carregamento normal do sistema.
O cliente vai se comportar quase da mesma forma que se comportaria caso estivesse com o CD do
ClusterKnoppix no drive. Também não existe muita diferença de desempenho, pois numa rede de 100
megabits o gargalo é a velocidade de leitura do CD-ROM e não a rede. Seria preciso um leitor de quase
100X para atingir uma taxa de leitura próxima de 12.5 MB/s.

Seja bem vindo ao mundo dos Clusters :-)