Partager via

Modèle d’achat vCore - Azure SQL Managed Instance

  • Article

S’applique à :Azure SQL Managed Instance

Cet article passe en revue le modèle d’achat vCore pour Azure SQL Managed Instance.

Vue d’ensemble

Un vCore représente une UC logique et offre la possibilité de choisir entre plusieurs caractéristiques physiques de matériel (par exemple, le nombre de cœurs, la mémoire et la taille de stockage). Le modèle d’achat vCore apporte flexibilité, contrôle et transparence pour la consommation des ressources individuelles. C’est aussi un moyen facile de traduire les exigences des charges de travail locales pour le cloud. Ce modèle optimise le prix et permet de sélectionner les ressources de calcul, de mémoire et de stockage en fonction des besoins de votre charge de travail.

Dans le modèle d’achat vCore, vos coûts dépendent du choix et de l’utilisation de ce qui suit :

  • Niveau de service
  • Configuration matérielle
  • Ressources de calcul (le nombre de vCores et la quantité de mémoire)
  • Stockage de base de données réservé
  • Stockage de sauvegarde réel

Le modèle d’achat vCore utilisé par Azure SQL Managed Instance offre les avantages suivants :

  • contrôle de la configuration du matériel pour mieux répondre aux besoins de calcul et de mémoire de la charge de travail ;
  • remises sur le tarif d’Azure Hybrid Benefit (AHB) et de l’Instance réservée (RI) ;
  • Une plus grande transparence des informations sur le matériel de calcul, ce qui facilite la planification des migrations à partir de déploiements locaux.
  • Une plus grande précision de la mise à l’échelle avec plusieurs tailles de calcul disponibles.

Compute

Le calcul SQL Managed Instance fournit une quantité spécifique de ressources de calcul provisionnées en continu, indépendamment de l’activité de la charge de travail, la quantité de ressources provisionnées étant facturée à un tarif horaire fixe.

Dans la mesure où trois réplicas supplémentaires sont automatiquement alloués dans le niveau de service Critique pour l’entreprise, le prix est environ 2,7 fois plus élevé que dans le niveau de service Usage général. Pour la même raison, le prix plus élevé du stockage par Go dans le niveau de service Critique pour l’entreprise reflète les limites d’E/S plus élevées et la latence plus faible du stockage SSD local.

Pour les instances dans le niveau de service Usage général, vous pouvez réaliser des économies sur les coûts de calcul et de licence en arrêtant votre instance quand vous ne l’utilisez pas. Consultez Arrêter et démarrer une instance pour en savoir plus.

Stockage des données et des journaux

Les facteurs suivants affectent la quantité de stockage utilisée pour les fichiers de données et les fichiers journaux, et s'appliquent aux niveaux Usage général et Critique pour l'entreprise.

  • Au niveau de service Usage général, tempdb utilise un disque SSD local et le coût de ce stockage est inclus dans le prix du modèle vCore.
  • Au niveau de service Critique pour l'entreprise, tempdb partage le disque SSD local avec les données et les fichiers journaux, et le coût du stockage tempdb est inclus dans le prix du modèle vCore.
  • La taille de stockage maximale d'une instance de SQL Managed Instance doit être spécifiée en multiples de 32 Go.

Important

Pour les deux niveaux de service, vous êtes facturé en fonction de la taille de stockage maximale configurée pour une instance managée.

Pour surveiller la taille totale de stockage d'instance consommée pour SQL Managed Instance, utilisez la métriquestorage_space_used_mb. Pour surveiller la taille de stockage actuellement allouée et utilisée par les données individuelles et les fichiers journaux dans une base de données à l'aide de T-SQL, utilisez la vue sys.database_files et la fonction FILEPROPERTY(... , 'SpaceUsed').

Stockage de sauvegarde

Le stockage des sauvegardes de base de données est alloué pour prendre en charge les fonctionnalités de SQL Managed Instance. Ce stockage, distinct du stockage des données et des fichiers journaux, est facturé séparément.

  • Récupération jusqu’à une date et heure (PITR) : la consommation de stockage dépend du taux de modification de la base de données et de la période de conservation configurée pour les sauvegardes. Vous pouvez configurer une période de rétention distincte pour chaque base de données : de 1 à 35 pour SQL Managed Instance. Une quantité de stockage de sauvegarde égale à la taille maximale des données configurées est fournie sans frais supplémentaires.
  • Conservation à long terme (LTR) : vous pouvez configurer la conservation à long terme des sauvegardes complètes pendant 10 ans maximum. La configuration que vous choisissez détermine la quantité de stockage utilisée pour les sauvegardes de conservation à long terme.

Niveaux de service

Le niveau de service définit généralement l’architecture de stockage, les limites d’espace et d’E/S et les options de continuité d’activité liées à la disponibilité et à la récupération d’urgence.

Azure SQL Managed Instance a deux niveaux de service :

Pour une comparaison détaillée entre les niveaux de service, consultez Limites des ressources, mais utilisez le tableau suivant pour obtenir une brève vue d’ensemble :

Catégorie Usage général Usage général nouvelle génération Critique pour l’entreprise
Idéal pour La plupart des charges de travail d’entreprise. Propose des options de calcul et de stockage équilibrées, évolutives et économiques. Charges de travail métier orientées budget qui ont besoin d’une plus grande capacité, d’un débit amélioré et d’une flexibilité des ressources. Offre aux applications métier la résilience la plus élevée aux défaillances en utilisant plusieurs réplicas isolés et assure les meilleures performances d’E/S.
Nombre maximal de vCore 80 128 128
Taille de stockage maximale des instances 16 To 32 To 16 To
Nombre maximal de bases de données par instance 100 500 100
Réplicas en lecture seule 0 0 1
Réplicas pour la disponibilité Nœuds de secours pour la haute disponibilité Nœuds de secours pour la haute disponibilité Trois réplicas haute disponibilité, 1 est également un réplica avec échelle lecture
Tarification/facturation vCore, stockage réservé et stockage de sauvegarde sont facturés.
Les IOPS ne sont pas facturées.		 VCore, stockage réservé, stockage de sauvegarde et IOPS (au-delà du quota gratuit) sont facturés. vCore, stockage réservé et stockage de sauvegarde sont facturés.
Les IOPS ne sont pas facturées.

Remarque

Pour plus d’informations sur le contrat de niveau de service (SLA), consultez SLA pour Azure SQL Managed Instance.

Usage général

Le modèle architectural du niveau de service Usage général est basé sur la séparation du calcul et du stockage. Ce modèle architectural s’appuie sur la haute disponibilité et la fiabilité du Stockage Blob Azure qui réplique les fichiers de base de données de façon transparente et qui garantit l’absence de perte de données en cas de panne de l’infrastructure sous-jacente.

L’illustration suivante montre quatre nœuds dans un modèle architectural Standard avec les couches de calcul et de stockage séparées.

Diagramme montrant la séparation du calcul et du stockage.

Le modèle architectural correspondant au niveau de service Usage général présente deux couches :

  • Couche de calcul sans état qui exécute le processus sqlservr.exe et ne contient que des données transitoires et données en cache (par exemple : cache du plan, pool de tampons, pool de columnstore). Ce nœud sans état est géré par Azure Service Fabric qui initialise le processus, contrôle l’intégrité du nœud et effectue le basculement vers un autre emplacement si nécessaire.
  • Une couche de données avec état comprenant les fichiers de base de données (.mdf/.ldf) stockés dans le service Stockage Blob Azure. Le service Stockage Blob Azure garantit qu'aucun enregistrement placé dans un fichier de base de données ne subira de perte de données. Stockage Azure est doté de fonctionnalités intégrées de redondance et de disponibilité des données qui garantissent la préservation des enregistrements d’un fichier journal ou des pages d’un fichier de données, même en cas de plantage du processus.

Dès que le moteur de base de données ou le système d’exploitation est mis à niveau, qu’une partie de l’infrastructure sous-jacente est défaillante ou qu’un problème critique est détecté dans le processus sqlservr.exe, Azure Service Fabric déplace le processus sans état vers un autre nœud de calcul sans état. Afin de réduire le temps de basculement, un ensemble de nœuds de réserve se tient prêt à exécuter le nouveau service de calcul en cas de basculement du nœud principal. Les données dans la couche Stockage Azure ne sont pas affectées, et les fichiers de données/journaux sont attachés à des processus nouvellement initialisés. Ce processus garantit une disponibilité de 99,99 % par défaut. Il pourrait affecter les performances des lourdes charges de travail en cours d’exécution, et ce en raison des délais de transition et du fait que le nouveau nœud démarre avec un cache à froid.

Quand choisir ce niveau de service ?

Le niveau de service Usage général est le niveau de service par défaut dans Azure SQL Managed Instance. Il convient à la plupart des charges de travail génériques. Si vous avez besoin d’un moteur de base de données entièrement managé avec un contrat SLA par défaut et une latence de stockage située entre 5 et 10 ms, le niveau Usage général est l’option qu’il vous faut.

Usage général nouvelle génération

Remarque

La mise à niveau vers le niveau de service Usage général nouvelle génération est actuellement en aperçu. Pour commencer, utilisez la mise à niveau du niveau de service Usage général nouvelle génération pour les instances nouvelles et existantes éligibles.

Le niveau de service Usage général nouvelle génération est une mise à niveau architecturale du niveau de service Usage général existant qui offre les caractéristiques clés suivantes :

  • Conçu pour les entreprises ayant des exigences de performances plus élevées tout en offrant le même coût de base que le niveau de service Usage général
  • Mises à niveau significatives vers les performances, l’extensibilité et la flexibilité des ressources par rapport au niveau de service Usage général
  • Utilise des disques managés au lieu d’objets blob de pages, améliorant considérablement les métriques de performances de stockage
  • 3 IOPS gratuites pour chaque Go de stockage réservé
  • Prise en charge d’un maximum de 500 bases de données par instance et d’une capacité de stockage maximale de 32 To

Étant donné que le niveau de service Usage général nouvelle génération est une mise à niveau du niveau de service Usage général existant, quel que soit le niveau de service que votre instance utilise, votre relevé de facturation reflète le niveau de service Usage général.

Modèle architectural

Le niveau de service Usage général nouvelle génération est une mise à niveau du niveau de service Usage général existant qui utilise une couche de stockage à distance mise à niveau pour stocker les données d’instance et les fichiers journaux sur les disques managés au lieu des objets blob de pages. Cela signifie que la mise à niveau du niveau de service Usage général nouvelle génération offre une latence de stockage, des IOPS et un débit plus rapides que le niveau de service Usage général existant, avec des limites accrues pour le stockage, le nombre de vCores et le nombre maximal de bases de données. En outre, étant donné que les quotas de performances sont partagés par l’instance entière, vous n’avez plus besoin de redimensionner des fichiers individuels pour améliorer leurs performances. Le coût de référence du niveau de service Usage général nouvelle génération est identique au niveau de service Usage général, mais vous pouvez utiliser des curseurs pour augmenter vos performances d’E/S, qui sont ensuite facturées séparément.

Le niveau de service Usage général nouvelle génération permet de réduire les coûts en offrant des IOPS gratuites au taux de trois IOPS pour chaque Go de stockage réservé. Le prix du stockage inclut les IOPS minimales. Si vous dépassez le minimum, vous êtes facturé comme suit : 1 IOPS = prix de stockage (par région) divisé par trois.

Par exemple :

  • Si 1 Go de stockage coûte 0,115, 1 IOPS = 0,115/3 = 0,038 par IOPS.
  • Une instance de 1 024 Go reçoit gratuitement 3 072 IOPS. Vous pouvez choisir d’augmenter vos IOPS jusqu’à la limite de la machine virtuelle moyennant un coût supplémentaire.

Quand choisir ce niveau de service ?

Choisissez ce niveau de service si votre entreprise est orientée budget, mais que les métriques de performances et les limites du niveau de service Usage général sont insuffisantes.

Les principales raisons pour lesquelles vous devez choisir le niveau de service Usage général nouvelle génération au lieu du niveau Usage général sont les suivantes :

  • Meilleures performances pour le même coût de base de référence
  • Latence, débit et IOPS améliorés
  • Capacité de stockage accrue
  • Flexibilité accrue pour votre capacité de calcul
  • Vous avez besoin de plus de 100 bases de données pour une instance unique
  • Vous avez besoin de plus de 16 To de stockage réservé

Critique pour l’entreprise

