Para uma Edge Computing robusta, planeje os ‘e se’

Quando uma caixa (ou centenas) fica inoperante, levando consigo aplicativos críticos, de repente você tem usuários irritados e a perspectiva de levar um engenheiro especialista a um local remoto (ou de um cliente) para solucionar o problema. É caro, é lento e pode fazer com que você se arrependa de ter entrado nessa coisa extrema em primeiro lugar.

Planejando os “e se”

Como dizem nossos parceiros da Intel, a vantagem não é apenas a nuvem em um local diferente. Possui riscos únicos e diversos que ameaçam seus níveis de serviço.

Você pode pensar nesses riscos em termos de “e se”:

• E se um barista derramar café quente no servidor e matar um nó?
• E se uma recepcionista odontológica desconectar o roteador e solicitar uma atualização do endereço IP do site?
• E se um patch de segurança bloquear o cluster?

Mas todos esses cenários do tipo “o que acontece se” são na verdade “o que acontece”. quando.” Eventos inesperados acontecem diariamente ou semanalmente quando você fala sobre centenas ou milhares de sites.

Portanto, ao construir sua pilha de borda, procure ferramentas que antecipem e planejem o maior número possível desses cenários de falha, seja impedindo a ocorrência da situação, mitigando seu impacto ou simplificando e reduzindo o custo da correção.

Você provavelmente já sabe disso em seu íntimo. Nossa pesquisa mais recente com adotantes do Kubernetes descobriu uma preocupação ampla e crescente sobre os desafios da operação de dispositivos de borda, desde a segurança até lidar com ambientes desconectados e realizar implementações e tarefas de operações diárias sem visitas de engenharia de campo.

Barra roxa mostra resultados de 2023; barra azul mostra resultados de 2022

Então, vamos dar uma olhada em alguns dos “e se” e revisar algumas maneiras de respondê-los.

Lidando com falhas de hardware

No limite, você provavelmente não tem o luxo de ter um rack inteiro de servidores com discos redundantes, controladores de interface de rede (NICs) e unidades de fonte de alimentação (PSUs), e o hardware implantado pode enfrentar temperaturas extremas, poeira, vibração e outros abusos.

A falha de hardware é inevitável, não importa qual caixa robusta você compre, mesmo se você seguir as práticas recomendadas, como testes de burn-in, para eliminar falhas precoces.

Considere que taxas anuais de falhas superiores a 2% são típicas para discos e os riscos se acumulam para cada componente.

Facilite a substituição de hardware

Se a falha de hardware for inevitável, isso significa que o hardware substituição também é inevitável. E o que você não quer que aconteça é que toda vez que uma caixa precisar ser trocada, você envie um especialista experiente (caro) em Kubernetes para cada local remoto.

Lá eles ficam sentados com um runbook de 200 páginas, passando dois ou três dias configurando o cluster antes de passar para o próximo trabalho. Era isso que um dos nossos clientes do setor de saúde estava fazendo.

Em vez disso, você deseja tornar a experiência de substituição o mais próxima possível do plug and play, para que um soldado, um gerente de loja, um subcontratado ou um profissional de TI geral no local possa ligar o dispositivo, conectá-lo à rede e integrá-lo ao gerenciamento dentro do seu Ambiente Kubernetes.

Resolvemos isso com nossas opções de integração de baixo toque, desde leituras de código QR para integração de dispositivos confiáveis ​​até pré-provisionamento completo em locais de teste, permitindo uma abordagem GitOps para substituir dispositivos quebrados.

Mantenha os aplicativos ativos quando as caixas caírem

Até mesmo o processo mais simplificado de substituição de hardware leva horas ou dias. E você precisa manter os serviços de aplicativos críticos disponíveis enquanto isso.

Embora existam muitas implantações Kubernetes de borda de nó único por aí, usando K3s e outras distribuições leves, você provavelmente investigou arquiteturas Kubernetes tradicionais de alta disponibilidade (HA) e descobriu que isso significa ter três nós por site, com todo o custo, espaço e poder que isso implica.

Para alguns casos de uso, isso é um obstáculo, e é por isso que construímos a primeira arquitetura HA Kubernetes de dois nós do mundo, superando alguns difíceis desafios de engenharia ao longo do caminho. Ele permite que seus aplicativos sobrevivam ininterruptamente a uma falha de nó e custa um terço menos do que o HA convencional de três nós. Assista à demonstração do CNCF para saber mais sobre como tornamos isso real.

Navegando no Velho Oeste das Redes

Uma das maiores diferenças entre a borda e a nuvem ou data center é a situação da rede.

Espaço de ar? É hora de ir para o local

Alguns sites de borda não se conectam a uma WAN privada ou mesmo à Internet porque estão em locais muito remotos ou porque precisam ser isolados – sem ar – por motivos operacionais.

Para estes cenários, não é suficiente apoiar a construção de clusters totalmente isolados. É igualmente necessário ter a liberdade de implantar uma instância da plataforma de gerenciamento em um ambiente isolado para permitir o gerenciamento centralizado seguro, por exemplo, em uma base militar ou em uma fábrica, como você pode fazer com o Palette.

Para operações diárias em ambientes isolados, o Palette oferece um console de gerenciamento local para implantação e gerenciamento de clusters. Ele vem com um registro de contêiner local que permite aos usuários importar manualmente o conteúdo da atualização de um stick USB por meio da UI da paleta local.

Transitar de gerenciado localmente para gerenciado centralmente ou vice-versa? Sem problemas. A IU do Palette oferece suporte total à alternância entre dois modos de gerenciamento e você também pode ter uma política para bloquear o modo de gerenciamento, se necessário.

DDIL? Sem problemas

Outros clusters de borda possuem conexões de baixa largura de banda por design ou estão operando em ambientes desafiadores. O NIST tem uma frase – ambientes de conectividade negados, interrompidos, intermitentes ou limitados (DDIL) – que se encaixa aqui. Algumas pessoas gostam de usar outras palavras como degradado ou interditado, mas você entendeu. Você não pode contar com a entrada ou saída de um pacote.

Se sua rede cair inesperadamente, é importante saber que seus clusters de borda continuarão funcionando. O Palette Edge possui uma arquitetura descentralizada com aplicação de políticas locais, para que cada cluster possa continuar a impor o estado desejado mesmo que não consiga alcançar o plano de gerenciamento. Quando a conexão for restabelecida, ela será ressincronizada perfeitamente com o plano de gerenciamento.

Reconhecendo que muitos ambientes de borda operam com recursos de rede limitados, otimizamos o Palette Edge para condições de baixa largura de banda. Isto garante operação eficiente e confiabilidade, mesmo quando a conectividade de rede é restrita, como em locais remotos ou mal atendidos. Você pode até fazer upload de conteúdo grande localmente para o cluster para evitar totalmente transferências de rede demoradas.

Adapte-se às mudanças de IP

Mesmo quando há uma conexão de rede sempre ativa e de alto desempenho para cada dispositivo de borda, isso não significa que você pode relaxar.

Os clusters Kubernetes dependem muito de endereçamento IP estável para o plano de controle e serão facilmente quebrados se o endereço IP da rede mudar.

Uma simples queda de energia ou troca de roteador pode desencadear isso, e é quase impossível protegê-los, especialmente quando você está implantando clusters em locais com redes que você não controla, como um produto conectado na fábrica ou ponto de venda de um cliente. terminais de venda para franqueados de varejo ou restaurantes.

Para isso, o Palette Edge oferece um recurso de sobreposição dinâmica que fornece estabilidade de IP ao cluster, mesmo se os endereços IP do host mudarem. É completamente independente, não necessita de assistência de sistemas externos e não depende de multicast (mDNS), que normalmente é desabilitado em redes seguras. Também é autocorretivo, permite que os nós entrem e saiam do cluster e se adapta continuamente.

Gerenciando patches e atualizações

Os dispositivos Edge Kubernetes em campo geralmente precisam de patches regulares, atualizações ou novo software, seja para corrigir vulnerabilidades de segurança ou adicionar recursos. Mas atualizar dispositivos remotos pode ser um verdadeiro desafio.

Não há mais barras de progresso

Como você obtém novas versões de software em um dispositivo quando lida com hardware limitado e conectividade lenta ou intermitente?

Resolvemos isso baseando o Palette Edge no projeto de código aberto Kairos, que usa contêineres como mecanismo de transporte. As imagens de contêiner são compostas de múltiplas camadas e cada camada pode ser atualizada de forma independente. Ao comparar o hash da camada de imagem, o software determina quais camadas precisam ser extraídas do registro remoto e evita o download daquelas que correspondem. Isso pode reduzir significativamente a largura de banda necessária e diminuir as janelas de atualização.

