Message passing interface e parallel virtual machine

mai
MESSAGE PASSING INTERFACE E PARALLEL VIRTUAL MACHINE:
Sistemas Distribuídos, uma análise de funcionamento sobre as
bibliotecas passagem de mensagem MPI e PVM.
JOÃO PAULO MENDES DE CARVALHO
FOZ DO IGUAÇU - PR
2012
UDC - FACULDADE DINÂMICA DAS CATARATAS
CURSO DE SISTEMAS DE INFORMAÇÃO

Sistemas Distribuídos, uma análise de funcionamento sobre a biblioteca
passagem de mensagem MPI e PVM.
JOÃO PAULO MENDES DE CARVALHO
Monografia submetida como requisito
parcial por João Paulo Mendes de Carvalho,
acadêmico do curso de Sistemas de
Informação à obtenção do grau de Bacharel em
Sistemas de Informação, sob a orientação do
professor Fabiano Damin. UDC – União
Dinâmica de Faculdades Cataratas – Foz do
Iguaçu, Paraná.
FOZ DO IGUAÇU - PR
2012
UDC - FACULDADE DINÂMICA DAS CATARATAS
CURSO DE SISTEMAS DE INFORMAÇÃO

TERMO DE APROVAÇÃO
UNIÃO DINAMICA DE FACULDADE CATARATAS
Sistemas distribuídos, uma análise de funcionamento sobre a biblioteca
passagem de mensagem MPI e PVM.
MONOGRAFIA APRESENTADA JUNTO AO CURSO DE SISTEMAS DE
INFORMAÇÃO DA UNIÃO DINÂMICA DE FACULDADES CATARATAS,
COMO REQUISITO PARCIAL DE OBTENÇÃO DO TÍTULO DE BACHAREL
EM SISTEMAS DE INFORMAÇÃO
________________________________________
Acadêmico: João Paulo Mendes de Carvalho
________________________________________
Orientador: Fabiano Damin
________________________________________
Nota Final:
Banca Examinadora:
________________________________________
Professor
________________________________________
Professor
Foz do Iguaçu, Novembro de 2012.

AGRADECIMENTOS
“Agradeço a os professores que me
permitiram estar aqui, e a minha família que
me deu suporte durante todo esse tempo.”

Resumo
Este trabalho representa uma análise de funcionamento sobre as bibliotecas de
passagem de mensagem em cluster, uma abordagem conceitual de sistemas distribuídos
com foco na passagem de mensagem. Aborda algumas ferramentas de construção de
sistemas distribuídos introduz alguns conceitos de redes de computadores para o
entendimento de determinadas características de funcionamento de uma passagem de
mensagem em um sistema distribuído. E por fim exemplifica a passagem de mensagem
com as bibliotecas foco do tralho MPI e PVM.
PALAVRAS-CHAVE: Paravirtualização, Aglomerado, Beowulf, Cluster.

Abstract
This document represents an analysis of message passing libraries in
clustering, a conceptual approach for distributed systems with a focus on message
passing. Covers some tools building distributed systems introduces some concepts of
computer networks for the understanding of certain operating characteristics of a
message passing in a distributed system. Finally exemplifies the message passing
libraries with focus of this work about MPI and PVM.
KEY-WORD: Paravirtualization, Particleboard, Beowulf, Cluster.

LISTA DE FIGURAS
Figura 1. Modelo de distribuição da rede dos EUA antes de Baran. .......................................5
Figura 2. Comunicação com socket TCP.............................................................................11
Figura 3. A hierarquia de requisições no modelo de camadas...............................................18
Figura 4. Funcionamento da requisição e resposta em sistemas de objetos distribuídos ........20
Figura 5. Múltiplas tarefas e única tarefa. ............................................................................33
Figura 6. Modelo de troca de mensagens: Processadores com sua memória local na LAN.....35
Figura 7. Estrutura de Código PVM.....................................................................................29
Figura 8. Configurando DHCP em Cluster Beowulf. .............................................................40
Figura 9. Nó controlador e escravos....................................................................................41

LISTA DE TABELAS:
Tabela 1: Primitivas mais intuitivas da MPI. .........................................................................36
Tabela 2. Argumentos de serviços em C e Fortran. ..............................................................36
Tabela 3. Descrição dos itens a serem comparados.............................................................44
Tabela 4. Tabela comparativa entre PVM e MPI...................................................................44

LISTA DE SIGLAS:
ARPA......................................................... Advanced Research Projects Agency
CORBA......................................... Common Object Request Broker Architecture
DHCP..........................................................Dynamic Host Configuration Protocol
FTP......................................................................................File Transfer Protocol
HA................................................................................................ High Availability
HPC....................................................................... High Performance Computing
HTTP ...................................................................... HyperText Transfer Protocol
IDL......................................................................... Interface Definition Language
IP ............................................................................................... Internet Protocol
MMOGs .........................................................Massive Multiplayer Online Games
MPI ........................................................................... Message Passing Interface
NFS...................................................................................... Network File System
ORNL ...................................................................Oak Ridge National Laboratory
OSI....................................................................... Open Systems Interconnection
PVM ................................................................................Parallel Virtual Machine
RM.............................OSI - Reference Model for Open Systems Interconnection
RMI............................................................................ Remote Method Invocation
RPC .................................................................................Remote Procedure Call
TCP................................................................................Transfer Control Protocol
TID...................................................................................................Task Identifier
TSAP..................................................................Transport Services Access Point
UDP................................................................................ User Datagram Protocol
UTK.................................................................University of Tennessee, Knoxville

SUMÁRIO
1 INTRODUÇÃO.......................................................................................................... 1
1.1 OBJETIVOS ..........................................................................................................2
1.1.1 OBJETIVO GERAL ............................................................................................2
1.1.2 OBJETIVOS ESPECÍFICOS ............................................................................2
1.1.3 JUSTIFICATIVA .................................................................................................2
1.2 PROBLEMA...........................................................................................................3
1.3 METODOLOGIA ...................................................................................................3
1.4 ESTRUTURA DO TRABALHO...........................................................................3
2 REDES DE COMPUTADORES E COMUNICAÇÃO DE DADOS .................... 5
2.1 HISTÓRICO...........................................................................................................5
2.2 O MODELO ISO/OSI ...........................................................................................7
2.3 AS SETE CAMADAS...........................................................................................7
2.4 O MODELO TCP/IP .............................................................................................9
2.4.1 A ARQUITETURA TCP/IP ................................................................................9
3 SISTEMAS DISTRIBUÍDOS ................................................................................. 14
3.1 OBJETIVO DOS SISTEMAS DISTRIBUÍDOS ..............................................15
3.2 ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS ......................................16
3.2.1 ARQUITETURA EM CAMADAS....................................................................17
3.2.2 ARQUITETURA BASEADA EM OBJETOS .................................................19
3.2.3 OUTRAS ARQUITETURAS ...........................................................................20
4 PARALLEL VIRTUAL MACHINE...................................................................... 26
4.1 HISTÓRICO.........................................................................................................26
4.2 ABORDAGEM GERAL DE FUNCIONAMENTO E APLICAÇÃO ...............26
5 MESSAGE PASSING INTERFACE ..................................................................... 31
5.1 HISTÓRICO.........................................................................................................31
5.2 FUNÇÃO DA MPI...............................................................................................32
5.3 VISÃO GERAL DE FUNCIONAMENTO.........................................................32
5.4 ALGUMAS FUNÇÕES MPI ..............................................................................35
6 CLUSTER.......................................................................Error! Bookmark not defined.
6.1 TIPOS E TECNOLOGIAS .................................................................................38
6.2 EXEMPLIFICAÇÃO DA PASSAGEM DE MENSAGEM ..............................39
7 COMPARATIVO ENTRE PVM E MPI ............................................................... 43
8 CONCLUSÃO E TRABALHOS FUTUROS ........................................................ 45
REFERÊNCIAS............................................................................................................ 46

“ Por traz de toda grande mente
existe sim um grande mestre.
Agradeço a todos os professores
que me permitiram estar aqui.”
João Paulo Mendes de Carvalho

1
1 INTRODUÇÃO
Atualmente a troca de mensagem ocorre em diversos ambientes,
permitindo diversos computadores se comunicarem, não se vê explicitamente
esta comunicação, pois acontece de forma transparente. Nos sistemas
distribuídos exemplificados neste trabalho será possível notar os diversos
recursos de passagem de mensagem que efetuam estas tarefas, mas
dificilmente são notados. Em um cluster, técnica foco que será exemplificada
neste trabalho, para demonstrar as biblioteca que permitem o mesmo
funcionar, as mensagens trafegam de forma a dividir tarefas, usando MPI
(Message Passing Interface) ou PVM (Parallel Virtual Machine) que trazem
consigo um conceito de troca de mensagem, essencial no processo de
agrupamento de computadores para efetuar muitas vezes aumento de
performance, técnica também chamada de clusterização, pois possuem a
implementação da passagem de mensagem para os nós de um cluster. Essa
necessidade veio com o crescimento das redes de computadores que se
tornaram grandes redes locais ou remotas junto ao aumento da demanda da
capacidade de processamento. Além da troca de mensagem, também surgiu a
necessidade do compartilhamento de recursos, desde memória a
processamento para o aumento de performance, já que o custo dos
supercomputadores também conhecidos como mainframes que possuíam alto
desempenho é muito elevado. A clusterização veio muito a calhar como uma
alternativa de baixo custo de aquisição e configuração.
O objetivo desta abordagem é mostrar as vantagens de se compartilhar
recursos diversos, e efetuar comunicação distribuída, conceituar os sistemas
distribuídos e comunicação distribuída, deixando claro que o principal objetivo
dos sistemas distribuídos, é facilitar o acesso a recursos remotos ou locais, por
usuários ou aplicações, de maneira controlada e eficiente, da forma mais
transparente possível, isto será exemplificado na clusterização, onde a MPI e
PVM serão vistas de forma mais clara, junto ao conceito de passagem de
mensagem, técnica permite a comunicação entre os nós de um cluster. O
trabalho irá mostrar como os sistemas distribuídos são importantes e pouco
visíveis ao usuário final, ainda ao final do trabalho será feito um comparativo
entre as bibliotecas de cluster PVM e MPI.

2
1.1 OBJETIVOS
Este trabalho tem como objetivo uma análise dos conceitos de
sistemas distribuídos e das bibliotecas MPI e PVM, exemplificando no processo
de clusterização estes conceitos de sistemas distribuídos e passagem de
mensagem, para permitir ao final das abordagens efetuar uma comparação
entre a MPI e PVM.
1.1.1 Objetivo geral
Apresentar os conceitos de sistemas distribuídos exemplificado no
processo de clusterização, assim como uma abordagem de funcionamento
sobre PVM e MPI.
1.1.2 Objetivos específicos
 Apresentar o conceito de passagem de mensagem e sistemas
distribuídos;
 Demonstrar o funcionamento da distribuição de mensagens no
processo de clusterização, o qual deixa claro o funcionamento das
dos modelos de passagem de mensagem e compartilhamento de
recursos.
 Expor o funcionamento das bibliotecas MPI e PVM e fazer um breve
comparativo;
1.1.3 Justificativa
Demonstrar de forma teórica o funcionamento do modelo de passagem
de mensagem MPI, e descreve as áreas fins, e o mesmo se aplica a biblioteca
PVM, que será demonstrada de forma teórica em seu âmbito funcional. Sua
necessidade é justificada na dificuldade em se encontrar materiais que
abstraiam de forma simples e compacta o funcionamento destas bibliotecas e
da passagem de mensagem. Já que seu uso é notável, mas transparente nos
ambientes computacionais em cluster atuais.

