ANÁLISEDODESEMPENHODAVIRTUALIZAÇÃOLEVEPARA ... · In order to do so, comparisons of CPU, memory,...

ANLISE DO DESEMPENHO DA VIRTUALIZAO LEVE PARAAMBIENTES COM EDGE COMPUTING BASEADA EM NFV

Leon Valentim Porto Trindade

Dissertao de Mestrado apresentada aoPrograma de Ps-graduao em EngenhariaEltrica, COPPE, da Universidade Federal doRio de Janeiro, como parte dos requisitosnecessrios obteno do ttulo de Mestre emEngenharia Eltrica.

Orientador: Lus Henrique Maciel KosmalskiCosta

Rio de JaneiroFevereiro de 2018



DISSERTAO SUBMETIDA AO CORPO DOCENTE DO INSTITUTOALBERTO LUIZ COIMBRA DE PS-GRADUAO E PESQUISA DEENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DEJANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA AOBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIAELTRICA.

Examinada por:

Prof. Lus Henrique Maciel Kosmalski Costa, Dr.

Prof. Anelise Munaretto Fonseca, Dr.

Prof. Marcelo Gonalves Rubinstein, D.Sc.

Prof. Miguel Elias Mitre Campista, D.Sc.

RIO DE JANEIRO, RJ BRASILFEVEREIRO DE 2018

Trindade, Leon Valentim PortoAnlise do Desempenho da Virtualizao Leve

para Ambientes com Edge Computing baseada emNFV/Leon Valentim Porto Trindade. Rio de Janeiro:UFRJ/COPPE, 2018.

XV, 57 p.: il.; 29, 7cm.Orientador: Lus Henrique Maciel Kosmalski CostaDissertao (mestrado) UFRJ/COPPE/Programa de

Engenharia Eltrica, 2018.Referncias Bibliogrficas: p. 52 57.1. Desempenho. 2. Continer. 3. Edge Computing.

4. Virtualizao leve. I. Costa, Lus Henrique MacielKosmalski. II. Universidade Federal do Rio de Janeiro,COPPE, Programa de Engenharia Eltrica. III. Ttulo.

iii

minha famlia. Em especial minha me Mariolan e minha

av Aida (In memoriam).

iv

Agradecimentos

Agradeo a minha famlia, em especial a minha me Mariolan por todo carinho,apoio e motivao sempre.

Tambm gostaria de agradecer a Mayli por sempre estar ao meu lado e a suafamlia por terem me dado todo o apoio necessrio para a superar as dificuldadesque surgiram ao longo desse perodo de estudo.

Alm disso, agradeo aos amigos da Embratel em especial ao Jos Silva, Ant-nio Silvrio, Walderson Vidal e Carlos Cunha que me deram essa oportunidade paraautodesenvolvimento, tambm aos RTs do Centro de Referncia Tecnolgica da Em-bratel especialmente a Carolina Neves, Bruno Peres, Joaquim Carvalho, Luiza Her-back, Maurcio Silva, Zeneide Veras, Rodrigo Vieira, Marcelo Gomes, Laila Sousa,Mauro Gomes, Aldair Freire, Fbio Biggi, Josemar e Genlson Santos que me aju-daram e me motivaram ao longo dessa jornada.

Gostaria agradecer ao meu orientador Lus Henrique pela pacincia, apoio etodo conhecimento compartilhado a fim de me direcionar ao longo do mestradoajudando a elaborar e organizar as ideias e textos com dicas sempre valiosas queforam essenciais para meu o aprendizado e crescimento profissional.

Agradeo tambm aos professores Miguel Mitre, Anelise Munaretto e MarceloRubinstein pela participao na banca examinadora desta dissertao.

v

Resumo da Dissertao apresentada COPPE/UFRJ como parte dos requisitosnecessrios para a obteno do grau de Mestre em Cincias (M.Sc.)



Fevereiro/2018

Orientador: Lus Henrique Maciel Kosmalski Costa

Programa: Engenharia Eltrica

O paradigma de Network Function Virtualization (NFV) est mudando a formapela qual os servios de rede so providos, permitindo o mesmo grau de versatilidadee agilidade j visto na computao na nuvem. De fato, o NFV prope mudar asfunes de rede que hoje so executadas nas chamadas middleboxes, um hardwarededicado, em funes virtuais. Ou seja, transformar solues fechadas em simplesimagens de software, chamadas Virtual Network Functions (VNFs), as quais podemser consolidadas e executadas em servidores padres da indstria. Porm, poss-vel implementar as funes virtuais atravs da virtualizao tradicional baseada emhipervisores ou da virtualizao leve, constituindo um compromisso entre flexibili-dade e desempenho. Assim, este trabalho compara o desempenho em ambientes queutilizam tecnologia de virtualizao com hipervisor aos que utilizam contineres, afim de verificar a mais adequada para ambientes operacionais aliados ao conceitode Edge Computing baseada em NFV. Com isso, pretende-se aferir a capacidadedessas tecnologias serem transparentes ao usurio em relao ao desempenho. Paratanto, foram feitos benchmarkings de Central Processing Unit (CPU), memria,Input/Output (I/O) de disco, rede e aplicao, evidenciando a baixa sobrecarga davirtualizao leve que chega a se aproximar do cenrio nativo em certos casos.

vi

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of therequirements for the degree of Master of Science (M.Sc.)

LIGHTWEIGHT VIRTUALIZATION PERFORMANCE ANALYSIS FORNFV-BASED EDGE COMPUTING ENVIRONMENTS


February/2018

Advisor: Lus Henrique Maciel Kosmalski Costa

Department: Electrical Engineering

The Network Function Virtualization (NFV) paradigm is changing the way net-work services are provided, allowing the same degree of versatility and agility as everseen in cloud computing. In fact, NFV proposes to change the network functionsthat are currently performed in the so-called middleboxes, a dedicated hardware, invirtual functions. That is, turn closed solutions into simple software images, calledVirtual Network Function (VNF), which can be consolidated and run on industrystandard servers. However, it is possible to implement as virtual functions throughtraditional virtualization in hypervisors or in lightweight virtualization, constitutinga compromise between flexibility and performance. Thus, this work compares theperformance in environments that use virtualization technology with hypervisor tothose that uses a container, for the purpose of verify the best for operational envi-ronments allied to the concept of Edge Computing in NFV. However, it is intendedto gauge the ability for the technologies to be transparent to the user regardingperformance. In order to do so, comparisons of CPU, memory, disk I/O, networkand application were made, evidencing a low overhead of lightweight virtualizationthat comes close to the native scenario in certain cases.

vii

Sumrio

Lista de Figuras x

Lista de Tabelas xi

Lista de Abreviaturas xii

1 Introduo 1

2 Virtualizao 52.1 Virtualizao Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Paravirtualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Virtualizao assistida por hardware . . . . . . . . . . . . . . . . . . 102.4 Virtualizao Leve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Unikernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Virtualizao Hbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Contineres 173.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Control Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 LXC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.1 Arquitetura do Docker . . . . . . . . . . . . . . . . . . . . . . 22

4 Virtualizao de Funes de Rede 254.1 Objetivo do NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Diferenas para solues legadas . . . . . . . . . . . . . . . . . . . . . 264.3 Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Desempenho em NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Trabalhos Relacionados 30

6 Metodologia de Anlise 336.1 Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

viii

6.2 Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Memria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4 Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.5 Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Resultados Experimentais 407.1 Desempenho de CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2 Desempenho de Memria . . . . . . . . . . . . . . . . . . . . . . . . . 427.3 Desempenho de Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.4 Desempenho de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.5 Desempenho de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Concluso e Trabalhos Futuros 498.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Referncias Bibliogrficas 52

ix

Lista de Figuras

2.1 Diversos usurios utilizando os mesmo recursos de hardware. . . . . . 62.2 As diferentes arquiteturas de virtualizao, desde a tradicional at a

virtualizao leve. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Os diferentes tipos de acesso ao recurso de hardware. . . . . . . . . . 112.4 Diferentes projetos de sistemas operacionais. . . . . . . . . . . . . . . 14

3.1 Exemplo da imagem Docker de uma aplicao em Java. . . . . . . . . 233.2 O ecossistema do Docker. . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1 Cenrios para avaliao do desempenho de rede. . . . . . . . . . . . . 34

7.1 Desempenho de CPU: tempo de clculo do nmero com x algarismosutilizando o Y-cruncher. . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2 Desempenho de CPU: tempo de clculo de N nmeros primos at ovalor superior x utilizando o Sysbench. . . . . . . . . . . . . . . . . . 42

7.3 Desempenho de Memria: Vazo de operaes em memria utilizandodiferentes operaes com a ferramenta STREAM. . . . . . . . . . . . 43

7.4 Desempenho de Disco: Vazo de acesso ao disco para diferentes quan-tidades de arquivos criados utilizando o Bonnie++. . . . . . . . . . . 45

7.5 Desempenho de Disco: Taxa de buscas aleatrias em disco feitas comsucesso utilizando o Bonnie++ e 4 processos em paralelo. . . . . . . . 45

7.6 Desempenho de aplicao: Tempo de execuo para consultas emuma tabela MySQL com 1 milho de linhas utilizando o Sysbench. . . 47

x

Lista de Tabelas

6.1 Cenrios de anlise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.1 Tabela de operaes STREAM. . . . . . . . . . . . . . . . . . . . . . 427.2 Desempenho de rede: Vazo total utilizando o Iperf. . . . . . . . . . . 46

xi

Lista de Abreviaturas

AHCI Advanced Host Controller Interface

ALU Arithmetic and Logic Unit

API Application Programming Interface

AUFS AnotherUnionFS

CAPEX Capital Expenditure

CDN Content Delivery Networks

CFS Completely Fair Scheduler

cgroups Control Groups

COTS Commercial off-the-shelf

CoW Copy-on-Write

CPE Customer Premises Equipment

CPL Current Privilege Level

CPU Central Processing Unit

CRM Customer Relationship Management

CSAM Code Scanning and Analysis Manager

CR3 Control Register 3

CU Control Unit

DocLite Docker Container-bases technology Lightweight Benchmarking

DPDK Data Plane Development Kit

EPC Evolved Packet Core

xii

EPT Extended Page Table

ERP Enterprise Resource Planning

ETSI European Telecommunication Standards Institute

HD Hard Disk

HTTP Hypertext Transfer Protocol

IMS IP Multimedia Subsystem

IOPS Input Output per Second

IoT Internet of Things

IP Internet Protocol

IPC Interprocess Communication

ISP Internet Service Provider

ISV Independent Software Vendor

I/O Input/Output

KVM Kernel-based Virtual Machine

LXC Linux Containers

LRU Least Recently Used

MEC Mobile Edge Computing

NAT Network Address Translation

NF Network Function

NFV Network Function Virtualization

NFVI Network Function Virtulization Infrastructure

NIC Network Interface Card

NSC Network Service Chaining

OCI Open Container Initiative

OPEX Operational Expenditure

