Tempo para efeito
Este blog é uma continuação de “Qual é um bom plano de controle para operar um grande número de clusters Kubernetes” . O blog anterior descreveu a abordagem exclusiva de Operações de Frota da Volterra para gerenciar uma frota de sites e aplicativos de infraestrutura. Este blog específico descreve um dos principais desafios de desvio de configuração enfrentado por uma equipe de operações ao fazer alterações de configuração em um grande número de clusters ou sites. Eu chamo esse desafio de “Tempo para Efeito”.
O que é tempo para efeito?
Pode ser simplesmente descrito como quanto tempo leva para que a intenção de uma operação entre em vigor. Exemplos incluem:
- Quanto tempo levará para que minha configuração de política de segurança entre em vigor em todos os meus sites?
- Quanto tempo levará para que a versão mais recente do meu aplicativo seja propagada para todos os sites?
- Quanto tempo levará para atualizar o sistema operacional ou o software de infraestrutura em todos os meus sites distribuídos globalmente?
Por que isso é importante?
Esta questão pode ser respondida por meio de alguns exemplos de clientes do mundo real:
- Meltdown e Spectre — A principal preocupação de todos os CISOs após a notícia do Meltdown/Spectre era como corrigir o sistema operacional em toda a sua infraestrutura rapidamente. A equipe de operações estava sendo medida a cada hora para que sua intenção (ou seja, atualizar a versão do sistema operacional) entrasse em vigor.
- Você deve ter ouvido falar sobre a frota de máquinas de venda automática que causou um ataque de negação de serviço em uma universidade? Aqui está o resumo, caso você não tenha acompanhado o ataque: hackers exploraram uma vulnerabilidade de dia zero e instalaram malware que se conectou a outras máquinas de venda automática e criou uma frota de bots de venda automática. Em seguida, ele enviou grandes volumes de tráfego e causou um ataque de negação de serviço na universidade. Ao detectar o ataque, a universidade teve que configurar regras de política de rede em cada máquina de venda automática, uma por uma, para impedir o acesso ao servidor de comando e controle. Era extremamente importante para eles que sua intenção (ou seja, bloquear o acesso a um site específico) fosse efetivada imediatamente em todas as máquinas de venda automática para estancar o vazamento.
O tempo para efeito é importante para diversas categorias, como software de infraestrutura, software de aplicativo, política de rede e política de segurança.
Qual é o desafio?
A gravidade do desafio é mais sentida quando a equipe de operações tem que gerenciar
- Uma grande escala de sites
- Sites distribuídos globalmente
- Ambientes heterogêneos, ou seja, sites em nuvens privadas, públicas, de telecomunicações e dispositivos de ponta
- Conectividade inconsistente para sites
Um ótimo exemplo de uma equipe de operações de um fabricante de equipamentos originais (OEM) automotivo responsável por atualizar o software e gerenciar a conectividade de seus automóveis (doravante denominados sites do cliente). A implantação típica incluiria um data center privado de onde a equipe de operações controla seus automóveis globalmente (ou regionalmente, dependendo da estrutura organizacional).
Para entender o desafio, vamos analisar as soluções que a equipe de operações tem à disposição. A maioria das soluções oferece software de gerenciamento hospedado no data center privado de um cliente para gerenciar centralmente a grande escala de sites distribuídos. Quando o fabricante automotivo configura uma política que precisa ser aplicada a todos os automóveis, o software de gerenciamento central basicamente baixa um script de configuração para cada carro, um por um. O script de configuração pode ser um manual do Ansible ou um gráfico do Helm que executa uma série de comandos de configuração em cada site. Isso pode ser visualizado como mostrado no diagrama abaixo.
O problema é que o tempo para efeito é diretamente proporcional ao número de sites. Os fornecedores de software de gerenciamento centralizado argumentarão que, desde que todas as operações possam ser realizadas remotamente e de forma automatizada, isso é o melhor que pode ser alcançado.
Volterra discorda e podemos provar isso neste blog. Construímos um plano de controle distribuído com uma abordagem arquitetônica hierárquica e escalável, projetada para garantir o mínimo de tempo para efeito.
Arquitetura Volterra para um tempo mínimo de efeito
Os blocos de construção fundamentais para atingir o Tempo mínimo para Efeito são:
- Arquitetura hierárquica baseada em árvore
- Plano de controle distribuído desenvolvido especificamente
Uma visão geral arquitetônica de alto nível é mostrada a seguir.
A abordagem da arquitetura hierárquica da Volterra é criar uma árvore de nós para distribuição de configuração. Cada nó faz um armazenamento e encaminhamento — ou seja, armazena a configuração localmente e depois a encaminha para seus filhos. Isso pode ser melhor descrito com um exemplo. Quando um usuário configura um objeto, como uma política de rede, no Volterra Console, o plano de controle e gerenciamento distribui a configuração para os filhos imediatos, as Bordas Regionais (RE). Cada RE armazena a configuração localmente e a encaminha para seus filhos. Os filhos da RE são sites de clientes conectados a essa RE.
Uma arquitetura hierárquica baseada em árvore garante um tempo mínimo para efeito. O tempo para efeito é limitado pelo número de níveis na árvore e pelo número de filhos por nó. O número máximo de níveis na árvore é três (controlador → RE → local do cliente). O número de filhos por nó é diretamente proporcional ao número de sites conectados ao RE. Uma instância de serviço é gerada no RE para manipular a configuração de um conjunto de sites. O plano de controle de expansão da Volterra gera novas instâncias de serviço, sob demanda, se houver um aumento no número de sites conectados ao RE.
Configuração de teste
A medição do Tempo para Efeito foi feita em uma grande escala de sites de clientes conectados a duas bordas regionais localizadas em Nova York (NY8-NYC) e Paris (PA4-PAR). Os sites dos clientes foram distribuídos globalmente por Santa Clara (CA), Houston (Texas), Madri (Espanha), Praga (República Tcheca), Londres (Reino Unido), etc. Além disso, os sites dos clientes estavam em ambientes heterogêneos, como AWS, máquinas virtuais (ESXi), gateways de borda, incluindo Intel NUCs e Fitlet2.
O portal do cliente e o plano de controle global da Volterra estavam sendo executados no Azure (Washington-IAD). Os sites dos clientes foram distribuídos em vários namespaces e locatários para representar um ambiente operacional do mundo real.
Condições de falha foram simuladas eliminando instâncias de serviço no RE e usando links de conectividade de baixa qualidade entre o RE e os sites do cliente. Uma visão instantânea de um segmento de toda a frota, em um único namespace, é mostrada na Figura 3.
Metodologia de teste
Logs de auditoria, com registros de data e hora, são capturados no sistema Volterra sempre que objetos são configurados no console Volterra e a configuração é aplicada em cada site do cliente. O tempo de propagação foi medido como a diferença de tempo entre a configuração no portal e a aplicação da configuração no site do cliente. Um processo detalhado passo a passo é descrito a seguir.
- Configurar objetos no portal do cliente.
- Meça o tempo de início como o tempo de criação do objeto no portal do cliente (referido aqui como Controlador Global Volterra). Veja a figura 4 como exemplo.
- Meça o tempo de término como o tempo de criação do objeto no site do cliente. Veja a figura 5 como exemplo.
Observe que as capturas de tela mostradas são amostradas e não se referem à mesma iteração de medição.
Hora de início da configuração
Hora de término da configuração
Resultados dos testes
Os resultados dos testes dos tempos de propagação são mostrados nas figuras 6 e 7. O gráfico na figura 6 indica que a maioria das amostras de medição teve um tempo de propagação entre 0–400 ms. Isso significa que todos os sites dos clientes são atualizados com uma nova configuração entre 0 e 400 ms. Conforme mencionado anteriormente, as condições de falha foram simuladas reiniciando os serviços no RE e introduzindo falhas/atrasos de conectividade no site do cliente. O tempo de propagação da configuração é maior nessas condições de falha e variou de 600 ms a 9 segundos, nesses testes específicos, dependendo do tipo de falha. Por exemplo, uma falha de conectividade entre a RE e os sites do cliente aumentará o tempo para a configuração chegar ao site do cliente. No entanto, o benefício do plano de controle distribuído da Volterra é que ele segue o paradigma de configuração eventualmente consistente, ou seja, ele continua tentando garantir que a configuração em todos os sites do cliente esteja alinhada à intenção definida pelo cliente.
O gráfico na figura 7 indica que 85% das vezes, todos os sites dos clientes são atualizados com uma nova configuração em 322 milissegundos. Na situação em que condições de falha são introduzidas, poucos sites de clientes podem experimentar um tempo de propagação de ~3–9 segundos.
Isenção de responsabilidade: Essas medições estão intimamente ligadas à topologia, escala, ambiente de implantação e situações de falha simuladas. Não medimos todas as possíveis situações de falha ou outros ambientes. Portanto, não podemos fazer alegações sobre o atraso de propagação em outras situações ou ambientes que não foram testados. Por exemplo, se houver uma falha no cluster do Kubernetes, o sistema terá que aguardar a detecção da falha, reiniciar e tentar novamente a configuração, resultando em um atraso de propagação maior.