Diplomarbeit. Entwurf und Implementierung eines verteilten, fehlertoleranten und ausfallssicheren Dateisystems mit Corso

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. Entwurf und Implementierung eines verteilten, fehlertoleranten und ausfallssicheren Dateisystems mit Corso"

Transkript

1 Diplomarbeit Entwurf und Implementierung eines verteilten, fehlertoleranten und ausfallssicheren Dateisystems mit Corso ausgeführt am Institut für Computersprachen Abteilung für Programmiersprachen und Übersetzerbau der Technischen Universität Wien unter der Anleitung von Ao. Univ.Prof. Dipl.-Ing. Dr. eva Kühn Georg Werthner Stolzenthalergasse 10/ Wien März 2004

2 2

3 Zusammenfassung In dieser Arbeit werden neben den verteilten Datei Systemen, Network File System, Andrew File System und Coda, auch ein neuentwickeltes verteiltes Dateiservice, das mit Java und unter Verwendung von Corso implementiert wurde, vorgestellt. Der implementierte Prototyp erfüllt die Anforderungen der Location, Failure, Replication und Migration Transparencies. Das Dateiservice kann aus beliebig vielen Server Prozessen bestehen. Aufgrund dessen und durch die Verwendung von Corso skaliert das Dateiservice automatisch durch das Starten zusätzlicher Corso Prozesse. Die komplette Kommunikation zwischen Client und Server wird verschlüsselt abgewickelt. Genauso werden die, vom Dateisystem verwalteten Dateien, verschlüsselt gespeichert. Weiters ist das Dateiservice tolerant gegenüber Netzwerkausfällen sowie Partitionierungen und führt bestimmte Operationen auch im Falle solcher Fehler aus.

4 Abstract This work will introduce and describe the distributed filesystems Network File System, Andrew File System and Coda. The analysis of the filesystems is based upon the different types of transparencies. This knowledge was used to design and implement a distributed filesystem using Corso and Java. The implmenented prototype achieves location, failure, replication and migration transparency. The filesystem consists of multiple multithreaded servers. Because of that and because of the usage of Corso, the requirements for scalability are fullfilled too. The files and the communication between the different components of the filesystem are encrypted. Finally the filesystem is tolerant to network errors and partitiong and tries to execute filesystem operations in case of such errors.

5 Inhaltsverzeichnis 1 Einführung Leitfaden Begriffsdefinitionen Dateien, Verzeichnisse und Dateisysteme Verteilte Dateiservices Anforderungen Grundvoraussetzungen Transparencies Zusätzliche Anforderungen Sicherheit Überblick über verteilte Dateisysteme Unix und Virtual Filesystem Network Filesystem Server Client Caching Transparencies und andere Anforderungen Andrew Filesystem Vice und Virtue Caching Transparencies und andere Anforderungen Coda Filesystem Architektur Replikation Caching Disconnected Operation Transparencies und andere Anforderungen Zusammenfassung

6 INHALTSVERZEICHNIS 2 4 Corso Filesystem Motivation und Aufgabenstellung Entwicklungsumgebung Corso System Architektur Authentifizierungskomponente KeyManager Server Komponente Client Komponente Service Information Client Server Kommunikation Zugriffskontrolle Datenstrukturen der Dateien und Verzeichnisse Sicherheit Funktionalität Checkout Checkin Skalierbarkeit Fehlertoleranz Ein Corso Object Space Verteilter Corso Object Space Analyse der Sicherheit Passive Angriffe Aktive Angriffe Vergleich zu NFS, AFS und Coda Ausblick Zusammenfassung Erweiterungen und Verbesserungen A Java Klassen 67 A.1 corsofilesystem.fs.result.* A.2 corsofilesystem.fs.corsofilesystem A.2.1 Felder A.2.2 Methoden A.3 corsofilesystem.client.corsofilesystem A.4 corsofilesystem.fs.inode A.4.1 Methoden A.5 corsofilesystem.fs.abstractinode A.5.1 Felder A.5.2 Methoden

7 INHALTSVERZEICHNIS 3 A.6 corsofilesystem.fs.regularfile A.7 corsofilesystem.fs.directory A.8 corsofilesystem.pc.pcinoderepairthread A.9 corsofilesystem.pc.pcfilerepairthread A.10 corsofilesystem.pc.pcdirectoryrepairthread A.11 corsofilesystem.service.login.loginprocess A.12 corsofilesystem.service.userdb.userdbprocess A.13 corsofilesystem.server.serverprocess A.13.1 Felder A.13.2 Methoden A.14 corsofilesystem.server.clientmanager A.14.1 Felder A.14.2 Konstruktor A.15 corsofilesystem.server.requestprocessor A.15.1 Felder A.15.2 Methoden A.16 corsofilesystem.common.queue.entry.requestqueueentry A.16.1 Felder A.16.2 Konstruktor A.16.3 Methoden B Corso Datenstrukturen 83 B.1 DataObject B.2 Version B.3 Alternative B.4 RegularFile B.5 Directory C Installation und Inbetriebnahme 86 C.1 Vorraussetzungen C.2 Vorarbeiten C.3 Service starten C.4 Client Anwendung starten

8 Abbildungsverzeichnis 3.1 NFS Architektur Corso, ein primitives Dateisystem Systemarchitektur Queue aus Corso Objekten Die Authentifizierungskomponente für Unix Corso Kommunikation Beispiel eines Objekt Baums No Primary Copy Fehler benötigt die Primary Copy 52 4

9 Tabellenverzeichnis 3.1 Vergleich von NFS, AFS und Coda Mögliche Konfliktsituationen bei Operationen auf Inodes Mögliche Konfliktsituationen bei Operation auf Verzeichnissen Mögliche Konfliktsituationen bei Operationen auf regulären Dateien

10 Kapitel 1 Einführung Das Dateisystem ist verantwortlich für die Organisation, die Speicherung, das Auslesen, die Namensgebung, die Verteilung und die Sicherung von Dateien. [5] Mit der Erweiterung von Unix um Netzwerkfähigkeiten wurde es möglich, Hardware, wie zum Beispiel Drucker, anderen Computern im Netz zur gemeinsamen Nutzung zur Verfügung zu stellen. Mit Hilfe eines verteilten Dateisystems können auch Dateien von verschiedenen Benutzern gemeinsam im Netz genutzt werden. Beispiele für solche verteilten Dateisysteme sind das Network File System (NFS), das Andrew File System (AFS) oder das Coda File System. Das Ziel dieser Arbeit war, aufbauend auf einer Analyse der gerade genannte Dateisysteme, ein verteiltes, fehlertolerantes und ausfallsicheres Dateisystem, unter Verwendung von Corso, eine auf dem Virtual Shared Memory Paradigma aufbauende Middleware, zu entwickeln, das sogenannte Corso File System. 1.1 Leitfaden Zunächst werden in Abschnitt 2 die Anforderungen, die an verteilte Dateisysteme gestellt werden, vorgestellt. Im nächsten Abschnitt 3 werden die Dateisysteme NFS, AFS und Coda vorgestellt und analysiert, in wie weit diese, die in Abschnitt 2 angeführten Anforderungen erfüllen. Anschließend wird in Abschnitt 4 das Corso File System vorgestellt. Abgeschlossen wird die Arbeit mit der Zusammenfassung (Abschnitt 5). 6

11 KAPITEL 1. EINFÜHRUNG Begriffsdefinitionen Dateien, Verzeichnisse und Dateisysteme In [19] wird eine Datei als Sammlung mehrerer ähnlicher records, welche wiederum als Sammlung von zusammengehörenden fields definiert werden, definiert. Ein Field ist ein einzelner Daten Wert, zum Beispiel ein Datum oder ein Nachname. Ein Record wäre dann zum Beispiel eine Adresse, die aus den Fields Vor- und Nachname, Straße und Stadt besteht. Eine Datei ist eine Menge von 0 oder mehreren Records. Eine leere Datei enthält keine Records. Dateien bestehen aber nicht nur aus den Records, dem Inhalt (oder den Nutzdaten) der Datei, sondern sie besitzen auch eine Reihe von Attributen, welche wiederum aus Fields und Records bestehen. Beispiele für Attribute wären die Länge der Datei, der Zeitpunkt der Erstellung der Datei oder die Zugriffsrechte, wer die Datei lesen, schreiben oder ausführen darf. Eine andere Definition stammt von Coulouris et al.: The file is an abstraction of permanent storage. [5] Das bedeutet, eine Datei ist die Abstraktion der physikalischen Speicherung der Datei. Also zum Beispiel in welcher Reihenfolge die Fields gespeichert werden, die Kodierung der Datentypen oder die Byte Order. Das Dateisystem stellt eine Schnittstelle für den Zugriff auf die Dateien zur Verfügung [5]. Es ist zuständig für die physikalische Organisation der Dateien auf dem Speichermedium, sowie für die Regelung der Zugriffe auf die Dateien (Autorisation) und stellt unter anderem Funktionen zum Anlegen, Löschen, Öffnen, Lesen und Schreiben von Dateien zur Verfügung. Die Namensgebung wird durch sogenannte Datei Verzeichnisse (oder kurz Verzeichnisse) ermöglicht. Verzeichnisse sind in fast allen Dateisystemen als eine spezielle Form von Dateien realisiert. Um diesem Umstand zu entsprechen, wird in dieser Arbeit für alle jene Dateien, die keine Verzeichnisse sind, die Bezeichnung reguläre Dateien verwendet. Der Unterscheid zu einer regulären Datei besteht darin, daß Verzeichnisse nur einen Typ von Records, nämlich eine Verknüpfung zwischen einem Namen und einer Datei, enthalten. Wie dabei die Datei adressiert wird, hängt vom Dateisystem ab. Besteht das Dateisystem nur aus einem Verzeichnis und beliebig vielen Dateien, ensteht ein flaches Namensschema. Können allerdings Verzeichnisse in Verzeichnissen anlegt werden, entsteht ein hierarchisches Namenschema. Das bedeutet, dass die Wurzel eines Dateisystems, egal ob hierarchisch oder flach, immer ein Verzeichnis sein muß, andernfalls würde das Dateisystem nur aus einer Datei bestehen. Dieses Verzeichnis wird als Wurzelverzeichnis oder Root directory bezeichnet. Dateisysteme strukturieren die Dateien normalerweise in Form von Bäumen.

12 KAPITEL 1. EINFÜHRUNG Verteilte Dateiservices Genaugenommen könnte die Überschrift dieses Abschnitts auch verteilte Dateisysteme heißen, was aber laut [5] nicht ganz zutreffend ist. Denn ein verteiltes Dateisystem wäre zum Beispiel ein auf zwei Computer aufgeteiltes Dateisystem, wobei der eine Rechner nur für die Lese Operationen und der anderen nur für die Schreiboperationen zuständig ist. Ein Service ist ein Dienst, welcher von einem Server angeboten wird und von einem (oder mehreren) Client(s) in Anspruch genommen wird. Ein Server ist ein Verwalter von Ressourcen, die von Clients benötigt werden, um ihre Arbeit erledigen zu können. Ein Server kann aber, um sein Service anbieten zu können, auch selbst die Dienste eines Servers in Anspruch nehmen. In diesem Fall ist er gleichzeitig Client und Server. Im Falle von verteilten Dateiservices sind die verwalteten Ressourcen Dateien, die von einem Dateiserver den Clients angeboten werden. Die Dateiserver sind Clients des lokalen Dateiservice, das vom Betriebssystem angeboten und über das Virtual File System angesprochen wird.

13 Kapitel 2 Anforderungen Damit ein verteiltes Dateiservice praktikabel arbeiten kann, muß es verschiedene Anforderungen, die in [5] angeführt sind, erfüllen. Im folgenden werden diese Anforderungen beschrieben. 2.1 Grundvoraussetzungen Ein verteiltes System - und im speziellen ein verteiltes Dateiservice - muß bestimmte Eigenschaften erfüllen, damit es überhaupt als ein solches gilt. In [5] wurden sechs dieser Eigenschaften identifiziert. Resource Sharing: Diese Eigenschaft ist zwingend erfüllt, da ein Dateiservice Dateien verteilt. Concurrency: Ein Server hat typischerweise mehr als einen Client zu bedienen. Die Anfragen der Clients sollten gleichzeitig abgearbeitet werden können, damit ein Client nicht solange warten muß, bis die Anfragen seines Vorgängers bearbeitet wurden. Die Gleichzeitigkeit wird üblicherweise dadurch erreicht, daß der Server für jeden Client entweder einen eigenen Betriebssystemprozeß oder einen Thread startet, welcher dann parallel zu den bereits laufenden Prozessen abläuft. Diese Parallelität erfordert dann aber die Synchronisation der Zugriffe auf die zu verteilenden Dateien. Parallelität ensteht auch, wenn die Dateien die ein Service anbietet, auf mehrere Server verteilt sind. Dann arbeiten die Server automatisch parallel. Auch in diesem Fall müssen die Zugriffe auf die Ressourcen synchronisiert werden. Scalability bedeutet die Erweiterbarkeit eines verteilten Systems. Kann ein Service erweitert werden, um zum Beispiel auf ein gestiegenes Benutzeraufkommen reagieren zu können? 9

14 KAPITEL 2. ANFORDERUNGEN 10 Fault Tolerance. Als fehlertolerant wird ein System bezeichnet, wenn man damit, obwohl Fehler aufgetreten sind oder gerade auftreten, weiterarbeiten kann. Transparency ist definiert als die Verschleierung der Komplexität eines Systems vor dem Benutzer beziehungsweise Programmierer. In Bezug auf verteilte Systeme bedeutet Transparenz, daß vor dem Benutzer bzw. Programmierer die Tatsache verborgen wird, daß das verteilte System aus verschiedenen verteilten Komponenten besteht. Ein verteiltes System ist transparent, wenn der Benutzer und der Programmierer das verteilte System als ein Ganzes wahrnehmen und nicht als Komposition mehrerer unabhängiger Bestandteile. Die einzelnen Transparencies werden im nächsten Abschnitt behandelt. Openness beschreibt, in wie weit ein verteiltes System erweitert werden kann. Openness wird durch die Veröffentlichung und Beschreibung der wichtigsten Interfaces zwischen den Komponenten eines verteilten Systems, erreicht. Zum Beispiel wurde die Openness des Unix Betriebssystems durch die Integration vom Virtual File System(Siehe Abschnitt 3.1) und dessen Veröffentlichung und Beschreibung erhöht. Durch das Virtual File System kann das Unix Betriebssystem um zusätzliche Dateisysteme erweitert werden. Dateisysteme können zum Beispiel durch Veröffentlichung aller Interfaces um zusätzliche Authentifizierungsmechanismen erweitert werden (wie in NFS Version 4 geschehen. Siehe dazu Abschnitt 3.2). 2.2 Transparencies Wie bereits oben erwähnt, ist Transparency eine sehr wichtige Eigenschaft von verteilten Systemen und Services. In [5] wurden acht Transparencies identifiziert, die ein verteiltes Dateiservice zumindest teilweise unterstützen sollte. Access Transparency ist erfüllt, wenn auf Dateien des verteilten Dateisystems genauso zugegriffen werden kann, wie auf lokale Dateien. Dies wird durch Verwendung eines einheitlichen Interfaces, in Unix mit Virtual File System (siehe Abschnitt 3.1), erreicht. Location Transparency ist dann erfüllt, wenn Benutzer und Programmierer nicht unterscheiden können, ob eine Datei lokal oder verteilt ist.

15 KAPITEL 2. ANFORDERUNGEN 11 Concurrency Transparency: Ein Client soll eine Datei ändern können, ohne daß andere Clients, die zur gleichen Zeit die selbe Datei bearbeiten oder lesen, dadurch gestört werden. Dabei können aber Probleme auftreten, die geregelt werden müssen. Angenommen zwei Clients öffnen dieselbe Datei und ändern diese. Was passiert, wenn zuerst ein Client die Datei mit seinen Änderungen speichert, und danach der andere Client seine Version der Datei speichert? Sollen die Änderungen des ersten Clients verloren gehen, da der zweite Client die Datei mit seinen Änderungen überschreibt? Oder soll der zweite Client darauf hingewiesen werden, daß sich der Inhalt der Datei geändert hat und er entscheidet dann selbst, ob er die Datei überschreibt, oder seine Änderungen in die geänderte Version einarbeitet? Die meisten verteilten Dateiservices versuchen in solchen Fällen das Verhalten von Unix, die sogenannte One-Copy Update Semantik, zu simulieren. Diese Semantik wird üblicherweise unter anderem durch das Sperren von Dateien erreicht. Bei der One Copy Update Semantik werden gleichzeitige, konkurrierende Dateizugriffe folgendermaßen geregelt: Wenn mehrere Clients dieselbe Datei öffnen, wird für jeden Client eine Kopie der Datei geöffnet. Angenommen zwei Clients: A und B. A und B öffnen eine Datei f. Für beide Benutzer öffnet Unix eine Kopie von f. A und B führen nun Änderungen an der Datei durch. Wenn dann zum Beispiel A seine Kopie schließt, wird B vom Betriebssystem benachrichtigt, daß f verändert wurde. B kann nun entweder f neu einlesen, wodurch seine Änderungen verloren wären, oder er kann die Datei trotzdem schließen und damit die Änderungen, die A an f getätigt hat, überschreiben. Obwohl jeder Client seine eigene Kopie der Datei geöffnet hat, sehen sie den Inhalt der Datei, wie wenn es nur ein Original oder eine Kopie (One Copy) geben würde. Failure Transparency verlangt, daß Server und Client bei Netzwerkfehlern und dadurch bedingten temporären Service Ausfällen, unbeeinträchtigt weiterarbeiten können. Performance Transparancy. Solange die Service Last, also die Anzahl der das Service gleichzeitig in Anspruch nehmenden Benutzer, eine bestimmte Grenze nicht übersteigt, sollen Clients zufriedenstellend damit arbeiten können. Scaling Transparency bezeichnet die Eigenschaft, daß das Dateiservice erweitert werden kann, um eine größere Anzahl von Benutzern bedienen zu können und in größeren Netzwerken arbeiten zu können,

16 KAPITEL 2. ANFORDERUNGEN 12 ohne daß der Benutzer etwas davon mitbekommt. Scalability hängt eng mit der Performance und damit mit der Verwendbarkeit des Dateiservice zusammen. Ist zum Beispiel das Dateiservice aufgrund einer zu großen Anzahl von angemeldeten Clients ausgelastet, können die Clients nicht mehr zufriedenstellend arbeiten, da sie lange auf Antworten auf ihre Request warten müssen. Dieses Problem kann durch Hinzufügen zusätzlicher Server gelöst werden. Replication Transparency. Diese Eigenschaft hängt eng mit der Scaling Transparency zusammen. Bei der Replikation werden von einer Datei Kopien, Replikate, erstellt, die auf mehrere Server verteilt werden. Damit kann auch die Last der Zugriffe auf mehrere Server verteilt werden. Das heißt, durch Replizierung wird die Erweiterbarkeit, die Performance und auch die Fehlertoleranz, da bei Ausfall eines Servers, die Datei von einem anderen angefordert werden kann, verbessert. Replizierung verursacht jedoch wiederum neue Probleme, wie zum Beispiel die Synchronisation der Änderungen am Original mit denen der Replikate. Replication Transparency ist dann erfüllt, wenn ein Client nicht zwischen dem Original und der Kopie unterscheiden kann. Migration Transparency ist dann erfüllt, wenn eine Datei von einem Server auf einen anderen Server umgesiedelt werden kann, ohne daß der Benutzer etwas davon mitbekommt. 2.3 Zusätzliche Anforderungen Neben den Transparencies gibt es noch zusätzliche Anforderungen, die ein verteiltes Dateiservice erfüllen sollte. Hardware and operating system heterogeneity wird heutzutage oft auch als Plattformunabhängigkeit bezeichnet. Es bedeutet, daß obwohl die einzelnen Komponenten einer verteilten Anwendung auf verschiedenen Hardware Plattformen und Betriebssystemen in unterschiedlichen Programmiersprachen implementiert wurden, miteinander zusammenarbeiten können. Support for fine-grained distribution of data: Das bedeutet die Verteilung der Inhalte von Dateien. Die meisten der heute erhältlichen Dateisysteme verteilen nur ganze Dateibäume (siehe dazu die Abschnitte 3.2, 3.3 und 3.4).

