Capping und zpricing Grundlagen

Transkript

1 Capping und zpricing Grundlagen 2014, zit Consulting GmbH 1 1

2 Begriffsdefinitionen R4HA - Rolling 4 Hour Average: Die Verrechnung im xwlc findet statt nach dem höchsten 4-Stunden- Mittel einer Verrechnungsperiode (2.-1.). Vom Prinzip her wird dabei pro LPAR und pro Produkt pro Stunde ein Stundenmittel ermittelt: jede Stunde fällt die älteste Stunde raus und wird die neue Stunde aufgenommen. SCRT: Sub Capacity Reporting Tool: das von IBM zur Verfügung gestellte Tool welches am Ende der Verrechnungsperiode berechnet welche LPAR und welches Produkt jeweils einzeln, aber auch in der Kombination mit wie vielen MSUs genutzt wurden. Seit neuestem auch MWRT: Mobile Workload Reporting Tool, allerdings noch sehr wenig im Einsatz. 2014, zit Consulting GmbH 2 2

3 Begriffsdefinitionen Combined Usage: LPAR A LPAR B LPAR A+B Software die nur auf LPAR A läuft wird gemäß Peak 2 berechnet Software die nur auf LPAR B läuft wird gemäß Peak 1 berechnet Software die auf beiden LPARs läfut wird gemäß der höchsten kombinierten Nutzung bezahlt. 2014, zit Consulting GmbH 3 3

4 Begriffsdefinitionen Capping: Quelle: Mit Capping bezeichnet man die Technik mit der die Höhe des 4-Stunden- Mittels nach oben hin begrenzt wird. Sobald diese Capping-Grenze erreicht wird, wird nur noch so viel Kapazität zur Verfügung gestellt, dass bei der Berechnung der Kosten die eingestellt Grenze nicht überschritten wird. 2014, zit Consulting GmbH 4 4

5 Aufteilung des Workloads in z/os Der Workloadin z/os läuft in Jobs, bzw. Regions, diese sind über einen Parameter jeweils einer Service Class zugeordnet. 2014, zit Consulting GmbH 5 5

6 WLM und Service Classes Diese Service Classes werden einem oder mehreren WLM Importance Levels zugeordnet, dabei ist IMP0 das höchste und Disc or IMP6 das niedrigste level, normalerweise läuft hier workload der absolut nicht zeitkritisch ist. 2014, zit Consulting GmbH 6 6

7 WLM und Service Classes Periodische Überprüfung Es ist wichtig, dass realistische Ziele definiert werden! Für jede Service Class werden Ziele (Response Time, Durchsatz) definiert. WLM probiert, beginnend mit IMP0 als höchste Stufe, die Verteilung der Kapazität so zu regeln, dass diese Goals erreicht werden. Übererfüllung des Ziels: WLM gibt der Klasse weniger Kapazität. Untererfüllung des Ziels: WLM gibt der Klasse mehr Kapazität. Permanente Untererfüllung des Ziels: WLM gibt (vorübergehend) auf. Ein Indikator, ob ein Goal richtig gesetzt ist, ist der Performance Index (PI). 2014, zit Consulting GmbH 7 7

8 Capping-Optionen Kein Capping, vor allem eine Option für Firmen die: Viel zu viel Geld haben In der Vergangenheit schlechte Erfahrungen mit Capping hatten Glauben, dass Capping einer Produktions-LPAR zu gefährlich ist. Starres Capping mit Hilfe von z/os-bordmittel Defined Capacity, auch bekannt als LPAR-Capping: Einzelne LPARs werden in ihr R4HA-Limit begrenzt und wenn das Limit erreicht wird, wird der MSU-Verbrauch auf das Limit eingefroren. GCL Group Capacity Limit, auch bekannt als Group Capping: Eine Gruppe von LPARs werden in ihr R4HA-Limit begrenzt, dabei wird beim Erreichen des Limits die Kapazität gemäß eines vorher festgelegten Verteilschlüssels über die LPARs der Gruppe verteilt. Flexibles Capping mit Hilfe von Spezial-Software Kombination von LPAR- und Group-Capping, unter Berücksichtigung des jeweils aktuellen Workloads. 2014, zit Consulting GmbH 8 8

9 z/os Bordmittel: Defined Capacity und GCL Für beide Optionen gilt: Besser als gar nichts, aber es gibt Nachteile für beide Optionen: Es gibt nur eine starre Obergrenze: Wird diese Grenze zu hoch eingestellt, wird sie eventuell nicht oder nur sehr selten erreicht und wurde eventuell Geld verschenkt. Wird die Grenze zu niedrig eingestellt, kann das dazu führen, dass LPARs über einer längeren Zeit hinweg langsamer arbeiten, weil der R4HA zuerst nach unten korrigiert werden muss. Erfahrungsgemäß ist die Geduld des Managements bei Capping- Probleme oder vermeindliche Capping-Probleme gering: dies führt oft dazu, dass Capping negativ beurteilt und ganz ausgeschaltet wird, weil sehr zeitkritische Anwendungen plötzlich sehr langsam oder die AE zu lange in ihrer Arbeit beschränkt werden. 2014, zit Consulting GmbH 9 9

10 z/os Bordmittel: Defined Capacity Die isolierte Sicht auf einzelne LPARs berücksichtigt nicht die Verrechnung auf Basis der Combined Usage : haben mehrere LPARs den (fast) gleichen Software-Stack, kann es sein dass das Cappen einer einzelnen LPAR keine finanzielle Vorteile bringt: Limitations without Savings. 2014, zit Consulting GmbH

11 z/os Standardmitteln: Defined Capacity Beispiel 1 Am wurde durch das Capping Workload des Importance Levels 4 (WLM4) ausgebremst. Am hatte das Capping faktisch keine Auswirkung auf dem Workload. 2014, zit Consulting GmbH

12 z/os Standardmitteln: Defined Capacity Beispiel 2 CEC LP1A und LP1C LA1A LA1C Dargestellt: Der Verbrauch des CECS, der PROD- LPARs (LP1A und LP1C) und der LPARs LA1A und LA1C. Die Linien zeigen die Situation zwischen11:30 und 12:45 Uhr an. Die PROD-LPARs sind nicht mehr am Maximum, während AE-LPARs LA1A und LA1C weiterhin gecappedwerden. Sollten die AE-LPARs LA1A und LA1C (vorübergehend) mehr Kapazität erhalten, würde dies zu Mehrkosten für PL/1 und COBOL in Höhe von ca. 18 Euro pro MSU führen. Ohne Automation wäre eine so genaue Steuerung nur mit hohem manuellen Aufwand möglich! 2014, zit Consulting GmbH

13 z/os Standardmitteln: Group Capacity Limit Group Capacity Limit: Auch besser als gar nichts, aber es gibt Nachteile: Eine LPAR kann nur zu einer Gruppe gehören: Untergruppen sind nicht vorgesehen. Bei der Definition des Group Capacity Limits wird faktisch vorher festgelegt, wie die Verteilung sein muss, wenn der Capping-Fall eintritt. Gemacht wird dies über Gewichtungsfaktoren (weights). Da aber die Einstellungen starr sind und gemacht werden müssen bevor die Peak- Situation eintritt, entspricht die voreingestellte Verteilung nur sehr selten die aktuelle Situation. In den meisten Fällen werden aus Sicherheitsgründen die Produktions-LPARs über die Massen bevorzugt. Dies führt dann dazu, dass die AE-LPARs stark begrenzt werden, während die Produktions-LPARs unter Umständen noch Workload durchführen der nicht zeitkritisch ist. 2014, zit Consulting GmbH