3
1.2 PROBLEMA
Como desenvolver aplicações distribuídas e usar recursos distribuídos
em redes remotas e locais, verificar as ferramentas que permitem comunicação
com recursos distribuídos focando principalmente nas bibliotecas MPI e PVM e
uma abordagem de que biblioteca usar e em que momento através de um
comparativo de características.
1.3 METODOLOGIA
A execução deste trabalho foi realizada através de pesquisas
bibliográficas, revisão bibliográfica, informações disponíveis referentes a
tecnologias MPI e PVM, além de estudos sobre sistemas distribuídos e
computação paralela abstraídos de livros e artigos e comentários na internet.
O trabalho será realizado em etapas de pesquisas, sobre
funcionamento de alguns tipos de sistemas distribuídos e suas aplicações nas
necessidades reais e atuais.
A primeira etapa será busca do material para pesquisa, realizada por
meio de um levantamento bibliográfico através de pesquisas em livros e
internet para a melhor qualidade da produção desta monografia.
A segunda etapa será a análise de alguns tipos de sistemas, e seus
funcionamentos a fim de esclarecer duvidas gerais de o que é um sistema
distribuído, e descrever esses funcionamentos, lembrando os objetivos
específicos e gerais.
Ao final será feita uma revisão destes aspectos de funcionamento
sobre a MPI e a PVM, junto a descrição de seus aspectos possíveis limitações
descritas nos matérias de estudo, e uma comparação entre as duas para se
verificar os ambientes onde devem ou podem ser aplicadas.
1.4 ESTRUTURA DO TRABALHO
O Capítulo II traz uma introdução sobre os conceitos de redes,
necessário ao entendimento do trabalho.
O capítulo III, Fala Sobre os conceitos de sistemas distribuídos, em
uma abordagem explicativa e seus diversos fins de utilização e conceitos de

4
diversas fontes, onde o modelo CORBA e RMI é comentado e sua função é
descrita brevemente.
O capítulo IV se destina a descrever o objetivo da biblioteca PVM e
aspectos gerais de funcionamento.
O capítulo V fala sobre os modelos de mensagem MPI e seu histórico,
introduzir informações sobre o funcionamento geral da MPI e algumas
primitivas mais intuitivas.
O capítulo VI fala sobre a clusterização e o funcionamento dos modelos
de passagem de mensagem, e compartilhamento de recursos em um cluster.
O capítulo VII faz um comparativo entre a PVM e a MPI, seguindo
determinadas métricas.
O Capítulo VIII faz uma análise geral sobre os temas abordados e uma
conclusão sobre possíveis trabalhos futuros.

5
2 REDES DE COMPUTADORES E COMUNICAÇÃO DE DADOS
2.1 HISTÓRICO
No final da década de 1950, bem quando a guerra fria estava em seu
auge, os EUA queriam uma rede de comando capaz de sobreviver a uma
grande guerra nuclear. Naquele tempo as comunicações militares trafegavam
pela rede de telefonia pública, considerada vulnerável. A organização desta
rede tinha pontos críticos que a tornavam ineficiente até certo ponto
(TANENBAUM, 2011).
Em 1962, o departamento de defesa dos Estados Unidos, concretizou
um acordo com a RAND Corporation. A fim de buscar uma forma de melhorar
suas comunicações. Um membro da equipe Paul Baran, apresentou um projeto
altamente resistente a falhas. Sabendo que o caminho entre duas centrais
eram bem mais longos do que a distância que os sinais analógicos trafegavam
sem distorção ou interferência, Baran propôs o uso da tecnologia digital de
comutação de pacote em todo o sistema. Baran enviou seus projetos e
relatórios ao departamento de defesa dos EUA com diversos detalhes. O
pentágono gostou da solução e solicitaram a AT&T, que na época era possuía
o controle nacional da telefonia note americana que desenvolvessem um
protótipo. A mesma descartou as soluções de Baran, pois a mais poderosa
corporação do mundo não permitiria que um jovem lhes ensinasse como criar
um sistema telefônico. A empresa afirmou que o projeto não poderia ser
realizado e então foi abandonado (RAND Corporation, 2011).
Figura 1. Modelo de distribuição da rede dos EUA antes de Baran.
Baseado em: (RAND Corporation, 2011).

6
Após muito tempo o departamento de defesa dos EUA ainda não
possuía um sistema mais eficiente de comando e controle. Após os EUA
perderem a corrida espacial para a União Soviética e perceberem que estavam
ociosos, o presidente Eisenhower acabou percebendo a disputa entre as forças
armadas pelo orçamento de pesquisa de defesa. Sua ação foi imediata criar
um único centro de pesquisa e defesa, a ARPA, ou Advanced Research Project
Agency. A ARPA não possuía uma infraestrutura avantajada, na verdade
constituía apenas um pequeno escritório com poucos recursos financeiros na
visão do pentágono. A agência trabalhava oferecendo concessões e contratos
a universidades e empresas cujas ideias pareciam conter potencial
(TANENBAUM, 2003).
Por algum tempo a ARPA buscava por uma missão, mas em 1967, os
esforços do até o momento diretor do projeto ARPA, Larry Roberts, se voltaram
para as redes, o mesmo contatou diversos especialistas para tomar uma
decisão. Um deles Wesley Clark, sugeriu a criação de uma sub-rede comutada
por pacote, dando a cada host seu próprio roteador. Com uma certa
desconfiança Roberts comprou a ideia e apresentou um documento simplista
no ACM SIGOPS (Symposium on operating system principles), realizado em
Gatlinburg, Tennessee, no final do nano de 1967. Para o animo de Roberts
outro trabalho na conferencia descrevia um sistema semelhante, que já havia
sido implementado, sobre a tutela de Donald Davies do NPL (National Physical
Laboratory), na Inglaterra. O sistema implantado no NPL, não funcionava a
nível nacional mas sim interligava vários computadores da NPL, ainda assim
era suficiente para demonstrar que a comutação de pacotes podia funcionar.
Esse trabalho também citava os trabalhos anteriores de Paul Baran. Gatlinburg,
após seu retorno estava empenhado em construir o que ficou conhecido como
ARPANET (TANENBAUM, 2003).
Inspirado pelo sucesso da ARPANET, o programa de pesquisa
experimental da seção de ciência da computação de matemática e física da
NSF, iniciou a sua própria rede em 1981. Chamado CSNET (Computer Science
Network), o sistema prestou serviços de Internet, incluindo correio eletrônico e
conexões para ARPANET (NSF, 2001).

7
2.2 O MODELO ISO/OSI
Este modelo se baseia nas propostas exigidas pelos padrões e
métricas ISO (Organização internacional de padronização). O OSI (sistema
aberto de interconexão) foi o padrão aplicado às interconexões de rede para
todo os sistemas. Possui sete camadas que por sua vez possuem suas
funções e características referentes à suas camadas. Para se chegar a
definição destas camadas alguns conceitos foram aplicados, entre eles o de
que para se criar uma nova camada deve-se verificar se é necessário um novo
grau de abstração. Outro define que cada camada deve realizar operações
bem definidas, a definição destas camadas e suas funções devem ser
caracterizadas com base nos protocolos padronizados internacionalmente. Os
limites de camadas devem ser escolhidos para minimizar os fluxos de
informações pelas interfaces. O número de camadas deve ser grande o
bastante para que funções distintas não precisem ser desnecessariamente
colocadas na mesma camada, e pequena de forma que o controle da
arquitetura não se torne complexo (TANENBAUM, 2011).
2.3 AS SETE CAMADAS
Historicamente, os grandes fabricantes de aparelhos de computação
tinham seu foco de funcionamento voltado a seus produtos, hardware e
software eram únicos daquelas plataformas. O mesmo ocorria com as
organizações e os usuários, isso levou a ISO propor o RM-OSI (Reference
Model – Open Systems Interconnection) (DANTAS, 2002).
Os tópicos a seguir esclareceram quais as camadas que o modelo ISO
propõe e seus aspectos gerais:
a. A camada física é constituída pelos componentes físicos e
elétricos e definições elétricas, os dados trafegam como 0 e 1,
pulsos elétricos KUROSE e ROSS (2006);
b. A camada de enlace possui a tarefa de converter o fluxo bruto
de bits (0 e 1), da camada física, em uma unidade de dado
coerente a camada mais superior TANENBAUM (2011);

8
c. A camada de rede está preocupada com a obtenção de
pacotes a partir da fonte de todo o caminho para o destino,
roteamento dos pacotes entre origem e destino, controle de
congestionamento, além de abertura e fechamento de
conexões ponto a ponto TANENBAUM (2011);
d. A camada de transporte fornece ligação lógica entre processos
de aplicações que rodam em hospedeiros diferentes,
comunicação lógica neste escopo, tem o significado de que
hospedeiros que rodam processos diferentes, do ponto de vista
de uma aplicação, se aparentam estar conectados diretamente,
mas podem estar em pontos remotos do planeta, interligados
por diversos roteadores KUROSE e ROSS (2006);
e. A camada de sessão é projetada para permitir a comunicação
entre aplicações. Então funções comuns deste nível são o
estabelecimento a manutenção e o fechamento de conexões.
Na interoperabilidade entre conexões (conexões com tipos de
sistemas diversos), a comunicação o tráfego (simplex, half-
duplex, ou full-duplex), a sincronização das partes e do
gerenciamento de permissão entre conexões DANTAS (2002);
f. A camada de apresentação oferece um serviço de
independência da representação, fazendo com que a
representação seja apropriada em cada computador. Esta
camada se preocupa com as informações transmitidas no
âmbito de sua sintaxe e semântica tornando possível o
intercambio de informações com computadores de diversas
codificações DANTAS (2002);
g. Na camada de Aplicação estão presentes as aplicações de
rede e seus protocolos como o HTTP (Hyper Text Transfer
Protocol), que prove requisição e envio de documentos na
internet, ou o FTP (File Trasfer Protocol), que prove a
transferência de arquivos entre dois sistemas finais KUROSE e
ROSS (2006).

9
2.4 O MODELO TCP/IP
Oficialmente o nome do chamado protocolo TCP/IP, ou o conjunto de
ferramentas denominada TCP/IP, que pode ser usado para comunicar através
de qualquer rede, ou conjunto da mesma interconectadas. Empresas usam o
TCP/IP para comunicar seus hosts internos, enquanto outras para
comunicação com locais geograficamente distantes. Embora a tecnologia de
TCP/IP é notável por si só, é especialmente interessante, notar que sua
viabilidade e funcionamento foram demonstrados em larga escala (COMER,
2000).
Os modelos OSI citado anteriormente e o TCP/IP são muito parecidos,
ambos se baseiam em uma pilha de protocolos independentes, e as camadas
tem certas semelhanças. Como por exemplo, em ambos os modelos a camada
de transporte esta lá para fornecer uma conexão ponta a ponta na rede.
Novamente em ambos os modelos a camada acima da camada de transporte
fornece suporte as aplicações do usuário, apesar de o TCP/IP possuir apenas
quatro camadas definidas por se considerar suficientes, as camadas
implementam funções como já disse semelhantes (TANENBAUM, 2011).
2.4.1 A Arquitetura TCP/IP
O uso do TCP/IP e demais protocolos pela maioria nas redes de
pesquisa em níveis nacionais e internacionais, permitiu a integração destas
redes geograficamente separada sem uma única rede, que cresceu
extremamente rápido até seu tamanho atual (COULOURIS et al. 2008).
No âmbito de camadas os protocolos usados em determinada camada,
são de responsabilidade da mesma e somente dela, a camada pode utilizar os
protocolos que quiser mas deve oferecer os recursos necessários a isso. A
camada também pode alterar esses protocolos, mas sem alterar o
funcionamento de aplicativos das camadas superiores. Essa ideia assemelha-
se ao conceito de programação de software orientada a objeto, um objeto tem
uma semântica e oferece determinados serviços através de seus métodos,
seus protocolos não estão explícitos, nem acessíveis ou seja seu código, mas
isso não interfere nem importa nada a os elementos fora do objeto, pois o
importante são os parâmetros e retornos (TANENBAUM, 2011).

10
2.4.1.1 O TCP
O TCP (transmission control protocol) é um protocolo caracterizado por
oferecer um serviço confiável entre aplicações a fim e de ser eficaz. O
protocolo identifica os pacotes recebidos fazendo uma associação de cada
pacote em suas respectivas conexões para efetuar a entrega de forma
garantida. A PDU do TCP é conhecida por seguimentos, ou também
denominados, pacotes. O TCP apesar de ser eficaz, durante a comunicação
ocorrem muitas perdas, os pacotes podem chegar fora de ordem, isso faz com
que ele possua uma implementação complexa. Esta localizado na camada três
na arquitetura TCP/IP local do nível dos protocolos de transporte, os protocolos
que hoje fazem parte desta camada são o TCP e o UDP, sendo futuramente
novo protocolos podem ser adicionados para completar as funcionalidades ou
trazer novas funções (DANTAS, 2002).
Complementando o assunto segundo COULOURIS et al. (2008) o TCP,
inclui certos adicionais que são consumidos do protocolo IP para garantir
confiabilidade, como o sequenciamento, controle de fluxo, retransmissão, uso
de buffer e soma de verificação TANENBAUM (2011) explica que TCP também
lida com controle de fluxo para garantir que um remetente rápido não inunde
um receptor lento com mais mensagens do que ele pode manipular.
Segundo KUROSE e ROSS (2006) TCP possui um processo de
comunicação através de socket1
entre um cliente e um servidor, o cliente inicia
uma conexão TCP com o servidor, o cliente cria um socket após isso, o cliente
especifica o endereço do processo servidor, o endereço IP do hospedeiro
servidor e o número da porta do processo servidor com a criação do socket no
cliente mais especificamente no programa cliente, o TCP no mesmo cria uma
apresentação de três vias, e cria uma conexão TCP com o servidor, durante a
apresentação de três vias o cliente solicita entrada no servidor, o servidor ouve
a solicitação de entrada, e cria uma nova porta para este cliente, na verdade
1 Terminal de comunicação onde uma aplicação pode escrever dados que serão
enviados pela rede ou ler dados recebidos (TANENBAUM e STEEN 2007).

11
um novo socket, reservado a este cliente especifico, liberando a porta inicial a
outros clientes. Pode-se verificar este processo na imagem a seguir.
2.4.1.2 O UDP
O protocolo UDP (user datagram protocol) diferente do citado
anteriormente o TCP, é caracterizado como protocolo otimista, pois envia todos
seus pacotes esperando que erro nenhum aconteça, e que a ordem de envio
dos pacotes não será alterada. O UDP, é um protocolo simplista, não
orientado a conexão, ele é usado por protocolos que efetuam operações de
confiabilidade fim a fim. Um exemplo de aplicado do UDP é o NFS2, em um
ambiente onde existe o NFS, a garantia de integridade dos pacotes é do NFS,
e a comunicação rápida entre os envolvidos é do UDP (DANTAS, 2002).
O UDP é amplamente usado em solicitações one-shot, são
solicitações do tipo cliente servidor onde a entrega rápida é mais importante
que a entrega correta, como exemplo de transmissões de vídeo ou fala muitas
vezes usam o UDP (TANENBAUM, 2011).
2 NFS é um sistema de arquivos criado com o objetivo de compartilhar arquivos e
diretórios entre computadores na rede COULOURIS et al. (2011).
Figura 2. Comunicação com socket TCP.
Baseado em: KUROSE e ROSS (2006) e TANEMBAUM (2011).

12
Segundo KUROSE e ROSS (2006) e como já foi visto, o TCP usa
sockets de forma que cria uma conexão confiável de entrega, ou podemos
dizer segura, pois isso essa é uma de suas finalidades. O UDP também
permite que processos que rodam em hospedeiros diferentes se comuniquem,
mas diferente do TCP o UDP não cria um túnel ou podemos dizer uma conexão
com ambos os lados. Como o UDP não cria esse túnel, se deve o remetente,
ou seja, quem esta enviando deve anexar o endereço do destino ao conjunto
de dados. Como o UDP não é orientado a conexão o servidor não precisa criar
um novo socket.
2.4.1.3 O Protocolo IP
O Protocolo IP (internet protocol), é da camada de internet, transmite
datagramas de um host para outro, o protocolo que contém informações de
endereçamento e algumas informações de controle que permite que os pacotes
sejam roteados. O IP representa o coração dos protocolos da Internet. IP tem
duas funções primárias, fornecer conexão, entrega de melhor esforço de
datagramas através de uma Interconexão e fornecimento de fragmentação e
remontagem de datagramas (COULOURIS et al., 2008).
Cada host e cada roteador tem um endereço IP que codifica seu
endereço na rede. A princípio, duas maquinas nunca tem o mesmo endereço
IP. Todos os endereços IP tem 32 bits, e são usados nos campos de endereço
de origem e endereço de destino dos pacotes IP, é importante observar que um
endereço IP não se refere realmente a um host. Na verdade, ele se refere a
uma interface de rede, assim, se um host estiver em duas redes, ele precisara
ter dois endereços IP. Porém, na prática, a maioria dos hosts está em uma
única rede e, portanto, só tem um endereço IP (TANENBAUM, 2003).
Para possuir uma visão clara do IP e sua necessidade, o mesmo será
descrito sobre uma visão de COULOURIS et.al. (2011). A camada IP roteia os
pacotes de sua origem até seu destino, cada roteador presente na internet
implementa o IP, ou seja, todo roteador possui a camada IP em si, isso é
necessário para poder fornecer um serviço de roteamento, termo rotear em si
tem o significado de encaminhamento de origem ao destino.

13
Neste capítulo foi possível verificar detalhes fundamentais para se
entender a passagem de mensagem e comunicação entre computadores
usando os protocolos TCP, UDP e IP que fazem parte da arquitetura TCP/IP.
Esses conceitos são a base da comunicação em sistemas distribuídos em uma
rede, com as informações adquiridas se é possível concluir que esse
funcionamento é transparente nas implementações dos sistemas que serão
abordados a seguir, sobre uma visão é claro de usuário final, pois segundo
TANENBAUM e STEEN (2007) quem implementa estes sistemas deve ter em
vista o funcionamento dos conceitos de redes para melhor desenvoltura de
suas aplicações e entre outros aspectos necessários a construção de um
sistemas distribuído. E se deve enfatizar que as bibliotecas de passagem de
mensagem também consomem os serviços destes protocolos de comunicação,
mas de forma transparente, como ficará claro quando forem abordadas.

14
3 SISTEMAS DISTRIBUÍDOS
Os sistemas distribuídos englobam muitas das mais significativas
tecnologias dos últimos anos e, portanto, uma compreensão das tecnologias e
suas estruturas são fundamentais para o conhecimento da computação
moderna. Com o aumento da maturidade das infraestruturas de sistemas
distribuídos, um número de empresas estão promovendo a visão de recursos
distribuídos como uma mercadoria ou utilidade, é feita uma analogia entre
recursos distribuídos e outras utilidades, como fornecimento de água ou
eletricidade. Com este modelo, os recursos são fornecidos por prestadores de
serviços adequados, e efetivamente alugados em vez de se tornarem
propriedade do usuário final. Este modelo aplica-se tanto a recursos físicos,
como processamento ou armazenamento, quanto a lógicos como os softwares
(COULOURIS et al., 2011).
De Acordo com TANENBAUM e STEEN (2007), um sistema distribuído
sobre uma visão simplista, é tido como conjunto de computadores
independentes que são vistos de forma transparente, ou seja, o usuário não
percebe que esta lidando com diversos computadores. Nenhuma premissa é
adotada para caracterizar o tipo de conexão ou equipamento conectado.
Como proposto por TANENBAUM e STEEN (2007), sistemas
distribuídos devem ser abertos, ou seja, deve ser criado a partir de regras
padronizadas para garantir compatibilidade com outros sistemas, no geral as
interfaces de comunicação costumam ser descritas em uma linguagem de
definição de interface ou no termo em inglês, Interface Definition Language, ou
pela sigla IDL, para que suas métricas sejam visíveis a quem desejar criar
outros recursos compatíveis com o mesmo .
Como proposto por NEUMAN (1994) os sistemas distribuídos devem
ser desenvolvidos de forma escalável, com três princípios básicos, entre eles o
seu tamanho, em termos geográficos, e por último e não menos importante, em
termos administrativos, ou seja, deve ser possível crescer de forma escalável,
de ser distribuído em locais remotos, e deve ser fácil de ser administrado, pois
caso esses requisitos não sejam cumpridos, o sistema estará limitado até certo
ponto, por estes impasses.

15
Uma abordagem simples e direta de sistemas distribuídos segundo
SILBERSCHATZ et al. (2010), e que complementa ou afirma todas as outras já
citadas, diz que, caracterizasse como sistemas distribuídos, um conjunto de
sistemas de computação, separados fisicamente, que pode ser ou não
heterogêneos em sua estrutura, para fornecer ao usuário recursos diversos que
o sistema mantém.
3.1 OBJETIVO DOS SISTEMAS DISTRIBUÍDOS
Anteriormente foram citadas algumas regras para se desenvolver
sistemas distribuídos, e abordados os motivos disto, outra abordagem de outro
autor diz que sistemas distribuídos devem oferecer fácil acesso a recursos, e
devem trazer vantagens em sua aplicação TANENBAUM e STEEN (2007), esta
abordagem simples do objetivo demonstra característica essencial de um
sistema distribuído segundo visão de TANENBAUM e STEEN. Antes de
estender a abordagem do objetivo dos sistemas distribuídos serão citados
alguns exemplos de sistemas existentes. Se pode citar como exemplos de
sistemas distribuídos segundo COULOURIS et al. (2011), sistemas usados na
área de saúde, onde o registro de pacientes é feito de forma eletrônica, ou
ainda a tele medicina no apoio ao diagnóstico remoto, podendo se citar
serviços mais avançados, tal como a cirurgia remota, incluindo o trabalho de
cooperação entre equipes remotas, um sistema de armazenamento distribuído,
que oferece acesso rápido a grandes conjuntos de dados, ou um sistema da
área de entretenimento, como os MMOGs (Massively multiplayer online
games), estes representam um grande desafio para sistemas distribuídos,
especialmente por causa da necessidade de tempo de resposta rápido para
preservar a interação do usuário com o jogo. Outros desafios incluem a
propagação em tempo real de eventos para os diversos jogadores, mantendo
uma visão coerente do mundo compartilhado.
COULOURIS et al. (2011), cita que em um sistema distribuído
localizado em redes de computadores, deve acomodar tanto o hardware
quanto a plataforma de sistema operacional além é claro da rede de
interconexão que é das mais variadas, sendo que essa variedade deve ser
suportada sem problemas. Sistema distribuído é um sistema onde os

