Chapter 6: Serviço Gerenciado na Nuvem

Este capítulo descreve como juntar todas as peças descritas nos capítulos anteriores para prover a conectividade do 5G como um serviço em nuvem. Tal serviço pode ser implementado em empresas, por exemplo, na coleção de dados operacionais, vídeo, robôs, equipamentos IoT, e assim por diante - um conjunto de casos de uso algumas vezes chamados de Indústria 4.0.

O primeiro passo é implementar todos os componentes usando blocos nativos da nuvem. Começamos pela introdução de blocos fundamentais na Seção 6.1. O segundo passo é introduzir novamente outro componente - uma Plataforma de Gerenciamento na Nuvem - isto é responsável pela operacionalização do 5G como serviço. O resto das seções descreve como construir um sistema de gerenciamento usando ferramentas de código aberto.

Antes de entrar em detalhes, é importante lembrar que o serviço móvel celular (voz e banda larga) tem sido oferecido por serviços de telecomunicações por 40 anos. Tratar com um serviço gerenciado de nuvem é um ponto de partida significativo desta história, mais notável é como a conectividade provida é operada e gerenciada. Como uma consequência, a Plataforma de Gerenciamento de Cloud descrita neste capítulo é significantemente diferente mecanismos de OSS/BSS legados que tem tradicionalmente sido a contrapartida do maquinário de gerenciamento das empresas de Telecom. A terminologia também é diferente, mas isto somente importa se você está tentando mapear a terminologia das empresas de telecomunicações na terminologia em nuvem (o que não faremos). Tomaremos “a terminologia de mapeamento de problema” de outro livro, e focamos no projeto do zero baseado em nuvem.

Leitura Adicional

L. Peterson, A. Bavier, S. Baker, Z. Williams, and B. Davie. Edge Cloud Operations: A Systems Approach. June 2022.

6.1 Blocos Básicos

A estratégia de implementação começa com o hardware comercial e software de código aberto. Estes blocos básicos serão familiares para aqueles que construíram uma aplicação nativa da nuvem, mas eles merecem ser explicitamente nomeados em uma discussão em uma rede celular móvel, que tem historicamente sido construída usando equipamentos de hardware fechados e proprietários.

Os blocos básicos de hardware incluem servidores e switches físicos, que incluem chips com processadores ARM o x86 e chips de chaveamento Tomahawk ou Tofino, respectivamente. Uma nuvem física é então construída com os blocos básicos de hardware organizados como mostrado Figure 39: um ou mais racks ou servidores conectados por uma estrutura de switches interconectados. Mostramos o conjunto de servidores para enfatizar que o software rodando neles controla os switches (como veremos na próxima seção).

_images/Slide41.png

Figure 39. Exemplo de blocos básicos usados para construir uma nuvem na borda, incluindo os servidores e switches, interconectados por uma espinha dorsal formada por switches.

Os blocos básicos que começam com o seguintes componentes de código livre:

  1. Funcionalidades de pacotes de software para Container Docker.

  2. Kubernetes instanciados e interconectados a um conjunto de containers.

  3. Helm especificando como as coleções de containers relacionados são conectados para construir um aplicação de microsserviços.

  4. Fleet específica como um conjunto de aplicações de Kubernetes devem ser instalados na infraestrutura disponível.

  5. Terraform provisiona um conjunto de um ou mais clusters de Kubernets, configurando-os para prover as aplicações dos microsserviços.

Docker é um executor de container que aproveita a isolação das APIS do sistema operacional para instanciar múltiplos contêineres, cada um com uma instância definida por uma imagem de Docker. Imagens do Docker são mais frequentemente construídas usando um Dockerfile, que usa a abordagem de camadas para permitir compartilhamento e imagens customizadas no topo de imagens base. Um imagem final para uma tarefa particular que incorpora todas às dependência é requerida pelo software que está executando no contêiner, resultando na imagem do contêiner que é portável em vários servidores, dependendo das imagens somente do kernel e do Docker runtime. Também assumimos um ou mais repositórios de imagens de artefatos dos containers Docker que esperamos desenvolver ou instalar na nuvem, dentre os quais https://hub.docker.com/ é o exemplo mais conhecido.

Leitura Adicional

Docker Tutorial.

Kubernetes é um sistema de gerenciamento de contêineres. Ele provê uma interface programável para o escalonamento up e down de contêineres, alocando recursos de servidores a eles, configurando redes virtuais para interconectar essas instâncias, e abrindo portas de serviço para clientes externos acessarem essas instâncias. Por detrás, Kubernetes monitora a vida dos contêineres, e automaticamente reinicia aqueles que falharam. Em outras palavras, se você instruir o Kubernetes a rodar três instâncias do microsserviço X, Kubernetes irá fazer o melhor para manter essas três instância do contêiner que implementa X rodando todo o tempo.

Leitura Adicional

Kubernetes Tutorial.

Helm é um gerenciador que roda sobre Kubernetes. Ele resolve questões contra a API do Kubernetes API de acordo com a especificação do desenvolvedor, conhecida como Helm Chart. É uma prática comum para aplicações na nuvem construir um conjunto de microsserviços para publicar um Helm chart que define como as aplicações serão desenvolvidas em um cluster Kubernetes. Veja https://artifacthub.io/ para uma coleção de Helm Charts disponíveis publicamente.

Leitura Adicional

Helm Tutorial.

