SAP HANA High Availability Disaster Recovery

geschrieben von
Jaroslaw Zdanowski
Alle SAP-Systeme funktionieren auf Basis einer Datenbank, in der alle erfassten Informationen gespeichert und vom SAP-System verarbeitet werden. Angesichts der zahlreichen Bedrohungen und Zufallsereignisse ist die Absicherung der Funktion der SAP-Systeme ein ausgesprochen wichtiger Aspekt. Das bedeutet, dass an erster Stelle die kritischsten Elemente einer Umgebung abgesichert werden müssen, also die bereits erwähnte Datenbank.

Bei der Plattform SAP HANA geschieht dies mit SAP Disaster Recovery (HADR). Die meisten erfahrenen Benutzer von Unternehmenstechnologien sind sich dessen bewusst, dass Maschinen unzuverlässig sein können. Werden sensible Informationen nur auf einem Server gespeichert und wird dieser Server körperlich beschädigt (Brand, Kurzschluss, Ausfall), kann das zum Stopp oder zu einer Beschädigung der Datenbank führen, was wiederum einen Geschäftsstillstand bedeutet, welcher mit reellen finanziellen Verlusten und der Beeinträchtigung des Vertrauens der Kunden verbunden sein kann. Eben darum hat die deutsche SAP die Lösung HADR entwickelt, die vor den unerwünschten Folgen von Serverproblemen schützen soll.

Wie funktioniert das?

Ganz einfach. Die Lösung HADR basiert auf mindestens zwei Servern, zwischen denen eine Datenreplikation erfolgt. Diese Server können (und sollten sogar) voneinander entfernt und nicht an demselben Ort stehen. Wenn es am Hauptstandort zu einer Funktionsstörung kommt – durch einen Stromausfall, einen Brand oder ein anderes unerwünschtes Ereignis – schaltet das SAP-System automatisch auf den Ersatzserver um und greift auf die von der Plattform SAP HANA replizierte Datenbank zu. Der gesamte Prozess kann voll automatisch ablaufen und für das Geschäft des Kunden praktisch unmerklich sein.

Vorteile:

• Die Kontinuität der Geschäftstätigkeit des Kunden ist gewährleistet.
• Es kommt zu keinem Datenverlust.
• Die Wiederherstellung von Datenbanken an einem anderen Standort aus den Dateien einer Ersatzkopie ist unnötig.
• Die Firma erleidet keine finanziellen Folgen verbunden mit der Nichtverfügbarkeit ihrer Schlüsselsysteme, z.B. Verkaufssysteme.

Drei Wege zur Implementierung von HADR

Die Firma SAP kommt den Erwartungen ihrer Kunden entgegen, indem sie ihnen ermöglicht, ihre Lösungen auch bei einem begrenzten Budget zu nutzen und ihre Umgebung entsprechend den wachsenden Anforderungen in Bezug auf die Datensicherheit auszubauen.
Die Grundkonfiguration der Lösung HADR sollte aus zwei voneinander abgesonderten Servern mit der Plattform SAP HANA bestehen. Einer dieser Server dient für den laufenden Betrieb des SAP-Systems. Der andere ist ein Ersatzserver, auf dem die Plattform SAP HANA im Standby-Modus läuft. Zwischen den Servern ist eine Echtzeit-Replikation konfiguriert, so dass die Daten im Standby-System zum Zeitpunkt eines Ausfalls des Hauptservers aktuell sind und so die Kontinuität der Geschäftstätigkeit gewährleistet ist.

Budgetversion

Jede SAP-Umgebung muss aus mindestens zwei Systemen bestehen: einem Entwicklungs- und Testsystem sowie einem Produktionssystem. Eine optimale Lösung ist ein zusätzliches drittes System – ein Testsystem. In Bezug auf SAP HANA bringt das die Implementierung von mindestens 2 getrennten Datenbankservern mit sich. Auch in diesem Szenario kann man die Lösung SAP HANA High Availability Disaster Recovery nutzen. Der Entwicklungs- und Testserver kann als Ersatzserver für die Produktionsumgebung eingesetzt werden. In diesem Fall empfiehlt es sich, um die Hochverfügbarkeit der Lösung zu wahren, die Nichtproduktionssysteme an einem anderen Standort zu installieren als die Produktionssysteme. Die Daten werden in Echtzeit in die Standby-Datenbanken kopiert, ähnlich wie bei dem klassischen Szenario mit einem Produktionsserver und einem dedizierten Ersatzserver.
Bei Ausfall des Hauptproduktionssystems muss dieses vor dem Umschalten auf das in der Entwicklungs- und Testumgebung untergebrachte Sekundärsystem ausgeschaltet werden, um die entsprechenden, für die Funktion des Reserve-Produktionssystems notwendigen Ressourcen zu gewährleisten.

Mit dieser Lösung können die Implementierungskosten gesenkt und die Gerätearchitektur in Zukunft aufrechterhalten werden, bei gleichzeitiger Gewährleistung von Sicherheit, einer hohen Verfügbarkeit und, vor allem, der Geschäftskontinuität.

Optimale Version:

Wenn eine komplexe Absicherung der auf die Plattform SAP HANA gestützten SAP-Systeme gefordert ist, besteht die Möglichkeit, die Gerätearchitektur um weitere Ersatzserver zu erweitern, die in Echtzeit von anderen Ersatzservern repliziert werden können.

Bei diesem Szenario kann das Geschäft sogar bei Ausfall zweier Datenbankserver fortgeführt werden, da das SAP-System für die Benutzer über die anderen Ersatzserver weiterhin verfügbar ist.

HANA 2.0

Die Firma SAP entwickelt ihre Produkte ständig, insbesondere die Plattform SAP HANA. Die Plattform SAP HANA 2.0 bringt viele Verbesserungen, einschließlich im Bereich der Hochverfügbarkeit.
Die wichtigste und gleichzeitig gefragteste Funktionalität ist die neue Option Active/Active Read-Enabled. Bisher wurde die Rechenleistung des Ersatzservers nicht ausgenutzt, erst wenn eine Störung eintrat und der Standby-Server die Rolle des Hauptdatenbankservers des SAP-Systems übernahm. Das hat sich mit der Ankunft von SAP HANA 2.0 geändert. Die vom Produktionsserver replizierten Daten können nun für die Geschäftsanalytik oder auch die Berichterstellung auf dem Ersatzserver genutzt werden. Ein weiterer Vorteil dieser Lösung ist die Tatsache, dass der Hauptserver mit der Übertragung der Analysen auf den Ersatzserver entlastet wird und zusätzliche Rechenleistung für das SAP-System bietet.

Benötigen Sie eine maßgeschneiderte Lösung?
Jarosław Zdanowski
SAP BASIS Consultant, Hicron

Diese Seite verwendet Cookies. Durch die weitere Nutzung dieser Website stimmen Sie unserer Datenschutzerklärung zu.

Ok, ich stimme zu