Resource Monitoring Oliver Röttger Matrikelnummer: 6100325 E-Mail

Universität Paderborn
Seminararbeit: Resource Monitoring
Oliver Röttger
Matrikelnummer: 6100325
E-Mail: [email protected]
Projektgruppe Peer-2-Peer basierte Suche nach Web-Services
Betreuer: Prof. Dr. Odej Kao, Felix Heine, Matthias Hovestadt, Dr. Achim
Streit
21. Dezember 2004
Inhaltsverzeichnis
1 Einführung und Überblick
1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2 Grid Monitoring Architecture
2.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Komponenten und Interfaces . . . . . . . . . . . . . . .
2
3
4
3 R-GMA
3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
7
4 GridRM
9
4.1 Local Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 Datentreiber . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Ganglia
5.1 Architektur . . . . . . . .
5.2 Implementierung . . . . .
5.2.1 gmond . . . . . . .
5.2.2 gmetad . . . . . . .
5.2.3 RRDtool . . . . . .
5.3 Performancebetrachtungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
14
14
16
16
16
6 Network Weather Service
16
6.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Forecasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Resümee
19
1
1
Einführung und Überblick
In einem Grid werden durch verteilte Hard- und Software große Rechenressourcen zur Verfügung gestellt. Um ein Grid vernünftig nutzen zu können,
werden weitreichende Informationen über den Zustand des Grids benötigt,
damit z.B. Jobs sinnvoll auf Ressourcen verteilt werden können oder auch
Fehler im Grid schnell gefunden (und damit auch schnell beseitigt) werden.
Ressourcen, die in einem Grid überwacht werden können, umfassen computerinhärente Komponenten wie Prozessoren und Haupt- und Plattenspeicher, Netzwerkkomponenten wie z.B. Switches und Router, eingebettete Systeme, aber auch Applikationen selber, die im Grid laufen.
1.1
Anforderungen
Bei der Entwicklung einer Ressourcenüberwachung müssen einige Bedingungen sorgfältig analysiert werden. So ist zum einen die Heterogenität eines
Grids problematisch, da viele verschiedene Komponenten verschiedenste Arten Statusinformationen über das Grid liefern. Die Gültigkeit der Daten ist
häufig auch sehr kurz (Bsp. Prozessorauslastung). Daraus folgt auch, dass
die Update-Frequenz der Informationen sehr hoch sein kann. Ein weiteres
Problem ist, dass einzelne Daten oft nicht ausreichen, um eine Ressource
umfassend zu charakterisieren, da diese ggf. ein stochastisches System ist [1].
Die Anforderungen, die sich aus diesen Randbedingungen an ein Resource
Monitoring System ergeben sind daher u.a. die Normalisierung verschiedener
Daten, geringe Latenzzeiten, hohe Datenraten, die gemessenen Komponenten
dürfen nur minimal beeinträchtigt werden, d.h. der Überwachungsprozess
stellt nur einen geringen Overhead für die Ressource dar. Des Weiteren muss
das System skalierbar sein, d.h. auch in sehr großen Grids noch vernünftig arbeiten und es muss sicher sein, d.h. es muss möglich sein, Daten mit
Zugriffsrechten zu versehen und die Integrität der Daten sicherzustellen.
In dieser Arbeit werden nun einige Monitoring-Systeme vorgestellt und
dabei verschiedene Aspekte der Ressourcenüberwachung beleuchtet.
2
Grid Monitoring Architecture
Die Grid Monitoring Architecture (GMA) ist eine vom Global Grid Forum
vorgeschlagene (abstrakte) Architektur für das Monitoring verteilter Ressourcen [1].
Aus der Anforderung der Skalierbarkeit folgt, dass nicht jede Anfrage nach
Monitoringdaten über einen zentralen Server laufen darf. Die GMA schlägt
2
daher einen verteilen Directory Service vor, der Metadaten von Producer bzw.
Consumer von Monitoringdaten speichert (s. Abb.1). In den Metadaten sind
neben den Informationen über die angebotenen Monitoringdaten, Informationen enthalten, die es ermöglichen bei einer (Monitoring-)Datenanfrage eine
direkte Verbindung zwischen Consumer und Producer herzustellen.
Abbildung 1: Grobübersicht über GMA
In den folgenden Abschnitten werden die Systemarchitektur und die einzelnen Komponenten der GMA genauer beleuchtet.
2.1
Systemarchitektur
Die Möglichkeiten, mit der Consumer und Producer kommunizieren können,
sind:
Publish/Subscribe: Entweder der Consumer oder der Producer können
eine Verbindung herstellen, bei der der Initiator der Verbindung dem
Server (Wenn der Producer Initiator ist, ist der Consumer Server und
umgekehrt) Interesse“ an bestimmten Daten (mit Information über
”
die Kodierung, Updatefrequenz und weiteren Protokolldetails) mitteilt.
Nach erfolgreicher Verbindungsaufnahme befinden sich beide Kommunikationspartner in dem Zustand Subscription, in dem der Producer die
vereinbarten Daten an den Consumer sendet. Beide Partner können die
Verbindung wieder beenden.
3
Query/Response: Hierbei kann nur der Consumer eine Verbindung anstoßen und bestimmte Daten anfragen; daraufhin sendet der Producer
alle seine Daten in einem Response zurück und danach wird die Verbindung wieder beendet.
Notification: Hierbei sendet der Producer initiativ Daten an den Consumer.
2.1.1
Komponenten und Interfaces
Um Monitoringinformationen im Grid zu finden, wird eine Stelle für die
Verwaltung und Beschreibung zum Wiederauffinden dieser Informationen
benötigt, dies wird in GMA durch einen verteilen Directory Service realisiert.
Der Directory Service speichert Metadaten von Consumer und Producer,
die Verbindungen akzeptieren. Diese umfassen die Informationen über die
akzeptierten Events, Protokolle, Sicherheitsmechanismen etc.1
Mit Hilfe der folgenden Methoden realisiert der Directory Service diese
Funktionalität:
Methode
Add
Update
Remove
Search
1
Funktionalität
Fügt einen Eintrag dem Verzeichnis hinzu
Aktualisiert einen Eintrag
Entfernt einen Eintrag
Sucht nach Informationen aufgrund definierter Auswahlregeln. Es kann sowohl ein einzelnes, auf die Suche zutreffendes Ergebnis, als auch eine Menge von passenden Ergebnissen
zurückgegeben werden. Dies hat der Client bei der Anfrage
mitzuteilen.
Diese Daten werden auch registration genannt.
4
Der Producer ist das Interface, das die Daten zur Verfügung stellt und
diese als Event an Consumer senden kann. Eine Komponente wird auch als
ein Producer bezeichnet, wenn diese mindestens ein Producer-Interface zur
Verfügung stellt.
Die von dem Producer zur Verfügung gestellt Methoden umfassen:
Methode
Funktionalität
Add/Update/Remove Hinzufügen/Aktualisieren und Entfernen von Metadaten der Events, die der
Producer zur Verfügung stellt.
Accept Query
Bearbeitet einen Request von einem
Consumer, d.h. Daten werden als
Event an diesen zurückgesendet.
Accept Subscribe
Akzeptiert ein Subscribe vom Consumer. Der Consumer erhält nun Events
vom Producer, bis ein Unsubscribe
stattfindet.
Accept Unsubscri- Der Consumer bekommt keine weiteren Events zugesandt.
be
Locate Consumer
Durchsucht den Directory Service
nach einem Consumer.
Notify
Versendet ein einzelnes Event an den
Consumer.
Initiate Subscribe
Meldet beim Consumer an, dass dieser
Events zugesandt bekommt (bis zum
Unsubscribe).
Initiate Unsubscri- Beendet eine Subscription eines Conbe
sumers.
5
Korrespondenz
Add/Update/Remove
vom Directory Service
Initiate Query vom
Consumer
Initiate Subscribe
vom Consumer
Initiate Unsubscribe vom Consumer
Search vom Directory Service
Accept Notification
vom Consumer
Accept Subscribe
vom Consumer
Accept Unsubscribe
vom Consumer
Der Consumer empfängt über das Consumer-Interface Monitoringdaten
vom Producer. Wie der Producer wird auch eine Komponente mit einem oder
mehreren Consumer-Interfaces als Consumer bezeichnet.
Methode
Locate Producer
Funktionalität
Sucht im Directory Service nach einem
Producer.
Initiate Query
Fragt beim Producer nach einem
Event, der als Antwort der Anfrage
zurückkommt.
Initiate Subscribe
Führt einen Subscribe beim Producer durch, danach werden regelmäßig
Events an den Consumer versandt.
Initiate Unsubscri- Beendet eine Subscription beim Probe
ducer.
Maintain Registra- Führt ein Update der Registrierung
tion
beim Directory Service durch. Dies betrifft die Events, die der Consumer
empfangen kann.
Accept Notification Akzeptiert einen Subscribe vom Producer, der danach regelmäßig, bis die
Verbindung beendet wird, Events an
den Consumer sendet.
Accept Unsubscri- Führt einen Unsubscribe vom Prodube
cer durch. Danach werden keine weiteren Events an den Consumer gesendet.
Locate Event Sche- Sucht nach einem Event Schema im
ma
Schema Repository.
Korrespondenz
Search vom Directory Service
Accept Query vom
Producer
Accept Subscribe
vom Producer
Accept Unsubscribe
vom Producer
Add, Update und
Remove vom Directory Service
Initiate Subscribe
vom Producer
Initiate Unsubscribe vom Producer
Die GMA sieht vor, dass so genannte Intermediaries eingesetzt werden, die
sowohl Consumer als auch Producer sind. Diese Struktur könnte z.B. für
Archive interessant sein, die sowohl Daten sammeln als auch wieder zur
Verfügung stellen. Abb. 2 veranschaulicht dies.
3
R-GMA
R-GMA [2] ist eine Implementierung der GMA [1], wobei die Besonderheit
dieses Systems ist, dass es sich nach außen wie eine große relationale Datenbank verhält (R-GMA). Tatsächlich ist R-GMA keine Datenbank, sondern
verhält sich nur so. Eine weitere Eigenschaft ist, dass die Registry (Directory
Service) der (R-)GMA völlig transparent verwaltet wird.
6
Abbildung 2: Intermediaries in der GMA
3.1
Architektur
Die Ressourceninformationen werden von R-GMA in einer großen virtuellen
Datenbank mit mehreren Tabellen (pro Virtueller Organisation2 ) verwaltet.
Producer können mit dem SQL-Kommando CREATE TABLE Tabellen erstellen und mit INSERT Daten darin ablegen. Dabei haben alle Tupel einen
Timestamp (in UTC), der gleichzeitig Primary Key der SQL-Datenbank ist.
Consumer können eine SQL-Anfrage an einzelne Tabellen stellen, dabei wird
von der Registry (die für den Benutzer völlig transparent ist) der der Anfrage
am besten entsprechende Producer gewählt. Dieser Prozess wird Mediation
genannt. Abb. 3 zeigt den Aufbau der virtuellen Datenbank.
Die Datenbank ist also virtuell, da die Datenbank nicht zentral gehalten
wird, sondern die Daten von verschiedenen Producern zur Verfügung gestellt
werden. Hat die Registry einen Producer gefunden, kontaktiert der Consumer
dann den Producer auf direktem Weg, so wie es die GMA vorsieht. Die Daten
werden dann von dem Producer als Tupel zurückgegeben.
Es gibt drei verschiedene Klassen von Producern. Die Primary Producer speichern regelmäßig direkt von den Datenquellen Werte. Datenanfragen
werden direkt aus dem internen Speicher beantwortet. Die Secondary Producer aggregieren Werte aus anderen Tabellen und beantworten Anfragen
2
Eine Virtuelle Organisation ist ein Netzwerk von Organisationen oder Individuen mit
einem gemeinsamen Interesse
7
Abbildung 3: Die virtuelle Datenbank von R-GMA [2]
dann auch aus ihrem eigenen Speicher. Die On-Demand Producer beantworten Anfragen nicht aus ihrem internen Speicher, sondern nehmen bei Bedarf
die Werte direkt von den Datenquellen.
Von Producern generierte Tupel haben zusätzlich eine LatestRetentionPeriod. Diese Zeit gibt an, wie lange ein Tupel aktuell“ ist und wird auch bei
”
Übernahme von Tupeln durch den Secondary Producer vom Primary Producer mit übernommen. Zusätzlich wird in der Registry von den Producern
eine HistoryRetentionPeriod deklariert, die angibt wie lang die ältesten Tupel
von den Producern gespeichert werden. Daher haben Producer zwei logische
Tupel-Speicher, einen für Anfragen nach Tupeln, die die LatestRetentionPeriod noch nicht überschritten haben und einen für Tupel, die die HistoryRetentionPeriod noch nicht überschritten haben. Daher liefert eine Anfrage
nach den neusten Tupeln diejenigen aus dem ersten logischen Tupel-Speicher
und eine History-Anfrage alle vorhandenen Tupel.
Zusätzlich gibt es noch eine continuous-Anfrage, bei der alle neuen Tupel,
die der Anfrage entsprechen dem Consumer übermittelt zu werden, bis der
Consumer ein Stopp sendet. Dieser Anfragetyp wird jedoch nicht von OnDemand Producern unterstützt.
R-GMA ist als Web-Service nach der Web Services Architecture des W3C
implementiert, nach der jeder Service seine Operationen in einem WSDLDokument veröffentlicht. In R-GMA wird die Kommunikation zwischen Consumer und Producer über SOAP durchgeführt (Abb. 4).
Da R-GMA aber ein API für das Ansprechen von R-GMA-Services zur
Verfügung stellt, bleibt die SOAP-Kommunikation vom Benutzer vollständig
verborgen. APIs sind für R-GMA z.Z. für Java, C++, C und Python verfügbar.
Es besteht aber dennoch auch die Möglichkeit, das API zu umgehen, um so
direkt mit dem Web-Service zu kommunizieren.
Eine Instanz eines Producers wird erst angelegt, wenn von einem Benutzer
8
Abbildung 4: R-GMA Kommunikation
ein create kommt (bei Benutzung des API geschieht dies automatisch) und
der Benutzer bekommt den Identifier dieser Instanz als Antwort zurück (bzw.
das API). Bei weiteren Anfragen wird dann dieser Identifier mit übermittelt
(von dem API). Wenn eine Zeit lang keine Anfragen an diesen Identifier mehr
gestellt werden, wird diese Instanz des Producers zerstört. Damit wird verhindert, dass ein System mit gleichen Producern überladen wird. Dies wird als
Soft-State Registration bezeichnet, da der Benutzer regelmäßig den Producer
kontaktieren muss, um ihn am Leben“ zu halten. Die Registry verhält sich
”
ebenso. Registrierte Consumer und Producer müssen sich regelmäßig über
Keep-Alive Nachrichten zurückmelden.
4
GridRM
Das GridRM [3] ist ein generisches Monitoring-System, dass auch auf der
GMA [1] basiert. Das Hauptaugenmerk wird dabei auf das Monitoring von
Ressourcen (nicht Anwendungen) gelegt. Alle Knoten im GridRM besitzen
einen GridRM Gateway, der in zwei Layer, nämlich das Global und Local
Layer unterteilt ist.
Der Global Layer ist für die Vernetzung zwischen den Knoten des Grids,
wie es die GMA vorsieht, zuständig. Abb. 5 verdeutlicht diesen Aufbau.
Abbildung 5: Der Global Layer von GridRM [4]
9
4.1
Local Layer
Die Gateways stellen im Local Layer Informationen über lokale Ressourcen
zur Verfügung. Das GridRM setzt dafür die so genannte Extensible Management Architektur ein, die verschiedene Abstraktionslayer des Gateways beschreibt. Aus Abb. 6 kann z.B. das Abstract Client Interface Layer (ACIL)
und das Coarse Grained Security Layer (CGSL) als Schnittstelle zum Global
Layer erkannt werden. Das ACIL dient dabei der Abstraktion von clientspezifischen Ressourceinformationen zu abstrakten GridRM-Datenmodellen und
das CGSL der Authentifikation und Autorisierung von externen Zugriffen auf
Informationen der Site.
Abbildung 6: Die Extensible Management Architektur [3]
Aus Abb. 6 ist auch die Plug-In Struktur von GridRM zu erkennen. Das
Abstract Data Layer (ADL) abstrahiert von darunterliegenden, heterogene
Informationen liefernden Datenquellen. Diese können mit Hilfe dynamisch
zur Laufzeit in das GridRM-Framework eingebundenen Treibern angesprochen werden.
4.1.1
Datentreiber
Im GridRM werden sämtliche Anfragen an Informationen über die Structured
Query Language (SQL) realisiert. Sämtliche Datentreiber müssen ein JDBCAPI implementieren, von dem aber auch ein Großteil aller Funktionen (das
gesamte API umfasst mehrere Hundert Methoden) null zurückgeben oder
eine SQLException auslösen darf. Bei einer Weiterentwicklung der Treiber
können dann diese Funktionalitäten hinzugefügt werden.
Minimal müssen die folgenden Interfaces bzw. Klassen implementiert sein,
um für das GridRM einen korrekten Treiber zu stellen:
10
java.sql.Driver: Legt fest, ob der Treiber mit den angegebenen Datenquellen umgehen kann.
java.sql.Connection: Baut eine Verbindung zur Datenquelle auf und
initialisiert die Schema-Einstellungen (zum Umwandeln der datenquellenspezifischen Informationen in ein gemeinsames Format, s.u.).
java.sql.Statement: Übersetzt SQL-Anfragen in Anfragen an die Datenquelle.
java.sql.ResultSet: Enthält die Ergebnisse einer Anfrage
java.sql.ResultSetMetaData: Beschreibt den Aufbau des zurückgelieferten ResultSets
Das Format der Monitoringdaten in GridRM entspricht dem GLUESchema (Grid Laboratory Uniform Environment) [5]. Diese Schema ermöglicht
eine einheitliche Benennung der Informationen unabhängig von den heterogenen Datenquellen. Aus diesem Grund müssen die Datenquellen-Treiber
Daten zwischen dem GLUE-Schema und dem proprietären DatenquellenFormat konvertieren können, wobei sie den Schema Manager zu Hilfe nehmen können, da dieser schon Mapping Funktionen für GLUE bietet. Falls
eine Konvertierung von bestimmten Werten einer Datenquelle nicht möglich
oder noch nicht implementiert ist, kann ein Treiber null zurückgeben.
Treiber können beim Gateway registriert werden, wenn der Gateway startet, oder dynamisch, sobald ein Client einen Treiber zu Verfügung stellt.
Wenn ein Treiber schon einmal beim Gateway registriert war, ist dieser im
Connection Manager gecacht, und wird auch nach einem Neustart des Gateway sofort wieder registriert. Es ist auch möglich einen Treiber erst bei einer
konkreten Anfrage eines Clients an eine bestimmte Datenquelle zu registrieren. Sämtliche Treiber-Registrierungen werden über den GridRM Driver
Manager abgewickelt. Eine typische Abfrage nach Informationen ist in Abb.
7 dargestellt.
Aus Abb. 7 ist außerdem der Event Manager zu erkennen. Dieser nimmt
native Daten von Datenquellen entgegen, die ohne Umweg eines Treiber erzeugt werden, speichert diese dauerhaft und leitet sie an dafür registrierte
Komponenten weiter. Zudem können Events von GridRM in ein für die Datenquellen verständliches Format konvertiert werden.
11
Abbildung 7: Ein Query im GridRM Gateway [3]
4.2
Status
Ein großer Nachteil des GridRM ist, dass es noch in der Entwicklung ist und
noch nicht zur Verfügung steht. Auf der offiziellen Internetseite des Projektes
wird ein Release für Ende dieses Jahres (2004) angekündigt3 . Es steht schon
fest, dass initial Datenquellentreiber für Ganglia, NetLogger, den Network
Weather Service (NWS), das Simple Network Managment Protocol (SNMP)
und das Scalable Cluster Management System (SCMS) zur Verfügung stehen
werden.
5
Ganglia
Ganglia [6] ist ein weiteres skalierbares, verteiltes Monitoringsystem für Grids,
wobei diese in der Ganglia-Terminologie ein Zusammenschluss verschiedener Cluster sind. Ganglia überwacht den Zustand eines Clusters basierend
auf einem multicastbasierten listen/announce Protokoll und setzt verbreitete und etablierte Techniken wie XML, XDR (External Data Representation,
ein Standard für die Binärcodierung von Daten) [7] ein und das RRDtool
zum Speichern und Visualisieren von Daten.
3
Meldung vom 8.11.2004
12
5.1
Architektur
In jedem Cluster benutzen einzelne Knoten Heartbeat Messages, die an eine
bekannte Multicast-Addresse versendet werden, um die Mitgliedschaft in dem
Cluster aufrecht zu halten. Werden über eine gewisse Anzahl von typischen
Announcement-Intervallen keine Heartbeat-Messages versandt, nimmt Ganglia an, dass der Knoten nicht mehr zur Verfügung steht. Die Knoten in einem
Cluster überwachen ihre lokalen Ressourcen und senden, wenn sich signifikante Änderungen ergeben, diese Informationen an die bekannte MulticastAdresse. Auch Applikationen können Informationen über eigene Metriken in
der gleichen Weise an diese Adresse veröffentlichen. Alle Knoten innerhalb eines Clusters akzeptieren Multicast-Pakete sowohl von Applikationen als auch
die von anderen Knoten. Damit hat jeder Knoten innerhalb eines Clusters
die gleichen Informationen. Nach einem Crash kann so schnell der Zustand
des Clusters wiederhergestellt werden.
In Ganglia werden verschiedene Cluster über eine Baumstruktur miteinander verbunden, wie in Abb. 8 dargestellt ist. Da jeder Knoten in einem
Abbildung 8: Die Ganglia Architektur [6]
Cluster ja Informationen über alle anderen Knoten und auch Applikationen
innerhalb des Clusters hat, kann das gesamte Cluster durch einen einzelnen,
beliebigen Knoten repräsentiert werden. Knoten, die höher in dem Baum
liegen, halten aus Redundanzgründen trotzdem Verbindungen zu mehreren
Knoten in einem Cluster. Damit repräsentiert jeder Knoten in dem Baum
eine Menge von Clustern und Informationen können über regelmäßiges Polling tieferliegenden Knoten aggregiert werden. Dabei werden auch immer alle
13
Informationen eines Knoten übertragen.
5.2
Implementierung
Ganglia ist durch die zwei Daemonen gmond und gmetad implementiert.
gmond ist der Daemon, der auf jedem Knoten gestartet wird und zum einen
für die Built-In Metriken als auch für die benutzer-/applikationsspezifischen
Metriken zuständig. gmetad ist für Informationen von Clusterverbünden zuständig.
5.2.1
gmond
gmond selber in mehrere Threads aufgeteilt, die alle dedizierte Aufgaben
haben (s. Abb. 9). Der Collect and Publish Thread sammelt lokale Informationen und versendet sie über Multicast. Außerdem sendet er die periodischen Heartbeat Messages. Die Listening Threads empfangen MulticastNachrichten von anderen Knoten im Cluster und legen diese Daten in einem als hierarchischer Hashtable organisierten lokalen Speicher ab. Als dritte Gruppe von Threads akzeptieren die XML Export Threads Anfragen nach
Daten von anderen Knoten und versenden diese entsprechend XML-kodiert.
Es ist normalerweise der Fall, dass die Anzahl eingehender Multicast-Nachrichten
die Anzahl an Requests von anderen Knoten bei weitem überwiegen.
In Ganglia werden die Multicastnachrichten XDR [7] kodiert versendet
und auch als Binärdaten abgelegt, da dies einen viel effizienteren Zugriff
ermöglicht und viel weniger Platz benötigt als eine XML-Kodierung.
Abbildung 9: Der Aufbau des gmond-Daemonen [6]
Typische Built-In Metriken, die vom gmond überwacht werden sind Dinge wie CPU-Auslastung, Speicherverbrauch, Prozesstabellen, System und Betriebssystemdetails etc. Diese Informationen werden über Standard-Interfaces
14
gesammelt (z.B. /proc). Applikationen können Metriken über das Kommandozeilentool gmetric publizieren. Um die Datenmengen, die per Multicast
versendet werden, zu minimieren, werden für die Built-In Metriken so genannte Static Metric Lookup-Tabellen eingeführt, in denen zu einem eindeutigen Key die Charakteristiken der entsprechenden Metrik verzeichnet sind.
Bei applikationsspezifischen Metriken müssen die Charakteristika jedoch explizit angegeben werden. Tabelle 1 stellt beispielhaft so eine Tabelle dar.
In weiteren Tabellen werden zu jeder Metrik Intervalle, Schwellwerte usw.
Key (xdr u uint) Metric
Value Format
0
User-defined Explicit
xdr u short
1
cpu num
2
cpu speed
xdr u uint
3
mem total
xdr u uint
4
swap total
xdr u uint
...
...
...
Tabelle 1: Eine Teil einer Static Metric Lookup Tabelle
festgelegt. Schwellwerte legen fest, ab wann Monitoringdaten dieser Metrik
versendet werden. So werden Ressourcen eingespart, wenn keine Daten in uninteressanten Wertebereichen zur Verfügung stehen. Die Intervalle kann man
für praktisch konstante Werte (z.B. Anzahl der CPUs) sehr groß wählen
und damit einer Ressourcenverschwendung vorbeugen. Die Intervalle werden
über Time Thresholds beschrieben. In Ganglia werden Nachrichten bis zu
dieser Maximalzeit zufallsverteilt versendet, damit die Netzwerklast zeitlich
möglichst gleichmäßig verteilt wird. Durch die Obergrenze (Time Threshold)
kann jedoch trotzdem ein Nicht-Ankommen von Nachrichten festgestellt werden.
Monitoringdaten haben einen Timestamp und werden von gmond mit
zwei Zeitlimits versehen. Bei einer Anfrage bekommt ein Client zusätzlich zu
den Monitoringdaten selber das Soft Limit mitgeteilt. Ist die aktuelle Zeit
über dem Soft Limit, weiß der Client, dass diese Daten evtl. schon veraltet
sind. Ist das Hard Limit überschritten werden die Monitoringdaten gelöscht
und so wieder Speicher freigegeben.
Um festzustellen, ob Knoten zwischen zwei Heartbeat-Messages neu gestartet worden sind, werden die Heartbeat-Messages mit der Startzeit des
gmond als Timestamp versehen. Stellt ein Knoten zwischen zwei HeartbeatMessages eines anderen Knoten eine veränderter Zeit fest, weiß er, dass der
Knoten neue Monitoringdaten braucht, um wieder den aktuellen Zustand des
Clusters zu kennen. Dazu werden im alle Time Thresholds zurückgesetzt und
15
so werden Monitoringdaten versandt, sobald sie bereitstehen. Dies ist besonders bei selten publizierten Daten (wie z.B. die Anzahl CPUs eines Knoten)
wichtig.
5.2.2
gmetad
Mit dem gmetad-Daemon werden Verbünde von Clustern überwacht und Daten von verschieden Clustern zusammengeführt (s. Abb. 8). Jeder gmetadDaemon pollt regelmäßig Informationen von den Datenquellen (d.h. von
gmond-Daemonen, die ein ganzes Cluster repräsentieren oder von anderen
gmetad-Daemonen, die Verbünde von Clustern repräsentieren), parst und
aggregiert die ankommende XML-Daten und stellt diese so anderen Clients
wieder als XML-Daten zur Verfügung. Zu jeder Datenquelle werden in einer Konfigurationsdatei des gmetad verschiedene IP-Adressen von tiefer im
Baum liegenden Knoten abgelegt, um Daten auch bei Wegfall eines Knoten
weiter sammeln zu können. Im gmetad wird für jede Datenquelle ein eigener
Thread gestartet.
5.2.3
RRDtool
In Ganglia werden Daten im RRDtool abgelegt, mit dem diese auch visualisiert werden können. Das RRDtool (Round Robin Database Tool) [8] kann
Zeitreihen von Daten in einer konstant großen Datenbank ablegen, in dem
bei Daten mit fortschreitendem Alter die Granularität schrittweise gröber
wird. Gleichzeitig kann das RRDtool aus den Datenbeständen die Werte der
verschiedenen Metriken von Ganglia als Graph gegen die Zeit auftragen.
5.3
Performancebetrachtungen
In [6] werden Messungen von Ganglia auf verschiedenen Grids beschrieben.
Die Messungen zeigen, dass Ganglia linear mit der Anzahl der Knoten und
der Clustergröße in dem Grid skaliert. Dies betrifft Parameter wie benötigte
Bandbreite, Anzahl Pakete, Speicherverbrauch etc. Dies ermöglicht Cluster
mit hunderten von Knoten und Verbünde mit bis zu 100 Clustern; dies kann
sogar noch gesteigert werden, wenn weitere Optimierungen wie z.B. Komprimierung eingesetzt werden.
6
Network Weather Service
Der Network Weather Service (NWS) [9] erhält seinen Namen dadurch, dass
er ähnlich einer Wettervorhersage, Vorhersagen über die Performance eines
16
Netzwerks und einzelner Computer macht. Die Vorhersagen werden auf Basis
historischer Daten für einen befristeten Zeitraum gemacht. Durch solche Aussagen können z.B. Scheduler optimiert werden. Ziel des NWS ist es, neben den
in der Einleitung genannte allgemeingültigen Zielen für Monitoring-Systeme
im Grid, eine möglichst präzise Vorhersage zu treffen.
6.1
Architektur
Im NWS werden vier verschiedene Teilprozesse4 eingesetzt. Der Persistant
State Prozess legt Messwerte dauerhaft in einem persistenten Speicher ab
und kann diese bei Bedarf auch von dort wieder laden. Der Name Server
Prozess verknüpft symbolische Namen mit Low-Level Kontaktinformationen
(z.B. IP-Adresse und Port). Die Sensor Prozesse sammeln von den überwachten Ressourcen die Messwerte. Der Forecaster Prozess trifft für eine
spezifizierte Ressource eine Performance-Vorhersage (für ein bestimmtes Intervall). Abb. 10 zeigt wie die Prozesse auf verschiedene Computer verteilt
werden können. In einem System gibt es nur einen Name Server, der auch
Abbildung 10: Die verschiedenen Prozesse im NWS
als einziger eine allgemein bekannte Adresse besitzt und bei dem alle anderen Prozessen beim Start die Bindings ihrer Namen registrieren. Nach einer
spezifizierten Zeit verlieren die Bindings ihre Gültigkeit und müssen neu registriert werden. Daher müssen sich aktive Prozesse regelmäßig beim Name
Server Prozess melden. Die Sensor Prozesse monitoren die Performance des
4
in [9] als Component Processes bezeichnet
17
Netzwerks und der Prozessoren und legen diese Informationen im Persistant
State Prozess ab. Der Forecaster Prozess agiert als Proxy zwischen Workstations und Benutzeranfragen. Alle Prozesse im NWS sind stateless, d.h. alle
Messungen (inkl. Timestamp) werden vom Persistant State Prozess sofort
persistent gespeichert und dann ein Acknowledge versendet. Da Messungen
für eine Vorhersage nur bis zu einem bestimmte Alter eine Rolle spielen,
werden zu alte Messungen verworfen.
6.2
Forecasts
Um eine Vorhersage zu machen, fragt der Forecaster beim Persistant State
Prozess nach einer Zeitreihe eines bestimmten Parameters. Das NWS versucht nicht messwertspezifische Vorhersagemodelle auf eine Zeitreihe anzuwenden, sondern versucht aus einer Menge von unspezifischen VorhersageModellen das auszuwählen, das wahrscheinlich die höchste Genauigkeit liefern wird. Dazu werden die Modelle auf verschieden große erste Teile“ der
”
Zeitreihe von Messwerten angewandt und daraus die restlichen Werte vor”
hergesagt“. Das Modell, dass kumulativ den geringsten Fehler bei der Vor”
hersage“ der schon bekannten Werte hat, wird benutzt um Werte aus der
(nahen) Zukunft vorherzusagen. Der Vorteil daraus ist, dass nicht für alle
gemessenen Parameter Vorhersage-Modelle vorliegen müssen. Die verschiedenen Vorhersage-Modelle, aus denen schließlich das beste gewählt wird, sind
über ein Interface beliebig erweiterbar. Beim Bestimmen einer Vorhersage
werden alle registrierten Prediction Module nach einer Vorhersage befragt.
Die Güte einer solchen Vorhersage ist aus Abb. 11 ersichtlich. Auf der
linken Seite der Abbildung ist die tatsächliche Netzwerklast einer Verbindung zwischen der University of California, Santa Barbara und der Kansas
State University zu sehen. Auf der rechten Seite ist die Vorhersage des NWS
dargestellt.
Abbildung 11: Links: Die gemessene Netzwerklast, Rechts: Die Vorhersage
vom NWS[9]
18
7
Resümee
In den vorhergehenden Kapiteln wurden nun einige Monitoringsysteme für
Ressourcen in Grids vorgestellt. Die beiden System R-GMA und GridRM
basieren auf der GMA vom GGF (Global Grid Forum), wobei das GridRM
in Global und Local Layer untergliedert wird, von dem nur“ der Global
”
Layer über eine GMA-Architektur vernetzt ist. Bei GridRM wird besonderer Wert auf die Erweiterbarkeit gelegt, da alle denkbaren Datenquellen um
Treiber erweitert werden können, die sich statisch oder dynamisch bei dem
Local Layer des verwaltenden Gateway registrieren. Sämtliche Kommunikation wird wie beim R-GMA über die Datenbanksprache SQL durchgeführt
wobei die Architektur des R-GMA explizit vorsieht, dass sich das System
nach außen hin wie eine große relationale Datenbank verhält und der interne
Aufbau des Systems bei der Kommunikation so wenig wie möglich eine Rolle
spielt.
Bei Ganglia ist eine ausgeklügelte Architektur mit hoher Ausfallsicherheit
erkennbar. Dadurch, dass Ressourceninformationen des Systems auf allen
Knoten verteilt sind, ist es für die Verfügbarkeit von Daten nicht tragisch,
wenn ein System ausfällt. Durch die Baumstruktur ist es leicht möglich einen
Überblick über die Ressourcen des Grids (bzw. eines Teils des Grids) zu
bekommen, bevor detaillierte Informationen angefordert werden.
Mit dem Network Weather Service liegt ein Resource-Monitoring System
vor, mit dem aus Zeitreihen von beliebigen Parametern Vorhersagen über die
zukünftige Performance des Systems getroffen werden kann. Daraus ergeben
sich enorme Vorteile beim Schedulen von Jobs, da hier mit hoher Wahrscheinlichkeit ein sehr guter Schedule aufgestellt werden kann.
19
Literatur
[1] B. Tierney, R. Aydt, D. Gunter, W. Smith, M. Swany, V. Taylor, and
R. Wolski. A grid monitoring architecture. Technical report, Global Grid
Forum, January 2002.
[2] R-gma: Relational grid monitoring architecture, 2004. Verfügbar bei
http://www.r-gma.org.
[3] Mark Baker and Garry Smith. GridRM: An extensible resource monitoring system. Technical report, Distributed Systems Group, University of
Portsmouth, UK, June 2003.
[4] Garry Smith. GridRM: A resource monitoring architecture for the grid,
2002.
[5] Glue-schema. Verfügbar bei http://www.hicb.org/glue/glue-schema/
schema.htm.
[6] Matthew L. Massie, Brent N. Chun, and David E. Culler. The ganglia
distributed monitoring system: design, implementation, and experience.
Technical report, Elsevier B.V., Amsterdam, 2003.
[7] R. Srinivasan. XDR: External data representation standard (rfc1832).
Technical report, Network Working Group, 1995.
[8] Ketan Patel.
RRD beginner guide.
Verfügbar bei http:
∼
//people.ee.ethz.ch/ oetiker/webtools/rrdtool/tutorial/
rrdbeginners.html.
[9] Rich Wolski, Neil T. Spring, and Jim Hayes. The network weather service: A distributed resource performance forecasting service for metacomputing. Technical report, National Partnership for Advanced Computational Infrastructure, 1999.
20