Geschwindigkeit für den Mittelstand
FIS-ASP baut sich OpenStack-Infrastruktur mit SAP, Suse und Thomas-Krenn AG
25.01.18 | Autor / Redakteur: Matthias Braun* / Ulrike Ostler
Eine Cloud-basierte Datacenter-Infrastruktur für den SAP-Mittelstand hat die FIS-ASP gemeinsam mit Suse und dem Server-Storage-Spezialisten Thomas-Krenn AG geschaffen. Sie basiert auf OpenStack und ist auf kurze Bereitstellungszeiten hin optimiert.
Auch mittelständische SAP-Anwender sind heute zunehmend international aufgestellt, daher steigen die Anforderungen beim Hosting. Zum einen wird die Bereitstellungszeit zum erfolgskritischen Faktor. Neue Aufgaben erwachsen außerdem aus „SAP HANA“- beziehungsweise aus „S/4“-Projekten, Migrationen, „SAP EWM“-Einführungen …. Während früher eine dreistufige SAP-Systemlandschaft im Aufbau ausreichend war, kommen heute oft weitere Landschaftskomponenten wie „SAP Fiori Frontend-Server“, „Adobe Document Services“ oder „Web-Dispatcher“ zum Einsatz.
Die Herausforderung liegt in der Kombination der Systeme untereinander und zu bestehenden Landschaften. Ferner müssen Updates und Umstellungen oft parallel möglich sein. Die FIS-ASP, Tochter der FIS Gruppe und spezialisiert auf Einführung, Betrieb und Pflege weltweiter SAP-Landschaften, startete deshalb 2013 ein Projekt, das sich mit der damals noch jungen OpenStack-Technologie beschäftigte. Ziel war es, mittels der Technologie eine automatisierte Cloud-Lösung für die von ihr gehosteten SAP-Landschaften zu schaffen.
OpenStack ermöglicht die gewünschte Automatisierung
Partner war von Anbeginn die Suse GmbH. Auf deren „Linux Enterprise Server“ betreibt die FIS-ASP mittlerweile fast drei Viertel der SAP-Systeme. OpenStack als von Suse unterstütztes Projekt zum Aufbau einer freien Architektur für Cloud-Computing ermöglicht genau die gewünschte Automatisierung.
Mit zwei Compute-Knoten, einem Controller und einem Admin-Knoten kam FIS-ASP im Proof-of-Concept nach einem Tag soweit wie in den vorhergehenden Versuchen erst nach mehreren Monate und konnte damit direkt mit dem Anlegen und Vorbereiten von Images für die SAP-Basisinstallation beginnen. Suse integrierte mit dem „Crowbar“-Modul eine Software für automatisiertes „Betanken“ der physischen Knoten einer Cloud.
Im Verlauf der Tests schwenkte FIS-ASP von SAN für das Betriebssystem auf diesen Knoten zu lokalen Disks. Auf den Compute-Knoten wurde ein SLES-Betriebssystem mit dem KVM-Hypervisor als Default ausgerollt.
Allerdings: Die Verwendung von SAN-Storage für das Host-Betriebssystem bereitet bis heute nur mehr Probleme beim „Betanken“ und bringt keinen Mehrwert in einer Umgebung, in der auf den Compute-Knoten nur ein Hypervisor mit einem zusätzlichen OpenStack-„Nova“-Service läuft. Nova ist die eigentliche Kernkomponente von OpenStack, die sich um das Starten, Stoppen und Verwalten der virtuellen Maschinen kümmert.
Controller-Knoten in hochverfügbarer Cluster-Variante
Ein weiterer technischer Meilenstein war die Umstellung des bis dato nur als Single Server installierten Controller-Knotens auf eine hochverfügbare Cluster-Variante, wie sie in der Suse Variante von OpenStack mitgeliefert wird. Hierbei werden alle kritischen Komponenten von OpenStack auf einem neuen „Pacemaker“-Cluster als Zwei- oder besser Drei-Knoten Variante hochverfügbar eingerichtet. Zu den kritischen Komponenten zählen unter anderem eine zentrale Datenbank mit „Postgress“ und ein schneller Message Service auf Basis von „Rabbit MQ“.
FIS-ASP nutzte Update-Fenster auf eine neue Version von „Suse OpenStack Cloud“, um diese Umstellung mit einer notwendigen Neuinstallation dieser Kernkomponenten auf einem Cluster erfolgreich durchzuführen.
Das Provider-Netz auf VLAN/VxLAN hält Cloud-Architektur einfach
Ein weiterer wichtiger Faktor im Setup war die Wahl der richtigen Netzwerk-Setups. Das im OpenStack verfügbare „Provider“-Netz erlaubt es, auf bewährte VLAN/VxLAN-Technologie aufzusetzen und die Cloud bewusst einfach in der Architektur, damit aber robuster im Betrieb zu halten.
Die Anzahl der Compute-Knoten lässt sich in OpenStack nun ohne Weiteres nach oben skalieren und wird durch eine Reihe von Features wie Verfügbarkeitszonen und Hochverfügbarkeit von Compute-Knoten ergänzt. Hinter den Verfügbarkeitszonen lassen sich Brandabschnitte im Datacenter oder abgesetzte Datacenter definieren, in denen die virtuellen Maschinen oder auch Landschaften laufen müssen.
In der jüngsten Version von Suse OpenStack Cloud kam die Hochverfügbarkeit von Compute-Knoten beziehungsweise spezifischer Workloads hinzu – eine wesentliche Voraussetzung für den Betrieb geschäftskritischer Systeme in der Cloud. Dies wurde über die Technologie in „Pacemaker-Remote“ möglich, die den bereits existierenden Cluster des Controller-Paars nutzt.
Was noch fehlte, war ein Shared Storage, um die Systeme ebenso verfügbar und performant zu halten, wie in einer traditionellen virtualisierten Umgebung. Verschiedene SAN- und NAS-Anbieter wurden ausgewählt und getestet. Gerade in der Anfangszeit gab es immer wieder Inkompatibilitäten zwischen den verfügbaren OpenStack zugehörigen „Cinder“-Treibern und dem „OpenStack Storage API“. Als zentrale Komponente von OpenStack kümmert sich Cinder um Blockstorage und deren Verwendung.
Ceph als Shared Storage
Die Lösung fand sich (wiederum im Umfeld von OpenStack) mit „Ceph“, einer der am weitesten verbreiteten softwaredefinierten Storage-Lösungen für OpenStack auf dem Markt. Ceph ist hochskalierbar, läuft auf Basis beliebiger Standardhardware und wurde analog der Cloud-Software als Standard Software Subskription von Suse als „Suse Enterprise Storage“ eingeführt.
Als Basis zog FIS-ASP eine Referenzarchitektur der Suse GmbH und der Thomas-Krenn AG heran, auf dessen Hardware sich ein Linux-basierender Ceph-Storage gut aufbauen lässt. Um den verteilten Zugriff von Datenbanken mit hoher Performance gerecht zu werden, sind in sechs Knoten jeweils zwei NVME Disks verbaut. NVME SSDs werden für das Journaling eingesetzt und sind dafür das ideale Medium: Sie sind hochperformant, können sehr viele permanente Schreibzugriffe bewältigen und haben eine extrem hohe Lebensdauer.
Images, Automatisierung, Standardisierung
Zielrichtung bei Cloud-Systemen sollte es generell sein, immer die jüngsten Versionen einzusetzen, insbesondere aus Sicherheitsaspekten heraus. Doch nicht jede Kombination aus System, Datenbank, Betriebssystem und verschiedenen Versionen ist sinnvoll im Hinblick auf Sicherheit, Stabilität, Performance und Kosten. Ein echter Mehrwert ist nur mit der richtigen Verbindung aus Standardisierung, Automatisierung und einer funktionierenden Image- und Versionsdatenbank zu erreichen.
Hier spielen OpenStack und Ceph mit ihrer offenen Architektur als Open-Source-Software ihre Stärken aus. Als Ergänzung kommen bei FIS-ASP weitere Open-Source-Anwendungen zum Einsatz wie „Github“-Software für die Versionsverwaltung der richtigen Images, „Salt“ zur Automatisierung der Nacharbeiten und „Heat“-Templates zum Aufbau der Virtual-Machine-Images zum Einsatz – alles aufeinander abgestimmt und gleichzeitig flexibel genug für die rauen Anforderungen des SAP-Betriebs.
Dabei ist es wichtig, dass die System-ID von SAP wählbar ist, ebenso wie die Domäne des Kunden oder die verwendeten Instanznummern. In OpenStack werden Kunden als so genannte Tennants angelegt und über die integrierte Firewall mit vordefinierten Regeln versorgt. In den letzten beiden Jahren hat SAP das API seines „SAP Software Provisioning Manager“ stabilisiert und besser dokumentiert. Der SWPM dient der Installation der SAP-Systeme, um die genannten Optionen (SAP SID, Domäne, Instanznummer… ) umzusetzen. Damit sind viele Installationen nun über Templates auswählbar und installierbar.
Matthias Braun, Head of Delivery SAP, der FIS-ASP GmbH, baute mit Partnern von Suse und der Thomas-Krenn AG sowie mit SAP- und Open-Stack-Software ein Service-Angebot für Mittelständler. (Bild: FIS-ASP)
Das Angebot von FIS-ASP
Auf Basis dieser Cloud-Infrastruktur ist die FIS-ASP in der Lage, ihren Kunden dedizierte Dienste in der Bereichen Infrastructure-as-a-Service, Platform-as-a-Service sowie Software-as-a-Service anzubieten – mit kurzen Implementierungszeiten neuer Systeme und Landschaften auch in komplexen Projekten. Im PaaS-Umfeld verschaltet der Hosting-Anbieter zum Beispiel mehrere SAP-Entwicklungssysteme für „SAP EWM“, „SAP Netweaver“ Gateways, Webdispatcher oder auch Backend ERP (respektive S/4) zu einem Verbund. Auf diesem können Entwickler und Kunden kurzfristig mit einer kompletten Entwicklungslandschaft starten.
Ein weiterer wichtiger und wachsender Bereich ist „SAP Hybris Commerce“. Der Shop eignet sich mit seinem (dem LAMP Stack ähnlichen) Setup gut für einen Einsatz in der Cloud. Mit LAMP (ein Akronym für „Linux, Apache, MySQL und PHP“) lassen sich dynamische Webseiten verfügbar machen. Die verschiedenen Komponenten von SAP Hybris mit den Datenbank-, Applikations-Servern für Frontend und Backend sowie weiteren Einheiten passen sich im Gegensatz zu SAP-Netweaver-basierenden Systemen sehr gut in die Cloud ein.
* Matthias Braun, Head of Delivery SAP, der FIS-ASP GmbH.