xiii

OTT Over the Top

PATM Patch Manager

PCI Peripheral Component Interconnect

PID Process Identifier

POSIX Portable Operating System Interface

QCI QoS Class Identifier

QEMU Quick Emulator

QoE Quality of Experience

QoS Quality of Service

RAM Random Access Memory

RAN Radio Access Network

REST Representational State Transfer

RTT Round Trip Time

SATA Serial ATA

SBC Single Board Computer

SD-WAN Software Defined-Wide Area Network

SLA Service Level Agreement

SR-IOv Single Root I/O Virtualization

SSD Solid-State Drive

TCP Transmission Control Protocol

TI Tecnologia da Informao

TLB Translation Look-aside Buffer

UDP User Datagram Protocol

UTS UNIX Time Sharing

vCPE Virtual Customer Premises Equipment

xiv

VDI Virtual Disk Image

VM Virtual Machine

VMM Virtual Machine Monitor

VMCS Virtual Machine Control Structure

VNF Virtual Network Function

VPS Virtual Private Server

xv

Captulo 1

Introduo

Os provedores de servios de telecomunicaes deparam-se constantemente com de-safios de mercado e assim buscam reduzir custos, sejam em termos de Capital Ex-penditure (CAPEX) e de Operational Expenditure (OPEX). Alm disso, buscamo aumento da agilidade de configurao dos servios e otimizao da utilizao derecursos. O NFV promete resolver esses desafios porque permite a diminuio doTime-to-Market de servios de rede nas operadoras, uma vez que o lanamento deservios pode ser feito com menores investimentos.

Alm disso, o NFV permite uma maior flexibilidade de configurao, migrao,automao e gerncia. Com isso, desde processos tcnicos at de governana podemser evoludos, agregando mais dinamismo e acelerando ciclos de inovao nas em-presas de tecnologia. O NFV promove uma mudana disruptiva na organizao dasempresas, uma vez que demanda planejamento tanto para reorganizar infraestruturatcnica e configurao lgica de rede quanto funes e departamentos pessoais queem alguns casos deixaro de existir.

Atualmente, a infraestrutura de redes das operadoras possui algumas caracte-rsticas bem definidas: ns topologicamente fixos, algumas funes de rede comredundncia dentro de black boxes, demora no lanamento de novos servios pelaoperadora, novos servios significam instalao de novos equipamentos e lgica decontrole em cada dispositivo com difcil evoluo. Sendo assim, caractersticas quecontrastam com a flexibilidade, portabilidade e resilincia propostas pela virtualiza-o.

A premissa do NFV evoluir a execuo de funes de rede em servidores dedi-cados para Virtual Network Functions (VNFs), executadas em servidores baseadosem arquitetura x86, de uso comercial. O conceito de execuo de funes de redeem software e em plataformas de computao genricas no novo, uma vez quefunes de rede baseadas em software esto disponveis h anos, como o QuaggaOpen Source Router [1] e o strongSwan IPsec Gateway [2] que so executados emcomputadores com arquitetura x86.

1

Quando um servidor compartilhado por diversos usurios, a sua utilizaoaumenta e o desempenho desejado por cada usurio dever ser o mesmo obtido comhardware dedicado. Uma das maiores vantagens das tecnologias de virtualizao nosdatacenters o melhor uso do hardware disponvel podendo inclusive compartilh-loem arquiteturas multi-inquilino, torna-se tambm uma das grandes desvantagens davirtualizao.

Com usurios simultneos, o desempenho pode ser comprometido quando o n-mero de utilizadores ou o nmero de tarefas demandadas torna-se elevado. Isso irafetar o sistema como um todo e resultar em um efeito cascata podendo resultar emuma resposta lenta e um desempenho ruim para todos os utilizadores. Para evitaresse cenrio as operadoras necessitam de uma excelente planejamento desses siste-mas para o seu uso sob alta demanda e assim poder obter um desempenho prximoaos de servidores dedicados.

Embora a virtualizao possua diversas vantagens e seja uma tecnologia pro-eminente da atualidade, ela tambm possui algumas desvantagens. No caso dedesempenho, o desempenho do sistema virtualizado geralmente menor que o dosistema ou rede sem virtualizao. Apesar das mquinas virtuais serem isoladas dohardware fsico, elas ainda esto conectadas a esse hardware no sentido que umafalha nesse hardware tambm reflete em uma falha na Virtual Machine (VM).

Quando a virtualizao investigada de perto, so observadas vantagens e des-vantagens. Ento, se faz necessrio o conhecimento e anlise do impacto da vir-tualizao atravs da medio de desempenho em cenrios com diversos tipos devirtualizao para compar-los a um referencial sem virtualizao e assim verificaro nvel de sobrecarga introduzido pelas diferentes tcnicas de virtualizao empre-gadas.

As operadoras de telecomunicaes demandam um desempenho previsvel nasVNFs para que elas sejam capazes de atender aos Service Level Agreements (SLAs),acordos sobre os nveis de servio contratados. A virtualizao permite a portabili-dade com a capacidade de migrar mquinas virtuais, ou seja, fornecendo a habilidadede mover uma mquina virtual em execuo de um servidor para outro.

Provedores de servios de telecomunicaes precisaro dessa live migration, oumigrao ao vivo, para entregar uma alta disponibilidade quando realizarem a ma-nuteno do sistema ou quando moverem uma VM para uma plataforma de com-putao com mais recursos. Alm disso, a portabilidade tem como consequnciaa habilidade de desenvolver uma VNF onde quer que ela seja necessria. Ento,consistncia na infraestrutura indispensvel para ajudar nesse desenvolvimento,garantindo o desempenho para o cliente.

Virtualizar as funes de rede, test-las e ento certific-las em vrias platafor-mas de infraestrutura um desafio importante para os fabricantes de equipamentos

2

de rede. Em muitos casos, eles oferecem plataformas de computao parceiras ouecossistemas a fim de fornecer uma oferta integrada. A oferta de uma soluo inte-grada faz com eles tenham que garantir que a VNF ir atuar como esperado, umavez que isso ser verificado em termos de interoperabilidade e desempenho. Almdisso, as operadoras de telecomunicaes necessitam de um desempenho previsveldas funes de rede virtuais para que elas sejam capazes de atender aos SLAs.

Ademais, o conceito de computao da borda modifica o paradigma de topologiacentralizada para descentralizada, pela utilizao de recursos de computao, redee armazenamento que esto mais prximos do usurio. Isso move o contedo e oservio para longe dos ns centrais, ou seja, dos datacenters ou da nuvem para as ex-tremidades lgicas da rede. Idealmente, seja a um nico salto de distncia do usurioou quanto mais perto estiver a aplicao e o contedo, melhor ser a qualidade deexperincia do usurio. A eliminao de um ambiente completamente centralizadofaz com que alguns gargalos e potenciais pontos de falha sejam removidos.

A edge computing busca a reduo do tempo de resposta ou latncia fazendocache ou descarregando o contedo nas pontas. As vantagens da utilizao desseconceito aliadas aos benefcios do NFV fazem com que novos servios possam serdesenvolvidos e consequentemente a avaliao da qualidade desses servios se tornanecessria. Essas avaliaes incluiro diferentes arquiteturas e seus requisitos es-pecficos para as diversas reas com potencial crescimento, como por exemplo aInternet das Coisas (Internet of Things (IoT)) com o conceito de Fog Computing,5G com o conceito de Mobile Edge Computing (MEC), Software Defined-Wide AreaNetwork (SD-WAN) com o roteamento baseado em polticas.

Com o surgimento da virtualizao leve, tem-se mais alternativas concorrendocom a virtualizao tradicional para implementao de servios na borda da rede dediversas reas de tecnologia. O continer um ambiente de execuo autocontidoque compartilha o mesmo kernel do sistema operacional hospedeiro e que isoladode outras instncias de contineres [3].

Ademais, os contineres prometem acabar com a sobrecarga proporcionada pelavirtualizao completa, a qual utiliza tcnicas como traduo binria para manipularos sistemas operacionais visitantes, alm de uma grande flexibilidade no gerencia-mento, migrao, atualizao e customizao das imagens de sistema.

Anlise de desempenho do plano de dados de NFV um aspecto crtico paraajudar os Internet Service Providers (ISPs) na transio para uma rede baseadaem virtualizao. Estruturas compartilhadas e ambientes multi-inquilino introdu-zem complexidades em cenrios que devem ser testados e necessitam de avaliaesmais completas devido a dependncia introduzida por componentes de software daNetwork Function Virtulization Infrastructure (NFVI) e isolamento da camada devirtualizao. Em ambientes compartilhados o desempenho da VNF no depende

3

somente da implementao dela e sim do conjunto de entidades que instanciam egerenciam todo seu ciclo de vida.

Visando atender s necessidades da computao na borda, a presente dissertaoanalisa o desempenho das camadas subjacentes de diferentes funes de rede emuma plataforma x86. Uma vez que essas funes podem utilizar diferentes tipos devirtualizao, um benchmarking foi realizado a fim de avaliar os possveis gargalosdestas solues e qual a mais apta para ser inserida na borda da rede garantindoum desempenho satisfatrio aos usurios. O benchmarking focado em cinco frentesconsideradas as mais relevantes, as quais so: I/O de disco, memria, rede, aplicaoe processamento.

Uma contribuio importante do presente trabalho relacionada ao preparo dasredes de telefonia mvel para o 5G. Uma vez que esta utilizar o conceito de EdgeComputing para permitir um novo QoS Class Identifier (QCI) nas redes mveisrelacionado ao valor mximo de latncia necessrio para determinada aplicao.Com a tendncia de virtualizao da Radio Access Network (RAN) para permitiruma maior flexibilidade do fronthaul das operadoras e prepar-las para funes comoNetwork Slicing, surge o questionamento de qual tecnologia de virtualizao utilizarna borda da rede e este trabalho tenta responder esta questo analisando tipos devirtualizao atuais para insero em um ambiente mais prximo do usurio.

Este trabalho aplicvel tambm a diversas reas emergentes como IoT com oconceito de Fog Computing para permitir redes que ofeream um contexto de usurioe assim gerando servios customizveis que fornecem, por exemplo, a localizao deusurio em tempo real servindo como base para aplicaes como carros autnomosou cirurgias remotas. Alm disso, o ganho para quem fornece os servios fazendo comque sua infraestrutura de rede seja otimizada atravs da possibilidade de haver umplanejamento de capacidade da rede diferente, j que o hot data ser descarregado naborda e somente o cold data ir para o core contribuindo inclusive para a engenhariade trfego de backbones de operadoras e diminuindo os gastos com infraestrutura.

