Este documento apresenta estratégias de recuperação de desastres (RD) para o Microsoft SQL Server para arquitetos e responsáveis técnicos responsáveis por conceber e implementar a recuperação de desastres no Google Cloud.
As bases de dados podem ficar indisponíveis por vários motivos, por exemplo, falhas de hardware ou de rede. Para fornecer acesso contínuo à base de dados durante falhas, é mantida uma base de dados secundária que é uma réplica de uma base de dados primária. Ter a base de dados secundária numa localização diferente aumenta as probabilidades de estar disponível quando a base de dados principal ficar indisponível.
Se a base de dados principal ficar indisponível, a sua app de serviço crítico liga-se a uma base de dados secundária, continuando a partir do estado de dados consistente conhecido mais recentemente para fornecer serviços aos seus utilizadores com uma inatividade mínima ou nula.
O processo de disponibilização de uma base de dados secundária em caso de falha da base de dados principal chama-se recuperação de desastres (RD) da base de dados. A base de dados secundária recupera da indisponibilidade da base de dados principal. Idealmente, a base de dados secundária tem exatamente o mesmo estado consistente que a base de dados principal quando está indisponível ou perde apenas um conjunto mínimo de transações recentes da base de dados principal.
A DR de bases de dados é uma funcionalidade essencial para os clientes empresariais. O principal fator é a continuidade de negócio para apps críticas. Por exemplo, uma app de missão crítica gera receita (comércio eletrónico), oferece serviços fiáveis contínuos (gestão de voos ou centrais elétricas) ou suporta funcionalidades de preservação da vida (monitorização de pacientes). Em todos estes exemplos, é de extrema importância que a app esteja continuamente disponível porque é considerada essencial para a missão.
A maioria dos sistemas de gestão de bases de dados oferece funcionalidade de recuperação de desastres, incluindo o Microsoft SQL Server. Este documento de arquitetura aborda a forma como as funcionalidades de DR fornecidas pelo SQL Server são implementadas no contexto do Google Cloud.
Terminologia
As secções seguintes explicam os termos usados ao longo deste documento.
Arquitetura de DR geral
O diagrama seguinte ilustra a topologia geral da arquitetura de DR.
No diagrama anterior, uma app acede a uma base de dados principal enquanto uma base de dados secundária está em espera e reflete o estado da base de dados principal. Os clientes estão a aceder à app que é executada no dispositivo Google Cloud.
Se a base de dados principal ficar indisponível, os administradores da base de dados ou a equipa de operações têm de decidir iniciar o processo de recuperação de desastres. Se for iniciada a recuperação de desastres da base de dados, a app é religada à base de dados secundária. Depois de estar ligada, a app pode voltar a apresentar anúncios aos respetivos clientes. Numa situação ideal, a app está disponível na base de dados secundária o mais rapidamente possível, para que os clientes possam nem sequer sentir uma indisponibilidade. Uma alternativa é aguardar que a base de dados principal volte a ficar acessível, em vez de iniciar a recuperação de desastres. Por exemplo, se a falha for intermitente, pode ser mais rápido resolver o problema em vez de fazer a comutação por falha.
Bases de dados principal e secundária
Uma base de dados principal é acedida por uma ou mais apps para fornecer serviços de persistência para a gestão do estado da app. Uma base de dados secundária está relacionada com uma base de dados principal e contém uma réplica da base de dados principal. Idealmente, o conteúdo da base de dados secundária corresponde exatamente ao conteúdo da base de dados principal em qualquer momento. Em muitos casos, a base de dados secundária fica atrás da base de dados principal devido a atrasos na aplicação de alterações transacionais feitas na base de dados principal. É possível associar mais do que uma base de dados secundária a uma base de dados principal, consoante a tecnologia de base de dados. O SQL Server suporta a associação de mais de uma base de dados secundária a uma base de dados principal.
Recuperação de desastres
Se uma base de dados principal ficar indisponível, a recuperação de desastres altera a função da base de dados secundária para se tornar a base de dados principal. Se existir mais do que uma base de dados secundária, uma dessas bases de dados é selecionada manualmente ou com base numa lista de alternativa preferencial. As apps têm de voltar a ligar-se à nova base de dados principal para continuar a aceder ao respetivo estado. Se a nova base de dados principal não estiver sincronizada com o estado conhecido mais recente da base de dados principal anterior, a app é iniciada a partir de um estado anterior (também conhecido como reversão).
É importante ter, pelo menos, uma base de dados secundária em todos os momentos para cada base de dados principal. Após uma recuperação de desastres, certifique-se de que é configurada uma nova base de dados secundária para processar futuros cenários de recuperação de desastres.
Comutação por falha, comutação e alternativa
Existem vários cenários para alterar a função entre bases de dados primárias e secundárias:
- Ativação pós-falha: o processo de alterar a função de uma base de dados secundária para ser a nova base de dados principal e associar todas as apps a esta. A comutação por falha é não intencional porque é acionada quando uma base de dados principal fica indisponível. Pode configurar a comutação por falha para ser acionada automaticamente ou manualmente.
- Comutação: ao contrário da comutação por falha, uma comutação de uma base de dados principal para uma base de dados secundária (nova base de dados principal) é acionada intencionalmente para testes iniciais e manutenção agendada. Teste o seu sistema de recuperação de desastres com uma comutação periódica regular para garantir a fiabilidade contínua da recuperação de desastres.
- Recuperação: a recuperação inverte o processo em que a nova base de dados principal se torna a base de dados secundária, após a reparação da base de dados principal. É acionado intencionalmente um fallback para restabelecer o estado antes de o failover ou a comutação serem iniciados. Não é estritamente necessário, mas pode ser feito com base nos requisitos de recuperação de desastres, como a localidade ou os recursos disponíveis.
Google Cloud zonas e regiões
Os recursos, como bases de dados, estão localizados em Google Cloud zonas e regiões, em que cada zona pertence a uma região. Uma zona é um domínio de ponto único de falha. Recomendamos a implementação de um recurso com alta disponibilidade e tolerância a falhas em várias zonas numa região.
Para se proteger contra a indisponibilidade de uma região inteira, estabeleça estratégias multirregionais para recuperação de desastres. Por exemplo, a base de dados principal está localizada numa região e a respetiva base de dados secundária correspondente está localizada noutra região.
Modos ativos: ativo-passivo e ativo-ativo
Uma base de dados principal é uma base de dados aberta para operações de leitura e escrita (operações DML) para que as apps que acedem à mesma possam gerir o respetivo estado. A base de dados principal é denominada base de dados ativa. A base de dados secundária correspondente é passiva porque replica a base de dados principal, mas não está disponível para nenhuma app para operações de alteração de estado. Após uma comutação por falha ou uma comutação, a base de dados secundária torna-se a nova base de dados principal e torna-se uma base de dados ativa.
A base de dados principal e a base de dados secundária podem ser bases de dados ativas se a tecnologia de base de dados suportar esta funcionalidade, denominada modo ativo-ativo. Neste caso, as apps podem estabelecer ligação a uma ou outra porque ambas as bases de dados estão disponíveis para a gestão de estados. A recuperação de desastres no modo ativo-ativo não requer uma comutação por falha se apenas uma das bases de dados ativas ficar indisponível. Se uma base de dados ativa estiver indisponível, a outra base de dados ativa continua a estar disponível. O modo ativo-ativo está fora do âmbito deste artigo porque o SQL Server não suporta este modo.
Modos de espera: quente, morno, frio e sem espera
Para que a base de dados principal seja a base de dados ativa, tem de estar em execução e ser capaz de executar declarações DML. Não é necessário que a base de dados secundária esteja em execução. Pode ser encerrada. Se não estiver em execução, o tempo necessário para recuperar de um desastre aumenta porque a nova base de dados principal tem de ser colocada em estado de execução primeiro, antes de assumir a função da nova base de dados principal.
Existem várias variações sobre como configurar a base de dados secundária:
- Hot standby: a base de dados secundária está em funcionamento e pronta para ser ligada pelos clientes. A alteração mais recente disponível na base de dados principal é sempre aplicada assim que fica disponível.
- Standby a quente: uma base de dados secundária está em funcionamento, mas nem todas as alterações da base de dados principal foram necessariamente aplicadas.
- Standby a frio: uma base de dados secundária não está em execução. Primeiro, tem de ser iniciado e, em seguida, sincronizado com o estado mais recente disponível.
- Sem modo de espera: o software da base de dados tem de ser instalado primeiro e, posteriormente, iniciado antes de todas as alterações da base de dados principal serem aplicadas. Este modo é o mais económico porque não consome recursos quando não são necessários, mas, em comparação com os outros modos, demora mais tempo a tornar-se uma nova base de dados principal.
Estratégias de RD
Nas secções seguintes, são explicadas as estratégias de recuperação de desastres suportadas pelo Microsoft SQL Server.
Dimensões da estratégia de recuperação
Existem várias dimensões importantes a ter em conta quando seleciona ou implementa uma estratégia de recuperação de desastres de base de dados. Cada dimensão tem um espetro e o comportamento e as expetativas da estratégia de recuperação de desastres dependem da seleção dos pontos no espetro. As principais dimensões são as seguintes:
- Objetivo de ponto de recuperação (OPR): O período máximo aceitável durante o qual os dados podem ser perdidos da sua app devido a um incidente grave. Esta dimensão varia com base nas formas como os dados são usados. O RPO pode ser expresso em duração (segundos, minutos ou horas) a partir do momento da indisponibilidade da base de dados principal ou pode ser expresso como estados de processamento identificáveis (última cópia de segurança completa ou última cópia de segurança incremental). Independentemente da forma como o RPO é especificado, a estratégia de recuperação de desastres tem de implementar a medida específica para que o requisito de RPO possa ser cumprido. O caso mais exigente é a última transação confirmada, o que significa que não pode ocorrer qualquer perda da base de dados principal para a base de dados secundária.
- Objetivo de tempo de recuperação (OTR). O período máximo aceitável durante o qual a sua app pode estar offline. Normalmente, este valor é especificado como parte de um contrato de nível de serviço mais amplo. Normalmente, o RTO é expresso em termos de duração a partir do momento da indisponibilidade da base de dados principal. Por exemplo, a app tem de estar totalmente operacional no prazo de 5 minutos. O caso mais exigente é o imediato, para que os utilizadores da app não reparem que ocorreu uma recuperação de desastres.
- Domínio de ponto único de falha. Cabe-lhe a si decidir se uma região é considerada um domínio de ponto único de falha para os seus requisitos de recuperação de desastres. Se uma região for um único ponto de domínio de falhas para si, a recuperação de desastres tem de ser configurada de modo que duas ou mais regiões estejam envolvidas na configuração real. Se a região que contém a base de dados principal falhar, a base de dados secundária numa região diferente torna-se a nova base de dados principal. Se o domínio de ponto único de falha for considerado uma zona, a recuperação de desastres pode ser configurada em várias zonas numa única região. Se uma zona falhar, a recuperação de desastres usa uma segunda zona e disponibiliza a nova base de dados principal na mesma.
A decisão sobre estas dimensões principais é uma decisão entre o custo e a qualidade. Quanto mais baixos forem o RTO e o RPO, mais dispendiosa pode tornar-se a solução de recuperação de desastres, uma vez que são usados mais recursos ativos. Nas secções seguintes, são abordadas várias estratégias de recuperação de desastres alternativas que representam pontos nas dimensões no contexto da base de dados do Microsoft SQL Server.
Estratégias de recuperação de desastres para o SQL Server
O artigo Continuidade da empresa e recuperação de bases de dados – SQL Server descreve as funcionalidades de disponibilidade que pode usar para implementar estratégias de recuperação de desastres.
Preliminares
O SQL Server é executado no Windows e no Linux. No entanto, nem todas as funcionalidades de disponibilidade estão disponíveis no Linux. O SQL Server tem várias edições, mas nem todas as funcionalidades de disponibilidade estão disponíveis em todas as edições.
O SQL Server distingue as instâncias das bases de dados. Uma instância é o software SQL Server em execução, enquanto uma base de dados é o conjunto de dados gerido por uma instância do SQL Server.
Grupos de disponibilidade Always On
Os grupos de disponibilidade Always On oferecem proteção ao nível da base de dados. Um grupo de disponibilidade tem duas ou mais réplicas. Uma réplica é a réplica principal com acesso de leitura e escrita, e as restantes réplicas são réplicas secundárias que podem fornecer acesso de leitura. Cada réplica da base de dados é gerida por uma instância do SQL Server autónoma. Um grupo de disponibilidade pode conter uma ou mais bases de dados. O número de bases de dados que podem ser incluídas num grupo de disponibilidade e o número de réplicas secundárias suportadas dependem da edição do SQL Server. Todas as bases de dados num grupo de disponibilidade sofrem as mesmas alterações de ciclo de vida ao mesmo tempo. Os grupos de disponibilidade implementam o modo ativo-passivo porque apenas a base de dados principal suporta o acesso de escrita.
Quando ocorre uma comutação por falha, uma réplica secundária torna-se a nova réplica principal. Uma vez que um grupo de disponibilidade inclui instâncias autónomas do SQL Server, todas as operações captadas nos registos de transações estão disponíveis nas réplicas. Qualquer alteração não capturada num registo de transações tem de ser sincronizada manualmente, por exemplo, inícios de sessão ao nível da instância do SQL Server ou tarefas do SQL Server Agent. Para oferecer proteção ao nível da base de dados e proteção da instância do SQL Server, tem de configurar instâncias de cluster de comutação por falha (FCIs). Esta arquitetura de implementação é abordada mais adiante na secção Instância de cluster de comutação por falha sempre ativa.
Pode proteger as apps contra alterações de funções através de um ouvinte. Um ouvinte suporta apps que se ligam ao grupo de disponibilidade. As apps não sabem que instâncias do SQL Server estão a gerir a base de dados principal ou as réplicas secundárias em qualquer momento. Os ouvintes requerem que os clientes usem uma versão mínima do .NET de 3.5 com uma atualização ou 4.0 e superior, conforme descrito em Continuidade da empresa e recuperação da base de dados – SQL Server.
Os grupos de disponibilidade baseiam-se em camadas subjacentes de abstração para fornecer a respetiva funcionalidade. Os grupos de disponibilidade são executados num cluster de failover do Windows Server (WSFC), conforme descrito em Clustering de failover do Windows Server com o SQL Server. Todos os nós que executam instâncias do SQL Server têm de fazer parte do mesmo WSFC.
As transações são enviadas da base de dados principal para todas as réplicas secundárias. Existem dois modos de envio de transações: síncrono e assíncrono. Pode configurar cada réplica de forma independente para usar um ou outro modo. No modo de envio síncrono, a transação na base de dados principal só é bem-sucedida se for bem-sucedida em todas as réplicas secundárias que estão sincronizadas. No modo assíncrono, a transação na base de dados principal pode ter êxito, mesmo que nem todas as réplicas secundárias tenham a transação aplicada.
A sua escolha do modo de envio influencia o RTO, o RPO e o modo de espera possíveis. Por exemplo, se as transações forem enviadas para todas as réplicas no modo síncrono, todas as réplicas estão exatamente no mesmo estado. O RPO mais exigente (transação mais recente) é cumprido, uma vez que todas as réplicas estão totalmente sincronizadas. As réplicas secundárias são reservas ativas, pelo que qualquer uma delas pode ser usada imediatamente como base de dados principal.
A comutação por falha pode ser automática ou manual. Uma comutação automática por falha é possível se todas as réplicas estiverem totalmente sincronizadas. No exemplo anterior, isto é possível porque todas as réplicas estão sempre totalmente sincronizadas.
A figura seguinte mostra um grupo de disponibilidade Always On numa única região.
O grupo de disponibilidade é representado como um retângulo que abrange zonas. Isto destina-se apenas a fins ilustrativos para indicar que todas as bases de dados pertencem ao mesmo grupo de disponibilidade. O grupo de disponibilidade não é um recurso da nuvem e, como tal, não está implementado num nó nem em qualquer outro tipo de recurso.
Instância de cluster de failover Always On
Para se proteger contra falhas de nós, pode usar instâncias de cluster de comutação por falha (FCIs) em vez de instâncias autónomas do SQL Server. Existem dois ou mais nós que executam instâncias do SQL Server para gerir uma base de dados (principal ou secundária). Os nós que gerem uma base de dados formam um cluster de ativação pós-falha. Um nó no cluster está a executar ativamente uma instância do SQL Server, enquanto os outros nós não estão a executar 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 a gestão da base de dados (failover do nó). Este processo de iniciar automaticamente uma instância do SQL Server oferece funcionalidade de alta disponibilidade.
O cluster FCI aparece como uma única unidade e os clientes que acedem ao cluster não veem a comutação por falha entre nós, exceto talvez durante um curto período de indisponibilidade. Não há perda de dados quando ocorre uma ativação pós-falha de um nó. Tudo o que estiver a ser executado na instância do SQL Server com falhas é movido para outra instância do SQL Server no mesmo cluster. Por exemplo, as tarefas do SQL Server Agent ou os servidores associados são movidos para outra instância.
Os nós do cluster FCI podem ser configurados em diferentes Google Cloud zonas. Esta arquitetura não só oferece elevada disponibilidade em caso de falha do nó, como também em caso de falhas de zona. É abordada uma implementação de exemplo desta estratégia na secção de alternativas de implementação de DR.
Embora diferentes nós geram a mesma base de dados e partilhem a base de dados, não é necessário um armazenamento comum entre os nós de um cluster de FCI. O SQL Server usa a funcionalidade Storage Spaces Direct (S2D) para gerir bases de dados em discos de nós dedicados. Para mais informações, consulte o artigo Configurar instâncias de cluster de comutação por falha do SQL Server.
O exemplo da secção anterior Grupos de disponibilidade Always On com FCIs em vez de instâncias autónomas do SQL Server é apresentado na figura seguinte. Cada FCI tem uma instância do SQL Server ativa que gere a base de dados.
Tal como no caso do grupo de disponibilidade, um FCI é representado como um retângulo. Isto é apenas para fins ilustrativos, para indicar que todos os nós pertencem ao mesmo FCI. Um FCI não é um recurso da nuvem e, como tal, não é implementado num nó nem em qualquer outro tipo de recurso.
Para uma discussão mais detalhada, consulte o artigo 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 com a função de grupo de disponibilidade principal e outro com a função de 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 principal para o grupo de disponibilidade secundário.
Embora cada um dos grupos de disponibilidade tenha a sua própria base de dados principal, esta não é uma implementação ativa-ativa. Apenas a base de dados principal do grupo de disponibilidade principal pode receber operações de escrita. A base de dados principal do grupo de disponibilidade secundário é denominada encaminhador. O encaminhador recebe as transações do grupo de disponibilidade principal e encaminha-as para as bases de dados secundárias do grupo de disponibilidade secundário. Uma comutação por falha do grupo de disponibilidade principal para o grupo de disponibilidade secundário tornaria a base de dados principal do novo grupo de disponibilidade principal acessível para operações de escrita.
Os grupos de disponibilidade principal e secundário não têm de estar na mesma localização e não têm de estar no mesmo sistema operativo. No entanto, cada grupo de disponibilidade tem de ter um ouvinte instalado. O 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. Toda a funcionalidade necessária para fazer com que os grupos de disponibilidade distribuídos funcionem está contida na funcionalidade do SQL Server e não requer 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 é uma topologia de ligação em série de um grupo de disponibilidade a outro grupo de disponibilidade em várias localizações. Outra topologia é uma topologia semelhante a uma árvore em que o grupo de disponibilidade principal 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 vários sistemas operativos. Por exemplo, o grupo de disponibilidade principal pode ser configurado no Windows e um segundo grupo de disponibilidade correspondente no Linux, com ambos os grupos de disponibilidade a formarem um grupo de disponibilidade distribuído.
O diagrama seguinte mostra dois grupos de disponibilidade que fazem parte de um grupo de disponibilidade distribuído.
O grupo de disponibilidade 1 é o grupo de disponibilidade principal e o grupo de disponibilidade 2 é o grupo de disponibilidade secundário.
Tal como no caso dos FCIs, um grupo de disponibilidade distribuído é representado como um retângulo. Isto destina-se apenas a fins ilustrativos para indicar que os grupos de disponibilidade pertencem todos 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 num nó nem em qualquer outro tipo de recurso.
Para mais informações, consulte o artigo Grupos de disponibilidade distribuídos.
Envio de registos
O envio de registos de transações é uma funcionalidade 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 no estado entre uma base de dados principal e a respetiva base de dados secundária é significativamente maior. A discrepância é maior em termos de estado porque um ficheiro de registo de transações contém muitas alterações de estado. A discrepância também é maior em termos de tempo de atraso, porque os ficheiros de registo de transações são transportados de forma assíncrona e têm de ser aplicados na sua totalidade a uma base de dados secundária.
Os ficheiros de registo de transações são criados pela base de dados principal e têm uma cópia de segurança, por exemplo, no Cloud Storage. Cada ficheiro de registo de transações é copiado para cada base de dados secundária e aplicado à mesma. Uma vez que a base de dados secundária está atrasada em relação à base de dados principal, encontra-se no modo de espera ativa. Os objetos e as alterações que não são captados pelos registos de transações têm de ser aplicados manualmente às bases de dados secundárias 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 registos de transações. O envio de registos tem de ser configurado para cada base de dados individualmente. Se um grupo de disponibilidade gerir mais do que uma base de dados, têm de ser configurados tantos processos de envio de registos quantos forem necessários.
Em caso de falha, o processo de recuperação de desastres tem de ser iniciado manualmente, uma vez que não existe apoio técnico automatizado. Além disso, o acesso do cliente não é abstraído da base de dados principal e das bases de dados secundárias por um ouvinte. Em caso de failover, os clientes têm de conseguir lidar com a alteração da função de uma base de dados da função secundária para a nova função principal por si próprios, estabelecendo ligação à nova função principal após uma recuperação de desastres. É possível criar abstrações separadas independentemente das instâncias do SQL Server, por exemplo, endereços IP flutuantes, conforme descrito nas práticas recomendadas para endereços IP flutuantes.
Uma vez que o envio de registos é, em parte, um processo manual, pode atrasar intencionalmente a aplicação de ficheiros de registo copiados às bases de dados secundárias (ao contrário dos grupos de disponibilidade e dos grupos de disponibilidade distribuídos, em que as alterações são aplicadas imediatamente). Um possível exemplo de utilização é impedir que os erros de modificação de dados na base de dados principal sejam aplicados às bases de dados secundárias até que os erros de modificação de dados sejam resolvidos. Neste caso, uma base de dados secundária à qual ainda não tenha sido aplicado um erro de modificação de dados pode tornar-se a base de dados principal até que o erro de modificação de dados seja resolvido. Depois, o processamento normal pode ser retomado.
Tal como no caso dos grupos de disponibilidade distribuídos, pode usar o envio de registos para soluções multiplataforma em que, por exemplo, a base de dados principal está a ser executada no Linux, enquanto as bases de dados secundárias estão no Linux e no Windows.
O diagrama seguinte ilustra uma implementação multiplataforma com envio de registos. Tenha em atenção que não existe uma configuração comum nas regiões, como um grupo de disponibilidade distribuído nesta topologia.
Os grupos de disponibilidade estão em regiões separadas, com um a ser executado no Linux e o outro no Windows.
Para mais informações sobre o envio de registos do SQL Server, leia o artigo Acerca do envio de registos (SQL Server).
Combinar funcionalidades de disponibilidade do SQL Server
Pode implementar funcionalidades de disponibilidade do SQL Server em diferentes combinações. Por exemplo, no exemplo de utilização anterior, o envio de registos foi usado com diferentes grupos de disponibilidade instalados em diferentes sistemas operativos.
Segue-se uma lista de possíveis combinações de funcionalidades de disponibilidade do servidor SQL:
- Use o envio de registos entre grupos de disponibilidade instalados no mesmo sistema operativo.
- Ter um grupo de disponibilidade principal que use 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 registe o envio entre regiões localizadas em continentes diferentes.
Estas são apenas algumas das combinações possíveis de funcionalidades de disponibilidade do SQL Server.
A flexibilidade que as funcionalidades de disponibilidade do SQL Server oferecem permite a otimização precisa de uma estratégia de recuperação de desastres de acordo com os requisitos indicados.
Replicação do SQL Server
Geralmente, a replicação do SQL Server não é considerada uma funcionalidade de disponibilidade, mas esta secção descreve brevemente como esta funcionalidade pode ser usada para recuperação de desastres.
A funcionalidade de replicação suporta a criação e a manutenção de réplicas de bases de dados. Os diferentes tipos de agentes do SQL Server colaboram para captar alterações, transmitir alterações captadas e aplicar essas alterações às réplicas. Este processo é assíncrono e as réplicas ficam normalmente atrás da base de dados de replicação em vários graus.
Por exemplo, é possível ter uma réplica de uma base de dados de produção. Em termos de recuperação de desastres, a base de dados de produção é a base de dados principal e a réplica é a base de dados secundária. A funcionalidade de replicação do SQL Server não sabe que as bases de dados assumem funções diferentes no contexto da recuperação de desastres. Por conseguinte, a replicação não tem operações que suportem o processo de recuperação de desastres, por exemplo, alterações de funções. O processo de recuperação de desastres tem de ser implementado separadamente da funcionalidade do SQL Server e executado pela organização que o implementa, uma vez que não existem abstrações de acesso do cliente.
Envio de ficheiros de cópia de segurança
O envio de ficheiros de cópia de segurança é outra estratégia de implementação de recuperação de desastres. Uma abordagem padrão para configurar e atualizar continuamente uma base de dados secundária consiste em fazer uma cópia de segurança completa inicial da base de dados principal e, posteriormente, cópias de segurança incrementais da mesma. Todos as cópias de segurança incrementais são aplicadas às bases de dados secundárias pela ordem correta. Existem muitas variações desta abordagem, consoante a frequência das cópias de segurança incrementais e a localização de armazenamento dos ficheiros de cópia de segurança (localização global ou efetivamente copiados entre localizações).
Esta estratégia não envolve nenhuma funcionalidade de disponibilidade do SQL Server quando replica alterações de estado da base de dados principal para qualquer base de dados secundária. Não usa o SQL Server Agent que é usado no caso do envio de registos.
Para mais informações, consulte a secção sobre o Exemplo: estratégia de recuperação de desastres de cópia de segurança e restauro.
Em comparação com a abordagem de replicação abordada na secção anterior, a replicação e o envio de ficheiros de cópia de segurança têm em comum o facto de o processo de recuperação de desastres ser implementado fora e separado do conjunto de funcionalidades do SQL Server. Do ponto de vista do envio de alterações capturadas, a replicação do SQL Server é mais conveniente, uma vez que implementa esta parte automaticamente através de agentes do SQL Server.
Nota sobre a interação entre o ciclo de vida da base de dados e o ciclo de vida da app
Uma comutação por falha da base de dados não é totalmente separada e independente das apps que acedem à base de dados. Em princípio, existem dois cenários de falha.
Primeiro, a app mantém-se operacional enquanto a base de dados está a falhar. Desde o momento em que a base de dados principal fica indisponível até ao momento em que a nova base de dados principal fica operacional, as apps não conseguem aceder à base de dados. As ligações existentes falham e não são estabelecidas novas ligações. Durante este período, a app não consegue publicar anúncios para os respetivos clientes, pelo menos, na medida em que a funcionalidade requer acesso à base de dados. As apps têm de reconhecer quando a nova base de dados principal está disponível para poderem retomar o processamento normal.
As apps podem ter um estado fora da base de dados, por exemplo, em caches da memória principal. A app garante que a cache é consistente (sincronizada) com a nova base de dados principal. Se não houve perda de transações durante a comutação por falha, a cache pode ser consistente sem manutenção adicional. No entanto, se ocorrer uma perda de transações (dados) durante a comutação por falha, a cache pode não ser consistente em relação à nova base de dados principal. A discussão análoga aplica-se ao estado partilhado quando, por exemplo, alguns dos dados na base de dados também fazem parte de mensagens em filas ou ficheiros no sistema de ficheiros. Este aspeto da consistência dos dados está fora do âmbito deste documento porque não está diretamente relacionado com a recuperação de desastres da base de dados.
Em segundo lugar, uma ou mais apps podem ficar indisponíveis ao mesmo tempo que a base de dados principal fica indisponível. Por exemplo, se uma região ficar offline, um sistema de aplicação em execução nessa região fica tão indisponível quanto a base de dados principal nessa mesma região. Neste caso, a app também tem de ser recuperada e não apenas o sistema de base de dados principal. Juntamente com o processo de recuperação de desastres da base de dados, tem de iniciar um processo de recuperação de apps semelhante. A app recuperada tem de se ligar à nova base de dados principal e ser reconfigurada (por exemplo, endereços IP flutuantes). A recuperação de apps está fora do âmbito deste documento.
Relação entre a cópia de segurança e o restauro com a recuperação de desastres
Fazer uma cópia de segurança de uma base de dados é independente e ortogonal à recuperação de desastres da base de dados. O objetivo da cópia de segurança da base de dados é poder restaurar um estado consistente, por exemplo, caso uma base de dados seja perdida ou fique danificada, ou um estado anterior tenha de ser recuperado devido a falhas ou erros da app.
A secção seguinte aborda como pode usar as cópias de segurança como um possível mecanismo para implementar a recuperação de desastres da base de dados. Neste cenário, copia os ficheiros de cópia de segurança para a localização da base de dados secundária para que a base de dados secundária possa ser restaurada. No entanto, os ficheiros de cópia de segurança não são um pré-requisito para a recuperação de desastres. A discussão anterior das funcionalidades de disponibilidade apresentou alternativas.
Alta disponibilidade e recuperação de desastres
A alta disponibilidade e a recuperação de desastres têm em comum o facto de oferecerem soluções para a indisponibilidade da base de dados. Se uma base de dados principal ficar indisponível, uma base de dados secundária torna-se a nova base de dados principal consistente e disponível.
A diferença entre a alta disponibilidade e a recuperação de desastres é o domínio de ponto único de falha. A alta disponibilidade resolve uma interrupção numa região, por exemplo, quando uma única zona falha ou um nó falha. Uma solução de alta disponibilidade fornece uma nova base de dados principal noutra zona na mesma região. Além disso, a alta disponibilidade resolve falhas de nós e não apenas falhas de bases de dados. Se um nó que executa uma instância do SQL Server falhar, é disponibilizado um novo nó que executa uma nova instância do SQL Server (consulte a discussão na secção Instância de cluster de failover Always On).
A recuperação de desastres envolve, pelo menos, duas regiões. Aborda o caso em que uma região inteira fica indisponível. A recuperação de desastres pode fornecer uma nova base de dados principal numa região diferente.
As funcionalidades de alta disponibilidade do SQL Server suportam soluções de alta disponibilidade e recuperação de desastres em simultâneo. Um único grupo de disponibilidade pode abranger as zonas numa região, bem como as próprias regiões. Um grupo de disponibilidade pode conter instâncias de cluster de failover para resolver a alta disponibilidade.
O SQL Server pode estabelecer grupos de disponibilidade numa região para alta disponibilidade e falhas de zonas, e combiná-lo com o envio de registos entre regiões para resolver a recuperação de desastres.
Alternativas de implementação de DR
Nas secções seguintes, são apresentadas algumas topologias de recuperação de desastres possíveis, além das abordadas até agora. Estas topologias satisfazem diferentes requisitos de RPO e RTO. Esta lista não é exaustiva.
RD e AD intrarregionais
Esta implementação é uma variação de um grupo de disponibilidade que contém FCIs, numa região composta por três zonas. As zonas são consideradas o único ponto de domínio de falhas neste cenário.
Em comparação com a implementação apresentada anteriormente, cada FCI consiste em três nós, em que cada nó é executado numa zona diferente. A vantagem desta configuração é que qualquer uma ou duas zonas podem falhar sem exigir um processo de recuperação de desastres.
O diagrama seguinte mostra esta configuração.
Os FCIs abrangem todas as zonas e cada FCI tem uma instância do SQL Server em execução que acede à base de dados correspondente. Existem mais duas instâncias do SQL Server que não estão a ser executadas em cada FCI e que podem ser iniciadas quando uma zona falha. As bases de dados são apresentadas em todas as zonas, uma vez que cada base de dados usa os discos de todos os nós num determinado FCI. Não é apresentada uma app para maior clareza.
DR inter-regional: grupo de disponibilidade que abrange regiões
Neste cenário, um grupo de disponibilidade é executado num cluster de comutação por falha do Windows Server e abrange duas regiões. As regiões são consideradas um domínio de ponto único de falha.
O diagrama seguinte ilustra esta configuração.
Para resolver potenciais problemas de latência, pode configurar as réplicas na região R1 para usar a propagação de transações síncrona, enquanto as réplicas na região R2 estão configuradas para usar a propagação de transações assíncrona.
RD inter-regional: transferência de ficheiros de cópia de segurança
Este cenário usa a transferência de ficheiros de cópia de segurança. Dois grupos de disponibilidade em duas regiões estão associados. Cada grupo de disponibilidade tem as respetivas réplicas a receber as transações de forma síncrona. Por conseguinte, as réplicas secundárias de cada região estão numa configuração de espera ativa.
O diagrama seguinte ilustra esta configuração.
No entanto, os dois grupos de disponibilidade estão ligados pela transferência de ficheiros de cópia de segurança. O grupo de disponibilidade AG1 é o grupo de disponibilidade principal e o grupo de disponibilidade AG2 é o grupo de disponibilidade secundário. À medida que os ficheiros de cópia de segurança são disponibilizados ao grupo de disponibilidade secundário, são aplicados nesse grupo. Este cenário é abordado mais detalhadamente na secção seguinte, Exemplo: estratégia de recuperação de desastres de cópia de segurança e restauro.
Topologia de localização dupla e localização terciária
Se existirem apenas duas bases de dados, uma base de dados principal e uma base de dados secundária, cada uma numa região separada, existe uma duração desprotegida após uma comutação por falha a partir do momento em que a nova base de dados principal está em execução e a nova base de dados secundária está pronta. Se a nova base de dados principal ficar indisponível enquanto a base de dados secundária ainda não estiver em execução, ocorre um tempo de inatividade difícil que só pode ser recuperado quando for estabelecida uma nova base de dados principal. O mesmo se aplica aos grupos de disponibilidade.
Uma terceira localização que execute outra base de dados secundária ou grupo de disponibilidade pode eliminar a duração desprotegida após uma ativação pós-falha. Esta configuração tem de garantir que uma das duas bases de dados secundárias permanece como base de dados secundária e é reatribuída a uma nova base de dados principal para que não ocorra perda de dados. Tal como antes, o mesmo se aplica aos grupos de disponibilidade.
Ciclo de vida da DR
Independentemente da solução de recuperação de desastres que escolher, existem passos comuns do ciclo de vida que se aplicam.
Numa situação real de recuperação de desastres, todas as partes interessadas (proprietários de apps, grupos de operações e administradores de bases de dados) têm de estar disponíveis e participar ativamente na gestão da recuperação de desastres. As partes interessadas têm de decidir sobre a autoridade de decisão (por vezes, denominada mestre de cerimónias) e os processos de decisão que seguem. Além disso, os intervenientes têm de concordar com a respetiva terminologia e métodos de comunicação.
Decidir iniciar um processo de comutação por falha
A menos que a comutação por falha seja iniciada automaticamente, as partes interessadas têm de tomar uma decisão para iniciar uma comutação por falha. Os vários intervenientes têm de coordenar estreitamente a decisão quando decidirem iniciar a comutação por falha.
O início de um processo de comutação por falha depende de vários fatores, principalmente da causa principal da indisponibilidade da base de dados principal.
Se o processo de recuperação de desastres demorar mais tempo do que o esperado para resolver a indisponibilidade da base de dados principal, uma comutação por falha seria prejudicial. Primeiro, tem de avaliar se o restauro da base de dados principal é uma opção viável.
Quanto melhor for testada a estratégia de recuperação de desastres e mais rapidamente for implementada, mais fácil é iniciar o processo de comutação por falha, porque há menos incertezas a considerar na decisão.
Execução do processo de comutação por falha
Idealmente, o processo de comutação por falha é testado regularmente e, por isso, é bem conhecido pelos vários intervenientes.
A autoridade de decisão tem de estar ciente de todos os passos que estão a ser realizados e de todos os problemas inesperados que surgirem. A autoridade de decisão conduz o processo de comutação por falha, e os intervenientes são responsáveis por apoiar a autoridade de decisão.
Deve manter estatísticas para a análise post mortem e a melhoria do processo de comutação por falha, incluindo as durações das atividades, os problemas que surgiram e qualquer confusão nos passos do processo de comutação por falha.
Proteção em falta
Se tiver apenas uma base de dados secundária, a partir do momento em que a nova base de dados principal estiver disponível e operacional até ser configurada uma nova base de dados secundária, não existe proteção de DR. Uma indisponibilidade durante este período pode causar um tempo de inatividade difícil, uma vez que não é possível uma comutação por falha para outra base de dados. Se essa situação ocorrer, tem de configurar outra base de dados principal, e o RPA é o último ponto que pode ser reconstruído com base nas cópias de segurança disponíveis.
A menos que a estratégia de recuperação de desastres esteja configurada para que haja proteção em todos os momentos, todas as partes interessadas têm de estar cientes desta duração da proteção em falta para tomar precauções adicionais durante a configuração ou as alterações de configuração do ambiente.
Pode evitar este período desprotegido se o acesso da app à nova base de dados principal for atrasado até que a nova base de dados secundária esteja em funcionamento. Assim que as alterações da base de dados principal são aplicadas, a base de dados principal fica disponível para as apps. Embora esta abordagem evite qualquer período em que as apps estejam desprotegidas contra a recuperação de desastres, atrasa a conclusão do processo de recuperação de desastres.
Evite situações de divisão de cérebro
É importante que as apps não possam aceder a uma base de dados principal e a uma base de dados secundária ao mesmo tempo, emitindo operações DML. Nesta situação, ocorre uma inconsistência de dados em que a base de dados principal e a base de dados secundária não concordam com os valores de dados do mesmo item de dados (cérebro dividido). Esta arquitetura é especialmente importante se a base de dados principal ficar indisponível enquanto continua a ser executada e pode receber operações de escrita. Se a indisponibilidade for causada por uma partição de rede intermitente, a partição pode parar em qualquer altura e uma app pode voltar a ter acesso. Se estiver a ocorrer um processo de failover nesse momento, as alterações à base de dados principal antiga podem ser perdidas ou algumas apps começam a funcionar na nova base de dados principal enquanto outras continuam a aceder à base de dados principal antiga.
O acesso de todas as apps a qualquer base de dados é desativado durante o processo de comutação por falha para que não seja possível alterar o estado em nenhuma das bases de dados. Após a ativação pós-falha, apenas uma base de dados está disponível para operações de escrita: a nova base de dados principal.
Declaração de conclusão
Após a conclusão do processo de comutação por falha, todas as partes interessadas têm de ser explicitamente informadas pela autoridade de decisão de que o processo está concluído. Qualquer problema que surja após a conclusão tem de ser tratado como um incidente separado que já não faz parte do processo de comutação por falha, mas sim do processamento normal. O problema pode ser uma consequência de um problema com o processo de comutação por falha ou um problema totalmente independente. No entanto, a abordagem para resolver o problema após a conclusão do processo de comutação por falha pode ser diferente da forma como é resolvido durante a execução do processo de comutação por falha.
Análise e relatório post mortem
Para referência futura e para melhorar o processo de comutação por falha, organize imediatamente uma análise post mortem para tomar nota dos aspetos importantes, das conclusões e dos itens de ação.
Escreva um relatório que resuma o evento de recuperação de desastres, as causas principais e todas as ações tomadas. Este relatório pode ser obrigatório se estiver a implementar requisitos regulamentares.
Teste e validação de DR
Uma vez que a recuperação de desastres não faz parte das operações normais do dia a dia, a sua solução de RD tem de ser testada regularmente para garantir o seu funcionamento adequado quando for realmente necessária.
A frequência dos testes depende dos requisitos operacionais e varia consoante a base de dados, a app e a empresa. Além disso, as alterações ao ambiente, como as alterações à configuração de rede e as atualizações de componentes de infraestrutura, devem acionar um teste de recuperação de desastres se as alterações forem feitas aos sistemas nos quais a solução de recuperação de desastres escolhida se baseia. 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.
Pode testar manualmente iniciando o processo de comutação ou automaticamente seguindo uma abordagem de engenharia do caos, conforme descrito em Engenharia do caos. Com os testes manuais, pode minimizar o impacto na empresa caso seja esperado um tempo de inatividade notável.
Um aspeto importante dos testes é a recolha de estatísticas bem definidas. Seguem-se algumas estatísticas importantes a ter em conta:
- Tempo de recuperação real: meça o tempo de recuperação real e compare-o com o OTR.
- Ponto de recuperação real: observe o ponto de recuperação real e compare-o com o OPR.
- Tempo até à deteção de falhas: o tempo que os DBAs ou a equipa de operações demoraram a perceber a necessidade de uma comutação por falha.
- Tempo para o início da recuperação: o tempo que demorou a iniciar o processo de comutação por falha após a deteção da falha.
- Fiabilidade: com que rigor o processo de comutação por falha foi seguido ou foram necessárias variações? Surgiram problemas inesperados que precisam de ser investigados e que podem resultar numa alteração da estratégia de recuperação?
Com base nas estatísticas recolhidas, o processo de comutação por falha pode ter de ser ajustado ou melhorado para corresponder melhor às expetativas de RPO e RTO.
Exemplo: estratégia de RD de cópia de segurança e restauro
As secções seguintes descrevem uma estratégia de recuperação de desastres de cópia de segurança e restauro de exemplo. Este cenário minimiza a utilização de funcionalidades de disponibilidade do SQL Server para demonstrar o esforço necessário para especificar uma estratégia de cópia de segurança e restauro de recuperação de desastres e para debater aspetos que são invisíveis em configurações mais automatizadas.
Exemplo de utilização
Um grupo de disponibilidade Always On principal está localizado e operacional na região R1. O grupo de disponibilidade secundário Always On é adicionado na região R2 para proteção adicional entre regiões e está disponível como destino de comutação por falha ou comutação.
Estratégia
A estratégia de recuperação de desastres baseia-se em cópias de segurança da base de dados. É feita uma cópia de segurança completa inicial, seguida de cópias de segurança diferenciais subsequentes. As cópias de segurança são aplicadas ao grupo de disponibilidade Always On secundário à medida que são feitas. Todas as cópias de segurança são armazenadas num contentor do Cloud Storage.
Neste exemplo, é aceitável que, após a conclusão da comutação por falha, o novo grupo de disponibilidade Always On na região R2 esteja ativo e desprotegido durante um período limitado até que o novo grupo de disponibilidade Always On secundário na região R1 esteja operacional.
Não tem de ocorrer nenhuma alternativa, uma vez que o grupo de disponibilidade Always On em cada uma das regiões está igualmente qualificado para ser publicado como um grupo de disponibilidade Always On de produção.
ORT e ORT
Neste exemplo, o RPO é definido como um máximo de 60 minutos, pelo que é feito uma cópia de segurança diferencial a cada 60 minutos.
O RTO não está definido explicitamente para uma duração, mas deve ser o mais mínimo possível. O melhor caso é o imediato. O grupo de disponibilidade secundário tem de ser configurado como um hot standby. No caso de um modo de espera ativo, todas as cópias de segurança são aplicadas imediatamente para que a comutação por falha não seja atrasada na aplicação das cópias de segurança.
Estratégia de DR de nível elevado
As secções seguintes descrevem a estratégia de recuperação de desastres. É breve para se concentrar nos passos essenciais.
Configuração inicial
- Crie um grupo de disponibilidade Always On secundário na região R2.
- Impedir o acesso da app ao grupo de disponibilidade secundário para que não ocorra acidentalmente uma situação de divisão de cérebros.
- Crie o contentor de ficheiros de cópia de segurança B1 no Cloud Storage para conter a cópia de segurança completa inicial do grupo de disponibilidade Always On em R1 e as cópias de segurança diferenciais por hora subsequentes do grupo de disponibilidade Always On em R1. Tem de estabelecer a ordem correta das cópias de segurança diferenciais para que o processo de aplicação das cópias de segurança ao grupo de disponibilidade secundário possa inferir a ordem correta. Uma abordagem pode ser uma convenção de nomenclatura que permita estabelecer a ordem cronológica correta com base na data e hora que fazem parte dos vários nomes de ficheiros.
Estratégia de lançamento
- Aplique a cópia de segurança completa ao grupo de disponibilidade Always On secundário na região R2.
- À medida que os backups diferenciais ficam disponíveis, aplique-os imediatamente ao grupo de disponibilidade Always On secundário no R2. A aplicação imediata é necessária para resolver a RTO.
- Depois da cópia de segurança completa inicial e de todas as cópias de segurança incrementais serem aplicadas, o grupo de disponibilidade Always On secundário está pronto.
- Teste a estratégia de recuperação de desastres fazendo uma comutação do grupo de disponibilidade principal para o grupo de disponibilidade secundário. Deve estar disponível, pelo menos, uma cópia de segurança incremental durante os testes.
Caso de comutação por falha ou comutação
No R2, os passos essenciais são os seguintes:
- Certifique-se de que a cópia de segurança diferencial mais recente foi aplicada ao grupo de disponibilidade Always On secundário no R2.
- Designar R2 como o novo grupo de disponibilidade Sempre ativo principal.
- Crie um novo contentor B2, faça uma cópia de segurança completa como base e abra o novo grupo de disponibilidade principal para acesso à app.
- Comece a fazer cópias de segurança diferenciais.
Na R1, os passos essenciais são os seguintes:
- Remova o contentor B1 porque já não é necessário.
- Quando o grupo de disponibilidade Always On em R1 ficar novamente disponível (como um novo grupo de disponibilidade Always On secundário), impeça o acesso à app e remova todos os dados da base de dados ou reponha-a para o respetivo estado inicial (vazio), a menos que tenha de ser criada novamente.
- Aplique a cópia de segurança completa do novo grupo de disponibilidade Always On principal em R2 e continue a aplicar cópias de segurança diferenciais imediatamente à medida que ficam disponíveis (armazenadas no contentor B2).
Possíveis melhorias
Uma possível melhoria à estratégia de DR é evitar fazer uma cópia de segurança completa após uma comutação por falha ou uma comutação, ao mesmo tempo que consegue configurar rapidamente o novo grupo de disponibilidade secundário. Em vez de uma única cópia de segurança completa e cópias de segurança diferenciais subsequentes, faça uma cópia de segurança completa todas as semanas e crie um contentor semanal que contenha a cópia de segurança completa da semana e todas as cópias de segurança diferenciais subsequentes dessa semana. O novo grupo de disponibilidade principal tem de criar cópias de segurança diferenciais apenas após a comutação por falha (e não uma cópia de segurança completa) e adicioná-las ao contentor. O novo grupo de disponibilidade secundário aplica simplesmente todas as cópias de segurança no conjunto da semana atual. Se usar esta abordagem semanal, tem de implementar uma estratégia de limpeza ou eliminação para remover as cópias de segurança obsoletas.
Outra melhoria baseia-se no facto de o novo grupo de disponibilidade secundário ter sido o grupo de disponibilidade principal anterior. Se a base de dados existir e estiver operacional após voltar a estar disponível, uma recuperação num determinado momento para a respetiva última cópia de segurança diferencial evita ter de a restaurar totalmente a partir da última cópia de segurança completa, conforme descrito no artigo Restaurar uma base de dados do SQL Server para um determinado momento (modelo de recuperação total). Este cenário reduz o esforço e o tempo durante o qual o novo grupo de disponibilidade principal fica desprotegido.
Práticas recomendadas de produção
Esta solução não especifica se as instâncias do SQL Server nos grupos de disponibilidade Always On são instâncias autónomas ou FCI. O tipo de instâncias usadas tem de ser decidido antes da implementação.
Até que um novo grupo de disponibilidade secundário Always On esteja operacional após uma transferência de controlo, existe um período em que a recuperação de desastres não está protegida. Deve configurar um grupo de disponibilidade Always On numa terceira região.
Além disso, deve implementar a monitorização para garantir que qualquer falha ou erro é detetado. A monitorização está fora do âmbito deste documento, mas é essencial para uma solução de recuperação de desastres funcional.
O que se segue?
- Configurar grupos de disponibilidade Always On do SQL Server.
- Implementar um grupo de disponibilidade Always On do SQL Server 2016 com várias sub-redes no Compute Engine.
- Configurar instâncias de cluster de comutação por falha do SQL Server.
- Executar clustering de comutação por falha do Windows Server.
- Como ativar o Cloud Logging, o Cloud Monitoring e o Error Reporting para apps .NET
- Instalar o agente do Cloud Monitoring.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.