veja o trabalho - Projetos

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO 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 considerarem 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
1
2
3
4
Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introdução
2
2.1
Servidor de Terminais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.2
Terminais Leves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4
Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
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
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
5
4.4
Sobre as ferramentas de monitoração . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5
Sobre os Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Resultados
5.1
6
Configuração do openMosix . . . . . . . . . . . . . . . . . . . . . . . . . 14
20
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
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 usufruindo 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 leves 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 processamento 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 funcionamento.
• 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 utilizados 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 Universidade 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 deliberadamente 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 (praticamente) qualquer sistema operacional pode acessar um ambiente gráfico de outro sistema operacioná 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 enviados 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 notouse 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 possuem Disco Rígido (Hard Disk HD). Desta forma, eles buscam seu Sistema Operacional da unidade 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 especial (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 partir 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 computacional 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 diferentes computadores ligados em rede (geralmente a Internet) para resolver problemas computacionais de grandes escalas (Ex. Cura do Câncer, Previsão do Tempo, Análise de sinais de RádioTelescópios, etc). Diferentemente dos Clusters, esta provê a habilidade de computar grandes escalas 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 Operacional, 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, possibilitando 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 capilares, 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 Centers 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 disponibilidade 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 processador/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 funcionalidades 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 openMosix) 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 computador 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 namorada 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 servidor. 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 processos 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 openMosixprocs. Foi utilizado também o Zabbix, ferramenta a qual não esta atrelada ao projeto openMosix.
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 backend 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 outro 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 seguintes 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
5.1.1
Dados Obtidos
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 (Advanced 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 problemas 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. Disponní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 Disponí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/openMosixHOWTO/x229.html
BUYTAERT, Kris. The openMosix HOWTO. Acesso 29/07/2006 Disponível em: http://www.tldp.or
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=
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/ltspmosix/
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/w
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_open
Computer Cluster. Acesso 30/07/2006
Disponível em: http://en.wikipedia.org/wiki/Computer_cluster