A presente dissertao est organizada da seguinte forma. O Captulo 2 apresentaos principais conceitos e diferentes tipos de virtualizao. O Captulo 3 apresentao conceito de contineres e algumas solues que utilizam essa tecnologia. O Cap-tulo 4 explica o conceito de virtualizao de funes de rede, enquanto o Captulo 5apresenta os trabalhos relacionados e suas principais diferenas em relao a pre-sente dissertao. O Captulo 6 apresenta a metodologia utilizada na avaliao dedesempenho das ferramentas de implementao do NFV. J o Captulo 7 apresentaos resultados experimentais da anlise de desempenho. Por fim, o Captulo 8 concluio trabalho e aponta direes de pesquisa futuras.

4

Captulo 2

Virtualizao

Na dcada de 1940, os primeiros sistemas com eletrnica digital no possuam siste-mas operacionais. Os computadores dessa poca eram totalmente primitivos com-parados aos de hoje e os programas eram frequentemente executados no computadorbit a bit nas linhas dos concentradores mecnicos. J na dcada de 50, os sistemasexecutavam uma tarefa por vez, o que permitia somente uma pessoa utilizar a m-quina, ou seja, todos os recursos computacionais estavam disponveis a um nicousurio.

O primeiro grande sistema, considerado por muitos o primeiro sistema operaci-onal, foi desenhado pelo laboratrio de pesquisa da General Motors para seu main-frame IBM 701 no comeo de 1956. Os sistemas operacionais so o software que faz ohardware tornar-se utilizvel. O hardware fornece o poder computacional bruto. Osistema operacional faz com que esse poder computacional esteja convenientementedisponvel para os usurios, atravs do gerenciamento do hardware cuidadosamentea fim de obter um bom desempenho.

Os sistemas operacionais tambm podem ser considerados como gerenciadoresde recursos. Um sistema operacional determina quais recursos computacionais se-ro utilizados para resolver determinado problema e a ordem na qual eles seroutilizados. Em geral, os sistema operacionais possuem trs funes bsicas. A pri-meira a alocao e atribuio de recursos computacionais como dispositivos deI/O, software, unidades de processamento central, etc. A segunda funo bsica escalonamento de tarefas coordenando recursos e tarefas seguindo uma prioridadedeterminada. A terceira a monitorao das tarefas do sistema mantendo o hist-rico de operaes, notificando os usurios ou operadores conforme alguma condiode erro encontrada.

A virtualizao surgiu em 1960 a partir da IBM, que tinha como objetivo parti-cionar os grandes mainframes da poca em instncias lgicas que seriam executadasem um nico hardware de um determinado mainframe hospedeiro. Essa necessidadeda IBM surgiu da incapacidade dos mainframes de aproveitar seu caro tempo de

5

clculo, ou seja, somente um usurio poderia utiliz-lo por vez. Com isso, a vir-tualizao veio juntamente com o conceito de time sharing (compartilhamento detempo), no qual mltiplos usurios utilizavam o mesmo hardware para aumentar aeficincia do trabalho conforme visto na Figura 2.1.

Figura 2.1: Diversos usurios utilizando os mesmo recursos de hardware.

No final da dcada de 70 os primeiros chips foram lanados pela Intel e na dcadaseguinte os microprocessadores foram responsveis pela mudana no foco de algumasempresas e assim deram o primeiro passo para a popularizao do microcomputa-dor e da arquitetura x86 que utilizada at hoje nos computadores pessoais e nosdatacenters, obviamente com muita evoluo ao longo dos anos. O termo x86 serefere a um conjunto de instrues de linguagens para a mquina presente em certosprocessadores da Intel e de algumas outras companhias. Ele define essencialmenteas regras de uso e vocabulrio para o chip.

Um datacenter um espao fsico responsvel por uma modalidade de serviode valor agregado que oferece recursos de processamento e armazenamento de dadosem larga escala para que organizaes de qualquer porte e at mesmo profissionaisliberais possam ter ao seu alcance uma estrutura de grande capacidade, flexibilidade,alta segurana e igualmente capacitada do ponto de vista de hardware e softwarepara processar e armazenar informaes.

Solues de virtualizao multiplicam o acesso ao hardware do computador per-mitindo que diferentes fatias virtuais sejam executadas sobre ele. Em um ambientede datacenter legado, sem virtualizao, um simples computador poderia somenteexecutar um nico sistema operacional por um certo tempo. Esse sistema seriaresponsvel por controlar todos os dispositivos de hardware do computador, comoCPU, memria, controladores de disco, disco rgido, placas de vdeo, placas de rede,e outros dispositivos perifricos. Com a virtualizao, mltiplos usurios tm a ilu-so do controle total sobre o hardware cada um em sua fatia virtual, ou seja, emseu prprio espao isolado de maneira lgica.

Essa abordagem ainda empregada em muitos datacenters, quando somente

6

um servio oferecido por uma dada mquina, geralmente para obter um nvelelevado de desempenho. Contudo, tanto espao fsico no armrio quanto consumo deenergia, escalabilidade e atualizaes de hardware so alguns pontos que necessitamde ateno. A virtualizao pode resolver esses desafios permitindo que diferentessistemas operacionais compartilhem o mesmo hardware e ento consolidando fatiasvirtuais em uma nica mquina fsica. Sendo assim, cada fatia virtual possui umaquantidade dedicada de recursos do servidor fsico.

A virtualizao pea fundamental para a computao na nuvem e o NFV. Osseus principais benefcios incluem independncia de hardware, isolamento, ambientesde usurio seguros e aumento da escalabilidade. Recentemente, observou-se umaumento no nmero de solues e de tecnologias de virtualizao fazendo com queas chamadas solues tradicionais baseadas em hipervisores hoje concorram com avirtualizao leve baseada em contineres que, em tese, possui menor sobrecargacomputacional. Alm disso, houve a introduo de novas tcnicas hbridas queprometem combinar as vantagens das anteriores. As sees seguintes fazem umabreve reviso destes conceitos.

2.1 Virtualizao Tradicional

Uma soluo de virtualizao tradicional, tambm conhecida como virtualizaocompleta, emprega uma camada de software chamada de hipervisor, que se situaentre o hardware e as mquinas virtuais. O hipervisor controla o acesso ao hardwaree realiza a alocao de recursos para cada VM, alm de fornecer isolamento entreelas. Com isso, as VMs utilizam diferentes sistemas operacionais e hospedam suasprprias aplicaes. Em geral, possvel dizer que cada VM possui seu prprioambiente computacional virtualizado, isto , seu prprio sistema operacional e sendoassim sua prpria abstrao de hardware.

H hipervisores conhecidos como do tipo I, os quais so executados diretamenteno hardware ou usualmente chamado de bare-metal. Esse tipo de hipervisor uti-liza uma virtualizao completa baseada em hardware, como pode ser visto ver naFigura 2.2(a), implementando uma modificao de um sistema operacional e assimtornando desnecessrio um sistema operacional hospedeiro intermedirio, uma vezque a prpria soluo quem hospeda os diversos sistemas operacionais visitantes.

Essa modificao de sistema operacional geralmente um kernel desenvolvidopor empresas seguindo o modelo de sistema operacional Portable Operating SystemInterface (POSIX) para fornecer funcionalidades similares que podem ser encontra-das em outros sistemas operacionais, como criao e controle de processos, sistemasde arquivos e threads. Um exemplo o vmkernel desenvolvido pela VMWare paraseu hipervisor VMWare ESXi que atua como um sistema operacional executado

7

diretamente no hardware e gerencia recursos como memria, processadores fsicos,armazenamento e controladores de rede.

Por outro lado, h hipervisores do tipo II, que utilizam uma virtualizao com-pleta baseada em software, como ilustrado na Figura 2.2(b), sendo executadossobre um sistema operacional hospedeiro. este sistema operacional hospedeiroque executado diretamente sobre o hardware gerando mais uma camada de sobre-carga ao sistema.

Apesar de adicionar mais uma camada de abstrao no hardware o que acarretaem uma perda de desempenho, os hipervisores do tipo II possuem a vantagem desuportar uma vasta gama de hardware hospedeiro. Isso se deve ao fato de que o sistema operacional hospedeiro que trata o gerenciamento do hardware. Almdisso, os hipervisores do tipo II geralmente so bem mais fceis de instalar que oshipervisores do tipo I.

Um conceito importante o de modelo de proteo, uma vez que CPUs modernosutilizam um esquema de proteo de recursos onde vrios anis de proteo socriados e cada um deles representa um nvel diferente de confiana na execuo detarefas. A arquitetura x86 oferece 4 anis, numerados de 0 a 3 e quanto menor onmero do anel, maior a representao do nvel de confiana no cdigo. Muitasvezes os nmeros do anis so referenciados pelo seu Current Privilege Level (CPL).A parte do sistema operacional, a qual necessita da maioria de privilgios executano anel 0, os drivers dos dispositivos executam no anel 1 ou acima e as aplicaesno anel 3, conforme observado na Figura 2.3(d).

Alm disso, algumas instrues como as I/Os do sistema necessitam de privilgioselevados. Quando uma aplicao do usurio necessita executar essas instrues, umafuno do sistema operacional chamada, a qual realiza a execuo do cdigo nokernel do sistema operacional, localizado no anel 0. Uma vez que essa funo terminasua execuo, esta retorna o resultado obtido e a execuo do cdigo da aplicaocontinua, com os privilgios anteriores de menor valor. Tal tcnica conhecida comotrap and emulate, j a camada de menor privilgio, onde as aplicaes so executadas o espao do usurio e a camada com o maior privilgio conhecida como espaodo kernel.

Algumas outras tcnicas como binary translation, direct execution e binary pat-ching so frequentemente utilizadas nas solues de virtualizao. Na binary transla-tion as instrues sensveis no cdigo do sistema operacional visitante so substitu-das tanto por hypercalls, as quais manipulam de forma segura as instrues quantopor opcodes (cdigos de operao) indefinidos que resultam em uma trap do CPUe esta, por sua vez, manipulada pelo hipervisor.

Ademais, a tcnica direct execution faz com que somente o cdigo do kernel sejatraduzido, evitando assim a sobrecarga advinda da traduo de partes desnecessrias

8

da aplicao pela tcnica binary translation. J a tcnica de binary patching similara binary translation, exceto pelo fato de ser mais leve uma vez que o cdigo alteradoao invs de ser traduzido o que gera uma alterao na memria do sistema visitante.

(a) Virtualizao baseada em Hardware. (b) Virtualizao baseada em Software.

(c) Virtualizao hbrida. (d) Paravirtualizao.

(e) Virtualizao leve.

Figura 2.2: As diferentes arquiteturas de virtualizao, desde a tradicional at avirtualizao leve.

2.2 Paravirtualizao

A paravirtualizao foi feita para superar as restries da arquitetura de processa-dores baseada em modo de proteo. Para melhorar a comunicao entre o sistemaoperacional do visitante e o hipervisor, a proposta de paravirtualizao modificao kernel (ncleo) do sistema operacional visitante substituindo as instrues no-virtualizveis por hypercalls que se comunicam diretamente com uma camada devirtualizao no hipervisor, como ilustrado na Figura 2.2(d). O hipervisor tambmfornece interfaces de hypercalls para outras operaes crticas do ncleo do sistema

