D5.2 Ergebnisse der Evaluierung

Größe: px
Ab Seite anzeigen:

Download "D5.2 Ergebnisse der Evaluierung"

Transkript

1 D5.2 Ergebnisse der Evaluierung Arbeitspaket/Task: AP 5 Task 5.2 Fälligkeit: M30 Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: NEC Jeutter, Andreas (AJ) Focht, Erich Lohrer, Marc Schwitalla, Jürgen Volk, Eugen Koudela, Daniela Belonozhka, Polina Schmidt, Matthias Schwarzkopf, Roland Volk, Eugen Schwarzkopf, Roland 471 Finale Version NEC NEC S&C S&C HLRS ZIH ZIH UMA UMA HLRS UMA Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X Version Datum Änderungen Autor Erstellung AJ Aktualisierung des Dokuments Alle Autoren Review und Aktualisierung des Dokuments Alle Autoren D5.2 Ergebnisse der Evaluierung v471 1/

2 Inhaltsverzeichnis 1 Einleitung Komponenten des Systems Monitoring Block Channels Tools Importer Schnittstellen zu anderen Komponenten Testszenarien Aggregatoren Hostaggregator Groupaggregator Schnittstellen zu anderen Komponenten Testszenarien Metrik Datenbank Tools Schnittstellen zu anderen Komponenten Testszenarien Hierarchie Regressionstests Compliancetests Filter & Event Generator Schnittstellen zu anderen Komponenten Testszenarien Management Block Rule-Engine Policy-Engine Testszenarien Schnittstellen zu anderen Komponenten Delegate D5.2 Ergebnisse der Evaluierung v471 2/

3 4.3.1 Schnittstellen zu anderen Komponenten Testszenarien vmmanager Komponente zur dynamischen Partitionierung Schnittstellen zu anderen Komponenten Testszenarien Integrationstests der Prototypkomponenten Testszenario 1: Importer - Channel - Metrik Datenbanken Testszenario 2: Importer - Channel Aggregator Channel - Metrik Datenbank Testszenario 3: Metrik Datenbank - DirectRPC Testszenario 4: Hierarchie-Ebenen Testszenario 5: Regressiontest (ZIH) Online: Importer - Channel Regressiontest Offline: Metrik Datenbank DirectRPC Regressiontest Testszenario 6: Partitionierung des Systems Test-Szenario 7: Policy-Engine Test-Szenario 8: Test des TIMaCS-Frameworks Szenariobeschreibung Ergebnisse Zusammenfassung Referenzen D5.2 Ergebnisse der Evaluierung v471 3/

4 1 Einleitung In diesem Dokument werden die Ergebnisse der Evaluierung des ersten integrierten Prototypen von TIMaCS dargestellt. Nachdem die Funktionalität der einzelnen Komponenten sichergestellt wurde, soll nun deren Zusammenwirken (Integration) an Hand von Testszenarien evaluiert werden. Die TIMaCS-Software wird auf dem zur Verfügung stehenden Entwicklungssystem (TIMaCS Cluster bestehend aus sechs Knoten) getestet. Dieses (kleine) Cluster ist ausreichend um die Komponenten bzw. deren Zusammenwirken auf richtige Funktionalität zu testen. In der nächsten Version dieses Dokuments soll der Test des TIMaCS-Frameworks auf einem großen System (BW-Grid mit etwa 500 Knoten) vorgesehen. Auf diesem System soll die Skalierbarkeit getestet werden. Um den Test spezieller Funktionalitäten (wie VM-Management) abzudecken ist ein Test auf dem im Aufbau befindlichen Games-Cluster vorgesehen. Allerdings wird dieses Cluster erst Ende Juli 2011 zur Verfügung stehen. D5.2 Ergebnisse der Evaluierung v471 4/

5 2 Komponenten des Systems In der folgenden Abbildung 1 ist die Gesamtarchitektur des TIMaCS Systems und die Interaktion der einzelnen TIMaCS Knoten dargestellt, entsprechend der Beschreibung und Darstellung in [D1.2] und [D1.3]. Legende Kommando Daten, Nachrichten, Ereignisse, Reports Heartbeat Update... Nachrichten / Ereignisse / Reports TIMaCS Administrator Knoten Heartbeat... TIMaCS Knoten Kommando Aktualisierung der Wissensbasis Aktualisierung der Wissensbasis... Wissensbasis Regeln, Policies,.. Wissensbasis Regeln, Policies,.. Aktualisierung der Wissensbasis Kommando Nachrichten / Ereignisse / Reports Nachrichten / Ereignisse / Reports Kommando Aktualisierung der Wissensbasis... Wissensbasis Regeln, Policies,.. TIMaCS Knoten Heartbeat... Heartbeat TIMaCS Knoten... Wissensbasis Regeln, Policies,.. Kommando Daten Daten Kommando Kommando Daten Daten Kommando Heartbeat Heartbeat Delegate Sensor Sensor Überwachte Ressource 1 Sensor... Sensor Sensor Sensor Überwachte Ressource n... Delegate Delegate Sensor Sensor Überwachte Ressource 1 Sensor Rechenknoten Rechenknoten Rechenknoten Abbildung 1: Hierarchische Struktur des Gesamtsystems.... Sensor Sensor Sensor Überwachte Ressource n Rechenknoten Delegate Die logische Struktur eines TIMaCS Knoten, dargestellt in Abbildung 2, wird durch einen Monitoring- und einen Management Block gebildet. D5.2 Ergebnisse der Evaluierung v471 5/

6 Legende Kommando, Query Daten Nachrichten, Events, Reports Heartbeat Rule/Policy Update TIMaCS Knoten Monitoring Block Data Data Query Events Data Heartbeat Kommando Management Block Kommando Events, Reports Heartbeat Heartbeat Kommando Wissensbasis Regeln, Policies,.. Sensor Sensor Sensor Überwachte Ressource 1 Abbildung 2: Struktur eines TIMaCS Knotens.... Delegate Sensor Sensor Sensor Überwachte Ressource n Delegate Im Folgenden werden kurz die bereits aus [D1.2] und [D1.3] bekannten Komponenten und deren Schnittstellen zu anderen Komponenten beschrieben. 3 Monitoring Block Der Monitoring Block setzt sich aus den Komponenten Channel, Importer, Metrik Datenbank und Aggregatoren zusammen. Das essentielle Datenformat für den Datenaustausch in TIMaCS ist das sogenannte Metrik Objekt. Dabei handelt es sich um eine Datenstruktur, die Key-Value-Pairs beinhaltet. Als Keys werden ausschließlich Strings verwendet, wohingegen Values jeden beliebigen Datentyp annehmen können. Die Anzahl und die Namen der Keys in einer Metrik sind beliebig, wobei die folgenden Keys immer vorhanden sein müssen. name value source host time Key Name der Metrik Wert des Datums Bemerkung Ursprung der Metrik (i. Allg. Name der Applikation) Name des Knotens, für den diese Metrik gilt Zeitpunkt (in Sekunden seit ) für den der Wert Gültigkeit hat D5.2 Ergebnisse der Evaluierung v471 6/

