Projektbericht
Sven Gärner
Coda und mobile Clients
Fakultät Technik und Informatik Faculty of Engineering and Computer Science
Sven Gärner
Coda und mobile Clients
Seminararbeit eingereicht im Rahmen der Projektveranstaltung im Studiengang Master Of Science Informatik
am Studiendepartment Informatik der Fakultät Technik und Informatik
der Hochschule für Angewandte Wissenschaften Betreuender Professor: Prof. Dr. rer. nat. Kai von Luck
Sven Gärner
Thema der
Coda und mobile Clients Stichworte
verteilte Dateisysteme, mobile Clients, Coda, Hochverfügbarkeit, Skalierbarkeit Kurzzusammenfassung
Coda ist ein verteiltes Dateisystem mit der besonderen Eigenschaft, mobilen Clients den Zugriff auf häufig zugegriffene Dateien zu gewähren, auch wenn keine Verbindung zum Dateiserver besteht. In dieser Arbeit soll nach vorheriger praktischer Untersuchung aufge- zeigt werden, inwieweit die Anbindung mobiler Clients funktioniert und welche Probleme auftraten.
Sven Gärner
Title of the paper
Coda and mobile clients Keywords
distributed filesystems, mobile clients, Coda, high availability, scalability Abstract
Coda is a distributed filesystem with an extraordinary property. It allows mobile clients to access recently used files without being connected to the file server. This paper is based on a previously practical examination of Coda and discusses problems and possibilities of this filesystem.
Inhaltsverzeichnis
1 Einleitung 5
2 Szenario 6
3 Coda 7
3.1 Geschichte und Entwicklung . . . 7
3.2 Architektur . . . 8
3.3 Anforderungen . . . 9
4 Projekt 10 4.1 Testumgebung . . . 10
4.2 Ergebnisse . . . 11
4.3 Allgemeine Funktionstests . . . 11
4.3.1 Zentrales Benutzerverzeichnis . . . 12
4.3.2 Manuelles Befüllen des Caches . . . 12
4.3.3 Backup . . . 13
4.3.4 Replizierte Volumes . . . 13
5 Fazit 15 Literaturverzeichnis 16 A Anhang 17 A.1 Installation vonDebian GNU/Linux . . . 17
A.2 Installation vonCoda . . . 17
A.3 DNS Anpassungen . . . 18
A.4 Hoardingdes Benutzerverzeichnisses . . . 18
1 Einleitung
Mit einer steigenden Anzahl an Computern pro Anwender und einem zunehmenden Einsatz von Notebooks, steigt auch die Notwendigkeit, Dateien zwischen diesen Computern auszutauschen.
Es gibt viele Anwendungen, die Anwender bei dem Austausch von Dateien zwischen Computern unterstützen.
Um einen möglichst automatischen Austausch der Dateien eines Benutzers zwischen seinen Computern zu ermöglichen, kann neben verschiedenen manuellen Synchronisationsarten auch ein verteiltes Dateisystem eingesetzt werden. Coda [6] ist ein verteiltes Dateisystem, das die Anbin- dung von Notebooks an zentrale Dateiserver und den Zugriff auf gewisse Dateien ermöglicht, auch wenn kein Dateiserver erreichbar ist. Im Rahmen des Projekts wurdeCoda untersucht und dabei insbesondere die Eigenschaft, auch ohne Verbindung zum Dateiserver auf zentral verfügbare Da- teien zuzugreifen.
Nach Beschreibung eines Szenarios, das die Notwendigkeit des Einsatzes dieses speziellen Datei- systems verdeutlicht, wird das verteilte DateisystemCoda vorgestellt. Anschließend wird darge- stellt, inwieweit die sich aus dem Szenario ergebenden Anforderungen erreicht beziehungsweise nicht erreicht werden konnten.
Abschließend soll ein Fazit gezogen werden, um aufzuzeigen, was beim Einsatz von Coda zu beachten ist.
2 Szenario
In diesem Kapitel soll zunächst ein Szenario dargestellt werden, um daraus anschließend Anforde- rungen abzuleiten, die dann als Ausgangspunkt für die Untersuchung des verteilten Dateisystems Coda dienen sollen.
In Firmen werden verstärkt Notebooks eingesetzt. Gerade wenn Mitarbeiter häufig auf Reisen sind, ist dies in der Regel der Fall. Da das Notebook in die Infrastruktur der Firma eingebunden ist, haben Mitarbeiter Zugriff auf verschiedene Verzeichnisse, die auf zentralen Servern gespei- chert sind. Dort befinden sich neben dem Benutzerverzeichnis des Mitarbeiters, auf das nur der jeweilige Benutzer Zugriff hat, auch gemeinsam genutzte Verzeichnisse. Der Vorteil des zentralen Servers liegt einerseits darin, die Dateien der jeweiligen Mitarbeiter in der Datensicherung zu be- rücksichtigen, andererseits wird so ermöglicht, genügend Speicherplatz zur Verfügung zu stellen.
Weiterhin lassen sich so auch defekte Computer leichter austauschen, da im Grunde keine Daten auf einzelnen Computern vorhanden und zu sichern sind.
Im Falle eines Notebooks sieht dies ganz anders aus. Dort befinden sich die Dateien auf der lo- kalen Festplatte und möglicherweise werden diese bei Bedarf in das Benutzerverzeichnis auf dem Server kopiert. Dadurch wird das Risiko eines Datenverlusts erhöht, sofern die Dateien immer manuell kopiert werden, da versehentlich Änderungen nicht erkannt und Dateien überschrieben werden. Mit Hilfe geeigneter Anwendungen, beispielsweiseUnison[10], kann das Risiko minimiert werden. Dennoch ist der Mitarbeiter gefordert, die Synchronisation regelmäßig manuell auszufüh- ren.
Aus Sicht der Administratoren ist es sicherlich einfacher, würde diese Synchronisation automa- tisch ablaufen. Jedesmal, wenn der Mitarbeiter sein Notebook mit dem Firmennetzwerk verbindet, ob über das LAN (Local Area Network) oder ein VPN1 (Virtual Private Network), könnte diese Synchronisation erfolgen.
Gerade die Anbindung eines mobilen Computers wie im Falles des Notebooks, das sehr häufig vom Netzwerk getrennt betrieben wird, wirft die Frage auf, wie dies funktionieren könnte. Daher wird im nächsten Kapitel Coda vorgestellt, das diese widersprüchlich erscheinende Möglichkeit bietet, einem vom Netzwerk getrennten Notebook Zugriff auf Dateien eines zentralen Dateiservers zu ermöglichen.
1Wikipedia:http://de.wikipedia.org/wiki/Virtual_Private_Network
3 Coda
In diesem Kapitel sollCoda vorgestellt werden. Dazu soll zunächst auf die Entwicklung, anschlie- ßend auf die Architektur und abschließend auf die Anforderungen eingegangen werden.
3.1 Geschichte und Entwicklung
Coda wird an der Carnegie Mellon University (CMU) seit etwa 1987 entwickelt. Entstanden ist Coda aus einer Erweiterung für dasAndrew File System Version 2 (AFS) [3], das ebenfalls an der CMU entwickelt wurde.AFS wurde darauf ausgelegt, problemlos von etwa 10.000 Clients genutzt zu werden, da es an der Universität selbst eingesetzt wurde [vgl.1, S. 678]. Gegen Ende der 1980er Jahre kam es aufgrund der Größe der Infrastruktur zu häufigen Server- oder Netzwerkausfällen, so dass die Anwender Probleme beim Zugriff auf ihre Dateien hatten [vgl.2]. Um diese Probleme zu beheben, sollte eben diese Erweiterung zuAFS entwickelt werden, die trotz dieser Ausfälle ein weiterarbeiten ermöglichen sollte. Während etwa zweijähriger Erfahrung mit dem Einsatz vonCo- da sind Defizite und neue Anwendungsfälle zu Tage getreten, inbesondere die Möglichkeit, mobile Computer anzubinden, wurde berücksichtigt [vgl.8, Kapitel 1].
Portable computers are commonplace today. In conjunction with high- and low-bandwidth cord- less networking technology, such computers will soon provide a pervasive hardware base for mobile computing. A key requirement of this new world of computing will be the ability to access critical data regardless of location. Satyanarayanan, M. u.a.(1993) Dies beschreibt einen Teil der Anforderungen, die in Kapitel2(S.6) genannt wurden, den Zugriff auf die Dateien, unabhängig vom Ort und auch über schmalbandige Leitungen.
Coda ist noch immer ein Forschungsprojekt an der CMU und wird kontinuierlich weiterentwi- ckelt. Leider ist an einigen Stellen zu spüren, dass es sich nicht um ein weitverbreitetes, im Pro- duktiveinsatz befindliches System handelt. Dies zeigt sich etwa bei der Benutzung einzelner Tools, bei nicht funktionierenden Funktionen und nicht kompilierbarer Kerberos Unterstützung. Doch aufgrund kontinuierlicher Weiterentwicklung sollten diese Probleme langfristig gelöst werden.
Nachfolgend soll nun die Architektur vorgestellt werden.
3 Coda
3.2 Architektur
Die Architektur vonCoda orientiert sich sehr stark an der Architektur vonAFS [vgl.7] und trennt strikt zwischen Server und Client. Server werden nur von Administratoren gepflegt und sind in re- lativ geringer Anzahl vorhanden, Clients hingegen sind in wesentlich höherer Anzahl im Einsatz.
Ein Coda Server verwaltet sogenannte Volumes, in denen Dateien und Verzeichnisse abgelegt werden. Die Volumes werden, um sie dem Anwender zugänglich zu machen, ähnlich dem Unix- Dateisystem unterhalb eines Verzeichnisses eingehängt (gemountet). Ein Anwender sieht daher nur eine Verzeichnisstruktur und keine Volumes. Volumes dienen auch nur administrativen Zwe- cken. Für Volumes lassen sich Berechtigungen vergeben, die über normale Unix-Dateirechte hin- ausgehen. So lassen sich etwa Administrationsrechte für ein Volume einem Benutzer zuordnen.
Weiterhin können Volumes auf mehrere Server repliziert werden, um die Verfügbarkeit zu erhö- hen, und sie können mit demCoda Backup Script gesichert werden.
Anders als beispielsweise beiNFS [9] oderSamba [4], dem hauptsächlich unter Microsoft Win- dows eingesetzten verteilten Dateisystem, kennt der Anweder bei Coda wie auch bei AFS die Server normalerweise nicht. Der Zugriff erfolgt über eine Domain, die über das Domain Name System (DNS) [vgl.1, S. 233ff] aufgelöst wird. Da zudem auf sämtlicheCoda Dateiserver über das Verzeichnis/coda zugegriffen wird, ist der Zugriff somit für den Anwender vollkommen transpa- rent. Im Fall der eingerichteten Testumgebung war der Zugriff beispielsweise auf ein gemeinsames Verzeichnis immer über/coda/ambient.local/publicmöglich. Dabei spielt es keine Rolle, ob der Client mit den Server verbunden ist oder nicht. Es ist ebenso unwichtig, auf welchem Volume die Dateien liegen oder ob es ein repliziertes Volume ist. Der Zugriff auf die Dateien erfolgt immer über diesen Pfad.
Um einen Zugriff ohne Verbindung zum Server zu ermöglichen, verwendetCoda einen lokalen LRU-Cache1 (Least Recently Used), der die am längsten nicht verwendeten Dateien wieder aus dem Cache entfernt. Jede zu öffnende Datei wird grundsätzlich zuerst komplett in den Cache über- tragen, so dass mit dieser Datei gearbeitet werden kann, auch in dem Fall, dass die Verbindung un- terbrochen wird. Änderungen können ebenfalls problemlos geschrieben werden, so dass die Datei immer in einem konsistenten Zustand ist. Um diesen Cache Algorithmus etwas zu umgehen, damit beispielsweise die Dateien des Benutzerverzeichnisses immer im Cache vorhanden sind, können Dateien und Verzeichnisse als „sticky“ (klebrig) markiert werden. Entsprechend markierte Dateien bleiben fortan immer im Cache und werden nicht verdrängt. Der Cache sollte dafür entsprechend groß gewählt werden. Um nicht jede Datei von Hand auswählen und markieren zu müssen, kann diese Eigenschaft auch direkt auf das Benutzerverzeichnis angewendet und rekursiv an alle – auch zukünftigen – Dateien vererbt werden.
1Wikipedia:http://en.wikipedia.org/wiki/Cache_algorithms
3 Coda
3.3 Anforderungen
In diesem Kapitel sollen die Anforderungen anCoda, die sich aus dem Szenario aus Kapitel2(S.6) ergeben, dargestellt werden.
DaCoda ausgewählt wurde, um gerade das Arbeiten ohne Verbindung zum Dateiserver zu er- möglichen, ist dies ein zentraler Punkt, der als erstes untersucht werden soll. Dabei ist besonders entscheidend, wie flexibel und problemlos sich die Benutzung gestaltet. Auch das permanente Vor- halten gewünschter Dateien auf dem Client ist eine wichtige Anforderung, die untersucht werden soll. Diese beiden Anforderungen stellen die Hauptgründe für diese Untersuchungen dar.
Weiterhin sollte untersucht werden, inwieweit sich dieCoda Server in eine zentrale Datensiche- rung integrieren lassen. Dabei sollten sowohl vollständige als auch inkrementelle Backups möglich sein.
Ebenfalls untersucht werden soll die Verwendung replizierter Volumes, um eine höhere Datensi- cherheit zu erhalten, indem die Dateien auf mehreren Servern gespeichert werden.
4 Projekt
In diesem Kapitel soll der Aufbau der Testumgebung, die Tests und die Bewertung der Ergebnis- se erfolgen. Zuerst wird der Aufbau der Testumgebung erläutert, bevor die Untersuchungen der allgemeinen Funktionalität, der Backup-Integration und der replizierten Volumes folgen. Abschlie- ßend erfolgt eine Bewertung der Ergebnisse.
4.1 Testumgebung
In diesem Kapitel wird die Testumgebung beschrieben, in derCodain Bezug auf die Anforderungen untersuchte wurde.
Zur Installation der Server standen mehrere IBM Blade Server (siehe Anhang A.1 (S. 17)) in einem Blade Center zur Verfügung. Für die Untersuchungen von Coda wurden zwei Blade Ser- ver und als Client einApple MacBook1 verwendet. Das gesamte Equipment wurde von derHAW Hamburg zur Verfügung gestellt.
Die Server wurden mitDebian GNU/Linux 4.0r12und der Client mitUbuntu 7.103betrieben. Die Wahl fiel auf Debian GNU/Linux, da es sehr ausgereift ist und die Coda Entwickler Installations- pakete fürDebian GNU/Linux zur Verfügung stellen.Ubuntu ist eine eigenständige Distribution4, hat aber viele Eigenschaften von Debian GNU/Linux übernommen. Diese Ähnlichkeit erlaubt es, die Installationspakete derCoda Entwickler auch unterUbuntu einzusetzen.
Da die Blade Server 64-Bit CPUs enthalten, wurde zuerst eine 64-Bit Version von Debian GNU/Linux installiert. Die Ubuntu Installation auf dem Client war dagegen eine 32-Bit Version und dieCoda Installationspakete liegen nur als 32-Bit Version vor. In dieser Kombination kam es jedoch zu Kommunikationsproblemen, so dass auf denBlade Servern schließlich auch eine 32-Bit Version vonDebian GNU/Linux installiert wurde.
Anfangs bestand die Testumgebung aus einem Server, der Systems Control Machine (SCM), und dem Client. Es muss genau eine SCM existieren, da auf dieser Änderungen an den Coda Datenbanken vorgenommen und diese dann an die anderen Coda Server repliziert werden. Der erste installierte Server übernimmt zwangsweise die Rolle derSCM.
1http://www.apple.com/macbook/
2http://www.debian.org/
3http://www.ubuntu.com/
4http://www.ubuntu.com/community/ubuntustory/debian
4 Projekt
Um sinnvoll testen zu können, wurden drei Benutzer angelegt, einer mit Administrationsrechten und zwei ohne besondere Rechte, die als Beispielnutzer dienen sollen. Dabei handelt es sich um spezielleCoda Benutzer, die nichts mit den Systembenutzern auf dem jeweiligen System (Server beziehungsweise Client) gemeinsam haben. Diese Benutzer dienen ausschließlich der Anmeldung und der Benutzung vonCoda. Für die Anmeldung amCoda Server wird ein spezielles Programm (clog) verwendet. Nach erfolgreicher Anmeldung erhält der Client einen Token, der eine gewisse Zeit gültig ist, und den Benutzer gegenüber dem Server authentifiziert. Damit ist die Anmeldung Kerberos [vgl.1, S. 530ff, 694ff] sehr ähnlich.
Für die Beispielnutzer wurde ein Benutzerverzeichnis angelegt, auf das nur der jeweilige Be- nutzer und Administratoren Zugriff besitzen. Weiterhin wurde noch ein öffentliches Verzeichnis angelegt, auf das jeder Benutzer Zugriff hat. Alle drei Verzeichnisse sind als Volumes angelegt worden, um die genannten Berechtigungen setzen zu können.
4.2 Ergebnisse
4.3 Allgemeine Funktionstests
Allgemein war es leider so, dass an diversen Stellen zu merken ist, dass Coda noch in einem experimentellen Stadium ist. Da es sich um ein Dateisystem handelt, ist eine Interaktion mit dem Benutzer besonders schwierig, dennoch wäre ein Tool, dass wichtige Meldungen des Clients benut- zerfreundlich signalisiert, hilfreich. Beispielsweise war anfangs der lokale Cache zu klein gewählt worden. Dies führte dazu, dass die Meldung„permission denied“ beim Kopieren von Dateien auf- tauchte. Es war leider nicht sofort ersichtlich, dass der lokale Cache zu klein war, um alle neuen Dateien aufzunehmen.
Es existieren zwar einige Programme, um den Coda Client zu überwachen. So informiert gcodaconetwa über den Zustand einzelner Volumes, was beim Erkennen von Konflikten hilft. Mit codaconexistiert auch eine text-basierte Variante, die allerdings diverse Meldungen der Kommu- nikation zwischen Client und Server darstellt und aufgrund der Fülle an Informationen eher für Entwickler geeignet scheint.
Weiterhin trat das Problem auf, dass die IP-Adresse eines Server nachträglich geändert werden musste, wodurch eine Re-Initialisierung des Client Caches notwendig war. Dies hatte zur Folge, dass der Cache neu gefüllt werden musste. Diese Problematik war leider nicht direkt ersichtlich, sondern konnte nur mit Hilfe voncodaconerkannt werden, da dort Fehler beim Kontaktieren des einen Servers sichtbar wurden. Es ist leicht unverständlich, dass die Änderung einer IP-Adresse diese Folgen nach sich ziehen, zumal die Zugriffe auf die Server in jedem Fall DNS Anfragen
4 Projekt
Der Zugriff auf Dateien, die sich im Cache befanden war problemlos möglich. Auch das zeitweise Entfernen des Netzwerkkabels, während viele Dateien kopiert wurden, störte den Kopiervorgang nicht. Der Kopiervogang lief ohne Unterbrechung weiter und die Überwachungsprogramme zeig- ten deutlich, dass die Dateien weiter an den Server übermittelt wurden, sobald das Netzwerk wieder verfügbar war.
Application-Specific Resolution [vgl. 5] versucht die Konfliktlösung zu automatisieren, indem eine Art Script definiert wird, das im Falle eines Konflikts abgearbeitet wird und Anweisungen enthält, wie der Konflitk behoben werden kann. Diese Möglichkeit wurde jedoch nicht weiter un- tersucht, da dies die Simulation von Konflikten erfordert hätte und dies war zeitlich leider nicht mehr machbar.
4.3.1 Zentrales Benutzerverzeichnis
Bei allen Tests hatte der Benutzer des Notebooks immer ein lokales Benutzerverzeichnis. Es war leider nicht möglich, in die lokale Anmeldung am Notebook die Anmeldung am Coda Server zu integrieren, damit sich der Anwender nur ein einziges Mal anmelden muss. FürKerberos existiert eine Integration in die lokale Anmeldung, allerdings ließ sich Coda nicht an Kerberos anbinden.
Nach erfolgter lokaler Anmeldung, greifen diverse Programme im Normalfall auf das Benutzer- verzeichnis zu, um Einstellungen zu lesen und die Arbeitsumgebung zu initialisieren. Ohne Au- thentifizierung am Coda Server besteht aber kein Zugriff auf das Benutzerverzeichnis. Je nach verwendeter Umgebung (Text-Konsole oder grafischer Oberfläche) könnte eine Anmeldung nicht einmal erfolgreich sein, so dass der Anwender keine Möglichkeit erhält, sich amCoda Server an- zumelden.
Es besteht die Möglichkeit, sich lokal ohne Netzwerkverbindung anzumelden und auf sein Benut- zerverzeichnis auf demCoda Server zuzugreifen. Sobald die Umgebung initialisiert wäre, könnte der Anwender sich mit Netzwerkverbindung gegenüber demCoda Server authentifizieren. Dieses Vorgehen ist jedoch fehlerträchtig und umständlich und daher nicht akzeptabel.
Daher war es leider nicht möglich, eine wesentliche Anforderung zu erfüllen und das Benutzer- verzeichnis auf dem Coda Server zentral zu verwalten. Um dennoch testen zu können, wurden zwei Benutzerverzeichnisse verwendet, ein lokales und eines auf demCoda Server.
4.3.2 Manuelles Befüllen des Caches
Hoarding bezeichnet das manuelle Befüllen des Caches mit als „sticky“ (klebrig) markierten Da- teien und funktionierte problemlos, so dass auch ohne Netzwerkverbindung ein Zugriff auf diese Dateien möglich war.
Dazu musste zuerst in der Konfiguration des Coda Clients der Hauptbenutzer des Notebooks eingetragen werden, da nur dieser und der Administrator den Cache in dieser Weise beeinflussen
4 Projekt
dürfen. Anschließend müssen die entsprechenden Dateien und Verzeichnisse als „sticky“ in die Hoard Datenbank eingetragen werden. Die entsprechend markierten Dateien und Verzeichnisse können dann manuell in den Cache geladen werden. Um nicht jede Datei in dieseHoard Datenbank eintragen zu müssen, können auch Verzeichnisse rekursiv markiert werden, so dass auch neue Dateien diese Eigenschaft erben (siehe AnhangA.4(S.18)).
4.3.3 Backup
Coda unterstützt Backups, in dem es von jedem Volume eine Art Snapshot anfertigen kann, das heißt, der Zustand des Volumes wird eingefroren und geklont und ist fortan als separates Volume verfügbar. Das ursprüngliche Volume wird dabei nicht verändert. Das neue Volume kann dann in eine Datei gesichert und bei Bedarf wiederhergestellt werden. Allerdings kann das neue Volume auch dem Benutzer zugänglich gemacht werden, damit dieser einzelne Dateien beispielsweise des Vortages kopieren kann. Dieses Volume ist dabei schreibgeschützt und erlaubt somit keinerlei Änderungen.
Um Backups zu ermöglichen, gibt es einige Scripte, die von denCodaEntwicklern zur Verfügung gestellt werden. Diese sind auch als separates Installationspaket verfügbar. Mit Hilfe dieser Tools kann ein eigener Server eingerichtet werden, der von jedem Volume ein Backup anlegt. Jedes Volume muss dazu in eine separate Datenbank eingetragen werden und für jeden Tag der Woche die Information erhalten, ob ein inkrementelles oder ein vollständiges Backup erstellt werden soll.
Diese Information wird dann von den Scripten ausgewertet und der Snapshot erstellt und in eine Datei geschrieben.
Leider ließ sich das Backup nicht testen, da die auf einem separatenBlade Server installierten Backup Tools die für das Backup markierten Volumes nicht klonen und anschließend sichern konn- te. Es gibt eine Korrektur für den Quelltext, die das beheben soll und auch eingespielt wurde. Dies führte jedoch nicht zum gewünschten Ergebnis, so dass es nicht möglich war, diese Anforderung zu erfüllen und mit Hilfe der vonCoda zur Verfügung gestellten Mittel ein Backup zu erstellen.
4.3.4 Replizierte Volumes
Replizierte Volumes dienen dazu, Dateien auf mehrere Server zu verteilen, um eine bessere Last- verteilung zu erreichen, die Datensicherheit zu erhöhen und um gegebenenfalls die Latenzzeiten zu reduzieren, indem Server weit verteilt und somit näher an den Clients aufgestellt werden.
In diesem Fall sollte ein bereits bestehendes Volume auf einen anderen Server repliziert werden.
Dazu ist es notwendig, ein neues nicht repliziertes Volume auf dem anderen Server anzulegen, die Volume Kennung manuell in die Volume Datenbank auf derSCM einzutragen und anschließend von
4 Projekt
Leider traten Probleme beim letzten Schritt auf. Es wurde leider keine einzige Datei auf das neue Volume repliziert und Fehler ließen sich ebenfalls nicht in den Log-Dateien finden.
Es ließ sich jedoch problemlos ein neues Volume auf mehreren Servern anlegen. Alle fortan auf dieses Volume geschriebenen Dateien wurden auf beide Server gleichzeitig geschrieben.
Der erste Fall, das dynamische Hinzufügen eines neuen Volumes, um ein vorhandenes zu repli- zieren, ist der sicherlich in der Praxis interessantere Fall, da Dateiserver in der Regel erweitert werden und die Anzahl der Server nicht von Anfang an feststeht. Dennoch ist es so möglich von An- fang an, alle oder sehr wichtige Volumes auf mehrere Server zu verteilen, um die Datensicherheit zu erhöhen.
5 Fazit
Zusammenfassend lässt sich feststellen, dassCoda einen durchaus stabilen Eindruck macht, wenn man einzelne kleine Stolpersteine beachtet.
Der Zugriff auf Dateien im Cache – trotz fehlender oder instabiler Netzwerkverbindung – funk- tionierte problemlos und machte einen sehr stabilen Eindruck, ebenso wie der Einsatz eines repli- zierten Volumes, sofern dieses entsprechend angelegt wurde.
Leider war es nicht möglich, dass Benutzerverzeichnis des Anwenders auf dem Coda Server abzulegen. So bleibt aktuell nur die Möglichkeit, zwei Benutzerverzeichnisse zu verwenden, und seine Dokumente entsprechend auf dem Coda Server abzulegen, während die Einstellungen in dem lokalen Benutzerverzeichnis abgelegt werden. Dies ist möglicherweise ungewohnt, aber in jedem Fall praktischer als die manuelle Synchronisation der Dateien.
Die separate Benutzerverwaltung dürfte gerade bei vielen Benutzern auch ein Problem darstel- len, da immer ein Abgleich der Benutzer notwendig ist. Eine Anbindung an Kerberos etwa wäre praktisch, da dann die Pflege einer Benutzer-Datenbank ausreichend wäre.
Insbesondere das nicht funktionierende Backup ist ein Problem, da so manuelle Lösungen ge- sucht werden müssen, die nicht die Möglichkeiten des Systems ausschöpfen.
Wenn man Coda nur dazu einsetzt, gewisse Dateien möglichst einfach und mit relativ wenig Aufwand zu replizieren, dann ist Coda durchaus eine gute Wahl. Am besten funktioniert der Cli- ent unter Linux, was für einige Anwender sicherlich eine starke Einschränkung darstellt. Zudem bietet es eine einfache Möglichkeit, zentral Dateien zur Verfügung zu stellen, verbunden mit der Eigenschaft, dass jeder Client sehr einfach auf die jeweils aktuellste Version Zugriff hat.
Literaturverzeichnis
[1] Andrew S. Tanenbaum und Marten van Steen. Verteilte Systeme. Pearson Studium, 2003.
ISBN 3-8273-7057-4. URLhttp://www.cs.vu.nl/~ast/books/ds1/. [letzter Zugriff: 27. Ju- li 2007].
[2] Peter J. Braam. The Coda Distributed File System, 1998. URL http://www.coda.
cs.cmu.edu/ljpaper/lj.html. PDF: http://www.cs.cmu.edu/afs/cs/project/coda-www/
ResearchWebPages/docdir/lj98.pdf[letzter Zugriff: 27. Juli 2007].
[3] Carnegie Mellon University und IBM Pittsburgh Labs. AFS. URLhttp://www.cs.cmu.edu/
afs/andrew.cmu.edu/usr/shadow/www/afs.html. [letzter Zugriff: 27. Juli 2007].
[4] IBM, Microsoft, und Samba Team. Server Message Block. URLhttp://de.wikipedia.org/
wiki/Server_Message_Block. [letzter Zugriff: 27. Juli 2007].
[5] Kumar, P. und Satyanarayanan, M. Supporting application-specific resolution in an optimisti- cally replicated file system. InProceedings of the Fourth IEEE Workshop on Workstation Ope- rating Systems, pages 66–70, October 1993. URLhttp://www.cs.cmu.edu/afs/cs/project/
coda-www/ResearchWebPages/docdir/wwos4.pdf. [letzter Zugriff: 22. Februar 2008].
[6] M. Satyanarayanan und Carnegie Mellon University Students. Coda. URLhttp://www.coda.
cs.cmu.edu/. [letzter Zugriff: 27. Juli 2007].
[7] M Satyanarayanan. Coda: A highly available file system for a distributed workstation envi- ronment. Technical report, 1989. URLhttp://www.cs.cmu.edu/afs/cs/project/coda-www/
ResearchWebPages/docdir/wwos2.pdf. [letzter Zugriff: 27. Juli 2007].
[8] Satyanarayanan, M., Kistler, J.J., Mummert, L.B., Ebling, M.R., Kumar, P., und Lu, Q. Ex- perience with disconnected operation in a mobile computing environment. In Procee- dings of the USENIX Symposium on Mobile and Location-Independent Computing, Ju- ne 1993. URL http://www.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/
docdir/mobile93.pdf. [letzter Zugriff: 16. Februar 2008].
[9] Sun Microsystems. Network File System. URL http://de.wikipedia.org/wiki/Network_
File_System. [letzter Zugriff: 27. Juli 2007].
[10] unison Development Team. unison. URL http://www.cis.upenn.edu/~bcpierce/unison/.
[letzter Zugriff: 27. Juli 2007].
A Anhang
Der Anhang dient dazu weitere Erfahrungen und Probleme, die während der Untersuchung von Coda auftraten, zu dokumentieren.
A.1 Installation von Debian GNU/Linux
Die Installation vonDebian GNU/Linux funktionierte problemlos auf dem hier verwendeten Blade Server (HS21)1. Allerdings werden die Festplatten während der Installation in anderer Reihenfolge erkannt als dies später im Betrieb der Fall ist. Während der Installation tauchte die Festplatte als /dev/sdb auf während sie im Betrieb als /dev/sda verwendet wird. Dies führt dazu, dass der BootloaderGRUB und die/etc/fstabfalsche Einträge enthalten.
In der /etc/fstab müssen dabei nach der Installation, aber vor dem Neustart, alle Vorkom- men von /dev/sdb durch /dev/sda ersetzt werden. Dies kann auf einer zweiten Konsole ge- schehen. Das installierte System ist unter /target gemountet, dass heißt aus /etc/fstab wird /target/etc/fstab.
Für GRUB muss die Datei /boot/menu.lst angepasst werden und dort root=/dev/sdb? durch root=/dev/sda??ersetzt werden, wobei??die entsprechende Partition bezeichnet.
A.2 Installation von Coda
Die Installation desCoda Server gestaltet sich recht einfach, wenn man dieDebianPakete verwen- det. Diese finden sich auf derCoda Webseite2. Danach muss das Programmvice-setup ausgeführt werden, dass den Server konfiguriert.
Die Konfigurationsdateien des Servers werden unter/viceabgelegt, die Benutzerdateien in der Regel unter/vicepa.
Nachdem das Skriptvice-setupausgeführt wurde, ist der Server eigentlich schon betriebsbe- reit. Wichtig ist, dass es nureine einzigeSystems Control Machine (SCM) gibt.
A Anhang
A.3 DNS Anpassungen
Um über die Domain auf dieCoda Server zuzugreifen, muss einDomain Name Server (DNS) betrie- ben werden. Dazu sind zweiSRVEinträge notwendig, die zum einen den Zugriff auf den Dateiserver selber und zum anderen den Zugriff auf den Authentifizierungsdaemon ermöglichen.
1 blade01 . ambient . l o c a l . A 192.168.14.10
2 _codasrv . _udp . ambient . l o c a l . SRV 0 0 2432 blade01 . ambient . l o c a l .
3 _codaauth2 . _udp . ambient . l o c a l . SRV 0 0 370 blade01 . ambient . l o c a l . Listing A.1:DNS Auszüge für denCoda Server
Dies ermöglicht den Zugriff auf dieCoda Server über den Namensraum/coda/ambient.local.
A.4 Hoarding des Benutzerverzeichnisses
Das Befüllen der Hoard Datenbank für das Verzeichnis /coda/ambient.local/users/sven funk- tioniert mit folgenden Befehlen.
1 $ hoard add / coda / ambient . l o c a l / users / sven 1000:d+
2 $ hoard walk
Listing A.2:hoard-Befehl
In Zeile 1 wird zunächst mit höchster Priorität das Benutzerverzeichnis in dieHoard Datenbank eingetragen, dabei werden alle aktuellen und alle zukünftigen Dateien ebenfalls als „sticky“ mar- kiert und dauerhaft im Cache vorgehalten. Die Zeile2kopiert explizit die entsprechend markierten Dateien in den Cache, andernfalls würden diese nur nach und nach – sobald auf eine Datei zuge- griffen wurde – in den Cache kopiert werden.
Diese Befehle müssen entweder als der in der/etc/coda/venus.confangegebeneprimaryuser oder als root ausgeführt werden. Andere Benutzer haben in der Regel keinen Zugriff auf die Hoard Datenbank. Loggt man sich an einer lokalen Textkonsole an, so kann es sein, dass Coda diesen Benutzer alsprimaryuserannimmt.
