Gesetzte Eckpfeiler

Mit dem Wechsel in Richtung Hana und der Nutzung Hana-basierter Lösungen wie S/4 als „digital Core“ oder auch der SAP Cloud Platform (SCP) samt IoT sind mehrerlei Veränderungen verbunden. Ein Fokus dabei: der Switch in Richtung Linux – zudem die Verwendung weiterer innovativer Open-Source-Lösungen als zukunftsfeste Infrastruktureckpfeiler für den Mission-Critical-SAP-Einsatz im Digitalisierungszeitalter, die von Suse bereitgestellt werden und von denen Kunden profitieren.

Allen SAP-Business-Suite-Bestandskunden ist zwischenzeitlich sehr wohl bewusst, dass der vollständige Any-DB-Support 2025 zu einem Ende gelangt. Zigtausend Unternehmen rund um den Globus sind angehalten, ihre SAP-Systeme auf Hana und auf den ERP-Technologienachfolger SAP S/4 Hana umzustellen.

Damit gehen mehrerlei Veränderungen einher – sowohl anwendungs-, aber auch SAP-IT-infrastrukturseitig. Ein Teil der Anwender hat diese Umstellungen bereits durchgeführt.

Faktum ist: Zum einen ist damit ein Datenbankwechsel verbunden, von einer sogenannten Any-DB wie Oracle, DB2 oder MS SQL Server in Richtung der SAP-In-memory-Datenbank Hana.

Zugleich bedeutet die SAP-Neuausrichtung eine Veränderung bei den verwendeten Servern (und unter Umständen auch bei den Storage-Systemen). Wobei hier für SAP-Kunden die Möglichkeit besteht, unter mehreren Hardwareanbietern zu wählen: hier eine Vielzahl von Intel-x86-basierten Hana-Server-Systemen, dort Power-Prozessor-getriebene Hana-Server von IBM, ebenfalls für eine Scale-out- und Scale-up-Nutzung.

Außerdem gilt es, einen Betriebssystem-Switch auf Linux vorzunehmen, das von SAP vorgegebene OS (Operating System) für den Hana-Datenbank-Einsatz oder von Hana-basierten Lösungen wie S/4 oder BW/4, eben jenen Lösungen, welche die Hana-Datenbank voraussetzen.

Das heißt, eine sehr große Anzahl von SAP-Bestandskunden, bei denen sich Unix oder Windows im Einsatz befinden – nach Erhebungen von Marktforschern wie etwa IDC verwenden immer noch allein rund 50 Prozent aller Business-Suite-Anwenderunternehmen Windows –, haben auf Linux umzustellen.

Weil bei Unix-SAP-Anwendern die Hardware quasi nicht Linux-kompatibel ist, hat sich diese Anwendergruppe sozusagen mit einer Dreifachumstellung zu befassen: Hardware-, Datenbank- und Linux-Migration. Bei Windows-SAP-Anwendern gilt dies in ähnlicher Weise, da alle x86-Hana-Server-Systeme eine SAP-Zertifizierung aufzuweisen haben, was bei existierenden Systemen in aller Regel nicht der Fall ist.

Plattformausbau von SLES for SAP Applications

Eine signifikante SAP-Anwenderzahl kennt Linux von den unterschiedlichsten SAP-Business-Suite-Einsätzen und der intensivierten SAP-Hana- oder S/4-Verwendung bereits aus dem Effeff.

Andere wiederum – insbesondere Unix- und Windows-SAP-Bestandskunden, die den Hana-Wechsel erst angehen – sind damit überhaupt nicht oder wenig vertraut. An beide SAP-Kundengruppen richten sich die folgenden Ausführungen respektive Erläuterungen.

Was leistet Suse Linux Enterprise Server (SLES) for SAP Applications als von SAP ausgewählte und empfohlene Betriebssystemplattform im Zusammenspiel mit SAP Hana oder mit Hana-basierten SAP-Lösungen wie S/4 Hana?

Oder: Welche Lösungen stellt der langjährige SAP-Partner und Open-Source-Innovator Suse für SAP-Anwender neben SLES for SAP Applications (in der aktuellen Version 12) zur Verfügung, die darauf ausgerichtet sind, agile sowie flexible und insbesondere digitalisierungsgerechte IT-Infrastrukturen im Hy­brid- oder Multi-Cloud- und Software-Defined-Infrastructure-Zeitalter (SDI) nutzenbringend zu verwenden?

Wichtig zu wissen ist zunächst einmal, dass Suse und SAP auf eine langjährige und sehr erfolgreiche Partnerschaft zurückblicken können. Wie überhaupt Suse als Open-Source-Keyplayer sein sehr umfangreiches Partnernetz über die vergangenen 25 Jahre kontinuierlich ausgebaut hat.

