SAP – Adaptives Design, die wertvolle Unterstützung

Für viele Nutzer ist es heutzutage kaum noch vorstellbar, dass ein Service oder eine Applikation längere Zeit nicht zur Verfügung steht. Diese Tatsache begegnet uns sowohl im privaten als auch im beruflichen Kontext. Aus dieser Erwartung erwächst für viele Kunden die Aufgabe, IT-Services, darunter auch die SAP Services, so verfügbar wie möglich zu gestalten. Solange keine Änderungen am System notwendig sind, funktioniert das auch weitestgehend problemlos. Die Realität zeigt aber, dass „am Ball bleiben“, also die Systeme und die darunterliegenden Systemkomponenten aktuell zu halten, eine nicht zu unterschätzende Daueraufgabe für den täglichen Betrieb darstellt. Nur so kann eine sichere und stabile Systemlandschaft bereitgestellt werden. SAP bietet mit dem adaptiven Design einen Architekturvorschlag für SAP NetWeaver-basierte Systeme, um ihren Kunden die Möglichkeit zu bieten, eine Vielzahl an Wartungsarbeiten vorzunehmen, ohne den SAP-Service unterbrechen zu müssen.

Das adaptive Design von SAP bietet außerdem den Vorteil, dass Systeme bei steigenden Leistungsanforderungen sehr leicht skalieren können. Die Integration weiterer SAP Applikationsserver oder der Umzug der Datenbank auf leistungsfähigere Hardware stellt durch die richtige Wahl der SAP-Architektur in der Zukunft keine Probleme dar. 

Das adaptive Design

Laut SAP basiert das Konzept des adaptiven Designs auf der logischen Zuordnung dedizierter virtueller IP-Adressen und Hostnamen sowie dynamischer Speicherlayouts zu bestimmten Anwendungen. Es werden dabei einzelnen SAP- und Datenbankinstanzen idealerweise eigene Netzwerk- und Speicherressourcen zugeordnet [1]. Das bedeutet, dass jede Systemkomponente eines SAP-Systems (z. B. die Datenbank, die A-SCS und der Applikationsserver) separate virtuelle IP-Adressen und separate Speicherbereiche zugeordnet bekommt. Dies bietet den Vorteil, dass eine klare Trennung zwischen der Betriebssysteminstanz und der Applikationskomponente erfolgt. 

Bildlich gesprochen ist es ein Sattelschlepper (Betriebssystem) und ein Auflieger (Applikationskomponente). Der Sattelschlepper kann den Auflieger unkompliziert abhängen, einen anderen Auflieger aufnehmen und an sein Ziel bringen. Andererseits kann auch ein anderer Sattelschlepper an den Auflieger andocken und zu der gewünschten Destination befördern. Besonders leistungsfähige Sattelschlepper könnten theoretisch sogar mehrere Auflieger bewegen. So ähnlich verhält es sich auch mit dem adaptiven Design. Durch die klare Trennung kann jede SAP-Systemkomponente mit wenig Aufwand an eine andere Betriebssysteminstanz gebracht werden. Verschiedene Applikationskomponenten können ebenfalls auf einem Betriebssystem ausgeführt werden. So erhält man eine maximale Modularisierung und Flexibilität. 

Folgende Voraussetzungen sind notwendig:

  • die Verwendung eines zentralen Speichers, um die Applikationsdateien an den Betriebssysteminstanzen bereitzustellen,
  • virtuelle IP-Adressen für jede Applikationskomponente müssen vergeben werden,
  • Forward- als auch Reverse-Lookups müssen funktionieren,
  • Verwaltung der Betriebssystemnutzer und -gruppen in einem zentralen Identitätsmanagementsystem,
  • Nutzung eines zentralen NFS-Servers zur Bereitstellung der globalen SAP- und Schnittstellenverzeichnisse (z. B. /sapmnt und /usr/sap/trans) und
  • Standardisierung der Architektur Ihrer SAP-Landschaft.

