Haute disponibilité pour Azure SQL Database

  • Article

S’applique à Azure SQL Database

Cet article décrit l’architecture de haute disponibilité dans Azure SQL Database.

Vue d’ensemble

L’objectif de l’architecture haute disponibilité dans Azure SQL Database est de réduire l’impact des opérations de maintenance et des interruptions de service sur les charges de travail des clients. Pour plus d’informations sur les contrats SLA spécifiques des différents niveaux de service, consultez Contrat de niveau de service (SLA) pour Azure SQL Database.

SQL Database s’exécute sur la dernière version stable du moteur de base de données SQL Server sur le système d’exploitation Windows avec tous les patchs applicables. SQL Database gère automatiquement les tâches de maintenance critiques, comme les mises à jour correctives, les sauvegardes, les mises à niveau de Windows et du moteur SQL, ainsi que les événements non planifiés, comme les défaillances sous-jacentes de type matériel, logiciel ou réseau. Quand une base de données ou un pool élastique dans SQL Database est corrigé ou bascule, le temps d’arrêt n’a aucun impact si vous utilisez une logique de nouvelle tentative dans votre application. Pour assurer la disponibilité de vos données, SQL Database bénéficie de fonctionnalités de récupération rapide, même dans les situations les plus critiques. La plupart des utilisateurs ne remarquent pas que les mises à niveau sont effectuées en continu.

La solution de haute disponibilité est conçue pour garantir que les données validées ne sont jamais perdues pour cause d’échecs, que les opérations de maintenance n’affectent pas votre charge de travail, et que la base de données ne constitue pas un point de défaillance unique dans votre architecture logicielle.

Trois modèles d’architecture à haute disponibilité sont disponibles :

  • Modèle de stockage étendu basé sur la séparation du calcul et du stockage. Il s’appuie sur la haute disponibilité et la fiabilité du niveau de stockage à distance. Cette architecture cible des applications métier économiques, capables de tolérer une baisse de performances pendant les activités de maintenance.
  • Modèle de stockage local basé sur un cluster de processus de moteur de base de données. Il repose sur le fait qu’il existe toujours un quorum de nœuds de moteur de base de données disponible. Cette architecture s’adresse à des applications stratégiques ayant des performances d’E/S supérieures et un taux de transactions élevé. Elle garantit un impact minimal sur les performances de votre charge de travail pendant les activités de maintenance.
  • Modèle Hyperscale qui utilise un système distribué de composants hautement disponibles comme les nœuds de calcul, les serveurs de pages, le service de journaux et le stockage persistant. Chaque composant prenant en charge une base de données Hyperscale fournit sa redondance et sa résilience propres en cas de défaillances. Les nœuds de calcul, les serveurs de page et le service de journal s’exécutent sur Azure Service Fabric, qui contrôle l’intégrité de chaque composant et effectue les basculements vers des nœuds sains disponibles quand cela est nécessaire. Le stockage persistant utilise Stockage Azure avec ses fonctionnalités natives de haute disponibilité et de redondance. Pour plus d’informations, consultez Architecture Hyperscale.

Dans chacun des trois modèles de disponibilité, SQL Database prend en charge les options de redondance locale et de redondance interzone. La redondance locale assure la résilience au sein d’un centre de données, tandis que la redondance zonale améliore davantage la résilience en protégeant contre les pannes d’une zone de disponibilité au sein d’une région.

Le tableau suivant présente les options de disponibilité en fonction des niveaux de service :

Niveau de service Modèle haute disponibilité disponibilité localement redondante Disponibilité redondante interzone
Usage général (vCore) Stockage étendu Oui Oui
Critique pour l’entreprise (vCore) Stockage local Oui Oui
Hyperscale (vCore) Hyperscale Oui Oui
De base (DTU) Stockage étendu Oui Non
Standard (DTU) Stockage étendu Oui Non
Premium (DTU) Stockage local Oui Oui

Disponibilité localement redondante

La disponibilité redondante localement est basée sur le stockage de votre base de données et des données sur un stockage localement redondant (LRS) qui copie vos données trois fois dans un centre de données unique de la région primaire et protège vos données en cas de défaillance locale, comme une panne de l'alimentation ou du réseau à petite échelle. Le stockage redondant localement est la solution de redondance la moins coûteuse, mais offrant la durabilité la plus faible par rapport aux autres options. Si un sinistre de grande ampleur, comme un incendie ou une inondation, se produit dans une région, toutes les réplicas d'un compte de stockage utilisant LRS peuvent être perdues ou irrécupérables. Par conséquent, envisagez une option de stockage plus résiliente pour vos sauvegardes de base de données afin de mieux protéger vos données si vous utilisez l'option de disponibilité localement redondante. Cela ne s’applique pas aux bases de données Hyperscale qui utilisent le même stockage pour les fichiers de données et les sauvegardes.

La disponibilité localement redondante est accessible à toutes les bases de données dans tous les niveaux de service, tandis que l’objectif de point de récupération (RPO) indiquant la quantité de perte de données est égal à zéro.

Niveaux de service De base, Standard et Usage général

Les niveaux de service De base, Standard et Usage général utilisent le modèle de disponibilité de stockage étendu pour le calcul provisionné et serverless. L’illustration suivante montre quatre nœuds distincts, avec les couches de calcul et de stockage séparées.

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

Le modèle de disponibilité du stockage étendu comprend deux couches :

  • Une couche de calcul sans état, qui exécute le processus du moteur de base de données et contient uniquement des données transitoires et mises en cache comme les bases de données tempdb et model sur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Ce nœud sans état est géré par Azure Service Fabric qui initialise le moteur de base de données, contrôle l'intégrité du nœud et effectue le basculement vers un autre nœud si nécessaire.
  • Une couche de données avec état, comprenant les fichiers de base de données (.mdf et .ldf) stockés dans le service Stockage Blob Azure. Les fonctionnalités de disponibilité et de redondance des données sont intégrées au Stockage Blob Azure. Celle-ci garantit la conservation de chaque enregistrement du fichier journal ou de chaque page du fichier de données, même si le moteur de base de données se bloque.

En cas de mise à niveau du moteur de base de données ou du système d’exploitation, ou si une défaillance est détectée, Azure Service Fabric déplace le moteur de base de données sans état vers un autre nœud de calcul sans état disposant d’une capacité disponible suffisante. Les données conservées dans le Stockage Blob Azure ne sont pas affectées par le déplacement. Les fichiers de données et de journaux sont joints au moteur de base de données qui vient d’être initialisé. Ce processus garantit une haute disponibilité. Toutefois, une charge de travail importante peut subir une détérioration des performances pendant la transition, car le nouveau processus de moteur de base de données démarre avec un cache froid.

Niveaux de service Premium et Critique pour l’entreprise

Les niveaux de service Premium et Critique pour l’entreprise utilisent le modèle de disponibilité de stockage local, qui intègre des ressources de calcul (processus de moteur de base de données) et du stockage (SSD attaché localement) sur un nœud unique. La haute disponibilité est obtenue en répliquant le calcul et le stockage sur des nœuds supplémentaires.

Diagramme d’un cluster de nœuds de moteur de base de données.

Les fichiers de base de données sous-jacents (.mdf/.ldf) sont placés sur le stockage SSD attaché, afin de fournir une latence des E/S très faible à votre charge de travail. La haute disponibilité est implémentée au moyen d'une technologie semblable à celles des groupes de disponibilité AlwaysOn de SQL Server. Le cluster comprend un seul réplica principal qui est accessible pour les charges de travail en lecture-écriture des clients, et un maximum de trois réplicas secondaires (de calcul et de stockage) contenant les copies des données. Le réplica principal envoie constamment des modifications aux réplicas secondaires dans l’ordre et garantit que les données sont conservées sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ce processus garantit qu’en cas de blocage du réplica principal ou d’un réplica secondaire accessible en lecture pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible en vue du basculement. Le basculement est initié par Azure Service Fabric. Quand un réplica secondaire devient le nouveau réplica principal, un autre réplica secondaire est créé afin de s’assurer que le cluster dispose d’un nombre suffisant de réplicas pour maintenir le quorum. Une fois le basculement terminé, les connexions Azure SQL sont redirigées automatiquement vers le nouveau réplica principal ou vers le réplica secondaire accessible en lecture.