Le modèle de niveau de service Critique pour l’entreprise est basé sur un cluster de processus de moteur de base de données. Ce modèle architectural repose sur un quorum de nœuds de moteur de base de données toujours disponibles pour minimiser l’impact sur les performances de votre charge de travail, même pendant les activités de maintenance. Azure met à niveau et corrige le système d’exploitation, les pilotes et le moteur de base de données SQL Server sous-jacents de manière transparente avec un temps d’arrêt minimal pour les utilisateurs finaux.

Dans le modèle critique pour l’entreprise, le calcul et le stockage sont intégrés sur chaque nœud. La réplication des données entre les processus du moteur de base de données sur chaque nœud d’un cluster à quatre nœuds permet d’atteindre un haut niveau de disponibilité, chaque nœud utilisant un disque SSD attaché localement comme stockage de données.

Diagramme montrant le cluster de nœuds du moteur de base de données.

Le processus du moteur de base de données SQL Server et les fichiers .mdf/.ldf sous-jacents sont placés sur le même nœud, et le stockage SSD attaché localement permet à votre charge de travail de bénéficier d’une faible latence. La haute disponibilité est implémentée à l'aide d'une technologie similaire aux groupes de disponibilité AlwaysOn de SQL Server.

Chaque instance est un cluster de nœuds de moteur de base de données qui contiennent des copies de toutes les bases de données sur une instance, avec une base de données primaire accessible pour les charges de travail des clients et trois bases de données secondaires contenant des copies des données, prêtes pour le basculement. Le nœud principal pousse constamment les changements vers les nœuds secondaires afin de garantir la disponibilité des données sur les réplicas secondaires en cas de défaillance du nœud principal.

Le basculement est géré par le moteur de base de données SQL Server : un réplica secondaire devient le nœud principal, et un réplica secondaire est créé pour garantir un nombre suffisant de nœuds dans le cluster. La charge de travail est automatiquement redirigée vers le nouveau nœud principal.

Par ailleurs, le cluster Critique pour l’entreprise intègre la fonctionnalité Échelle lecture qui fournit un réplica en lecture seule gratuit. Ce dernier permet d’exécuter des requêtes en lecture seule (comme des rapports) qui n’affectent pas les performances de la charge de travail sur votre réplica principal.

Quand choisir ce niveau de service ?

Le niveau de service Critique pour l’entreprise est conçu pour les applications qui exigent des réponses à faible latence du stockage SSD sous-jacent (de 1 à 2 ms en moyenne), une récupération plus rapide en cas de défaillance de l’infrastructure sous-jacente, ou qui ont besoin de décharger des rapports, des données analytiques et des requêtes en lecture seule sur le réplica secondaire accessible en lecture gratuit de la base de données primaire.

Les principales raisons pour lesquelles vous devez choisir le niveau de service Critique pour l’entreprise plutôt que le niveau Usage général sont les suivantes :

  • Exigences de faible latence pour les E/S : les charges de travail nécessitant une réponse rapide de la couche de stockage (une à deux millisecondes en moyenne) doivent utiliser le niveau Critique pour l’entreprise.
  • Charge de travail avec requêtes de rapport et requêtes analytiques qui peuvent être redirigées vers le réplica secondaire disponible en lecture seule gratuit.
  • Plus grande résilience et récupération plus rapide après les défaillances. En cas de défaillance du système, les bases de données de l’instance principale sont mises hors connexion et l’un des réplicas secondaires devient immédiatement la nouvelle instance primaire en lecture-écriture, prête à traiter les requêtes. Le moteur de base de données n’a pas besoin d’analyser et de restaurer par progression les transactions du fichier journal, ni de charger des données dans des mémoires tampons.
  • Protection avancée contre l’altération des données. Étant donné que le niveau Critique pour l’entreprise utilise des réplicas de bases de données en arrière-plan, il tire parti de la réparation de page automatique disponible avec la mise en miroir et les groupes de disponibilité pour atténuer l’altération des données. Si un réplica ne peut pas lire une page en raison d’un problème d’intégrité des données, une nouvelle copie de la page est récupérée à partir d’un autre réplica, remplaçant la page illisible sans perte de données ni temps d’arrêt du client. Cette fonctionnalité est disponible dans le niveau Usage général si l’instance managée a un réplica géosecondaire.
  • Disponibilité supérieure - Le niveau Critique pour l’entreprise dans une configuration à plusieurs zones de disponibilité offre une résilience aux défaillances zonales et un SLA avec une disponibilité plus élevée.
  • Géorécupération rapide - Si un groupe de basculement est configuré, le niveau Critique pour l’entreprise a un objectif de point de récupération (RPO) garanti de 5 secondes et un objectif de délai de récupération (RTO) de 30 secondes pour 100 % des heures déployées.

Lorsque vous spécifiez le niveau de service dans les modèles ou les scripts, le niveau est fourni en utilisant son nom. Le tableau suivant s’applique :

Matériel Nom
Usage général GeneralPurpose
Critique pour l’entreprise BusinessCritical

Configurations matérielles

Les options de configuration de matériel du modèle vCore incluent la série Standard (Gen5), la série Premium et la série Premium à mémoire optimisée. La configuration matérielle définit généralement les limites de calcul et de mémoire, ainsi que d’autres caractéristiques qui ont un impact sur les performances de la charge de travail.

Pour plus d’informations sur les spécificités et les limitations des configurations matérielles, consultez Caractéristiques des configurations matérielles.

Dans la vue de gestion dynamique sys.dm_user_db_resource_governance, la génération de matériel pour les instances utilisant des processeurs Intel® SP-8160 (Skylake) apparaît comme Gen6, tandis que la génération de matériel pour les instances utilisant des processeurs Intel® 8272CL (Cascade Lake) apparaît comme Gen7. Les processeurs Intel® 8370C (Ice Lake) utilisés par les générations de matériel des séries Premium et Premium à mémoire optimisée apparaissent sous le nom de Gen8. Les limites de ressources pour toutes les instances de la série Standard (Gen5) sont identiques, quel que soit le type de processeur (Broadwell, Skylake ou Cascade Lake).

Sélectionner une configuration matérielle

Vous pouvez sélectionner la configuration matérielle au moment de la création de l’instance, ou modifier le matériel d’une instance existante.

Pour sélectionner une configuration matérielle lors de la création d’une instance SQL Managed Instance

Pour plus d’informations, consultez Créer une instance SQL Managed Instance.

Sous l’onglet Informations de base, sélectionnez le lien Configurer la base de données dans la section Calcul + Stockage, puis sélectionnez le matériel souhaité :

Capture d’écran du Portail Azure montrant où configurer SQL Managed Instance.

Pour changer le matériel d’une instance SQL Managed Instance existante

Sur la page SQL Managed Instance, sélectionnez Calcul + Stockage sous Paramètres :

Capture d’écran du Portail Azure montrant la page Calcul + stockage pour l’instance managée SQL.

Sur la page Calcul + Stockage, vous pouvez modifier votre matériel sous Génération matérielle à l’aide des curseurs pour vCores et Stockage.

Lorsque vous spécifiez un paramètre matériel dans des modèles ou des scripts, le matériel est fourni à l’aide de son nom. Le tableau suivant s’applique :

Matériel Nom
Série Standard (Gen5) Gen5
Série Premium G8IM
Série Premium à mémoire optimisée G8IH

Noms SKU

Remarque

Lorsque vous spécifiez le matériel et le niveau de service dans des modèles ou des scripts, vous pouvez les spécifier indépendamment ou fournir un nom SKU. Lorsque vous spécifiez le nom SKU, le tableau suivant s’applique :

Référence (SKU) Niveau de service Matériel
GP_Gen5 Usage général Séries Standard
GP_G8IM Usage général Série Premium
GP_G8IH Usage général Mémoire optimisée pour la série Premium
BC_Gen5 Critique pour l’entreprise Séries Standard
BC_G8IM Critique pour l’entreprise Série Premium
BC_G8IH Critique pour l’entreprise Mémoire optimisée pour la série Premium

Disponibilité matérielle

Série Standard (Gen5) et série Premium

Le matériel de la série Standard (Gen5) et de la série Premium est disponible dans toutes les régions publiques du monde.

Le matériel des séries Premium à mémoire optimisée est en préversion, et sa disponibilité régionale est limitée. Pour plus d’informations, consultez Limites de ressources Azure SQL Managed Instance.

Contenu connexe