Partager via

Vue d’ensemble des opérations de gestion dans Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article fournit une vue d’ensemble des différentes opérations qui se produisent lors de la gestion d’Azure SQL Managed Instance. Les opérations de gestion sont des opérations effectuées sur le serveur principal lorsque vous créez, mettez à jour ou supprimez une instance.

Pour obtenir une description détaillée des étapes et de la durée estimée de chaque opération de gestion, passez en revue la durée des opérations de gestion.

Présentation des opérations de gestion

La gestion d’Azure SQL Managed Instance implique les opérations suivantes :

  • Créer : opérations qui se produisent lors de la première création d’une instance managée SQL. Cela inclut la création du groupe de machines virtuelles sous-jacentes et le déploiement du processus du moteur de base de données SQL.
  • Mise à jour : opérations qui se produisent lorsque vous modifiez les propriétés d’une instance managée SQL existante, comme la mise à l’échelle du calcul ou le stockage, la modification du niveau de service ou la mise à jour de la configuration de l’instance. Effectuer des mises à jour implique souvent le redimensionnement du groupe de machines virtuelles, ainsi que l’amorçage des données, puis le basculement, vers un nouveau processus du moteur de base de données SQL.
  • Supprimer : opérations qui se produisent lorsque vous supprimez une instance managée SQL existante, y compris le nettoyage des ressources telles que le groupe de machines virtuelles associé à l’instance.

Pour obtenir une description détaillée des étapes et de la durée estimée de chaque opération de gestion, passez en revue la durée des opérations de gestion.

Les opérations de gestion SQL Managed Instance sont effectuées via les processus sous-jacents suivants :

  • Opérations de groupe de machines virtuelles : opérations impliquant la création et la gestion du groupe de machines virtuelles sous-jacent qui hébergent l’instance managée SQL. Cela inclut le redimensionnement du groupe de machines virtuelles, la création de nouveaux groupes de machines virtuelles et la gestion des machines virtuelles au sein de ces groupes.
  • Amorçage : initialisation et synchronisation des données dans les processus du moteur de base de données SQL, généralement pour préparer un basculement.
  • Basculement : opérations consistant à transférer le trafic vers un autre processus du moteur de base de données SQL, soit dans le même groupe de machines virtuelles, soit dans un nouveau groupe.

Opérations de groupe de machines virtuelles

Pour prendre en charge les déploiements au sein des réseaux virtuels Azure et assurer l’isolation et la sécurité des clients, SQL Managed Instance s’appuie sur des clusters virtuels. Le cluster virtuel représente un ensemble dédié de machines virtuelles isolées déployées à l’intérieur de votre sous-réseau de réseau virtuel et organisées au sein de groupes de machines virtuelles. Essentiellement, chaque instance managée SQL déployée sur un sous-réseau vide génère un nouveau cluster virtuel qui génère le tout premier groupe de machines virtuelles.

Les opérations de gestion suivantes sur les instances managées SQL peuvent affecter les groupes de machines virtuelles sous-jacents. Les modifications qui affectent les groupes de machines virtuelles sous-jacents peuvent affecter la durée des opérations de gestion, car le déploiement de machines virtuelles supplémentaires sur le cluster virtuel est fourni avec une surcharge que vous devez prendre en compte lorsque vous planifiez de nouveaux déploiements ou mises à jour sur des instances existantes.

Pour plus d’informations sur l’architecture du cluster virtuel, consultez architecture de cluster virtuel.

Ensemencement

L’amorçage joue un rôle essentiel dans le fonctionnement d’Azure SQL Managed Instance, en particulier lors de l’installation et de la réplication des bases de données. L’amorçage est le processus qui initialise et synchronise les données entre les processus du moteur de base de données SQL, qui est une partie cruciale de la gestion des instances. Bien qu’il s’agit souvent de l’étape la plus longue mais la plus fastidieuse des opérations réussies, l’amorçage sert de pierre angulaire pour établir un environnement d’instance managée SQL sain et fonctionnel.

Pour une durée estimée des opérations d’amorçage, consultez la durée des opérations de gestion.

Le processus d’amorçage implique généralement les étapes suivantes, quel que soit le niveau de service :

  • Initialisation : le système identifie la base de données source et de destination et démarre plusieurs tâches qui préparent les processus du moteur de base de données SQL pour le transfert de données.
  • Transfert de données : les packages de données réels sont transférés de la source au processus cible du moteur de base de données SQL, qui inclut une copie complète ou partielle de la base de données, selon le scénario.
  • Synchronisation : une fois le transfert de données initial terminé, le système synchronise toutes les mises à jour ou modifications suivantes via la réplication des blocs de journal des transactions pour garantir l’intégrité des données.
  • Validation et finalisation : le processus est finalisé et le processus cible du moteur de base de données SQL est validé pour confirmer la réussite de la réplication et de l’amorçage. Le basculement se produit afin que le trafic soit acheminé vers le nouveau processus du moteur de base de données SQL.

