Alta Disponibilidade com exemplo gerido pelo SQL com arco Azure

A exemplo gerida pelo Azure Arc é implantada em Kubernetes como uma aplicação contentorizada. Utiliza construções de Kubernetes como conjuntos imponentes e armazenamento persistente para fornecer monitorização de saúde incorporada, deteção de falhas e mecanismos de failover para manter a saúde do serviço. Para uma maior fiabilidade, também pode configurar a SqL Gerditd Instance ativada pelo Arco azul para implementar com réplicas extra numa configuração de alta disponibilidade. A monitorização, deteção de falhas e falha automática são geridas pelo controlador de dados dos serviços de dados do Arco. O serviço de dados via arc-enabled fornece este serviço é fornecido sem a intervenção do utilizador. O serviço configura o grupo de disponibilidade, configura pontos finais espelhados de base de dados, adiciona bases de dados ao grupo de disponibilidade e coordena o failover e o upgrade. Este documento explora ambos os tipos de alta disponibilidade.

A exemplo gerida pelo Azure Arc fornece diferentes níveis de alta disponibilidade, dependendo se a instância gerida pelo SQL foi implantada como um nível de serviço de finalidade geral ou nível de serviço Business Critical .

Alta disponibilidade no nível de serviço de finalidade geral

No nível de serviço De Fim Geral, existe apenas uma réplica disponível, e a alta disponibilidade é alcançada através da orquestração de Kubernetes. Por exemplo, se uma vagem ou nó que contém a imagem do contentor de instância gerida se despenhar, então kubernetes tentará levantar-se de outra vagem ou nó, e anexar-se ao mesmo armazenamento persistente. Durante este período, o exemplo gerido pelo SQL não está disponível para as aplicações. As aplicações terão de voltar a ligar e refazer a transação quando a nova cápsula estiver em cima. Se load balancer for o tipo de serviço utilizado, então as aplicações podem voltar a ligar-se ao mesmo ponto final primário e a Kubernetes irá redirecionar a ligação para o novo primário. Se o tipo de serviço for nodeport , as aplicações terão de voltar a ligar-se ao novo endereço IP.

Verifique a alta disponibilidade incorporada

Para verificar a elevada disponibilidade de construção fornecida pela Kubernetes, pode eliminar o casulo de uma instância gerida existente e verificar se a Kubernetes recupera desta ação, ao colocar outra cápsula e anexar o armazenamento persistente.

Pré-requisitos

  1. Veja as cápsulas.

    kubectl get pods -n <namespace of data controller>
    
  2. Elimine a cápsula de instância gerida.

    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. Veja as cápsulas para verificar se a instância gerida está a recuperar.

    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 de recuperados todos os recipientes dentro da cápsula, pode ligar-se à instância gerida.

Alta disponibilidade no nível de serviço Business Critical

No nível de serviço Business Critical, para além do que é fornecido de forma nativa pela orquestração Kubernetes, a Azure SQL Managed Instance for Azure Arc fornece um grupo de disponibilidade contido. O grupo de disponibilidade contido é construído com a tecnologia SQL Server Always On. Proporciona níveis mais elevados de disponibilidade. A exemplo gerido pelo SQL ativado pelo Azure Arc implementado com o nível de serviço Business Critical pode ser implantado com réplicas de 2 ou 3. Estas réplicas são sempre mantidas sincronizadas umas com as outras. Com grupos de disponibilidade contidos, quaisquer falhas de pod ou nó são transparentes para a aplicação, uma vez que existe pelo menos uma outra cápsula que tem o caso que tem todos os dados da primária e está pronta para assumir as ligações.

Grupos de disponibilidade contidos

Um grupo de disponibilidade liga uma ou mais bases de dados de utilizadores a um grupo lógico para que, quando há uma falha, todo o grupo de bases de dados falhe na réplica secundária como uma única unidade. Um grupo de disponibilidade apenas replica dados nas bases de dados dos utilizadores, mas não nos dados em bases de dados do sistema, tais como logins, permissões ou trabalhos de agentes. Um grupo de disponibilidade contido inclui metadados de bases de dados de sistemas, tais como msdb bases master de dados. Quando os logins são criados ou modificados na réplica primária, também são automaticamente criados nas réplicas secundárias. Da mesma forma, quando um trabalho de agente é criado ou modificado na réplica primária, as réplicas secundárias também recebem essas alterações.

