Auf einen Blick: Der Rolling 4-Hour Average (R4HA) ist entscheidend für die Optimierung der Mainframe-Effizienz und die Senkung der Kosten im Zusammenhang mit IBMs Lizenzmodell. Das Verständnis von R4HA ermöglicht eine strategische Workload-Planung, um monatliche Lizenzgebühren basierend auf der Spitzennutzung zu minimieren.
- R4HA beeinflusst die monatlichen Lizenzgebühren und die Gesamtkosten für Mainframes.
- Die Planung von Arbeitslasten außerhalb der Spitzenzeiten kann den MSU-Verbrauch senken.
Warum ist der Rolling 4-Hour Average (R4HA) wichtig? Warum sollten Sie und ich uns darum kümmern? Entwickler, Tester, Systemadministratoren und andere technische Fachleute sind tatsächlich stark von dieser wichtigen Kennzahl betroffen. Für diejenigen, die mit dem Mainframe-Rolling-4-Stunden-Durchschnitt nicht vertraut sind, hilft dieser Blog, seine Bedeutung zu beschreiben.
Schauen Sie sich Abbildung 1 an. Die blauen Spalten zeigen die Spitzenauslastung pro Stunde, die orangefarbene Linie ist der gleitende 4-Stunden-Durchschnitt der letzten 4 Stunden, und die rote Linie ist die definierte Kapazitäts - oder Soft-Capping-Grenze .
Egal, ob Sie DBA, Systemprogrammierer, Kapazitätsmanager oder Entwickler sind, es ist wichtig zu verstehen, dass unabhängig von der Art der laufenden Arbeitslast, der Art des Codes, den Sie schreiben, den unterstützten Tabellen und den von Ihnen festgelegten Systemparametern all diese Faktoren zum 4-Stunden-Durchschnitt beitragen.
Wie R4HA funktioniert
Hier kommt der entscheidende Teil: Wenn Sie diese Kennzahl für Ihren Kunden senken können, helfen Sie diesem Kunden direkt, Geld zu sparen – vielleicht sogar erhebliche Summen.
IBM verwendet sein Sub-Capacity-Preis-/Lizenzmodell, um seine Kunden auf Basis des Spitzen-Laufdurchschnitts von 4 Stunden pro Monat zu berechnen. Dies wird auch als Monthly License Charge oder MLC bezeichnet. Mehr dazu können Sie hier lesen – Sieben Strategien mit hohem ROI zur Senkung der Mainframe-Kosten
Jedes Subkapazitätsprodukt wird basierend auf dem Spitzen-4-Stunden-Durchschnitt auf der logischen Partition (LPAR), auf der es läuft, berechnet.
Das Verständnis der Mathematik
Im ersten Diagramm ist der Peak R4HA für LPARs A und B (die DB2 ausführen) nicht 140 + 160. Er liegt bei 293,75.
Ähnlich liegt bei den LPARs mit IMS der Peak R4HA nicht bei 170, sondern bei 166,25, und für alle 3 LPARs zusammen liegt es bei 322,5 statt nur der Summe der einzelnen Spitzen der 3 LPARs. DB2 wird also auf Basis von 293,75 MSUs bepreist, CICS mit 322,5 MSUs, IMS mit 166,25 MSUs und z/OS mit 322,5 MSUs. Das ist deutlich teurer, als viele denken.
Alle LPARs scheinen zwischen 1 und 4 Uhr morgens ruhig zu sein, daher ist es aus Entwicklersicht kein großes Problem, wenn man eine schlecht gestaltete SQL-Anwendung in dieser Zeit betreibt, im Vergleich zu einer schlechten SQL-Anwendung, wenn alle drei LPARs am Höhepunkt stehen. In den obigen Diagrammen beginnt das gegen 18 Uhr bis Mitternacht.
Daher ist es wichtig zu verstehen, ob der Code, den Sie schreiben, während der Spitzenverarbeitungsphase oder in der Lean-Phase läuft. Das wird Sie nicht nur dazu bringen, besseren Code zu schreiben, sondern hilft dem Mainframe-Box, nur die MSUs zu verbrauchen, die für die Arbeitslast geeignet sind, und nicht nur ein bisschen mehr.
Ähnlich könntest du, wenn du eine Reihe von Jobs hast, die derzeit während der Spitzenphase laufen und viele MSUs selbst verbrauchen, in Erwägung ziehen, diese Jobs auf eine andere Zeit zu verschieben. Wenn eine solche Jobgruppe um etwa 30 Minuten verschoben wird, kann das den Peak-R4HA erheblich reduzieren. Wenn du die Jobs überhaupt nicht verschieben kannst, ist der aktuelle Spitzenwert R4HA gerechtfertigt.
Die Quintessenz ist folgende: R4HA-sensitiv zu sein, hilft Ihnen immer. Jede MSU, die während der Spitzenzeit gespeichert wird, kann die Kosten für den Betrieb derselben Arbeitslast erheblich senken und so die Gesamtkosten des Großrechners senken.
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.