Il n’existe aucun amorçage de données dans le niveau de service Usage général , sauf lorsque vous remplacez le niveau de service par le niveau de service Critique pour l’entreprise . Les opérations de gestion dans le niveau de service Usage général impliquent de détacher le stockage distant de l’ancien processus du moteur de base de données SQL et de l’attacher au nouveau processus du moteur de base de données SQL.

À l’inverse, le niveau de service Critique pour l’entreprise , conçu pour les charges de travail hautes performances, nécessite un stockage local et la capacité de code des couches de calcul et de stockage. Par conséquent, presque toutes les opérations et scénarios de ce niveau de service nécessitent l’amorçage pour garantir la disponibilité et la cohérence des données.

Si l’amorçage est déclenché ou non dépend du scénario particulier et du niveau de service, par exemple :

  • Niveaux de service Usage général et Utilisation générale de nouvelle génération :
    • Passage au niveau de service Critique pour l’entreprise : les données doivent être transférées du stockage distant vers le stockage local utilisé dans le niveau de service Usage général.
    • Activation ou désactivation de la redondance de zone : les données doivent être copiées vers ou depuis les régions redondantes interzone.
  • Niveau de service Critique pour l’entreprise :
    • Mise à l’échelle du stockage : étant donné que le stockage est physiquement attaché à l’ordinateur local, chaque modification de stockage nécessite la création d’un groupe de machines virtuelles, de sorte que les données doivent être transférées de l’ancien ordinateur à la nouvelle machine (sur tous les 4 réplicas).
    • Mise à l’échelle des vCores : chaque opération de mise à l’échelle du calcul nécessite la création d’un groupe de machines virtuelles. Les données doivent donc être copiées à partir de l’ancien ordinateur vers la nouvelle machine (sur tous les 4 réplicas).
    • Modification de la fenêtre de maintenance ou matérielle : si un groupe de machines virtuelles existe déjà dans le sous-réseau avec une configuration correspondante, ce groupe de machines virtuelles est redimensionné. S’il s’agit d’une nouvelle configuration, un nouveau groupe de machines virtuelles est créé. Les données doivent être copiées de l’ancien groupe de machines virtuelles vers le nouveau groupe de machines virtuelles (sur tous les 4 réplicas).
    • Modification du niveau de service : les données doivent être copiées du stockage local vers le stockage distant utilisé dans le niveau de service Usage général.
    • Activation ou désactivation de la redondance de zone : les données doivent être copiées vers ou depuis les régions redondantes interzone.

Vitesses d’amorçage

Les facteurs suivants affectent la durée du processus d’amorçage :

  • Taille de la base de données : les bases de données plus volumineuses nécessitent plus de temps pour transférer des données et se synchroniser entre les processus du moteur de base de données SQL.
  • Dépendances réseau : la bande passante réseau et la latence peuvent considérablement influencer les vitesses d’amorçage.
  • Opérations de sauvegarde et de restauration : les opérations de sauvegarde en cours sur le processus du moteur de base de données SQL source peuvent influencer la préparation des données à envoyer à un autre processus du moteur de base de données SQL.
  • Charge de travail d’instance : une charge de travail d’instance lors de l’amorçage peut entraîner un ralentissement et prolonger de beaucoup le processus.

Bien que la plupart de ces facteurs dépassent votre contrôle, vous pouvez gérer le trafic d’instance pour optimiser considérablement les vitesses d’amorçage. L’amorçage utilise les mêmes ressources informatiques d’instance que celles qui gèrent le trafic d’instance. Un trafic dense pendant l’amorçage peut réduire la disponibilité de vCore, entraînant une capacité insuffisante pour le processus d’amorçage et provoquant un ralentissement.

Le trafic élevé pendant l’amorçage peut avoir un impact sur la synchronisation, car l’amorçage est conçu pour empaqueter et transférer toutes les données actuellement stockées dans une seule opération. Les modifications de données ultérieures apportées à l'ancien processus du moteur de base de données SQL, qui arrivent après l'initialisation du seeding, doivent être synchronisées de manière incrémentielle avec le nouveau processus du moteur de base de données SQL via la réplication par bloc de journal des transactions avant que le basculement ne puisse se produire. Si l’instance est sous forte charge, l’amorçage peut avoir du mal à suivre le rythme des données entrantes, entraînant des retards et des échecs potentiels dans la phase de synchronisation. Le trafic élevé continu sur l’ancien processus du moteur de base de données SQL après le démarrage peut entraîner une situation où la phase de synchronisation ne se termine jamais, car de nouvelles données continuent d’arriver et doivent être transférées. Cela peut entraîner un cycle perpétuel de transfert de données qui empêche le basculement vers le nouveau processus du moteur de base de données SQL.

Pour une durée estimée des opérations d’amorçage, consultez la durée des opérations de gestion.

Infrastructure et notifications Azure

L’amorçage est un processus qui ne peut pas être précisément quantifié ou strictement prédit, car il s’appuie sur les services Azure partagés. Les opérations de transfert et d’amorçage de données dépendent de différents services et infrastructures Azure internes, qui sont partagés dans l’ensemble de l’écosystème Azure. Ces services sont utilisés par de nombreux autres services non liés dans Azure. Tous les services de l’écosystème Azure concurrencent les ressources disponibles, ce qui entraîne des fluctuations de la disponibilité momentanée influencée par plusieurs facteurs. Bien que Microsoft puisse fournir une plage dans laquelle la capacité d’infrastructure fonctionne, faire des prédictions précises est difficile.

Basculement

Le basculement d’instance se produit lorsque le trafic est acheminé d’un ancien processus du moteur SQL vers un nouveau processus du moteur SQL au sein des nœuds d’un groupe de machines virtuelles englobant l’instance SQL managée. Le basculement est une partie cruciale de la plupart des opérations de gestion, en particulier lors de la mise à jour d’une instance. Le bref instant où les connexions sont interrompues pendant que le trafic est redirigé vers le nouveau processus du moteur de base de données SQL est appelé basculement.

Votre instance est uniquement indisponible pendant le basculement, lorsque le trafic est redirigé vers le nouveau processus du moteur de base de données SQL. Dans le niveau de service Critique pour l’entreprise , votre instance n’est pas disponible pendant jusqu’à 20 secondes, tandis que dans le niveau de service Usage général , votre instance peut être indisponible pendant 2 minutes maximum. Toutes les opérations back-end qui se produisent pour préparer le basculement en raison d’une opération de gestion, comme le réamorçage des bases de données dans le niveau de service critique pour l’entreprise, se produisent en arrière-plan et n’affectent pas la disponibilité de votre instance.

Importante

Pour les opérations de mise à jour qui ne se terminent pas localement mais qui entraînent le rattachement de la base de données (par exemple, la mise à l’échelle des vCores, la mise à l’échelle de la mémoire, la modification du matériel ou de la fenêtre de maintenance), la durée de basculement des bases de données augmente sur le niveau de service Usage général de nouvelle génération en fonction du nombre de bases de données, jusqu’à 10 minutes. Pendant que l’instance devient disponible après 2 minutes, certaines bases de données peuvent être disponibles après un délai. La durée du basculement est mesurée à partir du moment où la première base de données est hors connexion, jusqu’au moment où la dernière base de données est en ligne. Le niveau de service Usage général de nouvelle génération augmente le nombre maximal de bases de données par instance de 100 à 500.

Les différences architecturales entre les niveaux de service sont expliquées en profondeur dans la disponibilité.

Impact sur les opérations de gestion

Les opérations de gestion sur une instance managée SQL peuvent affecter les opérations de gestion d’autres instances placées dans le même sous-réseau :

  • Les opérations de restauration de longue durée dans un cluster virtuel placent d’autres opérations dans le même cluster virtuel en attente, telles que les opérations de création ou de mise à l’échelle.

    Exemple: S’il existe une opération de restauration longue et une demande de mise à l’échelle qui réduit le groupe de machines virtuelles, la demande de réduction prend plus de temps, car elle attend la fin de l’opération de restauration avant de pouvoir continuer.

  • Une opération de création ou de mise à l’échelle d’instance ultérieure est mise en attente par une mise à l’échelle d’instance ou de création d’instance lancée précédemment qui a lancé un redimensionnement du groupe de machines virtuelles.

    Exemple: S’il existe plusieurs demandes de création et/ou de mise à l’échelle dans le même sous-réseau sous le même groupe de machines virtuelles et qu’une d’entre elles lance un redimensionnement d’un groupe de machines virtuelles, toutes les demandes envoyées 1 minutes après la demande d’opération initiale dure plus longtemps que prévu, car ces demandes doivent attendre la fin du redimensionnement avant de reprendre.

  • Les opérations de création/mise à l’échelle soumises dans une fenêtre de 1 minute sont traitées par lots et exécutées en parallèle.

    Exemple: Un seul redimensionnement de cluster virtuel est effectué pour toutes les opérations soumises dans une fenêtre de 1 minute (mesurée à partir du moment où la première demande d’opération est envoyée). Si une autre demande est envoyée plus de 1 minute après l’envoi du premier, elle attend que le redimensionnement du cluster virtuel se termine avant le démarrage de l’exécution.

Importante

Les opérations de gestion mises en attente en raison d’une autre opération en cours sont automatiquement reprise une fois les conditions remplies. Aucune action de l’utilisateur n’est nécessaire pour reprendre les opérations de gestion temporairement suspendues.

Surveiller les opérations de gestion

Pour savoir comment surveiller la progression et l’état de l’opération de gestion, consultez Surveillance des opérations de gestion d’Azure SQL Managed Instance.

Annuler les opérations de gestion

Pour savoir comment annuler l’opération de gestion, consultez Annuler les opérations de gestion d’Azure SQL Managed Instance.

Contenu connexe

  • Last updated on