Aggiornare un servizio Istanza gestita di SQL di Azure abilitato per Azure Arc connesso indirettamente tramite l'interfaccia della riga di comando

Articolo
09/26/2024

Questo articolo spiega come aggiornare un servizio Istanza gestita di SQL distribuito in un controller dei dati abilitato per Azure Arc connesso indirettamente tramite l'interfaccia della riga di comando di Azure (az).

Prerequisiti

Installare gli strumenti

Prima di procedere con le attività descritte in questo articolo, installare gli elementi seguenti:

La versione dell'estensione arcdata e la versione dell'immagine sono correlate. Nel log delle versioni verificare che la versione dell'estensione arcdata sia corretta e corrisponda alla versione dell'immagine a cui si vuole eseguire l'aggiornamento.

Limiti

Il controller dei dati di Azure Arc deve essere aggiornato alla nuova versione prima che l'istanza gestita possa essere aggiornata.

Se l'integrazione di Active Directory è abilitata, è necessario aggiornare Active Directory Connector alla nuova versione prima che l'istanza gestita possa essere aggiornata.

L'istanza gestita deve avere la stessa versione del controller dei dati e di Active Directory Connector prima che un controller dei dati possa essere aggiornato.

Al momento non è disponibile alcun processo di aggiornamento batch.

Aggiornare l'istanza gestita

È prima possibile eseguire una prova. Durante la prova viene eseguita la convalida dello schema delle versioni e viene restituito l'elenco delle istanze che verranno aggiornate.

Ad esempio:

az sql mi-arc upgrade --name <instance name> --k8s-namespace <namespace> --dry-run --use-k8s

L'output sarà:

Preparing to upgrade sql sqlmi-1 in namespace arc to data controller version.
****Dry Run****1 instance(s) would be upgraded by this commandsqlmi-1 would be upgraded to <version-tag>.

Utilizzo generico

Durante l'aggiornamento di un servizio Istanza gestita di SQL per utilizzo generico, il pod verrà terminato e sottoposto a nuovo provisioning in base alla nuova versione. Ciò causerà un breve periodo di inattività durante la creazione del nuovo pod. Sarà necessario creare resilienza a livello di applicazione, ad esempio la logica di ripetizione dei tentativi di connessione, per garantire un'interruzione minima. Per altre informazioni sulla progettazione della resilienza e indicazioni sui nuovi tentativi di connessione per i servizi di Azure, vedere Panoramica del pilastro dell'affidabilità.

Business Critical

Durante un aggiornamento business critical del servizio Istanza gestita di SQL con più repliche:

I pod di replica secondari vengono terminati e sottoposti a nuovo provisioning in base alla nuova versione
Dopo l'aggiornamento delle repliche, verrà eseguito il failover del pod primario in una replica aggiornata
Il pod primario precedente viene terminato e sottoposto a nuovo provisioning in base alla nuova versione, diventando così un pod secondario

Durante l'esecuzione del failover si verifica un breve momento di inattività.

Aggiorna

Per aggiornare l'istanza gestita, usare il comando seguente:

az sql mi-arc upgrade --name <instance name> --desired-version <version> --k8s-namespace <namespace> --use-k8s

Esempio:

az sql mi-arc upgrade --name instance1 --desired-version v1.0.0.20211028 --k8s-namespace arc1 --use-k8s

Monitoraggio

CLI

È possibile monitorare lo stato di avanzamento dell'aggiornamento con il comando show.

az sql mi-arc show --name <instance name> --k8s-namespace <namespace> --use-k8s

Output

L'output del comando mostrerà le informazioni sulla risorsa. Le informazioni sull'aggiornamento saranno incluse nello stato.

Durante l'aggiornamento, State indicherà Updating e Running Version sarà la versione corrente:

Status:
  Log Search Dashboard:  https://30.88.222.48:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqlmi-1'))
  Metrics Dashboard:     https://30.88.221.32:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqlmi-1-0
  Observed Generation:   2
  Primary Endpoint:      30.76.129.38,1433
  Ready Replicas:        1/1
  Running Version:       v1.0.0_2021-07-30
  State:                 Updating

Al termine dell'aggiornamento, State indicherà Ready e Running Version sarà la nuova versione:

Status:
  Log Search Dashboard:  https://30.88.222.48:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqlmi-1'))
  Metrics Dashboard:     https://30.88.221.32:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqlmi-1-0
  Observed Generation:   2
  Primary Endpoint:      30.76.129.38,1433
  Ready Replicas:        1/1
  Running Version:       <version-tag>
  State:                 Ready

Risoluzione dei problemi

Quando la versione desiderata è impostata su una versione specifica, il processo del caricatore di bootstrap tenterà di eseguire l'aggiornamento a tale versione fino a quando l'operazione non ha esito positivo. Se l'aggiornamento ha esito positivo, la proprietà RunningVersion della specifica viene aggiornata in base alla nuova versione. Gli aggiornamenti potrebbero non riuscire in scenari in cui i tag immagine non sono corretti, risulta impossibile connettersi al registro o al repository, la CPU o la memoria allocata ai contenitori non è sufficiente oppure le risorse di archiviazione sono insufficienti.

Eseguire il comando seguente per verificare se uno dei pod è associato allo stato Error o ha un numero elevato di riavvii:
```
kubectl get pods --namespace <namespace>
```
Per esaminare gli eventi e verificare l'eventuale presenza di un errore, eseguire:
```
kubectl describe pod <pod name> --namespace <namespace>
```

Per ottenere l'elenco dei contenitori nei pod, eseguire:

kubectl get pods <pod name> --namespace <namespace> -o jsonpath='{.spec.containers[*].name}*'

Per ottenere i log per un contenitore, eseguire:

kubectl logs <pod name> <container name> --namespace <namespace>

Per visualizzare gli errori comuni e come risolverli, consultare Risorse per la risoluzione dei problemi.

Condividi tramite