9

operacional como gerenciamento de memria, manipulao de interrupes e manu-teno de tempo.

A paravirtualizao diferencia-se da virtualizao tradicional, onde o sistemaoperacional visitante sem modificaes no sabe que virtualizado e as chamadassensveis do sistema operacional so tratadas utilizando a tcnica de traduo binria(binary translation). Uma vantagem da paravirtualizao a diminuio dos gar-galos decorrentes da virtualizao completa, entretanto a diferena de desempenhoentre ambas pode variar de acordo com a carga aplicada. Como a paravirtualizaono suporta sistemas operacionais sem modificao, sua compatibilidade e portabi-lidade fraca. A ferramenta mais conhecida desse tipo de virtualizao o Xen [4].

O Xen um hipervisor open source desenvolvido para executar em servidoresCommercial off-the-shelf (COTS). O Xen permite executar mltiplas VMs simul-taneamente em uma nica mquina fsica. Alm disso, ele implementa a tcnica deparavirtualizao que melhora o desempenho do sistema visitante atravs da trocado seu comportamento a fim de acionar o hipervisor quando necessrio, evitando anecessidade da traduo binria das instrues do sistema. A arquitetura do Xen composta por um hipervisor localizado acima do hardware fsico e mquinas virtuaissobre o hipervisor.

Cada mquina virtual possui seu prprio sistema operacional e aplicaes quandoexecutadas no Xen. O hipervisor controla o acesso ao hardware e tambm gerenciaos recursos compartilhados disponveis para as mquinas virtuais. Adicionalmente,os drivers do dispostivo so colocados em uma mquina virtual isolada, chamadaDomain 0 (dom0), a fim de fornecer confiabilidade e eficincia ao hardware.Devidoao dom0 possuir acesso total ao hardware fsico, ele possui privilgios especiais com-parado a outras mquinas virtuais, referenciadas como user domains(domUs). Poroutro lado, os user domains possui drivers virtuais, chamados de front-end dri-vers(fe), os quais se comunicam com os back-end drivers(be) localizados no dom0para acesso o hardware fsico.

2.3 Virtualizao assistida por hardware

A virtualizao assistida por hardware foi criada para superar as restries da pa-ravirtualizao e da virtualizao completa atravs da criao de um mecanismo decontrole robusto no CPU. Este dispensa o uso de tcnicas como ring compressionque retira privilgios do sistema operacional visitante colocando-o para executar noanel 1 e tambm dispensa a modificao de cdigo no sistema operacional visitante.

A tecnologia de virtualizao assistida por hardware foi desenvolvida para pos-sibilitar alto desempenho do hipervisor sem necessitar de mudanas decorrentes daparavirtualizao ou de tcnicas como traduo binria. Com isso, possibilita uma

10

implementao de hipervisor que pode suportar uma vasta gama de sistemas ope-racionais visitantes sem modificao.

Para um hipervisor usufruir das vantagens de tecnologias como a Intel VT-x, ele executado em um novo modo de CPU chamado de VMX Root e o sistema operacionalvisitante executado no modo VMX Non-root. Assim, o Virtual Machine Monitor(VMM) gerencia as VMs atravs de um mecanismo de entrada e sada, conformemostra a Figura 2.3(d).

A tecnologia Intel VT-x inclui duas formas de operao para que o hipervisorpossa ter um controle granular sobre o comportamento da CPU, essa instruo doponto de vista do processador o estado VMX-root que significa a possibilidadede execuo de qualquer instruo no processador sem nenhuma restrio, inclusivesomente neste contexto se pode alterar o estado do sistema.

(a) Sem virtualizao. (b) Virtualizao completa.

(c) Paravirtualizao. (d) Virtualizao assistida por hardware.

Figura 2.3: Os diferentes tipos de acesso ao recurso de hardware.

Adicionalmente, quando o estado de execuo VMX-non root significa queo processador est configurado para entender que a execuo neste contexto de

11

uma mquina virtualizada. Com isso, algumas instrues, as mais privilegiadas, sodesabilitadas e os ponteiros do processador deste contexto sero armazenados emcache dentro do prprio processador a fim de acelerar o compartilhamento do tempode processamento de outras mquinas virtuais, j que a gravao e recuperao nocache do processador so muito mais velozes do que se fosse na memria principal.

A operao do estado VMX non-root e as transies entre os estados so con-troladas pela estrutura de dados conhecida como Virtual Machine Control Struc-ture (VMCS). O acesso ao VMCS controlado atravs de um componente doprocessador chamado VMCS pointer e existe um para cada processador lgico. OVMCS gerencia os modos de operao anteriormente citados e contm campos paralidar com os estados das transies, para informar quais so as excees permitidasou proibidas, para informar a motivo das transies e flags para alterar o compor-tamento das transies.

2.4 Virtualizao Leve

A virtualizao leve, tambm chamada de virtualizao baseada em contineres oude virtualizao a nvel de sistema operacional, fornece um nvel diferente de abs-trao em termos de virtualizao e isolamento quando comparada aos hipervisores.Conforme mencionado anteriormente, os hipervisores fornecem uma abstrao dehardware que resulta em uma sobrecarga em termos da prpria virtualizao dohardware e dos drivers virtuais do dispositivo. Isso significa que cada instncia deVM totalmente implementada com hardware virtual para suportar um sistemaoperacional visitante no modificado, executado sobre o hipervisor.

Diferente da virtualizao completa, na virtualizao leve fornecido um isola-mento de processos no nvel do sistema operacional evitando sobrecarga da camadade abstrao do hardware virtual para cada VM instanciada, como pode ser vistona Figura 2.2(e). Com isso, as imagens so executadas sobre o mesmo kernel do sis-tema operacional compartilhado no servidor fsico, sendo que um ou mais processospodem executar dentro de cada imagem.

Sendo assim, a virtualizao leve considerada mais leve e com melhor desem-penho que a virtualizao tradicional. Apesar de fornecer menor capacidade deisolamento que a virtualizao completa ou a paravirtualizao, ela consideradacom um nvel de isolamento suficiente para cenrios de gerncia de recursos em IoTdevido a sua capacidade de ser executada em ambiente com baixo recursos compu-tacionais [5].

Uma desvantagem da tcnica de implementao da virtualizao leve ao utilizaro mesmo kernel quando comparada as VMs relacionada a questes de segurana.Diferente da virtualizao tradicional, a virtualizao leve expe as tabelas de cha-

12

mada do sistema do hospedeiro para cada visitante e confia em ponteiros para re-direcionar essas chamadas de sistemas para estruturas de dados isoladas, chamadasnamespaces. Com isso, aberta a possibilidade de explorar vulnerabilidades desseponteiro a fim de obter informaes sigilosas ou obter um privilgio maior.

Outra desvantagem na utilizao do mesmo kernel que uma determinada vul-nerabilidade no kernel hospedeiro compartilhada com todas as instncias, sendoassim possuem o mesmos problemas de sistemas monolticos que foram escritos comlinguagens inseguras, as quais fizeram os usurio optarem por VM para um isola-mento seguro mesmo considerando o compromisso entre desempenho e segurana.

2.4.1 Unikernel

Um sistema operacional pode ser decomposto em dois espaos de endereamento:o espao do kernel e o espao do usurio. O espao do kernel contm as funesutilizadas pelo sistema operacional e bibliotecas compartilhadas incluindo funesde baixo nvel como I/O de disco, acesso ao sistema de arquivos, gerenciamentode memria, bibliotecas compartilhadas, etc. Ele tambm fornece um isolamentode processos, catlogo de processos e outras funes necessrias para sistemas ope-racionais multiusurio. O espao do usurio, por outro lado, contm o cdigo daaplicao como visto na Figura 2.4(a).

Ao utilizar Unikernel, no h diviso entre o espao do usurio e o espao dokernel, como pode ser visto na Figura 2.4(b). Apesar disso parecer uma pequena di-ferena, de fato o oposto, uma vez que a pilha de protocolos do sistema operacional uma combinao do kernel, bibliotecas compartilhadas e uma aplicao para obterseu objetivo final. S existe um programa sendo executado, e ele contm desde ocdigo em alto nvel da aplicao at as rotinas em baixo nvel de I/O do dispositivo,sendo uma imagem singular e autocontida que no requer nada adicional para queseja inicializada.

O Unikernel pode ser considerado um tipo de virtualizao leve, porm imple-mentado de uma maneira diferente da viso compartilhada no mesmo sistema ope-racional anteriormente citada. Sendo assim, um sistema operacional que utilizaum conceito verdadeiramente minimalista para criao da pilha de software, ou seja,preocupa-se somente com as necessidades especficas para cada aplicao. No designdo sistema operacional, as bibliotecas utilizadas para constru-lo so as estritamentenecessrias para funcionamento da aplicao, com isso tornando-o mais leve do queas tradicionais VMs.

O Unikernel conhecido como sistema operacional de bibliotecas, no umaideia nova, porm no era amplamente implementado devido incapacidade detratar com inmeros hardwares diferentes. Entretanto, com a popularizao dos

13

(a) Sistema operacional tradicional.

(b) Sistema operacional com Unikernel.

Figura 2.4: Diferentes projetos de sistemas operacionais.

hipervisores, essa preocupao de lidar diretamente com o hardware foi superadatornando possvel um sistema operacional com essas caractersticas ser executadoem um ambiente de nuvem.

Uma das vantagens do Unikernel em relao a outras ferramentas que elemelhora a segurana por ser um sistema operacional muito pequeno e especfico aponto de carecer de ferramentas internas adicionais para serem utilizadas a fim deajudar em uma possvel invaso. Ademais, seu desempenho elevado devido a sualeveza, a inexistncia de processos mltiplos com necessidade de gerenciamento ea excluso de mudanas de contextos de usurio na sua implementao, entretantoessa ferramenta no foi utilizada no presente trabalho.

14

2.5 Virtualizao Hbrida

Alm dos casos relatados anteriormente, existe a virtualizao hbrida que misturaos tipos de virtualizao anteriores, sendo ilustrada na Figura 2.2(c). A virtua-lizao hbrida no limitada a um tipo de virtualizao especfica e sim umaprtica na qual mistura-se mais de um tipo de virtualizao para possivelmentemelhorar algum aspecto especfico, como por exemplo segurana. Um exemplo oClearContainers [6] da Intel agora integrado ao KataContainers [7] da comunidadeOpenstack que mistura virtualizao leve, paravirtualizao e virtualizao assistidapor hardware para melhorar o desempenho e a segurana.

O Clearcontainers um projeto que nasceu em 2015 para lidar com uma fa-lha de segurana chamada DirtCow dentro dos contineres que explorava a tcnicaCopy-on-Write (CoW) para obter privilgios indevidos no sistema. A soluo foicriada atravs da utilizao da tecnologia Intel VT-x que um tipo de virtualizaoassistida por hardware explicada anteriormente a fim de fornecer mais seguranaao ambiente executando os contineres como se fossem mquinas virtuais leves ecompatveis com ferramentas de orquestrao j existentes como Kubernetes [8].

