Disponibilité via la redondance de zone locale et interzone - Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article décrit l’architecture d’Azure SQL Managed Instance qui assure la disponibilité par le biais de la redondance locale et de la haute disponibilité par le biais de la redondance de zone.

Vue d’ensemble

SQL Managed Instance 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 Managed Instance gère automatiquement les tâches de maintenance critiques, comme les mises à jour correctives, les sauvegardes, les mises à niveau de Windows et du moteur de base de données 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 instance est corrigée 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 Managed Instance 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.

Par défaut, Azure SQL Managed Instance obtient une disponibilité par le biais de la redondance locale, en vous assurant que votre instance gère les interruptions telles que :

• Opérations de gestion initiées par le client qui entraînent un bref temps d’arrêt
• Opérations de maintenance de service
• Problèmes et pannes du centre de données avec :
  • Rack où fonctionnent les machines qui font fonctionner votre service.
  • la machine physique qui héberge la machine virtuelle qui exécute le moteur de base de données SQL ; ou
  • la machine virtuelle qui exécute le moteur de base de données SQL.
• Autres problèmes liés au moteur de base de données SQL
• Autres pannes locales imprévues possibles

La solution de disponibilité par défaut est conçue pour s’assurer que les données validées ne sont jamais perdues en raison d’échecs, que les opérations de maintenance ont un impact minimal sur votre charge de travail et que l’instance n’est pas un point de défaillance unique dans votre architecture logicielle.

Toutefois, pour réduire l’impact sur vos données en cas de panne dans une zone entière, vous pouvez obtenir une haute disponibilité en activant la redondance de zone. Sans redondance de zone, les basculements se produisent localement au sein du même centre de données, ce qui peut entraîner l’indisponibilité de votre instance jusqu’à ce que la panne soit résolue. La seule façon de récupérer est via une solution de récupération d'urgence, telle qu’un groupe de basculement ou une géorestauration d’une sauvegarde géo-redondante. Pour plus d’informations, passez en revue la vue d'ensemble de la continuité d'activité.

La haute disponibilité augmente la fiabilité de votre service en vous protégeant de l’impact sur :

• Zone de disponibilité qui forme le centre de données

Il existe deux modèles architecturaux différents de disponibilité en fonction du niveau de service :

• Le modèle de stockage de dépôt distant se base sur une séparation du calcul et du stockage dans le niveau de service Usage général et Usage général nouvelle génération qui repose sur la disponibilité et la fiabilité du stockage de dépôt distant et sur la disponibilité des clusters de calcul managés par Azure Service Fabric. Ce modèle de disponibilité cible les applications de gestion des informations professionnelles à budget limité qui peuvent tolérer une certaine détérioration des performances pendant les activités de maintenance.
• Le modèle de stockage local est basé sur un cluster de processus de moteur de base de données qui repose sur un quorum de nœuds de moteur de base de données disponibles dans le niveau de service critique pour l'entreprise qui disposent d'un stockage local. Ce modèle de stockage local cible des applications stratégiques qui ont un taux de transaction élevé et nécessitent des performances d'E/S élevées. L'architecture de haute disponibilité garantit un impact minimal sur les performances de votre charge de travail pendant les activités de maintenance.

Pour plus d’informations sur les contrats SLA spécifiques des différents niveaux de service, consultez SLA pour Azure SQL Managed Instance.

la disponibilité par le biais de la redondance locale

La disponibilité localement redondante est basée sur le stockage de vos nœuds de calcul et les données 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. Si un sinistre de grande ampleur, comme un incendie ou une inondation, se produit dans une région, tous les réplicas d'un compte de stockage ou des données sur les nœuds de calcul peuvent être perdus 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.

Niveau de service à usage général

Le niveau de service Usage général utilise l’architecture de disponibilité du stockage distant. L’illustration suivante montre quatre nœuds distincts, avec les couches de calcul et de stockage séparées.

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. La disponibilité localement redondante est basée sur le stockage de vos 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. 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.

Niveau de service à usage général de nouvelle génération

La nouvelle génération de General Purpose est une mise à niveau architecturale du niveau de service General Purpose existant qui utilise une couche de stockage distante améliorée pour stocker les données d’instance et les fichiers journaux sur Elastic SAN au lieu de pages blobs.

