Guia de soluções Microsoft SQL Server AlwaysOn para alta

Guia de soluções Microsoft SQL Server AlwaysOn
para alta disponibilidade e recuperação de desastre
Autor: LeRoy Tuttle, Jr. (Microsoft).
Colaboradores: Cephas Lin (Microsoft), Justin Erickson (Microsoft), Lindsey Allen (Microsoft),
Min He (Microsoft), Sanjay Mishra (Microsoft).
Revisores: Alexei Khalyako (Microsoft), Allan Hirt (SQLHA), Ayad Shammout (Caregroup),
Benjamin Wright-Jones (Microsoft), Charles Matthews (Microsoft), David P. Smith (ServiceU),
Juergen Thomas (Microsoft), Kevin Farlee (Microsoft), Shahryar G. Hashemi (Motricity),
Wolfgang Kutschera (Bwin Party).
Publicado em:
janeiro de 2012
Aplica-se a:
SQL Server 2012
Resumo:
Este white paper discute como reduzir o tempo de inatividade planejado e não
planejado, maximizar a disponibilidade do aplicativo e fornecer proteção de dados usando soluções de
alta disponibilidade e recuperação de desastre do SQL Server 2012 AlwaysOn.
Um objetivo fundamental deste documento é estabelecer um contexto comum para discussões
relacionadas entre participantes comerciais, tomadores de decisões técnicas, arquitetos de sistemas,
engenheiros de infraestrutura e administradores de bancos de dados.
O conteúdo é apresentado em duas partes principais:
Conceitos de alta disponibilidade e recuperação de desastre. Fornecem uma breve discussão dos
fatores comerciais e desafios de planejar, gerenciar e medir objetivos de negócios de um ambiente de
banco de dados altamente disponível. Essa discussão é seguida por uma breve visão geral dos recursos
de alta disponibilidade e recuperação de desastre de soluções do SQL Server 2012 AlwaysOn e do
Windows Server.
Camadas de proteção do SQL Server AlwaysOn. Fornecem uma descrição mais detalhada sobre os
recursos, a lógica e as dependências das camadas de proteção oferecidas por uma solução SQL Server
AlwaysOn. Descrevem a disponibilidade da infraestrutura, a proteção em nível de instância do SQL
Server, a proteção em nível de banco de dados e os recursos de aplicativo da camada de dados.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
i
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
ii
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 descritos aqui são fictícios e fornecidos apenas como ilustração. Nenhuma associação
ou ligação real é intencional 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.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
iii
Sumário
Conceitos de alta disponibilidade e recuperação de desastre .............................................................. 1
Descrevendo a alta disponibilidade .......................................................................................................... 1
Tempo de inatividade planejado e não planejado .................................................................................................................. 1
Disponibilidade inadequada ................................................................................................................................................... 2
Determinando o tempo de inatividade .................................................................................................... 2
Objetivos de recuperação ....................................................................................................................................................... 3
Justificando o ROI ou o custo de oportunidade ...................................................................................................................... 3
Monitorando a integridade da disponibilidade ...................................................................................................................... 4
Planejando a recuperação de desastre ................................................................................................................................... 4
Visão geral: alta disponibilidade com o Microsoft SQL Server 2012 ........................................................ 5
SQL Server AlwaysOn .............................................................................................................................................................. 5
Reduzir significativamente o tempo de inatividade planejado ............................................................................................... 5
Eliminar o hardware ocioso e aumentar a relação custo-benefício e o desempenho ............................................................ 6
Implantação e gerenciamento fáceis ...................................................................................................................................... 6
Fazendo a comparação de recursos de RPO e RTO ................................................................................................................ 6
Camadas de proteção do SQL Server AlwaysOn .................................................................................. 7
Infraestrutura de disponibilidade ............................................................................................................. 8
Sistema operacional Windows ................................................................................................................................................ 8
Windows Server Failover Clustering ....................................................................................................................................... 9
Assistente de validação de cluster do WSFC ......................................................................................................................... 11
Modos de quorum do WSFC e configuração de votação ...................................................................................................... 13
Recuperação de desastre do WSFC por meio de quorum forçado ....................................................................................... 16
Proteção em nível de instância do SQL Server ....................................................................................... 18
Aperfeiçoamentos de disponibilidade – instâncias do SQL Server ....................................................................................... 18
Instâncias de Cluster de Failover AlwaysOn ......................................................................................................................... 19
Disponibilidade do banco de dados ........................................................................................................ 21
Grupos de Disponibilidade AlwaysOn ................................................................................................................................... 21
Failover de grupo de disponibilidade .................................................................................................................................... 23
Ouvinte de grupos de disponibilidade .................................................................................................................................. 24
Aperfeiçoamentos de disponibilidade – bancos de dados ................................................................................................... 26
Recomendações de conectividade de cliente......................................................................................... 27
Conclusão ........................................................................................................................................ 28
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
iv
Conceitos de alta disponibilidade e recuperação de desastre
Você pode fazer a melhor seleção de uma tecnologia de banco de dados para uma solução de alta
disponibilidade e recuperação de desastre quando todos os participantes compreendem da mesma
forma os fatores comerciais, os desafios e objetivos do planejamento, o gerenciamento e a medição de
objetivos de RTO e RPO.
Os leitores que estiverem familiarizados com esses conceitos poderão passar diretamente para a seção
Visão geral: alta disponibilidade com o Microsoft SQL Server 2012 deste documento.
Descrevendo a alta disponibilidade
Para um determinado aplicativo de software ou serviço, a alta disponibilidade é medida em termos da
experiência e das expectativas do usuário final. O impacto tangível e percebido do tempo de inatividade
nos negócios pode ser expresso em termos de perda de informações, danos materiais, queda de
produtividade, custos de oportunidade, danos contratuais ou danos morais.
O principal objetivo de uma solução de alta disponibilidade é minimizar ou reduzir o impacto do tempo
de inatividade. Uma estratégia segura para isso equilibra da melhor maneira possível os processos de
negócios e SLAs (contratos de nível de serviço) com recursos técnicos e custos de infraestrutura.
Uma plataforma é considerada altamente disponível conforme o contrato e as expectativas dos clientes
e participantes. A disponibilidade de um sistema pode ser expressa como este cálculo:
𝑇𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒 𝑟𝑒𝑎𝑙
× 100%
𝑇𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒 𝑒𝑠𝑝𝑒𝑟𝑎𝑑𝑜
O valor resultante é frequentemente expresso pelo setor de atividade em termos do número de noves
que a solução oferece, cujo propósito é expressar um número anual de minutos de tempo de atividade
possível ou, por outro lado, minutos de tempo de inatividade.
Número de noves
2
3
4
5
Percentual de
disponibilidade
99%
99,9%
99,99%
99,999%
Tempo de inatividade
anual total
3 dias, 15 horas
8 horas, 45 minutos
52 minutos, 34 segundos
5 minutos, 15 segundos
Tempo de inatividade planejado e não planejado
As interrupções do sistema são previstas e planejadas ou resultam de uma falha não planejada. O tempo
de inatividade não precisa ser considerado um aspecto negativo se for gerenciado adequadamente.
Existem dois tipos principais de tempo de inatividade previsível:

Manutenção planejada. Uma janela de tempo pré-anunciada e coordenada para tarefas de manutenção
planejada, como a aplicação de patches de software, atualizações de hardware, atualizações de
senha, reindexação offline, carregamento de dados ou execução de testes de procedimentos de
recuperação de desastre. Os procedimentos operacionais deliberados e bem-gerenciados devem
minimizar o tempo de inatividade e impedir qualquer perda de dados. As atividades de manutenção
planejada podem ser consideradas como investimentos necessários para evitar ou reduzir outros
cenários de interrupção não planejada potencialmente mais severos.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
1

Interrupção não planejada. As falhas em nível de sistema, de infraestrutura ou de processo podem
ocorrer de forma não planejada ou incontrolável, ou podem ser previsíveis, mas consideradas muito
improváveis ou com um impacto aceitável. Uma solução de alta disponibilidade robusta detecta
esses tipos de falhas, faz uma recuperação automática da interrupção e, em seguida, restabelece
a tolerância a falhas.
Ao estabelecer SLAs para alta disponibilidade, você deve calcular KPIs (indicadores chave de desempenho)
separados para atividades de manutenção planejada e tempo de inatividade não planejado. Essa
abordagem permite comparar seu investimento em atividades de manutenção planejada com a vantagem
de evitar o tempo de inatividade não planejado.
Disponibilidade inadequada
A alta disponibilidade não deve ser considerada como uma proposta de tudo ou nada. Como alternativa
a uma interrupção total, em geral, é aceitável para o usuário final que um sistema esteja parcialmente
disponível ou que tenha uma funcionalidade limitada ou redução de desempenho. Esses vários graus de
disponibilidade incluem:

Operações somente leitura e adiadas. Durante uma janela de manutenção, ou durante uma
recuperação de desastre feita em fases, a recuperação de dados ainda é possível, mas os novos
fluxos de trabalho e o processamento em segundo plano podem estar temporariamente paralisados
ou enfileirados.

Latência de dados e capacidade de resposta do aplicativo. Devido a uma carga de trabalho pesada,
uma lista de pendências de processamento ou uma falha parcial da plataforma, os recursos de
hardware limitados podem estar sobrecarregados ou subdimensionados. A experiência do usuário
poderá ser afetada, mas o trabalho ainda poderá ser feito de uma forma menos produtiva.

Falhas parciais, temporárias ou iminentes. Robustez na lógica do aplicativo ou pilha de hardware que
faz novas tentativas ou correções automáticas ao encontrar um erro. Esses tipos de problemas podem
aparecer para o usuário final como latência de dados ou resposta insatisfatória do aplicativo.

Falha de ponta a ponta parcial. As interrupções planejadas ou não planejadas podem ocorrer nas
camadas verticais da pilha de solução (infraestrutura, plataforma e aplicativo), ou horizontalmente
entre componentes funcionais diferentes. Os usuários podem experimentar êxito ou degradação
parcial, dependendo dos recursos ou dos componentes afetados.
A possibilidade de aceitação desses cenários abaixo do ideal deve ser considerada como parte de um
espectro de redução de disponibilidade que resulta em interrupção total, bem como etapas intermediárias
em uma recuperação de desastre dividida em fases.
Determinando o tempo de inatividade
Quando ocorre o tempo de inatividade, planejado ou não, o principal objetivo empresarial é fazer
o sistema ficar novamente online e minimizar a perda de dados. Cada minuto de tempo de inatividade
tem custos diretos e indiretos. Com o tempo de inatividade não planejado, você deve equilibrar o tempo
e o esforço necessários para determinar por que a interrupção ocorreu, qual é o estado atual do sistema
e que etapas são necessárias para a recuperação da interrupção.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
2
Em um momento predeterminado em qualquer interrupção, você deve tomar ou obter a decisão
empresarial de parar de investigar a interrupção ou executar tarefas de manutenção, recuperar-se da
interrupção colocando o sistema novamente online e, se necessário, restabelecer a tolerância a falhas.
Objetivos de recuperação
A redundância de dados é um componente fundamental de uma solução de banco de dados de alta
disponibilidade. A atividade transacional na sua instância primária do SQL Server é aplicada de forma
síncrona ou assíncrona em uma ou mais instâncias secundárias. Quando ocorre uma interrupção, as
transações que estavam em andamento podem ser revertidas ou perder-se nas instâncias secundárias
devido a atrasos na propagação dos dados.
Você pode medir o impacto e definir metas de recuperação em termos de quanto tempo levará para
retomar os negócios e quanta latência de tempo há na última transação recuperada:

RTO (objetivo de tempo de recuperação). Essa é a duração da interrupção. A meta inicial é fazer
com que o sistema volte a ficar online pelo menos a uma capacidade de somente leitura para
facilitar a investigação da falha. Entretanto, a meta principal é restaurar o serviço completo até
o ponto em que novas transações possam ocorrer.

RPO (objetivo de ponto de recuperação). Isso é frequentemente chamado de medida de perda de
dados aceitável. É o intervalo ou a latência de tempo entre a última transação de dados confirmada
antes da falha e os dados mais recentes recuperados depois da falha. A perda de dados real pode
variar dependendo da carga de trabalho no sistema no momento da falha, do tipo de falha e do tipo
de solução de alta disponibilidade usado.
Use os valores de RTO e de RPO como metas que indicam a tolerância de tempo de inatividade
comercial e perda de dados aceitável, e como métricas para monitorar a integridade da disponibilidade.
Justificando o ROI ou o custo de oportunidade
Os custos empresariais do tempo de inatividade podem ser financeiros ou na forma de reputação do
cliente. Esses custos podem ser acumulados com o tempo ou podem incidir em um determinado ponto
na janela de interrupção. Além da projeção do custo de incorrer em uma interrupção com um tempo
e um ponto de recuperação de dados específicos, você também pode calcular o processo comercial e os
investimentos em infraestrutura necessários para atingir suas metas de RTO e RPO ou para evitar
qualquer interrupção. Esses temas de investimento devem incluir:

Evitar o tempo de inatividade. Os custos de recuperação de uma interrupção serão todos evitados,
antes de tudo, se não houver uma interrupção. Os investimentos incluem o custo de hardware ou
infraestrutura tolerante a falhas e redundante, a distribuição de cargas de trabalho por pontos de
falha isolados e o tempo de inatividade planejado para manutenção preventiva.

Recuperação automática. Se ocorrer uma falha do sistema, você poderá reduzir significativamente
o impacto do tempo de inatividade na experiência do cliente por meio da recuperação automática
e transparente.

Utilização de recursos. A infraestrutura secundária ou em espera pode permanecer ociosa,
aguardando uma interrupção. Ela também pode ser aproveitada para cargas de trabalho somente
leitura, ou para melhorar o desempenho geral do sistema com a distribuição de cargas de trabalho
em todo o hardware disponível.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
3
Para determinadas metas de RTO de RPO, os investimentos em disponibilidade e recuperação necessários,
combinados aos custos de tempo de inatividade projetados, podem ser expressos e justificados em
função do tempo. Durante uma interrupção real, isso permite que você tome decisões baseadas no
custo de acordo com o tempo de inatividade decorrido.
Monitorando a integridade da disponibilidade
De um ponto de vista operacional, durante uma interrupção real, você não deve tentar considerar todas
as variáveis relevantes e calcular o ROI ou os custos de oportunidade em tempo real. Em vez disso, deve
monitorar a latência de dados em suas instâncias em espera como um proxy para verificar o RPO
esperado.
No caso de uma interrupção, você também deve limitar o tempo inicial gasto na investigação da causa
raiz durante a interrupção e, em vez disso, concentrar-se na validação da integridade de seu ambiente
de recuperação, para depois recorrer aos logs detalhados do sistema e às cópias secundárias de dados
para obter uma análise investigativa subsequente.
Planejando a recuperação de desastre
Embora os esforços de alta disponibilidade envolvam o que você faz para impedir uma interrupção, os
esforços de recuperação de desastre tratam do que é feito para restabelecer a alta disponibilidade após
a interrupção.
Tanto quanto possível, os procedimentos de recuperação de desastre e as responsabilidades devem ser
formulados antes que ocorra uma interrupção real. Com base em monitoramento e alertas ativos,
a decisão de iniciar um failover automático ou manual e um plano de recuperação deve estar ligada
a limites preestabelecidos de RTO e RPO. O escopo de um plano de recuperação de desastre satisfatório
deve incluir:

Granularidade de falha e recuperação. Dependendo do local e do tipo de falha, você pode executar
uma ação corretiva em níveis diferentes; ou seja, no data center, na infraestrutura, na plataforma,
no aplicativo ou na carga de trabalho.

Material de origem investigativa. Linha de base e histórico de monitoramento recente, alertas do
sistema, logs de eventos e consultas de diagnóstico devem estar prontamente acessíveis às partes
adequadas.

Coordenação de dependências. Na pilha do aplicativo, por meio dos participantes, quais são as
dependências do sistema e da empresa?

Árvore de decisão. Uma árvore de decisão predeterminada, repetível e validada que inclui as
responsabilidades das funções, a triagem de falhas, os critérios de failover em termos de metas de
RPO e RTO e as etapas de recuperação prescritas.

Validação. Depois de executar as etapas para a recuperação da interrupção, o que deve ser feito
para verificar se o sistema retornou às operações normais?

Documentação. Capture todos os itens acima em um conjunto de documentação, com detalhes
e clareza suficientes para que uma equipe terceirizada possa executar o plano de recuperação com
assistência mínima. Esse tipo de documentação geralmente é chamado de ‘processos de compilação
de rotinas’ ou ‘livro de receitas’.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
4

Execuções de teste de recuperação. Pratique regularmente o plano de recuperação de desastre
para estabelecer expectativas de base para metas de RTO, e considere a rotação normal de
hospedagem do site de produção primário entre o site primário e cada um dos sites de recuperação
de desastre.
Visão geral: alta disponibilidade com o Microsoft SQL Server 2012
O cumprimento das metas necessárias de RPO e RTO envolve garantir o tempo de atividade contínuo de
aplicativos essenciais e proteger os dados críticos contra os tempos de inatividade planejado e não
planejado. O SQL Server fornece um conjunto de recursos que podem ajudá-lo a cumprir essas metas
mantendo os custos e a complexidade baixos.
Os leitores que já estiverem familiarizados com os recursos AlwaysOn poderão passar diretamente para
a abordagem mais detalhada na seção Camadas de proteção do SQL Server AlwaysOn deste
documento.
SQL Server AlwaysOn
O AlwaysOn é uma nova solução de alta disponibilidade e recuperação de desastre integrada, flexível
e econômica. Ele pode fornecer redundância de dados e hardware em um ou mais data centers,
e melhora o tempo de failover de aplicativo para aumentar a disponibilidade de seus aplicativos críticos.
O AlwaysOn fornece flexibilidade na configuração e permite a reutilização dos investimentos em
hardware existentes.
Uma solução AlwaysOn pode utilizar dois recursos importantes do SQL Server 2012 para configurar
a disponibilidade no nível de banco de dados e no nível de instância:

Os Grupos de Disponibilidade AlwaysOn, novidade no SQL Server 2012, aumentam
consideravelmente os recursos de espelhamento de banco de dados e ajudam a garantir
a disponibilidade de bancos de dados de aplicativos, além de permitir a perda de dados zero
por meio da movimentação de dados baseada em log para proteção de dados sem discos
compartilhados.
Os grupos de disponibilidade fornecem um conjunto integrado de opções, incluindo failover
automático e manual de um grupo lógico de bancos de dados, suporte para até quatro réplicas
secundárias, failover rápido de aplicativo e reparo automático de página.

As Instâncias de Cluster de Failover (FCIs) AlwaysOn aprimoram o recurso de clustering de failover
do SQL Server e dão suporte ao clustering multissite em sub-redes, permitindo o failover entre data
centers de instâncias do SQL Server. Um failover de instância mais rápido e mais previsível é outro
benefício fundamental que permite uma recuperação de aplicativo mais rápida.
Reduzir significativamente o tempo de inatividade planejado
O principal motivo para o tempo de inatividade do aplicativo em qualquer organização é o tempo de
inatividade planejado causado pela aplicação de patches no sistema operacional, pela manutenção de
hardware e assim por diante. Isso pode representar quase 80% das interrupções em um ambiente de TI.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
5
O SQL Server 2012 ajuda a reduzir significativamente o tempo de inatividade planejado ao reduzir os
requisitos de aplicação de patches e permitir mais operações de manutenção online:

Windows Server Core. O SQL Server 2012 dá suporte a implantações no Windows Server Core, uma
opção de implantação mínima simplificada para Windows Server 2008 e Windows Server 2008 R2.
Essa configuração do sistema operacional pode reduzir o tempo de inatividade planejado
minimizando os requisitos de aplicação de patches no sistema operacional em até 60%.

Operações online. O suporte avançado para operações online, como a reindexação de LOB
e a adição de colunas com valores padrão ajuda a reduzir o tempo de inatividade durante as
operações de manutenção de banco de dados.

Atualização e aplicação de patches sem interrupção. Os recursos AlwaysOn facilitam a distribuição
de atualizações e aplicação de patches de instâncias, o que ajuda a reduzir significativamente
o tempo de inatividade do aplicativo.

