Problemlöser Schichtenmodell

Wer sich die jüngsten Verkaufsquartalszahlen zum Unix-Servermarkt zu Gemüte geführt hat, den kann schon ein Hallo-Effekt befallen.

Der Rückgang hält nämlich weiter an, um es nett zu formulieren. Demgegenüber steigen die x86-Serververkäufe.

Dieses Bild passt in das Faktische. Vor allem vor dem Hintergrund, dass sich immer mehr IT-Anwender von Unix abkehren und in Richtung Linux wechseln. Das gilt natürlich auch für die SAP-Community.

Ein Aspekt treibt die Anwender dabei allerdings um: Bekanntlich können bei einer Unix–Linux–Migration und einer Eins-zu-eins-Übertragung der Unix–SAP-Architektur die Datenbanklizenzkosten durch die hohe Anzahl der Intel Cores explodieren.

Vor allem wenn die Datenbankschicht ungetrennt übertragen wird. Hier spielen als Side-Effekt auch Hochverfügbarkeitsaspekte in den jeweiligen Schichten eine nicht unerhebliche Rolle.

Clevere Lösung

Was kann man also tun, um diesen Kosten ein Schnippchen zu schlagen?

Ein Ansatz zur Optimierung besteht darin, das aktuelle SAP-Architekturdesign zu prüfen und daraus eine Trennung der Anwendungsschichten abzuleiten.

Das heißt, man hat so die Möglichkeit, für die Datenbank nur noch Rechenleistung zu lizenzieren, die durch die Datenbank wirklich verbraucht wird und nicht Core-mäßig.

Kurz zur Erläuterung, was unter einem Schichtenmodell verstanden wird: Hierbei teilt man die SAP-Landschaft in drei Ebenen auf: in die Applikationsserver-Schicht, in die Central-SAP-Services-Schicht und die Datenbank-Schicht.

Ziel ist es, die Anzahl der Cores, die für die Datenbankschicht benötigt werden, zu reduzieren – um die Lizenzkosten für die Datenbankschicht zu minimieren. Interessant ist diese Art von Design-Optimierung für Kunden, die Datenbank-Direktverträge mit Core-basierter Datenbank-Lizenzierung eingegangen sind.

Und: Die Einführung eines Schichtenmodells lohnt sich in aller Regel ab fünf Produktionslinien und 15 Instanzen/SIDs.

Wichtig ist außerdem: Bei der Einführung eines SAP-Schichtenmodells sind gewisse Parameter zu prüfen. Vor allem, weil sich unter den genannten fünf Produktivlinien und weniger als 15 SAP–Instanzen ein derartiges Re-Design nicht rechnet.

Der Hauptgrund: Es werden mehr OS-Partitionen pro SAP-ID-Instanz benötigt. Was bedeutet, dass eine höhere Anzahl von physischen Servern notwendig wird.

Fällt der Check positiv aus und findet ein Re-Design statt, wird dann quasi die Physik optimiert, und zwar mittels SAP–Virtualisierung.

Im Endeffekt wird durch die Optimierungsmaßnahme weniger Physik erforderlich, sprich: es werden weniger Server benötigt.

SAP-Central-Services-Schicht

Bei einem Re-Design auf Basis eines Schichtenmodells können Single Point of Failures (vor dem Hintergrund von HA-Aspekten) durch Enqueue Replication und Message Server Clustering eliminiert werden.

Es macht Sinn, hier auf die zertifizierte Variante der SAP-Cluster-Referenzarchitektur zurückzugreifen. Die SAP NetWeaver High Availability Cluster 7.30 Certification (Referenzarchitektur) beschreibt das Zusammenwirken des SAP Control Frameworks mit dem sap-startsrv.

Kernpunkt dabei ist, dass mittels sapcontrol über den sapstartsrv sowie via SAP_SUSE Cluster Connector die Kommunikation zum Cluster Framework definiert wird.

Die Clusterkomponente nennt sich bei Suse HA Extension. Wobei die HA Extension die Kommunikation zum SAP Instance Resource Agent sicherstellt, der wiederum mit sapcontrol verbunden ist.

Über SAP Instance Resource Agent ist ferner SAP LVM mit dem SAP Control Framework gekoppelt.

Was die Applikationsschicht betrifft, werden Skalierbarkeit und Hochverfügbarkeit durch multiple Dialoginstanzen erzeugt.

Fällt ein SAP-Applikationsserver aus, so kann dieser einfach wieder generiert und anschließend hochgefahren werden.

Hana kein Kostentreiber

Nebenbei bemerkt: Mit Suite on Hana wird es möglich, immer mehr SAP-Module auf Hana zu betreiben.

Durch den Kompressionsfaktor von 1:5 und durch den Hana-Betrieb in Verbindung mit der Suse–Intel–Infrastruktur ist die Lizenzierung der Hana–Datenbank nicht Core-basiert und stellt somit keinen Kostentreiber dar.

Um weitere Kriterien für die Durchführbarkeit der SAP-Landschaft auf der Grundlage eines Schichtenmodells zu evaluieren und die Hochverfügbarkeit gemäß der NetWeaver High Availability Cluster 7.30 Certification zu arrondieren sowie die damit verbundene Integration in den SAP LVM auszuloten, ist empfehlenswert, sich mit der Studie zum Thema von Realtech zu befassen.