UNIVERSIDADE FEDERAL DE SANTA CATARINACURSO DE GRADUAÇÃO EM CIÊNCIAS DA COMPUTAÇÃO

Guilherme Arthur Geronimo

Estudo em Terminais Leves como nós de um Cluster.

Trabalho de Conclusão de Curso

André Zimmermann

José Eduardo De Lucca, Dr.

Florianópolis, Fevereiro de 2007

Estudo em Terminais Leves como nós de um Cluster.

Guilherme Arthur Geronimo

Este Trabalho de Conclusão de Curso foi aprovado em sua forma final pelo Curso de Ciências da

Computação da Universidade Federal de Santa Catarina.

André Zimmermann

José Eduardo De Lucca, Dr.

Prof. José Mazzuco Júnior, Dr.

Banca Examinadora

André Zimmermann

Prof. José Eduardo De Lucca, Dr.

Mario Dantas, Dr.

iii

"Okite hanjô, nete itijô. Tenka tottemo nigôhan."(Provérbio Japonês)

Agradecimentos

Agradeço a todos que aqueles que não acreditaram na minha idéia. Pois a dúvida destes

me apontou o caminho. Agradeço mais ainda à todos do NPD da UFSC, que apesar de me con-

siderarem louco nunca me negaram tempo e material para minha o meu estudo. E aos meus pais

agradeço pelo interesse, pois mesmo sem me entender ouviam pacientes e interessados.

Sumário

Sumário v

Lista de Figuras vii

Resumo viii

Abstract ix

1 Objetivos 1

1.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Introdução 2

2.1 Servidor de Terminais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Terminais Leves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Estado da Arte e Motivações 6

3.1 Terminais Leves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Exemplificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.2 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.3 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Metodologia 12

4.1 Sobre o Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Sobre a Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Sobre o Linux e o openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vi

4.3.1 Configuração do openMosix . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4 Sobre as ferramentas de monitoração . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5 Sobre os Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Resultados 20

5.1 Dados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.1 Teste Sem openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.2 Teste com openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Análise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3 Problemas Encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4 Considerações Finais e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . 39

6 Referências Bibliográficas 40

Lista de Figuras

3.1 oMFS - openMosix Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Rich Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 CluxtMaxter - Servidor do Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 openMosixView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 openMosix Migration Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Memória Livre do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Número de Processos no Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Carga do Média do Sistema (a cada minuto) . . . . . . . . . . . . . . . . . . . . . 22

5.4 Carga do Média do Sistema (a cada 5 minutos) . . . . . . . . . . . . . . . . . . . 23

5.5 Numero de Operações de Escrita e Leitura . . . . . . . . . . . . . . . . . . . . . . 24

5.6 Carga Total e Eficiência do Balanceamento de Carga . . . . . . . . . . . . . . . . 25

5.7 Carga e Memória do Nó 1 (Servidor) . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.8 Carga e Memória do Nó 248 (Rich Client) . . . . . . . . . . . . . . . . . . . . . . 27

5.9 Carga e Memória do Nó 247 (Thin Client) . . . . . . . . . . . . . . . . . . . . . . 28

5.10 Carga do Média do Sistema (a cada minuto) . . . . . . . . . . . . . . . . . . . . . 29

5.11 Carga do Média do Sistema (a cada 5 minutos) . . . . . . . . . . . . . . . . . . . 30

5.12 Lista de Processos Migrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.13 Memória Livre do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.14 Memória Total Utilizada no Cluster . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.15 Número de Processos no Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.16 Número de Operações de Escrita e Leitura . . . . . . . . . . . . . . . . . . . . . . 35

5.17 Entrada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.18 Saída de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Resumo

Nos dias de hoje, com a melhora das redes de comunicação, cada vez mais estamos usu-

fruindo da tecnologia de acesso remoto à servidores de terminais. Mas com esta convergência

em massa, mais e mais é exigido do hardware do servidor, mas nem sempre há possibilidade de

atualizações da máquina. Por este motivo o trabalho testa a viabilidade de utilizar o poder de

processamento e a memória ociosos do cliente para compartilhar a carga do servidor. Para isso

utilizaremos a solução em cluster openMosix.

Abstract

Now days, with the improve of the communication networks, more we are using the remote

access technology to connect to terminal servers. That mass convergence demands more and more

from the server’s hardware, but sometime we don’t have ways (reads, money) to upgrade the

machine. For that reason, this paper tries to test the viability of use idle processor’s cycles and idle

memory of the clients to balance the load of the server. To do this we’ll try to use the openMosix

solution.

Capítulo 1

Objetivos

O presente trabalho tem como objetivo verificar a viabilidade da utilização de terminais le-

ves como nós (nodes) de um cluster OpenSource (openMosix) servidor de aplicações. Os mesmos

terminais leves (Thin Clients) que exibem as aplicações para os usuários, ajudarão no processa-

mento das mesmas incluindo-se no cluster. A idéia é utilizar o processamento de cada terminal -

que apesar de não ser muito, normalmente fica ocioso - para diminuir a carga do servidor.

1.1 Objetivos Específicos

• Estudar o projeto OpenSource OpenMosix. Visando aprender sua estrutura de funciona-

mento.

• Montar um cluster OpenMosix, o qual servirá como um servidor de aplicações e utilizará

como nós (nodes) terminais leves.

• Testar o desempenho do cluster executando softwares básicos, softwares normalmente utili-

