von Tibor Kálmán Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen Am Fassberg, Göttingen

Transkript

1 Nagios-Plugins zur Überwachung von zustandsbehafteten Grid-Diensten von Tibor Kálmán Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen Am Fassberg, Göttingen Fon: Fax:

2 Agenda Nagios-Plugins zur Überwachung von stateful Grid Services Überwachung von Grid Diensten mit Nagios Stateful Grid Services Optional: CHEP2010 Konferenz Hochenergiephysik & Computing Konferenz in 18 monatigem Intervall Optional: Taiwan für Dienstreisende Allgemeines, Geschichte, Wetter, Verkehr, Essen

3 Integriertes, einheitliches Monitoring von heterogenen Grid Infrastrukturen

4 Motivation Grid Monitoring Grid-Ressourcenmonitoring für die GWDG und für die GöGrid-Communities Ausgangspunkt: die (Grid-)Basisinfrastruktur wird in jedem Rechenzentrum schon überwacht (Ping, CPU- Auslastung, Netzverkehr, Speicher, Filesystem, usw.) Sich anschließende Frage: Laufen die Grid-Dienste ordnungsgemäß?

5 Motivation - QoS Quality of Service Noch bessere Verfügbarkeit von Grid Diensten Wie wird die Verfügbarkeit definiert? Automatisierte Reaktion auf die unterschiedlichen, typischen Fehler z.b.: container.log: Java Heap Size Fehler Benachrichtigung gleich wenn ein Problem auftritt bzw. gelöst wurde , Webseite (oder bei uns: SMS, Jabber, Ticket)

6 Motivation - Problemisolierung Lokalisieren der Problemursache Möglichst gut eingeschränkte Problemmeldungen Problemen mit der Basisinfrastruktur Z.B. Abgelaufenes Zertifikat bei Job Submission Gut für die Administratoren Realisierbar mittels Abhängigkeit zwischen den Tests Weniger Fehlermeldungen (weniger Rot) Keine unnötigen Tests (weniger Last)

7 Motivation - Statusübersicht Statusübersicht der Ressourcen: Visualisierung des Status Einfaches Management Interface Leichter Zugriff auf Monitoring-Informationen Möglichst integrierbar in die bestehende Lösungen Nagios, HappyFace, usw.

8 Dienstmonitoring im D-Grid Im D-Grid werden 3 unterschiedliche Grid Middlewares unterstüzt (Globus Toolkit v4, UNICORE6, glite) Das Dienstmonitoring ist unterschiedlich und abhängig: von den Communities von den Anbietern Es gab kein integriertes, einheitliches Dienstmonitoring für die 3 Grid Middlewares

9 Dienstmonitoring Resource Admin Grid User Service Überwacht werden sollten: Grid Sicherheitskomponenten Zertifikate Execution Management Job Datenmanagement Datentransfer Monitoring- und Informationsdienste Grid Service A Middleware A Grid Service B Grid Service C Middleware B

10 Architektur - Konzept Überwacht werden sollten: Grid Sicherheitskomponenten Zertifikate Resource Management Monitoring Server Execution Management Job Plugin Management Monitoring Client Datenmanagement Datentransfer VO Management Grid Service A Grid Service B Grid Client Grid Service C Monitoring- und Informationsdienste Middleware A Middleware B

11 Architektur - Implementierung Globus Sicherheits-Komponenten: CA-Zertifikate, MyProxy, Container- Zertifikat Lifetime Resource DB Plugin Management VO Proxy DB Nagios Server Nagios Client Globus Client Execution Management Dienste: Globus Gatekeeper, WS-GRAM Datenmanagement Dienste: GridFTP, SRM, dcache, ReliableFileTransfer Monitoring- und Informationsdienste: MDS4, CIS Globus WS- GRAM Globus RFT Globus MDS4

12 Architektur Komponente: Nagios::Plugin Objektumorientierte Perl-Module für einfache Pluginsentwicklung keine Abhängigkeit von EGEE/WLCG Nagios-Modulen (GridMon) Helper class for returning both output and return codes when testing Nagios::Plugin::ExitResult OO perl module providing standardised argument processing for Nagios plugins Nagios::Plugin::Getopt Class for handling Nagios::Plugin performance data Nagios::Plugin::Performance Class for handling Nagios::Plugin range data Nagios::Plugin::Range Class for handling Nagios::Plugin thresholds Nagios::Plugin::Threshold

13 Entwickelte Komponenten Lokal: gt4fd geöffnete Dateien gt4log kritische Einträge in container.log (weitere: Globus-Prozess, usw) Remote: gt4wsgram WS-GRAM Job Submission Test gt4mds4 MDS4 Index Test gt4rft Datentransfer mit RFT (weitere: GSISSH, Container-Zertifikat, Container-Port, GridFTP, alter GRAM, usw.)

14 Demo (Screenshot) Demo 1 Testen mit Hilfe von Commandline Demo 2 Dienstverfügbarkeit Weboberfläche Demo 3 Nagios Installation für die Deutsche Grid Initiative

15 Demo1 Plugin ohne Nagios Standalone Plugin ohne Nagios-Server Nagios::Plugin::GT4 in MediGRID 1. GT4 Ressourcenliste aus dem VO MDS4 2. Job Submission mit dem check_gt4wsgram.pl Plugin 3. Evaluierung der Ergebnisse

16 Demo1 Plugin ohne Nagios

17 Demo2 Service Availability (gridmon)

18 Demo3 Nagios für die Deutsche Grid Initiative (DGI) D-Grid Nagios zur Grid-Site Überwachung: Die Plugins wurden auf dem Nagios-Server des KIT/SCC (FZK) installiert Meta-Monitoring: Business Prozesse wurden definiert Live-Demo (Screenshots) WS-GRAM MDS4 RFT GridFTP GSISSH

19 Demo3: D-Grid Nagios

20 Demo3: D-Grid Nagios

21 Demo3: D-Grid Nagios

22 Demo3: D-Grid Nagios

23 Erfahrungen und Ausblick Prototyp System überwacht Globus Toolkit v4 Dienste Übersicht zeigt fehlerhafte Dienste Derzeit fast keine automatische Intervention (nur lokal) Mit Hilfe von Nagios::Plugin Modulen ist die Kompatibilität gewährleistet Sicherheit bei aktiven Checks mit sudo Interpretation der Monitoringdaten wird erschwert durch nicht angekündigte Downtimes Zurückführen der Monitoring Informationen in die Informationssysteme der Grid Middleware für die Schedulerentscheidungen Trends erkennen Archivieren von Daten wird von Nagios unterstützt

24 Teil 2: Überwachung von stateful Grid Services

25 Grid Infrastruktur mit Grid Services Grid Middleware Systeme bieten Grid Dienste an Grid Dienste erlauben Zugriff auf Grid Ressourcen (Supercomputer, Massenspeichersystemen, Teleskope, ) Dienste müssen standardisiert angeboten werden: OGSA! Erweiterung des Internets um Hochleistungsrechner und Massenspeichersysteme und statische Sensorgeräte, Rechenleistungen verbessert und Datenkapazitäten erhöht!

26 Grid Dienste normale Grid-Dienste Ähnlich den anderen UNIX Diensten oder Daemons Nagios Sensoren sind schon vorhanden Zustandsbehaftete Grid-Dienste Stateful Web Services Java API oder einfache Clientanwendungen Entwicklung von neuen Sensoren, Plugins oder Tests für eine existierende Monitoringslösung nötig (nächste Folien überspringen) Mehr Details: Grid Programmierpraktikum an der Uni-Göttingen (Tibor Kalman, Thomas Rings): Praktikum: Anwendung und Programmierung im Grid (Tibor Kalman, Thomas Rings):

27 Typischer Web Service Aufruf

28 Typischer Web Service Aufruf 1. Auffinden einen Web Service welcher den Anforderungen entspricht 2. Der Auffindungsdienst gibt uns server zurück welche den benötigten Dienst anbieten 3. Der Web Service muss uns sagen, wie er aufgerufen werden kann. 4. Die Sprache WSDL muss benutzt werden 5. Ein SOAP Anfrage wird geschickt 6. Der Web Service antwortet mit der Information oder mit einer Fehlermeldung wegen falscher SOAP Anfrage

29 Ein zustandsloser Web Service Aufruf

30 Ein zustandsbehafteter Web Service Aufruf

31 Zustände durch Ressourcen Zustand wird nicht im Web Service integriert! Eine separate Entität (Ressource) speichert die Zustands- Information Jedes Ressource hat einen einzigartigen Schlüssel für ihre Identifizierung

32 WS-Resource: Ein Dienst + Ressource Verschiedene Ressourcen Mehrere Werte können behalten werden WS-Addressing Die Adresse von einer WS-Ressource ist die Endpoint Reference (EPR)

33 Efficient Monitoring of Stateful Grid Services Auch zustandsbehaftete Grid-Dienste müsste man effizient überwachen Das Time-Out & Clean-Up Problem: Grid services are stateful services that generate persistent data in the service container. These data enable the storage and retrieval of stateful data even if service consumers may disappear. Thus, clients do not need to remain online throughout the duration of long job executions or file transfers. However, the stateful data should be cleaned up properly. In case of a time-out or failure, the monitoring frameworks for stateless services just break the connection to ensure overloading of the monitoring service and do not take care of stateful service data (Figure 1a). Solution Proper clean-up need to be performed for all monitoring tasks. The monitoring tool ensures that resources and resource properties are always properly deleted. To monitor stateful services efficiently, we have implemented mechanisms to handle the Web Service Resource Framework (WSRF) correctly (Figure 1b). This prevents negative performance consequences resulting from a large number of unused WS-Resources and WS-Resource Properties, caused by monitoring itself.

34 Das Time-Out Problem bei Überwachung

35 Zusätzliche Time-Out zum Aufräumen

36 Erfahrungen und Ausblick Prototyp System überwacht Globus Toolkit v4 Dienste Aufräumen nach einer Time-Out klappt besser

37 Danke!