Cluster Set

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS COLEGIADO DO CURSO DE CINCIA DA COMPUTAO
Alex Yuichi Yokokura
Estudo de Viabilidade da Implantao de Tcnicas de Cluster ao Projeto Servidor de Estaes de Trabalho (SET)
Belm 2005
Trabalho
de
Concluso
de
Curso
apresentado para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Msc. Raimundo Vigas Jnior
Belm 2005
Trabalho de Concluso de Curso
apresentado para obteno do grau de Bacharel em Cincia da Computao. Data da defesa: 4 de fevereiro de 2005 Conceito: Banca Examinadora
Prof. Msc. Raimundo Vigas Jnior Depto. de Informtica / UFPA Orientador
Prof. Dr. Antnio Jorge Gomes Abelm Depto. de Informtica / UFPA Membro
Prof. Dr. Eloi Luiz Favero Depto. de Informtica / UFPA Membro
Belm 2005
Aos meus avs, Shigeru e Chie. minha me Terezinha e tia Iracema. minha namorada, Shirlene.
AGRADECIMENTOS
Em primeiro lugar a minha me e tia, Terezinha e Iracema, pela minha formao como cidado, bem como pelo incentivo nos momentos mais difceis de minha vida, e aos meus avs, Shigeru e Chie, que acreditam em meu potencial e que muito lutaram para criar a nossa famlia.
Agradeo minha namorada, Shirlene, por tudo que vivemos nos ltimos cinco anos, e sobretudo ao seu companheirismo, amor e apoio psicolgico para o desenvolvimento deste trabalho.
Ao Prof. Msc. Raimundo Vigas, amigo e orientador do trabalho, que sempre acreditou em meu potencial e que depositou sua confiana em mim no desenvolvimento deste trabalho.
todos os amigos e amigas da universidade, especialmente para Glauco, Ulisses, Ailto, Jess, Mrio, Vanderlene e Danielle, pelos momentos que convivemos durante os cinco anos de curso.
Uma meno em especial ao meu grande amigo Pedro Paiva ("Insano") pelo apoio e confiana.
RESUMO
Atualmente, diversas instituies de ensino pblicas ainda adotam laboratrios de informtica da maneira tradicional, onde cada computador possui seus recursos computacionais como discos rgidos, memria e processador de forma local. Entretanto, uma nova maneira de construir esses laboratrios vem chamando a ateno, a qual reduz os componentes existentes nos computadores. Tal construo foi denominada de Computador Popular de Rede (CPR), e vem sendo empregada com sucesso na Universidade Federal do Par (UFPA) por meio do Projeto Servidor de Estaes de Trabalho (SET). Nessa arquitetura, todo poder de processamento fica centralizado em um servidor de aplicaes, o qual prov os recursos computacionais s estaes de trabalho de caractersticas limitadas. Porm, essas estaes fazem pouco uso do processador. Com o aparecimento de novas tcnicas na construo de cluster de computadores, surge a oportunidade de aproveitar os recursos de processamento disponveis nas estaes de trabalho. Nesse contexto, o presente trabalho desenvolve um estudo de viabilidade no emprego dessas novas tcnicas de processamento distribudo ao projeto, pois introduz conceitos relativos s arquiteturas paralelas apresentando tecnologias envolvidas em agregados de computadores e descrevendo essa nova estrutura acompanhada de seus devidos resultados de desempenho, a fim de que se possa empregar com vantagens em futuras implantaes de laboratrios de informtica na UFPA. PALAVRAS-CHAVE: Arquitetura Paralela, Cluster, Computao de Alto Desempenho, Laboratrio de Informtica, Software livre.
ABSTRACT
Currently, diverse institutions of public education still use laboratories of computer science in the traditional way, where each computer possess its computational resources as disk, memory and processor of local form. However, a new way to construct these laboratories comes recently calling the attention, which reduces the existing components in those computers. Such construction was called Computador Popular de Rede (CPR), and comes being employed in the Universidade Federal do Par (UFPA) by means of the Project Servidor de Estaes de Trabalho (SET). In this architecture, all power of processing is centered in a server of applications, which provide the computational resources to the workstations of limited characteristics. However, these workstations make little use of the processor. With the appearance of new techniques in the construction of cluster of computers, appears the chance to use the available resources of processing in the computers. In this context, the present work develops a feasibility study of these new techniques of cluster to the abovementioned project, therefore: it enumerates relative concepts in parallel architectures, presents the involved technologies in aggregate of computers and describes this new structure in cluster followed of its results of performance, so that can be use in future implantations of computer science laboratories in UFPA. KEY WORDS: Parallel Architecture, Cluster, High Performance Computing, Computer Science Laboratory, Free Software.
LISTA DE FIGURAS
Figura 1.1 Supercomputador CRAY-1 ..................................................................... 16 Figura 1.2 Cluster class Beowulf ............................................................................. 18 Figura 2.1 Arquitetura SISD .................................................................................... 21 Figura 2.2 Arquitetura MISD .................................................................................... 21 Figura 2.3 Arquitetura SIMD .................................................................................... 21 Figura 2.4 Arquitetura MIMD ................................................................................... 22 Figura 4.1 Esquema de Alta Disponibilidade .......................................................... 26 Figura 4.2 Exemplo de cluster de balanceamento de carga ................................... 27 Figura 4.3 Comparativo utilizando channel bonding ............................................... 30 Figura 4.4 Interface Myrinet .................................................................................... 32 Figura 4.5 Interface SCI .......................................................................................... 33 Figura 4.6 Arquitetura de uma MPP ........................................................................ 34 Figura 4.7 Arquitetura de mquina com DSM ......................................................... 35 Figura 4.8 Arquitetura de um NOW ......................................................................... 35 Figura 4.9 Estrutura de um COW ............................................................................ 37 Figura 5.1 Arquitetura do Projeto SET .................................................................... 40 Figura 6.1 Exemplos de processo local e processo remoto .................................... 48 Figura 6.2 Tela principal do openMosixview ........................................................... 52 Figura 6.3 Janela de configurao de um n .......................................................... 52 Figura 6.4 Janela de gerenciamento de processos ................................................. 53 Figura 6.5 Informaes inerente a um processo ..................................................... 54 Figura 6.6 Histrico com a ferramenta openMosixanalyzer .................................... 54 Figura 6.7 Histrico dos processos executados ...................................................... 55 Figura 6.8 Migrao de processos com openMosixmigmon ................................... 55 Figura 7.2 Imagem landscape gerada pelo POVRay .............................................. 61 Figura 7.4 Imagem benchmark gerada pelo POVRay ............................................. 62
LISTA DE GRFICOS
Grfico 7.1 Tempo de codificao para 3 arquivos de udio .................................. 59 Grfico 7.3 Tempo de renderizao da imagem landscape .................................... 61 Grfico 7.5 Tempo de renderizao da imagem benchmark ................................... 62
LISTA DE TABELAS
Tabela 1 Configurao do servidor SET no laboratrio do SECOM ....................... 43 Tabela 2 Configurao das estaes de trabalho no laboratrio do SECOM ......... 44 Tabela 3 Configurao do micro da arquitetura AMD ............................................. 58 Tabela 4 Configurao da primeira estao da arquitetura Intel ............................. 58 Tabela 5 Configurao da segunda estao da arquitetura Intel ............................ 58
SUMRIO
1 Introduo .............................................................................................................. 12 1.1 Objetivos .............................................................................................................. 13 1.2 Organizao do Trabalho ..................................................................................... 13 2 Histrico da Supercomputao ........................................................................... 14 2.1 Evoluo das Arquiteturas Paralelas ................................................................... 14 2.2 Surgimento dos Clusters de Computadores ......................................................... 17 2.2.1 O Cluster Beowulf ............................................................................................. 17 2.2.2 O Projeto openMosix ......................................................................................... 19 3 Introduo s Arquiteturas Paralelas .................................................................. 20 3.1 Classificao de Flynn ......................................................................................... 20 3.1.1 Arquitetura SISD ............................................................................................... 20 3.1.2 Arquitetura MISD ............................................................................................... 21 3.1.3 Arquitetura SIMD ............................................................................................... 21 3.1.4 Arquitetura MIMD .............................................................................................. 22 3.2 Unidades de Medida ............................................................................................ 23 3.3 Granularidade ...................................................................................................... 23 4 Cluster de Computadores ..................................................................................... 25 4.1 Conceito ............................................................................................................... 25 4.2 Tipos de Cluster ................................................................................................... 25 4.2.1 Alta Disponibilidade ........................................................................................... 26 4.2.2 Balanceamento de Carga .................................................................................. 26 4.2.3 Alta Performance .............................................................................................. 27 4.3 Componentes ....................................................................................................... 28 4.4 Sistema Operacional GNU/Linux ......................................................................... 29 4.5 Tecnologias de Redes ......................................................................................... 29 4.5.1 Ethernet e Fast-Ethernet ................................................................................... 29 4.5.2 Myrinet .............................................................................................................. 31 4.5.3 Scalable Coherent Interface (SCI) .................................................................... 32 4.6 Tendncias na Construo de Clusters ............................................................... 33 4.6.1 Mquinas Maciamente Paralelas (MPP) ......................................................... 33 4.6.2 Distributed Shared Memory (DSM) .................................................................... 34
4.6.3 Redes de Estaes de Trabalho (NOW) ........................................................... 35 4.6.4 Mquinas Agregadas (COW) ............................................................................ 36 4.7 Consideraes de Projeto .................................................................................... 37 5 O Projeto Servidor de Estaes de Trabalho (SET) ........................................... 39 5.1 Arquitetura ............................................................................................................ 39 5.2 Vantagens e Desvantagens ................................................................................. 41 5.3 Objetivos .............................................................................................................. 42 5.4 Estudo de Caso .................................................................................................... 43 5.5 Consideraes sobre o Projeto ............................................................................ 44 6 Utilizao de Tcnicas de Cluster no Projeto SET ............................................. 45 6.1 Tecnologia openMosix ......................................................................................... 46 6.1.1 Algoritmos de Compartilhamento de Recursos ................................................. 47 6.1.2 Migrao de Processos ..................................................................................... 48 6.1.3 Acesso a Arquivos ............................................................................................ 49 6.2 Vantagens e Desvantagens do openMosix .......................................................... 50 6.3 Software de Gerenciamento ................................................................................. 51 6.3.1 openMosixview .................................................................................................. 51 6.3.2 Gerenciando Processos .................................................................................... 53 6.3.3 Histrico de Utilizao ...................................................................................... 54 6.3.4 Monitorando Migraes ..................................................................................... 55 7 Testes de Desempenho no Cluster ...................................................................... 57 7.1 Ambiente de Testes ............................................................................................. 57 7.2 Procedimentos e Tcnicas ................................................................................... 58 7.3 Testes e Resultados ............................................................................................. 59 7.3.1 FLAC (Free Lossless Audio Encoder) ............................................................... 59 7.3.2 POVRay (Persistence of Vision Raytracer) ....................................................... 60 8 Consideraes Finais ........................................................................................... 63 9 Trabalhos Futuros ................................................................................................. 64 9 Referncias Bibliogrficas ................................................................................... 65 ANEXOS .................................................................................................................... 68
1 Introduo
Atualmente, diversos laboratrios informtica ainda so concebidos segundo o modelo de computadores pessoais, ou seja, vrios computadores autnomos e independentes, onde cada um possui disco, memria, processador, entre outros componentes necessrios. Entretanto, um novo paradigma tem surgido, o conceito de estaes leves, onde faz-se uso de diversos computadores sem a necessidade de discos para armazenamento dos dados. Na Universidade Federal do Par, esse conceito j uma realidade. Por meio do Projeto Servidor de Estaes de Trabalho (SET), conseguiu-se aplicar este novo conceito e reduzir os custos dos laboratrios de informtica. Alm do fator financeiro, diversas vantagens foram incorporadas como manuteno facilitada, minimizao dos problemas de vrus, administrao centralizada, entre outros mais. No entanto, percebeu-se que nesses novos laboratrios de informtica, os microcomputadores adquiridos como estaes de trabalho, possuam um poder de processamento considervel, mas que ficavam ociosos em virtude da soluo concentrar todo o processamento no servidor. Caso o servidor sofresse uma alta carga de processamento, a queda de desempenho seria percebida imediatamente pelo usurio do sistema. Em razo do problema exposto que o presente trabalho tenta desenvolver uma soluo que consiga minimizar essas altas cargas de processamento do servidor. Para tal, necessrio um sistema que seja capaz de balancear a carga de processamento do servidor entre os processadores das estaes de trabalho. Aliado aos objetivos do Projeto SET, principalmente no que tange ao uso de softwares livres e na adoo de solues de baixo custo, encontrou-se uma implementao adequada para ser integrada, a qual denominada de openMosix. Tal soluo permite a construo de um sistema de alta performance baseado em um conjunto de microcomputadores genricos, como o caso do SET. Seu principal atrativo o mecanismo de migrao de processos, por onde consegue-se equilibrar a carga entre os micros de modo que se consiga executar mais processos do que normalmente se conseguiria com um nico processador isolado.
13
1.1 Objetivos
O objetivo principal do presente trabalho apresentar um estudo de viabilidade envolvendo a implementao do openMosix sobre a arquitetura SET. Busca-se conseguir construir um ambiente de cluster para tal arquitetura, proporcionando ganhos de desempenho com o uso dos ciclos de processamento ociosos das estaes de trabalho. Aps a implementao do cluster SET, tambm faz se necessrio a adoo de um software capaz de gerenciar, monitorar e prover relatrios de uso do sistema. Portanto, inclui-se ainda a apresentao de um software especfico para o openMosix. Por fim, para atingir o objetivo desse trabalho, adotou-se ferramentas adequadas para realizar os testes de desempenho que comprovem se soluo adequada para o SET ou no.
1.2 Organizao do Trabalho

