Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz 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 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 Netzwerkdienste

MACH- Betriebssystemkern Mach-Kern Benutzer- File Speicher Terminal programm Manager Manager I/O user mode kernel mode Scheduler, Nachrichtenübermittlung, Basic I/O, Speicherobjekte Hardware Mikrokern Vorteile: minimaler Kern, alle Funktionen modularisiert austauschbar Nachteile: Kommunikationsdauer zwischen Managern 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 Netzwerkdienste

Netzwerke- Grundbegriffe Subnetz mit zum Internet Stern - Netzarchitektur Router Router Hub Backbone Switch Router Router Repeater Das Ziel, alle Rechner eines Netzes miteinander zu verbinden, kann man sowohl durch einen Kabelstrang erreichen, der an den Enden miteinander verbunden sein kann (Ringarchitektur), als auch dadurch, dass jeder Rechner mit einem Kabel zu einem zentralen Punkt verbunden ist (Sternarchitektur). In der Abb. ist ein solche Architektur gezeigt, in der die Rechner als Kreise und die Vermittlungseinheiten als Vierecke gezeichnet sind. Werden die Kabelstücke durch den Apparat des zentralen Punkts zu einem einzigen, elektrisch zusammenhängenden Netzwerk geschaltet, so wird dieser als Hub bezeichnet. Ein solches Netz hat zwar physisch eine Sternstruktur, logisch entspricht dies aber einer einzigen, langen Leitung. Solch eine Struktur wird gern verwendet, da sie die zentrale Kontrolle jeden Anschlusses erlaubt: fehlerhaften Rechnern im Netz kann jederzeit „der Stecker gezogen“ werden, ohne die anderen Rechner im Netz zu blockieren.. Der Übergang der Signalinhalte von einem Netz in ein angeschlossenes anderes wird durch ein spezielles Gerät, eine Brücke (Bridge) oder ein Gateway, ermöglicht. Grundsätzlich betrachtet eine solche Bridge alle Signale und leitet diejenigen ins Nachbarnetz um, die als solche kenntlich gemacht wurden. Schnelle Brücken, die auch noch weitere Funktionen zur Vermittlung beherrschen, werden als Switch bezeichnet. Wird die Brücke gezielt angesprochen und beauftragt, die Signale aus dem lokalen Netz, wo sie erzeugt wurden, zum Zielrechner in ein anderes Netz geeignet weiterzuleiten, so spricht man von einem Router. Sowohl ein Hub als auch ein Switch kann zu einem Router ausgebaut werden. Man kann mehrere Netze über Router oder Gateways zusammenkoppeln. In Firmennetzen („Intranet“) bildet die Kopplung über ein spezielles Netz, das keine Drucker oder andere gemeinsam genutzte Geräte (Ressourcen) enthält und nur zur zuverlässigen Verbindung der Subnetze zuständig ist, eine wichtige Geschäftsgrundlage. Es wird deshalb als Backbone-Netz bezeichnet im Unterschied zu Netzen, die nichts weiterleiten können, den Stub-Netzen. Router, die zu diesem zentralen Daten-Umschlagplatz vermitteln, sind die Backbone-Router. “Backbone- Router” Subnetz Netzwerkdienste

Netzwerkschichten OSI-ISO Schichten virtueller Maschinen End-to-End Verbindung: portable Software Rechner B Rechner A virtuelle P2P - Verbindungen B 7 Anwendung 7 Anwendung 6 Präsentation 6 Präsentation 5 Sitzung 5 Sitzung Transport 4 Transport 4 Transport 3 Netzwerk 3 Netzwerk 2 Datenverbindung 2 Datenverbindung 1 Phys. Verbi n dung 1 Phys. Verbi n dung Netzkabel Vorteil Systematische, portable Einteilung Nachteil zu starr und damit zu langsam Lösung Zusammenfassung von Schichten Netzwerkdienste

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

Netzwerkschichten Kapselung der Datenpakete Daten Schicht 6 Daten Header Schicht6 Daten Schicht 6 Header Schicht 5 Daten Header Schicht 4 Daten Header Schicht 3 Daten ACHTUNG: das gleiche gilt auf für das Ende (Tail)! Header Schicht 2 Schicht 3 Daten Signal - Datenpaket Netzwerkdienste