No final de 2017, o projeto ClearContainers foi incorporado ao KataContainersque acrescentou um ambiente de execuo chamada runV [9], o qual compatvelcom as normas da Open Container Initiative (OCI) fazendo com que os continerespossam ser executados em diferentes plataformas e possuam um sistema operacionalleve e um kernel dedicado.

Adicionalmente a iniciativas de execuo de contineres juntamente com virtua-lizao assistida por hardware, h tambm outras frentes de trabalho mais antigascomo a do projeto Xenserver [10], o qual utiliza a paravirtualizao, que adaptamsua soluo para utilizar a virtualizao assistida por hardware que j est presenteem grande parte dos hardwares atuais, contineres e Unikernel como no projetoMirageOS [11] e no plugin xscontainer [12].

Uma outra iniciativa famosa que pode utilizar mais de um tipo de virtualizao o Kernel-based Virtual Machine (KVM) [13] que baseado na ferramenta QuickEmulator (QEMU) [14], uma vez que nele os dispositivos podem ser paravirtualiza-dos atravs da Application Programming Interface (API) Virtio [15] que fornece umacamada de abstrao evitando que os dispositivos sejam emulados, o que acarretaem uma sobrecarga maior.

O QEMU um emulador open source que pode emular desde dispositivos ataplicaes. Ele executado no Linux, Windows e OS X e possibilita que sistemashospedeiros executem programas escritos para arquiteturas diferentes. Entretanto,h sobrecarga em relao a desempenho devido ao uso da tcnica dynamic binarytranslation mencionada anteriormente.

15

O hipervisor KVM uma extenso do kernel do Linux e trabalha expondo umaAPI, a qual pode ser utilizada para interagir com o kernel e com o hardware. EssaAPI, por sua vez, ento utilizada por um client tal como o QEMU. Isso permitea uma instncia de software hospedada no QEMU ser executada mais rpido, umavez que a virtualizao assistida por hardware um requisito.

Recentemente uma outra estratgia adotada foi a mistura da virtualizao leveutilizando contineres com a virtualizao assistida por hardware e com o projetoUnikernel para fornecer a ferramenta Docker nas plataformas Windows e Mac evi-denciando a importncia da virtualizao hbrida nos dias atuais.

16

Captulo 3

Contineres

Apesar de o termo ter se tornado conhecido nos ltimos anos, durante dcadas j seutilizava o conceito de contineres em sistemas Unix, atravs do comando chroot queera apenas uma forma de isolar o sistema de arquivos (filesystem). Em computao,um filesystem um mtodo para guardar e organizar arquivos e dados contidos paratornar fceis a procura e o acesso. Um sistema de arquivos utilizado sobre umdispositivo de armazenamento de dados como um disco rgido a fim de preservar alocalizao fsica dos arquivos.

Em seguida, vieram os jails do sistema operacional FreeBSD que, alm do iso-lamento do sistema de arquivos, permitiam tambm o isolamento de processos. Ochroot era limitado e ao longo do anos foram descobertas formas de burlar sua segu-rana, com isso os jails vieram para melhorar a segurana e expandir o isolamentopara um conjunto determinado de usurios e subsistemas de rede.

J a Sun Microsystems desenvolveu o Solaris Zones, mais uma soluo baseadaem contineres, porm somente para sistemas Solaris. O grande passo rumo aocenrio dos dias de hoje foi a criao de um painel que permitia o fcil gerenciamentode contineres e a disponibilizao do ncleo de um sistema, chamado Virtuozzocomo cdigo aberto com o nome de OpenVZ [16].

O OpenVZ foi criado pela empresa Parallels e outra tecnologia baseada emvirtualizao leve. considerado o antecessor do Linux Containers (LXC) tantoque uma parte do cdigo do LXC derivado do OpenVZ ou com contribuio dotime do OpenVZ. A diferena do OpenVZ para os demais que o seu kernel eraproprietrio e derivado do kernel Linux 2.6, porm aps um certo tempo ele foidesenvolvido para o ncleo Linux podendo ser executado em ambos. Alm disso, elepossui funes como live migration e foi muito utilizado em cenrios de produopara Virtual Private Server (VPS).

Uma desvantagem do OpenVZ era a necessidade de aplicar um patch ao kernelLinux. Aps o surgimento do OpenVZ, o Google iniciou o desenvolvimento dosControl Groups (cgroups) para o kernel do Linux e iniciou a utilizao de contineres

17

em seus datacenters. Logo depois, surgiu o LXC que trazia consigo os cgroups paralimitar os recursos computacionais, os namespaces para isolar os processos e o chrootfornecendo uma soluo completa para a criao e gerenciamento de contineres.

A virtualizao baseada em contineres considerada uma alternativa leve virtualizao baseada em hipervisor. Contineres implementam isolamento de pro-cessos a nvel do sistema operacional da mquina hospedeira. Assim, evita-se asobrecarga devido ao hardware virtualizado e aos drivers virtualizados de disposi-tivos. Um continer pode ser considerado um ambiente virtual pequeno e isolado,o qual inclui um conjunto de dependncias especficas necessrias para executardeterminada aplicao.

Os processos dentro dos contineres no conseguem ver outros processos externose cada um dos contineres tem a sua prpria rvore de diretrios. Sendo assim, naperspectiva da aplicao o continer no difere da virtualizao tradicional porqueem ambos os casos a aplicao no sabe que est sendo executada em um ambientevirtualizado. O mecanismo para proporcionar a construo desse ambiente isoladochamado continer constitudo por ferramentas como os namespaces e os cgroups.

3.1 Namespaces

Os namespaces so umas das principais ferramentas do kernel Linux para permitir avirtualizao leve. A proposta de cada namespace separar uma parte dos recursosde sistema global em uma abstrao que faz com que parea para os processosdentro de um namespace que eles possuem sua prpria instncia isolada de recursosdo sistema hospedeiro.

O primeiro namespace, de montagem, foi introduzido no Linux kernel verso2.4.19 em 2002 e atualmente o Linux possui namespaces para identificadores deprocessos, comunicao inter-processos, rede, hostname, ponto de montagem, iden-tificadores de usurio e cgroups.

Os namespaces so utilizados para criar mltiplos espaos de usurio isolados nokernel hospedeiro. Alm disso, os namespaces permitem que processos enxerguemum diretrio arbitrrio como sendo seu diretrio raiz. Processos podem trabalharcom privilgio de superusurio dentro de um namespace sem colocar em perigo osistema hospedeiro fora dele. Adicionalmente, os namespaces expandem o isolamentopara outras partes e funes do kernel.

Tradicionalmente, o sistema operacional Linux pode somente lidar com umanica rvore de processos, a qual consiste em processos pais e filhos. Diferentesprocessos podem possuir diferentes privilgios podendo inspecionar uns aos outros narvore e cada um deles possui um nico identificador de processo (Process Identifier(PID)). Quando o Linux inicia, ao primeiro processo atribudo o PID 1 e esse

18

processo considerado como um processo init do sistema. Alm disso, o processode inicializao executa e mantm todos os outros daemons e servios necessrios.

Os namespaces de PID so utilizados para virtualizar as rvores de processos.Estes, por sua vez, dentro do namespace de PID, so isolados dos outros processosdo hospedeiro assim como dos processos em diferentes namespaces de PID. Osnamespaces de PID so hierrquicos, o que significa que cada processo tambm capaz de enxergar todos os processos dentro de seus namespaces filhos. Por exemplo,o hospedeiro pode ver os processos de todos os namespaces na sua rvore de processosoriginal. Processos dentro de um namespace de PID tem um espao para um PIDisolado e eles podem ter seu prprio processo init com PID 1. Isso significa que osprocessos podem possuir mltiplos processos atribudos a eles, um para cada rvorede processo hospedeira e outro processo que visvel dentro do namespace.

Processos executando dentro de um namespace podem precisar se comunicarcom outros processos de fora para funcionarem corretamente. Essa comunicaointer-processos feita por namespaces de Interprocess Communication (IPC) quepermitem comunicaes somente entre os processos pertencentes ao mesmo names-pace de IPC. Isso previne a interferncia de processos em namespaces distintos.

Os namespaces de rede fornecem isolamento de recursos do sistema relacionadosa rede. Ento, cada namespace de rede possui seus prprios dispositivos de rede,endereos de Internet Protocol (IP), tabela de roteamento, diretrios /proc/net,nmeros de porta e etc. Atravs do uso de namespaces de rede, processos diferentespodem enxergar diferentes interfaces de rede. Os namespaces de rede so capazes defornecer novas interfaces de rede e endereos virtuais para seus processos. Processoshospedeiros e processos em diferentes namespaces podem se comunicar uns com osoutros utilizando essas interfaces virtuais como se estivessem se comunicando comusurios externos.

J os namespacess de montagem so teis para determinar quais pontos de mon-tagem podem ser vistos dentro dos namespaces. Um processo consegue inicialmentever os mesmos pontos de montagem que o hospedeiro, contudo, com namespaces demontagem, os processos podem montar e desmontar terminais sem afetar os pontosde montagem do hospedeiro.

Adicionalmente, os namespaces de usurio so utilizados para executar os pro-cessos que possuem identidades de usurio ou de grupo diferentes. O namespace deusurio tambm permite que um processo tenha privilgios de superusurio dentrodo namespace sem ter os mesmos privilgios fora deste namespace.

19

3.2 Control Groups

Os Control Groups (cgroups) servem para gerenciar o uso do hardware e do software,como por exemplo CPU, memria, disco e rede de grupos de processos especficos.Isso feito pela atribuio de um conjunto de processos dentro de grupos hierrquicosque possuem regras especficas para seu comportamento tendo como exemplo o limitede quanto de CPU os processos podem consumir.

O projeto de cgroups iniciou atravs de dois engenheiros do Google em 2006, noano seguinte foi incorporado ao kernel do Linux. Entretanto, a comunidade alterouo conceito de cgroups e ele foi redesenhado e includo na verso 4.5 do kernel doLinux em 2016.

Com os cgroups possvel garantir que certos grupos de processos no possamconsumir muitos recursos computacionais. Alm disso, so utilizados para garantirque um grupo especfico de processos capaz de obter determinada quantidadede recursos de computao. Os cgroups se tornaram realmente teis quando elesforam combinados com os namespaces, servindo como base para a implementaode contineres.

A partir do momento em que os cgroups foram combinados com os namespaces foipossvel determinar a quantidade de recursos computacionais que cada continer tempermisso de utilizar. Isso aproximou a virtualizao a nvel de sistema operacionalda virtualizao tradicional, onde as aplicaes de recursos computacionais podemser atribudas para mquinas virtuais diferentes. Os cgroups tambm fornecemmtricas para utilizao de recursos computacionais e essas mtricas, por sua vez,podem tambm ser utilizadas para outros fins, a ttulo de exemplo para tarifao(billing).

