COLLA: UMA PLAAFORMA COLABORATIVA ARAP PROGRAMAS … · pois serve cerca de um dos dois e meio...
Transcript of COLLA: UMA PLAAFORMA COLABORATIVA ARAP PROGRAMAS … · pois serve cerca de um dos dois e meio...
BRUNO CERQUEIRA HOTT
Orientador: Joubert de Castro Lima
COLLA: UMA PLATAFORMA COLABORATIVA PARA
PROGRAMAS JAVA E JAVACÁ&LÁ
Ouro Preto
Dezembro de 2012
Universidade Federal de Ouro Preto
Instituto de Ciências ExatasBacharelado em Ciência da Computação
COLLA: UMA PLATAFORMA COLABORATIVA PARA
PROGRAMAS JAVA E JAVACÁ&LÁ
Monogra�a apresentada ao Curso de Bachare-lado em Ciência da Computação da Universi-dade Federal de Ouro Preto como requisito par-cial para a obtenção do grau de Bacharel emCiência da Computação.
BRUNO CERQUEIRA HOTT
Ouro Preto
Dezembro de 2012
UNIVERSIDADE FEDERAL DE OURO PRETO
FOLHA DE APROVAÇÃO
CollA: Uma Plataforma Colaborativa para programas Java e JavaCá&Lá
BRUNO CERQUEIRA HOTT
Monogra�a defendida e aprovada pela banca examinadora constituída por:
Dr. Joubert de Castro Lima � OrientadorUniversidade Federal de Ouro Preto
Ms. Felipe Santiago Martins Coimbra de MeloUniversidade Federal de Ouro Preto
Ms. Túlio Ângelo Machado ToffoloUniversidade Federal de Ouro Preto
Ouro Preto, Dezembro de 2012
Resumo
Atualmente, já dispomos na literatura de vasto conjunto de middlewares que permitem espe-
cialistas a executarem suas tarefas em clusters ou grids computacionais. A ideia da compu-
tação voluntária está normalmente presente. Nela, usuários podem participar de um projeto
cedendo computadores, tornando desta forma a infraestrutura computacional maior e mais
propicia a obter soluções a menor custo. Infelizmente, não dispomos de uma infraestrutura
computacional que permita que qualquer especialista possa ceder, porém também usar recur-
sos compartilhados numa rede de voluntários e colaboradores.
A plataforma de software denominada Collaborative Anlysis (CollA) tem como obje-
tivo permitir que artefatos possam ser compartilhadas por diversos especialistas em diversos
ambientes. Os principais artefatos da plataforma CollA são: fontes de dados, nós de proces-
samento (incluindo processador, memória principal e secundária), componentes de software,
experimentos ou apenas resultados dos experimentos. Nossa hipótese é que ao compartilhar
artefatos permitimos que especialistas possam colaborar cada vez mais no processo decisório,
tornando-o menos custoso, mais ágil e mais robusto.
Neste trabalho foram implementados os serviços básicos da plataforma CollA, tais como
chat, manutenção de usuários e grupos de usuário, serviço de compartilhamento de computa-
dores, incluindo a possibilidade de utilização de computadores com IPs inválidos, o serviço de
execução de quaisquer tarefas implementadas em Java e a integração com o middleware para
desenvolvimento de aplicações paralelas ou distribuídas Java Cá&Lá. A plataforma CollA
foi testada exaustivamente, onde fora realizado a submissão de tarefas por mais de oito ho-
ras consecutivas a ambientes homogêneos e heterogêneos criados com a plataforma CollA. Nos
ambientes criados a plataforma chegou a gerenciar mais de trinta computadores com diferentes
con�gurações e localizados em diferentes partes do globo. A primeira versão gratuita e livre
da plataforma CollA está disponível ao público, incluindo manuais de utilização e instalação.
i
Abstract
There are many middleware's in the literature useful for specialists to submit tasks to a com-
puter cluster or grid. The voluntary computing is part of such e�ort. Users can participate
from a project by registering computers, turning the computer infrastructure bigger and the-
refore able to solve some hard problems with lower costs. Unfortunately, there is no platform
where users can create communities and share computers, applications, simulations results,
forming a network of volunteers and also collaborators.
The Collaborative Platform called CollA main goal is to share artifacts with specialists in
di�erent communities created in CollA. CollA artifacts are: computers, data sources, applica-
tions and applications results. Our hypothesis is to enable tools and a platform where we can
share, so we believe that specialists will collaborate in the decision making process, turning it
less expensive, robust and faster.
We have implemented the basic services of CollA, including chat, users and groups mana-
gement, computers sharing, including computers with invalid IPs, and task executors. Each
task can be a Java program or a JavaCá&Lá program. JavaCá&Lá is a middleware to fast
prototype distributed or parallel Java applications, where you develop like your sequential
Java environment. CollA platform was tested with homogeneous and heterogeneous compu-
ters. A tester application submits tasks during eight hours to CollA. CollA worked with more
than 30 computers with di�erent con�gurations and disposed at di�erent locations of globe.
Colla is free and public software. Software, manuals and publications can be downloaded from
CollA site.
ii
Dedico este trabalho à minha �lha Marcela, meu bem mais precioso e fonte de perseverança.
iii
Agradecimentos
Agradeço primeiramente a Deus pelos dons da vida e sabedoria. Agradeço à UFOP e aos
professores do DECOM pela oportunidade oferecida e pelos ensinamentos passados. Agradeço
especialmente ao Prof. Joubert pelo tempo dedicado e por toda ajuda para que esse trabalho
fosse realizado. E ao prof. David pela con�ança depositada durante minha graduação. À
turma 08.1 pelos momentos e, em especial, ao Victor Hugo e Saulo Henrique pelo apoio e
ajuda. Agradeço também ao Diogo, companheiro de projeto, que mesmo longe sempre me
ajudou.
Agradeço às repúblicas Molotov e Jóia Rara e aos meus amigos pela companhia, risadas e
rocks. À toda minha família que me incentivou a buscar um futuro melhor e aos meus pais
por sonhar e batalhar por esse dia. E à minha �lha por ser meu maior incentivo. À Lays,
minha �el namorada, por todo amor, incentivo e ajuda, sem você eu já tinha desistido a muito
tempo, você é essencial na minha vida. E a toda família Murta pela torcida.
iv
Sumário
1 Introdução 1
1.1 Organização da Monogra�a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Referencial Teórico 4
2.1 Arquiteturas de Computadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Memória Compartilhada . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Memória Distribuída . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Arquiteturas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Cliente/Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Ponto a ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Soluções Híbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 JavaCá&Lá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Trabalhos Correlatos 10
3.1 Globus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Legion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 MyGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Condor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 BOINC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 XtremWeb-CH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 BonjourGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 PastryGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 SETI@home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Desenvolvimento 18
4.1 CollA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 IPs inválidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 CollA Task Executor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 CollA Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 CollA Client - Aplicativo Developer Viewer . . . . . . . . . . . . . . . . . . . . 27
v
4.4 CollA Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 CollA Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Experimentos 31
5.1 Ambiente Computacional dos Experimentos . . . . . . . . . . . . . . . . . . . . 31
5.2 Metodologia dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Resultados do experimento no ambiente homogêneo e com IPs válidos . . . . . 33
5.4 Resultados do experimento no ambiente heterogêneo e com IPs inválidos . . . . 33
6 Conclusões 35
7 Trabalhos Futuros 36
Referências Bibliográ�cas 51
vi
Lista de Figuras
2.1 Exemplo de uma grade de computação com clusters . . . . . . . . . . . . . . . . . 5
2.2 Organização hierárquica de nós em uma rede de superpares . . . . . . . . . . . . . 8
2.3 Funcionamento principal do BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Componentes da plataforma CollA. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Tela principal do CollA Super Server. . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Modelo de arquitetura utilizado pelo CollA . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Arquitetura do CollA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 Modelo de arquitetura utilizado pelo CollA para o envio de mensagens de chat
entre usuários com IP inválido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente
e o host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7 Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente
e o host com IP inválido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 Tela principal do CollA Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9 Arquitetura do CollA Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10 Tela principal do CollA Developer Viewer. . . . . . . . . . . . . . . . . . . . . . . . 27
4.11 Arquitetura do CollA Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.12 Tela de informações do CollA Groups . . . . . . . . . . . . . . . . . . . . . . . . . 29
vii
Lista de Tabelas
2.1 Tipos de prováveis gargalos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Resultados do experimento em ambiente homogêneo . . . . . . . . . . . . . . . . . 33
5.2 Tempo médio de cada tarefa utilizada no experimento em ambiente homogêneo . . 33
5.3 Resultados do experimento em ambiente heterôgeneo . . . . . . . . . . . . . . . . . 34
5.4 Tempo médio de cada tarefa utilizada no experimento em ambiente heterogêneo . . 34
viii
Capítulo 1
Introdução
A espécie humana pode ser considerada a única que vive no presente, analisa o passado e tenta
prever o futuro. Como estamos cercados de abstrações, tentamos a todo momento predizer
seus comportamentos. Existem duas alternativas cientí�cas para predizer o comportamento
de uma abstração, seja esta uma empresa, a bolsa de valores de um país, um indivíduo de uma
espécie, a Amazônia, e tantas outras. A primeira usa teorias que descrevem o comportamento
da abstração sendo modelada. Normalmente, tais teorias descrevem fenômenos físicos usando
matemática como linguagem. Esta alternativa é representada por abordagens orientadas por
teorias (Theory-Driven Approaches). A segunda usa o comportamento passado, descrito nor-
malmente por um grande volume de dados, para predizer o comportamento. Esta alternativa é
representada por abordagens orientadas por dados (Data-Driven Approaches (Sismanis et al.,
2002; Witten et al., 2005)), usadas quando teorias não existem.
As abordagens orientadas por dados são divididas em abordagens orientadas por hipóteses
(Hypothesis-Driven Approaches Gray et al. (1997); Harinarayan et al. (1996)) e abordagens
orientadas por descobertas (Discover-Driven Approaches (Alpaydin, 2004; Langley, 1996; Mit-
chell, 1997; Russell, 1995)). De uma forma geral, abordagens orientadas por dados permitem
identi�car padrões desconhecidos, não triviais, potencialmente úteis e implícitos a partir de
grandes volumes de dados.
O volume de dados é uma realidade que afeta sensivelmente os recursos computacionais
utilizados pelas abordagens orientadas por dados, sejam estes processamento e memória. Re-
centemente, a Akamai, empresa de infraestrutura de rede da qual pouca gente ouve falar, mas
que é responsável por boa parte do conteúdo que chega a seu browser em qualquer dispositivo,
pois serve cerca de um dos dois e meio bilhões de usuários da internet, lançou o tamanho do
problema no volume de dados. Em seu relatório do primeiro trimestre de 2012 já chegamos
a mais de 700 Petabytes de dados por semana, ou seja, cerca de 700 milhões de bilhões de
bytes por semana. Como prover serviços de análise que suportem tamanha demanda? Já
estamos estudando e neste projeto propomos uma alternativa de solução inicial que passa pela
COLABORAÇÃO.
1
1. Introdução 2
Infelizmente muito pouca pesquisa foi feita no sentido de tornar o processo de análise de
dados mais colaborativo, já que o volume de dados e o número de abordagens para analisá-los
tende a crescer. Partimos da hipótese de que serviços como chats, edição colaborativa, entre
outros, tornam qualquer processo mais colaborativo, incluindo o processo de análise de grandes
volumes de dados. De uma forma geral, existem inúmeras abordagens sendo disponibilizadas,
algumas reunidas em ambientes de código aberto como o Weka (WEKA, 2012), e um número
crescente de fontes de dados disponíveis para serem copiadas e analisadas individualmente por
tais abordagens ou ambientes, mas até o momento quase nenhum esforço foi feito no sentido
de compartilhar mais do que simplesmente fontes de dados entre especialistas. Temos também
na literatura diversos middlewares que permitem criarmos clusters ou grids de computação
voluntária. Nestes ambientes, aplicações ou tarefas podem ser executadas de forma similar
ao CollA, assim como computadores podem ser cedidos à resolução de um problema em larga
escala, porém ainda não é possível criar ambientes onde todos os usuários possam executar
tarefas, ceder computadores e compartilhar fontes de dados.
Devido as limitações impostas nos middlewares e a falta de uma infraestrutura simples e
robusta para o desenvolvimento de aplicações para análise de dados que sejam colaborativas e
distribuídas, implementamos a plataforma de software denominada Collaborative Analysis
(CollA). A plataforma CollA já permite que não somente fontes de dados sejam comparti-
lhadas, mas também que componentes de software, experimentos, resultados de experimentos
e nós de processamento (incluindo memória principal, secundária e processadores) possam ser
usados de forma colaborativa por diferentes especialistas em diferentes ambientes criados na
plataforma.
A plataforma já dispõe do serviço de chat, manutenção de usuários e grupos de usuário,
serviço de compartilhamento de computadores, incluindo a possibilidade de utilização de com-
putadores com IPs inválidos, o serviço de execução de quaisquer tarefas implementadas em
Java e a integração com o middleware para desenvolvimento de aplicações paralelas ou distri-
buídas Java Cá&Lá(JavaCá&Lá, 2012). A plataforma CollA foi testada exaustivamente, onde
fora realizado a submissão de tarefas por mais de oito horas consecutivas a ambientes homo-
gêneos e heterogêneos criados com a plataforma CollA. Nos ambientes criados a plataforma
chegou a gerenciar mais de trinta computadores com diferentes con�gurações e localizados
em diferentes partes do globo. A primeira versão gratuita e livre da plataforma CollA está
disponível ao público, incluindo manuais de utilização e instalação.
1.1 Organização da Monogra�a
O Capítulo 2 faz uma revisão de conceitos sobre computação distribuída, abordando os mo-
delos de arquitetura de computadores e sistemas.
No Capítulo 3 são apresentados alguns trabalhos correlatos que serviram de orientação
1. Introdução 3
para o trabalho proposto.
Os detalhes da arquitetura e desenvolvimento da plataforma são explicados no Capítulo 4.
No Capítulo 5 são apresentados a elaboração e os resultados dos testes e os mesmos são
analisados para se caracterizar o comportamento da plataforma e veri�car a validade das
estratégias propostas e implementadas.
Por �m, as conclusões são apresentadas no Capítulo 6.
Capítulo 2
Referencial Teórico
2.1 Arquiteturas de Computadores
Nesta seção serão abordadas as arquiteturas de computador mais comuns, dentre estas, po-
demos dividi-las em arquiteturas paralelas e arquiteturas distribuídas. Arquiteturas paralelas
possuem diversos elementos de processamento e um sistema de endereço único, facilitando
desta forma a comunicação. Já nas arquiteturas distribuídas encontramos sistemas de ende-
reçamento distintos e o sistema de comunicação usando obrigatoriamente uma rede de dados.
2.1.1 Memória Compartilhada
Arquiteturas paralelas assumem endereçamento compartilhado entre os processos em execu-
ção, portanto não existe envio de mensagens usando redes de dados em tais arquiteturas. Nor-
malmente, temos as máquinas multicore como exemplos de arquiteturas paralelas. Note que
alguns sistemas operacionais oferecem um único sistema de endereços aos processos, mesmo
quando executado sobre um conjunto de máquinas. Neste exemplo não temos uma arqui-
tetura paralela, pois somente os processos dos usuários são abstraídos para usufruírem de
um endereço único, porém os processos de sistema continuam a usar a rede de dados para
comunicação.
2.1.2 Memória Distribuída
Quando temos um grupo de máquinas, �sicamente temos sistemas de memória distintos, por-
tanto não há como processos comunicarem usando o mesmo sistema de endereçamento. Neste
cenário uma rede de dados é adicionada e os processos comunicam por troca de mensagens.
Na literatura diferenciamos as arquiteturas de computadores distribuídas em clusters e grades
computacionais.
4
2. Referencial Teórico 5
Arquitetura em cluster
Um cluster é formado por um conjunto de computadores idênticos que utilizam um mesmo
sistema operacional. Muitas vezes é construído a partir de computadores convencionais, os
quais são ligados em rede e comunicam-se através do sistema, trabalhando como se fossem
uma única máquina de grande porte. Há diversos tipos de cluster. Um tipo famoso é o cluster
da classe Beowulf(Becker et al., 1995), constituído por diversos nós escravos gerenciados por
um só computador.
Segundo o site top500 (Top500, 2012), atualmente o cluster mais poderoso do mundo é o
americano Sequoia, com 1572864 cores e capaz de realizar 20132.7 TFlops de computação.
Arquitetura em grade
Um aspecto característico da computação de cluster é sua homogeneidade. Os computadores
que compõem um cluster são os mesmos, todos têm o mesmo sistema operacional e todos
estão conectados a mesma rede. Por comparação, sistemas de computação em grade têm
alto grau de heterogeneidade: Nenhuma premissa é adotada em relação a hardware, sistemas
operacionais, redes, domínios administrativos, políticas de segurança e assim por diante.
A �gura 2.1 exempli�ca o conceito de grades de computadores. A grade possui dois clusters,
cada um com um conjunto de máquinas de tipos diferentes, e mais duas máquinas autônomas
utilizadas por clientes da aplicação.
Figura 2.1: Exemplo de uma grade de computação com clusters
2. Referencial Teórico 6
2.2 Arquiteturas de Software
Quando se vai projetar um sistema distribuído, fundamentalmente, o arquiteto de software
utiliza a arquitetura centralizada, distribuída ou mesmo uma mistura das duas primeiras.
2.2.1 Cliente/Servidor
Pensar em termos de clientes que requisitam serviços a servidores nos ajudam a entender
e gerenciar a complexidade de sistemas distribuídos. No modelo cliente/servidor básico,
processos em sistemas distribuídos são divididos em dois grupos, com possível sobreposição.
Um servidor é um processo que implementa um serviço especí�co (um serviço de banco de
dados, por exemplo) e um cliente é um processo que requisita um serviço de um servidor
enviando-lhe uma requisição e, na sequência, esperando pela resposta do servidor
Problemas Se uma quantidade maior de usuários ou recursos devem ser considerados deve-
se tomar cuidado com serviços, dados e algoritmos centralizados. Estes conceitos são explica-
dos na tabela 2.1, pois eles normalmente se tornam gargalos, pontos únicos de falhas e saturam
a rede onde residem.
Conceito Exemplo
Serviços centralizados Um único servidor para todos os usuáriosDados centralizados Uma única lista telefônica para todos os usuáriosAlgoritmos centralizados Fazer roteamento com base em informações completas
Tabela 2.1: Tipos de prováveis gargalos
2.2.2 Ponto a ponto
Uma rede ponto a ponto (P2P em inglês) consiste num conjunto de computadores que comu-
nicam entre si de forma descentralizada, isto é, sem a necessidade de um nó ou nós centrais
responsáveis por gerir as ligações entre eles. Cada processo se comporta como um cliente e um
servidor ao mesmo tempo. As arquiteturas descentralizadas possuem as seguintes diferenças
com relação às centralizadas:
• Nenhum nó possui informação completa do estado do sistema;
• Cada nó toma decisões baseado somente em informações locais;
• A falha de um nó não inviabiliza a execução do algoritmo;
• Não se pressupõe a existência de um relógio global.
2. Referencial Teórico 7
As arquiteturas descentralizadas também possuem várias vantagens com relação aos siste-
mas centralizados, entre as quais se destacam:
• Elevada disponibilidade - Como a rede não depende de um nó central a disponibi-
lidade da rede é bastante superior à de uma rede baseada no modelo cliente-servidor.
Mesmo que um determinado nó esteja inativo é sempre possível contactar qualquer outro
nó da rede.
• Particionamento de recursos - Os recursos necessários (algoritmos, dados e comuni-
cação essencialmente) são distribuídos e não estão todos concentrados num nó central.
Desta forma é possível conseguir melhor desempenho e aumentar a capacidade de forma
econômica. Ao contrário de uma rede cliente-servidor, o aumento de nós da rede repre-
senta uma possível melhora na escalabilidade e na tolerância a diversos tipos de falha,
haja visto a possibilidade de implementar replicação e cache em arquiteturas descentra-
lizadas. Note que a latência também pode ser reduzida quando utilizamos arquiteturas
ponto-a-ponto, por exemplo.
• Elevada Segurança e Robustez - Dada a inexistência de um servidor central que
possa ser alvo de um ataque (Single Point of Failure) uma rede P2P apresenta uma
menor probabilidade de ser afetada num ataque malicioso. Sistemas descentralizados
são mais resilientes, ou seja, tolerantes a falha.
Superpares Deve-se notar que localizar recursos relevantes em sistemas P2P pode se tornar
problemático à medida que a rede cresce. A razão para esse problema de escalabilidade é
simples: como não há nenhum modo determinístico para rotear uma requisição de pesquisa
até um recurso especí�co, em essência, a única técnica à qual um nó pode recorrer é enviar
a requisição a todos os nós. Como alternativa, muitos sistemas peer-to-peer propuseram a
utilização de nós especiais que mantenham um índice de recursos localmente.
Nós que mantém índice, ou agem como intermediários, em geral são denominados superpa-
res (superpeers). Sua utilização resulta em uma organização hierárquica. Um exemplo simples
dessa organização é mostrado na �gura 2.2. Nessa organização, todo par comum está conec-
tado como cliente a um superpar. Toda comunicação de e para um par comum ocorre por
meio daquele superpar associado ao par.
2.2.3 Soluções Híbridas
Estruturas híbridas são disponibilizadas notavelmente em sistemas distribuídos colaborativos.
Vamos considerar o sistema de compartilhamento de arquivos BitTorrent. O BitTorrent é um
sistema ponto a ponto de transferência de arquivos. Seu funcionamento principal é mostrado
na �gura 2.3. A ideia básica é que, quando um usuário �nal estiver procurando um arquivo,
ele trans�ra porções do arquivo de outros usuários até que as porções transferidas possam ser
2. Referencial Teórico 8
Figura 2.2: Organização hierárquica de nós em uma rede de superpares
montadas em conjunto, resultando no arquivo completo. Uma meta importante de projeto é
garantir colaboração. Na maioria dos sistemas de compartilhamento de arquivos uma fração
signi�cativa de participantes se limita a obter arquivos. Com essa �nalidade, um arquivo só
pode ser transferido quando o cliente que está transferindo estiver fornecendo conteúdo a mais
alguém.
Figura 2.3: Funcionamento principal do BitTorrent
O BitTorrent combina soluções centralizadas e descentralizadas. Assim como o BitTorrent,
temos um conjunto de serviços sendo ofertados em clouds públicos ou privados que possuem
a mesma natureza. As APIs do Google para serviços de roteamento, geolocalização, tradução
e consulta são outros excelentes exemplos de arquiteturas de sistemas distribuídos híbridas e
bem sucedidas.
2. Referencial Teórico 9
2.3 JavaCá&Lá
Java Cá&Lá (JCL) é um middleware para programação em java de soluções paralelas esca-
láveis, rápidas e robustas sem necessidade de explicitar threads, servidores, balanceadores de
carga ou serviços de nomeação, localização, sincronização, redundância, entre outros. Java
Cá&Lá é um software gratuito e de código aberto desenvolvido na Universidade Federal de
Ouro Preto. Alguns métodos importantes encontrados em sua API são:
• register: Registra um método para futura execução no JCL.
• execute: Executa o método registrado.
• getResult: Recebe o resultado do método, pode bloquear ou não a execução até que
o resultado seja recebido. O resultado é do tipo JCL_result, que pode ser um Objeto
Java ou, em caso de erro, uma Exception Java. A aplicação do usuário pode cair, mas
o JCl não vai propagar tal erro.
• instantiateGlobalVar: Cria uma variável global à aplicação do usuário e ao JCL.
• setValue: Atualiza o valor da variável global.
• getValue: Recebe o valor da variável global.
O Programa 2.1 é um exemplo de uma aplicação feita utilizando o JavaCá&Lá. Primei-
ramente, o usuário instanciou o JCL e registrou a classe Fibonacci com o nome fib. Em
seguida, os argumentos foram passados e fib foi executado. Por �m, o resultado é capturado
e impresso ao usuário.
Programa 2.1: Exemplo de código em JCL
public appl1 ( ) {
// I n i c i a l i z a n d o o JCL
JCL_facade j c l = JCL_FacadeImpl . g e t In s tance ( ) ;
j c l . r e g i s t e r ( Fibonacc i . class , "fib" ) ;
//Execução do Fibonacc i
Object [ ] a rgs ={ new I n t eg e r ( "30" ) } ;
S t r ing t i c k e t = j c l . execute ( "fib" , a rgs ) ;
//Pegando o r e su l t a do
JCL_result j c l r = j c l . ge tResu l tB lock ing ( t i c k e t ) ;
i f ( j c l r . g e tCor rec tResu l t ( ) != null )
System . out . p r i n t l n ( "Fib(30) = " + j c l r . g e tCor rec tResu l t ( ) . t oS t r i ng ( ) ) ;
else
j c l r . ge tErrorResu l t ( ) . pr intStackTrace ( ) ;
}
Capítulo 3
Trabalhos Correlatos
Com a popularização da internet temos a disseminação da computação voluntária e da
computação colaborativa. No primeiro exemplo hosts de usuários dispostos pelo mundo
cedem tempo ocioso de seus computadores para execução de porções de problemas de grande
porte como, por exemplo, a varredura dos sinais oriundos do espaço ou mesmo a procura por
curas de doenças mortais e vastamente contraídas por populações. No segundo exemplo os
usuários não somente cedem CPU, memória e disco, mas também possuem a possibilidade de
submeter tarefas, visualizar resultados e em alguns casos interagir com outros usuários for-
mando grupos. Neste capítulo apresentamos o estado da arte sobre plataformas colaborativas
ou apenas voluntárias existentes.
3.1 Globus
O Globus (Foster e Kesselman, 1997)(Globus, 2012) é atualmente o projeto de maior impacto
na área de Computação em Grade. O sistema desenvolvido é denominado Globus Toolkit (GT)
e provê uma série de funcionalidades que permitem a implantação de sistemas de Computação
em Grade onde hosts podem ser cadastrados e assim se pode montar uma plataforma privada
de computação voluntária em que os computadores cadastrados são usados para processamento
e armazenamento. Este software lida com certas questões de infraestrutura, como manipulação
de mensagens e gerenciamento de recursos, permitindo, portanto, ao desenvolvedor focar sua
atenção na lógica da aplicação.
O GRAM (Grid Resource Allocation and Management) provê uma interface assíncona
de Web Services para iniciar, monitorar e gerir a execução de computações arbitrárias em
computadores remotos. Esta interface permite que o cliente de�na algumas variáveis como o
tipo e a quantidade de recursos designados, os dados para serem enviados para e do local da
execução, o executável e seus argumentos, as credenciais a serem utilizadas, e as persistências
exigidas pelo trabalho. Em outras palavras, é permitido ao cliente monitorar o status tanto
do recurso computacional quanto das tarefas individualmente.
10
3. Trabalhos Correlatos 11
A especi�cação GridFTP provê bibliotecas e ferramentas para uma transferência de dados
con�ável, segura, e de alta performance de memória para memória e de disco para disco. O
WSRF e WS-Noti�cation provê associações entre as propriedades dos recursos com entidades
de rede e o WS-Noti�cation permite o acesso a tais propriedades. Tais funcionalidades per-
mitem a coleta de informações sobre o estado recente dos recursos, que �cam expostos para
consultas externas.
Infelizmente, no Globus o usuário constrói o seu GRID, ou seja, o Globus não suporta
computação colaborativa, onde usuários e grupos de usuários compartilham serviços e variá-
veis. O Globus não pode ser oferecido como serviço a um conjunto de usuários para realizarem
computações diversas e algum tipo de interação entre seus usuários, portanto mantê-lo pode
ser custoso quando usuários esporádicos precisam executar tarefas ou manter dados de forma
distribuída. Imagine um usuário ter de criar uma plataforma Globus para que possa executar
alguns pares de programas e então ter de desfazer tal infraestrutura.
Java CoG Kit
O Java CoG Kit(von Laszewski et al., 2001)(Java CoG Kit, 2012) nos permite acessar, uti-
lizando Java, os serviços Grid providos pelo Globus toolkit. Dentre as funcionalidades do
CoG Kit podemos citar: agendar e administrar computação remota; manipular sistemas de
arquivos distribuídos; permitir a utilização de políticas de segurança; reservar e alocar recur-
sos; disponibilizar meios grá�cos para administração do sistema, execução de tarefas e outras
funcionalidades do usuário.
Por se tratar de um extensão Globus para usuários Java, este sofre das mesmas limitações
descritas para o Globus.
3.2 Legion
Assim como o Globus, o Legion(Grimshaw et al., 1997)(Legion, 2012) é uma plataforma para
se construir serviços em grade de computadores. A característica marcante do Legion é sua
arquitetura orientada a objetos: entidades, tais como computadores, dispositivos de armaze-
namento, aplicações e serviços da grade, são representadas por objetos. Legion provê serviços
básicos que todo objeto necessita, como chamada de métodos e propagação de excessões, e faz
uso de serviços de camadas inferiores, como transporte de mensagem. É assíncrono e possui
variáveis, recursos, compartilhados
Ele possuiu uma arquitetura escalável sem nodos centralizados. O Legion mascara a com-
plexidade do ambiente de hardware, a comunicação e a sincronização. Mantém um nível de
segurança aos usuários e recursos. Contêm mecanismos para administrar e explorar recursos
heterogêneos. Suporta códigos escritos em múltiplas linguagens e provê interoperacionalidade
entre eles. Legion também é tolerante à falhas.
3. Trabalhos Correlatos 12
O legion é �exível às necessidades do usuário no que se diz respeito à performance e nível de
serviço. Por exemplo, um banco necessita de protocolos de segurança mais so�sticados do que
o usuário comum, pagando, então, o preço de se utilizar chaves criptográ�cas maiores assim
como algoritmos de criptogra�a que demandam mais CPU. Para atingir às suas necessidades,
o usuário pode implementar suas próprias políticas ou utilizar alguma existente por meio de
herança. Legion especi�ca a funcionalidade (não a implementação) dos objetos do núcleo
do sistema. Na verdade, ele também provê implementações dos objetos que compreendem o
núcleo, mas os usuários não são obrigados a usá-los.
Devido às suas semelhanças, Globus e Legion dividem os mesmos problemas no que diz
respeito a usuários esporádicos e plataformas voluntárias e não colaborativas.
3.3 MyGrid
O MyGrid(Cirne et al., 2003) objetiva, ao máximo, simpli�car o processo de implantação da
grade computacional, permitindo que qualquer usuário tome a iniciativa de instalar uma grade
computacional com os recursos que dispõe. Sua arquitetura é dividida em uma máquina que
submete e coordena a execução das aplicações (Home Machines), e as máquinas da grade que
serão utilizadas para a execução das aplicações de usuário (Grid Machines). Tais máquinas
podem estar sob um outro tipo de GRID, como o Globus.
Uma tarefa do MyGrid (MyGrid task) é formada pelas subtarefas inicial, grid, e �nal, que
são executadas sequencialmente nesta ordem. Subtarefas são comandos externos chamados
pelo MyGrid. Consequentemente, qualquer programa, escrito em qualquer linguagem, pode
ser visto como uma subtarefa. As subtarefas inicial e �nal são executadas na Home Machine. A
subtarefa inicial é incumbida de con�gurar o ambiente para a tarefa, por exemplo, transferindo
os dados de entrada para aGrid Machine. A subtarefa �nal é tipicamente utilizada para coletar
os resultados das tasks de volta para a Home Machine. As subtarefas de grid executam em
uma Grid Machine e executam a computação em si. Note que as subtarefas intermediárias
podem ser executadas de forma assíncrona pela plataforma MyGrid.
Outro componente importante do MyGrid é o agendador (Scheduler). O Scheduler recebe
a descrição das tarefas que compõe a aplicação do usuário, escolhe qual máquina deve executar
cada tarefa e submete as tarefas para execução. MyGrid utiliza uma �la de trabalhos com
réplica que consiste em agendar todas as tarefas para execução e quando não há mais tarefas a
serem executadas o MyGrid seleciona as máquinas que estão sem trabalho para executarem ré-
plicas das tarefas já submetidas. A réplica que acabar sua execução primeiro é assumido como
uma execução válida e as outras réplicas são canceladas. Essa tática melhora a performance
em situações onde as tasks são designadas a hosts lentos.
As desvantagens são que o próprio usuário que deseja executar aplicações o responsável por
sua implantação. Não considera grupos de usuários e colaboração de computadores, serviços
3. Trabalhos Correlatos 13
e variáveis/recursos.
OurGrid
O OurGrid(Andrade et al., 2003)(OurGrid, 2012) foi construído para suprir a limitação de
usuários colaborando ao ceder máquinas e executores e escalonadores de tarefas distribuídas
facilmente pelo grid. Trata-se de uma comunidade peer-to-peer para compartilhamento de
maquinas para execução, agendada ou não, de tarefas.
O modelo de compartilhamento adotado é de uma rede de favores, ou seja, um modelo no
qual fornecer peers para outro peer é considerado um favor. OurGrid promove equidade aos
seus usuários, em outras palavras, os participantes da rede que doarem mais peers possuem
maior participação na grade de computadores.
OurGrid é completamente descentralizado e composto de entidades autônomas. Cada peer
depende somente do seu conhecimento local para fazer parte do sistema. Quando um usuário
necessita consumir alguns recursos ele envia, via broadcast, uma mensagem solicitando recursos
que te atendam. Todos aqueles que seus recursos satisfazem as características solicitadas e
estão disponíveis (de acordo com suas políticas locais) respondem ao solicitante lhe enviando
uma mensagem.
OurGrid é a plataforma que mais se assemelha ao CollA, possui as mesmas funcionalidades,
porém é completamente descentralizada.
3.4 Condor
O principal objetivo do Condor(Litzkow et al., 1988)(Condor, 2012) é utilizar capacidade
disponível e inutilizada de máquinas pessoais para executar programas, preservando o propri-
etário, do recurso, de perdas de desempenho.
Cada tarefa é realizada individualmente em cada estação de trabalho. Elas não se comu-
nicam ou trocam informação umas com as outras. Se uma tarefa está executando em uma
estação de trabalho, esta veri�ca se o usuário voltou a utilizá-la, e caso tenha voltado, a tarefa
em background é suspensa. Neste caso, o Condor salva seu estado para que a tarefa possa
continuar a executar quando a estação de trabalho �car ociosa novamente.
O cronograma de tarefas é realizado por um coordenador estático e centralizado. Este
coordenador é responsável por reunir as informações do sistema - quais tarefas se encontram
em espera e quais estão executando, além da localização das máquinas ociosas - e implementar
a política de planejamento. O coordenador central pergunta às estações de trabalho para
ver quais estações estão disponíveis, como recursos, aos sistemas e quais já tem tarefas em
background aguardando.
Para que o acesso às máquinas remotas seja feita de maneira justa, o Condor veri�ca
quantas máquinas foram alocadas ao usuário durante um período de tempo, priorizando aque-
3. Trabalhos Correlatos 14
les usuários que menos conseguem máquinas para seu uso. Estes usuários são os chamados
usuários leves ou esporádicos, em contrapartida os usuários que utilizam várias máquinas são
conhecidos como usuários pesados ou intensos.
Como o Condor só utiliza o processamento ocioso das máquinas, o usuário não tem garantia
de quando sua aplicação será executada, dependendo sempre da disponibilidade dos recursos
do GRID.
3.5 BOINC
O sistema BOINC (Berkeley Open Infrastructure for Network Computing)(Anderson,
2004)(Boinc, 2012) foi criado para: reduzir as barreiras da entrada à computação voluntária,
prover o compartilhamento de recursos por projetos autônomos, suportar diversas aplicações
e recompensar os participantes.
Boinc provê ferramentas (scripts em Python e interfaces em C++) para criar, iniciar,
parar e consultar projetos. Adicionando novas aplicações, plataformas e versões de aplicações;
criando unidades de trabalho e monitorando a performance do servidor. BOINC foi projetado
para ser usado por cientistas e não por programadores ou pro�ssionais de TI. Suas ferramentas
são simples, bem documentadas e um projeto cheio de recursos pode ser criado em poucas
horas. Suas aplicações são executáveis na maioria das plataformas disponíveis.
Os participantes podem escolher várias opções que vão desde quanto de banda o BOINC
poderá usar até a velocidade que sua CPU pode trabalhar. BOINC prevê um sistema de
contabilidade que é uma unidade de �crédito�, calculada pela combinação de computação,
armazenamento e transferência utilizada do usuário.
BOINC foi desenvolvido para suprir a alta demanda de computação dos projetos que
possuem vida longa. Em outras palavras, BOINC é uma plataforma para projetos que vão
�car executando por alguns meses ou anos, pois é muito custoso criar uma plataforma deste
porte para executar um problema por algumas horas ou dias. Outra desvantagem vem do
fato de o BOINC não ser colaborativo e sim voluntário, seus usuários apenas cedem poder
computacional para o projeto e não obtém retorno.
3.6 XtremWeb-CH
XtremWeb-CH(XWCH)(Abdennadher et al., 2012)(XtremWeb-CH, 2012) é um middleware
para computação voluntária que pode facilmente implantar e executar aplicações paralelas
e distribuídas em uma infraestrutura de computação voluntária. XWCH consiste de três
componentes principais: o coordenador, o trabalhador e o depósito.
• O coordenador aceita requisições de execução vindas dos clientes, atribui as tarefas
para os trabalhadores de acordo com uma política de escalonamento e disponibilidade,
3. Trabalhos Correlatos 15
supervisiona a execução de tarefas nos trabalhadores, detecta falência/desconexão dos
trabalhadores e re-envia tarefas para outros trabalhadores disponíveis.
• O trabalhador inicia a computação designada a ele e aguarda até que a tarefa �nalize.
Eles utilizam somente um método de �retirar�: ele iniciam conexões com o coordenador
para obter dados de tarefas, ou para noti�car o coordenador sobre o status da tarefa.
Trabalhadores podem executar em um ambiente com IPs inválidos (NAT)
• O depósito é usado pelos trabalhadores para baixarem dados de entrada necessários
para executar sua tarefa alocada e/ou enviar dados de saída produzidos pela tarefa. Um
nó depósito age como um repositório ou servidor de arquivos.
Tem-se também um cliente de linha de comando e uma API para submissão de aplicações.
Pelo ponto de vista do usuário, existem três níveis de abstrações no XWCH:
• Uma aplicação é um conjunto de tarefas, que poderão ser submetidas a restrições de
precedência.
• Um módulo é um conjunto de códigos binários que , em geral, contém o mesmo código
fonte. Cada binário tem como alvo uma plataforma especí�ca (OS, CPU). Uma vez que
um módulo é criado ele está disponível para uso. Desenvolvedores podem utilizá-lo como
um bloco de construção para desenvolver suas aplicações.
• Uma tarefa é a execução de um código binário em um dado trabalhador.
XtremWeb-CH não considera grupos de usuários e a colaboração de computadores, serviços
e variáveis/recursos.
3.7 BonjourGrid
BounjourGrid (Abbes et al., 2009) é capaz de 1) criar, para cada usuário, um ambiente de exe-
cução especí�co de forma descentralizada e 2) orquestrar múltiplas instâncias de middlewares
para grades computacionais. É possível então, construir, sob demanda, ambientes de execução
especí�cos (combinação dos middlewares XtremWeb, Condor, Boinc, entre outros).
BonjourGrid implanta um coordenador, localmente na máquina do usuário, e então solicita
participantes (workers). Utilizando uma infraestrutura de publicar/subscrever, cada máquina
publica seu estado (ocioso, trabalhador, coordenador). O coordenador, então, seleciona um
subgrupo de nós, formando assim um Elemento de Computação (CE) que � utilizando mid-
dlewares como XtremWeb, Condor ou Boinc � irá executar, gerenciar e controlar a aplicação
do usuário. Quando um CE termina a aplicação, seu coordenador retorna ao estado ocioso e
libera todos os trabalhadores para também retornarem ao estado ocioso.
3. Trabalhos Correlatos 16
Cada CE é de propriedade do usuário que iniciou o estado de coordenador na sua máquina.
Então este CE é responsável pela execução de uma ou várias aplicações do mesmo usuário.
No nível de usuário, cada usuário implanta sua aplicação na sua máquina e a execução parece
local. No nível do middleware, encontramos múltiplos CEs independentes executando sua
própria aplicação. E por �m, no nível mais baixo todas as máquinas estão interconectadas e
disponíveis a qualquer usuário.
O BonjourGrid não é colaborativo de forma que os usuários possam interagir e trabalhar
juntos. Além disso, o usuário é dono de um conjunto de máquinas até que a execução de tarefas
seja concluída, o que pode gerar o um desbalanceamento destes recursos entre os usuários do
sistema caso algum mal intencionado decida obter um grande número de máquinas para si.
3.8 PastryGrid
PastryGrid(Abbes et al., 2008) é um sistema para gestão de grades computacionais e aplicações
do usuário sobre uma rede P2P totalmente descentralizada. O sistema não executa somente
aplicações do tipo Bag of Tasts (BoT) mas também aplicações distribuídas com precedência de
tarefas de uma maneira descentralizada. A idéia básica do PastryGrid é que cada aplicação do
usuário cria seu próprio, autônomo e descentralizado ambiente de execução. Cada aplicação
detém um local chamado de Rendez-Vouz Point (RDV), para armazenar ou recuperar dados.
As máquinas que contribuem para a execução de uma ou várias tarefas de uma aplicação
também podem contribuir na gestão e controle de outras tarefas da memsa aplicação. Não
existe um elemento especí�co que coordena os passos da execução das aplicações.
A originalidade do PastryGrid consiste na execução de aplicações distribuídas para tarefas
com precedência, de maneira descentralizada. Uma Aplicação Distribuída (DA) é a combi-
nação de um ou vários módulos. Um módulo é um conjunto de tarefas que usa um mesmo
arquivo binário e, geralmente, diferentes arquivos de entrada. Tarefas de um mesmo módulo
podem ser realizadas de maneira paralela.
Para descrever sua aplicação distribuída um usuário deverá fornecer um pacote comprimido
contento todos os dados necessários, arquivos binários e o grafo de �uxo de dados da aplicação
(onde os nós são as tarefas e as arestas são as comunicações entre as tarefas). O usuário deve
especi�car também os requerimentos para a execução de cada tarefa da plicação. PastryGrid
provê uma ferramenta, chamada de SDAD (Sistema para descrição de aplicações distribuídas).
Nesta ferramenta temos um modo grá�co para aplicações simples e um modo avançado para
aquelas complexas.
O esquema de endereçamento utilizado é baseado em DHT (Tabela Hash Distribuída).
Neste modelo os nós podem se juntar e sair da rede, e as entradas da tabela hash são automa-
ticamente mapeadas em novos nós físicos. Referencias para essas entradas não precisam ser
atualizadas. Ela utiliza um algoritmo de roteamento totalmente descentralizado que garante
3. Trabalhos Correlatos 17
a entrega das mensagens em no máximo O(log(N)) saltos, onde N é o número de nós físicos
participando da rede.
Assim como a plataforma BonjourGrid, o PastryGrid não é colaborativo de forma que os
usuários possam interagir e trabalhar juntos. Além disso, o usuário é dono de um conjunto de
máquinas até que a execução de tarefas seja concluída, o que pode gerar o um desbalancea-
mento destes recursos entre os usuários do sistema caso algum mal intencionado decida obter
um grande número de máquinas para si.
A grande vantagem é a possibilidade de execução de aplicações distribuídas do próprio
usuário, pois os demais middlewares suportam dados distribuídos e aplicações sequenciais
ou paralelas apenas. No caso do CollA o usuário pode enviar tarefas codi�cadas usando
JavaCá&Lá, que permite a fácil prototipação de aplicações Java paralelas ou distribuídas a
partir de um único código similar ao sequencial.
3.9 SETI@home
Por �m temos o SETI@home(Anderson et al., 2002)(SETI@home, 2012) que, diferentemente
das demais, não é uma plataforma e sim uma aplicação. SETI@home utiliza milhões de com-
putadores em casas e escritórios de todo o mundo para analisar sinais de rádio do espaço em
busca de vida extraterrestre. Essa abordagem proporcionou um poder computacional sem
precedentes e demonstrou a viabilidade da computação voluntária onde os recursos compu-
tacionais são providos pelo público em geral. Atualmente existem 4,5 milhões de usuários
cadastrados e o software do cliente foi portado para 175 plataformas diferentes.
A arquitetura do sistema é bem simples: Os dados são quebrados em pequenos pacotes
de 350 KiB, denominados unidades de trabalho (workunits). Os clientes SETI@home são
executados em computadores pessoais espalhados pelo mundo. Basicamente eles requisitam
uma unidade de trabalho, processam a mesma, enviam os resultados para o servidor central
e nesse momento recebem outra unidade de trabalho. O protocolo de comunicação entre os
clientes e o servidor é baseado em HTTP , de maneira a permitir que máquinas atrás de
�rewals consigam contatar o servidor.
A aplicação é fortemente acoplada ao sistema, não permitindo que se executem outros
problemas além do SETI. Além disso, falta um mecanismo que permita um uso mais e�ciente
dos recursos: quando a máquina não está totalmente ociosa o único controle que pode-se fazer
sobre o cliente é colocá-lo em baixa prioridade. O SETI foi o precursor do BOINC.
Capítulo 4
Desenvolvimento
Neste trabalho implementamos uma plataforma de software denominada Collaborative Analy-
sis (CollA). A plataforma CollA já permite que não somente fontes de dados sejam comparti-
lhadas, mas também que componentes de software, experimentos, resultados de experimentos
e nós de processamento (incluindo memória principal, secundária e processadores) possam ser
usados de forma colaborativa por diferentes especialistas em diferentes ambientes CollA que
operam sobre um conjunto de máquinas ou hosts heterogêneos e distribuídos pela internet em
diferentes topologias e tecnologias de rede.
A plataforma CollA permite que grupos de usuários possam ser criados e que artefatos
comuns à análise possam estar disponíveis em tais grupos. A plataforma também já dispõe
do serviço de chat, manutenção de usuários e grupos de usuário, serviço de compartilhamento
de computadores, incluindo a possibilidade de utilização de computadores com IPs inválidos,
o serviço de execução de quaisquer tarefas implementadas em Java e a integração com o mid-
dleware para desenvolvimento de aplicações paralelas ou distribuídas Java Cá&Lá(JavaCá&Lá,
2012). A primeira versão gratuita e livre da plataforma CollA está disponível ao público, in-
cluindo manuais de utilização e instalação.
Na Figura 4.1 ilustramos os serviços nativos na plataforma CollA. Neste exemplo, os
usuários Cli1 e Cli2 possuem os hosts que chamaremos h1, h2 e h3, respectivamente. O
usuário Cli1 possui apenas um host enquanto o usuário Cli2 possui dois hosts cadastrados
no CollA. O usuário Cli1 decide submeter sua tarefa para o CollA executar e o resultado,
assim como a tarefa, passam a �car disponíveis a todo o grupo ao qual Cli1 pertence. Neste
caso, ambos os usuários Cli1 e Cli2 conseguirão re-submeter a tarefa ou mesmo analisar os
resultados. Em suma, basta cada usuário cadastrar um conjunto de hosts CollA e se juntar a
grupos CollA para usufruir de maior poder computacional. Além de submeter tarefas, o CollA
permite que usuários de um mesmo grupo conversem usando chat. Note que o usuário pode se
juntar e/ou criar quantos grupos almejar. Quantos mais hosts forem sendo cadastrados mais
a ideia do CollA �ca interessante.
18
4. Desenvolvimento 19
Figura 4.1: Componentes da plataforma CollA.
4.1 CollA Server
A plataforma CollA possui o servidor, ainda centralizado, chamado de CollA Server, que
mantém informações sobre todo o sistema. Quando um usuário (ou host) efetua seu cadastrado
no sistema ele contata o servidor, passa suas informações e pede permissão para cadastro. O
mesmo ocorre quando um usuário (ou host) se conecta/desconecta do sistema. Sempre uma
solicitação é enviada ao servidor que armazena esta informação. Outra informação importante
que o servidor mantém é o cadastro de grupos existentes e seus participantes.
O servidor possui uma interface onde as principais informações do sistema podem ser
visualizadas de forma coerente. Uma lista com todos os clientes cadastrados na plataforma é
disponibilizada e ao selecionar um deles um grupo de informações sobre o usuário é exibido,
entre elas: nome, email, se ele está online, entre outras. Ao selecionar um usuário os seus hosts
são exibidos e então temos a opção de obtermos informações de qualquer um deles. Outra
informação relevante que �ca disponível no servidor são as seções do usuário, permitindo
acompanhar o histórico de tarefas de cada cliente que inclui: quando ele se conectou, qual
serviço ele utilizou e quando ele deixou o sistema. Por �m, o servidor possui ainda um log que
traz informações, em tempo real, de tudo o que acontece no sistema.
4. Desenvolvimento 20
No exemplo da �gura 4.2 o administrador selecionou o cliente bruno e pode visualizar suas
informações assim como os seus hosts e suas seções. Tal cliente possui apenas o host bruno_0,
está online, possui o IP 192.168.2.101, não possui um IP público, utilizou o serviço de chat às
14:49hs do dia 03/10/2012, etc.
Figura 4.2: Tela principal do CollA Super Server.
No ato do login, o usuário requisita ao servidor os grupos que ele participa e seus membros,
a resposta obtida é uma lista de usuários com seus endereços IP e grupos aos quais pertencem,
além de outras informações como os hosts ofertados. De posse desta lista, o cliente tem a
capacidade de contatar outros usuários de forma direta, sem ter de requisitar essa comunicação
ao servidor.
Fica evidenciado que a arquitetura do CollA é híbrida com base nas arquiteturas clien-
te/servidor e ponto a ponto. Essa estratégia torna o CollA mais robusto e escalável, já que
são poucas as comunicações que devem ser centralizadas, além de seguro, pois exige-se uma
autenticação com o servidor.
A �gura 4.3 exempli�ca simpli�cadamente a arquitetura da plataforma CollA e nos mostra
como uma mensagem de chat é enviada pela rede. No exemplo, o usuário cli1 abre uma conexão
4. Desenvolvimento 21
(a) com o servidor solicitando sua lista de contatos e então abre uma nova conexão (b), desta
vez, com cli2 e envia sua mensagem. A conexão em (b) permanece ativa enquanto o chat
estiver aberto por algum dos seus participantes e é utilizada durante a troca de mensagens
entre eles.
Figura 4.3: Modelo de arquitetura utilizado pelo CollA
Arquiteturalmente, como pode ser visto na �gura 4.4, o CollA Server é um servidor mul-
tithread que utiliza da técnica produtor/consumidor, onde o produtor é o servidor que recebe
as solicitações e as repassa para um de seus Server Workers para que possam responder à so-
licitação. As informações pertinentes à plataforma são encaminhadas ao CollA Management
que se encarrega de armazená-las. Caso o usuário não possua um IP público e visível fora de
sua rede, o socket utilizado na conexão com servidor será armazenado para que este mante-
nha um meio de comunicação com o usuário. O problema com IPs inválidos são tratados na
próxima seção.
Figura 4.4: Arquitetura do CollA Server
4. Desenvolvimento 22
4.1.1 IPs inválidos
Máquinas com IPs válidos podem ser encontradas diretamente por outras máquinas na In-
ternet. Já as máquinas com IPs inválidos não podem ser encontradas diretamente, pois o
endereço IP ao qual se tem acesso é, na realidade, o endereço do provedor de acesso à Internet
(ISP, na sigla em inglês). O ISP distribui endereços IP válidos somente em sua rede interna,
sendo tais endereços IP inacessíveis fora da mesma, impossibilitando, desta forma, o uso de
tais computadores pela plataforma CollA.
IPs inválidos foi uma das questões mais complexas impostas na primeira fase do projeto
CollA, ao qual este documento faz parte. Para solucionar este problema utilizamos o servi-
dor CollA como intermediário na comunicação. Como exemplo, vamos adotar o cenário em
que temos dois usuários: cli1 possuindo IP válido e cli2, inválido. Neste cenário, ao se logar
cli1 entra em contato com o servidor CollA, enviando os dados de autenticação de usuário e
também o seu endereço IP. O servidor compara os dados enviados com a conexão existente.
O mesmo ocorre com cli2, porém o servidor CollA identi�ca que seu IP é invalido, con�r-
mando que trata-se de um computador utilizando algum ISP. Neste cenário cli2 consegue se
comunicar diretamente com cli1, porém cli1 deve utilizar o servidor CollA para que possa se
comunicar com cli2. Utilizando, além do cenário descrito, a aplicação CollA Chat e a �gura
4.5 para exempli�car, temos cli1 enviando sua mensagem, pelo canal (a), para o servidor e este
repassando a mensagem, por (b), ao cli2 que pode respondê-la de maneira direta, utilizando-se
do canal de comunicação unidirecional (c).
Figura 4.5: Modelo de arquitetura utilizado pelo CollA para o envio de mensagens de chatentre usuários com IP inválido
Para que o servidor CollA possa agir como intermediário para clientes ou hosts com ende-
reços IP inválidos, se faz necessária uma conexão ininterrupta entre o usuário com IP inválido
e o servidor. Esta solução inicial acarreta em um gargalo na plataforma CollA, pois se um
número crescente de clientes ou hosts estiverem conectados via ISPs o servidor CollA se torna
o limitante, já que toda a comunicação deverá passar por ele. Neste sentido, estamos traba-
4. Desenvolvimento 23
lhando na versão que diminui tal gargalo, criando o conceito de super Hosts ou super Peers �
Maiores detalhes de super hosts e outras melhorias no capítulo 7.
4.1.2 CollA Task Executor
O que torna o CollA colaborativo é a sua capacidade para executar aplicações em cima da sua
infraestrutura. Os usuários podem ceder suas máquinas pessoais para outros clientes CollA,
possibilitando que pequenos laboratórios possam obter, quando necessário, poder computaci-
onal em grandezas muito superiores das quais eles teriam acesso se utilizassem apenas seus
próprios computadores.
A tarefa a ser executada deve sempre estar vinculada a um grupo ao qual o usuário
pertença, desse modo a tarefa não pertence mais a um cliente e sim ao grupo e seus membros,
que podem acompanhar a sua execução e obter informações sobre a tarefa, como o tempo
que ela levou para executar e o resultado obtido. Uma vez compartilhada, a tarefa pode ser
re-submetida por qualquer usuário do grupo e não apenas seu codi�cador ou proprietário.
Internamente à plataforma CollA, o usuário que solicita a execução de algum aplicativo
deve, antes de mais nada, solicitar ao servidor um host disponível para execução. De posse das
informações dos hosts ativos (online), o servidor é capaz de escolher um host que vai atender
ao usuário, utilizando a técnica round-robin para garantir algum balanceamento. Tal técnica
foi escolhida pois escolhe sempre um host diferente na tentativa de ocupar igualmente todos
os hosts. Depois de escolhido, suas informações são enviadas ao usuário que deve entrar em
contato. O cliente então entra em contato diretamente com o host. Pelo exemplo da �gura 4.6
podemos observar que, por (a), o cliente cli1 entra em contato com o servidor com o intuito
de enviar uma aplicação para execução recebe a informação de que o host h2 se encontra
disponível e, por meio de (b), lhe envia a tarefa para ser executada. O resultado da tarefa é
retornado ao usuário pelo mesmo canal de comunicação (b).
Assim como acontece com a troca de mensagens por chat, alguns dos hosts podem utilizar
IP inválido, o que não permite que sejam contatados diretamente. Nestes casos, também
utilizamos a solução de enviar a aplicação para o servidor que repassa ao host. Podemos
observar esse cenário no exemplo da �gura 4.7, onde o servidor repassa a tarefa de cli1,
recebida por (a), para h2, por meio de (b). O resultado da computação pode ser enviado
diretamente à cli2 desde que este possua um IP válido, usando o canal de comunicação (c).
É também permitido ao usuário que envie alguns anexos à aplicação, tais anexos podem
ser outras aplicações ou bibliotecas que a tarefa necessite para executar, ou ainda arquivos
que a tarefa manipule.
O software JavaCá&Lá (JavaCá&Lá, 2012) é o responsável pela execução das tarefas no
host. Tal software tem a capacidade de executar qualquer aplicação escrita em Java para-
lelamente em um computador multicore. E é também um middleware para dar suporte à
4. Desenvolvimento 24
Figura 4.6: Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o clientee o host
Figura 4.7: Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o clientee o host com IP inválido
4. Desenvolvimento 25
programação paralela, onde as suas aplicações são programadas de forma similar a sequencial,
sendo necessário atender algumas restrições impostas pelo middleware.
Os resultados obtidos através dos hosts e algumas informações sobre a execução da tarefa,
como o tempo de execução da mesma, são disponibilizados a um grupo de usuários CollA.
Cabe a cada usuário abrir o resultado em um aplicativo especí�co, como é o caso dos editores
e planilhas ou ferramentas matemáticas e estatísticas. Assim como os resultados de tarefas
CollA �cam disponíveis a usuários de um grupo CollA, o mesmo acontece com as próprias
tarefas. Desta forma, permitimos a re-submissão de tarefas de qualquer usuário de um grupo
e não apenas pelo programador da mesma. Tarefas que implementam soluções não exatas
para problemas com ordem de complexidade não polinomiais podem se valer e muito da re-
submissão de tarefas CollA com parâmetros de execução diferenciados e obtidos por diferentes
especialistas.
4.2 CollA Host
O CollA Host tem como objetivo permitir que usuários possam cadastrar as máquinas que
se deseja compartilhar com a plataforma CollA. Hosts podem executar qualquer tipo de pro-
grama escrito em Java ou JavaCá&Lá. Com essa funcionalidade o CollA permite que múltiplos
programas possam ser executados transparentemente em máquinas multicore ou grades he-
terogêneas de computadores e que objetos Java possam ser compartilhados entre diferentes
aplicações Java em JVMs distintas. Na seção 4.1.2 foi detalhado o serviço nativo CollA de
execução de tarefas Java ou Java Cá&Lá.
Antes de cadastrar um host o usuário precisa ter cadastrado um usuário utilizando o CollA
Developer Viewer, pois os hosts devem sempre estar vinculados a um usuário. No exemplo da
�gura 4.8 o host bruno_1 se conecta à plataforma CollA.
Arquiteturalmente, como pode ser visto na �gura 4.9, o componente Host Register é res-
ponsável pelo cadastro e login do host com o servidor. Então, um Micro Server passa a
executar para que possa receber mensagens de clientes e servidores CollA. O Micro Server é
multithread e utiliza da técnica produtor/consumidor, onde o produzido são as tarefas rece-
bidas através das mensagens e os consumidores são threads que se encarregam de executar
tais tarefas. Com essa abordagem cada host consegue atender a um número considerável de
usuários.
CollA Host é integrado ao middleware JavaCá&Lá que �ca responsável por executar as ta-
refas recebidas. Com isso, o Task Executor é responsável por enviar as tarefas ao JavaCá&Lá
e por requisitar seus resultados ao mesmo. Os resultados das mensagens são enviados dire-
tamente aos usuários ou ao servidor CollA, podendo também ser armazenados para futuras
solicitações dos clientes.
4. Desenvolvimento 26
Figura 4.8: Tela principal do CollA Host.
Figura 4.9: Arquitetura do CollA Host
4. Desenvolvimento 27
4.3 CollA Client - Aplicativo Developer Viewer
Os usuários CollA utilizam do programa CollA Developer Viewer (CDV) para se cadastrar,
logar, e utilizar os serviços disponíveis pelo CollA, como criação e manipulação de grupos,
chat, submissão de tarefas, entre outros.
Após efetuar seu cadastro e se conectar à plataforma, o usuário pode visualizar os grupos
aos quais ele pertence e os contatos dos seus grupos, assim como a disponibilidade (online ou
o�ine) de tais amigos. Uma vez selecionado algum contato, é possível visualizar seus hosts
cadastrados no CollA e suas características, que vão desde a quantidade de processadores e
memória que a máquina possui até mesmo sua arquitetura e sistema operacional. Uma área de
noti�cações é visível e nela são disponibilizadas algumas informações úteis como, por exemplo,
se o usuário foi aceito em um grupo que ele pediu ingresso ou se seu novo grupo foi criado
com êxito.
Note que o usuário pode se �liar a vários grupos CollA, como também pode cadastrar
vários hosts à sua conta de usuário. No exemplo da Figura 4.10 o usuário bruno selecionou o
grupo Group-test � que também possui cadastrado o usuário diogo � e após ele se selecionar
no grupo, ele visualiza as características do seu host nomeado de bruno_0. Tal host possui 4
processadores, sistema operacional Windows, está cadastrado no Brasil, etc.
Figura 4.10: Tela principal do CollA Developer Viewer.
Arquiteturalmente, como pode ser visto na �gura 4.11 o componente User Register é o
responsável por efetuar o cadastro do usuário e também por logá-lo. Então, um Micro Server
passa a executar para que possa receber mensagens de clientes, hosts e servidores CollA.
4. Desenvolvimento 28
As mensagens recebidas de outros usuários podem ser mensagens de chat ou mensagens de
solicitação de ingresso a grupos. As mensagens recebidas de hosts podem ser mensagens
informando o �m da execução de tarefas ou mensagens com os resultados das tarefas. O
servidor pode contatar o usuário para repassar mensagens de outros usuários e hosts ou enviar
mensagens de con�rmação de login ou con�rmação de criação de grupo.
O componente de Chat é responsável por enviar as mensagens de chat aos outros usuários e
por organizar as mensagens de chat recebidas. O componente Group Manager é o responsável
por criar grupos, pedir ingresso a grupos, por receber convites de ingresso a grupos e por
gerenciar os grupos que o cliente faz parte. O componente Task Scheduler é o responsável
por enviar tarefas para serem executadas, por receber os resultados das tarefas e também por
gerenciar as tarefas e os resultados.
Figura 4.11: Arquitetura do CollA Client
4.4 CollA Groups
O CollA é colaborativo, portanto grupos são fundamentais. No CollA grupos compartilham
de toda infraestrutura computacional cadastrada no CollA. Além disto, grupos usufruem de
privacidade com tarefas, resultados de tarefas e chats disponíveis aos grupos apenas.
Qualquer usuário cadastrado na plataforma pode criar o seu próprio CollA Group, aqueles
que quiserem fazer parte do grupo deverão solicitar seu ingresso, que será analisado pelo seu
administrador. Quem cria o grupo é chamado de administrador e tem o per�l de aceitar ou
recusar novos ingressantes.
Todos os usuários podem visualizar quais são os membros que pertencem aos grupos em
que ele está cadastrado. Algumas informações acerca destes membros também são disponibi-
lizadas, como email do usuário, país de origem e com quantos hosts ele está contribuindo. Na
4. Desenvolvimento 29
�gura 4.12 é exibida as informações do grupo �Group-test�, podemos observar que o usuário
bruno pode ser contatado pelo email �[email protected]�, reside no Brasil e está oferecendo 2
hosts para serem utilizados pela plataforma.
Figura 4.12: Tela de informações do CollA Groups
4.5 CollA Chat
O chat só é possível entre os usuários de um mesmo grupo e como não existe um limite de
grupos em que se pode participar, o chat pode ocorrer entre muitos usuários. Quando um
usuário inicia um chat com alguém, ele envia sua mensagem diretamente ao amigo que é
comunicado e pode respondê-lo da mesma forma. E, no caso do destinatário se encontrar
sob um ISP e com isso possuir um IP inválido, a mensagem é enviada ao servidor para ser
repassada.
4.6 Conclusões
Na atual versão CollA, disponível em (CollA, 2012) já dispomos do serviço CollA Job Executor
para execução de programas Java na plataforma. Cabe a plataforma executar remotamente
o JAR, noti�car o resultado e obter o resultado localmente para possível visualização ou
4. Desenvolvimento 30
análise. As tarefas submetidas, assim como seus resultados, �cam disponíveis ao grupo CollA,
possibilitando a re-submissão de tarefas ou a análise colaborativa dos resultados. O CollA
já executa em ambientes distribuídos compostos por máquinas com IPs válidos e inválidos,
resolvendo assim uma das questões mais complexas impostas na primeira fase do projeto.
Manuais de instalação e utilização foram feitos e já se encontram disponíveis no site. O código
fonte e a documentação, javadoc, do mesmo foram feitos, porém optamos por não torná-los
públicos até que fechemos a segunda fase do projeto, planejada para 2013 apenas.
No próximo capítulo experimentos com o CollA são feitos e os serviços de compartilhamento
de máquinas e submissão de tarefas é testado em dois grupos de usuários, um homogêneo e com
IPs válidos e outro com máquinas distintas, SOs distintos, IPs inválidos e longas distâncias
entre hosts CollA.
Capítulo 5
Experimentos
Este capítulo apresenta os resultados obtidos a partir dos experimentos realizados com a
plataforma CollA. A funcionalidade escolhida para teste foi o CollA Task Executor, pois
utiliza de toda a arquitetura da plataforma.
Foram escolhidos três algoritmos simples para a execução dos experimentos, denominados
jar0, jar1 e jar2. O algoritmo jar0 é responsável por calcular, de forma recursiva, o 40o
elemento da série de Fibonacci. Ele é considerado um algoritmo leve, pois a sua computação
é realizada em menos de um segundo tornando-o excelente para veri�car se as tarefas chegam
a seus destinos e são computadas corretamente, assim como para veri�car se os resultados
obtidos através delas são retornados com sucesso. O algoritmo jar1 gera um vetor de elementos
aleatórios de tamanho 100.000 e os ordena utilizando do método de ordenação Gnome sort1.
Neste exemplo os vetores de números não são enviados pela rede, sendo apenas gerados e
ordenados no host CollA. Este é considerado um algoritmo moderado, pois sua computação
é realizada em um tempo que varia de 17 à 70 segundos dependendo da máquina onde ele
é executado, sendo utilizado para veri�car o comportamento dos hosts quando estressados
e quando possuem várias tarefas por executar. Por �m, o algoritmo jar2 também gera e
ordena um vetor de tamanho 100.000, mas aqui enviamos junto um arquivo anexo de 858KB
e obtemos como resposta o vetor ordenado de tamanho 800KB. Este algoritmo é considerado
pesado e tem como objetivo veri�car o comportamento da plataforma quando sujeita a dados.
5.1 Ambiente Computacional dos Experimentos
Os experimentos foram testados em dois ambientes. Ambos utilizando como servidor uma
máquina com processador Intel Xeon (2, 00 GHz) de 8 núcleos e 16GB de memória RAM com
1Algoritmo similar ao Insertion sort com a diferença que o Gnome sort leva um elemento para suaposição correta, com uma sequencia grande de trocas assim como o Bubble sort. O algoritmo percorre o vetorcomparando seus elementos dois a dois, assim que ele encontra um elemento que está na posição incorreta, ouseja, um número maior antes de um menor, ele troca a posição dos elementos, e volta com este elemento atéque encontre o seu respectivo lugar. Complexidade de tempo: Θ(n2)
31
5. Experimentos 32
sistema operacional Linux Ubuntu, possuindo IP válido.
• O primeiro são dois clusters, um composto por 17 máquinas com processador Intel Core
i3 (3, 30GHz) de 4 núcleos e 8GB de memória RAM com sistema operacionalWindows 7
e outro composto por 18 máquinas com processador Athlon Dual Core 5400B (2, 80GHz)
de 2 núcleos e 2GB de memória RAM com sistema operacional Windows 7. Todas as
máquinas do cluster possuem IPs válidos.
• O segundo ambiente contou com as máquinas do primeiro ambiente e mais um note-
book com processador Intel Core 2 Duo (2, 10GHz) de 2 núcleos e 3GB de memória
RAM com sistema operacional Windows 7, um notebook com processador Intel Core
i3 (2, 40GHz) de 4 núcleos e 3GB de memória RAM com sistema operacional Linux
Ubuntu, um notebook com processador Intel Atom (1, 50GHz) de 2 núcleos com sistema
operacional Windows 7 e 2GB de memória RAM, e um notebook com processador Intel
Core i3 (2, 20GHz) de 4 núcleos e 3GB de memória RAM com sistema operacional Linux
Ubuntu. Todos os notebooks estavam fora da rede local do servidor e não possuíam IPs
válidos. Neste cenário 3 notebooks estavam na cidade de Ouro Preto, Minas Gerais e 1
na cidade do Porto, em Portugal.
O primeiro ambiente foi utilizado para testar a plataforma onde todos os seus usuários
possuem IPs válido. Enquanto no segundo ambiente foi testado o comportamento da plata-
forma quando seus hosts são heterogêneos, ou seja, alguns de seus participantes se encontram
sob provedores de internet e não podem ser contatados diretamente.
5.2 Metodologia dos Experimentos
Foi desenvolvido um algoritmo, denominado Tester, para validar o funcionamento da plata-
forma. Esse algoritmo se cadastra no servidor, loga e envia milhares de tarefas ininterrupta-
mente à plataforma, esperando receber seus resultados. Os três algoritmos descritos no início
deste capítulo foram utilizados nos experimentos, como representado na equação 5.1, onde t
representa o algoritmo enviado e i representa a itereção do Tester :
t0, i%3 = 0
t1, i%3 = 1
t2, i%3 = 2
(5.1)
Antes de inicializar o Tester, o servidor é ligado e as máquinas do ambiente cadastradas
como hosts. Depois do Tester ter sido inicializado o experimento era realizado por um período
de 8 horas sem alteração de hosts.
5. Experimentos 33
5.3 Resultados do experimento no ambiente homogêneo e com
IPs válidos
Para testar a plataforma utilizando um ambiente homogêneo o Tester foi con�gurado para
enviar 40 tarefas por minuto o que daria 19.200 tarefas durante às 8 horas de execução. O
resultado deste teste pode ser visto na tabela 5.1
Tarefas à enviar Tarefas enviadas Respostas obtidas
19.200 18.633 18.632
100, 00% 97, 05% 97, 04%
Tabela 5.1: Resultados do experimento em ambiente homogêneo
Temos então, 19.200 requisições ao servidor com o intuito de obter hosts disponíveis, destas
18.633 foram atendidas e este mesmo número de tarefas foram enviadas aos hosts. Somente
uma tarefa se perdeu ao fazer o caminho contrário e retornar o resultado obtido ao Tester. E
por �m, todos os resultados obtidos foram corretos. Podemos observar um comportamento
estável da plataforma, onde temos algumas tarefas não enviadas pois o servidor não respondeu
à todas as solicitações de �obtenção de hosts� feitas pelo Tester, reforçando que o gargalo da
plataforma é o servidor.
O tempo médio de execução de cada tarefa executada com sucesso, considerando os mo-
mentos em que a tarefa é enviada ao host e o resultado retorna ao Tester é demonstrado na
tabela 5.2.
Algoritmo Tempo médio de execução
jar0 29, 8sjar1 87, 9sjar2 87, 4s
Tabela 5.2: Tempo médio de cada tarefa utilizada no experimento em ambiente homogêneo
5.4 Resultados do experimento no ambiente heterogêneo e
com IPs inválidos
Diferentemente do teste anterior, aqui utilizamos duas máquinas como Testers, cada uma
enviando 12 tarefas por minuto o que daria 5.760 tarefas por cada Tester durante às mesmas
8 horas de execução. O resultado do teste pode ser visto na tabela 5.3
No total temos, 11.520 requisições ao servidor com o intuito de obter hosts disponíveis,
destas 11.219 foram atendidas e este mesmo número de tarefas fora enviadas aos hosts. Du-
rante o teste um dos notebooks se desligou, �cando indisponível. Neste caso o problema é que
5. Experimentos 34
Tester Tarefas à enviar Tarefas enviadas Respostas obtidas
Tester1 5.760 5.619 5.353
Tester1 100, 00% 97, 55% 92, 93%
Tester2 5.760 5.600 5.364
Tester2 100, 00% 97, 22% 93, 13%
Tabela 5.3: Resultados do experimento em ambiente heterôgeneo
o servidor ainda o via como um host disponível e, às vezes, o enviava ao Tester. Como resul-
tado todas as tarefas enviadas à ele foram perdidas. Assim, 502 tarefas se perderam ao fazer
o caminho contrário e retornar o resultado obtido ao Tester. E por �m, todos os resultados
obtidos foram corretos. Podemos observar um comportamento estável da plataforma, onde
temos como gargalo o servidor que não respondeu à todas as solicitações feitas pelo Tester.
O tempo médio de execução de cada tarefa executada com sucesso, considerando os mo-
mentos em que a tarefa é enviada ao host e o resultado retorna ao Tester é demonstrado na
tabela 5.4.
Algoritmo Tempo médio de execução
jar0 7, 6sjar1 64, 2sjar2 69, 1s
Tabela 5.4: Tempo médio de cada tarefa utilizada no experimento em ambiente heterogêneo
Capítulo 6
Conclusões
A plataforma CollA é uma alternativa de solução baseada em colaboração para resolver o
problema da massiva quantidade de dados a serem analisados por diferentes especialistas.
Nesta versão implementamos os serviços básicos que já tornam a plataforma CollA útil a
usuários que almejem colaborar cedendo computadores e componentes de software. Já é
possível executar tarefas programadas em Java (com ou sem o uso do middleware Java Cá&Lá)
na plataforma.
Em linhas gerais, pessoas físicas, laboratórios, universidades, empresas, entre outros, já po-
dem se cadastrar em ambientes na plataforma CollA. CollA pode também ser executado numa
intranet de uma determinada empresa, órgão do governo ou universidade, onde funcionários
criam ambientes, compartilham e cooperam seus processos analíticos. A academia, o governo
e a iniciativa privada podem encontrar ou criar ambientes direcionados a determinadas áreas,
permitindo com isto que especialistas multidisciplinares compartilhem e cooperem cada vez
mais.
A infraestrutura básica para que isto ocorra já está disponível e, como apresentado no
capítulo 7, muitas melhorias já estão em andamento para que tenhamos uma plataforma mais
robusta e que permita que usuários possam formar grupos colaborativos compartilhando re-
cursos computacionais de maneira mais e�ciente, aumentando o desempenho de seus projetos,
uma melhoria bem-vinda principalmente para grupos com acesso a um menor número de
máquinas.
35
Capítulo 7
Trabalhos Futuros
As metas propostas por este trabalho foram concluídas e como melhoria incluiremos alguns
métodos de tolerância à falha, tais como re-conexão dos sockets quando não conseguem se
estabelecer, envio da mesma tarefa para mais de um host como forma de prevenir falhas e
constante monitoração do status dos membros da plataforma de modo a não permitir que
mensagens sejam enviadas a quem não estiver mais disponível.
Incluiremos, também, o conceito de Super Hosts que cuidarão de grupos de hosts ou clien-
tes que estejam usando ISPs para comunicação, recebendo e encaminhando as mensagens que
estes não conseguem receber de forma direta. Deste modo não teremos apenas um interme-
diário CollA (Servidor) e sim vários (Super Hosts). Acreditamos que esta solução, comumente
adotada em sistemas distribuídos em grade escala, atenda as necessidades da plataforma CollA.
E por �m, propomos a integração completa ao projeto Cá&Lá Parallel Program-
ming(JavaCá&Lá, 2012), permitindo que tarefas CollA possam ser programadas usando o
middleware Java Cá&Lá em qualquer versão. Desta forma, as tarefas poderão ser executadas
em várias máquinas e gerenciadas pelo CollA transparentemente. Na segunda fase do pro-
jeto também propomos implementar o serviço de partição de bases de dados para o usuário.
Massivas bases de dados em formato texto poderão usar o ambiente CollA como repositório
compartilhado. Além disto, as atuais tarefas poderão usar as bases a partir da plataforma
CollA e não mais localmente.
36
Apêndice
Neste capítulo são apresentados o Guia de Instalação e o Guia do Usuário da plataforma
CollA.
37
GUIA DE INSTALAÇÃO COLLA
CONFIGURAR XML SERVER_CONF
Antes de instalar, cabe ao usuário configurar o arquivo server_conf. O usuário deve editar somente o
campo referente ao endereço IP da máquina servidor. O arquivo XML server_conf deve estar presente
no mesmo diretório dos projetos CollA_Client e CollA_Host. Sem o correto endereço IP do server CollA a
plataforma não funciona.
INSTALAR SERVIDOR
O usuário deverá escolher uma máquina de sua rede e instalar o jar chamado CollA_server. Nenhuma
informação será requerida neste passo.
INSTALAR CLIENTE
Após o servidor estar funcionando, instalar o jar CollA_client na máquina que o usuário almeja submeter
tarefas, fazer chat, etc. Caso o usuário possua mais de um dispositivo, basta instalar o CollA_Client em
quantos computadores almejar. Depois de instalado, o usuário loga ou se cadastra na plataforma CollA.
INSTALAR HOST
Por fim, instale quantos hosts almejar usando o jar CollA_Host. Cada host exigirá registrar os dados do
usuário, portanto algum usuário já deve estar cadastrado na plataforma CollA.
JÁ INSTALEI, E AGORA?
Depois de toda plataforma CollA instalada, você pode convidar quantos clientes almejar e estes podem
registrar hosts, submeter Tasks, etc., tornando um departamento, uma universidade, uma software
house, um grupo de pesquisa, etc., um grupo CollA.
GUIA DO USUÁRIO COLLA
É fundamental a leitura do documento Guia do Usuário. Com ele aprenderemos a usar os serviços já
disponíveis na plataforma CollA.
GUIA DO USUÁRIO COLLA
SERVIDOR
INFORMAÇÕES
VISUALIZAÇÃO DOS LOGS DO SISTEMA
Na tela principal do Servidor - aba Server Status - estão disponíveis informações do sistema, tais como:
cliente C conectou, cliente D se cadastrou, entre outras.
Fig1. Server status
VISUALIZAÇÃO DOS CLIENTES E HOSTS CADASTRADOS
Clicando na aba Clients você pode visualizar, do lado esquerdo, todos os clientes cadastrados na
plataforma e também seus hosts.
Fig2. Clientes CollA e seus hosts
VISUALIZAÇÃO DOS STATUS DE CLIENTES E HOSTS
Para visualizar as informações detalhadas sobre cada cliente basta selecioná-lo para que suas
informações apareçam na coluna central do aplicativo CollA Server. Os hosts cadastrados pelo usuário
podem ser detalhados ao clicar sobre o host desejado. No exemplo da Figura 2 temos o cliente Bruno
com apenas um host cadastrado (bruno_0) .
VISUALIZAÇÃO DAS SEÇÕES
As sessões de cada usuário podem ser apresentadas no componente sessions da Figura 2.
CLIENTE
GERAL
REALIZAR CADASTRO
Para se cadastrar na plataforma você deverá clicar em "Signup" na tela inicial e preencher um
formulário com algumas informações pessoais. Em seguida confirme seu cadastro pressionando o botão
"Signup". Pronto ! Você está cadastrado na plataforma CollA.
Fig3. Cadastro
LOGAR
Para logar basta entrar com usuário e senha na tela inicial do aplicativo e em seguida no botão "Login".
A janela principal do programa irá abrir.
Fig4. Login
INFORMAÇÕES DA TELA PRINCIPAL
Na tela principal você pode visualizar os contatos do seu grupo que estão online ou off-line. Uma vez
selecionado algum contato, você pode visualizar os hosts de tal contato no painel inferior esquerdo na
Figura 5. Note que você pode se filiar a vários grupos CollA. No exemplo da Figura 5, o usuário bruno
selecionou o grupo Group-test e neste grupo CollA foi escolhido o host bruno_0. O host bruno_0 possui
4 processadores, roda Windows, está cadastrado no Brasil, etc. Na parte inferior da tela são
disponibilizadas algumas informações úteis como, por exemplo, se você foi aceito em algum grupo que
almeja, se o novo grupo foi criado com êxito, entre outras.
Fig5. GUI do usuário na plataforma CollA
GRUPOS
CRIAR NOVO GRUPO
Para criar um novo grupo você deve selecionar "Groups" na barra de menus e em seguida "Create a
group". Insira o nome do grupo e selecione o botão "Create". Você já vai fazer parte deste grupo. Na
Figura 6 criamos o grupo Teste.
Fig6. Criando um novo grupo CollA
PARTICIPAR DE UM GRUPO JÁ EXISTENTE
Para solicitar ingresso em um grupo já existente você deve ir até "Groups->Join a group", pesquisar o
grupo desejado, selecioná-lo e então clicar no botão "Join". Lembrando que seu ingresso ao grupo
depende da aceitação do administrador do mesmo.
Fig7. Filiação a grupos no CollA
ACEITAR OU RECUSAR INGRESSO DE MEMBROS NO MEU GRUPO
Se você é administrador de algum grupo, você pode verificar se existem solicitações de ingresso
pendentes selecionando "Groups->manage my groups". Uma janela será aberta e do lado esquerdo
temos uma lista dos usuários que solicitaram ingresso no grupo. Do lado direito temos duas listas, a
primeira dos usuários que você deseja aceitar e a segunda dos usuários que você deseja recusar. Para
aceitar ou recusar você deve selecionar o usuário desejado e inseri-lo na lista "Accept" ou "Refuse" e em
seguida selecionar o botão "APPLY".
Fig8. Aceites ou recusas de participação de membros em grupos CollA
VISUALIZAR INFORMAÇÕES DO GRUPO
Em "Groups->manage my groups" na aba "Members" você pode visualizar uma lista de membros do
grupo e ao selecionar algum membro você visualiza algumas informações sobre o mesmo. Na Figura 9
ilustramos o detalhamento do membro bruno, pertencente ao grupo Group-test.
Fig9. Informações sobre um membro de um grupo CollA
CHAT
ENVIAR UMA MENSAGEM DE CHAT
Chats só podem ser realizados por pessoas do mesmo grupo, portanto para começar um chat com
alguém é necessário que vocês estejam no mesmo grupo. Do lado esquerdo da tela principal você deve
dar dois cliques sobre o usuário desejado. Uma vez feito isto, uma janela de chat se abre, conforme
ilustra a Figura 10. Observe que existe uma aba para cada usuário que você esteja conversando.
Fig10. Chats
TASKS
ENVIAR UMA TASK
Para enviar uma task (um arquivo jar, ear ou war, com ou sem dependências) a ser executada pelo CollA
remotamente você deve ir ao menu "File->Send Task". Na janela que abrir você deve primeiramente
selecionar o grupo usado para processar a task. Neste caso o CollA seleciona apenas os hosts deste
grupo para usar no processamento da task. Em "Task dependencies" você deverá selecionar todos os
arquivos "jar" que a task precisa para executar. Clique em add para poder navegar nas pastas de seu
sistema de arquivos e escolher. Em "Task arguments (Files)" você deve selecionar todos os arquivos que
a task vai manipular durante sua execução, arquivos texto por exemplo. Clique em add para poder
navegar nas pastas de seu sistema de arquivos e escolher. Depois destes passos você deve selecionar a
task a ser executada (um arquivo jar!). Clique em add para poder navegar nas pastas de seu sistema de
arquivos e escolher. Logo em seguida você deve selecionar a classe a ser executada, dentre as classes
disponíveis na task, e o método a ser executado, dentre os métodos da classe solicitada. Os argumentos
definidos em Task arguments serão usados como parâmetros para o método escolhido, portanto na
atual versão só pode executar tasks que não possuam parâmetros ou que estes sejam arquivos de
qualquer tipo.
Fig11. Enviando uma task para o CollA executar remotamente usando hosts de algum grupo
VER RESULTADOS DAS TASKS
Para ver o resultado de alguma task você deve ir até "File->Results" e selecionar o grupo ao qual a task
pertence. Uma lista de tasks pertencentes ao grupo é exibida. Selecione a task desejada para visualizar
diversas informações da task, assim como o resultado da task. O resultado pode ser persistido na
máquina onde o usuário esta operando o CollA, portanto basta clicar em click here to save... para
persistir o resultado localmente. Se o resultado for do tipo arquivo (Java File Class) o CollA inclusive
oferece a opção de abrir localmente o aplicativo onde tal arquivo poderá ser exibido.
Fig12. Visualizando resultados de tasks submetidas ao CollA
LOGOUT
Para sair da plataforma você deve fechar o aplicativo simplesmente.
HOST
GERAL
REALIZAR CADASTRO
Na primeira vez que você inicializar o host, você terá que cadastrá-lo. Para isso basta inserir as
informações do usuário ao qual você deseje vincular o novo host. Note que o usuário já foi cadastrado
usando a Figura 3, portanto ao cadastrar um host apenas informe os dados de usuários ou membros já
cadastrados. Repita este passo para cada máquina que você almeja colaborar com outros. Cadastre
muitas e cobre de seus parceiros a mesma atitude.
IMPORTANTE: antes de cadastrar um host você deve ter que cadastrar um usuário.
Fig13. Registrar um host
LOGAR
Uma vez que você tenha cadastrado a sua máquina como host, ela irá se conectar automaticamente
quando o programa for inicializado.
INFORMAÇÕES DA TELA PRONCIPAL
A tela principal do host nos traz algumas informações como o ID vinculado a ele e algum possível erro de
conexão.
Referências Bibliográ�cas
Abbes, H.; Cerin, C. e Jemni, M. (2009). Bonjourgrid: Orchestration of multi-instances of grid
middlewares on institutional desktop grids. Parallel and Distributed Processing Symposium,
International, 0:1�8.
Abbes, H.; Cérin, C. e Jemni, M. (2008). Pastrygrid: decentralisation of the execution of
distributed applications in desktop grid. In Proceedings of the 6th international workshop
on Middleware for grid computing, MGC '08, pp. 4:1�4:6, New York, NY, USA. ACM.
Abdennadher, N.; Niinimaki, M. e BenBelgacem, M. (2012). The XtremWebCH Volunteer
Computing Platform, chapter 3. Taylor-Francis.
Alpaydin, E. (2004). Introduction to Machine Learning (Adaptive Computation and Machine
Learning). The MIT Press, 1 edição.
Anderson, D. P. (2004). Boinc: A system for public-resource computing and storage. Procee-
dings of the Fifth IEEE/ACM International Workshop on Grid Computing, pp. 4�10.
Anderson, D. P.; Cobb, J.; Korpela, E.; Lebofsky, M. e Werthimer, D. (2002). Seti@home an
experiment in public-resource computing. Communications of the ACM, 45(11):56�61.
Andrade, N.; Cirne, W.; Brasileiro, F. e Roisenberg, P. (2003). Ourgrid: An approach to
easily assemble grids with equitable resource sharing. Proceedings of the 9th Workshop on
Job Scheduling Strategies for Parallel Processing, 2862:61�86.
Becker, D. J.; Sterling, T.; Savarese, D.; Dorband, J. E.; Ranawake, U. A. e Packer, C. V.
(1995). Beowulf: A parallel workstation for scienti�c computation. International Conference
on Parallel Processing.
Boinc (2012). Boinc open-source software for volunteer computing and grid computing. http:
//boinc.berkeley.edu./.
Cirne, W.; Parannhos, D.; Costa, L.; Santos-Neto, E.; Brasileiro, F.; Sauvé, J.; Silva, F. A. B.;
Barros, C. O. e Silveira, C. (2003). Running bag-of-tasks applicatins on computational
grids: The mygrid approach. Proceedings of the 2003 International Conference on Parallel
Processing, pp. 407�416.
51
Referências Bibliográficas 52
CollA (2012). Colla - collaborative analysis. http://www.joubertlima.com.br/colla/
index.htm.
Condor (2012). Condor high throughput computing. http://research.cs.wisc.edu/
condor/.
Foster, I. e Kesselman, C. (1997). Globus: A metacomputing infrastructure toolkit. Interna-
tional Journal of Supercomputer Applications, 2(11):115�128.
Globus (2012). Globus. http://globus.org/.
Gray, J.; Chaudhuri, S.; Bosworth, A.; Layman, A.; Reichart, D.; Venkatrao, M.; Pellow, F.
e Pirahesh, H. (1997). Data cube: A relational aggregation operator generalizing group-by,
cross-tab, and sub-totals. Data Min. Knowl. Discov., 1(1):29�53.
Grimshaw, A. S.; Wulf, W. A. e Team, T. L. (1997). The legion vision of a worldwide virtual
computer. Communications of the ACM, 40(1):39�45.
Harinarayan, V.; Rajaraman, A. e Ullman, J. D. (1996). Implementing data cubes e�ciently.
SIGMOD Rec., 25(2):205�216.
Java CoG Kit (2012). Java cog kit. http://wiki.cogkit.org/wiki/Main_Page.
JavaCá&Lá (2012). Cá&Lá parallel programming. http://www.joubertlima.com.br/
calapp/index.htm.
Langley, P. (1996). Elements of Machine Learning. Morgan Kaufmann, 1 edição.
Legion (2012). Legion: A worldwide virtual computer. http://www.cs.virginia.edu/
~legion/.
Litzkow, M. J.; Livny, M. e Mutka, M. W. (1988). Condor - a hunter of idle workstations.
Proceedings of the 8th International Conference of Distributed Computing Systems, pp. 104�
111.
Mitchell, T. (1997). Machine Learning. McGraw-Hill Science/Engineering/Math, 1 edição.
OurGrid (2012). Ourgrid. http://www.ourgrid.org/.
Russell, S. (1995). Arti�cial Intelligence: A Modern Approach. Prentice Hall, 1 edição.
SETI@home (2012). Seti@home. http://setiathome.ssl.berkeley.edu/.
Sismanis, Y.; Deligiannakis, A.; Roussopoulos, N. e Kotidis, Y. (2002). Dwarf: shrinking the
petacube. In Proceedings of the 2002 ACM SIGMOD international conference on Manage-
ment of data, SIGMOD '02, pp. 464�475, New York, NY, USA. ACM.
Referências Bibliográficas 53
Top500 (2012). Top500 supercomputer sites. http://www.top500.org/.
von Laszewski, G.; Foster, I.; Gawor, J. e Lane, P. (2001). A java commodity grid kit.
Concurrency and Computation: Practice and Experience, 13:645�662.
WEKA (2012). WEKA project. http://www.cs.waikato.ac.nz/ml/weka/.
Witten, I. H.; Frank, E. e Hall, M. A. (2005). Data Mining: Practical Machine Learning Tools
and Techniques. Morgan Kaufmann, 1 edição.
XtremWeb-CH (2012). Xtremweb-ch: Towards a true p2p computing platform. http://www.
xtremwebch.net.