SAP High Availability Architektur: Muster, die unter echtem Produktionsdruck halten

Die gefährlichste SAP High Availability Konfiguration ist die, die nie getestet wurde. Im Architekturdiagramm sieht sie korrekt aus, sie hat den Go-live Review bestanden, und alle im Team sind ziemlich sicher, dass sie funktionieren würde, wenn etwas schiefgeht. Aber sie ist nie tatsächlich umgeschaltet worden. Deshalb weiß niemand mit Sicherheit, ob das sekundäre System in 90 Sekunden oder in 25 Minuten übernimmt, ob sich der Enqueue Replication Server nach einem Ausfall des primären Knotens sauber wieder verbindet, oder ob das Monitoring-Team eine Warnung erhält, bevor die Nutzer anfangen anzurufen.

Dieser Artikel behandelt die Architektur-Patterns, die wirklich standhalten, wenn Produktionssysteme ausfallen, nicht die, die in Herstellerpräsentationen gut aussehen. Er setzt voraus, dass Sie wissen, was SAP HANA System Replication ist. Ziel ist es, die konkreten Entscheidungen und Fehlkonfigurationen zu beleuchten, die darüber entscheiden, ob Ihr HA-Setup einen realen Ausfall übersteht.

Wovor eine SAP High Availability Architektur wirklich schützen muss

Der Unterschied zwischen HA und DR, und warum ihre Vermischung Lücken schafft

High Availability und Disaster Recovery sind unterschiedliche Probleme mit unterschiedlichen Lösungen. SAP-Teams, die beides gut beherrschen, behandeln sie von Anfang an als getrennte Designfragen. HA bedeutet, den Service am Laufen zu halten, wenn eine einzelne Komponente ausfällt: ein Datenbankknoten, ein Applikationsserver, eine Netzwerkverbindung. Das Wiederherstellungsziel liegt bei Minuten. Der geografische Umfang liegt typischerweise innerhalb eines einzelnen Rechenzentrums oder zwischen zwei Standorten mit niedriger Latenz.

Disaster Recovery bedeutet, den Service nach einem Ereignis auf Standortebene wiederherzustellen: Stromausfall im Rechenzentrum, größerer Hardwarevorfall, regionaler Netzwerkausfall. Das Wiederherstellungsziel liegt bei Stunden. Der geografische Umfang erfordert physische Distanz, was in der Regel asynchrone Replikation bedeutet, da synchrone Replikation über große Entfernungen Schreiblatenz erzeugt, die produktive HANA-Systeme nicht auffangen können.

Die teuerste Lücke entsteht oft, wenn Unternehmen versuchen, ein einziges System für beide Aufgaben zu entwerfen. Ein HANA System Replication Setup im synchronen Modus zwischen zwei Racks im selben Rechenzentrum liefert HA, aber kein DR. Ein Setup im asynchronen Modus zwischen zwei 500 km voneinander entfernten Rechenzentren liefert DR, akzeptiert aber potenziellen Datenverlust. Ein mehrstufiges Replikationssetup mit einem synchronen sekundären System in der Nähe und einem asynchronen tertiären System in der Ferne liefert beides, ist aber komplexer zu betreiben und zu testen. Wer vor der Replikationskonfiguration weiß, für welches Szenario er entwirft, vermeidet die teure Erkenntnis, dass der DR-Plan Fähigkeiten vorausgesetzt hat, die die HA-Konfiguration gar nicht bereitstellt.

Ausfallarten, die Standard-HA-Konfigurationen übersehen

Ein Failover eines Datenbankknotens ist das Ausfallszenario, für das jede SAP High Availability Konfiguration ausgelegt ist. Gleichzeitig gehört es in einer gut gewarteten Umgebung zu den seltensten Ausfallarten. Die Ausfälle, die in der Produktion tatsächlich Downtime verursachen, sind meist gewöhnlicher und vielfältiger: Sättigung einer Netzwerkschnittstelle zwischen Applikations- und Datenbankschicht, Storage-I/O-Degradation mit Auswirkungen auf die HANA Log Writes, ein Hintergrundjob, der Work Processes über alle Applikationsserverinstanzen hinweg monopolisiert, oder eine Konfigurationsänderung, die nicht zuerst in einer Nicht-Produktionsumgebung getestet wurde.

