MAC0499 - Trabalho de Formatura Supervisionado

Projeto de Iniciação Científica^{∗}

Suporte para Aplicações com Conhecimento da Rede através de

Pesquisa por Pacotes

Aluno: Daniel de Angelis Cordeiro Orientador: Prof. Alfredo Goldman vel Lejbman

             {danielc,gold}@ime.usp.br

7 de dezembro de 2003

O objetivo deste trabalho é pesquisar formas de obtenção do estado da rede de forma dinâmica, isto é, queremos obter as características do ambiente de rede onde o sistema se encontra. O foco desta pesquisa são ambientes de grade computacional (grid computing) que são, de forma simplificada, um conjunto de recursos computacionais (aglomerados de PCs e supercomputadores) interconectados.

A análise de sistemas de grade computacional tradicionais nos mostra que a rede não é considerada um recurso para as tarefas da grade. Descobrimos também que sistemas de sondagem especializados produzem resultados mais precisos, mas não são adequados para o ambiente de grade computacional que é formado, tipicamente, por um sistema heterogêneo.

∗Este projeto é fomentado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq

Proc. No. 55.2028/02-9)

Sumário  Sumário

Sistemas de sondagem por pacotes resolvem o problema da heterogeneidade da rede, mas esbarram no problema dos equipamentos de rede que não dão suporte a camada três (TCP/IP) de rede. Podemos utilizar o protocolo ICMP para resolver o problema, mas equipamentos de rede tratam pacotes ICMP e IP de maneiras diferentes, o que produz um resultado que não é preciso.

Sumário

I. Projeto de Iniciação Científica 3

1. Introdução 3

2. Objetivo 4

3. Trabalhos Relacionados 4

3.1. Sistemas de Grade Computacionais . . . . . . . . . . . . . . . . . 5 3.1.1. Legion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. OurGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2. Sistemas Especializados . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. ReMoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3. Pesquisa por Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Pesquisa Ativa e Passiva . . . . . . . . . . . . . . . . . . . 10 3.3.2. Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3. Dispersão de Pacotes . . . . . . . . . . . . . . . . . . . . . 11 3.3.4. Pacotes de Tamanhos Variados . . . . . . . . . . . . . . . 12 3.3.5. Roteamento e Topologia . . . . . . . . . . . . . . . . . . . 12

4. Ferramentas de Pesquisa por Pacotes 13 4.1. pathchar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. netperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. netest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. nettimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. igi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1 INTRODUÇÃO

5. Atividades Realizadas 16 6. Conclusão 16

II. Experiência Pessoal 18

7. Desafios e Frustrações 18 8. Disciplinas do BCC mais relevantes 19 9. Integração com os membros do InteGrade 19 10. Trabalhos futuros 20 11. Conclusões finais 20 12. Agradecimentos 21

Parte I.

Projeto de Iniciação Científica

1. Introdução

Atualmente, nota-se um aumento no interesse [6] por grades computacionais que são, de forma simplificada, um conjunto de recursos computacionais (aglomerados de PCs e supercomputadores) interconectados. A possibilidade de tal infra-estrutura nos leva a ampliar os horizontes para novos tipos de aplicações de alto desempenho que utilizem recursos da grade de forma eficiente. Para isso, é necessário possibilitar a programação paralela no ambiente distribuído de uma grade computacional. O projeto InteGrade [1], que está sendo desenvolvido no Instituto de Matemática e Estatística da USP, e no qual este trabalho está inserido, visa construir essa infra-estrutura genérica de middleware que permitirá a criação de uma grade computacional que integrará

3 TRABALHOS RELACIONADOS

os recursos computacionais disponíveis em máquinas ociosas em um ambiente de execução unificado.

Para que essa infra-estrutura fornecida pelo InteGrade seja apropriada para programação paralela é necessário que a integração dos recursos computacionais disponíveis leve em conta o ambiente de rede disponível, de forma a minimizar o efeito da troca de mensagens realizadas no desempenho das aplicações paralelas. É necessário, portanto, que o InteGrade seja uma aplicação que consiga obter, de forma dinâmica, informações sobre a rede em que se encontra.

O restante deste trabalho é dividido como segue. A seção 2 explicita os objetivos deste trabalho. A seção 3 descreve os trabalhos relacionados estudados durante esta iniciação científica, enquanto que as atividades realizadas são descritas na seção 5. As conclusões são discutidas na seção 6.

2. Objetivo

O objetivo deste trabalho é pesquisar formas de obtenção do estado da rede de forma dinâmica. Queremos poder estimar as características da rede onde se encontram os recursos computacionais que serão integrados pelo InteGrade. Para tanto, é necessário desenvolver um método de inferência dos recursos da rede de forma não intrusiva, ou seja, que consuma pouca banda e que não necessite de alterações de baixo nível (alterações no sistema operacional, por exemplo) nos nós que compõem a grade.

3. Trabalhos Relacionados

Há três categorias de sistemas relacionados a este trabalho. Em um âmbito mais geral, todos os sistemas de grade computacional conhecidos estão relacionados com o projeto InteGrade e, conseqüentemente, com este trabalho. No âmbito de sondagem de rede, podemos classificar os sistemas existentes em dois tipos: sistemas especializados, ou seja, sistemas que dependem de características específicas de rede em que se encontram e sistemas de pesquisa de rede por pacotes, isto é, que não necessitam de nenhum conhecimento sobre o tipo de rede em que se encontram.

3.1 Sistemas de Grade Computacionais  3 TRABALHOS RELACIONADOS

Os sistemas de grade computacionais estudados serão descritos na seção 3.1, os sistemas especializados de sondagem estudados serão descritos em 3.2 e os sistemas de pesquisa por pacotes estudados serão descritos na seção 3.3.

3.1. Sistemas de Grade Computacionais

O padrão Grade [8] define uma grade computacional como um middleware que integra recursos distribuídos de modo a criar um ambiente de execução unificado para as aplicações. Uma grade computacional permite o compartilhamento de recursos de hardware e software em sistemas distribuídos e heterogêneos, viabilizando, assim, a execução de aplicações que fazem uso intensivo de computação.

Diversos sistemas de grade computacional estão sendo desenvolvidos. Como exemplos, podemos citar os sistemas Globus, Legion, Condor, BOINC e os brasileiros OurGrid, Brazilian National Computation Grid, GridRio e InteGrade, entre tantos outros projetos. Dois sistemas de grade computacional foram estudados neste trabalho e serão descritos a seguir: Legion e OurGrid.

3.1.1. Legion

Legion [5] é um sistema de grade computacional que foi desenvolvido pela Universidade de Virginia. Um dos pioneiros em computação em grade, o desenvolvimento do Legion começou em 1993. Em 2001, seus idealizadores fundaram a Avaki, uma empresa que atualmente desenvolve e comercializa sistemas que utilizam a tecnologia do Legion.

O Legion foi desenvolvido utilizando-se o paradigma de orientação a objetos. Em Legion, todos os elementos da Grade são representados por objetos, sejam eles dados ou objetos reais, tais como microscópios, telescópios e outros equipamentos. Alguns dos objetivos da arquitetura são os seguintes:

• autonomia para diferentes domínios: cada domínio administrativo, isto é, cada conjunto de recursos computacionais aglomerados em uma única unidade administrativa, pode especificar como seus recursos podem ser utilizados. Legion não impõe nenhuma política aos usuários;

• núcleo extensível: a arquitetura de Legion permite que partes do sistema sejam trocadas ou aprimoradas conforme as necessidades dos usuários; • arquitetura escalável: o sistema é totalmente distribuído de modo a permitir grande

escalabilidade;

• ambiente de computação homogêneo: a grade deve esconder as diferentes plataformas sobre as quais está executando;

• espaço de nomes único e persistente;

• aproveitamento de recursos heterogêneos: em algumas situações, pode ser conveniente executar uma aplicação em uma máquina mais adequada;

• suporte a múltiplas linguagens e interoperabilidade;

• tolerância a falhas;

• executar com poucos privilégios, ou seja, não deve exigir nenhum tipo de privilégio de super-usuário.

O Legion se destaca pela sua preocupação com o suporte à aplicações paralelas. O Legion possui uma implementação das bibliotecas MPI (Message Passing Interface) e PVM (Parallel Virtual Machine). Para utilizar um programa escrito em MPI ou PVM no Legion basta recompilá-lo utilizando as bibliotecas fornecidas pelo Legion. Isso permite que a migração da infra-estrutura antiga para a infra-estrutura do Legion seja praticamente instantânea.

Além das bibliotecas, Legion fornece suporte nativo a algumas linguagens de programação paralela. É possível utilizar as linguagens MPL (Mentat Programming Language, uma extensão de C++ para programação paralela), BFS (Basic Fortran Support) e Java.

Por fim, aplicações legadas que não utilizem nenhuma das bibliotecas ou linguagens acima podem ser encapsuladas dentro de objetos Legion. Basta o usuário registrar o programa legado com o comando legion_register_program e o sistema constrói um objeto Legion que encapsula o programa legado e, automaticamente, ele se torna elegível para ser executado pelo sistema. Isso garante que qualquer programa possa ser executado no ambiente do Legion. Se o programa realizar algum tipo de comunicação, basta que o programador escreva um adaptador para o programa legado que converta as chamadas a biblioteca de comunicação à chamadas a métodos de comunicação do Legion.

3.1.2. OurGrid

3.2 Sistemas Especializados  3 TRABALHOS RELACIONADOS

OurGrid [4] é um projeto de grade computacional desenvolvido em conjunto pela Universidade Federal de Campina Grande e Hewlett-Packard (HP). O objetivo do OurGrid é pesquisar e desenvolver soluções para uso e gerenciamento de grades computacionais. O projeto OurGrid é fundamentado no projeto MyGrid, desenvolvido também na Universidade Federal de Campina Grande, que propôs e desenvolveu uma implementação de um sistema de grade computacional. O MyGrid é um sistema de grade computacional para aplicações do tipo Bag-of-Tasks, ou seja, para aplicações que sejam compostas por uma seqüência de tarefas independentes entre si. Um dos objetivos do projeto MyGrid é a simplicidade. Seus idealizadores acreditam que um sistema de grade que seja simples de usar é o que os desenvolvedores de aplicações de alto desempenho precisam hoje. Essa simplicidade se reflete tanto na arquitetura do sistema quanto em seu uso. Para utilizar a infra-estrutura do MyGrid, o desenvolvedor necessita apenas informar quais as informações de entrada de cada tarefa e onde as informações de saída serão armazenadas. Não é necessário utilizar nenhuma biblioteca específica nem se preocupar com questões como o escalonamento das tarefas ou configuração do sistema de grade. Surpreendentemente, não é necessário instalar nenhum programa nos computadores que formarão a rede. É necessário apenas que o usuário tenha algum tipo de acesso remoto como, por exemplo, via SSH (Secure SHell), aos outros nós que compõe a grade. A arquitetura do MyGrid também é muito simples. Há apenas um escalonador centralizado para todos os nós que compõem a grade. Toda tarefa a ser executada na grade deve ser enviada para este escalonador que, após analisar a carga de trabalho em todos os nós da grade, decidirá qual nó executará cada tarefa. Está prevista na arquitetura do MyGrid a capacidade de interoperabilidade com outros sistemas de grade computacional. Um protótipo de integração com o sistema Globus já está sendo desenvolvido pela equipe do MyGrid. O sistema Legion permite a execução de programas paralelos que necessitem comunicação entre nós. O OurGrid só permite que problemas embaraçosamente paralelizáveis sejam executados, devido ao modelo de aplicações Bag-of-Tasks utilizado. Porém, o sistema Legion requer que o usuário especifique os nós em que as tarefas serão executadas, ao contrário do OurGrid, que possui um escalonador que define esses nós dinamicamente. O projeto InteGrade visa fornecer suporte para todos os tipos de programas paralelos, atribuindo cada tarefa a um nó da grade de forma dinâmica. Com o uso de sistemas de sondagem de rede, o sistema de escalonamento de tarefas poderá distribuir as tarefas entre nós próximos, diminuindo os efeitos da degradação de desempenho decorrentes da comunicação entre nós.

3.2. Sistemas Especializados

Chamamos de sistemas de sondagem especializados aqueles que necessitam conhecer alguma característica específica da rede onde o sistema se encontra. Este trabalho analisou dois sistemas de sondagem especializados: SNMP e ReMoS.

3.2.1. SNMP

- O Simple Network Management Protocol [7] (SNMP), foi desenvolvido por volta de 1998 e, desde então, tornou-se o padrão de gerenciamento de redes “de facto” da indústria. O SNMP prima por sua simplicidade e flexibilidade. Implementar um agente SNMP em um produto requer muito pouco código e adicionar novas funcionalidades de gerenciamento de rede às existentes requer pouco esforço. Outra característica que tornou o SNMP popular é que a implementação da camada de gerenciamento é independente da implementação da camada de hardware, o que permite mesclar a implementação de múltiplos fornecedores.

SNMP contém dois tipos de elementos primários: gerentes (managers) e agentes (agents). Os gerentes são as interfaces pelas quais o administrador de rede realiza suas tarefas de gerenciamento. Agentes são entidades que fornecem a interface com o dispositivo que está sendo gerenciado. Bridges, hubs e roteadores são exemplos de dispositivos gerenciáveis pelo SNMP. Estes dispositivos contém o que SNMP denomina de “objetos gerenciáveis”. Os objetos gerenciáveis são características que estão relacionadas com a operação do dispositivo, como parâmetros de configuração, estatísticas de desempenho, hardware, etc. Esses objetos são agrupados em banco de dados virtual de informações sobre a rede, chamado MIB (management information base). SNMP permite que gerentes e agentes se comuniquem para permitir o acesso a esses objetos.

Um agente, tipicamente:

• armazena e obtém dados de gerenciamento definidos no MIB; • notifica, de forma assíncrona, um gerente sobre a ocorrência de um evento;

• serve de proxy para um dispositivo de rede que não suporta SNMP.

Um gerente, tipicamente:

• requisita informações sobre o os objetos disponibilizados por cada agente;

• são notificados, pelos agentes, da ocorrência de eventos;

• define variáveis de configuração dos agentes.

A comunicação entre agentes e gerentes SNMP não é orientada a conexão. Em outras palavras, não há conexão pré-estabelecida entre o agente e o gerente antes da transmissão de dados ser realizada. Em conseqüência disso, SNMP não oferece nenhuma garantia sobre o envio dos dados. A comunicação é realizada utilizando-se UDP (User Datagram Protocol) e IP (Internet Protocol).

A desvantagem de utilizar o SNMP como sistema de obtenção de recursos de rede por um sistema de grade computacional é que nem todos os dispositivos de redes possuem agem como agentes SNMP. Muitas vezes o dispositivo não provê suporte a SNMP ou o administrador do sistema desativou o suporte por motivos de segurança. Isso faz com que SNMP não seja uma opção genérica para sistemas de sondagem de rede.

3.2.2. ReMoS

O Remos [3] (REsource MOnitoring System ou sistema de monitoramento de recursos) foi desenvolvido na Carnegie Mellon University e permite que aplicações obtenham informações relevantes sobre o ambiente de rede onde se encontram.

O Remos possui uma interface que disponibiliza as informações sobre o ambiente de rede de forma independente da tecnologia utilizada pela rede. Dessa forma, aplicações que utilizem o Remos podem se adaptar ao ambiente de execução ainda que este seja composto por redes que utilizem diferentes tecnologias.

3.3 Pesquisa por Pacotes  3 TRABALHOS RELACIONADOS

As informações disponibilizadas pelo Remos são independentes da tecnologia utilizada. Isso significa que, apesar da aplicação utilizar informações coletadas pelo Remos, essas informações são independentes da tecnologia de rede utilizada. Dessa forma, a mesma aplicação poderá ser executada em uma rede que utilize outra tecnologia sem necessidade de mudanças no código-fonte da aplicação.

Outra característica interessante do Remos é sua capacidade de previsão. Os dados coletados durante a execução do Remos são armazenados para referência futura. Aplicações que utilizam o Remos podem obter informações sobre um estado passado. Por exemplo, é possível obter informações sobre o estado da rede há três horas atrás. O sistema Remos possui uma heurística de predição de estado. Um programa pode pedir para o sistema prever como estará a rede daqui a dez minutos, por exemplo, e o Remos utilizará os dados coletados para realizar a previsão.

Há duas formas de obtenção de dados no Remos. A primeira é uma pesquisa de alto nível, denominada flow-based queries, que permite que consultas sobre largura de banda e latência sejam realizadas. A segunda forma de obtenção de dados são as pesquisas de baixo nível, denominada no Remos por logical network topology, que permitem que pesquisas sobre a topologia de rede sejam realizadas. No Remos, a topologia de rede é representada por um grafo onde os vértices são os nós da rede e as arestas representam os custos de comunicação entre os dois nós interligados pela aresta.

A implementação do Remos utiliza o protocolo de gerenciamento de rede SNMP, descrito na seção 3.2.1.

3.3. Pesquisa por Pacotes

Os sistemas de pesquisa por pacotes (packet-probing) são aqueles que utilizam apenas troca de mensagens para inferir características da rede. Isso possibilita usar o mesmo sistema independentemente da tecnologia de rede utilizada, ao contrário dos sistemas especializados vistos na seção 3.2.

A seguir, apresentaremos diferentes técnicas de pesquisa por pacotes, conforme classificadas por Schoonderwoerd [9].

3.3.1. Pesquisa Ativa e Passiva

As várias técnicas usadas por sistemas de pesquisa por pacotes podem ser separadas em duas categorias: pesquisa ativa e pesquisa passiva. Pesquisa ativa significa que o sistema enviará, ativamente, pacotes de sondagem pela rede. Já os sistemas de pesquisa passiva, monitoram o tráfego de rede, sem nenhum tipo de interferência.

Sistemas de pesquisa ativa podem ser tanto de “apenas-envio” (one-way) ou “envio-e-resposta” (two-way). Programas como ping são do tipo de pesquisa de apenas-envio. O ping envia uma mensagem e espera por uma resposta automática, utilizando ICMP e UDP ou TCP. Sistemas de envio-e-resposta utilizam uma arquitetura cliente-servidor. O cliente envia um pacote de sondagem ao servidor, que executa alguns cálculos e responde ou apenas reenvia os dados recebidos ao cliente.

Pesquisa passiva é considerado um método menos confiável do que pesquisa ativa. Alguns pesquisadores afirmam que não é possível extrair nenhum dado útil do monitoramento da rede. Entretanto, há diversos esforços de utilização de pesquisa passiva.

3.3.2. Atraso

O atraso de envio (one-way delay) é o tempo necessário para um pacote viajar de sua origem ao seu destino, utilizando um timestamp e relógios sincronizados. O tempo de envio e resposta (round-trip time) é medido enviando-se um pacote de tamanho pequeno a um servidor e contando o tempo necessário para que a resposta chegue.

3.3.3. Dispersão de Pacotes

Sistemas que utilizam dispersão de pacotes funcionam do seguinte modo. Utilizando-se pacotes do tipo UDP ou ICMP ECHO, seqüências de pacotes são enviados consecutivamentes para o nó de destino, que reenvia os pacotes de volta. Ao passar por um link de menor capacidade, os pacotes serão enfileirados. Após este link, os pacotes terão um espaço entre eles devido ao enfileiramento. O espaço ou dispersão entre os pacotes é definido como o tempo entre a chegada do último bit do primeiro pacote e o tempo da chegada do último bit do segundo pacote. Após passar pelo link de menor capacidade, o tamanho da dispersão, teoricamente, não ficará maior. A dispersão média entre os pacotes da seqüência é medido e a capacidade Ĉ, em bytes por segundo, é dado pela fórmula:

Ĉ = \frac{P}{t_{dispersao}},

onde P é o tamanho do pacote, em bytes, e t_{dipersao} é a média do tempo de dispersão da seqüência, em segundos. A capacidade Ĉ é, então, usada como estimativa para a capacidade do link.

A existência de pacotes concomitantes aos pacotes da seqüência, isto é, a existência de tráfego no nó de rede que não seja gerado pelo sistema de pesquisa, faz com que a estimativa de capacidade fique menos acurada.

3.3.4. Pacotes de Tamanhos Variados

A técnica de pacotes de tamanhos variados foi utilizada pela primeira vez na ferramenta pathchar [10]. A idéia básica é que a ferramenta mande um pacote onde o campo TTL (timeto-live) do cabeçalho IP do pacote é definido com um valor específico. Cada dispositivo da camada três de rede (TCP/IP) irá decrementar o valor do TTL em um. Quando o valor de TTL atingir zero, o dispositivo enviará uma mensagem de erro do tipo ICMP TTL-exceeded para o remetente do pacote. Ao receber essa mensagem de erro, a ferramenta pode estimar o tempo de envio e resposta. O tempo de envio e resposta é medido várias vezes para diferentes tamanhos de pacote. Com uma certa dose de sorte, alguns pacotes de resposta chegarão de volta ao remetente sem serem enfileirados nenhuma vez por nenhum dispositivo de rede. Estes representarão os menores tempos de envio e resposta para determinado tamanho de pacote. Os tempos obtidos permitirão que seja estimada a largura de banda do link de menor capacidade.

3.3.5. Roteamento e Topologia

Esta metodologia é a mais antiga e utilizada de todas. Desde 1988 a ferramenta traceroute, criada por Van Jacobson, é utilizada para descobrir por quais nós um pacote passa para chegar a um nó destino em particular. Desta forma, uma pequena parte da topologia de rede se torna visível. Porém, nem todos os pacotes necessariamente seguem um mesmo caminho. Todos as ferramentas que realizam medição por link, isto é, medem as características de rede levando em consideração todo o caminho que os pacotes percorrem, utilizam a mesma técnica. Descobrem todos os dispositivos de rede nível três, enviam pacotes de rede com o campo TTL modificado e esperam os pacotes com as mensagens de erros chegarem.

Devido a diferenciação que os equipamentos de roteamento de rede fazem entre pacotes ICMP e IP, os resultados produzidos por esta técnica não são confiáveis. Entretanto, nota-

4 FERRAMENTAS DE PESQUISA POR PACOTES

se que, atualmente, a utilização de outras técnicas de sondagem em conjunto com técnicas de roteamento e topologia estão se tornando uma tendência.

Pode-se notar que os sistemas de grade computacionais tradicionais não consideram as características de rede como um recurso do sistema de grade. Apenas assume-se que a rede existe, e que todos os nós são alcançáveis a partir de qualquer outro, ou seja, o grafo que representa a topologia e a comunicação entre os nós é completo. Nota-se, também, que sistemas de sondagem especializados produzem resultados mais precisos do que os de pesquisa por pacotes, mas necessitam de informações sobre a tecnologia de rede utilizada, o que nem sempre está disponível em ambientes heterogêneos como a Internet. Por fim, temos que sistemas de pesquisa por pacotes produzem estimativas das características do ambiente de rede, mas não modelam bem equipamentos de rede que não operam na camada três de rede (TCP/IP).

4. Ferramentas de Pesquisa por Pacotes

Durante este projeto algumas ferramentas de pesquisa por pacotes foram experimentadas. A seguir, descreveremos as ferramentas pathchar, netperf, nettimer e igi.

4.1. pathchar

Pathchar [10] é uma ferramenta de pesquisa por pacotes idealizada por Van Jacobson, do Lawrence Berkeley Laboratory. O pathchar tenta inferir as características dos links individuais que compõem o caminho entre os dois nós da rede que estão sendo sondados. Para isso, ele mede o tempo de envio-e-resposta para cada nó que compõe o caminho entre os dois nós sondados, utilizando a seguinte fórmula:

tempo de envio e resposta = (latência + tamanho do pacote / banda disponível) + latência,

Onde o tempo de envio e resposta é medido pela ferramenta e a latência pode ser estimada enviando pacotes de tamanho cada vez menor. Ao aplicar essa fórmula para todos os nós que compõe a rede, pathchar consegue determinar qual a largura de banda máxima entre os dois nós sondados.

Para encontrar os nós que compõem o caminho, a ferramenta utiliza o mesmo princípio utilizado pelo traceroute, também idealizado por Jacobson. Um pacote IP é montado de

4.2 netperf  4 FERRAMENTAS DE PESQUISA POR PACOTES

forma que o campo Time-to-Live (TTL) seja pequeno. Cada nó que compõe o caminho, ao receber o pacote, decrementa 1 do valor de TTL e, se TTL chegar a zero, envia uma mensagem de erro ICMP para o remetente do pacote. Se TTL não for zero, envia o pacote para o próximo nó que compõe o caminho.

O pathchar é uma das mais antigas ferramentas de pesquisa por pacotes. Ela foi apresentada no Mathematical Sciences Research Institute em abril de 1997.

4.2. netperf

Netperf [13] é uma ferramenta desenvolvida inicialmente pela Hewlett-Packard (HP) e que posteriormente teve seu código disponibilizado para a seus usuários. O netperf pode ser usado para medir vários aspectos que influenciam o desempenho de redes de computadores. Seu foco primário é na transferência de grandes quantidades de dados e na medição de desempenho de envio-e-resposta utilizando tanto TCP e UDP.

O netperf mede a largura de banda total do link. Durante 10 segundos, a ferramenta mede o tempo gasto para enviar pacotes de tamanhos fixos entre os dois nós que estão sendo sondados. Medindo o tempo gasto e sabendo-se o tamanho dos pacotes enviados, é possível para a ferramenta descobrir qual a banda total disponível.

Das ferramentas analisadas, netperf é a que produz resultados mais precisos. Por outro lado, é a ferramenta que mais gera tráfego durante sua utilização.

4.3. netest

O netest [12] foi desenvolvido para fornecer informações sobre todos os nós que compõem um caminho entre dois nós quaisquer, de forma não intrusiva.

Netest informa a largura de banda total entre os dois nós sondados e exibe diversas informações sobre a configuração das conexões TCP utilizadas entre os nós. Entre essas informações, destaca-se a largura da janela dos pacotes TCP e algumas recomendações para a configuração do sistema de TCP.