17 KAPITEL 2. ANFORDERUNGEN 13 Tolerance to network partitioning and detached operation: Detached Operation wird heutzutage oft auch als Disconnected Operation bezeichnet. Dies tritt vor allem bei mobilen Devices, wie zum Beispiel Handys, auf, wenn für kurze Zeit die Verbindung zum Netz und damit zum Service ausfällt. Network Partitioning ist die Aufteilung eines Netzes aufgrund von Fehlern in mehrere disjunkte Teilnetze. Dies kann in der Nichterreichbarkeit des Service für eine bestimmte Gruppen von Clients resultieren. Insofern macht es aus Sicht des Clients keinen Unterschied, ob das Service aufgrund von Detached Operation oder durch Network Partitioning, nicht erreichbar ist. Deshalb ist diese Anforderung nicht nur für mobilen Devices von Bedeutung. 2.4 Sicherheit Ein verteiltes Dateiservice sollte die Sicherheit der darin gespeicherten Daten garantieren. Daraus folgt einerseits eine sichere Authentifizierungsmethode, die sicherstellt, daß sich erstens nur berechtigte Benutzer anmelden können, und daß zweitens die Daten für die Authentifizierung sicher zwischen Authentifizierungsstelle und dem noch unbekannten Benutzer übermittelt werden. Konnte ein Benutzer identifiziert werden, muß der Zugriff auf die Dateien geregelt werden. Das erfordert eine sichere Autorisation der Dateizugriffe. Und natürlich müssen die Daten, die beim Zugriff eines Benutzers auf das Dateiservice zwischen Server und Client übertragen werden, damit sie nicht abgehört werden können, verschlüsselt werden. Genauso sollten die Dateien, die vom Dateisystem verwaltet werden, verschlüsselt gespeichert werden.

18 Kapitel 3 Überblick über verteilte Dateisysteme Da die Dateisysteme, die in diesem Kapitel vorgestellt werden, alle das Vnode Layer/Virtual File System (VFS) 1 verwenden, wird zunächst das VFS besprochen, bevor die Dateisysteme NFS, AFS und Coda vorgestellt werden. 3.1 Unix und Virtual Filesystem In Unix Dateisystemen werden zur internen Repräsentation von Dateien sogenannte Inodes (Index Nodes) verwendet. Beim Anlegen des Dateisystems wird eine bestimmte Anzahl von Inodes, welche von der Größe des Speichermediums abhängig ist, sowie ein Super Block erstellt. Der Super Block enthält die Konfiguration des Dateisystems, wieviele Inodes vorhanden sind, wieviele davon frei sind, sowie die Inodenummer des Wurzelverzeichnisses. Jede Inode ist für einen bestimmten Teil des Speichmediums zuständig. Eine Datei kann aus beliebig vielen Inodes bestehen. Eine Inode kann aber immer nur für eine Datei zuständig sein, solange sie nicht durch das Löschen der Datei explizit freigegeben werden. In den Inodes werden allerdings nicht die Dateien, sondern die Adressen auf dem physikalischen Speichermedium, gespeichert. Verzeichnisse enhtalten einer Menge von Verknüpfungen zwischen den Namen, der in diesem Verzeichnis enthaltenen Dateien, und den entsprechenden Inodes. Viele Firmen haben ihre eigenen Unix Versionen herausgebracht. Dementsprechend gibt es auch ziemlich viele unterschiedliche Dateisysteme, die aber alle anders angesprochen werden müssen - sie bieten eine ähnliche Funk- 1 Sun hat diesem Konzept den Namen Vnode Layer gegeben. Die Linux Implementierung hingegen trägt den Namen Virtual Filesystem. 14

19 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 15 tionalität, nur die Interfaces für den Zugriff sind unterschiedlich. Um dem Benutzer den Zugriff auf die verschiedenen Dateisysteme zu erleichtern, wurde daher eine zusätzliche Abstraktionsschicht in das Unix Betriebssystem integriert (Ein Beispiel für das Virtual Filesystem zeigt Abbildung 3.1 auf Seite 16), das als Vnode Layer[10] oder VFS 2 bezeichnet wird. Das VFS stellt dem Benutzer einen einheitlichen Zugang zu den Dateien der verschiedenen unterschiedlichen Dateisysteme zur Verfügung. Das VFS ist so etwas wie ein Übersetzer: Der Client stellt seine Anfrage in der VFS Sprache, leitet dann die Anfrage in der Sprache des entsprechenden Dateisystems an jenes weiter, und liefert dann die in die VFS Sprache übersetzte Antwort an den Client zurück. Dies wird als Access Transparency bezeichnet. Wie bereits weiter oben erwähnt, können die Dateien eines Dateisystems als Baum visualisiert werden. Da ein Baum immer nur eine Wurzel haben kann, kann auch das VFS nur ein Wurzelverzeichnis haben. Da aber die vielen verschiedenen Dateisysteme, die vom VFS vereint werden, alle ein eigenes Wurzelverzeichnis besitzen, gibt es im VFS sogenannte Mount Points. Das sind Verzeichnisse, in die jeweils ein Dateisystem eingehängt werden kann. Für den Benutzer sieht dieser Mount Point aus wie ein normales Verzeichnis. Er kann ohne Informationen über die Mount Points nicht entscheiden, aus welchem Dateisystem die Datei stammt. Dies wird als Location Transparency bezeichnet. [10, 15] 3.2 Network Filesystem Das Sun Network File System ist, nachdem bereits mehrere verteilte Dateisysteme auf Universitätsebene entwickelt worden waren, das erste Dateisystem, das als kommerzielles Produkt entwickelt wurde. NFS wurde 1985 vorgestellt. Die Referenzimplementierung wurde an andere Firmen lizenziert und die Interfaces wurden veröffentlicht, sodaß heutzutage Implementierungen (Client und Server) für fast alle Betriebssysteme zur Verfügung stehen. Noch heute (17 Jahre nach der Vorstellung) erfreut sich NFS, mittlerweile bei der Version 4 [16] angekommen, noch immer großer Beliebtheit. NFS besteht aus zwei Komponenten: Client und Server (Siehe Abbildung 3.1). Jeder Client kann gleichzeitig auch Server sein und umgekehrt Server Der Server ist, zumindest bei der Unix Implementierung (im Gegensatz zu Windows), teil des Betriebssystemkerns. Client und Server kommmunizieren 2 Es gibt Diskussionen darüber ob VFS die Abkürzung von Virtual File System oder von Virtual Filesystem Switch ist.[15]

20 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 16 Client Computer Server Computer Unix Kernel Virtual File System Unix Kernel Virtual File System Local FS NFS Client NFS Server Local FS NFS Client Abbildung 3.1: NFS Architektur mit dem Remote Procedure Call (RPC) Mechanismus von Sun miteinander. Der Server stellt eine Menge von Operationen zum Öffnen, Lesen, Schreiben, usw. zur Verfügung. Die wichtigste Funktion ist lookup. Sie liefert für einen Dateinamen in einem bestimmten Verzeichnis den sogenannten File Handle zurück. Der File Handle in der Unix Implementierung besteht aus drei Feldern: Filesystem identifier: Das ist eine eindeutige Nummer, die jedem Dateisystem bei der Erstellung zugeordnet wird. Inode number: Unter Unix werden Dateien durch Inodes identifiziert. Bei der Erstellung eines Dateisystems werden entsprechend der Größe des Dateisystems eine Menge von Inodes erstellt. Wenn nun ein Programm eine Datei öffnen will, liefert der Betriebssystemkern für den Dateinnamen die Inode Nummer, mit der dann die Datei im Dateisystem gefunden werden kann. Wenn keine Inodes mehr verhanden sind, ist das Dateisystem voll. In NFS sind diese Inodes Teil des file handle. Inode generation number: Diese Nummer wird benötigt, um den File Handle eindeutig zu machen. In Unix werden Inodenummern wiederverwendet, nachdem eine Datei gelöscht. Mit diesem File Handle können dann die anderen Funktionen wie Lesen, Schreiben, Datei-Attribute verändern, usw. aufgerufen werden. Die Dateien, die ein Server zur Verfügung stellt, werden unter Unix in einer Datei festgelegt, die meistens /etc/exports heißt. Dort werden die Verzeichnisse angegeben, die der Server exportiert und die von den Clients gemountet werden können. Wenn ein Client ein exportiertes Verzeichnis mountet, bekommt er als ersten File Handle den File Handle für das Wurzelverzeichnis.

21 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME Client Das NFS Client Modul ist zuständig für die Kommunikation mit dem Server. Um lokale und verteilte Dateien zu untestützen, wurde dem Unix Kernel das Vnode Layer hinzugefügt. Es ermöglicht den User Level Prozessen einen einheitlichen Zugriff auf verschiedene Dateisysteme (Siehe Abschnitt 3.1). Mit Hilfe des Vnode Layer kann der Betriebssystemkern zwischen lokalen und verteilten Dateien unterscheiden. Zugriffe auf lokale Dateien werden vom Betriebssystemkern behandelt und ausgeführt. Zugriffe auf verteilte Dateien werden vom Vnode Layer an das NFS Client Modul übergeben, welches die Zugriffe in die entsprechenden NFS Operationen übersetzt und auf dem entsprechenden NFS Server auführt. Das Client Modul arbeitet also in gewisser Weise wie ein Dateisystem Treiber für lokale Dateisysteme. Es liefert auch genauso wie herkömmliche Dateisysteme nicht ganze Dateien auf einmal aus, sondern in einzelnen Blöcken Caching NFS verwendet Caching auf Client und Server Seite, um die Performance zu steigern. Server Auf der Server Seite werden mit einer Ausnahme (siehe weiter unten) die selben Caching Methoden verwendet, wie von Unix Betriebssystemen. NFS liefert, genauso wie Unix, Dateien nicht als ganzes aus, sondern in Blöcken oder sogenannten File Pages. Diese Blöcke werden wie die Verzeichnisse und die Dateiattribute in einem sogenannten Buffer Cache zwischengespeichert. Um die Performance bei Lesezugriffen zu steigern, verwendet Unix die sogenannte Read Ahead Methode. Dabei werden, wenn ein Block einer bestimmten Datei angefordert wird, auch gleich die darauffolgenden Blöcke gelesen und in den Buffer Cache geschrieben. Wenn nun der nächste Block angefordert wird, kann dieser direkt aus dem Cache geliefert werden. Die Read Ahead Methode wird auch von NFS auf der Server Seite verwendet. Der Unterschied zu Unix besteht in der Behandlung von Schreibzugriffen. Unix verwendet die sogenannte Delayed Write Methode, um Schreibzugriffe zu beschleunigen. Wenn ein Block im Buffer Cache verändert wird, wird der veränderte Block nicht sofort ins Dateisystem geschrieben. Dies erledigt die Unix Funktion sync. sync schreibt die veränderten Blöcke periodisch, normalerweise alle 30 Sekunden, ins Dateisystem. Dies beruht auf der Annahme,

22 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 18 daß es schneller ist, mehrere Blöcke auf einmal, anstatt jeden Block sofort zu schreiben. Darin unterscheidet sich NFS von Unix. Da es bei einem Fehler des Servers zu Datenverlusten kommen kann, weil veränderte Blöcke noch nicht ins Dateisystem geschrieben wurden, werden veränderte Blöcke vom Server sofort geschrieben. Dies wird als Write-Through Methode bezeichnet. Client Auf der Client Seite werden die Blöcke von gelesenen und geschriebenen Dateien, die Dateiattribute, die Verzeichnisse und die NFS File Handles zwischengespeichert. Für jeden Block im Cache wird eine sogenannte Timestamp mitgespeichert. Der Cache wird periodisch nach einem bestimmten Zeitintervall, das beim Einhängen des Dateisystems festgelegt wird, oder wenn vom Benutzer eine Datei geöffnet wird oder wenn neue Blöcke vom Server angefordert werden, auf Gültigkeit überprüft. Dazu wird zu jedem Element im Cache vom Server die Modification Time angefordert. Ist die Modification Time jünger als die Timestamp, werden die entsprechenden Elemente neu vom Server geholt. Wenn ein Block im Cache verändert wurde, wird der Block im Cache als dirty gekennzeichnet. Bei einem sync oder wenn der Benutzer eine veränderte Datei schließt, werden die dirty Elemente an den Server geschickt. Nachdem die Konsistenz des Cache überprüft wurde, werden Dateien und Verzeichnisse für eine bestimmte Zeitdauer als valid angesehen. Da während dieser Zeitdauer der Cache nicht überprüft wird und der NFS Client nicht unterscheiden kann, ob eine Datei auch von anderen NFS Clients geöffnet ist, können sogenannte Time Lags und dadurch Inkonsistenzen des Clientcache entstehen. Allerdings stellen laut [5] die meisten Unix Anwendung keine besonders strengen Anforderungen an den Cache Transparencies und andere Anforderungen In diesem Abschnitt wird untersucht, welche der in Abschnitt 2.2 auf Seite 10 angeführten Anforderungen von NFS erfüllt werden und welche nicht: Access transparency wird erfüllt, da der Client dasselbe Interface zur Verfügung stellt, wie eine lokales Dateisystem. Daher können unter Unix Datei Zugriffe wie bei lokalen Dateien durch Unix System Calls durchgeführt werden. Location transparency: Auf Client Seite werden die verteilten Dateisysteme in das lokale Dateisystem eingehängt. Der Benutzer sieht einen auf diesen einen Rechner bezogenen, einheitlichen File Namespace und kann nicht unterscheiden, ob eine Datei lokal oder remote gespeichert

23 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 19 wird. Wenn die Clients entsprechend konfiguriert werden, kann auch ein auf das gesamte Netzwerk bezogener, einheitlichen File Namespace erzeugt werden. Damit ist auch die Anforderung Location transparency erfüllt. Failure transparency: Das NFS Dateisystem Service ist stateless. Weiters sind die meisten NFS Funktionen idempotent 3 implementiert. Wenn ein Server ausfällt, stehen die Dateien, die er verwaltet, für die Zeit des Ausfalls nicht zur Verfügung. Danach können die Clients, da der Server stateless ist, sofort an der Stelle, an der das Service ausgefallen ist, weiterarbeiten. Fehler auf Client Seite haben auf das NFS Dateisystem keine Auswirkungen, da der Server keine Informationen über die Clients besitzt/benötigt. Performance transparency: Auf beiden Seiten, Client und Server, wird Caching verwendet, um die Performance zu steigern. Da Client und Server als Teil des Betriebssystemkerns implementiert worden sind, sind Zugriffe auf verteilte Dateien (auf leicht belasteten Servern) um maximal 20 Prozent langsamer als auf lokale Dateien. Migration transparency: Wird von älteren NFS Versionen nur teilweise erfüllt, da beim Verschieben von Dateien auf andere Server die Remote Mount Tables geändert werden müssen. In der aktuellen Version 4 wird die Migration von Server Dateisystemen durch die Verwendung des sogenannten Filesystem Location Dateiattributs unterstützt. Mit diesem Attribut kann die Client Anwendung, falls ein Server Dateisystem umgezogen ist, den neuen Speicherort des Dateisystems erfahren [16]. Replication transparency: Das ursprüngliche NFS Dateisystem verwendet keine Replikationsmechanismen. Die neueste Version 4 unterstützt aber durch die Verwendung des Filesystem Location Dateiattributs die Replikation von read-only Server Dateisystemen. Dieses Attribut ermöglicht es der Client Anwendung, den Server über die Speicherorte eines Server Dateisystems zu befragen.[16]. Dasselbe Attribut wird auch verwendet, wenn ein Dateisystem umgezogen ist und vom Client nicht gefunden werden kann. Concurrency transparency: Die Concurrency Transparency wird mittlerweile von NFS Version 4 besser unterstützt, als von älteren 3 Idempotente Funktionen können beliebig oft ausgeführt werden. Dabei haben sie den gleichen Effekt als ob sie nur einmal ausgeführt worden sind. [5]

24 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 20 Versionen. In den vorherigen Versionen wurden nur sehr rudimentäre Sperrmöglichkeiten für Dateien angeboten. In Version 4 können jetzt Dateien auf Blockebene gesperrt werden und erlaubt damit eine bessere Simulierung der Unix One Copy Update Semantik. Scalability: Im Gegensatz zu den ersten NFS Versionen erfüllt NFS Version 4 Migration und Replication Transparency und erlaubt damit eine viel besser Skalierbarkeit. Security: Der im RFC 2203 [11] beschriebene RPCSEC GSS Mechanismus erweitert RPC (und damit auch NFS, da NFS auf RPC aufbaut) um sichere Authentifikation und private Kommunikation [16]. 3.3 Andrew Filesystem Das Andrew File System (AFS) ist Teil einer verteilten Datenverarbeitungsumgebung mit dem Namen Andrew. Andrew wurde an der Carnegie-Mellon University (CMU) geplant und entwickelt und wurde 1985 ebendort in Betrieb genommen [7] wurde, um AFS kommerziell vermarkten zu können, die Firma TransarcCorporation gegründet. Diese Firma wurde 1998 von IBM übernommen. Das AFS Projekt wurde von IBM im Jahr 2000 eingestellt und an die Open Source Initiative OpenAFS übergeben Vice und Virtue In AFS wird der Server als Vice und der Client als Virtue bezeichnet. Vice war in AFS-1 so implementiert, daß für jeden Client ein eigener Vice Prozess gestartet wurde. In AFS-2 wurde Vice hingegen als multi-threaded Server implementiert. Virtue besteht einerseits aus einer Änderung am Betriebssystemkern, um zwischen lokalen und verteilten Dateien unterscheiden zu können, und einem User-Level Prozess, der als Venus bezeichnet wird. In AFS-3 implementiert Virtue das Virtual File System. Venus ist zuständig für die Kommunikation mit Vice und das Cache Management. Vice und Virtue kommunizieren über RPC miteinander. Mehrere Vice Server spannen einen gemeinsamen verteilten Namespace, das Andrew File System, auf. Jeder Vice Server ist als Custodian für ein Volume zuständig. Ein Volume ist eine Menge von Dateien, die einen bestimmten Teilbaum (Verzeichnis) des verteilten Namespaces bilden. Vice und Virtue verwenden sogenannte FIDs (File Identifiers) für die Identifikation von Dateien. Ein FID besteht aus folgenden Elementen:

25 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 21 Volume number: Das Volume, in dem die Datei gespeichert ist. NFS file handle: Damit wird die Datei innerhalb des Volumes identifiziert. Siehe auf Seite 16. Uniquifier: Eine 32 Bit lange Zahl, die den File Identifier eindeutig macht und die Wiederverwendung von FIDs verhindert. Für die Übersetzung von Dateinamen in FIDs ist Venus zuständig. Ein Dateizugriff Ein großer Unterschied zu NFS besteht darin, daß in AFS Dateien als ganzes von Vice an Venus ausgeliefert und von Venus zwischengespeichert werden, und nicht in einzelnen Blöcken wie bei NFS. Wenn ein Prozeß eine verteilte Datei öffnet, überprüft Venus zuerst ob die gewünschte Datei im Cache ist und ob der Cache Eintrag gültig ist. Wenn dies der Fall ist, wird der Request direkt aus dem Cache beantwortet und es findet kein Netzwerkverkehr mit Vice statt. Wenn die Datei nicht im Cache vorhanden oder ungültig ist, wird der Request an den nächsten Vice Server geschickt. Ist der kontaktierte Vice Server der Custodian für die gewünschte Datei, wird die Datei ausgeliefert, ansonsten antwortet der Server mit der Adresse des Custodians. Gegebenenfalls muß nun der Request an den Custodian geschickt Caching Die Dateien werden in einem Verzeichnis auf dem Client Rechner zwischengespeichert. Vice liefert Dateien zusammen mit einer sogenannten Callback promise aus. Das bedeutet, daß Vice, oder besser gesagt der Custodian dieser Datei, dem Client verspricht, daß er benachrichtigt wird, wenn jemand diese Datei verändert. Dies geschieht, indem der Custodian einen Callback an den Client schickt. Der Custodian muß demnach auch Informationen über Clients speichern. Er muß für jede Datei für die er zuständig ist, die Clients speichern, an die er Callback Promises geschickt hat. Eine Callback Promise kann entweder valid oder cancelled sein. Wenn ein Client einen Callback erhält, setzt er die entsprechende Callback Promise in seinem Cache auf cancelled. Wenn ein Client eine verteilte Datei öffnen will, wird zuerst überprüft, ob die Datei überhaupt im Cache vorhanden ist. Wenn die Datei im Cache vorhanden ist und die entsprechende Callback Promise gültig ist, wird der Request direkt aus dem Cache beantwortet, ansonsten muß eine neue Kopie von Vice geholt werden. Wenn ein Client (nach einem Fehler) neu gestartet wird, werden alle Dateien im Cache, deren Callback Promise ungültig ist,

26 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 22 neu vom Server geholt. Für Dateien deren Callback Promise ungültig ist, wird die Änderungszeit jeder Datei an den jeweiligen Custodian geschickt. Wenn sich die Änderungszeit nicht geändert hat, antwortet der Server mit valid und die Callback Promise wird wieder auf gültig gesetzt. Die Callback Promises werden nicht nur beim Öffnen einer Datei überprüft, sondern auch periodisch nach einer bestimmten Zeit T (wird in Sekunden angegeben), da zum Beispiel durch Netzwerkfehler Callbacks verloren gegangen sein könnten. AFS garantiert nach der erfolgreichen Öffnung einer Datei, daß entweder die neueste Datei geöffnet wurde oder daß ein Callback verloren gegangen ist und die Datei aus dem Cache geöffnet wurde. Falls die Datei aus dem Cache geöffnet wird zusätzlich garantiert, daß die Datei seit maximal T Sekunden nicht upgedated wurde Transparencies und andere Anforderungen Access transparency: In AFS erfolgt der Zugriff auf verteilte Dateien genau wie auf lokale Dateien über System Calls. Damit unterstützt AFS genauso wie NFS Access Transparency. Location transparency: Ein Benutzer kann anhand des Namens einer Datei nicht entscheiden, ob sie lokal oder verteilt ist. Concurrency transparency: AFS versucht so weit wie möglich die Unix File Update Semantik zu emulieren. AFS verwendet dazu die Callback Promises, um eine möglichst gute Annäherung an die One Copy Update Semantik zu erreichen [5, 17]. Failure transparency: Bei Auftreten von Netzausfällen bleibt der Client solange unbeeinträchtigt, solange die vom Client angeforderten Daten im Cache enthalten sind. Migration transparency: Werden Dateien oder ganze Verzeichnisse auf andere AFS Server verschoben, muß nur auf Server Seite die Location Database, wo die Adressen der einzelnen Vice Server eingetragen sind, geändert werden. Auf Client Seite müssen keine Änderungen vorgenommen werden. Die Migration passiert also transparent für den Benutzer. Replication transparency: In AFS gibt es nur die Möglichkeit, sogenannte Read Volumes (Verzeichnisse auf die nur lesend zugegriffen werden kann) auf mehrere Servern zu replizieren [12].

27 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 23 Scalability: Scalability war ein Design Ziel von AFS. Wie man gesehen hat, ist in AFS für ein Volume oder Verzeichnis und den darin liegenden Dateien, ein Custodian zuständig, d.h. ein Volume wird auf einem Server gespeichert. Falls ein Custodian sehr oft überlastet ist, kann man das Volume auf mehrere Server/Custodians aufteilen. Das erfordert nur Änderungen an der Location Database. Weiters gibt es die Möglichkeit, Volumes, deren Dateien sich nur sehr selten ändern, als Read Volumes zu definieren, und auf mehrere Servern zu replizieren. [18] Security: AFS verwendete ursprünglich eine Variante des Needham- Schröder Private Key Algorithm [5], um eine sichere Kommunikation zwischen Client und Server zu ermöglichen. Mittlerweile wird für die Authentifizierung Kerberos verwendet. Die Dateizugriffe werden über eine Kombination von Access Control Lists und den Unix File Protection Semantics geregelt. [12, 18] 3.4 Coda Filesystem Das Coda Dateisystem [17] wurde, wie das Andrew File System, an der Carnegie Mellon University entwickelt und ist die Weiterentwicklung von AFS. Coda wurde entwickelt, da neue Anforderungen an verteilte Dateisysteme aufgetaucht sind. Der Grund dafür war, die zur damaligen Zeit zunehmende Verbreitung und Verwendung von mobilen Computern. Da diese mobilen Computer nicht immer einen Zugang zum Internet oder zum Campusnetzwerk haben, d.h. ihre Verbindung zu den Dateiservern unterbrochen ist, sollte es möglich sein, auch ohne Verbindung zum Dateisystem, weiterarbeiten zu können. Dies wird als Disconnected Operation [9] bezeichnet. Eine weitere Anforderung an Coda war, die Availability des Services zu erhöhen Architektur Wie in AFS besteht der Coda Client aus Änderungen am Betriebssystemkern und einem User Level Prozess Venus. Coda implementiert das Virtual Filesystem. User Programme können transparent über System Calls auf die Dateien zugreifen. Laut [9] ist die Verwendung des VFS mit einem Overhead verbunden. Um diesen zu vermindern, wurde der sogenannte MiniCache in den Kernel integriert. Der MiniCache speichert die Ergebnisse der Requests an den User Level Prozess Venus. Der MiniCache ist allerdings nicht für die Kommunikation mit Coda Dateiserver, Replikation oder Disconnected Operation zuständig. Ein Datei Request wird durch das VFS an den MiniCache

28 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 24 weitergeleitet. Wenn möglich, beantwortet der MiniCache die Anfrage aus seinem Cache. Ist das nicht möglich, wird der Request an Venus weitergeleitet, der dann den Request entweder aus seinem Cache beantwortet oder einen Coda Server kontaktiert. Die Kommunikation zwischen Venus und MiniCache wurde bidirektional ausgelegt, damit Venus, zum Beispiel aufgrund eines Updates einer Datei, dem MiniCache mitteilen kann, daß bestimmte Elemente im Zwischenspeicher des MiniCache nicht mehr gültig sind. Auf diese Weise bleiben die Einträge im MiniCache konsistent [2] Replikation Coda verwendet Replikation einerseits, um die Performance zu steigern, und andererseits, um die Availability und die Fault Tolerance zu verbessern. Coda repliziert nur Volumes, keine Dateien. Die Menge von Coda Datei Servern, die ein Replikat eines Volumes speichern, wird als Volume Storage Group (VSG) bezeichnet. Venus speichert für jedes Volume, von dem es Dateien im Cache besitzt, die gerade erreichbaren Server aus der entsprechenden VSG ab. Diese Menge von Servern wird als Accessible Volume Storage Group (AVSG) bezeichnet. Die AVSG eines Volumes ist eine Teilmenge der entsprechenden VSG dieses Volumes. Die verwendete Replikationsstrategie ist optimistisch. Sie läßt Änderungen an einer Datei auch bei einer leeren AVSG zu. Um semantische Konflikte zu vermeiden, besitzt jede Datei einen sogenannten Coda Version Vector. In diesem Vector wird für jedes Mitglied der VSG die Anzahl der Änderungen gespeichert. Dadurch werden semantische Konflikte entdeckt und soweit möglich auch gelöst. Bei Konflikten, die nicht gelöst werden können, wird die Datei als inoperable gekennzeichnet und der Besitzer der Datei benachrichtigt. Dieser muß dann den Konflikt händisch auflösen Caching In Coda werden, genau wie bei AFS, Dateien auf Client und Server Seite zwischengespeichert. Der Unterschied zu AFS besteht aufgrund der verwendeten Replikation in der erweiterten Überprüfung der Kohärenz des Zwischenspeichers Disconnected Operation Als Disconnected Operation wird der Zustand bezeichnet, der auftritt, wenn der Client aufgrund von Netzausfällen keine Verbindung zu einem Coda Dateiserver hat, oder anders ausgedrückt wenn die AVSGs für die vom Client benötigten Dateien leer sind. Während kurzer Ausfälle wird in vielen

29 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 25 Fällen der Cache ausreichen, damit der Benutzer für die Dauer des Ausfalls weiterarbeiten kann. Wenn die Dauer der Disconnected Operation zu lang wird, wird der Cache nicht mehr ausreichen und die Funktionalität des Clients wird gestört. Gerade im Zeitalter von mobilen Devices sind längere Netzausfälle keine Seltenheit. Daher können Coda Benutzer eine Liste von wichtigen Dateien anlegen. Die Einträge dieser Liste werden dann, genügend Platz im Zwischenspeicher/Festplatte vorausgesetzt, immer im Cache gehalten. Nach dem Ende der Disconnected Operation startet der Client einen sogenannten Reintegration Process, in dem versucht wird, die Replikate für jede im Zwischenspeicher enthaltene Datei auf den aktuellen Stand zu bringen. Ist dies aufgrund von semantischen Konflikten nicht möglich, wird der verantwortliche Benutzer verständigt Transparencies und andere Anforderungen Access Transparency: Ist erfüllt, da der Zugriff, genau wie bei lokalen Dateisystemen, erfolgt. Location Transparency: Ist erfüllt, da Coda eine Weiterentwicklung von AFS ist (siehe Abschnitt 3.3.3). Concurrency Transparency: Ist erfüllt. Die Update Semantik ist im Gegensatz zu AFS, aufgrund der optimistischen Replikationsstrategie, weniger streng ausgelegt, ansonsten aber äquivalent zu AFS [5]. Failure Transparency: Kann als erfüllt angesehen werden. Durch die von Coda unterstützte Disconnected Operation können Benutzer auch bei längerer Nichterreichbarkeit von Server Prozessen aufgrund von Netzausfällen oder -partionierung, ohne Beeinträchtigungen weiterarbeiten. Allerdings kann es nach Ende der Disconnected Operation zu semantischen Konflikten kommen (siehe Abschnitt 3.4.4). Migration Transparency: Ist erfüllt (Siehe Abschnitt 3.3.3). Replication Transparency: Coda repliziert ganze Volumes. Die Einschränkung von AFS, wo nur read-only Volumes repliziert werden können, wurde bei Coda aufgehoben. Scalability: Coda kann im nachhinein um Server erweitert werden. Dadurch und durch die Verwendung von Replikation skaliert Coda sehr gut mit einer steigenden Anzahl von Benutzern und Dateien.

30 KAPITEL 3. ÜBERBLICK ÜBER VERTEILTE DATEISYSTEME 26 Security: Coda verwendet für die Authentifizierung von Benutzern und zur Verschlüsselung der Kommunikation zwischen Client und Server ein zu Kerberos [5] ähnliches Protokoll. Die Zugriffe auf Dateien und Verzeichnisse werden über Access Control Lists geregelt [1]. 3.5 Zusammenfassung Die Ergebnisse der Untersuchung der Dateisysteme NFS, AFS und Coda sind in Tabelle 3.1 zusammengefasst. Wie man sieht, kann Coda als das mächtigste Dateisystem angesehen werden. Es unterstützt als einziges Dateisystem Disconnected Operation und die Replizierung von beschreibbaren Verzeichnissen. NFS wurde mit der Version 4 so erweitert, daß es nun transparente Replizierung von read only Verzeichnissen sowie die Migration von Verzeichnissen unterstützt. Weiters kann man nun bei NFS zur Authentifizierung und Autorisation Kerberos und Acess Control Lists verwenden. AFS, der kleine Bruder von Coda, wird mittlerweile in dem Open Source Projekt OpenAFS weiterentwickelt. Es soll in Zukunft um Disconnected Operation erweitert werden. Ein neu entwickeltes Dateisystem sollte demnach wie Coda die Replizierung von beschreibbaren Verzeichnissen beziehungsweise Dateien unterstützen. Außerdem sollte die Kommunikation zwischen Client und Server verschlüsselt stattfinden. Das Service sollte einfach und transparent für die Clients um zusätzliche Server erweitert werden können, beziehungsweise Server sollten transparent für den Benutzer auf andere Rechner umziehen können.

Server: Vice nach Tanenbaum, van Steen

Server: Vice nach Tanenbaum, van Steen 3 Fallbeispiel: Coda Nachfolger des Andrew File Systems (AFS) Carnegie Mellon University, 1990 (CMU) Zielsetzung hohe Verfügbarkeit bei mehreren 10.000 Client-Rechnern Fehlertoleranz abgesetzter Betrieb

Mehr

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und AFS / OpenAFS Präsentiert von Bastian Steinert Und obert Schuppenies Agenda AFS Verteilte Dateisysteme, allg. Aufbau Sicherheit und Zugriffsrechte Installation Demo Vergleich zu anderen DFs Diskussion

Mehr

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015 Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2 3.3 Verteilte Dateisysteme Architektur Dateidienst-Interface Verlagerungsmodell (upload/download model) Ganze Dateien werden vom zum transferiert lund dort bearbeitet Typisch für Massenspeichersysteme,

Mehr

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE Tobias Jähnel und Peter Trommler Fakultät Informatik Georg-Simon-Ohm-Hochschule Nürnberg http://offlinefs.sourceforge.net Übersicht Hintergrund

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

Mehr

Verteilte Dateisysteme

Verteilte Dateisysteme Verteilte Dateisysteme Proseminar: Speicher und Dateisysteme Hauke Holstein Gliederung 1/23 - Einleitung - NFS - AFS - SMB Einleitung Was sind Verteilte Dateisysteme? 2/23 - Zugriff über ein Netzwerk -

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Einrichten der Outlook-Synchronisation

Einrichten der Outlook-Synchronisation Das will ich auch wissen! - Kapitel 3 Einrichten der Outlook-Synchronisation Inhaltsverzeichnis Überblick über dieses Dokument... 2 Diese Kenntnisse möchten wir Ihnen vermitteln... 2 Diese Kenntnisse empfehlen

Mehr

peer-to-peer Dateisystem Synchronisation

peer-to-peer Dateisystem Synchronisation Ziel Realisierungen Coda Ideen Fazit Literatur peer-to-peer Dateisystem Synchronisation Studiendepartment Informatik Hochschule für Angewandte Wissenschaften Hamburg 30. November 2007 Ziel Realisierungen

Mehr

2 Datei- und Druckdienste

2 Datei- und Druckdienste Datei- und Druckdienste 2 Datei- und Druckdienste Lernziele: Verteiltes Dateisystem (DFS) Dateiserver Ressourcen Manager (FSRM) Verschlüsseln Erweiterte Überwachung Prüfungsanforderungen von Microsoft:

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009

Lehrveranstaltung Speichersysteme Sommersemester 2009 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 12: Network File Systems André Brinkmann Beispiel: SUN NFS NFS (Network File System) ist ein offenes Protokoll für den Austausch von Dateien

Mehr

Betriebssystemschichten (11.03.2011)

Betriebssystemschichten (11.03.2011) Proseminar Speicher- und Dateisysteme (11.03.2011) Bernd Ihnen Übersicht 2/20 Einleitung Betriebssysteme/ Übersicht Mikrokernel Monolithischer Kernel Vergleich der Kernel Fallbeispiel Linux Kernelaufbau

Mehr

Er musste so eingerichtet werden, dass das D-Laufwerk auf das E-Laufwerk gespiegelt

Er musste so eingerichtet werden, dass das D-Laufwerk auf das E-Laufwerk gespiegelt Inhaltsverzeichnis Aufgabe... 1 Allgemein... 1 Active Directory... 1 Konfiguration... 2 Benutzer erstellen... 3 Eigenes Verzeichnis erstellen... 3 Benutzerkonto erstellen... 3 Profil einrichten... 5 Berechtigungen

Mehr

Ordner und Laufwerke aus dem Netzwerk einbinden

Ordner und Laufwerke aus dem Netzwerk einbinden Inhaltsverzeichnis 1. Einführung...2 2. Quellcomputer vorbereiten...3 2.1 Netzwerkeinstellungen...3 2.2 Ordner und Laufwerke freigeben...4 2.2.1 Einfache Freigabe...5 2.2.2 Erweiterte Freigabe...6 3. Zugriff

Mehr

Kurzanleitung zu. von Daniel Jettka 18.11.2008

Kurzanleitung zu. von Daniel Jettka 18.11.2008 Kurzanleitung zu Tigris.org Open Source Software Engineering Tools von Daniel Jettka 18.11.2008 Inhaltsverzeichnis 1.Einführung...1 2.Das Projektarchivs...3 2.1.Anlegen des Projektarchivs...3 2.2.Organisation

Mehr

Aufbau einer Testumgebung mit VMware Server

Aufbau einer Testumgebung mit VMware Server Aufbau einer Testumgebung mit VMware Server 1. Download des kostenlosen VMware Servers / Registrierung... 2 2. Installation der Software... 2 2.1 VMware Server Windows client package... 3 3. Einrichten

Mehr

Bibliographix installieren

Bibliographix installieren Bibliographix installieren Version 10.8.3 Inhalt Inhalt... 1 Systemvoraussetzungen... 1 Download... 2 Installation der Software... 2 Installation unter Windows... 2 Installation unter Mac OS X... 3 Installation

Mehr

Kryptographische Dateisysteme

Kryptographische Dateisysteme 1 Proseminar: Konzepte von Betriebssystemkomponenten 1 Kryptographische Dateisysteme 2 Übersicht über den Vortrag 2 Braucht man überhaupt Verschlüsslung von Dateisystemen? Konkrete Zielsetzung Cryptographic

Mehr

Einfu hrung in Subversion mit TortoiseSVN

Einfu hrung in Subversion mit TortoiseSVN Einfu hrung in Subversion mit TortoiseSVN Inhalt Konzept... 1 Begriffe... 1 Werkzeuge... 2 Arbeiten mit TortoiseSVN... 2 Vorbereitung... 2 Erster Checkout... 2 Hinzufügen eines neuen Verzeichnisses...

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Michael Flachsel. Das SAN an der TUB. Aufbau und Funktion. 15. November 2007

Michael Flachsel. Das SAN an der TUB. Aufbau und Funktion. 15. November 2007 Michael Flachsel Das SAN an der TUB Aufbau und Funktion 15. November 2007 Struktur Produktion Backup 2 (c) 2007 Michael Flachsel TUB-SAN" Hardware 3 (c) 2007 Michael Flachsel TUB-SAN" Komponenten 8x IBM

Mehr

juliteccrm Dokumentation

juliteccrm Dokumentation Customer Relationship Management für kleine und mittelständische Unternehmen juliteccrm Dokumentation 2012, julitec GmbH Page 1 of 12 julitec GmbH Flößaustraße 22 a 90763 Fürth Telefon: +49 911 979070-0

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

Mehr

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Übersicht UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Die in diesem Teil vorgestellten Informationen stellen lediglich das Prinzip dar - im Detail ist alles etwas komplizierter...

Mehr

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Caching Handbuch Auftraggeber: Version: 01 Projekttyp: Erstellt durch: Internet David Bürge INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Email david.buerge@inm.ch URL http://www.inm.ch

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

Einführung in die technische Informatik

Einführung in die technische Informatik Einführung in die technische Informatik Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Betriebssysteme Aufgaben Management von Ressourcen Präsentation einer einheitlichen

Mehr

DDBAC-SDK unter Linux (mit Wine) Installationsanleitung

DDBAC-SDK unter Linux (mit Wine) Installationsanleitung DDBAC-SDK unter Linux (mit Wine) Installationsanleitung Installation von Wine Einleitung Übersicht Titel Thema Datei DDBAC-SDK unter Linux (mit Wine) Installationsanleitung DDBAC_Wine_Installation.doc

Mehr

OpenAFS an der HSZ-T

OpenAFS an der HSZ-T Einführung Hochschule für Technik Zürich Studiengang Informatik 2.11.2008 Outline Einführung 1 Einführung Wieso? Geschichtlicher Rückblick 2 3 4 Einführung Wieso? Wieso? Geschichtlicher Rückblick Echtes

Mehr

38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional)

38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) 38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) Mit easy2000 haben Sie ein, im Vergleich zu anderen Anbietern, sehr preiswertes System für Ihr Business erworben. easy2000 ist auch im Netzwerkbetrieb

Mehr

XPRIS Update. Updates 2011. XPRIS Version: 8.0256 bis 8.0261. Mosberger EDV AG Lettenstrasse 7 6343 Rotkreuz. www.xpris.ch. Mosberger EDV AG Seite 1

XPRIS Update. Updates 2011. XPRIS Version: 8.0256 bis 8.0261. Mosberger EDV AG Lettenstrasse 7 6343 Rotkreuz. www.xpris.ch. Mosberger EDV AG Seite 1 Updates 2011 XPRIS Version: 8.0256 bis 8.0261 Mosberger EDV AG Lettenstrasse 7 6343 Rotkreuz www.xpris.ch Mosberger EDV AG Seite 1 Inhalt Dokumente pro Kunde... 3 Ein Dokument im Kundenstamm ablegen...

Mehr

Unterrichtseinheit 7

Unterrichtseinheit 7 Unterrichtseinheit 7 Freigegebene Ordner: Durch freigegebene Ordnern können Benutzer Zugriff auf Dateien und Ordner innerhalb eines Netzwerkes (auch bei verstreut gespeicherten Daten, mit Hilfe des Distributed

Mehr

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel VS7 Slide 1 Verteilte Systeme Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

ZMI Benutzerhandbuch Sophos. Sophos Virenscanner Benutzerhandbuch

ZMI Benutzerhandbuch Sophos. Sophos Virenscanner Benutzerhandbuch ZMI Benutzerhandbuch Sophos Sophos Virenscanner Benutzerhandbuch Version: 1.0 12.07.2007 Herausgeber Zentrum für Medien und IT ANSCHRIFT: HAUS-/ZUSTELLADRESSE: TELEFON: E-MAIL-ADRESSE: Zentrum für Medien

Mehr

storage management (c) Till Hänisch 2003, BA Heidenheim

storage management (c) Till Hänisch 2003, BA Heidenheim storage management (c) Till Hänisch 2003, BA Heidenheim warum? haenisch@susi:~ > df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 35115800 16351708 16980076 50% / /dev/sda1 23300 3486 18611

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN)

Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN) Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN) Prof. Dr. Rolf Dornberger Software-Engineering: 7.3 Versionsmanagement-Systeme

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

OP-LOG www.op-log.de

OP-LOG www.op-log.de Verwendung von Microsoft SQL Server, Seite 1/18 OP-LOG www.op-log.de Anleitung: Verwendung von Microsoft SQL Server 2005 Stand Mai 2010 1 Ich-lese-keine-Anleitungen 'Verwendung von Microsoft SQL Server

Mehr

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt. Arbeitsblätter Der Windows Small Business Server 2011 MCTS Trainer Vorbereitung zur MCTS Prüfung 70 169 Aufgaben Kapitel 1 1. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

Mehr

teamspace TM Outlook Synchronisation

teamspace TM Outlook Synchronisation teamspace TM Outlook Synchronisation Benutzerhandbuch teamsync Version 1.4 Stand Dezember 2005 * teamspace ist ein eingetragenes Markenzeichen der 5 POINT AG ** Microsoft Outlook ist ein eingetragenes

Mehr

DocuWare unter Windows 7

DocuWare unter Windows 7 DocuWare unter Windows 7 DocuWare läuft unter dem neuesten Microsoft-Betriebssystem Windows 7 problemlos. Es gibt jedoch einige Besonderheiten bei der Installation und Verwendung von DocuWare, die Sie

Mehr

Informatives zur CAS genesisworld-administration

Informatives zur CAS genesisworld-administration Informatives zur CAS genesisworld-administration Inhalt dieser Präsentation Loadbalancing mit CAS genesisworld Der CAS Updateservice Einführung in Version x5 Konfigurationsmöglichkeit Sicherheit / Dienstübersicht

Mehr

Pervasive.SQL ODBC Treiber. ab ABACUS 2006.20er-Version Installationsanleitung

Pervasive.SQL ODBC Treiber. ab ABACUS 2006.20er-Version Installationsanleitung Inhaltsverzeichnis Pervasive.SQL ODBC Treiber ab ABACUS 2006.20er-Version Installationsanleitung Mai 2013 / CL 1 Serverinstallation... 1 2 Clientinstallation... 8 WICHTIG Alle untenstehenden Schritte müssen

Mehr

EINFÜHRUNG. Durch Model Sharing. Model Sharing ist Bestandteil von Tekla Structures 21.0 Es ist keine zusätzliche Installation notwendig

EINFÜHRUNG. Durch Model Sharing. Model Sharing ist Bestandteil von Tekla Structures 21.0 Es ist keine zusätzliche Installation notwendig TEKLA MODEL SHARING EINFÜHRUNG Durch Model Sharing können mehrere Anwender gemeinsam an einem Modell arbeiten können die Anwender räumlich und zeitlich unabhängig von einander arbeiten ist keine permanente

Mehr

08.05.2012 UNIX. Linux. UNIX Derivate, die wichtigsten. Free BSD (Open) Solaris MacOS X Linux. UNIX Dateisystem, wichtige Ordner.

08.05.2012 UNIX. Linux. UNIX Derivate, die wichtigsten. Free BSD (Open) Solaris MacOS X Linux. UNIX Dateisystem, wichtige Ordner. 23 UNIX Einführung in Betriebssysteme UNIX AM BEISPIEL LINUX entwickelt Anfang der 1970er Jahre von Ken Thompson und Dennis Ritchie (Bell Laboratories) Quelle: Wikipedia Zusammen und auf der Basis von

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Jeder Datenträger besitzt einen I-Node-Array. Jede Datei auf dem Datenträger hat einen I-Node-Eintrag.

Jeder Datenträger besitzt einen I-Node-Array. Jede Datei auf dem Datenträger hat einen I-Node-Eintrag. Einführung in die Betriebssysteme Fallstudien zu Dateisystemen Seite 1 Unix-Dateisystem Der Adreßraum einer Datei wird in gleichlange Blöcke aufgeteilt. Ein Block hat die Länge von 1 oder mehreren Sektoren

Mehr

Storage Engineering. Version 1.0. Januar 2008. TEKKVIS Consultants GmbH. s p i c e u p y o u r k n o w l e d g e. Gartenstrasse 24 CH-5432 Neuenhof

Storage Engineering. Version 1.0. Januar 2008. TEKKVIS Consultants GmbH. s p i c e u p y o u r k n o w l e d g e. Gartenstrasse 24 CH-5432 Neuenhof s p i c e u p y o u r k n o w l e d g e Storage Engineering Version 1.0 Januar 2008 TEKKVIS Consultants GmbH Gartenstrasse 24 CH-5432 Neuenhof www.tekkvis.ch Inhaltsverzeichnis 1. Storage Engineering 1.1

Mehr

Protected User-Level DMA in SCI Shared Memory Umgebungen

Protected User-Level DMA in SCI Shared Memory Umgebungen Protected User-Level DMA in SCI Shared Memory Umgebungen Mario Trams University of Technology Chemnitz, Chair of Computer Architecture 6. Halle Chemnitz Seminar zu Parallelverarbeitung und Programmiersprachen

Mehr

Seminarvortrag Secure NFS

Seminarvortrag Secure NFS Seminarvortrag Secure NFS Michael Stilkerich michael.stilkerich@informatik.stud.uni-erlangen.de am 12. Mai 2003 Einleitung Das Network File System ist ein sehr eleganter Weg, gemeinsam genutzte Dateisysteme

Mehr

Um dies zu tun, öffnen Sie in den Systemeinstellungen das Kontrollfeld "Sharing". Auf dem Bildschirm sollte folgendes Fenster erscheinen:

Um dies zu tun, öffnen Sie in den Systemeinstellungen das Kontrollfeld Sharing. Auf dem Bildschirm sollte folgendes Fenster erscheinen: Einleitung Unter MacOS X hat Apple die Freigabe standardmäßig auf den "Public" Ordner eines Benutzers beschränkt. Mit SharePoints wird diese Beschränkung beseitigt. SharePoints erlaubt auch die Kontrolle

Mehr

Prozessarchitektur einer Oracle-Instanz

Prozessarchitektur einer Oracle-Instanz 6. Juni 2008 Inhaltsverzeichnis Oracle Instanz 1 Oracle Instanz 2 3 Redo Log Buffer Shared Pool Java Pool & Large Pool Oracle Instanz Eine Oracle-Instanz ist Hauptbestandteil des Oracle Datenbank Management

Mehr

Funktion rsync mit den actinas Cube Systemen.

Funktion rsync mit den actinas Cube Systemen. Funktion rsync mit den actinas Cube Systemen. Unternehmen haben oft keine ausgebildete IT Abteilung. Trotzdem oder gerade deshalb sind Backups so wichtig, denn das ist im Falle eines Datenverlustes, Ihre

Mehr

CFS und TCFS. 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung

CFS und TCFS. 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung CFS und TCFS 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung CFS und TCFS 1. Ziele des Dateisystems 2. CFS als Lösung 3. CFS in der Anwendung 4. Verbesserungen bei TCFS 5. Anwendung

Mehr

EBW Systems HANDBUCH Offline Programm

EBW Systems HANDBUCH Offline Programm EBW Systems HANDBUCH Offline Programm Seite 1 von 7 Inhaltsverzeichnis 1. Programmsteuerung 2. Veranstaltungen verwalten 3. Daten absenden 4. Sonstige Hinweise Seite 2 von 7 1. Programmsteuerung Programm

Mehr

X5 unter Windows Vista / 7 und Windows 2008 Server

X5 unter Windows Vista / 7 und Windows 2008 Server X5 unter Windows Vista / 7 und Windows 2008 Server Die Benutzerkontensteuerung (später UAC) ist ein Sicherheitsfeature welches Microsoft ab Windows Vista innerhalb Ihrer Betriebssysteme einsetzt. Die UAC

Mehr

3 Entwerfen von Identitäts- und

3 Entwerfen von Identitäts- und 3 Entwerfen von Identitäts- und Zugriffsmanagementkomponenten Prüfungsanforderungen von Microsoft: Designing Support Identity and Access Management Components o Plan for domain or forest migration, upgrade,

Mehr

Kap. 8: Dateisysteme (E3 EXT2 Dateisystem) 1

Kap. 8: Dateisysteme (E3 EXT2 Dateisystem) 1 Kap. 8: Dateisysteme (E3 EXT2 Dateisystem) 1 E 3 EXT2 Dateisystem Lernziele Aufbau des ext2-dateisystems kennenlernen Verwaltungsstrukturen auf dem Datenträger analysieren Hard- und Softlinks Übungsumgebung

Mehr

Handbuch zum Umgang mit dem. Open Ticket Request System OTRS

Handbuch zum Umgang mit dem. Open Ticket Request System OTRS Handbuch zum Umgang mit dem Open Ticket Request System OTRS Inhaltsverzeichnis 1 Allgemeine Funktionen... 1 1.1 Anmeldung... 1 1.2 Beschreibung der Oberfläche... 1 1.2.1 Einstellungen... 2 1.2.2 Verantwortlicher...

Mehr

KURZANLEITUNG CLOUD OBJECT STORAGE

KURZANLEITUNG CLOUD OBJECT STORAGE KURZANLEITUNG CLOUD OBJECT STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung... Seite 03 2. Anmelden am Cloud&Heat Dashboard... Seite 04 3. Anlegen eines Containers... Seite 05

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

1 Änderungen bei Windows Server 2008 R2

