Disponibilità elevata con Istanza gestita di SQL abilitata da Azure Arc

Istanza gestita di SQL abilitato da Azure Arc viene distribuito in Kubernetes come applicazione in contenitori. Usa costrutti Kubernetes, ad esempio set con stato e archiviazione permanente per fornire la funzionalità predefinita:

• Monitoraggio dell’integrità
• rilevamento degli errori
• Failover automatico per mantenere l'integrità dei servizi.

Per una maggiore affidabilità, è anche possibile configurare Istanza gestita di SQL abilitata da Azure Arc per la distribuzione con repliche aggiuntive in una configurazione a disponibilità elevata. Il titolare del trattamento dei dati di Arc Data Services gestisce:

• Monitoraggio
• rilevamento degli errori
• Automatic failover

Il servizio dati abilitato per Arc fornisce questo servizio senza l'intervento dell'utente. Il servizio:

• Configura il gruppo di disponibilità
• Configura gli endpoint del mirroring del database
• Aggiunge database al gruppo di disponibilità
• Coordina il failover e l'aggiornamento.

Questo documento illustra entrambi i tipi di disponibilità elevata.

Istanza gestita di SQL abilitato da Azure Arc offre diversi livelli di disponibilità elevata a seconda che l'istanza gestita di SQL sia stata distribuita come Livello di servizio per utilizzo generico o livello di servizio Business Critical.

Disponibilità elevata nel livello di servizio Per utilizzo generico

Nel livello di servizio Per utilizzo generico è disponibile una sola replica e la disponibilità elevata viene ottenuta tramite l'orchestrazione kubernetes. Ad esempio, se un pod o un nodo contenente l'immagine del contenitore dell'istanza gestita si arresta in modo anomalo, Kubernetes tenta di gestire un altro pod o nodo e collegarsi alla stessa risorsa di archiviazione persistente. Durante questo periodo, l'istanza gestita di SQL non è disponibile per le applicazioni. Le applicazioni devono riconnettersi e ripetere la transazione quando il nuovo pod è in esecuzione. Se load balancer è il tipo di servizio usato, le applicazioni possono riconnettersi allo stesso endpoint primario e Kubernetes reindirizzerà la connessione al nuovo database primario. Se il tipo di servizio è nodeport , le applicazioni dovranno riconnettersi al nuovo indirizzo IP.

Verificare la disponibilità elevata predefinita

Per verificare la disponibilità elevata della build fornita da Kubernetes, è possibile:

1. Eliminare il pod di un'istanza gestita esistente
2. Verificare che Kubernetes si ripristini da questa azione

Durante il ripristino, Kubernetes esegue il bootstrap di un altro pod e collega l'archiviazione permanente.

Prerequisiti

• Il cluster Kubernetes richiede l'archiviazione remota condivisa
• Un Istanza gestita di SQL abilitato da Azure Arc distribuito con una replica (impostazione predefinita)

1. Visualizzare i pod.

   kubectl get pods -n <namespace of data controller>
   

2. Eliminare il pod dell'istanza gestita.

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

   Ad esempio:

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

3. Visualizzare i pod per verificare che l'istanza gestita stia ripristinando.

   kubectl get pods -n <namespace of data controller>
   

   Ad esempio:

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

Dopo il ripristino di tutti i contenitori all'interno del pod, è possibile connettersi all'istanza gestita.

Disponibilità elevata nel livello di servizio Business Critical

Nel livello di servizio Business Critical, oltre a quello fornito in modo nativo dall'orchestrazione Kubernetes, Istanza gestita di SQL per Azure Arc fornisce un gruppo di disponibilità indipendente. Il gruppo di disponibilità indipendente è basato sulla tecnologia SQL Server Always On. Offre livelli di disponibilità più elevati. Istanza gestita di SQL abilitato da Azure Arc distribuito con Il livello di servizio Business Critical può essere distribuito con 2 o 3 repliche. Queste repliche vengono sempre sincronizzate tra loro.

Con i gruppi di disponibilità contenuti, eventuali arresti anomali dei pod o errori dei nodi sono trasparenti per l'applicazione. Il gruppo di disponibilità indipendente fornisce almeno un altro pod che contiene tutti i dati del database primario ed è pronto per acquisire connessioni.

Gruppi di disponibilità indipendenti

Un gruppo di disponibilità associa uno o più database utente a un gruppo logico in modo che, quando si verifica un failover, l'intero gruppo di database esegue il failover nella replica secondaria come singola unità. Un gruppo di disponibilità replica solo i dati nei database utente, ma non i dati nei database di sistema, ad esempio account di accesso, autorizzazioni o processi dell'agente. Un gruppo di disponibilità indipendente include metadati di database di sistema, msdb ad esempio e master database. Quando gli account di accesso vengono creati o modificati nella replica primaria, vengono creati automaticamente anche nelle repliche secondarie. Analogamente, quando un processo dell'agente viene creato o modificato nella replica primaria, le repliche secondarie ricevono anche tali modifiche.

