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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ü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

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

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

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

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

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

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

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

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

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

Verteiltes Persistenz-System. Mykhaylo Kabalkin

Verteiltes Persistenz-System. Mykhaylo Kabalkin Verteiltes Persistenz-System Mykhaylo Kabalkin 01.12.2006 Übersicht Motivation und Problematik Ziel Anforderungen Systemarchitektur erster Entwurf Architekturkomponenten Risiken 01.12.2006 Seminar Ringvorlesung

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

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

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

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

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

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

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

Wiederholung: Realisierung von Dateien

Wiederholung: Realisierung von Dateien Wiederholung: Realisierung von Dateien Zusammenhängende Belegung Datei A Datei C Datei E Datei G Datei B Datei D Datei F Belegung durch verkettete Listen (z.b. FAT) Dateiblock 0 Dateiblock 1 Dateiblock

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

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

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

36 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional)

36 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) 36 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) Wenn Sie easy2000 in einem Netzwerk installieren, ist die Anwendung auf jedem Rechner im Netzwerk ausführbar und mehrere Benutzer können gleichzeitig

Mehr

bla bla Guard Benutzeranleitung

bla bla Guard Benutzeranleitung bla bla Guard Benutzeranleitung Guard Guard: Benutzeranleitung Veröffentlicht Mittwoch, 03. September 2014 Version 1.0 Copyright 2006-2014 OPEN-XCHANGE Inc. Dieses Werk ist geistiges Eigentum der Open-Xchange

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

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

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

Was machen wir heute? Betriebssysteme Tutorium 10. Frage 10.1.a. Frage 10.1.a

Was machen wir heute? Betriebssysteme Tutorium 10. Frage 10.1.a. Frage 10.1.a Was machen wir heute? Betriebssysteme Tutorium 10 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

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

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Installationsanleitung für die netzbasierte Variante Bis Version 3.5. KnoWau, Allgemeine Bedienhinweise Seite 1

Installationsanleitung für die netzbasierte Variante Bis Version 3.5. KnoWau, Allgemeine Bedienhinweise Seite 1 1 Installationsanleitung für die netzbasierte Variante Bis Version 3.5 Copyright KnoWau Software 2013 KnoWau, Allgemeine Bedienhinweise Seite 1 2 Seite absichtlich leer KnoWau, Allgemeine Bedienhinweise

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock

Mehr

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Technische Mitteilung Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Informationen zum Dokument Kurzbeschreibung Dieses Dokument gibt Hinweise zur Konfiguration des RDBMS Oracle und von VIP ContentManager

Mehr

1 Network File System ( NFS )

1 Network File System ( NFS ) Network File System 1 Network File System ( NFS ) 1.1 Motivation für die Entwicklung Mit Hilfe von ftp können komplette reguläre Dateien von einem Rechner über das Netzwerk zu einem anderen Rechner transferiert

Mehr

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161?

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161? Was machen wir heute? Betriebssysteme Tutorium 2 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

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

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

PADS 3.0 Viewer - Konfigurationen

PADS 3.0 Viewer - Konfigurationen PADS 3.0 Viewer - Konfigurationen Net Display Systems (Deutschland) GmbH - Am Neuenhof 4-40629 Düsseldorf Telefon: +49 211 9293915 - Telefax: +49 211 9293916 www.fids.de - email: info@fids.de Übersicht

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

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2012 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

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

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

Adressverwaltung. Adressen erfassen

Adressverwaltung. Adressen erfassen Adressverwaltung Löschen ohne Nachfrage Ja/Nein Duplizieren beim Erfassen Ja/Nein Notizen Ja/Nein Gruppen Ja/Nein Externe Objekte Ja/Nein Adressen erfassen Um eine neue Adresse zu erfassen benutzen Sie

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

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

WinSCP Zugriff auf Daten des Uni-Netzwerkes

