SERVIO NACIONAL DE APRENDIZAGEM INDUSTRIAL CURSO TCNICO EM REDES DE COMPUTADORES TIAGO RAFAEL PERIN

PROCESSAMENTO DISTRIBUDO

JARAGU DO SUL 2008

TIAGO RAFAEL PERIN

PROCESSAMENTO DISTRIBUDO Trabalho apresentado banca examinadora de TCC do curso Tcnico em Redes de Computadores do SENAI/SC Jaragu do Sul, sob a orientao do Prof. Rodrigo Machado Prado.

JARAGU DO SUL 2008

RESUMO

Este trabalho tem como objetivo apresentar um mtodo vivel para utilizao de mtodos em cluster atravs da ferramenta openMosix. Alm de ser relatado sobre o contedo terico do mesmo, realizam-se estudos de caso afim de se testar a implantao realizada no desenvolvimento do projeto. Utilizou-se um software para renderizao de imagens, sendo este um tpico de teste. Outro fato de teste, foi o balanceamento de carga, migrao de processos, pontos de falha, entre outros. Portanto, com a utilizao do openMosix e todo o seu conjunto de ferramentas grficas para administrao do sistema, tornando assim mais fcil, rpido e intuitivo o seu manuseio, possvel implantar aplicaes que exijam alto poder computacional com um baixo custo de hardware e tempo.

NDICE DE FIGURAS

Figura 1: Logotipo do OpenMosixview........................................................................26 Figura 2: Topologia do cluster.....................................................................................30 Figura 3: rea de Trabalho: ClusterKnoppix...............................................................33 Figura 4: Tela Inicial do OpenMosixview.....................................................................34 Figura 5: Janela de Configurao...............................................................................37 Figura 6: OpenMosixmigmon......................................................................................39 Figura 7: OpenMosixprocs..........................................................................................41 Figura 8: Gerenciados de Processos Remotos..........................................................42 Figura 9: Janela de Migrao......................................................................................43 Figura 10: OpenMosixanalyzer...................................................................................45 Figura 11: OpenMosixanalyzer: estatstica dos nodos...............................................46 Figura 12: OpenMosixhistory......................................................................................47 Figura 13: Teste de Comunicao: Migrao de Processos.......................................49 Figura 14: Teste de Comunicao: Balanceamento de Carga...................................50 Figura 15: Renderizao de imagens em 1 computador............................................54 Figura 16: Renderizao de imagens em 4 ns.........................................................55 Figura 17: Comportamento dos ns durante a renderizao.....................................56 Figura 18: Balanceamento de carga durante a renderizao.....................................57 Figura 19: Renderizao de imagens em 9 ns.........................................................57 Figura 20: Relao Tempo X Nmero de Ns............................................................58 Figura 21: openMosixmigmon com 9 ns e 30 processos..........................................60 Figura 22: Relao Tempo X Nmero de Processos..................................................61 Figura 23: N sobrecarregado ao executar o script....................................................62 Figura 24: Aplicao funcionando normalmente.........................................................63 Figura 25: OpenMosixview com um n desconectado...............................................64 Figura 26: Aplicao "travada" aps o nodo ser desconectado.................................65

NDICE DE QUADROS

Quadro 1: Comando para ativao da ferramenta principal.......................................34 Quadro 2: Comando para ativao do openMosixmigmon.........................................38 Quadro 3: Comando para ativao do openMosixprocs.............................................40 Quadro 4: Comando para ativao do openMosixanalyzer........................................45 Quadro 5: Comando para ativao do openMosixhistory...........................................46 Quadro 6: Script de teste de comunicao.................................................................48 Quadro 7: Comando para execuo do script de teste de comunicao...................48 Quadro 8: Script para renderizao de imagens........................................................52 Quadro 9: Comando para execuo da renderizao de imagens no blender..........53 Quadro 10: Tempo de renderizao com n de processos iguais ao n de ns.........58 Quadro 11: Tempo de renderizao em 9 ns com diferentes n de processos........60

SUMRIO

1 INTRODUO..........................................................................................................7 1.1 OBJETIVO GERAL............................................................................................8 1.2 OBJETIVOS ESPECFICOS..............................................................................8 1.3 JUSTIFICATIVA..................................................................................................8 1.4 METODOLOGIA.................................................................................................9 2 CONCEITOS DO CLUSTER...................................................................................11 2.1 HISTRIA.........................................................................................................11 2.2 DEFINIO......................................................................................................12 2.3 TIPOS DE CLUSTER.......................................................................................13 2.3.1 Cluster de Alta Disponibilidade.............................................................13 2.3.2 Cluster de Alto Desempenho.................................................................14 2.3.3 Cluster de Balanceamento de Carga....................................................15 2.4 PRINCIPAIS CARACTERSTICAS DE UM CLUSTER...................................16 2.4.1 Escalabilidade.........................................................................................16 2.4.2 Tolerncia a Falhas.................................................................................17 2.4.3 Custo Reduzido.......................................................................................17 2.4.4 Independncia de Fornecedores..........................................................18 3 SOFTWARES DO CLUSTER.................................................................................19 3.1 SISTEMA OPERACIONAL...............................................................................19 3.1.1 Linux.........................................................................................................20 3.1.1.1 ClusterKnoppix..................................................................................20 3.2 OPENMOSIX....................................................................................................21 3.2.1 Algoritmos de Compartilhamento de Recursos..................................23 3.2.1.1 Balanceamento Dinmico de Carga.................................................24 3.2.1.2 Algoritmo de Anunciao de Memria...............................................24 3.2.2 Migrao Preemptiva de Processos.....................................................25 3.2.3 OpenMosixVIEW.....................................................................................26 3.2.3.1 OpenMosixview.................................................................................26 3.2.3.2 OpenMosixprocs................................................................................27 3.2.3.3 OpenMosixcollector...........................................................................27 3.2.3.4 OpenMosixanalyzer...........................................................................27 3.2.3.5 OpenMosixhistory..............................................................................28 3.2.3.6 OpenMosixmigmon............................................................................28 4 PLANEJAMENTO E REQUISITOS........................................................................29 4.1 PLANEJAMENTO DO SISTEMA.....................................................................29 4.2 REQUISITOS DE HARDWARE.......................................................................31 4.3 REQUISITOS DE SOFTWARE........................................................................31 5 CONFIGURAO DO CLUSTER..........................................................................32 5.1 INSTALAO DO SISTEMA OPERACIONAL................................................32 5.2 FERRAMENTAS DO OPENMOSIX.................................................................33 5.2.1 OpenMosixview Viso do openMosix................................................34 5.2.2 OpenMosix-configuration Janela de Configurao ........................36 5.2.3 OpenMosixmigmon Monitor de Migraes.......................................38 5.2.4 OpenMosixprocs Gerenciador de Processos...................................40 5.2.5 OpenMosixcollector...............................................................................44

5.2.6 OpenMosixanalyzer................................................................................44 5.2.7 OpenMosixhistory..................................................................................46 6 COMUNICAO.....................................................................................................48 7 TESTANDO A APLICAO NO OPENMOSIX......................................................51 7.1 APLICAO UTILIZADA.................................................................................51 7.2 RESULTADOS DAS COMPARAES............................................................53 7.2.1 Renderizao com nmero iguais de processos e nodos................53 7.2.2 Renderizao em 9 nodos com nmero de processos diferentes....59 7.3 PONTOS DE FALHA........................................................................................63 8 CONCLUSO.........................................................................................................66 REFERNCIAS...........................................................................................................67

7 1 INTRODUO

Com o passar dos anos, diversas aplicaes desenvolvidas necessitam de computadores cada vez mais potentes. Com isso, indstrias de pequeno e mdio porte geralmente no possuem condies financeiras de obterem

supercomputadores. Com o objetivo de suprir toda essa demanda de poder, foi desenvolvido um mtodo que interligasse diversos computadores com o intuito de dividir as tarefas de processamento. Esse conjunto foi denominado cluster. Dessa forma, o trabalho apresenta as vantagens de se utilizar o mesmo durante um processamento que requer alto desempenho da mquina. Isto ser comprovado atravs de pesquisas e testes que comprovam a sua eficincia. Um cluster nada mais que computadores comuns interligados em rede. Esse mtodo vivel principalmente pelo baixo custo que apresenta, pois so utilizados computadores comuns, com um desempenho muito semelhante a um computador de alta performance que tem um custo mais elevado. Desse modo, mais vivel utilizar-se de um cluster do que encomendar um supercomputador. Outra vantagem a questo de tolerncia a falhas, pois os supercomputadores geralmente so construdos sob encomenda, o que torna o proprietrio totalmente dependente dos fornecedores caso haja alguma falha no sistema. Isto no acontece no caso de um cluster, que pode utilizar computadores comuns, como os usados por usurios domsticos, o que facilita a manuteno, pois no possui um sistema muito complexo em relao a um computador de alta performance.

8 1.1 OBJETIVO GERAL

Implantar um cluster de balanceamento de carga, utilizando sistema operacional ClusterKnoppix 3.6.

1.2

OBJETIVOS ESPECFICOS

Os objetivos especficos deste trabalho so:

Realizar uma pesquisa aprofundada sobre a utilizao do mtodo de processamento cluster;

Estabelecer a comunicao entre os computadores presentes no sistema; Utilizar uma aplicao que realize o teste do sistema cluster; Realizar a comparao entre o sistema de cluster e uma mquina nica; Analisar o comportamento do cluster, considerando pontos de falha.

1.3

JUSTIFICATIVA

Empresas de pequeno e mdio porte, ou at mesmo usurios domsticos, necessitam de computadores que ofeream desempenho elevado para executar os

9 programas que necessitam de alto poder computacional. Usando o sistema cluster, o proprietrio no necessita investir em um supercomputador. Ele apenas necessita de dois ou mais computadores comuns, ou seja, que no possuem processadores sofisticados, porm quando interligados, se tornam to eficientes quanto um supercomputador independente. Alm do mais o cluster facilita a expansibilidade do sistema, pois necessita simplesmente da insero de um novo nodo ao conjunto. Percebe-se a importncia desse tema para que os usurios possam conhecer os benefcios de quando e como utiliz-lo, sendo este um meio de reduzir custos de forma significativa e ao mesmo tempo obtendo alta performance e disponibilidade.

1.4

METODOLOGIA

A realizao do projeto teve incio no ms de julho e sua concluso prevista para o ms de dezembro de 2008. O trabalho ser desenvolvido em duas etapas, sendo que a primeira delas especificamente buscar o aprofundamento em pesquisas bibliogrficas sobre o assunto abordado atravs de revistas, trabalhos cientficos, livros e artigos via web, para desenvolver a introduo ao projeto e aprimoramento nas tcnicas para a elaborao do sistema. A segunda etapa definida para o desenvolvimento da soluo e realizao dos devidos testes utilizando os computadores oferecidos pela instituio SENAI/Jaragu do Sul e, se necessrio, mais pesquisas para obter as solues para resoluo dos possveis problemas que possam ocorrer nos testes efetivados. Abaixo segue o cronograma das datas e

10 procedimentos a serem cumpridos. Atividades Meses Jul 1 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 2 Ago 1 2 Set 1 2 Out 1 2 Nov 1 2 Dez 1 2

Quinzenas Definio do Tema Avaliao do Formulrio -realizada pelo orientador Levantamento Bibliogrfico Produo do Pr-Projeto em relao ao formulrio Entrega e avaliao do prprojeto Produo do TCC em relao ao pr-projeto Implementao do sistema Testes Pesquisas para solucionar problemas nos testes Entrega e avaliao da verso Parcial do TCC Produo do TCC em relao verso parcial Entrega da verso final do TCC Apresentao do TCC para a banca examinadora

Formulrio de Acompanhamento X

11 2 CONCEITOS DO CLUSTER

Neste captulo esto disponveis os assuntos pesquisados para auxiliar no desenvolvimento do projeto. Dividiu-se em sees para cada assunto. Na seo 2.1 ser abordado sobre a histria do cluster, desde os seus primrdios. No tpico 2.2 definem-se os conceitos os conceitos e tecnologias envolvidos no mesmo. A seo 2.3 aborda os principais tipos de cluster e suas funes especficas. No tpico 2.4 apresentam-se as principais caractersticas de um sistema de processamento distribudo explicando o que cada caracterstica significa.

2.1

HISTRIA

Os clusters surgiram a partir do momento em que uma tarefa no podia ser executa somente por um nico computador e tambm quando as tarefas exigiam um nvel maior de segurana e processamento, o que um computador sozinho no garantia. A data especfica do surgimento e utilizao dos primeiros clusters desconhecida, porm eles foram utilizados por volta do fim da dcada de 50 e incio da dcada de 60 (MARCO, 2006). Os clusters atuais so bem sucedidos devido as grandes evolues das redes de computadores, do desenvolvimento do protocolo TCP/IP (Transmission Control Protocol/Internet Protocol) e do sistema operacional Unix na dcada de 70

12 (BECHER, 2007), que mais adiante seria a base do sistema operacional Linux, desenvolvido por Linus Torvalds. Em 1962, surgiu o conceito de redes baseado na comutao de pacotes desenvolvido pela RAND Corporation, deste modo em 1969 surgiu um dos primeiros clusters utilizando hardware comum e foi apelidado de ARPANET. Por volta de 1983, surgiram protocolos e ferramentas que facilitaram a distribuio de tarefas entre diferentes CPUs. Em 1977, surgiu a primeira soluo de cluster comercial desenvolvido pela empresa Datapoint e nomeado de ARCNET (BECHER, 2007), que permitia a ligao de mquinas em rede por meio de hardware, aplicativo e outros equipamentos.

2.2

DEFINIO

Tambm chamado de Clustering,cluster o nome dado a um sistema montado com mais de um computador, cujo objetivo fazer com que todo o processamento da aplicao seja distribudo aos computadores, mas de forma que parea com que eles sejam um computador s. (ALECRIM, 2004)

Em outras palavras, os computadores dividem as tarefas a serem processadas trabalhando como se fosse um computador s. Dessa forma possvel realizar processamentos pesados com alta taxa de velocidade, o que at ento s computadores de alta performance conseguiriam, com um custo mais acessvel do que a compra de um computador de alto nvel. Cada um dos equipamentos

13 interligados chamado de n e, normalmente, existe um n mestre que gerencia e/ou divide as tarefas entre os demais ns, chamados de escravos (OLIVEIRA, 2004), ou seja, um computador ser configurado como o n mestre com a funo de dividir o processamento para cada computador escravo.

2.3

TIPOS DE CLUSTER

Existem diversos tipos de cluster, entre eles, pode-se citar de modo geral: alta disponibilidade, alto desempenho e balanceamento de carga. A seguir ser aprofundado sobre cada um deles.

2.3.1

Cluster de Alta Disponibilidade

Este tipo de cluster muito utilizado em tarefas que necessitem estar operando 24 horas por dia, como por exemplo, previso meteorolgica e o sistema bancrio. Esse modelo tem a finalidade principal de prover uma alta taxa de confiana, mantendo ao mximo tempo disponvel, os servios e recursos de forma ininterrupta (PINTO; SILVA; SILVEIRA, 2007). Os recursos tm que estar sempre, ou quase sempre, disponveis para atender s requisies dos clientes, ou seja, tm de estar acessveis por um perodo de tempo muito prximo a 100% (PEREIRA, 2004). Assim um dos requisitos exigidos na alta disponibilidade eliminar os pontos

14 de falhas. Para isso necessria a redundncia de equipamentos e/ou servios, ou seja, caso um computador da rede falhar, o outro automaticamente o substitui sem haver perda de dados e assim sucessivamente. Tambm so mantidas cpias dos recursos, pois caso houver a parada dos servios disponibilizados, este por fim, substitudo pelas cpias realizadas anteriormente. Entretanto, como foram utilizados equipamentos redundantes, o sistema no disponibiliza todo o desempenho que poderia oferecer ao aplicativo.

2.3.2

Cluster de Alto Desempenho

Neste tipo de cluster, as tarefas que exigem um grande poder computacional so divididas em nodos, ou seja, so executados de forma paralela a fim de dividir o tempo de processamento da tarefa. Desta forma, quanto mais computadores estiverem no sistema, menor ser o tempo de processamento (PEREIRA, 2004). Este mtodo muito utilizado para renderizao de imagens, processamentos de clculos de engenharia, banco de dados robustos, entre outros que exijam alto grau de processamento. Existem dois tipos de arquiteturas: a centralizada e a descentralizada (CARDOSO; LEO, 2004). A arquitetura centralizada apresenta um n mestre, que gerencia todos os outros ns, denominados escravos porque eles possuem apenas a funo de executar os processamentos enviados pelo n mestre. Sua principal vantagem que o processamento dividido por todos os componentes do cluster sendo que

15 raramente haver ns ociosos. Porm a sua desvantagem que se o n mestre vir a falhar ou parar de funcionar todo o sistema ficar em desuso (CARDOSO; LEO, 2004). Na arquitetura descentralizada, cada n o seu prprio mestre. Se caso houver falha de um n, haver um impacto bem menor pois cada n trabalha individualmente. Entretanto, a vantagem que se apresentava numa arquitetura centralizada de no haver ns ociosos a desvantagem apresentada na descentralizada que pode conter computadores parados por um grande tempo por no haver um nico mestre que gerencie o sistema todo, ou seja, essa arquitetura no oferece todo o desempenho possvel.

2.3.3

Cluster de Balanceamento de Carga

Os Clusters de balanceamento de carga Load Balance Clusters (LBC) so um misto de cluster de alto desempenho, com cluster de alta disponibilidade (BECHER, 2007). A funo principal dele :[...] distribuir as requisies feitas aos elementos que o compe, esse cluster mantm de forma equilibrada o trfego gerado a determinados servios, alm de redistribuir as requisies enviadas a determinado n, aos outros ns do cluster, caso este venha a falhar (PINTO; SILVA; SILVEIRA, 2007).

Esse tipo de cluster necessita monitorao constante por meio de mecanismos de redundncia. Se no houver isso, qualquer tipo de falha pode vir a interromper todo o sistema. Ele muito utilizado em servidores de e-mail na Internet, comrcio eletrnico e em

16 sistemas de lojas. A Google utiliza este mtodo em cluster. O balanceamento de carga entre servidores faz parte de uma soluo abrangente em uma explosiva e crescente utilizao da rede e da Internet, provendo um aumento na capacidade da rede, melhorando a performance (PITANGA, 2003, p. 19). O balanceamento de carga se tornou essencial em diversos setores, como o comrcio eletrnico.

2.4

PRINCIPAIS CARACTERSTICAS DE UM CLUSTER

Existem diversas caractersticas de um sistema em cluster. Dentre as principais, temos em destaque os itens abaixo:

2.4.1

Escalabilidade

O cluster possibilita adicionar novos ns para melhorar a performance do sistema, medida que a carga de trabalho aumenta, com a maior facilidade. Uma das caractersticas mais prticas que deve ser adicionada configurao de um cluster (ROCHA, 2004), ou seja, a configurao do sistema deve possibilitar servios ativos, como adicionar perifricos e efetuar conexes internas de rede.

17 2.4.2 Tolerncia a Falhas

O cluster deve apresentar um aumento da confiabilidade do sistema, de forma que se acaso algum n venha a falhar o sistema no fique prejudicado (PINTO; SILVA; SILVEIRA, 2007). O sistema necessita de tcnicas para tolerncia falhas. Esses tipos de tcnicas garantem o funcionamento do cluster e so todas baseadas na redundncia por adio de componentes ou mesmo por algoritmos especiais. Existem duas tcnicas de tolerncia falhas: mascaramento ou deteco, localizao e reconfigurao. Na primeira as falhas no se manifestam como erros, pois so mascaradas na origem. O mascaramento geralmente emprega mais redundncia que a segunda e, por no envolver os tempos gastos para as tarefas de deteco, localizao e reconfigurao, a preferida para sistemas de tempo real crticos (WEBER, [200-?]).

2.4.3

Custo Reduzido

A principal vantagem de um cluster o baixo custo que ela disponibiliza. Isso se deve por utilizar recursos de fcil acesso e de uso comum, como por exemplo, microcomputadores de uso pessoal e mini-hub (OLIVEIRA, 2004). Em relao a custo/desempenho de um cluster, pode se dizer que:[...] devido relativa facilidade em construir o sistema, a partir de elementos ou ns comercialmente disponveis possvel obter um

18cluster com poder de computao igual ou superior a um supercomputador, por exemplo, com custo muito menor (ROCHA, 2004).

2.4.4

Independncia de Fornecedores

Como j foi citado anteriormente, um supercomputador totalmente dependente dos fornecedores caso houver alguma falha no sistema. Isso se deve pelo sistema ser muito complexo e apenas conhecido pela empresa que o desenvolveu. O que no importa no caso do cluster, que por utilizar microcomputadores comuns, que podem ter plataformas heterogneas, no esto presos a uma tecnologia especfica (OLIVEIRA, 2004).

19 3 SOFTWARES DO CLUSTER

Neste captulo esto descritos os softwares utilizados no projeto. Na seo 3.1 ser descrito o sistema operacional utilizado no projeto. O tpico 3.2 descreve o software utilizado para distribuio dos processos e nos tpicos subseqentes as caractersticas de cada ferramenta da aplicao.

3.1

SISTEMA OPERACIONAL

Para escolher o sistema operacional no desenvolvimento do cluster, foi levado em conta o menor custo possvel, pois um dos objetivos da utilizao do mesmo a viabilidade em relao a um supercomputador independente. Desta forma, chegouse a concluso que o melhor sistema operacional a ser utilizado o Linux. Ele, ao contrrio dos sistemas operacionais proprietrios, um software livre que pode ser adquirido de forma gratuita e suporta diversas arquiteturas. O sistema operacional deve atender, alm do custo reduzido: segurana; ser estvel; ter capacidade de trabalhar em sistemas multiusurio e multitarefa; operar sobre variadas arquiteturas de computadores; ter seu cdigo fonte disponvel (ROCHA, 2003). O Linux se encaixa perfeitamente a todas essas exigncias, e alm do mais sua utilizao tem crescido significativamente nos ltimos anos em todo o mundo.

20 3.1.1 Linux

Linux ao mesmo tempo um kernel (ou ncleo) e o sistema operacional que roda sobre ele, dependendo do contexto em que voc encontrar a referncia (CAMPOS, 2006). O linux uma verso gratuita de UNIX desenvolvida inicialmente por um estudante da Universidade de Helsinque (Finlndia), chamado Linus Torvalds (OLIVEIRA, 2004). Ele foi baseado no sistema operacional MINIX, uma verso criada anteriormente por Andrew Tannembaum. Linus Torvalds criou o kernel Linux em 1991, e hoje mantido mundialmente por diversos desenvolvedores, como as empresas IBM e HP, e coordenada pelo prprio Linus (CAMPOS, 2006). Os sistemas operacionais Linux possuem a vantagem de serem livremente distribudos, ou seja, o usurio pode modific-los de acordo com as suas necessidades. Dessa forma, a sua implantao num sistema de clusters tem diversas vantagens, entre elas se destaca por ser um sistema robusto, que d suporte desde aplicao simples at aplicaes extremamente complexas, e tambm por ser possvel dot-lo de caractersticas diferentes facilitando a implementao em aplicaes paralelas (OLIVEIRA, 2004).

3.1.1.1

ClusterKnoppix

O ClusterKnoppix uma distribuio baseada no sistema operacional Knoppix que vem com um servidor OpenMosix, que ser abordado a seguir, configurado para

21 rodar diretamente do CD (MORIMOTO, 2003). Ele foi desenvolvido especialmente para o funcionamento em cluster. Possui um sistema de autodescoberta, o que permite com que os nodos do cluster se integrem automaticamente no ambiente. O ClusterKnoppix j vm com todo o ferramental do OpenMosix pronto para a utilizao (PITANGA, 2003). Essas caractersticas so extremamente teis para desenvolver um cluster, pois no necessrio realizar todo o processo de instalao do sistema operacional e configurao do mesmo, porque o prprio sistema se encarrega de fazer tudo automaticamente, facilitando o trabalho do usurio.

3.2

OPENMOSIX

O projeto Mosix Multicomputer Operating System UnIX um sistema operacional distribudo, desenvolvido originalmente pelos alunos do professor Amnon Barak, na Universidade Hebrew em Jerusalm, Israel (PITANGA, 2003, p. 241). O Mosix permite a construo de um sistema escalvel utilizando componentes genricos e oferecendo alta performance. A sua principal vantagem em relao aos outros sistemas sua capacidade de resposta em relao aos diversos usurios conectados ao sistema (PITANGA, 2003). O cluster Mosix tem a caracterstica de proporcionar o equilbrio entre a carga e as mquinas com o intuito de rodar mais processos do que uma nica UCP, o que beneficia os aplicativos que utilizam vrios processos independentes (PITANGA, 2003).

22 O openMosix uma extenso do projeto Mosix, [...] iniciado em 10 de fevereiro de 2002, [...] para manter os privilgios desta soluo Linux para cluster disponvel com software de cdigo aberto (PITANGA, 2003, p. 242). Todas as instalaes que eram baseadas no Mosix migraram para o openMosix. No openMosix foram acrescidas diversas caractersticas que no continham no projeto Mosix, dentre elas as principais so:

Portado para arquitetura User-mode Linux (UML); Cdigo novo para migrao de processos; Um melhor balanceador de carga; Diminuio da latncia do kernel; Suporte a placas SCI (Dolphin) e arquitetura IA64; Uma grande simplificao da instalao por meio de empacotamento RPM (PITANGA, 2003, p. 242).

Mesmo o openMosix sendo uma extenso do Mosix, os dois so completamente incompatveis, ou seja, se o usurio misturar implementaes do Mosix ao openMosix, o sistema no funcionar.O openMosix uma extenso do ncleo do sistema operacional 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 balanceamento dinmico de carga (PITANGA, 2003, p. 243).

A Migrao Preemptiva de Processos capaz de migrar qualquer processo do usurio, em qualquer instante e para qualquer n disponvel de maneira transparente (PITANGA, 2003, p. 243). Dessa forma, para atingir um melhor desempenho so utilizados algoritmos de balanceamento de carga para responder dinamicamente as variaes que ocorreram durante o processo. Esses algoritmos

23 no possuem um nico controlador (n mestre) e ns escravos. Cada n mestre para os processos locais e escravos para os processos remotos vindos de outros ns do cluster. Assim, pode ser removido ou acrescentado mquinas do mesmo a qualquer momento, com mnimo distrbio do sistema (PITANGA, 2003).No openMosix operaes so totalmente transparentes para as aplicaes, [...] voc no precisa conhecer onde seus processos esto sendo executados, nem se preocupar com que os outros usurios esto fazendo na rede [...] em pouco tempo depois de iniciar os processos, eles so enviados para um melhor computador da rede (PITANGA, 2003, p. 244).

Essa caracterstica interessante, pois ao iniciar um processamento no cluster, o openMosix separa o processamento aos ns de forma equilibrada de acordo com o poder computacional de cada componente, ou seja, o melhor computador receber mais processos, e conforme for sendo adicionados processos, o sistema monitora os novos processos e os movimenta pelos computadores com pouca carga de trabalho. Infelizmente o projeto do openMosix foi abandonado devido a alguns fatores, dentre eles: falta de estmulo para continuar o projeto; acreditar que processadores com mltiplos ncleos so o futuro da supercomputao e tornar obsoleto o processo clustering diz Moshe Bar (fundador e lder do projeto openMosix); no acreditar mais no conceito de cluster puramente SSI Imagem nica do Sistema (ULBRICH, 2007).

3.2.1

Algoritmos de Compartilhamento de Recursos

Nos sub-tpicos a seguir so apresentados os algoritmos que realizam o

24 compartilhamento dos recursos.

3.2.1.1

Balanceamento Dinmico de Carga

O algoritmo de balanceamento de carga tenta reduzir a diferena de carga entre pares de ns, migrando os processos de um n muito sobrecarregado para um n com mais recursos disponveis no cluster (PITANGA, 2003, p. 248). Este algoritmo descentralizado, ou seja, cada membro do cluster executa o mesmo algoritmo, onde cada par de nodos tenta diminuir as diferenas de processamentos existentes entre eles de forma totalmente independente e transparente (PITANGA, 2003). O nmero de processadores e a velocidade de cada n so importantes para o perfeito funcionamento deste algoritmo e so as opes principais para o compartilhamento de recursos (PITANGA, 2003, p. 248). Este algoritmo executa o balanceamento de carga atravs das informaes enviadas pelos nodos sobre os processos que esto em tempo de execuo, ou seja, os nodos enviam as suas informaes a cada 1 segundo sobre a memria livre, utilizao, velocidade, carga de CPU e a tabela de processos livres/abertos (PITANGA, 2003). Exemplificando, se o sistema possuir um Pentium 2 e um Pentium 4, o algoritmo descentralizado quem divulga a capacidade de memria e uso de CPU entre os nodos que participam do cluster, dessa maneira revelando que o Pentium 4 melhor do que o Pentium 2.

3.2.1.2

Algoritmo de Anunciao de Memria

25 Esse algoritmo usado para evitar o total esgotamento da memria. Seu objetivo tentar ocupar toda a memria do cluster se possvel, evitando assim que ocorram paginaes ou utilizao da memria virtual (PITANGA, 2003, p. 248). Esse algoritmo entra em ao quando ocorre muita paginao devido falta de memria. Dessa forma, o processo que est ocasionando a falta de memria migra para outro componente do cluster que possua memria livre, independentemente de vir a ocorrer desbalanceamento de carga (PITANGA, 2003). Devido a esse problema de limitao de processos em determinados nodos, o openMosix elaborou um novo algoritmo no qual ele seleciona em qual dos nodos o processo pode executar (PITANGA, 2003).O modelo matemtico baseado em um algoritmo de escalonamento onde a lgica baseada na teoria da economia de mercado, que determina um comparativo de preos para cada recurso. [...] O novo algoritmo implementado no openMosix bem interessante porque [...] baseado em princpios da economia e anlise de competitividade (PITANGA, 2003, p. 248).

A idia chave converter o uso total dos diversos recursos heterogneos (computadores com configuraes de hardware diferentes) em um custo homogneo (semelhante), dirigindo os processos ento para o local onde possui um menor custo (PITANGA, 2003).

3.2.2

Migrao Preemptiva de Processos

A Migrao Preemptiva de Processos tem a capacidade de migrar qualquer

26 processo, a qualquer instante, para qualquer n do cluster. [...] Cada processo tem [...] a sua mquina na qual o processo foi criado (PITANGA, 2003, p. 249). Cada processo pensa que est rodando na sua mquina local e todos os processos compartilham o ambiente. 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 da mquina em que o processo foi criado (PITANGA, 2003).

3.2.3

OpenMosixVIEW

Figura 1: Logotipo do OpenMosixview

O OpenMosixview um gerenciador grfico [...]. Com essa aplicao possvel gerenciar e ajustar os principais parmetros do cluster como visualizao da carga de todos os ns do cluster, visualizao de processos remotos em outros ns, executar ou transferir processos para outros computadores que compem o cluster (PITANGA, 2003, p. 265).

Ele um conjunto de ferramentas que tem a funo de administrar e monitorar o cluster OpenMosix.

3.2.3.1

OpenMosixview

27 A principal aplicao de administrao/monitoramento do openMosix (PITANGA, 2003). Ele permite a visualizao de desempenho do cluster. Todas as partes so acessveis pela janela principal da aplicao, todos os comandos do openMosix podem ser executados pelo simples clicar do mouse (PITANGA, 2003, p. 266). O openMosixview uma interface grfica simples de se manusear, composto por painis, barras de progresso, botes e nomes para cada n do cluster.

3.2.3.2

OpenMosixprocs

Um box para gerenciamento de processos existentes no cluster (PITANGA, 2003, p. 266). Ele mostra quais os processos que migraram e para onde foram, entre outros dados.

3.2.3.3

OpenMosixcollector

Coleta informaes dos ns do cluster atravs de um processo daemons para gerao de logs do sistema (PITANGA, 2003, p. 266). O openMosixcollector utilizado pelo analisador de logs denominado openMosixAnalyzer, que faz uma avaliao ininterrupta da carga, memria e processos do cluster (PITANGA, 2003, p. 274). Reinicia a cada 12 horas e salva o histrico do sistema.

3.2.3.4

OpenMosixanalyzer

Utilizado para a anlise dos dados coletados pelo openMosixcollector (PITANGA, 2003, p. 266). Ela demonstra, por meio de grficos estatsticos, um histrico da

28 operacionalidade do nosso cluster.

3.2.3.5

OpenMosixhistory

Histrico dos processos no nosso cluster (PITANGA, 2003, p. 266). Ele possui a capacidade de listar um conjunto de processos executados anteriormente (PITANGA, 2003).

3.2.3.6

OpenMosixmigmon

Usado para monitoramento de processos migrados (PITANGA, 2003, p. 266). O openMosixmigmon um monitor para migraes efetuadas pelo seu cluster openMosix (PITANGA, 2003, p. 277).

29 4 PLANEJAMENTO E REQUISITOS

Na seo 4.1 define-se o planejamento de uma topologia a ser implantada no sistema. Na seo 4.2 aborda-se sobre os requisitos de hardware. O tpico 4.3 apresenta os requisitos de software.

4.1

PLANEJAMENTO DO SISTEMA

Um cluster requer no mnimo 2 mquinas conectadas em rede de interconexo, via cabo cross-over, hub ou switch. Dessa forma, foi optado pela utilizao de um switch por oferecer melhor performance ao sistema. Antes de comear a realizar as configuraes do cluster, planeja-se quantos nodos que o sistema obter. Para comprovar a eficincia do cluster openMosix e obter um alto poder de processamento, decidiu-se utilizar 9 computadores e 1 switch para interlig-los, conforme segue a figura a seguir realizada no Packet Tracer.

30

Figura 2: Topologia do cluster

O ambiente a ser desenvolvido o cluster essencial para o correto funcionamento do mesmo. Se o sistema possuir muitas mquinas, a garagem de uma casa no seria a melhor opo para o desenvolvimento do mesmo. Ento necessrio um local onde tenha um bom suporte ar-condicionado, por exemplo, para manter a temperatura ideal e constante.

31 4.2 REQUISITOS DE HARDWARE

O SENAI de Jaragu do Sul disponibilizou o laboratrio B216, onde foram utilizados 8 microcomputadores com processador Intel Celeron; 2.4 Ghz; 1GB de memria RAM e 1 microcomputador com processador Intel Celeron; 2.4 Ghz; 512 MB de memria RAM. Placas de rede devidamente configuradas. Tambm se utilizou 1 switch Cisco Catalyst 2950.

4.3

REQUISITOS DE SOFTWARE

O sistema em questo necessita de um CD de instalao do sistema operacional clusterKnoppix 3.6, que contm o kernel 2.4.27 e a ferramenta openMosix j integrada ao sistema.

32 5 CONFIGURAO DO CLUSTER

