Disponibilità elevata con l'istanza gestita di SQL abilitata da Azure Arc

L'istanza gestita di SQL abilitata da Azure Arc è distribuita in Kubernetes come applicazione in contenitori. Usa costrutti Kubernetes, ad esempio set con stato e archiviazione permanente, per fornire come funzionalità predefinite:

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

Per una maggiore affidabilità, è anche possibile configurare l'istanza gestita di SQL abilitata da Azure Arc per la distribuzione con repliche aggiuntive in una configurazione a disponibilità elevata. Il controller dei dati dei servizi dati Arc gestisce:

• Monitoraggio
• rilevamento degli errori
• Failover automatico

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

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

Questo documento illustra entrambi i tipi di disponibilità elevata.

L'istanza gestita di SQL abilitata da Azure Arc offre diversi livelli di disponibilità elevata a seconda che sia stata distribuita come livello di servizio per utilizzo generico o business critical.

Disponibilità elevata con livello di servizio per utilizzo generico

Nel livello di servizio per utilizzo generico è disponibile una sola replica e la disponibilità elevata si ottiene tramite l'orchestrazione di Kubernetes. Ad esempio, in caso di arresto anomalo di un pod o di un nodo contenente l'immagine del contenitore dell'istanza gestita, Kubernetes tenta di attivare un altro pod o nodo e di collegarlo alla stessa risorsa di archiviazione permanente. Durante questo periodo, l'istanza gestita di SQL non è disponibile alle applicazioni. Le applicazioni devono riconnettersi e ripetere la transazione quando è attivo il nuovo pod. Se il tipo di servizio usato è load balancer, le applicazioni possono riconnettersi allo stesso endpoint primario e Kubernetes reindirizzerà la connessione al nuovo endpoint 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 predefinita 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 e condivisa
• Istanza gestita di SQL abilitata da Azure Arc distribuita 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 sia in corso il ripristino dell'istanza gestita.

   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 nel pod, è possibile connettersi all'istanza gestita.

Disponibilità elevata con livello di servizio business critical

Nel livello di servizio business critical, oltre a quanto viene fornito in modo nativo dall'orchestrazione Kubernetes, l'istanza gestita di SQL per Azure Arc offre un gruppo di disponibilità indipendente. Il gruppo di disponibilità indipendente si basa sulla tecnologia Always On di SQL Server. Offre livelli più elevati di disponibilità. L'istanza gestita di SQL abilitata da Azure Arc distribuita con livello di servizio business critical può essere distribuita con 2 o 3 repliche. Queste repliche sono sempre sincronizzate tra loro.

Con i gruppi di disponibilità indipendenti, 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 nodo primario ed è pronto a gestire le connessioni.

Gruppi di disponibilità indipendenti

Un gruppo di disponibilità associa uno o più database utente a un gruppo logico in modo che, in caso di failover, l'intero gruppo di database esegue il failover nella replica secondaria come unità singola. Un gruppo di disponibilità replica solo i dati nei database dell'utente, ma non quelli nei database di sistema, come account di accesso, autorizzazioni o processi dell'agente. Un gruppo di disponibilità indipendente include metadati dei database di sistema, come i database msdb e master. 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, anche le repliche secondarie ricevono tali modifiche.

L'istanza gestita di SQL abilitata da Azure Arc accetta il concetto di gruppo di disponibilità indipendente e aggiunge l'operatore Kubernetes per supportarne la distribuzione e la gestione su larga scala.

I gruppi di disponibilità indipendenti abilitano queste funzionalità:

• Con la distribuzione con più repliche, viene creato un singolo gruppo di disponibilità 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 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.

• 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 database containedag_master e containedag_msdb se ci si connette direttamente all'istanza. 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 l'istanza gestita di SQL abilitata per Azure Arc con più repliche mediante il portale di Azure

Dal portale di Azure, nella pagina Creare un'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. Selezionare l'opzione "Solo a scopo di sviluppo", per l'uso 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 si distribuisce l'istanza gestita di SQL abilitata per Azure Arc nel livello di servizio business critical, vengono create più repliche. L'impostazione 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à indirettamente connessa:

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à direttamente connessa:

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 sono configurate in modalità sincrona. Pertanto qualsiasi aggiornamento nell'istanza primaria viene replicato in modo sincrono in ogni istanza secondaria.

