TDI Phase 5 – Hana doppelt so schnell

Mit TDI 5 können damit SAP-Kunden gemeinsam mit Hardware-Lieferanten ihre Hana-Server-Dimensionierungen oder -Konfigurationen eigenverantwortlich bestimmen. Ein gutes Stück weit zumindest. Ähnlich wie in SAP-Klassik-Zeiten. TDI 5 bringt für Kunden Kosteneinsparungen mit sich.

Lange waren SAP-Kunden angehalten, Hana ausschließlich als Appliance aufzusetzen und zu betreiben. Alles vom Design/Setup her in einer Box als vorkonfigurierte, vorinstallierte und getestete Systemlösung mit den Kernkomponenten (Layern): Server und Storage inklusive Linux als OS-Plattform, SAP-Software und auch Netzwerkfunktionalität.

Hauptvorteile aus SAP-Sicht dabei: alle Komponenten sind aufeinander abgestimmt beziehungsweise verprobt; Lösungsevaluierungen der als ScaleUp-Systeme als Single-Node oder ScaleOut-Systeme als Multi-node konzipierten Appliances nahmen SAP und Partner vor.

Entsprechend des jeweiligen Kundenbedarfs erfolgte ein Sizing, wenn man so will, eine Konfektionierung mit anschließendem Systemverbau und Testing sowie Installation und Betrieb.

Doch dann erfolgte ein Richtungswechsel respektive eine zusätzlich Design-/Setup-Option: nämlich durch dass sogenannte „SAP Hana Tailored Data Center Integration-Konzept“, kurz TDI.

Wer als SAP-Kunde wollte, konnte ab Herbst 2014 auf der Grundlage von TDI eine SAP-Hana-Systemumgebung (neben ScaleUp- auch ScaleOut-Systeme) zu einem Stück weit selbst designen oder aufsetzen.

Wobei sich die Hana-Design-Kernelemente von einer Appliance vor allem in der Gestalt unterscheiden, dass beim TDI-Ansatz sowohl Server, der Storage- und der Netzwerk–Layer mehr oder weniger frei gewählt werden kann.

Allerdings müssen die Server–, Storage- und Netzwerk–Systeme der verschiedenen Anbieter eine SAP-Zertifizierung aufweisen. Bis heute bleibt ausschließlich Linux das einzige in Verbindung mit Hana nutzbare Operating System, mit Suse SLES for SAP Applications, als der bevorzugten Betriebssystemplattform.

Quicksizer von SAP gibt vor

Nun geht es laut übereinstimmenden Informationen aus der SAP-Community mit der TDI Phase 5, kurz TDI 5, in eine neue Runde. Mehr noch. Demnach bedeutet TDI 5 eine Zäsur, man könnte es aber auch so sehen: SAP rudert in Sachen Hana-Server zurück. Und zwar in einen Zustand, ähnlich wie es bei SAP-Klassik, eben bei Netweaver-basierten Systemen, der Fall war.

Auf Nachfrage bei SAP-Partnern bringt TDI 5 nämlich mit sich, „dass SAP-Kunden bei der Dimensionierung ihrer Hana-Server wieder mehr Flexibilität oder Freiräume erhalten.

Jetzt können Kunde und Hardware-Lieferant zu einem ganz großen Stück weit wieder gemeinsam die System-Ausprägungen bestimmen und sie sind wieder gemeinsam dafür verantwortlich, vor allem bei den Core-Ausprägungen“, wie es ein Experte eines Hana-Hardwareherstellers formuliert. „Neu ist auch, dass die Begrifflichkeit SAPS wieder zurückkehrt“, wird berichtet.

Nach wie vor spuckt quasi demzufolge ein SAP-Tool namens Qucksizer die Hardware-Dimensionierungen aus, zuvorderst die Memory-Größe und die Core-Anzahl, und zwar kategorisiert gemäß T-Shirt-Größen.

Eben L, M und S. Zusätzlich mit TDI 5 jedoch werde auch wieder mit SAPSen gearbeitet, eine Einheit für das Leistungsvermögen eines SAP-Systems aus der SAP-Netweaver-/Klassik-Welt. Sie diene als eine Grundlage für die Bestimmung der notwendigen Core-Anzahl eines Hana-Systems. Wo mit SAPSen nicht gearbeitet werden könne, trete die sogenannte Core-to-Memory-Ratio in Aktion, so die Erklärungen.

Zusätzlich könne man bei einem Hana-Sizing neben dem Quicksizer auf den sogenannten Migration-Report zurückgreifen. Er zeige bei einem SAP-Klassik-Hana-Wechsel weiteres auf, zum Beispiel erzeugte Workloads und anderes mehr.

Eine damit verbundene wichtige Neuerung wird so beschrieben:

„Nun sind Kunden in der Lage zusammen mit ihrem Hardware-Lieferanten das entsprechende Sizing eigenverantwortlich zu bestimmen oder festzulegen, ob L, M oder S – mit einer niedrigeren Core-Anzahl als bislang und mit der Verwendung von kleineren Servern“.

Auch könne beispielsweise durch ein Hana-Data Load, ein Daten-In-Memory-Laden aus anderen Quellsystemen, dazu führen, dass anstelle einer M-Größe mit weniger Cores durch den Quicksizer vorgeschlagen oder festgelegt werde, eine L-Größe mit vielen Cores zu verwenden – man aber dennoch eine M-Größe mit weniger Cores nutzen könne.

Also, verständige man sich mit dem Kunden auf ein M-Size-System mit weniger Cores, weil ein Dataload an und für sich im laufenden Hana-Betrieb weniger häufig stattfindet und man sich gegebenenfalls Etwas Zeit damit lassen kann.

Mit anderen Worten:

Mit TDI 5 lassen sich laut den vorliegenden Informationen Cores einsparen. Was im Endeffekt zu einer Kostenreduzierung führe. Gerade die Verpflichtung, nämlich quasi überpowerte Hana-Systeme mit vielen Cores einsetzen zu müssen und von denen auch noch eine hohe Core-Anzahl praktisch nicht genutzt werde, sei mehrfach an SAP herangetragen worden, erklärt ein Szenenkenner und malt folgendes Bild:

„Es war und ist ja noch immer vielfach so, als läuft ein Sportwagen mit vielleicht 400 PS bis zum Anschlag hochtourig im Leerlauf, fährt aber kaum“. Konkret: von beispielsweise vorhandenen 120 Cores würden nicht einmal 20 genutzt.

Andererseits liegt auf der Hand, dass auch die Weiterentwicklungen bei den Prozessoren – neben stetig steigender Visualisierung –, die Leistungsfähigkeit von aktuellen Hana-Servern erhöht und aufgrund dessen auch weniger Cores bei gleicher Leistung verbaut werden müssen.

Im Intel-Umfeld (Hana-on-Intel) erzeugen die aktuellen Skylake-Prozessoren einen neuen Schub, ebenso im Hana-on-Power-Umfeld mit von IBM neuangekündigten Hana-Maschinen mit Power 9-Prozessoren.

Ohne Kundendruck nichts passiert

SAP-Kunden dürfte TDI 5 also erfreuen ob der Neuerungen, die in der Konsequenz zum einen Kosteneinsparungen bedeuten, zum anderen eine Art von Back-to-the Roots mit größerer Hana-Server-Selbstbestimmung oder mehr Flexibilität in Eigenregie.

Apropos Kunden. In den Gesprächen mit Experten aus der SAP-Community tauchte die Frage auf: Was hat SAP jetzt dazu bewogen, die mit TDI 5 verbundenen und die zuvor skizzierten Kernänderungen durchzuführen?

Praktisch unisono war Folgendes zu vernehmen: „Nur der Kundendruck hat SAP dazu bewogen, umzuschwenken“.

Ein Community-Mitglied, das wie andere nicht genannt werden will, gab folgende interessante Begebenheit zu Protokoll: Bei einem größeren SAP-Bestandskunden mit vielen Tochtergesellschaften sei es darum gegangen, Hana- beziehungsweise S/4-Lizenzen abzuschließen.

Die Company habe dies jedoch davon abhängig gemacht, weniger Cores verwenden zu dürfen als eigentlich vorgegeben. Und zwar in etwa so viele, wie bislang bei SAP-Klassik auch. Erst als dies von SAP zugesichert worden sei, habe man die SAP-Lizenzen abgeschlossen.

Warum SAP als Technologiewächter in Sachen Hana-Server-Hardware eigentlich seit jeher eine eher restriktive Linie bevorzugte, obwohl die Hana-Server an sich eigentlich leistungsmäßig mehr bieten als benötigt oder höher ausgereizt werden könnten (mit einer höheren Core-to-Memory-Ratio), wird von Community-Mitgliedern so beantwortet:

„Bei SAP hat man offenbar schlichtweg Angst davor, dass sich durch eine zu hohe Hana-Server- oder Core-Auslastung Hana-Datenbank-Responsezeiten nur um Bruchteile von Sekunden verschlechtern.“