Standard-HA-Architektur schützt vor keinem dieser Fälle. Ein HANA-Cluster mit zwei Knoten und Pacemaker behandelt den Ausfall eines Datenbankknotens. Er hilft nicht, wenn das Problem in der Applikationsserver-Schicht liegt. Er hilft auch nicht, wenn alle Applikationsserver erreichbar sind, der HANA-Primärserver aber durch eine ausufernde analytische Abfrage so stark ausgelastet ist, dass Dialogtransaktionen Timeouts erzeugen.

Das ist für Architekturentscheidungen entscheidend, weil Teams, die ausschließlich für Knotenausfälle planen, eine robuste Reaktion auf genau einen Ausfallmodus erhalten und für die anderen keine Abdeckung haben. Ein vollständiger HA-Ansatz berücksichtigt neben dem Datenbankcluster auch die Applikationsschicht, die Integrationsschicht und die Monitoring-Infrastruktur.

Die SAP HANA Schicht: System Replication richtig umsetzen

Synchrone oder asynchrone Replikation: die Entscheidung, die Ihr RPO festlegt

SAP HANA System Replication arbeitet in drei Modi. Die Wahl zwischen ihnen ist keine Geschmacksfrage. Sie bestimmt direkt Ihr Recovery Point Objective und hat messbare Auswirkungen auf die Schreibleistung des Primärsystems.

SYNC ist die richtige Wahl für primäre HA innerhalb eines Rechenzentrums oder zwischen Standorten, die über ein Netzwerk mit einer Roundtrip-Latenz unter 1 ms verbunden sind. Die Performance-Auswirkung ist real, aber begrenzt, und es ist der einzige Modus, der bei einem Failover null Datenverlust garantiert. SYNC über eine WAN-Verbindung mit hoher Latenz einzusetzen, erzeugt Schreiblatenz, die sich über jede bestätigte Transaktion hinweg summiert. In einem stark ausgelasteten Produktionssystem wird das für Nutzer sichtbar.

SYNCMEM ist ein sinnvoller Kompromiss, wenn die Performance-Auswirkung von SYNC messbar ist und das theoretische Risiko akzeptabel bleibt, dass Daten auf dem sekundären System noch im Speicher liegen und noch nicht auf die Festplatte geschrieben wurden. In den meisten Produktionsumgebungen ist dieses Risiko sehr klein, und SYNCMEM performt unter hoher Schreiblast spürbar besser als SYNC.

ASYNC für primäre HA ist ein überraschend häufiger Architekturfehler. Man versteht, warum er passiert: Die Konfiguration sieht identisch aus, das sekundäre System ist online, und in einer Testumgebung mit geringem Schreibvolumen ist der Replikations-Lag vernachlässigbar. Unter Produktionslast kann ASYNC-Lag während schreibintensiver Phasen auf Sekunden oder Minuten anwachsen. Ein Failover in diesem Lag-Fenster bedeutet, dass bestätigte Transaktionen auf dem Primärsystem, die das sekundäre System nie erreicht haben, dauerhaft verloren gehen.

Häufiger Fehler: ASYNC für ein HA-Sekundärsystem im selben Rechenzentrum zu nutzen, ist ein dokumentiertes Anti-Pattern. Die Performance-Einsparungen sind real, aber klein. Das Risiko von Datenverlust ist ebenfalls klein, aber nicht null. Für ein produktives Finanz- oder Logistiksystem ist dieser Trade-off nicht sinnvoll.

HANA System Replication mit Pacemaker: Konfigurationsdetails, die zählen

