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.


Ouro Preto

Dezembro de 2012

UNIVERSIDADE FEDERAL DE OURO PRETO

FOLHA DE APROVAÇÃO

CollA: Uma Plataforma Colaborativa para programas Java e JavaCá&Lá


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


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


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


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


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-


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,


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.


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


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.


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


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


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 à


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


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.


Figura 4.8: Tela principal do CollA Host.

Figura 4.9: Arquitetura do CollA Host


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.


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


�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


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.

COLLA: UMA PLAAFORMA COLABORATIVA ARAP PROGRAMAS … · pois serve cerca de um dos dois e meio...

Documents

Transcript of COLLA: UMA PLAAFORMA COLABORATIVA ARAP PROGRAMAS … · pois serve cerca de um dos dois e meio...