Este trabalho composto de vrias partes que consistem em apresentar o estudo das arquiteturas paralelas e do estudo de viabilidade de implementao destas tcnicas ao Projeto SET. No segundo captulo realizado uma busca pelo desenvolvimento da supercomputao at chegar aos atuais cluster de computadores. A evoluo das arquiteturas de computadores e o surgimento de novas tcnicas na computao, so alguns dos assuntos contidos nesta parte. No terceiro captulo h uma pequena introduo aos conceitos de arquiteturas paralelas. Para o quarto captulo so reservados diversos assuntos sobre a construo de cluster de computadores. No quinto captulo, apresentado o Projeto Servidor de Estaes de Trabalho, uma soluo alternativa para construo de laboratrios de informtica de bom desempenho e baixo custo. O sexto captulo dedicado para descrio do funcionamento do cluster openMosix integrado ao Projeto SET, bem como para apresentao de sua ferramenta de gerenciamento. Para o oitavo captulo, documentado os principais testes realizados para aferir o desempenho na nova arquitetura. Por fim, as consideraes finais referentes ao trabalho desenvolvido, acompanhados de possveis trabalhos futuros.
14
2 Histrico da Supercomputao
Na primeira gerao de computadores, foi onde se estabeleceram conceitos bsicos de organizao de computadores eletrnicos. Na dcada de 50, surgia ento o modelo base de toda a computao, conhecido como modelo da "mquina de von Neumann". (PITANGA, 2004, p.1) A mquina de von Neumann consistia, basicamente, de trs componentes: um processador, memria e dispositivos de entrada e sada de dados. O processador o elemento que possui ainda, em sua estrutura, unidade lgico-aritmtico e unidade de controle. Todas as instrues so executadas de forma seqencial pelo processador, obedecendo-se a ordem definida pela unidade de controle deste. Baseada nesta arquitetura bem simples, a evoluo das tecnologias de fabricao de mquinas monoprocessadas conseguiam atender perfeitamente demanda de processamento durante as dcadas de 50 e 60. A partir dos anos 70, a tecnologia dos monoprocessadores comeavam a apresentar os seus primeiros sinas de escassez de poder computacional, tornando-se necessrio o desenvolvimento de tcnicas de concorrncia para conseguir obter o desempenho requerido. Tais tcnicas nada mais eram que a execuo de tarefas em paralelo, tornando o processador o mais independente possvel. Embora a velocidade do hardware tendesse a crescer, sempre esbarrava no custo elevado de produo e no limite da capacidade tecnolgica. Como as exigncias sobre os computadores crescem mais rpido que a sua velocidade de operao, a soluo para o problema estava no emprego de vrios processadores operando de forma conjunta para obteno de uma maior capacidade de processamento. nesse momento que surge o termo Processamento Paralelo, o qual visa implementar diferentes tcnicas de concorrncia para elevar a velocidade de processamento.
2.1 Evoluo das Arquiteturas Paralelas

O desenvolvimento dessas arquiteturas levou construo de mquinas especializadas em realizar grandes quantidades de operaes por segundo. Estes computadores que proporcionavam um maior desempenho na resoluo de
15 problemas eram denominados de Supercomputadores. Essa rea tambm era conhecida como Processamento de Alto Desempenho (PAD), ou, em ingls, High Performance Computing (HPC). Entretanto, a rea de processamento paralelo j no era novidade, pois em 1920, Vanevar Bush, do MIT (Massachussets Institute of Technology), apresentava o primeiro computador com capacidade de resolver problemas em paralelo, mas especificamente para problemas de equaes diferenciais. (DE ROSE, 2003, p.1) Em seguida, surgiu o UNIVAC 1, a primeira mquina a implementar o paralelismo do tipo sobreposio. Tal tcnica consistia em sobrepor as operaes de execuo de programas com as operaes de entrada e sada, obtendo assim um ganho de velocidade nas execues das operaes. At ento, o fator da velocidade dos computadores dependia
principalmente da velocidade de execuo das instrues e da transferncia dos dados entre a memria e a CPU. Uma tcnica utilizada para acelerar essa transferncia dos dados foi empregada na mquina IBM 7094, a qual utilizava uma memria de 72 bits de largura e 32 bits para as instrues. Isso eliminava metade dos acessos memria na busca de instrues. (DE ROSE, 2003, p.2) A evoluo seguiu para o emprego de entrelaamento de memria nos computadores. Essa tcnica permite o acesso simultneo memria dividindo-se esta em diversos bancos, criando assim canais de acesso em separado, os quais permitem transferir dados simultaneamente. Posteriormente, surge o emprego das tcnicas de pipeline. Esta consiste na execuo de uma tarefa atravs da sua diviso em subtarefas, de forma que o conjunto destas equivalha execuo da tarefa original. Os pedaos da tarefa original so denominados de estgios. A cada vez que a tarefa passa para o prximo estgio, uma nova tarefa pode aproveitar-se do estgio anterior, conseguindo dessa forma um melhor aproveitamento do hardware existente. (DE ROSE, 2003, p.15) No obstante, surge ainda uma maneira de melhorar ainda mais a velocidade de transferncia de dados entre a memria e os processadores. Essa tcnica consiste em empregar pequenas memrias, bem mais rpidas que as comuns, de tal forma que funcionassem como uma rea de armazenamento temporrio entre a
16 CPU e a memria. Essas memrias bem mais velozes foram denominadas de memria cache. As tcnicas para conseguir maior desempenho continuavam a evoluir, e logo em seguida surgiram as Mquinas ou Processadores Vetoriais. Essas eram utilizadas para a resoluo de tarefas que demandavam grandes quantidades de processamento repetitivo em um conjunto de elementos individuais: os vetores. Surgia ento uma nova classe de instrues, as instrues vetoriais. Os primeiros exemplos dessas mquinas so o IBM 2938, o CDC STAR-100 e o TI-ASC. (DE ROSE, 2003, p.2) Diversas tcnicas, das citadas anteriormente, so usualmente utilizadas nos computadores seqenciais da atualidade. Entretanto, por mais que a evoluo continuasse, o problema da limitao de hardware de cada poca ainda persistia. Dessa forma, percebeu-se que a utilizao de paralelismo era necessrio. Uma forma de paralelismo foi o emprego de diversos elementos de processamento com suas respectivas memrias interconectadas, surgindo ento os primeiros computadores com mais de um processador. O marco inicial desta idia foi atingido pelo Illiac IV, composto de 64 processadores e que cujo projeto iniciou-se nos anos 60, mas que somente tornou-se operacional em 1972, sendo considerado o primeiro Supercomputador. (DE ROSE, 2003, p.3)
Figura 1.1 Supercomputador CRAY-1
Aps esse marco, nos anos 80, as mquinas consideradas como supercomputadores pertenciam a empresa de Seymour Cray. O primeiro a ser fabricado foi o CRAY-1 (apresentado na figura 1.1), em 1976, o qual era capaz de atingir picos de 133 Megaflops, ou seja, 133 milhes de clculos de ponto flutuante por segundo. Em 1985, a empresa lana o Cray-2, com mais poder de
17 processamento, 1.9 Gigaflops, alm de contar com um espao de endereamento de 2 Gigabytes. Tais supercomputadores so bastante utilizados em atividades como previso do tempo, fabricao de remdios, explorao de petrleo, programas espaciais, entre outros, pois exigem bastante processamento. (PITANGA, 2003, p.5) Diversas empresas, bem como institutos de pesquisas, desenvolveram vrios supercomputadores de arquitetura dedicada e otimizada para clculos cientficos. Entretanto, o custo de fabricao desses equipamentos eram elevados demais. Alm do custo, a falta de software adequado, como sistemas operacionais, linguagens de programao, dentre outros, fizeram com que diversas dessas mquinas paralelas fossem descontinuadas. Ento, em 1994, vrias fabricantes de hardware paralelo foram a falncia. (PITANGA, 2003, p.10)
2.2 Surgimento dos Clusters de Computadores

Nos anos 90, surgem as mquinas compostas por agregados de computadores, mais conhecidos como Clusters. Primeiramente, compostos por estaes de trabalhos, como os IBM SP2, para logo em seguida serem transformados em cluster de PCs (Computadores Pessoais). Estes agrupamentos so compostos por dois ou mais computadores que ficam interligados por meio de uma conexo, normalmente rpida, tornando-se assim, o conjunto, em uma unidade de processamento de alto desempenho (DE ROSE, 2003, p.3). Apesar da computao em cluster no ser uma novidade, tendo sua origem com o projeto SAGE (Semi-Automatic Ground Environment) da IBM, esta uma rea que vem se desenvolvendo em ritmo acelerado.
2.2.1 O Cluster Beowulf

No ano de 1994, a agncia espacial NASA necessitava de um equipamento que conseguisse processar na ordem de um gigaflop (bilhes de clculos em ponto flutuante por segundo). Esses tipos de equipamentos eram necessrios para realizar as vrias simulaes de partidas das naves espaciais, alm de outras diversas aplicaes de misso crtica. Na poca, os supercomputadores que possuam o nvel de desempenho requerido custavam muito caro, algo em torno de um milho de dlares. Isso era considerado um investimento muito alto para um pequeno grupo de
18 pesquisadores que precisavam deste equipamento. (PITANGA, 2003, p.35) Nesse mesmo perodo, era notrio o crescimento da capacidade computacional dos PCs. Foi o momento em que o mercado de PCs crescia e a preos relativamente bem mais acessveis. Sem contar que, em muitos casos, o desempenho desses computadores conseguia at mesmo sobrepor ao de diversas estaes de trabalhos dedicadas. Aliando o momento de crescimento dos computadores pessoais com as necessidades pela qual passavam na NASA, que os pesquisadores Thomas Sterling e Donald J. Becker decidiram criar uma estrutura composta por diversos computadores interligados. Eram 16 computadores, cada um dotado de microprocessadores 486DX4-100, utilizando o sistema operacional Linux e diversas bibliotecas para troca de mensagens. A esta arquitetura batizaram de Cluster Beowulf (exemplo na figura 1.2).
Figura 1.2 Cluster classe Beowulf
Ao utilizar as aplicaes cientficas, o cluster conseguiu atingir a marca de 70 megaflops. Uma valor relativamente alto se comparado com os supercomputadores comerciais disponveis naquela poca. O custo total da plataforma ficou por volta de U$ 50.000,00 (cinqenta mil dlares), o qual representava 10% do preo de uma mquina comercial de mesmo desempenho. (PITANGA, 2003, p.36)
19
2.2.2 O Projeto openMosix

Alternativamente ao cluster Beowulf, surge um sistema operacional distribudo denominado de Mosix (Multicomputer Operating System unIX). O projeto Mosix originrio da Universidade Hebrew em Jerusalm, Israel, sob coordenao do professor Amnon Barak. O projeto traz uma nova viso para a computao baseada em cluster, visto que este permite a construo de um sistema de alto desempenho utilizando-se componentes genricos. Alm disso, uma caracterstica notvel neste tipo de sistema que o crescimento do mesmo no introduz problema relacionado sobrecarga de desempenho. (PITANGA2, 2003, p.241) J o openMosix uma extenso do projeto Mosix, que surgiu devido a conflitos de opinies, entre os integrantes, sobre a licena que viria a ser adotada ao projeto Mosix. Diferentemente de seu antecessor, o openMosix foi licenciado sob a GPL. O projeto teve incio em fevereiro de 2002 e coordenado pelo Ph.D Moshe Bar, ex-integrante do projeto supracitado. Desde agosto de 2002, considerado um dos projetos mais ativos da comunidade de desenvolvimento opensource, sem falar que conta com patrocnio de diversas fabricantes de hardware como Intel, AMD, HP, entre outras.
20
3 Introduo s Arquiteturas Paralelas

Como foi apresentado no histrico, o processamento paralelo j vem sendo praticado h vrios anos em muitos sistemas. Inclusive, as mais avanadas tcnicas superescalares foram agregadas s diversas arquiteturas ao longo dos anos. Pode-se at mesmo concluir que, nos ltimos anos, ocorreu uma gradativa passagem das tcnicas empregadas nos Supercomputadores para dentro das arquiteturas dos microprocessadores. (DE ROSE, 2003, p.3) Apesar dessa evoluo, h alguns conceitos bsicos inerente arquiteturas paralelas, os quais precisam ser compreendidos. Para compreender melhor esses conceitos, precisamos ver inicialmente os modelos de arquiteturas segundo a classificao de Flynn.
3.1 Classificao de Flynn

Em 1972, Michael Flynn caracterizou diversos modelos de arquiteturas. Tais modelos foram concebidos segundo a relao entre o nmero de fluxos de dados e de instrues existentes em um dado instante, produzindo quatro classes: a) Single Instruction Single Data (SISD); b) Multiple Instruction Single Data (MISD); c) Single Instruction Multiple Data (SIMD); d) Multiple Instruction Multiple Data (MIMD).
3.1.1 Arquitetura SISD

Nesse modelo, as instrues so executadas uma por vez para cada dado em memria, como demonstra a figura 2.1. O fluxo de instrues alimenta a unidade de controle, a qual ativa o processador, que por sua vez, agir sobre um nico fluxo de dados. Os representantes desta categoria so os computadores monoprocessados como os computadores pessoais e estaes de trabalho.
21
Figura 2.1 Arquitetura SISD
3.1.2 Arquitetura MISD

Nessa classificao se enquadrariam as mquinas que executam mltiplas instrues, todas ao mesmo tempo, sobre um nico fluxo de dados (Figura 2.2). Entretanto, esta no possui nenhum representante, inclusive, Flynn duvidou que algum dia isso possa existir. (PITANGA, 2003, p.11).
Figura 2.2 Arquitetura MISD
3.1.3 Arquitetura SIMD

Nesse tipo de arquitetura, a unidade de controle gerencia os vrios processadores, enviando para cada um deles a mesma instruo. Todas as instrues so executadas de forma paralela e sncrona sobre fluxos de dados distintos (Figura 2.3). Esta uma arquitetura bem especfica, onde se encaixariam os computadores vetoriais como o CRAY-1.
Figura 2.3 Arquitetura SIMD
22
3.1.4 Arquitetura MIMD

Em mquinas de arquiteturas MIMD, encontramos vrias unidades de controle, cada uma com seu respectivo processador. O fluxo de instrues recebidos pelas unidades de controle so repassados para sua unidade processadora para que seja executado. Assim, cada processador executa seu prprio programa sobre fluxos de dados distintos de forma assncrona (Figura 2.4). Enquadram-se nesta categoria os servidores com mltiplos processadores, cluster de computadores, redes de estaes, entre outras.
Figura 2.4 Arquitetura MIMD
A categoria MIMD, diferentemente das outras, engloba uma grande variedade de mquinas. Portanto, esta ainda pode ser subdividida em duas subclasses de acordo com o tipo de acesso a memria, se ela compartilhada ou distribuda. As mquinas com memria compartilhada so denominadas de multiprocessadores, enquanto que as de memria distribuda so ditas de multicomputadores. (DE ROSE, 2003, p.69) Os multiprocessadores possuem um espao de endereamento nico, o qual compartilhado por todos os processadores. Como exemplo de mquina para esta subclasse, pode-se citar os microcomputadores SMP (Symetrical Multiprocessors). J nos multicomputadores, cada computador tem sua prpria memria, e a comunicao entre os processadores dar-se- por meio da troca de mensagens. Uma rede de microcomputadores inteconectados atravs de um barramento Ethernet, um exemplo desta subclasse. Para cada uma dessas duas subclasses, ainda h uma subdiviso quanto ao tipo de arquitetura de rede, podendo ser uma ligao por barramento (bus) ou por chaveamento (switch). Em uma ligao por barramento, entende-se que existe uma
23 nica rede conectada por um cabo ou um meio que conecta todos os computadores. J em sistemas por chaveamento, existem diversas ligaes individuais de uma mquina para outra, com diferentes canais em uso. (DE ROSE, 2003, p.67)
3.2 Unidades de Medida

