Configuração dos Experimentos

Para avaliar o ARENA, nós modelamos e simulamos um ambiente NFV utilizando o simulador CloudSimSDN [64], uma ferramenta de simulação estendida do CloudSim [65] que permite a definição de ambientes de nuvem definidos por software com recursos dina- micamente gerenciados. A ferramenta permite a avaliação de políticas de gerenciamento de recursos – incluindo algoritmos de colocação de funções – e simular máquinas físicas e virtuais, switches, enlaces e topologias, além de capturar métricas de desempenho tanto para avaliar garantias de QoS quanto de consumo de energia.

Foi necessário estender as capacidades do simulador, pois até então ele não possuía a capacidade de implementar serviços encadeados nem políticas de elasticidade horizontal ou vertical. A partir de então, foi possível criar modelos com a especificação da ordem correta que os workloads deveriam percorrer uma SFC e agendar os momentos de decisão de elasticidade com base na predição.

6.1.1

Serviço encadeado ofertado

Para os experimentos foi considerado um serviço encadeado composto por cinco fun- ções virtuais, extraído dos trabalhos de [66] e [55], listado na Tabela 2.

Tabela 2: Serviço encadeado considerado no experimento.

Funções encadeadas

NAT → Firewall → Traffic Monitoring → Wan Optimizer → Intrusion Detection

Cada uma das funções descritas na Tabela 2 possui especificações do número de nú- cleos coletadas de versões análogas que se encontram à disposição para aluguel em serviços de nuvem [67–71], conforme descrito na Tabela 3. Conforme mencionado, uma vez que os cálculos de ocupação consideram apenas a utilização de CPU, os valores de memória RAM serão desconsiderados nos experimentos.

Tabela 3: Especificação das capacidades requisitadas por cada VNF.

VNF # Cores/MIPS AMI Reference

NAT 2/3300 t2.small

Firewall (FW) 4/3300 m4.xlarge

Traffic Monitor (TrafMonit) 8/3300 c5.2xlarge

WAN Optimizer (WanOpt) 2/3300 m4.large

Intrusion Detection System (IDS) 8/3300 m4.2xlarge

Para os experimentos do ARENA Vertical, definimos uma lista de configurações de VNFs em escala crescente para serem utilizadas nas decisões de elasticidade tanto do ARENA quanto dos modelos de comparação reativo e proativo. Os modelos foram base- ados em versões disponíveis na lista de instâncias do serviço Google Cloud1_{, listadas na} Tabela 4 da mínima até a máxima versão possível de ser escolhida nas decisões.

Assim, a configuração mínima que uma VNF pode ter é de 4 núcleos e a máxima é de 200 núcleos. Também definimos um modelo de custo de utilização das instâncias, baseado na política de preços do serviço Amazon AWS2, cuja cobrança corresponde ao custo de $0,069 por núcleo de CPU por hora.

6.1.2

Requisito de processamento unitário das funções

Conforme mencionado na seção 4.1.3.1, utilizaremos um modelo de consumo uniforme que cada VNF oferece a partir da execução de um único workload, extraídos exatamente

1_{https://cloud.google.com/compute/docs/machine-types} 2_{https://aws.amazon.com/pt/ec2/pricing/on-demand/}

Tabela 4: Lista de configurações de VNFs utilizadas nos experimentos de elasticidade vertical .

# Cores/MIPS Machine name 4/3300 n2-highcpu-4 8/3300 n2-highcpu-8 16/3300 n2-highcpu-16 32/3300 n2-highcpu-32 48/3300 n2-highcpu-48 64/3300 n2-highcpu-64 80/3300 n2-highcpu-80 96/3300 n2d-standard-96 160/3300 m1-ultramem-160 200/3300 n2d-standard-224

como definidos em [55]. Os dados de PRU para cada função estão descritos na Tabela 5.

Tabela 5: Requisito de Processamento Unitário para cada usuário.

VNF PRU NAT 0.0092% FW 0.009% TrafMonit 0.133% WanOpt 0.054% IDS 0.107%

Segundo a Tabela 5, temos que cada workload que passar por essa cadeia vai consumir, por exemplo, 0.107% de CPU por segundo da função IDS até ser totalmente atendido.

6.1.3

NFVI e algoritmo de colocação

A infraestrutura NFV utilizada nos experimentos é composta por três racks interli- gados entre si contendo cinco NFV-Nodes (servidores) de capacidades heterogêneas de CPU de 16, 28, 36, 112 e 256 núcleos de 3.3Ghz e 20GB de memória RAM. O número de núcleos de CPU dos cinco nós foi baseado na lista de plataformas de CPU oferecida pelo serviço de nuvem Google Cloud3. Vamos considerar o acréscimo de 1 milissegundo no tempo de execução de um workload cada vez que este precisar percorrer uma VNF localizada em um rack diferente do que se encontra.

Mediremos o consumo de energia dos servidores em utilização a fim de avaliar o impacto da abordagem ARENA sobre os custos nesse sentido. O modelo de consumo de

energia será calculado por um modelo linear descrito em [72] dado por:

Ps= Pidle+ Ppeak∗ u (6.1)

onde, u é a porcentagem de utilização de CPU do servidor; Pidle é o consumo do servidor quando não há utilização de CPU e; Ppeak é o consumo de energia do servidor quando está em utilização máxima. Vamos considerar 140 Kwh paraPpeake 100 Kwh para Pidle.

O algoritmo utilizado para determinar a alocação das instâncias sobre os servidores seguiu a estratégia do Most Full, isto é, prioriza seu posicionamento sobre os hospedeiros mais cheios, o que na prática significa utilizar o menor número possível de servidores. Nos experimentos de elasticidade horizontal, o número de instâncias para cada VNF foi de 6 para NAT e Firewall, 13 para Traffic Monitoring, 9 para Wan Optimizer e 8 para IDS.

6.1.4

Parâmetros de simulação

Os testes foram realizados com base nos valores preditos para 7 dias de tráfego cor- respondentes à medição ocorrida entre os dias 24 e 31 de março de 2017, assumindo que o algoritmo já treinado fornece a predição dos próximos 5 minutos para cada 15 minutos de tráfego medido. A Figura 6.1 mostra a variação da demanda a cada janela de cinco minutos. O número de requisições retirado do arquivo de capturas e injetado na simula- ção representando workloads na direção da SFC foi multiplicado por 100 a fim de gerar consumo de CPU suficiente para engatilhar as decisões de elasticidade.

Consideramos que as decisões de elasticidade horizontal de diminuição de instâncias serão instantâneas e as de aumento levarão 1 segundo para estarem disponíveis, uma vez já estarem alocadas desde o início do experimento. Para os experimentos com elasticidade vertical, consideramos que as decisões de aumento ou diminuição levarão 26 segundos para começar a valer, de acordo com estatísticas de provedores de nuvem [73] e 16 segundos de para conclusão de uma migração[74], durante o qual os workloads que ingressarem serão descartados.

O limiar de utilização, utilizado para o cálculo dos recursos necessários com base na demanda predita, será de 50% para o máximo e de 10% para o mínimo. O valor de 50% para o máximo é inspirado numa política comum utilizada em servidores de nuvem de buscar uma alocação de recursos que mantenha a utilização em média pela metade a fim

Figura 6.1: Variação do tráfego de dados utilizada nos experimentos

de estar preparada para eventuais picos de demanda durante a janela de alocação4.

6.1.5

Modelo de comparação horizontal proativo

Para a avaliação da assertividade do ARENA no modo de elasticidade horizontal, foi escolhido como modelo de comparação (baseline) outra solução proativa baseada na abordagem apresentada em [47]. Nessa abordagem, a elasticidade proativa é alcançada mediante a conversão do problema de dimensionamento automático num problema de classificação de aprendizagem de máquina supervisionado.

Para treinar o classificador supervisionado, os autores observaram as decisões de elas- ticidade passadas associadas ao tráfego de dados medido naqueles mesmos instantes. Com o classificador já treinado, o modelo dá como saída o número de instâncias de cada VNF que compõe a SFC a partir das informações do tráfego medido e associadas a outros dados referentes ao tempo como hora do dia, dia da semana, etc. Os autores não descre- vem em maiores detalhes os parâmetros do modelo reativo do qual treinam seu modelo proativo. Para o nosso experimento, configuramos no simulador um mecanismo de elasti- cidade horizontal reativa que prioriza a manutenção do desempenho do serviço baseado no monitoramento do consumo de CPU.

A estratégia de elasticidade adota uma abordagem agressiva para aumentar os recursos e conservadora para diminuir: as decisões de aumento se dão caso o consumo de CPU da instância (ou a média de consumo entre todas as instâncias ativas) tenha ultrapassado 50% em qualquer instante durante os últimos 60 segundos, acrescentando uma instância por vez, enquanto que para diminuição o modelo considera o caso onde a instância (ou a média entre as ativas) tenho ficado abaixo de 10% durante os últimos cinco minutos seguidos, de acordo com recomendações de políticas de elasticidade apresentadas nos principais provedores de nuvem567_.

Com o modelo pronto, foi simulado o equivalente a 15 dias de utilização dos serviços, isto é, foram injetadas as requisições do conjunto de dados de tráfego correspondente à captura de 15 dias, que iam gerando carga de trabalho sobre as funções virtualizadas e resultando em decisões do mecanismo reativo de aumento e diminuição ao longo do tempo de simulação, todas registradas em arquivo. De posse destas informações, um modelo de predição foi montado nos moldes do que foi feito no trabalho de referência.

Escolhemos o mesmo modelo utilizado no trabalho (Random Forest )[75] para treinar o algoritmo e obter o número de instâncias a partir da entrada do volume de tráfego da última janela e das características temporais, dos quais utilizamos os seguintes: hora do dia, minuto, dia da semana, dia do mês e fim de semana (booleano). Treinamos o modelo sobre a metade do conjunto e validamos sobre a outra metade, obtendo uma precisão média de mais de 94%, muito próximo dos 96% obtidos nos experimentos originais. Uma vez treinado e validado, o modelo está pronto para utilização na comparação, o qual será nomeado nos testes como Baseline Horizontal.

6.1.6

Modelo de comparação horizontal reativo

Conforme mencionado na seção 1.4, um dos objetivos desta tese de doutorado é com- parar a contribuição da abordagem proativa do ARENA com a abordagem reativa nos objetivos de custo e desempenho. Para isto, selecionamos como modelo de comparação de elasticidade horizontal reativa uma abordagem baseada na estratégia de dimensiona- mento horizontal do Kubernetes[76], um sistema de orquestração de contêineres de código aberto que automatiza a implantação, o dimensionamento e a gestão de aplicações em contêineres, originalmente projetado pelo Google.

5_{https://cloud.google.com/compute/docs/autoscaler/scaling-cpu}

6_{https://docs.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling}

Diferente do modelo reativo descrito na seção anterior, no Kubernetes a decisão pelo número de instâncias a ser adicionadas é determinada em função da proporção entre o consumo medido e o valor de referência para ele. Assim, por exemplo, se o consumo de CPU medido estiver o dobro do limiar, o número de instâncias deverá ser dobrado e se estiver à metade da referência deverá também ser reduzido à metade, arrendondando os valores sempre para cima, conforme equação 6.2.

numInstances = 

currentN umInstances ∗ currentOccup targetOccup



(6.2)

Replicamos essa estratégia exatamente como descrita, adotando como valor de refe- rência uma ocupação de 50% e reduções somente se passados pelo menos cinco minutos da última conforme descrito em sua documentação. O dimensionamento não ocorrerá se o valor da razão currentOccup_targetOccup estiver suficientemente perto de 1, portanto adotamos um limiar de tolerância de 10%, também conforme recomendado na documentação.

6.1.7

Modelo de comparação vertical proativo

Para a avaliação do ARENA Vertical, definimos um modelo vertical proativo sob a mesma abordagem definida em [47] e adaptada conforme descrito na seção 6.1.5. Isto é, também definimos um modelo reativo que toma decisões de elasticidade verticais, neste caso, subindo ou descendo uma unidade na escala de especificações de VNFs descritas na seção 6.1.2 sempre que o limiar de ocupação ultrapassou 50% no último minuto ou permaneceu abaixo de 10% pelos últimos cinco minutos e registramos todas as decisões tomadas durante os 15 dias simulados.

O processo de treinamento e validação se repetiu também com o modelo Random Forest e sob os mesmos parâmetros de entrada na versão horizontal, obtendo precisão média de 95%. Esse modelo será nomeado nos testes avaliativos como Baseline Vertical.

6.1.8

Modelo de comparação vertical reativo

A abordagem vertical reativa que será comparada com o ARENA Vertical seguirá a mesma abordagem utilizada para o treinamento do modelo horizontal proativo, isto é, decisões de aumento caso o consumo tenha ultrapassado 50% em qualquer instante durante a última janela de 1 minuto, subindo uma escala na lista de categorias à disposição, e retração caso o consumo tenho ficado abaixo de 10% durante os últimos cinco minutos

seguidos. Será nomeado nos testes como Reativo Vertical.