Maintenance imposée, feuilles de route peu claires

Les clients SAP sont mécontents, de nombreuses lignes ont déjà été écrites sur le comment et le pourquoi. Une maintenance imposée, des frais de licence élevés et des feuilles de route peu claires ne sont que quelques-uns des points qui reviennent sans cesse. Mais n'est-ce pas justement à l'heure actuelle que la corporation des conseillers technologiques apporte une contribution importante ?

La technologie sur laquelle repose un système SAP n'a pas changé au cours des dernières années. Elle se compose d'un système d'exploitation, d'un tas de fichiers exécutables et d'une base de données. C'est ainsi, c'était ainsi et cela restera ainsi pour le moment. Même la tendance au cloud et à S/4 n'y changera rien pour le moment. Un système SAP reste un système SAP.

De bonnes conditions

De nombreuses entreprises, qu'il s'agisse d'une entreprise interne ou d'une société de conseil, continuent à installer les logiciels manuellement, étape par étape. Les outils automatiques ne sont utilisés que par une minorité et, s'ils le sont, c'est pour un bon prix. Les outils open source et leurs possibilités ne sont pas utilisés. En Allemagne notamment, les bonnes solutions semblent toujours devoir coûter quelque chose. Est-ce encore d'actualité ? Ou devons-nous passer à l'étape suivante ?

Docker existe depuis 2013, Ansible depuis 2012 déjà, Kubernetes depuis 2015. Néanmoins, la technologie SAP semble souvent être à la traîne de la tendance vers plus d'agilité et de flexibilité. Le déploiement automatique est rudimentaire, le rolling kernel switch est rarement utilisé. L'Infrastructure as Code et le Containering semblent être passés complètement à côté de SAP jusqu'à présent. Pourtant, un système SAP offre en fait de bonnes conditions pour mettre en œuvre une telle approche.

Des questions très simples se posent donc : avons-nous tous simplement dormi ? Ne pouvons-nous pas déjà déployer automatiquement des systèmes SAP ? Et à quel point le déploiement automatique est-il déjà intégré ? Jetons donc un coup d'œil aux différents aspects d'un système SAP. Au début d'une vie SAP, il y a toujours la question de la structure et de la configuration : combien d'utilisateurs travaillent sur le système ? Combien de systèmes vais-je relier à mon système SAP et comment ? Est-ce que je n'ai besoin que d'un système de production ou est-ce que les tests et le développement sont également nécessaires ?

Dans les PME en particulier, on aboutit généralement à un environnement à trois systèmes, composé d'une combinaison de base de données et de serveur d'applications. Souvent, on ne compte qu'avec un seul serveur d'applications, notamment pour réduire les coûts. Dans l'optique de Hana, on calcule souvent au plus juste et on se concentre principalement sur les coûts. De nombreuses entreprises prévoient encore d'utiliser leurs propres centres de calcul ou du matériel en sous-traitance.

Ce faisant, on néglige souvent les possibilités à droite et à gauche du courant dominant. Imaginez le scénario suivant : Vous êtes une entreprise commerciale de taille moyenne et vous souhaitez migrer votre SAP ECC 6.0 EHP 7 d'AnyDB vers Hana pour être prêt à affronter l'avenir. Les rapports de dimensionnement vous indiquent un besoin de stockage d'une instance Hana de 1,5 TB et environ 500 utilisateurs doivent travailler sur le système dans le monde entier.

Comme vous faites du commerce dans le monde entier, vous voulez bien sûr que votre système de production soit hautement disponible. Vous avez déjà externalisé le développement et les collègues ne travaillent de toute façon que pendant les heures de bureau normales. Vous pourriez bien sûr mettre en place une nouvelle solution de virtualisation et acheter le matériel correspondant. Les données, l'installation et la maintenance sont entre vos mains. Le cas échéant, vous avez encore fait appel à un partenaire externe pour obtenir de l'aide.

De manière imprévue, votre département spécialisé a souhaité disposer d'un système d'entrepôt commercial. Or, votre matériel n'était pas du tout conçu pour cela.

Que faire de plus ? Continuer à réfléchir !

Option 1 : Vous achetez du nouveau matériel. Le processus d'acquisition vous prendra un certain temps et vous aurez besoin de l'espace nécessaire dans le centre de données.

Option 2 : Vous installez les systèmes en externe. Dans tous les cas, vous vous épargnerez le long processus d'acquisition du matériel et vous en confierez la responsabilité à d'autres. Qu'il s'agisse d'Amazon Web Services, de Microsoft Azure, de la plate-forme Google Cloud ou d'un autre hébergeur, la responsabilité du matériel est ailleurs. De nombreux hébergeurs vous déchargent également de la responsabilité du système d'exploitation et de la base de données. Félicitations, vous êtes arrivé dans la jungle des services. Vous n'avez plus le droit que d'utiliser le système et chaque modification nécessite un changement spécifique.

Option 3 : Vous voyez plus loin. Jusqu'à présent, vous avez exploité votre système ERP avec une réplication de système et vous souhaitez impérativement la conserver. Et si vous transfériez le côté réplication dans le cloud ? Vous aurez ainsi de la place pour le Business Warehouse souhaité et pourrez en même temps encore profiter des avantages du cloud.

"Mais les coûts !", penseront certainement certains. Le cloud n'est pas bon marché, aucun des trois grands ne mettra gratuitement son infrastructure à votre disposition et veut bien sûr encore gagner quelque chose. Mais si vous utilisez maintenant la réplication de système sans Memory Preload, vous ne payez tout d'abord que pour un système virtuel relativement petit et la mémoire de la base de données.

En cas de panne de la base de données principale, la Cloud Virtual Machine peut être adaptée et redémarrée de manière automatisée en quelques secondes. Ce n'est qu'à ce moment-là que vous payez pour la taille totale de la base de données Hana.

Si nous poursuivons l'idée un peu plus loin, nous pourrions tout de même réaliser des serveurs d'applications et une instance ASCS à haute disponibilité. Si nous les répartissons au niveau mondial, les collaborateurs au Japon et aux États-Unis se réjouiront également de la réduction des temps d'exécution de l'interface graphique. On peut bien sûr continuer à esquisser d'autres variantes, mais on arrive malheureusement assez vite dans des régions qui ne sont plus supportables et exploitables pour une PME.

Dans une entreprise, il y a toujours des périodes où l'utilisateur final souhaite que le système soit plus performant. L'ajout rapide d'un serveur d'applications est certainement une solution simple mais efficace. Les étapes nécessaires sont claires, mais même les techniciens chevronnés sont déjà occupés pendant une journée avec la mise à disposition, l'installation et la configuration. Et si l'on pouvait automatiser une grande partie du déploiement et de l'installation ?

Vous ne pouvez pas ? Mais si !

Infrastructure as a Code, Ansible et Unattended Installation sont les mots magiques. Le tout n'est pas limité à l'un des hypercalers, mais peut aussi être exécuté très simplement sur n'importe quel ESXi avec VSphere.

Commençons par la création de la machine virtuelle. Sur VMware, la VM est généralement créée à partir d'une autre par clonage ou à partir d'un modèle. Ensuite, on crée les contrôleurs SCSI et les disques durs nécessaires et on les intègre dans le système d'exploitation. Que ce soit avec des commandes ou avec Yast, on passe deux à trois heures rien que pour cette étape.

Avec une automatisation avec Ansible, nous pouvons déjà réaliser cette première étape en quelques minutes. En outre, nous pouvons déjà charger nos supports d'installation pour le serveur d'applications à partir d'un dépôt de données central et démarrer le gestionnaire de provisionnement de logiciels. Il n'est pas inutile de jeter un coup d'œil aux dépôts GitHub de Google et Amazon. On peut certainement y puiser l'un ou l'autre élément pour les scripts que l'on construit soi-même.

Dans le cas de Linux, les scripts n'ont rien de sorcier et tous ceux qui s'y sont déjà frottés s'en sortiront. Le téléchargement et la configuration des paquets SLES nécessaires deviennent ainsi, par exemple, un script shell très court. La mise à disposition des points de montage nécessaires ou des groupes de volumes et des volumes logiques se fait également en quelques commandes familières à la plupart des connaisseurs de Linux. Windows et Linux nous ont habitués à de jolies interfaces graphiques colorées, alors que beaucoup de choses pourraient être traitées en quelques commandes. Comme il est également possible de les enregistrer et de les combiner, les futurs déploiements seront de plus en plus rapides.

