Das Dateisystem "Lustre". Architektur, Funktionen, Verwendung, aktuelle Forschung

INHALT

1. Einleitung
1.1 Motivation
1.1 Das Projekt Lustre

2. Architektur
2.1 Clients
2.2 Management Server / Management Target
2.3 Metadata Server / Metadata Target
2.4 Object Storage Server / Object storage Target
2.5 Object Storage Devices
2.6 Lustre Networking (LNET)
2.7 Konfiguration

3. Funktionen
3.1 Failover
3.2 Striping

4. Verwendung

5. Aktuelle Forschung

6. Fazit

Quellenverzeichnis

1. EINLEITUNG

Der Name Lustre ist eine Zusammensetzung aus Linux und Cluster. Lustre beschreibt ein paralleles, verteiltes Dateisystem, welches für Linux-Systeme entwickelt wurde und speziell in Cluster-Computing-Umgeben eingesetzt wird. Diese setzen voraus, dass sehr viele Clients (100.000+)¹ auf einen Shared-Storage zugreifen können und, dass das Dateisystem auch bei hoher Auslastung verlässlich arbeitet. Lustre ist, wie es für Dateisysteme, welche unter Linux verwendet werden, üblich ist, POSIX-konform, wodurch es eine standardisierte Schnittstelle anbieten kann, welche nicht extra für jedes Betriebssystem angepasst werden muss. Lustre ist unter der Open-Source-GNU-GPL-Lizenz (Version 2) frei verfügbar und darf bearbeitet und auch wieder veröffentlicht werden.²

1.1 MOTIVATION

Der Anspruch an moderne Dateisysteme wächst immer weiter. Diese müssen immer größere Datenmengen in kürzerer Zeit verarbeiten können. Die Server haben jedoch einen beschränkten Durchsatz und eine beschränkte Kapazität. Lustre will dieses Flaschenhalsproblem, dass sich die Übertragung an einem Server staut, dadurch vermeiden, dass die Daten über mehrere Server verteilt werden. So kann der Durchsatz, also die übertragene Datenmenge in einer bestimmten Zeit deutlich erhöht werden. Wie Lustre dies genau umsetzt, wird im Folgenden erläutert.

1.1 DAS PROJEKT LUSTRE

Lustre wurde 1999 als Forschungsprojekt von Peter J. Braam an der Carnegie Mellon University ins Leben gerufen. Zwei Jahre später gründete er daraus das Unternehmen Cluster File Systems, welches vom US-Energieministerium gefördert wurde. 2007 wurde die Firma von Sun Microsystems aufgekauft, welche das eigene Dateisystem ZFS und ihr Betriebssystem mit Lustre optimieren wollte. Nachdem Sun Microsystems jedoch 2010 von Oracle aufgekauft wurde, wurde die Weiterentwicklung an Lustre eingestellt. Daraufhin setzten verschiedene Gruppen, wie Whamcloud oder Open SFS, die Weiterentwicklung fort, was durch die Open Source Lizenz möglich wurde.2

2. ARCHITEKTUR

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau eines Lustre Dateisystems von wiki.lustre.org 1

Das Lustre-Dateisystem besteht aus Clients, Servern und Speichermedien (Targets). Die Kommunikation erfolgt über das L(ustre)-Net(working). Über dieses sind alle Komponenten miteinander verbunden. Dadurch müssen die Clients nicht mehr direkt mit den Speichermedien kommunizieren, sondern können Anfragen an die jeweiligen Server stellen, welche die Anfragen bearbeiten und das Ergebnis den Clients melden. So muss den Clients der genaue Speicherort der Dateien nicht länger bekannt sein. Es gibt drei verschiedene Server- und Targetarten. Jeweils Management-, Metadata- und Object Storage-Server und Targets. Die Funktionen dieser Server auf denen entsprechende Services laufen, werden im Folgenden weiter erläutert.

2.1 CLIENTS

Lustre ist für eine sehr hohe Anzahl an Clients konzipiert, kann jedoch auch für kleinere Systeme genutzt werden. Die Clients können durch den Global Name Space alle Daten sehen und benötigen keine eigenen Festplatten mehr, da alle Dateien verteilt gespeichert werden. Der Lustre-Client fasst die Meta- und Objektdaten POSIX-konform zusammen, wodurch die Anwendungen, die auf den Rechnern laufen, nicht speziell für Lustre geschrieben werden müssen.

2.2 MANAGEMENT SERVER / MANAGEMENT TARGET

Der Management Service (MGS) stellt die Konfigurationsinformationen über das Netzwerk bereit. Alle Komponenten des Netzwerkes müssen sich bei der ersten Anmeldung bei dem Management Service registrieren, damit die Kommunikation zwischen den verschiedenen Komponenten möglich ist. Ein Lustre-Netz- werk hat nur genau einen Management Server. Die Konfigurationsinformationen werden von dem Management Service auf den Management Targets (MGT) gespeichert, wobei ein Management Service Dateien auf mehreren Management Targets speichern kann. Der Management Service ist nicht an den eigentlichen I/O-Operationen beteiligt. Ein Ausfall des Management Services ist besonders kritisch, da sich dann keine Server oder Clients mehr in dem Netzwerk registrieren könnten.³

2.3 METADATA SERVER / METADATA TARGET

