Partage via

Les pools élastiques vous aident à gérer et à mettre à l’échelle plusieurs bases de données dans Azure SQL Database

  • Article

S’applique à : Azure SQL Database

Les pools élastiques Azure SQL Database constituent une solution simple et rentable de gestion et de mise à l’échelle de plusieurs bases de données qui ont des demandes d’utilisation variables et imprévisibles. Les bases de données d’un pool élastique se trouvent sur un seul serveur et partagent un nombre défini de ressources à prix fixe. Les pools élastiques dans Azure SQL Database permettent aux développeurs software as a service (SaaS) d’optimiser le rendement pour un groupe de bases de données respectant un budget prévu tout en offrant une élasticité des performances pour chaque base de données.

Présentation des pools élastiques SQL

Les développeurs SaaS créent des applications qui reposent sur des couches de données à grande échelle composées de bases de données multiples. Un modèle d’application courant consiste à approvisionner une base de données unique pour chaque client. Toutefois, les modèles d’utilisation sont souvent imprévisibles et varient d’un client à l’autre, et il est difficile de prévoir les besoins en ressources de chaque utilisateur de base de données. Vous disposez généralement de deux options :

  • Sur-approvisionner les ressources en fonction du pic d’utilisation et trop payer.
  • Sous-approvisionner pour réduire les coûts, au détriment des performances et de la satisfaction des clients au moment des pics d’utilisation.

Les pools élastiques résolvent ce problème en vous assurant que les bases de données disposent des ressources de performances nécessaires au moment où elles en ont besoin. Ils représentent un mécanisme simple d’allocation de ressources avec un budget prévisible. Pour en savoir plus sur les modèles de conception pour les applications SaaS à l’aide de pools élastiques, consultezModèles de conception pour les applications SaaS multilocataires avec SQL Database.

Important

Les frais par base de données pour les pools élastiques n’existent pas. Vous êtes facturé pour chaque heure d’existence d’un pool selon le nombre d’eDTU ou de vCores le plus élevé, indépendamment de l’utilisation ou si le pool a été actif pendant moins d’une heure.

Un pool élastique est un pool que partagent plusieurs bases de données, et pour lequel vous pouvez acheter des ressources lorsque les bases de données l’utilisent de manière imprévisible. Vous pouvez configurer les ressources du pool avec le modèle d’achat DTU ou le modèle d’achat vCore. Le besoin en ressources d’un pool est déterminé par l’utilisation globale de ses bases de données.

La quantité de ressources disponibles pour le pool dépend de votre budget. Tout ce que vous avez à faire, c’est :

  • Ajouter des bases de données au pool.
  • Facultativement, définissez les ressources minimales et maximales pour les bases de données, dans le modèle d’achat DTU ou vCore.
  • Définir les ressources du pool en fonction de votre budget.

Vous pouvez utiliser des pools pour faire évoluer votre service en toute simplicité et passer d’une lean startup à une entreprise mature à une vitesse en croissance constante.

Au sein du pool, les bases de données individuelles peuvent, en toute souplesse, utiliser les ressources des paramètres définis. Si la charge est élevée, une base de données peut consommer plus de ressources pour répondre à la demande. Les bases de données soumises à des charges légères en consomment moins, et celles qui ne sont soumises à aucune charge n’en consomment pas du tout. L’approvisionnement des ressources pour l’ensemble du pool plutôt que pour des bases de données uniques simplifie vos tâches de gestion. En outre, vous disposez d’un budget prévisible pour le pool.

Des ressources supplémentaires peuvent être ajoutées à un pool existant avec un temps d’arrêt minimal. Si les ressources supplémentaires ne sont plus nécessaires, elles peuvent être supprimées du pool existant à tout moment. Vous pouvez également ajouter des bases de données dans le pool ou en supprimer. Si, de manière prévisible, une base de données sous-utilise des ressources, vous pouvez la déplacer.

Remarque

Lorsque vous déplacez des bases de données en direction ou en dehors d’un pool élastique, cela n’entraîne aucun temps d’arrêt, hormis un bref laps de temps (de l’ordre de quelques secondes) à la fin de l’opération lorsque les connexions de base de données sont abandonnées.

Quand devez-vous envisager d’utiliser un pool élastique SQL Database ?

Les pools sont parfaits dans le cas de nombreuses bases de données avec des modèles d’utilisation spécifiques. Pour une base de données donnée, ce modèle se caractérise par une faible utilisation moyenne avec des pics d'utilisation relativement rares. À l’inverse, évitez de placer des bases de données multiples avec une utilisation moyenne-élevée permanente dans le même pool élastique.

Plus vous ajoutez de bases de données à un pool, plus vous faites d’économies. En fonction de votre modèle d’utilisation de l’application, il est possible de faire des économies avec seulement deux bases de données S3.

Les sections suivantes vous aident à comprendre comment évaluer si votre collection de bases de données spécifique peut tirer profit de l’utilisation d’un pool. Les exemples utilisent des pools Standard, mais les mêmes principes s’appliquent également aux pools élastiques dans d’autres niveaux de service.

Évaluer des modèles d'utilisation de base de données

La figure suivante montre l’exemple d'une base de données qui est la plupart du temps inactive, mais qui connaît de temps en temps des pics d’activité. Ce modèle d’utilisation est adapté à un pool.

Graphique représentant une base de données unique adaptée à un pool.

Le graphique illustre l’utilisation de DTU sur une période de une heure comprise entre 12h00 et 13h00, où chaque point de données a une granularité d’une minute. À 12h10, DB1 culmine à 90 DTU, mais son utilisation moyenne totale est inférieure à cinq DTU. Une taille de calcul S3 est requise pour exécuter cette charge de travail dans une base de données unique. Cependant, cette taille laisse la plupart des ressources inutilisées pendant les périodes de faible activité.

Un pool permet de partager ces DTU inutilisées entre des bases de données multiples. Un pool réduit les DTU nécessaires et le coût global.

En s'appuyant sur l'exemple précédent, supposons qu'il y ait d’autres bases de données avec des modèles d'utilisation semblables à DB1. Dans les deux graphiques ci-dessous, les utilisations de 4 et 20 bases de données sont représentées sur le même graphique pour montrer qu’avec le modèle d’achat DTU, leur utilisation ne se chevauche pas dans le temps :

Graphique représentant quatre bases de données avec un modèle d’utilisation adapté à un pool.

Graphique représentant 20 bases de données avec un modèle d’utilisation adapté à un pool.

L’utilisation globale des DTU pour les 20 bases de données est illustrée par la ligne noire dans le graphique ci-dessus. Cela montre que l'utilisation globale des DTU ne dépasse jamais 100 DTU et que les 20 bases de données peuvent partager 100 eDTU sur cette période de temps. Le nombre de DTU est diminué par 20 et le prix par 13 par rapport au placement de chacune des bases de données dans des tailles de calcul S3 pour les bases de données uniques.

Cet exemple est idéal pour les raisons suivantes :

  • Il existe de grandes différences entre les pics d’utilisation et l'utilisation moyenne par base de données.
  • Les pics d’utilisation de chaque base de données se produisent à différents moments dans le temps.
  • Les eDTU sont partagées entre plusieurs bases de données.

Dans le modèle d’achat DTU, le prix d’un pool dépend de ses unités eDTU. Alors que le prix unitaire d’une eDTU pour un pool est 1,5 fois supérieur au prix unitaire d’une DTU pour une base de données unique, les eDTU du pool peuvent être partagées avec de nombreuses bases de données ; un nombre moins important d’eDTU est donc requis au total. Ces différences en matière de prix et de partage des eDTU constituent la base du potentiel d'économies que les pools peuvent présenter.

