Centro Federal de Educacao Tecnologica de Goias Departamento de Telecomunicacoes Curso de Redes de Comunicacao

ESLI PEREIRA FAUSTINO JUNIOR REINALDO BORGES DE FREITAS

Construindo Supercomputadores com Linux- Cluster Beowulf -

Goinia a 2005

ESLI PEREIRA FAUSTINO JUNIOR REINALDO BORGES DE FREITAS

Construindo Supercomputadores com Linux- Cluster Beowulf -

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

Orientador: Cloves Ferreira J nior uMestre

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

ESLI PEREIRA FAUSTINO JUNIOR REINALDO BORGES DE FREITAS

Construindo Supercomputadores com Linux- Cluster Beowulf -

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

Aprovado em 17 de maro de 2005 c

BANCA EXAMINADORA

Cloves Ferreira Jnior uMestre

Edio Cardoso de PaivaMestre

Paulo Csar Bezerra Bastos eMestre

` A Deus o autor da vida. Aos nossos familiares. ` A nossa carreira.

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

AbstractOne 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

Lista de Figuras Lista de Tabelas 1 Introduo ca 2 Cluster 2.1 2.2

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

3 Por que o Linux? 4 Beowulf 4.1

BProc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1 4.1.2 4.1.3 Processos Ghost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Mascaramento de PID . . . . . . . . . . . . . . . . . . . . . . . . . 26 Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 4.3

PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 34

5 Administrao do Cluster ca 5.1

bWatch - Beowulf Watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 O Cluster OpenMosix 6.1 6.2

36

Cluster OpenMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 OpenMOSIXVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 41 50

7 Implementao ca 8 Demonstrao do Cluster Beowulf ca 8.1 8.2 Demonstraao do BProc c

. . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Aplicaoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 c 8.2.1 8.2.2 PovRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Compilador Distribu - Pvmmake . . . . . . . . . . . . . . . . . . 54 do

8.3 8.4

PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 63

9 Tuning 9.1 9.2 9.3

O que . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 e Como fazer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Outras Consideraoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 c 68

10 Consideraes para trabalhos futuros co

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

8

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

Viso Geral - BProc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 a Bwatch com carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

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

8.1 8.2 8.3

Stress2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Tempo de Compilaao do Kernel . . . . . . . . . . . . . . . . . . . . . . . 58 c Renderizaao POVRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 c

11

1 Introduo caO 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 Cluster2.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

2.2 Tipos de Clusters

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

Cluster de Alta Disponibilidade

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

2.2 Tipos de Clusters

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

Cluster de Alta Performance de Computao ca

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

