UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO
MARCOS ENNES BARRETO
RAFAEL BOHRER ÁVILA
Estudo e Desenvolvimento de um Modelo de
Integração de Agregados Heterogêneos
Relatório de Pesquisa
RP-666
Prof. Dr. Philippe Olivier Alexandre Navaux
Orientador
Porto Alegre, abril de 2003
SUMÁRIO
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 COMPUTAÇÃO BASEADA EM GRIDS . . . . . . . . . . . . . . . . . .
2.1
Estudos de Casos: Ambientes de programação para grids . . . . . . . .
2.1.1
Globus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Legion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
WebFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4
NetSolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5
Síntese e Análise Comparativa . . . . . . . . . . . . . . . . . . . . . . .
7
8
8
10
13
14
16
3 A BIBLIOTECA DE PROGRAMAÇÃO DECK
3.1
Modelo de programação . . . . . . . . . . . .
3.2
Estrutura do modelo . . . . . . . . . . . . . .
3.2.1
DECK em redes Ethernet . . . . . . . . . . .
3.2.2
DECK em redes Myrinet . . . . . . . . . . .
3.2.3
DECK em redes SCI . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
19
19
19
22
23
24
4 O MODELO DE INTEGRAÇÃO: MULTICLUSTER
4.1
Aspectos de hardware . . . . . . . . . . . . . . . .
4.2
Aspectos de software . . . . . . . . . . . . . . . . .
4.2.1
Nós lógicos e físicos . . . . . . . . . . . . . . . .
4.2.2
Comunicação . . . . . . . . . . . . . . . . . . . .
4.2.3
Heterogeneidade . . . . . . . . . . . . . . . . . . .
4.3
Protocolo de comunicação entre clusters . . . . . .
4.3.1
Avaliação de um protótipo do RCD . . . . . . . . .
4.4
Considerações adicionais sobre o modelo . . . . . .
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
26
26
27
27
28
29
30
30
32
CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5
.
.
.
.
.
.
.
.
.
.
.
.
LISTA DE FIGURAS
Figura 3.1:
Figura 3.2:
Figura 3.3:
Figura 3.4:
Figura 3.5:
Interações no ambiente DECK . . . . . . . . . . . . .
Estrutura do modelo conceitual do DECK. . . . . . . .
Latência e largura de banda para a rede Fast Ethernet. .
Latência e largura de banda para a rede Myrinet. . . .
Largura de banda do DECK e ScaMPI na rede SCI. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
23
24
25
Figura 4.1:
Figura 4.2:
Figura 4.3:
Figura 4.4:
Interconexão entre clusters Myrinet e SCI. . . . . . . . . . . . . . .
Arquivo descritor para uma aplicação MultiCluster. . . . . . . . . .
Trajeto da mensagem enviada de um cluster a outro através do RCD
Latência e largura de banda obtidas com o protótipo do RCD . . . .
.
.
.
.
27
28
31
31
LISTA DE TABELAS
Tabela 2.1:
Síntese das funcionalidades dos ambientes de Grid Computing. . . .
17
5
1 INTRODUÇÃO
A partir da metade dos anos 90, com o surgimento de redes de comunicação
de alto desempenho, tais como Myrinet (BODEN et al., 1995) e SCI (INSTITUTE
OF ELECTRICAL AND ELECTRONIC ENGINEERS, 1992; HELLWAGNER; REINEFELD, 1999), muitas instituições de ensino e pesquisa começaram a utilizar plataformas
baseadas em computadores comuns conectados por essas redes. Essas plataformas foram denominadas clusters e a sua utilização ficou mundialmente conhecida como cluster
computing (STERLING et al., 1999; BUYYA, 1999a,b; STERLING, 2002).
O uso de clusters mudou drasticamente o panorama da programação paralela, uma
vez que as bibliotecas de multiprogramação e comunicação até então utilizadas tiveram
que ser adaptadas para protocolos específicos para essas redes de alto desempenho. Até o
presente momento, muita pesquisa já foi realizada com esse tipo de plataforma, resultando
em ambientes de programação e gerenciamento de clusters até mesmo com centenas de
nós processadores.
Atualmente, o foco das pesquisa nessa área evoluiu para o estabelecimento de
grandes plataformas computacionais, onde cada nó corresponde não mais a um PC mono
ou multiprocessado, mas sim a um cluster com dezenas ou centenas de PCs. Essa nova
área de estudo é denominada metacomputing ou grid computing e seu objetivo principal é
a junção de clusters geograficamente distribuídos com o intuito de formar uma única plataforma computacional, que possa ser compartilhada por diferentes usuários considerandose aspectos relacionados às interfaces de programação, questões de compartilhamento de
dados e arquivos, segurança, autenticação, balanceamento de carga e tolerância a falhas.
Nesse contexto, existem igualmente dezenas de ambientes que propõem-se a tal
fim; muitos deles evoluiram de plataformas baseadas em clusters para plataformas de
grids. Além dos ambientes, existem diferentes esforços da comunidade científica e industrial (grupos de trabalhos, fóruns, listas de discussão, etc.) para o estabelecimento de
padrões para os serviços e protocolos que devem ser suportados nessas plataformas.
Este projeto de pesquisa não trata diretamente da área de grid computing, pois
está relacionado ao projeto MultiCluster (descrito no Capítulo 4), que tem por objetivo
a integração de clusters que estão fisicamente próximos, mas que são heterogêneos em
relação ao paradigma de comunicação entre processos e à rede de comunicação. Dessa
forma, aspectos como segurança e autenticação não são prioritários nesse contexto. O
foco está no estabelecimento de um ambiente de programação que possa integrar de forma
eficiente clusters conectados por redes Myrinet, SCI e Fast Ethernet, por exemplo.
O projeto apresenta também um estudo sobre alguns dos mais importantes ambientes utilizados em plataformas de grid atualmente, com o objetivo de ilustrar as funcionalidades providas por cada um, bem como aspectos de sua organização estrutural.
Este trabalho está organizado da seguinte maneira: o Capítulo 2 descreve alguns
6
aspectos sobre a computação baseada em clusters e a sua evolução para a exploração de
grids, bem como apresenta estudos de casos sobre alguns ambientes largamente utilizados
em plataformas de clusters e grids e uma análise comparativa entre os mesmos; o Capítulo 3 apresenta o DECK, que corresponde a um ambiente de programação originalmente
destinado para clusters e que vem sendo estendido para suportar as características advindas da integração de clusters, as quais são propostas pelo MultiCluster; nesse capítulo são
ainda descritas algumas implementações disponíveis do DECK, bem como avaliações de
desempenho da execução de aplicações paralelas. O modelo de integração de clusters
heterogêneos proposto é apresentado no Capítulo 4, detalhando as características de integração definidas, juntamente com uma avaliação preliminar de desempenho. Por último,
o Capítulo 5 apresenta algumas conclusões sobre o trabalho desenvolvido e considerações
futuras.
7
2 COMPUTAÇÃO BASEADA EM GRIDS
O termo metacomputing é originalmente atribuído a Larry Smarr, diretor do NCSA,
que por volta de 1989 o divulgou mundialmente através de seu projeto CASA, que consistia em uma das primeiras redes Gigabit dos Estados Unidos (FOSTER; KESSELMAN,
1999).
Um metacomputador ou grid pode ser definido como um ambiente dinâmico onde
um conjunto de nós de processamento (agregados ou clusters) pode ser adicionado ou
removido sempre que necessário. Cada conjunto de nós é, portanto, independente dos
demais. De uma forma geral, um metacomputador corresponde a um conjunto de agregados interconectados via uma rede de comunicação e que pode ser usado de maneira
transparente para a execução de aplicações paralelas ou distribuídas.
O surgimento da computação baseada em grids deu-se como uma consequência
direta do estabelecimento de plataformas baseadas em agregados individuais em universidades e na indústria para a execução de aplicações complexas.
É claro que atualmente não existem ainda muitas plataformas desse tipo, pois muitos aspectos relacionados com segurança, compartilhamento de recursos, comunicação e
gerenciamento têm sido estudados com o objetivo de se determinar quais os recursos mínimos necessários para que esse tipo de plataforma possa ser utilizada de maneira eficiente
e segura para a execução de aplicações complexas de grande porte.
Mesmo com tantas questões ainda pendentes, já existem diversos ambientes de
programação e de gerenciamento voltados para esse tipo de arquitetura, tais como Globus, Legion, Condor, Codine, LSF, WebFlow e NetSolve. Todos esses ambientes provêem
serviços e mecanismos que implementam a maioria dos aspectos relacionados com a utilização de grids.
Basicamente, pode-se estabelecer que a exploração de grids requer as seguintes
funcionalidades:
• acesso homogêneo e transparente a todos os nós (agregados ou máquinas paralelas dedicadas) componentes do grid. Isto requer a definição de interfaces de
acesso comuns a todos os nós, bem como esquemas de proteção e autenticação
de usuários e aplicações.
• manutenção da autonomia local de cada nó, compreendendo a sustentação de
políticas de acesso, segurança, comunicação e de escalonamento.
• definição de protocolos de comunicação comuns a todos os nós, bem como
suporte para todas as linguagens e bibliotecas de programação usadas. É importante salientar que o usuário não deve ser obrigado a utilizar uma determinada
8
linguagem ou biblioteca simplesmente porque a plataforma não provê suporte
para outras ferramentas.
• estabelecimento de uma camada global de gerenciamento e alocação de recursos, uma vez que os usuários têm necessidades diferentes e a plataforma pode
ser composta por nós heterogêneos em relação ao poder de processamento, representação de dados e mecanismos de comunicação. Isso requer igualmente
que as políticas locais de gerenciamento sejam mantidas.
• definição de mecanismos de tolerância a falhas, com possibilidade de migração
de tarefas entre os nós do grid, visto que algumas aplicações requerem muito
tempo de processamento e alto grau de confiabilidade.
• definição de políticas e protocolos para compartilhamento e transferência de
arquivos entre os nós.
Ainda, é necessária a definição de regras para autenticação remota de usuários,
visto que o mesmo não deve, obrigatoriamente, possuir cadastro (login e diretório home)
em todas as máquinas componentes da plataforma.
Como pode ser observado, a utilização de grids não é trivialmente realizável em
um curto espaço de tempo, visto que demanda um conjunto de funcionalidades bastante
complexo. Ainda pode-se salientar que, como a maioria das aplicações já possui uma ou
mais implementações voltadas para arquiteturas de agregados ou para redes de estações,
é necessário que um ambiente de programação para grid suporte linguagens e bibliotecas
consideradas padrões de facto na comunidade científica, tais como PThreads e MPI.
Entretanto, esse tipo de plataforma tem sido considerada “a quinta era” (FOSTER;
KESSELMAN, 1999) da computação, onde vislumbra-se a total integração de plataformas geograficamente dispersas com o objetivo de prover um poder de processamento até
hoje não disponível, com acesso seguro e utilização eficiente dos recursos compartilhados. A computação baseada em grids têm sido o novo desafio na área de computação
distribuída, da mesma forma que a utilização eficiente de agregados afetou a área de computação paralela nos anos 90.
2.1 Estudos de Casos: Ambientes de programação para grids
Atualmente, existem dezenas de ambientes de desenvolvimento de aplicações para
plataformas baseadas em clusters e grids. Alguns desses ambientes correspondem a evoluções de ambientes já existentes, quando a computação paralela e distribuída era explorada
em supercomputadores e em redes de computadores ou estações, respectivamente.
Esta Seção apresenta alguns ambientes cujos propósitos estão inseridos no contexto da computação baseada em grids, escolhidos em razão de sua importância e unanimidade dentro da comunidade científica.
2.1.1 Globus
Globus (FOSTER; KESSELMAN, 1998) é um projeto multi-institucional americano cujo objetivo é possibilitar a construção de grids computacionais.
Um grid, na terminologia do projeto, corresponde a um infraestrutura de hardware
e software que provê acesso a recursos computacionais, independente da localização geográfica dos mesmos. Dessa forma, uma aplicação que executa sobre o Globus é capaz
9
de gerenciar recursos distribuídos e até mesmos heterogêneos como se fossem uma única
máquina virtual.
O principal componente dessa infraestrutura é o Globus Metacomputing Toolkit
(GMT), que corresponde a uma camada de software que implementa serviços e funcionalidades requeridos para o estabelecimento de um grid computacional, tais como localização e gerenciamento de recursos, serviço de nomes, comunicação, entre outros.
Um ponto importante na filosofia do Globus é o fornecimento não de um único
modelo de programação, mas sim de um conjunto de serviços elementares os quais os
desenvolvedores de aplicações podem estender para implementar as funcionalidades que
necessitam. Estruturado em módulos, o Globus provê serviços de baixo nível, necessários para a execução de qualquer aplicação; e serviços mais elaborados, construídos sobre
os primeiros. Dessa forma, os desenvolvedores de aplicações têm bastante flexibilidade
para interagir com um determinado serviço, sem precisar utilizar outros serviços desnecessários (por exemplo, utilizar o gerenciamento de recursos sem utilizar primitivas de
comunicação). Essa característica também pode ser notada no DECK.
Algumas das funcionalidades providas pelo GMT são:
• gerenciamento de processos e alocação de recursos (GRAM);
• primitivas de comunicação ponto-a-ponto e em grupo (Nexus);
• serviços de autenticação e segurança (GSI);
• interfaces seqüenciais e paralelas para acesso remoto a dados e caching(GASS);
• acesso remoto a informações de estado e estrutura (MDS);
• monitoramento dos recursos do sistema (HBM);
• gerenciamento de executáveis (GEM).
De uma maneira geral, o Globus pode ser visto como um framework composto
por um conjunto de interfaces (APIs) para serviços básicos, possibilitando ao programador o desenvolvimento de ambientes de computação e aplicações complexas, capazes de
explorarem os recursos providos por um grid.
Algumas das principais características do Globus são:
• A estrutura modular adotada pelo Globus torna todos os serviços iguais hierarquicamente, ou seja, existem interfaces de comunicação para qualquer par de
serviços.
• Todas as funcionalidades de comunicação são providas pela biblioteca Nexus,
através de primitivas de comunicação que suportam diferentes semânticas (protocolos e suas características). Nexus é um exemplo de biblioteca que foi largamente usada para o desenvolvimento de aplicações em redes de estações e em
clusters, e que mais tarde foi adaptada para a exploração de grids.
• O MDS (Metacomputing Directory Service) é responsável por prover informações estáticas e dinâmicas sobre os recursos existentes dentro do ambiente de
grid. Esse serviço está baseado em um servidor LDAP (Lightweight Directory
Access Protocol) capaz de armazenar informações sobre potência e disponibilidade dos recursos.
10
• As entidades de computação são os processos. Dessa forma, todo o controle
de concorrência e a comunicação entre threads deve ser feita via primitivas da
biblioteca Nexus.
• A resolução de nomes é realizada através de servidores LDAP, DNS e X.500; e
o controle de tempo fica a cargo de cada site componente do grid.
• Possui três interfaces para acesso remoto a dados:
– GASS Global Access to Secondary Storage — rotinas para leitura e escrita
remota de arquivos;
– RIO Remote I/O — implementação distribuída para a biblioteca MPI-IO;
– GEM Globus Executable Management — permite leitura e execução remota de arquivos através dos serviços GRAM e GASS.
• Utiliza o serviço GSI (Generic Security Service) para implementar políticas de
segurança e de autorização de acesso. O GSI é uma implementação de SSL (Secure Sockets Layers) que utiliza algoritmos RSA e chaves públicas e privadas,
juntamente com certificados X509. Esses certificados é que identificam o usuário dentro de todo o sistema e que permitem acesso aos recursos do mesmo, de
acordo com as políticas estabelecidas.
• Oferece recursos básicos para a implementação de mecanismos de recuperação
de falhas. Tanto o Nexus quanto o GHM (Globus Heartbeat Monitor) provêem
funcionalidades básicas de monitoramento de processos.
• Em relação ao gerenciamento de recursos e ao escalonamento, o Globus implementa o serviço GRAM (Globus Resource Allocation Manager). Esse serviço
permite a criação, monitoramento e terminação de processos locais e remotos.
Em cada site componente do grid, os processos são gerenciados de acordo com
as políticas locais de alocação de recursos e escalonamento; sendo que essas
políticas podem ser implementadas por outras ferramentas, tais como LSF, Codine ou Condor. Além dessas funcionalidades, o GRAM é também responsável
por i) interpretar especificações RSL (Resource Specification Language), mecanismo pelo qual os processos são especificados e criados, ii) gerenciamento
e monitoramento remoto de processos e iii) atualização do MDS com informações de estado dos recursos.
Atualmente, o Globus está diponível para os sistemas Unix e Linux, e vem sendo
portado para o Windows NT. O framework pode ser utilizado com as linguagens Java, Perl
e C++, bem como as bibliotecas MPI e Simple RPC. Existem trabalhos em andamento
para a integração de recursos de outros ambientes, tais como NetSolve e Legion.
2.1.2 Legion
Legion (GRIMSHAW et al., 1999) é um projeto desenvolvido na Universidade de
Virginia cujo objetivo é prover uma infraestrutura de software que permita aos usuários
acessar, de forma transparente, recursos geograficamente distribuídos e possivelmente
heterogêneos.
A filosofia do Legion baseia-se na orientação a objetos como a maneira para prover
transparência. Todo e qualquer serviço ou funcionalidade provida pelo Legion é vista pelo
11
programador como um objeto. Um objeto é um processo ativo que responde à invocações
de métodos realizadas por outros objetos; entretanto, o Legion somente define a interface
de comunicação entre objetos (através de uma IDL) e não especifica nenhuma linguagem
de programação ou protocolo de comunicação.
Estruturalmente, o Legion está organizado em classes que realizam tarefas de gerenciamento e cálculo, e metaclasses, que correspondem a classes de classes. Adicionalmente, existe um conjunto de objetos com funções distintas dentro do sistema:
• objetos hospedeiros: são abstrações de recursos e podem representar desde um
simples processador até múltiplos processadores, bem como outros elementos
de software.
• objetos persistentes: correspondem a objetos que armazenam informações sobre
estados de execução dos objetos do sistema, para fins de persistência.
• objetos de implementação e cache: os primeiros são semelhantes a arquivos
executáveis Unix e correspondem a serviços providos dentro do sistema; os
segundos correspondem a objetos cujos dados são freqüentemente acessados,
simulando uma cache de dados.
• objetos de contexto e de associação: os objetos de contexto mapeiam nomes
de contexto para identificadores de objetos usados pelo Legion, permitindo que
o programador possa nomear seus objetos com um string de tamanho arbitrário. Já os objetos de associação são responsáveis por mapear identificadores de
objetos para endereços físicos.
Por estar calcado na orientação a objetos como metodologia de desenvolvimento,
o Legion provê uma série de vantagens, tais como abstração de dados, polimorfismo e
herança; o que são características bastante desejáveis em aplicações complexas. Entretanto, esse paradigma não é totalmente adequado quando o Legion precisa interagir com
sistemas legados, podendo causar alguns problemas. Outro ponto a considerar é o fato
do Legion estar implementado com a linguagem MPL (Mentat Programming Language),
uma linguagem C++ paralela que precisa ser adaptada para cada plataforma antes da instalação do Legion.
Algumas das principais características do Legion são:
• Não existe uma hierarquia definida entre os objetos; todos são iguais e capazes
de comunicarem entre si através de uma camada de comunicação baseada em
sockets Unix denominada MMPS (Modular Message Passing System).
• Implementa um esquema de nomeação em três camadas: o usuário refere-se aos
objetos através de nomes comuns (strings), denominados “nomes de contexto”,
que são mapeados para LOIDs (Legion object identifiers) — independentes de
localização e com chaves RSA. Por último, cada LOID é mapeado para um
ou mais LOAs (Legion object address) para fins de comunicação. Um para
LOID/LOA é chamado de “associação” na terminologia do Legion, sendo que
as associações ficam armazenadas nos objetos de associação.
• Similarmente ao Globus, o Legion não provê multiprogramação nem um serviço
de tempo específico. A entidade computacional do Legion é o processo, sendo
alocado um processo por objeto componente da aplicação.
12
• Possui um gerenciador de contextos implementado através de uma interface
gráfica Java e que permite a manipulação de objetos, arquivos e contextos na
forma de ícones. Os comandos básicos para a manipulação desses ícones são:
move, alias, get interface, get attributes, destroy, activate e deactivate.
• O compartilhamento de arquivos é suportado através de um sistema de arquivos
virtual, implementado com uma bilioteca de rotinas para leitura e escrita remota
com semântica semelhante a do Unix.
• As questões de segurança e autorização são tratadas de forma simples, uma vez
que o modelo de segurança do Legion é voltado para a proteção dos objetos e da
comunicação entre eles. Cada usuário, ao definir um objeto, define também seus
direitos e métodos que podem ser invocados. A cada objeto é adicionado um
método chamado MayI, que é responsável por receber as invocações e verificar
os direitos de acesso e a identidade do objeto chamador antes de invocar o método desejado. Essa verificação é baseada em um par de chaves — uma pública
e outra privada —, onde a primeira faz parte do nome do objeto e é usada para
criptografar toda a comunicação com esse objeto, e a segunda é usada como
assinatura de qualquer mensagem enviada por um determinado objeto.
• Provê apenas primitivas para replicação de objetos e checkpointing de comunicação entre eles. Se uma aplicação necessitar de um alto nível de tolerância a
falhas, o programador deve especificar classes que implementem essa funcionalidade.
• O gerenciamento de recursos é feito através dos objetos hospedeiros, que representam processadores. Esses objetos podem criar e gerenciar objetos Legion,
através de comandos para criação, terminação e controle. As classes invocam
métodos dos objetos hospedeiros para a instanciação de objetos nos nós que
esses hospedeiros representam.
• O escalonamento é implementado através de três componentes:
– collection: responsável pela coleta de informações de estado do sistema.
– scheduler: interage com o collection para determinar um conjunto de recursos que supra as necessidades de escalonamento.
– enactor: responsável pela alocação de recursos, baseada em uma lista de
escalonamentos desejados pelo scheduler.
Além da linguagem MPL, o Legion também suporta a linguagem BFS (Basic Fortran Support), que corresponde a um conjunto de pseudo-comandos para Fortran e um
pré-processador que habilita o acesso aos objetos do Legion através desses comandos.
Adicionalmente, as bibliotecas PVM, MPI e HPF são suportadas, bem como a linguagem
Java.
De forma semelhante ao Globus, o Legion implementa interfaces gráficas e orientadas a caracteres para o desenvolvimento de aplicações. O gerenciador de contextos
pode ser executado em qualquer plataforma que disponha de JDK 1.1.3, bem como existe
uma implementação disponível para Windows 95 denominada Legion Server.
O Legion está atualmente disponivel para os sistemas Linux (x86/Alpha), Solaris
(SPARC), AIX (RS/6000), IRIX (SGI), DEC UNIX (Alpha) e Cray T90.
13
2.1.3 WebFlow
WebFlow (2003) é um framework que estende o modelo da Web com recursos
para computação distribuída e computação baseada em grids. O principal objetivo do
WebFlow é permitir o desenvolvimento e o reuso de módulos computacionais, onde o
usuário final pode, através de um navegador Web, utilizar módulos Webflow como componentes visuais e editores de texto como ferramentas de autoria para suas aplicações
distribuídas.
O WebFlow está organizado em uma arquitetura Java de três camadas que pode
ser considerada como um sistema dataflow visual. A primeira camada corresponde a
um conjunto de applets para permitir tarefas de autoria e controle do ambiente. Esses
applets interagem com uma camada de controle, baseada em servlets, que por sua vez
interagem com sistemas legados ou simuladores de alto desempenho. A última camada é
implementada com recursos providos pelo ambiente Globus, onde:
• o Metacomputing Directory Service — MDS é usado para mapear e identificar
recursos;
• o Globus Resource Allocation Manager — GRAM é usado para o controle de
alocaçäo de recursos;
• o Global Access to Secondary Storage — GRASS é usado para permitir a transferência rápida de dados.
A filosofia do WebFlow é bastante semelhante à filosofia da própria Web. Os
desenvolvedores de aplicações podem disponibilizar módulos computacionais em servidores Web, que são semelhantes a páginas Web. Cada link dentro do módulo pode ser
comparado a um canal de transferência de dados (comunicação) entre módulos. Dessa
forma, as saídas de um módulo podem ser conectadas nas entradas de outro módulo, formando uma espécie de grafo de computação distribuída (compute-webs na terminologia
do WebFlow).
Os usuário ativam os módulos computacionais simplesmente clicando nos links
dentro de cada página disponível nos servidores Web. Novas aplicações podem ser criadas
através do reuso de componentes prontos ou simplesmente clicando-se nos ícones que
representam módulos, arrastando-os para a área de edição e especificando-se as linhas de
conexão entre cada módulo (fluxo de execução e troca de informações).
O protótipo do WebFlow executa com um conjunto de servidores Web capazes de
interpretar Java (Apache), que executam servlets encarregados do gerenciamento de recursos distribuídos. Existem três servlets principais: session manager, module manager e
connection manager. Esses servlets usam endereços URL e podem fornecer informações
sobre seus serviços e estado de execução.
Diferentemente do Legion e do Globus, o WebFlow é implementado de uma forma
híbrida, através de uma arquitetura em três camadas que concilia a Web com serviços especializados providos por terceiros (como é o caso da utilização do Globus como última
camada). Essa abordagem traz muitas vantagens, uma vez que é possível a adição de
outras funcionalidades de maneira totalmente transparente ao usuário. Além disso, é extremamente portável, requerendo apenas um servidor Web capaz de interpretar servlets
Java.
Algumas características do WebFlow compreendem:
14
• Não existe uma hierarquia definida, uma vez que um nó WebFlow é um servidor
Web com um único endereço URL e capaz de comunicar-se com qualquer outro
nó.
• O modelo de comunicação é ponto-a-ponto e dirigido a dados. O WebFlow
provê diferentes protocolos para fins de comunicação: a comunicação entre
applets e o servidor Web é feita via protocolo HTTP, entre servidores é feita
através de TCP/IP e os módulos da aplicação podem trocar dados (objetos Java
serializados) através de portas de entrada e saída, regidos por um política de
eventos. Além desses protocolos de comunicação, estão também disponíveis diferentes protocolos para troca de arquivos (HTTP, FTP, IIOP e Globus GASS).
• Cada módulo executa como uma thread Java independente, e o usuário é responsável pela sincronização entre cada módulo. Similarmente ao Legion e ao
Globus, nenhum serviço de tempo é especificado, sendo utilizados os serviços
disponíveis em cada nó componente do ambiente.
• O compartilhamento e o acesso remoto a arquivos é realizado através de um
“navegador de arquivos”, onde o usuário pode selecionar um conjunto de arquivos e enviá-lo para outro local através de HTTP, IIOP, FTP ou GRAM.
• O esquema de segurança está estruturado em duas camadas: as transações entre
os clientes e a camada intermediária, via navegador Web, são autenticadas pelo
protocolo TLS 1.0; e o acesso aos recursos da camada inferior é autenticado
pelos próprios fornecedores desses recursos, tais como o Globus.
• Na implementação atual do WebFlow, aspectos de tolerância a falhas e monitoramento do sistema não estão disponíveis. A próxima versão irá prover essas
funcionalidades, baseadas em serviços definidos no padrão CORBA.
• O gerenciamento de recursos e o escalonamento são feitos através do GMT
(Globus Metacomputing Toolkit) ou de pacotes específicos, tais como PBS e
Condor.
Todos os módulos do WebFlow são objetos Java, capazes de encapsular código de
outras linguagens de programação, tais como C, Fortran, HPF e Pascal. Dessa maneira,
qualquer plataforma que suporte a execução de uma máquina virtual Java é capaz de
executar aplicações WebFlow.
Em termos de interface gráfica, existe uma ferramenta de desenvolvimento que
permite ao programador a criação de uma (meta)aplicação através da combinação de módulos pré-definidos. Também é possível ao programador o desenvolvimento de interfaces
customizadas, através de uma API específica para tal.
2.1.4 NetSolve
NetSolve (CASANOVA; DONGARRA, 1995) é um framework que emprega o
paradigma Cliente/Servidor para permitir a solução de problemas computacionais de uma
maneira distribuída. O sistema é baseada na conexão de diferentes recursos computacionais através de uma rede local ou a própria Internet.
As aplicações podem ser escritas nas linguagens C ou Fortran e os usuários podem, ainda, utilizar o MatLab ou um navegador Web para interagir com serviços remotos.
15
Adicionalmente, o NetSolve permite que o usuário procure por um determinado serviço
dentro do sistema, escolha qual o melhor, submeta o problema a ser resolvido (com possibilidade de recuperação em caso de falhas) e receba a resposta. A implementação do
NetSolve permite que vários pacotes numéricos, tais como FitPack, ScaLAPACK, BLAS
e QMR, sejam utilizados para a resolução de problemas.
Estruturalmente, o NetSolve está organizado em:
• Um conjunto de interfaces de programação (APIs) definidas em diferentes bibliotecas numéricas e que podem ser acessadas remotamente através de programas
escritos em C, Fortran, MATLAB e Java.
• Um conjunto de servidores que encapsulam essas rotinas numéricas, e
• Um ou mais agentes responsáveis pela associação de requisições de serviços
aos servidores que provêem esses serviços.
Uma requisição de serviço é submetida a um agente, como resultado de uma chamada à interface de programação do cliente. O agente, então, determina o servidor mais
adequado para a execução desse serviço e o mesmo, após executar o serviço, repassa ao
cliente o resultado esperado. Um servidor pode estar executando em diferentes tipos de
plataforma, tais como simples estações, uma rede de estações ou uma arquitetura paralela
dedicada (MPP).
O NetSolve provê um “linguagem de aplicação” — conjunto de comandos através
do qual é possível invocar funções numéricas escritas em linguagem de alto nível (por
exemplo, MATLAB) ou em linguagens de baixo nível (por exemplo, C e Java). Por
exemplo, a porção de código em MATLAB para multiplicação de matrizes é c = a ∗ b,
sendo a porção equivalente em NetSolve definida como c = netsolve(‘matmul 0 , a, b),
onde matmul é o nome do serviço implementado em algum servidor do ambiente.
A utilização de agentes para a realização de escalonamento das chamadas de serviços remotos é fundamentada na idéia de que um agente específico para cada nó componente do sistema pode prover melhor desempenho e confiabilidade na execução de
aplicações. Um agente NetSolve tem duas funções principais:
• Manter uma relação dos recursos computacionais disponíveis e suas características.
• Fazer a associação de uma requisição de serviço, disparada por um cliente, para
o servidor mais adequado para executá-la, considerando informações estáticas
e dinâmicas de cada recurso, bem como informações sobre o problema a ser
resolvido.
A escolha do servidor “mais adequado” para a execução de um serviço é baseada
em um mecanismo de balanceamento de carga que considera diferentes tipos de parâmetros para o seu modelo de custo:
• parâmetros dependentes do cliente: tamanho dos dados a serem enviados, tamanho do resultado esperado e tamanho do problema.
• parâmetros estáticos dependentes do servidor: características de rede entre o
servidor e o cliente, complexidade do algoritmo executado no servidor e o desempenho teórico (raw performance) do servidor.
16
• parâmetros dinâmicos dependentes do servidor: corresponde a carga de trabalho em um determinado momento, calculada através de um modelo de custo
específico (CASANOVA; DONGARRA, 1995).
Com esses parâmetros, o NetSolve pode calcular o tempo (T ) estimado para que
um determinado servidor execute um serviço, sendo que o menor tempo corresponde ao
servidor mais adequado. Adicionalmente, o NetSolve executa estimativas de desempenho
para cada candidato a melhor servidor.
Os servidores NetSolve, que representam recursos computacionais, foram desenvolvidos com três objetivos principais: i) prover acesso uniforme a todo o software disponível, como se o usuário estivesse utilizando um único pacote de funções; ii) prover boa
escalabilidade, permitindo que o ambiente possa incorporar diferentes bibliotecas de funções; e iii) prover independência de plataforma e garantir que todo o software necessário
ao desenvolvimento de aplicações esteja instalado e configurado em cada nó participante
do ambiente.
Esses objetivos são alcançados através da utilização de uma linguagem de descrição de funções, que permite ao programador especificar arquivos com funções que
devem ser providas por servidores. Essas funções são então traduzidas para módulos
do NetSolve, acessíveis a partir de aplicações escritas em C, Java, Fortran e MATLAB,
conforme já descrito. Além disso, esses arquivos descritivos podem ser trocados entre diferentes grupos de pesquisadores, colaborando para a extensão das funcionalidades
providas pelo NetSolve.
Outra funcionalidade provida pelo ambiente é a tolerância a falhas em servidores
e agentes, através de um mecanismo chamado retry. Cada agente é responsável por manter informações sobre quais servidores estão operacionais em um determinado momento.
Além disso, podem ser utilizados múltiplos agentes em cada nó do sistema, para casos de
falhas em agentes. Se uma falha é detectada, uma requisição de serviços pode ser retransmitida a outro servidor capaz de executá-la. Para prover tal funcionalidade, o NetSolve
emprega rotinas providas por outros ambientes, tais como o Globus e o Condor.
2.1.5 Síntese e Análise Comparativa
Esta seção apresenta uma análise comparativa dos ambientes apresentados nas seções anteriores. Essa análise baseia-se na observação das funcionalidades providas por
cada ambiente, e nos mecanismos e técnicas usadas para implementar essas funcionalidades. Uma análise mais detalhada pode ser obtida em (FOSTER; KESSELMAN, 1999).
O primeiro ponto a observar, quando da comparação entre diferentes ambientes,
é o estabelecimento de uma relação entre a terminologia empregada em cada um. Esse
ponto não é trivialmente realizável, levando ao agrupamento por funcionalidades.
Considerando a Tabela 2.1, é possível observar que todos os ambientes, exceto o
NetSolve, não empregam nenhuma hierarquia organizacional, o que favorece a escalabilidade e diminiu os pontos suscetíveis a falhas. A escalabilidade no NetSolve é defendida
através da facilidade de adição de novas funções, através de uma linguagem específica
para essa finalidade; e a tolerância a falhas é garantida através de mecanismos de checkpoiting e serviços Globus e Condor.
É importante salientar que, dentre os quatro ambientes apresentados, o NetSolve
é o ambiente mais recente e com menos funcionalidades disponíveis. Quando da implementação de suas versões iniciais, nenhum mecanismo padrão para gerenciamento de
recursos, comunicação e serviço de diretório estava definido; o que fez com que a equipe
17
Tabela 2.1: Síntese das funcionalidades dos ambientes de Grid Computing.
Funcionalidade
Hierarquia
Comunicação
Diretório e
Registro
Concorrência
Globus
Par
Nexus
MDS — LDAP
Serv. de Tempo
Nomeação
Não definido
LDAP + DNS
Sistema de
Arquivos
Segurança
GASS + ROMIO
Tolerância a
Falhas
Gerenciamento
de Recursos
Programação
Interfaces de
Usuário
Disponibilidade
Processos
GSI (RSA +
X.509 cert.)
Monitor
heartbeat
GRAM + RSL
Legion
WebFlow
Par
Par
MMPS
Sockets + MPI
Agente de
MDS — LDAP
associação
Processos e
Processos
objetos
Não definido
Não definido
Gerenciador de
LDAP + DNS
contexto + DNS
LegionFS
GASS
Baseado em
objetos + RSA
Não implem.
NetSolve
Cliente/Servidor
Sockets e XDR
Não
implementado
Servidores
monoprocessados
Não definido
Agentes
Não definido
SSL
Não definido
Nenhum
Retry
+ Globus e Condor
Agentes +
scripts
C, Fortran, Java e
MATLAB
Interativas
e shell
Diversos
paradigmas
GUI + texto
Objeto
host
MPL, BFS +
wrappers
GUI + texto
GRAM
Applets
UNIX
UNIX
UNIX, NT
MPI
de desenvolvimento estabelecesse soluções proprietárias ou adotasse protocolos já difundidos (caso do TCP/IP e XDR) para a implementação de algumas funcionalidades.
O Globus é construído de forma modular, onde serviços de alto nível são desenvolvidos sobre serviços de baixo nível. O GMT é organizado como um conjunto de serviços
distintos, cada qual com uma API bem definida, permitindo ao programador escolher
quais dos serviços serão usados para as suas aplicações. Adicionalmente, essas interfaces
podem ser adaptadas para utilizarem outros ambientes, tais como Condor ou NQE para
o gerenciamento de recursos. A principal vantagem do Globus, além da quantidade de
serviços disponíveis, é o fato de os mesmos estarem abstraídos em interfaces bem definidas, permitindo uma fácil portabilidade, reescrita das funcionalidades sem alterar as
aplicações e a inclusão de novas funcionalidades.
O Legion adota uma filosofia diferente em relação ao Globus, pois encapsula todas
as funcionalidades em objetos, o que lhe dá todas as vantagens advindas com o paradigma
de orientação a objetos. De uma maneira geral, essa filosofia é bastante adequada para a
construção de ambientes de programação para grids, pois consegue mapear e, ao mesmo
tempo, abstrair detalhes de implementação da maioria das aplicações para esse tipo de
plataforma. Entretanto, dependendo da funcionalidade a ser provida, é necessário converter as interfaces procedurais (como é o caso do DNS, por exemplo) para interfaces
orientadas a objetos, o que é ralizado através de objetos wrappers.
Em relação ao WebFlow, sua principal vantagem está na organização em múltiplas
camadas, onde a camada mais básica geralmente é composta por serviços de terceiros, tais
como o Globus e (ainda em desenvolvimento) o CORBA. Esta organização provê grande
portabilidade as aplicações escritas em WebFlow, pois as mesmas podem executar em
qualquer máquina capaz de executar um servidor Web.
Os ambientes apresentados nesse capítulo são apenas alguns exemplos dos muitos esforços despendidos pela comunidade científica mundial para o desenvolvimento de
18
ambientes de programação e gerenciamento de arquiteturas de grids. Atualmente, existem várias dezenas de projetos em andamento ao redor do mundo, bem como existem
foruns e grupos de trabalhos preocupados em estabelecer padrões de serviços que devem
ser providos em um ambientes desse tipo.
19
3 A BIBLIOTECA DE PROGRAMAÇÃO DECK
DECK (Distributed Execution and Communication Kernel) é um modelo para um
ambiente de programação cujo objetivo é prover recursos que permitam o desenvolvimento de aplicações paralelas irregulares, através da combinação de multiprogramação e
comunicação (BARRETO; NAVAUX; RIVIÈRE, 1998; BARRETO, 2000).
A filosofia seguida pelo DECK é semelhante à filosofia seguida por outros ambientes de programação, em relação à integração de comunicação com multiprogramação
e à obtenção de alto desempenho; entretanto, o DECK difere desses ambientes em três
aspectos: a estrutura modular adotada, os serviços oferecidos e o suporte para diferentes
arquiteturas de clusters.
3.1 Modelo de programação
O modelo original destina-se ao suporte de aplicações irregulares, oferecendo recursos de troca de mensagens e memória distribuída para permitir a interação entre diferentes tarefas dentro da aplicação. Nesse modelo, cada thread em execução pode criar
novos threads, local ou remotamente. A comunicação é feita por memória compartilhada,
para threads locais e por primitivas de comunicação ponto a ponto, para threads em diferentes nós. Nesse último caso, são utilizadas mail boxes, que são estruturas de comunicação para o envio e recebimento de mensagens. Cada mail box é local a um determinado
processo ou thread e possui um identificador único no sistema (nome), gerenciado por
um servidor de nomes e que permite que um nó remoto possa obter uma referência a essa
mailbox para fins de comunicação.
Contextos de comunicação podem ser utilizados com o objetivo de permitir o gerenciamento individual dos nós do cluster, de maneira a facilitar tarefas relativas à multiplexação de redes e tolerância a falhas. Além dessas funcionalidades, o modelo original
prevê mecanismos para a criação dinâmica de processos, com o intuito de melhor suportar
aplicações irregulares. A Figura 3.1 ilustra as principais interações previstas no modelo
original.
Um conjunto de serviços mais elaborados é proposto pelo sistema, tais como balanceamento de carga, tolerância a falhas, visualização e depuração, usados de acordo
com a necessidade de cada aplicação.
3.2 Estrutura do modelo
A Figura 3.2 ilustra a estrutura geral do ambiente DECK, organizado internamente
em dois níveis: uma camada inferior, denominada µDECK, que corresponde à parte de-
20
Processo 0
Processo 1
memória compartilhada
memória compartilhada
acesso à
memória remota
thread
Nodo 0
Rede
Nodo 1
criação
remota
de thread
thread principal
mailbox
criação remota
de processo
dado
memória compartilhada
memória compartilhada
Processo 2
Processo 3
Figura 3.1: Interações no ambiente DECK
Serviços
nomes
mensagem
comunicação
em grupo
tolerância
a falhas
balanceamento
de carga
multiplexação
de redes
uDECK
comunicação
multiprogramação
sincronização
abstração de
interface de rede
Figura 3.2: Estrutura do modelo conceitual do DECK.
pendente de plataforma (sistema operacional e hardware utilizados) e é responsável pelo
fornecimento de mecanismos de comunicação e multiprogramação. A camada superior,
denominada camada de serviços, é a parte independente de plataforma, sendo responsável pela implementação de serviços mais elaborados (BARRETO et al., 2000).
A camada inferior interage diretamente com o sistema operacional e protocolos
de comunicação com o objetivo de explorar eficientemente os recursos da arquitetura e
prover alto desempenho. Nesta camada são definidas abstrações relativas à:
• multiprogramação, através de um módulo que fornece primitivas associadas à
criação e destruição de threads, colocação em estado de espera e liberação do
processador, o que faz com que o thread seja desescalonado.
• sincronização, através de um módulo que fornece primitivas relacionadas ao
controle de acesso a dados globais (conflitos de acesso para escrita e leitura, por
exemplo), bloqueando e desbloqueando threads.
21
• comunicação, através de um módulo que fornece primitivas associadas à manipulação de mailboxes, para permitir o envio e recebimento de mensagens; e
primitivas relacionadas com a criação e manutenção de um espaço de endereçamento global, para permitir a interação entre processos e/ou threads remotos
por meio de leitura e escrita em dados compartilhados. Adicionalmente, são
previstas primitivas para o cadastramento e consulta de mailboxes e áreas de
memória compartilhada no servidor de nomes.
• abstração de interfaces de rede, através de um módulo encarregado de prover
mecanismos de endereçamento e controle de mensagens (polling) para cada interface de rede disponível em um determinado nó do cluster e que seja suportada
pelo ambiente.
A camada superior do ambiente corresponde aos serviços oferecidos, classificados
em duas categorias: serviços globais, que são utilizados por qualquer aplicação DECK
e correspondem ao serviço de nomes, ao serviço de mensagens e ao suporte à múltiplas
interfaces de rede; e serviços locais, que são utilizados de acordo com as necessidades
particulares de uma determinada aplicação e correspondem a serviços mais elaborados,
tais como comunicação em grupo, tolerância a falhas e balanceamento de carga.
O servidor de nomes é um elemento único no sistema cuja função é o cadastramento de mailboxes e de áreas de memória global, permitindo a associação de nomes
lógicos a esses recursos. Uma vez associado a um nome, um mailbox pode ser obtido por
um processo mediante a apresentação desse nome. No caso de memória compartilhada
distribuída, um nome pode ser utilizado para realizar operações de leitura e escrita em
dados dentro de uma área de memória compartilhada.
O serviço de mensagens fornece uma área de armazenamento (mensagem) utilizada para o empacotamento e desempacotamento de dados. Este serviço fornece primitivas para realizar a conversão na representação de dados, no caso de arquiteturas heterogêneas, bem como primitivas que permitem a re-utilização de uma mensagem em diferentes
operações de comunicação.
O serviço de multiplexação de redes é responsável pelo suporte a diferentes interfaces de rede que possam co-existir nos nós de um cluster. A idéia básica por trás desse
serviço é permitir uma melhor utilização das redes de comunicação, dividindo o tráfego
entre elas. Dessa forma, é possível direcionar mensagens de controle do ambiente para
a rede mais lenta, deixando a rede mais rápida dedicada somente à aplicação do usuário.
Além disso, é responsabilidade desse serviço abstrair do usuário a interface de rede e o
esquema de endereçamento utilizados, de maneira a prover portabilidade para qualquer
aplicação.
O serviço de comunicação em grupo permite que um conjunto de mailboxes
possa ser tratado coletivamente como uma única abstração, de maneira a prover facilidades para a difusão confiável de mensagens entre os processos e/ou threads que mantêm
esses mailboxes. Esse serviço define primitivas para a criação e destruição de grupos,
inclusão e remoção de elementos, bem como envio de mensagens e sincronização. Esse
serviço é especialmente útil em aplicações de cálculo paralelo (multiplicação de matrizes
por vetores, por exemplo) que necessitam transmitir um conjunto de dados a diferentes
threads em execução dentro de um tempo hábil, o que seria inviável através de primitivas
ponto-a-ponto.
O serviço de balanceamento de carga é responsável por duas tarefas básicas:
prover técnicas de escalonamento eficientes para tirar proveito de arquiteturas multipro-
22
cessadas e oferecer mecanismos que permitam uma distribuição uniforme da carga de
trabalho entre os nós do cluster.
O serviço de tolerância a falhas tem como objetivo prover recursos que assegurem a correta execução das aplicações sobre o cluster, mesmo na presença de falhas.
Para tanto, são previstos protocolos para o estabelecimento de pontos de recuperação
(checkpoints) distribuídos orientados aos threads da aplicação. Esta facilidade não é atualmente oferecida pelos ambientes tradicionalmente utilizados para programação paralela
e distribuída; mas é altamente desejável em aplicações paralelas que possuem um tempo
razoavelmente alto de execução.
Esta divisão em camadas provê grande portabilidade ao ambiente, uma vez que
somente a camada básica precisa ser adaptada para a utilização do DECK em diferentes
plataformas. É importante salientar ainda que a camada básica pode ser utilizada diretamente pela aplicação; os serviços da camada superior são inseridos na aplicação somente
se necessários. Além disso, a organização em módulos facilita a alteração de um determinado recurso sem a necessidade de modificações em outros módulos.
As seções a seguir apresentam as versões atualmente disponíveis do ambiente
DECK. Em relação aos módulos de multiprogramação e sincronização, ambas as versões utilizam o pacote PTHreads como implementação básica. Nesse sentido, o principal
ponto que distingue uma implementação de outra diz respeito ao módulo de comunicação, que utiliza diferentes protocolos, dependendo da rede de comunicação disponível no
cluster.
3.2.1 DECK em redes Ethernet
A primeira implementação do ambiente DECK foi realizada sobre a rede Fast
Ethernet, utilizando o protocolo TCP/IP (sockets Unix) para realizar a comunicação.
O objetivo dessa versão foi o de validar a estrutura modular do ambiente e definir uma interface básica de programação para permitir o desenvolvimento da camada de
serviços. Para tanto, foram desenvolvidos os módulos de comunicação, sincronização,
multiprogramação e o serviço de nomes.
Os resultados obtidos com essa implementação foram bastante satisfatórios, considerando-se que o protocolo TCP/IP não é adequado para programação paralela. Dessa
forma, tentou-se minimizar a sobrecarga introduzida por mensagens de confirmação do
TCP adotando-se sockets do tipo datagrama para a comunicação.
Os resultados obtidos para latência (a) e largura de banda (b) sobre a rede Fast
Ethernet são ilustrados na Figura 3.3. A latência de comunicação do PVM e das implementações de MPI para mensagens grandes (acima de 2 KB) é bastante próxima à
latência apresentada pelo DECK. Para mensagens de tamanho menor (até 1 KB aproximadamente), esses ambientes apresentam sobrecargas bastante significativas, com uma
pequena vantagem para o LAM. Para mensagens de 1 byte, DECK apresentou uma latência de 162 µs, contra 199 µs do LAM, 267 µs do MPICH e 289 µs do PVM, o que
representa um ganho de 18 %, 39 % e 44 %, respectivamente.
A largura de banda apresentada é um reflexo direto da latência: para mensagens
pequenas, DECK apresenta um ganho de 13 %, 21 % e 27 % em relação ao LAM, MPICH
e PVM, respectivamente. Entretanto, para mensagens maiores (32 KB por exemplo), o
resultado é bastante próximo para todos os ambientes (cerca de 8 MB), com uma pequena
vantagem para o PVM, que atingiu 9 MB. Essa vantagem deve-se principalmente aos mecanismos empregados para o gerenciamento de buffers de comunicação e à fragmentação
de mensagens. Para mensagens a partir de 1 KB, DECK apresenta uma queda na taxa de
23
Latência − Fast Ethernet (nodos SMP)
Largura de banda − Fast Ethernet (nodos SMP)
1000
16M
8M
tempo (us)
largura de banda (bytes/s)
4M
100
2M
1M
512K
256K
128K
64K
32K
DECK
LAM 6.1
MPICH 1.1.2
PVM 3.4
DECK
LAM 6.1
MPICH 1.1.2
PVM 3.4
16K
8K
1
2
4
8
16
32
64 128 256 512
tamanho da mensagem (bytes)
(a)
1K
2K
4K
4
8
16
32
64 128 256 512 1K 2K
tamanho da mensagem (bytes)
4K
8K
16K 32K
(b)
Figura 3.3: Latência e largura de banda para a rede Fast Ethernet.
transmissão, o que é reflexo direto do aumento no tempo de latência para mensagens a
partir desse tamanho.
3.2.2 DECK em redes Myrinet
Para a implementação do DECK sobre a rede Myrinet (BARRETO et al., 2000) foi
utilizada a biblioteca BIP, devido principalmente ao desempenho e a API simples. O BIP
provê primitivas básicas de comunicação ponto-a-ponto (send() e recv() assíncronos) para
a rede Myrinet, com a restrição de que a troca de mensagens longas (large messages na
terminologia do BIP) deve seguir uma semântica síncrona (rendez-vous), o que significa
que uma primitiva recv() deve vir sempre antes da primitiva send() correspondente.
Para tal, o DECK emprega um protocolo de controle de fluxo (handshaking), onde
o emissor envia uma mensagem pequena de requisição antes de realizar a transmissão da
mensagem longa. Essa mensagem de requisição é tratada, no lado receptor, por um thread
específico, denominado rv-daemon, criado quando da inicialização da aplicação.
Na avaliação sobre a rede Myrinet, a implementação do DECK utiliza primitivas
de comunicação orientadas às filas de recebimento (tags) do protocolo BIP. Por questões
de comparação, foi utilizada a implementação MPICH-BIP (WESTRELIN, 1999) e o
protocolo BIP diretamente, com o intuito de quantificar a sobrecarga imposta pelos dois
primeiros ambientes sobre o protocolo BIP. Uma consideração importante sobre o DECK
é que o thread adicional para tratamento de mensagens longas pode causar um impacto
grande no desempenho das operações de comunicação
Os resultados obtidos para latência (a) e largura de banda (b) sobre a rede Myrinet
são ilustrados na Figura 3.4.
A latência apresentada pelo DECK é menor do que a latência apresentada pelo
MPICH, para mensagens com tamanho de até 1 KB. A partir desse tamanho, a influência
do protocolo de controle de fluxo afeta em maior escala o desempenho do DECK em
relação ao MPICH. Entretanto, para mensagens de 1 byte, DECK apresentou uma latência
de apenas 8.2 µs contra 12.8 µs do MPICH. Se comparada com a latência apresentada pelo
BIP, em torno de 7.3 µs, a diferença entre DECK e MPICH é de cerca de 35 %, o que
reflete um ganho razoável do DECK sobre o MPICH.
O resultado obtido para a largura de banda é reflexo, novamente neste caso, da
latência de comunicação imposta pelos ambientes. Para mensagens de até 1 KB, DECK
24
Latência − Myrinet
Largura de banda − Myrinet
120M
100M
100
tempo (us)
largura de banda (bytes/s)
80M
40M
20M
10
BIP 0.99e
DECK−BIP
MPICH−BIP
1
2
4
8
16
32
64
128 256
tamanho da mensagem (bytes)
(a)
512
10M
1K
2K
256
BIP 0.99e
DECK−BIP
MPICH−BIP
512
1K
2K
4K
8K 16K 32K 64K 128K 256K 512K 1024K
tamanho da mensagem (bytes)
(b)
Figura 3.4: Latência e largura de banda para a rede Myrinet.
apresentou uma largura de banda de aproximadamente 13 MB, enquanto que o MPICH
apresentou um resultado de 11 MB. Isso representa um ganho de cerca de 10 % para esse
tamanho de mensagem. A partir desse tamanho, a largura de banda obtida pelo DECK diminui bastante, ficando razoavelmente longe dos valores obtidos pelo MPICH e o próprio
BIP, respectivamente 80 MB, 100 MB e 107 MB para mensagens com tamanho de 1 MB.
Embora a latência de comunicação do DECK não apresente a mesma porcentagem de variação, a largura de banda é influenciada pela implementação não-otimizada do protocolo
de controle de fluxo.
É importante salientar que, para a obtenção dos resultados sobre o protocolo BIP,
foram tomadas duas medições: a primeira medição não implementa nenhum tipo de controle de envio e recebimento de mensagens grandes, o que causa, em algumas execuções,
erros de controle de fluxo no protocolo, fazendo com que o mesmo falhe. A segunda
versão utiliza uma primitiva usleep() para forçar um pequeno atraso (delay) no processo
emissor, a fim de que o receptor possa disponibilizar um buffer de recebimento. Em função desse cenário, os gráficos para o protocolo BIP apresentados na Figura 3.4 consideram
para a latência os resultados da primeira versão e para largura de banda os resultados da
segunda versão.
Essas restrições impostas pelo protocolo BIP obrigam ambientes de programação
de mais alto nível a implementar algum tipo de protocolo para tratamento de mensagens grandes, tais como os protocolos oferecidos pelo MPICH e o DECK. Os resultados
apresentados na Figura 3.4 evidenciam que a implementação de tal protocolo no DECK
precisa ser revista e otimizada, para permitir uma largura de banda mais próxima à apresentada pelo MPICH e o próprio BIP. Atualmente, o grupo trabalha também em uma
implementação do DECK sobre o protocolo GM (1999).
3.2.3 DECK em redes SCI
A implementação do DECK para a rede SCI (OLIVEIRA, 2001; OLIVEIRA
et al., 2001) utiliza a interface de programação SISCI — Software Infrastructure for
SCI. Essa API é uma especificação de primitivas padrão para a programação em redes
SCI, baseadas em memória compartilhada. Essa especificação foi proposta por um comitê composto por representantes industriais e acadêmicos. Uma implementação da API
SISCI está disponível no SSP (Scali Software Platform), um pacote de software distri-
25
90
80
bandwidth (bytes/s)
70
60
50
40
30
20
10
256
DECK−SCI
ScaMPI
512
1K
2K
4K
8K 16K 32K 64K 128K 256K 512K 1M
message size (bytes)
Figura 3.5: Largura de banda do DECK e ScaMPI na rede SCI.
buído com o Scali Wulfkits (SCALI HOMEPAGE—SCALABLE LINUX SYSTEMS—
AFFORDABLE SUPERCOMPUTING, 2000).
Três protocolos de comunicação foram desenvolvidos para a implementação do
DECK sobre SCI, com o objetivo de garantir baixa latência e a mínima sobrecarga possível para troca de mensagens pequenas, bem como alta largura de banda para mensagens
maiores.
Um protocolo específico é encarregado da troca de mensagens pequenas, garantindo baixa latência através da combinação de comunicação e sinalização dentro do mesmo
pacote SCI; enquanto que a alta largura de banda é atingida graças a um protocolo de comunicação que dispensa cópias intermediárias de mensagens (zero-copy protocol).
A Figura 3.5 apresenta uma avaliação de desempenho do DECK/SCI e do ScaMPI,
a implementação MPI fornecida pela Scali (HUSE et al., 1999). O gráfico ilustra que o
desempenho do DECK/SCI é claramente melhor do que o do ScaMPI. É possível, com
o DECK/SCI, atingir uma latência mínima de 4.66 µs e uma largura de banda máxima
de cerca de 84 Mbytes/s. Esse resultados estão bem próximos dos resultados teóricos da
rede SCI.
Em contraste ao DECK/BIP, DECK/SCI é mais eficiente do que o MPI para qualquer tamanho de mensagem, devido principalmente ao fato de que nenhum thread adicional é empregado para o controle de fluxo.
26
4 O MODELO DE INTEGRAÇÃO: MULTICLUSTER
O objetivo do projeto MultiCluster, desenvolvido no Instituto de Informática da
UFRGS, é a definição de um modelo de integração de clusters independentes e heterogêneos em relação ao paradigma de comunicação, a fim de formar uma arquitetura integrada
que possa ser utilizada através de uma única interface de programação. Dentro desse modelo, o usuário é capaz de configurar a arquitetura de acordo com as necessidades de suas
aplicações e, posteriormente, decidir a melhor localização para as tarefas componentes da
aplicação, de acordo com aspectos de comunicação e desempenho.
No desenvolvimento deste Projeto de Pesquisa, foram definidas as características
primordiais do modelo, complementando um trabalho iniciado no final de 1999 (BARRETO; ÁVILA; NAVAUX, 2000). Essas características têm a função de nortear os passos atuais e futuros no projeto, permitindo um planejamento a médio e longo prazo de
atividades de pesquisa para os alunos de graduação e pós-graduação vinculados ao grupo.
O modelo MultiCluster pode ser abordado em dois níveis: aspectos relacionados
ao hardware e aspectos relacionados à organização do software.
4.1 Aspectos de hardware
O modelo de integração assume, inicialmente, a existência de duas arquiteturas de
clusters: a primeira arquitetura corresponde a um cluster onde os nós estão conectados
pela rede de comunicação Myrinet, e a segunda arquitetura corresponde a um cluster que
emprega a rede de comunicação SCI para a conexão dos nós. A escolha inicial dessas
duas tecnologias se deve ao fato de serem as duas mais utilizadas em clusters, depois da
Ethernet (BAKER, 2000). A Figura 4.1 ilustra detalhes estruturais dessas arquiteturas.
A rede Myrinet é normalmente utilizada em conjunto com switches específicos, pois a
topologia lógica é em barramento. Já no caso da SCI, o uso de switches é dispensado em
clusters de pequeno porte (até 8 nós) pois a topologia natural é em anel. Em todo caso,
switches e também placas com conexões adicionais estão disponíveis para a configuração
de clusters maiores (no caso das placas, para topologia torus).
Esses clusters correspondem a duas arquiteturas atualmente disponíveis no Instituto de Informática da UFRGS, sendo o primeiro (à esquerda na figura) um cluster composto por 4 nós Dual Pentium Pro de 200 MHz e o segundo composto por 4 nós Dual
Pentium III de 500 MHz. Esses dois clusters foram diretamente utilizados nos testes relativos à definição do modelo MultiCluster, por isso são aqui apresentados como exemplo.
Adicionalmente a esses dois, o Instituto também conta com um cluster de 16 nós Pentium III 1GHz conectados por redes Fast Ethernet e Myrinet, adquirido através de um
projeto FINEP, e outro cluster de 20 nós Pentium III 1GHz conectados por Fast Ethernet,
27
Myrinet cluster
Myrinet switch
SCI cluster
Fast Ethernet
or
Myrinet link
Figura 4.1: Interconexão entre clusters Myrinet e SCI.
adquirido no âmbito do convênio LabTeC UFRGS/Dell1 .
A escolha da rede usada para a conexão dos clusters depende basicamente das necessidades das aplicações. É possível utilizar a rede Fast Ethernet ao invés da Myrinet
para esse fim; entretanto, a escolha pela Myrinet deve-se a dois motivos: ela pode minimizar as perdas relacionadas com a comunicação entre os clusters, uma vez que provê
melhor taxa de transmissão e não é necessária a implementação de um terceiro protocolo
de comunicação, a ser utilizado na rede Fast Ethernet.
É neste contexto que aparece a primeira característica do modelo MultiCluster:
em cada cluster participante do sistema, é necessário que exista um nó que implemente as
funções relacionadas com a comunicação com outros clusters. Esse nó deve conter duas
ou mais interfaces de rede e age similarmente a um gateway de uma rede local, realizando
o roteamento da comunicação entre as máquinas que compõem cada cluster (nas seções
seguintes serão apresentadas algumas exigências em relação ao software que executa no
nó gateway).
Um aspecto importante do modelo MultiCluster é que o mesmo não considera
questões relacionadas a custo e escalabilidade. Diferentemente das plataformas de grids,
onde essas questões são extremamente pertinentes, o modelo MultiCluster aborda uma
situação prática onde uma universidade ou empresa dispõe de pelo menos dois clusters e
deseja utilizá-los conjuntamente para atividades de ensino, pesquisa ou desenvolvimento
comercial e industrial. Nesse cenário, questões relacionadas com transparência, eficiência
e confiabilidade são prioritárias.
4.2 Aspectos de software
Em termos de software, o modelo MultiCluster estabelece algumas premissas que
determinam como os clusters podem ser integrados e posteriormente utilizados. Essas
premissas constituem a base para o funcionamento do modelo, sendo descritas a seguir.
4.2.1 Nós lógicos e físicos
A primeira premissa diz respeito às diferentes visões da arquitetura integrada. Um
nó físico corresponde a uma máquina pertecente a um determinado cluster e somente
interessa para questões de organização física da arquitetura.
Um nó lógico corresponde a um recurso computacional do ponto de vista da apli1
http://www.inf.ufrgs.br/LabTeC
28
// máquina virtual
@virtual_machine:
verissimo, quintana, euclides, dionelio,
scliar, ostermann, meyer, luft
// sub-redes
@comm_contexts:
myrinet 0
sci 1
// nós lógicos
@logical_nodes:
node 0:0 machines verissimo
node 1:0 machines quintana
node 2:0 machines euclides
node 3:0 machines dionelio
node 4:1 machines scliar, luft
node 5:1 machines ostermann, meyer
// nós gateway
@gateways:
quintana, scliar
Figura 4.2: Arquivo descritor para uma aplicação MultiCluster.
cação, sendo que para clusters baseados em comunicação por troca de mensagens (caso
da Myrinet), cada nó lógico corresponde a um nó físico; e para clusters baseados em comunicação por memória distribuída (caso do SCI), cada nó lógico pode corresponder a
mais de um nó físico.
A determinação dos nós lógicos dentro da arquitetura fica a cargo do programador, através da especificação de um arquivo descritor. Nesse arquivo, exemplificado na
Figura 4.2, o usuário deve determinar quais as máquinas que compõem a arquitetura integrada, quais os contextos, ou sub-redes, de comunicação que serão utilizados e quais
máquinas (nós lógicos) pertencem a cada contexto.
Um contexto de comunicação corresponde ao conjunto de nós capazes de se
comunicar através de uma determinada rede. Assim, a distinção entre os nós lógicos
da rede Myrinet e da rede SCI é feita pelo identificador de cada nó e pelo contexto de
comunicação ao qual o nó pertence.
No exemplo da Figura 4.2, “node 1:0” significa o segundo nó da sub-rede 0 (que
é a Myrinet, no exemplo), enquanto que “node 4:1” significa o primeiro nó da sub-rede
1 (que é a rede SCI). É importante salientar que a numeração dos nós é seqüencial, independentemente da sub-rede à qual o mesmo pertence. No exemplo, existem 6 nós lógicos,
numerados de 0 a 5. Esse esquema de numeração, embora complexo, é totalmente processado pelo ambiente de maneira transparente ao programador: o usuário somente precisa
saber quantos nós lógicos existem na arquitetura e quais os seus respectivos identificadores e contextos.
4.2.2 Comunicação
As questões relativas a comunicação são tratadas de acordo com a visão que o
programador tem da arquitetura, ou seja, de acordo com a existência dos nós lógicos.
Dessa forma, existe a distinção entre a comunicação interna a um nó lógico e externa a
29
um nó lógico.
Dentro de um nó lógico, a comunicação é realizada através de memória compartilhada. Se o nó lógico corresponde a uma máquina pertencente ao cluster conectado pela
rede Myrinet, é possível estabelecer comunicação entre processos ou threads executando
nos diferentes processadores através de memória comum a todos esses processadores. Se
o nó lógico corresponde a um conjunto de máquinas pertencentes ao cluster conectado
pela rede SCI, é possível a criação de um espaço de endereçamento global através do
mapeamento de porções individuais de memória de cada nó; mantendo, assim, a comunicação através de memória compartilhada.
A comunicação entre nós lógicos distintos é obrigatoriamente realizada por primitivas de troca de mensagens, uma vez que esses nós lógicos podem pertencer a clusters
diferentes. Quando a comunicação dá-se entre nós lógicos dentro de um mesmo contexto de comunicação, é possível otimizar essa comunicação através da utilização de um
único protocolo de comunicação para a rede representada pelo contexto — por exemplo,
pode-se utilizar o protocolo BIP para a rede Myrinet.
Quando a comunicação envolve nós lógicos pertencentes a diferentes contextos,
então é preciso realizar o roteamento de mensagens através do nó que comporta-se como
gateway. Nesse caso, pode ser necessária a troca do protocolo de comunicação utilizado
pelo gateway, uma vez que ele pode receber mensagens pela rede Myrinet e precisar
mandá-las ao outro cluster através de uma rede Fast Ethernet, por exemplo.
Estudos têm sido realizados pelos pesquisadores do projeto em relação aos problemas relacionados com a integração de diferentes arquiteturas e aos aspectos de comunicação entre as mesmas. A princípio, a escolha pela rede Myrinet justifica-se, conforme
já mencionado, pela possibilidade de se diminuir as perdas com a comunicação entre
clusters e pela eliminação de um terceiro protocolo de comunicação dentro do modelo.
Entretanto, não se pode ignorar o fato de que a maioria dos clusters utilizados atualmente
possui uma rede padrão Ethernet para a conexão de seus nós (geralmente utilizada como
rede para aspectos administrativos); e que a mesma pode ser usada para a comunicação
entre clusters.
4.2.3 Heterogeneidade
Embora seja um problema menos freqüente, a heterogeneidade pode aparecer em
razão da flexibilidade do modelo no que diz respeito ao hardware empregado. É possível
pensar na integração de clusters com arquitetura Intel e SPARC ou ainda na integração de
um cluster com uma máquina paralela dedicada.
Nesses contextos, deve-se considerar a existência de diferentes formatos para representação de dados e o modelo de integração deve prover subsídios para que possa
pensar em uma maneira de solucionar essa questão.
Uma possível solução é acrescentar informações, no arquivo descritor do modelo,
em relação ao formato de dados ou à arquitetura empregada em cada nó lógico ou em
cada contexto de comunicação. Dessa forma, o ambiente que implementar o modelo poderá prover soluções do tipo XDR ou embutir em cada mensagem informações a respeito
da arquitetura do emissor das mensagens. Independentemente da solução adotada, é importante salientar que o máximo de transparência possível é esperada pelo usuário de tal
arquitetura.
30
4.3 Protocolo de comunicação entre clusters
A fim de prover suporte ao modelo MultiCluster, um protocolo de comunicação
entre clusters, denominado Remote Communication Daemon, é oferecido como uma extensão ao módulo de comunicação do DECK.
No modelo MultiCluster, como em cada cluster integrado deve existir um nó com
funcionalidade de “gateway”, o mesmo foi escolhido para servir de hospedeiro para a
execução do protocolo RCD. Esse RCD segue a mesma semântica do servidor de nomes:
possui uma caixa postal (mailbox) conhecida por todos os demais nós pertencentes ao
cluster.
O RCD atua sob demanda em duas situações específicas: quando um nome definido remotamente (isto é, em outro cluster) precisa ser encontrado, e quando uma mensagem precisa ser transmitida para caixas postais remotas. Quando uma pritimiva DECK
não consegue descobrir um nome consultando o servidor de nomes local, ela interage
com o RCD, a fim de que o mesmo repasse a consulta para outros RCDs que executam
nos demais clusters pertencentes à plataforma integrada. No segundo caso, quando uma
primitiva DECK precisa enviar uma mensagem para uma caixa postal remota, ela interage com o RCD para que o mesmo repasse a mensagem para o RCD do cluster onde
encontra-se a caixa postal destinatária da mensagem.
É importante salientar que a comunicação entre threads em diferentes nós lógicos,
bem como em diferentes clusters, é sempre realizada via troca de mensagens. Mesmo no
caso de clusters SCI, deve existir pelo menos uma caixa postal para permitir a comunicação com o RCD e, eventualmente, receber mensagens. O uso de um espaço de endereçamento global para o estabelecimento de comunicação entre clusters não está sendo
considerado até o momento — embora suportado pelo SCI.
4.3.1 Avaliação de um protótipo do RCD
A fim de permitir uma avaliação sobre o modelo proposto para o RCD, um protótipo foi implementado como um serviço da biblioteca DECK. Foram utilizadas duas
partições do cluster Myrinet citados anteriormente. Cada partição é composta de 2 nós,
onde um atua como gateway. O teste foi realizado dessa forma para permitir uma avaliação da comunicação inter-cluster através da Myrinet, visto que, atualmente, não existe
uma versão do DECK capaz de se comunicar por duas tecnologias diferentes ao mesmo
tempo. Como o objetivo é avaliar o desempenho do roteamento, o fato de os nós estarem
no mesmo contexto não afeta os resultados obtidos.
O protótipo implementado consiste de um serviço de simples roteamento das mensagens recebidas pelo RCD de um cluster para o RCD de outro cluster. Cada RCD declara
uma mail box local, a qual será usada para o recebimento das mensagens, e, ao mesmo
tempo, obtém referências para as mail boxes dos demais RCDs participantes. Assim,
o trajeto de uma mensagem de um cluster para outro segue obrigatoriamente 3 etapas,
conforme ilustra a Figura 4.3:
1. o nó originário da mensagem original a envia ao RCD do seu cluster, RCD #1;
2. o RCD #1 repassa a mensagem ao RCD do cluster que contém o nó destino —
RCD #2;
3. o RCD #2 envia, finalmente, a mensagem ao nó destinatário.
Para a devida integração desse serviço no ambiente DECK, seria necessária uma
pequena adaptação nesse último, com a finalidade de verificar o destinatário de uma
31
RCD #1
RCD #2
(2)
(1)
(3)
no
originario
no
destinatario
Figura 4.3: Trajeto da mensagem enviada de um cluster a outro através do RCD
110
8
Larg. banda RCD
7
90
6
Larg. banda (MB/s)
Latência (us)
Latência RCD
100
80
70
60
5
4
3
50
2
40
1
30
0
1
2
4
8
16
32
Tam. mensagem (bytes)
64
128
256
1
2
4
8
16
32
64 128 256 512 1K
2K
4K
8K 16K
Tam. mensagem (bytes)
Figura 4.4: Latência e largura de banda obtidas com o protótipo do RCD
mensagem a ser enviada; se o destinatário pertence ao contexto de comunicação local,
a mensagem é enviada diretamente, caso contrário ela é enviada ao RCD que por sua vez
encarrega-se do roteamento. No caso da avaliação aqui apresentada, as mensagens foram
explicitamente enviadas ao RCD.
Os testes realizados consistem nas medidas de desempenho clássicas utilizadas em
clusters, nomimalmente a latência mínima de comunicação e a largura de banda sustentada máxima para troca de dados.
Os gráficos apresentando os valores obtidos são mostrados na Figura 4.4. Como
esperado, observa-se um atraso no envio das mensagens, em comparação a um envio “local” (conforme apresentado no capítulo anterior). Adicionalmente, no gráfico relativo à
largura de banda, nota-se uma mudança de comportamento da curva, a partir do tamanho 1K. Essa mudança é devido à troca de protocolo de comunicação, no DECK-BIP,
justamente nesse tamanho de mensagem.
Considera-se que o programador tem consciência da natureza fracamente acoplada
da união dos clusters, e que a aplicação paralela deve ser devidamente adaptada para essa
situação. Analogamente, assim como os algoritmos paralelos existentes no início dos
anos 90 tiveram que ser adaptados para serem utilizados em ambientes de clusters (BAKER, 2000), devido ao menor desempenho da comunicação, acredita-se que os algoritmos
podem também ser adaptados para tolerar a maior latência de comunicação entre clusters
acoplados por um modelo como o MultiCluster. Julga-se que as possíveis vantagens obtidas pela união de recursos computacionais eventualmente disponíveis, mas a princípio
isolados entre si, supera e compensa os problemas advindos da comunicação.
32
4.4 Considerações adicionais sobre o modelo
O modelo apresentado nesse Projeto de Pesquisa está em constante desenvolvimento pelos pesquisadores do projeto MultiCluster. Atualmente, dois alunos de Doutorado, dois de Mestrado e diversos bolsistas de Iniciação Científica trabalham em temas
ligados ao modelo e na adaptação do ambiente DECK para que o mesmo possa implementar as funcionalidades previstas dentro do modelo.
A idéia básica é fornecer ao programador uma interface de programação que encapsule todos os aspectos relativos à integração dos clusters e que forneça-lhe todas as
primitivas e funcionalidades necessárias para que o mesmo possa determinar como desejar configurar a arquitetura e posteriormente distribuir suas tarefas de cálculo de acordo
com as necessidades de comunicação de cada uma, explorando a disponibilidade de memória compartilhada e troca de mensagens.
Nesse sentido, a idéia é estender o ambiente DECK com novos módulos que implementem as funcionalidades previstas no modelo. Um módulo de comunicação entre
clusters, que suporte e implemente o protocolo RCD é uma das extensões. Adicionalmente, o processamento do arquivo descritor e a correta configuração e inicialização do
ambiente de acordo com esse arquivo é outra extensão prevista; bem como o gerenciamento de toda a arquitetura integrada para fins de balanceamento de carga e tolerância a
falhas e a determinação de métricas para medir desempenho nessa arquitetura correspondem a outras extensões.
33
5 CONCLUSÕES
A exploração de arquiteturas de clusters firmou-se ao longo dos anos 90 como uma
revolução na área de computação paralela, provando que todos os benefícios trazidos por
esse tipo de arqutiterua são perfeitamente alcançáveis e reais. Um reflexo desse panorama
é o contexto atual, onde se pode encontrar clusters compostos por algumas centenas de
nós processadores, cujos índices de desempenhos são bastante próximos ou até mesmo
ultrapassam os índices providos por arquiteturas dedicadas.
Aspectos relativos a novos protocolos de comunicação, controle de fluxo em transmissões de grandes quantidades de dados, gerenciamento de clusters compostos por muitos nós, escalonamento, balanceamento de carga e tolerância a falhas são praticamente
dominados hoje em dia. Muitos grupos de pesquisa ao redor do mundo já publicaram e
defenderam suas propostas no que concerne a esse tipo de arquitetura.
O estabelecimento de plataformas baseadas em grids parece ser uma evolução
lógica dessa panorama e a concretização de idéias surgidas ainda na metade dos anos
80 e que somente agora, com a disponibilidade de tecnologias de rede e ambientes de
programação eficientes e robustos, parece ser possível.
O projeto MultiCluster segue uma evolução parecida: com a finalização das atividades do projeto DPC++, o qual resultou em um ambiente de programação orientada a
objetos distribuídos, que foi alvo de estudo de mestrandos e doutorando do Instituto de
Informática da UFRGS, bem como assunto de algumas dezenas de artigos publicados;
começou-se a exploração de computação baseada em clusters.
Em 1997, o II/UFRGS adquiriu sua primeira plataforma de cluster, com tecnologia Myrinet. Em 1999, a segunda arquitetura (com tecnologia SCI) foi adquirida. Nesse
período, a cooperação com pesquisadores da França e da Alemanha contribui para o entendimento desse novo paradigma para a construção de ambientes de programação, resultando em três versões do ambiente DECK, descritas ao longo desse projeto.
Logicamente, a continuação dessa evolução seria a integração desses clusters com
outros disponíveis no Brasil ou em outro lugar qualquer. Entretanto, busca-se em um
primeiro momento a exploração de um aspecto um pouco menor, mas com igual importância no meio científico: a integração de diferentes paradigmas de comunicação e o
fornecimento de desempenho e confiabilidade dentro desse novo cenário.
Até o presente momento, nenhuma iniciativa específica com esse propósito foi
encontrada, visto que a grande parte da comunidade científica está voltada para o estabelecimento de grandes plataformas computacionais baseadas em grids, sendo em parte
financiadas e apoiadas por governos e indústrias com o mesmo objetivo.
Entendemos que o estabelecimento de grids é algo extremamente relevante e realizável, daqui a pouco tempo, visto a grande quantidade de propostas já existentes. O
modelo MultiCluster nada mais é que um subconjunto de grids, sua arquitetura modular-
34
pode ser facilmente estendida ou integrada a outros ambientes para permitir que o modelo
seja usado em clusters geograficamente distantes, caracterizando uma espécie de grid.
O trabalho apresentado nesse Projeto de Pesquisa corresponde aos estudos iniciais acerca do modelo, com o estabelecimento de aspectos básicos da funcionalidade e
estrutura do mesmo. Adicionalmente, as diferentes versões do ambiente DECK foram
descritas, com o objetivo de mostrar quais as direções e decisões que têm norteado o
projeto.
35
REFERÊNCIAS
BAKER, M. (Ed.). Cluster Computing White Paper. [S.l.]: IEEE Task Force in Cluster
Computing, 2000. Available at http://www.dcs.port.ac.uk/∼mab/tfcc/WhitePaper/finalpaper.pdf. Final Release, Version 2.0.
BARRETO, M.; ÁVILA, R.; CASSALI, R.; CARISSIMI, A.; NAVAUX, P. Implementation of the DECK Environment with BIP. In: MYRINET USER GROUP CONFERENCE, 1., 2000, Lyon, France. Proceedings. . . Lyon: INRIA Rocquencourt, 2000.
p.82–88.
BARRETO, M.; ÁVILA, R.; NAVAUX, P. The MultiCluster Model to the Integrated
Use of Multiple Workstation Clusters. In: WORKSHOP ON PERSONAL COMPUTER
BASED NETWORKS OF WORKSTATIONS, 3., 2000, Cancun. Proceedings. . . Berlin:
Springer-Verlag, 2000. p.71–80. (Lecture Notes in Computer Science, v.1800).
BARRETO, M. E. DECK: Um Ambiente para Programação Paralela em Agregados de
Multiprocessadores. 2000. Dissertação (Mestrado em Ciência da Computação) — Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre.
BARRETO, M. E.; ÁVILA, R. B.; OLIVEIRA, F. A. D. de; CASSALI, R.; NAVAUX,
P. O. A. DECK: An Environment for Parallel Programming on Clusters of Multiprocessors. In: SYMPOSIUM ON COMPUTER ARCHITECTURES AND HIGH PERFORMANCE COMPUTING, 12., 2000, São Pedro, SP. Proceedings. . . São Carlos: UFSCAR, 2000. p.321–329.
BARRETO, M. E.; NAVAUX, P. O. A.; RIVIÈRE, M. P. DECK: a New Model for a Distributed Executive Kernel Integrating Communication and Multithreading for Support of
Distributed Object Oriented Application with Fault Tolerance Support. In: CONGRESO
ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN, 4., 1998, Neuquén, Argentina.
Trabajos Seleccionados. . . Neuquén: Universidad Nacional del Comahue, 1998. v.2,
p.623–637.
BODEN, N. et al. Myrinet: a Gigabit-per-Second Local-Area Network. IEEE Micro, Los
Alamitos, v.15, n.1, p.29–36, Feb. 1995.
BUYYA, R. (Ed.). High Performance Cluster Computing: Architectures and Systems.
Upper Saddle River: Prentice Hall PTR, 1999. 849p.
BUYYA, R. (Ed.). High Performance Cluster Computing: Programming and Applications. Upper Saddle River: Prentice Hall PTR, 1999. 664p.
36
CASANOVA, H.; DONGARRA, J. NetSolve: a Network Server for Solving Computational Science Problems. [S.l.]: University of Tennessee, 1995. (TR-CS-95-313).
FOSTER, I. T.; KESSELMAN, C. Globus: A Metacomputing Infrastucture Toolkit. Disponível por WWW em http://www.globus.org (dez. 1998).
FOSTER, I. T.; KESSELMAN, C. (Ed.). The Grid: Blueprint for a New Computing
Infrastructure. San Francisco: Morgan Kaufmann, 1999. 677p.
GM. Disponível por WWW em http://www.myri.com/GM (dez. 1999).
GRIMSHAW, A. S. et al. Legion: an Operating System for Wide-Area Computing. IEEE
Micro, [S.l.], v.32, n.5, p.29–37, May 1999.
HELLWAGNER, H.; REINEFELD, A. (Ed.). SCI: Scalable Coherent Interface: Architecture and Software for High-Performance Compute Clusters. Berlin: Springer-Verlag,
1999. 490p. (Lecture Notes in Computer Science, v.1734).
HUSE, L. P.; OMANG, K.; BUGGE, H.; RY, H.; HAUGSDAL, A. T.; RUSTAD, E.
ScaMPI—Design and Implementation. In: HELLWAGNER, H.; REINEFELD, A. (Ed.).
SCI: Scalable Coherent Interface: Architecture and Software for High-Performance Compute Clusters. Berlin: Springer-Verlag, 1999. p.249–261. (Lecture Notes in Computer
Science, v.1734).
INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. IEEE Standard
for Scalable Coherent Interface (SCI). New York: [s.n.], 1992. IEEE 1596-1992.
OLIVEIRA, F. A. D. de. Uma Biblioteca para Programação Paralela por Troca de
Mensagens de Clusters Baseados na Tecnologia SCI. 2001. Dissertação (Mestrado em
Ciência da Computação) — Instituto de Informática, Universidade Federal do Rio Grande
do Sul, Porto Alegre.
OLIVEIRA, F. A. D. de; ÁVILA, R. B.; BARRETO, M. E.; NAVAUX, P. O. A.;
DE ROSE, C. DECK-SCI: High-Performance Communication and Multithreading for
SCI Clusters. In: IEEE INTERNATIONAL CONFERENCE ON CLUSTER COMPUTING, 3., 2001, Newport Beach, CA. Proceedings. . . Los Alamitos: CA: IEEE Computer Society, 2001. p.372–379.
SCALI Homepage—Scalable Linux Systems—Affordable Supercomputing. Disponível
por WWW em http://www.scali.com (abr. 2000).
STERLING, T. L. Beowulf Cluster Computing with Linux. Cambridge: MIT Press,
2002.
STERLING, T. L.; SALMON, J.; BECKER, D. J.; SAVARESE, D. F. How to Build a
Beowulf: a Guide to the Implementation and Application of PC Clusters. Cambridge:
MIT, 1999. 239p.
WEBFLOW:
Web
based
Metacomputing.
<http://osprey7.npac.syr.edu>. Acesso em: mar. 2003.
Disponível
em:
WESTRELIN, R. Une Implémentation de MPI Pour Réseaux Locaux à Très Haut Débit:
MPI-BIP. In: RENCONTRES FRANCOPHONES DU PARALLÉLISME), 11., 1999,
Rennes. Proceedings. . . Lyon: INRIA, 1999.