Fleet é um gerenciador de implantação de aplicação que é responsável por instalar um Pacote (Bundle) do Helm Charts em um ou mais clusters alvo. Se estamos tentando implementar um único Chart em um cluster Kubernetes, então Helm pode ser suficiente. O valor do Fleet é que escala este processo, nos ajudando a gerenciar a implantação de múltiplos charts em múltiplos clusters. Entretanto, Fleet faz isto usando uma abordagem conhecida como Configuração-como-Código, na qual a configuração desejada é verificada em um repositório, como qualquer outro software. Encontrando um Bundle novo ou atualizado no repositório inicia a implantação da aplicação correspondente.

Leitura Adicional

Fleet: GitOps at Scale.

Terraform é um gerenciador de infraestrutura que, no nosso cenário, provê um ou mais cluster de Kubernetes, os preparando para uma coleção de aplicações especificadas pelo Helm-specified. Ele faz isso usando uma abordagem conhecida como Infraestrutura-como-Código, que documenta exatamente como a infraestrutura é configurada em um formato declarativo que pode ser (a) verificado em um repositório, (b) versão controlada, e (c) executada como qualquer peça de software. Terraform assume que API de provisionamento, como o Microsof Azure Kubernetes Service (AKS), AWS Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) e Ranchers Rancher Kubernetes Engine (RKE) exemplos.

Leitura Adicional

Terraform Tutorials.

Os papéis inter-relacionados do Helm, Fleet, e Terraform podem ser confundidos, em parte porque existe uma sobreposição entre o que cada um tenta fazer. Uma distinção é que os Helm Charts são tipicamente especificados pelos desenvolvedores como uma forma de especificar como uma aplicação é construída a partir de um conjunto de microsserviços, enquanto Fleet e Terraform dá aos operadores a oportunidade de especificar os detalhes de um cenário de implementação em particular. Uma segunda distinção é que Helm e Fleet ajudam a gerenciar as aplicações rodando em um ou mais clusters Kubernetes, enquanto Terraform é usado para obter e configurar o cluster Kubernetes base em primeiro lugar. Novamente, existe uma sobreposição nestas ferramentas, mas estas duas distinções caracterizam como eles são usados no Aether. A observação mais geral é que o gerenciamento na nuvem tem que acomodar ambos os desenvolvedores e os operadores, a claramente delinear a linha entre aplicações e plataformas.

6.2 Exemplo de Implementação

Usando estes blocos básicos, é possível construir uma grande variedade de cenários de implementação para um serviço 5G gerenciado. Para fins de ilustração, usamos uma implementação particular baseada na nuvem Aether introduzida no Capítulo 2. Aether é uma nuvem de borda operacional que tem sido implementada em vários sites, e mais importante para nosso propósito, inclui uma API que apps de borda podem usar para customizar a conectividade 5G para melhor atingir seus objetivos.

6.2.1 Nuvem na Borda

Uma implementação na borda do Aether, chamada de ACE (Aether Connected Edge), é um cluster baseado em Kubernetes. Ele consiste de um ou mais racks de servidores interconectados por uma espinha dorsal formada por switches, com um plano de controle SDN (denotado por SD-Fabric) gerenciando o conjunto. Falamos sobre o SD-Fabric no Capítulo 5 como uma opção de implementação da User Plane Function (UPF) do Core, mas para uma descrição mais detalhada do SD-Fabric, nos referimos a nosso livro.

Leitura Adicional

L. Peterson, C. Cascone, B. O’Connor, T. Vachuska, and B. Davie. Software-Defined Networks: A Systems Approach. November 2021.

_images/Slide51.png

Figure 40. Aether Connected Edge (ACE) = Uma plataforma em nuvem (Kubernetes e SD-Fabric) mais o serviço de conectividade do 5G (RAN e User Plane do Mobile Core). Linhas pontilhadas (e.g., entre SD-RAN e às estações base individuais, e entre o OS de Rede e o switch individual) representa relações de controle (e.g., SD-RAN controla as small cells e o SD-Fabric controla os switches).

Como mostrado na Figure 40, ACE suporta dois subsistemas baseados em microsserviços; eles coletivamente implementam um 5G como um serviço. O primeiro subsistema, SD-RAN, é uma implementação baseada em SDN da Rede de Acesso de Rádio (RAN) descrita no Capítulo 4. Ele controla as estações base de small cell implementadas na empresa. O segundo subsistem, SD-Core, é uma implementação baseada em SDN da parte de Core que é o User Plane descrito no Capítulo 5. Ele é responsável por encaminhar o tráfego entre a RAN e a Internet. O Plano de Controle (CP) do SD-Core roda off-site, e não é mostrado na Figure 40. Ambos os subsistemas (como também o SD-Fabric), são implementados como um conjunto de microsserviços, exatamente como qualquer outra aplicação nativa na nuvem.

Uma vez que um cluster de borda está rodando nesta configuração, ele está pronto para hospedar uma coleção de aplicações nativas da nuvem (não mostradas na Figure 40). O que é único neste exemplo de configuração é a habilidade de conectar essas aplicações aos serviços móveis da empresa usando a conectividades 5G implementada pelo SD-RAN e SD-COre, sem o tráfego resultante sair da empresa; um serviço conhecido como local breakout. Entretanto, este serviço é oferecido como um serviço gerenciado, com os administradores da empresa sendo hábeis a utilizar API programáveis (e associadas como o portal GUI) para controle o serviço; isto é, equipamentos autorizado, acesso restrito, perfis de QoS para diferentes equipamentos e aplicações, e assim por diante.

6.2.2 Núvem Híbrida

Enquanto é possível instanciar um único cluster ACE em um site, Aether é projetado para suportar múltiplas instalações de borda, todas gerenciadas do cloud central. Este cenário de cloud híbrida está descrita na Figure 41, que mostra dois subsistemas rodando no mesmo cloud central: (a) uma ou mais instâncias do Plano de Controle de Cloud, e (2) a Plataforma de Gerenciamento do Aether (AMP).

Cada SD-Core CP controla uma ou mais SD-Core UPFs. Exatamente como as instância do CP (rodando centralmente) são pareadas com instâncias UPF (rodando nas bordas) em uma decisão de tempo de execução, e dependem do grau de isolação que o site da empresa requer. AMP é a realização da Plataforma de Gerenciamento de Cloud do Aether; ela é responsável pelo gerenciamento centralizado dos subsistemas de borda ( como introduzido na próxima seção).

_images/Slide61.png

Figure 41. Aether roda em um configuração de cloud híbrida, com o Plano de Controle do Core e a Plataforma de Gerenciamento Aether (AMP) rodando na Cloud Central.

Há um aspecto importante nesta cloud híbrida que não é óbvio na Figure 41, quando citamos “cloud híbrida” é melhor descrever como um conjunto de clusters de Kubernetes, ao invés de um conjunto de clusters físicos. Isto porque, enquanto cada site ACE usualmente corresponde a um cluster físico construído em componentes físicos, cada subsistema CP do SD-Core mostrado na Figure 41 é atualmente implementado em um cluster de Kubernetes lógicos em uma cloud comercial. O mesmo é verdade para o AMP. Os componentes centralizados do Aether conseguem rodar em um Google Cloud Platform, Microsoft Azure, e Amazon AWS. Eles também rodam em um cluster emulado implementado por um sistema como KIND (Kubernetes in Docker), tornando possível para desenvolvedores rodar estes componentes nos seus laptops.

6.2.3 Stakeholders

Com o entendimento que nosso ambiente objetivo é uma coleção de clusters de Kubernetes - alguns rodando em hardware físicos e sites de borda e outros rodando em datacenters - existe uma questão crucial de como a responsabilidade pela tomada de decisão para esses cluster é compartilhada entre os múltiplos stakeholders. Identificar cada stakeholders relevante é um pré-requisito importante para estabelecer um serviço em cloud, e mesmo sabendo que nosso exemplo não é adequado para todas as situações, ele serve para ilustrar as implicações de projeto.

Para o Aether, nos preocupamos com dois stakeholders primários: (1) o operador da cloud que gerencia a cloud híbrida como um todo, e (2) os usuários da empresa que decidem considerando cada site como tomar vantagem dos recursos da cloud local (e.g., qual aplicação de borda rodar e como dividir os recursos de conectividade com estes apps). Chamaremos de “admins da empresa” para distinguir dos “usuários finais” que desejam gerenciar seus próprios equipamentos.

Aether é multi-tenant no sentido que ele autentica e isola estes stakeholders, permitindo a cada um acessar somente os objetos que são de sua responsabilidade. Isso torna a abordagem agnóstica de como todos os sites de borda pertencem a uma única organização (com a organização sendo também responsável pela operação da cloud), ou alternativamente, sendo uma organização em separado que oferece um serviço gerenciado para um conjunto de empresas distintas (cada um atingindo um ou mais sites).

Existe um terceiro stakeholder — o provedor de serviço terceirizado - que aponta para o grande problema de como implementar e gerenciar aplicações na borda que tomam vantagem do 5G como um serviço. A abordagem que o Aether usa é esperar os provedores de serviço disponibilizarem suas aplicações tanto como um código fonte (que funciona para aplicações de código aberto ou in-house), ou como artefatos padrões nativos da cloud (e.g., imagens Docker e Helm charts). Ambos os formatos podem ser colocados no pipeline de Gerenciamento de Ciclo de Vida descrito na Seção 6.3.2. A alternativa pode ser para provedores de serviço de borda compartilharem a responsabilidade operacional sobre o cloud da borda com o operador de cloud, que é possível se a infraestrutura rodando na borda é multi-tenant ou um multi-cloud.

6.2.4 Configurações Alternativas

A implementação do Aether que acabamos de descrever está cheia de glória. Configurações simples também são possíveis, o que faz sentido em cenários menos exigentes. Exemplos incluem:

  • Cluster de borda pequenos podem ser construídos com somente um único switch (ou dois switches por resiliência), com ou sem um controle baseado em SDN. No limite, uma borda Aether pode rodar em um único servidor.

  • É possível substituir uma small cell legada por uma solução SD-RAN que inclui um near RT-RIC e os xApps associados.

  • É possível localizar ambos o AMP e o SD-Core CP no cluster de borda, resultando em uma implementação Aether completa que é auto-contida em um único site.

Estas são opções de configuração direta. Uma abordagem muito diferente é começar com um cluster de borda que é gerenciado por um dos super escalonadores, ao invés de ter uma provisão do Aether implementado em Kubernetes em máquinas físicas. Google Anthos, Microsoft Azure Arc, and Amazon ECS-Anywhere são exemplos de aplicações SD-Core e SD-RAN rodando sobre Kubernetes, mas não na plataforma de base (que pode ou não incluir um conjunto de switches baseados em SDN).

