ARENA Auto-scaling Dimensionador Automático de Fun ções Virtuais

Para a descrição do componente responsável pelo dimensionamento automático, serão elencadas algumas premissas consideradas nesta tese de doutorado para lidar com o pro- blema da elasticidade horizontal e vertical de funções virtualizadas em cadeias de serviço. Esta tese considera um cenário onde VNFs são instanciadas sobre uma NFVI disponível a partir de um ambiente de computação em nuvem. Considera-se uma NFVI composta por um ou mais NFV-PoPs interligados por enlaces de alta capacidade, como ilustrado na Figura 4.5, com cada NFV-PoP sendo formado por um conjunto de NFV-Nodes, isto é, servidores de propósito geral sob a premissa de que o componente VIM tem permissão para gerenciar o ligamento e desligamento dos nós reservados para a infraestrutura para auxiliar na sua gestão de custos.

A NFVI serve de base para a oferta de serviços de rede na forma de cadeias de funções. Isto é, cada serviço de rede é uma cadeia de funções virtualizadas pelas quais o tráfego ingressante deve percorrer na ordem pré-definida, estejam elas alocadas no mesmo NFV- Node, no mesmo NFV-PoP mas em um NFV-Node diferente ou em diferentes NFV-PoPs, conforme ilustrado na Figura 4.5.

Cada VNF apresenta seus próprios requisitos de processamento, armazenamento e memória. A possibilidade de instanciação de uma VNF sobre um NFV-Node estará en- tão sujeita à disponibilidade de processamento, memória e armazenamento no servidor

Figura 4.5: Dois serviços oferecidos ao longo da NFVI envolvendo diferentes NFV-PoPs

hospedeiro em quantidade pelo menos igual à exigida pela instância.

A colocação das instâncias ao longo da NFVI será orientada por um algoritmo de colocação que considera a quantidade e as capacidades requisitadas por cada função e as capacidades disponíveis nos servidores. Além disso, ele pode ser guiado por objetivos como a menor distância possível entre as funções que compõem a mesma cadeia de serviços e/ou a utilização do menor número possível de recursos computacionais à disposição. Entretanto, apesar de considerar esse processo como parte do problema de se prover elasticidade proativa horizontal e vertical, esta etapa do processo não será objeto de estudo desta tese de doutorado a fim de concentrarmos os esforços no problema de maximização da assertividade.

Uma vez alocada sobre um servidor, cada instância ativa é responsável por processar a carga de trabalho (workload ) ingressante, de acordo com a função que exerce. Entende- se por workload uma requisição de um usuário por um serviço encadeado que irá gerar ocupação de largura de banda disponível nos enlaces que interliguem as funções da SFC determinada pelo tamanho da requisição, além da ocupação de recursos computacionais em cada uma das funções da cadeia de serviços em sequência para seu processamento completo. Por exemplo, numa SFC composta por uma função NAT e um inspecionador de pacotes, o workload ingressará primeiro no NAT, que traduzirá seu endereço de rede. Após concluído seu processamento, o workload é encaminhado para a VNF de inspeção de pacotes, que verificará seu conteúdo na procura por dados potencialmente maliciosos.

Cada VNF possui um requisito de processamento por workload diferente, uma vez que se supõe ser mais complexo executar a inspeção de um pacote do que apenas traduzir um endereço de rede. Assim sendo, cada função não só possui características de hard-

ware diferentes como também um mesmo workload vai levar um tempo diferente para ser processado em cada VNF, a depender da complexidade de sua função. Desta forma, se uma instância de uma das funções da cadeia apresentar, por exemplo, sobrecarga de ocupação no seu núcleo de CPU reservado, como consequência os workloads passantes por ela terão sua conclusão atrasada, o que levará ao aumento no atraso fim-a-fim total dos consumidores deste serviço.

Esta tese de doutorado vai considerar o consumo de CPU das funções virtualizadas como métrica de referência para as tomadas de decisão de elasticidade horizontal e vertical. Como cada função pode apresentar uma diferente carga de consumo de CPU para uma mesma vazão, variando de acordo com a complexidade da função exercida, essa proposta considera a premissa de que é possível inferir um requisito de processamento de acordo com o tráfego ingressante. Tal premissa é assumida na maioria dos trabalhos relacionados e pode ser reforçada pelos trabalhos [53] e [54], onde ambos apresentam modelos capazes de estimar o consumo de CPU de acordo com o tráfego utilizando métodos baseados em aprendizagem de máquina.

Sendo possível determinar a ocupação de CPU em função do tráfego, conhecendo antecipadamente a demanda para cada cadeia de serviços, supõe-se que isso permitirá antecipar o consumo de CPU gerado sobre as instâncias. Desta forma, estabelecendo um limiar máximo de ocupação que seja considerado seguro para o processamento dos workloads sem atraso considerável, podemos antecipar decisões de elasticidade. Além de permitir a manutenção do desempenho dos serviços em execução, o ARENA também habilita o gerenciamento de custos sobre a utilização na estratégia horizontal, desativando instâncias não utilizadas em momentos de baixa demanda e desligando os servidores que não possuam instâncias ativas numa determinada janela de tempo.

