Vielfach

Inhaltsverzeichnis

XtreemFS (www.xtreemfs.org) entstand im Rahmen des ehemaligen europäischen Forschungsprojekts XtreemOS (www.xtreemos.eu). Dessen Ziel war die Entwicklung eines Linux-Ablegers, der die Vorzüge von Grid Computing mit der einfachen Handhabung eines einzelnen Computers verbinden sollte (siehe Kasten „XtreemOS“). Das Grid agiert dabei für den Anwender wie ein eigenständiger Rechner, nimmt den Compute-Auftrag entgegen und verwaltet die benötigten Ressourcen und Berechtigungen. Für die Verwaltung der Daten in einem solchen Grid eignet sich am besten ein verteiltes Dateisystem.

Als das Projekt 2006 begann, waren die für Linux verfügbaren verteilten Dateisysteme allerdings noch dünn gesät. Zudem lag der Fokus von XtreemOS eher auf Verteilung, Sicherheit und Skalierbarkeit als auf Performance. Also entwickelten die Forscher ihr eigenes Dateisystem. XtreemFS 1.0 erschien 2009 und unterstützte Funktionen wie parallele Lese- und Schreibzugriffe sowie Datenreplikation im Lesemodus. Mitte 2011 kam Version 1.3 heraus, die Daten auch im Schreibmodus replizieren kann.

Wie manch anderer Vertreter seiner Klasse besitzt XtreemFS eine auf Objekten basierte Speicherverwaltung. Sogenannte Object-based Storage Devices (OSD) bilden eine Kernkomponente der Architektur. Sie speichern die Daten und führen die benötigten Lese- und Schreibzugriffe durch. XtreemFS verwendet eine eigene Software-Implementierung für die OSDs.

Objektorientiert gespeichert

Metadaten wie Dateinamen, Zugriffsrechte und andere Verwaltungsinformationen legt XtreemFS auf einem Metadatenserver ab. Der ist außerdem für die Verwaltung der Datei-Repliken zuständig und heißt deshalb „Metadata and Replica Catalog“ (MRC). Zusätzlich führt er die Nutzerauthentifizierung durch und erlaubt beziehungsweise verbietet den Zugriff auf die Daten. Dritter im Bunde ist der Directory Service (DIR), eine zentrale Registratur für die XtreemFS-Dienste einschließlich MRC und OSDs (siehe Abb.).

Der Client erlaubt Zugriffe auf das Dateisystem über eine POSIX-konforme Schnittstelle, sodass Anwendungen ohne Änderung mit XtreemFS arbeiten können. Er ist nicht Bestandteil des Kernels, sondern per FUSE eingebunden. Obwohl XtreemFS nicht auf den HPC-Sektor zielt, empfehlen die Entwickler für eine akzeptable Performance die Verwendung aktueller Kernel und FUSE-Bibliotheken.

Sämtliche Server laufen als selbstständige Prozesse unter einer nicht privilegierten Nutzerkennung, meist xtreemfs. Man kann prinzipiell unterschiedliche Kennungen für die einzelnen Dienste verwenden, praktisch ist so eine Konfiguration jedoch nicht.

Die Kommunikation zwischen Clients und Diensten sowie zwischen OSDs, MRC und DIR findet vorwiegend per TCP beziehungsweise UDP statt. DIR-Service, MRC und die OSDs sind auf den Ports 32638, 32636 und 32640 erreichbar. In der Standardkonfiguration sind alle Netzverbindungen unverschlüsselt, XtreemFS erlaubt jedoch das Absichern der Kanäle mit SSL. In der „Light“-Variante, Grid-SSL-Modus genannt, verwendet das Dateisystem Zertifikate nur zur Nutzerauthentifizierung, der eigentliche Datenverkehr findet im Klartext statt.

XtreemFS wirbt mit der Unterstützung für mehrere Plattformen: Linux, Mac OS X und Windows. Da die Server-Prozesse in Java geschrieben sind, ist eine Portierung auf andere Betriebssysteme denkbar. Noch ist der Multi-Plattform-Support jedoch alles andere als ideal. Auf der Projektseite finden sich nur für Linux vorgefertigte Pakete. Für Mac OS X ist Handarbeit nötig, die Windows-Fraktion ist zurzeit im Hintertreffen: Die aktuelle Version 1.3 des Clients gibt es nur für Linux und Mac OS X. Zwar sind ältere Versionen für Windows verfügbar, doch die sind mit den aktuellen Servern nicht kompatibel.

Daten-Eier in mehreren Körbchen

Replikation ist nach Aussagen der Entwickler eine zentrale Funktion von XtreemFS. Sie soll eine hohe Verfügbarkeit der Daten gewährleisten. Das Dateisystem unterstützt verschiedene Methoden der Vervielfältigung. Sogenannte Nur-Lese-Dateien kann XtreemFS schon seit Version 1.0 replizieren. Dabei unterscheidet das Dateisystem zwischen vollständigen und partiellen Kopien. Letztere sind zunächst leer – XtreemFS befüllt sie erst, wenn entsprechende Anfragen eines Clients eingehen. Dieses Vorgehen minimiert Transportvorgänge über das Netz, da nur die gerade benötigten Teile der Datei kopiert werden müssen. Nur-Lese-Kopien sind per Design nicht veränderbar, sodass XtreemFS ohne großen Verwaltungsaufwand fast beliebig viele Kopien anlegen kann. Außerdem gibt es keine Hierarchie der Repliken – alle Kopien sind gleichwertig. Typische Anwendungsfälle sind große Dateien mit statischem Inhalt, die das Grid-Dateisystem über Netzverbindungen mit geringer Kapazität dem Nutzer quasi-lokal zur Verfügung stellt.

Seit der aktuellen Version 1.3 beherrscht XtreemFS auch das Replizieren nicht schreibgeschützter Dateien. Dazu verwendet es eine Master/Slave- respektive Primary/Secondary-Technik. Trifft eine Anfrage ein, machen die beteiligten OSDs unter sich aus, welche als Ansprechpartner für den Client dienen soll. Diese Primär-OSD verfügt über einen sogenannten Lease („Mietvertrag“), der sie für einen gewissen Zeitraum als „Master“ für Zugriffe auf diese Datei auszeichnet. Sie führt alle Zugriffe zunächst lokal aus. Verändert sich der Dateiinhalt, benachrichtigt sie alle übrigen OSDs, die eine Replik besitzen. Fällt die Primär-OSD aus, wählen die verbliebenen einen neuen Master.

Falls eine OSD nicht erreichbar ist, entscheidet das Dateisystem anhand einer Replikationsrichtlinie, ob der gesamte Schreibzugriff fehlschlägt oder nur auf den verbliebenen Datenträgern stattfindet. Im letzteren Fall verlangt XtreemFS, dass die Mehrzahl der benötigten Kopien erreichbar ist. Diese Richtlinie heißt WqRq (Write quorum, Read quorum). Das Gegenstück WaR1 (Write all, Read 1) erlaubt Schreibzugriffe nur, wenn alle Repliken verfügbar sind. Replikationsrichtlinien kann der Administrator sowohl auf Volume- als auch auf Dateiebene festlegen. Änderungen an der Volume-Konfiguration – etwa der Zahl der Kopien oder der Richtlinie selbst – wirken sich nur auf neu angelegte Dateien aus.

Redundante Metadaten

DIR- und MRC-Server speichern ihre Daten lokal. Ein zweiter Kopiermechanismus erhöht die Verfügbarkeit. Analog zur Datenreplikation kommt das Master/Slave-Prinzip zur Anwendung, wobei ausschließlich der Master einen Lease besitzt. Zurzeit können die DIR-Server jedoch nur einen konsistenten Datenbestand absichern, ein automatischer Failover ist noch nicht implementiert. Da das automatische Finden des DIR-Servers (Autodiscovery) leider auch nicht funktioniert, muss der Administrator entweder externe HA-Maßnahmen treffen oder im Fehlerfall selbst Hand anlegen.

Etwas besser sieht es beim MRC aus. Die aktuelle Entwicklerversion unterstützt einen automatischen Failover des MRC-Masters unter bestimmten Voraussetzungen: Zum einen müssen mindestens drei MRC-Instanzen existieren, damit bei einem Ausfall noch eine Mehrheitsentscheidung möglich ist. Zum anderen müssen die Uhren der entsprechenden Server synchronisiert sein, etwa per NTP.

