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

Aplica-se a:SQL Server

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

Hotfixes do .NET que suportam grupos de disponibilidade

Dependendo dos componentes e recursos do SQL Server que você usará com grupos de disponibilidade Always On, talvez seja necessário instalar hotfixes .NET adicionais identificados na tabela a seguir. As correções rápidas podem ser instaladas em qualquer ordem.

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

Para dar suporte ao recurso de grupos de disponibilidade Always On, certifique-se de que cada computador que deve participar de um ou mais grupos de disponibilidade atenda aos seguintes requisitos fundamentais:

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 em disco suficiente: Cada computador no qual uma instância de servidor hospeda uma réplica de disponibilidade deve possuir 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, os bancos de dados secundários correspondentes crescem a mesma quantidade.

• 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 da 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. Analise Restrições ( bancos de dados de disponibilidade) para layouts de disco diferentes entre si.

• 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 do grupo de disponibilidade.

Permissões (sistema Windows)

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

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

Tarefas relacionadas (sistema Windows)

Alterar o HostRecordTTL (usando o PowerShell)

1. Abra a janela do PowerShell por meio do Executar como administrador.

2. Importe o módulo FailoverClusters.

3. Use o cmdlet Get-ClusterResource para localizar o recurso Nome da Rede e, em seguida, use cmdlet Set-ClusterParameter para definir o valor de HostRecordTTL, da seguinte maneira:

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

   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 abres uma nova janela do PowerShell, precisas de importar o módulo FailoverClusters.

Conteúdo relacionado (PowerShell)

• Clustering e Alta Disponibilidade (Blog do Grupo de Clustering de Failover e Balanceamento de Carga de Rede)

• Introdução ao Windows PowerShell num cluster de failover

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

Conteúdo relacionado (sistema Windows)

• Configurar definições de DNS em um Cluster de Failover Multissite

• Registro DNS com o 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 , que são hospedados por instâncias do SQL Server. Uma determinada instância de servidor pode ser uma instância autónoma ou uma instância de cluster de failover (FCI) do SQL Server .

Nesta secção:

• Checklist: Pré-requisitos
• Uso de threads por grupos de disponibilidade
• Permissões
• Tarefas relacionadas
• Conteúdo relacionado

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

Para obter uma lista de recursos suportados pelas edições do SQL Server no Windows, consulte:

• 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 threads por grupos de disponibilidade

Os Grupos de Disponibilidade Always On têm os seguintes requisitos para tópicos 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 usados pelos grupos de disponibilidade é a configuração configurada para o número máximo de threads de 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á de 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 estiver 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 permanecer por mais tempo.

  • Para réplicas secundárias, uma instância do SQL Server usa até 100 threads para reexecução paralela. 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 refazer para cada banco de dados restante. Os threads de refazer serial são liberados após aproximadamente 15 segundos de inatividade.

• Além disso, os grupos de disponibilidade usam threads não compartilhados, da seguinte maneira:

  • Cada réplica primária usa 1 thread de captura de log para cada banco de dados primário. Além disso, ele 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 para reexecução em paralelo, que é um pool de threads a nível de instância, partilhado por todas as bases de dados com tarefas de reexecuçã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 versões anteriores, o número de threads disponíveis para refazer é limitado a 100.

• O SQL Server 2019 (15.x) introduziu o refazer paralelo para bases de dados de grupos de disponibilidade otimizados para memória. 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 estiver otimizado para memória.

Para obter mais informações, consulte Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (um blog de engenheiros do SQL Server CSS).

Permissões (instância do servidor)

Tarefas relacionadas (instância do servidor)

Conteúdo relacionado (instância do servidor)

• Always On - HADRON Learning Series: Uso do pool de trabalhadores para bancos de dados habilitados para HADRON

Recomendações de conectividade de rede

É altamente recomendável que se usem os mesmos links de rede para comunicação entre os nós do WSFC e entre as réplicas de disponibilidade. O uso de links de rede separados pode causar comportamentos inesperados se alguns dos links falharem (mesmo intermitentemente).

Por exemplo, para que um grupo de disponibilidade ofereça suporte a failover automático, a réplica secundária que é o parceiro de failover automático deve estar no estado SINCRONIZADO. Se o link de rede para essa réplica secundária falhar (mesmo intermitentemente), a réplica entrará no estado UNSYNCHRONIZED e não poderá começar a ressincronizar 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 do cliente

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

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

Nesta secção:

• Restrições
• Checklist: Pré-requisitos
• Tarefas relacionadas
• Conteúdo relacionado

Restrições (FCIs)

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

  Além disso, todas as outras réplicas devem ser hospedadas por uma instância do SQL Server que reside num nó de cluster diferente dentro do mesmo cluster de failover do Windows Server. A única exceção é que, ao ser migrado para outro cluster, um grupo de disponibilidade pode temporariamente abarcar dois clusters.

  Advertência

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

• FCIs não oferecem suporte a comutação por falha automática por grupos de disponibilidade: FCIs não oferecem suporte a comutação por falha automática por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade alojada por uma FCI só pode ser configurada para comutação por falha manual.

