Pinguine auf fernsehern mit Linux als schrift

Hana-HA-Cluster-Funktionalität einfach nutzen

IT-Verantwortliche kommen um den Einsatz von Cluster-Management-Software zur Sicherung der Hana High Availability (HA) nicht umhin. Durch die bereitgestellte Automatisierung erhöhen sich die SLAs, zudem vereinfacht sich die Cluster-Nutzung generell.

Ohne die fundierte Abarbeitung von IT-Infrastruktur- oder -Betriebsthemen stehen Hana-Projekte auf tönernen Füßen.

Unternehmen haben dafür zu sorgen, dass die geschäftskritischen SAP-Anwendungen wie etwa S/4 oder BW/4 Hana praktisch zu jeder Zeit verwendet werden können. Schließlich darf die Business Continuity weder längere Zeit stocken noch gar völlig brachliegen.

Auf der IT-Infrastruktur-/Hana-Agenda steht der Themenkomplex High Availability (HA) nach wie vor ganz oben und wird, nebenbei bemerkt, beispielsweise praktisch bei jedem Suse-SAP-Workshop in der einen oder anderen Art und Weise diskutiert.

Wie bereits in den Vorgängerversionen wird SAP-Suse-Kunden in der aktuellen Version 12 von Suse Linux Enterprise (SLES) for SAP Applications von vornherein die sogenannte High Availability Extension (HAE) inklusive Disaster-Recovery-(DR-)Funktionalität bereitgestellt. Nutzbar sowohl für den Any-DB- als auch für den Hana-DB-Einsatz.

Wichtig dabei:

Bei der High Availability Extension in SLES for SAP Applications handelt es sich um ein komplettes HA-Open-Source-Lösungspaket, das SAP-Suse-Kunden zur kostenfreien Verwendung zur Verfügung steht.

Dadurch ist es nicht erforderlich, bei Hana-Einsätzen zusätzliche Aufwendungen für eine zusätzliche Cluster-Resource-Management-Lösung zu tätigen.

Suse HAE for SAP Applications basiert übrigens auf der Open-Source-Lösung Pacemaker.

Selbstverständlich ist die Suse-HA-Lösung ebenso wie die Betriebssystemplattform Suse Linux Enter­prise Server for SAP Applications in das SAP-Systemmanagement (Solution Manager) integriert.

Im Mittelpunkt des Hana-HA-Konzepts von SAP steht die Hana System Replication (SR). Allerdings erfolgt die Handhabung/Nutzung normalerweise manuell.

Vorteile bringt natürlich eine SR-Automation, wodurch sich eine Steigerung der SLAs erzielen lässt.

Eine Hana-Systemreplikation läuft über ein Memory Preload in einem Cluster (im Minimum 2-Node-Cluster). Im Fall der Fälle erfolgt die automatische Umschaltung mittels Suse HAE for SAP Applications.

Desaster Recovery

Bei einem notwendigen Disaster-Recovery-Szenario ist es möglich, dass eine Hana System Replication durch eine zusätzliche asynchrone Replikation auf eine weitere Site (z. B. ein weiteres Data Center) durchgeführt wird, um somit eine DR-Abdeckung zu erzielen.

Außerdem gibt es einen „Cost-optimized-Ansatz“. Hier wird auf ein Memory Preload (auf ein ständig parallel laufendes System) verzichtet. Auch hier wird ein zweiter Knoten (Node) genutzt.

Allerdings fungiert er hauptsächlich als Test- und Development-System, und es wird ausschließlich im HA-Fall eine Hana System Replication auf dem zweiten Knoten ausgeführt oder verwendet.

Gegenüber einer High-Availability-Umgebung mit synchronem Memory Preload dauert hier die Hana-Wiederverfügbarkeit selbstverständlich länger.

Gleichwohl bedeutet dieser Ansatz eine vorteilhafte Investitions-/Betriebskostenminimierung. Bei einem möglichen DR-Szenario wird ebenfalls wieder asynchron in die „Secondary Site“ repliziert.

Auf der Grundlage von Hana Resource Agents (RA) von Suse lassen sich Hana-Datenbank-Instanzen und -Replikationen verwalten und managen.

Diese Resource Agents ermöglichen darüber hinaus die intelligente und zugleich vereinfachte Nutzung von Cluster-Konfigurationen. Und zwar wesentlich einfacher, als dies in der Vergangenheit der Fall war.

Fazit

Zusammengefasst kann man sagen, dass nunmehr seit Jahren die mit SLES for SAP Applications bereitgestellte Suse High Availability Extension (HAE) eine bewährte und führende Hochverfügbarkeitslösung zur Verbesserung der Business Continuity/High Availability inklusive Disaster-Recovery-Funktionalität für SAP-Lösungen darstellt.

Sie wurde gemeinsam mit SAP für den Hana-Einsatz durch Zusatzentwicklungen optimiert.

Sie erhöht die SLAs beim Hana-Betrieb, vereinfacht den Umgang mit Cluster-Konfigurationen und lässt sich sowohl für Scale-up- als auch für Scale-out-Systemumgebungen verwenden. Wobei es für den Scale-out-Einsatz eine „controlled Avai­lability“ (cA) gibt.

Das könnte Sie auch interessieren

0 Kommentare

Dein Kommentar

Möchten Sie uns Ihre Meinung zum Thema sagen?
Hinterlassen Sie uns einen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.