zados por usuários em um escritório e/ou laboratório de informática.

• Verificar viabilidade da implantação de uma estrutura como esta em um Escritório/Laboratório.

Capítulo 2

Introdução

Devemos primeiramente narrar ao leitor a conjuntura a qual este se desenvolveu. Este é

um trabalho prático, que foi executado no Núcleo de Processamento de Dados (NPD) da Univer-

sidade Federal de Santa Catarina (UFSC). Sua idéia surgiu devido a uma crise de hardwares que

estávamos passando durante a implantação dos Servidores de Terminais (Terminal Server) Linux

no Laboratório de Informática dos Alunos de Graduação e Pós-Graduação da UFSC (LabUFSC).

Tínhamos algumas máquinas boas, mas que não seriam o bastante para suportar todo os usuários

do laboratório, o que contabilizava algo na faixa de 150 máquinas mais ou menos. Surgiu então a

idéia: "Já que os Terminais não processam nada (além da imagem que vem do servidor), porque

não colocar eles para ajudar o servidor?!". E assim surgiu a idéia deste.

No Capítulo anterior (Objetivos) assim como no parágrafo acima, foram citados delibe-

radamente uma série de termos e expressões que, além de serem chaves para este trabalho, para

alguns podem não ser tão usuais assim. Acredito então que antes de mais nada devemos conceituar

alguns destes termos chaves que trataremos ao longo do texto, tais como: Servidor de Terminais,

Terminais Leves, Clusters e Grids. Os quais serão imprescindíveis para a compreensão do trabalho.

2.1 Servidor de Terminais

Também conhecido por "Servidor de Aplicações", o Servidor de Terminais nada mais é

que um servidor de Interfaces Gráficas. Utilizando um sistema operacional multi usuário, este

permite e gerencia a abertura de Ambientes Gráficos (sessões) de usuários remotos. Separando

então o sistema operacional nativo (que o usuário utiliza em seu computador pessoal), do sistema

operacional visualizado (o qual ele necessita para executar suas aplicações). Aos olhos do usuário

3

é como se o sistema operacional remoto estivesse na sua máquina. É claro que existem algumas

restrições por exemplo, o acesso aos dispositivos locais de sua máquina é um caso complicado. Se

o usuário desejar utilizá-los estes deverão ser montados remotamente no servidor.

Existem uma série de maneiras - leia-se protocolos - de acessar remotamente o ambiente

gráfico de um servidor. Uma das primeiras soluções de acesso remoto que mais se difundiu (além

dos antigos terminais Citrix ICA e Tarantella) foi o VNC, com ele um usuário utilizando (prati-

camente) qualquer sistema operacional pode acessar um ambiente gráfico de outro sistema ope-

racioná completamente diferente. Característica essa que ajudou em muito a sua difusão, mesmo

apresentando uma qualidade de imagem e tempo de resposta não muito satisfatórios. O VNC é

baseado no protocolo RFB, Remote FrameBuffer. Todos os eventos de mouse e teclado são envi-

ados para o servidor e adicionados no buffer, o mesmo acontece (mas de maneira inversa) com as

imagens enviadas ao dispositivo de vídeos.

Desde o lançamento da plataforma NT o Windows trouxe com ele o sistema de acesso

remoto RDP (Remote Desktop Protocol) baseado no protocolo T.128. Inicialmente utilizado para

administração remota de servidores, permitia apenas o acesso de um usuário por vez. Logo notou-

se o potencial do mesmo e em um curto espaço de tempo a Microsoft lança seu primeiro Servidor

de Terminais, o Windows NT 4.0 Server - Terminal Server Edition. O RDP trás com ele uma série

de funcionalidades que auxiliam o usuário, tais como redirecionamento de áudio, encriptação de

dados, redirecionamento de sistemas de arquivo, redirecionamento de impressora, entre outros que

careciam no VNC.

Um dos "protocolos exclusivos"(e um dos mais antigos) do UNIX é o XDMCP , protocolo

padrão do servidor gráfico X11. Praticamente todos os sistemas linux e BSD utililizam ele, mesmo

não sendo um servidor de terminais ele é utilizado via comunicação interna (sockets) nestes S.O.’s.

Ele oferece uma qualidade de imagem vezes superior ao VNC, mas também gera um tráfego de

rede de maneira proporcional. Apartir de 2002, a empresa NoMachine vem trazendo uma solução

para sanar este problema, o NX. Este por sua vez utiliza-se da encriptação do SSH, da compressão

JPEG e do GZIP para enviar seus dados para os clientes de forma rápida e segura.

4

2.2 Terminais Leves

Terminais Leves (Thin Clients), por definição são computadores desprovidos de hardwares

de alto desempenho, que interligados em rede, se utilizam do processamento de um servidor para

processar seus aplicativos. Geralmente se conectam apenas na interface gráfica do servidor de

aplicações, passando assim a ser uma "janela"deste para com o usuário.

Os Terminais Diskless são uma ramificação dos Terminais Leves. Estes por sua vez não pos-

suem Disco Rígido (Hard Disk HD). Desta forma, eles buscam seu Sistema Operacional da uni-

dade de CD/Diskete, da Rede (Network Boot) e/ou de uma unidade remota na rede (geralmente

via NFS , Network Filesystem). Neste trabalho utilizamos Terminais Diskless que iniciam pelo

driver de CD.

Os Terminais Diskless são uma ramificação dos Terminais Leves. Estes por sua vez não

