Deep Dive: SAP-Automatisierung mit Ansible auf SLES for SAP 16 – Architektur, Collections & Playbooks

Willkommen zurück im Tech-Blog. Als Senior IT-Architekt verfolge ich die Evolution der SAP-Infrastrukturen seit Jahren. Mit dem kommenden Release von SUSE Linux Enterprise Server (SLES) 16 steht ein fundamentaler Paradigmenwechsel in der Automatisierung von SAP-Landschaften an.

Das klassische Bereitstellen über manuelle sapinst-Aufrufe oder stark fragmentierte Bash-Skripte weicht einer hochstandardisierten, deklarativen Methodik. In diesem Artikel analysieren wir tiefgreifend die neuen Ansible-Konzepte, verknüpfen sie mit etabliertem Architektur-Wissen und sezieren die technischen Details, die SUSEs Solution Architect Mat Matsum Mamula kürzlich vorgestellt hat.

Der strategische Shift: Von Salt zu Ansible

Historisch betrachtet war SUSE im Automatisierungsumfeld stark mit Salt (bzw. SaltStack) verbandelt, insbesondere getrieben durch SUSE Manager (Uyuni). Die wichtige Nachricht für bestehende Architekturen lautet: Salt verschwindet nicht und bleibt ein essenzieller Bestandteil für das Management bestehender Infrastrukturen. Allerdings verlagert SUSE seinen klaren Fokus für die dedizierte SAP-Automatisierung auf Ansible.

Diese Entscheidung reflektiert den breiteren Industrie-Standard. Um die Interoperabilität zu maximieren, wurde die SAP Linux Lab Open Source Initiative ins Leben gerufen – ein kollaboratives Upstream-Projekt auf GitHub (github.com/sap-linuxlab), das Technologiepartner wie SUSE, Red Hat, IBM, SAP, NetApp und die Open-Source-Community vereint. Das architektonische Ziel dieser Allianz ("fostering collaboration") ist es, Automatisierungscode zu schreiben, der auf allen Plattformen der Partner agnostisch und einwandfrei funktioniert, anstatt proprietäre Silos zu pflegen. Werden beispielsweise neue Features auf Basis der SUSE-Dokumentation entwickelt, fließen diese zeitgleich in den Red Hat-Zweig ein, um vollständige Kompatibilität zu gewährleisten.

SLES 16 vs. SLES for SAP 16: Tooling vs. Automations

Ein kritischer Aspekt für das Design künftiger Landschaften ist die strikte Trennung der Auslieferung. Während das reguläre SLES 16 lediglich die grundlegenden Werkzeuge (Tooling) erhält, werden die eigentlichen SAP-Automatisierungen exklusiv mit SLES for SAP 16 ausgeliefert.

Der architektonische Grund hierfür ist simpel, aber entscheidend: Reguläres SLES 16 ist weder validiert noch zertifiziert oder offiziell für den Betrieb von SAP-Workloads oder SAP High Availability (HA) Clustern freigegeben. Dies ist exklusiv der "for SAP"-Variante vorbehalten, weshalb auch die Automatisierungsskripte strikt an dieses Produkt gebunden sind. Für die Installation existiert in SLES for SAP 16 ein spezielles Pattern namens patterns-sap-automation, welches sämtliche notwendigen Abhängigkeiten auf dem System installiert.

Technische Basisdaten: Python, Ansible Core und CVE-Hürden

Die unterliegende Technologie erfährt ein signifikantes Upgrade, das bei Migrationen zwingend beachtet werden muss. Der aktuelle Planungsstand (welcher sich im agilen Release-Zyklus noch minimal ändern kann) sieht die Auslieferung von Python 3.11 sowohl für SLES 16 als auch für SLES for SAP vor. Dies ist eine drastische Modernisierung gegenüber den alten SLES 15-Ständen.

Auf dieser Basis wird aktuell Ansible sowie Ansible Core in der Version 2.18 validiert und getestet. Interessant aus Security-Perspektive: Ursprünglich waren ältere Ansible-Versionen geplant, jedoch zwangen kritische Sicherheitslücken (CVEs) in zwei Vorgängerversionen das Entwicklungsteam dazu, direkt auf den neuesten Versionsstand zu springen, welcher die Tests erfolgreich durchlief.

Architektonische Fallstricke: Abwärtskompatibilität und Python

Ein extrem wichtiges Detail für hybride Landschaften oder Migrationen von SLES 15 auf 16: In Python 3.7 und 3.9 gab es fundamentale Änderungen bezüglich sogenannter iterated to future-Feature-Annotationen, die in Ansible zu Komplikationen führten und strengere Python-Anforderungen erzwangen.

Da SLES 16 auf Python 3.11 basiert, funktioniert die Kommunikation von "16 zu 16" out-of-the-box. Wenn Sie jedoch als Orchestrierungs-Knoten SLES 16 nutzen, um SAP auf SLES 15 (ab SP5) auszurollen, müssen Sie zwingend Python 3.11 auf dem Zielsystem nachinstallieren. Dies wird in den mitgelieferten Playbooks über das Ansible raw-Modul automatisiert gelöst, ist aber als Basiswissen für IT-Architekten beim Troubleshooting unerlässlich.