16
componentes de hardware e software, localizados em computadores
interligados por uma rede, comunicam e coordenam suas ações somente
através de troca de mensagens, esta abordagem de COULOURIS deixa claro o
objetivo de um sistema distribuído, falando sobre a heterogeneidade das
plataformas lógicas e físicas e complementa mais os conceitos já citados.
3.2 ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS
Quando se foi comentado sobre sistemas distribuídos, foi possível ter
uma visão geral sobre o funcionamento e alguns exemplos de sistemas
distribuídos, mas não se foi descrito como eles são desenvolvidos em sua
estrutura organizacional, em termos de implementação de um sistema
distribuído, será visto neste capítulo as arquiteturas, ou seja, organização
destes sistemas em termos de implementação, com as mais conhecidas e
usadas hoje segundo abordagem de TANENBAUM e STEEN (2007), sendo a
de objetos distribuídos a de maior ênfase neste trabalho, pois no processo de
clusterização onde as bibliotecas de passagem de mensagem MPI e PVM
segundo STERLING (2002) são usadas. STERLING (2002), cita que o modelo
de objetos distribuído é o que melhor representa o funcionamento da
passagem de mensagem em computação distribuída, pois cada nó de um
cluster pode representar um objeto onde as mensagens trafegam, e cada nó
pode e deve ser possível de ser adicionado ao serviço tornando o crescimento
escalável, se pode concluir que isto esta mostrando o conceito de
escalabilidade em sistemas distribuídos.
Complementando as abordagens anteriores e justificando o porque de
se verificar a distribuição das camadas de um sistema, BASS et al. (2003) faz a
observação de que para iniciar uma análise sobre sistemas distribuídos se
deve verificar a distribuição lógica da mesma, ou seja seus componentes,
também denominados arquitetura de sistema. Projetar ou adotar uma
arquitetura hoje se torna essencial para o desenvolvimento de software, esse
estilo de desenvolvimento em arquitetura, serve para interligar os componentes
as arquiteturas de software em camadas e baseadas em objetos, estes estilos
são considerados essências no desenvolvimento de aplicações de grande
porte.

17
3.2.1 Arquitetura em Camadas
Quando se cita a utilização de camadas, há sempre confusão com os
termos layer (camada) e tier (camada). Frequentemente são utilizados como
sinônimos, mas muitos olham tier como uma implicação de separação física.
Sistemas cliente/servidor são frequentemente descritos como sistemas two-tier:
O cliente é um desktop e o servidor é, em geral, um SGBD ou um computador
que presta serviços. As layers (camadas lógicas) se designam à hierarquia de
cada um dos elementos do sistema abstraindo uma separação das suas
tarefas. Na arquitetura em camada cada camada proporciona auxilio a camada
adjacentes por meio de troca de mensagens. A colaboração ocorre
normalmente por métricas de desenho ou os conhecidos design patterns
(FOWLER, 2003).
Camadas de software, se designam como conceito de divisão do
software em camadas, ou módulos em um único computador, ou em termos de
serviços que podem ser oferecidos, e que estarão sendo consumidos por
processos que podem estar solicitando de um mesmo computador, ou de
computadores diferentes, essas camadas efetuam a divisão de tarefas
(COULOURIS et al., 2011).
Como citado por GARLAND e ANTHONY (2003) muitos atributos ou
qualidades são de interesse em arquitetura de software. Estas qualidades são
importantes pois podem impactar no projeto e desenvolvimento de diversas
partes do software. Algumas dessas qualidades são citadas como segurança,
para impedir o acesso não autorizado, a integridade dos dados para não
fornecer dados ruins, entendível, o software pode ser entendido, de modo que
as mudanças posam ser feitas, testável, o software pode ser testado, de forma
eficaz visando seu impacto no meio e sua mutabilidade. Estes são alguns dos
meios os quais a arquitetura se diz técnica e o conjunto mínimo de regras que
regem a arranjo, interação e interdependência das partes ou elementos que,
em conjunto podem ser utilizados para formar um sistema de informação. O
seu objetivo é para garantir que um sistema satisfaça um determinado
conjunto de condições.
Arquitetura é um ingrediente essencial para o sucesso de sistemas de
todos os tipos, de software e serviços para as linhas de produtos e

18
empresas. A capacidade de se expressar, analisar e comunicar essas
arquiteturas é a chave para esse sucesso. Diversos são os interessados que
englobam uma série de preocupações, como a capacidade do sistema que
será desenvolvido, o custo de propriedade, robustez e facilidade de manuseio
que a arquitetura deve enfrentar. Para expressar essas preocupações e
dilemas, cada arquiteto aplica as convenções do seu ponto de vista da
arquitetura. Um ponto de vista determina os tipos de modelo de arquiteturas,
técnicas e métodos pertinentes a um ponto de vista, dando assim os criadores
e usuários uma base de entendimento comum e análise do objeto final (IEEE,
2011).
A figura a seguir demonstra um exemplo do modelo de camadas
representado pelas descrições anteriores e sua hierarquia de resposta e
requisição, conforme também proposto por TANENBAUM e STEEN (2007).
Figura 3. A hierarquia de requisições no modelo de camadas.
Baseado em: (TANENBAUM e STEEN, 2007).
Como citado por GARLAND e ANTHONY (2003), vários padrões
descrevem a relação de compromisso envolvida na criação de uma camada da
arquitetura. O Padrão Camadas descrito por BUSCHMAN (1996), envolve
estruturação do sistema por meio da organização dos elementos em grupos
com diferentes níveis de abstração. O objetivo é estruturar o sistema em um

19
número apropriado de camadas, com o mais alto nível de abstração na camada
superior, e os menores níveis de abstração na camada inferior, essa analogia
se assemelha as características atuais do desenvolvimento em camadas.
A dissolução de sistemas de grande complexidade em camadas é uma
das técnicas mais usadas por arquitetos de software. É uma técnica alugada
da arquitetura de computadores, que utiliza camadas para chamadas de
sistema, devices drivers, instruções do processador, até as portas lógicas
contidas nos chips. Os protocolos de rede também têm utilizado a mesma
técnica de camadas como, o FTP que é baseado em TCP, que por sua vez
utiliza o protocolo IP, que utiliza Ethernet, esta abordagem comparativa mostra
como as diversas camadas consomem uma os serviços da outra (FOWLER,
2003).
3.2.2 Arquitetura baseada em objetos
O objeto distribuído geralmente se refere a software ou módulos que
são projetados para trabalhar em conjunto, ou estar alocado em
vários computadores se comunicando através de uma rede, se comunicando
através de requisições e respostas. Um objeto envia uma mensagem para
outro objeto em uma máquina remota, ou processo para executar uma
tarefa. Os resultados são enviados de volta para o objeto que requisitou a
chamada (COULOURIS, 2011).
Complementando COULOURIS citado acima, TANENBAUM e STEEN
(2007), da por entender que na arquitetura de objetos distribuídos, um sistema
de objetos distribuídos é aquele que permite a operação com objetos remotos.
Assim dito, é possível a partir de uma aplicação cliente orientada a objetos,
obter uma referência para um objeto remoto que oferece o determinado
serviço, e através dessa referência, invocar métodos desse objeto, mesmo que
a instância desse objeto esteja em uma máquina diferente daquela do objeto
cliente.
O desenho a seguir baseado nas ideias propostas mostra como os
objetos distribuídos funcionam no seu modelo de requisição em forma
simplificada.

20
Figura 4. Funcionamento da requisição e resposta em sistemas de objetos distribuídos
Baseado em: (TANENBAUM e STEEN 2007).
A condição atual de um objeto esta em seus valores e variáveis
alocadas. No paradigma baseado em objeto o estado do de um programa
consiste em partes separadas cada uma das partes deve estar associadas a
uma entidade objeto. Como softwares baseados em objeto são logicamente
divididos a distribuição física dos objetos em processos diferentes ou maquinas
é um a extensão natural. Esse tipo de sistema por objeto distribuído pode
adotar uma arquitetura baseada em cliente e servidor, onde os servidores
gerenciam e os clientes invocam, essa invocação pode ser feita por meio de
RMI (remote method invocation) (COULOURIS et al., 2008).
3.2.3 Outras Arquiteturas
Diversas arquiteturas podem ser descritas alem das já citadas e não
menos importantes, como a centrada em dados, que se especifica segundo
TANENBAUM e STEEN (2007), uma arquitetura que se comunica através de
um repositório comum podendo ser ele passivo ou ativo. Normalmente essa

21
arquitetura é usada em sistemas distribuídos de arquivos compartilhados onde
a comunicação quase sempre ocorre por meio de arquivos, as aplicações web
normalmente utilizam muito desse tipo de sistema.
3.2.3.1 Remote Procedure Call
Próximo ao ano de 1970 foi proposto um conceito e técnica
denominada chamada a procedimento remoto, tal conceito permitiria a
comunicação entre processos remotos. O conceito se baseia na possibilidade
de um computador poder invocar serviços de outro computador, de forma
remota. Esse procedimento se mostra uma interação do tipo cliente e servidor,
onde o cliente envia os parâmetros ao servidor, o servidor efetua determinada
operação solicitada pelo cliente, e responde ao cliente o resultado através da
rede. Um dos objetivos da RPC, sigla que denomina esta operação é a
transparência, outro dos demais é facilitar o desenvolvimento de aplicações
distribuídas (DEITEL, 2005).
Em momento qualquer pode haver a necessidade de querer transferir
computação de um sistema local para um remoto, considere uma tarefa que
precisa acessar varias unidades de arquivos em vários locais diferentes para
receber uma previa destes arquivos, ao invés de acessas ele mesmo estes
locais remotos e listar estes arquivos ele invoca o procedimento remoto dos
locais que estes arquivos estão, e recebe apenas os resultados, isto pode ser
feito com uma RPC e é denominado migração de computação. Também existe
a migração de processo, uma extensão da migração de computação, neste
caso, tente supor que um processo que é solicitado execução, nem sempre
será executado no computador onde teve inicio, isso pode ocorrer para que
seja possível balancear carga, acelerar o tempo de computação, a execução
deste processo pode ser mais eficiente em outra plataforma, entre outros. Esse
serviço pode ser feito através de uma RPC (SILBERSCHATZ, 2010).
A RPC segundo TANENBAUM e STEEN (2007) é uma técnica de
passagem de mensagem que é programada de forma transparente ao
desenvolvedor, permite invocação de métodos em computadores remotos. A
Ideia é simples o procedimento que chama não deve estar ciente de que esta
chamando um procedimento em outro computador e o mesmo se aplica a que
esta executando.

22
3.2.3.2 O CORBA
Os serviços CORBA são descritos através de uma interface escrita em
IDL (interface definition language), que são métricas de especificação de
interfaces dos objetos servidores que os clientes precisarão possuir
conhecimento. CORBA não está ligado a uma única plataforma como esta o
RMI com Java, que será descrito em breve. Há mapeamentos IDL para as
linguagens mais utilizadas e, podendo ser escritos para futuras linguagens que
requeiram este suporte sendo assim mais accessível. CORBA permite a troca
de mensagens entre dois objetos remotos e que os objetos locais possam
efetuar chamadas de métodos de forma remota GOULART E GEYER (2000).
O CORBA é uma grande ideia, mas graças a concorrência comercial não
obteve grande sucesso. Um exemplo de aplicação que veio de alternativa ao
CORBA é a Microsoft que, criou sua própria forma de comunicação distribuída,
denominada de DCOM (Distributed Component Object Model), que funciona
apenas em ambiente Microsoft, diferente do CORBA. O CORBA possui o ORB
(Object Request Broker) ou agente de requisição de objetos é um módulo
intermediário entre cliente e objeto, sendo responsável em aceitar a requisição
do cliente, enviá-la para o objeto e depois devolver o resultado, é um tipo de
middleware3 (IBM, 2003; IBM, 2007; DEITEL, 2005).
Vários sistemas de objetos distribuídos foram concebidos ao longo dos
anos, mas os mais promissores para o desenvolvimento de aplicações em
cluster do tipo Beowulf foram CORBA e Java RMI. Existe também Microsoft
DCOM que é uma alternativa viável para o Windows baseados em clusters por
ser da própria Microsoft e fornecer melhores serviços em seu ambiente
homogêneo STERLING (2002). Mais detalhes sobre essa tecnologia de cluster
Beowulf serão concebidos ao longo do trabalho, pois será a tecnologia usada
para exemplificar a passagem de mensagem com MPI e PVM.
CORBA é útil em muitas situações por causa da maneira fácil que
CORBA integra máquinas múltiplas, com tamanhos que variam de mainframes
a desktops e sistemas embarcados, é o middleware de escolha para grandes
ou nem sempre tão grandes empresas. Um exemplo de situação segundo
3 Software que ajuda a fornecer portabilidade, transparência e interoperabilidade em
sistemas distribuídos DEITEL (2005).

23
DEITEL et al. (2005) é quando as plataformas de linguagem a se comunicar
são diferentes, elas podem operar entre si pelo acesso a um núcleo CORBA
comum diferente de Java RMI que só se comunica com objetos Java. Um dos
seus mais importantes, bem mais frequente, que o utiliza é em servidores que
devem lidar com grande número de clientes, com taxas de sucesso elevadas,
com alta confiabilidade.
3.2.3.3 A Invocação de Método Remoto
Como CORBA, Java RMI permite a invocação de métodos em objetos
remotos, ao contrario de CORBA, RMI é de uma facilidade profunda,
construída inteiramente em Java e não requer uma IDL, em Java RMI quando
você referência um objeto remoto ele pode ser usado exatamente como se
estivesse local STERLING (2002).
Como descrito por CHEN et al. (2001), o esquema de entrega de
mensagens pode ser implementado como um processo síncrono, ou um
processo assíncrono. Por exemplo, a um sistema de distribuição síncrona pode
ser implementado usando sockets, uma entrega assíncrona pode ser
implementado como um conjunto de invocações de métodos Remotos (RMI).
O Java Remote Method Invocation (RMI) permite que um objeto sendo
executado em uma máquina virtual Java contate métodos em um objeto em
execução em outra máquina virtual Java. RMI fornece suporte para a
comunicação remota entre programas escritos na linguagem de programação
Java (ORACLE, 2012). Se invocar um método em um outro computador
remoto, usando a mesma sintaxe de chamada a um método local (DEITEL et
al., 2005).
Como a popularidade da tecnologia de objetos aumentou, foram
desenvolvidas técnicas para permitir que as chamadas para objetos remotos,
levando ao que é conhecido como invocação de método remoto (RMI). Uma
RMI é essencialmente o mesmo que uma RPC, exceto que se opera em
objetos, em vez de aplicações (TANENBAUM e STEEN, 2007).

24
3.2.3.4 A API de Sockets
Já citamos o termo socket anteriormente, mas não o contextualizamos
de forma mais exata, mesmo sobre uma visão geral as citações a seguir
deixaram mais claro a função de um socket. Como descrito em TANENBAUM
(2011), cada socket tem um número de socket que representa um endereço,
que consiste no endereço IP do host e em um número de 16 bits local para
esse host, chamado porta. Porta é o nome usado pelo TCP para um TSAP
(Transport Services Access Point). Em TCP para que o serviço TCP funcione, é
necessário que uma conexão seja explicitamente estabelecida entre um socket
da maquina transmissora e um socket da maquina receptora. Um socket pode
ser utilizado por varias conexões ao mesmo tempo. Em outras palavras, duas
ou mais conexões podem terminar no mesmo socket.
Complementando e afirmando termos citados por TANENBAUM
(2011), KUROSE e ROSS (2006), diz que um socket é uma interface de
comunicação em rede, e que possui um buffer usado para escrita e ou leitura,
um socket pode ter múltiplas conexões simultâneas, é pelo socket que os
dados entram e saem.
Neste capítulo foi citado muito sobre sistemas distribuídos, se for
exemplificado no cotidiano segundo os conceitos abordados, eles são
realmente transparentes, e nos fornecem os mais variados serviços, um
exemplo são os jogos, não se vê a comunicação entre os objetos no jogo, se
vê os eventos das ações de jogadores em locais remotos, que criam eventos
na tela que aparentam ocorrer localmente, estes eventos são criados de forma
distribuída quem está jogando pensa que está ocorrendo em sua tela.
Anteriormente foram feitas citações sobre as arquiteturas de sistemas
distribuídos, e ferramentas como Java RMI e CORBA, que permitem
implementar, estes conceitos junto a os de redes ajudam a entender o
funcionamento da passagem de mensagem em uma rede a grosso modo, e
como os diversos sistemas podem se comunicar em uma arquitetura de
objetos de múltiplas ou de uma única plataforma, todos os conceitos abordados
permitem ter uma ideia mais definitiva de um sistema distribuído e seu
funcionamento. A RPC foi o que iniciou o conceito de invocação de método
remoto, e permitiu o surgimento de derivações como o RMI que como já foi

25
visto, é a forma Java de fazer RPC. Finalizando esta revisão geral, com estes
conceitos, se é possível ter ideia da complexidade, que se pode verificar existir
no desenvolvimento de um grande sistema distribuído, permitindo conhecer os
aspectos gerais de sua estrutura de funcionamento, que são essenciais ao
entendimento do conceito de passagem de mensagem.

26
4 PARALLEL VIRTUAL MACHINE
4.1 HISTÓRICO
De Acordo com STERLING (2002), a biblioteca de programação
paralela PVM (Parallel Virtual Machine) foi produzida pelo Heterogeneous
Network Project, um esforço conjunto da Oak Ridge National Laboratory,
University of Tenesse, Emory University e Carneige Mellon University, em
1989, para facilitar o campo da computação paralela heterogênea. O PVM foi
um dos primeiros sistemas de software a possibilitar que programadores
utilizassem uma rede de sistemas heterogêneos, os sistemas heterogêneos
são constituídos por máquinas diferentes com sistemas operacionais dos mais
diversos tipos ou sistemas MPP4 (Massively Parallel Processors) para
desenvolver aplicações paralelas sobre o conceito de passagem de
mensagens. Se diz que um marco importante na aplicação prática do modelo
de passagem de mensagens foi o desenvolvimento de PVM, uma biblioteca de
funções vinculáveis que poderia permitir que as rotinas em execução em
computadores separados, mas em rede para trocar dados e coordenar sua
operação.
Como descrito na UTK e ORNL (2010) PVM é um subproduto de um
projeto de rede heterogênea em curso pesquisas de computação envolvendo
diversos autores e suas instituições. Os objetivos gerais deste projeto são
investigar questões, e desenvolver soluções para, a computação heterogênea
concorrente. PVM é um conjunto integrado de ferramentas de software e
bibliotecas que emula o uso geral, flexível, estrutura de computação
heterogênea simultânea em computadores interligados de arquitetura variada.
4.2 ABORDAGEM GERAL DE FUNCIONAMENTO E APLICAÇÃO
PVM (Parallel Virtual Machine) é um pacote de software que permite
que uma coleção heterogênea de Unix e ou Windows unidos entre si por uma
rede para ser utilizado como um computador de grande porte paralelo e único.
Assim grandes problemas computacionais podem ser resolvidos de maneira
4 São vários computadores, cada com seu processador, conectados por uma rede de
alta velocidade, para obtenção de alto desempenho (DEITEL, 2005 ).

27
mais econômica, usando o poder agregado e memória de muitos
computadores comuns. O software é muito portátil. Objetivo geral do Parallel
Virtual Machine consiste em montar uma máquina virtual de n processadores e
usar estes para executar tarefas em paralelo. O PVM é dividido em três partes
principais, entre elas o console é uma das partes e importantíssimo pois é
usado para montar a máquina paralela virtual. O daemon um programa que
roda em cada máquina do ambiente estabelecendo a comunicação entre as
diversas máquinas E biblioteca da API nesta biblioteca que estão os serviços
ou funções se assim dizer e sub-rotinas que instruem o código a dividir as
tarefas entre os diversos daemons (CSM, 2011).
PVM apresenta API com serviços intuitivos, oferece suporte para
tolerância à falhas, monitoração, entre outros, que é um diferencial ao MPI que
não fornece tolerância a falhas. A biblioteca PVM permitir que um grupo de
computadores interconectados, possivelmente com diferentes arquiteturas,
possa trabalhar cooperativamente formando uma máquina paralela virtual
única, o que contribuiu para torná-lo um padrão de respeito. Dito como um
mecanismo de distribuição livre que oferece recursos para computação
paralela com uma utilização de pouca complexidade (BACELAR, 2006).
De acordo com GEIST et al. (1994), e STERLING (2002),
complementado as descrições anteriores o PVM é composto de duas partes. A
primeira parte, o daemon, chamado pvmd3, executado em todos os
computadores do nó que formarão a máquina virtual paralela. O daemon roda
em background em cada um dos nós, formando a maquina virtual, sendo
responsável pela troca de mensagens entre eles além da coordenação das
tarefas que estão em execução nos nós, As tarefas executadas através do
PVM usam um número inteiro como identificador, o task identifier (TID), que
são utilizados nas mensagens que são trocadas entre os computadores que
formam a máquina virtual paralela. A segunda parte é a biblioteca de funções.
BACELLAR (2008) descreve o PVM com a seguinte citação, o PVM, é uma
biblioteca de comunicação que emula computação concorrente heterogênea de
propósitos gerais em computadores interconectados, qual pode se trabalhar
com diversas arquiteturas.

28
Ainda conceituando o funcionamento da PVM agora sobre uma
abordagem de STERLING (2002) que afirma a versão de divisão em duas
partes do PVM e ainda exemplifica seu funcionamento. O sistema de PVM é
composto de duas partes. A primeira parte é uma daemon, chamado pvmd3, e
por vezes abreviado pvmd, que reside em todos os computadores que
compõem a máquina virtual, (um exemplo de um programa de daemon, é o
programa de email, que roda em segundo plano e trata todo o correio
eletrônico de entrada e saída em um computador).
Segundo DANTAS (2005), PVM foi estruturado com a intenção de
oferecer, facilidade durante o desenvolvimento em ambientes de programação
paralela e a criação de um ambiente sem complexidade, com cluster de
computadores de forma a unificar computadores homogêneos ou heterogêneos
numa imagem de sistema único.
PVM é baseado em um modelo de computação dinâmica onde os nós
do cluster podem ser adicionados e excluídos da computação em tempo real, e
as tarefas paralelas podem ser geradas ou mortas. PVM não possui ricos
recursos de passagem de mensagem como o MPI, sendo um modelo de
maquina virtual tem um conjunto de características que o tornam interessante
como a comunicação entre seus daemos que o tornam mais dinâmico e
comporta abstração diferente da MPI. O controle de processos maior no PVM,
sendo permitido iniciar, interromper, e controlar processos em tempo de
execução, ao passo que no MPI, o controle é bastante restrito sendo permitido
somente o controle de grupo de tarefas. A abstração não existe no MPI, pois
não possui o conceito de máquina virtual paralela. Está mais voltado para o
conceito de passagem de mensagem. No PVM, ao contrário, é possível
considerar a coleção de máquinas como sendo um único recurso
computacional (STERLING, 2002).
Este programa obtém o seu hostname e transmite ao mestre usando
uma sequência de três chamadas, pvm_initsend para inicializar o buffer de
envio (transparente), pvm_pkstr para colocar uma sequencia de caracteres em
uma no buffer de envio e, pvm_send para transmiti-lo para o processo destino
especificado pelo ptid, etiquetando a mensagem com o número 1. Na figura
abaixo é mostrado um exemplo pratico de uma rotina PVM segundo
STERLING (2002).

29
Figura 5. Estrutura de Código PVM.
Fonte: STERLING (2002).
PVM é capaz de resistir a falhas no equipamento onde esta instalado e
na rede. Ele não recupera automaticamente depois de um acidente, mas
fornece primitivas de notificação para permitir encontrar erros de
funcionamento (UTK e ORNL, 2010 ).
PVM não somente suporta o nível de portabilidade como MPI, mas o
expande para o nível de interoperabilidade, um mesmo programa pode estar
interagindo com outro gerado para uma arquitetura completamente diferente
(BARCELAR, 2006).
As aplicações paralelas possuem vários processos que são executados
concorrentemente um ao outro. Todos os processos precisam ser gerenciados
pelos daemons respectivos. As funções do PVM são divididas entre funções de
controle que controlam os processos e funções que gerenciam o envio de
dados pelos sockets (GEIST, et al., 1994).

