Alta disponibilidade com a instância gerenciada do SQL habilitada pelo Azure Arc

A Instância Gerenciada de SQL habilitada pelo Azure Arc é implantada no Kubernetes como um aplicativo conteinerizado. Ele usa construções do Kubernetes, como conjuntos com monitoração de estado e armazenamento persistente para fornecer informações internas:

• Monitoramento da integridade
• detecção de falhas
• Failover automático para manter a integridade do serviço.

Para aumentar a confiabilidade, você também pode configurar a Instância Gerenciada de SQL habilitada pelo Azure Arc para implantar com réplicas extras em uma configuração de alta disponibilidade. O controlador de dados dos serviços de dados Arc gerencia:

• Monitoramento
• detecção de falhas
• Failover automático

O serviço de dados habilitado para arco fornece esse serviço sem intervenção do usuário. O serviço:

• Configura o grupo de disponibilidade
• Configura pontos de extremidade de espelhamento de banco de dados
• Adiciona bancos de dados ao grupo de disponibilidade
• Coordena failover e atualização.

Este documento explora os dois tipos de alta disponibilidade.

A Instância Gerenciada de SQL habilitada pelo Azure Arc fornece diferentes níveis de alta disponibilidade, dependendo se a Instância Gerenciada de SQL foi implantada como uma camada de serviço Uso Geral ou uma camada de serviço Comercialmente Crítico.

Alta disponibilidade na camada de serviço Uso Geral

Na camada de serviço Uso Geral, há apenas uma réplica disponível e a alta disponibilidade é obtida por meio da orquestração de Kubernetes. Por exemplo, se um pod ou nó que contém a imagem do contêiner da instância gerenciada falhar, o Kubernetes tentará levantar outro pod ou nó e anexar ao mesmo armazenamento persistente. Durante esse tempo, a instância gerenciada de SQL não está disponível para os aplicativos. Os aplicativos precisam se reconectar e tentar novamente a transação quando o novo pod estiver ativo. Se load balancer for o tipo de serviço usado, 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 o tipo de serviço for nodeport, os aplicativos precisarão se reconectar ao novo endereço IP.

Verificar alta disponibilidade interna

Para verificar a alta disponibilidade de compilação fornecida pelo Kubernetes, você pode:

1. Excluir o pod de uma instância gerenciada existente
2. Verifique se o Kubernetes se recupera dessa ação

Durante a recuperação, o Kubernetes inicializa outro pod e anexa o armazenamento persistente.

Pré-requisitos

• O cluster do Kubernetes requer armazenamento remoto compartilhado
• Uma Instância Gerenciada de SQL habilitada pelo Azure Arc implantada com uma réplica (padrão)

1. Exibir o pods.

   kubectl get pods -n <namespace of data controller>
   

2. Excluir o pod de instância gerenciada.

   kubectl delete pod <name of managed instance>-0 -n <namespace of data controller>
   

   Por exemplo

   user@pc:/# kubectl delete pod sql1-0 -n arc
   pod "sql1-0" deleted
   

3. Exibir o pods para verificar se a instância gerenciada está sendo recuperada.

   kubectl get pods -n <namespace of data controller>
   

   Por exemplo:

   user@pc:/# kubectl get pods -n arc
   NAME                 READY   STATUS    RESTARTS   AGE
   sql1-0               2/3     Running   0          22s
   

Depois que todos os contêineres dentro do pod se recuperarem, você poderá se conectar à instância gerenciada.

Alta disponibilidade na camada de serviço Comercialmente Crítico

Na camada de serviço Business Critical, além do que é fornecido nativamente pela orquestração do Kubernetes, a Instância Gerenciada do SQL para Azure Arc fornece um grupo de disponibilidade contido. O grupo de disponibilidade independente é baseado na tecnologia Always On do SQL Server. Ele fornece níveis mais altos de disponibilidade. A Instância Gerenciada de SQL habilitada pelo Azure Arc implantada com a camada de serviço Comercialmente Crítico pode ser implantada com 2 ou 3 réplicas. Essas réplicas sempre são mantidas sincronizadas entre si.

Com grupos de disponibilidade contidos, quaisquer falhas de pod ou falhas de nó são transparentes para o aplicativo. O grupo de disponibilidade contida fornece pelo menos um outro pod que tem todos os dados do primário e está pronto para assumir conexões.

