Microsoft Azure fournit un moteur de base de données Platform as a Service (PaaS) via la plate-forme Azure SQL Database, afin que nous puissions utiliser cette base de données pour les applications basées sur le cloud. Le principal avantage d'Azure SQL Database est de permettre une mise à l'échelle facile sans temps d'arrêt et ne nécessite aucun processus de mise à niveau ou de correction de version. De plus, nous n'avons pas à nous soucier des problèmes matériels.

Cependant, la considération importante d'Azure SQL Database est de répondre aux exigences de performances de la base de données déployée pour un coût minimum. Sans aucun doute, personne ne veut payer pour les ressources ou fonctionnalités redondantes qu'il n'utilise pas ou ne prévoit pas d'utiliser.

À ce stade, Microsoft Azure propose deux modèles d'achat différents pour assurer la rentabilité :

• Modèle d'achat basé sur l'unité de transaction de base de données (DTU).
• Modèle d'achat basé sur le cœur virtuel (vCore)

Une décision de modèle d'achat affecte directement les performances de la base de données et le montant total des factures. À mon avis, si la base de données déployée ne consomme pas trop de ressources, le modèle d'achat basé sur DTU sera plus approprié.

Nous allons maintenant discuter des détails de ces deux modèles d'achat dans les sections suivantes.

Modèle d'achat basé sur l'unité de transaction de base de données (DTU)

Afin de comprendre plus clairement le modèle d'achat basé sur la DTU, nous devons clarifier ce qui fait une DTU logique dans Azure SQL Database. DTU est l'abréviation de "Database Transaction Unit" et décrit une métrique d'unité de performance pour Azure SQL Database. Nous pouvons tout comme le DTU à la puissance en chevaux dans une voiture car cela affecte directement les performances de la base de données. La DTU représente un mélange des métriques de performances suivantes en tant qu'unité de performance unique pour Azure SQL Database :

• Processeur
• Mémoire
• E/S de données et E/S de journal

L'idée principale du concept DTU est d'offrir une configuration de ressources préconfigurée aux clients afin de simplifier la mise à l'échelle des performances sur une seule métrique. Par exemple, si nous avons besoin de plus de performances, nous pouvons faire glisser la barre et augmenter le nombre de DTU dans Azure SQL Database.

Le modèle d'achat basé sur les DTU contient trois niveaux de service différents et ces niveaux de service offrent différentes DTU et options de fonctionnalités. Le tableau suivant illustre les niveaux de service qui ont participé au modèle d'achat basé sur les DTU.

Comme nous pouvons le constater, les DTU et les fonctionnalités maximales varient en fonction de leur niveau de service. De plus, le modèle de tarification sera modifié en fonction du niveau de service. Par exemple, la configuration suivante pour une seule base de données dans le modèle d'achat basé sur DTU sera de 584,00 USD par mois.

Bassin élastique

En bref, Elastic Pool nous aide à gérer et à mettre à l'échelle automatiquement les multiples bases de données qui ont des demandes de ressources imprévisibles et variables sur un pool de ressources partagées. Grâce au pool élastique, nous n'avons pas besoin de faire évoluer les bases de données en continu en fonction des fluctuations de la demande de ressources. Les bases de données qui participent au pool consomment les ressources du pool élastique lorsqu'elles sont nécessaires, mais elles ne peuvent pas dépasser les limites des ressources du pool élastique afin de fournir une solution rentable.

Estimation correcte du DTU pour Azure SQL Database

Après avoir décidé d'utiliser le modèle d'achat basé sur DTU, nous devons trouver la question-réponse suivante avec des raisons logiques :

• Quel niveau de service et combien de DTU sont nécessaires pour ma charge de travail lors de la migration vers Azure SQL ?

DTU Calculator sera la principale solution pour estimer les besoins en DTU lorsque nous migrerons des bases de données sur site vers Azure SQL Database. L'idée principale de cet outil est de capturer les différentes utilisations de métriques du serveur SQL existant qui affectent les DTU, puis il essaie d'estimer approximativement les DTU et le niveau de service à la lumière des utilisations de performances collectées. La calculatrice DTU collecte les métriques suivantes via l'utilitaire de ligne de commande ou le script PowerShell et enregistre ces métriques dans un fichier CSV.

• Processeur - % de temps processeur
• Disque logique – Lectures de disque/s
• Disque logique :écritures sur disque/s
• Base de données – Octets de journal supprimés/s

Dans cet article, nous apprendrons l'utilisation de l'utilitaire de ligne de commande car il s'agit d'un projet open source et les codes sont hébergés sur le GitHub. Ainsi, nous pouvons apporter des modifications facilement si nous en avons besoin. Après avoir téléchargé et décompressé l'utilitaire de ligne de commande, deux fichiers viendront devant nous.

SqlDtuPerfmon.exe.config nous aide à déterminer certains paramètres de l'utilitaire de ligne de commande :

CsvPath spécifie le chemin du fichier CSV où les métriques collectées seront stockées.

SampleInterval spécifie combien de secondes d'intervalle les échantillons seront collectés

MaxSamples spécifie le nombre maximum d'échantillons qui seront collectés.

À ce stade, nous devons prendre en compte certaines considérations concernant le calculateur de DTU. DTU Calculator collecte l'utilisation totale des métriques sur l'ordinateur. Pour cette raison, les autres processus qui affectent la consommation du processeur, de la mémoire et du disque doivent être arrêtés, sinon il sera difficile de faire une estimation précise des DTU. Un autre problème est que, dans la mesure du possible, nous devons collecter l'utilisation des métriques qui couvrent les intervalles de temps de charge de travail de pointe. De cette façon, le calculateur de DTU offre les meilleures recommandations et nous découvrons l'exigence maximale de DTU avec une estimation plus approximative. Maintenant, nous allons exécuter SqlDtuPerfmon.exe et il commencera directement à collecter l'utilisation des ressources et enregistrera le fichier CSV spécifié.

Une fois la collecte de l'utilisation des ressources terminée, nous entrerons le nombre de cœurs et téléchargerons le fichier CSV sur le site Web du calculateur DTU.

Lorsque nous cliquons sur le bouton Calculer, tout d'abord, le graphique à secteurs Niveau de service/Niveau de performance apparaît à l'écran et affiche les suggestions de niveau de service estimées divisées en tranches avec les détails en pourcentage. Selon DTU Calculator, le niveau Standard - S6 fournira des performances satisfaisantes pour cette charge de travail.

Juste en dessous de ce graphique, le graphique des DTU au fil du temps est affiché et ce graphique représente l'évolution des DTU par rapport à la période. Avant d'évaluer ce graphique, nous pouvons ajouter quelques informations supplémentaires afin de l'interpréter plus facilement.

Comme vous pouvez le voir, le graphique linéaire représente une charge de travail instable, mais cela avait plus de sens lorsque nous avons ajouté des notes d'information. À mon avis, ce graphique est très utile pour comprendre l'interaction entre les changements de charge de travail et les DTU. Ainsi, nous pouvons faire une estimation plus appropriée des DTU requis. Comme nous l'avons mentionné à l'entrée de l'article, notre objectif principal devrait être de trouver une solution rentable pour la charge de travail.

Cependant, ces suggestions n'expriment pas les exigences précises du DTU dans Azure SQL. Pour cette raison, nous devrons peut-être modifier le niveau de service ou le modèle d'achat après le déploiement de la base de données sur Azure SQL.

Lorsque nous cliquons sur Afficher plus de détails, des rapports supplémentaires s'affichent et ces rapports représentent les recommandations individuelles pour les utilisations des ressources CPU, IOPS et Log. Ils seront très utiles pour comprendre particulièrement ces utilisations.

Modèle d'achat basé sur le cœur virtuel (vCore)

Ce concept est similaire à l'approche traditionnelle car nous sommes en mesure de décider de chaque ressource de la base de données. Nous pouvons organiser les VCores et les options de taille maximale des données manuellement dans ce modèle. Cependant, nous ne pouvons pas déterminer la ressource mémoire. Chaque VCore est livré avec une mémoire dédiée et la valeur dédiée de la mémoire dépend de la génération des VCore.

Enfin, dans ce modèle, nous pouvons choisir les niveaux de service suivants :

• Usage général.
• Critique pour l'entreprise
• Hyperscale

Conclusion

Dans cet article, nous avons exploré les modèles d'achat de la base de données Azure SQL et nous avons découvert les instructions d'utilisation du calculateur de DTU afin d'estimer le DTU requis dans Azure SQL pour les bases de données sur site.