1 Änderungen bei Windows Server 2008 R2 1 Änderungen bei Windows Server 2008 R2 1.1 Der BranchCache Eine völlig neue Möglichkeit, auf Ressourcen zuzugreifen, bietet der BranchCache. In vielen Firmen gibt es Zweigstellen, die mit der Hauptstelle

Mehr

Alle alltäglichen Aufgaben können auch über das Frontend durchgeführt werden, das in den anderen Anleitungen erläutert wird.

Alle alltäglichen Aufgaben können auch über das Frontend durchgeführt werden, das in den anderen Anleitungen erläutert wird. Der Admin-Bereich im Backend Achtung: Diese Anleitung gibt nur einen groben Überblick über die häufigsten Aufgaben im Backend-Bereich. Sollten Sie sich nicht sicher sein, was genau Sie gerade tun, dann

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009

Lehrveranstaltung Speichersysteme Sommersemester 2009 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 11: Network File Systems Part 1 André Brinkmann Gliederung Network AFached Storage Speichertechnologien hinter NAS Verteilte Dateisysteme NFS

Mehr

Fuse. Filesystem in Userspace PRÄSENTATION VON TIM WELGE

Fuse. Filesystem in Userspace PRÄSENTATION VON TIM WELGE Fuse Filesystem in Userspace PRÄSENTATION VON TIM WELGE 1 INHALTSVERZEICHNIS Einführung Was ist ein Dateisystem Was ist der Userspace FUSE Andere Schlüssel Funktionen Beispiele Wie funktioniert FUSE Schreiben

Mehr

Anleitungen zu Inside FHNW

Anleitungen zu Inside FHNW Anleitungen zu Inside FHNW Jasmin Kämpf, Sabina Tschanz und Caroline Weibel, elearning.aps@fhnw.ch Version 1.0 20.8.14 Zürich, August 2014 1 Inhaltsverzeichnis 1. Anleitung Inside FHNW Gruppe eröffnen

Mehr

Outlook-Abgleich. Änderungen, Irrtümer und Druckfehler vorbehalten. Bearbeitet von Harald Borges. Stand April 2015 www.cobra.de

Outlook-Abgleich. Änderungen, Irrtümer und Druckfehler vorbehalten. Bearbeitet von Harald Borges. Stand April 2015 www.cobra.de Outlook-Abgleich Copyright 2015 cobra computer s brainware GmbH cobra Adress PLUS, cobra CRM PLUS, cobra CRM PRO und cobra CRM BI sind eingetragene Warenzeichen der cobra computer s brainware GmbH. Andere

Mehr

FrogSure Installation und Konfiguration

FrogSure Installation und Konfiguration FrogSure Installation und Konfiguration 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis...1 2 Installation...1 2.1 Installation beginnen...2 2.2 Lizenzbedingungen...3 2.3 Installationsordner auswählen...4 2.4

Mehr

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen.

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen. 1 Passwort ändern Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern Dazu klicken Sie bitte auf Ihren Namen Abb 1-1 Erstmaliger Anmeldung Danach erscheint ein PopUp indem Sie Ihr Passwort

Mehr

Anleitung für das Content Management System

Anleitung für das Content Management System Homepage der Pfarre Maria Treu Anleitung für das Content Management System Teil 5 Fotogalerien Anlegen neuer Fotoalben Das Anlegen neuer Fotoalben erfolgt in zwei bzw. drei Schritten: Im ersten Schritt

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

MAXDATA PrimeBackup Secure Client Kurzanleitung

MAXDATA PrimeBackup Secure Client Kurzanleitung MAXDATA PrimeBackup Secure Client Kurzanleitung Inhalt Inhalt... II 1. Einführung... 1 2. Die Installation... 2 3. Erster Start... 3 3.1. Kennwort ändern... 4 3.2. Sicherung löschen... 4 3.3. Konfigurations-Möglichkeiten...

Mehr

Virtual Private Network Ver 1.0

Virtual Private Network Ver 1.0 Virtual Private Network Ver 1.0 Mag Georg Steingruber Veröffentlicht: April 2003 Installationsanleitung für den Einsatz der im Microsoft-BM:BWK Schoolagreement enthaltenen Serverprodukte Abstract Dieses

Mehr

Cookies. Krishna Tateneni Jost Schenck Übersetzer: Jürgen Nagel

Cookies. Krishna Tateneni Jost Schenck Übersetzer: Jürgen Nagel Krishna Tateneni Jost Schenck Übersetzer: Jürgen Nagel 2 Inhaltsverzeichnis 1 Cookies 4 1.1 Regelungen......................................... 4 1.2 Verwaltung..........................................

Mehr

SANDBOXIE konfigurieren

SANDBOXIE konfigurieren SANDBOXIE konfigurieren für Webbrowser und E-Mail-Programme Dies ist eine kurze Anleitung für die grundlegenden folgender Programme: Webbrowser: Internet Explorer, Mozilla Firefox und Opera E-Mail-Programme:

Mehr

How-to: VPN mit IPSec und Gateway to Gateway. Securepoint Security System Version 2007nx

How-to: VPN mit IPSec und Gateway to Gateway. Securepoint Security System Version 2007nx Securepoint Security System Version 2007nx Inhaltsverzeichnis VPN mit IPSec und Gateway to Gateway... 3 1 Konfiguration der Appliance... 4 1.1 Erstellen von Netzwerkobjekten im Securepoint Security Manager...

Mehr

SSH Authentifizierung über Public Key

SSH Authentifizierung über Public Key SSH Authentifizierung über Public Key Diese Dokumentation beschreibt die Vorgehensweise, wie man den Zugang zu einem SSH Server mit der Authentifizierung über öffentliche Schlüssel realisiert. Wer einen

Mehr

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen Abgleich von Adressen und Terminen Stand Juni 2004 Was ist CAS genesisworld.exchange connect? Inhalt 1 Was ist CAS genesisworld.exchange connect?... 3 2 Systemvoraussetzungen... 5 2.1 Software...5 2.2

Mehr

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Verwendung der bereitgestellten Virtuellen Maschinen»Einrichten einer Virtuellen Maschine mittels VirtualBox sowie Zugriff auf

Mehr

Hinweise zu A-Plan 2009 SQL

Hinweise zu A-Plan 2009 SQL Hinweise zu A-Plan 2009 SQL Für Microsoft Windows Copyright Copyright 2008 BRainTool Software GmbH Inhalt INHALT 2 EINLEITUNG 3 WAS IST A-PLAN 2009 SQL? 3 WANN SOLLTE A-PLAN 2009 SQL EINGESETZT WERDEN?

Mehr

8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe:

8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe: 8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe: Client für Microsoft Netzwerke: - Remote Volumes werden sichtbar, - Rechner im Netz werden sichtbar,

Mehr

Linux Hochverfügbarkeits-Cluster

Linux Hochverfügbarkeits-Cluster Seminarunterlage Version: 5.05 Version 5.05 vom 23. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Installation über MSI. CAS genesisworld mit MSI-Paketen installieren

Installation über MSI. CAS genesisworld mit MSI-Paketen installieren Installation über MSI CAS genesisworld mit MSI-Paketen installieren 1 Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den Beispielen verwendeten

Mehr

Universität Karlsruhe (TH)

Universität Karlsruhe (TH) Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Cluster-Praktikum Sommersemester 2007 Transparent Replizierte Objekte in JavaParty Institut für Programmstrukturen und Datenorganisation

Mehr

Eingehende E-Mails überwachen, abrufen und verteilen

Eingehende E-Mails überwachen, abrufen und verteilen Seite 1 Dieser Workshop behandelt den E-Mail Posteingang. Grundlegende Funktionen und Überlegungen : DokuWork beinhaltet einen eigenen E-Mail Client mit dem über das POP3 Protokoll E-Mails von einem E-Mail

Mehr

Step by Step VPN unter Windows Server 2003. von Christian Bartl

Step by Step VPN unter Windows Server 2003. von Christian Bartl Step by Step VPN unter Windows Server 2003 von VPN unter Windows Server 2003 Einrichten des Servers 1. Um die VPN-Funktion des Windows 2003 Servers zu nutzen muss der Routing- und RAS-Serverdienst installiert

Mehr

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes. Binäre Bäume Definition: Ein binärer Baum T besteht aus einer Menge von Knoten, die durch eine Vater-Kind-Beziehung wie folgt strukturiert ist: 1. Es gibt genau einen hervorgehobenen Knoten r T, die Wurzel

Mehr

FTP-Leitfaden RZ. Benutzerleitfaden

FTP-Leitfaden RZ. Benutzerleitfaden FTP-Leitfaden RZ Benutzerleitfaden Version 1.4 Stand 08.03.2012 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Zeitaufwand... 3 2 Beschaffung der Software... 3 3 Installation... 3 4 Auswahl des Verbindungstyps...

Mehr

Verschlüsseln von Dateien mit Hilfe einer TCOS-Smartcard per Truecrypt. T-Systems International GmbH. Version 1.0 Stand 29.06.11

Verschlüsseln von Dateien mit Hilfe einer TCOS-Smartcard per Truecrypt. T-Systems International GmbH. Version 1.0 Stand 29.06.11 Verschlüsseln von Dateien mit Hilfe einer TCOS-Smartcard per Truecrypt T-Systems International GmbH Version 1.0 Stand 29.06.11 Impressum Herausgeber T-Systems International GmbH Untere Industriestraße

Mehr

Rembo/mySHN. Version 2.0 Kurzanleitung. das selbstheilende Netzwerk. Stand: 01.05.2006. my selfhealing network

Rembo/mySHN. Version 2.0 Kurzanleitung. das selbstheilende Netzwerk. Stand: 01.05.2006. my selfhealing network Rembo/mySHN Version 2.0 Kurzanleitung das selbstheilende Netzwerk my selfhealing network Stand: 01.05.2006 Postanschrift: SBE network solutions GmbH Edisonstrasse 21 74076 Heilbronn IV Inhalt Kurzanleitung...i

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

Novell Filr Inhaltsverzeichnis

Novell Filr Inhaltsverzeichnis Novell Filr Inhaltsverzeichnis 1. Webanwendung...2 1.1 Aufbau...2 1.2 Funktionen...2 1.2.1 Meine Dateien...2 1.2.2 Für mich freigegeben...3 1.2.3 Von mir freigegeben...4 1.2.4 Netzwerkordner...4 1.2.5

Mehr