Komponentenbasierte Anwendungsentwicklung für Computational Grids

Transkript

1 Komponentenbasierte Anwendungsentwicklung für Computational Grids Jan Dünnweber Westfälische Wilhelms-Universität Münster Münsteraner Kolloquium für Parallelität, 16. Dezember 2005, Institut für Wirtschaftsinformatik, Münster 1

2 DAS OGSA-MODELL FÜR DIE GRID-PROGRAMMIERUNG Grid Middleware Grid Servers hosted by Application Client request Service deliver Result SOAP/HTTP provide service virtually stateful Web Service Resource Resource interact manage Resource Home obtain endpoints WSRF-Middleware (service container) vermittelt zwischen Anwendung und Ressourcen Worin besteht die Aufgabe des Entwicklers? DAS OGSA-MODELL FÜR DIE GRID-PROGRAMMIERUNG 2

3 GRID-PROGRAMMIERUNG MIT WSRF Konfiguration von Services & Ressourcen (erweiterte WSDL) Zuordnung von Namensräumen/Bezeichnern an Codedateien Impl. Services, Ressourcen und homes (factories) Bereitstellung der Deployment Konfiguration (WSDD) Lokalisierung eines Grid Application Archivs (JNDI) WSDD OGSA WSN GT 4 WSDL GAR WSRF WSDD WSDL GT 4 CODE CODE Deployment Descriptor Developer Service Interfaces Globus Implementation GAR Grid Application Archive GRID-PROGRAMMIERUNG MIT WSRF 3

4 EIN BEISPIEL WSDL-INTERFACE FOR WSRF <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions name="masterservice" targetnamespace=" xmlns:wsdlpp=" <!-- more namespace declarations --> xmlns=" <wsdl:import location="../../wsrf/properties/ws-resourceproperties.wsdl"/>... <!-- more WSR-import statements --> <wsdl:types> <schema targetnamespace=" xmlns=" <import namespace=" <complextype name="arrayof_xsd_double"> <complexcontent> <restriction base="soapenc:array"> <attribute ref="soapenc:arraytype" wsdl:arraytype="xsd:double[]"/> </restriction> </complexcontent> </complextype>... <!-- weitere Parametertyp und --> </element> <!-- resource property Vereinbarungen --> </schema> </wsdl:types> <wsdl:message name="configurerequest"> <wsdl:part name="in0" type="impl:arrayof_xsd_string"/> </wsdl:message> <wsdl:message name="configureresponse"> <part name="parameters" element="impl:void"/> </wsdl:message> <!-- more message declarations --> <wsdl:porttype name="masterporttype" wsdlpp:extends="wsrpw:getresourceproperty wsrlw:immediateresourcetermination" wsrp:resourceproperties="tns:masterresourceproperties"> <wsdl:operation name="configure" parameterorder="in0"> <wsdl:input message="impl:configurerequest"/> <wsdl:output message="impl:configureresponse"/> </wsdl:operation>... <!-- more operation declarations --> </wsdl:porttype> </wsdl:definitions> EIN BEISPIEL WSDL-INTERFACE FOR WSRF 4

5 IDEE: KOMPONENTEN HÖHERER ORDNUNG (HOCS) Auswahl und Parametrisierung von Komponenten (HOCs): vorgefertigte verteilte/parallele Impl. inkl. Konfiguration Programmierung durch Zusammenfügen von Komponenten Beachte: Parameter sind Programme höhere Ordnung select Component Repository Map HOC Farm HOC Pipeline HOC DWT HOC Divide& Conquer HOC write Java or Script application specific code, e.g., worker parameter for an image processing farm Application Developer mobile code parameter Grid Expert IDEE: KOMPONENTEN HÖHERER ORDNUNG (HOCS) 5

6 DAS HOC-KONZEPT IN JAVA Serverrechner halten Implementierungen oftmals benötigter Schemata bereit, beispielsweise die Skelette Farm und Pipeline Solche, partiellen Implementierungen sind bereits mit der verwendeten Middleware integriert und bieten Schnittstellen für den Fernzugriff: public interface FarmHOC <E > { public void setmaster( Master m ); public void setworker( Worker w ); public E[] compute (E input ); } Die serverseitige Implementierung ist hardware-spezifisch und anwendugunabhängig DAS HOC-KONZEPT IN JAVA 6

7 DIE ARBEITSWEISE DER KOMPONENTE FARM-HOC ➀ Der Clientrechner fordert eine Farm Service Instanz an ➁ Farm Service legt Worker Instanzen an, ➂ unterteilt die Eingabedaten und ➃ fügt die Ergebnisse zusammen ➄ 2 client 5 1 Farm HOC Factory Farm HOC 1) Farm Service... create Worker 4 Worker Factory Factory 2) Worker Service... create 2) Worker Service 2) Worker Service... create 2) Worker Service DIE ARBEITSWEISE DER KOMPONENTE FARM-HOC 7

8 HOC-PARAMETER: MOBILE CODEFRAGMENTE Die clientseitig festgelegten Parameter sind anwendungsspezifisch und hardwareunabhängig Die Schnittstellen der Parameter sind z.b. public interface Worker <E > { public E compute (E input ); } public interface Master <E > { } public E[] split (E input, int numworkers ); HOC-PARAMETER: MOBILE CODEFRAGMENTE 8

9 CODE ALS PARAMETER EINES WEB SERVICE? Problem: XML-Schemata erlauben keine Beschreibung von Schnittstellen wie Master und Worker (nur Primitive) Grid hosts Server Y HOC repository Client local code... HOC1( A,B)... code for A code for B 1 2 A B Server X CodeBase Service B C A 3 HOC1 B A B A B Remote Class Loader A C A HOC2 instantiation of HOC1 4 HOC repository C A HOC2 Server Z B D C HOC3 Lösung: Code-Service ordnet Bezeichnern Schnittstellen zu CODE ALS PARAMETER EINES WEB SERVICE? 9

10 BEISPIELANWENDUNG 1: BERECHNUNG VON FRAKTALEN Zeitgleiche Verarbeitung unterschiedlicher Teilbereiche Direkt mittels Rechnerfarm parallelisierbar Grid Impl. verwendet entspr. die Komponente Farm-HOC BEISPIELANWENDUNG 1: BERECHNUNG VON FRAKTALEN 10

11 INHALT DER CODEPARAMETER In der Fraktalanwendung schreibt der Programmierer nur den einfachen Fraktalgenerator (kein Unterschied zu einer sequentiellen Version): public class FractalWorker implements Worker < Tile > { public Tile compute ( Tile extract ) { for (int y = 0; y < extract. height ; ++ y) { for (int x = 0; x < extract. width ; ++ x) {... // compute color value for (x, y) } }}} Wie wird die Berechnung im Grid gestartet? INHALT DER CODEPARAMETER 11

12 DER FERNZUGRIFF AUF EIN HOC farmhoc = farmhocfactory. createhoc ( ); farmhoc. setmaster (" masterid"); farmhoc. setworker (" workerid"); farmhoc. configuregrid ( " masterhost ", " workerhost1 ",..., " workerhostn " ); farmhoc. compute( input ); Anforderung der HOC-Instanz mittels factory Auswahl der Code Parameter Auswahl der Server Start der ausgelagerten Berechnung DER FERNZUGRIFF AUF EIN HOC 12

13 BEISPIELANWENDUNG 2: BIOINFORMATIK Proteinsequenzabstände werden mittels Ähnlichkeitsmatrizen beschrieben, deren Elemente wie folgt definiert sind: s i,j := max(s i,j 1 +penalty,s i 1,j 1 +δ(i,j),s i 1,j +penalty) wobei δ(i, j) := +1, if ε 1 (i) = ε 2 ( j) 1, otherwise Eine Berechnung dieser Art heißt globaler Abgleich Ähnlichkeitsdefinition mittels Codeparameter möglich Die Matrix wird mit dem Wellenfront-HOC parallel berechnet BEISPIELANWENDUNG 2: BIOINFORMATIK 13

14 DAS WELLENFRONT-HOC In der Matrix hängt jedes Element von seinem nördlichen, nördwestlichen und westlichen, direkten Nachbarn ab G G A C T G T T C T Matrixelements werden in Wellenfronten gruppiert, die entlang der Antidiagonalen verlaufen und mit dem Fortschreiten der Berechnungen die Matrix überdecken DAS WELLENFRONT-HOC 14

15 DER CODEPARAMETER FÜR DEN PROTEINSEQUENZABGLEICH Folgende Schnittstelle muss Implementiert werden: public interface Binder <E > { } public E bind (int i, int j); Die Spezifikation kann auch in einer Skriptsprache erfolgen, z.b. in Ruby: def bind (i, j) end return [ matrix.get(i, j 1)+penalty, matrix.get(i 1, j 1) + p(i, j), matrix.get(i 1, j)+penalty ]. max HOCs unterstützen verschiedene Programmiersprachen DER CODEPARAMETER FÜR DEN PROTEINSEQUENZABGLEICH 15

16 BEISPIELANWENDUNG 3: DISKRETE WAVELET TRANSFORMATION (DWT) Integrale Abbildung, wie FFT (Fast Fourier-Transform), jedoch wavelets (ψ) anstelle trigonometrischer Funktionen ( f ;a,b) Z f (t)a 1 2 ψ(a 1 (t b))dt z.b. für die Bildverarbeitung, Datenkompression und andere Daten/Rechen-intensive Anwendungen Oftmals benötigt = als Web Service bereitgestellt Anwendungsscenario: Mehrere Nutzer wollen zeitgleich große Datenmengen verarbeiten Parallele, Grid-taugliche Implementierung als HOC ist wünschenswert BEISPIELANWENDUNG 3: DISKRETE WAVELET TRANSFORMATION (DWT) 16

17 DIE SKELETALE STRUKTUR DES LIFTING-HOC Festes Lifting Schema, variable split, predict & update Funktionen (u i,v i ) := split(u i 1 ) u i+1, j := u i, j predict(v i, j ) v i+1, j mi := v i, j mi + update(u i+1, j mi ) for j < m i for j m i zu Beginn: u 0, j = x j for j = 0..m 0 (erster Index i ist der lifting Schritt) Menge u i 1 wird in gleichgroße Untermengen u i und v i geteilt while notempty(u i ) wende predict auf v i an und berechne neue u i+1 ersetze u i mit Differenzen zwischen alten und neuen Werten wende update auf die Differenzen an und addiere sie zu v i Bisektion während des Liftings = log 2 m 0 Schritte DIE SKELETALE STRUKTUR DES LIFTING-HOC 17

18 EINE PARALLELE AUSWER TUNG MITTELS MPI-PIPELINE Die Lifting steps des Schaltplans entsprechen Pipeline Stufen u i 1 subset vi predict split subset ui + update subset vi+1 predict split subset ui+1 + update v i+1 u i+1 update predict + merge v i u i update predict + merge Eine Invertierung des Schemas erlaubt die Eingabe zu rekonstruieren und läßt somit die Korrektheit der Parallelimplementierung überprüfen. split, predict & update Funktionen können vom Benutzer angegeben werden, z.b. so dass in einem Signal, Werte mit ungeraden Indizes separiert werden oder linare bzw. polynomiale Abhängigkeiten angenommen werden EINE PARALLELE AUSWERTUNG MITTELS MPI-PIPELINE 18

19 BEOBACHTUNG: DIE PARAMETERFUNKTIONEN SIND POR TABEL In der Waveletanwendung erfordern die Parameter keinen Austausch von Kontrollstrukturen (Schleifen, Auswahl etc.) predict und update sind arithmetische Terme Das splitting Muster hat eine grafische Repräsentation Formulierung mittels XPath-Ausdrücken oder anderen XML-basierten Formaten ist möglich Solche Daten können auch dann zwischen Komponenten und Clientanwendungen ausgetauscht werden, wenn unterschiedliche Programmiersprachen verwendet werden Wir haben, z.b. Java-basierte Web-Anwendung zum Filtern von Bilddaten implementiert Das feingranulare Lifting-Schema wird mittels einer C/MPI-basierten Pipeline parallelisiert BEOBACHTUNG: DIE PARAMETERFUNKTIONEN SIND PORTABEL 19

20 INTEGRATION VON HOCS MIT NATIVEN TECHNOLOGIEN Def: Ein gateway erlaubt die Kommunikation zwischen Netzen, die unterschiedliche Protokolle nutzen Java Web Application SOAP Globus Web Service Operations init execute getresults TCP Socket send recv MPI State Data parameters results #numprocessors HPC Platform system(mpirun...) Unser SOAP/MPI-gateway basiert auf WSRF-Ressource INTEGRATION VON HOCS MIT NATIVEN TECHNOLOGIEN 20

21 ZUSAMMENFASSUNG HOCs erlauben Programmierern die Anwendungslogik zu fokussieren, bewirken jedoch kaum Performance-Einbußen Von Grid spezifischen Aspekten (fault-tolerance, security,...) wird bei dieser Vorgehensweise abstrahiert Die Implementierung kann neuer HOCs lässt sich mittels Bibliotheken vereinfachen (Lithium, eskel, DatTeL, MUESLI,...) Clientanwendungen kommunizieren mit unterschiedlichen HOCs mittels einheitlicher Web Service Interfaces Die gegenwärtige Forschungsschwerpunkte sind Adaptivität und Kompostionalität von HOCs ZUSAMMENFASSUNG 21