alwayson architecture guide - building a high availability...

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árioIntroduçã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..........................................11

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

Configurando a solução no data center de DR......................................................................................20

Considerações sobre monitoramento.......................................................................................................25

Recuperando-se de um desastre...............................................................................................................26

Revertendo para o data center primário...................................................................................................32

Conclusão..................................................................................................................................................35

Referências................................................................................................................................................36

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

http://msdn.microsoft.com/library/hh923056.aspx





http://go.microsoft.com/fwlink/?LinkId=255048


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.

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.

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 ServerUma 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étricoDuas 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ânciaAs 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

http://support.microsoft.com/kb/976097



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 failoverPara 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 quorumObservaçã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

http://technet.microsoft.com/library/cc770620(v=WS.10).aspx


http://msdn.microsoft.com/library/hh510190

http://msdn.microsoft.com/library/hh510190

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

http://msdn.microsoft.com/library/hh270280.aspx#RecommendedAdjustmentstoQuorumVoting


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



http://technet.microsoft.com/library/cc770620(v=ws.10).aspx#BKMK_asymmetric

http://technet.microsoft.com/library/cc770620(v=ws.10).aspx#BKMK_asymmetric

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 quorumHá 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 Para alterar o modelo de quorum

Gerenciador de Cluster de Failover do Windows

Windows PowerShellCluster.exe

DMVs do SQL ServerPainel AlwaysOn no SQL Server

Management Studio

Gerenciador de Cluster de Failover do WindowsWindows 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ósWindows PowerShell

Cluster.exeDMVs do SQL Server

Painel AlwaysOn

Windows PowerShellCluster.exe

Configurando o modelo de quorum do WSFCAqui 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 quorumEmbora 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 cluster_name, quorum_type_desc, quorum_state_descFROM sys.dm_hadr_cluster;

Quando essa consulta é executada no exemplo abordado neste white paper, retorna o resultado a seguir

cluster_name quorum_type_desc quorum_state_desc------------ ---------------- -----------------contosocluster NODE_AND_FILE_SHARE_MAJORITY NORMAL_QUORUM

Para exibir os votos de nós, consulte a DMV sys.dm_hadr_cluster_members.

SELECT member_name, number_of_quorum_votesFROM 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 number_of_quorum_votes------------------ ----------------------PrimaryNode1 1PrimaryNode2 1DRNode1 0DRNode2 0File Share Witness 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

http://technet.microsoft.com/library/hh231519(v=sql.110).aspx

http://technet.microsoft.com/pt-br/library/hh212952(v=sql.110).aspx

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ósA 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-redesO 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é-requisitosAntes 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:


Você talvez precise de atualizações adicionais. 15




http://msdn.microsoft.com/library/ff878487(v=sql.110).aspx


http://msdn.microsoft.com/library/hh213417(v=sql.110).aspx



Configurando a solução no data center primárioA 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 Administrador de banco de dados

Administrador do Windows Server \cluster

Administrador de rede

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.

Sim (coordenação das atividades entre funções)

Sim

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.

Sim

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.

Sim

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.

Sim

17

http://technet.microsoft.com/library/cc731002(WS.10).aspx



http://technet.microsoft.com/library/cc771404.aspx







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.

Sim Sim, para alguns problemas que podem ocorrer no sistema de rede dos nós

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.

Sim

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.

Sim

18








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.

Sim

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




http://msdn.microsoft.com/library/ms179530(v=sql.110).aspx

http://msdn.microsoft.com/library/ms179530(v=sql.110).aspx




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

http://support.microsoft.com/kb/918992/

Configurando a solução no data center de DREsta tabela fornece o fluxo de trabalho para configurar os nós secundários de recuperação de desastre e criar o grupo de disponibilidade.




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.

Sim (coordenação das atividades entre funções)

Sim

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.

Sim

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.

Sim

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.


21




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

Sim

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.

Sim

8. Mova o armazenamento disponível para um dos nós do data center de DR para uso na próxima etapa.

Sim

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.

Sim Sim, para coordenar o endereço IP (se você estiver usando endereços IP estáticos) e considerações de porta

22




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.

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.

Sim

11. Gere 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).

Estes são os mesmos objetos que talvez já estejam com os scripts gerados e copiados na FCI do data center primário.

Sim

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







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.

Sim Sim, para verificar se as portas de ponto de extremidade estão abertas e para solucionar problemas, quando necessário

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




http://msdn.microsoft.com/library/ff878265.aspx



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 monitoramentoMigrar 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 desastreEsta 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 State------- --------drnode1 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.


Administrador do Windows Server\cluster


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.

Sim Sim Sim

2. Force o quorum em um dos nós no site de DR para acessar a FCI de DR.

Sim

3. Force o failover do grupo de disponibilidade para a FCI de recuperação de desastre.

Sim

4. Adicione votos aos nós de DR e remova votos dos nós primários.

Sim

Tabela 3: Recuperação de um desastre por cargo

32

Revertendo para o data center primárioCom 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 snapshotCREATE 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;GOALTER DATABASE ConfigDB SET HADR RESUME;GOALTER 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

http://technet.microsoft.com/library/hh213151.aspx

USE [master]GOALTER 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]GOALTER 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]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);GO

USE [master]GOALTER 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.


Administrador do Windows Server\cluster


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.

Sim

2. Retome as sessões do banco de dados de disponibilidade em cada réplica secundária.

Sim

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.

Sim

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

Sim

5. Faça failover para a réplica de FCI do data center primário.

Sim

6. Reverta a réplica de recuperação de desastre para confirmação assíncrona (para corresponder à configuração original).

Sim

7. Remova os votos dos nós do WSFC de DR.

Sim

Tabela 4: Revertendo para o data center primário

ConclusãoOs 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-survival-guide-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

mailto:[email protected]?subject=Coment%E1rios%20sobre%20o%20white%20paper:%20Guia%20da%20arquitetura%20AlwaysOn:%20criando%20uma%20solu%E7%E3o%20de%20alta%20disponibilidade%20e%20recupera%E7%E3o%20de%20desastre%20usando%20inst%E2ncias%20de%20cluster%20de%20failover%20e%20grupos%20de%20disponibilidade

http://msdn.microsoft.com/sqlserver/

http://technet.microsoft.com/sqlserver/

http://www.microsoft.com/sqlserver/

http://msdn.microsoft.com/pt-br/library/hh245198.aspx

http://technet.microsoft.com/library/ee461009.aspx

http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx

http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx

http://technet.microsoft.com/library/ee619744(v=WS.10).aspx

http://technet.microsoft.com/library/bb978526



http://technet.microsoft.com/library/ff878487(v=sql.110).aspx

http://technet.microsoft.com/library/ff929171.aspx

http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx

http://technet.microsoft.com/library/ms189134.aspx



alwayson architecture guide - building a high availability...

Documents