7 Da die gesamte Software, die für den Monitoring Block von TIMaCS entwickelt wurde in der Programmiersprache Python implementiert wurde, werden Metriken i. Allg. auch in der Python Notation dargestellt. Dies erlaubt die einfache Lesbarkeit und ermöglicht die Erzeugung eines Python-Objektes mittels der eval() Funktion. Hier ein Beispiel für ein Metrikobjekt, welches aus einem Datensatz des Gangliaimporters erzeugt wurde. Metric(name=u'load_fifteen', tmax=950, type_=u'float', value=0.0, tn=77l, source=u'gmond', host=u'n105', time= l, units=u' ', dmax=0) Alle Komponenten des Monitoring Blocks werden über einen Daemonprozess (htimacsd) gestartet. htimacsd startet dabei entsprechend der Hierarchiestruktur (siehe folgende Kapitel) des Systems die entsprechenden Komponenten. Der Daemon wird hierbei mittels Konfigurationsdateien und Kommandozeilenoptionen gesteuert. Um eine Übersicht der verfügbaren Optionen zu erhalten, kann htimacsd mit dem Argument --help gestartet werden. 3.1 Channels Die TIMaCS zugrunde liegende Kommunikationsschicht wird durch ein Publish / Subscribe System mit einem AMQP Server gebildet. Die Schnittstelle zu AMQP wird durch sogenannte Channels abstrahiert und optimiert. Befinden sich Publisher und Subscriber einer Nachricht auf demselben Knoten, so kann der aufwändige Transport über AMQP durch die Abstraktionsschicht zu einem lokalen Funktionsaufruf abgekürzt werden. Zur Adressierung wird ein sogenannter Topic verwendet, der sich wie folgt zusammensetzt: <nodename>.<source>.<metrikname> Beispiel: n101.gmond.load_one Die Verwendung von Wildcards ist möglich. So adressiert das folgende Beispiel z.b. alle Metriken, die von Knoten n101 bereitgestellt werden. n101.*.* Channel sind für die Kommunikation der einzelnen Komponenten essentiell und bilden daher das gemeinsame Bindeglied. Über Channels werden ausschließlich Metriken des oben beschriebenen Formates transportiert. Ein Channel wird durch eine URL spezifiziert, welche dem folgenden Schema folgt: Hierbei kann scheme die Werte amqp, local oder pika annehmen. AMQP benutzt im Normalfall die D5.2 Ergebnisse der Evaluierung v471 7/

8 Werte guest:guest für username und password. Im Wesentlichen werden zur Kommunikation über einen Channel die Funktionen publish(), subscribe() und notify_callback() benötigt. Diese bilden somit die Hauptschnittstelle zwischen den Komponenten im Monitoring Block. Über diese Schnittstelle werden Daten im eben beschriebenen Metrikformat ausgetauscht Tools Für Debug- und Testzwecke wurde ein Werkzeug (channel_dumper.py) entwickelt, welches erlaubt, die über einen Channel verschickten Metrikdaten zu monitoren. Der channel_dumper.py kann dabei auch in einem raw-modus benutzt werden, in dem nicht nur die Nutzlast, sondern die gesamte AMQP Nachricht ausgegeben wird. Usage: channel_dumper.py [options] Options: -h, --help show this help message and exit --channel=channel URL of channel to listen to --raw Dump raw AMQP messages --topic=topic topic to subscribe, default matches all topics Zusätzlich zu den Metrikdaten gibt der channel_dumper.py auch noch eine kurze Statistik über die Anzahl der empfangenen Metriken aus. 3.2 Importer Importer sammelt die Daten der unterschiedlichen Sensoren ein und stellt sie dem TIMaCS System in aufbereiteter Form als Metriken zur Verfügung. Es stehen Importerklassen für die Sensoren Ganglia, Nagios und Collectd zur Verfügung. Zur Konfiguration ist eine Datei mit den Definitionen der Importer auf der htimacsd Kommandozeile über die Option --conf-importer=path/file anzugeben. Hier eine Beispielkonfiguration, die jeweils eine Instanz der oben aufgeführten Importer startet. [importers] GangliaXMLMetric 1 = host_name=localhost:only_group=<false>:only_self=<false> NagiosStatusLog = SocketTxt 1 = port_or_path="10000" Schnittstellen zu anderen Komponenten Zum einen werden die Daten von den unterschiedlichen Sensoren gelesen, aufbereitet, d.h. in ein einheitliches Format (Metric) gepackt, und über die publish() Funktion anderen Komponenten zur Verfügung gestellt. D5.2 Ergebnisse der Evaluierung v471 8/

9 3.2.2 Testszenarien Die Funktion der Importer inklusive Schnittstelle wird unter anderem durch das in Kapitel 6 beschriebene Testszenario 1 getestet. 3.3 Aggregatoren Aggregatoren abstrahieren die gesammelten Monitoringdaten (Metrik) zur Bildung von Durchschnittswerten und Aggregaten. Abhängig vom Anwendungsfall können Metriken eines einzelnen Knotens, wie z.b. Berechnung der durchschnittlichen CPU Temperatur auf einem Knoten, oder einer Gruppe, z.b. Bildung der mittleren Last aller Gruppenknoten, konfiguriert werden. Aggregatoren werden in einer Datei konfiguriert, welche dem Daemon htimcsd über den Parameter --conf-aggregator=path/file übergeben wird Hostaggregator Ein Beispiel für einen einfachen Hostaggregator, welcher die drei Zustände OK, WARNING und CRITICAL annehmen kann. [aggregator_preset ThreeStateNumeric] base_class = HostSimpleStateAggregator state_ok = OK state_warning = WARNING state_critical = CRITICAL cond_ok = ((metric.value < arg_warn) and (arg_warn <= arg_crit)) or ((metric.value > arg_warn) and (arg_warn > arg_crit)) cond_warning = ((arg_warn <= metric.value < arg_crit) or (arg_crit < metric.value <= arg_warn)) cond_critical = ((metric.value >= arg_crit) and (arg_warn <= arg_crit)) or ((metric.value <= arg_crit) and (arg_warn > arg_crit)) max_age = Groupaggregator Beispiel für einen Gruppenaggregator, der aus der Metrik mit dem Namen load_one die Summe (Zeile 2) und den Durchschnitt (Zeile 3) der Knoten in der zugehörigen Gruppe bildet und als neue Metrik mit dem Namen grpsumc_load_one bzw. grpavgc_load_one veröffentlicht. [aggregate] load_one as grpsumc_load_one = GroupSumCycle:max_age=<30> load_one as grpavgc_load_one = GroupAvgCycle:max_age=<30> cpu_num as grpsumc_cpu_num = GroupSumCycle:max_age=<30> cpu_num as grpmax_cpu_num = GroupMax # demo for preset aggregator: warning if load_one exceeds 2, critical if it exceeds 5 load_one as overload_state = ThreeStateNumeric:arg_warn=<0.1>:arg_crit=<5.0> overload_state as grp_overload_state = GroupTristateCycle:max_age=<130> Schnittstellen zu anderen Komponenten Aggregatoren erhalten Metrikdaten aus dem Publish/Subscribe System indem sie bestimmte Topics D5.2 Ergebnisse der Evaluierung v471 9/

10 abonnieren. Die erhaltenen Metriken werden mit Hilfe der konfigurierten Methoden aggregiert und mit neuem Topic den entsprechenden Komponenten (i. Allg. auf Gruppenmaster Knoten) wieder über das Publish/Subscribe System zur Verfügung gestellt Testszenarien Aggregatoren sind die elementaren Komponenten, die Daten aus Gruppen entsprechend der Hierarchie an Gruppenmaster weiterleiten. Daher sind sie in nahezu allen Testszenarien involviert (von trivialen Hierarchien mit nur einem Level abgesehen). Die Funktionalität und Interaktion mit anderen Komponenten kann deshalb mit dem in Kapitel 6 beschriebenen Testszenario 2 sichergestellt werden. 3.4 Metrik Datenbank Die Aufgabe der Metrik Datenbank ist das Speichern der gesammelten Sensordaten im Metrikformat. Gleichzeitig bietet die Metrik Datenbank eine Abfrageschnittstelle, die es ermöglicht gespeicherte Metriken abzufragen (Query). Die resultierenden Metriken können entsprechend eines Zeitintervalls und eines Wertebereiches ( where-clause ) gefiltert werden. Die Metrik Datenbank kann als verteiltes System betrachtet werden. D.h. auf allen als Gruppenmaster (weitere Informationen dazu im Kapitel Hierarchie) aktiven Knoten wird von htimacsd automatisch eine Instanz erzeugt. Diese Instanz speichert jeweils die Daten der zugehörigen Gruppenknoten. Die Datenbank stellt eine RPC (Remote Procedure Call) Schnittstelle zur Verfügung welche zur Abfrage der Daten (Query) benutzt werden kann. Für diese Schnittstelle existiert ein Kommandozeilentool (Beschreibung im folgenden Kapitel). Es sind die folgenden Methoden via RPC registriert und können abgefragt werden. Die Ergebnisse eines RPC Aufrufs werden in Python Notation wiedergegeben, d.h. sie können über eine eval() Operation wieder in Objekte gewandelt werden. dbsetoffline(group_path): Setzt die Instanz der Datenbank in den offline Modus. Im offline Modus wird kein sog. Commit durchgeführt. Die Datenbank speichert jedoch die empfangenen Metriken im Speicher. Diese Funktion dient der Synchronisation zwischen zwei Datenbankinstanzen. dbsetonline(group_path): Setzt die Datenbank zurück in den online Modus und speichert alle Metriken, die gepuffert wurden. gethostnames(group_path): Listet alle Knotennamen, für die Metriken gespeichert sind. getlastmetricsbyhostname(group_path, host_name): Gibt ein Objekt vom Typ MetricSet zurück.ein MetricSet ist eine Liste, die Metriken eines bestimmten Knotens beinhaltet. getlastmetricbymetricname(group_path, host_name, metric_name): Gibt eine Metrik spezifiziert durch host_name und metric_name zurück. Diese Metrik enthält die aktuellsten (die letzten gespeicherten) Wert (value) und Zeit (time) Attribute. D5.2 Ergebnisse der Evaluierung v471 10/

11 getlastseen(group_path, host_name): Zeigt die last_seen und age Werte eines Knotens an. getmetricnames(group_path, host_name): Listet alle Namen (name) von Metriken, die für einen bestimmten Knoten (host_name) gespeichert sind. getrecordsbymetricname(group_path, host_name, metric_name, start_s, end_s, nsteps, step_s): Gibt eine Liste (list) zurück, die Objekte vom Typ Record beinhaltet. Jeder Record besitzt zwei Attribute: time_ns (Zeit in 10E-9 Sekunden) und value (Wert). Das Argument start_s in Sekunden gibt den frühesten Zeitpunkt an, ab dem Records geliefert werden. end_s (in Sekunden) gibt den Endzeitpunkt an. Mit step_s lässt sich die Anzahl der zurückgelieferten Objekte beeinflussen. getsummary(group_path, path): Gibt ein directory Listing eines Pfads innerhalb der serialisierten Datenbank aus. gettimeseriestype(group_path, host_name, metric_name): Gibt einen String zurück, der den Typ der Metrik beinhaltet. Dies kann RRD (nummerische Typen, wie Float, Integer,...) oder LOG (String) sein. findwheremetric(group_path, metric_name, metric_attr, condition, value, recurse=false): Gibt Knotennamen und Metriken zurück, für welche das angegebene Metrikattribut (metric_attr) die Bedingung (condition) für den Wert (value) erfüllt. Dies Methode ist auf Geschwindigkeit optimiert und durchsucht nur Metriken, die sich im Speicher befinden, d.h. Metriken, die bereits auf Festplatte gespeichert sind werden nicht berücksichtigt. Wenn recurse auf true gesetzt wird, dann werden alle auf einem niedrigeren Level liegenden und zum gegenwärtigen Ast gehörenden Datenbankinstanzen ebenfalls durchsucht. hierarchygroupnames(group_path): Hilfsfunktion, welche alle Gruppenpfade (group_path) in der Hierarchie auflistet, die Kinder des angegebenen group_path Parameters sind. Mit dieser Funktion ist es möglich sich den Hierarchiepfad von der Wurzel aus zu erschließen. getdbinstances(): Listet alle Datenbankinstanzen auf, die auf diesem Knoten aktiv sind. Gibt eine Liste von Gruppenpfaden (group_path) zurück, für die der Knoten ein Gruppenmaster ist. Abfragen der Datenbank, welche über die RPC Schnittstelle erfolgen, haben die allg. Form: python src/timacs/direct_rpc_client.py <node> <method> <group_path> Node entspricht dem Knotennamen. Method ist eine der obigen Methoden. Group_path spezifiziert den Gruppenpfad, für den Informationen angefragt werden. Sollte der angefragte Gruppenpfad nicht in der Datenbank des Knotens, an den der RPC gerichtet wurde, vorhanden sein, so leitet der Knoten diese Anfrage automatisch an den entsprechenden Knoten weiter. Informationen darüber, auf welchem Knoten die Metriken mit dem angefragten Gruppenpfad vorhanden sind, entnimmt der Knoten dem Hierarchieobjekt. D5.2 Ergebnisse der Evaluierung v471 11/

12 3.4.1 Tools Es existiert ein Kommandozeilentool mit dem alle registrierten RPCs aufgerufen werden können. Somit ist es auch möglich, die die Metrik Datenbank abzufragen. Hierzu ein Beispiel. python src/timacs/direct_rpc_client.py n102 getlastmetricsbyhostname /g1 [Metric(name='cpufreq', value= , source='collectd', host='n102', time= , type='cpufreq'), Metric(name='echo', value=3.0, source='collectd', host='deepsky', time= , type='absolute'), Metric(name='log', value='5', source='collectd', host='n102', time= , output='uc_update: Value too old: name = n102/echo-absolute/absolute-value; value time = ; last cache update = ;')] Schnittstellen zu anderen Komponenten Die Datenbank tritt aktiv nur als Datensenke (Subscriber) im System in Erscheinung und hat daher nur eine Schnittstelle zum Publish / Subscribe System. Zur Abfrage der Datenbank ist eine RPC (Remote Procedure Call) Schnittstelle implementiert, für die ein einfacher Client (direct_rpc_client.py) zur Verfügung steht. Diese Schnittstelle kann auch von anderen Komponenten benutzt werden Testszenarien Die Abfrage (Query) der Datenbank wird im Testszenario 3 getestet. 3.5 Hierarchie Die Hierarchie wird durch Knoten (hosts, compute nodes) und Gruppen gebildet. Gruppen können weitere Gruppen und Knoten beinhalten. Daraus kann ein baumartiger Graph gebildet werden. Die Kommunikation der Monitoringkomponenten über das Publish/Subscribe System erfolgt dann entlang der Kanten des Graphen. Die Position der Knoten innerhalb des Baumes wird durch deren Pfad von der Wurzel aus den über die jeweiligen Gruppen gebildet, deren Namen mit einem Schrägstrich / verkettet werden (in Anlehnung zu bekannten Dateisystempfaden). Das folgende Beispiel zeigt die Konfiguration der Hierarchie auf dem HLRS Entwicklungssystem, welches aus sechs Knoten besteht, die in zwei Gruppen mit Namen g1 und g2 aufgeteilt sind. Der Knoten n101 fungiert als Masterknoten auf dem obersten Level (dieses Level / diese Gruppe wird als universe oder abgekürzt / bezeichnet). D5.2 Ergebnisse der Evaluierung v471 12/