Em mquinas de alta performance, comum medir o desempenho atravs do nmero de instrues executadas em um perodo de tempo. Portanto, para medir a velocidade de mquinas paralelas, foi empregado a unidade denominada FLOPS. Assim como o MIPS representa milhes de instrues por segundo para um computador comum, o MFLOPS representa o nmero de milhes de operaes em ponto flutuante executadas por segundo em uma mquina paralela. No entanto, essa medida bastante imprecisa, pois o conjunto de instrues varia de mquina para mquina. A partir desse problema, pode-se concluir que a forma mais correta de medir o desempenho de uma mquina paralela seja executar programas padronizados. Essa tcnica conhecida como Benchmarking. (DE ROSE, 2003, p.8) Os Benchmarks so vrios programas que possuem um conjunto de testes, os quais so aplicados para medir o desempenho de computadores, analisando suas caractersticas de processamento e de movimentao dos dados. Atualmente, existem diversos programas conhecidos e empregados para realizar essas medidas, tais como LINPACK, NAS e SPEC. (DE ROSE, 2003, p.8)
3.3 Granularidade
A granularidade pode ser definida como a forma pela qual um programa executado em uma determinada arquitetura paralela. Por exemplo, alguns computadores paralelos so concebidos para rodar vrias tarefas independentes, de forma simultnea, sem a necessidade de comunicao entre eles. Uma outra forma, executar uma nica tarefa dividindo-se em diversos processos que executam simultaneamente, com o objetivo de obter mais velocidade na soluo do problema. Por fim, mquinas nas quais o paralelismo se manifesta por meio de um alto grau de processamento pipeline, os quais operam sobre a mesma instruo ao mesmo tempo.
24 Os trs exemplos, citados anteriormente, diferem no que denominado de granularidade. Quando se h vrios programas grandes em paralelo, com pouca ou nenhuma comunicao entre eles, costuma-se designar como paralelismo de granularidade alta (ou grossa). De forma oposta, est o tipo de paralelismo encontrado em sistemas de processamento vetorial, conhecido como paralelismo de granularidade baixa (ou fina). No entanto, essas denominaes referem-se a algoritmos e softwares, mas para complementar, h uma analogia direta com o hardware. Sistemas compostos de uma pequena quantidade de processadores grandes, independentes e com conexes de baixa velocidade so chamados de sistema fracamente acoplados. J aqueles que so compostos de processadores de pouca potncia computacional, fisicamente prximos e que interagem por meio de redes de comunicao de alta velocidade so chamados de sistemas fortemente acoplados. (TANENBAUM, 2000, p.316). Em certos problemas que envolvem o paralelimo de granularidade alta, podem rodar melhor em sistemas fracamente acoplados, ao passo que, em problemas com paralelismo de granularidade baixa rodam melhor em sistema fortemente acoplados. Essas diversas possibilidades de combinaes que levaram a uma grande variedade de arquiteturas. (TANENBAUM, 2000, p.316)
25
4 Cluster de Computadores
Grande parte do tempo, os computadores que utilizamos encontram-se ociosos, ou seja, sem nada para processar. Isso se deve, em grande parte, pelas aplicaes que estamos acostumados a utilizar, as quais normalmente esto aguardando por uma interao do usurio ou realizando tarefas de Entrada/Sada. Entretanto, tambm existem momentos em que o computador encontra-se bastante lento por estar executando uma tarefa que exige muito do processador, como a compilao de vrios programas. Em um contexto de se haver dois ou mais computadores, existe uma grande chance de que um deles esteja completamente ocupado e de que os outros estejam ociosos. A partir dessa premissa que os clusters de computadores podem ser utilizados, pois o objetivo dividir o processamento das aplicaes consideradas "pesadas" entre os diversos processadores que se encontram no estado ocioso.
4.1 Conceito
A definio de cluster pode ser resumida como sendo um conjunto de computadores autnomos e que interligados comportam-se como um nico sistema do ponto de vista do usurio. Ou seja, todos os aspectos relativos distribuio de tarefas, comunicao, sincronizao e organizao fsica do sistema devem ser abstrados do usurio. (PITANGA, 2003, p.17)
4.2 Tipos de Cluster

De acordo com o conceito, existem diversos tipos de solues que podem ser classificadas como clusters. Mas basicamente, existem trs tipos: alta disponibilidade, balanceamento de carga e alta performance. Em termos comerciais, o emprego das duas primeiras solues so mais comuns, enquanto que o ltimo mais utilizado para aplicaes cientficas, cujo objetivo de obter resultados em um menor tempo possvel.
26
4.2.1 Alta Disponibilidade

A Alta Disponibilidade est ligada diretamente a nossa crescente dependncia pelos computadores. Atualmente, diversas empresas contam com os recursos computacionais para proverem os seus servios, como e-business, sistemas bancrios, sites web, banco de dados, entre outros. Um cluster de Alta Disponibilidade tem como objetivo manter os servios prestados, por um sistema computacional, disponveis a todo momento, mesmo em caso de falhas. Isso conseguido atravs da criao de rplicas dos servios e servidores, onde os computadores agem como um nico sistema. Cada um monitora os outros por meio de software e, no caso de ocorrer uma falha, um deles assume os servios daquele que ficou indisponvel. (GARCIA, 2003).
Na estrutura apresentada pela figura 4.1, os Servidores so exatamente rplicas, tanto de hardware como de software. O Servidor da direita, atravs do esquema de monitoramento, detecta a indisponibilidade do Servidor da esquerda, e logo assume o posto para manter o servio disponvel.
4.2.2 Balanceamento de Carga

Esta soluo tem como objetivo manter o equilbrio de carga entre diversos servidores, garantindo assim a disponibilidade do servio em momentos de elevados acessos. A necessidade desta implementao devido a grande quantidade de trfego nos servidores que prestam servio em uma rede, pois, atualmente, um dos maiores problemas enfrentados na Internet so os excessivos acessos quando se tem apenas um servidor.
27 O sistema de cluster baseado em balanceamento de carga consiste em integrar seus computadores para que todas as requisies provenientes dos clientes sejam distribudas de maneira equilibrada entre os servidores. A tarefa principal redirecionar essas requisies de entrada por meio de um elemento que far o balanceamento entre os servidores e os usurios. Portanto, nessa estrutura teriam-se mltiplos servidores, mas que parecem ser somente um para o cliente (ver figura 4.2).
Este tipo de cluster especialmente utilizado em servios de comrcio eletrnico e provedores de Internet, que necessitam resolver diferenas de carga provenientes de mltiplas requisies de entrada em tempo real.
4.2.3 Alta Performance

Um dos objetivos dessa soluo a obteno de desempenho na execuo de aplicaes paralelas ou seqenciais. O ambiente computacional concebido para escalonar uma grande quantidade de tarefas a serem executadas de forma paralela. A finalidade principal de melhorar a utilizao dos computadores que possuem uma carga baixa de processamento, distribuindo as tarefas entre os ns para obter resultados no menor tempo possvel. Sua utilizao mais comum para resoluo de problemas tipicamente paralelos, ou seja, aplicaes desenvolvidas para processarem clculos de forma paralela. A grande vantagem desse sistema que ele pode ser visto como uma soluo alternativa para universidades e empresas de pequeno a mdio porte, pois o custo de aquisio de PCs, para construir um cluster, so relativamente baixos.
28
4.3 Componentes
Os principais componentes de um cluster de computadores so: a) Ns so os computadores que faro parte do agregado. Estes podem ser desde computadores pessoais at os computadores multiprocessados. b) Sistema operacional existem diversas alternativas como Windows 2000, FreeBSD ou NetBSD, GNU/Linux, dentre outros. O mais utilizado o GNU/Linux, o qual possui cdigo fonte aberto, permitindo assim realizar ajustes como o caso do projeto openMosix. c) Rede Local este um dos componentes que est diretamente ligado a performance do cluster. A placa de rede, o switch e o cabeamento so os responsveis pela transmisso e recebimento de pacotes entre os ns. Para se ter uma idia de sua importncia, existem tecnologias especialmente voltadas para computao de alto desempenho como Myrinet (MYRICOM, 2004) e SCI (DOLPHIN, 2004). d) Protocolos conjunto de regras e procedimentos para se efetuar uma comunicao de dados rpida e confivel entre os ns do cluster. O protocolo TCP/IP, apesar de no ser otimizado para tarefas deste tipo, o mais utilizado nesta rea, pois oferece menor custo de implantao. e) Sistema de arquivos o mais conhecido, e utilizado, sistema de arquivos o NFS (Network File System), mas existem diversas bibliotecas de interfaces a sistemas de arquivos paralelos para redes de estaes. Um exemplo o DFSA (Direct File System Access), utilizado pelo sistema openMosix. f) Ferramentas de comunicao importante um cluster tambm possuir ambientes de programao que ofeream meios para desenvolver programas paralelos, como o MPI (Message Passing Interface). g) Ferramentas de gerenciamento um conjunto de programas para realizar tarefas de monitoramento e gerenciamento de clusters, como o caso do openMosixview.
29
4.4 Sistema Operacional GNU/Linux

O GNU/Linux o sistema operacional mais utilizado em implementaes de clusters, graas a sua estabilidade e flexibilidade. A possibilidade de ter acesso e modificar o cdigo fonte tambm foram fundamentais para a adoo deste sistema como plataforma de desenvolvimento em agregados de computadores. O kernel Linux foi criado em 1991, por Linus Torvalds, estudante da Universidade de Helsinky na Finlndia. Seu projeto de construir um sistema operacional foi inspirado no Minix, um sistema Unix de pequeno porte desenvolvido por Andrew Tanenbaum. A idia era desenvolver um sistema operacional para mquinas de pequeno porte, de tal forma que conseguisse explorar os novos recursos dos processadores 80386 da poca. Atualmente, o kernel Linux possui milhes de linha de cdigo e conta com vrias pessoas do mundo inteiro no seu desenvolvimento, alm do apoio de grandes empresas como HP, IBM, Sun e outras. Devido a sua filosofia de desenvolvimento colaborativo, diversas funcionalidades foram incorporadas ao sistema, permitindo com que vrias arquiteturas, como Alpha e RISC, tambm fossem suportadas
4.5 Tecnologias de Redes

Durante os ltimos anos, notou-se um grande esforo para atingir um aumento de performance das redes para clusters, principalmente no que se refere reduo da latncia e o aumento da largura de banda. Sabe-se que a interconexo um ponto crtico para sistemas de agregados, j que a performance das LANs tradicionais no acompanham a dos processadores. Por isso que, tanto a indstria como a comunidade acadmica vm investindo em pesquisas e desenvolvimento de tecnologias de redes para clusters, das quais sero apresentadas as de uso mais comum neste tipo de estrutura.
4.5.1 Ethernet e Fast-Ethernet

O padro Ethernet foi bastante utilizado nas primeiras construes de clusters. Seu funcionamento consiste basicamente de um meio compartilhado, com banda passante de 10 Mbps, onde os computadores conectados competem entre si para ter acesso ao mesmo. Os dados somente eram enviados caso o meio estivesse
30 livre. No entanto, poderia ocorrer o problema da coliso de dados, a qual acontece quando duas mquinas tentam transmitir ao mesmo tempo os seus dados. Para evitar que tal situao ocorresse, foi ento criado um protocolo prprio ao padro para controlar o meio, denominado de CSMA/CD (Carrier Sense Multiple Access/Collision Detect). (TANENBAUM, 1997) Uma verso melhorada do mesmo padro, conhecida como Fast-Ethernet, fornece uma largura de banda de 100 Mbps sobre cabos de par tranado UTP ou fibra tica. Assim, a substituio do padro Ethernet para o Fast-Ethernet, aumentou consideravelmente a performance dos sistemas de agregados. Atualmente, esta a tecnologia mais utilizada em termos de redes locais de alta velocidade, pois o custo de implantao so relativamente baixos. Apesar do aumento da largura de banda do Fast-Ethernet, para alguns sistemas em clusters, ainda no era grande o suficiente para um canal de comunicao entre os ns. Portanto, para aumentar ainda mais a largura de banda, possvel utilizar uma tcnica especial chamada de Channel Bonding. Esta tcnica consiste em se agregar mltiplas redes e transform-las em uma nica rede com mais largura de banda, resultando em ganhos de velocidade para alguns clusters. (PITANGA, 2003, p.128)
Figura 4.3 Comparativo utilizando channel bonding. Fonte: PITANGA, 2004, p.128.
31 Observando a segunda linha, de baixo para cima (no grfico da figura 4.3), nota-se que o emprego da tcnica citada, com duas placas de rede, consegue obter o dobro de performance do que com apenas uma placa de rede. No entanto, para quantidades acima de dois, os ganhos j no so significativos. Atualmente, o estado da arte em tecnologia Ethernet o padro Gigabit Ethernet, o qual tambm est representado no grfico anterior. Este novo padro fornece uma largura de banda de 1 Gbps. Apesar do custo de implantao dessa nova tecnologia ainda ser elevado, este tende a se reduzir com o passar dos anos. Isso se deve, em grande parte, ao nmero de empresas concorrentes na produo desta tecnologia, impondo dessa forma preos mais competitivos.
4.5.2 Myrinet
A Myrinet uma rede de interconexo full-duplex com largura de banda de 1.28 Gbps e latncia nominal de 3s. Sua tecnologia proprietria, desenvolvida e comercializada pela empresa norte-americana Myricom, foi concebida para facilitar na construo de agregados, implementando-se uma rede de baixa latncia com placas PCI. Essas placas so conectadas em matrizes chaveadoras especficas, as quais implementam o protocolo de roteamento cut-through. O funcionamento deste protocolo de roteamento consiste em repassar, para o prximo n da rede, cada segmento de pacote a ser transmitido, diminuindo-se, assim, o atraso no envio da mensagem. (DE ROSE, 2003, p.88) Esta tecnologia, alm de ser considerada uma rede de alta velocidade, possui caractersticas desejveis como controle de fluxo nos canais de comunicao, controle de erro, baixa latncia, interfaces que podem mapear a rede, rotas selecionadas e tolerncia a falhas. As placas de rede ainda incluem um processador on-board que, alm de garantir a independncia da CPU, executa um programa de controle que mapeia e monitora a rede continuamente. A figura 4.4 apresenta uma interface de rede Myrinet.
32
Figura 4.4 Interface Myrinet Fonte: Diretrio de imagens do Google
Cabe ressaltar que esta tecnologia, alm de utilizar os protocolos de comunicao desenvolvidos pela prpria Myricom, tambm suporta o IP diretamente, sem nenhuma camada de adaptao, bem como todos os protocolos acima deste, tais como TCP e UDP. Devido sua elevada largura de banda, baixa latncia e escalabilidade, tal tecnologia mostra-se particularmente interessante para interligar PCs em clusters usados para aplicaes de computao paralela, bem como para aplicaes que demandam altas taxas de transferncia como imagens de alta resoluo e vdeo.
4.5.3 Scalable Coherent Interface (SCI)

SCI um padro especificado pela IEEE e que foi desenvolvido com o objetivo de prover um barramento de alta velocidade para a interligao de processadores em mquinas paralelas. A comunicao realizada atravs do acesso memria dos ns remotos por meio da implementao em hardware de uma memria distribuda compartilhada de baixa latncia e alta vazo. Isso permite a programao de aplicaes paralelas com o paradigma de memria compartilhada, o qual mais fcil se comparado com troca de mensagens. Sua estrutura consiste de ns interligados por conexes ponto-a-ponto que formam um anel unidirecional. Quando uma operao de escrita em memria remota ocorre, esta direcionada para a placa SCI da mquina origem, a qual encaminha a operao para a placa SCI da mquina destino atravs do anel. A vazo terica desse anel de 6.4 Gbps, entretanto, vale ressaltar que esse meio compartilhado por todas as operaes que circulam nele. (DE ROSE, 2003, p.134)
33
Figura 4.5 Interface SCI Fonte: Diretrio de imagens do Google
A figura 4.5 apresenta uma tpica interface SCI. A latncia dessas placas, teoricamente, fica em torno de 3s para operaes em memrias remotas. Apesar de toda essa tecnologia apresentar bons resultados, faz se necessrio um alto investimento, em virtude de seus componentes serem relativamente caros.
4.6 Tendncias na Construo de Clusters

Nesta seo, so apresentados alguns modelos fsicos que constituem atualmente as principais tendncias na construo de clusters de computadores. Cabe ressaltar que, segundo a classificao de Flynn, os modelos apresentados, a seguir, pertencem classe de arquiteturas MIMD.
4.6.1 Mquinas Maciamente Paralelas (MPP)

As mquinas maciamente paralelas, do ingls Massively Parallel Processors (MPP), so multicomputadores construdos com milhares de processadores comerciais conectados por uma rede proprietria de alta velocidade. A proposta dessas mquinas a obteno de alto desempenho atravs da utilizao de um grande nmero de processadores. Devido ao fator custo, esses processadores acabam sendo de poder computacional mdio ou pequeno. Nessa arquitetura, cada n possui sua memria local com um espao de endereamento prprio, no sendo possvel o acesso memria de ns vizinhos. Esta caracterstica faz com que essas mquinas sejam altamente escalveis, suportando inmeros processadores. Cada n comunica-se com o outro atravs da rede de interconexo por meio do adaptador de rede (AR). A figura 4.4 mostra a
34 organizao dessa arquitetura.
Como conseqncia dessa organizao, a comunicao nessas mquinas se d por meio da troca de mensagens. Este paradigma considerado de difcil programao, pois difere bastante do modelo de programao em sistemas tradicionais. (ROSE, 2003, p.119)
4.6.2 Distributed Shared Memory (DSM)

Este considerado um novo paradigma na computao paralela, onde, apesar da memria encontrar-se fisicamente distribuda atravs dos ns, todos os processadores conseguem acessar todas as memrias. O objetivo dessa tcnica agrupar a memria local de cada n do cluster, de forma a obter um nico espao de endereamento lgico para o sistema. Tal implementao pode ser desenvolvida tanto por hardware como por software, ou ainda, com a combinao dos dois. De forma semelhante a arquitetura MPP, os vrios ns possuem unidades de processamento (CPU) e memrias locais (MEM). O adaptador de rede (AR) o componente responsvel por interligar estes ns em uma rede de interconexo especfica. A diferena entre essa arquitetura e a mquina maciamente paralela est na possibilidade de acesso s memrias remotas e na utilizao de protocolos para coerncia de cache (ROSE, 2003, p.98). A figura 4.5 apresenta o modelo empregado em DSM. Uma grande vantagem nessa arquitetura quanto a programao, pois no necessita usar o paradigma da troca de mensagens. Assim, os programas tm acesso a memria compartilhada da mesma forma como se estivessem acessando variveis locais. (PITANGA, 2003, p.72)
35
4.6.3 Redes de Estaes de Trabalho (NOW)

So sistemas constitudos por vrias estaes de trabalho interligadas por uma rede tradicional, como Ethernet ou ATM. Do ponto de vista de uma arquitetura paralela, a rede local tambm pode ser uma mquina paralela, onde os vrios processadores com suas memrias locais, so interligados por uma rede de baixo custo. A diferena dessa arquitetura em relao a um MPP, consiste na existncia de uma hierarquia de barramento (utilizada nas estaes), na presena de discos locais em cada n e na tecnologia de rede adotada, como demonstra a figura 4.6. A principal diferena que a rede local foi concebida para fins de compartilhamento de arquivos e acesso a perifricos remotos como impressora, bem diferente daquelas que so construdas para execuo de aplicaes paralelas.
A estrutura hierrquica de barramento, utilizada nas estaes, serve para suportar um grande nmero de perifricos locais sem prejudicar o desempenho do processador. Como os perifricos so dispositivos lentos, estes so conectados a barramentos de E/S mais distantes do processador, que so acessados atravs dos adaptadores de barramento (AB). Os adaptadores de rede (AR) tambm so
36 conectados a estes barramentos de E/S. Entretanto, em uma mquina paralela, a rede tem papel fundamental para o desempenho, e esse acoplamento fraco do adaptador de rede implica em grandes perdas nas comunicaes entre os ns. Um outro problema que as redes tradicionais, como Ethernet e ATM, no so otimizadas para as operaes de comunicao de aplicaes paralelas. Apesar das dificuldades encontradas neste tipo de arquitetura, tal estrutura se mostra perfeita para ambientes de ensino e aprendizagem de processamento paralelo e distribudo, ou na execuo de aplicaes em que a comunicao entre os ns no seja to intensa.
4.6.4 Mquinas Agregadas (COW)

As mquinas agregadas, ou Cluster of Workstations (COW), assim como as NOW, tambm so constitudas por vrias estaes de trabalho interligadas, mas com a diferena de serem dedicadas para executar aplicaes paralelas. Como so mquinas otimizadas para esse fim, na maioria dos casos, os ns no possuem monitor, teclado e mouse, sendo denominadas de "estaes de trabalho sem cabea" ou headless workstation. O termo Pile-of-PC's tambm utilizado para denominar esta organizao de mquinas. Como as estaes no so utilizadas de forma local, vrias otimizaes podem ser realizadas nos softwares que sero instalados nestes computadores. Por exemplo, o sistema operacional pode ser "enxugado", removendo-se o suporte de dispositivos inexistentes e desabilitando servios desnecessrios s estaes. Outra forma de melhorar o desempenho simplificando as camadas de rede, pois as necessidades de mquinas paralelas so diferentes das necessidades em redes locais. Mas as otimizaes no ficam somente em software, a rede de interconexo tambm pode ser otimizada para esta arquitetura. Atualmente, existem duas tendncias: agregados interligados por redes padro (Ethernet) e agregados interligados por redes de baixa latncia (Myrinet, SCI, etc.). Por exemplo, para diminuir um pouco a latncia das redes padro, so empregados comutadores (switches) no lugar de hubs que funcionam como grandes barramentos. O principal
37 objetivo em agregados interligados por redes padro a obteno de desempenho com muitos ns no sistema e em aplicaes que demandam pouca comunicao. Os agregados interligados por redes de baixa latncia requer a aquisio de placas de interconexo especficas, cujos valores ainda so muito caros, o que dificulta na construo de um sistema constitudo por muitos ns. Portanto, para compensar o menor nmero de estaes, so utilizados, geralmente, computadores multiprocessados como n. O resultado uma estrutura mais equilibrada em termos de processamento e desempenho da rede, mesmo com aplicaes que necessitem de muita comunicao.
A figura 4.7 apresenta a organizao de uma arquitetura COW. A estrutura interna de cada n semelhante s arquiteturas NOW, j que se trata de uma evoluo do mesmo princpio. As principais diferenas ficam na rede de interconexo, que pode ser tanto uma rede padro como uma rede de baixa latncia, e nas estaes que podem ser multiprocessadas.
4.7 Consideraes de Projeto

Ao construir um cluster de alta performance e de fcil utilizao, devemos elaborar um projeto que leve em considerao alguns cuidados. Deve-se ter em mente que as aplicaes utilizadas sero o principal fator de muitas escolhas. Antes de adquirir os equipamentos, importante verificar o Espao Fsico onde ficar o cluster. Portanto, salas apropriadas, sistemas de refrigerao, instalaes eltricas adequadas e sistemas de energia ininterrupta so observaes importantes a serem consideradas. Como atualmente existe um grande nmero de modelos de processadores no mercado, devemos tomar o cuidado de realizar uma escolha adequada. Para tal, deve ser levado em considerao a capacidade de desempenho que ser exigida do
38 sistema, alm do oramento estabelecido para aquisio dos componentes. A Tecnologia de Rede tambm muito importante em um projeto, pois o elemento que determinar o desempenho de um cluster. Para projetos de pequeno a mdio porte, tecnologias de rede padro Fast Ethernet e Gigabit Ethernet costumam ser timas escolhas, graas ao seu baixo custo e facilidade de implantao. Tecnologias como Myrinet e SCI so mais adequadas para projetos de grande porte, em virtude da baixa latncia e melhor escalabilidade, entretanto, o custo dessas solues ainda so elevados. Como um dos objetivos na construo de clusters o baixo custo, o Sistema Operacional mais adequado para projeto deste tipo o GNU/Linux, mas isso no significa que outros sistemas no possam ser utilizados. As principais distribuies GNU/Linux adotadas so: Red Hat, Suse e Mandrake. Outras distribuies tambm podem ser selecionadas, mas o fator preponderante na escolha da distribuio, geralmente est relacionado com a facilidade de utilizao e suporte tcnico. Outra questo importante a escolha de um software para Troca de Mensagens, fornecendo suporte para o desenvolvimento de programas paralelos. O MPI, por exemplo, a biblioteca padro para clusters classe Beowulf, a qual encapsula a complexidade envolvida na comunicao entre os ns, alm de incluir protees para os diferentes mtodos de comunicao interprocessos. J o cluster openMosix trata esta questo de forma diferente, pois este cria um ambiente de balanceamento de carga e transferncia de processos entre os ns de forma totalmente transparente. Assim, tanto aplicaes paralelas como seqenciais conseguem obter, teoricamente, os benefcios de um cluster. Um ltimo ponto a se considerar a adoo de um software para Gerenciamento do Sistema, de tal forma que se possa controlar e balancear a atividade computacional entre os ns. Existem diversos programas para realizar estas tarefas, tanto solues comerciais como de cdigo aberto.
39
5 O Projeto Servidor de Estaes de Trabalho (SET)

Atualmente, h uma tendncia em se construir laboratrios de informtica atravs da aquisio de computadores com processamento, dispositivos de armazenamento, memria local e softwares proprietrios. Porm, o custo de implementao e manuteno de tal estrutura pode ser invivel para a maioria das instituies de ensino, principalmente as pblicas. Uma equipe de professores da Universidade Federal do Par (UFPA), ao perceberem essa dificuldade na montagem de laboratrios de informtica, buscaram uma alternativa para o problema, visando reduzir esse custo de montagem e manuteno. A partir da, nasceu o Projeto SET, que visa atender a uma demanda reprimida de laboratrios de informtica da UFPA. Este projeto apresenta uma soluo de baixo custo, tanto em termos de software como de hardware, para a implementao de laboratrios de computao e redes departamentais. As estaes de trabalhos utilizadas neste sistema possuem as mesmas funcionalidades de um computador pessoal, porm, sem disco rgido, sem perifricos (unidade de disquete e CD-ROM) e com pouca memria. Para tal estrutura de computador, denominou-se de Computador Popular de Rede (CPR). A utilizao dos softwares livres, na plataforma aberta GNU/Linux, tambm foram um dos fatores que proporcionou a reduo de custos da soluo. (VIGAS, 2004).
5.1 Arquitetura
A soluo tem como base a utilizao de um Servidor de Aplicaes com capacidade de processamento, memria e dispositivos de E/S (Entrada/Sada) superiores s de uma estao de trabalho comum. Esse servidor efetua a transferncia de um micro-kernel do sistema para as estaes tornarem-se operacionais pelos usurios. Com isso, todo o processamento necessrio pelas estaes so executados pelo Servidor. Uma vez liberadas do processamento pesado, as estaes de trabalho podem ter seu processador, memria e disco rgido reduzidos at um conjunto mnimo suficiente para operao.
40 Basicamente, o funcionamento das estaes de trabalho resume-se a:
Habilitar a placa de rede para inicializao do sistema operacional atravs de uma tcnica denominada de boot remoto (ETHERBOOT, 2004);
Obter o endereo IP (Internet Protocol) fornecido pelo Servidor e carregar uma cpia do micro-kernel do sistema operacional para inicializar a estao (ROM-O-MATIC, 2004);
Montar o sistema de arquivos dos usurios a partir do diretrio principal, utilizando o servio de montagem de diretrio (STERN, 2001);
Por fim, iniciar o servidor e o cliente grfico na memria principal; e execut-los, permitindo o acesso de forma autenticada (STEVEN, 2000). Na arquitetura concebida, o desempenho da soluo depende
principalmente do sistema operacional em conjunto com o hardware do Servidor. O sistema operacional deve ser capaz de alocar os recursos necessrios para a execuo da aplicao do usurio, bem como compartilhar esses recursos para a aplicao de um outro usurio, em suma, o sistema deve ser multiusurio e multitarefa. J as estaes de trabalho, para funcionarem adequadamente, precisam estar conectados na mesma rede do Servidor, alm de possurem as condies mnimas para executar uma instncia do servidor com cliente grfico. A figura 5.1 apresenta a estrutura do projeto SET.
Figura 5.1 Arquitetura do Projeto SET
41 Alm do servio de boot remoto, o servidor de estaes de trabalho configurado para disponibilizar um conjunto de servios de rede, de modo a proporcionar uma infra-estrutura completa para laboratrios de informtica. Alguns desses servios so: servidor web, ftp, dhcp, proxy, arquivos, autenticao, acesso remoto (ssh e VPN), banco de dados e impresso. (VIGAS, 2003) Alm dos softwares de rede, so instalados no Servidor um conjunto de aplicaes bsicas para um laboratrio de informtica, como navegador web, cliente de e-mail e pacote tipo Office. Vale ressaltar ainda a necessidade de outros aplicativos que devem ser instalados no Servidor, de acordo com a necessidade de cada curso. Uma caracterstica importante que todos os softwares utilizados na soluo so de natureza livre, ou seja, alm de gratuitos, so programas que permitem a adaptao dos cdigos de acordo com a necessidade.
5.2 Vantagens e Desvantagens

