Was genau macht eigentlich ein verteiltes Dateisystem?

0
37
Dateisystem
Photo by Twitter: @jankolario on Unsplash

Mit zunehmender Datenmenge in Unternehmen ist die IT-Abteilung mehr und mehr mit der Herausforderung konfrontiert, die Menge an Daten schnell und zuverlässig zu speichern. Daten sollen so abgelegt werden, dass sie schnell wieder gefunden werden können. Herkömmliche Storage- und Dateisysteme stoßen dabei durchaus an Grenzen. Eine mögliche Abhilfe sind sogenannte verteilte Dateisysteme bzw. Distributed Filesystems. Im nachfolgenden Artikel stellt der Autor diese Art Dateisysteme vor. Er erläutert die grundsätzliche Funktionsweise und geht auf  Vor- und Nachteile von verteilten Dateisystemen ein.

GRUNDSÄTZLICHES

Wesentliches Merkmal von verteilten Dateisystemen ist die räumliche Trennung von Nutzdaten und Metadaten. Verteilte Dateisysteme haben mindestens einen, üblich aber mehrere Storage-Nodes. Das sind Server mit Zugriff auf Fesplatten. Die Platten können lokal im Server eingebaut sein, oder als Block-Device aus einem SAN kommen. Ein RAID je Server ist möglich, aber i. d. R. nicht erforderlich, wie wir später noch sehen werden.

Zusätzlich muss es einen Dienst für die Verwaltung der Metadaten geben. Das ist normalerweise ein eigener Server mit eigenen Platten im Zugriff. Auch diese Platten können lokal im Server verbaut sein oder als Blockdevice aus einem SAN kommen. Um zuverlässigen Zugriff auf die Metadaten eines Dateisystems zu haben, sollte der Metadaten-Service redundant über zwei oder mehr Metadata-Server konfiguriert werden.

Wie Nutzdaten auf die einzelnen Storage-Nodes abgelegt werden, wird im Metadaten-Service konfiguriert. Beeinflussende Parameter sind erforderliche Zugriffsgeschwindigkeit, typische Dateigröße, gewünschte oder erforderliche Ausfallsicherheit u. ä. Besonders große Dateien können z. B. in gleich große Stücke geschnitten und auf verschiedene Storage-Nodes verteilt werden, um Dateien so besonders schnell auf Platte schreiben zu können (Slices). Dateien können in mehrfachen Kopien auf Storage-Nodes verteilt werden, um die Ausfallsicherheit zu erhöhen. Beide Optionen — Slices und Redundanz — können kombiniert werden. Konfiguriert man die Redundanz so, dass Kopien in verschiedenen Rechenzentren geschrieben werden, kann man damit auch vergleichsweise einfach Geo-Redundanz abbilden.

Manche Dateisysteme haben zusätzlich einen oder mehrere Management-Nodes, die für den Betrieb eines verteilten Dateisystems nicht unbedingt erforderlich sind. Sie helfen aber insbesondere in großen komplexen Umgebungen, den Überblick zu behalten. Die nachfolgende Abbildung zeigt schematisch den Aufbau eines verteilten Dateisystems. Einzelne Hersteller unterscheiden sich in Features, wie einfach oder komplex die Konfiguration ist, und wie ein Dateisystem im Fehlerfall reagiert. Das grundlegende Prinzip — Trennung von Nutzdaten und Metadaten — ist bei allen Produkten gleich.

Für viele verteilte Dateisysteme gilt: Storage-Node und Storage-Client muss mit dem selben Betriebssystem laufen. Es gibt aber auch Produkte, die Client-Treiber für alle gängigen Betriebssysteme mitbringen. Ein Mischbetrieb auf Client-Seite ist damit möglich. Ein Storage-Client kann auch Server sein, der die Storage-Kapazität z. B. per NFS oder CIFS an Workstations weitergibt. Es ist aber nicht unüblich, Workstations direkt an das verteilte Dateisystem anzubinden, vor allem wenn eine besonders hohe Performance beim Zugriff auf einzelne Dateien gefordert ist. Häufig sieht man solche Konstellationen dort, wo viele große Bild- oder Videodateien verarbeitet werden müssen.
Zwischen den Storage-Clients und den Storage-Nodes muss es Netzwerk-Infrastruktur geben. Viele moderne verteilte Dateisysteme können hier mit unterschiedlichen Protokollen arbeiten:

  • TCP/IP
  • Fiber Channel
  • Infiniband