Netest é um sistema de pesquisa ativo que utiliza uma metodologia que mescla atraso, visto na seção 3.3.2 e pesquisa por roteamento e topologia, visto na seção 3.3.5.

4.4 nettimer  4 FERRAMENTAS DE PESQUISA POR PACOTES

4.4. nettimer

A ferramenta nettimer [15] propõe uma sondagem que seja menos intrusiva possível, ou seja, que consuma pouca banda, a fim de não degradar o desempenho das aplicações que já estão rodando no nó da rede que está sendo testado. A ferramenta nettimer foi uma das primeiras ferramentas a tentar sondar apenas o link que provoca gargalo, ao invés de tentar medir a largura da banda de todos os links.

Nettimer utiliza duas abordagens para a realização da sondagem. A primeira utiliza um método que baseia-se no conceito de pesquisa passiva (veja seção 3.3.1). A equipe do nettimer desenvolveu uma biblioteca chamada libdpcap que nada mais é do que uma biblioteca para captura distribuída de pacotes. A biblioteca utilizou como base a conhecida biblioteca de captura de pacotes libpcap, que não é distribuída. Com as informações geradas pela libdpcap, o nettimer é capaz de determinar a largura da banda do menor link entre dois nós. Mas, como citado na seção 3.3.1, metodologias baseadas em pesquisa passiva não produzem resultados muito acurados.

A segunda utiliza pesquisa ativa, utilizando a metodologia de atraso, visto na seção 3.3.2.

4.5. igi

O método IGI [14] (Initial Gap Increasing) foi desenvolvido por Peter Steenkiste e Ningning Hu na Carnegie Mellon University. O IGI utiliza pesquisa ativa baseada na metodologia de dispersão de pacotes (ver seção 3.3.3).

O algoritmo IGI envia uma seqüência de pacotes consecutivos. O tempo de envio entre um pacote e outro é crescente durante a execução do algoritmo. A ferramenta, então, monitora a diferença entre a média dos tempos de chegada entre o primeiro e o segundo pacote e o intervalo de tempo entre o envio dos pacotes. Quando esta diferença for próxima de zero, a ferramenta considera que este é o melhor tempo que um pacote consegue realizar entre os dois nós e, conseqüentemente, pode inferir a largura de banda.

Das ferramentas analisadas, esta foi a que apresentou os melhores resultados e o melhor desempenho em ambientes de rede de alta velocidade.

A tabela 1 resume as principais características das ferramentas analisadas.

6 CONCLUSÃO

Ferramenta  Pesquisa  Metodologia  Protocolo Características medidas
pathchar  ativa  roteamento e topologia UDP e ICMP banda total, latência
netperf  ativa  atraso  TCP e UDP  banda total, latência
netest  ativa  atraso  UDP  banda total
nettimer ativa e passiva dispersão de pacotes  TCP  banda total
igi  ativa  dispersão de pacotes TCP e UDP  banda disponível

Tabela 1: Características principais das ferramentas analisadas

5. Atividades Realizadas

As atividades realizadas, em ordem cronológica, foram:

• estudo do protocolo de gerenciamento de rede SNMP;

• estudo do sistema ReMoS de obtenção dinâmica do estado de rede;

• familiarização com as diferentes linhas de pesquisa em grades computacionais [6];

• análise do sistema de grade computacional OurGrid;

• estudo do sistema de grade Legion, com enfoque no gerenciamento de recursos de rede;

• familiarização com o conceito de pesquisa por pacotes [11] e pesquisa de ferramentas que implementassem esse conceito;

• estudo das ferramentas netest [12], netperf [13], pathchar [10], igi [14], nettimer [15].

6. Conclusão

Neste estudo, analisamos como alguns sistemas de grade computacional tratam as limitações de desempenho que as redes oferecem. Pesquisamos, também, diversos métodos de sondagem de rede que permitissem que os recursos computacionais disponíveis para sistemas conscientes da rede pudessem obter informações sobre o ambiente de rede de forma dinâmica.

6 CONCLUSÃO

Os sistemas de grade tradicionais não consideram as características de rede como, por exemplo, largura de banda disponível, um recurso do sistema de grade computacional. Informações desta natureza são fundamentais para aplicações paralelas de alto desempenho. No futuro, algoritmos de escalonamento de tarefas [2] farão uso destas informações para minimizar a degradação de desempenho causada pela comunicação feita entre nós da grade. Entre os projetos de grade computacional que tratarão as características de rede como recursos, podemos citar o projeto Globus e o InteGrade.

A pesquisa sobre métodos de sondagem de rede nos mostrou que sistemas especializados normalmente produzem resultados mais precisos. Porém, é necessário que o sistema conheça com antecedência qual o tipo de tecnologia de rede utilizada entre os nós que participam da rede. Essa abordagem não é adequada para grades computacionais, onde o ambiente de rede computacional é heterogêneo e dinâmico, uma vez que qualquer computador interligado a Internet pode começar a participar da grade ou sair dela.

Os métodos de pesquisa por pacotes, em sua maioria, não modelam corretamente os diferentes equipamentos de rede nem a utilização da rede por outros aplicativos. Equipamentos que operam apenas no nível dois da camada de rede, como alguns roteadores, não são percebidos por métodos que utilizam apenas pacotes IP. Métodos que utilizam ICMP detectam esses equipamentos, porém mensagens ICMP são tratados com menor prioridade do que mensagens IP e, portanto, levam a resultados menos precisos. Certas especificidades do sistema operacional e do dispositivo de rede como, por exemplo, o modo como os pacotes são enfileirados no dispositivo de rede se a conexão física estiver sendo usada, deveriam ser considerados por estes métodos para produzir um resultado mais preciso. Mas isso tornaria inviável a criação de um sistema genérico que seja independente da tecnologia utilizada.

