Mettre à l’échelle de façon dynamique les ressources de base de données avec un temps d’arrêt minimal : Azure SQL Database et Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL DatabaseAzure SQL Managed Instance

base de données Azure SQL et Azure SQL Managed Instance vous permet d'ajouter de manière dynamique plus de ressources à votre base de données avec un temps d'arrêt minimal. Toutefois, il existe un délai de basculement durant lequel la connectivité à la base de données est perdue pendant un court laps de temps, qui peut être atténué à l'aide d'une logique de nouvelle tentative.

Vue d’ensemble

Lorsque la demande ciblant votre application s’accroît de quelques appareils et clients à plusieurs millions, Azure SQL Database et SQL Managed Instance se mettent à l’échelle immédiatement avec un temps d’arrêt minimal. La scalabilité est une des caractéristiques les plus importantes de PaaS (plateforme en tant que service) qui vous permet d’ajouter plus de ressources de façon dynamique à votre service, si besoin. Azure SQL Database vous permet de modifier en toute simplicité vos ressources (alimentation processeur, mémoire, débit E/S et stockage) allouées à vos bases de données.

Vous pouvez limiter les problèmes de performances dus à une utilisation croissante de votre application qui ne peuvent être résolus en utilisant des méthodes de réécriture de requête ou d’indexation. L’ajout de ressources vous permet de réagir rapidement lorsqu’une base de données atteint la limite de ressources actuelles et a besoin de plus de puissance pour gérer les charges entrantes. Azure SQL Database vous permet aussi de diminuer la taille des ressources lorsqu’elles ne sont pas nécessaires afin de réduire les coûts.

Vous n’avez pas à vous inquiéter de l’achat de matériel et du changement d’infrastructure sous-jacente. La mise à l'échelle d’une base de données peut être effectuée en toute simplicité via le portail Azure à l’aide d’un curseur.

Scale database performance

Azure SQL Database offre le modèle d’achat DTU et le modèle d’achat DTU et le modèle d'achat vCore, tandis que Azure SQL Managed Instance offre uniquement le modèle d’achat vCore.

  • Le modèle d’achat DTU offre une combinaison de ressources de calcul, de mémoire et d’E/S réparties sur trois niveaux de service pour prendre en charge les charges de travail de base de données, aussi bien légères qu’importantes : De base, Standard et Premium. Les niveaux de performance de chaque niveau fournissent une combinaison différente de ces ressources, à laquelle vous pouvez ajouter d’autres ressources de stockage.
  • Le modèle d’achat vCore vous permet de choisir le nombre de vCores, la quantité de mémoire et de stockage, ainsi que la vitesse de stockage. Ce modèle d’achat propose trois niveaux de service : Usage général, Critique pour l’entreprise et Hyperscale.

Le niveau de service, le niveau de calcul et les limites de ressources d’une base de données, d’un pool élastique ou d’une instance managée peuvent être modifiés à tout moment. Par exemple, vous pouvez créer votre première application sur une seule base de données avec le niveau de calcul serverless. Vous pouvez à tout moment remplacer son niveau de service, manuellement ou automatiquement, par le niveau de calcul provisionné pour répondre aux besoins de votre solution.

Notes

Les exceptions notables pour lesquelles vous ne pouvez pas modifier le niveau de service d’une base de données sont les suivantes :

  • Les bases de données qui utilisent des fonctionnalités uniquement disponibles dans les niveaux de service Critique pour l’entreprise/Premium ne peuvent pas être modifiées pour utiliser le niveau de service Usage général/Standard. Actuellement, la seule fonctionnalité de ce type est OLTP en mémoire.
  • Les bases de données créées à l’origine dans le niveau de service Hyperscale ne peuvent pas être déplacées vers d’autres niveaux de service. Si vous avez migré une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale, vous pouvez inverser la migration vers le niveau de service usage général dans les 45 jours suivant la migration d’origine vers Hyperscale. Si vous souhaitez migrer la base de données vers un autre niveau de service, tel que critique pour l'entreprise, effectuez d’abord une migration inversée vers le niveau de service usage général, puis effectuez une autre migration. Découvrez plus en détail comment inverser la migration à partir d’Hyperscale.

Vous pouvez ajuster les ressources allouées à votre base de données en modifiant l’objectif de service, ou la mise à l’échelle, pour répondre aux demandes de la charge de travail. De cette façon, vous payez uniquement pour les ressources dont vous avez besoin, quand vous en avez besoin. Reportez-vous à la remarque concernant l’impact potentiel d’une opération de mise à l’échelle sur une application.

Azure SQL Database offre la possibilité de mettre à l'échelle vos bases de données de façon dynamique :

  • Avec une base de données unique, vous pouvez utiliser des modèles DTU ou vCore pour définir le volume maximal de ressources assignées à chaque base de données.
  • Les pools élastiques vous permettent de définir la limite de ressources maximale par groupe de bases de données dans le pool.

Azure SQL Managed Instance vous permet également une mise à l’échelle :

  • SQL Managed Instance utilise le mode vCores et vous permet de définir le nombre maximum de cœurs UC et la quantité maximale de stockage alloués à votre instance. Toutes les bases de données au sein de l’instance gérée partageront les ressources allouées à l’instance.

Conseil

La mise à l’échelle dynamique permet aux clients de modifier l’allocation des ressources manuellement ou par programmation. La fonctionnalité de mise à l’échelle dynamique est disponible pour toutes les ressources Azure SQL Database et Azure SQL Managed Instance.

En plus de prendre en charge la mise à l’échelle dynamique, le niveau Serverless dans Azure SQL Database prend en charge la mise à l’échelle automatique. Les bases de données du niveau serverless mettent automatiquement à l’échelle les ressources dans une plage spécifiée par le client, en fonction de la demande de charge de travail. Aucune action du client n’est requise pour mettre à l’échelle la base de données.

Impact des opérations de scale-up ou de scale-down

Quelle que soit la saveur, une action de scale-up ou de scale-down redémarre le processus du moteur de base de données et le déplace si nécessaire vers une autre machine virtuelle. Le déplacement du processus du moteur de base de données vers une nouvelle machine virtuelle est un processus en ligne durant lequel vous pouvez continuer à utiliser votre service Azure SQL Database existant. Une fois que le moteur de base de données cible est prêt à traiter les requêtes, les connexions ouvertes au moteur de base de données actif sont terminées et les transactions non validées sont restaurées. De nouvelles connexions sont établies au moteur de base de données cible.

Notes

Il n’est pas recommandé de mettre votre instance gérée à l’échelle si une transaction durable, telle que l’importation de données, les travaux de traitement de données, la régénération d’index, etc., est en cours d’exécution, ou si vous avez une connexion active sur l’instance. Pour éviter que la mise à l’échelle ne prenne plus de temps que d’habitude, vous devez mettre l’instance à l’échelle à la fin de toutes les opérations durables.

Notes

Une courte interruption de la connexion risque de se produire à la fin du processus de mise à l’échelle. Si vous avez implémenté une Logique de nouvelles tentatives pour les erreurs temporaires standard, vous ne remarquerez pas le basculement.

Autres méthodes de mise à l’échelle

La mise à l'échelle des ressources reste la façon la plus facile et efficace pour améliorer les performances de votre base de données sans changer le code de la base de données ou de l’application. Dans certains cas, même les niveaux de service, les tailles de calcul et les optimisations de performances les plus élevés peuvent ne pas suffire à gérer votre charge de travail correctement et de façon économique. Dans ce cas, vous disposez d’autres options pour mettre à l’échelle votre base de données :

  • Lecture du Scale-out est une fonctionnalité disponible qui vous offre un réplica en lecture seule de vos données, sur lequel vous pouvez exécutez des requêtes en lecture seule exigeantes telles que les rapports. Un réplica en lecture seule gère votre charge de travail en lecture seule sans affecter l’utilisation des ressources sur votre base de données principale.
  • Le partitionnement de base de données est un ensemble de techniques qui vous permet de diviser vos données en plusieurs bases de données pour les mettre à l'échelle indépendamment.

Étapes suivantes