Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Modul: B-BS Betriebssysteme SS 2014 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik.

Ähnliche Präsentationen


Präsentation zum Thema: "Modul: B-BS Betriebssysteme SS 2014 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik."—  Präsentation transkript:

1

2 Modul: B-BS Betriebssysteme SS 2014 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik (12) Netzwerkdienste

3 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 2 Dienste im Netz Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Netzwerke Netzwerkdienste

4 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 3 Netzwerkdienste Netzwerk-Nutzen electronic mail Kommunikation: Terminabsprachen, Projektkoordination, Mitteilungen,... file sharing keine multiplen Kopien: Dateikonsistenz, Speichererparnis device sharing bessere Druckerauslastung, lohnende Anschaffung von Spezialhardware (Farblaserdrucker, high-speed-scanner,...) processor sharing Zeitersparnis durch bessere Prozessorauslastung bei Lastverteilung und /oder Kostenersparnis durch geringere Investitionen

5 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 4 Netzwerkdienste Verteilte Betriebssysteme Verteiltes System: Aufteilung von Funktionen in einem Rechnernetz, wobei BS auf jedem Rechner ex. Verteiltes Betriebssystem: Jede BS-Funktion ex. nur einmal im Netz

6 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 5 MACH- Betriebssystemkern Mach-Kern Scheduler, Nachrichtenübermittlung, Basic I/O, Speicherobjekte Speicher Manager File Manager Terminal I/O Benutzer- programm user mode kernel mode Hardware Mikrokern  Vorteile: minimaler Kern, alle Funktionen modularisiert austauschbar  Nachteile: Kommunikationsdauer zwischen Managern Netzwerkdienste

7 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 6 Netzwerkdienste Verteilte Betriebssysteme Vorteile Flexibilität inkrementelle Erweiterbarkeit um neue Dienste Transparenz durch ortsunabhängige Dienste Leistungssteigerung bei Lastverteilung Fehlertoleranz bei multiplen, gleichen Diensten Nachteile Leistungseinbuße durch Kommunikationsverzögerung Keine Fehlertoleranz wenn Funktion nur einmal vorhanden Fazit Alle BS sind Mischsysteme aus netzbasierten & lokalen BS-Funktionen; es ex. kein „reines“ System

8 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 7 Netzwerkdienste Netzwerke- Grundbegriffe Hub Switch Router “Backbone-Router” Subnetz mit Stern - Netzarchitektur Backbone Subnetz zum Internet Repeater

9 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 8 Netzwerkdienste Netzwerkschichten OSI-ISO Schichten virtueller Maschinen End-to-End Verbindung: portable Software Vorteil Systematische, portable Einteilung Nachteil zu starr und damit zu langsam Lösung Zusammenfassung von Schichten Rechner A virtuelle P2P-Verbindungen Rechner B B Netzkabel 7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbindung 7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbindung Transport

10 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 9 Layer 7 : Layer 7 : Anwendungsschicht High-level Programme: FTP, Grafik, electronic mail,... Layer 6 : Layer 6 : Präsentationsebene Datenformatierung, Kodierung, Gruppierung (Records, Verschlüsselung, ) Layer 5 : Layer 5 : Sitzungsebene open/close-Semantik: Sender, Empfänger, high-level-Fehlerbehandlung, logon-passwords, Daten/Kontrollunterscheidung,... Layer 4 : Layer 4 : Transportschicht Umwandlung in Datenpakete, Reihenfolge der Pakete, usw.Bei TCP (Transmission Control Protocol): Fehlertoleranzgrad TP0-4 festlegen Layer 3 : Layer 3 : Netzwerkschicht Fragen der Netztopologie: Übertragungsweg, Umleitung (routing), Netzstatus, Grenzen, Auslastung, usw. Typisch: Internet Protocol IP Layer 2 : Layer 2 : Datenverbindung Datenpakete  Unterteilung in log. Signalframes, Wiederholung bei NO-ACK. Aber: Frame-Reihenfolge ist unkontrolliert. Z.B.: Ethernet Layer 1 : Layer 1 : physikalische Signale Bits  Impulse, Freq. z.B.10BaseT Netzwerkdienste Netzwerkschichten OSI-ISO

11 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 10 Netzwerkdienste Netzwerkschichten Kapselung der Datenpakete Signal-Datenpaket Header Schicht 5 Daten Header Schicht 4 Daten Schicht 4 Header Schicht 3 Daten Schicht 3 Header Schicht 2 Schicht 3 Daten Header Schicht6 Daten Schicht 6

