Configurar a recuperação de desastres para Ative Directory e DNS

Aplicativos corporativos como SharePoint, Dynamics AX e SAP dependem do Ative Directory e de uma infraestrutura DNS para funcionar corretamente. Ao configurar a recuperação de desastres para aplicativos, muitas vezes você precisa recuperar o Ative Directory e o DNS (Sistema de Nomes de Domínio) antes de recuperar outros componentes do aplicativo, para garantir a funcionalidade correta do aplicativo.

Você pode usar a Recuperação de Site para criar um plano de recuperação de desastres para o Ative Directory. Quando ocorre uma interrupção, você pode iniciar um failover. Pode ter o Active Directory a funcionar em apenas alguns minutos. Se você implantou o Ative Directory para vários aplicativos em seu site primário, por exemplo, para SharePoint e SAP, convém fazer failover do site completo. Você pode primeiro fazer failover do Ative Directory usando a Recuperação de Site. Em seguida, faça failover dos outros aplicativos, usando planos de recuperação específicos do aplicativo.

Este artigo explica como criar uma solução de recuperação de desastres para o Ative Directory. Inclui pré-requisitos e instruções de failover. Você deve estar familiarizado com o Ative Directory e a Recuperação de Site antes de começar.

Pré-requisitos

• Se você estiver replicando para o Azure, prepare os recursos do Azure, incluindo uma assinatura, uma Rede Virtual do Azure, uma conta de armazenamento e um cofre dos Serviços de Recuperação.
• Reveja os requisitos de suporte de todos os componentes.

Replicar o controlador de domínio

• Você deve configurar a replicação do Site Recovery em pelo menos uma máquina virtual (VM) que hospede um controlador de domínio ou DNS.
• Se você tiver vários controladores de domínio em seu ambiente, também deverá configurar um controlador de domínio adicional no site de destino. O controlador de domínio adicional pode estar no Azure ou em um datacenter local secundário.
• Se você tiver apenas alguns aplicativos e um controlador de domínio, convém fazer failover de todo o site juntos. Nesse caso, recomendamos usar a Recuperação de Site para replicar o controlador de domínio para o site de destino, no Azure ou em um datacenter local secundário. Você pode usar o mesmo controlador de domínio replicado ou máquina virtual DNS para failover de teste.
• Se você tiver muitos aplicativos e mais de um controlador de domínio em seu ambiente, ou se planeja fazer failover de alguns aplicativos ao mesmo tempo, além de replicar a máquina virtual do controlador de domínio com a Recuperação de Site, recomendamos que você configure um controlador de domínio adicional no site de destino (no Azure ou em um datacenter local secundário). Para failover de teste, você pode usar um controlador de domínio replicado pelo Site Recovery. Para failover, você pode usar o controlador de domínio adicional no site de destino.

Habilite a proteção com o Site Recovery

Você pode usar a Recuperação de Site para proteger a máquina virtual que hospeda o controlador de domínio ou o DNS.

Proteger a VM

O controlador de domínio que é replicado usando a Recuperação de Site é usado para failover de teste. Certifique-se de que cumpre os seguintes requisitos:

1. O controlador de domínio é um servidor de catálogo global.
2. O controlador de domínio deve ser o proprietário da função FSMO (Flexible Single Master Operations) para funções que são necessárias durante um failover de teste. Caso contrário, essas funções precisarão ser aproveitadas após o failover.

Definir configurações de rede da VM

Para a máquina virtual que hospeda o controlador de domínio ou DNS, em Recuperação de Site, defina as configurações de rede nas configurações de rede da máquina virtual replicada. Isso garante que a máquina virtual esteja conectada à rede correta após o failover.

Proteger o Ative Directory

Proteção site a site

Crie um controlador de domínio no site secundário. Ao promover o servidor para uma função de controlador de domínio, especifique o nome do mesmo domínio que está sendo usado no site primário. Você pode usar o snap-in Sites e Serviços do Ative Directory para definir configurações no objeto de link de site ao qual os sites são adicionados. Ao definir as configurações em um link de site, você pode controlar quando a replicação ocorre entre dois ou mais sites e com que frequência ela ocorre. Para obter mais informações, consulte Agendando a replicação entre sites.

Proteção de site para Azure

Primeiro, crie um controlador de domínio em uma rede virtual do Azure. Ao promover o servidor para uma função de controlador de domínio, especifique o mesmo nome de domínio usado no site primário.

Em seguida, reconfigure o servidor DNS para a rede virtual para usar o servidor DNS no Azure.

Proteção Azure-to-Azure

Primeiro, crie um controlador de domínio em uma rede virtual do Azure. Ao promover o servidor para uma função de controlador de domínio, especifique o mesmo nome de domínio usado no site primário.

Em seguida, reconfigure o servidor DNS para a rede virtual para usar o servidor DNS no Azure.

