D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge

Größe: px
Ab Seite anzeigen:

Download "D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge"

Transkript

1 D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge Arbeitspaket/Task: AP 2 Task 2.2 Fälligkeit: M12 Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: ZIH Koudela, Daniela (DK) Mickler, Holger (HM) Focht, Erich (EF) Gordon, Minor (MG) 180 /Abgeschlossen ZIH ZIH NEC NEC Interne Gutachter: Volk, Eugen HLRS Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X Version Datum Änderungen Autor Erste Gedanken DK Struktur soweit klar und einiger Text drin DK, HM Kapitel 3.2 Infrastruktur DK D2.1 Design der Monitor[...] Werkzeuge v180 1/

2 Infrastruktur DK, HM Regressionstests u. a. DK, HM Metriken, Schlüssel-Wert-Paare, Kommentare vom HLRS Kommunikationskanäle überarbeitet DK Kapitel 3 Grundlagen überarbeitet, noch einige TODOs drin, aber sollte aus inhaltlicher Sicht soweit passen. Einleitung Compliance-Tests-Kapitel soweit fertig. Einarbeitung von Kommentaren Schnittstellen in Kapitel 3 neu organisiert. HM Überarbeitung Kapitel 2 HM DK, HM DK, HM DK, HM Monitoring Framework Text, Kapitel 3. EF, MG Überarbeitung der Regressions- und Compliance-Tests Kleine Änderungen an Kapitel 3 EF Überarbeitung des Dokumentes DK HM, DK D2.1 Design der Monitor[...] Werkzeuge v180 2/

3 Inhaltsverzeichnis 1 Einleitung Grundlagen für Monitoring, Regressions- und Compliance-Tests Datenrepräsentation Metriken Schlüssel-Wert-Paare Infrastruktur Kommunikationskanäle Nachrichtenfluss Aufbau und Inhalt der Nachrichten Persistente Speicherung der Daten und deren Abfrage Schnittstellen Schnittstelle zum Monitoring Schnittstelle zum Batch-System Schnittstelle für Compliance-Tests Schnittstelle für Regressionstests Monitoring Publish / Subscribe Publisher Subscriber Broker API Publish/Subscribe und das Monitoring Framework Datenkollektoren Kommandos Verbraucher von Daten Implementation des Monitoring Frameworks Implementation von Datenkollektoren Kommandos Verbraucher von Monitoring-Daten Implementation der Broker Beispiel: Nachrichtenfluss im Monitoring Framework Design der Compliance-Tests Komponenten von Compliance-Tests Monitoring-Plugin Event-Generator Manager Design der Regressionstests Konfiguration von Regressionstests Ablauf eines Regressionstests Online-Regressionstest Offline-Regressionstest...20 D2.1 Design der Monitor[...] Werkzeuge v180 3/

4 5.3 Algorithmen für Regressionsanalysen Algorithmus lineare Regression Zusammenfassung/Fazit...23 D2.1 Design der Monitor[...] Werkzeuge v180 4/

5 1 Einleitung In diesem Dokument wird das Design für das Monitoring und für die Regressions- und Compliance-Tests erläutert. Dieses baut auf dem Konzept der Gesamtarchitektur, das in Dokument [D1.2] beschrieben ist, auf. Eine detaillierte Spezifikation der im Design vorgesehenen Schnittstellen und Datenformate wird im Dokument [TSD] TIMaCS Schnittstellen und Datenformate definiert. Kapitel 2 beschreibt die gemeinsamen Grundlagen von Monitoring, Regressions- und Compliance- Tests. Dabei geht es um die Darstellung der Daten, die Infrastruktur, zu der die Kommunikationskanäle gehören, auf denen die Daten zwischen den Computern ausgetauscht werden und um die Art und Weise, wie Daten persistent gespeichert werden können, so dass man sie bei Bedarf später abfragen kann. Auch die Schnittstellen werden in diesem Kapitel kurz skizziert. Kapitel 3 beschäftigt sich mit Monitoring. Hier wird vor allem dargestellt, wie die Daten von den Sensoren über ein Publish/Subscribe System an die Verbraucher der Daten weitergeleitet werden. In Kapitel 4 werden die Compliance-Tests beschrieben, indem auf die einzelnen Komponenten eingegangen wird, die man zur Durchführung eines Compliance-Tests braucht. Regressionstests sind das Thema von Kapitel 5. Hier wird deren Konfiguration und Ablauf geschildert. Des Weiteren wird eine Unterteilung in Online- und Offline-Regressionstests vorgenommen und die Unterschiede zwischen den beiden Arten erläutert. Anschließend werden die bereits implementierten Algorithmen zur Regressionsanalyse beschrieben. Kapitel 6 liefert eine kurze Zusammenfassung der wesentlichen Ergebnisse dieses Berichts. D2.1 Design der Monitor[...] Werkzeuge v180 5/

6 2 Grundlagen für Monitoring, Regressions- und Compliance- Tests In diesem Kapitel geht es um die Grundlagen, die Monitoring, Compliance- und Regressionstests gemeinsam haben. Dies sind zum einen die Metriken, die angefordert oder weiterverarbeitet werden, zum anderen ist es die Infrastruktur, die nötig ist, um Daten und Nachrichten im System auszutauschen und zu speichern. Ferner werden in diesem Kapitel auch die erforderlichen Schnittstellen kurz skizziert. 2.1 Datenrepräsentation Alle Daten, die vom Monitoring und von Regressions- und Compliance-Tests erzeugt werden, müssen in einer generischen Form in TIMaCS vorliegen, damit das System alle Informationen gleichermaßen für Entscheidungen, bspw. über auszuführende Aktionen, verwenden kann. Die Form der Daten wird in Metriken beschrieben und die verschiedenen generierten Daten werden in einem einheitlichen Format als Schlüssel-Wert-Paare in TIMaCS eingespeist Metriken Eine Metrik ist die Beschreibung einer Datenquelle, deren Werte mit TIMaCS aufgezeichnet werden. In einer Metrik wird definiert, von welchem Typ die gesammelten Daten sind und in welcher Einheit die Daten gespeichert werden. Jede Metrik hat einen eindeutigen Namen, unter dem die Daten zugeordnet werden. Die genaue Definition einer Metrik, wie sie in TIMaCS zum Einsatz kommt, ist im Dokument [TSD] beschrieben. Eine aggregierte Metrik ist eine Kombination verschiedener Messwerte. Um eine aggregierte Metrik zu erhalten, werden einzelne Messwerte analysiert und danach mit bestimmten anderen Messwerten (bzw. deren Resultat nach einer Analyse) so kombiniert, dass eine neue Metrik entsteht Schlüssel-Wert-Paare Auf Basis der definierten Metriken werden die von Plugins gesammelten Daten als Paket von Schlüssel-Wert-Paaren in TIMaCS weiterverarbeitet. Die in einem Paket zusammengefassten Schlüssel-Wert-Paare beschreiben genau einen Monitoring-Wert. Ein Paket muss immer den Zeitstempel der Messung, eine Kennung für den Knoten, die Metrik und die Datenquelle, sowie den eigentlichen Monitoring-Wert enthalten. Die Einbeziehung einer Kennung der Datenquelle erlaubt die Erfassung mehrerer gleichartiger Werte so kann zum Beispiel ein Sensor zur Messung der Prozessortemperatur alle Prozessoren eines Knotens mit derselben Metrik aufnehmen. Die von TIMaCS verwendeten Schlüsselbezeichnungen und der Aufbau eines Pakets bezüglich notwendiger Schlüssel-Wert-Paare sind im Dokument [TSD] spezifiziert. D2.1 Design der Monitor[...] Werkzeuge v180 6/

7 2.2 Infrastruktur Tools for Intelligent System Management of Die Infrastruktur von TIMaCS ermöglicht ein Austauschen von Daten, Nachrichten und Kommandos zwischen den einzelnen Komponenten von TIMaCS, sowohl innerhalb eines Knotens als auch zwischen verschiedenen Knoten, sowie deren Speicherung Kommunikationskanäle Kommunikationskanäle werden dazu gebraucht, um die Monitoring-Daten, sowie Sensorwerte für Regressions- und Compliance-Tests als auch deren Ergebnisse zu den Stellen weiterzuleiten, an denen sie gespeichert und/oder weiterverarbeitet werden. Dazu ist es häufig notwendig, die Informationen von einem Knoten zu einem oder mehreren Knoten der benachbarten Ebene in der TIMaCS- Hierarchie zu schicken. Dies geschieht mit einem Publish/Subscribe System, das auf dem Standard AMQP basiert Nachrichtenfluss Der Data-Collector sammelt die Monitoring-Daten. Dabei werden Pull-Sensoren abgefragt und Push-Sensoren liefern ihre Daten. Die Daten werden zum einen im Storage gespeichert und zum anderen an den Filter & Event Generator weitergeleitet. Der Filter & Event Generator analysiert die Daten und meldet Fehler in Form von Events. Diese werden an den Management-Block geschickt. Dort empfängt sie der Event/Data Handler, welcher empfangene Events und Reports zum einen zur Bildung von Statistiken zwischenspeichert und zum anderen untersucht. Stellt der Event/Data Handler einen Fehler fest, so wird die Decision-Komponente benachrichtigt und entscheidet, was zur Fehlerbehebung getan werden soll. Diese kann einerseits wiederum ein Event generieren, andererseits aber auch einen Befehl zur Reaktion auf den eingetretenen Fehlerfall. Im letzteren Fall wird zusätzlich ein Report generiert, damit die nächsthöhere Ebene, die üblicherweise mehr Informationen hat, weiß, was passiert ist und Entscheidungen gegebenenfalls korrigieren kann Aufbau und Inhalt der Nachrichten Der Aufbau und Inhalt der Nachrichten sind im Dokument [TSD] beschrieben Persistente Speicherung der Daten und deren Abfrage Da das Ergebnis von Performance-Messungen mit früheren Messwerten verglichen wird, ist es wichtig, aktuelle Monitoring-Daten, Events, sowie die Ergebnisse der Regressions- und Compliance-Tests für spätere Abfragen zu speichern. Als Speichermedium eignet sich eine Round-Robin Datenbank, die auf allen TIMaCS-Knoten installiert werden kann. Um die Größe der Datenbank in einem vernünftigen Rahmen zu halten, aber dennoch auf Monitoring-Werte, die schon weiter zurück liegen, zugreifen zu können, gibt es die Möglichkeit, für Daten, die ein bestimmtes Alter erreicht haben, nur Mittelwerte und/oder Maxima bzw. Minima zu speichern. Dabei ist das Alter, ab welchem nicht mehr alle Details gespeichert werden, konfigurierbar, damit TIMaCS sich an die unterschiedlichen Bedürfnisse verschiedener Rechenzentren anpassen lässt. D2.1 Design der Monitor[...] Werkzeuge v180 7/

8 Um eine gute Skalierbarkeit zu erhalten, speichert jeder TIMaCS-Knoten von Schicht 1 die Daten der Rechenknoten für die er zuständig ist in seiner Round-Robin Datenbank. Aus Gründen der Fehlertoleranz sollen die Daten jedoch redundant gespeichert werden. Dabei liegt das Hauptaugenmerk auf der Wiederherstellbarkeit der Daten, weniger auf der ständigen Verfügbarkeit, wobei eine einfache Redundanz als ausreichend erachtet wird. Damit die Daten auch bei einer kaputten Festplatte nicht verloren sind, werden die Daten zwischen den Knoten der ersten Schicht gespiegelt. Eine Möglichkeit wäre, dass jeweils zwei TIMaCS-Knoten sich gegenseitig spiegeln. Dies setzt jedoch eine gerade Anzahl TIMaCS-Knoten in der ersten Schicht voraus. Eine andere Möglichkeit, die nicht eine bestimmte Knotenanzahl voraussetzt, wäre, die Spiegelung in einer ringförmigen Anordnung vorzunehmen, d. h. Knoten n spiegelt seine Daten auf Knoten n+1 und Knoten n max spiegelt seine Daten auf Knoten 0. So könnte ein TIMaCS-Knoten die ankommenden AMQP-Nachrichten aus der Data Queue an den Knoten, der ihn spiegelt, weiterleiten. Da die Wahrscheinlichkeit, dass zwei Festplatten gleichzeitig ausfallen, zwar sehr gering, aber immer noch größer als Null ist, kann man TIMaCS auch so konfigurieren, dass die Daten auf mehrere Knoten gespiegelt werden. Dies erzeugt jedoch mehr Last im Netzwerk und der Speicherverbrauch auf den TIMaCS-Knoten der ersten Schicht steigt. Analoges gilt für die TIMaCS-Knoten der Schicht n. Diese speichern die aggregierten Daten der TI- MaCS-Knoten von Schicht n-1, für die sie zuständig sind und die des TIMaCS-Knotens der gleichen Schicht, den sie spiegeln. Sobald die Daten gespeichert sind, lassen sie sich durch den Administrator abrufen. Dieses Kommando wird vom TIMaCS-Administratorknoten nach unten an die Knoten der Schicht n geleitet. Dabei kann der Administrator durch einen Filter auswählen, welche Daten er sehen möchte. Bei der Menge der Daten, die TIMaCS speichert, ist dies empfehlenswert. So können einerseits die Ist-Werte (aktuellste Daten der Datenbank) abgefragt werden um z. B. genauere Informationen zu einem aktuellen Problem zu bekommen. Andererseits können auch historische Daten eines beliebigen Zeitintervalls der gespeicherten Daten abgefragt werden. Dies kann z. B. dann erforderlich sein, wenn ein Problem mehrfach aufgetreten ist und man untersuchen möchte, ob sich das Problem in den Monitoring-Daten vor seinem Auftreten bereits ankündigt. Im Filter lässt sich nicht nur das Zeitintervall, aus dem man die Daten sehen möchte, einstellen, sondern auch, ob man nur die Daten von bestimmten Knoten angezeigt haben möchte und welche Metriken angezeigt werden sollen. Neben der Abfragemöglichkeit Zeige mir die Daten der Knoten A, B, C,... im Zeitintervall von t 1 bis t 2 und zwar bin ich an den Metriken x, y,... interessiert. gibt es noch die Möglichkeit, sich alle Knoten eines Zeitintervalls anzeigen zu lassen, die ein bestimmtes Kriterium erfüllen. Ein Beispiel hierfür ist: Zeige mir alle Knoten an, die im Zeitintervall von t 1 bis t 2 mindestens 1 GB Swap belegt haben. 2.3 Schnittstellen TIMaCS definiert eine Reihe von Schnittstellen, die beispielsweise dazu dienen, (Mess-)Daten aus unterschiedlichen Quellen in einheitlicher Form in TIMaCS weiterverarbeiten und Management- Funktionalitäten verschiedener Systeme zur Steuerung benutzen zu können. Für dieses Dokument sind insbesondere die Schnittstelle für Compliance-Tests, die Schnittstelle für Regressionstests und die Schnittstelle für das Monitoring-System von Interesse, wobei die Schnittstelle für das Monito- D2.1 Design der Monitor[...] Werkzeuge v180 8/

