Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03599.jsonl.gz/391

NFS vs. iSCSI
Siehe auch
NFS vs. iSCSI
NFS und iSCSI sind zwei für unterschiedliche Anforderungen entwickelte Protokolle. Nur eine Handvoll Software kommt mit Unterstützung für beide Varianten daher, beispielsweise VMware, welches beide Protokolle für das Setup eines Shared Storage für VMs anbietet.
NFS ist ein File Sharing Protokoll. Der NFS-Service kümmert sich um das Locking und erlaubt einen sehr effizienten, konkurrierenden Zugriff von mehreren Clients.
iSCSI ist ein Block Level Protokoll: damit gibt es sich nach aussen wie eine physische Festplatte, auf welche ein Dateisystem installiert werden muss. iSCSI unterstützt einen Client pro Volume. Ein Client kann mit Hilfe eines iSCSI Block Volumes zwar Daten lesen und schreiben, es ist aber nicht dafür ausgelegt, diese Daten über mehrere Clients zu teilen. Geclusterte Applikationen, die einen block-basierten Shared Storage verwenden, müssen ein verteiltes Dateisystem selbst implementieren und damit unter anderem konkurrierende Schreibzugriffe untereinander regeln. VMware bietet dafür beispielsweise das Dateisystem VMFS.
Caching wird in beiden Protokollen unterschiedlich gehandhabt. Bei NFS liegt der File System Cache auf dem NFS-Server (dort liegt ja auch das Dateisystem). Cache-Anfragen erzeugen daher auch immer eine geringe Netzwerklast. NFS-Clients führen deswegen einen zusätzlichen lokalen Cache für die Abfrage von Daten und Metadaten. Um Inkonsistenzen zu vermeiden, verlangt NFS v2 und v3 von den Clients einen regelmässigen Abgleich mit dem Server: Metadaten laufen nach 3 Sekunden, Daten nach 30 Sekunden ab. Zusätzlich können Leseanfragen auf Daten und Metadaten auch bei einem Cache Hit einen Nachrichtenaustausch mit dem Server antriggern (z.B. einen Konsistenzcheck auslösen). NFS v4 kann diesen Nachrichtenaustausch bei reinen Daten verhindern, sofern der NFS-Server File Delegation unterstützt. Schreibvorgänge jeder Art sind in NFS v2 immer synchron. NFS v3 und v4 unterstützen ansynchrone Schreibvorgänge für Daten; Metadaten werden aber immer synchron geschrieben. Dazu kommt, dass NFS verschiedene Arten von Write-through Caching unterstützt, je nach Version.
In iSCSI hängt die Caching-Strategie allein vom verwendeten Dateisystem ab. Da das Dateisystem auf dem Client liegt, profitieren Daten als auch Metadaten gleichermassen vom lokalen File System Caching. Daten werden in den allermeisten Dateisystemen asynchron geschrieben; heutzutage gilt das auch für die Metadaten (bei Dateisystemen, die ein Log-based Journaling verwenden, um ein schnelles Recovery zu ermöglichen). Ext3 und Ext4 schreiben Metadaten an Commit Points asynchron. Die Asynchronität und Häufigkeit der Commit Points ist ein Kompromiss zwischen Recovery-Stabilität und Performance (Ext3 und Ext4 verwenden ein 5 Sekunden Commit-Intervall). Bei Verwendung von Ext3 oder Ext4 profitiert iSCSI zusätzlich von einem Write-back Cache.
Die erzwungenen synchronen Metadaten-Updates in NFS garantieren einen konsistenten Stand auch bei Absturz eines Clients. Stürzt ein Client bei Verwendung eines iSCSI-Devices ab, ist durch die Asynchronität nicht sichergestellt, dass Daten und Metadaten vor dem Journal- und Datenblock-Update geschrieben werden konnten.
Built on 2022-06-03