Modul: B-BS, BS2, M-SIW-S1A, M-SIW-S1B, M-SIW-S2, M-SIW-VA, M-SIW-VB, M-SIW-VC Betriebssysteme WS 2015/16 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur

Modul: B-BS, BS2, M-SIW-S1A, M-SIW-S1B, M-SIW-S2, M-SIW-VA, M-SIW-VB, M-SIW-VC

BetriebssystemeWS 2015/16

Prof. Dr. Rüdiger BrauseAdaptive SystemarchitekturInstitut für InformatikFachbereich Informatik und Mathematik (12)

Netzwerk-dienste

Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 2

Dienste im Netz

Kommunikation in NetzenDateisysteme im Netz

Arbeitsmodelle im Netz

Netzwerke

Netzwerkdienste

Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 3Netzwerkdienste

Netzwerk-Nutzen

electronic mailKommunikation: Terminabsprachen, Projektkoordination, Mitteilungen, ...

file sharingkeine multiplen Kopien: Dateikonsistenz, Speichererparnis

device sharingbessere Druckerauslastung, lohnende Anschaffung von Spezialhardware (Farblaserdrucker, high-speed-scanner,...)

processor sharingZeitersparnis durch bessere Prozessorauslastung bei Lastverteilung und /oder Kostenersparnis durch geringere Investitionen


Verteilte BetriebssystemeVerteiltes System: Aufteilung von Funktionen in einem Rechnernetz, wobei BS auf jedem Rechner ex.Verteiltes Betriebssystem: Jede BS-Funktion ex. nur einmal im Netz

client file server print server

Benutzer-prozeß

Mikrokern

Dateisystem-Manager

Mikrokern

Printer-Manager

Mikrokern


MACH- Betriebssystemkern

Mach-Kern

Scheduler, Nachrichtenübermittlung, Basic I/O, Speicherobjekte

SpeicherManager

FileManager

TerminalI/O

Benutzer-programm

user modekernel mode

Hardware

Mikrokern Vorteile: minimaler Kern, alle Funktionen modularisiert austauschbar

Nachteile: Kommunikationsdauer zwischen Managern

Netzwerkdienste


Verteilte BetriebssystemeVorteile

Flexibilität inkrementelle Erweiterbarkeit um neue DiensteTransparenz durch ortsunabhängige DiensteLeistungssteigerung bei LastverteilungFehlertoleranz bei multiplen, gleichen Diensten

NachteileLeistungseinbuße durch Kommunikationsverzögerung Keine Fehlertoleranz wenn Funktion nur einmal vorhandenSynchronisation nötig bei Aktualisierung verteilter Daten

FazitAlle BS sind Mischsysteme aus netzbasierten &lokalen BS-Funktionen; es ex. kein „reines“ System


Netzwerke: Grundbegriffe

Hub Switch

Router

Router

Router

Router

“Backbone- Router”

Subnetz mit Stern-

Netzarchitektur

Backbone

Subnetz

zum Internet

Repeater


Netzwerkschichten OSI-ISOSchichten virtueller MaschinenEnd-to-End Verbindung: portable Software

Vorteil Systematische, portable EinteilungNachteil zu starr und damit zu langsamLösung Zusammenfassung von Schichten

Rechner A virtuelle P2P- Verbindungen Rechner BB

Netzkabel

7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbi ndung

7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbi ndung

Transport


Layer 7 : AnwendungsschichtHigh-level Programme: FTP, Grafik, electronic mail, ...

Layer 6 : PräsentationsebeneDatenformatierung, Kodierung, Gruppierung (Records, Verschlüsselung, )

Layer 5 : Sitzungsebeneopen/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 : NetzwerkschichtFragen der Netztopologie: Übertragungsweg, Umleitung (routing), Netzstatus, Grenzen, Auslastung, usw. Typisch: Internet Protocol IPLayer 2 : DatenverbindungDatenpakete Unterteilung in log. Signalframes, Wiederholung bei NO-ACK. Aber: Frame-Reihenfolge ist unkontrolliert. Z.B.: EthernetLayer 1 : physikalische Signale BitsImpulse, Freq. z.B.10BaseT

