Azure SQL Database est un service basé sur une architecture de moteur de base de données SQL Server.
Celle-ci est ajustée pour l’environnement cloud afin de garantir une disponibilité de 99,99 % même en cas de panne d’infrastructure. Trois modèles d’architecture sont utilisés dans Azure SQL Database :
• Usage général/Standard
• Hyperscale
• Critique pour l’entreprise/Premium
Le niveau de service Hyperscale dans Azure SQL Database est le tout nouveau niveau de service du modèle d’achat vCore. Ce niveau de service est un stockage hautement scalable et un niveau de performances de calcul qui tire parti de l’architecture Azure pour augmenter le stockage et les ressources de calcul d’une base de données Azure SQL bien au-delà des limites disponibles des niveaux Usage général et Critique pour l’entreprise.
Le niveau de service Hyperscale dans Azure SQL Database fournit les fonctionnalités supplémentaires suivantes :
- Prise en charge d’une taille de base de données pouvant atteindre 100 To
- Sauvegardes de base de données quasi instantanées (basées sur des instantanés de fichiers conservés dans le Stockage Blob Azure), quelle que soit leur taille, sans impact des E/S sur les ressources de calcul
- Restaurations de base de données rapides (basées sur des instantanés de fichiers) en minutes plutôt qu’en heures ou en jours (opération qui ne dépend pas de la taille des données)
- Meilleures performances générales en raison d’un débit de journal plus élevé et de temps de validation de transaction plus rapides, quels que soient les volumes de données
- Augmentation rapide du nombre de nœuds (scale out) : vous pouvez provisionner un ou plusieurs nœuds en lecture seule pour décharger votre charge de travail de lecture et les utiliser comme serveurs de secours
- Augmentation rapide de la puissance des ressources (scale up) : vous pouvez, en temps constant, augmenter la puissance de vos ressources de calcul pour prendre en charge des charges de travail lourdes quand vous en avez besoin, puis diminuer la puissance des ressources de calcul quand elles ne sont plus nécessaires.
À qui est destiné le niveau de service Hyperscale ?
Le niveau de service Hyperscale est principalement destiné aux clients qui ont de grandes bases de données en local et veulent moderniser leurs applications en les déplaçant dans le cloud, ou aux clients qui sont déjà dans le cloud et sont limités par les restrictions en matière de taille maximale de base de données (1-4 To). Il est également destiné aux clients qui recherchent des hautes performances et une haute scalabilité pour le stockage et le calcul.
Modèle tarifaire Hyperscale
Le niveau de service Hyperscale est disponible uniquement dans le modèle vCore. Pour s’aligner sur la nouvelle architecture, le modèle tarifaire est légèrement différent des niveaux de service Usage général ou Critique pour l’entreprise :
- Calcul :
Le prix unitaire du calcul Hyperscale est par réplica. Par défaut, nous créons un réplica principal et un réplica en lecture seule par base de données Hyperscale. Les utilisateurs peuvent ajuster le nombre total de réplicas, y compris de réplicas principaux de 1 à 5.
- Stockage :
Vous n’avez pas besoin de spécifier la taille maximale des données lors de la configuration d’une base de données Hyperscale. Dans le niveau Hyperscale, le stockage de votre base de données vous est facturé selon votre utilisation réelle.
Architecture des fonctions distribuées
Contrairement aux moteurs de base de données traditionnels qui centralisaient toutes les fonctions de gestion de données dans un même emplacement/processus, une base de données Hyperscale sépare le moteur de traitement des requêtes, où la sémantique des différents moteurs de données diffère, des composants qui fournissent un stockage à long terme et une durabilité pour les données.
Une base de données Hyperscale contient les différents types de nœuds suivants :
- Nœud de calcul
Comme le nœud de calcul héberge le moteur relationnel, c’est là que tous les éléments de langage, le traitement des requêtes et ainsi de suite, se produisent. Toutes les interactions utilisateur avec une base de données Hyperscale se produisent dans ces nœuds de calcul. Les nœuds de calcul ont des caches SSD (étiquetés RBPEX – Extension du pool de mémoires tampons durable dans le diagramme précédent) afin de réduire le nombre d’allers-retours sur le réseau nécessaires pour récupérer une page de données. Il existe un nœud de calcul principal où sont traitées toutes les charges de travail de lecture-écriture et les transactions. Il existe un ou plusieurs nœuds de calcul secondaires qui agissent comme des serveurs de secours pour le basculement, et comme des nœuds de calcul en lecture seule pour décharger les charges de travail de lecture (si cette fonctionnalité est souhaitée).
- Nœud de serveur de pages
Les serveurs de pages sont des systèmes qui représentent un moteur de stockage scale-out. Chaque serveur de pages est responsable d’un sous-ensemble de pages dans la base de données. Nominalement, chaque serveur de pages contrôle entre 128 Go et 1 To de données. Aucune donnée n’est partagée sur plusieurs serveurs de pages. Le travail d’un serveur de pages est de servir à la demande des pages de base de données aux nœuds de calcul et d’actualiser les pages à mesure que les transactions mettent à jour les données.
- Nœud de service de journal
Le nœud de service de journal accepte les enregistrements de journal du nœud de calcul principal, les conserve dans un cache durable et les transfère au reste des nœuds de calcul (afin qu’ils mettent à jour leurs caches) ainsi qu’aux serveurs de pages appropriés afin que les données y soient mises à jour. De cette façon, tous les changements de données dans le nœud de calcul principal sont propagés par le service de journal à tous les nœuds de calcul secondaires et les serveurs de pages.
- Nœud de stockage Azure
Le nœud de stockage Azure est la destination finale des données provenant des serveurs de pages. Ce stockage est utilisé pour la sauvegarde ainsi que pour la réplication entre régions Azure. Les sauvegardes sont constituées d’instantanés de fichiers de données. L’opération de restauration est rapide à partir de ces instantanés, et les données peuvent être restaurées à n’importe quel point dans le temps.
Sauvegarde et restauration
Comme les sauvegardes sont basées sur des instantanés de fichier, elles sont quasi instantanées. La séparation du stockage et du calcul permet de pousser l’opération de sauvegarde/restauration vers la couche de stockage afin de réduire la charge de traitement sur le nœud de calcul principal. Par conséquent, la sauvegarde de grandes bases de données n’impacte pas les performances du nœud de calcul principal. De même, les restaurations sont effectuées en copiant l’instantané de fichier et n’ont donc pas la taille d’une opération de données. Pour les restaurations dans le même compte de stockage, l’opération de restauration est rapide.
Ecrit par David THIOMBIANO.
Vous avez un projet à nous confier contactez-nous !
Si vous êtes intéressé pour travailler sur des projets similaire rejoignez nos équipes !