Considerações sobre failover de teste

Para evitar impacto nas cargas de trabalho de produção, o failover de teste ocorre em uma rede isolada da rede de produção.

A maioria dos aplicativos requer a presença de um controlador de domínio ou um servidor DNS. Portanto, antes que o aplicativo faça failover, você deve criar um controlador de domínio na rede isolada para ser usado para failover de teste. A maneira mais fácil de fazer isso é usar a Recuperação de Site para replicar uma máquina virtual que hospeda um controlador de domínio ou DNS. Em seguida, execute um failover de teste da máquina virtual do controlador de domínio antes de executar um failover de teste do plano de recuperação para o aplicativo.

1. Use o Site Recovery para replicar a máquina virtual que hospeda o controlador de domínio ou DNS.

2. Crie uma rede isolada. Qualquer rede virtual criada no Azure é isolada de outras redes por padrão. Recomendamos que você use o mesmo intervalo de endereços IP para essa rede que você usa em sua rede de produção. Não habilite a conectividade site a site nesta rede.

3. Forneça um endereço IP DNS na rede isolada. Use o endereço IP que você espera que a máquina virtual DNS obtenha. Se você estiver replicando para o Azure, forneça o endereço IP da máquina virtual usada no failover. Para inserir o endereço IP, na máquina virtual replicada, nas Configurações de rede, selecione as configurações de IP de destino.

   

   Gorjeta

   A Recuperação de Site tenta criar máquinas virtuais de teste em uma sub-rede com o mesmo nome e usando o mesmo endereço IP fornecido nas configurações de rede da máquina virtual. Se uma sub-rede com o mesmo nome não estiver disponível na rede virtual do Azure fornecida para failover de teste, a máquina virtual de teste será criada na primeira sub-rede alfabética.

   Se o endereço IP de destino fizer parte da sub-rede selecionada, o Site Recovery tentará criar a máquina virtual de failover de teste usando o endereço IP de destino. Se o IP de destino não fizer parte da sub-rede selecionada, a máquina virtual de failover de teste será criada usando o próximo IP disponível na sub-rede selecionada.

Testar failover para um site secundário

1. Se você estiver replicando para outro site local e usar DHCP, configure DNS e DHCP para failover de teste.
2. Faça um failover de teste da máquina virtual do controlador de domínio que é executada na rede isolada. Use o ponto de recuperação consistente do aplicativo mais recente disponível da máquina virtual do controlador de domínio para fazer o failover de teste.
3. Execute um failover de teste para o plano de recuperação que contém máquinas virtuais nas quais o aplicativo é executado.
4. Quando o teste estiver concluído, limpe o failover de teste na máquina virtual do controlador de domínio. Esta etapa exclui o controlador de domínio que foi criado para failover de teste.

Remover referências a outros controladores de domínio

Quando você inicia um failover de teste, não inclua todos os controladores de domínio na rede de teste. Para remover referências a outros controladores de domínio existentes em seu ambiente de produção, talvez seja necessário aproveitar as funções do FSMO Ative Directory e fazer a limpeza de metadados para controladores de domínio ausentes.

Problemas causados por proteções de virtualização

Importante

Algumas das configurações descritas nesta seção não são configurações padrão ou padrão do controlador de domínio. Se não quiser fazer essas alterações em um controlador de domínio de produção, você pode criar um controlador de domínio dedicado para a Recuperação de Site usar para failover de teste. Faça essas alterações somente nesse controlador de domínio.

A partir do Windows Server 2012, proteções adicionais são incorporadas aos Serviços de Domínio Ative Directory (AD DS). Essas proteções ajudam a proteger os controladores de domínio virtualizados contra reversões de USN (número de sequência de atualização) se a plataforma de hipervisor subjacente oferecer suporte a VM-GenerationID. O Azure suporta VM-GenerationID. Por isso, os controladores de domínio que executam o Windows Server 2012 ou posterior em máquinas virtuais do Azure têm essas proteções adicionais.

Quando VM-GenerationID é redefinido, o valor InvocationID do banco de dados do AD DS também é redefinido. Além disso, o pool de ID relativo (RID) é descartado e SYSVOL a pasta é marcada como não autoritativa. Para obter mais informações, consulte Introdução à virtualização dos Serviços de Domínio Ative Directory e Virtualização segura da Replicação do Sistema de Arquivos Distribuído (DFSR).

O failover para o Azure pode fazer com que o VM-GenerationID seja redefinido. A redefinição de VM-GenerationID aciona proteções adicionais quando a máquina virtual do controlador de domínio é iniciada no Azure. Isso pode resultar em um atraso significativo na capacidade de entrar na máquina virtual do controlador de domínio.

Como esse controlador de domínio é usado apenas em um failover de teste, as proteções de virtualização não são necessárias. Para garantir que o valor VM-GenerationID para a máquina virtual do controlador de domínio não seja alterado, você pode alterar o valor de seguinte DWORD para 4 no controlador de domínio local:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gencounter\Start

Sintomas de salvaguardas de virtualização

Se as proteções de virtualização forem acionadas após um failover de teste, você poderá ver um ou mais dos seguintes sintomas:

• O valor GenerationID muda:

• O valor InvocationID muda:

• SYSVOL pasta e NETLOGON compartilhamentos não estão disponíveis.

  

  

• Os bancos de dados DFSR são excluídos.

Solucionar problemas do controlador de domínio durante o failover de teste

Importante

Algumas das configurações descritas nesta seção não são configurações padrão ou padrão do controlador de domínio. Se não quiser fazer essas alterações em um controlador de domínio de produção, você pode criar um controlador de domínio dedicado para failover de teste de Recuperação de Site. Faça as alterações somente nesse controlador de domínio dedicado.

1. No prompt de comando, execute o seguinte comando para verificar se SYSVOL a pasta e NETLOGON a pasta são compartilhadas:

   NET SHARE

2. No prompt de comando, execute o seguinte comando para garantir que o controlador de domínio esteja funcionando corretamente:

   dcdiag /v > dcdiag.txt

3. No log de saída, procure o seguinte texto. O texto confirma que o controlador de domínio está funcionando corretamente.

   • passed test Connectivity
   • passed test Advertising
   • passed test MachineAccount

Se as condições anteriores forem satisfeitas, é provável que o controlador de domínio esteja funcionando corretamente. Se não estiver, conclua as seguintes etapas:

1. Faça uma restauração autoritativa do controlador de domínio. Tenha em mente as seguintes informações:

   • Embora não recomendemos a replicação usando o FRS (Serviço de Replicação de Arquivos), se você usar a replicação FRS, siga as etapas para uma restauração autoritativa. O processo é descrito em Usando a chave do Registro BurFlags para reinicializar o Serviço de Replicação de Arquivos.

     Para obter mais informações sobre BurFlags, consulte a postagem do blog D2 e D4: Para que serve?.

   • Se você usar a replicação DFSR, conclua as etapas para uma restauração autoritativa. O processo é descrito em Forçar uma sincronização autoritativa e não autoritativa para a pasta SYSVOL replicada pelo DFSR (como "D4/D2" para FRS).

     Você também pode usar as funções do PowerShell. Para obter mais informações, consulte DFSR-SYSVOL authoritative/non-authoritative restore PowerShell functions.

2. Ignore o requisito de sincronização inicial definindo a seguinte chave do Registro como 0 no controlador de domínio local. Se o DWORD não existir, você poderá criá-lo no nó Parâmetros .

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

   Para obter mais informações, consulte Solucionar problemas de ID de Evento DNS 4013: O servidor DNS não pôde carregar zonas DNS integradas ao AD.

3. Desative o requisito de que um servidor de catálogo global esteja disponível para validar o login do usuário. Para fazer isso, no controlador de domínio local, defina a seguinte chave do Registro como 1. Se o DWORD não existir, você pode criá-lo no nó Lsa .

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures

   Para obter mais informações, consulte Como funciona o catálogo global.

DNS e controlador de domínio em máquinas diferentes

Se estiver a executar o controlador de domínio e o DNS na mesma VM, pode ignorar este procedimento.

Se o DNS não estiver na mesma VM que o controlador de domínio, você precisará criar uma VM DNS para o failover de teste. Você pode usar um novo servidor DNS e criar todas as zonas necessárias. Por exemplo, se o seu domínio do Ative Directory for contoso.com, pode criar uma zona DNS com o nome contoso.com. As entradas que correspondem ao Ative Directory devem ser atualizadas no DNS da seguinte maneira:

1. Verifique se essas configurações estão em vigor antes que qualquer outra máquina virtual no plano de recuperação seja iniciada:

   • A zona deve ser nomeada após o nome da raiz da floresta.
   • A zona deve ser apoiada por arquivos.
   • A zona deve estar habilitada para atualizações seguras e não seguras.
   • O resolvedor da máquina virtual que hospeda o controlador de domínio deve apontar para o endereço IP da máquina virtual DNS.

2. Execute o seguinte comando na VM que hospeda o controlador de domínio:

   nltest /dsregdns

3. Execute os seguintes comandos para adicionar uma zona no servidor DNS, permitir atualizações não seguras e adicionar uma entrada para a zona ao DNS:

   dnscmd /zoneadd contoso.com  /Primary
   
   dnscmd /recordadd contoso.com  contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1
   
   dnscmd /recordadd contoso.com %computername%  A <IP_OF_DNS_VM>
   
   dnscmd /config contoso.com /allowupdate 1
   

Próximos passos

Saiba mais sobre como proteger cargas de trabalho empresariais com o Azure Site Recovery.