relevante para o experimento. A ferramenta também possibilitou calcular e exportar os dados re- ferentes às métricas objetos de estudo, os quais foram exportados para uma planilha, tornando-os mais organizados e portáveis para, posteriormente, serem utilizados por softwares de estatísticas para análise. Para cada medição foi gerada uma planilha com a amostra, perfazendo um total de 100 para cada tratamento. Entretanto, foram retirados os dados extremos ou “Outliers”, que podem vir a influenciar no cálculo da média, ocasionando a distorção dos resultados, restando 75 amostras para a obtenção das médias.
4.5 Avaliação do Controlador
Em uma segunda seção, realizou-se a avaliação da carga de processamento do controlador SDN. No ambiente proposto para a avaliação da infraestrutura de rede virtualizada, o controlador tem papel fundamental, tendo em vista que é o responsável por realizar todo o processamento dos fluxos de entrada e saída, tomando a decisão em relação a esses fluxos, ou seja, se serão aceitos, bloqueados ou encaminhados. Em um ambiente SDN, primeiramente, o controlador realiza toda a decisão de encaminhamento e, em seguida, repassa para o switch apenas executar essas decisões [49].
Atualmente, diversas implementações de controladores são propostas, tanto pela indústria quanto pela academia, em torno de 30 tipos de controladores. Essas implementações possuem várias linguagens de programação, tecnologias e conjunto de recursos. Frequentemente, a usabilidade e o desempenho desses controladores em produção divergem do protótipo conceitual. Nesse contexto, a avaliação da performance dos controladores se faz necessária, a fim de identificar e compreender o seu funcionamento e os gargalos que este venha a possuir [13], além de permitir definir um diferencial que apoie a decisão de escolha da solução apresentada como a mais adequada para utilizar no ambiente.
Os importantes controladores selecionados para realizar a medição foram ONOS e Open Day Light, pois ambos são projetos Open Source, que, nos últimos anos, têm ganhado bastante força, devido principalmente a quantidade de empresas que apoiam o seu desenvolvimento. Os dois controladores possuem algumas características semelhantes, tais como: a linguagem na qual foram escritos (java), o suporte à alta disponibilidade e a área de implementação (datacenter) [50].
A Tabela 4.2 apresenta alguns aspectos de semelhança entre esses dois controladores, entretanto, ainda é necessário analisar o desempenho desses controladores e o quanto de recurso este consome no processamento dos fluxos. Desse modo, é possível determinar qual controlador melhor se adéqua na infraestrutura proposta.
4.5. AVALIAÇÃO DO CONTROLADOR 58
Controlador Versão Linguagem Protocolos
suportados Openflow HA
ONOS Emu (1.4.0)
Java
OpenFlow, BGP,
TL1 1.0 e 1.3 Sim
Open Day Light Beryllium-SR4 OpenFlow, OVSDB,
BGP, NETCONF
Tabela 4.2: Características dos controladores
O ambiente para avaliar os controladores foi o mesmo descrito na subseção4.3.1 e ilustrado na Figura 4.5. Com o uso da ferramenta Iperf, duas estações trocaram tráfego na rede, fazendo com que o controlador tivesse que processar e decidir sobre os pacotes da rede. A métrica avaliada foi o consumo de CPU. Cada interação teve um período de 300 segundos, dando um intervalo de 180 segundos para que o processador fique ocioso. O teste foi repetido 100 vezes.
Como os controladores são VMs hospedadas em servidores virtualizados, as informações de consumo de CPU foram extraídas do próprio Xen Server, tendo em vista que o hipervisor por padrão monitora as máquinas virtuais com a função de mostrar o quanto cada VM consome de recurso. A fim de exportar as informações para um arquivo que possibilitasse a organização e a leitura dos dados, foi utilizada a ferramenta RRD2csv, a qual exporta as informações coletadas para um arquivo em formato “csv”.
59 59 59
5
RESULTADOS EXPERIMENTAIS
Neste capítulo são apresentados os resultados dos experimentos realizados de acordo com a metodologia descrita anteriormente. O gerador SIPp foi utilizado para gerar as cargas de trabalho com 50, 100, 500 e 1000 chamadas simultâneas. Essas cargas de trabalho que foram definidas obedecem a um incremento gradativo com o propósito de observar a escalabilidade do ambiente. No ambiente experimental foi adotada uma configuração padrão, a fim de se evitar que qualquer otimização realizada possa vir a interferir nos resultados. As métricas de interesse adotadas foram atraso e jitter. Cada chamada teve uma duração de 40 segundos e foram alocadas estações de trabalho para que fosse gerado tráfego concorrente na rede, simulando o funcionamento de um ambiente de produção real. São mostrados os resultados da avaliação para cada métrica, bem como os testes estatísticos realizados. É exibida, ainda, a efetivação do isolamento proposto para o tráfego VoIP, assim como os resultados da avaliação realizada sobre os controladores SDN, utilizados para compor o ambiente experimental, no qual foi adotado o consumo de CPU como métrica.
5.1 Análise do Atraso
Nas figuras 5.1, 5.2, 5.3 e 5.4 são apresentados os valores médios obtidos na medição do atraso.
5.1. ANÁLISE DO ATRASO 60
Figura 5.1: Média do Atraso - 50 chamadas simultâneas
5.1. ANÁLISE DO ATRASO 61
Figura 5.3: Média do Atraso - 500 chamadas simultâneas
Figura 5.4: Média do Atraso - 1000 chamadas simultâneas
5.2. ANÁLISE DO JITTER 62 (bridge, Open vSwitch e rede virtualizada) e nas quatro cargas de trabalho (50, 100, 500 e 1000 chamadas simultâneas). Os resultados obtidos em todos os tratamentos foram praticamente os mesmos, não havendo grandes variações para a métrica em questão. Acredita-se que essa constância dos valores médios do atraso deve-se, principalmente, ao fato do experimento ser realizado em uma rede local, em que os pacotes não trafegam por segmentos muito longos e não executam muitos “saltos” entre dispositivos de rede. Não foram identificados percentuais de perdas de pacotes que fossem relevantes.
Observa-se, de acordo com os resultados exibidos, que a métrica praticamente não sofreu alteração, mesmo com o aumento da carga de trabalho ou com a mudança no modo de operação da rede.
Com base na análise dos resultados é possível observar que a Virtualização da Rede, bem como os outros modos de operação não causaram qualquer tipo de impacto no atraso dos pacotes no tráfego VoIP, sejam eles positivos ou negativos.
5.2 Análise do jitter
As Figuras 5.5, 5.6, 5.7 e 5.8 apresentam os valores médios calculados para o jitter.
5.2. ANÁLISE DO JITTER 63
Figura 5.6: Média do Jitter - 100 chamadas simultâneas
5.2. ANÁLISE DO JITTER 64
Figura 5.8: Média do Jitter - 1000 chamadas simultâneas
Em alguns tipos de serviços o jitter não é um fator preocupante, porém, quando se trata de transmissão em tempo real, como o VoIP, essa métrica pode causar efeitos não desejados. Um jitter alto em uma ligação VoIP pode acarretar níveis inaceitáveis de qualidade da chamada.
Assim como para o atraso, também foi realizada a medição do jitter nos três cenários propostos (Brige, Open vSwitch e Rede Virtualizada) e em cada carga de trabalho (50, 100, 500 e 1000 chamadas simultâneas). Os resultados obtidos mostram que houve uma leve alteração no valor do jitter entre os modos de operação e nas cargas de trabalho adotadas.
As figuras 5.5 e 5.6 mostram os valores médios do jitter para as cargas de 50 e 100 chamadas simultâneas, onde nota-se que não houve aumento considerável do jitter. Nessas duas cargas de trabalho, os valores praticamente não tiveram alterações, sendo que, quando o ambiente operou com a rede virtualizada, os valores foram levemente menores, respectivamente, com 0,51 e 0,60ms para 50 e 100 chamadas simultâneas. Já os maiores valores ocorreram quando a rede operou usando o Open vSwitch como backend.
Somente quando a carga de trabalho aumentou para 500 chamadas simultâneas, foi possível observar um leve aumento nos valores médios do jitter em relação às cargas de 50 e 100 chamadas, entretanto, praticamente não houve diferença nos valores médios entre os modos de operação da rede, conforme apresentado na figura 5.7. Todavia, nota-se que novamente o valor obtido quando o ambiente operou com a rede virtualizada foi levemente menor do que os demais modos de operação, com 0,85ms.
5.3. TESTES ESTATÍSTICOS 65 ocorre um aumento um pouco maior do jitter em relação as demais cargas de trabalho. Em relação aos modos de operação da rede, observa-se que também houve diferenças entre eles. O maior valor médio do jitter ocorreu quando a rede operou com o Open vSwitch, chegando a 1,70ms, e o menor valor foi quando a rede foi virtualizada, obtendo 1,44ms.
5.3 Testes estatísticos
A fim de comparar os dados dos tratamentos, foi realizado o teste estatístico de Kruskal- Wallis, uma vez que as distribuições das amostras não são distribuições normais. Este teste é estatístico não paramétrico, isto é, testa a hipótese nula de que as amostras proveem de uma mesma população ou de população diferente. O teste de Kruskal-Wallis foi usado na comparação dos tratamentos de acordo com as cargas de trabalho. As tabelas 5.1, 5.2, 5.3 e 5.4 apresentam os resultados para os testes estatísticos realizados. Nas tabelas também são apresentados a soma dos postos e os p-valores.
50 chamadas
Jitter Atraso
Nível Soma dos Postos Nível Soma dos Postos
Open vSwitch: 10380.5 Open vSwitch: 8214.5
Bridge: 8600 Bridge: 9215
Virtualizado: 7125.5 Virtualizado: 8676.5
p-valor: < 0.001 p-valor: 0.4685
Tabela 5.1: Teste de Kruskal-Wallis: 50 chamadas
100 chamadas
Jitter Atraso
Nível Soma dos Postos Nível Soma dos Postos
Open vSwitch: 8665 Open vSwitch: 8530
Bridge: 10018.5 Bridge: 8572.5
Virtualizado: 7522.5 Virtualizado: 9003.5
p-valor: 0.006 p-valor: 0.812
5.3. TESTES ESTATÍSTICOS 66 500 chamadas
Jitter Atraso
Nível Soma dos Postos Nível Soma dos Postos
Open vSwitch: 8769.0 Open vSwitch: 8680
Bridge: 9971.5 Bridge: 7551.5
Virtualizado: 7365.5 Virtualizado: 9874.5
p-valor: 0.006 p-valor: 0.017
Tabela 5.3: Teste de Kruskal-Wallis: 500 chamadas
1000 chamadas
Jitter Atraso
Nível Soma dos Postos Nível Soma dos Postos
Open vSwitch: 14181 Open vSwitch: 7912
Bridge: 7004 Bridge: 8724
Virtualizado: 4921 Virtualizado: 9470
p-valor: < 0.001 p-valor: 0.1594
Tabela 5.4: Teste de Kruskal-Wallis: 1000 chamadas
Os resultados dos testes para o jitter apresentaram os seguintes valores: para 50 chamadas p-valor > 0.001; para 100 chamadas p-valor = 0.006; para 500 chamadas p-valor = 0.006; e, para 1000 chamadas p-valor < 0.001. Os números apresentados mostram que os p-valores são menores do que o nível de significância de 0.05, rejeitando a hipótese nula.
Para o atraso, os resultados foram os seguintes: para 50 chamadas p-valor = 0.4685; para 100 chamadas p-valor = 0.812; para 500 chamadas p-valor = 0.017; e, para 1000 chamadas p-valor = 0.159. Os resultados obtidos mostram que para 50, 100 e 1000 chamadas os p-valores são maiores do que o nível de significância, aceitando a hipótese nula. Porém, para 500 chamadas o p-valor é menor do que o nível de significância, rejeitando a hipótese nula.
Os testes KW indicam que o jitter não vem da mesma distribuição, mas a sobreposição de intervalos de confiança não fornece evidência suficiente quanto à diferença estatística dos valores médios. No entanto, para 1000 chamadas o Open vSwitch tem uma maior jitter e intervalos de confiança não se sobrepõem. Contudo, a diferença, por ser menor que 1ms, é considerada pequena se comparada a outras tecnologias e não é significativa para impactar a experiência do usuário em VoIP.
Em relação ao atraso, os resultados e o teste KW indicam que a diferença entre os valores médios não é estatisticamente significativa. Ressalta-se que é um resultado notável, visto que a rede virtualizada e o SDN têm benefícios adicionais que as infraestruturas de rede regulares, representadas pelo nível Bridge, não possuem, como flexibilidade, redução de custos e facilidade no gerenciamento.
5.4. ISOLAMENTO DE TRÁFEGO 67 5.4 Isolamento de tráfego
Isolamento de tráfego por redes virtuais basicamente possuem dois propósitos: isola- mento de recursos e isolamento de comunicação. O isolamento de recursos garante que uma rede virtual não interfira no desempenho de outra. Com isso, uma rede não terá seu recurso esgotado por outra rede virtual, evitando uma possível negação de serviço. Já o isolamento de comunicação possibilita que somente os nós pertencentes a mesma rede virtual se comuniquem. No caso de dois elementos que fazem parte de redes virtuais distintas, eles não se enxergarão, mesmo que estejam na mesma faixa de endereçamento IP. Este tipo de recurso torna-se essencial em uma rede de computadores, principalmente porque, muitas vezes, há diversos serviços rodando em uma mesma rede física e, por questões de segurança, não é desejável que pacotes de um determinado serviço se misture a outro [51].
Diante disso, o trabalho propôs a implementação de um isolamento lógico que fosse capaz de separar o tráfego VoIP dos demais tráfegos da rede. O isolamento é baseado no paradigma da separação dos planos de controle do plano de dados. Com essa implementação também é possível criar oportunidade de inovação em um ambiente de data center, pois permite que uma infraestrutura física possa ser utilizada simultaneamente, tanto para produção quanto para experimentação, sem que o tráfego de um venha a interferir no outro.
Na arquitetura dos data centers atuais, o isolamento entre máquinas virtuais ou inquilinos é alcançado através de VLANs. Para isso são utilizados switches tradicionais, com suporte a VLAN [1]. A solução alcança o objetivo de isolar tráfegos, porém, ela possui limitações em relação ao número de VLANs criadas, visto que o máximo de VLANs permitidas pelo padrão 802.1q é 4096, limitando, dessa forma, o crescimento da rede [11]. Além disso, as VLANs teriam que ser configuradas em cada porta do switch, tornando sua implementação e possíveis mudanças mais demoradas [52].
Para alcançar o isolamento proposto foi necessária a utilização de um hipervisor ou virtualizador de rede. Para esta demanda adotou-se o FlowVisor, ferramenta que permite virtualização e divisão de uma infraestrutura física em diferentes redes virtuais, bem como fornece mecanismo de isolamento para topologia e espaço de endereçamento [53].
Os testes para verificar a efetividade do isolamento consistiram em criar dois slices, denominados voip e slice1. No ambiente experimental, descrito na Seção 4 e ilustrado na Figura 4.5, duas estações (PC01 e PC03), que estavam conectadas em servidores físicos diferentes, foram inseridas no slice voip e outras duas estações (PC02 e PC04) no slice1. Primeiramente, realizou-se o teste com a ferramenta ping, que envia pacotes icmp aos destinatários. Nesse teste, a estação PC01 enviou pacotes icmp para as estações PC02, PC03 e PC04, entretanto, só obteve resposta da estação PC03, que estava no mesmo slice (VoIP). O mesmo teste foi repetido com as demais estações, porém, a comunicação entre as estações somente foi possível entre as que faziam parte do mesmo slice.
5.5. AVALIAÇÃO DOS CONTROLADORES 68