LUGS - Vorträge: Coda vom 11.3.1999
LUGS Über die LUGS Statuten und Protokolle Sektionen Terminliste IRC Mailinglisten Kontaktadressen Mitglied werden Internes Mitgliederliste LINUX Was ist Linux?    Screenshots Distributionen    kmLinux Firmen Ressourcen LIB Dokumentation Events Projekte Vorträge Allgemeines ChangeLog Sprache Galerie	Am 11. März 1999 hat Beat Rubischon einen Vortrag über Coda gehalten. Ich schreibe hier eine kurze Zusammenfassung darüber. Weder war der Vortrag eine Konfigurations- oder Installationsanleitung, noch soll dieser Artikel das nachholen. Ich will einfach einen kleinen Überblick über die Funktionalität, die Vor- und Nachteile von Coda geben. Idee und Herkunft Coda kommt ursprünglich aus der Welt der Gross-Systeme von IBM und ist dort aus dem AFS (Andrew File System) entstanden. Das merkt man dem System auch an verschiedenen Stellen an. Alles Wissenswerte über Coda (HOWTO, Installationsanleitung et al.) ist von der Coda-Homepage erhältlich. Die Idee bei Coda ist, dass nicht nur ein Server die Daten zur Verfügung stellt, sondern ein ganzes Rudel von Servern. Der Client kann dann auswählen, welchen Server er benutzen möchte. Als Kriterium werden da zum Beispiel die Erreichbarkeit oder die Antwortzeit herangezogen. Die Server stehen dabei untereinander auch in Verbindung und sorgen für einen ständigen Abgleich der Daten, sodass auf allen Servern die aktuellen Daten vorhanden sind. Die Verbindungen zwischen den Servern und den Clients müssen nicht dauernd vorhanden sein, das System funktioniert trotzdem. Dazu hat jeder Client einen eigenen Cache auf seiner lokalen Festplatte. Aufbau auf Server-Seite Die Daten, die auf dem Coda-Server liegen, werden unter /vicepa gespeichert. Und zwar nicht so wie bei NFS als normale Files und Verzeichnisse, sondern eher wie bei Squid in einer eigenen Verzeichnis-Struktur. Dazu gehört natürlich noch die Datenbank RVM (Recoverable Virtual Memory) mit den Informationen, welches File wo in der Verzeichnis-Struktur unter /vicepa zu finden ist. Die Grösse des RVM muss 4% des gesamten Platzes des Coda-Servers betragen und das RVM wird dann in den Speicher gemapt. Das heisst für viel Platz auf dem Server braucht es auch viel Platz im Hauptspeicher (am besten physikalisch). Zusätzlich dazu gibt es noch ein Journal, in dem alle Vorgänge in Coda aufgezeichnet werden. Dadurch wird das ganze System bei Abstürzen viel weniger beschädigt (meist sogar gar nicht). Auf dem Server läuft der codasrv-Prozess, der die Kommunikation mit den Clients erledigt. Er ist zuständig für den Daten-Versand und die Authentifikation der User auf den Clients. Diese müssen sich sowohl auf Ihrer Workstation als auch beim Coda-Server anmelden. So eine Anmeldung bleibt 24 Stunden gültig. An den Authentifikations-Daten darf übrigens nur ein Server (System Controll Machine SCM) Änderungen vornehmen. Wie schon erwähnt, können mehrere Coda-Server die gleichen Daten haben und den Clients anbieten. Das muss aber nichts so sein. Es können auch verschiedene Coda-Server verschiedene Daten verwalten und anbieten. Für einen Client ist es dann egal, zu welchem Server er Verbindung aufnimmt, er sieht immer alle zugänglichen Daten in des "`Server-Clusters"'. In der Terminologie von Coda: die Server einer Zelle verwalten Volumes, die dann in das /coda-Verzeichnis gemountet werden. Jeder Server muss auch das Root-Volume verwalten. Ein kleines Beispiel: Server A Server B Server C root root root home home stuff home und stuff sind also nicht auf allen Servern vorhanden. Der Client sieht allerdings in seinem /coda-Verzeichnis folgendes Bild. Client root home stuff Und das unabhängig vom Server, zu welchem er Verbindung aufgenommen hat. Aufbau auf Client-Seite Auf dem Client läuft der venus-Prozess, der die Schnittstelle zwischen Cache, Server und dem Coda-Modul im Kernel bildet. Dieses Modul ist seit 2.1.x im Kernel dabei. Es sorgt für die Verbindung zwischen dem Verzeichnis /coda auf den Clients und dem venus-Prozess. Wenn man Verbindung zu einem Coda-Server aufnimmt, dann kann man dessen Verzeichnisse nicht wie bei NFS an beliebige Stellen mounten, sondern sie erscheinen unter /coda. Der Cache besteht aus einer Datei, deren Grösse festgelegt werden kann. Die Verbindung zum Server und die Verbindung unter den Server basiert auf UDP und ist also "`verbindungslos"' (so wie bei NFS -- im Gegensatz zu TCP zum Beispiel bei Telnet). Vor- und Nachteile Zuerst die Vorteile: Es können mehrere Server existieren, das verteilt die Last und erhöht die Ausfallsicherheit. Die Clients können dank des Caches auch offline arbeiten (praktisch für tragbare Computer). Die Berechtigungen können in Coda sehr viel feiner als in einem normalen Unix-System vergeben werden. Der jeweilige User sieht dann einfach nur das, was er darf. Das Journal sorgt für einen problemlosen Neustart bei einem Absturz. Dann die Nachteile: Der Platzbedarf im Hauptspeicher steigt linear mit dem zur Verfügung gestellten Plattenplatz: 4%. Das heisst mit 1 GB RAM kann man höchstens 25 GB Plattenplatz mit Coda verwalten. Denn es macht wenig Sinn, das RVM im virtuellen Speicher zu halten. Auch der Rest von Coda ist nicht für den Heimanwender gerechnet: Coda beinhaltet einen eigenen Portmapper und eigenes Threading. Beat hat für 512 MB Plattenplatz 20 MB für das RVM benötigt und Coda verbrauchte nach dem Start etwa 30 MB RAM. Das Erstellen von vielen Files ist sehr langsam (ungefähr Faktor fünf bis zehn beim Auspacken der Kernel-Sourcen), wenn das Journal, das RVM und /vicepa auf dem Server auf der gleichen Platte liegen. Die Anmeldung bleibt 24 Stunden gültig. Faule Leute sagen, das sei ein Job für Cron. Damit wird natürlich die Idee des Passwort-Schutzes untergraben. Wenn eine Verbindung ausfällt (gewollt mit dem Laptop oder ungewollt bei einem Ausfall des Netzwerks) und in beiden enstehenden Teilen von Coda Änderungen an der gleichen Datei gemacht werden, dann entstehen Konflikte, die ein Administrator von Hand lösen muss. Zusammenfassung des Vortrags durch Philipp Frauenfelder