Partager via

Guide de récupération d'urgence - Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Azure SQL Managed Instance offre une garantie de haute disponibilité d’au moins 99,99 % pour prendre en charge une grande variété d’applications, y compris les applications critiques, qui doivent toujours être disponibles. Azure SQL Managed Instance dispose également de capacités de continuité d'activité clés en main que vous pouvez mettre en œuvre pour une récupération d'urgence en cas de panne régionale. Cet article contient des informations précieuses à consulter avant le déploiement de l’application.

Bien que nous nous efforcions continuellement de fournir une haute disponibilité, il arrive parfois que le service Azure SQL Managed Instance subisse des pannes qui provoquent l’indisponibilité de votre base de données et affectent donc votre application. Lorsque notre analyse du service détecte des problèmes qui provoquent des erreurs de connectivité généralisées, des défaillances ou des problèmes de performances, le service déclare automatiquement une panne pour vous tenir informé.

Interruption de service

En cas de panne du service d’Azure SQL Managed Instance, vous trouverez des détails supplémentaires liés à la panne aux endroits suivants :

  • Bannière Portail Azure

    Si votre abonnement est identifié comme concerné, il y a une alerte de panne d’un problème de service dans votre portail Azure Notifications :

    Capture d’écran du portail Azure d'une notification d'un problème lié au service Azure SQL Managed Instance.

  • Aide + support ou Support + résolution des problèmes

    Lorsque vous créez un ticket de support à partir de Aide + support ou Support + dépannage, vous trouvez des informations sur les problèmes qui ont un impact sur vos ressources. Sélectionnez Afficher les détails sur la panne pour plus d’informations et un résumé de l’impact. Il y a également une alerte dans la page Nouvelle demande de support.

    Capture d’écran de la page Aide + support montrant une notification d’un problème d’intégrité du service actif.

  • Service de contrôle d’intégrité

    La page Service Health du Portail Azure contient des informations sur l’état du centre de données Azure à l’échelle mondiale. Recherchez « Intégrité des services » dans la barre de recherche du Portail Azure, puis affichez Problèmes de service dans la catégorie Événements actifs. Vous pouvez également afficher l’intégrité des ressources individuelles dans la page Intégrité des ressources de n’importe quelle ressource sous le menu Aide. Voici un exemple de capture d’écran de la page Intégrité des services, avec des informations sur un problème de service actif en Asie Sud-Est :

    Capture d’écran de la page Portail Azure Service Health lors d’un problème de service en Asie Sud-Est, montrant le problème et un mappage des ressources affectées.

  • Notification par e-mail

    Si vous avez configuré des alertes, une notification par e-mail est envoyée de azure-noreply@microsoft.com lorsqu’une panne de service a un impact sur votre abonnement et vos ressources. Le corps de l’e-mail commence généralement par « L’alerte du journal d’activité ... a été déclenchée par un problème de service pour l’abonnement Azure... ». Pour plus d’informations sur les alertes d’intégrité du service, consultez Recevoir des alertes de journal d’activité sur les notifications de service Azure à l’aide du Portail Azure.

Quand lancer la récupération d’urgence pendant une panne

En cas de panne de service impactant les ressources de l’application, envisagez les actions suivantes :

  • Les équipes Azure mettent tous les efforts en œuvre pour restaurer le service aussi rapidement que possible, mais cela peut parfois prendre plusieurs heures. Si votre application peut tolérer un temps d'arrêt important, vous pouvez simplement attendre que la récupération soit terminée. Dans ce cas, aucune action n’est requise de votre part. Affichez l’intégrité des ressources individuelles dans la page Intégrité des ressources de n’importe quelle ressource sous le menu Aide. Reportez-vous à la page Intégrité des ressources pour les mises à jour et les informations les plus récentes concernant une panne. Une fois le service rétabli dans la région, la disponibilité de votre application est restaurée.

  • La récupération vers une autre région Azure peut nécessiter la modification des chaînes de connexion d’application ou l’utilisation de la redirection DNS et peut entraîner une perte de données permanente. Par conséquent, la récupération d’urgence ne doit être effectuée que lorsque la durée de panne approche de l’objectif de temps de récupération (RTO) de votre application. Lorsque l’application est déployée en production, vous devez effectuer une analyse régulière de l’intégrité de l’application et affirmer que la récupération est justifiée uniquement en cas d’échec de connectivité prolongé entre la couche Application et la base de données. En fonction de la tolérance de votre application aux temps d’arrêt et de la responsabilité éventuelle de l’entreprise, vous pouvez décider si vous souhaitez attendre que le service soit récupéré ou lancer la récupération d’urgence vous-même.

