PLANETLAB: UM LABORATÓRIO VIRTUAL PARA DESENVOLVIMENTO DE NOVAS APLICAÇÕES PARA A INTERNET

Transcrição

1 PLANETLAB: UM LABORATÓRIO VIRTUAL PARA DESENVOLVIMENTO DE NOVAS APLICAÇÕES PARA A INTERNET Etienne César Ribeiro de Oliveira 1-2, Célio Vinicius Neves de Albuquerque 1-2 Abstract The development of new Internet applications require a structure that allows for the creation of a test environment with the same characteristics of the real environment. This work aims at presenting PlanetLab and describing its functionalities. PlanetLab is a virtual laboratory designed to help the development of computer network applications, such as distance education frameworks, network management frameworks, network services, distributed systems, etc, in a geographically distributed platform. PlanetLab features, that are not present in most educational and research institutions, are an aid to the learning process, providing access to more than 700 nodes (computers) previously configured with the Linux Fedora Core 2 operating system via Internet. Making use of virtual machines, users can install programming environments using such as Perl, Python and C and test their applications, designing their own networks and potentially establishing connections to other nodes spread all over the world. Index Terms PlanetLab, Internet Applications Development. INTRODUÇÃO O desenvolvimento de novas aplicações para a Internet ou que apresentem uma forte dependência de redes de computadores requer, cada vez mais, um ambiente capaz avaliar o impacto das aplicações sobre as redes de computadores e, principalmente, o comportamento das aplicações em um ambiente tipicamente instável como das redes de computadores. O aprovisionamento de recursos de hardware, de software e de telecomunicações apropriados para testar e avaliar componentes em desenvolvimento requer uma infraestrutura complexa, de alto custo e de difícil manutenção. E, como essa infra-estrutura não encontra-se disponível para a maioria das instituições de pesquisa, de ensino, do governo, industriais etc, soluções alternativas que se aproximem da realidade têm sido propostas [2]. Em função destas preocupações, inúmeros simuladores para redes de computadores têm sido desenvolvidos com intuito de possibilitar a avaliação de novas aplicações, novos protocolos e o desempenho das soluções propostas. Apenas como exemplo, o ns-2 [1] é um simulador para redes de computadores, baseado em eventos, capaz de efetuar simulações com os principais protocolos para redes de computadores existentes, e ainda possibilita o desenvolvimento de novos protocolos para redes de computadores, assim como o desenvolvimento de módulos adicionais, que podem atuar na camada de aplicação. Embora os simuladores para redes de computadores demandem uma infra-estrutura infinitamente inferior à infraestrutura do mundo real, esses simuladores apresentam algumas desvantagens, como, por exemplo, a dificuldade de modelar tempos de processamentos, entre outras. O PlanetLab, inaugurado em 2002, apresenta-se como uma solução para os problemas evidenciados. O PlanetLab é um laboratório virtual para o desenvolvimento de novas aplicações que incluem distribuição de conteúdo, análise de anomalias e diagnósticos de falhas, serviços multicast, mobilidade, entre tantas novas aplicações. Atualmente, o PlanetLab dispõe de 718 computadores, hospedados em 345 sites e espalhados em 25 países. A maioria destes computadores encontra-se em instituições de pesquisa, embora alguns estejam localizados em centros de roteamento, como no backbone da rede norte-americana Abilene, integrante do projeto Internet2 [1]. A seção Estrutura e Terminologia do PlanetLab apresenta os princípios, os principais termos e suas respectivas definições e a estrutura organizacional do PlanetLab. Já a seção Utilização do PlanetLab descreve os passos necessários para prover o acesso ao PlanetLab e para definir um cenário capaz de permitir o desenvolvimento de novas aplicações. A seção Desenvolvimento de uma Aplicação especifica uma aplicação de roteamento baseado no RTT (Round Trip Time) sobre a rede overlay do PlanetLab. Por fim, a seção Conclusões tece considerações acerca da arquitetura PlanetLab. ESTRUTURA E TERMINOLOGIA DO PLANETLAB Como o PlanetLab é resultado de um consórcio de inúmeras instituições, para que usuários possam acessar os recursos disponibilizados pelo PlanetLab é necessário obter, junto a uma das instituições participantes deste consórcio, uma autorização para usufruir a plataforma PlanetLab. Da mesma forma, existem regras definidas para que instituições possam se vincular ao consórcio. No caso específico do Brasil, a autorização de acesso pode ser provida através da RNP (Rede Nacional de Ensino e Pesquisa), a UFCG (Universidade Federal de Campina Grande), UFMG (Universidade Federal de Minas Gerais), Hewlett-Packard Brasil etc. 1 Universidade Federal Fluminense, Centro Tecnológico Rua Passo da Pátria, 156, bloco E, 3º andar, São Domingos, CEP , Niterói, RJ, Brasil, {eoliveira, celio}@ic.uff.br. 2 Os autores agradecem à RNP (Rede Nacional de Ensino e Pesquisa) pelo criação do slice rnp_icece, sem o qual este trabalho não poderia ter sido realizado.

2 O entendimento da terminologia descrita a seguir é primordial para o perfeito entendimento da estrutura do PlanetLab [1]. Node É um servidor dedicado à plataforma PlanetLab, que executa os serviços necessários à sua participação; Site Pode ser definido como um local onde encontram-se nodes do PlanetLab. Existem, no Brasil, nodes localizados no Ceará, no Rio de Janeiro, na Paraíba, no Rio Grande do Sul etc; Slice É um conjunto de recursos alocados e distribuídos entre vários servidores do PlanetLab. Pode ser explicado, de forma mais simplista, como o acesso a uma interface Shell Unix de alguns nodes do PlanetLab. Os Slices têm um tempo de vida limitado (2 meses) e devem ser periodicamente renovados para que permaneçam válidos; Sliver Um conjunto de recursos alocados em um servidor do PlanetLab; Virtual Server (VServer) Os Slivers são implementados como Linux VServers [3] e os recursos são alocados de forma diferenciada para os usuários através do CKRM (Class-based Kernel Resource Management) [4]. A virtualização do acesso através da rede é implementada através do VNET [5]; Users Um usuário pode ser qualquer pessoa que desenvolva ou avalie aplicações sobre a arquitetura PlanetLab; Principal Invertigator (PI) - Os PIs são responsáveis pelo gerenciamento dos slices e dos usuários de cada site, ou seja, cabe ao PI as tarefas de criação de slices e a respectiva associação aos usuários. Os usuários somente são capazes de adicionar nodes aos seus slices após a realização desta tarefa pelo PI responsável; Technical Contact (Tech Contact) Cada site deve ter ao menos um contato técnico, que é responsável pela instalação, manutenção e monitoração dos nodes. O PlanetLab encontra-se estruturado em uma rede overlay sobre as principais redes ao redor do mundo, tais como a Internet, a Abilene etc. Ou seja, como a comunicação entre os nodes ocorre através desta rede overlay, a realidade necessária para a avaliação de novas aplicações sobre a Internet é provida, automaticamente, pelo PlanetLab. Essa característica oferece aos seus usuários um nível de realidade e de imprevisibilidade indisponível nos simuladores de rede. Atualmente, a arquitetura PlanetLab provê aos seus usuários mecanismos de controle de admissão para um conjunto de recursos (CPU, memória, banda de rede etc), tais como o Sirius (PlanetLab Sirius Calendar Service) e o Bellagio [1]. Esse controle permite que aplicações que requisitem uma maior dedicação de recursos possam ser executadas sem comprometimento, independente da existência de outras aplicações, através de agendamento [6]. Os slices são criados com uma configuração básica do sistema operacional Linux Fedora Core 2. No entanto, após efetuar o login em um node, os usuários podem se transformar em root e efetuar a instalação de pacotes, criar novos usuários etc UTILIZAÇÃO DO PLANETLAB Conforme descrito anteriormente, após terem os slices criados e as respectivas senhas definidas, os usuários encontram-se prontos para se autenticar no web site do PlanetLab ( e iniciar o uso dos recursos disponíveis. O processo de autenticação requer que o usuário informe o e a senha cadastrados. As subseções a seguir descrevem as tarefas que devem ser executadas para se ter acesso ao Shell Unix dos nodes do PlanetLab. Listagem dos Nodes Existentes Após o processo de autenticação no web site do PlanetLab, o usuário pode listar os nodes disponíveis clicando na aba Nodes e, em seguida, em View All Nodes. Esta ação provocará a exibição de uma lista com todos os nodes. Informações detalhadas sobre cada um dos nodes podem ser obtidas clicando-se, especificamente, sobre um node. A FIGURA 1 apresenta um resumo das principais informações disponibilizadas pelo PlanetLab. FIGURA 1 INFORMAÇÕES DETALHADAS DOS NODES [1] Associação de Nodes aos Slices A próxima etapa é a associação de nodes aos seus respectivos slices. Deve-se, então, clicar na aba Slices e, em seguida, em View Slices, quando serão relacionados os slices associados aos usuários, conforme ilustra a FIGURA 2. O

3 slice rnp_icece foi criado especificamente para o desenvolvimento deste trabalho. FIGURA 2 INFORMAÇÕES DETALHADAS DOS SLICES [1] Clicando-se sobre o slice selecionado (rnp_icece, no exemplo), serão exibidos detalhes sobre o slice, tais como nome, descrição, data de expiração, do usuário etc. Além destas informações, as opções Renew this slice (permite a renovação do prazo de expiração do slice), Delete this slice (remove definitivamente o slice) e Manage Nodes (permite a inclusão e exclusão de nodes no slice) são apresentadas conforme a FIGURA 3. FIGURA 4 INFORMAÇÕES PARA GERÊNCIA DE NODES[1] Acesso aos Nodes do PlanetLab O processo de autenticação do PlanetLab requer o uso de chaves SSH (Secure Shell) que podem ser geradas, em ambiente Unix, através do comando (1). ssh-keygen t rsa f id_rnp_icece (1) FIGURA 3 INFORMAÇÕES DETALHADAS DO SLICE RNP_ICECE [1] Selecionando a opção Manage Nodes será exibida uma tela com os requerimentos necessários à inclusão e exclusão de nodes do slice selecionado, conforme pode ser observado na FIGURA 4. Os nodes associados ao site RNP Rio Grande do Sul foram selecionados a partir do menu drop-down. A partir deste menu drop-down é possível visualizar todos os sites do PlanetLab e efetuar inclusões à lista de nodes pertencentes ao slice. Os processos de inclusão e de exclusão podem ser facilmente executados: para efetuar estas ações, ou seja, é necessário apenas clicar sobre os nodes exibidos, selecionando-os e, em seguida, sobre o botão responsável pela ação desejada (Add Selected ou Remove Selected). Deve-se considerar que o processo de criação ou remoção dos nodes nos servidores selecionados não é instantâneo. E, dependendo da situação do servidor, este processo pode demorar muitas horas. Após a execução do comando (1), serão criados 2 arquivos: id_rnp_icece (chave privada) e o arquivo id_rnp_icece.pub (chave pública). A chave pública, ou seja, o arquivo id_rnp_icece.pub no exemplo formulado deve ser armazenado no PlanetLab. Para executar esta tarefa é necessário clicar na aba User, depois selecionar a opção Manage My Account e, por fim, Manage Keys. A FIGURA 5 exemplifica esta tarefa. FIGURA 5 GERENCIAMENTO DE CHAVES [1] Após a propagação da chave, pode-se acessar qualquer um dos nodes previamente adicionados (ver FIGURA 4). A partir do servidor Unix onde foram criadas as chaves pública e privada, deve-se executar o comando (2).

4 ssh v l rnp_icece i id_rnp_ icece.pub planetlab1.poprj.rnp.br (2) Para a opção l (nome de login) deve ser informado o nome do slice criado e para a opção i (chave privada) deve ser informado o nome do arquivo que armazena a chave privada criada com o comando (1). A opção v ativa o modo verbose da negociação que pode ser útil para o processo de depuração, caso ocorra algum problema durante a autenticação. Transferência de Arquivos no PlanetLab A transferência de arquivos entre os nodes do PlanetLab e demais servidores na Internet é possível através do comando scp. Supondo a necessidade de transferência do arquivo pgm1.c, localizado no diretório bin, para o servidor planetlab1.pop-rj.rnp.br, devemos executar o comando (3). configurações obtidas pelo protocolo de roteamento. A aplicação foi desenvolvida na linguagem C, em um servidor externo ao PlanetLab, instalado com Linux Fedora Core 3, compilado com gcc e instalada em todos os nodes criados. O protocolo NetAlive troca mensagens periodicamente com os demais nodes, enviando e recebendo informações acerca da tabela de roteamento de cada um dos nodes aos quais ela mantém uma conexão direta sobre a rede overlay, ou seja, com apenas 1 hop. Com base nestas informações, cada um dos nodes será capaz de apresentar uma visão particular da rede. A tabela de roteamento contém o endereço IP de todos os nodes, o estado de comunicação (up, warning, critical, ou down), o menor tempo de atraso registrado, o tempo médio de atraso, o tempo máximo de atraso e a quantidade de hops até o nó. A FIGURA 6 apresenta a topologia preparada para a avaliação do NetAlive. scp i id_rnp_icece.pub bin/ pgm1.c rnpicece@ planetlab1.pop-rj.rnp.br: (3) O comando rsync pode ser utilizado caso haja necessidade de sincronização de diretórios entre diferentes nodes do PlanetLab. Supondo a sincronização do diretório fontes com o servidor planetlab2.lsd.ufcg.edu.br, devemos executar o comando (4). rsync rvaz e ssh progress delete fontes planetlab2.lsd.ufcg.edu.br (4) Instalação de Pacotes nos Nodes do PlanetLab Como os nodes são criados com uma configuração básica, é provável que haja necessidade de instalação de algum pacote específico. Neste caso, basta executar o comando sudo para que comandos responsáveis pela instalação de pacotes, tais como yum <opções> install <nome(s) do(s) pacote(s)>, sejam executados como superusuário (root). Como exemplo, a instalação do compilador gcc e do make seria possível através do comando (5). sudo yum -y -t install gcc make (5) DESENVOLVIMENTO DE UMA APLICAÇÃO Com intuito de avaliarmos os recursos disponibilizados pelo PlanetLab, foi desenvolvida uma aplicação de roteamento baseado no RTT sobre a rede overlay do PlanetLab denominada NetAlive. Um console simples foi implementado com intuito de extrair as informações e FIGURA 6 TOPOLOGIA PARA AVALIAÇÃO DO NETALIVE] Para avaliar o comportamento do NetAlive foram adicionados 18 nodes ao slice, sendo 7 nodes no Brasil, 2 nodes na China, 1 node no Canadá, 1 node na França, 5 nodes nos EUA, 1 node na Índia e 1 node no Reino Unido. Dos 18 nodes incluídos, 6 não estavam operacionais. O estado da comunicação entre os nodes foi discretizado a partir do cálculo do atraso médio, com intuito de simplificar a representação valores, e representado da seguinte forma: [U] Up - de 0 até 150 ms; [W] Warning - de 151 até 450 ms; [C] Critical - acima de 451 ms; [D] Down - sem resposta. Apenas como exemplo, a FIGURA 7 exibe o console do node planetlab1.pop-rj.rnp.br.

5 CONCLUSÃO O PlanetLab é resultado de um consórcio de inúmeras instituições, idealizado com intuito de prover aos seus usuários uma laboratório virtual para o desenvolvimento de novas aplicações. As vantagens de ter acesso a este ambiente diferenciado possibilitam o desenvolvimento de aplicações apropriadas para a Internet. Podemos relacionar, entre as inúmeras vantagens existentes, as seguintes: Ambiente Escalável A estrutura de comunicação de dados do PlanetLab possibilita a adição constante do novos servidores, possibilitando aos usuários um serviço com maior capilaridade e sem comprometido dos recursos existentes; Ambiente de Avaliação Real O fato do PlanetLab utilizar a Internet como forma de comunicação, possibilita a avaliação e depuração de aplicações em um ambiente real; Simplicidade de acesso O acesso aos recursos disponibilizados pelo PlanetLab é bem simples, sendo desnecessário o aprendizado de linguagens de scripts proprietárias para a realização dos experimentos. Entre os problemas identificados durante o uso do Planetlab podemos relacionar os seguintes: Tempo de Criação dos Nodes Durante os testes realizados, o tempo de criação de nodes manteve-se totalmente irregular. Em algumas tentativas, poucos minutos após a criação do node, o acesso estava disponível. No entanto, ocorreram situações de demora excessiva, permanecendo o node criado inacessível por um período inaceitável (superior a 24 horas); Acesso aos Nodes Alguns nodes permaneceram inacessíveis durante todo o tempo de confecção deste trabalho; Cópia de Segurança Como os nodes do PlanetLab podem ser regerados a qualquer momento, sem aviso prévio, o ideal é manter cópias dos dados em múltiplos nodes ou em servidores externos ao PlanetLab que disponham de mecanismos eficientes para realizar uma cópia de segurança; Devido à limitação da quantidade de páginas, algumas FIGURA 7 CONSOLE DO NETALIVE características, facilidades, vantagens, desvantagens foram suprimidas. No entanto, visando a melhoria do PlanetLab, as seguintes sugestões foram relacionadas: Carga dos Nodes Evidentemente que, por ser tratar de servidores compartilhados, não existem mecanismos que possam assegurar o padrão de comprometimento dos recursos por um longo período de tempo. Entretanto, a disponibilidade de um histórico do comprometimento dos recursos (CPU, memória, banda de rede etc) possibilitaria aos usuários do PlanetLab um nível de informação diferenciada no momento da inclusão dos nodes; Padronização dos Nomes O fato de não existir uma regra clara e bem definida para a definição dos nomes dos sites faz com que sejam necessárias consultas constantes ao web site do PlanetLab. A padronização dos nomes dos sites seria uma tarefa simples e influenciaria positivamente na organização da estrutura do PlanetLab. A experiência obtida durante o uso do PlanetLab ratifica a importância deste ambiente para o desenvolvimento de aplicações voltadas para a Internet, proporcionando mecanismos de avaliação fundamentais e inexistentes nos simuladores de rede. REFERÊNCIAS [1] PlanetLab Consortium, PlanetLab: Home, acessado em Novembro de [2] Peterson, L., Anderson, T., Culler, D. Roscoe, T., A Blueprint for Introducing Disruptive Technology into the Internet, Proceedings of ACM HotNets-I Workshop, Princeton, New Jersey, USA, October [3] Linux VServer, Welcome to Linux-VServer.org Linux-VServer, acessado em Novembro de [4] CKRM, Class-based Kernel Resource Management, acessado em Novembro de [5] VNET, PlanetLab: VNET: PlanetLab Virtualized Network Access, acessado em Novembro de [6] Peterson, L., Pai, V., Spring, N., Bavier, A., Using PlanetLab for Network Research: Myths, Realities, and Best Practices, acessado em Novembro de 2006.