Alta disponibilidade com a Instância Gerenciada de SQL habilitada para Azure Arc

A Instância Gerenciada de SQL habilitada para Azure Arc é implantada no Kubernetes como um aplicativo conteinerizado. Ela usa constructos de Kubernetes como conjuntos com estado e armazenamento persistente para fornecer monitoramento de integridade interno, detecção de falha e mecanismos de failover para manter a integridade do serviço. Para maior confiabilidade, você também pode configurar a Instância Gerenciada de SQL habilitada para o Azure Arc para implantar com réplicas extras em uma configuração de alta disponibilidade. O monitoramento, a detecção de falhas e o failover automático são gerenciados pelo controlador de dados dos serviços de dados do Arc. O serviço de dados habilitado para Arc fornece esse serviço, e ele é fornecido sem intervenção do usuário. O serviço configura o grupo de disponibilidade, configura os pontos de extremidade de espelhamento de banco de dados, adiciona bancos de dados ao grupo de disponibilidade e coordena o failover e a atualização. Este documento explora os dois tipos de alta disponibilidade.

A Instância Gerenciada de SQL habilitada para 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 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 de contêiner de instância gerenciada falhar, o Kubernetes tentará abrir 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 precisarão se reconectar e repetir 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 interna fornecida pelo Kubernetes, você pode excluir o pod de uma instância gerenciada existente e verificar se o Kubernetes se recupera dessa ação inicializando outro pod e anexando o armazenamento persistente.

Pré-requisitos

  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 tiverem sido recuperados, você poderá se conectar à instância gerenciada.

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

Na camada de serviço Comercialmente Crítico, além do que é fornecido nativamente pela orquestração do Kubernetes, a Instância Gerenciada de SQL do Azure para Azure Arc fornece um grupo de disponibilidade independente. 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 para Azure Arc implantada com a camada de serviço Comercialmente Crítico pode ser implantada com duas ou três réplicas. Essas réplicas sempre são mantidas sincronizadas entre si. Nos grupos de disponibilidade independentes, toda falha de pod ou de nó fica transparente para o aplicativo, pois há, pelo menos, outro pod que tenha a instância contendo todos os dados do primário e esteja pronta para fazer 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 para Azure Arc usa esse conceito de grupo de disponibilidade contido e adiciona o operador de 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. Grupos de disponibilidade adicionais não podem ser criados na Instância Gerenciada de SQL habilitada para o Azure Arc.

  • 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 de SQL habilitada para Azure Arc com várias réplicas usando o portal do Azure

No portal do Azure, na página criar Instância Gerenciada de SQL habilitada para 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.

High availability settings

Implantar a Instância Gerenciada de SQL habilitada para Azure Arc com várias réplicas usando a CLI do Azure

Quando uma Instância Gerenciada de SQL habilitada para Azure Arc é implantada na camada de serviço Comercialmente Crítico, isso permite que várias réplicas sejam criadas. 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 conectado indiretamente:

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 conectado diretamente:

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 serão replicadas de forma síncrona para cada uma das instâncias secundárias.

Exibir e monitorar o status do grupo de 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

ou

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 do grupo de disponibilidade.

Exemplo:

kubectl describe sqlmi sqldemo -n my-namespace

ou

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

Saída de exemplo:

 "status": {
    "AGStatus": "Healthy",
    "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=sqlmi1-0",
    "mirroringEndpoint": "10.15.100.150:5022",
    "observedGeneration": 1,
    "primaryEndpoint": "10.15.100.150,1433",
    "readyReplicas": "2/2",
    "runningVersion": "v1.2.0_2021-12-15",
    "secondaryEndpoint": "10.15.100.156,1433",
    "state": "Ready"
  }

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

SELECT * FROM sys.dm_hadr_availability_replica_states

Availability Group

E o painel de disponibilidade contido:

Container Availability Group dashboard

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 da capacidade de recuperação subsequente é diferente em cada configuração. Uma instância de três réplicas fornece um nível muito 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 se tornar disponível, ela será 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 ingressada no grupo de disponibilidade contido e as alterações pendentes são sincronizadas. Se houver problemas de conectividade entre as réplicas e mais de duas 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 comando abaixo se o cluster Kubernetes usar serviços nodePort. 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 para o Azure Arc têm 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.

Próximas etapas

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