SAP HANA: note de synthèse

SAP HANA: note de synthèse
Préface:
Au cœur des nombreux défis que doivent relever les entreprises, l’informatique se doit de soutenir les évolutions,
d’aider au développement de nouveaux avantages concurrentiels tout en traitant un volume d’informations de
plus en plus important avec des délais très courts.
Afin de répondre à ces besoins l’Editeur SAP propose avec HANA une ‘révolution’ dans la manière d’appréhen-
der les bases de données
• Traitement plus efficace de forts volumes de données avec une réduction du TCO
• Simplification des architectures de type datawarehouse centralisés
• Capacité à disposer de modèles analytiques en temps réel
Après un phase dans laquelle seules les entreprise avant-gardistes ont adopté SAP HANA,
nous entrons dans une seconde phase dans laquelle le niveau de maturité de la solution
ayant fortement progressé ,Il n’existe maintenant plus de freins majeurs à un déploiement
massif dans les entreprises tant pour les environnements décisionnels que les environne-
ments de type ERP.
Il est toutefois bon de se rappeler que bien que SAP ait ouvert la solution HANA à la virtuali-
sation, celle-ci est incomplètement supportée et il existe encore des limites dans la capacité
de convertir les tables en lignes en tables en colonnes.
Nous vous proposons de découvrir dans cette note les principes de fonctionnement de SAP
’HANA et de vous donner un aperçu des changements que cela peut engendrer dans le contexte de l’héberge-
ment et de l’administration SAP.
Nicolas Conan
Responsable offre hébergement ERP

