Criar um grupo de disponibilidade independente de domínio

Aplica-se a: SQL Server

Os grupos de disponibilidade Always On (AGs) exigem um cluster de failover do Windows Server (WSFC) subjacente. A implantação de um WSFC por meio do Windows Server 2012 R2 exigia que os servidores que eram parte de um WSFC, também conhecidos como nós, fossem conectados ao mesmo domínio. Para obter mais informações sobre o AD DS (Active Directory Domain Services), consulte aqui.

A dependência do AD DS e do WSFC é mais complexa do que na implantação anterior com uma configuração de espelhamento de banco de dados (DBM), pois o DBM pode ser implantado em vários data centers usando certificados, sem nenhuma dessas dependências. Um grupo de disponibilidade tradicional que abrange mais de um data center exige que todos os servidores estejam conectados ao mesmo domínio do Active Directory. Domínios diferentes, mesmo domínios confiáveis, não funcionam. Todos os servidores devem ser nós do mesmo WSFC. A figura a seguir mostra essa configuração. O SQL Server 2016 (13.x) e versões posteriores também têm AGs distribuídos, que alcançam esse objetivo de uma maneira diferente.

O Windows Server 2012 R2 introduziu um cluster desanexado do Active Directory, uma forma especializada de um cluster de failover do Windows Server que pode ser usada com grupos de disponibilidade. Esse tipo de WSFC ainda exige que os nós sejam ingressados no mesmo domínio do Active Directory, mas nesse caso, o WSFC usa o DNS, não o domínio. Como ainda existe um domínio envolvido, um cluster desanexado do Active Directory continua não oferecendo uma experiência totalmente livre de domínio.

O Windows Server 2016 introduziu um novo tipo de cluster de failover do Windows Server baseado na fundação do cluster desanexado do Active Directory: um cluster de grupo de trabalho. Um cluster de grupo de trabalho permite que o SQL Server implante um grupo de disponibilidade em um WSFC que não exige AD DS. O SQL Server exige o uso de certificados para a segurança do ponto de extremidade, assim como o cenário de espelhamento de banco de dados exige certificados. Esse tipo de um grupo de disponibilidade é chamado de grupo de disponibilidade independente de domínio. A implantação de um grupo de disponibilidade com um cluster de grupo de trabalho subjacente é compatível com as seguintes combinações de nós que vão compor o WSFC:

• Nenhum nó é ingressado em um domínio.
• Todos os nós são ingressados em domínios diferentes.
• Os nós são combinados, com uma combinação de nós ingressados no domínio e não ingressados no domínio.

A próxima figura mostra um exemplo de um grupo de disponibilidade independente de domínio no qual os nós do Data Center 1 são conectados ao domínio, mas os nós do Data Center 2 usam apenas o DNS. Nesse caso, defina o sufixo DNS em todos os servidores que serão nós do WSFC. Cada aplicativo e servidor que acessa o grupo de disponibilidade devem ver as mesmas informações de DNS.

Um grupo de disponibilidade independente de domínio não serve apenas para cenários multissites ou de recuperação de desastre. Você pode implantá-lo em um único data center e até usá-lo com um grupo de disponibilidade básico. Essa configuração fornece uma arquitetura semelhante ao que era possível usando espelhamento de banco de dados com certificados, conforme mostrado.

A implantação de um grupo de disponibilidade independente de domínio tem algumas limitações conhecidas:

• Os únicos tipos de testemunha disponíveis para uso com o quorum são disco e nuvem, o que é uma novidade no Windows Server 2016. O disco é um problema, pois provavelmente o grupo de disponibilidade não usa disco compartilhado.

• A variante do cluster de grupo de trabalho subjacente de um WSFC só pode ser criada com o PowerShell, mas depois pode ser administrada com o Gerenciador de Cluster de Failover.

• Se o Kerberos for exigido, você deverá implantar um WSFC padrão anexado a um domínio do Active Directory, e um grupo de disponibilidade independente de domínio provavelmente não será uma opção.

