Toekomst NFS, alternatieven

[vanaalten]

Naar aanleiding van een zijspoor-discussie die hier startte:
Ben(V) in "P2P Cat5e ethernet haalt niet volledig potentieel via Samba3"

NFS wordt als op-sterven-na-dood verklaart. Nou heb ik een drietal Linux machines in huis die via NFS wat directories delen en dat werkt eigenlijk wel prima. Ik ben dus ook zeker niet van plan dat op korte termijn te veranderen (of het moet voor de hobby zijn, "het werkt probleemloos, laat ik het veranderen").

Maar toch: zijn meer mensen het er over eens, is het een algemeen geaccepteerde stelling dat NFS er wel uit gaat? En wat zijn dan de betere alternatieven? Het gaat er bij mij niet zo in dat Samba, een min of meer gesloten protocol ontwikkeld voor Windows-systemen, het betere alternatief voor Linux met NFS zou zijn.

Dit is vooral niet bedoeld als rant-topic voor/tegen NFS of SMB. Ben oprecht benieuwd of er een ontwikkeling is die ik als hobbyist gemist heb.

[_JGC_]

NFS gaat niet verdwijnen, nu niet en over 20 jaar is het er nog steeds. Alleen omdat een tweaker stelt dat het antiek is zegt niks. SMB is ook antiek, maar inmiddels zover doorontwikkeld dat het veilig is en fatsoenlijke performance heeft. Bij NFSv4 is dat niet anders.

Wat je wel ziet is verschuiving naar cloud en cluster filesystems. Ik zie niet hoe NFS ooit in dat plaatje gaat passen.

[DeBolle]

Zodra die stelling (NFS op sterven-na-dood) als algemeen wordt verondersteld of. zoals zoveel gebeurt op Tweakers, iedereen gaat elkaar napraten wordt het een selffulfilling prophecy.

Als contrast kan ik bijvoorbeeld stellen dat in mijn werkgebied ik enige maanden geleden ben begonnen met een POC voor NFSv4, met name vanwege toegenomen security eisen.
Van Mainframe, Unix, appliances en propietary spul tot en met het virtuele park met RHEL bouwt alles nog voort op NFS.
Een groot aantal appliances zijn gebaseerd op een Linux variant en doen voor reload, backup & restore en verdere connectivity, native NFS. De leveranciers hiervan zijn regelmatig bezig hun appliances te certificeren op de Storage leveranciers, zoals Dell/EMC.
In deze wereld is NFS tamelijk levendig in gebruik vanweg de 'proven technology'. Applicatieleveranciers zoals Oracle vinden iets van NFS versus CIFS/SMB en laten dat merken in hun White Papers. Sybase, DB2 hebben ook een aantal best practices waarbij veel teruggevallen wordt op NFS boven andere connectivity.

Bij KA & werkplekken is het anders, daar wordt alles inmiddels geregeld door Windows gebeuren, ook al omdat IDM in ADS is opgehangen, maar dat terzijde. In die wereld is inderdaad NFS meer de vreemde eend in de bijt.

[Hero of Time]

Die opmerking van 'm is ongefundeerd en bevat niet eens een bron of iets om dat te onderbouwen. Zolang NFS veiliger* is dan SMB, kan je mij niet wijsmaken dat het dood is en gaat verdwijnen.

Zolang het een open/vrije systeem is itt de gesloten aard van Samba, gaat NFS er echt niet uit.


* NFS heeft ondersteuning voor authenticatie en ook nog eens Kerberos er bovenop. Alsmede ingebouwde ondersteuning voor IP restricties. Samba heeft dat niet. En dan hebben we het nog niet eens over ACLs. Dat moet met Samba apart en met extra moeite ingesteld worden, maar kan het niet native op de client zien of aanpassen.

[vanaalten]

Dank allen voor de info! Blij te zien dat ik niet een trend gemist heb.

Ik kon mij wel zo voorstellen dat er meer een trend is richting cloud-systemen koppelen. Bijvoorbeeld Amazon S3 storage mounten op een machine. Zelf heb ik een nextcloud server draaien en via 'davfs' daarvan een folder gemount. Wat op zich best aardig werkt, maar ik heb nog niet het idee dat dit soort systemen nu al heel groot zijn - voelde meer als hobbykamer-werk. Maar goed, ik ben dan ook best een Linux-amateur die aan het hobbyen is, dus ik claim vooral niet dat ik de kwaliteit of robuustheid van deze systemen goed kan inschatten.

@Hero of Time, Stel dat Microsoft de volledige standaard van SMB zou vrijgeven en het in beheer zou geven van een of andere gerenommeerde IEEE-achtige instantie - zou het dan kans maken om NFS te vervangen? Zat mij vooral af te vragen hoe groot de invloed is van de gesloten aard op de verhouding SMB-NFS.

[Hero of Time]

Dan nog heb ik m'n twijfels. NFS is een bewezen techniek. Net zoals SMB dat is. Waarom zou er 1 netwerk filesystem over moeten blijven?

Je haalt S3 aan, maar dat is een compleet ander systeem. Namelijk een object store. Daar kan je niet mee vergelijken.

[ripperke]

Hero of Time schreef op zaterdag 4 juli 2020 @ 17:15:
Die opmerking van 'm is ongefundeerd en bevat niet eens een bron of iets om dat te onderbouwen. Zolang NFS veiliger* is dan SMB, kan je mij niet wijsmaken dat het dood is en gaat verdwijnen.

Zolang het een open/vrije systeem is itt de gesloten aard van Samba, gaat NFS er echt niet uit.


* NFS heeft ondersteuning voor authenticatie en ook nog eens Kerberos er bovenop. Alsmede ingebouwde ondersteuning voor IP restricties. Samba heeft dat niet. En dan hebben we het nog niet eens over ACLs. Dat moet met Samba apart en met extra moeite ingesteld worden, maar kan het niet native op de client zien of aanpassen.

Zonder te oordelen of CIFS of NFS nu beter is, vind ik je hele opmerking wel heel kort door de bocht, sorry.

Uiteraard ondersteunt Samba/CIFS authenticatie en Kerberos. Ik kan moeilijk vatten waar je dat vandaan zou halen?
Ook ondersteunt Samba prima IP restricties (host allow parameter).

