SAP HANA Hochverfügbarkeit mit SUSE Pacemaker

1. Architektur-Überblick

Ein typisches 2-Knoten-Setup besteht aus zwei SAP-HANA-Instanzen derselben Version und SID, die per SAP HANA System Replication (synchroner Modus für minimalen Datenverlust) miteinander verbunden sind. Pacemaker übernimmt als Cluster-Resource-Manager die Überwachung und steuert im Fehlerfall den automatischen Takeover auf das Sekundärsystem; Corosync stellt die Cluster-Kommunikation zwischen den Knoten sicher.

Da ein 2-Knoten-Cluster allein kein zuverlässiges Mehrheitsvotum bilden kann, braucht er einen Fencing-/STONITH-Mechanismus, der einen nicht mehr erreichbaren Knoten zuverlässig isoliert oder abschaltet – sonst droht ein Split-Brain, bei dem beide Knoten sich für primär halten.

2. Voraussetzungen

• SLES for SAP Applications auf beiden Knoten, identische SAP-HANA-Version und SID.
• Separates, redundantes Netzwerk für die Cluster-Kommunikation, getrennt vom HANA-Replikationsnetzwerk, wo möglich.
• Zeitsynchronisation (NTP/Chrony) auf beiden Knoten.
• Ein zur Plattform passender Fencing-Mechanismus (z. B. SBD bei On-Premises/VMware, cloud-spezifischer Fencing-Agent bei Azure/AWS/GCP).
• Namensauflösung beider Knoten in /etc/hosts oder DNS.

3. HA-Pakete installieren

Auf beiden Knoten das High-Availability-Pattern sowie den SAP-HANA-spezifischen Resource Agent installieren:

# HA-Extension-Pattern
zypper install -t pattern ha_sles

# SAP-HANA-Resource-Agent inkl. Doku
zypper install SAPHanaSR SAPHanaSR-doc

4. Cluster-Basis einrichten

Auf dem ersten Knoten den Cluster initialisieren, auf dem zweiten beitreten:

ha-cluster-init

ha-cluster-join -c <node-a-hostname>

Status danach mit crm status prüfen – beide Knoten sollten als „online" erscheinen.

5. SAP HANA System Replication konfigurieren

Vor der Cluster-Integration muss die HANA-Replikation zwischen den Instanzen stehen. Auf dem primären Knoten die Replikation aktivieren, auf dem sekundären registrieren:

hdbnsutil -sr_enable --name=SITE_A

HDB stop
hdbnsutil -sr_register --name=SITE_B \
  --remoteHost=<node-a-hostname> --remoteInstance=<nr> \
  --replicationMode=sync --operationMode=logreplay
HDB start

Replikationsstatus auf dem primären Knoten prüfen:

python systemReplicationStatus.py

6. Cluster-Ressourcen definieren

Die beiden SAPHanaSR-Ressourcen anlegen: SAPHanaTopology als Clone-Set auf beiden Knoten, SAPHana als Promotable/Master-Slave-Ressource, die den aktiven Primary kennt. Vereinfacht (Parameter projektabhängig):

# Topology-Ressource als Clone auf beiden Knoten
crm configure primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600"
crm configure clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
  meta clone-node-max="1" interleave="true"

# Promotable HANA-Ressource (Master/Slave)
crm configure primitive rsc_SAPHana_HA1_HDB00 ocf:suse:SAPHana \
  params SID="HA1" InstanceNumber="00" \
  op monitor interval="61" role="Slave" timeout="700" \
  op monitor interval="59" role="Master" timeout="700"
crm configure ms msl_SAPHana_HA1_HDB00 rsc_SAPHana_HA1_HDB00 \
  meta clone-node-max="1" master-max="1" interleave="true"

Reihenfolge- und Kolokations-Constraints stellen sicher, dass Topology vor der HANA-Ressource startet und beide auf denselben Knoten „gehören".

7. Fencing / STONITH

Ohne funktionierendes Fencing ist ein HA-Cluster nicht produktionstauglich. Je nach Plattform:

• On-Premises/VMware: SBD (STONITH Block Device) über ein gemeinsames Shared-Storage-Device.
• Azure/AWS/GCP: cloud-spezifischer Fencing-Agent, der über die jeweilige Cloud-API einen Knoten neu starten oder isolieren kann.

8. Virtuelle IP-Ressource

Eine virtuelle IP-Adresse, die Applikationen als Verbindungsziel nutzen, folgt per Kolokations-Constraint immer dem aktiven Primary:

crm configure primitive rsc_ip_HA1_HDB00 ocf:heartbeat:IPaddr2 \
  params ip="10.0.0.50" cidr_netmask="24"
crm configure colocation col_ip_with_master inf: \
  rsc_ip_HA1_HDB00 msl_SAPHana_HA1_HDB00:Master

9. Test & Betrieb

Vor Produktivbetrieb mindestens folgende Szenarien kontrolliert durchspielen:

1. Kontrollierter Takeover: crm resource move bzw. SAPHanaSR-eigene Takeover-Prozedur.
2. Harter Node-Ausfall (z. B. Stromausfall simulieren) – greift das Fencing wie erwartet?
3. Netzwerktrennung zwischen den Knoten (Split-Brain-Simulation).

Im laufenden Betrieb Status und Replikation regelmäßig prüfen:

crm status
SAPHanaSR-showAttr

Für geplante Wartung lässt sich der Primary kontrolliert auf das Sekundärsystem „umschalten", patchen, und anschließend zurückschalten – das ist das downtime-minimierte Patchmuster, mit dem sich SAP-HANA-Updates nahezu ohne Ausfallzeit einspielen lassen.

Quellen & weiterführende Dokumentation

Diese Seite fasst das allgemein bekannte Standard-Vorgehen zusammen und ersetzt keine aktuelle Herstellerdokumentation. Maßgeblich für die produktive Umsetzung: