Construire des environnements Hana robustes

Outre l'approche d'implémentation de l'appliance (boîte noire) et de la TDI (Tailored Datacenter Integration) personnalisée, il existe différentes formes de dimensionnement de la disponibilité d'un paysage Hana.

Ceux-ci sont à leur tour directement influencés par l'architecture elle-même. On distingue principalement la haute disponibilité (HA) asynchrone ou basée sur le stockage et les mécanismes HA synchrones que la Hana DB apporte d'office.

Outre le mode "asynchrone", il existe encore trois interprétations différentes au sein de la HA synchrone : Sync, Sync-MEM et Full Sync. Alors que le mode Sync standard peut être comparé à une méthode Fire-and-Forget vers l'instance fantôme, les deux autres mécanismes attendent que le côté miroir ait écrit les instructions de la base de données soit en mémoire, soit en mode Full, soit même jusque dans le stockage.

Les niveaux de sécurité accrus de la synchronisation qui en résultent se paient par une dépendance également accrue et des exigences de performance plus élevées du côté miroir. Ainsi, dans le pire des cas, la synchronisation complète peut conduire à ce qu'un site miroir ralentisse ou paralyse complètement le site productif.

Selon le niveau HA souhaité, le côté miroir doit être construit de manière performante par rapport au côté productif. En outre, dans les environnements scale-out, il existe une option de basculement pour prévenir une panne de serveur.

En outre, il existe actuellement deux variantes de cluster au niveau du système d'exploitation, en complément des méthodes de synchronisation de Hana elle-même. Manuelle (manuelle ou basée sur des scripts) ou entièrement automatique avec une structure de cluster (Red Hat Enterprise Linux High Availability Add-on ou Suse-Extension).

Par conséquent, la question se pose dès la phase d'architecture et de conception : Qui effectue la reprise (planifiée ou non) ? L'administrateur de la base de données au niveau de Hana ou l'administrateur Linux dans le Cluster Resource Manager (Pacemaker). L'administrateur de la base SAP est également nécessaire au plus tard pour la mise en place de la fonctionnalité DBSL Suspend.

Globalement, on peut dire que la plupart des clients SAP préfèrent aujourd'hui clairement un environnement TDI à une appliance, d'une part pour pouvoir réutiliser les investissements existants, et d'autre part pour pouvoir adapter l'architecture globale de manière robuste et conformément à leurs besoins.

En ce qui concerne l'architecture HA, les points de vue sont aussi différents que les besoins. La plupart du temps, les scénarios de basculement sont complétés par le mécanisme de synchronisation standard afin de prendre des précautions au niveau du matériel et du logiciel.

Cycle de vie Hana et conséquences

En raison du développement rapide de la technologie Hana, le cycle de maintenance de SAP ne prévoit effectivement que neuf mois de support pour un API. Compte tenu du fait qu'il ne faut utiliser que des DSP (Data Center Service Points) dans des environnements de production (leur libération a lieu tous les six mois environ), les fenêtres de maintenance deviennent très courtes dans le temps.

Surtout si l'on déduit encore une phase de test d'un à deux mois. Si l'on souhaite en outre installer et exploiter Hana de manière autonome, il faut au moins deux certifications Hana.

Ce qui est nouveau, c'est que ces certifications ne sont plus valables que pour trois API, soit environ 3 x 6 mois. Actuellement, on ne sait pas encore (la question est posée directement à SAP) à partir de quand la certification est valable, c'est-à-dire à la date de la certification ou à la date de la version.

Indépendamment de cela, il en résulte actuellement un besoin de recertification des collaborateurs au plus tard tous les ans et demi en ce qui concerne Hana. Cela n'a jamais été le cas pour toutes les autres bases de données autorisées par SAP (AnyDB). On peut se demander s'il s'agit d'une nécessité ou d'une source de revenus supplémentaire pour SAP.

Qui est responsable ?

Comme nous l'avons déjà mentionné, les questions de responsabilité concernant l'exploitation, le monitoring et la maintenance se posent en raison des architectures TDI Hana spécifiques aux clients. Quel service est responsable de quoi dans la TDI Hana ? Insourcing, outsourcing/cloud ou services gérés ?