Dans le modèle d’achat vCore, le prix unitaire vCore pour les pools élastiques est le même que pour les bases de données uniques.

Comment choisir la bonne taille de pool ?

Pour un pool, la taille optimale dépend du nombre global de ressources nécessaires pour toutes les bases de données du pool. Vous devez déterminer :

  • Quantité maximale de ressources de calcul utilisées par toutes les bases de données du pool. Les ressources de calcul sont indexées par eDTU ou vCore selon le modèle d’achat choisi.
  • Nombre maximal d’octets de stockage que se partagent toutes les bases de données du pool.

Pour connaître les niveaux de service et les limites de ressources de chacun des modèles d’achat, consultez Modèle d’achat DTU ou Modèle d’achat vCore.

Les étapes suivantes peuvent vous aider à estimer si un pool est plus économique que les bases de données uniques :

  1. Estimer le nombre d’eDTU ou de vCore nécessaires pour le pool :

    1. Pour le modèle d’achat DTU :
      1. MAX(<Nombre total de bases de données x Utilisation moyenne des DTU par base de données>, <Nombre de bases de données connaissant un pic simultané x Utilisation maximale des DTU par base de données>)
    2. Pour le modèle d’achat vCore :
      1. MAX(<Nombre total de bases de données x Utilisation moyenne des vCores par base de données>, <Nombre de bases de données connaissant un pic simultané x Utilisation maximale des vCores par base de données>)

  2. Estimez l’espace de stockage total nécessaire au pool en ajoutant la taille des données nécessaires à toutes les bases de données du pool. Pour le modèle d’achat DTU, déterminez la taille du pool d’eDTU qui fournit cette quantité de stockage.

  3. Pour le modèle d’achat DTU, prenez la plus grande des estimations d’eDTU des étapes 1 et 2.

    1. Pour le modèle d’achat vCore, prenez l’estimation vCore de l’étape 1.

  4. Visiter la page de tarification SQL Database.

    1. Recherchez la plus petite taille de pool supérieure à l’estimation de l’étape 3.

  5. Comparez le prix du pool de l’étape 4 à celui des tailles de calcul appropriées pour les bases de données uniques.

Important

Si le nombre de bases de données dans un pool approche le maximum pris en charge, veillez à prendre en compte la gestion des ressources dans les pools élastiques denses.

Propriétés par base de données

Vous pouvez éventuellement définir des propriétés par base de données pour modifier les modèles de consommation des ressources dans les pools élastiques. Pour plus d’informations, reportez-vous à la documentation sur les limites de ressources pour les pools élastiques DTU et vCore.

Utilisation d’autres fonctionnalités SQL Database à l’aide de pools élastiques

Vous pouvez utiliser d’autres fonctionnalités SQL Database à l’aide de pools élastiques.

Travaux élastiques et pools élastiques

Un pool simplifie les tâches de gestion grâce à l’exécution des scripts dans des tâches élastiques . Un travail élastique élimine pratiquement le caractère fastidieux d’un nombre élevé de bases de données.

Pour en savoir plus sur les autres outils de base de données permettant d’utiliser des bases de données multiples, consultez Scale-out avec SQL Database.

Pools élastiques Hyperscale

Les pools élastiques Hyperscale Azure SQL Database sont en disponibilité générale.

Options de continuité de l’activité pour les bases de données d’un pool élastique

Les bases de données mises en pool prennent généralement en charge les mêmes fonctionnalités de continuité d’activité que celles disponibles pour les bases de données uniques :

  • Limite de restauration dans le temps : la limite de restauration dans le temps utilise les sauvegardes automatiques de base de données pour récupérer une base de données d’un pool à un moment précis dans le temps. Voir Limite de restauration dans le temps.
  • Géorestauration : la géorestauration constitue l’option de récupération par défaut lorsqu’une base de données est indisponible en raison d’un incident survenu dans la région où elle est hébergée. Consultez Géo-restauration.
  • La géoréplication active : pour les applications qui ont des exigences de récupération plus agressives que ce qu’offre la géo-restauration, configurez la géo-réplication active ou un groupe de basculement.

