Niveau de service Hyperscale

S’applique à : Azure SQL Database

Azure SQL Database est 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 haute disponibilité 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 utilise l’architecture Azure pour effectuer un scale-out du stockage et des 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.

Notes

  • Pour en savoir plus sur les niveaux de service Usage général et Critique pour l’entreprise du modèle d’achat vCore, consultez les niveaux de service Usage général et Critique pour l’entreprise. Pour obtenir une comparaison du modèle d’achat vCore avec le modèle d’achat DTU, consultez Ressources et modèles d’achat Azure SQL Database.
  • Le niveau de service Hyperscale n'est actuellement disponible que pour Azure SQL Database, et non pour Azure SQL Managed Instance.

Présentation des fonctionnalités Hyperscale

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 (basées sur des instantanés de fichiers conservés dans le Stockage Blob Azure), quel 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).
  • Des performances globales plus élevées grâce à un débit plus important du journal des transactions et à des temps de validation des transactions plus rapides, quel que soit le volume des données.
  • Effectuer un scale-out rapide : vous pouvez provisionner un ou plusieurs réplicas en lecture seule pour déplacer votre charge de travail de lecture et les utiliser comme serveurs de secours.
  • Scale-up rapide : vous pouvez, en temps constant, augmenter la puissance de vos ressources de calcul pour prendre en charge des charges de travail lourdes en cas de besoin, puis la diminuer à nouveau.

Le niveau de service Hyperscale supprime de nombreuses limites pratiques traditionnellement rencontrées dans les bases de données cloud. Là où la plupart des autres bases de données sont limitées par les ressources disponibles dans un seul nœud, les bases de données du niveau de service Hyperscale n’ont pas de limite. Avec son architecture de stockage flexible, le stockage augmente en fonction des besoins. En fait, les bases de données Hyperscale sont créées sans taille maximale définie. Une base de données Hyperscale augmente en fonction des besoins, et vous êtes facturé uniquement pour la capacité que vous utilisez. Pour les charges de travail de lecture intensives, le niveau de service Hyperscale permet un scale-out rapide en provisionnant des réplicas de supplémentaires en fonction des besoins pour déplacer les charges de travail de lecture.

Par ailleurs, le temps nécessaire pour créer des sauvegardes de base de données ou pour augmenter ou diminuer la puissance n’est plus lié au volume de données de la base de données. Les bases de données Hyperscale peuvent être sauvegardées presque instantanément. Vous pouvez aussi mettre à l’échelle une base de données de plusieurs dizaines de téraoctets en quelques minutes. Cette fonctionnalité vous évite d’être limité par votre choix de configuration initial.

Pour plus d’informations sur les tailles de calcul pour le niveau de service Hyperscale, consultez Caractéristiques du niveau de service.

À qui est destiné le niveau de service Hyperscale

Le niveau de service Hyperscale est destiné à tous les clients qui ont besoin de performances et d’une disponibilité élevées, de sauvegardes et de restaurations rapides, et/ou d’un stockage rapide et d’une scalabilité de calcul. Cela inclut les clients qui passent au cloud pour moderniser leurs applications, ainsi que les clients qui utilisent déjà d’autres niveaux de service dans Azure SQL Database. Le niveau de service Hyperscale prend en charge un large éventail de charges de travail, de l’OLTP pur à l’analytique pure. Il est optimisé pour les charges de travail OLTP et HTAP (traitement analytique et de transaction hybride).

Important

Les pools élastiques ne prennent pas en charge le niveau de service Hyperscale.

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. Le prix Azure Hybrid Benefit est automatiquement appliqué aux réplicas nommés et à haute disponibilité. Les utilisateurs peuvent ajuster le nombre total de réplicas secondaires à haute disponibilité de 0 à 4, en fonction des exigences de disponibilité et d’extensibilité, et créer jusqu’à 30 réplicas nommés pour prendre en charge une variété de charges de travail de scale-out en lecture.

  • 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. Au niveau Hyperscale, le stockage de votre base de données est facturé en fonction de la répartition réelle. Un espace de stockage compris entre 10 Go et 100 To est automatiquement alloué, qui croît par incréments de 10 Go en fonction des besoins.