Ele também oferece suporte a registros locais, portanto, se você precisar adicionar um novo pacote de software à pilha, ele já poderá estar no disco local. Ter um repositório local também significa que o conteúdo da atualização precisa ser baixado apenas uma vez e pode ser usado para atualizar cada nó no cluster de borda.

Se no começo você não tiver sucesso…

Depois que o pacote é transferido para a caixa de borda, há um momento de prender a respiração enquanto você espera para ver se a atualização foi bem-sucedida ou se você bloqueou seu dispositivo e precisa enviar um engenheiro de campo.

Para evitar isso, o Palette Edge usa particionamento A/B para atualizações do sistema. Cada dispositivo possui uma segunda partição onde o software atualizado é baixado e aplicado. O dispositivo tenta mudar para a nova partição após uma atualização. Se isso falhar, o sistema volta automaticamente para a execução na partição anterior. A capacidade da plataforma de se recuperar automaticamente para um estado bom em caso de falhas de atualização ou problemas no sistema é um componente essencial de sua robustez.

Prevenindo ameaças à segurança

Qualquer discussão sobre robustez deve incluir segurança. Robustez significa não apenas ignorar falhas de hardware, mas também manter os níveis de serviço sob ataque deliberado, especialmente se o seu caso de uso de borda for coberto por requisitos de conformidade como FIPS (que o Palette Edge suporta até a borda).

Os problemas de segurança na borda são diferentes daqueles encontrados na nuvem pública ou no data center, incluindo roubo físico, adulteração e redes não confiáveis. Nossa arquitetura de segurança SENA oferece uma ampla gama de recursos projetados especificamente para resolver esses problemas.

Endureça-se contra adulteração e roubo

Quando você não consegue impedir que invasores obtenham acesso físico ao dispositivo de borda, como pode ter certeza de que eles não adulteraram o software ou exfiltraram dados confidenciais?

Nós abordamos isso de algumas maneiras diferentes. Primeiro, o Palette Edge usa um sistema operacional de borda imutável e imagens Kubernetes. Isso significa que componentes essenciais do sistema, como o kernel, não podem ser alterados no dispositivo.

Ele também protege os nós de borda usando um processo de inicialização segura verificado por hardware. Verifica se cada componente da sequência de inicialização do sistema está assinado e validado, evitando a execução não autorizada de códigos. Ele constitui a base para a segurança da plataforma, permitindo recursos como criptografia de partição de dados.

Para atender a diversos requisitos de segurança, o Palette Edge permite criptografia de partição altamente personalizável. Essa flexibilidade ajuda a proteger dados confidenciais de uma maneira que se alinhe com políticas de segurança e requisitos de conformidade específicos.

Para autenticar o acesso a dados criptografados, o Palette Edge oferece suporte a opções de chave de criptografia local e remota. Para criptografia local, ele usa o hardware Trusted Platform Module (TPM), trabalhando em conjunto com o processo de inicialização segura para proteger os dados mesmo em casos de roubo físico. Isso ajuda a manter os dados seguros e praticamente inacessíveis, mesmo em dispositivos roubados.

Para uma segurança ainda maior, você pode exigir que o dispositivo acesse um servidor de chaves específico através da rede. Isso protege contra roubo de dados quando os dispositivos são removidos do local pretendido.

Você pode se dar ao luxo de assumir o risco?

Acreditamos que a borda é o futuro, com potencial quase ilimitado. Mas só poderá concretizar esse potencial se as empresas e os utilizadores puderem confiar na disponibilidade e segurança da infraestrutura que alimenta as suas experiências.

Muitos de nossos clientes foram prejudicados por outros fornecedores que lhes venderam a promessa de vantagem. Muitas vezes, esses fornecedores simplesmente não pensaram nos muitos cenários inevitáveis ​​do tipo “e se” que a borda apresenta e não têm uma resposta confiável.

A melhor maneira de ver a robustez do Palette Edge é começar com uma demonstração feita por um de nossos especialistas.

A postagem Para Robust Edge Computing, planeje os ‘What Ifs’ apareceu pela primeira vez em The New Stack.