Os Grupos de Disponibilidade do SQL Server 2012 AlwaysOn

Guia da arquitetura AlwaysOn: criando uma solução de alta
disponibilidade e recuperação de desastre usando instâncias de
cluster de failover e grupos de disponibilidade
Artigo técnico do SQL Server
Autores: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft)
Revisores técnicos: Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako
(Microsoft), Charles Mathews (Microsoft), Prem Mehra (Microsoft), Juergen Thomas (Microsoft),
Mike Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca
Hotz (SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry
(SQLskills.com)
Gerente de programa de conteúdo: Glenn Minch (Microsoft)
Publicado em: junho de 2012
Aplica-se a: SQL Server 2012
Resumo: As Instâncias de Cluster de Failover (FCI) do SQL Server 2012 AlwaysOn e os
Grupos de Disponibilidade AlwaysOn oferecem uma solução de alta disponibilidade
e recuperação de desastre abrangente. Antes do SQL Server 2012, vários clientes usavam
FCIs para fornecer alta disponibilidade local dentro de um data center e o espelhamento de
banco de dados para a recuperação de desastre em um data center remoto. Com o SQL
Server 2012, esse padrão comum de design pode ser substituído por uma arquitetura que
usa FCIs para alta disponibilidade e grupos de disponibilidade para requisitos de negócios
de recuperação de desastre. Os grupos de disponibilidade utilizam a funcionalidade WSFC
(Windows Server Failover Clustering) e habilitam vários recursos não disponíveis no
espelhamento de banco de dados. Este documento descreve os principais requisitos da
topologia desse padrão de design específico, inclusive considerações sobre o armazenamento
assimétrico, a seleção do modelo de quorum, votos de quorum, as etapas necessárias para
criar o ambiente e um fluxo de trabalho que ilustra como tratar um evento de recuperação de
desastre na nova topologia entre os cargos participantes.
Direitos autorais
Este documento é fornecido “como está”. As informações e opiniões expressas nele, inclusive URLs
e outras referências a sites da Internet, poderão ser alteradas sem aviso prévio. Você se responsabiliza
por usá-lo.
Alguns exemplos representados aqui são fornecidos apenas para ilustração e são fictícios. Nenhuma
associação real ou conexão é desejada ou deve ser inferida.
Este documento não fornece direitos legais a nenhuma propriedade intelectual de qualquer produto
Microsoft. Você pode copiar e usar este documento para sua referência interna.
© 2012 Microsoft. Todos os direitos reservados.
2
Sumário
Introdução..................................................................................................................................................... 4
FCIs para HA local e espelhamento de banco de dados para DR ................................................................. 4
FCIs para HA local e grupos de disponibilidade para DR .............................................................................. 5
Planejamento e considerações ..................................................................................................................... 7
Requisitos de cluster de failover do Windows Server .............................................................................. 7
Armazenamento assimétrico .................................................................................................................... 7
Nomenclatura e caminho de arquivo de instância ................................................................................... 7
Modo de disponibilidade e modo de failover ........................................................................................... 8
Votos de nós e modelos de quorum ......................................................................................................... 8
Ferramentas para exibir e alterar votos de nós e modelos de quorum ............................................. 11
Configurando o modelo de quorum do WSFC .................................................................................... 11
Usando DMVs e o painel AlwaysOn para exibir informações de quorum .......................................... 12
Configurando votos de nós ................................................................................................................. 13
Conectividade de cliente......................................................................................................................... 14
Cargas de trabalho de leitura/gravação ............................................................................................. 14
Cargas de trabalho somente leitura ................................................................................................... 14
Suporte à conexão de várias sub-redes .............................................................................................. 15
Configurando a solução FCI+AG.................................................................................................................. 15
Instalando pré-requisitos ........................................................................................................................ 15
Configurando a solução no data center primário ................................................................................... 16
Configurando a solução no data center de DR ....................................................................................... 21
Considerações sobre monitoramento ........................................................................................................ 26
Recuperando-se de um desastre ................................................................................................................ 27
Revertendo para o data center primário .................................................................................................... 33
Conclusão .................................................................................................................................................... 36
Referências.................................................................................................................................................. 37
3
Introdução
O Microsoft SQL Server 2012 AlwaysOn fornece opções flexíveis de design para a seleção de uma solução
adequada de alta disponibilidade (HA) e recuperação de desastre (DR) para seu aplicativo. Para saber
mais sobre os padrões de design de alta disponibilidade e recuperação de desastre do SQL Server 2012
AlwaysOn, consulte Padrões de design de alta disponibilidade e recuperação de desastre do SQL
Server 2012 AlwaysOn.
Este white paper descreve a solução usando instâncias de cluster de failover (FCI) para HA e usando
grupos de disponibilidade (AG) para DR. Essa arquitetura combina uma solução de armazenamento
compartilhado (FCI) e uma solução de armazenamento não compartilhado (AG).
Antes do SQL Server 2012, uma arquitetura comum de implantação de HA e DR envolvia o uso de FCIs
para alta disponibilidade local e espelhamento de banco de dados (DBM) para a recuperação de
desastre remota. Com o SQL Server 2012, os grupos de disponibilidade podem substituir o componente
de espelhamento de banco de dados da solução.
Este documento aborda considerações de planejamento e descreve as etapas necessárias para criar essa
solução. Ele também aborda as etapas necessárias para recuperação de um desastre e explica como
reverter para o data center primário após sua restauração.
Este documento pressupõe um conhecimento básico dos conceitos de instâncias de cluster de failover
(FCIs), grupos de disponibilidade, alta disponibilidade e recuperação de desastre. Para saber mais sobre
o conjunto completo de recursos da solução AlwaysOn, consulte o white paper Guia de soluções
Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre. Para saber mais
sobre as etapas de migração, consulte o white paper Guia de migração: migrando para clustering de
failover do SQL Server 2012 e grupos de disponibilidade a partir de implantações de clustering
e espelhamento anteriores.
O público-alvo deste white paper inclui administradores operacionais de bancos de dados do SQL Server
e arquitetos de tecnologia. Ele também se dirige aos administradores de sistemas que colaboram com
a função de administrador de banco de dados para gerenciar o Windows Server, os Serviços de Domínio
Active Directory (AD DS), o WSFC e o sistema de rede.
FCIs para HA local e espelhamento de banco de dados para DR
Conforme mencionado na introdução, antes do SQL Server 2012, uma arquitetura de implantação
comum do SQL Server envolvia o uso de FCIs para alta disponibilidade local e o uso do espelhamento de
banco de dados para recuperação de desastre entre data centers. Isso era conhecido como uma solução
FCI+DBM. Para essa solução, uma FCI é configurada no data center primário usando armazenamento em
disco compartilhado (por meio da SAN, por exemplo) para fornecer proteção em nível de instância do
SQL Server. Se ocorrer uma falha de hardware em um dos nós, outro nó poderá assumir como o host da
FCI dentro do mesmo data center.
4
O espelhamento de banco de dados é usado entre o site primário e o site de recuperação de desastre
para fornecer proteção em nível de banco de dados. No caso de uma interrupção do data center
primário, ou se o armazenamento compartilhado no data center primário apresentar uma falha,
o espelho no data center de DR poderá ser usado para restaurar o serviço para os aplicativos. O data
center de recuperação de desastre hospeda outra FCI em um WSFC separado, com seu próprio
armazenamento compartilhado. A Figura 1 fornece uma representação dessa arquitetura de solução.
Data center primário
Data center de recuperação de desastre
Cluster de failover “A” do Windows
Server
Cluster de failover “B” do Windows Server
Cluster de failover “A” do Windows Server
SQLFCIPrimary\INST_A
SQLFCIDR\INST
A
Espelhamento de
banco de dados
Banco de dados
principal
Banco de dados
espelho
Figura 1: FCI para alta disponibilidade e espelhamento de banco de dados para recuperação de desastre
Em geral, o data center de DR está localizado a uma distância do data center primário, e a sessão de
espelhamento é definida como modo assíncrono de “alto desempenho” para minimizar a sobrecarga em
transações. Ocasionalmente, o espelhamento de banco de dados síncrono entre os data centers
também é observado.
Para obter mais informações, incluindo um exemplo prático dessa solução específica, consulte Alta
disponibilidade e recuperação de desastre em ServiceU: um estudo de caso técnico do SQL Server 2008.
FCIs para HA local e grupos de disponibilidade para DR
Com o SQL Server 2012, uma solução semelhante envolve o uso de FCIs para alta disponibilidade local,
como a solução FCI+DBM, porém o uso de grupos de disponibilidade (AG) para a recuperação de
desastre. Essa solução é chamada de FCI+AG.
A Figura 2 mostra a solução usando FCIs para alta disponibilidade local e grupos de disponibilidade para
a recuperação de desastre entre data centers.
Figura 2: FCIs para alta disponibilidade e grupos de disponibilidade para recuperação de desastre
5
A Figura 2 mostra duas FCIs, uma no data center primário e outra no data center de recuperação de
desastre. Cada FCI tem dois nós e seu próprio armazenamento compartilhado. Todos os quatro nós,
porém, fazem parte do mesmo WSFC. Um requisito para grupos de disponibilidade é que todos os nós
pertençam ao mesmo WSFC.
A Figura 2 ilustra uma topologia simples com dois data centers, cada um hospedando uma réplica do AG
em uma FCI de dois nós. A arquitetura permite variações nesta topologia:





Vários data centers
Várias réplicas, até cinco, incluindo uma réplica primária e uma a quatro réplicas secundárias.
Mais de dois nós em cada FCI se forem desejados nós passivos adicionais para fins de HA
Nem todas as réplicas de um grupo de disponibilidade precisam residir em instâncias FCI;
algumas podem residir em instâncias do SQL Server autônomas não FCI
Vários grupos de disponibilidade baseados no agrupamento lógico de bancos de dados para
o ambiente do seu aplicativo
A discussão neste white paper se concentra na topologia mostrada na Figura 2; entretanto, os conceitos
gerais também se aplicam a outras variações.
Como os quatro nós em dois sites fazem parte do mesmo WSFC, há considerações adicionais para uso
do armazenamento compartilhado que é visível apenas nos nós do data center local. Também há
considerações adicionais sobre a votação de quorum e o modelo de quorum. Este artigo descreve essas
e outras considerações.
O grupo de disponibilidade pode ser configurado com um ou mais bancos de dados de usuário, e pode
usar o movimento de dados síncrono ou assíncrono. As réplicas síncronas adicionam latência às transações
de banco de dados, pois a primária precisa receber a confirmação de que os registros de log foram
intensificados para os logs da réplica secundária antes que a réplica primária confirme a transação.
Também é importante observar que a instância do SQL Server de recuperação de desastre não precisa
ser uma FCI. Um grupo de disponibilidade também pode ter uma instância autônoma do SQL Server
para a réplica secundária. Com os grupos de disponibilidade, você pode combinar duas instâncias
autônomas e FCIs em uma única topologia no mesmo WSFC. A Figura 3 mostra uma topologia mista.
Data center primário
Data center de recuperação de desastre
Cluster de failover do Windows Server
SQLFCIPrimary\INST_A
SQLDR\INST_B
Grupo de
Disponibilidade
Banco de dados
primário
Banco de dados
secundário
Figura 3: FCI para o HA local e grupos de disponibilidade para DR, com a instância de DR sendo uma instância autônoma
O restante do documento presume que as réplicas primárias e secundárias são FCIs hospedadas, e não
instâncias autônomas.
6
Planejamento e considerações
Esta seção descreve questões de planejamento, requisitos e pré-requisitos a serem considerados antes
da implementação de uma solução FCI+AG para alta disponibilidade e recuperação de desastre.
Requisitos de cluster de failover do Windows Server
Uma alteração fundamental entre uma FCI+DBM versus uma solução FCI+AG é que você está mudando
do uso de duas FCIs em dois WSFCs separados para o uso de duas FCIs em um único WSFC. Todas as
réplicas de um grupo de disponibilidade devem existir em um único WSFC dentro de um único domínio
do Active Directory, mesmo entre data centers.
Armazenamento assimétrico
Duas FCIs, uma em cada site em um único WSFC de vários sites, introduzem considerações sobre como
o armazenamento compartilhado é tratado. Cada FCI tem seu próprio armazenamento compartilhado.
Os nós do site primário compartilham armazenamento entre eles para formar uma FCI de
armazenamento compartilhado, e os nós do site de DR compartilham armazenamento entre eles para
formar outra FCI de armazenamento compartilhado. O armazenamento no site primário não é visível
aos nós do site de recuperação de desastre e vice-versa. Essa organização de armazenamento, onde um
disco de cluster é compartilhado entre um subconjunto de nós dentro de um WSFC, é conhecida como
armazenamento assimétrico. Antes do recurso de armazenamento assimétrico, o armazenamento
compartilhado precisava estar visível a todos os nós do WSFC (armazenamento simétrico).
O armazenamento assimétrico foi apresentado como uma opção de implantação para o Windows Server
2008 por meio de um hotfix. O armazenamento assimétrico também tem suporte no Windows Server
2008 R2 via Service Pack 1. Para saber mais sobre esse hotfix, consulte o artigo da Base de Dados de
Conhecimento Hotfix para adicionar suporte para armazenamentos assimétricos no snap-in
Gerenciamento de Cluster de Failover do MMC para um cluster de failover que esteja executando
o Windows Server 2008 ou o Windows Server 2008 R2.
Esse aperfeiçoamento do Windows Server é a parte fundamental da funcionalidade que permite
a arquitetura de solução FCI + AG abordada neste white paper. Ao habilitar essa funcionalidade, você
pode combinar a solução de armazenamento compartilhado (FCI) com a solução de armazenamento não
compartilhado (grupos de disponibilidade) em uma única solução HA + DR. Com isso, o aperfeiçoamento
também permite usar letras de unidade idênticas para recursos de disco compartilhados entre os
data centers.
Observe que, quando você configurar o armazenamento assimétrico, poderá ver uma mensagem
durante os testes de validação do WSFC que diz “O disco com a id XYZ só está visível ou só pode ser
colocado em cluster por meio de um subconjunto de nós’. Para o armazenamento assimétrico, isso
é esperado e não é motivo de preocupação.
Nomenclatura e caminho de arquivo de instância
As duas FCIs devem usar nomes de instância diferentes no mesmo WSFC, por exemplo, usando “INST_A”
como o nome da instância para a FCI primária e ”INST_B” como o nome de instância para a FCI de DR.
(Ao contrário dos grupos de disponibilidade, o espelhamento de banco de dados permite que cada FCI
use o mesmo nome de instância caso as FCIs estejam em WSFCs separados. Na Figura 1, ambas as FCIs
usaram o mesmo nome de instância, INST_A, com a solução FCI+DBM).
7
Cada FCI tem seu próprio armazenamento compartilhado, que não é acessível aos nós do outro data
center, e que deve usar letras de unidade idênticas para os discos, bem como caminhos de arquivo
idênticos para arquivos de banco de dados e arquivos de log de transações nas FCIs. Caminhos de
arquivo e letras de unidade idênticos não são um requisito absoluto, mas se os caminhos forem
diferentes, você deverá fazer um RESTORE WITH MOVE manual ao restaurar os bancos de dados da
réplica na secundária. Além disso, os caminhos heterogêneos nas duas FCIs invalidarão operações
subsequentes de adição de arquivo, como a criação de grupos de arquivos ou arquivos de dados ou logs
secundários. Para obter mais informações, incluindo um cenário e uma resolução do problema, consulte
Solucionar problemas de uma falha na operação de adicionar arquivos (Grupos de Disponibilidade
AlwaysOn).
Modo de disponibilidade e modo de failover
Para o grupo de disponibilidade criado entre as duas FCIs, você pode designar modos de disponibilidade
de confirmação síncronos ou assíncronos. Se o modo de disponibilidade for síncrono, a réplica primária
aguardará para confirmar transações de usuário até que elas tenham sido enviadas e intensificadas nas
réplicas secundárias. Isso pode adicionar latência às transações de usuário, mas também ajuda a eliminar
a possibilidade de perda de dados na réplica secundária, garantindo que as transações sejam enviadas
à FCI de recuperação de desastre antes de uma confirmação ser sinalizada na transação da réplica
primária.
Se o modo de disponibilidade for assíncrono, as transações de usuário da sua réplica primária não
aguardarão que as transações sejam intensificadas nos logs da réplica secundária. Isso reduz a latência
da transação, mas aumenta a exposição à perda de dados no caso de uma interrupção.
Em relação aos modos de failover, quando forem usadas FCIs na topologia de grupo de disponibilidade,
o modo de failover dos grupos de disponibilidade deverá ser manual (não automático). Porém, dentro
de cada FCI, o failover de FCI da instância do SQL Server em outros nós é automático.
Votos de nós e modelos de quorum
Observação: as discussões sobre modelos de quorum e as informações relacionadas neste white
paper se aplicam a soluções que estejam executando os sistemas operacionais Windows Server
2008 e Windows Server 2008 R2 com os service packs apropriados e outras atualizações de
software.
Como a infraestrutura subjacente da solução FCI+AG é um WSFC, é importante considerar o modelo de
quorum apropriado para o WSFC. A configuração de quorum é gerenciada no nível do WSFC, não importa
o número de FCIs, o número de réplicas e o número de grupos de disponibilidade hospedados no WSFC.
No WSFC, há quatro modelos de quorum: Maioria de Nós, Maioria dos Nós e Compartilhamentos de
Arquivos, Maioria de Nós e Discos, Nenhuma Maioria: Somente Disco. Para saber mais sobre modelos
de quorum, consulte Guia passo a passo de cluster de failover: configurando o quorum em um cluster
de failover.
8
Antes de selecionar um modelo de quorum, é importante levar em conta o número de nós votantes.
A atribuição de votos de nós apropriados tem uma função importante no design de HA+DR. Por padrão,
todos os nós em um cluster de failover têm um voto, mas isso pode não ser apropriado para sua solução
de HA+DR em particular, dependendo da distribuição de nós nos data centers primário e de DR. Há um
hotfix disponível (http://support.microsoft.com/kb/2494036) que permite que você atribua 1 voto
a alguns nós e 0 voto a alguns outros nós do WSFC. A propriedade NodeWeight do nó do WSFC
representa o voto desse nó em particular. O valor ‘0’ significa que o nó não tem um voto. O valor ‘1’
indica que o nó tem um voto de quorum. Esse hotfix deve ser instalado em cada nó da topologia.
As recomendações gerais de votação de quorum para uma solução de HA+DR AlwaysOn são fornecidas
no tópico Ajustes recomendados para votação de quorum nos Manuais Online do SQL Server. Elas
devem ser tratadas como diretrizes na decisão sobre o esquema de votação para a solução AlwaysOn.
Levando em consideração essas diretrizes, para garantir que o quorum dos nós do data center primário
não seja afetado por interrupções no data center de DR ou pela perda de conectividade entre os dois
data centers, para a solução FCI+AG apresentada na Figura 2, o esquema de votação será:


Um voto para cada nó do data center primário
Zero voto para cada nó do data center de recuperação de desastre
Essa atribuição de voto se traduz em um total de 2 votos para o WSFC. Como prática recomendada,
o número total de votos do WSFC deve ser um número ímpar. Se houver um número par de nós
votantes (como em nossa topologia de exemplo), você poderá adicionar uma testemunha de
compartilhamento de arquivos e, em seguida, escolher o modelo de quorum Maioria dos Nós
e Compartilhamentos de Arquivos.
Observação: em muitos ambientes corporativos, é comum um compartilhamento de arquivos
pertencer a uma equipe e ser gerenciado por outra. Essa equipe tem controle sobre um voto de
nó e, portanto, tem influência no status do cluster de failover. Um compartilhamento de arquivos
se torna um voto e, por isso, deve estar sempre disponível. O clustering ou outras tecnologias de
HA são recomendados para garantir a disponibilidade do voto de compartilhamento de
arquivos.
Como alternativa, você pode incluir um nó adicional e usar o modelo de quorum Maioria de Nós. O nó
adicional precisa estar no WSFC, mas não é necessário que seja parte da configuração de FCI. Ele
também deve estar localizado no mesmo data center primário, colocado junto com os outros dois nós
do WSFC existentes nesse data center.
A Figura 4 mostra a alocação de votos usando o modelo de quorum Maioria dos Nós e Compartilhamentos
de Arquivos.
9
Figura 4: Solução de HA/DR FCI+AG com atribuições de votos de nós
Na Figura 4, cada um dos dois nós do data center primário tem um voto. Uma testemunha de
compartilhamento de arquivos também é definida no data center primário e também tem um voto. Os
dois nós do data center de recuperação de desastre não recebem um voto e não podem afetar o quorum.
As outras opções possíveis de modelo de quorum para essa arquitetura de implantação são Maioria de
Nós e Discos (usando um disco assimétrico) ou Nenhuma Maioria: Somente Disco (usando um disco
assimétrico). Antes que o armazenamento assimétrico estivesse disponível em um WSFC, um disco
compartilhado poderia atuar como um recurso de quorum, caso ele fosse visível de todos os nós do
WSFC. Com o armazenamento assimétrico, o armazenamento de cluster pode ficar visível a um
subconjunto de nós e ainda ser usado como um recurso de quorum. Com o modelo de quorum
Nenhuma Maioria: Somente Disco, você pode implementar um cenário “o último remanescente”, onde
o WSFC mantém o quorum enquanto um único nó tiver contato com o disco assimétrico que atua como
o recurso de quorum.
Você pode habilitar isso usando a linha de comando do cluster.exe, mas não pode habilitá-lo por meio
do Gerenciador de Cluster de Failover ou do Windows PowerShell. Para ver um exemplo dessa
configuração, consulte a seção Alterando a configuração de quorum em um cluster de failover com
armazenamento assimétrico do artigo Guia passo a passo de cluster de failover: configurando o quorum
em um cluster de failover.
Importante: o uso de um disco assimétrico como o recurso de quorum oferece diversos
benefícios, mas também exige um grau muito mais elevado de experiência em cluster
e planejamento. Você deve se familiarizar bastante com essa configuração antes de implantá-la
em um ambiente de produção.
10
No caso de uma interrupção do data center primário que requeira a ativação do serviço em um data
center de recuperação de desastre, será necessário reavaliar a configuração do quorum. Cada nó do
data center de recuperação de desastre deve receber um voto, e cada nó do data center primário deve
ter seu voto removido (definido como “0”) até que o serviço seja restaurado. Supondo-se dois nós para
a FCI e uma interrupção mais prolongada do data center primário, você também deverá configurar uma
testemunha de compartilhamento de arquivos (ou outro voto adicional) no data center de DR e definir
o modelo de quorum adequadamente. Depois que o data center primário estiver novamente pronto
para a atividade, a votação deverá ser mais uma vez ajustada e o modelo de quorum, reavaliado. Mais
adiante neste documento, demonstraremos um cenário de recuperação de desastre e o fluxo de
processos associado.
As atribuições de modelo de quorum e de voto apresentadas na Figura 4 também presume que
a solução tenha duas réplicas — uma em cada um dos dois data centers. Se houver mais data centers
e você planejar colocar alguma parte de sua solução em um terceiro data center, as decisões do modelo
de quorum e as atribuições de votos poderão variar.
Ferramentas para exibir e alterar votos de nós e modelos de quorum
Há várias maneiras de exibir e alterar o modelo de quorum de cluster e/ou os votos de quorum. A tabela
a seguir lista as várias ferramentas para essas tarefas.
Para exibir o modelo de quorum
Gerenciador de Cluster de Failover
do Windows
Windows PowerShell
Cluster.exe
DMVs do SQL Server
Painel AlwaysOn no SQL Server
Management Studio
Para alterar o modelo de quorum
Gerenciador de Cluster de Failover do Windows
Windows PowerShell
Cluster.exe
Observação: somente o Cluster.exe pode ser
usado para definir o modelo de quorum como
“Maioria de Nós e Discos (assimétrico) ou
“Nenhuma Maioria: Somente Disco (assimétrico)”
Para exibir votos de nós
Para alterar votos de nós
Windows PowerShell
Cluster.exe
DMVs do SQL Server
Painel AlwaysOn
Windows PowerShell
Cluster.exe
Configurando o modelo de quorum do WSFC
Aqui estão alguns exemplos de como usar o Windows PowerShell por meio da linha de comando para
exibir o modelo atual de quorum e alterar o modelo de quorum.
Para exibir o modelo de quorum existente
Get-ClusterQuorum
Para configurar o modelo de quorum Maioria de Nós
Set-ClusterQuorum -NodeMajority
Para alterar o modelo de quorum para Maioria dos Nós e Compartilhamentos de Arquivos
Set-ClusterQuorum -NodeAndFileShareMajority \\FileShare\Witness
11
A testemunha compartilhamento de arquivos escolhida por você não deve estar em um nó que já esteja
participando da configuração do WSFC AlwaysOn. Entretanto, ela pode ser posicionada como um
compartilhamento em outra configuração do WSFC e deve existir no mesmo domínio do Active
Directory que o WSFC. Além disso, a conta de serviço de cluster do WSFC exige permissões de leitura
e gravação para a testemunha de compartilhamento de arquivos. O Gerenciador de Cluster de Failover
tem a lógica interna para adicionar essas permissões à testemunha de compartilhamento de arquivos,
desde que a conta por meio da qual o modelo de quorum é alterado tenha permissões no
compartilhamento de arquivos.
Usando DMVs e o painel AlwaysOn para exibir informações de quorum
Embora você não possa definir ou alterar o modelo de quorum ou os votos de nós usando ferramentas
do SQL Server, pode usar consultas Transact-SQL em DMVs e o Painel AlwaysOn no SQL Server
Management Studio para exibir os votos de nós e o modelo de quorum do cluster do Windows que
hospeda o grupo de disponibilidade.
Para exibir o modelo de quorum do cluster do Windows que está hospedando o grupo de disponibilidade,
consulte a DMV sys.dm_hadr_cluster (http://technet.microsoft.com/pt-br/library/hh212952(v=sql.110).aspx).
SELECT
FROM
cluster_name, quorum_type_desc, quorum_state_desc
sys.dm_hadr_cluster;
Quando essa consulta é executada no exemplo abordado neste white paper, retorna o resultado a seguir
cluster_name
-----------contosocluster
quorum_type_desc
---------------NODE_AND_FILE_SHARE_MAJORITY
quorum_state_desc
----------------NORMAL_QUORUM
Para exibir os votos de nós, consulte a DMV sys.dm_hadr_cluster_members.
SELECT
FROM
member_name, number_of_quorum_votes
sys.dm_hadr_cluster_members;
Quando essa consulta é executada no exemplo abordado neste white paper, retorna o resultado
a seguir. A alocação de votos será abordada em uma seção posterior.
member_name
-----------------PrimaryNode1
PrimaryNode2
DRNode1
DRNode2
File Share Witness
number_of_quorum_votes
---------------------1
1
0
0
1
O Painel AlwaysOn no SQL Server Management Studio também pode ser usado para exibir votos de
quorum e o estado do cluster. A Figura 5 mostra essas informações para um cluster do Windows com
o modelo de quorum Maioria de Nós (o estado do cluster e os votos de quorum estão realçados).
12
Figura 5: Exibindo votos de quorum e o estado do cluster no painel AlwaysOn
Embora a coluna Votos de Quorum não seja exibida por padrão, você pode adicioná-la ao painel. Basta
clicar com o botão direito do mouse no cabeçalho de coluna da tabela Réplica de disponibilidade
e selecionar a coluna específica a ser exibida.
Para um modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos, essa exibição do painel
AlwaysOn mostra somente os nós, não o compartilhamento de arquivos. Para ver informações completas
sobre quorum, clique em Exibir informações de quorum do cluster no lado direito da tela. Será exibida
uma janela pop-up semelhante à Figura 6.
Figura 6: Informações de quorum de cluster para o modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos
Configurando votos de nós
A propriedade NodeWeight do nó do WSFC representa o voto desse nó em particular. Os exemplos
a seguir demonstram como configurar o nó NodeWeight de um nó em um WSFC usando o Windows
PowerShell. Para executar o Windows PowerShell no nó do servidor, clique em Iniciar, aponte para
Ferramentas Administrativas e clique em Módulos do Windows PowerShell. Neste exemplo, DRNode1
representa um nó específico do WSFC localizado no data center de recuperação de desastre.
Para exibir configurações de voto atuais para todos os nós
13
Get-ClusterNode | fl NodeName, NodeWeight
Para definir o voto de um nó como “0”
(Get-ClusterNode “DRNode1”).NodeWeight=0
Observação: o valor ‘0’ significa que o nó não tem um voto. O valor ‘1’ indica que o nó tem um
voto de quorum.
Conectividade de cliente
Os métodos de conexão de FCI no SQL Server 2012 são iguais aos das versões anteriores, mas para
migrações de espelhamento de banco de dados para grupos de disponibilidade, há alterações que você
deve considerar e planejar antes de poder usar a nova funcionalidade de secundária legível. Para saber
mais sobre migração, incluindo considerações e etapas detalhadas, consulte Guia de migração:
migrando para clustering de failover do SQL Server 2012 e grupos de disponibilidade a partir de
implantações de clustering e espelhamento anteriores.
Cargas de trabalho de leitura/gravação
Para as cargas de trabalho de leitura/gravação executadas nos bancos de dados de disponibilidade em
um grupo de disponibilidade, você pode se conectar à réplica usando duas opções. A primeira
é conectar-se diretamente ao VNN (nome de rede virtual) da FCI; cada réplica tem um VNN de FCI
diferente. A segunda opção é usar o nome do ouvinte de grupo de disponibilidade. O ouvinte de grupo
de disponibilidade é a opção preferencial porque oferece transparência e redirecionamento automático
para a réplica primária atual, e o nome na cadeia de conexão permanece o mesmo para todas as
instâncias. O ouvinte de grupo de disponibilidade é um VNN associado a um ou mais endereços TCP/IP
e portas de escuta, e é usado para a conexão automática a qualquer réplica sem a necessidade de
designar explicitamente cada réplica de grupo de disponibilidade possível na cadeia de conexão.
Se você estiver migrando conexões de aplicativos de carga de trabalho de leitura/gravação de uma
solução de espelhamento de banco de dados herdada que usa o atributo Parceiro de Failover, ainda
poderá usar sua cadeia de conexão de espelhamento de banco de dados, mas somente se o grupo de
disponibilidade for configurado com uma única réplica secundária configurada para atividade de
leitura/gravação. Você pode usar o nome do servidor da réplica primária inicial como a fonte de dados
e (opcionalmente) o nome da réplica secundária como o parceiro de failover. Entretanto, isso não deve
ser usado como uma solução de longo prazo.
Cargas de trabalho somente leitura
Para conexões de carga de trabalho somente leitura, você também tem duas opções disponíveis. Você
pode usar o VNN da FCI ou pode usar o ouvinte de grupo de disponibilidade e especificar o novo
atributo ApplicationIntent na cadeia de conexão como “ReadOnly”.
Se você estiver usando uma cadeia de conexão herdada de espelhamento de banco de dados, só poderá
se conectar ao grupo de disponibilidade se o grupo de disponibilidade estiver configurado como uma
única réplica secundária configurada para a atividade de leitura/gravação.
14
Se você quiser aproveitar o roteamento somente leitura, deverá usar o nome do ouvinte de grupo de
disponibilidade junto com o atributo ApplicationIntent e o valor “ReadOnly”. Você também referenciar
um banco de dados de disponibilidade no grupo de disponibilidade. O grupo de disponibilidade também
deve ser configurado para roteamento somente leitura para réplicas secundárias legíveis por meio da
criação de URLs de roteamento somente leitura e listas de roteamento somente leitura. Para saber mais
sobre esse processo, consulte Configurar o roteamento somente leitura para um grupo de
disponibilidade (SQL Server).
Suporte à conexão de várias sub-redes
O ouvinte de grupo de disponibilidade também pode aproveitar o atributo de conexão MultiSubnetFailover
em bibliotecas de cliente. É recomendável que as cadeias de conexão do grupo de disponibilidade
designem o atributo MultiSubnetFailover para topologias de várias sub-redes ao referenciarem um
nome de ouvinte de grupo de disponibilidade. A opção de conexão MultiSubnetFailover habilita
o suporte para conexões de várias sub-redes e abre soquetes TCP para os endereços IP de ouvinte de
grupo de disponibilidade em paralelo. Para as bibliotecas de cliente herdadas que não dão suporte ao
atributo MultiSubnetFailover, você deverá considerar o tempo limite de logon apropriado do cliente.
Para saber mais sobre considerações de conectividade de cliente e failover de aplicativo, consulte
Conectividade de cliente e failover de aplicativo (Grupos de Disponibilidade AlwaysOn) nos Manuais
Online do SQL Server.
Configurando a solução FCI+AG
Este fluxo de trabalho descreve as etapas necessárias para criar a solução FCI+AG. Embora não seja
descrita aqui cada etapa detalhada, o objetivo desta seção é ajudar a esclarecer as etapas de
implementação de fluxo de trabalho e as tarefas para cada cargo participante. A documentação de
suporte será mencionada quando apropriado. As etapas são divididas por cargo porque a maioria dos
ambientes de grandes empresas define uma separação de tarefas entre as funções de administrador de
banco de dados, administrador do Windows (ou cluster) e administrador de rede. Por isso, é importante
se comunicar e coordenar corretamente as atividades nas diferentes funções.
Instalando pré-requisitos
Antes de implantar sua solução de Grupos de Disponibilidade AlwaysOn, é importante verificar se seu
sistema atende aos requisitos, incluindo atualizações. Para saber mais sobre os pré-requisitos da
implantação de uma solução de Grupos de Disponibilidade AlwaysOn, consulte Pré-requisitos, restrições
e recomendações para Grupos de Disponibilidade AlwaysOn (SQL Server). É altamente recomendável
que você examine este tópico antes de continuar.
Todos os nós devem ter a mesma versão do sistema operacional Windows Server e as atualizações de
software instaladas. O sistema operacional de servidor deve ser, no mínimo, o Windows Server
2008 SP2 ou o Windows Server 2008 R2 SP1 com pelo menos as seguintes atualizações:



Armazenamento assimétrico (se você estiver usando o Windows Server 2008):
http://support.microsoft.com/kb/976097
Votos de nós: http://support.microsoft.com/kb/2494036
Validar o teste de disco durante a validação de cluster:
http://support.microsoft.com/kb/2531907
Você talvez precise de atualizações adicionais.
15
Configurando a solução no data center primário
A Tabela 1 fornece o fluxo de trabalho para configuração dos nós do data center primário e presume
que haja dois nós.
16
Etapa
1. Adicione o recurso de clustering de
failover em dois nós localizados no data
center primário. Para saber mais sobre
esse processo, consulte Instalar o recurso
Clustering de Failover. Para saber mais
sobre como validar sua infraestrutura de
rede e outros requisitos, consulte
Compreendendo os requisitos para
clusters de failover.
2. Examine os pré-requisitos necessários
e instale as atualizações de software
necessárias do Windows Server em cada
nó do data center primário.
3. Verifique se os volumes de
armazenamento compartilhado
designados para a FCI do data center
primário estão formatados e fornecidos
com uma letra de unidade.
Recomendamos que as letras de unidade
e o caminho do diretório correspondentes
para a FCI de DR correspondam à FCI
primária. Mantenha essa consideração em
mente ao atribuir letras de unidade na FCI
primária.
4. Valide se a conta que você usará para
instalar e configurar o WSFC é uma conta
de domínio. Essa conta também deve ter
permissões de administrador em cada nó
do cluster, além das permissões Criar
Objetos de Computador e Ler Todas as
Propriedades no contêiner usado para as
contas de computadores do domínio.
Como alternativa, você pode preparar
previamente as contas de objetos de
nome ou usar uma conta de administrador
de domínio para a instalação. Para saber
mais sobre as permissões necessárias e as
opções de provisionamento, consulte Guia
passo a passo de cluster de failover:
configurando contas no Active Directory.
17
Administrador Administrador Administrador
de banco de
do Windows
de rede
dados
Server \
cluster
Sim
Sim
(coordenação
das atividades
entre funções)
Sim
Sim
Sim
Etapa
5. Usando o Gerenciador de Cluster de
Failover, execute a validação de cluster
dos dois nós de servidor no data center
primário e no compartilhamento
compartilhado que será adicionado ao
WSFC. Execute a validação de modo
iterativo até que não haja nenhum erro
de bloqueio.
Se você for autorizado a passar para
a próxima etapa com os avisos existentes,
deverá entender todos os avisos para
ajudar a garantir uma configuração
estável. Para saber mais sobre a execução
de um teste de validação, consulte
Validando uma configuração de cluster de
failover.
6. Ao término da etapa de validação de
cluster, use o Gerenciador de Cluster de
Failover para criar um WSFC de dois nós.
Para obter mais informações, incluindo
uma visão geral detalhada desse
processo, consulte Criar um novo cluster
de failover.
7. Verifique se há um número ímpar de
votos; por exemplo, você pode fazer isso
incluindo um compartilhamento de
arquivos ou um nó adicional, conforme
discutido anteriormente neste
documento.
Se você escolher Maioria dos Nós
e Compartilhamentos de Arquivos, antes
de alterar a configuração, verifique se
concedeu permissões de leitura
e gravação na testemunha
compartilhamento de arquivos à conta de
cluster do WSFC.
8. Verifique se a instalação usa
armazenamento compartilhado
formatado que seja acessível apenas aos
dois nós localizados no data center
primário. Esses discos serão usados para
o SQL Server na próxima etapa.
18
Administrador Administrador Administrador
de banco de
do Windows
de rede
dados
Server \
cluster
Sim
Sim, para alguns
problemas que
podem ocorrer
no sistema de
rede dos nós
Sim
Sim
Sim
Sim, para alguns
problemas que
podem ocorrer
no sistema de
rede dos nós
Etapa
9. Instale uma instância FCI do SQL Server
2012 Enterprise no data center primário.
Para saber mais, consulte Criar um novo
cluster de failover do SQL Server.
Você deve executar duas instalações:
a primeira é Nova instalação de cluster de
failover do SQL Server, que cria a FCI, e a
segunda é Adicionar nó a um cluster de
failover do SQL Server no segundo nó do
data center primário.
10. Depois de instalar a primeira FCI, habilite
recursos do Grupo de Disponibilidade
AlwaysOn em ambas as instâncias do
SQL Server.
Para saber mais sobre o uso do SQL Server
Configuration Manager ou,
opcionalmente, do SQL Server
PowerShell, consulte Habilitar
e desabilitar Grupos de Disponibilidade
AlwaysOn. Observe que, ao habilitar
Grupos de Disponibilidade AlwaysOn para
a instância, você deve reiniciá-la para que
a alteração entre em vigor.
19
Administrador Administrador Administrador
de banco de
do Windows
de rede
dados
Server \
cluster
Sim
Etapa
Administrador Administrador Administrador
de banco de
do Windows
de rede
dados
Server \
cluster
11. Depois de habilitar a FCI de DR para dar
suporte a Grupos de Disponibilidade
AlwaysOn, faça backup de seus bancos de
dados de usuário de produção da topologia
herdada e, em seguida, restaure-os na FCI
do data center primário.
Observação: você pode optar por adiar
essa etapa até que a FCI de DR também
esteja disponível e o grupo de
disponibilidade possa ser configurado
com duas réplicas.
Você também deve gerar um script de
outros objetos do SQL Server da topologia
herdada de que seus bancos de dados de
usuário dependerão, mas que não
estejam contidos nos bancos de dados de
usuário restaurados (por exemplo, logons
do SQL Server, permissões em nível de
servidor associadas e trabalhos do SQL
Server Agent).
Isso é semelhante ao processo seguido ao
criar scripts de objetos dependentes que
são externos ao banco de dados
espelhado para uma parceria de
espelhamento de banco de dados.
Existem vários métodos que você pode
usar para transferir objetos e princípios
de banco de dados entre instâncias do
SQL Server. A tarefa Transferir Objetos do
SQL Server do Integration Services é um
desses métodos. Outro método, no qual
os logons e as senhas são transferidos
entre instâncias, é descrito aqui:
http://support.microsoft.com/kb/918992/
Tabela 1: Criando a solução FCI+AG no data center primário
20
Configurando a solução no data center de DR
Esta tabela fornece o fluxo de trabalho para configurar os nós secundários de recuperação de desastre
e criar o grupo de disponibilidade.
Etapa
Administrador
de banco de
dados
1. Adicione o recurso Clustering
de Failover a todos os nós
localizados no data center de
recuperação de desastre e que
participam da solução.
2. Examine os pré-requisitos
necessários e instale as
atualizações de software
necessárias do Windows Server
em cada nó do data center de DR.
3. Valide se a conta que você usará
para instalar e configurar o WSFC
é uma conta de domínio. Essa
conta também deve ter
permissões de administrador em
cada nó do cluster, além das
permissões Criar Objetos de
Computador e Ler Todas as
Propriedades no contêiner usado
para as contas de computadors
do domínio. Se você estiver
usando as mesmas contas que
o data center primário, essas
permissões já estarão definidas
corretamente.
4. Usando o Gerenciador de Cluster
de Failover, execute a validação
de cluster dos dois nós de
servidor e do armazenamento
compartilhado que integrarão
o WSFC existente. Se você vir
a mensagem de aviso de
armazenamento assimétrico
“O disco com a id XYZ só está
visível ou só pode ser colocado
em cluster por meio de um
subconjunto de nós”, não
precisará fazer nada, pois isso
é esperado e aceitável para
o armazenamento assimétrico.
Execute a validação de modo
iterativo até que não haja
nenhum erro de bloqueio.
Sim (coordenação
das atividades
entre funções)
21
Administrador
do Windows
Server \
cluster
Sim
Administrador de
rede
Sim
Sim
Sim
Sim, para alguns
problemas que
podem ocorrer no
sistema de rede
dos nós
Etapa
Administrador
de banco de
dados
5. Depois que a validação for
concluída, use o Gerenciador de
Cluster de Failover para adicionar
os dois nós de recuperação de
desastre ao WSFC existente.
6. Defina o NodeWeight dos nós do
WSFC do data center de
recuperação de desastre como
um peso 0 (zero) (consulte Figura
4: Solução de HA/DR FCI+AG com
atribuições de votos de nós para
ver um exemplo).
7. Esta instalação deve usar
o armazenamento compartilhado
e formatado acessível apenas
pelos dois nós localizados no data
center de DR. Esses discos serão
usados para o SQL Server na
próxima etapa.
Mantenha a letra da unidade e de
mapeamento idênticas para
simplificar a implantação do
grupo de disponibilidade em
etapas posteriores e permitir
operações de arquivos de banco
de dados que não exijam
intervenção manual ou
a interrupção da sessão do grupo
de disponibilidade.
8. Mova o armazenamento
disponível para um dos nós do
data center de DR para uso na
próxima etapa.
9. Instale uma instância FCI do SQL
Server 2012 Enterprise no data
center de recuperação de
desastre.
Você precisa executar a opção
Nova instalação de cluster de
failover do SQL Server em um
dos nós para criar a FCI e, em
seguida, executar a opção
Adicionar nó a um cluster de
failover do SQL Server no
segundo nó do data center de DR.
22
Administrador
do Windows
Server \
cluster
Sim
Administrador de
rede
Sim, para alguns
problemas que
podem ocorrer no
sistema de rede dos
nós
Sim
Sim
Sim
Sim
Sim, para coordenar
o endereço IP (se você
estiver usando
endereços IP
estáticos)
e considerações de
porta
Etapa
Administrador
de banco de
dados
10. Após a instalação das duas FCIs,
a próxima etapa será habilitar
recursos do Grupo de
Disponibilidade AlwaysOn na
instância do SQL Server do data
center de DR.
Sim
Para ver etapas detalhadas sobre
o uso do SQL Server Configuration
Manager ou, opcionalmente, do
PowerShell, consulte Habilitar
e desabilitar Grupos de
Disponibilidade AlwaysOn.
Observe que a habilitação do
Grupo de Disponibilidade
AlwaysOn para a instância exige
a reinicialização da instância para
entrar em vigor.
11. Gere um script de outros objetos Sim
do SQL Server da topologia
herdada de que seus bancos de
dados de usuário dependerão,
mas que não estejam contidos
nos bancos de dados de usuário
restaurados (por exemplo, logons
do SQL Server, permissões em
nível de servidor associadas
e trabalhos do SQL Server Agent).
Estes são os mesmos objetos que
talvez já estejam com os scripts
gerados e copiados na FCI do data
center primário.
12. Verifique se os possíveis
proprietários das duas FCIs foram
definidos corretamente, isto é, os
possíveis proprietários de INST_A
devem ser PRIMARYNODE1,
PRIMARYNODE2; e os possíveis
proprietários de INST_B devem
ser DRNODE1, DRNODE2.
23
Administrador
do Windows
Server \
cluster
Administrador de
rede
Etapa
Administrador
de banco de
dados
13. Crie um grupo de disponibilidade
(esta etapa envolve as FCIs
primária e de DR). Você pode
definir o modo de disponibilidade
como síncrono ou assíncrono,
dependendo das características
de carga de trabalho e de rede do
seu ambiente. Selecione
o failover manual para grupos de
disponibilidade. Em uma solução
FCI+AG, o failover de FCI
é automático e o failover do
grupo de disponibilidade
é manual. Para saber mais sobre
como configurar o failover para
esta solução, consulte Criação
e configuração de grupos de
disponibilidade.
14. Crie o ouvinte de grupo de
disponibilidade. Esta etapa não
será necessária se você já a tiver
configurado para a criação do
grupo de disponibilidade. Você
pode criar o ouvinte do grupo de
disponibilidade usando
Transact-SQL, o SQL Server
PowerShell ou um assistente do
SQL Server Management Studio.
Para saber mais sobre o uso de
vários métodos, consulte Criar ou
configurar um ouvinte de Grupo
de Disponibilidade.
Sim
Sim
Administrador
do Windows
Server \
cluster
Administrador de
rede
Sim, para verificar se
as portas de ponto de
extremidade estão
abertas e para
solucionar problemas,
quando necessário
Sim
Sim, para coordenar
considerações de
endereço IP e porta
Tabela 2: Criando a solução FCI+AG no data center de recuperação de desastre
Depois de concluir estas etapas no Gerenciador de Cluster de Failover do Windows, você poderá ver que
foi criado um novo grupo em Serviços e Aplicativos com o mesmo nome do grupo de disponibilidade.
Nesse novo grupo, você também encontrará o recurso de ouvinte de grupo de disponibilidade e endereços
IP associados a ouvintes (veja a Figura 5).
24
Figura 7: Após a configuração da FCI para a solução de design de DR, HA e AG
A Figura 7 mostra a exibição do WSFC da implantação. Observe que o ouvinte de AG na figura mostra
um endereço IP associado para fins ilustrativos; entretanto, são comuns dois endereços IP para
topologias de vários data centers.
Observação: quando o grupo de disponibilidade aparece como um recurso no WSFC, você não
deve tentar gerenciá-lo com o Gerenciador de Cluster de Failover ou com interfaces com escopo
definido pelo WSFC. Em vez disso, gerencie o grupo de disponibilidade dentro do contexto da
instância do SQL Server usando o SQL Server Management Studio, Transact-SQL ou o Windows
PowerShell. Para saber mais sobre o motivo pelo qual não se deve usar o Gerenciador de Cluster
de Failover ou outras interfaces com escopo definido pelo WSFC, consulte a postagem de blog
NÃO use o Gerenciador de Cluster de Failover do Windows para executar o Failover de Grupo de
Disponibilidade.
A Figura 8 mostra a implantação no SQL Server Management Studio. O painel mostra uma das FCIs com
a hierarquia de pastas do Pesquisador de Objetos de Alta Disponibilidade AlwaysOn aberta. Neste
exemplo, a FCI de DR é a réplica secundária e a outra FCI é a réplica primária. Os três bancos de dados
de disponibilidade que participam do grupo estão listados, bem como o nome do ouvinte do grupo de
disponibilidade.
25
Figura 8: Pós-configuração da FCI para a solução de design de DR, HA e AG no SQL Server Management Studio
Considerações sobre monitoramento
Migrar de uma topologia de FCI e espelhamento de banco de dados para uma solução de FCI e grupo de
disponibilidade exigirá novos métodos de monitoramento da topologia. Os métodos e as ferramentas
que você pode usar para monitorar a infraestrutura do grupo de disponibilidade incluem o Painel
AlwaysOn no SQL Server Management Studio, informações de estado do Pesquisador de Objetos,
políticas de Gerenciamento Baseado em Políticas, novos contadores de desempenho relacionados ao
grupo de disponibilidade, exibições do catálogo, exibições de gerenciamento dinâmico e uma sessão de
Eventos Estendidos que rastreia execuções recentes de instruções relacionadas a DDL AlwaysOn,
problemas de conectividade do WSFC, eventos de failover, alterações de estado e blocos de thread
de restauração.
O Painel AlwaysOn é uma forma recomendada de exibir rapidamente a integridade de um grupo de
disponibilidade específico. Nele, você pode consultar a localização da instância primária, o modo de
failover das réplicas, o estado de sincronização das réplicas e a prontidão de failover das várias réplicas.
Você também pode acessar os dados da sessão de Eventos Estendidos de Integridade AlwaysOn
diretamente no painel para exibir a atividade recente do grupo de disponibilidade, alterações de estado
e eventos.
26
Figura 9: Painel AlwaysOn
Além disso, é possível criar alertas do SQL Server Agent e respostas de trabalho com base em limites do
contador de desempenho e alterações de estado de grupo de disponibilidade. Para obter mais
informações e diretrizes sobre o monitoramento de um ambiente de grupo de disponibilidade, consulte
Monitoramento de grupos de disponibilidade.
Recuperando-se de um desastre
Esta seção descreve detalhadamente o fluxo de trabalho de etapas que você deve executar no caso de
uma interrupção da réplica primária no data center primário. Ela também inclui as etapas necessárias
para restaurar a disponibilidade da réplica primária no data center de recuperação de desastre. Uma
interrupção da réplica primária pode ser causada por um ou mais dos seguintes motivos:



Falha de todos os nós da FCI do data center primário
Falha do armazenamento da FCI do data center primário
Falha ou interrupções de rede que afetam o data center primário inteiro
Em qualquer um desses cenários, são necessárias determinadas ações no data center de recuperação de
desastre para retomar o serviço do SQL Server para os aplicativos.
A Figura 10 mostra a janela Informações de Quorum de Cluster para este cenário (essas informações
podem ser acessadas pelo Painel AlwaysOn e pelo link Exibir Informações de Quorum do Cluster). Ela
mostra o quorum antes de um desastre, onde ambos os nós de DR têm zero voto.
27
Figura 10: O estado “anterior” dos votos de quorum de cluster
O fluxo de trabalho a seguir especifica as etapas necessárias para recuperar um grupo de disponibilidade
no data center de recuperação de desastre no caso de uma interrupção do data center primário:
1. Force o quorum em um dos nós de DR e assegure-se de que os nós do data center primário não
formem seu próprio quorum.
É improvável que o Gerenciador de Cluster de Failover iniciado em um nó de recuperação de
desastre forneça (inicialmente) informações úteis sobre o estado do WSFC, pois o cluster não tem
mais quorum.
Figura 11: Gerenciador de Cluster de Failover depois de um desastre e antes da recuperação
Como as FCIs dependem de um WSFC em funcionamento, elas estarão acessíveis, a menos que um
quorum de cluster e o serviço de cluster estejam em execução. Para um cenário em que o status do
data center primário é incerto e o serviço deve ser restaurado do data center de DR secundário para
estar em conformidade com objetivos de tempo de recuperação da empresa, você deve forçar
o quorum em um dos nós de DR.
O comando a seguir do Windows PowerShell demonstra como forçar o quorum em um dos nós de DR.
Start-ClusterNode –Name "DRNODE1" –FixQuorum
28
Depois de executar esse comando, você verá algo semelhante à saída a seguir.
Name
------drnode1
State
-------Joining
Observação: se o serviço de cluster ainda estiver em execução em “DRNODE1”, você
poderá usar o comando a seguir no Windows PowerShell para pará-lo antes de reiniciar
o serviço de cluster com quorum forçado.
Stop-ClusterNode –Name "DRNODE1"
Para verificar ferramentas adicionais que podem ser usadas para forçar o quorum, como
o cluster.exe ou o Gerenciador de Cluster de Failover, consulte Forçar um cluster do WSFC a iniciar
sem um quorum.
2. Abra o Gerenciador de Cluster de Failover para verificar o status do cluster do Windows. Neste
ponto, o cluster do Windows deve estar ativo no estado de quorum forçado, e a FCI secundária
deve estar ativa. A FCI do data center primário ainda estará offline, assim como os recursos do
grupo de disponibilidade.
Figura 12: Gerenciador de Cluster de Failover depois de forçar o quorum
3. Coloque o grupo de disponibilidade online na FCI de recuperação de desastre.
Cuidado: se a réplica foi configurada com o modo assíncrono, isso significa que restaurar o serviço
poderá resultar na perda de dados para todos os registros de log não enviados. Certifique-se de que
você compreende totalmente as consequências dessa ação.
Para saber mais sobre o que fazer antes, durante e depois desse tipo de failover manual, consulte
Executar um failover manual forçado de um Grupo de Disponibilidade.
Conecte-se à FCI no data center de DR usando o SQL Server Management Studio, que deve mostrar
os bancos de dados de disponibilidade em um estado “não sincronizando”. A FCI de DR também
deverá ser mostrada como “resolvendo”, como mostra a Figura 13.
29
Figura 13: O Pesquisador de Objetos do SQL Server Management Studio depois de forçar o quorum
Observe na Figura 13 que a outra réplica, que neste exemplo é ”SQLFCIPrimary\INST_A”, não
mostra nenhum estado no pesquisador de objetos na pasta ‘Réplicas de Disponibilidade’ do
AG1. Essa é a FCI do data center primário que não está mais acessível devido à interrupção.
Se o risco de alguma perda de dados for aceitável e o serviço precisar ser restaurado no data
center, execute a sintaxe Transact-SQL a seguir na FCI de recuperação de desastre para forçar
o failover.
ALTER AVAILABILITY GROUP [AG1]
FORCE_FAILOVER_ALLOW_DATA_LOSS;
Neste ponto, seus bancos de dados no grupo de disponibilidade deverão estar disponíveis.
Consulte a Figura 14 para ver um exemplo do estado de failover depois de forçá-lo.
30
Figura 14: O Pesquisador de Objetos após o failover forçado
Depois que voltar a ficar online, as novas conexões ao ouvinte de grupo de disponibilidade serão
automaticamente roteadas para a réplica primária atual, que agora é hospedada pela FCI de
recuperação de desastre.
Observe também que você ainda verá diversas mensagens de aviso sobre os nós do data center
primário que não estão disponíveis no SQL Server Management Studio. A Figura 15 mostra um
exemplo disso.
Figura 15: O Painel AlwaysOn depois de um failover forçado
31
4. Em um nó do WSFC de DR, remova votos dos nós do data center primário e dê votos aos nós do
data center de DR. Os votos poderão ser removidos mesmo se os nós do data center primário não
estiverem disponíveis. Os dois nós que receberem um peso “1” serão os nós do WSFC de DR.
(Get-ClusterNode "DRNode1").NodeWeight=1
(Get-ClusterNode "DRNode2").NodeWeight=1
(Get-ClusterNode "PrimaryNode1").NodeWeight=0
(Get-ClusterNode "PrimaryNode2").NodeWeight=0
Observação: se o site de DR precisar ser usado por um período mais longo,
é recomendável que os membros de votação adicionais (nó ou compartilhamento de
arquivos do WSFC) sejam adicionados.
Antes de continuar, você pode validar que os votos do nó foram modificados conforme
planejado usando o comando do Windows PowerShell a seguir.
Get-ClusterNode | fl NodeName, NodeWeight
Como mencionado anteriormente no documento, os ambientes de grandes empresas costumam ter
uma separação de tarefas entre as funções de administrador de banco de dados, administrador do
Windows Server (ou cluster) e administrador de rede. A tabela a seguir recapitula o fluxo de trabalho de
recuperação de desastre descrito anteriormente, indicando quais áreas costumam ser incluídas nas
várias funções empresariais de uma perspectiva de planejamento.
Etapa
Administrador de
banco de dados
1. Confirme o estado atual do
data center primário e os nós
de recuperação de desastre do
WSFC restantes, coordenando
esforços.
2. Force o quorum em um dos
nós no site de DR para acessar
a FCI de DR.
3. Force o failover do grupo de
disponibilidade para a FCI de
recuperação de desastre.
4. Adicione votos aos nós de DR
e remova votos dos nós
primários.
Sim
Sim
Sim
Tabela 3: Recuperação de um desastre por cargo
32
Administrador do
Windows
Server\cluster
Sim
Sim
Administrador
de rede
Sim
Revertendo para o data center primário
Com o serviço restaurado no data center de recuperação de desastre, este cenário ilustrado neste
documento será considerado como um estado temporário até que os problemas do data center
primário sejam resolvidos. Um cenário de interrupção pode ter muitas variações e, portanto, variações
na recuperação. O cenário descrito aqui supõe um cenário de desastre onde os servidores do data
center primário estão inativos por um longo período.
Depois que os problemas com o data center primário forem resolvidos, e os nós no data center primário
forem religados, os nós tentarão se conectar ao WSFC. Depois que serem reconectados ao WSFC com
serviços de cluster em execução, os pesos do nó atribuídos no nó de recuperação de desastre deverão
estar em vigor. Este cenário também supõe que as instalações originais do SQL Server e dos bancos de
dados associados ainda estejam intactas.
A réplica na FCI do data center primário anteriormente com falha estará em um estado “não
sincronizando” (consulte Figura 16).
Figura 16: O SQL Server Management Studio depois da recuperação da FCI primária mas antes da retomada do grupo de
disponibilidade
A instância do SQL Server do site de DR (em nosso exemplo, “SQLFCIDR\DC2”) ainda é a réplica primária.
Observe também o símbolo de “pausa” para cada banco de dados de disponibilidade na pasta Bancos de
Dados de Disponibilidade.
Neste ponto, você deve avaliar se precisa salvar todos os dados (ou seja, as alterações de dados feitas
na réplica primária original, mas que não foram enviadas à réplica de DR pouco antes do desastre) ou
avançar com o restabelecimento das sessões da réplica.
33
Cuidado: retomar as réplicas de grupo de disponibilidade neste momento poderá causar perda de dados
e, portanto, se a perda de dados não for aceitável, os dados deverão ser salvos antes que o movimento
de dados seja retomado. Por outro lado, não retomar o grupo de disponibilidade fará com que os
arquivos de log de transações continuem aumentando nos bancos de dados da réplica de DR.
Um método para fazer isso seria criar um instantâneo do banco de dados nos bancos de dados secundários
suspensos (primário original) com a finalidade de extrair os dados necessários para sincronizar novamente
com a versão da réplica de DR dos bancos de dados de disponibilidade. O exemplo a seguir demonstra
como criar um instantâneo de banco de dados em um banco de dados de disponibilidade “não sincronizando”.
-- Create the database snapshot
CREATE DATABASE AppDB_A1 ON
( NAME = AppDB, FILENAME =
'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' )
AS SNAPSHOT OF AppDB;
GO
Os dados necessários agora podem ser extraídos do instantâneo de banco de dados e inseridos na
réplica primária atual de forma apropriada, antes de a movimentação de dados ser retomada.
Observação: para saber mais sobre os riscos de forçar o failover e reduzir a perda de dados,
consulte Failover e modos de failover.
Depois que a questão da perda de dados for tratada de modo adequado, e quando estiver na hora de
reverter o serviço novamente para o data center primário, a próxima etapa será mover a função de
réplica primária de volta ao data center primário de forma controlada:
1. Inicie a migração controlada de volta ao data center primário adicionando novamente os votos
de quorum aos dois nós do data center primário. Depois de definir essa configuração, verifique
mais uma vez se todos os nós do WSFC têm um voto.
2. Para retomar cada banco de dados participante do grupo de disponibilidade, execute os comandos
Transact-SQL ALTER DATABASE na FCI do data center primário. Aqui está um exemplo.
ALTER DATABASE AppDB SET HADR RESUME;
GO
ALTER DATABASE ConfigDB SET HADR RESUME;
GO
ALTER DATABASE ReportDB SET HADR RESUME;
GO
3. Para sincronizar antes do failover, modifique o grupo de disponibilidade na FCI de DR para usar
temporariamente o modo de disponibilidade de confirmação síncrona. O ideal é que
a configuração de confirmação síncrona seja feita durante um período de baixa atividade do
aplicativo, para minimizar o impacto da latência de transações em usuários.
Este é um exemplo do comando Transact-SQL (executado na FCI primária atual do data center
de recuperação de desastre). Neste exemplo, AG1 é o grupo de disponibilidade e a réplica do
data center primário é designada como SQLFCIPrimary\INST_A.
34
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
GO
Na mesma sessão do SQL Server Management Studio, execute o comando a seguir para definir
a confirmação síncrona também na réplica de DR.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
GO
4. Confirme o status da sincronização entre os dois locais (ambos os estados das réplicas devem
indicar “healthy” (íntegra) antes de você passar para a próxima etapa, o que significa que
ambas as réplicas de confirmação síncrona estão sincronizadas).
SELECT
role_desc,
synchronization_health_desc
FROM sys.dm_hadr_availability_replica_states;
5. Para fazer failover da FCI do data center de recuperação de desastre para a FCI do data center
primário anterior, conecte-se e execute o script a seguir na FCI do data center primário que se
tornará a nova réplica primária.
ALTER AVAILABILITY GROUP [AG1] FAILOVER;
6. Se sua topologia usa o modo de alto desempenho, como mencionado anteriormente, altere
o nó da réplica de FCI de recuperação de desastre novamente para confirmação assíncrona.
Execute o comando Transact-SQL a seguir na réplica primária.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH
(AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
GO
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH
(AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
GO
7. Remova os votos de quorum dos nós de recuperação de desastre.
35
A tabela a seguir recapitula o fluxo de trabalho de recuperação de desastre descrito anteriormente,
indicando quais áreas costumam ser incluídas nas várias funções empresariais de uma perspectiva de
planejamento.
Etapa
1. Após o serviço do data center
primário, os nós e a FCI forem
restaurados, adicione
novamente os votos de quorum
aos nós primários originais.
2. Retome as sessões do banco de
dados de disponibilidade em
cada réplica secundária.
3. Altere a réplica de FCI de
recuperação de desastre e a
réplica de FCI do data center
primário para confirmação
síncrona.
4. Confirme o status da
sincronização entre os dois locais
(ambos os estados das réplicas
devem indicar “healthy” (íntegra)
antes de você passar para
a próxima etapa).
5. Faça failover para a réplica de FCI
do data center primário.
6. Reverta a réplica de recuperação
de desastre para confirmação
assíncrona (para corresponder
à configuração original).
7. Remova os votos dos nós do
WSFC de DR.
Administrador
de banco de
dados
Administrador do
Windows
Server\cluster
Sim
Administrador
de rede
Sim
Sim
Sim
Sim
Sim
Sim
Tabela 4: Revertendo para o data center primário
Conclusão
Os Grupos de Disponibilidade do SQL Server 2012 AlwaysOn podem ser usados para substituir
o espelhamento de banco de dados em topologias com FCIs para alta disponibilidade e espelhamento
de banco de dados para recuperação de desastre. O padrão de design estende os recursos além do que
era oferecido em versões anteriores, permitindo uma unidade de failover com vários bancos de dados,
réplicas somente leitura e mais. A intenção deste white paper era apresentar uma nova solução de HA
e DR usando FCIs AlwaysOn e Grupos de Disponibilidade AlwaysOn para substituir a arquitetura
herdada.
A implantação bem-sucedida de uma solução de HA/DR envolve não apenas a equipe do DBA, mas
a colaboração próxima entre a equipe do DBA, a equipe de administração do Windows Server e a equipe
de rede da organização de TI. O intercâmbio de habilidades é muito valioso quando você implanta
a solução de HA/DR.
36
Referências













Padrões de design de alta disponibilidade e recuperação de desastre do SQL Server 2012 AlwaysOn
(http://go.microsoft.com/fwlink/?LinkId=255048)
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de
desastre (http://msdn.microsoft.com/library/hh781257.aspx)
Instâncias de cluster de failover AlwaysOn (http://technet.microsoft.com/library/ms189134.aspx)
Visão geral de Grupos de Disponibilidade AlwaysOn
(http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx)
Clustering de Failover e Grupos de Disponibilidade AlwaysOn
(http://technet.microsoft.com/library/ff929171.aspx)
Pré-requisitos, restrições e recomendações para Grupos de Disponibilidade AlwaysOn
(http://technet.microsoft.com/library/ff878487(v=sql.110).aspx)
Guia passo a passo de cluster de failover: configurando o quorum em um cluster de failover
(http://technet.microsoft.com/library/cc770620(v=WS.10).aspx)
Hotfix do Windows Server para votos de quorum (http://support.microsoft.com/kb/2494036)
Windows PowerShell (http://technet.microsoft.com/library/bb978526)
Mapeando comandos do Cluster.exe para cmdlets do Windows PowerShell para clusters de failover
(http://technet.microsoft.com/library/ee619744(v=WS.10).aspx)
Guia de sobrevivência do Windows PowerShell
(http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survivalguide-en-us.aspx)
Cmdlets de cluster de failover no Windows PowerShell
(http://technet.microsoft.com/library/ee461009.aspx)
SQL Server PowerShell (http://msdn.microsoft.com/pt-br/library/hh245198.aspx)
Para saber mais:
Site do SQL Server (http://www.microsoft.com/sqlserver/)
SQL Server TechCenter (http://technet.microsoft.com/sqlserver/)
SQL Server DevCenter (http://msdn.microsoft.com/sqlserver/)
Este white paper ajudou você? Envie seus comentários. Em uma escala de 1 (ruim)
a 5 (excelente), como você classificaria este white paper e por quê? Por exemplo:


Você está classificando-o como excelente devido aos bons exemplos, às excelentes
capturas de tela, à clareza do texto ou por outro motivo?
Você está classificando-o como ruim devido aos exemplos insatisfatórios, às capturas
de tela confusas ou ao texto mal-escrito?
Os comentários nos ajudam a melhorar a qualidade dos white papers que lançamos.
Enviar comentários
37