13 Abbildung 3: Aufteilung der Knoten mittels Gruppen, die eine Hierarchie bilden. Die Knoten sind in der Abbildung nicht nur mit ihrem Knotennamen, sondern mit der kompletten Gruppenpfadangabe bezeichnet. Diese Hierarchie muss beim Start von htimacsd mit der Option --hierarchy-cfg=<path/file> wie folgt angegeben werden. /n101 m:/ /g1/n102 m:/g1 /g1/n103 /g2/n104 m:/g2 /g2/n105 /g2/n106 Datenbankinstanzen und Aggregatoren werden von htimacsd automatisch anhand dieser Information auf allen Gruppenmastern, d.h.in diesem Fall auf n104, n102 und n101 gestartet. Sensordaten der Knoten n106, n105 werden dann in der Datenbank auf n104, Daten von n103 in der Datenbank auf n102 gespeichert. Die auf n102 und n104 laufenden Aggregatoren verwenden diese Metriken um wiederum Metriken zu erzeugen, die dann entlang der Kanten des Graphen D5.2 Ergebnisse der Evaluierung v471 13/

14 kommuniziert werden und in der Datenbank von n101 gespeichert werden. 3.6 Regressionstests Regressionstests analysieren den zeitlichen Verlauf von Monitoring-Daten. Durch den Vergleich mit früher gemessenen Werten können Performance-Verluste bemerkt werden, bevor es zu einem Ausfall der entsprechenden Komponente kommt. 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. TIMaCS unterscheidet zwischen Online- und Offline-Regressionstests. Erstere werden nach ihrer Konfiguration regelmäßig von TIMaCS durchgeführt und greifen bei der Analyse nur auf die Daten der jüngsten Vergangenheit zurück. Diese bekommen sie direkt aus dem Publish/Subscribe-System und sie behalten die Daten in ihrem Arbeitsspeicher. Nur wenn TIMaCS neu gestartet wird und der Arbeitsspeicher noch leer ist, holen sie sich die Daten aus der Datenbank um gleich beim ersten Eintreffen eines Monitoringwertes der gewählten Metrik einen Regressionstest durchführen zu können. Im Gegensatz dazu werden Offline-Regressionstests nur auf Anfrage durchgeführt. Diese holen sich die Daten aus der Metrik Datenbank. Der Offline-Regressionstest hat den Vorteil, dass man das Zeitintervall, über das sich der Regressionstest erstrecken soll, frei wählen kann und bietet sogar eine Mittelungsroutine, um bei einer großen Menge an Daten lediglich die Mittelwerte älterer Daten zu berücksichtigen. Je nach Komplexität der gewählten Regressionsanalyse kann dies die Berechnung beschleunigen. 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 TIMaCS, 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. Online-Regressionstests laufen nur auf Master-Knoten. Es werden nur die Metriken analysiert, die von Rechnern kommen, für die dieser Knoten der Master-Knoten ist. Läuft TIMaCS auf allen Master-Knoten, so wird jeder konfigurierte Regressionstest genau auf einem Knoten des Clusters durchgeführt werden. Ein Offline-Regressionstest berechnet die Regressionswerte für die gewählte Metrik über einen bestimmten Zeitraum, der beim Aufruf des Tests angegeben wird. 3.7 Compliancetests Um Compliance-Tests durchzuführen, müssen diese zunächst konfiguriert werden. Dazu ruft man D5.2 Ergebnisse der Evaluierung v471 14/

15 das Programm do_compliancetest auf dem Administratorknoten mit folgendem Befehl auf: python bin/do_compliancetest.py config-file-compliancetest config/settings_compliancetest.conf Dieses Programm bietet die Möglichkeit, sich eine Liste aller verfügbaren Sensoren und Benchmarks anzeigen zu lassen, damit man die auswählen kann, die man für den Compliancetest benötigt. Hat man einen Compliancetest konfiguriert, so kann man die Konfiguration speichern, um ihn auch nach einem Neustart des Programms wieder aufrufen oder ggf. ändern zu können. Man kann so viele verschiedene Compliancetests konfigurieren, wie man möchte. Jeder konfigurierte Compliancetest kann beliebig oft durchgeführt werden. Compliance-Tests werden jedoch nur auf Anfrage durchgeführt. Damit Compliance-Tests erfolgreich durchgeführt werden können, muss auf jedem TIMaCS- Knoten eine Regelmaschine und ein TIMaCS-Daemon laufen. Die Regelmaschine muss Regeln enthalten, die die vom Compliance-Test generierten Metriken auswerten und Events generieren, die eine boolsche Interpretation des Ergebnisses und eventuelle Fehlermeldungen enthalten. Der TIMaCS-Daemon startet ein Delegate, das die Kommandos zum Abfragen der Sensoren in Befehle umwandelt, sowie die Durchführung der Benchmarks startet. Ferner startet er auch einen Aggregator, der die Events der Regelmaschine einsammelt und als aggregierte Nachricht an den Administratorknoten sendet, auf dem wiederum ein Aggregator läuft, der aus den aggregierten Nachrichten der TIMaCS-Knoten ein Gesamtergebnis des Compliance-Tests generiert. Zusätzlich zu den erwähnten Komponenten wurde ein Timer implementiert. Dieser ist nötig, um zu wissen, wann ein Compliance-Test beendet ist. Der Timer tritt an zwei Stellen in Erscheinung. Zum einen wird bei jeder Sensorabfrage und jeder Benchmarkdurchführung ein Timer gestartet. Liegt bei Ablauf des Timers kein Ergebnis des betreffenden Sensors oder Benchmarks vor, so wird die Abfrage/Durchführung abgebrochen und der daraufhin generierten Metrik wird als Fehlermeldung mitgegeben, dass der Timeout erreicht wurde bevor ein Ergebnis vorlag. Die Länge des Timeouts lässt sich für jeden Sensor oder Benchmark eines Compliance-Tests separat konfigurieren. Des Weiteren ist der Aggregator auf dem Administratorknoten mit einem Timer ausgestattet. Dessen Timer läuft mindestens so lange wie der längste Timer der von diesem Compliance-Test abgefragten Sensoren/durchgeführten Benchmarks plus eine konfigurierbare Zeitdauer. Liegen nach Ablauf des Timers nicht von allen involvierten TIMaCS-Knoten aggregierte Ergebnisse vor, so wird das bis zu diesem Zeitpunkt vorliegende Ergebnis dem Nutzer angezeigt sowie die Nachricht, welche Knoten bis jetzt kein Ergebnis gesendet haben. 3.8 Filter & Event Generator Der Filter & Event Generator filtert und evaluiert die gesammelten Monitoring-Daten um festzustellen, ob sie auf einen Fehler hindeuten. Im Falle einer Fehlererkennung, wird ein Event generiert und an den Management Block weitergeleitet. Der Filter & Event Generator ist durch eine Regelmaschine realisiert, die entsprechend der konfigurierten Regeln auf eingehende Nachrichten reagiert. Zum Testen der Regelmaschine existiert ein Testframework, in das eigene Tests einfach integriert werden können. Jeder Test wird dabei D5.2 Ergebnisse der Evaluierung v471 15/

16 durch eine Nachricht initialisiert, und es wird überprüft, ob innerhalb einer konfigurierten Zeitspanne eine Systemantwort, die wiederum als Nachricht vorliegen muss, eintrifft. Wie die erwartete Antwort aussehen muss, wird in den jeweiligen Tests formuliert. Getestet wird damit: Die Basisfunktionalität der Regelmaschine: Die Bausteine, die zur Formulierung der Regeln zur Verfügung stehen, werden in Tests auf korrekte Funktionalität überprüft. Die Performance: Durch das Testframework wird sichergestellt, dass das erwartete Ergebnis (wiederum eine Nachricht) innerhalb der im Test konfigurierten Zeit erreicht wird. Die Funktionalität der konfigurierten Regeln: Diese Tests prüfen nicht die Regelmaschine an sich, sondern stellen sicher, dass die konfigurierten Regeln sich wie erwartet verhalten. Dadurch wird nicht nur die Korrektheit der Konfiguration gesichert, die Tests dienen auch der Dokumentation der Regeln, weil in ihnen sowohl der erwartete Input als auch das Ergebnis beschrieben wird. In dem Testframework wird für jeden Test eine Triggernachricht an die Regelmaschine geschickt. Diese Nachricht initialisiert das Testframework und beschreibt außerdem, wie die erwartete Ergebnisnachricht aussehen soll und bis wann sie spätestens eintreffen muss. Wenn diese eintrifft, wird die im Test konfigurierte Erfolgsbedingung ausgewertet und entsprechend eine Erfolgs- oder Fehlernachricht als Testergebnis erzeugt. Falls die Antwort zu spät kommt oder ausbleibt, wird ebenfalls eine entsprechende Fehlernachricht als Testresultat verschickt. So wird sichergestellt, dass auch das Ausbleiben einer Antwort als Fehler erkannt wird. Durch dieses allgemeine Testframework ist es auch möglich, Tests über mehrere Regelmaschinen hinweg auszuführen. So kann z.b. durchaus in einem Test, der auf einer bestimmten Regelmaschine angestoßen wird, das erwartete Ergebnis von einer anderen Regelmaschine sichergestellt werden. Angestoßen werden die Tests entweder einzeln oder gebündelt aus dem graphischen Editor. Die Testresultate werden in der graphischen Oberfläche tabellarisch dargestellt Schnittstellen zu anderen Komponenten Der Filter & Event Generator ist durch Regeln in der Regelmaschine umgesetzt, damit sind die Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zum Filter & Event Generator stehen die Monitoringkomponente, die Regressions- und Compliancetests und die Policy Engine. Die Funktionalität der konfigurierten Regeln wird mit dem Testframework getestet. Da das Zusammenwirken mit den anderen Komponenten wiederum durch Regeln beschrieben ist, kann dadurch auch die komplette Interaktion mit den Partnerkomponenten getestet werden Testszenarien Im Moment existieren die folgenden Tests: D5.2 Ergebnisse der Evaluierung v471 16/

17 Funktionalität der Regelmaschine: sendmessagetest: Test des Elements SendMessage zur Regelerstellung configwritertest: Test des Elements ConfigurationWriter zur Regelerstellung iteratortest: Test der Elemente Container Store Reader und Container Store Writer zur Regelerstellung typeconversiontest: Stellt sicher, dass innerhalb der Regelmaschine die Typkonvertierung (z.b. String->Float) korrekt funktioniert Spezifische Regeltests: normalizetest: Test, der die Funktionalität der Normierungsregel für eingehende Nagiosnachrichten prüft. 4 Management Block Die Aufgabe des Management-Blocks ist es, Entscheidungen zur Behandlung von Fehlern, welche durch Events identifiziert werden, zu treffen. Empfängt der Management-Block ein Event, das auf einen Fehler hindeutet, trifft er eine Entscheidung, wie der Fehler behandelt werden soll. Die Entscheidungen werden dann in Kommandos umgewandelt und auf Ressourcen mittels Delegates ausgeführt. Die Umsetzung der Komponenten des Management-Blocks erfolgt in Abhängigkeit vom Hierarchie-Level mit Hilfe der Rule-Engine (Level 1) und der Policy-Engine (Level 2 und höher). Die Rule-Engine ist auf Level 1 angesiedelt und ist zuständig für das Ausführen einfacher, meistens auf Schwellwertüberwachung basierenden Regeln. Sie besitzt eine vereinfachte Form des Event/Data-Handlers, der nur für das Empfangen und Weiterleiten der Nachrichten (Events) zuständig ist, und des Decision-Makers, der auf Basis vordefinierter Regeln die Auswertung der empfangenen Nachrichten (Events) durchführt und Entscheidungen in Form von Kommando-Nachrichten trifft. Die Policy-Engine ist auf Level 2 und höher angesiedelt und ist für die Evaluation komplexer Events oder Reports zuständig, die eine Auswertung der komplexen System- Zustände und Abfrage der semantischen Datenbanken erfordern. Sie besitzt den vollen Umfang der in [D1.3] Abschnitt 3.3 beschriebenen Funktionalität des Management-Blocks. 4.1 Rule-Engine Der Definition der Testszenarien und der Test der Rule-Engine erfolgt in der gleichen Weise wie in Kapitel 3.8 beschreiben, da der Filter&Event-Generator mit Hilfe der Rule-Engine umgesetzt wird. 4.2 Policy-Engine Der Test der Policy-Engine erfolgt durch Vorbelegung der Wissensbasis mit vordefinierten Werten D5.2 Ergebnisse der Evaluierung v471 17/

18 und durch Erzeugung der zu verarbeitenden Event-Nachrichten, die eine Reaktion des Managementblocks in Form einer Aktion-Nachricht oder Event-Nachricht bewirkten. Damit kann getestet werden: Die Funktionalität der Policy-Engine: Zum Testen der Funktionalität der Policy-Engine sind mehrere Testfunktionen in die Policy-Engine eingebaut, die die Wissensbasis mit den vordefinierten Zustands-Werten der überwachten Ressourcen belegen und vordefinierte Event-Nachrichten erzeugen. Die erzeugten Event-Nachrichten werden von allen Komponenten der Policy-Engine verarbeitet. Dabei werden in jedem Verarbeitungsschritt die Zwischenergebnisse angezeigt, welche eine Übersicht über Inhalt und Änderung der Wissensbasis sowie die getroffenen Entscheidungen liefern. Da jeder Entscheidungsschritt mit den erwarteten Ergebnissen verglichen werden kann, lässt sich damit auch die Funktionalität der konfigurierten Policies und Regeln überprüfen. Als Ergebnis der Entscheidung des Management Blocks wird eine Nachricht generiert und am Bildschirm ausgegeben, welche mit der erwarteten Soll-Nachricht verglichen werden kann. Funktionalität der Schnittstellen: Zum Testen der Funktionalität der Schnittstellen, welche die Policy-Engine an den Message-Bus anbindet, werden Event-Nachrichten erzeugt und über den Message-Bus versendet. Die Policy-Engine verarbeitet diese Nachrichten in der oben erwähnten Weise und erzeugt Antwort-Nachrichten, welche über den Message- Busversendet werden. Die versendeten Nachrichten werden mit einem Client ausgegeben. Die Performance: Zur Messung der Verarbeitungsgeschwindigkeit der Policy-Engine kann die Zeit pro Verarbeitung einer Nachricht, von der Einspeisung der Nachricht bis zur Erzeugung der Ergebnisse, gestoppt werden. Hierzu ist in der Policy-Engine eine Zeitstopp- Funktion eingebaut. Des weiteren kann auch die Zeit für die Verarbeitung mehrerer Nachrichten gemessen werden Testszenarien Zustandsänderung, -propagierung und Erzeugung der Kommando-Nachricht Die Wissensbasis der Policy-Engine wird zunächst mit den modellierten Abhängigkeiten zwischen den unterschiedlichen Ressourcen/Services als auch mit den vordefinierten Zustands-Werten belegt. Anschließend wird eine Test-Event-Nachricht in den Message-Bus eingespeist, die einen kritischen Fehler-Event in einer der abhängigen Ressource enthält. In jedem Verarbeitungsschritt wird die Auswirkung des Events auf die abhängigen Ressourcen und damit auf den gesamten Zustand der Granularität (Knoten, Gruppe, Cluster...) überwacht. Das Ergebnis wird mit den erwarteten Werten verglichen. Schließlich erzeugt der Management Block eine neue Event-Nachricht, die eine Änderung des Gesamtzustands an die nächst höhere Management Block signalisiert. Gleichzeitig werden Kommando-Nachrichten erzeugt und an betroffene Delegates verschickt. Im zweiten Durchlauf wird eine neue Test-Event-Nachricht erzeugt, die zwar eine Zustandsänderung der kritischen Ressource enthält, jedoch keine Änderung des Gesamt-Zustands bewirkt. Damit soll die Event-Unterdrückung des Systems getestet werden. Die Ausführung der Testszenarien für die Policy-Engine ist in Kapitel 5.7 beschreiben. D5.2 Ergebnisse der Evaluierung v471 18/

