HANA Hochverfügbarkeit durch System-Replikation

SAP HANA wird mehr und mehr die Datenbank der Wahl für Organisationen mit Mission Critical-Systemen. Vertraglich vereinbarte SLAs erhöhen die Wichtigkeit, dass diese Systeme jederzeit in Betrieb und verfügbar sind. SAP HANA bietet einige Mechanismen um die Verfügbarkeit zu sichern:

• Storage Replication - Die Daten werden bei diesem Verfahren durch Spiegelung der Speicherarchitektur repliziert, unabhängig von der Datenbank-Software selbst. Festplatten werden dabei ohne einen Kontrollprozess in SAP HANA gespiegelt. Solche Lösungen stellt üblicherweise der Hardware-Anbieter bereit.
• Host Auto-Failure - Im Fehlerfalle werden hierbei die Data- und Log-Volumes von einem Hot Standby-System übernommen.
• SAP HANA System Replication - In diesem Szenario repliziert SAP HANA permanent alle Daten auf ein sekundäres SAP HANA-System.

In diesem Artikel werden wir SAP HANA System Replication näher betrachten und aufzeigen, wie die Überwachung mittels syslink Xandria sicherstellt, dass die Daten-Replizierung einwandfrei funktioniert und zur Verfügung steht, sollte sie einmal gebraucht werden.

SAP HANA System Replication

Die SAP HANA System Replication wird druch den SAP HANA Datenbank-Kernel gesteuert. Benötigt werden dazu zwei separate Systeme mit der exakt gleichen Anzahl aktiver HANA-Nodes. Sobald die Replikation zwischen den beiden HANA-Systemen eingerichtet ist, wir eines als Primary- und das andere als Secondary-System definiert.

Dann werden zunächst alle Daten aus dem Primary-System in das Secondary-System repliziert, um eine initiale Baseline zu erzeugen. Und schliesslich werden alle Datenänderungen am primären HANA-System kontinuierlich auf das Secondary-System übertragem, dort jedoch noch nicht eingespielt. In ähnlicher weise sendet der Mechanismus in vordefinierten Zeitabschnitten Daten-Snapshots vom primären auf das sekundäre HANA-System.

Im Falle eines Fehlers beim Primary-System, in dem das Secondary-System die Funktion übernehmen muss, kommt der letzte Snapshot zur Anwendung, und die Logs seit dem letzten Snapshot werden eingespielt. Zusammen mit dem Daten-Snapshot sendet das Primary-System auch Informationen über die in den Hauptspeicher geladenen Tabellen, falls der Parameter 'preload_column_tables' auf 'true' gesetzt ist. Wenn dieser Parameter auch auf dem Secondary-System auf 'true' gesetzt ist, lädt dieses die Tabellen ebenfalls in den Hauptspeicher. Dadurch reduziert sich die Recovery-Zeit und bietet für das gesamte SAP HANA-System hinsichtlich Recovery eine deutlich schnellere Hochverfügbarkeitslösung.

Seit dem SPS11 gibt es zwei verschiedene Betriebsmodi für die HANA-Replikation. Der erste, delta_datashipping, verhält sich ähnlich wie in den früheren Versionen der HANA-Replikation mit zusätzlicher Übertragung der Deltas alle 10 Minuten. Diese zusätzlichen Deltas werden kontinuierlich auf den intialen Snaphsot aufgesetzt, damit im Failover-Falle weniger Logs eingespielt werden müssen und sich die Recovery-Zeit reduziert. Der zweite Betriebsmodus, log_replay, vewendet die ursprüngliche HANA System-Replikation mit einem Snapshot und den versendeten Logs. Der Unterschied ist, dass die Logs sofort auf dem Secondary-System eingespielt werden. So entsteht eine Near High Availability-Lösung, oder ein Hot Standby-Szenario.

Dazu kommen noch weitere Synchronisations-Modi, unter anderem Synchronous on Disk, Synchronous in Memory, Asynchronous und Full Sync. Mehr dazu finden Sie in dieser technischen Dokumentation von SAP.

Herausforderungen beim Monitoring von HANA-Replikation

Das Eintreten einer Disaster-Recovery-Situation versetzt SAP Support-Teams in eine Stress-Situation. Obwohl der Betrieb "wasserdicht" aussieht, kann es einige Sorgen bereiten, die Übertragung aller Logs sicherzustellen. Bereites ein fehlendes Log wird ziemlich sicher zu unerwünschtem Verhalten führen wenn man versucht, das Secondary-System zu verwenden. Ohne gute Überwachungslösung lässt sich nicht eindeutig feststellen, ob alle nötigen Daten vorhanden sind, bevor Sie versuchen das Secondary-System zu verwenden. Support-Teams setzen üblicherweise die Replikation auf, hoffen, dass der Prozess erfolgreich läuft und beten, dass das Secondary-System nie benutzt wird. Obwohl es Best Practice wäre, einmal pro Jahr den Disaster-Recovery-Fall zu testen, bedeutet dies in der Praxis das Anfordern von Wartungsfenstern und eine Menge Koordinations-Aufwand. Der Test ist oftmals nicht wirklich erfolgreich oder dauert deutlich länger als angenommen. All das führt dazu, dass Disaster-Recovery-Tests auf die lange Bank geschoben werden oder gänzlich in Vergessenheit geraten.  

Wie Xandria diese Herausforderungen meistert

Mit Xandria hofft Ihr IT-Team nicht nur, dass die System-Replikation funktioniert, das Team weiss es. Xandria kann potenzielle zukünftige Fehler im Replikationsprozess klar identifizieren und erlaubt Ihrem Team diese zu beheben, damit Sie auf das Secondary-System zurückgreifen können, sollte dies tatsächlich notwendig werden.

Xandria liefert auf einen Blick die vollständige Übersicht über den Replikationsprozess und hilft damit sicherzustellen, dass dieser Prozess heute und in der Zukunft verlässlich ausgeführt wird. Disaster-Recovery-Situationen, ob real oder nur im Test, erzeugen genug Stress für SAP Support-Teams. Xandria gibt jedem Support-Team die Zuversicht, dass im Falle eines Disaster-Recovery alle Komponenten betriebsbereit und das Secondary-System einsatzfähig ist.