SQL Server no Hyper-v. As instâncias do SQL Server hospedadas no ambiente Hyper-v recebem
o benefício adicional da Migração ao Vivo, que permite migrar máquinas virtuais entre hosts com
tempo de inatividade zero. Os administradores podem executar operações de manutenção no host
sem afetar os aplicativos.
Eliminar o hardware ocioso e aumentar a relação custo-benefício e o desempenho
As soluções de alta disponibilidade típicas envolvem a implantação de servidores caros, redundantes
e passivos. Os Grupos de Disponibilidade AlwaysOn permitem utilizar réplicas de banco de dados
secundárias em servidores, de outra forma passivos ou ociosos, para cargas de trabalho somente leitura,
como consultas de relatórios do SQL Server Reporting Services ou operações de backup. A capacidade
de usar simultaneamente as réplicas de banco de dados primária e secundárias aumenta o desempenho
de todas as cargas de trabalho devido ao melhor equilíbrio de recursos de seus investimentos em
hardware de servidor.
Implantação e gerenciamento fáceis
Recursos como o Assistente de Configuração, o suporte à interface de linha de comando do Windows
PowerShell, painéis, DMVs (exibições de gerenciamento dinâmico), o gerenciamento baseado em
políticas e a ajuda de integração do System Center ajudam a simplificar a implantação e o gerenciamento de
grupos de disponibilidade.
Fazendo a comparação de recursos de RPO e RTO
As metas empresariais de RPO (objetivo de ponto de recuperação) e RTO (objetivo de tempo de
recuperação) devem ser os principais fatores na seleção de uma tecnologia do SQL Server para sua
solução de alta disponibilidade e recuperação de desastre. Esta tabela oferece uma comparação
aproximada do tipo de resultados que as diferentes soluções podem obter:
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
6
Potencial
perda de
dados
(RPO)
Potencial
tempo de
recuperação
(RTO)
Failover
automático
Secundárias
legíveis(1)
Grupo de Disponibilidade AlwaysOn - confirmação
síncrona
Zero
Segundos
Sim(4)
0-2
Grupo de Disponibilidade AlwaysOn - confirmação
assíncrona
Segundos
Minutos
Não
0-4
Instância de cluster de failover AlwaysOn
ND(5)
Sim
ND
Espelhamento de banco de dados(2) - Alta segurança
(assíncrona + testemunha)
Zero
Segundos
a minutos
Segundos
Sim
ND
Espelhamento de banco de dados(2) - Alto desempenho
(assíncrono)
Segundos(6)
Minutos(6)
Não
ND
Envio de logs
Minutos(6)
Minutos
a horas(6)
Não
Horas(6)
Horas
a dias(6)
Não
Não durante
uma
restauração
Não durante
uma
restauração
Alta disponibilidade e recuperação de
desastre Solução do SQL Server
Backup, cópia, restauração(3)
(1)
Um Grupo de Disponibilidade AlwaysOn não pode ter mais do que um total de quatro réplicas secundárias, independentemente do tipo.
(2) Este
recurso será removido em uma versão futura do Microsoft SQL Server. Use Grupos de Disponibilidade AlwaysOn em seu lugar.
(3) O recurso
de backup, cópia, restauração é apropriado para recuperação de desastre, mas não para alta disponibilidade.
(4)
O failover automático de um grupo de disponibilidade não tem suporte para ou de uma instância de cluster de failover.
(5)
A FCI em si não oferece proteção de dados; a perda de dados depende da implementação do sistema de armazenamento.
(6)
Altamente dependente da carga de trabalho, do volume de dados e dos procedimentos de failover.
Camadas de proteção do SQL Server AlwaysOn
As soluções SQL Server AlwaysOn ajudam a oferecer tolerância a falhas e recuperação de desastre
através de várias camadas lógicas e físicas de componentes de infraestrutura e de aplicativo.
Historicamente, tem sido uma prática comum ter uma separação de tarefas e responsabilidades entre os
vários públicos e funções envolvidos, de modo que cada um se preocupava predominantemente apenas
com uma parte dessas camadas de soluções.
Esta seção do documento é organizada para percorrer uma descrição mais profunda de cada uma dessas
camadas, além de oferecer a lógica e as diretrizes para suas discussões de design e decisões sobre
implementação.
Uma solução bem-sucedida do SQL Server AlwaysOn requer o conhecimento e a colaboração entre estas
camadas:

Nível de infraestrutura. A comunicação de rede intranó e a tolerância a falhas em nível de servidor
utiliza recursos do Windows Server Failover Clustering (WSFC) para o monitoramento de integridade
e a coordenação de failover.

Nível de instância do SQL Server. A Instância de Cluster de Failover (FCI) do SQL Server AlwaysOn
é uma instância do SQL Server que está instalada em nós do servidor e que pode fazer failover para
eles em um cluster do WSFC. Os nós que hospedam a FCI são anexados ao armazenamento
compartilhado simétrico avançado (SAN ou SMB).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
7

Nível de banco de dados. Um grupo de disponibilidade é um conjunto de bancos de dados de
usuário que fazem failover juntos. Um grupo de disponibilidade consiste em uma réplica primária
e de uma a quatro réplicas secundárias. Cada réplica é hospedada por uma instância do SQL Server
(FCI ou não FCI) em um nó diferente do cluster do WSFC.