Chez de nombreux clients, cela est redéfini lors de l'introduction de Hana. Dans ce cas, il est recommandé d'établir une matrice RACI par le biais d'un Hana SLA, afin de déterminer les tâches qui seront mises en œuvre et dont l'administrateur de la base Linux, HDB ou SAP sera responsable.

Sur cette base, il est également possible de déterminer à peu de frais ses besoins en matière de sourcing et de formation. En outre, il convient de mentionner qu'un système de notification (alerting) raisonnable et intégré à Hana n'est actuellement accessible que via le Solution Manager.

Un autre point important est le housekeeping Hana. Le catalogue de sauvegarde contient toutes les sauvegardes importantes de données et de logs et est sauvegardé lors de chaque sauvegarde. Il devrait être nettoyé de manière cyclique, car il n'existe pas de fonction automatisée pour cela dans Hana.

Conclusion

D'un point de vue technologique, on peut constater que Hana se trouve toujours dans une courbe de développement abrupte et dynamique. Il est recommandé de se positionner durablement, tant sur le plan architectural qu'organisationnel, afin de pouvoir profiter des nouveautés et d'établir la technologie Hana comme compétence clé dans sa propre entreprise.

Il s'agit notamment de vérifier et de balayer avec clairvoyance les composants ERP existants en direction de S/4 Hana au moyen du rapport R_S4_PRE_TRANSITION_CHECKS (note 2182725), qui devrait vérifier pendant environ un an les systèmes SAP existants en direction de S/4 Hana Readiness.

Hana & Non-ERP

"Cela risque d'être difficile en comparaison"

estime Matthias Kneissl.

"Il est clair qu'avec la pile Hana, SAP met également à disposition une solution qui peut tout à fait faire plus que concurrence à un JBoss.

Toutefois, il y a certainement aussi la question des prix et des licences. En outre, les développeurs Java Enterprise classiques sont habitués à leurs piles respectives, de sorte qu'il devrait être difficile de s'approprier les candidats connus JBoss ou WebSphere.

Pour qu'un client échange la pile - dans l'environnement J2EE, c'est nettement plus compliqué que dans le monde SAP, où une migration OS/DB est possible avec des outils standard -, il doit en tirer des avantages évidents.

Certes, les bibliothèques pour la recherche de texte et la logique floue sont formidables, mais à notre avis, SAP ne les commercialise pas encore suffisamment au sein de la communauté. En outre, SAP est également un nouvel acteur, largement inconnu jusqu'à présent, au sein de la communauté Java".

Guido Hoepfner ajoute à ce sujet que l'innovation chez les clients de Q-Partners se situe d'une part dans le domaine des solutions mobiles, de l'utilisation des Fiori Apps ainsi que du développement d'applications propres sur la base de SAPUI5.

"Dans le domaine de la technologie, il est vrai qu'un grand nombre de nos clients s'intéressent au thème de SAP Hana et que nous effectuons actuellement diverses conversions de solutions existantes vers Hana".

il fait part de sa pratique professionnelle.

"Une fois cette base posée, les conditions sont réunies pour que l'application soit innovante. C'est une évolution que nous voyons venir. La première étape logique est la conversion de la base SAP à la nouvelle plate-forme".

Les défis consistent notamment à intégrer les nouveaux modèles de programmation, les technologies et les architectures. D'un point de vue historique, il est possible de programmer structurellement dans Abap de manière orientée objet et de manière non orientée objet d'un point de vue historique.

"C'est encore une pratique courante et parfois utile dans les rapports".

souligne Kneissl.

Avec la nouvelle technologie en direction de Hana, SAPUI5 et NetWeaver Gateway, il faut se diriger nettement plus vers l'orientation objet.

"C'est particulièrement important pour que les utilisateurs puissent utiliser les nouvelles technologies à bon escient et profiter de leurs avantages. Il s'agit bien sûr d'un changement important qu'un utilisateur ne réalise pas du jour au lendemain. Il en va de même dans le domaine de la technologie".

ajoute Hoepfner.