30
Neste capítulo foi possível verificar que o PVM trabalha com o conceito
de maquina virtual, onde cada daemon, é uma maquina virtual que se
comunica com as demais, que existe um daemon mestre e demais escravos
submissos ao mestre. Diferente do MPI, que não trabalha sobre esse conceito
de abstração o que não permite a integração de ambientes diversos, diferente
do MPI não possui uma IDL. Se for verificado cautelosamente, todo esse
ambiente distribuído permite comunicar diversos computadores para aumento
de desempenho de aplicações, e redução de processamento centralizado pela
distribuição de tarefas, conceito muito útil para aplicações de grande porte com
grande carga de tarefas e processamento. Podemos assim concluir que o PVM
apesar de não oferecer quantidades tão ricas de serviços quanto o MPI, ainda
assim é uma alternativa viável para paralelismo.

31
5 MESSAGE PASSING INTERFACE
5.1 HISTÓRICO
Conforme TANENBAUM E STEEN (2007), em determinado momento,
a necessidade de independência de hardware, e de plataforma, resultou na
criação de um padrão de troca de mensagem, com a denominação de interface
de passagem de mensagem, ou também denominada MPI (Message Passing
Interface). A Ferramenta MPI é projetada para aplicações paralelas, e por isso,
projetada para comunicação transiente usando a rede subjacente, a MPI foi
projetada para permitir comunicação em rede através da passagem de
mensagem.
O MPI é o resultado do esforço de aproximadamente 60 pessoas,
pertencentes a cerca de 40 instituições, maior parte fabricantes dos Estados
Unidos e Europa. A grande maioria dos fabricantes de computadores paralelos
se fez presente, de algum modo, da elaboração do projeto MPI, em conjunto
com pesquisadores de instituições de ensino, laboratórios e autoridades do
governo. Tudo teve início do processo de criação de um padrão, que
aconteceu no seminário sobre padronização para troca de mensagens em
ambiente de memória distribuída, realizado pelo Center for Research on
Parallel Computing, em abril de 1992. Neste evento, as ferramentas básicas
para uma padronização de troca de mensagens foram discutidas e foi
estabelecido uma espécie de grupo que iria trabalhar para dar continuidade à
padronização. O arcabouço preliminar foi criado por Dongarra, Hempel, Hey e
Walker, em novembro 1992, sendo a versão revisada finalizada em fevereiro
de 1993 dando origem a MPI 1.0 (FERREIRA FILHO E IGNÁCIO, 2002).
Historicamente, O MPI surgiu na versão MPI-1.0 em (Junho de 1994)
para a MPI-1.1 em (12 de junho de 1995) para MPI 1.2 em (18 de julho de
1997), com vários acréscimos e publicações de funcionalidades como parte do
documento MPI-2, a MPI-2.0 veio em (18 de julho de 1997), com novas
funcionalidades, a MPI-1.3 (30 de maio de 2008) foi a combinação, por razões
históricas dos documentos 1.1 e 1.2 e alguns documentos de erratas para um
documento combinado, e para MPI-2.1 (23 de junho de 2008), combinando os
documentos anteriores. Versão MPI-2.2 (Setembro de 2009), acrescentou

32
explicações e correções de erros e sete novas rotinas. Em setembro de 2012 a
MPI 3.0 foi lançada, a 3.0 é uma extensão da 2.2 (MPI STANDARD, 2012).
5.2 FUNÇÃO DA MPI
MPI é uma biblioteca de especificação de passagem de mensagem,
usada para comunicação entre processos. MPI aborda principalmente a
passagem de mensagem no modelo de programação paralela, em que os
processos são movidos para o espaço de endereço de um processo para o de
outro processo, através da cooperação entre processos. MPI é uma
especificação não uma implementação, existem varias implementações da
MPI. MPI não é uma linguagem, e todas as operações da MPI são
desenvolvidas em procedimentos ou funções de acordo com a linguagem
apropriada, que em C e Fortran pertencem ao padrão MPI. Esta biblioteca é
desenvolvida por cientistas de computação, programadores, entre outros, o
projeto foi criado por diversos fornecedores de programas paralelos em um
projeto aberto (MPI STANDARD, 2012).
Um dos Objetivos do projeto MPI, é permitir ser implementada como
uma biblioteca, sem necessidade de pré processamento adicional ou
compilação. Assim não se pode esperar ou supor que a chamada de
comunicação tenha informações sobre tipo de dados variáveis no buffer de
comunicação, essas informações devem estar explicitas (MPI STANDARD,
2012).
5.3 VISÃO GERAL DE FUNCIONAMENTO
Antes de falar mais da MPI que trabalha sobre o conceito de
paralelismo e distribuição de tarefas através da passagem de mensagem, se
deve conceituar uma tarefa paralela e uma sequencial. De acordo com DEITEL
(2005), e MACHADO e MAIA (2007), abstraindo de uma forma simples e pouco
abrangente, a execução de uma instrução pode ser paralela ou sequencial,
imagine a sequencial quando uma única tarefa é criada, por uma aplicação
como no nosso exemplo abaixo, e processada por um único processador, e a
paralela, quando uma aplicação gera varia tarefas que pode ser processadas
por diversos processadores ou um único cada uma concorrendo com a outra,

33
esse conceito é uma abstração simples é claro, mas explica a diferença,
também podemos exemplificar varias aplicações gerando cada uma sua tarefa,
ou varias aplicações gerando varias tarefas, a imagem a seguir abstrai esse
conceito conforme a explicação.
MPI aborda o modelo de passagem de mensagens de computação
paralela, em que processos com espaços de endereços separados
sincronizam-se e transferem dados a partir do espaço de endereço de um
processo para a de outro pelo envio e recebimento de mensagens (STERLING,
2002).
..., considera falhas sérias, como quedas de processos ou partições de rede,
sejam fatais e não requeiram recuperação automática.
A MPI adota premissa de que a comunicação ocorre dentro de um
grupo conhecido de processos. Cada grupo recebe um identificador. Cada
processo dentro de um grupo também recebe um identificador (local). Por
conseguinte um par (groupID, processID) identifica automaticamente a fonte ou
o destinatário de uma mensagem e é usado no lugar de um endereço de nível
de transporte. Vários grupos de processos, possivelmente sobrepostos,
poderão estar envolvidos em um serviço de computação, e todo eles poderão
estar em execução ao mesmo tempo (TANENBAUM E STEEN, 2007, p.86).
A descrição abaixo mostra serviços básicos fornecidos pela MPI, com
detalhes simplistas de implementação segundo a MPI STANDARD de 2012:
a) Operação de envio de mensagem;
int MPI_Send( void *buf, int cont,
MPI_Datatype tipo, int dest, int tag,
MPI_Comm grupo );
Figura 6. Múltiplas tarefas e única tarefa.
Baseado em: DEITEL (2005) e MACHADO e MAIA (2007).

34
b) Operação de recepção de mensagem.
int MPI_Recv( void *buf, int cont,
MPI_Datatype tipo, int origem, int tag,
MPI_Comm grupo, MPI_Status *st );
A MPI usada tanto para paralelismo de dados como paralelismo de
tasks (tarefas). Comunmente desenvolvido para C, C++ e Fortran,a
funcionalidade e a semântica (significado das construções) são as mesmas,
dentro dos limites de cada linguagem. A forma de expressar, ou seja, a
sintaxe é semelhante (não é idêntica por as linguagens terem sintaxes
diferentes). É comum, mas não necessário, que os processos tenham acesso a
um mesmo sistema de arquivos, podendo compartilhar arquivos (é problema
deles o fazer, MPI apenas transmite mensagens entre processos)
(PENTEADO, 2010).
Em C ou Fortran quase todas as chamadas retornam um código que
indica a conclusão bem sucedida da operação solicitada. Sempre que possível
as operações MPI retornam um erro se possível, esse erro é um código de erro
da própria. Por padrão sempre que um erro ocorre a operação MPI é abortada,
exceto para operações de arquivos (MPI STANDARD, 2012).
As formas de comunicação é através de operação com bloqueio ou
(blocking operation) onde o processo só pode continuar para a próxima
operação quando tiver finalizado a que já iniciou, ou operação sem bloqueio
(non-blocking operation), a qual o processo pode continuar para a próxima
operação antes de terminar a que iniciou. De uma maneira simples, as
comunicações podem ser vistas como, síncronas, onde o processo que remete
deve esperar que o processo destinatário inicie o recebimento dos dados. Ou
também as assíncronas onde o processo remetente não precisa esperar o
destinatário começar a receber os dados, podendo continuar com a próxima
operação. Alcançar a linha seguinte do programa não significa que o
destinatário já esteja recebendo os dados (PENTEADO, 2010).
MPI gerencia a memória do sistema que é usado para uma mensagem
de buffer e para armazenamento de representações internas de vários objetos
MPI, tais como grupos, comunicadores, tipos de dados, etc. Esta memória não
é diretamente acessível para o usuário (MPI STANDARD, 2012), se pode

35
verificar na figura abaixo o modelo de troca de mensagem, cada computador
possui seu recurso de memória e processamento local, representados na
imagem por processador e memória, a nuvem representa a rede interna, esse
processo da MPI se baseia em memória distribuída, onde cada processador
tem sua memória local, acessível somente a ele. No modelo de memória
compartilhada múltiplos processadores acessam a mesma memória, a forma
de acesso a memória influencia na implementação das bibliotecas de
computação paralela (DIETEL, 2005), mas estes detalhes não serão abordados
neste trabalho.
Figura 7. Modelo de troca de mensagens: Processadores com sua memória local na LAN.
Baseado em: Segundo conceituado por MPI STANDARD (2012) e PENTEADO (2010).
5.4 ALGUMAS FUNÇÕES MPI
A tabela abaixo demonstra alguns serviços disponíveis na API de
padrão MPI:
Primitivas Significados
MPI_bsend Anexa mensagem de saída a um buffer local de
envio
MPI_send Envia uma mensagem e espera até que seja
copiada para buffer local ou remoto
MPI_ssend Envia uma mensagem e espera até o recebimento
começar
MPI_sendrecv Envia uma mensagem e espera por resposta
MPI_isend Passa referencia para mensagem de saída e
continua

36
MPI_issend Passa referencia para mensagem de saída e
espera até o recebimento começar
MPI_recv Recebe uma mensagem ; bloqueia se não houver
nenhuma
MPI_irecv Verifica se há uma mensagem chegando mas não
bloqueia
MPI_Gather Recolhe um elemento de dados de cada processo
(bloqueando).
MPI_Scatter O oposto de Gather (bloqueando).
MPI_Bcast Manda a mesma mensagem para todo mundo
(bloqueando).
MPI_Sendrecv Combina Send com Recv em uma única função
Tabela 1: Primitivas mais intuitivas da MPI.
Baseado em: (TANENBAUM e STEEN 2007 E MPI STANDARD).
A semântica das primitivas de comunicação MPI nem sempre são
diretas e, ás vezes, primitivas diferentes podem ser trocadas sem afetar a
correção de um programa, pois possuem a mesma função, mas são
implementadas de forma diferente. A razão pela qual são suportadas tantas
formas diferentes de comunicação é que isso da aos desenvolvedores de
sistemas MPI possibilidades suficientes para melhorar o desempenho das
aplicações (TANENBAUM E STEEN, 2007).
A seguir uma das funções MPI mais detalhada em seus argumentos da
assinatura segundo MPI STANDARD (2012) para entendimento geral:
LINGUAGEM ASSINATURA
C int MPI_Bcast(*buffer, count, datatype, root, comm)
Fortran CALL MPI_BCAST (buffer, count, datatype, root, comm, ierr)
ARGUMENTO DESCRIÇÃO DO ARGUMENTO
buffer Endereço inicial do dado a ser enviado
count Variável inteira que indica o número de elementos no buffer
datatype Constante MPI que identifica o tipo de dado dos elementos no buffer;
root Inteiro com a identificação do processo que irá efetuar um broadcast,
enviar a mensagem;
comm Identificação do comunicador.
Tabela 2. Argumentos de serviços em C e Fortran.
Baseado em: MPI STANDARD (2012).

