Partager via

Niveau de service Hyperscale

  • Article

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. Il existe trois choix de niveau de service dans le modèle d’achat vCore pour Azure SQL Database :

  • Usage général
  • Critique pour l’entreprise
  • Hyperscale

Le niveau de service Hyperscale convient à tous les types de charges de travail. Son architecture native Cloud fournit un calcul et un stockage indépendamment scalables pour prendre en charge la plus vaste gamme d’applications traditionnelles et modernes. Les ressources de calcul et de stockage dans Hyperscale dépassent largement les ressources disponibles dans les niveaux Usage général et Critique pour l’entreprise.

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 Comparer les modèles d’achat vCore et DTU d’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 :

  • 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.
  • 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, scale-down et facturation automatiques pour le calcul en fonction de l’utilisation avec le calcul serverless.
  • Prix/performances optimisés pour un groupe de bases de données Hyperscale présentant des besoins en ressources variables avec des pools élastiques.
  • Stockage de mise à l’échelle automatique avec prise en charge d’un maximum de 128 To de base de données ou de taille de pool élastique de 100 To.
  • 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.
  • Sauvegardes de base de données (basées sur des instantanés de fichiers), quelle que soit leur taille, sans impact des E/S sur les ressources de calcul.
  • Restaurations ou copies de base de données rapides (basées sur des instantanés de fichiers) en minutes plutôt qu’en heures ou en jours.

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é de stockage allouée. 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 quasi instantanément. Vous pouvez aussi effectuer en quelques minutes un scale-up ou un scale-down de plusieurs dizaines de téraoctets sur une base de données dans le niveau de calcul approvisionné, ou utiliser le mode serverless pour mettre automatiquement le calcul à l’échelle. 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).

Modèle tarifaire Hyperscale

Remarque

La tarification simplifiée pour la base de données Azure SQL Hyperscale est arrivée ! Passez en revue le nouveau niveau tarifaire pour l’annonce de la base de données d’Azure SQL Hyperscale et, pour plus d’informations sur les modifications tarifaires, consultez la Base de données Azure SQL Hyperscale – tarification plus basse et simplifiée !.

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 provisionné :

    Le prix unitaire du calcul Hyperscale est par réplica. Les utilisateurs peuvent ajuster le nombre total de réplicas secondaires à haute disponibilité de 0 à 4, en fonction des exigences de disponibilité et de scalabilité, et créer jusqu’à 30 réplicas nommés pour prendre en charge diverses charges de travail d’échelle horizontale en lecture.

  • Calcul serverless :

    La facturation de calcul serverless est basée sur l’utilisation. Pour plus d’informations, consultez Niveaux de calcul serverless pour Azure SQL Database.

  • 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 128 To est automatiquement alloué, qui croît par incréments de 10 Go en fonction des besoins.

Pour plus d’informations sur la tarification Hyperscale, consultez Tarification d’Azure SQL Database.

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 vous permet de mettre à l’échelle la capacité de stockage en fonction des besoins (jusqu’à 128 To) et de mettre à l’échelle rapidement les ressources de calcul.

Le diagramme suivant illustre l’architecture Hyperscale fonctionnelle :

Diagramme montrant l’architecture Hyperscale.

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. Les nœuds de calcul en lecture seule dans Hyperscale sont également disponibles dans le niveau de calcul serverless, qui met automatiquement à l’échelle le calcul en fonction de la demande des charges de travail.

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 de haute disponibilité existant comme cible de basculement. Dans un basculement non planifié (tel qu’une défaillance matérielle sur le réplica principal), le système utilise un réplica de 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.

Vous pouvez choisir une fenêtre de maintenance qui vous autorise à rendre les événements de maintenance importants prévisibles et moins perturbants pour votre charge de travail.

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

Pool de mémoires tampons, extension de pool de mémoires tampons résilientes et la préparation en continu

Dans Azure Database Hyperscale, il existe une séparation distincte entre le calcul et le stockage. Le stockage contient toutes les pages de base de données d’une base de données et peut être alloué sur plusieurs machines à mesure que la base de données augmente. Toutefois, le nœud de calcul met uniquement en cache ce qui est utilisé récemment. Les pages les plus chaudes du calcul sont conservées en mémoire dans une structure appelée pool de mémoires tampons (BP). Il est également stocké dans le SSD local, l’extension de pool de mémoires tampons résiliente (RBPEX), afin que les données puissent être récupérées plus rapidement au cas où le processus de calcul redémarre.

