Share via

Continuidade de negócio e recuperação após desastre para SQL Managed Instance compatíveis com o Azure Arc

  • Artigo

O SQL Managed Instance compatível com o Azure Arc fornece capacidades de continuidade de negócio e recuperação após desastre (BCDR) que ajudam as empresas a recuperar de interrupções e a continuar a operar com um período de indisponibilidade mínimo.

Este artigo fornece considerações e recomendações de conceção fundamentais para configurar e gerir capacidades de continuidade do negócio, como restauro para um ponto anterior no tempo, elevada disponibilidade e recuperação após desastre.

Arquitetura

Os diagramas de arquitetura seguintes mostram as capacidades de elevada disponibilidade do SQL Managed Instance compatível com o Arc no escalão de serviço Crítico para a Empresa, que suporta a ativação pós-falha com um período de indisponibilidade quase nulo. Se a instância primária falhar, o balanceador de carga deixa de enviar tráfego para essa instância. Em seguida, uma das instâncias secundárias é promovida para primária e a instância recentemente promovida começa a receber tráfego de leitura-escrita do balanceador de carga. Depois de a instância com falha voltar a estar online, é adicionada como uma instância secundária.

Um diagrama que mostra o estado operacional de uma instância crítica para a empresa de elevada disponibilidade.

Um diagrama que mostra uma falha na réplica primária e a promoção de 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 seguinte mostra como os SQL Managed Instance compatíveis com o Arc podem ser implementados em dois clusters do Kubernetes separados em dois sites diferentes para recuperação após desastre.

Um diagrama que mostra SQL Managed Instance implementados numa configuração de Recuperação após desastre em dois clusters.

O seguinte diagrama de arquitetura mostra como o SQL Managed Instance compatível com o Arc responde quando é iniciada uma ativação pós-falha de recuperação após desastre.

Um diagrama que mostra a iniciação da ativação pós-falha de recuperação após desastre do Azure Arc ativada SQL Managed Instance em dois clusters.

Considerações de design

Para avaliar o efeito da SQL Managed Instance compatível com o Azure Arc no seu modelo BCDR global, reveja as recomendações bcDR para zonas de destino em Continuidade de negócio e recuperação após desastre. Tenha em atenção que o foco da continuidade de negócio e da recuperação após desastre está apenas nas recomendações de conceção para a continuidade do negócio, mas a elevada disponibilidade e resiliência da sua instância também depende da disponibilidade da infraestrutura do Kubernetes subjacente.

Restauro para um ponto anterior no tempo

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

  • Determine quanto tempo pretende manter e restaurar as cópias de segurança 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 das cópias de segurança. A retenção predefinida é de sete dias. Com esta duração, pode restaurar até sete dias e obter uma cópia de segurança completa, um diferencial diário e cópias de segurança de registos transacionais a cada cinco minutos.

  • Considere a classe de armazenamento a utilizar para o volume persistente para cópias de segurança. Para obter orientações, veja Disciplinas de armazenamento para SQL Managed Instance compatíveis com o Azure Arc.

  • Considere o tamanho do volume persistente para cópias de segurança no contexto do tamanho de dados esperado e do período de retenção configurado.

  • Para obter as melhores práticas de armazenamento, veja Disciplinas de armazenamento para SQL Managed Instance compatíveis com o Azure Arc.

  • As cópias de segurança são sempre executadas na réplica primária. Considere os efeitos de desempenho dos processos de cópia de segurança e restauro ao identificar os recursos alocados à sua instância.

  • Tenha em conta que os restauros para um ponto anterior no tempo de uma base de dados não podem substituir uma base de dados existente. No entanto, podem restaurar dados para uma nova base de dados na mesma instância.

  • Considere os passos adicionais necessários para recuperar totalmente a sua base de dados se a sua aplicação estiver online durante o processo de restauro.

  • Considere os passos adicionais necessários para restaurar uma base de dados para uma instância de várias réplicas, conforme descrito em Restaurar uma base de dados para uma instância de várias réplicas.

  • Determine as ferramentas que os administradores de bases de dados utilizam para configurar e restaurar cópias de segurança. Para obter mais informações, veja Ligar a SQL Managed Instance compatíveis com o Azure Arc.

Elevada disponibilidade

  • Reveja os requisitos de disponibilidade da carga de trabalho e decida qual o escalão de serviço mais adequado para a implementação de SQL Managed Instance compatíveis com o Arc:

    • No escalão de serviço Fins Gerais, existe uma única réplica disponível e a elevada disponibilidade é obtida através da orquestração do Kubernetes.
    • No escalão de serviço Crítico para a Empresa, o SQL Managed Instance compatível com o Azure Arc fornece um grupo de disponibilidade contido, além do que é fornecido nativamente pela orquestração do Kubernetes.

  • Considere os potenciais efeitos empresariais do tempo de inatividade no escalão de serviço Fins Gerais que podem resultar devido à existência de apenas uma réplica.

  • Considere quantas réplicas (uma a três) implementar no escalão de serviço Crítico para a Empresa.

  • Ao implementar uma instância num escalão de serviço Crítico para a Empresa com duas ou mais réplicas, pode configurar as réplicas secundárias como legíveis. Decida o número de réplicas secundárias a implementar no escalão de serviço Crítico para a Empresa. Para obter informações sobre como alterar o número, veja Configurar secundários legíveis.

  • Decida sobre como atribuir prioridades à consistência em relação à disponibilidade através do número de réplicas secundárias necessárias para consolidar uma transação no escalão de serviço Crítico para a Empresa utilizando o parâmetro opcional--sync-secondary-to-commit. Se existirem problemas de conectividade entre as réplicas, o principal poderá não consolidar quaisquer transações:

    • Numa configuração de duas réplicas, uma transação tem de ser consolidada em ambas as réplicas para que a primária receba uma mensagem de êxito.
    • Numa configuração de três réplicas, pelo menos duas das três réplicas têm de consolidar uma transação para devolver uma mensagem de êxito.

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

  • Decida que tipo de serviço do Kubernetes irá utilizar, LoadBalancer ou NodePort. Se utilizar o balanceador de carga, as aplicações poderão voltar a ligar-se ao mesmo ponto final primário e o Kubernetes redirecionará a ligação para o novo principal. Se utilizar a porta do nó, as aplicações têm de voltar a ligar ao novo endereço IP.

Recuperação após desastre

  • As instâncias de SQL Managed Instance compatíveis com o Azure Arc em sites georreplicados e georreplicados secundários têm de ser idênticas na computação e na capacidade, bem como implementadas nos mesmos escalões de serviço.

  • Decida uma localização na qual armazenar os certificados de espelhamento quando criar a configuração de recuperação após desastre acessível por ambos os clusters que alojam a instância.

  • Considere como monitorizar o tempo de inatividade da instância primária para decidir quando efetuar uma ativação pós-falha para a instância secundária.

  • Cada instância tem os seus próprios pontos finais. Considere como as aplicações acederão ao ponto final primário com interrupções mínimas em caso de ativação pós-falha.

Recomendações de conceção

As secções seguintes listam recomendações de conceção para restauro para um ponto anterior no tempo, elevada disponibilidade e recuperação após desastre.

Restauro para um ponto anterior no tempo

Elevada disponibilidade

  • Efetue testes regulares para validar a elevada disponibilidade da sua instância de SQL Managed Instance compatíveis com o Arc. Exemplos de explorações incluem a eliminação de um pod numa instância de Fins Gerais e a falha de uma réplica numa instância de Crítico para a Empresa.

  • Na camada Crítico para a Empresa, implemente uma instância numa configuração de três réplicas em vez de uma configuração de duas réplicas para alcançar uma perda de dados quase nula.

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

  • Reveja as limitações de elevada disponibilidade dos SQL Managed Instance compatíveis com o Azure Arc.

  • Reveja os modos de disponibilidade suportados para decidir qual o modo a utilizar com base nas suas necessidades de elevada disponibilidade.

  • Ao implementar uma instância Crítico para a Empresa com várias réplicas, utilize uma das réplicas secundárias para cargas de trabalho de Leitura. A cadeia de ligação da aplicação tem de especificar o ponto final secundário como serviço de escuta para redirecionamento para as réplicas secundárias. Para obter informações sobre pontos finais, veja Obter os pontos finais primários e secundários e o estado do AG.

  • Para compreender as melhores práticas para monitorizar a disponibilidade das suas instâncias, veja Gestão e monitorização de SQL Managed Instance compatíveis com o Azure Arc.

Recuperação após desastre

  • Certifique-se de que as instâncias de SQL Managed Instance compatíveis com o Arc têm nomes diferentes para sites primários e secundários e que o valor de nome partilhado dos sites é idêntico.

  • Efetue testes regulares de recuperação após desastre para validar o processo de ativação pós-falha.

  • Crie um processo para iniciar ativações pós-falha manuais e forçadas.

  • Para compreender as melhores práticas para monitorizar o estado de funcionamento dos clusters e compreender quando é necessária uma ativação pós-falha, veja Gestão e monitorização de SQL Managed Instance compatíveis com o Azure Arc.

  • Defina o registo DNS para o nome partilhado do grupo de disponibilidade distribuído nos seus servidores DNS para evitar a necessidade de criar manualmente registos DNS durante a ativação pós-falha.

Passos seguintes

Para obter mais informações sobre o seu percurso na cloud híbrida e multicloud, veja os seguintes artigos: