Compartilhar via

Configurar um grupo de failover - CLI

  • Artigo

Este artigo explica como configurar a recuperação de desastres para a Instância Gerenciada SQL habilitada pelo Azure Arc com a CLI. Antes de continuar, revise as informações e os pré-requisitos na Instância Gerenciada do SQL habilitada pelo Azure Arc - recuperação de desastres.

Pré-requisitos

Os seguintes pré-requisitos devem ser atendidos antes de configurar grupos de failover entre duas instâncias da Instância Gerenciada SQL habilitada pelo Azure Arc:

  • Um controlador de dados do Azure Arc e uma instância gerenciada SQL habilitada para Arc provisionados no site primário com --license-type como um dos BasePrice ou LicenseIncluded.
  • Um controlador de dados do Azure Arc e uma instância gerenciada SQL habilitada para Arc provisionados no site secundário com configuração idêntica à principal em termos de:
    • CPU
    • Memória
    • Armazenamento
    • Camada de serviço
    • Ordenação
    • Outras configurações de instância
  • A instância no site secundário requer --license-type como DisasterRecovery. Essa instância precisa ser nova, sem nenhum objeto de usuário.

Observação

  • É importante especificar o --license-type durante a criação da instância gerenciada. Isso permitirá que a instância de DR seja semeada da instância primária no data center primário. A atualização dessa propriedade após a implantação não terá o mesmo efeito.

Processo de implantação

Para configurar um grupo de failover do Azure entre duas instâncias, conclua as seguintes etapas:

  1. criar recurso personalizado para o grupo de disponibilidade distribuído no site primário;
  2. criar recurso personalizado para o grupo de disponibilidade distribuído no site secundário;
  3. Copiar os dados binários dos certificados de espelhamento
  4. Configurar o grupo de disponibilidade distribuída entre os sites primário e secundário no modo sync ou no modo async

A imagem a seguir mostra um grupo de disponibilidade distribuído configurado corretamente:

Diagrama mostrando um grupo de disponibilidade distribuído configurado corretamente.

Modos de sincronização

Os grupos de failover nos serviços de dados do Azure Arc dão suporte a dois modos de sincronização - sync e async. O modo de sincronização afeta diretamente como os dados são sincronizados entre as instâncias e, potencialmente, o desempenho na instância gerenciada primária.

Se os sites primário e secundário estiverem a poucos quilômetros um do outro, use o modo sync. Caso contrário, use o modo async para evitar qualquer impacto no desempenho do site primário.

Configurar o grupo de failover do Azure - modo direto

Siga as etapas abaixo se os serviços de dados do Azure Arc forem implantados no directly modo conectado.

Depois que os pré-requisitos forem atendidos, execute o comando abaixo para configurar o grupo de failover do Azure entre as duas instâncias:

az sql instance-failover-group-arc create --name <name of failover group> --mi <primary SQL MI> --partner-mi <Partner MI> --resource-group <name of RG> --partner-resource-group <name of partner MI RG>

Exemplo:

az sql instance-failover-group-arc create --name sql-fog --mi sql1 --partner-mi sql2 --resource-group rg-name --partner-resource-group rg-name

O comando acima:

  • Cria os recursos personalizados necessários em sites primários e secundários
  • Copia os certificados de espelhamento e configura o grupo de failover entre as instâncias

Configurar o grupo de failover do Azure - modo indireto

