Surveillance de l’état d’intégrité haute disponibilité pour Azure Database pour PostgreSQL - Serveur flexible

Azure Database pour PostgreSQL serveur flexible inclut une fonctionnalité de surveillance de l'état d'intégrité haute disponibilité (HA) qui utilise l'infrastructure Resource Health Check (RHC) de Azure. Ce service fournit une visibilité continue sur l’état de santé des instances activées pour la haute disponibilité et vous avertit des événements susceptibles d’affecter la connectivité et la disponibilité. Les sections suivantes décrivent chaque état de santé et les scénarios associés afin de vous aider à résoudre les problèmes et à maintenir la stabilité de la HA.

États d'intégrité

Le service surveille chaque état de haute disponibilité via différents signaux internes qui représentent des conditions spécifiques. La liste suivante décrit les états de haute disponibilité possibles, ainsi que les indicateurs visuels et les scénarios susceptibles d’affecter votre serveur flexible Azure Database pour PostgreSQL.

Prêt – la HA est opérationnelle

L’état Prêt indique que votre serveur avec haute disponibilité activée fonctionne normalement, sans aucun problème détecté susceptible de compromettre l’état de préparation au basculement. Toutes les configurations nécessaires sont intactes et aucune condition d’erreur significative n’existe.

Capture d’écran montrant l’état HA prêt.

Détérioré : groupe de sécurité réseau (NSG) ou appliance virtuelle bloquant les connexions

L’état détérioré peut apparaître lorsque des règles de groupe de sécurité réseau ou une appliance virtuelle bloquent les connexions essentielles requises pour la haute disponibilité. Ce problème de configuration empêche le fonctionnement complet de la haute disponibilité. Corrigez le problème en modifiant les paramètres du groupe de sécurité réseau.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû au blocage des connexions par un groupe de sécurité réseau.

Détérioré – État en lecture seule

Si votre serveur flexible PostgreSQL entre dans un état en lecture seule, l’état détérioré reflète cette restriction. Cet état nécessite généralement l’approvisionnement de ressources supplémentaires ou l’adressage des conditions qui ont conduit au paramètre en lecture seule pour restaurer la fonctionnalité complète.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû à un état de lecture seule.

Détérioré : haute disponibilité dans un état détérioré

Cet état s’affiche lorsque le service haute disponibilité (HA) subit une dégradation des performances, éventuellement en raison de problèmes temporaires ou de conditions au niveau du système. L’implémentation d’une logique de nouvelle tentative peut aider à atténuer les effets de ces interruptions de connectivité temporaires. L’état détérioré ne signifie pas que le serveur n’est pas disponible. Il indique plutôt que la configuration HA globale et les contrôles d’état ne sont pas complètement finalisés. Malgré cet état, le serveur peut toujours être opérationnel et accessible.

Pour surveiller avec précision la disponibilité de votre base de données pendant ces périodes, utilisez la métrique dans le is_db_alive cadre des métriques de disponibilité de la base de données. Cette métrique fournit un indicateur fiable de la disponibilité de la base de données, ce qui vous permet de faire la distinction entre une configuration de haute disponibilité incomplète temporaire et un temps d’arrêt réel.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû à des problèmes de performances.

Détérioré – Lancement d’un basculement planifié

Lors d’un événement de basculement planifié lancé pour votre serveur, l’état Détériorée s’affiche, ce qui signifie que les processus de basculement HA sont actifs. Ce processus est généralement bref et contrôlé, et le service devrait reprendre peu de temps.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû à un basculement planifié.

Détérioré – Lancement d’un basculement non planifié

Pour un basculement non planifié, cet état indique un événement de basculement actif déclenché par des circonstances inattendues. Ce scénario peut impliquer de brèves interruptions de connectivité jusqu’à ce que le serveur ait terminé les procédures de basculement.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû à un basculement non planifié.

Dégradé – Basculement de mise à niveau initié

Pendant les mises à niveau système, votre serveur HA peut subir un basculement de mise à niveau pour l’application de mises à jour nécessaires. Dans cet état, le serveur peut restreindre temporairement les nouvelles connexions. Implémentez la logique de nouvelle tentative pour gérer efficacement les problèmes temporaires.

Capture d’écran montrant l’état Détériorée de la haute disponibilité dû à un basculement de mise à niveau.

Configuration des alertes Resource Health

Configurez Resource Health alertes pour recevoir des notifications en temps réel quand des modifications se produisent dans l’état d’intégrité de votre instance PostgreSQL avec haute disponibilité. Vous pouvez configurer ces alertes via le portail Azure ou à l’aide d’un modèle ARM. De cette façon, vous restez informé des mises à jour d’état de haute disponibilité sans surveiller activement le portail.

Étapes de configuration des alertes Resource Health via le portail

  1. Accédez au portail Azure et sélectionnez votre serveur flexible PostgreSQL.
  2. Dans le menu de gauche, sous la section Surveillance , sélectionnez Alertes.
  3. Sélectionnez Nouvelle règle d’alerte et configurez la logique d’alerte en fonction des signaux Resource Health.
  4. Configurez le groupe d’actions pour spécifier la façon dont vous souhaitez être averti (e-mail, SMS, etc.).
  5. Passez en revue et créez la règle d’alerte.

Étapes de création d’alertes Resource Health à l’aide d’un modèle ARM

  1. Téléchargez le modèle ARM à partir du guide de modèle ARM d’alertes Resource Health.
  2. Personnalisez le modèle avec les détails de votre serveur et vos préférences d’alerte spécifiques.
  3. Déployez le modèle ARM à l’aide de Azure CLI ou de Azure PowerShell.
  4. Vérifiez le déploiement et veillez à ce que les alertes soient actives.

Pour plus d’informations sur la configuration des alertes, consultez les guides suivants :

Le monitoring de l’état d’intégrité de la haute disponibilité vous permet d’obtenir des insights essentiels sur les performances de haute disponibilité de votre serveur PostgreSQL, et ainsi d’adopter une approche proactive de la gestion de la durée de bon fonctionnement et de la disponibilité.

Contenu connexe

  • Dernière mise à jour :