THIAGO GARRETT SELEÇ ÃO DE NODOS PARA A EXECUÇ ÃO DE EXPERIMENTOS NO PLANETLAB BASEADA NO MONITORAMENTO DE ESTABILIDADE DAS INTERAÇ ÕES FIM-A-FIM

(1)

SELEC ¸ ˜ AO DE NODOS PARA A EXECUC ¸ ˜ AO DE EXPERIMENTOS NO PLANETLAB BASEADA NO

MONITORAMENTO DE ESTABILIDADE DAS INTERAC ¸ ˜ OES FIM-A-FIM

Disserta¸cão apresentada como requisito parcial à obten¸cão do grau de Mestre. Pro- grama de Pós-Gradua¸cão em Informática, Setor de Ciências Exatas, Universidade Fe- deral do Paraná.

Orientador: Prof. Dr. Elias P. Duarte Jr.

Co-Orientador: Prof. Dr. Luis C. E. Bona

CURITIBA 2011

(2)

SUM ´ ARIO

RESUMO iii

ABSTRACT iv

LISTA DE FIGURAS vi

LISTA DE TABELAS vii

LISTA DE ABREVIATURAS E SIGLAS viii

1 INTRODUC¸ ˜AO 1

2 TRABALHOS RELACIONADOS 5

2.1 CoMon . . . 5

2.2 PlanetFlow2 . . . 6

2.3 netEmbed . . . 7

2.4 Vivaldi . . . 8

2.5 Ganglia . . . 8

2.6 MON . . . 9

2.7 SWORD . . . 10

3 MONITORAMENTO OFFLINE DO PLANETLAB 11 3.1 Estrat´egia de Monitoramento Offline . . . 11

3.2 Resultados . . . 14

4 MONITORAMENTO ONLINE DO PLANETLAB 19 4.1 Estrat´egia de Monitoramento Online . . . 19

4.2 Estrat´egias de Sele¸c˜ao de Nodos . . . 20

4.2.1 Grau M´ınimo . . . 20

4.2.2 Maior Grau M´ınimo . . . 22

(3)

4.2.3 Subgrafo com Grau M´ınimo . . . 23

4.2.4 Subgrafo com Maior Grau M´ınimo . . . 24

4.2.5 Clique Est´avel . . . 25

4.3 Implementa¸c˜ao da Ferramenta . . . 27

4.3.1 M´odulo de Monitoramento . . . 28

4.3.2 M´odulo Servidor . . . 28

4.3.3 M´odulo Cliente . . . 29

5 RESULTADOS EXPERIMENTAIS 32 5.1 Análise dos Grafos Obtidos e Estratégias de Sele¸cão . . . 33

5.2 Qualidade dos Nodos Selecionados . . . 44

5.3 Sumariza¸c˜ao das Amostras . . . 54

6 CONCLUS ˜AO 58

REFERˆENCIAS BIBLIOGR ´AFICAS 60

A NODOS DO PLANETLAB UTILIZADOS NOS EXPERIMENTOS 63

(4)

RESUMO

O PlanetLab é umtestbed global de pesquisa que suporta a experimenta¸cão de protocolos e sistemas distribu´ıdos. Usuários de testbeds dinâmicos de larga escala frequentemente executam experimentos que necessitam de um conjunto de nodos com um n´ıvel razoável de estabilidade. Existem ferramentas que auxiliam na sele¸cão de nodos, monitorando-os e filtrando-os segundo critérios estabelecidos pelo usuário. Porém, nenhuma delas monitora intera¸cões fim-a-fim entre pares de nodos. Neste trabalho descrevemos uma estratégia online de monitoramento e várias estratégias de sele¸cão de nodos focadas na comunica¸cão entre cada par de nodos no PlanetLab. Uma das estratégias de sele¸cão consiste em encontrar um conjunto de nodos em que todos comunicam-se entre si de forma estável, o que chamamos de uma Clique Estável, considerando o PlanetLab como um grafo em que uma aresta entre dois nodos representa uma boa comunica¸cão entre eles. Outras estratégias de sele¸cão de nodos, menos restritivas que a Clique Estável, também foram definidas, baseadas nos graus dos nodos. É poss´ıvel selecionar nodos com um grau m´ınimo no grafo, ou com um grau m´ınimo entre si. Uma estratégia de monitoramentooffline para deteçcão de Cliques Estáveis no PlanetLab foi implementada e é descrita. A partir da estratégia online, uma ferramenta foi implementada. Vários experimentos foram executados com a ferramenta criada e são descritos neste trabalho. Os experimentos incluem a sele¸cão de nodos com diferentes estratégias e em diferentes per´ıodos de tempo, a fim de compará-las e verificar seu comportamento no decorrer do tempo. Foi também realizado um experimento para comparar o desempenho dos nodos selecionados pela ferramenta criada com o desempenho de nodos selecionados por outra ferramenta de sele¸cão de nodos, o SWORD.

Esta compara¸cão foi feita por meio da execu¸cão de uma aplica¸cão MapReduce nos nodos selecionados com ambas as ferramentas. Estes experimentos mostraram que os nodos selecionados pela ferramenta proposta executaram o programa, na maioria dos casos, em tempo significativamente menor do que os nodos selecionados pela outra ferramenta.

(5)

ABSTRACT

PlanetLab is a global research testbed used to run experiments with new protocols and distributed applications under realistic conditions. Users of dynamic large-scale testbeds often execute experiments which must be run on a group of nodes with a reasonable level of stability. Although there are tools designed for selecting PlanetLab nodes on which experiments are run, none of these tools classify and select nodes according to their ability to communicate, i.e. they do not monitor the end-to-end interaction between pairs of nodes. In this work we describe an online monitoring strategy as well as several node selection strategies, based on the stability of the communication between pairs of nodes on PlanetLab. One of the node selection strategies finds a group of nodes in whichall nodes communicate among themselves in a stable fashion. We call such a group of nodes a Stable Clique, considering PlanetLab as a graph such that there is an edge between two nodes if they are able to communicate stably according to some criteria. Other node selection strategies, less restrictive than the Stable Clique, were also defined, all of them based on the nodes’ degrees. It is possible to select nodes all of which have some minimum degree or a group of nodes that have some minimum degree considering only the nodes in the group.

An offline monitoring strategy for finding Stable Cliques in PlanetLab was implemented and is described. The online strategy was implemented as a node selection tool. Using this tool, several experiments were conducted and are described in this work. These experiments include the selection of nodes with different stability criteria and for different periods of time, for the sake of comparing them and verifying their behavior as time passes. Experiments comparing the performance of nodes selected by the proposed tool with the performance of nodes selected by another tool, SWORD, were also conducted.

The comparison was made executing a MapReduce application on both sets of nodes.

The experiment results show that, in most cases, the nodes selected by the proposed tool ran the application significantly faster than the nodes selected by the other tool.

(6)

LISTA DE FIGURAS

3.1 Varia¸c˜ao do RTT de um nodo inst´avel. . . 12

3.2 Um limiar ´e usado para classificar os nodos. . . 14

3.3 Taxa de assimetria na classifica¸c˜ao dos nodos. . . 15

3.4 Varia¸c˜ao do tamanho da clique m´axima para o experimento 1. . . 16

4.1 61 nodos com grau m´ınimo 100 no grafo original. . . 21

4.2 100 nodos selecionados com a estrat´egia M GM. . . 22

4.3 Subgrafo de 137 nodos com grau m´ınimo 44 entre eles . . . 24

4.4 62 nodos com grau m´ınimo 45 entre eles. . . 25

4.5 Clique de 30 nodos selecionada. . . 26

4.6 M´odulos da ferramenta implementada. . . 27

4.7 Interface Web. . . 30

5.1 Grau m´edio e m´aximo de hora em hora durante 3 semanas. . . 34

5.2 Grau m´edio e m´aximo no decorrer de um dia. . . 35

5.3 Quantidade de nodos selecionados com diferentes graus m´ınimos no decorrer de 3 semanas. . . 36

5.4 Quantidade de nodos selecionados com diferentes graus m´ınimos no decorrer de um dia. . . 37

5.5 Maior grau m´ınimo para grupos selecionados com diferentes tamanhos no decorrer de 3 semanas. . . 38

5.6 Maior grau m´ınimo para grupos selecionados com diferentes tamanhos no decorrer de um dia. . . 39

5.7 Tamanho e grau m´ınimo do subgrafo selecionado no decorrer de 3 semanas. 40 5.8 Tamanho e grau m´ınimo do subgrafo selecionado no decorrer de 1 dia. . . . 41

(7)

5.9 Quantidade de nodos com o maior grau poss´ıvel dentro de diferentes grupos

no decorrer de 1 dia. . . 42

5.10 Graus m´ınimo, m´edio e m´aximo de um mesmo subgrafo de 62 nodos no decorrer de um dia. . . 43

