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

Aplica-se a: do 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 bases de dados individuais oferecem suporte ao mesmo tipo de capacidades 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 de aplicativo canônico de fornecedor independente de software SaaS (ISV):

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.

Cenário 1. Startup sensível aos custos

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 inquilinos, 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 neste 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, orqueste mover a aplicação 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.
• Transferir os bancos de dados de gestão 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 de 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 aceitar algum tempo de inatividade, mas eu quero reduzir a sua probabilidade. Para os clientes pagantes, qualquer tempo de indisponibilidade representa um risco de perda de clientes. 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 teste têm mais baixos eDTU ou vCores por inquilino e menor SLA, 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 dos inquilinos dos clientes pagadores têm bases de dados ativas no pool pago provisionado na região primária. Crie um pool secundário com o mesmo nome na região de DR. Cada locatário é replicado geograficamente para o grupo 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 em teste existentes veem os 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 sejam acionados sob demanda pelas conexões do utilizador 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 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 as bases de dados dos clientes de avaliação (6).
• Depois de criar o pool de clientes de avaliação, utilize a restauração geográfica para recuperar as bases de dados individuais dos locatários 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 ponto, seu aplicativo está novamente on-line 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 você tiver restaurado o aplicativo na região DR, poderá continuar executando o aplicativo nessa região ou poderá decidir fazer failback para a região primária. Se a região primária for recuperada antes de o processo de failover ser concluído, considere falhar de volta imediatamente. O failback executa as etapas ilustradas no diagrama a seguir:

• Cancele todas as solicitações de restauração geográfica pendentes.
• Realizar failover dos bancos de dados de gestão (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 as secundárias. Agora voltam a ser as primárias.
• Defina os bancos de dados experimentais 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).

Benefício

O principal benefício dessa estratégia é que ela fornece o SLA mais alto para os clientes pagantes. Garante também que os novos ensaios 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 base de dados em duas regiões diferentes para alojar as bases de dados dos clientes pagantes. 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 possível durante interrupções, os bancos de dados de inquilinos dos clientes pagantes são geo-replicados com 50% dos bancos de dados primários em cada uma das duas regiões. Da mesma forma, cada região tem 50% de 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.

As bases de dados dos arrendatários dos clientes pagantes também são replicadas geograficamente, mas com as bases principais 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.

• Efetuar imediatamente o failover dos bancos de dados de gestão 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 teste existentes veem os 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). Dado que o failover é uma alteração rápida ao nível de metadados, poderás considerar uma otimização em que os failovers individuais são acionados sob demanda pelas conexões do utilizador 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 as bases de dados dos clientes de teste (6).
• Depois de criar o pool, use a restauração geográfica para restaurar o banco de dados do inquilino de teste 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.

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, precisas decidir se desejas utilizar a região B para clientes de avaliação ou reverter para utilizar a piscina de clientes de avaliação na região A. Um critério poderia ser a % dos bancos de dados de inquilinos de avaliação modificados desde o restabelecimento. Independentemente dessa decisão, necessita reequilibrar os inquilinos pagos entre dois grupos. O diagrama a seguir ilustra o processo quando os bancos de dados dos clientes de teste retornam para a região A.

• Cancele todas as solicitações de restauração geográfica pendentes para o pool de DR de avaliação.
• Executar failover da base de dados de gestão (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 retornam no pool 1 e inicie a migração para os 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 teste que foi alterado desde a recuperação, renomeie ou exclua o banco de dados correspondente no pool de teste primário (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:

• O sistema suporta o Acordo de Nível de Serviço (SLA) mais agressivo para os clientes pagantes, pois garante que uma interrupção não possa afetar mais de 50% dos bancos de dados do locatário.
• Ele garante que os novos testes sejam desbloqueados assim que o pool de DR de trilha for criado durante a recuperação.
• Isto permite um uso mais eficiente da capacidade do pool, pois garante que 50% dos bancos de dados secundários no pool 1 e no pool 2 sejam 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 registo de locatário tem uma etiqueta de localização que precisa ser alterada no contexto de 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 escolhida baseia-se nas necessidades da aplicação, tais como o modelo de negócio, o SLA que pretende oferecer aos seus clientes, restrições orçamentais, 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 de 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.