Architecture SAP haute disponibilité : les modèles qui tiennent sous la pression de la production réelle

La configuration SAP haute disponibilité la plus dangereuse est celle qui n’a jamais été testée. Elle semble correcte dans le schéma d’architecture, elle a passé la revue de mise en production, et toute l’équipe est raisonnablement convaincue qu’elle fonctionnerait en cas de problème. Mais elle n’a jamais réellement basculé. Personne ne sait donc avec certitude si le système secondaire reprend en 90 secondes ou en 25 minutes, si l’Enqueue Replication Server se reconnecte proprement après la défaillance du nœud primaire, ou si l’équipe de supervision reçoit une alerte avant que les utilisateurs commencent à appeler.

Cet article présente les modèles d’architecture qui résistent vraiment lorsque les systèmes de production tombent en panne, pas ceux qui paraissent convaincants dans les présentations éditeurs. Il suppose que vous connaissez déjà SAP HANA System Replication. L’objectif est de couvrir les décisions concrètes et les mauvaises configurations qui déterminent si votre dispositif HA survit ou non à une panne réelle.

Ce que l’architecture SAP haute disponibilité doit réellement protéger

La différence entre HA et DR, et pourquoi les confondre crée des failles

La haute disponibilité et le disaster recovery répondent à deux problèmes différents, avec des solutions différentes. Les équipes SAP qui gèrent bien les deux les traitent comme deux sujets d’architecture distincts dès le départ. La HA vise à maintenir le service lorsqu’un composant unique tombe en panne : un nœud de base de données, un serveur applicatif, un lien réseau. L’objectif de reprise se compte en minutes. Le périmètre géographique se situe généralement dans un même data center ou entre deux sites reliés par une connectivité à faible latence.

Le disaster recovery consiste à restaurer le service après un événement touchant un site entier : coupure électrique d’un data center, incident matériel majeur, panne réseau régionale. L’objectif de reprise se compte en heures. Le périmètre géographique exige une vraie distance physique, ce qui implique 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.

L’écart qui coûte le plus cher aux organisations vient souvent de la volonté de concevoir un seul système pour remplir les deux rôles. Une configuration HANA System Replication en mode synchrone entre deux baies dans le même data center fournit de la HA, mais pas de DR. Une configuration en mode asynchrone entre deux data centers distants de 500 km fournit du DR, mais accepte une perte potentielle de données. Une réplication multi-niveaux, avec un secondaire synchrone à proximité et un tertiaire asynchrone à distance, couvre les deux besoins, mais elle est plus complexe à exploiter et à tester. Savoir quel scénario vous concevez avant de configurer la réplication évite de découvrir trop tard que votre plan de DR supposait des capacités que votre configuration HA ne fournit pas.

Les modes de défaillance que les configurations HA standard ne couvrent pas

Le basculement d’un nœud de base de données est le scénario de panne que toute configuration SAP haute disponibilité est conçue pour gérer. C’est aussi l’un des scénarios les plus rares dans un environnement bien maintenu. Les pannes qui provoquent réellement de l’indisponibilité en production sont souvent plus banales et plus variées : saturation de l’interface réseau entre les couches applicative et base de données, dégradation des I/O de stockage qui affecte les écritures de logs HANA, job en arrière-plan qui monopolise les work processes sur toutes les instances applicatives, ou changement de configuration qui n’a pas été testé d’abord en environnement hors production.

L’architecture HA standard ne protège contre aucun de ces cas. Un cluster HANA à deux nœuds avec Pacemaker gère la défaillance d’un nœud de base de données. Il n’aide pas lorsque le problème vient de la couche serveur applicatif. Il n’aide pas non plus lorsque tous les serveurs applicatifs sont joignables, mais que le primaire HANA est tellement sollicité par une requête analytique incontrôlée que les transactions dialog expirent.

C’est important pour les décisions d’architecture, car les équipes qui conçoivent uniquement autour de la panne de nœud obtiennent une réponse robuste à un mode de défaillance précis, mais 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 supervision, en plus du cluster de base de données.

La couche SAP HANA : réussir la réplication système

Réplication synchrone ou asynchrone : le choix qui fixe votre RPO

SAP HANA System Replication fonctionne selon trois modes. Le choix entre ces modes n’est pas une préférence. C’est une décision qui détermine directement votre Recovery Point Objective et qui a un impact mesurable sur les performances d’écriture du système primaire.

Le mode SYNC est le bon choix pour la HA primaire dans un data center ou entre des sites connectés par un réseau avec une latence aller-retour inférieure à 1 ms. L’impact performance est réel, mais maîtrisé, et c’est le seul mode qui garantit zéro perte de données lors du basculement. Exécuter SYNC sur un lien WAN à forte latence introduit une latence d’écriture qui s’accumule à chaque transaction validée. Dans un système de production chargé, cela devient visible pour les utilisateurs.

SYNCMEM est un compromis raisonnable lorsque l’impact performance de SYNC est mesurable et que le risque théorique de données encore en mémoire sur le secondaire, pas encore écrites sur disque, est acceptable. Dans la plupart des environnements de production, ce risque est très faible, et SYNCMEM offre des performances sensiblement meilleures que SYNC sous forte charge d’écriture.

Utiliser ASYNC pour la HA primaire est une erreur d’architecture étonnamment fréquente. On comprend pourquoi elle se produit : la configuration semble identique, le secondaire est en ligne, et dans un environnement de test à faible volume d’écriture, le retard de réplication est négligeable. Sous charge de production, le retard ASYNC peut atteindre plusieurs secondes ou minutes pendant les périodes intensives en écriture. Un failover pendant cette fenêtre signifie que des transactions validées sur le primaire, mais jamais arrivées sur le secondaire, sont définitivement perdues.

Erreur fréquente : utiliser le mode ASYNC pour un secondaire HA dans le même data center est un anti-pattern documenté. Les gains de performance sont réels, mais limités. Le risque de perte de données est faible, mais non nul. Pour un système financier ou logistique en production, ce compromis ne vaut pas la peine d’être pris.

HANA System Replication avec Pacemaker : les détails de configuration qui comptent

Pacemaker est le gestionnaire de ressources de cluster standard pour la HA SAP HANA sur Linux. Il gère la détection de panne de nœud, la séquence de basculement et le fencing, aussi appelé STONITH pour Shoot The Other Node In The Head. Chacune de ces trois fonctions comporte des détails de configuration qui déterminent si un failover se termine proprement ou reste bloqué.

La vitesse de détection d’une panne de nœud est contrôlée par les paramètres de timeout et d’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é pendant 30 à 60 secondes avec la configuration standard. Pour les environnements ayant des objectifs RTO agressifs, il est nécessaire d’abaisser ces valeurs, mais cela exige des tests minutieux. Des seuils de détection trop agressifs provoquent des faux positifs : Pacemaker déclare un nœud en panne lors d’une brève microcoupure réseau et déclenche un failover inutile.

La configuration STONITH est l’élément le plus souvent traité comme une simple case à cocher pendant l’installation. Le rôle du fencing est de garantir qu’un nœud que Pacemaker considère comme défaillant ne peut pas continuer à écrire sur des ressources partagées avant que le secondaire prenne le relais, ce qui pourrait sinon provoquer une corruption de données en 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 out-of-band dédié et du matériel adapté. Les environnements qui désactivent STONITH parce qu’il est difficile à configurer acceptent un risque de split-brain en échange d’une installation plus simple. Ce n’est pas un compromis acceptable pour une HA de production.

Note : la note SAP 1984787 couvre les exigences de configuration de SUSE Linux Enterprise Server pour SAP HANA HA avec Pacemaker. La note SAP 2578899 couvre l’équivalent pour Red Hat Enterprise Linux. Les deux sont des lectures indispensables avant un déploiement en production, pas des références optionnelles.

Réplication multi-niveaux : quand vous avez besoin à la fois de HA et de DR

HANA System Replication prend en charge le chaînage : un primaire réplique de manière synchrone vers un secondaire local pour la HA, puis ce secondaire réplique de manière asynchrone vers un tertiaire distant pour le DR. Cette configuration offre un RPO quasi nul en cas de panne locale et une cible DR qui accepte une certaine perte de données tout en garantissant la séparation géographique.

La complexité opérationnelle d’une réplication multi-niveaux est plus élevée que celle d’une réplication simple. Après une panne du primaire et un failover HA, l’ancien secondaire devient le nouveau primaire, et le tertiaire doit être redirigé pour répliquer depuis ce nouveau primaire. Cette redirection n’est pas automatique par défaut. Elle nécessite soit une intervention manuelle, soit un script d’automatisation personnalisé intégré au runbook de failover. Les équipes qui déploient une réplication multi-niveaux sans documenter ni tester la procédure de redirection DR disposent d’une configuration qui fonctionne pour le premier mode de panne, mais les laisse reconstituer manuellement une chaîne DR pendant un incident actif.

Haute disponibilité des serveurs applicatifs : la couche trop souvent sous-estimée

L’Enqueue Replication Server : le composant SAP HA le plus souvent mal configuré

Le SAP Enqueue Server gère les verrous pour l’application ABAP. C’est un processus unique. Dans une installation standard sans configuration HA, l’Enqueue Server tourne sur une instance de serveur applicatif, 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 pratiquement être redémarré pour nettoyer la table de verrous.

L’Enqueue Replication Server, ou ERS, résout ce problème en maintenant une copie répliquée de la table de verrous sur une deuxième instance. Lorsque l’Enqueue Server primaire échoue, l’ERS se promeut, et la table de verrous est préservée. Dans la plupart des cas, le failover est transparent pour les utilisateurs.

La faille de configuration qui apparaît régulièrement en production est un ERS techniquement présent, mais mal intégré avec Pacemaker. L’instance ERS existe et réplique la table de verrous, mais Pacemaker n’en a pas connaissance. Une panne du nœud hébergeant l’Enqueue Server primaire ne déclenche donc pas la promotion automatique de l’ERS. La table de verrous est répliquée, mais elle n’est pas activée. Le résultat est la même indisponibilité que si l’ERS n’avait pas été configuré.

La vérification de l’intégration ERS-Pacemaker doit faire partie de toute revue de configuration HA. Le test est simple : simuler une panne du nœud qui héberge l’Enqueue Server primaire et confirmer que l’ERS se promeut proprement, pendant que les utilisateurs ayant des sessions actives peuvent poursuivre leurs transactions. Si ce test n’a pas été exécuté, la configuration ERS n’est pas vérifiée.

En pratique : dans les environnements où l’Enqueue Server tourne sur le même nœud que le primaire HANA, une seule panne de nœud fait tomber à la fois la base de données et la gestion des verrous applicatifs. Placer l’Enqueue Server et le primaire HANA sur des hôtes physiques ou virtuels séparés signifie qu’une panne de nœud de base de données ne crée pas automatiquement un incident de table de verrous côté applicatif.

Répartir les instances applicatives sans créer de nouveaux modes de panne

Exécuter plusieurs instances dialog SAP sur plusieurs serveurs applicatifs est l’approche standard pour la disponibilité de la couche applicative. Si une instance AS échoue, les utilisateurs se reconnectent via le message server vers une autre instance disponible. Cela fonctionne de manière fiable pour les opérations sans état.

Le mode de panne que plusieurs instances AS ne couvrent pas est la saturation simultanée du pool de work processes sur toutes les instances. Si un job batch incontrôlé ou un rapport mal optimisé monopolise les work processes background ou dialog sur tous les serveurs applicatifs disponibles, le système devient effectivement indisponible, même si aucune instance n’est tombée. L’architecture HA au niveau infrastructure ne traite pas ce cas.

La distribution des work processes exige aussi que le message server, qui gère l’équilibrage de charge entre les instances de serveurs applicatifs, soit lui-même protégé. Dans la plupart des déploiements de production, le message server fonctionne comme un composant de l’instance applicative primaire. Une panne de cette instance fait tomber à la fois les processus dialog et la couche de routage. Exécuter le message server sur une instance dédiée avec sa propre configuration de failover ajoute de la complexité, mais supprime un point de défaillance unique important dans les environnements fortement sollicités.

Haute disponibilité dans les environnements cloud et hybrides

Ce qui change lorsque SAP tourne sur un hyperscaler

Les concepts HA sous-jacents pour SAP sur AWS, Azure ou GCP sont les mêmes qu’on-premise : HANA System Replication, Pacemaker, ERS, plusieurs instances AS. Ce qui change, c’est la couche d’infrastructure sur laquelle ces composants s’exécutent, et cette couche apporte à la fois de nouvelles capacités et de nouvelles contraintes.

Les Availability Zones des hyperscalers offrent une séparation physique au sein d’une région, et placer les nœuds HANA primaire et secondaire dans des AZ séparées protège contre une panne au niveau d’une zone. La contrainte pratique est la latence réseau. La latence inter-AZ au sein d’une même région se situe généralement entre 1 ms et 2 ms. Cela reste dans la plage où la réplication HANA SYNC est viable, mais se rapproche du seuil où les workloads très intensifs en écriture commencent à montrer un impact mesurable. Tester les performances de réplication sous une charge d’écriture représentative de la production avant de valider une configuration SYNC cross-AZ est une étape nécessaire, pas une option.

Les hyperscalers gèrent aussi STONITH différemment des environnements on-premise. Le fencing matériel basé sur IPMI ou BMC, standard sur bare metal, n’est pas disponible dans un contexte de machine virtuelle. Les agents STONITH cloud-native utilisent les API de gestion d’instances de l’hyperscaler pour éteindre un nœud cible. Ces agents sont bien testés et fiables, mais ils nécessitent la configuration des permissions IAM appropriées. Ces permissions doivent être vérifiées avant un vrai scénario de failover, pas pendant.

RISE with SAP et la frontière de supervision

RISE with SAP transfère la gestion de l’infrastructure et les opérations de plateforme de base à SAP et à l’hyperscaler sous-jacent. Pour l’architecture HA, cela signifie que SAP gère la configuration du cluster HANA, le setup Pacemaker et le failover au niveau infrastructure pour le cœur S/4HANA. Le client ne configure ni ne maintient directement ces composants.

Ce que le client conserve dans un environnement RISE, c’est la responsabilité de la disponibilité applicative : les extensions construites sur SAP BTP, les intégrations avec des systèmes non SAP, la planification des jobs en arrière-plan qui détermine si les processus critiques s’exécutent dans les bonnes fenêtres, et surtout la couche de supervision qui offre une visibilité sur la santé réelle du système d’un point de vue métier.

Le SLA RISE de SAP couvre la disponibilité de l’infrastructure. Il ne couvre pas la santé du code ABAP personnalisé, le taux de réussite du traitement des interfaces, ni le fait que les jobs planifiés se terminent dans leurs délais métier. Une organisation qui fonctionne sur RISE sans couche de supervision indépendante dépend entièrement du portail support SAP pour découvrir qu’un problème existe au niveau applicatif. C’est un écart opérationnel important, quelle que soit la promesse du SLA infrastructure.

Tester votre configuration HA : l’étape que la plupart des équipes sautent

Un failover non testé est un failover inconnu

Les configurations HA se dégradent avec le temps sans que personne ne le remarque. Une ressource cluster correctement enregistrée dans Pacemaker au go-live devient orpheline lorsqu’un patch OS modifie un nom de service. Un timeout Pacemaker calibré pour le profil matériel initial ne correspond plus après un redimensionnement de VM. Une instance ERS vérifiée après l’installation initiale n’est jamais revérifiée après une montée de version SAP majeure.

La seule façon de savoir si un failover fonctionnera est d’en exécuter un. Pas un failover simulé dans un environnement sandbox avec une fraction des données. Un vrai failover du cluster de production, pendant une fenêtre de maintenance, avec l’équipe opérations devant les dashboards de supervision et le chronométrage de chaque phase de la séquence de reprise.

La plupart des organisations ne le font pas chaque année. Beaucoup ne l’ont jamais fait. L’argument contre le test est le risque : un test de failover pourrait lui-même causer une indisponibilité non planifiée si quelque chose se passe mal. Cet argument est réel. Mais l’argument inverse est plus fort : découvrir une configuration de failover cassée pendant un incident de production réel, sans fenêtre de maintenance, sous pression, avec des utilisateurs impactés, est bien pire que de la découvrir pendant un test contrôlé, quand vous avez le temps de corriger.

Ce qu’un test HA réaliste doit couvrir

Un test HA utile ne se limite pas à vérifier que le nœud HANA secondaire prend le relais après l’arrêt du primaire. Il teste toute la séquence de reprise et mesure chaque phase.

• Temps entre la panne du primaire et la détection par Pacemaker : devrait être inférieur à 30 secondes avec une configuration standard.
  
• Temps entre la détection et la finalisation de STONITH : confirme que le mécanisme de fencing fonctionne.
  
• Temps entre le fencing et la promotion du secondaire : phase de takeover HANA, généralement entre 30 et 90 secondes selon le volume de delta logs.
  
• Temps entre la promotion du secondaire et la première connexion utilisateur réussie : inclut la reconnexion du serveur applicatif et l’enregistrement auprès du message server.
  
• Comportement de l’ERS : confirmer que les utilisateurs ayant des sessions actives au moment de la panne peuvent poursuivre leurs transactions sans erreur de session après reconnexion.
  
• Livraison des alertes : confirmer que le système de supervision a détecté la panne et routé la bonne alerte vers la bonne équipe dans le délai attendu.

Ce dernier point mérite d’être souligné. Un test HA qui n’inclut pas la vérification de la supervision est incomplet. Le cluster peut récupérer en 90 secondes, mais si l’équipe opérations découvre la panne en lisant un e-mail 20 minutes plus tard, le MTTR effectif de cet incident inclut l’écart de détection. La supervision n’est pas séparée de l’architecture HA. C’est la couche qui détermine si l’architecture fonctionne comme prévu lorsqu’un problème survient réellement.

La supervision comme composant fonctionnel de l’architecture SAP haute disponibilité

Les documents d’architecture HA s’arrêtent généralement à la couche infrastructure : configuration du cluster, mode de réplication, setup du fencing. La couche de supervision est souvent traitée séparément, dans une autre section de la documentation d’architecture, par une autre équipe.

Cette séparation crée un problème pratique. Lors d’un vrai failover, le système de supervision est la principale source de vérité sur ce qui se passe et à quelle vitesse. S’il indique qu’un takeover HANA est en cours, l’équipe opérations sait qu’elle ne doit pas redémarrer les services manuellement. S’il indique que la promotion de l’ERS échoue, elle sait où concentrer ses efforts. S’il montre que l’alerte a été déclenchée 40 secondes après la détection de la panne, 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 supervision détecte aussi les modes de panne que l’architecture HA ne gère pas : les dégradations de performance qui précèdent une panne de nœud, la saturation des work processes qui rend le système indisponible sans événement infrastructure, ou le job en arrière-plan qui tourne à 200 % de sa durée normale et risque de manquer une échéance métier nécessitant une remédiation manuelle. Aucun de ces cas ne déclenche un événement Pacemaker. Tous affectent la continuité d’activité.

Une architecture SAP haute disponibilité bien conçue précise ce que la couche de supervision doit observer, à quelle fréquence et avec quel routage d’alerte. Elle ne laisse pas la supervision comme une réflexion de dernière minute, configurée par la personne disponible après le go-live. Les deux conceptions ne sont pas séparées : l’une protège l’infrastructure, l’autre apporte la visibilité qui rend cette protection exploitable.

Les modèles qui tiennent vraiment

La haute disponibilité SAP n’est pas une configuration que l’on paramètre une fois avant de l’oublier. C’est un système de composants interdépendants, dont chacun peut s’éloigner de son état prévu avec le temps, et dont chacun doit être vérifié périodiquement pour confirmer qu’il fait toujours ce que le document d’architecture affirme.

Les modèles qui tiennent sous la pression réelle de la production ont plusieurs points communs. Ils séparent la HA du DR par conception, et non par hypothèse. Ils protègent la couche Enqueue avec la même rigueur que la couche HANA, car la perte d’une table de verrous est aussi perturbante qu’une panne de nœud de base de données. Ils testent le failover selon un calendrier, au lieu d’attendre un incident pour découvrir les failles. Et ils traitent la supervision non comme un ajout, mais comme une exigence structurelle : la couche qui transforme une capacité HA théorique en capacité opérationnelle.

Les configurations qui échouent sous pression sont celles où chaque composant individuel a été correctement installé, mais où les interactions entre composants n’ont jamais été validées comme un système complet. Le cluster HANA est prêt. L’ERS est configuré. La supervision fonctionne. Mais l’ERS n’a jamais été enregistré dans Pacemaker, le seuil de supervision pour le takeover HANA est réglé trop bas et génère des faux positifs, et le test de failover a été planifié deux fois puis annulé parce que la production était trop chargée.

Ce n’est pas une configuration HA. C’est un ensemble de composants HA qui n’ont pas été assemblés en un système fonctionnel. La différence devient évidente à 03:00 un lundi matin, lorsque le nœud primaire tombe.

Redpeaks supervise en temps réel le statut de SAP HANA System Replication, la santé du cluster Pacemaker, la disponibilité des serveurs applicatifs et l’état de l’ERS, avec des alertes qui couvrent les phases de transition d’un failover, pas seulement les métriques en régime stable.

Voir les détails de couverture de supervision