CODA-horten und verteilen

Netzwerkdateisysteme sind nichts neues - in großen Netzen geht bei all den Shares und Netzlaufwerken allerdings schnell der Durchblick verloren. Und die Zeit für das ewige Kopieren von Dateien zwischen Laptop und Server könnte sinnvoller genutzt werden. Was tun?

Eine alte Weisheit (nein, nicht Konfuzius) besagt: Festplatten können nicht groß genug sein. Zwar gibt es einen Trend zur Rezentralisierung- der Mainframe bleibt im Rechenzentrum, bekommt aber von mehreren Midrange-Servern Gesellschaft, die sich die Aufgaben teilen, und auf die jeder von (fast) überall zugreifen will. Dies gilt auch für das "Fußvolk" mit betagtem Laptop oder aktuellem Handheld. Und wenn dann auch noch der Abgleich zwischen Fileserver und Client zum größten Teil automatisch abläuft...

mobile computing

Die Entwicklung begann bereits 1987 als Abkömmling von AFS-2 und wurde von Firmen wie IBM, Defense Advanced Projects Agency, Digital Equipment, Sun, Bellcore und Intel unterstützt. Bei CODA bilden sämtliche Volumes einen einheitlichen Namensraum. Dieser wird auf Unix-Clients unter /coda montiert - die Windows-Clients verbinden ein Netzlaufwerk dauerhaft. Die Lage der Volumes ist für den Benutzer nicht ersichtlich. Volumes bilden in mehrerer Hinsicht die kleinste zu verwaltende Einheit:

• die einzelnen Volumes werden zu einem hierarchischen Baum verknüpft,
• ein Backup erfolgt auf Ebene der Volumes und
• Zugriffsrechte und Quotas (Limitierung der Kapazität auf Benutzerebene) können pro Volume vergeben werden.

Volumes werden auf den Fileservern in eigenen Partitionen angelegt. Für Konsistenzprüfungen kommt CODA mit salvage und einem modifizierten fsck -Kommando daher. Der Verwaltungsaufwand zur Einrichtung der Server ist recht hoch und muß noch händisch geschehen. Es ist aber zu erwarten, daß bald Werkzeuge geschaffen werden, die einem das Anlegen der Konfigurationsdateien abnehmen. Zuerst wird die SCM (system control machine) eingerichtet. Hierzu gehören

• die Vergabe eines Server-Namens und einer ID
• Anlegen eines root-Volumes mit createvol_rep <v.name> <VSG> /vicepa
• Erzeugen nicht replizierter Volumes mit createvol <v.name> <server> <device>
• Starten des Servers mit codastart
• das Anlegen von Benutzern und Gruppen mittels pdbtool.

Die Administratorin kann zwischen vier Arten von Volumes wählen, deren Eigenschaften in Tabelle 1 wiedergegeben werden. Zu beachten ist, daß Heimatverzeichnisse von Benutzern nur sinnvoll read/write-repliziert werden sollten, damit der Anwender sich von beliebiger Stelle ohne Performanzverlust anmelden kann. Hauptnachteile der read/write-Replikate sind der Protokollmehraufwand und die potentiellen Konflikte. Ein Konflikt tritt auf, wenn in einer disconnected-Phase, z.B. bei Netzausfall, eine Datei auf zwei Replikas verändert wird. Nach Wiederherstellung der Netzwerkverbindung stellt CODA diesen Konflikt fest, gibt entsprechende Meldungen aus und entfernt alle betroffenen Dateien aus dem Namensraum. An die Stelle des Verzeichnis wird ein symbolischer Link auf die fid angelegt. Während dieser Phase ist kein Zugriff möglich. Mit dem repair Programm kann der Konflikt manuell aufgelöst werden. Der Einsatz von read/write-Replikas sollte also wohlüberlegt sein, um die Anzahl manuell aufzulösender Konflikte gering zu halten. Volumes mit sich selten ändernden Daten, wie z.B. Programmdateien, sollten read-only repliziert werden.

RVM wacht über Filesystem-Änderungen

Für die Metadaten (entsprechen etwa der inode-table+sämtlicher Verzeichnisse) benötigt CODA ca. 5% des Volumens der Nutzdaten; bei 2GB ungefähr 90MB. Für die Protokollierung von Änderungen (logging) am Dateisystem werden ca. 2 MB empfohlen, da die Häufigkeit der Kürzung und die Größe Einfluß auf die Performanz haben. Für die Log- und Metadaten sollten keine Unixdateien verwendet werden, obwohl dies möglich ist. Mit rvmutl wird das Log, mit rdsinit das Datensegment für RVM angelegt. Hier ist vor allem bei der Wahl der Größe Vorsicht geboten.

server not responding - still trying...

Um gegen Netzwerkausfälle immun zu sein, bedarf es der lokalen Speicherung der Dateien in einem dafür vorgesehenen Cache-Bereich. Das clientseitige Pendant zum RVM ist die client modification list (CML). Im Falle eines Server- oder Netzwerkausfalles protokolliert der CODA-Client im CML sämtliche lokale Änderungen im Cache, die nicht an den Server übertragen werden können. Kann die Verbindung zum Server wieder hergestellt werden, gleichen Client und Server die Änderungen ab. Hierbei kann es zu den weiter oben beschriebenen Konflikten bei read/write-replizierten Volumes kommen.

Damit die Reise und die Vorstellung beim Kunden nicht zur Lotterie mutiert, kann der Benutzer über einen hoarding genannten Mechanismus bestimmen, welche Dateien er unbedingt lokal vorhalten möchte. Über die hoardfiles, in alter Unix-Tradition plain ASCII, kann den Dateien eine Priorität vergeben werden, um das Entfernen bei gefülltem Cache zu vermeiden. Hierbei werkelt die Synchronisation weiterhin im Hintergrund.

alles im Griff

• lookup
• read
• write
• insert
• delete
• administer.

Die allgemeine Architektur von CODA zeigt Abbildung 1. Bis auf einen minimalen Dateisystemtreiber sind die Bestandteile im User-Level angeordnet. Dies bringt den Vorteil einer leichteren Portierbarkeit. Um den Mehraufwand für den ständigen Wechsel zwischen User- und Kernellevel zu vermeiden, wurde ein Minicache getauftes System entwickelt. Die Kommunikation zwischen Venus und dem Kernel findet über eine spezielle Gerätedatei /dev/cfs0 statt.

Der RPC-Mechanismus wurde quasi um multicasting-Fähigkeiten erweitert, um die Änderungen an einem Replikat auf sämtlichen beteiligten Servern vorzunehmen. Wenn die angesprochene Datei allerdings bereits vom Cache-Manager auf der lokalen Festplatte gespeichert und gültig ist, erfolgt der Abruf nicht von einem der möglichen Dateiserver, sondern wird wiederum über das VFS des Kernels (gestrichelte Schritte 4 und 5) aufgelöst.

Aussicht

Durch die freie Verfügbarkeit des Quellcodes ist zu erwarten, daß sich CODA schnell stabilisieren und weitere Plattformen unterstützen wird. Mit der Adressierung des mobile computing und der Fehlertoleranz gegen Netzwerkausfälle zeigt es sich konkurrenzlos. Gelingt es, stabile Unterstützung für Windows-Clients herzustellen, steht einer allgemeinen Verwendung nichts im Wege - Akzeptanz in den Köpfen der Entscheider vorausgesetzt. Die Familie der AFS-basierten Dateisysteme, also DCE/DFS und CODA bieten doch wesentlich bessere Konzepte für Skalierbarkeit und Verwaltung von Plattenspeicher als das Meta-Dateienverzeichnis von Microsoft. Vor einer allgemeinen Akzeptanz von CODA müssen neben Linux, FreeBSD, NetBSD und Windows NT auch die klassischen Unices wie Solaris, AIX und HP/UX Unterstützung finden. Die Authentifizierungsmethoden sollten in die Betriebssysteme integriert werden und die Verwaltung der Server und der hoard-files muß verbessert werden.
 
  Weitere Teile:

• Installation
• Überblick diverser Netzdateisysteme