Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On

Aplica-se a:SQL Server

Este artigo descreve considerações para a implantação de grupos de disponibilidade Always On, incluindo pré-requisitos, restrições e recomendações para computadores host, clusters de failover do Windows Server (WSFC), instâncias de servidor e grupos de disponibilidade. Para cada um desses componentes, são indicadas considerações sobre segurança e as permissões exigidas, se houver.

Hotfixes do .NET que dão suporte a grupos de disponibilidade

Dependendo dos componentes e recursos do SQL Server usados com o Grupos de disponibilidade Always On, você poderá precisar instalar hotfixes do .NET adicionais identificados na tabela a seguir. Você pode instalar os hotfixes em qualquer ordem.

Lista de verificação: requisitos (sistema Windows)

Para oferecer suporte ao recurso Grupos de disponibilidade AlwaysOn , verifique se cada computador que participará de um ou mais grupos de disponibilidade atende aos seguintes requisitos básicos:

Recomendações para computadores que hospedam réplicas de disponibilidade (sistema Windows)

• Sistemas comparáveis: para um determinado grupo de disponibilidade, todas as réplicas de disponibilidade devem ser executadas em sistemas comparáveis que possam lidar com cargas de trabalho idênticas.

• Adaptadores de rede dedicados: Para obter o melhor desempenho, use um adaptador de rede dedicado (placa de interface de rede) para grupos de disponibilidade Always On.

• Espaço suficiente em disco: cada computador em que uma instância de servidor hospeda uma réplica de disponibilidade deve ter espaço em disco suficiente para todos os bancos de dados do grupo de disponibilidade. Lembre-se de que à medida que os bancos de dados primários crescem, seus bancos de dados secundários correspondentes crescem na mesma proporção.

• Layout de disco idêntico: cada computador no qual uma instância de servidor hospeda uma réplica de disponibilidade deve ter um layout de disco idêntico (com letras e tamanhos exatos de unidade de disco) para garantir que os caminhos de arquivo para arquivos de banco de dados (mdf, ldf) sejam espelhados, evitando complicações durante a propagação e sincronização. Consulte as Restrições (bancos de dados de disponibilidade) para layouts de disco diferentes.

• Configuração do administrador de recursos: Se você estiver usando o administrador de recursos, use a mesma configuração do administrador de recursos em todas as instâncias que hospedam réplicas de grupo de disponibilidade.

Permissões (sistema Windows)

Para administrar um WSFC, o usuário deve ser um administrador do sistema em cada nó do cluster.

Para obter mais informações sobre a conta usada para administrar o cluster, confira Apêndice A: Requisitos do cluster de failover.

Altere o HostRecordTTL (usando o PowerShell)

1. Abra a janela do PowerShell por meio da opção Executar como Administrador.

2. Importe o módulo FailoverClusters.

3. Use o cmdlet Get-ClusterResource para encontrar o recurso de Nome de Rede, depois use o cmlet Set-ClusterParameter para definir o valor de HostRecordTTL , da seguinte maneira:

   Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   O exemplo do PowerShell a seguir define o HostRecordTTL como 300 segundos para um recurso de nome de rede chamado SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Dica

   Sempre que você abrir uma nova janela do PowerShell, deverá importar o módulo FailoverClusters .

Conteúdo relacionado (PowerShell)

• Clustering e alta disponibilidade (blog da equipe de Cluster de Failover e Balanceamento de Carga de Rede)

• Introdução ao Windows PowerShell em um cluster de failover

• Comandos de recursos de cluster e cmdlets equivalentes no Windows PowerShell

Conteúdo relacionado (sistema Windows)

• Definir configurações de DNS em um cluster de failover de vários sites

• Registro de DNS com recurso de nome de rede

Pré-requisitos e restrições da instância do SQL Server

Cada grupo de disponibilidade requer um conjunto de parceiros de failover, conhecidos como réplicas de disponibilidade, hospedadas em instâncias do SQL Server. Uma instância de servidor específica pode ser uma instância independente ou uma instância de cluster de failover (FCI) do SQL Server.

