ESTUDO DE APLICABILIDADE DE SISTEMAS

Trabalho realizado com o incentivo e fomento da Anhanguera Educacional S.A.

E

STUDO DE APLICABILIDADE DE SISTEMAS

FRACAMENTE ACOPLADOS UTILIZANDO HARDWARE

DE BAIXO CUSTO

Correspondência/Contato Alameda Maria Tereza, 2000 Valinhos, São Paulo - 13.278-181 rc.ipade@unianhanguera.edu.br pic.ipade@unianhanguera.edu.br Coordenação Instituto de Pesquisas Aplicadas e Desenvolvimento Educacional - IPADE Publicação: 09 de março de 2009

Hilário Viana Bacellar

Matheus de Paula França

Rafael Roberto

Prof. Ms. Edgar Noda

Curso: Ciência da Computação

FACULDADE ANHANGUERA DE VALINHOS ANHANGUERA EDUCACIONAL S.A.

Trabalho apresentado no 8º. Congresso Nacional de Iniciação Científica – CONIC – SEMESP em novembro de 2008.

Trabalho premiado com o 1º. lugar na área de Ciências Exatas, da Terra e Engenharias no 2º. Seminário da Produção Docente e Discente da Anhanguera Educacional em dezembro de 2008.

RESUMO

Este trabalho apresenta um estudo inicial que verifica o uso de arquiteturas paralelas fracamente acopladas na resolução de problemas tradicionalmente intratáveis pelos sistemas computacionais usuais. Entende-se por sistemas computacionais usuais todo o poder de processamento obtido em uma única máquina, cujo custo é considerado acessível ao público em geral. A solução proposta neste artigo é baseada em uma estrutura de cluster Beowulf, implementado com a biblioteca de comunicação paralela MPI em um hardware de baixo custo. A heterogeneidade do equipamento utilizado também foi levada em consideração por ser um cenário usual na utilização de máquinas de baixo custo. De forma a validar o modelo proposto são comparados os tempos de execução de tarefas que executam cálculos exaustivos, os quais foram paralelizados em configurações distintas. A expectativa inicial com relação à possibilidade de ganhar tempo computacional com a paralelização dos dados é confirmada assim como a relevância que a escalabilidade de máquinas possui sobre os resultados obtidos.

Palavras-Chave: Beowulf; cluster; Sistemas Fracamente Acoplados; MPI; Programação Paralela;

A

P

I

C

D

1. INTRODUÇÃO

Nesses últimos anos é notável a evolução do poder computacional que está disponível para a grande maioria de usuários. Com a atual tendência da indústria no desenvolvimento de processadores com múltiplos núcleos, o processamento paralelo nunca esteve tão acessível. Entretanto, muitas aplicações ainda necessitam de um equipamento muitas vezes superior ao utilizado pela maioria dos usuários comuns. Aplicações como previsões climáticas, simulações de problemas que envolvam um número elevado de variáveis ou mesmo resoluções ótimas de problemas com características exponenciais, ainda demandam arquiteturas multiprocessadas fortemente acopladas, equipamentos classificados como supercomputadores.

Devido ao alto valor em investimento, os supercomputadores se tornam inviáveis para a grande maioria dos potenciais usuários interessados nesse tipo de processamento.

Os supercomputadores que são sistemas fortemente acoplados apresentam características como compartilhamento do endereçamento de memória e utilização de um sistema operacional homogêneo. Machado (2007) explica que os sistemas fracamente acoplados são caracterizados pela independência de seus nós computacionais sendo que a comunicação entre eles é realizada por uma das tecnologias de redes de computadores. Uma desvantagem de sistemas fracamente acoplados em relação aos supercomputadores é a necessidade de troca de informações através da rede. Esse é um limitador considerável de desempenho se comparado aos supercomputadores que utilizam o mesmo barramento de memória para a troca de informações. Nos casos de tarefas que apresentam uma

granulosidade grossa1 _{é possível obter um desempenho similar ao de um}

supercomputador, pois, a utilização da rede não influencia no resultado por haver pouca troca de informação.

Na atualidade, existem diversos trabalhos que vem sendo desenvolvidos na área de sistemas distribuídos, no qual, clusters de computadores fazem parte. No trabalho realizado por Pitanga (2003) o cluster Multipinguim é usado para a programação paralela e é uma implementação do tipo Beowulf, cuja finalidade é criar um supercomputador acessível a laboratórios e instituições de ensino superior. Adams (2007) apresenta o Microwulf cujo objetivo foi conseguir a menor relação custo/benefício de um cluster de alto desempenho, visando quebrar a barreira dos 100 dólares por gigaflop2_{. Ao término do}

projeto, com um gasto de 2570 dólares o cluster alcançou a marca de 26,25 gigaflops.

2. OBJETIVO

Tem-se por objetivo a avaliação do desempenho de sistemas fracamente acoplados utilizando hardware de baixo custo ao se utilizar tarefas de cálculo exaustivo e paralelizável. Para isso é necessário a construção de um cluster de computadores compatível com programação paralela tendo como foco o processamento de dados.

3. METODOLOGIA

Com o embasamento da revisão bibliográfica foi possível aprofundar o conhecimento sobre os tipos de cluster e suas principais características. Desta forma, foi adotada inicialmente, a concepção e realização de testes com o cluster do tipo de alto desempenho, cujo foco é o processamento massivo de dados.

Para o cluster de alto desempenho, foi escolhido o tipo Beowulf, utilizando-se o sistema operacional Linux e a biblioteca MPI (Message Passing Interface) para a comunicação paralela. O principal motivo da escolha do tipo Beowulf se deve a sua flexibilidade em trabalhar tanto em ambientes homogêneos como em heterogêneos. A escolha pela MPI se deve aos fatos de que ela é uma biblioteca de comunicação portátil, estável e relativamente nova, apresentando ainda uma facilidade na obtenção de documentação.

O material utilizado para o desenvolvimento da pesquisa foi alocado conforme a disponibilidade dos recursos no laboratório em que os testes foram realizados.

• Um Sempron 3000 1.8 GHz com 512 Mb de memória RAM (Random Access Memory), 40 Gb de HD e placa de rede 100 Mbits.

• Três Duron 950 Mhz com 512 Mb de memória RAM, 20 Gb de HD e placas de rede 100 Mbits.

• Um Hub com 8 portas ethernet.

• Oito Sempron 3000 1.8 GHz com 512 Mb de memória RAM (Random Access Memory), 40 Gb de HD e placa de rede 100 Mbits.

4. DESENVOLVIMENTO

Para a realização deste trabalho foi necessário o entendimento sobre o funcionamento de

clusters, como tornar um processo paralelizável e o uso de bibliotecas de comunicação

paralelas no suporte desta tarefa. Logo, nesta seção são apresentadas informações básicas sobre esses tópicos.

4.1. Cluster

Por definição cluster é uma arquitetura fracamente acoplada interligando mais de um computador em rede, cujo objetivo é fazer com que todo o processamento da aplicação seja distribuído entre os processadores de forma mais transparente possível. De acordo com Tanenbaum (2007) “sistemas de computação em cluster tornaram-se populares quando a razão preço/desempenho de computadores pessoais e estações de trabalho melhorou.” Conforme afirma Pitanga (2004) a utilização de cluster de computadores tem inúmeras vantagens, entre as quais é possível destacar o alto desempenho, a escalabilidade, tolerância a falhas, baixo custo e independência de fornecedores.

Por essas razões clusters são utilizados em servidores web, sistemas de comércio eletrônico, servidores de banco de dados e soluções de firewall. Os tipos de cluster mais conhecidos são:

• processamento distribuído; • balanceamento de carga;

• alta disponibilidade e balanceamento de carga; • alta disponibilidade e tolerância a falhas.

O cluster Beowulf não exige uma arquitetura dedicada, tão pouco máquinas

homogêneas. A conexão entre os nós pode ser feita por meio de Ethernet. Deve haver um ou mais nós mestres (também chamados de nós controladores ou front-end) para realizar o controle dos nós escravos (back-end) - Figura 1. O sistema operacional deve ser baseado em Linux, sendo que o mesmo deve conter todas as ferramentas necessárias para a configuração do cluster.

Figura 1. Arquitetura front-end back-end em cluster.

O nó mestre é responsável pelo monitoramento das falhas que possivelmente podem ocorrer e pelo direcionamento da carga de processamento, caso haja alguma indisponibilidade.

Os nós escravos estão restritos ao processamento das informações passadas a eles pelo nó mestre e a devolução dos resultados.

4.2. Biblioteca de Comunicação Paralela

As bibliotecas de comunicação paralela são responsáveis pela comunicação entre os nós do

cluster. Cada tipo de biblioteca de comunicação tem suas particularidades, ou seja, nelas

são implementadas de maneira diferente as soluções para os problemas de comunicação paralela.

Os padrões mais difundidos de comunicação paralela são: PVM (Parallel Virtual

Machine) e MPI (Message Passing Interface).

Segundo Jaquie (1999) o PVM é um conjunto integrado de bibliotecas e de ferramentas de software, cuja finalidade é emular um sistema heterogêneo.

O PVM cria um modelo de programação paralela composto de processos seqüenciais assíncronos cooperando através de troca de mensagens (KRUG, 1996).

O ambiente PVM é composto de três partes principais. A primeira parte é o

console3 _{que é usado para montar a máquina paralela virtual, por meio de uma máquina}

que estará disponível para o programador disparar os processos. A segunda parte é um

daemon – um programa que roda em todos os nós que formam o cluster, responsável pelo

controle das tarefas que estão sendo executadas nesses nós. A terceira parte é uma biblioteca das rotinas de interface, que contém um conjunto de primitivas que são necessárias para a cooperação entre tarefas de uma aplicação.

O MPI é uma biblioteca de rotinas que fornecem funcionalidades básicas para que os processos se comuniquem. Segundo Jaquie (1999) o MPI surgiu da necessidade de resolver alguns problemas relacionados a plataformas de portabilidades.

O MPI diferentemente do PVM não possui uma máquina virtual paralela. Está centrado no padrão de comunicação de dados para a comunicação paralela por troca de mensagens entre os processos. O MPI oferece diversas rotinas de suporte que ajudam a resolver, ou estruturam melhor a solução para o problema. As rotinas básicas mais conhecidas são definidas a seguir.

• Rank: identificação única crescente atribuída pelo sistema, começando de zero até N-1, no qual N é o número de processos.

• Group: é o conjunto ordenado de processos, podendo este ser o todo ou parte dele.

• Communicator: é o conjunto dos grupos. Permite ao usuário definir módulos encapsulados que fornecem estruturas de comunicação interna.

4.3. Configuração do Cluster implementado

Partindo do pressuposto que o sistema operacional Linux já esteja instalado, as demais configurações necessárias podem ser divididas em três partes: redes, comunicação SSH (Secure Shell) e MPI.

Na Tabela 1 são apresentadas as configurações de rede utilizadas em cada um dos nós do cluster. Na Figura 2 está descrita a edição necessária do arquivo /etc/hosts para estabelecer a identificação das máquinas utilizadas.

Tabela 1: Configuração de rede das máquinas no cluster.

HOSTNAME IP NETMASK GATEWAY

Host1.cluster (Server) 192.168.1.1 255.255.255.0 192.168.1.1 Host2.cluster (Client) 192.168.1.2 255.255.255.0 192.168.1.1 Host3.cluster (Client) 192.168.1.3 255.255.255.0 192.168.1.1 Host4.cluster (Client) 192.168.1.4 255.255.255.0 192.168.1.1 #for loopback 127.0.0.1 localhost #machines 192.168.0.1 host1.cluster host1 192.168.0.2 host2.cluster host2 192.168.0.3 host3.cluster host3 192.168.0.4 host4.cluster host4

Figura 2. Arquivo com as configurações de rede.

