AlwaysOn Availability Groups

MVP Virtual Conference 2013
Alta Disponibilidade e Integração de Dados
Nilton Pinheiro
Luciano Moreira
Nilton Pinheiro
[email protected]
@nilton_pinheiro
http://www.
mcdbabrasil
.com.br
SQL Server MVP | MCITP | MCSE |
MCDBA | MCTS | MCT
Luciano Moreira [Luti]
@luticm
[email protected]
http://luticm.blogspot.
com
SQL Server MVP | PASS RM |
MC* | MCM Wannabe
Agenda
Alta disponibilidade
“Ontem”
Cenários de alta
disponibilidade
Considerações e
Quorum
Guidelines
HA + Integração de
dados
Conclusão
Referências
Alta Disponibilidade “Ontem”
 Failover Clustering (FC)
 Requer uma storage compartilhada
 Não permite nó secundário ativo (leitura ou backup)
 Para disaster recovery (DR)
 Requer replicação síncrona entre storages ou uma combinação de FC com
Database Mirroring ou Log Shipping
 Database Mirroring
 Failover automático: requer SNAC ou o parâmetro FailoverPartner na
string de conexão, Witness
 Não permite conexão dos sistemas utilizando nome virtual
 É possível leitura no secundário utilizando database snapshot no mirror
Alta Disponibilidade “Ontem”
 Log Shipping
 Não permite failover automático
 Nós secundários offline (não permite leitura nos secundários)
 Difícil implementação e manutenção (Alto custo
operacional\administrativo)
 Failover no nível de banco de dados
Uma Necessidade Comum
Movimentação de
dados Assíncrona
Movimentação
de dados Síncrona
Log
Shipping

Alta disponibilidade local (site
principal) com failover
automático.

Réplica do banco de dados em
um terceiro servidor no site
principal para execucão de
relatórios.

Se o site principal cair, deve-se
fazer failover para o site de
contingência (DR).

Para reduzir custo, replicação
entre storage não é uma opção.
DB
Mirroring
A
A
Failover
Clustering
A
Relatórios
Cenário – FCI + DBM
Movimentação de
dados Assíncrona
Movimentação
de dados Síncrona
Failover Manual
(Database Mirroring)

Failover Cluster Instance (FCI) em cada
site provê a alta disponibilidade local

Cada site possui seu próprio Windows
Server Failover Cluster (WSFC)

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
A
A
SQL Server AlwaysOn
Novas soluções com AlwaysOn
AlwaysOn Availability Groups
proteção no nível de banco de dados
 Failover de múltiplos bancos de dados
 Múltiplos servidores secundários
 Sevidores secundários ativos
 Gerenciamento integrado através de um
Dashboard
 Suporte a nome e IP virtual
AlwaysOn Failover Cluster
Instances
proteção no nível de instância
 Multisite Clustering através de
subnets
 Política de Failover Flexível
 Windows Server Core
 TEMPDB em disco local
Cenário – FCI + AG
Movimentação de
dados Assíncrona
Movimentação
de dados Síncrona
Requisito do Availability Group:

Failover Manual
(Availability Group)
Todas as réplicas de um AG devem
pertencer a um único Windows Server
Failover Cluster (WSFC)
Pontos para consideração:
A

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
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
Considerações – 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
 Sempre que possível utilize 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
 Antes de selecionar o modelo do quorum, conside o número de nós votantes no cluster
 Por default, cada nó do cluster conta 1 voto
 Para uma solução de HA/DR pode não ser o mais apropriado
 KB 2490036 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 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
Quorum Guidelines - FCI + AG
 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
NÃO
VOTO
A
NÃO
VOTO
VOTO
VOTO
A
VOTO
FileShare
Demo
Failover Cluster Intance
+ Availability Group
Integração de Dados
 Com a proliferação dos sistemas, existe
necessidade de se oferecer a integração dos
dados
 Durante a escolha da solução entre as alternativas
arquiteturais, existem trade-offs:





Tolerância para latência
Push versus pull
Granularidade
Relação mestre/subordinado
Lógica de sincronização versus latência
 Há diversas formas de fazermos integração dos dados,
até manutenção de fonte única é uma abordagem
Integração de Dados
 Opções de replicação de dados:
Move Copy of Data
Data Replication
Master-Master Replication
Master-Subordinate Replication
Master-Master Row-Level Synchronization
Master-Subordinate Snapshot Replication
Capture Transaction Details
Master-Subordinate Transactional Incremental
Replication
 Implementing Master-Master Row Level
Synchronization Using SQL Server
 Implementing Master-Subordinate Snapshot
Replication Using SQL Server
 Master-Subordinate Cascading Replication








Integração de Dados
 Always-on Availability Groups com secundários Read-Only
 É uma excelente forma de garantir a alta disponibilidade, mas também
a acessibilidade do dado
 Acessibilidade = menor overhead nos sistemas OLTP e possibilidade de
manutenção de sistemas em near real time
 Integration Services pode se beneficiar bastante para cargas de dados
incrementais
 Questões como latência do dado e modelo de sincronização entre
elementos do AG devem ser sempre considerados
Integração de Dados
 SSIS é uma plataforma extensível para
construir soluções de ETL complexas
 Disponível junto com o SQL Server
2012 para instalação
 Consiste em serviço do Windows e
diversas ferramentas auxiliares, para
desenvolvimento e execução dos
pacotes
 Integração com plataforma de
desenvolvimento .NET
Demo
SQL Server Integration
Services
Conclusão
 Existem diversos cenários de alta disponibilidade que podem ser
criados dependendo da necessidade do seu negócio
 AlwaysOn Availability Groups é uma das “estrelas” do SQL Server 2012
e facilita questões como separação de cargas de leitura / escrita
 O SSIS 2012 como ferramenta de integração pode se beneficiar dos
secundários ativos para integração de dados
 A plataforma SQL Server oferece uma cobertura ampla de soluções
para essas e outras questões
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
Obrigado!