Hana and Linux on Power: From Big to Little Endian

The availability of IBM Power systems for SAP Hana has expanded the circle of Hana server providers. And it is clearly perceptible that IBM has increased sales and marketing activities in the SAP environment with its Hana-on-Power (HoP) servers since about the beginning of the year.

At the same time, the HoP systems based on Power 8 processors are adapting to certain Hana conditions or standards in technical terms. Whereby the Hana 1.0-Hana 2.0 change represents a kind of directional change marker.

The topic that is relevant here is that with Hana 2.0 and Suse Enterprise Linux Server (SLES) 12 for SAP Applications, the HoP systems with P8 processors are being converted from big endian to little endian in terms of internal byte order processing/storage - which means that from now on all Hana server systems will have little endian byte order processing/storage; both Hana-on-Intel systems and Hana-on-Power systems in the scale-out and scale-up versions.

Which of the processing types, little endian here or big endian there, is used is usually determined by the processor manufacturer. Sparc processors or also processors from Motorola - and to date also IBM - use big-endian processing; Intel processors, on the other hand, have always used little-endian processing.

Little first

The selected processing type has no influence on the performance or speed of a processor. Big Endian means "big end first" and means that the data sorting and storage in a processor, for example of a multi-digit number including letters (multi-byte data field), takes place from large to small.

With little-endian ("little end first") processing, it is the reverse case, namely from small to big. The big-endian to little-endian switch essentially means two things: a certain standardization in Hana servers as of Hana 2.0, but also a simpler approach in the future when deploying/porting an operating system, for example, because only one type of processing - namely little endian - needs to be supported.

In the case of SLES for SAP and HoP, this starts with version 12. SLES for SAP 11 (SP4) also supports HoP systems with Big Endian. While Hana 1.0 required NetWeaver 7.40, Hana 2.0 requires version 7.50.

High Availability and Disaster Recovery

Incidentally, SLES for SAP 12 from Suse is the first time that the associated innovations can also be used by Hana-on-Power systems. For example, extended automated high-availability (HA) and disaster recovery (DR) functionality.

SAP provides SAP Hana System Replication (SR) mechanisms for HA in particular, which are generally handled and used manually. The increase of the SLA via automation is provided by the Suse High Availability Solution (HAE) of SLES 12.

System replication via a memory preload in a cluster (e.g. 2-node cluster) is generally preferred as a central HA solution for SAP Hana.

Hana Resource Agents

Another highlight of SLES for SAP 12 is the SAP Hana Resource Agents (RAs) for cluster configurations. This also allows Hana database instances and replications to be managed, monitored and controlled.

On top of that, the RAs can be configured. To date, Suse Linux/SLES for SAP Applications is the only operating system platform for Hana on Power.