Nesta seção:

• Lista de verificação: Pré-requisitos
• Uso de thread por grupos de disponibilidade
• Permissões
• Tarefas relacionadas
• Conteúdo relacionado

Lista de verificação: pré-requisitos (instância de servidor)

Para obter uma lista dos recursos com suporte das edições do SQL Server no Windows, confira:

• Edições e recursos com suporte do SQL Server 2025
• Edições e recursos com suporte do SQL Server 2022
• Edições e recursos com suporte do SQL Server 2019
• Edições e recursos com suporte do SQL Server 2017
• Edições e recursos com suporte do SQL Server 2016

Uso de thread por grupos de disponibilidade

Os grupos de disponibilidade Always On têm os seguintes requisitos para threads de trabalho:

• Em uma instância ociosa do SQL Server, os grupos de disponibilidade Always On usam 0 threads.

• O número máximo de threads usado pelos grupos de disponibilidade é o valor configurado para o número máximo de threads do servidor (max worker threads) menos 40.

• As réplicas de disponibilidade hospedadas em uma determinada instância de servidor compartilham um único pool de threads no SQL Server 2019 (15.x) e em versões anteriores.

  Os threads são compartilhados sob demanda, da seguinte maneira:

  • Normalmente, há 3 a 10 threads compartilhados, mas esse número pode aumentar dependendo da carga de trabalho da réplica primária.

  • Se um determinado thread ficar ocioso por um tempo, ele será liberado novamente no pool de threads geral do SQL Server. Normalmente, um thread inativo é liberado após ~15 segundos de inatividade. No entanto, dependendo da última atividade, um thread ocioso pode ser retido por mais tempo.

  • Uma instância do SQL Server usa até 100 threads de restauração paralela para réplicas secundárias. Cada banco de dados usa até metade do número total de núcleos de CPU, mas não mais de 16 threads por banco de dados. Se o número total de threads necessários para uma única instância exceder 100, o SQL Server usará um único thread de restauração para cada banco de dados restante. Os threads de restauração serial são liberados após, aproximadamente, 15 segundos de inatividade.

• Além disso, os grupos de disponibilidade usam threads não compartilhadas, conforme a seguir:

  • Cada réplica primária usa 1 thread de captura de log para cada banco de dados primário. Além de isso, ela usa 1 thread de envio de log para cada banco de dados secundário. Os threads de envio de log são liberados após ~15 segundos de inatividade.

  • Um backup em uma réplica secundária mantém um thread na réplica primária durante a operação de backup.

• O SQL Server 2022 (16.x) introduziu o pool de threads de restauração paralela, que é um pool de threads em nível de instância compartilhado com todos os bancos de dados que têm trabalho de restauração. Com esse pool, o mesmo conjunto de threads pode processar os registros de log para diferentes bancos de dados ao mesmo tempo (em paralelo). No SQL Server 2019 (15.x) e em versões anteriores, o número de threads disponíveis para restauração é limitado a 100.

• O SQL Server 2019 (15.x) introduziu o redo paralelo para bancos de dados com otimização de memória de grupos de disponibilidade. No SQL Server 2016 (13.x) e no SQL Server 2017 (14.x), as tabelas baseadas em disco não usam refazer paralelo se um banco de dados em um grupo de disponibilidade também for otimizado para memória.

Para obter mais informações, consulte Always On – HADRON Learning Series: Uso do pool de trabalho para bancos de dados habilitados para HADRON (um blog de engenheiros do SQL Server do CSS).

Permissões (instância de servidor)

Tarefas relacionadas (instância de servidor)

Conteúdo relacionado (instância de servidor)

• Always On – HADRON Learning Series: uso do pool de trabalho para bancos de dados habilitados para HADRON

Recomendações de conectividade de rede

