DIE HERAUSFORDERUNG

Kunden, die Ihre Systeme mit einer „festen“, 7x24*365 Defined- oder Group-Capacity betreiben, stehen oft vor dem Problem, dass unerwartete Last-Situationen die Systeme unter Druck setzen, und dadurch ggf. Folgeprobleme auftreten.

Genau aus diesem Grund sind viele Mainframe Kunden dazu übergegangen, das Erreichen eines Defined- oder Group-Limits über Tag zu vermeiden. Die Limits werden so eingestellt, dass sie nur selten erreicht werden oder nur zu Zeiten, in denen die Auswirkungen kalkulierbar sind. „Starre“ Limits haben oft nichts oder nur wenig mit dem tatsächlichen SCRT/MLC Software Peak zu tun, d.h. Sie als Kunde limitieren sich in Zeiten, in denen die Softwarekosten gar nicht beeinflusst werden. Im Gegensatz dazu lassen Sie MLC Peaks zu, obwohl während des 4 Stunden Fensters ausreichend Workload vorhanden war, den man hätte beeinflussen können.

Fazit: Sie verschenken Geld. Der Mainframe produziert unnötig hohe Kosten.

Mit den Standard (HMC/WLM) Tools der IBM ist eine intelligente, verbrauchsminimierte Steuerung der LPARs nicht möglich. Um Ihre Systeme auf einem möglichst geringen MSU Level betreiben zu können, brauchen Sie flexible Mechanismen, die automatisiert auf Veränderungen reagieren. zGUARD © bietet Ihnen hierfür alle Möglichkeiten und überwacht und steuert Ihre Systeme –anzahlunabhängig– nach Ihren Vorgaben. zGUARD © kann dadurch automatisiert auf Veränderungen reagieren und alarmiert Sie rechtzeitig bevor neue Kosten entstehen. Natürlich übernimmt zGUARD © auch die Steuerung der Systeme, um auf unvorhersehbare Situationen Event-basiert zu reagieren.

EINFÜHRUNG

Mainframe Systeme bieten die Möglichkeiten die zur Verfügung stehenden Rechnerressourcen dynamisch zu verteilen. Dazu stehen auf der Hardware- (PR/SM), sowie auf der z/OS Betriebssystem-Ebene mit dem Workloadmanager (WLM) mehrere Werkzeuge zur Verfügung, welche die Verteilung von Systemressourcen kontrollieren und zugleich die Verarbeitung in Abhängigkeit der Ressourcenverfügbarkeit steuern. Alle Werkzeuge haben diverse Schnittstellen untereinander, um den Ressourcenverbrauch der Systeme zu kontrollieren und -falls notwendig- zu beeinflussen.

In erster Linie dienen diese Steuerungswerkzeuge dazu, die vorhandenen Ressourcen bestmöglich zur zeitgerechten Bewältigung der anfallenden Arbeitslasten zuzuweisen.

Dabei bleibt ein wesentlicher Faktor unberücksichtigt. Wird ein Lizenzmodell angewendet, das verbrauchsabhängig abrechnet, entstehen mitunter Leistungsspitzen, die abrechnungswirksam sind, aber durch einfache Maßnahmen vermeidbar gewesen wären. zGUARD © eröffnet Ihnen die Möglichkeit auf Grundlage permanent ermittelter Verbrauchswerte Regeln (Policies) zu entwickeln, die Systemressourcen auch nach abrechnungsrelevanten Kriterien verteilen.

zGUARD © ist ein „Real-Time“-Programm zur verbrauchsoptimierten (MSU/h) Steuerung Ihrer IBM z/OS Mainframe Systeme. Ob es dabei um die Steuerung/Verteilung von Batch oder um das Verändern von Defined- und Group Capacity Werten geht, spielt keine Rolle. zGUARD © ist in der Lage alle Steuerungen zu übernehmen.

Jede Minute werden die Performance-, Delay- und Verbrauchswerte der LPARs gemessen und auf Trigger / Events basierte Aktionen ausgeführt.

Es reichen bereits einzelne Minuten von Intervallen, um den Verbrauch zu beeinflussen. Ein dauerhaftes Capping ist oft nicht sinnvoll und nicht mehr zeitgemäß.

Grafik

FUNKTIONSWEISE

zGUARD © ist als Produkt in der Nutzung frei programmierbar. Es gibt keine Einschränkungen in den Möglichkeiten zur Steuerung. Alle notwendigen Werte werden Ihnen von zGUARD © minutenaktuell und auswertbar zur Verfügung gestellt.

Werden aufgrund von Schwellwerten Trigger / Events ausgelöst, haben Sie die Möglichkeit vordefinierte Scripte zu starten. Die Scripte können in nahezu jeder beliebigen Programmsprache verfasst werden, ein spezielles Mainframe Know-How ist dafür nicht erforderlich. Innerhalb des Scripts können Sie dann z.B. Werte und Verbräuche miteinander vergleichen, Berechnungen anstellen und dann –automatisiert– HMC Werte verändern, Console Kommandos absetzen oder einen einfachen WTO in das Syslog des betroffenen Systems schreiben. Der Detailgrad an Informationen, die Ihnen zGUARD © dafür zur Verfügung stellt, reicht bis auf Service- / Reportklassenebene. Das heißt, Sie haben sehr detaillierte Informationen, um den Zustand Ihrer Systeme bewerten zu können.

Exemplarische, schematische Darstellung:

Funktionsweise

ANALYSEBEISPIEL

​​

Wenn Sie ausgewertet haben, welche LPAR mit welchem Workload an dem jeweiligen Peak beteiligt war, können Sie Events entwickeln, die solche Situationen beeinflussen.

Analysebeispiel


Die Potentiale zu kennen ist essentiell. Sie benötigen Informationen, welche LPAR Grenzen Sie setzen möchten oder Sie lassen zGUARD © aufgrund von anderen Parametern (z.B. „Delays“) die Entscheidungen treffen.

Analysebeispiel


​Beispiel: Ist ausreichend Batch Workload vorhanden, der nicht zeitkritisch ist, dann ist es möglich die LPAR zu cappen ohne höherwertigen Workload zu beeinflussen. Dieser Workload dient als Puffer in dem Zeitraum in dem Capping einsetzt.

Analysebeispiel


Analysebeispiel


Welchen Workload treffen Sie durch Capping? Wann muss der WLM (© IBM) eingreifen, um den wichtigen, zeitkritischen Workload zu schützen?

Analysebeispiel


Welche Serviceklassen sind in welchem Maß an den Peaks beteiligt? Welcher Workload ist wirklich zeitkritisch? Es geht nicht um „wichtig“!

Analysebeispiel


Wenn Sie ein genaues Bild über die Entstehung der Peaks haben und wissen welche LPAR Sie in welchem Zeitraum Ressourcen verweigern können, dann sind Sie in der Position über eine dynamische, automatisierte Anpassung von Limits zu entscheiden. Mit entsprechenden Regeln werden die Systeme anfangen sich automatisch zu steuern und auf entsprechende Lastverteilungen zu reagieren. Eine gute Praxis ist dabei Minimum und Maximum Werte z.B. für eine Defined-Capacity festzulegen. zGUARD © wird die Werte dann nur innerhalb dieses Bereiches verändern.

Analysebeispiel

ANWENDUNGSBEISPIELE

Je nachdem welchen Effekt der Kunde erzielen möchte, kann er mittels zGUARD © Limits oder System-Einstellungen verändern. Die Anpassungen erfolgen, wenn nötig, jede Minute. Man sieht an folgenden Charts sehr eindrucksvoll, wie sich der 4h Rolling Average (blaue Linie mit weißem Rand) durch die angepasste Defined-Capacity verändert.

Ohne das Eingreifen von zGUARD © wäre der 4h Rolling Average anders und steiler verlaufen, was deutlich höhere Kosten verursacht hätte. Nachdem eine „mögliche“ Peak Situation vorüber ist, haben die Kunden entschieden der LPAR wieder eine (Standard) Defined-Capacity zu geben, die als Maximalwert dient, solange kein neuer MLC Peak bevorsteht.

Wie Sie an den Charts sehen können werden die LPARs nur zu Zeitpunkten begrenzt, in denen es aus Kostengesichtspunkten sinnvoll ist. Obwohl die LPARs teilweise stark beeinflusst werden, sind es über den Monat gesehen, nur wenige Stunden die ausreichen, um die MLC Kosten nachhaltig zu senken.

Anwendungsbeispiel


Anwendungsbeispiel


Anwendungsbeispiel

KONTAKT

zBusiness Services GmbH & Co. KG
Ansprechpartner: Uwe Oswald
Telefon: 06246 9048153
Telefax: 06246 9074220
E-Mail: info@zbss.de
Grüner Weg 1
67575 Eich

KOOPERATIONSPARTNER

Logo ASG Logo InteroConsulting