[Fonte] Alta Disponibilidade no SQL Server (1) ---- uma visão geral da alta disponibilidade

Desde o SQL Server 2005, a Microsoft tem fornecido uma variedade de tecnologias de alta disponibilidade para reduzir o tempo de inatividade e aumentar a proteção dos dados empresariais, e com o lançamento contínuo do SQL Server 2008, SQL Server 2008 R2 e SQL Server 2012, existem muitas tecnologias de alta disponibilidade no SQL Server para atender a diferentes cenários.

    Antes de começar este artigo, vou fazer uma breve visão geral do que determina qual tecnologia de alta disponibilidade usar.

    Muitas empresas precisam que todos ou parte de seus dados estejam altamente disponíveis, como sites de compras online, bancos de dados de produtos online precisam estar online 24 horas por dia, 7 dias por semana, caso contrário, em um ambiente de mercado altamente competitivo, o tempo de inatividade significa perda de clientes e receita. Por exemplo, em um call center que depende do SQL Server, se o banco de dados cair, todos os chamadores só podem sentar e responder ao cliente "Desculpe, falha do sistema", o que também é inaceitável.

    Claro, em um mundo ideal, todos os dados críticos estariam online o tempo todo, mas no mundo real haverá várias razões para o banco de dados estar indisponível, pois é impossível prever o momento e a forma do desastre, sendo necessário tomar medidas antecipadamente para evitar diversas emergências. Assim, o SQL Server oferece uma variedade de tecnologias de alta disponibilidade, que incluem principalmente: clustering, replicação, espelhamento, entrega de logs, grupos de disponibilidade AlwaysOn e outras, como backup e restauração de grupos de arquivos, Tecnologias de alta disponibilidade de instância única, como índices de reconstrução online. O uso de tecnologia de alta disponibilidade não é para escolher uma tecnologia familiar para uso direto, mas para considerar o negócio e a tecnologia de forma abrangente. Porque não existe uma única tecnologia que possa alcançar todas as funções. Como adotar essas tecnologias com base no seu negócio e orçamento específicos é o que se conhece como estratégia de alta disponibilidade.

Ao projetar uma estratégia de alta disponibilidade, você deve primeiro considerar os seguintes fatores:

• RTO (Objetivo de Tempo de Recuperação) - ou seja, objetivo de tempo de recuperação, significa quanto tempo de inatividade é permitido, geralmente expresso por alguns 9s, por exemplo, disponibilidade de 99,999% significa no máximo 5 minutos de tempo de indisponibilidade por ano, disponibilidade de 99,99% significa no máximo 52,5 minutos de tempo de indisponibilidade por ano, e disponibilidade de 99,9% significa no máximo 8,75 horas de tempo de inatividade por ano. Vale notar que o método de cálculo do RTO leva em conta se o sistema é 24*365 ou apenas das 6h às 21h, etc. Você também precisa prestar atenção se a janela de manutenção é considerada como tempo de inatividade, e é mais fácil alcançar maior disponibilidade se a manutenção do banco de dados e o patching forem permitidos durante a janela de manutenção.
• RPO (Objetivo do Ponto de Recuperação) – Também conhecido como objetivo do ponto de recuperação, significa quanto de perda de dados é permitida. Normalmente, desde que você faça um bom backup, pode facilmente obter perda zero de dados. Mas quando ocorre um desastre, dependendo da extensão da corrupção do banco de dados, o tempo necessário para restaurar os dados a partir de um backup fará com que o banco de dados fique indisponível, o que afetará a implementação do RTO. Um exemplo inicial e mais famoso é um sistema bancário na Europa e nos Estados Unidos, considerando apenas RPO, há apenas backups completos e backups de log no sistema, backups completos a cada 3 meses, backups de log a cada 15 minutos; quando ocorre um desastre, somente por meio de backups completos e de log backups podem restaurar dados, então, embora não haja perda de dados, como levou dois dias inteiros para restaurar os dados, o sistema bancário ficou indisponível por 2 dias, perdendo um grande número de clientes. Outro exemplo oposto é um site de vídeo online doméstico, que usa SQL Server como banco de dados relacional back-end, o front-end usa No-SQL, e importa regularmente dados No-SQL para o banco de dados relacional como backup.
  

    Orçamento – RTO e RPO são coletivamente conhecidos como SLAs (Acordos de Nível de Serviço), e ao projetar uma estratégia de alta disponibilidade, você precisa medir o quão bem você cumpre os SLAs com base no seu negócio, dependendo do seu orçamento e medindo o custo de diferentes SLAs em caso de falha. De modo geral, é difícil alcançar altos SLAs com um orçamento limitado, e mesmo que altos SLAs sejam alcançados por meio de arquiteturas complexas, arquiteturas complexas também significam altos custos de operação e manutenção, então é necessário escolher a tecnologia certa dentro do orçamento para atender aos SLAs.

