Architecture des fonctions distribuées Hyperscale
S’applique à : 
Azure SQL Database
Le niveau de service Hyperscale utilise une architecture avec des niveaux de stockage et de calcul séparés et hautement évolutifs. Cet article décrit les composants qui permettent aux clients de mettre rapidement à l’échelle des bases de données Hyperscale tout en bénéficiant de sauvegardes quasi instantanées et de journalisation des transactions hautement évolutives.
Conseil
La tarification simplifiée de SQL Database Hyperscale est arrivée en décembre 2023. Pour en savoir plus, reportez-vous au blog de tarification Hyperscale.
Présentation de l’architecture Hyperscale
Les moteurs de base de données traditionnels centralisent les fonctions de gestion des données dans un même processus : même les bases de données distribuées en production ont aujourd’hui plusieurs copies d’un moteur de données monolithique.
Les bases de données Hyperscale suivent une approche différente. Hyperscale sépare le moteur de traitement des requêtes, où la sémantique des différents moteurs de données diverge, des composants qui assurent le stockage et la durabilité à long terme des données. De cette manière, la capacité de stockage peut être étendue en douceur jusqu'à 128 To pour une seule base de données Hyperscale.
Toutes les communications réseau entre les composants Hyperscale utilisent l’infrastructure réseau Azure avec redondance intégrée.
Les réplicas secondaires à haute disponibilité et les réplicas nommés sont des nœuds de calcul facultatifs pouvant être ajoutés à la demande. Ils partagent tous deux les mêmes composants de stockage, aucune copie de données n’est donc nécessaire pour mettre en place un nouveau réplica. Un réplica géosecondaire peut être ajouté à la demande dans la même région ou dans une autre région Azure. Pour la redondance et la protection des données, les réplicas géosecondaires disposent de composants de stockage différents de ceux utilisés par le réplica principal.
Le diagramme suivant illustre l’architecture Hyperscale fonctionnelle :
Une base de données Hyperscale contient les types de composants suivants : nœuds de calcul, serveurs de pages, service de journal et stockage Azure.
Calcul
Le nœud de calcul est l’emplacement où réside le moteur relationnel. Le nœud de calcul traite le langage, les requêtes et les transactions. Toutes les interactions utilisateur avec une base de données Hyperscale se produisent via les nœuds de calcul. Les nœuds de calcul peuvent être configurés pour utiliser un calcul serverless ou provisionné.
Les nœuds de calcul disposent de caches SSD locaux appelés Resilient Buffer Pool Extension (cache de données RBPEX). Le cache de données RBPEX est un cache de données intelligent à faible latence qui réduit la nécessité d’extraire des données à partir de serveurs de pages distants.
Les bases de données Hyperscale ont un nœud de calcul principal où la charge de travail et les transactions en lecture-écriture sont traitées. Jusqu’à quatre nœuds de calcul secondaires à haute disponibilité peuvent être ajoutés à la demande. Ils agissent comme nœuds de serveur de secours à des fins de basculement et peuvent servir de nœuds de calcul en lecture seule pour décharger les charges de travail en lecture lorsque cela est nécessaire. Les réplicas nommés sont des nœuds de calcul secondaires conçus pour autoriser plusieurs scénarios de scale-out en lecture OLTP et pour mieux prendre en charge les charges de travail de traitement transactionnel et analytique hybride (HTAP, Hybrid Transactional and Analytical Processing). Un nœud de calcul géosecondaire peut être ajouté à des fins de récupération d’urgence, ainsi qu’en tant que nœud de calcul en lecture seule pour décharger des charges de travail de lecture dans une autre région Azure.
En mode serverless, le réplica principal et tous les réplicas à haute disponibilité ou les réplicas nommés sont mis à l’échelle automatiquement indépendamment en fonction de leur utilisation. La plage de mise à l’échelle automatique du calcul pour le réplica principal et les réplicas nommés est configurée indépendamment. La plage de mise à l’échelle automatique des réplicas à haute disponibilité est héritée de la configuration de mise à l’échelle automatique spécifiée par le réplica principal ou le réplica nommé associé.
Le moteur de base de données s’exécutant sur des nœuds de calcul Hyperscale est le même que dans les autres niveaux de service Azure SQL Database. Lorsque les utilisateurs interagissent avec le moteur de base de données sur des nœuds de calcul Hyperscale, la surface d’exposition prise en charge et le comportement du moteur sont les mêmes que dans d’autres niveaux de service, à l’exception des limitations connues.
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. Chaque serveur de pages dispose également d’un réplica conservé pour la redondance et la disponibilité.
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. Les serveurs de pages sont tenus à jour en relisant les enregistrements du journal des transactions à partir du service de journalisation.
Les serveurs de pages entretiennent aussi les caches SSD de couverture pour améliorer les performances. Le stockage à long terme des pages de données s’effectue dans le Stockage Azure pour une meilleure durabilité.
Service de journal
Le service de journal accepte les enregistrements du journal des transactions qui correspondent aux modifications de données du réplica de calcul principal. Les serveurs de pages reçoivent ensuite les enregistrements du journal du service de journal et appliquent les modifications à leurs tranches de données respectives. En outre, les réplicas secondaires de calcul reçoivent les enregistrements de journal du service de journal et relisent uniquement les modifications apportées aux pages déjà dans leur pool de mémoires tampons ou le cache RBPEX local. Tous les changements de données dans le réplica de calcul principal sont propagés par le biais du service de journal à tous les réplicas de calcul secondaires et les serveurs de pages.
Enfin, les enregistrements du journal des transactions sont poussés vers le stockage à long terme dans Azure Storage, qui est un référentiel de stockage virtuellement infini. Avec ce mécanisme, vous n’avez plus besoin de tronquer fréquemment le journal. Les raisons courantes de la croissance des journaux, telles que les sauvegardes de fichier journal manquées ou la réplication lente des données vers des réplicas secondaires, ne s’appliquent pas à Hyperscale. Le service de journal a une mémoire locale et des caches SSD pour accélérer l’accès aux enregistrements de journal.
Azure Storage
Stockage Azure contient tous les fichiers de données d’une base de données. Les serveurs de pages tiennent à jour les fichiers de données dans Stockage Azure. Ce stockage est également utilisé à des fins de sauvegarde et peut être répliqué entre les régions en fonction du choix de la redondance du stockage.
Les sauvegardes sont implémentées à l’aide de captures instantanées de stockage de fichiers de données. Les opérations de restauration à l’aide d’instantanés sont rapides, quelle que soit la taille des données. Une base de données peut être restaurée à n’importe quel point dans le temps dans la période de conservation de sauvegarde.
Hyperscale prend en charge la redondance de stockage configurable. Lors de la création d'une base de données Hyperscale, vous pouvez faire votre choix parmi les types de stockage standard Azure suivants :
- Stockage localement redondant (LRS)
- Stockage redondant interzone (ZRS)
- Stockage géo-redondant avec accès en lecture (RA-GRS)
- Stockage géo-redondant interzone avec accès en lecture (RA-GRS)
Les options de stockage redondant interzone sont disponibles dans les régions Azure dotées de zones de disponibilité.
L’option de redondance de stockage sélectionnée est utilisée pendant la durée de vie de la base de données pour la redondance de stockage de données et la redondance de stockage de sauvegarde.