Deep Dive: Die drei Säulen der SAP-Collections

Der Automatisierungs-Code ist in hochgradig spezialisierte Ansible Collections unterteilt, die klare Zuständigkeiten in der Provisionierungs-Pipeline (Day-1 und Day-2 Operations) aufweisen.

1. SAP Infrastructure (ansible-collection-sap_infrastructure)

Diese Collection ist für die Bereitstellung der nackten Server in Cloud-Umgebungen zuständig. Architektonisch spannend ist die Dualität: Die Provisionierung kann wahlweise nativ durch Ansible oder durch Terraform (gesteuert via Ansible) erfolgen. Die offizielle Philosophie lautet hier: "Terraform ist mächtiger, aber Ansible ist smarter". Entsprechend wird Ansible als primäre Provisionierungsmethode favorisiert, da es Bedingungen (Requirements) im Vorfeld intelligenter prüfen kann, während Terraform stumpf Netzwerk-Elemente provisioniert.

Die Infrastruktur-Collection unterstützt aktuell gängige Cloud-Provider, hat aber auch experimentelle Module für VMware und KubeVirt in der Pipeline. Wichtig: Das reine Paket reicht nicht aus. Aufgrund von Lizenzrestriktionen können Third-Party-Bibliotheken nicht mitgeliefert werden. Wenn Sie beispielsweise AWS ansteuern, müssen Sie zwingend Python boto3, die AWS CLI sowie die amazon.aws Collection manuell bereitstellen, was in den Paketen entsprechend dokumentiert ist.

2. SAP Install (ansible-collection-sap_install)

Das Herzstück der Automatisierung für On-Premise und Cloud (Day-1 Applikations-Layer). Die Architektur folgt einer strikten, nicht überlappenden Pipeline (Top-to-Bottom-Ausführung):

• sap_storage_setup: Initialisierung von Disks, LVMs, Volumes und Partitionen (sowohl für Cloud als auch On-Prem und Bare-Metal).

• sap_general_preconfigure: Setzen der extrem kritischen saptune-Parameter (Kernel, Sysctl) und Installation der durch SAP-Notes geforderten OS-Pakete.

• sap_install_media: Ein intelligenter Entpacker. Liest Manifest-Dateien aus bereitgestellten SAP-Medien aus und entpackt/sortiert die Files zielgerichtet, was klassische Bash-Skripte oft zum Scheitern bringt.

• sap_swpm & sap_hana_install: Dies sind sehr tiefgreifende, komplexe Wrapper um die offiziellen SAP-Binaries sapinst (Software Provisioning Manager) und hdblcm (HANA Database Lifecycle Manager).

• HA Pacemaker: Die finale Konfiguration der Cluster-Ressourcen für HANA, ASCS und (neu hinzugekommen) SCS/ERS.

3. SAP Operations (ansible-collection-sap_operations)

Eine fokussierte, kleinere Collection für Day-2-Automatisierungen nach der erfolgreichen Grundinstallation.

Playbooks und Deployment-Szenarien (ansible-sap-playbooks)

Die eigentliche Magie entsteht, wenn diese Collections orchestriert werden. SUSE hat die Playbooks (zu finden unter /usr/share/ansible/playbooks/) für das anstehende Release einer gigantischen Überarbeitung unterzogen – 90% des Codes wurden von Grund auf neu geschrieben (mit über 15.000 Code-Changes in aktuellen Pull Requests).

Es stehen über 20 verschiedene Deployment-Szenarien zur Verfügung, die nahezu jedes Architektur-Pattern abdecken. Dazu zählen BW/4HANA, SAP ECC, HANA, NetWeaver, S/4HANA und Solution Manager. Diese gibt es wiederum in diversen Flavors: von einfachen Sandbox-Systemen über hochverfügbare (HA) Cluster bis hin zu extrem verteilten (distributed) Systemen.

Ein massiver architektonischer Fortschritt ist die Entkopplung von Infrastruktur-Provisionierung und Software-Deployment. Die Playbooks wurden extrem modularisiert. Wenn ein Unternehmen bereits eigene Server on-premise betreibt (Prague Data Center im Beispiel) oder eine eigene Terraform-Pipeline hat, lässt sich die Provisionierungs-Phase in den Playbooks komplett überspringen. Die einzigen Voraussetzungen sind in diesem Fall: Das Vorhandensein des Pattern-Pakets, ein sauberes Ansible-Inventory und verteilte SSH-Keys.

Execution Modes: Vom Profi bis zum Anfänger

Um die Einstiegshürde ("How to start") drastisch zu senken, wurden drei spezifische Ausführungsmodi implementiert:

• Fully Non-Interactive Mode (Der Standard für Automatisierungs-Architekten): Erwartet einen erfahrenen DevOps-Engineer. Alle Variablen (Host-Definitionen, OS-Parameter, SAP-Produkt-IDs) werden in einer kompakten YAML-Datei definiert, die von unnötigem Ballast befreit wurde.

