La plupart des programmes de r\u00e9duction des co\u00fbts mainframe commencent par chercher \u00e0 consommer moins de MIPS. C'est la mauvaise cible, car IBM n'a jamais factur\u00e9 personne en MIPS. Dans ses deux mod\u00e8les de tarification actuels, l'unit\u00e9 de facturation est le MSU, et ce qu'IBM fait de vos MSU d\u00e9pend enti\u00e8rement du mod\u00e8le sur lequel vous \u00eates.<\/p>\n\n\n\n
Avec Advanced Workload License Charges (AWLC), vous \u00eates factur\u00e9 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, \u00e0 condition que ce travail tombe aux bons endroits.<\/p>\n\n\n\n
Cet article porte sur le m\u00e9canisme AWLC, car c'est l\u00e0 que redessiner le mois change la facture. Si vous \u00eates factur\u00e9 en Tailored Fit Pricing (TFP), les leviers sont diff\u00e9rents, et l'article AWLC vs TFP<\/a> traite de ce choix.<\/p>\n\n\n\n Le MIPS (Million Instructions Per Second) est une mesure de vitesse. Il indique \u00e0 peu pr\u00e8s la quantit\u00e9 de travail qu'un processeur peut faire. Il sert donc \u00e0 dimensionner le mat\u00e9riel et \u00e0 comparer des machines. Il n'appara\u00eet nulle part sur votre facture.<\/p>\n\n\n\n Ce qui appara\u00eet sur votre facture, c'est le MSU (Million Service Units), l'unit\u00e9 de consommation d'IBM. En facturation en sous-capacit\u00e9, ce n'est pourtant pas le total de vos MSU du mois. IBM facture les produits en sous-capacit\u00e9 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<\/a><\/strong>). La R4HA est recalcul\u00e9e en continu. Le syst\u00e8me 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\u00e9riode de quatre heures (Planet Mainframe<\/a><\/strong>).<\/p>\n\n\n\n \u00c0 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\u00e9 de cette partition. Une seule p\u00e9riode de quatre heures sur tout le mois d\u00e9cide de ce que vous payez. Vous la d\u00e9clarez avec le Sub-Capacity Reporting Tool (SCRT), un outil IBM gratuit qui lit un mois de donn\u00e9es SMF (System Management Facilities) de types 70-1 et 89, et produit le rapport sur lequel IBM facture (IBM<\/a><\/strong>).<\/p>\n\n\n\n Ce m\u00e9canisme change toute la d\u00e9marche. Deux sites qui font tourner exactement la m\u00eame charge annuelle peuvent payer des montants tr\u00e8s diff\u00e9rents. Celui dont les pics se superposent paie plus que celui dont les pics sont \u00e9tal\u00e9s. Dans les deux cas, aucun travail n'a \u00e9t\u00e9 supprim\u00e9.<\/p>\n\n\n\n La question n'est plus \u00ab comment consommer moins \u00bb, mais \u00ab qu'est-ce qui tourne dans notre fen\u00eatre de pic, et ce travail doit-il vraiment y \u00eatre \u00bb.<\/p>\n\n\n\n Avant d'y consacrer des efforts, il est utile de savoir quelles parties de la facture ce travail peut atteindre.<\/p>\n\n\n\n Le mat\u00e9riel est une d\u00e9cision d'investissement prise tous les quelques ann\u00e9es, et la maintenance suit le mat\u00e9riel. Les co\u00fbts 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\u00e9, plus les licences d'\u00e9diteurs tiers index\u00e9es sur les m\u00eames mesures de capacit\u00e9. Sur la plupart des sites, c'est la plus grosse ligne ma\u00eetrisable, et elle r\u00e9agit en un cycle de facturation plut\u00f4t qu'en un cycle budg\u00e9taire.<\/p>\n\n\n\n Ce p\u00e9rim\u00e8tre m\u00e9rite d'\u00eatre clair. La gestion des pics fait bouger la ligne logicielle. Elle ne restructure pas un budget mainframe.<\/p>\n\n\n\n La premi\u00e8re technique d'optimisation des MIPS est aussi la moins technique. Identifiez ce qui tourne pendant votre fen\u00eatre de pic, puis demandez-vous si ce travail doit y tourner.<\/p>\n\n\n\n Le batch est la cause la plus fr\u00e9quente. Rapports, extractions, t\u00e2ches de maintenance, archivages : du travail sans \u00e9ch\u00e9ance m\u00e9tier, planifi\u00e9 \u00e0 une heure choisie il y a des ann\u00e9es et jamais revue, qui tombe aujourd'hui en plein sur le pic des transactions en ligne. Le d\u00e9placer demande de l'attention sur la planification, et rien d'autre.<\/p>\n\n\n\n Le placement sur les partitions est le deuxi\u00e8me levier. Les frais sont calcul\u00e9s par LPAR. Deux charges de travail qui culminent ensemble sur une partition co\u00fbtent donc plus cher que les deux m\u00eames charges r\u00e9parties sur des partitions dont les pics tombent \u00e0 des moments diff\u00e9rents. La machine est la m\u00eame, le travail total aussi. Seule la facture change.<\/p>\n\n\n\n Certaines charges de travail peuvent quitter compl\u00e8tement la plateforme, d'autres ne le peuvent vraiment pas. Soyez prudent dans l'analyse, car l'\u00e9tude qui annonce \u00ab d\u00e9placez ceci et \u00e9conomisez \u00bb chiffre souvent la puissance de calcul et oublie les donn\u00e9es qui l'entourent et qu'il faudrait d\u00e9placer aussi. Regardez ce qu'une charge de travail utilise r\u00e9ellement avant de supposer qu'elle peut partir.<\/p>\n\n\n\n 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<\/a><\/strong>). Le probl\u00e8me para\u00eet r\u00e9gl\u00e9. On fixe une limite, on paie la limite.<\/p>\n\n\n\n En pratique, c'est l\u00e0 que les sites rencontrent des probl\u00e8mes. Un plafond statique ne sait pas quel jour on est. Fixez-le assez bas pour faire de vraies \u00e9conomies, et t\u00f4t ou tard il bloquera une charge de travail qui avait besoin de capacit\u00e9. D\u00e8s que la R4HA d\u00e9passe la limite, la partition peut \u00eatre plafonn\u00e9e, et le travail est retard\u00e9 (Planet Mainframe<\/a><\/strong>). Cl\u00f4ture de fin de mois, \u00e9v\u00e9nement de march\u00e9, relance apr\u00e8s un incident : les moments o\u00f9 la demande grimpe sont souvent ceux o\u00f9 un retard est le moins acceptable. Le plafond est alors relev\u00e9 \u00ab temporairement \u00bb, personne ne le rabaisse, et l'\u00e9conomie dispara\u00eet en quelques trimestres.<\/p>\n\n\n\n L'autre approche consiste \u00e0 ajuster la capacit\u00e9 en continu selon ce qui se passe r\u00e9ellement, en prot\u00e9geant les charges de travail soumises \u00e0 un SLA (accord de niveau de service) et en retenant les autres.<\/p>\n\n\n\n Il faut savoir o\u00f9 cette approche cesse de s'appliquer. Le capping sert \u00e0 contenir un pic de facturation. En TFP, il n'y a pas de pic \u00e0 contenir, et le capping \u00e0 des fins de co\u00fbt n'a donc pas de cible (l'article AWLC vs TFP<\/a>).<\/p>\n\n\n\n C'est ce que fait Zetaly Automated Capacity<\/a> (ZAC). Il surveille la R4HA en temps r\u00e9el et r\u00e9alloue la capacit\u00e9 avant les pics qui comptent pour la facture. Il freine le travail moins prioritaire, tandis que les services critiques gardent leur marge. ZAC g\u00e8re le pic de facturation, pas la consommation, et cette distinction compte : un site peut consommer plus et payer moins une fois sa R4HA liss\u00e9e. Sur plus de 30 d\u00e9ploiements en entreprise, ZAC r\u00e9duit les MLC de 5 \u00e0 20 % d\u00e8s 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<\/a>). ZAC s'installe sur site et tourne directement sur votre mainframe.<\/p>\n\n\n\n Deux points m\u00e9ritent d'\u00eatre v\u00e9rifi\u00e9s avant votre prochain renouvellement.<\/p>\n\n\n\n Le premier est ce pour quoi vous avez une licence, compar\u00e9 \u00e0 ce que vous faites tourner. Les inventaires de produits d\u00e9rivent au fil des ann\u00e9es. Des sites conservent des produits en sous-capacit\u00e9 que personne n'a ouverts depuis longtemps, et chacun est factur\u00e9 sur le m\u00eame pic de R4HA que tout le reste de la partition. Un inventaire honn\u00eate est un travail ingrat, qui se rembourse souvent de lui-m\u00eame.<\/p>\n\n\n\n Le second est le mod\u00e8le de tarification sur lequel vous \u00eates, car il d\u00e9cide lesquels des leviers ci-dessus vous sont accessibles.<\/p>\n\n\n\n AWLC est le mod\u00e8le fond\u00e9 sur le pic que d\u00e9crit tout ce qui pr\u00e9c\u00e8de. TFP facture \u00e0 l'inverse, sur la consommation totale de l'ann\u00e9e. Les actions utiles ne sont donc pas les m\u00eames. Si un changement est envisag\u00e9, l'article AWLC vs TFP<\/a> pr\u00e9sente les compromis et le bon moment pour changer.<\/p>\n\n\n\n La gestion des pics traite le mois en cours. La planification de capacit\u00e9 traite l'ann\u00e9e.<\/p>\n\n\n\n La plupart des sites planifient leur capacit\u00e9 en appliquant un pourcentage de croissance aux totaux de l'ann\u00e9e pr\u00e9c\u00e9dente. Cette m\u00e9thode convient pour dimensionner le mat\u00e9riel, mais pr\u00e9voit mal le co\u00fbt. Le co\u00fbt suit les pics, et les pics suivent les \u00e9v\u00e9nements m\u00e9tier : un lancement de produit, un cycle saisonnier, une migration, une acquisition. Planifier en fonction de ces \u00e9v\u00e9nements vous dit quand la facture va bouger, assez t\u00f4t pour agir. Zetaly Resource Planning<\/a> (ZRP) est con\u00e7u pour cette vision \u00e0 l'avance.<\/p>\n\n\n\n Rien de tout cela ne peut se juger sans point de r\u00e9f\u00e9rence, et ce point de r\u00e9f\u00e9rence n'est pas \u00ab nos MIPS \u00bb.<\/p>\n\n\n\nMIPS, MSU et ce qu'IBM vous facture vraiment<\/h2>\n\n\n\n
D'o\u00f9 vient vraiment le co\u00fbt<\/h2>\n\n\n\n
Placer le travail, pas le supprimer<\/h2>\n\n\n\n
Le soft capping dynamique<\/h2>\n\n\n\n
Les termes de licence et ce qui est vraiment n\u00e9gociable<\/h2>\n\n\n\n
Planification de capacit\u00e9<\/h2>\n\n\n\n
Ce qu'il faut mesurer avant de changer quoi que ce soit<\/h2>\n\n\n\n