Teste de fluxo

Este teste tem como objetivo conferir se os fluxos que passam pelas portas dos Switches estão corretos. Ele é realizado com base na comparação dos dados de fluxo agregado, informações do switch e estatística de pacotes, presentes na interface web, com o que se é esperado teoricamente de acordo com a topologia previamente definida no mininet.

Este teste foi realizado com uma topologia linear com quatro switches e quatro hosts, como mostrado na Figura 30.

Figura 30 - Topologia linear utilizada no teste.

Esta topologia foi criada no Mininet e analisada na página web. Para que se pudesse fazer a análise, foram enviados pacotes do host 2 para o host 3, através do comando iperf h2 h3, no terminal da máquina virtual onde o Mininet estava rodando.

A primeira análise realizada foi a de “Informações do Switch”. Foi possível perceber que, ao se enviar pacotes entre h2 e h3, a contagem de bytes e a contagem de pacotes aumentou consideravelmente no fluxo cuja origem é o host 2 (IP 10.0.0.2) e o destino é o host 3(IP 10.0.0.3). Além disso, a quantidade de pacotes e bytes com origem no host 3 e destino no host 2 também tiveram um pequeno aumento. Isto se deve aos pacotes ACK enviados pelo host 3 ao host 2. Com relação aos outros fluxos, as contagens permaneceram com um número baixo, como mostrado na Figura 31.

Figura 31 - Informações do switch para o teste realizado.

A segunda análise foi a de “Fluxo Agregado” e, assim como na de “Informações do Switch”, pode-se perceber que a contagem de pacotes e a contagem de fluxos é muito maior no switch 2 e 3. Além disso, observamos que, como era esperado, a contagem dos fluxos do switch 2 e do 3 é igual a 11, o que equivale a soma dos fluxos mostrado na Figura 31 mais o fluxo do controlador, como mostrado na Figura 32.

Figura 32 - Contagem dos fluxos do teste.

O último teste realizado foi o de “Estatísticas Pacotes” e, como era esperado, com base na topologia da rede, é possível ver que ocorreu o seguinte tráfego: Os pacotes do iperf foram enviados pelo host 2 ao switch 2, que os recebeu na porta 1. Posteriormente, o switch 2 transmitiu os pacotes para o switch 3 através da sua porta 3. Na sequência, o Switch 3 recebeu os pacotes em sua porta 2 e, por fim, o switch 3 enviou os dados para o host 3, através de sua porta 1

A Figura 33 e a Figura 34 representam a Estatística de pacotes para os switches 2 e 3, respectivamente. Já a Figura 35 mostra o tráfego que ocorreu na rede.

Figura 33 - Estatística de Pacotes para o switch 2.

Figura 34 - Estatística de Pacotes para o Switch 3. .

v

Figura 35 - Tráfego na rede.

Realizamos agora a mesma análise anterior, porém com pacotes sendo enviados de h1 para h4.

Na análise de “Informações do Switch”, foi observado um comportamento similar ao da análise anterior, onde, neste caso, a contagem de bytes e a contagem de pacotes aumentou consideravelmente no fluxo cuja origem é o host 1 (IP 10.0.0.1) e o destino é o host 4(IP 10.0.0.4). Além disso, a quantidade de pacotes e bytes com origem no host 4 e destino no host 1 também tiveram um pequeno aumento. Isto se deve aos pacotes ACK enviados pelo host 4 ao host 1, como mostrado na Figura 36.

Figura 36 - Análise de Informações do Switch.

No “Fluxo Agregado”, foi percebida uma contagem de pacotes e de bytes alta em todos os switches, como visto na Figura 37. Isso se deve ao fato do tráfego passar por todos os switches da rede para ir do host 1 para o host 4.

Figura 37 - Análise do Fluxo Agregado.

Na sequência, o teste de “Estatística de Pacotes” mostrou que os tráfegos nas portas correspondem a topologia linear escolhida, como mostrado na Figura 38, Figura 39 e Figura 40.

• Os pacotes do iperf foram enviados pelo host 1 ao switch 1, que os recebeu na porta 1

• Posteriormente, o switch 21 transmitiu os pacotes para o switch 2 através da sua porta 2

• Switch 2 recebeu os pacotes em sua porta 2

• Switch 2 enviou os dados para o switch 3, através de sua porta 3 • Switch 3 recebeu os pacotes em sua porta 2

• Switch 3 enviou os dados para o switch 4, através de sua porta 3 • Switch 4 recebeu os pacotes em sua porta 2

• Por fim, o switch 4 enviou os pacotes para o host 4 através da porta 1.

Figura 38 - Estatística de Pacotes para o switch 1.

Figura 40 - Estatística de Pacotes para o switch 3.

Figura 41 - Estatística de Pacotes para o switch 4.

Figura 42- Análise de Fluxo Agregado.

6.2

Teste de carga

Este teste tem como objetivo buscar o tamanho máximo da rede que a aplicação suporta e, para isso, foram testados dois tipos topologia (linear e em árvore), onde foram adicionados hosts e switches. Para que essas topologias fossem testadas, foram enviados pacotes entre os diferentes hosts através do comando iperf. Vale ressaltar que, devido à complexidade das topologias utilizadas foi necessário o envio de vários iperfs, que foram feitos automáticamente, através de um script contruido baseado numa API do Mininet.

Primeiramente, determinou-se o tamanho da rede suportado para o intervalo padrão entre as chamadas Rest para inserção de dados no banco, isto é, 30 segundos. A fim de se estabelecer uma margem de segurança, foram consideradas apenas topologias que tivessem o tempo de inserção na base de dados menor do que 25 segundos.

Após a observação do funcionamento da aplicação, foi verificado que os dados com tempo de inserção maiores foram os relativos à tabela de FluxosSwitches. Como já dito anteriormente, esta tabela armazena informação de tráfego de todos os fluxos

possíveis entre diferentes hosts em diferentes switches. Desta forma, o número de instâncias de dados a ser inserido nesta tabela em cada chamada REST era consideravelmente maior do que no restante.

A fim de se obter a informação do tempo de cada requisição, a função para inserção no banco de dados deveria ser chamada uma única vez e, na sequência, seria feita uma consulta ao banco, verificando a diferença de tempo entre a primeira e a última inserção na tabela FluxosSwitches. Com isso, seria possível comparar tal valor com os 25 segundos previamente estipulados. Feito isto, seria possível concluir se a topologia poderia ser encaminhada para o próximo teste.

Com esta primeira etapa realizada, seria possível iniciar uma segunda, testar a página web e verificar a taxa do controlador e as funcionalidades do site, para verificar se não havia queda de desempenho.

Feito isto, foi possível se fazer uma breve análise acerca do desempenho da aplicação, tanto do ponto de vista computacional, ou seja, a avaliação sobre quais topologias suportam uma maior quantidade de dados sendo inseridos na base de dados, quanto da rede em si, isto é, as topologias que suportam um maior número de hosts.

Por fim, foram testadas topologias cujo tempo de inserção é superior ao tempo padrão (ou seja, maior que os 25 segundos estipulados). A finalidade destes testes é orientar possíveis usuários acerca do intervalo de tempo indicado a ser usado entre as requisições para diversas topologias. Este intervalo, como já foi dito em sessões anteriores, não é configurável através da página principal, sendo assim, é definido na aplicação de inserção no banco de dados.

Desta forma, foi possível entender o comportamento da aplicação desenvolvida e, também, os melhores casos de uso da mesma.

6.2.1 Topologia linear

Primeiramente foram testadas topologias lineares com diferentes números de hosts e switches. A metodologia utilizada foi a de fixar um número de hosts ou switches e assim variar o outro até que se chegasse a um valor limítrofe.

No primeiro teste foi buscado o número máximo de switches com apenas 1 host por switch, cujo tempo de inserção de dados não fosse maior do que 25s. Após a realização de diversos testes com diferentes números de switches, a quantidade máxima de switches suportada para tal intervalo foi de 35 switches. Os tempos de inserção variaram entre 22 e 24 segundos e o número de matches para essa topologia foi de 15470. Ao seguir para o teste da página web, foi constatado um desempenho bom e as taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 43.

Figura 43 - Taxas do controlador.

Na sequência foi realizado um teste que buscava o número máximo de hosts com apenas 1 switch. O resultado obtido foi o de 42 hosts. O número de matches foi 1722. Já a inserção de dados demorou entre 20 e 23 segundos para ser completada.

Ao seguir para o teste da página web, foi contatado um desempenho bom e as taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 44.

O último teste buscava um número intermediário de hosts e switches cujo tempo de inserção de dados não fosse maior do que 25s. Definiu-se que a cada switch seriam ligados 8 hosts. após a realização de diversos testes a quantidade de switches que limitou o uso da rede foi de 6 switches. O número de matches foi 6736 e inserção de dados com esse número variou entre 18 e 20 segundos

Ao seguir para o teste da página web, foi constatado um desempenho bom e as taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 45.

Figura 45 - Taxas do controlador.

Algo interessante de se notar foi o fato de que o número de matches e, consequentemente, o de fluxos foi consideravelmente maior no primeiro caso, onde se tinha um host por switch. Isto ocorre pois a aplicação Web utiliza o Ajax para realizar as chamadas Rest e as inserções no banco, ou seja, as inserções são assíncronas. Basicamente, como tais chamadas são feitas a partir do dpid, o número de switches é igual ao número de chamadas e, consequentemente, ao número de processos em paralelo para inserção de dados na base.

Desta forma, no primeiro caso de topologia linear foram feitas 35 chamadas Rest resultando em 35 inserções na base de dados, todas feitas de maneira paralela.

Já para o segundo caso, onde só havia um switch o número de matches que limitou o uso da aplicação foi consideravelmente menor (aproximadamente 9 vezes menor). Isto pois a inserção destes dados não foi feita de maneira paralela.

Como esperado, o terceiro caso apresentou um resultado intermediário, quase 4 vezes melhor que o caso 2 porém aproximadamente 2,3 vezes pior que o caso 1.

Entretanto, este foi o caso onde houve o maior número de hosts conectados à rede, 48. Já o primeiro e o segundo caso tiveram, respectivamente 35 e 42, respectivamente

A conclusão a que se chega é a de que dado um número x de hosts, se a topologia tem um número demasiado de hosts ligados a um mesmo switch, é preciso atualizar alguns parâmetros da interface para que se tenha uma resposta correta na mesma.

6.2.2 Topologia em árvore

Foram testadas diferentes topologias em árvore com diferentes números de camadas e ramos e, para cada número de camadas, encontrou-se o número máximo de ramos suportados para que não se ultrapassasse os 25 segundos estipulados.

O número padrão de ramos é 2 e, para esta quantidade, o número máximo de camadas que a aplicação suportou foi 5. A inserção de dados com esse número demorou entre 12 e 16 segundos para ser completada e o número de matches foi 7264.

Ao seguir para o teste da página web, foi constatado um desempenho bom e as taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 46.

Figura 46 - Taxas do controlador.

Na sequência foram testados diversos números de ramos diferentes para 3 camadas e, como resultado, o número máximo de ramos que a aplicação suportou foram 3. A inserção de dados com tal número demorou de 3 a 4 segundos para ser completada

e o número de matches foi 2970, valores que estão dentro dos padrões previamente definidos.

Como esperado, o desempenho da página não ficou comprometido. As taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 47.

Figura 47 - Taxas do controlador.

Por último foram testados diversos números de ramos diferentes para 2 camadas e, como resultado, o número máximo de ramos que a aplicação suportou foram 6. A inserção de dados com esse número demorou entre 9 e 11 segundos para ser completada e o número de matches foi 3420, valores que estão dentro dos padrões previamente definidos.

Feito o teste na página web, foi constatado novamente um desempenho bom e as taxas de bits/s e pacotes/s no controlador estão indicadas na Figura 48.

Figura 48 - Taxas do Controlador.

Confirmando aquilo constado na seção correspondente às topologias lineares, topologias com maiores números de switches fazem com que a aplicação Web possua um melhor desempenho. Entretanto, a comparação neste caso é mais complicada de ser feita visto que uma simples mudança como a adição de uma nova camada ou um novo ramo gera diversos nós na rede.

No fim, o que se pode concluir é que, do ponto de vista de número de hosts suportados, a topologia que melhor se adaptou a aplicação foi a terceira, totalizando 36 hosts. A primeira e a segunda possuem, respectivamente, 28 e 27 hosts.

6.2.3 Outros intervalos

A finalidade desta seção é demonstrar que os intervalos de tempo de topologias não suportadas pela aplicação quando utilizado o intervalo padrão. Para tal, o tempo de inserção foi testado diversas vezes para que se pudesse ter uma noção mais acurada a seu respeito. Evidentemente, recomenda-se que, caso a aplicação seja utilizada para uma das topologias testadas, utilize-se um intervalo relativamente maior do que o aqui obtido. Os resultados obtidos estão expressos na Tabela 7 para topologias lineares e na Tabela 8 para topologias em árvores.

Tabela 7 - Intervalo de tempo não suportado pela topologia linear Topologia Linear Número de Switchs Número de Hosts por Switch Tempo Máximo(s) Tempo Mínimo Número de Matches Número Total de Hosts 40 1 50 42 22880 40 45 1 71 62 32340 45 50 1 99 86 44100 50 1 50 50 40 2450 50 1 60 89 81 3540 60 1 70 148 134 4831 70 1 80 228 218 6321 80 7 8 40 34 10249 56 8 8 60 52 14785 64 10 8 162 131 27441 80 5 16 175 125 16651 80

Tabela 8 - Intervalo de tempo não suportado pela topologia em árvore. Topologia em Árvore Número de Camadas Número de ramos Tempo Máximo(s) Tempo Mínimo Número de Matches Número Total de Hosts 6 2 122 106 37057 64 4 3 162 148 39243 81 3 4 88 75 17857 64

Mais uma vez, percebe-se que para topologias com baixo número de switches, o desempenho da aplicação, ou seja, o tempo de inserção de uma determinada quantidade de linhas (aproximadamente o número de matches) é consideravelmente pior do que em topologias em que há muitos hosts ligados a um switch.

Um bom modo de se perceber isso é analisando as topologias lineares cujo número de hosts é 80.

No caso em que há apenas um switch, o número de matches é de apenas 6321. Porém, o tempo de inserção pode chegar a quase 230 segundos.

No caso de 5 switches, o número de matches é de 16651 e o tempo de inserção varia entre 125 e 175 segundos, uma diferença considerável em comparação à topologia descrita no parágrafo anterior.

Por fim, no caso de 10 switches, o número de matches é de 27441, com o tempo variando entre 131 e 162 segundos.

Em uma análise de taxa de inserção, considerando-se o tempo máximo obtido para essas topologias, tem-se 79 inserções por segundo para o primeiro caso, 95,15 para o caso com 5 switches e 169,4 para o caso de 10 switches.

Com base nesses resultados, foi demonstrado que a aplicação aqui desenvolvida tem um desempenho computacional melhor em topologias com maior número de switches. Isto valida a hipótese de que o uso do Ajax para paralelizar as inserções de dados influencia de maneira substancial no desempenho da rede.

6.3

Teste de topologia

Este teste tem como objetivo testar a funcionalidade da topologia de rede,e, para isso foram testadas três topologias diferentes: anel, linear e árvore.

Para o primeiro teste utilizamos a topologia em árvore com 4 camadas e dois ramos e obtivemos, como esperado, a topologia da Figura 49.

A seguir realizamos um segundo teste, também com a topologia em árvore, só que com 3 camadas e 3 ramos e obtivemos o resultado da Figura 50.

Figura 50 - Topologia em árvore utilizada para o teste de topologia

Na sequência, foi feito um teste de topologia linear com 7 switches e foi obtido, como esperado, o resultado da Figura 51.

Figura 51 - Topologia linear utilizada para o teste de topologia.

Por fim, foi realizado um teste com a topologia em anel, com 10 switches e foi obtido, como esperado, o resultado da Figura 52.

Figura 52 - Topologia em anel utilizada para o teste de topologia.

7. Conclusão

Com a realização deste trabalho, pode-se consolidar e aprofundar os conhecimentos, de forma geral, a cerca de conceitos de redes de computadores. Além disso, pode-se ver como a separação entre o plano de dados e o de controle em SDN permite o desenvolvimento de aplicações de maneira simples e rápida.

No desenvolvimento da aplicação, foi possível o contato com tecnologias de software de ponta, que poderão auxiliar em trabalhos científicos futuros e na vida profissional.

Em se tratando de desempenho, foi possível observar que, ao se paralelizar as inserções de dados no banco, é possível haver a inserção de mais dados por segundo, aumentando, assim, a eficácia da aplicação. Além disso, foi demonstrado que é possível se desenvolver aplicações a partir de APIs existentes nos controladores SDN e que, com isso, se torna fácil o desenvolvimento de novas funcionalidades. Foi observado, também, que, em caso de necessidade, o desenvolvimento de novas APIs se dá de forma simples e rápida.

Para trabalhos futuros, pode se tentar realizar uma paralelização ainda maior na inserção de dados e, tendo em vista que a aplicação roda em cima de um controlador, podem ser adicionados novos controladores, o que permitirá a divisão do trabalho de monitoramento, aumentando, assim, o desempenho da aplicação.

8. Referências bibliográficas

[1]Goransson, Paul. et al. Software Defined Networks: A Comprehensive Approach. 2 ed. Cambridge, 2017.

[2] OpenFlow Switch Specification, https://www.opennetworking.org/wp- content/uploads/2014/10/openflow-switch-v1.5.1.pdf

[3] Projeto de Desenvolvimento em OpenFlow, https://www.inf.ufes.br/~magnos/IF/if_files/Tutorial.pdf

[4] Gerenciamento e Monitoramento de Redes I: Análise de Desemprenho, http://www.teleco.com.br/pdfs/tutorialgmredes1.pdf

[5] Mininet and Open Switch,

http://www.openvswitch.org//support/ovscon2015/16/1305-lantz.pdf [6] RYU SDN Framework, http://osrg.github.io/ryu-book/en/Ryubook.pdf [7] Ryu.app.ofctl_rest, http://ryu.readthedocs.io/en/latest/app/ofctl_rest.html [8] JQuery, https://jquery.com/

[9] Bootstrap, https://getbootstrap.com/

[10] Google Charts, https://developers.google.com/chart/ [11] Vis, http://visjs.org/

[12] ASP.NET Razor, https://www.w3schools.com/asp/razor_syntax.asp [13] O que é DNS?, https://www.oficinadanet.com.br/post/16321-o-que-e-dns

9. Anexos

[Anexo 1] Script de configuração do Controlador:

https://github.com/pedroabz/TCCSDNScriptsControlador/blob/master/controlador.py [Anexo 2] API ofctl_rest modficada:

https://github.com/pedroabz/TCCSDNScriptsControlador/blob/master/ofctl_rest2.py [Anexo 3] Script Iperf automático Mininet:

https://github.com/pedroabz/MininetScripts_TCC/blob/master/script_mininet_iperf.py [Anexo 5] Aplicação Web de Monitoramento

https://github.com/pedroabz/Monitor-SDN

[Anexo 6] Aplicação Web para inserção dos dados de monitoramento na base de dados: https://github.com/pedroabz/Monitor-SDN_InsereBD