OMF Control Management Framework

Transcrição

1 OMF Control Management Framework Igor Leonardo Eloy Macedo Joberto S. B. Martins Resumo A crescente popularização da internet está expondo cada vez suas falhas e limitações, fato que impulsiona a indústria e pesquisadores a desenvolver novas tecnologias de rede. Para que o produto chegue em produção, faz-se necessidade do uso de uma metodologia capaz de validar eficientemente essas novas tecnologias. Atualmente faz-se uso de network testbeds, que em conjunto com frameworks como o OMF estão tornando os testes cada vez mais maduros. Este artigo faz uma breve apresentação sobre o OMF, explicando o que é, como funciona e como pode ser aplicado. Abstract The growing popularity of the Internet is increasingly exposing their flaws and limitations, a fact that drives the industry and researchers to develop new network technologies. For the product reaches production, it is necessary to use a methodology able to validate these new technologies effectively. Network testbeds, nowadays, are the most significant way to reach this objective. Agregated with frameworks, like OMF, are making tests more mature. This article is a brief presentation on the OMF, explaining the self is, how it works and how it can be applied. 1. Introdução A popularização da internet é crescente e está expondo cada vez mais suas falhas e limitações. Isto está impulsionando a indústria e pesquisadores a

2 desenvolver novas tecnologias de rede que antes de partirem para produção devem ser massivamente testadas e avaliadas. Para tal, faz-se uso da melhor das metodologias com maior capacidade de geração de resultados próximos à realidade, as plataformas experimentais com foco em redes (network testbeds), que são fatores chave no desenvolvimento e amadurecimento das redes de computadores. Apesar disso, testbeds são produtos muito custosos (em implementação e preço) e comumente são desativados após um período de tempo, por terem sido projetados exclusivamente para um projeto específico. Este desperdício de recursos é comumente apontado pelos pesquisadores e por isso iniciativas de testbeds mais genéricos estão se ascendendo cada vez mais, como por exemplo, o Planetlab e o Orbit, que apesar de suas limitações, deram certo e estão cada vez mais evoluídas. Baseado na filosofia de testbeds genéricos, o OMF, framework criado para ser utilizado exclusivamente no projeto ORBIT, está amadurecendo para suportar e apoiar cada vez mais novos recursos e tecnologias. Este artigo aborda o que é o OMF, como ele é estruturado e seu funcionamento. Após a leitura deste artigo, o leitor será capaz de desenvolver um pequeno experimento e executá-lo em um testbed que tenha o OMF como framwork. 2. OMF O OMF Control Management Framework é um framework de gerência, medições e controle de recursos em testbeds de rede. Desenvolvido a partir de uma parceria entre o NICTA e o WINLAB foi concebido para ser utilizado no projeto ORBIT. Em constante evolução, hoje pode ser utilizado com diversos tipos de redes. O OMF é composto por um conjunto de serviços capazes de gerenciar de forma eficiente todos os recursos de um testbed (e.g. resetar nós, reportar seus status, instalar novos sistemas, etc). Para o pesquisador, o OMF vai um pouco além, ele provê um conjunto de ferramentas capazes de descrever, instrumentar, executar o experimento, além de coletar seus resultados.

3 De acordo com a Figura 1, o testbed gerenciado pelo OMF recebe a descrição do experimento, desenvolvida com o uso da linguagem OEDL (OMF Experiment Description Language). O OMF se encarrega de publicar, configurar e executar todas as definições para o experimento. Durante este processo, dados são medidos e coletados de acordo com a definição e podem ser armazenados e/ou reutilizados durante o experimento. Figura 1 - Visão Geral do OMF 3. Arquitetura do OMF Um framework é um conjunto de ferramentas provedoras de serviços. O OMF segue este conceito e categoriza suas ferramentas da seguinte maneira: Ferramentas de Gerenciamento: o Aggregate Manager (AM): gerencia todos os recursos de um testbed de maneira minuciosa. Não interage diretamente com o usuário. Ferramentas de Controle o Experiment Description (ED): é um script que define os recursos e ações para um experimento. É escrita com o uso da OEDL.

4 o Experiment Controller (EC): é a ferramenta que faz a comunicação entre o testbed e o usuário, processando a ED e instruindo o AM sobre quais recursos alocar para o experimento. Após a alocação, ele se comunica com cada RC, que de acordo com a ED, irá executar com eficiência o experimento. o Resource Controller (RC): também denominado de NodeAgent, é componente presente em cada um dos recursos existentes no testbed. É responsável pela execução das ações definidas para os recursos. Ferramentas de Medição o Measurement Library (ML): biblioteca de desenvolvimento, criada com a linguagem C, que deve estar disponível em todos os recursos utilizados no experimento, que se deseja monitorar. Na Figura 2 é possível observar onde os componentes supracitados se encaixam, além de ser possível visualizar o fluxo de interações entre eles. O primeiro evento deste fluxo se inicia quando o pesquisador submete a ED a uma nova instância do EC. Este, interpreta a ED e solicita ao AM que inicialize e configure os recursos definidos pelo pesquisador. Quando estes estão completamente inicializados, o EC sinaliza os RCs para executá-los, colocando o experimento no status de Em Execução (running). Durante este processo a aplicação deverá realizar medições, gerando dados que serão repassados para a ML, que poderá pré-processar e/ou armazenar tais informações.

5 Figura 2 - Arquitetura do OMF Esta arquitetura de compartilhamento e gerência recursos permite que vários pesquisadores executem seus experimentos paralelamente, num mesmo testbed, entretanto não há a possibilidade de utilizar o mesmo recurso em vários experimentos, ou seja, não existe compartilhamento do recurso (cada um deles é alocado a um único experimento). 4. Ciclo de vida de um experimento com o OMF No primeiro passo, (1) o usuário desenvolverá ou modificará uma aplicação capaz de ser executada em um sistema operacional (normalmente Linux) de um recurso do testbed. No caso de haver interesse em coleta de medições durante a execução do experimento, as configurações necessárias (chamadas à biblioteca OML) para o uso do OML deverão ser feitas no código da aplicação. O próximo passo é (2) definir como será o experimento. Para tal faz-se uso da ED, que descreve os recursos necessários para o experimento e suas respectivas configurações. Além disso, a ED descreverá as ações e sua ordem de execução. Como dito anteriormente a ED é descrita através da OEDL (mais informações em [2]). Definido o experimento, deve-se (3) executá-lo e para tal, os seguintes passos são necessários:

6 Ter acesso a um testbed baseado no OMF. Para tal é necessário abrir uma conta em um testbed já existente ou implantar um próprio (em [2] há tutoriais sobre como fazer isso); Reservar os recursos necessários. O esquema de reserva de recursos varia para cada testbed. Segundo [2] o WinLab faz essas reservas por horários, objetivando o compartilhamento dos recursos entre todos os usuários; Se certificar que as aplicações para o experimento e a ED são acessíveis pelo testbed (o testbed só acessa esses arquivos localmente); Rodar o experimento com o uso do OMF Tools, em especial o aplicativo omf (omf [subcomando argumento]). A Tabela 1 exibe a lista de subcomandos existentes no app omf; help Exibe a ajuda exec Executa o experimento load Carrega uma imagem (disk image) para os nós save Salva uma imagem nos nós tell Liga e desliga os nós stat Retorna o status dos nós Tabela 1 - Lista de subcomandos do app omf Caso o experimento faça uso do OML, após sua execução, as medições realizadas durante ele deverão ser (4) coletadas para análise. Durante um experimento um OLM Client coleta informações e as envia para o OML Collection Server que armazena as informações em uma base de dados com o ID igual ao do experimento. É através deste ID que a base de dados pode ser acessada para a coleta de informações. 5. Exemplo de um experimento Para demonstrar a aplicação prática do OMF, foi retirado de [2] um exemplo básico que demonstra como desenvolver, executar e obter os resultados de um experimento com OMF.

7 5.1. O cenário: A Figura 3 ilustra o cenário do experimento a ser ilustrado. Nela é possível verificar que existem 2 equipamentos wireless, sendo um deles transmissor e o outro receptor. A aplicação utilizada no transmissor é o OTG2, um gerador de tráfego UDP. A aplicação utilizada no receptor é o OTR2, um receptor de tráfego. A comunicação entre os dois equipamentos é através do ar, ou seja, fazendo uso de redes sem fio. Figura 3 - Cenário de um experimento Wireless Conforme indicado no item (3) da seção 4 deste artigo, o primeiro passo para utilizar um testbed é obter uma conta de acesso. Com o acesso ao testbed é necessário carregar a aplicação a ser utilizada no experimento, utilizando o comando omf load. Neste exemplo, a aplicação já está instalada no sistema base do recurso, tornando o comando omf load desnecessário. Após a carga da aplicação, para inicializá-la é necessário submeter a ED da aplicação para o EC. 1. defgroup('sender', [1,2]) { node 2. node.addapplication("test:app:otg2") { app 3. app.setproperty('udp:local_host', ' ') 4. app.setproperty('udp:dst_host', ' ') 5. app.setproperty('udp:dst_port', 3000) 6. app.measure('udp_out', :interval => 3) 7. } 8. node.net.w0.mode = "adhoc" 9. node.net.w0.type = 'g' 10. node.net.w0.channel = "6" 11. node.net.w0.essid = "helloworld" 12. node.net.w0.ip = " " 13. } defgroup('receiver', [1,3]) { node 16. node.addapplication("test:app:otr2") { app 17. app.setproperty('udp:local_host', ' ')

8 18. app.setproperty('udp:local_port', 3000) 19. app.measure('udp_in', :interval => 3) 20. } 21. node.net.w0.mode = "adhoc" 22. node.net.w0.type = 'g' 23. node.net.w0.channel = "6" 24. node.net.w0.essid = "helloworld" 25. node.net.w0.ip = " " 26. } whenallinstalled() { node 29. info "This is my first OMF experiment" 30. wait allgroups.startapplications 32. info "All my Applications are started now..." 33. wait allgroups.stopapplications 35. info "All my Applications are stopped now." 36. Experiment.done 37. } Figura 4 - Exemplo de uma Experiment Description A Figura 4 exemplifica a ED para o experimento em questão, escrita na lingualgem OEDL. Nela observa-se detalhes descritivos sobre os recursos requeridos e o conjunto de ações a serem executadas para o experimento. As linhas 1 e 15 definem novos grupos de recursos denominados de Sender e Receiver identificados pelos identificadores únicos 1,2 e 1,3 respectivamente. Nas linhas de 2 à 7 definições a respeito da aplicação forma feitas. Na linha 2 uma aplicação de nome test:app:otg2 é associada a este grupo de recursos, ou seja, quaisquer recursos que estejam vinculados a este grupo terão a aplicação especificada instalada. Na linha 3 a propriedade local_host da aplicação foi definida com o número de ip indicando o endereço do remetente. As linhas 4 e 5 indicam o endereço e porta do destinatário. A linha 6 diz que a aplicação fará medições no ponto de medição (ver mais informações sobre OML em [2]) especificado como udp_out. As linhas de 8 a 12 indicam propriedades para o grupo sender. A linha 8 diz que a interface wireless w0 dos recursos deste grupo ficarão no modo adhoc. As linhas 9 e 10 indicam que a mesma interface transmitirá utilizando o protocolo g através do canal 6. O SSID da rede será helloworld e o IP da mesma interface será As linhas de 15 a 26 indicam as mesmas configurações, porém para o grupo de recursos receiver.

9 As linhas de 28 a 37 descrevem as ações. O OMF utiliza o modelo de máquinas de estado para descrever as ações a serem executadas num experimento, o que quer dizer que ações estão associadas a estados, e são executadas quando os estados são alcançados. Um estado no OMF pode ser caracterizado por diferentes condições, como por exemplo, o estado de todos os recursos serem ligados, ou quando uma variável atingir um determinado valor, entre outros. No experimento em questão, há apenas uma ação, nomeada de whenallinstaled, na linha 28, que basicamente verifica quando todos os nós estão ligados e todas as aplicações estão instaladas. As linhas subseqüentes definem como esta ação. As linhas 29,32 e 35 laçam no console algumas mensagens indicando o status do experimento. A linha manda o EC parar por 10 s. esta paralisação é recomendada para garantir que todo os recursos do testbed alocados para o experimento foram configurados. A linha 31 diz aos grupos para inicializar as aplicações associadas a eles. A linha 33 solicita uma pausa de 30 s, garantindo que o tráfego enviado do transmissor chegará ao receptor. A linha 34 manda que os grupos parem a execução de suas aplicações. A linha 36 encerra o experimento limpando todas as configurações e ações realizadas anteriormente. Tudo pronto, é hora de executar o experimento. Mas antes é importante se certificar dos seguintes itens: Ter reservado um horário para a execução do experimento no testbed; Estar com o console do testbed acessível; Ter carregado a aplicação para o testbed; Agora é necessário criar uma nova instância do EC, responsável pela execução do experimento. Isto é feito com uma chamada ao aplicativo omf, passando o subcomando exec. Este comando deverá receber uma entrada, que será a ED, que estará em uma arquivo texto simples com uma extensão. Seguido os padrões do OMF todo arquivo de ED deverá ter a extensão.rb. dessa forma a chamada ao omf ficará da seguinte maneira: omf exec myed.rb, sendo myed.rb o arquivo de ED. Após a conclusão da execução do experimento, graças ao uso da OML, é possível obter dados a respeito dele. Os dados coletados estão armazenados em

10 um banco de dados pertencente ao OML Measurement Collection Server. Cada experimento executado cria um novo banco de dados com o mesmo nome do identificador do experimento. Cada instalação do OMF possui um ou mais AM que provêm uma série de recursos para gerenciamento, dentre eles um portal no qual também é possível acessar os resultados. 6. Conclusão Este artigo apresentou uma visão geral a respeito do OMF, um framework bastante completo, capaz de gerenciar, controlar e realizar medições em testbeds, além de possuir uma arquitetura de compartilhamento e gerência de recurso, que apesar de seu grande potencial, não é capaz de compartilhar recursos de forma simultânea. Apesar das deficiências do OMF, em seu estágio atual ele se mostra muito eficiente e num estágio de desenvolvimento bastante dinâmico, caracterizando seu amadurecimento. Seu objetivo é atingir um patamar que consiga transformar testbeds em ambientes de teste duradores, eficientes e bastante usáveis. Referências [1]. [2].