Após realizar as configurações iniciais, utiliza-se o protocolo de comunicação seguro e criptografado SSH para que as máquinas se comuniquem. Porém é necessário configurá-lo para não haver a necessidade de senha. Para isso, deve-se aplicar o comando apresentado na Figura 3 nos nós escravos.

ssh-keygen -t rsa

Figura 3. Comando para geração de chave pública.

Uma chave pública é gerada após o comando da Figura 3 e é necessário concatená-la com a chave do servidor do cluster (Figura 4).

scp /root/.ssh/id_rsa.pub root@servidor:/root/ (Digitar senha)

ssh host2

cat /root/id_rsa.pub >> /root/.ssh/authorized_keys

Figura 4. Comandos para concatenar as chaves.

Esses passos devem ser seguidos para todos os nós pertencentes ao cluster. Feito isso, a comunicação sem senha está pronta.

O próximo passo é a instalação da biblioteca MPI. Foi utilizada uma extensão do MPI, mpich-1.2.7p1, cuja configuração é feita ao executar os comandos apresentados na Figura 5.

cd mpich-1.2.7p1

./configure --prefix=/usr/local -rsh=ssh make

make install

Figura 5. Comandos para configuração e instalação do Mpich

A configuração do SSH sem senha e a instalação do Mpich devem ser executadas em todas as máquinas.

4.4. Aplicação Testada

O paradigma escolhido para ser aplicado neste trabalho foi SPMD (Single Program Multiple

Data) com enfoque em um problema clássico - paralelismo de dados para a solução da

multiplicação de matriz quadrática, o qual necessita de alto poder computacional.

A estratégia utilizada para a divisão das tarefas consiste no modelo mestre-escravo, no qual o nó mestre recebe as informações, divide as tarefas entre os integrantes do cluster de forma homogênea, as envia por meio de troca de mensagem MPI e fica aguardando a resposta de cada nó para agrupar as informações e concluir o processo de execução. Na Figura 6 é apresentado esse cenário.

A aplicação implementada foi programada em C e é baseada no paralelismo explícito de dados, no qual o programador é responsável pelo controle do algoritmo paralelo aplicado. Foi utilizada, como modelo de comunicação, a troca de mensagens da biblioteca MPI para linguagem C.

O processo paralelo tem início no nó mestre que recebe as informações e inicia o processo paralelo. Essa atividade consiste em realizar o start do programa em todas as máquinas e, é nesse momento que cada processo recebe sua identificação única dentro do grupo de comunicação que também é criado nesse instante. O grupo de comunicação contém a identificação de todos os processos que foram criados.

Com a conclusão dessa atividade o processo mestre cria e inicializa as matrizes quadráticas A, B e C com dados aleatórios do tipo double. Em seguida, realiza a distribuição das matrizes, em dimensão homogênea, entre os nós escravos e aguarda a resposta.

Por sua vez, o processo escravo aguarda o recebimento dos dados do processo mestre. Cada processo escravo recebe a matriz B e a cada troca de informação uma das colunas da matriz A. Com essas informações, cada processo escravo realiza o cálculo de multiplicação de matriz quadrática e devolve os resultados para ao mestre e finaliza o processo paralelo encerrando a comunicação.

O processo mestre agrupa todos os resultados na matriz C e também encerra o processo paralelo. Na Figura 7 é apresentado o pseudocódigo do algoritmo proposto para o modelo mestre-escravo. INICIO inicia_processo_paralelo Processo_mestre cria_iniciliza_matriz(A) cria_iniciliza_matriz(B) cria_matriz(C) distribui_matriz_entre_escravos(A) envia_matriz(B) recebe_resultado_escravos(C) Fim Processo_mestre Processo_escravo recebe_fragmento_matriz(A) recebe_matriz(B) realizar_calculo envia_resultados_mestre Fim Processo_escravo Finaliza_processo_paralelo FIM

5. RESULTADOS

Os testes realizados consistiram em 10 execuções para cada dimensão N da matriz quadrada avaliada. As matrizes foram geradas aleatoriamente utilizando a função Rand() com o tamanho entre [0, 10000] e também foi utilizada uma semente por tempo, assim evitou-se que os valores das matrizes fossem iguais.

5.1. Cluster Heterogêneo

Na Tabela 2 são descritas as configurações dos testes realizados. Na Tabela 3 são apresentados os tempos médios dos testes e o desvio padrão obtido na variação das 10 execuções para as dimensões de N igual a 1000, 3000 e 5000.

Tabela 2. Configuração dos testes

Configuração 1 1 Sempron 3000

Configuração 2 1 Sempron 3000 e 1 Duron 950 Configuração 3 1 Sempron 3000 e 3 Duron 950

Tabela 3. Tempo de execução dos testes

Configuração 1 Configuração 2 Configuração 3 Tipo de dados: double

tempo (s) tempo (s) tempo (s)

Média 23,032 44,374 24,097 N = 1000 Desvio Padrão 0,014 0,015 0,009 Média 2434,157 4568,150 2273,433 N = 3000 Desvio Padrão 6,868 7,114 6,570 Média 13590,481 22306,736 11024,401 N = 5000 Desvio Padrão 10,198 12,055 9,406

As análises foram realizadas considerando as dimensões das matrizes e as configurações testadas.

Matriz N = 1000

Neste teste, a configuração 1 se mostrou mais eficaz, por se tratar de uma amostra pequena de dados. Com relação à configuração 2, ao realizar a paralelização dos dados verificou-se que poder computacional das máquinas influência nos resultados, pois o tempo total de processamento ficou limitado ao fim da execução da tarefa no Duron 950. Na configuração 3, o cluster teve desempenho similar ao processo seqüencial na configuração 1.

Foi observado que a configuração 2 teve grande aumento no tempo total de execução. Isso ocorreu devido às diferenças entre as máquinas e a necessidade de troca de informações pela rede, causando um atraso.

Matriz N = 3000

Neste teste, a configuração 3 teve tempo de execução menor, devido ao fato de que uma matriz dessa ordem apresenta a necessidade de um poder computacional maior, que é atendido com o processamento paralelo. Por sua vez a configuração 1, por processo seqüencial, não consegue suprir essa necessidade de processamento. Foi observada grande ociosidade do Server (Sempron 3000) durante a execução da configuração 2, causada pela demasiada demora de conclusão da tarefa no Duron 950.

Esse problema poderá ser resolvido com a otimização do algoritmo proposto. Uma alternativa seria adaptar o algoritmo para balancear a carga de processamento entre o Sempron 3000 e o Duron 950 baseado na capacidade de processamento de cada máquina.

Matriz N = 5000

Neste teste, fica evidente que na configuração 2 o tempo total de execução é limitado ao fim da tarefa no Duron 950, pois o poder de processamento do Duron é muito inferior ao do Sempron 3000. O tempo gasto com as trocas de mensagens para paralelizar a execução mais o tempo necessário para o Duron 950 concluir o processamento, aumentaram o tempo total da execução.

A configuração 3 se mostrou aproximadamente 18,75% mais rápida que a configuração 1 e aproximadamente 50,50% mais rápida que a configuração 2. Esses dados comprovam que o cluster da configuração 3 para o problema de multiplicação de matriz quadrática, se torna viável para os casos testados aproximadamente a partir de N igual a 3000. É a partir desta dimensão que a configuração 3 começa a ter tempo total de execução menor que os tempo obtidos pelas configurações 1 e 2. A Figura 8 ilustra a disposição dos tempos apresentados na Tabela 3.

Figura 8. Acompanhamento dos tempos médios de execução.

5.2. Cluster homogêneo

Na Tabela 4 são descritos os cenários dos testes realizados. Na Tabela 5 são apresentados os tempos médios dos testes para cada cenário e o desvio padrão obtidos na variação das execuções para cada dimensão de N.

Tabela 4. Cenários de teste configuração 2.

Cenário 1 1 Sempron 3000

Cenário 2 2 Sempron 3000

Cenário 3 4 Sempron 3000

Cenário 4 8 Sempron 3000

Tabela 5. Tempos de execução da configuração 2.

Cenário 1 Cenário 2 Cenário 3 Cenário 4

Tipo de dados: double

