Google-Dateisystem - Google File System

Google-Dateisystem
Betriebssystem Linux Kernel
Art Verteiltes Dateisystem
Lizenz Proprietär

Das Google-Dateisystem ( GFS oder GoogleFS , nicht zu verwechseln mit dem GFS- Linux-Dateisystem) ist ein proprietäres verteiltes Dateisystem, das von Google entwickelt wurde , um einen effizienten und zuverlässigen Zugriff auf Daten mithilfe großer Cluster von Standardhardware zu ermöglichen . Die letzte Version des Google-Dateisystems mit dem Codenamen Colossus wurde 2010 veröffentlicht.

Design

Image
Google File System wurde für die Interaktion von System zu System und nicht für die Interaktion von Benutzer zu System entwickelt. Die Chunk-Server replizieren die Daten automatisch.

GFS wurde für die zentralen Anforderungen von Google an die Speicherung und Nutzung von Daten (hauptsächlich die Suchmaschine ) erweitert, wodurch enorme Datenmengen generiert werden können, die aufbewahrt werden müssen. Das Google-Dateisystem entstand aus einer früheren Google-Initiative, "BigFiles", die von Larry Page und Sergey Brin in den frühen Tagen von Google entwickelt wurde, als es sich noch in Stanford befand . Dateien sind unterteilt in feste Größe Brocken von 64 Megabyte , ähnlich wie Cluster oder Sektoren in regelmäßigen Dateisystemen, die nur äußerst selten überschrieben oder geschrumpfte; Dateien werden normalerweise angehängt oder gelesen. Es wurde auch für die Ausführung auf Googles Computerclustern entwickelt und optimiert, dichten Knoten, die aus billigen "Standard" -Computern bestehen. Dies bedeutet, dass Vorkehrungen gegen die hohe Ausfallrate einzelner Knoten und den nachfolgenden Datenverlust getroffen werden müssen. Andere Entwurfsentscheidungen entscheiden sich für einen hohen Datendurchsatz , selbst wenn dies auf Kosten der Latenz geht .

Ein GFS-Cluster besteht aus mehreren Knoten. Diese Knoten sind in zwei Typen unterteilt: ein Master - Knoten und mehr Chunkservers . Jede Datei ist in Blöcke fester Größe unterteilt. Chunkserver speichern diese Chunks. Jedem Block wird zum Zeitpunkt der Erstellung vom Masterknoten eine global eindeutige 64-Bit-Bezeichnung zugewiesen, und logische Zuordnungen von Dateien zu einzelnen Blöcken werden beibehalten. Jeder Block wird mehrmals im gesamten Netzwerk repliziert. Standardmäßig wird es dreimal repliziert, dies ist jedoch konfigurierbar. Gefragte Dateien haben möglicherweise einen höheren Replikationsfaktor, während Dateien, für die der Anwendungsclient strenge Speicheroptimierungen verwendet, möglicherweise weniger als dreimal repliziert werden, um die Richtlinien für eine schnelle Müllbereinigung zu erfüllen.

Der Master-Server speichert normalerweise nicht die tatsächlichen Chunks, sondern alle den Chunks zugeordneten Metadaten , z. B. die Tabellen, die die 64-Bit-Beschriftungen den Chunk-Speicherorten zuordnen, und die Dateien, aus denen sie bestehen (Zuordnung von Dateien zu Chunks), die Speicherorte von den Kopien der Chunks, welche Prozesse in einen bestimmten Chunk lesen oder schreiben oder einen "Snapshot" des Chunks erstellen, um ihn zu replizieren (normalerweise auf Veranlassung des Master-Servers, wenn aufgrund von Knotenfehlern die Nummer von Kopien eines Blocks ist unter die festgelegte Anzahl gefallen). Alle diese Metadaten werden vom Master-Server auf dem neuesten Stand gehalten und erhalten regelmäßig Updates von jedem Chunk-Server ("Heart-Beat-Nachrichten").

Berechtigungen für Änderungen werden von einem System zeitlich begrenzter, ablaufender "Leases" verwaltet, bei dem der Master-Server einem Prozess für einen begrenzten Zeitraum die Berechtigung erteilt, während der kein anderer Prozess vom Master-Server die Berechtigung zum Ändern des Blocks erhält . Der modifizierende Chunkserver, der immer der primäre Chunk-Inhaber ist, gibt die Änderungen dann mit den Sicherungskopien an die Chunkserver weiter. Die Änderungen werden erst gespeichert, wenn alle Chunkserver dies bestätigen, wodurch der Abschluss und die Atomizität des Vorgangs garantiert werden.

Programme greifen auf die Chunks zu, indem sie zuerst den Master-Server nach den Speicherorten der gewünschten Chunks abfragen. Wenn die Chunks nicht bearbeitet werden (dh es sind keine ausstehenden Leases vorhanden), antwortet der Master mit den Standorten, und das Programm kontaktiert und empfängt die Daten direkt vom Chunkserver (ähnlich wie Kazaa und seine Superknoten ).

Im Gegensatz zu den meisten anderen Dateisystemen wird GFS nicht im Kernel eines Betriebssystems implementiert , sondern als Userspace- Bibliothek bereitgestellt.

Schnittstelle

Das Google-Dateisystem bietet keine POSIX- Schnittstelle. Dateien sind hierarchisch in Verzeichnissen organisiert und durch Pfadnamen gekennzeichnet. Die Dateivorgänge wie Erstellen, Löschen, Öffnen, Schließen, Lesen, Schreiben werden unterstützt. Es unterstützt Record Append, wodurch mehrere Clients Daten gleichzeitig an dieselbe Datei anhängen können und die Atomizität garantiert ist.

Performance

Ausgehend von den Benchmarking-Ergebnissen erzielt das Dateisystem bei Verwendung mit einer relativ geringen Anzahl von Servern (15) eine Leseleistung, die mit der einer einzelnen Festplatte vergleichbar ist (80–100 MB / s), weist jedoch eine verringerte Schreibleistung (30 MB / s) auf ) und ist relativ langsam (5 MB / s) beim Anhängen von Daten an vorhandene Dateien. Die Autoren präsentieren keine Ergebnisse zur zufälligen Suchzeit. Da der Masterknoten nicht direkt am Lesen von Daten beteiligt ist (die Daten werden vom Chunk-Server direkt an den Lese-Client übergeben), steigt die Leserate mit der Anzahl der Chunk-Server erheblich an und erreicht für 342 Knoten 583 MB / s. Das Zusammenfassen mehrerer Server ermöglicht auch eine große Kapazität, während die Speicherung von Daten an drei unabhängigen Standorten (um Redundanz zu gewährleisten) etwas verringert wird.

Siehe auch

Verweise

Literaturverzeichnis

Externe Links