• Fully Interactive Mode (Das neue Highlight): Ein gewaltiges Feature mit über 1.300 Zeilen Code allein für die interaktive Abfrage. Der Modus fragt Schritt für Schritt alle Parameter ab ("Verwenden Sie Ansible oder Terraform?", "Wohin soll provisioniert werden?"). Etwa 70% der Variablen sind mit validen Default-Werten vorbelegt und können per Enter-Taste bestätigt werden. Der Clou: Am Ende der geführten Installation lassen sich die Eingaben als YAML abspeichern und für künftige, nicht-interaktive Rollouts als Blaupause nutzen.

• Light Mode für bestehende Server: Ein minimales Input-File, bei dem alle Cloud/Plattform-spezifischen Variablen schlicht gelöscht werden. Die Playbooks sind so robust, dass sie sich nicht an fehlenden Infrastruktur-Variablen stören, wenn nicht provisioniert wird.

High Availability (HA) und Idempotenz-Herausforderungen

Als Senior IT-Architekt lege ich besonderen Wert auf Ausfallsicherheit. Die HA-Automatisierung deckt mittlerweile ein extrem breites Spektrum ab. Für die HANA-Datenbank wurde letztes Jahr die Unterstützung für SAP HANA SR-NG (System Replication Next Generation), die designierte HA-Zukunft für HANA, erfolgreich implementiert. Für Applikations-Cluster (ASCS / ERS) werden sowohl ENSA1 als auch das moderne ENSA2 unterstützt. Im ENSA2-Umfeld kann sogar im "Classic Mode" mit File System Resource Agents oder mittels Simple Mount installiert werden. Interessantes Detail am Rande: Selbst nicht offiziell unterstützte Architekturen, wie Java-Cluster, wurden aus Proof-of-Concept-Sicht in den Code integriert.

Ein oft unterschätztes Problem der Automatisierung ist die Idempotenz (die Eigenschaft eines Skripts, bei mehrfacher Ausführung denselben Endzustand ohne Seiteneffekte zu garantieren). Die gute Nachricht: Fast alle SAP-Rollen, inklusive des hdblcm-Wrappers für HANA, arbeiten vollständig idempotent. Sie prüfen Konfigurationen und fixen Abweichungen, andernfalls überspringen sie den Task.

Die architektonische Ausnahme bildet der SAP SWPM (sapinst). SAP hat sapinst historisch nicht für Idempotenz konzipiert; führt man ihn erneut auf einem laufenden System aus, zerstört er die Installation unwiderruflich. Die Entwickler der Upstream-Initiative arbeiten derzeit massiv daran, robuste Wrapper um den SWPM zu bauen, die diesen Design-Fehler von SAP umgehen und Item-Potency simulieren.

Software Supply Chain: Automatisierter SAP-Download

Ein weiteres Praxis-Problem löst die Upstream-Rolle sap_launchpad (welche bald auch über den SUSE Package Hub verfügbar sein wird). Wenn Sie gültige S-User-Credentials übergeben, kümmert sich die Rolle automatisch um den Download der benötigten Software-Pakete und Patches direkt von SAP.

Dies eliminiert einen manuellen und extrem fehleranfälligen Prozess. Ist die Rolle nicht vorhanden oder werden keine Zugangsdaten übergeben, greift der Code dynamisch auf alternative Quellen wie zentrale NFS-Shares zurück. Da SAP notorisch dafür bekannt ist, Dateinamen bei Patch-Rollouts von heute auf morgen zu ändern, wird diese Rolle kontinuierlich weiterentwickelt, um Dateien intelligenter zu identifizieren.

Fazit

Mit den Ankündigungen zu SLES for SAP 16 beweist SUSE, dass sie die Notwendigkeit einer "Infrastructure as Code"-Kultur im SAP-Umfeld verstanden haben. Der Wechsel von isolierten Skript-Sammlungen zu einem standardisierten, extrem flexiblen Ansible-Regelwerk, getrieben von der SAP Linux Lab Open Source Initiative, ist ein gewaltiger Sprung. Für uns als IT-Architekten bedeutet das: Playbooks, die gleichermaßen auf AWS, im eigenen RZ, für HANA-Scale-Outs oder NetWeaver-Sandboxen funktionieren, radikal entschlackte Variablen-Dateien und durch den interaktiven Modus eine deutlich flachere Lernkurve für Operations-Teams.

Wichtig ist jedoch, die architektonischen Restriktionen im Hinterkopf zu behalten: Denken Sie an die fehlende Out-of-the-box-Idempotenz des sapinst, die korrekte Python 3.11-Injection auf SLES 15 Zielsystemen via raw-Modul und die strikte Trennung von Tooling (SLES 16) und Automations (SLES for SAP 16). Wer diese Aspekte in seiner Lösungsarchitektur berücksichtigt, bekommt ein mächtiges, zukunftssicheres Werkzeug an die Hand. Der Code liegt auf GitHub – der Evaluierung für die nächste SAP-Landschaft steht also nichts im Wege.