possuem Disco Rígido (Hard Disk - HD). Desta forma, eles buscam seu Sistema Operacional da

unidade de CD/Diskete ou da Rede (Network Boot). Neste trabalho utilizamos Boot pelo driver de

CD.

2.3 Clusters

Um cluster é uma estrutura computacional Multi-Computada. Esta é formada por um con-

junto de computadores, interconectados por uma rede, que pode-se utilizar de um software es-

pecial (PVM,MPI,etc) e/ou um tipo especial de sistema operacional classificado como sistema

distribuído, trabalhando assim de uma forma unificada. Estes são construídos muitas vezes a par-

tir de computadores convencionais (Commodity Off-The-Shelf, ou COTS), interligados por uma

rede comunicam-se de uma forma tal que o sistema trabalha como se fosse uma única máquina de

grande porte. O custo benefício desta estrutura é superior, pois ao invés de investir em um grande

computador (de alto custo), investe-se em vários computadores (de baixo custo) e colocam eles

para trabalharem juntos.

Joseph D. Sloan em seu livro High Performance Linux Clusters mostra um case de sucesso

desta arquitetura computacional de Multicomputada:

"(...)O cluster "Big Mac"construído pelo Virginia Polytechnic Institute e a State University

foi inicialmente construído com 1100 computadores bi-processados Macintosh G5. Sua velocidade

era da ordem de 10 teraflops, fazendo dele um dos supercomputadores mais rápidos que existiam.

Enquanto supercomputadores desde tipo geralmente levam alguns anos para serem construídos e

5

custavam em entre $100 milhões e $250 milhões de dólares, o Big Mac foi construído em menos

de um mês e custou em torno de $5 milhões de dólares."

2.4 Grids

Os termos Cluster e Grid muitas vezes andam juntos, e geralmente são tidos como sinô-

nimo, o que não o são. A Computação em Grid, assim como os clusters, é um modelo computaci-

onal emergente que fornece um throughput elevado, utilizando muitos computadores interligados

em rede, montando uma arquitetura de computador virtual que pode distribuir a execução de um

processo através de uma infraestrutura em paralelo. O Grid utiliza-se dos recursos de diferen-

tes computadores ligados em rede (geralmente a Internet) para resolver problemas computacio-

nais de grandes escalas (Ex. Cura do Câncer, Previsão do Tempo, Análise de sinais de Rádio-

Telescópios, etc). Diferentemente dos Clusters, esta provê a habilidade de computar grandes es-

calas de dados, quebrando-os em pedaços menores e os processando-os em paralelo, dividindo o

"problema"igualmente entre vários computadores.

A Computação em Grid pode ser realizada de forma heterogênea e em rede (Internet ou

dedicada). Não existe necessariamente uma rede tal como existe, por exemplo, na interligação dos

nós em um cluster. Podemos dizer que: "Podemos ter um cluster dentro de um Grid, mas não

podemos ter um Grid dentro de um cluster".

Um dos projetos mais famosos que utiliza Grid é o SETI@Home, da Universidade de

Berkeley. Este é uma experiência científica que utiliza computadores conectados à Internet na

procura por Inteligência Extraterrestre. Cada computador conectado ao projeto ajuda na análise de

dados recebidos pelo radio telescópio do mesmo.

Capítulo 3

Estado da Arte e Motivações

3.1 Terminais Leves

A idéia de utilizar Terminais não é algo recente. Desde a época dos MainFrames esta

idéia ja era aplicada. Um terminal nada mais é que equipamento disponibilizado ao usuário, que

serve de interface para um sistema de informação. Nos Mainframes, existiam vários terminais

conectados (diretamente e/ou através da rede) possibilitando assim a utilização de seus recurso por

vários usuários simultâneos.

Com a popularização dos PC’s (Personal Computers), pouco a pouco os MainFrames foram

caindo em desuso sendo substituidos por máquinas Standalone, com seu próprio Sistema Opera-

cional, Disco-Rígido, etc. Esta mudança tecnológica possibilitou uma maior flexibilidade nestas

estação de trabalho, o que deixou os usuários mais a vontade com seu ambiente de trabalho, pos-

sibilitando o mesmo ter a liberdade de escolher seu Sistema Operacional, utilizar seus programas

preferidos, etc. Custando assim aos Profissionais de T.I. noites mal dormidas e implantes capi-

lares, pois nesta estrutura necessitou-se de sistemas de intercâmbio de informações, investimento

em hardwares e monitoramento dos mesmos. Sem contar com as eventuais falhas de hardwares,

pois a probabilidade de dar algum erro é vezes maior pelo fato de estarem tratando com vários

computadores e não uma máquina só.

Apesar disto hoje em dia, em muitos ambientes corporativos e acadêmicos (como Call Cen-

ters e Laborátorios) não podemos ceder tais privilégios para nossos usuários, e muito menos correr

o risco de perder dados de usuários (ainda mais aqueles que são desenvolvedores) por "crash"de

hardware. Voltou-se então a idéia de ceder aos usuário Terminais. Como a tecnologia em software

(e Sistemas Operacionais Multi-Usuários principalmente) avançou em passos largos na ultima dé-

7

cada, oferecer um terminal para o funcionário não teria grande impacto para o usuário final, afinal

a interface a qual o mesmo teria de lidar seria praticamente a mesma o qual ele estava acostumado.