• Embora um ouvinte possa ser configurado, ele deve ser registrado no DNS para ser utilizável. Conforme observado acima, o Kerberos não é compatível com o ouvinte.

• Os aplicativos que se conectam ao SQL Server devem usar a autenticação do SQL Server preferencialmente, pois os domínios podem não existir ou podem não estar configurados para funcionar juntos.

• Os certificados serão usados na configuração do grupo de disponibilidade.

Definir e verificar o sufixo DNS em todos os servidores de réplica

Um sufixo DNS comum é necessário para o cluster de grupo de trabalho do grupo de disponibilidade independente de domínio. Para definir e verificar o sufixo DNS em cada Windows Server que hospedará uma réplica para o grupo de disponibilidade, siga estas instruções:

1. Usando o atalho da tecla Windows + X, selecione Sistema.
2. Se o nome do computador e o nome completo do computador forem iguais, isso indicará que o sufixo DNS não está definido. Por exemplo, se o nome do computador for SERVER1, o valor do nome completo do computador não deverá ser apenas SERVER1. Ela será algo como SERVER1.CONTOSO.LAB. CONTOSO.LAB é o sufixo DNS. O valor de Grupo de Trabalho deverá ser WORKGROUP. Se você precisar definir o sufixo DNS, selecione Alterar Configurações.
3. Na caixa de diálogo Propriedades do Sistema, selecione Alterar na guia Nome do Computador.
4. Na caixa de diálogo Alterações no Nome do Computador/Domínio, selecione Mais.
5. Na caixa de diálogo Sufixo DNS e Nome do Computador do NetBIOS, insira o sufixo DNS comum como o sufixo DNS Primário.
6. Selecione OK para fechar a caixa de diálogo Sufixo DNS e Nome do Computador do NetBIOS.
7. Selecione OK para fechar a caixa de diálogo Alterações no Nome do Computador/Domínio.
8. Você é instruído a reiniciar o servidor para as alterações entrarem em vigor. Selecione OK para fechar a caixa de diálogo Alterações no Nome do Computador/Domínio.
9. Selecione Fechar para fechar a caixa de diálogo Propriedades do Sistema.
10. Você é instruído a reiniciar. Se você não desejar reiniciar imediatamente, clique em Reiniciar Mais Tarde, do contrário, clique em Reiniciar Agora.
11. Depois que o servidor for reiniciado, verifique se o sufixo DNS comum está configurado, olhando novamente em Sistema.

Observação

Se você estiver usando várias sub-redes e tiver um DNS estático, será necessário ter um processo implantado para atualizar o registro DNS associado ao ouvinte antes de executar um failover; do contrário, o nome da rede não entrará online.

Criar um grupo de disponibilidade independente de domínio

Atualmente, não é possível criar completamente um grupo de disponibilidade independente de domínio com o SQL Server Management Studio. Embora criar o grupo de disponibilidade independente de domínio seja basicamente igual a criar um grupo de disponibilidade normal, alguns aspectos (como a criação de certificados) só são possíveis com o Transact-SQL. O exemplo a seguir pressupõe uma configuração de grupo de disponibilidade com duas réplicas: uma primária e uma secundária.

1. Usando as instruções em Clusters de grupo de trabalho e vários domínios no Windows Server 2016, implante um cluster de grupos de trabalho composto por todos os servidores que farão parte do grupo de disponibilidade. Certifique-se de que o sufixo DNS comum já está configurado antes de configurar o cluster de grupo de trabalho.

2. Habilite ou desabilite o recurso de grupos de disponibilidade AlwaysOn em cada instância que fará parte do grupo de disponibilidade. Isso exige que toda instância do SQL Server seja reiniciada.

3. Toda instância que hospeda a réplica primária exige uma chave mestra de banco de dados (DMK). Se uma ainda não existir uma DMK, execute o seguinte comando:

   CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password';
   GO
   

