Le problème est maîtrisé depuis des années. Mais, évalue-t-on toujours toutes les finesses du dimensionnement du centre informatique hébergeant l’ERP ? Réseau, serveur et stockage, les ingrédients entrant dans la bonne formule du calibrage de la plate-forme matérielle sont nombreux. En oublier un, c’est l’assurance d’une inadéquation du choix technique pour les besoins à venir.Le dimensionnement d’une plate-forme ERP commence par la détermination du nombre et du type de module à installer, du nombre d’utilisateurs total et par module, et du niveau d’activité (faible, moyenne ou élevée) de ces utilisateurs.
Satisfaire à des contraintes de temps de réponse
Ces informations permettent de définir le niveau minimal de puissance fonctionnelle (mesuré, par exemple, en unités SAPS dans le monde R/3) que devra délivrer le centre de données ERP. Cela n’est cependant que le point de départ de l’évaluation. Il faudra aussi tenir compte des contraintes de type SLA (Service level agreement). Il s’agira, notamment, de faire en sorte que le centre informatique ERP satisfasse à des contraintes de temps de réponse. Tel système devra délivrer un temps de réponse inférieur à la seconde dans 98 % des cas. Eu égard à ce seul critère de performances, la puissance du serveur devra donc être plus importante que ce que laissait augurer l’estimation initiale de la charge transactionnelle.D’un projet à un autre, la puissance qu’il faudra “aligner” pourra fortement varier. Considérons les contraintes de haute disponibilité : celles-ci imposeront de mettre en place des ressources informatiques redondantes, non seulement pour assurer la continuité de service, mais aussi pour maintenir un niveau de performances satisfaisant en conditions d’exploitation dégradées. Mais, souvent, la charge de travail des systèmes ERP en production autre que le transactionnel est sous-évaluée. Quels sont les traitements par lots que ces serveurs auront à assurer, leurs fréquences, volumes, temps de passage et impact sur la puissance CPU ?
Une architecture distribuée multiniveau ou consolidée ?
Ces questions trouvent rarement de réponses précises. En conséquence, l’architecture technique d’une plate-forme ERP devra être abordée en plusieurs phases : mise en production sur un site circonscrit, montée en charge, capacity planning (gestion prévisionnelle de la puissance des machines) et dimensionnement itératif. Faut-il opter pour une architecture informatique distribuée multiniveau ou consolidée ? Encore récemment, le modèle architectural en vogue privilégiait la première solution, dans laquelle un ou plusieurs serveurs de base de données sont au service de un ou plusieurs serveurs d’applications. Reste que, avec les actuels serveurs d’entreprise de classe mainframe, modules et applications ERP peuvent être consolidés sur un même serveur ?” dans le monde Unix (chez IBM, HP, et Sun, notamment) ou même Windows NT (chez Unisys). Le modèle d’architecture distribué n’a pas, pour autant, été évacué, ne serait-ce que parce que, e-business aidant, on se retrouve à adjoindre aux applications back-office des applications de CRM, commerce électronique et passerelles Web, qu’il peut être rationnel d’ôter des serveurs dédiés.En corollaire, la problématique du calibrage de l’infrastructure réseau des centres informatiques ERP reste d’actualité. La mise en production d’une grosse solution ERP peut, d’ailleurs, être l’occasion de passer au Gigabit Ethernet. Difficile de faire avaler cette pilule réseau à un projet fonctionnel. Il n’empêche que les contraintes SLA permettront difficilement de faire l’impasse sur une réévaluation des performances de l’existant en matière de réseau. D’autant que d’autres facteurs, le stockage en ligne et la sauvegarde, contribuent à accroître le stress réseau.L’un des grands mérites des architectures de réseau SAN (Storage area network) est de d’autoriser l’isolation des flux de données des échanges transactionnels. C’est pourquoi les SAN tendent à s’imposer dans les grands centres ERP, ne serait-ce que parce ce qu’on souhaite installer des solutions de sauvegarde modernes de type LANless-serverless backup, pour décongestionner les réseaux transactionnels et économiser la puissance des serveurs ERP.Une fois arrêtés les éléments de l’architecture technique, il existe un bon moyen, en phase de préproduction et/ou d’évolution, de jauger l’adéquation d’une plate-forme aux besoins : le test de performances. Nés avec le client-serveur, les outils de test de montée en charge proposés, entre autres, par Compuware, Mercury ou Rational ont été rapidement adaptés à certains ERP et progiciels intégrés. Leurs éditeurs ont travaillé avec les fournisseurs d’ERP, de façon à reconnaître les objets graphiques spécifiques, et à fournir des bibliothèques de scripts permettant de jouer les processus métiers les plus représentatifs. Il ne faut cependant pas se leurrer : tout séduisants que soient ces logiciels de test, ils impliquent un effort d’ingénierie important pour déterminer les charges de test représentatives et conduire les campagnes de test. Leur mise en ?”uvre a, certes, été facilitée par l’introduction de consoles de pilotage de campagnes de test ainsi que d’outils de capture de l’expérience utilisateur réelle.
Les tests de performances devraient se généraliser
Néanmoins, l’investissement à consentir pour monter une campagne de test ne pourra être rentabilisé que si l’on procède selon une logique d’industrialisation et, donc, de réutilisation des scripts, pour déployer les ERP dans des sites multiples ou pour conduire les mises à jour des solutions applicatives.Les évolutions e-business inciteraient tout de même à un plus large recours aux tests de performances, dans la mesure où il est difficile de déterminer, a priori, l’impact transactionnel de modules front-office. L’aptitude des outils de test à traiter les flux Internet en plus des flux client-serveur conventionnels n’est donc pas le moindre de leur intérêt.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
