Estratégias de recuperação de desastres para aplicativos que usam pools elásticos do Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

O Banco de Dados SQL do Azure fornece vários recursos para fornecer a continuidade de negócios do seu aplicativo quando ocorrem incidentes catastróficos. Pools elásticos e bancos de dados únicos oferecem suporte ao mesmo tipo de recursos de recuperação de desastres (DR). Este artigo descreve várias estratégias de DR para pools elásticos que aproveitam esses recursos de continuidade de negócios do Banco de Dados SQL do Azure.

Este artigo usa o seguinte padrão canônico de aplicativo ISV SaaS:

Um aplicativo Web moderno baseado em nuvem provisiona um banco de dados para cada usuário final. O ISV tem muitos clientes e, portanto, usa muitos bancos de dados, conhecidos como bancos de dados de locatário. Como os bancos de dados do locatário normalmente têm padrões de atividade imprevisíveis, o ISV usa um pool elástico para tornar o custo do banco de dados muito previsível durante longos períodos de tempo. O pool elástico também simplifica o gerenciamento de desempenho quando a atividade do usuário aumenta. Além dos bancos de dados de locatários, o aplicativo também usa vários bancos de dados para gerenciar perfis de usuário, segurança, coletar padrões de uso, etc. A disponibilidade dos locatários individuais não afeta a disponibilidade do aplicativo como um todo. No entanto, a disponibilidade e o desempenho dos bancos de dados de gerenciamento são críticos para a função do aplicativo e, se os bancos de dados de gerenciamento estiverem offline, todo o aplicativo estará offline.

Este artigo discute as estratégias de DR que abrangem uma variedade de cenários, desde aplicativos de inicialização sensíveis ao custo até aqueles com requisitos de disponibilidade rigorosos.

Nota

Se você estiver usando bancos de dados Premium ou Business Critical e pools elásticos, poderá torná-los resilientes a interrupções regionais convertendo-os em configuração de implantação redundante de zona. Consulte Bancos de dados com redundância de zona.

Cenário 1. Arranque sensível ao custo

Sou uma startup e sou extremamente sensível aos custos. Quero simplificar a implantação e o gerenciamento do aplicativo e posso ter um SLA limitado para clientes individuais. Mas quero garantir que o aplicativo como um todo nunca esteja offline.

Para satisfazer o requisito de simplicidade, implante todos os bancos de dados de locatário em um pool elástico na região do Azure de sua escolha e implante bancos de dados de gerenciamento como bancos de dados únicos replicados geograficamente. Para a recuperação de desastres de locatários, use a restauração geográfica, que não tem custo adicional. Para garantir a disponibilidade dos bancos de dados de gerenciamento, replique-os geograficamente para outra região usando um grupo de failover (etapa 1). O custo contínuo da configuração de recuperação de desastres nesse cenário é igual ao custo total dos bancos de dados secundários. Esta configuração é ilustrada no diagrama seguinte.

Se ocorrer uma interrupção na região primária, as etapas de recuperação para colocar seu aplicativo online são ilustradas pelo diagrama a seguir.

• O grupo de failover inicia o failover automático do banco de dados de gerenciamento para a região de DR. O aplicativo é reconectado automaticamente ao novo primário e todas as novas contas e bancos de dados de locatários são criados na região DR. Os clientes existentes veem seus dados temporariamente indisponíveis.
• Crie o pool elástico com a mesma configuração do pool original (2).
• Use a restauração geográfica para criar cópias dos bancos de dados do locatário (3). Você pode considerar acionar as restaurações individuais pelas conexões de usuário final ou usar algum outro esquema de prioridade específico do aplicativo.

Neste ponto, seu aplicativo está on-line novamente na região de DR, mas alguns clientes enfrentam atrasos ao acessar seus dados.

Se a interrupção foi temporária, é possível que a região primária seja recuperada pelo Azure antes que todas as restaurações de banco de dados sejam concluídas na região de DR. Nesse caso, orquestre mover o aplicativo de volta para a região primária. O processo segue as etapas ilustradas no diagrama seguinte.

• Cancele todas as solicitações de restauração geográfica pendentes.
• Failover dos bancos de dados de gerenciamento para a região primária (5). Após a recuperação da região, as antigas primárias tornaram-se automaticamente secundárias. Agora, voltam a mudar de função.
• Altere a cadeia de conexão do aplicativo para apontar de volta para a região primária. Agora, todas as novas contas e bancos de dados de locatários são criados na região primária. Alguns clientes existentes veem seus dados temporariamente indisponíveis.
• Defina todos os bancos de dados no pool de DR como somente leitura para garantir que não possam ser modificados na região de DR (6).
• Para cada banco de dados no pool de DR que foi alterado desde a recuperação, renomeie ou exclua os bancos de dados correspondentes no pool primário (7).
• Copie os bancos de dados atualizados do pool de DR para o pool primário (8).
• Excluir o pool de DR (9)

Neste ponto, seu aplicativo está online na região primária com todos os bancos de dados de locatários disponíveis no pool primário.

Benefício

O principal benefício dessa estratégia é o baixo custo contínuo para redundância da camada de dados. O Banco de Dados SQL do Azure faz backup automático de bancos de dados sem regravação de aplicativos sem custo adicional. O custo é incorrido somente quando os bancos de dados elásticos são restaurados.

Compromisso

A contrapartida é que a recuperação completa de todos os bancos de dados de locatários leva um tempo significativo. O período de tempo depende do número total de restaurações iniciadas na região DR e do tamanho geral dos bancos de dados do locatário. Mesmo que você priorize algumas restaurações de locatários em detrimento de outras, estará competindo com todas as outras restaurações iniciadas na mesma região em que o serviço arbitra e limita para minimizar o impacto geral nos bancos de dados dos clientes existentes. Além disso, a recuperação dos bancos de dados de locatários não pode ser iniciada até que o novo pool elástico na região DR seja criado.

Cenário 2. Aplicativo maduro com serviço hierárquico

Sou um aplicativo SaaS maduro com ofertas de serviços hierárquicos e SLAs diferentes para clientes de avaliação e para clientes pagantes. Para os clientes de teste, eu tenho que reduzir o custo tanto quanto possível. Os clientes de teste podem reduzir o tempo de inatividade, mas eu quero reduzir sua probabilidade. Para os clientes pagantes, qualquer tempo de inatividade é um risco de voo. Por isso, quero ter a certeza de que os clientes pagantes podem sempre aceder aos seus dados.

Para dar suporte a esse cenário, separe os locatários de avaliação dos locatários pagos, colocando-os em pools elásticos separados. Os clientes de avaliação têm eDTU ou vCores mais baixos por locatário e SLA mais baixo com um tempo de recuperação mais longo. Os clientes pagantes estão em um pool com eDTU ou vCores mais altos por locatário e um SLA mais alto. Para garantir o menor tempo de recuperação, os bancos de dados de locatários dos clientes pagantes são replicados geograficamente. Esta configuração é ilustrada no diagrama seguinte.

Como no primeiro cenário, os bancos de dados de gerenciamento são bastante ativos, então você usa um único banco de dados replicado geograficamente para ele (1). Isso garante o desempenho previsível para novas assinaturas de clientes, atualizações de perfil e outras operações de gerenciamento. A região na qual residem as primárias dos bancos de dados de gerenciamento é a região primária e a região na qual residem os secundários dos bancos de dados de gerenciamento é a região DR.

Os bancos de dados de locatários dos clientes pagadores têm bancos de dados ativos no pool pago provisionado na região primária. Provisione um pool secundário com o mesmo nome na região DR. Cada locatário é replicado geograficamente para o pool secundário (2). Isso permite a recuperação rápida de todos os bancos de dados de locatários usando failover.

Se ocorrer uma interrupção na região primária, as etapas de recuperação para colocar seu aplicativo online são ilustradas no diagrama a seguir:

• Failover imediato dos bancos de dados de gerenciamento para a região DR (3).
• Altere a cadeia de conexão do aplicativo para apontar para a região DR. Agora, todas as novas contas e bancos de dados de locatários são criados na região DR. Os clientes de avaliação existentes veem seus dados temporariamente indisponíveis.
• Faça failover dos bancos de dados do locatário pago para o pool na região de DR para restaurar imediatamente sua disponibilidade (4). Como o failover é uma alteração rápida no nível de metadados, considere uma otimização em que os failovers individuais são acionados sob demanda pelas conexões do usuário final.
• Se o tamanho do eDTU do pool secundário ou o valor do vCore for menor do que o primário porque os bancos de dados secundários exigiam apenas a capacidade de processar os logs de alterações enquanto eles eram secundários, aumente imediatamente a capacidade do pool agora para acomodar a carga de trabalho completa de todos os locatários (5).
• Crie o novo pool elástico com o mesmo nome e a mesma configuração na região DR para os bancos de dados dos clientes de avaliação (6).
• Depois que o pool de clientes de avaliação for criado, use a restauração geográfica para restaurar os bancos de dados individuais do locatário de avaliação no novo pool (7). Considere acionar as restaurações individuais pelas conexões de usuário final ou usar algum outro esquema de prioridade específico do aplicativo.

Neste momento, a sua candidatura está novamente online na região DR. Todos os clientes pagantes têm acesso aos seus dados enquanto os clientes da versão experimental sofrem atrasos no acesso aos seus dados.

Quando a região primária é recuperada pelo Azure depois de restaurar o aplicativo na região DR, você pode continuar executando o aplicativo nessa região ou pode decidir fazer failback para a região primária. Se a região primária for recuperada antes que o processo de failover seja concluído, considere o failback imediatamente. O failback executa as etapas ilustradas no diagrama a seguir:

• Cancele todas as solicitações de restauração geográfica pendentes.
• Failover dos bancos de dados de gerenciamento (8). Após a recuperação da região, o antigo primário torna-se automaticamente o secundário. Agora torna-se novamente o principal.
• Failover dos bancos de dados de locatários pagos (9). Da mesma forma, após a recuperação da região, as antigas primárias tornam-se automaticamente secundárias. Agora voltam a ser as primárias.
• Defina os bancos de dados de avaliação restaurados que foram alterados na região DR como somente leitura (10).
• Para cada banco de dados no pool de DR de clientes de avaliação que foi alterado desde a recuperação, renomeie ou exclua o banco de dados correspondente no pool primário de clientes de avaliação (11).
• Copie os bancos de dados atualizados do pool de DR para o pool primário (12).
• Exclua o pool de DR (13).

Nota

A operação de failover é assíncrona. Para minimizar o tempo de recuperação, é importante executar o comando failover dos bancos de dados do locatário em lotes de pelo menos 20 bancos de dados.

Benefício

O principal benefício dessa estratégia é que ela fornece o SLA mais alto para os clientes pagantes. Ele também garante que os novos testes sejam desbloqueados assim que o pool de DR de avaliação for criado.

Compromisso

A contrapartida é que essa configuração aumenta o custo total dos bancos de dados do locatário pelo custo do pool de DR secundário para clientes pagos. Além disso, se o pool secundário tiver um tamanho diferente, os clientes pagantes terão um desempenho menor após o failover até que a atualização do pool na região de DR seja concluída.

Cenário 3. Aplicativo distribuído geograficamente com serviço hierárquico

Tenho um aplicativo SaaS maduro com ofertas de serviços hierárquicos. Quero oferecer um SLA muito agressivo aos meus clientes pagos e minimizar o risco de impacto quando ocorrem interrupções, porque mesmo uma breve interrupção pode causar insatisfação do cliente. É fundamental que os clientes pagantes possam sempre aceder aos seus dados. Os testes são gratuitos e um SLA não é oferecido durante o período de teste.

Para dar suporte a esse cenário, use três pools elásticos separados. Provisione dois pools de tamanho igual com eDTUs ou vCores altos por banco de dados em duas regiões diferentes para conter os bancos de dados de locatários dos clientes pagos. O terceiro pool que contém os locatários de avaliação pode ter eDTUs ou vCores mais baixos por banco de dados e ser provisionado em uma das duas regiões.

Para garantir o menor tempo de recuperação durante interrupções, os bancos de dados de locatários dos clientes pagantes são replicados geograficamente com 50% dos bancos de dados primários em cada uma das duas regiões. Da mesma forma, cada região tem 50% das bases de dados secundárias. Dessa forma, se uma região estiver offline, apenas 50% dos bancos de dados dos clientes pagos serão afetados e terão que fazer failover. As outras bases de dados permanecem intactas. Esta configuração é ilustrada no diagrama a seguir:

Como nos cenários anteriores, os bancos de dados de gerenciamento são bastante ativos, portanto, configure-os como bancos de dados replicados geograficamente únicos (1). Isso garante o desempenho previsível das novas assinaturas de clientes, atualizações de perfil e outras operações de gerenciamento. A região A é a região primária para os bancos de dados de gerenciamento e a região B é usada para recuperação dos bancos de dados de gerenciamento.

Os bancos de dados de locatários dos clientes pagantes também são replicados geograficamente, mas com primárias e secundárias divididas entre a região A e a região B (2). Dessa forma, os bancos de dados primários do locatário afetados pela interrupção podem fazer failover para a outra região e ficar disponíveis. A outra metade dos bancos de dados de locatários não é afetada.

O diagrama seguinte ilustra os passos de recuperação a seguir se ocorrer uma interrupção na região A.

• Failover imediato dos bancos de dados de gerenciamento para a região B (3).
• Altere a cadeia de conexão do aplicativo para apontar para os bancos de dados de gerenciamento na região B. Modifique os bancos de dados de gerenciamento para garantir que as novas contas e bancos de dados de locatários sejam criados na região B e que os bancos de dados de locatários existentes também sejam encontrados lá. Os clientes de avaliação existentes veem seus dados temporariamente indisponíveis.
• Faça failover dos bancos de dados do locatário pago para o pool 2 na região B para restaurar imediatamente sua disponibilidade (4). Como o failover é uma alteração rápida no nível de metadados, você pode considerar uma otimização em que os failovers individuais são acionados sob demanda pelas conexões do usuário final.
• Como agora o pool 2 contém apenas bancos de dados primários, a carga de trabalho total no pool aumenta e pode aumentar imediatamente seu tamanho de eDTU (5) ou o número de vCores.
• Crie o novo pool elástico com o mesmo nome e a mesma configuração na região B para os bancos de dados dos clientes de avaliação (6).
• Depois que o pool for criado, use a restauração geográfica para restaurar o banco de dados de locatário de avaliação individual no pool (7). Você pode considerar acionar as restaurações individuais pelas conexões de usuário final ou usar algum outro esquema de prioridade específico do aplicativo.

Nota

A operação de failover é assíncrona. Para minimizar o tempo de recuperação, é importante executar o comando failover dos bancos de dados do locatário em lotes de pelo menos 20 bancos de dados.

Neste momento, a sua candidatura está novamente online na região B. Todos os clientes pagantes têm acesso aos seus dados enquanto os clientes da versão experimental sofrem atrasos no acesso aos seus dados.

Quando a região A é recuperada, você precisa decidir se deseja usar a região B para clientes de avaliação ou failback para usar o pool de clientes de avaliação na região A. Um critério poderia ser a % de bancos de dados de locatários de avaliação modificados desde a recuperação. Independentemente dessa decisão, você precisa reequilibrar os inquilinos pagos entre dois pools. O diagrama a seguir ilustra o processo quando os bancos de dados do locatário de avaliação fazem failback para a região A.

• Cancele todas as solicitações de restauração geográfica pendentes para o pool de DR de avaliação.
• Failover do banco de dados de gerenciamento (8). Após a recuperação da região, o antigo primário tornou-se automaticamente o secundário. Agora torna-se novamente o principal.
• Selecione quais bancos de dados de locatários pagos failback para o pool 1 e inicie o failover para seus secundários (9). Após a recuperação da região, todos os bancos de dados do pool 1 se tornaram automaticamente secundários. Agora, 50% deles voltam a ser primários.
• Reduza o tamanho do pool 2 para o eDTU original (10) ou o número de vCores.
• Defina todos os bancos de dados de avaliação restaurados na região B como somente leitura (11).
• Para cada banco de dados no pool de DR de avaliação que foi alterado desde a recuperação, renomeie ou exclua o banco de dados correspondente no pool primário de avaliação (12).
• Copie os bancos de dados atualizados do pool de DR para o pool primário (13).
• Exclua o pool de DR (14).

Benefício

Os principais benefícios desta estratégia são:

• Ele suporta o SLA mais agressivo para os clientes pagantes porque garante que uma interrupção não possa afetar mais de 50% dos bancos de dados de locatários.
• Ele garante que os novos testes sejam desbloqueados assim que o pool de DR de trilha for criado durante a recuperação.
• Ele permite um uso mais eficiente da capacidade do pool, já que 50% dos bancos de dados secundários do pool 1 e do pool 2 têm a garantia de serem menos ativos do que os bancos de dados primários.

Compensações

Os principais compromissos são:

• As operações CRUD em relação aos bancos de dados de gerenciamento têm latência menor para os usuários finais conectados à região A do que para os usuários finais conectados à região B, pois são executadas em relação ao primário dos bancos de dados de gerenciamento.
• Requer um design mais complexo do banco de dados de gerenciamento. Por exemplo, cada registro de locatário tem uma marca de local que precisa ser alterada durante failover e failback.
• Os clientes pagantes podem ter um desempenho inferior ao habitual até que a atualização do pool na região B seja concluída.

Resumo

Este artigo se concentra nas estratégias de recuperação de desastres para a camada de banco de dados usada por um aplicativo multilocatário ISV SaaS. A estratégia que você escolhe é baseada nas necessidades do aplicativo, como o modelo de negócios, o SLA que você deseja oferecer aos seus clientes, restrição de orçamento etc. Cada estratégia descrita descreve os benefícios e o compromisso para que você possa tomar uma decisão informada. Além disso, seu aplicativo específico provavelmente inclui outros componentes do Azure. Assim, você revisa suas diretrizes de continuidade de negócios e orquestra a recuperação da camada de banco de dados com eles. Para saber mais sobre como gerenciar a recuperação de aplicativos de banco de dados no Azure, consulte Projetando soluções de nuvem para recuperação de desastres.

Próximos passos

• Para saber mais sobre backups automatizados do Banco de Dados SQL do Azure, consulte Backups automatizados do Banco de Dados SQL do Azure.
• Para obter uma visão geral e cenários de continuidade de negócios, consulte Visão geral de continuidade de negócios.
• Para saber mais sobre como usar backups automatizados para recuperação, consulte Restaurar um banco de dados a partir dos backups iniciados pelo serviço.
• Para saber mais sobre opções de recuperação mais rápidas, consulte Replicação geográfica ativa e Grupos de failover.
• Para saber mais sobre como usar backups automatizados para arquivamento, consulte Cópia de banco de dados.