En mode rattrapage

IBM déclare : "Avec HoP, nous ne nous adressons pas seulement aux anciens clients SAP qui utilisent des systèmes IBM Power, mais aussi aux clients x86 qui sont insatisfaits ou qui s'attendaient à autre chose".

Et en effet, le degré de satisfaction de l'un ou l'autre client SAP concernant le matériel Hana-In-Memory-Intel utilisé semble - pour le formuler avec retenue - être limité. Un utilisateur de HoI rapporte par exemple que les rapports (BW-on-Hana) créés pour un petit groupe d'utilisateurs (trois ou quatre utilisateurs) nécessitent une extension supplémentaire du noyau, avec les coûts supplémentaires que cela implique - bien que l'on utilise l'un des plus grands systèmes Hana-on-Intel disponibles. Il y aurait également des instabilités imprévues dans le système Suite on Hana (SoH). SoH est utilisé dans l'entreprise par environ 12.000 utilisateurs SAP dans le monde entier.

En tant que superviseur technologique, SAP connaît certainement les domaines d'optimisation possibles lors de l'utilisation de systèmes Hana on Intel. En effet, SAP définit les spécifications pour les serveurs Hana on Intel ou autorise des développements supplémentaires - et reçoit également des informations en retour de la part des fournisseurs HoI ou des fournisseurs de services SAP. Par exemple, en ce qui concerne la stabilité dans différents scénarios d'application, le "core to memory ratio" ou l'utilisation de technologies de virtualisation. On peut se poser la question : Pourquoi SAP ne mise-t-il pas ici aussi sur l'open source, par exemple sur Xen ou KVM, au lieu d'utiliser exclusivement VMware/vSphere ? En ce qui concerne les serveurs Hana basés sur les processeurs Power8, IBM n'a pu, comme on le sait, démarrer le marché qu'avec du retard, et ce n'est apparemment pas le partenaire de SAP, IBM, qui en est responsable. Mais aujourd'hui, ce dernier a manifestement le vent en poupe pour les systèmes Hana on Power (systèmes Scaleup et Scaleout) certifiés par SAP depuis un certain temps déjà. On se trouve pour ainsi dire en mode de rattrapage. IBM semble également avoir acquis suffisamment d'expérience dans l'exploitation de Hana auprès de différents utilisateurs SAP. Selon ses propres informations, l'entreprise compte actuellement environ 850 clients dans le monde qui ont acheté des systèmes Power pour l'utilisation de Hana, tous avec Suse Linux Enterprise Server (SLES) for SAP Applications comme plate-forme de système d'exploitation. Et l'on s'attend à ce que la barre des 1.000 clients soit franchie dès le troisième trimestre en cours.

Maintenant 5 800 clients S/4 présumés

Selon l'entreprise, "les systèmes HoP se répartissent en grande partie sur Suite on Hana ainsi que sur BW on Hana et environ 10 à 15 pour cent sur S/4 Hana". Il n'y a actuellement pas de données concrètes sur le pourcentage de systèmes déjà en production. Il paraît que le dernier chiffre pour S/4, le successeur de la technologie Business Suite, est d'environ 5.800 licences vendues. Toutes ne sont certainement pas mises en production. La prochaine version de S/4 est d'ailleurs prévue pour 1709. 17 est pour 2017 et 09 pour septembre. Le renforcement récent des activités de vente et de marketing montre que le partenariat entre IBM et SAP a pris de l'ampleur en ce qui concerne Hana on Power. Des événements clients sont organisés sous le slogan "The perfect match : Hana et IBM Power", avec la participation de SAP. En outre, des bannières publicitaires sur le thème "IBM et SAP" sont diffusées. Ce qui ne serait probablement pas possible sans le placet de SAP.

Différenciation réfléchie

Quels sont les avantages principaux de HoP qui sont maintenant mis en avant par IBM par rapport à la concurrence HoI ?, comment se positionne-t-on sur le marché des serveurs Hana ? ou en quoi l'offre de matériel IBM Hana doit-elle principalement se différencier de la concurrence Hana on Intel ?

Le prix d'achat par rapport aux systèmes HoI ne peut pas être en cause. IBM communique qu'il faut débourser un peu plus d'argent pour acheter des systèmes HoP que des systèmes HoI. Néanmoins, "on obtient de la qualité en échange. Et les coûts d'acquisition un peu plus élevés sont compensés par les avantages en termes de flexibilité", explique l'entreprise. Selon l'entreprise, ces avantages résident en particulier dans la possibilité d'activer ou de désactiver de manière flexible les ressources de processeur existantes et non utilisées (ressources au sein de ce que l'on appelle les LPAR avec partitionnement logique de la technologie de virtualisation IBM PowerVM) ou les ressources de mémoire, ainsi que de les déplacer/affecter, même par exemple dans le cadre d'un environnement IaaS de cloud privé.

Avec PowerVM, il est possible de créer des LPAR dans une bande passante de 0,1 cœur par exemple, avec une taille en mémoire de 32 téraoctets, ou inversement de définir uniquement la LPAR avec 1 Go et 192 cœurs, indépendamment des socles de processeur et de la mémoire principale qui y est installée, de mettre à disposition ou d'utiliser de manière flexible des ressources pour Hana, en fonction du cas d'application. Il est également possible de mettre en œuvre des consolidations de systèmes plus poussées. Cela n'est pas possible dans l'environnement Hana on Intel, souligne-t-on. De plus, le nombre utilisable sous PowerVM est de 7 LPAR productifs avec Hana sur les grands serveurs Power Enterprise d'IBM, les charges de travail Hana non productives et toutes les autres applications comme les serveurs d'application SAP, AIX, Linux, System i etc. sont exploitées dans le pool de processeurs partagés. De même, l'overhead de PowerVM serait nettement plus faible que celui de VMware et x86.

Le deuxième avantage qu'IBM met en avant concerne l'aspect RAS, c'est-à-dire tout ce qui a trait à la fiabilité, à la disponibilité et au service. "Nous connaissons les systèmes SAP d'IBM et les paysages SAP dans les moindres détails depuis des décennies et nous savons comment fonctionne une mission critique SAP 7×24 efficace avec S/4 Hana ou Suite on Hana, ainsi que les exigences et les besoins nécessaires pour cela, réalisables avec Power et d'autres solutions IBM", explique l'Ondit. Pour ce faire, l'Ondit couvre, selon ses propres indications, les champs thématiques importants dans l'environnement SAP comme la High Availability (HA) et la Disaster Recovery (DR), également avec le Hana System Replication Service ou les Suse SLES for SAP Applications High Availability Extensions (HAE), ainsi qu'avec ses propres offres de solutions - en fonction des exigences des utilisateurs et de ce qu'ils sont prêts à payer pour une solution Hana HA ou DR d'un point de vue monétaire.

Enfin, mais non des moindres, IBM fait référence aux performances qui pourraient être obtenues avec le matériel Hana on Power. Ils estiment par exemple que des cœurs puissants avec une bande passante élevée présentent des avantages. On pourrait ainsi traiter jusqu'à huit threads par cœur, contre deux seulement pour Intel. Le concept de cœurs puissants avec une bande passante élevée serait idéal pour les applications Hana en mémoire, veut-on savoir. Des exemples d'applications HoP sont cités à l'appui, par exemple par une entreprise pharmaceutique qui utilise 50 cœurs HoP (BW on Hana, sept To de mémoire Hana, système scale-up) au lieu de 300 cœurs HoI et dont les temps de réponse ont été réduits de 14 pour cent. De la même manière, il est fait état d'une utilisation d'analyseur de banque où le débit de Hana on POWER était 4 fois plus élevé que celui de Hana on Intel. IBM met également en avant une "correction d'erreur intelligente", une sorte de fonctionnalité d'auto-réparation matérielle pour la mémoire principale, qui devrait en fin de compte contribuer à réduire les pannes de Hana. Sans cette fonction, une base de données Hana d'un To serait indisponible 32 fois par an ou ne pourrait pas être utilisée dans son intégralité en raison d'une panne, selon les explications données, d'un point de vue statistique.

Clientèle hétérogène

IBM met à disposition différents serveurs HoP-Scaleout basés sur Power8 (9, 10 et 11 sont sur la feuille de route Power et sont déjà en cours de développement), d'une capacité In-Memory de 512 Go jusqu'aux serveurs d'entreprise avec un maximum de 32 To de mémoire principale. Bien entendu, le concept TDI (Tailored Datacenter Integration) de SAP est soutenu, avec la possibilité d'utiliser justement des serveurs HoP et des composants d'infrastructure tels que des composants de stockage ou de réseau d'un autre fournisseur. Toutefois, on ne cache pas "que nous préférons que les clients SAP utilisent les systèmes Hana on Power avec les produits de stockage IBM Spectrum, y compris FlashSystem et Storwize". Si l'on prend la peine de regarder quels sont les (groupes de) clients SAP parmi les 850 clients HoP actuels, on constate qu'il ne s'agit pas exclusivement d'anciens clients SAP Power AIX (SAP Classic). Mais aussi d'anciens clients Hana on Intel. Les clients HoP sont souvent de très gros utilisateurs SAP, mais aussi des PME, ainsi que des fournisseurs de services SAP. En outre, il s'agit de clients SAP existants qui sont passés de leur "AnyDB" à Hana ou qui sont en train de le faire. Il est intéressant de constater qu'ils passent également d'IBM DB2 à Hana. On aimerait bien jouer au chat et à la souris avec les discussions internes entre la "fraction DB2" et la "fraction Hana on Power"...
Faits marquants de l'étude

Le regard se pose avec une certaine perplexité sur un camembert qui montre les parts de marché des fournisseurs de serveurs Hana d'une étude IDC de novembre 2016. Et ce d'autant plus que l'on en connaît une autre, celle de Gartner de juin 2016. Dans l'étude de Gartner, HPE (pour les déploiements dits physiques) est clairement en tête, avec bien plus de 50 %, suivi de Lenovo, Fujitsu, Dell, Cisco, Hitachi, SGI, Huawei, IBM, Atos et NEC. Si l'on regarde le graphique IDC, Cisco est le numéro un avec un peu plus de 20 %, puis vient HPE (16,4), ensuite IBM Power (15,3), Dell (15), Lenovo (6,9)/IBM System x (8,9), Huawei (4,2), Bull (Atos 4.0), Fujitsu (3,1) et d'autres avec 5,8 %. En y regardant de plus près, on constate que cette étude IDC ne porte que sur le marché nord-américain, et ce sur la base de 300 réponses. Les différences pourraient être dues aux différentes périodes d'observation ou à la restriction géographique de l'enquête. Les différences sont toutefois étranges ou frappantes.