3.3 LXC

O LXC considerado o primeiro mtodo de conteinerizao real que foi includono kernel do Linux. Apesar de haver outras solues que tambm fazem uso davirtualizao a nvel de sistema operacional, elas no eram to ativas na integraocom o kernel do Linux.

Ademais, o LXC utiliza o mesmo tipo de isolamento que o chroot, contudo oLXC utiliza os namespaces do Linux para expandir seu isolamento tendo em contaprocessos e rede. O LXC tambm utiliza os cgroups para gerenciar recursos e parautilizar algumas funes de segurana, como polticas seccomp que so oferecidaspelo kernel do Linux para limitar a quantidade de system calls que determinadoprocesso pode realizar.

O LXC oferece um isolamento lgico completo para os processos executados nos

20

contineres. Os contineres so isolados do host, assim como dos outros contine-res. Os contineres LXC compartilham o mesmo kernel subjacente do hospedeiro eportanto no necessrio um sistema operacional adicional dentro dos contineres.Atravs da utilizao do LXC possvel compartilhar os dispositivos do hospedeiroe as imagens com os contineres.

Alm disso, o LXC oferece um conjunto de ferramentas que podem ser utiliza-das para gerenciar os contineres. Isso inclui ferramentas para criao, destruio,inicializao, pausa de contineres, clonagem e monitorao dos contineres. Con-tudo, o LXC um tecnologia mais antiga quando comparada a outros gerenciadoresde contineres, como por exemplo o Docker que foi feito originalmente utilizandoo LXC como driver principal. O LXC no tem uma comunidade to grande parasuporte como o Docker, o suporte do LXC geralmente mais focado na distribuioUbuntu.

O objetivo do LXC criar um ambiente o mais prximo possvel de uma distri-buio Linux padro sem precisar separar o kernel. A sua arquitetura pode ser vistana Figura 2.2(e), desconsiderando a camada superior adicionada pelo Docker [17].Algumas caractersticas como leveza e versatilidade tem facilitado o uso dos conti-neres em diferentes contextos abrangendo desde computao na nuvem at cenriosde IoT, passando por NFV.

3.4 Docker

Conforme dito anteriormente, o conceito de contineres no novo no mundo davirtualizao, mas tem adquirido maior relevncia com a crescente adoo do sistemaDocker. O Docker introduz um mecanismo de camadas subjacentes junto a uma APIfuncional que permite facilmente criar, gerenciar e remover a aplicao dentro docontiner. Devido pequena sobrecarga adicionada, vrios contineres podem serexecutados mesmo em dispositivos com recursos computacionais limitados, tais comoplataformas Single Board Computer (SBC).

O Docker baseado no sistema operacional Linux e permite utilizar o modeloRepresentational State Transfer (REST) para gerenciar os contineres atravs dassuas imagens Docker. Um continer Docker semelhante a uma mquina virtual,contudo o continer Docker talvez mais eficiente que a VM porque ele elimina ohipervisor e o sistema operacional do visitante completamente enquanto mantm oscontineres portveis atravs do kernel do sistema operacional Linux.

A significativa melhoria do continer em relao VM no limitada a desem-penho, mas tambm a densidade de desenvolvimento. A natureza leve do continertorna a densidade de desenvolvimento mais rpida que a de VM. Alta densidade dedesenvolvimento em computao na nuvem significa que menos mquinas fsicas so

21

necessrias para atender mesma quantidade de clientes, com isso h uma reduode custos de CAPEX e OPEX para as operadoras de cloud.

Uma desvantagem do Docker a falta de maturidade da tecnologia em compa-rao a VMs j conhecidas h dcadas, alm disso h uma desconfiana em relaoa capacidade do Docker de fornecer segurana uma vez que o mesmo kernel dosistema hospedeiro compartilhado com as instncias visitantes. Ademais, outradesvantagem para implantao do Docker em ambientes de produo o esforo queas companhias tero que fazer para alterar suas prticas comuns de gerenciamento,desenvolver polticas de automao para o Docker, alterar a governana de reastcnicas, obter treinamento para equipes se qualificarem confiando em uma empresaque h muito pouco tempo desenvolveu uma verso de software com suporte garan-tido conhecida como Docker Enterprises Edition.

Alm do Docker e LXC, o Rocket [18], o Kurma [19] e o Jetpack [20] so ferra-mentas para execuo de contineres de aplicaes no Linux. O mais completo oRocket que integrado com ferramentas de orquestrao de clusters e totalmentecompatvel com outras ferramentas para contineres linux, como por exemplo o Doc-ker. Isso significa que o Rocket pode executar imagens Docker. Ele foi construdoutilizando uma especificao chamada appc feita pela CoreOS que tornou-se obsoletacom a criao dos padres da Open Container Initiative (OCI), portanto a ferra-menta no foi utilizada no presente trabalho devido a sua base ser uma especificaoobsoleta.

A escolha do Docker devido a ser atualmente a ferramenta mais utilizadarelacionada a virtualizao leve e a que possui a maior comunidade para suporte eintegrao com diversas ferramentas de orquestrao. Alm disso, a ferramentaque possui o maior ecossistema em torno das suas funes desde a contribuio paraa criao de um padro para contineres com a OCI, eventos globais de incentivo aouso da tecnologia, aquisies de empresas para impulsionar a cultura de utilizaoda ferramenta e parcerias com Over the Tops (OTTs) como Google e Amazon paratornar a ferramenta global em ambientes de produo de grandes empresas.

J a escolha do LXC devido a ele ter sido considerado o primeiro sistema decontineres que entregava uma soluo completa. Alm disso, at a verso 1.11 oDocker ainda utilizava ele em uma camada subjacente do seu cdigo servindo comoplataforma base para execuo das imagens de contineres.

3.4.1 Arquitetura do Docker

O Docker foi desenvolvido com tcnicas de Copy-on-Write (CoW). A ideia bsica que um novo recurso, seja ele um bloco de disco ou uma rea de memria, s alocadoquando for modificado. O Docker utiliza um esquema de camadas (layers) e para

22

montar essas camadas so usadas tcnicas de CoW. Um continer basicamenteuma pilha composta por N camadas read-only e uma camada, a superior, conhecidacomo read-write, conforme visto na Figura 3.1.

As camadas da Figura 3.1 representam uma aplicao web Java e elas so cons-trudas atravs de uma ferramenta chamada Dockerfile que simplesmente um ar-quivo de texto com uma sintaxe especfica para criao de imagens Docker. A tcnicade CoW faz com que caso o usurio precise fazer o download e configurar um Apa-che Tomcat dentro de um diretrio /opt/tomcat, esse procedimento no afetar aimagem original do Java na camada abaixo. Ao invs disso, o Docker iniciar es-crevendo uma camada de sistema de arquivos totalmente nova. Quando o contineriniciar, ele agrupar esses sistemas de arquivos juntos. Isso permite ler o diretrio/usr/bin/java de uma camada e um /opt/tomcat/bin de outra. De fato, cadapasso em um Dockerfile produz uma camada nova de um sistema de arquivos, mesmose somente um arquivo alterado. Por fim, essas imagens customizadas, construdasmuitas vezes em funo de outras imagens j existentes podem ser salvas e replicadascom facilidade.

Figura 3.1: Exemplo da imagem Docker de uma aplicao em Java.

O Docker daemon escuta as requisies das APIs Docker e gerencia os objetosDocker tais como imagens, contineres, redes e volumes. Um daemon tambm podese comunicar com outros para gerenciar servios Docker. J o cliente Docker aprincipal maneira dos usurios interagirem com a ferramenta Docker e com issoenviarem comandos para o daemon atravs de uma API Docker.

Alm dos elementos acima, h o registro Docker, onde so armazenadas as ima-gens. Por padro, o Docker utiliza o Docker Hub, mas tambm h a Docker Cloud.Alm desses anteriores, h a Docker Store que possibilita a compra e venda de ima-

23

gens, uma vez que as imagens so customizveis e geralmente baseadas em outrasimagens.

A Docker Cloud fornece um servio de registro hospedado com construo eteste de facilidade para imagens de aplicaes Docker, ferramentas para auxiliar aconstruo de imagens, gerenciamento de infraestrutura e aplicaes com funes deciclo de vida dos contineres para automatizar o desenvolvimento e atualizao deservios criados com imagens Docker, conforme visto na Figura 3.2.

Conforme dito anteriormente, a Docker Store a loja onde podem ser publicadoscdigos e procurar plugins ou imagens que podem agregar valor a soluo de negciode cada empresa ou para desenvolvedores que pensam em empreender. Alm disso,h uma verso open source do Docker que a Community Edition e outra paga paraempresas que buscam suporte e contratos de SLA que a Enterprise Edition. Comisso, o Docker criou um ecossistema para aproveitar ao mximo suas ferramentas edifundi-las para ambientes de produo de empresas a nvel global.

Figura 3.2: O ecossistema do Docker.

A eficincia das facilidades do Docker no armazenamento e distribuio de ima-gens dos contineres baseada em um backend de armazenamento flexvel e permut-vel. Por padro, o Docker utiliza o sistema de arquivo sobreposto AnotherUnionFS(AUFS). Este combina diversos diretrios em um sistema de arquivo virtual commltiplas camadas chamadas branches. As camadas inferiores so somente de leitura,porm os arquivos dessas camadas podem ser logicamente trocados reescrevendo umarquivo de um branch superior, conforme pode ser observado na Figura 3.1 para umaaplicao web em Java.

24

Captulo 4

Virtualizao de Funes de Rede

O trabalho colaborativo em NFV nasceu em outubro de 2012, quando alguns prove-dores de servios de telecomunicaes ao redor do mundo publicaram um documentopedindo uma ao industrial e acadmica. Em novembro de 2012, sete desses prove-dores selecionaram o European Telecommunication Standards Institute (ETSI) paraser o grupo de especificao industrial para NFV. Atualmente, mais de 5 anosdepois, uma grande comunidade de experts est trabalhando intensamente para de-senvolver os padres necessrios para NFV e compartilhando suas experincias noseu desenvolvimento e implantao [21].

4.1 Objetivo do NFV

A demanda dos usurios por novos servios, muitas vezes de curta durao e combanda passante elevada, continua a aumentar. Por exemplo, frequentemente osclientes solicitam um aumento programado de banda por um tempo limitado ou obloqueio de portas em um firewall para todas as filiais de uma empresa, para algumamanuteno rpida.

Com isso, as operadoras continuamente compram, guardam e operam novos equi-pamentos fsicos, os quais possuem custos muito elevados. A principal ideia do NFV desacoplar o equipamento de rede fsico das funes que so executadas nele. Issosignifica que uma funo de rede tal como um firewall, pode ser vista pela operadoracomo uma instncia de um software simples, adotando o conceito de NFV.

