La plupart des programmes de réduction des coûts mainframe commencent par chercher à consommer moins de MIPS. C'est la mauvaise cible, car IBM n'a jamais facturé personne en MIPS. Dans ses deux modèles de tarification actuels, l'unité de facturation est le MSU, et ce qu'IBM fait de vos MSU dépend entièrement du modèle sur lequel vous êtes.
Avec Advanced Workload License Charges (AWLC), vous êtes facturé sur la plus haute moyenne glissante sur quatre heures que vos partitions atteignent dans le mois. Un seul pic fixe la facture. Vous pouvez donc faire tourner plus de travail et payer moins, à condition que ce travail tombe aux bons endroits.
Cet article porte sur le mécanisme AWLC, car c'est là que redessiner le mois change la facture. Si vous êtes facturé en Tailored Fit Pricing (TFP), les leviers sont différents, et l'article AWLC vs TFP traite de ce choix.
MIPS, MSU et ce qu'IBM vous facture vraiment
Le MIPS (Million Instructions Per Second) est une mesure de vitesse. Il indique à peu près la quantité de travail qu'un processeur peut faire. Il sert donc à dimensionner le matériel et à comparer des machines. Il n'apparaît nulle part sur votre facture.
Ce qui apparaît sur votre facture, c'est le MSU (Million Service Units), l'unité de consommation d'IBM. En facturation en sous-capacité, ce n'est pourtant pas le total de vos MSU du mois. IBM facture les produits en sous-capacité sur le pic de la moyenne glissante sur quatre heures, ou R4HA (rolling four-hour average), atteint par la partition logique (LPAR) sur laquelle tourne chaque produit (BMC). La R4HA est recalculée en continu. Le système prend une mesure toutes les cinq minutes, fait la moyenne de douze de ces mesures pour obtenir un chiffre horaire, et fait glisser ce calcul sur une période de quatre heures (Planet Mainframe).
À la fin du mois, la valeur la plus haute atteinte par cette moyenne fixe vos Monthly License Charges (MLC, les frais de licence mensuels) pour chaque produit en sous-capacité de cette partition. Une seule période de quatre heures sur tout le mois décide de ce que vous payez. Vous la déclarez avec le Sub-Capacity Reporting Tool (SCRT), un outil IBM gratuit qui lit un mois de données SMF (System Management Facilities) de types 70-1 et 89, et produit le rapport sur lequel IBM facture (IBM).
Ce mécanisme change toute la démarche. Deux sites qui font tourner exactement la même charge annuelle peuvent payer des montants très différents. Celui dont les pics se superposent paie plus que celui dont les pics sont étalés. Dans les deux cas, aucun travail n'a été supprimé.
La question n'est plus « comment consommer moins », mais « qu'est-ce qui tourne dans notre fenêtre de pic, et ce travail doit-il vraiment y être ».
D'où vient vraiment le coût
Avant d'y consacrer des efforts, il est utile de savoir quelles parties de la facture ce travail peut atteindre.
Le matériel est une décision d'investissement prise tous les quelques années, et la maintenance suit le matériel. Les coûts de personnel suivent leur propre logique. Ce que l'optimisation des MIPS atteint, c'est la ligne logicielle : les MLC des produits IBM en sous-capacité, plus les licences d'éditeurs tiers indexées sur les mêmes mesures de capacité. Sur la plupart des sites, c'est la plus grosse ligne maîtrisable, et elle réagit en un cycle de facturation plutôt qu'en un cycle budgétaire.
Ce périmètre mérite d'être clair. La gestion des pics fait bouger la ligne logicielle. Elle ne restructure pas un budget mainframe.
Placer le travail, pas le supprimer
La première technique d'optimisation des MIPS est aussi la moins technique. Identifiez ce qui tourne pendant votre fenêtre de pic, puis demandez-vous si ce travail doit y tourner.
Le batch est la cause la plus fréquente. Rapports, extractions, tâches de maintenance, archivages : du travail sans échéance métier, planifié à une heure choisie il y a des années et jamais revue, qui tombe aujourd'hui en plein sur le pic des transactions en ligne. Le déplacer demande de l'attention sur la planification, et rien d'autre.
Le placement sur les partitions est le deuxième levier. Les frais sont calculés par LPAR. Deux charges de travail qui culminent ensemble sur une partition coûtent donc plus cher que les deux mêmes charges réparties sur des partitions dont les pics tombent à des moments différents. La machine est la même, le travail total aussi. Seule la facture change.
Certaines charges de travail peuvent quitter complètement la plateforme, d'autres ne le peuvent vraiment pas. Soyez prudent dans l'analyse, car l'étude qui annonce « déplacez ceci et économisez » chiffre souvent la puissance de calcul et oublie les données qui l'entourent et qu'il faudrait déplacer aussi. Regardez ce qu'une charge de travail utilise réellement avant de supposer qu'elle peut partir.
Le soft capping dynamique
Avec la defined capacity, vous fixez un plafond sur une LPAR, et IBM facture le plus bas entre votre pic de R4HA et cette defined capacity (Planet Mainframe). Le problème paraît réglé. On fixe une limite, on paie la limite.
En pratique, c'est là que les sites rencontrent des problèmes. Un plafond statique ne sait pas quel jour on est. Fixez-le assez bas pour faire de vraies économies, et tôt ou tard il bloquera une charge de travail qui avait besoin de capacité. Dès que la R4HA dépasse la limite, la partition peut être plafonnée, et le travail est retardé (Planet Mainframe). Clôture de fin de mois, événement de marché, relance après un incident : les moments où la demande grimpe sont souvent ceux où un retard est le moins acceptable. Le plafond est alors relevé « temporairement », personne ne le rabaisse, et l'économie disparaît en quelques trimestres.
L'autre approche consiste à ajuster la capacité en continu selon ce qui se passe réellement, en protégeant les charges de travail soumises à un SLA (accord de niveau de service) et en retenant les autres.
Il faut savoir où cette approche cesse de s'appliquer. Le capping sert à contenir un pic de facturation. En TFP, il n'y a pas de pic à contenir, et le capping à des fins de coût n'a donc pas de cible (l'article AWLC vs TFP).
C'est ce que fait Zetaly Automated Capacity (ZAC). Il surveille la R4HA en temps réel et réalloue la capacité avant les pics qui comptent pour la facture. Il freine le travail moins prioritaire, tandis que les services critiques gardent leur marge. ZAC gère le pic de facturation, pas la consommation, et cette distinction compte : un site peut consommer plus et payer moins une fois sa R4HA lissée. Sur plus de 30 déploiements en entreprise, ZAC réduit les MLC de 5 à 20 % dès la mise en route. Orange, par exemple, utilise ZAC pour absorber les hausses annuelles du prix de ses logiciels sans impact sur les performances (Zetaly). ZAC s'installe sur site et tourne directement sur votre mainframe.
Les termes de licence et ce qui est vraiment négociable
Deux points méritent d'être vérifiés avant votre prochain renouvellement.
Le premier est ce pour quoi vous avez une licence, comparé à ce que vous faites tourner. Les inventaires de produits dérivent au fil des années. Des sites conservent des produits en sous-capacité que personne n'a ouverts depuis longtemps, et chacun est facturé sur le même pic de R4HA que tout le reste de la partition. Un inventaire honnête est un travail ingrat, qui se rembourse souvent de lui-même.
Le second est le modèle de tarification sur lequel vous êtes, car il décide lesquels des leviers ci-dessus vous sont accessibles.
AWLC est le modèle fondé sur le pic que décrit tout ce qui précède. TFP facture à l'inverse, sur la consommation totale de l'année. Les actions utiles ne sont donc pas les mêmes. Si un changement est envisagé, l'article AWLC vs TFP présente les compromis et le bon moment pour changer.
Planification de capacité
La gestion des pics traite le mois en cours. La planification de capacité traite l'année.
La plupart des sites planifient leur capacité en appliquant un pourcentage de croissance aux totaux de l'année précédente. Cette méthode convient pour dimensionner le matériel, mais prévoit mal le coût. Le coût suit les pics, et les pics suivent les événements métier : un lancement de produit, un cycle saisonnier, une migration, une acquisition. Planifier en fonction de ces événements vous dit quand la facture va bouger, assez tôt pour agir. Zetaly Resource Planning (ZRP) est conçu pour cette vision à l'avance.
Ce qu'il faut mesurer avant de changer quoi que ce soit
Rien de tout cela ne peut se juger sans point de référence, et ce point de référence n'est pas « nos MIPS ».
Il vous faut le pic de R4HA par LPAR et par mois sur au moins douze mois, les charges de travail qui tournent pendant ces pics, l'écart entre votre pic et votre charge habituelle, et les produits en sous-capacité présents sur chaque partition. Cet écart donne la taille approximative de l'opportunité. Zetaly Cost Control (ZCC) donne une visibilité en temps réel sur cet écart, mais les douze mois de rapports SCRT déjà envoyés vous mèneront en grande partie à une première réponse.
Ce travail vaut la peine d'être fait avant de choisir une approche. L'optimisation des MIPS mainframe n'est pas une technique unique appliquée partout. Un site un peu au-dessus de sa charge moyenne n'a pas le même problème qu'un site très au-dessus, et les deux demandent un travail différent.
FAQ
Quelle est la différence entre MIPS et MSU ?
Le MIPS (Million Instructions Per Second) mesure la vitesse d'un processeur et sert à dimensionner le matériel. Le MSU (Million Service Units) est l'unité de consommation d'IBM, et il apparaît sur votre facture. Les logiciels en sous-capacité sont facturés sur le pic mensuel de la moyenne glissante sur quatre heures de la consommation en MSU, par partition logique.
Quelles sont les techniques d'optimisation des MIPS les plus efficaces ?
Sortir de votre fenêtre de pic le batch sans échéance, répartir sur des partitions différentes les charges de travail qui culminent ensemble, et gérer la defined capacity de façon dynamique plutôt qu'avec une limite statique. Le nettoyage de l'inventaire des licences se rembourse souvent aussi. Aucune de ces techniques ne réduit le travail que vous faites.
Comment réduire les coûts du mainframe sans réduire la charge de travail ?
IBM facture les produits en sous-capacité sur le pic mensuel de votre moyenne glissante sur quatre heures, pas sur la consommation totale. Déplacer le travail dans le temps fait baisser ce pic, pour le même volume traité. Deux sites qui ont la même charge annuelle peuvent payer des montants très différents selon la façon dont tombent leurs pics.
Qu'est-ce que le MIPS sur un mainframe ?
MIPS signifie Million Instructions Per Second et mesure la quantité de travail qu'un processeur peut faire. C'est une mesure de capacité, utile pour comparer des machines et dimensionner le matériel. Le MIPS n'apparaît pas sur votre facture IBM, qui est calculée à partir de la consommation en MSU.
Quelles économies sur le mainframe sont réalistes ?
Zetaly Automated Capacity réduit les Monthly License Charges de 5 à 20 % dès la mise en route, sur plus de 30 déploiements en entreprise. Orange l'utilise pour absorber les hausses annuelles du prix de ses logiciels sans impact sur les performances. Le résultat d'un site dépend surtout de l'écart entre son pic actuel et sa charge habituelle.
Le soft capping ralentit-il mes charges de travail ?
Un plafond statique peut les ralentir. Quand la moyenne glissante sur quatre heures dépasse une limite de defined capacity, la partition peut être plafonnée et le travail est retardé. Une gestion dynamique évite ce problème en réallouant la capacité en temps réel, et protège tout ce qui est soumis à un SLA.
