Arquitetura do Módulo SDNMon

Conforme ilustra a Figura 7, o desenvolvimento do módulo de monitoramento SDN- Mon é feito sob o cenário de SDN, composta por dispositivos de rede OpenFlow, sendo os dispositivos de rede responsáveis pela composição do Plano de Dados e ao menos um controlador responsável pela composição do Plano de Controle. Além disso, todas as infor- mações coletadas pelo módulo de monitoramento estão disponíveis utilizando o protocolo RESTful, através de uma extensão à API northbound do controlador. Nesta interface, a Aplicação de Monitoramento (Seção 4.1.6) proposta consegue interagir com o Módulo de Monitoramento proposto (SDNMon), obtendo dados para apresentação em uma interface

60 Capítulo 4. SDNMon e MP-Routing

gráĄca e, também, indicando qual o nível de granularidade desejado. O diagrama de classes do SDNMon está detalhado no Apêndice A.

Figura 7 Ű Uma instância da Arquitetura SDN com as extensões de monitoramento. O SDNMon é desenvolvido como uma extensão ao controlador Floodlight, sendo que o módulo SDNMon proposto é responsável por coletar, processar e armazenar os dados processados em um banco de dados. A Figura 8 ilustra a arquitetura do SDNMon junta- mente com sua interação com outros módulos do controlador Floodlight e com um Banco de Dados. Os componentes do SDNMon e do Floodlight estão detalhados abaixo:

4.1. SDNMon 61

Componentes do SDNMon:

❏ Gerenciador: Responsável por fazer o gerenciamento do módulo SDNMon junto ao Floodlight, deĄnir a ordem de recebimento de mensagens; o nome; o registro e o fornecimento de serviços oferecidos pelo módulo, tanto via API RESTful, como pela API Java. O Gerenciador é, também, responsável por instanciar o Escalonador e o Processador;

❏ Processador: Coleta os dados do Banco de Dados armazenados previamente pelas

Threads de monitoramento, e os processa para deixar em um formato padronizado

para uso futuro. Com isso, o processador permite que dados coletados, indepeden- temente do mecanismo de monitoramento e da granularidade da Thread de Monito- ramento, estejam em um formato adequado para o cálculo de algumas métricas de QoS da rede, tais como vazão, atraso de propagação e perdas de pacote. Estes da- dos formatados são importantes também para o oferecimento destas métricas para aplicações, através da API Restful, ou para outros módulos, através da API Java; ❏ Escalonador: Responsável por consultar a topologia da rede, acessando o módulo

Gerenciador de Topologia fornecido pelo componente Gerenciador, e, inicialmente, criar uma thread de monitoramento para cada comutador da rede. Este módulo também é responsável por analisar a carga coletada pelas Threads de Monitoramento e à medida que o tráfego da rede vai variando, este componente é responsável por instanciar, destruir ou realocar novas threads do Pool de Threads, como também, deĄnir o escopo das mesmas, para o monitoramento da rede;

❏ Thread de Monitoramento: Responsável por coletar as estatísticas dos comuta- dores, com o mecanismo de monitoramento (polling ou push) e através do escopo (por porta, grupo, Ćuxo ou Ąla) recebido do Escalonador;

❏ Pool de Threads: Mantém as threads que foram instanciadas e estão inutilizadas no momento. Quando o escalonador percebe que é necessário utilizar alguma thread para o monitoramento, ele ativa esta thread, que provavelmente está ŞdormindoŤ, e deĄne um escopo de monitoramento para ela. Com o pool de threads, reduz-se o aumento do gasto computacional para criar e deletar threads;

❏ Componentes de Monitoramento: São componentes responsáveis por coletar as estatísticas da rede. Para a coleta das estatísticas, é usado um mecanismo de mo- nitoramento, como o polling, o sFlow ou algum outro, futuramente implementado. Após a coleta da estatística, estes dados são armazenados no Banco de Dados; ❏ Banco de Dados: O Banco de Dados armazena dados relativos ao monitoramento

(SDNMon) e ao módulo de multi-caminhos (MP-Routing), este último módulo é detalhado na Seção 4.2. A base de dados de monitoramento é povoado da seguinte

62 Capítulo 4. SDNMon e MP-Routing

forma: todos os dados coletados pelo SDNMon são armazenados na Base de Dados do tipo chave-valor pelas threads. A chave refere-se a um dispositivo de rede, uma porta, uma Ąla ou a um Ćuxo. No caso de um dispositivo de rede, das portas ou das Ąlas, o campo valor armazena dados referentes ao volume agregado de tráfego sendo experimentado neste componente. No caso de um Ćuxo, o valor do objeto é o conjunto de arestas do caminho percorrido pelo Ćuxo; para cada aresta há uma outra entrada na base de dados, cuja chave associa o Ćuxo ao par de comutadores que compõem a aresta e o valor é o conjunto de informações relativas à mesma. Desta forma, as threads podem atualizar as arestas concorrentemente.

Componentes do Floodlight:

❏ Rest API Server: Todos os módulos que desejam disponibilizar seus serviços através da API RESTful devem registrar-se no Rest API Server. Este módulo expõe uma API Java onde o SDNMon, ou qualquer outro módulo, pode deĄnir a

Uniform Resource IdentiĄer (URI) para acessar os serviços expostos e qual o método

usado para os pedidos Hypertext Transfer Protocol (HTTP), tais como o Get e o

Put. Lembrando que os dados ofertados através da RESTful API estão no formato JavaScript Object Notation (JSON), por padrão;

❏ Gerenciador de Topologia: Este módulo é responsável por manter a topologia da rede, sendo que a topologia é atualizada sempre que acontece algum evento na rede, por exemplo, quando alguma interface do comutador é desligada ou ligada. Este módulo disponibiliza a topologia da rede através de sua API Java, onde iremos, posteriormente, acessar esta API para retornar a topologia da rede que é usada para alimentar o escalonador do SDNMon, possibilitando ao escalonador criar, deletar e atualizar as threads;

❏ Outros módulos: O Floodlight possui mais de uma dúzia de módulos e descreve- remos apenas os dois módulos que mais interagem com o SDNMon. O Floodlight fornece alguns módulos interessantes, como o Forwarding, para o roteamento de pacotes; um módulo de Firewall; um módulo para o descobrimento de arestas,

LinkDiscoveryManager, através do envio de mensagens Link Layer Discovery Pro- tocol (LLDP); entre outros.