9 ring-system auch eine Schnittstelle zum Batch-System beinhaltet. Für diese Schnittstellen können Erweiterungen sogenannte Plugins geschrieben werden, um die Funktionalität von TIMaCS an die unterschiedlichen Bedürfnisse der einzelnen Rechenzentren anzupassen. Im Folgenden werden diese Schnittstellen skizziert. Die vollständigen Definitionen aller von TI- MaCS angebotenen Schnittstellen werden in [TSD] fortlaufend aktualisiert Schnittstelle zum Monitoring Die Schnittstelle zum Monitoring dient dazu, neue Sensoren und Monitoring Systeme als Plugins einzubinden. Diese Schnittstelle wird durch die Art und Weise definiert, wie Daten in das Publish/Subscribe-System eingelesen werden Schnittstelle zum Batch-System Die Schnittstelle zum Batch-System erfüllt zwei Funktionen. Sie erlaubt nicht nur das Monitoring des Batch-Systems, sondern durch sie ist es auch möglich, Einstellungen am Batch-System zu ändern (z. B. Knoten aus dem Batch-Betrieb entfernen oder eine Queue zu starten). Da letzteres eine Aufgabe des Managements ist, soll an dieser Stelle nur auf das Monitoring des Batch-Systems eingegangen werden. Will man Informationen, wie Anzahl der Jobs pro Queue, welche Jobs laufen auf welchem Knoten oder akzeptieren die Queues Jobs und werden diese auf die Knoten verteilt auch als regelmäßig aktualisierte Monitoring-Werte beobachten/aufzeichnen, so muss TIMaCS in der Lage sein, mit dem verwendeten Batch-System zu kommunizieren. Dazu wird das Batch-System über eine Schnittstelle eingebunden. Dies ermöglicht, je nach verwendetem Batch-System unterschiedliche Plugins zu laden und für noch nicht unterstützte Batch-Systeme eigene Erweiterungen zu schreiben. Der Vorteil einer solchen Schnittstelle ist, dass sie die Programmierung von Monitoring-Plugins erlaubt, die nur gegen diese Schnittstelle programmiert werden müssen. Dadurch sinkt der Aufwand bei der Integration neuer Batch-Systeme, da nur die Schnittstelle zu diesem Batch-System programmiert werden muss und nicht zusätzlich noch eine Reihe von Monitoring-Plugins. Da die unterschiedlichen Batch-Systeme hinsichtlich ihres Funktionsumfangs differieren, muss die Schnittstelle so gestaltet sein, dass es eine Abfragemöglichkeit gibt, welche Funktionen das gewählte Batch-System zur Verfügung stellt. Dies hat den Vorteil, dass man in der Auswahl des Batch-Systems nicht eingeschränkt ist und auch spezielle Funktionen einzelner Batch-Systeme genutzt werden können, um einen Mehrwert bezüglich der Verwaltung mittels TIMaCS zu realisieren Schnittstelle für Compliance-Tests Der Compliance-Test nutzt die Schnittstelle zu den Monitoring-Plugins. Diese Schnittstelle muss jedoch die Möglichkeit bieten, Monitoring-Werte auch zwischenzeitlich abfragen zu können, damit sie für Compliance-Tests verwendbar ist. Des Weiteren ermöglicht die Schnittstelle für Compliance- Tests auch das Erstellen von Sensoren, die nur auf Anfrage ausgelesen werden. D2.1 Design der Monitor[...] Werkzeuge v180 9/

10 2.3.3 Schnittstelle für Regressionstests Tools for Intelligent System Management of Aufgrund seines Designs besitzt ein Regressionstest mehrere Schnittstellen. Schnittstelle zum Publish/Subscribe System: Ein Online-Regressionstest (siehe Kap ) ist ein Verbraucher von Monitoring-Daten und nutzt somit die selbe Schnittstelle zum Publish/Subscribe System wie auch die anderen Verbraucher (siehe Kap. 3.1). Schnittstelle zur Datenbank: Ein Offline-Regressionstest (siehe Kap ) holt sich seine Daten aus der Datenbank und nutzt somit die Schnittstelle zur Datenbank. Die Schnittstelle zur Regressionsanalyse ist als offene Schnittstelle gestaltet, um Nutzern/Entwicklern die Möglichkeit zu geben, weitere Algorithmen für Regressionsanalysen zu implementieren. An dieser Stelle wird ein Datenarray mit Zeitstempel-Wert-Paaren übergeben. Für das Ergebnis eines Regressionstests wird die selbe Schnittstelle verwendet wie für die Weiterverarbeitung von klassischen Monitoring-Werten. D2.1 Design der Monitor[...] Werkzeuge v180 10/

11 3 Monitoring In diesem Kapitel wird auf Basis von [D1.2] das Design des Monitoring Frameworks zusammen mit der zur Kommunikation verwendeten Publish/Subscribe Architektur beschrieben. Im ersten Abschnitt beschreiben und motivieren wir die Nutzung der Publish/Subscribe Architektur und deren Grundkomponenten. Der darauf folgende Abschnitt 3.2 erklärt wie die einzelnen Komponenten des Monitoring Frameworks auf die Publish/Subscribe Architektur abgebildet werden. Abschnitt 3.3 beschreibt die konkrete Implementation des Monitoring Prototyps in Python. Der letzte Abschnitt widmet sich dem Nachrichtenfluss durch das Framework am Beispiel des Prototyps. 3.1 Publish / Subscribe Das Monitoring Framework benutzt ein Topic-basiertes Publish/Subscribe System [EPT03a] zum Datentransport. In solchen Systemen senden Publisher Nachrichten (Events) an Broker über durch URIs eindeutig identifizierbare Datenkanäle (Named Channels, Topics). Die URIs der Datenkanäle werden von Subscribern benutzt, um bei Brokern nur Nachrichten bestimmter Topics zu abonnieren. Broker leiten Nachrichten an andere Broker weiter, die interessierte (abonnierte) Subscriber haben. Die Stärke von Publish/Subscribe Systemen ist die zeitliche und räumliche Entkopplung von Datenerzeugern und Datenverbrauchern, die strikt asynchron kommunizieren, was Skalierbarkeit und Fehlertoleranz zur Folge hat. Die folgenden Abschnitte erläutern die Funktionen der einzelnen Komponenten Publisher Publisher sind die aktiven Quellen aller im System transportierter Daten. Beim Versenden einer Nachricht an einen Broker erwartet und bekommt der Publisher keine unmittelbare Rückmeldung über den Erfolg der Zustellung oder Weiterleitung der Nachricht an Subscriber. Aus diesem Grund muss der Publisher weder dauerhaft mit dem Broker in Verbindung stehen noch permanent laufen, und kann somit ein separates externes Programm sein, das einfach periodisch oder aperiodisch aufgerufen wird. Die inherente Asynchronie des Publish/Subscribe Programmiermodells hat zur Folge, dass man damit keine synchronen RPCs (Remote Procedure Calls) im üblichen Sinne implementieren kann. Pull Mechanismen sind in einem solchen System ebenfalls nicht direkt programmierbar, da diese, wie RPCs, auf synchronem Austauschen von Anfragen und Antworten basieren. Im Publish/Subscribe Modell muss man stattdessen die Kopplung von Anfrage und dazugehöriger Antwort asynchron emulieren, zum Beispiel durch das Abonnieren eines temporären Rückkanals oder durch implizite Antworten, bei denen der Anfragende die Antwort aus der Änderung im normalen Nachrichtenstrom des Angefragten erkennt. Diese Nachteile in der synchronen Programmierung kompensiert das Publish/Subscribe Modell durch viele Vorteile wie: eine mögliche Garantie von Nachrichtenauslieferung (und damit Fehlertoleranz), Pufferung von Nachrichten an Brokern, die temporäre Netzwerkausfälle kompensiert, etc. D2.1 Design der Monitor[...] Werkzeuge v180 11/