• Alterando o nome da rede FCI: Se você precisar alterar o nome de rede de uma FCI que hospeda uma réplica de disponibilidade, precisará remover a réplica de seu grupo de disponibilidade e, em seguida, adicionar a réplica de volta ao grupo de disponibilidade. Não é possível remover a réplica primária, portanto, se estiver renomeando uma FCI que esteja hospedando a réplica primária, faça failover para uma réplica secundária e, em seguida, remova a réplica primária anterior e adicione-a novamente. Renomear uma FCI pode alterar o URL do ponto de extremidade de espelhamento do banco de dados. Ao adicionar a réplica, certifique-se de especificar 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 secçã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 determinado grupo de disponibilidade, as réplicas de disponibilidade devem ser hospedadas por instâncias de servidor em execução em nós diferentes do mesmo WSFC. A única exceção é que, ao ser migrado para outro cluster, um grupo de disponibilidade pode temporariamente estar presente em dois clusters.

  Observação

  Cada máquina virtual no mesmo computador físico pode hospedar uma réplica de disponibilidade para o mesmo grupo de disponibilidade porque cada máquina virtual atua como um computador separado.

• Nome exclusivo do grupo de disponibilidade: Cada nome de grupo de disponibilidade deve ser exclusivo no WSFC. O comprimento máximo para um nome de grupo de disponibilidade é de 128 caracteres.

• Réplicas de disponibilidade: Cada grupo de disponibilidade oferece suporte a uma réplica primária e 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 no Windows e no SQL Server. Os nomes de servidor entre o Windows e o SQL Server devem corresponder.

• 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 não há limite imposto. A Microsoft testou até 10 AGs e 100 DBs por máquina física, no entanto, este não é um limite vinculativo. Dependendo da especificação de hardware no servidor e da carga de trabalho, você pode 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, mas não estão limitados a, exaustão de threads de trabalho, tempos de resposta lentos para visualizações do sistema de grupos de disponibilidade e DMVs, e/ou despejos do sistema de despachante paralisados. Certifique-se de testar completamente seu ambiente com uma carga de trabalho semelhante à produção para garantir que ele possa lidar com a capacidade de carga de trabalho máxima dentro dos SLAs do aplicativo. Ao considerar SLAs, certifique-se de considerar a carga em 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 é partilhado entre o SQL Server e o WSFC (Cluster de Failover do Windows Server), com o SQL Server mantendo informações de estado mais detalhadas sobre as instâncias do que o cluster considera. O modelo de gerenciamento é que o SQL Server deve conduzir as transações e é responsável por manter a exibição do estado do cluster sincronizada com a exibição de estado do SQL Server. Se o estado do cluster for alterado fora do SQL Server, é possível que o estado fique fora de sincronia entre o WSFC e o SQL Server, o que pode 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 Gerenciador de Cluster de Failover 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 recursos adicionais (incluindo usuário ou terceiros) na função de grupo de disponibilidade ou alterar as dependências de 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, certifique-se de cumprir os seguintes requisitos.

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 do usuário ao nível de todo o cluster.

  • Acesso de leitura apenas

  • Controlo 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 dá a ele controle total do cluster (por meio do SID de Serviço).

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

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

• 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 elegível para ser adicionado a um grupo de disponibilidade, um banco de dados deve atender aos seguintes pré-requisitos e restrições.

Nesta secção:

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

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

Para ser elegível para ser adicionado a um grupo de disponibilidade, um banco de dados deve:

Restrições (bases de dados de disponibilidade)

• Se o caminho do ficheiro (incluindo a letra da unidade) de uma base de dados secundária for diferente do caminho da base de dados primária correspondente, aplicam-se as seguintes restrições:

  • Assistente para Novo Grupo de Disponibilidade/Assistente para Adicionar Base de Dados ao Grupo de Disponibilidade: A opção Completa não é suportada (na página Seleção Inicial de Sincronização de Dados (Assistentes de Grupo de Disponibilidade Sempre Ativo)).

  • RESTAURAR COM MOVE: Para criar os bancos de dados secundários, os ficheiros da base de dados devem ser RESTAURADOS COM MOVE em cada instância do SQL Server que hospeda uma réplica secundária.

  • Impacto nas operações de arquivo adicional: Uma operação de arquivo adicional posterior na réplica primária pode falhar nos bancos de dados secundários. Essa falha pode fazer com que os bancos de dados secundários sejam suspensos. Isso, por sua vez, faz com que as réplicas secundárias entrem no estado Não Sincronizando.

    Observação

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

• Não é possível descartar um banco de dados que atualmente pertence a um grupo de disponibilidade.

Acompanhamento de bases de dados protegidas por TDE

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

Permissões (bases 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 Oficial da Equipa Always On do SQL Server: O Blog Oficial da Equipa Always On do SQL Server
• Always On - Série de Aprendizado HADRON: Utilização do grupo de trabalho para bases de dados habilitadas para HADRON
• O que é um grupo de disponibilidade Always On?
• Clustering de Failover e Grupos de Disponibilidade Sempre Ativos (SQL Server)
• Suporte de conectividade de driver e cliente para grupos de disponibilidade