Kommunikationsschichten: Unix Stream-System für Protokollschichten Schicht = Treiber, leicht austauschbar 7 Anwendung named pipes, rlogin, … 6 Präsentation XDS BS-Schnittstelle: so c kets 5 Sitzung ports , IP Adresse 4 Transport TCP/IP 3 Netzwerk 2 Datenverbindung Network Access Layer 1 Phys. Verbi n dung 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 NetBIOS NBT Windows - Sockets Net IPX/ TCP/IP 3 Netzwerk BEUI SPX 2 Datenverbindung NDIS Protokoll NDIS - Treiber Network Access Layer 1 Phys. Verbi n dung Netzwerkdienste

Virtual Private Networks VPN Probleme Geheimhaltung von Daten (Sprache, Dokumente, email) Unterschiedl. Grösse der Datenpakete in gekoppelten Netzen Unterschiedl. Art von Transportprotokollen Lösung Verschlüsselung der Kommunikation der Anwenderebene Netzwerkdienste

Virtual Private Networks VPN End-to-End-Protokoll: VPN durch Verschlüsselung Netzwerkdienste

Technik VoIP, Video IP Anforderung: Viele Sprach/Bildsamples Lösung: Neues Paketmanagement im Schichtenmodell 7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbi n dung Network Access Layer TCP IP RTP UDP H.323 Codec , Sicherheit Service: Konferenz, Gebühren,.. For example, if the voice samples in one packet represent a duration of 20 milliseconds, then 50 (1000ms/20ms) of these samples would be required each second (the selection of this payload duration is a compromise between bandwidth requirements and quality). Each sample carries an IP/UDP/RTP header overhead of 320 bits, meaning that 16,000 (50 X 320) header bits are sent each second. It can therefore generally be assumed that header information will add 16kbps to the bandwidth requirement for voiceover IP. For example, if an 8kbps algorithm such as G.729 is used, the total bandwidth required to transmit each voice channel will be 24kbps (8+16). Overhead 40Byte/Paket: Header IPv4:20 Byte, UDP:12 Byte, RTP: 8 Byte Zusammenfassung mehrerer samples zu einem Paket! Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

IP-Adresse Namensgebung im Internet Eindeutige IP-Adresse: z.B. „141.2.15.25“ IPv4: 32 Bits, notiert in 4 Dezimalzahlen je 0..254 (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 127.0.0.0/8 lokaler Computer loopback 192.168.0.0/16 private Netzwerke Automat. Konfiguration: Dynamic Host Configuration Protocol DHCP 169.254.0.0/16 privates, link-local Netz (APIPA) 32 Bit sind nur wenige Adressen. Um jeden Mobilrechner (Handy!) oder Haushaltsgerät einheitlich eindeutig adressieren zu können, sind mehr Bits nötig. Dazu wurde mit 128 Bit die Version 6 geschaffen. Das Internet wurde mit dem TCP/IP Protokoll von der Defense Advanced Research Projects Agency (DARPA) geschaffen. Die Verwaltung der IP-Nummern und Namen wurde zuerst von der Defense Communication Agency (DCA) (jetzt Defense Information Systems Agency (DISA)) ausgeübt, die ein Network Information Center (NIC) betrieb. Die Registrierungsrechte wurden 1998 der internationalen, non-profit Organisation ICANN (Internet Corporation for Assigned Names and Numbers) übergeben. Für Deutschland ist das DENIC zuständig. Netzwerkdienste 17

IP-Adresse 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) Adressierung (Routingentscheidung) der Subnetze durch die Maske: (Adresse AND Maske) =? Subnetznummer JA : Zielrechner ist lokal im Subnetz NEIN : Routing-Rechner ansprechen Beispiel 129.206.218.160 /24 CIDR-Notation Rechner 160 129.206.218.160 1000.0001.1100.1110.1101.1010.1010.0000 Maske 255.255.255.0 1111.1111.1111.1111.1111.1111.0000.0000 im Subnetz 129.206.218.0 1000.0001.1100.1110.1101.1010.0000.0000 Also: Festlegung des Routing durch Angabe (Subnetznummer,Maske) Frage: Ist die RechnerId immer größer als die Id des Subnetzes, in der er ist? CIDR = Classless Inter-Domain Routing : /x Anzahl x der obersten Bits für das Netzwerk, Rest für das Interface Netzwerkdienste