12 3.1.2 Subscriber Tools for Intelligent System Management of Subscriber sind die passiven Senken für die Nachrichten und Daten die im Publish/Subscribe System ausgetauscht werden. Sie empfangen Nachrichten auf einem oder mehreren Kanälen von genau einem Broker Broker Broker nehmen Nachrichten auf bestimmten Kanälen von Publishern in Empfang und liefern diese an Subscriber aus, die die entsprechenden Kanäle abonniert haben. Systeme können um einen einzigen zentralen Broker aufgebaut werden, oder um ein logisches Netzwerk von miteinander gekoppelten Brokern, die ein Overlay-Network bilden [PB03]. Die Topologie des Overlay-Networks wird bestimmt durch die abonnierten Kanäle, da nur diese Nachrichten transportieren. Sie sollte der physikalischen Topologie und Hierarchie des Clusters nah kommen API Broker präsentieren eine sehr simple API: publish(event) : für Publisher, subscribe(topic) : für Subscriber, wie in [PEKS07] beschrieben. Die Auslieferung der Nachrichten an die Subscriber kann via push erfolgen, durch den Aufruf einer notify(event) Methode auf dem Subscriber durch einen RPC-artigen Mechanismus, oder durch pull von Subscriber Seite, was etwa einem synchronen poll_events() RPC Aufruf der Subscriber auf dem Broker entspricht. Diese einfache API kann in verschiedenen Arten erweitert und optimiert werden, so könnten zum Beispiel Publisher ihre Absicht, auf bestimmten Kanälen Nachrichten zu verschicken, ankündigen, was sowohl das Broker-Routing als auch die Abonnements der Subscriber beeinflussen könnte. 3.2 Publish/Subscribe und das Monitoring Framework Datenkollektoren Datenkollektoren sind die wichtigsten Publisher im Monitoring Framework. Sie sammeln Daten von spezifischen Quellen (zum Beispiel: Temperatursensoren oder Load des Knotens oder des Batch Systems). Dies kann sowohl aktiv geschehen, durch Abfrage der Datenquellen, oder passiv durch Empfang von Benachrichtigungen einer Datenquelle (zum Beispiel über SMTP). Die Daten werden anschließend an den Broker als Nachricht über einen vereinbarten Kanal geschickt. Datenkollektoren können autonome Agenten sein, die kontinuierlich Daten sammeln und publizieren, oder könnten von einem externen Programm getriggert werden (bspw. mittels cron Jobs). Sie können jedoch nicht direkt Daten durch pull an einen Interessenten liefern. D2.1 Design der Monitor[...] Werkzeuge v180 12/

