O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

O QUE O CLUSTER OPENMOSIX COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX. 1 Andr Avila Kaminski 2
Resumo Um cluster openMosix formado por um conjunto de computadores que utilizam um sistema operacional distribudo. construdo a partir de computadores convencionais (ns) ligados em rede, os quais comunicam-se atravs do sistema de forma que ocorre um balanceamento de carga de processamento entre os ns do cluster. Utiliza-se o kernel Linux para a instalao do sistema, no qual aplicado um patch que torna possvel a compilao de suporte migrao de processos, bem como medio de carga e comunicao entre os ns do sistema diretamente no kernel. O openMosix um projeto de Software Livre, motivo pelo qual garante o baixo custo de montagem de um cluster cujo desempenho muito interessante. Palavras-chave: Cluster, Linux, Software Livre Abstract An openMosix Cluster is formed by a set of computers that use a distributed operational system. It is constructed from conventional computers (nodes) on a network, which communicate themselves through the system, occurring a balancing of load process by the nodes of the cluster. The kernel Linux is used for the installation of the system, a patch is applied in the kernel making possible the compilation of support to the migration of processes, as well as load measurement and communication by the nodes of the system directly in the kernel. The openMosix is a free software project, it is the reason for the guarantees to the low cost of assembly of cluster whose performance is very interesting. Key-words: Cluster, Linux, Free Software

1. CLUSTER

Define-se um cluster como um conjunto de Pcs ou estaes que, interligados, comportam-se como um sistema de imagem nica (SSI - Single System Image). O conceito de SSI se resume em que um sistema paralelo ou distribudo independe de ser composto por vrios processadores ou recursos fsicamente distribudos, deve comportar-se com um sistema centralizado do ponto de vista do usurio, sendo transparente ao mesmo todos os aspectos relativos distribuio de dados e tarefas, comunicao e sincronizao entre tarefas e a organizao fsica do sistema.
1

Este artigo encontra-se sob a licena Creative Commons. http://creativecommons.org/licenses/by-ncsa/2.0/br/. Foi liberado pelo prprio autor para ser inserido na Revista Gesto e Conhecimento. 2 Bacharel em Relaes Internacionais e estudante de ps-graduao em Software Livre. Bolsista h 2 anos no Instituto de Tecnologia do Paran (http://www.tecpar.br), atuando em pesquisas de solues em Software Livre para projetos de migrao de plataformas. Pesquisador do desenvolvimento do Software Livre na Amrica Latina, bem como dos impactos polticos e sociais gerados pela evoluo do mesmo na regio. E-mail: kaminski@tecpar.br

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006: 49 - 75

Kaminski, Andr vila

Em uma rede, os ns tendem a ser menos complexos do que os ns de um cluster, pois em uma rede os ns correspondem a Pcs ou estaes monoprocessadas. Em um cluster, os ns podem conter dois, quatro ou mais processadores, tendo uma complexidade igual ou at mesmo maior do que mquinas MPP (mquinas proprietrias de processamento massivo), se for considerado a presena de discos e sistemas operacionais. As mquinas SMP (mquinas multiprocessadas) geralmente so mais complexas, pois podem conter um nmero maior de processadores. As redes de comunicao dos computadores podem ser baseadas em switches de alta velocidade, que permitem a transmisso simultnea de pacotes pertencentes a diferentes pares de comunicao em alta velocidade, como no caso do fast ethernet e gigabit ethernet. A constante demanda de poder computacional vem gerando a necessidade de processadores cada vez mais rpidos. Na computao de alto desempenho, utilizada para programao cientfica, multimdia, gerenciamento de grandes volumes de dados etc., a soluo passa por mquinas com mltiplos processadores ou ainda clusters proprietrios fornecidos por grandes empresas. Ambas solues so custosas e de pouca escalabilidade. O projeto openMosix viabiliza a computao de alto desempenho utilizando computadores ligados em rede e com sistema operacional GNU/Linux.

1.1 O Cluster openMosix

Durante a dcada de 1980, foi utilizado pela fora area americana, para a construo de um cluster de computadores PDP 11/45, o projeto Mosix (Multicomputer Operating System uniX), um sistema operacional distribuido originalmente desenvolvido pelos estudantes da Universidade Hebrew em Jerusalm, Israel, juntamente com o professor Ammon Barak.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

50

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

Em 10 de fevereiro de 2002 surgiu uma extenso do projeto Mosix, o openMsix, baseado na GPLv2 3 para manter os privilgios dessa soluo Linux 4 para cluster disponvel com software de cdigo aberto, coordenado pelo Ph.D Moshe Bar. O openMosix uma extenso do kernel Linux do sistema operacional GNU/Linux, que faz com que um cluster de computadores se comporte como um grande e nico supercomputador atravs da utilizao de migrao preemptiva de processos e balenceamento dinmico de carga. A implementao da migrao preemptiva de processos capaz de migrar qualquer processo do usurio, em qualquer instante e para qualquer n disponvel de maneira transparente. Para atingir um melhor desempenho este controlado por algoritmos de balanceamento dinmico de carga e de preveno contra a falta de memria. Estes algoritmos so projetados para responder dinamicamente as variaes da utilizao dos recursos nos diversos ns. Isto garante que o cluster se comporte muito bem, seja numa configurao com poucas ou com muitas mquinas, propiciando uma maior escalabilidade. Se o programa que estamos rodando em uma mquina consumir muito recurso dela, o sistema varre a rede toda e procura uma mquina que esteja com seus recursos mais disponveis em termos de memria e CPU, e desloca o processo, ou parte dele, para ser executado remotamente, assim, o sistema ganha desempenho. Os algoritmos de balanceamento dinmico de carga e de preveno contra a falta de memria so descentralizados, no existindo assim a configurao de um controlador mestre e ns escravos como ocorre no Cluster Beowulf 5 para computao paralela. Cada n um mestre para os processos que so criados localmente, e um servidor para processos remotos, migrados de outros ns do cluster. Sendo assim, podemos acrescentar ou remover as mquinas do cluster em qualquer momento, com um mnimo de disturbio no sistema. Existem tambm algoritmos de monitoramento que identificam a velocidade de cada n, a carga da CPU e a memria livre disponvel, e

http://www.gnu.org/copyleft/gpl.html http://www.kernel.org/ 5 http://www.beowulf.org/

4

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

51

Kaminski, Andr vila

tambm como est a comunicao interprocessos IPC e a velocidade de acesso a cada processo. O openMosix opera de forma silenciosa, assim as operaes so transparentes para as aplicaes, pode-se executar aplicaes sequenciais e paralelas como se fosse um nico computador SMP (multiprocessamento simtrico). Voc no precisa saber onde os processos esto sendo executados, nem se preocupar com o que as outras mquinas esto fazendo na rede, por isso ele usa o acrnimo fork and forget. O que ele faz , pouco tempo depois de iniciar os processos, o openMosix enviaos para um melhor computador da rede, o openMosix continua a monitorar os novos processos e os demais, e poder moviment-los pelos computadores com pouca carga de trabalho maximizando o trabalho e melhorando a performance do cluster. Aplicaes que se beneficiam com o openMosix:

processos CPU-bound: processos com longos tempos de execuo e baixo volume de comunicao entre processos, como aplicaes cientficas e de engenharia, que necessitam de altas performances de computao; grandes compilaes; processos I/O bound misturados com processos da CPU: executados atravs do servidor de arquivos, usando o sistema de arquivos distribudos do openMosix, o MFS (Mosix File System) e o DFSA (Distributed File System Architeture); banco de dados que no usem memria compartilhada; processos que podem ser migrados manualmente.

As desvantagens do openMosix:

processos com baixa computao, como aplicativos com alta comunicao interprocessos; aplicaes com memria compartilhada;

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

52

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

aplicaes dependentes do hardware que necessitam de acesso a um perifrico de um n em especial; aplicaes com muitas threads no ganham desempenho; no se ganha desempenho quando se roda um nico processo, tal como seu browser por exemplo.

Aplicaes testadas que no migram sobre openMosix:

programas em Java usando threads nativas no migram desde que eles utilizem memria compartilhada. Green Threads JVMs, entretanto, podem ser migradas porque cada thread Java um processo separado; aplicaes que usam pthreads; MySQL, Apache, Oracle, Postgres, SAP, Baan, usam memria compartilhada; python com threading habilitada; Vmware. Este, ao rodar o Win98, algumas vezes trava e em outras o emulador do sistema operacional pra. Deve-se ter muito cuidado quando utilizar o Vmware com o openMosix.

A caracterstica de no migrar uma situao normal para programas que falhariam ao serem movimentados pelo openMosix. Estes programas devem rodar como planejado no n onde foram iniciados.

2.

ALGORITMO DE COMPARTILHAMENTO DE RECURSOS DO CLUSTER

OPENMOSIX

2.2 Balanceamento Dinmico de Carga

O algoritmo de balanceamento de carga tenta continuamente reduzir a diferena de carga entre pares de ns, transportando processos de um n muito

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

53

Kaminski, Andr vila

carregado para um n menos carregado. O esquema utilizado no centralizado, todos os ns executam o mesmo algoritmo, e a tentativa de reduo das diferenas executada independentemente e aos pares.

2.3 Anunciador de Memria

O algoritmo do anunciador de memria serve para evitar o exaurimento da memria. Este direcionado para tentar colocar a maior ocupao possvel da memria do cluster de computadores, evitando ao mximo que ocorra a paginao ou utilizao da memria virtual. Inclusive, quando um determinado n comea a fazer muita paginao que o algoritmo entra em ao. Neste caso especfico, este algoritmo tem a preferncia sobre os demais, mesmo que a migrao do processo cause um desbalanceamento de carga.

2.4 Migrao Preemptiva de Processos

A Migrao Preemptiva de Processos (MPP) capaz de migrar qualquer processo, em qualquer instante, para qualquer n do cluste. Usualmente esta migrao baseada nas informaes geradas pelos algoritmos automticos, mas tambm podem ser sobrepostas por operaes manuais, sejam estas executas pelo usurio ou por outros processos. Cada processo tem o seu UHN (Unique Home Node), mquina na qual o processo foi criado.Normalmente onde o usurio est logado. O modelo que o openMosix segue espelhado num Cluster de Computadores CC (Cluster of Computers) onde cada processo "pensa" que est rodando no seu UHN e todos os processos deste usurio compartilham este ambiente UHN. Os processos que so migrados para outros ns podem usar os recursos locais do novo n, caso seja possvel, mas interagem com o ambiente do usurio atravs do UHN. Para exemplificar esse conceito, podemos dizer que caso o usurio venha a executar um comando "top", este dever listar todos os processos que o usurio disparou, inclusive aqueles que foram transferidos para os ns remotos. Outro exemplo seria: um dos processos que foi

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

54

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