Outra variável em como o 5G pode ser implementado na borda está relacionado a quem pertence a infraestrutura base do cloud. Ao invés de um provedor de cloud, uma empresa, ou uma MNO tradicional proprietária do hardware, existem situações onde um terceira parte, normalmente chamda de host neutro*, é proprietária e opera o hardware (junto com a* imobiliária que ele está), e então aluga acesso acessos a esses recurso para múltiplos provedores 5G. Cada provedor do serviço móvel é então um inquilino de uma infraestrutura compartilhada.

Este tipo de arranjo existe há anos, embora com equipamentos convencionais da RAN, mas mudando para um projeto baseado em cloud torna possível para hosts neutros para alugar acessos a recursos de borda virtualizadas para seus usuários. Em princípio, a única diferença entre este cenário e as cloud multi-usuários atuais é que este provedores podem oferecer recursos de borda - localizados em torres celulares, prédios de apartamento, e centros urbanos densos - ao invés de recursos de datacenters. Os arranjos de negócios podem também ser diferentes para 5G Privados, mas o projeto técnico apresentado neste livro ainda se aplica.

6.3 Plataforma de Gerenciamento de Nuvem

Operacionalizando os componentes de hardware e software descritos nas duas seções anteriores é a essência do que significa um serviço 5G gerenciando. A responsabilidade é da Plataforma de Gerenciamento de Cloud, que no Aether corresponde ao componente AMP centralizado mostrado na Figure 41. AMP gerencia ambos o conjunto distribuído do cluster ACE e um ou mais cluster SD-Core CP rodando no cloud central.

A figura a seguir usa o AMP para ilustrar como entregar 5G como um serviço, mas a abordagem pode ser generalizada pois o AMP é baseado em ferramentas de código livre muito usadas. Para mais detalhes sobre todos os subsistemas envolvidos na operacionalização do clou na borda, veja o livro mencionado na introdução deste capítulo.

_images/Slide71.png

Figure 42. Os quatro subsistemas que compõem o AMP: Provisionamento de Recursos, Gerenciamento de Tempo de Vida, Orquestrados de Serviço, e Monitoramento e Telemetria.

No alto nível, AMP é organizada em torno de quatro subsistemas mostrados na Figure 42:

  • Provisionamento de Recursos (Resource Provisioning) é responsável pela inicialização de recursos (e.g., servidores, switches) que adicionam, repõem ou aumentam a capacidade. Ele configura e retém os recursos físicos e virtuais, trazendo-os para o estado tal que o Gerenciamento do Tempo de Vida pode tomar conta e gerencia os softwares rodando naqueles recursos.

  • Gerenciamento do Tempo de Vida (Lifecycle Management) é responsável pela integração contínua e implementação dos componentes de software que coletivamente implementam o 5G como um serviço. Ele adota a prática GitOps da Configuração como Códigoi, usando Helm Charts, Terraform Templates, e Fleet Bundles para especificar como a funcionalidade é desenvolvida e configurada.

  • Orquestração de Serviço (Service Orchestration) provê uma forma de gerenciar os serviços uma vez que estão operacionais. Define uma API que esconde os detalhes de implementação dos microsserviços básicos, e é usado para gerenciar e prover o serviço de conectividade do 5G.

  • Monitoramento e Telemetria (Monitoring & Telemetry) é responsável por coletar, arquivar e analisar os dados gerados pelos componentes básicos. Faz o possível para diagnosticar e responder a falhas, ajustar o desempenho, analisar a causa raíz, auditoria de segurança, e entender quando é necessário provisionar capacidade adicional.

AMP implementa todos os quatro subsistemas, mas uma perspectiva alternativa que caracteriza a plataforma de gerenciamento como estando online ou offline também é instrutiva. Tal como um esquemático bidimensional como mostrado na Figure 43. Gerenciamento de Ciclo de Vida (acoplado com Provisionamento de Recursos) roda offline, estando ao lado da cloud híbrida. Operadores e Desenvolvedores provisionam e mudam o sistema verificando código (incluindo especificações de configuração) em um repositório, que dispara um gatilho de atualização do sistema em execução. Orquestração de Serviço (acoplado com Monitoramento e Telemetria) roda online, em camada sobre a cloud híbrida sendo gerenciada. Ele define uma API que pode ser usada para ler e escrever parâmetros no sistema em execução, que serve como uma base para construção do loop de controle.

_images/Slide111.png

Figure 43. Representação Alternativa da plataforma de gerenciamento, destacando os aspectos online e offline do gerenciamento da cloud.

Os aspectos online e offline do gerenciamento da cloud são relacionados no sentido que o componente offline é responsável pelo gerenciamento do ciclo de vida dos componentes online. Isto porque o último é implementado como uma coleção de aplicações de Kubernetes, como no SD-Core e SD-RAN. Gerenciamento de versão é um aspecto chave para este relacionamento desde que o tempo de execução da API do serviço de conectividade do 5G tem que estar em sincronismo com a implementação base dos sistemas constituintes. Como Aether realiza o controle de versão é descrito em mais detalhes no livro Edge Cloud.

6.3.1 Provisionamento de Recursos

Provisionamento de Recursos é o processo de lidar com recursos virtuais e físicos de forma online. Para recursos físicos, há ambos um recurso mão na massa (racks e conexões de equipamentos) e configurações de bootstrap (configurando como os recursos inicializam em um estado “pronto”). Quando utilizando um recurso virtual (e.g., VMs instanciada um cloud comercial) o passo de “rack e conexão” é feito por uma sequência de chamadas de API ao invés de técnicos mão na massa.