Centralizando o Sistema Operacional, facilitaria a monitoração do sistema e os gastos com

hardware diminuiriam. Afinal, é mais fácil monitorar e mais barato investir em uma máquina só

que em várias máquinas ao mesmo tempo. Isto abriu uma série "portas"para os Administradores

de T.I., eles poderiam se concentrar em garantir a segurança do sistema e investir na integridade

dos dados (através de espelhamento, RAID, etc.) e ainda assim podendo garantir (ou não) as

configurações dos usuários, e sua saúde capilar.

3.2 openMosix

O próprio projeto do openMosix define o mesmo como "uma extensão de kernel para clus-

terização SSI. Ele é proeminente do projeto MOSIX mas esta sobre a licença GPL (Gnu Public

License)". Não explica muito, mas Joseph D. Sloan, diz que "basicamente, o software openMosix

inclui tanto uma extensão de kernel quanto um pacote de ferramentas de suporte. A extensão de

kernel prove suporte para a movimentação de processos entre as máquinas do cluster. Tipicamente

a migração de processos é totalmente transparente para o usuário. Porém, usando as ferramentas

providas pelo openMosix, juntamente com outras aplicações, o usuário pode controlar a migração

dos processos entre as máquinas do cluster.".

Uma vez instalado, os nós do cluster mantém comunicações entre eles sobre a disponibi-

lidade dos recursos (processador e memória), permitindo a cada nó ter conhecimento do status

dos outros nós, podendo assim disponibilizar os seus próprios recursos. Desta forma, se um nó

com vários processos detecta que outro nó tem disponibilidade superior (tem menos carga no pro-

cessador/RAM), o openMosix encarrega-se de migrar um desses processos para esse nó, dando

origem ao processamento distribuído. O openMosix tenta continuamente classificar os custos de

transladação e fazer previsões sobre a viabilidade da mesma, atribuindo pesos a cada nó.

O openMosix utiliza um sistema de arquivos próprio, o openMosix FileSystem (oMFS). Ele

permite trocas de dados entre vários processos. Este mecanismo suporta algumas das funcionalida-

des de Inter Process Communication (IPC) mais simples, como pipes, fifos, e redirecionamento de

arquivos. Utilizando oMFS e uma configuração adequada, é ainda possível permitir aos processos

remotos o acesso direto a arquivos, dados e dispositivos existentes no servidor, ainda que estes não

existam no nó anfitrião do processo. Segue abaixo uma imagem exemplificando.

8

Figura 3.1: oMFS - openMosix Filesystem

9

3.2.1 Exemplificação

Se você é um daqueles que leu as definições anteriores, entendeu mas ainda não sabe ao

certo como funciona, vamos exemplificar o funcionamento dele antes de aprofundar um pouco

mais. Existem uma série de exemplos que poderíamos dar, uns simples, outros mais complexo.

Falaremos sobre dois então, um tradicional (o qual aparece até mesmo na documentação do open-

Mosix) e outro funcional, demonstrando assim a ligação entre a tecnologia ao objetivo inicial deste

trabalho.

Imagine que você durante sua graduação esteja dividindo um quarto com um colega da

faculdade. Ambos são aficionados por Linux e softwares livres. Como cada um tem seu computa-

dor sem duvida instalaram o openMosix desde sua primeira versão. Um certo dia você consegue

aquele novo CD do Julio Iglesias que a sua namorada tanto pediu de presente. Depois de passar

todas as musica (digamos umas 20) do CD para .WAV no computador, você começa a converte-las

para .MP3. Mas como seu PC é mais antigo (leia-se lento) que Silvio Santos, cada musica demora

em torno de 120 segundos para converter. Enquanto isto, seu companheiro de quarto (o qual é

apaixonado por jogos online) esta em seu computador ultra-moderno no Messenger com sua na-

morada virtual sem rodar nada pesado em seu PC. Você então executa 4 processos de conversão

(um convertendo cada musica) e manda o openMosix migrar 3 deles para o PC de seu colega. Ou

seja, ao invés de demorar 40 minutos convertendo as MP3, você demoraria 10 minutos (supondo

que o PC de seu colega converta 3 arquivos a cada 120 segundos).

No caso do Servidor de Terminais aconteceria mais ou menos a mesma coisa. Quando o

servidor estivesse com uma carga alta devido a quantidade de processos dos usuários, ele come-

çaria a enviar os mesmos para serem executados pelos nós/clientes. Diferentemente dos clusters

Ad-Hoc, nos quais os nós distribuem seus próprios processos no cluster, neste existe apenas um

servidor que distribui os processos e os nós não podem migrar os seus processos para o servi-

dor. Ou seja, quando o servidor esta com uma carga alta, ele distribui sua carga para os nós, mas

quando os nós precisam de ajuda no processamento, seu processos são impedidos de migrar para

o servidor.

3.2.2 Vantagens

Como citado acima, o openMosix oferece um ambiente clusterizado SSI (Single System

Image). O Servidor funciona como uma máquina SMP virtual (continua sendo uma arquitetura

Multi-Computada, mas parece uma Multi-processada), onde cada nó prove seu processador e me-

10

mória para o cluster.

O fato de todos o nós rodarem (impreferivelmente) o mesmo kernel e tornar a migração

dos processos transparente para os usuários, torna desnecessário qualquer alteração dos códigos

dos programas executados. Ou seja, não é necessário a utilização de nenhuma biblioteca especial

