Hana et Linux on Power : de Big à Little Endian

La disponibilité des systèmes IBM Power pour SAP Hana a élargi le cercle des fournisseurs de serveurs Hana. Et il est clairement perceptible qu'IBM a augmenté ses activités de vente et de marketing dans l'environnement SAP avec ses serveurs Hana-on-Power (HoP) depuis le début de l'année environ.

Parallèlement, les systèmes HoP basés sur des processeurs Power 8 s'adaptent d'un point de vue technique à certaines circonstances ou normes Hana. Le passage de Hana 1.0 à Hana 2.0 constitue en quelque sorte un changement d'orientation.

Avec Hana 2.0 et Suse Enterprise Linux Server (SLES) 12 for SAP Applications, les systèmes HoP avec processeurs P8 passent de Big Endian à Little Endian pour le traitement/stockage interne des octets, ce qui signifie que tous les systèmes serveur Hana ont un traitement/stockage des octets Little Endian, qu'il s'agisse de systèmes Hana-on-Intel ou de systèmes Hana-on-Power dans les versions Scale-out et Scale-up.

En règle générale, c'est le fabricant du processeur qui détermine quel type de traitement, Little Endian ici ou Big Endian là, est utilisé. Les processeurs Sparc ou les processeurs de Motorola - et jusqu'à présent également IBM - utilisent le traitement Big Endian ; les processeurs Intel, en revanche, utilisent depuis toujours le traitement Little Endian.

Little first

Le type de traitement choisi n'a aucune influence sur les performances ou la vitesse d'un processeur. Big Endian signifie "big end first" et signifie que le tri et le stockage des données dans un processeur, par exemple un nombre à plusieurs chiffres incluant des lettres (champ de données multi-octets), se fait du plus grand au plus petit.

Pour le traitement Little-Endian ("little end first"), c'est le cas inverse, à savoir du petit au grand. Le changement Big-Endian-Little-Endian signifie en substance deux choses : une certaine uniformisation pour les serveurs Hana à partir de Hana 2.0, mais aussi une procédure plus simple à l'avenir lors de la mise à disposition/du portage d'un système d'exploitation par exemple, car un seul type de traitement - à savoir Little Endian - doit être pris en charge.

Dans le cas de SLES for SAP et HoP, cela commence avec la version 12. SLES for SAP 11 (SP4) supporte également les systèmes HoP avec Big Endian. Si Hana 1.0 présupposait NetWeaver 7.40, Hana 2.0 présuppose la version 7.50.

Haute disponibilité et reprise après sinistre

Avec SLES for SAP 12 de Suse, les systèmes Hana-on-Power peuvent pour la première fois profiter des nouveautés qui y sont liées. Il s'agit par exemple d'une fonctionnalité High Availability (HA) et Disaster Recovery (DR) automatisée et étendue.

Pour la HA, SAP fournit notamment des mécanismes de réplication du système SAP Hana (SR), dont la manipulation et l'utilisation sont généralement manuelles. La solution Suse High Availability Solution (HAE) de SLES 12 permet d'augmenter le niveau de service grâce à l'automatisation.

La solution HA centrale préférée pour SAP Hana est la réplication du système via un Memory Preload dans un cluster (par exemple un cluster à 2 nœuds).

Agents de ressources Hana

Les agents de ressources (RA) SAP Hana pour les configurations en cluster constituent un autre point fort de SLES for SAP 12. Ils permettent également de gérer, de surveiller et de contrôler les instances et les réplications de bases de données Hana.

Les RA peuvent en outre être configurés. À ce jour, Suse Linux/SLES for SAP Applications est la seule plate-forme de système d'exploitation pour Hana on Power.