Pour plus d’informations sur les stratégies ci-dessus, consultez Aide sur la récupération d’urgence Azure SQL Database.

Création d’un nouveau pool élastique SQL Database à l’aide du portail Azure

Vous pouvez créer une pool élastique dans le portail Azure de deux façons :

  • Créez un pool élastique et sélectionnez un serveur existant ou nouveau.
  • Créez un pool élastique à partir d’un serveur existant.

Pour créer un pool élastique et sélectionner un serveur existant ou nouveau :

  1. Accédez au portail Azure pour créer un pool élastique. Recherchez et sélectionnez Azure SQL.

  2. Sélectionnez Créer pour ouvrir le volet Sélectionner l’option de déploiement SQL. Pour afficher plus d’informations sur les pools élastiques, sur la vignette Bases de données, sélectionnez Afficher les détails.

  3. Sur la vignette Bases de données, dans la liste déroulante Type de ressource, sélectionnez Pool élastique. Sélectionnez ensuite Créer.

    Capture d’écran montrant la création d’un pool élastique.

  4. Ensuite, gérez votre pool élastique via le portail Azure, PowerShell, Azure CLI, l’API REST ou T-SQL.

Pour créer un pool élastique à partir d’un serveur existant :

  1. Allez sur un serveur existant et sélectionnez Nouveau pool pour créer un pool directement dans ce serveur.

    Notes

    Vous pouvez créer plusieurs pools sur un serveur, mais il est impossible d’ajouter des bases de données de différents serveurs dans le même pool.

    Le niveau de service du pool détermine les fonctionnalités disponibles pour les bases de données élastiques du pool, ainsi que le nombre maximal de ressources pour chaque base de données. Pour plus d’informations, consultez les limites de ressources des pools élastiques dans le Modèle DTU. Pour les limites de ressource vCore de pools élastiques, consultez vCore-based resource limits - elastic pools (limites de ressource vCore - pools élastiques).

  2. Pour configurer les ressources et les prix du pool, cliquez sur Configurer le pool. Ensuite, sélectionnez un niveau de service, ajoutez les bases de données au pool, puis configurez les limites de ressources pour le pool et ses bases de données.

  3. Une fois le pool configuré, sélectionnez Appliquer, nommez le pool et sélectionnez OK pour créer le pool.

  4. Ensuite, gérez votre pool élastique via le portail Azure, PowerShell, Azure CLI, l’API REST ou T-SQL.

Surveiller un pool élastique et ses bases de données

Dans le portail Azure, vous pouvez surveiller l’utilisation d’un pool élastique et des bases de données que contient ce pool. Vous pouvez également apporter un ensemble de modifications à votre pool élastique et soumettre toutes les modifications en même temps. Ces modifications incluent l’ajout ou la suppression de bases de données, ainsi que le changement des paramètres du pool élastique ou des bases de données.

Vous pouvez utiliser les outils intégrés de monitoring des performances et d’alerte, combinés avec les indices de performance. De plus, SQL Database peut émettre des métriques et des journaux de ressources pour faciliter le monitoring.

Études de cas clients

  • SnelStart : SnelStart a utilisé des pools élastiques avec SQL Database pour développer rapidement ses services métier au rythme de 1 000 nouvelles bases de données SQL par mois.
  • Umbraco : Umbraco utilise des pools élastiques avec SQL Database afin d’approvisionner rapidement des services et de les mettre à l’échelle pour des milliers de locataires dans le cloud.
  • Daxko/CSI : Daxko/CSI utilise des pools élastiques avec SQL Database pour accélérer son cycle de développement et améliorer ses performances et ses services clients.

Contenu connexe