Share via


Disciplines de mise à niveau pour SQL Managed Instance avec Azure Arc

Les services de données compatibles avec Azure Arc vous permettent de bénéficier d’une version persistante de SQL disponible uniquement dans SQL Managed Instance avec Arc. Du fait de sa nature persistante, SQL Managed Instance avec Arc offre une capacité de mise à niveau basée sur un service managé pour vous permettre de tirer parti de l’innovation dans votre infrastructure Azure dès qu’elle est disponible, ce qui n’est pas le cas des installations locales ou des environnements multiclouds.

Cet article présente les éléments de conception clés ainsi des recommandations pour configurer et gérer le processus de mise à niveau pour vos services de données compatibles avec Azure Arc.

Architecture

Mode de connexion directe

Le diagramme suivant illustre le flux de mise à niveau des services de données en mode Connecté directement.

Capture d’écran montrant le flux de mise à niveau des services de données en mode Connecté directement.

Mode de connexion indirecte

Le diagramme suivant illustre le flux de mise à niveau des services de données en mode Connecté indirectement.

Capture d’écran montrant le flux de mise à niveau des services de données en mode Connecté Indirectement.

Niveau de service Usage général

Les diagrammes suivants illustrent le processus de mise à niveau pour SQL Managed Instance avec Arc dans un niveau de service Usage général.

Capture d’écran montrant le processus de préparation à la mise à niveau d’une instance SQL Managed Instance avec Arc dans un niveau de service Usage général.

Capture d’écran montrant le processus de mise à niveau d’une instance SQL Managed Instance avec Arc dans un niveau de service Usage général.

Niveau de service Critique pour l’entreprise

Les diagrammes suivants illustrent le processus de mise à niveau pour SQL Managed Instance avec Arc dans un niveau de service Critique pour l’entreprise.

Capture d’écran montrant le processus de préparation à la mise à niveau d’une instance SQL Managed Instance avec Arc dans un niveau de service Critique pour l’entreprise.

Capture d’écran montrant le processus de mise à niveau d’une instance SQL Managed Instance avec Arc dans un niveau de service Critique pour l’entreprise.

Capture d’écran montrant le lancement de la mise à niveau des réplicas secondaires restants dans le cadre d’une mise à niveau du niveau de service Critique pour l’entreprise.

Capture d’écran montrant le basculement au niveau de SQL et l’instanciation du dernier pod dans le cadre d’une mise à niveau du niveau de service Critique pour l’entreprise.

Remarques relatives à la conception

Mises à niveau du contrôleur de données Azure Arc

  • Les mises à niveau peuvent être effectuées à l’aide de différents outils, notamment Azure CLI, le portail Azure ou Kubernetes. Choisissez l’outil en fonction du mode de connectivité utilisé (Connecté directement ou indirectement) et de votre aisance à l’utiliser.
  • Examinez votre contrôleur de données Azure Arc pour vérifier si des services de données en préversion, comme PostgreSQL avec Azure Arc, sont déployés en même temps que SQL Managed Instance avec Arc. Vous ne pouvez pas effectuer de mises à niveau sur place si un assortiment de services en préversion et en disponibilité générale est déployé sur un même contrôleur de données.
  • Avant d’effectuer la mise à niveau, vérifiez que la version de toutes les instances SQL Managed Instance avec Arc utilisées par le contrôleur de données correspond à celle du contrôleur de données.
  • Tenez compte du chemin de mise à niveau pris en charge pour déterminer quelle est la prochaine version adaptée à votre contrôleur de données avant la mise à niveau.

Notes

Une mise à niveau du contrôleur de données Azure Arc n’entraîne pas de temps d’arrêt pour SQL Managed Instance avec Arc.

Mode de connexion directe

Mode de connexion indirecte

  • Déterminez si la mise à niveau du contrôleur de données Azure Arc en mode Connecté indirectement doit être implémentée à l’aide d’Azure CLI ou des outils Kubernetes.
  • Passez en revue les prérequis pour les mises à niveau à partir des outils Kubernetes et d’Azure CLI.
  • Déterminez si vous allez utiliser le Registre des artefacts Microsoft dans l’hypothèse où vos clusters disposent d’une connectivité Internet ou un registre privé si vos clusters sont déconnectés pour extraire les images des services de données compatibles avec Azure Arc.
  • Prévoyez les autorisations Kubernetes nécessaires pour le compte de service dont vous allez vous servir pour mettre à niveau le contrôleur de données Azure Arc à l’aide des outils Kubernetes.
  • Vérifiez que les informations du référentiel sont valides et que de nouvelles images y ont déjà été placées.

Mises à niveau de SQL Managed Instance avec Azure Arc

Considérations d’ordre général

  • Les mises à niveau à destination du contrôleur de données Azure Arc doivent être effectuées préalablement à la mise à niveau de SQL Managed Instance avec Arc. Les versions de l’extension du cluster arcdata et des extensions SQL Managed Instance sont liées et doivent être identiques.
  • Déterminez si vous allez utiliser les mises à niveau automatiques ou manuelles pour votre instance SQL Managed Instance avec Arc, selon vos besoins.
  • Dans le cas des mises à niveau automatiques, une seule fenêtre de maintenance peut être définie pour un contrôleur de données. Tenez compte du nombre de fenêtres de maintenance nécessaires en fonction du nombre de charges de travail existantes afin de déterminer le nombre de contrôleurs de données dont vous avez besoin.

Niveau de service Usage général

  • À l’occasion d’une mise à niveau du niveau de service Usage général, le pod Kubernetes est mis à l’arrêt et reprovisionné avec la nouvelle version. Il est important de comprendre l’effet côté application et côté client d’une mise à niveau au cours de laquelle un bref temps d’arrêt est à observer pendant que le pod est créé.
  • Passez en revue l’architecture de vos applications pour déterminer si elles disposent de la résilience et de la logique de nouvelle tentative nécessaires pour prendre en charge le bref impact d’une mise à niveau.

Niveau de service Critique pour l’entreprise

  • À l’occasion d’une mise à niveau du niveau de service Critique pour l’entreprise avec plusieurs réplicas, les réplicas secondaires sont les premiers à être mis à niveau. L’un des réplicas secondaires mis à niveau est promu pour devenir le nouveau réplica principal tandis que l’ancien réplica principal devient un réplica secondaire et est mis à niveau. Entre le moment où l’ancien réplica principal se transforme en nouveau réplica principal, un bref temps d’arrêt est à observer pendant que basculement se produit. Il est important de comprendre l’impact côté application et côté client d’une mise à niveau pendant que le basculement se produit.
  • Passez en revue l’architecture de vos applications pour déterminer si elles disposent de la résilience et de la logique de nouvelle tentative nécessaires pour prendre en charge le bref impact d’une mise à niveau.

Recommandations de conception

Mises à niveau du contrôleur de données Azure Arc

  • Si vous effectuez une mise à niveau à partir d’Azure CLI, vérifiez que la version de l’extension Azure CLI arcdata correspond à la version de l’image vers laquelle vous souhaitez effectuer la mise à niveau dans le journal des versions.

  • Dans les environnements multiclusters, effectuez d’abord les mises à niveau dans un environnement de test/développement pour valider les éventuels problèmes ou changements cassants.

  • Effectuez une exécution de test avant la mise à niveau pour valider le schéma de version, le jeton d’autorisation du référentiel privé éventuellement utilisé, et vérifiez que le registre existe avant de tenter une mise à niveau réelle.

  • Créez un processus pour rechercher les nouvelles mises à niveau de contrôleur de données Azure Arc.

  • Ne combinez pas PostgreSQL avec SQL Managed Instance avec Arc sur un même contrôleur de données, car PostgreSQL est toujours en préversion alors que SQL Managed Instance avec Arc est en disposition générale. Pour tester PostgreSQL, prévoyez un cluster distinct doté de son propre contrôleur de données.

  • Évitez d’utiliser des fonctionnalités en préversion dans votre environnement de production, et utilisez uniquement les fonctionnalités en préversion à titre d’évaluation sur des instances de développement/test.

  • Créez un inventaire des versions actuelles des contrôleurs de données déployés. Vous pouvez utiliser Azure Resource Graph pour interroger vos contrôleurs de données actuellement déployés.

      resources
      | where type == 'microsoft.azurearcdata/datacontrollers'
      | extend version = tostring(properties.k8sRaw.status.runningVersion)
      | project name,location,resourceGroup,version
    
  • Consultez le guide de résolution des problèmes pour savoir comment vous procurer les journaux nécessaires à la résolution des problèmes de mise à niveau.

Mode de connexion directe

Mode de connexion indirecte

Mises à niveau de SQL Managed Instance avec Azure Arc

Recommandations générales

  • Tenez à jour votre instance SQL Managed Instance avec Arc avec la dernière version disponible pour recevoir les patchs, les correctifs de bogues et les fonctionnalités les plus récents. Pour l’heure, les services de données Arc ne permettent pas de sauter des mises en production pendant les mises à niveau. Par conséquent, s’il y a plusieurs mises en production à mettre à niveau, vous devez effectuer une mise à niveau vers des mises en production séquentielles pour parvenir à la dernière version. Il est recommandé de ne pas trop dériver des dernières mises en production.

  • Veillez à configurer votre stratégie de sauvegarde « restauration à un instant dans le passé » de façon à pouvoir effectuer une récupération en cas de problème durant une mise à niveau. Penchez-vous sur le domaine de conception critique de continuité d’activité et de reprise d’activité et utilisez la commande kubectl describe sqlmi sur vos instances pour vérifier les paramètres de rétention actuels.

  • Dans les environnements ou scénarios multiclusters dans lesquels plusieurs déploiements de SQL Managed Instance avec Arc représentent différents environnements, effectuez d’abord les mises à niveau dans les environnements de développement/test, par exemple l’environnement de développement, pour valider les éventuels problèmes ou changements cassants.

  • Effectuez une exécution de test avant la mise à niveau pour valider le schéma de version, le jeton d’autorisation du référentiel privé éventuellement utilisé, et vérifiez que le registre existe avant de tenter une mise à niveau réelle.

  • Utilisez Azure CLI pour effectuer des mises à niveau à grande échelle de votre instance SQL Managed Instance avec Arc.

  • Procédez à des mises à niveau automatiques pour les charges de travail qui peuvent tolérer des mises à niveau immédiates et refusez les mises à niveau automatiques pour les charges de travail dont la mise à niveau doit se produire à une heure creuse planifiée.

  • Si vous utilisez les mises à niveau automatiques, veillez à définir une fenêtre de maintenance appropriée pour prévoir les mises à niveau à des heures creuses.

  • Dans le cas des mises à niveau manuelles, veillez à établir une cadence de mise à niveau régulière afin de vous maintenir dans les versions prises en charge.

    Notes

    Vous pouvez aussi interroger le Registre des artefacts Microsoft à propos des nouvelles versions d’image conteneur.

  • Créez un processus pour superviser l’état de mise à niveau à l’aide d’Azure CLI ou des outils Kubernetes.

  • Examinez les versions correspondantes des différents composants avant d’effectuer une mise à niveau pour vérifier que les bonnes versions des composants sont en place.

Niveau de service Usage général

Niveau de service Critique pour l’entreprise

  • Déployez l’instance Critique pour l’entreprise avec trois réplicas au lieu de deux pour bénéficier d’une plus grande disponibilité et de temps d’arrêt inférieurs durant les activités de mise à niveau et de basculement.
  • Effectuez les mises à niveau à des heures non critiques pour limiter l’impact sur les utilisateurs et les données de l’organisation.

Étapes suivantes

Pour plus d’informations sur le parcours cloud hybride et multicloud, consultez les articles suivants :