Pierres d'achoppement

Maintenant que la VM est prête et que le système d'exploitation est configuré, les supports d'installation nécessaires et le SWPM sont téléchargés. Dans le cas de la plateforme cloud de Google, nous plaçons les données nécessaires de manière organisée dans un cloud bucket et pouvons maintenant charger les données du cloud bucket sur la nouvelle VM à l'aide de simples commandes gsutil. Cette procédure fonctionne bien sûr aussi avec AWS et Azure ainsi que comme simple montage NFS dans l'environnement VMware.

Après avoir placé et décompressé le Software Provisioning Manager (ci-après SWPM), il est déjà temps de l'appeler. C'est ici qu'il faut éviter les petits écueils. Tout d'abord, nous avons besoin d'un fichier inifile.params et du fichier instkey.pkey. Le fichier inifile.params contient le contenu et les médias et mots de passe à installer.

Les mots de passe sont cryptés avec la clé du fichier instkey.pkey. Pour obtenir les deux fichiers, il faut initialement effectuer l'installation manuellement et l'arrêter dans l'aperçu de l'installation de SWPM. Ensuite, enregistrez les deux fichiers et conservez-les précieusement. Pour les systèmes suivants, vous pouvez facilement modifier les inifile.params et effectuer ainsi des installations et surtout des copies de système beaucoup plus rapidement.

Le deuxième point important est l'ID produit du système à installer. Vous le trouverez à nouveau dans inifile.params et, comme son nom l'indique, il est spécifique au produit.

Nous savons maintenant qu'il est possible d'installer automatiquement des systèmes avec SWPM. Mais qu'est-ce que cela nous apporte au quotidien ? Revenons à notre étude de cas initiale, à savoir ce qu'il faut faire avec le nouveau BW et l'ancien ERP.

Nous supposons simplement que les systèmes ERP doivent être migrés vers l'un des trois grands fournisseurs de cloud pendant la migration vers Hana. Si nous nous rappelons la structure d'un système SAP, nous pouvons utiliser ces connaissances pour accélérer considérablement la migration vers Hana.

Automatiser les déploiements

Un système SAP se compose à la base de quelques fichiers exécutables, des profils nécessaires et d'une base de données contenant les informations sur les versions. Pour que la migration soit réussie, il suffit que le noyau corresponde aux informations stockées dans la base de données et que notre système fonctionne sur le nouveau matériel ou la nouvelle base de données. L'objectif doit être d'installer les systèmes cloud le plus rapidement possible par déploiement automatique. Ensuite, il peut être converti dans le système source correspondant par un rafraîchissement de la base de données par exportation/importation.

Nous pouvons bien sûr automatiser encore davantage le déploiement des systèmes. Ainsi, les Ansible Playbooks sont une occupation qui vaut la peine d'être faite pour la crise actuelle. Même pour un consultant SAP expérimenté, ce sujet sera d'abord un terrain totalement inconnu, mais la communauté et Red Hat ont entièrement documenté les fonctions les plus importantes.

Les fonctions de base pour la mise à disposition d'un système sont définies dans un playbook. Dans le langage courant, il s'agit d'un ensemble de tâches qui doivent être exécutées sur l'hôte correspondant. De la création de groupes de volumes au lancement de scripts, en passant par la création d'utilisateurs et de groupes, tout est possible. Sans autre intervention, nous pouvons ainsi installer des systèmes ou des serveurs d'applications, effectuer des copies de systèmes ou même désinstaller des choses.

Comme vous pouvez le constater, je ne vous ai pas donné ici un guide complet sur le déploiement automatique de systèmes SAP. Ce n'est d'ailleurs pas possible, car chaque environnement système et chaque exigence sont différents. Le chemin et la décision de se transformer en cloud sont aussi individuels qu'il existe de possibilités. Toutes les possibilités décrites sont également possibles dans votre propre centre de données et avec VMWare et ne nécessitent pas une grande infrastructure de cloud. En fin de compte, comme c'est souvent le cas, c'est l'environnement système hybride que nous rencontrerons.