Istanza gestita di SQL abilitato da Azure Arc accetta questo concetto di gruppo di disponibilità indipendente e aggiunge l'operatore Kubernetes in modo che possano essere distribuiti e gestiti su larga scala.

Le funzionalità che contengono gruppi di disponibilità abilitano:

• Quando viene distribuito con più repliche, viene creato un singolo gruppo di disponibilità denominato con lo stesso nome dell'istanza gestita di SQL abilitata per Arc. Per impostazione predefinita, il gruppo di disponibilità indipendente include tre repliche, tra cui la replica primaria. Tutte le operazioni CRUD per il gruppo di disponibilità vengono gestite internamente, inclusa la creazione del gruppo di disponibilità o l'aggiunta di repliche al gruppo di disponibilità creato. Non è possibile creare più gruppi di disponibilità in un'istanza di .

• Tutti i database vengono aggiunti automaticamente al gruppo di disponibilità, inclusi tutti i database utente e di sistema come master e msdb. Questa funzionalità offre una vista a singolo sistema di tutte le repliche del gruppo di disponibilità. Si notino entrambi i containedag_master database e containedag_msdb se ci si connette direttamente all'istanza di . I database containedag_* rappresentano i database master e msdb all'interno del gruppo di disponibilità.

• Viene effettuato il provisioning automatico di un endpoint esterno per la connessione ai database all'interno del gruppo di disponibilità. Questo endpoint <managed_instance_name>-external-svc ha il ruolo di listener del gruppo di disponibilità.

Distribuire Istanza gestita di SQL abilitati da Azure Arc con più repliche usando portale di Azure

Da portale di Azure, nella pagina Crea Istanza gestita di SQL abilitata da Azure Arc:

1. Selezionare Configura calcolo e Archiviazione in Calcolo e Archiviazione. Il portale mostra le impostazioni avanzate.
2. In Livello di servizio selezionare Business Critical.
3. Controllare l'opzione "Solo per lo sviluppo", se si usa a scopo di sviluppo.
4. In Disponibilità elevata selezionare 2 repliche o 3 repliche.

Eseguire la distribuzione con più repliche usando l'interfaccia della riga di comando di Azure

Quando un Istanza gestita di SQL abilitato da Azure Arc viene distribuito nel livello di servizio Business Critical, la distribuzione crea più repliche. L'installazione e la configurazione dei gruppi di disponibilità indipendenti tra tali istanze vengono eseguite automaticamente durante il provisioning.

Ad esempio, il comando seguente crea un'istanza gestita con 3 repliche.

Modalità connessa indirettamente:

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

Esempio:

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

Modalità connessa diretta:

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>

Esempio:

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

Per impostazione predefinita, tutte le repliche vengono configurate in modalità sincrona. Ciò significa che tutti gli aggiornamenti nell'istanza primaria vengono replicati in modo sincrono in ognuna delle istanze secondarie.

Visualizzare e monitorare lo stato di disponibilità elevata

Al termine della distribuzione, connettersi all'endpoint primario da SQL Server Management Studio.

Verificare e recuperare l'endpoint della replica primaria e connettersi a esso da SQL Server Management Studio. Ad esempio, se l'istanza DI SQL è stata distribuita usando service-type=loadbalancer, eseguire il comando seguente per recuperare l'endpoint a cui connettersi:

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

oppure

kubectl get sqlmi -A

Ottenere gli endpoint primari e secondari e lo stato del gruppo di disponibilità

Usare i kubectl describe sqlmi comandi o az sql mi-arc show per visualizzare gli endpoint primari e secondari e lo stato di disponibilità elevata.

Esempio:

kubectl describe sqlmi sqldemo -n my-namespace

oppure

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

Output di esempio:

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

È possibile connettersi all'endpoint primario con SQL Server Management Studio e verificare le DMV come:

SELECT * FROM sys.dm_hadr_availability_replica_states

E il dashboard di disponibilità indipendente:

Scenari di failover

A differenza dei gruppi di disponibilità AlwaysOn di SQL Server, il gruppo di disponibilità indipendente è una soluzione a disponibilità elevata gestita. Di conseguenza, le modalità di failover sono limitate rispetto alle modalità tipiche disponibili con i gruppi di disponibilità AlwaysOn di SQL Server.

Distribuire istanze gestite di SQL del livello di servizio business critical nella configurazione a due repliche o in tre configurazioni di replica. Gli effetti degli errori e la successiva recuperabilità sono diversi con ogni configurazione. Un'istanza di tre repliche offre un livello di disponibilità e ripristino superiore rispetto a un'istanza di replica in due.

In una configurazione di due repliche, quando entrambi gli stati del nodo sono SYNCHRONIZED, se la replica primaria non è più disponibile, la replica secondaria viene alzata di livello automaticamente a primaria. Quando la replica non riuscita diventa disponibile, viene aggiornata con tutte le modifiche in sospeso. Se si verificano problemi di connettività tra le repliche, la replica primaria potrebbe non eseguire il commit di alcuna transazione perché ogni transazione deve essere sottoposta a commit in entrambe le repliche prima che venga restituito un esito positivo nel database primario.

In una configurazione di tre repliche, una transazione deve eseguire il commit in almeno 2 delle 3 repliche prima di restituire un messaggio di esito positivo all'applicazione. In caso di errore, una delle repliche secondarie viene promossa automaticamente alla replica primaria mentre Kubernetes tenta di recuperare la replica non riuscita. Quando la replica diventa disponibile, viene automaticamente unita al gruppo di disponibilità indipendente e le modifiche in sospeso vengono sincronizzate. Se si verificano problemi di connettività tra le repliche e più di 2 repliche non sono sincronizzate, la replica primaria non eseguirà il commit di alcuna transazione.

Nota

È consigliabile distribuire un Istanza gestita di SQL business critical in una configurazione di tre repliche rispetto a una configurazione di due repliche per ottenere una perdita di dati quasi zero.

Per eseguire il failover dalla replica primaria a uno dei database secondari, per un evento pianificato, eseguire il comando seguente:

Se ci si connette al database primario, è possibile usare T-SQL seguente per eseguire il failover dell'istanza DI SQL in uno dei database secondari:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Se ci si connette al database secondario, è possibile usare T-SQL seguente per alzare di livello il database secondario desiderato alla replica primaria.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Replica primaria preferita

È anche possibile impostare una replica specifica come replica primaria usando l'interfaccia della riga di comando az come indicato di seguito:

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

Esempio:

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

Nota

Kubernetes tenterà di impostare la replica preferita, ma non è garantita.

Ripristino di un database in un'istanza con più repliche

Sono necessari passaggi aggiuntivi per ripristinare un database in un gruppo di disponibilità. La procedura seguente illustra come ripristinare un database in un'istanza gestita e aggiungerlo a un gruppo di disponibilità.

1. Esporre l'endpoint esterno dell'istanza primaria creando un nuovo servizio Kubernetes.

   Determinare il pod che ospita la replica primaria. Connessione all'istanza gestita ed eseguire:

   SELECT @@SERVERNAME
   

   La query restituisce il pod che ospita la replica primaria.

   Creare il servizio Kubernetes nell'istanza primaria eseguendo il comando seguente se il cluster Kubernetes usa NodePort servizi. Sostituire <podName> con il nome del server restituito nel passaggio precedente, <serviceName> con il nome preferito per il servizio Kubernetes creato.

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

   Per un servizio LoadBalancer, eseguire lo stesso comando, ad eccezione del fatto che il tipo del servizio creato è LoadBalancer. Ad esempio:

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

   Di seguito è riportato un esempio di questo comando eseguito su servizio Azure Kubernetes, in cui il pod che ospita il database primario è sql2-0:

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

   Ottenere l'indirizzo IP del servizio Kubernetes creato:

   kubectl get services -n <namespaceName>
   

2. Ripristinare il database nell'endpoint dell'istanza primaria.

   Aggiungere il file di backup del database nel contenitore dell'istanza primaria.

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

   Esempio

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

   Ripristinare il file di backup del database eseguendo il comando seguente.

   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
   

   Esempio

   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. Aggiungere il database al gruppo di disponibilità.

   Affinché il database venga aggiunto al gruppo di disponibilità, deve essere eseguito in modalità di recupero completo e deve essere eseguito un backup del log. Eseguire le istruzioni TSQL seguenti per aggiungere il database ripristinato nel gruppo di disponibilità.

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

   L'esempio seguente aggiunge un database denominato WideWorldImporters che è stato ripristinato nell'istanza:

   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

Come procedura consigliata, è consigliabile eliminare il servizio Kubernetes creato in precedenza eseguendo questo comando:

kubectl delete svc sql2-0-p -n arc

Limiti

Istanza gestita di SQL abilitato dai gruppi di disponibilità di Azure Arc presenta le stesse limitazioni dei gruppi di disponibilità del cluster Big Data. Per altre informazioni, vedere Distribuire un cluster Big Data di SQL Server con disponibilità elevata.

Contenuto correlato

Altre informazioni sulle funzionalità e sulle funzionalità di Istanza gestita di SQL abilitate da Azure Arc