Pacemaker ist der Standard-Cluster-Resource-Manager für SAP HANA HA unter Linux. Er übernimmt die Erkennung von Knotenausfällen, die Failover-Sequenzierung und das Fencing, auch STONITH genannt, für Shoot The Other Node In The Head. Jede dieser drei Funktionen hat Konfigurationsdetails, die darüber entscheiden, ob ein Failover sauber abgeschlossen wird oder hängen bleibt.

Die Geschwindigkeit der Knotenausfallerkennung wird über Pacemaker Timeout- und Ping-Intervall-Einstellungen gesteuert. Die Standardwerte sind konservativ. Das bedeutet, dass ein ausgefallener Knoten bei Standardeinstellungen möglicherweise erst nach 30 bis 60 Sekunden erkannt wird. Für Umgebungen mit aggressiven RTO-Zielen müssen diese Werte nach unten angepasst werden, aber das erfordert sorgfältige Tests. Zu aggressive Erkennungsschwellen führen zu False Positives: Pacemaker erklärt einen Knoten während eines kurzen Netzwerkproblems für ausgefallen und löst einen Failover aus, der gar nicht nötig war.

Die STONITH-Konfiguration ist der Teil, der beim Setup am häufigsten wie eine Checkbox behandelt wird. Zweck des Fencings ist es sicherzustellen, dass ein Knoten, den Pacemaker für ausgefallen hält, nicht weiter auf gemeinsame Ressourcen schreiben kann, bevor das sekundäre System übernimmt. Andernfalls kann Split-Brain-Datenkorruption entstehen. In einer Virtual-Machine-Umgebung wird STONITH typischerweise über die Power-Management-API des Hypervisors umgesetzt. In einer Bare-Metal-Umgebung benötigt es ein dediziertes Out-of-Band-Management-Netzwerk und entsprechende Hardware. Umgebungen, die STONITH deaktivieren, weil es schwer zu konfigurieren ist, akzeptieren Split-Brain-Risiko im Austausch für ein einfacheres Setup. Das ist kein Trade-off, den man für produktive HA eingehen sollte.

Hinweis: SAP Note 1984787 behandelt die Konfigurationsanforderungen für SUSE Linux Enterprise Server bei SAP HANA HA mit Pacemaker. SAP Note 2578899 behandelt das entsprechende Thema für Red Hat Enterprise Linux. Beide sind Pflichtlektüre vor dem produktiven Deployment, keine optionalen Referenzen.

Mehrstufige Replikation: wenn Sie sowohl HA als auch DR brauchen

HANA System Replication unterstützt Chaining: Ein Primärsystem repliziert synchron auf ein lokales Sekundärsystem für HA, und dieses Sekundärsystem repliziert asynchron auf ein entferntes Tertiärsystem für DR. Diese Konfiguration bietet ein nahezu null RPO für lokale Ausfälle und ein DR-Ziel, das etwas Datenverlust akzeptiert, dafür aber geografische Trennung gewährleistet.

Die operative Komplexität mehrstufiger Replikation ist höher als bei einstufiger Replikation. Nach einem Primärausfall und einem HA-Failover ist das alte Sekundärsystem jetzt das neue Primärsystem, und das Tertiärsystem muss neu ausgerichtet werden, damit es von diesem System repliziert. Dieses Repointing ist standardmäßig nicht automatisch. Es erfordert entweder manuelle Intervention oder ein individuelles Automatisierungsskript als Teil des Failover-Runbooks. Teams, die mehrstufige Replikation einsetzen, ohne das DR-Repointing zu dokumentieren und zu testen, haben eine Konfiguration, die für den ersten Ausfallmodus funktioniert, sie aber während eines aktiven Incidents dazu zwingt, die DR-Kette manuell wieder zusammenzusetzen.

High Availability für Applikationsserver: die Schicht, die zu wenig Aufmerksamkeit bekommt

Der Enqueue Replication Server: die am häufigsten falsch konfigurierte SAP HA Komponente

Der SAP Enqueue Server verwaltet das Lock Management für die ABAP-Applikation. Er ist ein einzelner Prozess. In einer Standardinstallation ohne HA-Konfiguration läuft der Enqueue Server auf einer Applikationsserverinstanz. Wenn diese Instanz ausfällt, gehen alle Locks verloren. Nutzer erhalten einen Session-Fehler, laufende Transaktionen können nicht bestätigt werden, und das System muss faktisch neu gestartet werden, um die Lock-Tabelle zu bereinigen.

Der Enqueue Replication Server, ERS, löst dieses Problem, indem er eine replizierte Kopie der Lock-Tabelle auf einer zweiten Instanz hält. Wenn der primäre Enqueue Server ausfällt, promoted sich der ERS, und die Lock-Tabelle bleibt erhalten. Der Failover ist in den meisten Fällen für Nutzer transparent.

Die Konfigurationslücke, die in Produktionsumgebungen immer wieder auftaucht, ist ein ERS-Setup, das technisch vorhanden, aber nicht korrekt mit Pacemaker integriert ist. Die ERS-Instanz existiert und repliziert die Lock-Tabelle, aber Pacemaker kennt sie nicht. Ein Knotenausfall, der den primären Enqueue Server herunterzieht, löst deshalb keine automatische ERS-Promotion aus. Die Lock-Tabelle ist repliziert, aber nicht aktiviert. Das Ergebnis ist dieselbe Downtime, als wäre ERS gar nicht konfiguriert worden.

Die Überprüfung der ERS-Pacemaker-Integration sollte Teil jeder HA-Konfigurationsprüfung sein. Der Test ist einfach: Simulieren Sie einen Ausfall des Knotens, auf dem der primäre Enqueue Server läuft, und bestätigen Sie, dass der ERS sauber promoted und Nutzer mit aktiven Sessions ihre Transaktionen fortsetzen können. Wenn dieser Test nicht durchgeführt wurde, ist die ERS-Konfiguration nicht verifiziert.

In der Praxis: In Umgebungen, in denen der Enqueue Server auf demselben Knoten wie das HANA-Primärsystem läuft, legt ein einzelner Knotenausfall gleichzeitig die Datenbank und das Lock Management lahm. Werden Enqueue Server und HANA-Primärsystem auf getrennte physische oder virtuelle Hosts gelegt, erzeugt ein Datenbankknotenausfall nicht automatisch ein Lock-Table-Ereignis in der Applikationsschicht.

Applikationsserverinstanzen verteilen, ohne neue Ausfallarten zu schaffen

Mehrere SAP Dialoginstanzen über mehrere Applikationsserver hinweg zu betreiben, ist der Standardansatz für Verfügbarkeit auf Applikationsebene. Wenn eine AS-Instanz ausfällt, verbinden sich Nutzer über den Message Server erneut mit einer anderen verfügbaren Instanz. Für zustandslose Operationen funktioniert das zuverlässig.

Die Ausfallart, gegen die mehrere AS-Instanzen nicht schützen, ist die gleichzeitige Sättigung des Work-Process-Pools über alle Instanzen hinweg. Wenn ein ausufernder Batchjob oder ein schlecht optimierter Report Background- oder Dialog-Work-Processes auf jedem verfügbaren Applikationsserver monopolisiert, ist das System effektiv nicht verfügbar, obwohl keine Instanz ausgefallen ist. HA-Architektur auf Infrastrukturebene adressiert dieses Problem nicht.

Auch die Work-Process-Verteilung erfordert, dass der Message Server, der das Load Balancing zwischen Applikationsserverinstanzen übernimmt, selbst geschützt ist. In den meisten produktiven Deployments läuft der Message Server als Komponente der primären Applikationsserverinstanz. Ein Ausfall dieser Instanz legt sowohl die Dialogprozesse als auch die Routing-Schicht lahm. Den Message Server auf einer dedizierten Instanz mit eigener Failover-Konfiguration zu betreiben, erhöht die Komplexität, beseitigt aber in stark ausgelasteten Umgebungen einen relevanten Single Point of Failure.

