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

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

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

Arquitetura

Os diagramas de arquitetura a seguir mostram os recursos de alta disponibilidade do Instância Gerenciada de SQL habilitado para Arc na camada de serviço Comercialmente Crítico, que dá suporte ao 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 voltar a ficar online, ela será adicionada como uma instância secundária.

O diagrama de arquitetura a seguir mostra como os Instância Gerenciada de SQL habilitados para Arc podem ser implantados em dois clusters kubernetes separados em dois locais diferentes para recuperação de desastre.

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

Considerações sobre o design

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

Restauração em um momento determinado

• Defina seus destinos para RPO ( objetivo de ponto de recuperação ) e RTO ( objetivo de tempo de recuperação ).

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

• 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 diretrizes, consulte Disciplinas de armazenamento para Instância Gerenciada de SQL habilitados 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, confira As disciplinas de armazenamento para Instância Gerenciada de SQL habilitadas para Azure Arc.

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

• Leve em conta que as restaurações pontuais 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éplica, conforme descrito em Restaurando um banco de dados em uma instância de várias réplica.

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

Alta disponibilidade

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

  • Na camada de serviço 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 Comercialmente Crítico, o Instância Gerenciada de SQL habilitado para Azure Arc fornece um grupo de disponibilidade independente, além do que é fornecido nativamente pela orquestração do Kubernetes.

• Considere os possíveis efeitos de negócios do tempo de inatividade na camada de serviço Uso Geral que pode resultar devido à existência de apenas um réplica.

• Considere quantas réplicas, uma a três, devem ser implantadas na camada de serviço Comercialmente Crítico.

• Ao implantar uma instância em uma camada de serviço Comercialmente Crítico 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 Comercialmente Crítico. Para obter informações sobre como alterar o número, consulte Configurar secundários legíveis.

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

  • Em uma configuração de dois réplica, uma transação deve ser confirmada em ambas as réplicas para que a primária receba uma mensagem de êxito.
  • Em uma configuração de três réplica, 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 primária. Para obter informações sobre como especificar um réplica primário, consulte Réplica primário 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 primário. 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 de Instância Gerenciada de SQL habilitadas para Azure Arc em sites geográficos primários e geográficos secundários devem ser idênticas na computação e na 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 desastre 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 interrupção mínima em caso de failover.

Recomendações sobre design

As seções a seguir listam as recomendações de design para restauração pontual, alta disponibilidade e recuperação de desastre.

Restauração em um momento determinado

• Ao implantar uma nova instância do Instância Gerenciada de SQL habilitado 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 dê suporte a ReadWriteMany (RWX) para o volume de backups. Para obter diretrizes, consulte As disciplinas de armazenamento para Instância Gerenciada de SQL habilitados 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 seria bem-sucedida. Para obter mais informações, consulte Criar um banco de dados de um ponto no tempo 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 análises regulares para validar a alta disponibilidade da instância do Instância Gerenciada de SQL habilitado para Arc. Exemplos de análises incluem a exclusão de um pod em uma instância de Uso Geral e a falha de um réplica em uma instância de Comercialmente Crítico.

• Na camada Comercialmente Crítico, implante uma instância em uma configuração de três réplica em vez de uma configuração de dois réplica para obter perda de dados quase zero.

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

• Examine as limitações de alta disponibilidade do Instância Gerenciada de SQL habilitado para Azure Arc.

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

• Ao implantar uma instância de Comercialmente Crítico 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 status do AG.

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

Recuperação de desastre

• Verifique se as instâncias de Instância Gerenciada de SQL habilitadas para Arc têm nomes diferentes para sites primários e secundários e se o valor de nome compartilhado para os sites é idêntico.

• Execute análises regulares de recuperação de desastre 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 entender quando um failover é necessário, consulte Gerenciamento e monitoramento para Instância Gerenciada de SQL habilitados 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óximas etapas

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

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