Der Metadata Service (MDS) ist für die Bereitstellung von Metadaten zuständig. Die Metadaten werden in inodes (Index nodes) gespeichert und enthalten Informationen über die Datei, wie den Dateinamen, Zugriffsrechte, Sperren oder Informationen über die Aufteilung in Stripes. Die Sperren sind in verteilten, parallelen Dateisystemen dringend notwendig, um die Kohärenz der Dateien sicherzustellen. Die inodes werden auf Metadata Targets (MDT) gespeichert. Außerdem sind die Metadata Services für das Erstellen und Löschen von Dateien zuständig, da bei diesen Vorgängen Metadaten bearbeitet oder erzeugt werden müssen. Ohne die Metadata Services oder die Metadata Targets ist kein Zugriff auf die Dateien möglich, da der Speicherort nicht ermittelt werden kann. Im Gegensatz zu den Management Services ist die Anzahl der Metadata Services nicht begrenzt.

2.4 OBJECT STORAGE SERVER / OBJECT STORAGE TARGET

Der Object Storage Service (OSS) verwaltet die gespeicherten Dateien. Diese werden auf den Object Storage Targets (OST) gespeichert. Des Weiteren ist der Object Storage Service für I/O-Operationen, also für den lesenden oder schreibenden Zugriff zuständig. Untereinander agieren die Object Storage Server passiv, da die Verteilung der Dateien von den Metadata Services übernommen wird. Dateien werden in Stripes aufgeteilt und auf mehrere Objekte verteilt, dadurch muss eine Datei nicht unbedingt auf einem einzigen Server liegen. Die Kapazität des Netzwerkes lässt sich leicht durch Hinzufügen von Object Storage Targets erhöhen, wodurch die einfache Skalierbarkeit der Lustre Netzwerke realisiert wird. Die Kapazität des Netzwerkes wird durch die Summe der Kapazitäten der einzelnen Object Storage Targets bestimmt. Diese sollten möglichst gleichmäßig auf die Object Storage Server verteilt werden, um eine maximale Performance zu ermöglichen.

2.5 OBJECT STORAGE DEVICES

Die verschiedenen Targets sind Object Storage Device (OSD) Instanzen. Diese können zwei verschiedene Dateisysteme in Lustre installiert haben. Die erste Möglichkeit ist LDISKFS, eine Weiterentwicklung von ext4. Für dieses muss jedoch der Kernel angepasst werden. Die Anzahl der Inodes, welche auf dem Target gespeichert werden können, wird bei der Formatierung des Speichers berechnet. Am Anfang wurde in Lustre nur LDISKFS für die Targets unterstützt. Ab der Version 2.3 von Lustre wurde dann auch das Dateisystem ZFS unterstützt. Für dieses muss der Kernel nicht angepasst werden, jedoch ist die Installation aufwendiger als bei LDISKFS. Die Anzahl der Inodes wird dynamisch berechnet. ZFS ermöglicht die Speicherung von Dateien mit größerer Dateigröße als bei LDISKFS, außerdem kann theoretisch insgesamt eine größere Datenmenge gespeichert werden. Diese ist aber natürlich auch durch die Eigenschaften des Speichermediums begrenzt. Kombinationen von ZFS und LDISKFS sind ebenfalls möglich.2

2.6 LUSTRE NETWORKING (LNET)

LNET dient als API und Kommunikationsprotokoll für Lustre. Es vermittelt zwischen den Clients und den Servern. Dementsprechend müssen alle Clients und Server für LNET konfiguriert sein. LNET unterstützt verschiedene Netzwerktypen, wie Ethernet, Quadrics oder Infiniband. Letzteres ist besonders für hohen Durchsatz ausgelegt. Durch die Verwendung von LNET Routern können mehrere LNET-Netzwerke verbunden werden und Schnittstellen zwischen den verschiedenen Netzwerktypen geschaffen werden.

2.7 KONFIGURATION

Der minimale Aufbau eines Lustre-Netzwerkes besteht aus jeweils einem Paar aus Management Server und -Target, Metadata Server und -Target und Object Storage Server und -Target. Um jedoch eine hohe Verfügbarkeit zu generieren werden der Metadata Server und der Management Server in einer Failover- Kombination verbunden. Failover-Kombinationen stellen eine zentrales Merkmal von Lustre dar, welches ich im nächstes Kapitel weiter erläutern werde. Durch die einfache Skalierbarkeit von Lustre lassen sich problemlos weitere Metadata Server und -Targets und Object Storage Server und -Targets hinzufügen, wodurch die hohe Verfügbarkeit und Kapazität ermöglicht werden können. Bei herkömmlichen Dateisystem könnte durch das Hinzufügen weiterer Server zwar die Verfügbarkeit erhöht werden, aber nicht die Performance des Netzwerkes, da trotzdem nur ein Server auf den Speicher zugreifen könnte, es wird also nur ein zweites Dateisystem erzeugt, anstatt dass der zweite Server den ersten bezogen auf die Performance unterstützt.1

3. FUNKTIONEN

Zwei wesentliche Funktionen von Lustre sind Failover-Konfigurationen und Striping. Beide tragen zu großen Teilen den Hauptversprechen von Lustre bei. Durch sie sollen besonders die hohe Verfügbarkeit aber auch die einfache Ska- lierbarkeit und das Speichern von vielen und großen Daten ermöglicht werden.

3.1 FAILOVER

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufbau von Failoverpaaren von doc.lustre.org [2]

[...]

¹ Lustre; “Introduction to Lustre Architecture”; Oktober 2017: http://wiki.lus- tre.org/images/6/64/LustreArchitecture-v4.pdf

² Wikipedia: https://en.wikipedia.org/wiki/Lustre_(file_system)

³ Lustre; “Introduction to Lustre Architecture”; Oktober 2017: http://wiki.lus- tre.org/images/6/64/LustreArchitecture-v4.pdf