Mudanças de configuração na camada de balanceamento de carga e segurança são inevitáveis. Novos backends são adicionados, regras WAAP são atualizadas, certificados são renovados, health checks são ajustados, políticas de rate limit são restritas, ou novas regras de bloqueio são escritas no meio de um ataque. Se cada mudança exigir uma reinicialização do serviço, mesmo tarefas operacionais pequenas se tornam interrupções de sessão de usuário.
O modelo clássico de reinicialização é especialmente problemático para conexões TCP e de longa duração. Sessões de usuário ativas podem ser cortadas, transferências de arquivos podem ficar incompletas, clientes de API podem receber erros, e uma mudança de regra de firewall pode causar uma falha de acesso momentânea. Como resultado, equipes começam a adiar mudanças necessárias, e a agilidade de segurança e operacional sofre.
O problema é mais agudo em conjuntos de regras WAAP e de segurança. Esperar uma janela de manutenção para aplicar uma atualização de regra enquanto um novo padrão de ataque está sendo ativamente observado não é uma posição aceitável. Da mesma forma, operações rotineiras como renovação de certificado ou expansão de pool de backend não devem afetar desnecessariamente o tráfego ao vivo.
O modelo correto é distinguir entre tipos de mudança. Mudanças que podem ser aplicadas em runtime — regras, certificados, health checks, listas de backend e perfis de segurança — devem passar pelo soft reload. Apenas mudanças que afetam parâmetros de criação de serviço — VIP, porta, namespace, limites de recursos ou tipo de serviço — devem exigir um restart controlado.
O Hot Config Reload do TR7 faz essa distinção: soft reload por pool, fallback automático para hard, visibilidade do motivo de restart e fluxo paralelo de operações aplicam mudanças de configuração enquanto minimizam o impacto no tráfego ao vivo.
O TR7 projeta o reload de configuração não como uma única operação uniforme de restart, mas como um fluxo de operação em camadas que decide com base no tipo de mudança.
Cada pool pode receber um reload por meio de seu próprio canal de gerenciamento. Esse modelo garante que uma mudança em um pool seja aplicada sem afetar outros pools.
O TR7 usa o caminho de soft reload que preserva conexões ao vivo por padrão. Se o soft reload falhar ou a mudança exigir um hard restart, o sistema muda para um caminho de restart controlado.
A análise de diff de configuração determina quais campos requerem um reload e quais requerem um restart. Os operadores podem ver antecipadamente se uma mudança pode ser aplicada ao vivo ou envolve uma modificação de creationConfig que exige um restart.
Operações de balanceamento de carga e de container de log podem correr em paralelo quando são independentes. Isso impede que o tempo de edição do pool seja estendido por esperas sequenciais desnecessárias.
O Hot Config Reload combina reload por pool, análise de tipo de mudança, fallback, drain de conexão e operações paralelas em um único fluxo de gerenciamento.
O soft reload ativa a nova configuração para mudanças elegíveis enquanto permite que as conexões existentes se completem naturalmente. O worker antigo entra no modo drain e continua servindo sessões ativas até que sejam fechadas. Novas conexões são tratadas pela configuração atualizada. Essa abordagem elimina a necessidade de vincular mudanças de regra e certificado a uma janela de manutenção.
O TR7 usa por padrão o caminho de soft reload. Se um erro ocorrer durante o soft reload, o sistema recupera via fallback de hard restart. Esse modelo oferece aos operadores um único fluxo seguro: reload sem downtime onde possível, restart de forma controlada onde necessário. Tentativas de reload com falha não resultam em um estado de configuração indeterminado e parcialmente aplicado.
Algumas mudanças não podem ser aplicadas via reload ao vivo porque modificam parâmetros de criação de serviço. Campos como tipo de serviço, limite de CPU, limite de memória, VIP, porta, namespace de rede, imagem ou versão de binário requerem um hard restart. Nesses casos, o comportamento forceHard torna o restart explícito e intencional. Os operadores podem planejar o impacto da mudança com antecedência.
Para cada campo de configuração, o motivo pelo qual uma mudança requer um reload ou restart pode ser mantido na lista restartReasons. Essa visibilidade responde à pergunta "por que essa mudança precisa de um restart?" para a equipe de operações. Torna a tomada de decisão mais clara, especialmente durante processos de gerenciamento de mudanças e aprovação de manutenção. O impacto das mudanças deixa de ser uma caixa preta.
Cada pool é tratado com sua própria estrutura de runtime e canal de gerenciamento. Enquanto um perfil WAAP, certificado ou lista de backend muda em um pool, outros pools continuam correndo sem interrupção. Esse isolamento restringe o raio de impacto das mudanças em grandes plataformas. A equipe de operações recarrega apenas o serviço relevante, não todo o appliance.
Configurações de transporte de log ou de container de log podem ser tratadas separadamente do container de balanceamento de carga. Mudanças no lado do log, portanto, não afetam desnecessariamente a camada de roteamento de tráfego. Da mesma forma, um reload no lado do tráfego não força o pipeline de log a ser interrompido. Essa separação dá um gerenciamento de mudanças mais controlado em toda a plataforma.
Se uma mudança afeta tanto os lados de balanceamento de carga quanto de log, operações elegíveis podem correr em paralelo. A espera sequencial é reduzida e o tempo total do trabalho é encurtado. Isso importa especialmente com configurações grandes ou atualizações que afetam múltiplos subcomponentes. A janela de operação é usada de forma mais eficiente.
Quando um soft reload é aplicado, o worker antigo não é encerrado imediatamente — as conexões existentes têm permissão para fechar naturalmente. Novo tráfego é direcionado para a configuração atualizada enquanto o tráfego existente completa seu fechamento natural. Isso é crítico para conexões TCP de longa duração e sessões de usuário ativas. O objetivo é evitar produzir TCP resets ou desconexões abruptas no momento da mudança.
Quando um limite específico de erros é excedido nas estatísticas do pool, um reload automático pode ser acionado. Esse comportamento ajuda problemas transitórios de runtime a se recuperarem sem aguardar intervenção manual. Para os operadores, isso significa um sinal automático de melhoria de saúde para o serviço. Causas recorrentes de reload ainda devem ser avaliadas por meio de monitoramento e análise de causa raiz.
Atualizações de perfil WAAP, whitelist, conjunto de regras e scripts Lua podem ser tratadas como mudanças recarregáveis ao vivo. Isso permite atualizações rápidas de política de segurança durante um ataque e ativa nova lógica sem interromper o tráfego da aplicação. Mudanças de conjunto de regras não estão vinculadas a um restart completo da plataforma. Essa abordagem aumenta a agilidade das operações de segurança.
O hot config reload opera em conjunto com o caminho de gerenciamento de pool, comportamento de comando, timeout, lógica de retry e a classificação de quais campos contam como mudanças soft ou hard.
Cada pool tem um socket de gerenciamento dedicado. O comando de reload é enviado ao canal de gerenciamento do pool relevante. Essa estrutura é a base do comportamento de reload independente por pool.
O soft reload é acionado por um comando de reload enviado ao canal de gerenciamento. Se o comando for bem-sucedido, a nova configuração é ativada e as conexões existentes são protegidas pelo comportamento de drain. Em caso de falha, o smart reload pode aplicar um fallback de hard restart.
Os nomes de container de pool seguem um padrão consistente vinculado ao poolId. Essa estrutura garante que operações de reload, restart, limpeza de log e health check sejam aplicadas ao container correto. A automação de operações se beneficia dessa nomenclatura determinística.
No modelo padrão, o soft reload é tentado uma vez. Se ocorrer uma exceção ou falha de reload, o sistema muda para o caminho de hard restart. Essa abordagem evita estender o tempo de operação tentando repetidamente um reload com falha.
O timeout total para um trabalho de edição de pool pode ser mantido em 5 minutos. Isso cobre o escopo completo de limpeza de log, reload e restart se necessário. Trabalhos de longa duração não permanecem abertos em estado indeterminado na tela de operações.
Os valores padrão de waitBefore e waitAfter podem ser executados de forma otimizada em 0. Isso remove esperas fixas desnecessárias. O tempo de espera real é determinado pelo estado da operação e pela resposta do sistema.
Um novo conjunto de regras WAAP ou atualização baseada em OWASP pode ser incluído no escopo de soft reload. As sessões de usuário existentes são preservadas enquanto a nova lógica de segurança entra em vigor para requisições recebidas. Não é necessário aguardar uma janela de manutenção durante um ataque ativo.
Quando um certificado próximo do vencimento é atualizado, a mudança de lbCertificates pode ser aplicada via soft reload. Novas conexões TLS usam o certificado atualizado. As conexões existentes fecham naturalmente por meio do comportamento de drain.
Novos nós de backend podem ser adicionados à lista de lbBackends. Após o soft reload, novas conexões se beneficiam do pool expandido. A capacidade é aumentada sem afetar outros pools ou conexões existentes.
Um novo perfil de DDoS ou rate limit pode ser aplicado como uma mudança de configuração ao vivo. A política entra em vigor para requisições recebidas em um curto espaço de tempo. A equipe de operações responde ao ataque sem criar downtime adicional de um restart.
Aplique regras WAAP, certificados, pools de backend e políticas de rate limit sem derrubar sessões ativas. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.