37
Conforme já dito a MPI veio com o intuito de padronizar a troca de
mensagem em ambientes paralelos, a MPI não é uma linguagem, e sim uma
biblioteca que pode ser desenvolvida, seguindo determinadas métricas que
estão descritas em seu manual com sua IDL, a MPI fornece diversos serviços
pra a troca de mensagem, muitos serviços tem a mesmo função, segundo
STERLING (2002), mas implementações diferentes, para oferecer aos
desenvolvedores mais flexibilidade para otimização. O MPI, como se pôde
observar, é usado para comunicação entre processos, para distribuir carga de
processamento entre hosts, será exposto no final deste trabalho o
funcionamento da MPI em um cluster, que mostrará a passagem de mensagem
de um nó a outro.

38
6 CLUSTER
De acordo com STERLING (2002), clustering é um conceito poderoso,
e técnica para derivar e estender as capacidades de diversas classes de
componentes existentes. Na natureza, a agregação é um mecanismo
fundamental para criar complexidade e diversidade através da agregação e
síntese de bases simples de elementos. O resultado é nada menos que a
evolução e estrutura do universo, a moléculas dos compostos que ditam a
forma e os atributos de todos os materiais e da forma e comportamento de toda
a vida multicelular, incluindo nós mesmo. Essa visão de STERLING não é
explicitamente computacional é claro mas traz uma certa visão sobre o
potencial da técnica por assim dizer. Mas sobre uma visão de PITANGA
(2008), o termo clustering, se da do inglês para o português como agregado, e
referencia atualmente em duas categorias básicas, o de alta performance e de
alta disponibilidade que trataremos como HA e HPC.
Ainda de acordo com PITANGA (2008), a tecnologia de cluster não é
nada novo, vem de desde os anos 80, mas só comoçou a se popularizar devido
a três fatores, entre eles a construção de processadores de alto desempenho,
o surgimento das redes de baixa latência, e a padronização das ferramentas de
computação paralela e distribuída.
Para simplificar o conceito de cluster sobre uma visão de alto nível é
possível citar o conceito de TANENBAUM e STEEN (2007), o mesmo define
cluster, como um conjunto de maquinas conectadas em rede, trabalhando
como um único recurso. Se abstrairmos esses conceitos já ditos podemos
observar que a transparência está presente neste recurso, pois quem o usa
não vai perceber diversos computadores e sim um único recurso.
6.1 TIPOS E TECNOLOGIAS
Existem diversos tipos e tecnologias de cluster, como O Beowulf,
OSCAR, OpenMosix, OpenSSI, entre outras tecnologias de agregação
proprietárias ou não. Para este trabalho citaremos a tecnologia Beowulf, pois
segundo STERLING (2002), e PITANGA (2008) foi a tecnologia que mais se
popularizou e popularizou as bibliotecas de passagem de mensagem MPI e

39
PVM, além de ser a tecnologia mais comentada em trabalhos científicos neste
ramo .
Estes sistemas Beowulf se tornaram extremamente populares,
fornecendo preço excepcional, alta performance, flexibilidade de configuração,
atualização, e escalabilidade e é baseado em Linux (STERLING, 2002).
Segundo SILBERSCHATZ (2010) o interessante nesta tecnologia é que não
usa um pacote de software específico, sendo criado a partir de um conjunto de
biblioteca de código fonte aberto, que permite a comunicação entre os diversos
nós de um cluster, e ainda não exigem hardware específico, sendo
normalmente construídos com vários computadores pessoais.
Como citado anteriormente PITANGA (2008) classifica cluster em duas
categorias, HA e HPC ou em seus originais em inglês high-availability e high-
performance-computing. Os sistemas do tipo HA tem o objetivo de manter o
serviço seguro de forma que fique disponível o maior tempo possível, os HPC
tem o objetivo de fornecer alta performance computacional. Já sobre uma visão
de DEITEL (2005), os clusters podem ser divididos em três categorias, sendo
que adiciona um tipo, chamado balanceamento de carga, que seria
responsável por distribuir requisições, imaginemos milhares de clientes
exigindo determinado serviço, o balanceamento de carga, seria o técnica de
dividir estas requisições para diversos outros computadores que possuíssem o
mesmo serviço, ao invés de sobrecarregar apenas um computador. A uma
divergência entre os tipos entre estes dois autores, isso ocorre pois PITANGA
(2008) inclui o balanceamento de carga como do tipo HA.
6.2 EXEMPLIFICAÇÃO DA PASSAGEM DE MENSAGEM
Em descrições de STERLING (2002), e relembrando os conceitos de
rede aqui relatados, considere a comunicação em rede entre os nós de um
cluster usando TCP/IP o protocolo padrão de comunicação nesta tecnologia,
sockets também são usados, mas quem usa as tecnologias de passagem de
mensagem MPI e PVM não se preocupara em implementar a comunicação
apenas irá configurar os destinos que aqui são denominados nós essa
comunicação já está implementada nas primitivas MPI e PVM, e só são
solicitados argumentos nos casos onde houve maior esforço devido a

40
necessidade de customização de comunicação. Isso se estiver usando com o
intuito de montar um cluster. Se deve inicialmente, para permitir a passagem de
mensagem, configurar os computadores que serão usados, para isso
necessitamos de um IP em cada um dos computadores, os computadores
devem estar em uma rede de confiança e configurada corretamente, digo
roteadores ou switches, uma das bibliotecas MPI ou PVM devem estar
instaladas. O passo a passo da configuração não é objetivo deste trabalho,
mas algumas configurações serão demonstradas para fim de esclarecimento, é
necessário um conhecimento básico do ambiente GNU/Linux PITANGA (2008).
O DHCP (Dinamic Host Configuration Protocol) é um protocolo que permite
configuração dinâmica de endereços de computadores que usam TCP/IP. O
DHCP evita ter de ir computador por computador configurar seus endereços.
Se pode gerar um arquivo DHCP padrão configurando o arquivo dhcpd.conf do
Linux (PITANGA, 2008).
O nó mestre neste caso, terá um domínio próprio com o nome
mestre.pinguim.br, e assim os escravos terão o nome escravo1.pinguim.br,
Figura 8. Configurando DHCP em Cluster Beowulf.
Fonte: PITANGA (2008).

41
escravo2.pinguim.br, e assim por diante. Desta forma trabalharam em conjunto
dentro da mesma rede. Estas e outras configurações devem ser feitas para o
funcionamento do cluster, nada de complexo para quem possui alguma
afinidade no ambiente Linux. Com estas configurações realizadas de forma
correta os escravos deverão saber quem é seu mestre e a quem devem
responder os resultados, e o mestre a quem deve mandar as solicitações
PITANGA (2008).
Visto estes conceitos analisemos a passagem de mensagem segundo
a seguinte imagem:
Figura 9. Nó controlador e escravos.
Baseado em: PITANGA (2008) e STERLING (2002).

42
Os usuário de um cluster não percebe que está interagindo com
diversos computadores e que as tarefas estão sendo divididas, ele vê apenas
as respostas as solicitações efetuadas, a comunicação entre as bibliotecas e o
sistema operacional ocorre por meio de system calls5
, ou seja, chamadas do
sistema, este conceito se baseia no princípio de que a aplicação, neste caso as
bibliotecas, não são as responsáveis por gerenciar os recursos do hardware, o
sistema operacional é que gerencia estes recursos e retorna os resultados as
bibliotecas STERLING (2002).
Visualize a figura 9 de forma a acoplar a passagem de mensagem
usando as bibliotecas MPI ou PVM, a mensagem sai do nó mestre e vai até os
nós escravos, que por sua vez processam as requisições e retornam ao nó
mestre. Desta forma imagine uma aplicação que cria diversas tarefas, e que é
usada por diversos usuários que fazem diversas requisições. A passagem de
mensagem, que é aplicada neste processo de clustering é essencial, as
bibliotecas que ajudam nesta tarefa se mostram eficientes neste âmbito, pois
haveria menos esforço computacional, distribuir estas tarefas que as computar
localmente. Assim se pode concluir que sistemas distribuídos é um conceito
eficiente e transparente, e é permitido se dizer necessários. Sem a evolução
destes sistemas e dos que os permitiram surgir, nossos recursos atuais seriam
ineficientes, pois tarefas simples seriam muito mais complexas já que recursos
distribuídos teriam de ser todos locais. Com a análise dos ambientes atuais,
também se pode concluir, que estes recursos distribuídos serão cada vez mais
comuns e solicitados, e a transparência, ou seja, o grau de abstração ao
usuário, mais alto, e os recursos distribuídos estarão cada vez mais acessíveis,
como é possível observar hoje, com o surgimento da cloud computing, que
mostra o poder da integração e abstração dos recursos remotos.
5 È um serviço solicitado a o sistema operacional, forma de uma aplicação interagir
com o sistema operacional transferindo responsabilidades (SILBERSCHATZ, 2010).

43
7 COMPARATIVO ENTRE PVM E MPI
Antes de iniciar uma comparação entre as bibliotecas de cluster, é
necessário saber o que deve ser comparado, pois deve haver pontos de
comparação, é necessário criar métricas de comparação para deixar bem
definidos este pontos. Para efetuar este procedimento serão definidas as
seguintes métricas. Quanto a portabilidade, interoperabilidade, tolerância a
falhas e nível dos serviços. Estes parâmetros foram escolhidos com base nas
características descritas pelas literaturas que abordam estas bibliotecas, estas
características estão neste trabalho, e serão organizadas para permitir melhor
visualização das distinções das bibliotecas, as características descritas podem
ser encontradas em STERLING (2002) e PITANGA (2008) assim como no
próprio manual MPI e PVM.
A comparação entre as MPI e PVM será feita em uma tabela, que
organizará as diferenças e homogeneidades das mesmas expostas neste
trabalho, a fim de expor essas características principais segundo as literaturas
que as descrevem, permitindo realizar uma análise de possíveis aplicações das
mesmas em determinados ambientes.
A tabela possuirá quatro linhas, que se referem aos itens de análise,
sendo eles o serviço, interoperabilidade a portabilidade e a tolerância a falhas,
ambos os itens estão na coluna que se designa a característica. A tabela
possuirá uma coluna dedicada a biblioteca PVM, onde em cada linha será dada
uma descrição referente ao item da linha. O mesmo que o PVM será feito com
o MPI.
Antes de comparar as bibliotecas será feita uma descrição do
significado de cada item que a ser comparado, na tabela a seguir:

44
ITEM DESCRIÇÃO
Portabilidade A portabilidade será definida como a capacidade de se
compilar o código fonte e fazer uso do mesmo em qualquer
plataforma BACELAR (2008).
Interoperabilidade A interoperabilidade é dada como a capacidade de permitir
a comunicação entre plataformas distintas. Ex.: A
comunicação pode ser feita entre um sistema operacional
Linux e um Windows STERLING (2002).
Tolerância a falhas É dada como a capacidade de detectar e ou corrigir falhas
STERLING (2002).
Serviços O nível de serviço irá descrever qual das bibliotecas
oferece melhor flexibilidade (múltiplas implementações
para uma mesma tarefa) em seus serviços TANENBAUM
E STEEN (2007).
Tabela 3. Descrição dos itens a serem comparados.
Fonte: Elaborado pelo autor.
Já foi descrito qual significado de cada item, agora se pode analisar as
bibliotecas e as vincular as características descritas, e se definir qual pode ser
usada em quais momentos.
CARACTERÍSTICA MPI PVM
Portabilidade
A MPI é portável, o código
pode ser compilado em
outra arquitetura e
funcionar normalmente
sem qualquer mudança.
A PVM possui
portabilidade, o código
pode ser usado em
qualquer arquitetura sem
mudanças.
Interoperabilidade A MPI não trabalha com o
conceito de abstração
como PVM.
A PVM além de portável
pode trabalhar em diversas
arquiteturas diferentes.
Trabalha com o conceito
de abstração dando ao
usuário a imagem de um
sistema único.
Serviços
A MPI possui diversas
implantações para uma
mesma tarefa, permitindo
ao desenvolvedor uma
gama de possibilidades
para otimizar a
comunicação.
A PVM não possui ricos
recursos de passagem de
mensagem como a MPI.
Tolerância a falhas
Possui alguns serviços
básicos de tolerância a
falhas, como mensagens
de erro de comunicação.
Ainda não possui serviços
de tolerância a falhas na
amplitude do PVM, adota a
premissa de que tudo está
integro no ambiente.
Tabela 4. Tabela comparativa entre PVM e MPI.
Fonte: Elaborado pelo autor.