Uma vez apresentadas as principais premissas assumidas no contexto deste trabalho, as sessões a seguir têm por objetivo descrever os modelos de dimensionamento horizontal e vertical que serão adotados nesta tese para nossa abordagem proativa de elasticidade.

4.1.3.1 Elasticidade horizontal do ARENA

Conforme mencionamos na seção 4.1.3, consideramos nesta tese a premissa da possi- bilidade de mapeamento entre a vazão ingressante e o consumo de CPU gerado sobre as funções. É esperado que cada VNF possua complexidade distinta dependendo da função que executa, de maneira que um workload na direção de uma SFC vai apresentar diferen- tes requisitos de processamento sobre cada uma das funções da cadeia, levando tempos

distintos para serem processados e gerando diferentes níveis de ocupação de CPU.

Assim sendo, cada VNF possuirá um requisito de processamento unitário (Process Requirement Unit (PRU) ), conceito extraído de [55], definido a partir das especificações oficiais de middleboxes comerciais, dado pela razão do número de núcleos de CPU e o fluxo suportado pela middlebox. Apesar de ser um valor estimativo, permite diferenciar VNFs de processamento mais oneroso como um inspecionador de pacotes daquelas que executam funções mais simples, como um firewall.

Desta forma, um workload w de tamanho b vai gerar uma ocupação mínima minOccup em uma VNF de x núcleos de vCPU’s de y MIPS, segundo a seguinte equação:

minOccup = P RU

nCores ∗ M IP S (4.1)

Onde:

minOccup – Ocupação mínima gerada por um workload sobre uma VNF

PRU – Requisito de Processamento Unitário

nCores – Quantidade de núcleos de vCPU da VNF

MIPS – Capacidade de Processamento da vCPU

Para melhor descrever a aplicação destes valores, suponhamos um workload ingres- sante de tamanho b = 1M bit que exerce P RU de 1% sobre uma VNF. Uma vazão de 90 Mbps (ou seja, 90 workloads ingressando por segundo) geraria uma ocupação de 90% sobre a vCPU desta função. Considerando que uma função cuja ocupação de vCPU co- mece a se aproximar de 100% vai gerar atraso no processamento dos pacotes, definimos um limiar máximo de ocupação maxOccupT hr que será utilizado para o cálculo do nú- mero de instâncias necessárias para lidar com a demanda prevista sem sobrecarregar o processamento das instâncias.

Tomando como base os mesmos dados utilizados no exemplo anterior, se tivéssemos uma demanda prevista de 120 Mbps, teríamos uma ocupação de 120% na vCPU da função hipotética, mas se tivéssemos duas instâncias dividindo o processamento da mesma quantidade de workloads, alcançaríamos uma ocupação média por segundo de 60% sobre ambas as vCPU’s. Assim sendo, para calcular o número de workloads que uma função pode suportar até atingir seu limiar máximo de ocupação, temos:

maxW kl = maxOccupT hr

minOccup (4.2)

Onde:

maxOccupThr – Limiar máximo de ocupação de vCPU em uma VNF

Se temos um limiar máximo de ocupação de 90%, por exemplo, para uma PRU de 1%, tal função suportaria no máximo 90 workloads de 1Mbps. Uma vazão de 180 Mbps indicaria a necessidade de duas instâncias para lidar com tal demanda, isto é, as duas instâncias desta mesma função com esses requisitos conseguiriam processar a demanda consumindo até o máximo de vCPU que lhes são permitidas. Desta forma, determinamos o número de instâncias para cada função de acordo com a demanda pela equação, assumindo que o tamanho dos workloads (sizeW orkload) é fixo para todos eles:

numInst = demand

maxW kl ∗ sizeW kl (4.3)

Onde demand pode ser considerada sob diferentes janelas de tempo, logo, para uma janela w temos:

numInstw =

demandw

maxW kl ∗ sizeW kl (4.4)

Onde:

demandw – Demanda prevista para uma janelaw

sizeWkl – Tamanho fixo do workload

O algoritmo 1 apresenta as equações na sequência em que são realizadas para a defi- nição do número de instâncias de cada uma das VNFs que compõem uma SFC a partir de um valor estatístico oferecido pelo preditor de demanda para a próxima janela de decisão do auto-scaling horizontal.

Nesse sentido, espera-se que cada novo valor estatístico representativo da janela ofe- recido pelo mecanismo de predição de demanda e entregue para o módulo de elasticidade na abordagem horizontal determine o número de instâncias de cada VNF da cadeia de serviços.

