Pré-requisitos, restrições e recomendações para grupos de disponibilidade AlwaysOn (SQL Server)

Este tópico descreve considerações sobre a implantação do Grupos de Disponibilidade AlwaysOn, inclusive pré-requisitos, restrições e recomendações para computadores host, clusters WSFC (Windows Server Failover Clustering), 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.

Observação importanteImportante

Antes de implantar o Grupos de Disponibilidade AlwaysOn, é altamente recomendável que você leia cada seção deste tópico.

Neste tópico:

  • Hotfixes do .Net que dão suporte a grupos de disponibilidade AlwaysOn

  • Requisitos e recomendações do sistema Windows

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

  • Recomendações de conectividade de rede

  • Suporte à conectividade de cliente

  • 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

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

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

  • Conteúdo relacionado

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

Dependendo dos componentes e recursos do SQL Server 2012 usados com o Grupos de Disponibilidade AlwaysOn, você poderá precisar instalar hotfixes .Net adicionais identificados na tabela seguinte. Os hotfixes podem ser instalados em qualquer ordem.

   

Recurso dependente

Hotfix

Link

Caixa de seleção

Reporting Services

O hotfix para .Net 3.5 SP1 adiciona suporte a recursos do Cliente SQL para AlwaysOn de intenção de Leitura, somente leitura e multisubnetfailover. O hotfix precisa ser instalado em cada servidor de relatório do Reporting Services.

KB 2654347: Hotfix para .Net 3.5 SP1 para adicionar suporte para recursos AlwaysOn

Requisitos e recomendações do sistema Windows

Nesta seção:

  • Lista de verificação: requisitos

  • Hotfixes do Windows que dão suporte a grupos de disponibilidade AlwaysOn (Sistema do Windows)

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

  • Permissões

  • Tarefas relacionadas

  • Conteúdo relacionado

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:

   

Requisito

Link

Caixa de seleção

Verifique se o sistema não é um controlador de domínio.

Os grupos de disponibilidade não têm suporte em controladores de domínio.

Caixa de seleção

Verifique se cada computador está executando o Windows Server 2008 (não WOW64) na versão x86, x64 ou posterior.

O WOW64 (Windows de 32 bits no Windows de 64 bits) não oferece suporte ao Grupos de Disponibilidade AlwaysOn.

Caixa de seleção

Verifique se cada computador é um nó em um cluster WSFC (Windows Server Failover Clustering).

WSFC (Windows Server Failover Clustering) com o SQL Server

Caixa de seleção

Verifique se o cluster WSFC contém nós suficientes para oferecer suporte às suas configurações de grupo de disponibilidade.

Um nó WSFC pode hospedar apenas uma réplica de disponibilidade para determinado grupo de disponibilidade. Em um nó WSFC específico, uma ou mais instâncias do SQL Server podem hospedar réplicas de disponibilidade para muitos grupos de disponibilidade.

Pergunte aos administradores do banco de dados quantos nós WSFC são necessários para oferecer suporte às réplicas de disponibilidade dos grupos de disponibilidade planejados.

Visão geral de grupos de disponibilidade AlwaysOn (SQL Server).

Caixa de seleção

Verifique se todos os hotfixes do Windows aplicáveis foram instalados em todos os nós do cluster WSFC.

Observação importanteImportante

Vários hotfixes são necessários ou recomendados para os nós de um cluster WSFC no qual o Grupos de Disponibilidade AlwaysOn está sendo implantado. Para obter mais informações, consulte Hotfixes do Windows que oferecem suporte a grupos de disponibilidade AlwaysOn (Sistema do Windows), posteriormente nesta seção.

Observação importanteImportante

Verifique também se seu ambiente está corretamente configurado para a conexão a um grupo de disponibilidade. Para obter mais informações, consulte Conectividade de cliente AlwaysOn (SQL Server).

Hotfixes do Windows que dão suporte a grupos de disponibilidade AlwaysOn (Sistema do Windows)

Dependendo da sua topologia de cluster, diversos hotfixes adicionais do Windows Server 2008 Service Pack (SP2) ou Windows Server 2008 R2 podem ser aplicáveis para dar suporte ao Grupos de Disponibilidade AlwaysOn. A tabela a seguir identifica esses hotfixes. Esses hotfixes podem ser instalados em qualquer ordem.

     

Aplica-se ao Windows 2008 SP2

Aplica-se ao Windows 2008 R2 SP1

Incluído no Windows 2012

Para dar suporte a…

Hotfix

Link

Caixa de seleção

    √

    √

Sim

Configurando o quorum ideal de WSFC

Em cada nó WSFC, verifique se o hotfix descrito no artigo 2494036 da Base de Dados de Conhecimento foi instalado.

Este hotfix oferece suporte à configuração de quorum ideal com destinos de failover não automático. Essa funcionalidade aprimora os clusters multissite, permitindo que você selecione os nós que votam.

KB 2494036:  Um hotfix está disponível para permitir que você configure um nó de cluster que não tem votos de quorum no Windows Server 2008 e no Windows Server 2008 R2

Para obter mais informações sobre votação de quorum, consulte Configuração de modos de quorum WSFC e votação (SQL Server)

Caixa de seleção

    √

    √

Sim

Uso mais eficiente da largura de banda de rede

Em cada nó WSFC, verifique se o hotfix descrito no artigo 2616514 da Base de Dados de Conhecimento foi instalado.

Sem este hotfix, o serviço de Cluster envia notificações do Registro desnecessárias entre nós de cluster. Este comportamento limite a largura de banda de rede, que é um problema sério para Grupos de Disponibilidade AlwaysOn.

KB 2616514:  O serviço de cluster envia notificações desnecessárias de alterações da chave do Registro entre nós de cluster no Windows Server 2008 ou no Windows Server 2008 R2

Caixa de seleção

    √

Não aplicável

O teste de armazenamento de VPD em discos que não estão disponíveis a todos os nós WSFC

Se um nó WSFC estiver executando o Windows Server 2008 R2 Service Pack 1 (SP1) e o teste de armazenamento Validar VPD (Vital Product Data) do dispositivo SCSI falhar depois de execução incorreta em discos online e não disponíveis a todos os nós no cluster WSFC, instale o hotfix descrito no artigo 2531907 da Base de Dados de Conhecimento.

Este hotfix elimina avisos incorretos ou erros no relatório de validação quando há discos online.

KB 2531907:  O teste Validar VPD (Vital Product Data) do dispositivo SCSI apresenta falha depois que você instala o Windows Server 2008 R2 SP1

Caixa de seleção

    √

Sim

Failover mais rápido para réplicas locais

Se um nó WSFC estiver sendo executado no Windows Server 2008 R2 Service Pack 1 (SP1), verifique se o hotfix descrito no artigo 2687741 da Base de Dados de Conhecimento foi instalado.

Este hotfix melhora o desempenho do failover do Grupos de Disponibilidade AlwaysOn para réplicas locais.

KB 2687741:  Um hotfix que melhora o desempenho do recurso "Grupo de disponibilidade AlwaysOn" no SQL Server 2012 está disponível para o Windows Server 2008 R2

Caixa de seleção

    √

    √

Sim

Armazenamento assimétrico para FCIs (Instâncias de cluster de failover)

Se alguma Instância de Cluster de Failover (FCI) estiver habilitada para Grupos de Disponibilidade AlwaysOn, instale o hotfix 976097 do Windows Server 2008.

Este hotfix habilita o snap-in MMC (Console de Gerenciamento Microsoft) de Gerenciamento de Cluster de Failover a oferecer suporte ao armazenamento assimétrico, ou seja, discos compartilhados que estão disponíveis em apenas alguns dos nós WSFC.

KB 976097: hotfix para adicionar suporte para armazenamentos assimétricos no snap-in MMC de Gerenciamento de Cluster de Failover para um cluster de failover que está executando o Windows Server 2008 ou o Windows Server 2008 R2

Guia da arquitetura do AlwaysOn: Criando uma solução de alta disponibilidade e recuperação de desastres usando instâncias de cluster de failover e grupos de disponibilidade

Caixa de seleção

    √

    √

Não aplicável

Protocolo IPsec

Se seu ambiente usar conexões IPsec, você poderá experimentar um longo atraso (cerca de dois ou três minutos) quando o computador cliente restabelece a conexão IPsec com um nome de rede virtual (e, neste contexto, para conectar-se ao ouvinte do grupo de disponibilidade). Se você utilizar conexões IPsec, será recomendável rever os cenários específicos detalhados no seguinte artigo da Base de Dados de Conhecimento (KB 980915).

KB 980915:  Ocorre um atraso muito longo ao reconectar uma conexão IPSec de um computador que está executando o Windows Server 2003, o Windows Vista, o Windows Server 2008, Windows 7 ou o Windows Server 2008 R2

Caixa de seleção

    √

    √

Sim

IPv6

Se você utilizar conexões IPv6, será recomendável rever os cenários específicos detalhados no artigo 2578103 ou 2578113 da Base de Dados de Conhecimento, dependendo do sistema operacional do seu Windows Server.

Se sua topologia do Windows Server usar o IP versão 6 (IPv6), o serviço de Cluster WSFC precisará de cerca de 30 segundos para realizar o failover do endereço IP IPv6. Isso faz com que os clientes esperem cerca de 30 segundos para reconectar-se com o endereço IP IPv6.

Caixa de seleção

    √

    √

Sim

Nenhum roteador entre o cluster e o servidor de aplicativo

Se não existir nenhum roteador entre o cluster de failover e o servidor de aplicativos, o serviço de cluster lentamente fará o failover dos recursos relacionados à rede. Isso atrasa as reconexões do cliente depois que um grupo de disponibilidade faz failover. Na ausência de um roteador, será recomendável rever os cenários específicos detalhados no seguinte artigo da Base de Dados de Conhecimento 2582281 e instalar o hotfix, se isso for aplicável a seu ambiente:

KB 2582281: Operação de failover lenta se não existir nenhum roteador entre o cluster e um servidor de aplicativos

Ícone de seta usado com o link Voltar ao InícioInício

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 um melhor desempenho, use um adaptador de rede dedicado (placa de interface de rede) para Grupos de Disponibilidade AlwaysOn.

  • **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.

Permissões (sistema Windows)

Para administrar um cluster WSFC, o usuário deve ser um administrador do sistema em todo 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)

Tarefa

Link

Defina o valor de HostRecordTTL.

Alterar o HostRecordTTL (usando o Windows PowerShell)

Alterar o HostRecordTTL (usando o Windows 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 localizar o recurso Nome da Rede e use o cmdlet Set-ClusterParameter para definir o valor de HostRecordTTL, como segue:

    Get-ClusterResource “<NetworkResourceName>” | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    O exemplo do PowerShell a seguir define o HostRecordTTL como 300 segundos para um recurso Nome da Rede nomeado “SQL Network Name (SQL35)”.

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

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

Conteúdo relacionado (PowerShell)

Conteúdo relacionado (Windows System)

Ícone de seta usado com o link Voltar ao Início[Início]

Pré-requisitos e restrições da instância de 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. 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 seção:

  • Lista de verificação: pré-requisitos

  • Restrições

  • Uso de thread por grupos de disponibilidade

  • Permissões

  • Tarefas relacionadas

  • Conteúdo relacionado

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

Pré-requisito

Links

Caixa de seleção

O computador host deve ser um nó WSFC (Windows Server Failover Clustering). As instâncias do SQL Server que hospedam as réplicas de disponibilidade para um determinado grupo de disponibilidade residem em nós separados de um único cluster do WSFC. A única exceção é que, embora tenha sido migrado para outro cluster WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

WSFC (Windows Server Failover Clustering) com o SQL Server

Clustering de failover e Grupos de Disponibilidade AlwaysOn (SQL Server)

Em cada nó WSFC que hospeda uma réplica de disponibilidade, verifique se o hotfix descrito no artigo 2897554 da Base de Dados de Conhecimento foi instalado.

Esse hotfix garante que o estado de sincronização de cada réplica de disponibilidade será atualizado corretamente, o que ajudará a evitar a perda de dados inesperada em um failover automático.

KB 2897554: CORREÇÃO: o estado de sincronização de uma réplica do Grupo de Disponibilidade AlwaysOn não poderá ser atualizado se a réplica primária não estiver íntegra

Caixa de seleção

Se você desejar um grupo de disponibilidade para funcionar com o Kerberos:

  • Todas as instâncias de servidor que hospedam uma réplica de disponibilidade para o grupo de disponibilidade deve usar a mesma conta de serviço do SQL Server.

  • O administrador de domínio precisa registrar um Nome de entidade de serviço (SPN) manualmente com Active Directory na conta de serviço do SQL Server para o nome de rede virtual (VNN) do ouvinte de grupo de disponibilidade. Se o SPN for registrado em uma conta diferente da conta de serviço do SQL Server, a autenticação falhará.

Observação importanteImportante

Se você alterar a conta de serviço do SQL Server, o administrador de domínio precisará registrar de novo o SPN manualmente.

Registrar um nome de entidade de serviço para conexões de Kerberos

Breve explicação:

O Kerberos e os SPNs impõem a autenticação mútua. O SPN é mapeado para a conta do Windows que inicia os serviços do SQL Server. Se o SPN não estiver registrado corretamente ou se ele falhar, a camada de segurança do Windows não poderá determinar a conta associada ao SPN e a autenticação Kerberos não será utilizada.

ObservaçãoObservação

O NTLM não tem este requisito.

Caixa de seleção

Se você pretende usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade, verifique se compreende as restrições de FCI e se os requisitos de FCI são atendidos.

Pré-requisitos e requisitos para usar uma FCI (instância de cluster de failover) do SQL Server para hospedar uma réplica de disponibilidade (mais adiante neste tópico)

Caixa de seleção

Cada instância de servidor deve estar executando a Enterprise Edition do SQL Server 2012.

Recursos compatíveis com as edições do SQL Server 2012

Caixa de seleção

Todas as instâncias de servidor que hospedam réplicas de disponibilidade para um grupo de disponibilidade devem usar o mesmo agrupamento do SQL Server.

Definir ou alterar o agrupamento do servidor

Caixa de seleção

Habilite o recurso Grupos de Disponibilidade AlwaysOn em cada instância de servidor que hospedará uma réplica de disponibilidade para qualquer grupo de disponibilidade. Em determinado computador, você pode habilitar quantas instâncias de servidor desejar para o Grupos de Disponibilidade AlwaysOn, desde que tenham suporte da instalação do SQL Server.

Habilitar e desabilitar Grupos de Disponibilidade AlwaysOn (SQL Server)

Observação importanteImportante

Se você excluir e recriar um cluster WSFC, precisará desabilitar e reabilitar o recurso Grupos de Disponibilidade AlwaysOn em cada instância de servidor habilitada para Grupos de Disponibilidade AlwaysOn no cluster WSFC original.

Caixa de seleção

Cada instância de servidor exige um ponto de extremidade de espelhamento de banco de dados. Note que esse ponto de extremidade é compartilhado por todas as réplicas de disponibilidade e parceiros de espelhamento de banco de dados e testemunhas na instância de servidor.

Se uma instância de servidor selecionada para hospedar uma réplica de disponibilidade estiver sendo executada em uma conta de usuário de domínio e ainda não tiver um ponto de extremidade de espelhamento de banco de dados, o Assistente de Novo Grupo de Disponibilidade (ou o Assistente para Adicionar Réplica ao Grupo de Disponibilidade) poderá criar o ponto de extremidade e conceder a permissão CONNECT à conta de serviço da instância de servidor. No entanto, se o serviço SQL Server estiver sendo executado como uma conta interna, como Sistema Local, Serviço Local ou Serviço de Rede, ou como uma conta que não pertença a um domínio, você deverá usar certificados para autenticação de ponto de extremidade, e o assistente não poderá criar um ponto de extremidade de espelhamento de banco de dados na instância de servidor. Nesse caso, é recomendável criar manualmente os pontos de extremidade de espelhamento de banco de dados antes de iniciar o assistente.

Observação sobre segurançaObservação sobre segurança

A segurança de transporte para o Grupos de Disponibilidade AlwaysOn é a mesma do espelhamento de banco de dados.

O ponto de extremidade de espelhamento de banco de dados (SQL Server)

Segurança de transporte para espelhamento de banco de dados e grupos de disponibilidade AlwaysOn (SQL Server)

Caixa de seleção

Se algum banco de dados que utilize o FILESTREAM for adicionado a um grupo de disponibilidade, verifique se o FILESTREAM está habilitado em cada instância de servidor que hospedará uma réplica de disponibilidade do grupo de disponibilidade.

Habilitar e configurar FILESTREAM

Caixa de seleção

Se algum banco de dados independente for adicionado a um grupo de disponibilidade, verifique se a opção de servidor contained database authentication está definida como 1 em cada instância de servidor que hospedará uma réplica de disponibilidade do grupo de disponibilidade.

Opção de configuração de servidor contained database authentication

Opções de configuração de servidor

Uso de thread por grupos de disponibilidade

O Grupos de Disponibilidade AlwaysOn tem os seguintes requisitos para threads de trabalho:

  • Em uma instância ociosa do SQL Server, o Grupos de Disponibilidade AlwaysOn não usa nenhum thread.

  • O número máximo de threads usados por grupos de disponibilidade é a configuração definida para o número máximo de threads de servidor ('max worker threads') menos 40.

  • As réplicas de disponibilidade hospedadas em uma instância de servidor específica compartilham um único pool de threads.

    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 inativa é liberado após ~15 segundos de inatividade. No entanto, dependendo da última atividade, um thread ocioso pode ser retido por mais tempo.

  • 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 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.

    • Cada réplica secundária usa 1 thread de restauração para cada banco de dados secundário. Os threads de restauração 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.

Para obter mais informações, consulte Série de aprendizado do AlwaysON - HADRON: uso do pool de trabalho para bancos de dados habilitados para HADRON (um blog dos engenheiros do CSS SQL Server).

Permissões (instância de servidor)

Tarefa

Permissões necessárias

Criando o ponto de extremidade de espelhamento de banco de dados

Exige a permissão CREATE ENDPOINT ou a associação na função de servidor fixa sysadmin. Também requer a permissão CONTROL ON ENDPOINT. Para obter mais informações, consulte Permissões de ponto de extremidade GRANT (Transact-SQL).

Habilitando o Grupos de Disponibilidade AlwaysOn

Requer a associação ao grupo Administrador no computador local e o controle total no cluster WSFC.

Tarefas relacionadas (instância de servidor)

Tarefa

Tópico

Determinando se existe um ponto de extremidade de espelhamento de banco de dados

sys.database_mirroring_endpoints (Transact-SQL)

Criando o ponto de extremidade de espelhamento de banco de dados (caso ainda não exista)

Habilitando grupos de disponibilidade AlwaysOn

Habilitar e desabilitar Grupos de Disponibilidade AlwaysOn (SQL Server)

Conteúdo relacionado (instância de servidor)

Ícone de seta usado com o link Voltar ao Início[Início]

Recomendações de conectividade de rede

Nós recomendamos fortemente que você use os mesmos links de rede para comunicações entre os membros de cluster do WSFC e as comunicações 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 dê suporte a failover automático, a réplica secundária que é o parceiro de failover automático deverá estar no estado SYNCHRONIZED. Se o link de rede para esta réplica secundária falhar (até mesmo com intermitência), a réplica entrará no estado UNSYNCHRONIZED e não poderá começar a ressincronizar até que o link seja restaurado. Se o cluster do WSFC solicitar um failover automático enquanto a réplica secundária estiver não sincronizada, o failover automático não ocorrerá.

Ícone de seta usado com o link Voltar ao Início[Início]

Suporte à conectividade de cliente

Para obter informações sobre o suporte a Grupos de Disponibilidade AlwaysOn para conectividade de cliente, consulte Conectividade de cliente AlwaysOn (SQL Server).

Ícone de seta usado com o link Voltar ao Início[Início]

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 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 para um determinado grupo de disponibilidade: ** se você adicionar uma réplica de disponibilidade a uma FCI, os nós de cluster 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.

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

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

  • Alterando o nome de rede de FCI: se você precisar alterar o nome de rede de um FCI que hospeda uma réplica de disponibilidade, 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; então, se você estiver renomeando um FCI que está hospedando a réplica primária, realize failover em uma réplica secundária e, depois, remova a réplica primária anterior e adicione-a novamente. Note que a renomeação de um FCI pode alterar a URL de seu ponto de extremidade de espelhamento de banco de dados. Ao adicionar a réplica, especifique a URL do ponto de extremidade atual.

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

Pré-requisito

Link

Caixa de seleção

Antes de usar um FCI para hospedar uma réplica de disponibilidade, verifique se o administrador do sistema instalou o hotfix do Windows Server 2008 descrito no artigo KB 976097 da Base de Dados de Conhecimento. Este hotfix habilita o snap-in MMC (Console de Gerenciamento Microsoft) de Gerenciamento de Cluster de Failover a oferecer suporte ao armazenamento assimétrico, ou seja, discos compartilhados que estão disponíveis em apenas alguns dos nós WSFC.

KB 976097: hotfix para adicionar suporte para armazenamentos assimétricos no snap-in MMC de Gerenciamento de Cluster de Failover para um cluster de failover que está executando o Windows Server 2008 ou o Windows Server 2008 R2

Caixa de seleção

Verifique se cada instância de cluster de failover do SQL Server (FCI) possui o armazenamento compartilhado exigido pela instalação de instância de cluster de failover do SQL Server padrão.

Tarefas relacionadas (FCIs)

Tarefa

Tópico

Instalando um cluster de failover do SQL Server

Criar um novo cluster de failover do SQL Server (instalação)

Atualização in-loco de seu cluster de failover do SQL Server existente

Atualizar uma instância de cluster de failover do SQL Server (instalação)

Manutenção do seu cluster de failover existente do SQL Server

Adicionar ou remover nós em um cluster de failover do SQL Server (instalação)

Ícone de seta usado com o link Voltar ao Início[Início]

Conteúdo relacionado (FCIs)

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 cluster 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 cluster WSFC. A única exceção é que, embora tenha sido migrado para outro cluster WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

    ObservaçãoObservaçã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: **cada nome de grupo de disponibilidade deve ser exclusivo no cluster WSFC. O tamanho máximo de um nome de grupo de disponibilidade é 128 caracteres.

  • Réplicas de disponibilidade: Cada grupo de disponibilidade oferece suporte a uma réplica primária e até quatro réplicas secundárias. Todas as réplicas podem ser executadas no modo de confirmação assíncrona ou até três de elas podem ser executadas no modo de confirmação síncrona.

  • 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 amplamente 10 grupos de disponibilidade e 100 bancos de dados por computador físico. Os sinais de sistemas sobrecarregados podem incluir, sem limitação, esgotamento de thread de trabalho, tempos de resposta lentos para exibições de sistema AlwaysOn e DMVs e/ou despejos de sistema do dispatcher parados. Não se esqueça de testar completamente seu ambiente com uma carga de trabalho semelhante à de produção para assegurar que ele possa manipular a capacidade da carga de trabalho de pico nos SLAs do seu aplicativo. 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:

    Por exemplo:

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

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

Pré-requisitos (grupos de disponibilidade)

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

Pré-requisito

Descrição

Caixa de seleção

Se você pretende usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade, verifique se compreende as restrições de FCI e se os requisitos de FCI são atendidos.

Pré-requisitos e restrições do uso de uma FCI (instância de cluster de failover) do SQL Server para hospedar uma réplica de disponibilidade (anteriormente neste tópico)

Segurança (grupos de disponibilidade)

  • A segurança é herdada do cluster WSFC (Windows Server Failover Clustering). O WSFC fornece dois níveis de segurança de usuário na granularidade de APIs inteiras de cluster WSFC:

    • Acesso somente leitura

    • Controle total

      O Grupos de Disponibilidade AlwaysOn precisa de controle total; a habilitação do Grupos de Disponibilidade AlwaysOn em uma instância do SQL Server concede controle total do cluster WSFC (por SID de serviço).

      Você não pode adicionar ou remover diretamente a segurança de uma instância de servidor no Gerenciador de Cluster de Failover WSFC. Para gerenciar sessões de segurança WSFC, use o SQL Server Gerenciador de Configuração 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 sucessivamente.

  • É recomendável que você use a criptografia para conexões entre instâncias de servidor que hospedam réplicas de disponibilidade do Grupos de Disponibilidade AlwaysOn.

Permissões (grupos de disponibilidade)

Tarefa

Permissões necessárias

Criando um grupo de disponibilidade

Requer a associação na função de servidor fixa sysadmin e a permissão de servidor CREATE AVAILABILITY GROUP, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER.

Alterando um grupo de disponibilidade

Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER.

Além disso, unir um banco de dados a um grupo de disponibilidade exige a associação na função de banco de dados fixa db_owner.

Descartando/excluindo um grupo de disponibilidade

Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER. Para descartar um grupo de disponibilidade não hospedado na localização de réplica local, você precisará da permissão CONTROL SERVER ou CONTROL nesse grupo de disponibilidade.

Tarefas relacionadas (grupos de disponibilidade)

Tarefa

Tópico

Criando um grupo de disponibilidade

Modificando o número de réplicas de disponibilidade

Criando um ouvinte de grupo de disponibilidade

Criar ou configurar um ouvinte de grupo de disponibilidade (SQL Server)

Descartando um grupo de disponibilidade

Remover um grupo de disponibilidade (SQL Server)

Ícone de seta usado com o link Voltar ao Início[Início]

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:

Requisitos

Link

Caixa de seleção

Ser um banco de dados de usuário. Os bancos de dados do sistema não podem pertencer a um grupo de disponibilidade.

Caixa de seleção

Residir na instância do SQL Server em que você cria o grupo de disponibilidade e ser acessível à instância de servidor.

Caixa de seleção

Ser um banco de dados de leitura/gravação. Os bancos de dados somente leitura não podem ser adicionados a um grupo de disponibilidade.

sys.databases (is_read_only = 0)

Caixa de seleção

Ser um banco de dados de vários usuários.

sys.databases (user_access = 0)

Caixa de seleção

Não usar AUTO_CLOSE.

sys.databases (is_auto_close_on = 0)

Caixa de seleção

Use o modelo de recuperação completa (também conhecido como modo de recuperação completa).

sys.databases (recovery_model = 1)

Caixa de seleção

Ter pelo menos um backup de banco de dados completo.

ObservaçãoObservação

Após a definição de uma banco de dados para um modo de recuperação completa, um backup completo será necessário para iniciar a cadeia de log de recuperação completa.

Criar um backup completo de banco de dados (SQL Server)

Caixa de seleção

Não pertencer a um grupo de disponibilidade existente.

sys.databases (group_database_id = NULL)

Caixa de seleção

Não ser configurado para espelhamento de banco de dados.

sys.database_mirroring (Se o banco de dados não participar do espelhamento, todas as colunas prefixadas com "mirroring_" serão NULL.)

Caixa de seleção

Antes de adicionar um banco de dados que usa o FILESTREAM a um grupo de disponibilidade, verifique se o FILESTREAM está habilitado em cada instância de servidor que hospeda ou hospedará uma réplica de disponibilidade do grupo de disponibilidade.

Habilitar e configurar FILESTREAM

Caixa de seleção

Antes de adicionar um banco de dados independente a um grupo de disponibilidade, verifique se a opção de servidor contained database authentication está definida como 1 em cada instância de servidor que hospeda ou hospedará uma réplica de disponibilidade do grupo de disponibilidade.

Opção de configuração de servidor contained database authentication

Opções de configuração de servidor

ObservaçãoObservação

O Grupos de Disponibilidade AlwaysOn funciona com qualquer nível de compatibilidade de banco de dados para o qual haja suporte.

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 de grupo de nova disponibilidade/Adicionar banco de dados ao Assistente de Grupo de Disponibilidade: **a opção Completa não tem suporte (na página Selecionar Sincronização de Dados Inicial),

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

    • Impacto em operações adicionar arquivos: uma operação adicionar 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, leva as réplicas secundárias a entrarem no estado NOT SYNCHRONIZING.

      ObservaçãoObservação

      Para obter mais informações sobre a resposta a uma falha na operação adicionar arquivos, consulte Solução de problemas de uma operação de adicionar arquivos com falha (grupos de disponibilidade de AlwaysOn).

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

Acompanhamento para bancos de dados TDE protegidos

Se você usar criptografia de dados transparente (TDE), o certificado ou a chave assimétrica para criação e descriptografia de outras chaves deverá ser igual em todas as instância de 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 (bancos de dados de disponibilidade)

Requer a permissão ALTER no banco de dados.

Tarefas relacionadas (bancos de dados de disponibilidade)

Tarefa

Tópico

Preparando um banco de dados secundário (manualmente)

Preparar um banco de dados secundário manualmente para um grupo de disponibilidade (SQL Server)

Unindo um banco de dados secundário ao grupo de disponibilidade (manualmente)

Unir um banco de dados secundário a um grupo de disponibilidade (SQL Server)

Modificando o número de bancos de dados de disponibilidade

Ícone de seta usado com o link Voltar ao Início[Início]

Conteúdo relacionado

Ícone de seta usado com o link Voltar ao Início[Início]

Consulte também

Conceitos

Visão geral de grupos de disponibilidade AlwaysOn (SQL Server)

Clustering de failover e Grupos de Disponibilidade AlwaysOn (SQL Server)

Conectividade de cliente AlwaysOn (SQL Server)