Continuidade de negócios e recuperação de desastres para a Instância Gerenciada SQL habilitada para Azure Arc

A Instância Gerenciada SQL habilitada para Azure Arc fornece recursos para continuidade de negócios e recuperação de desastres (BCDR) que ajudam as empresas a se recuperarem de interrupções e continuarem operando com o mínimo de tempo de inatividade.

Este artigo fornece as principais considerações de design e recomendações para configurar e gerenciar recursos de continuidade de negócios, como restauração point-in-time, alta disponibilidade e recuperação de desastres.

Arquitetura

Os diagramas de arquitetura a seguir mostram os recursos de alta disponibilidade da Instância Gerenciada SQL habilitada para Arc na camada de serviço Business Critical, que oferece suporte a failover com tempo de inatividade quase zero. Se a instância primária falhar, o balanceador de carga interromperá o envio de tráfego para essa instância. Em seguida, uma das instâncias secundárias é promovida para primária e a instância recém-promovida começa a receber tráfego de leitura-gravação do balanceador de carga. Depois que a instância com falha volta a ficar online, ela é adicionada como uma instância secundária.

O diagrama de arquitetura a seguir mostra como a Instância Gerenciada SQL habilitada para Arc pode ser implantada em dois clusters Kubernetes separados em dois locais diferentes para recuperação de desastres.

O diagrama de arquitetura a seguir mostra como a Instância Gerenciada SQL habilitada para Arc responde quando um failover de recuperação de desastres é iniciado.

Considerações de design

Para avaliar o efeito da Instância Gerenciada SQL habilitada para Azure Arc em seu modelo BCDR geral, revise as recomendações do BCDR para zonas de aterrissagem em Continuidade de negócios e recuperação de desastres. Observe que o foco da continuidade de negócios e da recuperação de desastres está nas recomendações de design apenas para continuidade de negócios, mas a alta disponibilidade e a resiliência da sua instância também dependem da disponibilidade da infraestrutura subjacente do Kubernetes.

Restauro para um ponto anterior no tempo

• Defina suas metas para RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e RTO (Recovery Time Objetive, objetivo de tempo de recuperação).

• Determine por quanto tempo você deseja manter e restaurar seus backups dentro dos limites de retenção suportados.

• Considere as implicações para o armazenamento e o custo de aumentar o período de retenção dos backups. A retenção padrão é de sete dias. Com essa duração, você pode restaurar por até sete dias e obter um backup completo, um diferencial diário e backups de logs transacionais a cada cinco minutos.

• Considere qual classe de armazenamento usar para o volume persistente para backups. Para obter orientação, consulte Disciplinas de armazenamento para a Instância Gerenciada SQL habilitada para Azure Arc.

• Considere o tamanho do volume persistente para backups no contexto do tamanho de dados esperado e do período de retenção configurado.

• Para obter as práticas recomendadas para armazenamento, consulte as disciplinas de armazenamento para a Instância Gerenciada SQL habilitada para Azure Arc.

• Os backups são sempre executados na réplica principal. Considere os efeitos de desempenho dos processos de backup e restauração ao identificar os recursos alocados para sua instância.

• Leve em consideração que as restaurações point-in-time de um banco de dados não podem substituir um banco de dados existente. No entanto, eles podem restaurar dados para um novo banco de dados na mesma instância.

• Considere as etapas adicionais necessárias para recuperar totalmente seu banco de dados se seu aplicativo estiver online durante o processo de restauração.

• Considere as etapas adicionais necessárias para restaurar um banco de dados em uma instância de várias réplicas, conforme descrito em Restaurando um banco de dados em uma instância de várias réplicas.

• Determine as ferramentas que os administradores de banco de dados usam para configurar e restaurar backups. Para obter mais informações, consulte Conectar-se à instância gerenciada SQL habilitada para Azure Arc.

Elevada disponibilidade

• Analise os requisitos de disponibilidade de sua carga de trabalho e decida sobre a camada de serviço que é melhor para sua implantação da Instância Gerenciada SQL habilitada para Arc:

  • Na camada de serviço de uso geral, há uma única réplica disponível, e a alta disponibilidade é alcançada por meio da orquestração do Kubernetes.
  • Na camada de serviço Business Critical, a Instância Gerenciada SQL habilitada para Azure Arc fornece um grupo de disponibilidade contido, além do que é fornecido nativamente pela orquestração do Kubernetes.

• Considere os potenciais efeitos comerciais do tempo de inatividade na camada de serviço de uso geral que podem resultar da existência de apenas uma réplica.

• Considere quantas réplicas — uma a três — devem ser implantadas na camada de serviço Crítica para os Negócios.

• Ao implantar uma instância em uma camada de serviço Crítica para os Negócios com duas ou mais réplicas, você pode configurar as réplicas secundárias como legíveis. Decida o número de réplicas secundárias a serem implantadas na camada de serviço Crítica para os Negócios. Para obter informações sobre como alterar o número, consulte Configurar secundários legíveis.

• Decida priorizar a consistência sobre a disponibilidade por meio do número de réplicas secundárias necessárias para confirmar uma transação na camada de serviço Crítica para os Negócios usando o parâmetro opcional --sync-secondary-to-commit. Se houver problemas de conectividade entre as réplicas, o primário pode não confirmar nenhuma transação:

  • Em uma configuração de duas réplicas, uma transação deve ser confirmada em ambas as réplicas para que o primário receba uma mensagem de êxito.
  • Em uma configuração de três réplicas, pelo menos duas das três réplicas devem confirmar uma transação para retornar uma mensagem de êxito.

• Decida se você precisa designar uma réplica específica como principal. Para obter informações sobre como especificar uma réplica primária, consulte Réplica primária preferencial.

• Decida qual tipo de serviço Kubernetes você usará, LoadBalancer ou NodePort. Se você usar o balanceador de carga, os aplicativos poderão se reconectar ao mesmo ponto de extremidade primário e o Kubernetes redirecionará a conexão para o novo primário. Se você usar a porta do nó, os aplicativos deverão se reconectar ao novo endereço IP.

Recuperação após desastre

• As instâncias da Instância Gerenciada SQL habilitada para Arco do Azure em sites geoprimários e geosecundários devem ser idênticas em computação e capacidade, bem como implantadas nas mesmas camadas de serviço.

• Decida um local no qual armazenar os certificados de espelhamento ao criar a configuração de recuperação de desastres acessível por ambos os clusters que hospedam a instância.

• Considere como monitorar o tempo de inatividade da instância primária para decidir quando executar um failover para a instância secundária.

• Cada instância tem seus próprios pontos de extremidade. Considere como seus aplicativos acessarão o ponto de extremidade principal com o mínimo de interrupção em caso de failover.

Recomendações de design

As seções a seguir listam recomendações de design para restauração point-in-time, alta disponibilidade e recuperação de desastres.

Restauro para um ponto anterior no tempo

• Ao implantar uma nova instância da Instância Gerenciada SQL habilitada para Arc, sempre defina a classe de armazenamento para backups para evitar o padrão para a classe de armazenamento de dados.

• Use uma classe de armazenamento que ofereça suporte a ReadWriteMany (RWX) para o volume de backups. Para obter orientação, consulte as disciplinas de Armazenamento para a Instância Gerenciada SQL habilitada para Azure Arc.

• Antes de iniciar uma operação de restauração, use o parâmetro opcional --dry-run para primeiro validar se a operação será bem-sucedida. Para obter mais informações, consulte Criar um banco de dados a partir de um point-in-time usando az CLI.

• Crie um processo para enviar backups que precisam de períodos de retenção mais longos para o Azure ou outro armazenamento frio local.

• Monitore o armazenamento consumido pelos backups para determinar se é possível acomodar uma retenção mais longa, se necessário.

Elevada disponibilidade

• Execute exercícios regulares para validar a alta disponibilidade de sua instância da Instância Gerenciada SQL habilitada para Arc. Exemplos de exercícios incluem a exclusão de um pod em uma instância de uso geral e a falha de uma réplica em uma instância crítica de negócios.

• Na camada Crítica de Negócios, implante uma instância em uma configuração de três réplicas em vez de uma configuração de duas réplicas para obter perda de dados quase nula.

• Para melhor disponibilidade, use o LoadBalancer como o tipo de serviço ao implantar uma instância.

• Analise as limitações de alta disponibilidade da Instância Gerenciada SQL habilitada para Azure Arc.

• Analise os modos de disponibilidade suportados para decidir qual modo usar com base em suas necessidades de alta disponibilidade.

• Ao implantar uma instância crítica de negócios com várias réplicas, use uma das réplicas secundárias para cargas de trabalho de leitura . A cadeia de conexão do aplicativo deve especificar o ponto de extremidade secundário como ouvinte de serviço para redirecionamento para as réplicas secundárias. Para obter informações sobre pontos de extremidade, consulte Obter os pontos de extremidade primários e secundários e o status AG.

• Para entender as práticas recomendadas para monitorar a disponibilidade de suas instâncias, consulte Gerenciamento e monitoramento da Instância Gerenciada SQL habilitada para Azure Arc.

Recuperação após desastre

• Certifique-se de que suas instâncias da Instância Gerenciada SQL habilitada para Arc tenham nomes diferentes para sites primários e secundários e que o valor de nome compartilhado para os sites seja idêntico.

• Execute exercícios regulares de recuperação de desastres para validar o processo de failover.

• Crie um processo para iniciar failovers manuais e forçados.

• Para entender as práticas recomendadas para monitorar a integridade dos clusters e para entender quando um failover é necessário, consulte Gerenciamento e monitoramento da Instância Gerenciada SQL habilitada para Azure Arc.

• Defina o registro DNS para o nome compartilhado do grupo de disponibilidade distribuído em seus servidores DNS para evitar a necessidade de criar manualmente registros DNS durante o failover.

Próximos passos

Para obter mais informações sobre sua jornada de nuvem híbrida e multicloud, consulte os seguintes artigos:

• O que são serviços de dados habilitados para Azure Arc?
• Visão geral: continuidade de negócios da Instância Gerenciada SQL habilitada para Azure Arc
• Validação do Kubernetes dos serviços de dados habilitados para Azure Arc
• Gerencie seu portfólio em operações híbridas e multicloud
• Serviços de dados habilitados para Azure Arc para cenários automatizados com o Azure Arc Jumpstart
• Traga a inovação do Azure para os seus ambientes híbridos com o Azure Arc, um caminho de aprendizagem do Microsoft Learn