SAP HANA: note de synthèse
Notions de base :
La partie SAP HANA Database est illustrée en tant que
"system" dans les schémas suivants et l'ensemble de ce
document.
Le system est composé à minima d’une zone de stock-
age partagé (Shared Storage), et d’une instance portée
sur un hôte
Dans une version distribuée, le ‘’system’’ peut être com-
posé de plusieurs instances (même numéro d’instance
sur l’ensemble des hôtes) partageant tous la Shared
Storage
Architecture logique :
La database représente une partie de l’ensemble SAP
HANA Appliance et repose sur deux moteurs :
• Le premier se charge des données agrégées de
type colonne (column store) et participe aux opé-
rations de type analytique.
• Le second se charge des données traditionnelles
de type ligne (row store) moteur de type tradition-
nel
Les deux moteurs partagent une même couche mé-
moire la « persistence layer » permettant le passage
vers la couche de stockage permanente notamment des
logs (stockage sur mémoire flash, non volatile et rapide).
Un moteur de calcul «Calculation engine » vient en sup-
plément afin d’intégrer la logique métier au niveau data-
base plutôt que par passage des données vers l’applica-
tion qui entrainerait des temps de latence
En complément viennent s’ajouter la couche MDX
(Extension Multi-dimensionnel du SQL) et SQL Script
(ce dernier est une extension du SQL traditionnel
Configuration sur un hôte simple
Configuration multi hôtes
Chaque hôte peut être configuré comme acf (acve host) ou
en passif (standby host)

SAP HANA: note de synthèse
La participation de plusieurs hôtes répond aussi bien à
des problématiques d'équilibrage de charge que de bas-
culement en cas de panne (fail over); de fait on peut clas-
ser les systèmes par le dimensionnement de leur archi-
tecture comme les exemples ci-dessous :
Performances:
Mémoire et problématique de la persistance:
L’utilisation en mémoire ne remet pas en cause les prin-
cipes d’atomicité, consistance, et d’isolation inhérents
aux SGBD de façon générale mais remet en cause celui
de la durabilité.
Une panne de courant sur un support volatile se traduit
par une perte de données.
Afin d’éviter ce problème, les logs sont écrits sur un sup-
port persistant (non volatile) à intervalle régulier de sorte
à pouvoir garantir la remontée de la base au niveau de
ce qu’elle était avant crash et assurer la persistance.
Des points de sauvegarde sont réalisées par défaut
toutes les 5 minutes
Compression des données
La compression de données est assurée par la normalisaon
du modèle de données et le stockage en colonne.
Le découplage d’une table en trois ensemble, avec ici custo-
mer et material permet d’obtenir 2 index disncts par cons-
trucon et diminuer l’ulisaon mémoire de la table princi-
pale dans laquelle on retrouve les ID des index qui recons-
tuent l’informaon.
Normalisaon du modèle
"En apparence on injecte de la complexité dans le mode de
stockage, mais les principes de normalisaon des modèles de
données sont mieux respectés et le volume de données est
réduit ainsi que les temps d’accès
Stockage en colonnes

SAP HANA: note de synthèse
Cette normalisation s'est accompagnée d'un effort de
recodage et d'optimisation important mené par SAP
La recherche des enregistrements ayant le customer 4 et
Material 3 se trouve accélérée par les opérations bit à bit.
Ce type d’opération étant particulièrement rapide, il justi-
fie pleinement l’apparente complexification du mode de
stockage.
La mise à jour ou insertion de données bénéficie d'un
gain de performance moindre, uniquement liée à l’accélé-
ration de l'accès au support, mais aussi au profit d’une
plus grande rapidité d’accès à l’information une fois
stockée.
Logique applicative intégrée
La séparation de la logique applicative de la couche base
de données induit une dépendance au niveau de la rapi-
dité du réseau pour extraire, transformer et retourner les
données. Dès lors que la database est pensée pour fonc-
tionner en temps réel (mémoire volatile), la vitesse du
réseau devient potentiellement significative au regard des
temps mémoire pour justifier l’intégration de la logique
applicative au niveau du serveur de base de données.
C'est pourquoi SAP préconise l'installation des ap-
pliances SAP HANA DB dans le contexte de réseau 10G-
bit/s
Parallélisassion et partitionnement
Plutôt que de confier une masse de travail lors d’une re-
quête à un cœur de CPU, on divise la tâche en plusieurs
sous requêtes indépendantes réparties sur plusieurs
cœurs de sorte à réduire le temps de traitement global.
Au delà des limites d’un seul serveur, la base de don-
nées peut être répartie sur plusieurs serveurs au travers
d’un cluster ce qui permet d’aller vers l’architecture distri-
buée décrite plus tôt. L’exploitation des column tables sur
des partitions séparées permet du aussi a répartition des
ressources.
Prérequis installation
Licences
SAP fournit des licences temporaires mais recommande
d’installer une licence permanente et ce dans tous les
cas avant la date d’expiration de la License temporaire.
Matrice de disponibilité produit SAP
SAP HANA utilise surtout la mémoire, depuis 128Gb
(24Gb pour une base de test) jusqu’à plusieurs Tb
D’une manière générale si 4X Go représente la taille du
volume de données, il faut compter :
• X Go de taille pour le volume de logs de base de
données
• X Go de mémoire physique
Matrice officielle de compatibilité SAP (PAM) à l’adresse
suivante http://global.sap.com/community/ebook/2014-09
-02-hana-hardware/enEN/index.html
Prérequis logiciel
Il est recommandé que le software SAP HANA soit instal-
lé par un partenaire hardware certifié ou toute personne
ayant obtenu la certification E_HANAINS131.
Ne rien installer qui sorte des matrices de compatibilité
au niveau software sur les systèmes SAP HANA
Système d’exploitation pour SAP HANA
• SUSE Linux Enterprise Server (SLES) 11 SPA, SP2
• RedHat (Red Hat Enterprise Linux (RHEL) 6.5
Les deux suites logicielles sont déclinées dans des ver-
sions adaptées à HANA avec des niveaux de support à
même de couvrir l’exigence d’un environnement de pro-
duction avec des coûts de licences associés.
Tous les logiciels qui interagissent avec les systèmes
HANA ou nécessitant des agents doivent aussi être certi-
fiés (outil de surveillance, outil de sauvegarde…).
D’une façon générale, toute brique logicielle pouvant
avoir une influence sur l’utilisation du disque, du CPU ou
de la mémoire, nécessite, pour être certifié, d’être testé
par SAP dans les différents cas d’utilisation de SAP HA-
NA.

SAP HANA: note de synthèse
SAP HANA dans votre data centre
SAP HANA Studio
Une nouvelle console d’administration : Le HANA Studio.
HANA Studio tourne sur une plateforme de développe-
ment JAVA Eclipse.
Dans le cadre de l’administration, cette application
couvre les tâches d’administration comme l’ar-
rêt/démarrage des instances de bases de données, leur
configuration comme la gestion des autorisations, la pla-
nification et le suivi de l’exécution de celles-ci, l’utilisation
des ressources systèmes, et plus globalement le monito-
ring de l’activité des bases HANA.
Bien qu’HANA Studio soit préférable pour la configuration
des instances de bases de données, une fois la mise en
œuvre réalisée, la base HANA peut se greffer au pay-
sage applicatif géré avec Solution Manager. Cela permet
un suivi intégral du ou des paysages applicatifs des
suites SAP déployés dans un contexte donné.
Les échanges entre HANA Studio et la base de données
se font au travers du langage SQL.
SAP HANA et la virtualisation
A ce jour, il existe des limitations dans ce que SAP sup-
porte en termes de déploiement de HANA dans des envi-
ronnements virtualisés.
Base matérielle
La sortie du SP7 de HANA DB a néanmoins élargi les
frontières de l’utilisation en environnement virtualisé.
Un jeux de base matérielle limité est autorisé à faire tour-
ner des machines virtuelles afin d’héberger HANA. Il se
base sur :
Elle ce limite aux CPU de type Intel Xeon E7 et E5 (IBM
Power 7+ prévu mais non validé à fin Novembre 2014)
Machines virtuelles
L’utilisation de VMs est ouvertes à l’ensemble des sys-
tèmes non productifs, mais reste contrainte pour les sys-
tèmes productifs a quelques configuration restreintes.
MCOS : Multiple components on one System
Evolutions
La feuille de route de SAP prévoit les évolutions vers le
complément de gamme VmWare en 2015, en particulier
avec la gestion des cluster vSphere et la certification de
vSphere 6 ainsi que l’extension continue des bases ma-
térielles à même de supporter HANA avec comme direc-
tion principale la volonté de favoriser l’accroissement
d’échelle par la démultiplication des hôtes.