Verteilte Systeme Kapitel 4: Realisierung von Netzwerkdiensten

Transkript

1 Verteilte Systeme Kapitel 4: Realisierung von Netzwerkdiensten Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck

2 Inhaltsüberblick der Vorlesung 1. Einführung und Motivation 2. Protokolle und Schichtenmodelle 3. Nachrichtenrepräsentation 4. Realisierung von Netzwerkdiensten 5. Kommunikationsmechanismen 6. Adressen, Namen und Verzeichnisdienste 7. Synchronisation 8. Replikation und Konsistenz 9. Fehlertoleranz 10.Verteilte Transaktionen 11.Sicherheit 1-2

3 Übersicht Sockets Realisierungsmöglichkeiten Super-Server Single-Process / Single-Thread Multi-Process Multi-Thread Multi-Process und multi-thread Event-Driven High-Performance Servers 3

4 Sockets

5 Sockets Abstraktion für Interprozesskommunikation Inter Process Communication (IPC) Via IPv4, IPv6, Unix-IPC,... De facto-standard: BSD/Berkeley Sockets API (heute: POSIX) Kommunikation zwischen Prozessen Socket API Socket API IPC / TCP / UDP 5

6 BSD Sockets: Eigenschaften Kernabstraktion von Unix Everything is a file Auch bei Sockets konsequent angewendet Verbindungen abstrahiert über File-Deskriptoren Standardfunktionen für Dateien können verwendet werden (read/write/close) Anwendungen müssen nicht zwingend netzwerkfähig sein Super-Server (später) 6

7 Sockets: Server Erzeuge Socket socket_fd socket(familie, Typ, Protokoll) Binde Socket (z.b. an IP+Port) bind(socket_fd, Adresse) Markiere socket als passiv ( Server) listen(socket_fd, backlog-queue-size) Server Warte auf Verbindung peer_fd accept(socket_fd, Peer-Adresse*) Datenaustausch (via peer_fd) Datenaustausch beenden close(peer_fd) Server-Socket schließen close(socket_fd) 7

8 Server Bsp: IPC 8

9 Sockets: Client Erzeuge Socket socket_fdsocket(familie, Typ, Protokoll) Verbinde Socket connect (socket_fd, Adresse) Client Datenaustausch (via socket_fd) Datenaustausch beenden close(socket_fd) 9

10 Beispiel: Unix-Socket Client 10

11 BSD Sockets: Unterstützte Protokolle PF: Protocol Family AF: Address Family Ursprünglich getrennte Konzepte, heute: gleiche Bedeutung Name PF_UNIX, PF_LOCAL PF_INET PF_INET6 PF_IPX PF_NETLINK PF_X25 PF_AX25 PF_ATMPVC PF_APPLETALK PF_PACKET Beschreibung Lokaler IPC IPv4 Internet Protokolle IPv6 Internet Protokolle IPX - Novell protocols Kernel user interface device ITU-T X.25 / ISO-8208 Protokolle Amateurfunk AX.25 Protokoll Zugriff auf ATM PVCs Appletalk OSI Layer 2 Zugriff 11

12 BSD Sockets: Unterstützte Socket Typen SOCK_STREAM Verbindungsorientiert Zuverlässig Bidirektional Reihenfolgenerhaltend SOCK_DGRAM (Datagram) Verbindungslos Unidirektional Nicht zuverlässig Obere Grenze der Nachrichtenlänge Weitere Typen SOCK_SEQPACKET (Bidirektionaler, zuverlässiger, reihenfolgenerhaltender Datagramdienst) SOCK_RAW (Raw packet access) SOCK_RDM (zuverlässiger Datagramdienst, keine garantierte Reihenfolge) SOCK_PACKET (obsolet) 12

13 Super-Server

14 Super-Server Trennung von Netzwerk- und Anwendungsfunktionalität Sog. Super-Server akzeptiert Verbindungen Reicht empfangene Daten als Datenstrom an zuständiges Programm weiter Liest von Socket-Datenstrom und schreibt Daten auf Standardeingabe-Strom des zuständigen Programms (Pipe) Sendet Ausgaben des Programms an verbundenen Client Pipe von Standardausgabe nach Socket-Strom Process #1 Process #2 Super Server Client Client Process #3 Client 14

15 Super-Server Vorteil Sehr einfache Implementierung Kann mit beliebigen Quellen/Senken verwendet werden (Files, Tastatur,...) Nachteile: Performance Ein Prozess pro Verbindung Für jeden Request wird ein Prozess gestartet (Startverzögerung) Beispiel: inetd / xinetd unter Linux Process #1 Process #2 Super Server Client Client Process #3 Client 15

16 Beispiel: /etc/inetd.conf Dienste werden in /etc/inetd.conf registriert Servicename: Muss in /etc/services eingetragen sein 16

17 Inetd Server: Beispiel 17

18 Concurrent Server

19 Iterative vs. Concurrent Server Bisher: Iterative Server Können nur einen Client zur gleichen Zeit bedienen Problem der Skalierbarkeit Lösung: Concurrent Server Varianten Multi-Process (Fork-on-Request, Pre-Fork) Multi-Thread (Thread-on-Request, Thread-Pooling) Multi-Process & Multi-Thread Event-Driven 19

20 Multi-Process Server Jeder Request wird in eigenem Prozess verarbeitet Bessere Skalierbarkeit als iterative Server Eigenschaften Hohe Stabilität (Absturz von Prozessen beeinflusst keine anderen Anfragen) Erhöhter Overhead durch Prozesserzeugung (Delay/Jitter) Erschwerte Abstimmung zwischen einzelnen Anfragen (getrennte Prozesse IPC) Varianten Fork-on-Request (Prozess erstellen bei Empfang eines Requests) Pre-Fork (Menge von Prozessen stehen bereit um Requests zu verarbeiten) 20

21 Beispiel: Fork-on-Request Server Details auf nächster Folie 21

22 Beispiel: Fork-on-Request Server fork() erzeugt Kopie des Prozesses Rückgabewert: - PID des neuen Prozesses im Vater-Prozess - 0 im Kind-Prozess 22

23 Multi-Thread Server Jeder Request wird in eigenem Thread verarbeitet Eigenschaften Weniger Overhead als ein Prozess pro Request Nachteil: Geteilter Speicher Sicherheit / Stabilität gefährdet Varianten Thread-on-Request Thread-Pooling 23

24 Multi-Process und Multi-Thread Ein Prozess delegiert Requests an Threads in verschiedenen Prozessen Kombiniert Vorteile von Multi-Process und Multi-Thread Vorteile Performanz durch Multi-Threading Stabilität durch Multi-Prozess Implementiert im Apache Webserver 24

25 Event-Driven Servers Problem von Multi-Prozess/Multi-Thread Potenziell mehrere sequentielle Requests pro Verbindung Langlebige Verbindungen: Zwischen Requests wird ein Prozess/Thread blockiert Beispiel: HTTP Keep-Alive Event-Driven Servers Anstelle einer Verbindung wird ein Request auf einen Prozess/Thread verteilt Wird z.b. vom Apache Webserver implementiert ( 25

26 High-Performance Servers

27 High-Performance Servers Performance von Anwendungen sehr wichtig Extrem gestiegene Nutzerzahlen Hohe Bandbreiten verfügbar Nutzer verlange schnelle Anwendungen Energieeffizienz wichtig Kosten Bei der Implementierung müssen Flaschenhälse vermieden werden Statischer vs. dynamisch generierter Inhalt Statisch: File-Server (Grafiken, Dokumente,...) Dynamisch: PHP, Servlets,... 27

28 File-Server: Traditioneller Ansatz Daten von Festplatte lesen und auf Socket schreiben 28

29 File-Server: Traditioneller Ansatz Problem: Kopiervorgänge und Kontextwechsel zwischen Kernel- und Userspace Performance Gut Read Buffer Socket Buffer NIC Buffer Schlecht Kernel Context Application Context App Application Buffer 29

30 File-Server: Zero-Copy Ansatz Daten werden via Direct Memory Access (DMA) im Kernel kopiert Keine CPU-Belastung Keine Belastung der Memory-Bandbreite Kein Kopiervorgang zwischen Kernel- und Userspace Gut Read Buffer Socket Buffer NIC Buffer Perfekt! Auftrag Kernel Context Application Context App Application Buffer 30

31 Zero-Copy mit Java NIO 31

32 Einfacher Benchmark: Copy vs. Zero-Copy 32

33 High-Performance Servers Nicht nur kopieren zwischen Kernel- und User-Space ist problematisch Auch häufiges Kopieren im gleichen Space (User-und Kernel-) kostet Performance Application HTTP XML Payload Transport TCP App-Payload Internet IP IP-Payload Link Layer Ethernet 33

34 High-Performance Servers Häufig ist das Kopieren nicht notwendig Werden die Daten nicht verändert, so kann ein Ausschnitt des Puffers unverändert weitergereicht werden Beispiel: ChannelBuffer-Klasse in JBoss Netty ( Application Transport Ethernet IP TCP HTTP XML Ethernet IP TCP HTTP XML Ethernet IP TCP HTTP XML Internet Ethernet IP TCP HTTP XML Link Layer Ethernet IP TCP HTTP XML 34

35 Zusammenfassung Sockets, Prozesse und Threads sind technische Grundlage für Kommunikation Vielfalt an Realisierungsmöglichkeiten Trade-Off zwischen Komplexität und Performanceanforderungen Zero-Copy-Ansätze zur effizienten Implementierung 35