Brincando de cluster

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 640×480 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:

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=1024×768) 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 🙂