A utilizao de mquinas sem unidade de CD-ROM, dispositivos de armazenamento e capacidade de processamento prprio, pode parecer estranho para usurios acostumados com computadores domsticos, mas do ponto de vista administrativo algo que faz sentido. muito difcil gerenciar um laboratrio com dezenas de computadores pessoais completos. A vantagem principal desta soluo consiste no fator financeiro, pois os custos de suporte e configurao so drasticamente reduzidos. Existem tambm outras vantagens na adoo deste tipo de sistema, tais como: a) Baixo custo de aquisio dos equipamentos, visto que no mais necessrio o disco rgido e unidade de CD-ROM; b) A atualizao nas estaes praticamente desnecessria, pois os componentes mais importantes ficam localizados no servidor; c) Melhor aproveitamento dos recursos financeiros, podendo-se alocar despesas na aquisio de outros equipamentos necessrios para ensino; d) Segurana quanto ao armazenamento de dados dos usurios, uma vez que o dispositivo de armazenamento encontra-se no servidor de
42 aplicaes, polticas de backup podem ser facilmente empregadas e gerenciadas; e) Diminuio do problema de vrus, j que as estaes no possuem disco rgido, esta preocupao fica apenas para o servidor, ressaltando que atualmente no h relatos de vrus sobre o sistema operacional GNU/Linux; f) Reaproveitamento de computadores obsoletos, eliminando a
necessidade de aquisio de novas estaes de trabalho e reduzindo o custo de implantao dos laboratrios; g) Sem necessidade de administrao de softwares nas estaes, pois o controle do sistema est centralizado no servidor. Apesar da soluo agregar diversas funcionalidades interessantes, existem algumas desvantagens inerentes a este tipo de sistema. Uma delas que a soluo depende totalmente de uma boa infra-estrutura de rede, pois caso ocorra algum problema, as estaes de trabalho podero ficar inoperantes. Um outro problema quanto a sobrecarga ocasionada por aplicaes que demandam bastante poder computacional. Por exemplo, no momento em que vrios usurios estiverem utilizando as estaes de trabalho, sendo que um deles inicia um processo "pesado", todos sero penalizados com a queda de desempenho. Alguns exemplos de aplicaes deste porte so os Ambientes de Desenvolvimento Integrados (IDE) construdos na plataforma Java.
5.3 Objetivos
Dentre os diversos objetivos do projeto, podemos citar: a) Reduo do custo de implantao do projeto, atravs do reaproveitamento de mquinas clientes obsoletas e atualizao de hardware e software restrita ao servidor; b) Reduo dos custos com aquisio de licenas de software, preferindo a utilizao de programas livres e desenvolvimento em plataforma aberta;
43 c) Administrao centralizada do laboratrio, por meio de um sistema localizado somente no servidor; d) Implantao de laboratrios piloto, para criao de distribuies GNU/Linux especficas em cada rea da instituio (administrativa, docncia e alunos) com todos os aplicativos voltados para rea de interesse destes grupos; e) Divulgao e uso do pacote OpenOffice, em substituio ao Microsoft Office, com treinamento para os usurios e administradores da instituio; f) Padronizao de um ambiente informatizado, baseado em padres abertos de software.
5.4 Estudo de Caso

Atualmente, o SET possui um projeto piloto em um dos laboratrios de informtica do SECOM (Servio de Computao), na Universidade Federal do Par. Inicialmente, foram utilizados softwares para acesso a Internet e edio de textos, mas nas verses atuais pode-se instalar qualquer programa que rode em plataforma GNU/Linux. No laboratrio experimental foi utilizado como servidor uma mquina com as configuraes especificadas na tabela 1. O sistema operacional adotado foi o GNU/Linux da distribuio Red Hat, na sua verso 9.0. Os aplicativos disponibilizados foram basicamente editores de texto, editor de imagens, navegador de Internet, ambientes de programao e clientes de e-mail.
Tabela 1 Configurao do servidor SET no laboratrio do SECOM. Componente Descrio Processador AMD Athlon XP 2400+ Memria 512 MBytes Disco rgido 80 GBytes Placa de rede 10/100 Mbps, padro Ethernet Monitor Super VGA, colorido, 15" Teclado Padro PS/2 Mouse Padro PS/2 Fonte: Projeto SET em http://sig.ufpa.br/set Quantidade 1 2 1 3 1 1 1
44 Como estaes de trabalho, foram reaproveitados os computadores existentes no laboratrio de informtica do SECOM, onde haviam 10 mquinas. A tabela 2 apresenta a configurao genrica das estaes.
Tabela 2 Configurao das estaes de trabalho no laboratrio do SECOM Componente Descrio Processador Pentium II 200 MHz Memria 64 MBytes Placa de rede 10/100 Mbps, padro Ethernet Monitor Super VGA, colorido, 14" Teclado Padro PS/2 Mouse Padro PS/2 Fonte: Projeto SET em http://sig.ufpa.br/set Quantidade 1 1 1 1 1 1
Cabe ressaltar que para interligar o servidor com as estaes de trabalho foram utilizados um switch 10/100 Mbps, de 16 portas, e cabos padro Ethernet categoria 5 enhanced.
5.5 Consideraes sobre o Projeto

A tcnica de se utilizar um computador de maior porte para gerenciar vrias mquinas, de recursos computacionais reduzidos, existe h muito tempo, desde a poca em que o sistema operacional Unix foi concebido. Porm, seu uso era limitado, diferentemente do que se possui hoje, tanto em termos de hardware como de software. Alm disso, as solues que existiam, em sua grande maioria, eram proprietrias, o que ocasionava custos elevados de aquisio. Atualmente, os softwares esto exigindo cada vez mais do hardware, e o que foi adquirido no passado, passa a ser considerado como tecnologicamente ultrapassado, pois no conseguem mais suprir a demanda com os recursos disponveis. Permanecer atualizando um laboratrio de informtica, que contm de 10 a 20 computadores, praticamente impossvel, ainda mais em uma instituio de ensino pblica. Como o componente principal dessa soluo o servidor, apenas este precisaria passar por atualizaes. Em suma, por meio do Projeto SET, consegue-se resgatar computadores tecnologicamente defasados e aumentar o tempo de vida til das estaes de trabalho, reduzindo assim o custo total de propriedade (TCO) para laboratrios de informtica. (VIGAS, 2004)
45
6 Utilizao de Tcnicas de Cluster no Projeto SET

A idia de incluir funcionalidades de cluster ao SET vem de uma observao realizada pelos desenvolvedores do projeto, a qual est relacionada com o processador contido nas estaes de trabalho. A arquitetura na qual o SET montado atualmente, no se faz muito uso dos ciclos de CPU disponveis nas estaes de trabalho. Isso se deve aos poucos programas que rodam no lado cliente, pois h somente a necessidade de obter os recursos grficos disponibilizados pelo servidor, o que no demanda muito recurso computacional e, ainda, justifica o reaproveitamento de mquinas obsoletas. Atualmente, diversos laboratrios esto sendo implantados na UFPA seguindo a arquitetura do SET. Entretanto, a maioria dos equipamentos adotados nos laboratrios so computadores com os recursos computacionais renovados. Cabe ressaltar que, apesar de serem mquinas novas, os processadores adotados possuem uma velocidade de clock relativamente baixo, o que justifica o baixo custo da soluo, mas no o desperdcio de processamento. Portanto, a idia de implementar uma arquitetura de cluster no SET vem justamente para fazer uso dos ciclos ociosos das novas estaes de trabalho. Para implementar uma estrutura de cluster no SET, primou-se por uma soluo que consiga manter as mesmas propriedades existentes atualmente, e que provoquem o mnimo de distrbio no sistema, ou praticamente nenhum. A soluo escolhida para adicionar as funcionalidades to almejadas foi justamente a tecnologia de cluster openMosix. O openMosix um conjunto de funcionalidades embutidas no kernel Linux que fazem com que mltiplos computadores, sejam monoprocessados ou multiprocessados, operem de forma cooperativa na execuo de suas tarefas. Dentre as funcionalidades incluem-se diversos algoritmos para compartilhamento de recursos, os quais foram desenvolvidos com a finalidade de se aproveitar melhor os recursos computacionais disponveis pelos ns do cluster. Para tal, so utilizados mecanismos de migrao preemptiva de processos, que permite migrar um processo de um n para outro, de forma totalmente transparente, procurando sempre manter um balanceamento de carga e evitar operaes de paginao de memria (swap).
46
6.1 Tecnologia openMosix

A tecnologia openMosix consiste basicamente de duas partes: o mecanismo de migrao preemptiva de processos (MPP) e os algoritmos de compartilhamento de recursos. Ambas as implementaes so codificadas a nvel de kernel do sistema operacional, o que faz com que no haja necessidade de modificar a aplicao para fazer uso desses recursos. (MAYA, 2004, p.10) O mecanismo de MPP capaz de migrar qualquer processo, a qualquer instante, para qualquer n disponvel. Normalmente, essas operaes ocorrem de forma automatizada pelo sistema, com base nas informaes providas por um dos algoritmos de compartilhamento de recursos. Entretanto, a migrao tambm pode ser realizada manualmente pelo usurio que criou o processo, sendo que este dever ainda verificar o melhor n para executar a tarefa. Cada processo criado possui um Unique Home Node (UHN), o qual significa a origem do processo. Quando um processo migrado, este faz uso dos recursos computacionais do n remoto, mas sempre interage com o ambiente original atravs de seu UHN. Por exemplo, se um determinado processo, que foi migrado, invocar uma rotina para obter a data do sistema, este dever receber a data corrente da mquina UHN, e no do local onde foi migrado. A MPP a ferramenta principal para os algoritmos de gerncia de recursos, pois estes tentam aproveitar da melhor maneira possvel os recursos disponveis no sistema. Por exemplo, enquanto houver capacidade de memria ou CPU, um determinado processo estar confinado a ficar em seu UHN, caso contrrio, ser necessrio migrar para um n menos sobrecarregado. A granularidade dos programas no openMosix est diretamente ligado com os processos executados no sistema. Os usurios podem tanto rodar aplicaes paralelas como iniciar vrios processos seqenciais, o que far com que o sistema atribua o processo para o melhor n naquele momento. Toda operao realizada pelo openMosix feito sem a necessidade de um controle central, ou seja, no h nenhum relacionamento do tipo mestre/escravo entre os ns. Cada n do sistema opera de maneira autnoma, tomando as suas prprias decises de forma independente. Com essa estrutura possvel realizar
47 configuraes dinmicas, onde os ns podem tanto entrar como sair do agregado sem ocasionar grandes impactos sobre o sistema. Isso garante uma boa escalabilidade tanto em sistemas de grande porte quanto em pequenos clusters. (PITANGA, 2003, p.250)
6.1.1 Algoritmos de Compartilhamento de Recursos

Dentre os algoritmos de compartilhamento de recursos do openMosix, destacam-se principalmente o balanceamento de carga e o de anunciao de memria. O algoritmo de balanceamento dinmico de carga tenta reduzir a diferena de carga entre pares de ns, migrando os processos de um n sobrecarregado para um n menos sobrecarregado. Como a estrutura descentralizada, todos os ns do cluster executam o mesmo algoritmo, e a tentativa de reduo das diferenas realizada de forma totalmente independente entre pares de hosts. (MAYA, 2004, p.12) O segundo algoritmo, de anunciao de memria, previne o esgotamento total da memria, evitando assim que ocorram paginaes ou a utilizao de memria virtual. O algoritmo ativado quando um dos ns comea a realizar muita paginao, em virtude do esgotamento de memria livre. Neste caso, o processo que est ocasionando tal situao imediatamente migrado para um n que possua memria livre, mesmo que isso ocasione em uma m distribuio de carga no sistema. Posteriormente, foi criado um novo algoritmo de escalonamento para selecionar em qual dos ns um determinado programa deve rodar. Esse algoritmo baseado no modelo terico matemtico da economia de mercado, que determina um comparativo de preos para cada recurso. Determinar o melhor local para executar um processo uma das tarefas mais complicadas, ainda mais em uma arquitetura de mquinas totalmente heterogneas (computadores com configuraes diferentes de hardware), como o caso do openMosix. O novo algoritmo implementado no openMosix bastante interessante porque tenta-se conciliar as diferenas baseado em princpios da economia e anlise de competitividade. Para o algoritmo chegar a uma concluso, os recursos de comunicao so medidos em termos de largura de banda, memria em termos de espao e CPU em termos de ciclos. A idia chave converter o uso total desses diversos recursos heterogneos em um custo homogneo. Com isso, os processos
48 so ento transferidos para o local que possuir menor custo. (PITANGA, 2003, p.248)
6.1.2 Migrao de Processos

Para realizar a migrao de processos de modo preemptivo, o openMosix divide o processo a ser migrado em duas partes: o que ser transferido, denominado de remote, e o que permanecer no UHN, chamado de deputy. A parte remote a que contm o cdigo do programa, a pilha, os dados, os mapas de memria e o estado dos registradores do processo, os quais rodam no modo usurio do sistema operacional. J o deputy encapsula a parte que contm todas as descries dos recursos dos quais o processo faz uso ou dos que esto alocado para ele, alm da pilha do sistema que controla a execuo do processo. Esta parte do processo fica confinada no UHN, ou seja, no pode ser migrada, pois depende exclusivamente do contexto do sistema. A figura 6.1 apresenta a estrutura de diviso de um processo migrado.
Segundo a figura 6.1, existem dois contextos de execuo para um processo: o modo usurio e o modo sistema, onde este ltimo tambm conhecido como modo kernel. Como a interface de ambos os modos bem definida e conhecida, toda e qualquer interao que haja entre esses dois modos so interceptadas para serem devidamente encaminhadas pela rede de comunicao. Este processo realizado pela camada de adaptao (link layer), a qual contm um canal especial de comunicao para a interao dos dois contextos do sistema operacional. (MAYA, 2004, p.13) Cabe ressaltar que algumas funes do kernel do sistema no so compatveis com esse esquema de diviso de processos. Alguns exemplos so as
49 funes de escrita em memria compartilhada, aplicaes em tempo real, instrues que acessem um barramento especfico, entre outras. Quando um desses casos ocorrerem, os processos no conseguiro migrar, permanecendo assim em seu UHN.
6.1.3 Acesso a Arquivos

A implementao de um sistema de arquivos que permita, caso seja necessrio, o acesso aos arquivos remotos por parte dos processos migrados tambm muito importante. Para tal, existem duas formas de se fazer isso. Primeiramente, poderia se interceptar todas as operaes de E/S realizadas pelos processos migrados e enviar estas requisies para o seu UHN. A segunda maneira seria utilizar o sistema de arquivos de rede NFS (Network File System), criando-se assim uma forma global de acessar todos os arquivos dos ns. A primeira soluo apresenta-se bem mais fcil de manter as operaes requisitadas, uma vez que h uma camada interceptando as operaes, mas tambm mais difcil de se desenvolver e acarreta em um grande overhead nas comunicaes. J a segunda soluo seria bem mais fcil de se implementar, mas se tornaria problemtica ao montar todos os sistemas de arquivos de cada n de maneira inteligente, e ainda garantir a consistncia de permisso de acesso aos arquivos por usurio. Devido aos problemas encontrados nas solues anteriores, os
desenvolvedores do openMosix implementaram um sistema de arquivos capaz de prover uma viso global com todos os ns. O sistema de arquivos DFSA (Direct File System Access). Esta implementao foi projetada para reduzir o overhead causado pela execuo de E/S em chamadas de sistemas de processos migrados. Isto foi conseguido ao permitir com que a execuo de grande parte das chamadas de sistemas fossem realizadas de forma local, ou seja, no n em que o processo se encontra. Alm disso, o DFSA levou implementao de um novo algoritmo que leva em considerao as operaes de E/S e que foi adicionado poltica de distribuio de carga. (PITANGA, 2003, p.253)
50
6.2 Vantagens e Desvantagens do openMosix

O openMosix implementa uma gama de recursos novos ao kernel Linux, que fazem deste uma estrutura de cluster ideal, pois permite fazer uso dos processadores de maneira totalmente transparente. Entretanto, esses recursos no so aplicveis a qualquer tipo de processo, principalmente para: a) Processos com baixo processamento, como aplicativos que fazem uso de alta comunicao interprocessos; b) Aplicaes com memria compartilhada, geralmente os Web Servers ou Database Servers; c) Aplicaes dependentes do hardware, que necessitam de acesso a um perifrico em algum n especfico do cluster; d) Aplicaes com diversas linhas de execuo (threads) no ganham desempenho; e) A execuo de um nico processo, como o browser, no ganha performance. Apesar de parecer muito desvantajoso em um primeiro momento, os ganhos obtidos de sua implementao so inmeros, pois as desvantagens existentes esto relacionadas a questes de paralelismo de execuo. Em um laboratrio de informtica, nos moldes do SET, a implementao perfeitamente justificvel, e os ganhos seriam em: a) Processos de uso intensivo da CPU, os quais ocasionam longos tempos de execuo e baixo volume de comunicao; b) Compilao de programas extensos; c) Processos que possuem tempo de execuo longos e rpidos ou com quantidade moderada de comunicao interprocessos; d) Processos com muita operaes de E/S, utilizando o DFSA; e) Banco de dados que no utilizam memria compartilhada; f) Processos que podem ser migrados manualmente.
51
6.3 Software de Gerenciamento

Para manter tal arquitetura, importante adotar-se um software para gerenciamento do cluster. O mais utilizado para openMosix o gerenciador grfico openMosixview. Com essa aplicao, tambm possvel ajustar os principais parmetros do cluster, alm de permitir a visualizao de carga do sistema, a visualizao dos processos migrados e de executar ou transferir processos manualmente. O conjunto de ferramentas que fazem parte do openMosixview so: a) openMosixview: a aplicao principal, que alm de dar acesso as outras, permite a visualizao de desempenho do cluster; b) openMosixprocs: este permite o gerenciamento de processos; c) openMosixcollector: atravs de um daemon que coleta informaes dos ns, permite a exibio do comportamento do cluster durante um perodo de execuo; d) openMosixanalyzer: este utilitrio serve para analisar os dados coletados pela aplicao acima; e) openMosixhistory: exibe um histrico dos processos que esto executando no sistema; f) openMosixmigmon: com esta aplicao pode-se visualizar, atravs de um mapa, as ocorrncias de migrao de processos.
6.3.1 openMosixview
O openMosixview apresenta uma interface grfica bem intuitiva e simples de manusear, como demonstra a figura 6.2. Ao lado esquerdo, na janela da aplicao, so exibidos os IPs dos ns que compem o cluster, e ao seu lado, h uma numerao indicando se o mesmo est operacional ou no (verde para funcionando e vermelho para indicar alguma falha). Em seguida, com o boto deslizante, pode-se modificar a velocidade para cada n. O balanceamento de carga do sistema realizado com base nesses valores, por exemplo, um processo pode migrar facilmente para um n cujo valor de
52 velocidade esteja mais alto em comparao aos outros. Cabe ressaltar que essa velocidade no representa a capacidade fsica do equipamento, e sim a velocidade com que o openMosix avalia o n em questo.
As barras de progresso, encontradas no meio da janela, informam o quanto esto sobrecarregados os ns do sistema e o consumo de memria de cada um deles. Na seqncia, os nmeros indicam o total de memria e a quantidade de CPUs para cada n, respectivamente. Cabe ressaltar que a primeira informao, localizada logo acima desses valores, indicam o desempenho do sistema em sua plenitude. Pode-se ainda realizar algumas configuraes inerentes a cada n desejado. Ao clicar no endereo IP do n, ser exibido uma tela de configurao semelhante ao da figura 6.3, onde os parmetros como o mecanismo de migrao automatizada, migrao de processos locais, comunicao com outros ns, dentre outros, podem ser ativados ou desativados.
53
6.3.2 Gerenciando Processos

O openMosixprocs a aplicao responsvel pelo gerenciamento dos processos que esto sendo executados no cluster. possvel visualizar nesta aplicao informaes como a identificao de cada processo, o n em que est sendo executado, a situao atual, o comando referente ao processo, entre outros. Na primeira coluna, contida na figura 6.4, nota-se a presena de alguns cones para cada processo. Aqueles que esto representados por um cadeado no podem ser migrados. Os cones de engrenagem representam processos que podem ser migrados, e esto na cor verde para processos remotos (migrados) e laranja para processos locais.
Ao disparar um duplo clique do mouse em um dos processos da lista, a janela de migrao da figura 6.5 ser apresentada. Com ela, poder ser realizada tarefas como travar um processo, via boto sigstop, e reinici-lo, via boto sigcont, bem como migrar processos manualmente. Com o boto deslizante, localizado na parte inferior, pode-se atribuir um valor de prioridade para o processo, onde o valor -20 significa prioridade mxima e o valor 20 prioridade mnima.
54
6.3.3 Histrico de Utilizao

H um processo daemon chamado de openMosixcollector que cria arquivos de log contendo a carga de cada n do openMosix, mantendo assim um histrico das atividades realizadas. Posteriormente, esse histrico pode ser utilizado pelo analisador de logs openMosixanalyzer, que faz uma avaliao ininterrupta da carga, memria e processos do cluster. A tela da figura 6.6 mostra, por meio de grficos estatsticos, um histrico da operacionalidade do cluster utilizando a ferramenta openMosixanalyzer.
55 Atravs dos logs gerados pelo processo daemon citado anteriormente, pode-se ainda visualizar os processos que foram executados durante o tempo de coleta atravs da ferramenta openMosixhistory (ver figura 6.7).
6.3.4 Monitorando Migraes

O openMosixmigmon a ferramenta utilizada para monitorar a migraes efetuadas no cluster openMosix. So apresentados vrios pingins envoltos por um crculo representando os ns do sistema, como demonstra a figura 6.8.
56 O crculo maior, localizado no meio da imagem, identifica a mquina que est executando a ferramenta. Os pequenos quadrados pretos, formando a circunferncia do n, representam os processos que podem ser migrados. Quando um processo migra para um dos ns, exibido uma ligao entre o processo principal (deputy) e o processo remoto (remote), onde este ltimo marcado por um quadrado verde. Outro caracterstica interessante dessa ferramenta a possibilidade de arrastar o processo e soltar em um outro n, permitindo assim, movimentar o processo sem muito esforo.
57
7 Testes de Desempenho no Cluster

Os testes de desempenho realizados em um cluster openMosix, especificamente em uma arquitetura SET, tiveram como objetivo identificar se, ao empregar esta soluo, h algum tipo de retorno em termos de processamento para algumas aplicaes. Portanto, foram selecionados dois softwares para realizar a avaliao da estrutura em cluster e validar os reais ganhos de desempenho. O primeiro software adotado foi o FLAC (Free Lossless Audio Codec). Este programa realiza a compresso de streams de audio, permitindo com que se possa economizar espao em disco. Entretanto, diferentemente de outros sistemas, neste no h perdas no processo de compresso, ou seja, ao descomprimir o arquivo gerado pelo mesmo, obter-se- um arquivo com a mesma qualidade antes do processo de compresso. Na maioria dos casos, este programa consegue comprimir os dados de audio em at 65% do tamanho original. O segundo software utilizado foi o POVRay (Persistence of Vision Raytracer). Este programa permite que, a partir da especificao de formas, cores, texturas e iluminao, se criem imagens de realismo fotogrfico. Como a tecnologia empregada neste programa trata-se de um traador de raios, o processo de criao das imagens consumiro bastante tempo de processamento, o que o tornar adequado para a realizao de testes na estrutura em cluster.
7.1 Ambiente de Testes

Os testes foram realizados com trs computadores interligados por uma rede Fast Ethernet. A topologia da rede seguia o padro estrela, onde um nico equipamento concentra as ligaes de todos os ns da rede. O equipamento utilizado foi um Switch 8 portas de 10/100 Mpbs. Quanto aos computadores, um pertencia a arquitetura AMD Duron, enquanto que os demais pertenciam a arquitetura Intel Celeron. As tabelas 3, 4 e 5 apresentam as configuraes genricas de cada mquina. Cabe ressaltar que os equipamentos utilizados nos testes no condizem com a estrutura empregada pela soluo SET. Todavia, pode-se esperar resultados mais satisfatrios em um ambiente real, em virtude das configuraes adotadas aqui serem inferiores se comparadas
58 com uma arquitetura SET.

Tabela 3 Configurao do micro da arquitetura AMD Componente Processador Memria Disco Placa de rede Monitor Teclado Mouse Descrio AMD Duron 1.1 GHz 375 MBytes 20 GBytes 10/100 Mbps, padro Ethernet Super VGA, colorido, 15" Padro PS/2 Padro PS/2 Quantidade 1 1 1 2 1 1 1
Tabela 4 Configurao da primeira estao da arquitetura Intel Componente Processador Memria Placa de rede Monitor Teclado Mouse Descrio Intel Celeron 1.7 GHz 111 MBytes 10/100 Mbps, padro Ethernet Super VGA, colorido, 15" Padro PS/2 Padro PS/2 Quantidade 1 1 1 1 1 1
Tabela 5 Configurao da segunda estao da arquitetura Intel Componente Processador Memria Placa de rede Monitor Teclado Mouse Descrio Intel Celeron 2 GHz 111 MBytes 10/100 Mbps, padro Ethernet Super VGA, colorido, 15" Padro PS/2 Padro PS/2 Quantidade 1 1 1 1 1 1
Primeiramente, preparou-se uma estrutura semelhante ao do Projeto SET, onde o computador AMD Duron atuava como servidor e os demais como estaes de trabalho. Em seguida, implantou-se sobre esta estrutura a implementao do cluster openMosix, como especificado em anexo.
7.2 Procedimentos e Tcnicas

Os testes consistiram em executar os programas supracitados no incio deste captulo em trs instncias. No primeiro momento, executou-se os programas apenas no servidor. Em segundo, incluiu-se uma das estaes de trabalho para auxiliar o servidor na execuo das tarefas. E por ltimo, a segunda estao de trabalho, totalizando trs computadores para realizar as mesmas tarefas.
59 Em cada um dos momentos citados anteriormente, houve uma aferio do tempo necessrio para finalizar uma determinada tarefa submetida ao cluster. Cabe ressaltar que, para o programa FLAC, foi utilizado a ferramenta time para obter o tempo total de execuo do processo. Por outro lado, esse mesmo artifcio no foi necessrio para o programa POVRay, pois este apresenta um relatrio ao trmino do processamento.
7.3 Testes e Resultados 7.3.1 FLAC (Free Lossless Audio Encoder)

Um dos motivos que levaram a adoo do FLAC como uma das ferramentas para testes foi porque programas desse tipo, geralmente, fazem uso intensivo do processador. O processo de codificao, tanto de udio como de vdeo, costumam realizar vrios clculos matemticos e conseqentemente acabam fazendo uso total da CPU. Alm dessa carga ocasionada pela codificao, esses programas tambm demandam vrias operaes de E/S, mas sem serem excessivos. Em adio a esses fatores, a codificao de udio e vdeo geram processos ideais para serem executados na implementao openMosix, pois as tarefas executadas levam um certo tempo para serem finalizadas. O teste realizado com o FLAC envolveu a codificao de trs arquivos de udio, os quais encontravam-se no formato wav (no comprimido) e foram transformados para o formato flac (comprimido). Ao trmino do processo, notou-se um ganho significativo em termos de produtividade, como apresenta o grfico 7.1.
Codificao de udio utilizando Flac
1 node
2 nodes
3 nodes
25
50
75
100
125
150
175
200
Tempo (seg.)
Grfico 7.1 Tempo de codificao para 3 arquivos de udio
60 Ao executar a tarefa de codificao com dois ns, incluindo o servidor, obteve-se uma reduo de 31% em relao ao tempo gasto com um nico computador (servidor). Com a incluso de mais um n ao cluster, percebe-se um ganho de 56% em relao ao primeiro teste.
7.3.2 POVRay (Persistence of Vision Raytracer)

Atualmente, o POVRay muito utilizado para fazer benchmark em agregados de computadores, inclusive em computadores individualmente. A finalidade deste programa consiste em produzir imagens tridimensionais de alta qualidade e com vrios requinte de detalhes. Para tal, utilizado o mtodo denominado de Ray-tracing, com o qual possvel gerar imagens a partir de uma descrio geomtrica dos objetos, e modelando-os a partir de raios de luz. Como em uma foto real, o sistema simula a realidade descrita em uma cena. Por exemplo, em uma cena existem diversos objetos e cada um deles possui texturas e cores diferentes (uma esfera com textura de vidro, um cho xadrez, entre outros). No sistema Ray-tracing, tudo que se v trata-se de luz refletida, como em um mundo real, e quando a luz intercepta um objeto transparente, esta dever refletir o que est por trs deste objeto. Contudo, este processo costuma demorar um pouco para concluir a renderizao (gerao da imagem), pois a projeo de raios de luz realizada para todos os pixels da imagem, at que sejam concludas. Para auxiliar nos testes desta aplicao foi utilizado o software POVmosix. Este programa prove uma forma de paralelizar o processo de renderizao da imagem pelo POVRay. Tal artifcio consiste em dividir a imagem em pequenos pedaos denominados de sub-tarefas, podendo-se, assim, executar os vrios processos em paralelo. (BONFANTI, 2004) O pacote do programa POVRay vem acompanhado de vrios exemplos para criao de imagens. Para realizar o benchmark, primeiramente foi utilizado o arquivo landscape.pov, o qual contm a descrio geomtrica para gerar a imagem da figura 7.2.
61
Figura 7.2 Imagem landscape gerada pelo POVRay
A resoluo da imagem gerada continha 1024 pixels de resoluo horizontal e 768 pixels de resoluo vertical. O grfico 7.3 apresenta o tempo de renderizao obtido nos testes.
Renderizao de Imagem com Povray

1 node
2 nodes
3 nodes
250
500
750
1000
1250
1500
Tempo (seg.)
Grfico 7.3 Tempo de renderizao da imagem landscape
Inicialmente, nota-se um ganho acima de 100%, mas descobriu-se que essa imagem no era adequada para realizar os testes no sistema, pois no havia muitos objetos em cena. Ento, para realizar um benchmark completo, utilizou-se o arquivo benchmark.pov, o qual continha a descrio de vrios objetos, bem mais complexos que o anterior. Cabe ressaltar que esse o arquivo mais utilizado para realizar testes desse tipo.
62
Figura 7.4 Imagem benchmark gerada pelo POVRay
Para iniciar o teste, decidiu-se por dividir a imagem em apenas quatro pedaos, gerando assim, quatro processos em paralelo para constru-la. Outro detalhe foi quanto a resoluo da imagem, que optou-se por 800 pixels na horizontal e 600 pixels na vertical. A figura 7.4 apresenta um exemplo da imagem benchmark. O grfico 7.5 apresenta os tempos obtidos na renderizao da imagem citada anteriormente. A reduo no tempo de renderizao, comparado com um nico n (servidor), ficou na mdia de 19% e 34%, para dois e trs ns, respectivamente.
Renderizao de Imagem com Povray