Suse war 1999 mit dabei, als das Walldorfer Linux Lab von SAP ins Leben gerufen wurde. Das Ziel lautete damals: ein Enterprise Linux für den Mission-Critical-SAP-Einsatz zu entwickeln. Eigentlich nur unwesentlich später kam das Thema SAP Adaptive Computing hinzu; konkret Flexframe für SAP von Fujitsu zu unterstützen.

Was Suse auch in die Tat umsetzte – ebenfalls mit SLES for SAP Applications, der heute marktführenden Linux-Betriebssystemplattform im SAP-Umfeld. Und nebenbei bemerkt ist SLES for SAP Applications nach wie vor die einzige Linux-Betriebssystemplattform für die Flexframe-Lösung (siehe hierzu auch den Beitrag von Fujitsu auf den Seiten 68 und 69).

Weitere Highlights der SAP-Suse-Zusammenarbeit über die Zeit hinweg: die Verfügbarkeit von SLES for SAP Applications HAE (High Availability Extension), eines Installation Wizzard für die teilautomatisierte Installation von SAP-Basis-Komponenten, SLES for SAP Applications als Standard für die SAP-Cloud-Lösung Business By Design, den SAP BW Accelerator oder als Betriebssystemplattform für SAP-Entwicklungen und vieles andere mehr.

2009 wurde Suse dann in das damals geheime „Projekt SAP Hana“ eingebunden. Das In-memory-Projekt veränderte SAPs DB-Strategie, und Suses Exklusivität auf Intel für SAP Hana lief über einen Zeitraum von fünf Jahren, auf IBM Power noch bis Heute.

Es liegt auf der Hand, dass SAP-Kunden von dem immensen Erfahrungsschatz und Know-how-Vorsprung von jetzt Tausenden von Hana-SLES-for-SAP-Applications-Installationen profitieren.

Wobei das gemeinsame Miteinander sich stetig erweitert. So zum Beispiel in Verbindung mit SAP Hana 2. Hier stellt ein neues Hana-HA-Feature im Rahmen einer Active-Active-Architektur in einer geclusterten Hana-Umgebung mit dem Fokus auf „Secondary Read Enabled“ beispielsweise ein Highlight dar, das auf Suse-Technologie basiert.

Bereits von Hana-Beginn an war Suse Linux Enterprise Server for SAP Applications weit mehr als ein übliches Betriebssystem, zuständig quasi nur für die Ver- beziehungsweise Abarbeitung maschinen- oder prozessabhängiger Befehle.

Auch beinhaltet diese Variante als Plattform zahlreiche speziell auf den SAP-Hana-Einsatz hin entwickelte Features, die über die klassische Suse-SLES-Version hinausgehen und wichtige Datacenter-Funktionalitäten beim SAP-Einsatz vorteilhaft unterstützen. Entwickelt wurden sie in jahrelanger enger Zusammenarbeit oder Abstimmung mit SAP.

Dies betrifft RAS-(Reliability and Resilience)-Aspekte ebenso wie Performance-, Ease-of-Use-/Deployment- und Basis-Operating- oder Support-Themenfelder. Und zwar alles mit dem Ziel, leistungsstarke und innovative Produkte sowie Supportleistungen bereitzustellen, um Anwenderunternehmen zu helfen, die Komplexität zu verringern, den Automatisierungsgrad zu erhöhen, Kosten zu reduzieren und verlässliche Services für den Mission-Critical-SAP-Hana-Einsatz bereitzustellen.

Spezielle auf SAP-Hana hin entwickelte Features

So sorgten beispielsweise gleich eine Reihe von Features von SLES for SAP Applications dafür, dass eine möglichst umfangreiche High Availability (HA) inklusive DR-Funktionalität beim Hana-Einsatz gemäß dem Ansatz „Towards Zero Downtimes“ gegeben ist beziehungsweise das immer wichtiger werdende Themenfeld RAS samt Security abgedeckt wird.

Seit Jahren bietet die in SLES for SAP Applications bereits enthaltene Suse High Availability Extension (HAE) als bewährte und führende Hochverfügbarkeitslösung ausgefeilte Funktionen zur Verbesserung der Business Continuity/High Availability sowie für Disaster-Recovery-Unterstützung bei der Nutzung von SAP.