Grupos de disponibilidade contidos

Um grupo de disponibilidade associa um ou mais bancos de dados de usuário a um grupo lógico para que, quando houver um failover, todo o grupo de bancos de dados faça failover para a réplica secundária como uma única unidade. Um grupo de disponibilidade só faz replica de dados nos bancos de dado do usuário, mas não dos dados em bancos de dado do sistema, como logons, permissões ou trabalhos de agente. Um grupo de disponibilidade contido inclui metadados de bancos de dados do sistema, como bancos de dados do msdb e do master. Quando os logons são criados ou modificados na réplica primária, eles também são criados nas réplicas secundárias automaticamente. Assim, quando um trabalho do agente é criado ou modificado na réplica primária, as réplicas secundárias também recebem alterações.

A Instância Gerenciada de SQL habilitada pelo Azure Arc usa esse conceito de grupo de disponibilidade contido e adiciona o operador do Kubernetes para que eles possam ser implantados e gerenciados em escala.

Recursos que os grupos de disponibilidade contidos habilitam:

• Quando implantado com várias réplicas, é criado um único grupo de disponibilidade com o mesmo nome que a instância gerenciada de SQL habilitada para Arc. Por padrão, GA contidos têm três réplicas, incluindo a primária. Todas as operações CRUD para o grupo de disponibilidade são gerenciadas internamente, incluindo a criação do grupo de disponibilidade ou a adição de réplicas ao grupo de disponibilidade criado. Não é possível criar mais grupos de disponibilidade em uma instância.

• Todos os bancos de dados são adicionados automaticamente ao grupo de disponibilidade, incluindo todos os bancos de dados do usuário e do sistema, como master e msdb. Essa funcionalidade fornece um modo de exibição do sistema único entre as réplicas do grupo de disponibilidade. Observe os bancos de dados containedag_master e containedag_msdb se você se conectar diretamente à instância. Os bancos de dados do containedag_* representam o master e o msdb dentro do grupo de disponibilidade.

• Um ponto de extremidade externo é provisionado automaticamente para conectar-se a bancos de dados dentro do grupo de disponibilidade. Esse ponto de extremidade <managed_instance_name>-external-svc desempenha a função do ouvinte do grupo de disponibilidade.

Implantar a Instância Gerenciada SQL habilitada pelo Azure Arc com várias réplicas usando o portal do Azure

No portal do Azure, na página Criar Instância Gerenciada SQL habilitada pelo Azure Arc:

1. Selecione Configurar computação + Armazenamento em Computação + Armazenamento. O portal mostra as configurações avançadas.
2. Em camada de serviço, selecione Comercialmente Crítico.
3. Marque "Usar somente para desenvolvimento", se estiver usando para fins de desenvolvimento.
4. Em alta disponibilidade, selecione 2 réplicas ou 3 réplicas.

Implantar com várias réplicas usando a CLI do Azure

Quando uma Instância Gerenciada SQL habilitada pelo Azure Arc é implantada na camada de serviço Business Critical, a implantação cria várias réplicas. A definição e a configuração de grupos de disponibilidade contidos entre essas instâncias são feitas automaticamente durante o provisionamento.

Por exemplo, o comando a seguir cria uma instância gerenciada com 3 réplicas.

Modo de conexão indireta:

az sql mi-arc create -n <instanceName> --k8s-namespace <namespace> --use-k8s --tier <tier> --replicas <number of replicas>

Exemplo:

az sql mi-arc create -n sqldemo --k8s-namespace my-namespace --use-k8s --tier BusinessCritical --replicas 3

Modo de conexão direta:

az sql mi-arc create --name <name> --resource-group <group>  --location <Azure location> –subscription <subscription>  --custom-location <custom-location> --tier <tier> --replicas <number of replicas>

Exemplo:

az sql mi-arc create --name sqldemo --resource-group rg  --location uswest2 –subscription xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --custom-location private-location --tier BusinessCritical --replcias 3

Por padrão, todas as réplicas são configuradas no modo síncrono. Isso significa que todas as atualizações na instância primária são replicadas de forma síncrona para cada uma das instâncias secundárias.

Exibir e monitorar o status de alta disponibilidade