No ambiente de grade computacional, a escolha do método de pesquisa de pacote deve ser cuidadosa. O método deve ser rápido e não intrusivo, ou seja, o método não pode degradar o desempenho da comunicação de rede das aplicações que estão sendo executadas nos nós da grade. O sistema deve assegurar, também, que um mesmo nó não participe de duas sondagens em paralelo, pois isso resultaria em resultados enviesados.

7 DESAFIOS E FRUSTRAÇÕES

Parte II.

Experiência Pessoal

A segunda parte desta monografia trata de questões relacionadas a experiência obtida com minha participação no projeto InteGrade e com a realização da pesquisa de métodos de obtenção dinâmicos do estado da rede, relatada na parte I deste trabalho.

7. Desafios e Frustrações

Todos os desafios enfrentados durante a realização deste projeto estão relacionados ao fato de que as pesquisas na área de sondagem de rede são ainda muito recentes e imaturas.

O primeiro desafio foi fazer um mapa desta área de pesquisa. Nós, em um primeiro momento, não conhecíamos nenhum trabalho relacionado a sondagem de redes a não ser o projeto ReMoS, descrito na seção 3.2.2. O estudo do ReMoS nos levou ao estudo do SNMP e à primeira ferramenta de pesquisa por pacote, o pathchar. A partir do artigo [10], realizamos uma pesquisa recursiva nas referências de cada artigo que encontrávamos. Assim, conseguimos obter uma idéia das linhas de pesquisa desta área.

O segundo grande desafio foi conseguir mesclar as informações que obtia lendo cada um dos trabalhos que encontramos. Como o assunto é relativamente novo, ainda não há uma nomenclatura bem definida e cada artigo define os mesmos conceitos utilizando nomes diferentes ou utiliza definições similares, mas não iguais. Isso me atrapalhou bastante no começo, mas depois fui me acostumando. Mais tarde, quando li a tese [9], percebi que não tinha sido o único a ter esse tipo de dificuldade. O primeiro capítulo da tese é uma tentativa de formalização e padronização da nomenclatura utilizada nos artigos sobre pesquisa por pacotes.

A única frustração deste trabalho foi não conseguir encontrar uma ferramenta que consiga resolver os problemas de sondagem de rede para ambientes de grade computacional. Mas fico satisfeito em saber que este trabalho contribui com informações para que esta escolha seja a melhor possível.

9 INTEGRAÇÃO COM OS MEMBROS DO INTEGRADE

8. Disciplinas do BCC mais relevantes

As disciplinas que cursei no BCC que foram mais relevantes para este trabalho foram:

• MAC0110 - Introdução à Computação: por ter introduzido todos os conceitos de computação e de programação de computadores;

• PCS0210 - Redes de Computadores: por ter apresentado e discutido diversos tipos de redes de computadores distintos, que foram muito importantes para meu entendimento das limitações dos métodos de sondagem decorrentes da heterogeneidade das redes que compõem a Internet;

• MAC0412 - Organização de Computadores: por explicar como dispositivos de rede são integrados fisicamente com o restante do computador;

• MAC0422 - Sistemas Operacionais: por explicar como o sistema operacional lida com o envio de informações para os dispositivos de rede (operações de entrada e saída, enfileiramento dos pacotes, etc.).

Não posso deixar de citar minha experiência como administrador da Rede GNU/Linux, dos alunos de graduação, no período de janeiro de 2001 à março de 2003. Apesar de ter sido uma tarefa extra-curricular, foi muito importante para o aprendizado de diversos conceitos referentes às redes de computadores que muito me ajudaram durante este projeto.

9. Integração com os membros do InteGrade

A interação com os outros membros do InteGrade foi excelente.

Os membros do projeto InteGrade (atualmente composto por cerca de 4 professores, 3 alunos de doutorado, 6 alunos de mestrado e 3 alunos de graduação) se reúnem duas vezes por mês para que cada um possa relatar o andamento de seus projetos de pesquisa. Durante os relatos, muitas sugestões e críticas eram tecidas para todos os alunos participantes. As reuniões do projeto permitem que todos os alunos acompanhem o andamento de todos os trabalhos que compõem o projeto e permite que cada aluno possa ajudar o outro a realizar seus trabalhos. As sugestões e cobranças que recebi durante estas reuniões me ajudaram muito durante todo o meu trabalho.

11 CONCLUSÕES FINAIS

Além das reuniões com todos os integrantes do projeto, haviam as reuniões em que participavam apenas eu, meu orientador e o aluno de mestrado Alex Pires de Camargo. Nestas reuniões discutíamos problemas de caráter técnico mais específicos dos que os discutidos nas reuniões do InteGrade. Essa aproximação entre meu projeto e a pesquisa realizada pelo Alex, proporcionada pelo meu orientador, foi benéfica para ambos. Procuramos nos ajudar discutindo idéias e fazendo novas sugestões para ambos os projetos. Além disso, o contato com um projeto de mestrado me ajudou a tomar a decisão de continuar meus estudos no IME, fazendo mestrado.

10. Trabalhos futuros

Para que a pesquisa em sondagem de rede seja completa, ainda há muito trabalho a ser feito.

Primeiramente, os sistemas especializados devem ser melhor estudados. Apesar de serem feitos para ambientes de redes específicos, são muito importantes quando os resultados produzidos pela sondagem de rede devem ser os mais precisos possíveis.

Há inúmeras ferramentas de pesquisa por pacotes que devem ser analisadas também. Este trabalho tentou analisar as ferramentas mais importantes devido as restrições de tempo.

Sondagens baseadas em algoritmos adaptativos também poderiam ser analisadas. Programas de transmissão de vídeo digital como RealPlayer ou Windows Media Player utilizam esses algoritmos para determinar a qualidade da conexão. Este trabalho não analisou nenhum algoritmo deste tipo.

11. Conclusões finais

Esta iniciação científica foi um excelente modo de compreender o que é ser um pesquisador e quais os desafios que isto acarreta. Foi, também, uma boa forma de entrar em contato com as pesquisas em grades computacionais que é uma área promissora e excitante, em temos de pesquisa.

Além disso, este projeto me permitiu aplicar conceitos distintos, aprendidos separadamente durante o curso de bacharelado em computação e durante meu trabalho como administrador

\underline{Referências}

da Rede GNU/Linux dos alunos de graduação, em um único trabalho, o que nem sempre podemos fazer durante o decorrer do curso.

Por fim, este trabalho me colocou em contato com as novas pesquisas realizadas na área de sondagem de rede que, sem dúvida, são de uma utilidade inestimável em ambientes de sistemas distribuídos.

12. Agradecimentos

Gostaria de agradecer a diversas pessoas sem as quais este trabalho teria sido muito mais difícil.

Aos meus pais, pelo apoio e compreensão que sempre me deram.

Ao professor Carlos Eduardo Ferreira, pela oportunidade que me deu de entrar em contato com o interessante e trabalhoso ramo de administração de redes.

Aos participantes das listas de usuários dos projetos ReMoS e MyGrid, pela ajuda que me deram e que tornaram possível a experimentação destes sistemas. E a todos os integrantes do projeto InteGrade, por acompanharem de perto este trabalho.

Ao meu orientador, professor Alfredo Goldman, por todas as suas sugestões, críticas e, principalmente, paciência.

Ao Conselho Nacional de Desenvolvimento Científico e Tecnológico, CNPq, pelo financiamento dado através do processo No. 55.2028/02-9.

Referências

[1] InteGrade: Rumo a um Sistema de Computação em Grade para Aproveitamento de Recursos Ociosos em Máquinas compartilhadas. Andrei Goldchleger, Fabio Kon, Alfredo Goldman Vel Lejbman, Marcelo Finger e Siang Wun Song. Relatório Técnico MAC-IME-USP, outubro 2002.

[2] A model for parallel job scheduling on dynamical computer grids. Alfredo Goldman e Carlos Queiroz. ACM/IFIP/USENIX International Workshop on Middleware for Grid Computing, Rio de Janeiro, junho 2003.

Referências  Referências

[3] ReMoS: A resource monitoring system for network aware applications. Anthony DeWitt, Thomas Gross, Bruce Lowekmap, Nancy Miller, Peter Steenkiste, Jaspal Subhlok e Dean Sutherland. D. Tech. Rep. CMU-CS-97-194, School of Computer Science, Carnegie Mellon University, dezembro 1997.

[4] Open Grid: A User-Centric Approach for Grid Computing. Walfredo Cirne and Keith Marzullo, Proceedings of the 13th Symposium on Computer Architecture and High Performance Computing, setembro 2001.

[5] The Core Legion Object Model. Michael Lewis e Andrew Grimshaw, Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing, agosto 1996.

[6] The grid forum http://www.gridforum.org/.

[7] Simple Network Management Protocol http://www.snmplink.org/.

[8] Grade: um Padrão Arquitetural. Andrei Goldchleger, Márcio Rodrigo de Freitas Carneiro e Fabio Kon. Relatório Técnico MAC-IME-USP, março 2003.

[9] Network Performance Measurement Tools - a Comprehensive Comparison. Rody Schoonderwoerd. Tese de mestrado, Vrije Universiteit, Amsterdam, novembro 2002.

[10] Using pathchar to Estimate Link Characteristics. Allen Downey. In Proceedings of the ACM SIGCOMM, 1999.

[11] Packet Probing for Network-aware Scientific Applications in Cluster Environments, Sam Storie e Masha Sosonkina. HeteroPar’03.

[12] Netest: An Tool to Measure the Maximum Burst Size, Available Bandwith and Achievable Throughput. Guojun Jin e Brian Tierney. Disponível em http://www-didc.

lbl.gov/NCS/.

[13] Netperf: A Network Performance Benchmark. Hewlett-Packard Company Information Networks Division. Disponível em http://www.netperf.org/.

[14] Evaluation and Characterization of Available Bandwidth Probing Techniques. Ningning Hu e Peter Steenkiste. In the IEEE JSAC Special Issue in Internet and WWW Measurement, Mapping, and Modeling, Vol. 21(6), agosto 2003.

[15] Nettimer: A Tool for Measuring Bottleneck Link Bandwidth. Kevin Lai e Mary Baker. Proceedings of the USENIX Symposium on Internet Technologies and Systems, março 2001.