La redondance de zone pour le niveau de service à usage général de nouvelle génération est actuellement en préversion. Le version préliminaire prend également en compte la mémoire flexible pour les instances redondantes en zone sur du matériel de série Premium.

Niveau de service Critique pour l’entreprise

Le niveau de service Critique pour l’entreprise utilise 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 disponibilité est obtenue en répliquant à la fois le calcul et le stockage vers des nœuds supplémentaires.

Les fichiers de base de données sous-jacents (.mdf/.ldf) sont placés sur un stockage SSD attaché pour fournir une E/S à très faible latence pour votre charge de travail. La disponibilité est implémentée à l’aide d’une technologie similaire aux groupes de disponibilité Always On 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. La réplique principale transmet en permanence les modifications aux répliques secondaires, successivement, afin de s’assurer que les données sont enregistrées de manière persistante sur un nombre suffisant de répliques secondaires avant de valider chaque transaction. Ce processus garantit que, si le réplica principal ou un réplica secondaire lisible devient indisponible pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible vers lequel basculer. Le basculement est initié par Azure Service Fabric. Lorsqu’un réplica secondaire devient le nouveau réplica principal, un autre réplica secondaire est créé de façon à garantir 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 automatiquement redirigées vers le nouveau réplica principal (ou vers le réplica secondaire accessible en lecture en fonction de la chaîne de connexion).

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.

la haute disponibilité via la redondance de zone

La disponibilité redondante interzone est basée sur le placement de réplicas dans 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.

Par défaut, le cluster de nœuds pour le modèle de disponibilité de stockage local est créé dans le même centre de données. Avec l’introduction de Azure Zones de disponibilité, SQL Managed Instance répartit différentes répliques 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 zones. Le trafic du plan de contrôle est ensuite acheminé vers un équilibreur de charge également déployé dans les zones de disponibilité. Le routage du trafic du plan de contrôle vers l’équilibreur de charge est contrôlé par Azure Traffic Manager (ATM).

En utilisant une configuration redondante en zone, vous pouvez rendre vos instances Business Critical, General Purpose ou Next Gen General Purpose résilientes à un ensemble beaucoup plus large de pannes, y compris des interruptions catastrophiques de centres de données, sans aucun changement dans la logique applicative. Vous pouvez convertir les instances existantes en configuration de zone redondante. La redondance de zone pour le niveau de service Usage général nouvelle génération est actuellement en préversion.

Parce que les instances redondantes par zone ont des répliques dans différents centres de données avec une certaine distance entre elles, la latence réseau accrue peut augmenter le temps d’engagement des transactions, et ainsi affecter 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 qui ressemble à la mise à niveau de l’objectif des niveaux de service ordinaire. À la fin du processus, l’instance migre d’un anneau redondant interzone vers un anneau de zone unique, ou inversement.

Pour commencer à utiliser la redondance de zone pour votre SQL managed instance, passez en revue Configurer la redondance de zone. Passez en revue la disponibilité de la redondance de zone par région pour Azure SQL Managed Instance.

Niveau de service à usage général

Dans le niveau de service Usage général, la redondance de zone est obtenue en plaçant des nœuds de calcul sans état dans différentes zones de disponibilité, et repose ensuite sur un stockage avec état redondant interzone (ZRS) rattaché au nœud qui héberge actuellement le processus actif du moteur SQL Moteur de base de données. En cas de panne, le processus du moteur de base de données SQL devient actif sur l’un des nœuds sans état, puis accède aux données du stockage avec état.

Le diagramme suivant illustre l’architecture de redondance de zone pour le niveau de service Usage général :

Niveau de service à usage général de nouvelle génération

La redondance de zone pour le niveau de service à usage général de nouvelle génération est actuellement en préversion. Une configuration redondante de zone répartit les composants de service entre les zones de disponibilité et utilise la couche de stockage distante Elastic SAN améliorée. L’aperçu prend en compte la mémoire flexible sur le matériel de la série Premium, ce qui permet d’ajuster la mémoire indépendamment du nombre de vCores.

Niveau de service Critique pour l’entreprise

Dans le niveau de service Critique pour l'entreprise, la redondance de zone est obtenue en plaçant des réplicas de calcul et de stockage dans différentes zones de disponibilité, puis en utilisant la technologie de groupe de disponibilité Always On sous-jacente pour répliquer les modifications des données de l’instance principale vers les réplicas de secours dans d’autres zones de disponibilité. En cas de panne, un basculement automatique se produit et fait passer de manière transparente l’un des réplicas de secours au rôle principal.

Le diagramme suivant illustre l’architecture de redondance de zone pour le niveau de service Critique pour l'entreprise :

Test de résilience aux erreurs de l’application

La disponibilité est un élément fondamental de la plateforme SQL Managed Instance qui fonctionne de manière transparente pour votre application de base de données. Cependant, nous reconnaissons que vous pourriez vouloir tester comment les opérations de basculement automatique initiées lors d’événements planifiés ou imprévus affecteraient une application avant de la déployer en production. Vous pouvez déclencher manuellement un basculement en appelant une API spéciale pour redémarrer une instance managée. 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 instance gérée.

Lors d’un vrai basculement, les connexions à l’instance échouent alors que le service SQL devient principal sur un autre nœud. Pour simuler un basculement, appelez la commande qui redémarre le processus SQL pour simuler le démarrage du service comme s’il y avait un basculement. Toutefois, les connexions peuvent échouer pendant une période plus longue pendant un basculement réel par rapport à un basculement simulé, car pendant un véritable basculement, le processus SQL devient le principal sur une autre machine virtuelle au sein du cluster (localement ou dans une autre zone si la redondance de zone est activée) et pendant un basculement simulé, le processus SQL est redémarré sur la machine virtuelle existante.

La commande de basculement manuel introduite dans cette section fonctionne généralement de la même manière dans les configurations à redondance locale et à redondance de zone. En règle générale, la commande redémarre uniquement le processus SQL localement et ne lance pas de basculement vers un autre nœud, bien que quelques exceptions s’appliquent. Ce basculement local diffère d’un basculement qui survient dans le cadre d’un groupe de basculement. Toutefois, il n’existe aucune contrainte qui garantit que le nouveau processus démarre sur le même nœud et qu’il peut démarrer sur un autre nœud dans le même, ou dans une zone de disponibilité différente. Un basculement local peut être initié à l’aide de PowerShell, de l’API REST ou d’Azure CLI :

Tests de connectivité interne automatiques

Pour garantir la disponibilité de votre service, Azure SQL Managed Instance exécute des tests de connectivité internes automatiques pour surveiller la fiabilité du service et accélérer la détection des problèmes. Ces tests s’exécutent toutes les 10 secondes à partir d’adresses IP internes au sein du sous-réseau de l’instance managée SQL et ont un impact négligeable sur le débit réseau et les performances du service. Un test valide la connectivité de bout en bout en tentant une connexion avec des informations d’identification connues pour échouer (AzureSQLConnectivityChecker), ce qui génère des entrées de connexion ayant échoué attendues dans les journaux d’audit, les événements étendus et les journaux d’erreurs SQL. Ces entrées sont normales et n’indiquent pas de problème de sécurité. Pour plus d’informations, notamment sur la façon d’identifier les signatures de test dans vos journaux d’activité, consultez Tests de connectivité interne automatiques.

Conclusion

Azure SQL Managed Instance offre une solution de haute disponibilité intégrée en profondeur à la plateforme Azure. Le service dépend de Service Fabric pour détecter les défaillances et les rétablir, du stockage Blob Azure pour protéger les données et des zones de disponibilité pour une plus grande tolérance de panne. Et pour le niveau de service Business Critical, SQL Managed Instance utilise la technologie des groupes de disponibilité Always On de SQL Server pour la réplication de bases 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

• Tests de connectivité interne automatiques - Azure SQL Managed Instance
• Configurer la redondance de zone - Azure SQL Managed Instance
• Zones de disponibilité Azure
• Service Fabric
• Azure Traffic Manager
• Redémarrer une instance avec un basculement manuel initié par l’utilisateur - Azure SQL Managed Instance
• Présentation de la continuité d’activité avec Azure SQL Managed Instance