WinSCP Zugriff auf Daten des Uni-Netzwerkes WinSCP Zugriff auf Daten des Uni-Netzwerkes Robert Hillig 2013/03 1. Vorwort Das Universitätsnetzwerk ist von außen per SSH (Secure SHell) über login.tu-chemnitz.de auf Port 22 erreichbar. SSH ist ein

Mehr

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort Was machen wir heute? Betriebssysteme Tutorium 12 1 Organisatorisches Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität

Mehr

Handbuch für ios 1.4 1

Handbuch für ios 1.4 1 Handbuch für ios 1.4 1 Inhaltsverzeichnis 1. Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 4 2. Installation... 5 3. Grundfunktionen... 6 3.1. Einrichtung von Boxcryptor

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

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

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

AFS/OpenAFS als Cluster-Dateisystem (?)

AFS/OpenAFS als Cluster-Dateisystem (?) als Cluster-Dateisystem (?) Sebastian Heidl Plan Einführung, Historisches Überblick, Benutzung Sicherheit Funktionsweise AFS verteiltes Dateisystem auf Client/Server Basis geeignet/konzipiert

Mehr

telpho10 Hylafax Server

telpho10 Hylafax Server telpho10 Hylafax Server Version 2.6.1 Stand 02.07.2012 VORWORT... 2 NACHTRÄGLICHE INSTALLATION HYLAFAX SERVER... 3 HYLAFAX ENDGERÄT ANLEGEN... 5 HYLAFAX ENDGERÄT BEARBEITEN... 6 ALLGEMEIN... 6 HYLAFAX

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

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

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

Kooperativer Speicher: Schwächen und Gegenmaßnahmen

Kooperativer Speicher: Schwächen und Gegenmaßnahmen Kooperativer Speicher: Schwächen und Gegenmaßnahmen Cooperative storage: weaknesses and countermeasures Lutz Behnke 2. Dezember 2005 2005 Lutz Behnke 1 /home/sage/texte/haw/master/seminar/coop_storage_failure.sxi

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Zentrale Installation

Zentrale Installation Einführung STEP 7 wird durch ein Setup-Programm installiert. Eingabeaufforderungen auf dem Bildschirm führen Sie Schritt für Schritt durch den gesamten Installationsvorgang. Mit der Record-Funktion steht

Mehr

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

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

Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen. 11.10.2007 Christian Schmidt

Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen. 11.10.2007 Christian Schmidt Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen 11.10.2007 Christian Schmidt Agenda Ausgangssituation am Beispiel der IBB Einführung in NFS und

Mehr

Neuigkeiten in Microsoft Windows Codename Longhorn. 2006 Egon Pramstrahler - egon@pramstrahler.it

Neuigkeiten in Microsoft Windows Codename Longhorn. 2006 Egon Pramstrahler - egon@pramstrahler.it Neuigkeiten in Microsoft Windows Codename Longhorn Windows Server - Next Generation Derzeit noch Beta Version (aktuelles Build 5308) Weder definitiver Name und Erscheinungstermin sind festgelegt Direkter

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

Mehr

NETZWERKHANDBUCH. Druckprotokoll im Netzwerk speichern. Version 0 GER

NETZWERKHANDBUCH. Druckprotokoll im Netzwerk speichern. Version 0 GER NETZWERKHANDBUCH Druckprotokoll im Netzwerk speichern Version 0 GER Hinweise in dieser Anleitung In diesem Handbuch wird das folgende Symbol verwendet: Hier finden Sie Hinweise, wie auf eine bestimmte

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

SVN Windows Howto. Inhaltsverzeichnis. 1 Revisionsgeschichte

SVN Windows Howto. Inhaltsverzeichnis. 1 Revisionsgeschichte Inhaltsverzeichnis SVN Windows Howto DI Werner Damböck (2008) public: svn://193.170.118.37/et/howto/svn-howto-htl-et.pdf source: svn://193.170.118.37/damb/howto/svn-howto-htl-et.odt 1 Revisionshierarchie...1

Mehr