migrado invoca o mtodo "gettimeofday()" que deve retornar o horrio corrente da mquina UHN. O MPP a principal ferramenta que os algoritmos de gerncia de recursos utiliza, por exemplo, enquanto os recursos, como a memria ou a CPU, esto subutilizados ou abaixo do limite estabelecido o processo est confinado a ficar no UHN. Mas, se em um determinado instante estes limites forem extrapolados, alguns processos sero migrados para outros ns para aproveitar da melhor maneira possvel os recursos disponveis. Todo este processo feito sem um controle central, no existindo nenhum relacionamento mestre/escravo entre os ns. Ou seja, cada n do sistema opera de maneira independente e autnoma, tomando as suas decises de maneira independente, o que permite uma configurao dinmica, onde os ns podem entrar ou sair do grupo causando o mnimo de problema. Isto garante uma boa escalabilidade tanto em sistemas de grande porte quanto em pequenos sistemas.

2.5 Implementao da Migrao de Processos

O openMosix suporta e implementa de maneira transparente a migrao de processos de modo preemptivo. Para realizar isso, o openMosix divide o processo que ser migrado em duas partes, ou seja, em dois contextos: um que ser transferido, que chamado de contexto do usurio, e outro que dependente da UHN e que no pode ser migrado, que chamamos de contexto do sistema. O contexto do usurio, chamado de representado, contm o cdigo do programa, a pilha, os dados, os mapas de memria e o estado dos registradores do processo. O representado encapsula todas as informaes do processo que esto rodando em modo usurio. O contexto do sistema, chamado de representante encapsula o processo quando este est rodando em modo supervisor. Este contm todas as descries dos recursos os quais o processo faz uso ou est alocado para ele, e a pilha do sistema que

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

55

Kaminski, Andr vila

controla a execuo do processo. Como ele contm a parte do processo que dependente do contexto do sistema, ele deve permanecer no UHN. Como foi citado anteriormente, o representado pode ser transferido quantas vezes for necessrio, para qualquer n do cluster, mas o representante jamais pode ser movido. Como a interface entre o modo usurio e o modo supervisor muito bem definida e conhecida, possvel e extremamente simples interceptar toda e qualquer interao que existe entre esses dois modos e encaminh-la para outros ns da rede. Isto feito numa camada que chamamos de camada de adaptao a qual contm um canal especial de comunicao para a interao entre elas. Por causa desta diviso o processo a ser migrado tem um tempo de migrao tambm composto por duas partes, uma fixa que o tempo para criar a imagem do processo no n remoto, e uma parte linearmente proporcional ao nmero de pginas a serem transferidas do processo. Para tentar minimizar a sobrecarga imposta pela migrao, somente a tabela de pginas e as pginas marcadas como "sujas" do processo so transferidas. No momento da execuo o openMosix garante a transparncia de localizao, transferindo todas as chamadas de sistema que so dependentes do local para o representante que est no UHN do processo. Estas chamadas so sncronas, ou seja, so interceptadas pela camada de adaptao remota e transferidas pelo canal especial de comunicao para o n onde o processo foi lanado, este executado e o retorno re-transferido para o n remoto o qual segue na execuo do processo. Se durante esta execuo a camada de adaptao descobre que algumas dessas chamadas ao sistema so independentes da localizao, esta decide por no mandar a chamada para o UHN e a executa localmente, melhorando assim o desempenho. Evidentemente existem outras formas de interao entre os dois contextos do processo, como sinais, dados chegando pela rede, eventos, etc. Estes tipos de interaes fazem com que o representante assincronamente tente localizar e interagir com o representado. Para que isso funcione o representado fica monitorando o canal especial de comunicao para ver se algum evento ou dado chega para ele. Ao mesmo

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

56

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

tempo o representante verifica sempre se alguma ao deve ser tomada quando algum tipo de evento ou dado chega para ele. Essa implementao bastante robusta e independente de modificaes que ocorram no ncleo do sistema, assim como no utiliza caractersticas especiais do sistema ou da mquina, o que garante que isso possa ser portado para diferentes arquiteturas de mquinas. Porm existe um pequeno problema. Para todas as chamadas do sistema existe uma sobrecarga para testar o que deve ser feito, e esta ser ainda maior se tiver que ser transferida entre os ns. No entanto, normalmente, os ganhos so maiores o que justifica a implementao deste sistema. Algumas funes do ncleo do sistema no so compatveis com esse esquema de diviso do processo em duas partes, como, por exemplo, escrita em memria compartilhada, aplicaes em tempo real, instrues que acessem um barramento especfico, dentre outras. Nestes casos, os processo so automaticamente confinados no UHN e, se por algum motivo eles j foram transportados, eles devem ser migrados de volta para o UHN.

2.6 Acesso Arquivos

Outro grande desafio dos clusters SSI que cada n tem que ser capaz de acessar o sistema de arquivos de todos os outros ns. Isso acontece porque caso seja executado um programa que abre o arquivo /tmp/teste para leitura e escrita este processo migra para outro n do cluster e ele deve ser capaz de continuar fazendo I/O para o arquivo e a partir dele. At agora existem duas opes para fazer isso. Na primeira, o cluster openMosix intercepta todos I/Os feitos por processos que foram migrados para o host corrente e depois para outro n e manda estas requisies para o n no qual o processo se originou. A segunda, seria criar uma viso global do sistema de arquivos atravs de NFS. A primeira mais difcil de desenvolver, mas mais fcil de manter em operaes do dia-a-dia. A segunda mais fcil de implementar, mas pode ser mais

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

57

Kaminski, Andr vila

problemtico montar todos sistemas de arquivos de maneira inteligente, permitindo que cada n acesse todos os outros ns. Adicionalmente preciso ter certeza que todos os UIDs (identificador de usurios no sistemas Linux) e GIDs (identificador de grupos nos sistemas Linux) so consistentes para todos os ns no cluster, em contrapatida srios problemas de permisses de acessos aos arquivos iro aparecer. At ento o openMosix suportou as duas opes. Mas agora est surgindo um novo sistema de arquivos de cluster para Linux que permite uma viso compartilhada de todos os sistemas de arquivos. Desenvolvedores de clusters dizem que todas as solues atuais para sistemas de arquivos de cluster do tipo cluster-wide so baseados num servidor de arquivos central, mas existem novas tecnologias de sistemas de arquivos sendo desenvolvidas que atendem todas as necessidades de um cluster SSI como o openMosix. Utilizando o melhor do que est sendo pesquisado atualmente em sistema de arquivos e aplicando isto ao openMosix, surgiu o DFSA (Direct File System Access). O sistema de arquivos DFSA foi projetado para reduzir o overhead causado pela execuo de I/Os feitas por chamadas de sistemas de processos migrados. Isto foi feito permitindo que a execuo de grande parte das chamadas de sistemas seja feita localmente - no n onde o processo se encontra. Alm disso, o DFSA possui um novo algoritmo que leva em conta as operaes de I/O que foi adicionado poltica de distribuio de processos do openMosix (balanceamento de carga). O resultado dessas inovaes que os processos que executam de moderado a alto volume de I/Os provavelmente sero migrados para o n ao qual se dirigem a maior parte de seus I/Os. Uma vantagem bvia disto que os processos que tenhas I/O limitado tero uma flexibilidade maior para migrar de seus respectivos ns originais para que o sistema obtenha um melhor balanceamento de carga. Ento, diferentemente de todos os sistemas de arquivos de rede existentes (se diz NFS) que trazem os dados do servidor de arquivos para o n do cliente atravs da rede, um cluster openMosix tenta migrar os processos para um n no qual o arquivo est armazenado.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

58

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

3. CONSTRUINDO UM CLUSTER OPENMOSIX

Pode-se ter um cluster openMosix basicamente de duas maneiras:

A primeira opo seria utilizar uma distribuio Linux diretamente de um CD bootavel. Estas distribuies so voltadas exatamente para a montagem de clusters, facilitando muito o aprendizado de iniciantes no mundo dos supercomputadores, pois necessrio apenas dar o boot pelo CD em duas ou mais mquinas interligadas em rede para ver um cluster funcionando. Pode-se citar como exemplo de distribuies a distribuio ClusterKnoppix 6 , que serve como um Terminal Server para mquinas clientes com boot via PXE e a distribuio dyne:bolic, voltada para produo multimdia. Outras distribuies bootveis podem ser encontradas no site

http://openmosix.sourceforge.net/instant_openm osix_clusters.html;

A segunda opo, a qual ser descrita neste artigo, utilizar uma distribuio Linux qualquer com instalao fsica na mquina. Deve-se utilizar um kernel Linux e aplicar um patch neste kernel, habilitando-o s necessidades do openMosix.

3.1 Escolhendo uma Distribuio Linux

A distribuio Linux a ser utilizada depende muito da opo da pessoa responsvel pelo cluster, pois o importante o kernel Linux estar habilitado para trabalhar com o openMosix. Para a construo de um cluster openMosix a distribuio Debian GNU/Linux 7 amplamente utilizada, mas pode-se encontrar tutoriais de montagem de um cluster openMosix com vrias outras distribuies, como o tutorial openMosix Cluster on Gentoo 8 do Gentoo Linux 9 , por exemplo.
6 7 8

http://bofh.be/clusterknoppix/ http://www.debian.org/
http://www.gentoo.org/doc/en/openmosix-howto.xml 59

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

Kaminski, Andr vila

Ser utilizada o Debian GNU/Linux para a montagem do cluster openMosix. Existem nos repositrios da distribuio os pacotes necessrios para a instalao do cluster e monitorao do mesmo, e pode-se encontrar tambm na internet shell scripts para demonstrar a migrao de processos entre os ns do cluster.

3.2 Escolhendo um Kernel Linux para o Sistema

A escolha do kernel pode ser definida pela finalidade da montagem do cluster e pelo hardware utilizado nas estaes. No site oficial do projeto openMosix 10 apenas o patch para o kernel verso 2.4.26 disponibilizado como estvel, mas existem patchs para outras verses em um site no-oficial 11 , onde encontra-se at mesmo para as ltimas verses. Na internet fica fcil encontrar resolues de problemas para verses mais antigas do kernel, enquanto para as verses mais recentes encontrase pouca coisa, por isso aconselhvel utilizar verses mais velhas do kernel. Atualmente (10/11/2005) o kernel Linux est na verso estvel 2.6.14.1, mas como o patch para esta verso ainda no est oficialmente declarado estvel pelos mantenedores do projeto openMosix, ser utilizado o kernel 2.4.26, o qual se mostra muito estvel para a funo.

3.3 Iniciando a Montagem do Cluster para Demonstrao dos Testes

Para demonstrao do funcionamento de um cluster openMosix, sero utilizadas duas mquinas com sistema operacional Debian GNU/Linux com um kernel 2.4.26 com o patch devidamente aplicado. As configuraes das mquinas (ns) do cluster so:

Mquina 01 (N1): Notebook Acer / TravelMate 260

10 11

http://www.gentoo.org/ http://openmosix.sourceforge.net/

http://openmosix.snarc.org/

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

60

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

Processador Intel Mobile Pentium III 1000MHz, 512KB cache 256MB de memria RAM Placa de rede fast ethernet RealTek RTL-8139 10/100

Mquina 02 (N2): Processador AMD Athlon 2800+ (1800MHz), 64 bits, 512KB cache 512MB de memria RAM Placa de rede gigabit ethernet Realtek RTL8169/8110 10/100/1000

No sistema operacional Debian GNU/Linux da N1 est instalado a interface grfica Gnome 12 , para que seja possvel a visualizao da migrao de processos entre os ns do cluster atravs do aplicativo openMosixview 13 , verso 1.5. Neste aplicativo podem ser vistos a eficincia do balanceamento de carga entre os ns, a memria total do cluster, o nmero de processadores do cluster, a porcentagem de memria utilizada e tambm existem opes para visualizar a migrao de processos entre os ns, os processos que esto em andamento e grficos da carga dos ns do cluster, dando a opo de poder gravar e/ou imprimir estes grficos. necessria a interface grfica na N1 por dois motivos: o primeiro seria a demonstrao grfica da migrao de processos; o segundo seria por ser uma mquina com menor poder de processamento e memria RAM, facilitando a induo de migrao de processos para a N2. Na mquina N2 no haver necessidade de utilizar interface grfica, pois assim haver mais memria livre para os testes. No n N2 no haver mais nada rodando a mais do que o sistema operacional Debian GNU/Linux e o openMosix. A ligao entre os dois ns do cluster ser feita por um cabo crossover, por ter apenas dois ns, e sem a necessidade de conexo com outra rede ou mquinas, ser dispensado a utilizao de switches ou hubs, para que haja uma maior performance e diminua a possibilidade de falhas na hora dos testes. A velocidade da placa de rede do N2 gigabit ethernet, mas trabalhar apenas como fast ethernet, pois a limitao est na placa de rede do n N1.
12

http://www.gnome.org/

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

61

Kaminski, Andr vila

4.

COMPILADOR PARA UM KERNEL LINUX COM SUPORTE AO CLUSTER

OPENMOSIX

Para que se possa compilar um Kernel Linux openMosix necessrio utilizar a verso 3.3.2 do compilador gcc 14 , pois quando utilizada outra verso, a compilao apresentou muitos erros, impossibilitando a criao do kernel openMosix. Para isso foi necessrio fazer o download do cdigo fonte do gcc-3.3.2 15 , descompact-lo com o comando:

tar jxvf gcc-3.3.2.tar.bz2

E compil-lo com a opo CC=gcc-3.3, para que fosse corretamente compilado e instalado, com os seguintes comandos:

cd gcc-3.3.2 ./configure make CC=gcc-3.3 make CC=gcc-3.3 install Agora j existe no sistema o compilador necessrio para a criao do kernel openMosix. O executvel do compilador gcc verso 3.3.2 ser instalado no diretrio /usr/local/bin/ com o nome de i686-pc-linux-gnu-gcc-3.3.2.

5. COMPILANDO UM KERNEL LINUX PARA CLUSTER OPENMOSIX

Como citado anteriormente, ser utilizado um kernel Linux verso 2.4.26 para a utilizao nos ns, tanto no N1 quanto no N2. No h nada a mais nos kernels de ambas as mquinas do que o necessrio para cada uma funcionar como um n de

13 14

http://www.openmosixview.com/ http://gcc.gnu.org/ 15 http://mirrors.usc.edu/pub/gnu/gcc/gcc-3.3.2/gcc-3.3.2.tar.bz2

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

62

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

cluster openMosix e habilitar as funcionalidades necessrias para a demosntrao do funcionamento do cluster. O primeiro passo foi fazer o download do cdigo fonte do kernel 2.4.26 16 do site oficial do Kernel Linux, descompar o cdigo fonte no diretrio correto:

mv linux-2.4.26.tar.bz2 /usr/src/ cd /usr/src/ tar jxvf linux-2.4.26.tar.bz2 Criar o link simblico: ln -s /usr/src/linux-2.4.26 /usr/src/linux Fazer o download do patch 17 a ser aplicado no Kernel Linux do site oficial do openMosix e descompact-lo diretrio correto:

bunzip2 openMosix-2.4.26-1.bz2 mv openMosix-2.4.26-1 /usr/src/linux/ O cdigo fonte do kernel j est, juntamente com o patch apropriado, dentro do diretrio correto. Agora, antes de aplicar o patch no kernel, necessrio retirar do cdigo fonte do kernel tudo que no for necessrio para a compilao, com os seguintes comandos:

cd /usr/src/linux/ make clean make mrproper E copiar uma configurao bsica para o kernel:

cp arch/i386/defconfig .config

E ento aplicar o patch de modificao:

16 17

http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.26.tar.bz2 http://prdownloads.sourceforge.net/openmosix/openMosix-2.4.26-1.bz2?download

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

63

Kaminski, Andr vila

cat openMosix-2.4.26-1 | patch -Np1

Este ltimo comando no dever retornar erro algum. Se algum erro ocorrer, verifique se a verso do kernel e do patch so as mesmas citadas acima. Neste ponto est efetuada a modificao no cdigo fonte do Kernel Linux. Isto modificou cerca de 3% do cdigo fonte, acrescentando algumas entradas para que seja possvel a correta compilao do kernel com suporte todas as funcionalidades do openMosix. O prximo passo selecionar no kernel o que for necessrio e terminar a compilao. Deve-se ter em mente que o processo dever ser efetuado em cada n do cluster, pois cada um deles necessita de um kernel apropriado para ser hardware, a no ser que todas as mquinas do cluster tenhas exatamente a mesma configurao. O prximo comando para acessar a interface de configurao do kernel :

cd /usr/src/linux make menuconfig Uma interface com todas opes do kernel Linux aberta, possibilitando a ativao do hardware necessrio para uma boa compilao. Pode-se observar uma entrada openMosix na primeira linha, a qual no estaria presente se o patch no tivesse sido aplicado. necessrio que no kernel estejam presentes no mnimo as seguintes configuraes:

Na entrada openMosix, para habilitar o suporte cluster: openMosix process migration support Stricter security on openMosix ports (3) Level of process-identity disclosure Poll/Select exceptions on pipes

Deve ser escolhido o processador certo na entrada Processor type and features para suporte ao processador do n em questo

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

64

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

Na entrada Block devices, para suporte comunicao entre trabalhos cliente X servidor sobre rede TCP/IP: Network block device support Deve ser escolhido o modelo da placa de rede do n em questo na entrada Network device support Na entrada File systems devem ser selecionados todos os sitemas de arquivos que estejam presentes no sistema operacional do n em questo

Deve-se gravar as configuraes e sair da interface. Basicamente isso que deve estar no kernel. aconselhvel no colocar nada que no seja necessrio, para maior performance do sistema. Agora, depois de ter configurado o kernel para ser compilado com suporte todas as necessidades, j possvel comear a compilao do kernel para a mquina utilizando o gcc verso 3.3.2, com os comandos:

make CC=/usr/local/bin/i686-pc-linux-gnu-gcc-3.3.2 dep make CC=/usr/local/bin/i686-pc-linux-gnu-gcc-3.3.2 bzImage make CC=/usr/local/bin/i686-pc-linux-gnu-gcc-3.3.2 modules make CC=/usr/local/bin/i686-pc-linux-gnu-gcc-3.3.2 modules_install Se nenhum erro ocorrer, o kernel j dever estar compilado neste momento, e deve ser copiado para o diretrio /boot :

cp arch/i386/boot/bzImage /boot/kernel-2.4.26-om1 Neste ponto s falta configurar o loader. No caso est sendo utilizado o GRUB 18 , ento:

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

65

Kaminski, Andr vila

vi /boot/grub/menu.lst E adiciona as entradas necessrias para o sistema bootar pelo novo kernel openMosix: Ao reiniciar o sistema pelo novo kernel, se for necessrio fazer alguma mudana, s adicionar ou remover as entradas na configurao do kernel (make menuconfig) e repetir os passos posteriores, deixando o kernel exatamente como o n precisa para correto funcionamento. O processo deve ser repetido para cada um dos ns.

6. EXECUTANDO OS TESTES

Para demonstrar o funcionamento do cluster openMosix, formado pelos ns N1 e N2, utilizou-se um shell script (teste-om.sh) elaborado com a funo de testar a velocidade de processamento do cluster, que dispara cinco vezes outro shell script (stress-test.sh) com o comando awk que eleva o processamento do n ao mximo, chegando a utilizar 100% da CPU dos ns. O n utilizado para rodar o script foi o n N1, que tem menor poder de processamento, j para demonstrar a migrao dos processos para o n N2, uma mquina maispotente. O tempo de processamento do script inicialmente sera medido rodando apenas no n N1, com o cluster desativado, sendo comparado com o tempo obtido com o cluster ativado, rodando o n N1 e o n N2. Abaixo estao listados os comandos de cada shell script utilizado para testar o cluster:

- Shell script teste-om.sh #!/bin/bash #por Andre Kaminski #kaminski@tecpar.br

18

http://www.gnu.org/software/grub/

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

66

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

echo 'Iniciando teste do openMosix' date "+%Hh %Mm %Ss" ./stress-test.sh & ./stress-test.sh & ./stress-test.sh & ./stress-test.sh & ./stress-test.sh date "+%Hh %Mm %Ss" echo 'Final do teste do openMosix' - Shell script stress-test.sh

#!/bin/bash awk 'BEGIN {for (i=0;i<10000;i++)for(j=0;j<10000;j++);}' No primeiro script pode-se observar cinco chamadas para o segundo, que por sua vez pode ser modificado para conseguir um maior processamento do(s) n(s) do cluster. O tempo inicial e final do script tambm so demonstrados, com a finalidade de medir quanto tempo foi necessrio para rodar o script apenas no n N1, com o cluster desativado, e tambm nos ns N1 e N2, com o cluster ativado, para posteriormente serem comparados e demonstrar a funcionalidade do openMosix. Foram elaborados cinco testes com o openMosix ativado e cinco testes com o openMosix desativado, para obter-se a media dos resultados. O resultado, com o cluster desativado, rodando no n N1, ficou registrado no arquivo texto n1.txt, e est listado abaixo. Testes com o cluster openMosix desativado:

Iniciando teste do openMosix 00h 46m 52s 00h 49m 13s Final do teste do openMosix Iniciando teste do openMosix 00h 49m 57s 00h 52m 15s Final do teste do openMosix

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

67

Kaminski, Andr vila

