Quando uma mudança de configuração corta o tráfego ao vivo, cada atualização de regra se torna uma janela de manutenção.
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.
Nossa abordagem
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.
O canal de gerenciamento de pool aplica comandos de reload ao vivo de forma independente
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 soft reload é tentado primeiro; o fallback de restart corre se falhar
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 do motivo de restart dá ao operador visibilidade sobre o porquê
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.
As operações ADC e de log correm em paralelo para reduzir o tempo total de edição
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.
Capacidades
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.
Dois tipos de mudança, dois mecanismos — e nenhum pede janela de manutenção
Uma alteração de configuração é aplicada ao serviço em funcionamento por recarga a quente, preservando as ligações vivas. Uma atualização de sistema é outra coisa e é tratada como tal: a imagem seguinte é escrita na segunda ranhura, o equipamento arranca a partir dela e uma verificação de saúde após o arranque decide se fica — se não passar, a imagem anterior regressa sozinha. Manter as duas separadas é o que impede que «mudámos uma regra» e «atualizámos a plataforma» carreguem o mesmo risco.
O soft reload aplica mudanças de configuração preservando conexões ao vivo
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.
Um instantâneo de segurança antes de cada alteração arriscada
As cópias correm por calendário, em cada alteração de configuração e — o que mais importa — automaticamente antes de uma operação crítica: uma alteração de acesso de gestão, a eliminação de uma zona, um restauro. Os momentos mais arriscados do dia de um operador são exatamente os que trazem consigo um caminho de volta automático, por isso a resposta a «conseguimos desfazer isto?» fica decidida antes da alteração e não depois.
O smart reload tenta o caminho soft primeiro e recorre ao hard restart em caso de falha
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.
A opção forceHard fornece restart explícito para mudanças de configuração de criação
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.
Registros de motivo de restart tornam visível o impacto das mudanças de configuração
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.
O reload independente por pool corre sem afetar outros serviços
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.
As operações de container de log são gerenciadas independentemente da camada de balanceamento de carga
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.
A execução paralela reduz o tempo total de edição
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.
O drain de conexão durante o soft reload reduz o risco de quedas de sessão
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.
O reload automático baseado em contador de erros fornece auto-recuperação
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.
Mudanças de WAAP e Lua podem ser incluídas no escopo de soft reload
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.
Profundidade operacional
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.
Socket de gerenciamento de pool
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.
Comando de reload
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.
Modelo de nomenclatura de container
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.
Comportamento de retry de soft
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.
Limite de timeout de trabalho
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.
Durações de espera
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.
Quando usar
Publicar uma nova versão de regra WAAP sem cortar o tráfego ao vivo
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.
Renovar um certificado sem derrubar as conexões existentes
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.
Expandir o pool de backend após autoscaling
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.
Restringir rapidamente a política de rate limit durante um ataque
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.
Perguntas frequentes
Quais mudanças de configuração passam pelo soft reload e quais requerem um restart?
O que acontece se o soft reload falhar?
O que acontece com as sessões ativas durante um soft reload?
Recarregar um pool afeta outros pools?
Como um operador pode ver por que uma mudança requer um restart?
Uma mudança de conjunto de regras WAAP requer uma janela de manutenção?
Mudanças de configuração não devem exigir uma janela de manutenção
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.