A configurao do cluster se divide em 2 etapas: instalao do sistema operacional nos membros do cluster e as ferramentas do openMosix. A seguir esto dispostas as configuraes do mesmo.

5.1

INSTALAO DO SISTEMA OPERACIONAL

Inicialmente insere-se o CD de instalao do ClusterKnoppix 3.6 na unidade de CDROM e reinicia-se o computador. Ao iniciar, se pressiona a tecla enter para iniciar o processo de inicializao automtica do Linux. Repete-se os mesmos procedimentos nos demais computadores. Nesse instante, o ClusterKnoppix j est com o openMosix ativo e, ao mesmo tempo, j reconheceu automaticamente os nodos interligados via rede a ele. A seguir, apresenta-se a imagem que caracteriza a rea de trabalho do sistema operacional ClusterKnoppix.

33

Figura 3: rea de Trabalho: ClusterKnoppix

5.2

FERRAMENTAS DO OPENMOSIX

Ao instalar o sistema operacional ClusterKnoppix aos membros do cluster, j possvel manusear as ferramentas do openMosix que administram o mesmo. O openMosix disponibiliza interfaces grficas para a realizao desses processos, dessa forma no necessrio realizar a administrao atravs de linhas de comando, tornando o sistema mais fcil e intuitivo. Nos sub-tpicos a seguir,

34 apresentam-se as principais ferramentas grficas do openMosix e suas funes.

5.2.1

OpenMosixview Viso do openMosix

Como citado anteriormente, essa a principal ferramenta grfica do openMosix. Para inici-la, seleciona-se a opo openMosixview (como exibe a figura 3), apresentada na barra de ferramentas do sistema operacional ou atravs da console do ClusterKnoppix, executando o seguinte comando:openmosixview

Quadro 1: Comando para ativao da ferramenta principal

A partir deste momento a interface grfica do openMosixview ser aberta e o usurio j pode observar os membros do cluster em funcionamento, como exibido na figura 4.

Figura 4: Tela Inicial do OpenMosixview

35 Como pode ser observado claramente na figura 4, todos os 9 membros, como citado no planejamento, do cluster se encontram na aplicao. A primeira coluna da aplicao apresenta o ID de cada componente do mesmo. A luz em plano de fundo indica o estado em que se encontra o nodo, se estiver verde significa que o n est operativo, entretanto se a luz for vermelha, o n est com alguma falha ou j foi desligado. A segunda coluna exibe os endereos IP configurados em cada componente. Ao clicar sobre um dos botes que mostram o IP, uma tela de configurao de dilogo do componente aparecer, como mostra a figura 5. Na seo 4.4.4.2, se explica a utilidade desta janela. Retornando a aplicao principal, a terceira coluna apresenta uma barra de progresso chamada load-balancing efficiency, que um indicador da eficincia do algoritmo de balanceamento de carga no sistema, ou seja, se o valor estiver prximo a 100% indica que a carga computacional est dividida equivalentemente entre todos os membros do cluster. Na mesma coluna, se observa um boto deslizante para cada componente. Nele pode ser estabelecida a velocidade que o cluster considerar para cada nodo do mesmo. Ao lado da barra de balanceamento de carga, mostrada numericamente, em um painel no formato LCD, a velocidade atual do n. Ao lado apresentam-se as barras de overall load que exibem o estado geral da carga em cada n membro do cluster. Ela designada para a carga do processador e mostra uma porcentagem aproximada em cada n e mais acima da carga global. A prxima barra de progressos, denominada overall used memory, projetada para demonstrar em porcentagem - a memria utilizada em cada nodo. A barra

36 que contm o ID all apresenta o uso de memria global de acordo com a memria disponvel dos hosts. No canto direito da aplicao, existem 2 boxes. O primeiro, denominado all memory, exibe o nmero total, em megabytes, de memria que o cluster possui e a memria que cada membro disponibiliza. O segundo, denominado all cpu, mostra o nmero de nodos que o cluster possui.

5.2.2

OpenMosix-configuration Janela de Configurao

Como abordado anteriormente, ao clicar em algum boto que exibe o nmero IP do host, uma nova tela ser apresentada, e nela podem ser modificadas facilmente as configuraes do mesmo, onde todos os comandos executados nos hosts remotos so via ssh ou rsh. A figura 5 apresenta a janela de configurao.

37

Figura 5: Janela de Configurao Como pode ser observado na primeira linha da interface, o box apresenta o endereo IP selecionado. Neste caso foram selecionados todos os nodos do cluster, com o intuito de acelerar a configurao do mesmo, pois a configurao semelhante em todos os membros do sistema. Para isso pressiona-se na interface principal do openMosixview o boto all-nodes. A segunda linha, denominada automigration, apresenta dois botes on e off que tem a finalidade de autorizar a migrao automtica dos processos, ou seja, se o boto on estiver pressionado os nodos deixam seus processos serem migrados a outros nodos de forma automtica. Neste caso, deixa-se a opo on ativada. A seguir apresentada a opo talk to other nodes que tem a funo de conversar com os outros membros do cluster. Assim, habilita-se essa opo clicando em yes. A prxima linha exibe o local procs stay, ou seja, pergunta se os processos locais devem permanecer na mquina selecionada. Seleciona-se no neste momento para que os processos locais sejam

38 migrados aos demais nodos. A linha seguinte, denominada send away guest procs, interroga se os processos vindos de outro membro devem ser mandados embora. Nessa linha escolhe-se a opo no novamente. A seguir pressiona-se start para ativar as opes anteriores e aperta-se apply para aplic-las. Selecionando a opo remote-proc box, ser aberto o openMosixprocs remoto onde podem ser gerenciados os programas.

5.2.3

OpenMosixmigmon Monitor de Migraes

O openMosixmigmon uma ferramenta muito til para monitorar as migraes do sistema. Para inici-la seleciona-se a opo openMosixmigmon na interface do openMosixview ou atravs da console do ClusterKnoppix executa-se o seguinte comando:openmosixmigmon

Quadro 2: Comando para ativao do openMosixmigmon

Por conseguinte, a interface do openMosixmigmon ser exibida, conforme demonstra a figura 6.

39

Figura 6: OpenMosixmigmon

Como pode ser observado na figura 6, o openMosixmigmon mostra cada n do cluster com um pingim e o ID do mesmo. Os nodos que esto participando da migrao de processos so envoltos por um crculo, em que cada circunferncia corresponde a um nodo.

40 O crculo central corresponde ao n que est executando e cada quadrado preto envolta dele corresponde a um processo. O processo que migra para outro nodo apresenta colorao verde. Pode ser observada a origem do processo at a mquina que est executando o mesmo atravs de uma linha pontilhada saindo do crculo central e indo parar no crculo do host de destino. Se passar o mouse por cima de um processo, este mostra o seu PID com o processo que est sendo executado. O programa disponibiliza a filosofia arrastar e soltar, ou seja, o usurio pode movimentar um processo de um nodo a outro com o simples movimento do mouse.

5.2.4

OpenMosixprocs Gerenciador de Processos

O openMosixprocs uma ferramenta de grande utilidade, pois ela que gerencia os PIDs (Processos Unificados) dos ns do cluster e possibilita o usurio a verificar os mesmos. Existem duas possibilidades de abrir a interface do gerenciador de processos: uma atravs da tela do openMosixview; a outra atravs da console executando o seguinte comando:openmosixprocs

Quadro 3: Comando para ativao do openMosixprocs

Nesse instante, a janela do openMosixprocs ser acionada, como pode ser observada na figura 7.

41

Figura 7: OpenMosixprocs

Como exibido na figura 7, a coluna nomeada pid exibe os processos que esto em execuo. Os processos que foram migrados esto simbolizados com a cor verde, j os processos que no podem ser migrados so identificados com um cone de fechadura. A segunda coluna, denominada n#, apresenta o nodo que est

42 executando o processo. Se estiver estabelecido o nmero 0, o processo local, entretanto se estiver com qualquer outro valor os processos so remotos. A caixa de seleo bem ao topo da janela, cujo nome processes, tem a funo de determinar os processos a serem exibidos, por exemplo, se estiver selecionado all todos os processos na mquina sero listados. O boto denominado manage procs from remote, ao ser selecionado, exibe uma nova janela informando todos os processos atualmente migrados para o host local vindos de outros membros do cluster. A figura 8 exibe o gerenciador de processos remotos

Figura 8: Gerenciados de Processos Remotos

Como pode ser observados na figura 8, os processos so divididos por abas. Selecionado uma delas, apresentado o nodo pertencente a ela e seu IP. O boto goto home node ao ser clicado, direciona o processo ao host de origem. O segundo boto denominado goto best node, movimenta o processo para o melhor

43 nodo componente do cluster. Retornando ao openMosixprocs, se o usurio clicar duas vezes sobre um dos processos do mesmo, uma nova janela ser exibida identificada como janela de migrao, como pode ser observada na figura 9.

Figura 9: Janela de Migrao

A janela de migrao exibe todos os ns componentes do cluster. No canto direito existem diversos botes com suas determinadas funes. O boto denominado home, direciona o processo ao host de origem do mesmo. O boto chamado best encaminha o processo ao melhor nodo do cluster. O lock tem a funo de trancar

44 o processo, e para desativ-lo simplesmente pressiona-se o unlock. Pressionando pidlog, uma nova janela exibida com os dados do processo. Os botes sigstop e sigcont param por certo momento o processo e o reinicia, respectivamente. Selecionando kill, o processo ser excludo do renice process possvel alterar a prioridade do processo movendo o boto deslizante, se moviment-lo negativamente o processo obter maior prioridade, todavia se modificar o boto positivamente o processo apresentar menor prioridade.

5.2.5

OpenMosixcollector

Esta ferramenta tem a funo de criar o log com a carga de cada componente do cluster e iniciada automaticamente no ClusterKnoppix. Esse log utilizado pelo openMosixanalyzer que elabora um grfico atravs deles. Ele reinicia

automaticamente a cada 12 horas e salva os seus histricos que automaticamente so finalizados, e talvez no futuro possam ser utilizados.

5.2.6

OpenMosixanalyzer

O openMosixanalyzer elabora um grfico de acordo com os logs capturados do openMosixcollector. Ele pode ser acionado atravs da interface do openMosxview, como tambm pela console atravs do comando:

45openmosixanalyzer

Quadro 4: Comando para ativao do openMosixanalyzer

Ao ser acionado o comando, uma nova janela ser exibida demonstrando o grfico elaborado. A figura 10 apresenta o openMosixanalyzer.

Figura 10: OpenMosixanalyzer

Como pode ser analisado na figura 10, o openMosixanalyzer elabora um grfico da avaliao de carga de cada n e de todos em conjunto. Clicando duas vezes sobre um dos grficos, uma nova janela exibida divulgando uma estatstica sobre cada

46 n do cluster conforme segue a figura 11.

Figura 11: OpenMosixanalyzer: estatstica dos nodos

5.2.7

OpenMosixhistory

O

openMosixhistory

registra

todos

os

processos

que

foram

executados

anteriormente. Ele pode ser executado atravs da console do ClusterKnoppix pelo seguinte comando:openmosixhistory

Quadro 5: Comando para ativao do openMosixhistory

Nesse instante, a interface do openMosixhistory ser aberta conforme segue a figura 12.

47

Figura 12: OpenMosixhistory

A interface do openMosixhistory apresenta no canto superior um box, cujo nome time, onde apresenta-se o tempo em que foi executado o processo exibido na tela. Para exibir outros processos, foi projetada a barra deslizante que apresenta os mesmos com seus tempos.

48 6 COMUNICAO

Para ter a certeza de que todas as mquinas esto em funcionamento e se comunicando, foi realizado um pequeno teste para ver os processos sendo migrados de forma automtica. Primeiramente foi criado um pequeno script em bash que gera nmeros at 10000. O comando elaborado foi o seguinte:awk 'BEGIN {for (i=0;i