Recuperação de desastres para um aplicativo SaaS multilocatário usando replicação geográfica de banco de dados

Aplica-se a:Banco de Dados SQL do Azure

Neste tutorial, você explora um cenário de recuperação de desastres completo para um aplicativo SaaS multilocatário implementado usando o modelo de banco de dados por locatário. Para proteger o aplicativo de uma interrupção, use a replicação geográfica para criar réplicas para os bancos de dados de catálogo e locatário em uma região de recuperação alternativa. Se ocorrer uma interrupção, você rapidamente fará failover para essas réplicas para retomar as operações comerciais normais. No failover, os bancos de dados na região original tornam-se réplicas secundárias dos bancos de dados na região de recuperação. Quando essas réplicas voltam a ficar online, elas alcançam automaticamente o estado dos bancos de dados na região de recuperação. Depois que a interrupção for resolvida, você fará failover para os bancos de dados na região de produção original.

Este tutorial explora os fluxos de trabalho de failover e failback. Saberá como:

• Sincronizar informações de configuração do banco de dados e do pool elástico no catálogo do locatário
• Configure um ambiente de recuperação em uma região alternativa, incluindo aplicativos, servidores e pools
• Usar a replicação geográfica para replicar os bancos de dados de catálogo e locatário para a região de recuperação
• Failover dos bancos de dados de aplicativo, catálogo e locatário para a região de recuperação
• Mais tarde, faça failover dos bancos de dados de aplicativos, catálogos e locatários de volta para a região original depois que a interrupção for resolvida
• Atualize o catálogo à medida que cada banco de dados de locatário é submetido a failover para controlar o local principal do banco de dados de cada locatário
• Verifique se o aplicativo e o banco de dados do locatário primário estão sempre colocalizados na mesma região do Azure para reduzir a latência

Antes de iniciar este tutorial, verifique se os seguintes pré-requisitos foram concluídos:

• O banco de dados SaaS de tíquetes de ponta de asa por aplicativo de locatário é implantado. Para implantar em menos de cinco minutos, consulte Implantar e explorar o banco de dados SaaS de tíquetes Wingtip por aplicativo locatário
• O Azure PowerShell está instalado. Para obter mais detalhes, veja Introdução ao Azure PowerShell

Introdução ao padrão de recuperação de replicação geográfica

A recuperação de desastres (DR) é uma consideração importante para muitos aplicativos, seja por motivos de conformidade ou continuidade de negócios. Se houver uma interrupção prolongada do serviço, um plano de DR bem preparado pode minimizar a interrupção dos negócios. O uso da replicação geográfica fornece o menor RPO e RTO mantendo réplicas de banco de dados em uma região de recuperação para as quais é possível fazer failover em curto prazo.

Um plano de DR baseado na replicação geográfica compreende três partes distintas:

• Set-up - criação e manutenção do ambiente de recuperação
• Recuperação - failover do aplicativo e dos bancos de dados para o ambiente de recuperação se ocorrer uma interrupção,
• Repatriação - failover do aplicativo e dos bancos de dados de volta para a região original assim que o aplicativo for resolvido

Todas as peças devem ser consideradas com cuidado, especialmente se operarem em escala. No geral, o plano deve atingir vários objetivos:

• Configuração
  • Estabeleça e mantenha um ambiente de imagem espelhada na região de recuperação. A criação de pools elásticos e a replicação de quaisquer bancos de dados nesse ambiente de recuperação reservam capacidade na região de recuperação. A manutenção desse ambiente inclui a replicação de novos bancos de dados de locatários à medida que são provisionados.
• Recuperação
  • Quando um ambiente de recuperação reduzido é usado para minimizar os custos diários, pools e bancos de dados devem ser ampliados para adquirir capacidade operacional total na região de recuperação
  • Habilite o provisionamento de novos locatários na região de recuperação o mais rápido possível
  • Ser otimizado para restaurar locatários em ordem de prioridade
  • Seja otimizado para colocar os inquilinos online o mais rápido possível, fazendo etapas em paralelo onde for prático
  • Seja resiliente a falhas, reinicializável e idempotente
  • Ser possível cancelar o processo no meio do voo se a região original voltar a ficar on-line.
• Repatriamento
  • Failover de bancos de dados da região de recuperação para réplicas na região original com impacto mínimo para os locatários: sem perda de dados e período mínimo off-line por locatário.

Neste tutorial, esses desafios são abordados usando recursos do Banco de Dados SQL do Azure e da plataforma Azure:

• Modelos do Azure Resource Manager, para reservar toda a capacidade necessária o mais rápido possível. Os modelos do Azure Resource Manager são usados para provisionar uma imagem espelhada dos servidores de produção e pools elásticos na região de recuperação.
• Replicação geográfica, para criar secundários somente leitura replicados de forma assíncrona para todos os bancos de dados. Durante uma interrupção, você faz failover para as réplicas na região de recuperação. Depois que a interrupção for resolvida, você fará failover para os bancos de dados na região original sem perda de dados.
• Operações de failover assíncronas enviadas em ordem de prioridade de locatário, para minimizar o tempo de failover para um grande número de bancos de dados.
• Recursos de recuperação de gerenciamento de estilhaços, para alterar as entradas do banco de dados no catálogo durante a recuperação e a repatriação. Esses recursos permitem que o aplicativo se conecte a bancos de dados de locatários, independentemente do local, sem reconfigurar o aplicativo.
• Aliases DNS do SQL Server, para permitir o provisionamento contínuo de novos locatários, independentemente da região em que o aplicativo está operando. Os aliases DNS também são usados para permitir que o processo de sincronização do catálogo se conecte ao catálogo ativo, independentemente de seu local.

Obtenha os scripts de recuperação de desastres

Importante

Como todos os scripts de gerenciamento de Wingtip Tickets, os scripts DR são de qualidade de amostra e não devem ser usados na produção.

Os scripts de recuperação usados neste tutorial e o código-fonte do aplicativo Wingtip estão disponíveis no banco de dados SaaS Wingtip Tickets por repositório GitHub do locatário. Confira as orientações gerais para conhecer as etapas para baixar e desbloquear os scripts de gerenciamento de Wingtip Tickets.

Descrição geral dos tutoriais

Neste tutorial, você primeiro usa a replicação geográfica para criar réplicas do aplicativo Wingtip Tickets e seus bancos de dados em uma região diferente. Em seguida, faça failover para essa região para simular a recuperação de uma interrupção. Quando concluído, o aplicativo estará totalmente funcional na região de recuperação.

Mais tarde, em uma etapa de repatriação separada, você faz failover dos bancos de dados de catálogo e locatário na região de recuperação para a região original. A aplicação e as bases de dados permanecem disponíveis durante o repatriamento. Quando concluído, o aplicativo estará totalmente funcional na região original.

Nota

O aplicativo é recuperado na região emparelhada da região na qual o aplicativo é implantado. Para obter mais informações, consulte Regiões emparelhadas do Azure.

Rever o estado de funcionamento da aplicação

Antes de iniciar o processo de recuperação, revise o estado normal de integridade do aplicativo.

1. Em seu navegador da Web, abra o Wingtip Tickets Events Hub (http://events.wingtip-dpt.<user.trafficmanager.net - substitua <user>> pelo valor de usuário da sua implantação).

   • Role até a parte inferior da página e observe o nome e o local do servidor de catálogo no rodapé. O local é a região na qual você implantou o aplicativo. DICA: passe o mouse sobre o local para ampliar a tela.

2. Clique no locatário da Sala de Concertos da Contoso e abra a página do evento.

   • No rodapé, observe o nome do servidor locatário. O local será o mesmo que o local do servidor de catálogo.

3. No portal do Azure, abra o grupo de recursos no qual o aplicativo é implantado

   • Observe a região na qual os servidores estão implantados.

Sincronizar a configuração do locatário no catálogo

Nesta tarefa, você inicia um processo que sincroniza a configuração dos servidores, pools elásticos e bancos de dados no catálogo do locatário. O processo mantém essas informações atualizadas no catálogo. O processo funciona com o catálogo ativo, seja na região original ou na região de recuperação. As informações de configuração são usadas como parte do processo de recuperação para garantir que o ambiente de recuperação seja consistente com o ambiente original e, posteriormente, durante a repatriação, para garantir que a região original seja consistente com quaisquer alterações feitas no ambiente de recuperação. O catálogo também é usado para acompanhar o estado de recuperação dos recursos do locatário

Importante

Para simplificar, o processo de sincronização e outros processos de recuperação e repatriação de longa duração são implementados nestes tutoriais como trabalhos ou sessões locais do PowerShell que são executados sob o login de usuário do cliente. Os tokens de autenticação emitidos quando você fizer login expirarão após várias horas e os trabalhos falharão. Em um cenário de produção, os processos de longa execução devem ser implementados como serviços confiáveis do Azure de algum tipo, executados sob uma entidade de serviço. Consulte Usar o Azure PowerShell para criar uma entidade de serviço com um certificado.

1. No ISE do PowerShell, abra o arquivo ...\Learning Modules\UserConfig.psm1. Substitua <resourcegroup> e nas linhas 10 e <user> 11 pelo valor usado quando você implantou o aplicativo. Salve o arquivo!

2. No ISE do PowerShell, abra o script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 e defina:

   • $DemoScenario = 1, Inicie um trabalho em segundo plano que sincronize o servidor locatário e as informações de configuração do pool no catálogo

3. Pressione F5 para executar o script de sincronização. Uma nova sessão do PowerShell é aberta para sincronizar a configuração dos recursos do locatário.

Deixe a janela do PowerShell em execução em segundo plano e continue com o restante do tutorial.

Nota

O processo de sincronização se conecta ao catálogo por meio de um alias DNS. Esse alias é modificado durante a restauração e a repatriação para apontar para o catálogo ativo. O processo de sincronização mantém o catálogo atualizado com quaisquer alterações de configuração de banco de dados ou pool feitas na região de recuperação. Durante o repatriamento, estas alterações são aplicadas aos recursos equivalentes na região de origem.

Criar réplicas de banco de dados secundárias na região de recuperação

Nesta tarefa, você inicia um processo que implanta uma instância de aplicativo duplicada e replica o catálogo e todos os bancos de dados de locatário para uma região de recuperação.

Nota

Este tutorial adiciona proteção de replicação geográfica ao aplicativo de exemplo Wingtip Tickets. Em um cenário de produção para um aplicativo que usa replicação geográfica, cada locatário seria provisionado com um banco de dados replicado geograficamente desde o início. Consulte Projetando serviços altamente disponíveis usando o Banco de Dados SQL do Azure

1. No ISE do PowerShell, abra o script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 e defina os seguintes valores:

   • $DemoScenario = 2, Criar ambiente de recuperação de imagem espelhada e replicar bancos de dados de catálogo e locatário

2. Prima F5 para executar o script. Uma nova sessão do PowerShell é aberta para criar as réplicas.

Revisar o estado normal do aplicativo

Neste ponto, o aplicativo está sendo executado normalmente na região original e agora está protegido por replicação geográfica. Existem réplicas secundárias somente leitura na região de recuperação para todos os bancos de dados.

1. No portal do Azure, examine seus grupos de recursos e observe que um grupo de recursos foi criado com o sufixo -recovery na região de recuperação.

2. Explore os recursos no grupo de recursos de recuperação.

3. Clique no banco de dados da Sala de Concertos da Contoso no servidor tenants1-dpt-user-recovery><. Clique em Geo-Replication no lado esquerdo.

   

No mapa de regiões do Azure, observe o link de replicação geográfica entre o primário na região original e o secundário na região de recuperação.

Failover do aplicativo na região de recuperação

Visão geral do processo de recuperação de replicação geográfica

O script de recuperação executa as seguintes tarefas:

1. Desabilita o ponto de extremidade do Gerenciador de Tráfego para o aplicativo Web na região original. A desativação do ponto de extremidade impede que os usuários se conectem ao aplicativo em um estado inválido caso a região original fique online durante a recuperação.

2. Usa um failover de força do banco de dados de catálogo na região de recuperação para torná-lo o banco de dados primário e atualiza o alias activecatalog para apontar para o servidor de catálogo de recuperação.

3. Atualiza o alias newtenant para apontar para o servidor locatário na região de recuperação. A alteração desse alias garante que os bancos de dados de quaisquer novos locatários sejam provisionados na região de recuperação.

4. Marca todos os locatários existentes no catálogo de recuperação como offline para impedir o acesso aos bancos de dados de locatários antes que eles sejam submetidos a failover.

5. Atualiza a configuração de todos os pools elásticos e bancos de dados únicos replicados na região de recuperação para espelhar sua configuração na região original. (Essa tarefa só será necessária se pools ou bancos de dados replicados no ambiente de recuperação forem reduzidos durante as operações normais para reduzir custos).

6. Habilita o ponto de extremidade do Gerenciador de Tráfego para o aplicativo Web na região de recuperação. A habilitação desse ponto de extremidade permite que o aplicativo provisione novos locatários. Nesta fase, os inquilinos existentes ainda estão offline.

7. Envia lotes de solicitações para forçar o failover de bancos de dados em ordem de prioridade.

   • Os lotes são organizados de modo que os bancos de dados sejam submetidos a failover em paralelo em todos os pools.
   • As solicitações de failover são enviadas usando operações assíncronas para que sejam enviadas rapidamente e várias solicitações possam ser processadas simultaneamente.

   Nota

   Em um cenário de interrupção, os bancos de dados primários na região original estão offline. Forçar failover no secundário quebra a conexão com o primário sem tentar aplicar quaisquer transações residuais em fila. Em um cenário de drill de DR como este tutorial, se houver alguma atividade de atualização no momento do failover, pode haver alguma perda de dados. Mais tarde, durante a repatriação, quando você faz failover de bancos de dados na região de recuperação de volta para a região original, um failover normal é usado para garantir que não haja perda de dados.

8. Monitora o serviço para determinar quando os bancos de dados foram submetidos a failover. Depois que um banco de dados de locatário é submetido a failover, ele atualiza o catálogo para registrar o estado de recuperação do banco de dados do locatário e marcar o locatário como online.

   • Os bancos de dados de locatários podem ser acessados pelo aplicativo assim que forem marcados online no catálogo.
   • Uma soma de valores rowversion no banco de dados do locatário é armazenada no catálogo. Este valor funciona como uma impressão digital que permite ao processo de repatriação determinar se a base de dados foi atualizada na região de recuperação.

Execute o script para failover para a região de recuperação

Agora imagine que há uma interrupção na região em que o aplicativo é implantado e execute o script de recuperação:

1. No ISE do PowerShell, abra o script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 e defina os seguintes valores:

   • $DemoScenario = 3, Recupere o aplicativo em uma região de recuperação fazendo failover para réplicas

2. Prima F5 para executar o script.

   • O script é aberto em uma nova janela do PowerShell e, em seguida, inicia uma série de trabalhos do PowerShell que são executados em paralelo. Esses trabalhos fazem failover de bancos de dados de locatários para a região de recuperação.
   • A região de recuperação é a região emparelhada associada à região do Azure na qual você implantou o aplicativo. Para obter mais informações, consulte Regiões emparelhadas do Azure.

3. Monitore o status do processo de recuperação na janela do PowerShell.

Nota

Para explorar o código para os trabalhos de recuperação, revise os scripts do PowerShell na pasta ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs.

Revisar o estado do aplicativo durante a recuperação

Enquanto o ponto de extremidade do aplicativo está desativado no Gerenciador de Tráfego, o aplicativo não está disponível. Depois que o catálogo é transferido para a região de recuperação e todos os locatários marcados offline, o aplicativo é colocado online novamente. Embora o aplicativo esteja disponível, cada locatário aparece offline no hub de eventos até que seu banco de dados seja submetido a failover. É importante projetar seu aplicativo para lidar com bancos de dados de locatários offline.

1. Imediatamente após a recuperação do banco de dados de catálogo, atualize o Wingtip Tickets Events Hub em seu navegador da Web.

   • No rodapé, observe que o nome do servidor de catálogo agora tem um sufixo -recovery e está localizado na região de recuperação.

   • Observe que os locatários que ainda não foram restaurados estão marcados como offline e não podem ser selecionados.

     Nota

     Com apenas alguns bancos de dados para recuperar, talvez não seja possível atualizar o navegador antes que a recuperação seja concluída, portanto, talvez não veja os locatários enquanto eles estiverem offline.

     

   • Se você abrir a página Eventos de um locatário offline diretamente, ela exibirá uma notificação de "locatário offline". Por exemplo, se a Sala de Concertos da Contoso estiver offline, tente abrir http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>

Provisionar um novo locatário na região de recuperação

Mesmo antes de todos os bancos de dados de locatários existentes terem falhado, você pode provisionar novos locatários na região de recuperação.

1. No ISE do PowerShell, abra o script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 e defina a seguinte propriedade:

   • $DemoScenario = 4, provisionar um novo locatário na região de recuperação

2. Pressione F5 para executar o script e provisionar o novo locatário.

3. A página de eventos do Hawthorn Hall é aberta no navegador quando é concluída. Observe no rodapé que o banco de dados Hawthorn Hall está provisionado na região de recuperação.

4. No navegador, atualize a página do Wingtip Tickets Events Hub para ver o Hawthorn Hall incluído.

   • Se você provisionou o Hawthorn Hall sem esperar que os outros locatários restaurem, outros locatários ainda podem estar offline.

Rever o estado recuperado do pedido

Quando o processo de recuperação for concluído, o aplicativo e todos os locatários estarão totalmente funcionais na região de recuperação.

1. Quando a exibição na janela do console do PowerShell indicar que todos os locatários foram recuperados, atualize o Hub de Eventos. Os inquilinos aparecerão todos online, incluindo o novo inquilino, Hawthorn Hall.

   

2. No portal do Azure, abra a lista de grupos de recursos.

   • Observe o grupo de recursos que você implantou, mais o grupo de recursos de recuperação, com o sufixo -recovery . O grupo de recursos de recuperação contém todos os recursos criados durante o processo de recuperação, além de novos recursos criados durante a interrupção.

3. Abra o grupo de recursos de recuperação e observe os seguintes itens:

   • As versões de recuperação do catálogo e dos servidores tenants1, com o sufixo -recovery . Os bancos de dados de catálogo e locatário restaurados nesses servidores têm os nomes usados na região original.

   • O servidor SQL tenants2-dpt-user-recovery><. Esse servidor é usado para provisionar novos locatários durante a interrupção.

   • O Serviço de Aplicativo nomeado, events-wingtip-dpt-recoveryregion-user<<>>, que é a instância de recuperação do aplicativo Eventos.

     

4. Abra o servidor SQL tenants2-dpt-user-recovery><. Observe que ele contém o banco de dados hawthornhall e o pool elástico, Pool1. O banco de dados hawthornhall é configurado como um banco de dados elástico no pool elástico Pool1 .

5. Navegue de volta para o grupo de recursos e clique no banco de dados da Sala de Concertos da Contoso no servidor tenants1-dpt-user-recovery><. Clique em Geo-Replication no lado esquerdo.

   

Alterar dados do locatário

Nesta tarefa, você atualiza um dos bancos de dados do locatário.

1. No navegador, localize a lista de eventos da Sala de Concertos da Contoso e anote o último nome do evento.
2. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1, defina o seguinte valor:
   • $DemoScenario = 5 Excluir um evento de um locatário na região de recuperação
3. Pressione F5 para executar o script
4. Atualize a página de eventos da Sala de Concertos da Contoso (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall> - substitua <o usuário pelo valor de usuário da sua implantação) e observe que o> último evento foi excluído.

Repatriar o pedido para a sua região de produção original

Esta tarefa repatria a aplicação para a sua região de origem. Em um cenário real, você iniciaria a repatriação quando a interrupção for resolvida.

Visão geral do processo de repatriação

O processo de repatriamento:

1. Cancela quaisquer solicitações de restauração de banco de dados pendentes ou em andamento.
2. Atualiza o alias newtenant para apontar para o servidor dos locatários na região de origem. A alteração desse alias garante que os bancos de dados de quaisquer novos locatários agora serão provisionados na região de origem.
3. Propaga quaisquer dados alterados do locatário para a região original
4. Realiza failover sobre bancos de dados de locatários em ordem de prioridade.

O failover move efetivamente o banco de dados para a região original. Quando o banco de dados faz failover, todas as conexões abertas são descartadas e o banco de dados fica indisponível por alguns segundos. Os aplicativos devem ser escritos com lógica de repetição para garantir que eles se conectem novamente. Embora essa breve desconexão muitas vezes não seja notada, você pode optar por repatriar bancos de dados fora do horário comercial.

Executar o script de repatriação

Agora vamos imaginar que a interrupção está resolvida e executar o script de repatriação.

1. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1.

2. Verifique se o processo de Sincronização de Catálogo ainda está em execução em sua instância do PowerShell. Se necessário, reinicie-o definindo:

   • $DemoScenario = 1, Comece a sincronizar as informações de configuração do servidor do locatário, do pool e do banco de dados no catálogo
   • Prima F5 para executar o script.

3. Em seguida, para iniciar o processo de repatriação, defina:

   • $DemoScenario = 6, Repatriar o aplicativo para sua região original
   • Pressione F5 para executar o script de recuperação em uma nova janela do PowerShell. A repatriação levará vários minutos e pode ser monitorada na janela do PowerShell.

4. Enquanto o script estiver em execução, atualize a página do Hub de Eventos (http://events.wingtip-dpt.<user.trafficmanager.net>)

   • Repare que todos os inquilinos estão online e acessíveis ao longo deste processo.

5. Após a conclusão da repatriação, atualize o hub de eventos e abra a página de eventos do Hawthorn Hall. Observe que este banco de dados foi repatriado para a região original.

Projetando o aplicativo para garantir que o aplicativo e o banco de dados sejam colocados em conjunto

O aplicativo é projetado para que ele sempre se conecte a partir de uma instância na mesma região que o banco de dados do locatário. Esse design reduz a latência entre o aplicativo e o banco de dados. Essa otimização pressupõe que a interação entre aplicativos e bancos de dados seja mais chata do que a interação entre usuários.

Os bancos de dados de locatários podem estar espalhados pelas regiões de recuperação e originais por algum tempo durante a repatriação. Para cada banco de dados, o aplicativo procura a região na qual o banco de dados está localizado fazendo uma pesquisa de DNS no nome do servidor locatário. No Banco de dados SQL, o nome do servidor é um alias. O nome do servidor com alias contém o nome da região. Se o aplicativo não estiver na mesma região do banco de dados, ele redirecionará para a instância na mesma região do servidor. O redirecionamento para instância na mesma região do banco de dados minimiza a latência entre o aplicativo e o banco de dados.

Próximos passos

Neste tutorial, ficou a saber como:

• Sincronizar informações de configuração do banco de dados e do pool elástico no catálogo do locatário
• Configure um ambiente de recuperação em uma região alternativa, incluindo aplicativos, servidores e pools
• Usar a replicação geográfica para replicar os bancos de dados de catálogo e locatário para a região de recuperação
• Failover dos bancos de dados de aplicativo, catálogo e locatário para a região de recuperação
• Fazer failback dos bancos de dados de aplicativo, catálogo e locatário para a região original depois que a interrupção for resolvida

Você pode saber mais sobre as tecnologias que o Banco de Dados SQL do Azure fornece para habilitar a continuidade de negócios na documentação Visão geral da continuidade de negócios.

Recursos adicionais

• Tutoriais adicionais que se baseiam no aplicativo SaaS Wingtip