45
8 CONCLUSÃO E TRABALHOS FUTUROS
Com a análise da MPI e PVM, é possível verificar melhores aplicações
para ambas. Como foi escrito, a MPI possui diversas implementações para
uma mesma tarefa, esta ideia permite ao desenvolvedor otimizar seu
funcionamento de forma mais eficiente para determinada aplicação, ou seja,
oferece diversos serviços para uma mesma tarefa. Assim a MPI pode ser
usada quando o objetivo é criar um ambiente de sistemas operacionais
homogêneos para comunicação paralela, onde o conceito de abstração
presente na PVM, não seja um requisito. A PVM pode ser usada em
ambientes heterogêneos, para integração de ambientes distintos, criando a
imagem de um sistema homogêneo, ela é necessária em ambientes onde a
abstração do mesmo é requisito, a PVM, é uma tecnologia mais antiga que a
MPI, apesar de não fornecer serviços tão ricos, ainda se demonstra viável se
verificados seus aspectos. Descrita esta conclusão se pode verificar que os
conceitos de sistemas distribuídos formam características importantes no
conceito de cluster e nos serviços oferecidos por aplicações remotas, se
demonstrando essenciais atualmente.
Para trabalhos futuros diversos paradigmas não foram abordados aqui,
como a segurança e sistemas distribuídos, fato que é de suma importância
para seu futuro. Para trabalhos futuros, serão analisadas as melhores formas
de se implementar segurança em sistemas distribuídos de cluster, para
fornecer serviços de maior confiabilidade sem remover a transparência destes
sistemas.

46
9 REFERÊNCIAS
.FOWLER, Martin. et al. Patterns of Enterprise Application Architecture.
1.ed. Pearson education, 2003.
BACELAR, Ricardo R. (Esp.). ALGORÍTIMOS PARALELOS: MPI e PVM
Algoritmos paralelos aplicações em sistemas distribuídos, 2006.
BACELLAR, H. Viana. et al. Estudo de Viabilidade de Sistemas
Francamente Acoplados Utilizando Hardware de Baixo Custo. Anhanguera
Educacional S.A. Anuário da Produção de iniciação cientifica discente vol. XI,
n° 12 de 2008.
BASS, Len; CLEMENTS, Paul; KAZMAN Rick. Software Architecture in
Practice. 2.ed. Pearson Education, 2003.
BUSCHMAN, Frank. et al. Pattern-Oriented Software Architecture: A System
of.Patterns. 1.ed, Jon Wiley and Son Ltda, 1996, .V.1.
CHEN, Herry; JOSHI, Anupam; FININ, Tim. Dynamic Service Discovery for
Mobile Computing: Intelligent Agents Meet Jini in the Aether. Fevereiro de
2001. Artigo de teste experimental dos engenheiros da University of Maryland
Baltimore County. Publicado em: Baltzer Science Journal. Disponível em:
<http://ebiquity.umbc.edu/_file_directory_/papers/ 37.pdf>. Acessado em: 24
Set. 2012.
CISCO Systens Inc. Internetworking Technologies Handbook: An essential
reference for every network Professional. 4.ed. CISCO Press, 2003.
COMER, Douglas E. Internetworking with TCP/IP: Principles, Protocols, end
architectures.1.ed. Pearson Education. 2000. V.1.
Computer Science and Mathematics. PVM: Parallel Virtual Machine. Dez.,
2011, Disponível em: <http://www.csm.ornl.gov/pvm/>. Acessado em: 09 de
Nov. de 2012
COULOURIS, G. et al. Distributed Systems: Concepts end Designs. 5.ed.
Boston. Pearson Education, 2011.
COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tin. Sistemas
distribuídos: Conceitos e projetos 4.ed. Bookman, 2008.
DANTAS, Mario. Computação distribuída de alto desempenho: Redes,
Clusters e Grids Computacionais. 1.ed. Rio de Janeiro. Excel Books, 2005.
DANTAS, Mario. Tecnologias de redes de comunicação e computadores.
Rio de Janeiro. Excel Books do Brasil, 2002.
DEITEL, Harvey M.; DEITEL, Paul J.; CHOFFNES, David R. Sistemas
Operacionais. 3.ed. Pearson Prentice Hall, São Paulo, 2005.

47
GARLAND, Jeff; ANTHONY, Richard. Largue Scale Software Architect: A
Practice Guide Using UML, John Wiley and Sons, 2003.
GEIST, A. et al. PVM Parallel Virtual Machine: A Users’ Guide end Tutorial for
Networked Parallel Computing. Massachusetts, Cambridge, MIT Press, 1994.
GOULART, Ricardo A.; GEYER, Claúdio. Um Estudo comparativo sobre os
modelos de objetos distribuídos CORBA, DCOM, e RMI. Trabalho
Especialização (Mestrado), Universidade federal do Rio grande do sul, Porto
alegre. Junho, 2000. Disponível em: <http://www.inf.ufrgs.br/gppd/disc/
cmp167/trabalhos/mp2000-1/RicardoGoulart/index.html#SOCKETS>.Acessado
em: 24 de Set. de 2012.
HILLIARD, Rich. ISO and IEEE publish new edition of standard for
architecture description of systems: Revises the popular standard, IEEE
1471-2000. 17 de jul. 2011. Disponível em: <http://www.iso-
architecture.org/ieee-1471/pr-42010-2011-12.html>. Acesso em: 21 de Set. de
2012.
IBM. IBM WebSphere Application Server Enterprise, Version 5: Common
Object Request Broker Architecture (CORBA). Disponível em:<ftp://ftp.software.
ibm.com/software/webserver/appserv/library/corba.pdf>, 2003. Acessado em:
15 de Nov. de 2012.
IBM. IBM WEBSPHERE® BUSINESS INTEGRATION ADAPTER FOR
CORBA: Working to CORBA. Disponível em: <http://publib.boulder.ibm.com/
infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fbc
22420_.htm>. Ago. de 2012. Acessado em 15 de Nov. de 2012.
IEEE. ISO and IEEE publish new edition of standard for architecture
description of systems: Revises the popular standard. 17 de jul. 2011.
Disponível em: <http://www.iso-architecture.org/ieee-1471/pr-42010-2011-
12.html>. Acesso em: 13 de Nov. de 2012.
IGNÁCIO, Aníbal A. V.; FERREIRA FILHO, Virgilio J. M. MPI: UMA
FERRAMENTA PARA IMPLEMENTAÇÃO PARALELA. Dissertação
(Mestrado), Departamento de engenharia industrial, UFRJ, Rio de janeiro,
Junho de 2002. Disponível em: <http://www.scielo.br/scielo.php? script=sci_
arttext&pid=S0101-74382002000 100007>. Acessado em: 20 de out. de 2012.
KUROSE, James F.; Ross, Keith W. Redes de Computadores e a Internet:
Uma abordagem top-down. Pearson Education do Brasil. 3.ed, São Paulo,
2006.
MACHADO, Francis B; MAIA, Luiz P. Arquitetura de Sistemas Operacionais.
4.ed. L.T.C. Rio de Janeiro, 2007.
MPI STANDARD, MPI: A Message-Passing Interface Standard Version 2.2,
Message Passing Interface Forum, 9 de Set. de 2009.

48
MPI STANDARD, MPI: A Message-Passing Interface Standard Version 3.0,
Message Passing Interface Forum, 21 de Set. de 2012.
NATIONAL SCIENCE FOUNDATION, The Launch of NSFNET. Disponível
em: <http://www.nsf.gov/about/history/nsf0050/internet/launch.htm>, 2001.
Acesso em: 10 de Set. de 2012.
NEUMAN, B. Clifford. Scale in Distributed Systems. 1994, Trabalho de
termino de especialização (Phd) pelo Information Sciences Institute University
of Southern California. IEEE Computer Society Press, 1994.
OBJS. OMG CORBA IDL. Disponível em: <http://www.objs.com/x3h7/corbaidl.
htm>. Acessado em 24 de Set. de 2012.
OMG. CORBA® Basics. 09 de Setembro de 2012. Disponível em: <http://www.
omg.org/gettingstarted/corbafaq.htm#HowWork>. Acessado em 24 de Set. de
2012.
ORACLE. Package Java.rmi. Disponível em: <http://docs.oracle.com/javase/
1.4.2/docs/api/java/rmi/package-summary.html>. Acessado em 24 de Set. de
2012.
ORACLE. Trail: RMI. Disponível em: <http://docs.oracle.com/javase/tutorial/rmi/
index.html>. Acessado em 12 de Nov. de 2012.
PENTEADO, Cesar G. Arquitetura Modular de Processador Multicore Flexível,
Segura e Tolerante a Falhas para Sistemas Embarcados Ciberfisícos. 2010.
Tese Apresentada a escola Politécnica da USP para obtenção do titulo de
Doutor em Engenharia Elétrica, São Paulo, 23 de Dez. de 2010. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/3/3142/tde-28022011-155817/publico/Tese
_Cesar_Giacomini_Penteado.pdf>. Acessado em: 17 de Nov. de 2012.
PITANGA, Marcos. Construindo Supercomputadores com Linux. 3.ed.
Editora Brasport. Rio de Janeiro, 2008.
RAND CORPORATION. Paul Baran and the Origins of the Internet.
Disponível em: <http://www.rand.org/about/history/baran.html> 23 de dezembro
de 2011, Acessado em: 21 de Out. de 2012.
RAND CORPORATION. Transcendental Destination. Disponível em:
<http://www.rand.org/publications/randreview/issues/rr-12-
00/transcendental.html> 23 de dezembro de 2011, Acessado em: 21 de out. de
2012.
SILBERSCHATZ, Abraham; GALVIN, Peter B.; GAGNE, Greg. Fundamentos
de Sistemas Operacionais. 8.ed. L.T.C Ltda., Rio de janeiro, 2010.
STERLING, Thomas. Beowulf cluster computing whith Linux. MIT Press.
Out., 2001.

49
TANENBAUM, Andrew S., Sistemas Operacionais Modernos, Makron Books,
São Paulo, 2003.
TANENBAUM , Andrew S; WETHERALL, David J. Redes de Computadores.
5.ed. Rio de Janeiro: Pearson education do Brasil, 2011.
TANENBAUM ,Andrew S. Redes de Computadores. 4 ed. Rio de Janeiro:
Elsevier editora Ltda, 2003.
TANENBAUM, Andrew S.; STEEN, V. Marteen. Sistemas distribuídos:
Princípios e paradigmas. 2.ed. São Paulo: Pearson Education do Brasil, 2007.
THE UNIVERSITY OF TENESSE e OAK RIDGE NATIONAL LABORATORY.
The PVM System. Disponível em:<http://www.netlib.org/pvm3/book/node17.
html>. Acessado em 22 de out. de 2012.

Message passing interface e parallel virtual machine

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Message passing interface e parallel virtual machine

Semelhante a Message passing interface e parallel virtual machine (20)

Message passing interface e parallel virtual machine