A Azure Arc-enabled SQL Managed Instance pega neste conceito de grupo de disponibilidade contido e adiciona operador Kubernetes para que estes possam ser implantados e geridos em escala.

As capacidades que continham grupos de disponibilidade permitem:

  • Quando implantado com múltiplas réplicas, é criado um único grupo de disponibilidade com o mesmo nome que o Arc enabled SQL. Por padrão, a AG contida tem três réplicas, incluindo primárias. Todas as operações CRUD para o grupo de disponibilidade são geridas internamente, incluindo a criação do grupo de disponibilidade ou a junção de réplicas ao grupo de disponibilidade criado. Grupos de disponibilidade adicionais não podem ser criados na Ocorrência gerida pelo Azure Arc.

  • Todas as bases de dados são automaticamente adicionadas ao grupo de disponibilidade, incluindo todas as bases de dados de utilizadores e sistemas como master e msdb. Esta capacidade fornece uma visão de um sistema em todas as réplicas do grupo de disponibilidade. Note ambas e containedag_msdb bases containedag_master de dados se ligar diretamente ao caso. As containedag_* bases de dados representam o master grupo de disponibilidade e msdb o grupo de disponibilidade.

  • É automaticamente previsto um ponto final externo para a ligação às bases de dados dentro do grupo de disponibilidade. Este ponto final <managed_instance_name>-external-svc desempenha o papel do ouvinte do grupo de disponibilidade.

Implementar exemplo gerido pelo SQL ativado pelo Arco Azure com múltiplas réplicas usando o portal Azure

A partir do portal Azure, na página de exemplo gerida pelo Azure Arc:

  1. Selecione Configurar Compute + Armazenamento em Compute + Armazenamento. O portal mostra configurações avançadas.
  2. No nível de Serviço, selecione Business Critical.
  3. Verifique apenas o "Para uso de desenvolvimento", se utilizar para fins de desenvolvimento.
  4. Em Alta disponibilidade, selecione 2 réplicas ou 3 réplicas.

High availability settings

Implementar Azure Arc-enabled SQL Managed Instance com múltiplas réplicas usando Azure CLI

Quando um SQL Gerido Instância Gerido ativado pelo Arco Azure é implantado no nível de serviço Business Critical, isto permite a criação de múltiplas réplicas. A configuração e configuração de grupos de disponibilidade contidos entre essas instâncias é feita automaticamente durante o provisionamento.

Por exemplo, o seguinte comando cria uma instância gerida com 3 réplicas.

Modo indiretamente ligado:

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 ligado 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 predefinição, todas as réplicas estão configuradas em modo sincronizado. Isto significa que quaisquer atualizações sobre a instância primária serão sincronizadas replicadas em cada uma das instâncias secundárias.

Ver e monitorizar o estado do grupo de disponibilidade

Assim que a implementação estiver concluída, ligue-se ao ponto final primário do SQL Server Management Studio.

Verifique e recupere o ponto final da réplica primária e ligue-a a partir do SQL Server Management Studio. Por exemplo, se a instância SQL foi implantada utilizando service-type=loadbalancer, executar o comando abaixo para recuperar o ponto final para ligar a:

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

ou

kubectl get sqlmi -A

Obtenha os pontos finais primários e secundários e o estado de AG

Utilize os kubectl describe sqlmi comandos ou az sql mi-arc show comandos para visualizar os pontos finais primários e secundários e o estado 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

Exemplo de saída:

 "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"
  }

Pode ligar-se ao ponto final primário acima, utilizando o SQL Server Management Studio e verificar a utilização de 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 do SQL Server Always On, o grupo de disponibilidade contido é uma solução gerida de alta disponibilidade. Assim, os modos de failover são limitados em comparação com os modos típicos disponíveis com sql Server Always On availability groups.