3 Por que o Linux?Hoje em dia o Linux um clone do Unix, capaz de rodar X Windows, TCP/IP, Emacs, e UUCP, mail e muitos outros recursos consagrados. Quase todos os programas de dom nio pblico tm sido portados para o Linux. Sof twares comerciais tambm tm recebido u e e e verses para Linux. A quantidade de dispositivos suportados pelas verses de hoje (2.6.x) o o tambm foi consideravelmente ampliada em relaao `s suas primeiras verses. e c a o O Unix um dos sistemas operacionais mais populares dispon e veis hoje em dia. Um dos motivos dessa popularidade o grande nmero de arquiteturas que rodam alguma e u verso Unix. Ele foi originalmente desenvolvido na dcada de 1970, nos laboratrios Bell, a e o como um sistema multitarefa para minicomputadores e computadores de grande porte. As primeiras verses do Unix tiveram seu cdigo licenciado para diversas universidades o o e centros de pesquisa, onde gerou uma legio de fs e desenvolvedores. Isso contribui a a tambm para o desenvolvimento e implementao de vrias verses de Unix, muitas das e ca a o quais continuaram a ser desenvolvidas depois que o cdigo do Unix passou a no ser mais o a licenciado academicamente, como o caso da Universidade de Berkeley (BSD- Berkeley e Software Distribution). A partir do momento em que o cdigo do Unix no pode mais ser utilizado livremente, alo a guns programadores partiram para implementaes prprias do sistema operacional Unix, co o como o caso do Minix (Tanenbaum, 1986) e do Linux por Linus Torvalds. e O sistema operacional Linux uma implementaao independente da especicao para e c ca sistema operacional POSIX, com extenses System V e BSD. O linux distribu grao e do tuitamente nos termos da Licena Pblica GNU (GN U General P ublic Licence), sendo c u que no existe cdigo de propriedade em seu pacote de distribuio. Ele funciona em IBM a o ca PCs e compat veis com barramentos ISA, EISA ou PCI e processadores 386 ou superiores, existindo tambm implementaoes para outras arquiteturas. e c O Linux foi originalmente desenvolvido como passatempo por Linus Torvalds na Universidade de Helsinky, na Finlndia. O desenvolvimento do Linux contou, no entanto, com a a colaboraao e ajuda de muitos programadores e especialista em Unix atravs da Interc e net. Ele foi inspirado no sistema operacional Minix, um sistema Unix de pequeno porte desenvolvido por Andrew Tanenbaum (1986), sendo que as primeiras discusses sobre o o

3 Por que o Linux?

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

3 Por que o Linux?

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

3 Por que o Linux?

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

Figura 4.1: Viso Geral - BProc a

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:

console: usado para montar a mquina paralela virtual. a

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

5.1 bWatch - Beowulf Watch

35

Figura 5.2: Bwatch sem carga as mquinas listadas no arquivo listofhosts. a

Figura 5.3: Bwatch sem escravo1

36

6 O Cluster OpenMosix6.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

6.1 Cluster OpenMosix

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.

6.2 OpenMOSIXVIEW OpenMosixhistory: histrico dos processos no nosso cluster. o

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

7 Implementaao c + libpcap + libpcap-devel + mcrypt

42

Rede:

+ iptables + iptraf + libnet + nfs-server + nmap + rsh + tcpdump

Utilitrios: a

+ unzip + zip

X11:

+ xterm

Congure as interfaces de rede: IP, mscara, nome, gateway e DNS. a

Congure o arquivo /etc/hosts com os IPs dos ns do cluster: o

127.0.0.1 127.0.0.2 127.0.0.3 127.0.0.4

mestre escravo1 escravo2 escravo3

mestre escravo1 escravo2 escravo3

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

mestre escravo1 escravo2 escravo3 escravo4 escravo5 escravo6 escravo7

Acrescente em /etc/securetty:

rsh rlogin

Selecione o GRUB como gerenciador de boot.

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

+ atd + crond + gpm (se quiser usar mouse no console) + keytable

7 Implementaao c + netfs + network + nfs + nfslock + portmap + random + rawdevices + rlogin + rsh + sshd + syslog + xinetd

44

Reinicie a mquina. a

Neste ponto o Conectiva 8 estar pronto para funcionar. a

### PREPARANDO PARA COMPILAR O KERNEL ###

Baixe a fonte do kernel 2.4.19, dispon em www.kernel.org vel

Descompacte e crie um link simblico: o

/usr/src# tar zxvf /caminho/para/linux-2.4.16.tar.gz /usr/src# ln -s linux-2.4.16.tar.gz linux

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

Baixe e descompacte o fonte do BProc. Depois aplique o patch[23] no kernel:

/usr/src/linux# patch -p1 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.

Saia do menu e salve a congurao. ca

/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

Reinicie com o novo kernel.

### INSTALANDO O BProc ### V para o diretrio do fonte do BProc e execute: a o

# make # make install # cp clients/libBProc.so.2 /usr/lib/. # cd/boot /boot# rm -f vmlinuz /boot# ln -s vmlinuz-2.4.19 vmlinuz

Reinicie com o novo kernel.

Neste ponto sua mquina est pronta para atuar em cluster beowulf. a a

### CONFIGURANDO O BProc###

Edite o arquivo de conguraao do mestre: /etc/beowulf/cong c

As diretivas de conguraao esto na documentaao do BProc. c a c

# 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

### TESTANDO A INSTALACAO DO BProc ###

Execute tanto no mestre como nos escravos:

# modprobe BProc

No mestre, execute:

# bpmaster

Nos escravos, execute:

# bpslave 2223

Onde MESTRE representa o IP ou o NOME do mestre na rede.

De volta ao mestre, execute:

# bpstat

e verique se todos os escravos esto listados como UP. a ### AUTOMATIZANDO A INICIALIZACAO ###

No MESTRE, crie o arquivo /etc/init.d/BProc :

7 Implementaao c

48

!/bin/sh /sbin/modprobe BProc /usr/sbin/bpmaster

Nos ESCRAVOS, crie o arquivo /etc/init.d/BProc :

!/bin/sh /sbin/modprobe BProc /usr/sbin/bpslave MESTRE 2223

Onde MESTRE representa o IP ou o NOME do mestre na rede.

Em TODOS os ns do cluster, inclusive MESTRE: o

# cd /etc/rcN.d/

(N pode ser 2,3,4 ou 5. No Conectiva, quando iniciado no console, use 3)

/etc/rc3.d# ln -s ../init.d/BProc S98BProc

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

Edite o arquivo /etc/bashrc e acrescente estas linhas:

export PVM_ROOT=/usr/share/pvm3 export PVM_ARCH=LINUX export PVM_TMP=/tmp/pvm

7 Implementaao c

49

export PATH=$PATH:$PVM_ROOT/lib:$PVM_ROOT/lib/$PVM_ARCH:$PVM_ROOT/bin/$PVM_ARCH export PVM_DPATH=$PVM_ROOT/lib/pvmd

Compile o PVM:

cd /usr/share/pvm3 /usr/share/pvm3# make

Inicie o PVM no MESTRE:

# pvm pvm> add mestre

Acrescente os escravos:

pvm> add escravo1 pvm> add escravo2 pvm> add escravo3 pvm> add escravo4 pvm> add escravo5 pvm> add escravo6 pvm> add escravo7

Verique se todos esto no cluster: a

pvm> conf

50

8 Demonstrao do Cluster Beowulf caAs estaoes utilizadas nesse projeto foram: c 3 mquinas Pentium 4, 1.8 GHz; (2 mquinas para o cluster e outra apenas para a a monitorar) cada uma com 40GB de HD; cada uma com 128M de RAM; Teclados 102 teclas (ABNT2); Mouses e monitores padro IBM; a

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

8.1 Demonstrao do BProc ca

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~

Processos na mquina mestre durante a execuao: a c

895 899

?

S

0:00

/usr/sbin/bpslave -s 192.168.200.1 mestre 2223

?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

1163 ? 1166 ? 1169 ? 1172 ?

8.1 Demonstrao do BProc ca 1175 ? R 0:04 ./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

Processos na mquina escravo1: a

925 929

? ?

S S R R R R R

0:00 0:00 0:06 0:06 0:06 0:06 0:05

/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

1045 ? 1046 ? 1047 ? 1048 ? 1049 ?

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

8.2 Aplicaoes c Resultados 1 Mquina a Stress2 188 s 2 Mquinas a 94 s

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

Aplicaes coPovRay

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

Compilador Distribu - Pvmmake do

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

Processos na mquina escravo1: a

4377 ? 4454 ? 4455 ? 4468 ? 4469 ? 4724 ? 4725 ? 4848 ?

S S S S S S S S

0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00

/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

8.3 PVM 4849 ? 4853 ? 4854 ? S S R 0:00 0:00 0:00

56 /root/mestre/linux-2.4.19/../pvmgmake/make -C q /usr/share/pvm3/bin/LINUX/make_pvm 262186 /root/mestre/linux-2.4.19/../pvmgmake/make -C i

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

Figura 8.2: XPVM - Sa da

Figura 8.3: Diviso dos Processos - pvmmake a

8.3 PVM

58

Figura 8.4: Utilizao - pvmmake ca

Resultados mestre Tempo 22 min e 22 seg mestre+escravo 17min e 23 seg

Tabela 8.2: Tempo de Compilao do Kernel ca

8.4 MPI

59 Tambm realizamos a renderizao de uma imagem tridimensional utilizando e ca

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

Figura 8.5: XPVM - Linha do Tempo

Figura 8.6: Renderizao Parcial do POVRAY ca

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

0:00 0:00 0:00 0:00 0:00 0:00 0:00

/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

732 ? 19308 ? 19309 ? 19310 ?

S S R S

0:00 0:00 0:35 0:00

xinetd -reuse in.rshd /root/mestre/povray31/source/mpi-unix/mpi-x-pov /root/mestre/povray31/source/mpi-unix/mpi-x-p

Processos na mquina escravo1: a

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

/root/mestre/povray31/source/mpi-unix/mpi-x-pov /root/mestre/povray31/source/mpi-unix/mpi-x-p in.rshd /root/mestre/povray31/source/mpi-unix/mpi-x-pov /root/mestre/povray31/source/mpi-unix/mpi-x-p

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

9.2 Como fazer

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

9.2 Como fazer

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

9.3 Outras Consideraes co

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 granul