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éhender 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 environnements de type ERP.
Il est toutefois bon de se rappeler que bien que SAP ait ouvert la solution HANA à la virtualisation, 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ébergement et de l’administration SAP.
Nicolas Conan
Responsable offre hébergement ERP
SAP HANA: note de synthèse
Les deux moteurs partagent une même couche mémoire la « persistence layer » permettant le passage
La partie SAP HANA Database est illustrée en tant que vers la couche de stockage permanente notamment des
"system" dans les schémas suivants et l'ensemble de ce logs (stockage sur mémoire flash, non volatile et rapide).
document.
Un moteur de calcul «Calculation engine » vient en supLe system est composé à minima d’une zone de stock- plément afin d’intégrer la logique métier au niveau dataage partagé (Shared Storage), et d’une instance portée base plutôt que par passage des données vers l’application qui entrainerait des temps de latence
sur un hôte
Notions de base :
Dans une version distribuée, le ‘’system’’ peut être com- En complément viennent s’ajouter la couche MDX
(Extension Multi-dimensionnel du SQL) et SQL Script
posé de plusieurs instances (même numéro d’instance
(ce dernier est une extension du SQL traditionnel
sur l’ensemble des hôtes) partageant tous la Shared
Storage
Configuration sur un hôte simple
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 traditionnel
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 points de sauvegarde sont réalisées par défaut
des problématiques d'équilibrage de charge que de bas- toutes les 5 minutes
culement en cas de panne (fail over); de fait on peut classer les systèmes par le dimensionnement de leur architecture comme les exemples ci-dessous :
Compression des données
Performances:
Mémoire et problématique de la persistance:
L’utilisation en mémoire ne remet pas en cause les principes 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.
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 customer et material permet d’obtenir 2 index dis ncts par construc on et diminuer l’u lisa on mémoire de la table principale 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
Afin d’éviter ce problème, les logs sont écrits sur un support 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.
SAP HANA: note de synthèse
Cette normalisation s'est accompagnée d'un effort de
recodage et d'optimisation important mené par SAP
Prérequis installation
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 justifie pleinement l’apparente complexification du mode de
stockage.
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
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
SAP HANA utilise surtout la mémoire, depuis 128Gb
plus grande rapidité d’accès à l’information une fois
(24Gb pour une base de test) jusqu’à plusieurs Tb
stockée.
D’une manière générale si 4X Go représente la taille du
Logique applicative intégrée
volume de données, il faut compter :
La séparation de la logique applicative de la couche base
de données induit une dépendance au niveau de la rapidité du réseau pour extraire, transformer et retourner les
données. Dès lors que la database est pensée pour fonctionner 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.
•
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
C'est pourquoi SAP préconise l'installation des appliances SAP HANA DB dans le contexte de réseau 10GIl est recommandé que le software SAP HANA soit instalbit/s
lé par un partenaire hardware certifié ou toute personne
Parallélisassion et partitionnement
ayant obtenu la certification E_HANAINS131.
Plutôt que de confier une masse de travail lors d’une requê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.
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
Au delà des limites d’un seul serveur, la base de données peut être répartie sur plusieurs serveurs au travers
• RedHat (Red Hat Enterprise Linux (RHEL) 6.5
d’un cluster ce qui permet d’aller vers l’architecture distribuée décrite plus tôt. L’exploitation des column tables sur
des partitions séparées permet du aussi a répartition des Les deux suites logicielles sont déclinées dans des verressources.
sions adaptées à HANA avec des niveaux de support à
même de couvrir l’exigence d’un environnement de production 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 certifié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 HANA.
SAP HANA: note de synthèse
SAP HANA dans votre data centre
SAP HANA et la virtualisation
A ce jour, il existe des limitations dans ce que SAP supSAP HANA Studio
Une nouvelle console d’administration : Le HANA Studio. porte en termes de déploiement de HANA dans des environnements 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 tourner 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)
HANA Studio tourne sur une plateforme de développement JAVA Eclipse.
Machines virtuelles
L’utilisation de VMs est ouvertes à l’ensemble des systèmes non productifs, mais reste contrainte pour les systèmes productifs a quelques configuration restreintes.
Dans le cadre de l’administration, cette application
couvre les tâches d’administration comme l’arrêt/démarrage des instances de bases de données, leur
configuration comme la gestion des autorisations, la planification et le suivi de l’exécution de celles-ci, l’utilisation
des ressources systèmes, et plus globalement le monitoring de l’activité des bases HANA.
MCOS : Multiple components on one System
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 paysage 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.
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 matérielles à même de supporter HANA avec comme direction principale la volonté de favoriser l’accroissement
d’échelle par la démultiplication des hôtes.