Pour plus d’informations sur les tarifs Hyperscale, consultez Tarifs Azure SQL Database.

Comparer les limites de ressources

Les niveaux de service basés sur vCore sont différenciés en fonction de la disponibilité de la base de données et du type de stockage, des performances et de la taille maximale du stockage, comme décrit dans le tableau suivant :

Usage général Hyperscale Critique pour l’entreprise
Idéal pour Offre des options de calcul et de stockage équilibrées et économiques. La plupart des charges de travail d’entreprise. Mise à l’échelle automatique de la taille de stockage jusqu’à 100 To, mise à l’échelle verticale et horizontale rapide du calcul, restauration rapide de la base de données. Applications OLTP avec des débits de transactions élevés et une faible latence des E/S. Offre une meilleure résilience aux défaillances et des basculements rapides à l’aide de plusieurs réplicas mis à jour de façon synchrone.
Taille de calcul 1 à 80 cœurs virtuels 1 à 80 vCores1 1 à 80 cœurs virtuels
Type de stockage Stockage distant Premium (par instance) Stockage découplé avec cache disque SSD local (par instance) Stockage SSD local ultra-rapide (par instance)
Taille de stockage1 5 Go - 4 To Jusqu’à 100 To 5 Go - 4 To
D’OPÉRATIONS D’E/S PAR SECONDE 500 IOPS par vCore avec un maximum de 7 000 IOPS L’architecture hyperscale est une architecture à plusieurs niveaux avec une mise en cache sur plusieurs niveaux. L’efficacité des IOPS dépend de la charge de travail. 5 000 IOPS avec un maximum de 200 000 IOPS
Disponibilité 1 réplica, aucune échelle horizontale en lecture, haute disponibilité redondante interzone (préversion), aucun cache local Plusieurs réplicas, jusqu’à 4 échelles horizontales en lecture, haute disponibilité redondante interzone, cache local partiel 3 réplicas, 1 échelle horizontale en lecture, haute disponibilité redondante interzone, stockage local complet
Sauvegardes Choix d’un stockage de sauvegarde géoredondant, redondant interzone ou localement redondant, conservation des données comprise entre 1 et 35 jours (7 jours par défaut) Choix d’un stockage de sauvegarde géoredondant, redondant interzone ou localement redondant, conservation des données comprise entre 1 et 35 jours (7 jours par défaut) Choix d’un stockage de sauvegarde géoredondant, redondant interzone ou localement redondant, conservation des données comprise entre 1 et 35 jours (7 jours par défaut)

1 Les pools élastiques ne sont pas pris en charge dans le niveau de service Hyperscale.

Notes

La rétention des sauvegardes à court terme, de 1 à 35 jours, pour les bases de données Hyperscale est actuellement en préversion.

Architecture des fonctions distribuées

L’approche Hyperscale sépare le moteur de traitement des requêtes des composants qui fournissent un stockage à long terme et une durabilité pour les données. Cette architecture offre la possibilité de mettre à l’échelle la capacité de stockage en douceur autant que nécessaire (la cible initiale est de 100 To) et de mettre à l’échelle les ressources de calcul rapidement.

Le diagramme suivant illustre les différents types de nœuds dans une base de données Hyperscale :

architecture

Apprenez-en davantage sur l’architecture des fonctions distribuées Hyperscale.

Avantages de scalabilité et de performances

Avec la possibilité d’ajouter ou de supprimer rapidement des nœuds de calcul en lecture seule, l’architecture Hyperscale apporte des fonctionnalités d’échelle horizontale en lecture significatives et peut aussi libérer le nœud de calcul principal pour qu’il traite davantage de demandes d’écriture. Par ailleurs, les nœuds de calcul peuvent être mis à l’échelle (augmentation ou diminution) rapidement grâce à la fonctionnalité de stockage partagé propre à l’architecture Hyperscale.

Créer et gérer des bases de données Hyperscale

Vous pouvez créer et gérer des bases de données Hyperscale à l’aide du portail Azure, de Transact-SQL, de PowerShell et d’Azure CLI. Consultez Démarrage rapide : Créer une base de données Hyperscale.

opération Détails En savoir plus
Créer une base de données Hyperscale Les bases de données Hyperscale sont uniquement disponibles avec le modèle d'achat vCore. Trouvez des exemples qui montrent comment créer une base de données Hyperscale dans le Guide de démarrage rapide : Créer une base de données Hyperscale dans Azure SQL Database.
Mettre à niveau une base de données existante vers le mode Hyperscale La migration d'une base de données Azure SQL Database existante vers le niveau Hyperscale est une opération de taille de données. Découvrez comment Migrer une base de données existante vers Hyperscale.
Inverser la migration d’une base de données Hyperscale vers le niveau de service Usage général (préversion) Si vous avez précédemment migré un Azure SQL Database existant vers le niveau de service Hyperscale, vous pouvez inverser la migration d’une base de données 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 modifiez le niveau de service.
Découvrez comment inverser la migration à partir d’Hyperscale, y compris les limitations de la migration inversée.

Haute disponibilité de la base de données dans Hyperscale

Comme pour tous les autres niveaux de service, Hyperscale garantit la durabilité des données pour les transactions validées, quelle que soit la disponibilité des réplicas de calcul. L’étendue des temps d’arrêt dus au fait que le réplica principal devient indisponible dépend du type de basculement (planifié ou non planifié) que la redondance de zone soit configurée ou non, et de la présence d’au moins un réplica à haute disponibilité. Dans un basculement planifié (par exemple un événement de maintenance), le système crée le réplica principal avant de lancer un basculement ou utilise un réplica à haute disponibilité existant comme cible de basculement. Dans un basculement non planifié (par exemple une défaillance matérielle sur le réplica principal), le système utilise un réplica à haute disponibilité (s’il en existe un) comme cible de basculement ou crée un réplica principal à partir du pool de capacité de calcul disponible. Dans ce dernier cas, la durée d’inactivité est plus longue en raison des étapes supplémentaires nécessaires pour créer le réplica principal.

Pour plus d’informations sur les contrats SLA Hyperscale, consultez SLA pour Azure SQL Database.

Sauvegarde et restauration

Les opérations de sauvegarde et de restauration pour les bases de données Hyperscale sont basées sur des instantanés de fichiers. Cela permet à ces opérations d’être quasiment instantanées. Étant donné que l’architecture Hyperscale utilise la couche de stockage pour la sauvegarde et la restauration, la charge de traitement et l’impact sur les performances des réplicas de calcul sont considérablement réduits. Plus d’informations sur Sauvegardes Hyperscale et redondance du stockage.

Récupération d’urgence pour les bases de données Hyperscale

Si vous avec besoin de restaurer une base de données Hyperscale dans Azure SQL Database dans une région autre que celle dans laquelle elle est actuellement hébergée, à des fins de récupération d’urgence, d’exploration, de relocalisation ou pour tout autre motif, la méthode principale consiste à opérer une géo-restauration de la base de données. La géorestauration n’est disponible que lorsque le stockage géo-redondant (RA-GRS) est choisi pour la redondance du stockage.

Pour en savoir plus, consultez Restauration d’une base de données Hyperscale dans une autre région.

Limitations connues

Voici les limitations actuelles du niveau de service Hyperscale. Nous travaillons activement à la suppression d’un maximum de ces limitations.

Problème Description
Rétention des sauvegardes à court terme La rétention des sauvegardes à court terme, de 1 à 35 jours, pour les bases de données Hyperscale est actuellement en préversion. Une base de données non Hyperscale ne peut pas être restaurée en tant que base de données Hyperscale, et une base de données Hyperscale ne peut pas être restaurée en tant que base de données non Hyperscale.

Pour les bases de données migrées vers Hyperscale à partir d’autres niveaux de service d’Azure SQL Database, les sauvegardes avant migration sont conservées pendant toute la période de rétention des sauvegardes de la base de données source, y compris les stratégies de conservation à long terme. La restauration d’une sauvegarde avant la migration pendant la période de rétention de la base de données est prise en charge via la ligne de commande. Vous pouvez restaurer ces sauvegardes à n’importe quel niveau de service non Hyperscale.
Rétention des sauvegardes à long terme La rétention des sauvegardes à long terme n’est actuellement pas prise en charge. Hyperscale a une architecture de sauvegarde basée sur des instantanés, différente de celle des autres niveaux de service.
Le changement de niveau de service, de Hyperscale à Usage général, est pris en charge directement dans les scénarios limités La migration inversée à partir d’Hyperscale permet aux clients qui ont récemment migré une Azure SQL Database existante vers le niveau de service Hyperscale de revenir au niveau Usage général si Hyperscale ne répond pas à leurs besoins. Bien que la migration inversée soit lancée par un changement de niveau de service, il s’agit essentiellement d’un déplacement de taille de données entre différentes architectures. Les bases de données créées dans le niveau de service Hyperscale ne sont pas éligibles à la migration inversée. Découvrez les limitations de la migration inversée.

Pour les bases de données pour lesquelles la migration inversée n’est pas possible, la seule façon de migrer une base de données d’Hyperscale vers un niveau de service non-Hyperscale consiste à exporter/importer à l’aide d’un fichier bacpac ou d’autres technologies de déplacement de données (copie en bloc, Azure Data Factory, Azure Databricks, SSIS, etc.) L’exportation et l’importation bacpac à partir du portail Azure, à partir de PowerShell à l’aide des cmdlets New-AzSqlDatabaseExport ou New-AzSqlDatabaseImport, à partir d’Azure CLI à l’aide des commandes az sql db export et az sql db import, et d’une API REST, ne sont pas prises en charge. L’exportation et l’importation bacpac pour des bases de données Hyperscale de plus petite taille (jusqu’à 200 Go) est prise en charge à l’aide de SSMS et de SqlPackage versions 18.4 et ultérieures. Pour des bases de données plus volumineuses, l’exportation et l’importation bacpac peuvent prendre beaucoup de temps et échouer pour différentes raisons.
Pools élastiques Les pools élastiques ne sont actuellement pas pris en charge avec Hyperscale.
Migration de bases de données avec des objets OLTP en mémoire Hyperscale prend en charge une partie des objets OLTP en mémoire, notamment les types de tables à mémoire optimisée, les variables de table et les modules compilés en mode natif. Toutefois, lorsqu’un des objets OLTP en mémoire est présent dans la base de données en cours de migration, la migration des niveaux de service Premium et Critique pour l’entreprise vers Hyperscale n’est pas prise en charge. Pour migrer une telle base de données vers Hyperscale, tous les objets OLTP en mémoire et leurs dépendances doivent être supprimés. Une fois la base de données migrée, ces objets peuvent être recréés. Les tables à mémoire optimisée durables et non durables ne sont actuellement pas prises en charge dans Hyperscale et doivent être changées en tables de disques.
Réduire la base de données DBCC SHRINKDATABASE, DBCC SHRINKFILE ou le paramètre AUTO_SHRINK défini sur ON au niveau de la base de données, ne sont actuellement pas pris en charge pour les bases de données Hyperscale.
Vérification de l’intégrité de la base de données DBCC CHECKDB n’est pas pris en charge actuellement pour les bases de données Hyperscale. DBCC CHECKTABLE ('TableName') WITH TABLOCK et DBCC CHECKFILEGROUP WITH TABLOCK peuvent être utilisés comme solution de contournement. Pour plus d’informations sur la gestion de l’intégrité des données dans Azure SQL Database, consultez Intégrité des données dans Azure SQL Database.
Travaux élastiques L’utilisation d’une base de données Hyperscale comme base de données de travail n’est pas prise en charge. Toutefois, les travaux élastiques peuvent cibler des bases de données Hyperscale comme n’importe quelle autre base de données dans Azure SQL Database.
Synchronisation des données L’utilisation d’une base de données Hyperscale en tant que base de données de hub ou de métadonnées de synchronisation n’est pas prise en charge. Toutefois, une base de données Hyperscale peut être une base de données membre dans une topologie de synchronisation des données.

Étapes suivantes

Pour en savoir plus sur le mode Hyperscale dans Azure SQL Database, consultez les articles suivants :