Como queremos automatizar a sequência de chamadas necessárias para ativar a infraestrutura virtual, adotamos uma abordagem conhecida como Infraestrutura como Código. Isto é quando o Terraform aparece. A ideia geral é documentar, em um formato declarativo pode ser “executado”, exatamente como a infraestrutura como ele aparece. O código define como a infraestrutura pode ser configurada.

Quando a cloud é construída de uma combinação de recursos virtuais e físicos, como no caso de uma cloud híbrida como o Aether, necessitamos de uma forma similar de acomodar ambos. Para este fim, nossa abordagem é primeiro sobrepor a estrutura lógica no topo de recursos de hardware, tornando-os fortemente equivalente a recursos virtuais obtidos de um provedor comercial de cloud. Isto resulta em cenário híbrido como mostrado na Figure 44. Uma forma de pensar sobre isto é a tarefa de inicializar o hardware em um estado “pronto” que envolve instalar e configurar vários subsistemas que coletivamente formam a plataforma em cloud. É a plataforma de a Terraform interagem, indiretamente, através de um API de provisionamento de cloud.

_images/Slide121.png

Figure 44. Provisionamento de recurso em uma cloud híbrida que inclui ambos recursos físicos e virtuais.

6.3.2 Gerenciamento do Ciclo de Vida

Gerenciamento do Ciclo de Vida está relacionado com o update e evolução à medida que o tempo passa de sistemas em execução; Figure 45 fornece um overview do pipeline/toolchain que compõem as duas metades do Gerenciamento do Ciclo de Vida - Integração Contínua (Continuous Integration - CI) e Implementação Contínua (Continuous Deployment - CD). Essas partes são chave para focar nos repositórios de Imagem e Configurações que estão no meio. Elas representam a “interface” entre as duas metades: CI produz Docker Images e Helm Charts, os armazenando nos respectivos repositórios, enquanto CD consome Docker Images e Helm Charts, pegando dos respectivos repositórios.

_images/Slide81.png

Figure 45. Visão Geral do pipeline CI/CD.

O Repositório de Configuração também contém especificações declarativas da infraestrutura de artefatos (especificamente, templates Terraform templates e Fleet Bundles). Estes arquivos são entradas do Gerenciamento do Ciclo de Vida, que implica em Terraform e Fleet serem invocados como partes do CI/CD toda vez que estes arquivos mudam. Em outras palavras, CI/CD mantém tanto os componentes relacionados ao software na plataforma de cloud de suporte e as cargas de microsserviços rodando no tempo de plataforma.

Há três observações sobre esta visão geral. O primeiro é que tendo artefatos bem definidos passando entre o CI e o CD (entre operadores responsáveis pelo provisionamento de recursos e CD), os subsistemas são fracamente acoplados, e conseguem realizar suas tarefas independentemente. O segundo é que todo estado em autorização precisa construir e implementar com sucesso o sistema de está contido dentro do pipeline, especificamente, como uma especificação declarativa no Config Repo. Isto é o pilar da Configuração como Código (também conhecido como GitOps), a abordagem nativa na nuvem para o CI/CD. O terceiro é que existe uma oportunidade para operadores aplicarem “Deployment Gate” na Figura, controlando quais features são implementadas. (Tenha em mente que “continuo” não necessariamente significa “instantâneo”; existe uma variedade de funções de abertura injetadas no pipeline CI/CD para controlar quando às atualizações podem ser realizadas.)

O terceiro repositório mostrado na Figure 45 é o Code Repo (mais à esquerda). Desenvolvedores continuamente verificam características e fixam bugs neste repositório, que inicia o pipeline CI/CD. Um conjunto de testes e revisões de código são executadas nesses check-ins, com a saída dos testes/revisão reportadas de volta aos desenvolvedores, que modificam seus conjuntos de patch de acordo. (Estes laços desenvolve-teste são imediatamente implicados pelas linhas pontilhadas na Figure 45.)

O mais à direita na Figure 45 mostra o conjunto de objetivos de desenvolvimento, com Staging e Production destacados como dois exemplos ilustrativos. A ideia é que uma nova versão do software é implementada primeiro em um conjunto dos clusters do Staging, quando é submetido a uma carga de trabalho realista por um período de tempo, e então repassado aos clusters Production pois a implementação de Staging deu confiança para que o upgrade é confiável.

Finalmente, dois dos estágios CI são mostrados na Figure 45 identificados como componente de Testing. Um é um conjunto de testes de nível de componentes que estão executando cada patch no Code Repo. Estes testes fornecem integração; fundindo completamente um patch no Code Repo requer primeiro passar pela rodada preliminar de testes. Finalizada a junção, o pipeline realiza um build em todos os componentes, e um segundo round de testes acontece em um cluster de Quality Assurance (QA). Passados estes testes, como já descrito, testes acontecem no cluster de Staging como parte do fim do CD do pipeline.

6.3.3 Orquestração de Serviços

Orquestração de serviço é responsável pelo gerenciamento da carga de trabalho dos Kubernetes uma vez que eles estão ativos e rodando, que no nosso caso significa prover uma API programática que pode ser usada por vários stakeholders para gerenciar os serviços de conectividade do 5G. Como mostrado na Figure 46, o Orquestrador de Serviço (Service Orchestrator) esconde os detalhes de implementação da conectividade 5G, que abrange quatro componentes distintos e múltiplas clouds. Ele faz isso provendo uma interface coerente para usuários, os habilitando a autorizar os equipamento autorizados e configurar os parâmetros de QoS em uma base fim-a-fim.

_images/Slide91.png

Figure 46. Exemplo de um caso de uso que requer um controle de execução em andamento.

Em outras palavras, o Orquestrador de Serviço define uma camada de abstração no topo de uma coleção de componentes do backend, tornando-os efetivamente em um serviço de cloud visível (e controlável) externamente. Em algumas situações um único componente de backend pode implementar o serviço inteiro, mas no caso do 5G, que é construído de uma coleção de componentes desagregados, a Orquestração de Serviços é onde definimos uma API que topologicamente integra os componentes em um todo coerente e unificado. É também uma oportunidade para “levantar o nível de abstração” para os sistemas de base, escondendo os detalhes de implementação desnecessários.

Descrevemos essa interface de conectividade na Seção 6.4. No momento, nosso foco está nas dificuldades que o Orquestrador de Serviço deve endereçar para oferecer esta API. Em alto nível, ele deve:

  1. Autenticar o ente principal wanting para realizar a operação.

  2. Determinar se o principal tem privilégios suficientes para realizar a operação.

  3. Coletar os novos parâmetros para configurar um ou mais componentes de base.

  4. Gravar os parâmetros especificados, tal que um valor persista.

Central a este papel está o requisito que a Orquestração de Serviço possa representar um conjunto de objetos abstratos, ou seja, implementar um modelo de dados. A API é então gerada deste modelo de dados, e o estado persistente associado com as instâncias dos modelos são armazenados no campo Chave/Valor (Key/Value store). Aether usa YANG para especificar estes modelos, em parte porque ela é uma linguagem rica para modelamento de dados, mas também porque existe uma coleção robusta de ferramentas baseadas em YANG que podemos construir.

Finalmente, mudanças no parâmetros definidos pelo modelo devem ser propagados de volta para os os componentes de base (backend components), e na prática não existe uma API estabelecida para fazer isso. Aether assume gNMI como uma interface southbound para comunicar mudanças de configuração a estes serviços, sendo um que o Adaptador (não mostrado na figura) tendo que ser escrito para cada serviço que não é nativo do gNMI.

6.3.4 Monitoramento e Telemetria

Coletar dados de telemetria para um sistema em execução é essencial para uma plataforma de gerenciamento. Ela habilita operadores a monitorar o comportamento do sistema, avaliar desempenho, tomar decisões de provisão com base em dados, e diagnosticar problemas. Existem três tipos de dados de telemetria - métricas, logs, e traços- que em conjunto com as pilhas de software livre ajudam a coletar, armazenar, atuar em cada um deles.

Metricas são dados quantitativos sobre um sistema. Isto inclui métricas comuns de desempenho como largura de banda, utilização da CPU, e uso da memória, mas também resultados binários correspondentes a “ligar” e “desligar”, como também outras variáveis de estado que podem ser codificadas numericamente. Estes valores são produzidos e coletados periodicamente (e.g., a cada poucos segundos), seja pela leitura de um contador, ou pela execução de um teste em tempo real que retorna um valor. Estas métricas podem ser associadas com recursos físicos tais como servidores e switches, recursos virtuais como VMs e contêineres, ou abstrações de alto nível como Serviço de Conectividade descrito na próxima seção. Dadas essas muitas possíveis fontes de dados, o trabalho da pilha de monitoramento das métricas é coletar, arquivar, visualizar e otimizar a análise desses dados. Prometheus é uma ferramenta open source para armazenar e pesquisar métricas.

Leitura Adicional

Prometheus.

Logs são os dados qualitativos que são gerados quando um evento que chama a atenção ocorre. Esta informação pode ser usada para identificar condições problemáticas de operação (i.e. pode disparar um alerta), porém mais comumente, é usada para resolução de problemas após eles serem detectados. Vários componentes do sistema- todos desde o baixo nível como o kernel do OS até o alto nível como os serviços em nuvem - escrevem mensagens que são adequadas ao formato definido no log. Estas mensagens incluem uma marca de tempo (timestamp), que tornam possível para a pilha de análise de logs analisar e correlacionar mensagem de diferentes componentes. ElasticSearch é uma ferramenta muito usada para armazenamento e análise de mensagens de log.

Leitura Adicional

ElasticSearch.

Traços são gravações de uma relação causal (e.g., serviço A chama Serviço B) resultado de transações iniciadas pelos usuários ou por tarefas. Eles são relacionados a logs, mas provém informações mais especializadas sobre o contexto em que diferentes eventos acontecem. Tracing é bem entendido como um único programa, onde o traço da execução é comumente gravado como uma pilha de chamadas em memória, mas traços são inerentemente distribuídos ao longo de uma rede de microsserviços conectados em uma configuração de cloud. Isto torna o problema desafiante, mas também criticamente importante pois ele normalmente é a única forma de entender um fenômeno dependente do tempo - tal como um recurso particular é sobrecarregado - é entender como múltiplos workflows independentes interagem entre si. Jaeger é uma ferramenta de código livre popular para fazer o tracing.

Finalmente, note que nossa janela de monitoramento e telemetria como parte de um aspecto online do gerenciamento é de certa forma simplista. Certamente dados de telemetria são coletados de um processo embarcado em um sistema em execução, e tais dados podem ser acoplados com as operações de controle online para realizar controle de laço fechado, mas é também o caso em que algum dado de telemetria é avaliado offline. Isto é verdade para logs e traces usados para diagnosticar problemas, e para dados de desempenho usados para provisionar decisões, ambos podendo levar a mudanças de código que entram na próxima interação do gerenciamento do ciclo de vida.