Siga as etapas abaixo se os serviços de dados do Azure Arc forem implantados no indirectly modo conectado.

  1. Provisionar a instância gerenciada no site primário.

    az sql mi-arc create --name <primaryinstance> --tier bc --replicas 3 --k8s-namespace <namespace> --use-k8s

  2. Alterne o contexto para o cluster secundário executando kubectl config use-context <secondarycluster> e provisione a instância gerenciada no site secundário que será a instância de recuperação de desastres. Neste ponto, os bancos de dados do sistema não fazem parte do grupo de disponibilidade contido.

    Observação

    É importante especificar --license-type DisasterRecoverydurante a instância gerenciada. Isso permitirá que a instância de DR seja semeada da instância primária no data center primário. A atualização dessa propriedade após a implantação não terá o mesmo efeito.

    az sql mi-arc create --name <secondaryinstance> --tier bc --replicas 3 --license-type DisasterRecovery --k8s-namespace <namespace> --use-k8s

  3. Certificados de espelhamento: os dados binários contidos na propriedade Certificado de Espelhamento da instância gerenciada são necessários para a criação do CR (recurso personalizado) do Grupo de Failover da Instância.

    Isso pode ser feito de algumas maneiras:

    (a) Se estiver usando a CLI az, primeiro gere o arquivo de certificado de espelhamento e, em seguida, aponte para esse arquivo enquanto configura o Grupo de Failover da Instância para que os dados binários sejam lidos do arquivo e copiados para o CR. Os arquivos de certificado não são necessários após a criação do grupo de failover.

    (b) Se estiver usando o kubectl, copie e cole diretamente os dados binários do CR da instância gerenciada no arquivo YAML que será usado para criar o Grupo de Failover da Instância.

    Usando (a) acima:

    Crie o arquivo de certificado de espelhamento para a instância primária:

    az sql mi-arc get-mirroring-cert --name <primaryinstance> --cert-file </path/name>.pem​ --k8s-namespace <namespace> --use-k8s

    Exemplo:

    az sql mi-arc get-mirroring-cert --name sqlprimary --cert-file $HOME/sqlcerts/sqlprimary.pem​ --k8s-namespace my-namespace --use-k8s

    Conecte-se ao cluster secundário e crie o arquivo de certificado de espelhamento para a instância secundária:

    az sql mi-arc get-mirroring-cert --name <secondaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s

    Exemplo:

    az sql mi-arc get-mirroring-cert --name sqlsecondary --cert-file $HOME/sqlcerts/sqlsecondary.pem --k8s-namespace my-namespace --use-k8s

    Depois que os arquivos de certificado de espelhamento forem criados, copie o certificado da instância secundária para um caminho compartilhado/local no cluster de instância primária e vice-versa.

  4. Criar o recurso do grupo de failover nos dois sites.

    Observação

    Verifique se as instâncias SQL têm nomes diferentes para sites primários e secundários e se o valor shared-name precisa ser idêntico em ambos os sites.

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary failover group resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s

    Exemplo:

    az sql instance-failover-group-arc create --shared-name myfog --name primarycr --mi sqlinstance1 --role primary --partner-mi sqlinstance2  --partner-mirroring-url tcp://10.20.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance2.pem --k8s-namespace my-namespace --use-k8s

    Na instância secundária, execute o seguinte comando para configurar o recurso personalizado do grupo de failover. O --partner-mirroring-cert-file neste caso deve apontar para um caminho que tenha o arquivo de certificado de espelhamento gerado a partir da instância primária conforme descrito em 3(a) acima.

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for secondary failover group resource> --mi <local SQL managed instance name> --role secondary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<primary IP> --partner-mirroring-cert-file <primary.pem> --k8s-namespace <namespace> --use-k8s

    Exemplo:

    az sql instance-failover-group-arc create --shared-name myfog --name secondarycr --mi sqlinstance2 --role secondary --partner-mi sqlinstance1  --partner-mirroring-url tcp://10.10.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance1.pem --k8s-namespace my-namespace --use-k8s

Recuperar o estado de integridade do grupo de failover do Azure

As informações sobre o grupo de failover, como função primária, função secundária e o status de integridade atual, podem ser exibidas no recurso personalizado no site primário ou secundário.

Execute o comando abaixo no site primário e/ou secundário para listar o recurso personalizado dos grupos de failover:

kubectl get fog -n <namespace>

