Вы находитесь на странице: 1из 27
O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX. 1

André Avila Kaminski 2

Resumo Um cluster openMosix é formado por um conjunto de computadores que utilizam um sistema operacional distribuído. É construído a partir de computadores convencionais (nós) ligados em rede, os quais comunicam-se através do sistema de forma que ocorre um balanceamento de carga de processamento entre os nós do cluster. Utiliza-se o kernel Linux para a instalação do sistema, no qual é aplicado um patch que torna possível a compilação de suporte à migração de processos, bem como medição de carga e comunicação entre os nós 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 estações 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 distribuído independe de ser

composto por vários processadores ou recursos físicamente distribuídos, deve

comportar-se com um sistema centralizado do ponto de vista do usuário, sendo

transparente ao mesmo todos os aspectos relativos à distribuição de dados e tarefas,

comunicação e sincronização entre tarefas e a organização física do sistema.

1 Este artigo encontra-se sob a licença Creative Commons. http://creativecommons.org/licenses/by-nc- sa/2.0/br/. Foi liberado pelo próprio autor para ser inserido na Revista Gestão e Conhecimento.

2 Bacharel em Relações Internacionais e estudante de pós-graduação em Software Livre. Bolsista há 2 anos no Instituto de Tecnologia do Paraná (http://www.tecpar.br), atuando em pesquisas de soluções em Software Livre para projetos de migração de plataformas. Pesquisador do desenvolvimento do Software Livre na América Latina, bem como dos impactos políticos e sociais gerados pela evolução do mesmo na região. E-mail: kaminski@tecpar.br

Kaminski, André Ávila

Em uma rede, os nós tendem a ser menos complexos do que os nós de um cluster, pois em uma rede os nós correspondem a Pcs ou estações monoprocessadas. Em um cluster, os nós podem conter dois, quatro ou mais processadores, tendo uma complexidade igual ou até mesmo maior do que máquinas MPP (máquinas proprietárias de processamento massivo), se for considerado a presença de discos e sistemas operacionais. As máquinas SMP (máquinas multiprocessadas) geralmente são mais complexas, pois podem conter um número maior de processadores. As redes de comunicação dos computadores podem ser baseadas em switches de alta velocidade, que permitem a transmissão simultânea de pacotes pertencentes a diferentes pares de comunicação 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 rápidos. Na computação de alto desempenho, utilizada para programação científica, multimídia, gerenciamento de grandes volumes de dados etc., a solução passa por máquinas com múltiplos processadores ou ainda clusters proprietários fornecidos por grandes empresas. Ambas soluções são custosas e de pouca escalabilidade. O projeto openMosix viabiliza a computação de alto desempenho utilizando computadores ligados em rede e com sistema operacional GNU/Linux.

1.1 O Cluster openMosix

Durante a década de 1980, foi utilizado pela força aérea americana, para a construção 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 Jerusalém, Israel, juntamente com o professor Ammon Barak.

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

Em 10 de fevereiro de 2002 surgiu uma extensão do projeto Mosix, o openMsix, baseado na GPLv2 3 para manter os privilégios dessa solução Linux 4 para cluster disponível com software de código aberto, coordenado pelo Ph.D Moshe Bar.

O openMosix é uma extensão do kernel Linux do sistema operacional

GNU/Linux, que faz com que um cluster de computadores se comporte como um grande e único supercomputador através da utilização de migração preemptiva de processos e balenceamento dinâmico de carga. A implementação da migração preemptiva de processos é capaz de migrar

qualquer processo do usuário, em qualquer instante e para qualquer nó disponível de maneira transparente. Para atingir um melhor desempenho este é controlado por algoritmos de balanceamento dinâmico de carga e de prevenção contra a falta de memória. Estes algoritmos são projetados para responder dinamicamente as variações da utilização dos recursos nos diversos nós. Isto garante que o cluster se comporte muito bem, seja numa configuração com poucas ou com muitas máquinas, propiciando uma maior escalabilidade. Se o programa que estamos rodando em uma máquina consumir muito recurso dela, o sistema varre a rede toda e procura uma máquina que esteja com seus recursos mais disponíveis em termos de memória e CPU, e desloca o processo, ou parte dele, para ser executado remotamente, assim, o sistema ganha desempenho.

Os algoritmos de balanceamento dinâmico de carga e de prevenção contra a

falta de memória são descentralizados, não existindo assim a configuração de um controlador mestre e nós escravos como ocorre no Cluster Beowulf 5 para computação paralela. Cada nó um mestre para os processos que são criados localmente, e um servidor para processos remotos, migrados de outros nós do cluster. Sendo assim, podemos acrescentar ou remover as máquinas do cluster em qualquer momento, com um mínimo de disturbio no sistema. Existem também algoritmos de monitoramento que identificam a velocidade de cada nó, a carga da CPU e a memória livre disponível, e

3 http://www.gnu.org/copyleft/gpl.html

4 http://www.kernel.org/ 5 http://www.beowulf.org/

Kaminski, André Ávila

também como está a comunicação interprocessos IPC e a velocidade de acesso a cada processo. O openMosix opera de forma silenciosa, assim as operações são transparentes para as aplicações, pode-se executar aplicações sequenciais e paralelas como se fosse um único computador SMP (multiprocessamento simétrico). Você não precisa saber onde os processos estão sendo executados, nem se preocupar com o que as outras máquinas estão fazendo na rede, por isso ele usa o acrônimo “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. Aplicações que se beneficiam com o openMosix:

– processos CPU-bound: processos com longos tempos de execução e baixo

volume de comunicação entre processos, como aplicações científicas e de engenharia, que necessitam de altas performances de computação;

– grandes compilações;

– processos I/O bound misturados com processos da CPU: executados através do servidor de arquivos, usando o sistema de arquivos distribuídos do openMosix, o MFS (Mosix File System) e o DFSA (Distributed File System Architeture);

– banco de dados que não usem memória compartilhada;

– processos que podem ser migrados manualmente.

As desvantagens do openMosix:

– processos com baixa computação, como aplicativos com alta comunicação interprocessos;

– aplicações com memória compartilhada;

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

– aplicações dependentes do hardware que necessitam de acesso a um

periférico de um nó em especial;

– aplicações com muitas threads não ganham desempenho;

– não se ganha desempenho quando se roda um único processo, tal como seu browser por exemplo.

Aplicações testadas que não migram sobre openMosix:

– programas em Java usando threads nativas não migram desde que eles

utilizem memória compartilhada. Green Threads JVMs, entretanto, podem ser migradas porque cada thread Java é um processo separado;

– aplicações que usam pthreads;

– MySQL, Apache, Oracle, Postgres, SAP, Baan, usam memória compartilhada;

– python com threading habilitada;

– Vmware. Este, ao rodar o Win98, algumas vezes trava e em outras o emulador do sistema operacional pára. Deve-se ter muito cuidado quando utilizar o Vmware com o openMosix.

A característica de não migrar é uma situação normal para programas que falhariam ao serem movimentados pelo openMosix. Estes programas devem rodar como planejado no nó onde foram iniciados.

2.

OPENMOSIX

ALGORITMO

DE

COMPARTILHAMENTO

DE

2.2 Balanceamento Dinâmico de Carga

RECURSOS

DO

CLUSTER

O algoritmo de balanceamento de carga tenta continuamente reduzir a diferença de carga entre pares de nós, transportando processos de um nó muito

Kaminski, André Ávila

carregado para um nó menos carregado. O esquema utilizado não é centralizado, todos

os nós executam o mesmo algoritmo, e a tentativa de redução das diferenças é

executada independentemente e aos pares.

2.3 Anunciador de Memória

O algoritmo do anunciador de memória serve para evitar o exaurimento da

memória. Este é direcionado para tentar colocar a maior ocupação possível da memória do cluster de computadores, evitando ao máximo que ocorra a paginação ou utilização

da memória virtual. Inclusive, é quando um determinado nó começa a fazer muita

paginação que o algoritmo entra em ação. Neste caso específico, este algoritmo tem a

preferência sobre os demais, mesmo que a migração do processo cause um desbalanceamento de carga.

2.4 Migração Preemptiva de Processos

A Migração Preemptiva de Processos (MPP) é capaz de migrar qualquer

processo, em qualquer instante, para qualquer nó do cluste. Usualmente esta migração

é baseada nas informações geradas pelos algoritmos automáticos, mas também podem

ser sobrepostas por operações manuais, sejam estas executas pelo usuário ou por

outros processos. Cada processo tem o seu UHN (Unique Home Node), máquina na qual o processo foi criado.Normalmente é onde o usuário 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 usuário compartilham este ambiente UHN. Os processos

que são migrados para outros nós podem usar os recursos locais do novo nó, caso seja

possível, mas interagem com o ambiente do usuário através do UHN. Para exemplificar esse conceito, podemos dizer que caso o usuário venha a executar um comando "top", este deverá listar todos os processos que o usuário disparou, inclusive aqueles que foram transferidos para os nós remotos. Outro exemplo seria: um dos processos que foi

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

migrado invoca o método "gettimeofday()" que deve retornar o horário corrente da máquina UHN.

O MPP é a principal ferramenta que os algoritmos de gerência de recursos

utiliza, por exemplo, enquanto os recursos, como a memória ou a CPU, estão sub- utilizados 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 serão migrados para outros nós para aproveitar da melhor maneira possível os recursos disponíveis. Todo este processo é feito sem um controle central, não existindo nenhum

relacionamento mestre/escravo entre os nós. Ou seja, cada nó do sistema opera de maneira independente e autônoma, tomando as suas decisões de maneira independente, o que permite uma configuração dinâmica, onde os nós podem entrar ou sair do grupo causando o mínimo de problema. Isto garante uma boa escalabilidade tanto em sistemas de grande porte quanto em pequenos sistemas.

2.5 Implementação da Migração de Processos

O openMosix suporta e implementa de maneira transparente a migração 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 usuário, e outro que é dependente da UHN e que não pode ser migrado, que chamamos de contexto do sistema. O contexto do usuário, chamado de representado, contém o código do programa, a pilha, os dados, os mapas de memória e o estado dos registradores do processo. O representado encapsula todas as informações do processo que estão rodando em modo usuário.

O contexto do sistema, chamado de representante encapsula o processo

quando este está rodando em modo supervisor. Este contém todas as descrições dos recursos os quais o processo faz uso ou está alocado para ele, e a pilha do sistema que

Kaminski, André Ávila

controla a execução do processo. Como ele contém 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 necessário, para qualquer nó do cluster, mas o representante jamais pode ser movido. Como a interface entre o modo usuário e o modo supervisor é muito bem definida e conhecida, é possível e extremamente simples interceptar toda e qualquer interação que existe entre esses dois modos e encaminhá-la para outros nós da rede. Isto é feito numa camada que chamamos de camada de adaptação a qual contém um canal especial de comunicação para a interação entre elas.

Por causa desta divisão o processo a ser migrado tem um tempo de migração também composto por duas partes, uma fixa que é o tempo para criar a imagem do processo no nó remoto, e uma parte linearmente proporcional ao número de páginas a serem transferidas do processo. Para tentar minimizar a sobrecarga imposta pela migração, somente a tabela de páginas e as páginas marcadas como "sujas" do processo são transferidas. No momento da execução o openMosix garante a transparência de localização, transferindo todas as chamadas de sistema que são dependentes do local para o representante que está no UHN do processo. Estas chamadas são síncronas, ou seja, são interceptadas pela camada de adaptação remota e transferidas pelo canal especial de comunicação para o nó onde o processo foi lançado, este é executado e o retorno é re-transferido para o nó remoto o qual segue na execução do processo. Se durante esta execução a camada de adaptação descobre que algumas dessas chamadas ao sistema são independentes da localização, esta decide por não mandar a chamada para o UHN e a executa localmente, melhorando assim o desempenho. Evidentemente existem outras formas de interação entre os dois contextos do processo, como sinais, dados chegando pela rede, eventos, etc. Estes tipos de interações 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 comunicação para ver se algum evento ou dado chega para ele. Ao mesmo

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

tempo o representante verifica sempre se alguma ação deve ser tomada quando algum tipo de evento ou dado chega para ele. Essa implementação é bastante robusta e independente de modificações que ocorram no núcleo do sistema, assim como não utiliza características especiais do sistema ou da máquina, o que garante que isso possa ser portado para diferentes arquiteturas de máquinas. Porém 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 nós. No entanto, normalmente, os ganhos são maiores o que justifica a implementação deste sistema. Algumas funções do núcleo do sistema não são compatíveis com esse esquema de divisão do processo em duas partes, como, por exemplo, escrita em memória compartilhada, aplicações em tempo real, instruções que acessem um barramento específico, dentre outras. Nestes casos, os processo são 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 nós. 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 opções 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 requisições para o nó no qual o processo se originou. A segunda, seria criar uma visão global do sistema de arquivos através de NFS. A primeira é mais difícil de desenvolver, mas mais fácil de manter em operações do dia-a-dia. A segunda é mais fácil de implementar, mas pode ser mais

Kaminski, André Ávila

problemático montar todos sistemas de arquivos de maneira inteligente, permitindo que cada nó acesse todos os outros nós. Adicionalmente é preciso ter certeza que todos os UIDs (identificador de usuários no sistemas Linux) e GIDs (identificador de grupos nos sistemas Linux) são consistentes para todos os nós no cluster, em contrapatida sérios problemas de permissões de acessos aos arquivos irão aparecer. Até então o openMosix suportou as duas opções. Mas agora está surgindo um novo sistema de arquivos de cluster para Linux que permite uma visão compartilhada de todos os sistemas de arquivos. Desenvolvedores de clusters dizem que todas as soluções atuais para sistemas de arquivos de cluster do tipo cluster-wide são 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 execução de I/Os feitas por chamadas de sistemas de processos migrados. Isto foi feito permitindo que a execução de grande parte das chamadas de sistemas seja feita localmente - no nó onde o processo se encontra. Além disso, o DFSA possui um novo algoritmo que leva em conta as operações de I/O que foi adicionado à política de distribuição de processos do openMosix (balanceamento de carga). O resultado dessas inovações é que os processos que executam de moderado a alto volume de I/Os provavelmente serão 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 terão uma flexibilidade maior para migrar de seus respectivos nós originais para que o sistema obtenha um melhor balanceamento de carga. Então, 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 através da rede, um cluster openMosix tenta migrar os processos para um nó no qual o arquivo está armazenado.

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

3.

CONSTRUINDO UM CLUSTER OPENMOSIX

 
 

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

A primeira opção seria utilizar uma distribuição Linux diretamente de um CD

bootavel. Estas distribuições são voltadas exatamente para a montagem de

clusters, facilitando muito o aprendizado de iniciantes no mundo dos

supercomputadores, pois é necessário apenas dar o boot pelo CD em duas ou

mais máquinas interligadas em rede para ver um cluster funcionando. Pode-se

citar como exemplo de distribuições a distribuição ClusterKnoppix 6 , que serve

como um “Terminal Server” para máquinas clientes com boot via PXE e a

distribuição dyne:bolic, voltada para produção multimídia. Outras distribuições

bootáveis podem ser encontradas

no

site

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

A segunda opção, a qual será descrita neste artigo, é utilizar uma distribuição

Linux qualquer com instalação física na máquina. Deve-se utilizar um kernel

Linux e aplicar um patch neste kernel, habilitando-o às necessidades do

openMosix.

 

3.1

Escolhendo uma Distribuição Linux

A distribuição Linux a ser utilizada depende muito da opção da pessoa

responsável pelo cluster, pois o importante é o kernel Linux estar habilitado para

trabalhar com o openMosix. Para a construção de um cluster openMosix a distribuição

Debian GNU/Linux 7 é amplamente utilizada, mas pode-se encontrar tutoriais de

montagem de um cluster openMosix com várias outras distribuições, como o tutorial

openMosix Cluster on Gentoo 8 ” do Gentoo Linux 9 , por exemplo.

6 http://bofh.be/clusterknoppix/

7 http://www.debian.org/

8 http://www.gentoo.org/doc/en/openmosix-howto.xml

Kaminski, André Ávila

Será utilizada o Debian GNU/Linux para a montagem do cluster openMosix. Existem nos repositórios da distribuição os pacotes necessários para a instalação do cluster e monitoração do mesmo, e pode-se encontrar também na internet shell scripts para demonstrar a migração de processos entre os nós 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 estações. No site oficial do projeto openMosix 10 apenas o patch para o kernel versão 2.4.26 é disponibilizado como estável, mas existem patchs para outras versões em um site não-oficial 11 , onde encontra-se até mesmo para as últimas versões. Na internet fica fácil encontrar resoluções de problemas para versões mais antigas do kernel, enquanto para as versões mais recentes encontrase pouca coisa, por isso é aconselhável utilizar versões mais velhas do kernel. Atualmente (10/11/2005) o kernel Linux está na versão estável 2.6.14.1, mas como o patch para esta versão ainda não está oficialmente declarado estável pelos mantenedores do projeto openMosix, será utilizado o kernel 2.4.26, o qual se mostra muito estável para a função.

3.3 Iniciando a Montagem do Cluster para Demonstração dos Testes

Para demonstração do funcionamento de um cluster openMosix, serão utilizadas duas máquinas com sistema operacional Debian GNU/Linux com um kernel 2.4.26 com o patch devidamente aplicado. As configurações das máquinas (nós) do cluster são:

Máquina 01 (N1):

– Notebook Acer / TravelMate 260

9 http://www.gentoo.org/

10 http://openmosix.sourceforge.net/

11 http://openmosix.snarc.org/

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

– Processador Intel Mobile Pentium III 1000MHz, 512KB cache

– 256MB de memória RAM – Placa de rede fast ethernet RealTek RTL-8139 10/100

Máquina 02 (N2):

– Processador AMD Athlon 2800+ (1800MHz), 64 bits, 512KB cache

– 512MB de memória RAM

– Placa de rede gigabit ethernet Realtek RTL8169/8110 10/100/1000

No sistema operacional Debian GNU/Linux da N1 está instalado a interface gráfica Gnome 12 , para que seja possível a visualização da migração de processos entre

os nós do cluster através do aplicativo openMosixview 13 , versão 1.5. Neste aplicativo podem ser vistos a eficiência do balanceamento de carga entre os nós, a memória total do cluster, o número de processadores do cluster, a porcentagem de memória utilizada

e também existem opções para visualizar a migração de processos entre os nós, os

processos que estão em andamento e gráficos da carga dos nós do cluster, dando a opção de poder gravar e/ou imprimir estes gráficos. É necessária a interface gráfica na N1 por dois motivos: o primeiro seria a demonstração gráfica da migração de processos; o segundo seria por ser uma máquina com menor poder de processamento

e memória RAM, facilitando a indução de migração de processos para a N2. Na máquina N2 não haverá necessidade de utilizar interface gráfica, pois assim haverá mais memória livre para os testes. No nó N2 não haverá mais nada rodando a mais do que o sistema operacional Debian GNU/Linux e o openMosix. A ligação entre os dois nós do cluster será feita por um cabo crossover, por ter apenas dois nós, e sem a necessidade de conexão com outra rede ou máquinas, será dispensado a utilização 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 limitação está na placa de rede do nó N1.

12 http://www.gnome.org/

Kaminski, André Ávila

4. COMPILADOR PARA UM KERNEL LINUX COM SUPORTE AO CLUSTER

OPENMOSIX

Para que se possa compilar um Kernel Linux openMosix é necessário utilizar a

versão 3.3.2 do compilador gcc 14 , pois quando utilizada outra versão, a compilação

apresentou muitos erros, impossibilitando a criação do kernel openMosix.

Para isso foi necessário fazer o download do código 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 opção 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 necessário para a criação do kernel

openMosix. O executável do compilador gcc versão 3.3.2 será instalado no diretório

/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 versão 2.4.26 para a

utilização nos nós, tanto no N1 quanto no N2. Não há nada a mais nos kernels de

ambas as máquinas do que o necessário para cada uma funcionar como um nó de

13 http://www.openmosixview.com/

14 http://gcc.gnu.org/

15 http://mirrors.usc.edu/pub/gnu/gcc/gcc-3.3.2/gcc-3.3.2.tar.bz2

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

cluster openMosix e habilitar as funcionalidades necessárias para a demosntração do

funcionamento do cluster.

O primeiro passo foi fazer o download do código fonte do kernel 2.4.26 16 do site

oficial do Kernel Linux, descompar o código fonte no diretório correto:

mv linux-2.4.26.tar.bz2 /usr/src/

cd /usr/src/

tar jxvf linux-2.4.26.tar.bz2

Criar o link simbólico:

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 diretório correto:

bunzip2 openMosix-2.4.26-1.bz2

mv openMosix-2.4.26-1 /usr/src/linux/

O código fonte do kernel já está, juntamente com o patch apropriado, dentro do

diretório correto. Agora, antes de aplicar o patch no kernel, é necessário retirar do

código fonte do kernel tudo que não for necessário para a compilação, com os

seguintes comandos:

cd /usr/src/linux/

make clean

make mrproper

E

copiar uma configuração básica para o kernel:

cp

arch/i386/defconfig .config

E

então aplicar o patch de modificação:

16 http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.26.tar.bz2

17 http://prdownloads.sourceforge.net/openmosix/openMosix-2.4.26-1.bz2?download

Kaminski, André Ávila

cat openMosix-2.4.26-1 | patch -Np1

Este último comando não deverá retornar erro algum. Se algum erro ocorrer,

verifique se a versão do kernel e do patch são as mesmas citadas acima. Neste ponto

está efetuada a modificação no código fonte do Kernel Linux. Isto modificou cerca de

3% do código fonte, acrescentando algumas entradas para que seja possível a correta

compilação do kernel com suporte à todas as funcionalidades do openMosix.

O próximo passo é selecionar no kernel o que for necessário e terminar a

compilação. 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

não ser que todas as máquinas do cluster tenhas exatamente a mesma configuração.

O próximo comando para acessar a interface de configuração do kernel é:

cd /usr/src/linux make menuconfig

Uma interface com todas opções do kernel Linux é aberta, possibilitando a

ativação do hardware necessário para uma boa compilação. Pode-se observar uma

entrada “openMosix” na primeira linha, a qual não estaria presente se o patch não

tivesse sido aplicado. É necessário que no kernel estejam presentes no mínimo as

seguintes configurações:

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 questão

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

Na entrada “Block devices”, para suporte à comunicação 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 questão 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 questão

Deve-se gravar as configurações e sair da interface.

Basicamente é isso que deve estar no kernel. É aconselhável não colocar nada

que não seja necessário, para maior performance do sistema.

Agora, depois de ter configurado o kernel para ser compilado com suporte à

todas as necessidades, já é possível começar a compilação do kernel para a máquina

utilizando o gcc versão 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 diretório /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 ,

então:

Kaminski, André Ávila

vi /boot/grub/menu.lst

E adiciona as entradas necessárias para o sistema bootar pelo novo kernel

openMosix:

Ao reiniciar o sistema pelo novo kernel, se for necessário fazer alguma mudança,

é só adicionar ou remover as entradas na configuração 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 nós.

6. EXECUTANDO OS TESTES

Para demonstrar o funcionamento do cluster openMosix, formado pelos nós N1 e

N2, utilizou-se um shell script (teste-om.sh) elaborado com a função 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 máximo,

chegando a utilizar 100% da CPU dos nós. O nó utilizado para rodar o script foi o nó

N1, que tem menor poder de processamento, já para demonstrar a migração dos

processos para o nó N2, uma máquina 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/

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA 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 também são demonstrados, com a finalidade de

medir quanto tempo foi necessário para rodar o script apenas no nó N1, com o cluster

desativado, e também nos nós 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

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

-

 

inicio

 

fim

total (s)

Teste 01

00h

46m

00h

49m

141s

52s

13s

Teste 02

00h

49m

00h

52m

138s

57s

15s

Teste 03

00h

52m

00h

54m

141s

22s

43s

Teste 04

00h

54m

00h

57m

138s

56s

14s

Teste 05

00h

57m

00h

59m

139s

18s

37s

Media

 

-

 

-

139,4s

O tempo de processamento do script variou entre 138 segundos e 141

segundos, obtendo-se uma média de 139,4 segundos. Pode-se observar que o tempo

de processamento nos cinco testes efetuados com o cluster openMosix desativado não

tiveram uma variação muito considerável, isso demonstra que não 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

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA 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

-

 

inicio

 

fim

total (s)

Teste 01

00h

37m

00h

38m

55s

31s

26s

Teste 02

00h

38m

00h

39m

59s

36s

35s

Teste 03

01h

26m

01h

27m

59s

25s

24s

Teste 04

01h

34m

01h

35m

58s

04s

02s

Teste 05

15h

55m

15h

56m

59s

38s

37s

Media

 

-

 

-

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 média de 58 segundos.

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 eficiência 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 dinâmico de balanceamento de carga do no N1, utilizou a migração preemptiva de processos para migrar alguns processos para o nó N2, que, além de ser mais potente, não estava sobrecarregado, deste modo, o processamento do script foi distribuido pelos nos do cluster, diminuindo muito o tempo de execução do script. O aplicativo openMosixView, instalado no nó N1, demonstrou graficamente a migração dos processos. Pode-se observar três, 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 não foi observado o processo na lista do aplicativo top, porem observou-se a mudanca do nível do processamento da máquina. Se os testes estivessem sido efetuados em um cluster openMosix com tres, quatro, cinco nos ou mais, poderia ser observada a migração para todos os nos que estivessem sendo pouco utilizados, e o tempo de execucao do script seria muito menor. O cluster openMosix não tem a capacidade de dividir o processamento de apena um software para os seus nós, o openMosix apenas migra processos inteiros para nós menos sobrecarregados com a finalidade de balancear a carga dos nós.

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

O Projeto Beowulf 19 , iniciado pela NASA em 1994, não 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 nós o processamento, o que o cluster openMosix não 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 nós 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 aplicação de efeitos especiais e renderização de imagens em produções cinematográficas.

A estrutura do cluster Beowulf necessita de um nó mestre (front-end) que

controla a distribuição de tarefas entre os nós escravos, assim não há migração de processos entre os nós escravos, como no cluster openMosix. Por ser um tipo muito potente de cluster, é amplamente explorado em universidades e aplicado para várias 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 nós do cluster. O MPI é mais avançado, pois trabalha com mensagens para todos os nós do cluster, ou apenas para um determinado grupo. Não pode-se comparar qual modelo de cluster é melhor, isso deve ser decidido dependendo da finalidade de utilização do cluster. No openMosix, por exemplo, todos os computadores podem continuar sendo utilizados, e quando algum estiver sobrecarregado de processamento, acontece a migração de processos para outro nó menos carregado, sempre procurando balancear a carga de todos os nós no cluster. No cluster Beowulf, os nós escravos não podem ser utilizados normalmente, eles apenas

19 http://www.beowulf.org/

Kaminski, André Ávila

servem para processar dados enviados pelo nó mestre, utilçizando o MPI para comunicação. As tecnologia dos clusters possibilitam a solução de diversos problemas que envolvem grande volume de processamento. As aplicações que um cluster pode ter são diversas, indo desde a simples melhora no desempenho de um determinado sistema até o processo de pesquisas científicas complexas. O que chama a atenção, é que todo o processamento pode ser feito de maneira que pareça ser um único computador de alta capacidade. Assim, é possível que determinadas aplicações sejam implementadas em cluster, mas sem interferir no funcionamento de outras aplicações que estejam relacionadas. Empresas especializadas, centros de pesquisas e universidades costumam estudar este assunto a fundo. Como conseqüência, existem clusters com até milhares de nós. Um exemplo no Brasil, é um cluster que foi desenvolvido em 2003 por um aluno da Universidade Estadual Paulista (Unesp), de São 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, é possível ver os vários benefícios do uso de clusters. Processamento eficiente, custo baixo e ampla gama de aplicações. Quem se sujeita a estudar o conceito de clusters poderá não só ter sucesso profissional, mas ter um conhecimento grande sobre vários conceitos da computação em si.

8.1 Esquemas Simples de Clusters

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

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

ILUSTRAÇÃO 1 - MODELO DE CLUSTER OPENMOSIX

OPENMOSIX. ILUSTRAÇÃO 1 - MODELO DE CLUSTER OPENMOSIX ILUSTRAÇÃO 2 - MODELO DE CLUSTER BEOWULF Gestão

ILUSTRAÇÃO 2 - MODELO DE CLUSTER BEOWULF

Gestão & Conhecimento, v. 4, n.1 , jan./jun. 2006 73
Gestão & Conhecimento, v. 4, n.1 , jan./jun. 2006
73

Kaminski, André Ávila

Pode-se observar que a estrutura necessária para a montagem destes modelos de clusters é simples. Desde o hardware das máquinas até a infra-estrutura da rede são equipamentos facilmente encontrados para venda. O software necessário é livre, todos estão sobre a GPL e não necessitam de gastos para obtenção. Estes são os motivos pelos quais os clusters são facilmente implementados e motivo pelo qual são objeto de grandes estudos em universidades.

8.2 Clusters Instantâneos

Pode-se utilizar live-CDs, ou seja, CDs bootáveis, pode-se fazer estudos para saber como funcionam os sistemas operacionais com funções de cluster, ou apenas por curiosidade, pois estes CDs não necessitam sistemas operacionais instalados no disco rígido, podem ser utilizados sem risco de dano aos seus dados. Existem muitas distribuições Linux que podem ser utilizadas para estudar os clusters que funcionam por live-CDs. Algumas delas são:

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

Quantian - http://dirk.eddelbuettel.com/quantian.html Baseado no ClusterKnoppix, é modificado para funções científicas matemáticas para um DVD bootável.

CHAOS - http://midnightcode.org/projects/chaos/ Mini distribuição em um mini-cd que transforma um PC em um nó de cluster openMosix.

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER

O QUE É O CLUSTER OPENMOSIX - COMPILAÇÃO DE UM KERNEL LINUX PARA UM CLUSTER OPEN/MOSIX E MONTAGEM BÁSICA DE UM CLUSTER OPENMOSIX.

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

Grendelsbane - http://www.linux4all.de/livecd/ Distribuição baseada em RadHat.

Dyne:bolic - http://www.dynebolic.org/ Voltado à produção multimídia. Contém o software Blender 20 .

Mediainlinux -http://www.mediainlinux.org/index.php/mediainlinux Outra distribuição voltada à produção multimídia.

EucaristOS - http://eucaristos.sourceforge.net/ Distribuição em um floppy de 1.44Mb para montagem de cluster.

GoMF - http://gomf.sourceforge.net/ Outra distribuição em floppy de 1.44Mb.

Clusterix - http://clusterix.livecd.net/ Distribuição com openMosix + LAM/MPI.

OpenMosixLOAF - http://openmosixloaf.sourceforge.net/ Mais uma distribuição em floppy de 1.44Mb.

Com estas distribuições pode-se montar clusters sem a necessidade de ter conhecimentos de como instalar o GNU/Linux, ou de compilar um kernel específico com aplicação de patch para openMosix. É uma ótima oportunidade de ver um supercomputador funcionando.

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