Evaluierung von AFS/OpenAFS als Clusterdateisystem

Transkript

1 Evaluierung von AFS/OpenAFS als Clusterdateisystem Sebastian Heidl Juli 2001 Zusammenfassung Im Rahmen des Seminars Management von Linux Clustern wurde die Eignung von AFS bzw. OpenAFS (siehe Abschnitt 1) als Clusterdateisystem untersucht. Dabei sind verschiedene clusterrelevante Eigenschaften eines Dateisystems evaluiert und eine Testinstallation durchgeführt worden. Die geplanten Performance-Messungen konnten leider aufgrund von Stabilitätsproblemen im Testcluster nicht durchgeführt werden. 1 AFS/OpenAFS Die Abkürzung AFS steht ursprünglich für Andrew File System. Das AFS wurde Ende der 80 er Jahre an der Carnegie Mellon University im Rahmen des Forschungsprojekts Andrew entwickelt. Das Ziel des Projekts war eine einheitliche Plattform für verschiedenste Netzwerkdienste zur Verfügung zu stellen und den Nutzern eine einheitliche Sicht auf das System (single system image), unabhängig von ihrem aktuellen Arbeitsplatz, zu gewähren. Im Zuge der Entwicklung von Andrew wurde 1989 die Transarc Corp. 1 gegründet, um AFS weiterzuentwickeln und als Produkt zu vermarkten. Kurz darauf wurde Transarc von IBM übernommen und ist jetzt auch unter dem Namen IBM Pittsburgh Lab 2 im Internet zu finden. Dessen ungeachtet wurde AFS weiterentwickelt und ist inzwischen in der Version 3.6 erhältlich. Im September 2000 veröffentlichte IBM den aktuellen Quelltext der damaligen AFS Version und das OpenAFS Projekt 3 entstand. Die aktuelle OpenAFS Version trägt die Nummer und ist auf diversen UNIX Plattformen lauffähig. Es existieren auch Clients für einige Microsoft Windows Versionen und für MacOS. Wenn in den folgenden Abschnitten von AFS die Rede ist, so gelten die Aussagen auch für Open- AFS, da sich beide Varianten (soweit das festgestellt werden konnte) hinsichtlich des Funktionsumfangs nicht wesentlich voneinander unterscheiden. Da allerdings nur die Open-Source Version Open- AFS untersucht wurde, konnte dies nicht überprüft werden. 2 AFS Überblick AFS ist ein Dateisystem, das eine klare Trennung von Client (greift auf die Daten zu) und Server (stellt die Daten zur Verfügung) vornimmt. Allerdings läßt sich ein Rechner, der als Server fungiert zusätzlich als Client konfigurieren, damit Nutzer, die auf diesem Rechner angemeldet sind, auch auf die Daten zugreifen können. client Cell A client server server server client client Cell C Cell B client server Abbildung 1: Überblick über die Struktur des AFS Systems 1

2 Wie in Abbildung 1 dargestellt wird der AFS-Space in sogenannte Zellen eingeteilt. Eine Zelle wird als lokale Ansammlung von Rechnern betrachtet, beispielsweise die Rechner einer Filiale einer Firma oder allgemein eines LANs. Außerdem läßt sich erkennen, daß mehrere Server sich die Arbeit in einer Zelle teilen können und daß Clients auch Zugang zu mehreren Zellen haben können. Auf diese Art und Weise ist es möglich, auch weit voneinander entfernte Zellen miteinander zu verbinden. Zu den Hauptmerkmalen von AFS zählen: 1. Es ist geeignet und konzipiert für die Verwendung in LANs und WANs. 2. Es implementiert ein ausgefeiltes Authentisierungs- und Zugriffsschutzsystem (siehe Abschnitt 4) durch die Verwendung von Kerberos 4 und Access Control Lists (ACLs). 3. Es präsentiert allen Nutzern die gleiche Sicht auf das System (single system image). 4. Durch die Verwendung von Caches soll die Zugriffszeit auf die Daten und die erzeugte Netzlast verringert werden. 5. Die Daten können auf mehrere Server repliziert werden, so daß der Ausfall einer Servermaschine für die Clients transparent bleibt. In den folgenden Kapiteln sollen einige Aspekte der Funktionsweise von AFS untersucht werden. Dabei konnten nicht alle möglichen Konfigurationsoptionen berücksichtigt werden, da es sich um ein komplexes System mit einem weit gefächerten Anwendungsspektrum handelt. 3 Benutzung Dem Nutzer präsentiert sich AFS in einer einfachen Art und Weise. Alle Daten, auf die er Zugriff hat, sind (unter UNIX) im Pfad beginnend mit /afs abgelegt. Es ist auch durchaus üblich, die Heimatverzeichnisse der Benutzer unter /afs abzulegen, d.h. der Nutzer befindet sich nach dem Anmelden bereits im AFS-Verzeichnisbaum. In der nächsten Verzeichnisebene (unter /afs) werden nach Konvention die zur Verfügung stehenden 4 Zellen (sowohl lokale als auch entfernte) unter ihren Namen gemountet. Für die Namen der Zellen wiederum besteht die Konvention, einen Teil des Domainnamens, also beispielsweise zib.de, zu verwenden. Somit ist es den Nutzern möglich zuzuordnen, in welcher Zelle die Daten auf die sie gerade zugreifen, lokalisiert sind. Allerdings ist der tatsächliche Speicherort (der Server) für die Nutzer normalerweise nicht sichtbar. Die Authentisierung des Nutzers erfolgt üblicherweise schon bei der Anmeldung am UNIX-System. Hier wird vom Cache Manager (siehe Abschnitt 6) ein Token für den Benutzer abgespeichert, das für die Authentisierung des Nutzers gegenüber den Servern dient (siehe 4.1). Danach wird AFS, wie jedes andere Dateisystem, über die normalen Kommandos und Systemaufrufe bedient. Unterschiede in der Benutzung ergeben sich nur, wenn die Zugriffsrechte einer Datei oder eines Verzeichnisses bearbeitet bzw. untersucht werden sollen. Die normalen UNIX-Zugriffsrechte existieren weiterhin, allerdings in einer abgewandelten Interpretation. Zur Manipulation oder zum Anzeigen der Access Control List (ACL) eines Verzeichnisses sind spezielle Kommandos erforderlich. 4 Zugriffsschutz und Authentisierung Wie bereits erwähnt, erfolgt die Authentisierung der Nutzer bei AFS durch das Kerberos Protokoll. Da dieses Protokoll ebenfalls sehr komplex ist, kann hier nur ein grober Überblick gegeben werden. Für eine detaillierte Einführung sei der Leser auf [9] und [10], sowie auf [8] verwiesen. 4.1 Kerberos Das Kerberos Authentisierungssystem wurde und wird am Massachusetts Institute of Technology (MIT) entwickelt und dient der gegenseitigen Authentisierung von Clients und Services in einem als unsicher betrachteten Netzwerk. Es soll also sowohl die Identität des Clients, als auch die Identität des Services bestätigt werden. Weitere Anforderungen an das System sind: Der Nutzer soll sich nur einmal am System anmelden und dann alle Dienste, für die er die 2

3 Berechtigung hat, benutzen können, ohne sich erneut authentisieren zu müssen. Authentisierungsinformationen sollen nicht ungeschützt über das Netzwerk übertragen werden. Diese Ansprüche werden durch ein mehrstufiges Ticketsystem realisiert. Jeder Nutzer und jeder Service besitzt einen privaten Authentisierungsschlüssel. Diesen Schlüssel kennt nur der Benutzer beziehungsweise der Service selbst. Zusätzlich sind die Schlüssel in der Kerberos Datenbank abgelegt. Kerberos Database Ticket Granting Service 2 Key Distribution Center 1 Client 3 4 Print Service File Service Abbildung 2: Überblick über das Kerberos System Um einen bestimmten Service benutzen zu können, muß der Benutzer ein Ticket für diesen Service erwerben, das dem Service anzeigt, daß dieser Nutzer berechtigt ist, diesen Service zu benutzen. Damit sich der Nutzer nicht erneut authentisieren muß, wenn er einen anderen Service benutzen will, existiert ein Ticket Granting Service (TGS), der dem Nutzer entsprechende Service-Tickets ausstellen kann. Die erforderlichen Schritte zum Erwerben eines Service-Tickets sind in Abbildung 2 dargestellt: 1. Der Nutzer schickt eine Anfrage an das Key Distribution Center (KDC), um ein Ticket für den TGS zu erhalten. Zu diesem Zeitpunkt findet die Authentisierung des Nutzers statt. Ist sie erfolgreich, erhält der Nutzer ein Ticket für den Ticket Granting Service (TGS) und einen Session-Key, der für die Verschlüsselung der Kommunikation mit dem TGS dient. 2. Mit dem TGS-Ticket kann der Nutzer nun eine Anfrage an den TGS stellen, um ein Ticket für den Print-Service zu erhalten. Hier muß er sich nicht erneut authentisieren, da er ein Ticket für den TGS besitzt. Der TGS generiert einen neuen Session-Key für die Kommunikation zwischen Nutzer und Print-Service und schickt diesen zusammen mit dem Ticket für den Print-Service zurück. 3. Der Nutzer kann den Print-Service in Anspruch nehmen, da er für die Anfragen sein Print-Service-Ticket benutzen kann. 4. Soll noch ein weiterer Service genutzt werden, so ist erneut eine Anfrage an den TGS zu richten, der dann einen neuen Session-Key und ein entsprechendes Ticket ausstellen wird. Es sei noch einmal darauf hingewiesen, daß hier nur eine sehr knappe Einführung in das Kerberos Authentisierungssystem gegeben werden konnte, da es nicht Gegenstand der Untersuchungen war. 4.2 Access Control Lists (ACLs) Wie schon im vorigen Abschnitt beschrieben, bringt AFS sein eigenes Authentisierungssystem mit. Als Teil dieses Systems erhält jeder Nutzer eine AFS-User-ID, die normalerweise den gleichen Wert, wie die normale UNIX-UID enthält, damit die Anzeige des Besitzers einer Datei sinnvolle Angaben enthält. Als weiteren Teil der Nutzerverwaltung existieren in AFS auch Gruppen von Nutzern, die allerdings nicht nur AFS-UIDs, sondern auch IP-Adressen enthalten können. Somit kann der Zugriff auf bestimmte Teile des AFS-Verzeichnisbaumes nur für Anfragen von bestimmten Rechnern freigegeben werden. Nach der Installation des AFS-Systems existieren bereits 3 vordefinierte Gruppen: system:administrators: Die Mitglieder dieser Gruppe haben den Administrator Status und können somit privilegierte Kommandos, z.b. zum Starten und Stoppen von Servern, ausführen. Bei der Installation wird mindestens ein Benutzer angelegt, der Mitglied dieser Gruppe ist. system:authuser: Alle Nutzer, die sich erfolgreich am AFS-System anmelden konnten, sind automatisch in dieser Gruppe enthalten. So kann man bestimmte Dateien und Verzeichnisse nur für AFS-Berechtigte freigeben. 3

4 system:anyuser: Jeder Nutzer, der sich (noch) nicht beim AFS-System angemeldet hat, wird dieser Gruppe zugeordnet. Dateien und Verzeichnisse, die für diese Gruppe zugänglich sind, sind sozusagen public, d.h. für alle Nutzer, die sich an einem Rechner, der als AFS-Client konfiguriert ist, anmelden können, verfügbar. Wie in den vordefinierten Gruppen schon zu erkennen ist, bestehen Guppennamen aus zwei Bestandteilen, die durch einen Doppelpunkt (:) voneinander getrennt werden. Dabei ist der vordere Teil der Name des Nutzers, der die Gruppe angelegt hat und der hintere Teil der eigentliche Name der Gruppe. AFS-Acess-Control-Lists werden ausschließlich für Verzeichnisse vergeben. Der Zugriff auf alle Dateien innerhalb des Verzeichnisses wird durch die ACL des Verzeichnisses gesteuert. Soll eine Datei stärker geschützt oder nicht so restriktiv gehandhabt werden, so muß sie in ein anderes Verzeichnis verschoben werden. Das bringt natürlich auch eine gewisse Umgewöhnung mit sich, da durch das einfache Verschieben von Dateien ihre Zugriffsrechte gravierend geändert werden können. Innerhalb einer ACL können dann für einzelne UIDs oder Gruppen unabhängig voneinander verschiedene Rechte vergeben werden. Die Rechte, die eine ACL gewährt, werden noch einmal in zwei Gruppen, die Verzeichnisrechte und die Dateirechte, unterschieden. Verzeichnisrechte: Die Rechte lookup, insert, delete und administer beziehen sich eher auf Operationen, die das Verzeichnis betreffen. Das lookup Recht ist wohl das grundlegendste von allen. Es berechtigt den Nutzer, das Verzeichnis zu betreten, und sich mit ls die Namen der Dateien und Unterverzeichnisse anzuzeigen. Die Rechte insert und delete ermächtigen den Nutzer, Dateien und Unterverzeichnisse anzulegen bzw. zu löschen. Das administer Recht berechtigt dazu, die ACL des Verzeichnisses zu ändern, also beispielsweise Nutzer hinzuzufügen. Dateirechte: Die Rechte, die sich auf Operationen auf den Dateien des Verzeichnisses beziehen, heißen read, write und lock. Die ersten Beiden sind selbsterklärend. Das lock Recht wird benötigt, um Systemrufe zum Locken von Dateien auszuführen. Zu erwähnen ist noch, daß erst die Kombination aus lookup und read Recht zum Ausführen des Befehls ls -l berechtigt, da das lookup Recht allein das Anzeigen von Dateiinformationen, abgesehen vom Namen, nicht erlaubt. 4.3 Interpretation der UNIX-Zugriffsrechte Alle Dateien und Verzeichnisse tragen auch innerhalb des AFS-Baums die normalen UNIX-Zugriffsrechte. Allerdings werden die UNIX-Mode-Bits für Verzeichnisse ignoriert, da hier die ACLs die Berechtigungen regeln. Für Dateien haben nur die Mode-Bits des Users (owners) eine Bedeutung. Die UNIX read und write Berechtigungen ergänzen sich mit den AFS-Rechten rl (read, lookup) und wl (write, lookup). Ein Nutzer kann eine Datei nur lesen, wenn er gleichzeitig die AFS-Rechte rl und das UNIX-Recht read hat. Für write gilt die gleiche Verknüpfung. Um eine Datei ausführen zu können werden die AFS-Rechte rl und das UNIX-Recht execute benötigt. Eine Besonderheit stellt noch das UNIX-S-Bit dar. Nur Mitglieder der Gruppe system:administrators können das S-Bit von Dateien modifizieren. Auch der Zugriff von SUID-Programmen auf den AFS-Baum ist eingeschränkt: Er kann komplett verboten werden oder, wenn er erlaubt ist, erfolgt er mit der tatsächlichen UID des Nutzers, der das Programm gestartet hat. Das S-Bit hat also nur Einfluß auf den Zugriff außerhalb des AFS-Space. 5 AFS Server In diesem und dem folgenden Abschnitt soll der innere Aufbau und die Funktionsweise des AFS- Systems genauer beschrieben werden. Dazu werden zunächst die verschiedenen Rollen, die ein AFS- Server übernehmen kann, vorgestellt. File Server Machine: Wie die Bezeichnung schon nahelegt, sind AFS-Server, die diese Rolle übernehmen, für die Bereitstellung und das Ablegen der Nutzerdaten zuständig. Es kann natürlich mehrere File Server in einer Zelle geben, die sich die Arbeit teilen, indem Volumes (siehe Abschnitt 5.1.1) auf verschiedene Server verteilt werden. Binary Distribution Machine: Diese Rolle übernimmt nur ein Server innerhalb der Zelle. Die Binary Distribution Machine beherbergt die ausführbaren Dateien, die für die Funktionen eines AFS- 4

5 Servers benötigt werden. Alle anderen Server in der Zelle kontaktieren periodisch diese Maschine, um ihre lokalen Kopien der AFS-Server-Binaries zu aktualisieren. So können AFS-Software-Updates problemlos und automatisch auf alle Server verteilt werden. Um eine ähnlich gute Administrierbarkeit für die Client Binaries zu gewährleisten, werden diese oft im AFS-Baum in einem für die Gruppe system:anyuser lesbaren Bereich abgelegt und müssen somit ebenfalls nur an einer Stelle aktualisiert werden. System Control Machine: Der Server, der diese Rolle wahrnimmt, ist für die Verteilung der AFS- Konfigurationsdateien verantwortlich. Zur Vereinfachung der Administration kann man eine System Control Machine bestimmen, die die Konfigurationsdateien verwaltet und von der sich die anderen Server periodisch eine lokale Kopie der Dateien abholen. Da hierbei auch sensible Daten übertragen werden könnten, kann die Verbindung auch verschlüsselt werden. Auch von dieser Rolle sollte es nur einen Vertreter innerhalb einer Zelle geben. Database Server Machine: Um die Funktionsfähigkeit des AFS-Systems zu gewährleisten, werden verschiedene Datenbanken benötigt (siehe Abschnitt 5.2). Die Verwaltung dieser Datenbanken wird von einem oder mehreren Datenbankservern übernommen. Dabei wird der Datenbestand auf allen Servern ständig synchron gehalten, so daß, bei Ausfall eines Datenbankservers, die Clients problemlos auf einen anderen zugreifen können. Diese vier verschiedenen Rollen, die ein AFS Server übernehmen kann, können physikalisch voneinander getrennt werden, d.h. sie können unabhängig voneinander auf verschiedenen Maschinen installiert werden. Da die Binary Distribution Machine und die System Control Machine Optionen sind, die im Gegensatz zu den beiden anderen Rollen nicht in jeder Zelle vorhanden sein müssen, soll im weiteren Verlauf dieses Abschnitts nur noch auf die Rollen des File Servers und des Database Servers eingegangen werden, die neben dem Cache-Manager (siehe Abschnitt 6) die wesentlichen Komponenten eines AFS-Systems darstellen. 5.1 File Server Im letzten Abschnitt wurde bereits kurz auf die Funktion des File Servers eingegangen. Er ist für das Speichern und Bereitstellen der Daten innerhalb des AFS-Baums verantwortlich. Dazu werden auf dem File Server eine oder mehrere Partitionen exklusiv für das Ablegen von AFS Daten angelegt. Diese Partitionen müssen mit einem, dem verwendeten Betriebssystem bekannten, Dateisystem formatiert werden. AFS benutzt kein eigenes Dateisystem für das Speichern der Daten. Die Organisation der Daten erfolgt in Volumes. Volumes sind Datencontainer, die später in den AFS- Baum gemountet werden. Ein Volume muß immer in eine Partition eines File Servers passen. Das Verteilen auf mehrere Partitionen bzw. Server ist nicht möglich. Desweiteren ist die Dateigröße in der aktuellen AFS Version auf 2 Gigabyte beschränkt. Volumes dürfen eine Größe von 8 Gigabyte nicht überschreiten (zu weiteren Einschränkungen bzgl. der Anzahl der Partitionen und der Fileserver siehe [4]). Dateien dürfen ebenfalls nicht größer als das sie beherbergende Volume sein und können nicht auf mehrere Volumes verteilt werden Volumes Volumes erhalten bei ihrer Erzeugung einen (möglichst eindeutigen) Namen und eine automatisch generierte und eindeutige ID. Außerdem muß die Partition, die das Volume aufnehmen soll und die Größe des Volumes angegeben werden. Diese beiden Eigenschaften eines Volumes können allerdings, ebenso wie der Name, später problemlos verändert werden. Nachdem das Volume angelegt wurde, kann es auf ein Verzeichnis im AFS-Baum gemountet werden. So kann z.b. das Home-Verzeichnis jedes Nutzers auf einem eigenen Volume angelegt werden. Es werden 3 Arten von Volumes unterschieden: read-write Volumes, read-only Volumes und backup Volumes. Auf die Unterschiede und Einsatzmöglichkeinten der verschiedenen Arten wird im Folgenden eingegangen. Volumes, auf die schreibend und lesend zugegriffen werden kann, heißen read-write Volumes. Sie sind an allen Stellen sinnvoll, wo sich der Inhalt (die Daten) eines Verzeichnisses oder eines Verzeichnisbaums häufig ändern. Diese Art der Volumes bildet auch die Quelle bzw. Grundlage für die beiden anderen Volume-Typen. Die read-only und backup Volumes werden immer auf der Basis eines readwrite Volumes erstellt. 5

6 Sollte ein Volume sehr stark frequentiert, d.h. sehr oft benutzt werden, ist es möglich von ihm eine Kopie auf einem anderen Server anzulegen. Dieser Vorgang wird Replikation eines Volumes genannt. Die Clients können dann je nach Lastsituation entscheiden, von welchem Server sie die Daten dieses Volumes beziehen. Die Replikation eines Volumes kann während des Betriebs des Servers erfolgen und ist für die Benutzer transparent. Bei der Replikation eines Volumes entstehen allerdings immer read-only Kopien, d.h. die Erzeugung von replizierten Volumes ist nur sinnvoll, wenn die replizierten Daten weitgehend statisch sind, sich also nicht oft ändern und wenn einem Großteil der Nutzer der lesende Zugriff ausreicht. Die Replika eines Volumes sind allerdings nicht statisch, sie können, wenn auch manuell, vom Administrator, aktualisiert, d.h. mit dem Original abgeglichen werden. Um alle replizierten Versionen eines Volumes zu aktualisieren führt ein Administrator ein release-kommando für das Original-Volume aus, das die Erneuerung der read-only Kopien einleitet. Eine andere Möglichkeit, einen Server zu entlasten, ist, ein oder mehrere Volumes vollständig auf einen anderen Server zu verschieben, der möglicherweise weniger Volumes beherbergt und nicht so oft angesprochen wird. Ein anderer Grund für das Bewegen von Volumes auf einen anderen Server könnte z.b. ein Hardwareausfall sein, der es erfordert, den ursprünglichen Server der Volumes abzuschalten. Dieses Bewegen von Volumes erfolgt ebenfalls ohne Unterbrechung der Arbeit des Server oder der Clients. Im Gegensatz zu read-only Versionen eines Volumes, die in nahezu allen Fällen eine vollständige Kopie der Originaldaten darstellen, sind backup Volumes sogenannte Clones des Originalvolumes. Ein Clone ist ein sogenannter Snapshot von einem Volume und enthält nur Verweise auf die ursprünglichen Daten. Daher nehmen backup Volumes zunächst auch nur sehr wenig Platz ein. Erst wenn im Originalvolume eine Datei geändert oder gelöscht wird, erfolgt eine Sicherung des Ausgangszustandes dieser Datei im backup Volume, d.h. die Implementation der backup Volumes folgt dem copy-on-write Konzept. Allerdings können backup Volumes nur in der gleichen Partition wie das Original angelegt werden, da sonst die Vorgehensweise, nur Verweise zu speichern nicht möglich wäre. Backup Volumes werden zu späteren Zeitpunkten auf ein externes Medium gesichert. Während dieser Sicherung, die auch von einem normalen readwrite Volume möglich wäre, wäre das Volume jedoch nicht erreichbar. Daher sind backup Volumes der geeignetere und auch der dafür vorgesehene Weg für die Datensicherung. Eine weitere Eigenschaft der backup Volumes ist es, daß sie auch wieder in den AFS-Baum gemountet werden können. So sind beispielsweise Benutzer selbst in der Lage, versehentlich gelöschte Dateien wiederherzustellen. 5.2 Database Server Der AFS-Datenbankserver verwaltet die vier verschiedenen Datenbanken, die zum Betrieb einer AFS Zelle erforderlich sind. Hierbei handelt es sich um folgende Datenbanken: authentication database: Sie speichert die privaten Schlüssel der Benutzer und der Server. Diese Datenbank entspricht der Kerberos Database (siehe Abbildung 2) des Kerberos Authentisierungssystems. protection database: Diese Datenbank enthält die Abbildungen von Kerberos Identitäten auf AFS-UIDs, die Gruppen und ihre Mitglieder, sowie sämtliche ACLs, die angelegt wurden. volume location database: Wie der Name schon verrät, werden in dieser Datenbank Informationen über die Volumes, und ihre Replika abgelegt. backup database: Es ist möglich, mehrere backup Volumes zu einem Volume Set zusammenzufassen und Operationen auf dem gesamten Volume Set auszuführen. Darüber hinaus muß für den tatsächlichen Vorgang der Datensicherung ein Rechner als Tape Coordinator benannt werden, der möglicherweise verschiedene Bandlaufwerke zur Verfügung stellt. Diese und weitere Informationen zur Datensicherung (siehe [2]) werden in der backup database verwaltet. Für jede dieser Datenbanken wird auf dem AFS Database Server ein Managementprozeß ausgeführt, der den Zugriff auf die Daten verwaltet und der insbesondere auch die Synchronisation mit weiteren Instanzen dieser Datenbank regelt. Um den Betrieb einer AFS Zelle aufrecht zu erhalten, sollten 6

7 nicht nur von den aufbewahrten Daten Sicherheitskopien angelegt bzw. bereitgehalten werden, sondern auch von den verschiedenen Verwaltungsdatenbanken. Sollte der einzige Datenbank Server einer Zelle ausfallen, ist faktisch kaum noch ein Arbeiten möglich (siehe Abschnitt 6), da häufig auf die Datenbanken zugegriffen werden muß. Aus diesem Grund ist es sinnvoll, bzw. sehr empfehlenswert, einen zweiten Datenbank Server einzurichen, der die Arbeit bei Ausfall des Ersten übernehmen kann. Darüberhinaus können sich auch mehrere Datenbank Server die Arbeit teilen Das Ubik Protokoll Die Synchronisation der replitzierten Datenbanken erfolgt über das Ubik Protokoll. Der Name Ubik stammt von der Bezeichnung ubiquitous data ab, die soviel wie allgegenwärtige Daten bedeutet. Im folgenden soll die Funktionsweise dieses Protokolls zum Management einer Datenbank, die über mehrere Sites verteilt ist, skizziert werden. Für jede der replizierten Datenbanken existiert eine master copy an der sogenannten synchronization site. Alle anderen (replizierten) Instanzen dieser Datenbank werden secondary sites genannt. Ein Ubik Koordinator verwaltet auf jeder Site die Datenbankoperationen. Empfängt ein Koordinator einer secondary site eine Anfrage zum Ändern der Datenbank, so leitet er sie an die synchronization site weiter. Nur dort werden Veränderungen vorgenommen und dann an die secondary sites verteilt. Jede Kopie der Datenbank trägt eine Versionsnummer, die bei allen Kopien übereinstimmen muß. Mit ihr überprüft der Koordinator der synchronization site, ob die secondary sites eine aktuelle Kopie der Datenbank besitzen. Sollte eine secondary site vom Netz getrennt werden, so erhält sie keine Updates der Datenbank mehr, was der Koordinator der synchronization site an der zu kleinen Versionsnummer erkennt und der secondary site eine aktuelle Kopie zuschickt. Der Koordinator der synchronization site sendet periodisch eine Anfrage zu allen secondary sites. Wenn er eine Antwort erhält, zählt er sie als Stimme für seine weitere Wahl zur synchronization site. Diese Stimmabgabe wird vom Koordinator der synchronization site protokolliert und sobald die Mehrheit (mehr als 50 %) der secondary sites gegen ihn stimmt, d.h. nicht antwortet, muß eine neue synchronization site bestimmt werden. Die Notwendigkeit einer Mehrheit unter den Datenbankservern favorisiert eine ungerade Anzahl von ihnen. Sollte man sich doch für eine gerade Anzahl entscheiden, so werden die Stimmen der Server mit einer niedrigeren IP- Adresse in ihrer Wertigkeit angehoben und somit wieder eine Mehrheitsfähigkeit hergestellt. Weitere Gründe für die Wahl einer neuen synchronization site (neben dem Verlust der Mehrheit der Stimmen der secondary sites) sind das Fehlschlagen eines Updates auf einer Mehrheit der secondary sites oder ein Ausfall der synchronisation site sein. Die Wahl einer neuen synchronization site erfolgt nach dem einfachen Prinzip, daß jeder Koordinator von den Servern, die er erreichen kann, jenen wählt, der die niedrigste Netzwerkaddresse hat. Normalerweise wird also die Maschine mit der kleinsten Netzwerkadresse die neue synchronization site. Nach erfolgreicher Wahl überprüft der Koordinator der neuen synchronization site die Versionsnummern aller secondary sites und seiner eigenen und verteilt jene Kopie mit der höchsten Nummer als neue master copy an alle sites. Während der Wahl einer neuen synchronization site und der Verteilung der aktuellen Datenbankversion ist die entsprechende Datenbank nicht ansprechbar. Dieser Vorgang dauert allerdings normalerweise nicht länger als ein paar Minuten. Der gesamte Vorgang der ständigen Bestätigung der synchronization site und der Wahl einer neuen synchronization site geschieht völlig ohne Nutzer- oder Administratorinteraktion. Auch hier konnte nur ein kleiner Einblick gegeben werden. Weitere Informationen finden sich in der Literaturliste ([5]). 7

8 6 Cache Management Um den Zugriff auf häufig benötigte Dateien zu beschleunigen und außerdem die Netzlast zu verringern, ist auf den AFS Clients ein Cache Manager installiert. Der Cache Manager afsd ist ein User- Space Prozeß, der über das AFS-Kernel-Modul (siehe Abschnitt 7) angesprochen wird. Tatsächlich werden mehrere Prozesse gestartet, die unterschiedliche Teilaufgaben des Cache Managements übernehmen. Die Verwaltung der Callbacks (s.u.) übernimmt der callback daemon. Er antwortet auch auf die periodischen Anfragen der File Server, ob der Client noch aktiv ist. Der maintenance daemon ist u.a. für die Garbage Collection (z.b. abgelaufene Token) und die Dateisynchronisation verantwortlich. Ist der Cache voll, tritt der cache-truncation daemon in Aktion. Er löscht lange nicht genutzte Chunks (s.u.) und schickt veränderte Daten zum File Server. Als weiterer Prozeß wird der server connection daemon gestartet. Er überwacht die Verbindungen zu den File Servern, von denen Daten im Cache sind. Außerdem synchronisiert er die lokale Systemzeit des Clients periodisch mit einem zufällig ausgewählten File Server. 5 Weiterhin werden noch mehrere (standardmäßig zwei) background daemons gestartet die durch das Pre- Fetching von Daten die Performance erhöhen sollen. In der Konfiguration des Cache Managers kann man zunächst entscheiden, ob der Cache auf der Festplatte oder im Hauptspeicher angelegt werden soll. Die Cache Funktionalität kommt allerdings nur beim Lesen von Dateien zum Tragen. Das Schreiben erfolgt im write-through Verfahren, d.h. jede Dateiänderung wird sofort an den Server, auf dem die Datei gespeichert ist, weitergeleitet. 6 Das Caching der Dateien erfolgt in Chunks, d.h. es wird nicht die gesamte Datei übertragen, sondern zunächst nur der Block, auf den zugegriffen wurde. Die voreingestellte und auch empfohlene Chunk- Größe beträgt 64 Kilobyte. Zusätzlich zu den Datei- Chunks werden auch noch andere Informationen im Cache gehalten. Dazu gehören die Authentifizierungstoken der Nutzer und Daten, die aus den verschiedenen AFS-Datenbanken stammen (siehe Ab- 5 Die AFS Server synchronisieren ihre Systemuhren untereinander. 6 Sofort bedeutet in diesem Zusammenhang, bei der Ausführung des close() Systemaufrufs. schnitt 5.2), wie zum Beispiel Informationen über den Aufenthaltsort von Volumes. Darauf soll im folgenden noch weiter eingegangen werden. Bevor jedoch eine Datei übertragen werden kann, sind eine Reihe von Überprüfungen und Datenbankanfragen nötig, die in Abbildung 3 schematisch dargestellt sind. client node File Server Database Server $ cat /afs/cell/readm E 1 5 Cache Manager 3 File Server 2 4 Protection Server Volume Location Server Abbildung 3: Ablauf einer AFS-Operation Als Ausgangssituation für die Abbildung 3 wird angenommen, daß der Nutzer sich erfolgreich am System angemeldet und ein AFS-Token erhalten hat. Wird vom Benutzer die Ausgabe des Inhalts einer Datei, die im AFS-Baum liegt, gefordert, sind die folgenden Schritte zur Ausführung der Anfrage erforderlich: 1. Die Anfrage des Nutzers wird zuerst vom Virtual File System (VFS) des Kernels entgegengenommen. Dieser Schritt ist in der Abbildung nicht enthalten. Sobald festgestellt wird, daß es sich um eine AFS Datei handelt, wird die Anfrage an den afsd (den Cache Manager) weitergeleitet. Im einfachsten Fall ist die Datei bzw. der angeforderte Block (Chunk) schon im Cache enthalten und der Cache Manager kann ihn an die Applikation ausliefern. 2. Ist die Datei nicht im Cache, so muß de Cache Manager zunächst feststellen, welche File Server die Datei zur Verfügung stellen können. Dazu stellt er eine Anfrage an einen Volume Location Server (VL-Server), dem er den Pfad der Datei, die gesucht wird, mitteilt. Der VL- Server antwortet nun mit einer Liste von File Servern, die das Volume beherbergen und die Daten liefern könnten. Diese Informationen werden ebenfalls im Cache zwischengespeichert. 8