1 node
2 nodes
3 nodes
1000
2000
3000
4000
5000
Tempo (seg.)
Grfico 7.5 Tempo de renderizao da imagem benchmark
63
8 Consideraes Finais
No decorrer do trabalho, foi possvel apresentar uma soluo alternativa para laboratrios de informtica de baixo custo, o Projeto Servidor de Estaes de Trabalho (SET). Tal projeto se faz muito importante em instituies de ensino pblicas, especialmente para a Universidade Federal do Par. Na busca de evoluir a arquitetura do Projeto SET, procurando atingir nveis ainda maiores em termos de escalabilidade, robustez e desempenho, encontrou-se nas arquiteturas paralelas uma sada para incrementar ainda mais o seu potencial. Associado ao fato da popularizao dos clusters de computadores, a idia de adicionar tcnicas que permitam realizar tarefas em paralelo foi ideal para elevar o potencial da soluo. O openMosix o que h de mais novo em termos de pesquisas envolvendo clusters de computadores. Alm de ser uma soluo gratuita, segue a filosofia de software livre, com a qual permite realizar-se estudos mais aprofundados na tecnologia e evolu-las de forma independente. Portanto, segundo o estudo de viabilidade realizado por este trabalho, a soluo se mostrou completamente vivel para futuras implementaes do Projeto Servidor de Estaes de Trabalho. Outro fator percebido, durante o desenvolvimento desse trabalho, foi a possibilidade de se utilizar a soluo como uma ferramenta apropriada para ensino das disciplinas dos cursos de computao, como sistemas distribudos e arquiteturas paralelas. Uma das justificativas seria que, com tal estrutura, o aluno poderia ter um contato bem mais prximo de um cluster e, ao mesmo tempo, dispor de um laboratrio completo em termos de ferramentas e programas. Analisando os dados fornecidos pelo trabalho, pode-se concluir tambm que apenas aplicaes especficas conseguem obter ganhos de processamento, tais como as que foram utilizadas nos testes de desempenho. Entretanto, aps conhecer os fundamentos da tecnologia openMosix, ficou claro a razo de aplicaes de uso dirio no conseguirem se beneficiar da arquitetura, pois estes tipos de programas fazem uso de multi-threads, bem como de memria compartilhada. Por fim, considera-se que o objetivo do presente trabalho foi atingido, uma vez que o estudo de viabilidade disponibilizado provou que o cluster openMosix pode oferecer grandes funcionalidades ao projeto SET, sem alterar a sua estrutura original.
64
9 Trabalhos Futuros
Para um possvel trabalho futuro, poderia-se realizar estudos para a viabilizao da implementao de memria compartilhada distribuda (DSM), atualmente considerada forte tendncia de desenvolvimento em ambientes de cluster. Tal implementao tem por objetivo permitir a migrao de processos que usam memria compartilhada, bem como aqueles que fazem uso de multi-threads, sem perdas de desempenho. Geralmente estes processos pertencem ao domnio das aplicaes comuns. Uma outra questo importante, antes de construir o cluster, seria em realizar uma anlise de desempenho completa da estrutura do Projeto SET, pois traria uma noo bem apurada do quanto vivel a implementao desta soluo. Seguindo esta mesma linha de pensamento, em anlise de desempenho, poderia-se tambm realizar um levantamento de vrias aplicaes, necessrias para ambientes de laboratrios de informtica, que podem obter ganhos de desempenho em uma estrutura de clusters. Um outro aspecto, quanto a arquitetura do SET, seria na disponibilidade do servidor. Caso ocorra uma falha, um laboratrio inteiro ficaria parado, uma vez que as estaes de trabalho dependem de seu funcionamento. Para evitar que tal situao acontea, poderia-se realizar um estudo para empregar os recursos da Alta Disponibilidade. Contudo, existem inmeros temas a serem desenvolvidos envolvendo assuntos relacionados com o presente trabalho.
65
10 Referncias Bibliogrficas
BARAK, Amnon. MOSIX. Disponvel em: <http://www.mosix.org>. Acesso em: 02 ago. 2004. BAR, Moshe. openMosix: The openMosix Project. Disponvel em: <http://openmosix.sourceforge.net>. Acesso em: 02 ago. 2004. BONFANTI, Alessandro. POVmosix. Disponvel em: <http://povmosix.sourceforge.net>. Acesso em: 08 nov. 2004. BUYTAERT, Kris. Introducing openMosix. Disponvel em: <http://www.linuxdevcenter.com/pub/a/linux/2004/02/19/openmosix.html>. Acesso em: 07 ago. 2004. ______. The openMosix HOWTO. Disponvel em: <http://www.tldp.org/HOWTO/openMosix-HOWTO/index.html>. Acesso em: 07 ago. 2004. CAMP, Richard. K12LTSP MOSIX Howto. Disponvel em: <http://www.k12os.org/modules.php?op=modload&name=News&file=article&sid=14>. Acesso em: 08 ago. 2004. CLAY, John. Reduced Cost Network Computing Trough The Use of Thin Clients and Low Cost Software. Disponvel em: <http://ltsp.org/articles/ThinClient.pdf>. Acesso em: 04 jun. 2004. DANIAU, William. LTSP-MOSIX. Disponvel em: <http://www.lpmo.edu/~daniau/ltspmosix/>. Acesso em: 08 ago. 2004. DE ROSE, Csar A. F.; NAVAUX, Philippe O. A. Arquiteturas Paralelas. Porto Alegre: Sagra Luzzatto, 2003. ETHERBOOT Project. Disponvel em: <http://etherboot.sourceforge.net>. Acesso em: 02 ago. 2004. FERREIRA, Jos Alexandre. Estudo de Modelos de Agrupamento de Computadores para Computao de Alta Performance utilizando Clientes Leves. Alagoas: UFAL, 2003. GARCIA, Sulamita. Montando um pequeno ambiente de Alta Disponibilidade no Slackware. Disponvel em: <http://ha.underlinux.com.br>. Acesso em: 10 out. 2004.
66 HOFFMAN, Forrest. High Performance Interconnects. Linux Magazine, ed. set., 2002. Disponvel em: <http://www.linux-mag.com/cgi-bin/printer.pl?issue=200209&article=extreme>. Acesso em: 08 ago. 2004. JENSEN, James. LTSP + openMosix: Integration How-To. Disponvel em: <http://openmosix.sourceforge.net/ltsp-omr4-1.html>. Acesso em: 08 ago. 2004. JIN, Hai & BUYYA, Rajkumar & BAKER, Mark. Cluster Computing Tools, Applications, and Australian Initiatives for Low Cost Supercomputing. LIBES, Maurice. Utilisation d'un cluster de calcul openMOSIX et dploiement l'aide de LTSP. [S.I.: s.n.], 2003. Disponvel em: <http://www.com.univmrs.fr/ssc/info/omosix.html>. Acesso em: 07 ago. 2004. MAYA; ASMITA; ANURADHA; SNEHAL; KRUSHNA. Migshm Project Report. Disponvel em: <http://mcaserta.com/maask/Migshm_Report.pdf>. Acesso em: 07 ago. 2004. MCQUILLAN, James. Linux Terminal Server Project. Disponvel em: <http://www.ltsp.org>. Acesso em: 02 ago. 2004. MYRICOM. Myrinet Products. Disponvel em: <http://www.myri.com>. Acesso em: 02 nov. 2004. PASQUARELLI, Maria Luiza Rigo. Normas para a Apresentao de Trabalhos Acadmicos: ABNT/NBR-14724, AGOSTO 2002. 2. ed. So Paulo: ODIFIEO, 2004. PINHEIRO, Jorge; HOUNSELL, Franci. Monografia em Cincias Jurdicas e Sociais: Como elaborar. Belm: [s.n.], 2003. PITANGA, Marcos. Computao em Cluster: O Estado da Arte da Computao. Rio de Janeiro: Brasport, 2003. ______. Construindo Supercomputadores com Linux. 2. ed. Rio de Janeiro: Brasport, 2004. ROBBINS, Daniel. OpenMosix: Part 1 of 3. Disponvel em: <http://www.intel.com/cd/ids/developer/asmo-na/eng/20449.htm>. Acesso em: 04 out. 2004. ______. OpenMosix: Part 2 of 3. Disponvel em: <http://www.intel.com/cd/ids/developer/asmo-na/eng/20445.htm>. Acesso em: 04 out. 2004.
67 ROBBINS, Daniel. OpenMosix: Part 3 of 3. Disponvel em: <http://www.intel.com/cd/ids/developer/asmo-na/eng/20446.htm>. Acesso em: 04 out. 2004. ROM-O-MATIC: dinamically generates Etherboot ROM images. Disponvel em: <http://rom-o-matic.net>. Acesso em: 02 ago. 2004. SANTOSA, Mulyadi. Checkpointing and Distributed Shared Memory in openMosix. Disponvel em: <http://www.unixreview.com/documents/s=8989/ur0404l/>. Acesso em: 07 ago. 2004. ______. Interview with MAASK Team. Linux Journal, ed. jan., 2004. Disponvel em: <http://mcaserta.com/maask/MigShmforopenMosixPrintable.pdf>. Acesso em: 07 ago. 2004. STERN, Hal; EISLER, Mike; LABIAGA, Ricardo. Managing NFS and NIS. 2. ed. [S.I.]: O'Reilly, 2001. STEVEN, Raymond Eric. The Linux XFree86 HOWTO. [S.I.: s.n.], 2000. Disponvel em: <http://www.tldp.org/HOWTO/XFree86-HOWTO/index.html>. Acesso em: 02 ago. 2004. TANENBAUM, Andrew S. Organizao Estruturada de Computadores. 4. ed. Rio de Janeiro: LTC, 2001. TANENBAUM, Andrew S. Redes de Computadores. 3. ed. Rio de Janeiro: Campus, 1997. TANENBAUM, Andrew S.; Woodhull, Albert S. Sistemas Operacionais: Projeto e Implementao. 2. ed. Porto Alegre: Bookman, 2000. TORVALDS, Linus. Kernel Linux. Disponvel em: <http://www.kernel.org>. Acesso em: 02 ago. 2004. VIGAS, Raimundo; FAVERO, Eloi; GONALVES, Glauco. SET Uma Soluo de Computador Popular de Rede Para Laboratrios de Informtica. In: WORLD CONGRESS ON ENGINEERING AND TECHNOLOGY EDUCATION, 2004, Santos. Anais... Santos: [s.n.], 2004.
ANEXOS
ANEXO A Implementao do openMosix ao Projeto SET
Implementao do openMosix ao Projeto SET

Antes de iniciar com o processo de instalao e configurao do openMosix no Servidor SET, deve-se realizar o download dos seguintes pacotes:
Fontes do Kernel 2.4.27 (linux-2.4.27.tar.bz2)
Patch do openMosix (patch-2.4.27-om-20041102.bz2)
openMosixtools (openmosix-tools-0.3.6-2.i386.rpm)
openMosixview (openmosix-view-1.5-redhat9.i386.rpm)
mknbi (mknbi-1.4.4-1.noarch.rpm)
LTSP Initrd Kit (ltsp_initrd_kit-3.0.15-i386.tgz) Os fontes do kernel podem ser obtidos no site www.kernel.org. J o patch
do
openMosix
pode
ser
encontrado
no
site
http://openmosix.snarc.org/files/releases/2.4/ e o openMosixtools na seguinte URL http://openmosix.sf.net, e neste mesmo site encontram-se inclusive pacotes prcompilados para o Red Hat 9. A ferramenta openMosixview deve ser obtida do site http://www.openmosixview.com. O mknbi est disponvel em http://etherboot.sf.net e o LTSP Initrd Kit em http://ltsp.sf.net. Vale ressaltar tambm que, para este tutorial, foi utilizado como distribuio o Red Hat 9, kernel 2.4.20-8, em um servidor Athlon XP 2000+, com 256 MB de RAM e HD de 80 GB. Por questes didticas, ser considerado que todos os pacotes, citados acima, estejam localizados no diretrio /usr/src.
1 Pr-Instalao
Antes de iniciar a instalao do openMosix, deve-se possuir um servidor configurado segundo os padres do projeto SET. Aps a implementao do SET, certifique-se de que as estaes clientes estejam realizando o processo de boot normalmente, bem como a inicializao em modo grfico. As precaues tomadas aqui podero evitar diversos problemas, portanto, no prossiga sem antes certificar-se de que tudo esteja funcionando corretamente.
2 Compilando o Kernel openMosix para o Servidor

Primeiramente, deve-se descomprimir os fontes do kernel:
# cd /usr/src # tar -xjvf linux-2.4.27.tar.bz2 ...
Aps o processo de descompresso, entre no diretrio criado e aplique o patch do openMosix da seguinte forma:
# cd linux-2.4.27 # bzip -dc ../patch-2.4.27-om-20041102.bz2 | patch -Np1 ...
Aps o procedimento acima, edite o arquivo "Makefile" e altere a linha que contm "EXTRAVERSION =" para "EXTRAVERSION = -om1". Depois de aplicado o patch do openMosix sobre o kernel Linux, deve-se gerar um arquivo denominado ".config", o qual mantm as configuraes de compilao. Ser utilizado como base uma configurao existente na distribuio Red Hat 9. Para configurar, proceda da seguinte forma:
# cp /boot/config-2.4.20-8 /usr/src/linux-2.4.27/.config # make oldconfig ...
No decorrer do ltimo comando executado, sero realizadas vrias perguntas referente aos novos parmetros. Para cada uma delas aperte a tecla <ENTER>, que dever atribuir o valor padro. O importante nesse passo gerar uma configurao compatvel com a verso de kernel existente. O comando a seguir roda uma aplicao (ver figura A1) que serve para modificar os parmetros de compilao do kernel:
# make xconfig ...
Figura A1 Configurao do Kernel
Na tela de configurao do kernel, entre na opo "openMosix" e certifique-se de que esto marcados para compilao os seguintes itens:
openMosix process migration support
Stricter security on openMosix ports
openMosix File-System
Poll/selection on exception on pipes
Disable OOM Killer E ainda, na opo "Level of process-identity disclosure (0-3)", atribua o
valor 3. As demais opes devem estar marcadas para no serem compiladas. Terminada as configuraes acima, volte ao menu principal e salve as configuraes, clicando em "Save and Exit". Agora, compile e instale o kernel da seguinte forma:
# # # # # make dep clean bzImage modules make modules_install cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.27-om1 cp System.map /boot/System.map-2.4.27-om1 mkinitrd /boot/initrd-2.4.27-om1.img 2.4.27-om1
Crie uma nova entrada no grub, editando o arquivo menu.lst (/boot/grub/menu.lst) e adicione as seguintes linhas:
title openMosix (2.4.27-om1) root (hd0,0) kernel /boot/vmlinuz-2.4.27-om1 ro root=/dev/hda1 hdc=ide-scsi initrd /boot/initrd-2.4.27-om1.img
Certifique-se de que o parmetros de localizao das imagens estejam corretos. Aps estes procedimentos, reinicie o computador e quando carregar o gerenciador de boot, selecione a opo "openMosix". Se estiver tudo correto, o novo kernel ser carregado e o sistema j estar rodando com openMosix no Servidor.
3 Compilando o Kernel openMosix para as Estaes de Trabalho

