WISSEN > GLOBAL FILESYSTEM -> WAS IST EIN GLOBAL FILESYSTEM
Grundlegene Beschreibung eines globalen Filesystems.
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ist ein globales Filesystem?
Das sollten Sie mitnehmen:
- Global Namespace ≠ Global File System
Ein gemeinsamer Dateipfad allein macht noch kein Global File System.
- Global verfügbar ≠ überall gespeichert
Logische Verfügbarkeit sagt zunächst nichts darüber aus, wo Daten physisch gespeichert oder repliziert werden.
- Ein Global File System beseitigt WAN-Latenz nicht
Lokale File Services und Caching können Remote-I/O reduzieren; die Netzwerklatenz selbst bleibt bestehen.
- Datenlokalität erfordert Konsistenzmechanismen
Sobald Dateien an mehreren Standorten lokal verarbeitet werden können, muss die Architektur Änderungen und konkurrierende Zugriffe koordinieren.
- Das Verhalten im Fehlerfall gehört zur Architektur
Ob ein Standort bei WAN-Ausfall lesen oder schreiben kann und wie Änderungen anschließend behandelt werden, ist eine zentrale Eigenschaft der jeweiligen Implementierung.
Inhaltsverzeichnis
- Vom lokalen File System zum globalen Namespace
- Global Namespace und Global File System
- Wie funktioniert ein Global File System?
- Warum geografische Verteilung schwierig ist
- Lokales Caching und Datenlokalität
- Konsistenz in einer verteilten File-Architektur
- Was geschieht bei einem WAN-Ausfall?
- Global bedeutet nicht vollständige Replikation
- Unterschied zu einem klassischen NAS
- Global File System und Distributed File System
- Welche Probleme adressiert ein Global File System?
- Welche technischen Fragen sollte man stellen?
- Fazit
- Quellen
Ein Global File System stellt Dateien und Verzeichnisse über mehrere physische Systeme oder Standorte hinweg in einer gemeinsamen logischen Dateistruktur bereit. Benutzer und Anwendungen können dadurch auf Dateien zugreifen, ohne dass der physische Speicherort unmittelbar aus dem verwendeten Dateipfad hervorgehen muss.
Das grundlegende Architekturprinzip besteht in der Trennung zwischen logischem Dateizugriff und physischem Speicherort. Ein Dateipfad beschreibt damit nicht zwingend, auf welchem konkreten File Server oder Storage-System die zugehörigen Daten gespeichert sind.
Diese Abstraktion ist insbesondere für Unternehmen relevant, deren Benutzer und Daten auf mehrere Standorte, Rechenzentren oder Cloud-Umgebungen verteilt sind.
Vom lokalen File System zum globalen Namespace
Bei einem klassischen File Server sind Namespace und Datenhaltung eng miteinander verbunden. Ein Benutzer greift beispielsweise auf eine SMB-Freigabe eines bestimmten Servers zu:
\\fileserver-muc\projects
Der Servername ist Bestandteil des Zugriffspfades. Wird die Datenhaltung auf einen anderen Server verschoben, kann sich deshalb auch der Zugriffspfad ändern.
Eine verteilte Namespace-Architektur löst diese feste Zuordnung auf. Ein logischer Pfad kann beispielsweise lauten:
\\company\files\projects
Welche Systeme die Daten tatsächlich bereitstellen, wird durch eine zusätzliche Abstraktionsschicht bestimmt.
Dass dieses Prinzip nicht an ein bestimmtes Produkt gebunden ist, zeigt NFSv4.1. RFC 8881 beschreibt sogenannte Multi-Server Namespaces. Dabei können File Systems verschiedener Server Bestandteil eines übergeordneten Namespace sein. Die Spezifikation nennt ausdrücklich die Trennung der logischen Position eines File Systems innerhalb des Namespace von seinem tatsächlichen Standort auf einem bestimmten Server als Vorteil dieses Ansatzes.
Global Namespace und Global File System
Die Begriffe Global Namespace und Global File System sollten nicht gleichgesetzt werden.
Ein Global Namespace löst zunächst ein Namens- und Adressierungsproblem. Er kann unterschiedliche File-Ressourcen unter einer gemeinsamen hierarchischen Struktur zusammenfassen.
Ein vereinfachtes Beispiel:
Microsoft DFS Namespaces ist ein Beispiel für dieses Prinzip. Microsoft beschreibt DFS Namespaces als Möglichkeit, freigegebene Ordner auf unterschiedlichen Servern in logisch strukturierten Namespaces zusammenzufassen. Benutzer erhalten dadurch eine virtuelle Sicht auf die Freigaben und können über einen gemeinsamen Pfad auf Daten verschiedener Server zugreifen.
Ein Namespace beantwortet damit im Wesentlichen die Frage:
Unter welchem logischen Pfad ist eine Datei erreichbar?
Für ein umfassenderes Global File System kommen weitere Fragestellungen hinzu:
- Wo befinden sich die eigentlichen Dateidaten?
- Wie wird ein Client zu diesen Daten geführt?
- Werden Daten repliziert oder lokal zwischengespeichert?
- Wie werden Änderungen zwischen Standorten koordiniert?
- Wie werden konkurrierende Zugriffe behandelt?
- Was geschieht bei einer WAN-Unterbrechung?
- Welche Komponenten müssen für einen Dateizugriff verfügbar sein?
Ein Global Namespace ist daher eine wichtige Grundlage einer globalen File-Architektur, beschreibt aber noch nicht deren vollständiges Verhalten.
Wie funktioniert ein Global File System?
Die konkrete Implementierung unterscheidet sich zwischen verschiedenen Architekturen. Abstrakt lassen sich jedoch mehrere funktionale Ebenen unterscheiden:
1. Namespace
Der Namespace stellt die logische Sicht auf Dateien und Verzeichnisse bereit.
Beispielsweise:
\\company\files\engineering\project-a
Dieser Pfad kann stabil bleiben, obwohl sich die zugrunde liegende physische Datenhaltung verändert.
NFSv4.1 beschreibt mit Referrals einen Mechanismus, mit dem ein Namespace-Eintrag auf ein File System eines anderen Servers verweisen kann. Der Client kann dadurch seine logische Position innerhalb des Namespace beibehalten, obwohl der tatsächliche Zugriff über einen anderen Server erfolgt.
2. File Services
Der globale Namespace ersetzt nicht die eigentlichen File Services.
Clients müssen Dateien weiterhin über entsprechende Protokolle und Dienste öffnen, lesen, verändern und schließen. Je nach Architektur können beispielsweise SMB- oder NFS-basierte File Services eingesetzt werden.
Das Zugriffsprotokoll und der globale Namespace erfüllen dabei unterschiedliche Aufgaben:
File-Protokoll: Wie greift ein Client auf Dateien zu?
Namespace: Unter welchem logischen Pfad findet der Client die Datei?
Datenarchitektur: Wo liegen die Daten tatsächlich und wie werden sie bereitgestellt?
Diese Ebenen sollten bei der Bewertung einer Global-File-System-Architektur getrennt betrachtet werden.
Daten und Metadaten
Eine globale File-Architektur benötigt Informationen darüber, welche Dateien und Verzeichnisse existieren und wo bzw. wie die zugehörigen Daten erreichbar sind.
Dabei muss zwischen Metadaten und Dateidaten unterschieden werden.
Metadaten beschreiben Eigenschaften und Strukturen des Dateisystems. Die eigentlichen Nutzdaten bilden dagegen den Inhalt der Dateien.
Je nach Implementierung können diese Informationen unterschiedlich verteilt werden. Deshalb gehört zu den zentralen Architekturfragen eines Global File Systems:
Welche Informationen müssen global koordiniert werden und welche können lokal verwaltet werden?
Diese Entscheidung beeinflusst unter anderem Skalierbarkeit, Verfügbarkeit, Konsistenz und das Verhalten bei Netzwerkstörungen.
Warum geografische Verteilung schwierig ist
Ein gemeinsamer Namespace macht eine Datei logisch global erreichbar. Er beseitigt jedoch nicht die physikalischen Auswirkungen geografischer Entfernung.
Liegt ein Client in München und das angesprochene Storage-System in New York, muss die Kommunikation weiterhin das Wide Area Network durchlaufen.
Vereinfacht:
Für Anwendungen ist dabei nicht nur die verfügbare Bandbreite relevant. Auch die Round-Trip-Time (RTT) zwischen Client und entferntem System beeinflusst Workloads, die mehrere sequenziell voneinander abhängige Netzwerkoperationen benötigen.
Ein Global File System kann diese physikalische Latenz nicht beseitigen.
Eine mögliche Architekturstrategie besteht deshalb darin, Daten näher an den Clients bereitzustellen.
Lokales Caching und Datenlokalität
Global-File-System-Architekturen können lokale File Services oder Caches einsetzen. Häufig benötigte Daten werden dann näher am jeweiligen Standort bereitgestellt.
Der Datenpfad verändert sich damit grundsätzlich:
Ein Cache kann Remote-Zugriffe vermeiden, wenn die benötigten Daten lokal vorhanden und verwendbar sind.
Damit entsteht jedoch unmittelbar ein neues Problem:
Wie wird sichergestellt, dass der lokale Zustand mit dem maßgeblichen Zustand des Gesamtsystems vereinbar ist?
Caching und Konsistenz müssen deshalb gemeinsam betrachtet werden.
Konsistenz in einer verteilten File-Architektur
Angenommen, dieselbe logische Datei ist an zwei Standorten verfügbar:
Wenn beide Standorte Änderungen durchführen können, muss die Architektur festlegen, wie diese Zugriffe koordiniert werden.
Das betrifft beispielsweise Fragen wie:
- Können mehrere Standorte gleichzeitig schreiben?
- Wie werden File Locks behandelt?
- Wann werden Änderungen an anderen Standorten sichtbar?
- Wie werden lokale Caches invalidiert oder aktualisiert?
- Was passiert bei gleichzeitig vorgenommenen Änderungen?
- Was geschieht während einer Netzwerkunterbrechung?
Für diese Fragen existiert keine allgemeingültige Antwort für alle Global File Systems. Sie sind Eigenschaften der jeweiligen Implementierung.
Das verwendete Konsistenzmodell ist deshalb ein wesentliches technisches Bewertungskriterium.
Was geschieht bei einem WAN-Ausfall?
Eine weitere zentrale Frage betrifft Netzwerkpartitionen.
Angenommen, ein Standort verliert die Verbindung zur übergeordneten Infrastruktur:
Das Verhalten hängt von der Architektur ab.
Ein System könnte beispielsweise weiterhin lesenden Zugriff auf lokal vorhandene Daten ermöglichen. Eine andere Architektur könnte bestimmte Schreiboperationen zulassen. Wieder eine andere könnte Zugriffe blockieren, wenn die notwendige Koordination mit anderen Komponenten nicht mehr möglich ist.
Dabei entsteht ein grundlegender Trade-off verteilter Systeme:
Lokale Verfügbarkeit, globale Konsistenz und das Verhalten bei Netzwerkpartitionen müssen gemeinsam betrachtet werden.
Deshalb sollte bei einer technischen Bewertung immer untersucht werden, welche Operationen bei einer WAN-Unterbrechung tatsächlich möglich sind und wie das System nach Wiederherstellung der Verbindung mit zwischenzeitlichen Änderungen umgeht.
Global bedeutet nicht vollständige Replikation
Ein häufiges Missverständnis besteht darin, globale Verfügbarkeit mit vollständiger Datenreplikation gleichzusetzen.
Dass eine Datei über einen globalen Namespace an mehreren Standorten erreichbar ist, bedeutet nicht automatisch, dass an jedem Standort eine vollständige persistente Kopie dieser Datei vorhanden ist.
Mehrere Ebenen müssen getrennt betrachtet werden:
Eine Architektur kann beispielsweise einen globalen Namespace besitzen, während Daten nur an ausgewählten Orten persistent gespeichert werden.
Eine andere Architektur kann Daten replizieren.
Eine weitere kann eine übergeordnete persistente Datenhaltung mit lokalen Caches kombinieren.
Global File System bezeichnet deshalb nicht automatisch eine bestimmte Methode der Datenplatzierung.
Unterschied zu einem klassischen NAS
Ein klassisches Network Attached Storage (NAS) und ein Global File System sind keine direkten Gegensätze.
Ein NAS stellt File Services über Netzwerkprotokolle wie SMB oder NFS bereit. Für lokale oder zentralisierte Workloads kann dies eine geeignete Architektur sein.
Problematischer wird eine ausschließlich standortbezogene Architektur, wenn viele unabhängige Systeme entstehen:
Die logische Datenstruktur entspricht dann häufig der physischen Infrastruktur.
Eine globale File-Architektur kann diese Zuordnung abstrahieren:
Der entscheidende Unterschied liegt damit weniger im verwendeten File-Protokoll als in der Abstraktion und Koordination der verteilten File-Infrastruktur.
Global File System und Distributed File System
Auch die Begriffe Distributed File System und Global File System werden nicht immer einheitlich verwendet.
Ein Distributed File System verteilt Funktionen oder Daten eines Dateisystems auf mehrere vernetzte Systeme. Ein Global File System kann als spezielle Ausprägung einer solchen verteilten File-Architektur verstanden werden, bei der insbesondere ein standort- bzw. systemübergreifender logischer Zugriff auf Dateien im Mittelpunkt steht.
Aus dem Begriff allein sollte jedoch nicht auf konkrete Eigenschaften geschlossen werden.
Ob eine Lösung beispielsweise
- Daten repliziert,
- lokale Caches verwendet,
- offline arbeiten kann,
- Active-Active-Schreibzugriffe unterstützt oder
- bestimmte Konsistenzgarantien bietet,
muss anhand ihrer konkreten Architektur und Dokumentation geprüft werden.
Welche Probleme adressiert ein Global File System?
Ein Global File System wird vor allem dann architektonisch interessant, wenn Benutzer, Anwendungen und Daten geografisch verteilt sind, die Dateiumgebung aber nicht entsprechend fragmentiert werden soll.
Typische Anforderungen sind:
- ein gemeinsamer logischer Namespace,
- standortübergreifender Dateizugriff,
- Entkopplung des Dateipfades vom physischen Storage,
- Verlagerung von Daten ohne Änderung logischer Zugriffspfade,
- lokale File Services innerhalb einer übergeordneten Datenarchitektur,
- Reduzierung voneinander unabhängiger File-Storage-Silos.
Ob eine konkrete Lösung diese Anforderungen erfüllt, lässt sich allerdings nicht aus der Produktbezeichnung „Global File System“ ableiten.
Welche technischen Fragen sollte man stellen?
Bei der Bewertung einer Global-File-System-Architektur sind insbesondere sechs Fragen entscheidend:
1. Namespace:
Wie wird der globale Namespace aufgebaut und verwaltet?
2. Metadaten:
Wo befinden sich die für den Dateizugriff erforderlichen Metadaten und wie werden sie koordiniert?
3. Daten:
Wo werden die eigentlichen Dateidaten persistent gespeichert?
4. Datenlokalität:
Welche Daten werden repliziert oder gecacht und nach welchen Regeln?
5. Konsistenz:
Wie behandelt das System konkurrierende Zugriffe und Änderungen von mehreren Standorten?
6. Failure Handling:
Was geschieht bei Ausfall eines File Service, eines Storage-Systems, eines Standortes oder der WAN-Verbindung?
Erst die Antworten auf diese Fragen beschreiben die tatsächliche technische Architektur.
Fazit
Ein Global File System ist mehr als ein gemeinsames Verzeichnis für mehrere Standorte. Das zentrale Architekturprinzip besteht darin, den logischen Zugriff auf Dateien von deren physischer Bereitstellung zu abstrahieren.
Ein globaler Namespace bildet dafür eine wesentliche Grundlage. NFSv4.1 zeigt mit seinen Multi-Server-Namespaces und Referrals standardisiert, wie die logische Position eines File Systems von seinem tatsächlichen Serverstandort getrennt werden kann. Microsoft DFS Namespaces zeigt ein ähnliches Grundprinzip für Windows File Services: Freigaben unterschiedlicher Server werden in einer gemeinsamen logischen Struktur zusammengeführt.
Ein Namespace allein löst jedoch weder WAN-Latenz noch Datenlokalität, Konsistenz oder Failure Handling.
Für die technische Bewertung eines Global File Systems sind deshalb nicht die Bezeichnung oder der gemeinsame Dateipfad entscheidend, sondern die darunterliegenden Mechanismen:
Wo liegen Daten und Metadaten? Wie werden sie gefunden? Welche Zugriffe erfolgen lokal? Wie werden Änderungen koordiniert? Und was passiert, wenn Teile der verteilten Infrastruktur nicht erreichbar sind?
Diese Fragen bestimmen, wie ein Global File System unter realen Betriebsbedingungen tatsächlich funktioniert.
Quellen
- IETF / Noveck, D.; Lever, C.: RFC 8881 – Network File System (NFS) Version 4 Minor Version 1 Protocol. Internet Standards Track, August 2020. Insbesondere Abschnitt 11 „Multi-Server Namespace“ und 11.5.6 „Referrals“.
- Microsoft: DFS Namespaces overview in Windows Server. Microsoft Learn. Gültig für Windows Server 2016, 2019, 2022 und 2025. Stand der Dokumentation: 2025.
- Microsoft: [MS-DFSNM]: Distributed File System (DFS): Namespace Management Protocol. Microsoft Open Specifications.
- Microsoft: [MS-DFSC]: Distributed File System (DFS): Referral Protocol. Microsoft Open Specifications.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
