Praktische Erfahrung mit Hana on Power

Durch das „Appliance-Hana-System“ ergab sich bei Kunden, die es gewohnt waren, dass ein klassisches System in unserer Private Cloud binnen weniger Wochen bereitgestellt werden konnte, für ein Hana-System weit über einen Monat Wartezeit, weil die Appliance in der jeweiligen Größe beim Hersteller erst gebaut werden, eingeflogen und zolltechnisch behandelt werden musste, bis sie in unserem Cloud- Rechenzentrum eingebaut werden konnte.

Dort gab es dann das Problem, ein „Bare Metal“-System als „kundenindividuelle Sonderlocke“ in eine Umgebung einzufügen, die auf Standardisierung, Virtualisierung und automatisiertes Deployment optimiert war. Vom Monitoring, Patching und Erweitern ganz zu schweigen.

Hana-T-Shirt-Sizes

Durch die rigide Beschränkung auf T-Shirt- Sizes war zudem keine Feinabstimmung auf die Bedürfnisse der Kunden möglich, Flexibilität ist leider ein Fremdwort für Appliances! Man musste beim Memory immer nach oben aufrunden und dabei raten, was der Kunde wohl in drei Jahren brauchen könnte, was natürlich zu wesentlich höheren Beschaffungskosten führte.

Bei vielen Kunden standen wir zudem vor dem Problem, dass deren Hauptspeicherbedarf dann doch viel schneller stieg als erwartet. Der einzige Weg, eine Appliance „aufzurüsten“, ist aber, physikalisch mehr DIMMs und CPUs einzubauen – wenn das ursprünglich gewählte Motherboard dafür noch Platz hatte. War das nicht der Fall, musste eine größere Appliance beschafft werden.

Never Touch a Running Appliance

Hierbei mussten wir dann die Erfahrung machen, dass die alte Computerweisheit „Never Touch a Running System“ immer noch Gültigkeit hat. Da zusätzliche DIMMs und CPUs mit einem gewissen Kraftaufwand in ihre Fassungen gedrückt werden müssen und sich dabei das Motherboard etwas durchbiegt, konnte es sein, dass an einer anderen Stelle ein Stecker aus der Buchse poppte.

Beim Versuch, wieder zu booten, waren dann plötzlich nicht mehr alle Lüfter betriebsbereit oder das System war gar nicht mehr zum Leben zu erwecken, was wieder den Einsatz von Servicetechnikern von Herstellern notwendig machte – und das alles, während der Kunde darauf wartete, wieder arbeiten zu können!

Alles in allem eine für alle Beteiligten unbefriedigende Situation – Hana als Appliance war einfach ein Widerspruch zur Cloud. Vielleicht ein Grund für die in den ersten Jahren niedrigen Implementierungszahlen von Hana.

Tailored Datacenter Integration

Glücklicherweise gelang es den Hardwareherstellern mit der Hilfe einiger großer Kunden, SAP nach und nach zum Aufweichen des rigiden Appliance-Modells zu bewegen. In der ersten Phase durften externe Storage Arrays genutzt werden statt interner Platten, später durften für kleine Systeme die preiswerteren E5-Prozessoren verwendet werden, gefolgt vom Support von VMware und schließlich IBM Power – alles unter dem Label: Tailored Datacenter Integration (TDI).

Maßanzug statt Zwangsjacke

Dadurch ergab sich auch für uns die Gelegenheit, den SAP-Bestandskunden statt einer Zwangsjacke von der Stange einen flexiblen Maßanzug zur Verfügung zu stellen, der sich zudem in eine moderne Pri­vate-Cloud-Umgebung einfügte. Aber auf welcher Plattform?

Ein Abgleich der Restriktionen von Intel mit VMware gegen IBM Power mit „eingebauter“ Virtualisierung ergab Unterschiede in der möglichen Größe und Anzahl virtualisierter Hana-Systeme.

Zudem hatten mehrere Kunden signalisiert, dass sie wesentlich mehr Memory benötigten als die zu diesem Zeitpunkt auf den üblichen 4-Socket-Intel-Systemen möglichen 3 TB. Und das Ganze „as single instance as possible“, da man mit Scale-out nicht gerade die besten Erfahrungen gemacht hatte.

Auf dieser Grundlage und aufgrund der im Unternehmen vorhandenen Erfahrung mit IBM Power fiel die Entscheidung für die Beschaffung von zwei Maschinentypen: die S824L für Hana-Systeme bis zu 2 TB sowie E880 für alles, was größer war. Später kam dann noch eine E850 hinzu, die sich mit ihren 4 TB als ideales „Brot und Butter“-Arbeitspferd etablierte.

In der „Linux only“-Version, wie sie für Hana benötigt wird, sind Power-Maschinen zudem wesentlich preiswerter als für AIX. Diese Entscheidung erwies sich innerhalb kurzer Zeit als voller Erfolg – sowohl aus technischer als auch aus kaufmännischer Sicht.

Virtualisierung

Durch die aus der Mainframe-Welt stammende Virtualisierung (Wer erinnert sich noch an MVS?) auf Firmware-Ebene konnten die sonst bei 3rd-Party-Virtualisierungen üblichen Verluste durch zusätzliche Latenzen vor allem im IO vermieden werden – für Hana bedeutet das „bare metal performance“.

Sowohl das Memory als auch die CPU-Leistung lassen sich bis auf 1 MB und 1/20-Core-Ebene an die Kundenbedürfnisse anpassen. Da Hana-Systeme in der Regel nur einen Bruchteil der CPU-Leistung benötigen, die vom SAP-Regelwerk als „Angststahl“ vorgegeben wird, kann man die überschüssige CPU-Leistung in einen von allen auf der Maschine laufenden Hana-Systemen gesharten Pool geben. (Als Angststahl bezeichnen Bauingenieure eine völlig überdimensionierte Armierung von Stahlbeton, um „tausend Prozent“ sicherzugehen, sodass der Bauherr nicht einen Prozess wegen Rissen in der Wand anstrengt.) Aus diesem kann sich ein System, das dann doch einmal mehr Power braucht als gedacht, bedienen, ohne dass dem Kunden dafür zusätzliche Kosten entstehen.

Im Prinzip könnte man auch das Memory dynamisch anpassen, wenn Hana nach einer Reduktion des Memorys nicht versuchen würde, auf nicht mehr vorhandene Ressourcen zuzugreifen. Daher empfiehlt es sich, bei Änderungen der Memory-Ressourcen Hana durchzustarten.

Als besonders segensreich hat sich LPAR Live Mobility erwiesen, mit dem auch sehr große Hana-Systeme im laufenden Betrieb von einer Maschine auf eine andere verschoben werden können.

Auch wenn die Po­wer-Hardware extrem stabil läuft, kommt es bei einem größeren Maschinenpark schon rein statistisch dazu, dass einmal ein Problem auftritt, das den Austausch einer Komponente erfordert. Glücklicherweise waren bis jetzt alle aufgetretenen Probleme so freundlich, sich vorher anzukündigen, oder wurden durch Redundanz abgefangen.

Dadurch waren wir dank Live Mobility in der Lage, die fraglichen Maschinen im laufenden Betrieb von Kundensystemen freizuräumen, das fragliche Motherboard oder die Netzwerkkarte auszutauschen und danach die Systeme zurückzuschieben, ohne dass der Kunde etwas davon mitbekommt.

Sogar ein kompletter Wechsel der Architektur von Shared Cluster zu SAN boot, wo rollierend jede einzelne Maschine im Verbund einmal freigeräumt und umkonfiguriert werden konnte, war möglich, ohne den Betrieb der Kunden zu beeinträchtigen.

Memory-Tetris

Besonders begeistert haben sich Vertrieb und Kunden gezeigt, da es mit etwas vo­rausschauender Planung gelang, immer genügend Reserven vorzuhalten, um auch mittelgroße Hana-Systeme ad hoc zur Verfügung zu stellen, indem freie Slots auf den Maschinen aufgefüllt werden. Und wenn auf keiner Maschine ein Slot frei war, der groß genug war, konnte man durch Rochaden kleinerer Systeme immer genügend freiräumen.

Das Ganze erinnert sehr an das Computerspiel Tetris, bei dem Klötzchen unterschiedlicher Größe „vom Himmel fallen“ und so verteilt werden müssen, dass eine „dichteste Kugelpackung“ entsteht.

So ähnlich machen wir das im Hana-Betrieb. Was da „aus heiterem Himmel“ fällt, sind die Kundenanforderungen nach neuen Hana-Systemen in jeder beliebigen Größe, die alle schon gestern zur Verfügung stehen sollen.

Wie beim Computerspiel wird durch geschickte Verteilung dafür gesorgt, dass das Memory aller Maschinen in kürzester Zeit zu fast einhundert Prozent ausgenutzt wird, was wiederum den CFO freut, auch wenn er ständig professionell jammert, dass wegen immer weiter steigender Kundennachfrage alle paar Wochen neue Maschinen gekauft werden müssen, um wieder freie Slots zu bekommen.

Durch geschicktes Umverteilen ist es genauso möglich, die laufenden Kundensysteme an den realen Bedarf anzupassen. Über unser „Hana Memory Observatory“ können wir SAP-Bestandskunden einen ­Forecast geben, wann es notwendig wird, einem Hana-System mehr Hauptspeicher zu allokieren, um den berüchtigten Abbrüchen großer Reports wegen „Out of Memory“ (OOM) zuvorzukommen.

Was viele Kunden darüber hinaus schätzen, ist, dass sie für PoCs auch größere Hana-Systeme temporär nutzen können. Wenn der PoC vorbei ist, werden die Ressourcen zurück in den Pool gegeben und es entstehen keine weiteren Kosten.

Damit muss der Kunde auch bei großen Hana-Systemen immer nur das bezahlen, was er aktuell benötigt – ganz im Gegensatz zu den Cloud-Providern, wo man große Hana-Instanzen, die nicht auf deren Standard-Blades passen, drei Jahre im Voraus buchen und bezahlen muss.

Der einzige Wermutstropfen ist hier, dass auf einer Power-Maschine mit z. B. 4 TB nicht 4096 GB zur Verfügung stehen, da die Virtualisierung selbst einige GB verbraucht. In den meisten Fällen ist es aber möglich, sich mit dem Kunden da­rauf zu einigen, dass 1 TB gleich 1000 GB ist – dann geht das ganz bequem.

Mit den neuen IBM-Power-9-Maschinen, die mit 4 Sockets maximal 16 TB und mit bezahlbaren DIMMs immerhin 8 TB zur Verfügung stellen, verbessert sich die Möglichkeit zur Optimierung der Systemlandschaft weiter.

Fazit

Durch Hana on Power ist es uns gelungen, Hana flexibel und kosteneffizient in eine Private Cloud zu integrieren und damit die Zufriedenheit von Kunden, Vertrieb und auch der Finanzabteilung enorm zu steigern.

Flexible Systemgrößen, schnelle Verfügbarkeit neuer Systeme und temporäre Nutzung von Ressourcen freuen Kunden und Vertrieb, eine fast vollständige Auslastung der Investitionen in kurzer Zeit die Finanzabteilung. Zudem können wir größere Hana-Systeme mit 7-mal-24-Betrieb wesentlich günstiger anbieten als jeder Public-Cloud-Anbieter.

Dies schlägt sich in ständig steigenden Installationszahlen nieder. Aktuell wächst unsere Hana-on-Power-Systemlandschaft durch ständig neue Kundeninstallationen um 1 TB pro Woche mit der Tendenz zu einer Verdoppelung. Hana on Power ist Hana, wie man es in einer Cloud erwartet – wir bei Syntax (ehemals Freudenberg IT) nennen das flexHana.