Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Verteilte Systeme 11. Client/Server-Systeme
Rückblick: Client/Server auf einem Rechner
I I
Verbreitete Systemarchitektur Verlagerung von Kernfunktionen in ServerServer-Prozesse
Server
– Mikrokern – Server im UserUser-Modus I
Vorteile – EntwicklungsEntwicklungs- und Testmethoden für Anwendungen auf Server übertragbar – Erweiterbarkeit, Austauschbarkeit
I
Nachteile
Client
Server Server
Hardware
– Zusätzliche Kontextwechsel – Weitergabe von HardwareHardwareEreignissen (Interrupts (Interrupts)) – Zugriff auf Geräteregister Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.2
1
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
I
Betriebssystem
Betriebssystem
Rechner 1
Rechner 2
Lokale Server
I
– Dateisystem – EinEin- und Ausgabedienste (Graphik, Kommunikation, ...) – Prozeßverwaltung, Prozeßverwaltung, Paging, Paging, ...
Server
Server
Client
Client
Server
Server
Client
Client
Client/ServerClient/Server-Architektur
Entfernte Server – – – – –
Netzwerkdateisystem, z.B. NFS Verteiltes Dateisystem Rlogin, Rlogin, Telnet, ... WWWWWW-Server (httpd (httpd)) Uhrensynchronisation (ntp (ntp))
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.3
Realisierungsvarianten C
S
KS
C
KS
I
Kommunikationsserver
I
Kernkommunikation
I
Vorteile
I
Vorteile
– Erweiterbarkeit – Einfacher Kern I
Nachteile – Zusätzliche Kontextwechsel – Höhere Nachrichtenlaufzeit
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
S
– Minimale Verzögerungen – Schnelle Übertragung I
Nachteile – Kernänderung bei Erweiterungen – Komplexer Kern – Routing, Routing, ...
Folie 11.4
2
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Kommunikation in Client/ServerClient/Server-Architekturen I
SRSI „sehr schöne“ Abstraktion – send und receive nicht explizit sichtbar – Kapselung der Dienste in eine Art Prozeduraufruf
I
Sender send()
receive()
Remote Procedure Call (RPC) RPC) – „Der“ SRSISRSI-Vertreter – Idee: RPC = Lokaler Prozeduraufruf – Birrell und Nelson, 1984
I
Empfänger
reply() receive()
Grundlage für Client/ServerClient/Server-Systeme – Server: Passiv, bietet Dienste an – Client: Aktiv, ruft Dienste auf
I
Alternative: Asynchroner entfernter Dienstaufruf
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.5
RPCRPC-Architektur
Lokaler Prozeduraufruf:
Anwendung r := f(p); f
Client
Server
r := rp(p);
rp
3
1 Client-Stub rp
6
Server-Stub rp
4
send/receive Betriebssystem
Betriebssystem
Rechner
Rechner 2
5 Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Netzwerk
Folie 11.6
3
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Semantiken I
Ideale Semantik: ExactlyExactly-OnceOnce-Semantik – Entfernter Dienstaufruf findet genau einmal statt
I
Realität: Fehlerfälle – Verlust von Nachrichten – ServerServer-Abstürze
I
Realisierbare Semantiken – AtAt-LeastLeast-OnceOnce-Semantik Dienstaufruf findet mindestens einmal statt I Aufträge können mehrfach ausgeführt werden I – AtAt-MostMost-OnceOnce-Semantik Dienstaufruf findet höchstens einmal statt I Aufträge dürfen nicht wiederholt werden I
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.7
Umsetzung AtAt-LeastLeast-Once I
Einfacher Server
AtAt-MostMost-Once I
while (1) { receive(job) from client; // Auftrag ausfü ausführen send(reply) to client; } I
Mehrfachausführung in vielen Fällen unkritisch – Uhrzeit abfragen – Datei lesen?
I
Komplexer Server while (1) { receive(job) from client; if (neuer (neuer Auftrag) Auftrag) { // Auftrag ausfü ausführen } send(reply) to client; }
I
Wie erkennt man neuen Auftrag? – Zustand
Idempotenz wünschenswert
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.8
4
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Fehlerfälle im Detail
Client Auftrag
I
Annahme: Alle zu einem Auftrag gehörenden Protokollnachrichten sind identifizierbar – Z.B. fortlaufende Auftragsnummer
I
Client sendet Auftrag k und erhält längere Zeit kein Reply
I
Situation beim Timeout – – – – – – –
∆T
Auftragsnachricht ging verloren ReplyReply-Nachricht ging verloren Reply unterwegs Server vor Auftragsbearbeitung abgestürzt Server während der Auftragsbearbeitung abgestürzt Server bearbeitet noch Auftrag ...
I
In allen Fällen Nachrichtenwiederholung sinnvoll
I
... und wie geht es weiter?
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.9
ServerServer-Abstürze I
Schnellstmöglicher Ersatz des ausgefallenen Servers – Elektion unter den Ersatzservern – Neustart eines Ersatzservers
I
Zustandsverluste – Partieller oder vollständiger Gedächtnisverlust – Amnesia Failures
I
AtAt-LeastLeast-Once – Unkritisch
I
AtAt-MostMost-Once – Ersatzserver: Wurde der Auftrag schon ausgeführt? – Unter Umständen aufwendiges Loggen
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.10
5
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Zustandsbehafteter Server I
Relevanter Serverzustand – Zustand für korrekte Diensterbringung notwendig Zustand der Clientverbindung I Information über kausal abhängige Auftragsfolgen I Liste der ausgeführten Aufträge (At I (At--MostMost-Once) Once) ... I – Nicht gemeint sind lokale Variablen u.ä. I u.ä. Dateien eines Dateiservers I
I
Primär leistungssteigernde Maßnahme Client c
Server State c
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.11
Zustandslose Server I
Umgehen der Zustandsproblematik
I
Verlagerung des relevanten Zustands in den Client – Client speichert Zustandsinformation – Notwendige Zustandsinformation ist Teil des Auftrags – Reply aktualisiert auch clientclient-seitigen Zustand
I
Nachteile – Größere Nachrichten State c Client State c
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Server State’ c
Folie 11.12
6
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Beispiel: Dateiserver I
I
Client: fd = send(OPEN,name,READ) to server; data = send(READ,fd) to server; ... Send(CLOSE) to server;
Ausgangspunkt: Zustandsbehafteter Server Elemente des Serverzustands – Dateideskriptor (explizit) – Aktuelle Position innerhalb der Datei (implizit) – Dateipuffer (implizit) – ...
I
Auswirkungen der Semantik – AtAt-MostMost-Once? Once? – AtAt-LeastLeast-Once? Once?
I
Server: receive(OPEN,name,mode) from client { fd = open(name,mode,...); reply(fd) to client; } receive(READ,fd) from client { data = read(fd,...); reply(data) to client; }
ServerServer-Absturz?
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.13
Verlagerung des Serverzustands I
Kein serverseitiger Deskriptor – Übermittlung des symbolischen Dateinamens in jedem Auftrag – Speicherung der Leseposition auf Clientseite
I
I
Client: data = send(READ,name,pos) to server; ...
Öffnen und Schließen einer Datei erübrigt sich Auswirkungen auf Semantik – AtAt-MostMost-Once? Once? – AtAt-LeastLeast-Once? Once?
I
ServerServer-Absturz
I
Weitere Probleme
Server: receive(READ,name,mode) from client { fd = open(name,mode,...); lseek(fd,pos,...); data = read(fd,...); reply(fd) to client; close(fd); }
– Sperren von Dateien? – Performanz Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.14
7
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Unkritischer Serverzustand I
I
I
„Caching“ Caching“ von Serverzustand auch in einem zustandslosen Server möglich
Client: data = send(READ,name,pos) to server; ...
Vollständiger Zustand aus Auftrag wieder herleitbar Gelegentliches Aufräumen
Server: receive(READ,name,mode) from client { if ((name,client) in cache) fd = cached_fd(name,client); else { fd = open(name,mode,...); lseek(fd,pos,...); } data = read(fd,...); reply(fd) to client; close(fd); }
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.15
Idempotente Aufträge I
Wiederholung desselben Auftrags liefert dasselbe Ergebnis
I
Viele Aufträge inhärent idempotent
I
Lösung bei nichtnicht-idempotenten Aufträgen – Aufträge enthalten alle notwendige Zustandsinformation – Zustandsloser Server
I
Rätselecke: – Gibt es inhärent nichtnicht-idempotente Aufträge? – Wie werden diese trotzdem idempotent? idempotent?
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.16
8
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Lösung Client I
I
I
I
Server
Speicherung fertiggestellter Aufträge Bei Wiederholungsauftrag gespeichertes Reply erneut zurücksenden
Auftrag
∆T
Wann kann man gespeicherte Replies löschen? Dilemma – Zustandsbehafteter Server unumgänglich
Reply
Reply speichern
Auftragwdh
Reply
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.17
ServerServer-Realisierungen I
Iterativer Server – Maximal ein Auftrag in Bearbeitung – Vorteile Einfache Realisierung I – Nachteile Unter Umständen lange Antwortzeiten I Reihenfolger der Bearbeitung liegt fest I
I
Konkurrenter Server – Mehrere Aufträge gleichzeitig in Bearbeitung – Vorteile I Leistungssteigerung (Multiprozessor, Auftragsreihenfolge, Blockadezeiten) – Nachteile Komplexere Realisierung I Synchronisation I
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.18
9
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Realisierungsvarianten eines konkurrenten Servers I
MultiplexMultiplex-Server – Server unterteilt größere Aufträge selbst in kleinere Einheiten – Explizite Verwaltung der Bearbeitungszustände – Problematik: Blockierende Systemaufrufe
I
Multithreaded Server – Leichtgewichtige Threads in einem Adreßraum – Kommunikation über gemeinsamen Speicher – Speicherbasierte Synchronisation
I
MultiMulti-Process Server – – – –
Mehrere Prozesse Typische Organisationsform: Manager und WorkerWorker-Pool Kommunikation über Nachrichten Verteilte Synchronisationsverfahren
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.19
Neuerzeugen Neuerzeugen oder Wiederverwenden I
Betrifft Worker in einem konkurrenten Server
I
Neuerzeugung eines “Workers” – Vorteile Gute Ressourcenbelegung I I Einfache Implementierung – Nachteile Höhere Latenz I
I
Wiederverwendung der beendeten “Worker“Worker-Hülsen” Hülsen” – Vorteile I Geringere Latenz – Nachteile Belegung von Systemressourcen I Komplexe Implementierung I
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.20
10
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
Beispiel: Beispiel: Der Schlafserver I
Auswirkungen der Servervarianten untersuchen – Kommunikationskosten nicht meßrelevant – Einfache TCPTCP-Realisierung
I
I
Client
Server “schläft “schläft”” für die angegebene Zeit
Sleep 200
Vergleichbar einer E/AE/A-Blockade – Block lesen und schreiben – Netzkommunikation (Auftrag an weiteren Server) – Synchronisation
Done
Verteilte Systeme, Wintersemester 2000/2001
Server
Folie 11.21
Der Schlafclient I
int main ( int ac, char ** av ) { TCP_Socket sock; Server_Address saddr; saddr; host = av[1]; av[1]; port = av[2]; av[2]; loops = av[3]; av[3]; delay = av[4]; av[4]; saddr = Server_Address( Server_Address(host,port); host,port); sock.connect( sock.connect(saddr); saddr); watch.start(); watch.start(); for (int (int i=0;i< i=0;ireceive(buf,sizeof >receive(buf,sizeof buf); buf); sscanf( sscanf(buf,”sleep %d”,&delay); %d”,&delay); if (delay>0) sleep(delay); sprintf( sprintf(buf,”done”); buf,”done”); csock(buf)); csock->send(buf,strlen >send(buf,strlen( buf)); delete csock; csock; } }
Verteilte Systeme, Wintersemester 2000/2001
Folie 11.23
2. Multithreaded Server (WG (WG)) I
Übung
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.24
12
Vorlesung "Verteilte Systeme"
Wintersemester 2000/2001
3. MultiMulti-Process Server (Hotel) I
int main ( int ac, char **av ) { TCP_Socket asock; asock; TCP_Socket *csock; *csock; asock.bind(); asock.bind(); printf(“Sleeping printf(“Sleeping at port %d\ %d\n”,asock.port()); n”,asock.port()); while (1) { csock = asock.accept(); asock.accept(); if (fork() == 0) { csockcsock->receive(buf,sizeof >receive(buf,sizeof buf); buf); sscanf( sscanf(buf,”sleep %d”,&delay); %d”,&delay); if (delay>0) sleep(delay); sprintf( sprintf(buf,”done”); buf,”done”); csock(buf)); csock->send(buf,strlen >send(buf,strlen( buf)); exit(); } delete csock; csock; } }
Verteilte Systeme, Wintersemester 2000/2001
(c) Peter Sturm, Universität Trier
Folie 11.25
13