„Kunden können sowohl vorhandene Power-Server als auch neue nutzen, da sich mit TDI 5 das Memory-to-Core Verhältnis deutlich verbessert. Es müssen weniger Cores für die gleiche Menge Memory eingesetzt werden.

So kann sich der Server-Footprint reduzieren weil unter Umständen weniger Server erforderlich sind sowie sich die Kosten für die Aktivierung und die Wartung von Cores sinken können.

Für das Sizing aller neuen Angebote, aber auch für Kunden, die schon Hana-on-Power nutzen (Re-Sizing nach TDI 5), kann die Hardware effizienter und kostengünstiger genutzt werden.

MIt dem Wechsel von TDI 4 mit Core to Memory nach TDI 5 mit SAPSen ergibt sich eine deutlich verbesserter, fairerer, verringerter und damit für den Kunden kostengünstigerer Ressourcenbedarf der benötigten CPU-Kapazität sowie so eine verbesserte Prozessorauslastung der Hana-on-Power-Systeme.

Dies bedeutet ein deutlicher Schritt in die richtige Richtung, was den Ressourcenbedarf an vorzuhaltender Rechenleistung anbelangt, und vor allem auch die wiedererlangte Verantwortung des Kunden für die Beschaffung und Nutzung von Rechnerressourcen in Zusammenarbeit mit dem Hersteller und dem Business Partner, wie es seit jeher für die klassischen SAP-Systeme der Fall ist.“

„Hana TDI 5 hat auf den ersten Blick keine große Auswirkungen für mit VMware virtualisierte Hana-Umgebungen. Bereits vor TDI 5 ermöglichte der Einsatz von VMware vSphere für Hana den Kunden, Hana-Server-Systeme stärker und flexibler auszulasten, als die festen Hana-Appliance-Server-Konfigurationen.

Vor TDI 5 war der einzige Faktor zur Leistungsberechnung der benötigte Arbeitsspeicher einer Hana-Instanz. Die dazu festgelegte CPU-Konfiguration, wurde über das sogenannte Core-to-Memory-Ratio beschrieben.

Mit TDI 5 kann die zu erwartende Arbeitslast in SAPS berechnet und über diese Angabe bestimmt werden, wie groß der Arbeitsspeicher eines Hana-Systems (physikalische oder virtuelle Hana) maximal werden darf.

Nun ist es möglich, Hana-VMs zu konfigurieren, die an die 4-TB-Grenze heranreichen. Die zusätzliche Flexibilität, welche TDI 5 für die Konfiguration einer Hana-VM bringt, macht das regelkonforme Konfigurieren einer VM komplexer.

VMware hat ein Konfigurationswerkzeug entwickelt, welches neben dem bestehenden SAP Hana-Appliance-T-Shirt-Sizing auch einen SAPS basierenden Ansatz unterstützt und diese Sizings als Basis für die Erstellung von konformen Hana-VM-Konfigurationen verwendet und diese somit erleichtert.

Diese Standardisierungsinitiative wird zurzeit von VMware und SAP im SAP Sizing Meeting mit allen SAP-Technologiepartnern diskutiert. Aus Kundensicht ändert sich mit TDI 5 aus VMware-Sicht auf den Punkt gebracht, Folgendes: mehr RAM per Hana-VM ist möglich (abhängig vom SAPS Sizing), mehr Hana-RAM per VMware-CPU-Lizenz, bessere Ausnutzung bestehender Server Ressourcen und Nutzung, gegebenenfalls kann ein kleinerer CPU-Typ (weniger CPU-Kerne) verwendet werden oder es ist kein Hardwarewechsel aufgrund von RAM-Limitierungen mehr notwendig.

Jedes Sizing, mit oder ohne TDI 5, sollte als ein iterativer Prozess (Plan, Do, Check, Act) angesehen werden, da sich Systeme über deren Lebenszeit verändern. Die VM-Konfiguration sollte entsprechend dieser Änderungen angepasst werden. Die Möglichkeit mehr RAM pro CPU-Ressourcen, oder kleinere CPUs zu nutzten. bringt Flexibilität und spart letztendlich bares Geld!“

„SAP TDI Phase 5 verändert nicht die Core to Memory Ratio: Die liegt nach wie vor bei 768 GB für BW beziehungsweise 1,5 TB für SoH (für Skylake Prozessoren).

Neu ist, dass sowohl der Quicksizer bei neuen Systemen als auch der Sizing-Report bei vorhandenen Systemen einen SAPS-Wert ausgeben. Mit dieser Angabe ist es möglich, eine kleinere und damit kostengünstigere Lösung zu wählen.

Ziel der SAP ist es, neben der Adressierung von Memory, dass Kunden die CPU entsprechend ihrem Bedarf auswählen können und damit Konfigurationen mit zu starken (überdimensionierten) Prozessoren vermeiden. Nach unten ist das Verfahren durch die Anforderung von minimal 8 Cores pro CPU abgesichert.

Für HPE als Hersteller bietet sich dadurch die Möglichkeit, bedarfsgerechte und damit kostenoptimierte Lösungen anzubieten. Es geht bei TDI Phase 5 um Optimierung – noch mehr CPU-Leistung wird derzeit im Hana-Markt nicht benötigt. Die Adressierung von Memory steht nach wie vor im Fokus.“

„TDI 5 schreibt die Optimierungen, die SAP mit Tailored Datacenter Integration bei der SAP-Hana-Server-Nutzung ganz generell eingeführt hat, abermals fort. SAP-Kunden sind damit in der Lage, noch flexibler ihren individuellen Bedarf in punkto IT-Infrastruktur zu handhaben.

Aus Kundensicht, auch für SAP-Serviceprovider, bringt dies Nutzenvorteile mit sich, bis hin zu Kostenvorteilen. Suse als langjähriger SAP-Partner unterstützt bekanntlich sowohl den Appliance-Gedanken als auch den Tailor-Datacenter-Integration (TDI)-Ansatz von SAP.

Dabei arbeitet Suse als bevorzugter und ausgewählter Linux-Lieferant mit SLES for SAP Applications ebenfalls mit den Hana-on-Intel-Anbietern sowie mit IBM-Hana-on-Power-Systemen selbstverständlich eng zusammen.

Was Entwicklungen anbelangt, aber auch tagtäglich in SAP-Hana-Projekten oder in Projekten bei denen der Einsatz von Hana-basierten Anwendungslösungen wie etwa SAP S/4 Hana im Mittelpunkt stehen “

„Mit TDI Phase 5 eröffnet SAP die Möglichkeit, Hana-Infrastrukturen bedarfsgerecht an dem kundenspezifischen Workload auszurichten. Fujitsu nutzt durch intelligente Konzepte die gewonnenen Spielräume um die Investitionen in eine SAP-IT-Infrastruktur zu optimieren und den ROI der Gesamtlösung SAP Hana zu verbessern.

Durch die bisherige Bindung des Arbeitsspeichers an die verwendete CPU hat sich in vielen Fällen bei den Kunden eine unzureichende Auslastung der in den Systemen verwendeten Prozessoren ergeben. Speziell bei Suite-on-Hana-Anwendungen sind CPU-Auslastungen während des Standardbetriebes von 10 bis 15 Prozent nicht unüblich.

Durch TDI Phase 5 ergeben sich nun folgende zusätzliche Möglichkeiten, nämlich: eine Bedarfsermittlung mit dem SAP Quicksizer, bei dem auf Basis von empirischen Daten zu erwartende Leistungsanforderungen hinterlegt sind. Anhand dieser Daten kann im Vorfeld einer Hana-Neuinstallation ein Eindruck von den zu erwartenden Anforderungen gewonnen werden.

Die Angabe der SAPS-Werte für den Datenbankserver ergeben dabei eine in der Regel größere Arbeitsspeicherausstattung pro CPU und einhergehend quasi “mehr Hana/Euro“. Zusätzlich kann das Verhältnis von CPU zu Arbeitsspeicher ganz individuell an den Kunden angepasst und eine optimale Auslastung der Infrastruktur erreicht werden.

Durch TDI Phase 5 ist der Kunde de facto von dem festen Verhältnis zwischen CPU und Memory entkoppelt, die einzigen Beschränkungen bestehen in der Verwendung von für SAP Hana frei gegebenen Systemen. Das führt zu einer verbesserten Core to Memory Ratio und zu einem verbessertes Preis-/Leistungsverhältnis.

Beispielsweise kann für eine Hana-Datenbank mit einem Hauptspeicherbedarf anstatt eines vier CPU-Systems ein zwei CPU-System ausgewählt werden, das den Anforderungen in Punkto SAPS-Leistung genügt.

Über den reinen Betrieb der SAP Hana-Datenbank hinaus bietet Fujitsu für seine Kunden auch die Integration in ein Betriebsmodell an das Hana homogen in die Arbeitsabläufe einbindet und es aus seiner Sonderrolle entbindet.“