Le modèle de disponibilité de stockage local offre un avantage supplémentaire : il permet de rediriger les connexions Azure SQL en lecture seule vers l’un des réplicas secondaires. Cette fonctionnalité est appelée Scale-out en lecture. Elle fournit 100 % de capacité de calcul, sans frais supplémentaires, pour décharger depuis le réplica principal des opérations en lecture seule, telles que les charges de travail analytiques.

Niveau de service Hyperscale

L’architecture du niveau de service Hyperscale est décrite dans Architecture des fonctions distribuées.

Diagramme montrant l’architecture fonctionnelle Hyperscale.

Le modèle de disponibilité dans Hyperscale comprend quatre couches :

  • Une couche de calcul sans état, qui exécute les processus du moteur de base de données et contient uniquement des données transitoires et mises en cache, comme le cache RBPEX non couvrant, des bases de données tempdb et model, etc. sur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Cette couche sans état comprend le réplica de calcul principal et, éventuellement, un certain nombre de réplicas de calcul secondaires qui peuvent servir de cibles de basculement.
  • Une couche de stockage sans état formée de serveurs de pages. Cette couche est le moteur de stockage distribué des processus de moteur de base de données s’exécutant sur les réplicas de calcul. Chaque serveur de pages contient uniquement des données temporaires et mises en cache, comme le cache RBPEX couvrant sur le disque SSD attaché ainsi que les pages de données mise en cache dans la mémoire. Chaque serveur de pages dispose d’un serveur de pages appairé dans une configuration active-active pour assurer l’équilibrage de charge, la redondance et la haute disponibilité.
  • Une couche de stockage du journal des transactions avec état formée du nœud de calcul exécutant le processus du service de journal, la zone d’atterrissage du journal des transactions et le stockage durable du journal des transactions. La zone d’atterrissage et le stockage durable utilisent Stockage Azure, qui assure la disponibilité et la redondance du journal des transactions, ce qui garantit la durabilité des données pour les transactions validées.
  • Une couche de stockage de données avec état avec les fichiers de base de données (.mdf/.ndf) qui sont stockés dans Stockage Azure et mis à jour par les serveurs de pages. Cette couche utilise les fonctionnalités de disponibilité et de redondance des données de Stockage Azure. Cela garantit que chaque page d’un fichier de données est conservée, même si les processus des autres couches de l’architecture Hyperscale se bloquent ou si des nœuds de calcul subissent une défaillance.

Dans toutes les couches Hyperscale, les nœuds de calcul s’exécutent sur Azure Service Fabric, qui contrôle la santé de chaque nœud et assure les basculements vers des nœuds sains disponibles quand cela est nécessaire.

Pour plus d’informations sur la haute disponibilité dans Hyperscale, consultez Haute disponibilité de la base de données dans Hyperscale .

Disponibilité redondante interzone

La disponibilité redondante interzone garantit que vos données sont réparties entre trois zones de disponibilité Azure dans la région primaire. Chaque zone de disponibilité est un emplacement physique distinct avec une alimentation, un refroidissement et une mise en réseau indépendants.

La disponibilité redondante interzone est disponible pour les bases de données dans les niveaux de service Premium, Critique pour l'entreprise, Usage général, et Hyperscale, et non pour les niveaux de service De base et Standard du modèle d’achat DTU. Chaque niveau de service implémente la disponibilité redondante interzone différemment. Consultez les détails de chaque niveau de service dans les sections suivantes. Toutes les implémentations garantissent un objectif de point de récupération (RPO) sans perte de données validées lors du basculement.

Niveau de service Usage général

La configuration redondante interzone pour le niveau de service Usage général est proposée à la fois pour le calcul serverless et le calcul provisionné des bases de données dans le modèle d’achat vCore. Cette configuration utilise des Zones de disponibilité Azure pour répliquer les bases de données sur plusieurs emplacements physiques au sein d’une région Azure. En sélectionnant la redondance interzone, vous pouvez rendre vos bases de données uniques serverless et provisionnées à usage général, et vos pools élastiques nouveaux et existants résilients à un plus grand éventail d’échecs, notamment les pannes graves de centre de données, sans aucune modification de la logique d’application.

La configuration redondante interzone pour le niveau Usage général contient deux couches :

  • Une couche de données avec état, comprenant les fichiers de base de données (.mdf/.ldf) stockés dans ZRS (stockage redondant interzone). Avec ZRS, les fichiers de données et les fichiers journaux sont copiés de façon synchrone sur trois zones de disponibilité Azure physiquement isolées.
  • Une couche de calcul sans état, qui exécute le processus sqlservr.exe et contient uniquement des données transitoires et mises en cache comme les bases de données tempdb et model sur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Ce nœud sans état est géré par Azure Service Fabric qui initialise sqlservr.exe, contrôle l’intégrité du nœud et effectue le basculement vers un autre nœud si nécessaire. Pour les bases de données redondantes interzones à usage général sans serveur et approvisionnées, les nœuds avec une capacité de rechange sont facilement disponibles dans d’autres zones de disponibilité pour le basculement.

La version redondante interzone de l’architecture de haute disponibilité pour le niveau de service à usage général est illustrée dans le diagramme suivant :

Diagramme d’une configuration redondante interzone pour le niveau Usage général.

Tenez compte des éléments suivants lors de la configuration de vos bases de données Usage général avec redondance interzone :

  • La configuration redondante interzone pour le niveau Usage général est à disponibilité générale dans les régions suivantes :
    • (Afrique) Afrique du Sud Nord
    • (Asie-Pacifique) Australie Est
    • (Asie-Pacifique) Asie Est
    • (Asie-Pacifique) Japon Est
    • (Asie-Pacifique) Corée Centre
    • (Asie-Pacifique) Asie Sud-Est
    • (Asie-Pacifique) Inde Centre
    • (Asie-Pacifique) Chine Nord 3
    • (Asie-Pacifique) Émirats arabes unis Nord
    • (Europe) France Centre
    • (Europe) Allemagne Centre-Ouest
    • (Europe) Italie Nord
    • (Europe) Europe Nord
    • (Europe) Norvège Est
    • (Europe) Pologne Centre
    • (Europe) Europe Ouest
    • (Europe) Royaume-Uni Sud
    • (Europe) Suisse Nord
    • (Europe) Suède Centre
    • (Moyen-Orient) Israël Central
    • (Moyen-Orient) Qatar Central
    • (Amérique du Nord) Canada Centre
    • (Amérique du Nord) USA Est
    • (Amérique du Nord) USA Est 2
    • (Amérique du Nord) USA Centre Sud
    • (Amérique du Nord) USA Ouest 2
    • (Amérique du Nord) USA Ouest 3
    • (Amérique du Sud) Brésil Sud
  • Pour la disponibilité redondante interzone, le choix d’une fenêtre de maintenance autre que la fenêtre par défaut est actuellement disponible dans certaines régions.
  • La configuration redondante interzone est uniquement disponible dans SQL Database quand du matériel de série Standard (Gen5) est sélectionné.
  • La redondance interzone n’est pas disponible pour les niveaux de service De base ni Standard dans le modèle d’achat DTU.

Niveaux de service Premium et Critique pour l’entreprise

Lorsque la redondance de zone est activée pour le niveau de service Premium ou Critique pour l’entreprise, les réplicas sont placés dans différentes zones de disponibilité dans la même région. Pour éliminer un point de défaillance unique, l’anneau de contrôle est également dupliqué sur plusieurs fuseaux horaires sous forme de trois anneaux de passerelle (GW). Le routage vers un anneau de passerelle spécifique est contrôlé par Azure Traffic Manager. Étant donné que la configuration redondante interzone dans les niveaux de service Premium ou Critique pour l’entreprise utilise ses réplicas existants pour les placer dans différentes zones de disponibilité, vous pouvez l’activer sans coûts supplémentaires. En sélectionnant une configuration redondante interzone, vous rendez vos pools élastiques et vos bases de données Premium ou Critique pour l’entreprise résistants à un plus grand éventail d’échecs, notamment les pannes graves de centre de données, sans aucune modification à la logique d’application. Vous pouvez également convertir vos pools élastiques ou vos bases de données Premium ou Critique pour l’entreprise en configuration redondant interzone.

La version redondante interzone de l’architecture de haute disponibilité est illustrée dans le diagramme suivant :

Diagramme de l’architecture de haute disponibilité redondante interzone.

Tenez compte des éléments suivants lors de la configuration de vos bases de données Premium ou Critique pour l’entreprise avec redondance interzone :

Niveau de service Hyperscale

Il est possible de configurer la redondance interzone pour les bases de données du niveau de service Hyperscale. Pour plus d’informations, consultez Créer une base de données Hyperscale redondante interzone.

L’activation de cette configuration garantit la résilience au niveau des zones via la réplication dans des zones de disponibilité pour toutes les couches Hyperscale. En sélectionnant la redondance de zone, vous pouvez rendre vos bases de données Hyperscale résilientes à un ensemble de défaillances beaucoup plus important, notamment les pannes graves du centre de données, sans aucune modification de la logique d’application. Toutes les régions Azure qui ont des Zones de disponibilité prennent charge la base de données Hyperscale redondante interzone.

La disponibilité redondante interzone est prise en charge dans les bases de données autonomes Hyperscale et les pools élastiques Hyperscale. Pour plus d’informations, consultez les pools élastiques Hyperscale.

Le diagramme suivant illustre l’architecture sous-jacente des bases de données Hyperscale redondantes :

Diagramme montrant l’architecture sous-jacente des bases de données Hyperscale redondantes interzone.

Tenez compte des limitations suivantes :

  • La configuration redondante interzone peut être spécifiée uniquement lors de la création de la base de données. Ce paramètre n’est pas modifiable après le provisionnement de la ressource. Utilisez la copie de base de données, la restauration à un instant dans le passé ou créez un géo-réplica pour mettre à jour la configuration redondante interzone pour une base de données Hyperscale existante. Quand vous utilisez l’une de ces options de mise à jour, si la base de données cible se trouve dans une autre région que la source ou si la redondance du stockage de la sauvegarde de la base de données de la cible diffère de celle de la base de données source, l’opération de copie est une opération à l’échelle des données.

  • Pour la disponibilité redondante interzone, le choix d’une fenêtre de maintenance autre que la fenêtre par défaut est actuellement disponible dans certaines régions.

  • Il n’existe actuellement aucune option permettant de spécifier la redondance de zone lors de la migration d’une base de données vers Hyperscale à l’aide du Portail Azure. En revanche, la redondance de zone ne peut pas être spécifiée avec Azure PowerShell, Azure CLI, ou l’API REST lors de la migration vers Hyperscale d’une base de données existante d’un autre niveau de service Azure SQL Database. Voici un exemple avec Azure CLI :

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true

  • Au moins un réplica de calcul haute disponibilité et l’utilisation d’un stockage de sauvegarde redondant interzone ou géo-redondant interzone sont nécessaires pour activer la configuration redondante interzone pour Hyperscale.

Disponibilité redondante interzone de la base de données

Dans Azure SQL Database, un serveur est une construction logique qui joue le rôle d’un point d’administration central pour une collection de bases de données. Au niveau du serveur, vous pouvez administrer des connexions, des méthodes d’authentification, des règles de pare-feu, des règles d’audit, des stratégies de détection des menaces et des groupes de basculement. Les données liées à certaines de ces fonctionnalités, telles que les ID de connexion et les règles de pare-feu, sont stockées dans la base de données master. Les données de certains DMV, par exemple sys.resource_stats, sont également stockées dans la base de données master.

Quand une base de données avec une configuration redondante interzone est créée sur un serveur logique, la base de données master associée au serveur devient automatiquement redondante interzone. Cela garantit qu’en cas de panne zonale, les applications utilisant la base de données restent inchangées, car les fonctionnalités dépendant de la base de données master, telles que les ID de connexion et les règles de pare-feu, sont toujours disponibles. Rendre la base de données master redondante interzone est un processus asynchrone qui prendra un certain temps à se terminer en arrière-plan.

Quand aucune des bases de données sur un serveur n’est redondante interzone, ou quand vous créez un serveur vide, la base de données master associée au serveur n’est pas redondante interzone.

Vous pouvez utiliser Azure PowerShell, Azure CLI ou l’API REST pour vérifier la propriété ZoneRedundant pour la base de données master :

Utilisez l’exemple de commande suivant pour vérifier la valeur de la propriété « ZoneRedundant » pour la base de données master.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Test de résilience aux erreurs de l’application

La haute disponibilité est un élément fondamental de la plateforme SQL Database qui fonctionne de manière transparente pour votre application de base de données. Cependant, nous sommes conscients que vous pourriez vouloir tester l'impact, sur une application, des opérations de basculement automatique lancées lors d'événements planifiés ou non planifiés avant de déployer l'application en production. Vous pouvez déclencher manuellement un basculement en appelant une API spéciale pour redémarrer une base de données ou un pool élastique. Dans le cas d’une base de données ou d’un pool élastique redondant interzone serverless et provisionnés, l’appel d’API entraînerait la redirection des connexions clientes vers le nouveau réplica principal dans une zone de disponibilité différente de l’ancien. Ainsi, en plus de tester l’impact du basculement sur les sessions de base de données existantes, vous pouvez aussi vérifier s’il a un impact sur les performances de bout en bout en raison des changements de latence réseau. Sachant que l’opération de redémarrage est intrusive et qu’un grand nombre de redémarrages pourrait peser sur la plateforme, un seul appel de basculement est autorisé toutes les 15 minutes pour chaque base de données ou pool élastique.

Pour plus d’informations sur la haute disponibilité et la récupération d’urgence d’Azure SQL Database, consultez la Liste de vérification de haute disponibilité et récupération d’urgence.

Un basculement peut être initié à l’aide de PowerShell, de l’API REST ou d’Azure CLI :

Type de déploiement PowerShell API REST Azure CLI
Base de données Invoke-AzSqlDatabaseFailover Basculement de base de données az rest peut être utilisé pour lancer un appel à l'API REST à partir de Azure CLI
Pool élastique Invoke-AzSqlElasticPoolFailover Basculement de pool élastique az rest peut être utilisé pour lancer un appel à l'API REST à partir de Azure CLI

Important

La commande de basculement n’est pas disponible pour les réplicas secondaires accessibles en lecture des bases de données Hyperscale.

Conclusion

Azure SQL Database offre une solution de haute disponibilité intégrée en profondeur à la plateforme Azure. Cette solution dépend de Service Fabric pour la détection et la récupération des défaillances, mais aussi du stockage Blob Azure pour la protection des données et des Zones de disponibilité pour une meilleure tolérance aux pannes. Par ailleurs, SQL Database utilise la technologie de groupe de disponibilité Always On de SQL Server pour la synchronisation de données et le basculement. La combinaison de ces technologies permet aux applications de bénéficier pleinement des avantages d’un modèle de stockage mixte et prend en charge les contrats de niveau de service les plus exigeants.

Contenu connexe