Configurer un réplica en attente sans licence (aperçu) pour la base de données Azure SQL

  • Article

S’applique à Azure SQL Database

Cet article décrit comment vous pouvez réduire les coûts de licence en désignant votre base de données secondaire de récupération d'urgence (DR) comme base de données en attente lors de l'utilisation de la base de données Azure SQL.

Remarque

Les réplicas de base de données Azure SQL en attente sont actuellement en aperçu.

Vue d’ensemble

Lorsqu'un réplica de base de données secondaire n'est utilisé qu'à des fins de récupération d'urgence et qu'aucune charge de travail ou application ne s'y connecte, vous pouvez réduire les coûts de licence en désignant la base de données comme un réplica en attente. Lorsqu'une base de données secondaire est désignée comme secours, Microsoft vous fournit le nombre de vCores acquis sous licence pour la base de données primaire sans frais supplémentaires dans le cadre de l'avantage des droits de basculement prévu dans les termes du contrat de licence du produit. Vous êtes toujours facturé pour le calcul et le stockage utilisés par la base de données secondaire.

Vous pouvez désigner un réplica en attente lorsque vous configurez une nouvelle réplication géoréplication active, ou convertir un réplica existant pour rester en attente.

Alors que la géoréplication active permet d'ajouter quatre réplicas secondaires, vous ne pouvez désigner qu'un seul réplica de base de données secondaire comme réplica en attente. Les groupes de basculement prennent en charge un réplica de base de données secondaire par base de données primaire, qui peut être soit accessible en lecture, soit en attente.

Lors d'un basculement planifié ou non, le réplica en attente devient le nouveau réplica primaire et commence à assumer les coûts de licence vCore habituels, tandis que le réplica primaire d'origine devient le nouveau réplica secondaire en attente et cesse d'assumer les coûts de licence vCore.

Pour en savoir plus, regardez cette vidéo de Data Exposed :

Coût-avantages

Lorsque vous désignez un réplica de base de données comme étant en attente, Microsoft ne vous facture pas les frais de licence SQL Server pour les vCores utilisés par le réplica en attente. Toutefois, la base de données étant facturée pour l'heure entière, des coûts de licence peuvent toujours vous être facturés pour l'heure entière si le changement d'état est effectué au milieu de l'heure.

L’avantage diffère selon que les clients utilisent le modèle de paiement à l’utilisation ou le modèle Azure Hybrid Benefit. Pour un client avec paiement à l’utilisation, la remise relative aux vCores apparaît sur sa facture. Pour un client qui utilise Azure Hybrid Benefit pour le réplica en attente, le nombre de vCores que le réplica secondaire utilise est retourné à son pool de licences.

Par exemple, en tant que client avec paiement à l'utilisation, si vous disposez de 16 vCores attribués à la base de données secondaire, une remise de 16 vCores apparaît sur votre facture si vous désignez votre base de données secondaire comme étant uniquement en attente.

Dans un autre exemple, si vous disposez de 16 licences Azure Hybrid Benefit et que vous déployez une base de données avec 16 vCores, après avoir désigné la base de données secondaire comme étant en attente, 16 vCores sont renvoyés dans votre pool de licences pour que vous puissiez les utiliser avec d'autres déploiements Azure SQL.

Fonctionnalités opérationnelles

La table suivante décrit les capacités fonctionnelles d'un réplica de base de données secondaire en attente :

