O failover de DHCP não funcionou quando um servidor estava off-line

Question

Estou executando dois servidores DHCP com o Windows Server 2012. Eles são configurados com alta disponibilidade usando "carga balanceada, divisão 50/50". Eles nomearam DC1 e DC2.

Esta manhã, o DC1 estava congelado, havia uma tela preta e o computador não respondia. Não há nada no log de eventos que sugira o que deu errado. Eu acabei tendo que redefinir isso. Parecia que o DC2 não estava recuperando a folga enquanto o DC1 estava fora do ar. Percebi porque um novo computador que eu conectei à rede não estava sendo atribuído a um endereço IP. Além disso, a renovação do endereço falhou em outro computador, isso estava no log de eventos:

Your computer was not able to renew its address from the network (from the DHCP Server) for the Network Card with network address XXX

Your computer has lost the lease to its IP address 192.168.1.XXX on the Network Card with network address XXX.

Se o DC1 não estiver funcionando, o DC2 não deve começar automaticamente a emitir IPs e atender a solicitações de renovação? Ou isso é algo que tem que ser configurado em algum lugar? Eu não estou muito familiarizado com a forma como isso funciona, por isso qualquer ajuda seria apreciada.

Gostaria de saber se isso ocorreu porque o DC1 não foi realmente desconectado ou desligado, apenas congelado?

    

Answer 1

If DC1 is not working, shouldn't DC2 automatically start issuing IPs and addressing renewal requests?

Sim. Em um relacionamento de failover de DHCP com balanceamento de carga, o servidor parceiro do DHCP atribuirá uma concessão de DHCP ao parceiro indisponível.

Como funciona:

As parcerias de failover de DHCP criam um hash do endereço MAC do cliente quando uma solicitação de lease é recebida. Ambos os servidores saberão quais hashes ele precisa responder e ambos os servidores devem poder ver as solicitações. Se uma solicitação não for atendida após um punhado de tentativas do cliente, o servidor parceiro responderá com uma concessão de curto prazo de seu pool de IPs igual ao comprimento de MCLT. (Assim, ele pode expirar rapidamente quando o servidor indisponível estiver em backup). Referência do Servidor 2012 e Referência Obscura de Failover de DHCP do ietf

As solicitações DHCP ocorrem em intervalos de um segundo, e todo esse processo geralmente não é visivelmente mais longo (para um humano) do que receber uma concessão padrão de DHCP.

is this something that has to be configured somewhere?

Você deve verificar sua configuração se não estiver familiarizado com ela. Passar por um bom tutorial seria uma boa maneira de verificar sua configuração. Você também pode fazer uma verificação rápida em um escopo a partir do snap-in do DHCP clicando com o botão direito no escopo e selecionando Exibir estatísticas. Isso mostrará quantos endereços IP são atribuídos e disponibilizados por cada parceiro de failover.

VocêtambémpodevisualizarseuestadodeparceriavisualizandoaspropriedadesdosescoposeselecionandoaguiaFailover.

I'm wondering if this was because DC1 wasn't actually unplugged or turned off, just frozen?

Todos esses estados acionarão o mesmo estado Communtication-Interrupted no servidor parceiro. Seu parceiro secundário deve assumir o leasing sem resposta, independentemente de por que ele não pode se comunicar com o parceiro.

Mais solução de problemas:

Se o servidor secundário ainda não puder exibir concessões em Communication-Interrupted state, sua melhor opção é trabalhar com o administrador da rede. Se você é ele, eu sugeriria pacotes de captura de tráfego DHCP e verificação de endereços auxiliares DHCP correspondentes a ambos servidores DHCP em todos os switches intermediários.

    

Answer 2

Eu nunca tive sorte em ter o balanceamento de carga DHCP funcionando em 2012 ainda. Na verdade, muitas coisas em 2012 são realmente problemáticas e eu já rebaixei para o 2008 R2 várias vezes. Até que consertem tudo. O que você pode fazer é desabilitar o balanceamento de carga e criar um único escopo em cada servidor DHCP e garantir que os dois escopos não ultrapassem o limite. Se você não tiver IPs suficientes no escopo de divisão para atender à rede inteira, crie o escopo em uma sub-rede maior, ou seja, 255.255.254.0 para ambos os escopos.