Visualizzare e monitorare lo stato di disponibilità elevata

Al termine della distribuzione, eseguire la connessione 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 di seguito per recuperare l'endpoint a cui connettersi:

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

o

kubectl get sqlmi -A

Ottenere gli endpoint primario e secondario e lo stato del gruppo di disponibilità

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

Esempio:

kubectl describe sqlmi sqldemo -n my-namespace

o

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

Output di esempio; l'output ottenuto sarà diverso:

 "status": {
    "endpoints": {...
      "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

Dashboard di disponibilità indipendente:

Scenari di failover

A differenza dei gruppi di disponibilità Always On di SQL Server, il gruppo di disponibilità indipendente è una soluzione a disponibilità elevata gestita. Di conseguenza, le modalità di failover sono limitate rispetto a quelle tipiche a disposizione per i gruppi di disponibilità Always On di SQL Server.

Distribuire istanze gestite di SQL con livello di servizio business critical nella configurazione a due o tre repliche. Gli effetti degli errori e la successiva capacità di ripristino variano per ogni configurazione. Un'istanza a tre repliche offre un livello di disponibilità e ripristino superiore rispetto a un'istanza a due repliche.

In una configurazione a due repliche, quando entrambi gli stati del nodo sono SYNCHRONIZED, se la replica primaria non è disponibile, la replica secondaria viene automaticamente promossa a primaria. Quando la replica con errore 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 dell'esito positivo della replica primaria.

In una configurazione a tre repliche, una transazione deve eseguire il commit in almeno due delle tre repliche prima di restituire un messaggio di esito positivo all'applicazione. In caso di errore, una delle repliche secondarie viene automaticamente promossa a primaria mentre Kubernetes tenta di recuperare la replica con errore. 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 due repliche non sono sincronizzate, la replica primaria non eseguirà il commit di qualsiasi transazione.

Note

È consigliabile distribuire un'istanza gestita di SQL business critical in una configurazione a tre repliche anziché a due repliche, per ottenere una perdita di dati quasi pari a zero.

Per il failover dalla replica primaria a una secondaria per un evento pianificato, eseguire il comando seguente:

Se ci si connette alla replica primaria, è possibile usare il T-SQL seguente per eseguire il failover dell'istanza di SQL in una delle secondarie:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Se ci si connette alla secondaria, è possibile usare il T-SQL seguente per promuovere la replica secondaria desiderata a primaria.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Replica primaria preferita

È anche possibile impostare una replica specifica come primaria usando l'interfaccia della riga di comando di Azure 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

Note

Kubernetes tenterà di impostare la replica preferita, ma l'esito dell'operazione non è garantito.

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

Sono necessari altri passaggi 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. Connettersi 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 servizi NodePort. Sostituire <podName> con il nome del server restituito al passaggio precedente e <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, tranne per il fatto che il tipo del servizio creato è LoadBalancer. Ad esempio:

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

   Ecco un esempio di questo comando eseguito sul servizio Azure Kubernetes, in cui il pod che ospita la replica primaria è 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 all'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 di seguito.

   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à.

   Per aggiungerlo al gruppo di disponibilità, è necessario eseguire il database in modalità di recupero con registrazione completa ed acquisire un backup del log. Eseguire le istruzioni TSQL di seguito 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, è opportuno eliminare il servizio Kubernetes creato in precedenza mediante questo comando:

kubectl delete svc sql2-0-p -n arc

Limitazioni

I gruppi di disponibilità dell'istanza gestita di SQL abilitata per Azure Arc hanno gli stessi limiti dei gruppi di disponibilità del cluster Big Data. Per altre informazioni, vedere Distribuire un cluster Big Data di SQL Server con disponibilità elevata.

Contenuti correlati

Per altre informazioni, vedere Caratteristiche e funzionalità dell'istanza gestita di SQL abilitata da Azure Arc