Iniciando teste do openMosix 00h 52m 22s 00h 54m 43s Final do teste do openMosix Iniciando teste do openMosix 00h 54m 56s 00h 57m 14s Final do teste do openMosix Iniciando teste do openMosix 00h 57m 18s 00h 59m 37s Final do teste do openMosix Organizando os resultados obteve-se a Tabela 01 abaixo relacionada: TABELA 01 - RESULTADO DOS TESTES COM CLUSTER DESATIVADO
Teste 01 Teste 02 Teste 03 Teste 04 Teste 05 Media 00h 52s 00h 57s 00h 22s 00h 56s 00h 18s inicio 46m 00h 13s 49m 00h 15s 52m 00h 43s 54m 00h 14s 57m 00h 37s fim 49m 52m 54m 57m 59m total (s) 141s 138s 141s 138s 139s 139,4s

O tempo de processamento do script variou entre 138 segundos e 141 segundos, obtendo-se uma mdia de 139,4 segundos. Pode-se observar que o tempo de processamento nos cinco testes efetuados com o cluster openMosix desativado no tiveram uma variao muito considervel, isso demonstra que no houveram problemas durante nenhum dos testes. Nos testes efetuados com o cluster openMosix ativados percebe-se uma grande diferenca nos resultados. O arquivo texto n1+n2.txt, abaixo listado mostra a saida dos resultados obtidos. Testes com o cluster openMosix ativado:

Iniciando teste do openMosix

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

68

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

00h 37m 31s 00h 38m 26s Final do teste do openMosix Iniciando teste do openMosix 00h 38m 36s 00h 39m 35s Final do teste do openMosix Iniciando teste do openMosix 01h 26m 25s 01h 27m 24s Final do teste do openMosix Iniciando teste do openMosix 01h 34m 04s 01h 35m 02s Final do teste do openMosix Iniciando teste do openMosix 15h 55m 38s 15h 56m 37s Final do teste do openMosix Organizando os resultados obteve-se a Tabela 02 abaixo relacionada: TABELA 02 - RESULTADO DOS TESTES COM CLUSTER ATIVADO
Teste 01 Teste 02 Teste 03 Teste 04 Teste 05 Media 00h 31s 00h 36s 01h 25s 01h 04s 15h 38s inicio 37m 00h 26s 38m 00h 35s 26m 01h 24s 34m 01h 02s 55m 15h 37s fim 38m 39m 27m 35m 56m total (s) 55s 59s 59s 58s 59s 58s

Pode-se observar a diferenca dos resultados entre os dois testes, o primeiro com o cluster openMosix desativado e o segundo com o cluster openMosix ativado. No segundo teste, os tempos variaram entre 55 segundos e 59 segundos, obtendo-se uma mdia de 58 segundos.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

69

Kaminski, Andr vila

7. ANALISANDO OS RESULTADOS

Comparando os resultados, temos uma diferenca media de 81,4 segundos. Conseguiu-se um resultado surpreendentemente menor, demonstrando a eficincia do cluster openMosix. Ao rodar o script apenas no n N1, o processador teve que dar conta de todos os processos, elevando a quase 100% a capacidade de processamento, por cerca de 139,4 segundos. J com o cluster openMosix ativado, o algoritmo dinmico de balanceamento de carga do no N1, utilizou a migrao preemptiva de processos para migrar alguns processos para o n N2, que, alm de ser mais potente, no estava sobrecarregado, deste modo, o processamento do script foi distribuido pelos nos do cluster, diminuindo muito o tempo de execuo do script. O aplicativo openMosixView, instalado no n N1, demonstrou graficamente a migrao dos processos. Pode-se observar trs, ou, em alguns dos testes, at mesmo quatro processos sendo enviados do n N1 para o n N2, e depois sendo devolvidos com o resultado do processamento. Utilizando o aplicativo top para observar os processos e a utilizacao da CPU do n N1, foi observado que os processos continuaram listados, como se estivessem no estado sleeping, mas na verdade estavam em outro n, o n N2. J no outro n, o processamento subiu para quase 100%, mas no foi observado o processo na lista do aplicativo top, porem observou-se a mudanca do nvel do processamento da mquina. Se os testes estivessem sido efetuados em um cluster openMosix com tres, quatro, cinco nos ou mais, poderia ser observada a migrao para todos os nos que estivessem sendo pouco utilizados, e o tempo de execucao do script seria muito menor. O cluster openMosix no tem a capacidade de dividir o processamento de apena um software para os seus ns, o openMosix apenas migra processos inteiros para ns menos sobrecarregados com a finalidade de balancear a carga dos ns.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

70

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

O Projeto Beowulf 19 , iniciado pela NASA em 1994, no tem a caracteristica de procesamento em tempo real, como jogos exemplo, mas tem a capacidade de quebrar grande quantidade de dados em pequenas partes, dividindo entre os ns o processamento, o que o cluster openMosix no faz.

8. O CLUSTER BEOWULF

O cluster Beowulf outro projeto em Software Livre, que utiliza o kernel Linux como base. Como j citado anteriormente, o cluster openMosix apenas migra processos inteiros para outros ns pela rede e recolhe os resultados, j o cluster Beowulf tem a capacidade de dividir grandes quantidades de dados em pequenas partes para que cada n processe uma parte. Esse modelo de cluster amplamente utilizado para aplicao de efeitos especiais e renderizao de imagens em produes