A maioria dos processos que se seguem nesta seo so semelhantes aos procedimentos apresentados anteriormente. Por questes de organizao, sero repetidos os passos anteriores dependendo da necessidade. Antes de compilar o kernel para as estaes de trabalho, precisamos instalar os pacotes mknbi e ltsp_initrd_kit. Proceda da seguinte forma:
# cd /usr/src # rpm -ivh mknbi-1.4.4-1.noarch.rpm # tar -xzvf ltsp_initrd_kit-3.0.15-i386.tgz
Aps o ltimo comando, ser gerado o diretrio ltsp_initrd_kit dentro do diretrio corrente (/usr/src). Agora, entre no diretrio fonte do kernel (j com o patch do openMosix aplicado) e execute os comandos para eliminar as configuraes realizadas anteriormente:
# cd /usr/src/linux-2.4.27 # make mrproper # make clean
Nesse momento, deve-se obter a configurao base das estaes de trabalho. Para tal, proceda da seguinte forma:
# cd /usr/src/linux-2.4.27 # cp /usr/src/ltsp_initrd_kit/config-2.4.24-ltsp-4 .config # make oldconfig
Na execuo do ltimo comando, surgiro perguntas relacionadas a configurao do kernel. Quando isso ocorrer, basta apertar a tecla <ENTER> que o valor padro ser assumido. Agora, precisamos editar o cabealho do arquivo "Makefile", onde, em EXTRAVERSION, dever conter "-wsom1", ficando da seguinte forma:
VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 27 EXTRAVERSION = -wsom1
Salve o arquivo e, em seguida, execute o seguinte comando:

# make xconfig ...
Surgir a aplicao para configurao dos parmetros do kernel, onde deve-se selecionar a opo "openMosix". Ento, na tela de configurao, certifiquese de estarem habilitados para compilao os seguintes parmetros:
openMosix process migration support
Stricter security on openMosix ports
openMosix File-system
Poll/selection on exception on pipes
Disable OOM Killer E ainda, na opo "Level of process-identity disclosure (0-3)", atribua o
valor 3. As demais opes devem estar marcadas para no serem compiladas (ver figura A2).
Figura A2 Configurao do kernel openMosix
Aps a configurao dos parmetros do openMosix, selecione a opo "Processor type and features", do menu principal. Na primeira opo, em "Processor family", selecione a arquitetura 486. Depois, clique em "Main Menu" e, em seguida, "Save and Exit". Agora deve-se continuar com a compilao por meio dos comandos:
# make dep clean bzImage modules # make modules_install ...
Para gerar a imagem do kernel s estaes de trabalho deve-se utilizar o pacote ltsp_initrd_kit, o qual foi instalado anteriormente. Para tal, realize os passos a seguir:
# cd /usr/src/ltsp_initrd_kit # ./buildk ...
Sero realizadas as seguintes perguntas:

You can prepare a kernel for the following type of workstation: 1 - PCI/ISA network card 2 - PCMCIA (laptop) network card Enter option (1,2) [1]:
Na pergunta acima, selecione a opo 1, ou simplesmente pressione <ENTER>. Na pergunta seguinte, ser solicitado o diretrio onde esto localizados os fontes do kernel, devendo-se preencher com "/usr/src/linux-2.4.26". Para as questes a seguir, basta teclar <ENTER> para assumir o valor padro:
Size of initrd filesystem [2500]: <ENTER> Number of inodes to allocate in initrd filesystem [180]: <ENTER>
Aps estes procedimentos, sero gerados no diretrio corrente trs arquivos: bzImage-2.4.26-wsom1, initrd-2.4.26-wsom1.gz e vmlinuz-2.4.26-wsom1. Copie-os para o diretrio /tftpboot da seguinte forma:
# cp vmlinuz-2.4.26-wsom1 /tftpboot/lts
Caso o sistema tambm possua suporte a boot via PXE, deve-se criar uma estrutura semelhante para o novo kernel compilado. Veja o exemplo a seguir:
# # # # # # # cd /tftpboot/lts mkdir -p 2.4.26-wsom1 cd 2.4.26-ltsp-2 cp -ar pxelinux.0 pxelinux.cfg ../2.4.26-wsom1 cd ../2.4.26-wsom1 cp /usr/src/ltsp_initrd_kit/bzImage-2.4.26-wsom1 . cp /usr/src/ltsp_initrd_kit/initrd-2.4.26-wsom1.gz .
E editar o arquivo "default", contido no diretrio "pxelinux.cfg", ficando da seguinte forma:

prompt=0 label linux kernel bzImage-2.4.26-wsom1 append init=/linuxrc rw root=/dev/ram0 \ initrd=initrd-2.4.26-wsom1.gz
Agora necessrio mover os mdulos do kernel para o diretrio raiz das estaes de trabalho, localizado em /opt/ltsp/i386/lib/modules:
# mv /lib/modules/2.4.27-wsom1 /opt/ltsp/i386/lib/modules # unlink /opt/ltsp/i386/lib/modules/2.4.27-wsom1/build
O ltimo passo agora alterar as configuraes no servidor de DHCP. Edite o arquivo "/etc/dhcpd.conf" e procure pelo parmetro "filename". Nesta opo, dependendo do processo de boot da estao, deve conter o seguinte valor: Para Etherboot:
filename = "/lts/vmlinuz-2.4.26-wsom1";
E para PXE:
filename = "/lts/2.4.26-om1/pxelinux.0"
Pronto! Agora reinicie o servio de DHCP:

# service dhcpd restart ...
Aps tudo isso, certifique-se de que as estaes de trabalho ainda conseguem inicializar, inclusive em modo grfico. Caso ocorra algum problema, tente corrigir o erro. No prossiga enquanto no tiver sanado os problemas.
4 Configurando o sistema de arquivos openMFS

Para habilitar o sistema de arquivos do openMosix, deve-se adicionar uma entrada no arquivo fstab, localizado em /etc. Nesse arquivo, dever conter a linha especificada abaixo:
none /mfs mfs dfsa=1 0 0
O mesmo processo deve ser repetido para o arquivo fstab das estaes de trabalho, agora localizado em /opt/ltsp/i386/etc. Antes de iniciar o sistema de arquivos, crie o diretrio /mfs, e somente depois monte o sistema de arquivos:
# mkdir /mfs # mount /mfs
Para que as estaes montem o sistema de arquivos durante o processo de inicializao, dever ser includo, em dos scripts de boot, uma linha contendo os comando de montagem. Esse ltimo processo ser especificado mais adiante.
5 Instalando e configurando o openMosixtools

Aps preparar o sistema com o kernel openMosix, necessrio instalar as ferramentas que serviro para realizar o gerenciamento em modo texto. Para instalar tais ferramentas, basta proceder da seguinte forma:
rpm -ivh /usr/src/openmosix-tools-0.3.6-2.i386.rpm
Terminada a instalao, segue-se para a configurao do arquivo openmosix.map. Para tal, edite o arquivo supracitado, o qual est localizado no diretrio /etc. Nesse arquivo deve conter a numerao de cada n seguido de seu endereo IP. O ltimo nmero refere-se a quantidade de ns que havero aps um determinado IP, por exemplo:
# MOSIX-# IP number-of-nodes # ============================ 1 192.168.0.1 1 2 192.168.0.102 2
No exemplo anterior, haver mais um n representado pelo nmero 3 e com endereo IP 192.168.0.103, pois o ltimo nmero indica a quantidade de ns existentes aps o seu respectivo IP (incluindo o prprio host tambm). Outro detalhe importante quanto ao arquivo /etc/hosts, o qual deve conter todos os hostnames dos computadores que fazem parte do cluster. necessrio que estaes tambm possuam o mesmo arquivo de hosts do servidor. Para tal, realize os procedimentos a seguir:
# cd /opt/ltsp/i386/etc # unlink hosts # cp /etc/hosts .
Agora basta copiar os arquivos binrios para configurao do openMosix nas estaes de trabalho. Cabe ressaltar que os arquivos a serem copiados so todos aqueles que se encontram no pacote openmosix-tools, mas especificamente no diretrio /sbin, /bin e /lib. Para fazer esta cpia, basta seguir os passos a seguir:
# cd /bin # cp mps mtop migrategroup iojob nomig runhome ompsinfo migrate\ cpujob fastdecay fixvfork.sh fixvfork.so moslimit joingroup \ mosctl mosmon mosrun showgroup nodecay resetgroup slowdecay \ /opt/ltsp/i386/bin # cd /lib # cp libmos.so.0.3.0 libmos.la libmos.a /opt/ltsp/i386/lib # ln -s /opt/ltsp/i386/lib/libmos.so.0.3.0 \ /opt/ltsp/i386/lib/libmos.so # ln -s /opt/ltsp/i386/lib/libmos.so.0.3.0 \
/opt/ltsp/i386/lib/libmos.so.0 # cd /sbin # cp setpe showmap omdiscd /opt/ltsp/i386/sbin # cp /etc/init.d/openmosix /opt/ltsp/i386/etc/rc.openmosix
Obs: A barra invertida, no fim de algumas das instrues anteriores, significa apenas uma quebra de linha, por no caber no texto a linha completa. No arquivo rc.openmosix, copiado anteriormente, deve-se editar a linha que contenha o comando touch. Essa linha deve ficar da seguinte forma: Antes:
touch /var/lock/subsys//openmosix
Depois:
echo > /var/lock/subsys//openmosix
Agora, s falta adicionar os comandos para as estaes inicializarem o openMosix. Deve ser includo no arquivo /opt/ltsp/i386/etc/rc.sysinit, as linhas a seguir:
##################################### # # Run a rc.local, if there is one # if [ -x /etc/rc.openmosix ]; then mount /mfs /etc/rc.openmosix start echo 1 > /proc/hpc/admin/stay fi
Procure adicionar as linhas anteriores um pouco antes do fim, seguindo o padro existente no arquivo original. O comando "mount /mfs" faz a montagem do sistema de arquivos do openMosix, j o "rc.openmosix" o script para inicializao do sistema nas estaes. O ltimo do comando do script anterior refere-se ao parmetro de migrao de processos, ou seja, os processos existentes nas estaes de trabalho no devero ser migrados.
6 Instalando o openMosixview
Para finalizar a construo do openMosix sobre a estrutura SET, basta instalar agora o openMosixview. Tal ferramenta permite gerenciar e configurar os ns do cluster, entretanto, para poder realizar as configuraes de cada um deles, inclusive no servidor, necessrio que esteja habilitado o servio de rsh ou ssh, sem
autenticao, tanto no servidor como nas estaes. Para instalar a ferramenta, basta executar o comando abaixo:
rpm -ivh /usr/src/openmosix-view-1.5-redhat9.i386.rpm
Agora basta rodar a aplicao chamando uma de suas ferramentas: openmosixview, openmosixprocs, openmosixmigmon, entre outras. Cabe ressaltar que o openmosixview a ferramenta principal, onde as outras podero ser chamadas por meio desta. Por fim, basta fazer uso do sistema para verificar o seu funcionamento. Algumas ferramentas interessantes que fazem uso do mecanismo de migrao de processos do openMosix so: POVRAY, POV-Mosix, make, Flac, entre outros.

Cluster Set

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cluster Set

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS COLEGIADO DO CURSO DE CINCIA DA COMPUTAO

Alex Yuichi Yokokura

Alex Yuichi Yokokura

Alex Yuichi Yokokura

Prof. Msc. Raimundo Vigas Jnior Depto. de Informtica / UFPA Orientador

Prof. Dr. Eloi Luiz Favero Depto. de Informtica / UFPA Membro

1.2 Organizao do Trabalho

2.1 Evoluo das Arquiteturas Paralelas

Figura 1.1 Supercomputador CRAY-1

2.2 Surgimento dos Clusters de Computadores

2.2.1 O Cluster Beowulf

Figura 1.2 Cluster classe Beowulf

2.2.2 O Projeto openMosix

3 Introduo s Arquiteturas Paralelas

3.1 Classificao de Flynn

3.1.1 Arquitetura SISD

Figura 2.1 Arquitetura SISD

3.1.2 Arquitetura MISD

Figura 2.2 Arquitetura MISD

3.1.3 Arquitetura SIMD

Figura 2.3 Arquitetura SIMD

3.1.4 Arquitetura MIMD

Figura 2.4 Arquitetura MIMD

3.2 Unidades de Medida

4.2 Tipos de Cluster

4.2.1 Alta Disponibilidade

4.2.2 Balanceamento de Carga

4.2.3 Alta Performance

4.4 Sistema Operacional GNU/Linux

4.5 Tecnologias de Redes

4.5.1 Ethernet e Fast-Ethernet

Figura 4.4 Interface Myrinet Fonte: Diretrio de imagens do Google

4.5.3 Scalable Coherent Interface (SCI)

Figura 4.5 Interface SCI Fonte: Diretrio de imagens do Google

4.6 Tendncias na Construo de Clusters

4.6.1 Mquinas Maciamente Paralelas (MPP)

34 organizao dessa arquitetura.

4.6.2 Distributed Shared Memory (DSM)

4.6.3 Redes de Estaes de Trabalho (NOW)

4.6.4 Mquinas Agregadas (COW)

4.7 Consideraes de Projeto

5 O Projeto Servidor de Estaes de Trabalho (SET)

40 Basicamente, o funcionamento das estaes de trabalho resume-se a:

Figura 5.1 Arquitetura do Projeto SET

5.2 Vantagens e Desvantagens

5.4 Estudo de Caso

5.5 Consideraes sobre o Projeto

6 Utilizao de Tcnicas de Cluster no Projeto SET

6.1 Tecnologia openMosix

6.1.1 Algoritmos de Compartilhamento de Recursos

6.1.2 Migrao de Processos

6.1.3 Acesso a Arquivos

6.2 Vantagens e Desvantagens do openMosix

6.3 Software de Gerenciamento

6.3.2 Gerenciando Processos

6.3.3 Histrico de Utilizao

6.3.4 Monitorando Migraes

7 Testes de Desempenho no Cluster

7.1 Ambiente de Testes

58 com uma arquitetura SET.

7.2 Procedimentos e Tcnicas

7.3 Testes e Resultados 7.3.1 FLAC (Free Lossless Audio Encoder)

Grfico 7.1 Tempo de codificao para 3 arquivos de udio

7.3.2 POVRay (Persistence of Vision Raytracer)