Crie um grupo de disponibilidade independente do domínio

Aplica-se a:SQL Server

Os grupos de disponibilidade Sempre Ligados (AGs) requerem um Cluster de Failover do Windows Server subjacente (WSFC). A implementação de um WSFC através do Windows Server 2012 R2 exigia que os servidores participantes num WSFC, também conhecidos como nós, estivessem ligados ao mesmo domínio. Para mais informações sobre os Serviços de Domínio do Active Directory (AD DS), veja O que são domínios e florestas?

A dependência do AD DS e do WSFC é mais complexa do que anteriormente implementada com uma configuração de espelhamento de base de dados (DBM), uma vez que o DBM pode ser implementado em múltiplos centros de dados usando certificados, sem quaisquer dessas dependências. Um grupo tradicional de disponibilidade que abrange mais do que um centro de dados exige que todos os servidores estejam ligados ao mesmo domínio Active Directory. Domínios diferentes, mesmo domínios de confiança, não funcionam. Todos os servidores devem ser nós do mesmo WSFC. A figura seguinte mostra esta configuração. O SQL Server 2016 (13.x) e versões posteriores também têm AGs distribuídos, que alcançam este objetivo de forma diferente.

O Windows Server 2012 R2 introduziu um cluster independente do Active Directory, uma forma especializada de cluster de failover, que pode ser usado com grupos de disponibilidade. Este tipo de WSFC ainda exige que os nós estejam ligados ao mesmo domínio do Active Directory, mas neste caso o WSFC usa DNS, mas não utiliza o domínio. Como um domínio ainda está envolvido, um cluster separado do Active Directory continua a não proporcionar uma experiência livre de domínio.

O Windows Server 2016 introduziu um novo tipo de cluster de failover do Windows Server baseado na base do cluster separado do Active Directory: um cluster de grupos de trabalho. Um cluster de grupo de trabalho permite que o SQL Server implemente um grupo de disponibilidade por cima de um WSFC que não requer AD DS. O SQL Server requer a utilização de certificados para a segurança dos endpoints, tal como o cenário de espelhamento de bases de dados requer certificados. Este tipo de grupo de disponibilidade é chamado de grupo de disponibilidade independente do domínio. A implementação de um grupo de disponibilidade com um cluster de grupo de trabalho subjacente suporta as seguintes combinações para os nós que compõem a WSFC:

• Nenhum nó está associado a um domínio.
• Todos os nós estão ligados a domínios diferentes.
• Os nós são mistos, com uma combinação de nós unidos ao domínio e não unidos ao domínio.

A figura seguinte mostra um exemplo de um grupo de disponibilidade independente de domínio, onde os nós do Data Center 1 são unidos ao domínio, mas os do Data Center 2 apenas usam DNS. Neste caso, defina o sufixo DNS em todos os servidores que serão nós da WSFC. Cada aplicação e servidor que acede ao grupo de disponibilidade deve ver a mesma informação DNS.

Um grupo de disponibilidade independente do domínio não é apenas para cenários multi-site ou de recuperação de desastres. Pode implementá-lo num único centro de dados e até usá-lo com um grupo básico de disponibilidade. Esta configuração oferece uma arquitetura semelhante à que era possível através do espelhamento de base de dados com certificados, como mostrado.

A implementação de um grupo de disponibilidade independente do domínio tem algumas ressalvas conhecidas:

• Os únicos tipos de testemunha disponíveis para uso com quórum são disco e cloud, o que é novo no Windows Server 2016. O disco é problemático porque provavelmente não há uso de disco partilhado pelo grupo de disponibilidade.

• A variante subjacente de cluster de grupo de trabalho de uma WSFC só pode ser criada usando PowerShell, mas pode depois ser administrada usando o Gestor de Clusters de Failover.

• Se o Kerberos for necessário, deve implementar um WSFC padrão que esteja ligado a um domínio do Active Directory, e um grupo de disponibilidade independente do domínio provavelmente não é uma opção.

• Embora um ouvinte possa ser configurado, tem de estar registado no DNS para ser utilizável. Como referido anteriormente, não há suporte do Kerberos para o ouvinte.

• As aplicações que se ligam ao SQL Server devem usar principalmente autenticação SQL Server, uma vez que os domínios podem não existir ou podem não estar configurados para funcionar em conjunto.

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

Defina e verifique o sufixo DNS em todos os servidores réplica

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

1. Usando o atalho Windows Key + X, selecione Sistema.
2. Se o nome do computador e o nome completo forem iguais, 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 deve ser apenas SERVER1. Deveria ser algo como SERVER1.CONTOSO.LAB. CONTOSO.LAB é o sufixo DNS. O valor de Workgroup deveria ser WORKGROUP. Se precisares de definir o sufixo DNS, seleciona Alterar Definições.
3. No diálogo Propriedades do Sistema, selecione Alterar no separador Nome do Computador.
4. No diálogo Nome do Computador/Alterações de Domínio, selecione Mais.
5. No diálogo de Sufixo DNS e Nome de Computador NetBIOS, introduza 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 NetBIOS.
7. Selecione OK para fechar o diálogo Nome do Computador/Alterações de Domínio.
8. É solicitado que reinicie o servidor para que as alterações entrem em vigor. Selecione OK para fechar o diálogo Nome do Computador/Alterações de Domínio.
9. Selecione Fechar para fechar o diálogo Propriedades do Sistema.
10. És convidado a reiniciar. Se não quiseres reiniciar imediatamente, seleciona Reiniciar Depois, caso contrário seleciona Reiniciar Agora.
11. Depois de o servidor reiniciar, verifique se o sufixo DNS comum está configurado verificando novamente o Sistema.

Criar um grupo de disponibilidade independente do domínio

Criar um grupo de disponibilidade independente do domínio não pode atualmente ser feito completamente usando o SQL Server Management Studio. Embora criar o grupo de disponibilidade independente do domínio seja basicamente o mesmo que a criação de um grupo de disponibilidade normal, certos aspetos (como a criação dos certificados) só são possíveis com o Transact-SQL. O exemplo seguinte assume uma configuração de grupo de disponibilidade com duas réplicas: uma primária e uma secundária.

1. Utilizando as instruções dos clusters Workgroup e Multi-domain no Windows Server 2016, implemente um cluster de workgroup composto por todos os servidores que irão participar no grupo de disponibilidade. Certifique-se de que o sufixo DNS comum já está configurado antes de configurar o cluster do grupo de trabalho.

2. Ative ou desative a funcionalidade de grupo de disponibilidade Always On em cada instância que participará no grupo de disponibilidade. Isto requer um reinício de cada instância do SQL Server.

3. Cada instância que hospeda a réplica principal requer uma chave mestra de base de dados (DMK). Se ainda não existir um 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 tanto para ligações de entrada nas réplicas secundárias como para proteger o endpoint na réplica primária.

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

5. Faça backup do certificado. Também podes protegê-lo ainda mais com uma chave privada, se assim o desejares. Este exemplo não usa uma chave privada.

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

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

7. Na réplica principal, deve criar um login para cada réplica secundária do grupo de disponibilidade. Este login recebe permissões para se ligar ao endpoint utilizado pelo grupo de disponibilidade independente do domínio. Por exemplo, para uma réplica chamada InstanceB:

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

8. Em cada réplica secundária, cria um login para a réplica primária. Este login recebe permissões para se ligar ao endpoint. Por exemplo, numa réplica chamada InstanceB:

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

9. Em todas as instâncias, cria um utilizador para cada login que foi criado. Este utilizador é utilizado na restauração dos certificados. Por exemplo, para criar um utilizador para a réplica principal:

   CREATE USER InstanceA_User FOR LOGIN InstanceA_Login;
   GO
   

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

11. Em cada instância, restaurar os certificados das outras instâncias que tiveram login e utilizador criado. Na réplica primária, restaure todos os certificados das réplicas secundárias. Em cada secundário, restaure o certificado digital da réplica primária e também em qualquer outra réplica que possa se tornar primária. Por exemplo:

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

12. Crie o endpoint que será usado pelo grupo de disponibilidade em cada instância e que será uma réplica. Para grupos de disponibilidade, o endpoint deve ter um tipo de DATABASE_MIRRORING. O endpoint utiliza o certificado criado no Step 4 para essa instância para autenticação. A sintaxe é mostrada no exemplo seguinte para criar um endpoint usando um certificado. Use o método de encriptação adequado e outras opções relevantes para o seu ambiente. Para mais informações sobre as opções disponíveis, consulte CREATE ENDPOINT.

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

13. Atribui direitos a cada login criado nessa instância no Passo 8 para poderes ligar-te ao endpoint.

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

14. Depois de configurados os certificados subjacentes e a segurança dos endpoints, crie o grupo de disponibilidade usando o método preferido. Deves fazer backup manualmente, copiar e restaurar o backup usado para inicializar o secundário, ou usar seeding automático. A utilização do Assistente para inicializar as réplicas secundárias envolve o uso de ficheiros Server Message Block (SMB), o que pode não funcionar ao usar um cluster de grupo de trabalho não unido ao domínio.

15. Ao criar um ouvinte, certifique-se de que tanto o nome como o endereço IP estão registados no DNS.

Conteúdo relacionado

• Usar o 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 Transact-SQL (T-SQL)