cinematogrficas. A estrutura do cluster Beowulf necessita de um n mestre (front-end) que controla a distribuio de tarefas entre os ns escravos, assim no h migrao de processos entre os ns escravos, como no cluster openMosix. Por ser um tipo muito potente de cluster, amplamente explorado em universidades e aplicado para vrias finalidades. O sistema do cluster Beowulf necessite de bibliotecas para Parallel Virtual Machine (PVM) ou para Message Passing Interface (MPI), para troca de mensagens entre os ns do cluster. O MPI mais avanado, pois trabalha com mensagens para todos os ns do cluster, ou apenas para um determinado grupo. No pode-se comparar qual modelo de cluster melhor, isso deve ser decidido dependendo da finalidade de utilizao do cluster. No openMosix, por exemplo, todos os computadores podem continuar sendo utilizados, e quando algum estiver sobrecarregado de processamento, acontece a migrao de processos para outro n menos carregado, sempre procurando balancear a carga de todos os ns no cluster. No cluster Beowulf, os ns escravos no podem ser utilizados normalmente, eles apenas
19

http://www.beowulf.org/ 71

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

Kaminski, Andr vila

servem para processar dados enviados pelo n mestre, utilizando o MPI para comunicao. As tecnologia dos clusters possibilitam a soluo de diversos problemas que envolvem grande volume de processamento. As aplicaes que um cluster pode ter so diversas, indo desde a simples melhora no desempenho de um determinado sistema at o processo de pesquisas cientficas complexas. O que chama a ateno, que todo o processamento pode ser feito de maneira que parea ser um nico computador de alta capacidade. Assim, possvel que determinadas aplicaes sejam implementadas em cluster, mas sem interferir no funcionamento de outras aplicaes que estejam relacionadas. Empresas especializadas, centros de pesquisas e universidades costumam estudar este assunto a fundo. Como conseqncia, existem clusters com at milhares de ns. Um exemplo no Brasil, um cluster que foi desenvolvido em 2003 por um aluno da Universidade Estadual Paulista (Unesp), de So Paulo. Baseado no tipo Beowulf, este cluster ficou bastante conhecido, por ajudar na pesquisa de medicamentos para o tratamento da tuberculose. O valor gasto neste projeto foi 60 mil reais. Se tivesse sido utilizado um supercomputador de capacidade equivalente, os gastos seriam at 17 vezes maior. S por este exemplo, possvel ver os vrios benefcios do uso de clusters. Processamento eficiente, custo baixo e ampla gama de aplicaes. Quem se sujeita a estudar o conceito de clusters poder no s ter sucesso profissional, mas ter um conhecimento grande sobre vrios conceitos da computao em si.

8.1 Esquemas Simples de Clusters

Os sistemas de clusters openMosix e Beowulf podem montados em estruturas simples de rede. Abaixo esto figuras representando os dois modelos.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

72

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

ILUSTRAO 1 - MODELO DE CLUSTER OPENMOSIX

ILUSTRAO 2 - MODELO DE CLUSTER BEOWULF

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

73

Kaminski, Andr vila

Pode-se observar que a estrutura necessria para a montagem destes modelos de clusters simples. Desde o hardware das mquinas at a infra-estrutura da rede so equipamentos facilmente encontrados para venda. O software necessrio livre, todos esto sobre a GPL e no necessitam de gastos para obteno. Estes so os motivos pelos quais os clusters so facilmente implementados e motivo pelo qual so objeto de grandes estudos em universidades.

8.2 Clusters Instantneos

Pode-se utilizar live-CDs, ou seja, CDs bootveis, pode-se fazer estudos para saber como funcionam os sistemas operacionais com funes de cluster, ou apenas por curiosidade, pois estes CDs no necessitam sistemas operacionais instalados no disco rgido, podem ser utilizados sem risco de dano aos seus dados. Existem muitas distribuies Linux que podem ser utilizadas para estudar os clusters que funcionam por live-CDs. Algumas delas so:

ClusterKnoppix http://bofh.be/clusterknoppix/ Cluster openMosix que funciona como um terminal server para mquinas clientes com boot remoto pela rede.

Quantian - http://dirk.eddelbuettel.com/quantian.html Baseado no ClusterKnoppix, modificado para funes cientficas

matemticas para um DVD bootvel.

CHAOS - http://midnightcode.org/projects/chaos/ Mini distribuio em um mini-cd que transforma um PC em um n de cluster openMosix.

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006

74

O QUE O CLUSTER OPENMOSIX - COMPILAO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BSICA DE UM CLUSTER OPENMOSIX.

BCCD - http://bccd.cs.uni.edu/ CD bootvel para estudos do cluster openMosix.

Grendelsbane - http://www.linux4all.de/livecd/ Distribuio baseada em RadHat.

Dyne:bolic - http://www.dynebolic.org/ Voltado produo multimdia. Contm o software Blender 20 .

Mediainlinux -http://www.mediainlinux.org/index.php/mediainlinux Outra distribuio voltada produo multimdia.

EucaristOS - http://eucaristos.sourceforge.net/ Distribuio em um floppy de 1.44Mb para montagem de cluster.

GoMF - http://gomf.sourceforge.net/ Outra distribuio em floppy de 1.44Mb.

Clusterix - http://clusterix.livecd.net/ Distribuio com openMosix + LAM/MPI.

OpenMosixLOAF - http://openmosixloaf.sourceforge.net/ Mais uma distribuio em floppy de 1.44Mb.

Com estas distribuies pode-se montar clusters sem a necessidade de ter conhecimentos de como instalar o GNU/Linux, ou de compilar um kernel especfico com aplicao de patch para openMosix. uma tima oportunidade de ver um supercomputador funcionando.
20

http://www.blender.org/cms/Home.2.0.html 75

Gesto & Conhecimento, v. 4, n.1 , jan./jun. 2006