Während des MRC-Failover sind sämtliche Anfragen zeitweise blockiert. Schreibende Zugriffe müssen danach einen anderen Server adressieren. Der Administrator kann konfigurieren, ob diese Umleitungen für den Nutzer sichtbar sind oder nicht. Die Replikation der DIR- und MRC-Daten läuft über separate Netzverbindungen, optional mit SSL-Verschlüsselung. Letztere muss man in der Konfiguration separat aktivieren.

Zum Speichern der DIR- und MRC-Daten verwendet XtreemFS eine nicht relationale dateibasierte Datenbank names BabuDB (siehe Kasten „BabuDB“). Genau genommen sind die verwendeten Replikationsmechanismen Bestandteil von BabuDB und nicht extra für XtreemFS entwickelt. Alle Datenbankoperationen auf dem Master protokolliert BabuDB in einer Log-Datei. Die Log-Einträge sendet der Master serialisiert an die konfigurierten Slaves. Aus Gründen der Datenkonsistenz verbietet sich ein Puffern von Daten im Speicher. In der Standardeinstellung öffnet der DIR-Dienst daher die Datei im asynchronen Modus und ruft nach dem Schreiben fsync() auf. Alternative Einstellungen erlauben das Öffnen im synchronen Modus (O_SYNC oder O_DSYNC), sofern das Betriebssystem das unterstützt (siehe Tabelle „BabuFS-Schreibmodi“). Der MRC-Server öffnet die BabuDB-Datei aus Performance-Gründen ohne forciertes fsync(); diese Voreinstellung muss der Administrator ändern, damit die Replikation der MRC-Daten funktioniert.

Datenübertragung im nicht Geheimen

Beim Transportieren von Daten über das Internet stellt sich grundsätzlich die Frage, wie man Zugriffe Unbefugter unterbinden kann. Bei XtreemFS verwenden die Entwickler SSL und folgen einem Alles-oder-Nichts-Ansatz: Entweder ist jeglicher Datenverkehr zwischen den Dateisystemkomponenten verschlüsselt, oder keiner. In der vorliegenden Version müssen die SSL-Zertifikate lokal auf den jeweiligen Servern liegen. Mit steigender Zahl der Rechner, und seien es nur die Clients, wächst der Verwaltungsaufwand. Eine Schnittstelle zu einer PKI ist nahezu zwingend, wenn man das Dateisystem skalieren möchte.

Mehr Infos

BaduDB

BabuDB gehört zur Familie der dateibasierten, eingebetteten Datenbanken. Sie verwendet sogenannte LSM-Bäume (Log-Structured Merge-Trees) und ist in Java und C++ erhältlich.

Eine BabuDB-Datenbank besteht aus einem Satz von Key-Value-Indizes, einer Log-Verwaltung und einem sogenannten Checkpointer. Zu jedem Index gehören eine auf der Festplatte gespeicherte Liste und mehrere im Speicher abgelegte Bäume, von denen nur einer aktiv und veränderbar ist. Jegliche Datenmanipulation findet nur im aktiven Baum statt und wird vom Log-Verwalter protokolliert. Die Suche nach einem Eintrag findet zunächst im aktiven Baum statt, danach in den übrigen Bäumen im Speicher und zu guter Letzt auf der Festplatte.

XtreemFS versteht Zertifikate im X.509-PKCS#12-Format, kann aber auch das im Java-Umfeld bekannte JKS-Format (Java Key Store) lesen. Welches zum Einsatz kommt, entscheidet der Administrator per Konfiguration. Da keine Root-CA-Zertifikate zum Lieferumfang gehören, muss man diese manuell einpflegen und auf alle beteiligten Rechner verteilen.

Typischerweise schützt man Zertifikate durch Passwörter vor Missbrauch. Ein automatischer Start der DIR-, MRC- und OSD-Dienste erfordert dann allerdings das Hinterlegen des Passworts in den jeweiligen Konfigurationsdateien. Außerdem muss man zum Einhängen des Dateisystems auf dem Client das Passwort auf der Kommandozeile angeben – und der mount-Prozess läuft im Hintergrund, solange das Dateisystem gemountet ist. Selbst wenn es gelingt, die Konfigurationsdateien vor neugierigen Blicken zu schützen – ein Aufruf von ps auf dem Client genügt, und das Geheimnis ist keins mehr. An dieser Stelle erscheint Nacharbeit dringend notwendig.

Software-Implementierungen von OSDs präsentieren dem Client eine objektbasierte Schnittstelle, nutzen jedoch ein gewöhnliches Dateisystem als Datenablage. Der OSD-Entwickler kann die OSD-Mechanismen entweder in seinen Dateisystem-Code einbauen oder ein geeignetes Dateisystem als Backend verwenden. Die Macher von XtreemFS haben sich für den ersten Ansatz entschieden. Funktionen wie Copy on Write (CoW) oder Snapshots sind im XtreemFS-Code enthalten und gestatten die Verwendung eines quasi beliebigen Dateisystems als Unterbau.

Ein Dateisystem-Snapshot enthält den Zustand aller Daten und Metadaten zu einem bestimmten Zeitpunkt. Die Daten konserviert XtreemFS durch ein versioniertes Copy on Write, das die OSDs von Haus aus bereitstellen. Das „Einfrieren“ der Metadaten bewerkstelligt das Dateisystem, indem es einen BabuDB-Snapshot anlegt – die Funktion ist die Grundlage des Backup-Mechanismus der Datenbank und daher ohnehin vorhanden. Da BabuDB keine schreibenden Zugriffe auf die Snapshots gestattet, ist auch der XtreemFS-Snapshot selbst nur lesbar.

Mehr Infos

XtreemOs

Das XtreemOS-Projekt entwickelt ein Grid-fähiges Betriebssystem auf der Basis von Linux. Von 2006 bis 2010 fand die Entwicklung unter der Schirmherrschaft der Europäischen Union im Rahmen der Framework Programmes for Research and Technological Development statt. Es fanden sich fast 20 Projektpartner aus verschiedenen europäischen Ländern sowie aus China – sowohl aus dem universitären als auch aus dem industriellen Umfeld.

Ein aus XtreemOS-Rechnern bestehendes Grid soll dem Anwender wie ein einzelner Computer vorkommen und entsprechend einfach zu handhaben sein. Die zugrunde liegende Hardware ist für den Endanwender irrelevant – die Palette reicht vom mobilen Endgerät bis zum „Big Iron“ –, da XtreemOS die Ressourcenverwaltung selbst vornimmt. Jeder Nutzer ist Teil einer sogenannten Virtuellen Organisation, die Rechenzeit im Grid zugeteilt bekommt.

Die Architektur von XtreemOS besteht aus zwei Schichten: dem Flavour-Layer (XtreemOS-F) und dem Grid-Layer (XtreemOS-G). XtreemOS-F unterscheidet zwischen einen Standard-PC, einem Mobilgerät und einem Compute-Cluster, integriert diese und stellt dem Integrations-Layer eine einheitliche Schnittstelle zur Verfügung. XtreemOS-G bündelt die Ressourcen des Flavour-Layer und stellt sie dem Anwender als Einheit zur Verfügung.

Mit dem Ende des Förderprogramms der EU kam nicht das Endes Projekts. Die ehemaligen Partner beschlossen, die Entwicklung von XtreemOS weiterhin zu unterstützen. Version 3.0 des Betriebssystems ist Anfang Februar erschienen und steht auf der Projektseite als Disk-Image für die Virtualisierer KVM und VirtualBox zum Download bereit.

Wie XtreemFS die Daten einer Datei über die OSD-Landschaft verteilt, bestimmt eine Verteilungsrichtlinie (striping policy). In künftigen Versionen soll der Administrator zwischen RAID 5 und RAID 0 wählen können, momentan steht nur Letzteres zur Verfügung. In der Standardkonfiguration legt XtreemFS alle Daten einer Datei in 128 KByte großen Häppchen auf derselben OSD ab. Die Einstellung lässt sich sowohl beim Anlegen des Volumes als auch im laufenden Betrieb ändern. Der Verwalter kann wählen, wie viele OSDs zum Einsatz kommen und wie groß die Dateischnipsel sein sollen. Das Verteilen der Daten auf mehrere OSDs kommt vor allem der Performance zugute, weil Lese- und Schreibzugriffe parallel stattfinden können. Wie bei der Replikationsrichtlinie wirkt sich eine Änderung der Verteilungsrichtlinie auf Volume-Ebene nur auf neu angelegte Dateien aus; eine Umverteilung von Daten existierender Dateien findet nicht statt.