Speziell für den SAP-Hana-Einsatz wurde die Solution optimiert beziehungsweise weiterentwickelt und stellt auch eine Art Standard für HA und DR im SAP-Hana-Umfeld (für Scale-out und Scale-up dar. Von SAP werden für HA insbesondere SAP-Hana-System-Repli­cation (SR)-Mechanismen bereitgestellt.

Die Erhöhung der SLAs über eine Automation ermöglicht die Suse High Availability Solution (HAE) von SLES 12 for SAP Applications. Präferiert wird generell als zentrale HA-Lösung für SAP Hana eine Systemreplikation über ein Memory Preload in einem Cluster (beispielsweise 2-Node-Cluster).

Die Automatisierung der Umschaltung lässt sich mittels Suse HAE komfortabel ausführen; zum Beispiel 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 SAP Hana System Replication eine asynchrone Replikation auf eine weitere Site (zum Beispiel ein weiteres Rechenzentrum), sodass hierüber der Desaster-Fall abgedeckt wird. Integriert in Suse SLES 12 for SAP Applications zum Beispiel ferner: die 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.

Hana Resource Agents

Hervorzuheben ebenfalls: SAP Hana Resource Agents (RA). Damit lassen sich Hana-Datenbank-Instanzen und -Replikationen verwalten, überwachen und steuern. Die RAs können obendrein konfiguriert werden. Und:

Suse unterstützt mit den SAP Hana Resource Agents einfach handhabbare Cluster-Konfigurationen. Sie laufen auf allen Knoten eines SLES 12 for SAP Applications HAE Clusters und liefern Konfigurationsinformationen oder Systemstatus von Hana-Systemen und Hana-Replikationen (etwa für Systemmanagement-Zwecke).

Außerdem besteht die Möglichkeit, übergreifende Managementsysteme wie etwa Datavard Insights des SAP- und Suse-Partners Datavard zur Überwachung/Monitoring und Steuerung beziehungsweise zum proaktiven Alerting von SAP Hana und SLES for SAP Applications zu verwenden. (Siehe hierzu auch den Beitrag über Datavard Insights auf Seite 15.)

Ein anderes Beispiel im Zusammenhang der bereitgestellten SLES-for-SAP-Applications-RAS-Funktionalität stellt ein Security Hardening for Hana dar. Hier wird durch eine hohe Härtung von Suse SLES for SAP Applications Angriffen oder Bedrohungen von außen entgegengewirkt.

Auch können damit Mechanismen eingesetzt werden, die aufzeigen, welche Betriebssystem-Packages sinnvollerweise verfügbar sein sollten und auf welche gegebenenfalls verzichtet werden kann. Kernfokus ist, dass weniger Packages eine geringere Angriffsfläche gegenüber Bedrohungen bedeutet. Eine weitere in SLES 12 for SAP Applications integrierte Funktion: ein standardmäßig mit ausgeliefertes Remote Storage Encryption Management oder eine konfigurierbare Firewall.

Daneben werden in der Version 12 sogenannte SAP Hana Pattern für die weitere Vereinfachung/Automatisierung von Hana-Installationen für das Themenfeld Simplified Operations 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. Zahlreiche andere Funktionen für den Mission-Critical-Hana-Einsatz sind bereits in der Version 11 von SLES for SAP Applications berücksichtigt.

Alle bereitgestellten Kernfunktionen/Packages der Betriebssystemplattform SLES for SAP Applications für RAS, Performance, Ease of Use and Deployment (mit Simplified Operations etwa auf Basis der Management-Lösung Suse Manager) und Base Operating System and Support finden sich übersichtsmäßig in der Abbildung „Suse Linux Enterprise Server for SAP Applications: Schlüsselfunktionsthemenfelder im Überblick“. Es liegt auf der Hand, dass Suse SLES for SAP Applications quasi permanent weiterentwickelt wird oder neue Technologien integriert werden. Vorstellbar ist zum Beispiel, das Thema Machine Learning aufzunehmen. Etwa in Form von Funktionen auf Basis von Google TensorFlow.

SLES for SAP Applications und da­rüber hinaus

Der Footprint oder die Rolle von Suse im SAP-Umfeld reicht mittlerweile über SLES for SAP Applications weit hinaus. Insbesondere vor dem Hintergrund der digitalen Transformation und den dabei zur Verfügung gestellten Lösungsinnovationen auf Open-Source-Basis, die als weitere Infrastrukturanker oder wichtige Eckpfeiler nutzenbringende Vorteile bieten.

Unterstützt werden SAP Hana und S/4 Hana als digital Core inklusive einer neuen User-Experience auf der Grundlage von Fiori. Wobei der Business-Suite-Technologienachfolger bekanntlich sowohl die ERP-Nutzung als auch den Einsatz von Big Data, Analytics, Mobile Computing, Geschäftsnetzwerken oder SAP Leonardo mit Internet of Things (IoT) berücksichtigt.

Und das im On-premise- und Cloud-Betrieb, in hybrider Form On-premise/Cloud oder in Form einer Multi-Cloud-Nutzung. (Hierzu auch der Beitrag von QSC auf den Seiten 61 und 62.)

Überall lässt sich dabei Suse Linux Enterprise Server for SAP in Verbindung mit Hana oder Hana-basierten Lösungen verwenden – sozusagen als One Infrastructure für alle Deployment-Formen: auf Hana-on-Intel-x86, auf IBM Hana on Power, aber zudem auch via Amazon AWS, der Google Cloud Platform (GCP), der SAP Cloud Platform und der SAP Hana Enterprise Platform (HEC) oder via Microsoft Azure. Was einer Standardisierung gerade im Hinblick auf die immer stärker aufkommende Multi-Cloud-Nutzung stark entgegenkommt.

Die digitale Transformation bringt ebenfalls neue Anforderungen an Anwendungen, Anwendungsentwicklung und den Betrieb von Rechenzentren mit sich, und zwar basierend auf dem Dev­Ops-Modell. Anwendungsentwicklung und IT-Betrieb werden hier entsprechend den Erfordernissen intelligent miteinander verwoben, um neue Applikationen schnell oder bedarfsgerecht zeitnah zur Verfügung zu stellen.

Mit den SAP Core Data Services rücken übrigens Hana und S/4 noch enger zusammen, was den DevOps-Gedanken unterstützt. Wichtig dabei: die Notwendigkeit einer dynamischen und hochflexiblen IT-Infrastruktur samt -Komponenten auf der Grundlage gemäß Software-Defined-Data-Center- (SDDC) oder Software-Defined-Infrastructure-Prinzipien.

In diesem Zusammenhang nimmt wie ausgeführt Linux als Open-Source-Betriebssystemplattform für Hana eine wichtige Rolle ein. Aber auch etwa Ha­doop als eine Komponente für das Themenfeld Big Data steht im Fokus.

Obendrein die Kernelemente OpenStack (IaaS) für die Cloud-Server-Provisionierung, Cloud Foundry (PaaS) als Entwicklungsplattform oder Container-as-s-Service (CaaS) samt Kubernetes Magnum oder Docker für die effiziente Virtualisierungsverwendung. Allesamt übrigens sehr bedeutsame Infrastrukturelemente oder -komponenten der SAP Cloud Platform, einem Dreh- und Angelpunkt für die App-Entwicklung und -Bereitstellung bei der Verwendung von S/4 Hana.

OpenStack, Cloud Foundry und SCP

Ein Blick auf OpenStack, Cloud Foundry und Container-as-s-Service: Wie die OpenStack Foundation ist die Cloud Foundry Foundation ein freies Open-Source-Projekt, das von vielen namhaften Firmen herstellerübergreifend als Non-Profit-Organisation unterstützt wird.

SAP und Suse sind dabei, aber auch viele, viele andere aus dem IT- und Non-IT-Umfeld, wie etwa General Electric. Als erster Linux-Distributor überhaupt ist Suse seit 2012 Mitglied der OpenStack Foundation und stellte im gleichen Jahr mit Suse OpenStack Cloud die erste Enterprise-OpenStack-Lösung vor. Cloud-Foundry-Foundation-Mitglied ist Suse seit 2015.

Die Foundation liefert mit Cloud Foundry und den Cloud-Foundry-Komponenten konkret einsetzbare Softwarelösungen. Das OpenStack-Gegenstück zertifiziert zudem die verschiedenen PaaS-Lösungen der Cloud-Foundry-Mitglieder. Dadurch wird insbesondere sichergestellt, dass Cloud-Plattformen auf der Basis eines einheitlichen und offenen Standards untereinander kompatibel und konsistent sind.

Im Fokus der Suse-SAP-Aktivitäten (SAP-Suse-Co-Development) steht die Bereitstellung eines OpenStack Cloud Provider Interfaces (CPI). Das Hauptaugenmerk dabei: mittels eines CPIs die Kommunikation zwischen Cloud Foundry und der darunter liegenden OpenStack-Infrastruktur zu vereinfachen beziehungsweise zu automatisieren.

So ist man in der Lage, Anwendungs-Apps aufwendungsarm zu testen und sie in Private- oder Public-Clouds umgehend auszurollen und einzusetzen. Das zuvor Skizzierte findet bei der SAP Cloud Platform (vormals Hana Cloud Platform, HCP) Verwendung.

Durch den Einsatz einer Open-Source-OpenStack-basierten IaaS-Cloud (Private- oder On-premise-Cloud) für SAP-Anwendungen ergeben sich handfeste Nutzenvorteile – bis hin zu der Tatsache, dass sich SAP-Lösungen effizient und kosteneffektiv ausrollen lassen.

Im Zuge der Digitalisierung lassen sich dadurch Services oder Anwendungen schnell und flexibel bereitstellen. Immer mehr Unternehmen, aber auch etwa IT-Serviceprovider, setzen auf OpenStack-basierte Cloud-Umgebungen.

Das aktuelle Release von Suse OpenStack Cloud liegt derzeit in der Version 7 vor und enthält bereits Con­tainer-as-a-Service-Funktionalitäten. Darüber hinaus ermöglicht sie Software-Upgrades, die keine Störung des laufenden Betriebs mehr mit sich bringen.

Diese Version bietet zum Beispiel bereits vollständige Unterstützung von Docker auf Basis von Kubernetes als Framework für die Container-Orchestrierung, das im Rahmen der Integration von OpenStack Magnum zur Verfügung gestellt wird. Kunden erhalten so Zugriff auf Container-as-a-Service-Funktionalitäten, mit denen sie innovative Cloud-native Workloads und Anwendungen entwickeln sowie DevOps-Prozesse und -Umgebungen unterstützen können.

Weiter gibt es zusätzliche Hochverfügbarkeits-Features, darunter eine High-Availability-Protection für virtuelle Maschinen und Workloads, die die Hochverfügbarkeit für Control-Planes und Compute-Nodes ergänzen. Kunden können somit auch geschäftskritische Anwendungen in die Cloud verlagern.

Auch steht eine Integration von OpenStack Manila mit CephFS zur Verfügung, die über Suse Enterprise Storage ausgeliefert wird. Auf diese Weise steht eine vereinheitlichte Storage-Umgebung zur Verfügung, mit der Kunden Workloads für ihre Block-, Objekt- und File-Storage-Systeme in einem einzigen Cluster laufen lassen können, um so Investitions- und Betriebskosten zu senken.

Außerdem erhalten Anwender eine verbesserte Skalierbarkeit, die das Deployment über mehrere Datenzentren hinweg erlaubt. Benutzer sind übrigens damit in der Lage, mehrere Private-Clouds über eine einzige Benutzeroberfläche zu administrieren.

Cloud Foundry Dojo im SAP Cloud Lab

PaaS als Cloud-Service setzt bekanntlich auf IaaS auf. Suse und SAP fokussieren sich mit dem sogenannten Cloud Foundry Dojo, SAP Cloud Lab, auf die oben skizzierte Integration von OpenStack und Cloud Foundry. Dabei forcieren Suse und SAP die gemeinsamen Entwicklungen sowohl bei Linux- als auch bei der Integration von OpenStack und Cloud Foundry weiter.

Von Vorteil dabei ist, dass sich Suse-Technologie-Assets im Bereich OpenStack und Cloud Foundry durch die Übernahmen von HPE-Assets erweitern. In Teilen wurde es bereits in das Suse-Portfolio integriert. Unterfüttert wird von Suse das Thema Container-as-a-Service (CaaS) mit der neuen Suse CaaS Platform.

Im Vordergrund hier: flexible, vereinfachte und automatisierte Möglichkeiten zur Auslieferung von kleinteiligen Services (Microservices) mit Hilfe von Containern – samt der Verwendung von Docker oder Kubernetes. Speziell Kubernetes ist in der Lage, Container-Apps in Cluster-Umgebungen (physische oder virtuelle Maschinen) effizient zu unterstützen.

Ebenso wird Kubernetes bevorzugt, um das Ziel einer Container-zentrischen Infrastruktur vorteilhaft in die Tat umzusetzen (anstelle einer eher starren Host-zentrischen). In diesem Zusammenhang spielt übrigens auch Suse Linux Enterprise Server (SLES) als Container Host OS in einer spezialisierten Version (SLES Micro OS) wiederum eine Rolle. Der Nutzen dabei: ein geringer Footprint bei einer optimalen Ressourcenverwendung.
DevOps und Open Source

Der Einsatz von DevOps (Development and IT Operations) unter Verwendung von Open-Source-Lösungen bei der SAP Cloud Platform ist heute bereits State of the Art, um Anwendungen zu entwickeln sowie zu managen – samt einem kompletten und vollständigen Life Cycle Management. Damit ist der Weg auch für SAP-Anwenderfirmen quasi vorgezeichnet, um neue Apps gemäß Business-Vorgaben in die Tat umzusetzen und zu betreiben.