4. Na instância que será a réplica primária, crie o certificado que será usado para conexões de entrada nas réplicas secundárias e para proteger o ponto de extremidade na réplica primária.

   CREATE CERTIFICATE InstanceA_Cert
   WITH SUBJECT = 'InstanceA Certificate';
   GO
   

5. Faça backup do certificado. Você também pode fornecer proteção avançada a ele com uma chave privada, se desejado. Esse exemplo não usa uma chave privada.

   BACKUP CERTIFICATE InstanceA_Cert
   TO FILE = 'Backup_path\InstanceA_Cert.cer';
   GO
   

6. Repita as etapas 4 e 5 para criar e fazer backup dos certificados de cada réplica secundária, usando os nomes apropriados para os certificados, como InstanceB_Cert.

7. Na réplica primária, crie um logon para cada réplica secundária do grupo de disponibilidade. Esse logon receberá permissões para se conectar ao ponto de extremidade usado pelo grupo de disponibilidade independente de domínio. Por exemplo, em uma réplica denominada InstanceB:

   CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password';
   GO
   

8. Em cada réplica secundária, crie um logon para a réplica primária. Esse logon tem permissões para se conectar ao ponto de extremidade. Por exemplo, em uma réplica denominada InstanceB:

   CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password';
   GO
   

9. Em todas as instâncias, crie um usuário para cada logon que foi criado. Esse usuário é usado ao restaurar os certificados. Por exemplo, para criar um usuário para a réplica primária:

   CREATE USER InstanceA_User FOR LOGIN InstanceA_Login;
   GO
   

10. Para qualquer réplica que possa ser uma réplica primária, crie um logon e um usuário em todas as réplicas secundárias relevantes.

11. Em cada instância, restaure os certificados para as outras instâncias que tinham um logon e um usuário criados. Na réplica primária, restaure todos os certificados da réplica secundária. Em cada secundária, restaure o certificado da réplica primária e também em qualquer outra réplica que pode ser uma primária. Por exemplo:

    CREATE CERTIFICATE [InstanceB_Cert]
    AUTHORIZATION InstanceB_User
    FROM FILE = 'Restore_path\InstanceB_Cert.cer';
    

12. Crie o ponto de extremidade que será usado pelo grupo de disponibilidade em cada instância que será uma réplica. Para grupos de disponibilidade, o ponto de extremidade deve ter um tipo de DATABASE_MIRRORING. O ponto de extremidade usa o certificado criado na Etapa 4 para essa instância para autenticação. A sintaxe para criar um ponto de extremidade usando um certificado é mostrada no exemplo a seguir. Use o método de criptografia apropriado e outras opções relevantes para o ambiente. Para obter mais informações sobre as opções disponíveis, consulte CRIAR PONTO DE EXTREMIDADE.

    CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP (
        LISTENER_PORT = 5022,
        LISTENER_IP = ALL
    )
    FOR DATABASE_MIRRORING (
        AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL
    );
    

13. Atribua direitos a cada logon criado nessa instância na Etapa 8 para que eles possam se conectar ao ponto de extremidade.

    GRANT CONNECT ON ENDPOINT::DIAG_EP TO [InstanceX_Login];
    GO
    

14. Quando os certificados subjacentes e a segurança do ponto de extremidade são configurados, crie o grupo de disponibilidade usando seu método preferido. Você deve fazer backup, copiar e restaurar manualmente o backup usado para inicializar a réplica secundária ou usar a propagação automática. O uso do Assistente para inicializar as réplicas secundárias envolve o uso de arquivos do protocolo SMB, que talvez não funcionem quando for usado um cluster de grupo de trabalho não conectado ao domínio.

15. Se estiver criando um ouvinte, verifique se seu nome e endereço IP são registrados no DNS.

Conteúdo relacionado

• Usar a caixa de diálogo Assistente de Grupo de Disponibilidade (SQL Server Management Studio)
• Usar a caixa de diálogo Novo Grupo de Disponibilidade (SQL Server Management Studio)
• Criar um grupo de disponibilidade Always On usando o Transact-SQL (T-SQL)