Die Meinung der SAP-Community Linux Kolumne MAG 1603

Hana Data Center und Zero Downtimes

Pinguine auf fernsehern mit Linux als schrift
Geschrieben von Friedrich Krey, Suse

Bei Hana stehen für IT-Infrastruktur- und -Betriebsverantwortliche zwei Fragen obenan: Wie lassen sich Downtimes minimieren und wie können optimale High-Availability- und Disaster-Recovery-Szenarien beim Hana-Einsatz abgebildet werden?

SAP-Kunden steht ab sofort die neue Version 12 von Suse Linux Enterprise for SAP Applications zum Einsatz zur Verfügung, die bereits wie die Vorgängerversionen von vornherein die sogenannte High Availability (HA) Extension inklusive Disaster- Recovery-(DR)-Funktionalität beinhaltet.

Und zwar SAP-zertifiziert (derzeit zusammen mit x86-Hardware) sowohl für den Any-DB- als auch für den Hana-DB-Einsatz. Dabei liegt es auf der Hand, dass Kunden angesichts einer immer stärkeren Hanaisierung auch in den überwiegenden Einsatzfällen die SAP-In-memory-DB-Nutzung zusammen mit SLES 12 für SAP Applications votieren.

Insbesondere drei Neuerungen sind hier hervorzuheben, von denen Kunden beim Hana-Einsatz profitieren (sei es bei der Nutzung von Business Suite on Hana, S/4, BW on Hana und andere; eben alle Hana-basierten SAP-Lösungen bis hin zu Business One powered by Hana).

Zum einen werden neue sogenannte Hana-Pattern für die weitere Vereinfachung/Automatisierung von Hana-Installationen zur Verfügung gestellt, bis hin zu einer vollständigen Automatisierung von SAP-lösungsbasierten Systemen über gesamte IT-Landschaften hinweg gemäß einem n-Tier-Ansatz.

Was im Endeffekt manuelle Fehler eliminiert und so mögliche  Downtimes minimiert (Unterstützung Zero Down­time). Neu in Suse SLES 12 for SAP Application auch: die neue von Suse entwickelte Technologie namens kGraft, eine Live-Kernel-Patching-Technologie. Sie ermöglicht das Online-Updaten von Security Patches ohne Reboot oder Warten auf das nächste geplante Service-Fenster.

Hervorzuheben sind auch sogenannte Hana Resource Agents (RA), die mit ausgeliefert werden. Damit lassen sich Hana-Datenbank-Instanzen und -Replikationen verwalten, überwachen und steuern. Die RAs können obendrein konfiguriert werden.

Suse unterstützt mit Hana Resource Agents einfach handhabbare Cluster-Konfigurationen. Sie laufen auf allen Knoten eines SLES 12 HAE Clusters und liefern Konfigurationsinformationen oder System­status von Hana-Systemen und Hana-Replikationen.

Seit Jahren bietet die in SLES bereits enthaltene Suse High Availability Extension (HAE) eine bewährte und führende Hochverfügbarkeitslösung zur Verbesserung der Business Continuity/HA sowie Disaster-Recovery-Funktionen für SAP-Lösungen.

Speziell für den Hana-Einsatz wurde die Solution optimiert und weiterentwickelt und stellt eine Art Standard für HA und DR im Hana-Umfeld (bisher für Scale-up) dar. Von SAP werden für HA insbesondere Hana-System-Replication-(SR)-Mechanismen bereitgestellt, deren Handhabung und Nutzung in aller Regel manuell erfolgt.

Die Erhöhung des SLAs über eine Automation geht mit der Suse High Availability Solution (HAE) von SLES 12. Präferiert wird generell als zentrale HA-Lösung für Hana eine Systemreplikation über Memory Preload in einem Cluster (z. B. 2-Node­Cluster).

Die Automatisierung der Umschaltung lässt sich mittels HAE komfortabel ausführen; z. B. in einem 2-Node-Cluster mit einem (zweiten) synchron laufenden HA-System für ein Hana-On-Site-System (wäre dann Knoten eins).

Für ein DR-Szenario ermöglicht die Hana SR eine asynchrone Replikation auf eine weitere Site (z. B. ein weiteres Rechenzentrum), sodass hierüber der Disaster-Fall abgedeckt wird.

Als Alternative-HA in der On- oder Haupt-Site kann ein „Cost-optimized“-Ansatz zum Zuge kommen. Hier gibt es keinen Memory Preload auf ein zweites System, sondern ein zweiter Knoten (Node) steht als Test- und Development-System zur Verfügung. Nur im HA-Fall erfolgt die Hana SR auf den zweiten Knoten.

Was gegenüber einer HA-Lösung mit existierendem Memory-Preload logischerweise länger dauert; jedoch eben eine vorteilhafte Kostenminimierung bei Investitions-/Betriebskosten bedeutet. Bei einem DR-Szenario wird ebenfalls wieder asynchron in die „Secondary-Site“ repliziert.

Fazit:

IInsgesamt senken Hana-Pattern, kGraft in Verbindung mit Suse HAE sowie in Kombination mit der Hana System Replication massiv die Downtime – und tragen somit zur Realisierung einer anvisierten Zero Downtime in einem SAP-Rechenzentrum bei.

Über den Autor

Friedrich Krey, Suse

Friedrich Krey ist Head of SAP Alliances and Partners EMEA Central
SUSE Linux GmbH sowie einer unserer geschätzten E3 SAP Community Magazin Kolumnisten.

Hinterlassen Sie einen Kommentar

AdvertDie Meinung 2