- Google File System
-
Das Google File System (GFS) ist ein proprietäres, auf Linux basierendes verteiltes Dateisystem, das Google für seine Anwendungen benutzt. Es ist für Googles Internetsuche optimiert. Die Daten sind bleibend in teilweise mehrere Gigabyte großen Dateien gespeichert, die selten gelöscht, überschrieben oder verkleinert werden. Auch ist es für hohe Datendurchsätze optimiert.
Aufbau
Das Google File System ist an die notwendigen Anforderungen der Websuche angepasst, die eine enorme Menge an zu speichernden Daten generiert. GFS entstand aus einem früheren Versuch Googles, welcher den Namen „BigFiles“ trägt und von Larry Page sowie Sergei Brin während ihrer Forschungstätigkeit an der Stanford-Universität entwickelt wurde.
Die Daten werden durchgehend in sehr großen, teilweise sogar mehrere Gigabyte großen Dateien gespeichert, welche nur in extrem seltenen Fällen gelöscht, überschrieben oder komprimiert werden; Daten werden üblicherweise angehängt oder ausgelesen. Das Dateisystem ist auch entworfen und optimiert worden, um auf Googles rechnenden Clustern laufen zu können, deren Netzknoten aus handelsüblichen PCs bestehen. Dies bedeutet allerdings auch, dass man die hohe Ausfallrate und den damit verbundenen Datenverlust individueller Netzknoten als Normalzustand ansehen muss. Das äußert sich auch darin, dass kein Unterschied zwischen normaler (Runterfahren) und abnormaler Beendigung (Absturz) gemacht wird: Serverprozesse werden standardmäßig per Killbefehl beendet. Andere Designentscheidungen setzen auf hohe Datendurchsatzraten, auch wenn dies auf Kosten der Latenzzeit geht.
Ein GFS Cluster besteht aus einem Master und hunderten oder tausenden Chunkservern. Die Chunkserver speichern die Dateien, wobei jede Datei in 64 MB große Stücke („Chunks“) gespalten ist, ähnlich Clustern oder Sektoren in gebräuchlichen Dateisystemen.
Um Datenverlust zu verhindern, wird jede Datei beim GFS standardmäßig mindestens dreimal pro Cluster gespeichert. Bei Ausfall eines Chunkservers treten nur verschwindend geringe Verzögerungen auf, bis die Datei wieder ihre Standardanzahl an Replika besitzt. Je nach Bedarf kann die Anzahl auch höher liegen, etwa bei ausführbaren Dateien. Jedem Chunk wird eine eindeutige, 64 Bit lange Kennzeichnung zugewiesen, logische Mappings der Dateien zu den einzelnen Chunks werden beibehalten.
Der Master dagegen speichert keine Chunks, sondern vielmehr deren Metadaten, wie etwa Dateinamen, Dateigrößen, ihren Speicherort sowie den ihrer Kopien, welche Prozesse gerade auf welchen Chunk zugreifen etc. Die Master erhalten jegliche Anfragen für eine Datei und liefern als Antwort die dazugehörigen Chunkserver und erteilen entsprechende Sperren an den Prozess. Ein Client darf allerdings für gewisse Zeit die Adresse der Chunkserver cachen. Fällt die Anzahl an verfügbaren Replika unter die Normzahl, sind es auch die Master, die die Erstellung einer neuen Chunkkopie anstoßen. Die Metadaten werden aktuell gehalten, indem die Master regelmäßig Aktualisierungsanfragen an die Chunkserver senden („heart-beat messages“, auf deutsch etwa: „Herzschlag-Nachrichten“).
Der Quelltext des GFS sieht nur einen Master pro Cluster vor. Dies hat den Anschein, ein Fehler im System zu sein, die dessen Skalierbarkeit und Zuverlässigkeit begrenzt, da die maximale Größe und Uptime von der Leistungsfähigkeit und Uptime des Masters abhängt, da dieser die Metadaten katalogisiert und fast alle Anfragen durch ihn laufen; Googles Techniker haben allerdings durch Messungen gezeigt, dass dies (zumindest bis jetzt) nicht der Fall und GFS sehr wohl skalierbar ist. Der Master ist im Normalfall der leistungsfähigste Netzknoten im Netzwerk. Um die Ausfallsicherheit sicherzustellen, gibt es mehrere „Schatten-Master“, die den Hauptrechner spiegeln und notfalls, sollte der Master einmal ausfallen, sofort einspringen. Zusätzlich stehen die Schattenmaster auch für reine Leseanfragen, die ja den Haupttraffic ausmachen, zur Verfügung, so dass sich die Skalierbarkeit dadurch weiter erhöht. Engstellen gibt es nur selten, da Clients nur nach Metadaten fragen, die komplett im Arbeitsspeicher als B-Baum vorgehalten werden – sie sind sehr kompakt, pro Megabyte Daten fallen lediglich einige Kilobyte an. Durch den Einsatz nur eines Hauptknotens verringert sich die Softwarekomplexität drastisch, da Schreiboperationen nicht koordiniert werden müssen.
Siehe auch
Weblinks
Kategorien:- Dateisystem
- Netzwerkarchitektur
- Linux-Software
Wikimedia Foundation.