Um das Potential nutzen zu können, müssen auch alle Verbindungen zum SAP-System über die „Nabe“ des SAP-Systems geleitet werden. Die A-SCS spielt hier die zentrale Rolle. SAPgui-, HTTP- und auch RFC-Requests müssen durch die Prozesse der A-SCS inklusive des integrierten WebDispatchers als auch Gateway geleitet werden.  Dies ist ausschlaggebend für die Flexibilität bei Wartungsarbeiten an den SAP Applikationsservern. Das i-Tüpfelchen ist, wenn auch alle ausgehenden Schnittstellenverbindungen über die virtuellen IP-Adressen kommunizieren. Änderungen an SAP-Profilparametern ermöglichen dies. So erreicht man die volle Adaptivität [2].

Abb. 1: Schematische Darstellung des adaptiven Designs

Wartungsfähigkeit erreichen

Durch die Umsetzung des adaptiven Designs können u. a. folgende Wartungsaufgaben unterstützt werden:

  • Die Betriebssystemaktualisierung erfolgt bei A-SCS und SAP HANA Datenbank zuerst auf der sekundären Seite. Nach Aktualisierung wird sowohl A-SCS als auch SAP HANA Datenbank auf der zweiten Seite aktiviert. Nun ist das Betriebssystem der primären Seite bereit für die Aktualisierung. Der SAP Systemservice ist über die sekundären Systeme erreichbar. Eine n-fache Verfügbarkeit der SAP Applikationsserver erlaubt es, diese nacheinander aus der Lastverteilung zu entfernen, zu stoppen und zu aktualisieren. Nach erfolgter Arbeit werden die Systeme wieder in den Normalbetrieb integriert. Alternativ können auch neue Betriebssysteme deployed werden. Die Applikation wird dann einfach an die neuen Instanzen „gehängt“.
  • Datenbankaktualisierung: SAP HANA Datenbanken, welche durch die SAP HANA System Replication abgesichert werden, können in der folgenden Sequenz aktualisiert werden:
    • Aktualisierung der sekundären Seite,
    • Schwenk von der primären auf die sekundäre Seite des Datenbank-Service (Dabei werden die internen Strukturen auf die neue Version gebracht),
    • Etablieren der System Replication von der sekundären auf die primäre Seite,
    • Aktualisierung der primären Seite.

Im Nachgang kann dann der Ausgangszustand der Systemverteilung durch eine bewusste Umschaltung wiederhergestellt werden.

  • SAP-Kernel-Aktualisierung: SAP bietet mit der Methode des Rolling Kernel Switch (RKS) die Möglichkeit, einzelne SAP-Applikationsserver mit einem aktuellen Kernel zu versorgen. Durch die Nutzung von SAP Logon Gruppen, Batch Server Gruppen und Load Balancern können die Applikationsserver im Vorfeld aus der aktiven Verteilung neuer Verbindungen ausgeschlossen werden. Sobald der Server „leergeräumt“ ist, kann das System in Wartung genommen und aktualisiert werden.
  • SAP-Parameteränderung: Die Änderung von SAP-Parametern erfordert ggf. einen Neustart des Anwendungsservers zur Aktivierung der Parameter. Hier greift das gleiche Konzept wie bei der SAP-Kernel-Aktualisierung.

Rüstzeug für den Fehlerfall

Im Fehlerfall unterstützt das adaptive Design ebenfalls, um den Systemservice schnell wieder bereitzustellen. Applikationsserver werden redundant ausgestattet, sodass hier kein Gesamtsystemausfall auftritt. Die Single Point of Failures (SPoF) werden durch technische Methoden abgesichert, um im Fehlerfall die Möglichkeit zu besitzen, den Service wieder bereitzustellen. Notwendige Daten der A-SCS werden auf einem shared Storage bereitgestellt. Die Datenbank wird per SAP HANA System Replication repliziert. So besteht die Möglichkeit, auch im Fehlerfall die gleichen Methoden wie bei der Wartung zu nutzen. Das Vorgehen ist vertraut und bietet die Gelegenheit, kompetent auf Fehlersituationen zu reagieren. Die Umschaltung erfolgt entweder manuell oder automatisch, durch eine Cluster-Software gesteuert. Eine bewusste Entscheidung der Umschaltung ist dem komplexen automatischen Prozess vorzuziehen. Die SAP stellt in dem KBA 2063657 – SAP HANA System Replication Takeover Decision Guideline eine Entscheidungsgrundlage für den Take-over der Datenbank zur Verfügung. Die Reduzierung der Komplexität durch Verzicht auf eine komplexe Clusterlösung führt zu einem stabileren Betrieb der Gesamtlandschaft.

Nebenwirkungen des adaptiven Designs

Neben den zahlreichen Vorteilen birgt diese Architektur aber auch einige zu bedenkende Herausforderungen. Durch die strikte Trennung der Applikationen durch eigene Filesysteme und IP-Adressen benötigt man eine erhöhte Anzahl dieser Ressourcen. Oft wird auch jede SAP-Komponente (Datenbank, A-SCS, Applikationsserver) auf eigenen virtuellen Instanzen betrieben. Dies erhöht den Aufwand im Bereich der Instanz- und Betriebssystempflege. Es ist zu beachten, dass bei Cloud-Deployments (Infrastructure as a Service) für das adaptive Design eine größere Anzahl an virtuellen Instanzen benötigt wird. Dies führt zu weiteren Kosten durch notwendige Betriebssystemlizenzen sowie zu einem höheren Hauptspeicher- und Storageverbrauch. Bei On Premise-Lösungen sind pauschale Lizenzmodelle ebenso wie kalkulierte Hauptspeicher- und Storagereserven möglich. Bei Cloud-Deployments ist daher die Granularität des adaptiven Designs gegenüber den Kosten abzuwägen.

Außerdem kann die Umsetzung dieser Architekturidee in einer bestehenden Landschaft auf Hindernisse stoßen, da die passenden Infrastrukturkomponenten vorhanden sein müssen, um die Anforderungen umsetzen zu können. Hier kann eine notwendige Hardwareerneuerung oder eine Migration der Systeme hin zu SAP HANA als Chance genutzt werden, das adaptive Design in Ihrer Landschaft umzusetzen.

Die SAP bietet mit dem SAP Landscape Management (SAP LaMa) ein Werkzeug, um Ihre SAP-Landschaft innerhalb einer Oberfläche zu verwalten und zu automatisieren. Um den größten Nutzen aus dem SAP LaMa ziehen zu können, empfehlen wir die Umsetzung des adaptiven Designs.

Heute an morgen denken

Die richtige SAP-Systemarchitektur kann Sie dabei unterstützen, die Verfügbarkeit Ihrer Anwendungen maßgeblich zu verbessern. Notwendige Wartungsarbeiten sorgen, durch verfügbare Redundanzen und Methoden der Absicherung der Single Point of Failures, nicht mehr dafür, dass der gesamte Service nicht verfügbar ist. Aufgaben können während der normalen Bürozeiten durchgeführt werden und Wochenendeinsätze Ihrer Mitarbeiter reduzieren. Dadurch wird der Grundstein für eine stabile, verfügbare und sichere SAP-Landschaft in Ihrem Unternehmen gelegt.

 

Quellen:

[1] https://help.sap.com/viewer/3f4bd9fa1c9c4d9c8df4fb0d2d34b4be/3.0.13.0/de-DE/737a99e86f8743bdb8d1f6cf4b862c79.html

[2] https://dsagnet.de/dsag-resource?id=91650&app=forum&embeddedObjectId=113586&embeddedObjectEntityType=4

Adaptives Design – intern
Wartungsszenarien – intern