Netznamen Namen im regionalen Netz wide area network WAN Probleme Integration von Diensten mehrerer Domänen Konsistente, zeitveränderliche Ressourcentabelle Lösung CCITT 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 Service nutzt LDAP Ressourcen sind Blätter im Pfadbaum <DomänenId>://<Pfad> „Aktive Objekte“: Jede Änderung im Verzeichnis wird dem Knoten darüber mitgeteilt (z.B. Druckerstatus) Nur die letzte Änderung an einem Objekt bleibt erhalten Netzwerkdienste

Netznamen Namen im lokalen Netz local area network LAN Zusammenschluß mehrer Rechner gemeinsame Wurzel // ¼ Hera Kronos Zentrale EDV Abteilung 7 Einzelverbindung / Zentrale EDV AndereAbteilungen ¼ Abteilung 7 Homogene Sicht: Beispiel Andrew File System mit DFS Inhomogene Sicht: Beispiel NFS-System unter Unix Netzwerkdienste

Dateinamen: Windows NT Namensraum Wiederholung: Symbolic link parsing-Methode Beispiel Lese Datei A:\Texte\bs_files.doc \ Device DosDevices Floppy0 HardDisk0 A: B: C: Email Partition0 Objekt Manager Namensraum Dateimanager Namensraum bs_mem.doc bs_files.doc Texte Datei Löschen: 2 Zähler, einen für user (->Löschen im Namensraum) und einen für kernel (Speicher erst freigeben, wenn alle SysCalls beendet) Symbolic link parsing-Methode: Angenommen, das Verzeichnis von Floppy A: soll gelesen werden. „A:“ wird ersetzt durch den symbolic link „\Device\Floppy0“ und dem Objektmanager übergeben. Dann wird stattdessen der Pfad „\Device\Floppy0“ abgearbeitet, bis wieder auf einen symbolic link gestoßen wird. In unserem Fall wird die „Durchsuchen“-Methode von Floppy0 ausgeführt, die im Floppy-Treiber enthalten ist und das FAT Dateisystem auslesen kann. Dies ermöglicht, auch sehr unterschiedliche Dateisysteme homogen einzubinden wie MS-FAT, HPFS von OS/2 oder CD-ROM Dateisysteme. Objekt manager: A:\Texte\bs_files.doc  \Device\Floppy0\Texte\bs_files.doc Datei manager: Lese Texte\bs_files.doc 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“ \ Device\NetWareFileSystem\public\text .doc \ Device DosDevices Floppy0 NetWareFileSystem A: .. V: UNC : MUP Beide Mechanismen garantieren nur eine lokale Sicht des Systems durch spezielle Punkt-zu-Punkt-Verbindungen. V:\public\text.doc Redirector 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 Netzwerkdienste

Netzkommunikation: Ports Konzept Punkt-zu-Punkt Kommunikation („Kommunikationspunkte“) Beispiel TCP/IP: well known port numbers Dienst Portnummer Protokoll HTTP 80 TCP FTP 21 SMTP 25 rlogin 513 rsh 514 portmap 111 rwhod UDP Unix: /etc/services Windows NT: \system32\drivers \etc\services 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ß A Prozeß B Transportendpunkt Transportschicht Problem: Zwischenschicht transparent, ohne Beeinflussung Netzwerkdienste

Netzkommunikation: Sockets Verbindungsorientierte Punkt-zu-Punkt Kommunikation Client Server Kommunikation socket() socket() bind ( „Kunde“ ) Kunde ServerDienst bind ( „ ServerDienst“ ) connect() listen() accept() 1. Verbindung deklarieren und einrichten 2. Name des aufrufenden Prozesses registrieren lassen send() recv() recv() send() close() close() 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. Netzwerkdienste

Netzkommunikation: Mailbox Konzept: Briefkasten ex. für Sender und Empfänger Multicast & Broadcast möglich Probleme: keine garantierte Reihenfolge, kein garantierter Empfang Netzwerkdienste

Netzkommunikation: Mailbox Beispiel Windows NT mail slots Briefkasten = mail slot, erzeugt mit CreateMailslot(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 Netzwerkdienste

Netzkommunikation: RPC Konzept: Prozedur-Fernaufruf Remote Procedure Calls RPC Remote Method Invocation RMI Java! Remote Function Call RFC Form: wie normaler Prozedur/Methodenaufruf, Ausführung durch Netzwerk-dienst & Transport bleiben verborgen (Client-Server Standardmechanismus!) Client Server Anwender- RPC - Pr o zeß prozeß RPC -Prozeduren RPC-Prozeduren Prozeduraufruf Transport Transport Original- Prozeduren Syntaxformen Wetter=7 Stub-Procedure: ComputeWetter(heute)  RPC(7, „heute“) StdProc+Arg. RPC(7,“heute“) Netzwerkdienste

Netzkommunikation: RPC RPC-Ablauf Client Stub Netzwerk Stub Server Prozeduraufruf Argumente packen wartet .. RPC Argumente entpa c ken warten … Prozeduraufruf Original- Rückkehr ablauf Ergebnisse packen RPC return Ergebnisse auspacken RETURN Netzwerkdienste

Netzkommunikation: RPC Transport der Daten Problem: Hardwareformat von Zahlen RPC-Argumente sollten maschinenunabhängig sein! Big endian Motorola 680X0, IBM 370 höherwertig niederwertig Byte0 Byte1 Byte2 Byte3 Little endian Intel 80X86, VAX, NS32000 höherwertig niederwertig Byte3 Byte2 Byte1 Byte0 Transport: Umkehrung der Byte-Reihenfolge Lösung: data marshaling, z.B. mit XML, Java Serialisierung, ... auch für compiler data alignment (Adreßgrenzen bei records, Wortadressierung,...) 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 RPC-library 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 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 MIDL= Microsoft IDL-Compiler Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

? Dateisysteme im Netz Synchronisationsprobleme z.B. inkrement. Backup Datei, Ordner neu gelöscht überschrieben umbenannt gegenüber früherem Synchronisationspunkt Angenommen, die Ordner-Baumstruktur hat sich geändert. Woher wissen wir, was der Grund dafür ist? Ist eine Datei neu oder nur umbenannt? Wie kann ein „intelligentes Backup“ gestaltet werden? ? Netzwerkdienste

Synchronisationsstrategien Situation: Datei in A gegenüber Datei in B 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 existiert in B, aber nicht in A A  B umbenennen B  A umbenennen B  A kopieren auch in B löschen Es ex. Verschiedene Möglichkeiten, die Änderungen zu interpretieren und entsprechend das Backup zu gestalten. Netzwerkdienste

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

Wer darf wann schreiben ? Dateisysteme im Netz Zugriffssemantiken Nutzer A Dateisystem Nutzer B Netz Wer darf wann schreiben ? Netzwerkdienste

Dateisysteme im Netz Zugriffssemantiken 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. 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 Netzwerkdienste

Dateisysteme im Netz Zustandsbehaftete vs. zustandslose Server Fazit: 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 Fazit: Server(Verbindung) mit Zustand kann Dateien reservieren, Auftragskopien vermeiden. Server(Verbindung) ohne Zustand ist fehlertoleranter, kann mehr Benutzer gleichzeitig verwalten. Netzwerkdienste

Dateisysteme im Netz Beispiel Unix NFS-Server Auftrag: file locking Network Lock Manager Client Benutzer prozeß NFS-Client statd lockd Server statd lockd NFS-Server File locking Zustandslose Client & Server Zugriffsinfo auf Client +Server gespeichert File lock durch RPC 4) Status /etc/sm 3) 6) 1) 5) Auftrag OK 7) 2) Datei Vorteile einer 2-Stellvertreterprozeß-Architektur: a) Bei client/server crash werden die Tabellen unabhängig von Benutzerprozessen wieder aufgebaut b) Bei weiteren Sperranfragen an die gleiche Datei prüft der lokale Monitorprozeß, ob der frühere Benutzerprozeß, der sperren ließ, noch am Leben ist. Wenn nein, wird die Datei entsperrt und steht allen anderen Interessenten wieder zur Verfügung. ABER: Dies ist kein Schutz vor Verklemmungen ! 7) Frage: Sind Verklemmungen möglich ? 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 Leiter Platte Client Server Benutzerprozeß Heap/Stack Transport Client Ausgangspuffer Leiter 1GHz auf 3 km=10kBit Transport Server Eingangspuffer Netzdateisystem Dateipuffer Lokaler Treiber Blockpuffer Plattencontroller Schreib-/Lesepuffer Die Informationsmenge im Leiter zwischen zwei Rechnern errechnet sich zu 1GHz=109 Bits/sec, c=3x108 m/sec also 10x108/3x108 = 3,3 Bits/m. Bei 3 000 m Rechnerabstand über Lichtleiter sind dies 10.000 Bits =10kB Probleme gibt es immer dann, wenn ein paralleler Zugriff bestimmte Puffer NICHT benutzt, sondern seine eigenen hat. Netzwerkdienste

Dateisysteme im Netz : Cache Problem: Konsistenz der lokalen Cache A B Datenobjekt A, B lesen A schreibt B schreibt Puffer A Puffer B ? Objektpuffer Inkonsistenz ! 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!) 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 Netzwerkdienste

Dateisysteme im Netz: Dateiserver Implementierung eines Dateiserver durch Prozesse Client Server Anwenderprozeß Netzdateimanager Dateitre i ber Gerätetreiber Netzdatei - treiber Transport Netzanschluß tre Betriebssystemaufruf System call Vorteil symmetrisches System, jeder kann beides sein Nachteil Kopieren der Systempuffer kernel space/user space Netzwerkdienste

Dateisysteme im Netz: Dateiserver Implementierung eines Dateiserver durch Treiber Client Server Anwenderprozeß Dateitre i ber Gerätetreiber Netzdatei - treiber Transport Netzanschluß tre Betriebssystemaufruf System call Vorteil schnelles System Nachteil asymmetrische Kerne Netzwerkdienste

Dateisysteme im Netz Beispiel Unix Das NFS-System Client Server 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 Anwenderprozeß Netz MS-DOS file sy s tem UNIX Cl i ent Gerätetreiber Virtual File System y UDP/IP Systemaufruf-Verteiler Netzwerkdienste

Dateisysteme im Netz Beispiel Windows NT Netzdateisystem Server Client 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 s y stem NT-file system Redirec- tor Gerätetreiber Netz- transport OS/2-file Treiber Anwenderprozeß Netz 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 Unix NFS-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 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 Netzwerkdienste

Dateisysteme: Virtueller Massenspeicher Storage Area Network SAN asym. Pooling LAN Ortsinfo S A N file server metadata server Block I/O Ein virtueller Massenspeicher kann aus einem Netzwerk bestehen, das nicht nur die Speicherfunktionen intern organisiert, sondern auch die Zugriffsrechte, die Datensicherung (backup) und Zugriffsoptimierung (Lastverteilung, Datenmigration) selbst regelt. Konflikte gibt es dabei mit unabhängigen Untereinheiten, die selbst diese Funktionen übernehmen wollen (z.B. NAS oder SAN-in-a-box). Asymmetr. Pool: Ein Server dient als Metadaten-Server (Wo sind welche Daten) und gibt Block-I/O Informationen an die anderen Symm.Pool (3-tiers-Lösung): Die Speichergeräte sind nur mit mehreren Metadaten-Servern über ein extra Netzwerk verbunden; die Metaserver hängen über das SAN an den NAS Network Attached Storage Lun 2 Netzwerkdienste

Dateisysteme: Speichernetze Speicherkonfigurationen des Storage Area Network SAN Netzwerkdienste

Dateisysteme: Speichernetze Info SNIA-Schichtenkonzept Netzwerkdienste