Zowel het CIFS protocol (https://docs.microsoft.co...36-406e-a951-4f04b2fd1d2b) als Samba (https://gitlab.com/samba-team/samba) zijn volledig open, is niks gesloten aan.

ACLs zijn in het algemeen gewoon een soep, daar valt niet veel (meer) aan te doen (https://wiki.linux-nfs.or..._Interoperability_Problem), het is dus ook moeilijk oordelen wat beter is.

IMHO ben je in een Linux <-> Linux environment het best af met NFS, eenmaal je in een mixed environment (Windows, Linux) komt ben je het best af met CIFS/Samba.

[MAX3400]

NFS & CIFS kunnen toch zelfs tegelijk gebruikt worden? Zelfs op de (recente) Windows Server OS'en kan je NFS toevoegen als role en als je dan "zelfs als beginner" de GUI-wizard afloopt, kan je o.a. Krb5i configureren

Ben een beetje zoekende naar de continue differentiatie "NFS of SMB" of "NFS vs SMB".?

[MainframeX]

De stelling van ben(v) is gewoon incorrect, kort gezegd snapt 'ie er gewoon geen donder van.

Ik sluit me trouwens aan wat @ripperke zegt. Voor linux omgevingen is nfs het makkelijkst maar zodra je os'en door elkaar gaat gebruiken vind ik samba het fijnst. Daar zitten overigens wel beperkingen aan; samba is single threaded dus de cpu op je host moet je wel goed afmeten op werklast die deze krijgt.

[Hero of Time]

ripperke schreef op woensdag 8 juli 2020 @ 18:11:
[...]

Zonder te oordelen of CIFS of NFS nu beter is, vind ik je hele opmerking wel heel kort door de bocht, sorry.

Ik ben wat kort door de bocht vanwege de enorme versimpeling die ik maak tussen de twee. Niet helemaal juist, daar heb je een goed punt.

ACLs zijn in het algemeen gewoon een soep, daar valt niet veel (meer) aan te doen (https://wiki.linux-nfs.or..._Interoperability_Problem), het is dus ook moeilijk oordelen wat beter is.

Beetje ongelukkige woordkeuze van mij, maar met ACL bedoelde ik meer de rechtenstructuur op het host systeem. Bij CIFS kan het wel, maar vereist meer werk terwijl het bij NFS geen speciale configuratie vereist.

Ik weet eigenlijk niet of je via CIFS met extra configuratie aan de server kant en ondersteuning aan de client kant de rechten op bestanden en mappen kan wijzigen zoals je dat bij NFS kan (denk aan read-only maken, uitvoerbaar, naar een andere gebruiker zetten indien toegestaan, etc).

IMHO ben je in een Linux <-> Linux environment het best af met NFS, eenmaal je in een mixed environment (Windows, Linux) komt ben je het best af met CIFS/Samba.

Daarom denk ik ook dat NFS nog lang niet afgeschreven zal worden.

[Rainmaker]

NFS, en dan met name pNFS binnen NFS4.1 is echt niet "makkelijk op te zetten". Het vereist een redelijke infrastructuur met betrekking tot KDC, als je het goed wil doen.

Iedereen blijft alleen halstarrig vasthouden aan NFS3, juist omdat dat inderdaad zo lekker makkelijk is om op te zetten.

Overigens is dit bij CIFS niet anders, waar je ook een domain controller o.i.d. moet hebben.

[Wim-Bart]

Voor bepaalde omgevingen (niet alle) prefereer ik zelfs NFS boven iSCSI als datastore onder ESX. Omdat het vaak sneller is en het afhandelen van de "Filesystem" taken naar storage device verlegd wordt. NFS is dus zeker niet dood. Zo is NFS via een NetApp filer 20-30% sneller dan iSCSI.

Natuurlijk blijft iSCSI en NFS inferieur aan native Fibre Channel. Maar dat is een andere discussie.

[Oogje]

vanaalten schreef op zaterdag 4 juli 2020 @ 17:36:

Ik kon mij wel zo voorstellen dat er meer een trend is richting cloud-systemen koppelen. Bijvoorbeeld Amazon S3 storage mounten op een machine.

S3 is anders zoals @Hero of Time al aanstipt. En in het storagelandschap van AWS is er meer dan dat, waaronder EFS en dat is op basis van NFS

[goarilla]

Daar zitten overigens wel beperkingen aan; samba is single threaded dus de cpu op je host moet je wel goed afmeten op werklast die deze krijgt.

Huh voor iedere share/user wordt een nieuw process gestart hoor.

[DeBolle]

MAX3400 schreef op woensdag 8 juli 2020 @ 18:16:
NFS & CIFS kunnen toch zelfs tegelijk gebruikt worden? Zelfs op de (recente) Windows Server OS'en kan je NFS toevoegen als role en als je dan "zelfs als beginner" de GUI-wizard afloopt, kan je o.a. Krb5i configureren

Ben een beetje zoekende naar de continue differentiatie "NFS of SMB" of "NFS vs SMB".?

Goed punt roer je daar aan, vanouds waren de eerste NAS servers (EMC Celera, NetApp FAS) al uitgerust met beide protocollen, welke gelijktijdig op hetzelfde filesystem actief waren.

Het lokale filesystem (DART resp. WAFL) was dan beschikbaar als NFS en als CIFS, compleet met alle permissies die bij het protocol horen en een mapping mogelijkheid om accounts op beide gelijktijdig verschillend of gelijk te houden.

Inderdaad is voor Windows server op dat vlak ook al sinds NT4 een aantal subsystems beschikbaar, waardoor je een filesystem kunt exporteren als CIFS/SMB en NFS gelijktijdig. Werkt prima, kost alleen wat hoofdbrekens wanneer je accounts hebt die onder NFS iets anders willen qua permissies dan onder CIFS.

Dat gezegd hebbende lijkt het erop dat de vraag NFS of SMB inderdaad niet terzake doende is.

[HollowGamer]

Heeft iemand een betrouwbare bron met de vermelding dat NFS deprecated is?

[vanaalten]

HollowGamer schreef op maandag 13 juli 2020 @ 08:58:
Heeft iemand een betrouwbare bron met de vermelding dat NFS deprecated is?

Nou, dan zou die hier al wel gepost zijn, lijkt mij. Ik ben dit topic begonnen omdat er in een ander topic door @Ben(V) zo iets werd gesteld. Wellicht dat hij er een bron voor heeft of een onderbouwde mening. Of wellicht dat ik zijn stelling verkeerd opvatte en/of uit z'n verband trok.

[HollowGamer]

vanaalten schreef op maandag 13 juli 2020 @ 09:00:
[...]

Nou, dan zou die hier al wel gepost zijn, lijkt mij. Ik ben dit topic begonnen omdat er in een ander topic door @Ben(V) zo iets werd gesteld. Wellicht dat hij er een bron voor heeft of een onderbouwde mening. Of wellicht dat ik zijn stelling verkeerd opvatte en/of uit z'n verband trok.

Ik denk vooral het laatste. NFS wordt ontzettend veel gebruik, vooral op server niveau voor het mounten van remote bestandssystemen. De laatste tijd zijn daar ook Linux patches bijgekomen voor betere caching en andere performance fixes. Iets als ZFS heeft ook ingebouwde ondersteuning ervoor.

Een hele lange tijd heb ik SMB gebruikt, maar NFS is 5x sneller (zie Arch Linux Wiki - NFS, voor tweaks). Het enige is dat veelal clients het niet ondersteunen zoals Android en Windows zonder toevoegingen.

Nu gebruik ik enkel NFS thuis en voor direct mounting. SMB is velen malen beter en makkelijker met authenticatie en ACL. Ik weet niet of ik NFS zou gebruiken met meerdere users, daar vind ik SMB wel beter in. Dat is in mijn ogen de reden waarom SMB trager is door de overhead*.

[ Voor 6% gewijzigd door HollowGamer op 13-07-2020 09:10 ]

[Brahiewahiewa]

HollowGamer schreef op maandag 13 juli 2020 @ 09:08:
[...]

Een hele lange tijd heb ik SMB gebruikt, maar NFS is 5x sneller (zie Arch Linux Wiki - NFS, voor tweaks)...

Als NFS 5 x sneller is dan SMB, dan doe je iets goed fout met SMB

Ik haal met SMB3 een netto doorvoer snelheid van 138 MB/s (want SMB3 comprimeert) over een 1Gb/s link
Met NFS kom ik niet verder dan 113 MB/s

Niet dat ik hiermee de discussie wil opstarten dat SMB beter is dan NFS, maar een factor 5 claimen is ongeloofwaardig

[Hero of Time]

Ik dacht dat je voor dezelfde locatie SMB en NFS juist niet tegelijk kan gebruiken omdat beide technieken hele andere locking methodes gebruikt en je zo niet fatsoenlijk kan weten of een bestand in gebruik is, met alle mogelijke gevolgen van dien.

[HollowGamer]

Brahiewahiewa schreef op maandag 13 juli 2020 @ 13:59:
[...]

Als NFS 5 x sneller is dan SMB, dan doe je iets goed fout met SMB

Ik haal met SMB3 een netto doorvoer snelheid van 138 MB/s (want SMB3 comprimeert) over een 1Gb/s link
Met NFS kom ik niet verder dan 113 MB/s

Niet dat ik hiermee de discussie wil opstarten dat SMB beter is dan NFS, maar een factor 5 claimen is ongeloofwaardig

SMB3 is gewoon langzamer, er zit gewoon meer overhead in. Ik heb SMB3 echt een tijd gedraaid, maar er wordt tegenwoordig ook met encryptie gewerkt. Al die zaken maken SMB in mijn ogen beter dan NFS, maar nog altijd heeft dat een performance penalty.

Je kunt deze dingen uitzetten, maar dan nog viel de performance van SMB erg tegen t.o.v. NFS. 5x sneller is inderdaad overdreven, maar in mijn ervaring wel sneller dan SMB.

[Brahiewahiewa]

HollowGamer schreef op maandag 13 juli 2020 @ 15:42:
[...]

SMB3 is gewoon langzamer,..

Nee, SMB3 is sneller want het comprimeert bestanden voordat het op het netwerk gezet wordt

Maar, zoals aangegeven, deze diskussie wilde ik niet voeren

[DeBolle]

Hero of Time schreef op maandag 13 juli 2020 @ 14:36:
Ik dacht dat je voor dezelfde locatie SMB en NFS juist niet tegelijk kan gebruiken omdat beide technieken hele andere locking methodes gebruikt en je zo niet fatsoenlijk kan weten of een bestand in gebruik is, met alle mogelijke gevolgen van dien.

De protocollen geven hun wensen en eisen door aan de processen en die gaan uiteindelijk naar het lokale filesystem. Uiteindelijk is alleen dat laatste van belang, al het andere is een mapping van en naar NFS en CIFS.
Zie bijvoorbeeld de uitleg bij Netapp: https://library.netapp.com/ecm/ecm_download_file/ECMP1401220

In de praktijk ben ik op dit vlak nog geen problemen tegengekomen overigens, jij wel dus?

[GuntherDW]

@Brahiewahiewa dat telt ook enkel maar als de bestanden die overgezet worden ook goed compresseerbaar zijn.

Maargoed, als je je zorgen moet maken over encryptie en compressie op een gbit link voor CIFS vs NFS zou ik toch eens die 486 van je upgraden , of zien waar al je CPU usage heen gaat.

Beetje nutteloze discussie wel inderdaad. Ik persoonlijk gebruik nu al meer dan 10 jaar beiden op m'n netwerk, NFS voor de *NIX dozen en CIFS voor de non-*NIX dozen. Voor linux is NFS handiger, al is het misschien minder veilig gezien ik de "simpele" versie gebruik zonder echte auth. Enkel wat IP restricties.
Saturate zelfs op m'n oude (10+jaar) systeem de volledige gbit link. Tenzij je misschien honderden kleine files per keer overzet. Maar dan zit je meer aan overhead in het algemeen te verspillen dan de rest.

[ Voor 14% gewijzigd door GuntherDW op 14-07-2020 07:42 ]

[Frank-NL]

Hij bedoelt het vast goed maar ik weet niet hoe serieus we de aanstichter van dit topic moeten nemen, ook gezien zijn andere stellige uitspraken die hij doet in het Synology topic, als hij erop wordt gewezen dat iets niet helemaal klopt.

Overigens kom ik NFS shares overal tegen, ook in data centers

[ Voor 19% gewijzigd door Frank-NL op 14-07-2020 14:23 ]

[GuntherDW]

Oef, die laatste reply van 'm inderdaad is nogal... bedenkelijk te noemen.

Het enige punt waar hij nog gelijk in zou kunnen hebben is als Synology met MBR zou werken, én van die disks/setups zou booten. Maar dat is een disk layout indicator, geen file system.

Maargoed, gezien die reply is het inderdaad iets waarbij je rekening moet houden...

[HollowGamer]

goarilla schreef op zondag 12 juli 2020 @ 13:32:
[...]
Huh voor iedere share/user wordt een nieuw process gestart hoor.

Een nieuw process of een nieuwe connectie? Ik dacht altijd het laatste, wat dus geen nieuwe thread is.

[Hero of Time]

DeBolle schreef op maandag 13 juli 2020 @ 19:16:
[...]

De protocollen geven hun wensen en eisen door aan de processen en die gaan uiteindelijk naar het lokale filesystem. Uiteindelijk is alleen dat laatste van belang, al het andere is een mapping van en naar NFS en CIFS.
Zie bijvoorbeeld de uitleg bij Netapp: https://library.netapp.com/ecm/ecm_download_file/ECMP1401220

In de praktijk ben ik op dit vlak nog geen problemen tegengekomen overigens, jij wel dus?

Zelf niet meegemaakt, omdat ik dus nooit beide tegelijk gebruik voor een share.

[goarilla]

Ik dacht dat het moederprocess smbd, draaiend als root, voor iedere "connectie als user" een nieuw
process forked en dat dan wanneer nodig seteuid en setegid naar de uid van die user. Met ps en smbstatus kan je dat zien.

Zo heb ik zelf 4 shares gemount, 3 onder een guest user, 1 onder een prive user.
Ik heb 2 processes 1 voor de guest user die hergebruikt wordt voor de andere shares
En 1 voor de prive user:

smbstatus

3533 1594804272 guest IP nethdd
3533 1594804272 guest IP video
16730 1594818509 goarilla IP home
3533 1594818565 guest IP audio

Maar als je dus meerdere users hebt ... heb je zowiezo meerdere child processes.

[GarBaGe]

Ik verwacht niet dat NFS weg gaat.
Vooral voor kleinere lokale netwerken, kan het prima werken.
Wil je echt enterprisey, HA of meerdere DCs dan heb je wellicht een geavanceerder gedistribueerd filesystem nodig, zoals bijvoorbeeld GlusterFS.

Je moet NFS dus wel gebruiken waarvoor het bedoeld is.

[MAX3400]

GarBaGe schreef op woensdag 15 juli 2020 @ 15:57:
...
Wil je echt enterprisey, HA of meerdere DCs dan heb je wellicht een geavanceerder gedistribueerd filesystem nodig, zoals bijvoorbeeld GlusterFS...

Klinkt leuk en aardig maar waarom laat je het op "zeer grote infrastructuren" nog afhangen van je filesystem? Zelfs een simpel opzetje (kosten daargelaten) in een standaard Microsoft examen voor je "ouderwetse" MSCE praat niet eens meer specifiek over het filesystem maar gaat meteen de replicatie/synchronisatie-modus in voor 2 zeer kleine sites (zeg even, de loodgieter en zijn kantoortje 50km verderop).

Voor grotere / "enterprisey" infrastructuren zeg ik zeker niet dat je misschien niet een ander filesystem zou kunnen / moeten gebruiken maar dat is alleen als je "transparant" de data anytime / anywhere wil kunnen raadplegen zonder merkbare latency aan het frontend etc. In bijna alle gevallen laat je je filesystem lekker zijn gang gaan en ga je op andere manieren ervoor zorgen dat je data aan "de andere kanten" terecht komt. En, allicht mis ik iets in je argumenten, ook SMB of NFS is "gewoon" geschikt om over 8 kleurtjes glasverbinding data naar een ander datacenter te sturen.

Ik denk echter dat een richtlijn is: "hoe meer HA'er je wil gaan, hoe meer bottom-up" je moet gaan denken als je het OSI-model erbij pakt?

[Yarisken]

Vroeger veel nfs gebruikt met netapp / esx toen ik nog infra deed.
Thuis draai ik mijn shares op nfs en op het werk draaien we ook nog veel nfs.
Gaat niet direct weggaan denk ik zo :-).
Onder netapp retestabiel, nooit issues gehad.

[syl765]

NFS word zeker nog veel gebruikt en zal ook niet snel verdwijnen denk ik.
Binnen FreeBSD is men bezig met een NFS over TLS implementatie project.
http://www.freebsd.cz/new...S-over-TLS-implementation