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

Transcrição

1 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

2 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.

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

4 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.

5 Sumário Sumário Lista de Figuras Resumo Abstract v vii viii ix 1 Objetivos Objetivos Específicos Introdução Servidor de Terminais Terminais Leves Clusters Grids Estado da Arte e Motivações Terminais Leves openmosix Exemplificação Vantagens Desvantagens Metodologia Sobre o Hardware Sobre a Rede Sobre o Linux e o openmosix

6 vi Configuração do openmosix Sobre as ferramentas de monitoração Sobre os Testes Resultados Dados Obtidos Teste Sem openmosix Teste com openmosix Análise dos Dados Problemas Encontrados Considerações Finais e Trabalhos Futuros Referências Bibliográficas 40

7 Lista de Figuras 3.1 omfs - openmosix Filesystem Rich Client CluxtMaxter - Servidor do Cluster openmosixview openmosix Migration Monitor Memória Livre do Servidor Número de Processos no Sistema Carga do Média do Sistema (a cada minuto) Carga do Média do Sistema (a cada 5 minutos) Numero de Operações de Escrita e Leitura 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 Média do Sistema (a cada minuto) Carga do Média do Sistema (a cada 5 minutos) Lista de Processos Migrados Memória Livre do Servidor Memória Total Utilizada no Cluster Número de Processos no Sistema Número de Operações de Escrita e Leitura Entrada de Rede Saída de Rede

8 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.

9 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.

10 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.

11 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

12 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.

13 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 conjunto 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

14 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." 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ádio- Telescó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.

15 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é-

16 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 clusterizaçã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.

17 Figura 3.1: omfs - openmosix Filesystem 8

18 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 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 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-

19 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.

20 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 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.

21 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 (1.494 MHz)

22 13 Cache Size KB Memória MB Rede - SiS baseTx-FD Rich Client Processador - Petium II 350 MHz Cache Size - 512KB Memória 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

23 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 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

24 Sobre as ferramentas de monitoração O openmosix possui uma série de ferramentas de monitoração própria. Dentre elas utilizamos 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

25 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).

26 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 com janela 01 do navegador. Entraria no site com janela 02 do navegador. Entraria no site webmail.inf.ufsc.br com janela 03 do navegador e logaria entraria em sua conta.

27 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.

28 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.

29 Capítulo 5 Resultados 5.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

30 Figura 5.2: Número de Processos no Sistema 21

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

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

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

34 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

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

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

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

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

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

40 Figura 5.12: Lista de Processos Migrados 31

41 Figura 5.13: Memória Livre do Servidor 32

42 Figura 5.14: Memória Total Utilizada no Cluster 33

43 Figura 5.15: Número de Processos no Sistema 34

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

45 Figura 5.17: Entrada de Rede 36

46 Figura 5.18: Saída de Rede 37