Expérience pratique avec Hana on Power

Avec le système "Appliance Hana", les clients qui étaient habitués à ce qu'un système classique puisse être déployé dans notre cloud privé en quelques semaines, ont dû attendre bien plus d'un mois pour un système Hana, car l'appliance de la taille correspondante devait d'abord être construite chez le fabricant, transportée par avion et traitée par les douanes avant de pouvoir être installée dans notre centre de données cloud.

Là, il y avait le problème d'insérer un système "bare metal" comme "verrou spécial personnalisé" dans un environnement optimisé pour la standardisation, la virtualisation et le déploiement automatisé. Sans parler du monitoring, du patching et de l'extension.

Hana-T-Shirt-Sizes

La limitation rigide aux tailles T-shirt ne permettait pas non plus d'affiner les besoins des clients, la flexibilité étant malheureusement un mot étranger aux appliances ! Il fallait toujours arrondir la mémoire vers le haut et deviner ce dont le client pourrait avoir besoin dans trois ans, ce qui entraînait naturellement des coûts d'acquisition beaucoup plus élevés.

Pour de nombreux clients, nous avons également été confrontés au problème que leurs besoins en mémoire principale augmentaient beaucoup plus rapidement que prévu. La seule façon de "mettre à niveau" une appliance est d'installer physiquement plus de modules DIMM et de processeurs - si la carte mère choisie à l'origine avait encore de la place pour cela. Si ce n'était pas le cas, il fallait acheter une appliance plus grande.

Ne jamais toucher à un appareil en marche

Nous avons alors dû faire l'expérience que le vieil adage informatique "Never Touch a Running System" est toujours valable. Comme les modules DIMM et les unités centrales supplémentaires doivent être enfoncés dans leur logement avec une certaine force et que la carte mère fléchit un peu, il se peut qu'une fiche sorte de la prise à un autre endroit.

Lors de la tentative de redémarrage, tous les ventilateurs n'étaient soudainement plus en état de marche ou le système n'était même plus en état de fonctionner, ce qui nécessitait à nouveau l'intervention des techniciens de service des fabricants - et tout cela pendant que le client attendait de pouvoir travailler à nouveau ! En somme, une situation insatisfaisante pour toutes les parties concernées - Hana en tant qu'appliance était tout simplement en contradiction avec le cloud. C'est peut-être l'une des raisons pour lesquelles le nombre d'implémentations de Hana a été faible au cours des premières années.

Intégration de centres de données sur mesure

Heureusement, les fabricants de matériel informatique ont réussi, avec l'aide de quelques grands clients, à convaincre SAP d'assouplir peu à peu le modèle rigide des appliances. Dans un premier temps, les baies de stockage externes ont pu être utilisées au lieu de disques internes, puis les processeurs E5 moins chers ont pu être utilisés pour les petits systèmes, suivis par le support de VMware et enfin IBM Power - le tout sous le label : Tailored Datacenter Integration (TDI).

Un costume sur mesure plutôt qu'une camisole de force

Cela nous a également donné l'occasion de fournir aux clients SAP existants un costume sur mesure flexible au lieu d'une camisole de force toute faite, qui s'intégrait en outre dans un environnement moderne de cloud privé. Mais sur quelle plateforme ? Une comparaison des restrictions d'Intel avec VMware contre IBM Power avec virtualisation "intégrée" a révélé des différences dans la taille et le nombre possibles de systèmes Hana virtualisés.

De plus, plusieurs clients avaient signalé qu'ils avaient besoin de beaucoup plus de mémoire que les 3 TB possibles à l'époque sur les systèmes Intel habituels à 4 sockets. Et tout cela "as single instance as possible", car l'expérience avec le scale-out n'avait pas été des plus concluantes.

Sur cette base et en raison de l'expérience de l'entreprise avec IBM Power, la décision a été prise d'acquérir deux types de machines : la S824L pour les systèmes Hana jusqu'à 2 TB et la E880 pour tout ce qui était plus grand. Plus tard, une E850 est venue s'y ajouter et s'est imposée, avec ses 4 To, comme le cheval de bataille idéal pour le "pain et le beurre".

Dans la version "Linux only", telle qu'elle est nécessaire pour Hana, les machines Power sont en outre beaucoup moins chères que pour AIX. Cette décision s'est avérée être un succès total en peu de temps, tant du point de vue technique que commercial.

Virtualisation

Grâce à la virtualisation issue du monde des mainframes (qui se souvient encore de MVS ?) au niveau du micrologiciel, les pertes habituelles dues aux latences supplémentaires, surtout dans l'IO, lors des virtualisations 3rd-Party ont pu être évitées - pour Hana, cela signifie "bare metal performance".

Tant la mémoire que la puissance du CPU peuvent être adaptées aux besoins du client jusqu'au niveau de 1 Mo et 1/20e de cœur. Étant donné que les systèmes Hana n'ont généralement besoin que d'une fraction de la puissance CPU définie comme "acier de peur" par le système de règles SAP, il est possible de mettre l'excédent de puissance CPU dans un pool partagé par tous les systèmes Hana fonctionnant sur la machine. (Les ingénieurs en bâtiment désignent par acier de peur une armature de béton armé complètement surdimensionnée pour être sûr à "mille pour cent" que le maître d'ouvrage n'entame pas un procès pour des fissures dans le mur). Un système qui a besoin de plus de puissance que prévu peut y puiser sans que le client n'ait à payer de frais supplémentaires.

En principe, on pourrait également adapter la mémoire de manière dynamique si Hana n'essayait pas d'accéder à des ressources qui ne sont plus disponibles après une réduction de la mémoire. Il est donc recommandé de relancer Hana en cas de modification des ressources de la mémoire. La LPAR Live Mobility s'est avérée particulièrement bénéfique, car elle permet de déplacer des systèmes Hana très volumineux d'une machine à l'autre en cours de fonctionnement.

Même si le matériel Power est extrêmement stable, il arrive statistiquement qu'un problème survienne dans un parc de machines important et qu'il faille remplacer un composant. Heureusement, tous les problèmes rencontrés jusqu'à présent ont eu la gentillesse d'être annoncés à l'avance ou ont été pris en charge par la redondance.

Grâce à Live Mobility, nous avons pu libérer les machines en question des systèmes des clients en cours de fonctionnement, remplacer la carte mère ou la carte réseau en question, puis réinstaller les systèmes sans que le client ne s'en aperçoive. Il a même été possible de changer complètement d'architecture, passant d'un cluster partagé à un SAN boot, où chaque machine du réseau pouvait être libérée et reconfigurée une fois, sans que cela n'affecte le fonctionnement des clients.

Memory-Tetris

Le service commercial et les clients se sont montrés particulièrement enthousiastes car, avec un peu d'anticipation, il a été possible de toujours garder suffisamment de réserves pour mettre à disposition des systèmes Hana de taille moyenne de manière ad hoc, en remplissant les slots libres sur les machines. Et s'il n'y avait pas de slot libre assez grand sur aucune machine, il était toujours possible d'en libérer suffisamment par des rocades de petits systèmes.

L'ensemble rappelle beaucoup le jeu informatique Tetris, dans lequel des blocs de différentes tailles "tombent du ciel" et doivent être répartis de manière à former un "paquet de billes le plus dense possible". C'est un peu ce que nous faisons dans l'entreprise Hana. Ce qui tombe "du ciel", ce sont les demandes des clients pour de nouveaux systèmes Hana de n'importe quelle taille, qui doivent tous être disponibles dès hier.

Comme dans un jeu d'ordinateur, une répartition habile permet d'utiliser presque 100 % de la mémoire de toutes les machines en un minimum de temps, ce qui réjouit le CFO, même s'il se plaint toujours professionnellement que la demande des clients ne cesse d'augmenter et qu'il faut acheter de nouvelles machines toutes les quelques semaines pour obtenir à nouveau des créneaux libres.

Grâce à une réaffectation judicieuse, il est également possible d'adapter les systèmes clients en cours aux besoins réels. Grâce à notre "Observatoire de la mémoire Hana", nous pouvons donner aux clients SAP existants une prévision du moment où il sera nécessaire d'allouer plus de mémoire principale à un système Hana, afin d'éviter les fameux arrêts de grands rapports pour cause de "Out of Memory" (OOM).

Ce que de nombreux clients apprécient en outre, c'est qu'ils peuvent utiliser temporairement des systèmes Hana plus importants pour les PoC. Une fois le PoC terminé, les ressources sont remises dans le pool et il n'y a pas de frais supplémentaires. Ainsi, même pour les grands systèmes Hana, le client ne doit payer que ce dont il a besoin actuellement, contrairement aux fournisseurs de cloud où il faut réserver et payer trois ans à l'avance les grandes instances Hana qui ne correspondent pas à leurs blades standard.

La seule ombre au tableau est que sur une machine puissante de 4 To par exemple, on ne dispose pas de 4096 Go, car la virtualisation consomme elle-même quelques Go. Dans la plupart des cas, il est toutefois possible de se mettre d'accord avec le client sur le fait que 1 To est égal à 1000 Go - cela se fait alors très confortablement. Avec les nouvelles machines IBM Power 9, qui mettent à disposition un maximum de 16 TB avec 4 sockets et tout de même 8 TB avec des DIMM abordables, la possibilité d'optimiser l'environnement système s'améliore encore.

Conclusion

Grâce à Hana on Power, nous avons réussi à intégrer Hana de manière flexible et rentable dans un cloud privé, ce qui a permis d'augmenter considérablement la satisfaction des clients, des commerciaux et du service financier. La taille flexible des systèmes, la disponibilité rapide de nouveaux systèmes et l'utilisation temporaire des ressources font la joie des clients et du service commercial, tandis que le service financier utilise presque entièrement ses investissements en peu de temps. De plus, nous sommes en mesure de proposer des systèmes Hana plus grands, fonctionnant 7 jours sur 7 et 24 heures sur 24, à un prix nettement inférieur à celui de n'importe quel fournisseur de cloud public.

Cela se traduit par une augmentation constante du nombre d'installations. Actuellement, notre environnement système Hana on Power augmente de 1 TB par semaine grâce aux nouvelles installations de nos clients, et la tendance est au doublement. Hana on Power est Hana tel qu'on l'attend dans un cloud - chez Syntax (anciennement Freudenberg IT), nous l'appelons flexHana.

PDF dans d'autres langues :

EN / ES / FR