Daten schwärmen aus

XtreemFS nimmt für sich in Anspruch, auch über große Entfernungen und mit schmalbrüstigen Netzverbindungen zu funktionieren. Das setzt allerdings voraus, dass der Administrator die OSD-Auswahl für die Datenablage konfigurieren kann. Die Selektion von OSDs findet sowohl beim Anlegen neuer Dateien als auch beim Hinzufügen von Kopien statt. Obwohl beide Aufgaben einander ähneln, unterscheidet XtreemFS zwischen OSD-Auswahlrichtlinien und Replik-Auswahlrichtlinien, die beide auf Volume-Ebene zu konfigurieren sind.

Es gibt drei Kategorien von Richtlinien, die sich miteinander kombinieren lassen: Filter, Gruppierer und Sortierer. Filter erwarten als Eingabe eine Liste von OSDs und wählen anhand vorgegebener Merkmale eine oder mehrere davon aus. Mögliche Auswahlkriterien sind die Verfügbarkeit – Antwortzeit oder freie Kapazität – Domainnamen, IP-Adressen und Entfernungen. Gruppierer hingegen selektieren eine bestimmte Untermenge aus einer vorgegebenen Liste. Sortierer ändern lediglich die Reihenfolge der OSDs in einer Liste.

Intern verwendet XtreemFS UUIDs (Universally Unique Identifier) zur Adressierung und Verwaltung der registrierten Dienste. Für MRC und OSD ist die Erzeugung dieser eindeutigen Zeichenketten Bestandteil der XtreemFS-Installation. Sie ist im Klartext in den Konfigurationsdateien abgelegt. Eine nachträgliche Änderung ist nur bedingt möglich und erfordert ein Wartungsfenster der entsprechenden Dienste. Jeder UUID entspricht einem sogenannten Service-Endpoint, der aus einer IP-Adresse und einem Port besteht. Dennoch erfordert die Änderung von IP-Adresse oder -Port keine Änderung der UUID. XtreemFS-Volumes erhalten beim Anlegen automatisch eine eindeutige UUID. In späteren Releases wollen die XtreemFS-Entwickler die Gültigkeit von UUIDs durch die Verwendung von Netzmasken auf bestimmte IP-Bereiche einschränken. Dies würde prinzipiell die Verwendung identischer Identifier in unterschiedlichen Netzen gestatten. Zurzeit müssen alle UUIDs im gesamten Netzwerk eindeutig sein.

Einen Überblick über die XtreemFS-Konfiguration bieten die eingebauten Web-Schnittstellen der DIR-, MRC- und OSD-Server. Entgegen der Dokumentation ist es jedoch momentan nicht möglich, das Dateisystem mit dem Browser zu konfigurieren.

Fazit

Mehr Infos

iX-Tract

• XtreemFS entstand als Unterbau für das Grid-Dateisystem XtreemOS, lässt sich jedoch auch unabhängig davon einsetzen.
• Das Dateisystem verwendet Object-based Storage Devices (OSD) als Datenspeicher und bewahrt Metadaten getrennt auf.
• Die Kommunikation zwischen Server und Client sowie zwischen den beteiligten Diensten lässt sich per SSL verschlüsseln und soll auch über größere Entfernung funktionieren.

XtreemFS hat sich hohe Ziele gesetzt. Von der Unterstützung vieler Plattformen ist momentan aber nicht viel zu sehen. Die HA-Mechanismen weisen Kinderkrankheiten auf und auch das Housekeeping des Dateisystems lässt noch zu wünschen übrig. Auf der Habenseite stehen einfach zu konfigurierende Replikations- und Verteilungsrichtlinien für die Daten, die Absicherung über SSL und die flexible Authentifizierung. Alles in allem verfügt XtreemFS jedoch über vielversprechende Ansätze, deren Umsetzung man in Version 1.4 oder 2.0 gern sehen würde.

Dr. Udo Seidel

leitet eine Unix/Linux-Sysadmin-Gruppe bei der Amadeus Data Processing GmbH in Erding.

Alle Links: www.ix.de/ix1203110 (mr)