9 3. Als Nächstes wählt der Cache Manager den File Server, der die beste Antwortzeit hat, aus und schickt eine Anfrage für die geforderte Datei an diesen Server. Diese Anfrage beinhaltet auch die AFS-UID des Nutzers, der die Datei angefordert hat. 4. Der Fileserver überprüft nun zunächst, ob der Benutzer berechtigt ist, diese Datei zu lesen. Dazu sendet er die AFS-UID des Nutzers und die Dateiinformationen zu einem Protection Server, der Zugriff auf die Protection Database hat. Dieser verifiziert die Berechtigung des Nutzers an Hand der Access Control List des Verzeichnisses in dem die Datei liegt und teilt das Ergebnis dem File Server mit. 5. Bei positiver Antwort des Protection Servers liefert der File Server die geforderte Datei bzw. die angeforderten Chunks an den Cache Manager aus, der die Daten an den Nutzer übergeben kann. Zusätzlich bekommt der Cache Manager einen Callback für diese Datei mitgeliefert (s.u.). Damit ist die Operation abgeschlossen. Um den Cacheinhalt konsistent zu halten, wird vom File Server, auf dem die Datei gespeichert ist, für jede Datei (bei read-write Volumes) bzw. für das ganze Volume (bei read-only Volumes) ein Callback an den Cache Manager des Clients übergeben. Sollte ein anderer Client (Cache Manager) eine veränderte Version dieser Datei zum File Server schicken (weil ein Nutzer sie bearbeitet hat), so wird der File Server bei allen anderen Cache Managern, die Callbacks für diese Datei invalidieren. Somit sind sie informiert, daß sie beim nächsten Zugriff die Daten erneut vom File Server anfordern müssen. Bei read-only Volumes existiert immer nur ein Callback für das gesamte Volume, der invalidiert wird, sollte das Volume akualisiert (released) werden (siehe Abschnitt 5.1.1). Sollte das geschehen sein, müssen alle Zugriffe auf Daten dieses Volumes zunächst erneut durch eine Anfrage den File Server bearbeitet werden. 7 Testinstallation Die Testinstallation von OpenAFS wurde auf unserem experimentellen Linux Cluster durchgeführt. Er besteht aus fünf Dualprozessor PCs von denen allerdings nur 4 für AFS konfiguriert wurden, da der fünfte Knoten, der gleichzeitig als Gateway nach außen fungiert, auch bei AFS-bedingten Systemfehlern erreichbar bleiben sollte. Je zwei Rechner wurden als Clients und als Server konfiguriert. Da, wie schon am Anfang erwähnt, keine Performance Messungen möglich waren, soll hier nur kurz die Konfiguration beschrieben werden. Einige der folgenden Beschreibungen sind spezifisch für Linux. Darauf soll allerdings nicht genauer eingegangen werden. Weitere Informationen zu systemspezifischen Konfigurationsoptionen sind in [4] nachzulesen. Die Server waren beide als Datenbank und File Server konfiguriert. Für die File Server Funktionalität wurden auf den lokalen Festplatten Partitionen angelegt, die im Dateisystem unter /vicep[a-z] gemountet werden. Die Konfigurationsdateien CellServDB und ThisCell enthalten die Liste der verfügbaren Datenbank Server der Zelle und den Namen der lokalen Zelle. In CellServDB werden gegebenenfalls auch die entfernten Zellen mit ihren Datenbank Servern eingetragen. Diese Dateien werden unter /usr/afs/etc gespeichert. Für den Fileserver werden beim Start des Systems mehrere Prozesse gestartet, die für die Bearbeitung von Requests der Clients zuständig sind. Für die Konfiguration der Datenbankserver wird für jede Datenbank ein Managerprozeß gestartet, der dann über Kommandos der AFS-Suite angesprochen werden kann. Beim Start greifen die Manager auf die Datei CellServDB zu, um die anderen Datenbank Server dieser Zelle kennenzulernen. Zusätzlich können noch einige Server Prozesse gestartet werden, die sich um die Verteilung der Server Binaries, der Konfigurationsdateien oder um die Synchronisation der Systemzeit auf den Servern kümmern. Bei den Clients ist es, im Gegensatz zur Serverkonfiguration, notwendig, den Kernel über ein AFS Modul zu erweitern, damit er mit dem AFS- Dateisystem umgehen kann. Die Konfigurationsdateien befinden sich unter /usr/vice/etc. Hier sind wieder CellServDB und ThisCell zu finden aber auch das Kernel Modul, das afsd Binary und eine Datei cacheinfo. In dieser Datei wird für einen Disk-Cache festgelegt, in welchem Verzeichnis die Cache-Dateien abgelegt werden sollen (Standard ist /usr/vice/cache) und wie groß der Cache sein 9

10 soll. Bei Benutzung eines Memory-Caches wird nur die Größeninformation aus der Datei benutzt. Die beiden zentralen Konfigurationsdateien CellServDB und ThisCell sollten auf allen Rechnern einer Zelle identisch sein. Leider gibt es jedoch keinen Mechanismus, sie auf allen Maschinen aktuell zu halten. Nur für die Server existiert diese Möglichkeit bei Verwendung einer System Control Machine (siehe Abschnitt 5). Im Rückblick zeigt sich die Installation recht komplex, da sehr viele Einzelschritte notwendig sind und es z.b. keine graphische Unterstützung für die Konfiguration gibt, die den Überblick wesentlich verbessern könnte. 8 Auswertung Das AFS ist ein mächtiges Werkzeug für die Verwaltung von Daten, die an verschiedenen Standorten gespeichert sein können. Wie kurze Tests allerdings bestätigt haben, kann es mit explizit für den Clustereinsatz entworfenen Dateisystemen wie PVFS bezüglich Performance nicht konkurrieren. Allerdings ist es auch nicht für dieses Einsatzgebiet entworfen worden. Im Gegensatz zu PVFS implementiert es ein sehr umfangreiches Authentisierungssystem, das im Clustereinsatz allerdings wiederum zum Hindernis werden könnte. Aufgrund dieser Einschränkungen kann AFS nicht als Clusterdateisystem empfohlen werden. [5] Zayas, Edward R., AFS-3 Programmers Reference: Architectural Overview, September 1991, Transarc Corp. [6] Campbell, Richard; Campbell, Andrew, Managing AFS: The Andrew File System, Prentice Hall, August [7] AFS Frequently Asked Questions, Juli 1998, q.html. [8] Kerberos: The Network Authentication Protocol, Dezember 2000, eros/www/. [9] Bryant, Bill, Designing an Authentication System: a Dialogue in Four Scenes, Februar tml. [10] Kohl, John; Neuman, Clifford, The Kerberos Network Authentication Service (Version 5) Internet Requst for Comments RFC-1510, September Literatur [1] Satyanarayanan, Mahadev, Scalable, Secure and Highly Available Distributed File Access, IEEE Computer 23(5), Mai 1990 [2] IBM AFS Administration Guide Version 3.6, First Edition, April 2000, erhältlich unter mentation/afs/3.6/unix/en US/HTML/index.htm. [3] IBM Quick Beginnings Version 3.6, First Edition, April 2000, erhältlich siehe [2]. [4] IBM AFS Release Notes Version 3.6, First Edition, April 2000, erhältlich unter siehe [2]. 10