19 4.2.2 Schnittstellen zu anderen Komponenten Durch die Anbindung der Policy-Engine an den Message-Bus sind Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zur Policy-Engine stehen die Rule-Engine, Filter&Event-Generator, die Regressions- und Compliancetests sie erzeugen Event-Nachrichten die von der Policy-Engine weiterverarbeitet werden. Der Delegate (siehe Kapitel 4.3) konsumiert die von der Policy-Engine erzeugten Kommando-Nachrichten und ist für das Ausführen der Entscheidungen zuständig. Wie bereits in Kapitel erwähnt, kann das Zusammenwirken mit allen Komponenten durch Regeln in der Rule-Engine beschrieben werden, dadurch kann auch die komplette Interaktion mit allen Partnerkomponenten getestet werden. 4.3 Delegate Der Delegate ist die Schnittstelle zwischen Management-Block und den verwalteten Systemen bzw. Komponenten zur Verwaltung der Systeme. Aus diesem Grund müssen beide Seiten des Delegate, also die Kommunikation mit den übrigen Komponenten des Management-Blocks und die Kommunikation mit den verwalteten Systemen, getestet werden. Für den Delegate zum Management virtueller Maschinen existieren sowohl ein spezieller Test- Client, der den Management-Block simuliert, als auch ein Dummy des eigentlichen vmmanager. Auf diese Weise können beide Seiten individuell getestet werden. Der Test-Client kann die benötigten Nachrichten erzeugen, über die sämtliche Aktionen der Komponente zur Verwaltung virtueller Maschinen ausgelöst werden können. Der Dummy simuliert den echten vmmanager und ermöglicht ein sehr schnelles Testen des Zusammenspiels mit den übrigen Komponenten, da keine Verzögerung durch das tatsächliche Ausführen der Aktionen auftritt. Eine Untersuchung der Performance des Delegate ist aufgrund seiner Funktion als reiner Vermittler nicht notwendig Schnittstellen zu anderen Komponenten Ein Delegate ist an den Nachrichtenbus angeschlossen. Damit sind die Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zum Delegate steht lediglich die Policy Engine. Ein Test des Delegate kann folglich dadurch erfolgen, dass die Policy Engine Nachrichten an den Delegate schickt, die zur Ausführung von Kommandos führen. Die Schnittstelle zur Policy Engine kann weiterhin mit dem Test-Client getestet werden Testszenarien Es bietet sich an, den Delegate zum Management virtueller Maschinen zusammen mit dem vmmanager zu testen. Ein möglicher Testablauf ist in Testszenario 6 beschrieben. D5.2 Ergebnisse der Evaluierung v471 19/

20 4.4 vmmanager Komponente zur dynamischen Partitionierung Der vmmanager ist für die dynamische Partitionierung des Systems zuständig. Er ist indirekt über den zugehörigen Delegate an das Gesamtsystem angebunden. Die Kommunikation zwischen Delegate und vmmanager erfolgt hierbei über XML-RPC. Für den vmmanager existiert ein Client, mit dem die komplette Funktionalität getestet werden kann. Der Client kommuniziert über die XML-RPC Schnittstelle direkt mit dem vmmanager. Dieser Client entspricht in seiner Verwendung dem Test-Client des Delegate, so dass ein Test relativ einfach möglich ist. Da die Geschwindigkeit des vmmanager zu großen Teilen vom eingesetzten System abhängig ist (gemeinsamer Speicher vs. lokaler Speicher, Netzwerkbandbreite), ist ein Geschwindigkeitstest des vmmanager schwierig, da die (leicht zu messende) Gesamtausführungszeit einer Aktion nicht eindeutig dem vmmanager bzw. dem verwendeten System zugeordnet werden kann. Weiterhin beträgt die Zeit, die zum Ausführen von vmmanager- Aktionen (z.b. Migration von virtuellen Maschinen) benötigt wird, in der Regel ein vielfaches von der Zeit, die intern zum Veranlassen der Aktion benötigt wird Schnittstellen zu anderen Komponenten Der vmmanager ist nicht an den Nachrichtenbus angeschlossen. Er besitzt eine XML-RPC Schnittstelle, über die die angebotenen Aktionen ausgelöst werden können. Die Anbindung an den Nachrichtenbus erfolgt über den zugehörigen Delegate. In direktem Kontakt zum vmmanager steht lediglich der Delegate. Ein Test des vmmanager sollte daher in Kombination mit dem zugehörigen Delegate erfolgen Testszenarien Es bietet sich an, den vmmanager zusammen mit dem Delegate zum Management virtueller Maschinen zu Testen. Ein möglicher Testablauf ist in Testszenario 6 beschrieben. 5 Integrationstests der Prototypkomponenten Ziel der Evaluierung des Gesamtsystems ist es die Übereinstimmung des TIMaCS Prototypen mit den in [D1.1] beschriebenen Use-Cases darzulegen. Hierzu wurden einige Testszenarien und Testfälle definiert, welche im folgenden Abschnitt zu finden sind. Die Tests wurden so ausgelegt, dass alle vorhandenen Komponenten und Schnittstellen in den Tests eingebunden sind. Da die unterschiedlichen Komponenten des Gesamtsystems von unterschiedlichen Projektpartnern entwickelt wurden, ist das besondere Augenmerk bei den Tests auf die richtige Bereitstellung der Daten an den jeweiligen Schnittstellen gerichtet. 5.1 Testszenario 1: Importer - Channel - Metrik Datenbanken Der erste unmittelbar zusammenhängende Datenfluss erstreckt sich von der Datenquelle (dem Sensor), welche vom entsprechenden Importer ausgelesen wird über die Erstellung eines D5.2 Ergebnisse der Evaluierung v471 20/

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

D5.3 Aktualisierte Ergebnisse der Evaluierung

D5.3 Aktualisierte Ergebnisse der Evaluierung D5.3 Aktualisierte Ergebnisse der Evaluierung Arbeitspaket/Task: AP 5 Task 5.3 Fälligkeit: M36 Abgabetermin: 31.12.11 Verantwortlich: NEC Versionsnummer/Status: 288 Final Autoren: Jeutter, Andreas Focht,

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

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

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

BS1000 messenger to web server

BS1000 messenger to web server BS1000 Messenger Web Server 1/5 Juni 15, 2010 BS1000 messenger to web server Einführung Die BS1000 LAN Basisstation für das Arexx-Multilogger System stellt einen Messenger-Dienst zur Verfügung, womit man

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

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

D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge Arbeitspaket/Task: AP 2 Task 2.2 Fälligkeit: M12 Abgabetermin: 30.04.10 Verantwortlich: Versionsnummer/Status: Autoren: ZIH Koudela,

Mehr

Workbooster File Exchanger Command Line Tool

Workbooster File Exchanger Command Line Tool Thema Technische Benutzerdokumentation - WBFileExchanger Workbooster File Exchanger Command Line Tool Letzte Anpassung 18. Januar 2014 Status / Version Finale Version - V 1.1 Summary Erstellung Diese technische

Mehr

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland DOKUMENT: TYP: ERSTELLT VON: Manual nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION: STAND: 9.x 23. September 2015 Inhaltsverzeichnis 1 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4

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

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01 Installation, Konfiguration, Verwendung Version 1.01 Seite 2 von 20 OPC-Server VM OPC Revision Version Erstellt am Versionsnummer Bemerkung 1.00 26.07.2013 Erstellung 1.01 05.11.2013 2.14 - Reiter der

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

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe.

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. Change Log: DBB/LX Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. 1. Version 4.5.0.1243 1. AF: Das Tool Datenbank neu aufbauen wurde ergänzt. Damit können Datenbanken,

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

Wartungsfreie Logsicherung mittels ontape

Wartungsfreie Logsicherung mittels ontape Wartungsfreie Logsicherung mittels ontape Edgar Riegger, IBM Deutschland GmbH August 2008 Getreu dem Motto: Cheetah - Expanding the Administration Free Zone wird im IBM Informix Dynamic Server (IDS) seit

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

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation MySQL-Job-Automation Managed User Jobs JOB SCHEDULER Dokumentation Juli 2005 Software- und Organisations-Service GmbH Giesebrechtstr. 15 D-10629 Berlin Telefon (030) 86 47 90-0 Telefax (030) 861 33 35

Mehr

ERANGER 3.5.4 (FREEBSD) ERANGER 3.6.4 (RHEL) Release Announcement

ERANGER 3.5.4 (FREEBSD) ERANGER 3.6.4 (RHEL) Release Announcement ERANGER 3.5.4 (FREEBSD) ERANGER 3.6.4 (RHEL) Release Announcement 6. November 2014 2014 Junisphere Systems AG Junisphere Systems AG Glatt Tower, P.O. Box CH-8301 Glattzentrum Tel. +41 (0)43 443 31 80 info@junisphere.net

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

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Elektronische Vollmachten - Demonstrator

Elektronische Vollmachten - Demonstrator www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI

Mehr

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration IBM SPSS Entity Analytics - Erweiterte Konfiguration Einführung Die vorgesehene Zielgruppe für dieses Handbuch sind Systemadministratoren, die IBM SPSS Entity Analytics (EA) für die Ausführung in einer

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

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

IBM SPSS Collaboration and Deployment Services (C&DS) version 7

IBM SPSS Collaboration and Deployment Services (C&DS) version 7 Dieses Handbuch richtet sich an Systemadministratoren, die IBM SPSS Modeler Entity Analytics (EA) für die Ausführung mit einem der folgenden Produkte konfigurieren: IBM SPSS Collaboration and Deployment

Mehr

OPC-Server Siemens TRPort

OPC-Server Siemens TRPort Installation, Konfiguration, Verwendung Version 1.00 Seite 2 von 20 OPC-Server Siemens TRPort Revision Version Erstellt am Versionsnummer Bemerkung 1.00 11.06.2014 Erstellung Seite 3 von 20 Seite 4 von

Mehr

MGE Datenanbindung in GeoMedia

MGE Datenanbindung in GeoMedia TIPPS & TRICKS MGE Datenanbindung in GeoMedia 10. September 2002 / AHU INTERGRAPH (Schweiz) AG Neumattstrasse 24, CH 8953 Dietikon Tel: 043 322 46 46 Fax: 043 322 46 10 HOTLINE: Telefon: 043 322 46 00

Mehr

Grundlagen DNS 1/5. DNS (Domain Name System)

Grundlagen DNS 1/5. DNS (Domain Name System) Grundlagen DNS 1/5 DNS (Domain Name System) Weltweit gibt es 13 zentrale DNS-Server (Root-Nameserver), auf denen die verschiedenen Domains abgelegt sind. Der Domönennamensraum bzw. das Domain Name Space

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

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

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

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München Time CGI Version 1.5 Stand 04.12.2013 TimeMachine Dokument: time.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor Version Datum Kommentar

Mehr

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP Inhaltsverzeichnis Dokumenteninformation... 2 Voraussetzungen... 2 Einschränkungen... 2 Installation von ESTOS Metadir...

Mehr

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

Archive / Backup System für OpenVMS

Archive / Backup System für OpenVMS Archive / Backup System für OpenVMS DECUS Symposium 2002 Bonn Vortrag-Nr. 3C04 Günther Fröhlin Compaq Computer Corporation Colorado Springs, USA 1 Highlights V4.0 Auslieferung Januar 2002 Hauptversion

Mehr

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 E-Mail: sales@softvision.de Web: www.softvision.de Inhaltsverzeichnis

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

Technische Dokumentation SEPPmail Outlook Add-In v1.5.3

Technische Dokumentation SEPPmail Outlook Add-In v1.5.3 Technische Dokumentation SEPPmail Outlook Add-In v1.5.3 In diesem Dokument wird dargelegt, wie das SEPPmail Outlook Add-in funktioniert, und welche Einstellungen vorgenommen werden können. Seite 2 Inhalt

Mehr

Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle

Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle Wie funktioniert die Zeitsynchronisation in Windows Netzwerken: http://support.microsoft.com/kb/816042 MSDN Blog

Mehr

4 Aufruf des Servers, Kommandozeilen-Optionen

4 Aufruf des Servers, Kommandozeilen-Optionen 4 Aufruf des Servers, Kommandozeilen-Optionen 4.1 Einführung In diesem Abschnitt lernen Sie verschiedene Methoden zum Start des Apache-Servers, einige der wichtigsten Kommandozeilen-Optionen und Methoden

Mehr

RIWA NetUpdater Tool für automatische Daten- und Softwareupdates

RIWA NetUpdater Tool für automatische Daten- und Softwareupdates RIWA NetUpdater Tool für automatische Daten- und Softwareupdates Grundlegendes... 1 Ausführbare Dateien und Betriebsmodi... 2 netupdater.exe... 2 netstart.exe... 2 netconfig.exe... 2 nethash.exe... 2 Verzeichnisse...

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

System- und Netzwerkmanagement

System- und Netzwerkmanagement System- und Netzwerkmanagement Protokollierung mit Syslog-NG Markus Müller (11043150) Sven Nissel (11042398) Roman Pyro (11042289) Christian Fehmer (11042419) Versuchsaufbau - Übersicht Syslog Konfiguration

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

DHCP und dynamischer Update eines DNS

DHCP und dynamischer Update eines DNS DHCP und dynamischer Update eines DNS Als Voraussetzung für diese Dokumentation wird eine funktionierende Konfiguration eines DNS Servers, mit den entsprechenden Zonefiles angenommen. Die hier verwendete

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

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

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

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

MySQL Community Server 5.1 Installationsbeispiel

MySQL Community Server 5.1 Installationsbeispiel MySQL Community Server 5.1 Installationsbeispiel Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der untermstrich-datenbank

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

Kurzbeschreibung PC-Software für das Gerät URO-2050

Kurzbeschreibung PC-Software für das Gerät URO-2050 Kurzbeschreibung PC-Software für das Gerät URO-2050 1 Einleitung 1.1 Allgemeines Das Programm kann zum Verwalten der durchgeführten Untersuchungen mit dem Gerät URO-2050 benutzt werden. Es funktioniert

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

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

Tec Local 4.0 Installationsanleitung: Besteller & Mehrplatz (Client) TecLocal 4.0. Installationsanleitung: Besteller-Modus bei Mehrplatzinstallation

Tec Local 4.0 Installationsanleitung: Besteller & Mehrplatz (Client) TecLocal 4.0. Installationsanleitung: Besteller-Modus bei Mehrplatzinstallation Tec Local 4.0 Installationsanleitung: Besteller & Mehrplatz (Client) TecLocal 4.0 Installationsanleitung: Besteller-Modus bei Mehrplatzinstallation (Teil II - Client) Version: 1.0 Autor: TecCom Solution

Mehr

Einleitung. Storage-Monitoring mit Nagios