sind die gebräuchlichen. Manche Dateisysteme sind festgelegt auf ein oder zwei Protokolle. Andere sind schon von Anfang an so flexibel programmiert, dass sie agnostisch gegenüber den darunterliegenden Transportschichten sind.

WIE FUNKTIONIERT’S?

Wie kommen jetzt Daten in das Dateisystem und wieder heraus? Wir nehmen an, ein Storage-Client will eine neue Datei in ein verteiltes Dateisystem schreiben. Dazu kontaktiert der Client zunächst den Metadaten-Server mit einer entsprechenden Anfrage. In der Anfrage enthalten sind die Metadaten der Datei: Name, Eigentümer, Größe, Zugriffsrechte etc. Abhängig von der Konfiguration bekommt der Client vom Metadata-Service jetzt Anweisungen: in wie große und/oder wie viele Stücke die Datei aufzuteilen ist, und welches Stück auf welchen Storage-Node zu schreiben ist. Anschließend kontaktiert der Storage-Client direkt die entsprechenden Storage-Nodes, und übermittelt das jeweilige Stückchen Daten.

Will ein Client eine Datei lesen, erfolgt auch wieder zunächst eine Anfrage auf den Metadata-Service nach der Datei. Der Metadaten-Service gibt Auskunft, welche Stückchen der Datei auf welchen Storage-Nodes liegen. Sind die Stückchen redundant abgelegt, bekommt der Client auch den Ort aller Kopien genannt. Anschließend kontaktiert der Storage-Client alle erforderlichen Storage-Nodes, um die komplette Datei lesen zu können.

ALLES GUT, ODER HAT DIE SACHE AUCH EINEN HAKEN?

Zunächst bringt ein verteiltes Dateisystem eine Menge Vorteile, insbesondere im täglichen Betrieb und Umgang mit großen Datenmengen. Durch den parallelen Zugriff auf mehrere Storage-Nodes gleichzeitig ist die Gesamtbandbreite und IOPS des gesamten Dateisystems entsprechend hoch. Verteilte Dateisysteme skalieren i. d. R. nahezu linear über die Anzahl aktiver Storage-Nodes. Je nach Hersteller ist das Hinzufügen neuer Storage-Nodes extrem einfach oder sogar (fast) automatisiert. Wenn also mehr Kapazität oder mehr Bandbreite gebraucht wird, kann die IT-Abteilung das schnell zur Verfügung stellen.

Werden neue Storage-Nodes zu einem bestehenden Dateisystem hinzugefügt, kann eine automatische Neuverteilung aller Daten-Chunks erfolgen, so dass nach einer bestimmten Zeit alle Storage-Nodes gleichmäßig belegt sind und darauf dann auch statistisch gleichmäßig zugegriffen wird. Redundanz über Storage-Nodes wird bei modernen verteilten Dateisystemen über sogenanntes Erasure Coding sichergestellt. Das sind mathematische Verfahren, die deutlich mehr Spielarten der Redundanz zulassen, als das von RAID-Levels bekannt ist.

Durch die Möglichkeit, ein verteiltes Dateisystem flexibel zu erweitern, ist auch eine Migration auf neue Storage-Hardware vergleichsweise einfach. Man bringt das neue Storage als Erweiterung in der Gesamtsystem, und migriert die Daten dann — im Hintergrund — von den alten Systemen weg. Wenn diese schließlich leer sind, werden sie bei laufendem Betrieb aus der Konfiguration entfernt.

Auf der Contra-Seite bleibt zu erwähnen, dass verteilte Dateisysteme natürlich komplexer sind, als herkömmliches Storage. Damit steigt vor allem in der Einführungsphase der Aufwand zur Administration. Später kann der Betreuungsaufwand gegenüber herkömmlichen Storage-Systemen sogar sinken. Bei unkluger Wahl des Redundanz-Algorithmus kommt es bei Restore eines einzelnen Storage-Nodes außerdem zu einer sog. Write Amplification: Je nach dem, wie die Daten bei einem solchen Restore gemäß Konfiguration neu verteilt werden müssen, wird auf viele Storage-Nodes gleichzeitig geschrieben, was für die Dauer des Restores die Gesamtperformance empfindlich beeinträchtigen kann.

Dieser Artikel erschien im Original am 03. März 2017 im Boston-Blog.

HINTERLASSEN SIE EINE ANTWORT

Please enter your comment!
Please enter your name here