É altamente recomendável usar os mesmos links de rede para a comunicação entre nós do WSFC e a comunicação entre réplicas de disponibilidade. Usar links de rede separados pode causar comportamentos inesperados se algum dos links falhar (até mesmo com intermitência).

Por exemplo, para que um grupo de disponibilidade ofereça suporte a failover automático, a réplica secundária que seja o parceiro de failover automático deve estar no estado SYNCHRONIZED. Se o link de rede para essa réplica secundária falhar (ainda que com intermitência), a réplica entrará no estado UNSYNCHRONIZED e não poderá começar a ressincronização até que o link seja restaurado. Se o WSFC solicitar um failover automático enquanto a réplica secundária não estiver sincronizada, o failover automático não ocorrerá.

Suporte à conectividade de cliente

Para obter informações sobre o suporte a grupos de disponibilidade Always On para conectividade de cliente, confira Suporte de driver e conectividade de cliente para grupos de disponibilidade.

Pré-requisitos e restrições para usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade

Nesta seção:

• Restrições
• Lista de verificação: Pré-requisitos
• Tarefas relacionadas
• Conteúdo relacionado

Restrições (FCIs)

• Os nós de cluster de uma FCI podem hospedar somente uma réplica de determinado grupo de disponibilidade: se você adicionar uma réplica de disponibilidade a uma FCI, os nós do WSFC, que são possíveis proprietários da FCI, não poderão hospedar outra réplica para o mesmo grupo de disponibilidade. Para evitar possíveis conflitos, é recomendável configurar os proprietários possíveis da instância de cluster de failover. Isso evitará a possibilidade de que um único WSFC tente hospedar duas réplicas de disponibilidade para o mesmo grupo de disponibilidade.

  Além disso, cada uma das outras réplicas deve ser hospedada por uma instância do SQL Server que resida em um nó de cluster diferente no mesmo cluster de failover do Windows Server. A única exceção é que, embora tenha sido migrado para outro cluster, um grupo de disponibilidade pode temporariamente abranger dois clusters.

  Aviso

  Usar o Gerenciador de Cluster de Failover para mover uma FCI que hospeda um grupo de disponibilidade para um nó que já hospeda uma réplica do mesmo grupo de disponibilidade pode resultar na perda da réplica do grupo de disponibilidade, impedindo que ela seja colocada online no nó de destino. Um único nó de um cluster de failover não pode hospedar mais de uma réplica do mesmo grupo de disponibilidade. Para obter mais informações sobre como isso ocorre e como se recuperar, consulte o artigo no blog Réplica removida inesperadamente do grupo de disponibilidade.

• As FCIs não dão suporte ao failover automático por grupos de disponibilidade: As FCIs não dão suporte ao failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade hospedada por uma FCI pode ser configurada apenas para failover manual.

• Alteração do nome da rede de FCI: caso precise alterar o nome de rede de uma FCI que hospeda uma réplica de disponibilidade, você precisará remover a réplica de seu grupo de disponibilidade e, então, adicionar novamente a réplica ao grupo de disponibilidade. Você não pode remover a réplica primária; portanto, se estiver renomeando uma FCI que hospeda a réplica primária, faça failover para uma réplica secundária e, em seguida, remova a antiga réplica primária e adicione-a novamente. Renomear uma FCI pode alterar a URL do endpoint de espelhamento do banco de dados. Ao adicionar a réplica, especifique a URL do ponto de extremidade atual.

Lista de verificação: Pré-requisitos (FCIs)

Tarefas relacionadas (FCIs)

Conteúdo relacionado (FCIs)

• Cluster de failover e grupos de disponibilidade Always On (SQL Server)

• Guia de Arquitetura Always On: Criando uma solução de alta disponibilidade e recuperação de desastres usando instâncias de cluster de failover e grupos de disponibilidade

Pré-requisitos e restrições do grupo de disponibilidade

Nesta seção:

• Restrições
• Requisitos
• Segurança
• Tarefas relacionadas

Restrições (grupos de disponibilidade)

• As réplicas de disponibilidade devem ser hospedadas por nós diferentes de um WSFC: para um grupo de disponibilidade específico, as réplicas de disponibilidade devem ser hospedadas por instâncias de servidor executadas em diferentes nós do mesmo WSFC. A única exceção é que, embora tenha sido migrado para outro cluster, um grupo de disponibilidade pode temporariamente abranger dois clusters.

  Observação

  Cada uma das máquinas virtuais no mesmo computador físico pode hospedar uma réplica de disponibilidade para o mesmo grupo de disponibilidade, pois cada uma delas funciona como um computador separado.

• Nome do grupo de disponibilidade exclusivo: o nome de cada grupo de disponibilidade deve ser exclusivo no WSFC. O tamanho máximo de um nome de grupo de disponibilidade é 128 caracteres.

• Réplicas de disponibilidade: cada grupo de disponibilidade dá suporte a uma réplica primária e a até oito réplicas secundárias. Todas as réplicas podem ser executadas no modo de confirmação assíncrona ou até cinco delas podem ser executadas no modo de confirmação síncrona (uma réplica primária com duas réplicas secundárias síncronas). Cada réplica deve ter um nome de servidor exclusivo tanto no Windows quanto no SQL Server. Os nomes de servidor entre o Windows e o SQL Server devem ser correspondentes.

• Número máximo de grupos de disponibilidade e bancos de dados de disponibilidade por computador: o número real de bancos de dados e grupos de disponibilidade que você pode colocar em um computador (VM ou físico) depende do hardware e da carga de trabalho, mas nenhum limite é imposto. A Microsoft testou até 10 AGs e 100 DBs por máquina física; no entanto, esse não é um limite vinculante. Dependendo da especificação de hardware no servidor e da carga de trabalho, é possível colocar um número maior de bancos de dados e grupos de disponibilidade em uma instância do SQL Server. Os sinais de sistemas sobrecarregados podem incluir, entre outros, esgotamento de thread de trabalho, lentidão nos tempos de resposta para exibições do sistema dos grupos de disponibilidade e nas DMVs e despejos de sistema do dispatcher parados. Certifique-se de testar exaustivamente seu ambiente com uma carga de trabalho semelhante à de produção para garantir que ele possa suportar os picos de carga dentro dos SLAs da sua aplicação. Ao considerar SLAs, não se esqueça de considerar a carga sob condições de falha, bem como os tempos de resposta esperados.

• Não use o Gerenciador de Cluster de Failover para manipular grupos de disponibilidade. O estado de uma FCI do SQL Server é compartilhado entre o SQL Server e o Cluster de Failover do Windows Server (WSFC), com o SQL Server mantendo informações mais detalhadas sobre o estado das instâncias do que as necessárias para o cluster. O modelo de gerenciamento é que o SQL Server deve orientar as transações e é responsável por manter a exibição do estado do cluster em sincronia com a exibição do estado do SQL Server. Se o estado do cluster for alterado fora do SQL Server, é possível que o estado saia da sincronização entre o WSFC e o SQL Server, o que poderá levar a um comportamento imprevisível.

  Por exemplo:

  • Não altere nenhuma propriedade do grupo de disponibilidade, como os possíveis proprietários.

  • Não use o Failover Cluster Manager para fazer failover de grupos de disponibilidade. Você deve usar o Transact-SQL ou o SQL Server Management Studio.

• Não adicione recursos nem altere dependências associadas à função de grupo de disponibilidade. Não recomendamos colocar quaisquer recursos adicionais (incluindo recursos de usuário ou de terceiros) na função do grupo de disponibilidade nem alterar as dependências da função, pois essas alterações podem afetar negativamente o desempenho de failover.

Pré-requisitos (grupos de disponibilidade)

Ao criar ou reconfigurar uma configuração de grupo de disponibilidade, cumpra os requisitos a seguir.

Segurança (grupos de disponibilidade)

• A segurança é herdada do WSFC. O cluster de failover do Windows Server fornece dois níveis de segurança de usuário no nível do cluster inteiro:

  • Acesso somente para leitura

  • Controle total

    Os grupos de disponibilidade Always On precisam de controle total e habilitar grupos de disponibilidade Always On em uma instância do SQL Server fornece controle total do cluster (por meio do Serviço SID).

    Não é possível adicionar nem remover diretamente a segurança de uma instância de servidor no Gerenciador de Cluster. Para gerenciar sessões de segurança de cluster, use o SQL Server Configuration Manager ou o WMI equivalente no SQL Server.

• Cada instância do SQL Server deve ter permissões para acessar o Registro, o cluster e assim sucessivamente.

• Recomendamos que você use criptografia para conexões entre instâncias de servidor que hospedam réplicas de disponibilidade de grupos de disponibilidade Always On.

Permissões (grupos de disponibilidade)

Tarefas relacionadas (grupos de disponibilidade)

Pré-requisitos e restrições do banco de dados de disponibilidade

Para ser qualificado para ser adicionado a um grupo de disponibilidade, um banco de dados precisa atender aos pré-requisitos e restrições a seguir.

Nesta seção:

• Requisitos
• Restrições
• Recomendações para computadores que hospedam réplicas de disponibilidade (sistema Windows)
• Permissões
• Tarefas relacionadas

Lista de verificação: requisitos (bancos de dados de disponibilidade)

Para estar qualificado para ser adicionado a um grupo de disponibilidade, um banco de dados deve ter as seguintes condições:

Restrições (bancos de dados de disponibilidade)

• Se o caminho do arquivo (incluindo a letra da unidade) de um banco de dados secundário diferir do caminho do banco de dados primário correspondente, as seguintes restrições se aplicarão:

  • Assistente para Novo Grupo de Disponibilidade/Assistente para Adicionar Banco de Dados ao Grupo de Disponibilidade: Não há suporte para a opção Completo (na página Selecionar Sincronização inicial de dados (assistentes de grupo de disponibilidade AlwaysOn),

  • RESTORE WITH MOVE: Para criar os bancos de dados secundários, os arquivos de banco de dados devem ser restaurados WITH MOVE em cada instância de SQL Server que hospeda uma réplica secundária.

  • Impacto em operações de adição de arquivos: uma operação de adição de arquivos posterior na réplica primária pode falhar nos bancos de dados secundários. Esta falha pode levar à suspensão de bancos de dados secundários. Isso, por sua vez, faz com que as réplicas secundárias entrem no estado NOT SYNCHRONIZING.

    Observação

    Para obter informações sobre como responder a uma operação de adição de arquivo com falha, consulte Solucionar problemas de uma operação de adição de arquivo com falha (grupos de disponibilidade Always On).

• Você não pode remover um banco de dados que pertence atualmente a um grupo de disponibilidade.

Acompanhamento para bancos de dados protegidos por TDE

Se você usar criptografia transparente de dados (TDE), o certificado ou a chave assimétrica usados para criar e descriptografar outras chaves devem ser os mesmos em todas as instâncias de servidor que hospedam uma réplica de disponibilidade do grupo de disponibilidade. Para obter mais informações, consulte Mover um banco de dados protegido por TDE para outro SQL Server.

Permissões (bancos de dados de disponibilidade)

Requer permissão ALTER no banco de dados.

Tarefas relacionadas (bancos de dados de disponibilidade)

Conteúdo relacionado

• Guia de soluções Always On do Microsoft SQL Server para alta disponibilidade e recuperação de desastres
• Blog da equipe Always On do SQL Server: o blog oficial da equipe Always On do SQL Server
• Always On – HADRON Learning Series: uso do pool de trabalho para bancos de dados habilitados para HADRON
• O que é um grupo de disponibilidade Always On?
• Cluster de failover e grupos de disponibilidade Always On (SQL Server)
• Suporte de driver e conectividade de cliente para grupos de disponibilidade