Descreva o recurso personalizado para recuperar o status do grupo de failover, da seguinte maneira:

kubectl describe fog <failover group cr name> -n <namespace>

Operações de grupos de failover

Depois que o grupo de failover é configurado entre as instâncias gerenciadas, diferentes operações de failover podem ser executadas, dependendo das circunstâncias.

Os possíveis cenários de failover são:

  • As instâncias em ambos os sites estão em estado íntegro e um failover precisa ser executado:

    • executar um failover manual do primário para o secundário sem perda de dados definindo role=secondary na MI SQL primária.

  • O site primário não está íntegro/inacessível e um failover precisa ser executado:

    • a Instância Gerenciada SQL primária habilitada pelo Azure Arc está inativa/não íntegra/inacessível
    • a Instância Gerenciada SQL secundária habilitada pelo Azure Arc precisa ser promovida à força para primária com potencial perda de dados
    • quando a Instância Gerenciada SQL primária original habilitada pelo Azure Arc voltar a ficar online, ela será relatada como Primary função e estado não íntegro e precisará ser forçada a uma função secondary para que possa ingressar no grupo de failover e os dados possam ser sincronizados.

Failover manual (sem perda de dados)

Use az sql instance-failover-group-arc update ... grupo de comandos para iniciar um failover do primário para o secundário. Todas as transações pendentes na instância geográfica primária são replicadas para a instância geográfica secundária antes do failover.

Modo de conexão direta

Execute o seguinte comando para iniciar um failover manual, em direct modo conectado usando APIs ARM:

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <primary instance> --role secondary --resource-group <resource group>

Exemplo:

az sql instance-failover-group-arc update --name myfog --mi sqlmi1 --role secondary --resource-group myresourcegroup

Modo conectado indiretamente

Execute o seguinte comando para iniciar um failover manual, no modo conectado indirect usando APIs do kubernetes:

az sql instance-failover-group-arc update --name <name of failover group resource> --role secondary --k8s-namespace <namespace> --use-k8s

Exemplo:

az sql instance-failover-group-arc update --name myfog --role secondary --k8s-namespace my-namespace --use-k8s

Failover forçado com perda de dados

Na circunstância em que a instância geográfica primária se torna indisponível, os comandos a seguir podem ser executados na instância de recuperação de desastre geográfica secundária para promover para a primária com um failover forçado gerando potencial perda de dados.

Na instância de recuperação de desastre geográfica secundária, execute o comando a seguir para promovê-la para a função primária, com perda de dados.

Observação

Se o --partner-sync-mode foi configurado como sync, ele precisará ser redefinido para async quando o secundário for promovido a principal.

Modo de conexão direta

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <instance> --role force-primary-allow-data-loss --resource-group <resource group> --partner-sync-mode async

Exemplo:

az sql instance-failover-group-arc update --name myfog --mi sqlmi2 --role force-primary-allow-data-loss --resource-group myresourcegroup --partner-sync-mode async

Modo conectado indiretamente

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-primary-allow-data-loss --partner-sync-mode async

Quando a instância primária geográfica ficar disponível, execute o comando abaixo para levá-la para o grupo de failover e sincronizar os dados:

Modo conectado diretamente

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <old primary instance> --role force-secondary --resource-group <resource group>

Modo conectado indiretamente

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-secondary

Opcionalmente, o --partner-sync-mode pode ser configurado de volta para o modo sync, se desejado.

Operações pós-failover

Depois de executar um failover do site primário para o site secundário, com ou sem perda de dados, talvez seja necessário fazer o seguinte:

  • Atualize a cadeia de conexão para que seus aplicativos se conectem à instância gerenciada Arc SQL primária recém-promovida
  • Se você planeja continuar executando a carga de trabalho de produção fora do site secundário, atualize o --license-type para BasePrice ou LicenseIncluded para iniciar o faturamento dos vCores consumidos.

Conteúdo relacionado