14 z/os Standardmitteln: Group Capacity Limit Dies ist das normale Bild: GCL wird einmalig (eventuell pro Monat) festgelegt und dann nicht mehr geändert. Der eingestellte Wert wird selten oder gar nicht erreicht. Somit ist GCL eine Budget-Versicherung gegen ausufernden MLC-Kosten. 2014, zit Consulting GmbH

15 Real Time Capacity Management Unter Real Time CapacityManagement versteht man die Technik die es ermöglicht das MSU-Management idealerweise auf nachfolgende Faktoren zu basieren: MSU-Unter-und Obergrenzen anstelle von feste Werte pro LPAR und pro Gruppe Frequente (automatische) Anpassung der MSU-Werte pro LPAR und pro Gruppe (Automatisches) Balancieren der MSU-Kapazität zwischen LPAR-Gruppen (Automatische) Anpassung der MSU-Werte pro LPAR basierend auf Zuordnung von Workload-Prioritäten Minimierung der Nutzung durch die (automatische) Ausnutzung des Effekts der Optimierung der Defined Capacity. 2014, zit Consulting GmbH

16 Real Time Capacity Management Ein einfaches Beispiel Initial Situation 3 LPARs mit jeweils 230, 85 und 18 MSU, insgesamt mit 333 MSU. BC ist dabei der Business Critical Workload mit 220 MSU, TC ist der Time Critical Workload mit 60 MSU und NTC ist der Not Time Critical Workload mit 58 MSU. 2014, zit Consulting GmbH

17 Real Time Capacity Management Ein einfaches Beispiel Meistens ist es so, dass beim ersten Anzeigen dass es mehr Workload gibt und dass das zu einem Problem führen könnte, wird die DefCap hochgesetzt ohne zu berücksichtigen, ob der auf den LPARs durchgeführte Workload zeitkritisch ist. Dies führt sehr schnell zu Extrakosten. Im hier vorliegenden Beispiel: 15 MSU mehr an BC und TC Workload auf PRD1 und 30 auf DEV1 würde zu zusätzlichen 45 MSU auf der MLC-Rechnung führen (378 MSU anstelle von 333 MSU). 2014, zit Consulting GmbH

18 Real Time Capacity Management Ein einfaches Beispiel Ursprüngliche Situation Mit ein aktives RTCM kann dies verhindert werden: die vorher für NTC Workload genutzte Kapazität wird jetzt für BC und TC Workload genutzt indem der NTC Workload temporär ausgebremst wird. Dies ist möglich weil WLM die vorhandene Kapazität probiert im Top-Down-Verfahren optimal ein zu setzen. Bedingung für eine solche Vorgehensweise ist die Kategorisierung des Workloads. 2014, zit Consulting GmbH

19 DefCap Optimization : Sparen ohne Einschränkungen 392 MSU 428 MSU Die Defined Capacitywar auf 320 MSU gesetzt und wurde von 10:30 Uhr an langsam bis 392 MSU angehoben, synchron mit Act MSU und R4HA. Als die Act MSU abnahm, wurde die DefinedCapacity auch gesenkt. Dabei wurde darauf geachtet, dass der DefCap-Wert immer geringfügig höher war als die wirkliche Nutzung. In der MLC-Rechnung wurden 392 MSU (DefCap) verrechnet anstelle von 428 MSU (R4HA). Einsparung: > Euro in dem Monat. 2014, zit Consulting GmbH

20 Cheryl Watsons Newsletter Mehr Informationen über Capping und Capping-Produkte gibt es in der neuesten Ausgabe von Cheryl Watsons Newsletter: Oder direkt bei mir : johannes.peeters@zit-consulting.com Mobil: , zit Consulting GmbH

21 Q & A zit Consulting GmbH Moorstrich Jade Johannes Peeters johannes.peeters@zit-consulting.com Phone: +49 (0) Web: Information: info@zit-consulting.com zpricemanager und zdynacap are registered trademarks of zitconsulting GmbH, patents pending. IBM, z/os, and zseries are registered trademarks of International Buisiness Machines, Inc. 2014, zit Consulting GmbH