Stor IT Back - Ihr Speicherspezialist
NFS - Network File System V1.3 (c) Stor IT Back 2024
Für eine Client-Server-Architektur müssen Dateien zwischen verschiedenen Clients und zentralen Server ausgetauscht werden. Dabei können sowohl
Server wie auch Client unterschiedliche Betriebssysteme und Filesysteme nutzen. Dafür entwickelte Sun Microsystems (jetzt Oracle) das
NFS Protokoll, anfangs nur für die interne Verwendung zum Datenaustausch in ihrer Unix (Solaris) Umgebung. Erst die Version 2 wurde für Kunden freigegeben.
Beim Network File System werden die Dateien nicht, wie zum Beispiel bei FTP, übertragen, sondern bleiben auf dem Server, ein
sogenanntes verteiltes Dateisystem (Distributed File System).
Im Windows Umfeld entspricht dies SMB bzw. CIFS. Die beiden Protokolle sind aber nicht kompatibel,
nur ähnlich in der Anwendung. Aber auch Microsoft hat in seinen Betriebssystemen NFS implementiert.
Genutzt wird NFS in der gesamten Linux und Unix Welt, nicht nur zwischen Clients und zentralen Servern. Auch Server nutzen NFS Freigaben von anderen Servern, zum Beispiel in
verteilten Webserver-Systemen. Dort liegen an zentraler Stelle die Daten für alle Webserver-Frontends.
NFS wurde mit der Version 1 auf UDP entwickelt, während SMB / CIFS auf TCP beruht. Die Authentifizierung bei den NFS Versionen bis 3
war rein auf den Client beschränkt. Dies bedeutet, das der Export auf dem Server auf bestimmte IP Adresse begrenzt werden kann, nicht aber auf einen User auf diesem Client. Erst ab
der Version NFS v4 ist eine User Authentifizierung möglich.
Aber was ist da der Unterschied? Bei den ersten Versionen von NFS wurden nur IP Adressen für den Zugriff definiert. Dabei konnte zwischen Read Only und
Read / Write unterschieden werden, aber nicht auf den User. Können sich also mehrere User auf einem NFS Client anmelden, so dürfen alle User
den Export auf dem NFS Server nutzen. Na ja, die Berechtigung auf Datei-Ebene gibt es trotzdem, das benötigt aber eine einheitliche User-Struktur
auf allen Systemen. Der User mit der ID 1000 hat Zugriff auf eine Datei auf dem Server, dann muss dieser User auch die ID 1000 auf dem Client haben. Und auf
anderen Clients, die den gleichen Export nutzen, darf es keine ID 1000 für einen anderen User geben (der hätte sonst auch Zugriff auf diese Datei).
Das war früher in zentralen Netzen kein Problem, dafür gibt es die zentrale Userverwaltung NIS. Aber in verteilten Unix und Linux Umgebungen ist dies nicht mehr möglich und
auch nicht mehr kontrollierbar.
In der Version 4 von NFS werden die Unix IDs durch einen echten Nutzer in der Form user1@domaine1.org ersetzt. Damit ist die Unix ID durch eine
dezentrale User Kennung ersetzt worden. Die Domain kennzeichnet die Domaine des Servers und die User-IDs werden auf Unix IDs auf dem Server gemappt. Damit
ist also keine Beziehung der Unix-IDs zwischen Server und Client notwendig. Das gleiche Prinzip wie bei SMB.
Mit NFS v4 fällt auch UDP weg, bzw. die Port-Problematik gerade für Firewalls. Die Kommunikation läuft über TCP, dafür wird der feste Port 2049 genutzt. Also
nur noch ein Port durch die Firewall freigeben.
Weiterhin werden auch Cluster-Umgebungen besser unterstützt. Mit der Version 4.1 sind skalierbare parallele Zugriffe über verteile Server möglich (NFS Multipathing). Mit
der Version 4.2 kommen noch Server-Side Clone and Copy dazu, sowie weitere Verbesserungen in pNFS und Space Reservation.
NFS wird zwischen Linux und Unix Systemen eingesetzt. Zum Beispiel können hiermit die User-Verzeichnisse zentral auf einem Server vorgehalten werden.
Meldet sich der User an einem anderen Client an, dann hat er trotzdem alle seine persönlichen Dateien im Zugriff. In der Windows Umgebung entspricht dies
dem Domänen-Profil eines Users.
Aber nicht nur bei Clients wird NFS eingesetzt, auch im reinen Server Umfeld ist NFS sehr verbreitet in Linux und Unix Systemen. Nehmen wir als Beispiel eine
Webserver-Farm. Um den Zugriff der vielen User bewältigen zu können, benötigt man häufig mehrere Webserver, die aber immer den gleich Inhalt wiedergeben sollen.
Damit man die Dateien nicht auf jedem Webserver vorhalten und entsprechend gleichzeitig überall ändern muss, liegen die Dateien auf einem NFS Server und alle
Webserver mounten sich das gleich Dateiverzeichnis. Die Änderung der Dateien erfolgt dann auf dem NFS Server, also zentral.
Was bei einem Webserver geht, das geht natürlich auch in der Virtualisierung. Auch VMware ESXi hat einen NFS Client und kann sich Speicher von
einem NFS Server holen. Das ist sehr einfach, ein Shared Storage ist bei NFS ja schon eingebaut. Aber das Problem ist die Performance. Selbst bei 10 Gbit/s
Ethernet ist schnell eine Grenze erreicht.
Aber gerade die Datensicherung ist über NFS wieder sehr einfach möglich. Die Performance ist ja definierbar bzw. steuerbar, dann wird eben nur immer eine virtuelle Maschine zur Zeit gesichert. Hierbei ist die einfach Anbindung der große Vorteil. Der NFS Server und damit das Sicherungsziel kann in einem anderen Brandabschnitt stehen und es wird nur eine Ethernet-Verbindung benötigt.
