DANYEL MENDES NOGUEIRA RAMOS
AVALIAÇÃO DE DESEMPENHO DE UM CONTROLADOR SDN
IMPLEMENTADO COMO UMA VNF
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
RECIFE 2017
Danyel Mendes Nogueira Ramos
AVALIAÇÃO DE DESEMPENHO DE UM CONTROLADOR
SDN IMPLEMENTADO COMO UMA VNF
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.
ORIENTADOR: Stênio Flávio de Lacerda Fernandes CO-ORIENTADOR: Marcelo A. Batista dos Santos
RECIFE 2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
R175a Ramos, Danyel Mendes Nogueira
Avaliação de desempenho de um controlador SDN implementado como uma VNF / Danyel Mendes Nogueira Ramos. – 2017.
89 f.: il., fig., tab.
Orientador: Stênio Flávio de Lacerda Fernandes.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências.
1. Redes de computadores. 2. Avaliação de desempenho. I. Fernandes, Stênio Flávio de Lacerda (orientador). II. Título.
Danyel Mendes Nogueira Ramos
Avaliação de desempenho de um controlador SDN implementado como
uma VNF
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 04 de abril de 2017.
Aprovado em: 04/04/2017.
BANCA EXAMINADORA
__________________________________________ Prof. Kelvin Lopes Dias
Centro de Informática / UFPE
__________________________________________ Prof. Ramide Augusto Sales Dantas
Instituto Federal de Pernambuco
__________________________________________ Prof. Stênio Flávio de Lacerda Fernandes
Centro de Informática / UFPE (Orientador)
À minha noiva, toda a minha família, amigos, professores e colegas de trabalho envolvidos nessa conquista.
AGRADECIMENTOS
Primeiramente a DEUS, que me abençoou durante todo esse tempo na minha trajetória em busca dos meus objetivos.
Ao professor orientador DR. STENIO FLAVIO DE LACERDA FERNANDES pelo incentivo, excelência e presteza no auxílio às atividades e discussões sobre o andamento desta dissertação de mestrado.
Ao Co-orientador MSc. MARCELO ANDERSON BATISTA DOS SANTOS pela disponibilidade, paciência, dicas e explicações no auxílio a todas as atividades envolvidas na dissertação.
Aos demais idealizadores e coordenadores do CIn, bem como a todos os professores e colegas de turma, pela dedicação e entusiasmo demonstrado ao longo do curso.
A todos os meus familiares, em especial, ao meu avô AGOSTINHO NETO e às minhas avós ANITA RAMOS e ANTONIA NOGUEIRA (In Memoriam), bem como à minha mãe MARIA APARECIDA, no empenho, esforço, e vontade de ajudar-me em mais uma conquista.
A minha noiva JULIANA BARBOSA pelo carinho, incentivo, conselhos e apoio empreendido para que essa conquista fosse possível.
Aos gestores do IF Sertão-PE, pelo apoio institucional e suporte financeiro na realização do mestrado, bem como a todos os colegas de trabalho que me ajudaram direta ou indiretamente nessa conquista.
“A mente não tem limite. Quando a mente pode antever o fato de que você pode realizar algo, você realmente pode, desde que acredite nisso 100%.”
RESUMO
A implementação de serviços de rede em dispositivos embarcados proprietários tem impedido o avanço e a evolução da rede, induzindo um problema denominado ossificação. Aproveitando os benefícios da virtualização, NFV se constitui em uma abordagem que dissocia os serviços de rede do hardware subjacente, permitindo a virtualização de funções de rede em servidores de propósito geral resultando em redução de OPEX/CAPEX. Integrado com SDN, a arquitetura NFV Definida por Software tem o potencial de oferecer mais agilidade e flexibilidade no encaminhamento de tráfego e no encadeamento de funções, justificando-se a importância de avaliarmos um controlador SDN implementado como uma NFV, com o objetivo de verificarmos as implicações no desempenho, uma vez que estudos recentes demonstram a degradação de desempenho imposta pela virtualização de funções de rede. No presente trabalho, realizamos experimentos com um controlador SDN implementado como uma função de rede virtual nos hypervisores de código aberto KVM e XEN e comparamos os parâmetros de desempenho mais críticos em relação a um cenário nativo com o propósito de mensurar a degradação de desempenho causada pela virtualização. Cbench foi utilizado para emular redes SDN e avaliar o desempenho e a latência do controlador Floodlight. Os resultados mostram que a virtualização do controlador no ambiente KVM resultou na degradação do processamento de fluxos em 29%, apresentou um aumento do tempo de resposta de 22% e utilizou bem menos o processador em relação ao ambiente Xen, que sobrecarregou a CPU em 25%, mas foi capaz de atingir melhor throughput e alocação de memória RAM quando comparada ao controlador virtualizado em KVM. Finalmente, uma proposta de aplicação SDN de roteamento de QoS e a respectiva infraestrutura NFV de implantação é apresentada como estudo de caso na autarquia federal IF Sertão-PE.
ABSTRACT
The implementation of network services in proprietary embedded devices has prevented the advancement and evolution of the network, inducing a problem called ossification. Leveraging the benefits of virtualization, NFV is an approach that disassociates network services from the underlying hardware, enabling virtualization of network functions on general purpose servers resulting in OPEX / CAPEX reduction. Integrated with SDN, the Software Defined NFV architecture has the potential to offer more agility and flexibility in traffic routing and in the chain of functions, justifying the importance of evaluating an SDN controller implemented as an NFV, in order to verify the Implications for performance, as recent studies demonstrate the performance degradation imposed by virtualization of network functions. In the present work, we performed experiments with an SDN controller implemented as a virtual network function in the KVM and XEN open source hypervisors and compared the most critical performance parameters in relation to a native scenario in order to measure the degradation of performance caused by Virtualization. We use Cbench to emulate SDN networks and evaluate the performance and latency of the Floodlight controller. We found that virtualization of the controller in the KVM environment resulted in degradation of the processing of flows by 29%, showed an increase in the response time of 22% and used much less the processor in relation to Xen, which overloaded the CPU by 15%, but Was able to achieve better performance of throughput and RAM compared to the virtualized controller in KVM. Finally, a proposed SDN routing QoS application and the respective deployment NFV infrastructure is presented as a case study in the federal authority IF Sertão-PE.
LISTA DE FIGURAS
Figura 1: Dispositivos de hardware dedicado para serviços de rede e a solução NFV ... 14
Figura 2: Arquitetura NFV definida por software ... 17
Figura 3: Tipos de hypervisores ... 24
Figura 4: Arquitetura KVM base ... 30
Figura 5: Arquitetura Xen ... 31
Figura 6: Arquitetura SDN e suas abstrações fundamentais ... 35
Figura 7: Dispositivos SDN habilitados para OpenFlow ... 36
Figura 8: TesteBed utilizado nos experimentos... 46
Figura 9: Ambientes de implantação do controlador SDN ... 52
Figura 10: Throughput para um número variável de switches ... 57
Figura 11: Latência real para um número variável de switches ... 58
Figura 12: Consumo de CPU para um número variável de switches ... 61
Figura 13: Utilização de memória total nos modos throughput (a) e latency (b) de Cbench . 64 Figura 14: Distribuição geográfica dos campi do IF Sertão-PE ... 71
Figura 15: Cenário atual de rede sem QoS para webconf e VoIP ... 72
Figura 16: Implementação do Controlador SDN como uma VNF ... 76
Figura 17: Implementação de algumas funções do appliance como aplicações SDN ... 77
LISTA DE TABELAS
Tabela 1: Controladores SDN ... 36
Tabela 2: Descrição das máquinas virtuais ... 46
Tabela 3: Parâmetros de Cbench ... 47
Tabela 4: Relação entre tempo, fluxos SDN e CPU Total do servidor em um teste ... 49
Tabela 5: Métricas dos experimentos ... 49
Tabela 6: Cenários e métricas dos experimentos. ... 51
Tabela 7: Fatores, níveis e valores dos experimentos ... 52
Tabela 8: Desempenho das funções de rede nativa e virtuais para 1 switch ... 55
Tabela 9: Throughput das funções de rede para vários switches ... 56
Tabela 10: Latência das funções de rede para vários switches ... 57
Tabela 11: CPU total das funções de rede para 1 switch ... 59
Tabela 12: CPU total das funções de rede para vários switches emulados ... 60
Tabela 13: CPU total das funções de rede para vários switches emulados ... 60
Tabela 14: Memória total das funções de rede nos para um 1 switch ... 62
Tabela 15: Memória total das funções de rede nos testes de throughput ... 63
Tabela 16: Memória total das funções de rede nos testes de latência ... 63
Tabela 17: Avaliação de desempenho de rede da função de rede em três ambientes ... 64
Tabela 18: Desempenho de CPU nos modos throughput e latência de Cbench ... 66
Tabela 19: Detalhes da CPU das VNFs em modo throughput (32 switches) ... 66
Tabela 20: Detalhes de CPU das VNFs em modo latência (32 switches) ... 67
Tabela 21: Alocação de memória RAM da função de rede em três configurações ... 68
Tabela 22: Requisitos de QoS para aplicações típicas ... 75
SUMÁRIO
1 Introdução ... 13 1.1 DESCRIÇÃO DO PROBLEMA ... 16 1.2 OBJETIVOS GERAIS ... 18 1.3 OBJETIVOS ESPECÍFICOS ... 19 1.4 ESTRUTURA DA DISSERTAÇÃO ... 19 2 Referencial Teórico ... 20 2.1 VIRTUALIZAÇÃO ... 20 2.1.1 Definições e conceitos ... 21 2.1.2 Hypervisores ... 23 2.2 ABORDAGENS DE VIRTUALIZAÇÃO ... 25 2.2.1 Virtualização total ... 25 2.2.2 Para-virtualização ... 262.2.3 Virtualização assistida por hardware ... 27
2.3 KERNEL-BASED VIRTUAL MACHINE (KVM) ... 28
2.4 XEN ... 30
2.5 VIRTUALIZAÇÃO DE FUNÇÕES DE REDE ... 32
2.6 REDES DEFINIDAS POR SOFTWARE ... 34
2.6.1 Controladores SDN ... 36 2.6.2 Floodlight ... 37 3 Trabalhos Relacionados ... 38 3.1 INTRODUÇÃO ... 38 3.2 VIRTUALIZAÇÃO DE COMPUTAÇÃO ... 39 3.3 VIRTUALIZAÇÃO DE REDE ... 39 3.4 DESEMPENHO DE CONTROLADORES SDN ... 40
3.5 VIRTUALIZAÇÃO DE FUNÇÕES DE REDE ... 42
4 Metodologia ... 45
4.1 AMBIENTE DE TESTES ... 45
4.2 CBENCH ... 47
4.3 EXPERIMENTOS ... 48
4.3.1 Script orquestrador dos experimentos... 48
4.3.2 Cargas de trabalho ... 50
4.3.3 Cenários de experimentos ... 51
5 Resultados ... 54
5.1.1 Número de switches emulados ... 55
5.2 CONSUMO DE CPU ... 59
5.2.1 Variação do Número de switches emulados ... 60
5.3 MEMÓRIA RAM ... 61
5.3.1 Número de switches emulados ... 63
5.4 DISCUSSÕES E LIÇÕES APRENDIDAS... 64
6 Estudo de caso ... 70 6.1 INTRODUÇÃO ... 70 6.2 A INSTITUIÇÃO ... 70 6.3 CENÁRIO ATUAL ... 72 6.4 PROBLEMATIZAÇÃO ... 73 6.5 APLICAÇÃO ... 74
6.5.1 Virtualização das funções de rede físicas ... 75
6.5.2 QoSOptimizer ... 77 7 Considerações Finais ... 80 7.1 CONTRIBUIÇÕES ... 82 7.2 LIMITAÇÕES ... 82 7.3 TRABALHOS FUTUROS ... 83 Referências...85
1
Introdução
Funções de rede têm sido implementadas por operadores e provedores de serviços em diversos middleboxes dedicados proprietários há décadas, resultando no aumento de custos OPEX1/CAPEX2, dificuldade de implantação e gerenciamento de novas funções e serviços, causando o problema da ossificação da internet, fator que tem dificultado o avanço e o crescimento da rede (LI; CHEN, 2015). Neste contexto, Virtualização de funções de rede (NFV - Network Functions Virtualization) surge como uma solução para a inflexível infraestrutura atual de rede, que precisa atender crescentes demandas dos usuários e de tráfego na implementação de novos serviços (JEON; LEE, 2015).
Na indústria de telecomunicações, a oferta de serviços de rede aos usuários geralmente é realizada por provedores de serviço que implantam e utilizam equipamentos físicos dedicados – middleboxes, para fornecer uma função de rede (MIJUMBI et al., 2015), que pode ser componente de uma cadeia que especifica o caminho de processamento de um serviço, necessitando de ordenação estrita, fator que acaba refletindo na topologia da rede e nos locais dos dispositivos (LI; CHEN, 2015). Esses fatores somados aos requisitos de alta qualidade e estabilidade, resultam em ciclos de equipamentos longos, dificuldade de implantação e manutenção de novos Appliances3, falta de agilidade de suporte e dependência de hardware especializado.
O caráter estático dos middleboxes dedicados proprietários, bem como a dificuldade de gerenciamento e manutenção implicam em altos custos operacionais (OPEX) e de capital (CAPEX), uma vez que um Appliance é um dispositivo dedicado, fechado, projetado e
1 OPEX é uma sigla derivada da expressão operational expenditure, que significa o capital utilizado para manter
ou melhorar os bens físicos de uma empresa.
2 CAPEX é a sigla da expressão inglesa capital expenditure (em português, despesas de capital ou investimento
em bens de capital).
construído especificamente para processar uma função de rede, com caraterísticas peculiares do fabricante (MIJUMBI et al., 2015).
Em um cenário onde implantar, testar e migrar novas funções de rede em infraestruturas compostas por diversos equipamentos proprietários fixos têm sido cada vez mais complexo e improdutivo, NFV foi proposta como tecnologia-chave para beneficiar a evolução da virtualização de TI (MIJUMBI et al., 2015), separando as funções de rede do hardware subjacente (LI; CHEN, 2015), em um ambiente que concebe as funções de rede como aplicações de software em execução nas VMs, que são hospedadas em servidores de propósito geral de baixo-custo. Desta forma, diferentes funções de rede podem ser executadas em servidores comerciais (BONAFIGLIA et al., 2015), e implementadas em vários pontos de presença da rede conforme a necessidade dos provedores, com flexibilidade e eficiência nos aspectos de implantação e gerenciamento (LI; CHEN, 2015).
Figura 1: Dispositivos de hardware dedicado para serviços de rede e a solução NFV
Fonte: (HAN; GOPALAKR, 2015)
Além de reduzir investimentos operacionais e de capital, NVF pode reduzir também o consumo de energia elétrica (MIJUMBI et al., 2015), uma vez que diversos dispositivos de
rede podem ser consolidados em servidores commodity4, sendo possível executar diversas funções de rede em um único servidor, através do compartilhamento de recursos de computação e rede possibilitado pela virtualização. NVF também possibilita a rápida implantação e migração de novos serviços de rede de forma flexível entre pontos de presença, sem a necessidade de aquisição de novos dispositivos físicos (FALKNER et al., 2016).
Considerando a degradação de desempenho causada pela virtualização de sistemas, pretendemos verificar os seus efeitos sobre o processamento de uma função de rede virtual, a magnitude dos impactos negativos e a viabilidade de utilização de NFVs em ambientes de produção, uma vez que a adoção da virtualização em ambientes de rede e datacenters,
sobretudo na computação em nuvem, tem sido amplamente utilizada tanto no compartilhamento eficiente de recursos quanto para alcançar objetivos de negócio (LEITE et al., 2012).
No presente trabalho, avaliamos o desempenho do controlador Floodlight (FLOODLIGHT, 2016) nos dois principais hypervisores de código aberto mais populares,
KVM e XEN (PATEL et al., 2015), mensurando o impacto dos overheads de virtualização no desempenho da função de rede. O controlador Floodlight foi escolhido para os testes porque oferece bom desempenho, portabilidade, ampla documentação disponível e facilidade de instalação e configuração.
O controlador SDN será avaliado em três cenários distintos: Sem virtualização (cenário nativo) e virtualizado nos hypervisores KVM (KIVITY et al., 2007) e Xen (XEN, 2014). Os hypervisores open Source5 KVM e Xen foram escolhidos para a avaliação de desempenho porque são muito populares, não proprietários, amplamente utilizados em pesquisas acadêmicas/indústria e possuem documentação abundante. Avaliar uma função de rede (controlador SDN) nos hypervisores KVM e Xen nos permite comparar duas abordagens de virtualização distintas, a virtualização total com assistência de hardware (HVM) e a para-virtualização (respectivamente) e verificar as vantagens e desvantagens de cada técnica. É importante ressaltar que os drivers para-virtualizados KVM Virtio (RUSSELL, 2008) não serão utilizados neste trabalho.
Utilizamos um gerador de tráfego de referência denominado Cbench (LAISSAOUI et al., 2015) (ZHAO et al., 2015) para emular uma rede de comutadores OpenFlow que é capaz de enviar fluxos para o controlador. Desta forma, o desempenho de rede, a utilização do processador e a alocação de memória da VNF6 foram mensurados em uma rede com um número variável de comutadores, observando também o desempenho do controlador conforme a rede cresce.
Finalmente, foi proposto um estudo de caso de implantação de uma aplicação de roteamento QoS no Instituto Federal Sertão-PE. A aplicação denominada QoSOptimizer foi proposta para ser capaz de priorizar e otimizar os serviços VoIP e web conferência do provedor RNP, oferecendo mais qualidade de serviço (QoS) e de experiência (QoE). O estudo de caso propõe uma aplicação que funcionaria no controlador Floodlight, virtualizado no hypervisor Xen sobre uma infraestrutura NFV.
5 Open Source: Código aberto. Referente a software livre (não proprietário) 6 Do inglês Virtual Network Function: Função de rede virtual
1.1
DESCRIÇÃO DO PROBLEMA
A virtualização de funções de rede se constitui em um passo importante para arquitetar infraestruturas de rede com agilidade, baixo custo, mudando radicalmente o cenário convencional de implantação dos serviços de rede e a indústria das telecomunicações, com o potencial de trazer vários benefícios para os provedores de rede (WANG, 2016).
No entanto, junto com os benefícios trazidos pela virtualização de funções, surgem preocupações com o desempenho da rede, uma vez que servidores de propósito geral agora executam várias funções que antes eram executadas por Middleboxes dedicados de alto desempenho, fazendo inclusive, uso de circuitos ASICs7 para o processamento de funções específicas (HAN; GOPALAKR, 2015).
Desta maneira, fornecer um desempenho equiparável aos dispositivos de hardware dedicados ainda é um grande desafio para NFV, visto que a virtualização implica em degradação de desempenho porque o hypervisor precisa traduzir as operações realizadas pelas máquinas virtuais para garantir o isolamento das mesmas (EIRAS et al., 2016) e a virtualização pode implicar em variações anormais de latência e instabilidade de taxa de transferência considerável, até quando a utilização da rede subjacente é leve. Neste contexto, é um desafio para os provedores de serviços garantir que VNFs tenham desempenho de rede satisfatório e equivalente aos middleboxes dedicados, cujas pesquisas indicam que a implantação de dispositivos virtuais pode ser afetada negativamente pelas instabilidades nas redes causadas pela virtualização (HAN; GOPALAKR, 2015).
O desempenho de virtualização de E/S (entrada/saída) é um problema importante em KVM quando QEMU é utilizado. Essa técnica baseada em emulação de software, é utilizada também por outros hypervisores baseados em hospedeiro e provoca uma degradação significativa no desempenho (ZHANG et al., 2010). Experimentos realizados por (CHE et al., 2008) demonstraram que a virtualização de E/S é uma das principais fontes de degradação de desempenho.
Por outro lado, Leite et al. (2012) avaliou o desempenho dos hypervisores XEN e KVM considerando a execução concorrente de máquinas virtuais no hospedeiro para demonstrar que apesar da sobrecarga adicional, a virtualização é vantajosa para aproveitar recursos subutilizados na máquina física (LEITE et al., 2012). O autor também concluiu que uma máquina virtual baseada no hypervisor XEN obteve um aumento de 52% no tempo de resposta em relação a execução direta na máquina física, enquanto a execução concorrente de
5 VMs aumentou em 64% o tempo de resposta em relação ao host sem virtualização. Dobrando-se o número de VMs, a degradação ficou em torno de 76%. Para Anderson et al. (2016), a virtualização de hardware implica na degradação de desempenho e redução da eficiência (ANDERSON et al., 2016).
Atualmente, NFV e Redes definidas por software (SDN) são conceitos complementares e estritamente relacionados e tem se tornado a forma padrão de NFV, sendo denominada de arquitetura NFV definida por software (LI; CHEN, 2015). Esta integração de conceitos possibilita maior domínio e agilidade no direcionamento de tráfego, sendo utilizada principalmente em aplicações de encadeamento de serviços, fornecendo também otimização de funções e recursos de rede. Um controlador SDN pode ser virtualizado como uma função de rede, permitindo a migração dinâmica para outros pontos de presença da rede a partir da implantação do controlador na nuvem. Por outro lado, SDN pode beneficiar NFV fornecendo conectividade de rede programável entre funções virtuais e direcionamento de tráfego otimizado no encadeamento de VNFs (LI; CHEN, 2015). A arquitetura NFV definida por software pode ser visualizada na Figura 2.
Figura 2: Arquitetura NFV definida por software Fonte: (LI; CHEN, 2015).
Diante de um cenário onde a integração entre as arquiteturas NFV e SDN é cada vez mais frequente, surgem os seguintes questionamentos sobre a virtualização e migração de controladores SDN para a arquitetura NFV:
1. Qual o impacto da virtualização no desempenho de um controlador SDN quando este é implementado como uma VNF nos hypervisores KVM e XEN?
2. Quais as implicações no tempo de resposta, utilização de CPU e na alocação de memória quando um controlador SDN é virtualizado?
Embora NFV seja promessa de vários benefícios para os provedores de rede, a virtualização traz consigo a degradação de desempenho já conhecida e que pode afetar significativamente o desempenho dos serviços de rede, implicando negativamente na qualidade de serviço – QoS. Além dos vários impactos na arquitetura de hardware, a virtualização afeta principalmente o desempenho de CPU, memória e Entrada/Saída (SEMNANIAN et al., 2010). Desta forma, avaliar o impacto da degradação de desempenho causada pela virtualização no controlador SDN Floodlight é a contribuição deste trabalho.
1.2
OBJETIVOS GERAIS
O principal objetivo deste trabalho é avaliar o impacto da sobrecarga causada pela virtualização sobre uma função de rede virtual, implementada como um controlador SDN, verificando os efeitos dessa degradação de desempenho nas principais métricas de desempenho de rede – latência e taxa de transferência, bem como na utilização do processador e alocação de memória RAM.
Com a realização das aferições desse trabalho, pretendemos demonstrar que a virtualização, apesar de ser cada vez mais utilizada, pode trazer implicações negativas para o desempenho de funções de rede virtuais, e que é necessário aperfeiçoar o desempenho dos hypervisores, especialmente no aspecto de virtualização de entrada/saída de rede. Pretendemos ainda demonstrar que a degradação de desempenho do controlador aumenta com o crescimento da rede SDN.
Neste contexto, espera-se verificar quantitativamente a degradação de desempenho de uma função de rede virtualizada nos hypervisores KVM e XEN, considerando como parâmetros de observação, o desempenho de rede, utilização de CPU e memória RAM, além de considerar os gargalos e limitações da arquitetura NFV definida por software, visto que sua utilização está sendo cada vez mais intensificada.
1.3
OBJETIVOS ESPECÍFICOS
1. Desenvolver uma abordagem para avaliar o desempenho de controladores SDN implementados como funções de rede virtuais nos ambientes KVM e XEN;
2. Implementar um ambiente de testes para avaliar o desempenho de rede, CPU e memória de controladores SDN;
3. Verificar que métricas de desempenho são mais afetadas pela virtualização em um controlador SDN;
4. Verificar qual hypervisor oferece o melhor cenário para a implantação de controladores SDN como funções de rede;
1.4
ESTRUTURA DA DISSERTAÇÃO
Esta dissertação está estruturada da seguinte forma: No Capítulo 2 apresentamos o referencial teórico necessário para a compreensão dos principais conceitos e tecnologias envolvidos na avaliação de desempenho. O Capítulo 3 apresenta um resumo das principais investigações relacionadas com o presente trabalho. O Capítulo 4 descreve o ambiente de testes utilizado nos experimentos e os procedimentos e técnicas empregadas para atingir os resultados. No Capítulo 5 os resultados obtidos são apresentados e discutidos. O Capítulo 6 apresenta um cenário de implantação de uma ferramenta de roteamento QoS no IF Sertão-PE. Finalmente, no Capítulo 7 apresentamos as principais conclusões do trabalho, algumas contribuições e direcionamentos para trabalhos futuros.
2
Referencial Teórico
Neste capítulo, apresentaremos o background técnico necessário para a compreensão dos principais conceitos envolvidos no desenvolvimento deste trabalho. Inicialmente, apresentaremos alguns conceitos de virtualização e as abordagens que se relacionam com esse trabalho nas seções 2.1 e 2.2. Nas duas seções seguintes, apresentaremos dois hypervisores de código aberto utilizados neste trabalho, KVM e XEN. Finalmente, vamos discutir a virtualização de funções de rede na seção 2.5 e as redes SDN na seção 2.6.
2.1
VIRTUALIZAÇÃO
Nos últimos anos, a virtualização tem se tornado o elemento fundamental da computação em nuvem, que possibilita que usuários solicitem sob demanda, máquinas virtuais, recursos de rede, plataformas e serviços com tarifação ajustada à utilização dos recursos e requisitos de negócios (SORIGA; BARBULESCU, 2013).
Com o rápido crescimento das demandas tecnológicas, as empresas de tecnologia da informação precisam investir no aprimoramento de suas infraestruturas e na consolidação de servidores através da virtualização, visando a expansão e otimização do parque computacional com o menor investimento, maior custo benefício, flexibilidade e gestão simplificada, possibilitando a oferta de recursos computacionais configuráveis sob demanda com menor esforço operacional para o fornecimento. Compreendemos a computação em nuvem como um prestador de serviços, enquanto a virtualização refere-se a um recurso tecnológico componente da infraestrutura física, que possibilita a otimização e a melhoria da eficiência dos recursos (MANIK, 2016).
A virtualização possibilita o compartilhamento e a utilização eficiente de recursos computacionais que eram subutilizados em cenários tradicionais, pautados no paradigma servidor por carga de trabalho (UHLIG et al. 2005). Posteriormente, essas cargas de trabalho – que ocupavam uma pequena fatia dos recursos de um servidor físico, passaram a ser hospedadas em computadores virtuais com o devido isolamento e segurança, em um cenário idêntico a um computador real (MANIK, 2016). Desta forma, a virtualização possibilita o compartilhamento de cargas de trabalho distintas e isoladas em várias instâncias de máquinas virtuais hospedadas em um único host físico. Neste sentido, os recursos computacionais dos servidores são otimizados, proporcionando a redução de custos com hardware e energia, eficiência, confiabilidade, disponibilidade, flexibilidade e segurança (WANG; NG, 2010).
Em um cenário convencional, podemos entender virtualização como uma tecnologia que possibilita a execução de várias instâncias de sistemas operacionais em um único hardware através de uma camada de abstração de software inserida entre o hardware e os sistemas operacionais virtualizados e suas aplicações.
2.1.1 Definições e conceitos
Um computador é uma máquina modular, ou seja, é construído a partir de uma série de subsistemas – que possuem interfaces de comunicação bem definidas, podem ser compreendidas de forma independente e fornecem serviços para as camadas superiores. Uma das principais interfaces de um sistema de computação é o conjunto de instruções de máquina – ISA8(SMITH; NAIR, 2005).
Os primeiros conceitos mais importantes na compreensão da virtualização referem-se as instruções privilegiadas9 e não-privilegiadas. Somente alguns programas com privilégios especiais, como os sistemas operacionais, podem executar instruções tanto de nível privilegiado quanto de nível não-privilegiado (SEMNANIAN et al., 2010). Os computadores podem operar em dois modos distintos: modo usuário ou espaço de aplicação e modo
supervisor. O primeiro é o modo onde as aplicações de usuários operam e embora não seja
possível executar instruções privilegiadas de acesso aos recursos do computador nesse modo, instruções não-privilegiadas podem ser executadas diretamente na CPU (MENASCÉ, 2005).
8 ISA – do inglês Instruction set architecture, trata-se de uma interface entre hardware e software e normalmente
segue um padrão específico, por exemplo o Intel IA-32 (x86),
9 Instruções que possuem o controle e alteram o estado dos recursos de hardware como CPU, memória, Discos e
O modo supervisor tem privilégios especiais para executar qualquer tipo de instruções, privilegiadas e não-privilegiadas, sendo o modo onde os sistemas operacionais operam (SMITH; NAIR, 2005).
Existem vários níveis de privilégios – rings, para a execução de instruções enumerados a partir do ring 0, de tal maneira que quanto mais baixo o nível, maior é o privilégio da aplicação (MENASCÉ, 2005). Os sistemas operacionais geralmente operam no ring 0 e as aplicações do modo usuário operam no ring mais alto (ring 3 na arquitetura x86) (UHLIG et al. 2005).
Em um cenário virtualizado temos dois tipos de sistemas: Hospedeiro e visitante. O
sistema hospedeiro – Host Operating System, é o sistema operacional que é instalado de
forma nativa na máquina, imediatamente sobre o hardware, opera no modo supervisor e constitui a camada de abstração (entre hardware e visitante) que realizará a virtualização (SEMNANIAN et al., 2010). O sistema visitante – Guest Operating System, é o S.O. instalado em uma máquina virtual – VM, virtualizada pelo sistema hospedeiro, que permite várias instâncias de máquinas virtuais em execução, uma vez que o hardware passa a ter uma camada de abstração de software (SORIGA; BARBULESCU, 2013). Um sistema visitante executa sobre o hardware virtualizado no modo usuário, e quando o primeiro tenta executar uma instrução privilegiada, uma interrupção é gerada e o hospedeiro emula essa instrução (SMITH; NAIR, 2005).
Para (SEMNANIAN et al., 2010), existem dois tipos de implementações de máquinas virtuais:
Hypervisor10: Um monitor de máquina virtual – VMM, que é instalado imediatamente sobre o hardware físico e protege os recursos de hardware de acessos não autorizados dos sistemas convidados. Essa interface estará disponível quando o computador estiver ligado e fornece um conjunto de instruções de máquina para os sistemas convidados. Nesse tipo de implementação de máquina virtual, vários sistemas operacionais convidados podem executar na mesma plataforma de maneira independente.
Máquina virtual de processo: Nessa implementação de máquina virtual, uma aplicação executa sobre o sistema operacional e fornece um ambiente de execução apropriado para outras aplicações. A máquina virtual java – JVM, é um exemplo
de máquina virtual de processo, bem como o VMWare Player executando um sistema Linux em plataforma Windows.
2.1.2 Hypervisores
A camada de abstração comumente é denominada VMM – Monitor de máquina virtual ou hypervisor, e tem a função de gerenciar os dispositivos físicos do computador, permitindo que várias instâncias de computadores virtuais executem simultaneamente através do compartilhamento de hardware, otimizando a utilização de recursos (SAHOO et al., 2010).
A camada de abstração de software que gerencia os recursos de hardware, possibilita a criação de unidades lógicas denominadas máquinas virtuais – VMs, garantindo o isolamento de recursos e segurança (UHLIG et al. 2005). Desta maneira, as máquinas virtuais possuem os mesmos recursos que um computador real, isto é, CPU, memória, disco rígido, interfaces de rede, dispositivos USB, drivers ópticos e etc. As máquinas virtuais podem ter seu próprio sistema operacional. Todavia, um gerenciador de máquinas virtuais deve garantir a execução simultânea das VMs com isolamento e segurança, de modo que uma instância de uma máquina virtual não atrapalhe o funcionamento e o desempenho de outras (MANIK, 2016).
Os Hypervisores ou monitores de máquinas virtuais são utilizados para criar, instanciar e gerenciar máquinas e recursos virtuais. O processo de criação de uma máquina virtual permite a configuração11 dos mesmos parâmetros de um computador real, isto é, CPU virtual (vCPU), memória RAM virtual (vRAM), disco rígido virtual (vDisk), interfaces de rede (vNIC) e etc. (MANIK, 2016). Para instalar um sistema operacional em uma VMs, normalmente utiliza-se uma imagem de disco, que contém todos os recursos necessários para a inicialização (boot) e instalação de um sistema operacional no disco rígido virtual (vDisk). Os hypervisores geralmente possuem comandos elementares fundamentais ao funcionamento das VMs (iniciar VM, parar, clonar, remover, salvar, restaurar estado, exportar e importar) e mecanismos para editar/gerenciar todos os recursos virtuais (SEMNANIAN et al., 2010).
11 A configuração dos recursos virtuais das VMs não pode exceder ou sobrecarregar os recursos físicos do
computador. Normalmente um processador físico de 4 núcleos não pode ser compartilhado com 4(quatro) máquinas virtuais que possuam 1(um) núcleo lógico, por que o sistema hospedeiro ou hypervisor precisa de no mínimo um núcleo para funcionar.
Podemos encontrar diversos hypervisores na indústria de tecnologia da informação para várias aplicações. Xen e KVM são os principais nomes quando o assunto é software livre. No âmbito comercial, Xen Server, VMware vSphere e Microsoft Hyper-V são alguns dos principais nomes (MANIK, 2016).
Figura 3: Tipos de hypervisores Fonte: [Elaboração Própria]
De acordo com (RODRÍGUEZ-HARO et al., 2012) há dois tipos de hypervisores:
Tipo 1 (Bare Metal) e tipo 2 (Hosted), conforme mostra a Figura 3.
1. Hypervisores tipo 1. São executados diretamente sobre o hardware da máquina (bare-metal) no anel de maior privilégio e se constituem em uma fina camada de software entre o hardware e as máquinas virtuais, sendo o hypervisor seu próprio sistema operacional. Hypervisores bare-metal se comunicam diretamente com o hardware subjacente, controlam todas as máquinas virtuais e apresentam menor latência e degradação de desempenho se comparados com o tipo 2. Os principais exemplos desse tipo de hypervisor são VMware ESX, Hyper-V e Xen (SCHLOSSER et al., 2011) (RODRÍGUEZ-HARO et al., 2012).
2. Hypervisores tipo 2. O hypervisor do tipo (hosted) é instalado sobre um sistema operacional como um programa aplicativo e depende do sistema hospedeiro para funcionar. Esse tipo de hypervisor não oferece o mesmo nível de segurança, robustez, confiabilidade e desempenho que os hypervisores bare-metal, uma vez que executam sobre um sistema operacional convencional, disputam recursos de hardware com outras aplicações e não são adequados para uso empresarial. A popularidade desse tipo de hypervisor se deve principalmente a possibilidade de execução em qualquer hardware, uma vez que o reconhecimento e a administração são realizados pelo sistema operacional. Exemplos de hypervisores hosted são VirtualBox (GROUP; RESERVED, 2009) e KVM (SCHLOSSER et al., 2011) (RODRÍGUEZ-HARO et al., 2012).
2.2
ABORDAGENS DE VIRTUALIZAÇÃO
A maneira como as máquinas virtuais são virtualizadas no hypervisor referem-se as abordagens de virtualização. A classificação realizada por (RODRÍGUEZ-HARO et al., 2012) divide as abordagens de virtualização do ponto de vista do sistema operacional em duas categorias principais:
1. Execução de convidados modificados. Envolve as técnicas de virtualização em nível de sistema operacional e a para-virtualização, que será discutida em detalhes na subseção 2.2.2. A primeira técnica utiliza o compartilhamento do kernel do host entre contêineres isolados para virtualizar o servidor físico no nível do sistema operacional. Trata-se de uma abordagem que oferece baixa sobrecarga e tem a desvantagem de não suportar vários kernels. Alguns exemplos dessa técnica são OpenVZ (ODIN, 2005), Linux-VServer (VSERVER, 2013) e Docker (DOCKER, 2016).
2. Execução de convidados não-modificados. Envolve duas abordagens de
virtualização: A tradução binária e a assistência de hardware, que será descrita detalhadamente na subseção 2.2.3. Para (RODRÍGUEZ-HARO et al., 2012), a tradução binária permite a execução de sistemas operacionais não modificados através da emulação de um conjunto de instruções por outro fazendo uso da tradução de código de máquina. Assim, esta técnica é utilizada para executar uma arquitetura de processador sobre outra arquitetura de processador. A principal desvantagem dessa técnica é a degradação de desempenho causada pela emulação do conjunto de instruções completo. QEMU (BELLARD, 2005) é um exemplo de emulação multiplataforma.
Apresentaremos a seguir as abordagens de virtualização que se relacionam com este trabalho: virtualização total, para-virtualização e virtualização assistida por hardware.
2.2.1 Virtualização total
Também denominada emulação de hardware, a virtualização total ou full, não exige a modificação do sistema operacional convidado. Desta maneira, o sistema operacional
convidado tem a ilusão de estar sendo executado sobre hardware físico (SAHOO et al., 2010), por que a existência de uma camada de abstração de software – o hypervisor, é transparente para o sistema convidado. Esta abordagem traz uma degradação de desempenho significativa para o sistema operacional visitante por que o comportamento do hardware físico é simulado pelo hypervisor.
Antes da execução de qualquer instrução do sistema operacional convidado, o hypervisor realiza um teste para determinar se a instrução é privilegiada ou não, o que acaba reduzindo consideravelmente o desempenho do sistema devido ao custo adicional de processamento. Na virtualização total, o hypervisor provê um ambiente virtual para as VMs semelhante a uma réplica do hardware, é executado acima deste e realiza a gestão de recursos físicos da máquina, tais como memória, processamento, E/S e rede (SAHOO et al., 2010). No entanto, devido à complexidade dos computadores e a variedade de dispositivos periféricos, é praticamente impossível reproduzir com exatidão o hardware de um computador em uma VM. Para sanar o problema, a solução é prover no hypervisor, o suporte genérico (drivers) para os dispositivos (SORIGA; BARBULESCU, 2013).
A virtualização total é a melhor opção em isolamento e segurança de máquinas virtuais e não possui assistência de hardware ou Sistema operacional (SEMNANIAN et al., 2010). A VMware foi a precursora da técnica que associa tradução binária dinâmica, técnicas de execução direta e virtualização total. Nesta abordagem as instruções não-sensíveis são executadas diretamente e um bloco equivalente de instruções sensíveis é o resultado da operação de um tradutor binário dinâmico sobre instruções sensíveis. Desta forma, é possível executar diretamente na CPU o bloco traduzido com o mesmo efeito das instruções de origem (CHEN et al. 2008).
2.2.2 Para-virtualização
A para-virtualização é uma técnica que contorna algumas limitações fundamentais da virtualização total, principalmente o desempenho. Diferentemente da virtualização full, a para-virtualização, também denominada virtualização assistida por sistema operacional, requer a modificação do kernel do sistema convidado para que este possa “enxergar” o hypervisor e trabalhar em conjunto com o mesmo. Sahoo et al. (2010) afirma que um sistema convidado para-virtualizado sabe que está sendo virtualizado (SAHOO et al., 2010).
Essa abordagem consegue oferecer um desempenho muito melhor que a virtualização total nos aspectos de CPU, Memória e E/S através do suporte especial ao kernel do Linux, que acaba sendo uma desvantagem nos aspectos de compatibilidade e controle de versões de sistemas convidados (BARHAM et al., 2003). Um hypervisor para-virtualizado não precisa testar todas as instruções originadas na máquina virtual para determinar se são sensíveis ou não por que o convidado aciona o VMM através de chamadas de sistema quando pretende executar uma instrução crítica que possa alterar o estado do sistema, fator que melhora o desempenho. As instruções não privilegiadas são executadas diretamente em hardware.
Na Para-virtualização o hypervisor é mais simples e consiste em uma fina camada de software entre o hardware físico e o sistema convidado, permitindo que os visitantes alcancem um desempenho bem mais próximo do nativo (RODRÍGUEZ-HARO et al., 2012) (SAHOO et al., 2010). Diferentemente dos ambientes totalmente virtualizados, que emulam os dispositivos do sistema como discos e interfaces de rede, a para-virtualização utiliza drivers separados e extensões paravirt (PVOPS) no núcleo do sistema Linux. Ao invés de utilizar drivers genéricos que limitam a capacidade total dos dispositivos como na virtualização total, a máquina virtual faz uso de drivers próprios. Para prover acesso aos dispositivos físicos de maneira eficiente, Xen (BARHAM et al., 2003) oferece um conjunto de interfaces otimizadas sem afetar negativamente os requisitos de isolamento e proteção (BARHAM et al., 2003).
Os principais exemplos de soluções de Para-virtualização de máquinas virtuais são Denali (WHITAKER et al., 2002) e Xen. Entre as desvantagens estão a necessidade de modificação do sistema operacional convidado (SORIGA; BARBULESCU, 2013).
2.2.3 Virtualização assistida por hardware
Embora a virtualização de sistemas x86 têm concentrado vários esforços para tornar o sistema operacional independente do hardware subjacente através da virtualização total e da Para-virtualização, esses métodos ainda precisam superar alguns desafios nas áreas de desempenho e complexidade. Desta forma, visando melhorias de desempenho e redução da complexidade, a Intel e a AMD desenvolveram extensões de virtualização para processadores x86, a partir da inclusão de suporte a virtualização a nível de hardware nos processadores, que passam a ser assistidos pelo hypervisor (CHEN et al. 2008). As extensões da Intel são conhecidas como Intel VT – Intel Virtualization Tecnology, para arquiteturas x86 de 32 e 64
bits e as extensões da AMD conhecidas como AMD-V (AMD Virtualization) se aplicam as arquiteturas x86 de 64 bits (AMEEN; HAMO, 2013).
A virtualização assistida por hardware foi viabilizada pelos novos recursos de virtualização incorporados nos novos processadores da Intel e AMD desde 2006, que possuem extensões do conjunto de instruções necessárias para a execução de sistemas operacionais convidados não modificados sem a necessidade de Para-virtualização ou tradução binária e suas respectivas desvantagens (SEMNANIAN et al., 2010).
A assistência de hardware acelera a execução de instruções privilegiadas a partir da implementação de um nível de privilégio mais alto (ring -1) na arquitetura do processador, permitindo assim que os hypervisores que suportam essa tecnologia sejam executados no ring -1 (modo raiz) e o sistema operacional convidado possa ascender ao nível de privilégio 0 (modo não-root) (RODRÍGUEZ-HARO et al., 2012). Desta forma, sistemas visitantes não-modificados podem executar normalmente como se estivessem diretamente sobre uma máquina física. Quando um sistema visitante tenta executar uma instrução sensível, uma interrupção é capturada e o hypervisor é acionado para tratá-la.
Uma vez atendida pelo hypervisor, a instrução é modificada e depois devolvida para a execução no processador (SEMNANIAN et al., 2010) (AMEEN; HAMO, 2013). O novo nível de privilégio (ring -1) foi implementado no processador nas tecnologias de assistência de hardware Intel-VT e AMD-V (CHEN et al. 2008).
2.3
KERNEL-BASED VIRTUAL MACHINE (KVM)
O Kernel-Based Virtual Machine – KVM (KIVITY et al., 2007), é um gerenciador de máquinas virtuais (VMM) de código aberto baseado em plataforma x86, desenvolvido e mantido pela Qumranet, Inc. O KVM consiste em uma solução de virtualização total que possui extensões de virtualização da Intel VT e AMD-V (SORIGA; BARBULESCU, 2013), foi integrado ao Kernel Linux em 2007 e o transforma em um hypervisor que aproveita as vantagens do Kernel padrão (GUO et al., 2015).
O KVM consiste em um módulo carregável denominado kvm.ko que implementa as funcionalidades fundamentais de virtualização como agendamento do processador e gerenciamento de memória e um módulo específico do processador, intel.ko ou kvm-amd.ko (ZENG; HAO, 2009). Para simular componentes de hardware de um computador, o KVM utiliza um emulador QEMU (BELLARD, 2005) estreitamente modificado que executa
no espaço de utilizador e fornece um modelo de operações de E/S (ZENG; HAO, 2009). Para o kernel Linux, uma máquina virtual se apresenta como um processo regular, uma vez que os convidados executam realmente no espaço de usuário (SORIGA; BARBULESCU, 2013).
O KVM adiciona um terceiro modo de execução no Linux além dos tradicionais modos kernel e usuário: O modo convidado (CHE et al., 2008). Este hypervisor concebe cada máquina virtual visitante com um processo convencional, fazendo com que as máquinas virtuais acabem disputando os recursos do sistema com outros processos em execução, fator que afeta negativamente o desempenho das máquinas virtuais por que o kernel não conhece a natureza especial da VM e não atribui maior prioridade (DING et al., 2010). De acordo com Soriga & Barbulescu (2013), a CPU virtual dos convidados é implementada com threads convencionais, o que é um fator positivo porque é possível atribuir prioridades e afinidades para esses processos e utilizar utilitários comuns do sistema.
A arquitetura KVM utiliza dispositivos de caracteres típicos /dev/kvm para instanciar e executar máquinas virtuais no espaço de usuário através de um conjunto de chamadas ioctls. Os dispositivos /dev/kvm fornecem algumas operações, tais como criar uma nova máquina virtual, atribuir memória a uma MV e etc (KIVITY et al., 2007). Na instanciação, as máquinas virtuais podem ter seu espaço de armazenamento alocado pelo agendador do sistema a partir da utilização de dispositivos /dev/kvm (CHE et al., 2008).
Li et al. (2009) afirma que para fornecer um conjunto de dispositivos virtuais para as VMs tais como interface de placa de rede virtual (vNIC), disco rígido virtual e etc., o KVM utiliza o emulador QEMU levemente modificado no espaço de usuário para fornecer um conjunto de dispositivos de E/S. QEMU utiliza dispositivos de rede virtual (TUN/TAP) em cada VM (que corresponde ao vNIC na VM) para enviar e receber pacotes entre máquinas virtuais e hosts (LI et al., 2009).
Na arquitetura KVM, cada máquina virtual s conecta em rede, envia e recebe pacotes de outras VMs ou de hosts na rede externa utilizando uma interface de rede virtual, vNIC, através de um processo QEMU modificado. QEMU também fornece dispositivos de rede virtual (TUN/TAP) para que as VMs se conectem as interfaces físicas por meio de um dispositivo de ponte virtual, Bridge, (LI et al., 2009). Através do subsistema Virtio, KVM também suporta a para-virtualização de E/S, permitindo que as máquinas virtuais alcancem um alto desempenho de rede e disco. Virtio é uma solução de virtualização de drivers de dispositivos, em que apenas o driver convidado tem ciência do ambiente virtual e coopera com o VMM (SORIGA; BARBULESCU, 2013). A Figura 4 mostra a arquitetura KVM.
Figura 4: Arquitetura KVM base Fonte: (PATEL et al., 2015)
2.4
XEN
Xen (XEN, 2014) é um hypervisor de código aberto muito popular que implementa para-virtualização de máquinas virtuais sem sacrificar o desempenho, baseado principalmente na plataforma x86 e suporta vários sistemas operacionais, incluindo Linux, Solares, Windows e algumas versões BSD (BARHAM et al., 2003). Xen é atualmente mantido e distribuído pela Citrix System, Inc., mas sua primeira versão foi originalmente desenvolvida na universidade de Cambridge e publicada em 2003 (CHE et al., 2008). Xen apresenta um desempenho muito melhor do que a virtualização total quando a máquina hospedeira não possui suporte a virtualização assistida por hardware, mas é preciso que os sistemas convidados sejam alterados para dar suporte à para-virtualização (HOSSEINIT; ANALOUI, 2015).
Na implementação da paravirtualização, Xen utiliza uma arquitetura composta por Hypervisor, sistema hospedeiro e domínios. O hypervisor executa diretamente sobre o hardware em um nível de privilégio mais alto que outros softwares que executam no computador, tendo como principais funções iniciar o domínio privilegiado Dom0 (Domínio 0), gerenciar o agendamento de CPU das máquinas virtuais, gerenciar a memória e também as funções de comunicação (BARHAM et al., 2003).
Xen pode enviar solicitações privilegiadas para o hardware, mas não detém os drivers de dispositivos que acessam diretamente os dispositivos físicos do computador. O domínio especial Dom0 contém os drivers de acesso para os dispositivos de E/S da máquina hospedeira, sendo responsável por gerenciar os domínios convidados, incluindo criação, inicialização, pausa, migração e interrupção destes (CHE et al., 2008). Embora Dom0 seja um domínio privilegiado que executa sobre o hypervisor, ele possui memória e CPUs virtuais
como os outros convidados. Os domínios não privilegiados – DomU, são os sistemas operacionais convidados que operam no nível de privilégio 1 do processador e só podem ter acesso ao hardware indiretamente através dos drivers disponíveis no domínio privilegiado (HOSSEINIT; ANALOUI, 2015).
Como pode ser observado na Figura 5, a comunicação entre o Dom0 e os DomU e realizada através de canais de E/S. Os drivers FrontEnd dos domínios não privilegiados são utilizados para trocar solicitações e respostas com o Dom0, que possui um driver BackEnd. Os canais de E/S são utilizados para evitar a degradação de desempenho de transferência de dados, uma vez que apenas as referências de memória para os buffers são transmitidas através do canal (SORIGA; BARBULESCU, 2013).
Figura 5: Arquitetura Xen Fonte: (PATEL et al., 2015)
A arquitetura Xen utiliza um mecanismo de anel de descritor de buffer assíncrono baseado em canais de dispositivos e uma memória compartilhada para implementar a virtualização de E/S. Xen implementa dois mecanismos de comunicação entre hypervisor e domínios: chamadas síncronas e eventos assíncronos. As chamadas síncronas utilizam hypercalls para enviar mensagens das VMs convidadas para Xen, enquanto os eventos assíncronos utilizam interrupções virtuais para enviar mensagens de Xen para as VMs convidadas (BARHAM et al., 2003). Quando os dados de um convidado são enviados para memória física, Dom0 intervém disparando uma interrupção virtual para aquele e realiza a troca de páginas, oferecendo uma página vazia para receber os dados ao invés de deixar os dados na página de memória que contém os dados do visitante (CHE et al., 2008).
O Xen suporta para-virtualização desde a sua concepção e alcança um desempenho muito bom com o custo da modificação do kernel do sistema operacional hospedeiro, mas tem como principal ponto negativo o fato de só suportar o sistema Linux, que precisa ter o kernel e o carregador de boot modificados. Com o surgimento das tecnologias de suporte a
virtualização de hardware, Xen também passou a suportar a virtualização total, não necessitando, portanto, da modificação dos sistemas operacionais visitantes (SORIGA; BARBULESCU, 2013).
2.5
VIRTUALIZAÇÃO DE FUNÇÕES DE REDE
Existe na tecnologia da informação, uma necessidade constante por redução dos custos operacionais (OPEX) e das despesas de capital (CAPEX), em cenários cujos investimentos precisam ser cada vez mais efetivos para obter um melhor retorno sobre o capital investido (LI; CHEN, 2015). Nesse contexto, a virtualização surgiu como uma estratégia para a redução de investimentos e custos operacionais, através da dissociação do aplicativo de software do hardware subjacente, com a execução do software em um ambiente virtualizado (HAWILO et al., 2014) .
Com o crescimento da internet e os avanços das telecomunicações, cresce a demanda por conectividade de rede de banda larga e qualidade de serviço, o que consiste em um grande desafio para os operadores, projetar e implementar serviços de rede em infraestruturas tradicionais, considerando aspectos de desempenho, resiliência, elasticidade e gerenciamento de topologia (BATTULA, 2014). Essa crescente demanda, pressiona os provedores a investir no aperfeiçoamento da infraestrutura para suprir as exigências dos usuários finais e aplicações de rede atuais (GIOTIS et al., 2015). A dependência substancial de redes em hardware subjacente tem aumentado os desafios dos operadores de redes, considerando a existência de vários equipamentos dedicados (como firewalls e roteadores) na infraestrutura (HAWILO et al., 2014). Neste contexto, a arquitetura de funções de rede virtualizada tem surgido como uma proposta para agilizar os negócios e diminuir custos operacionais (GIOTIS et al., 2015).
Através da arquitetura NFV podemos dissociar as funções de rede de um hardware específico, de forma que serviços podem executar como componentes de software em uma arquitetura virtualizada (GIOTIS et al., 2015), eliminando tanto a dependência de hardware específico de determinado fornecedor quanto o fim dos ciclos de vida reduzida do hardware proporcionados pelos avanços e inovação tecnológica. NFV é um conceito que transfere as funções de rede dos hardwares dedicados de fornecedores específicos para a execução em aplicações baseadas em software, que executam em equipamentos comerciais através de virtualização em plataformas consolidadas no mercado, como servidores de alto desempenho (LI; QIAN, 2016).
Entre os benefícios principais de NFV estão a melhor eficiência nos gastos de capital (CAPEX) em relação ao hardware dedicado, rápida implementação de novos serviços, flexibilidade na definição de funções de rede, redução de energia elétrica, padronização de interfaces e melhoria de eficiência nos processos operacionais (HAWILO et al., 2014).
Aproveitando as tecnologias de virtualização existentes, o grupo ETSI (ETSI, 2013) desenvolveu uma arquitetura de referência para implementação de NFV, onde os serviços de rede virtualizados são especificados para executar como uma aplicação de software sobre a infraestrutura NFV, que objetiva entre outros fatores, permitir a instanciação dinâmica de funções de rede virtuais e a orquestração de instâncias VNF (LI; CHEN, 2015). A arquitetura de referência também especifica as relações entre as instâncias NFV, suas dependências de dados e controle, conectividade entre outros atributos. Funções de rede virtualizadas podem estar relacionadas logicamente através de conectividade de rede que são representadas por grafos (NFV-FG), indicando por exemplo, a relação de interconexão lógica entre as funções DNS, roteamento e Proxy no provimento de algum serviço (HAWILO et al., 2014).
A arquitetura de alto nível para a virtualização de funções de rede compreende três blocos funcionais principais: Funções de rede virtualizadas (NFVs), Infraestrutura NFV (NFVI) e Gerenciamento e orquestração.
Funções de rede virtualizadas incluem funções que podem ser desempenhadas por gateways residenciais, roteadores, firewalls, servidores DNS, servidores DHCP entre outros (LI; QIAN, 2016). Uma função de rede pode executar em várias máquinas virtuais diferentes e podem ter relações de conectividade de rede e dependências de dados no provimento de um serviço. A infraestrutura NFV – NFVI, é composta pelo conjunto dos recursos de hardware e de software que dá suporte a implementação, execução e gerenciamento das NFVs.
Sobre a camada de hardware, temos uma camada de virtualização, que provê recursos de rede, processamento e armazenamento para as VNFs através de virtualização desses recursos. A camada de virtualização é muito importante para desacoplar o hardware utilizado das funções de rede, o que favorece a flexibilidade e redução de custos, de forma que o uso de hypervisores são soluções muito utilizadas.
O Gerenciador/orquestrador funciona como um controlador de diversos aspectos das VNFs, sendo responsáveis pelo gerenciamento de recursos de hardware sob sua autoridade, interação das VNFs com esses recursos, interação entre as funções virtuais e visibilidade da infraestrutura NFVI. O orquestrador também é responsável pela coleta de estatísticas, gerência de falhas e desempenho (HAWILO et al., 2014).
2.6
REDES DEFINIDAS POR SOFTWARE
Atualmente, o conjunto de tecnologias empregados na internet implica negativamente na evolução de novos sistemas de comunicação, uma vez que o TCP/IP não pode ser facilmente substituído por outros protocolos, sugerindo um processo de ossificação da internet (MACEDO et al. 2015). Neste contexto, aplicações e serviços atuais e emergentes tornam-se cada vez mais complexos e exigentes, havendo, portanto, uma necessidade de evolução da internet para enfrentar esses novos desafios. No entanto, por causa da sua base de implantação tais como infraestrutura física os protocolos, a internet tem se tornado extremamente resistente à evolução (NUNES et al., 2014).
As tradicionais redes IP são complexas e difíceis de administrar, sendo necessário para os administradores, configurar cada dispositivo individualmente para implementar políticas de rede de alto nível, bem como usar comandos de fornecedores específicos e de baixo nível. Além disso, as redes IPs são verticalmente integradas, com os planos de dados e de controle encapsulados dentro dos dispositivos de rede, fator que reduz a flexibilidade e restringe a inovação e evolução dessas redes (KREUTZ et al., 2015). Desta forma, como solução, invés de incorporar as políticas de manipulação de dados em hardware, podemos implementá-los como módulos de software. Essa abordagem permite um maior controle sobre o tráfego de rede pelos administradores, potencializando significativamente o desempenho em termos de utilização eficiente dos recursos. Essa ideia consiste em uma tecnologia inovadora, as Redes Definidas por Software – SDN (HU et al., 2014).
De acordo com Agarwal (2013), as redes definidas por software é um paradigma que quebra a integração vertical, com a separação radical dos planos de encaminhamento de pacotes e de controle, fornecendo aplicativos com uma visão centralizada abstrata do estado distribuído da rede. Os planos de dados e controle são interligados por interfaces públicas, e possibilitam a programação direta do plano de controle. Desta forma, todas as políticas de rede podem ser implementadas e gerenciadas de forma logicamente centralizada como um todo no controlador, possibilitando a gerencia da rede como uma entidade única e programável [AGARWAL, 2013] (AGARWAL, 2013).
O padrão mais amplamente utilizado e consolidates para redes SDN é o OpenFlow (MCKEOWN et al., 2008). Conforme podemos verificar na Figura 6, nas redes SDN, toda a inteligência se encontra logicamente centralizada em controladores baseados em software (plano de controle) e os dispositivos de rede tornam-se elementos de encaminhamento simples
de pacotes (plano de dados), que podem ser programados através de uma interface aberta como o OpenFlow (NUNES et al., 2014) (SALDANA et al., 2014).
Figura 6: Arquitetura SDN e suas abstrações fundamentais Fonte: (KREUTZ et al., 2015)
Em termos de gerenciamento, controle e monitoramento de redes, SDN resulta em maior desempenho. Com SDN é possível controlar características específicas dos dispositivos de encaminhamento, alterar arbitrariamente as tabelas de rotas de roteadores em uma rede a partir de um controlador central, sem a necessidade de configuração individual de dispositivos encaminhadores. Além disso, administradores podem configurar o bloqueio ou permissão de certos pacotes que fluem pela rede e atribuir priorização de tráfego para determinadas aplicações (HU et al., 2014).
As aplicações SDN programadas no controlador definem regras de manipulação de pacotes que caracterizam determinados tipos de tráfego. De acordo com Kreutz et al. (2015), um fluxo compreende uma sequência de pacotes entre uma origem e um destino. As regras indicam as ações a serem efetuadas sobre um conjunto de pacotes que pertencem a um fluxo específico e são instaladas nas tabelas de fluxo dos comutadores. Quando um comutador recebe uma solicitação de encaminhamento de pacotes e não possui nenhuma entrada de fluxo associada, o mesmo faz uma solicitação ao controlador para obter a informação pendente (KREUTZ et al., 2015). A Figura 7 mostra um esquema das tabelas de fluxos de dispositivos habilitados para o protocolo OpenFlow.
Figura 7: Dispositivos SDN habilitados para OpenFlow Fonte: (ALENCAR et al., 2014)
2.6.1 Controladores SDN
Em uma rede SDN, o controlador é o elemento fundamental, uma vez que centraliza toda a gerência e a programação da rede, possibilitando ainda a unificação das políticas definidas pelos administradores de rede (ZHAO et al., 2015). O controlador centraliza toda a lógica de controle da rede e fornece os recursos e abstrações fundamentais para a programação de dispositivos de encaminhamento, além de fornecer uma visão global da rede suportada pela coleta de informações do plano de dados, como o estado dos switches e conexões (KREUTZ et al., 2015).
Controller Language OpenFlow Multi-thread
POX Python 1.0 No
NOX C++ 1.0 No
Floodlight Java 1.1 Yes
Beacon Java 1.0 Yes
Programmable Flow C 1.3 No
Tabela 1: Controladores SDN Fonte: (ALENCAR et al., 2014)
Controladores SDN são softwares capazes de se comunicar com dispositivos de encaminhamento através do padrão OpenFlow para obter e fornecer informações de controle de rede e dos comutadores, bem como dos seus respetivos estados, instruindo-os na tomada de decisões de encaminhamento do plano de dados (LAISSAOUI et al., 2015). Existem mais de 30 tipos de controladores para as mais diversas aplicações e preferências, que variam de
acordo com a tecnologia de ambiente de execução, linguagem de programação, conjunto de APIs12 e recursos utilizados (ZHAO et al., 2015).
POX (KREUTZ et al., 2015), NOX (KREUTZ et al., 2015), Floodlight (MORALES et al., 2016), Beacon (ERICKSON, 2013) e Programmable Flow (KREUTZ et al., 2015) são alguns controladores bem conhecidos e amplamente utilizados conforme mostra a Tabela 1.
2.6.2 Floodlight
Floodlight (FLOODLIGHT, 2016) é um controlador SDN muito popular no meio acadêmico que possui licença Apache, executa no ambiente Java, é modular e projetado para ter bom desempenho (ALENCAR et al., 2014). Por ser modular, este controlador suporta uma série de aprimoramentos e subsídios para sua extensão, além de ser bastante flexível e facilitar o desenvolvimento de novas aplicações SDN (MORALES et al., 2016). O projeto foi baseado em Beacon, e é suportado por uma comunidade de desenvolvedores e também recebe o apoio de um startup que produz produtos comerciais compatíveis com o Floodlight, a The Big Switch Networks (ALENCAR et al., 2014).
Por ser desenvolvido em Java, Floodlight tem a vantagem de suportar diversas plataformas de sistemas operacionais, possuir ótimo gerenciamento de memória, e oferecer suporte a múltiplos threads. Além de suportar uma variedade de comutadores físicos, Floodlight também suporta comutadores virtuais, o que facilita o desenvolvimento de experimentos e agiliza o desenvolvimento e testes de novos módulos em ambientes virtuais (MORZHOV et al., 2016) (MORALES et al., 2016).
Utilizaremos o controlador Floodlight neste trabalho devido ao suporte e documentação disponível, facilidade de instalação e configuração, desempenho e portabilidade. Uma pesquisa realizada em (LAISSAOUI et al., 2015) compara quatro populares controladores de código aberto e conclui que, de maneira geral, Floodlight é melhor Beacon, Pox e Ryu em uma rede SDN com suporte a OpenFlow versão 1.0, o que reforça a escolha de Floodlight.