Dans un système cloud, le calcul peut se déplacer vers différentes machines en fonction des besoins. La couche de calcul peut avoir plusieurs réplicas. L’un est le principal et reçoit toutes les mises à jour, tandis que d’autres sont des réplicas secondaires. En cas d’échec principal, l’une des réplicas secondaires à haute disponibilité peut rapidement être promu en réplica principale dans un processus appelé basculement. La réplica secondaire peut ne pas avoir de cache dans sa base de données BP et RBPEX optimisée pour la charge de travail principale.

L’amorçage en continu est un processus qui collecte des informations sur les pages les plus chaudes dans tous les réplicas de calcul. Ces informations sont agrégées et les réplicas secondaires à haute disponibilité utilisent la liste des pages les plus chaudes qui correspondent à la charge de travail client classique. Cela remplit à la fois BP et RBPEX avec les pages les plus chaudes, en continu, pour suivre les modifications de la charge de travail du client.

Sans a continu, BP et RBPEX ne sont pas hérités par de nouveaux réplicas à haute disponibilité et ne sont reconstruits que pendant la charge de travail de l’utilisateur. L’amorçage continu permet de gagner du temps et d’éviter les performances incohérentes, car il n’y a pas d’attente avant que les caches ne soient entièrement hydratés. Avec l’amorçage continu, les nouveaux réplicas secondaires à haute disponibilité commenceront immédiatement à commencer la préparation de leur BP et RBPEX. Cela permet de maintenir les performances de manière plus cohérente à mesure que les basculements se produisent.

L’amorçage continu fonctionne de deux façons : les réplicas secondaires à haute disponibilité utilisent les pages utilisées dans le réplica principal, et le réplica principal met en cache les pages avec la charge de travail des réplicas secondaires.

Remarque

L’amorçage continu est actuellement en préversion contrôlée et n’est pas disponible pour les bases de données serverless. Pour plus d’informations et pour consentir à l’amorçage continu, consultez Blog : améliorations apportées à Hyperscale en novembre 2024.

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 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.

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. Ces différences entre ces versions sont décrites dans le tableau suivant :

ㅤ Usage général Critique pour l’entreprise Hyperscale
Idéal pour Offre des options de calcul et de stockage équilibrées et économiques. Applications OLTP avec des débits de transactions élevés et une faible latence des E/S. Offre une résilience élevée aux défaillances et des basculements rapides à l’aide de plusieurs réplicas de secours à chaud. Plus vaste gamme de charges de travail. Mise à l’échelle automatique de la taille de stockage jusqu’à 128 To, mise à l’échelle verticale et horizontale rapide du calcul, restauration rapide de la base de données.
Taille de calcul 2 à 128 vCores 2 à 128 vCores 2 à 128 vCores
Type de stockage Stockage distant Premium (par instance) Stockage SSD local ultra-rapide (par instance) Stockage découplé avec cache disque SSD local (par réplica de calcul)
Taille de stockage 1 Go - 4 To 1 Go - 4 To 10 Go – 128 To
D’OPÉRATIONS D’E/S PAR SECONDE 320 IOPS par vCore avec un maximum de 16 000 IOPS 4 000 IOPS par vCore avec 327 680 IOPS au maximum 327 680 IOPS avec disque SSD local (maximum)
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.
Mémoire/vCore 5,1 Go 5,1 Go 5,1 Go ou 10,2 Go
Disponibilité Un réplica, aucune échelle lecture, haute disponibilité redondante interzone Trois réplicas, une échelle lecture, haute disponibilité redondante interzone Plusieurs réplicas, jusqu’à quatre échelles lecture, haute disponibilité redondante interzone
Sauvegardes Choix entre stockage localement redondant (LRS), redondant interzone (ZRS) et géoredondant (GRS)
Conservation de 1 à 35 jours (sept jours par défaut), avec conservation à long terme de 10 ans maximum disponible		 Choix entre stockage localement redondant (LRS), redondant interzone (ZRS) et géoredondant (GRS)
Conservation de 1 à 35 jours (sept jours par défaut), avec conservation à long terme de 10 ans maximum disponible		 Choix entre stockage localement redondant (LRS), redondant interzone (ZRS) et géoredondant (GRS)
Conservation de 1 à 35 jours (sept jours par défaut), avec conservation à long terme de 10 ans maximum disponible
Tarification/facturation vCore, stockage réservé et stockage de sauvegarde sont facturés.
Les IOPS ne sont pas facturées.		 vCore, stockage réservé et stockage de sauvegarde sont facturés.
Les IOPS ne sont pas facturées.		 Les vCores pour chaque réplica, stockage de données alloué et stockage de sauvegarde sont facturés.
Les IOPS ne sont pas facturées.
Modèles de remise1 Instances réservées
Azure Hybrid Benefit2
Abonnements Entreprise et Dev/Test – Paiement à l’utilisation		 Instances réservées
Azure Hybrid Benefit2
Abonnements Entreprise et Dev/Test – Paiement à l’utilisation		 Instances réservées
Azure Hybrid Benefit2
Abonnements Entreprise et Dev/Test – Paiement à l’utilisation

1 La tarification réduite et simplifiée de SQL Database Hyperscale débute en décembre 2023. Pour en savoir plus, reportez-vous au blog de tarification Hyperscale.

2 À compter de décembre 2023, Azure Hybrid Benefit n’est pas disponible pour les nouvelles bases de données Hyperscale ou dans les abonnements de développement/test. Les bases de données uniques Hyperscale existantes avec un calcul approvisionné peuvent continuer à utiliser Azure Hybrid Benefit pour économiser sur les coûts de calcul jusqu’en décembre 2026. Pour plus d’informations, consultez le blog sur la tarification Hyperscale.

Ressources de calcul

Configuration matérielle UC Mémoire
Série Standard (Gen5) Calcul provisionné
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platine 8370C (Ice Lake)1, processeurs AMD EPYC 7763v (Milan)
- Approvisionnement dans la limite de 80 vCores (hyper-thread)

Calcul serverless
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platine 8370C (Ice Lake)1, processeurs AMD EPYC 7763v (Milan)
– Effectuer un scale-up automatique dans la limite de 80 vCores (hyper-thread)
– Le ratio mémoire/vCore s’adapte dynamiquement à l’utilisation de la mémoire et du processeur selon la demande des charges de travail et peut atteindre 24 Go par vCore. À un moment donné par exemple, une charge de travail pourrait utiliser être facturée pour 240 Go de mémoire et 10 vCores uniquement.		 Calcul provisionné
- 5,1 Go par vCore
– Provisionnement jusqu’à 625 Go

Calcul serverless
- Mise à l’échelle automatique dans la limite de 24 Go par vCore
- Mise à l’échelle automatique dans la limite de 240 Go
Série Premium - Processeurs Intel® Xeon® Platine 8370C (Ice Lake), AMD EPYC 7763v (Milan)
- Approvisionnement dans la limite de 128 vCores (hyper-thread)		 - 5,1 Go par vCore
Mémoire optimisée pour la série Premium - Processeurs Intel® Xeon® Platine 8370C (Ice Lake), AMD EPYC 7763v (Milan)
- Approvisionnement dans la limite de 80 vCores (hyper-thread)		 – 10,2 Go par vCore

1 Dans la vue de gestion dynamique sys.dm_user_db_resource_governance, la génération de matériel pour les bases de données utilisant des processeurs Intel® SP-8160 (Skylake) apparaît comme Gen6, la génération de matériel pour les bases de données utilisant Intel® 8272CL (Cascade Lake) apparaît comme Gen7, et la génération de matériel pour les bases de données utilisant Intel® Xeon® Platine 8370C (Ice Lake) ou AMD® EPYC® 7763v (Milan) apparaît comme Gen8. Pour une taille de calcul et une configuration matérielle données, les limites de ressources sont identiques quel que soit le type de processeur. Pour plus d’informations, consultez les limites de ressources pour les bases de données uniques et les pools élastiques.

Le mode serverless est pris en charge seulement sur le matériel de la série Standard (Gen5).

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. Pour plus d’informations, 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 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.

Réduire

Les opérations de réduction de base de données et de fichiers sont actuellement en préversion pour Azure SQL Database Hyperscale. Pour plus d’informations sur la préversion, consultez Réduction pour Azure SQL Database Hyperscale.

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
La réduction est bloquée lorsque TDE est désactivé Actuellement, les opérations de réduction de base de données et de fichiers ne sont pas prises en charge lorsque Transparent Data Encryption (TDE) est désactivé dans Azure SQL Database Hyperscale.
Restaurer la base de données à partir d’autres niveaux de service 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.
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.
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.
Matériel de la série Premium pour le niveau de service Hyperscale Le matériel de la série Premium et de la série Premium à mémoire optimisée ne prend pas actuellement en charge le niveau de calcul serverless.
Disponibilité régionale Le matériel des séries Premium et Premium à mémoire optimisée du niveau de service Hyperscale est disponible dans les régions Azure limitées. Pour obtenir une liste, consultez disponibilité de la série Premium Hyperscale.

Contenu connexe