Вы находитесь на странице: 1из 7

Brincando de cluster :-)

Artigos
Voc pode ter um cluster em casa. A utilidade seria questionvel 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 afirmao possa parecer, a mais pura verdade. possvel ter um cluster configurado em menos de 5 minutos utilizando o ClusterKnoppix, uma distribuio baseada no Knoppix (irmozinho do Kurumin :-) que vem com um servidor OpenMosix configurado para rodar direto do CD.Carlos E.
Morimoto 04/06/2003

Voc pode ter um cluster em casa. A utilidade seria questionvel 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 afirmao possa parecer, a mais pura verdade. possvel ter um cluster configurado em menos de 5 minutos utilizando o ClusterKnoppix, uma distribuio baseada no Knoppix (irmozinho 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 genrica usada em vrias situaes 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 especfico, existem basicamente trs aplicaes para um cluster de micros PCs. A primeira e provavelmente a mais usada a tolerncia 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 relao ao primeiro e a monitor-lo constantemente. Se o primeiro PC sair do ar por qualquer motivo, o segundo imediatamente assume suas funes. Esta tecnologia muito usada em servidores Web e servidores de banco de dados em Intranets. A segunda aplicao o balanceamento de carga, usada principalmente em servidores Web. Neste caso temos pelo menos trs PCs, onde o primeiro recebe todas as requisies e se encarrega de divid-las entre os demais PCs. Ao invs de ter apenas um super-servidor carssimo, voc pode usar vrios PCs baratos para fazer o mesmo trabalho. A terceira aplicao o processamento paralelo, onde brilham os famosos clusters Beowulf. Este tipo de cluster muito til em aplicaes cientficas, assim como animaes e efeitos destinados a filmes onde existe um gigantesco volume de dados a ser processado. O trabalho dividido em pequenas partes, processado de forma distribuda e depois o quebra cabeas montado, gerando o trabalho final. Os clusters Beowulf so muito famosos pelo seu uso na NASA, em vrias universidades, na renderizao das cenas de filmes como StarWars ep. 2, Final Fantasy (entre muitos outros) e assim por diante. Configurar um cluster Beowulf no nenhum bicho papo, voc poderia configurar um se quisesse, mas existe um pequeno detalhe que os torna pouco teis em ambientes domsticos: possvel processar quantidades fabulosas de dados, mas apenas ao utilizar aplicativos escritos com suporte arquitetura. Isto no um grande problema para as universidades ou grandes estdios, que geralmente cuidam de grande parte do desenvolvimento dos programas e podem port-los, mas no uma alternativa vivel na maioria dos casos. Os clusters OpenMosix seguem uma idia diferente, que os torna mais adequados para o uso geral. Ao invs de dividir processamento dentro de um mesmo programa (o que exigiria que o programa seja portado e otimizado) vrios programas diferentes, ou vrias instncias do mesmo programa migram para os outros ns do cluster e so executados em paralelo de uma forma transparente para o usurio. A vantagem que o sistema funciona com os programas que voc j usa no dia a dia, no preciso sair caando aplicativos especiais. Imagine que voc tente comprimir dois vdeos em Divx ao mesmo tempo, abrindo duas instncias do mesmo programa de compresso. A primeira instncia 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 vdeos compactados quase que no tempo de um. O sistema envia uma cpia do programa para o segundo n, e em seguida passar a aliment-lo com os dados necessrios. Ao invs de ter todo o trabalho de comprimir o segundo vdeo, o seu PC receber apenas os resultados mastigados. Veja que para comprimir um vdeo em divx necessrio uma quantidade absurda de processamento, um DVD de duas horas demora cerca de 11 horas num Athlon de 1.0 GHz. Em compensao, temos uma quantidade relativamente pequena de dados, cerca de 4 GB para a imagem do DVD (os dados so transmitidos ao longo das 11 horas, o que daria uma mdia de 103 KB/s) e no final temos gerado um arquivo menor ainda, que pode ser transmitido facilmente atravs da rede. O mesmo acontece se voc estiver comprimindo audio, renderizando cenas 3D ou outras tarefas onde seja necessria uma grande quantidade de processamento. Voc no precisa fazer nada para que os processos migrem. Cada micro roda uma distribuio Linux completa, com um pequeno cliente OpenMosix que monitora o nvel de carregamento dos demais ns da rede. O software inclui um conjunto de funes que "decidem" quais programas so bons candidatos a serem migrados, baseado no nvel 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 disponvel 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+ disponvel do lado, ele quem acabar recebendo a maior parte do trabalho, fazendo com que alm de realizar as tarefas muito mais rpido, 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 vdeo em Divx ou um DVD ou rodar um servidor de banco de dados por exemplo nunca so migradas automaticamente. Mesmo que voc forasse 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 so exibidos pela placa de vdeo. Num filme com resoluo 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 transmisso de pouco mais de 15 MB/s para o vdeo e mais 88 KB/s para o udio. Se o vdeo estiver sendo processado localmente os dados vo direto para a placa de vdeo e a quatidade de dados no 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 mquina da rede os clculos j ficam mais apertados. Uma rede de 100 megabits permite uma taxa de transmisso terica de 12.5 MB/s mas na prtica sempre temos um pouco menos. preciso ao mesmo tempo enviar os dados a serem descomprimidos junto com outras informaes e receber os quadros e udio prontos para serem exibidos. No final voc acabar com uma utilizao muito alta da rede, atrapalhando o trabalho dos outros micros e ainda por cima um vdeo falhado. Com uma conexo fullduplex (100 Mb de upload e 100 Mb de download simultneos) o cenrio j seria mais confortvel, mas ainda assim seria difcil ver o vdeo com qualidade. Embora no seja a soluo pra tudo, o OpenMosix uma soluo interessante pois no necessrio ter ns dedicados. Voc pode manter o cliente OpenMosix (que ao mesmo tempo um servidor) nas mquinas da sua rede, de forma que os ciclos livres de uma sejam usados para processar dados enviados por outras mquinas. O OpenMosix no ajuda muito nas tarefas do dia a dia, como editar um arquivo no

OpenOffice, jogar Unreall 2003 ou abrir um monte de pginas no Mozilla, mas pode ajudar bastante em tarefas mais pesadas, que so afinal onde voc realmente precisa de mais desempenho. A pgina oficial do OpenMosix a: http://www.openmosix.org ou http://openmosix.sourceforge.net/ Para funcionar preciso um mdulo compilado no Kernel. Em muitos casos as distribuies j vem com o modulo pronto na forma de um pacote instalvel mas em outros preciso recompilar o Kernel adicionando o patch do OpenMosix. Existe um arquivo muito bom sobre a instalao do OpenMosix em vrias distribuies disponvel aqui: http://howto.ipng.be/openMosix-HOWTO/. O ClusterKnoppix uma verso customizada do Knoppix que inclui uma instalao do OpenMosix pronta pra usar. Ele to plug-and-play quanto o Knoppix original, basta dar boot em alguns PCs ligados em rede, abrir o programa monitor e os ns comearo 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 pgina do ClusterKnoppix : http://bofh.be/clusterknoppix/. A imagem do CD tem quase 700, o mesmo tamanho do Knoppix original e por enquanto est disponvel 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 no houver nenhum servidor disponvel 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 ns do cluster, junto com seus respectivos endereos IP. O que est no centro o seu micro, os pontos pretos em volta dele so os processos que esto sendo executados e os pontos verdes mostram os processos que migraram para outros ns 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 no pode ser migrada. Por outro lado, muitos dos programas que voc abrir sero imediatamente migrados, mesmo sem a sua interveno. Um outro programa til o "openmosixview". Ele mostra o nvel de carregamento de cada um dos ns do cluster. O "13667" na linha do n 234 mostra seu ndice de desempenho (no muito apurado) que usado para determinar quais ns 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 rpido do cluster vai perceber que os processos demoram a migrar, mesmo que os outros PCs estejam livres. A idia bsica executar as tarefas o mais rpido possvel, ento se o seu micro o mais rpido 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 mximo de processos possvel. Experimente usar o comando: mosctl setspeed 1000 Existe um outro programa mais simples chamado "mosmon", que mostra um grfico simples, em modo texto indicando o nvel de carregamento de cada n. Aqui estou rodando duas instncias do kandel, um programa gerador de factrais que faz parte da distribuio. 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 instncias do Kandel cada um dos ns 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 boto com o endereo IP de qualquer um dos ns voc tem acesso a um menu de configurao, onde voc pode desabilitar a migrao automtica de processos para um determinado n da rede (uma mquina lenta por exemplo) entre outras opes. Esta configurao pode ser salva, mas isso s ser til se voc estiver usando o ClusterKnoppix instalado no HD (a instalao idntica do Knoppix normal) caso contrrio voc perde tudo ao reiniciar a mquina.

Obs: Embora o sistema de arquivos aparea como opo durante a instalao do ClusterKnoppix, a instalao vai falhar se voc escolh-lo. Verses antigas do ClusterKnoppix tambm 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 executvel qualquer (a maioria dos programas est na pasta /usr/bin ou /usr/share). Voc cair no menu de execuo avanada, onde voc pode definir em qual n do cluster o programa ser executado (opo "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 no deve ser migrado:

Outro programa interessante o "openmosixprocs" que mostra uma lista dos processos que esto rodando e permite gerenciar os processos que migraram para outras mquinas:

Clicando sobre um processo qualquer na lista principal voc tem a opo de envia-lo para outra mquina ou mesmo fech-lo:

Se voc tiver apenas um CD do cluster Knoppix, ou no tiver drive de CD em todas as mquinas, 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 atravs da rede. Este sistema basicamente o mesmo utilizado pelo LTSP e pelo Kurumin Terminal Server, a diferena que os clientes carregam todo o sistema do servidor e rodam os aplicativos localmente ao invs de passarem a atuar como terminais burros do servidor. A configurao bem simples. Ele pergunta a faixa de endereos IP que ser reservada para os clientes remotos e em seguida pede que voc escolha os mdulos das placas de rede usadas nos clientes. Voc pode marcar quantos mdulos achar necessrio (em caso de dvida por exemplo), o nico inconveniente que com muitos mdulos ativos o servidor consumir um pouco a mais de memria RAM. A seguir voc ter a opo de ativar mais alguns recursos:

A opo "textmode" faz com que os clientes no careguem o modo grfico durante o boot, deixando mais memria RAM disponvel para rodar os aplicativos. Esta opo interessante apenas caso voc queira deixar os outros clientes disponveis para receber processos, sem que ningum os use. As opes Masq, DNS e Squid cache/Proxy ativam o compartilhamento da conexo com a Intenret para os clientes. Estas opes so necessrias apenas caso o servidor esteja acessando diretamente a internet. Se todos os micros, incluindo o servidor estiverem atrs de um outro micro que compartilha a conexo ou caso voc no pretenda acessar a Internet, as trs podem ficar desativadas. A ltima tela permite que voc passe parmetros de boot para as mquinas clientes, aquelas mesmas opes que podem ser usadas na tela de boot do Knoppix para ativar a rodinha do mouse (whellmouse), forar uma determinada resoluo de tela (screen=1024x768) e assim por diante. A maioria das placas me atuais, sobretudo as com rede onboard (PC-chips includas) suportam boot via rede utilizando o protocolo PXE. Voc precisa apenas configurar a sequncia de boot no Setup ou pressionar F8 (ou F12, dependendo da placa) durante a contagem de memria. O isso far o cliente enviar um pacote de broadcast pela rede, que ser respondido pelo servidor, dando sequncia 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. Tambm no existe muita

diferena de desempenho, pois numa rede de 100 megabits o gargalo a velocidade de leitura do CD-ROM e no a rede. Seria preciso um leitor de quase 100X para atingir uma taxa de leitura prxima de 12.5 MB/s.