Beruflich Dokumente
Kultur Dokumente
Goinia a 2005
Monograa apresentada ao Curso de Redes de Comunicaao da CEFET-GO, como requisito para a c obteno do grau de TECNOLOGO em Redes de ca Comunicaao. c
Goinia a 2005
JUNIOR e FREITAS, ESLI E REINALDO Construindo Supercomputadores com Linux / ESLI E REINALDO JUNIOR e FREITAS - 2005 190.p
1.Construindo Supercomputadores com Linux-Redes. I.T tulo. CDD 536.7 CDU 536.21
Monograa apresentada ao Curso de Redes de Comunicaao da CEFET-GO, como requisito para c a obteno parcial do grau de TECNOLOGO em ca Redes de Comunicaao. c
BANCA EXAMINADORA
Resumo
Trata-se de um trabalho cujo objetivo propor a construo de supercomputadores com e ca alto poder de processamento com sof twares livres. Discorremos sobre conceitos bsicos sobre Clusters, vantagens e aplicaes. Apresentamos a co dois tipos de Clusters, Beowulf e OpenMosix, e ferramentas de administrao. ca Depois expomos um roteiro de implementao de um Cluster Beowulf, no estilo passo-aca passo. Tambm demonstramos algumas aplicaoes e funcionamentos das bibliotecas de e c programao paralela, apresentando os resultados obtidos. ca Por m, tratamos dos ajustes necessrios para obtenao de rendimento mximo do Clusa c a ter.
Abstract
One is about a work whose objective is to consider the construction of supercomputers with high being able of processing with free softwares. We discourse on basic concepts on Clusters, advantages and applications. We present two types of Clusters, Beowulf and OpenMosix, and tools of administration. Later we display a script of implementation of a Cluster Beowulf, in the style step-bystep. Also we demonstrate some applications and functionings of the libraries of parallel programming, presenting the gotten results. Finally, we deal with the necessary adjustments for attainment of maximum income of the Cluster.
Agradecimentos
` A Deus o autor e o consumador de nossa f. e Aos nossos pais, irmos, tios, primos, nossas respectivas namoradas e amigos. a Aos nossos colegas que foram at o nal com a gente ( Luciano, Maria Amlia, Cristiane, e e Erika, Srgio, Nyron ), e aos nossos colegas que no puderam concluir conosco. e a a Aos professores, orientadores pelas cr ticas e sugestes e por nos honrar com suas preo senas em nossa banca examinadora. c Aos professores do Departamento de Redes de Telecomunicaoes pelos seus ensinamentos c e aos nossos colegas e amigos de curso. Ao professor Cloves por nos ajudar e lutar por esse trabalho. Ao Clio, Wagsley e e Cristhian (Universidade Salgado de Oliveira ). Ao Fbio pela fora e nimo para nos ajudar a carregar e montar o cluster. a c a
O caminho do homem justo como a e luz da aurora que vai brilhando mais e mais at ser dia perfeito. e Provrbio de Salomo e a
Indice
9 10 11 12
O que . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 e Tipos de Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1 2.2.2 Cluster de Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . 13 Cluster de Alta Performance de Computaao . . . . . . . . . . . . . 14 c
2.3 2.4
Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Aplicaoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 c 20 24
4.2 4.3
PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 34
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.3 8.4
PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 63
10.1 Distribuiao baseada em Beowulf . . . . . . . . . . . . . . . . . . . . . . . 68 c 10.2 Boot Remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 10.3 Distribuiao em Floppy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 c 10.4 LinuxBios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 10.5 Sistemas de Arquivos Distribu do . . . . . . . . . . . . . . . . . . . . . . . 69 11 Concluso a I Programas Utilizados I.1 70 71
Stress1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7
I.2
Stress2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 81
II Arquivos de Congurao ca
II.1 machines.LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 II.2 .rhosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 II.3 .xpvm hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 II.4 bashrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 II.5 mpipov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 II.6 Makele.aimk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Bibliograa 99
Lista de Figuras
4.1 5.1 5.2 5.3 6.1 8.1 8.2 8.3 8.4 8.5 8.6 8.7
Bwatch sem carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Bwatch sem escravo1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 OpenMosixView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 XPVM - Ns do Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 o XPVM - Sa da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Diviso dos Processos - pvmmake . . . . . . . . . . . . . . . . . . . . . . . 57 a Utilizaao - pvmmake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 c XPVM - Linha do Tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Renderizaao Parcial do POVRAY . . . . . . . . . . . . . . . . . . . . . . 60 c Renderizaao completa do POVRAY . . . . . . . . . . . . . . . . . . . . . 61 c
Lista de Tabelas
11
1 Introduo ca
O mercado necessita de investimentos tecnolgicos, e que geralmente so caros. O Cluso a ter Beowulf pode ser uma soluao para empresas de mdio porte e universidades. Essas c e solues so baratas, o que torna fcil e acess a criaao de supercomputadores. Em co a a vel c conseqncia promove o desenvolvimento de novas tecnologias, permite renderizaao de ue c grcos em alta velocidade, viabiliza simulaoes e outras tarefas que utilizam grande poder a c de processamento. O principal objetivo desse trabalho avaliar o funcionamento de um Supercomputae dor Beowulf, apresentando vantagens, desvantagens, viabilidades. Todas as etapas sero a demonstradas e explicadas nesse processo de construao do cluster. c
12
2 Cluster
2.1 O que e
Do ingls, cluster signica: grupo compacto de coisas do mesmo tipo; agrupar(-se); e juntar(-se). Neste caso, Cluster um conjunto de mquinas (especicamente, PCs) e a interligadas via rede que trabalham em conjunto trocando informaoes entre si em torno c de uma unica tarefa.[01] O termo clustering refere-se atualmente a um nmero de diferentes tecnologias e conu guraes. co Um cluster pode ser denido como um conjunto de ns processadores (Personal Computo ers ou estaes) autnomos e que interligados comportam-se como um sistema de imagem co o unica. O conceito de imagem unica dita que um sistema paralelo ou distribu indepen do, dente de ser composto por vrios processadores ou recursos geogracamente distribu a dos, deve comportar-se com um sistema centralizado do ponto de vista do usurio. Dessa a forma, todos os aspectos relativos ` distribuiao de dados e de tarefas, comunicao e sina c ca cronizao entre tarefas e a organizao f ca ca sica do sistema devem ser abstra dos do usurio, a ou seja, devem ser transparentes a ele. Os ns de uma rede tendem a ser menos complexos do que os ns de um cluster, uma vez o o que em sua maioria correspondem a PCs ou estaoes monoprocessadas. Os ns de um c o cluster podem conter dois ou quatro processadores, sendo de igual ou maior complexidade do que mquinas MPP (mquinas proprietrias de processamento massivo), se levarmos a a a em considerao a presena de discos e sistemas operacionais completos no primeiro em ca c comparao com a ausncia de discos e sistemas operacionais baseados em microkernel no ca e segundo. Mquinas SMP (mquinas multiprocessadas) geralmente so mais complexas, a a a pois podem conter um nmero maior de processadores. u O fornecimento de imagem unica ou transparncia maior em mquinas SMP, que o e e a suportam em praticamente todos os n veis da arquitetura. Mquinas MPP suportam a esse conceito em apenas alguns n veis (por exemplo, aplicao). Os clusters provem ca e transparncia em um n e vel comparvel ao de mquinas MPP - o sistema operacional a a encarrega-se da gerncia dos vrios processadores e as ferramentas mais recentes de gerene a
13
ciamento permitem uma viso centralizada de todos os ns do cluster. As redes de estaes a o co no suportam esse conceito, visto que a autonomia dos ns impe mltiplas imagens. a o o u Essas arquiteturas ainda podem ser comparadas em relao ao tipo de sistema operacional ca que utilizam (monol tico ou modular e heterogneo ou homogneo), em relao ao modelo e e ca de comunicaao empregado (memria compartilhada ou troca de mensagens) ou ainda ao c o protocolo e tecnologia de rede utilizada.
2.2
Tipos de Clusters
Existem trs tipos de clusters: Alta Disponibilidade (HA- High Availability), Alta Pere formance (HPC- High Performance Computing) e cluster Combo que combina as caracter sticas dos anteriores. O cluster HA tem nalidade de manter um determinado servio c de forma segura o maior tempo poss vel. O cluster de HPC uma conguraao designada e c a prover grande poder computacional, maior que somente um unico computador poderia oferecer em capacidade de processamento.
2.2.1
Um cluster de alta disponibilidade tem como funo essencial deixar um sistema no ar ca vinte e quatro horas por dia, sete dias por semana, ou que no suporte paradas de meia a hora ou alguns minutos. So estas paradas no planejadas que inuenciam diretamente a a na qualidade do servio e nos preju c zos nanceiros que estas podem acarretar. Atualmente os computadores crescem em todos os ambientes empresariais, comerciais, e at mesmo domsticos e nenhum usurio quer que seu equipamento pare de funcionar. e e a E a alta disponibilidade vem a tpico para resolver esse tipo de situao, garantindo a o ca continuidade da operaao do sistema em servios de rede, armazenamento de dados ou c c processamento, mesmo se houver falhas em um ou mais dispositivos, sejam eles hardware ou software. Nos clusters de alta disponibilidade, os equipamentos so usados em conjunto para mana ter um servio ou equipamento sempre ativo, replicando servios e servidores, o que evita c c mquinas paradas, ociosas, esperando apenas o outro equipamento ou servio paralisar, a c passando as demais a responder por elas normalmente. E claro que com isso poderemos
14
ter perda de performance e poder de processamento, mas o principal objetivo ser ala canado, ou seja, no paralisar o servio. c a c A disponibilidade dos sistemas torna-se ento uma questo vital de sobrevivncia emprea a e sarial, ou seja, se o sistema parar a empresa pra. Um sistema de comrcio eletrnico, a e o como venda de livros por exemplo, no admite indisponibilidade. De maneira geral, um a servidor de boa qualidade apresenta uma disponibilidade de 99,5% enquanto que uma soluo atravs de cluster de computadores apresenta uma disponibilidade de 99,99%.[02] ca e Alto desempenho e balanceamento de carga em um cluster no signica necessariamente a alta disponibilidade. Como referncia podemos citar alguns trabalhos em linux open e source sobre alta disponibilidade: LVS - Linux Vitual Server: O objetivo neste projeto o balanceamento de carga e e alta disponibilidade em um cluster de servidores, criando a imagem de um unico servidor virtual. Eddiware : Atua com escalabilidade de servidores web, consistindo em um servidor de balanceamento HTTP, um servidor DNS aperfeioado, usa tcnicas de duas c e camadas com o frontend e backend, fazendo roteamento de trfego. a TurboLinux Cluster: Baseado na soluo da distribuio asitica TuboLinux, prov ca ca a e alta disponibilidade para roteadores e servidores, e baseado no LVS, inseres no e co kernel(patch), tunneling, ferramentas de instalao e congurao. ca ca Ento conclui-se que os clusters de alta disponibilidade e balanceamento de carga compara tilham diversos mdulos como uma soluao para uma variedade de problemas relacionados o c a alto trfego de sites muito acessados, aplicaoes de misso cr a c a tica, paradas programadas, servios cont c nuos, dentre outros.
2.2.2
Este tipo de cluster tem como foco o alto desempenho(o que a meta do nosso trabalho), e algoritmos de processamento paralelo, construoes de aplicaoes paralelas. c c Um cluster de computadores pode ser visto como uma soluo alternativa para univerca sidades e empresas de pequeno e mdio porte, para obterem processamento de alto dee sempenho na resoluao de problemas atravs de aplicaes paralelizveis, a um custo c e co a
2.3 Vantagens
15
razoalvelmante baixo se comparado com os altos valores necessrios para a aquisio de a ca um supercomputador na mesma classe de processamento. Quando se fala em processamento de alto desempenho, que pode ser traduzido em processamento paralelo e processamento distribu do, muitas pessoas pensam em grandes mquinas dedicadas (supercomputadores), que custam milhes de dlares, dif a o o ceis de serem operados e com salas superprotegidas. Mas hoje em dia, devido aos clusters, os custos foram reduzidos e existem mquinas muito rpidas, o que viabiliza o uso do proa a cessamento de alto desempenho na soluo de problemas em diversas reas. ca a A vantagem do custo bvia, pois uma dzia de estaoes de trabalho custa muito menos eo u c do que o mais barato dos supercomputadores. Outra vantagem a facilidade de se montar e um cluster: tudo o que se precisa so duas ou mais estaoes de trabalho ou computadores a c pessoais conectados por uma rede padro, como Ethernet por exemplo, e todo o software a necessrio pode ser obtido em um dom a nio pblico atravs da Internet. u e O cluster HPC um tipo de sistema para processamento paralelo ou distribu que e do consiste de uma coleo de computadores interconectados, trabalhando juntos como um ca recurso de computaao simples e integrado. Um n do cluster pode ser um simples sisc o tema multiprocessado (PCs, estaes de trabalho ou SMPs) com memria, dispositivo co o de entrada/sa de dados de um sistema operacional. No entanto, esse sistema pode da fornecer caracter sticas e benef cios (servios rpidos e conveis) encontrados somente c a a em sistemas com memria compartilhada (Multiprocessadores Simtricos- SMP), como o e os supercomputadores.
2.3
Vantagens
Com a adoao de um cluster, sua empresa passa a dispor de recursos computacionais c equivalentes aos de um supercomputador de milhes de dlares com custos incomparavelo o mente menores. Grandes corporaoes precisam de grande poder computacional a um baixo custo para renc derizar grcos em alta velocidade, prever o clima, fazer simulaoes de exploses atmicas a c o o e outras tarefas que exigem mquinas com alto desempenho. Empresas que trabalham com a servios de misso cr c a tica precisam de alta disponibilidade para garantir que equipamentos hospitalares e sistemas pblicos de emergncia estejam sempre acess u e veis e funcionando. Manter apenas um computador realizando apenas uma tarefa importante, no garantia a e
2.3 Vantagens
16
segura de que o servio vai estar sempre dispon c vel, pois problemas de hardware ou software podem causar a interrupao do servio. c c Os clusters fornecem desempenho e tolerncia a falhas, no encontradas em qualquer a a sistema com Multiprocessamento Simtrico (SMP). O desempenho escalvel atravs e e a e do simples acrscimo de computadores ao sistema. Os clusters tambm oferecem maior e e disponibilidade, pelo fato de que se um n falhar, os outros podem continuar fornecendo o servios de dados e a carga de trabalho dos ns defeituosos pode ser redistribu para os c o da ns restantes. o Dentre inmeras vantagens em se utilizar clusters, pode-se destacar algumas: u
Alto Desempenho - possibilidade de se resolver problemas muitos complexos atravs do processamento paralelo, diminuindo o tempo de resoluo do mesmo; e ca Escalabilidade - possibilidade de que novos componentes sejam adicionados ` mea dida que cresce a carga de trabalho. O unico limite capacidade da rede; e Tolerncia a Falhas - o aumento de conabilidade do sistema como um todo, caso a alguma parte falhe; Baixo Custo - a reduao de custo para se obter processamento de alto desempenho c utilizando-se simples PCs; Independncia de fornecedores - utilizaao de hardware aberto, software de uso e c livre e independncia de fabricantes e licena de uso. e c H algum tempo atrs, o paralelismo era vista como uma rara, extica e interessante sub a a o rea da computao, mas de uma pequena relevncia para o programador comum. a ca a Empresas de menor porte e universidades, com poucos recursos nanceiros podem recorrer a uma alternativa cada vez mais freqente para a obtenao do processamento de alto u c desempenho, a custos razoveis, aproveitando hardware existente. Essa alternativa pode a ser concretizada atravs do uso de clusters de computadores, com desempenho da ordem e de Gigaops, o que se tornou poss atravs do desenvolvimento e barateamento da vel e tecnologia das redes locais de alta velocidade e da evoluao dos processadores. c Atualmente, diversas instituioes cient c cas possuem clusters com um porte e poder computacional razovel, com nmero de computadores variando desde dois at milhares de a u e
2.4 Aplicaoes c
17
ns. No site www.top500.org, de atualizaao semestral, encontra-se uma relaao dos o c c supercomputadores proprietrios e dos clusters que possuem a maior capacidade de proa cessamento do mundo [03][04].
2.4
Aplicaes co
Clusters so recomendados para empresas que rodam sistemas pesados, banco de daa dos robustos, servidores de redes sobrecarregados, engenharia e aplicaoes de clculos c a cient cos, processamento de logs em provedores, portais de grande acesso e sites que enviam diariamente milhes de e-mails. o A rea de aplicaoes dos clusters muito diversicada. Em qualquer local onde tivera c e mos um grande problema computacional em que o processamento seja considerado uma vantagem, pode ser indicada a utilizao de um cluster. O processamento paralelo pode ca ser explorado atravs do desenvolvimento de aplicaoes paralelas, que uma tarefa sige c e nicativamente mais complexa e dif que o desenvolvimento de aplicaes seqenciais cil co u (aplicaes processadas em um unico processador)[05]. Algumas necessitam de enormes co quantidades de memria, algumas possuem tempo de processamento gigantesco, outras o fazem o uso elevado de comunicao. Em geral, elas resolvem problemas fundamentais ca que possuem grande impacto econmico e cient o co. So tidas como imposs a veis sem o uso de modernos computadores paralelos, por causa do tamanho das suas necessidades em matria de tempo de processamento, memria e de comunicaao. e o c Os computadores cada vez se tornam mais rpidos, devido ao fato de que uma nova a tecnologia em particular satisfaa as aplicaes conhecidas, novas aplicaoes ultrapasc co c saro o limite destas tecnologias e demandaro o desenvolvimento de novas tecnologias. a a Tradicionalmente, o desenvolvimento de computadores tem sido motivado por simulaoes c numricas de sistemas complexos como tempo, clima, dispositivos mecnicos, circuitos e a eletrnicos, processos de manufaturamento e reaes qu o co micas. Estas aplicaoes incluem videoconferncia, ambientes de trabalhos cooperativo, diagnsticos c e o em medicina, base de dados paralelos utilizados para suporte a decises e grcos avanados o a c em realidade virtual, particularmente na indstria do entretenimento. Por exemplo, inu tegrao de computaao paralela, redes de alto desempenho e tecnologias de multim ca c dia esto conduzindo para o desenvolvimento de servidores de v a deo, projeto de computadores para servir centenas ou milhares de requisies simultneas para v co a deos de tempo real.
2.4 Aplicaoes c Alguns exemplos de reas onde a utilizaao de clusters pode ser indicada so: a c a
18
Servidores de Internet - o grande crescimento de utilizaao de Internet revelou c fragilidades nos sites muito visitados. Um cluster pode distribuir a carga e aumentar a capacidade de resposta; Segurana - a grande capacidade que o processamento paralelo oferece beneciar c a qualquer processo para identicaao, quebra na segurana (criptograa) e vericao c c ca de poss veis solues; co Bases de Dados - pesquisas intensivas (cujo o tempo-resposta seja pequeno) em banco de dados podem demorar muito tempo em um sistema comum. A utilizaao c de um cluster pode reduzir esse tempo signicativamente; Computao Grca - nesta rea, muito comum o tempo de processamento ca a a e ser uma limitao para a evoluao da qualidade dos projetos. A utilizao de um ca c ca cluster pode diminuir o tempo de renderizaao de imagens durante a elaborao de c ca um lme, por exemplo; Aerodinmica - produoes de novas capacidades tecnolgicas e econmicas na a c o o presso enfrentada em aeronaves, lanamento de naves espaciais e nos estudos de a c turbulncia; e Anlise de elementos nitos - clculos de barragens, pontes, navios, avies, a a o grandes edif cios, ve culos espaciais; Aplicaes em sensoriamento remoto - anlise de imagens de satlite para a co a e obtenao de informaoes sobre a agricultura, orestas, geologia, fontes h c c bridas; Inteligncia articial e automao - processamento de imagens, reconhecimento e ca de padres, viso por computador, reconhecimento de voz, mquinas de intero a a ferncia; e Engenharia Gentica - projeto Genoma; e Explorao s ca smica - empregado especialmente pelas companhias petrol feras para determinaao de local de poos de petrleo; c c o
2.4 Aplicaoes c
19
Oceanograa e astrof sica - exploraao de recursos dos oceanos, estudo da formao c ca da terra, dinmica das galxias; a a Previso do tempo - um processo demorado e com pouca preciso quando gerado a a atravs de computadores seqenciais; e u Pesquisas militares - projeto de armas nucleares, simulao dos efeitos das armas, ca em especial as radioativas, processamento de sinais de radares para o comando de m sseis antibal sticos, geraao automtica de mapas, acompanhamento de submaric a nos; Problemas de pesquisa bsica - em qu a mica, f sica e engenharia, tais como mecnica quntica, mecnica, estat a a a stica, qu mica de pol meros, crescimento de cristais, anlise de trajetrias de part a o culas, dinmica dos uidos, teoria do campo a quntico, dinmica molecular, equaoes de circuitos de alta escala, distribuio de a a c ca conexes em circuitos VLSI; o Segurana de reatores nucleares - anlises das condies do reator, controle c a co automtico, treinamento atravs de simulaao de operaoes, atuaao rpida em a e c c c a caso de acidente;[01]
20
21
Linux apareceram na lista de discusso do Minix (comp.os.minix). A idia era desena e volver um sistema operacional Unix para mquinas de pequeno porte que explorasse novas a funcionalidades dispon veis nos processadores 80386, como interface de modo protegido. Facilidades estas que no eram exploradas pelo Minix.[06] a A distribuiao Linux que adotamos neste trabalho o Conectiva, devido a facilidade de c e instalar e remover aplicativos atravs do apt-get (aplicaao que facilita a instalao e e c ca remoo de pacotes) e principalmente por ser uma distribuiao brasileira que possui manca c uais traduzidos para o portugus. Mais observa-se que todos aplicativos utilizados neste e trabalho esto no formato RPM e tar.gz. a Muitas pessoas novas ao software livre encontram-se confusas porque a palavra free no termo free software no usada como elas esperam. Para eles free signica sem a e custo. Um dicionrio de ingls lista quase vinte signicados para a palavra free. Apea e nas uma delas sem custo. O resto se refere ` liberdade e falta de obrigaao. Quando e a c falamos de Software Livre falamos de liberdade, no de preo. a c Sof tware que livre apenas no sentido de no ter de pagar para usar dicilmente e a e livre no nal das contas. Voc pode ser impedido de pass-lo para frente e quase certae a mente impedido de melhor-lo. Software licenciado sem custo normalmente uma arma a e numa campanha de marketing para promover um produto ligado a ele ou para tirar um competidor menor do mercado. No h garantia de que ele continuar livre. a a a O verdadeiro sof tware livre ser sempre livre. Software que colocado no dom pblico a e nio u pode ser pego e colocado em programas no-livres. Quaisquer melhoras feitas, assim, so a a perdidas para a sociedade. Para car livre, o software precisa ter copyright e licena. c Para os no-iniciados, ou um software livre ou no. Para entender que tipos de coisas a e a as pessoas esto colocando quando chamam o software de software livre apresentaremos a conceitos sobre licenas de sof tware. c Os copyrights so um mtodo de proteger os direitos do criador de certos tipos de traa e balhos. Na maioria dos pa ses, o software que voc escreve tem automaticamente um e copyright. Uma licena o jeito de o autor permitir o uso de sua criaao (sof tware nesse c e c caso) a outros, de maneiras aceitveis para ele. Cabe ao autor incluir uma licena que a c declara em que maneiras o software pode ser usado.[07] Claro, diferentes circunstncias chamam por diferentes licenas. As companhias de softa c ware esto procurando proteger-se para apenas lanarem cdigo compilado (que no a c o a e leg para humanos) e colocar muitas restrioes no uso do software. vel c
22
Software livre (open-source) um conceito de extrema importncia no mundo da come a putao. De forma bsica, quando um software livre, signica que seu cdigo-fonte est ca a e o a dispon para qualquer um e voc pode alter-lo para adequ-lo `s suas necessidades, vel e a a a sem ter que pagar. Portanto, software livre, de fato gratuito, mas usar este termo soe mente para designar sof twares sem custo, um erro grosseiro. e Uma das maiores vantagens do Software Livre sua colaboraao com qualquer projeto ou e c trabalho de incluso digital, seja por meio da reduo de custos de licenas de software, a ca c seja por reduo no preo da aquisiao de hardware ou ainda na otimizao de pessoal. ca c c ca Mas nem s disso vive a incluso digital. Tambm se faz necessria a disponibilizaao o a e a c de cdigo-fonte como forma de ampliao e compartilhamento do conhecimento para seus o ca usurios. E essa uma das premissas do software livre, a partilha do cdigo e sua disponia e o bilizao para quem desejar. ca No caso do Linux, a sua licena de uso, a GPL. A GPL, sigla para GNU Public Lic e cense, uma das formas mais conhecidas de distribuio de programas. A maior parte e ca dos sof twares para Linux baseada na licena GPL. Vale dizer que uma licena um e c c e documento que permite o uso e distribuio de programas dentro de uma srie de circa e cunstncias. E uma espcie de copyright (direitos autorais) que protege o proprietrio do a e a programa. Tendo copyright, o dono pode vender, doar, tornar freeware, enm. No nosso caso, a licena GPL faz exatamente o contrrio. Ela permite que voc copie o c a e programa, instale em quantos computadores quiser, veja, estude, altere o cdigo-fonte e o no pague nada por isso. A GPL no simplesmente um texto que diz o que voc deve a a e e fazer para desenvolver um software livre. E, resumidamente, um documento que garante a prtica e existncia do mesmo. Sua losoa consiste em defender vrios pontos, dentre a e a as quais, destacam-se os mais importantes abaixo: Liberdade para executar um programa para qualquer nalidade; Liberdade para estudar um programa, e adapt-lo `s suas necessidades; a a Liberdade de distribuir cpias e assim ajudar um colega, uma instituiao qualquer; o c Liberdade de melhorar o programa e entreg-los ` comunidade. a a Para um software ter licena GPL, deve seguir essas quatro liberdades. Esta uma licena c e c pertencente ` Free Software Fundation, que como o prprio nome diz, uma organizaao a o e c a que trabalha em prol do software livre. E vlido dizer que o conceito de software livre
23
no se aplica somente ao Linux. Qualquer programa, independente da plataforma, pode a ter cdigo aberto. O navegador de Internet Mozilla por exemplo, possui cdigo fonte o o dispon tanto para Linux, como para Windows e outros sistemas operacionais. vel O software livre, sem dvida, essencial no s para a concepao e uso de programas, u e a o c mas tambm por ser de grande importncia em pesquisas e avanos tecnolgicos, princie a c o palmente em pa com problemas nanceiros. ses
24
4 Beowulf
Em 1993, Donald Becker e Thomas Sterling comearam a esboar um cluster que sec c ria uma alternativa de baixo custo aos grandes supercomputadores. Em 1994 o projeto Beowulf foi iniciado no CESDIS (Center of Excellence in Space Data and Information Sciences) da NASA, sob o patroc do projeto HPCC/ESS (High Performance Computing nio Cluster/Earth and Space Sciences). O prottipo inicial consistia em um conjunto de 16 computadores Intel 486 DX4 conectao dos por uma rede Ethernet 10Mbps. O cluster teve um sucesso imediato e sua idia de usar e produtos de prateleira para satisfazer exigncias computacionais espec e cas fez com que ele se espalhasse dentro da NASA e nas comunidades acadmicas e de pesquisa.[08] e O Beowulf portanto uma pilha de PCs comuns, com algumas caracter e sticas especiais: Nenhum componente feito sob medida; Independncia de fornecedores de hardware e software; e Perifricos escalveis; e a Software livre e de cdigo aberto. o O Beowulf pode ser implementado atravs de modicaes no kernel do Linux, ou atravs e co e do uso de ferramentas e bibliotecas de programaao espec c cas para esse m[09][10]. Em todos os casos, o objetivo permitir a distribuiao das tarefas entre os PCs que fazem e c parte do cluster.[11][03]
4.1
BProc
O BPROC(Beowulf Distributed Process) tem como objetivo criar um sistema de viso a unica para os processos (Single Process Space) em um cluster Beowulf. BProc consiste em quatro partes bsicas. No n mestre, h o processo ghost que suporta todos os a o a processos remotos. H tambm o daemon mestre que determina as mensagem para o a e
4.1 BProc
25
sistema e tambm mantm a informaao do estado sobre a existncia e a localidade dos e e c e processos. Nos ns slave h o ID process que engana o sistema fazendo com que os o a processos que esto no n sejam enxergados no mestre. H tambm um daemon simples a o a e no lado slave que comunica o kernel dos ns escravos com a rede.O BPROC um cono e junto de modicaes no kernel (ncleo do sistema operacional), utilitrios e biblioteca co u a para a funo de iniciar processos de usurios em outras mquinas em um cluster Beowulf. ca a a
4.1.1
Processos Ghost
Estes representam no f rontend, os processos remotos, que executam nos restantes ns o sobre a monitorao dos slaves daemons. Estes processos no tm espao de memria, ca a e c o arquivos associados nem contexto. No entanto, possuem signal handlers e las de mensagens. A sua funcionalidade o seguinte: e (1) Encaminham os sinais que recebem para os respectivos processos remotos que representam; (2) Efetuam fork() (funao da linguagem de programaao C que divide processos)a c c pedido do respectivo processo remoto. Quando um processo remoto pretende efetuar fork() necessrio obter o PID do processo lho a ser criado a partir do master e a daemon, que quem gera o espao de processos distribu e c dos. Isto conseguido e atravs do seu processo ghost, que efetuam fork() e retorna o PID do lho ao n e o remoto atravs do Mascaramento de PIDs efetuado pelo slave daemon no n de e o destino; (3) Sempre que um processo efetua wait() o respectivo ghost deve fazer o mesmo para impedir a acumulaao de processos ghost zombies na rvore de processos; c a (4) Sempre que um processo remoto efetua um exit() o seu cdigo de terminaao o c e enviado ao respectivo ghost que tambm efetua o exit() com mesmo cdigo de e o terminaao, o que permite que wait() no processo pai remoto receba a informao c ca sobre o trmino do respectivo processo lho (que poderia encontrar-se em execuo e ca em qualquer outro n do sistema). o
4.1 BProc
26
No entanto, estes processos espelham o estado dos processos remotos que so representaa dos. A informaao acerca desses processos remotos representada no /proc le system em c e vez da informao acerca dos prprios processos ghost, que so invis ca o a veis para o utilizador. Essa informaao atualizada a pedido (por consulta de /proc utilizando o comando top c e por exemplo) e tambm periodicamente. Neste sentido, /proc passa a ser designado Unie ed /proc File System, ou espao unicado no sistema de arquivos proc. c
4.1.2
Mascaramento de PID
Os ns remotos executam em uma parte da sua rvore de processos de frontend. Para o a alm desses processos podem existir outros processos iniciados por rsh por exemplo, que e devem coexistir com os processos remotos controlados pelo BPROC, iniciados utilizando as primitivas indicadas. Quando se desloca um processo de um n para o outro, o seu PID o no deve mudar devido as dependncias que existem entre diversos processos. Para que a e tal seja poss vel, o slave daemon cria e controla um espao de processos local que um c e subconjunto do espao de processos do master daemon. Neste subespao, os processos tm c c e o mesmo identicador dos processos ghost correspondentes - isto designa-se de Mascaramento de PID. Podem eventualmente existir outros processos no n associados a diferentes o daemons e conseqentemente a diferentes espaos de processos que no interferem entre si. u c a
4.1.3
Daemons
O master daemon armazena a informao sobre as conguraes dos ns e conhece a ca co o localizao de todos os processos no seu espao de endereamento. E responsvel pela ca c c a criao da imagem de uma unica rvore de processos. Os slaves daemons atuam como ca a intermedirios entre os processos remotos e o master daemon. Representam um subcona junto do espao de processos global e efetuam o Mascaramento PID nesse subespao. c c
4.2 PVM
27
4.2
PVM
A idia do Parallel Virtual Machine consiste em montar uma mquina virtual de n proe a cessadores e us-los para executar tarefas simultneas. O PVM dividido em trs partes a a e e principais:
daemon: um programa que roda em cada mquina do ambiente estabelecendo a a comunicaao entre as diversas mquinas. c a
biblioteca: na biblioteca que reside as funoes e sub-rotinas que instruem o e c cdigo a dividir as tarefas entre os daemons. o A biblioteca dispe de recursos que possibilitam manipular qualquer coisa do seu ambiente o virtual, pode-se manipular o tempo de execuao, embora no seja muito bom. Devido c a ao custo computacional de se adicionar e retirar mquinas em tempo de execuao. O a c
4.2 PVM
28
ideal criar a mquina virtual fora do cdigo, atravs do console, e us-la vrias vezes, e a o e a a ou mesmo deix-la ativa enquanto as mquinas estiverem ligadas, alm de possibilitar a a e disparar e matar processos a partir do console. A biblioteca de programaao paralela PVM (Parallel Virtual Machine) foi produzido pelo c Heterogeneous Network Project, um esforo conjunto da Oak Ridge National Laboratory, c University of Tenesse, Emory University e Carneige Mellon University, em 1989, para facilitar o campo da computaao paralela heterognea. O PVM foi um dos primeiros c e sistemas de software a possibilitar que programadores utilizassem uma rede de sistemas heterogneos (mquinas diferentes com sistemas operacionais diversos) ou sistemas MPP e a (Massively Parallel Processors) para desenvolver aplicaoes paralelas sobre o conceito de c passagem de mensagens. Esta biblioteca ou API de programao tem sido muito difunca dida em ambientes computacionais cient cos e recentemente tem ganho muitos adeptos tambm no campo de aplicaoes comerciais devido ` sua capacidade de portabilidade, e c a sendo referenciada como o padro de facto em sua rea. a a Um cluster consiste basicamente em processos trocando mensagens sobre uma rede de comunicaao e o PVM possui muitas funoes de recebimento e envio de mensagens. O c c pacote PVM relativamente pequeno (cerca de 4.5Mb de cdigo fonte em C), roda sobre e o ambiente Unix, seus derivados e Windows NT, e necessita ser instalado apenas uma vez em cada mquina para ser acess a todos os usurios. Alm disso, a instalao no a vel a e ca a requer privilgios especiais e pode ser efetuada por qualquer usurio. e a O daemon chamado pvmd3, que reside em todas as mquinas que compem o cluster, e a o criando o que se refere como uma mquina virtual paralela. Quando um usurio deseja a a usar uma aplicaao PVM, ele executa o daemon pvmd3 em um dos seus computadores do c cluster, no qual responsabiliza-se por chamar outros processos daemons pvmd3 escravos em cada computador da mquina paralela virtual. Uma aplicaao PVM pode ento ser a c a iniciada em um prompt Unix em qualquer console do cluster. A biblioteca de rotinas contm o padro de comunicao do PVM. Esta biblioteca contm e a ca e rotinas chamveis pelo usurio para passagem de mensagens, criaao de processos, sina a c cronizao de tarefas e modicao da mquina virtual. As aplicaoes devem ser ligadas ca ca a c com esta biblioteca para poderem usufruir do ambiente paralelo criado pelo PVM. A biblioteca PVM pode ser baixada no site www.epm.ornl.gov/pvm/ e pode ser utilizada em uma rede com Linux e Windows NT, podendo-se, com isso utilizar um combinado de computadores com Windows NT e Unix.[12][13]
4.2 PVM
29
A principal idia por trs do PVM utilizar um conjunto de computadores heterogneos e a e e interconectados, como um recurso virtualmente unico. Cada computador existente na rede pode ser utilizado como sendo um n da mquina paralela virtual. O papel de cono a sole da mquina paralela assumido pelo prprio n local onde o usurio est localizado a e o o a a sicamente. O usurio pode alocar qualquer n da rede localmente, ou a longa distncia, a o a desde que o mesmo esteja devidamente autorizado. Este ambiente constitu de uma e do biblioteca de rotinas em C e FORTRAN, onde o usurio pode escolher qual protocolo a de camada de transporte deseja utilizar, TCP ou UDP, no envio e recebimento de mensagens. Em ambos os casos as mensagens so empacotadas (STUB) antes do envio e a desempacotadas pelo processo receptor. Estes procedimentos geram uma sobrecarga extra (overhead). Um daemon mestre cria os diversos daemons escravos na mquina do cluster via remote a shell - rsh, os quais devem estar devidamente congurados em todos os host antes do uso do PVM. Vejamos algumas caracter sticas importantes do PVM:
Quanto a interoperabilidade: alm da portabilidade, os programas podem ser execu` e tados em arquiteturas completamente diferentes; Abstracao completa: o PVM permite que a rede seja totalmente heterognea, admine istrada como uma unica mquina virtual; a Controle de processo: capacidade de iniciar, interromper e controlar processos, em tempo de execuao; c Controle de recursos: totalmente abstrato, graas ao conceito de mquina virtual parc a alela; T olerncia a f alhas: comporta esquemas bsicos de noticaao de falhas, para alguns a a c casos. Porm, permite exibilidade, de forma que, ainda em certas situaoes onde no e c a existe resposta de um n, uma aplicao receba os resultados das outras. o ca
H muitas formas de se melhorar a performance com o PVM, mas a verdade que no a e a h uma receita ou mtodo a ser seguido, pois tudo depende da arquitetura do cluster, a e da velocidade da rede, das conguraoes dos sistemas e de muitos outros fatores determic nantes que devem ser avaliados no momento de se escolher uma metodologia para resolver determinado problema.[14][15]
4.3 MPI
30
4.3
MPI
O MPI (Message Passing Interface) constitu por um padro de troca de mensagens e do a com sintaxe denida, mas preservando caracter sticas exclusivas de cada arquitetura, inclusive para arquiteturas de memria compartilhada. O MPI dene um conjunto de o rotinas para facilitar a comunicao (troca de dados e sincronizaao) entre processos em ca c memria, ela portvel para qualquer arquitetura, tem aproximadamente 125 funoes o e a c para programaao e ferramentas para anlise de performance. A biblioteca MPI possui c a rotinas para programas em linguagem C/C++, Fortran 77/90. Os programas so compia lados e ligados ` biblioteca MPI. a O principal objetivo do MPI otimizar a comunicaao e aumentar o desempenho come c putacional das mquinas, no possuindo dessa forma gerenciamento dinmico de processos a a a e processadores. Embora exista a restrio citada acima, os programas escritos em MPI tendem a serem ca mais ecientes pelo fato de no haver overhead na carga de processos em tempo de exa ecuo. ca O padro para Message Passing, denominado MPI (Message Passing Interface), foi proa jetado em um forum aberto constitu de pesquisadores, acadmicos, programadores, do e usurios e vendedores, representando 40 organizaes ao todo. a co No MPI Forum foram discutidos e denido a:Sintaxe, Semntica e o Conjunto de rotinas a padronizadas para Message Passing.[16][17] As principais caracter sticas do MPI so: a Ecincia - Foi cuidadosamente projetado para executar ecientemente em mquinas e a diferentes. Especica somente o funcionamento lgico das operaes. Deixa em o co aberto a implementaao. Os desenvolvedores otimizam o cdigo usando caracc o ter sticas espec cas de cada mquina. a Facilidade - Dene uma interface no muito diferente dos padres PVM, NX, Exa o press, P4, etc. e acrescenta algumas extenses que permitem maior exibilidade. o Portabilidade - E compat para sistemas de memria distribu NOWs (network vel o da, of workstations) e uma combinao deles. ca
4.3 MPI
31
Transparncia - Permite que um programa seja executado em sistemas heterogneos e e sem mudanas signicativas. c Segurana - Prov uma interface de comunicao convel. O usurio no precisa c e ca a a a preocupar-se com falhas na comunicaao. c Escalabilidade - O MPI suporta escalabilidade sob diversas formas, por exemplo: uma aplicaao pode criar subgrupos de processos que permitem operaoes de comuc c nicaao coletiva para melhorar o alcance dos processos. c A diferena bsica entre o MPI e o PVM que, ao contrrio do anterior, no MPI existe um c a e a unico cdigo fonte igual para todas as mquinas e conseqentemente um unico processo o a u rodando. O MPI funciona da seguinte forma: cada mquina (node) recebe uma cpia do cdigo a o o fonte e um nome. Cada n comea a executar o programa a partir da primeira linha o c de comando utilizando as seguintes diretrizes: Executar todas as linhas de comando no a nomeadas; Executar as linhas de comando nomeadas com o mesmo nome do node; No a executar as linhas de comando com o nome de outro node. Muitas implementaoes de bibliotecas do padro MPI tm sido desenvolvidas, sendo alc a e gumas proprietrias e outras de cdigo livre, mas todas seguindo o mesmo padro de a o a funcionamento e uso. O esforo de padronizao MPI envolve cerca de 60 pessoas de c ca 40 organizaoes, principalmente dos Estados Unidos e da Europa. A maioria dos vendec dores de computadores paralelos e concorrentes esto envolvidos com o padro MPI, a a atravs de pesquisas em universidades e laboratrios governamentais e industriais. O e o processo de padronizaao comeou com um seminrio sobre o Centro de Pesquisas em c c a Computao Paralela, realizada em 29 e 30 de abril de 1992 em Williamsburg, Virginia. ca Nesse seminrio, as caracter a sticas essenciais para uma padronizao de uma interface de ca passagem de mensagem foram discutidas, sendo estabelecido tambm um grupo de trae balho para continuar o processo de padronizao. ca As funcionalidades que MPI designa so baseadas em prticas comum de paralelismo e a a outras bibliotecas de passagem de mensagens similares, como Express, NX/2, Vertex, Parmacs e P4. A losoa geral do padro MPI implementar e testar caracter a e sticas novas que venham a surgir no mundo da computaao paralela. Assim que uma deterc minada gama de caracter sticas novas tenham sido testadas e aprovadas, o grupo MPI rene-se novamente para considerar sua incluso na especicao do padro. Muitas das u a ca a
4.3 MPI
32
caracter sticas do MPI tm sido investigadas e usadas por grupos de pesquisas durante e muitos anos, mas no em ambiente de produao ou comerciais. Sendo assim, existe um a c grande espao de tempo entre novidades do padro e sua implementao por vendedores c a ca e colaboradores. Entretanto, a incorporao destas caracter ca sticas dentro do padro MPI a justicada pela expressivas inovaoes que elas trazem. e c O MPI implementa um excelente mecanismo de portabilidade e independncia de plataforma e computacional. Por exemplo, um cdigo MPI, que foi escrito para uma arquitetura IBM o RS-600 utilizando o sistema operacional AIX, pode ser portado para a arquitetura SPARC com o S.O.Solaris ou PC com Linux com quase nenhuma modicao no cdigo fonte da ca o aplicao. ca O MPI-1.2 uma extenso para o padro MPI-1 de 1992. H uma terceira especicaao e a a a c chamada MPI-2, que adiciona vrias extenses ` verso 1.2, sendo uma das mais ima o a a portantes o controle de processos dinmicos. Devido a diculdade de se encontrar uma a implementaao MPI-2 que seja distribu livremente, este trabalho restringe-se ao padro c da a ao padro MPI-1.2. Portanto, qualquer meno do padro MPI, refere-se na verdade, ao a ca a padro MPI-1.2. a A execuao de uma aplicaao executando esta API (Interface de Programao de Aplicaoes) c c ca c inicia um procedimento de disparar atravs de um processo pai seus processos lhos e para serem executados remotamente nos computadores escravos do cluster. Cada processo executa e comunica-se com outras instncias do programa, possibilitando a a execuo no mesmo processador e diferentes processadores. A melhor performance quando ca esses processos so distribu a dos entre diversos processadores. A comunicao bsica conca a siste em enviar e receber dados de um processador para o outro. Esta comunicaao se d c a atravs de uma rede de alta velocidade, no qual os processos estaro em um sistema de e a memria distribu o da. O pacote de dados enviados pelo MPI requer vrios pedaos de informaoes: o proa c c cesso transmissor, o processo receptor, o endereo inicial de memria onde os c o tens de dados devero ser mandados, a mensagem de identicao e o grupo de processos que poa ca dem receber a mensagem, ou seja, tudo isto car sob responsabilidade do programador a em identicar o paralelismo e implementar um algoritmo utilizando construoes com o c MPI.[18] Algumas implementaes do MPI: co MPI-F: IBM Research
4.3 MPI MPICH: ANL/MSU - Argonne National Laboratory e Missipi State University UNIFY: Missipi State University CHIMP: Edinburg Parallel Computing Center LAM: Ohio Supercomputer Center MPL: IBM Research
33
34
5 Administrao do Cluster ca
5.1 bWatch - Beowulf Watch
O bWatch um script escrito na linguagem interpretada grca Tcl/Tk designado para e a monitorar clusters. Sua tarefa observar a carga e o uso da memria em todos os ns do e o o supercomputador.[19] Este programa assume que na mquina na qual ele esteja rodando possa executar o rea mote shell (rsh) em todos os computadores listados na varivel $listO-fHosts. Ele tambm a e assume que seu interpretador wish esteja em /usr/bin/wish. Se voc no estiver com o e a Tcl/Tk instalado em seu computador, ento faa-o. a c
Figura 5.1: Bwatch com carga Esta ferramenta no necessita que voc esteja logado como root para funa e cionar, e pode ser executado por qualquer usurio cadastrado no sistema que possua a a permisso de executar comandos remotos via protocolo rsh (remote shell)para as outras a mquinas. a
O BWatch foi escrito especicamente para a plataforma Linux e poder no a a ser executado em qualquer outro sistema Unix a menos que seu sistema de arquivo possua o diretrio /proc; exatamente igual ao Linux. Esta ferramenta cona elmente no o sistema de arquivo /proc; assim, deve-se compilar este suporte dentro do kernel de todas
35
36
6 O Cluster OpenMosix
6.1 Cluster OpenMosix
O projeto Mosix - Multicomputer Operating System unIX - um sistema operacional e distribu do, desenvolvido originalmente pelos estudantes do professor Amnom Barak, na Universidade Hebrew em Jerusalm, Israel. Foi utilizado nos anos 80 pela fora rea e c a americana para a construao de um cluster de computadores PDP11/45. O projeto foi c desenvolvido em sete fases, para diferentes verses de UNIX e arquiteturas de computao dores. A primeira verso para PC foi desenvolvida para o BSD/OS. A ultima verso foi a a para o sistema operacional Linux em plataforma Intel. O OpenMosix uma extenso do projeto Mosix, baseado no GPLv2, iniciado em 10 de e a fevereiro de 2002, coordenado pelo Ph.D Moshe Bar, para manter os privilgios desta e soluo Linux para cluster dispon com software de cdigo aberto. ca vel o Este agrupamento de mquinas Linux o que poder a e amos classicar de verdadeiro sistema de imagem simples (SSI - Single System Image), pois j claro que a idia de que no se ae e a tem um cluster verdadeiro enquanto no existir um SSI. Podemos ter como referncia os a e primeiros clusters SSI como o IBM SysPlex e o cluster DEC. Em um cluster DEC voc e executa um telnet para um endereo no cluster e essa chamada ser atendida por qualc a quer n do cluster, e o usurio no precisa se preocupar com qual n que ir atender esta o a a o a chamada, e qualquer programa iniciado pelo usurio ser executado no n que possuir a a o maior disponibilidade de recursos para atender ao programa. O OpenMosix uma extenso do ncleo do Linux, que faz com que um cluster de come a u putadores se comporte como um grande e unico supercomputador atravs da utilizaao e c de migraao preemptiva de processos e balanceamento dinmico de carga. c a A implementao da Migrao Preemptiva de processos capaz de migrar qualquer proca ca e cesso do usurio, em qualquer instante e para qualquer n dispon de maneira transa o vel parente. Para atingir um melhor desempenho este controlado por Algoritmos de Bale anceamento Dinmico de Carga e de prevenao contra falta de memria. Estes algoritmos a c o so projetados para responder dinamicamente as variaoes da utilizao dos recursos nos a c ca diversos ns. Isto garante que o cluster se comporte muito bem, seja numa conguraao o c
37
com poucas ou com muitas mquinas, propiciando uma maior escalabilidade. Ou seja, se a o programa que estamos rodando em uma mquina consumir muitos recursos, o sistema a varre toda e rede e procura uma mquina mais dispon no momento em termos de a vel memria e CPU, e desloca seu programa ou parte dele para ser executado remotamente. o Com isso, o sistema ganha desempenho. Estes algoritmos so descentralizados, ou seja, no existe a conguraao de Controlador a a c Mestre e ns escravos como ocorre no Cluster Beowulf para computaao paralela. Cada o c n um mestre para os processos que so criados localmente, e um servidor para procesoe a sos remotos, migrados de outros ns do cluster. Isto signica que podemos acrescentar o ou remover as mquinas do cluster em qualquer momento, com um m a nimo de distrbio u no sistema. Este cluster possui tambm algoritmos de monitoramento que identicam e a velocidade de cada n, a carga da CPU, a memria livre dispon o o vel, a comunicaao c interprocessos IPC e a velocidade de acesso de cada processo. Como o OpenMosix opera de forma silenciosa e as operaes so transparentes para as co a aplicaes, ou seja, pode-se executar aplicaes seqenciais e paralelas como se fosse um co co u unico computador SMP (Symmetric Multi-Processor - Multiprocessamento simtrico). e Voc no precisa conhecer onde seus processos esto sendo executados, nem se preocupar e a a com que os outros usurios esto fazendo na rede por isso ele usa o acrnimo fork and a a o forget. O que ele faz , pouco tempo depois de iniciar os processos, o OpenMosix enviae os para um melhor computador da rede, o OpenMosix continua a monitorar os novos processos e os demais, e poder moviment-los pelos computadores com pouca carga de a a trabalho maximizando o trabalho e melhorando a performance. Aplicaes que se beneciam com o OpenMosix: co Processos CPU-bound: processos com longos tempos de execuao e baixo volume c de comunicao entre processos, ex: aplicaoes cient ca c cas, engenharia e outras aplicaoes que demandam alta performance de computaao. c c Grandes compilaes. co Para processos que misturam longos e rpidos tempos de execuao ou com quantias a c moderadas de comunicaao interprocessos, recomendado o uso das bibliotecas c e MPI/PVM amplamente utilizadas em computao paralela. ca Processos I/O bound misturados com processos da CPU: executados atravs do e servidor de arquivos, usando o sistema de arquivos distribu dos do OpenMosix, o
6.1 Cluster OpenMosix MFS (Mosix File System) e o DFSA (Distributed File System Architeture). Banco de dados que no usem memria compartilhada. a o Processos que podem ser migrados manualmente. As desvantagens do OpenMosix:
38
Processos com baixa computaao, como aplicativos com alta comunicao interproc ca cessos. Aplicaoes com memria compartilhada. c o Aplicaoes dependentes do hardware que necessitam de acesso a um perifrico de c e um n em especial. Aplicaoes com muitas threads no ganham desempenho. o c a No se ganha desempenho quando se roda um unico processo, tal como seu browser. a Aplicaoes testadas que no migraram sobre OpenMosix: c a Programas em Java usando threads nativas no migram desde que eles utilizem a memria compartilhada. Green Threads JVMs, entretanto, podem ser migradas o porque cada thread Java um processo separado. e Aplicaoes que usam pthreads. c MySQL, Apache, Oracle, Postgres, SAP, Baan, usam memria compartilhada. o Python com threading habilitada. VMware, este ao rodar o Win98, algumas vezes travou e em outras o emulador do SO parou. Voc dever ter muito cuidado quando usar o VMware com o OpenMosix. e a A caracter stica de no migrar uma situao normal para programas que fala e ca hariam ao serem movimentados pelo OpenMosix. Estes programas devem rodar como planejado no n onde foram iniciados. o
6.2 OpenMOSIXVIEW
39
6.2
OpenMOSIXVIEW
O OpenMosixview um gerenciador grco (GUI - Graphic User Interface), ele um e a e front-end para os comandos mosctl. Com esta aplicaao poss gerenciar e ajustar c e vel os principais parmetros deste cluster tais como: visualizar a carga de todos os ns do a o cluster, visualizao de processos remotos em outros ns, bem como executar ou transferir ca o processos para outros computadores que compem o cluster. o
Figura 6.1: OpenMosixView O OpenMosixview um conjunto de cinco ferramentas utilizadas para admine istrao e monitoramento do Cluster OpenMosix. So eles: ca a OpenMosixview: a aplicaao principal de administrao/monitoramento. c ca OpenMosixprocs: um box para gerenciamento de processos. OpenMosixcollector: coleta informaoes dos ns do cluster atravs de um processo c o e daemons para geraao de logs do sistema. c OpenMosixanalyzer: utilizado para a anlise dos dados coletados pelo OpenMosixa collector.
40
41
7 Implementao ca
### INSTALANDO O CONECTIVA 8 ### Siga os passos normais.[20][21][22] Em PERFIL DE INSTALACAO escolha Instalao REALMENTE M ca nima, e marque a opao Forar seleo de pacotes. c c ca Em SELECAO DE COMPONENTES, marque:
+ Minimal + Development Workstation + Linuxconf + C Development + C++ Development + Linuxconf modules + Sistema X Window + Window Maker + Aplica~es para Console co + Extra Development Files + Selecionar pacotes individuais Em SELECAO DE PACOTES, acrescente: Administrao: ca
+ apt-listchanges
Bibliotecas:
+ glibc + gmp2
42
Rede:
Utilitrios: a
+ unzip + zip
X11:
+ xterm
7 Implementaao c 127.0.0.5 127.0.0.6 127.0.0.7 127.0.0.8 escravo4 escravo5 escravo6 escravo7 escravo4 escravo5 escravo6 escravo7
43
Para que o protocolo RSH (Remote Shell) funcione corretamente, congure os arquivos /etc/host.equiv e /root/.rhosts, informando os nomes dos ns do cluster: o
Acrescente em /etc/securetty:
rsh rlogin
Para poder gerenciar os ns de forma segura, veja o manual do SSH (Secure Shell) e o congure o servidor SSH, editando o arquivo /etc/ssh/sshd cong.
Execute o ntsysv para congurar os servios que devem ser inicializados automaticamente: c
7 Implementaao c + netfs + network + nfs + nfslock + portmap + random + rawdevices + rlogin + rsh + sshd + syslog + xinetd
44
Reinicie a mquina. a
Baixe o iptables, dispon em www.iptables.org, assim como o patch-o-magic (dispon vel vel no mesmo site). Descompacte o iptables e o patch-o-magic. Execute o patch-o-magic e siga as instruoes. c
7 Implementaao c
45
No menu de congurao do kernel: ca - Selecione o modelo do processador. - Ajuste os drivers de rede e demais necessrios (na dvida, marque todos como MODULO) a u Desative Network Device Support -> PCMCIA (*) Desative ISDN (*) Desative File Systems - Reiserfs (*) (*) Se estes mdulos forem necessrios para seu equipamento, consulte as instrues dos o a co fabricantes para saber quais as ferramentas necessrias para compilar o kernel com estes a recursos.
/usr/src/linux# make dep /usr/src/linux# make clean /usr/src/linux# make bzImage /usr/src/linux# make modules /usr/src/linux# make modules_install /usr/src/linux# mkinitrd /boot/initrd-2.4.19.img 2.4.19 /usr/src/linux# cp -aRdiv arch/i386/boot/bzImage /boot/vmlinuz-2.4.19 /usr/src/linux# cp System.map /boot/System.map-2.4.19 /usr/src/linux# cp include/linux/kernel.h /boot/kernel.h-2.4.19 /usr/src/linux# cd /boot /boot# rm System.map /boot# rm kernel.h /boot# ln -s System.map-2.4.19 System.map /boot# ln -s kernel.h-2.4.19 kernel.h
7 Implementaao c
46
Acrescente uma entrada em /boot/grub/menu.lst para a nova imagem do kernel que foi gerada: title = Beowulf kernel = (hd1,1)/boot/vmlinuz-2.4.19 root=/dev/hdb2 3 initrd = (hd1,1)/boot/initrd-2.4.19.img
# make # make install # cp clients/libBProc.so.2 /usr/lib/. # cd/boot /boot# rm -f vmlinuz /boot# ln -s vmlinuz-2.4.19 vmlinuz
Neste ponto sua mquina est pronta para atuar em cluster beowulf. a a
# Interface de escuta do MESTRE interface lo 127.0.0.1 255.0.0.0 # Numero de nos nodes 9 # Faixa de IPs para os nos
7 Implementaao c iprange 1 127.0.0.1 127.0.0.8 # Bibliotecas que serao compartilhadas entre os nos libraries /lib/ld-* libraries /lib/libc-* libraries /lib/liBProc* libraries /lib/libtermcap* libraries /usr/lib/libBProc*
47
# modprobe BProc
No mestre, execute:
# bpmaster
# bpstat
e verique se todos os escravos esto listados como UP. a ### AUTOMATIZANDO A INICIALIZACAO ###
7 Implementaao c
48
# cd /etc/rcN.d/
Quando as mquinas forem reiniciadas, entraro automaticamente no cluster. Lembre-se a a apenas de iniciar o MESTRE antes dos ESCRAVOS.
### INSTALANDO O PVM ### Faa o download da verso 3.4.4, dispon em www.csm.ornl.gov/pvm e descompacte c a vel no diretrio /usr/share/pvm3 o
7 Implementaao c
49
Compile o PVM:
Acrescente os escravos:
pvm> add escravo1 pvm> add escravo2 pvm> add escravo3 pvm> add escravo4 pvm> add escravo5 pvm> add escravo6 pvm> add escravo7
pvm> conf
50
8.1
Demonstrao do BProc ca
Para demonstrar o funcionando da biblioteca BProc, utilizamos dois programas: Stress1 e Stress2. Ambos realizam um nmero arbitrrio de operaes de multiplicaao com u a co c nmeros em ponto utuante de 80 bits. As operaoes, no correlatas, foram divididas em u c a subprocessos tambm de forma arbitrria. Stress1 utiliza o mtodo fork() para criar os e a e subprocessos. Espervamos que o kernel com BProc fosse distribuir esses subprocessos no a cluster, mas isso no aconteceu. Todos os subprocessos foram executados na mquina que a a os invocou. No programa Stress2 substitu mos o mtodo fork() por bproc_rfork(), e e com isso os subprocessos foram distribu dos no cluster. Mas a distribuio no ocorreu de ca a forma automtica. Tivemos que utilizar outros mtodos do BProc para obter uma lista a e dos ns ativos, e a cada chamada de bproc_rfork() tivemos que especicar em qual n o o o subprocesso deveria ser executado. Como utilizamos duas mquinas com o mesmo poder de processamento, distribu a mos de forma uniforme os processos e obtivemos ganhos da ordem de 100%. Durante a execuao c do Stress2 distribu do, capturamos os processos em execuao em cada mquina, e pudec a mos ver a distribuiao. Para o teste executamos 250 milhes de operaes, divididas em c o co dez subprocessos de 25 milhes de operaes. O resultado da execuao o seguinte: o co c e
51
Inicio: Wed Jul 21 08:33:44 2004 Filho 1 -> pid 1162 -> no 0 Filho 2 -> pid 1164 -> no 1 Filho 3 -> pid 1165 -> no 0 Filho 4-> pid 1167 -> no 1 Filho 5 -> pid 1168 -> no 0 Filho 6 -> pid 1170 -> no 1 Filho 7 -> pid 1171 -> no 0 Filho 8 -> pid 1173 -> no 1 Filho 9 -> pid 1174 -> no 0 Filho 10 -> pid 1176 -> no 1 Fim do pid 1164 (status = 0) Fim do pid 1167 (status = 0) Fim do pid 1170 (status = 0) Fim do pid 1162 (status = 0) Fim do pid 1173 (status = 0) Fim do pid 1176 (status = 0) Fim do pid 1165 (status = 0) Fim do pid 1168 (status = 0) Fim do pid 1171 (status = 0) Fim do pid 1174 (status = 0) Fim: Wed Jul 21 08:35:19 2004 Tempo gasto (s): 95 Numero total de operaoes: 250000000 c~
895 899
0:00
?S 0:00 /usr/sbin/bpslave -s 192.168.200.1 mestre 2223 R R R R 0:05 0:04 0:04 0:04 ./stress2 5000 10 ./stress2 5000 10 ./stress2 5000 10 ./stress2 5000 10
52
908 914
? tty1
S S S RW RW RW RW RW RW RW RW RW RW
0:00 0:00 0:00 0:05 0:05 0:04 0:04 0:04 0:04 0:04 0:04 0:04 0:04
login -- root -bash ./stress2 5000 10 [stress2] [stress2] [stress2] [stress2] [stress2] [stress2] [stress2] [stress2] [stress2] [stress2]
1161 tty1 1162 tty1 1164 tty1 1165 tty1 1167 tty1 1168 tty1 1170 tty1 1171 tty1 1173 tty1 1174 tty1 1176 tty1
925 929
? ?
S S R R R R R
/usr/sbin/bpslave mestre 2223 /usr/sbin/bpslave mestre 2223 ./stress2 5000 10 ./stress2 5000 10 ./stress2 5000 10 ./stress2 5000 10 ./stress2 5000 10
Podemos ver que para cada instncia do daemon escravo (bpslave) tivemos cinco suba processos em execuao. Observe que a mquina mestre tambm executou o daemon c a e bpslave para que zesse parte da distribuio de tarefas. ca
Tambm podemos ver nesse exemplo o conceito de mascaramento de PID. Obe serve que cada processo lho obteve um nmero PID que o identica na mquina mestre. u a Cada um desses PIDs est representado de uma forma especial pelo sistema operacional, a
53
Tabela 8.1: Stress2 por se tratar de processos fantasmas. Os processos fantasmas no so executados, eles a a servem para transmitir sinais entre processos de forma transparente, pois no necessrio a e a saber em qual n um processo est realmente em execuo para que se possa enviar um o a ca sinal ao mesmo. A desvantagem da utilizao da biblioteca BProc que sua utilizao implica no desenca e ca volvimento de mtodos de controle da distribuio de tarefas, assim como para troca de e ca mensagens, pois essas tarefas no fazem parte do BProc. a
8.2
8.2.1
Aplicaes co
PovRay
O PovRay uma ferramenta de alta qualidade, totalmente livre para criar grcos tridie a mensionais. Est dispon em verses ociais para OS X e Windows, do mac OS/Mac e a vel o i86 Linux. O Persistence of Ray-Tracer da viso cria imagens 3D, foto-real a sticas usando uma tcnica de renderizao chamada ray-tracing. L uma informao dentro do arquivo e ca e ca fonte que descreve os objetos, ilumina uma cena e gera uma imagem dessa cena do ponto da vista de uma cmera descrita tambm no cdigo. O Ray-Tracer no um processo a e o a e rpido, mas produz imagens da qualidade muito elevada com reexes real a o sticas [24]. Para instalar o POVRay, foram executados os seguintes passos: # cd /usr/local # mkdir povray31 # cd povray31 # cp /lugar/pacotes/de/instala~o/povuni* . ca Depois foram aplicados patches ao programa para rodarem sobre PVM e MPI. Foram copiados todos os patches para o diretrio /usr/local/povray31 . o Como so dois patches espec a cos, foram criados dois diretrios dentro de /usr/local/povray31 o e copiados todos os dados descompactados. Para o patch do MPI foram feitos os seguintes passos: Dentro do /usr/local/povray31:
8.2 Aplicaoes c # mkdir mpipov # cd mpipov # tar zfvx ../povuni_s.tgz # tar zfvx ../povuni_d.tgz # cp /lugar/de/origem/do/patch/mpi-povray-1.0.patch.gz . # gunzip mpi-povray-1.0.patch | patch -p1 # cd source/mpi-unix # make newxwin Para o patch do PVM foram feitos os seguintes passos: $ cd /usr/local/povray31 $ cp /lugar/de/origem/do/patch/pvmpov-3.1g2.tgz . $ tar zfvx pvmpov-3.1g2.tgz Ser criado o diretrio pvmpov3 1g 2 a o $ cd pvmpov3_1g_2 $ tar zfvx ../povuni_s.tgz $ tar zfvx ../povuni_d.tgz $ ./inst-pvm $ cd povray31/source/pvm $ aimk newunix $ aimk newsvga $ aimk newxwin $ make install
54
8.2.2
PVMmake um compilador que usa a biblioteca de passagem PVM para executar duas e operaes bsicas: co a T ransf erncia de Arquivo - O PVMmake envia dados de texto (formato ASCII), e possibilitando a comunicaao entre dois hosts; c Execucao de Comando - PVMmake pode emitir um comando arbitrrio para um a host arbitrrio. Assim, o PVMmake pode executar comandos do UNIX e shell scripts a
8.3 PVM
55
bem como programas compilados. Ademais, o output destes comandos, scripts ou programas podem ser vistos nos Ns onde o PVMmake foi lanado ou iniciado. o c Essas duas operaes bsicas fazem com que o PVMmake se torne bastante ex co a vel, poderoso, e de fcil uso. a
8.3
PVM
Para demonstrar o funcionando da biblioteca PVM, utilizamos o pvmmake para realizarmos a compilaao do kernel do linux. Processos na mquina mestre durante a c a execuo: ca
9013 tty5 14279 tty5 14280 tty5 14281 tty5 14282 tty5 14286 tty5 14287 tty5 14354 tty5 14355 tty5 14356 tty5
S S S S S S S S S R
0:03 /usr/share/pvm3/lib/LINUX/pvmd3 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 /usr/share/pvm3/bin/LINUX/make_pvm 525749 make -C drivers fastdep /usr/share/pvm3/bin/LINUX/make_pvm 263622 make _sfdep_acpi _sfdep_atm _sfdep_block _sfdep /usr/share/pvm3/bin/LINUX/make_pvm 525753 make _sfdep_dispatcher _sfdep_events _sfdep_exe /usr/share/pvm3/bin/LINUX/make_pvm 525789 /bin/sh -c /usr/src/linux-teste/scripts/mkdep /usr/src/linux-teste/scripts/mkdep -D__KERNEL
S S S S S S S S
/usr/share/pvm3/lib/LINUX/pvmd3 -s -d0x0 -nescravo1 /usr/share/pvm3/bin/LINUX/make_pvm 0 /root/mestre/linux-2.4.19/../pvmgmake/make _sfd /usr/share/pvm3/bin/LINUX/make_pvm 524324 /root/mestre/linux-2.4.19/../pvmgmake/make -C d /usr/share/pvm3/bin/LINUX/make_pvm 262248 /root/mestre/linux-2.4.19/../pvmgmake/make _sfd /usr/share/pvm3/bin/LINUX/make_pvm 262199
Podemos observar um funcionamento anlogo ao funcionamento do BProc: cada n a o executa um daemon que recebe as tarefas, sem a utilizaao de remote shell. c O grande diferencial da biblioteca PVM que a distribuiao de tarefas ca a cargo do e c daemon do n mestre, e no do programa em execuo. Isso permite ao programador o a ca uma abstraao da arquitetura do cluster, o que torna esse sistema bastante ex c vel. Na gura adiante podemos ver a representao da distribuiao de tarefas dessa comca c pilao, obtida atravs da ferramenta XPVM. ca e
Figura 8.1: XPVM - Ns do Cluster o Na tabela seguinte temos os tempos totais de execuao dessa compilao. Obc ca serve que o ganho foi de apenas 28,67%. O ganho no foi maior porque a compilaao do a c kernel no foi adequada ao processamento paralelo. Isso signica que em muitas vezes o a processo em um dos ns era paralisado at que o outro n terminasse parte da compilaao. o e o c
8.3 PVM
57
8.3 PVM
58
8.4 MPI
uma adaptaao do PovRay. O PovRay precisou ser adaptado para fazer uso dos rec cursos do PVM de processamento paralelo. A imagem a ser renderizada foi dividida em pequenos blocos, e cada bloco renderizado por um subprocesso. Os subprocessos do PovRay foram distribu dos entre os ns do cluster. Os tempos gastos o na execuao esto na Tabela IV.2. Podemos observar que o ganho do processamento no c a cluster foi de 72,22% em relao ao processamento em apenas um n. ca o
Resultados mestre [tempo (s)] MPI PVM 187 31 mestre+escravo [tempo (s)] 94 18
Tabela 8.3: Renderizaao POVRay c As condies da rede eram as mesmas do momento em que zemos a execuao co c do Stress2 e obtivemos ganhos de 100,00%. O ganho com o PVM no to grande porque a e a o prprio PVM consome recursos do cluster para realizar o gerenciamento das tarefas e o de trocas de mensagens. Essa a desvantagem em se utilizar o PVM, se comparado ao e BProc. A Figura seguinte foi capturada durante a renderizao da imagem no cluster. ca prximas duas guras mostram a imagem renderizada. o As
8.4
MPI
Realizamos uma renderizao de imagem para demonstrar o funcionamento da biblioteca ca MPI, usando uma adaptao do PovRay: o mpipov. ca O princ o mesmo usado na renderizaao com o PVM: a gura dividida em blocos, pio e c e e os blocos so distribu a dos entre os ns do cluster. o O MPI no utiliza daemons para distribuiao de tarefas, mas sim o remote shell. E isso a c mostrou-se uma desvantagem, devido ` necessidade de execuao de tarefas de login cada a c vez que um processo enviado a um n escravo. Entretanto, esse mtodo pode ser mais e o e seguro que o uso de daemons, pois pode-se efetuar o login remoto usando o ssh (security
8.4 MPI
60
8.4 MPI
61
Figura 8.7: Renderizaao completa do POVRAY c shell) com sistemas de chaves assimtricas para autenticaao. e c Processos na mquina mestre durante a execuao: a c
19175 tty1 19176 tty1 19304 tty1 19305 tty1 19306 tty1 19307 tty1 19311 tty1
S S S S S S S
/bin/sh ./mpipov skyvase.pov 4 /bin/sh /usr/local/mpich-BProc/bin/mpirun -np /root/mestre/povray31/source/mpi-unix/mpi-x /root/mestre/povray31/source/mpi-unix/mpi /usr/bin/rsh escravo1 -l root -n /root/me /usr/bin/rsh mestre.localdomain -l root /usr/bin/rsh escravo1 -l root -n /root/me
S S R S
8.4 MPI 767 ? 4460 ? 4461 ? 4462 ? 4463 ? 4464 ? 4465 ? S S R S S R S 0:00 0:00 0:14 0:00 0:00 0:14 0:00 xinetd -reuse in.rshd
62
Ao executarmos o mpipov, a biblioteca MPI se encarregou de distribuir os subprocessos entre os ns utilizando o rsh (remote shell). Observe a existncia de um processo o e no mestre disparado pelo remote shell atravs do servio xinetd. No escravo1 podee c mos observar dois processos disparados pelo xinetd. A biblioteca MPI tem a mesma abstrao da biblioteca PVM, ou seja, cria a imagem de uma mquina virtual para o ca a programador, e a prpria biblioteca se encarrega de distribuir as tarefas. Na Tabela IV.2 o temos os tempos gastos para a renderizao em uma mquina apenas, e no cluster: ganho ca a de 98,94%. Esse ganho um excelente resultado, se analisado de forma isolada. Vamos e comparar agora a renderizaao utilizando o PVM e utilizando o MPI. A renderizao, c ca utilizando apenas uma mquina, com PVM obteve um ganho de 503,23% em relao a ca a renderizaao com MPI. Utilizando duas mquinas, o ganho do PVM em relao ao c a ca MPI foi de 422,22%. Esses resultados reforam a teoria de que a utilizaao de daemons c c para distribuio de processos, como ocorro com o BProc e o PVM, mais gil do que ca e a a utilizao de remote shell, como no MPI. Quando se utiliza daemons, cada tarefa ca e executada por um subprocesso desse daemon. Ao usar remote shell, um novo processo shell iniciado para cada tarefa, e isso requer a execuao de uma srie de tarefas de login, e c e tais como vericao de cotas, conguraao de variveis de ambiente, registros nos logs de ca c a acesso ao sistema, dentre vrias executadas pelo sistema operacional. A execuao dessas a c tarefas de login prejudicam o desempenho do cluster. No caso do mpipov, o prprio deo senvolvedor recomenda a utilizao do pvmpov[25][26]. A biblioteca MPI oferece mais ca recursos ao programador do que a biblioteca PVM. Mas, devido ao problema descrito, o PVM a melhor opao. Est em fase de implementao um biblioteca PVM que ine c a ca corpore todos os recursos oferecidos pelo MPI, numa tentativa de unicar as bibliotecas utilizando o conceito do PVM de daemons para distribuiao de tarefas [27]. c
63
9 Tuning
9.1 O que e
Uma traduo para tunning seria anaao. T unning so os ajustes necessrios para a ca c a a obteno do mximo desempenho poss ca a vel. Esse conceito no se aplica apenas em clusa ters, mas em diversas reas. a Inmeros so os fatores que inuenciam a performance do cluster. O poder de processau a mento dos ns o fator mais importante e notrio. A princ o e o pio, imagina-se que o poder de processamento de um cluster a soma das capacidades de cada n. Isso seria o ideal, mas e o no acontece na prtica, pois a administrao do cluster e das tarefas consome recursos a a ca das mquinas. a O desempenho da rede tambm de suma importncia, pois depende dela a distribuiao e e a c de tarefas e a coleta de resultados. Esses dois fatores so controlados pelo administrador do cluster e dependem diretamente a da quantidade de recursos nanceiros dispon veis para a montagem do cluster.Outro fator importante, mas que no est sob controle do administrador, a granulaao das tarefas. a a e c Para que uma tarefa possa ser executada em um cluster, ela precisa ser dividida em subprocessos que possam ser distribu das. A tarefa precisa estar adaptada para sofrer essa fragmentaao. c O tamanho de cada subprocesso que determina a granulaao. Entenda-se tamanho e c como nmero de instruoes necessrias para executar o subprocesso. Uma tarefa com alta u c a taxa de granulaao (grande quantidade de gros, ou fragmentos) ter uma grande quanc a a tidade de subprocessos de pequenos tamanhos (ou pequenas quantidades de instruoes). c O fator granulaao controlado pelo programador, pois s ele pode denir os pontos de c e o diviso de cada tarefa. a
64
9.2
Como fazer
Como o fator granulao no depende de recursos nanceiros, ele o fator que deve ser ca a e ajustado no processo de tunning para se obter o melhor desempenho. Vamos ilustrar uma situaao para abordar esse tema: c Um cluster com dois ns. O n A tem poder de processamento de um milho (1M) de o o a instrues por segundo. O n B pode processar dois milhes (2M) de instrues por co o o co segundo. Existe ainda o n mestre, que apenas coordena a distribuio e execuao de o ca c tarefas. Os ns esto interligados por uma rede, com capacidade de transmisso de 10 o a a mensagens por segundo. A tarefa a ser executada tem 100 milhes (100M) de instruoes. o c Na primeira situao, vamos dividir a tarefa em 4 subprocessos independentes (que no ca a dependem do trmino de outro subprocesso para serem processados), de 25M instruoes e c cada. Vejamos as etapas do processo:
Resultados Relgio o 0,0s 0,1s 0,1s 0,2s 12,7s 12,8s 12,9s 25,1s 25,2s 25,3s 25,4s 50,3s 50,4s Etapa SuBProcesso enviado para n A o N A inicia o subprocessamento (subprocesso 1) o SuBProcesso 2 enviado para n B o N B inicia processamento (subprocesso 2) o N B envia resultado (subprocesso 2) o SuBProcesso 3 enviado para n B o N B inicia processamento (subprocesso 3) o N A envia resultado (subprocesso 1) o SuBProcesso 4 enviado para n A o N A inicia processamento (subprocesso 4) o N B envia resultado (subprocesso 3) o N A envia resultado (subprocesso 4) o Fim do processamento Tempo Gasto 0,1s 25,0s 0,1s 12,5s 0,1s 0,1s 12,5s 0,1s 0,1s 25,0s 0,1s 0,1s
Se a tarefa estivesse sendo executada toda em A, o tempo gasto seria de 100 segundos. Se fosse executada em B, o tempo necessrio seria de 50 segundos. Observe que o a
65
tempo necessrio para a execuo na situaao ilustrada foi maior do que o necessrio para a ca c a a execuao no n mais rpido do cluster. Houve uma perda de 0,8%. Isso ocorreu porque c o a o n B cou ocioso a partir do tempo 25,4s, totalizando 25,0s de ociosidade. o Vamos repetir essa simulao, mas agora dividindo a tarefa em 10 subprocessos de 10M. ca Vejamos as etapas do processo:
9.2 Como fazer Resultados Relgio o 0,0s 0,1s 0,1s 0,2s 5,2s 5,3s 5,4s 10,1s 10,2s 10,3s 10,4s 10,5s 10,6s 15,6s 15,7s 15,8s 20,3s 20,4s 20,5s 20,8s 20,9s 21,0s 26,0s 26,1s 26,2s 30,5s 30,6s 30,7s 31,2s 40,7s 40,8s Etapa Subprocesso 1 enviado para n A o Subprocesso 2 enviado para n B o N A inicia processamento (subprocesso 1) o N B inicia processamento (subprocesso 2) o N B envia resultado (subprocesso 2) o Subprocesso 3 enviado para n B o N B inicia processamento (subprocesso 3) o N A envia resultado (subprocesso 1) o Subprocesso 4 enviado para n A o N A inicia processamento (subprocesso 4) o N B envia resultado (subprocesso 3) o Subprocesso 5 enviado para n B o N B inicia processamento (subprocesso 5) o N B envia resultado (subprocesso 5) o Subprocesso 6 enviado para n B o N B inicia processamento (subprocesso 6) o N A envia resultado (subprocesso 4) o Subprocesso 7 enviado para n A o N A inicia processamento (subprocesso 7) o N B envia resultado (subprocesso 6) o Subprocesso 8 enviado para n B o N B inicia processamento (subprocesso 8) o N B envia resultado (subprocesso 8) o Subprocesso 9 enviado para n B o N B inicia processamento (subprocesso 6) o N A envia resultado (subprocesso 7) o Subprocesso 10 enviado para n A o N A inicia processamento (subprocesso 1) o N B envia resultado (subprocesso 6) o N A envia resultado (subprocesso 1) o Fim do processamento Tempo Gasto 0,1s 0,1s 10,0s 5,0s 0,1s 0,1s 5,0s 0,1s 0,1s 10,0s 0,1s 0,1s 5,0s 0,1s 0,1s 5,0s 0,1s 0,1s 10,0s 0,1s 0,1s 5,0s 0,1s 0,1s 5,0s 0,1s 0,1s 10,0s 0,1s 0,1s
66
67
Veja que agora houve um ganho de 22,5%, e que o tempo de ociosidade do n B foi de o apenas 9,6 segundos. O tempo mximo de ociosidade de um n o tempo necessrio para processar o maior a oe a subprocesso no n com menor poder de processamento. Na primeira simulao esse tempo o ca mximo era de 25 segundos. J na segunda esse tempo diminuiu para 10 segundos. a a Se desconsiderarmos o tempo gasto com a troca de mensagens, quanto maior a taxa de granulaao (ou nmero de subprocessos), menor ser o tempo mximo de ociosidade de c u a a um n, e melhor ser o desempenho do cluster. o a Entretanto, aumentar a granulao implica em um nmero maior de troca de mensagens. ca u Se a rede car congestionada, os ns podem car ociosos aguardando a chegada de meno sagens, e ociosidade signica menor desempenho. Outro fator importante o tempo necessrio para administrar cada subprocesso. Em e a tarefas pequenas esse tempo desprez e vel, mas em grandes tarefas deve ser considerado se no existir um n dedicado a essa funo. a o ca Portanto, o objetivo do tunning aumentar a granulao da tarefa at atingir o limite da e ca e capacidade de transmisso da rede que interliga os ns do cluster. Quando essa situao a o ca for atingida, o cluster estar operando com desempenho total. a
9.3
Outras Consideraes co
O ajuste da granulaao tambm pode levar ` concluso de que a rede que interliga os ns c e a a o est impondo um tempo mximo de ociosidade elevado demais, e que precisa ser melhoa a rada. Tambm pode levar ` concluso de que o n com menor poder de processamento e a a o precisa ser retirado para diminuir o tempo mximo de ociosidade. a Outro fato importante ocorre em clusters que executam vrias tarefas simultaneamente. a Mesmo que as tarefas no tenham a granulaao ideal, o cluster pode operar com dea c sempenho mximo. As tarefas no sero executadas no menor tempo poss a a a vel, mas os diferentes tamanhos de subprocessos podem levar a uma condiao de baixa ociosidade c do cluster no geral. E por esse motivo que clusters multi-tarefas de propsito geral no o a se preocupam em determinar a granulao com preciso. ca a
68
10.1
Assim como a OpenMosix, a idia bsica construir uma distribuiao bootvel atravs e a e c a e de um CD baseada em Beowulf. A intenao principal que o mestre que com o c e
CD bootvel, e que essa distribuiao possua scripts que ativem os servidores e autoa c congurem os arquivos das aplicaes.Os compiladores dessa distribuio so todos disco ca a tribu dos e prprio para cada biblioteca de programaao paralela (MPI, PVM, BProc e o c etc.) Nessa distribuio deve ter aplicaoes ou scripts que crie disquetes para boot remoto dos ca c escravos, utilizando apenas o oppy, poupando assim o uso do HD e drive de CD dessas estaes. co O mestre deve ter a capacidade de auto-detectar a inicializaao dos escravos. c
10.2
Boot Remoto
A idia principal desenvolver maneiras que facilitem o boot dos escravos para o cluster e e usando tcnicas de boot BOOTP/DHCP, TFTP e pela EPROM da placa de rede. e
69
10.3
Distribuio em Floppy ca
Assim como o OpenMosixLOAF, existe a possibilidade de criar uma distribuiao que caiba c em um disquete, e que torne mais prtico a congurao das estaes. a ca co
10.4
LinuxBios
LinuxBIOS um projeto aberto que visa criar um sistema de boot simples e rpido. O e a projeto foi iniciado como parte do trabalho de pesquisa no Laboratrio Nacional de Los o Alamos. A idia ganhar o controle dos ns( estaoes ) atravs de uma imagem do sise e o c e tema operacional ( kernel-Linux ) gravada na BIOS ( reprogramaao ). Isto permite uma c maior rapidez para carregar o sistema operacional, o que denominado carregar a frio.O e tempo mais rpido de um boot j registrado de 3 segundos. Outra vantagem de usar a a e LinuxBIOS a economia de energia, pois apenas dois motores trabalham na mquina: O e a ventilador do processador central e da fonte de alimentaao. c LinuxBIOS um Linux bem simples: e
Possui 10 patches inclusos no kernel. Possui 500 linhas em Assembler e 5000 linhas em C - para inicializao do kernel. ca Executa 16 instrues para entrar no modo 32-bit, acessar a memria e inicializar co o outros hardwares que sero necessrios aps o Linux iniciar. a a o
10.5
Existe um projeto chamado V9FS cujo o objetivo criar uma viso unica de disco. O sise a tema funciona como o NFS, porm, fazendo com que vrios discos se unam virtualmente, e a criando uma imagem unica de disco.
70
11 Concluso a
Este trabalho fornece algumas soluoes para a construao de supercomputadores, utic c lizando sof twares livres, reaproveitando mquinas antigas, possibilitando a construao a c de supermquinas caseiras. Essas soluoes podem suprir as necessidades de grandes Unia c versidades e empresas de mdio porte. e Todas essas solues apresentadas possuem uma total viabilidade, algumas chegaram a co 100% de ganho, porm, existe a diculdade para encontrar aplicaoes para esta plataforma. e c Nos nossos testes o BPROC obteve um grande desempenho, por ser leve e trabalhar diretamente no kernel do sistema operacional. O n escravo chegou a processar em 100%, o aproveitando todos os recursos dele. Outra vantagem foi o no congestionamento da rede. a O MPI no alcanou as expectativas deste trabalho, deixando a desejar na renderizaao de a c c imagens. Isto acontece devido a grande troca de mensagens o que gera um alto overhead. Alm de ser prtico o PVM agradou em desempenho chegando a render 200%, diminuindo e a o tempo de processamento pela metade. Dentre essas trs implementaoes, o BPROC e o PVM atingiram as nossas expectativas. e c Um grande problema encontrado encontrado nessas trs implementaoes, a grande come c e plexidade de programar para ambientes paralelos. Para empresas e universidades uma porta aberta para investimentos em tecnologia, e principalmente as que requerem recursos computacionais. Pode-se abrir vrias reas de a a estudo em relaao a essas solues como : programao para sistemas distribu c co ca dos, programao paralela, escalonamento de processos, processamento de imagens distribu ca das, sistemas de arquivos, arquiteturas de redes, gerncia de rede, criaao de protocolos mais e c ecientes.
71
I Programas Utilizados
I.1 Stress1
/***************************************************************** CEFET-GO Redes de Computadores Trabalho de Conclus~o de Curso a Esli P. Jnior u Reinaldo B. Freitas M. Sc. Cloves F. J. (orientador) ****************************************************************** stress1.cpp
Realiza multiplicaoes com nmeros em ponto flutuante c~ u do tipo long double (80 bits para i586), divididas em subprocessos.
Forma de uso:
<processos> Indica o nmero de subprocessos que ser~o u a criados para realizar os clculos a
I.1 Stress1
72
O processo pai indicar a hora do incio do processamento a e do fim, assim como o tempo gasto (em segundos). */
#include <stdio.h> #include <wait.h> #include <signal.h> #include <string.h> #include <stdlib.h> #include <unistd.h> #include <time.h>
0 1
OPER PROC
50000 50
I.1 Stress1 int temp = 0, i = 0, j = 0, k = 0; int filhos = 0; // time t ini, fim; // Uso geral
73
// Vericando parmetros a if( argc != 3 ) { printf( "Forma de uso: %s <num operera> <num procs>\n", argv[0] ); exit( } operacoes = atoi( argv[1] ); if( operacoes <= 0 || operacoes > MAX OPER ) operacoes = MAX OPER; processos = atoi( argv[2] ); if( processos <= 0 || processos > MAX PROC ) processos = MAX PROC; ERRO );
// Marcando hora inicial ini = time( &ini ); printf( "Inicio: %s\n", ctime(&ini) );
// Criando subprocessos for( i = 0; i < processos; i++ ) { // Utilizada a funao fork() padro para criar subprocessos c a temp = fork();
I.1 Stress1 if( temp < 0 ) { perror( "Erro ao criar subprocesso\n"); exit( ERRO ); } // Processo lho: temp == 0 if( temp == 0 ) { for( j = 0; j < operacoes; j++ ) { for( k = 0; k < operacoes; k++ ) { // Clculo propriamente dito a acumulado *= acumulado; } } exit( OK ); } // Processo pai filhos++; // Fim do processo lho
74
printf( "Filho %d -> pid %d\n", filhos, temp ); } // Aguardando o m de todos os processos lhos
while( filhos > 0 ) { i = wait( &temp ); if( i > 0 ) { printf( "Fim do pid %d (status = %d)\n", i, temp ); filhos--; } }
I.2 Stress2
75
printf( "Tempo gasto (s): %d\n", fim - ini ); printf( "Numero total de operacoes: %d\n", operacoes * operacoes * processos); }
I.2
Stress2
/***************************************************************** CEFET-GO Redes de Computadores Trabalho de Concluso de Curso a Esli P. Jnior u Reinaldo B. Freitas M. Sc. Cloves F. J. (orientador) ****************************************************************** stress2.cpp
I.2 Stress2 Realiza multiplicaoes com nmeros em ponto utuante c u do tipo long double (80 bits para i586), divididas em subprocessos.
76
PS: esse programa utiliza a biblioteca BPROC, e precisa ser linkado com essa biblioteca:
Forma de uso:
<processos> Indica o nmero de subprocessos que sero u a criados para realizar os clculos a
O processo pai indicar a hora do in a cio do processamento e do m, assim como o tempo gasto (em segundos). */ #include <stdio.h> #include <wait.h> #include <signal.h> #include <string.h>
I.2 Stress2 #include <stdlib.h> #include <unistd.h> #include <time.h> #include <sys/BProc.h>
77
0 1
50000 50
long double fator, acumulado; unsigned int operacoes, processos; int temp = 0, i = 0, j = 0, k = 0; int filhos = 0; time t ini, fim;
struct BProc node info t *hosts; // Matriz com as informaoes dos ns c o int nhosts; int no = 0; // Nmero de ns do cluster u o
// Consultando cluster nhosts = BProc nodelist( &hosts ); if( nhosts <= 0 ) { perror( "Erro ao consultar cluster.\n"
78
// Vericando parmetros a if( argc != 3 ) { printf( "Forma de uso: %s <num operera> <num procs>\n", argv[0] ); exit( ERRO ); } operacoes = atoi( argv[1] ); if( operacoes <= 0 || operacoes > MAX OPER ) operacoes = MAX OPER; processos = atoi( argv[2] ); if( processos <= 0 || processos > MAX PROC ) processos = MAX PROC;
// Marcando hora inicial ini = time( &ini ); printf( "Inicio: %s\n", ctime(&ini) );
// Criando subprocessos for( i = 0; i < processos; i++ ) { // Procurando um n ativo no cluster para executar o o // prximo subprocesso o
79
if( no >= nhosts ) no = 0; // Voltando ao in cio da la } // Criando subprocesso com a funo do BPROC ca // O n de destino ja est indicado por hosts[no].node o a temp = BProc rfork( hosts[no].node ); if( temp < 0 ) { printf( "Erro ao criar subprocesso (nhosts=%d) (no=%d)\n", nhosts, no ); exit( ERRO ); } // Processo lho: temp == 0 if( temp == 0 ) { for( j = 0; j < operacoes; j++ ) { for( k = 0; k < operacoes; k++ ) { // Clculo propriamente dito a acumulado *= acumulado; } } exit( OK ); // Fim do processo lho } // Processo pai filhos++; printf( "Filho %d -> pid %d -> no %d\n", filhos, temp, hosts[no].node ); // Avanando na la c no++;
I.2 Stress2 if( no >= nhosts ) no = 0; // Voltando ao in cio da la } // Aguardando o m de todos os processos lhos while( filhos > 0 ) { i = wait( &temp ); if( i > 0 ) {
80
// Marcando hora nal e apresentando resultados fim = time( &fim ); printf( "Fim: %s\n", ctime(&fim) );
printf( "Tempo gasto (s): %d\n", fim - ini ); printf("Numero total de operacoes:%d\n", operacoes * operacoes * processos); }
81
II Arquivos de Congurao ca
II.1 machines.LINUX
#Change this file to contain the machines that you want to use #to run MPI jobs on. #hostname #or #hostname:n #where n is the number of processors in an SMP. The hostname should # be the same as the result from the command hostname mestre.localdomain escravo1 The format is one host name per line, with either
II.2
.rhosts
II.3
mestre
.xpvm hosts
escravo1 lo=beowulf
II.4 bashrc
82
II.4
bashrc
/etc/bashrc
System-wide functions and aliases Environment conguration on/etc/prole PS1=[\u@\h \W]$ alias which=type -path alias l=ls -laF color=auto alias ls=ls color=auto alias m=minicom -s -con -L alias minicom=minicom -s -con -L alias tm=tail -f /var/log/messages alias tmm=tail -f /var/log/maillog alias tms=tail -f /var/log/secure alias cds=cd /etc/rc.d/init.d ls alias fd=mount /dev/fd0 /mnt/oppy; cd /mnt/oppy ls alias ufd=cd /mnt umount oppy ls alias ldir=mount /mnt/oppy l /mnt/oppy umount /mnt/oppy
export PVM ROOT=/usr/share/pvm3 export PVM ARCH=BEOLIN #export PVM TMP=/tmp/pvm #export PVM TMP=/root/escravo1/pvmtmp export PVM TMP=/tmps
export PATH=$PATH:$PVM ROOT/lib:$PVM ROOT/lib/$PVM ARCH:$PVM ROOT/bin/$PVM export PVM DPATH=$PVM ROOT/lib/pvmd export PROC LIST=mestre:escravo1 lo=beowulf
export XPVM ROOT=/usr/local/xpvm export TCL LIBRARY=/usr/lib/tcl export TK LIBRARY=/usr/lib/tk export PATH=$PATH:/usr/local/mpich-1.2.4/bin export MPIR HOME=/usr/local/mpich-1.2.4
II.5 mpipov
83
II.5
mpipov
#!/bin/sh /usr/local/mpich-BProc/bin/mpirun -np \$2/root/mestre/povray31-mpi/source/mpiunix/mpi-x-povray $3 -I $1 +v1 +ft -x +mb25 +a.0.300 +j1.000 +r3 -q9 -w640 -H480 -S1 E480 -k0.000 -mv2.0 +b1000 +L/root/mestre/povray31-mpi/include/ +NH128 +NW128 $4 $5 $6 $7 $8
II.6
#
Makele.aimk
# \$Id: Makefile.aimk,v 1.40 2001/05/11 18:58:10 pvmsrc Exp \$ # # Generic Makefile body to be concatenated to config header. # # Imports: # # # # # # # # # Compatibility defines (usually in conf/*.def): # # # # # # # FDSETPATCH USESTRERROR HASERRORVARS HASSTDLIB NEEDENDIAN NEEDMENDIAN NOGETDTBLSIZ if system includes dont have fd_set stuff if sys_errlist, sys_nerr not public, use strerror() if errno, sys_nerr, sys_errlist already declared if system has stdlib.h to include <endian.h> to include <machine/endian.h> if system doesnt have getdtablesize() PVM_ARCH = the official pvm-name of your processor
ARCHCFLAGS = special cc flags ARCHDLIB ARCHDOBJ HASRANLIB AMEM PLOCKFILE = special libs needed for daemon = special objects needed for daemon = t or f = Memory page locks from Convex = Page Lock in line code from SUN
II.6 Makele.aimk # # # # # # # # # # # # # # # # # # # # # # # # Options defines: # # # # # # # # # CLUMP_ALLOC MCHECKSUM RSHNPLL= RSHTIMEOUT= STATISTICS TIMESTAMPLOG USE_PVM_ALLOC USE_GNU_REGEX allocates several data structures in big chunks to enable crc checksums on messages for number of parallel rsh startups (default is 5) for rsh timeout other than default (60 sec) to enable collection of statistics in pvmd to enable timestamps in pvmd log file to enable instrumented malloc functs (for pvm debug) to enable use of GNU Regex for Mbox Lookup -> requires installation of GNU regex, as well as FDSETNOTSTRUCT CTIMEISTIMET SYSERRISCONST SHAREDTMP SOCKADHASLEN SYSVBFUNC SYSVSIGNAL SYSVSTR UDPMAXLEN= NEEDSSELECTH SOCKLENISUINT NOREXEC NOSOCKOPT NOSTRCASE NOTMPNAM NOUNIXDOM NOWAIT3 NOWAITPID RSHCOMMAND= if system doesnt have rexec()
84
if system doesnt have setsockopt() / it doesnt work if system doesnt have strcasecmp, strncasecmp if system doesnt have tmpnam() or its hosed to disable use of Unix domain sockets if system doesnt have wait3() if system doesnt have waitpid() either for rsh command other than /usr/ucb/rsh (can override using PVM_RSH environment variable) if /tmp is shared between machines (yecch) if struct sockaddr has an sa_len field if system uses memcpy() instead of bcopy(), etc. if system has sysV signal handling if system uses strchr() instead of index() for alternate max udp packet size if you need to include select.h to get fd_set (IBMs) if socket parameter is unsigned int (or size_t), generally -> recvfrom() accept() getsockname()
remove flag for AIX 4.1 compiler complaints... if fd_set var declarations do not require struct if ctime() takes an arg of type timet if char *sys_errlist[] defined as const
II.6 Makele.aimk # # # modifying the following defines (see below): REGEXCONF, REGEXCONFOS2, REGEXOBJS
85
SHELL PVMDIR SDIR LIBDIR CFLOPTS #CFLOPTS #OPTIONS #OPTIONS #OPTIONS OPTIONS
= = = = = = = = = =
/bin/sh ../.. \$(PVMDIR)/src \$(PVMDIR)/lib/\$(PVM_ARCH) -O -g -DCLUMP_ALLOC -DSTATISTICS -p -DCLUMP_ALLOC -DSTATISTICS \ -DTIMESTAMPLOG -DSANITY
CFLAGS
LIBPREFIX LIBPVM
= =
lib \$(LIBPREFIX)pvm3
REGEXCONF #REGEXCONF
= = regexconfig
REGEXCONFOS2 #REGEXCONFOS2
= = regexconfig-os2
REGEXOBJS
86
DOBJ
= \ ddpro.o \ host.o \ hoster.o \ imalloc.o \ msgbox.o \ pkt.o \ pmsg.o \ pvmalloc.o \ pvmcruft.o \ pvmd.o \ pvmdpack.o \ pvmdtev.o \ pvmerr.o \ pvmfrag.o \ pvmlog.o \ sdpro.o \ task.o \ tdpro.o \ waitc.o \ global.o \ \$(REGEXOBJS)
SOCKDOBJ
= \
pvmdabuf.o \ pvmdunix.o
87
MPPDOBJ
= \
BEODOBJ
= \
pvmdmimd.o
OS2DOBJ
= \
LOBJ
88
LPVMSOCK
lpvm.o
SOCKLOBJ
= \
pvmdabuf.o
LPVMSHMEM
lpvmshmem.o
SHMEMLOBJ
= \
\$(AMEMOBJ) \ pvmshmem.o
LPVMMIMD
lpvmmimd.o
MPPLOBJ
= \
OS2LOBJ
stdlog.o
REGEXSRC
= \
89
REGEXDIR
./regex
REGEXCP
= \
REGEXOPTS
SHMEMTARGETS
MPPTARGETS
BEOTARGETS
$(LIBDIR)/pvmd3-beo $(LIBDIR)/$(LIBPVM).a
OS2TARGETS
$(LIBDIR)/pvmd3-os2 $(LIBDIR)/lib-os2
all:
pvmd3$(EXESFX) $(LIBPVM).a
all-shm:
all-mpp:
90
all-os2:
pvmd3-os2 lib-os2
install:
install-shm:
$(LIBDIR) $(SHMEMTARGETS)
install-mpp:
$(LIBDIR) $(MPPTARGETS)
install-beo:
$(LIBDIR) $(BEOTARGETS)
install-os2:
$(LIBDIR) $(OS2TARGETS)
$(LIBDIR)/pvmd3$(EXESFX):
pvmd3$(EXESFX)
cp pvmd3$(EXESFX) $(LIBDIR)
$(LIBDIR)/$(LIBPVM).a:
$(LIBPVM).a
cp $(LIBPVM).a $(LIBDIR)
$(LIBDIR)/pvmd3-shm:
pvmd3-shm
$(LIBDIR)/lib-shm:
lib-shm
cp $(LIBPVM).a $(LIBDIR)
91
$(LIBDIR)/$(LIBPVM)s.a:
$(LIBPVM)s.a
cp $(LIBPVM)s.a $(LIBDIR)/$(LIBPVM)s.a
$(LIBDIR)/pvmd3-mpp:
pvmd3-mpp
$(LIBDIR)/$(LIBPVM)pe.a:
$(LIBPVM)pe.a
cp $(LIBPVM)pe.a $(LIBDIR)
$(LIBDIR)/pvmd3-beo:
pvmd3-beo
$(LIBDIR)/pvmd3-os2:
pvmd3-os2
$(LIBDIR)/lib-os2:
lib-os2
92
$(LIBPVM).a:
rm -f $(LIBPVM).a $(AR) cr $(LIBPVM).a $(LOBJ) $(LPVMSOCK) $(SOCKLOBJ) case x$(HASRANLIB) in xt ) echo ranlib; ranlib $(LIBPVM).a ;; esac
pvmd3-shm:
lib-shm:
rm -f $(LIBPVM).a $(AR) cr $(LIBPVM).a $(LOBJ) $(LPVMSHMEM) $(SHMEMLOBJ) case x$(HASRANLIB) in xt ) echo ranlib; ranlib $(LIBPVM).a ;; esac touch lib-shm
$(LIBPVM)s.a:
rm -f $(LIBPVM)s.a $(AR) cr $(LIBPVM)s.a $(LOBJ) $(LPVMSOCK) $(SOCKLOBJ) case x$(HASRANLIB) in xt ) echo ranlib; ranlib $(LIBPVM)s.a ;; esac
pvmd3-mpp:
$(LIBPVM)pe.a:
93
pvmd3-beo:
pvmd3-os2:
$(CC) $(CFLAGS) -o pvmd3$(EXESFX) $(OS2DOBJ) $(DOBJ) $(SOCKDOBJ) \ $(LOPT) $(ARCHDLIB) touch pvmd3-os2
lib-os2:
rm -f $(LIBPVM).a $(AR) cr $(LIBPVM).a $(LOBJ) $(OS2LOBJ) $(LPVMSOCK) $(SOCKLOBJ) case x$(HASRANLIB) in xt ) echo ranlib; ranlib $(LIBPVM).a ;; esac touch lib-os2
clean:
tidy
tidy: rm -f $(DOBJ) $(SOCKDOBJ) $(SHMEMDOBJ) $(MPPDOBJ) \ $(LOBJ) $(LPVMSOCK) $(SOCKLOBJ) $(LPVMSHMEM) $(SHMEMLOBJ) \ $(LPVMMIMD) $(MPPLOBJ) $(REGEXDIR)/*.o \ pvmd3-shm lib-shm pvmd3-mpp pvmd3-os2 lib-os2 \
94
lint:
lintd lintl
lintd: lint -DARCHCLASS=\$(PVM_ARCH)\ \ ddpro.c host.c hoster.c imalloc.c pkt.c pmsg.c \ pvmalloc.c pvmcruft.c pvmd.c pvmdtev.c pvmfrag.c pvmlog.c \ task.c tdpro.c waitc.c global.c > Ld
lintl: lint -I$(PVMDIR)/include \ lpvm.c0 lpvmshmem.c lpvmmimd.c \ imalloc.c lpvmcat.c lpvmgen.c lpvmpack.c lpvmglob.c \ pvmalloc.c pvmcruft.c pvmerr.c pvmfrag.c tev.c global.c > Ll
$(CC) $(CFLAGS) -c $(SDIR)/ddpro.c host.o: $(SDIR)/host.c $(CC) $(CFLAGS) -c $(SDIR)/host.c vhoster.o: $(SDIR)/hoster.c
$(CC) $(CFLAGS) -c $(SDIR)/imalloc.c lmsg.o: $(SDIR)/lmsg.c $(NODECC) $(CFLAGS) -DIMA_NODE -c $(SDIR)/lmsg.c lpvm.o: $(SDIR)/lpvm.c $(CC) $(CFLAGS) -c $(SDIR)/lpvm.c lpvmshmem.o: $(SDIR)/lpvmshmem.c
95
$(CC) $(CFLAGS) -c $(SDIR)/lpvmgen.c lpvmpack.o: $(SDIR)/lpvmpack.c $(CC) $(CFLAGS) -c $(SDIR)/lpvmpack.c lpvmglob.o: $(SDIR)/lpvmglob.c $(CC) $(CFLAGS) -c $(SDIR)/lpvmglob.c msgbox.o: $(SDIR)/msgbox.c
$(CC) $(CFLAGS) -c $(SDIR)/msgbox.c mppchunkhost.o: $(SDIR)/mppchunk.c $(CC) $(CFLAGS) -c -o mppchunkhost.o $(SDIR)/mppchunk.c mppchunknode.o: $(SDIR)/mppchunk.c $(NODECC) $(CFLAGS) -DIMA_NODE -c -o mppchunknode.o \ $(SDIR)/mppchunk.c mppmsghost.o: $(SDIR)/mppmsg.c
$(NODECC) $(CFLAGS) -DIMA_NODE -c -o mppmsgnode.o $(SDIR)/mppmsg.c nmdclass.o: $(SDIR)/nmdclass.c $(CC) $(CFLAGS) -c $(SDIR)/nmdclass.c pkt.o: $(SDIR)/pkt.c
$(CC) $(CFLAGS) -c $(SDIR)/pkt.c pmsg.o: $(SDIR)/pmsg.c $(CC) $(CFLAGS) -c $(SDIR)/pmsg.c pvmalloc.o: $(SDIR)/pvmalloc.c $(CC) $(CFLAGS) -c $(SDIR)/pvmalloc.c pvmcruft.o: $(SDIR)/pvmcruft.c $(CC) $(CFLAGS) -c $(SDIR)/pvmcruft.c pvmd.o: $(SDIR)/pvmd.c
II.6 Makele.aimk $(CC) $(CFLAGS) -c $(SDIR)/pvmd.c pvmdabuf.o: $(SDIR)/pvmdabuf.c $(CC) $(CFLAGS) -c $(SDIR)/pvmdabuf.c pvmdshmem.o: $(SDIR)/pvmdshmem.c
96
$(CC) $(CFLAGS) -c $(SDIR)/pvmdshmem.c $(PLOCKFILE) pvmdmimd.o: pvmdmimd.c $(CC) $(CFLAGS) -I.. -c pvmdmimd.c
pvmdpack.o: $(SDIR)/pvmdpack.c $(CC) $(CFLAGS) -c $(SDIR)/pvmdpack.c pvmdunix.o: $(SDIR)/pvmdunix.c $(CC) $(CFLAGS) -c $(SDIR)/pvmdunix.c pvmerr.o: $(SDIR)/pvmerr.c
$(CC) $(CFLAGS) -c $(SDIR)/pvmlog.c pvmshmem.o: $(SDIR)/pvmshmem.c $(CC) $(CFLAGS) -c $(SDIR)/pvmshmem.c $(PLOCKFILE) pvmmpp.o: $(SDIR)/pvmmpp.c
$(CC) $(CFLAGS) -c $(SDIR)/sdpro.c task.o: $(SDIR)/task.c $(CC) $(CFLAGS) -c $(SDIR)/task.c tev.o: $(SDIR)/tev.c
97
$(CC) $(CFLAGS) -c $(SDIR)/$(PVM_ARCH)/src/stdlog.c sthoster.o: $(SDIR)/$(PVM_ARCH)/src/sthoster.c $(CC) $(CFLAGS) -c $(SDIR)/$(PVM_ARCH)/src/sthoster.c rexec.o: $(SDIR)/$(PVM_ARCH)/src/rexec.c
$(CC) $(CFLAGS) -c $(SDIR)/$(PVM_ARCH)/src/rexec.c ruserpas.o: $(SDIR)/$(PVM_ARCH)/src/ruserpas.c $(CC) $(CFLAGS) -c $(SDIR)/$(PVM_ARCH)/src/ruserpas.c os2spawn.o: $(SDIR)/$(PVM_ARCH)/src/os2spawn.c $(CC) $(CFLAGS) -c $(SDIR)/$(PVM_ARCH)/src/os2spawn.c
regexconfig:
@ touch regexconfig
regexconfig-os2:
$(REGEXDIR) $(REGEXCP)
$(REGEXDIR)/Makefile:
II.6 Makele.aimk cd $(REGEXDIR) ; CC=$(CC) ./configure $(REGEXCP): $(REGEXSRC) cp $(REGEXSRC) $(REGEXDIR) $(REGEXDIR): @- mkdir $(REGEXDIR)
98
include $(PVMDEPPATH)$(SDIR)/pvmdep
Bibliograa
[01] http://www.linuxclube.com/colunas/13,06,2004.php, acesso em 20 de maro de 2004. c [02] Pitanga,Marcos, Construindo Supercomputadores com Linux, Brasport, Rio de Janeiro , 2002. [03] http://clustering.foundries.sourceforge.net/, acesso em 26 de maro de 2004. c [04] http://www.beowulf-underground.org/, acesso em 26 de maro de 2004. c [05] http://www.inf.aedb.br/download/biblio/sbc2000/eventos/semish/semi008.pdf, acesso em 06 de maio de 2004. [06 ] Tanembaum, Andrew S., Sistemas Operacionais Modernos, Makron Books, So a Paulo , 2003. [07] http://www.copyright.gov/, acesso em 11 de abril de 2004. [08] http://www.beowulf.org, acesso em 05 de junho de 2004. [09] http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=840, acesso em 05 de junho de 2004. [10] http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=733, acesso em 03 de julho de 2004. [11] http://www.beowulf.gr, acesso em 22 de maro de 2004. c [12] http://www.csm.ornl.gov/pvm/pvm home.html, acesso em 07 de agosto de 2004. [13] http://www.csm.ornl.gov/pvm/man/manpages.html, acesso em 20 de agosto de 2004. [14] http://www.canonical.org/ kragen/beowulf-faq.html, acesso em 22 de agosto de 2004. [15] http://www.netlib.org/pvm3/book/node1.html, acesso em 22 de agosto de 2004. [16] http://www-unix.mcs.anl.gov/mpi/, acesso em 02 de setembro de 2004.
BIBLIOGRAFIA [17] http://www-unix.mcs.anl.gov/mpi/mpich2/, acesso em 03 de setembro de 2004. [18] http://www.cacr.caltech.edu/beowulf/, acesso em 10 de setembro de 2004. [19] http://es.tldp.org/Manuales-LuCAS/doc-cluster-computadoras/doc-clustercomputadoras-html/node59.html, acesso em 22 de junho de 2004.
100
[20] http://www.cacr.caltech.edu/beowulf/tutorial/building.html, acesso em 26 de agosto de 2004. [21] http://www.ats.ucla.edu/at/clustering/default.htm, acesso em 17 de maio de 2004. [22] http://www.fysik.dtu.dk/CAMP/cluster-howto.html, acesso em 17 de maio de 2004. [23] http://www.clustermatic.org, acesso em 07 de julho de 2004. [24] http://www.povray.org/, acesso em 10 de novembro de 2004. [25] http://pvmpov.sourceforge.net/, acesso em 02 de abril de 2004. [26] http://www.verrall.demon.co.uk/mpipov/, acesso em 04 de junho de 2004. [27] http://www.linuxjournal.com/article.php?sid=5690, acesso em 06 de junho de 2004.