para os programas rodarem no cluster, tais como PVM e MPI. Os processos não são quebrados para

serem processados, eles são apenas migrados para outras máquinas e processados remotamente.

As versões mais novas do openMosix vem com uma ferramenta chamada Auto Discovery.

Que por sua vez fica monitorando a rede em busca de novos nós que vão surgindo e os incorporam

automaticamente em sua relação de nós. Auxiliando assim no gerenciamento do cluster e por sua

vez aumentando a escalabilidade do sistema.

Como o openMosix precisa praticamente apenas do kernel e nenhum outro pacote adicional

isso possibilita gerar facilmente um novo nó no cluster. Geralmente quando tratamos de terminais

leves, tratamos com máquinas que não possuem disco rígido e por este motivo fazem boot via Rede

ou CD, puxando seu kernel e seu sistema operacional de um servidor. Basta então disponibilizar

um kernel com o patch do openMosix e um initial RAM disk com as configurações padrão para o

nó e liga-lo. Como o sistema depende do kernel e da versão do openMosix (todos os nós devem

ter a mesma versão do kernel com a mesma versão do openMosix) pode-se teoricamente utilizar

uma infinidade de hardwares como nós, basta compila-lo no mesmo. Permitindo assim a criação

de um cluster em um ambiente heterogêneo.

11

3.2.3 Desvantagens

Como vimos acima, o núcleo do openMosix é o kernel, e isto é considerado por muitos

uma grande vantagem. Mas podemos considerar isso uma faca de dois cumes, pois pode ser

considerado uma grande desvantagem também. Infelizmente o projeto openMosix (além de um

tanto estagnado) foca seu desenvolvimento em versões de kernel, não há um patch genérico que

sirva para qualquer versão, aliás, todas sua versões estáveis ainda são para 2.4.X, e recentemente

lançaram uma versão beta para o 2.6.1. Então se você possuir algum hardware que é suportado

apenas pelas versões mais recentes do kernel e não funciona com as versões as quais o openMosix

trabalha você terá, ou melhor, não terá mais um nó.

Como citamos no sub-item "Vantagens", a granularidade da estrutura esta relacionada ao

nível dos processos. Sendo assim, se utilizarmos aplicativos "monolíticos"que não geram pro-

cessos menores ou que geram vários processos rápidos (menos que 5 segundos) não haverá ganho

algum de desempenho, pois estes não migrarão. Processos que lidam diretamente com dispositivos

de I/O também não migrarão. O que torna o sistema um tanto instável no quisito de balanceamento

de carga.

Capítulo 4

Metodologia

4.1 Sobre o Hardware

Foram utilizados 3 (três) computadores na fase de experimentos. Um de cada categoria.

Estes foram escolhidos devido sua similaridade para com as que existem no parque de máquinas do

LabUFSC: Um workstation com Hard Disk (HD) o qual foi utilizado como servidor, uma maquina

depreciada sem Hard Disk (Diskless) mas com uma quantidade considerável de memória a qual

foi nomeada como Rich Client e uma máquina depreciada sem Hard Disk e com pouca memória

que nomeamos de Thin Client. Segue abaixo suas respectivas fotos e especificações técnicas:

Figura 4.1: Rich Client Figura 4.2: CluxtMaxter - Servidor do Cluster

Servidor

• Processador - AMD Athlon(tm) XP 1800+ (1.494 MHz)

13

• Cache Size - 256 KB

• Memória - 754 MB

• Rede - SiS900 100baseTx-FD

Rich Client

• Processador - Petium II 350 MHz

• Cache Size - 512KB

• Memória - 384 MB

• Rede - 10/100Mbps

Thin Client

• Processador - Pentium 133MHz

• Cache Size - 256KB

• Memória - 64MB Ram

• Rede - Realtek 10/100Mbps

4.2 Sobre a Rede

Para a estrutura da rede, foi utilizado um Hub Ethernet da Encore de 10/100Mbps e cabos

da Furokawa clipados de forma paralela. A decisão de utilizar um Hub 10/100Mbps (e não um

Switch) foi decorrido pela necessidade de tornarmos o ambiente mais hostil. Seria irreal pensar

que em um cluster teríamos uma Taxa de Transmissão alta para cada nó (node), por isto a rede de

10/100Mbps foi compartilhada entre 3 (três) computadores. Segue abaixo respectivamente suas

fotos e suas especificações técnicas.

4.3 Sobre o Linux e o openMosix

Primeiramente tentou-se fazer a unificação do projeto LTSP e do projeto ThinStation como

um kernel com o patch do openMosix e suas devidas ferramentas para controle e monitoração

14

(User Space Tool) do mesmo. Nos demos conta então, depois de um certo tempo perdido, de que

este passo que deveria ser inicial e teoricamente rápido tomaria muito tempo do projeto, tempo

este que não tínhamos. Partiu-se então para uma solução um tanto mais prática e simples, utilizar

uma distribuição de Linux que já utilizasse o openMosix em seu kernel padrão. Identificou-se

então um leque considerável de distribuições Linux para utilizarmos em nosso trabalho. Entre elas

o clusterKnoppix, o Quantian e o BCCD, projetos os quais se destacavam entre os mesmos de sua

categoria. O Quantian, como uma distribuição voltada para o meio Científico oferece uma gama

gigantesca de softwares Físicos, Matemáticos, Astronômicos, Mecânicos, Contábeis e etc, e por

este motivo é distribuído como uma imagem de DVD, ou seja, sua instalação era muito maior e

mais pesada que as outras distribuições. O BCCD pareceu bem enxuto em termos de softwares,

tão enxuto que não proporcionou os softwares necessários para posteriormente fazermos os testes.

Já o clusterKnoppix, além de ter uma certa maturidade (foi uma das primeiras distros que veio com

o patch do openMosix) cedia todas as ferramentas necessárias tanto para os testes quanto para a

monitoração dos mesmos, e por este motivo foi utilizado neste trabalho.

4.3.1 Configuração do openMosix

Apesar da próprio distribuição oferecer uma configuração padrão do openMosix, uma série

de otimizações foram feitas. Afinal de contas a configuração dos nós devem ser diferentes da do

servidor.

Para o servidor, a entrada de todo e qualquer processo imigrante foi bloqueada. Ele não

aceitava processos vindo de outros nós. Tanto a migração de seus processos quanto a utilização do

oMFS foram habilitadas. O último (oMFS) foi removido das novas versões do openMosix, mas

sem ele o sistema não funcionou.

Nos nós, a chegada de processos imigrante foi habilitada e a saida de processos locais/imigrante

que poderiam migrar foi bloqueada, para evitar a sobrecarga da rede. Como não há possibilidade

dos processos dos nós migrarem, não havia necessidade de habilitar o oMFS neles, por este motivo

o mesmo foi desabilitado nos nós.

Nos Anexos constam as configurações utilizadas tanto no servidor quanto nos nós

15

4.4 Sobre as ferramentas de monitoração

O openMosix possui uma série de ferramentas de monitoração própria. Dentre elas utiliza-

mos o openMosixWebView, openMosixView, Migration Monitor, openMosixcollector e o open-

Mosixprocs. Foi utilizado também o Zabbix, ferramenta a qual não esta atrelada ao projeto open-

Mosix.

O openMosixView e o Migration Monitor foram utilizados apenas durante a fase de testes,

para monitorar a migração dos processos, pois não apresentavam muitos dados sobre o sistema,

mas mesmo assim se mostraram muito úteis. As figuras 4.1 e 4.2 são screenshots dos mesmos.

Figura 4.3: openMosixView

16

Figura 4.4: openMosix Migration Monitor

As ferramentas mais utilizadas foram openMosixWebView que forneceu em forma de grá-

ficos praticamente todos os dados condizentes ao cluster, o openMosixcollector que serve de bac-

kend para o openMosixWebView, o openMosixprocs que lista quais os processos que migraram e

para onde foram (entre outros dados) e o Zabbix, o qual forneceu também em forma de gráficos um

leque imenso de dados do sistema, tanto quando o mesmo estava utilizando o sistema openMosix,

quanto sem o openMosix (ambiente o qual o openMosixWebView funcionou).

17

4.5 Sobre os Testes

Para testarmos o desempenho da estrutura formulamos um protocolo a ser seguido durante

os testes. Cada usuário que abrisse uma sessão no servidor executaria uma série de programas pré

determinados e assim que estes tivesse carregado, os mesmo interagiriam com estes de acordo ou-

tro protocolo. Após 10 minutos a sessão seria encerrada. E os dados seriam recolhidos. Como em

um sistema de terminais geralmente existem N-1 sessões abertas no servidor, sendo X o número de

computadores na rede contando com o servidor, em nossos testes utilizamos duas sessões abertas.

A conexão com a interface gráfica do servidor foi feito via NX. Sistema parecido com o

VNC, mas com grande diferença na conexão feita entre o cliente e o servidor. Esta é feita via um

túnel SSH, o mesmo compacta a imagem se ser exibida na tela e a envia de forma compactada e

encriptada para o cliente. Além de fornecer segurança, ocupa uma banda irrisória, mas consome

um certo processamento de ambas as partes, para compactar/descompactar e encriptar/decriptar.

Voltando aos softwares. Como a idéia do trabalho era verificar a viabilidade da estrutura em

um ambiente de escritório/laboratório, escolhemos uma série de aplicativos um tanto difundidos

dentro do mundo OpenSource e que são usualmente encontrados e utilizados neste meio. Bom

frisar que alguns foram escolhidos pela sua exigência de de hardware, tanto no quesito de memória

quanto no de processador. Escolhemos então:

• Konqueror - Navegador de Internet.

• BrOffice - Editor de texto, planilhas, Apresentações e etc.

• Gimp - Editor de imagem.

• Gaim - Programa de mensagens.

Assim que a sessão abrisse e os programas supracitados fossem devidamente executados e

carregados, o usuário:

• Abriria uma sessão no Gaim e se conectaria a rede de mensagens instantâneas.

• Entraria no site www.terra.com.br com janela 01 do navegador.

• Entraria no site www.fuskerxp.com com janela 02 do navegador.

• Entraria no site webmail.inf.ufsc.br com janela 03 do navegador e logaria entraria em sua

conta.

18

• Carregaria um arquivo predeterminado com o BrOffice.

• Carregaria uma imagem pré determinada com o Gimp.

• Salvaria o arquivo do BrOffice.

• Salvaria a imagem do Gimp.

Os sites utilizados nos testes foram escolhidos pela quantidade de seu conteúdo (e pela

qualidade também), o que refletiria (em nossa concepção) na utilização da memória cache do

navegador de Internet, ja que o mesmo utiliza a memória RAM do computador para armazenar o

seu cache antes de passar para o disco rígido. Já o BrOffice e o Gimp representavam a abertura

e o carregamento de arquivos em disco para a memória (além do processamento). Ambos os

programas têm fama de sobrecarregar a maioria dos computadores, e nossa maior preocupação era

ver como ele reagiria tendo seu processo em uma máquina e seus arquivos em outra.

Um pouco antes do tempo dos testes expirarem e após as sessões serem fechadas, os se-

guintes dados e gráficos foram coletados das ferramentas de monitoração:

• Carga Total e Eficiência do Balanceamento de Carga.

• Carga e Memória do Nó 1 (Servidor).

• Carga e Memória do Nó 248 (Rich Client).

• Carga e Memória do Nó 247 (Thin Client).

• Carga do Sistema (a cada segundo).

• Carga do Sistema (a cada 5 segundos).

• Entrada da Rede do servidor.

• Lista de Processos Migrados.

• Memória Livre do Servidor.

• Memória Total Utilizada no Cluster.

• Numero de Operações de Escrita e Leitura.

• Número de Processos no Sistema.

19

• Saída da Rede do Servidor

Para poder ter uma base de comparação repetimos este teste de duas maneiras, com a

utilização dos nós e sem a utilização do nós. Em um primeiro momento desabilitamos a migração

de processos para o cluster, e em um segundo momento os habilitamos.

Capítulo 5

Resultados

5.1 Dados Obtidos

5.1.1 Teste Sem openMosix

Após a execução da bateria de testes, os dados recolhidos foram:

Figura 5.1: Memória Livre do Servidor

21

Figura 5.2: Número de Processos no Sistema

22

Figura 5.3: Carga do Média do Sistema (a cada minuto)

23

Figura 5.4: Carga do Média do Sistema (a cada 5 minutos)

24

Figura 5.5: Numero de Operações de Escrita e Leitura

25

5.1.2 Teste com openMosix

Após habilitar o openMosix e execução da bateria de testes, os dados recolhidos foram:

Figura 5.6: Carga Total e Eficiência do Balanceamento de Carga

26

Figura 5.7: Carga e Memória do Nó 1 (Servidor)

27

Figura 5.8: Carga e Memória do Nó 248 (Rich Client)

28

Figura 5.9: Carga e Memória do Nó 247 (Thin Client)

29

Figura 5.10: Carga do Média do Sistema (a cada minuto)

30

Figura 5.11: Carga do Média do Sistema (a cada 5 minutos)

31

Figura 5.12: Lista de Processos Migrados

32

Figura 5.13: Memória Livre do Servidor

33

Figura 5.14: Memória Total Utilizada no Cluster

34

Figura 5.15: Número de Processos no Sistema

35

Figura 5.16: Número de Operações de Escrita e Leitura

36

Figura 5.17: Entrada de Rede

37

Figura 5.18: Saída de Rede

38

5.2 Análise dos Dados

Observandos os gráficos de memória livre logo podemos ver a diferença que o openMosix

proporcionou. Sem o mesmo a memória do servidor foi utilizada quase 100% do tempo enquanto

o com ele houve um suave ocupação da memória, restando ainda em seu píco de utilização mais

de 60MB livres, certa de 10% do total.

Já quando comparamos os Load Averege nos dois casos, notamos que a carga do sistema foi

relativamente maior durante a utilização do cluster. O Load Averege é o valor médio de processos

sendo executados ou esperando para serem executados durante o período de 1, 5 e 15 minutos.

Como o número de processos não mudou de um cenário para o outro (como visto nos gráficos),

só pode ser decorrido ao delay de acesso aos dispositivos de I/O. Se analisarmos o gráfico de I/O

podemos ver que de um cenário para o outros, o número de leitura e escrita dobrou, passou de

24.000 para 48.000 operações de leitura e escrita. O que era de se esperar, afinal o oMFS também

é considerado um sistemas de arquivos, o qual é acessado frequentemente pelos nós.

Visto que o oMFS ja foi um ponto extremamente relevante no quisito de carga do sistema,

ja era de se esperar que tivesse muita relevância (e peso) no quisito de rede. Mas quando foi posto

os dados no papel, ele surpreendeu. Durante os testes, a média da taxa de transferência de entrada

de dados no servidor foi de 850 Kbps e a de saída dados foi 845 Kbps.

5.3 Problemas Encontrados

A primeira tentativa que realizamos, resolvemos começar com o auxílio do cluster. O

servidor estava ligado já faziam alguns dias. Quando começamos a rodar o teste, tudo esta saindo

com o planejado. Os processos estavam migrando normalmente e o nós estavam comunicando

corretamente com o servidor. Quando começamos a monitorar os dados dos nós, o servidor travou.

Após o servidor ter reiniciado, foi verificado os registros (logs) do sistema mas nada parecia

estar errado. Quando fomos checar os nós, descobrimos que o Thin Client havia travado devido

sobrecarga na memória. O programa que fica coletando os dados dos nós do cluster (o qual só é

realmente útil no servidor) consumiu toda a memória disponível.

Desabilitamos então o sistema de coleta de dados dos nós. Aproveitando, desabilitamos

também o sistema de arquivos oMFS dos nós, afinal, o mesmo só é utilizado pelos nós que migram

seus processos para outros. O que não é o caso dos nós.

Com os devidos ajustes feitos reiniciamos a bateria de testes. Assim como o primeiro tudo

39

corria bem, até travar novamente. O Servidor travou de vez. Reiniciamos ele e voltamos a checar

os registros do sistema. Ao que parece estavam ocorrendo problemas de comunicação com o Rich

Client, ele não retornou alguns processos vitais da interface gráfica. Mas o motivo, não estava

claro.

Após algumas horas de intensa concentração em cima do problema e nenhum resultado,

irritados (com o problema) e injuriados (pelo calor) resolvemos ligar o ar condicionado. Foi onde

nosso problemas acabaram. Realmente estávamos lidando com problemas de hardware. Pagamos

o preço pela reciclagem da "sucata". Daí por diante, tudo correu bem.

5.4 Considerações Finais e Trabalhos Futuros

Durante outros testes realizamos experiências do tipo ShutDown. Ou seja, durante o fun-

cionamento do cluster desligamos os computadores. Os computadores que possuiam ACPI (Ad-

vanced Configuration and Power Interface) ao executarem os procedimentos de saída, expulsavam

(expurgavam) os processos recebidos para o nó original (o servidor) e desligavam sem causar pro-

blemas para com o cluster. Mas aqueles que não possuiam nenhum tipo de Power Management

simplesmente desligavam e comprometiam todo o cluster. Muitas vezes travavam o servidor. Por

este motivo devo consideramos o projeto um tanto inviável, pois o usuário pode travar com todo o

sistema com o apertar de um botão.

Apesar dos dados terem sido positivos, acredito que a falta de um ambiente industrial (por

assim dizer) contribuiu em muito para os mesmos. Por este motivo o proximo passo do trabalho

será montar o mesmo em um cenário mais realista, utilizando um Switch Gerenciavel 10/100, boot

via PXE e no mínimo 24 nós e usuarios utilizando estes ao mesmo tempo. Deixe de legado para

quem continuar este trabalho um conselho e insentivo, se conseguir compilar (com o kernel 2.6) e

fundir o projeto ThinStation com o mesmo, milhares de usuários serão eternamente gratos. Pois aí

sim qualquer usuário leigo poderá ter um cluster HPC em sua casa.

Capítulo 6

Referências Bibliográficas

MAIA, Luiz F. J. Fragmentos da História da computação. Lages: Faculdade de Ciência da

Computação, Sociedade Lageana de Educação, 1999.

BRANCO, M. O caso a Rede Escolar e da Uergs. 2002. Acesso em 27/07/2006. Dispon-

nível em: http://www.softwarelivre.org/articles/54/print

LINUX Terminal Server Project. Acesso em 27/07/2006. Dispon?vel em: http://www.ltsp.org

PERRY,Alexander. Clusters for Nothing and Nodes for Free. Acesso em 31/07/2006 Dis-

ponível em: http://delivery.acm.org/10.1145/1010000/1005578/7185.html

FROM a single PC to Terminals and Servers. Acesso em 28/07/2006. Disponível em:

http://wiki.ltsp.org/twiki/bin/view/Ltsp/XServersAndXclients

Pros of openMosix. Acesso 29/07/2006 Disponível em: http://www.tldp.org/HOWTO/openMosix-

HOWTO/x229.html

BUYTAERT, Kris. The openMosix HOWTO. Acesso 29/07/2006 Disponível em: http://www.tldp.org/HOWTO/openMosix-

HOWTO/

TREZENTOS, Paulo. Contribuições para o Glossário da Sociedade de Informação . Acesso

30/07/2006 Disponível em: http://paulo.trezentos.gul.pt/artigos/ContribuicoesGlossarioAPDSI/

LOTTIAUX Renaud. GALLARD, Pascal. OpenMosix, OpenSSI and Kerrighed: A Com-

parative Study. Acesso em 31/07/2006 Disponível em: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1558672

OpenMosix . Acesso 30/07/2006 Disponível em: http://pt.wikipedia.org/wiki/OpenMosix

OpenMosix . Acesso 30/07/2006 Disponível em: http://en.wikipedia.org/wiki/OpenMosix

Cluster. Acesso 30/07/2006 Disponível em: http://pt.wikipedia.org/wiki/Cluster

LTSP-MOSIX. Acesso 30/07/2006 Disponível em: http://www.femto-st.fr/ daniau/ltsp-

mosix/

41

DHCP. Acesso 30/07/2006 Disponível em: http://en.wikipedia.org/wiki/DHCP

DHCP. Acesso 30/07/2006 Disponível em: http://pt.wikipedia.org/wiki/DHCP

TFTP. Acesso 30/07/2006 Disponível em: http://pt.wikipedia.org/wiki/TFTP

Trivial File Transfer Protocol. Acesso 30/07/2006 Disponível em: http://en.wikipedia.org/wiki/TFTP

Linux Terminal Server Project (LTSP) . Acesso 30/07/2006 Disponível em: http://pt.wikipedia.org/wiki/LTSP

X display manager. Acesso 30/07/2006 Disponível em: http://en.wikipedia.org/wiki/XDMCP

BAR, Moshe [et. Al.], Introduction to openMosix[online], Edição em Adobe Acrobat PDF,

2003, Acesso em 15/03/2006. Disponível em: http://openmosix.sourceforge.net/linux-kongress_2003_openMosix.pdf

Computer Cluster. Acesso 30/07/2006

Disponível em: http://en.wikipedia.org/wiki/Computer_cluster