High Availability in Cloud- und Hybridumgebungen

Was sich ändert, wenn SAP auf einem Hyperscaler läuft

Die grundlegenden HA-Konzepte für SAP auf AWS, Azure oder GCP sind dieselben wie on-premise: HANA System Replication, Pacemaker, ERS, mehrere AS-Instanzen. Was sich ändert, ist die Infrastrukturschicht, auf der diese Komponenten laufen, und diese Schicht bringt sowohl neue Möglichkeiten als auch neue Einschränkungen mit sich.

Availability Zones bei Hyperscalern bieten physische Trennung innerhalb einer Region. Die Platzierung von primären und sekundären HANA-Knoten in getrennten AZs schützt vor einem Ausfall auf Zonenebene. Die praktische Einschränkung ist die Netzwerklatenz. Die AZ-zu-AZ-Latenz innerhalb einer einzelnen Region liegt typischerweise zwischen 1 ms und 2 ms. Das liegt im Bereich, in dem HANA SYNC Replikation machbar ist, aber näher an der Schwelle, an der schreibintensive Workloads messbare Auswirkungen zeigen. Die Replikationsperformance unter einer produktionsnahen Schreiblast zu testen, bevor man sich auf eine Cross-AZ-SYNC-Konfiguration festlegt, ist ein notwendiger Schritt, kein optionaler.

Hyperscaler behandeln STONITH auch anders als On-Premise-Umgebungen. Hardwarebasiertes IPMI/BMC-Fencing, das auf Bare Metal Standard ist, steht im Kontext virtueller Maschinen nicht zur Verfügung. Cloud-native STONITH-Agents verwenden die Instance-Management-APIs des Hyperscalers, um einen Zielknoten auszuschalten. Diese Agents sind gut getestet und zuverlässig, benötigen aber korrekt konfigurierte IAM-Berechtigungen. Diese Berechtigungen müssen vor einem realen Failover-Szenario überprüft werden, nicht währenddessen.

RISE with SAP und die Monitoring-Grenze

RISE with SAP verlagert Infrastrukturmanagement und grundlegende Plattformoperationen zu SAP und zum zugrunde liegenden Hyperscaler. Für die HA-Architektur bedeutet das konkret: SAP verwaltet die HANA-Clusterkonfiguration, das Pacemaker-Setup und den Infrastruktur-Failover für den S/4HANA-Kern. Der Kunde konfiguriert und betreibt diese Komponenten nicht direkt.

Was beim Kunden in einer RISE-Umgebung verbleibt, ist die Verantwortung für Verfügbarkeit auf Applikationsebene: Erweiterungen auf SAP BTP, Integrationen mit Nicht-SAP-Systemen, Hintergrundjobplanung, die bestimmt, ob kritische Prozesse innerhalb ihrer Zeitfenster laufen, und vor allem die Monitoring-Schicht, die sichtbar macht, ob das System aus Business-Sicht wirklich gesund ist.

Das RISE SLA von SAP deckt Infrastrukturverfügbarkeit ab. Es deckt nicht die Gesundheit von individuellem ABAP-Code ab, nicht die Erfolgsrate der Interface-Verarbeitung und nicht die Frage, ob geplante Jobs innerhalb ihrer Business-Fristen abgeschlossen wurden. Eine Organisation, die auf RISE läuft und keine unabhängige Monitoring-Schicht hat, hängt vollständig vom SAP-Supportportal ab, um Probleme auf Applikationsebene zu entdecken. Das ist eine relevante operative Lücke, unabhängig davon, was das Infrastruktur-SLA verspricht.

HA-Konfiguration testen: der Schritt, den die meisten Teams auslassen

Ein ungetesteter Failover ist ein unbekannter Failover