Portanto, em geral, o grande arcabouço para alta disponibilidade pode ser determinado por várias questões de tomada de pedidos:

• Qual é o tempo de inatividade que os acionistas estão dispostos a aceitar?
• Qual tempo de inatividade é aceitável para gerentes?
• Qual é o orçamento previsto para um cenário de alta disponibilidade?
• Qual é a perda por hora devido ao tempo de inatividade?
  

• Backup frio: O servidor de espera é configurado para aceitar os dados do servidor principal e, quando falhar, restaurar manualmente os dados no banco de dados primário ou reconfigurar a string de conexão ou as permissões do programa para colocar o banco de dados de backup online.
• Backup quente: Os dados do servidor primário transmitem continuamente logs para o servidor de backup (em intervalos irregulares, podem ser de 15 minutos, 30 minutos, 1 minuto, etc.), dessa forma, o servidor principal para o servidor de backup geralmente é atualizado assíncrono, de modo que os dados do servidor principal e do servidor de backup não podem ser garantidos. Além disso, esse esquema normalmente não implementa monitoramento automático de falhas e failover.
• Backup quente: Os dados do servidor principal são sincronizados automaticamente no servidor de backup e, na maioria dos casos, monitoramento automático de falhas e failover são incluídos, garantindo a consistência dos dados entre o servidor principal e o servidor de backup.
  

    Com backups de frio para quente e quente, os custos disparam.

    Os recursos de alta disponibilidade suportados no SQL Server estão intimamente relacionados à versão, e a edição Enterprise suporta todos os recursos de alta disponibilidade, incluindo:

• Cluster de failover
• L Imagem do banco de dados
• L Transmissão de registros de transações
• L Snapshots do banco de dados
• L Upgrades de alta disponibilidade
• L Memória de carregamento quente
• L Operações de indexação online
• L Banco de dados parcialmente online (apenas o grupo de arquivos mestre ou grupo de arquivos mestre e arquivos NDF adicionais são restaurados)
  

    Para versões específicas que oferecem alta disponibilidade, veja:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxVale notar que a versão gratuita Express pode servir como servidor testemunha para espelhamento de banco de dados, resultando em economia de custos.

Cluster de failover

    Clusters de failover oferecem suporte de alta disponibilidade para toda a instância do SQL Server, o que significa que uma instância do SQL Server em um nó do cluster faz failover para outros nós do cluster devido a erros de hardware, erros do sistema operacional, etc. Alta disponibilidade é alcançada por múltiplos servidores (nós) compartilhando um ou mais discos, e clusters de failover aparecem na rede da mesma forma que um único computador, porém com características de alta disponibilidade. É importante notar que, como clusters de failover são baseados em discos compartilhados, há um único ponto de falha do disco, portanto, proteções adicionais, como a replicação SAN, precisam ser implantadas no nível do disco. O cluster de failover mais comum é um cluster de failover de dois nós, incluindo o mestre e o escravo.

Transmissão de logares de transação

    O envio de logs de transações oferece proteção de alta disponibilidade em nível de banco de dados. O registro é usado para manter um ou mais bancos de dados de espera (chamados de "bancos de dados secundários") do banco de dados de produção correspondente (chamado de "banco de dados primário"). Antes que ocorra um failover, o banco de dados secundário deve ser totalmente atualizado aplicando manualmente todos os backups de log não restaurados. A entrega de logs tem a flexibilidade de suportar múltiplos bancos de dados de espera. Se forem necessários múltiplos bancos de dados alternativos, a entrega de logs pode ser usada separadamente ou como complemento ao espelhamento de banco de dados. Quando essas soluções são usadas em conjunto, o banco de dados principal da configuração atual de espelhamento de banco de dados também é o banco de dados principal da configuração atual de envio de logs.

    A entrega de log de transações pode ser usada para fazer backups a frio e a quente.

Espelhamento de banco de dados

    O espelhamento de banco de dados é, na verdade, uma solução de software que também oferece proteção em nível de banco de dados, proporcionando failover quase instantâneo para melhorar a disponibilidade do banco de dados. Um espelho de banco de dados pode ser usado para manter um único banco de dados de reserva (ou "banco de dados espelhado") para o banco de dados de produção correspondente (chamado de "banco de dados principal").
Como o banco de dados espelhado está sempre em estado de restauração, mas o banco de dados não é restaurado, o banco de dados espelhado não pode ser acessado diretamente. No entanto, para cargas somente leitura, como relatórios, você pode usar o banco de dados espelhado indiretamente criando um snapshot do banco de dados espelhado. Snapshots de banco de dados fornecem aos clientes acesso somente leitura aos dados do banco de dados quando o snapshot é criado. Cada configuração de espelhamento de banco de dados envolve um "servidor principal" que contém o banco de dados principal, e também envolve um servidor espelho que contém o banco de dados espelhado. O servidor espelho atualiza continuamente o banco de dados espelhado com o banco de dados principal.
    O espelhamento de banco de dados roda em operação síncrona em modo de alta segurança ou operação assíncrona em modo de alto desempenho. No modo de alto desempenho, as transações não precisam esperar que o servidor espelho escreva logs no disco antes de poderem ser enviadas, o que maximiza o desempenho. No modo de alta segurança, transações comprometidas são comprometidas por ambos os parceiros, mas o tempo de atraso da transação é estendido. A configuração mais simples de espelhamento de banco de dados envolve apenas o servidor principal e o servidor espelhado. Nessa configuração, se o servidor principal for perdido, o servidor espelho pode ser usado como servidor de reserva, mas pode causar perda de dados. O modo de alta segurança suporta configuração de espera em modo de alta segurança com failover automático. Essa configuração envolve uma instância de servidor de terceiros chamada "servidor testemunha" que permite que o servidor espelho seja usado como um servidor de backup quente. O failover do banco de dados primário para o banco de dados espelhado normalmente leva alguns segundos.

    O espelhamento de banco de dados pode ser usado tanto para backups quentes quanto ativos.

copiar

    Replicação não é estritamente um recurso projetado para alta disponibilidade, mas pode ser aplicado à alta disponibilidade. A replicação oferece proteção em nível de objeto no banco de dados. A replicação utiliza um modelo de publicação-assinatura, onde os dados são publicados pelo servidor principal, conhecido como publisher, para um ou mais secundários ou assinantes. A replicação oferece disponibilidade e escalabilidade em tempo real entre esses servidores. Ele suporta filtragem para fornecer um subconjunto de dados aos assinantes, além de suportar atualizações de partições. O assinante está online e disponível para relatórios ou outras funções sem necessidade de recuperação de consultas. O SQL Server oferece quatro tipos de replicação: replicação snapshot, replicação transacional, replicação peer-to-peer e replicação por mescagem.