5.11 Resultados do experimento 1. . . 48

(8)

LISTA DE TABELAS

3.1 Tamanho da clique m´axima na interse¸c˜ao de todos os grafos. . . 17

3.2 Tamanho m´edio da clique m´axima para o per´ıodo de um dia. . . 18

3.3 Tamanho m´edio da clique m´axima para o per´ıodo de uma hora. . . 18

5.1 Média e desvio padrão dos graus médio e máximo para cada limiar. . . 35

5.2 M´edia e desvio padr˜ao da quantidade de nodos selecionados com diferentes graus m´ınimos para cada limiar. . . 37

5.3 M´edia e desvio padr˜ao do maior grau m´ınimo em grupos selecionados com diferentes tamanhos, para cada limiar. . . 39

5.4 M´edia e desvio padr˜ao do tamanho e grau m´ınimo do subgrafo selecionado, para cada limiar. . . 41

5.5 Experimentos realizados com o MapReduce. . . 46

5.6 Execu¸c˜oes do experimento 1. . . 47

5.12 Sumariza¸c˜ao de hora em hora. . . 56

5.13 Sumariza¸c˜ao di´aria. . . 57

(9)

LISTA DE ABREVIATURAS E SIGLAS

CE. . . Clique Est´avel

CGI. . . Common Gateway Interface CPU. . . Central Processing Unit GB. . . GigaByte

GM. . . Grau M´ınimo

HTML. . . HyperText Markup Language MB. . . MegaByte

MGM. . . Maior Grau M´ınimo NTP. . . Network Time Protocol P2P. . . Peer to Peer

RTT. . . Round-Trip Time

SGM. . . Subgrafo com Grau M´ınimo

SMGM. . . Subgrafo com Maior Grau M´ınimo TCP. . . Transmission Control Protocol UDP. . . User Datagram Protocol URL. . . Uniform Resource Locator

(10)

CAP´ ITULO 1 INTRODUC ¸ ˜ AO

Conforme novas alternativas para a arquitetura da Internet são propostas,testbedsreal´ısti- cos de larga escala tornam-se cada vez mais importantes [25]. Estes testbeds são redes amplas nas quais protocolos, aplica¸cões distribu´ıdas e servi¸cos são implantados e avaliados sob condi¸cões supostamente reais. O PlanetLab [10, 9, 27] é uma destas redes globais de pesquisa que suporta o desenvolvimento de novos protocolos e servi¸cos. Atualmente o PlanetLab é composto por cerca de 1088 nodos em cerca de 578 locais ao redor do mundo. Os nodos sãohosts TCP/IP que comunicam-se por meio da Internet. Cada nodo

é gerenciado por uma organiza¸cão autônoma, filiada ao PlanetLab. Diferentes nodos apresentam capacidades e ambientes diferentes. Além disso, não há reserva de tempo de processamento, os usuários utilizam os nodos simultaneamente, competindo pelos recursos, resultando em um ambiente de grande instabilidade.

Pesquisadores necessitam de um ambiente real, sujeito a condi¸c˜oes reais, tais como perdas ocasionais de conectividade e congestionamento, a fim de avaliar suas propostas.

Entretanto, para executar um protocolo ou uma aplica¸cão distribu´ıda é frequentemente necessária a existência de um grupo de nodos que apresentem um n´ıvel razoável de estabilidade entre si. Não é trivial encontrar tal grupo de nodos no PlanetLab [14]. Em um dado momento, um grupo grande desses nodos pode nem mesmo existir. Além disso, um canal de comunica¸cão pode ser, inclusive, não simétrico: se um nodo considera outro nodo estável, a rec´ıproca pode não ser verdadeira. Um nodo pode considerar outros dois estáveis, mas estes dois podem não considerar-se estáveis entre si.

Existem algumas ferramentas dispon´ıveis que auxiliam na sele¸cão de nodos do Pla- netLab [26, 17, 22, 11, 23, 20, 8]. Estas ferramentas, em geral, monitoram informa¸cões referentes a cada nodo (como uso do processador, memória, entre outros) e selecionam nodos que atendem aos critérios estabelecidos pelo usuário. Nenhuma, porém, monitora

(11)

informa¸cões referentes à comunica¸cão entre cada par de nodos. Uma lista destas ferramentas pode ser encontrada em [4].

Neste trabalho descrevemos uma estratégiaonline de monitoramento e vários critérios de sele¸cão de nodos focados na comunica¸cão entre cada par de nodos. Nesta estratégia, são monitoradas as intera¸cões fim-a-fim entre pares de nodos, isto é, o tempo de resposta, medido na camada de aplica¸cão, de cada nodo para cada outro nodo. Obtém-se assim o ponto de vista de cada nodo sobre o estado da rede. A partir destes dados, várias estratégias para selecionar nodos foram definidas.

Uma das estratégias de sele¸cão de nodos consiste em encontrar um grupo de nodos em que todos os nodos comunicam-se entre si de forma estável. Chamamos tal grupo de nodos de uma Clique Estável: se o PlaneLab é representado por um grafo G = (V, E), uma clique [13] é um subgrafo completo de G no qual as arestas correspondem a canais de comunica¸cão classificados como estáveis. Estas cliques podem ser vistas como uma parte estável de uma rede instável. Porém a busca de cliques envolve um alto custo computacional, o que pode tornar a estratégia inviável caso seja necessária uma grande quantidade de nodos.

Dependendo da topologia virtual do sistema a ser executado nos nodos selecionados, pode não ser necessária uma Clique Estável. Assim, foram definidas outras estratégias de sele¸cão de nodos, também baseadas no modelo de grafo da rede, são elas: Grau M´ınimo, Maior Grau M´ınimo, Subgrafo com Grau M´ınimo e Subgrafo com o Maior Grau M´ınimo.

Na estratégia do Grau M´ınimo, são selecionados todos os nodos com grau maior ou igual ao grau m´ınimo especificado. A estratégia do Maior Grau M´ınimo seleciona um número m´ınimo especificado de nodos, com o maior grau m´ınimo poss´ıvel no grafo. Já na es- tratégia do Subgrafo com Grau M´ınimo, são selecionados nodos que resultem em um subgrafo em que o grau m´ınimo seja igual ou maior que o grau m´ınimo especificado, ou seja, os nodos selecionados tem um grau m´ınimo entre eles. A estratégia do Subgrafo com o Maior Grau M´ınimo busca um conjunto de nodos com tamanho m´ınimo especificado que formam um subgrafo com o maior grau m´ınimo encontrado.

Uma estratégia de monitoramento offline para deteçcão de Cliques Estáveis no Pla-

(12)

netLab foi implementada e três experimentos foram realizados. Diz-se offline pois após um per´ıodo de tempo em que o monitoramento é executado, os dados de todos os nodos são coletados para análise. Cada nodo é classificado como estável ou instável, do ponto de vista de cada outro nodo. O critério de classifica¸cão emprega um limiar e será descrito posteriormente. A partir da classifica¸cão, grafos são gerados, nos quais as cliques são computadas. Os resultados dos experimentos referentes a este monitoramentooffline, realizados no PlanetLab, são apresentados neste trabalho.

A estratégia online de monitoramento e sele¸cão de nodos foi implementada em uma ferramenta. Diferentemente da estratégia offline, nesta ferramenta os nodos monitoram cada outro nodo continuamente, enviando os dados para um servidor conforme são obtidos.

Este servidor, além de armazenar os dados do monitoramento, também é responsável por gerar grafos, quando requisitado, os quais serão utilizados na sele¸cão de nodos. Outro aspecto do servidor implementado é que os dados são sumarizados com o passar do tempo, a fim de manter um histórico das medidas referentes a cada par de nodos, por um longo per´ıodo.

Diversos experimentos acerca das estratégias de sele¸cão de nodos foram realizados com a ferramenta criada. Vários resultados foram obtidos e são apresentados neste trabalho.

Estes experimentos incluem a sele¸cão de nodos com diferentes estratégias em grafos gerados ao longo de 3 semanas de monitoramento no PlanetLab. A partir destes resultados foi poss´ıvel comparar as diferentes estratégias de sele¸cão de nodos, além de verificar o comportamento de cada estratégia no decorrer do tempo. Outro experimento realizado foi uma compara¸cão da ferramenta criada com outra ferramenta de sele¸cão de nodos, o SWORD. A compara¸cão baseou-se em diversas execu¸cões de uma aplica¸cão MapReduce [12] em nodos selecionados por ambas as ferramentas. As execu¸cões desta aplica¸cão foram feitas com grupos de nodos de diversos tamanhos (20, 40, 80, 200), e diversos tamanhos de entrada (200MB, 400MB, 2GB, entre outros). Estes experimentos mostraram que os nodos selecionados pela ferramenta criada executaram o programa, na maioria dos casos, em menos tempo do que os nodos selecionados pela outra ferramenta. Em muitos casos o tempo de execu¸cão foi metade ou menor, demonstrando a eficiência da estratégia

(13)

de monitoramento e sele¸cão de nodos definida neste trabalho. Experimentos acerca da sumariza¸cão das amostras do monitoramento também foram realizados.

O restante deste trabalho está organizado da seguinte maneira. No cap´ıtulo 2 são descritos os trabalhos relacionados. No cap´ıtulo 3 são apresentados os resultados dos experimentos com a estratégia de monitoramentooffline para deteçcão de Cliques Estáveis no PlanetLab. O cap´ıtulo 4 descreve a estratégia online de monitoramento e sele¸cão de nodos, assim como a ferramenta implementada. O cap´ıtulo 5 descreve os experimentos realizados com a ferramenta criada e os resultados obtidos, seguido da conclusão no cap´ıtulo 6.

(14)

CAP´ ITULO 2

TRABALHOS RELACIONADOS

Este cap´ıtulo descreve trabalhos relacionados a esta disserta¸cão de mestrado. Diversos trabalhos tratam do monitoramento e da sele¸cão de nodos. Tais trabalhos diferem em diversos aspectos, como a forma de monitoramento, os atributos monitorados, a forma de sele¸cão dos nodos e os objetivos. Estes trabalhos são descritos nas se¸cões seguintes.

2.1 CoMon

O CoMon [26] é um sistema de monitoramento especificamente projetado para nodos do PlanetLab. O objetivo do CoMon é fornecer informa¸cões sobre o ambiente para usuários e administradores. Além de coletar passivamente as informa¸cões fornecidades pelo sistema operacional de cada nodo, o CoMon também coleta dados medidos ativamente, que auxiliam na execu¸cão de experimentos no PlanetLab. Com o CoMon, é poss´ıvel encontrar com maior facilidade nodos “problemáticos”, em que a causa do problema pode estar na própria máquina, no ambiente ou na carga de trabalho presente no nodo. Além disto, os usuários tem acesso a várias informa¸cões acerca de todos os experimentos em execu¸cão nos nodos do PlanetLab, facilitando não apenas o monitoramento e depura¸cão de seu próprio experimento, como também ajudando na tarefa de encontrar problemas causados devido a outros experimentos. A partir dos dados coletados com o monitoramento dos nodos, o CoMon disponibiliza uma ferramenta para a sele¸cão de nodos que satisfazem critérios estabelecidos pelo usuário.

O CoMon é composto de doisdaemons que executam em cada nodo do PlanetLab, uma infraestrutura centralizada para coleta e processamento de dados, e uma ferramenta que dá suporte a consultas simples especificadas pelo usuário. Os dois daemons executando em cada nodo são responsáveis por coletar dados: um coleta dados referentes ao nodo, e o outro dados referente aos slices. Exemplos de dados coletados pelo primeiro daemon são:

(15)

uptime, utiliza¸cão da CPU (Central Processing Unit), tamanho da memória, consumo de memória, tamanho do disco e espa¸co de disco dispon´ıvel. O outro daemon mede o total de recursos utilizado por cada slice: banda de transmissão e recebimento nos últimos 1, 5 e 15 minutos, consumo de memória f´ısica e virtual, uso de CPU e memória e número de portas em uso.

Outro componente do CoMon é uma infraestrutura centralizada para reunir os dados gerados pelosdaemons. Estes dados são coletados pela estrutura central a cada 5 minutos, e armazenados em vários arquivos. Com estes dados crus é feito um processamento básico gerando meta-arquivos que são utilizados por programas CGI (Common Gateway Interface) afim de criar tabelas HTML (HyperText Markup Language) sob demanda. O

´

ultimo componente do CoMon é uma ferramenta para sele¸cão de nodos. Esta ferramenta é acessada através de uma URL (Uniform Resource Locator). O usuário descreve os critérios para sele¸cão dos nodos por meio de uma linguagem com sintaxe similar a linguagem C.

O presente trabalho difere do CoMon no que diz respeito aos dados monitorados e a forma de sele¸cão dos nodos. No CoMon são monitorados apenas atributos relacionados ao estado do nodo, enquanto o presente trabalho visa monitorar o tempo de resposta entre cada par de nodos, ou seja, um atributo relacionado ao estado da comunica¸cão entre um par nodos. Já na sele¸cão de nodos, o CoMon seleciona os nodos que atendem as restri¸cões definidas com base nos últimos dados obtidos. Já a estratégia apresentada neste trabalho pode utilizar os dados referentes a um per´ıodo qualquer de tempo.

2.2 PlanetFlow2

O PlanetFlow [17] é um servi¸co de auditoria de rede que monitora todo o tráfego de rede gerado pelos nodos do PlanetLab. O objetivo deste monitoramento é manter a accountability (responsabiliza¸cão) do tráfego de rede do PlanetLab de forma transparente e eficiente, de acordo com os termos da pol´ıtica de uso do PlanetLab (PlanetLab Acceptable Use Policy), principalmente para auxiliar na resolu¸cão de queixas.

Além da auditoria, os dados coletados pelo PlanetFlow também são úteis para pesquisa, sendo assim armazenados de forma a permitir a minera¸cão e agrega¸cão, além de outras

(16)

consultas mais complexas do que simplesmente determinar qual slice enviou um determinado pacote. A quantidade de dados analisados e catalogados pelo PlanetFlow é de cerca de 4TB (Tera bytes) diários. Mesmo com uma grande quantidade de tráfego monitorado, ooverhead de CPU do PlanetFlow é baixo, chegando a 3% no pior caso.

O servi¸co do PlanetFlow é executado em um slice comum, em todos os nodos do PlanetLab. Porém, o servi¸co executa opera¸cões privilegiadas (como ler cabe¸calhos de pacotes gerados por outrosslices), através do servi¸co Proper [24], o que não é normalmente permitido. O PlanetFlow consiste de quatro componentes principais: um coletor de fluxo que classifica os pacotes enviados em fluxos IP; um banco de dados que armazena os fluxos; interfaces Web e administrativas para consultas à base de dados; e um servidor central para armazenar, consultar, e aquivar os dados de todos os nodos.

Os objetivos do PlanetFlow s˜ao bem diferentes dos objetivos do presente trabalho.

Enquanto o PlanetFlow trata do monitoramento de tr´afego do PlanetLab para auditoria, este trabalho tem como principal objetivo a sele¸c˜ao de nodos para uso em experimentos.

2.3 netEmbed

O netEmbed [21, 22] é um servi¸co para sele¸cão de recursos que satisfazem critérios desejados. A técnica utilizada neste servi¸co para encontrar um grupo de recursos que atenda aos critérios definidos é o mapeamento entre dois modelos: um representando a infraestrutura real dos recursos, e outro representando a estrutura e caracter´ısticas dos recursos desejados pelo usuário. Para tal mapeamento, são utilizados algoritmos heur´ısticos.

Na arquitetura do netEmbed, para manter o modelo que representa a infraestrutura real dos recursos podem ser usados um servi¸co de monitoramento, de gerência de recursos, ou uma combina¸cão de ambos. Porém, tais servi¸cos não são oferecidos pelo netEmbed.

O presente trabalho visa, al´em de selecionar nodos, monitorar os nodos. Isto caracteriza a principal diferen¸ca entre o netEmbed e este trabalho.

(17)

2.4 Vivaldi

O Vivaldi [11] ´e um sistema de coordenadas sint´eticas totalmente distribu´ıdo cujo objetivo

é predizer o RTT (Round-Trip Time) entre hosts, ou seja, determinar o RTT entre dois hosts sem a necessidade de um host comunicar-se com o outro. Para tanto, o algoritmo do Vivaldi atribui coordenadas sintéticas aos hosts, de forma que a distância entre as coordenadas de dois hosts quaisquer corresponde ao RTT entre eles. O algoritmo do Vivaldi tem baixo overhead e as coordenadas computadas estimam os valores de RTT com baixo erro.

Assim como o Vivaldi, o monitoramento do presente trabalho utiliza como métrica o RTT entre cada par de hosts. Porém, no Vivaldi o RTT é uma estimativa que, mesmo com boa precisão, não considera eventuais falhas dos nodos, picos no valor do RTT, problemas na rede ou se o nodo está lento. Além disso, na estratégia de monitoramento definida neste trabalho, consideramos o RTT em ambos os sentidos, ou seja, é medido o RTT de um nodo para outro e o inverso também.

2.5 Ganglia

O Ganglia [23] é um sistema de monitoramento distribu´ıdo escalável projetado para sistemas computacionais de alto desempenho, tais como clusters e grids [15]. Além de prover monitoramento escalável para estes sistemas, o Ganglia também foi implantado com sucesso no PlanetLab. O Ganglia é baseado em um estrutura hierárquica em clusters. Cada nodo dentro de um cluster monitora seus próprios recursos e informa seus dados para todos docluster por meio de um protocolo baseado emmulticast. Para agre- gar os dados dos clusters, o Ganglia usa uma árvore de conexões ponto-a-ponto entre os representantes dos clusters. As informa¸cões monitoradas no Ganglia são referentes ao estado do próprio nodo (como uso de CPU, memória e outras informa¸cões fornecidas pelo sistema operacional).

Assim como no CoMon, os atributos monitorados no Ganglia são relacionados apenas ao estado de cada nodo, e não à comunica¸cão entre cada par de nodo.

(18)

2.6 MON

O MON [20, 19],Management Overlay Network, é um sistema distribu´ıdo projetado para facilitar o gerenciamento de aplica¸cões distribu´ıdas. Para tanto, o MON constrói estruturas overlay que permitem aos usuários executarem comandos instantâneos de gerenciamento, tais como consultar o estado atual da aplica¸cão e dos nodos, ou enviar arquivos para todos os nodos. A estruturaoverlay é responsável por propagar os comandos para todos os nodos, e coletar o resultado. Esta estrutura é constru´ıda sob-demanda, desta forma não são necessários mecanismos de recupera¸cão de falhas complexos, já que a estrutura não é mantida por longos per´ıodos de tempo.

Cada nodo roda um servidor MON, que ´e constitu´ıdo de 3 camadas: gerenciamento de membros, constru¸c˜ao das estruturas overlay e gerenciamento do sistema distribu´ıdo.

O gerenciamento de membros é responsável por monitorar outros nodos a fim de manter uma lista de nodos vivos. Para tanto, cada nodo mantém uma lista parcial dos nodos do sistema. Periodicamente, escolhe um nodo aleatório desta lista para o qual envia uma mensagem contendo sua lista parcial, a fim de atualizar a lista parcial do outro nodo.

Ao receber a resposta, a lista parcial é atualizada. Com este monitoramento, a próxima camada do MON utiliza a informa¸cão dos nodos que estão vivos e falhos para a constru¸cão das estruturas overlays, quando requisitada. Por fim, a última camada é responsável por propagar os comandos de gerenciamento, ou arquivos, enviados pelo usuário, por meio da estrutura overlay criada pela camada anterior. Dentre os comandos suportados pelo MON, é poss´ıvel executar consultas para obter informa¸cões acerca dos recursos dos nodos (como CPU e memória), ou informa¸cões sobre a estruturaoverlay (como número de nodos e topologia). Com estas consultas, também é poss´ıvel selecionar nodos que satisfa¸cam critérios desejados.

O monitoramento do MON considera apenas se o nodo está falho ou não para, a partir desta informa¸cão, construir as estruturasoverlay requisitadas. Desta forma difere do presente trabalho, já que o monitoramento utilizado neste considera o estado da comunica¸cão entre cada par de nodos, e não apenas se os nodos estão falhos ou não.

(19)

2.7 SWORD

O SWORD [8] é uma infraestrutura para descoberta de recursos que permite ao usuário descrever os recursos desejados como um topologia de grupos interconectados, com requi- sitos referentes ao estado de cada nodo e às caracter´ısticas entre nodos e entre grupos.

Em outras palavras, o SWORD é uma ferramenta para encontrar um grupo de nodos que apresentam caracter´ısticas desejadas. Estas caracter´ısticas podem ser referentes ao estado do próprio nodo (como uso de CPU e memória), ou referentes à intera¸cão entre os nodos (como latência).

A arquitetura do SWORD é dividida em 3 componentes: o primeiro é responsável pela especifica¸cão das caracter´ısticas desejadas; o segundo é responsável pelo processamento da busca pelos nodos que satisfazem as caracter´ısticas definidas; o terceiro é um otimizador responsável por encontrar o melhor conjunto de nodos dentre os nodos encontrados pelo componente anterior. É neste otimizador que as restri¸cões entre nodos especificadas pelo usuário são aplicadas.

Para que a arquitetura do SWORD funcione é necessário obter de outro sistema os dados de monitoramento dos nodos do sistema. Na implementa¸cão do SWORD no Pla- netLab, são utilizados os dados do CoMon sobre os nodos.

O SWORD é o trabalho mais próximo do apresentado nesta disserta¸cão, pois é uma ferramenta voltada especificamente para a sele¸cão de nodos. O SWORD não trata do monitoramento dos nodos, apenas apresenta um algoritmo para sele¸cão a partir de dados de monitoramento obtidos de outro sistema. Porém, o SWORD tem uma versão online, possibilitando assim seu uso. Um experimento comparando os nodos selecionados pelo SWORD e pela ferramenta desenvolvida foi realizado e é descrito no cap´ıtulo 5. Como utiliza os dados do CoMon, a versão dispon´ıvel para uso do SWORD apresenta as mes- mas diferen¸cas do CoMon com rela¸cão ao presente trabalho, ou seja, utiliza apenas dados referentes ao estado dos próprios nodos, não da intera¸cão entre eles, e os dados correspondem apenas a última medi¸cão do CoMon. Já no presente trabalho, a medida utilizada é o RTT entre cada par de nodos e é poss´ıvel utilizar dados referentes a diferentes per´ıodos de tempo, não apenas as últimas medi¸cões.

(20)

CAP´ ITULO 3

MONITORAMENTO OFFLINE DO PLANETLAB

Este cap´ıtulo descreve uma estratégia de monitoramentooffline do PlanetLab, bem como resultados de experimentos realizados [14]. No decorrer do texto, os três experimentos realizados serão referenciados como experimento 1, 2 e 3. A se¸cão 3.1 descreve a implementa¸cão offline da estratégia de monitoramento. A se¸cão 3.2 descreve resultados experimentais.

3.1 Estrat´ egia de Monitoramento Offline

Uma estratégia de monitoramentooffline para encontrar um grupo de nodos em que todos os nodos comunicam-se entre si de forma estável. Chamamos tal grupo de nodos de uma Clique Estável: se o PlaneLab é representado por um grafoG= (V, E) no qual as arestas correspondem a canais de comunica¸cão classificados como estáveis, uma clique [13] é um subgrafo completo deG. Estas cliques podem ser vistas como uma parte estável de uma rede instável.

Na estratégia adotada os nodos monitoraram continuamente cada outro nodo, medindo periodicamente o RTT. Baseado nos dados do monitoramento, cada par de nodos é classificado como estável ou instável de acordo com um critério descrito nesta se¸cão. Esta classifica¸cão representa o histórico de estabilidade de cada nodo, do ponto de vista de cada outro, pois registra as mudan¸cas na classifica¸cão que ocorreram com o passar do tempo. A partir da classifica¸cão foram gerados grafos, nos quais foram computadas as cliques máximas.

A implementa¸cão desta estratégia foi feita por meio de um daemon presente em cada nodo. Este daemon enviava periodicamente uma mensagem para cada outro nodo, por meio de um socket UDP (User Datagram Protocol). Ao receber a resposta de cada mensagem, o nodo calculava o RTT e a varia¸cão do RTT, usando uma abordagem baseada

(21)

noTimeOut (TO) de van Jacobson [18].

Após o término do per´ıodo de monitoramento, os dados de todos os nodos foram coletados. Estes dados foram utilizados para modelar o sistema como um conjunto de grafos não direcionados. Um grafo Gt = (V, Et) foi gerado para um instante de tempo t, em que V é o conjunto de nodos que executaram o experimento e E^t o conjunto de arestas que estavam presentes no tempo t. Uma aresta entre dois nodos significa que ambos comunicam-se entre si de forma estável, ou seja, cada um considerou o outro estável. Foram encontrados diversos casos onde um nodo iconsiderou um nodoj estável, mas j não considerou i estável. Nestes casos i, j /∈E^t.

A figura 3.1 mostra a varia¸cão do RTT de um nodo classificado como instável pela maioria dos nodos durante todo o per´ıodo de monitoramento. Esta amostra de RTT em particular foi obtida do ponto de vista do nodo cujo vértice apresentou o maior grau nos grafos gerados no experimento 1.

Figura 3.1: Varia¸c˜ao do RTT de um nodo inst´avel.

Após os grafos G^t serem constru´ıdos, foi executado um algoritmo para encontrar o que chamamos de Cliques Estáveis em G^t, isto é, um subgrafo de G^t em que existe uma aresta de cada nodo para cada outro. Um grafo foi gerado a cada 15 minutos do per´ıodo monitorado. Para determinar se um par de nodos apresenta um padrão estável de comunica¸cão, foi considerado a varia¸cão do RTT como principal medida. A estratégia usada para classificar a comunica¸cão dos nodos como estável ou não emprega o TO (TimeOut) de Jacobson, que baseia-se fortemente na varia¸cão do RTT observada. Além do próprio

(22)

TO, a classifica¸cão emprega um valor de limiar ajustável, calculado empiricamente. Se uma fun¸cão do TO de um dado par de nodos estava abaixo do limiar, então o par de nodos é classificado como estável. Do contrário, é classificado como instável. Note que conforme o passar do tempo, a classifica¸cão de um par de par de nodos em espec´ıfico pode se alterar de estável para instável, e vice-versa. Os tamanhos das cliques para vários diferentes limiares foram avaliados.

O TO é atualizado para cada medida i do RTT. Seja T Oⁱ a média ponderada do TO calculado anteriormente e a medida atual do RTT. Esta média atua como um filtro estat´ıstico para remover ru´ıdos da curva do TO, tornando mais fácil a tarefa de encontrar os vales da curva do TO, descritos abaixo. O TO é calculado conforme a equa¸cão abaixo.

Na equa¸cão, ∆(RT Ti) é a média ponderada das medidas do RTT. |∆(RT Ti)−RT T| corresponde a diferen¸ca do último valor de RTT e a média ponderada. Nos experimentos foram utilizados α= 0.9 e β = 4.

T Oⁱ =α∗T Oⁱ−1+ (1−α)∗(∆(RT Tⁱ) +β∗ |∆(RT Tⁱ)−RT T|)

E importante calcular um limiar “justo” que permite classificar os nodos como estáveis´ ou instáveis. Considerando a curva do TO, exemplificada na figura 3.2, ela frequentemente apresenta uma série de cristas e vales. Um vale corresponde a valores baixos de TO e a varia¸cão do RTT também é baixa. Uma crista corresponde a per´ıodos em que há uma varia¸cão maior de medidas consecutivas de RTT. O limiar é determinado observando a varia¸cão do RTT e as curvas do TO. Inicialmente, a curva calculada para um par de nodos

é suavisada com um filtro estat´ıstico. A comunica¸cão entre o par de nodos é considerada estável durante os per´ıodos em que os vales da curva suavisada estão abaixo do limiar.

O exemplo na figura 3.2 mostra o uso de um limiar de 400ms para determinar a estabilidade de um nodo. Esta curva do TO foi calculada para um nodo que foi monitorado por 4 horas e 30 minutos no experimento 1. Os c´ırculos pequenos mostram os vales do TO. Até às 03:30 do dia 15 de Outubro, o RTT apresentou uma varia¸cão alta, e os vales do TO também foram altos. A varia¸cão do RTT então diminuiu, assim como os valores dos vales do TO. No per´ıodo em que os vales estão em sua maioria acima do limiar, o nodo

é classificado como RUIM (instável). No caso contrário, quando os vales do TO estão

(23)

abaixo do limiar, o nodo é classificado como BOM (estável). O gráfico também mostra que o critério de classifica¸cão não leva em conta varia¸cões breves no valor dos vales do TO, o que poderia levar a uma classica¸cão incorreta.

Figura 3.2: Um limiar ´e usado para classificar os nodos.

3.2 Resultados

Baseado nos dados obtidos com a classifica¸cão dos nodos em cada experimento, um algoritmo de buscas de cliques foi utilizado para encontrar as Cliques Estáveis. Uma descri¸cão deste algoritmo pode ser encontrada em [14].

O experimento 1 durou 7 dias, de 11 de outubro de 2008, 00:00:00 (GMT -3), até 18 de outubro de 2008, 00:00:00 (GMT -3), e envolveu 519 nodos, dos quais 200 foram considerados para a elabora¸cão dos resultados. O experimento 2 durou 8 dias, de 8 de julho de 2009, 00:00:00 (GMT), até 16 de julho de 2009, 00:00:00 (GMT), e envolveu 631 nodos, dos quais apenas 400 foram considerados. O experimento 3 durou 12 dias, de 18 de outubro de 2009, 00:00:00 (GMT), até 30 de outubro de 2009, 00:00:00 (GMT), e envolveu 638 nodos dos quais 461 foram considerados. Em cada um dos três experimentos, o intervalo de tempo entre a gera¸cão de cada grafo foi de 15 minutos, totalizando 4 grafos por hora.

Como descrito na se¸cão 3.1, um limiar foi empregado para classificar os nodos como estáveis ou instáveis a partir do ponto de vista de cada outro outro. Isto permitiu que o cálculo de caracter´ısticas como visões assimétricas, em que um nodo é considerado estável

(24)

por outro, mas o outro não considera ele estável. A figura 3.3 mostra a porcentagem de visões assimétricas obtidas no experimento 1, para diferentes valores de limiar, considerando todos os pares de nodos que foram monitorados.

Figura 3.3: Taxa de assimetria na classifica¸c˜ao dos nodos.

Após a classifica¸cão de todos os pares de nodos, um grafo não direcionado é constru´ıdo.

Neste grafo, os vértices são os nodos e existe uma aresta adjacente aos nodos u e v se e somente se ambos os nodos classificaram o outro como estável, ou seja, eles não apresentam visões assimétricas.

O comportamento do sistema para diferentes valores de limiar foi estudado. Para o experimento 1, valores de limiar de 400ms, 600ms, 1000ms e 2000ms foram usados; para os experimentos 2 e 3, valores de 200ms, 400ms e 600ms foram usados. No experimento 1, 7×24×4×4 = 2688 grafos foram constru´ıdos, no experimento 2, 8×24×4×3 = 2304 grafos foram constru´ıdos e no experimento 3 gerou 12×24×4×3 = 3456 grafos. No total 8448 grafos foram constru´ıdos. Estes s˜ao os grafos em que foram computadas as cliques m´aximas utilizando o algoritmo descrito em [14].

As figuras 3.4, 3.5 e 3.6 mostram o tamanho da clique máxima para cada grafo nos experimentos 1, 2 e 3. Como esperado, o tamanho da clique máxima aumenta conforme o limiar aumenta. Mas observa-se que, conforme o limiar aumenta, a distin¸cão entre estável e “não tão estável” torna-se confusa, já que muitos comportamentos, mesmo instáveis, serão considerados estáveis dentro do n´ıvel de estabilidade representado pelo limiar muito alto. De fato, quando um limiar mais alto é empregado, vários pares de nodos com

(25)

diferentes n´ıveis na varia¸cão do RTT são classificados como estáveis; enquanto um limiar mais baixo os teria diferenciado.

Figura 3.4: Varia¸c˜ao do tamanho da clique m´axima para o experimento 1.

Outro resultado interessante foi obtido quando a clique máxima foi computada a partir da interse¸cão de todos os grafos para cada experimentos e cada limiar. Esta clique corresponde a um grupo de nodos que mantiveram-se como uma clique durante todo o experimento, ou seja, cada nodo na clique classificou cada outro como estável em todos os grafos. A tabela 3.1 mostra o tamanho das cliques máximas nas interse¸cões para cada experimento e limiar.

Além da interseçcão de todos os grafos, outro resultado interessante é o tamanho da clique máxima no grafo resultante da interse¸cão de grafos referentes a per´ıodos menores de tempo. A obten¸cão deste resultado foi motivada pelo fato de que algumas aplica¸cões distribu´ıdas precisam de nodos muito estáveis durante intervalos de tempo menores do

(26)

Experimento Limiar Tamanho

1 400 59

1 600 91

1 1000 117

1 2000 149

2 200 78

2 400 153

2 600 196

3 200 42

3 400 85

3 600 114

Tabela 3.1: Tamanho da clique m´axima na interse¸c˜ao de todos os grafos.

que os dos experimentos. Em tais casos, o conhecimento do maior grupo de nodos que formam uma clique por um curto per´ıodo de tempo é a informa¸cão necessária.

Para cada um dos experimentos e limiares, foi computada a clique máxima nos grafos que foram constru´ıdos durante um dia e uma hora. Os resultados são mostrados nas tabelas 3.2 e 3.3, respectivamente. A tabela 3.2 mostra o tamanho médio das cliques máximas calculadas a cada dia para cada experimento e cada limiar. A tabela 3.3 mostra o tamanho médio das cliques máximas calculadas a cada hora para cada experimento e limiar.

(27)

Experimento Limiar Tamanho m´edio

1 400 90.142

1 600 118.285

1 1000 147.000

1 2000 173.714

2 200 103.375

2 400 185.500

2 600 228.125

3 200 79.416

3 400 151.250

3 600 196.250

Tabela 3.2: Tamanho m´edio da clique m´axima para o per´ıodo de um dia.

Experimento Limiar Tamanho m´edio

1 400 114.130

1 600 143.113

1 1000 167.541

1 2000 185.720

2 200 128.322

2 400 212.307

2 600 257.505

3 200 108.805

3 400 192.642

3 600 243.465

Tabela 3.3: Tamanho m´edio da clique m´axima para o per´ıodo de uma hora.

(28)

CAP´ ITULO 4

MONITORAMENTO ONLINE DO PLANETLAB

Este cap´ıtulo descreve a principal contribui¸cão deste trabalho: uma estratégia online de monitoramento e sele¸cão de nodos para execu¸cão de experimentos no PlanetLab. A estratégia foi implementada em uma ferramenta dispon´ıvel na Web¹.

A se¸cão 4.1 descreve a estratégia de monitoramento dos nodos do PlanetLab, assim como o armazenamento e sumariza¸cão dos dados do monitoramento. Na se¸cão 4.2 são descritas as estratégias de sele¸cão de nodos. A se¸cão 4.3 detalha a implementa¸cão da ferramenta.

4.1 Estrat´ egia de Monitoramento Online

A estrat´egia de monitoramento online ´e executada por todos os nodos do PlanetLab.

Periodicamente, cada nodo envia uma mensagem para cada outro nodo e espera uma resposta. Ao obter a resposta de um nodo, o RTT da mensagem é calculado e enviado a um servidor que precisa estar vis´ıvel. Os intervalos de tempo são medidos no relógio local de cada máquina. Os relógios são sincronizados com NTP (Network Time Protocol) [3].

Uma caracter´ıstica da estratégia é que o RTT é medido na camada de aplica¸cão, por isso o seu valor pode variar não apenas pelas condi¸cões da rede, mas também pelas condi¸cões do próprio nodo, como a quantidade de processos na fila do escalonador, uso de CPU, entre outros. O monitoramento, portanto, é fim-a-fim.

Um servidor é responsável por armazenar e sumarizar os valores de RTT recebidos dos nodos. A sumariza¸cão dos dados tem como objetivo diminuir o espa¸co em disco necessário para armazenar os dados, possibilitando guardá-los por um per´ıodo de tempo maior. No monitoramento, novos valores de RTT são armazenados sem altera¸cão. Em horas cheias, os valores de RTT referentes a antepenúltima hora são sumarizados, e os

1http://planetmon.c3sl.ufpr.br

(29)

dados originais são descartados. Assim, o servidor está sempre armazenando os valores de RTT sem altera¸cão referentes à hora anterior, e a hora atual. Ao sumarizar os dados referentes a uma hora, são calculadas a média, desvio padrão, valor m´ınimo e máximo do RTT dentro daquele per´ıodo, para cada par de nodos. Da mesma forma, na virada do dia, o antepenúltimo dia é sumarizado. Mês e ano também são sumarizados analogamente.

4.2 Estrat´ egias de Sele¸ c˜ ao de Nodos

A partir dos dados de monitoramento armazazenados, o servidor gera grafos que são utilizados na sele¸cão de nodos. Nos grafos gerados pelo servidor, cada vértice é um nodo da rede, e uma aresta entre dois vértices corresponde a uma comunica¸cão estável entre os nodos referentes aos dois vértices. A defini¸cão de estabilidade segue abaixo.

Para gerar os grafos, dois parâmetros são necessários: limiar para o RTT e per´ıodo de tempo. Com isso, para cada par de nodos (a, b), são contados quantos valores de RTT (ou média do RTT, caso estejam sendo usados dados sumarizados) existem dentro do per´ıodo desejado, e quantos valores são menores ou iguais ao limiar. Caso pelo menos 90% dos valores sejam menores ou iguais ao limiar, é dito que o nodoaconsiderab estável naquele per´ıodo e para aquele limiar. Se b também considerar a estável, então existe uma aresta entre a e b. Este processo resulta em um grafo G = (V, E) que representa a rede no per´ıodo e limiar especificados, ondeV representa os nodos do PlanetLab, e E os pares de nodos com comunica¸cão considerada estável.

Várias estratégias de sele¸cão de nodos foram definidas, são elas: Grau M´ınimo, Maior Grau M´ınimo, Subgrafo com Grau M´ınimo, Subgrafo com Maior Grau M´ınimo e Clique Estável. Estas estratégias são descritas nas subse¸cões seguintes e serão referenciadas no restante deste trabalho como GM, M GM, SGM, SM GM e CE, respectivamente.

4.2.1 Grau M´ınimo

A estratégia do Grau M´ınimo (GM) consiste em filtrar os nodos pelo seus graus no grafo que representa o sistema. O parâmetro desta estratégia é o grau m´ınimo. Nodos com

(30)

grau igual ou maior ao grau m´ınimo desejado são selecionados. Esta estratégia é a menos restritiva, e baseia-se somente no fato de que um nodo com grau alto comunica-se de forma estável com um grande número de nodos. Não existe nenhuma restri¸cão entre os nodos selecionados, como no caso da Clique Estável, por exemplo, onde devem haver arestas entre todos os pares de nodos. Desta forma, esta estratégia é a que seleciona o maior número de nodos.

A figura 4.1 mostra o subgrafo formado por 61 nodos com grau m´ınimo 100 no grafo original, selecionados com a estratégia GM. Observa-se que os nodos formaram dois grupos desconexos. O grafo utilizado para selecionar os nodos mostrados na figura corresponde a um per´ıodo de uma hora, de 00:00:00 do dia 9 de Fevereiro de 2011 até 00:59:59 do mesmo dia e limiar 0.05s. Os números nos nodos são identificadores usados internamente pela ferramenta.

Figura 4.1: 61 nodos com grau m´ınimo 100 no grafo original.

(31)

4.2.2 Maior Grau M´ınimo

A estratégia do Maior Grau M´ınimo (M GM) consiste em encontrar o maior grau m´ınimo poss´ıvel que, aplicando a estratégiaGM, resulte em uma quantidade m´ınima desejada de nodos. Assim, o parâmetro desta estratégia é o número m´ınimo de nodos. Em outras palavras, esta estratégia seleciona um grupo de nodos, com tamanho m´ınimo especificado, cujo grau m´ınimo no grafo é o maior poss´ıvel.

Para encontrar o maior grau m´ınimo que resulte em um grupo de nodos com um tamanho m´ınimo desejado, é executada uma busca binária. Esta busca binária inicia com um valor de grau m´ınimo igual a metade do total de nodos. Para testar cada valor de grau m´ınimo percorrido durante a busca, são selecionados nodos com o uso da estratégia GM, ou seja, seleciona-se nodos com grau igual ou maior ao valor em questão. Então verifica-se se a quantidade de nodos selecionados é maior ou igual à quantidade m´ınima de nodos desejada. A busca binária é orientada pelo resultado destes testes. No fim da busca, tem-se o maior grau m´ınimo que resultou em um grupo de nodos com tamanho maior ou igual ao tamanho desejado.

A figura 4.2 mostra o subgrafo formado por 100 nodos selecionados com a estratégia M GM. O grau m´ınimo dos nodos selecionados, no grafo original, foi de 85. Observa-se que os nodos formaram dois grupos desconexos. O grafo usado para esta sele¸cão é o mesmo da figura 4.1.

Figura 4.2: 100 nodos selecionados com a estrat´egia M GM.

(32)

4.2.3 Subgrafo com Grau M´ınimo

O objetivo da estratétia do Subgrafo com Grau M´ınimo (SGM) é encontrar um subgrafo com o grau m´ınimo desejado, ou seja, um grupo de nodos com um grau m´ınimo entre eles. O parâmetro desta estratégia, portanto, é o grau m´ınimo. Esta estratégia é mais restritiva que apenas filtrar os nodos pelo grau, como nas estratégias GM e M GM, pois os nodos selecionados tem um grau m´ınimo no subgrafo formado por eles. Mas não é tão restritiva quanto uma clique, em que o grau de todos os nodos é o maior poss´ıvel dentro do grupo.

Para encontrar um subgrafo com um grau m´ınimo desejado, os nodos são filtrados sucessivamente pelo seu grau, utilizando a estratégiaGM, até que se tenha um grupo de nodos com o grau m´ınimo desejado entre eles. Come¸cando com o grafo inteiro, filtra-se os nodos pelo grau m´ınimo, resultando em um subgrafo. Os nodos deste subgrafo são filtrados novamente pelo grau m´ınimo. Este processo repete-se até que o grau m´ınimo do subgrafo seja igual ou maior ao grau m´ınimo desejado, ou até que seja imposs´ıvel encontrar tal grupo (número de nodos no subgrafo menor ou igual ao grau m´ınimo desejado). Desta forma, obtém-se o maior grupo de nodos cujo subgrafo formado por eles tem o grau m´ınimo especificado.

A figura 4.3 mostra o subgrafo selecionado com grau m´ınimo 44, cujo tamanho foi de 137 nodos. Observa-se que neste caso os nodos formaram dois grupos desconexos, mesmo com a restri¸cão do grau m´ınimo entre os nodos selecionados. O grafo usado para esta sele¸cão é o mesmo da figura 4.1.

(33)

Figura 4.3: Subgrafo de 137 nodos com grau m´ınimo 44 entre eles

4.2.4 Subgrafo com Maior Grau M´ınimo

A estratégia do Subgrafo com Maior Grau M´ınimo (SM GM) consiste em encontrar o maior grau m´ınimo poss´ıvel que, aplicando a estratégia doSGM, resulte em uma quantidade m´ınima desejada de nodos. Assim, o parâmetro desta estratégia é o número m´ınimo de nodos. Em outras palavras, o objetivo desta estratégia é selecionar um grupo de nodos, com tamanho m´ınimo especificado, cujo grau m´ınimo dentro do grupo é o maior poss´ıvel.

Para encontrar o subgrafo com o maior grau m´ınimo, que contenha o número m´ınimo de nodos desejado, é feita uma busca binária análoga a feita na estratégia M GM para encontrar o maior grau m´ınimo que resulte em um grupo com um tamanho m´ınimo desejado.

A figura 4.4 mostra 62 nodos selecionados com a estrat´egia doSM GM. O grau m´ınimo do subgrafo foi de 45, ou seja, os 62 nodos selecionados tem grau m´ınimo 45 entre eles.

O grafo usado para esta sele¸c˜ao ´e o mesmo da figura 4.1.

(34)

Figura 4.4: 62 nodos com grau m´ınimo 45 entre eles.

4.2.5 Clique Est´ avel

A estrat´egia da Clique Est´avel (CE) consiste em encontrar uma clique [13] - um subgrafo completo - no grafo que representa o sistema, ou seja, existe uma aresta entre todos os pares de nodos selecionados.

O problema da busca de cliques ´e exponencial e pertence `a categoria NP-dif´ıcil [16].

Assim, encontrar a maior clique em grafos com um grande número de arestas como no caso dos grafos gerados pela ferramenta desenvolvida é inviável, pois uma ferramenta online para selecionar nodos para um experimento deve retornar rapidamente os nodos

(35)

selecionados. Para contornar o problema, a estrat´egia CE necessita de dois parˆametros:

o tamanho m´ınimo da clique desejada, e o tempo máximo de execu¸cão da busca. O procedimento de busca de cliques é executado até que uma clique com tamanho igual ou maior que o paramêtro seja encontrada. Além disto, caso tal clique não seja encontrada no limite de tempo especificado, a maior clique encontrada até então é selecionada.

Esta estratégia é a que seleciona o menor número de nodos, pois é bastante restritiva:

uma aresta deve existir entre todos os pares de nodos selecionados. Porém, esta caracter´ıstica significa que qualquer dos nodos selecionados comunicou-se de forma considerada estável com qualquer um dos outros nodos durante o per´ıodo informado na cria¸cão do grafo, o que pode ser importante, dependendo do experimento a ser realizado. A figura 4.5 mostra uma clique de 30 nodos. O grafo usado para esta sele¸cão é o mesmo da figura 4.1.

Figura 4.5: Clique de 30 nodos selecionada.

(36)

4.3 Implementa¸ c˜ ao da Ferramenta

Foi criada uma ferramenta que implementa a estratégia de monitoramento e as estratégias de sele¸cão de nodos descritas na se¸cão anterior. A ferramenta foi escrita inteiramente na linguagem de programa¸cão Python [6] e foi dividida em 3 módulos: monitoramento, servidor e cliente. O módulo de monitoramento é responsável por monitorar o RTT entre cada par de nodos do PlanetLab, enviando todos os dados para o módulo servidor. O módulo servidor é responsável por armazenar e sumarizar os dados, além de gerar grafos a partir destes dados, conforme solicitado pelo módulo cliente. O módulo cliente requisita grafos do módulo servidor, e a partir destes grafos faz a sele¸cão de nodos. Cada um destes módulos é descrito nas próximas subse¸cões.

A figura 4.6 mostra a organiza¸cão em módulos da ferramenta implementada. O módulo monitor está presente em cada nodo do PlanetLab. Os nodos enviam os dados do monitoramento para o servidor, que utiliza-os para gerar os grafos requisitados pelo cliente.

Utilizando o grafo gerado pelo servidor, o cliente seleciona os nodos conforme solicitado pelo usu´ario.

PlanetLab

Dados de Monitoramento

Nodos Selecionados

Requisição Grafo

Servidor

Figura 4.6: M´odulos da ferramenta implementada.

(37)

4.3.1 M´ odulo de Monitoramento

O módulo de monitoramento é constitu´ıdo de um daemon executado em cada um dos nodos do PlanetLab. Estedaemon é responsável por: enviar mensagens a todos os nodos e receber as respostas; e responder as mensagens enviadas por outros nodos.

Periodicamente, o daemon presente em cada nodo envia uma mensagem para cada outro nodo, por meio de um socket UDP, guardando a hora de envio de cada mensagem.

Chamamos o per´ıodo de envio destas mensagens de intervalo de medi¸cão. Conforme o daemon aguarda o intervalo de medi¸cão para enviar mensagens novamente, ele recebe as respostas referentes as mensagens recém enviadas, calculando e armazenando o tempo de resposta (RTT) de cada uma. Um timeout foi empregado para estas respostas, de forma que se alguma resposta demorar mais que o valor do timeout para chegar, ou não chegar antes do daemon enviar mensagens novamente, o valor do RTT para aquela mensagem é contabilizado com o valor dotimeout. Após o término do intervalo de medi¸cão, todos os valores de RTT são enviados ao servidor de uma só vez por meio de um socket TCP (Transmission Control Protocol). Após isto, odaemon envia mensagens para todos os nodos novamente.

Uma caracter´ıstica desta implementa¸cão é que, como já dito na se¸cão 4.1, o RTT

é medido na camada de aplica¸cão, por isso o seu valor pode variar não apenas pelas condi¸cões da rede, mas também pelas condi¸cões do próprio nodo, como a quantidade de processos na fila do escalonador, uso de CPU, entre outros. Caso odaemon demore para ser escalonado, por exemplo, a resposta para uma mensagem vinda de outro nodo pode demorar mais para ser enviada, resultando em um RTT maior.

4.3.2 M´ odulo Servidor

O módulo servidor consiste em um daemon executado em uma máquina qualquer - que aceite conexões vindas da Internet - e de um banco de dados. O banco de dados utilizado foi o PostgreSQL [5], versão 8.4.4. O daemon é responsável por: receber e armazenar os dados dos nodos, sumarizar os dados e responder requisi¸cões do módulo cliente.

Para receber os dados dos nodos ´e utilizado um socket TCP para esperar por conex˜oes

(38)

vindas dos nodos. Quando uma conexão é feita, os dados recebidos são adicionados em uma fila, para serem inseridos no banco de dados assim que poss´ıvel. Além de armazenar os dados de monitoramento, o servidor sumariza as amostras permitindo que um longo histórico permane¸ca armazenado. De hora em hora, odaemon sumariza os dados referentes à antepenúltima hora, e verifica se o dia, mês ou ano mudaram, para também sumarizar o antepenúltimo dia, mês ou ano, conforme necessário. A sumariza¸cão consiste em calcular a média, desvio padrão da média, valor m´ınimo e máximo de todos os valores de RTT dentro per´ıodo sendo sumarizado. Este conjunto de dados é armazenado, e os valores originais são apagados. Desta forma, o per´ıodo sumarizado passa a ser representado por este conjunto de dados. Portanto, ao sumarizar o per´ıodo de um ano, por exemplo, serão utilizados 12 conjuntos de dados, um para cada mês. Cada mês foi sumarizado a partir de conjuntos de dados representando cada dia do mês (um para cada dia). Da mesma forma, cada dia foi anteriormente sumarizado a partir de 24 conjuntos de dados, um para cada hora. Cada hora foi sumarizada a partir dos valores crus de RTT armazenados durante o per´ıodo correspondente aquela hora.

Para tratar as requisi¸cões feitas pelo módulo cliente, é utilizado um socket TCP para recebê-las. Uma requisi¸cão é composta de um per´ıodo de tempo - expresso por 2 números representando come¸co e final, no formatoUnix Time - e o limiar do RTT em segundos. A partir destes parâmetros é feita uma consulta no banco de dados, que retorna, para cada par de nodos, a quantidade de valores de RTT (ou média, no caso de dados sumarizados) dentro daquele per´ıodo, e a quantidade de valores de RTT que são menores ou iguais ao limiar dentro do per´ıodo. Para cada par de nodos (a, b), caso pelo menos 90% dos valores de RTT dea parab sejam menores ou iguais ao limiar, e deb paraa também, uma aresta existe entreaeb. Este procedimento gera uma lista de arestas, que é retornada ao módulo cliente, caracterizando o grafo requisitado pelo mesmo.

4.3.3 M´ odulo Cliente

O módulo cliente é responsável por requisitar grafos ao servidor e a partir dos grafos requisitados selecionar nodos conforme as estratégias de sele¸cão descritas na se¸cão 4.2. Uma

(39)

interface Web para o módulo cliente foi desenvolvida para facilitar o uso da ferramenta e torná-la dispon´ıvel para uso público. A sa´ıda deste módulo é a lista de nodos selecionados.

Também são disponibilizados para o usuário os grafos gerados, sem nenhuma sele¸cão de nodos.

A figura 4.7 mostra a interface Web desenvolvida. Na caixa superior esquerda, o usu´ario seleciona qual grafo deseja usar na sele¸c˜ao de nodos. Um grafo correspondente

à hora anterior está sempre dispon´ıvel. Na mesma caixa também é poss´ıvel requisitar outro grafo ao servidor, informando o limiar e o per´ıodo de tempo desejados. Na caixa superior direita o usuário informa os parâmetros para a sele¸cão de nodos: número m´ınimo de nodos, estratégia de sele¸cão, grau - caso necessário - e se deseja que uma imagem do subgrafo formado pelos nodos selecionados seja gerada. O resultado da sele¸cão de nodos

é apresentado ao usuário na caixa inferior esquerda. A caixa inferior direita contém instru¸cões de uso da interface Web. No rodapé há um link para uma página contendo uma lista de todos os nodos, com o estado de cada um: online, offline ou imposs´ıvel acessar. As informa¸cões desta página são atualizadas a cada 3 horas.

Figura 4.7: Interface Web.

Para fazer uma requisi¸cão são necessários dois paramêtros: per´ıodo e limiar. O per´ıodo

´e expresso por dois valores correspondentes ao inicio e ao fim do per´ıodo desejado, no

(40)

formato Unix Time. O limiar é expresso por um número real, em segundos. Após enviar a requisi¸cão ao servidor, o cliente aguarda até receber os dados que correpondem ao grafo requisitado.

A partir do grafo requisitado, é poss´ıvel selecionar nodos com qualquer uma das es- tratégias definidas. Estas estratégias, assim como todas as opera¸cões de grafos, foram implementadas com o uso da biblioteca NetworkX [2].

(41)

CAP´ ITULO 5

RESULTADOS EXPERIMENTAIS

Este cap´ıtulo descreve os resultados experimentais obtidos com a ferramenta desenvolvida.

O ambiente dos experimentos é o PlanetLab, Quando os experimentos foram executados, o PlanetLab era composto por cerca de 1036 nodos em cerca de 578 locais ao redor do mundo. Os nodos sãohosts TCP/IP que comunicam-se por meio da Internet. Cada nodo é gerenciado por uma organiza¸cão autônoma, as quais são filiadas ao PlanetLab. Diferentes nodos apresentam capacidades e ambientes diferentes. Além disso, não há reserva de tempo de processamento, os usuários utilizam os nodos simultaneamente, competindo pelos recursos, resultando em um ambiente de grande instabilidade.

Para a execu¸cão dos experimentos fizemos questão de monitorar todos os nodos do PlanetLab, que no in´ıcio do desenvolvimento deste trabalho eram 1036. Uma lista destes nodos, ordenados pelos seus respectivos identificadores internos a ferramenta, pode ser encontrada no apêndice A. Surpreendentemente, o número de nodos que efetivamente executou o experimento, ficou, em um instante qualquer, entre 600 e 700 nodos. Isto ocorreu pois um grande número de nodos alterna entre online e offline e alguns outros não foi sequer poss´ıvel acessar em nenhum momento. A cada 3 horas, um script tentava instalar odaemon responsável pelo monitoramento em todos os nodos que não estavam a executá-lo. Em todos os experimentos descritos neste cap´ıtulo, o intervalo de medi¸cão do RTT foi de 5 minutos e otimeout de recebimento da resposta de uma mensagem entre os nodos foi de 10 segundos.

Três grupos de experimentos foram realizados. Um destes grupos consistiu em uma análise de grafos obtidos durante 3 semanas de monitoramento no PlanetLab e das es- tratégias de sele¸cão aplicadas nestes grafos. Outro grupo de experimentos consistiu em uma compara¸cão da ferramenta criada com outra ferramenta de sele¸cão de nodos já existente, por meio da execu¸cão de uma aplica¸cão MapReduce em nodos selecionados com

(42)

ambas as ferramentas. O terceiro grupo de experimentos consistiu em comparar os grafos obtidos a partir dos dados n˜ao sumarizados com os grafos obtidos a partir dos dados sumarizados.

Este cap´ıtulo está organizado da seguinte maneira. A se¸cão 5.1 descreve a análise dos grafos obtidos a partir do monitoramento e das estatégias de sele¸cão de nodos. A se¸cão 5.2 descreve os experimentos com o MapReduce, que teve como objetivo comparar a ferramenta criada com outra ferramenta de sele¸cão de nodos já existente, o SWORD.

A se¸c˜ao 5.3 descreve os resultados dos experimentos com dados sumarizados.

5.1 An´ alise dos Grafos Obtidos e Estrat´ egias de Sele¸ c˜ ao

O per´ıodo de monitoramento deste experimento iniciou no dia 26 de janeiro de 2011, e terminou no dia 20 de mar¸co de 2011. A partir dos dados de monitoramento armazenados no servidor no decorrer deste per´ıodo, foram gerados grafos de hora em hora, das 00:00 de 30 de janeiro de 2011, domingo, até as 23:59 de 19 de fevereiro de 2011, sábado, totalizando 21 dias, 3 semanas completas. Como foram gerados a cada hora, foram usados os dados sem nenhuma sumariza¸cão. Os limiares usados na gera¸cão dos grafos foram 0.05ms, 0.1ms, 0.15ms e 0.2ms, portanto 4 grafos por hora, totalizando 2016 grafos.

N˜ao foram utilizados limiares com valores maiores, pois estes resultam em grafos com uma quantidade extremamente grande de arestas. Assim, mesmo nodos que n˜ao apresentam as caracter´ısticas desejadas acabam tendo um grau alto nos grafos gerados.

A partir dos grafos gerados, vários resultados foram obtidos. Foram analisadas algumas caracter´ısticas dos grafos em si, sem nenhuma sele¸cão de nodos. Além disso, as estratégias de sele¸cão descritas no cap´ıtulo 4 foram aplicadas aos grafos a fim de observar suas caracter´ısticas e seu comportamento no decorrer do tempo e com o aumento do limiar. Assim, foi poss´ıvel comparar as diferentes estratégias de sele¸cão.

Foram calculados os graus médio e máximo de todos os grafos gerados no experimento, sem nenhuma sele¸cão, a fim de observar o comportamento destas caracter´ısticas ao longo do tempo. A figura 5.1 mostra a varia¸cão do grau médio e grau máximo nos grafos gerados para todo o per´ıodo de 21 dias. Cada gráfico mostra a varia¸cão para um limiar diferente.

(43)

O eixo vertical indica o grau e o horizontal o per´ıodo. Observa-se que as curvas mantém o mesmo padrão para todos os limiares, apenas com valores maiores, como esperado. No gráfico referente ao limiar de 0.1s, por exemplo, o grau médio ficou entre 50 e 60 em grande parte do per´ıodo. Já o grau máximo teve uma varia¸cão maior, ficando entre 200 e 250 em quase todo o per´ıodo.

0 20 40 60 80 100 120 140 160 180

29/01 00:00 31/01 00:00 02/02 00:00 04/02 00:00 06/02 00:00 08/02 00:00 10/02 00:00 12/02 00:00 14/02 00:00 16/02 00:00 18/02 00:00 20/02 00:00 Grau medio e Grau Maximo, Limiar 0.05

Grau medio Grau maximo

0 50 100 150 200 250

29/01 00:0031/01 00:0002/02 00:0004/02 00:0006/02 00:0008/02 00:0010/02 00:0012/02 00:0014/02 00:0016/02 00:0018/02 00:0020/02 00:0022/02 00:00 Grau medio e Grau Maximo, Limiar 0.1

50 100 150 200 250 300 350 400

100 150 200 250 300 350 400 450 500

Figura 5.1: Grau m´edio e m´aximo de hora em hora durante 3 semanas.

A figura 5.2 mostra a varia¸cão do grau médio e máximo no decorrer de apenas um dia do per´ıodo mostrado na figura 5.1, para cada um dos limiares. No limiar de 0.05s, o grau médio ficou entre 20 e 30 e o grau máximo entre 130 e 150. No limiar de 0.1s, o grau médio ficou entre 60 e 70 e o grau máximo entre 220 e 240, em quase todo o per´ıodo.

No limiar de 0.15s, o grau médio ficou entre 100 e 110 em quase todo o per´ıodo e o grau máximo ficou entre 350 e 380. No limiar de 0.2s, o grau médio variou de 140 a 150 na maior parte do per´ıodo e o grau máximo de 440 a 450.

A tabela 5.1 mostra a média e o desvio padrão da média do grau médio e grau máximo no per´ıodo todo, para cada limiar. Observa-se que o desvio padrão da média em cada