Einleitung. Storage-Monitoring mit Nagios Einleitung Storage-Monitoring mit Nagios Kapitel 01: Einleitung Überblick... 01.01 NetApp - Network Appliance... 01.03 Data ONTAP & WAFL... 01.04 Interner Aufbau... 01.05 Überblick Storage-Monitoring mit

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

PDF-AS Webanwendung Dokumentation

PDF-AS Webanwendung Dokumentation Dokumentation PDF-AS Webanwendung Dokumentation Dokumentation zur PDF-AS Webanwendung ab Version 4 Version 0.5, 10.10.2014 Andreas Fitzek andreas.fitzek@egiz.gv.at Tobias Kellner tobias.kellner@egiz.gv.at

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

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

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

Benutzerhandbuch für FaxClient für HylaFAX

Benutzerhandbuch für FaxClient für HylaFAX Benutzerhandbuch für FaxClient für HylaFAX Vielen Dank, daß Sie entschlossen haben, dieses kleine Handbuch zu lesen. Es wird Sie bei der Installation und Benutzung des FaxClients für HylaFAX unterstützen.

Mehr

System Konfiguration: config.xml

System Konfiguration: config.xml System Konfiguration: config.xml Bruno Blumenthal und Roger Meyer 11. Dezember 2003 Zusammenfassung Dieser Konfigurations Guide beschreibt die Hauptkonfigurations Datei config.xml. Es werden alle Elemente

Mehr

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH Tipps & Tricks Neues, Nützliches und Praktisches Christian Dahmen con terra GmbH 1 Qualitätssicherung von Geodaten Qualitätssicherung von Geodaten Mit FME lassen sich einfache und komplexe Prüfroutinen

Mehr

DSLinux Skriptbasierte Inventarisierung für Linux

DSLinux Skriptbasierte Inventarisierung für Linux DSLinux Skriptbasierte Inventarisierung für Linux www.docusnap.com TITEL DSLinux AUTOR Docusnap Consulting DATUM 21.04.2015 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen, Verwertung

Mehr

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein:

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: 7. Intrusion Prevention System 7.1 Einleitung Sie konfigurieren das Intrusion Prevention System um das Netzwerk vor Angriffen zu schützen. Grundsätzlich soll nicht jeder TFTP Datenverkehr blockiert werden,

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Neue Technologien effizient nutzen Ehningen, 3. Juli 2014 Rodney Krick rk@aformatik.de aformatik Training & Consulting GmbH & Co. KG

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

HVS32 Datenbank Archivierungs Dienst

HVS32 Datenbank Archivierungs Dienst HVS32 Datenbank Archivierungs Dienst Features: HVS32 - vollautomatisierte, zeitgesteuerte Datenbank Archivierung Der HVS32- Datenbank Archivierungs Dienst bietet die Möglichkeit zu bestimmen, wann und

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

3 Richtlinienbasierte Verwaltung und Multi-Server- Administration

3 Richtlinienbasierte Verwaltung und Multi-Server- Administration Richtlinienbasierte Verwaltung und Multi-Server-Administration 3 Richtlinienbasierte Verwaltung und Multi-Server- Administration SQL Server Management Studio bietet eine Reihe von Unterstützungsmöglichkeiten,

Mehr

Manueller Import von Dateien

Manueller Import von Dateien PhPepperShop Enterprise Datum: 22. Mai 2015 Version: 1.2 Manueller Import von Dateien Importe/Exporte Business Connector Glarotech GmbH Inhaltsverzeichnis 1. Manueller Import von Dateien im Caller...3

Mehr

Wie benutzt der NetWorker Remote Procedure Calls (RPC)?

Wie benutzt der NetWorker Remote Procedure Calls (RPC)? NetWorker - Allgemein Tip 298, Seite 1/7 Wie benutzt der NetWorker Remote Procedure Calls (RPC)? Der NetWorker - wie jede andere Client/Server (Backup) Software - benutzt immer diese zwei grundlegenden

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Security. Stefan Dahler. 6. Zone Defense. 6.1 Einleitung

Security. Stefan Dahler. 6. Zone Defense. 6.1 Einleitung 6. Zone Defense 6.1 Einleitung Im Folgenden wird die Konfiguration von Zone Defense gezeigt. Sie verwenden einen Rechner für die Administration, den anderen für Ihre Tests. In der Firewall können Sie entweder

Mehr

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder FROSCON, 23.8.2009 Dr. Michael Schwartzkopff HA Firewall mit fwbuilder, Seite 1 Eine einfache Firewall Eine einfache Firewall mit Linux

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

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

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

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0 Leistungsbeschreibung PHOENIX Archiv Oktober 2014 Version 1.0 PHOENIX Archiv Mit PHOENIX Archiv werden Dokumente aus beliebigen Anwendungen dauerhaft, sicher und gesetzeskonform archiviert. PHOENIX Archiv

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion independit Integrative Technologies GmbH Bergstraße 6 D 86529 Schrobenhausen BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion Dieter Stubler Ronald Jeninga July 30,

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

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

telpho10 Update 2.1.6

telpho10 Update 2.1.6 telpho10 Update 2.1.6 Datum: 31.03.2011 NEUERUNGEN... 2 STANDORTANZEIGE GESPERRTER IP ADRESSEN... 2 NEUE SEITE SYSTEM STATUS IN DER ADMINISTRATOR WEB-GUI... 2 NEUE SEITE SNOM FIRMWARE IN DER ADMINISTRATOR

Mehr

Tivoli Monitoring for Databases (ITM) Resource Model Tivoli Enterprise Console (TEC) Zusammenfassung. IBM Tivoli. Marcel Brückner

Tivoli Monitoring for Databases (ITM) Resource Model Tivoli Enterprise Console (TEC) Zusammenfassung. IBM Tivoli. Marcel Brückner 1 Tivoli Monitoring for Databases (ITM) Grundidee Umsetzung 2 3 Aufbau Kombination mit ITM Rule Sets 4 Grundidee Umsetzung 1 Tivoli Monitoring for Databases (ITM) Grundidee Umsetzung 2 3 Aufbau Kombination

Mehr

SemTalk Services. SemTalk UserMeeting 29.10.2010

SemTalk Services. SemTalk UserMeeting 29.10.2010 SemTalk Services SemTalk UserMeeting 29.10.2010 Problemstellung Immer mehr Anwender nutzen SemTalk in Verbindung mit SharePoint Mehr Visio Dokumente Viele Dokumente mit jeweils wenigen Seiten, aber starker

Mehr

Daten-Ex- und Import mit Oracle und PostgreSQL

Daten-Ex- und Import mit Oracle und PostgreSQL Daten-Ex- und Import mit Oracle und PostgreSQL Holger Jakobs bibjah@bg.bib.de 2004-09-07 Inhaltsverzeichnis 1 Grund für Daten-Im- und -Exporte 1 2 Werkzeuge 1 2.1 Export mit pg_dump von PostgreSQL.....................

Mehr

Wichtige Kommandozeilenbefehle & Handhabung des GUI Tivoli Storage Manager

Wichtige Kommandozeilenbefehle & Handhabung des GUI Tivoli Storage Manager 11. März 2009, Version 1.0 Verwaltungsdirektion Informatikdienste Wichtige Kommandozeilenbefehle & Handhabung des I n haltsverzeichnis...1 I nformationen zu diesem Dokument... 1 Starten der Programme...

Mehr

Apache JMeter. Arbeit von Bundi Beat, 6Ie. Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C.

Apache JMeter. Arbeit von Bundi Beat, 6Ie. Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C. Apache JMeter Arbeit von Bundi Beat, 6Ie Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C.Nicola Windisch, 3. Juli 2003 Inhaltsverzeichnis 1. Was ist JMeter?...3

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder Programmieren in PASCAL Bäume 1 1. Baumstrukturen Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder 1. die leere Struktur oder 2. ein Knoten vom Typ Element

Mehr