Visão geral da continuidade dos negócios com a Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

• Banco de Dados SQL do Azure
• Instância Gerenciada do SQL do Azure

Este artigo fornece uma visão geral dos recursos de continuidade dos negócios e recuperação de desastres da Instância Gerenciada de SQL do Azure, descrevendo as opções e recomendações para recuperação de eventos disruptivos que podem levar à perda de dados ou fazer com que sua instância e aplicativo fiquem indisponíveis. Aprenda o que fazer quando um erro de usuário ou de aplicativo afeta a integridade dos dados, quando uma região ou zona de disponibilidade do Azure tem uma interrupção ou quando seu aplicativo necessita de manutenção.

Visão geral

A continuidade dos negócios na Instância Gerenciada de SQL do Azure refere-se aos mecanismos, políticas e procedimentos que permitem que sua empresa continue operando diante da interrupção, fornecendo disponibilidade, alta disponibilidade e recuperação de desastres.

Na maioria dos casos, a Instância Gerenciada de SQL lidará com os eventos de interrupção que podem acontecer no ambiente de nuvem e manterá seus aplicativos e processos de negócios em execução. No entanto, existem alguns eventos disruptivos em que a mitigação pode levar algum tempo, como:

• O usuário exclui ou atualiza acidentalmente uma linha em uma tabela.
• Um invasor mal-intencionado conseguiu excluir dados ou remover um banco de dados.
• Um evento catastrófico de desastre natural derruba um datacenter ou uma zona de disponibilidade ou região.
• Interrupção rara de datacenter, zona de disponibilidade ou interrupção em toda a região causada por uma alteração de configuração, bug de software ou falha de componente de hardware.

Disponibilidade

A Instância Gerenciada de SQL do Azure vem com uma promessa de resiliência e confiabilidade que a protege contra falhas de software ou hardware. Os backups de banco de dados são automatizados para proteger seus bancos de dados contra danos ou exclusão acidental. Como uma plataforma como serviço (PaaS), o serviço de Instância Gerenciada de SQL do Azure fornece disponibilidade como um recurso pronto para uso com um SLA de disponibilidade líder do setor de 99,99%.

Alta disponibilidade

Para obter alta disponibilidade no ambiente de nuvem do Azure, habilite a redundância de zona para que a instância use zonas de disponibilidade para garantir resiliência a falhas zonais. Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de data centers dentro de uma região que têm infraestrutura independente de energia, resfriamento e rede. As zonas de disponibilidade são projetadas para fornecer serviços regionais, capacidade e alta disponibilidade nas zonas restantes se uma zona sofrer uma interrupção. Ao habilitar a redundância de zona, a instância é resiliente a falhas zonais de hardware e software e a recuperação é transparente para os aplicativos. Quando a alta disponibilidade está habilitada, o serviço de Instância Gerenciada de SQL do Azure é capaz de fornecer um SLA de disponibilidade mais alto de 99,995%.

Recuperação de desastre

Para obter maior disponibilidade e redundância entre regiões, você pode habilitar os recursos de recuperação de desastres para recuperar rapidamente a instância de uma falha regional catastrófica. Opções de recuperação de desastre com a instância gerenciada de SQL do Azure são:

• Os grupos de failover permitem a sincronização contínua entre uma instância primária e secundária. Os grupos de failover fornecem pontos de extremidade de ouvinte de leitura/gravação e somente leitura que permanecem inalterados, portanto, não é necessário atualizar as cadeias de conexão do aplicativo após o failover.
• A restauração geográfica permite que você se recupere de uma interrupção regional restaurando backups duplicados geograficamente quando você não pode acessar seu banco de dados na região primária criando um novo banco de dados em qualquer instância existente em qualquer região do Azure.

Recursos que fornecem continuidade dos negócios

Para uma instância, há quatro cenários principais de interrupção em potencial. A tabela a seguir lista os recursos de continuidade dos negócios da Instância Gerenciada de SQL que você pode usar para mitigar um possível cenário de interrupção dos negócios:

Cenário de interrupção dos negócios	Recursos da continuidade dos negócios
Falhas locais de hardware ou software que afetam o nó do banco de dados.	Para mitigar falhas de hardware e software locais, a Instância Gerenciada de SQL inclui uma arquitetura de alta disponibilidade, que garante a recuperação automática dessas falhas com um SLA de disponibilidade de até 99,99%.
Corrupção ou exclusão de dados geralmente causada por um erro de aplicativo ou erro humano. Essas falhas são específicas do aplicativo e normalmente não podem ser detectadas pelo serviço.	Para proteger seus negócios contra perda de dados, a Instância Gerenciada de SQL cria, de modo automático, backups completos do banco de dados semanalmente, backups diferenciais do banco de dados a cada 12 ou 24 horas e backups do log de transações a cada 5 a 10 minutos. Por padrão, os backups são armazenados em armazenamento com redundância geográfica por sete dias, e suportam um período de retenção de backup configurável para restauração pontual de até 35 dias. Você poderá restaurar um banco de dados excluído para o ponto em que foi excluído, se a instância não tiver sido excluída, ou se você configurou a retenção de longo prazo.
Interrupção rara de datacenter ou zona de disponibilidade, possivelmente causada por uma alteração de configuração, bug de software ou falha de componente de hardware.	Para reduzir a interrupção no nível do datacenter ou da zona de disponibilidade, habilite a redundância de zona para a Instância Gerenciada de SQL para usar as Zonas de Disponibilidade do Azure e forneça redundância em várias zonas físicas em uma região do Azure. A habilitação da redundância de zona garante que a instância gerenciada seja resiliente a falhas zonais com SLA de alta disponibilidade de até 99,995%.
Rara interrupção de região que afeta todas as zonas de disponibilidade e os datacenters que a compõem, possivelmente causada por um evento catastrófico de desastre natural.	Para mitigar uma interrupção em toda a região, habilite a recuperação de desastres usando uma das opções: - Sincronização contínua de dados com grupos de failover para réplicas em uma região secundária usada para failover. - Configuração da redundância de armazenamento de backup para o armazenamento de backup com redundância geográfica para usar a restauração geográfica.

RTO e RPO

Na medida em que você desenvolve o plano de continuidade dos negócios, compreenda qual é o tempo máximo aceitável antes que o aplicativo recupere-se completamente após o evento de interrupção. O tempo necessário para um aplicativo se recuperar totalmente é conhecido como RTO (Objetivo de Tempo de Recuperação). Também é necessário entender o período máximo de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar de um evento com interrupção não planejado. A perda de dados potencial é conhecida como RPO (Objetivo de Tempo de Recuperação).

A seguinte tabela compara o RPO e o RTO de cada opção de continuidade dos negócios:

Opções de continuidade dos negócios	RTO (tempo de inatividade)	RPO (perda de dados)
Alta disponibilidade (habilitando redundância de zona)	Normalmente menos de 30 segundos	0
Recuperação de desastres (habilitando grupos de failover)	1 hora	5 segundos (Depende das alterações de dados antes do evento disruptivo que não foram replicados)
Recuperação de desastre (usando a restauração geográfica)	12 horas	1 hora

Recuperar um banco de dados na mesma região do Azure

Você pode usar backups de banco de dados automáticos para restaurar um banco de dados para um ponto no passado. Assim, você pode se recuperar de corrupções de dados causados por erros humanos. A restauração pontual (PITR) permite que você crie um banco de dados na mesma instância ou em outra, que representa o estado dos dados antes do evento causador da corrupção. A operação de restauração é um tamanho da operação de dados que também depende da carga de trabalho atual da instância de destino. Pode levar mais tempo para recuperar um banco de dados muito grande ou muito ativo. Para obter mais informações sobre tempo de recuperação, consulte tempo de recuperação do banco de dados.

Se o período de retenção de backup máximo com suporte para a PITR (restauração pontual) não for suficiente para o aplicativo, você poderá estendê-lo configurando uma política de LTR (retenção de longo prazo) para os bancos de dados. Para obter mais informações, confira Retenção de backup de longo prazo.

