Edge Computing: Além do Data Center¶

UMA EXPLORAÇÃO MAIS PROFUNDA DE CONSIDERAÇÕES DE EDGE COMPUTING¶

O “edge” em edge computing refere-se aos arredores de um domínio administrativo, o mais próximo possível de fontes de dados discretas ou dos usuários finais. Esse conceito se aplica a redes de telecomunicações, grandes companhias com pontos de presença distribuídos como o varejo, ou para outras aplicações, em particular, no contexto da Internet das Coisas.

Uma das características do edge computing é que a aplicação é fortemente associada com a localização da borda. Para telecomunicações, “the edge” deveria referir-se ao ponto próximo ao usuário final mas controlado pelo provedor, potencialmente tendo alguns elementos de cargas de trabalho em execução nos dispositivos dos usuários finais. Para grandes companhias, “the edge” é o ponto onde a aplicação, serviço ou força de trabalho é usado (uma loja de varejo ou uma fábrica). Para os propósitos dessa definição, “the edge” não é um dispositivo final com capacidade extremamente limitada para suportar até mesmo uma arquitetura mínima de nuvem, como um dispositivo IoT ou de monitoramento. Essa é uma consideração importante, porque algumas discussões sobre edge computing não fazem essa distinção.

Edge computing é similar a data center computing no seguinte:

• Ela inclui recursos de computação, armazenamento e rede.
• Seus recursos podem ser compartilhados por vários usuários e várias aplicações.
• Ela se beneficia da virtualização e da abstração do pool de recursos.
• Ela se beneficia da capacidade de alavancar hardware de commodities.
• Utiliza APIs para suportar interoperabilidade.

Edge computing se diferencia de computação em grandes centros de dados no seguinte:

• Sites de borda estão o mais próximo possível dos usuários finais. Eles melhoram a experiência em alta latência e conexões instáveis.
• Pode requerer hardware especializado, tal como GPU/FPGA plataformas para funcionalidade RA/RV.
• Edge pode escalar para um grande número de sites, distribuídos em localidades distintas.
• Uma localização de um site de borda e a identidade dos links de acesso que ele termina são significantes. Uma aplicação que precisa rodar próxima ao seu usuário, precisa estar na parte certa da borda. É comum que a localização da aplicação seja importante na edge computing.
• O pool inteiro de sites pode ser considerado dinâmico. Devido às suas separações físicas, sites de borda serão, em alguns casos, conectados uns aos outros e ao núcleo com conexões WAN. Sites de borda entrarão e sairão do pool de infraestrutura ao longo do tempo.
• Os sites de borda são remotos e potencialmente não tripulados, e portanto devem ser administrados remotamente. As ferramentas precisam suportar o acesso de rede intermitente ao site.
• Edge computing suporta grandes diferenças no tamanho e escala do site, desde a escala do centro de dados até um único dispositivo.
• Sites de borda podem ter limitações de recursos; A adição de capacidade a um site existente é restrita devido a requisitos de energia ou espaço.
• Multi-tenancy em escala massiva é requerida para alguns casos de uso.
• O isolamento da edge computing das nuvens de centros de dados pode ser necessário para garantir que os compromissos no domínio da “nuvem externa” não possam impactar os serviços.

O conceito de edge computing deve cobrir tanto o site de borda (ou seja, computação, rede e infraestrutura de armazenamento), quanto as aplicações (cargas de trabalho) que rodam nele. Vale à pena ressaltar que qualquer aplicação em um ambiente de edge computing deveria potencialmente alavancar qualquer ou todas as capacidades providas pela nuvem—computação, armazenamento em bloco, armazenamento de objetos, rede virtual, máquina física, ou contêineres.

As características essenciais que definem e separam edge computing da computação em nuvem são:

• a capacidade de suportar um pool dinâmico de múltiplos sites potencialmente amplamente distribuídos,
• conexões de rede potencialmente não confiáveis, ​​e
• a probabilidade de restrições de recursos difíceis de resolver em sites na rede.

CASOS DE USO¶

Existem provavelmente dezenas de formas para categorizar casos de uso e esse documento é muito curto para prover uma lista exaustiva sobre isso. Mas aqui estão alguns exemplos para ajudar a clarear o pensamento e realçar oportunidades para colaboração.

Quatro categorias principais de requisitos de carga de trabalho que se beneficiam da arquitetura distribuída são: Análise, conformidade, segurança e NFV.

CENÁRIOS¶

A característica básica do paradigma da computação de borda é que a infraestrutura é localizada próxima ao usuário final, que a escala de distribuição do site é alta e que os nós de borda são conectados pelas conexões de rede WAN. Examinando alguns cenários em uma profundidade maior nos ajuda a avaliar as capacidades atuais que mapeiam para o caso de uso, bem como destaca as fraquezas e oportunidades para melhoramento.

1. Varejo/finanças/localização remota “nuvem em uma caixa”: Infraestrutura de computação de nuvem que suporta uma suíte de aplicações customizadas para uma empresa específica ou indústria vertical. Frequentemente usada por empresas, a infraestrutura de computação de borda, em adição a uma infraestrutura distribuída, para reduzir o perfil de hardware, padronizar implantações em muitos sites, entregar maior flexibilidade para substituir aplicações localizadas na borda (e para ter a mesma aplicação rodando uniformemente em todos os nós independetemente do hardware), impulsionar resiliência, e abordar preocupações sobre conexões WAN intermitentes. Cache de conteúdo ou fornecimento de computação, armazenamento e rede para aplicações autônomas são usos óbvios para computação de borda em cenários com conectividade limitada.

2. Conectividade móvel: Redes móveis/sem fio são provavelmente os elementos de ambiente comuns para nuvem de computação de borda, visto que as redes móveis continuarão sendo caracterizadas por larguras de banda limitadas e imprevisíveis, ao menos até que a 5G esteja amplamente disponível. Aplicações tais como a realidade aumentada para reparos remotos e telemedicina, dispositivos de IoT para utilitário de captura de dados (água, gás, gerenciamento de instalações), inventário, cadeia de suprimentos e soluções de transporte, cidades inteligentes, estradas inteligentes e aplicações de segurança remota estarão todas confiando em uma rede móvel em maor ou menor grau. Todas elas se beneficiarão da capacidade da computação de borda de mover cargas de trabalho para próximo do usuário final.

   

3. Rede-como-um-Serviço (NaaS): Vindo da necessidade de entregar uma experiência de aplicação de serviço de rede idêntica em ambientes radicalmente diferentes, o caso de uso NaaS requer tanto uma pequena pegada de sua plataforma distribuída nas bordas, como ferramentas de gerenciamento fortemente centralizadas que atravessam conexões de rede WAN não confiáveis ou limitadas em apoio aos serviços fora da borda. As principais características desse cenário são: pegada pequena de hardware, movimentação (mudando as conexões de rede) e mudando constantemente as cargas de trabalho, localizações híbridas de dados e aplicações. Isso é um dos casos que necessitam de infraestrutura para suportar micro nós—pequenas doses de computação em pacotes não tradicionais (nem todos os racks de 19pol em um centro de dados resfriado). NaaS irá requerer suporte para milhares ou dezenas de milhares de nós de borda e deve suportar arquiteturas de malhas e/ou hierárquicas, bem como sites sob demanda que possam subir quando necessário e desligar quando estiverem concluídos. APIs e GUIs terão que mudar para refletir que esses grandes números de nós de computação terão diferentes locais em vez de estarem presentes no mesmo centro de dados.

   

4. Equipamentos Locais Universais para Clientes (uCPE): Esse cenário, já sendo implementado atualmente, exige suporte para pegada de hardware do tamanho do appliance e é caracterizado pelas conexões de rede limitadas com cargas de trabalho geralmente estáveis que requerem alta disponibilidade. Isso também requer um método para suportar localizações híbridas de dados e aplicações atravessando centenas ou milhares de nós e a expansão das implementações de uCPE existentes será um requisito emergente.

   Isso é particularmente aplicável para aplicações NFV onde diferentes sites poderiam precisar de diferentes conjuntos de aplicações em cadeia ou sites com um conjunto diferente de aplicações requeridas que ainda precisa trabalhar em união. Arquitetura de malha ou hierárquica precisaria ser suportada com capacidade localizada e a necessidade para armazenar e encaminhar o processamento de dados devido as conexões de rede intermitentes. Auto cura e autoadministração combinadas com a habilidade para administrar remotamente um nó são necessárias.

5. Comunicação via Satélite (SATCOM): Esse cenário é caracterizado pelos numerosos dispositivos terminais capazes, frequentemente distribuídos para condições mais remotas e severas. Ao mesmo tempo, faz sentido utilizar essas plataformas distribuídas para serviços de hospedagem, especialmente considerando a latência extremamente alta, largura de banda limitada e custo de comunicação por satélite. Exemplos específicos de tais casos de uso devem incluir embarcações (de barcos de pesca a navios tanques), aviões de guerra, plataformas de petróleo, operações de mineração ou infraestrutura de grau militar.

   

DESAFIOS¶

Embora haja abundância de exemplos de implementações de borda já em progresso ao redor do mundo, a adoção generalizada requer novas formas de pensamento para resolver desafios e limitações emergentes e já existentes.

Nós estabelecemos que a plataforma de computação de borda tem que ser, por design, muito mais tolerante a falhas e robusta que uma nuvem tradicional de centro de dados centralizado, em ambos os termos de hardware assim bem como nos serviços de plataforma que suportam o ciclo de vida da aplicação. Nós não podemos assumir que tais casos de uso de borda terão a manutenção e apoio a instalação que infraestrutura de centro de dados padrões possuem. Provisionamento zero-toque, automação, e orquestração autônoma em toda infraestrutura e pilhas de plataforma são cruciais nesses cenários.

Mas existem outros desafios que precisam ser levados em consideração.

Para um, sistemas de gerenciamento de recurso de borda devem entregar um conjunto de mecanismos de alto nível cuja montagem resulta em um sistema capaz de operar e usando uma infraestrutura IaaS geodistribuída confiando em interconexões WAN. Em outras palavras, o desafio é revisar (e estender quando necessário) serviços de núcleo IaaS a fim de lidar com especificações de borda acima especificadas—desconexões de rede/largura de banda, capacidades limitadas em termos de computação e armazenamento, implantações não tripuladas e assim por diante.

Algumas necessidades previsíveis incluem:

• Um gerenciador em máquina virtual/contêiner/máquina física responsável por gerenciar o ciclo de vida da máquina/contêiner (configuração, agendamento, implantação, suspender/reassumir, e desligar).
• Um gerenciador de imagem responsável por arquivos de modelos (conhecidos como imagens de máquina virtual/contêiner).
• Um gerenciador de rede responsável por fornecer conectividade para a infraestrutura: redes virtuais e acesso externo para usuários.
• Um gerenciador de armazenamento, fornecendo serviços de armazenamento para aplicações de borda.
• Ferramentas administrativas, fornecendo interfaces de usuário para operar e usar a infraestrutura dispersa.

Essas necessidades são relativamente óbvias e podem provavelmente ser atendidas alavancando e adaptando projetos existentes. Mas outras necessidades da computação de borda são mais desafiadoras. Estas incluem, mas não estão limitadas a:

• Abordagem da latência de armazenamento em cima de conexões WAN.
• Segurança reforçada na borda—monitoração da integridade física e de aplicação de cada site, com a capacidade de ativar correções anônimas quando necessário.
• Monitoração da utilização dos recursos de todos os nós simultaneamente.
• Ferramentas de orquestração que gerenciam e coordenam muitos sites e cargas de trabalho de borda, potencialmente conduzindo para um plano de controle emparelhado ou “self-organizing edge.”
• Orquestração de uma federação de plataformas de borda (ou nuvem de nuvens) tem que ser explorada e introduzida nos serviços centrais de IaaS.
  • Operações automatizadas de ativação/desativação, incluindo implantação inicial de software e atualizações dos componentes de sistema de gerenciamento de recursos.
  • Realocação automatizada de dados e cargas de trabalho—balanceamento de carga entre hardware geograficamente distribuído.
• Alguma forma de sincronização de propagação do estado abstrato deve ser necessária no “núcleo” da infraestrutura para lidar com links de rede descontínuos.
• Novas formas de lidar com problemas de particionamento de rede devido à limitação de conectividade—lidando com desconexões curtas e longas.
• Ferramentas para gerenciar ciclos de vida de aplicação de borda, incluindo:
  • A definição de restrições avançadas de atribuição para lidar com os requisitos de latência dos componentes do aplicativo.
  • O provisionamento/agendamento de aplicativos para satisfazer os requisitos de atribuição (atribuição inicial).
  • Realocações de dados e cargas de trabalho de acordo com eventos internos/externos (casos de uso de mobilidade, falhas, considerações de desempenho, etc.).
• Consciência de localização de integração: nem todas as implantações de borda exigirão o mesmo aplicativo no mesmo momento. A localização e a conscientização da demanda são uma necessidade provável.
• Hardware discreto com recursos limitados e a capacidade limitada de expansão no site remoto precisam ser levados em consideração ao projetar a arquitetura geral no nível macro e das ferramentas administrativas. O conceito de ser capaz de capturar recursos remotos sob demanda de outros sites, ou vizinhanças em uma rede de malha ou de elementos centrais em uma rede hierárquica, significa que as flutuações na demanda local podem ser atendidas sem ineficiência em implementações de hardware.