Conectividade de cliente. Os aplicativos cliente de banco de dados podem conectar-se diretamente
a um nome de rede de instância do SQL Server ou a um VNN (nome de rede virtual) associado a um
ouvinte de grupo de disponibilidade. O VNN abstrai a topologia do cluster do WSFC e do grupo de
disponibilidade, redirecionando logicamente solicitações de conexão à instância do SQL Server e à
réplica de banco de dados apropriadas.
A topologia lógica de uma solução AlwaysOn representativa é ilustrada neste diagrama:
Infraestrutura de disponibilidade
Os Grupos de Disponibilidade AlwaysOn e as Instâncias de Cluster de Failover AlwaysOn utilizam
o sistema operacional Windows Server e o WSFC como uma tecnologia de plataforma. Mais do que
nunca, os administradores de bancos de dados do Microsoft SQL Server bem-sucedidos dependerão de
uma sólida compreensão dessas tecnologias.
Sistema operacional Windows
O SQL Server depende da plataforma Windows para fornecer a infraestrutura e os serviços básicos de
rede, armazenamento, segurança, aplicação de patch e monitoramento.
As diferentes edições do SQL Server 2012 progressivamente se baseiam na capacidade e nos recursos
cada vez maiores de edições semelhantes do sistema operacional Windows Server 2008 R2, incluindo os
sistemas operacionais Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise
e Windows Server 2008 R2 Datacenter.
Para saber mais, consulte: Requisitos de hardware e software para a instalação do SQL Server 2012
(http://msdn.microsoft.com/pt-br/library/ms143506(SQL.110).aspx).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
8
Opção de instalação do Windows Server Core
Como um recurso fundamental de alta disponibilidade, o SQL Server 2012 dá suporte à implantação da
opção de instalação Server Core no Windows Server 2008 ou versões posteriores. A opção de instalação
Server Core oferece um ambiente mínimo para a execução de funções específicas de servidor com
funcionalidade limitada e suporte muito limitado a aplicativos de GUI. Por padrão, somente os serviços
necessários e um ambiente de prompt de comando são habilitados.
Esse modo de operação reduz a superfície de ataque do sistema operacional e a sobrecarga do sistema,
além de poder reduzir significativamente os constantes requisitos de manutenção, serviços e aplicação
de patch.
Uma consideração fundamental para implantar o SQL Server 2012 no Windows Server Core é que
qualquer implantação, configuração, administração e manutenção do SQL Server e do sistema
operacional deverá ser feita por meio de um ambiente de scripts, como o Windows PowerShell, ou com
o uso de ferramentas de linha de comando ou remotas.
Otimizando o SQL Server para a Nuvem Privada
Os cenários de alta disponibilidade e recuperação de desastre são cada vez mais importantes no
ambiente de Nuvem Privada. Implante o SQL Server em sua Nuvem Privada para ajudar a garantir que
seus recursos de computador, rede e armazenamento sejam usados com eficiência, reduzindo
a superfície física e as despesas de capital e operacionais. Isso ajuda você a consolidar implantações,
dimensionar seus recursos com eficiência e implantar recursos sob demanda sem comprometer
o controle.
Além do suporte do Windows Server Failover Clustering a sistemas Hyper-v e convidados, o SQL Server
também oferece suporte à Migração ao Vivo, que é a capacidade de mover máquinas virtuais entre
hosts sem um tempo de inatividade perceptível. A Migração ao Vivo também funciona em conjunto com
o clustering convidado.
Para saber mais, consulte Computação em Nuvem Privada - otimizando o SQL Server para a Nuvem
Privada (http://www.microsoft.com/SqlServerPrivateCloud).
Windows Server Failover Clustering
O WSFC (Windows Server Failover Clustering) fornece recursos de infraestrutura que dão suporte aos
cenários de alta disponibilidade e recuperação de desastre dos aplicativos de servidor hospedados,
como o Microsoft SQL Server.
Se houver falha em um nó de cluster ou serviço do WSFC, os serviços ou recursos que foram
hospedados nesse nó poderão ser transferidos de forma automática ou manual para outro nó disponível
em um processo conhecido como failover. Com as soluções AlwaysOn, esse processo se aplica às FCIs
e aos grupos de disponibilidade.
Os nós do cluster do WSFC funcionam em conjunto para fornecer coletivamente estes tipos de recursos:

Metadados distribuídos e notificações. O serviço WSFC e os metadados de aplicativos hospedados
são mantidos em cada nó do cluster. Esses metadados incluem a configuração e o status do WSFC,
além de configurações de aplicativos hospedados. As alterações nos metadados ou no status em um
nó são propagadas automaticamente para os outros nós do cluster.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
9

Gerenciamento de recursos. Os nós individuais do cluster podem fornecer recursos físicos, como
DAS (armazenamento diretamente conectado), interfaces de rede e acesso a armazenamento em
disco compartilhado. Os aplicativos hospedados, como o SQL Server, registram-se como um recurso
de cluster e podem configurar dependências de inicialização e integridade em outros recursos.

Monitoramento de integridade. A detecção de integridade de nó primário e entre nós é realizada por
meio de uma combinação de comunicações de rede de pulsação e monitoramento de recursos.
A integridade geral do cluster é determinada pelos votos de um quorum de nós no cluster.

Coordenação de failover. Cada recurso é configurado para ser hospedado em um nó primário,
e cada um deles pode ser transferido automática ou manualmente para um ou mais nós secundários.
Uma política de failover baseado em integridade controla a transferência automática de
propriedade de recurso entre nós. Os nós e os aplicativos hospedados são notificados quando
ocorre um failover para que possam reagir da maneira adequada.
Para saber mais, consulte Windows Server | Balanceamento de nós e clustering de failover
(http://www.microsoft.com/windowsserver2008/en/us/failover-clustering-main.aspx).
Observação: agora é extremamente importante que os administradores de banco de dados
compreendam os trabalhos internos de gerenciamento de quorum e clusters do WSFC.
O monitoramento de integridade AlwaysOn e as etapas de recuperação de falhas estão todos
intrinsecamente associados à configuração do WSFC.
Configurações de armazenamento do WSFC
O Windows Server Failover Clustering baseia-se em cada nó do cluster para gerenciar os dispositivos de
armazenamento, os volumes de disco e o sistema de arquivos conectados. O WSFC presume que
o subsistema de armazenamento seja extremamente robusto e, portanto, se o dispositivo de
armazenamento anexado a um nó estiver indisponível, o nó de cluster estará supostamente
apresentando falha.
Para operações baseadas em gravação, um volume de disco é logicamente anexado a um único nó de
cluster de cada vez usando uma reserva persistente SCSI-3. Dependendo dos recursos e da configuração
do subsistema de armazenamento, se um nó falhar, a propriedade lógica do volume de disco poderá ser
transferida para outro nó no cluster.
As soluções SQL Server AlwaysOn utilizam e são restritas a determinadas combinações de configuração de
armazenamento do WSFC, que incluem:

Conectado diretamente versus remoto. Os dispositivos de armazenamento são conectados
fisicamente de forma direta ao servidor, ou são apresentados por um dispositivo remoto através de
uma rede ou um adaptador de barramento de host (HBA). As tecnologias de armazenamento
remoto incluem soluções baseadas em Rede de Área de Armazenamento (SAN), como iSCSI e Fibre
Channel, bem como soluções baseadas em compartilhamento de arquivos de Bloco de Mensagens
de Servidor (SMB).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
10

Simétrico versus assimétrico. Os dispositivos de armazenamento serão considerados simétricos se
for apresentada exatamente a mesma configuração de volume de disco lógico e caminhos de
arquivo para cada nó do cluster. A implementação e a capacidade físicas dos volumes de disco
subjacentes podem variar.

Dedicado versus compartilhado. O armazenamento dedicado é reservado para uso e atribuído a um
único nó do cluster. O armazenamento compartilhado é acessível a vários nós do cluster. O controle
e a propriedade de dispositivos de armazenamento compartilhado compatíveis podem ser transferidos
de um nó para outro por meio de protocolos SCSI-3. O WSFC dá suporte à hospedagem de vários
nós simultâneos de volumes compartilhados de cluster para fins de compartilhamento de arquivos.
Entretanto, o SQL Server não dá suporte ao acesso de vários nós simultâneos a um volume compartilhado.
Observação: as FCIs do SQL Server ainda exigem que o armazenamento compartilhado simétrico esteja
acessível a todos os possíveis proprietários de nós da instância. No entanto, com a introdução de Grupos
de Disponibilidade AlwaysOn, agora você pode implantar instâncias não FCI diferentes do SQL Server em
um cluster do WSFC, cada um com seu próprio armazenamento exclusivo, dedicado, local ou remoto.
Failover e detecção de integridade de recursos do WSFC
Cada recurso em um nó de cluster do WSFC pode relatar seu status e integridade, periodicamente ou
sob demanda. Uma variedade de circunstâncias pode indicar uma falha de recurso de cluster, incluindo:
queda de energia, erros de disco ou de memória, erros de comunicação de rede, erros de configuração
ou serviços sem resposta.
Você pode tornar recursos de cluster do WSFC, como redes, armazenamento ou serviços, dependentes
uns dos outros. A integridade cumulativa de um recurso é determinada pelo rollup sucessivo de sua
integridade com a integridade de cada uma de suas dependências de recursos.
Para Grupos de Disponibilidade AlwaysOn, o grupo de disponibilidade e o ouvinte de grupo de
disponibilidade são registrados como recursos de cluster do WSFC. Para Instâncias de Cluster de Failover
AlwaysOn, os serviços do SQL Server e do SQL Server Agent são registrados como recursos de cluster do
WSFC, e ambos se tornam dependentes do recurso de nome de rede virtual da instância.
Se um recurso de cluster do WSFC tiver um número definido de erros ou de falhas durante um período,
a política de failover fará com que o serviço de cluster execute uma das seguinte ações:



Reiniciar o recurso no nó atual.
Definir o recurso como offline.
Iniciar um failover automático do recurso e de suas dependências para outro nó.
Observação: a detecção de integridade de recurso de cluster do WSFC não tem nenhum impacto direto
na integridade do nó individual ou na integridade geral do cluster.
Assistente de validação de cluster do WSFC
O assistente de validação de cluster é um recurso que está integrado ao clustering de failover no
Windows Server 2008 e no Windows Server 2008 R2. É uma ferramenta-chave para ajudar um
administrador de banco de dados a assegurar que haja um ambiente de WSFC limpo, íntegro e estável
antes da implantação de uma solução SQL Server AlwaysOn.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
11
Com o assistente de validação de cluster, você pode executar um conjunto de testes concentrados em
uma coleção de servidores que você pretende usar como nós em um cluster ou em um cluster existente.
Esse processo testa o hardware e o software subjacentes de forma direta, e individual, para obter uma
avaliação precisa de como seria o suporte a um cluster do WSFC em uma determinada configuração.
Esse processo de validação consiste em uma série de testes e de coleta de dados em cada nó nestas
categorias:

Estoque. Informações sobre versões de BIOS, níveis de ambiente, adaptadores de barramento de
host, RAM, versões de sistema operacional, dispositivos, serviços, drivers etc.

Rede. Informações sobre a ordem de associação de NICs, comunicações de rede, configuração IP
e configuração de firewall. Valida comunicações entre nós em todos as NICs.

Armazenamento. Informações sobre discos, capacidade de unidade, latência de acesso, sistemas de
arquivos etc. Valida comandos de SCSI, funcionalidade de failover do disco e a configuração de
armazenamento simétrico ou assimétrico.

Configuração do sistema. Valida a configuração do Active Directory, que os drivers são assinados,
configurações de despejo de memória, recursos e serviços necessários do sistema operacional,
arquitetura de processador compatível e níveis de service pack e de Atualização de Software
do Windows.
Os resultados desses testes de validação fornecem as informações necessárias para você ajustar uma
configuração de cluster, controlar a configuração e identificar potenciais problemas de configuração de
cluster antes que eles causem tempo de inatividade. Você pode salvar um relatório dos resultados dos
testes em um documento HTML para referência posterior.
É necessário executar esses testes antes e depois de fazer qualquer alteração na configuração do WSFC,
antes de instalar o SQL Server e como parte de qualquer processo de recuperação de desastre. Um
relatório de validação de cluster é exigido pelos Serviços de Atendimento ao Cliente da Microsoft (CSS)
como uma condição para que a Microsoft ofereça suporte a uma determinada configuração de cluster
do WSFC.
Para saber mais, consulte Guia passo a passo de cluster de failover: validando o hardware para um
cluster de failover (http://technet.microsoft.com/pt-br/library/cc732035(WS.10).aspx).
Observação: se a sua configuração de cluster tiver armazenamento assimétrico, como é o caso de
soluções de armazenamento de clustering geográfico baseadas em hardware, ou pode ser o caso de
Grupos de Disponibilidade AlwaysOn, você talvez precise aplicar alguns hotfixes para impedir a falha do
assistente de validação de cluster nas etapas de validação de armazenamento.
Para saber mais, consulte Pré-requisitos, restrições e recomendações para Grupos de Disponibilidade
AlwaysOn (http://msdn.microsoft.com/pt-br/library/ff878487(SQL.110).aspx#SystemReqsForAOAG).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
12
Modos de quorum do WSFC e configuração de votação
O WSFC usa uma abordagem baseada em quorum para monitorar a integridade geral do cluster
e maximizar a tolerância a falhas em nível de nó. Uma compreensão básica dos modos de quorum do
WSFC e da configuração de votação de nó é muito importantes para o design, a operação e a solução de
problemas de sua solução de alta disponibilidade e recuperação de desastre AlwaysOn.
Detecção de integridade de cluster por quorum
Cada nó em um cluster do WSFC participa da comunicação de pulsação periódica para compartilhar
o status de integridade do nó com os outros nós. Nós sem resposta são considerados como em estado
com falha.
Um conjunto de nós de quorum é uma maioria dos nós de votação e testemunhas no cluster WSFC.
A integridade e o status gerais de um cluster do WSFC são determinados por um voto de quorum
periódico. A presença de um quorum significa que o cluster está íntegro o suficiente para fornecer
tolerância a falhas em nível de nó.
A ausência de um quorum indica que o cluster não está íntegro. A integridade de cluster do WSFC em
geral deve ser mantida para assegurar que nós secundários íntegros estejam disponíveis para o failover
de nós primários. Se o voto de quorum falhar, todo o cluster do WSFC será definido como offline por
precaução. Isso também fará com que todas as instâncias do SQL Server registradas com o cluster sejam
interrompidas.
Observação: se um cluster do WSFC for definido como offline devido a uma falha de quorum,
a intervenção manual será necessária para colocá-lo online novamente. Para saber mais, consulte
a seção Recuperação de desastre do WSFC por meio de quorum forçado, mais adiante neste documento.
Modos de quorum
Um modo de quorum é configurado no nível do cluster do WSFC para especificar a metodologia usada
para votação de quorum. O utilitário Gerenciador de Cluster de Failover recomenda um modo de
quorum baseado no número de nós do cluster.
Um dos seguintes modos de quorum determina o que constitui um quorum de votos:

Maioria de Nós. Mais da metade dos nós votantes no cluster precisam votar afirmativamente para
o cluster ser íntegro.

Maioria de Nós e Compartilhamentos de Arquivos. Semelhante ao modo de quorum Maioria de
Nós, exceto pelo fato de um compartilhamento de arquivo remoto também ser configurado como
uma testemunha de votação e a conectividade de qualquer nó com esse compartilhamento também
ser contada como um voto afirmativo. Mais da metade dos votos possíveis deve ser afirmativa para
que o cluster esteja íntegro.
Como uma prática recomendada, o compartilhamento de arquivo de testemunha não deve residir
em nenhum nó no cluster e deve estar visível para todos os nós no cluster.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
13

Maioria de nós e discos. Semelhante ao modo de quorum Maioria de Nós, exceto pelo fato de um
recurso de cluster de disco compartilhado também ser designado como uma testemunha de
votação e a conectividade de qualquer nó com esse disco compartilhado também ser contada como
um voto afirmativo. Mais da metade dos votos possíveis deve ser afirmativa para que o cluster
esteja íntegro.

Somente Disco. Um recurso de cluster de disco compartilhado é designado como uma testemunha, e a
conectividade por qualquer nó com esse disco compartilhado é contada como um voto afirmativo.
Para saber mais, consulte Guia passo a passo de cluster de failover: configurando o quorum em um
cluster de failover (http://technet.microsoft.com/pt-br/library/cc770620(WS.10).aspx).
Observação: a menos que cada nó do cluster esteja configurado para usar o mesmo disco testemunha
de quorum de armazenamento compartilhado, você deverá usar o modo de quorum Maioria de Nós se
tiver um número ímpar de nós votantes, ou o modo de quorum Maioria dos Nós e Compartilhamentos
de Arquivos quando houver um número par de nós votantes.
Nós votantes e não votantes
Por padrão, cada nó do cluster do WSFC é incluído como membro do quorum de cluster; cada nó,
testemunha de compartilhamento de arquivos e testemunha de disco tem um único voto na
determinação da integridade de cluster geral. A discussão de quorum até este ponto do documento
qualificou cuidadosamente o conjunto de nós de cluster do WSFC que votam na integridade do cluster
como nós votantes. Em algumas circunstâncias, talvez você não queira que cada nó tenha um voto.
Cada nó em um cluster do WSFC tentará continuamente estabelecer um quorum. Nenhum nó individual
no cluster pode determinar definitivamente se o cluster como um todo é íntegro ou não íntegro.
A qualquer momento, da perspectiva de cada nó, alguns dos outros nós podem aparecer offline ou
talvez pareça que estão em processo de failover ou não respondentes devido a uma falha de
comunicação de rede. Uma função-chave do voto de quorum é determinar se o estado aparente de
cada nó do cluster do WSFC é de fato o estado real desses nós.
Para todos os modelos de quorum, exceto Somente Disco, a eficácia de um voto de quorum depende de
comunicações confiáveis entre todos os nós votantes no cluster. Você deverá confiar no voto de quorum
quando todos os nós estiverem na mesma sub-rede física.
No entanto, se um nó em outra sub-rede não estiver respondendo em um voto de quorum, mas estiver
realmente online e aparentemente íntegro, a causa mais provável será uma falha de comunicação de
rede entre sub-redes. Dependendo da topologia de cluster, do modo de quorum e da configuração da
política de failover, essa falha de comunicação de rede pode criar efetivamente mais de um conjunto
(ou subconjunto) de nós votantes.
Se mais de um subconjunto de nós votantes for capaz de estabelecer um quorum próprio, isso será
conhecido como cenário split-brain (partição de rede). Nesse cenário, os nós de quorums separados
podem se comportar de modo diferente e conflitante.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
14
Observação: o cenário split-brain só será possível se um administrador do sistema executar
manualmente uma operação de quorum forçado ou, em circunstâncias muito raras, um failover manual
forçado, subdividindo explicitamente o conjunto de nós do quorum. Para saber mais, consulte a seção
Recuperação de desastre do WSFC por meio de quorum forçado, mais adiante neste documento.
Para simplificar sua configuração de quorum e aumentar o tempo de atividade, talvez você queira
ajustar a configuração NodeWeight (um valor 0 ou 1) de cada nó, para que o voto do nó não seja
computado no quorum.
Ajustes recomendados na votação de quorum
Para determinar a configuração de votação de quorum recomendada para o cluster, aplique estas
diretrizes, em ordem sequencial:
1. Nenhum voto por padrão. Suponha que cada nó não deva votar sem uma justificativa explícita.
2. Inclua todos os nós primários. Cada nó que hospeda uma réplica primária do Grupo de
Disponibilidade AlwaysOn ou é o proprietário preferencial da Instância de Cluster de Failover
AlwaysOn deve ter um voto.
3. Inclua possíveis proprietários de failover automático. Cada nó que pode hospedar uma réplica
primária ou FCI, em virtude de um failover automático, deve ter um vote.
4. Exclua nós de site secundários. Em geral, não dê votos a nós que residem em um site de
recuperação de desastre secundário. Você não deseja que os nós no site secundário colaborem para
uma decisão de colocar o cluster offline quando não houver nada errado com o site primário.
5. Número ímpar de votos. Se necessário, adicione uma testemunha compartilhamento de arquivos, um
nó testemunha (com ou sem uma instância do SQL Server) ou um disco testemunha ao cluster
e ajuste o modo de quorum para prevenir possíveis empates no voto de quorum.
6. Reavalie atribuições de voto pós-failover. Você não deseja o failover em uma configuração de
cluster sem suporte para um quorum íntegro.
Para saber mais sobre como ajustar votos de nós, consulte Definir configurações de NodeWeight de
quorum de cluster (http://msdn.microsoft.com/pt-br/library/hh270281(SQL.110).aspx).
Você não pode ajustar o voto de uma testemunha de compartilhamento de arquivos. Em vez disso, você
deve selecionar um modo diferente de quorum para incluir ou excluir o voto.
Observação: o SQL Server expõe várias DMVs (exibições de gerenciamento dinâmico) do sistema que
podem ajudar você a administrar definições relacionadas à configuração de cluster do WSFC e à votação
de quorum do nó.
Para saber mais, consulte Monitorar grupos de disponibilidade (http://msdn.microsoft.com/ptbr/library/ff878305(SQL.110).aspx).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
15
Recuperação de desastre do WSFC por meio de quorum forçado
A falha de quorum normalmente é causada por um desastre sistêmico ou uma falha de comunicação
persistente envolvendo vários nós do cluster do WSFC. Lembre-se de que a falha de quorum deixa
offline todos os serviços clusterizados, instâncias do SQL Server e Grupos de Disponibilidade no cluster
do WSFC, pois o cluster não pode garantir a tolerância a falhas no nível de nó. Uma falha de quorum
significa que os nós votantes íntegros no cluster do WSFC não atendem mais ao modelo de quorum.
Alguns nós podem ter falhado totalmente e outros podem ter apenas desligado o serviço WSFC e, nesse
caso, são íntegros, exceto pela perda da capacidade de comunicação com um quorum.
Para colocar o cluster do WSFC online, corrija a causa raiz da falha de quorum em pelo menos um nó da
configuração existente. Em um cenário de desastre, você pode precisar reconfigurar ou identificar
o hardware alternativo a ser usado. Você talvez ainda queira reconfigurar os nós restantes no cluster do
WSFC para também refletir a topologia de cluster de sobrevivência.
Você pode usar o procedimento quorum forçado em um nó de cluster do WSFC para substituir
o controle de segurança que colocou o cluster offline. Isso indica efetivamente ao cluster que deve
suspender as verificações de votação de quorum e permite que você coloque os recursos de cluster
WSFC e SQL Server novamente online, em quaisquer nós no cluster.
Esse tipo de processo de recuperação de desastre deve incluir as seguintes etapas:
1) Determine o escopo da falha. Identifique quais grupos de disponibilidade ou instâncias do SQL
Server estão sem resposta e quais nós de cluster estão online e disponíveis para uso pós-desastre,
e examine os logs de eventos do Windows e os logs do sistema SQL Server. Quando for prático, você
deve preservar dados forenses e os logs do sistema para análise futura.
2) Inicie o cluster do WSFC usando o quorum forçado em um único nó. Em um nó íntegro, force
manualmente o cluster a ficar online usando o procedimento de quorum forçado. Para minimizar
a potencial perda de dados, selecione um nó recém-hospedado em uma réplica primária de grupo
de disponibilidade.
Para saber mais, consulte Forçar um cluster do WSFC a iniciar sem um quorum
(http://msdn.microsoft.com/pt-br/library/hh270275(v=SQL.110).aspx).
Observação: se você usar a configuração de quorum forçado, as verificações de quorum serão
bloqueadas em todo o cluster, até que o cluster do WSFC alcance uma maioria de votos e passe
automaticamente para um modo de operação de quorum normal.
3) Inicie normalmente o serviço WSFC em cada nó íntegro, um de cada vez. Você não precisará
especificar a opção de quorum forçado quando iniciar o serviço de cluster nos outros nós.
Como o serviço WSFC em cada nó volta a ficar online, ele negocia com os outros nós íntegros para
sincronizar o novo estado de configuração do cluster. Lembre-se de fazer isso em um nó de cada
vez, para evitar situações de potencial competição na resolução do último estado conhecido do
cluster.
Observação: verifique se cada nó iniciado pode se comunicar com os outros nós colocados online
recentemente, ou você correrá o risco de criar mais de um conjunto de nós de quorum; esse é um
cenário split-brain. Se seus resultados na etapa 1 forem precisos, isso não deverá ocorrer.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
16
4) Aplique o novo modo de quorum e a configuração de voto de nó. Se você reiniciou com êxito todos
os nós do cluster usando o procedimento de quorum forçado, e corrigiu a causa raiz da falha de
quorum, não precisará fazer alterações no modo de quorum original e na configuração de voto de nó.
Caso contrário, você deve avaliar o nó de cluster recém-recuperado e a topologia de réplica de
disponibilidade, e alterar o modo de quorum e as atribuições de voto para cada nó conforme
apropriado. Defina o serviço de cluster do WSFC em nós offline não recuperados ou defina os votos
de nós como zero.
Observação: neste momento, os nós e as instâncias do SQL Server no cluster podem parecer
restaurados à operação normal. Entretanto, talvez ainda não exista um quorum íntegro. Usando
o Gerenciador de Cluster de Failover, o Painel AlwaysOn no SQL Server Management Studio ou as
DMVs apropriadas, verifique se um quorum íntegro foi restaurado.
5) Recupere réplicas de banco de dados de grupo de disponibilidade, conforme necessário. Alguns
bancos de dados podem ser recuperados e voltar a ficar online por conta própria como parte do
processo normal de inicialização do SQL Server. A recuperação de outros bancos de dados pode
exigir etapas manuais adicionais.
Você pode minimizar a potencial perda de dados e o tempo de recuperação para as réplicas do
grupo de disponibilidade colocando-os novamente online nesta sequência, se possível: réplica
primária, réplicas secundárias síncronas, réplicas secundárias assíncronas.
6) Repare ou substitua componentes com falha e revalide o cluster. Agora que você se recuperou do
desastre inicial e da falha de quorum, deve reparar ou substituir os nós com falhas e ajustar as
configurações do WSFC e do AlwaysOn relacionadas adequadamente. Isso pode incluir remover
réplicas do grupo de disponibilidade, remover nós do cluster ou nivelar e reinstalar o software em
um nó.
Observação: você deve reparar ou remover todas as réplicas de disponibilidade com falha. O SQL
Server 2012 não truncará o log de transações após o último ponto conhecido da réplica de
disponibilidade mais afastada. Se uma réplica com falha não for reparada ou removida do grupo de
disponibilidade, os logs de transações aumentarão e você correrá o risco de ficar sem espaço para
log nas outras réplicas.
7) Repita a etapa 4 conforme necessário. A meta é restabelecer o nível apropriado de tolerância
a falhas e alta disponibilidade para operações íntegras.
8) Conduza a análise de RPO/RTO. Você deve analisar logs do sistema SQL Server, carimbos de
data/hora de banco de dados e logs de eventos do Windows para determinar a causa-raiz da falha
e documentar as experiências reais de Ponto de Recuperação e de Tempo de Recuperação.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
17
Proteção em nível de instância do SQL Server
A próxima camada de proteção em uma solução AlwaysOn é a própria plataforma de dados; esses são
os recursos oferecidos pelo Microsoft SQL Server 2012 e por sua integração com componentes de
infraestrutura do Windows Server.
Aperfeiçoamentos de disponibilidade – instâncias do SQL Server
Estes são os novos recursos em nível de instância do SQL Server 2012 que aprimoram a disponibilidade
para ambas as Instâncias de Cluster de Failover AlwaysOn, bem como para instâncias autônomas que
hospedam os Grupos de Disponibilidade AlwaysOn.
Estes aperfeiçoamentos representam melhorias em termos de gerenciamento e solução de problemas
de cenários de failover:

Política de failover flexível. A saída do novo procedimento armazenado do sistema usado para
a detecção robusta de falhas, sp_server_diagnostics, usa a propriedade FailureConditionLevel para
expressar a severidade de uma falha que afeta a instância do SQL Server. Uma política de failover do
WSFC controla como esse valor afeta a instância do SQL Server; variando da relativa tolerância
a erros até a sensibilidade a qualquer erro de componentes internos do SQL Server.
Você pode configurar o failover para ser disparado por qualquer um de uma série de níveis de erros,
incluindo: servidor inativo, servidor sem resposta, erro crítico, erro moderado e qualquer erro
qualificado. A propriedade FailureConditionLevel pode ser usada para FCI ou políticas de failover de
grupo de disponibilidade.
Antes do SQL Server 2012, não havia granularidade das condições de erro para controlar o failover;
qualquer falha em nível de serviço causava o failover.
Para saber mais, consulte Política de failover para instâncias de cluster de failover
(http://msdn.microsoft.com/pt-br/library/ff878664(SQL.110).aspx).

Instrumentação e logs avançados. Há várias exibições de configuração do sistema, DMVs,
contadores de desempenho e uma sessão de integridade de eventos estendidos específicos ao
AlwaysOn que capturam e despejam as informações necessárias para solucionar problemas,
monitorar e ajustar sua implantação AlwaysOn. Várias delas são expostas por meio de novas facetas
e políticas do Gerenciamento de Políticas do SQL Server.
Para saber mais, consulte Funções e exibições de gerenciamento dinâmico de Grupos de
Disponibilidade AlwaysOn (http://msdn.microsoft.com/pt-br/library/ff877943(SQL.110).aspx),
e sys.dm_os_cluster_nodes (http://msdn.microsoft.com/pt-br/library/ms187341(SQL.110).aspx).

Suporte ao compartilhamento de arquivos SMB. Você pode colocar arquivos de banco de dados
em um compartilhamento de arquivos remoto do Windows Server 2008, ou versões posteriores,
para instâncias de cluster de failover e autônomas, anulando a necessidade de uma letra de unidade
separada por FCI. Essa é uma boa opção para a consolidação do armazenamento ou para hospedar
o armazenamento de arquivos de banco de dados em um servidor físico para um sistema
operacional convidado de máquina virtual. Com a configuração certa, o desempenho de E/S pode
ser muito próximo do desempenho de um armazenamento diretamente conectado.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
18
Para saber mais, consulte Bancos de dados SQL em compartilhamentos de arquivos - é hora de
reconsiderar o cenário (http://blogs.msdn.com/b/sqlserverstorageengine/archive/2011/10/18/ sqldatabases-on-file-shares-it-s-time-to-reconsider-the-scenario.aspx).
Observação: em um cluster do WSFC, você não pode adicionar uma dependência de recursos de
compartilhamento de arquivos SMB ao grupo de recursos do SQL Server; você deve tomar medidas
separadas para garantir a disponibilidade do compartilhamento de arquivos. Se o compartilhamento de
arquivos ficar indisponível, o SQL Server lançará uma exceção de E/S e ficará offline.

Interoperabilidade do WSFC com o DNS. O VNN (nome de rede virtual) para uma FCI ou um ouvinte
de grupo de disponibilidade só será registrado no DNS durante a criação do VNN ou durante
alterações de configuração. Todos os endereços IP virtuais, independentemente do estado online ou
offline, são registrados no DNS com o mesmo nome de rede virtual. As chamadas de cliente para
resolver o nome de rede virtual no DNS retornam todos os endereços IP registrados em uma
sequência round-robin variável.
Instâncias de Cluster de Failover AlwaysOn
O objetivo principal de uma FCI (Instância de Cluster de Failover) do SQL Server AlwaysOn é aprimorar
a disponibilidade de uma instância do SQL Server hospedada em servidor local e do hardware de
armazenamento dentro de um único data center.
Uma FCI é única instância lógica do SQL Server instalada em nós de um cluster do WSFC (Windows
Server Failover Clustering), mas que fica ativa em um nó de cada vez. Os aplicativos cliente se conectam a um
nome de rede virtual e a um endereço IP virtual que pertencem ao nó de cluster ativo.
Cada nó instalado tem uma configuração e um conjunto de binários do SQL Server idênticos. O serviço
de cluster do WSFC também replica as alterações relevantes das entradas da instância ativa no Registro
do Windows para cada nó instalado. Cada nó em que a FCI está instalada é designado como um possível
proprietário da instância e de seus recursos, dentro de uma sequência preferencial de failover.
Os arquivos de banco de dados são armazenados em volumes de armazenamento simétricos
compartilhados, são registrados como um recurso no cluster do WSFC e pertencem ao nó que
atualmente hospeda a FCI.
Para saber mais, consulte Instâncias de Cluster de Failover AlwaysOn (http://msdn.microsoft.com/ptbr/library/ms189134(SQL.110).aspx).
Processo de failover da FCI
Quando um recurso de cluster dependente falha, uma Instância de Cluster de Failover AlwaysOn
interage com o serviço de cluster do WSFC usando este processo de alto nível para fazer um failover:
1) Uma reinicialização é indicada. Uma verificação periódica da configuração de Políticas de Failover
do WSFC ou do SQL Server indica um estado de falha. Por padrão, é feita uma tentativa de reiniciar
o serviço antes que seja iniciado um failover para outro nó. Um tempo limite na tentativa de
reinicialização indica uma falha de recurso.
2) Um failover é indicado. Uma verificação de Política de Failover indica a necessidade de um failover
de nó.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
19
3) O serviço do SQL Server é interrompido. Se estiver em execução, será feita uma tentativa de
desligamento ordenado do serviço SQL Server.
4) O recurso de cluster do WSFC é transferido. A propriedade do grupo de recursos de cluster do SQL
Server e seus recursos de armazenamento compartilhados e em rede dependentes são transferidos
para o próximo proprietário de nó preferencial da FCI.
5) O SQL Server é iniciado no novo nó. A instância do SQL Server examina seus procedimentos comuns
de inicialização. Se ela não voltar a ficar online dentro de um período de tempo limite pendente,
o serviço de cluster colocará o recurso nesse novo nó em um estado de falha.
6) Os bancos de dados de usuários são recuperados no novo nó. Cada banco de dados de usuário
é colocado no modo de recuperação enquanto as operações de restauração do log de transações
são aplicadas e as transações não confirmadas são revertidas.
Aperfeiçoamentos de FCI
As versões anteriores do SQL Server ofereciam uma opção de instalação de FCI; entretanto, vários
aperfeiçoamentos de recursos no SQL Server 2012 melhoram a robustez e a facilidade de manutenção
da disponibilidade:

Clustering de várias sub-redes O SQL Server 2012 dá suporte aos nós de cluster do WSFC que
residem em mais de uma sub-rede. Uma determinada instância do SQL Server que reside em um nó
de cluster do WSFC poderá ser iniciada se qualquer interface de rede estiver disponível; isso
é conhecido como uma dependência de recurso de cluster ‘OR’.
As versões anteriores do SQL Server exigiam que todas as interfaces de rede estivessem funcionais
para iniciar ou fazer failover do serviço do SQL Server, e que todas estivessem na mesma sub-rede
ou VLAN.
Observação: a replicação em nível de armazenamento entre nós de cluster não é implicitamente
habilitada com o clustering de várias redes. Sua solução FCI de várias sub-redes deve usar uma
solução baseada em SAN de terceiros para replicar dados e coordenar o failover de armazenamento
entre nós de cluster.
Para saber mais, consulte SQL Server 2012 AlwaysOn: Instância de Cluster de Failover Multissite
(http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_multisite-failover-cluster-instance.aspx).

Detecção robusta de falhas. O serviço de cluster do WSFC mantém uma conexão administrativa
dedicada com cada FCI do SQL Server 2012 no nó. Nessa conexão, uma chamada periódica a um
procedimento armazenado especial do sistema, sp_server_diagnostics, retorna uma matriz
sofisticada de informações de diagnóstico de integridade do sistema.
Antes do SQL Server 2012, o mecanismo primário de detecção de integridade para uma FCI era
implementado como um processo de sondagem unidirecional simples. Nesse processo, o serviço de
cluster do WSFC criava periodicamente uma nova conexão de cliente SQL com a instância,
consultava o nome do servidor e, em seguida, desconectava. Uma falha ao conectar, ou um tempo
limite de consulta, por qualquer motivo, disparava um failover com muito poucas informações de
diagnóstico disponíveis.
Para saber mais, consulte sql_server_diagnostics (http://msdn.microsoft.com/pt-br/
library/ff878233(SQL.110).aspx).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
20
Agora há um suporte mais amplo para cenários de armazenamento de FCI:

Melhor suporte de ponto de montagem. A instalação do SQL Server agora reconhece configurações do
ponto de montagem de disco de cluster. Os discos de cluster especificados e todos os discos
montados nele são automaticamente adicionados à dependência de recurso do SQL Server durante
a instalação.

tempdb no armazenamento local. As FCIs agora dão suporte ao posicionamento do tempdb em
armazenamento não compartilhado local, como uma unidade de estado sólido local,
potencialmente descarregando uma quantidade significativa de E/S de uma SAN compartilhada.
Antes do SQL Server 2012, as FCIs exigiam que o tempdb estivesse localizado em um volume de
armazenamento compartilhado simétrico que fazia failover com outros bancos de dados do sistema.
Observação: a localização do tempdb é armazenada no banco de dados master, que se move entre
nós durante o failover. Ele deve estar em um caminho de arquivo simétrico válido (unidade, pastas
e permissões) em todos os possíveis proprietários de nós, senão o serviço SQL Server não será
iniciado em alguns nós.
Disponibilidade do banco de dados
Os recursos de alta disponibilidade oferecidos pelos componentes de infraestrutura e em nível de
instância do SQL Server trabalham em conjunto para proteger implicitamente os bancos de dados
hospedados. Uma solução AlwaysOn oferece um conjunto adicional de opções para a proteção explícita
de dados de bancos de dados e aplicativos da camada de dados.
Grupos de Disponibilidade AlwaysOn
Um grupo de disponibilidade é um conjunto de bancos de dados de usuários que fazem failover juntos
de uma instância do SQL Server para outra no mesmo cluster do WSFC. Os aplicativos cliente podem se
conectar aos bancos de dados do grupo de disponibilidade por meio de um nome de rede virtual do
WSFC, conhecido como um ouvinte de grupo de disponibilidade, que abstrai as instâncias subjacentes do
SQL Server.
Os Grupos de Disponibilidade AlwaysOn dependem do Windows Server Failover Clustering para
monitoramento de integridade, coordenação de failover e conectividade de servidor. Você deve
habilitar o suporte a AlwaysOn em uma instância do SQL Server que reside em um nó de cluster do
WSFC. Porém, essa instância não precisa ser uma FCI e não requer o uso de armazenamento
compartilhado simétrico.
Para saber mais, consulte Visão geral de Grupos de Disponibilidade AlwaysOn
(http://msdn.microsoft.com/pt-br/library/ff877884(SQL.110).aspx).
Réplicas e funções de disponibilidade
Cada instância do SQL Server no grupo de disponibilidade hospeda uma réplica de disponibilidade que
contém uma cópia dos bancos de dados de usuários no grupo de disponibilidade. Uma instância do SQL
Server pode hospedar apenas uma réplica de disponibilidade de um determinado grupo de
disponibilidade, mas vários grupos de disponibilidade podem residir na mesma instância. A instância do
SQL Server deve ter volumes de armazenamento (não compartilhados) dedicados.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
21
Uma das réplicas de disponibilidade funciona como réplica primária. Ela é designada como a cópia
mestre dos bancos de dados do grupo de disponibilidade e habilitada para operações de
leitura/gravação.
Um grupo de disponibilidade pode conter de uma a quatro réplicas de disponibilidade somente leitura
adicionais, e cada uma funciona separadamente como uma réplica secundária.
Sincronização de réplicas de disponibilidade
O conteúdo de cada banco de dados em um grupo de disponibilidade é sincronizado da réplica primária
para cada uma das réplicas secundárias por meio de um mecanismo de movimentação de dados
baseada em log do SQL Server. Por esse motivo, todos os bancos de dados no grupo de disponibilidade
devem ser definidos para o modelo de recuperação completa.
As réplicas secundárias são inicializadas com um backup e restauração completos dos bancos de dados
e logs de transações da réplica primária. À medida que novas transações são confirmadas na réplica
primária, a parte correspondente do log de transações é armazenada em cache, enfileirada e, em
seguida, enviada pela rede a um ponto de extremidade de espelhamento de banco de dados em cada
um dos nós da réplica secundária.
Dessa forma, as novas entradas no log de transações da réplica primária são acrescentadas nos logs de
transações de cada réplica secundária. Cada réplica secundária comunica periodicamente um LSN
(número de sequência de log) à réplica primária para indicar uma marca-d’água de quanto de seu log de
transações foi protegido e liberado para o disco remoto.
Observação: cada réplica de disponibilidade tem seu próprio conjunto de threads de restauração de log
de transações independentes que não fazem parte do processo de sincronização da réplica de
disponibilidade. Você pode perceber atrasos no processo de restauração de log nas réplicas secundárias,
como latência de dados.
Além de ter uma função primária ou secundária, cada réplica de disponibilidade também tem um modo
de disponibilidade, que controla a coordenação da proteção dos logs de transações durante uma
instrução COMMIT TRAN:

Modo de confirmação síncrona. A réplica primária só confirma uma determinada transação depois
que todas as réplicas secundárias de confirmação síncrona reconhecem que terminaram de
proteger seus respectivos logs de transações após o LSN da transação. Um grupo de disponibilidade
pode ter até 2 réplicas secundárias de confirmação síncrona.
O modo de confirmação síncrona apresenta a latência de transação nos bancos de dados da réplica
primária, mas garante que não haja perda de dados nas réplicas secundárias para transações
confirmadas.

Modo de confirmação assíncrona. A réplica primária confirma as transações depois de proteger
o log de transações local, mas não aguarda pela confirmação de que uma réplica secundária de
confirmação assíncrona protegeu seu log de transações. Um grupo de disponibilidade pode ter até
4 réplicas secundárias de confirmação assíncrona, mas não mais do que um total de 4 réplicas
secundárias de qualquer tipo.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
22
O modo de confirmação assíncrona minimiza a latência de transações nos bancos de dados da
réplica primária, mas permite que os logs de transações de réplicas secundárias atrasem, tornando
possível alguma perda de dados.
Para saber mais, consulte Modos de disponibilidade (http://msdn.microsoft.com/pt-br/library/
ff877931(SQL.110).aspx).
A integridade geral do fluxo de dados entre as réplicas de disponibilidade é indicada pelo estado de
sincronização de cada réplica. Você provavelmente experimentará perda de dados se fizer failover para
uma réplica secundária com um estado de sincronização diferente de ‘Sincronizado’ ou ‘Sincronizando’.
O fluxo de sincronização de cada réplica secundária tem uma propriedade tempo limite de sessão.
Quando uma réplica secundária configurada para um modo de disponibilidade de confirmação síncrona
falha com um tempo limite de sessão, ela é marcada internamente como assíncrona de forma
temporária. Isso é feito para que a falha da réplica secundária não afete a proteção do log de transações
na réplica primária. Depois que a réplica secundária estiver íntegra e atualizada com a réplica primária,
ela será automaticamente revertida para operações normais de modo de confirmação síncrona.
Failover de grupo de disponibilidade
O grupo de disponibilidade e um nome de rede virtual correspondente são registrados como recursos
no cluster do WSFC. Um grupo de disponibilidade faz failover no nível de uma réplica de disponibilidade,
com base na política de integridade e failover da réplica primária.
Uma política de failover de grupo de disponibilidade usa a propriedade FailureConditionLevel para
indicar o nível de tolerância de severidade para uma falha que afeta o grupo de disponibilidade, em
conjunto com o procedimento armazenado do sistema sp_server_diagnostics. Esse mesmo mecanismo
é usado para políticas de failover de FCI.
No caso de um failover, em vez de transferir a propriedade de recursos físicos compartilhados para
outro nó, o WSFC é utilizado para reconfigurar uma réplica secundária em outra instância do SQL Server
para assumir a função de réplica primária. O recurso de nome de rede virtual do grupo de
disponibilidade é transferido para essa instância. Todas as conexões de cliente com as réplicas de
disponibilidade envolvidas são redefinidas.
Com base na integridade, no estado de sincronização e no modo de disponibilidade atuais das réplicas,
cada réplica tem um estado composto de prontidão de failover, que indica o potencial de perda de
dados. Essas informações de integridade da réplica podem ser exibidas no Painel AlwaysOn ou na
exibição do sistema sys.dm_hadr_availability_replica_states.
Cada réplica de disponibilidade também tem um modo de failover configurado, que controla
o comportamento da réplica quando o failover é indicado.

Failover automático (sem perda de dados). Permite um failover mais rápido de qualquer
configuração AlwaysOn, pois o log de transações da réplica secundária já está protegido
e sincronizado. As transações abertas na réplica primária são revertidas, e a função de réplica
primária é transferida para uma réplica secundária sem nenhuma intervenção do usuário.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
23
As réplicas primárias e secundárias devem ser definidas para o modo de failover automático,
e ambas devem ser definidas para o modo de disponibilidade de confirmação síncrona. O estado de
sincronização entre as réplicas deve ser ‘Sincronizado’. Além disso, o cluster do WSFC deve ter um
quorum íntegro.
O failover automático não terá suporte se a réplica primária ou secundária residir em uma FCI. Isso
é bloqueado para evitar uma potencial condição de corrida entre o grupo de disponibilidade e os
failovers de FCI.

Failover manual. Permite que o administrador avalie o estado da réplica primária e tome uma
decisão de deliberadamente fazer o failover para uma réplica secundária ou não.
Dependendo do modo de disponibilidade e do estado de sincronização, você tem estas opções:
o
Failover manual planejado (sem perda de dados). Você só poderá executar esse tipo de failover
se as réplicas primárias e secundárias estiverem íntegras e em um estado ‘Sincronizado’. Isso
é funcionalmente equivalente a um failover automático.
o
Failover manual forçado (permitindo potencial perda de dados). Esta é a única forma de
failover possível se a réplica secundária de destino estiver no modo de disponibilidade de
confirmação assíncrona ou não estiver sincronizada com a réplica primária.
Aviso: você só deverá usar essa opção de failover em uma situação de recuperação de desastre.
Se a réplica primária estiver íntegra e disponível, você deverá alterar o modo de disponibilidade
das réplicas envolvidas para confirmação síncrona e, em seguida, fazer um failover manual
planejado.
Para saber mais, consulte Executar um failover manual forçado de um grupo de disponibilidade
(http://msdn.microsoft.com/pt-br/library/ff877957(SQL.110).aspx).
Você deverá fazer um failover manual se qualquer uma das seguintes condições for verdadeira em
relação à réplica primária ou secundária para a qual você quer fazer o failover:



O modo de failover está definido como manual.
O modo de disponibilidade está definido como confirmação assíncrona.
A réplica reside em uma FCI.
Para saber mais, consulte Modos de failover (Grupos de Disponibilidade AlwaysOn)
(http://msdn.microsoft.com/pt-br/library/hh213151(SQL.110).aspx).
Observação: depois de um failover, se a nova réplica primária não estiver definida para o modo de
confirmação síncrona, as réplicas secundárias indicarão um estado de sincronização ‘Suspenso’. Não
haverá nenhum fluxo de dados para as réplicas secundárias até que a réplica primária seja definida para
o modo de confirmação síncrona.
Ouvinte de grupos de disponibilidade
Um ouvinte de grupo de disponibilidade é um VNN (nome de rede virtual) do WSFC que os clientes
podem usar para acessar um banco de dados no grupo de disponibilidade. O recurso de cluster do VNN
é de propriedade da instância do SQL Server na qual a réplica primária reside.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
24
O nome de rede virtual só será registrado no DNS durante a criação do ouvinte de grupo de
disponibilidade ou durante alterações de configuração. Todos os endereços IP virtuais definidos no
ouvinte de grupo de disponibilidade são registrados no DNS com o mesmo nome de rede virtual.
Para usar o ouvinte de grupo de disponibilidade, uma solicitação de conexão de cliente deve especificar
o nome de rede virtual como o servidor, e um nome de banco de dados que esteja no grupo de
disponibilidade. Por padrão, isso deve resultar em uma conexão com a instância do SQL Server que está
hospedando a réplica primária.
Em tempo de execução, o cliente usa seu resolvedor de DNS local para obter uma lista de endereços IP
e de portas TCP mapeados para o nome de rede virtual. O cliente tenta então se conectar a cada um dos
endereços IP até conseguir ou até atingir o tempo limite de conexão. O cliente tentará fazer essas
conexões em paralelo caso o parâmetro MultiSubnetFailover esteja definido como true, permitindo
failovers de cliente muito mais rápidos.
No caso de um failover, as conexões de cliente são redefinidas no servidor, a propriedade do ouvinte de
grupo de disponibilidade é movida com a função de réplica primária para uma nova instância do SQL
Server e o ponto de extremidade do VNN é associado aos endereços IP virtuais e às portas TCP da nova
instância.
Para saber mais, consulte Conectividade de cliente e failover de aplicativo
(http://msdn.microsoft.com/pt-br/library/hh213417(SQL.110).aspx).
Filtragem de tentativa de aplicativo
Ao conectar-se por meio do ouvinte de grupo de disponibilidade, o aplicativo pode especificar se sua
tentativa é para leitura e gravação de dados ou se ele executará exclusivamente operações somente
leitura. Se não for especificado, a tentativa padrão do aplicativo para o cliente será de leitura/gravação.
Para as funções primária e secundária de cada réplica de disponibilidade, você também pode especificar
uma propriedade de acesso de conexão, que será usada como um filtro em nível de conexão na
tentativa de aplicativo do cliente. Por padrão, as combinações de acesso de conexão e tentativa de
aplicativo inválidas resultam em uma conexão recusada. O SQL Server deve filtrar solicitações de
conexão de cliente usando as regras a seguir.
Quando a réplica de disponibilidade estiver na função primária e o acesso de conexão for igual a:


Permitir qualquer tentativa de aplicativo. Não filtre nenhuma conexão de cliente para
a tentativa de aplicativo.
Permitir somente tentativa de leitura/gravação explícita. Se o cliente especificar somente
leitura, rejeite a conexão.
Quando a réplica de disponibilidade estiver na função secundária e o acesso de conexão for igual a:



Nenhuma conexão permitida. Recuse todas as conexões; a réplica é usada apenas para
recuperação de desastre.
Permitir qualquer tentativa de aplicativo. Não filtre nenhuma conexão de cliente para
a tentativa de aplicativo.
Tentativa de aplicativo somente leitura. Se o cliente não especificar somente leitura, rejeite
a conexão.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
25
Para saber mais, consulte Configurar o acesso de conexão em uma réplica de disponibilidade
(http://msdn.microsoft.com/pt-br/library/hh213002(SQL.110).aspx).
Roteamento somente leitura de tentativa de aplicativo
Uma proposta de valor importante para Grupos de Disponibilidade AlwaysOn é a capacidade de usar sua
infraestrutura de hardware em espera para outras finalidades além da recuperação de desastre. Ao
configurar uma ou mais de suas réplicas secundárias para acesso somente leitura, você poderá
descarregar cargas de trabalho significativas de suas réplicas primárias.
As cargas de trabalho que podem ser prontamente adaptadas para sair de uma réplica secundária
somente leitura incluem: relatórios, backups de bancos de dados, verificações de consistência de banco
de dados, análise de fragmentação de índice, extração de pipeline de dados, suporte operacional
e consultas ad hoc.
Para cada réplica de disponibilidade, você pode, opcionalmente, configurar uma lista de roteamento
somente leitura sequencial dos pontos de extremidade da instância do SQL Server a serem aplicados
quando essa réplica estiver na função primária. Se estiver presente, essa lista será usada para
redirecionar solicitações de conexão de cliente que especifiquem a tentativa de aplicativo somente
leitura para a primeira réplica secundária disponível na lista que satisfizer os filtros de tentativa de
aplicativo observados anteriormente.
Observação: o redirecionamento de roteamento somente leitura é executado pelo ouvinte de grupo de
disponibilidade, que é associado à réplica primária. Se a réplica primária estiver offline,
o redirecionamento do cliente não funcionará.
Para saber mais, consulte Configurar o roteamento somente leitura em um Grupo de Disponibilidade
(SQL Server) (http://msdn.microsoft.com/pt-br/library/hh653924(SQL.110).aspx)
Aperfeiçoamentos de disponibilidade – bancos de dados
O SQL Server 2012 apresenta uma série de aperfeiçoamentos de recursos que são específicos
à configuração e aos recursos do banco de dados.
O aperfeiçoamento a seguir reduz o tempo de recuperação:

Tempo de recuperação previsível. Você pode definir um intervalo de tempo de recuperação de
destino por banco de dados, que é usado para controlar a programação de um comando
CHECKPOINT em segundo plano. Esse ponto de verificação indireto ocorre periodicamente, com
base no tempo estimado necessário para recuperar o log de transações no caso de uma
reinicialização ou um failover. Isso tem o efeito de nivelar a E/S em proporções aproximadamente
iguais para cada ponto de verificação, aumentando a previsibilidade do tempo de recuperação
crescente (RTO).
Antes do SQL Server 2012, os comandos CHECKPOINT em segundo plano eram emitidos em um
intervalo fixo, independentemente do volume ou da carga de transações, o que poderia gerar
tempos de recuperação imprevisíveis.
Para saber mais, consulte Pontos de verificação de banco de dados (http://msdn.microsoft.com/ptbr/library/ms189573(SQL.110).aspx).
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
26
Esses aperfeiçoamentos reduzem os cenários comuns que podem acionar o tempo de inatividade
planejado:

Operações de índice online para colunas LOB. Os índices que contêm colunas com varbinary(max),
varchar(max), nvarchar(max) ou tipos de dados XML podem agora ser recompilados ou
reorganizados online.

Modificação de esquema online para novas colunas NOT NULL. Se uma nova coluna NOT NULL for
adicionada com um valor padrão a uma tabela de banco de dados do SQL Server 2012, somente um
bloqueio de esquema será necessário para atualizar os metadados do sistema; nem todas as linhas
precisam ser preenchidas durante a instrução ALTER TABLE.
O SQL Server só manterá fisicamente o valor padrão de coluna se uma linha for realmente
modificada ou reindexada. As consultas retornam o valor padrão dos metadados, a menos que haja
um valor de coluna real.
Existe um exemplo de suporte mais abrangente para cenários de armazenamento:

Reparo automático de página. Determinados tipos de erros do subsistema de armazenamento
podem danificar uma página de dados, tornando-a ilegível. Os Grupos de Disponibilidade AlwaysOn
podem detectar e recuperar-se automaticamente desses tipos de erros ao solicitar de forma
assíncrona e aplicar uma cópia atualizada das páginas de dados afetadas de uma réplica de
disponibilidade diferente.
Existia uma funcionalidade semelhante antes do SQL Server 2012 para espelhamento de banco de
dados, mas agora ela foi aprimorada para dar suporte a várias réplicas.
Para saber mais, consulte Reparo automático de página (http://msdn.microsoft.com/pt-br/
library/bb677167(SQL.110).aspx).
Recomendações de conectividade de cliente
Siga estas diretrizes para permitir que aplicativos cliente aproveitem por completo a tecnologias do
Microsoft SQL Server 2012 AlwaysOn:

Biblioteca de cliente com reconhecimento do AlwaysOn. Use uma biblioteca de cliente que dê
suporte à versão 7.4, ou mais recente, do protocolo TDS. Isso deve fornecer a funcionalidade
desejada do lado do cliente para recursos AlwaysOn. As bibliotecas de cliente de exemplo incluem
o Provedor de Dados para SQL Server no .NET Framework 4.02 e o SQL Native Client 11.0.

Propriedade de provedor de conexão: MultiSubnetFailover = True. Use essa palavra-chave nas
cadeias de conexão para permitir que bibliotecas de cliente tentem se conectar em paralelo com
todos os endereços IP registrados para o ouvinte de grupo de disponibilidade ou a FCI que tenha
endereço IP em várias sub-redes.

Propriedade de provedor de conexão: ApplicationIntent = ReadOnly. Onde for possível,
descarregue cargas de trabalho somente leitura da sua réplica primária para as réplicas secundárias.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
27

Tempo limite de conexão de cliente herdado. As bibliotecas herdadas de banco de dados cliente
não implementam tentativas de conexão em paralelo e, portanto, quando vários endereços IP
estiverem presentes, elas tentarão se conectar a cada um deles sequencialmente até encontrarem
um tempo limite TCP ou conseguirem se conectar.
Você deve ajustar o tempo limite de conexão de clientes herdados para acomodar os potenciais
tempos limites sequenciais e novas tentativas, quando houver vários endereços IP, para um valor
que seja de pelo menos 15 segundos + 21 segundos para cada réplica secundária.
Conclusão
Este white paper estabeleceu o contexto de linha de base sobre como reduzir os tempos de inatividade
planejado e não planejado, maximizar a disponibilidade do aplicativo e fornecer proteção de dados
usando soluções de alta disponibilidade e recuperação de desastre do SQL Server 2012 AlwaysOn.
Muitos dos fatores e desafios comerciais de planejamento, gerenciamento e medição de um ambiente de
banco de dados altamente disponível podem ser quantificados e expressos como RPO (objetivo de
ponto de recuperação) e RTO (objetivo de tempo de recuperação).
O SQL Server 2012 AlwaysOn fornece recursos em nível de infraestrutura, plataforma de dados e banco
de dados que poderão ajudar sua organização a lidar com os cenários de alta disponibilidade
e recuperação de desastre mais comuns, de uma maneira que possa ser bem-justificada com o uso de
metas de RPO e RTO.
Para saber mais:
http://www.microsoft.com/sqlserver/: Site do SQL Server
http://technet.microsoft.com/pt-br/sqlserver/: SQL Server TechCenter
http://msdn.microsoft.com/pt-br/sqlserver/: SQL Server DevCenter
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.
◊ Versão 1.1, 21 de fevereiro de 2012.
Guia de soluções Microsoft SQL Server AlwaysOn para alta disponibilidade e recuperação de desastre
28