• Nenhum resultado encontrado

Algoritmo 6 – Balanceamento de Carga

5.2 Camada de Controle

5.2.1

Serviço de Monitoramento

Para implementar o serviço de monitoramento foi utilizada a API do Opendaylight versão Hydrogen. Além disso foi adotada a linguagem de programação Java. Para que a solução proposta fosse capaz de prover o monitoramento de tráfego em alguns níveis de granularidade (por porta do switch, por fluxo e por serviço), foi necessário obter as informações sobre toda a topologia da rede, sendo utilizado o modelo proposto para representar cada uma das entidades. Nesse processo, foram utilizados os seguintes objetos remotos providos pela API do OpenDaylight:

• TopologyNorthboundJAXRS - utilizado para obter dados da topologia da rede; • SwitchNorthbound - utilizado para obter dados de cada switch da rede;

• HostTrackerNorthbound - utilizado para obter todos os hosts ativos na rede, bem como o switchao qual cada um se encontra conectado.

5.2.1.1 Problema de Persistência dos Dados Estatísticos

Além desses objetos, foi utilizado o StatisticsNorthbound, com o objetivo de obter os dados estatísticos previstos pelo protocolo OpenFlow (total de pacotes e total de bytes). A coleta destes dados é feita de forma acumulativa, para cada regra presente na tabela de fluxos, de cada um dos switches, ou seja, é armazenado sempre o total de pacotes e o total de bytes que passaram por cada uma, desde o momento em que foram criadas. O problema disso, é que caso um determinado switch possa ser utilizado por mais de um caminho em um mesmo fluxo, não será possível saber a qual caminho pertencem os dados estatísticos. Por exemplo, caso exista uma regra para um determinado fluxo X (IP de origem 10.0.0.1 e IP de destino 10.0.0.2, por exemplo), que tenha como ação encaminhar os pacotes para a porta 2 do switch, caso seja feita uma mudança de caminho, que pode ser simplesmente uma alteração na ação, indicando que os pacotes devem ser encaminhados para a porta 3, toda a informação estatística obtida será perdida, pois para o protocolo OpenFlow uma nova regra foi criada.

Capítulo 5. Serviço de Monitoramento para SDN 51

Algoritmo 1 Manutenção da Topologia

1: procedure manterTopologiaRede() 2: enlacesRede ← obterEnlacesRede()

3: if sizeo f (enlacesRede) > 0 then

4: while i< sizeo f (enlacesRede) do

5: cadastrarS witch(enlacesRede[i].getOrigem()) 6: cadastrarS witch(enlacesRede[i].getDestino()) 7: cadastrarEnlaceS wS w(enlacesRede[i].getOrigem(), enlacesRede[i].getDestino()) 8: i ← i+ 1 9: else

10: switchesRede ← obterS witchesRede()

11: while i< sizeo f (switchesRede) do

12: cadastrarS witch(switchesRede[i])

13: i ← i+ 1

14: hostsRede ← obterHostsRede()

15: while i< sizeo f (hostsRede) do

16: cadastrarHost(hostsRede[i], hostsRede[i].getS witch())

17: i ← i+ 1

Algoritmo 2 Definição dos Caminhos

1: procedure montarCaminhosHosts(switchInicioCaminho, switchFimCaminho, switchesCaminho)

2: hostsInicioCaminho ← switchInicioCaminho.getHostsS witch()

3: if sizeo f(hostsInicioCaminho) > 0 ∧ switchInicioCaminho.getId() , switchFimCaminho.getId() then

4: hostsFimCaminho ← switchFimCaminho.getHostsS witch() 5: while i< hostsInicioCaminho do 6: while j< hostsFimCaminho do 7: cadastrarCaminhoHosts(hostsInicioCaminho[i], hostsFimCaminho[ j], switchesCaminho) 8: j ← j+ 1 9: i ← i+ 1

10: enlacesS witch ← switchInicioCaminho.getEnlaces() 11: while i< enlacesS witch do

12: montarCaminhosHosts(switchInicioCaminho, enlacesS witch[i], switchesCaminho)

13: i ← i+ 1

Para contornar este problema, foi necessário adicionar ao serviço de monitoramento proposto, um mecanismo que identifica e separa os caminhos presentes entre os hosts ativos na rede. Dessa forma, caso ocorra alguma mudança de caminho, além de não ocorrer a perda dos dados estatísticos coletados, é possível identificar a qual caminho cada conjunto de dados pertence. A coleta destes dados, é feita através do mecanismo de polling, que consiste em consumir a API do controlador de tempos em tempos.

Capítulo 5. Serviço de Monitoramento para SDN 52

Algoritmo 3 Definição dos Fluxos

1: procedure definirFluxos()

2: caminhosRede ← obterCaminhosRede()

3: while i< sizeo f (caminhosRede) do

4: cadastrarFluxo(caminhosRede[i].getHostOrigem(), caminhosRede[i].getHostDestino(), caminhosRede[i])

5: i ← i+ 1

namento, com o objetivo de capturar todo o tráfego de dados da rede, e representá-lo de acordo com o modelo proposto. Estas etapas são descritas a seguir:

• Manutenção da Topologia - etapa onde são obtidas todas as informações sobre todos os switchespresentes na rede, bem como os seus enlaces, com o objetivo de montar toda a topologia atual da rede. Além disso, são obtidos os hosts ativos presentes na rede, bem como a informação sobre a qual switch cada um se encontra conectado. O Algoritmo 1 descreve os passos realizados durante esta etapa;

• Definição dos Caminhos - uma vez identificados os hosts ativos da rede, é feito o mapea- mento sobre os caminhos possíveis entre eles, de acordo com a topologia atual da rede. Os passos realizados durante esta etapa podem ser vistos no Algoritmo 2;

• Definição dos Fluxos - cada host apresenta o seu endereço IP, sendo possível identificar quais fluxos poderão atuar na rede. Com isso, são salvos todos os fluxos e os seus respecti- vos caminhos, com o objetivo de terem os seus dados estatísticos atualizados. O Algoritmo 3 descreve os passos realizados durante esta etapa;

• Definição dos Serviços - neste ponto, é utilizada como parâmetro uma lista contendo os serviços que serão permitidos na rede. Pelo fato de todos os hosts ativos já terem sido identificados, é possível salvar todos os serviços e os seus respectivos caminhos, com o objetivo de terem os seus dados estatísticos atualizados. Os passos realizados durante esta etapa podem ser vistos no Algoritmo 4;

• Coleta de Dados - é utilizado o mecanismo de polling, obtendo assim os dados estatísticos de cada regra presente em cada switch, sendo atualizados o total de pacotes e o total de bytesde cada fluxo e de cada serviço. O Algoritmo 5 descreve os passos realizados durante esta etapa.

5.2.2

Serviço de Balanceamento de Carga

Adicionalmente, foi desenvolvido um serviço de balanceamento de carga, que tem como principal objetivo, utilizar os dados coletados pelo serviço de monitoramento aqui proposto,

Capítulo 5. Serviço de Monitoramento para SDN 53

Algoritmo 4 Definição dos Serviços

1: procedure definirServicos(listaServicos) 2: caminhosRede ← obterCaminhosRede()

3: while i< sizeo f (listaS ervicos) do

4: while j< sizeo f (caminhosRede) do

5: cadastrarS ervico(caminhosRede[ j].getHostOrigem(),

caminhosRede[ j].getHostDestino(), listaS ervicos[i].getProtocoloT ransp(), listaS ervicos[i].getPorta(), caminhosRede[ j])

6: j ← j+ 1

7: i ← i+ 1

Algoritmo 5 Coleta de Dados

1: procedure coletarDados()

2: caminhosRede ← obterCaminhosRede()

3: while i< sizeo f (caminhosRede) do

4: cadastrarFluxo(caminhosRede[i].getHostOrigem(), caminhosRede[i].getHostDestino(), caminhosRede[i])

5: i ← i+ 1

e alterar o estado da rede, visando uma melhora na sua utilização. Este serviço foi desenvol- vido através da linguagem de programação Java, e atua como um subserviço do serviço de monitoramento de tráfego.

Para aplicar o balanceamento de carga, foi necessário não somente conhecer todos os caminhos da rede, mas também ter a capacidade de alterar os fluxos e os serviços presentes em cada um deles, caso isso fosse necessário. Para tal, foi utilizado o seguinte objeto remoto provido pela API do OpenDaylight:

• FlowProgrammerNorthbound - através deste objeto, foi possível obter informações sobre todas as regras cadastradas em cada um dos switches da rede, permitindo alterá-las, removê- las, ou adicionar novas, caso seja necessário, tudo com o objetivo de alterar o caminho de um determinado fluxo ou serviço.

O serviço de balanceamento de carga, apresenta três abordagens distintas, com relação à escolha de qual caminho deverá ser utilizado por cada um dos fluxos e serviços presentes na rede. Para tomar esta decisão, foram implementados os seguintes algoritmos de escalonamento:

1. Round-Robin - algoritmo implementado através de uma fila circular, tradicionalmente utilizado pelos sistemas operacionais para realizar o escalonamento de processos. Neste contexto, cada processo ocupa uma posição da fila, sendo executado pelo processador durante um determinado período de tempo. Após o término deste intervalo de tempo, é executado o próximo processo da fila. Este ciclo se mantém até que não exista mais nenhum processo para ser executado. Trazendo este conceito para o contexto aqui analisado, a fila

Capítulo 5. Serviço de Monitoramento para SDN 54

Algoritmo 6 Balanceamento de Carga

1: procedure aplicarBalanceamentoCarga(tipoBalanceamento) 2: switch tipoBalanceamento do 3: case roundRobin 4: aplicarRoundRobin() 5: case bandwidthBased 6: aplicarBandwidthBased() 7: case roundRobinAndBandwidthBased 8: aplicarRoundRobinBandwidthBased() 9: case nenhum 10: exit()

cíclica é composta pelos caminhos da rede, sendo assim, sempre que um novo fluxo ou serviço precise ser alocado em um determinado caminho, é escolhido o primeiro da fila, garantindo uma distribuição uniforme entre todos os caminhos da rede;

2. Bandwidth-Based - assim como o Round-Robin, este algoritmo foi utilizado para determi- nar em qual caminho um determinado fluxo/serviço deverá seguir. A principal diferença com relação ao Round-Robin, é o fato de não alocar um fluxo/serviço no primeiro caminho disponível. Para isso, é feita uma relação entre a utilização atual de cada caminho (total de bytestrafegados em um determinado instante) e um limiar máximo de utilização definido (número que indica o percentual máximo de utilização que cada caminho pode atingir). Por exemplo, foi definido como limiar de utilização dos caminhos, um valor máximo de 70%, e existem dois caminhos na rede, um deles está com 40% de utilização, e o outro com 60%. Caso um novo fluxo/serviço precise ser alocado em algum caminho, o caminho com 40% de utilização será escolhido;

3. Round-Robin+ Bandwidth-Based - apesar da política de atendimento parecer justa, o Round-Robin pode acabar alocando fluxos/serviços de maior carga em um mesmo caminho, visto que ele não leva em consideração o tráfego gerado na rede para fazer as alocações, tornando-se ineficiente. Em contrapartida, calcular a utilização dos caminhos para aplicar a alocação, pode ser algo custoso. Com isso, foi proposta uma união entre os dois algoritmos, que visa utilizar o melhor de cada um deles, fazendo uma alocação inicial utilizando o Round-Robin, e aplicando posteriormente o Bandwidth-Based caso seja necessário.

O Algoritmo 6 descreve as etapas realizadas durante a execução do serviço de balancea- mento de carga. Para executar o serviço, é necessário informar qual tipo de balanceamento será aplicado à rede.

Capítulo 5. Serviço de Monitoramento para SDN 55

Figura 5.3 – Página inicial da aplicação Web. Fonte: Criada pelo autor

Figura 5.4 – Página da topologia da rede. Fonte: Criada pelo autor

Documentos relacionados