La configuration de haute disponibilité SAP la plus dangereuse est celle qui n’a jamais été testée. Elle semble correcte sur le schéma d’architecture, elle a passé avec succès l’examen de mise en service, et tous les membres de l’équipe sont raisonnablement convaincus qu’elle fonctionnerait si un problème venait à survenir. Mais elle n’a jamais réellement fait l’objet d’un basculement, donc personne ne sait avec certitude si le système secondaire prend le relais en 90 secondes ou en 25 minutes, si le serveur de réplication Enqueue se reconnecte correctement après une défaillance du nœud principal, ou si l’équipe de surveillance reçoit une alerte avant que les utilisateurs ne commencent à appeler.
Cet article traite des modèles architecturaux qui font réellement leurs preuves en cas de défaillance des systèmes de production, et non de ceux qui semblent convaincants dans les présentations des fournisseurs. Il part du principe que vous savez ce qu’est la réplication du système SAP HANA. L’objectif est d’aborder les décisions spécifiques et les erreurs de configuration qui déterminent si votre configuration HA résiste à une panne réelle.
Contre quoi la haute disponibilité SAP doit-elle réellement protéger ?
Quelle est la différence entre la haute disponibilité (HA) et la reprise après sinistre (DR), et pourquoi les confondre crée des lacunes ?
La haute disponibilité et la reprise après sinistre sont deux problèmes distincts qui nécessitent des solutions différentes ; les équipes SAP qui gèrent efficacement ces deux aspects les traitent dès le départ comme des enjeux de conception distincts. La haute disponibilité (HA) consiste à maintenir le service opérationnel en cas de défaillance d’un composant unique : un nœud de base de données, un serveur d’applications, une liaison réseau. L’objectif de reprise est de l’ordre de quelques minutes. La portée géographique se limite généralement à un seul centre de données ou à deux sites reliés par une connexion à faible latence.
La reprise après sinistre consiste à restaurer le service après un incident au niveau du site : une panne de courant dans le centre de données, un incident matériel majeur, une coupure de réseau régionale. L’objectif de reprise est de quelques heures. La portée géographique implique une distance physique, ce qui signifie généralement une réplication asynchrone, car la réplication synchrone sur de longues distances introduit une latence d’écriture que les systèmes HANA de production ne peuvent pas absorber.
La faille qui coûte le plus cher aux entreprises réside dans la conception d’un système unique censé remplir ces deux fonctions. Une configuration de réplication HANA en mode synchrone entre deux baies situées dans le même centre de données assure la haute disponibilité (HA), mais pas la reprise après sinistre (DR). Une configuration en mode asynchrone entre deux centres de données distants de 500 km assure la reprise après sinistre (DR), mais comporte un risque de perte de données. Une configuration de réplication à plusieurs niveaux, avec un site secondaire synchrone à proximité et un site tertiaire asynchrone à distance, offre les deux, mais sa configuration est plus complexe à exploiter et à tester. Savoir pour quel scénario vous concevez votre système avant de configurer la réplication vous évite de découvrir, à grands frais, que votre plan de reprise après sinistre (DR) reposait sur des capacités que votre configuration de haute disponibilité (HA) ne fournit pas.
Les modes de défaillance que les configurations HA standard ne prennent pas en compte
Le basculement d’un nœud de base de données est le mode de défaillance pour lequel toute configuration HA SAP est conçue. C’est également l’un des modes de défaillance les plus rares dans un environnement bien entretenu. Les défaillances qui provoquent réellement des temps d’arrêt en production sont généralement plus banales et plus variées : saturation de l’interface réseau entre les couches applicative et de base de données, dégradation des E/S de stockage affectant les performances d’écriture des journaux HANA, un job d’arrière-plan monopolisant les processus de travail sur toutes les instances de serveur d’applications, ou encore une modification de configuration qui n’a pas été testée au préalable en environnement de test.
L’architecture HA standard n’offre aucune protection contre ces problèmes. Un cluster HANA à deux nœuds avec Pacemaker gère la défaillance d’un nœud de base de données. Elle ne sert à rien lorsque le problème se situe au niveau de la couche des serveurs d’applications. Elle ne sert à rien lorsque tous les serveurs d’applications sont joignables mais que le nœud HANA principal est tellement occupé par une requête analytique indésirable que les transactions de dialogue expirent.
Cela a son importance pour les décisions architecturales, car les équipes qui conçoivent uniquement en vue d’une défaillance de nœud se retrouvent avec une réponse robuste à un seul mode de défaillance et aucune couverture pour les autres. Une approche HA complète prend en compte la couche applicative, la couche d’intégration et l’infrastructure de surveillance en plus du cluster de bases de données.
La couche SAP HANA : une réplication système bien pensée
Réplication synchrone ou asynchrone : le choix qui détermine votre RPO
La réplication système SAP HANA fonctionne selon trois modes. Le choix entre ces modes n’est pas une simple question de préférence. Il s’agit d’une décision qui détermine directement votre objectif de point de reprise (RPO) et qui a un impact mesurable sur les performances d’écriture du système principal.
| Mode | RPO | Impact sur la performance | Use case typique |
| SYNC | Aucune perte de données (RPO = 0) | Latence plus élevée lors des écritures. Un aller-retour réseau à chaque validation. | HA au sein du même centre de données ou d’un réseau à faible latence. |
| SYNCMEM | Presque zéro (données en mémoire sur le disque secondaire) | Inférieur à SYNC. Le système secondaire confirme la réception des données une fois celles-ci en mémoire, avant leur écriture sur le disque. | HA, où un certain regain de performances justifie un risque théorique minime de perte de données. |
| ASYNC | Risque de perte de données (en fonction du décalage au moment de la panne) | Impact minime sur les performances de base. | Réplication DR sur un réseau étendu (WAN). Ne convient pas pour une haute disponibilité (HA) de premier plan. |
Le mode SYNC est le choix approprié pour la haute disponibilité (HA) primaire au sein d’un centre de données ou entre des sites reliés par un réseau dont la latence aller-retour est inférieure à 1 ms. L’impact sur les performances est réel mais limité, et c’est le seul mode qui garantit une perte de données nulle lors du basculement. L’utilisation du mode SYNC sur une liaison WAN à forte latence introduit une latence d’écriture qui s’accumule à chaque transaction validée. Dans un système de production très sollicité, cela devient perceptible pour les utilisateurs.
SYNCMEM constitue un compromis raisonnable lorsque l’impact de SYNC sur les performances est mesurable et que le risque théorique que des données restent en mémoire sur le secondaire (sans avoir encore été écrites sur le disque) est acceptable. Pour la plupart des environnements de production, ce risque est très faible, et SYNCMEM offre des performances nettement supérieures à celles de SYNC en cas de charge d’écriture élevée.
L’utilisation d’ASYNC pour la haute disponibilité (HA) du serveur principal est une erreur d’architecture étonnamment courante. Il est facile de comprendre pourquoi cela se produit : la configuration semble identique, le serveur secondaire est en ligne et, dans un environnement de test avec un faible volume d’écriture, le décalage de réplication est négligeable. Sous une charge de production, le décalage ASYNC peut atteindre plusieurs secondes ou minutes pendant les périodes d’écriture intensive. Un basculement pendant une fenêtre de décalage signifie que les transactions validées sur le serveur principal qui n’ont jamais atteint le serveur secondaire sont définitivement perdues.
| Erreur courante : l’utilisation du mode ASYNC pour un serveur secondaire HA situé dans le même centre de données est un anti-modèle bien connu. Les gains de performances sont réels, mais minimes. Le risque de perte de données est également faible, mais pas nul. Pour un système financier ou logistique en production, ce compromis n’en vaut pas la peine. |
Réplication du système HANA avec Pacemaker : les détails de configuration qui comptent
Pacemaker est le gestionnaire de ressources de cluster standard pour la haute disponibilité (HA) de SAP HANA sous Linux. Il gère la détection des pannes de nœuds, la séquence de basculement et le « fencing » (STONITH : Shoot The Other Node In The Head). Chacune de ces trois fonctions comporte des détails de configuration qui déterminent si un basculement s’effectue correctement ou se bloque.
La vitesse de détection des pannes de nœuds est contrôlée par la configuration du délai d’expiration et de l’intervalle de ping de Pacemaker. Les valeurs par défaut sont prudentes, ce qui signifie qu’un nœud défaillant peut ne pas être détecté avant 30 à 60 secondes avec les paramètres par défaut. Pour les environnements ayant des objectifs RTO ambitieux, il est nécessaire de réduire ces valeurs, mais cela nécessite des tests minutieux. Des seuils de détection trop agressifs entraînent des faux positifs : Pacemaker déclare un nœud défaillant lors d’un bref incident réseau et lance un basculement qui n’était pas nécessaire.
La configuration de STONITH est souvent considérée comme une simple case à cocher lors de l’installation. L’objectif du « fencing » est de garantir qu’un nœud que Pacemaker considère comme défaillant ne puisse plus écrire sur les ressources partagées avant que le nœud secondaire ne prenne le relais, ce qui pourrait sinon entraîner une corruption des données due à un « split-brain ». Dans un environnement de machines virtuelles, STONITH est généralement implémenté via l’API de gestion de l’alimentation de l’hyperviseur. Dans un environnement bare-metal, il nécessite un réseau de gestion hors bande et du matériel dédiés. Les environnements qui désactivent STONITH en raison de sa difficulté de configuration acceptent le risque de « split-brain » en échange d’une configuration plus simple. Ce n’est pas un compromis qui devrait être fait pour la haute disponibilité en production.
| Remarque : la note SAP 1984787 traite des exigences de configuration de SUSE Linux Enterprise Server pour SAP HANA HA avec Pacemaker. La note SAP 2578899 traite des exigences équivalentes pour Red Hat Enterprise Linux. La lecture de ces deux notes est obligatoire avant tout déploiement en production ; il ne s’agit pas de références facultatives. |
Réplication à plusieurs niveaux : quand faut-il à la fois la haute disponibilité (HA) et la reprise après sinistre (DR) ?
La réplication du système HANA prend en charge le chaînage : un serveur primaire réplique de manière synchrone vers un serveur secondaire local (HA), et ce serveur secondaire réplique de manière asynchrone vers un serveur tertiaire distant (DR). Cette configuration offre un RPO quasi nul en cas de pannes locales et une cible de reprise après sinistre qui tolère une certaine perte de données tout en préservant la séparation géographique.
La complexité opérationnelle de la réplication à plusieurs niveaux est supérieure à celle de la réplication à un seul niveau. Après une défaillance du primaire et un basculement HA, l’ancien secondaire devient le nouveau primaire, et le tertiaire doit être redirigé pour se répliquer à partir de celui-ci. Cette redirection n’est pas automatique par défaut. Elle nécessite soit une intervention manuelle, soit un script d’automatisation personnalisé dans le cadre du guide de basculement. Les équipes qui déploient une réplication à plusieurs niveaux sans documenter ni tester la procédure de redirection de reprise après sinistre se retrouvent avec une configuration qui fonctionne pour le premier mode de défaillance, mais qui les oblige à bricoler manuellement une chaîne de reprise après sinistre tout en gérant un incident en cours.
Haute disponibilité des serveurs d’application : la couche souvent négligée
Le serveur de réplication Enqueue : le composant SAP HA le plus souvent mal configuré
Le serveur SAP Enqueue gère les verrous de l’application ABAP. Il s’agit d’un processus unique. Dans une installation standard sans configuration HA, le serveur Enqueue s’exécute sur une seule instance de serveur d’application, et si cette instance tombe en panne, tous les verrous sont perdus. Les utilisateurs reçoivent une erreur de session, les transactions en cours ne peuvent pas être validées et le système doit être redémarré pour effacer la table des verrous.
Le serveur de réplication Enqueue (ERS) résout ce problème en conservant une copie répliquée de la table des verrous sur une deuxième instance. Lorsque le serveur Enqueue principal tombe en panne, l’ERS prend le relais et la table des verrous est préservée. Dans la plupart des cas, le basculement est transparent pour les utilisateurs.
Le problème de configuration qui revient régulièrement dans les environnements de production concerne une installation ERS qui, bien que techniquement présente, n’est pas correctement intégrée à Pacemaker. L’instance ERS existe et réplique la table de verrouillage, mais Pacemaker n’en a pas connaissance ; par conséquent, une défaillance de nœud entraînant la mise hors service du serveur Enqueue principal ne déclenche pas de promotion automatique de l’ERS. La table de verrouillage est répliquée, mais n’est pas activée. Il en résulte un temps d’indisponibilité identique à celui qui se produirait si l’ERS n’avait pas été configuré du tout.
La vérification de la bonne intégration entre ERS et Pacemaker doit faire partie de chaque révision de configuration HA. Le test est simple : simulez une défaillance du nœud exécutant le serveur Enqueue principal et vérifiez que l’ERS prend le relais sans problème et que les utilisateurs ayant des sessions actives peuvent poursuivre leurs transactions. Si ce test n’a pas été effectué, la configuration de l’ERS n’est pas vérifiée.
| En pratique : dans les environnements où le serveur Enqueue s’exécute sur le même nœud que le nœud principal HANA, la défaillance d’un seul nœud entraîne la mise hors service simultanée de la base de données et de la gestion des verrous. Le fait de déployer le serveur Enqueue et le nœud principal HANA sur des hôtes physiques ou virtuels distincts signifie qu’une défaillance d’un nœud de base de données ne provoque pas automatiquement un événement lié à la table de verrous au niveau de la couche applicative. |
Répartir les instances de serveur d’applications sans créer de nouveaux modes de défaillance
L’exécution de plusieurs instances SAP en mode dialogue sur plusieurs serveurs d’applications constitue l’approche standard en matière de disponibilité au niveau de la couche applicative. Si une instance de serveur d’applications tombe en panne, les utilisateurs se reconnectent via le serveur de messages à une autre instance disponible. Ce système fonctionne de manière fiable pour les opérations sans état.
Le mode de défaillance contre lequel les instances multiples de serveur d’applications n’offrent aucune protection est la saturation simultanée du pool de processus de travail sur toutes les instances. Si un job batch incontrôlable ou un rapport mal optimisé monopolise les processus de travail en arrière-plan ou de dialogue sur tous les serveurs d’applications disponibles, le système est de fait indisponible, même si aucune instance n’a échoué. L’architecture HA au niveau de l’infrastructure ne résout pas ce problème.
La répartition des processus de travail nécessite également que le serveur de messages, qui gère l’équilibrage de charge entre les instances de serveur d’application, soit lui-même protégé. Dans la plupart des déploiements en production, le serveur de messages s’exécute en tant que composant de l’instance principale du serveur d’application. Une défaillance de cette instance met hors service à la fois les processus de dialogue et la couche de routage. L’exécution du serveur de messages sur une instance dédiée dotée de sa propre configuration de basculement ajoute de la complexité, mais élimine un point de défaillance unique significatif dans les environnements à forte demande.
Haute disponibilité dans les environnements cloud et hybrides
Qu’est-ce qui change lorsque SAP est exécuté sur une plateforme hyperscale
Les principes de haute disponibilité (HA) sous-jacents pour SAP sur AWS, Azure ou GCP sont les mêmes que pour les environnements sur site. Réplication du système HANA, Pacemaker, ERS, instances AS multiples. Ce qui change, c’est la couche d’infrastructure sur laquelle ces composants s’exécutent, et cette couche introduit à la fois de nouvelles capacités et de nouvelles contraintes.
Les zones de disponibilité (AZ) sur les hyperscalers offrent une séparation physique au sein d’une région, et le fait de placer les nœuds HANA primaire et secondaire dans des AZ distinctes protège contre une défaillance au niveau de la zone. La contrainte pratique est la latence réseau. La latence entre deux AZ au sein d’une même région se situe généralement entre 1 ms et 2 ms, ce qui se trouve dans la plage où la réplication HANA SYNC est viable, mais plus proche du seuil à partir duquel les charges de travail à forte intensité d’écriture commencent à avoir un impact mesurable. Tester les performances de réplication sous une charge d’écriture représentative de la production avant de s’engager dans une configuration SYNC inter-AZ est une étape nécessaire, et non facultative.
Les hyperscalers gèrent également STONITH différemment des environnements sur site. Le fencing IPMI/BMC basé sur le matériel, qui est standard sur le bare metal, n’est pas disponible dans le contexte d’une machine virtuelle. Les agents STONITH natifs du cloud utilisent les API de gestion des instances de l’hyperscaler pour mettre hors tension un nœud cible. Ces agents sont bien testés et fiables, mais ils nécessitent la configuration d’autorisations IAM appropriées, et ces autorisations doivent être vérifiées avant un scénario de basculement réel, et non pendant celui-ci.
RISE with SAP et les limites de la surveillance
RISE with SAP transfère la gestion de l’infrastructure et l’exploitation de la plateforme de base à SAP et à l’hyper-scaleur sous-jacent. En ce qui concerne plus particulièrement l’architecture HA, cela signifie que SAP gère la configuration du cluster HANA, la configuration de Pacemaker et le basculement au niveau de l’infrastructure pour le cœur de S/4HANA. Le client ne configure ni ne gère directement ces composants.
Ce que le client conserve dans un environnement RISE, c’est la responsabilité de la disponibilité au niveau des applications : les extensions développées sur SAP BTP, les intégrations avec des systèmes non-SAP, la planification des tâches en arrière-plan qui détermine si les processus critiques s’exécutent dans leurs fenêtres, et surtout, la couche de surveillance qui permet de vérifier si le système est réellement en bon état de fonctionnement d’un point de vue métier.
Le SLA RISE de SAP couvre la disponibilité de l’infrastructure. Il ne couvre pas l’état du code ABAP personnalisé, le taux de réussite du traitement des interfaces, ni le fait que les tâches planifiées aient été exécutées dans les délais opérationnels. Une organisation fonctionnant sur RISE et ne disposant pas de couche de surveillance indépendante dépend entièrement du portail d’assistance de SAP pour détecter tout dysfonctionnement au niveau de la couche applicative. Il s’agit là d’une lacune opérationnelle significative, indépendamment de ce que stipule le SLA de l’infrastructure.
Tester votre configuration HA : l’étape que la plupart des équipes négligent
Un basculement non testé est un basculement imprévisible
Les configurations HA se dégradent au fil du temps sans que personne ne s’en aperçoive. Une ressource de cluster correctement enregistrée auprès de Pacemaker lors de la mise en service se retrouve orpheline lorsqu’un correctif du système d’exploitation modifie le nom d’un service. Un délai d’expiration Pacemaker calibré pour le profil matériel d’origine n’est plus adapté après un redimensionnement de la machine virtuelle. Une instance ERS qui avait été vérifiée après la configuration initiale n’a jamais été revérifiée après une mise à niveau majeure de SAP.
La seule façon de savoir si un basculement fonctionnera est d’en exécuter un. Pas un basculement simulé dans un environnement sandbox avec une fraction des données. Un basculement réel du cluster de production, pendant une fenêtre de maintenance, avec l’équipe opérationnelle qui surveille les tableaux de bord de monitoring et chronomètre chaque phase de la séquence de reprise.
La plupart des organisations ne procèdent pas ainsi chaque année. Beaucoup ne l’ont jamais fait du tout. L’argument contre les tests est le risque : un test de basculement pourrait lui-même provoquer une interruption imprévue si quelque chose tournait mal. Cet argument est valable. Mais le contre-argument est que découvrir une configuration de basculement défaillante lors d’un incident réel en production, sans fenêtre de maintenance, sous pression, avec des utilisateurs affectés, est un résultat bien pire que de la découvrir lors d’un test contrôlé où l’on a le temps de la corriger.
En quoi consiste un test de haute disponibilité (HA) réaliste ?
Un test HA efficace ne se limite pas à vérifier que le nœud HANA secondaire prend le relais après l’arrêt du nœud principal. Il teste l’intégralité de la séquence de reprise et mesure chaque phase.
- Délai entre la défaillance du nœud principal et la détection par Pacemaker : doit être inférieur à 30 secondes avec une configuration standard.
- Délai entre la détection et l’achèvement de STONITH : confirme que le mécanisme de fencing fonctionne.
- Délai entre le fencing et la promotion du nœud secondaire : la phase de prise de relais par HANA, généralement de 30 à 90 secondes selon le volume du journal delta.
- Délai entre la promotion du nœud secondaire et la première connexion utilisateur réussie : inclut la reconnexion au serveur d’applications et l’enregistrement auprès du serveur de messages.
- Comportement de l’ERS : confirme que les utilisateurs ayant des sessions actives au moment de la défaillance peuvent poursuivre leurs transactions sans erreur de session après la reconnexion.
- Envoi d’alertes : vérifiez que le système de surveillance a détecté la panne et acheminé l’alerte appropriée à l’équipe concernée dans les délais prévus.
Ce dernier point mérite d’être souligné. Un test de haute disponibilité qui n’inclut pas la vérification de la surveillance est incomplet. Le cluster peut se rétablir en 90 secondes, mais si l’équipe d’exploitation n’a pris connaissance de la panne qu’en lisant un e-mail 20 minutes plus tard, le MTTR effectif pour cet incident inclut ce délai de détection. La surveillance ne fait pas partie intégrante de l’architecture de haute disponibilité. C’est la couche qui détermine si l’architecture fonctionne comme prévu lorsqu’un problème survient réellement.
La surveillance en tant que composante fonctionnelle de la haute disponibilité SAP
Les documents relatifs à l’architecture HA s’arrêtent généralement au niveau de la couche infrastructure. Configuration du cluster, mode de réplication, configuration du fencing. La couche de surveillance est généralement traitée séparément, dans une section distincte de la documentation architecturale, par une équipe différente.
Cette séparation pose un problème pratique. Lors d’un basculement réel, le système de surveillance est la principale source d’information fiable sur ce qui se passe et à quelle vitesse. S’il indique qu’une prise de relais HANA est en cours, l’équipe d’exploitation sait qu’elle ne doit pas redémarrer les services manuellement. S’il indique que la promotion ERS a échoué, elle sait où concentrer ses efforts. S’il indique que l’alerte a été déclenchée 40 secondes après la détection de la défaillance, elle sait que la chaîne d’escalade fonctionne. Sans cette vue en temps réel, la réponse est plus lente et le risque qu’une intervention manuelle aggrave la situation est plus élevé.
La couche de surveillance détecte également les modes de défaillance que l’architecture HA ne prend pas en charge : la baisse de performances qui précède la défaillance d’un nœud, la saturation des processus de travail qui rend le système pratiquement indisponible sans qu’aucun événement d’infrastructure ne se soit produit, ou encore la tâche d’arrière-plan qui s’exécute en 200 % de sa durée normale et qui est sur le point de dépasser un délai, ce qui nécessitera une intervention manuelle. Aucun de ces éléments ne déclenche d’événement Pacemaker. Or, tous ont une incidence sur la continuité des activités.
Une architecture SAP HA bien conçue spécifie ce que la couche de surveillance doit observer, à quelle fréquence et avec quel routage des alertes. Elle ne laisse pas la surveillance au second plan, à configurer par la première personne disponible après la mise en service. Les deux conceptions ne sont pas distinctes : l’une protège l’infrastructure, l’autre fournit la visibilité qui rend cette protection opérationnelle.
Les modèles qui font leurs preuves
La haute disponibilité SAP n’est pas une configuration que l’on définit une fois pour toutes. Il s’agit d’un système de composants interdépendants, dont chacun peut s’écarter de son état prévu au fil du temps, et dont chacun doit être vérifié périodiquement pour s’assurer qu’il fonctionne toujours conformément au document d’architecture.
Les modèles qui résistent à la pression réelle de la production ont plusieurs points communs. Ils distinguent la haute disponibilité (HA) de la reprise après sinistre (DR) par conception, et non par simple hypothèse. Ils protègent la couche Enqueue avec la même rigueur que la couche HANA, car la perte d’une table de verrouillage est aussi perturbante qu’une défaillance d’un nœud de base de données. Ils testent le basculement selon un calendrier plutôt que d’attendre qu’un incident révèle des lacunes. Et ils considèrent la surveillance non pas comme un simple ajout, mais comme une exigence structurelle : la couche qui transforme une capacité HA théorique en une capacité pratique.
Les configurations qui échouent sous pression sont celles où chaque composant a été correctement installé, mais où les interactions entre les composants n’ont jamais été validées au niveau du système. Le cluster HANA est prêt. L’ERS est configuré. La surveillance est opérationnelle. Mais l’ERS n’a jamais été enregistré auprès de Pacemaker, le seuil de surveillance pour la prise de relais de HANA a été défini trop bas et déclenche des faux positifs, et le test de basculement a été programmé deux fois et annulé à chaque fois car l’environnement de production était trop sollicité.
Ce n’est pas une configuration HA. Il s’agit d’un ensemble de composants HA qui n’ont pas été assemblés en un système fonctionnel. La différence devient évidente à 3 h du matin un lundi, lorsque le nœud principal tombe en panne.
Redpeaks surveille en temps réel l’état de la réplication du système SAP HANA, la santé du cluster Pacemaker, la disponibilité des serveurs d’applications et l’état de l’ERS, avec des alertes couvrant les phases de transition d’un basculement, et pas seulement les indicateurs en régime permanent.
