Reinicializar NTP, DNS e DHCP após uma queda total da rede: reinício ordenado por dependências

Objetivo

Reiniciar os serviços básicos de infraestrutura de uma rede pequena numa ordem que permita a cada um iniciar corretamente, depois de uma queda total em que NTP, DNS e DHCP ficaram indisponíveis ao mesmo tempo.

Pré-requisitos

Saber quais hosts executam cada serviço; ter acesso por console ou fora de banda (out-of-band) a cada host, já que o acesso remoto que depende da rede pode ainda não funcionar; ter a conectividade básica dos próprios hosts já restabelecida (energia, links de rede físicos ou virtuais ativos); manter os próprios servidores NTP, DNS e DHCP em endereços estáticos, e não obtidos por DHCP.

Passos

1. Suba primeiro o serviço de horário, no(s) host(s) que fornecem NTP. A validação de certificados, o tempo de vida dos tickets Kerberos e a correlação de timestamps de logs ao longo do resto da recuperação dependem de os relógios estarem próximos do correto. Um servidor cujo relógio se desviou muito durante a queda deve poder fazer step ou slew antes de qualquer coisa que verifique períodos de validade de certificados depender dele. Um resolvedor com validação DNSSEC também falha com o relógio muito errado. A dependência, porém, é circular: um servidor NTP cujos upstreams são hostnames (um nome de pool, servidores NTS) não consegue alcançá-los enquanto o DNS não funcionar. Por isso ele fornece apenas a hora do relógio de hardware ou, se estiver configurada, a referência local. Configure ao menos um upstream por endereço IP, ou aceite que a hora seja corrigida novamente quando o DNS estiver ativo.
2. Suba o DNS em seguida, no(s) host(s) que o fornecem. Muitos serviços se localizam entre si, e validam certificados TLS, por nome. Iniciar o DNS antes do DHCP significa que mesmo hosts configurados estaticamente — inclusive o próprio servidor DHCP, se a sua inicialização resolver algum nome — já conseguem fazer resolução.
3. Suba o DHCP por último entre os três. Os clientes que perderam a concessão (lease) precisam do DHCP para voltar a receber endereços. O servidor DHCP pode se beneficiar da hora correta (timestamps de leases, logs) e só precisa de DNS para atualizações dinâmicas de DNS, se estiverem configuradas.
4. Verifique cada serviço a partir de um cliente antes de declarar a rede recuperada: uma verificação de hora (o relógio do cliente converge para o do servidor NTP?), uma consulta de nome para um nome interno e outro externo, e a renovação de uma concessão DHCP num cliente de reserva.
5. Só depois de confirmar os três, reinicie os serviços que dependem de todos eles: autenticação (Kerberos/LDAP, que exigem hora correta e nomes resolvíveis) e serviços de aplicação que usam certificados de curta duração ou descoberta de serviços por nome.

Resultado esperado

Cada serviço deve iniciar sem ficar à espera de um dos outros dois e sem falhar silenciosamente por causa de um deles. Os clientes devem recuperar a conectividade completa na mesma ordem em que os serviços foram subindo, sem uma segunda rodada de reinícios causada por uma dependência esquecida.

Limites e base de verificação

Esta é uma ordem geral proposta, não substitui um runbook específico do ambiente: numa rede em que o endereço do próprio servidor DHCP é estático e o DNS é fornecido pelo mesmo host do NTP, há menos dependências reais a sequenciar. Implantações virtualizadas ou em contêineres, em que os três serviços rodam como serviços de aplicação atrás do seu próprio balanceador de carga, podem ter dependências adicionais — o plano de controle do hypervisor ou do orquestrador — que precisam estar ativas antes de qualquer um dos três. Não se alega nenhum experimento nem medição em campo para esta ordem: ela foi deduzida das dependências habituais desses serviços em relação a hora e resolução de nomes, e um ambiente concreto pode ter menos dependências ou outras diferentes.