Conseils sur la récupération après panne

Si la panne de Azure SQL Managed Instance dans une région n’a pas été atténuée pendant une période prolongée et affecte le contrat de niveau de service (contrat SLA) de votre application, envisager les étapes suivantes :

Basculement (aucune perte de données) vers une instance secondaire géo-répliquée

Si les groupes de basculement sont activés, vérifiez si l'état des ressources des instances primaires et secondaires est En ligne dans le portail Azure. Si c'est le cas, le plan de données des instances primaire et secondaire est sain.

Lancez un basculement de groupes de basculement vers la région secondaire à l’aide de :

Remarque

Un basculement nécessite une synchronisation complète des données avant de changer de rôle et n’entraîne pas de perte de données. Selon le type de panne de service, il n’existe aucune garantie que le basculement sans perte de données aboutira, mais il vaut la peine d’essayer comme première option de récupération.

Basculement forcé (perte de données potentiel) vers une instance secondaire géo-répliquée

Si le basculement ne se termine pas correctement et rencontre des erreurs ou si l’état de la base de données primaire n’est pas En ligne, envisagez soigneusement un basculement forcé avec une perte de données potentielle dans la région secondaire.

Pour lancer un basculement forcé, utilisez :

La géorestauration

Si vous n'avez pas activé les groupes de basculement, vous pouvez, en dernier recours, utiliser la géo-restauration pour récupérer après une panne. La géo-restauration utilise des sauvegardes géo-répliquées comme source. Vous pouvez restaurer une base de données sur toute instance dans n’importe quelle région Azure à partir des dernières sauvegardes géo-répliquées. Vous pouvez demander une géo-restauration même si une panne a rendu l’instance ou la région entière inaccessibles.

Pour plus d’informations sur les géo-restaurations à l’aide d’Azure CLI, le Portail Azure, PowerShell ou l’API REST, consultez Géo-restauration.

Configurer votre base de données après récupération

Si vous utilisez le basculement géographique ou la géorestauration pour récupérer après une panne, vous devez vous assurer que la connectivité à la nouvelle instance est correctement configurée pour permettre à l’application de reprendre un fonctionnement normal. Voici une liste de contrôle de tâches pour vous aider à remettre votre base de données restaurée en service.

Important

Il est recommandé d’effectuer des exercices périodiques de votre stratégie de récupération d’urgence pour vérifier la tolérance de l’application, ainsi que tous les aspects opérationnels de la procédure de récupération. Les autres couches de votre infrastructure d’application peuvent nécessiter une reconfiguration. Pour plus d’informations sur les étapes d’architecture résiliente, passez en revue la liste de contrôle haute disponibilité et récupération d'urgence.

Mettre à jour les chaînes de connexion

  • Si vous utilisez la géorestauration, vous devez vous assurer que la connectivité à la nouvelle instance est correctement configurée pour permettre à l’application de reprendre un fonctionnement normal. Comme votre base de données restaurée se trouve sur une autre instance, vous devez mettre à jour la chaîne de connexion de votre application de sorte qu’elle pointe vers celle-ci. Pour plus d’informations sur la modification des chaînes de connexion, consultez le langage de développement approprié pour votre bibliothèque de connectivité.
  • Si vous utilisez des groupes de basculement pour récupérer après une panne et utiliser des écouteurs en lecture-écriture et en lecture seule dans les chaînes de connexion de votre application, aucune autre action n’est nécessaire, car les connexions sont automatiquement dirigées vers le nouveau serveur principal.

Configurer les règles de pare-feu

Assurez-vous que les règles NSG et de table de routage configurées pour l'instance secondaire correspondent à celles configurées sur l'instance primaire. Pour en savoir plus, passez en revue la Configuration des sous-réseaux assistés par le service.

Configurer les identifiants de connexion et les utilisateurs de la base de données

Créez les identifiants qui doivent être présents dans la base de données master sur l'instance secondaire et assurez-vous que ces identifiants disposent des autorisations appropriées dans la base de données master, le cas échéant.

Configurer les alertes de télémétrie

Vérifiez que vos paramètres de règle d’alerte existants sont mis à jour pour mapper à la nouvelle instance principale. Pour en savoir plus, voir Réception de notifications d’alerte et Suivi de l’intégrité du service.

Activer la fonction d’audit

Si l'audit est configuré sur l'instance primaire, il doit être identique sur l'instance secondaire. Pour plus d’informations, consultez Audit Azure SQL pour Azure SQL Managed Instance.

Contenu connexe

Pour en savoir plus, consultez :