HA-Konfigurationen degradieren mit der Zeit, ohne dass es jemand merkt. Eine Cluster-Ressource, die beim Go-live korrekt in Pacemaker registriert war, wird verwaist, nachdem ein OS-Patch einen Servicenamen geändert hat. Ein Pacemaker Timeout, der für das ursprüngliche Hardwareprofil kalibriert wurde, passt nach einem VM-Resize nicht mehr. Eine ERS-Instanz, die nach dem initialen Setup verifiziert wurde, wurde nach einem größeren SAP-Upgrade nie erneut überprüft.

Der einzige Weg zu wissen, ob ein Failover funktioniert, ist, einen durchzuführen. Nicht einen simulierten Failover in einer Sandbox mit einem Bruchteil der Daten. Einen echten Failover des Produktionsclusters, in einem Wartungsfenster, mit dem Operations-Team vor den Monitoring-Dashboards und mit Zeitmessung jeder Phase der Recovery-Sequenz.

Die meisten Organisationen tun das nicht jährlich. Viele haben es noch nie getan. Das Argument gegen Tests ist Risiko: Ein Failover-Test könnte selbst einen ungeplanten Ausfall verursachen, wenn etwas schiefgeht. Dieses Argument ist real. Aber das Gegenargument ist stärker: Eine kaputte Failover-Konfiguration während eines echten Produktionsincidents zu entdecken, ohne Wartungsfenster, unter Druck, mit betroffenen Nutzern, ist deutlich schlimmer, als sie während eines kontrollierten Tests zu entdecken, wenn Zeit für Korrekturen bleibt.

Was ein realistischer HA-Test abdeckt

Ein sinnvoller HA-Test prüft nicht nur, ob der sekundäre HANA-Knoten nach einem Primärshutdown übernimmt. Er testet die gesamte Recovery-Sequenz und misst jede Phase.

• Zeit vom Primärausfall bis zur Pacemaker-Erkennung: sollte bei Standardkonfiguration unter 30 Sekunden liegen
  
• Zeit von der Erkennung bis zum Abschluss von STONITH: bestätigt, dass der Fencing-Mechanismus funktioniert.
  
• Zeit vom Fencing bis zur Promotion des sekundären Systems: die HANA-Takeover-Phase, typischerweise 30 bis 90 Sekunden, abhängig vom Delta-Log-Volumen.
  
• Zeit von der Promotion des sekundären Systems bis zum ersten erfolgreichen User Login: beinhaltet die Wiederverbindung des Applikationsservers und die Registrierung am Message Server.
  
• ERS-Verhalten: bestätigen, dass Nutzer mit aktiven Sessions zum Zeitpunkt des Ausfalls ihre Transaktionen nach der Wiederverbindung ohne Session-Fehler fortsetzen können.
  
• Alarmzustellung: bestätigen, dass das Monitoring-System den Ausfall erkannt und den richtigen Alarm innerhalb des erwarteten Zeitrahmens an das richtige Team geroutet hat.

Der letzte Punkt verdient besondere Betonung. Ein HA-Test ohne Monitoring-Verifikation ist unvollständig. Der Cluster kann sich in 90 Sekunden erholen, aber wenn das Operations-Team erst 20 Minuten später durch eine E-Mail vom Ausfall erfährt, beinhaltet die effektive MTTR dieses Incidents auch die Erkennungslücke. Monitoring ist nicht von der HA-Architektur getrennt. Es ist die Schicht, die bestimmt, ob die Architektur im Ernstfall so funktioniert, wie sie entworfen wurde.

Monitoring als funktionale Komponente der SAP High Availability Architektur

HA-Architekturdokumente enden typischerweise auf der Infrastrukturebene: Clusterkonfiguration, Replikationsmodus, Fencing-Setup. Die Monitoring-Schicht wird meist separat behandelt, in einem anderen Abschnitt der Architekturdokumentation, von einem anderen Team.

Diese Trennung schafft ein praktisches Problem. Während eines echten Failovers ist das Monitoring-System die primäre Quelle der Wahrheit darüber, was passiert und wie schnell. Wenn es einen laufenden HANA-Takeover zeigt, weiß das Operations-Team, dass es Services nicht manuell neu starten sollte. Wenn es zeigt, dass die ERS-Promotion fehlschlägt, weiß das Team, worauf es sich konzentrieren muss. Wenn es zeigt, dass der Alarm 40 Sekunden nach Ausfallerkennung ausgelöst wurde, weiß es, dass die Eskalationskette funktioniert. Ohne diese Echtzeitsicht ist die Reaktion langsamer, und das Risiko steigt, dass ein manueller Eingriff die Lage verschlimmert.

Die Monitoring-Schicht erkennt außerdem Ausfallarten, die die HA-Architektur nicht abdeckt: Performance-Degradation vor einem Knotenausfall, Work-Process-Sättigung, die das System ohne Infrastrukturereignis effektiv unverfügbar macht, oder ein Hintergrundjob, der bei 200 % seiner normalen Laufzeit liegt und kurz davor ist, eine Business-Deadline zu verpassen, was manuelle Nacharbeit erforderlich macht. Nichts davon löst ein Pacemaker-Ereignis aus. Alles davon beeinträchtigt die Business Continuity.

Eine gut konzipierte SAP High Availability Architektur legt fest, was die Monitoring-Schicht beobachten muss, in welcher Frequenz und mit welchem Alarm-Routing. Sie behandelt Monitoring nicht als nachträglichen Zusatz, der nach dem Go-live von der gerade verfügbaren Person konfiguriert wird. Die beiden Designs sind nicht getrennt: Das eine schützt die Infrastruktur, das andere liefert die Sichtbarkeit, die diesen Schutz handlungsfähig macht.

Die Muster, die wirklich halten

SAP High Availability ist keine Konfiguration, die man einmal setzt und dann vergisst. Sie ist ein System voneinander abhängiger Komponenten, von denen jede mit der Zeit von ihrem vorgesehenen Zustand abweichen kann und regelmäßig überprüft werden muss, um zu bestätigen, dass sie noch das tut, was im Architekturdokument steht.

Die Muster, die unter echtem Produktionsdruck halten, haben einige Gemeinsamkeiten. Sie trennen HA und DR bewusst im Design, nicht durch Annahmen. Sie schützen die Enqueue-Schicht mit derselben Strenge wie die HANA-Schicht, weil der Verlust einer Lock-Tabelle genauso störend ist wie der Ausfall eines Datenbankknotens. Sie testen Failover nach Plan, statt auf einen Incident zu warten, um Lücken zu entdecken. Und sie behandeln Monitoring nicht als Add-on, sondern als strukturelle Anforderung: die Schicht, die eine theoretische HA-Fähigkeit in eine praktische verwandelt.

Die Konfigurationen, die unter Druck scheitern, sind die, bei denen jede einzelne Komponente korrekt installiert wurde, aber die Interaktionen zwischen den Komponenten nie als Gesamtsystem validiert wurden. Der HANA-Cluster ist bereit. ERS ist konfiguriert. Das Monitoring läuft. Aber ERS wurde nie in Pacemaker registriert, der Monitoring-Schwellenwert für HANA Takeover ist zu niedrig gesetzt und erzeugt False Positives, und der Failover-Test wurde zweimal geplant und beide Male abgesagt, weil die Produktion zu beschäftigt war.

Das ist keine HA-Konfiguration. Es ist eine Sammlung von HA-Komponenten, die nicht zu einem funktionierenden System zusammengesetzt wurden. Der Unterschied wird an einem Montag um 03:00 Uhr sichtbar, wenn der primäre Knoten ausfällt.

Redpeaks überwacht den SAP HANA System Replication Status, die Pacemaker Cluster Health, die Verfügbarkeit der Applikationsserver und den ERS-Zustand in Echtzeit, mit Alarmierung, die die Übergangsphasen eines Failovers abdeckt, nicht nur die Steady-State-Metriken.

Sehen Sie sich die Details zur Monitoring-Abdeckung an.