Depois que a implantação for concluída, conecte-se ao ponto de extremidade primário do SQL Server Management Studio.

Verifique e recupere o ponto de extremidade da réplica primária e conecte-se a ele do SQL Server Management Studio. Por exemplo, se a instância de SQL foi implantada usando service-type=loadbalancer, execute o comando abaixo para recuperar o ponto de extremidade para conectar-se a:

az sql mi-arc list --k8s-namespace my-namespace --use-k8s

or

kubectl get sqlmi -A

Obtenha os pontos de extremidade primários e secundários e o status do GA

Use os comandos kubectl describe sqlmi ou az sql mi-arc show para exibir os pontos de extremidade primários e secundários e o status de alta disponibilidade.

Exemplo:

kubectl describe sqlmi sqldemo -n my-namespace

or

az sql mi-arc show --name sqldemo --k8s-namespace my-namespace --use-k8s

Exemplo de saída:

 "status": {
    "endpoints": {
      "logSearchDashboard": "https://10.120.230.404:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqldemo'))",
      "metricsDashboard": "https://10.120.230.46:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqldemo-0",
      "mirroring": "10.15.100.150:5022",
      "primary": "10.15.100.150,1433",
      "secondary": "10.15.100.156,1433"
    },
    "highAvailability": {
      "healthState": "OK",
      "mirroringCertificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
    },
    "observedGeneration": 1,
    "readyReplicas": "2/2",
    "state": "Ready"
  }

Você pode se conectar ao ponto de extremidade primário com o SQL Server Management Studio e verificar os DMVs como:

SELECT * FROM sys.dm_hadr_availability_replica_states

E o painel de disponibilidade contido:

Cenários de failover

Ao contrário dos grupos de disponibilidade Always On do SQL Server, o grupo de disponibilidade contido é uma solução gerenciada de alta disponibilidade. Assim, os modos de failover são limitados em comparação com os modos típicos disponíveis com grupos de disponibilidade Always On do SQL Server.

Implantar instâncias gerenciadas de SQL da camada de serviço Comercialmente Crítico em uma configuração de duas ou de três réplicas. Os efeitos das falhas e a capacidade de recuperação subsequente são diferentes com cada configuração. Uma instância de três réplicas fornece um nível mais alto de disponibilidade e recuperação do que uma instância de duas réplicas.

Em uma configuração de duas réplicas, quando os dois estados de nó são SYNCHRONIZED, se a réplica primária ficar indisponível, a réplica secundária será automaticamente promovida para a primária. Quando a réplica com falha fica disponível, ela é atualizada com todas as alterações pendentes. Se houver problemas de conectividade entre as réplicas, a réplica primária poderá não confirmar as transações, pois cada transação precisará ser confirmada em nas duas réplicas antes que um êxito seja retornado na primária.

Em uma configuração de três réplicas, uma transação precisa ser confirmada em pelo menos duas das três réplicas antes de retornar uma mensagem de êxito de volta para o aplicativo. Em caso de falha, uma dos secundárias é promovida automaticamente para primária enquanto o Kubernetes tenta recuperar a réplica com falha. Quando a réplica fica disponível, ela é automaticamente reintegrada ao grupo de disponibilidade contido e as alterações pendentes são sincronizadas. Se houver problemas de conectividade entre as réplicas e mais de 2 réplicas estiverem fora de sincronia, a réplica primária não confirmará nenhuma transação.

Observação

É recomendável implantar uma Instância Gerenciada de SQL Comercialmente Crítico em uma configuração de três réplicas do que uma configuração de duas réplicas para obter perda de dados quase zero.

Execute o seguinte comando para fazer failover da réplica primária para uma das secundárias, para um evento planejado:

se você se conectar à primária, poderá usar o T-SQL a seguir para fazer failover da instância de SQL para uma das secundárias:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

se você se conectar à secundária, poderá usar o T-SQL a seguir para promover a réplica secundária desejada para a primária.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Réplica primária preferencial

Você também pode definir uma réplica específica para ser a réplica primária usando a CLI do AZ da seguinte maneira:

az sql mi-arc update --name <sqlinstance name> --k8s-namespace <namespace> --use-k8s --preferred-primary-replica <replica>

Exemplo:

az sql mi-arc update --name sqldemo --k8s-namespace my-namespace --use-k8s --preferred-primary-replica sqldemo-3

Observação

O Kubernetes tentará definir a réplica preferencial, no entanto, não é garantido.

Restaurar um banco de dados em uma instância de várias réplicas

Etapas adicionais são necessárias para restaurar um banco de dados em um grupo de disponibilidade. As etapas a seguir demonstram como restaurar um banco de dados em uma instância gerenciada e adicioná-lo a um grupo de disponibilidade.

1. Expor o ponto de extremidade externo de instância primária criando um novo serviço do Kubernetes.

   Determine o pod que hospeda a réplica primária. Conecte-se à instância gerenciada e execute:

   SELECT @@SERVERNAME
   

   A consulta retorna o pod que hospeda a réplica primária.

   Crie o serviço Kubernetes para a instância primária executando o seguinte comando se o cluster do Kubernetes usar NodePort serviços. Substitua <podName> pelo nome do servidor retornado na etapa anterior, <serviceName> pelo nome preferencial para o serviço de Kubernetes criado.

   kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
   

   Para um serviço LoadBalancer, execute o mesmo comando, exceto que o tipo do serviço criado é LoadBalancer. Por exemplo:

   kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
   

   Aqui está um exemplo desse comando executado no Serviço de Kubernetes do Azure, em que o pod que hospeda o primário é sql2-0:

   kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
   

   Obtenha o IP do serviço de Kubernetes criado:

   kubectl get services -n <namespaceName>
   

2. Restaure o banco de dados para o ponto de extremidade da instância primária.

   Adicione o arquivo de backup de banco de dados ao contêiner da instância primária.

   kubectl cp <source file location> <pod name>:var/opt/mssql/data/<file name> -c <serviceName> -n <namespaceName>
   

   Exemplo

   kubectl cp /home/WideWorldImporters-Full.bak sql2-1:var/opt/mssql/data/WideWorldImporters-Full.bak -c arc-sqlmi -n arc
   

   Restaure o arquivo de backup do banco de dados executando o comando abaixo.

   RESTORE DATABASE test FROM DISK = '/var/opt/mssql/data/<file name>.bak'
   WITH MOVE '<database name>' to '/var/opt/mssql/data/<file name>.mdf'  
   ,MOVE '<database name>' to '/var/opt/mssql/data/<file name>_log.ldf'  
   ,RECOVERY, REPLACE, STATS = 5;  
   GO
   

   Exemplo

   RESTORE Database WideWorldImporters
   FROM DISK = '/var/opt/mssql/data/WideWorldImporters-Full.BAK'
   WITH
   MOVE 'WWI_Primary' TO '/var/opt/mssql/data/WideWorldImporters.mdf',
   MOVE 'WWI_UserData' TO '/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
   MOVE 'WWI_Log' TO '/var/opt/mssql/data/WideWorldImporters.ldf',
   MOVE 'WWI_InMemory_Data_1' TO '/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
   RECOVERY, REPLACE, STATS = 5;  
   GO
   

3. Adicione um banco de dados ao grupo de disponibilidade.

   Para que o banco de dados seja adicionado ao AG, ele deve ser executado no modo de recuperação completa e deve ser feito um backup do log. Execute as instruções TSQL abaixo para adicionar o banco de dados restaurado ao grupo de disponibilidade.

   ALTER DATABASE <databaseName> SET RECOVERY FULL;
   BACKUP DATABASE <databaseName> TO DISK='<filePath>'
   ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
   

   O exemplo a seguir adiciona um banco de dados chamado WideWorldImporters que foi restaurado na instância:

   ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
   BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
   ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
   

Importante

Como melhor prática, exclua o serviço de Kubernetes criado acima executando este comando:

kubectl delete svc sql2-0-p -n arc

Limitações

Os grupos de disponibilidade da Instância Gerenciada de SQL habilitada pelo Azure Arc tem as mesmas limitações que os grupos de disponibilidade do cluster de Big Data. Para obter mais informações, confira Implantar o cluster de Big Data do SQL Server com alta disponibilidade.

Conteúdo relacionado

Saiba mais sobre os recursos e as funcionalidades da Instância Gerenciada de SQL habilitada pelo Azure Arc