tempo (s) tempo (s) tempo (s) tempo (s)

Média 23,032 13,426 9,058 9,548 N = 1000 Desvio Padrão 0,014 0,782 0,500 0,014 Média 2434,157 1218,072 634,762 354,221 N = 3000 Desvio Padrão 6,868 2,603 0,754 0,365 Média 13590,481 6808,370 3389,542 1789,367 N = 5000 Desvio Padrão 10,198 3,980 9,846 14,858

As análises foram realizadas considerando as dimensões das matrizes e os cenários testados.

Matriz N = 1000

Neste teste, se pode observar que apesar de uma matriz dessa dimensão ser considerada pequena, em relação às outras testadas, os cenários 2, 3 e 4 já apresentam ganho em tempo total de execução.

Entretanto, ao analisar os tempos obtidos pelas configurações 3 e 4 se pode observar que o cenário 4 apresentou uma leve perda de tempo total de execução.

Durante a análise dos testes do cenário 4, foi observado que o problema está no meio físico comum de comunicação, ou seja, a rede. Pois o envio dos dados é feito de forma serial, e para uma matriz dessa dimensão se gasta mais tempo em tráfego de rede para trocar as mensagens entre as máquinas do que de processamento.

Isso comprova que apesar do cenário 4 fazer uso do dobro de máquinas do cenário 3, ele não é a melhor opção para uma matriz dessa ordem.

Com base nessas informações concluiu-se que para um problema no qual se deseja obter um melhor desempenho em tempo total de execução, nem sempre a melhor alternativa é aumentar o número de máquinas para realizar o processamento paralelo, pois há um limite na escalabilidade dessas máquinas.

Matriz N = 3000

Neste teste, pode ser notado que todos os cenários começaram a se apresentar viável como solução para reduzir o tempo total de execução da multiplicação de matriz quadrática de dimensão igual a 3000, pois todos os cenários apresentaram ganho, tanto individualmente, como se comparado uns aos outros.

O cenário 2, quando comparado ao cenário 1, obteve uma redução de aproximadamente 49,71% em seu tempo de execução. O cenário 3, que contém o dobro de máquinas do cenário 2, obteve uma ganho aproximado de 47,71%. E por fim, o cenário 4, que também contém o dobro de máquinas do cenário 3, obteve ganho de 44,07%.

Com base nesses dados, os cenários testados para essa proporção de matriz quadrática, apresentaram um ganho relevante ao dobrar a quantidade de máquinas disponíveis para processamento paralelo.

Matriz N = 5000

Neste teste, se pode observar que apesar do aumento da dimensão da matriz e conseqüentemente os tempos totais de execução, as proporções percentuais de ganho entre os cenários apresentados se manteve, de certa forma, estável.

O cenário 2, quando comparado ao cenário 1, obteve uma redução de aproximadamente 49,84% em seu tempo de execução. O cenário 3, que contém o dobro de máquinas do cenário 2, obteve uma ganho aproximado de 50,04%. E por fim, o cenário 4 obteve ganho de 46,02% com relação ao cenário 3.

De acordo com a Tabela 9, o cenário 4 obteve o menor tempo de execução para o problema de multiplicação de matriz quadrática de dimensão igual a 5000. Quando comparado ao cenário 1 foi obtido um ganho em tempo de execução de aproximadamente 86,71%. Esses dados comprovam que, para essa aplicação utilizada para testes, que implementa a multiplicação de matriz quadrática paralela, o cluster homogêneo se torna viável para os casos testados.

A Figura 9 ilustra a disposição dos tempos apresentados na Tabela 5.

Figura 9. Tempos médios de execução do cenário 2.

6. CONSIDERAÇÕES FINAIS

Os resultados obtidos no ambiente cluster de programação de alto desempenho utilizando

hardware de baixo custo foram satisfatórios. Considerando o equipamento utilizado nos

testes, foi possível verificar um ganho no poder computacional na utilização do equipamento quando configurado cluster. Ou seja, constatou-se que a utilização de técnicas de programação paralela aumenta o ganho de processamento em ambientes configurados para essa finalidade.

Com relação ao estudo sobre a técnica de processamento paralelo fracamente acoplado, pode-se concluir que essa arquitetura é uma alternativa viável para soluções de problemas que necessitam de um grande poder computacional. Pois, deve-se levar em consideração o aumento potencial da capacidade computacional que pode ser obtida com o aumento de número de nós ou a utilização de equipamento mais potente.

Cluster Heterogêneo

Um ponto importante a ser ressaltado é desempenho obtido pela configuração 2, uma vez que este caso de teste indicou que um ambiente heterogêneo necessita de uma técnica de balanceamento de carga proporcional a capacidade de processamento, pois é clara a perda de desempenho frente à configuração 1 com apenas uma máquina.

Outro fator importante a ser mencionado foi que para a alocação da matriz quadrática com tamanho a partir de 3000 foi utilizada uma grande quantidade de memória

swap do Linux. Essa memória, por sua vez, tem velocidade inferior à memória RAM por

estar alocada no disco rígido do sistema, o que gera perda no desempenho do cluster. Uma solução para esse problema é aumentar a quantidade de memória principal, mas na maioria das vezes não é viável, seja pelo custo ou pela disponibilidade dos computadores usados na concepção do cluster. Mesmo no caso da utilização de máquinas que disponham maior capacidade de processamento, ainda existe um limite no possível aumento de memória. Desta forma, o balanceamento de carga - limitador do poder computacional entre máquinas distintas em um cluster de acordo com suas configurações, e uma adequação da modelagem mestre-escravo proposta para esta tarefa, também podem ser utilizados neste caso.

Cluster Homogêneo

Um fator importante a ser mencionado foi o ganho de desempenho do cluster a partir do cenário 2, sendo que o tempo de execução caiu aproximadamente pela metade se comparado com o cenário 1 para as matrizes quadráticas de tamanho maior ou igual a 5000.

Outro ponto importante é o desempenho obtido pelo cenário 4, na matriz com dimensão igual a 1000. Este caso de teste indica que mesmo em um ambiente homogêneo, nem sempre a melhor alternativa é aumentar o número de máquinas para realizar o processamento paralelo, pois há um limite na escalabilidade dessas máquinas.

Respeitando-se as limitações observadas, conclui-se ainda que exista uma grande gama de aplicações que podem se beneficiar deste tipo de arquitetura. Isso motiva a

continuidade dos estudos de forma a avançar não apenas no desenvolvimento do modelo atual, assim como no estudo de outros tipos de clusters. Mais especificamente, a extensão para uma abordagem mista utilizando os conceitos de cluster de balanceamento de carga e alta disponibilidade.

REFERÊNCIAS

ADAMS, Joel. Brom Tim. Layton Jeff. Microwulf: Breaking the $100/GFLOP Barrier. Disponível em: <http://www.clustermonkey.net//content/view/211/1/>. Acesso em: jul. 2008.

JAQUIE, Kalinka Regina Lucas. Extensão da Ferramenta de Apoio à Programação Paralela (F.A.P.P.) para ambientes paralelos virtuais. Disponível em:

<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08022001-095456/>. Acesso em: jul. 2008.

KRUG, Ricardo Corrêa; TEODOROWITSCH, Roland. Ambiente de programação paralela. Relatório de Pesquisa da Universidade Luterana do Brasil, Centro de Ciências Naturais e Exatas. Departamento de Informática, Canoas, 1996. 191pag.

MACHADO, Francis. BERENGER, Maia, Luiz. Paulo. Arquitetura de Sistemas Operacionais. 4. ed. Editora LTC, São Paulo, 2007.

PITANGA, Marcos. O cluster Multipinguim. Disponível em:

<http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=269&pagina=2>. Acesso em: jul. 2008.

PITANGA, Marcos. Construindo supercomputadores com Linux. 2. ed. Editora Brasport. Rio de Janeiro, 2004.

TANENBAUM, Andrew S. Sistemas Distribuídos: Princípios e Paradigmas. 2. ed. Editora Pearson Prentice Hall, São Paulo, 2007.