Trabalhos Relacionados

Nesta Seção abordamos os trabalhos mais relevantes no campo de pesquisa desta dissertação. Na Seção 3.1.1 analisamos os trabalhos relacionados ao network slicing e cloud slicing, examinando as principais propostas relacionadas a interoperabilidade e integração da nuvem e rede. Já na Seção 3.1.2 analisamos os principais mecanismos de elasticidade que podem ser aplicados em um cenário de cloud-network slicing, averiguando como estes mecanismos atuam em cenários com insuficiência de recursos.

3.1.1

Infraestruturas de Network Slicing e Cloud Slicing

Diferentes trabalhos têm buscado propor soluções para os casos de uso relacionados ao 5G, onde grande parte dos esforços estão direcionados ao network slicing (AFOLABI et al., 2018). Atualmente, inúmeras iniciativas 5G da indústria e da academia propuseram novas arquiteturas para o cenário 5G envolvendo o slicing da rede. Nesta perspectiva, existem diversos projetos focados no gerenciamento e orquestração para redes 5G. Alguns destes projetos endereçam o gerenciamento e orquestração de network slices. Na litera- tura atual, evidencia-se que os projetos mais estritamente centrados nas soluções para o network slicing são 5PAGODA (AFOLABI et al., 2017), SLICENET (LORENZ et al., 2018), 5GMoNarch (MUMFORD, 2017), SONATA (SONATA, 2015), 5G NORMA (GRAMAGLIA et al., 2016), 5G TRANSFORMER (OLIVA et al., 2018), 5GEx (5GEX, 2015).

Tecnologias para a habilitação do slicing em redes 5G são amplamente discutidas no contexto atual. O uso de NFV para credenciar o network slicing é investigado por Chatras, Kwong e Bihannic (2017), sendo argumentado que a NFV irá desempenhar uma regra proeminente para a implementação do conceito de network slicing. De forma semelhante, Lin e Zhou (2018) também discutem o uso de NFV para o slicing das redes 5G, provendo um estudo baseado na limitação de recursos físicos. O uso de SDN e NFV para o slicing de redes 5G também é explorado por Ordonez-Lucena et al. (2017), abordando cenários que combinam tecnologias SDN e NFV para habilitar o network slicing. O slicing fim-a-fim das redes 5G com múltiplos-inquilinos, também baseado em SDN e NFV é abordado por (CHARTSIAS et al., 2017). Um framework baseado em SDN e NFV para o gerenciamento e implantação de serviços 5G é proposto por (MA et al., 2018). Outrossim, muitos projetos de pesquisa no âmbito 5G (por exemplo, 5GEx, 5GPAGODA, 5GNORMA e 5GinFIRE) estão endereçando a realização do network slicing através da combinação de SDN e NFV.

Os autores do trabalho Galis e Kukliński (2017) explora como os paradigmas de com- putação podem estender a visão do network slicing para data centers. A partir disso, os autores de Toosi et al. (2018) examinam como a tecnologia network slicing pode ser expan- dida além de redes em data centers, com foco em múltiplas nuvens. Novas abordagens para o network slicing utilizam recursos nativos da nuvem para estenderem a aplicabilidade das soluções do network slicing.

Cenários e tecnologias tem sido propostos para lidar com os novos requisitos da pró- xima geração de infraestruturas para data centers. A exploração de mecanismos, com- ponentes e abstrações que podem ser utilizados para incluir o network slicing em um cenário maior envolvendo nuvens é examinado por Clayman, Tusa e Galis (2018), visando realizar o slicing em infraestruturas de data centers como parte de uma infraestrutura NFV completa, garantindo que os recursos prescritos para network slices sejam aplicáveis dentro dos data centers. Extensões também vem sendo investigadas para orquestração de recursos em data centers visando prover uma integração entre a orquestração da nuvem juntamente com a rede através de cenários virtualizados (SPADARO et al., 2017). A inte- roperabilidade de infraestruturas de nuvem e rede é explorada por Martínez et al. (2018) visando prover a alocação de recursos para network slices.

O projeto NECOS (Novel Enablers para Cloud Slicing) (SILVA et al., 2018) apresenta- se como iniciativa única no cenário atual para lidar com as limitações de infraestruturas de computação em nuvem e redes softwarizadas, como forma de responder eficientemente às rigorosas demandas de casos de uso 5G futuristas. A plataforma NECOS embarca

tecnologias que interoperam para o particionamento (slicing) de infraestruturas de nuvem e de rede subjacentes de forma acoplada, constituindo-as em fatias de nuvem (cloud slices) conectadas por fatias de rede (network slices espalhadas por diferentes data centers e com alto nível de isolamento. Como resultado, as peças selecionadas são combinadas em instâncias de fatias de nuvem e de rede de ponta a ponta (end-to-end cloud-network slices), que devem ser oferecidas como serviço para ocupação sob demanda. Entre outros recursos descritos em (SILVA et al., 2018), a abordagem NECOS introduz novos mecanismos de elasticidade para atender aos requisitos de fatias da rede na nuvem.

3.1.2

Mecanismos de Suporte à Elasticidade

Atualmente, mecanismos de elasticidade que usam políticas para atuar de forma rea- tiva são amplamente utilizadas para a tomada de decisão em ambientes de computação em nuvem. Todavia, até onde se sabe não existe um estudo aprofundado sobre o comporta- mento de abordagens reativas em cenários com insuficiência de recursos, apesar da difusão desta técnica no mercado de nuvem. Neste sentido, esta Seção objetiva analisar cautelo- samente a eficiência e as limitações dos mecanismos que fazem uso desta abordagem em um cenário de provisionamento automático de recursos com escassez de recursos.

Segundo Farokhi et al. (2015), o desempenho da técnica baseada em threshold é al- tamente dependente dos parâmetros selecionados. No entanto, apesar de criticada em termos de desempenho, devido a sua facilidade de implantação a abordagem reativa ainda é bastante explorada por muitas das iniciativas comerciais como Amazon AWS (JEFF BARR, 2018), Azure (AZURE, 2018), Google Cloud Platform (GOOGLE, 2018a). Sistemas de gerenciamento de containers como Kubernetes, Swarm e Apache Mesos tam- bém usam esta abordagem.

A plataforma da Amazon EC2 AWS oferece uma técnica de auto-scaling denominada target tracking scaling (TTS), que é capaz de dinamicamente prover o ajuste de recursos baseados em um valor para uma métrica específica (AMAZON AWS, 2018). O algoritmo do TTS é baseado em regras e pode ser aplicado em containers e máquinas virtuais usando a elasticidade horizontal. Já o Google Cloud Platform suporta um mecanismo de auto- scaling denominado Multiple Polices – MP para usar múltiplas políticas de elasticidade individualmente em diferentes níveis (GOOGLE, 2018c). O algoritmo MP calcula o número de instâncias necessárias recomendadas por cada política e, em seguida, escolhe a diretiva que deixa o maior número de instâncias no cluster. O mecanismo do MP usa a abordagem reativa e elasticidade horizontal. Da mesma forma, o Kubernetes usa uma abordagem de

elasticidade horizontal que controla um algoritmo em loop baseado principalmente no uso de CPU (GOOGLE, 2019). O algoritmo denominado Horizontal Pod Autoscaler – HPA é capaz de aumentar ou diminuir o número de instâncias de containers tendo como base a média de uso de CPU ou memória RAM. O valor definido para disparar a elasticidade é de 80%.

Al-Sharif et al. (2017) apresentaram um framework denominado ACCRS (Autonomic Cloud Computing Resource Scaling) para provisionar um número suficiente de máquinas virtuais, visando atender às necessidades variáveis de recursos de aplicações diversas. A abordagem de adaptação proposta usa um conjunto de thresholds estáticos para CPU, memória RAM e largura de banda, visando avaliar estados de recursos em tempo de execução. O mecanismo do ACCRS usa uma abordagem reativa e elasticidade vertical.

Al-Dhuraibi et al. (2017) propõem um mecanismo para elasticidade vertical de forma autônoma em docker containers. A proposta realiza o scale up e scale down de recursos de CPU e memória RAM de cada container, de acordo com a carga de trabalho. Além disso, fazem uso de uma melhor utilização de recursos ao passo que aumentam a qualidade de experiência para aplicações de usuários finais. Quando não existem recursos suficientes para realizar a elasticidade, a técnica de live migration é utilizada.

O trabalho de Kan (2016) propõe uma plataforma de nuvem baseada no Docker com suporte a elasticidade horizontal. O mecanismo empregado nesta abordagem permite adi- cionar ou remover instâncias de containers para adaptar a carga de trabalho de aplicações web. O modelo reativo, elaborado pelos autores, considera um limite superior para cada container, sendo que ao ser atingido, uma nova réplica do container é feita. Além disso, um limite inferior também é definido para saber quando remover instâncias que não estão sendo utilizadas.

Já o trabalho de Kumar e Gondhi (2017) propõe uma abordagem de elasticidade com um modelo de provisionamento dinâmico para a alocação de recursos de forma reativa, levando em consideração o QoS. O mecanismo realiza correções de recursos em máquinas virtuais, considerando cenários de subutilização e utilização excessiva de recursos para realizar a elasticidade horizontal. Além disso, demonstram que o número de violações de SLA é reduzido quando comparado a abordagens de elasticidade estáticas.

Um algoritmo para o controle de elasticidade é proposto por (RIGHI et al., 2018). O algoritmo usa a técnica de live thresholds e é baseado no mecanismo de congestionamento do protocolo TCP que gerencia automaticamente o valores dos limites de elasticidade para melhorar a reatividade no provisionamento de recursos. O modelo de elasticidade tratado

neste trabalho fornece elasticidade horizontal através de um modelo híbrido, embora ba- seado em thresholds, para lançar ações de elasticidade reativamente, visando adaptar em tempo de execução seus valores e fornecer uma melhor reatividade de elasticidade.

Righi et al. (2016) propõem o AutoElastic, um modelo de elasticidade voltado a PaaS. O diferencial desta abordagem consiste em prover elasticidade para aplicações de alta per- formance sem intervenção do usuário. O mecanismo do AutoElastic provê uma abordagem baseada em envelhecimento para ações de alocação e desalocação de recursos, para evitar reconfigurações desnecessárias de máquinas virtuais. Além disso, o AutoElastic oferece elasticidade vertical automática e reativa.

3.2

Discussão

Como visto na Seção 2.2.2, os mecanismos de elasticidade podem ser classificados de diversas formas e podem utilizar várias técnicas no processo de tomada de decisão. A Tabela 1 a seguir sumariza as principais características dos mecanismos mais recentes analisados na Seção 3.1.2. Os principais requisitos analisados durante as comparações consistem em: (i) elasticidade vertical, (ii) modelos estocásticos, (iii) modelos estatísticos e (iv) atuação sob exaustão de recursos.

Mecanismo Elasticidade Modelo Modelo Atuação

Vertical Estocástico Estatístico Sob Exaustão de Recursos SLOTS 3 3 3 3 Amazon AWS _{7 3 7 7} Google Cloud 7 3 7 7 Kubernetes _{7 3 7 7} Docker Swarm _{7 3 7 7} Apache Mesos _{7 3 7 7} (Al-Sharif, 2017) _{3 3 7 7} (Al-Dhuraibi, 2017) 3 3 7 7 (Kan, 2016) _{7 3 7 7} (Kumar, 2017) 7 3 7 7 (Righi, 2018) _{7 3 7 7} (Righi, 2016) _{3 3 7 7}

Tabela 1: Comparação entre as principais soluções para elasticidade vertical de nuvem em detrimento da proposta SLOTS

Como principal ponto de análise, constata-se que as abordagens de elasticidade atuais sempre operam bem em cenários com recursos disponíveis. Todavia, quando a escassez de recursos é atingida, técnicas ou estratégias são necessárias para que novos recursos sejam disponibilizados, fazendo com que as abordagens de elasticidade possam continuar a pro- visionar os recursos necessários para manutenção de serviços, aplicações, infraestrutura, etc. Uma técnica bastante utilizada é a live migration, tanto para ambientes virtualizados que usam máquinas virtuais ou containers. Outra opção seria estender a infraestrutura existente, adicionando novos servidores. Abordagens usadas pelas plataformas de gerenci- amento de containers tentam balancear o uso de recursos dos nodos de um cluster através do balanceamento de carga, contudo, se o cluster estiver sobrecarregado, a elasticidade não pode ser realizada. De acordo com o mencionado, as soluções de elasticidade exis- tentes requerem obrigatoriamente recursos disponíveis para manter o nível de qualidade oferecido pelos mecanismos de elasticidade.

Diante do exposto, verifica-se que os principais mecanismos reativos não conseguem realizar a elasticidade quando recursos não estão disponíveis e nem sequer oferecem so- luções que busquem minimizar o impacto ocasionado pela insuficiência de recursos. Para contornar este problema, o SLOTS tenta minimizar o impacto causado pela insuficiência de recursos através da análise dos recursos alocados que estão sub-utilizados. Tal fato ocorre devido a necessidade de alocar sempre mais recursos que uma aplicação ou serviço necessita, pois se esta alocação não for realizada, os mecanismos de elasticidade precisa- riam realizar operações constantemente, além de necessitarem aplicar este procedimento em uma grande quantidade de serviços ou aplicações, tornando inviável que tais aborda- gens sejam utilizadas no contexto atual. Se os recursos alocados forem muito próximos a quantidade usada pelas aplicações ou serviços, pode ser que uma requisição por mais recursos não seja atendida de forma automática, prejudicando assim a performance destas aplicações ou serviços.