12 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 11 Netzwerkdienste Kommunikationsschichten: Unix Stream-System für Protokollschichten Schicht = Treiber, leicht austauschbar 7Anwendungnamedpipes,rlogin, … 6PräsentationXDS 5Sitzung BS-Schnittstelle: sockets 4Transport 3Netzwerk 2Datenverbindung 1Phys. Verbindung Network Access Layer TCP/IP ports, IP Adresse

13 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 12 Netzwerkdienste Kommunikationsschichten: Windows NT Kompatibilität zu bestehenden Protokollen SMB (server message block) NetBIOS (network basic input output system) 7 Anwendung files, named pipes, mail slots 6 Präsentation Subsysteme 5 Sitzung Redirector 4 Transport 3 Netzwerk 2 Datenverbindung NDIS Protokoll 1 Phys. Verbindung Net BEUI NetBIOS TCP/IP Windows- Sockets NDIS-Treiber NBT IPX/ Network Access Layer SPX

14 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 13 Netzwerkdienste Virtual Private Networks VPN Probleme Geheimhaltung von Daten (Sprache, Dokumente, ) Unterschiedl. Grösse der Datenpakete in gekoppelten Netzen Unterschiedl. Art von Transportprotokollen Lösung Verschlüsselung der Kommunikation der Anwenderebene

15 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 14 Netzwerkdienste Virtual Private Networks VPN End-to-End-Protokoll: VPN durch Verschlüsselung

16 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 15 Netzwerkdienste Technik VoIP, Video Anforderung: Viele Sprach/Bildsamples Lösung: Neues Paketmanagement im Schichtenmodell Overhead 40Byte/Paket: Header IPv4:20 Byte, UDP:12 Byte, RTP: 8 Byte  Zusammenfassung mehrerer samples zu einem Paket! 7Anwendung 6Präsentation 5 Sitzung 4 Transport 3Netzwerk 2Datenverbindung 1Phys. Verbindung Network Access Layer TCP IP RTP UDP H.323 Codec,Sicherheit Service: Konferenz, Gebühren,..

17 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 16 Dienste im Netz Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Netzwerke Netzwerkdienste

18 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 17 IP-Adresse Namensgebung im Internet  Eindeutige IP-Adresse: z.B. „ “ IPv4 : 32 Bits, notiert in 4 Dezimalzahlen je (1Byte), IPv6:128Bit  Name: kronos.rbi.uni-frankfurt.de server.LocalNet.domain.country Zuordnung IP-Nummer  Name wird auf speziellen Rechner gehalten (domain name service DNS) Vergabe und Zuordnung der IP-Adresse durch zentrale Instanzen Beispiele CIDR = Classless Inter-Domain Routing /8lokaler Computer loopback /16private Netzwerke Automat. Konfiguration: Dynamic Host Configuration Protocol DHCP /16privates, link-local Netz (APIPA) Netzwerkdienste

19 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 18 Adressierung (Routingentscheidung) der Subnetze durch die Maske: ? (Adresse AND Maske) =? Subnetznummer  JA : Zielrechner ist lokal im Subnetz  NEIN: Routing-Rechner ansprechen Beispiel /24CIDR-Notation Rechner Maske im Subnetz Also: Festlegung des Routing durch Angabe (Subnetznummer,Maske) Netzwerkdienste Internetnamen: Subnetze Problem: hoher zentraler Verwaltungsaufwand bei zu vielen Netzen Lösung:Unterteilung der Rechneradresse in (Subnetz,Rechner), dezentrale Verwaltung dynamische Aufteilung durch Bitmaske (Subnetzmaske) IP-Adresse

20 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 19 Netzwerkdienste Netznamen Namen im regionalen Netzwide area network WAN Probleme Integration von Diensten mehrerer Domänen Konsistente, zeitveränderliche Ressourcentabelle LösungCCITT X.500 (1988) DAP Directory Access Protocol Dateizugriff DSP Directory Service Protocol Server-Server Kommunikation DISP Directory Information Shadowing Protocol LDAP Lightweight DAP vereinf. DAP-Version auf TCP/IP Beispiel Windows NT ADS Active Directory Servicenutzt LDAP Ressourcen sind Blätter im Pfadbaum :// „Aktive Objekte“: Jede Änderung im Verzeichnis wird dem Knoten darüber mitgeteilt (z.B. Druckerstatus) Nur die letzte Änderung an einem Objekt bleibt erhalten