Implementar o nível de serviço de Negócios Critical SQL geriu instâncias em configuração de duas réplicas ou três configurações de réplica. Os efeitos das falhas e a recuperabilidade subsequente são diferentes a cada configuração. Uma instância de réplica de três fornece um nível muito mais alto de disponibilidade e recuperação, do que uma instância de réplica de duas réplicas.

Numa configuração de duas réplicas, quando ambos os estados do nó são SYNCHRONIZED, se a réplica primária ficar indisponível, a réplica secundária é automaticamente promovida para primária. Quando a réplica falhada estiver disponível, será atualizada com todas as alterações pendentes. Se houver problemas de conectividade entre as réplicas, então a réplica primária pode não cometer quaisquer transações, uma vez que cada transação precisa de ser comprometida em ambas as réplicas antes que um sucesso seja devolvido de volta às primárias.

Numa configuração de três réplicas, uma transação precisa de se comprometer em pelo menos 2 das 3 réplicas antes de devolver uma mensagem de sucesso à aplicação. Em caso de falha, um dos secundários é automaticamente promovido a primário enquanto Kubernetes tenta recuperar a réplica falhada. Quando a réplica fica disponível, é automaticamente unida de volta com o 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 dessincronizadas, a réplica primária não cometerá nenhuma transação.

Nota

Recomenda-se a implementação de uma Instância Gerida de SQL De Negócios Numa configuração de três réplicas do que uma configuração de duas réplicas para obter perda de dados quase nulas.

Para falhar da réplica primária para um dos secundários, para um evento planeado, executar o seguinte comando:

Se ligar ao primário, pode usar o T-SQL seguinte para falhar na instância SQL a um dos secundários:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Se ligar ao secundário, pode utilizar o T-SQL para promover a réplica secundária desejada para a réplica primária.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Réplica primária preferida

Também pode definir uma réplica específica para ser a réplica primária usando O CLI AZ da seguinte forma:

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

Nota

Kubernetes tentará definir a réplica preferida, no entanto não está garantida.

Restaurar uma base de dados numa instância multi-réplica

São necessárias etapas adicionais para restaurar uma base de dados num grupo de disponibilidade. Os seguintes passos demonstram como restaurar uma base de dados numa instância gerida e adicioná-la a um grupo de disponibilidade.

  1. Exponha o ponto final externo de instância primária criando um novo serviço Kubernetes.

    Determine a cápsula que acolhe a réplica primária. Ligue-se à instância gerida e corra:

    SELECT @@SERVERNAME
    

    A consulta devolve a cápsula que acolhe a réplica primária.

    Crie o serviço Kubernetes para a primeira instância executando o comando abaixo se o seu cluster Kubernetes utilizar serviços nodePort. Substitua-o podName pelo nome do servidor devolvido na etapa anterior, serviceName com o nome preferido para o serviço Kubernetes criado.

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

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

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

    Aqui está um exemplo desta corrida de comando contra o Serviço Azure Kubernetes, onde o pod que hospeda a primária é sql2-0:

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

    Obtenha o IP do serviço Kubernetes criado:

    kubectl get services -n <namespaceName>
    
  2. Restaurar a base de dados para o ponto final da instância primária.

    Adicione o ficheiro de cópia de segurança da base de dados no recipiente de 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
    

    Restaurar o ficheiro de backup da base 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 a base de dados ao grupo de disponibilidade.

    Para que a base de dados seja adicionada à AG, deve funcionar em modo de recuperação total e tem de ser feita uma cópia de segurança de registo. Execute as declarações da TSQL abaixo para adicionar a base de dados restaurada no 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 acrescenta uma base de dados denominada WideWorldImporters que foi restaurada no caso:

    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 boas práticas, deve eliminar o serviço Kubernetes criado acima, executando este comando:

kubectl delete svc sql2-0-p -n arc

Limitações

Os grupos de disponibilidade de instância gerida pelo Azure Arc têm as mesmas limitações que os grupos de disponibilidade do Big Data Cluster. Para obter mais informações, consulte implementar o SqL Server Big Data Cluster com alta disponibilidade.

Passos seguintes

Saiba mais sobre funcionalidades e capacidades da Azure Arc-enabled SQL Gestd Instance