als Cluster-Dateisystem (?) Sebastian Heidl <heidl@zib.de>
Plan Einführung, Historisches Überblick, Benutzung Sicherheit Funktionsweise
AFS verteiltes Dateisystem auf Client/Server Basis geeignet/konzipiert für LANs und WANs ausgefeiltes Authentisierungssystem basierend auf Kerberos und ACLs Caches für Reduktion der Zugriffszeit und Netzlast Clients und Server verfügbar für diverse UNIXe, Win9x, WinNT
Historie basiert auf Projekt für verteiltes Dateisystem der CMU Andrew File System 1989: Transarc Corp. wurde für Vermarktung und Weiterentwicklung von AFS gegründet Andrew fiel weg, AFS und /afs blieben ebenfalls 1989: Transarc wird von IBM gekauft 09/2000 IBM (Transarc) macht Zweig von AFS OpenSource OpenAFS
AFS Struktur Sebastian Heidl client server server Cell B client Cell A client client server client Cell C server
Überblick Zellen sind administrative Einheiten Zelle kann mehrere Server umfassen Daten können auf mehrere Server repliziert und verteilt werden Clients können mehreren Zellen angehören umfangreiche Rechteverwaltung über ACLs Authentisierung über Kerberos
Benutzung Nutzer meldet sich am System an und erhält automatisch ein AFS-Token (siehe Kerberos) AFS-Space wird auf /afs gemountet nächste Verzeichnisebene ist der Name der Zelle (/afs/cluster.inf.fu-berlin.de/) entfernte Zellen werden ebenfalls unter /afs gemountet (z.b. /afs/transarc.com/) aktueller Speicherort der Daten innerhalb einer Zelle ist transparent (SSI)
Sicherheit Authentisierung über Kerberos (mutual authentication) nach der Authentisierung Nutzung der normalen UNIX Kommandos und Systemrufe verzeichnisorientierte Rechtevergabe durch ACLs Daten sind nicht verschlüsselt
Kerberos Kerberos : dreiköpfiger Wachhund von Hades gegenseitige Authentisierung von Clients und Services über ein unsicheres Netzwerk entwickelt am MIT im Rahmen von Projekt Athena Nutzer soll sich nur einmal authentisieren keine ungeschützte Übertragung von Authentisierungsinformationen
Kerberos - Benutzung jeder Nutzer und jeder Service hat einen eigenen privaten Schlüssel alle Schlüssel liegen zusätzlich in der Kerberos DB Nutzer benötigt spezifisches Ticket, um Service zu benutzen Tickets werden vom Ticket-Granting Service ausgestellt Tickets haben eine bestimmte Lebenszeit
Kerberos - Systemüberblick Sebastian Heidl Kerberos Database Key Distribution Center Ticket Granting Service 1 3 Print Service 2 Client 4 File Service 1. ticket-granting Ticket vom KDC holen 2. Ticket für Service vom TGS holen 3. Ticket für Service benutzen 4. neues Ticket vom TGS holen und benutzen
Kerberos - Authentisierung 1. Client (user) holt sich TGS-Ticket vom KDC: C KDC: ticket request user addr nonce KDC C: TGS ticket TGSkey user addr service timestamp lifespan sessionkey 2. Service-Ticket vom TGS besorgen: C TGS: TGS C: service nonce Service Ticket Authenticator sessionkey user addr timestamp User Info sessionkey new sessionkey TGS Ticket User Info userkey sessionkey nonce service timestamp lifespan nonce service timestamp lifespan 3. neuen Authentikator erzeugen und mit dem Ticket zum Server schicken, ordnungsgemäße Antwort abwarten und Service nutzen
AFS - Access Control Lists (ACLs) jeder Nutzer bekommt AFS-UID drei vordefinierte Gruppen: system:anyuser, system:authuser, system:administrators steuern Zugriff auf Verzeichnisse und die enthaltenen Dateien können AFS-UIDs und AFS-Groups enthalten Verzeichnisrechte: lookup, insert, delete, administer Dateirechte: read, write, lock
Interpretation der UNIX Zugriffsrechte Sebastian Heidl mode-bits der Verzeichnisse werden ignoriert für Dateien sind nur User-Bits relevant r und w sollten mit den AFS Rechten rl und wl kombiniert werden nur system:administrators können S-Bit modifizieren Zugriff von SUID-Programmen auf den AFS-Space erfolgt mit real-uid Ausführung von SUID-Files kann verboten werden
AFS-Server Rollen Simple File Server Machine: stellt lokale Partitionen für den AFS-Space zur Verfügung und speichert die Daten Binary Distribution Machine: verteilt die AFS-Server binaries auf die anderen Server System Control Machine: verteilt die AFS Konfigurationsdateien auf die anderen Server Database Server Machine: hält eine lokale Kopie der AFS-Datenbanken (s.u.)
AFS-Server Sebastian Heidl AFS Server File Server Database Server Simple File Server Machine Binary Distribution Machine Protection Database Volume Location Database System Control Machine Authentication Database Backup Database
AFS-File-Server bekommt eine oder mehrere lokale Partitionen zugeteilt (max. 256) Partitionen müssen funktionierendes Dateisystem beinhalten z.z. Dateigröße auf 2GB beschränkt Dateien können nicht gestriped werden max. 255 File-Server in einer Zelle
Volumes Organisationseinheit für die Daten max. 8GB groß müssen in eine Partition passen (kein striping) read-write, read-only und backup Volumes können online zwischen Partitionen und Servern bewegt und repliziert werden
Volumes (2) Sebastian Heidl werden auf Verzeichnisse gemountet Replikation und Bewegen ist für Nutzer transparent Replikation erzeugt automatisch read-only Volume Replizierte Volumes müssen manuell released werden. bei Serverausfall greifen die Clients automatisch auf replizierte Volumes auf anderen Servern zu
Backup Volumes Snapshot des aktuellen Zustandes eines Volumes werden in Volume Sets zusammengefaßt nur Verweise auf die Daten des Volumes bei Änderungen am Original Volume alte Daten ins Backup irgendwann wird Backup Volume zum Tape Coordinator gedumped vollständige oder inkrementelle Dumps
Volumes bewegen Arbeit der Clients wird typically in the order of a few seconds unterbrochen Dump (Kopie) des Volumes machen und am neuen Ort installieren Volume locken und inkrementellen Dump anwerfen inkrementellen Dump auf Ziel installieren Original Volume löschen
AFS-Datenbank-Server führt Manager für die vier DBs aus: kaserver: Kerberos-Authentisierung, Tickets ausgeben ptserver: Mapping von Kerberos-Principals auf AFS-IDs, ACL Verwaltung vlserver: Verwaltung der Volume Location Database buserver: Backup Volume Sets, Tape Coordinator, dump hierarchy...
AFS-Datenbank-Server (2) Sebastian Heidl mehrere DB-Server können Ausfallsicherheit erhöhen DB-Synchronisation über Ubik Protokoll: DB-Server wählen coordinator für jede DB coordinator läuft auf synchronization site nur synchronization sites nehmen Änderungen von Clients entgegen sync. site kann auf andere Maschine migrieren (voting) andere (secondary) sites nehmen nur von sync. site Änderungen an
Cache Management Sebastian Heidl Clients führen mehrere Instanzen des Cache Managers (afsd) aus Memory- oder Disk-Cache eigentlich nur Lese-Cache (write-through) immer Chunks einer festen Größe übertragen File Server liefern Callbacks mit Dateien aktiviert, falls ein Anderer schreibt Authentisierungsinfo und Volume-Info ebenfalls gecached
Wie funktioniert s denn nun? client node File Server Database Server $ cat /afs/cell/readm E 1 5 3 File Server 4 Protection Server Cache Manager 2 Volume Location Server
Integration in Linux Kernel Modul für 2.2.x, 2.4.x diverse Binaries zur Administration Integration in Bootprozeß und Loginprozeß möglich
AFS Konfiguration für Linux Server Client binaries /usr/afs/bin /usr/vice/etc config usr/afs/etc /usr/vice/etc ThisCell CellServDB ThisCell CellServDB cacheinfo
Quellen Sebastian Heidl AFS: Kerberos: http://www.openafs.org http://oss.software.ibm.com/developerworks/opensource/afs/ http://www.transarc.ibm.com/ http://www.angelfire.com/hi/plutonic/afs-faq.html Zayas, E., AFS-3 Programmer s Reference: Architectural Overview http://web.mit.edu/kerberos/www http://web.mit.edu/kerberos/www/dialogue.html RFC-1510: The Kerberos Network Authentication Service (V5)