Hana und Linux on Power: Von Big zu Little Endian
Durch die Verfügbarkeit von IBM-Power-Systemen für SAP Hana hat sich der Kreis der Hana-Server-Anbieter erweitert. Und es ist deutlich vernehmbar, dass IBM mit ihren Hana-on-Power-(HoP)-Servern etwa seit Jahresbeginn die Vertriebs- und Marketingaktivitäten im SAP-Umfeld erhöht hat.
Gleichzeitig passen sich die HoP-Systeme auf Basis von Power-8-Prozessoren in technischer Hinsicht gewissen Hana-Begebenheiten oder auch -Standards an. Wobei der Hana-1.0-Hana-2.0-Wechsel eine Art Richtungsänderungsmarkstein darstellt.
Das Thema, das dabei von Belang ist: Mit Hana 2.0 und Suse Enterprise Linux Server (SLES) 12 for SAP Applications werden die HoP-Systeme mit P8-Prozessoren bei der internen Byte-Reihenfolgeverarbeitung/-Speicherung von Big Endian auf Little Endian umgestellt – was bedeutet, dass fortan alle Hana-Server-Systeme eine Little-Endian-Byte-Reihenfolgeverarbeitung/-Speicherung aufweisen; sowohl Hana-on-Intel-Systeme wie auch eben Hana-on-Power-Systeme in den Ausprägungen Scale-out und Scale-up.
Welche der Verarbeitungsart, Little Endian hier oder Big Endian dort, zum Zuge kommt, bestimmt in aller Regel der Prozessorhersteller. Sparc-Prozessoren oder auch Prozessoren von Motorola – und bis dato auch IBM – nutzen die Big-Endian-Verarbeitung; Intel-Prozessoren hingegen seit jeher die Little-Endian-Verarbeitung.
Little first
Auf die Leistungsfähigkeit oder Geschwindigkeit eines Prozessors hat die gewählte Verarbeitungsart keinen Einfluss. Big Endian heißt „big end first“ und bedeutet, dass die Datensortierung und -abspeicherung in einem Prozessor, etwa einer vielstelligen Zahl inklusive Buchstaben (Multi-Byte-Datenfeld), von groß nach klein erfolgt.
Bei der Little-Endian-(„little end first“)-Verarbeitung ist es der umgekehrte Fall, nämlich von klein nach groß. Der Big-Endian-Little-Endian-Wechsel bedeutet im Kern zweierlei: eine gewisse Vereinheitlichung bei den Hana-Servern ab Hana 2.0, aber auch eine künftige einfachere Vorgehensweise bei der Bereitstellung/Portierung beispielsweise eines Betriebssystems, weil nur noch eine Verarbeitungsart – nämlich Little Endian – unterstützt werden muss.
Im Fall von SLES for SAP und HoP beginnt dies mit der Version 12. SLES for SAP 11 (SP4) unterstützt auch HoP-Systeme mit Big Endian. Hatte Hana 1.0 NetWeaver 7.40 vorausgesetzt, ist es bei Hana 2.0 die Version 7.50.
High Availability und Disaster Recovery
Mit SLES for SAP 12 von Suse können übrigens erstmals die damit verbundenen Neuerungen auch von Hana-on-Power-Systemen genutzt werden. So etwa eine erweiterte automatisierte High-Availability- (HA) und Disaster-Recovery-(DR)-Funktionalität.
Von SAP werden für HA insbesondere SAP-Hana-System-Replication-(SR)-Mechanismen bereitgestellt, deren Handhabung und Nutzung in aller Regel manuell erfolgt. Die Erhöhung des SLAs über eine Automation stellt die Suse High Availability Solution (HAE) von SLES 12 bereit.
Präferiert wird generell als zentrale HA-Lösung für SAP Hana eine Systemreplikation über ein Memory Preload in einem Cluster (beispielsweise 2-Node-Cluster).
Hana Resource Agents
Ein weiteres Highlight von SLES for SAP 12 stellen die SAP Hana Resource Agents (RAs) für Cluster-Konfigurationen dar. Damit lassen sich auch Hana-Datenbank-Instanzen und -Replikationen verwalten, überwachen und steuern.
Die RAs können obendrein konfiguriert werden. Bis heute ist Suse Linux/SLES for SAP Applications die einzige Betriebssystemplattform für Hana on Power.
