Compartilhar via

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

  • Artigo

A Instância Gerenciada SQL habilitada para Arco do Azure 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 a 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 voltar a ficar online, ela será adicionada como uma instância secundária.

Um diagrama que mostra o estado operacional de uma instância crítica de negócios altamente disponível.

Um diagrama que mostra uma falha na réplica primária e promove uma réplica secundária para primária.

Um diagrama que mostra a falha da réplica primária.

Um diagrama que mostra o estado operacional restaurado.

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.

Um diagrama que mostra a Instância Gerenciada SQL habilitada para Arco do Azure implantada em uma configuração de recuperação de desastres em dois clusters.

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.

Um diagrama que mostra o início do failover de recuperação de desastres da Instância Gerenciada SQL habilitada para Arco do Azure em dois clusters.

Considerações sobre o design

Para avaliar o efeito da Instância Gerenciada SQL habilitada para Arco do Azure em seu modelo BCDR geral, revise as recomendações de 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 de sua instância também dependem da disponibilidade da infraestrutura subjacente do Kubernetes.

Restauração em um momento determinado

  • Defina suas metas para o RPO (recovery point objective, objetivo do ponto de recuperação) e RTO (recovery time objective, objetivo do tempo de recuperação).

  • Determine por quanto tempo você deseja reter 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 de seus 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 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 de 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 primária. Considere os efeitos de desempenho dos processos de backup e restauração ao identificar os recursos alocados à 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 o banco de dados se o aplicativo estiver online durante o processo de restauração.

  • Considere as etapas extras 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 arco do Azure.

Alta disponibilidade

  • Revise os requisitos de disponibilidade de sua carga de trabalho e decida sobre a camada de serviço que é melhor para sua implantação de 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 é obtida por meio da orquestração do Kubernetes.
    • Na camada de serviço Business Critical, a Instância Gerenciada SQL habilitada para Arco do Azure 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 Business Critical.

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

  • Decida sobre 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 Business Critical 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 a principal 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 do 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 principal. Se você usar a porta do nó, os aplicativos deverão se reconectar ao novo endereço IP.

Recuperação de 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 sobre 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 primário com o mínimo de interrupção em caso de failover.

Recomendações sobre design

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

Restauração em um momento determinado

  • 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 Arco do Azure.

  • 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 você pode acomodar uma retenção mais longa, se necessário.

Alta disponibilidade

  • Execute drills regulares para validar a alta disponibilidade de sua instância do Arc-enabled SQL Managed Instance. Exemplos de drills incluem a exclusão de um pod em uma instância de Propósito Geral e a falha de uma réplica em uma instância de Crítica de Negócios.

  • Na camada Business Critical, 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 próxima de zero.

  • Para obter melhor disponibilidade, use 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 Arco do Azure.

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

  • Ao implantar uma instância crítica para os 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 de desastre

Próximas etapas

Para obter mais informações sobre o percurso de nuvem híbrida e multicloud, confira os seguintes artigos: