Haute disponibilité pour Azure SQL Managed Instance

  • Article

S’applique à :Azure SQL Managed Instance

Cet article décrit la haute disponibilité dans Azure SQL Managed Instance.

Important

La configuration redondante interzone est disponible en préversion publique pour le niveau de service Usage général et disponible de manière générale pour le niveau de service Critique pour l’entreprise.

Vue d’ensemble

L'objectif de l'architecture de haute disponibilité dans Azure SQL Managed Instance est de réduire l'impact sur les charges de travail du client à partir des opérations de gestion initiées par le client qui se traduisent par un bref temps d'arrêt, des opérations de maintenance de service et des interruptions non planifiées. Pour plus d’informations sur les contrats SLA spécifiques des différents niveaux de service, consultez Azure SQL Managed Instance.

La haute disponibilité vous protège de l’impact sur :

  • la zone de disponibilité qui constitue le centre de données (en cas de région multizone) ;
  • le rack dans lequel les nœuds alimentant votre service sont en cours d’exécution ;
  • le nœud lui-même.
  • Couche Application

Pour réduire l'impact en cas de pannes régionales ou plus grandes, vous pouvez utiliser l'une des techniques disponibles décrites dans notre vue d'ensemble de la continuité d'activité.

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 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.

La solution de haute disponibilité permet de s’assurer que les données validées ne sont jamais perdues en raison de défaillances, que les opérations de maintenance n’affectent pas votre charge de travail et que l’instance ne constitue pas un point de défaillance unique dans votre architecture logicielle.

Il existe deux modèles architecturaux différents de haute 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 haute disponibilité et la fiabilité du stockage de dépôt distant et sur la haute disponibilité des clusters de calcul managés par Azure Service Fabric. Ce modèle de haute 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.

Disponibilité localement redondante

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 étendu. 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. 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 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.

Usage général nouvelle génération est une mise à niveau architecturale du niveau de service Usage général existant. Elle utilise une couche de stockage à distance mise à niveau qui stocke les données d’instance et les fichiers journaux sur les disques managés au lieu des objets blob de pages.

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 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 un stockage SSD attaché pour fournir une E/S à très faible latence pour 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 réplica principal unique qui est accessible pour les charges de travail de clients en lecture et en écriture, et jusqu'à trois réplicas secondaires (calcul et stockage) qui contiennent des copies de données. Le réplica principal envoie constamment des modifications aux réplicas secondaires de manière séquentielle afin de s'assurer que les données sont conservées sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ce processus garantit que, si le réplica principal ou un réplica secondaire accessible en lecture devient indisponible pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible pour effectuer un 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 automatiquement redirigées vers le nouveau réplica principal (ou 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.

Disponibilité redondante interzone

La disponibilité redondante interzone est basée sur le placement de nœuds de calcul et de réplicas de stockage 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 des Zones de disponibilité Azure, SQL Managed Instance peut placer différents réplicas de l’instance critique pour l’entreprise dans différentes zones de disponibilité au sein de la même région. De la même façon, les nœuds de calcul sans état d’un niveau de service Usage général sont placés dans une zone de disponibilité différente, tandis que le stockage avec état utilise la configuration de stockage redondant interzone (ZRS).

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). En sélectionnant une configuration redondante interzone, vous rendez vos instances de niveau Critique pour l’entreprise ou à Usage général résilientes face à un nombre de défaillances beaucoup plus important, notamment aux interruptions graves du centre de données, sans aucune modification à la logique d’application. Vous pouvez également convertir les instances de niveau Critique pour l’entreprise à Usage général existantes en configuration redondante interzone.

Les instances redondantes interzones disposent de réplicas dans différents centres de données avec une certaine distance de séparation. Par conséquent, le temps de réponse du réseau peut augmenter le temps de validation de la transaction et donc 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 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.

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 points suivants lors de l’utilisation de la redondance de zone :

  • La redondance de zone n’est pas disponible pour le niveau de service Usage général nouvelle génération.
  • Pour obtenir des informations à jour sur les régions qui prennent en charge les configurations redondantes interzones, consultez Prise en charge des services par région.
  • 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.

Régions prises en charge pour les instances Critiques pour l’entreprise

La redondance de zone du niveau critique pour l'entreprise pour SQL Managed Instance est prise en charge dans les régions suivantes :

Amérique Europe Moyen-Orient Afrique Asie-Pacifique
Brésil Sud France Centre Qatar Central Afrique du Sud Nord Australie Est
Centre du Canada Italie Nord Israël Central Inde centrale
USA Centre Allemagne Centre-Ouest Japon Est
USA Est Norvège Est Centre de la Corée
USA Est 2 Europe Nord Asie Sud-Est
États-Unis - partie centrale méridionale Sud du Royaume-Uni Asie Est
USA Ouest 2 Suède Centre
USA Ouest 3 Suisse Nord
Pologne Centre

Régions prises en charge pour les instances à Usage général

Remarque

La configuration redondante interzone est une préversion publique pour le niveau de service Usage général.

Amérique Europe Moyen-Orient Afrique Asie-Pacifique
Brésil Sud France Centre Qatar Central Afrique du Sud Nord Australie Est
USA Est Italie Nord Israël Central Inde centrale
USA Est 2 Allemagne Centre-Ouest Japon Est
États-Unis - partie centrale méridionale Norvège Est Centre de la Corée
USA Ouest 2 Europe Nord Asie Sud-Est
USA Ouest 3 Sud du Royaume-Uni Asie Est
Suède Centre
Suisse Nord
Pologne Centre

Test de résilience aux erreurs de l’application

La haute 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 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 instance managée. Dans le cas d’une instance redondante interzone, l’appel d’API entraîne la redirection des connexions clientes vers le nouveau réplica principal dans une autre zone de disponibilité que celle de l’ancien réplica principal. 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 instance gérée.

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

PowerShell API REST Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance – Basculement Le basculement az sql mi peut être utilisé pour invoquer un appel d'API REST à partir d'Azure CLI

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. Pour le niveau de service critique pour l'entreprise, SQL Managed Instance utilise la technologie de groupe de disponibilité SQL Server Always On pour la réplication de la base 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.

Étapes suivantes