21 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 20 Netzwerkdienste Namen im lokalen Netzlocal area network LAN Zusammenschluß mehrer Rechner gemeinsame Wurzel Netznamen //  Hera  Kronos  Zentrale EDV   Abteilung 7  Einzelverbindung / Zentrale EDV AndereAbteilungen  Abteilung 7 

22 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 21 Netzwerkdienste Dateinamen: Windows NT Namensraum Wiederholung: Symbolic link parsing-Methode \ Device DosDevices Floppy0 HardDisk0 A: B:C: Partition0 Objekt Manager Namensraum Objekt manager: A:\Texte\bs_files.doc  \Device\Floppy0\Texte\bs_files.doc Datei manager: Lese Texte\bs_files.doc Beispiel Lese Datei A:\Texte\bs_files.doc DateimanagerNamensraum bs_mem.docbs_files.doc Texte

23 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 22 Netzwerkdienste Netzkommunikation Beispiel Windows NT Namensraum im lokalen Netz Symbolic link parse-Methode der Treiber (MS Redirector, Novell NetWare File System) führt zum Netzverbindungsaufbau. Beispiel: Neuer „Laufwerks“buchstabe V: für Netzverbindung + Dateiname führt zu Umleitung „V:\public\text.doc“ Universal Naming Convention UNC Beispiel \\ textserv\public\text.doc  UNC: \textserv\public\text.doc  \Device\MUP \textserv\public\text.doc  \Device\NetWareFileSystem \textserv\public\text.doc \ Device DosDevices Floppy0 NetWareFileSystem A:.. V: UNC: Redirector V:\public\text.doc \ MUP Device\NetWareFileSystem\public\text.doc

24 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 23 Netzwerkdienste Netzkommunikation: Ports Konzept Punkt-zu-Punkt Kommunikation („Kommunikationspunkte“) BeispielTCP/IP: well known port numbers DienstPortnummerProtokoll HTTP80TCP FTP21TCP SMTP25TCP rlogin513TCP rsh514TCP portmap111TCP rwhod513UDP portmap111UDP Unix: /etc/services Windows NT: \system32\drivers \etc\services

25 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 24 Netzwerkdienste Netzkommunikation: Ports Nachrichtenbasierte Punkt-zu-Punkt Kommunikation ( Protokoll, RechnerAdresse von A, ProzeßId von A, RechnerAdresse von B, ProzeßId von B ) Beispiel UNIX Transport Layer Interface TLI X/Open: Extended Transport Interface XTI Transportendpunkte (Synchron/Asynchron) Prozeß AProzeß B Transportendpunkt Transportschicht Problem: Zwischenschicht transparent, ohne Beeinflussung

26 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 25 Netzwerkdienste Netzkommunikation: Sockets Verbindungsorientierte Punkt-zu-Punkt Kommunikation socket() bind ( „Kunde“ ) bind ( „ServerDienst“ ) connect()listen() accept() send()recv() send() close() Kunde ServerDienst ClientServer Kommunikation

27 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 26 Netzwerkdienste Netzkommunikation : Named Pipes Globales Konzept: Named pipe („Netzwerk/Pfadname“) => LAN-Interprozeß-Kommunikation Unix Named pipe = special device  nur IPC auf selbem Rechner, nicht NFS Named pipe = SystemV: STREAM socket pair() / bind() Windows NT CreateNamedPipe() : Objekt im globalen Namensraum, auch NetzPfad IPC = ReadFile() / WriteFile() UNC-Name =„\\ComputerName\PIPE\PipeName“ Lokale pipe: „\\. \PIPE\PipeName“ Kommunikation zu Unix möglich, wenn LAN-Manager für Unix LM/U installiert.

28 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 27 Netzwerkdienste Netzkommunikation: Mailbox Konzept:Briefkasten ex. für Sender und Empfänger Multicast & Broadcast möglich Probleme: keine garantierte Reihenfolge, kein garantierter Empfang

29 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 28 Netzwerkdienste Netzkommunikation: Mailbox Beispiel Windows NTmail slots Briefkasten = mail slot, erzeugt mit Creat slot( MailBoxName ) Senden: CreateFile( MailSlotName )-WriteFile()-CloseFile() mit MailSlotName = „ \\ ComputerName \mailslot\ MailBoxName“ (UNC) bei ComputerName= „. “  lokale IPC bei ComputerName= „ * “  Broadcast an alle angeschlossenen Rechner bei ComputerName= „DomainName“  Broadcast an alle Rechner der Domäne Empfänger sind jeweils alle Briefkästen mit dem angegebenen Namen, falls ex. Einschränkungen: Nachrichtenlänge bei NetBEUI: 64kB bei Punkt-zu-Punkt, 400Byte bei broadcast Höheres Protokoll erforderlich für Reihenfolge&Empfang etc., da UDP. Netzwerkdienste

30 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 29 Netzwerkdienste Netzkommunikation: RPC Konzept:Prozedur-Fernaufruf Remote Procedure Calls RPC Remote Method Invocation RMIJava! Remote Function Call RFC Form : wie normaler Prozedur/Methodenaufruf, Ausführung durch Netzwerk- dienst & Transport bleiben verborgen (Client-Server Standardmechanismus!) Client Server Anwender- RPC- Prozeß prozeß RPC-Prozeduren RPC-Prozeduren Prozeduraufruf Transport Original- Prozeduren SyntaxformenWetter=7 Stub-Procedure: ComputeWetter(heute)  RPC(7, „heute“) StdProc+ Arg. RPC(7,“heute“)

31 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 30 Netzwerkdienste Netzkommunikation: RPCRPC-Ablauf Client Stub Netzwerk Stub Server wartet.. warten … Prozeduraufruf Original- Rückkehr ablauf Prozeduraufruf Argumente packen RPC Argumente entpacken Ergebnisse packen RPCreturn Ergebnisse auspacken RETURN

32 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 31 Netzwerkdienste Netzkommunikation: RPC Transport der Daten Problem:Hardwareformat von Zahlen RPC-Argumente sollten maschinenunabhängig sein! Big endian Motorola 680X0, IBM 370 höherwertigniederwertig Byte0Byte1Byte2Byte3 höherwertigniederwertig Byte3Byte2Byte1Byte0 Little endian Intel 80X86, VAX, NS32000 Lösung: data marshaling, z.B. mit XML, Java Serialisierung,... auch für compiler data alignment (Adreßgrenzen bei records, Wortadressierung,...) Transport: Umkehrung der Byte-Reihenfolge

33 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 32 Netzwerkdienste Netzkommunikation: RPC Beispiel Unix Spezielle C-Bibliotheken /lib/libc.a; SystemV: /usr/lib/librpc.a RPC über NFS Schichtenmodell RPC/XDR external data representation Client: anmelden mit registerrpc() Client: callrpc() Server: svr _ run() clnt _.../ svc _... Parameter des Transportprotokoll TCP/IP setzen/lesen Berechtigungen setzen/lesen Pmap _.., ath _.., xdr _.. Details des Protokolls: Vorsicht! RPC bei DCE: Compiler für spezielle Interface Definition Languge IDL. RPC durch stub-Aufrufe und Laufzeitbibliothek für Transport RPC- library

34 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 33 Netzwerkdienste Netzkommunikation: RPC Beispiel Windows NT Verbindungslose RPC: anonymer Service (asynchron) Verbindungsorientierte RPC: bestimmte Prozeduren vom Server (synchr.) Network Data Representation (NDR)-Format Programmierung durch Microsoft IDL-Compiler MIDL Protokoll-Wahl durch Namensnotation: z.B. „ncacn_ip_tcp: MyServer[2004]“ = TCP/IP-Protokoll zu MyServer,port 2004

35 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 34 Dienste im Netz Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Netzwerke Netzwerkdienste

36 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 35 Netzwerkdienste Dateisysteme im NetzSynchronisationsprobleme Netz z.B. inkrement. Backup Datei, Ordner  neu  gelöscht  überschrieben  umbenannt gegenüber früherem Synchronisationspunkt ?

37 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 36 Synchronisationsstrategien  Weil …. existiert in A, aber nicht in B neuer umbenannt B  A umbenennen älter umbenannt A  B umbenennen neu erstellt A  B kopieren später gelöscht auch in A löschen Konfliktfall: Nach letztem Sync Datei in A geändert und in B  ist neuer in A  A  B kopieren  ist älter in A  B  A kopieren Netzwerkdienste existiert in B, aber nicht in A A  B umbenennen B  A umbenennen B  A kopieren auch in B löschen Situation: Datei in A gegenüber Datei in B

38 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 37 Synchronisationsstrategien Situation: Ordner in A gegenüber Ordner in B  existiert in beiden  Dateien darin synchronisieren  existiert in A, aber nicht in B  neuer umbenannt: B  A umbenennen  älter umbenannt: A  B umbenennen  neu erstellt: A  B kopieren mit Inhalt  in B neu gelöscht: auch in A löschen mit Inhalt  existiert nicht in A, aber in B  analog behandeln, s.o. Problem: Versionsgeschichte (z.B. Löschinformation) ist nicht vorhanden  Journaling Filesystem ist nötig! Netzwerkdienste

39 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 38 Netzwerkdienste Dateisysteme im NetzZugriffssemantiken Netz Wer darf wann schreiben ?

40 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 39 Netzwerkdienste Dateisysteme im NetzZugriffssemantiken Read Only File Problemlos, da alle Kopien aktuell sind, unabhängig von der Pufferung Operationssemantik race conditions Alle Änderungen werden sofort umgesetzt; die zeitlich nächste Operation bemerkt die Folgen der vorigen Sitzungssemantik race conditions Alle Änderungen werden nur auf einer Kopie ausgeführt. Am Ende der Sitzung wird das Original überschrieben. Transaktionssemantik Atomare Transaktion: Während der Sitzung ist die Datei gesperrt. Problem: Zugriffssemantik hängt von der Implementierung ab (Hardware, Existenz von Puffern, Netzprotokollen,...) Beispiel Operationssemantik: Reihenfolge der Operationen = Inhalt hängt von der Kommunikationsgeschwindigkeit (Leitungsgeschwindigkeit, Netzstruktur, CPU- Takt, BS-Version, Lastverteilung,...) ab.

41 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 40 Netzwerkdienste Dateisysteme im Netz Zustandsbehaftete vs. zustandslose Datei-Server = verbindungsorientierte Kommunikation vs. verbindungslose Kommunikation Server-Dienst/Verbindung eröffnen Datenstrukturen für Zugriff aufsetzen (Kennungen etc.) Zugriffsrechte prüfen Puffer einrichten Server-Dienst/Verbindung nutzen Mit Dateikennung lesen/schreiben Auftragskopien werden über gleiche Sequenznummern erkannt Server-Dienst/Verbindung schließen Puffer leeren + deallozieren Datenstrukturen abbauen

42 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 41 Netzwerkdienste Dateisysteme im Netz Zustandsbehaftete vs. zustandslose Server Vorteile Schneller Zugriff: keine Adreßinfo, keine Berechtigungsprüfung Effizienter Cache: Strategien möglich (read ahead etc.) Vermeiden von Auftragskopien Nummerierung der Aufträge Dateisperrung möglich (Exklusiver, atomarer Zugriff) Datenbanken! Nachteile Client crash: kein Löschen der Strukturen+Puffer Server crash: kein Löschen der Strukturen+Puffer, Dateizustand ungewiß Begrenzte, gleichzeitig benutzte Dateienzahl: begrenzte Speicherbelegung Server(Verbindung) mit Zustand kann Dateien reservieren, Auftragskopien vermeiden. Server(Verbindung) ohne Zustand ist fehlertoleranter, kann mehr Benutzer gleichzeitig verwalten. Fazit :

43 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 42 Netzwerkdienste Server statd lockd NFS-Server File locking 6) 7) /etc/sm Client Benutzer prozeß NFS-Client statd lockd Dateisysteme im Netz Beispiel Unix NFS-Server Auftrag: file locking Network Lock Manager  Zustandslose Client & Server  Zugriffsinfo auf Client +Server gespeichert  File lock durch RPC 1) 2) 3) 4)Status OK 5) Auftrag 7) Datei Frage: Sind Verklemmungen möglich ?

44 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 43 Netzwerkdienste Dateisysteme im Netz: Cache Cache und Puffer Vorteil: Puffer auf Client beschleunigt Lesen/Schreiben Nachteil: lokaler Puffer führt zu Inkonsistenz bei Zugriffen anderer Rechner Mögliche Pufferorte: BenutzerprozeßNetzdateisystem Transport lokaler Treiber LeiterPlatte ClientServer  BenutzerprozeßHeap/Stack  Transport ClientAusgangspuffer  Leiter 1GHz auf 3 km=10kBit  Transport ServerEingangspuffer  NetzdateisystemDateipuffer  Lokaler TreiberBlockpuffer  PlattencontrollerSchreib-/Lesepuffer

45 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 44 Netzwerkdienste A, B lesen B schreibt Puffer B A schreibt Puffer A Objektpuffer Dateisysteme im Netz: Cache Problem: Konsistenz der lokalen Cache Inkonsistenz ! A B Datenobjekt ?

46 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 45 Netzwerkdienste Dateisysteme im Netz: Cache Cache und Puffer: Konsistenzstrategien für lokalen Cache Zentrale Kontrolle Vor dem Lesen Vergleich der Änderungsinfos (VersionsNr, Quersummen) zwischen Client und Server aber: aufwändig! Delayed Write Sammeln der Änderungen, dann erst schicken aber: Zugriffssemantik verändert Write On Close Sitzungssemantik: lokale Kopie geht an Server bei close() aber: Inkonsistenzen durch Sitzungssemantik Write Through Änderungen gehen am Puffer vorbei sofort zum Original aber: langsam Fazit:Puffern auf Serverseite ist einfacher - auf Clientseite effizienter, aber komplexer (semant.Protokolle!)

47 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 46 Netzwerkdienste Dateisysteme im Netz: Cache Beispiel UNIX NFS-Cachestrategien Asynchrone RPC durch basic input output biod – Dämonen Read ahead Vorauseilende Anforderung von Benutzerblöcken Delayed write Pufferung aller Schreibdaten, flush() alle 3 s (Daten), 30 s (Verzeichnisse), bei sync(), Puffer belegt Write through bei exklusiv gesperrten Dateien Code aus Effizienzgründen im Kernel

48 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 47 Netzwerkdienste Dateisysteme im Netz: Dateiserver Prozesse Implementierung eines Dateiserver durch Prozesse Vorteil symmetrisches System, jeder kann beides sein Nachteil Kopieren der Systempuffer kernel space/user space

49 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 48 Netzwerkdienste Dateisysteme im Netz: Dateiserver Treiber Implementierung eines Dateiserver durch Treiber Vorteil schnelles System Nachteil asymmetrische Kerne

50 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 49 Netzwerkdienste Dateisysteme im Netz Beispiel UnixDas NFS-System Mount() zum Einhängen eines Server-Dateisystems Prozesskommunikation zum mount-demon Nfs _ svc() im kernel mode auf dem Server Virtual i-nodes für virtuelles Dateisystem Client Server System call NFS Server Anwenderprozeß Netz MS-DOS file system UNIX file system NFS Client Gerätetreiber Virtual File System MS-DOS file s ystem Virtual File System UDP/IPGerätetreiberUDP/IP UNIX file system Systemaufruf-Verteiler

51 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 50 Netzwerkdienste Dateisysteme im Netz Beispiel Windows NTNetzdateisystem Verbindungsorientierter Netzaufbau durch Redirector mit Transport Driver Interface TDI über virtual circuits (Kanäle) Kernel Thread pool im Server Client Server System call Systemaufruf-Verteiler I/O-Manager MS-DOS file system NT-file system Redirec- tor Gerätetreiber Netz- transport I/O-Manager OS/2-file system NT-file system Server Treiber Gerätetreiber Netz- transport Anwenderprozeß Netz

52 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 51 Netzwerkdienste Dateisysteme: Sicherheitsaspekte Problem Inkonsistente Netz-Kopplung von Systemen bei unterschiedlichen Sicherheitsmechanismen ! z.B. Authentifizierung bei unterschiedlich langen Namen und Groß/Kleinschreibung Unix/WinNT vs MS-DOS, fehlende ACLs,... Beispiel Windows NT NT 4.0: ACL, Netzbenutzer müssen beim SAM registriert sein mit gleichem Paßwort, sonst Nachfrage bzw. Ablehnung NT 5.0: Kerberos-System bei netzweiter Zugangskontrolle Beispiel UnixNFS-Sicherheitssystem NIS Benutzerliste (yellow pages) verwaltet von NIS RPC hat Zugriffsrechte user/group/other SuperUserID=0 auf Client  UserId=-2 auf Server („external Super User“) konsist. Behandlung von gleichen NutzerIds unterschiedl. Systeme

53 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 52 Netzwerkdienste Dateisysteme: Virtueller Massenspeicher Storage Area Network SAN asym. Pooling LAN NAS Network Attached Storage file server metadata server Block I/O Ortsinfo S A N Lun 2

54 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 53 Netzwerkdienste Dateisysteme: Speichernetze Speicherkonfigurationen des Storage Area Network SAN

55 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 54 Netzwerkdienste Dateisysteme: Speichernetze Info SNIA-Schichtenkonzept


Herunterladen ppt "Modul: B-BS Betriebssysteme SS 2014 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik."

Ähnliche Präsentationen


Google-Anzeigen