AlwaysOnGrupo de usabilidade

    Grupos de Disponibilidade AlwaysOn é um novo recurso introduzido no SQL Server 2012. Também é fornecida proteção em nível de banco de dados. Também expande o limite de que o espelhamento de banco de dados pode ser apenas 1:1, de modo que uma réplica primária pode corresponder a até 4 réplicas secundárias (no SQL Server 2014, esse limite é ampliado para 8), das quais 2 réplicas secundárias podem ser sincronizadas como backups quentes e réplicas primárias em tempo real, e as outras duas réplicas secundárias assíncronas podem ser usadas como backups quentes. Além disso, réplicas secundárias podem ser configuradas como somente leitura e podem ser usadas para suportar a carga de backups.

    Por causa disso, o espelhamento de banco de dados é marcado como "obsoleto" no SQL Server 2012.

    Depois de entender os conceitos básicos de alta disponibilidade e as tecnologias de alta disponibilidade fornecidas no SQL Server, vamos analisar o design de uma estratégia de alta disponibilidade. O planejamento de uma estratégia de alta disponibilidade pode ser dividido em quatro fases:

Requisitos de coleta

    O primeiro passo para decidir uma estratégia de alta disponibilidade é, sem dúvida, reunir os requisitos de negócio para estabelecer SLAs. RTO e RPO são as partes mais críticas e, com base nisso, estabeleça expectativas realistas para os requisitos de disponibilidade e uma estratégia realista de alta disponibilidade baseada nessas expectativas.

Limites de Avaliação

    Os limites de avaliação não se limitam apenas às limitações de diferentes tecnologias de alta disponibilidade no SQL Server, mas também àquelas que não são técnicas. Se você tem apenas um orçamento de dezenas de milhares de yuans, mas quer fazer uma solução de alta disponibilidade baseada em data centers externos e replicação de SAN, sem dúvida é um sonho de tolo. Outra limitação não técnica é o nível do pessoal de operações, e muitas vezes, arquiteturas complexas significam mais pessoal operacional qualificado. Outras limitações não técnicas incluem a disponibilidade de espaço em disco no data center, se a fonte de energia e o ar-condicionado podem atender às necessidades e o tempo necessário para implementar a estratégia de disponibilidade.

    Limitações técnicas incluem diferentes funções e limitações de alta disponibilidade, funções suportadas por diferentes versões do SQL Server, o número de CPUs e o tamanho da memória. É fortemente recomendado que você consulte primeiro as limitações das diferentes versões e recursos do SQL Server no site MSDN da Microsoft antes de implementar uma política de alta disponibilidade.

Tecnologia selecionada

    Após reunir os requisitos e avaliar as restrições, o próximo passo é selecionar as tecnologias ou a combinação de tecnologias descritas anteriormente neste artigo para atender aos requisitos do SLA. Se a tecnologia selecionada não atender ao SLA, é fácil relatar quais limitações não estão atendendo ao SLA, permitindo que você solicite recursos faltantes ou comprometa o SLA.

Teste, valide e documente

    As políticas de alta disponibilidade precisam ser rigorosamente testadas e validadas desde o início para garantir que as políticas atuais atendam aos SLAs. No entanto, quando uma estratégia de alta disponibilidade é lançada, também é necessário testá-la e validá-la regularmente para garantir que a política atual ainda possa atender aos SLAs, apesar do crescimento dos dados, mudanças no negócio ou nos requisitos. Ao mesmo tempo, a configuração da solução de disponibilidade, o método de failover e o plano de recuperação de desastres devem ser documentados ao mesmo tempo, para que possam ser rastreados em caso de falha ou ajuste futuro da estratégia de alta disponibilidade.

Este artigo explica os conceitos básicos de alta disponibilidade, o conceito de SLAs, os diferentes tipos de recursos de alta disponibilidade suportados no SQL Server e os passos necessários para projetar uma estratégia de alta disponibilidade. Vale ressaltar que, embora este artigo fale apenas sobre alta disponibilidade no nível do banco de dados, a alta disponibilidade não é apenas uma questão para DBA, mas também inclui a colaboração de diferentes funções, como pessoal de operação e manutenção de sistemas, administradores de rede, desenvolvedores e gerentes para melhor atender aos SLAs.