6.4 API de Conectividade

O aspecto visível do serviço 5G é a interface programática provida para o usuários, dando a habilidade de controlar a customizar o serviço de conectividade. Esta API é implementada pelo Orquestrador de Serviço discutido nas seções anteriores, mas o que realmente importa sobre ele é a interface em si. Usando Aether como um exemplo concreto, esta seção descreve essa API.

Com muitos serviços em nuvem, a API para 5G como um serviço é RESTful. Isto significa que ela suporta operações REST GET, POST, PATCH, e DELETE em um conjunto de recursos (objetos):

  • GET: Recupera um objeto.

  • POST: Cria um objeto.

  • PUT, PATCH: Modifica um objeto existente.

  • DELETE: Apaga um objeto.

Cada objeto, por sua vez, é tipicamente definido por um modelo de dados. No Aether este modelo é especificado em YANG, mas ao invés de entrar em detalhes nas particularidades do YANG, esta seção descreve informalmente modelos pela descrição de campos relevantes.

Todo objeto contém um campo id que é usado para o identificar unicamente. Alguns objetos contém referências a outros objetos. Por exemplo, muitos objetos contém referências ao objeto Empresa, que os permite ser associados com uma empresa em particular. Isto é, referências são construídas usando o campo id dos objetos referenciados.

Em adição ao campo id, vários outros campos também estão incluídos em todos os modos. Sendo eles:

  • descrição: Uma descrição que pode ser lida por seres humanos, usada para armazenar contexto adicional sobre o objeto.

  • Mostra-nome: Um nome que pode ser lido por humanos que é mostrado na GUI.

Como estes campos são comuns em todos os modos, nós o omitimos das descrições por modelo que segue. Note que usamos nomes em maiúsculos para denotar o modelo (e.g., Empresa) e minúsculo para denotar um campo em um modelo (e.g., empresa:w ).

6.4.1 Enterprises

Aether é implementado em empresas (enterpresises), e então precisam definir um conjunto representativo de abstrações organizacionais. Isto inclui Enterprise, que forma a raiz de uma hierarquia específica para o usuário. O modelo Enterprise é referenciado por muitos outros objetos, e permite que estes objetos ter escopo em uma Enterprise particular para propriedade e propósito de controle baseado em regras. Enterprise contêm os seguintes campos:

  • Serviço de conectividade: Uma lista de subsistemas de backend que implementa conectividade para esta enterprise. A lista corresponde ao API endpoint para os componentes SD-Core, SD-Fabric, e SD-RAN.

Enterprises são divididas em Sites. Um site é um ponto de presença para um Enterprise e pode ser tanto físico quanto lógico (i.e., uma única área geogrática pode conter um site lógico). O modelo Site, então, contém os seguintes campos:

  • enterprise: Um link para o Enterprise que é dono do site.

  • imsi-definition: Uma descrição de como IMSIs são construídos para este site. Ele consiste nos seguintes sub-campos: * mcc: Código mobile do país.. * mnc: Código mobile da rede. * enterprise: id numérico do enterprise. * format: Uma máscara que define como os três campos acima são codificados

    em um IMSI. Por exemplo CCCNNNEEESSSSSS especifica um IMSI com um MCC de 3 dígitos, um MNC de 3 dígitos, um ENT de 3 dígitos, e os 6 dígitos do assinante.

Uma observação, um IMSI é gravado em todo SIM card, e é usado para identificar e localizar UEs em uma rede celular global.

6.4.2 Slices

Aether modela a conectividade do 5G como um Slice, que representa um canal de comunicação isolado (e um parâmetro de QoS associado) que conecta um conjunto de equipamentos (modelados como Device-Group) para um um conjunto de aplicações (cada um sendo modelado como uma Aplicação). Por exemplo, um enterprise pode configurar um slice para transportar tráfego IoT e outro slice para tráfego de vídeo. O modelos de Slice tem os seguintes campos:

  • device-group: Uma lista de objetos Device-Group que podem participar do Slice. Cada entrada na lista contém tanto uma referência ao Device-Group como também um campo de habilitação que pode ser usado temporariamente para remover o acesso ao grupo.

  • application: Uma lista de objetos Application que são permitidos ou bloqueados para o Slice. Cada entrada na lista contém tanto uma referência para a Application como também um campo que pode ser configurado como verdadeira para permitir a aplicação ou falso para bloquear.

  • template: Referência ao Template que foi usado para inicializar o Slice.

  • upf: Referência a User Plane Function (UPF) que pode ser usada para processar pacotes no Slice. Múltiplos Slices compartilham um único UPF.

  • enterprise: Referência ao Enterprise proprietário deste Slice.

  • site: Referência ao Site onde o Slice está sendo implementado.

  • sst, sd: identificador do slice definido pelo 3GPP associado ao time de operação.

  • mbr.uplink, mbr.downlink, mbr.uplink-burst-size, mbr.downlink-burst-size. Taxa máxima de bit e tamanho de rajada para o slice.

Os parâmetros listados acima são inicializados usando um template, como descrito abaixo, mas esses valores podem ser modificados em tempo de execução. Note também que este exemplo ilustra como a modelagem pode ser usada para reforçar invariantes, neste caso, o Site do UPF e Device-Group devem casar com o Site do Slice. Isto é, os equipamentos físicos que conectar um slice e o UPF que implementa o segmento do core do slice devem ser restringidos a uma única localização física.