Fonctionnalités Description
Charges de travail en lecture limitées Après avoir désigné votre base de données comme étant en attente, vous ne pouvez exécuter qu'un nombre limité de charges de travail en lecture sur la base de données secondaire. Ces charges de travail peuvent inclure les vues de gestion dynamiques (DMV), les sauvegardes et les requêtes DBCC (Database Console Commands).
Basculement planifié Tous les scénarios de basculement planifiés, y compris les exercices de récupération, le déplacement de bases de données vers différentes régions et le retour de bases de données vers l'instance principale, sont pris en charge par le réplica en attente. Quand l’instance secondaire bascule vers l’instance principale, elle peut servir des requêtes de lecture et d’écriture. Le nouveau réplica secondaire (initialement réplica principal) devient le réplica en attente et ne doit pas être utilisé pour les charges de travail en lecture.
Basculement non planifié Pendant un basculement non planifié, après que l’instance secondaire a basculé vers le rôle principal, elle peut servir des requêtes de lecture et d’écriture. Une fois l'interruption atténuée et le réplica principal d'origine reconnecté, celui-ci devient le nouveau réplica en attente secondaire et ne doit pas être utilisé pour les charges de travail en lecture.
Sauvegarde et restauration Le comportement de sauvegarde et de restauration d'un réplica en attente et d'un réplica de base de données secondaire accessible en lecture est le même.
Surveillance Toutes les opérations de supervision prises en charge par un réplica secondaire accessible en lecture sont prises en charge par le réplica en attente.

Le réplica de base de données en attente ne doit être utilisé que pour la récupération d'urgence. Aucune application de production ne peut être connectée au réplica. Trouvez ci-dessous les seules activités autorisées sur la base de données en attente :

  • Effectuer des opérations de maintenance, telles que checkDB
  • Connecter des applications de supervision
  • Effectuer des essais de reprise d’activité

Limites

La table suivante répertorie les modèles de déploiement pris en charge et ceux qui ne le sont pas :

Modèle de déploiement Niveau de calcul Niveau de service Réplica en attente pris en charge Matériel
Base de données unique approvisionné Usage général Oui Sérien Standard (Gen5), série FSv2, série DC
Base de données unique approvisionné Critique pour l’entreprise Oui Série Standard (Gen5), série DC
Base de données unique approvisionné Hyperscale N/A N/A
Base de données unique Sans serveur Tous Non N/A
Pool élastique Tous Tout Non N/A

L'utilisation d'une base de données en attente présente les limites suivantes :

  • Un seul réplica de base de données secondaire peut être désigné comme réplica en attente.
  • Le niveau de capacité de calcul sans serveur n'est pas pris en charge. Le réplica en attente ne peut pas être activé si la base de données primaire ou secondaire se trouve dans le niveau de calcul sans serveur.
  • Le modèle d'achat DTU n'est pas pris en charge. Vous pouvez activer un réplica en attente pour les bases de données utilisant uniquement le modèle d'achat vCore.
  • Le niveau de service Hyperscale n'est pas pris en charge. Seules les bases de données des niveaux de service à usage général et critiques pour l'entreprise peuvent être désignées comme étant en attente.
  • Lors de l'utilisation d'un groupe de basculement, les droits de mise en attente sont attribués au niveau de la base de données, et non au niveau du groupe de basculement. Ces droits doivent également être attribués séparément pour chaque base de données au sein du groupe de basculement.
  • La désignation d'un réplica secondaire comme réplica en attente n'est pas prise en charge lorsque le réplica est un réplica secondaire d'un réplica secondaire (processus connu sous le nom de chaînage).

Prérequis

  • Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.
  • Une base de données Azure SQL vCore primaire approvisionnée dans le niveau de service à usage général ou critique pour l'entreprise est exécutée sur du matériel pris en charge. Pour bien démarrer, reportez-vous au Démarrage rapide.

Configurer un nouveau réplica en attente

Vous pouvez désigner un réplica en attente lorsque vous configurez une nouvelle relation de géoréplication active en utilisant le portail Azure, Azure CLI ou l’API REST.

Pour créer une nouvelle relation de géoréplication active et désigner votre base de données secondaire comme base de données en attente dans le portail Azure, procédez comme suit :

  1. Accédez à votre ressource SQL Database dans le portail Azure.

  2. Choisissez Réplicas sous Gestion des données dans le menu de ressources, puis sélectionnez + Créer un réplica pour ouvrir la page Créer une SQL Database – réplica de zone géographique.

    Capture d’écran de la page Réplicas pour la base de données SQL dans le portail Azure.

  3. À la page Créer une SQL Database – réplica de zone géographique, sélectionnez Réplica en attente pour le Type de réplica sous configuration du réplica. Cochez la case pour confirmer que vous utiliserez le réplica comme réplica en attente.

    Capture d’écran de la page Créer un géo-réplica avec un réplica en attente mis en évidence dans le portail Azure.

  4. Indiquez un serveur nouveau ou existant pour la nouvelle base de données en attente, puis utilisez Réviser + créer pour procéder à une validation finale des détails de votre base de données et de votre serveur.

  5. Utilisez Créer pour confirmer vos paramètres et créer votre réplica de base de données en attente.

Convertir un réplica existant

Vous pouvez utiliser le portail Azure ou la commande d’API REST Liens de réplication - Mettre à jour pour convertir un réplica existant d’un géo-réplica normal en réplica en attente, ou un réplica en attente en géo-réplica normal.

Pour convertir un réplica existant dans le Portail Azure, procédez comme suit :

  1. Accédez à votre ressource SQL Database dans le portail Azure.
  2. Sélectionnez Réplicas sous Gestion des données.
  3. Sélectionnez les points de suspension (...) pour le réplica, puis :
    1. Pour convertir un réplica standard en réplica en attente, choisissez Convertir en réplica en attente. Cochez la case en regard de Je confirme... dans la fenêtre contextuelle Convertir en réplica en attente, puis sélectionnez Oui pour enregistrer votre modification et convertir votre réplica.
    2. Pour convertir un réplica en attente en géo-réplica normal, choisissez Convertir en géo-réplica. Cochez la case en regard de Je confirme... dans la fenêtre contextuelle Convertir en géo-réplica, puis sélectionnez Oui pour enregistrer vos modifications et convertir votre réplica.

Pour convertir un réplica existant à l’aide de la commande d’API REST Liens de réplication - Mettre à jour, définissez linkType sur STANDBY pour un réplica en attente ou GEO pour convertir un réplica en attente existant en géo-réplica normal.

Afficher les droits de licence

Vous pouvez consulter les droits de licence d'une base de données existante en utilisant le portail Azure, PowerShell, Azure CLI ou l’API REST.

Pour vérifier les droits de licence d'une base de données existante en utilisant le portail Azure, procédez comme suit :

  1. Accédez à votre SQL Database dans le portail Azure.

  2. Sur la page de présentation, cochez la case Type de réplica sous Essentials. Une valeur de Standby indique que votre base de données est un réplica en attente et que vous ne payez pas de frais de licence SQL pour cette base de données :

    Capture d’écran de la page Vue d’ensemble pour la base de données dans le portail Azure, avec le type de réplica en évidence.

Supprimer le réplica en attente

Une fois qu'une base de données est désignée comme étant en attente, vous ne pouvez pas simplement supprimer la propriété de mise en attente. Pour supprimer un réplica en attente, vous devez arrêter la réplication pour mettre fin à la relation de géoréplication active. Une fois la réplication arrêtée, votre base de données devient autonome et vous commencerez à assumer des coûts de licence.

Vous pouvez arrêter la géoréplication en utilisant le portail Azure, PowerShell, Azure CLI et l’API REST.

Pour supprimer un réplica en attente en mettant fin à la géoréplication dans le portail Azure, procédez comme suit :

  1. Accédez à votre SQL Database dans le portail Azure.
  2. Sélectionnez Réplicas sous Gestion des données.
  3. Sélectionnez les ellipses (...) pour le Réplica en attente, puis sélectionnez Arrêter la réplication dans le menu contextuel. La réplication est alors interrompue, de sorte que votre base de données secondaire est désormais autonome et non plus désignée comme base de données en attente, ce qui entraîne des coûts de licence.

Forum aux questions (FAQ)

  • Quelles sont les implications en matière de tarification ?

    Les réplicas de base de données secondaire sont facturés pour les licences SQL, le calcul et le stockage des données et des sauvegardes. Lorsque vous désignez un réplica de base de données comme étant en attente, vous ne payez pas de frais de licence pour les vCores utilisés par le réplica secondaire, mais vous payez toujours les frais de calcul et de stockage.

  • Quelles sont les économies approximatives avec un réplica en attente ?

    Sans les coûts de licence, un réplica en attente permet d'économiser entre 35 et 40 % par rapport à un réplica secondaire normal entièrement accessible en lecture, bien que les réductions varient en fonction de la région. Pour obtenir un prix précis, utilisez la Calculette de tarification Azure et définissez la licence SQL sur Azure Hybrid Benefit.

  • Combien de vCores seront dépourvus de licence pour le réplica en attente ?

    Le même nombre de vCores que celui utilisé par la base de données primaire. Il est recommandé de configurer le réplica secondaire avec le même nombre de vCores que la base de données primaire afin d'optimiser les performances de la géoréplication.

  • Dois-je disposer d'une licence SQL Server avec Software Assuranceactive pour utiliser un réplica en attente ?

    Non. Le réplica en attente n'entraîne pas de coûts de licence, par conséquent, vous n'avez pas besoin d'une licence SQL Server active avec une Software Assurance active.

  • Comment puis-je utiliser le réplica en attente ?

    Les réplicas en attente sont uniquement destinés à la récupération d'urgence (DR) et ne peuvent pas contenir de charges de travail actives en lecture. Les seules charges de travail acceptables sont la surveillance, la maintenance comme l'exécution des DMV et CheckDB.

  • Puis-je changer mon réplica secondaire accessible en lecture existant en un réplca en attente afin de réduire les coûts ?

    Oui, dans le portail Azure, dans le volet Réplicas. Sélectionnez les points de suspension (...), puis l’option pour Convertir votre réplica.

  • Puis-je activer Azure Hybrid Benefit pour le réplica en attente ?

    La désignation d'un réplica comme réplica en attente remplace la remise d'Azure Hybrid Benefit, de sorte que vous ne pouvez pas modifier le modèle de licence pour le réplica en utilisant le portail Azure. Toutefois, si vous souhaitez que le réplica en attente utilise Azure Hybrid Benefit lors du basculement, vous pouvez utiliser la commande PowerShell Set-AzSqlDatabase ou la commande CLI Azure Mettre à jour az sql db pour mettre à jour le type de licence défini comme BasePrice (Azure Hybrid Benefit) à utiliser par le réplica en attente lorsqu'il devient primaire après le basculement.

  • Qu'advient-il du statut du réplica en attente pendant le basculement ?

    Lors d'un basculement planifié ou non, le réplica en attente devient le nouveau réplica primaire et assume les coûts de licence habituels, tandis que le réplica primaire d'origine devient le nouveau réplica secondaire en attente et cesse d'assumer les coûts de licence vCore. Toutefois, comme l'instance est facturée pour l'heure entière, il se peut que les coûts de licence pour le nouveau réplica secondaire vous soient facturés pour l'heure entière si le changement d'état se produit au milieu de l'heure. Si le réplica primaire d'origine (qui devient le réplica en attente après le basculement) utilisait Azure Hybrid Benefit, la remise des coûts de licence pour le réplica en attente remplace Azure Hybrid Benefit utilisé par la base de données.

  • Que se passe-t-il si j'effectue un scale-up du vCore primaire ou secondaire ?

    Lors du scale-up, la meilleure pratique consiste à mettre d'abord à l'échelle le vCore secondaire, puis le vCore primaire. Bien que le réplica secondaire ait un nombre plus élevé de vCores que le réplica primaire pendant la période de transition, les avantages du réplica en attente s'appliquent toujours. Essayez de réduire la période de transition autant que possible.

  • Que se passe-t-il si j'effectue un scale-down du vCore primaire ou secondaire ?

    Lors du scale-down, la meilleure pratique consiste à effectuer d'abord un scale-down, puis un scale-down du vCore primaire. Bien que le réplica secondaire ait un nombre plus élevé de vCores que le réplica primaire pendant la période de transition, les avantages du réplica en attente s'appliquent toujours. Essayez de réduire la période de transition autant que possible.

  • Que se passe-t-il si je supprime la relation de géoréplication entre les réplicas primaire et en attente ?

    Une fois la géoréplication supprimée, la base de données en attente devient une base de données autonome normale et commence à assumer les coûts de licence.

  • Puis-je bénéficier des avantages de capacité de réserve pour le réplica en attente ?

    Oui. La tarification de la capacité de réserve est entièrement compatible avec le réplica en attente.

Contenu connexe