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”.
Pode ser simplesmente descrito como quanto tempo leva para que a intenção de uma operação entre em vigor. Exemplos incluem:
Esta questão pode ser respondida por meio de alguns exemplos de clientes do mundo real:
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.
A gravidade do desafio é mais sentida quando a equipe de operações tem que gerenciar
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.
Os blocos de construção fundamentais para atingir o Tempo mínimo para Efeito são:
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.
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.
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.
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
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.