Mettre à niveau Azure SQL Managed Instance directement connecté à Azure Arc à l’aide de l’interface CLI

Article
10/16/2024

Cet article explique comment mettre à niveau Azure SQL Managed Instance déployé sur un contrôleur de données avec Azure Arc connecté directement à l’aide de l’interface de ligne de commande Azure (az).

Prérequis

Installer des outils

Avant de pouvoir effectuer les tâches de cet article, installez :

La version de l’extension arcdata et la version de l’image sont associées. Vérifiez que vous disposez de la version d’extension correcte arcdata qui correspond à la version d’image vers laquelle vous souhaitez effectuer une mise à niveau dans le journal des versions.

Limites

Le contrôleur de données Azure Arc doit être mis à niveau vers la nouvelle version avant de pouvoir mettre à niveau l’instance gérée.

Si l’intégration d’Active Directory est activée, le connecteur Active Directory doit être mis à niveau vers la nouvelle version avant que l’instance managée puisse être mise à niveau.

L’instance gérée doit être à la même version que le contrôleur de données et le connecteur Active Directory avant la mise à niveau d’un contrôleur de données.

Aucun processus de mise à niveau par lots n’est disponible pour l’instant.

Mettre à niveau l’instance gérée

Vous pouvez effectuer d’abord un test. L’exécution test valide le schéma de version et répertorie les instances à mettre à niveau. Utiliser --dry-run. Par exemple :

az sql mi-arc upgrade --resource-group <resource group> --name <instance name> --dry-run

La sortie se présente comme suit :

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

Usage général

Lors d'une mise à niveau générale de SQL Managed Instance, le pod sera interrompu et reprovisionné à la nouvelle version. Cela entraîne un court temps d’arrêt pendant la création du nouveau pod. Vous devrez intégrer la résilience dans votre application, telle que la logique de nouvelle tentative de connexion, pour garantir une interruption minimale. Pour plus d’informations sur l’architecture de la résilience, lisez Vue d’ensemble du pilier de fiabilité et Guide du mécanisme de nouvelle tentative relatif aux services Azure.

Critique pour l’entreprise

Pendant une mise à niveau de SQL Managed Instance critique pour l'entreprise avec plusieurs réplicas :

Les pods de réplica secondaire sont arrêtés et reprovisionnés à la nouvelle version
Une fois les réplicas mis à niveau, le réplica principal bascule vers un réplica mis à niveau
Le pod principal précédent est arrêté et reprovisionné à la nouvelle version, et devient un pod secondaire

Il y a un bref moment de temps d’arrêt lorsque le basculement se produit.

Mettre à jour

Pour mettre à niveau une instance gérée, utilisez la commande suivante :

az sql mi-arc upgrade --resource-group <resource group> --name <instance name> --desired-version <imageTag> [--no-wait]

Exemple :

az sql mi-arc upgrade --resource-group myresource-group --name sql1 --desired-version v1.6.0_2022-05-02 [--no-wait]

Monitor

Vous pouvez surveiller la progression de la mise à niveau à l’aide de l’interface CLI.

Exemple avec l’interface CLI

az sql mi-arc show --resource-group <resource group> --name <instance name>

Sortie

La sortie de la commande affiche les informations sur les ressources. Les informations de mise à niveau seront dans État.

Pendant la mise à niveau, State affiche Updating et Running Version correspond à la version actuelle :

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.5.0_2022-04-05
  State:                 Updating

Une fois la mise à niveau terminée, State affiche Ready et Running Version correspond à la nouvelle version :

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.6.0_2022-05-02
  State:                 Ready

Dépannage

Lorsque la version souhaitée est définie sur une version spécifique, le travail de démarrage tente de procéder à la mise à niveau vers cette version jusqu’à ce qu’elle réussisse. Si la mise à niveau réussit, la propriété RunningVersion de la spécification est mise à jour vers la nouvelle version. Les mises à niveau peuvent échouer dans des scénarios comme une balise d’image incorrecte, l’impossibilité de se connecter au registre ou au référentiel, une quantité de processeur ou de mémoire insuffisante allouée aux conteneurs ou un stockage insuffisant.

Exécutez la commande ci-dessous pour voir si l’un des pods présente un statut Error ou présente un nombre élevé de redémarrages :
```
kubectl get pods --namespace <namespace>
```
Pour examiner les événements pour voir s’il existe une erreur, exécutez
```
kubectl describe pod <pod name> --namespace <namespace>
```

Pour obtenir la liste des conteneurs dans les pods, exécutez

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

Pour obtenir les journaux d’un conteneur, exécutez

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

Pour afficher les erreurs courantes et la façon de les résoudre, accédez aux Ressources de dépannage.

Partager via