ARQUITETURA SDNCLOUD: PROPOSTA, PARAMETRIZAÇÃO DE
ELASTICIDADE E BALANCEAMENTO DE CARGA EM NUVEM
COMPUTACIONAL DEFINIDA POR SOFTWARE
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
RECIFE 2017
ARQUITETURA SDNCLOUD: PROPOSTA, PARAMETRIZAÇÃO DE
ELASTICIDADE E BALANCEAMENTO DE CARGA EM NUVEM
COMPUTACIONAL DEFINIDA POR SOFTWARE
Este trabalho foi apresentado à Pós-graduação em Ciên-cia da Computação do Centro de Informática da Universi-dade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.
Orientador: Kelvin Lopes Dias
RECIFE 2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
A958a Ávila, Igor Meneguitte
Arquitetura SDNCLOUD: proposta, parametrização de elasticidade e balanceamento de carga em nuvem computacional definida por software / Igor Meneguitte Ávila. – 2017.
100 f.: il., fig., tab.
Orientador: Kelvin Lopes Dias.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências e apêndices.
1. Redes de computadores. 2. Computação em nuvem. I. Dias, Kelvin Lopes (orientador). II. Título.
004.6 CDD (23. ed.) UFPE- MEI 2017-115
Arquitetura SDNCLOUD: proposta, parametrização de elasticidade
e balanceamento de carga em nuvem computacional definida por
software
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 24 de fevereiro de 2017.
Aprovado em: 24/02/2017.
BANCA EXAMINADORA
__________________________________________ Prof. Kiev Santos da Gama
Centro de Informática / UFPE
__________________________________________ Prof. Andson Marreiros Balieiro
Universidade de Pernambuco
__________________________________________ Prof. Kelvin Lopes Dias
Centro de Informática / UFPE (Orientador)
Agradecimentos
A Deus por ter me dado força e determinação para superar todas as adversidades presentes no caminho.
A minha mãe, que sempre me apoiou em todos os meus objetivos e metas. Seu jeito doce e enérgico de ser, sempre me dá forças para continuar e nunca desistir.
Minha irmã e pai, por sempre me incentivaram e apoiarem as minhas decisões.
Ao meu orientador, Prof. Kelvin, pela paciência com as minhas diversas mensagens e e-mails e por ter acreditado na minha ideia, lapidando-a.
Ao Prof. Rhodney, pela paciência, disponibilidade e conselhos. Seus ensinamentos foram mais do que de um professor, foram de um amigo.
Aos amigos e companheiros de pousada e mestrado Thiago Martorelli e Marcos Pantoja, pelo companheirismo, amizade e incentivo.
Aos meus amigos de setor do Campus Muriaé, Reginaldo, Saulo, Dayene e Rafael, por entende-rem o meu momento e me apoiaentende-rem de todas as formas necessárias.
Aos amigos e demais colegas de mestrado que sempre lançaram palavras de incentivo nos momentos em que eu estava cansado, enjoado e chateado com as dificuldades encontradas neste caminho.
mesmo expondo-se a derrota, do que formar fila com os pobres de espírito que nem gozam muito nem sofrem muito, porque vivem nessa penumbra cinzenta que não conhece vitória nem derrota.
Resumo
Em instituições federais de ensino, onde há sérias limitações orçamentárias e de infraes-trutura com poucos recursos computacionais, a Computação em Nuvem (CN) surge como uma solução para a hospedagem de Ambientes Virtuais de Aprendizagem (AVAs). A elasticidade sob demanda e o balanceamento de carga permitem o aproveitamento do parque tecnológico, reutilizando de maneira distribuída os equipamentos descontinuados e com poucos recursos computacionais. CN é extremamente flexível quanto à virtualização de sua infraestrutura de hardware com o uso de hipervisores e máquinas virtuais, porém as redes que conectam os recur-sos de processamento e armazenamento da CN, continuam rígidas e com pouca flexibilidade. O processo de configuração e atualização da rede é realizado individualmente, de maneira estática e pouco eficiente. Diante da ossificação das redes surge o paradigma de Redes Definidas por Software Software Defined Networking (SDN), que tem como objetivo tornar as redes dinâmicas e programáveis. O controlador SDN tem papel centralizador, sendo o responsável por coordenar as ações dos elementos de rede, alavancar a programação de redes e realizar gerenciamento de conectividade. A integração com SDN torna os ambientes de CN mais flexíveis, estendendo-os e permitindo novas soluções. Este trabalho propõe SDNCloud, uma arquitetura que integra SDN à CN com suporte à elasticidade e balanceamento de carga para um ambiente virtual de aprendizagem. O testbed implementado utiliza controlador SDN OpenDayLight integrado, fa-zendo com que os switches virtuais do OpenStack sejam gerenciados por controlador OpenFlow. Para avaliar a proposta foi utilizado modelo de tráfego baseado em logs de transações e banco de dados da operação de um ambiente real (Moodle) de ensino à distância do Campus Muriaé do Instituto Federal do Sudeste de Minas Gerais. Após a caracterização e a modelagem foi encontrado, via análise de aderência, a distribuição generalização de pareto para os intervalos entre as requisições e extraída as informações para parametrização da elasticidade. Os resultados mostram a importância na escolha apropriada das métricas para o processo de elasticidade e para medir sua qualidade. Utilização de Central Processing Unit (CPU), utilização de memória, bytes de entrada e bytes de saída foram métricas testadas para o processo de elasticidade, enquanto tempo de resposta médio e taxa de perda de requisição para dimensionar a qualidade da mesma. Além das métricas, os resultados demonstram a relevância do trade-off entre os limiares de elasticidade positiva, negativa e intervalo entre as elasticidades para a qualidade da elasticidade. Nos resultados, ainda, foram comparados o modelo tradicional de CN com SDNCloud, revelando que a utilização da arquitetura proposta melhora o desempenho dos switches virtuais.
Palavras-chave: Computação em Nuvem. Balanceamento de Carga. Elasticidade. Redes Definidas por Software. Ambientes Virtuais de Aprendizagem.
Abstract
In federal educational institutions, where there are serious budgetary constraints and infrastructure with few computational resources, Cloud Computing (CC) emerges as a solution for hosting Virtual Learning Environments (VLE). The elasticity of demand and the load balancing allow the use of the technological park, reusing in a distributed way the discontinued equipment and with few computational resources. CC is extremely flexible in terms of virtualizing its hardware infrastructure with the use of hypervisors and virtual machines, however the networks which connect processing resources and CC’s storage remain rigid and with little flexibility. The process of setting up and updating the network is done individually, in a static and little efficient way. Faced the network ossification, the Software Defined Networking (SDN) paradigm emerges, which aims to become the networks more dynamic and programmable. The SDN controller has a centralizing role, being responsible for coordinating the actions of network elements, leveraging network programming and performing connectivity management. Integration with SDN makes CC environments more flexible, extending them and enabling new solutions. This work proposes SDNCloud, an architecture which integrates SDN to CC with elasticity support and load balancing, for a virtual learning environment. The implemented testbed uses integrated OpenDayLight SDN controller, making The OpenStack virtual switches being managed by OpenFlow controller. In order to evaluate the proposal, it was used traffic model based on transaction logs and database of the operation of a real environment (Moodle) of distance learning of Southeast Federal Institute of Minas Gerais - Campus Muriaé. After characterization and modeling, the pareto generalization distribution was found via adherence analysis for the intervals between the requisitions and extracted the information for parameterization of the elasticity. The results showed how is important to choose an appropriate metrics to the elasticity process and to measure its quality. The use of CPU, memory, input and output bytes were the metric tested for the elasticity process, in terms of time response rate and request lost tax to design the same quality. Besides the metrics, the results demonstrated the trade-off relevance between the thresholds of positive elasticity, negative and the interval between the “elasticities” to the elasticity quality. In the results, still, were compared the traditional approach of CC with the SDNCloud, revealing that the use of the architecture propose improve the performance of the virtual switches.
Keywords: Cloud computing. load balancing. elasticity. software-defined networks. virtual learning environments.
Lista de Figuras
2.1 Diagrama de computação em nuvem . . . 24
2.2 Características essenciais . . . 25
2.3 Arquitetura de computação em nuvem . . . 27
2.4 Modelos de serviço . . . 28
2.5 Modelos de serviços emergentes . . . 30
2.6 Modelos de desenvolvimento de nuvens . . . 31
2.7 Paradigma de computação em nuvem: visão global . . . 32
2.8 Arquitetura dos controladores de nuvem . . . 33
2.9 Arquitetura mínima do OpenStack Kilo . . . 36
2.10 Arquitetura de serviços do Neutron . . . 39
2.11 Arquitetura do ML2 . . . 40
2.12 Arquitetura do Ceilometer . . . 42
2.13 Arquitetura do Heat . . . 43
2.14 Arquitetura do OpenNebula . . . 44
2.15 Camadas, serviços e ferramentas de OpenNebula. . . 45
2.16 Arquitetura do Eucalyptus . . . 46
2.17 Classificação Elasticidade. . . 48
2.18 Arquitetura Redes Definidas por Software. . . 50
2.19 Dispositivos com OpenFlow habilitado. . . 52
2.20 Matching na versão 1.0 OpenFlow . . . 52
2.21 Plataforma de Controle SDN. . . 54
2.22 Interface East/Weast. . . 54
2.23 Arquitetura OpenDayLight (ODL) . . . 56
2.24 Arquitetura de core distribuído do ONOS . . . 57
2.25 Evolução do número de matrículas (2003/2014) . . . 59
3.1 Arquitetura de interações dos módulos de SDNCloud . . . 66
3.2 Arquitetura SDNCloud . . . 67
3.3 Ambiente de Experimentação . . . 69
3.4 Diagrama de sequência da arquitetura SDNCloud . . . 70
3.5 Diagrama de sequência entre neutron e controlador SDN . . . 71
4.1 Métricas avaliadas para elasticidade e tempo de resposta . . . 76
4.2 Tempo de resposta médio por experimento. . . 77
4.3 Taxa de perda de requisição sem SDNCloud. . . 77
4.6 Pior taxa de perda sem SDNCloud (90-30-960) . . . 79 4.7 Melhor taxa de perda com SDNCloud (SDN-50-10-240) . . . 79 4.8 Pior taxa de perda com SDNCloud (SDN-90-30-960) . . . 80
Lista de Tabelas
2.1 Versões do OpenStack . . . 34
2.2 Serviços e projetos do OpenStack Kilo. . . 35
2.3 Revisão sobre conceitos genéricos de redes. . . 37
2.4 Revisão sobre tecnologias de tunelamento. . . 38
2.5 Revisão sobre tradução de endereços. . . 38
2.6 Descrição das funcionalidades dos componentes do Eucalyptus. . . 46
2.7 Descrição dos tipos de mensagens OpenFlow. . . 53
2.8 Descrição de módulos AVA . . . 60
3.1 Comparação entre trabalhos relacionados . . . 65
3.2 Configurações das Virtual Machines (VMs) do ambiente de experimentação . . 68
4.1 Padrões de tráfego de dados do Moodle. . . 73
4.2 Logs com padrão de tráfego . . . 74
4.3 Resultado teste de aderência . . . 74
Lista de Acrônimos
NIST National Institute of Standards and Technology . . . 23
TIC Tecnologias da Informação e Comunicação . . . 22
SLA Service Level Agreements . . . 23
TI Tecnologia da Informação. . . .24
CN Computação em Nuvem . . . 17
CAPEX Capital Expenditure . . . 25
OPEX Operational Expenditure . . . 23
DC Data Center . . . 18
QoS Quality of Service . . . 26
IaaS Infrasctruture as a Service . . . 27
PaaS Platform as a Service . . . 27
SaaS Software as a Service . . . 27
UC Utility Computing . . . 22
SO Sistema Operacional. . . .28
VMs Virtual Machines . . . 23
VM Virtual Machine. . . .36
CRM Customer Relationship Management . . . 30
VPC Virtual Private Cloud . . . 32
VPN Virtual Private Network . . . 32
DBaaS DataBase as a Service . . . 35
NCaaS Network Configuration as a Service . . . 35
SQL Structured Query Language . . . 36
NTP Network Time Protocol . . . 36
NAT Network Address Translation . . . 36
DHCP Dynamic Host Configuration Protocol . . . 36
IP Internet Protocol . . . 36
KVM Kernel-based Virtual Machine . . . 36
FWaaS FireWall as a Service . . . 36
OVS OpenVSwitch . . . 37
DNS Domain Name System . . . 37
API Application Programming Interface . . . 28
OSI Open systems interconection . . . 37
GRE Generic Routing Encapsulation . . . 38
VXLAN Virtual Extensible Local Area Network . . . 38
UDP User Datagram Protocol . . . 37
VLAN Virtual Local Area Network . . . 37
SNAT Source Network Address Translation . . . 38
DNAT Destination Network Address Translation. . . .38
ML2 Modular Layer 2 . . . 39
SDN Software-Defined Networking . . . 18
MaaS Monitoring as a Service . . . 41
HOT Heat Orchestration Template . . . 43
CLI Command Line Interface. . . .43
EaD Educação à Distância . . . 19
AVAs Ambientes Virtuais de Aprendizagem . . . 60
CMP Cloud Management Platforms . . . 33
EC2 Elastic Compute Cloud . . . 47
S3 Simple Storage Service . . . 47
IAM Identity and Access Management . . . 47
SDN Software Defined Networking . . . 18
ODL OpenDayLight . . . 55
SAL Services Abstraction Layer . . . 55
ONOS Open Network Operating System . . . 57
ON.Lab Open Networking Lab . . . 57
ONF Open Network Foundation . . . 57
AVA Ambiente Virtual de Aprendizagem . . . 19
FIB Forwarding Information Base . . . 80 CAM Content Addressable Memory . . . 80
Sumário
1 Introdução ... 17 1.1 Motivação ... 18 1.2 Objetivos ... 19 1.3 Contribuições ... 20 1.4 Organização ... 20 2 Fundamentação Teórica ... 22 2.1 Computação em Nuvem ... 22 2.1.1 Conceitos Iniciais ... 22 2.1.2 Características Essenciais ... 24 2.1.3 Camadas ... 26 2.1.4 Modelos de Serviços ... 27 2.1.4.1 IaaS ... 28 2.1.4.2 PaaS ... 29 2.1.4.3 SaaS ... 29 2.1.5 Modelos de Desenvolvimento ... 30 2.1.5.1 Privada ... 31 2.1.5.2 Comunitária ... 31 2.1.5.3 Pública ... 31 2.1.5.4 Híbrida ... 32 2.1.6 Controladores de Nuvem ... 33 2.1.6.1 OpenStack ... 34 2.1.6.1.1 Arquitetura ... 35 2.1.6.1.2 Neutron ... 36 2.1.6.1.3 Ceilometer ... 41 2.1.6.1.4 Heat ... 43 2.1.6.2 OpenNebula ... 44 2.1.6.3 Eucalyptus ... 452.2 Elasticidade / Provisionamento Dinâmico ... 47
2.2.1 Métodos ... 48
2.2.2 Políticas ... 49
2.2.3 Métricas para Elasticidade ... 49
2.3.2 Plataforma para Controle SDN ... 53
2.3.2.1 NOX/POX ... 55
2.3.2.2 OpenDaylight ... 55
2.3.2.3 ONOS ... 57
2.4 Educação à Distância ... 58
3 Estado da Arte e SDNCloud ... 61
3.1 Elasticidade em computação em nuvem ... 61
3.2 Balanceamento de Carga ... 62
3.3 Computação em nuvem com controlador SDN ... 63
3.4 Comparação ... 64 3.5 Descrição da proposta ... 65 3.6 Arquitetura ... 66 3.7 Ambiente ... 68 4 Avaliação ... 72 4.1 Cenário ... 72 4.2 Caracterização de tráfego ... 74 4.3 Geração de Carga ... 75
4.4 Métricas, fatores e níveis ... 75
4.5 Resultados ... 76
5 Conclusão e trabalhos futuros ... 82
5.1 Principais resultados ... 82 5.2 Trabalhos futuros ... 83 Referências ... 85 Apêndice ... 91 A Templates de Orquestração ... 92 A.1 Elasticidade ... 92
A.2 Balanceador de Carga ... 96
B Geração de carga e números aleatórios ... 98
B.1 Módulo Gera Carga ... 98
B.1.1 Download ... 99
B.1.2 Upload ...100
1
Introdução
A virtualização de um centro de dados (do inglês, Data Center - DC) tradicional permite a segmentação de uma máquina física em várias máquinas virtuais (do inglês, Virtual Machines -VMs). Nesse contexto, inclui-se uma camada de abstração sobre as máquinas físicas, tornando o ambiente totalmente flexível a alterações no hardware, uma vez que os sistemas operacionais e aplicações pertencem a uma camada superior que foi virtualizada.
A inclusão de Computação em Nuvem (CN) (ARMBRUST et al.,2010) nesses ambientes resulta em algumas vantagens comparando-se aos ambientes tradicionais. Entre elas, cita-se o pagamento somente pelo que é utilizado, com possibilidade de expansão dos recursos computacionais, dando a impressão de que eles são infinitos.
Implementações mais complexas permitem a adição de conceitos como elasticidade (HERBST; KOUNEV; REUSSNER,2013a) sob demanda, orquestração e balanceamento de carga. Na elasticidade os recursos computacionais tornam-se escaláveis horizontalmente, ou seja, há uma expansão na quantidade de instâncias virtuais para atender as demandas dos serviços hospedados na nuvem. Com o auxílio da orquestração e de ferramentas para monitoramento de recursos, ações de elasticidade podem ser automatizadas, fazendo com que não seja necessária a intervenção dos operadores de nuvem para que as ações de elasticidade sejam executadas, surgindo, com isso, a elasticidade sob demanda.
Como o número de instâncias virtuais aumenta ou diminui de acordo com a demanda, nativamente junto ao conceito de elasticidade está inserido o balanceamento de carga, distribuindo as requisições entre as referidas instâncias virtuais. Não é imperativo ter um balanceador de cargas sempre que houver elasticidade, mas essa união é muito comum quando se tratam de aplicações web.
A orquestração (MELL; GRANCE,2011) tem papel fundamental nesse contexto, pois, por intermédio dela, há um sincronismo nas ações de elasticidade, a fim de monitorar os recursos, identificar o momento para escalar os recursos, incluir ou remover membros no balanceador e tornar o serviço sob demanda de utilização.
Devido à flexibilização existente em CN, surge a necessidade de incluir novas funcionali-dades na infraestrutura de rede. Atualmente são rígidas e pouco versáteis, sendo imprescindível
configurações mais rápidas e dinâmicas. Os ativos de rede até então eram considerados caixas fechadas (black boxes), ou seja, cada fabricante implementa suas próprias funcionalidades, muitas vezes impossibilitando a comunicação com outros equipamentos.
Com o surgimento de virtualização de rede com Software Defined Networking (SDN) NUNES et al.(2014) as redes dos Data Center (DC) tornaram-se mais flexíveis. Houve o desa-coplamento dos planos de dados e de controle. No plano de controle foi incluída uma entidade centralizadora, para gerenciar e coordenar as ações dos ativos de rede. Nessa arquitetura, os switches ou plano de dados fazem apenas o encaminhamento dos fluxos, deixando toda a gerência sob a responsabilidade do plano de controle. Visão global dos equipamentos de rede, progra-mabilidade, gerenciamento de conectividade, melhorias nas decisões dos encaminhamentos dos fluxos, diminuição no overhead associado ao gerenciamento dos switches virtuais e coordenação das ações dos elementos de rede foram algumas das conquistas alcançadas.
Este trabalho aborda a orquestração de nuvens elásticas e balanceadas sob demanda, além da integração de SDN com CN, o que torna as nuvens mais flexíveis e adiciona o conceito de programabilidade em redes. São abordados aspectos fundamentais sobre a parametrização do ambiente, a escolha correta da métrica e dos limites mais eficientes tanto para alocação quanto para liberação de recursos diante do tráfego aplicado.
1.1 Motivação
CN surgiu da necessidade de prover recursos computacionais (memória, processamento, largura de banda de rede etc.) como forma de serviço NIST (MELL; GRANCE,2011). Assim, o usuário paga apenas pelo que utilizou seguindo o modelo pay as you go (ARMBRUST et al., 2010). Dessa forma, não há a necessidade de aquisição de uma infraestrutura complexa, de alto custo e de difícil gerenciamento.
Neste sentido, a utilização de elasticidade em CN surge como requisito para otimizar o uso dos recursos existentes, além da reciclagem do parque tecnológico (Yazhou Hu et al., 2016). O serviço é hospedado utilizando o mínimo de recursos computacionais necessários ao seu funcionamento, escalando-o horizontalmente com a inclusão de novas instâncias virtuais, adicionando recursos complementares sob demanda. Um balanceador de carga faz-se necessário para distribuir dinamicamente as requisições entre as instâncias a serem criadas ou removidas com a elasticidade. A solução busca o provimento de um ambiente eficiente sob demanda, de forma automática e orquestrada.
Existem provedores1 2 e controladores3 4de nuvem que fornecem o serviço de elasti-cidade sob demanda. No entanto, o emprego adequado desta funcionalidade depende de uma investigação para determinar quais métricas e parâmetros utilizar para realizar a elasticidade.
1aws.amazon.com 2www.rackspace.com 3www.openstack.org 4www.opennebula.org
Devido à flexibilização existente em CN, surge a necessidade de incluir novas funcio-nalidades na infraestrutura de rede. Atualmente, o ambiente de redes é rígido, dependente das aplicações proprietárias presentes nos ativos de rede, que, por não interagirem entre si em muitos dos casos permitem pouca flexibilidade quanto ao seu gerenciamento. SDN (NUNES et al., 2014) surge para alavancar a programabilidade de redes e o gerenciamento de conectividade para serviços em nuvem devido ao desacoplamento do plano de dados do plano de controle, além de prover uma visão global da rede. A integração de SDN com CN proporciona a nível de redes a flexibilidade necessária para este ambiente no contexto de CN (KREUTZ et al.,2015).
Nos institutos federais de ensino, uma aplicação fundamental é a EaD. Com o uso de ferramentas de comunicação, ela aumenta a capacidade do sistema de educação e dá suporte ao aprendizado dos estudantes. A Educação à Distância (EaD) tem como previsão uma taxa de crescimento anual composta de cerca de 11% até 2020 (TECHNAVIO,2016). Diante do crescimento já esperado deste formato de ensino, das limitações orçamentárias das instituições federais de ensino e de recursos computacionais dos DC, tornam-se necessárias novas estratégias para a gestão de recursos. Maximizar o uso sob demanda dos recursos existentes e reaproveitar, de forma distribuída, equipamentos descontinuados e com poucos recursos são algumas dessas alternativas.
Este trabalho apresenta SDNCloud, sua arquitetura contempla a integração de um contro-lador SDN a um ambiente de CN que realiza balanceamento de carga e elasticidade sob demanda. Além disso, apresenta os resultados da avaliação de desempenho de uma plataforma de EaD, utilizando SDNCloud. Esta investigação foi realizada comparando-se dois cenários distintos: o primeiro em um ambiente de CN tradicional; e, o segundo desacoplando os planos de dados e controle, fazendo a inclusão de um controlador SDN.
1.2 Objetivos
O objetivo geral deste trabalho de pesquisa é encontrar uma solução de hospedagem para um Ambiente Virtual de Aprendizagem (AVA) do Instituto Federal do Sudeste de Minas Gerais, Campus Muriaé, que leve em consideração as limitações orçamentárias e de recursos computacionais, incorporando a expansão prevista para o EaD até 2020.
O trabalho visa elaborar, implementar e avaliar SDNCloud, aplicando tráfego realista de um sistema de EaD. Obter uma maior compreensão sobre qual a métrica mais útil para a elasticidade, quais os parâmetros de elasticidade possuem o melhor compromisso (trade-off) com a taxas de requisições atendidas e negadas, bem como integrar a um controlador SDN ao ambiente de CN tradicional.
Os objetivos específicos são:
� analisar se a elasticidade de SDNCloud pode ser orquestrada de forma automática e se a ferramenta de orquestração é eficiente a ponto de atender às necessidades de
acesso ao AVA;
� avaliar a eficiência da orquestração com elasticidade das instâncias virtuais, bem como a inclusão e exclusão das mesmas no balanceador de cargas;
� analisar a possibilidade de balancear cargas de um serviço web através de nuvem elástica orquestrada;
� avaliar a possibilidade de implementar o conceito de programabilidade em nuvens computacionais elásticas, integrando um controlador SDN a um ambiente de compu-tação em nuvem tradicional;
� avaliar a métrica mais apropriada para o processo de elasticidade diante das mais de diversas cargas de trabalho aplicadas; e,
� identificar a implicação da variação dos limiares de elasticidade positiva, negativa e intervalo entre medições no aumento e na diminuição da taxa de requisições negadas.
1.3 Contribuições
As principais contribuições do trabalho são:
� Implementação de ambiente experimental com tráfego realista e obtenção de resul-tados que demonstram que a solução SDNCloud apresenta menor taxa de perda de requisição em comparação ao ambiente tradicional de CN;
� Identificação da métrica mais apropriada para a elasticidade e dos parâmetros mais influenciam o desempenho da métrica escolhida;
� Caracterização de tráfego de um ambiente virtual de aprendizagem (AVA); e, � mostrar que SDNCloud é capaz de substituir infraestruturas sem virtualização e com
mais recursos.
1.4 Organização
No Capítulo 2 são apresentadas as informações necessárias para contextualizar o leitor ao tema abordado no trabalho. No Capítulo 3 é exposto o estado da arte, comparando as contribui-ções de outros trabalhos com as deste trabalho de pesquisa. Em seguida é apresentado SDNCloud, descrevendo toda a sua arquitetura, o ambiente de experimentação e o seu funcionamento. No Capítulo 4 é descrita a metodologia utilizada na pesquisa. Apresenta a configuração do ambiente de experimentação, incluindo o template de orquestração, os cenários em que foram aplicados, bem como foram realizadas a coleta, o tratamento de dados, a caracterização de tráfego, a geração
de carga e as métricas, os fatores e os níveis aplicados. Exibe ainda os resultados obtidos com os experimentos e discuti as questões relevantes sobre o estudo. Por fim, no Capítulo 5, conclui-se a dissertação com uma breve descrição do trabalho realizado, além dos trabalhos futuros.
2
Fundamentação Teórica
Neste capítulo serão apresentados alguns dos principais conceitos e termos utilizados em computação em nuvem, elasticidade, redes definidas por software e Educação à Distância que serão relevantes a este trabalho.
2.1 Computação em Nuvem
Com a evolução das Tecnologias da Informação e Comunicação (TIC), percebeu-se uma mudança nas necessidades básicas dos indivíduos. Os sistemas computacionais deixaram de ser ferramentas utópicas, presentes apenas em filmes de ficção científica, para fazerem parte do cotidiano das pessoas. Com essa evolução, tornou-se possível o desenvolvimento de novas aplicações que, em diversos casos, facilitam as vidas das pessoas. (BUYYA et al.,2009)
Diante da sua rápida evolução e do desenvolvimento da sociedade moderna, a computação começa a se inserir como um serviço básico e essencial, entregue quase que de forma transparente aos usuários. Até pouco tempo, os serviços considerados básicos e de utilidade pública eram água, eletricidade, telefone e gás. O termo em inglês commodity é utilizado para classificar serviços dessa natureza. Eles normalmente são tarifados através de seu uso sob demanda. (MELL; GRANCE,2011)
CN é um modelo de computação orientada para o mercado e possui algumas característi-cas de outras tecnologias que se juntam em uma única abstração. Muitas vezes CN é confundida com outras tecnologias devido a esses aspectos. Algumas das tecnologias relacionadas são: grid computing, Utility Computing (UC) e virtualização. (GARG; BUYYA,2012)
2.1.1 Conceitos Iniciais
UC propõe a tarifação diferenciada pelo uso de recursos computacionais (memória, processamento, largura de banda de rede etc.) e a utilização sob demanda, e não tarifado de maneira fixa como realizado anteriormente. Essas características de UC foram muito exploradas pelo mercado. A inclusão de planos diferenciados por utilização de recursos e o provisionamento dinâmico tornou a CN extremamente competitiva em comparação a outras soluções de mercado.
Para os provedores maximizar a utilização de recursos não resulta necessariamente no aumento da Operational Expenditure (OPEX), já que o custo é mínimo, devido à dinamicidade do provisionamento. Essa expansão dinâmica dá ao usuário a impressão de que os recursos são ilimitados.(ZHANG; CHENG; BOUTABA,2010)
Grid computing é um paradigma de computação distribuída, que permite coordenar recursos em redes, dividindo as altas taxas de processamento entre elas. CN, por também ser distribuída, torna-se muito similar ao modelo citado. Entretanto, a CN avança em direção à virtualização para realizar o compartilhamento e provisionamento de recursos. (ARMBRUST et al.,2010)
A virtualização é uma tecnologia que abstrai o hardware físico das máquinas, criando um ambiente virtual, maximizando os recursos de máquinas físicas que estariam, teoricamente, subutilizadas. Com ela é possível construir várias Virtual Machines (VMs) através de uma única máquina física. Com a virtualização é possível modificar todos os recursos físicos, sem que seja necessário modificar os recursos virtuais, mantendo as soluções.(SAHOO; MOHAPATRA; LATH,2010)
Baseando-se nessas três tecnologias e nos serviços web, a CN é entregue a vários clientes, utilizando ambientes virtualizados multi-tenancy. Nesses ambientes, vários clientes conseguem executar vários processos lógicos e compartilhar os mesmos recursos físicos segregados logica-mente. Essas características de virtualização dão origem aos ambientes multi-inquilinos de CN. Neles vários clientes conseguem criar suas VMs sem que uma influencie no funcionamento da outra, havendo isolamento lógico entre os processos de cada cliente. (ALI; KHAN; VASILAKOS, 2015)
Na literatura, existem algumas definições para o termo Computação em Nuvem. Em 2009, surgiu uma das primeiras e mais citadas.BUYYA et al.(2009) classifica CN como um tipo de sistema distribuído e paralelo, consistindo em um conjunto de computadores interligados e virtualizados. Eles são provisionados e apresentados como um ou mais recursos computacionais, baseados em Service Level Agreement (SLA) entre o provedor de serviços aos seus clientes de forma dinâmica.
Em 2011, o National Institute of Standards and Technology (NIST) em uma publicação especial (NIST Special Publication 800-145) nomeada de The NIST Definition of Cloud Com-puting , expõe de forma mais detalhada o conceito de Computação em Nuvem. NIST faz parte da Divisão de Segurança da Computação, que é o instituto do Departamento de Comércio dos Estados Unidos responsável pelo desenvolvimento de normas e orientações, incluindo requisitos mínimos, para fornecer segurança da informação.
Em MELL; GRANCE(2011), CN é definida como um modelo para permitir acesso ubíquo, ou seja, presente em todos os lugares, conveniente sob demanda de rede a um conjunto compartilhado de recursos de computação (redes, servidores, armazenamento, aplicações e serviços). Esses recursos podem ser configuráveis e rapidamente fornecidos e liberados com um mínimo de esforço para gerenciamento ou interação com o provedor de serviços.
É possível perceber, diante dos conceitos apresentados, que CN é uma abstração para re-presentar uma complexa infraestrutura composta de vários conceitos já utilizados na computação tradicional.
A principal vantagem até o momento deste tipo de computação é o modelo pay-as-you-go, ou seja, os usuários pagam apenas o que consomem de serviço, não havendo a necessidade de aquisição de uma infraestrutura complexa, cara e de difícil gerência. Com esse novo modelo, iniciam-se novas formas de Tecnologia da Informação (TI) voltadas para a nuvem, assim como novas oportunidades de mercado. (ARMBRUST et al.,2010)
CN utiliza computação distribuída em vez de computadores locais ou servidores remotos. O grande número de sistemas distribuídos e interligados proporciona sistemas com armazena-mento seguro e rápido. A Figura 2.1 é um diagrama lógico que representa todos os ecossistemas que podem estar incluídos no modelo de computação em nuvem. Em seu núcleo, fornece serviço por computação distribuída, sendo consumido por dispositivos heterogêneos e com diferentes capacidades de processamento. (DALAPATI; SAHOO,2013)
Figura 2.1: Diagrama de computação em nuvem
Fonte: (DALAPATI; SAHOO,2013)
2.1.2 Características Essenciais
As características essenciais destacam as vantagens e diferenciam as soluções que utili-zam CN em detrimento dos demais modelos de computação. As cinco características (Figura 2.2) elencadas para o modelo citado são: autosserviço sob demanda (On-demand self-service), acesso amplo à rede (Broad network access), conjunto de recursos (Resource pooling), elasticidade
rápida (Rapid elasticity) e serviço medido (Measured service). Além das cinco características essenciais definidas emMELL; GRANCE(2011), Cloud Security Alliance (CSA)1 adiciona multi-tenancy como sendo importante, porém não essencial. (ALI; KHAN; VASILAKOS,2015)
Figura 2.2: Características essenciais
Fonte: Elaborada pelo autor
O autosserviço sob demanda é uma das principais características de CN, pois os usuários podem adquirir recursos computacionais (processamento, rede, armazenamento etc.) sem interação humana e diante da demanda apresentada. A aquisição é unilateral, com a possibilidade de aumento ou diminuição da quantidade de recursos disponíveis, podendo esta ser para hardware ou software. As modificações ocorrem de maneira automática e sem burocracia. (MEHMOOD et al.,2015)
Para os clientes dos provedores de serviço há uma economia significativa com Capital Expenditure (CAPEX), evitando investimentos com equipamentos para a montagem de um ambiente semelhante ao contratado. Para os provedores de serviço, o autosserviço sob demanda gera economia com OPEX, ou seja, baixo custo operacional. A automatização dos serviços reflete na diminuição de custos com funcionários.
Acesso amplo à rede é a capacidade de disponibilizar recursos, via rede local ou internet, aos mais diversos tipos de dispositivos. Os clientes da nuvem podem ser dispositivos heterogê-neos dos tipos thin ou thick, ou seja, com muitos ou poucos recursos computacionais. A interface de comunicação entre a nuvem e os clientes utiliza um mecanismo padrão que suporta desde smartphones, tablets, laptops até workstations. (MELL; GRANCE,2011)
O conjunto de recursos, também denominado pool de recursos, é a capacidade do prove-dor de servir seus clientes com o modelo multi-tenant. Podem ser fornecidas diversas capacidades físicas e virtuais de recursos computacionais para os clientes, sendo personalizadas diante das demandas apresentadas pelos clientes, tais como: quantidade de memória, de armazenamento, de processamento e de largura de banda. (MEHMOOD et al.,2015)
Um traço marcante do pool de recursos em CN é que os usuários, na maioria das vezes, não possuem conhecimento da localização física dos recursos computacionais. Como a nuvem
é composta por vários sistemas distribuídos em rede, normalmente não é possível afirmar com exatidão em qual DC aquele recurso encontra-se alocado. A localização informada fica em uma abstração mais elevada, podendo ser um país, um estado ou um centro de dados. (ALI; KHAN; VASILAKOS,2015)
Uma das características mais relevantes de CN é a capacidade de alocar ou liberar a quantidade de recursos de forma dinâmica e sob demanda. Com a elasticidade rápida, torna-se viável escalar os recursos, inclusive de forma automática, torna-sem a interação humana. Há a possibilidade de se criar várias instâncias de um mesmo serviço, balanceando-os e tornando-os elásticos diante da demanda apresentada, dando a impressão para os usuários de que os recursos são ilimitados. (AHMAD et al.,2015)
Grandes provedores de serviço de CN como a Amazon2 realizam o provisionamento dinâmico através de requisitos de Quality of Service (QoS) do usuário, tornando as aplicações automaticamente elásticas e aumentando sua capacidade. Esta técnica é conhecida como scale-up ou scale-down quando os recursos são suprimidos. (GARG; BUYYA,2012)
O serviço de medição disponível nas nuvens auxilia no controle e otimiza a utilização dos recursos, sendo possível criar diferentes planos e modelos de tarifação, precificando diferentes usos de hardware. Por exemplo, sistemas que utilizam mais banda de rede ou mais disco são precificados de maneira diferente, considerando apenas o que foi consumido. (MEHMOOD et al.,2015)
2.1.3 Camadas
A CN possui uma arquitetura em camadas, nas quais são incluídas abstrações que dife-renciam os modelos de serviço e de implementação padronizados pelo NIST. Como se observa na Figura 2.3, a arquitetura se divide em quatro camadas, sendo elas: hardware, infraestrutura, plataforma e aplicação.
Na hardware acontece todo o gerenciamento dos recursos físicos da nuvem. Quando se fala em CN não é preciso se preocupar com esta camada, pois existem abstrações que gerenciam todos os recursos físicos do DC. Esta camada fica sob gerência exclusiva dos provedores. (ZHANG; CHENG; BOUTABA,2010)
Acima da camada física tem-se a infraestrutura, onde se inicia a virtualização dos dispositivos físicos, e por este motivo pode ser denominada camada de virtualização. Tecnologias de virtualização, como os hipervisores, são utilizadas para particionar um servidor físico em várias VMs. Além do servidor físico, o armazenamento pode ser virtualizado com a utilização de tecnologias de armazenamento em blocos. (DALAPATI; SAHOO,2013)
Com o DC todo virtualizado, tem-se um cenário preparado para a camada de plataforma, nela se inicia a CN, sendo incluídos os sistemas operacionais e as aplicações. SegundoZHANG; CHENG; BOUTABA(2010), a finalidade desta camada é minimizar a carga de implantação de
aplicativos diretamente nas VMs. Exemplos de aplicações que interagem com esta camada são: Microsoft Azure3, Google AppEngine4e Amazon SimpleDB/S35.
A última das quatro camadas é a de aplicação, onde são hospedadas as aplicações utilizadas nas nuvens. Essas aplicações, diferentemente das tradicionais podem utilizar todas as vantagens das características essenciais da CN. Exemplos desses tipos de aplicação são: Saleforce.com6, GMail7e Office3658. (MEHMOOD et al.,2015)
Figura 2.3: Arquitetura de computação em nuvem
Fonte: (ZHANG; CHENG; BOUTABA,2010)
2.1.4 Modelos de Serviços
SegundoMELL; GRANCE(2011), CN possui três modelos de serviço: Infrasctruture as a Service (IaaS); Platform as a Service (PaaS); e, Software as a Service (SaaS), que na literatura também podem ser chamados de modelo de negócios (Business Model) por outras referências e sites. Esses modelos estão diretamente ligados à arquitetura de computação empregada no modelo de negócio. Além dos padronizados pelo NIST, surgiram modelos emergentes (Figura 2.5). SRINIVASAN(2014) cita estes modelos como a evolução das modalidades de serviço (as a service) da CN. Eles auxiliam a identificar a fronteira de responsabilidades de uso entre os atores (provedores) e usuários envolvidos em CN.
3http://www.microsoft.com/Azure 4https://appengine.google.com/ 5https://aws.amazon.com/pt/s3 6https://www.salesforce.com 7https://www.google.com/gmail/ 8microsoft.office.com
2.1.4.1 IaaS
IaaS é o modelo de serviço arquitetural de CN em que o provedor de serviços dispo-nibiliza uma infraestrutura completa utilizando abstrações de hardware por meio de software e tudo que for indispensável para a inclusão de Sistema Operacional (SO) e aplicativos. IaaS relaciona-se ao gerenciamento de recursos, de infraestrutura de rede, virtualização e multi-tenancy, gerenciamento de dados, Application Programming Interface (API) e interoperabilidade. (MANVI; Krishna Shyam,2014)
Figura 2.4: Modelos de serviço
Fonte: http://www.thoughtsoncloud.com/2014/01/cloud-computing-defined-characteristics-service-levels/
A Figura 2.4 exibe a pilha de abstrações da arquitetura de IaaS. Nela pode-se observar que toda a infraestrutura física é gerenciada pelo provedor de serviços ou pela nuvem privada, entregando o ambiente virtualizado ao usuário. Os contratantes do serviço não precisam se preocupar com escalabilidade, licenças de software, backup, entre outros.
Os modelos de serviços podem ser classificados de acordo com a possibilidade de customização, os custos para implantação e o tempo de implantação, baseando-se nas camadas da arquitetura de CN. Diante desses aspectos, IaaS permite maior customização, mas apresenta maior custo e tempo de implantação caso o objetivo seja implementar todas as camadas da referida arquitetura. (HUSSEIN; KHALID,2016)
Amazon Web Services (AWS), GoGrid9e Rackspace10 são exemplos de provedores de serviços de IaaS. AWS possui um extenso catálogo de produtos para computação em nuvem, incluindo soluções para computação, armazenamento, redes, banco de dados, serviços móveis, entre outras. O Amazon Elastic Compute Cloud (EC2)11 da AWS é o serviço que realiza a
9https://www.datapipe.com/gogrid/ 10https://www.rackspace.com/ 11https://aws.amazon.com/pt/ec2/
hospedagem de VMs, disponibilizando um modelo de IaaS que precifica de maneira diferenciada os recursos computacionais locados, bem como permite ampla personalização de instâncias virtuais (memória, CPU etc.) e de sistemas operacionais para as VMs, oferecendo SLA com 99,95% de disponibilidade.
GoGrid permite a execução de múltiplas soluções sob demanda de CN. Com mais de uma década de atuação, possui mais de 15.000 clientes e mais de 600.000 VMs implantadas. Em 2015, foi adquirida pelo grupo Datapipe12, que está apostando em aquisições e parcerias, inclusive com a AWS, para expandir suas atividades.
Rackspace, assim como as citadas anteriormente tem ampla expertise em CN, presente em mais de 120 países, com mais de 300.000 clientes e 3.000 profissionais de computação em nuvem. Um dos seus diferenciais é trabalhar com plataformas da AWS, Microsoft Cloud Azure13 e OpenStack Cloud14.
2.1.4.2 PaaS
PaaS (Figura 2.4) fornece aos usuários um ambiente de desenvolvimento, fornecendo abstração para o desenvolvimento de recursos físicos com o gerenciamento da infraestrutura, sistema operacional e linguagem de programação. SegundoMEHMOOD et al.(2015), esta camada, utilizada pelas equipes de desenvolvimento de software, usa os serviços de computação em nuvem para o desenvolvimento de nova aplicação para os seus clientes, sendo considerada a camada de abstração mais complexa das três padronizadas pelo NIST.
PaaS fornece aos usuários um ambiente com menor possibilidade de customização, menor custo e tempo de implantação, comparando-se a IaaS. Como exemplos de provedores que fornecem esse tipo de serviço tem-se: Google App Engine, Force.com e Heroku15. Essas aplicações possuem como vantagens o desenvolvimento rápido, simples e de baixo custo, sem a necessidade de aquisição de hardware e software, com ambiente já instalado e pronto para iniciar as aplicações. (GONZÁLEZ-MARTÍNEZ et al.,2015)
2.1.4.3 SaaS
SaaS fornece aos usuários aplicações sob demanda pela Internet. As aplicações deste modelo podem ser acessadas facilmente por qualquer dispositivo, independente do seu recurso computacional, visto que quase todo o processamento encontra-se na nuvem.
Os usuários não gerenciam a infraestrutura ou características próprias do ambiente de desenvolvimento, tornando-o, desta forma, um modelo sem customização, com rápido e baixíssimo ou nenhum custo de implantação (Figura 2.4). Exemplos para este tipo de modelo
12https://www.datapipe.com/
13https://www.rackspace.com/microsoft 14https://www.rackspace.com/openstack 15https://www.heroku.com/
são: Salesforce.com, Google Docs16 e Dropbox17. (ALI; KHAN; VASILAKOS,2015)
Salesforce.com é uma empresa originária dos Estados Unidos, desenvolvedora de softwa-res sob demanda. O Salesforce.com, software com mesmo nome da empsoftwa-resa é uma Customer Relationship Management (CRM), ou seja, é um software de gestão de relacionamento com o cliente, ferramenta que automatiza as funções de contato com o cliente.
Google Docs é uma aplicação do Google, desenvolvida em AJAX, que contém editores de textos, planilhas, apresentações e formulários, funcionando diretamente no navegador web dos usuários. Dropbox é um serviço de armazenamento e compartilhamento de arquivos em nuvem. Os arquivos dos clientes ficam armazenados em servidores remotos e são acessados por uma aplicação cliente ou por interface web.
Além dos modelos citados, devido à evolução dos serviços de CN, surgiram opções emergentes, as quais são variações dos modelos existentes com a inclusão de serviços diferencia-dos.SHARMA(2015) apresenta 68 modelos emergentes para serviços de CN que podem ser explorados.
FIRDHOUS(2014) exibe taxonomia para o modelo de IaaS, criando uma árvore com vários níveis e relacionando estes modelos. Entre os exemplos destes modelos emergentes (Figura 2.5) tem-se: Confidentiality-as-a-Service (CaaS), Content Distribution-as-a-Service (Co-Daas), Database-as-a-Service (DBaaS/DaaS) e Education and learning-as-a-Service (ELaaS).
Figura 2.5: Modelos de serviços emergentes
Fonte: (SRINIVASAN,2014)
2.1.5 Modelos de Desenvolvimento
A última das três classificações de CN abordada pelo NIST é o Modelo de Desenvol-vimento, ou seja, como essas nuvens são implementadas. Basicamente possuem quatro tipos: privada, comunitária, pública e híbrida. Muitos documentos consideram apenas três modelos, ex-cluindo as nuvens comunitárias.DALAPATI; SAHOO(2013) eZHANG; CHENG; BOUTABA
16https://docs.google.com/ 17https://www.dropbox.com
(2010) são autores que consideram este tipo de tendência. Como o trabalho está pautado nos conceitos apresentados pelo NIST, a comunitária também será apresentada.
O modelo de desenvolvimento está diretamente relacionado ao acesso e à disponibilidade do ambiente de CN por parte dos seus clientes. A decisão do tipo a ser utilizado deve considerar os objetivos do negócio e da aplicação da nuvem. (MODARES; SALLEH,2012)
2.1.5.1 Privada
Nuvens privadas (Figura 2.6) são modelos desenvolvidos para uso exclusivo de uma única organização, sendo administradas localmente, podendo ser consideradas nuvens local ou de acesso remoto. Geralmente, este tipo de nuvem é utilizado por empresas que possuem muitas unidades de negócios. Uma nuvem privada necessita de um controlador de nuvens que atribua a ela estas características. (MELL; GRANCE,2011)
Figura 2.6: Modelos de desenvolvimento de nuvens
Fonte: Elaborada pelo autor 2.1.5.2 Comunitária
Nuvens comunitárias inicialmente possuem o mesmo objetivo das nuvens privadas, ou seja, atendem a um conjunto específico de usuários de uma instituição. A diferença é que as empresas com interesses em comum compartilham a mesma nuvem. O gerenciamento deste ambiente possui restrições de acesso, podendo ser administrado por uma ou mais instituições pertencentes exclusivamente a esta comunidade. (MODARES; SALLEH,2012)
Um exemplo de modelo de desenvolvimento de nuvem comunitária é o PlanetLab18, o qual é composto por pesquisadores em instituições acadêmicas e laboratórios industriais que compartilham recursos de processamento e armazenamento, permitindo desenvolver e testar aplicações e serviços em grande escala. (CHUN et al.,2003)
2.1.5.3 Pública
Ao contrário das nuvens privadas, as públicas (Figura 2.6) são implementadas para atender o máximo de usuários, ou seja, seu acesso é público. Nesse modelo não são aplicadas
políticas de restrição de acesso, técnicas de autenticação e de autorização. (MEHMOOD et al., 2015)
2.1.5.4 Híbrida
Nuvens híbridas são compostas por conjuntos de nuvens, podendo ser privadas, públicas ou comunitárias. A Figura 2.6 retrata uma nuvem híbrida composta por nuvens privada e pública. É possível perceber que apenas uma organização acessa diretamente os dados da privada. A empresa pode ser, ainda, acessada remotamente através de uma nuvem pública, mas, para isso, são necessárias políticas de autorização e autenticação para ingresso na nuvem privada da referida empresa.
A figura supracitada demonstra que todos podem acessar a nuvem pública, sendo possível utilizá-la, ainda, para o acesso a nuvens privadas. ZHANG; CHENG; BOUTABA (2010) classificam essa comunicação entre nuvens públicas para privadas como sendo uma Virtual Private Cloud (VPC), ou seja, uma nuvem virtual privada. A comunicação entre as nuvens seria realizada utilizando a tecnologia Virtual Private Network (VPN), a rede virtual privada. A VPC, por não estar padronizada pelo NIST, foi citada apenas a título de informação.
Figura 2.7: Paradigma de computação em nuvem: visão global
Fonte: Inspirada emBOTTA et al.(2016)
Na Figura 2.7 pode-se identificar a arquitetura de CN juntamente com suas características e modelos conceituais, resumindo em uma só imagem todos os conceitos discutidos até o momento. (BOTTA et al.,2016)
2.1.6 Controladores de Nuvem
Cloud Management Platforms (CMP) ou controladores de nuvens são frameworks usados para implantar e gerenciar instâncias de máquinas virtuais permitindo a configuração e adminis-tração de recursos de infraestrutura de nuvem, independente da camada de virtualização (Xen, KVM, VMWare ou Oracle VirtualBox) utilizada. Eles gerenciam tanto recursos locais, quanto nuvens públicas externas. (FREET et al.,2016)
Figura 2.8: Arquitetura dos controladores de nuvem
Fonte: (WIND,2011)
A Figura 2.8 exibe a arquitetura dos controladores de gerenciamento de nuvens, os quais fornecem uma interface segura para criação, controle e monitoramento de toda a plataforma, suportando os modelos de desenvolvimento padronizados (nuvens públicas, privadas, híbridas e comunitárias) e gerenciando os recursos físicos abstraídos por virtualização. (ALAM; PANDEY; RAUTARAY,2015)
Provedores de serviço em nuvem utilizam controladores de nuvem para abstrair recursos computacionais e entregá-los como serviços a seus clientes. Alguns dos principais provedores de serviços cloud são Amazon e Microsoft. Tanto o Amazon com o AWS (Amazon Web Services), quanto a Microsoft com Azure utilizam seus próprios controladores de nuvens para administrar seus serviços. (WEN et al.,2012)
Uma alternativa mais acessível financeiramente do que os provedores comerciais são os controladores de nuvem de código aberto, pois proveem maior flexibilidade para trabalhar com os mais diversos sistemas subjacentes ou hardwares legados, tornando possível utilizar os
recursos já existentes para a implantação de nuvens computacionais. (WIND,2011) OpenStack19, OpenNebula20 e Eucalyptus21são exemplos de controladores de nuvem de código aberto. 2.1.6.1 OpenStack
OpenStack é um controlador de nuvens distribuído sob a licença Apache, ou seja, possui código aberto. Foi desenvolvido originalmente pela NASA22 (National Aeronautics and Space Administration), agência do Governo Federal dos Estados Unidos, e a empresa americana RackSpace. A missão era produzir uma plataforma aberta, ubíqua, simples de implementar e escalável. No final de 2013, devido ao sucesso, mais de 200 empresas aderiram ao desenvolvimento, entre elas AT&T, IBM, Intel, Oracle e VMware. (CARLSEN,2014)
Desde 2010, o OpenStack encontra-se em desenvolvimento. Sua primeira versão, Austin, foi lançada em 21 de outubro. Os desenvolvedores tiveram como proposta liberar uma nova versão a cada seis meses, mantendo versões com suporte a correções de segurança, estáveis e projetos futuros. A Tabela 2.1 detalha todas as versões do OpenStack, o status da versão, o início e o fim do suporte. (KUMAR,2014)
Tabela 2.1: Versões do OpenStack
Versão Situação Suporte Inicial Suporte Final
Queens Futuro A ser definido A ser definido
Pike Futuro A ser definido A ser definido
Ocata Futuro A ser definido A ser definido
Newton Em desenvolvimento 06/10/2016 A ser definido
Mitaka Estável e suporte segurança 07/04/2016 10/04/2017
Liberty suporte segurança 15/10/2015 17/11/2016
Kilo EOL (Sem suporte) 30/04/2015 02/05/2016
Juno EOL (Sem suporte) 16/10/2014 07/12/2015
Icehouse EOL (Sem suporte) 17/04/2014 02/07/2015
Havana EOL (Sem suporte) 17/10/2013 30/09/2014
Grizzly EOL (Sem suporte) 04/04/2013 29/03/2014
Folsom EOL (Sem suporte) 27/09/2012 19/11/2013
Essex EOL (Sem suporte) 05/04/2012 06/05/2013
Diablo EOL (Sem suporte) 22/09/2011 06/05/2013
Cactus Obsoleta 15/04/2011
Bexar Obsoleta 03/02/2011
Austin Obsoleta 21/10/2010
Fonte: https://releases.openstack.org/
Pelo fato de possuir várias versões, vem sendo bastante difundido e utilizado tanto no meio acadêmico, quanto no ramo empresarial, pois ambos investem no desenvolvimento de recursos adicionais e na correção do código fonte. Possui vasta documentação, comunidade ativa, além de ser modular, permitindo customizações. Aceita a criação de nuvens públicas e
19https://www.openstack.org/ 20opennebula.org/
21http://www8.hp.com/br/pt/cloud/helion-eucalyptus-overview.html 22https://www.nasa.gov
privadas. Possui interface web onde o administrador pode gerenciar os recursos computacionais de processamento, armazenamento e redes do DC. (THOMÉ; HENTGES; GRIEBLER,2013)
Em sua página oficial23 há uma série de configurações modulares que podem ser imple-mentadas, como exemplos tem-se: hospedagem web, nuvem pública, comércio eletrônico, big data, DataBase as a Service (DBaaS) e processamento de vídeos.
Os módulos do OpenStack possuem codinomes, em que cada um representa uma co-munidade de desenvolvedores e um serviço a ser realizado por aquele módulo. Os módulos que compõem a Kilo (que será utilizada no ambiente de experimentação) são: Horizon, Nova, Neutron, Swift, Cinder, Keystone, Glance, Ceilometer, Heat, Trove e Sahara. A Tabela 2.2 apresenta todos os serviços, seu respectivo nome de projeto e a descrição da Kilo do OpenStack. (OpenStack Foundation,2016)
Tabela 2.2: Serviços e projetos do OpenStack Kilo.
Serviço Nome doProjeto Descrição
Interface Web Horizon Portal de auto-serviço baseado na web para interagir com os serviços OpenStack.
Computação Nova Gerencia o ciclo de vida das instâncias (VMs) de computação.
Rede Neutron Habilita Network Configuration as a Service (NCaaS) para os outros serviços do OpenStack.
Armazenamento
(Objeto) Swift Armazena e recupera objetos de dados não estruturados através de um RESTful
Armazenamento
(Blocos) Cinder Armazenamento em bloco persistente para instâncias em execução
Identidade Keystone Serviço de autenticação e autorização para os outros serviços do OpenStack
Imagem Glance Armazena e recupera imagens de disco de VMs.
Telemetria Ceilometer Monitores e medidores para faturamento, benchmarking, escalabilidade e fins estatísticos.
Orquestração Heat Orquestra múltiplas aplicações em nuvem.
Banco de Dados Trove Fornece serviço de banco de dados escalável para banco de dados relacionais e não-relacionais. Processamento
de Dados Sahara Fornece recursos para provisionar e escalar clusters Hadoop em OpenStack.
Fonte: (OpenStack Foundation,2016)
A customização da Kilo pode ser feita através dos módulos disponíveis para esta versão. Nem todas as versões do OpenStack possuem os mesmos módulos, visto que novos módulos foram desenvolvidos nas versões mais recentes, como, por exemplo, o Magnum24 (virtualização por container), disponível na Mitaka.
2.1.6.1.1 Arquitetura
A arquitetura básica de funcionamento do OpenStack Kilo é composta por três nós (three-node architecture), sendo eles: controlador, rede e computação. Opcionalmente, podem ser incluídos mais dois nós, sendo um para armazenamento em blocos e outro para serviço de armazenamento de objetos. (OpenStack Foundation,2016)
No controlador, para funcionamento mínimo (Figura 2.9) são executados os módulos de identidade (Keystone), imagem (Glance), gerenciamento de computação (Nova), gerenciamento
23https://www.openstack.org/software/sample-configs/
Figura 2.9: Arquitetura mínima do OpenStack Kilo
Fonte: (OpenStack Foundation,2015a)
de rede (Neutron) e interface web (Horizon). Além desses módulos, são necessários um banco de dados Structured Query Language (SQL), normalmente MySQL, um serviço de mensagens (RabbitMQ) e um serviço Network Time Protocol (NTP). Opcionalmente podem ser incluídos os módulos de orquestração, telemetria, banco de dados e processamento de dados. (WEN et al., 2012)
O nó de rede (Figura 2.9) executa vários agentes para prover a comutação de pacotes aos tenants (inquilinos) do módulo de computação, além do roteamento para redes externas, Network Address Translation (NAT)e Dynamic Host Configuration Protocol (DHCP). Este nó permite que as VMs possam acessar a Internet e serem acessadas externamente através de floating IP, ou seja, um Internet Protocol (IP) flutuante que torna a Virtual Machine (VM) acessível externamente ao ambiente de nuvem. Além das funcionalidades padrão do módulo, podem ser adicionadas novas, tais como Load Balancing as a Service (LBaaS) e FireWall as a Service (FWaaS).(Red Hat Enterprise Linux,2016)
Computação (Figura 2.9) é o nó responsável pela virtualização das máquinas virtuais ou instâncias virtuais, e onde se executa o hipervisor. Por padrão o hipervisor do OpenStack é o Kernel-based Virtual Machine (KVM), porém, se o hardware não for compatível, é possível executar o Quick Emulator (QEMU). Também pode ser executado, de forma opcional, agentes para coleta de dados do serviço de telemetria. (RADEZ,2015)
2.1.6.1.2 Neutron
permite customizações (de configurações, de tecnologias e de protocolos). Para o funcionamento da instalação padrão do OpenStack são indispensáveis três redes: gerenciamento, tunelamento ou tenant e externa. A Figura 2.9 exibe a divisão de redes na arquitetura de três nós (controlador, rede e computação). Outras versões do OpenStack permitem arquiteturas com menos nós, como, por exemplo, dois (controlador e computação) na Liberty. As funções do nó de rede desta versão foram incluídas no controlador. (OpenStack Foundation,2016)
O nó de rede acessa a Internet através da rede externa. Os outros dois nós também carecem desse tipo de conexão para tarefas administrativas, tais como: instalação de pacotes, atualizações de segurança, Domain Name System (DNS) e NTP. Por NAT, via rede de geren-ciamento, o acesso à Internet é compartilhado para os outros nós. Esta rede é responsável, ainda, pela comunicação entre os serviços distribuídos e suas interfaces de programação API. Tunelamento é a rede responsável pela comunicação entre as VMs criadas no Nova (módulo de computação). (SUBRAMANIAN; CHOWDHURY,2015)
Tabela 2.3: Revisão sobre conceitos genéricos de redes.
Conceito Revisão
Switch Um switch é um dispositivo que é utilizado para ligar os dispositivos numa rede. Eles encaminham pacotes utilizando comutação de pacotes, operam geralmente na camada 2 do modelo Open systems interconection (OSI). Exemplo de um switch virtual é o OpenVSwitch (OVS). (OPENSTACK,2016)
VLAN VLAN é uma tecnologia de rede que permite que um único switch aja como se fosse vários independentes. Dois hosts que estão conectados ao mesmo switch, mas em diferentes VLANs não visualizam o tráfego do outro. OpenStack é capaz de tirar proveito de VLANs para isolar o tráfego de diferentes inquilinos, mesmo que os inquilinos tenham instâncias em execução no mesmo host de computação. Cada VLAN tem uma identificação numérica associada, entre 1 e 4095. (OPENSTACK,2016)
DHCP Um servidor DHCP distribui endereços IP para hosts, que são os clientes DHCP da rede. Clientes DHCP localizam o servidor, enviando um pacote User Datagram Protocol (UDP) da porta 68, enquanto o servidor DHCP responde enviando um pacote UDP da porta 67. OpenStack usa um programa de terceiros chamado dnsmasq para implementar o servidor DHCP. (OPENSTACK,2016)
Roteador Um roteador é um dispositivo de rede que conecta várias redes entre si. Quando recebem pacotes de dados, usam uma tabela de roteamento para determinar quais redes devem passar a informação. (OPENSTACK,2016)
Balanceador de Carga
Um balanceador de carga é um dispositivo de rede que distribui rede ou aplicação de tráfego através de um número de servidores. (OPENSTACK,2016)
Flat Uma rede virtual implementada como pacotes em uma rede física específica que não contém nenhum cabeçalho IEEE 802.1Q (permite a criação de Virtual Local Area Network (VLAN) dentro de uma rede ethernet). Cada rede física pode realizar no máximo uma rede flat. OpenStack Foundation(2015a)
Neutron é composto por serviços de rede que gerenciam roteamento, DHCP, balan-ceamento de carga e metadados. Todos esses conceitos estão relacionados na arquitetura do
OpenStack ao nó de rede. Este dedica-se a realizar o roteamento (camada 3) para as instâncias virtuais, ainda sendo possível a utilização de múltiplos hosts físicos, permitindo redundância em caso de falha de hardware. (Red Hat Enterprise Linux,2016)
Tabela 2.4: Revisão sobre tecnologias de tunelamento.
Tunelamento Revisão
GRE Uma rede virtual implementada como pacotes de rede encapsulado usando Generic Routing Encapsulation (GRE). Redes GRE também são referidos como túneis. Túnel GRE são encaminhadas pela tabela de encaminhamento IP para o host, de modo que elas não são associados com redes físicas específicas. (OpenStack Foundation,2015b)
VXLAN
Virtual Extensible Local Area Network (VXLAN) é um protocolo de encapsulamento pro-posto para a execução de uma rede sobreposta na infra-estrutura de camada existente 3. Uma rede sobreposta é uma rede virtual que é construído em cima de tecnologias existentes camada de rede 2 e camada 3 para suportar arquiteturas de computação elástica. (OpenStack Foundation,2015b)
Para uma melhor compreensão do funcionamento de toda infraestrutura de rede do Neutron, torna-se imprescindível a revisão de alguns conceitos, protocolos e tecnologias que podem ser utilizadas no OpenStack. A Tabela 2.3 revisa alguns conceitos genéricos de redes de computadores. Na Tabela 2.4 são exibidas as tecnologias de tunelamento que podem ser utilizadas e a 2.5 discorre sobre a tradução de endereços.
Tabela 2.5: Revisão sobre tradução de endereços.
Tradução Revisão
NAT NAT é um processo realizado para modificação do endereço de origem ou destino no cabeçaçho de um pacote IP enquanto o pacote está em trânsito na rede. NAT é frequentemente implementada por roteadores, por isso também é conhecido por roteador NAT. OpenStack usa o pacote de software iptables para implementar a funcionalidade NAT. (OPENSTACK, 2016)
SNAT Em Source Network Address Translation (SNAT), o roteador NAT modifica o endereço IP do remetente em pacotes IP. SNAT é comumente usado para permitir que hosts com endereços privados possam se comunicar com servidores na Internet pública. OpenStack usa SNAT para habilitar aplicativos em execução dentro de instâncias para conectar para a Internet pública. (OPENSTACK,2016)
DNAT Em Destination Network Address Translation (DNAT), o roteador NAT modifica o endereço IP de destino em pacotes IP. OpenStack usa DNAT para rotear pacotes de instâncias para o serviço de metadados. (OPENSTACK,2016)
One-to-One Em one-to-one NAT ou NAT estático, o roteador NAT mantém um mapeamento entre ende-reços IP privados e endeende-reços IP públicos. OpenStack usa NAT one-to-one para implementar endereços IP flutuantes. (OPENSTACK,2016)
OpenVSwitch25, mais conhecido como OVS, é um switch virtual que fornece serviços para redes virtualizadas com suporte aos padrões NetFlow, OpenFlow e sFlow, sendo inclusive capaz de se integrar com os switches físicos. A versão Kilo do OpenStack, em sua documentação oficial, orienta a utilização de OVS, já em versões mais recentes este foi substituído por Linux Bridge.(Red Hat Enterprise Linux,2016)
Possíveis integrações com ambientes SDN necessitam da utilização de OVS (nativo na Kilo), versões do OpenStack como, por exemplo, a Liberty, não trabalham por padrão com switch virtual, sendo necessária essa alteração.(CALLEGATI et al.,2014)
A Figura 2.10 representa a arquitetura de serviços do Neutron nos três nós do OpenS-tack, exibindo a relação de plugins e agentes. Os plugins são responsáveis por gerenciar o funcionamento dos agentes, tanto que o Modular Layer 2 (ML2) está presente nos três nós, geren-ciando os agentes responsáveis pelo funcionamento dos serviços prestados.(SUBRAMANIAN; CHOWDHURY,2015)
Figura 2.10: Arquitetura de serviços do Neutron
Fonte: (OPENSTACK,2016)
O agente OVS faz a gestão entre os switches virtuais, realizando a conectividade entre eles e as portas virtuais com os componentes da rede, inclusive com dispositivos físicos. O agente DHCP faz a gestão do qdhcp, o qual fornece o serviço de distribuição de endereços IPs para as instâncias que utilizam redes, sendo gerido pelo agente L3 em qrouter, que fornece o roteamento entre as redes externas e internas. Ele também gere o tráfego de metadados entre instâncias e o agente de metadados, responsável pela manipulação de operações das instâncias. (OPENSTACK,2016)
O plugin ML2 é um framework que permite ao Neutron utilizar simultaneamente várias tecnologias de camada 2 (enlace de dados). Ele trabalha com vários agentes, entre eles OVS,
Linux Bridge e HyperV L2. Outra função do ML2 é simplificar e adicionar suporte para novas tecnologias de rede de camada 2, exigindo menos esforço do que adicionar um novo plugin no núcleo do sistema. (RADEZ,2015)
Em sua arquitetura (Figura 2.11), o plugin ML2 divide-se em tipo de driver e mecanismo de driver. Com essas opções torna-se possível incluir vários tipos de redes e infraestruturas, fazendo a comunicação com os módulos de redes do OpenStack.
Figura 2.11: Arquitetura do ML2
Fonte: (OPENSTACK,2016)
Como descrito na Figura 2.11, os tipos de drivers disponíveis são: VLAN, GRE, VXLAN e Flat. A documentação oficial de instalação recomenda o uso de GRE para a comunicação entre as redes internas, enquanto compartilha a rede externa, utilizando Flat. (Red Hat Enterprise Linux,2016)
Os mecanismos utilizados podem ser: OpenVSwitch, Hyper-V, OpenDaylight26, Arista e Cisco Nexus. Por padrão, utiliza-se OVS nas instalações. Caso seja necessário incluir o controla-dor SDN, as configurações devem ser alteradas para OpenDaylight, se este for o controlacontrola-dor, ou pode-se criar um mecanismo personalizado. Um exemplo desta personalização seria a inclusão de networking-onos27, permitindo com isso a integração do Neutron com o controlador ONOS28. (OpenStack Foundation,2016)
Como já citado, o módulo de redes do OpenStack permite múltiplas configurações e está apto a se comunicar com os mais diversos tipos de equipamentos, tornado o ambiente totalmente customizável. Além dos plugins e agentes citados, é possível adicionar serviços, sendo LBaaS e FWaaS os principais disponíveis.
O balanceador de carga pode distribuir as requisições através de três métodos, a saber: Round Robin, Source IP (IP de Origem) e Least connections (menos conexões). LBaaS possui um monitor que verifica a disponibilidade dos membros do balanceador, caso um ou mais membros não estejam respondendo, estes são desligados e incluídos automaticamente quando estiverem ativos. É possível gerenciar o limite de conexões e persistência das sessões, evitando, dessa forma, sobrecargas do balanceador ou ataques de negação de serviço. (Red Hat Enterprise
26https://www.opendaylight.org/ 27https://launchpad.net/networking-onos 28onosproject.org/