Dessa maneira, um dado servio pode ser decomposto em um conjunto de VNFs,as quais podem ento ser implementadas em um software executado em um oumais servidores de prateleira (COTS). As VNFs podem ento ser realocadas einstanciadas em diferentes localizaes, acrescentando flexibilidade configuraoda rede da operadora [22].

25

4.2 Diferenas para solues legadas

O desacoplamento entre o software e o hardware faz com que um elemento de redeno seja mais uma composio de entidades de hardware e software integradas,frequentemente chamadas de solues verticais. Isso possibilita que as evolues deambos sejam independentes uma da outra e tambm permite a separao das linhasde desenvolvimento e manuteno [23].

Outra diferena o desenvolvimento flexvel de funes de rede, uma vez quea separao entre o software e o hardware ajuda a reatribuir e compartilhar osrecursos de infraestrutura, facilitando a realizao de diferentes funes em diferentesperodos. Isso ajuda as operadoras de rede a implantarem novos servios de formamais rpida utilizando a mesma plataforma fsica e com isso, componentes podemser instanciados em qualquer dispositivo que suporta NFV na rede e suas conexesconfiguradas de maneira flexvel.

Alm disso, o NFV proporciona uma escalabilidade dinmica, uma vez que aseparao da funcionalidade das funes de rede em componentes de software ins-tanciveis fornece uma alta flexibilidade para escalar o atual desempenho das VNFsdinamicamente [24] e com granularidade mais fina, por exemplo, de acordo com otrfego atual para o qual o operador precisa prover capacidade.

4.3 Edge Computing

A Edge Computing, ou computao na borda, uma tecnologia emergente quefornece servios de nuvem e de Tecnologia da Informao (TI) com uma maiorproximidade dos assinantes, com isso a inteligncia da rede expandida para a bordaaumentando a responsabilidade da operadora ao lidar com plataformas distribudase consequentemente com o aumento na complexidade para gerenciamento delas.

Uma plataforma de computao na borda reduz a latncia das aplicaes atravsde sua capacidade de computao e armazenamento na borda da rede, ou seja, maisprximo do usurio final [25]. Dispositivos mveis e de IoT so os grandes benefi-ciados desse novo conceito, uma vez que possuem uma grande descarga de trfegooriundo de aplicaes com uso computacional intensivo, tais como processamentode imagens, jogos mveis e etc.

A computao na borda no implica porm a substituio dos datacenters tra-dicionais ou da computao em nuvem que conhecemos. A computao na borda uma computao adicional que pode coexistir com a computao na nuvem. Assim,uma carga computacional distribuda onde mais conveniente, entre a borda e anuvem. Por exemplo, dados de sensores sero coletados e processados em gatewaysna borda onde solues de tratamento de grandes massas de dados (Big Data) po-

26

dem ser aplicadas utilizando algoritmos baseados em regras e inclusive podendo seraplicadas em tempo real.

Os dados filtrados podem ser enviados para uma nuvem centralizada visandoo enriquecimento e agregao destes com outras fontes de informao, tais comobanco de dados de Customer Relationship Management (CRM) e ento colocadosem mecanismos de anlise da rede para gerar modelos que podem ser novamenteenviados para anlise na borda.

Em relao telefonia mvel, a Mobile Edge Computing (MEC) oferece informa-o da RAN em tempo real para os desenvolvedores de aplicao e contedo [26].Essas informaes, tais como utilizao da rede e localizao do usurio na rede, soutilizadas para fornecer servios personalizados para assinantes mveis, elevando onvel de flexibilidade dos servios e consequentemente de satisfao do usurio eQuality of Experience (QoE). Alm disso, as operadoras podem permitir que os r-dios na borda da rede sejam manipulados por parceiros e com isso permitir o rpidodesenvolvimento de novas aplicaes e servios na ponta para assinantes mveis eempresas.

J no nicho de IoT, a Fog Computing proposta para possibilitar a computaodiretamente na borda da rede que pode entregar novas aplicaes e servios [27]especialmente para Internet do Futuro. Na Fog Computing, facilidades ou infraes-truturas que podem fornecer recursos para servios na borda da rede so chamadosfog nodes [28]. Estes podem ser dispositivos com poucos recursos como set-top-boxes,pontos de acesso, roteadores, concentradores, base stations ou terminais. Um exem-plo disso a plataforma IOx [29] da Cisco que executado em um hipervisor epermite que desenvolvedores executem cdigos python podendo assim executar seusprprios cdigos.

Apesar de terem nomes distintos em algumas reas, o cerne dos conceitos acima o mesmo, uma vez que a camada de Edge Computing ser executada perto dasfontes de dados e cada unidade de Edge Computing ter seu prprio conjunto derecursos no que diz respeito a computao, armazenamento e rede. Essas unidadessero configuradas para funes especficas as quais sero a funo principal dodispositivo. Estes, por sua vez, sero os primeiros responsveis pela manipulao defunes de rede como switching, routing, load balancing, segurana. O cluster dedispositivos de Edge computing o ponto de agregao local para dados originadosde uma variedade de fontes.

Ademais, cada um desses dados obtidos analisado por um mecanismo com-plexo de processamento de eventos que decide o caminho pelo qual eles seguirobaseado em polticas e regras predefinidas, com isso os dados so processados local-mente ou so encaminhados para a nuvem tradicional visando um processamentomais completo. O hot data, o qual crtico para a operao da infraestrutura lo-

27

cal ser analisado, armazenado e processado imediatamente pela camada de EdgeComputing. O cold data que contribui para uma anlise histrica a longo prazo serenviado para a nuvem tradicional para um processamento em lote [30].

4.4 Desempenho em NFV

O conceito de NFV consiste em executar Network Functions (NFs) em servido-res COTS, o que significa que os fornecedores de servidores poderiam produzir oequipamento sem o conhecimento das caractersticas das funes que, por sua vez,poderiam ser executadas neles no futuro. Da mesma forma, os fornecedores deVNFs poderiam garantir que essas funes seriam capazes de serem executadas nosservidores anteriores. Isso levanta a questo de que se as funes executadas nosservidores COTS poderiam realmente alcanar um desempenho comparvel que-las que so executadas em hardware especializado e se essas funes poderiam sermigrveis entre esses servidores.

O desempenho em altas taxas de transmisso um problema mesmo em equi-pamentos que executam funes de rede no virtualizadas. J em ambientes vir-tualizados, tcnicas tais como acelerao de hardware sero tambm importantespara NFV, uma vez que o desempenho impactado por uma srie de fatores como avirtualizao em si, o uso de redes sobrepostas e o uso de protocolos para transportecomo Transmission Control Protocol (TCP)/IP.

Alguns pesquisadores [31] [32] [33] em NFV buscam como alcanar alto desempe-nho em uma plataforma de software middlebox virtualizada. Para Edge Computingcom NFV, o desempenho em ambientes virtualizados ainda a primeira preocupa-o, uma vez que esse desafio possui dois aspectos: o primeiro a vazo e latnciadas middleboxes virtualizadas na rede e o outro como obter uma instalao efici-ente, colocao e migrao das instncias virtuais em uma rede dinmica cumprindorequisitos de latncia baixa e vazo elevada.

Existem algumas abordagens para acelerao de software como as bibliotecasData Plane Development Kit (DPDK) que utilizam polling para superar os gargalosdas interrupes geradas pelo hipervisor e utiliza tecnologias como Core pinningque fixa os processadores que a VM ir utilizar. J em relao a hardware existeo Single Root I/O Virtualization (SR-IOv) que permite que a Network InterfaceCard (NIC) crie diversas funes virtuais com acesso direto a VM realizando umbypass dos gargalos do sistema hospedeiro. Entretanto, o presente trabalho noconsiderou essas tcnicas de acelerao nos cenrios em anlise.

Ademais, VNFs relacionadas a servios de voz manipulam uma grande quanti-dade de pacotes com tamanhos pequenos, os quais exigem um grande esforo aosistema, sendo assim, a garantia contra perda de pacotes muito mais complexa

28

quando se tratam de pacotes pequenos. Alm disso, alguns subsistemas so compos-tos por diversos componentes, como por exemplo IP Multimedia Subsystem (IMS),Evolved Packet Core (EPC) e Virtual Customer Premises Equipment (vCPE), o quecontribui para penalizar o desempenho. Adicionalmente aos desafios decorrentes davirtualizao, h o impacto devido ao Network Service Chaining (NSC) para per-mitir o encadeamento de funes em determinados fluxos de carga gerando assim aflexibilidade lgica e automao prometidas pelo NFV.

29

Captulo 5

Trabalhos Relacionados

A avaliao de desempenho em solues virtualizadas est presente em diversos tra-balhos na literatura com alguns deles abordando aplicaes especficas como em [34]que faz uma anlise de desempenho de duas ferramentas de cdigo aberto de virtu-alizao, KVM e Docker, em um cenrio com Hypertext Transfer Protocol (HTTP)proxy. Adicionalmente, em [35] foram apresentadas tcnicas leves de benchmarkingsna nuvem que so executadas rapidamente e podem ser utilizadas em tempo real.

Em [36] realizada uma investigao sobre os impactos de vrios hipervisoresno que diz respeito ao desempenho do sistema e com o objetivo de identificar qual o hipervisor timo para satisfazer as necessidades do mercado. Os hipervisoresVMWare [37], VirtualBox e VirtualPC foram comparados adotando um benchmar-king de desempenho que analisa I/O de disco, memria, CPU e consumo de energia.Entretanto, o trabalho considera como cenrio nativo um sistema operacional di-ferente do cenrio virtualizado podendo ter seus resultados mascarados devido natureza das diferentes pilhas de sistemas operacionais hospedeiros. J o presentetrabalho leva em considerao o desempenho de rede, aplicao e utiliza o mesmosistema operacional hospedeiro para todos os cenrios avaliados trazendo mais con-fiabilidade s amostras.

J em [38] descrita uma abordagem fim a fim para avaliar plataformas de vir-tualizao. Introduz-se um benchmarking com virtualizao tradicional que envolveuma comparao de desempenho em sistemas reais versus desempenho em sistemasvirtualizados. Foram descritos trs benchmarkings especficos para ambientes virtu-alizados. Para nvel de sistema foi utilizado o VMMark [39], o qual incorpora rotinasque avaliam simultaneamente sobrecarga de diversos recursos como CPU, memriae I/O. As outras duas ferramentas foram desenhadas para medio de gerencia-mento de virtualizao e desempenho da aplicao: VCBench e ViewPlanner [40].Houve tambm uma preocupao com design de fluxos de trabalho, entretanto dife-rentemente do presente trabalho, o artigo focou em um nico tipo de virtualizaoutilizando um nico hipervisor para anlise o que gera um resultado muito especfico

30

podendo no ser aplicado em ambientes reais.Ademais, em [41] foi feita uma anlise de desempenho em 3 diferentes sistemas

de arquivos no Linux que so ext4, xfs e btrfs utilizando hipervisores do tipo 2.Foram utilizadas as ferramentas de benckmarking Postmark [42] e Bonnie++ paragerao de testes no ambiente com nfase na vazo de leitura e escrita de discosob diferentes condies de carga. Entretanto, a anlise foi especfica para disco quetalvez no seja o aspecto mais importante em termos de desempenho de aplicaes noecossistema de NFV, uma vez que processamento e memria so cruciais e tambmso uma das contribuies do presente trabalho.

Diversas tcnicas de benchmarking so tipicamente pesadas consumindo proces-sos os quais necessitam testar a VM inteira a fim de obter dados corretos. Taisbenchmarkings no podem ser feitos em tempo real na nuvem causando custos ex-tras quando a aplicao implementada. Em [35] , foram apresentadas tcnicasleves de benchmarking na nuvem que so executadas rapidamente e podem ser utili-zadas em tempo real. A utilizao de tcnicas de benchmarking leves so facilitadaspelo desenvolvimento do Docker Container-bases technology Lightweight Benchmar-king (DocLite). Este construdo com tecnologia Docker, a qual permite que umpedao definido pelo usurio seja testado. DocLite opera em dois modos, no pri-meiro, os contineres so utilizados para avaliar uma pequena parte da VM paragerar classificaes de desempenho. J no segundo modo de execuo, os dados his-tricos do benchmarking so utilizados atravs do primeiro modo de maneira hbridapara gerar classificaes de VMs.

Nos trabalhos [43] e [44], visando avaliar como sero os cenrios e protocolos paraInternet do Futuro, tendo como premissa que virtualizao ser a tcnica principalpara acomodar os elementos dessa nova Internet, os autores avaliaram o desempenhode trs ferramentas de virtualizao conhecidas que so Xen, VMWare e OpenVZconsiderando a utilizao para virtualizao de roteador. Os autores conduziram oexperimento com ferramentas de benchmarking para medir a sobrecarga introduzidapela virtualizao em termos de memria, processador, rede e desempenho de discodos roteadores virtuais executando em servidores COTS.

Adicionalmente, avaliaram os efeitos de escalabilidade de mquinas virtuais naferramenta de virtualizao Xen e os resultados mostraram que ele quem melhoratende os requisitos de roteadores virtuais. Entretanto, a anlise est defasadadevido a diversas melhorias nas ferramentas utilizadas diferentemente do presentetrabalho. Alm disso, o trabalho presente analisa explicitamente a virtualizaoassistida por hardware e a virtualizao leve que foco em ambientes operacionaisnas principais empresas que lidam com aplicaes na nuvem evidenciando um avanono trabalho atual em relao aos citados acima.

O NFV um novo paradigma no qual servios de rede so virtualizados e podem

31

ser executados em hardware genrico com melhor agilidade do servios e reduo decustos. H muitos fatores que encorajam o emprego de NFV, mas alguns requisitosparticulares devem ser cuidadosamente avaliados, como por exemplo qual tipo devirtualizao escolher. Em [34] foi feita uma anlise de desempenho de duas soluesde cdigo aberto (open source) de virtualizao, KVM e o Docker, em um cenrio deHTTP proxy. Os resultados mostraram que o Docker processa as requisies HTTPem um tempo menor que o KVM, devido a sua virtualizao leve. Com isso, baseadonos resultados, forneceram uma ampla discusso sobre cada soluo de virtualizaoaplicada em ambientes NFV.

Nenhum dos trabalhos anteriores mistura diversos tipos de virtualizao e ferra-mentas atuais com anlise de aplicaes de misso crtica, ou seja, aquelas cruciaispara a empresa como banco de dados, Enterprise Resource Planning (ERP), Cus-tomer Relationship Management (CRM) e plataformas de colaborao. Alm disso,nenhum dos anteriores utiliza mais de uma ferramenta em uma nica frente deanlise, conforme feito no caso de processamento para dupla validao do compor-tamento garantindo maior confiabilidade a anlise. Assim como os outros trabalhos,o presente trabalho se preocupa com tratamento estatstico, uma vez que em todosos casos foram consideradas entre 50 e 100 iteraes para cada ponto em anlise.

32

Captulo 6

Metodologia de Anlise

Este captulo descreve a metodologia utilizada para analisar o desempenho de di-ferentes tipos de virtualizao na implementao de Edge computing baseada emNFV, ou seja, a computao prxima ao usurio final. A computao na borda passvel de ser aplicada em diferentes casos como IoT, SD-WAN, Customer PremisesEquipments (CPEs) virtuais, Redes Mveis, Content Delivery Networks (CDN), BigData, entre outros.

Cabe ressaltar que quando medido o desempenho de um dispositivo de redevirtual, avalia-se o desempenho cumulativo de vrias entidades envolvidas, seja daVM, do continer, do hipervisor e dos recursos de NFVI. Qualquer comparao entredesempenho de alguma entidade de diferentes fornecedores deve ser feita somentequando as variveis envolvidas se mantiverem constantes para um cenrio justo. Porexemplo, quando o desempenho de VNFs fornecidas por diferentes Independent Soft-ware Vendors (ISVs) comparado, deve-se utilizar o mesmo hipervisor e os mesmosrecursos de NFVI no momento de execuo do benchmarking de desempenho.

Foram analisadas algumas das ferramentas de virtualizao mais difundidas atu-almente: KVM, VirtualBox [45], LXC e Docker. As ferramentas escolhidas repre-sentam diferentes tipos de virtualizao, conforme explicado anteriormente. Umadas maiores dificuldades em avaliar ferramentas de virtualizao que algumas fer-ramentas comuns de benchmarking tm suas medidas distorcidas pelo tempo internoao ambiente virtualizado, porm essa dificuldade no prejudicou a confiabilidade daanlise devido ao ajuste de timestamp no KVM e ao controle de drift temporal noVirtualbox.

Conforme dito anteriormente, as ferramentas de virtualizao de diferentes forne-cedores devem ser avaliadas utilizando os mesmos benchmarkings, alm das mesmasVNFs e recursos de NFVI a fim de manter a mesma referncia na anlise dos re-sultados obtidos. Entretanto, uma considerao importante que no basta avaliarsomente o nmero mximo de VMs suportadas, por exemplo. Em vez disso, deveser testado o nmero mximo de VM suportadas no hipervisor sob trfego avaliando

33

a QoE do usurio que o servio capaz de oferecer dentro de limites aceitveis esatisfazendo o SLA contratado.

Foram realizados benchmarkings avaliando desempenho de CPU, de memria,de entrada e sada em disco, de desempenho de rede, e de aplicaes visando a veri-ficao da qualidade de experincia do usurio que uma tendncia nas operadorasde telecomunicaes em face da real ameaa das chamadas OTTs.

Alm disso, vlido informar que o presente trabalho no leva em consideraoas tcnicas que alguns hipervisores e sistemas operacionais utilizam relacionadas otimizao de CPU diminuindo o nmero de interrupes no controle dos elementosvirtualizados atravs de tcnicas como SR-IOv, DPDK e Core pinning. Essa escolhafoi feita na tentativa de simplificar os cenrios, uma vez que o objetivo do presentetrabalho mostrar a diferena de desempenho das tecnologias de virtualizao con-forme elas so disponibilizadas na instalao bsica e padro.

Figura 6.1: Cenrios para avaliao do desempenho de rede.

Para realizar a anlise de desempenho, foi utilizado um cenrio composto porum computador pessoal com processador Core i7, 8 GB de Random Access Memory(RAM) e disco rgido de 1 TB. O computador executa um sistema operacional Linux,distribuio Ubuntu 16.4 com kernel verso 4.4.0-31 e placa de rede com velocidadede 100 Mbps.

Tabela 6.1: Cenrios de anlise.Cenrios Plataformas1o cenrio Nativo2o cenrio Nativo + Docker3o cenrio Nativo + LXC4o cenrio VirtualBox + VM5o cenrio KVM + VM

A configurao dos testes permitiu comparar o desempenho dos diferentes tiposde virtualizao em cinco cenrios distintos, ilustrados na Tabela 6.1. Ademais, a

34

topologia de rede est ilustrada na Figura 6.1, com origem e destino de acordo como cenrio definido na Tabela 6.1.

Os cenrios e ferramentas escolhidas foram o Docker por ser a ferramenta maisutizada relacionada a virtualizao leve, o LXC que deu origem ao Docker e con-siderado a primeira tecnologia a oferecer um ambiente completo para execuo decontineres. Alm dessas duas, h o Virtualbox que uma ferramenta muito co-nhecida por representar os hipervisores do tipo II e o KVM que open source emundialmente utilizado em ambientes de produo representando os hipervisorestipo I com virtualizao assistida por hardware. Ademais, h o cenrio nativo querepresenta o legado e serve como referncia para comparao dos gargalos inseridospelas diferentes tecnologias de virtualizao.

Alm disso, em alguns cenrios foram utilizadas mais de uma ferramenta deanlise para verificar a correlao dos resultados e evidenciar um comportamentosemelhante em ambas a ttulo de comparao. Com isso, possvel realizar umadupla validao do resultado e assim evitar que alguma ferramenta tenha uma con-cluso equivocada nos resultados do benchmarking devido a alguma caractersticapeculiar da sua implementao.

6.1 Processamento

Um programa de computador consiste em uma srie de passos chamados instrues,as quais informam aos computadores o que fazer e o processador de um computadorbusca, decodifica e executa as instrues dos programas. Cada instruo pode serum clculo aritmtico bsico ou uma operao lgica e antes que o programa possaser executado ela lida dentro da memria.

Essa basicamente a funo do processador, o qual controla o computador parabuscar uma instruo de programa na memria, decodificar a instruo e entoexecutar as aes necessrias no processo de execuo. de responsabilidade doprocessador executar o ciclo busca-decodificao-execuo inmeras vezes com asinstrues obtidas na memria. Essa ciclo de busca, decodificao e execuo frequentemente chamado de ciclo de execuo.

Os principais componentes do processador so a Unidade Lgica e Aritmtica(Arithmetic and Logic Unit (ALU)), a Unidade de Controle (Control Unit (CU)) e osregistradores. A primeira o crebro do processador, realiza os clculos aritmticosbsicos como adio, substrao, multiplicao e diviso e tambm as operaeslgicas como comparao. J a segunda, como o nome sugere quem controla todasas funes executadas dentro do prprio processador. Tambm indica para a ALUqual operao lgica ou aritmtica precisa ser feita, estas disparadas a cada clock dosistema e escolhendo todos os caminhos internos do processador para ter certeza de

35

que o dado seja obtido no lugar certo e v para o destino correto.Os registradores tambm so componentes chave dos processadores e eles ocupam

a posio de um armazenador temporrio dos dad

ANÁLISEDODESEMPENHODAVIRTUALIZAÇÃOLEVEPARA ... · In order to do so, comparisons of CPU, memory,...

Documents

Transcript of ANÁLISEDODESEMPENHODAVIRTUALIZAÇÃOLEVEPARA ... · In order to do so, comparisons of CPU, memory,...