Dezentralisiertes Systemmanagement verteilter eingebetteter Systeme Dipl. Inf. Camilo Lara 19.05.05 Universität Leipzig
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 2
Motivation Steigerung der Komplexität der eingebetteten Systeme Hardwarekomplexität Mehrere Mbyte RAM Leistungsstarke Prozessoren > 100 MIPS Rekonfigurierbare Hardware FPGA > 1.000.000 System Gates Softwarekomplexität Multitasking Betriebssystem Zeitkritische Anwendungen Vernetzte eingebettete Systeme Komplexes Konfigurations- und Rekonfigurations-Management Transaktionsbasierte Zustellung von Informationen z.b. 500 Transaktionen/Sek. 3
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 4
Ziele Was soll durch das Management erreicht werden? Verwaltung verteilter und vernetzter eingebetteter Systeme mit minimalem Aufwand durch: Objektorientierter Ansatz zur Beherrschung der Komplexität Überwachung von kritischen Systemkomponenten Automatische Reaktion auf erkannte Fehler Automatische Rekonfiguration von Hardware und Software Gewährleistung von Quality of Service Informationsmanagement (Statistik) 5
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 6
Systemeigenschaften Basiert auf vorhandenen etablierten Standards Interoperabilität und Herstellerunabhängigkeit XML (Extensible Markup Language) CIM (Common Information Model) Objektorientierte Modellierung des gesamten Systems z.b. Firmen, Abteilungen, Maschinen, Tasks, Rules, etc. Reduzierung der Management Komplexität Organisation über Vererbungshierarchien Einfache Modellierung deren Beziehungen Wiederverwendbarkeit Dezentralität Dezentrale Modellierung Dezentrales Management Dezentrale Speicherung von Informationen 7
Systemeigenschaften Hochverfügbarkeit & Skalierbarkeit Kein single-point-of-failure Redundante Speicherung von Informationen Clustering der Managementressourcen Dezentrale Vergabe der Ressourcen (z.b. Id Vergabe) Datenbank Clustering Load Balancing Flexibilität Unterstützung Mehrheit der eingebetteter Systeme Plattformunabhängigkeit Selbstmanagement Automatische Reaktion auf Fehler 8
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 9
Systemfunktionalität - Begriffserklärung Aktion Programm zur Überwachung, Konfiguration oder Aktualisierung z.b. DB leeren, Prozessor Temperatur messen Monitor Aktion zur Überwachung von Systemkomponenten + Parameter z.b. Temperatur des Prozessors messen / 10 x / in 30 Sek. Abstand Event Wert der von einem Monitor als solches (z.b. Fehler) erkannt wurde Repräsentation der Events als XML Dokumente Event liefert Informationen über Fehlerquelle Eventklasse Kategorisierung der Events nach Priorität z.b. Klasse Immediate: Sehr hoch priorisiert 10
Systemfunktionalität - Begriffserklärungen Task Aktion die von einem Server geschickt wird, um etwas zu bewirken z.b. neuer Monitor, Events löschen, shutdown Trigger Wert oder Wertebereich zur Auslösung einer Aktion Verschiedene Triggerbedingungen lösen verschiedene Aktionen aus Rule Trigger Aktion Beziehung Trigger wird mit Eigenschaften des Events verglichen Automatische Reaktion ohne User Interaktion z.b. Event (Immediate):Temperatur > 90 C & Originator = ES1 - > Aktion(shutdown) 11
Systemfunktionalität Modellierung Objektorientierte Modellierung der Ressourcen in UML Einsatz von Standards zur Management Modellierung Erzeugung von Objekten aus diesem Modell Objekte an Management Umgebung übergeben Objekte: Tasks, Rules, Aktionen, etc. Wiederverwendbare Objekten Monitoring Regelmäßige Überwachung von kritischen Ressourcen Überwachung direkt im Client Einbettung anderer Monitoring Möglichkeiten z.b. OS logging, SNMP, etc. 12
Systemfunktionalität Event Generierung Auswertung der gemessenen Werte im Client Nicht jede Messung ist ein Event Dynamische Entscheidung was ein Event ist Vermeidung von Systemüberlastung der Management Umgebung Event Generierung im Client 4 Event Klassen (Prioritäten) mit 4 Default Strategien Klasse Priorität DB Server LAM DB Server WAM GUI Default Aktion Immediate 1 Ja Ja Ja Ja Critical 2 Ja Ja Ja Nein Service 3 Nein Nein Ja Nein Information 4 Nein Nein Nein Nein 13
Systemfunktionalität Event Handling Kommunikation zum Server über Events Dezentrale Speicherung der Events in DB und auf dem Client Serverseitige Event Replikation Besonderheit der Immediate Events: Default Aktion Client sendet Event und wartet auf eine Antwort Automatische Antwort von Server oder Administrator Automatische Antwort im Client (Default Aktion) Zustellung der Events an der Darstellungsschicht Push und Pop Verfahren Interaktion mit dem Events Bestätigen (Ack) Status wechseln Reaktion ausführen 14
Systemfunktionalität Rule Handling Rule Handling im Client oder Management Umgebung Trigger mit Event vergleichen und Ausführung der Aktion Speicherung der Rules auf Servern (WAM) Caching der Rules auf Servern (LAM) 2 Stufige Rules: Routing und Aktion Rules Routing Rules Zustellung der Events an der gewünschten Stelle Aktion Rules Ausführbar auf allen Zielgeräten Messen, konfigurieren, aktualisieren, Informationen auslesen 15
Systemfunktionalität Task Handling Kommunikation zum Client über Tasks Verschiede Task Typen Konfigurations-Tasks: z.b. changemonitor Update-Tasks: z.b. addmonitor Verwaltungs-Tasks: deleteevents Für verschiedene Geräten Typen LAM / WAM Server, AccessPoint, embedded Systems, etc. Transaktionskontrolle in der Zustellung der Tasks Dezentrale Vergabe eines TaskID Eineindeutig Zeitliche Reihenfolge Keine fortlaufende ID notwendig 16
Systemfunktionalität Software/Hardware Verteilung Software/Hardware Verteilung und Update über Update-Tasks z.b. Verteilung neuer Binaries für Aktionen, Monitore, Rules Verteilung eines neuen Designs für einen FPGA Software/Hardware und Konfigurations- Inventory über TaskID Aktuelles Client TaskID liefert Informationen über Software/Hardware Zustand Client bekommt alle für ihn anstehenden Update- und Konfigurations-Tasks -> Client immer Aktuell 17
Systemfunktionalität Softwareupdate zur Laufzeit für Java Applikationen Java Programm wird im Quellcode durch ein selbst entwickeltes Software-Werkzeug modifiziert Passivierung der Instanzen der zu aktualisierenden Klassen Zustand der Instanzen wird erfasst Die originalen Klassen werden durch die neuen Klassen ersetz. Instanzierung der neuen Klasse. Der Zustand der alten Instanzen wird auf die neuen Klassen übertragen. alten Klasse werden gelöscht Verteilung der Neue Klassen über Update-Tasks deploynewclasstask 18
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 19
Architektur 20
Architektur Rule Module UML-Editor XMI2MOF Management Modell Event Module Deploy Module http CIMConnector Task Module xml Connection Module xmi mof object Datenbank CIM Server -ArgoUML / Poseidon, XMI2MOF -CIM / CIM Object Manager -CIMNavigator -Java WAM / LAM Server -EJB -JBOSS -MySQL Datenbank xml xml Rule Handling Event Task Handling Handling Betriebssystem Monitoring Thin / Full Client -Java Interpreter / C Compiler -Linux 21
Architektur Common Information Model CIM Standard (CIM 2.9) Entwickelt von Gesamten CIM Standard in UML Modelliert Standard zur Vereinheitlichung von Management-Ressourcen Objektorientierte Darstellung von Management Informationen von Systemen, Netzwerken, Applikationen und Diensten Abhängigkeiten werden durch Assoziationen zwischen den Objekten dargestellt Das Modell besteht aus 3 Schemata: Core Schema (Daten Typen, fundamentale Klassen), Common Schema (abstrakte Klassen), Extension Schema (spezielle Klassen) Schema Darstellung im MOF (Managed Object File) Format 22
Architektur Common Information Model - Konzept Modell (1) UML (2) XMI (3) MOF (1) Entwicklung des Modells (2) Exportieren aus der Modellierungs-Umgebung als XMI (3) Konvertierung in das Managed Object File Format (4) Einlesen der Klassendefinitionen in den CIMOM (5) Instanzbildung und Entwicklung der XML Konfiguration CIMOM (4) (CIM Object Manager) (5) XML 23
Architektur Entwicklung des Modells 24
Architektur XMI2MOF: Ein Tool zur Transformation von UML Modellen in CIM Modellen d.h. XML Metadata Interchange Format (XMI) wird zum Managed Object Format (MOF) abgebildet. Tool wird von OMG Angeboten: http://www.wbemsource.org/wbem-tools XMI2MOF arbeitet daher nach einem 4 Stufen Prinzip: Transformation in eine herstellerunabhängige XMI (Poseidon, ArgoUML, Umbrello, Rational Rose) Dekodieren der Modelldaten entsprechend der XMI Version (XMI 1.0, XMI 1.1, XMI 1.2) Anwendung von Algorithmen zur Abhängigkeitsauflösung, Kardinalitäts- und Multiplizitätserkennung sowie zur Vererbungsordnung Ausgabe des Modells im MOF 25
Architektur Objektbildung 26
27 Architektur Entwicklung des XML Konfigurations-Dokument <RBEM_ClientSetMonitor> <caption>"exampleclientsetmonitor"</caption> <description>"exampleclientsetmonitor"</description> <elementname>"examplesetmonitortask"</elementname> <RBEM_TargetMask> <deviceid>11.22.33</deviceid> <groupid>12345</groupid> <groupid>53653645643</groupid> <firmid>"536"</firmid> <caption>"exampletargetmask"</caption> <description>"exampletargetmask"</description> <elementname>"exampletargetmask"</elementname> <idrange>10.22.33-22.44</idrange> </RBEM_TargetMask> <RBEM_Header> <taskid>""</taskid> <name>"addmonitor_task"</name> <expiry>20060411115830.000329+060</expiry> <type>"2"</type> <ack>false</ack> <purpose>"update"</purpose> <caption>"exampleheader"</caption> <description>"exampleheader"</description> <elementname>"exampleheader"</elementname> <taskrepeat>1</taskrepeat> </RBEM_Header> <RBEM_Monitor> <name>"monitor1"</name> <run>true</run> <repeat>3</repeat> <period>1</period> <caption>"examplemonitor"</caption> <description>"examplemonitor"</description> <elementname>"examplemonitor"</elementname> <description>"immediateexampleeventclass"</description> <elementname>"immediateexampleeventclass"</elementname> <saveonconsole>true</saveonconsole> <saveonlaem>true</saveonlaem> <saveonclient>true</saveonclient> <timetoresponse>15</timetoresponse> <defaultreaction>"actionnameimmediate"</defaultreaction> </RBEM_EventClass> </RBEM_ClientSetMonitor> <RBEM_Header> <taskid>""</taskid> <name>"addmonitor_task"</name> <expiry>2006041111.329+060</expiry> <type>"2"</type> <ack>false</ack> <purpose>"update"</purpose>
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 28
Stand der Arbeit - Implementierung System Monitoring & Event Management Rule Handling Task Handling Event Handling XMI2MOF Management Modell Full Client Thin Client Software Verteilung & Konfiguration Inventory Management Java Updates zur Laufzeit Konfiguration über Tasks Darstellung Tasksanzeige / Pop Eventsanzeige / Pop 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 29
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 30
Ergebnisse Dauertest (Zustellung der Events über Transaktionen) Server + DB und Client: Pentium IV 2GHz, 512 Mbyte RAM, 100Mbit 90 FullClients / 1 Evt/s / 43200 s (12h) = 3888000 Evts Eventrate Test 1 FullClient / 100.000x / 1 Evt => 749.92 s => 133.34 Evts/s 1 FullClient / 50.000x / 2 Evts => 514.32 s => 194.42 Evts/s 1 FullClient / 33.333x / 3 Evts => 432.53 s => 231.19 Evts/s Event Absicherung Eventgenerierung (ThinClient) -> AccessPoint -> DB ca. 159 ms (+ ntp Fehlertoleranz 5-50 ms) 31
Ergebnisse Task Bearbeitungsdauer Verbindungsaufbau Client -> AP -> Server = ca. 1 s Task deploy WAM Server -> LAMServer -> AP -> Client ca. 500 ms Reaktionszeiten Eventgenerierung -> AP -> LAM -> Triggern -> Aktion Remote von Server: 689 ms Lokal auf dem Client: 16 ms Konfigurationsdauer (500 FullClients) 50 FullClients -> 1Event -> 1 Konfigurations-Task = ca. 25s Thin Client Speicher: ca. 150 Kbyte Client, ca. 30 Bytes/Event 32
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Demonstration Zusammenfassung Ausblick 33
Zusammenfassung Komplexes Management mit garantierter Zustellung von Informationen möglich wenn: Objektorientiertes Management Dezentrale Managementumgebung Dezentrale Datenspeicherung Vermeidung von single-point-of failure durch Clustering und Redundante Hardware Load Balancing Dynamische Event Identifikation und Generierung im Client Nicht jeder gemessene Wert muss ein Event sein! Komplexität-Reduzierung durch den Einsatz von etablierten Standards 34
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Demonstration Zusammenfassung Ausblick 35
Ausblick Fertigstellung des Prototyps Korrelation von Events Optimierung des Prototyps Testen in Zielumgebung Testen mit Datenbank Cluster Dokumentation 36
Themenübersicht Motivation Ziele Systemeigenschaften Systemfunktionalität Architektur Stand der Arbeit Ergebnisse Zusammenfassung Ausblick Demonstration 37
Demonstration 1. - Erstellung der Klasse SetMonitorTask - Konvertierung von XMI zu MOF - Klasse in Modell aufnehmen 38
Demonstration 2. 1. -Instantiierung der Klasse SetMonitorTask (DB) -Bereitstellung als XML Dokument -Speicherung in TaskDB 39
Demonstration 2. 1. - Client Starten - sendet start Event D = 0 - AP leitet Event zu LAM - Event Speicherung in EventsDB 3. 40
Demonstration 2. 1. 4. - LAM bezieht Task aus WAM - Task Speicherung im LAM Cache 3. 41
Demonstration 2. 1. - LAM sendet Task zu AP - AP sendet Task zu Client 4. 5. 3. 42
Demonstration 2. 1. 4. - Client deploy Task - Monitor wird gestartet - Client erzeugt Events 5. 6. 3. 43
Demonstration 2. 1. - Client sendet Events zu LAM - LAM speichert Events in EventsDB - LAM sendet Events zu WAM - WAM speichert Events in ConsoleEventsDB 4. 5. 3. 6. 7. 44
Demonstration 2. 1. 8. - Events werden über HTTP an der Administrator GUI angezeigt 4. 5. 3. 6. 7. 45
Demonstration 2. 1. 8. - Instantiierung der Klasse SetRuleTask 9. 4. 5. 3. 6. 7. 46
Demonstration 2. 1. 8. - Client reagiert selbsttätig 9. 4. 5. 10. 3. 6. 7. 47
Vielen Dank für Ihre Aufmerksamkeit. Fragen? 48