Este documento apresenta estratégias de recuperação de desastres (DR) para Microsoft SQL Server para arquitetos e líderes técnicos responsáveis por projetar e implementar recuperação de desastres em Google Cloud.
Os bancos de dados podem ficar indisponíveis por vários motivos, por exemplo, falhas de hardware ou de rede. Para fornecer acesso contínuo ao banco de dados durante falhas, é mantido um banco de dados secundário que é uma réplica de um banco de dados primário. Ter o banco de dados secundário em um local diferente aumenta as chances de ele estar disponível quando o banco de dados primário ficar indisponível.
Se o banco de dados primário ficar indisponível, seu aplicativo de missão crítica se conectará a um banco de dados secundário, continuando a partir do estado de dados consistente conhecido mais recentemente para fornecer serviços aos seus usuários com tempo de inatividade mínimo ou nenhum.
O processo de disponibilização de um banco de dados secundário em caso de falha do banco de dados primário é chamado de recuperação de desastres (DR) de banco de dados . O banco de dados secundário se recupera da indisponibilidade do banco de dados primário. Idealmente, o banco de dados secundário tem exatamente o mesmo estado consistente que o banco de dados primário quando está indisponível ou perde apenas um conjunto mínimo de transações recentes do banco de dados primário.
DR de banco de dados é um recurso essencial para clientes corporativos. O principal motivador é a continuidade dos negócios para aplicativos de missão crítica. Por exemplo, um aplicativo de missão crítica gera receita (comércio eletrônico), fornece serviços contínuos e confiáveis (gerenciamento de voos ou motores) ou oferece suporte a funcionalidades de preservação de vidas (monitoramento de pacientes). Em todos esses exemplos, é de extrema importância que o aplicativo esteja continuamente disponível porque é considerado de missão crítica.
A maioria dos sistemas de gerenciamento de banco de dados oferece funcionalidade de recuperação de desastres, incluindo o Microsoft SQL Server . Este documento de arquitetura discute como os recursos de DR fornecidos pelo SQL Server são implementados no contexto de Google Cloud.
Terminologia
As seções a seguir explicam os termos usados neste documento.
Arquitetura geral de DR
O diagrama a seguir ilustra a topologia geral da arquitetura de DR.
No diagrama anterior, um aplicativo acessa um banco de dados primário enquanto um banco de dados secundário está em espera e espelha o estado do banco de dados primário. Os clientes estão acessando o aplicativo executado em Google Cloud.
Se o banco de dados primário ficar indisponível, os administradores de banco de dados ou a equipe de operações terão que decidir iniciar o processo de recuperação de desastres. Se a recuperação de desastres do banco de dados for iniciada, o aplicativo será reconectado ao banco de dados secundário. Depois de conectado, o aplicativo poderá atender seus clientes novamente. Em uma situação ideal, o aplicativo estará disponível no banco de dados secundário o mais rápido possível, para que os clientes nem sequer sofram uma interrupção. Uma alternativa é esperar que o banco de dados primário fique acessível novamente, em vez de iniciar a recuperação de desastres. Por exemplo, se o desastre for intermitente, poderá ser mais rápido resolver o problema em vez de efetuar failover.
Bancos de dados primários e secundários
Um banco de dados primário é acessado por um ou mais aplicativos para fornecer serviços de persistência para o gerenciamento de estado do aplicativo. Um banco de dados secundário está relacionado a um banco de dados primário e contém uma réplica do banco de dados primário. Idealmente, o conteúdo do banco de dados secundário corresponde exatamente ao conteúdo do banco de dados primário em qualquer momento. Em muitos casos, o banco de dados secundário fica atrasado em relação ao banco de dados primário devido a atrasos na aplicação de alterações transacionais feitas no banco de dados primário. É possível associar mais de um banco de dados secundário a um banco de dados primário, dependendo da tecnologia do banco de dados. O SQL Server oferece suporte à associação de mais de um banco de dados secundário a um banco de dados primário .
Recuperação de desastres
Se um banco de dados primário ficar indisponível, o DR alterará a função do banco de dados secundário para se tornar o banco de dados primário. Se houver mais de um banco de dados secundário, um desses bancos de dados será selecionado manualmente ou com base em uma lista de failover preferencial. Os aplicativos precisam se reconectar ao novo banco de dados primário para continuar acessando seu estado. Se o novo banco de dados primário não estiver sincronizado com o último estado conhecido do antigo banco de dados primário, o aplicativo será iniciado a partir de um estado anterior (também conhecido como flashback ).
É importante ter sempre pelo menos um banco de dados secundário para cada banco de dados primário. Após uma recuperação de desastres, certifique-se de que um novo banco de dados secundário esteja configurado para lidar com futuros cenários de recuperação de desastres.
Failover, alternância e fallback
Existem vários cenários para alterar a função entre bancos de dados primários e secundários:
- Failover : o processo de alterar a função de um banco de dados secundário para ser o novo banco de dados primário e conectar todos os aplicativos a ele. O failover não é intencional porque é acionado quando um banco de dados primário fica indisponível. Você pode configurar o failover para ser acionado automática ou manualmente.
- Switchover : em contraste com o failover, uma mudança de um banco de dados primário para um banco de dados secundário (novo banco de dados primário) é acionada intencionalmente para testes iniciais e manutenção programada. Teste seu sistema de DR com alternâncias periódicas regulares para garantir a confiabilidade contínua da recuperação de desastres.
- Fallback : o fallback é a reversão do processo em que o novo banco de dados primário se torna o banco de dados secundário, após o reparo do banco de dados primário. Um fallback é acionado intencionalmente para restabelecer o estado antes do início do failover ou da alternância. Não é estritamente necessário, mas pode ser feito com base nos requisitos de recuperação de desastres, como localidade ou recursos disponíveis.
Google Cloud zonas e regiões
Recursos como bancos de dados estão localizados em Google Cloud zonas e regiões , onde cada zona pertence a uma região. Uma zona é um domínio de ponto único de falha. Recomendamos a implantação de um recurso altamente disponível e tolerante a falhas em múltiplas zonas dentro de uma região.
Para se proteger contra a interrupção de toda uma região, estabeleça estratégias multirregionais para a recuperação de desastres. Por exemplo, o banco de dados primário está localizado em uma região e seu banco de dados secundário correspondente está localizado em outra região.
Modos ativos: ativo-passivo e ativo-ativo
Um banco de dados primário é um banco de dados aberto para operações de leitura e gravação (operações DML) para que os aplicativos que o acessam possam gerenciar seu estado. O banco de dados primário é chamado de banco de dados ativo . O banco de dados secundário correspondente é passivo porque replica o banco de dados primário, mas não está disponível em nenhum aplicativo para operações de alteração de estado. Após um failover ou uma alternância, o banco de dados secundário se torna o novo banco de dados primário e se torna um banco de dados ativo.
O banco de dados primário e o banco de dados secundário podem ser bancos de dados ativos se a tecnologia de banco de dados suportar esse recurso, chamado modo ativo-ativo . Nesse caso, os aplicativos podem se conectar a um ou outro porque ambos os bancos de dados estão disponíveis para gerenciamento de estado. A recuperação de desastres no modo ativo não requer failover se apenas um dos bancos de dados ativos ficar indisponível. Se um banco de dados ativo estiver indisponível, o outro banco de dados ativo continuará disponível. O modo ativo-ativo está fora do escopo deste artigo porque o SQL Server não dá suporte a esse modo.
Modos de espera: quente, morno, frio e sem espera
Para que o banco de dados primário seja o banco de dados ativo, ele deve estar em execução e ser capaz de executar instruções DML. O banco de dados secundário não precisa estar em execução; ele pode ser desligado. Se não estiver em execução, o tempo necessário para a recuperação de um desastre aumenta porque o novo banco de dados primário deve primeiro ser colocado em estado de execução, antes de assumir a função do novo banco de dados primário.
Existem diversas variações sobre como configurar o banco de dados secundário:
- Hot standby : o banco de dados secundário está funcionando e pronto para ser conectado pelos clientes. A última alteração disponível no banco de dados primário é sempre aplicada assim que estiver disponível.
- Espera quente : um banco de dados secundário está instalado e em execução, no entanto, nem todas as alterações do banco de dados primário foram necessariamente aplicadas ainda.
- Cold standby : um banco de dados secundário não está em execução. Primeiro, ele precisa ser inicializado e depois sincronizado com o estado mais recente disponível.
- Sem espera : o software do banco de dados deve ser instalado primeiro e posteriormente inicializado antes que todas as alterações do banco de dados primário sejam aplicadas. Este modo é o menos dispendioso porque não consome recursos quando não são necessários, mas em comparação com os outros modos, leva mais tempo para se tornar um novo banco de dados primário.
Estratégias de DR
Nas seções a seguir, são explicadas as estratégias de recuperação de desastres suportadas pelo Microsoft SQL Server.
Dimensões da estratégia de recuperação
Há diversas dimensões importantes a serem consideradas ao selecionar ou implementar uma estratégia de recuperação de desastres de banco de dados. Cada dimensão tem um espectro e o comportamento e as expectativas da estratégia de recuperação de desastres dependem da seleção dos pontos do espectro. As principais dimensões são as seguintes:
- Objetivo do ponto de recuperação (RPO) : o período máximo aceitável durante o qual os dados podem ser perdidos do seu aplicativo devido a um incidente grave. Essa dimensão varia de acordo com a forma como os dados são usados. O RPO pode ser expresso em duração (segundos, minutos ou horas) a partir do momento da indisponibilidade do banco de dados primário ou pode ser expresso como estados de processamento identificáveis (último backup completo ou último backup incremental). Não importa como o RPO é especificado, a estratégia de recuperação de desastres deve implementar a medida específica para que o requisito do RPO possa ser satisfeito. O caso mais exigente é a última transação confirmada, o que significa que nenhuma perda do banco de dados primário para o banco de dados secundário deve ocorrer.
- Objetivo de tempo de recuperação (RTO) . O período máximo aceitável que seu aplicativo pode ficar off-line. Esse valor geralmente é especificado como parte de um acordo de nível de serviço mais amplo. O RTO geralmente é expresso em termos de duração a partir do momento da indisponibilidade do banco de dados primário, por exemplo, o aplicativo deve estar totalmente operacional em 5 minutos. O caso mais exigente é imediato, para que os usuários do aplicativo não percebam que ocorreu a recuperação de desastres.
- Domínio de ponto único de falha . Cabe a você decidir se uma região é considerada um domínio de ponto único de falha para seus requisitos de recuperação de desastres. Se uma região for um domínio de ponto único de falha para você, a recuperação de desastres deverá ser configurada para que duas ou mais regiões estejam envolvidas na configuração real. Se a região que contém o banco de dados primário falhar, o banco de dados secundário em uma região diferente será o novo banco de dados primário. Se o domínio de ponto único de falha for considerado uma zona, a recuperação de desastres poderá ser configurada em zonas de uma única região. Se uma zona falhar, a recuperação de desastres usará uma segunda zona e disponibilizará nela o novo banco de dados primário.
Decidir sobre essas dimensões-chave é tomar uma decisão entre custo e qualidade. Quanto menor o RTO e o RPO, mais cara a solução de recuperação de desastres pode se tornar à medida que mais recursos ativos são usados. Nas seções a seguir, são discutidas diversas estratégias alternativas de DR que representam pontos nas dimensões no contexto do banco de dados Microsoft SQL Server.
Estratégias de DR para SQL Server
Continuidade de negócios e recuperação de banco de dados – o SQL Server descreve recursos de disponibilidade que você pode usar para implementar estratégias de recuperação de desastres.
Preliminares
O SQL Server é executado em Windows e Linux. No entanto, nem todos os recursos de disponibilidade estão disponíveis no Linux. O SQL Server tem diversas edições, mas nem todos os recursos de disponibilidade estão disponíveis em todas as edições.
O SQL Server distingue instâncias de bancos de dados. Uma instância é o software SQL Server em execução, enquanto um banco de dados é o conjunto de dados gerenciado por uma instância do SQL Server.
Grupos de disponibilidade Always On
Os grupos de disponibilidade Always On fornecem proteção em nível de banco de dados. Um grupo de disponibilidade tem duas ou mais réplicas. Uma réplica é a réplica primária com acesso de leitura e gravação, e as réplicas restantes são réplicas secundárias que podem fornecer acesso de leitura. Cada réplica de banco de dados é gerenciada por uma instância autônoma do SQL Server. Um grupo de disponibilidade pode conter um ou mais bancos de dados. O número de bancos de dados que podem ser incluídos em um grupo de disponibilidade e o número de réplicas secundárias com suporte dependem da edição do SQL Server. Todos os bancos de dados de um grupo de disponibilidade passam pelas mesmas alterações do ciclo de vida ao mesmo tempo. Os grupos de disponibilidade implementam o modo ativo-passivo porque somente o banco de dados primário dá suporte ao acesso de gravação.
Quando ocorre um failover, uma réplica secundária se torna a nova réplica primária. Como um grupo de disponibilidade inclui instâncias autônomas do SQL Server, todas as operações capturadas nos logs de transações estão disponíveis nas réplicas. Qualquer alteração não capturada em um log de transações precisa ser sincronizada manualmente, por exemplo, logins em nível de instância do SQL Server ou trabalhos do SQL Server Agent. Para fornecer proteção em nível de banco de dados e proteção de instância do SQL Server, você precisa configurar FCIs (Instâncias de Cluster de Failover). Essa arquitetura de implantação será discutida posteriormente na seção Instância de cluster de failover Always On .
Você pode proteger os aplicativos contra alterações de função usando um ouvinte. Um ouvinte dá suporte a aplicativos que se conectam ao grupo de disponibilidade. Os aplicativos não sabem quais instâncias do SQL Server estão gerenciando o banco de dados primário ou as réplicas secundárias em nenhum momento. Os ouvintes exigem que os clientes usem uma versão mínima do .NET 3.5 com uma atualização ou 4.0 e superior, conforme descrito em Continuidade de negócios e recuperação de banco de dados - SQL Server .
Os grupos de disponibilidade dependem de camadas subjacentes de abstração para fornecer sua funcionalidade. Os grupos de disponibilidade são executados em um Cluster de Failover do Windows Server (WSFC), conforme descrito em Cluster de Failover do Windows Server com SQL Server . Todos os nós que executam instâncias do SQL Server devem fazer parte do mesmo WSFC.
As transações são enviadas do banco de dados primário para todas as réplicas secundárias. Existem dois modos de envio para enviar transações: síncrono e assíncrono. Você pode configurar independentemente cada réplica para usar um ou outro modo. No modo de envio síncrono, a transação no banco de dados primário só será bem-sucedida se for bem-sucedida em todas as réplicas secundárias vinculadas de forma síncrona. No modo assíncrono, a transação no banco de dados primário pode ser bem-sucedida mesmo que nem todas as réplicas secundárias tenham a transação aplicada.
A escolha do modo de envio influencia o possível RTO, RPO e o modo de espera. Por exemplo, se as transações forem enviadas para todas as réplicas no modo síncrono, todas as réplicas estarão exatamente no mesmo estado. O RPO (transação mais recente) mais exigente é cumprido, pois todas as réplicas são totalmente sincronizadas. As réplicas secundárias são hot standbys, portanto qualquer uma delas pode ser usada imediatamente como banco de dados primário.
O failover pode ser automático ou manual. Um failover automático é possível se todas as réplicas estiverem totalmente sincronizadas. No exemplo anterior, isso é possível porque todas as réplicas estão sempre totalmente sincronizadas.
A figura a seguir mostra um grupo de disponibilidade Always On em uma única região.
O grupo de disponibilidade é representado como um retângulo que abrange zonas. Isto é apenas para fins ilustrativos para indicar que todos os bancos de dados pertencem ao mesmo grupo de disponibilidade. O grupo de disponibilidade não é um recurso de nuvem e, como tal, não é implementado em um nó ou em qualquer outro tipo de recurso.
Instância de cluster de failover sempre ativa
Para se proteger contra falhas de nós, você pode usar FCIs (Instâncias de Cluster de Failover) em vez de instâncias autônomas do SQL Server. Existem dois ou mais nós que executam instâncias do SQL Server para gerenciar um banco de dados (primário ou secundário). Os nós que gerenciam um banco de dados formam um Cluster de Failover. Um nó no cluster está executando ativamente uma instância do SQL Server, enquanto os outros nós não estão executando instâncias do SQL Server. Quando o nó que executa a instância do SQL Server falha, outro nó no cluster inicia uma instância do SQL Server, assumindo o gerenciamento do banco de dados (failover do nó). Esse processo de inicialização automática de uma instância do SQL Server fornece funcionalidade de alta disponibilidade.
O cluster FCI aparece como uma unidade única e os clientes que acessam o cluster não veem o failover entre os nós, exceto talvez por um curto período de indisponibilidade. Não há perda de dados quando ocorre um failover de nó. Tudo o que está em execução na instância com falha do SQL Server é movido para outra instância do SQL Server no mesmo cluster. Por exemplo, os trabalhos do SQL Server Agent ou servidores vinculados são movidos para outra instância.
Os nós do cluster FCI podem ser configurados em diferentes Google Cloud zonas. Essa arquitetura não fornece apenas alta disponibilidade em caso de falha de nó, mas também em caso de falhas de zona. Um exemplo de implantação dessa estratégia é discutido na seção Alternativas de implantação de DR .
Embora diferentes nós gerenciem o mesmo banco de dados e compartilhem o banco de dados, não há necessidade de armazenamento comum entre os nós de um cluster FCI. O SQL Server usa a funcionalidade Storage Spaces Direct (S2D) para gerenciar bancos de dados em discos de nós dedicados. Para obter mais informações, consulte Configurando instâncias de cluster de failover do SQL Server .
O exemplo da seção anterior Grupos de disponibilidade Always On com FCIs em vez de instâncias autônomas do SQL Server é mostrado na figura a seguir. Cada FCI possui uma instância ativa do SQL Server gerenciando o banco de dados.
Assim como no caso do grupo de disponibilidade, uma FCI é representada como um retângulo. Isto é apenas para fins ilustrativos para indicar que todos os nós pertencem à mesma FCI. Uma FCI não é um recurso de nuvem e, como tal, não é implementada em um nó ou em qualquer outro tipo de recurso.
Para obter uma discussão mais detalhada, consulte Instâncias de cluster de failover Always On (SQL Server) .
Grupos de disponibilidade distribuídos
Os grupos de disponibilidade distribuídos são um tipo especial de grupo de disponibilidade. Um grupo de disponibilidade distribuído abrange dois grupos de disponibilidade, um na função do grupo de disponibilidade primário e outro na função do grupo de disponibilidade secundário. Os grupos de disponibilidade distribuídos podem encaminhar transações no modo síncrono e assíncrono do grupo de disponibilidade primário para o grupo de disponibilidade secundário.
Embora cada um dos grupos de disponibilidade tenha seu próprio banco de dados primário, esta não é uma implantação ativa. Somente o banco de dados primário do grupo de disponibilidade primário pode receber operações de gravação. O banco de dados primário do grupo de disponibilidade secundário é chamado de encaminhador. O encaminhador recebe as transações do grupo de disponibilidade primário e as encaminha para os bancos de dados secundários do grupo de disponibilidade secundário. Um failover do grupo de disponibilidade primário para o grupo de disponibilidade secundário tornaria o banco de dados primário do novo grupo de disponibilidade primário acessível para operações de gravação.
Os grupos de disponibilidade primário e secundário não precisam estar no mesmo local e não precisam estar no mesmo sistema operacional. No entanto, cada grupo de disponibilidade precisa ter um ouvinte instalado. O próprio grupo de disponibilidade distribuído não tem um ouvinte. Os grupos de disponibilidade distribuídos não exigem que os dois grupos de disponibilidade estejam no mesmo WSFC. Todas as funcionalidades necessárias para fazer os grupos de disponibilidade distribuídos funcionarem estão contidas na funcionalidade do SQL Server e não requerem a instalação adicional de componentes subjacentes.
Um grupo de disponibilidade distribuído abrange exatamente dois grupos de disponibilidade. Um grupo de disponibilidade pode fazer parte de dois grupos de disponibilidade distribuídos. Esta possibilidade suporta diferentes topologias. Uma delas é uma topologia de encadeamento em série de grupo de disponibilidade para grupo de disponibilidade em vários locais. Outra topologia é uma topologia em árvore em que o grupo de disponibilidade primário faz parte de dois grupos de disponibilidade distribuídos diferentes e separados.
Os grupos de disponibilidade distribuídos são o principal meio de implementar a recuperação de desastres em sistemas operacionais. Por exemplo, o grupo de disponibilidade primário pode ser configurado no Windows e um segundo grupo de disponibilidade correspondente no Linux, com ambos os grupos de disponibilidade formando um grupo de disponibilidade distribuído.
O diagrama a seguir mostra dois grupos de disponibilidade que fazem parte de um grupo de disponibilidade distribuído.
O grupo de disponibilidade 1 é o grupo de disponibilidade primário e o grupo de disponibilidade 2 é o grupo de disponibilidade secundário.
Tal como no caso dos FCIs, um grupo de disponibilidade distribuída é representado como um retângulo. Isto é apenas para fins ilustrativos para indicar que todos os grupos de disponibilidade pertencem ao mesmo grupo de disponibilidade distribuído. Um grupo de disponibilidade distribuído, como um grupo de disponibilidade, não é um recurso de nuvem e, como tal, não é implementado em um nó ou em qualquer outro tipo de recurso.
Para obter mais informações, consulte Grupos de disponibilidade distribuídos .
Envio de registros
O envio de log de transações é um recurso de disponibilidade do SQL Server quando o RTO e o RPO não são tão rigorosos (RTO baixo e/ou RPO recente) porque a discrepância de estado entre um banco de dados primário e seu banco de dados secundário é significativamente maior. A discrepância é maior em termos de estado porque um arquivo de log de transações contém muitas alterações de estado. A discrepância também é maior em termos de tempo de atraso porque os arquivos de log de transações são transportados de forma assíncrona e precisam ser aplicados integralmente a um banco de dados secundário.
Os arquivos de log de transações são criados pelo banco de dados primário e armazenados em backup, por exemplo, no Cloud Storage. Cada arquivo de log de transações é copiado para cada banco de dados secundário e aplicado a ele. Como o banco de dados secundário está atrasado em relação ao banco de dados primário, eles estão no modo de espera quente. Objetos e alterações que não são capturados pelos logs de transações devem ser aplicados manualmente aos bancos de dados secundários para estabelecer uma sincronização completa sem perdas.
O SQL Server Agent automatiza o processo geral de criação, cópia e aplicação de logs de transações. O envio de logs deve ser configurado para cada banco de dados individualmente. Se um grupo de disponibilidade gerenciar mais de um banco de dados, será necessário configurar o mesmo número de processos de envio de logs.
Em caso de falha, o processo de recuperação de desastres deve ser iniciado manualmente porque não há suporte automatizado. Além disso, o acesso do cliente não é abstraído do banco de dados primário e dos bancos de dados secundários por um ouvinte. Em caso de failover, os clientes precisam ser capazes de lidar sozinhos com a mudança de função de um banco de dados da função secundária para a nova função primária, conectando-se à nova função primária após uma recuperação de desastre. É possível criar abstrações separadas independentemente das instâncias do SQL Server, por exemplo, endereços IP flutuantes, conforme descrito em Práticas recomendadas para endereços IP flutuantes .
Como o envio de logs é, em parte, um processo manual, você pode atrasar a aplicação intencional de arquivos de log copiados aos bancos de dados secundários (em contraste com grupos de disponibilidade e grupos de disponibilidade distribuídos, onde as alterações são aplicadas imediatamente). Um possível caso de uso é evitar que erros de modificação de dados no banco de dados primário sejam aplicados a bancos de dados secundários até que os erros de modificação de dados sejam resolvidos. Nesse caso, um banco de dados secundário que ainda não tenha um erro de modificação de dados aplicado poderá se tornar o banco de dados primário até que o erro de modificação de dados seja resolvido. Depois disso, o processamento normal pode ser retomado.
Como no caso de grupos de disponibilidade distribuídos, você pode usar o envio de logs para soluções de plataforma cruzada onde, por exemplo, o banco de dados primário está em execução no Linux enquanto os bancos de dados secundários estão no Linux e no Windows.
O diagrama a seguir ilustra uma implantação multiplataforma com envio de logs. Observe que não há configuração comum entre regiões, como um grupo de disponibilidade distribuído nesta topologia.
Os grupos de disponibilidade estão em regiões separadas, sendo um executado no Linux e outro no Windows.
Para obter mais informações sobre o envio de logs do SQL Server, leia Sobre o envio de logs (SQL Server) .
Combinando recursos de disponibilidade do SQL Server
Você pode implantar recursos de disponibilidade do SQL Server em diferentes combinações. Por exemplo, no caso de uso anterior, o envio de logs foi usado com diferentes grupos de disponibilidade instalados em diferentes sistemas operacionais.
A seguir está uma lista de possíveis combinações de recursos de disponibilidade do SQL Server:
- Use o envio de logs entre grupos de disponibilidade instalados no mesmo sistema operacional.
- Tenha um grupo de disponibilidade primário usando FCIs com um grupo de disponibilidade secundário que use apenas instâncias autônomas do SQL Server.
- Use um grupo de disponibilidade distribuído entre regiões próximas e envie logs entre regiões localizadas em diferentes continentes.
Estas são apenas algumas das combinações possíveis de recursos de disponibilidade do SQL Server.
A flexibilidade fornecida pelos recursos de disponibilidade do SQL Server oferece suporte ao ajuste fino de uma estratégia de recuperação de desastres de acordo com os requisitos declarados.
Replicação do SQL Server
A replicação do SQL Server geralmente não é considerada um recurso de disponibilidade, mas esta seção descreve brevemente como esse recurso pode ser usado para recuperação de desastres.
O recurso de replicação oferece suporte à criação e manutenção de réplicas de bancos de dados. Diferentes tipos de agentes do SQL Server colaboram para capturar alterações, transmitir alterações capturadas e aplicar essas alterações às réplicas. Esse processo é assíncrono e as réplicas geralmente ficam atrás do banco de dados replicado em vários graus.
Por exemplo, é possível ter uma réplica de um banco de dados de produção. Em termos de recuperação de desastres, o banco de dados de produção é o banco de dados primário e a réplica é o banco de dados secundário. O recurso de replicação do SQL Server não sabe que os bancos de dados assumem funções diferentes no contexto da recuperação de desastres. Assim, a replicação não tem operações que apoiem o processo de recuperação de desastres, por exemplo, mudanças de função. O processo de recuperação de desastres deve ser implementado separadamente da funcionalidade do SQL Server e executado pela organização que o implementa porque não há abstrações de acesso do cliente.
Envio de arquivo de backup
O envio de arquivos de backup é outra estratégia de implementação de recuperação de desastres. Uma abordagem padrão para configurar e atualizar continuamente um banco de dados secundário é fazer um backup inicial completo do banco de dados primário e depois fazer backups incrementais dele. Todos os backups incrementais são aplicados aos bancos de dados secundários na ordem correta. Há muitas variações dessa abordagem, dependendo da frequência dos backups incrementais e do local de armazenamento do arquivo de backup (local global ou realmente copiado entre locais).
Esta estratégia não envolve nenhum recurso de disponibilidade do SQL Server ao replicar alterações de estado do banco de dados primário para qualquer banco de dados secundário. Ele não usa o SQL Server Agent usado no caso de envio de logs.
Para obter mais informações, consulte a seção sobre Exemplo: estratégia de DR de backup e restauração .
Em comparação com a abordagem de replicação discutida na seção anterior, tanto a replicação quanto o envio de arquivos de backup têm em comum o fato de o processo de recuperação de desastres ser implementado fora e separado do conjunto de recursos do SQL Server. Do ponto de vista do envio de alterações capturadas, a replicação do SQL Server é mais conveniente, pois implementa essa parte automaticamente por meio de SQL Server Agents.
Nota sobre a interação entre o ciclo de vida do banco de dados e o ciclo de vida do aplicativo
Um failover de banco de dados não é totalmente separado e independente dos aplicativos que acessam o banco de dados. Em princípio, existem dois cenários de falha.
Primeiro, o aplicativo permanece operacional enquanto o banco de dados está realizando failover. Desde o momento da indisponibilidade do banco de dados primário até o momento em que o novo banco de dados primário estiver operacional, os aplicativos não poderão acessar o banco de dados. As conexões existentes falham e nenhuma nova conexão é estabelecida. Durante esse período, o aplicativo não consegue atender seus clientes, pelo menos na medida em que a funcionalidade requer acesso ao banco de dados. Os aplicativos precisam reconhecer quando o novo banco de dados primário está disponível para que possam retomar o processamento normal.
Os aplicativos podem ter estado fora do banco de dados, por exemplo, nos caches da memória principal. O aplicativo garante que o cache seja consistente (sincronizado) com o novo banco de dados primário. Se não houve nenhuma perda de transações durante o failover, o cache poderá ser consistente sem manutenção adicional. No entanto, se ocorrer perda de transação (dados) durante o failover, o cache poderá não ser consistente em relação ao novo banco de dados primário. A discussão análoga se aplica ao estado compartilhado quando, por exemplo, alguns dados no banco de dados também fazem parte de mensagens em filas ou arquivos no sistema de arquivos. Este aspecto da consistência dos dados está fora do escopo deste documento porque não está diretamente relacionado à recuperação de desastres do banco de dados.
Segundo, um ou mais aplicativos podem ficar indisponíveis ao mesmo tempo que o banco de dados primário fica indisponível. Por exemplo, se uma região ficar offline, um sistema de aplicação em execução nessa região ficará tão indisponível quanto o banco de dados primário nessa mesma região. Neste caso, o aplicativo também deve ser recuperado, não apenas o sistema de banco de dados primário. Junto com o processo de recuperação de desastres do banco de dados, você precisa iniciar um processo semelhante de recuperação de aplicativo. O aplicativo recuperado deve se conectar ao novo banco de dados primário e ser reconfigurado (por exemplo, endereços IP flutuantes). A recuperação de aplicativos está fora do escopo deste documento.
Relação entre backup e restauração para recuperação de desastres
O backup de um banco de dados é independente e ortogonal à recuperação de desastres do banco de dados. O objetivo do backup do banco de dados é ser capaz de restaurar um estado consistente, por exemplo, no caso de um banco de dados ser perdido ou corrompido, ou um estado anterior precisar ser recuperado devido a falhas ou bugs do aplicativo.
A seção a seguir discute como você pode usar backups como um mecanismo possível para implementar a recuperação de desastres do banco de dados. Neste cenário, você copia os arquivos de backup para o local do banco de dados secundário para que o banco de dados secundário possa ser restaurado. Contudo, os arquivos de backup não são um pré-requisito para a recuperação de desastres; a discussão anterior sobre os recursos de disponibilidade apresentou alternativas.
Alta disponibilidade e recuperação de desastres
Tanto a alta disponibilidade quanto a recuperação de desastres têm em comum o fato de fornecerem soluções para indisponibilidade de bancos de dados. Se um banco de dados primário ficar indisponível, um banco de dados secundário se tornará o novo banco de dados primário consistente e disponível.
A diferença entre alta disponibilidade e recuperação de desastres é o domínio do ponto único de falha. A alta disponibilidade resolve uma interrupção dentro de uma região, por exemplo, quando uma única zona falha ou um nó falha. Uma solução de alta disponibilidade fornece um novo banco de dados primário em outra zona da mesma região. Além disso, a alta disponibilidade trata de falhas de nós e não apenas de bancos de dados. Se um nó executando uma instância do SQL Server falhar, um novo nó será disponibilizado executando uma nova instância do SQL Server (consulte a discussão na seção sempre na instância do cluster de failover ).
A recuperação de desastres envolve pelo menos duas regiões. Ele aborda o caso em que toda uma região fica indisponível. A recuperação de desastres pode fornecer um novo banco de dados primário em uma região diferente.
O SQL Server Alta disponibilidade apresenta soluções de suporte para alta disponibilidade e recuperação de desastres ao mesmo tempo. Um único grupo de disponibilidade pode abranger as zonas dentro de uma região e também como regiões. Um grupo de disponibilidade pode conter instâncias de cluster de failover para lidar com alta disponibilidade.
O SQL Server pode estabelecer grupos de disponibilidade em uma região para alta disponibilidade e falhas na zona e combiná -lo com o envio de log nas regiões para abordar a recuperação de desastres.
DR alternativas de implantação
Nas seções a seguir, algumas topologias possíveis de recuperação de desastres são mostradas, além das discutidas até agora. Essas topologias satisfazem diferentes requisitos de RPO e RTO. Esta lista não é exaustiva.
DR e HA intra -regional
Essa implantação é uma variação de um grupo de disponibilidade que contém FCIs, dentro de uma região que consiste em três zonas. As zonas são consideradas o domínio de ponto único de falha nesse cenário.
Comparado à implantação mostrada anteriormente, cada FCI consiste em três nós em que cada nó está sendo executado em uma zona diferente. O benefício dessa configuração é que qualquer uma ou duas zonas pode falhar sem exigir um processo de recuperação de desastres.
O diagrama a seguir mostra essa configuração.
O FCIS abrange todas as zonas, e cada FCI possui um executando a instância do SQL Server acessando o banco de dados correspondente. Existem mais duas instâncias do SQL Server que não estão sendo executadas em cada FCI que podem ser iniciadas quando uma zona falhar. Os bancos de dados são mostrados nas zonas, pois cada banco de dados usa os discos de todos os nós em um determinado FCI. Um aplicativo não é mostrado para clareza.
Interregional DR: Regiões de abrangência do Grupo de Disponibilidade
Nesse cenário, um grupo de disponibilidade é executado em um cluster de failover do Windows Server e abrange duas regiões. As regiões são consideradas um único domínio de ponto de falha.
O diagrama a seguir ilustra essa configuração.
Para resolver possíveis problemas de latência, você pode configurar as réplicas na região R1 para usar a propagação de transações síncronas, enquanto as réplicas na região R2 são configuradas para usar a propagação de transação assíncrona.
DR inter -regional: transferência de arquivos de backup
Este cenário usa a transferência de arquivo de backup. Dois grupos de disponibilidade em duas regiões estão vinculados. Cada grupo de disponibilidade possui suas réplicas recebendo as transações de forma síncrona; portanto, as réplicas secundárias de cada região estão em uma configuração quente de espera.
O diagrama a seguir ilustra essa configuração.
No entanto, os dois grupos de disponibilidade são conectados pela transferência de arquivos de backup. O grupo de disponibilidade AG1 é o grupo de disponibilidade primário e o grupo de disponibilidade AG2 é o grupo de disponibilidade secundário. Como os arquivos de backup são disponibilizados para o grupo de disponibilidade secundário, eles são aplicados lá. Esse cenário é discutido com mais detalhes na seção a seguir, exemplo: estratégia de backup e restauração de DR .
Localização dupla e topologia de localização terciária
Se houver apenas dois bancos de dados, um banco de dados primário e um banco de dados secundário, cada um em uma região separada, haverá uma duração desprotegida após um failover a partir do momento em que o novo banco de dados primário estará em execução e o novo banco de dados secundário estará pronto. Se o novo banco de dados primário ficar indisponível enquanto o banco de dados secundário ainda não estiver em execução, ocorre um tempo de inatividade difícil que só pode ser recuperado quando um novo banco de dados primário é estabelecido. O mesmo se aplica a grupos de disponibilidade.
Um terceiro local executando outro banco de dados secundário ou grupo de disponibilidade pode eliminar a duração desprotegida após um failover. Essa configuração precisa garantir que um dos dois bancos de dados secundários permaneça um banco de dados secundário e seja reatribuído para um novo banco de dados primário para que nenhuma perda de dados ocorra. Como antes do mesmo se aplica a grupos de disponibilidade.
Dr. Lifecycle
Independentemente da solução de recuperação de desastres que você escolher, existem etapas comuns do ciclo de vida que se aplicam.
Em uma situação real de recuperação de desastres, todas as partes interessadas (proprietários de aplicativos, grupos de operações e administradores de banco de dados) precisam estar disponíveis e participam ativamente no gerenciamento da recuperação de desastres. As partes interessadas precisam decidir sobre a autoridade de decisão (às vezes chamada de mestre da cerimônia ) e os processos de decisão que seguem. Além disso, as partes interessadas precisam concordar com seus métodos de terminologia e comunicação.
Decidir sobre o início de um processo de failover
A menos que o failover seja iniciado automaticamente, as partes interessadas devem tomar a decisão de iniciar um failover. As várias partes interessadas precisam coordenar firmemente a decisão quando decidirem iniciar o failover.
Iniciar um processo de failover depende de vários fatores, principalmente a causa raiz do banco de dados primário que se torna indisponível.
Se o processo de recuperação de desastres levar mais tempo do que o tempo esperado para resolver a indisponibilidade do banco de dados da primária, um failover será prejudicial. Primeiro, você deve avaliar se a restauração do banco de dados principal for uma opção viável.
Quanto melhor a estratégia de recuperação de desastres for testada e, mais rápido é implementado, mais fácil é iniciar o processo de failover, porque menos incerteza deve ser considerada na decisão.
Execução do processo de failover
O processo de failover é idealmente testado regularmente e, portanto, bem conhecido pelas várias partes interessadas.
A autoridade de decisão deve estar ciente de todas as etapas que estão ocorrendo e de todos os problemas inesperados. A autoridade de decisão impulsiona o processo de failover e as partes interessadas são responsáveis por apoiar a autoridade de decisão.
Você deve manter as estatísticas para análise post -mortem e melhoria do processo de failover; incluindo durações de atividades, questões que surgiram e qualquer confusão nas etapas do processo de failover.
Proteção ausente
Se você tiver apenas um banco de dados secundário, a partir do momento em que o novo banco de dados primário estará disponível e operacional até que um novo banco de dados secundário seja configurado, não existe proteção de DR. Uma indisponibilidade durante esse período pode causar um tempo de inatividade difícil, porque nenhum failover para outro banco de dados é possível. Se surgir essa situação, outro banco de dados primário deve ser configurado e o RPA é o último ponto que pode ser reconstruído com base nos backups disponíveis.
A menos que a estratégia de recuperação de desastres seja configurada para que haja proteção o tempo todo, todas as partes interessadas precisam estar cientes dessa duração da falta de proteção para tomar precauções extras durante as alterações de configuração ou configuração do ambiente.
Você pode evitar esse tempo desprotegido se o acesso do aplicativo ao novo banco de dados primário estiver atrasado até que o novo banco de dados secundário esteja em funcionamento. Assim que as alterações do banco de dados primário são aplicadas, o banco de dados principal está disponível para aplicativos. Embora essa abordagem evite a qualquer momento em que os aplicativos não sejam protegidos do DR, ela atrasa a conclusão do processo de recuperação de desastres.
Evite situações de divisão cerebral
É importante que os aplicativos não possam acessar um banco de dados primário e um banco de dados secundário ao mesmo tempo, emitindo operações de DML. Nesta situação, ocorre uma inconsistência de dados em que o banco de dados primário e o banco de dados secundário discordam dos valores de dados do mesmo item de dados ( Split-Brain ). Essa arquitetura é especialmente importante se o banco de dados primário ficar indisponível enquanto continuar sendo executado e puder receber operações de gravação. Se a indisponibilidade for causada pelo particionamento intermitente da rede, o particionamento poderá parar em qualquer momento e um aplicativo poderá ter acesso novamente. Se um processo de failover estiver acontecendo naquele momento, as alterações no banco de dados primárias antigas podem ser perdidas ou alguns aplicativos começam a operar no novo banco de dados primário, enquanto outros ainda estão acessando o antigo banco de dados primário.
Todo o acesso ao aplicativo está desligado para qualquer banco de dados durante o processo de failover, para que nenhuma mudança de estado possa ocorrer em nenhum dos bancos de dados. Após o failover, apenas um banco de dados está disponível para operações de gravação - o novo banco de dados primário.
Declaração de conclusão
Após a conclusão do processo de failover, todas as partes interessadas precisam ser explicitamente informadas pela autoridade de decisão de que o processo é realizado. Qualquer problema que apareça após a conclusão precisa ser tratado como um incidente separado que não faz mais parte do processo de failover, mas parte do processamento regular. O problema pode ser uma conseqüência de um problema com o processo de failover ou um problema independente. No entanto, a abordagem de abordar o problema após a conclusão do processo de failover pode ser diferente de como ela é abordada durante a execução do processo de failover.
Análise post mortem e relatório
Para referência futura e para melhorar seu processo de failover, organize uma análise post mortem imediatamente para anotar aspectos, descobertas e itens de ação importantes.
Escreva um relatório que resume o evento de recuperação de desastres, as causas raiz e todas as ações tomadas. Este relatório pode ser obrigatório se você estiver implementando requisitos regulatórios.
Teste e verificação de DR
Como a recuperação de desastres não faz parte das operações diárias normais, sua solução de DR deve ser testada regularmente para garantir seu funcionamento adequado quando for necessário.
A frequência do teste depende dos requisitos operacionais e varia de acordo com o banco de dados, o aplicativo e a empresa. Além disso, as alterações no ambiente, como alterações de configuração de rede e atualizações de componentes de infraestrutura, devem acionar um teste de recuperação de desastres se as alterações forem feitas nos sistemas em que a solução de recuperação de desastres escolhida depende. Qualquer alteração pode fazer com que a solução de recuperação de desastres falhe ou pode exigir o ajuste do processo de recuperação de desastres.
Você pode testar manualmente iniciando o processo de alternância ou automaticamente seguindo uma abordagem de engenharia do caos, conforme descrito na engenharia do caos . Com os testes manuais, você pode minimizar o impacto nos negócios, caso seja esperado o tempo de inatividade.
Um aspecto importante para o teste é a coleta de estatísticas bem definidas. Algumas estatísticas importantes a considerar são as seguintes:
- Tempo de recuperação Real : meça o tempo de recuperação real e compare -o com a RTO.
- Ponto de recuperação Real : observe o ponto real de recuperação e compare -o com o RPO.
- Hora de detecção de falhas: o tempo necessário para os DBAs ou a equipe de operações realizarem a necessidade de failover.
- Hora de iniciar a recuperação: o tempo necessário para iniciar o processo de failover após a falha foi detectada.
- Confiabilidade: quão intimamente o processo de failover foi seguido ou foram necessários desvios a partir dele? Surgiram questões inesperadas que precisam ser investigadas, possivelmente resultando em uma mudança de estratégia de recuperação?
Com base nas estatísticas coletadas, o processo de failover pode ter que ser ajustado ou aprimorado para corresponder melhor às expectativas RPO e RTO.
Exemplo: estratégia de backup e restauração
As seções a seguir descrevem um exemplo de estratégia de recuperação de desastres de backup e restauração. Esse cenário minimiza o uso dos recursos de disponibilidade do SQL Server, a fim de demonstrar o esforço necessário para especificar uma estratégia de backup e restauração de DR e discutir aspectos invisíveis em configurações mais automatizadas.
Caso de uso
Um grupo primário sempre no grupo de disponibilidade está localizado e operacional na região R1. O secundário sempre no grupo de disponibilidade é adicionado na Região R2 para proteção cruzada adicional e disponível como failover ou alvo de alternância.
Estratégia
A estratégia de recuperação de desastres é baseada em backups de banco de dados. Um backup completo inicial é realizado seguido por backups diferenciais subsequentes. Os backups são aplicados ao secundário sempre no grupo de disponibilidade à medida que são levados. Todos os backups são armazenados em um balde de armazenamento em nuvem.
Neste exemplo, é aceitável após a conclusão do failover que o novo grupo de disponibilidade do novo primário no R2 está ativo e desprotegido por um tempo limitado até que o novo secundário sempre no grupo de disponibilidade no R1 esteja operacional.
Nenhum fallback deve ocorrer, pois o Grupo de Disponibilidade Always On em cada uma das regiões é igualmente qualificado para servir como uma produção sempre no grupo de disponibilidade.
RTO e RPO
O RPO é definido neste exemplo como no máximo 60 minutos, portanto, um backup diferencial é retirado a cada 60 minutos.
A RTO não é definida explicitamente como duração do tempo, mas deve ser o mais mínimo possível - imediato é o melhor caso. O grupo de disponibilidade secundário deve ser configurado como um modo de espera quente. No caso de um modo de espera quente, todos os backups são aplicados imediatamente para que o failover não tenha atrasado a aplicação de backups.
Estratégia de DR de alto nível
As seções a seguir descrevem a estratégia de DR. É mantido brevemente se concentrar nas etapas essenciais.
Configuração inicial
- Crie sempre o secundário no Grupo de Disponibilidade na Região R2.
- Evite o acesso a aplicativos ao grupo de disponibilidade secundária para que nenhuma situação cerebral dividida possa ocorrer acidentalmente.
- Crie o balde de arquivo de backup B1 no armazenamento em nuvem para conter o backup completo inicial do Grupo de Disponibilidade Sempre no R1 e os backups diferenciais subsequentes de hora de sempre no grupo de disponibilidade no R1. A ordem correta dos backups diferenciais deve ser estabelecida para que o processo que aplique os backups ao grupo de disponibilidade secundário possa inferir a ordem correta. Uma abordagem pode ser uma convenção de nomenclatura que permite estabelecer a ordem cronológica correta com base na data e hora que fazem parte dos vários nomes de arquivos.
Lançar estratégia
- Aplique o backup completo ao secundário sempre no grupo de disponibilidade na região R2.
- À medida que os backups diferenciais estiverem disponíveis, aplique -os imediatamente ao secundário sempre no grupo de disponibilidade no R2. A aplicação imediata é necessária para abordar o RTO.
- Após o backup completo inicial e todos os backups incrementais são aplicados, o secundário sempre no grupo de disponibilidade está pronto.
- Teste a estratégia de DR, executando uma mudança do grupo de disponibilidade primária para o grupo de disponibilidade secundário. Pelo menos um backup incremental deve estar disponível durante o teste.
Capa de failover ou alternância
Em R2, as etapas essenciais são as seguintes:
- Verifique se o backup diferencial mais recente foi aplicado ao secundário sempre no grupo de disponibilidade no R2.
- Designe R2 como o novo primário sempre no grupo de disponibilidade.
- Crie um novo balde B2, faça um backup completo como linha de base e abra o novo grupo de disponibilidade primário para acesso ao aplicativo.
- Comece a fazer backups diferenciais.
Em R1, as etapas essenciais são as seguintes:
- Remova o balde B1 porque não é mais necessário.
- Quando o Grupo de Disponibilidade Sempre no R1 está disponível novamente (como um novo secundário sempre no grupo de disponibilidade), evite o acesso ao aplicativo e remova todos os dados do banco de dados ou redefini -los para seu estado inicial (vazio) (a menos que tivesse que ser criado recém).
- Aplique o backup completo do novo Grupo de Disponibilidade Primária sempre no R2 e continue aplicando backups diferenciais imediatamente à medida que estiverem disponíveis (armazenados no balde B2).
Possíveis melhorias
Uma possível melhoria para a estratégia de DR é evitar fazer um backup completo após um failover ou mudar, enquanto ainda é capaz de configurar rapidamente o novo grupo de disponibilidade secundária. Em vez de um único backup completo e backups diferenciais subsequentes, faça um backup completo toda semana e crie um balde semanal que contém o backup completo da semana e todos os backups diferenciais subsequentes para aquela semana. O novo grupo de disponibilidade primário precisa criar backups diferenciais somente após o failover (e não um backup completo) e adicioná -los ao balde. O novo grupo de disponibilidade secundário simplesmente aplica todos os backups no balde da semana atual. Se esta abordagem semanal for usada, você precisará implementar uma estratégia de limpeza ou purga para remover backups obsoletos.
Outra melhoria é baseada no fato de que o novo grupo de disponibilidade secundário foi o antigo grupo de disponibilidade primária. Se o banco de dados existir e estiver operacional depois de estar disponível novamente, uma recuperação de tempo para o seu último backup diferencial evitará restaurá -lo completamente do último backup completo, conforme descrito na restauração de um banco de dados do SQL Server até um ponto no tempo (modelo de recuperação completa) . Esse cenário reduz o esforço e a quantidade de tempo em que o novo grupo de disponibilidade primária não está protegido.
Práticas recomendadas de produção
Esta solução não especifica se as instâncias do SQL Server nos grupos sempre de disponibilidade são instâncias independentes ou FCI. O tipo de instâncias usadas precisa ser decidido antes da implementação.
Até que um novo secundário sempre no grupo de disponibilidade esteja operacional após um failover, há um tempo em que o DR não está protegido. Você deve configurar um terceiro sempre no grupo de disponibilidade em uma terceira região.
Além disso, você deve implementar o monitoramento para garantir que qualquer falha ou erro seja detectado. O monitoramento está fora do escopo deste documento, mas é essencial para uma solução de recuperação de desastres em funcionamento.
O que vem a seguir
- Configurando o SQL Server sempre em grupos de disponibilidade .
- Implantando um SQL Server 2016 multi-sub-sub-substituto sempre no grupo de disponibilidade no mecanismo de computação .
- Configurando instâncias de cluster de failover do SQL Server .
- Executando o cluster de failover do Windows Server .
- Como ativar o registro da nuvem, o monitoramento da nuvem e os relatórios de erros para aplicativos .NET
- Instalando o agente de monitoramento da nuvem .
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Dê uma olhada em nosso Centro de Arquitetura de Nuvem .