![\"Zu](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/server-1-1024x560.jpg\")
<\/a><\/figure>\n\n\n\n1. Die CPU Utilization \u00dcberwachung durch das Monitoring Tool<\/h2>\n\n\n\n
Der Klassiker unter den Useranfragen: \u201eWarum ist das System so langsam\u201c? Nur leider gibt es nicht nur \u201eein System\u201c im Unternehmen das langsam sein kann. Mehrere Komponenten wie Netzwerk, Storage und Server k\u00f6nnen die Ursache sein.<\/p>\n\n\n\n
Einfache Steuerung des Tools via Dashboard<\/h3>\n\n\n\n
Navigieren Sie per Mausklick im Dashboard der TRIN[IT]Y Software direkt zur ersten Grafik und sehen Sie auf einen Blick wieviel Cores Ihres Servers verbraucht werden:<\/p>\n\n\n\n Sie wollen wissen welche LPAR welchen Anteil verbraucht? Auch das ist kein Problem: TRIN[IT]Y Monitoring Tool zeigt Ihnen auf einen Blick die Details zum ausgew\u00e4hlten Prozessor Pool. In der folgenden Darstellung ist gut zu erkennen, dass LPAR2 und LPAR3 den Gro\u00dfteil der CPU Kapazit\u00e4t verbrauchen.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Eine Frage bleibt allerdings offen \u2013 ist nun die CPU der einzelnen LPAR auch wirklich zu 100% ausgelastet und daher auf Anschlag? Dazu kurz auf die Detaildaten der LPAR gewechselt und man sieht die gew\u00fcnschten Informationen:<\/p>\n\n\n\n Die LPAR ist auf 3 Processing Units fixiert. Somit besteht hier kein Handlungsbedarf.<\/p>\n\n\n\n Anders sieht es bei der folgenden Maschine aus: hier reicht die CPU nicht mehr aus, um die Erfordernisse zu erf\u00fcllen:<\/p>\n\n\n\n Aber auch viele andere Daten werden historisch aufgezeichnet und helfen somit einen \u00dcberblick \u00fcber die Umgebung zu erhalten. Meist geht der Performance Verlust schleichend vor sich und der erste Zeitpunkt der Verschlechterung ist nicht bekannt. Durch das Monitoring Tool k\u00f6nnen historische Daten dabei helfen, m\u00f6gliche Zeitpunkte und Ursachen ausfindig zu machen. Das schafft unsere Monitoring Software durch die InfluxDB. Damit unterst\u00fctzt sie Sie nicht nur im Bereich der \u00dcberwachung, sondern auch beim Darstellen und Erkl\u00e4ren des Problems beim Management Ihres Unternehmens.<\/p>\n\n\n\n Bei Enterprise Systemen kommt es \u00f6fters vor, dass CPU und Memory \u00fcber mehrere Systemeinheiten verteilt liegen. Dabei ist es f\u00fcr einen guten Affinity Score enorm wichtig, dass CPU und Memory einer einzelnen LPAR m\u00f6glichst im gleichen Drawer\/CEC liegen. Ist das nicht der Fall, f\u00e4llt der Affinity Score. Ein manuell ausgef\u00fchrtes Re-Arrangement von Performance zu Memory kann hier schon zu einer drastischen Performance Verbesserung und zu einer Verbesserung des Scores f\u00fchren. Aber ist der Affinity Score meiner Systeme schlecht? Auch das finden Sie sehr einfach mit dem TRIN[IT]Y Monitoring Tool heraus:<\/p>\n\n\n\n Ein Problem, das Sie bestimmt auch kennen: Sie wissen, dass das System langsam ist, weil die CPU im wait-Status ist und ben\u00f6tigen jetzt die Information, worauf es wartet. Wenn ein Threat im Wait-Status ist, kann es mehrere Gr\u00fcnde daf\u00fcr geben: Lesen Sie mehr dazu auf der IBM Website<\/a><\/p>\n\n\n\n Das TRIN[IT]Y Performance Monitoring Tool hilft hier schnell und ohne viel Vorwissen zu erkennen, woher die Waits kommen, ob die Applikation gut l\u00e4uft, oder wo es Ansatzpunkte gibt die Performance zu verbessern. Auch Applikations\u00e4nderungen k\u00f6nnen schnell auf ihre Effektivit\u00e4t \u00fcberpr\u00fcft werden. In der folgenden Grafik ist hingegen sofort erkennbar, dass die Threads kaum warten m\u00fcssen \u2013 ein Beispiel einer gut laufenden Software:<\/p>\n\n\n\n Mit der TRIN[IT]Y Software k\u00f6nnen Sie sich die Auslastung einzelner SAN Ports anzeigen lassen. In diesem Beispiel ist erkennbar, dass der Port durchg\u00e4ngig \u00fcber einen langen Zeitraum immer mit 800MB\/s schreibt. Mit dem Wissen, dass es sich hier um ein 8Gb Port handelt, wird schnell klar, dass die Auslastung am oberen Ende der Skala ist und dringend reagiert werden sollte. So geht professionelles Management mithilfe der richtigen Tools!<\/p>\n\n\n\n Apropos \u201eMit dem Wissen, dass es sich hier um ein 8Gb Port handelt\u2026\u201c: Das TRIN[IT]Y Monitoring Tool zeigt Ihnen auch grafisch Ihre komplette Netzwerkkonfiguration der SAN Topologie mithilfe des Network Views an: vom Server, den virtuellen Fibre Channel Verbindungen des jeweiligen Client Systems, vom VIO Server sowie zus\u00e4tzlich den physischen Kabelverbindungen vom VIO Server bis zum Fibre Channel Switch und deren Verbindungen zu Tape Laufwerken und Storage Systemen. Auch hier haben Sie die M\u00f6glichkeit mit der Maus einfach Details anzeigen zu lassen um Ihre \u00dcberwachung so effizient wie m\u00f6glich zu halten.<\/p>\n\n\n\n Diese View hilft Ihnen ebenfalls wenn Sie eine Konfiguration \u00fcberpr\u00fcfen m\u00fcssen, da sie in Echtzeit direkt aus den Systemen Ihres Unternehmens abgeleitet wird.<\/p>\n\n\n\n Ein h\u00e4ufig auftretender Fall ist der \u201eSlow drain Bottleneck\u201c. In Zeiten der klassischen HDD war der Datenstau oft sehr schnell verifizierbar. Mit der Entwicklung der Hybrid und All-Flash Storage Systeme, sowie der immer gr\u00f6\u00dferen Komplexit\u00e4t der SAN\u2019s, hat sich diese M\u00f6glichkeit jedoch verlagert und ist nicht mehr so einfach zu erkennen. Um das Problem zu verstehen, muss man die Ursache kennen: Mit dem TRIN[IT]Y Monitoring Tool k\u00f6nnen Sie das jedoch mit Grafiken sch\u00f6n erkennen. In dieser TRIN[IT]Y Grafik sehen Sie eine klassische IO Performance einer bestimmten SAN Komponente, die genau anzeigt, dass diese eine hohe Anzahl verz\u00f6gerter Pakete hat. Mit der Erweiterung der Buffers am ISL und einiger Rekonfigurationen konnte die Performance im SAN wieder erh\u00f6ht werden:<\/p>\n\n\n\n Jeder Systemadministrator hat wohl auch schon die Erfahrung gemacht, dass sich ein System pl\u00f6tzlich wegen zu hohen Temperaturanstieges herunterf\u00e4hrt. Das ist auf der einen Seite, der immer st\u00e4rker werdenden Hardware zu schulden, als auch durch immer h\u00f6herer Packungsdichte der Racks. Auch hier hat jeder Hersteller und jeder Server, Switch und Storage sein eigenes Warnsystem, das auf die standardhinterlegte Spezifizationswerte individuell warnt. Auch hier hilft Ihnen das TRIN[IT]Y Monitoring Tool durch eine gesamtheitliche Darstellung \u00fcber Ihre komplette IT-Landschaft.<\/p>\n\n\n\n Die unbeliebteste Arbeit von IT-Administratoren ist wohl mit Sicherheit die Dokumentation. Nach \u00c4nderungen ist diese vor allem wichtig, um zu einem sp\u00e4teren Zeitpunkt \u00c4nderungen und eventuelle Differenzen verifizieren zu k\u00f6nnen. Eine der \u00fcblichen T\u00e4tigkeiten, die gerne verschoben wird, weil es immer h\u00f6her priore Arbeiten im Unternehmen gibt. Und dann passiert es: Das System muss wieder hergestellt werden und es fehlt der Letztstand der Konfiguration sowie Detailinformationen zur Wiederherstellung. Auch da hilft Ihnen das TRIN[IT]Y Monitoring Tool durch seine automatische Dokumentationsm\u00f6glichkeit:<\/p>\n\n\n\n Die Dokumentation k\u00f6nnen Sie je nach Ihren gew\u00fcnschten Intervallen automatisch abgezogen und im Excel Formaten abgespeichert werden. Damit verlieren Sie, dank dem TRIN[IT]Y Monitoring Tool, nie wieder aktuelle Informationen. Konzentrieren Sie sich auf aktuelle Themen des Alltags und verlassen Sie sich darauf alle notwendigen Daten zur Verf\u00fcgung zu haben, wenn Sie sie im Notfall f\u00fcr Rekonstruktionen ben\u00f6tigen.<\/p>\n\n\n\n Mit den bereits erw\u00e4hnten Funktionen haben Sie alle Werkzeuge, Berichte und Belege in der Hand, um das Management Ihres Unternehmens davon zu \u00fcberzeugen, dass es an der Zeit f\u00fcr IT Investitionen ist. Allerdings haben Sie mit diesem Performance Monitoring auch die M\u00f6glichkeit Ihrem Management zu belegen, dass die neue Anschaffung auch sinnvoll war; beispielsweise mit einer Auslastungsgrafik. In diesem Fall ist klar ersichtlich, dass die Migration ein eindeutiger Erfolg war; Ihre \u00dcberwachung hat das bewiesen.<\/p>\n\n\n\n![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/blog2-2.jpg\")
<\/a><\/figure>\n\n\n\nInnerhalb eines Monitoring Tools zu den Details wechseln<\/h3>\n\n\n\n
![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/blog-2-3.jpg\")
<\/a><\/figure>\n\n\n\nEin Monitoring Tool f\u00fcr alle Ansichten und Details<\/h3>\n\n\n\n
![\"Die](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/blog-2-4.jpg\")
<\/a><\/figure>\n\n\n\n![\"Die](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/blog-2-5.jpg\")
<\/a><\/figure>\n\n\n\nEin Monitoring Tool mit schnellem Zugriff auf historische Daten<\/h3>\n\n\n\n
2. Affinity Score \u00dcberwachung durch flexibles Monitoring<\/h2>\n\n\n\n
![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-affinity-score.jpg\")
<\/a><\/figure>\n\n\n\n3. Einlesen von Wait-time-accounting Daten innerhalb eines zentralen Monitoring Tools<\/h2>\n\n\n\n
Die IBM i hat hierzu das patentierte \u201eWait time accounting\u201c. Dieses zeigt an, ob Threads auf der IBM i \u00fcberhaupt warten m\u00fcssen, und gegebenenfalls worauf sie warten. Somit ist es m\u00f6glich Bottlenecks auf der IBM i oder externen Ressourcen eines Netzwerks ausfindig zu machen und die Applikation\/LPAR\/Storage so anzupassen, dass diese Bottlenecks nicht mehr bestehen.<\/p>\n\n\n\n
\u2981 Ready to run \/ CPU queuing:
Dies ist ein spezieller Wartezustand und wird allgemein als \u201eCPU Queuing\u201c bezeichnet. Dies bedeutet, dass der Thread oder die Task in die Warteschlange gestellt wird und darauf wartet, auf der CPU ausgef\u00fchrt zu werden. Es gibt verschiedene Gr\u00fcnde, warum CPU-Warteschlangen auftreten k\u00f6nnen. Ein Beispiel k\u00f6nnte sein, wenn die Partition \u00fcberlastet ist und es mehr Arbeit gibt, als die Partition aufnehmen kann. Dann kann die Arbeit in die Warteschlange gestellt werden, um auf die CPU zu warten. Dies kann mit einer Autobahn mit Rampenz\u00e4hlern verglichen werden; wenn die Autobahn \u00fcberlastet ist, haben die Rampenz\u00e4hler ein rotes Signal, sodass die Autos anhalten und warten m\u00fcssen, bevor sie in den Verkehr einfahren k\u00f6nnen. Logische Partitionierung und gleichzeitiges Multithreading k\u00f6nnen auch zu CPU-Warteschlangen f\u00fchren.
\u2981 Idle wait:
Leerlaufwartezeiten sind eine normale und erwartete Bedingung. Leerlaufwartezeiten treten auf, wenn der Thread auf externe Eingaben wartet. Diese Eingabe kann von einem Benutzer, dem Netzwerk oder einer anderen Anwendung kommen. Bis diese Eingabe empfangen wird, gibt es keine Arbeit zu tun.
\u2981 Blocked wait:
Blockierte Wartezeiten sind das Ergebnis von Serialisierungsmechanismen, um den Zugriff auf gemeinsam genutzte Ressourcen zu synchronisieren. Blockierte Wartezeiten k\u00f6nnen normal und zu erwarten sein. Beispiele hierf\u00fcr sind der serialisierte Zugriff zum Aktualisieren einer Zeile in einer Tabelle, Platten-I\/O-Operationen oder Kommunikations-I\/O-Operationen. Blockierte Wartezeiten sind jedoch m\u00f6glicherweise nicht normal, und es sind diese unerwarteten Blockierungspunkte, die Situationen darstellen, in denen die Wartezurechnung verwendet werden kann, um die Wartebedingungen zu analysieren.<\/p>\n\n\n\n![\"Die](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-wait-accounting-stati.jpg\")
<\/a><\/figure>\n\n\n\n
Im unteren Beispiel sieht man beispielsweise auf einen Blick, dass die CPU gr\u00f6\u00dftenteils durch Journal Locks ausgebremst wird:<\/p>\n\n\n\n![\"In](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-wait-accounting-journal-wait-details.jpg\")
<\/a><\/figure>\n\n\n\n![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-wait-accounting-positives-beispiel.jpg\")
<\/a><\/figure>\n\n\n\n4. SAN Port Auslastung im ganzheitlichen TRIN[IT]Y Monitoring Tool<\/h2>\n\n\n\n
![\"Es](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-san-port.jpg\")
<\/a><\/figure>\n\n\n\n5. TRIN[IT]Y Monitoring Tool inklusive grafischer Nachverfolgung<\/h2>\n\n\n\n
![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-network-view.jpg\")
<\/a><\/figure>\n\n\n\n6. Buffer credit zero Problem und dessen Monitoring<\/h2>\n\n\n\n
Das Problem mit herk\u00f6mmlichen Monitoring Tools<\/h3>\n\n\n\n
Datenpakete werden von einem Sender (zB Server) \u00fcber fibre channel (FC) Switches an einen Empf\u00e4nger (zB Storage) gesendet. Dieser Datenverkehr zwischen zwei Komponenten wird \u00fcber Puffer gesteuert. F\u00fcr jeden Datenpaketblock den der FC Switch erh\u00e4lt (siehe Bild) reduziert sich die verf\u00fcgbare Pufferkapazit\u00e4t, bzw. erh\u00f6ht sich wieder f\u00fcr jedes Datenpaket das fertig verarbeitet und weitergesendet wurde. Die Kommunikation zum \u201eVorg\u00e4nger\u201c bzw. \u201eNachfolger\u201c erfolgt via R_RDY (receive-ready) messages. Erst wenn der Sender die Information hat, dass ein Paket verarbeitet wurde und wieder Pufferkapazit\u00e4t zur Verf\u00fcgung steht, kann das n\u00e4chste Paket versendet werden. Ist diese Kapazit\u00e4t jedoch ausgesch\u00f6pft entsteht ein \u201eBuffer Credit Zero\u201c und somit ein Backlog bei der Vorg\u00e4ngerkomponente. Jetzt gilt es herauszufinden wo genau das Problem liegt. Mit vielen Performance Monitoren k\u00f6nnen sie auslesen, dass der Server den Backlog hat und der Storage auf Input wartet. Aber ob nun der FC Switch 1 oder 2 das Problem ist, erkennen Sie daraus nicht.<\/p>\n\n\n\n![\"Die](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-buffer-credit-zero-erklaerung.jpg\")
<\/a><\/figure>\n\n\n\nDie L\u00f6sung: TRIN[IT]Y Monitoring Tool<\/h3>\n\n\n\n
![\"Die](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-buffer-credit-zero-IO-performance.jpg\")
<\/a><\/figure>\n\n\n\n7. Temperaturkontrolle durch zuverl\u00e4ssiges Monitoring<\/h2>\n\n\n\n
![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-temperaturkontrolle.jpg\")
<\/a><\/figure>\n\n\n\n8. Automatische Dokumentation der Konfiguration durch ein verl\u00e4ssliches Monitoring Tool<\/h2>\n\n\n\n
![\"Das](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-automatische-dokumentation.jpg\")
<\/a><\/figure>\n\n\n\n\u00dcberlassen Sie unserem Monitoring Tool die Dokumentation<\/h3>\n\n\n\n
9. Migrationsplanung und -erfolgsbeweis mithilfe eines konstanten Monitorings<\/h2>\n\n\n\n
![\":](\"https:\/\/trinity.it-ps.at\/wp-content\/uploads\/2021\/10\/trinity-monitoring-tool-migrationsauslastung.jpg\")
<\/a><\/figure>\n\n\n\n10. Individualanpassungen in einem flexiblen und gleichzeitig best\u00e4ndigen Monitoring Tools<\/h2>\n\n\n\n