HANA on POWER

“The Bigmem kernel (kernel-bigmem) is an additional Linux kernel available for SLES for SAP Applications 11 SP4 customers through the maintenance channel.
The Bigmem kernel is modified to provide support for up to 32TB on IBM POWER. Customers using SAP HANA can optionally use the Bigmem kernel to support any size memory up to 32TB.
Customers who are using SLES 11 for workloads other than SAP HANA will continue to use the standard kernel.
Moving forward, both kernels will be supported by SUSE on SLES for SAP Applications 11 SP4.

– The standard kernel-default is only certified for configurations up to 1.5TB and should be not used for larger installations.
– The kernel-bigmem is only supported for SAP HANA environments when running SUSE Linux Enterprise Server for SAP Applications 11 SP4 (ppc64)
– The kernel-bigmem is NOT supported when running the standard SUSE Linux Enterprise Server 11 SP4 4 (ppc64) or for workloads other than SAP HANA.

The Bigmem kernel also increases the number of threads supported by SLES for SAP Applications 11.
This is required for systems that have more than 1024 logical CPUs such as an IBM Power System E880 configured with 192 physical CPU core with SMT8, resulting in 1536 logical CPU threads.

Also, note that clients implementing SAP HANA on SLES for SAP Applications 12 do not need the Bigmem kernel because the base kernel in SLES 12 already supports up to 32 TB of memory.”

Source:
https://kruemcke.wordpress.com/2017/02/13/more-memory-now-available-for-sap-hana-on-sles-11-for-power/
https://www.suse.com/de-de/support/kb/doc/?id=7018408

current restrictions with HoP:
2188482 – SAP HANA on IBM Power Systems: Allowed Hardware
2055470 – HANA on POWER Planning and Installation Specifics – Central Note
2271345 – Cost-Optimized SAP HANA Hardware for Non-Production Usage
2230704 – SAP HANA on IBM Power Systems with multiple – LPARs per physical host

1) hohe Erreichbarkeit / niedrige Fehleranfälligkeit (RAS)
2) Capacity on Demand (turn on/off capacity)
3) bestehende Power 7+ / 8 Hardware kann verwendet werden
4) PowerVM Virtualisierung out of the box

Neben der bereits beschriebenen höheren Performance pro Core sprechen noch andere Aspekte für einen Einsatz der POWER Architektur im HANA Umfeld.
Durch verschiedene RAS (Reliability, Availability und Serviceability) Features steigt die uptime der Komponenten drastisch gegenüber Intel.
In dem hier (*) beschriebenen technischen Whitepapers (en) sind die verschiedenen Methoden zur Steigerung der Erreichbarkeit innerhalb der Power 7+/8 Architektur im Detail dargestellt.

Hier einige Key Facts der RAS Vorteile:
– Enterprise Memory mit Chipkill / Advanced ECC memory (**)
– Vermeidung von Soft Errors: eDRAM für L4 Cache
– Prozessor: L2 Cache Column Repair
– Active Memory Mirroring für den Hypervisor
– redundante Hardware (Stromversorgung, Lüfter, Service Prozessor, Clocking)
– ECC (= Error Correction Code)

(1) = Capability built in but not supported (3) = CoD supported on Enterprise Servers (not on 1 & 2 socket systems)
(2) = Chipkill on Systems with DRAM sparing (4) = Performance degradation and only x4 DRAM (Quelle: IBM)

ECC (= Error Correction Code) (Quelle: IBM)

Laut “ITIC 2014 – 2015 Global Server Hardware, Server OS Reliability Report” (**) ist die Server Hardware von IBM 6 Jahre in Folge der Hersteller mit den niedrigsten Ausfallzeiten.
Was nützt einem die günstigste und performateste Hardware, wenn sie anfällig ist und die SLA’s bzgl. Verfügbarkeit nicht eingehalten werden können?

58% der IBM POWER Server erzielten 99,999% Erreichbarkeit im Jahr, was 5,26 Minuten entspricht. Dies wären somit 5,26min ungeplanter Downtime pro Server im Jahr oder 44sec im Monat.
Interessant ist ebenso, dass die Downtime in der Range von 41min – 4h lediglich 5% betrug und über diesen Zeitraum nur 1%. Im Vergleich hierzu: DELL (24%) , HP (14%), Cisco (11%), Fujitsu PQ (15%)

99,999% = 5,26 Minuten
99,99% = 52,56 Minuten
99,9% = 8,76 Stunden

Capacity on Demand
CoD beschreibt das kostenpflichtige Freischalten von zusätzlichen Systemressourcen. Man beschafft sich also Hardware mit zum Beispiel voll ausgestatten Ressourcen (Hauptspeicher/CPU) welche man zum aktuellen Zeitpunkt noch nicht benötigt. Man aktiviert nur den Anteil, den man für die aktuelle Last der Systeme benötigt. Falls dies in einigen Monaten nicht mehr ausreicht, könnte man diese zeitweise oder dauerhaft hinzuschalten.
Hier gibt es die Unterteilung zwischen permantent und temporär:

1) Permantent ist, wie der Name sagt, die dauerhafte Freischaltung von bestimmten Ressourcen welche für die Maschine noch nicht aktiv freigeschalten worden sind.

2) Temporär unterteilt sich in elastic, utility und trial
a) elastic bedeutet eine Freischaltung von Prozessor & Memory auf tagesbasis
b) utility bedeutet die Freischaltung von Prozessorressourcen auf
minutenbasis um evtl. Peaks zu bestimmten Zeiten zu bewältigen
c) trial kann dazu verwendet werden um testweise Ressourcen zuzuordnen

Infos:

(*) RAS:
http://public.dhe.ibm.com/common/ssi/ecm/po/en/pow03133usen/POW03133USEN.PDF

(**) Chipkill oder Advanced ECC memory ist eine IBM xSeries Speicher
Subsytem Technologie die Speicher Ausfallsicherheit um einiges erhöht.
Ein
Test mit Standard ECC memory Modulen über 3 Jahre Workload ( BMRS
simulation 720 power-on hours) über 36 Monate mit 8x128MB DIMMs mit 4 x
64MB DRAMs ergab eine Verfügbarkeit von 91%.
Mit Chipkill Speicher wurde eine Verfügbarkeit von 99,94% erzielt.

IBM vs. Intel:
http://www.beatriceco.com/pdf/Power8_vs_Lintel_111214_cust.pptx

(***)IBM Reliability:
http://itic-corp.com/blog/2014/04/itic-2014-reliability-survey-ibm-servers-most-reliable-for-sixth-straight-year-cisco-ucs-comes-on-strong-hp-reliability-rebounds/
http://www.ibmsystemsmag.com/power/businessstrategy/competitiveadvantage/itic-reliability-survey/
http://www.lenovo.com/images/products/system-x/pdfs/analyst-reports/XSL03126USEN.PDF

Jens Gleichmann
Technical Lead Consultant
Q-Partners Consulting und Management GmbH (www.qpcm.de / jens.gleichmann(at)qpcm.de

SAP besitzt aktuell lediglich einen Benchmark für HANA Systeme mit der Bezeichnung BW-EML. Der Test besteht aus multi user reporting und Deltaladeprozeduren (weitere Infos hier). Im Mai 2015 lieferte hierbei Dell mit dem R930 eindrucksvolle 172.450 Ad-hoc Navigationsschritte/Stunde.
Der vorgehende IvyBridge basierende Benchmark von 137.010 Ad-hoc Navigationsschritte/Stunde mit dem Dell R920 wurde somit um 26% überboten!
Allerdings muss man dabei berücksichtigen, dass das System 20% mehr Cores (60:72), sowie 50% mehr Hauptspeicher (1024GB:1536GB) besitzt.
Im Juni 2015 lieferte IBM den ersten Benchmark mit 192.750 Ad-hoc Navigationsschritte/Stunde via p870.

Das sind erstaunliche 12% mehr Leistung
bei 45% weniger Cores und 33% weniger Hauptspeicher! Das Resultat: pro Core mehr als das doppelte an Performance!

Durch die unterschiedlichen Threading Technologien (SMT = Simultaneous Multithreading / HT = Hyperthreading) ergibt sich ein enormer Unterschied in der Anzahl an Threads. Bei IBM mit 40 cores und SMT=8 ergeben sich 320 Threads bei einer Taktung von 4,2 GHz. Im Gegenzug bei dem stärksten Intel Xeon Prozessor E7-8890 v3 (Haswell) mit 72 Cores und HT=2, lediglich 144 Threads bei Taktung von 2,5GHz.

Wenn man sich nun den CPU Caches (L1/L2/L3) widmet, dann erkennt man auch hier einen enormen Unterschied. Der L3 Cache bei Haswell wird pro Prozessor geshared!
Das bedeutet bei angegebenen 45MB L3 Cache pro Prozessor (4), und um vergleichbar zur IBM Angabe zu sein (pro Core), ergibt sich
folgendes Bild:
45MB*4/72=2,5MB
Ein weiterer Aspekt bei den CPU Caches wäre der L4 Cache (p870:128MB), den es bei Haswell-EX Systemen nicht gibt.

Wir sind gespannt auf weitere Benchmarks der IBM für eine Scale out Umgebung (mehrere Server Knoten im Verbund) – wie genau die Performance der Nodes skaliert.

weitere Informationen:
Benchmark BWL-EML
Bechnmarkergebnisse BWL-EML
The Impact of Intel’s Haswell Architecture on SAP’s HANA – von Hasso Plattner

Jens Gleichmann
Technical Lead Consultant
Q-Partners Consulting und Management GmbH (www.qpcm.de / info(at)qpcm.de)

Seit der Sapphire 2015 ist auch die TDI Lösung für IBM POWER Systeme (TDI Phase 4) freigegeben.
Bei Einsatz einer TDI (Tailored DataCenter Integration) Lösung, muss diese mit bestimmten KPI’s (Key Performance Indicator: Hardware, I/O und Netzwerk), die von SAP vorgeben sind, abgenommen werden.
Man verwendet hierzu bestehende HW-Komponenten, wie z.B. Enterprise Storage. Diese müssen aber ebenso bereits von der SAP zertifiziert sein und garantieren, im Gegensatz zu dem Appliance Ansatz, ein Maximum an Flexibilität. Eine Liste zertifizierter Server und des Storages, finden Sie unter den jeweiligen Links im Anhang.
Neben einer zertifizierten Person (Zertifikat: E_HANAINS*), muss das Tool HWCCT der SAP verwendet werden. Hierzu sollte man Hinweis 2161344 (Austausch eines fehlerhaften Python Skripts) beachten, da es unter SPS9 zu einigen Problemen kommt.
Für das HWCCT gelten zusätzlich noch einige Voraussetzungen, wie z.B. das OpenSource Tool Iperf, sowie bestimmte Libraries (GCC und libnumal) müssen in definierten Versionen installiert sein.

weitere Informationen:
Zertifizierte Server
Zertifizierter Enterprise Storage
Netzwerk Anforderungen
TDI Overview
1943937 – Zentraler Hinweis für das Tool zur Prüfung der Hardwarekonfiguration
2161344 – Patch-Hinweis für SAP HANA HW Configuration Check Tool

Jens Gleichmann
Technical Lead Consultant
Q-Partners Consulting und Management GmbH (www.qpcm.de / info(at)qpcm.de)

Betriebssystem
SUSE Linux Enterprise Server 11 SP3 für IBM Power (plus zusätzliche Packages)
Hardware
– Mindestens IBM Power Server mit POWER8-Prozessortechnologie
– Mindestens IBM Power Server mit POWER7+-Prozessortechnologie (für nicht produktive Umgebungen)
– SAP-HANA-Produktivpartitionen müssen so konfiguriert werden, dass Sie im Modus dedicated oder dedicated-donating ausgeführt werden (Workload bleibt bei denselben CPUs).
– SAP-HANA-Nichtproduktivpartitionen können in einem gemeinsamen Prozessorpool vorliegen, der mit Leistungseinbuße ausgeführt wird (Workload wechselt zwischen CPUs).

Im Ramp-up zulässige Hardware:

1) S824 2 socket (6c/8c/12c)
– Max 12c @ 3.89 GHz
– Max 16c @ 4.15GHz
– Max 24c @ 3.55GHz SMT8

2) E870
– 1-2 node, 4-8 socket (8c) 4.02 GHz SMT8
– 1-2 node, 4-8 socket (10c) 4.19 GHz SMT8

3) E880
– 1-2 node, 4-8 socket (8c) 4.35 GHz SMT8
– 1-2 node, 4-8 socket (12c) 4.02 GHz SMT8
=> Via Certified SAP HANA® Hardware Directory ist noch keine IBM HW gelistet
=> https://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html

Kern-Speicher-Verhältnis:
Das anfängliche Kern-Speicher-Verhältnis für SAP HANA auf IBM Power liegt bei 32 GB/Kern (Business Warehouse).
Derzeit unterstützt SAP HANA eine Systemgröße von bis zu 3TB

Infrastruktur und Virtualisierung
– 10 GB Ethernet-Ports
– Externe und interne Platten können verwendet werden, solange Sie die Anforderungen erfüllen, die vom Tool zur Prüfung der Hardwarekonfiguration (HWCCT-Tool) vorgegeben sind. Siehe dazu SAP-Hinweis 1943937.
– Für IBM PowerVM gelten die folgenden Regeln:

a) Für den Produktivbetrieb kann HANA on Power gegenwärtig nur mit einem HANA-LPAR pro physischem IBM Power Server ausgeführt werden. Zusätzlich können nur LPARs mit einem virtuellen ioserver (VIOS) parallel zu einem LPAR ausgeführt werden, auf dem ein SAP-HANA-Produktivsystem auf einem physischen IBM Power Server läuft. SAP und IBM ergreifen gemeinsam Maßnahmen, um diese Einschränkung künftig zu verringern.
b) Neben dieser Einschränkung für Tests, Entwicklung und Qualitätssicherung werden alle Kombinationen von SAP-HANA-Systemen und LPARs auf einem einzigen physischen Power Server unterstützt.

Anwendungsfälle
Bei der ersten Freigabe wird nur SAP Business Warehouse (BW) auf SAP HANA unterstützt.
Automatischer Host-Failover von SAP HANA: ein aktiver Master-Host und ein Standby-Host in einem Failover-Szenario
SAP-HANA-Systemreplikation
SAP NetWeaver BW Version 7.31 oder höher

Betriebssystem Linux
– SUSE SLES 11 SP3 Kernel 3.0.101-0.56

Dateisystem
– XFS mit Multi-Pathing

weiterführende Informationen:
2055470 – Planung und Installation von SAP HANA auf IBM Power: zentraler Hinweis
2133369 – SAP HANA auf IBM Power Systems: zentraler Release-Hinweis
http://help.sap.com/hana_on_power
SAP HANA on IBM Power Systems and IBM System Storage – Guides

Jens Gleichmann
Technical Lead Consultant
Q-Partners Consulting und Management GmbH (www.qpcm.de / info(at)qpcm.de)