Verteilte Systeme Sommer Vorteile Entwicklungs- und Testmethoden für Anwendungen auf Server übertragbar Erweiterbarkeit, Austauschbarkeit

Transkript

1 Verteilte Systeme 3. RPC und / / auf einem Rechner Verbreitete Systemarchitektur Verlagerung von Kernfunktionen in - Prozesse Mikrokern im User- Modus Vorteile Entwicklungs- und Testmethoden für Anwendungen auf übertragbar Erweiterbarkeit, Austauschbarkeit Nachteile Zusätzliche Kontextwechsel Weitergabe von Hardware- Ereignissen (Interrupts) Zugriff auf Geräteregister Hardware (c) 2013, Peter Sturm, Universität Trier 1

2 /- Architektur Betriebssystem Betriebssystem Rechner 1 Rechner 2 Lokale Dateisystem Ein- und Ausgabedienste (Graphik, Kommunikation,...) Prozeßverwaltung, Paging,... Entfernte Netzwerkdateisystem, z.b. NFS Verteiltes Dateisystem Rlogin, Telnet,... WWW- (httpd) Uhrensynchronisation (ntp) Realisierungsvarianten C S C S KS KS Kommunikationsserver Vorteile Erweiterbarkeit Einfacher Kern Nachteile Zusätzliche Kontextwechsel Höhere Nachrichtenlaufzeit Kernkommunikation Vorteile Minimale Verzögerungen Schnelle Übertragung Nachteile Kernänderung bei Erweiterungen Komplexer Kern Routing,... (c) 2013, Peter Sturm, Universität Trier 2

3 /- Architekturen SRSI sehr schöne Abstraktion send und receive nicht explizit sichtbar Kapselung der Dienste in eine Art Prozeduraufruf Remote Procedure Call (RPC) Der SRSI- Vertreter Idee: RPC = Lokaler Prozeduraufruf Birrell und Nelson, 1984 Grundlage für /- Systeme : Passiv, bietet Dienste an : Aktiv, ruft Dienste auf send() receive() Sender Alternative: Asynchroner entfernter Dienstaufruf Empfänger receive() reply() RPC- Architektur Lokaler Prozeduraufruf: Anwendung r := f(p); f r := rp(p); 1 3 rp 6 - Stub rp - Stub rp 4 Betriebssystem send/receive Betriebssystem Rechner 2 Rechner 5 Netzwerk (c) 2013, Peter Sturm, Universität Trier 3

4 Marshalling Encoding of basic data types may differ Little endian vs. big endian Define a generic network standard Sender converts data from local representation to network standard Receiver converts data from network standard to local representation Examples External data representation (xdr) ASN.1 XML (SOAP) JSON Defines a set of remote procedures Service or interface description Define signature for each method Type and sequence of arguments Name of procedure Return type Interface definition language (IDL) IDL compiler automates most functionality to call a remote procedure stubs stubs Additional server functionality RPC Compiler.c Stub Interface Description.c.c Compiler (e.g. C++) IDL Compiler Stub.c (c) 2013, Peter Sturm, Universität Trier 4

5 ONCRPC (SUN MICROSYSTEMS) Beispiel: ONCRPC RPC- Compiler (rpcgen) erzeugt Datenkonvertierungsroutinen (xdr) - Stub - Stub schleife optional Skelette für und Unterstützt UDP- und TCP- Kommunikation Rollenwechsel umständlich aber möglich Schutz realisierbar (c) 2013, Peter Sturm, Universität Trier 5

6 Entfernte Addition RPC- Schnittstellenbeschreibung: struct i_result { int x; ; struct i_param { int a1; int a2; ; program MY_RPC_SERVER { version MY_VERSION_1 { i_result ADD ( i_param ) = 1; = 1; = ; #include <rpc/rpc.h> Generierter Header struct i_result { int x; ; extern "C" bool_t xdr_i_result(xdr *, i_result*); struct i_param { int a1; int a2; ; extern "C" bool_t xdr_i_param(xdr *, i_param*); #define MY_RPC_SERVER ((u_long) ) #define MY_VERSION_1 ((u_long)1) #define ADD ((u_long)1) extern "C" i_result * add_1(i_param *, CLIENT *); extern "C" i_result * add_1_svc(i_param *, struct svc_req *); Leicht gekürzt (c) 2013, Peter Sturm, Universität Trier 6

7 - Stub #include <memory.h> /* for memset */ #include "remote_add.h" /* Default timeout can be changed using clnt_control() */ static struct timeval TIMEOUT = { 25, 0 ; i_result * add_1(i_param *argp, CLIENT *clnt) { static i_result clnt_res; memset((char *)&clnt_res, 0, sizeof(clnt_res)); if (clnt_call(clnt, ADD, (xdrproc_t) xdr_i_param, argp, (xdrproc_t) xdr_i_result, &clnt_res, TIMEOUT)!= RPC_SUCCESS) { return (NULL); return (&clnt_res); Die - Stub (Eine für alle) static void my_rpc_server_1(struct svc_req *rqstp, register SVCXPRT *transp) { union { i_param add_1_arg; argument; char *result; xdrproc_t xdr_argument, xdr_result; char *(*local)(char *, struct svc_req *); switch (rqstp- >rq_proc) {... case ADD: xdr_argument = (xdrproc_t) xdr_i_param; xdr_result = (xdrproc_t) xdr_i_result; local = (char *(*)(char *, struct svc_req *)) add_1_svc; break;... (void) memset((char *)&argument, 0, sizeof (argument)); svc_getargs(transp, xdr_argument, (caddr_t) &argument)); result = (*local)((char *)&argument, rqstp); svc_sendreply(transp, xdr_result, result)); svc_freeargs(transp, xdr_argument, (caddr_t) &argument)); Fehlerbehandlung entfernt (c) 2013, Peter Sturm, Universität Trier 7

8 int main(int argc, char **argv) { register SVCXPRT *transp; Die - Schleife (void) pmap_unset(my_rpc_server, MY_VERSION_1); transp = svcudp_create(rpc_anysock); svc_register(transp, MY_RPC_SERVER, MY_VERSION_1, my_rpc_server_1, IPPROTO_UDP)); transp = svctcp_create(rpc_anysock, 0, 0); svc_register(transp, MY_RPC_SERVER, MY_VERSION_1, my_rpc_server_1, IPPROTO_TCP)); svc_run(); Fehlerbehandlung entfernt Remote Procedure #include <rpc/rpc.h> #include header.h i_result *add_1_svc ( i_param *p, struct svc_req *sr ) { static i_result result; result.x = p- >a1 + p- >a2; return &result; (c) 2013, Peter Sturm, Universität Trier 8

9 #include header.h" Ein Beispiel- void my_rpc_server_1( char* host ) { CLIENT *clnt; i_result *result_1; i_param add_1_arg; clnt = clnt_create(host, MY_RPC_SERVER, MY_VERSION_1, "udp"); add_1_arg.a1 = 12; add_1_arg.a2 = 17; result_1 = add_1(&add_1_arg, clnt); printf( Die Summe ist %d\n,result_1- >x); clnt_destroy( clnt ); main( int argc, char* argv[] ) { char *host; if(argc < 2) { printf("usage: %s server_host\n", argv[0]); exit(1); host = argv[1]; my_rpc_server_1( host ); - Lokalisierung Angabe von IP- Adresse des - Hosts RPC- Service Version des RPC- Service Port 1 Portmapper liefert UDP- oder TCP- Port des gewünschten s 2 4 Port 111 Portmapper Port 3 Registrierte RPC- (c) 2013, Peter Sturm, Universität Trier 9

10 Interaktive Abfrage des Portmappers rpcinfo - p balvenie.uni- trier.de program vers proto port tcp 111 portmapper udp 111 portmapper udp 789 ypserv udp 789 ypserv tcp 792 ypserv udp 790 yppasswdd udp 792 ypbind tcp 794 ypbind udp 2049 nfs tcp 2049 nfs udp 829 mountd udp 829 mountd tcp 832 mountd tcp 832 mountd OO- RPC (c) 2013, Peter Sturm, Universität Trier 10

11 Hinzunahme eines Objektbezugs Feinere Granularität Integration in OO- Sprache Keine eigenständige IDL Interfacebeschreibung Attribute (z.b..net) Annotationen (z.b. Java) Stub- Generierung Reflektive Programmierung Objektorientierter RPC JAVA RMI (c) 2013, Peter Sturm, Universität Trier 11

12 Java RMI Remote Method Invocation Java- basierte OO- Variante eines RPC Objekte inkl. Code können ausgetauscht werden Vorteil einer homogenen Sprachumgebung Sicherheitsproblematik Function Shipping Direkte Unterstützung im JDK Aktuelle Version des JDK nutzt Reflection für die Generierung der Proxies Architektur RMI RMI RMI RMI rmiregistry RMI URL Protocol Web URL Protocol Web (c) 2013, Peter Sturm, Universität Trier 12

13 ... ein Interface Am Anfang war... package syssoft.rmi_example; import java.rmi.remote; import java.rmi.remoteexception; public interface Compute extends Remote { int Add ( int x, int y ) throws RemoteException; int Sub ( int x, int y ) throws RemoteException; Ableitung von Marker- Interface Remote (leer) Erkennen RMI- zugänglicher Interfaces über Reflection Remote- Methoden werfen RemoteException Zugeständnis an mögliche Fehlerfälle in verteilten Systemen package syssoft.rmi_example.server; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; import java.rmi.server.unicastremoteobject; import syssoft.rmi_example.*; public class implements Compute { public () { super(); public int Add ( int x, int y ) { return x+y; public static void main(string[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); try { String name = "SyssoftCompute"; Compute engine = new (); Compute stub = (Compute) UnicastRemoteObject.exportObject(engine,0); Registry registry = LocateRegistry.getRegistry(); registry.rebind(name, stub); System.out.println("ComputeEngine bound"); catch (Exception e) { System.err.println("ComputeEngine exception:"); e.printstacktrace(); (c) 2013, Peter Sturm, Universität Trier 13

14 package syssoft.rmi_example.client; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; import syssoft.rmi_example.*; public class { public static void main(string[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); try { String name = "SyssoftCompute"; Registry registry = LocateRegistry.getRegistry(args[0]); Compute comp = (Compute) registry.lookup(name); int result = comp.add(21, 21); System.out.println(result); catch (Exception e) { System.err.println("SyssoftCompute exception:"); e.printstacktrace(); # Compiling, packaging, and distributing the interface javac syssoft/rmi_example/compute.java jar cvf run/compute.jar syssoft/rmi_example/compute.class cp run/compute.jar ~peter/sites 42 # Preparing the server javac - cp run/compute.jar syssoft/rmi_example/server/.java # Preparing the client javac - cp run/compute.jar syssoft/rmi_example/client/.java # Starting RMI registry # rmiregistry & # Running server java - cp.:run/compute.jar - Djava.rmi.server.codebase= Compute.jar - Djava.rmi.server.hostname=localhost - Djava.security.policy=run/server.policy syssoft.rmi_example.server. & sleep 10 # Running client java - cp.:run/compute.jar - Djava.rmi.server.codebase= - Djava.security.policy=run/client.policy syssoft.rmi_example.client. localhost (c) 2013, Peter Sturm, Universität Trier 14

15 .NET Remoting Interface (c) 2013, Peter Sturm, Universität Trier 15

16 Implementierung (c) 2013, Peter Sturm, Universität Trier 16

17 KRITIK RPC (c) 2013, Peter Sturm, Universität Trier 17

18 Eine Kritik A.S. Tanenbaum, R. van Renesse, A Critique of the Remote Procedure Call Paradigm, in: Research into Networks and Distributed Applications R. Speth (Hrsg.), Elsevier Science Publishers, pp , pdf A Critique of the Remote Procedure Call Paradigm Andrew S. Tanenbaum Robbert van Renesse Dept. of Mathematics and Computer Science Vrije Universiteit Postbus MC Amsterdam, The Netherlands The remote procedure call paradigm is widely used in distributed operating systems. It is conceptually simple to use and straightforward to implement. Nevertheless, experience has shown that it also has some subtle, but less pleasant aspects. In this paper we discuss problems with RPC in the areas of conceptual problems with the model itself, technical problems with implementing it, problems caused by client and server crashes, problems caused by heterogeneous systems, and performance problems. The paper concludes with a discussion and analysis of the problems and proposed solutions. Probleme Ideal: RPC = LPC LPC- Semantik wird nur unvollständig errreicht Konzeptionelle Probleme Verletzung der Transparenz Behandlung von Ausfällen Performance- Probleme (c) 2013, Peter Sturm, Universität Trier 18

19 RPC- Probleme (1) Fileserver Who is Who? sind passiv, s aktiv! Beispiel: Datei- : p1 < f1 p2 p3 > f2 Wechsel in der /- Rolle hat z.b. wichtige Information, aber erwartet keine Nachricht vom Anzahl und Typen der Parameter Nur bei typstrengen Sprachen problemlos Beispiel printf() Parameterübergabe Call- by- Value Call- by- Reference? Call- by- Copy/Restore p1 p2 p3 RPC- Probleme (2) Abstürze und Nachrichtenverluste gibt es bei LPC nicht Exceptionmechanismus (Transparenzverletzung) Aufrufsemantik (Exactly- Once ideal, geht aber nicht) Zustandsverluste bei / Waisenkinder (Orphans) Zustandsmüll abgestürzter s beim Einschränkungen in der Parallelität ASRI komplexer Kein Streaming möglich LPC ist Strukturierungsmittel Nicht jede lokale Prozedur würde man als Remote Procedure realisieren Conceptual Mismatch (c) 2013, Peter Sturm, Universität Trier 19

20 Semantiken Ideale Semantik: Exactly- Once- Semantik Entfernter Dienstaufruf findet genau einmal statt Realität: Fehlerfälle Verlust von Nachrichten - Abstürze Realisierbare Semantiken At- Least- Once- Semantik Dienstaufruf findet mindestens einmal statt Aufträge können mehrfach ausgeführt werden At- Most- Once- Semantik Dienstaufruf findet höchstens einmal statt Aufträge dürfen nicht wiederholt werden Umsetzung At- Least- Once Einfacher while (1) { receive(job) from client; // Auftrag ausführen send(reply) to client; Mehrfachausführung in vielen Fällen unkritisch Uhrzeit abfragen Datei lesen? At- Most- Once Komplexer while (1) { receive(job) from client; if (neuer Auftrag) { // Auftrag ausführen send(reply) to client; Wie erkennt man neuen Auftrag? Zustand Idempotenz wünschenswert (c) 2013, Peter Sturm, Universität Trier 20

21 Fehlerfälle im Detail Nachrichtenzuordnung erkennen sendet Auftrag k und erhält kein Reply Situation beim Timeout Auftragsnachricht ging verloren Reply- Nachricht ging verloren Reply unterwegs vor Auftragsbearbeitung abgestürzt während der Auftragsbearbeitung abgestürzt bearbeitet noch Auftrag... Nachrichtenwiederholung Auftrag ΔT - Abstürze Schnellstmöglicher Ersatz des ausgefallenen s Elektion unter den Ersatzservern Neustart eines Ersatzservers Zustandsverluste Partieller oder vollständiger Gedächtnisverlust Amnesia Failures At- Least- Once Unkritisch At- Most- Once Ersatzserver: Wurde der Auftrag schon ausgeführt? Unter Umständen aufwendiges Loggen (c) 2013, Peter Sturm, Universität Trier 21

22 Zustandsbehafteter Relevanter zustand Zustand für korrekte Diensterbringung notwendig Zustand der verbindung Information über kausal abhängige Auftragsfolgen Liste der ausgeführten Aufträge (At- Most- Once) Nicht gemeint sind lokale Variablen u.ä. Dateien eines Dateiservers Primär leistungssteigernde Maßnahme c State c Umgehen der Zustandsproblematik Zustandslose Verlagerung des relevanten Zustands in den speichert Zustandsinformation Notwendige Zustandsinformation ist Teil des Auftrags Reply aktualisiert auch client- seitigen Zustand Nachteile Größere Nachrichten State c State c State c (c) 2013, Peter Sturm, Universität Trier 22

23 Idempotente Aufträge Wiederholung desselben Auftrags liefert dasselbe Ergebnis Viele Aufträge inhärent idempotent Lösung bei nicht- idempotenten Aufträgen Aufträge enthalten alle notwendige Zustandsinformation Zustandsloser Rätselecke: Gibt es inhärent nicht- idempotente Aufträge? Wie werden diese trotzdem idempotent? Speicherung fertiggestellter Aufträge Bei Wiederholungsauftrag gespeichertes Reply erneut zurücksenden Wann kann man gespeicherte Replies löschen? Dilemma Zustandsbehafteter unumgänglich ΔT Lösung Auftrag Reply Reply speichern Auftrag wdh Reply (c) 2013, Peter Sturm, Universität Trier 23

24 Realisierungsaspekte - Realisierungen Iterativer Maximal ein Auftrag in Bearbeitung Vorteile Einfache Realisierung Nachteile Unter Umständen lange Antwortzeiten Reihenfolge der Bearbeitung liegt fest Konkurrenter Mehrere Aufträge gleichzeitig in Bearbeitung Vorteile Leistungssteigerung (Multiprozessor, Auftragsreihenfolge, Blockadezeiten) Nachteile Komplexere Realisierung Synchronisation (c) 2013, Peter Sturm, Universität Trier 24

25 Realisierungsvarianten Multiplex- unterteilt größere Aufträge selbst in kleinere Einheiten Explizite Verwaltung der Bearbeitungszustände Problematik: Blockierende Systemaufrufe Asynchrone Lösungen Multithreaded Leichtgewichtige Threads in einem Adreßraum Kommunikation über gemeinsamen Speicher Speicherbasierte Synchronisation Multi- Process Mehrere Prozesse Typische Organisationsform: Manager und Worker- Pool Kommunikation über Nachrichten Verteilte Synchronisationsverfahren Beispiel: Der Schlafserver Auswirkungen der varianten untersuchen Kommunikationskosten nicht meßrelevant Einfache TCP- Realisierung schläft für die angegebene Zeit Vergleichbar einer E/A- Blockade Block lesen und schreiben Netzkommunikation (Auftrag an weiteren ) Synchronisation Done Sleep 200 (c) 2013, Peter Sturm, Universität Trier 25

26 int main ( int ac, char ** av ) { TCP_Socket sock; _Address saddr; Der Schlafclient host = av[1]; port = av[2]; loops = av[3]; delay = av[4]; saddr = _Address(host,port); sock.connect(saddr); watch.start(); for (int i=0;i<loops;i++) { sprintf(buf, sleep %d,delay); sock.send(buf,strlen(buf)); sock.receive(buf,sizeof buf); assert(strcmp(buf, done ) == 0); watch.stop(); average_delay = watch.msecs() / loops; 1. Iterativer (Single- Haushalt) int main ( int ac, char **av ) { TCP_Socket asock; TCP_Socket *csock; asock.bind(); printf( Sleeping at port %d\n,asock.port()); while (1) { csock = asock.accept(); csock- >receive(buf,sizeof buf); sscanf(buf, sleep %d,&delay); if (delay>0) sleep(delay); sprintf(buf, done ); csock- >send(buf,strlen(buf)); delete csock; (c) 2013, Peter Sturm, Universität Trier 26

27 3. Multi- Process (Hotel) int main ( int ac, char **av ) { TCP_Socket asock; TCP_Socket *csock; asock.bind(); printf( Sleeping at port %d\n,asock.port()); while (1) { csock = asock.accept(); if (fork() == 0) { csock- >receive(buf,sizeof buf); sscanf(buf, sleep %d,&delay); if (delay>0) sleep(delay); sprintf(buf, done ); csock- >send(buf,strlen(buf)); exit(); delete csock; 2. Multithreaded (WG) (c) 2013, Peter Sturm, Universität Trier 27

28 Neuerzeugen oder Wiederverwenden Betrifft Worker in einem konkurrenten Neuerzeugung eines Workers Vorteile Gute Ressourcenbelegung Einfache Implementierung Nachteile Höhere Latenz Wiederverwendung der beendeten Worker- Hülsen Vorteile Geringere Latenz Nachteile Belegung von Systemressourcen Komplexe Implementierung (c) 2013, Peter Sturm, Universität Trier 28