No fim de um slice está o Device-Group, que identifica um conjunto de equipamentos que são permitidos usar o Slice para conectar as várias aplicações. O modelo Device-Group contém os seguintes campos:

  • imsis: Uma lista de faixas de IMSI. Cada faixa tem os seguintes campos:

    • name: Nome da faixa. Usado como uma chave.

    • imsi-range-from: Primeiro IMSI na faixa.

    • imsi-range-to: Último IMSI na faixa. Não pode ser omitido se a faixa contém somente um IMSI.

  • ip-domain: Referência ao objeto IP-Domain que descreve as configurações de IP e DNS para UEs neste grupo.

  • site: Referência ao site onde o Device-Group pode ser usado. (Este campo identifica indiretamente os Enterprise pois um Site contém uma referência a um Enterprise.)

  • mbr.uplink, mbr.downlink: Taxa máxima de bits para o device group.

  • traffic-class: A classe de tráfego a ser usada neste grupo.

Na outra ponta de um Slice está uma lista de Application objects, que especifica os endpoints para os equipamentos falarem. O modelo Application contém os seguintes campos:

  • address: O nome do DNS ou endereço IP de cada componente do endpoint.

  • endpoint: Uma lista de endpoints. Cada uma tem os seguintes campos:

    • name: Nome de endpoint. Usado como uma chave.

    • port-start: Número de porta de início.

    • port-end: Número da porta final.

    • protocol: Protocolo (TCP|UDP) para o endpoint.

    • mbr.uplink,`mbr.downlink`: Taxa máxima de bits para os equipamentos se comunicarem com a aplicação.

    • traffic-class: Classe de tráfego para os equipamentos se comunicarem com a aplicação.

  • enterprise: Link para um objeto Enterprise proprietária da aplicação que pode ser usada em vários enterprises.

At the other end of a Slice is a list of Application objects, which specifies the endpoints for the program devices talk to. The Application model contains the following fields:

  • address: The DNS name or IP address of the endpoint.

  • endpoint: A list of endpoints. Each has the following fields:

    • name: Name of the endpoint. Used as a key.

    • port-start: Starting port number.

    • port-end: Ending port number.

    • protocol: Protocol (TCP|UDP) for the endpoint.

    • mbr.uplink, mbr.downlink: Maximum bitrate for devices communicating with this application.

    • traffic-class: Traffic class for devices communicating with this application.

  • enterprise: Link to an Enterprise object that owns this application. May be left empty to indicate a global application that may be used by multiple enterprises.

Note que a abstração do Aether Slice é similar a especificação do 3GPP de um “slice”, mas o modelo Slice inclui uma combinação de identificadores especificados pelo 3GPP (e.g., sst e sd), e detalhes sobre a implementação de base (e.g., upf denota a implementação UPF do plano de usuário do Core). O modelo do Slice inclui campos relacionados ao slice da RAN, com o Orquestrador de Serviços responsável por costurar a conectividade fim-a-fim por dentro da RAN, Core e o conjunto de equipamentos (Fabric).

6.4.3 Perfis de QoS

Associado com cada Slice está um perfil relacionado ao QoS que governa como o tráfego que passa pelo slice é tratado. Isto inicia um modelo de Template, que define uma configuração de conectividade válida (aceita). O time de operações do Aether é responsável por definir (as características que podem ofertar devem ser suportadas pelos subsistemas de backend), com enterprises selecionando o template que eles precisam aplicar a qualquer instância do serviço de conectividade que criarem (e.g., via um menu suspenso). Isto é, templates são usados para inicializar objetos Slice. O modelo do Template tem os seguintes campos:

  • sst, sd: identificadores dos Slice, como especificado pelo 3GPP.

  • mbr.uplink, mbr.downlink: Largura de banda máxima do uplink e downlink.

  • mbr.uplink-burst-size, mbr.downlink-burst-size: Tamanho máximo da rajada (burst).

  • traffic-class: Link para o objeto Traffic-Class que discrete o tipo de tráfego.

Veremos que os modelos Device-Group e Application incluem campos similares. A ideia é que os parâmetros de QoS sejam estabelecidos pelo slice como um todo (baseado no Template selecionado) e então equipamentos e aplicações individuais conectada ao slice podem definir seus próprios, e mais restritivos, parâmetros de QoS com base de cada instância.

Finalmente, o modelo Traffic-Class especifica a classe de tráfego, e inclui os seguintes campos:

  • arp: Prioridade de alocação e posicionamento.

  • qci: identificador da classe de QoS.

  • pelr: taxa de perda de pacotes.

  • pdb: Budget de atraso do pacote.

6.4.4 Outros Modelos

A descrição acima referencia outros modelos, que nós não descrevemos completamente aqui. Eles incluem uma AP-List, que especifica uma lista de pontos de acesso (rádios); Domínio-IP, que especifica configurações de IP e DNS; e UPF que especifica a User Plane Function (o elemento do plano de dados do SD-Core) que para encaminhar pacotes no lugar da sua instância do serviço de conectividade. O modelo UPF é necessário pois o Aether suporta duas implementações distintas: uma rodando como um microsserviço no servidor e a outra rodando no programa P4 carregado no switching fabric. Ambas as implementações são descritas no Capítulo 5.