Algoritmo 1 Definição do número de instâncias para cada VNF (Auto-scaling Horizontal) Entrada: SF C - Conjunto dos serviços ofertados

Entrada: vnf - Conjunto das funções que compõem cada SF C

Entrada: demand - Demanda prevista para a próxima janela de planejamento Entrada: sizeW kl - Tamanho fixo do workload

1: para cada sf ci in SF C faça

2: para cadavnfj in sf ci faça

3: minOccup ← P RU(vnfj)

coresP erM IP S(vnfj)

4: maxW kl ← maxOccupT hr_minOccup 5: numInst_vnfj ← _{maxW kl}demand

∗sizeW kl

6: fim para

7: fim para

4.1.3.2 Elasticidade vertical do ARENA

Para o problema da elasticidade vertical, o objetivo do ARENA será determinar o número de vCPUs que a VNF deve ter para lidar com a demanda prevista sem que a ocupação exceda o limiar máximo (maxOccupTh). Nesse sentido, assumindo workloads de tamanho fixo (sizeW orkload) e uma demanda prevista para uma janela específica (demand) e o valor de ocupação mínima que um workload causa sobre uma VNF específica (minOccup, equação 4.1), a ocupação prevista para a VNF é dada por:

predOccup = demand ∗ minOccup

sizeW kl (4.5)

Desta forma, assumindo uma lista finita de opções de modelos de VNFs de diferentes quantidades de vCPUs em sua especificação, onde cada modelo terá seu próprio valor de ocupação mínima (minOccup) de acordo com seu número de núcleos e de M IP S por núcleo, o modelo escolhido será aquele de menor número de vCPUs cuja ocupação prevista (predOccup) estiver situada entre o limiar máximo maxOccupT h e um limiar mínimominOccupT h.

O algoritmo 2 lista a sequência de passos para definição do número de vCPUs para cada VNF que compõe uma SFC, a partir de um valor de demanda predito. Suponhamos quef lavours seja o conjunto finito de especificações possíveis para uma VNF que vai de um número mínimo até um número máximo de vCPUs. A decisão de auto-scaling se dará a partir de um valor de demand oferecido pelo preditor que será usado para calcular a ocupação esperada (predOccup, linha 4) sobre uma VNF de acordo com suas configurações atuais. A partir desse valor esperado de ocupação, se for maior do que o limiar máximo definido (linha 5) inicia-se um processo para encontrar o flavour que permitirá alcançar

Algoritmo 2 Definição do número de vCPU para cada VNF (Autoscaling Vertical) Entrada: SF C - Conjunto dos serviços ofertados

Entrada: vnf - Conjunto das funções que compõem cada SF C

Entrada: demand - Demanda prevista para a próxima janela de planejamento Entrada: f lavours - Conjunto dos diferentes flavours para cada VNF

Entrada: sizeW kl - Tamanho fixo do workload

Entrada: maxOccupT h - Limiar máximo de ocupação das VNFs

1: para cada sf ci in SF C faça

2: para cadavnfj in sf ci faça

3: minOccup ← P RU(vnfj)

coresP erM IP S(vnfj)

4: predOccup ← demand_{sizeW kl}∗minOccup

5: se predOccup >= maxOccupTh então

6: numCores_vnfj ← next(f lavour_{vnf j}) 7: minOccup ← _{coresP erM IP S(vnf}P RU(vnfj)

j,numCores_vnfj)

8: predOccup ← demand∗minOccup

sizeW kl

9: enquanto(predOccup <= maxOccupT h e predOccup > minOccupT h) faça

10: se next(f lavourvnf j) > maxvCP U então

11: numCores_vnfj ← next(f lavour_{vnf j})

12: fim se

13: fim enquanto

14: senão

15: enquanto (predOccup < maxOccupT h) faça

16: se prev(f lavourvnf j) > minvCP U então

17: numCores_vnfj ← prev(f lavour_{vnf j})

18: minOccup ← P RU(vnfj)

coresP erM IP S(vnfj,numCores_vnfj)

19: predOccup ← demand_{sizeW kl}∗minOccup

20: fim se

21: fim enquanto

22: fim se

23: fim para 24: fim para

uma ocupação abaixo da máxima mas não menor do que uma mínima permitida (linha 9).

Assim sendo, o novo valor de vCPU (obtido a partir de next(f lavourvnfj) no algo-

ritmo) será o primeiro que alcançar uma ocupação dentro do limite definido na linha 9 ou o maior flavour possível, limitado por maxvCP U. O algoritmo também considera a definição de um valor mínimo possível de vCPU, limitado por minvCP U, que possa lidar com a demanda futura (linhas 15-19) a fim de permitir a redução com os custos de aluguel das instâncias. Caso o servidor hospedeiro não apresente capacidade física suficiente para acomodar o novo flavour escolhido para a VNF, o ARENA deve iniciar o processo de migração desta instância para outro servidor com as condições necessárias.