Haute disponibilité des services Azure SQL Database et SQL Managed Instance

S’APPLIQUE À : Azure SQL Database Azure SQL Managed Instance

L’objectif de l’architecture haute disponibilité dans Azure SQL Database et SQL Managed Instance est de garantir que votre base de données est opérationnelle au minimum 99,99 % du temps sans que vous deviez vous préoccuper de l’incidence des opérations de maintenance et des pannes. Pour plus d’informations sur les contrats de niveau de service propres à chaque niveau, consultez SLA pour Azure SQL Database et SLA pour Azure SQL Managed Instance.

Azure gère automatiquement les tâches de maintenance critiques, telles les mises à jour correctives, les sauvegardes, les mises à niveau de Windows et d’Azure SQL, ainsi que les événements non planifiés, comme les défaillances sous-jacentes de type matériel, logiciel ou réseau. Lorsque la base de données sous-jacente d'Azure SQL Database fait l'objet d'une mise à jour corrective ou d'un basculement, le temps d'arrêt n'est pas perceptible si vous utilisez une logique de nouvelle tentative dans votre application. Pour assurer la disponibilité de vos données, SQL Database et SQL Managed Instance bénéficient de fonctionnalités de récupération rapide, même dans les situations les plus critiques.

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 n’est pas un point de défaillance unique dans votre architecture logicielle. Rien, pas même une fenêtre de maintenance ou un temps d’arrêt, ne doit vous obliger à arrêter la charge de travail pendant la mise à niveau ou la maintenance de la base de données.

Deux modèles d'architecture à haute disponibilité sont disponibles :

  • Le modèle de disponibilité Standard est basé sur la séparation du calcul et du stockage. Il s’appuie sur la haute disponibilité et la fiabilité du niveau stockage à distance. Cette architecture cible des applications métier économiques, capables de tolérer une baisse de performances pendant les activités de maintenance.
  • Le modèle de disponibilité Premium est 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 concerne les 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.

Comme SQL Database et SQL Managed Instance s'exécutent tous les deux sur la dernière version stable du moteur de base de données SQL Server et du système d'exploitation Windows, la plupart des utilisateurs ne se rendent pas compte des mises à niveau qui sont effectuées en continu.

Disponibilité de redondance locale des niveaux de service De base, Standard et Usage général

Les niveaux de service De base, Standard et Usage général utilisent l’architecture de disponibilité standard 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.

Separation of compute and storage

Le modèle de disponibilité Standard comprend deux couches :

  • 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 TempDB, les bases de données 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.
  • 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. La fonctionnalité de disponibilité et redondance des données est intégrée au stockage d’objets 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 processus sqlservr.exe se bloque.

Dès que le moteur de base de données ou que le système d'exploitation est mis à niveau, ou qu'une défaillance est détectée, Azure Service Fabric déplace le processus sqlservr.exe 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, et les fichiers de données ou de journaux sont joints au processus sqlservr.exe nouvellement initialisé. Ce processus garantit une disponibilité de 99,99 %, mais une charge de travail lourde peut accuser une baisse de performances pendant la transition, car le nouveau processus sqlservr.exe démarre avec le cache à froid.

Disponibilité redondante interzone du niveau de service Usage général

La configuration redondante interzone pour le niveau de service Usage général est proposée pour le calcul provisionné et serverless. 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 comprend 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 TempDB, les bases de données 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 serverless et provisionné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 :

Zone redundant configuration for general purpose

Important

Pour le niveau usage général, la configuration redondante interzone est généralement disponible dans les régions suivantes : Europe Ouest, Europe Nord, USA Ouest 2 et France Centre. Ceci est en préversion dans les régions suivantes : USA Est, USA Est 2, Asie Sud-Est, Australie Est, Japon Est et Royaume-Uni Sud.

Notes

La configuration redondante interzone n’est pas disponible dans SQL Managed Instance. Dans SQL Database, cette fonctionnalité est disponible uniquement quand le matériel Gen5 est sélectionné.

Disponibilité redondante locale des niveaux de service Premium et Critique pour l’entreprise

Les niveaux de service Premium et Critique pour l’entreprise tirent parti du modèle de disponibilité Premium, qui intègre des ressources de calcul (processus sqlservr.exe) et du stockage (SSD attaché localement) sur un seul nœud. La haute disponibilité est obtenue en répliquant calcul et stockage sur des nœuds supplémentaires pour la création d’un cluster à trois ou quatre nœuds.

Cluster of database engine nodes

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 nœud principal envoie (push) constamment, et dans l’ordre, les modifications vers les nœuds secondaires, et s’assure que les données sont conservées sur au moins un réplica secondaire avant de valider chaque transaction. Ce processus garantit qu’en cas de plantage du nœud principal pour une quelconque raison, il existe toujours un nœud entièrement synchronisé vers lequel basculer. Le basculement est initié par Azure Service Fabric. Lorsque le réplica secondaire devient le nouveau nœud principal, un autre réplica secondaire est créé pour garantir que le cluster dispose de suffisamment de nœuds (ensemble du quorum). Une fois le basculement terminé, les connexions Azure SQL sont automatiquement redirigées vers le nouveau nœud principal.

Autre avantage, le modèle de disponibilité Premium permet de rediriger les connexions Azure SQL en lecture seule vers 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.

Disponibilité redondante interzone des niveaux de service Premium et Critique pour l’entreprise

Par défaut, le cluster de nœuds pour le modèle de disponibilité Premium est créé dans le même centre de données. Avec l’introduction des Zones de disponibilité Azure, SQL Database peut placer différents réplicas de la base de données Critique pour l’entreprise dans des zones de disponibilité distinctes au sein de 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 (ATM). Étant donné que la configuration redondante interzone dans les niveaux de service Premium ou Critique pour l’entreprise ne crée pas de redondance de base de données supplémentaire, vous pouvez l’activer sans frais supplémentaires. En sélectionnant une configuration redondante interzone, vous rendez vos bases de données Premium ou Critique pour l’entreprise résistantes à 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 bases de données ou pools Premium ou Critique pour l’entreprise en leur appliquant une configuration avec redondance interzone.

Étant donné que les bases de données de redondance interzone ont des réplicas dans différents centres de données distants les uns des autres, la latence accrue du réseau peut augmenter le temps de validation et ainsi avoir un impact sur les performances de certaines charges de travail OLTP. Vous pourrez toujours revenir à la configuration de zone unique en désactivant le paramètre de redondance interzone. Ce processus est une opération en ligne, semblable à la mise à niveau des niveaux de service ordinaires. À la fin du processus, la base de données ou le pool sont déplacés d’un anneau de redondance interzone vers un anneau de zone unique, ou vice versa.

Important

Cette fonctionnalité n'est pas disponible dans SQL Managed Instance. Dans SQL Database, quand vous utilisez le niveau Critique pour l’entreprise, la configuration redondante interzone est disponible uniquement quand le matériel Gen5 est sélectionné. Pour obtenir des informations à jour sur les régions qui prennent en charge les bases de données redondantes interzones, consultez Prise en charge des services par région.

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

high availability architecture zone redundant

Disponibilité redondante locale du niveau de service Hyperscale

L'architecture du niveau de service Hyperscale est décrite dans Architecture des fonctions distribuées et n'est actuellement disponible que pour SQL Database, et non pour SQL Managed Instance.

Hyperscale functional architecture

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

  • Une couche de calcul sans état, qui exécute les processus sqlservr.exe et contient uniquement des données transitoires et mises en cache, comme le cache RBPEX non couvrant, TempDB, une base de données 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 sqlservr.exe 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 du niveau de service Hyperscale (préversion)

La redondance de zone pour le niveau de service Hyperscale d’Azure SQL Database est désormais en préversion publique. 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.

Tenez compte des limitations suivantes :

  • Actuellement, seules les régions Azure suivantes sont prises en charge : Royaume-Uni Sud, Brésil Sud, USA Ouest 2, Japon Est, Europe Nord, Asie Sud-Est, Canada Centre, USA Centre, USA Centre Sud, France Centre, Australie Est, Allemagne Centre Ouest, Asie Est, Corée Centre, Norvège Est et USA Ouest 3.
  • La configuration redondante interzone peut être spécifiée uniquement lors de la création de la base de données. Ce paramètre ne peut pas être modifié 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. En outre, lors de l’utilisation de l’une de ces options de mise à jour, la base de données cible ne dispose pas des données de sauvegarde historiques de la base de données source pour la restauration à un instant dans le passé.
  • Les réplicas nommés ne sont pas pris en charge.
  • Seule la sauvegarde redondante interzone est prise en charge.
  • Seul le matériel Gen5 est pris en charge.
  • La géo-restauration n’est pas prise en charge actuellement.
  • La redondance de zone ne peut actuellement pas être spécifiée lors de la migration d’une base de données existante d’un autre niveau de service Azure SQL Database vers Hyperscale.

Important

Au moins un réplica de calcul haute disponibilité et l’utilisation du stockage de sauvegarde redondant interzone est nécessaire pour activer la configuration redondante interzone pour la fonctionnalité Hyperscale.

Créer une base de données Hyperscale redondante interzone

Utilisez Azure PowerShell ou l’interface Azure CLI pour créer une base de données Hyperscale redondante interzone. Vérifiez que vous disposez de la dernière version de l’API pour vous assurer que les modifications récentes sont prises en charge.

Spécifiez le paramètre -ZoneRedundant pour activer la redondance de zone pour votre base de données Hyperscale à l’aide d’Azure PowerShell. La base de données doit disposer d’au moins un réplica haute disponibilité et un stockage de sauvegarde redondant interzone doit être spécifié.

Pour activer la redondance de zone à l’aide d’Azure PowerShell, utilisez l’exemple de commande suivant :

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone

Créer une base de données Hyperscale redondante interzone en créant un géo-réplica

Pour rendre une base de données Hyperscale existante redondante interzone, utilisez Azure PowerShell ou l’interface Azure CLI afin de créer une base de données Hyperscale redondante interzone à l’aide de la géoréplication active. Le géo-réplica peut se trouver dans la même région ou dans une autre région que la base de données Hyperscale existante.

Spécifiez le paramètre -ZoneRedundant pour activer la redondance de zone pour votre base de données secondaire Hyperscale. La base de données secondaire doit disposer d’au moins un réplica haute disponibilité et un stockage de sauvegarde redondant interzone doit être spécifié.

Pour créer votre base de données redondante interzone à l’aide d’Azure PowerShell, utilisez l’exemple de commande suivant :

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

Créer une base de données Hyperscale redondante interzone en créant une copie de base de données

Pour rendre une base de données Hyperscale existante redondante interzone, utilisez Azure PowerShell ou l’interface Azure CLI afin de créer une base de données Hyperscale redondante interzone à l’aide de la copie de base de données. La copie de base de données peut se trouver dans la même région ou dans une autre région que la base de données Hyperscale existante.

Spécifiez le paramètre -ZoneRedundant pour activer la redondance de zone pour votre copie de base de données Hyperscale. La copie de la base de données doit disposer d’au moins un réplica haute disponibilité et un stockage de sauvegarde redondant interzone doit être spécifié.

Pour créer votre base de données redondante interzone à l’aide d’Azure PowerShell, utilisez l’exemple de commande suivant :

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone 

Récupération de base de données accélérée (ADR)

La récupération de base de données accélérée est une nouvelle fonctionnalité du moteur de base de données qui améliore considérablement la disponibilité des bases de données, particulièrement en présence de transactions durables. Actuellement, ADS est disponible pour Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics.

Test de résilience aux erreurs de l’application

La haute disponibilité est un élément fondamental de la plateforme SQL Database et SQL Managed Instance ; elle fonctionne de manière transparente pour votre application de base de données. Toutefois, nous avons conscience que vous souhaitez peut-être tester, avant le déploiement en production, la manière dont les opérations de basculement automatique initiées pendant les événements, planifiés ou non, impacteraient une application. Vous pouvez déclencher manuellement un basculement en appelant une API spéciale pour redémarrer une base de données, un pool élastique ou une instance gérée. 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, pool élastique ou instance gérée.

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 permettre d’invoquer un appel d’API REST à partir d’Azure CLI
Pool élastique Invoke-AzSqlElasticPoolFailover Basculement de pool élastique az rest peut permettre d’invoquer un appel d’API REST à partir d’Azure CLI
Instance gérée Invoke-AzSqlInstanceFailover Instances gérées - Basculement az sql mi failover peut être utilisé pour invoquer un appel d’API REST à partir de l’interface 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 et Azure SQL Managed Instance disposent d'une solution de haute disponibilité intégrée, qui est incorporé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 (comme mentionné plus haut dans ce document, cela n’est pas encore applicable à Azure SQL Managed Instance). Par ailleurs, SQL Database et SQL Managed Instance tirent parti de la technologie de groupe de disponibilité AlwaysOn de l’instance SQL Server pour la réplication et le basculement. La combinaison de ces technologies permet aux applications de profiter pleinement des avantages d’un modèle de stockage mixte, et de prendre en charge les contrats de niveau de service les plus exigeants.

Étapes suivantes