13 3.2.2 Kommandos Tools for Intelligent System Management of Externe Prozesse sollen auszuführende Befehle ins Monitoring System publizieren können, die asynchron ausgeführt werden. Diese sollten zum Beispiel die Konfiguration der Datenkollektoren ändern können, zum Beispiel die Zeitintervalle der Datensammlung ändern. Ebenso könnten von Subscribern Kommandos angenommen werden, die auf dem Knoten als UNIX Befehle auszuführen wären, es ist vorstellbar, dass so eine Komponente die Publish/Subscribe Infrastruktur des Monitoring Systems nutzt, aber streng genommen gehört die Ausführung von UNIX Kommandos zu Administrationszwecken nicht zum Monitoring System. In jedem Fall muss die Ausführung von Kommandos der asynchronen Natur des Publish/Subscribe Systems angepasst werden Verbraucher von Daten Im Monitoring Framework sind Subscriber die Verbraucher der Nachrichten, die Broker zur Verfügung stellen. Diese sind zum Beispiel: round-robin Datenbanken für historische Daten, User-Interfaces die Monitoring-Daten in Echtzeit darstellen, Aggregator-Prozesse die Monitoring-Daten kontinuierlich beobachten und daraus neue Daten generieren, die wiederum im Monitoring Framework publiziert werden. Publisher können gleichzeitig auch Subscriber sein, so wie Datenkollektoren, die Monitoring Metriken publizieren, aber auch Subscriber auf einem Kommando Kanal sind, oder Aggregatoren, die Subscriber sind für bestimmte Monitoring-Daten, aber selbst auch neue Monitoring-Daten erzeugen und an Broker senden. Broker sind im Monitoring Framework hingegen unabhängige Prozesse die immer vorhanden sein müssen, in etwa so wie Router in einem Netzwerk. Komponenten im Monitoring Framework können zusätzlich zum asynchronen Interface des gesamten Publish/Subscribe Systems ein synchrones Interface implementieren, zum Beispiel kann die round-robin Datenbank ein synchrones Interface zur Datenabfrage implementieren, dieses sollte allerdings strikt für Punkt-zu-Punkt Client-Server Anwendungen gelten, und nicht mit der Asynchronie des Monitoring Frameworks interferieren. 3.3 Implementation des Monitoring Frameworks Der aktuelle Prototyp des Monitoring Frameworks ist in der Programmiersprache Python implementiert [http://www.python.org/]. Der Hauptvorteil der Sprache ist, dass sie schnelles Prototyping und die Implementation experimentellen Codes einfach macht. Python erlaubt das dynamische Laden und neu Laden von Programmmodulen zur Laufzeit, besitzt eine umfangreiche Standardbibliothek und wird gepflegt und entwickelt von einer großen Community von Entwicklern Implementation von Datenkollektoren Datenkollektoren für verschiedene Quellen sind implementiert als Python Module, die als Plugins dynamisch zur Laufzeit geladen werden. Damit das Plugin mit TIMaCS zusammen funktioniert, ist genau ein Interface das zum Message Channel wichtig. Datenkollektoren können nur aus einem Sensor bestehen oder einen Zugang zu einem Dienst darstellen, der wiederum tausende Sensoren hat. Mehrere Kollektoren können in einem Prozess laufen und periodisch zeitgesteuert aktiviert werden um Daten zu sammeln und zu publizieren. Die Zielkanäle für die Nachrichten eines Daten- D2.1 Design der Monitor[...] Werkzeuge v180 13/

14 kollektors werden in einer Konfigurationsdatei angegeben. Datenkollektoren können Kommando- Kanäle abonnieren um Konfigurationsbefehle zu empfangen Kommandos Kommandos können als Teil einer GUI oder als Command Line Tools implementiert werden. In der Regel werden sie eine Nachricht publizieren und eventuell auf die Auswirkung dieser Nachricht warten (siehe Diskussion über die Emulation synchroner Kommandos) Verbraucher von Monitoring-Daten Wie die Datenkollektoren werden Datenverbraucher auch als Module/Plugins implementiert, die aus ihrer Konfigurationsdatei die zu abonnierenden Kanäle herauslesen. So konfiguriert sich die in Python implementierte round-robin Datenbank als Subscriber zu bestimmten Monitoring-Daten, empfängt die entsprechenden Nachrichten und speichert sie im Dateisystem. Weitere Verbraucher von Monitoring-Nachrichten sind: Aggregatoren die bestimmte Monitoring-Nachrichten abonnieren und daraus neue Metriken als neue Nachrichten erzeugen. Aggregatoren sind somit Subscriber auf einen bestimmten Teil des Namensraumes der Metrik-Kanäle, und Publisher für die aggregierten Metriken. Filter und Event-Generatoren sind ein Sonderfall der Aggregatoren. Wie Aggregatoren abonnieren sie einen oder mehrere Metrik-Kanäle und verfolgen deren Datenstrom, bloß die neu erzeugten Metriken sind speziell und werden als seltene Ereignisse interpretiert, auf die das automatische Management Framework reagieren muss. Technisch gibt es keine Unterscheidung zwischen Monitoring-Metriken oder Ereignissen, beide können dieselben Publish/Subscribe Mechanismen nutzen Implementation der Broker Es gibt eine Vielzahl von Implementationen des Publish/Subscribe Konzepts. Die von uns zur Zeit favorisierte Variante ist AMQP (Advanced Message Queueing Protocol) [http://www.amqp.org], die Publishern und Subscribern, die auf verschiedenen Rechnern laufen erlaubt, zu kommunizieren. AMQP implementiert die publish(), subscribe() und notify() Operationen und transportiert Nachrichten als binäre Blobs, ist also agnostisch bezüglich deren Inhalt und Format. In dem aktuellen Prototyp werden Python Objekte mit Hilfe von JSON [http://json.org/] als Nachrichten serialisiert. Als Optimierung können Publisher und Subscriber, die im selben Prozess laufen (also in der selben Python Instanz geladen sind), Nachrichten über einen prozessinternen Broker austauschen, der nur Zeiger auf die Nachrichten zwischen Publisher und Subscriber austauscht. Die prozessweise Entkopplung der Publisher und Subscriber ist im Konzept immer noch vorgesehen, und wird später vorgenommen. Das konkrete on-wire Format der Nachrichten ist leicht austauschbar und ebenfalls optimierbar, einerseits bezüglich Kompatibilität, andererseits bezüglich Performance. Die AMQP-Broker-Architektur [AMQP-0.10] zeigt die notwendige Skalierbarkeit, wie von Marsh et. al in [MSPP09] analysiert und beschrieben, und bringt die notwendige Zuverlässigkeit und Feh- D2.1 Design der Monitor[...] Werkzeuge v180 14/

15 lertoleranz. Diese Schlüssel-Eigenschaften (Skalierbarkeit, Zuverlässigkeit und Fehlertoleranz) der AMQP-Architektur stellen sicher, dass die Monitoring Komponente die angestrebte Skalierbarkeit, Robustheit und Hochverfügbarkeit erreicht. Die Topologie baut sich im Overlay Netzwerk automatisch auf und zwar durch die Abonnenten und die named channels. Dadurch fließen Nachrichten nur dorthin, wo sie gebraucht werden. Eine natürliche Wahl der Hierarchie in einem solchen Setup wäre die Abbildung der physikalischen Topologie: normale Rechenknoten haben Datenkollektoren und einen AMQP-Broker, Daten-Verbraucher auf Administrationsknoten, die zum Beispiel in jedem Rack vorhanden sein könnten, abonnieren Nachrichten der Rechenknoten des eigenen Racks und bekommen von diesen Nachrichten zugesandt. Aus Redundanzgründen könnte ein benachbarter Administrationsknoten dieselben Kanäle abonnieren. Administrationsknoten auf höherer Ebene abonnieren bloß Nachrichten der Rack-Administrationsknoten. 3.4 Beispiel: Nachrichtenfluss im Monitoring Framework In diesem Abschnitt beschreiben wir ein System, in dem Daten von einem Ganglia Monitoring System [http://ganglia.sf.net/] gesammelt werden, über einen vereinbarten Kanal ins Monitoring Framework publiziert werden, ihr zeitlicher Verlauf in einer Datenbank gespeichert wird, und später über ein Kommandozeilen-Tool abgefragt werden kann. Das System besteht aus folgenden Komponenten: Ein Ganglia Datenkollektor, der periodisch Ganglia's gmetad Dämon pollt (eine zusätzliche aperiodische Abfrage wäre auch denkbar) und neue Metrik-Werte aus den XML Daten herausliest und über publish() diese Metriken in Form von JSON-serialisierten Objekten an einen AMQP Broker über einen TCP Socket schickt. Ein AMQP Broker, der Nachrichten empfängt und diese an die Datenbank-Komponente sendet. Eine Datenbank, die den zeitlichen Verlauf der Metrikdaten speichert, eine notify(event) Operation dem dazugelinkten AMQP Brokercode bietet, und Nachrichten, die über diese Operation ankommen, verarbeitet, indem sie sie in eine Datei speichert. Ein Kommandozeilen Tool, das synchron die Datenbank nach dem zeitlichen Verlauf von Metriken in bestimmten Zeitintervallen abfragen kann, in etwa ähnlich rrdtool [http://oss.oetiker.ch/rrdtool/]. Die Nutzung des Publish/Subscribe Systems erlaubt eine einfache und bequeme Entkopplung der einzelnen Komponenten, wobei alle Nachrichten durch den AMQP Broker geleitet werden. Dies erlaubt getrennte Entwicklung, Separierung der Komponenten im Fehlerfall und eine simple Art Datenredundanz zu implementieren: durch das Hinzufügen einer zusätzlichen Datenbank als Subscriber. D2.1 Design der Monitor[...] Werkzeuge v180 15/

16 4 Design der Compliance-Tests Monitoring läuft autonom nach dem Bottom-up-Prinzip ab, d. h. die Sensoren der Monitoring-Plugins liefern periodisch Messwerte (push) oder werden periodisch abgefragt (pull). Diese Messwerte werden dann an einen Broker übermittelt (publish). Der Event-Generator bekommt als Subscriber jeden Messwert, prüft ihn zum Beispiel hinsichtlich Überschreitung eines Schwellwerts und generiert im Falle eines Überschreitens ein oder mehrere Events. Im Gegensatz dazu sind Compliance-Tests Top-down-Prozesse, die jedes Mal explizit aus der Management-Ebene gestartet werden. Ein Compliance-Test ermittelt zu einem willkürlichen Zeitpunkt den aktuellen Zustand (eines Teils) des Systems, damit in Abhängigkeit des Ergebnisses eine oder mehrere Aktionen ausgelöst werden können. Die Daten, die von Compliance-Tests zur Auswertung angefordert werden, lassen sich wie Monitoring-Daten als Metriken beschreiben und die Gewinnung der Daten ist auf ähnliche Weise möglich, daher wird die Infrastruktur des Monitorings als Basis für Compliance-Tests genutzt. 4.1 Komponenten von Compliance-Tests An der Durchführung eines Compliance-Tests sind mehrere Komponenten beteiligt, deren Aufgaben und Zusammenspiel nachfolgend erklärt werden Monitoring-Plugin Die Sensoren des Monitorings liefern die Messdaten, die von einem Compliance-Test ausgewertet werden. Klassisches Monitoring erfasst für gewöhnlich nur in einem festgelegten Intervall die Werte der Sensoren, was für die Top-down-Arbeitsweise von Compliance-Tests jedoch unter Umständen unzureichend ist nämlich dann, wenn das Monitoring-Intervall relativ groß ist, denn ein Compliance-Test soll den aktuellen Status des Systems bewerten. Daher enthält die Schnittstelle zu Monitoring-Plugins in TIMaCS die Möglichkeit, Sensorwerte zwischenzeitlich abfragen zu können. Dies ist nicht gleichzusetzen mit einer Pull-Abfrage von Sensordaten, vielmehr wird dem Monitoring-Plugin mittels eines Kommandos mitgeteilt, dass der aktuelle Wert eines bestimmten Sensors ausgegeben werden soll. Dieser Wert wird dann auf dem gewöhnlichen Weg über das Messaging- System verteilt. Zusammen mit der Anfrage nach dem aktuellen Sensorwert wird ein Time-out festgelegt, das angibt, wie lange der Empfänger bereit ist, auf den Wert zu warten. Das asynchrone Vorgehen in Verbindung mit einem Time-out bietet zwei Vorteile: 1. Es können auch Push-Sensoren für Compliance-Tests verwendet werden, wenn das Monitoring-Intervall klein genug ist und das Monitoring-Plugin die aktuellen Werte der Sensoren zwischenspeichert. Abhängig davon, wann der letzte Messwert des jeweiligen Sensors eingetroffen ist, kann entweder der gespeicherte Wert für den Compliance-Test ausgegeben werden oder das Monitoring-Plugin wartet auf den nächsten Messwert, wenn er voraussichtlich innerhalb des Time-outs kommen wird. 2. Im Fall von Pull-Sensoren kann das Monitoring-Plugin entscheiden, ob es eine zusätzliche Abfrage des Sensors außerhalb des festgelegten Intervalls durchführt (was zusätzlichen Overhead durch das Monitoring bedeutet) oder bis zum nächsten regulären Abfragezeitpunkt wartet, sofern dieser innerhalb des Time-outs liegt. D2.1 Design der Monitor[...] Werkzeuge v180 16/

17 Der erste Punkt hat eine Einschränkung der Auswahl von Sensoren für Compliance-Tests zur Folge es können nur jene verwendet werden, deren Monitoring-Intervall kleiner als das Doppelte des Time-outs ist. Unter Umständen ist diese Einschränkung zu restriktiv und unnötig, wenn auch ein älterer Sensorwert für den Compliance-Test genügt. Diese Information kann bei dem Kommando an das Monitoring-Plugin mitgegeben werden, so dass der Sensorwert von der letzten Messung für den Compliance-Test ausgegeben wird. Die Schnittstelle ermöglicht auch das Erstellen von Sensoren, die nur auf Anfrage ausgelesen werden und zur Generierung ihrer Messwerte ressourcenintensive Prozesse starten, zum Beispiel einen Benchmark. Die vom oben erwähnten Kommando angeforderten Messwerte werden auf dem gewöhnlichen Weg in TIMaCS eingespeist, das heißt sie werden genau wie alle anderen Monitoring-Daten über die Data Queue verteilt, worüber sie an alle Subscriber verteilt werden Event-Generator Die zweite Komponente, die bei einem Compliance-Test beteiligt ist, ist ein Event-Generator. Dieser ist Teil des Filter & Event Generators. Der Filter & Event Generator gliedert sich in mehrere Teile. Diejenigen Teile, die für die Filterung und das Generieren von Events der Daten des klassischen Monitorings zuständig sind, sind immer aktiv, filtern die eintreffenden Monitoring-Werte, und generieren bei speziellen Anlässen, wie z. B. im Fehlerfall, Events. Dies ist für Compliance-Tests nicht ausreichend, da hier immer die Information über den Monitoring-Wert weitergeleitet werden muss, weil vom Ergebnis des Compliance-Tests weitere Aktionen abhängen. Deswegen werden für die Durchführung eines Compliance-Tests Teile des Event-Generators aktiviert, die jeweils nur auf das Eintreffen eines Monitoring-Wertes warten, d. h. jeder dieser Teile abonniert eine Metrik, die durch den Compliance-Test ausgewertet wird. Sobald der Wert dieser Metrik da ist, wird ein Event generiert bzw. wenn nach Ablauf des Time-outs kein Messwert eingetroffen ist, wird auch ein Event generiert. Danach schalten sie sich wieder ab und werden erst bei der Durchführung des nächsten Compliance-Tests auf diesen Metriken wieder mittels eines Kommandos aktiviert, so dass nicht zu jedem vom Monitoring erfassten Messwert dieser Metriken weiter Events generiert werden. Der Inhalt der Events, die bei der Durchführung von Compliance-Tests generiert werden, ist eine boolesche Interpretation des Messwertes und enthält nach Bedarf noch weitere Details. Kam innerhalb des Time-outs kein Messwert an, so enthält das Event die Nachricht, dass kein Messwert eingetroffen ist. An der Durchführung von Compliance-Tests können Event-Generatoren mehrerer TIMaCS-Knoten beteiligt sein. Dies ist dann der Fall, wenn die Monitoring-Werte von unterschiedlichen Rechenknoten sind, die nicht alle von demselben TIMaCS-Knoten verwaltet werden Manager Die dritte Komponente eines Compliance-Tests befindet sich im Management-Block und ist für die Steuerung verantwortlich. Hier wird der Compliance-Test manuell oder durch einen Aktionsplan gestartet, indem die Kommandos zur Aktivierung der Event-Generatoren und die Befehle zur Abfrage D2.1 Design der Monitor[...] Werkzeuge v180 17/

18 der für diesen Compliance-Test ausgewählten Monitoring-Sensoren über die Command-Queue verteilt werden. Danach wird gewartet, bis entweder alle erwarteten Events eingetroffen sind oder das Time-out erreicht wurde. Wenn das Time-out erreicht wurde, wird ein Event zu dem Fehler generiert, das von TIMaCS weiter behandelt werden kann. Im anderen Fall werden die generierten Events ausgewertet und zu einem Gesamtergebnis des Compliance-Tests kombiniert. Dieses Ergebnis wird wiederum als Event verbreitet, um davon abhängige Prozesse starten zu können. D2.1 Design der Monitor[...] Werkzeuge v180 18/

19 5 Design der Regressionstests Ein Regressionstest analysiert den Verlauf der Messwerte einer Metrik, um Indikatoren für abnormes Verhalten zu finden. Dazu wird ein geeigneter Algorithmus auf eine konfigurierbare Menge von Daten angewendet, dieser Vorgang wird im Folgenden als Regressionsanalyse bezeichnet. Das Ergebnis der Regressionsanalyse stellt das Resultat des Regressionstests dar und wird in Form einer Metrik in TIMaCS publiziert, so dass die im TIMaCS-Framework vorhandenen Methoden zur Auswertung und Fehlererkennung diese Werte einbeziehen können. 5.1 Konfiguration von Regressionstests Das Verhalten eines Regressionstests, welcher von TIMaCS durchgeführt werden soll, ist durch seine Konfiguration festgelegt, die folgende Eigenschaften beinhaltet: Wahl einer Regressionsanalyse für die Berechnung Anzahl (N) der Messwerte, auf denen die Regressionsanalyse arbeiten soll Zeitintervall (T) als Limit für die Neuberechnung bei Online-Regressionstests Wahl der Metrik für Eingabedaten Definition der Ausgabemetrik Wahl der Schranke, ab wann abnormes Verhalten vorliegt 5.2 Ablauf eines Regressionstests Es gibt zwei unterschiedliche Varianten, wie Regressionstests ausgelöst werden. Online-Regressionstests berechnen ihr neues Ergebnis beim Eintreffen eines neuen Wertes der zugeordneten Metrik. Offline-Regressionstests werden manuell durch den Administrator oder anhand eines Aktionsplans von TIMaCS gestartet Online-Regressionstest Ein Online-Regressionstest abonniert die Metrik, deren Verlauf er analysieren soll. Er hält die letzten N Werte dieser Metrik im Speicher und jedes Mal, wenn ein neuer Wert dieser Metrik ankommt, wird das neue Ergebnis des Regressionstests berechnet. Abhängig vom eingesetzten Algorithmus kann die Berechnung sehr aufwendig sein, daher wird innerhalb des konfigurierten Zeitintervalls T die Berechnung nur einmal vorgenommen. Bei der Initialisierung, zum Beispiel beim Start von TI- MaCS, liest ein Online-Regressionstest die letzten N-1 Werte seiner Metrik aus der Datenbank in seinen Zwischenspeicher, um beim nächsten Eintreffen eines Messwerts sofort einen neuen Wert ausgeben zu können. D2.1 Design der Monitor[...] Werkzeuge v180 19/

20 5.2.2 Offline-Regressionstest Tools for Intelligent System Management of Ein Offline-Regressionstest berechnet die Regressionswerte über der gewählten Metrik für einen bestimmten Zeitraum, der beim Aufruf des Tests angegeben wird. Um dem Administrator jedoch ein funktionales Werkzeug zur Performance-Analyse zur Verfügung zu stellen, reicht die alleinige Angabe eines Zeitintervalls nicht aus. So ist zum Beispiel der Fall denkbar, dass der Performance-Verlust einer Komponente sehr langsam vonstatten geht, so dass Performance-Verluste nur entdeckt werden können, wenn sich der Regressionstest über einen längeren Zeitraum - z. B. mehrere Monate erstreckt. Wurden von dieser Komponente in diesem Zeitraum regelmäßig Monitoring-Daten aufgezeichnet, so sind die vorhandenen Daten zu zahlreich, als dass der Regressionstest seine Analyse in angemessener Zeit durchführen könnte. Deswegen sind hier in Abweichung zu Kap. 5.1 folgende Angaben zu machen: Wahl einer Regressionsanalyse für die Berechnung. Angabe von zwei Zeitpunkten t 0 und t 1 innerhalb derer die Messwerte liegen, die für den Regressionstest herangezogen werden sollen. Angabe eines Zeitpunktes t 2 mit t 0 t 2 t 1. t 2 gibt hierbei an, dass alle Daten zwischen t 0 und t 2 gemittelt werden und im Bereich t 2 bis t 1 werden alle Daten ohne Mittelwertbildung verwendet. Ist t 2 = t 0 wird keine Mittelwertbildung durchgeführt und bei t 2 = t 1 werden nur gemittelte Daten für die Regressionsanalyse verwendet. Zeitintervall Δt. Dies gibt das Zeitintervall für die Mittelwertbildung an. Idealerweise ist t 2 - t 0 ein Vielfaches von Δt. Wahl der Metrik für Eingabedaten. Definition der Ausgabemetrik. Hier ist es sinnvoll eine neue Metrik zu definieren, damit nicht versehentlich Daten der Online-Regressionstests, die möglicherweise einen identischen Zeitstempel haben, überschrieben werden. Es ist zu prüfen, wie lange es dauert, Daten aus der Datenbank auszulesen. Sollte dies sehr viel Zeit und Ressourcen brauchen, so könnte es durch aus sinnvoll sein, ein weiteres Zeitintervall zu definieren. Aus diesem Zeitintervall würden dann alle Daten der betreffenden Metrik in den Hauptspeicher kopiert werden, damit der Administrator auf verschiedenen Untermengen dieser Daten Regressionstests ausführen kann und so die Stabilität des Ergebnisses des Regressionstests bzgl. Veränderung der Parameter überprüfen kann. Will man mehrere Regressionstests hintereinander weg auf sich überschneidenden Datenmengen machen, so kann es durchaus schneller sein, erst alle Daten in den Hauptspeicher einzulesen anstatt jedes mal die Datenbank abzufragen. Aufgrund seines Designs ist die Definition des Zeitstempels eines Offline-Regressionstests nicht offensichtlich. Einerseits wird er in der Gegenwart durchgeführt, andererseits kann er sich über Werte erstrecken, die ausschließlich in der Vergangenheit gemessen wurden. Da der Zeitstempel bei Online-Regressionstests gleich dem Zeitstempel des jüngsten Eingabewertes ist, wird auch bei Offline-Regressionstests der Zeitstempel des jüngsten Eingabewertes als Zeitstempel des Ergebnisses genommen, auch wenn dieser bereits weit in der Vergangenheit liegt. D2.1 Design der Monitor[...] Werkzeuge v180 20/

Linux Cluster in Theorie und Praxis

Linux Cluster in Theorie und Praxis Foliensatz Center for Information Services and High Performance Computing (ZIH) Linux Cluster in Theorie und Praxis Monitoring 30. November 2009 Verfügbarkeit der Folien Vorlesungswebseite: http://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/

Mehr

Verteiltes Monitoring. 23. Oktober 2014

Verteiltes Monitoring. 23. Oktober 2014 Verteiltes Monitoring 23. Oktober 2014 Inhalt Szenarien Entscheidungskriterien Best practices Was wir nicht verfolgen 2 / 37 Szenarien Mehrere Rechenzentren weltweit Überwachung tausender Märkte Überwachung

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch SNMP4Nagios Grazer Linuxtage 2007 Peter Gritsch Inhalte Motivation für Network Monitoring SNMP Grundlagen Nagios Grundlagen SNMP4Nagios PlugIns Motivation für Network Monitoring Probleme erkennen bevor

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

Relevante Daten zum richtigen Zeitpunkt

Relevante Daten zum richtigen Zeitpunkt Netzwerkadministratoren analysieren Netze aus zahlreichen Blickwinkeln. Einmal steht die Netzwerksicherheit im Vordergrund, dann eine bestimmte Anwendung oder das Compliance-Management. Für alles gibt

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum NOCTUA by init.at... 3 3 Ihre Vorteile mit NOCTUA:... 4 4 NOCTUA Features... 5

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007 OSEK / COM Florian Hohnsbehn PG AutoLab Seminarwochenende 21.-23. Oktober 2007 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einführung 1.1 Was ist OSEK COM? OSEK COM ist eine vom OSEK-VDX-Konsortium entwickelte

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Systemmonitoring unter Linux

Systemmonitoring unter Linux Systemmonitoring unter Linux CPU-Counter B.Sc. Wirtsch.-Inform. Arno Sagawe, 29.06.10 Department of Informatics Scientifics Computing 1 Gliederung Systemmonitoring Protokolle und Dateien für das Systemmonitoring

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

BNG Bootloader Documentation

BNG Bootloader Documentation BNG Bootloader Documentation Release 0.2 Elias Medawar, Yves Peissard, Simon Honegger, Jonathan Stoppani 20. 04. 2010 Inhaltsverzeichnis 1 Abstract 1 2 Architektur 3 2.1 Überblick.................................................

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

D1.3 TIMaCS Gesamtarchitektur V2

D1.3 TIMaCS Gesamtarchitektur V2 D1.3 TIMaCS Gesamtarchitektur V2 Arbeitspaket/Task: Fälligkeit: AP1/T1.2 M25 Abgabetermin: 31.01.11 Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: HLRS Volk, Eugen Koudela, Daniela

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Sage 200 BI Installationsanleitung Cubes & Datawarehouses Manuelle Installation ohne SRSS/Sage Cockpit. Version 2014.0 11.11.2014

Sage 200 BI Installationsanleitung Cubes & Datawarehouses Manuelle Installation ohne SRSS/Sage Cockpit. Version 2014.0 11.11.2014 Sage 200 BI Installationsanleitung Cubes & Datawarehouses Manuelle Installation ohne SRSS/Sage Cockpit Version 2014.0 11.11.2014 Inhaltsverzeichnis Installationsanleitung Cubes & Datawarehouse Inhaltsverzeichnis

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: Advanced Resource Connector (ARC) ICA Joh.. Kepler Universität t Linz Advanced Resource Connector Entwickelt durch die NorduGrid Collaboration Skandinavische

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK" ANKE FLEISCHER

WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK ANKE FLEISCHER WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK" ANKE FLEISCHER EBINAR@LUNCHTIME HERZLICH WILLKOMMEN BEI WEBINAR@LUNCHTIME Moderation Anne K. Bogner-Hamleh

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

IBM SPSS Modeler Server 16 for Windows Installationsanweisungen

IBM SPSS Modeler Server 16 for Windows Installationsanweisungen IBM SPSS Modeler Server 16 for Windows Installationsanweisungen Inhaltsverzeichnis Installationsanweisungen....... 1 Systemanforderungen........... 1 Installation............... 1 Ziel................

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung. 1 - Inbetriebnahme. 1.1 - Gateway anschließen

Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung. 1 - Inbetriebnahme. 1.1 - Gateway anschließen Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung 1 - Inbetriebnahme Nachdem Sie die WeatherHub App von TFA Dostmann aus dem Apple App Store oder dem

Mehr

TimePunch. TimePunch Command. Benutzerhandbuch 14.08.2013. TimePunch KG, Wormser Str. 37, 68642 Bürstadt

TimePunch. TimePunch Command. Benutzerhandbuch 14.08.2013. TimePunch KG, Wormser Str. 37, 68642 Bürstadt TimePunch TimePunch Command Benutzerhandbuch 14.08.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch Command Revisions-Nummer 37 Gespeichert

Mehr

NAGIOS - WACHSAMER SCHUTZHEILIGER IM NETZ

NAGIOS - WACHSAMER SCHUTZHEILIGER IM NETZ CHEMNITZER LINUX-TAG 2004 Landeskriminalamt Thüringen NAGIOS - WACHSAMER SCHUTZHEILIGER IM NETZ Alexander Schreiber als@thangorodrim.de Chemnitz, den 7. März 2004 Nagions Inhalt Inhalt Übersicht & Name,

Mehr

EMU Bill & Report 1/33

EMU Bill & Report 1/33 EMU Bill & Report 1/33 Inhaltsverzeichnis Schnellstart... 3 1. Datenlogger hinzufügen... 3 2. Kostenstelle erstellen... 5 3. Zähler zu Kostenstelle hinzufügen... 6 4. Rechnungsposition erstellen... 7 5.

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

An integrated total solution for automatic job scheduling without user interaction

An integrated total solution for automatic job scheduling without user interaction An integrated total solution for automatic job scheduling without user interaction Multifunktional Der Job-Scheduler ist ein multifunktionaler Taskplaner welcher die Steuerzentrale zur regelmässigen Ausführung

Mehr

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 2

Mehr

CosmosMonitoring Server von CosmosNet

CosmosMonitoring Server von CosmosNet Network Services without limitation. Cosmos Server von CosmosNet Cosmos Cosmos Server [CMS] Der Cosmos Server, erhältlich als zertifizierte Hardware Box, virtuelle Maschine oder Softwarelösung, ist eine

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

Mehr

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014 Icinga Teil 2 Andreas Teuchert 25. Juli 2014 1 Nagios-Plugins Programme, die den Status von Diensten überprüfen können liegen in /usr/lib/nagios/plugins/ werden von Icinga aufgerufen, geben Status über

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Bitte beachten Sie beim Update einer Client / Server Version die Checkliste zum Update

Bitte beachten Sie beim Update einer Client / Server Version die Checkliste zum Update Hinweise zum Update Es gibt verschiedene Möglichkeiten ein pixafe System zu aktualisieren, die vorliegenden Hinweise helfen dabei neue Versionen zu finden und diese zu installieren. Dabei werden verschiedene

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

4D v11 SQL Release 6 (11.6) ADDENDUM

4D v11 SQL Release 6 (11.6) ADDENDUM ADDENDUM Willkommen zu Release 6 von 4D v11 SQL. Dieses Dokument beschreibt die neuen Funktionalitäten und Änderungen der Version. Erweiterte Verschlüsselungsmöglichkeiten Release 6 von 4D v11 SQL erweitert

Mehr

Generating Fingerprints of Network Servers and their Use in Honeypots. Thomas Apel

Generating Fingerprints of Network Servers and their Use in Honeypots. Thomas Apel Generating Fingerprints of Network Servers and their Use in Honeypots Thomas Apel Der Überblick Fingerprinting von Netzwerkdiensten Banner Verfügbare Optionen Reaktionen auf falsche Syntax Verwendung für

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen SiteAudit Knowledge Base Move Add Change Tracking Dezember 2010 In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen MAC Benachrichtigungen Vorteile Übersicht Heutzutage ändern sich

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Wurde eine Sammlung Werte übermittelt, so wird der örtliche Speicher des jeweiligen Moduls gelöscht und die Speicherung beginnt aufs Neue.

Wurde eine Sammlung Werte übermittelt, so wird der örtliche Speicher des jeweiligen Moduls gelöscht und die Speicherung beginnt aufs Neue. Um die Qualitätssicherung weiter zu verfeinern, wurde ein Modul entwickelt, welches die gemessenen Ölwerte während der Betriebszeit der Fritteuse kontinuierlich sammelt und diese dann auf Wunsch als E

Mehr

XMPP: Extensible Messaging and Presence Protocol

XMPP: Extensible Messaging and Presence Protocol XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung

Mehr

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2006. Peter Gritsch

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2006. Peter Gritsch SNMP4Nagios Grazer Linuxtage 2006 Peter Gritsch Inhalte Motivation für Network Monitoring SNMP Grundlagen Nagios Grundlagen SNMP4Nagios Plugins Motivation für Network Monitoring Probleme erkennen bevor

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Informationsbroschüre

Informationsbroschüre Informationsbroschüre Überwachung, Lastverteilung, automatische Aufgaben für Microsoft Dynamics NAV Mit IT IS control 2011 können Sie viele Mandanten und NAV-Datenbanken praktisch gleichzeitig mit wenigen

Mehr

EasyWk DAS Schwimmwettkampfprogramm

EasyWk DAS Schwimmwettkampfprogramm EasyWk DAS Schwimmwettkampfprogramm Arbeiten mit OMEGA ARES 21 EasyWk - DAS Schwimmwettkampfprogramm 1 Einleitung Diese Präsentation dient zur Darstellung der Zusammenarbeit zwischen EasyWk und der Zeitmessanlage

Mehr

ESB - Elektronischer Service Bericht

ESB - Elektronischer Service Bericht Desk Software & Consulting GmbH ESB - Elektronischer Service Bericht Dokumentation des elektronischen Serviceberichts Matthias Hoffmann 25.04.2012 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713

Mehr

Sensordaten mit SNMP verteilen

Sensordaten mit SNMP verteilen Sensordaten mit SNMP verteilen Axel Wachtler und Ralf Findeisen Chemnitzer Linux Tage 17.03.2013 Einleitung Systembeschreibung Was ist SNMP? Implementierung Demo Ausblick Systemüberblick Sensor- und Gatewayknoten

Mehr

Inhaltsverzeichnis. Teil 1 Node.js... 1

Inhaltsverzeichnis. Teil 1 Node.js... 1 xiii Teil 1 Node.js... 1 1 Was ist Node.js? 3 1.1 Die Zeitalter des Webs................................... 3 1.1.1 1990 bis 2000: Das Web 1.0....................... 3 1.1.2 2000 bis 2010: Das Web 2.0.......................

Mehr

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Erfassung von Umgebungskontext und Kontextmanagement

Erfassung von Umgebungskontext und Kontextmanagement Erfassung von Umgebungskontext und Kontextmanagement Jörg Schneider, Christian Mannweiler, Andreas Klein, Hans D. Schotten 13.05.2009 Inhalt 1. Einleitung 2. Anforderungen 3. Kontext Erfassung und Verteilung

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

AnyWeb AG 2006 www.anyweb.ch

AnyWeb AG 2006 www.anyweb.ch ITSM Practice Circle September 2006 Incident Management mit HP OpenView Operations Incident Mgt mit HP OV Operations Windows Was ist Incident Management? Einer von 10 - ITIL Prozessen Eine Störung (Incident)

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Die Informationen in diesem Artikel beziehen sich auf: Einleitung

Die Informationen in diesem Artikel beziehen sich auf: Einleitung Die Informationen in diesem Artikel beziehen sich auf:? Microsoft ISA Server 2004 Einleitung Der Microsoft ISA Server 2004 bietet sehr umfangreiche Monitoring Möglichkeiten um den Status der Firewall und

Mehr

Studienprojekt HP-MOM

Studienprojekt HP-MOM Institute of Parallel and Distributed Systems () Universitätsstraße 38 D-70569 Stuttgart Studienprojekt HP-MOM High Performance Message Oriented Middleware 23. Januar 2013 Kurt Rothermel, Frank Dürr, Patrick

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Seminarvortrag Secure NFS

Seminarvortrag Secure NFS Seminarvortrag Secure NFS Michael Stilkerich michael.stilkerich@informatik.stud.uni-erlangen.de am 12. Mai 2003 Einleitung Das Network File System ist ein sehr eleganter Weg, gemeinsam genutzte Dateisysteme

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Collax Monitoring mit Nagios

Collax Monitoring mit Nagios Collax Monitoring mit Nagios Howto Dieses Howto beschreibt die Konfiguration der Aktiven Überwachung auf einem Collax Server. Intern verwendet das System dafür Nagios. Primär wird Nagios zur Selbstüberwachung

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr

Die automatische Clientkonfiguration durch den DHCP-Server geschieht folgendermaßen:

Die automatische Clientkonfiguration durch den DHCP-Server geschieht folgendermaßen: Default Gateway: 172.16.22.254 Ein häufiger Fehler in den Konfigurationen liegt darin, dass der Netzanteil des Default Gateway nicht mit dem Netzanteil der IP-Adresse des Rechners übereinstimmt. 4.4 DHCP-Service

Mehr

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Caching Handbuch Auftraggeber: Version: 01 Projekttyp: Erstellt durch: Internet David Bürge INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Email david.buerge@inm.ch URL http://www.inm.ch

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Requirements Analysis Document

Requirements Analysis Document Requirements Analysis Document 1. Einleitung Dieses Dokument beschreibt die Anforderungen an ein automatisches Korrektur- und Abgabesystem für Uebungen mit dem Ziel einer Arbeitserleichterung für Assistenten.

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr