SERVO NACONAL DE APRENDZAGEM NDUSTRAL

CURSO TCNCO EM REDES DE COMPUTADORES

TAGO RAFAEL PERN
PROCESSAMENTO DISTRIBUDO
JARAGU DO SUL
2008
TAGO RAFAEL PERN
PROCESSAMENTO DISTRIBUDO
Trabalho apresentado banca
examinadora de TCC do curso Tcnico
em Redes de Computadores do
SENA/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 nicial 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 OBJETVO GERAL............................................................................................8
1.2 OBJETVOS ESPECFCOS..............................................................................8
1.3 JUSTFCATVA..................................................................................................8
1.4 METODOLOGA.................................................................................................9
2 CONCEITOS DO CLUSTER...................................................................................11
2.1 HSTRA.........................................................................................................11
2.2 DEFNO......................................................................................................12
2.3 TPOS DE CLUSTER.......................................................................................13
2.3.1 Clus!" #! Al$ D%s&'(%)%l%#$#!.............................................................13
2.3.2 Clus!" #! Al' D!s!*&!(+'.................................................................1,
2.3.3 Clus!" #! B$l$(-!$*!(' #! C$".$....................................................1/
2.4 PRNCPAS CARACTERSTCAS DE UM CLUSTER...................................16
2.,.1 Es-$l$)%l%#$#!.........................................................................................10
2.,.2 T'l!"1(-%$ $ F$l+$s.................................................................................17
2.,.3 Cus' R!#u2%#'.......................................................................................17
2.,., I(#!&!(#3(-%$ #! F'"(!-!#'"!s..........................................................14
3 SOFT5ARES DO CLUSTER.................................................................................16
3.1 SSTEMA OPERACONAL...............................................................................19
3.1.1 L%(u7.........................................................................................................28
3.1.1.1 ClusterKnoppix..................................................................................20
3.2 OPENMOSX....................................................................................................21
3.2.1 Al.'"%*'s #! C'*&$"%l+$*!(' #! R!-u"s's..................................23
3.2.1.1 Balanceamento Dinmico de Carga.................................................24
3.2.1.2 Algoritmo de Anunciao de Memria...............................................24
3.2.2 M%."$9:' P"!!*&%;$ #! P"'-!ss's.....................................................2/
3.2.3 O&!(M's%7<IE5.....................................................................................20
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
, PLANE=AMENTO E REQUISITOS........................................................................26
4.1 PLANEJAMENTO DO SSTEMA.....................................................................29
4.2 REQUSTOS DE HARDWARE.......................................................................31
4.3 REQUSTOS DE SOFTWARE........................................................................31
/ CONFIGURAO DO CLUSTER..........................................................................32
5.1 NSTALAO DO SSTEMA OPERACONAL................................................32
5.2 FERRAMENTAS DO OPENMOSX.................................................................33
/.2.1 O&!(M's%7;%!> ? <%s:' #' '&!(M's%7................................................3,
/.2.2 O&!(M's%7@-'(A%.u"$%'( ? =$(!l$ #! C'(A%.u"$9:' ........................30
/.2.3 O&!(M's%7*%.*'( ? M'(%'" #! M%."$9B!s.......................................34
/.2., O&!(M's%7&"'-s ? G!"!(-%$#'" #! P"'-!ss's...................................,8
/.2./ O&!(M's%7-'ll!-'"...............................................................................,,
/.2.0 O&!(M's%7$($lC2!"................................................................................,,
/.2.7 O&!(M's%7+%s'"C..................................................................................,0
0 COMUNICAO.....................................................................................................,4
7 TESTANDO A APLICAO NO OPENMOSID....................................................../1
7.1 APLCAO UTLZADA.................................................................................51
7.2 RESULTADOS DAS COMPARAES............................................................53
7.2.1 R!(#!"%2$9:' -'* (E*!"' %.u$%s #! &"'-!ss's ! ('#'s................/3
7.2.2 R!(#!"%2$9:' !* 6 ('#'s -'* (E*!"' #! &"'-!ss's #%A!"!(!s..../6
7.3 PONTOS DE FALHA........................................................................................63
4 CONCLUSO.........................................................................................................00
REFERFNCIAS...........................................................................................................07
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. sto 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. sto 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 OBJETVO GERAL
mplantar um cluster de balanceamento de carga, utilizando sistema operacional
ClusterKnoppix 3.6.
1.2 OBJETVOS ESPECFCOS
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 JUSTFCATVA
Empresas de pequeno e mdio porte, ou at mesmo usurios domsticos,
9
necessitam de computadores que ofeream desempenho elevado para executar os
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 METODOLOGA
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 SENA/Jaragu do Sul e, se necessrio,
mais pesquisas para obter as solues para resoluo dos possveis problemas que
10
possam ocorrer nos testes efetivados. Abaixo segue o cronograma das datas e
procedimentos a serem cumpridos.
A%;%#$#!s M!s!s Jul Ago Set Out Nov Dez
Qu%(2!($s 1 2 1 2 1 2 1 2 1 2 1 2
Definio do Tema X
Formulrio de Acompanhamento X X
Avaliao do Formulrio
-realizada pelo orientador
X
Levantamento Bibliogrfico X X X X X
Produo do Pr-Projeto em
relao ao formulrio
X X
Entrega e avaliao do pr-
projeto
X
Produo do TCC em relao ao
pr-projeto
X X X
mplementao do sistema X X
Testes X X X
Pesquisas para solucionar
problemas nos testes
X X X
Entrega e avaliao da verso
Parcial do TCC
X
Produo do TCC em relao
verso parcial
X X X X
Entrega da verso final do TCC X
Apresentao do TCC para a
banca examinadora
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 HSTRA
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/P (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 harware comum e foi apelidado de ARPAN!T. 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 ARCN!T (BECHER, 2007),
que permitia a ligao de mquinas em rede por meio de harware, aplicativo e
outros equipamentos.
2.2 DEFNO
Tambm chamado de Clusterin",
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. (ALECRM, 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 (OLVERA,
2004), ou seja, um computador ser configurado como o n mestre com a funo de
dividir o processamento para cada computador escravo.
2.3 TPOS 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 Clus!" #! Al$ D%s&'(%)%l%#$#!
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 (PNTO; SLVA; SLVERA, 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% (PERERA,
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 Clus!" #! Al' D!s!*&!(+'
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 (PERERA, 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 Clus!" #! B$l$(-!$*!(' #! C$".$
"Os Clusters de balanceamento de carga #oa $alance 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
(PNTO; SLVA; SLVERA, 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 nternet, comrcio eletrnico e em
16
sistemas de lojas. A %oo"le 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 nternet, provendo um
aumento na capacidade da rede, melhorando a performance (PTANGA, 2003, p.
19). O balanceamento de carga se tornou essencial em diversos setores, como o
comrcio eletrnico.
2.4 PRNCPAS CARACTERSTCAS DE UM CLUSTER
Existem diversas caractersticas de um sistema em cluster. Dentre as principais,
temos em destaque os itens abaixo:
2.,.1 Es-$l$)%l%#$#!
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.,.2 T'l!"1(-%$ $ F$l+$s
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 (PNTO; SLVA;
SLVERA, 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.,.3 Cus' R!#u2%#'
A principal vantagem de um cluster o baixo custo que ela disponibiliza. sso se
deve por utilizar recursos de fcil acesso e de uso comum, como por exemplo,
microcomputadores de uso pessoal e mini-hub (OLVERA, 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
18
cluster com poder de computao igual ou superior a um
supercomputador, por exemplo, com custo muito menor (ROCHA,
2004).
2.,., I(#!&!(#3(-%$ #! F'"(!-!#'"!s
Como j foi citado anteriormente, um supercomputador totalmente dependente dos
fornecedores caso houver alguma falha no sistema. sso 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
(OLVERA, 2004).
19
3 SOFT5ARES 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 SSTEMA OPERACONAL
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, chegou-
se 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 L%(u7
"Linux ao mesmo tempo um &ernel (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 UNX desenvolvida inicialmente por um
estudante da Universidade de Helsinque (Finlndia), chamado Linus Torvalds
(OLVERA, 2004). Ele foi baseado no sistema operacional MNX, uma verso
criada anteriormente por Andrew Tannembaum.
Linus Torvalds criou o &ernel Linux em 1991, e hoje mantido mundialmente por
diversos desenvolvedores, como as empresas BM 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 (OLVERA, 2004).
'()()() ClusterKnoppix
O ClusterKnoppix uma distribuio baseada no sistema operacional Knoppix que
vem com um servidor *penMosix, que ser abordado a seguir, configurado para
21
rodar diretamente do CD (MORMOTO, 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 *penMosix pronto para a
utilizao (PTANGA, 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 OPENMOSX
"O projeto Mosix Multicomputer Operating System UnX um sistema
operacional distribudo, desenvolvido originalmente pelos alunos do professor
Amnon Barak, na Universidade Hebrew em Jerusalm, srael (PTANGA, 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 (PTANGA, 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 (PTANGA,
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 (PTANGA, 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 +ser,moe Linux (UML);
Cdigo novo para migrao de processos;
Um melhor balanceador de carga;
Diminuio da latncia do &ernel;
Suporte a placas SC (Dolphin) e arquitetura A64;
Uma grande simplificao da instalao por meio de empacotamento RPM
(PTANGA, 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 (PTANGA, 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 (PTANGA, 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 (PTANGA, 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 (PTANGA, 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.
nfelizmente 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
clusterin"- diz Moshe Bar (fundador e lder do projeto openMosix). no acreditar
mais no conceito de cluster puramente SS magem nica do Sistema (ULBRCH,
2007).
3.2.1 Al.'"%*'s #! C'*&$"%l+$*!(' #! R!-u"s's
Nos sub-tpicos a seguir so apresentados os algoritmos que realizam o
24
compartilhamento dos recursos.
'(/()() $alanceamento Din0mico e Car"a
"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 (PTANGA, 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 (PTANGA, 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 (PTANGA, 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 (PTANGA, 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.
'(/()(/ Al"oritmo e Anuncia12o e Mem3ria
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 (PTANGA, 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 (PTANGA, 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 (PTANGA, 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
(PTANGA, 2003, p. 248).
A idia chave converter o uso total dos diversos recursos heterogneos
(computadores com configuraes de harware diferentes) em um custo homogneo
(semelhante), dirigindo os processos ento para o local onde possui um menor custo
(PTANGA, 2003).
3.2.2 M%."$9:' P"!!*&%;$ #! P"'-!ss's
"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 (PTANGA, 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 (PTANGA,
2003).
3.2.3 O&!(M's%7<IE5
O *penMosix4iew 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
(PTANGA, 2003, p. 265).
Ele um conjunto de ferramentas que tem a funo de administrar e monitorar o
cluster *penMosix.
'(/('() *penMosix4iew
Figura 1: Logotipo do OpenMosixview
27
A principal aplicao de administrao/monitoramento do openMosix (PTANGA,
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 (PTANGA, 2003, p. 266). O
openMosix4iew uma interface grfica simples de se manusear, composto por
painis, barras de progresso, botes e nomes para cada n do cluster.
'(/('(/ *penMosixprocs
"Um box para gerenciamento de processos existentes no cluster (PTANGA, 2003,
p. 266). Ele mostra quais os processos que migraram e para onde foram, entre
outros dados.
'(/('(' *penMosixcollector
"Coleta informaes dos ns do cluster atravs de um processo aemons para
gerao de lo"s do sistema (PTANGA, 2003, p. 266). O openMosixcollector "
utilizado pelo analisador de logs denominado openMosixAnal56er, que faz uma
avaliao ininterrupta da carga, memria e processos do cluster (PTANGA, 2003,
p. 274). Reinicia a cada 12 horas e salva o histrico do sistema.
'(/('(7 *penMosixanal56er
"Utilizado para a anlise dos dados coletados pelo openMosixcollector (PTANGA,
2003, p. 266). Ela demonstra, por meio de grficos estatsticos, um histrico da
28
operacionalidade do nosso cluster.
'(/('(8 *penMosixhistor5
"Histrico dos processos no nosso cluster (PTANGA, 2003, p. 266). Ele possui a
capacidade de listar um conjunto de processos executados anteriormente
(PTANGA, 2003).
'(/('(9 *penMosixmi"mon
"Usado para monitoramento de processos migrados (PTANGA, 2003, p. 266). O
openMosixmi"mon "um monitor para migraes efetuadas pelo seu cluster
openMosix (PTANGA, 2003, p. 277).
29
, PLANE=AMENTO 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 harware. O tpico 4.3
apresenta os requisitos de software.
4.1 PLANEJAMENTO DO SSTEMA
Um cluster requer no mnimo 2 mquinas conectadas em rede de interconexo, via
cabo cross,o4er, 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 Pac&et Tracer.
30
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.
Figura 2: Topologia do cluster
31
4.2 REQUSTOS DE HARDWARE
O SENA de Jaragu do Sul disponibilizou o laboratrio B216, onde foram utilizados
8 microcomputadores com processador ntel Celeron; 2.4 Ghz; 1GB de memria
RAM e 1 microcomputador com processador ntel Celeron; 2.4 Ghz; 512 MB de
memria RAM. Placas de rede devidamente configuradas. Tambm se utilizou 1
switch Cisco Catalyst 2950.
4.3 REQUSTOS DE SOFTWARE
O sistema em questo necessita de um CD de instalao do sistema operacional
clusterKnoppix 3.6, que contm o &ernel 2.4.27 e a ferramenta openMosix j
integrada ao sistema.
32
/ 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 NSTALAO DO SSTEMA OPERACONAL
nicialmente insere-se o CD de instalao do ClusterKnoppix 3.6 na unidade de CD-
ROM 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
5.2 FERRAMENTAS DO OPENMOSX
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,
Figura 3: rea de Trabalho: ClusterKnoppix
34
apresentam-se as principais ferramentas grficas do openMosix e suas funes.
/.2.1 O&!(M's%7;%!> ? <%s:' #' '&!(M's%7
Como citado anteriormente, essa a principal ferramenta grfica do openMosix.
Para inici-la, seleciona-se a opo openMosix4iew (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 openMosix4iew ser aberta e o usurio
j pode observar os membros do cluster em funcionamento, como exibido na figura
4.
Figura 4: Tela nicial 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 D 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 P configurados em cada componente. Ao
clicar sobre um dos botes que mostram o P, 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 :loa,balancin" efficienc5-, 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 "o4erall loa 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 :o4erall use memor5-, projetada
para demonstrar em porcentagem - a memria utilizada em cada nodo. A barra
36
que contm o D 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
memor5-, exibe o nmero total, em me"ab5tes, 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.
/.2.2 O&!(M's%7@-'(A%.u"$%'( ? =$(!l$ #! C'(A%.u"$9:'
Como abordado anteriormente, ao clicar em algum boto que exibe o nmero P 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
Como pode ser observado na primeira linha da interface, o box apresenta o
endereo P 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 openMosix4iew o boto :all,noes-. A segunda linha, denominada :auto,
mi"ration-, 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 :tal& to
other noes- que tem a funo de conversar com os outros membros do cluster.
Assim, habilita-se essa opo clicando em :5es-. A prxima linha exibe o :local procs
sta5-, ou seja, pergunta se os processos locais devem permanecer na mquina
selecionada. Seleciona-se :no- neste momento para que os processos locais sejam
Figura 5: Janela de Configurao
38
migrados aos demais nodos. A linha seguinte, denominada :sen awa5 "uest 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 "appl5- para aplic-las. Selecionando a
opo :remote,proc box-, ser aberto o openMosixprocs remoto onde podem ser
gerenciados os programas.
/.2.3 O&!(M's%7*%.*'( ? M'(%'" #! M%."$9B!s
O openMosixmi"mon uma ferramenta muito til para monitorar as migraes do
sistema. Para inici-la seleciona-se a opo openMosixmi"mon na interface do
openMosix4iew ou atravs da console do ClusterKnoppix executa-se o seguinte
comando:
openmosixmigmon
Quadro 2: Comando para ativao do openMosixmigmon
Por conseguinte, a interface do openMosixmi"mon ser exibida, conforme
demonstra a figura 6.
39
Como pode ser observado na figura 6, o openMosixmi"mon mostra cada n do
cluster com um pingim e o D do mesmo. Os nodos que esto participando da
migrao de processos so envoltos por um crculo, em que cada circunferncia
corresponde a um nodo.
Figura 6: OpenMosixmigmon
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 PD 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.
/.2., O&!(M's%7&"'-s ? G!"!(-%$#'" #! P"'-!ss's
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 openMosix4iew; 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
Como exibido na figura 7, a coluna nomeada :pi- 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
Figura 7: OpenMosixprocs
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 :mana"e 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
Como pode ser observados na figura 8, os processos so divididos por abas.
Selecionado uma delas, apresentado o nodo pertencente a ela e seu P. O boto
:"oto home noe- ao ser clicado, direciona o processo ao host de origem. O
segundo boto denominado :"oto best noe-, movimenta o processo para o melhor
Figura 8: Gerenciados de Processos Remotos
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.
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 :loc&- tem a funo de "trancar
Figura 9: Janela de Migrao
44
o processo, e para desativ-lo simplesmente pressiona-se o :unloc&-( Pressionando
:pilo"-, uma nova janela exibida com os dados do processo. Os botes :si"stop-
e :si"cont- param por certo momento o processo e o reinicia, respectivamente.
Selecionando :&ill-, 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.
/.2./ O&!(M's%7-'ll!-'"
Esta ferramenta tem a funo de criar o lo" com a carga de cada componente do
cluster e iniciada automaticamente no ClusterKnoppix( Esse lo" utilizado pelo
openMosixanal56er 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.
/.2.0 O&!(M's%7$($lC2!"
O openMosixanal56er elabora um grfico de acordo com os lo"s capturados do
openMosixcollector( Ele pode ser acionado atravs da interface do openMosx4iew,
como tambm pela console atravs do comando:
45
openmosixanalyzer
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 openMosixanal56er(
Como pode ser analisado na figura 10, o openMosixanal56er 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
Figura 10: OpenMosixanalyzer
46
n do cluster conforme segue a figura 11.
/.2.7 O&!(M's%7+%s'"C
O openMosixhistor5 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 openMosixhistor5 ser aberta conforme segue a figura
12.
Figura 11: OpenMosixanalyzer: estatstica dos nodos
47
A interface do openMosixhistor5 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.
Figura 12: OpenMosixhistory
48
0 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=!i"#!i$$% for (&=!&"#!&$$%!''
Quadro 6: Script de teste de comunicao
Em seguida, aps ativar-se a permisso de execuo do arquivo, executam-se
vrias instncias do programa atravs do comando:
()teste(sh *
Quadro 7: Comando para execuo do script de teste de comunicao
O cluster openMosix no consegue quebrar a execuo do for, ele apenas consegue
migrar os processos para as mquinas adjacentes. O script elaborado gera apenas 1
processo, porm acionado, por exemplo 10 vezes, gera conseqentemente 10
processos. Dessa forma possvel observar atravs do openMosixmi"mon os
mesmos sendo migrados e assim comprovar que o cluster est em funcionamento.
Tambm possvel analisar, atravs do openMosix4iew, o balanceamento de carga
do cluster( A figura 13 exibe o openMosixmi"mon durante a execuo dos scripts
mostrando os processos sendo migrados aos demais nodos do sistema.
49
A figura 14 exibe o openMosix4iew em funcionamento durante a execuo dos
scripts informando o balanceamento de carga do sistema.
Figura 13: Teste de Comunicao: Migrao de
Processos
50
Figura 14: Teste de Comunicao: Balanceamento de Carga
51
7 TESTANDO A APLICAO NO OPENMOSID
Ao realizar os testes de comunicao para comprovar o funcionamento do cluster,
foi realizada a execuo de uma aplicao que gere vrios processos para se obter
uma comparao de tempo entre um nico elemento executando o mesmo e um
cluster em funcionamento. Os sub-tpicos a seguir descrevem esta etapa.
7.1 APLCAO UTLZADA
A aplicao utilizada para realizao dos testes foi um renderizador de imagens, cujo
nome denomina-se blener. O arquivo pode ser obtido atravs do site
<ftp://ftp.info.abril.com.br/222-blacksmith.tgz>. Entretanto, para a aplicao gerar
vrios processos fez-se necessrio a utilizao de um script que realize o mesmo,
pois o blender uma ferramenta grfica que tem a funo de apenas renderizar a
imagem, e utilizando o script, esse por ventura ser a ferramenta que dividir a
execuo em vrios processos para o cluster distribuir eles aos demais membros. O
script que realiza a diviso de processos exibido no quadro 8, ou tambm pode ser
obtido atravs do site: <ftp://ftp.info.abril.com.br/222-blender.gz>.
52
+,)-in)sh
if . /+ 0lt # 1! then
echo 2syntax3 ren4er -len4erscene startimage en4image no4es2
exit #
fi
BIN=)5sr)-in)-len4er + -len4er path
67N=/# + name of -len4er scene
8I9=:expr ;( /< 0 /= ;%: + no( of images to ren4er
>?N=:expr ;( /8I9 ) /@ ;%: + no( of images per no4e
AB?=:expr ;( /@ 0 # ;%: + loop co5nter
for i in :seC /AB?: ! 4o
BEG=:expr ;( /i ;D />?N ;% ;$ ;( /= $ # ;%:
EN8=:expr ;( /i ;$ # ;% ;D />?N ;$ /=:
/BIN 0- /67N 0s /BEG 0e /EN8 0a E )4ev)n5ll =E )4ev)n5ll *
4one
echo 2 2
echo 2>en4ering2 /8I9 2images from2 /# 2on2 /@ 2no4es(2
echo 2Fasks forke4G network ren4ering in progress(2
echo 0n 2Ho- starte4 at3 2 ! 4ate '$I40Im0Iy IJ3IK3I6'
echo 2?lease wait while ren4ering(((2
wait
echo 2>en4ering s5ccessf5lly finishe4(2
echo 0n 2Ho- en4e4 at3 2 ! 4ate '$I40Im0Iy IJ3IK3I6'
echo 2 2
Quadro 8: Script para renderizao de imagens
53
Em seguida, aps ativar a permisso de execuo do script, executa-se o mesmo
atravs do comando:
ren4er -lacksmith0&peg(-len4 # =<L N
Quadro 9: Comando para execuo da renderizao de imagens no blender
Atravs desse comando acionada a execuo da renderizao de imagens, onde
blacksmith-jpeg.blend o nome do arquivo que ser feita a execuo, 1 o n de
vezes em que sero feitas as renderizaes das imagens, 235 o n de imagens
que sero renderizadas e N o nmero de processos que o usurio deseja que
sejam originadas a partir da renderizao.
7.2 RESULTADOS DAS COMPARAES
A comparao foi realizada de duas maneiras. A primeira foi renderizar as imagens
com diferentes nmeros de nodos no cluster. A segunda foi renderizar as imagens
com 9 nodos no cluster, porm com diferentes nmeros de processos. Nos sub-
tpicos a seguir so apresentadas as configuraes e resultados dos mesmos.
7.2.1 R!(#!"%2$9:' -'* (E*!"' %.u$%s #! &"'-!ss's ! ('#'s
Para realizar esta comparao foi ordenado um padro de processos de acordo com
54
o nmero de ns, ou seja, se o cluster conter 4 nodos, a letra N apresentada no
quadro 9 ser substituda por 4. Dessa forma foram realizadas 3 baterias de testes,
a primeira com apenas 1 computador, a segunda com 4 e a terceira com 9. Ao
acionar a aplicao em 1 nodo, o tempo de renderizao de imagem durou 16m20s,
conforme apresentado na figura 15.
Em seguida foi acionado a renderizao de imagens contendo 4 ns no cluster( O
tempo de execuo durou 6m30s conforme segue na figura 16:
Figura 15: Renderizao de imagens em 1 computador
55
Aps o trmino da renderizao em 4 ns, foi realizada o mesmo em 9 componentes
do cluster( Durante a execuo possvel observar o comportamento dos ns
durante a renderizao conforme segue na figura 17:
Figura 16: Renderizao de imagens em 4 ns
56
possvel tambm observar o balanceamento de carga atravs do openMosix4iew,
conforme segue na figura 18:
Figura 17: Comportamento dos ns durante a renderizao
57
Aps o trmino da renderizao nos 9 nodos, o tempo obtido foi de 2m58s conforme
segue na figura 19:
Aps esses procedimentos, foi realizado mais uma sesso de testes utilizando a
mesma aplicao em 1, 4 e 9 computadores, obtendo dessa forma 15m42s, 7m15s
e 2m36s, respectivamente. O quadro 10 apresenta os resultados obtidos e a mdia
de acordo com o mesmo.
Figura 18: Balanceamento de carga durante a renderizao
Figura 19: Renderizao de imagens em 9 ns
58
Nmero de Ns Teste 1 (segundos) Teste 2 (segundos) Mdia (segundos)
1 980 942 961
4 390 435 412
9 178 156 167
Quadro 10: Tempo de renderizao com n de processos iguais ao n de ns
Na figura 20 possvel observar um grfico que apresenta a relao entre o tempo e
o nmero de ns de forma mais clara.
Dessa forma, possvel comprovar a eficincia do cluster reduzindo o tempo da
renderizao em aproximadamente 82% ao ser acionado em 9 membros do cluster.
Figura 20: Relao Tempo X Nmero de Ns
59
7.2.2 R!(#!"%2$9:' !* 6 ('#'s -'* (E*!"' #! &"'-!ss's #%A!"!(!s
Nesta etapa, foi utilizado 9 ns em todos os testes, porm o nmero de processos
foi diferenciado. Dessa forma foi acionado 9, 15 e 30 processos para a realizao
dos devidos testes. Para estipular o nmero de processos a serem originados
durante a renderizao, foi substituda a letra N apresentada no quadro 9, pelo
nmero de processos, ou seja, se o usurio desejar 15 processos a letra N trocada
pelo nmero 15.
Em todas as baterias de testes, foi observado o comportamento dos ns e o
balanceamento de carga entre eles, a figura 21 apresenta a migrao de processos
durante a renderizao de imagens com 30 processos criados.
60
Aps o trmino da realizao dos testes, foram obtidos diferentes tempos na
renderizao, conforme apresentado no quadro 11.
N de processos Teste 1 (segundos) Teste 2 (segundos) Mdia (segundos)
9 178 156 167
15 158 164 161
30 420 394 407
Quadro 11: Tempo de renderizao em 9 ns com diferentes n de processos
Na figura 22, possvel observar a diferena que houve entre os diferentes nmeros
Figura 21: openMosixmigmon com 9 ns e 30 processos
61
de processos.
possvel observar que ao executar o script com 9 e 15 processos, o tempo fica
praticamente constante, porm ao acion-lo com 30 processos, o mesmo tem um
avano retardativo, chegando a ficar aproximadamente 40% mais lento do que com
os demais nmeros de processos. sso se deve ao fato de que ao executar o script
para iniciar a renderizao das imagens, o programa executado apenas em 1 n
ficando totalmente sobrecarregado como exibe a figura 23.
Figura 22: Relao Tempo X Nmero de Processos
62
Durante esse momento o script est sendo executado e "quebrando a aplicao em
diversos processos de acordo com o solicitado no comando. Dessa forma para
"quebrar a aplicao, por exemplo em 9 processos, o computador que executou a
aplicao leva um curto espao de tempo e assim os processos j podem ser
migrados aos demais membros do cluster. Entretanto, ao executar o mesmo e dividi-
lo em 30 processos, o computador mestre leva um espao maior de tempo em
relao a 9 processos, com isso o tempo de renderizao acaba sendo maior. Neste
caso, para obter a melhor performance o correto seria configurar o nmero de
processos de acordo com o nmero de membros includos no cluster, pois dessa
maneira todos os ns que compem o cluster participam da execuo num espao
menor de tempo.
Figura 23: N sobrecarregado ao executar o script
63
7.3 PONTOS DE FALHA
Para realizar os testes de pontos de falha, foi executado novamente no cluster o
comando para iniciar a renderizao de imagens, no qual pode ser observado no
quadro 9. Por conseguinte, a aplicao est em perfeita execuo como demonstra
a figura 24.
Durante a renderizao das imagens, um dos nodos foi desconectado para testar o
funcionamento da aplicao, conforme segue na figura 25.
Figura 24: Aplicao funcionando normalmente
64
Porm, ao ser desconectado o nodo da aplicao, a ferramente openMosixmi"mon
acabava "travando e dava pra se observar ainda os processos sendo migrados para
o nodo que havia sido desconectado anteriormente, dessa forma a aplicao nunca
terminava, conforme segue na figura 26.
Figura 25: OpenMosixview com um n desconectado
65
sso se deve ao fato do openMosix no possuir funes chec&point, ou seja, ele no
possui mecanismos de tolerncia a falhas onde so comumente encontrados em
cluster de alta disponibilidade. Dessa forma se um dos ns falhar, todas as tarefas
iniciadas nesse n e os que foram migrados sero perdidos. Se um dos ns for
paralisado por exemplo pelo comando shutown, os processos remotos que se
encontram nessa mquina retornaram ao seu host de origem, e assim podem ser
migrados novamente a outro membro do cluster (PTANGA, 2003).
Figura 26: Aplicao "travada" aps o nodo ser desconectado
66
4 CONCLUSO
O cluster, tambm chamado de Clusterin", uma alternativa vivel para os
proprietrios com poucos recursos financeiros. Ela vantajosa pela relao
custo/desempenho, pois apresenta um baixo custo e um alto poder computacional
em relao a um supercomputador independente.
Diante de tudo isso, o cluster ainda proporciona caractersticas que o torna uma
alternativa para instituies de pequeno, mdio e at mesmo grande porte, dentre
elas destaca-se sua escalabilidade, por permitir que novos nodos sejam inseridos de
forma fcil e rpida, aumentando seu desempenho; custo reduzido, como j citado
anteriormente e a independncia dos fornecedores, por utilizar computadores
comuns, facilitando a sua manuteno por no utilizar uma tecnologia muito
complexa.
Como pode ser observado nos testes realizados, o openMosix uma ferramenta de
grande utilidade e que cumpre a maioria das exigncias que lhe so atribudas, alm
de ser uma ferramenta gratuita. Como ela j vem implantada ao sistema operacional
ClusterKnoppix, que foi projetado exclusivamente para esta funo, a utilizao do
openMosix se torna mais intuitiva e rpida de ser implementada, pois a maioria de
suas configuraes realizada antecipadamente pelo prprio ClusterKnoppix(
67
REFERFNCIAS
ALECRM, Emerson. Clus!"G principais conceitos. Disponvel em:
<http://www.infowester.com/cluster.php>. Acesso em: 11 ago. 2008.
BECHER, Marcelo Renan. M'($.!* #! u* A*)%!(! #! Clus!" Us$(#'
S'A>$"! L%;"!G Uma Abordagem aos Clusters de Alta Disponibilidade. Disponvel
em: <http://www.cesarkallas.net/arquivos/tutoriais/TD-MarceloBecher-2007-1.pdf>.
Acesso em 22 ago. 2008.
CAMPOS, Augusto. O Hu! I L%(u7. Disponvel em <http://br-linux.org/faq-linux>.
Acesso em: 23 ago. 2008.
CARDOSO, Fabian Corra; LEO, Gabriela Batista. S'lu9:' $' P"'-!ss$*!('
M$-%9' #! D$#'s ! L%*%! #$ F"!HJ3(-%$ #! Cl'-K -'* ' Us' #! A.l'*!"$#'
#! C'*&u$#'"!s &'" M!%' #$ L%)"%#%2$9:' #! u* Clus!" #! Al' D!s!*&!(+'
-'* u* #! B$l$(-!$*!(' #! C$".$. Disponvel em: <http://www.ulbra-
to.br/eventos/encoinfo2004/..%5C..%5Censino%5C43020%5CArtigos
%5CAnais2004%5CAnais%5CgabrielaLeaoClusterEncoinfo2004.pdf>. Acesso em:
19 ago. 2008.
MACHADO, Carlos. Clus!" -'* L%(u7 ($ *:'. nfo, So Paulo, n. 222. p. 104-
106, set. 2004.
MARCO, Leandro R. Magalhes de. C'*&u$9:' #! Al' #!s!*&!(+'G Clusters.
Disponvel em: <http://www.ic.unicamp.br/~ducatte/mo401/1s2006/T2/Todos-
Trabalhos.pdf>. Acesso em: 4 ago. 2008.
MATOS, Edval Piccolo de. TMCNICAS PARA CONSTRUO DE CLUSTERS DE
ALTO DESEMPENLO COM BAIDO CUSTO. So Paulo: Universidade So
Francisco, 2006.
MORMOTO, Carlos E. B"%(-$(#' #! -lus!". Disponvel em:
<http://www.guiadohardware.net/artigos/cluster/>. Acesso em: 11 ago. 2008.
NEVES, Marcelo V. et. Al. P$('"$*$ #! A!""$*!($s &$"$ .!"!(-%$*!(' #!
-lus!"s. Disponvel em: <http://www-usr.inf.ufsm.br/~schepke/mestrado/wsppd.pdf>
Acesso em: 19 ago. 2008.
OLVERA, Daniel Cndido de. D!s!(;'l;%*!(' #! Clus!" #! Al'
D!s!*&!(+'. Disponvel em: <http://www.ulbra-
to.br/ensino/43020/artigos/relatorios2004-2/Arquivos/Daniel_Estagio.pdf>. Acesso
em: 19 ago. 2008.
68
PERERA, N. A. S!";%9's #! &!"%(3(-%$ &$"$ -lus!"s #! $l$ #%s&'(%)%l%#$#!.
So Paulo: USP, 2004.
PNTO, Hudson J. Lamounier; SLVA, Michel Pires D; SLVERA, Gabriel Damaso D.
A*)%!(!s #! Al' D!s!*&!(+' u%l%2$(#' Clus!" #! C'*&u$#'"!s.
Disponvel em: <http://www.ericfernandes.pro.br/images/5/5d/Ha3.pdf>. Acesso em:
19 ago. 2008.
PTANGA, Marcos. COMPUTAO EM CLUSTERG Construindo
Supercomputadores com Linux. Rio de Janeiro, Brasport, 2003.
ROCHA, Lidiane L. D. Clus!"sG Viso Geral. Disponvel em:
<http://www.cesmic.ucb.br/documentacao/producaocientifica/artigostutoriais/cluster_
vg.pdf>. Acesso em: 11 ago. 2008.
ROCHA, J. M. G. Clus!" B!'>ulAG Aspectos de projeto e implementao. Belm:
UFPA, 2003.
ULBRCH, Henrique Cesar. G!"!(-%$#'" #! Clus!"s L%(u7N '&!(M's%7N s!"O
#!s-'(%(u$#'. Disponvel em: <http://magnet.pro.br/mercado/gerenciador-de-
clusters-linux-openmosix-sera-descontinuado>. Acesso em: 8 nov. 2008
WEBER, Taisy Silva. T'l!"1(-%$ $ A$l+$sG conceitos e exemplos. Disponvel em:
<http://www.inf.ufrgs.br/~taisy/disciplinas/textos/ConceitosDependabilidade.PDF>.
Acesso em: 22 ago. 2008.