MVP Virtual Conference 2013Alta Disponibilidade e Integração de DadosNilton PinheiroLuciano Moreira

Nilton Pinheiro

SQL Server MVP | MCITP | MCSE | MCDBA | MCTS |

MCT

@nilton_pinheiro

http://www.mcdbabrasil

.com.br

niltonpinheiro@msn.com

Luciano Moreira [Luti]

SQL Server MVP | PASS RM | MC* | MCM

Wannabe

@luticmhttp://

luticm.blogspot.com

luciano.moreira@srnimbus.com.br

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 ComumMovimentação

de dados SíncronaMovimentação de dados Assíncrona Alta disponibilidade local

(site principal) com failover automático.

A

A

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

Site Principal

Site Contingência(DR)

Para reduzir custo, replicação entre storage não é uma opção.Relatórios

AFailover

Clustering

DB Mirroring

Log Shipping

Cenário – FCI + DBMMovimentação

de dados SíncronaMovimentação de dados Assíncrona

A

A

Site Princip

al

Site DR

VSQLINST1

WSFC “A”

WSFC “B”

VSQLINST1

Failover Cluster Instance (FCI) em cada site provê a alta disponibilidade local

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

MirrorDatabase Principal

Database

Failover Manual(Database Mirroring)

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

No site DR o SQL Server pode ser uma instância stand-alone

SQL Server AlwaysOn

Multisite Clustering através de subnets

Política de Failover Flexível Windows Server Core TEMPDB em disco local

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 Availability Groupsproteção no nível de banco de dados

AlwaysOn Failover Cluster Instancesproteção no nível de instância

Novas soluções com AlwaysOn

Cenário – FCI + AGMovimentação

de dados SíncronaMovimentação de dados Assíncrona

A

A

Site Princip

al

Site DR

VSQLINST1

WSFC “A”

VSQLINST2

Failover Manual(Availability

Group)

SecondaryDatabase

PrimaryDatabase

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

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

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

Requisito do Availability Group:

Pontos para consideração:

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 Recomendação para QuorumNúmero impar de nós Node MajorityNúmero pares de nós (mas não multi-site cluster) Node and Disk MajorityNúmero pares de nós (em multi-site cluster) Node and File Share MajorityNúmero pares de nós (não shared storage) Node and File Share Majority

A

A

Site Principal

Site DR

VSQLINST1

WSFC “A”

VSQLINST2

Failover Manual(Availability Group)

SecondaryDatabase

PrimaryDatabase

VOTOVOTONÃO

VOTONÃOVOT

O

FileShare

VOTO

Quorum Guidelines - FCI + AG Outros modelos

possíveis: Node and Disk

Majority No Majority: Disk

Only

** Windows 2008 R2 SP1 ou Windows 2008 SP2 + KB 976097

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!