Netzwerkdienste

Netzwerkschichten: OSI-ISO


Netzwerkschichten: DatenpaketeKapselung eines Datenpakets

Signal-Datenpaket

Header Schicht 5

Schicht 5 Daten

Header Schicht 4

DatenSchicht 4

Header Schicht 3 DatenSchicht 3

Header Schicht 2 Schicht 3 Daten

Header Schicht6

Daten Schicht 6


Kommunikationsschichten: UnixStream-System für ProtokollschichtenSchicht = Treiber, leicht austauschbar

7 Anwendung named pipes, rlogin, …6 Präsentation XDS

5 SitzungBS-Schnittstelle: sockets

4 Transport3 Netzwerk2 Datenverbindung1 Phys. Verbindung

Network Access Layer

TCP/IP

ports, IP Adresse


Kommunikationsschichten: Windows NTKompatibilität zu bestehenden ProtokollenSMB (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/


SPX


Virtual Private Networks VPN

ProblemeGeheimhaltung von Daten (Sprache, Dokumente, email)Unterschiedl. Grösse der Datenpakete in gekoppelten NetzenUnterschiedl. Art von Transportprotokollen

LösungVerschlüsselung der Kommunikation der Anwenderebene


Virtual Private Networks VPN

End-to-End-Protokoll: VPN durch Verschlüsselung

Internet

Sender

Empfänger VPN

Rechner A virtuelle Verbindungen Rechner B

Netzkabel

7 Anwendung6 Präsentation5 Sitzung4 Transport3 Netzwerk2 Datenverbindung1 Phys. Verbindung

7 Anwendung6 Präsentation5 Sitzung4 Transport3 Netzwerk2 Datenverbindung1 Phys. Verbindung


Technik VoIP, VideoAnforderung: Viele Sprach/BildsamplesLösung: Neues Paketmanagement im Schichtenmodell

Overhead 40Byte/Paket: Header IPv4:20 Byte, UDP:12 Byte, RTP: 8 Byte

Zusammenfassung mehrerer samples zu einem Paket!

7 Anwendung6 Präsentation5 Sitzung

4 Transport

3 Netzwerk2 Datenverbindung1 Phys. Verbindung


TCP

IP

RTPUDP

H.323Codec ,

SicherheitService: Konferenz, Gebühren,..


Dienste im Netz



Netzwerke

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.countryZuordnung IP-NummerName wird auf speziellen Rechner

gehalten (domain name service DNS)

Vergabe und Zuordnung der IP-Adresse durch zentrale InstanzenBeispiele CIDR = Classless Inter-Domain Routing

127.0.0.0/8 lokaler Computer loopback192.168.0.0/16 private Netzwerke

Automat. Konfiguration: Dynamic Host Configuration Protocol DHCP169.254.0.0/16 privates, link-local Netz (APIPA)

Netzwerkdienste


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-NotationRechner 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)

Netzwerkdienste

Internetnamen: SubnetzeProblem: hoher zentraler Verwaltungsaufwand bei zu vielen Netzen

Lösung: Unterteilung der Rechneradresse in (Subnetz,Rechner),dezentrale Verwaltungdynamische Aufteilung durch Bitmaske (Subnetzmaske)

IP-Adresse


NetznamenNamen im regionalen Netz wide area network WANProbleme

Integration von Diensten mehrerer Domänen Konsistente, zeitveränderliche Ressourcentabelle

Lösung CCITT X.500 (1988)DAP Directory Access Protocol DateizugriffDSP Directory Service Protocol Server-Server KommunikationDISP Directory Information Shadowing ProtocolLDAP Lightweight DAP vereinf. DAP-Version auf TCP/IP

Beispiel Windows NTADS 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


Namen im lokalen Netz local area network LANZusammenschluß mehrer Rechner

gemeinsame Wurzel

Netznamen

// ¼ Hera ¼ Kronos ¼ Zentrale EDV ¼ ¼ Abteilung 7 ¼

Einzelverbindung / Zentrale EDV AndereAbteilungen

¼ Abteilung 7 ¼


Dateinamen: Windows NT NamensraumWiederholung: Symbolic link parsing-Methode

\ Device DosDevices

Floppy0 HardDisk0 A: B: C:

Email 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

Dateimanager Namensraum

bs_mem.doc bs_files.doc

Texte


NetzkommunikationBeispiel Windows NT Namensraum im lokalen Netz

Symbolic linkparse-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 UNCBeispiel \\ 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


Netzkommunikation: PortsKonzept Punkt-zu-Punkt Kommunikation

(„Kommunikationspunkte“)

Beispiel TCP/IP: well known port numbers

Dienst Portnummer ProtokollHTTP 80 TCPFTP 21 TCPSMTP 25 TCPrlogin 513 TCPrsh 514 TCPportmap 111 TCPrwhod 513 UDPportmap 111 UDP

Unix: /etc/services

Windows NT:\system32\drivers \etc\services


Netzkommunikation: PortsNachrichtenbasierte 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 Transportendpunkt

Transportschicht

Problem: Zwischenschicht transparent, ohne Beeinflussung


Netzkommunikation: SocketsVerbindungsorientierte Punkt-zu-Punkt Kommunikation

socket() socket()

bind(„Kunde“) bind(„ServerDienst“)

connect() listen()accept()

send() recv()recv() send()

close() close()

Kunde ServerDienst

Client ServerKommunikation


Netzkommunikation : Named Pipes

Globales Konzept: Named pipe („Netzwerk/Pfadname“) => LAN-Interprozeß-Kommunikation

UnixNamed pipe = special device nur IPC auf selbem Rechner, nicht NFSNamed pipe = SystemV: STREAM socket pair() / bind()

Windows NTCreateNamedPipe() : 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.


Netzkommunikation: MailboxKonzept: Briefkasten ex. für Sender und Empfänger

Multicast & Broadcast möglich

Probleme: keine garantierte Reihenfolge, kein garantierter Empfang


Netzkommunikation: Mailbox

Beispiel Windows NT mail slotsBriefkasten = 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

Rechnerbei 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 broadcastHöheres Protokoll erforderlich für Reihenfolge&Empfang etc., da UDP.

Netzwerkdienste


Netzkommunikation: RPCKonzept: Prozedur-FernaufrufRemote Procedure Calls RPCRemote 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 - Prozeß 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“)


Netzkommunikation: RPCRPC-Ablauf

Client Stub Netzwerk Stub Server

wartet ..

warten … Prozeduraufruf Original- Rückkehr ablauf

ProzeduraufrufArgumentepacken RPC

Argumenteentpacken

Ergebnissepacken RPC return

Ergebnisseauspacken

RETURN


Netzkommunikation: RPCTransport der DatenProblem: Hardwareformat von Zahlen

RPC-Argumente sollten maschinenunabhängig sein!

Big endian Motorola 680X0, IBM 370

höherwertig niederwertigByte0 Byte1 Byte2 Byte3

höherwertig niederwertigByte3 Byte2 Byte1 Byte0

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


Netzkommunikation: RPCBeispiel Unix

Spezielle C-Bibliotheken /lib/libc.a; SystemV: /usr/lib/librpc.aRPC über NFSSchichtenmodell RPC/XDR external data representation

Client: anmelden mit registerrpc() Client: callrpc() Server: svr_run()

clnt_. ../ svc_...Parameter des Transportprotokoll TCP/IP setzen/lesenBerechtigungen 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


Netzkommunikation: RPCBeispiel Windows NT

Verbindungslose RPC: anonymer Service (asynchron)Verbindungsorientierte RPC: bestimmte Prozeduren vom Server (synchr.)Network Data Representation (NDR)-Format Programmierung durch Microsoft IDL-Compiler MIDLProtokoll-Wahl durch Namensnotation:

z.B. „ncacn_ip_tcp: MyServer[2004]“ = TCP/IP-Protokoll zu MyServer,port 2004

presentation layer

session layertransport layernetwork layer . . .

RPCnamed files

mailslots

TCP/IP

redirector

WinNetAPI

sockets

IPX/SPX NetBEUI etc.


Dienste im Netz



Netzwerke

Netzwerkdienste


Dateisysteme im NetzSynchronisationsprobleme

Dateisystem A

Dateisystem B

Netz

z.B. inkrement. Backup

Datei, Ordner neu gelöscht überschrieben umbenanntgegenüber früherem Synchronisationspunkt

?


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 AA B umbenennenB A umbenennenB A kopierenauch in B löschen

Situation: Datei in A gegenüber Datei in B


SynchronisationsstrategienSituation: 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


Dateisysteme im NetzZugriffssemantiken

Nutzer A

Dateisystem

Netz

Nutzer B

Wer darf wann schreiben ?


Dateisysteme im NetzZugriffssemantiken

Read Only File Problemlos, da alle Kopien aktuell sind, unabhängig von der Pufferung

Operationssemantik race conditionsAlle Änderungen werden sofort umgesetzt; die zeitlich nächste Operation bemerkt die Folgen der vorigenSitzungssemantik race conditionsAlle Ä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.


Dateisysteme im NetzZustandsbehaftete vs. zustandslose Datei-Server

= verbindungsorientierte Kommunikation vs. verbindungslose Kommunikation

Server-Dienst/Verbindung eröffnenDatenstrukturen für Zugriff aufsetzen (Kennungen etc.)Zugriffsrechte prüfenPuffer einrichten

Server-Dienst/Verbindung nutzenMit Dateikennung lesen/schreibenAuftragskopien werden über gleiche Sequenznummern erkannt

Server-Dienst/Verbindung schließenPuffer leeren + deallozierenDatenstrukturen abbauen


Dateisysteme im NetzZustandsbehaftete vs. zustandslose ServerVorteile

Schneller Zugriff: keine Adreßinfo, keine BerechtigungsprüfungEffizienter Cache: Strategien möglich (read ahead etc.)Vermeiden von Auftragskopien Nummerierung der AufträgeDateisperrung möglich (Exklusiver, atomarer Zugriff) Datenbanken!

NachteileClient crash: kein Löschen der Strukturen+PufferServer 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:


Server

statd

lockd

NFS-ServerFile locking

6)

7)

/etc/sm

Client

Benutzerprozeß

NFS-Client

statd

lockd

Dateisysteme im NetzBeispiel Unix NFS-ServerAuftrag: 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 ?


Dateisysteme im Netz: CacheCache und PufferVorteil: Puffer auf Client beschleunigt Lesen/SchreibenNachteil: lokaler Puffer führt zu Inkonsistenz bei Zugriffen anderer RechnerMögliche Pufferorte:

Benutzerprozeß NetzdateisystemTransport 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


A, B lesen

B schreibtPuffer B

A schreibtPuffer A

Objektpuffer

Dateisysteme im Netz : CacheProblem: Konsistenz der lokalen Cache

Inkonsistenz !

A B

Datenobjekt

?


Dateisysteme im Netz: CacheCache und Puffer: Konsistenzstrategien für lokalen Cache

Zentrale Kontrolle Vor dem Lesen Vergleich der Änderungsinfos (VersionsNr, Quersummen)zwischen Client und Serveraber: aufwändig!Delayed Write Sammeln der Änderungen, dann erst schicken aber: Zugriffssemantik verändertWrite On Close Sitzungssemantik: lokale Kopie geht an Server bei close()aber: Inkonsistenzen durch Sitzungssemantik

Write Through Änderungen gehen am Puffer vorbei sofort zum Originalaber: langsam

Fazit: Puffern auf Serverseite ist einfacher - auf Clientseite effizienter, aber komplexer (semant.Protokolle!)


Dateisysteme im Netz: CacheBeispiel UNIX NFS-Cachestrategien Asynchrone RPC durch basic input output biod – Dämonen

Read ahead Vorauseilende Anforderung von Benutzerblöcken

Delayed writePufferung aller Schreibdaten, flush() alle 3 s (Daten) , 30 s (Verzeichnisse), bei sync(), Puffer belegt

Write throughbei exklusiv gesperrten Dateien

Code aus Effizienzgründen im Kernel


Dateisysteme im Netz: DateiserverImplementierung eines Dateiserver durch Prozesse

Vorteil symmetrisches System, jeder kann beides seinNachteil Kopieren der Systempuffer kernel space/user space

Client Server

Anwenderprozeß Netzdateimanager

Dateitre iberGerätetreiber

Netzdatei-treiber

TransportNetzanschluß-

tre iber

BetriebssystemaufrufDateitre iberGerätetreiber

Netzdatei-treiber


tre iber

Betriebssystemaufruf

System call


Dateisysteme im Netz: DateiserverImplementierung eines Dateiserver durch Treiber

Vorteil schnelles SystemNachteil asymmetrische Kerne

Client Server

Anwenderprozeß

Dateitre iberGerätetreiber

Netzdatei-treiber


tre iber

BetriebssystemaufrufDateitre iberGerätetreiber

Netzdatei-treiber


tre iber

Betriebssystemaufruf

System call


Dateisysteme im NetzBeispiel Unix Das NFS-SystemMount() zum Einhängen eines Server-Dateisystems Prozesskommunikation zum mount-demonNfs_svc() im kernel mode auf dem ServerVirtual i-nodes für virtuelles Dateisystem

Client Server

System call

NFSServer

Anwenderprozeß

Netz

MS-DOSfile

system

UNIXfile

systemNFS

Client

Gerätetreiber

Virtual File SystemMS-DOS

filesystem

Virtual File System

UDP/IP GerätetreiberUDP/IP

UNIXfile

system

Systemaufruf-Verteiler


Dateisysteme im NetzBeispiel Windows NT Netzdateisystem

Verbindungsorientierter Netzaufbau durch Redirector mit Transport Driver Interface TDI über virtual circuits (Kanäle)Kernel Thread pool im Server

Client Server

System call

Systemaufruf-VerteilerI/O-Manager

MS-DOSfile

system

NT-filesystem

Redirec-tor

GerätetreiberNetz-

transport

I/O-ManagerOS/2-file

systemNT-filesystem

ServerTreiber

GerätetreiberNetz-

transport

Anwenderprozeß

Netz


Dateisysteme: SicherheitsaspekteProblem

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 NTNT 4.0: ACL, Netzbenutzer müssen beim SAM registriert sein mit gleichem Paßwort, sonst Nachfrage bzw. AblehnungNT 5.0: Kerberos-System bei netzweiter Zugangskontrolle

Beispiel Unix NFS-Sicherheitssystem NISBenutzerliste (yellow pages) verwaltet von NISRPC hat Zugriffsrechte user/group/otherSuperUserID=0 auf Client UserId=-2 auf Server („external Super User“)konsist. Behandlung von gleichen NutzerIds unterschiedl. Systeme


Dateisysteme: Virtueller MassenspeicherStorage Area Network SAN asym. Pooling

LAN

NASNetwork Attached Storage

file servermetadata server

Block I

/OOrtsinfo

S A N

Lun 2


Dateisysteme: SpeichernetzeSpeicherkonfigurationen des Storage Area Network SAN


Dateisysteme: Speichernetze

Info SNIA-Schichtenkonzept

Documents

Modul: B-BS, BS2, M-SIW-S1A, M-SIW-S1B, M-SIW-S2, M-SIW-VA, M-SIW-VB, M-SIW-VC Betriebssysteme WS 2015/16 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur