OSGI-basiertes Grid-Computing

Transcript

1. Do 8.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Bundle-Bee OSGI-basiertes Grid-Computing Phillip Ghadir Philipp Haußleiter The essence of modern software engineering Software meets Business January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich organized by SIGS DATACOM GmbH Lindlaustraße24: |D-53842Troisdorf Tel.+49 (0)2241.2341-100 | Fax+49(0)2241.2341-199 info@sigs-datacom.de |www.sigs‐datacom.de FACHINFORMATIONEN FÜR lT‐PROFESSIONALS
2. Bundle-Bee Eine OSGI-basierte Grid-Plattform Phillip.Ghadir@innoq.com Philipp.Haussleiter@innoq.com Agenda • Arten von Grid-Plattformen • Positionierung von Bundle-Bee • Das Programmier-Modell • Java sei Dank - Grundlegende Mechanismen • Bundle-Bee-Roadmap innoQ| Bundle‐Bee Eine OSGl-basierte Grid-Plattform Phillip.Ghadir@innoq.com Philipp.Haussleiter@innoq.com innoQ| Agenda 0 Arten von Grid-Plattformen ' Positionierungvon Bundle‐Bee . Das Programmier-Modell ' java sei Dank - Grundlegende Mechanismen . Bundle-Bee-Roadmap
3. Arten von Grid- Plattformen Arten von Grid- Plattformen Computing Data On-Demand • Beispiele • SunGrid • Amazon EC2 • Beispiel • Amazon S3 • Beispiele • Google Index Cluster • Super- Computer innoQ| Arten von Grid‑ Plattformen Arten von Grid- Innle Plattformen Computing Data On-Demand . Beispiele 0 Beispiel 0 Beispiele . Googlelndex . Amazon 53 . SunGrid Cluster 0 Amazon EC2 . Super‑ Computer
4. Computing Grids • parallele Verarbeitung von identischen Aufgaben • gleichmäßige Nutzung von CPU/RAM • gleichmäßige Ausnutzung aller Knoten • Aufgabe muss „zerteilbar“ sein • Knoten meistens hinsichtlich Durchsatz optimiert. • Skalierend über Prozessoren HPC Indexing Crawling Result Task Knoten 1 Knoten 2 Knoten 3 Data Grids • Speicherung von redundanten Datenpaketen innerhalb des Grids • Automatische Synchronisation der Knoten untereinander • transparenter Zugriff auf die gespeicherten Daten • Skalierend über Festspeicher • brauchbar für große Daten (e.g. viele Datenpakete) • wenig performant (Netzwerklatenz) Redundante Datenhaltung Knoten 1 011101 100010 011101 100010 001010 Knoten 3 001010 011101 011101 100010 001010 Knoten 2 100010 001010 innoi Computing Grids paralleleVerarbeitung von identischen Aufgaben gleichmäßige Nutzungvon CPU/RAM gleichmäßigeAusnutzung aller Knoten Aufgabe muss „zerteilbar“ sein Knoten meistens hinsichtlich Durchsatz optimiert. Skalierend über Prozessoren innoi Data Grids ' Speicherungvon redundanten Datenpaketen innerhalb des Grids ' Automatische Synchronisation der Knoten untereinander . transparenter Zugriff auf die gespeicherten Daten ' Skalierend über Festspeicher ' brauchbar für große Daten (e.g.viele Datenpakete) ' wenig performant (Netzwerklatenz)
5. On-Demand-Grids • Ausführung von unterschiedlichen Tasks auf verschiedenen Knoten • Skalierend über Prozesse • Ausfallsicherheit durch redundante Systeme • „jeder Knoten kann alles“ • Anfragen/Ergebnisse müssen verteilt und zugeordnet werden. • hohe, gleichmäßige Auslastung des Grids On-Demand-Grid Computing Cloud Knoten 1 Knoten 2 Knoten 3 Task 1 Task 2 Result 1 Result 2 Positionierung von Bundle-Bee innoi On-Demand-Grids Ausführung von unterschiedlichen Tasks auf verschiedenen Knoten Skalierend über Prozesse Ausfallsicherheit durch redundante Systeme „jeder Knoten kann alles“ Anfragen/Ergebnisse müssen verteilt und zugeordnet werden. hohe,gleichmäßige Auslastung des Grids inno Positionierung von Bundle-Bee
6. Positionierung von Bundle-Bee • Nutzung von Verarbeitungskapazitäten in “gewöhnlichen” OSGI-Runtimes • Verwendung des üblichen OSGI- Programmiermodells • Nutzung von Verteilungs- und Management- Infrastruktur • Schön-Wetter-Flug => Zero Configuration Das Programmier- Modell .. . innoQ| P05|tlonlerung von Bundle-Bee ' NutzungvonVerarbeitungskapazitäten in “gewöhnlichen” OSGl-Runtimes ' Verwendung des üblichen OSGI‑ Programmiermodells ' NutzungvonVerteilungs- und Management‑ Infrastruktur ' Schön-Wetter-Flug => Zero Configuration innoQ| Das Programmier‑ Modell
7. Allgemeine OSGI- Regeln • Modularisierung über Bundles • Bundles = JARs mit deklarierten Abhängigkeiten & Angeboten • Keine Komposition von Paketen sondern stets per Assoziation Spezifische Regeln für verteilte Systeme • Keine Zugriffe auf das lokale Dateisystem • Keine Sockets • Kein eigenes Ressourcen-Management • Keine eigenen Threads • Kein eigenes Class-Loading Allgemeine OSGl-lnnogl Regeln ' Modularisierung über Bundles ' Bundles = ]ARs mit deklarierten Abhängigkeiten &Angeboten ' Keine Komposition von Paketen sondern stets perAssoziation .innoQ| Spezifische Regeln fur verteilte Systeme 0 Keine Zugriffe auf das lokale Dateisystem ' Keine Sockets . Kein eigenes Ressourcen‐Management ' Keine eigenenThreads 0 Kein eigenes Class‐Loading
8. Grundlegende Mechanismen Bundle-Bee Architektur-Übersicht innoQ| Grundlegende Mechanismen Bundle-Bee '""°QI Architektur-Übersicht
9. OSGI- Framework com.example. testbundle start Classloading-Hook Javassist processClass Bundle-Bee Class-Loader Packages Aspekte testbundle beep(){ } start(){ } classloading-Hook: wird vom OSGI-Framework ausgeführt bevor eine Klasse geladen wird. process-Class: javassist-Modifikator, um den Bytecode einer Klasse zu verändern. eigene Packages (welche zusätzliche Klassen beinhalten), können mit Hilfe eines eigenen, modifizierten Class-Loaders in die Runtime geladen werden. die verschiedenen Aspekte, welche in den vorhandenen Bytecode eingewebt werden sollen, werden ebenfalls mit der Hilfe von javassist-Methoden hinzugefügt. Remote- Aspekt Start Analyse- Aspekt Aufruf im Bundle- Manager ENDE lokaler oder remote Aufruf? Es werden folgende Aspekte in den Bytecode integriert Analyse-Aspekt: - wird vor jedem Aufruf integriert - prüft ob eine lokale Ausführung einer remote-Ausführung vorzuziehen ist. Remote-Aspekt: - wird in den Bytecode integriert, falls eine lokale Ausführung länger dauert als ein remote-Aufruf - der Bundle-Manager löst die Anfrage nach einem Remote-Aufruf auf und bindet einen vorhandenen Dienst (auf einem anderen Knoten) - nach der Ausführung wird der Aufruf-Kontext in den lokalen Classloader Kontext zurück gegeben, geladener und ausgeführter Bytecode lokaler (direkter) Ablauf remote Aufruf classloading-Hook: Com.example. bevor e | n e Klasse geladen e r d . testbundle process-Class: testßüfidle Bundle-Bee Class-Loader V javassist Aspekte Packages b9990{ wird vom OSGl-Framework ausgeführt javassist-Modifikator, um den Bytecode einer Classloading-Hook Klasse zuverandern. eigene Packages (welche zusätzliche Klassen beinhalten),können mit Hilfe eines eigenen, modifizierten Class-Loaders in die Runtime geladen werden. die verschiedenen Aspekte,welche in den vorhandenen Bytecode eingewebt werden sollen,werden ebenfalls mit der Hilfe von javassist-Methoden hinzugefügt Analyse‑ Aspekt lokaler remote Aufruf Ablauf Eswerden folgende Aspekte in den Bytecode integriert Analyse-Aspekt: - wird vor jedem Aufruf integriert - prüft ob eine lokaleAusführung einer remote-Ausführungvorzuziehen ist. Remote-Aspekt: - wird in den Bytecode integriert.falls eine lokaleAusführung länger dauert als ein remote-Aufruf - der Bundle‐Manager löst die Anfrage nach einem Remote-Aufrufauf und bindet einen vorhandenen Dienst (auf einem anderen Knoten) - nach derAusführungwird der Aufruf‐Kontext in den lokalen Classloader Kontext zurück gegeben,
10. Lokal oder Remote? Bundle Registry Bundle Manager Bundle Repository Service Anfrage Service lokal vorhanden? ja! nein! frage nach Repository liefere Repository URL Anfrage nach Service-Bundle liefere Service-Bundle installiere Service- Bundle starte Service- Bundle speicherer Bundle in Repository registriere Bundle in Registry Node 1 Registry Node 2 Registry MultiCast Address Node 3 Registry Node N Registry distributed Hashmap Node 1 <192.168.100.1> Repository Node 2 <192.168.100.2> Manager Node 3 <192.168.100.3> ServiceA Node 3 <192.168.100.3> Repository Node 2 <192.168.100.2> ServiceB - jeder Knoten enthält eine eigene lokale Registry - jede Registry hält eine Map vor, in der Informationen aus dem Grid gespeichert sind. - Bei einer (lokalen) Änderung werden alle anderen Grid-Nodes über Multicast-Nachrichten über die Änderung informiert. innoQ| Lokal oder Remote? [ ‚li‐“£ | [ .?Tä'"! ; | R_ | | | Service _> Anfrage Service lokal ‐ P r ' ja! enden? nein! / _ frage nach _“ Repository ‘‐ lietere ‐L Repositorv ; URL Anfrage nach Service-Bundle IA ‘ liefere Service-Bundle installiere Service‑ Bundle speicherer _“ Bundle in Repository starte Service‑ Bundle _ ‚ _ registriere _, Bundle in Registry Mode 1 Registry 5 MultiCast R 't N0de 2 Address egls ry Registry ' Mode 3 Registry - jeder Knoten enthält eine eigene lokale Registry . . ‘ - jede Registry hält eine Map vor, d|5trlbUted in der Informationen aus dem Hashmap Grid gespeichert sind. - Bei einer (lokalen) Änderung < |92- ' 68-|00- |> Repository werden alle anderen Grid-Nodes < |92.|68.|00.2> Manager über Multicast-Nachrichten über < |92_ |68_ |00_3> ServiceA die Änderung informiert. < |92.|68.|00.3> Repository < |92.|68.|00.2> ServiceB
11. Aktueller Stand • Bundle_Bee_0_5_0 (Meilenstein 1) released • Machbarkeitsnachweis: • Einweben der Anbindung an den Grid • Verwaltung lokaler und entfernter Bundles • “Zero”-Configuration • Equinox-abhängig Roadmap • M1 • Grundlagen für Verteilung • Setup “ohne Konfiguration” • M2 • Berechtigungskonzept • M3 • Monitoring • Auto-Rekonfiguration innoQ| Aktueller Stand ' Bundle_ßee_0_5_0 (Meilenstein |) released ' Machbarkeitsnachweis: ' Einweben derAnbindung an den Grid ' Verwaltung lokaler und entfernter Bundles ' “Zero”-Configuration ' Equinox-abhängig innoQ| Roadmap . MI 0 Grundlagen fürVerteilung ' Setup "ohne Konfiguration” 0 M2 . Berechtigungskonzept . M3 ' Monitoring ' Auto-Rekonfiguration
12. Zusammenfassung • Bundle-Bee ist ein Grid auf Basis von OSGI • Bundle-Bee ist als Machbarkeitsstudie für Spielzwecke einsetzbar • Bundle-Bee M2 ist für ernstere Vorhaben geeignet • hehres Ziel: Write OSGI-compliant - Run in the Grid ENDE! Vielen Dank für Ihre Aufmerksamkeit! innoQ Deutschland GmbH innoQ Schweiz GmbH Halskestraße 17 Gewerbestrasse 11 D-40880 Ratingen CH-6330 Cham Phone +49 2102 77162-100 Phone +4141743 0111 info@innoq.com · www.innoq.com innoQ| Zusammenfassung Bundle‐Bee ist ein Grid auf Basis von OSGI Bundle‐Bee ist als Machbarkeitsstudie für Spielzwecke einsetzbar Bundle‐Bee M2 ist für ernstereVorhaben geeignet hehres Ziel: Write OSGI-compliant - Run in the Grid ll'll'lO ENDE! Vielen Dank für IhreAufmerksamkeit! innoQ| inn00 Deutschland GmbH inn00 Schweiz GmbH Halskestraße 17 Gewerbestrasse 11 D-40880 Ratingen CH-6330 Cham Phone+49 2102 77162-100 Phone +41417430111 info@innoq.com - www.innoq.com