Recuperar um banco de dados para uma instância existente

Embora seja raro, um datacenter do Azure pode ter uma interrupção. Quando uma interrupção ocorre, ela causa uma parada nos negócios, que pode durar alguns minutos ou horas.

• Uma opção é aguardar até que a instância retorne online quando a interrupção do datacenter terminar. Isso funciona para aplicativos que podem manter o banco de dados offline. Por exemplo, um projeto de desenvolvimento ou uma avaliação gratuita não precisam funcionar constantemente. Quando um datacenter sofre uma interrupção, você não sabe quanto tempo ela pode durar. Portanto, essa opção só funcionará se o banco de dados não for necessário por algum tempo.
• Se você estiver usando armazenamento GRS (com redundância geográfica) ou GZRS (com redundância de zona geográfica), outra opção é restaurar um banco de dados para qualquer instância gerenciada de SQL em qualquer região do Azure usando backups de banco de dados com redundância geográfica (restauração geográfica). A restauração geográfica usa um backup com redundância geográfica como sua fonte e pode ser usada para recuperar um banco de dados para o último ponto disponível no tempo, mesmo se o banco de dados ou o datacenter está inacessível devido a uma interrupção. O backup disponível pode ser encontrado na região emparelhada.
• Por fim, você poderá se recuperar rapidamente de uma interrupção se tiver configurado um secundário geográfico usando um grupo de failover para sua instância, usando o failover do cliente (recomendado) ou gerenciado pela Microsoft. Enquanto o próprio failover leva apenas alguns segundos, o serviço levará pelo menos 1 hora para ativar um failover geográfico gerenciado pela Microsoft, se estiver configurado. Isso é necessário para garantir que o failover seja justificado pela escala da interrupção. Além disso, o failover pode resultar na perda de dados alterados recentemente devido à natureza da replicação assíncrona entre as regiões emparelhadas.

Na medida em que você desenvolve o plano de continuidade dos negócios, será necessário compreender qual é o tempo máximo aceitável antes que o aplicativo recupere-se completamente após o evento de interrupção. O tempo necessário para o aplicativo se recuperar totalmente é conhecido como RTO (Objetivo de Tempo de Recuperação). Também é necessário entender o período máximo de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar de um evento com interrupção não planejado. A perda de dados potencial é conhecida como RPO (Objetivo de Tempo de Recuperação).

Métodos de recuperação diferentes oferecem níveis de RPO e RTO diferentes. Você pode escolher um método de recuperação específico ou usar uma combinação de métodos para atingir a recuperação completa do aplicativo.

Use grupos de failover se o aplicativo atender a algum desses critérios:

• Seja crítico.
• Tenha um SLA (Contrato de Nível de Serviço) que não permita um tempo de inatividade de 12 horas ou superior.
• O tempo de inatividade pode resultar em obrigação financeira.
• Ter uma alta taxa de alteração de dados e 1 hora de perda de dados não é aceitável.
• Que o custo adicional da replicação geográfica ativa seja menor que a responsabilidade financeira potencial e das perdas associadas do negócio.

Você poderá optar por usar uma combinação de backups de banco de dados e grupos de failover dependendo dos requisitos da aplicação.

As seções a seguir fornecem uma visão geral das etapas de recuperação usando os backups de banco de dados ou grupos de failover.

Prepare-se para uma interrupção

Independentemente do recurso de continuidade de negócios usados, você deve:

• Identifique e prepare a instância de destino, incluindo as regras de firewall de IP na rede, logons e permissões de nível de banco de dados master.
• Determinar como redirecionar os clientes e aplicativos clientes para a nova instância
• Documentar outras dependências, como as configurações e alertas de auditoria

Se você não se preparar corretamente, colocar seus aplicativos online após um failover ou uma recuperação de banco de dados exigirá um tempo adicional e, provavelmente, a solução de problemas também será exigida em um momento de estresse, ou seja, uma combinação ruim.

Fazer failover em uma instância secundária com replicação geográfica

Se você estiver usando os grupos de failover como mecanismos de recuperação, será possível configurar uma política de failover automático. Depois de iniciado, o failover faz com que a instância secundária se torne o novo primário, pronto para registrar novas transações e responder à consultas, com perda mínima de dados, para os dados que ainda não foram replicados.

Observação

Quando o datacenter volta a ficar online, o primário antigo reconecta-se automaticamente ao novo primário para se tornar a instância secundária. Se você precisar realocar o primário de volta para a região original, poderá iniciar um failover planejado manualmente (failback).

Executar uma restauração geográfica

Se você estiver usando backups automatizados com armazenamento com redundância geográfica (a opção de armazenamento padrão ao criar sua instância), poderá recuperar o banco de dados usando a restauração geográfica. A recuperação normalmente ocorre após 12 horas, com perda de dados de até uma hora determinada pelo momento em que o último backup de log ocorreu e foi replicado. Até que a recuperação seja concluída, o banco de dados não poderá registrar nenhuma transação ou responder a qualquer consulta. Observe que a restauração geográfica só restaura o banco de dados para o último momento disponível.

Observação

Se o datacenter voltar a ficar online antes de você transferir o aplicativo para o banco de dados recuperado, você poderá cancelar a recuperação.

Executar pós-failover / tarefas de recuperação

Após recuperar de um dos mecanismos de recuperação, você deverá executar as seguintes tarefas adicionais antes que os usuários e aplicativos entrem em funcionamento novamente:

• Redirecione os clientes e aplicativos clientes para a nova instância e o banco de dados restaurado.
• Verifique se as regras de firewall de IP de rede adequadas estão em vigor para que os usuários se conectem.
• Verifique se os logons apropriados e as permissões no nível do banco de dados master estão em vigor (ou use os usuários independentes).
• Configurar a auditoria conforme apropriado.
• Configurar os alertas conforme apropriado.

Observação

Se você estiver usando um grupo de failover e se conectar às instâncias usando o ouvinte de leitura/gravação, o redirecionamento após o failover ocorrerá de maneira automática e transparente no aplicativo.

Réplicas de DR sem licença

Você pode economizar nos custos de licença configurando uma Instância Gerenciada de SQL do Azure secundária apenas para recuperação de desastre (DR). Esse benefício estará disponível se você estiver usando um grupo de failover entre duas Instâncias Gerenciadas de SQL ou se tiver configurado um link híbrido entre o SQL Server e a Instância Gerenciada de SQL do Azure. Contanto que a instância secundária não tenha cargas de trabalho de leitura ou gravação e esteja apenas em espera passiva de DR, você não receberá cobrança pelos custos de licenciamento do vCores usados pela instância secundária.

Quando você designa uma instância secundária apenas para recuperação de desastre e nenhuma carga de trabalho de leitura ou gravação está em execução na instância, a Microsoft fornece o número de vCores licenciados para a instância primária sem custo adicional sob o benefício de direitos de failover. Você ainda será cobrado pela computação e armazenamento usados pela instância secundária. Para obter termos e condições precisos do benefício dos direitos de failover híbrido, consulte os termos de licenciamento do SQL Server online na seção "SQL Server: direitos de failover".

O nome do benefício depende do seu cenário:

• Direitos de failover híbridos para uma réplica passiva: ao configurar um link entre o SQL Server e a Instância Gerenciada de SQL do Azure, você pode usar o benefício de direitos de failover híbrido para economizar nos custos de licenciamento do vCore para a réplica secundária passiva.
• Direitos de failover para uma réplica em espera: ao configurar um grupo de failover entre duas instâncias gerenciadas, você pode usar o benefício de direitos de failover para economizar nos custos de licenciamento do vCore para a réplica secundária em espera.

O diagrama a seguir demonstra o benefício para cada cenário.

Próximas etapas

Para saber mais sobre os recursos de continuidade dos negócios, confira Backups automatizados e grupos de failover. Em caso de desastre, confira recuperar um banco de dados.