FCI e AG para DR

SESSÃO: INFRAESTRUTURA

TRILHA: PLATAFORMA DE DADOS & BUSINESS INTELLIGENCE (IT)

MVP ShowCast 2013
AlwaysOn Failover Cluster e Availability Group
em um Cenário de Disaster Recovery
Nilton Pinheiro
SQL Server
SQL Server Specialist
@nilton_pinheiro
© 2013, MVP ShowCast. Evento organizado por MVPs do Brasil com apoio da Microsoft.


Agenda
♦
♦
♦
♦
♦
♦
♦

Alta disponibilidade no SQL Server
Uma necessidade comum
Cenário com FCI + DBM
Cenário com FCI + AG
Considerações sobre FCI + AG
Quorum Guidelines para FCI + AG
Referências





Alta Disponibilidade no SQL Server
AlwaysOn Failover Cluster Intance
proteção no nível de instâncias

AlwaysOn Availability Groups

proteção no nível de banco de dados ou grupo
de bancos de dados

Database Mirroring

proteção no nível de banco de dados

Log Shipping





AlwaysOn Failover Cluster Intance
proteção no nível de instâncias

♦ Requer a utilização de storages compartilhada (shared disks)
♦ Para soluções de DR:
♦ Requer replicação de dados entre storages ou
♦ Combinação de FCI + DBM/Log Shipping ou FCI + AG

♦ Suporte a TEMPDB em disco local
♦ Requer Windows Server Failover Clustering (WSFC)
♦ Garante disponibilidade das bases de sistemas e usuários
♦ Alto custo
♦ Não permite “nó secundário” ativo (leitura ou backup)



AlwaysOn Availability Groups

proteção no nível de banco de dados ou grupo de bancos de dados

♦ Requer WSFC
♦ Suporta até 4 servidores secundários (réplicas)
♦ 2 síncronos (failover automático)
♦ 2 assíncronos (failover manual)

♦ Failover de múltiplos bancos de dados
♦ Servidores secundários ativos (readonly)
♦ Redirecionamento automático das aplicações usando nome/ip virtual
(listener)
♦ Não requer uso de storage
♦ Não espelha as bases de sistemas



Database Mirroring


♦ Failover automático requer “Witness” e parâmetro FailoverPartner na string
de conexão da aplicação
♦ Suporta apenas 1 secundário
♦ Replicação síncrona ou assícrona
♦ Failover é banco a banco
♦ Bases indisponíveis para leitura (possível com database snapshot)
♦ Não suporta utilização de nome/ip virtual (listener)
♦ Não requer uso de storage
♦ Não espelha as bases de sistemas



Log Shipping


♦ Diferentes bancos podem ser replicados para diferentes secundários
♦ Replicação é feita através dos log de transação de cada banco de dados
♦ SQL Jobs fazem backup, copiam pela rede e restauram no secundário

♦ Depende totalmente dos backups/restore dos logs
♦ Tudo que está no backup de log é transferido
♦ Failover é sempre manual e requer redirecionamento das aplicações
♦ Configuração e manutenção complexas
♦ Bases “espelho” podem ficar disponíveis para leitura nos secundários
(standby)



Uma Necessidade Comum
Movimentação
de dados Síncrona

Movimentação de
dados Assíncrona

♦ Alta disponibilidade local (site
principal) com failover
automático.
♦ Se o site principal cair, deve-se
fazer failover para o site de
contingência (DR).

A

A


♦ Para reduzir custo, replicação
entre storage não é uma opção.



Cenário com FCI + DBM
♦ Failover Cluster Instance (FCI)
em cada site provê a alta
disponibilidade local

Movimentação de
dados Assíncrona

Movimentação
de dados Síncrona

♦ Cada site possui seu próprio
Windows Server Failover Cluster
(WSFC)

Failover Manual
(Database Mirroring)

A

A

♦ Cada site possui sua própria
shared storage
♦ Database Mirroring (DBM) para
Disaster Recovery: oferece
proteção no nível de banco de
dados entre os sites
♦ No site DR o SQL Server pode
ser uma instância stand-alone




Cenário com FCI + AG
Movimentação de
dados Assíncrona

Movimentação
de dados Síncrona

Requisito do Availability Group:

♦ Todas as réplicas de um AG devem
pertencer a um único Windows Server
Failover Cluster (WSFC)

Failover Manual
(Availability Group)

Pontos para consideração:

A

A

♦ Algumas variações possíveis da arquitetura
♦
♦
♦
♦

Múltiplos data centers
Múltiplas réplicas: 1 primária e até 4 réplicas secundárias
Múltiplos Availability Groups, podendo criar um agrupamento lógico de bancos de dados
As réplicas não precisam estar em FCI (stand-alone)


♦ Shared storage com discos visíveis
apenas aos nós de cada site
(Asymmetric storage)
♦ Modelo do quorum e política de
votação dos nós



Considerações sobre FCI + AG
♦ Storage
♦ Asymmetric storage: discos são compartilhados apenas com os nós dos respectivos sites
♦ Suportado no Windows 2008 ou Windows 2008 SP2 através de hotfix (KB 976097)
♦ Suportado no Windows 2008 R2 SP1
♦ Ponto chave para o funcionamento do FCI + AG

♦ Extremamente recomendado que letras dos discos e caminhos sejam idênticos entre os sites
♦ Facilitar a configuração do AG
♦ Evitar problemas com adição de novos arquivos (Troubleshoot a Failed Add-File Operation (AlwaysOn Availability
Groups))

♦ Nome das Instâncias: no mesmo WSFC as duas FCI devem usar nomes diferentes
♦ Conectividade dos clientes:
♦ Pode ser feita usando o nome virtual do cluster (VNN) ou o Availability Group Listener Name
♦ Recomendado utilizar o “Availability Group Listener Name”

♦ Modo de Failover:
♦ Automático no FCI
♦ Manual entre o FCI e Availability Group



Quorum Guidelines FCI + AG
 Modelo de quorum e nós votantes no cluster




 Modelo de quorum e nós votantes no cluster
 Antes de selecionar o modelo de quorum para o cluster, considere o número de nós votantes
 Por default, cada nó do cluster conta 1 voto
♦ Para uma solução de HA/DR pode não ser o mais apropriado
♦ KB 2494036 permite remover o voto dos nós (Windows 2008/ Windows 2008 R2)
 Recomendações gerais para configuração de votos em ambientes FCI + AG
 Inclua todos os nós do site primário
 Inclua possíveis owners de failover automático
 Exclua os nós dos sites secundários (DR)
 Mantenha sempre um número impar de votos
 Pós-failover, reavalie a configuração do quorum
 Regra geral:
Característica do cluster
Número impar de nós
Número pares de nós (mas não multi-site cluster)
Número pares de nós (em multi-site cluster)
Número pares de nós (não shared storage)

Recomendação para Quorum
Node Majority
Node and Disk Majority
Node and File Share Majority
Node and File Share Majority




♦ Outros modelos possíveis:
♦ Node and Disk Majority
♦ No Majority: Disk Only

Failover Manual
(Availability Group)

** Windows 2008 R2 SP1 ou Windows 2008
SP2 + KB 976097
A
NÃO
VOTO

NÃO
VOTO

VOTO

VOTO

A

VOTO

FileShare




 No Windows Server 2012 a votação é dinâmica (Dynamic quorum)




Referências
♦ Migration Guide: Migrating to SQL Server 2012 Failover Clustering and Availability Groups from
Prior Clustering and Mirroring Deployments
♦ Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery
♦ Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster
♦ Recommended Adjustments to Quorum Voting
♦ Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)

♦ Client Connectivity and Application Failover (AlwaysOn Availability Groups)
♦ Asymmetric Storage: http://support.microsoft.com/kb/976097
♦ Node Votes: http://support.microsoft.com/kb/2494036
♦ Dynamic quorum:
♦ http://technet.microsoft.com/en-us/library/jj612870.aspx
♦ http://blogs.technet.com/b/aevalshah/archive/2013/06/05/windows-server-2012-failover-clustering-dynamicquorum-revisited.aspx


Perguntas & Respostas



FCI e AG para DR

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (8)

Destaque

Destaque (10)

Semelhante a FCI e AG para DR

Semelhante a FCI e AG para DR (20)

Mais de MVP ShowCast

Mais de MVP ShowCast (8)

FCI e AG para DR