Mainframeoptimierung

Die meisten Batch-Probleme sind Lastspitzenprobleme: Die versteckten Kosten von Mainframe-Engpässen 

Viele Probleme bei Mainframe-Batchprozessen entstehen durch Lastspitzen und nicht durch mangelnde Kapazität. Erfahren Sie, wie die Verlagerung von COBOL-Workloads auf zIIP GP-Lastspitzen reduziert und die Gesamtperformance verbessert.


5 MIN lesen

Ein bekanntes Szenario: Während Ihrer geschäftskritischsten Verarbeitungsfenster erreichen Ihre General Purpose (GP) Prozessoren ihre Belastungsgrenze und die Latenzen steigen. Dadurch geraten geschäftskritische Service Level Agreements (SLAs) in Gefahr. 

Der naheliegende Gedanke ist, einfach mehr Kapazität bereitzustellen. Wenn der Motor ausgelastet ist, braucht man schließlich einen größeren Motor, oder? 

Die gute Nachricht für die Gesamtbetriebskosten (TCO) Ihres Mainframes: nicht unbedingt. Tatsächlich sind viele Batch-Probleme keine Kapazitätsprobleme, sondern Probleme durch Lastspitzen.

Der Mythos vom Spitzenbedarf: Es ist kein Kapazitätsproblem  

Eine CPU an ihrer Leistungsgrenze ist wie eine Stadt im Berufsverkehr: Zu viele Fahrzeuge müssen gleichzeitig denselben Engpass passieren und aus der Autobahn wird ein Parkplatz. Mit der richtigen Verkehrsführung und einigen zusätzlichen Überholspuren kann der Verkehr jedoch wieder fließen.  

Batch-Lastspitzen sind nicht zwangsläufig ein Zeichen dafür, dass Ihr Mainframe seine Kapazitätsgrenze erreicht hat. Häufig weisen sie vielmehr darauf hin, dass Ihre General Purpose (GP) Engines nicht optimal ausgelastet sind. Zusätzliche GP Kapazität kann Engpässe zwar kurzfristig entschärfen, entspricht jedoch dem Ausbau einer Autobahn, obwohl es einfachere und effizientere Lösungen gibt.  

Den Stau verstehen

Steigt die Auslastung des General Purpose Prozessors stark an, versucht der Mainframe zunächst, die entstehenden Engpässe selbst zu bewältigen. Je näher die CPU an ihre Auslastungsgrenze von einhundert Prozent kommt, desto mehr Rechenleistung wird für die Verwaltung von Warteschlangen aufgewendet, anstatt produktive Workloads auszuführen. Die Folgen sind:

  • Höhere Latenzen, da Prozesse länger auf verfügbare CPU Zyklen warten müssen.
  • Verfehlte SLAs, weil sich Batch Verarbeitungsfenster bis in den nächsten Geschäftstag verlängern.
  • Ein Ressourcenengpass, bei dem kaum noch produktive Arbeit erledigt wird, da die CPU hauptsächlich damit beschäftigt ist, die Ressourcenkonflikte zu verwalten.

Hinzu kommt: GP Prozessoren zählen zu den teuersten Ressourcen in Ihrer Mainframe Umgebung. Sie für routinemäßige COBOL Batch Workloads einzusetzen, ist keine effiziente Nutzung der verfügbaren Kapazitäten, insbesondere wenn mit dem zIIP bereits eine deutlich kostengünstigere und leistungsfähigere Alternative zur Verfügung steht.

Die Überholspur-Strategie: Mit zIIP zu mehr Effizienz 

Wenn die GP Engines den regulären Straßen einer Stadt entsprechen, dann ist der IBM zIIP (System z Integrated Information Processor) die Überholspur. Traditionell waren zIIPs nur für bestimmte Workloads vorgesehen, beispielsweise für Db2 oder XML. 

Heute können jedoch achtzig Prozent oder mehr der Standard COBOL Batch Workloads für die Ausführung auf dem zIIP geeignet gemacht werden. 

Durch die Verlagerung der rechenintensiven COBOL Batch Workloads vom GP auf den zIIP werden Lastspitzen auf dem General Purpose Prozessor geglättet. So bleiben Sie unter Ihren Spitzenlastgrenzen und gewinnen zusätzliche Kapazität aus Ihrer bestehenden Mainframe Infrastruktur zurück. 

Warum dieser Ansatz die beste Grundlage für nachhaltige Skalierung bietet 

Es gibt drei Gründe, warum die Verlagerung von Workloads auf den zIIP der nachhaltigste Weg für Mainframe Umgebungen mit hohen Kapazitätsanforderungen ist: 

  1. Keine Änderungen am Code erforderlich. Ihre Entwicklerinnen und Entwickler müssen jahrzehntelang gewachsene COBOL Anwendungen weder neu schreiben noch aufwendig überarbeiten. Die Verlagerung erfolgt auf funktionaler Ebene. 
  1. Geringere Auslastung des General Purpose Prozessors. Durch die Entlastung der GP Prozessoren bleiben Sie auch dann unter den Grenzwerten des Rolling 4 Hour Average (R4HA), wenn zusätzliche Workloads ausgeführt werden. Bei Nutzung des Tailored Fit Pricing Modells helfen vermiedene Lastspitzen zudem dabei, im nächsten Vertragszeitraum in einer günstigeren Preisstufe zu bleiben. 
  2. Vorhersehbare Batch Verarbeitungszeiten. Werden Ressourcenkonflikte beseitigt, laufen Batch Prozesse planbarer und zuverlässiger. Das Risiko, vereinbarte Service Level Agreements (SLAs) zu verletzen, wird deutlich reduziert.

Ergebnisse 

Durch die Nutzung des zIIP verlagern Sie Workloads nicht nur, Sie führen sie auch effizienter aus. Daten stehen dem Unternehmen schneller zur Verfügung, wodurch nachgelagerte Prozesse von geringeren Latenzen profitieren. Vor allem aber schafft die Entlastung des General Purpose Prozessors zusätzliche Kapazitäten für neue Geschäftsinitiativen, ganz ohne zusätzliche Investitionen in neue Hardware. 

Ressourcen zurückgewinnen: Entlasten Sie Ihren Mainframe von aufwendigen Optimierungsmaßnahmen und sparen Sie über achtzig Prozent der CPU Ressourcen für COBOL Batch Workloads, um Kapazitäten für neue Projekte zu schaffen.

Workload Engpässe beseitigen: Erzielen Sie auch während Spitzenlastzeiten eine hohe Performance.

Budgets planbar machen: Planen Sie Upgrades nach Ihrem eigenen Zeitplan, anstatt auf steigenden Kapazitätsdruck reagieren zu müssen.

Modernisierung ohne Risiko: Modernisieren Sie Ihre Mainframe Umgebung, ohne bestehende Anwendungen, Datenspeicher, Scheduling Frameworks oder Ausgaben zu verändern.

Denken Sie an den Verkehrsfluss, nicht an mehr Motorleistung. 

Das Ziel eines modernen Mainframe Managements ist nicht, über den leistungsstärksten Prozessor zu verfügen, sondern die Workloads möglichst effizient zu steuern. Wenn Sie mit Batch Verarbeitungsfenstern und Lastspitzen auf dem General Purpose Prozessor zu kämpfen haben, sollten Sie nicht vorschnell zusätzliche Kapazität schaffen. Prüfen Sie stattdessen, wie sich Ihre Workloads effizienter optimieren und verteilen lassen. 

Unsere Empfehlung: Analysieren Sie die Spitzenlast auf Ihrem General Purpose Prozessor. Prüfen Sie, welcher Anteil der Ressourcenkonflikte durch routinemäßige COBOL Batch Workloads verursacht wird, und erfahren Sie, wie JOPAZ Ihnen dabei helfen kann, GP Kapazitäten zurückzugewinnen, indem Workloads für die Ausführung auf dem zIIP geeignet gemacht werden.