NFS biztonságosabbá tétele

Web, mail, IRC, IM, hálózatok

Szerveroldalon egyelőre az export fájlba ezt tettem bele: /home/serveruser/megosztas 192.168.1.124(rw,sync,root_squash,noexec,nosuid,nodev)

Ezzel elviekben kizártam azt, hogy kliens gépről root-ként matasson bárki is a szerveroldali gépen. Plusz ha jól értem, csak az adott IP-el tarthat csak kapcsolatot a szerver NFS-en keresztül. Egyrészt eddig jól tudom? Másrészt van-e még valami okosság, amivel még biztonságosabbá tehetem? Egyelőre minden renben működik ezekkel a beállításokkal is.

  • 2393 megtekintés

( agostonl | 2025. 12. 30., k – 08:09 )

Ha van rá lehetőség, én az egész NFS szerver-szerver forgalmat, egy szeparált VLAN-ba tenném.

A VMware egy Ferrari, amit a maffiától bérelsz és mindig a hó elején derül ki éppen mennyi lesz a beszedett díj. 
A Proxmox megy egy Porsche, ami az F1 motorját kapta meg. 
by: jevgenyij

Nagyobb infrastruktúra esetén a "hagyományos" NFS biztonsági hiányosságai, illetve performancia miatt célszerű szeparált, dedikált, zárt hálózatot használni úgy, hogy az érintett gépek ide bekötött interfészein minimum csomagszűréssel legyen korlátozva a forgalom kizárólag az NFS-hez szükségesre, és  sshd, postfix, ingyombingyom ne is hallgatózzon ezen a lábon. Ugyanígy az iSCSI forgalom szeparálása is a best practice része. 

A fenti mondat helyesen:

A VLAN swich nem egy biztonsági eszköz. Ez egy forgalom menedzselő eszköz. Nem lesz tőle semmi "biztonságosabb".

Áruld már el, hogy a kulcsra zárt szerverszoba esetén, amin belül mondjuk éppen NFS-en beszélgetnek a szerverek, külön VLAN-on, hogyan fogsz abba a forgalomba belehallgatni kívülről? Tfh. volt annyi esze a rendszergazdának, hogy csak untagged portot engedett ki, és persze port based, nem pedig MAC based VLAN-ról beszélünk.

Sima switch esetén már egy mac spoofing is elegendő erre. A szerverek pedig időnként fognak broadcast csomagokat küldeni, úgyhogy még ki se kell találni a MAC címet.

A VLAN swich nem egy biztonsági eszköz. Ez egy forgalom menedzselő eszköz.

Igen, de nem tudom, ez hogy jön ide a témához. VLAN-ról beszélünk abszolut amatőr megoldás azt gondolni, hogy VLAN ID egy L2 csomagon bármit jelent. 

 

Sima switch esetén már egy mac spoofing is elegendő erre.

Sima switch esetén én olyan VLAN ID-vel kommunkálok amivel akarok.

Mivel a "sima switch" amelyen működik a "MAC spoofing" (előző hozzászólások, és szál) nem képes forgalom menedzsmentre (VLAN ID beállítás vagy ez alapján port biztonsági szabályok kezelése, ahogy nem képes semmilyen más port biztonságra se), ott azt csinálsz amit akarsz, nincs korlát. Ha meg van rajta port biztonság, ott tuti biztos van valamelyik/mind az a lehetőség amit említettem és ehhez a VLAN nem kell. 

De miért ragaszkodsz ahhoz, hogy mindenképpen balfék módon kelljen VLAN-okat csinálni? Persze, ha balfék módon csinálja valaki, akkor azellen nem véd. De ahogy írtam, a "menedzselt switch" a mai világban nem egy olyan ritka madár, hogy ne lenne otthon kb mindenkinek 1 db belőle (csak openwrt-t kell ráraknod, mert a legtöbb gyártói firmware nem vezeti ki a vlan konfigurálási lehetőséget).

Régóta vágyok én, az androidok mezonkincsére már!

De miért ragaszkodsz ahhoz, hogy mindenképpen balfék módon kelljen VLAN-okat csinálni?

Ugye megnézted kinek a kérdésére ment ez a válasz?

 

De ahogy írtam, a "menedzselt switch" a mai világban nem egy olyan ritka madár

A te buborékodban. Otthon ritka, aki ért ehhez, az is ritka. Az adott "válasz" -> állíts be egy VLAN-t a forgalomra, a teljesen elégtelen válasz, mert önmagában ez nem csinál semmit. 

Friczy, Caro vagy agostonl? Szerintem egyikük sem írt hülyeséget. Lehet, hogy nem írtak komplett, minden részletre kiterjedő howto-t, de kifejezetten fals állítást nem látok egyiküktől sem.

A te buborékodban.

Innentől már csak ismételgetem magamat. A legalább 4-5 ethernet portos otthoni routerek belső switch-e szinte kivétel nélkül managelhető. Az más kérdés, hogy sok gyártó szándékosan eldugja a UI-ról, hogy a kedves felhasználó fogalmatlanul ne kotorásszon a VLAN beállításoknál, aztán csodálkozzon, hogy téglásította a routert ("aki ért ehhez, az is ritka" - ezt az állításodat abszolút nem vitatom). Ezért kötöttem ki, hogy legalább valami alternatív firmware felrakható legyen rá, amin ki van vezetve. Otthoni környezetben nem egy elérhetetlen valamiről beszélünk, nem kell sokszázezer Ft-ot beruházni hozzá. Ha valaki eddig a szolgáltatói központilag managelt szutykot használta routernek, akkor kb 3-4eFtból tud venni egy régi de már gigabites, openwrt által támogtaott routert. És máris van egy managelhető switch otthon. Nem egy akkora was ist.

Az, hogy kikepzo kollégának én ezt a megoldást javasolnám-e? Egyértelműen Nem. 

Úgy általában az egész NFS security témát nem javasolnám neki. Válasszon valami olyan network filerendszert, ami a Confidentiality, Integrity, Availability hármasra legalább rendelkezik beépített működő megoldásra és nem kívülről kell rátákolni mindent. Az NFS hardenelése kb a leg-munka- és hozzáértés-igényesebb. De hát ahogy elnézem ő szeret mindent azonnal hard mode-ban csinálni. :)

Régóta vágyok én, az androidok mezonkincsére már!

Friczy, Caro vagy agostonl? Szerintem egyikük sem írt hülyeséget.


Nem alkotnék véleményt a válaszokról, nem szokásom. Maradjunk abban, hogy senki nem fogta fel, hogy kinek van ajánlva. Az adott esetben teljesen feleslegesen írták amit írtak és nem tudnak engedni abból, hogy ja, ezt valakinek írtam akinek 2 gépe van otthon és fingja nincs arról amit javasoltak. 

 

Az, hogy kikepzo kollégának én ezt a megoldást javasolnám-e? Egyértelműen Nem. 

Megérkeztünk. Egy "tedd külön VLAN-ba" itt árt.

 


 

Inkább csak sejtettem, hogy innen fúj a szél ezért tettem hozzá az egész "ajánlanám-e" bekezdést. Visszaolvasva a hozzászólásaidat, elég ügyesen titkoltad, hogy erre akarsz kilyukadni. Kb ezt a félmondatot kellett volna hozzátenned az elején: "Ha csak a hoston végződteti a VLAN-okat, de managelhető switchen nem konfigurálja fel rendesen, ...." akkor nincs ez az egész flameelés.

Régóta vágyok én, az androidok mezonkincsére már!

Ne haragudj, nem folytatom tovább, sok energiámat elvesz. 

Otthoni feladatok neked:
1, Beállítottam, hogy csak 802.1x-el lehet feljönni a portra. Neked el kell érned, hogy a switch beszéljen veled.
2, Beállítottam, hogy a XX:YY:ZZ:AA:BB:CC MAC csak a 3-as porton lehet, de azok foglaltak és nem tudod a drótot kihúzni.

 

Igen, a MAC rögzítés elvben megoldás. Feltéve, hogy tudod menedzselni, nem használsz HA megoldást, ahol pl. egy virtuális MAC címnek vándorolnia kell, és végtelen időd van az adminisztrációra. Tipikusan az a helyzet, ami nem éri meg. Kevés gép/port esetén kezelhető a mennyiség, ellenben alacsony a támadás kockázata, ha növekszik a hálózat, akkor meg a belefektetett erőforrás lesz extrém sok.

Akkor hogy érthető legyen, ha így nem megy. Az eredeti állítás, szó szerint:

"Egy switch-elt hálózaton, mivel lesz előrébb, ha VLAN-t használ? (nem, nem lesz tőle szeparáltabb)"

Illetve:

A VLAN nem egy biztonsági eszköz. Ez egy forgalom menedzselő eszköz. Nem lesz tőle semmi "biztonságosabb". Amelyik switch-en tudod szabályozni melyik port milyen VLAN-t beszéljen, ott általában van ARP reply-only és/vagy 803.1x és/vagy port mátrix és/vagy ... 

Az én állításom:

VLAN segítségével meg lehet akadályozni illetéktelen hozzáférést egy hálózathoz. Igen, természetesen megfelelő fizikai biztonság meglétével együtt, anélkül semmi nem ér szart se. Ugyanezt egy "switch-elt hálózaton" nem lehet ilyen módon elérni. Tehát de, szeparáltabb lesz.

VLAN segítségével meg lehet akadályozni illetéktelen hozzáférést egy hálózathoz ..... Ugyanezt egy "switch-elt hálózaton" nem lehet ilyen módon elérni. Tehát de, szeparáltabb lesz.

Nem erről beszéltünk. Hanem arról, hogy a VLAN-ok mellé kell azt, hogy megmond melyik port melyik(ek)et kezelheti. Ha az a switch menedzselt, akkor a VLAN helyett bármilyen más port biztonsági beállítást használva meg lehet oldani, nem kell VLAN ehhez. Sőt ezek  VLAN-nál jobb megoldások. Tehát nem az dönt, hogy van e VLAN vagy sem, hanem, hogy mit tud a switch. 

Nem a VLAN a biztonsági eszköz, hanem a VLAN-ok közti forgalmat szűrő bármi a biztonsági eszköz.

Sima switch esetén olyan VLAN iD-vel kommunikálsz, amit a switch megenged (feltéve, hogy menedzselhető switch és menedzselik. Egy jól menedzselt hálóban te jellemzően access portot kapsz, és a natív VLANjával kommunikálsz, és ha VLAN ID-vel akarsz kommunikálni, akkor nem fogsz.

Egy jól menedzselt hálóban te jellemzően access portot kapsz, és a natív VLANjával kommunikálsz, és ha VLAN ID-vel akarsz kommunikálni, akkor nem fogsz.

Ez függ a hálózattól is, meg attól is hogy mire van használva. Az is jól menedzselt hálózat lehet, hogy ha semmi mással, csak egy konkrét VLAN ID-vel kommunikálhatsz, mert a switch azon a porton más forgalmat (untagged / más ID) nem enged. Nagyon-nagyon függ, hogy mire akarjuk használni. Hosting környezetben igaz lehet amit írsz. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem csak hosting környezetben. Ha a hálózat és a hostok menedzselése más kézben van (minél nagyobb a cég, ez annál inkább triviális), akkor nem célszerű a gépek üzemeltetőjének hálózati jellegű feladatot is adni. Persze ez előfordulhat, mondjuk egy olyan vmware környezetben, ahol az enclusure-ben virtual switchek is vannak, ott viszont azt kell végiggondolni, hogy kinek a feladata a virtual switchek konfigurálása. De ez már végképp messzire távolodik attól, ahonnan az egész diskurzus előfordult, szerintem ne menjünk tovább ebbe az irányba.

Mivel a VLAN-hopping meglehetősen nehezen kivitelezhető,

?? Mi közünk van ehhez? Vagy menedzselt a switch és kizárjuk a MAC tanulást és nem szórunk ki semmilyen oda nem tartozó tartalmat nem megfelelő portnak akkor ehhez nem kell VLAN, és az átlagos otthoni nem menedzselt switch-en pedig szart sem ér ha dobsz rá egy extra VLAN ID-t a csomagra. 

Openwrt-vel azért a legtöbb otthoni routerben levő switch-en tudsz vlan taggelést konfigurálni. Ok, általában elég limitált a dolog (sokszor csak 1..15-ig tudod az ID-kat állítani, stb.) egy rendes enterprise switch-hez képest, de meg tudod oldani, hogy az adott port bizonyos vlan id-kat engedjen vagy legyen untagged és belül mindig a default-ra állított VLAN ID-t kapja meg.

Régóta vágyok én, az androidok mezonkincsére már!

Ha a switch nem menedzselt, akkor felejtsük el a VLAN-t. Elvben persze lehetséges, hogy vagy egy switch, és az egyes hostok VLAN-ID-ket állítanak be, de ez elég értelmetlen marhaság. Részemről eleve feltételezem, hogy ha VLAN-okat alakítunk ki, akkor menedzselt switch.

Átlagos, nem menedzselt switchben ne szórakozzunk VLAN-nal.

Az eredeti témanyitótól messze kanyarodtunk, az a része nem érdekel. Viszont az a kijelentésed, hogy a VLAN-tól nem lesz szeparáltabb, alapvetően nem állja meg a helyét. Még akkor sem, ha nem önmagában a VLAN-tól lesz szeparáltabb, hanem azzal, ami ésszerű módon azzal együtt jár (vagyis a VLAN-ok közti forgalom korlátozása, szűrése).

hogy a VLAN-tól nem lesz szeparáltabb, alapvetően nem állja meg a helyét

Amit a VLAN-ba vizionáltok az a port biztonság része. Ezt próbáltam igazolni azzal, hogy ha van olyan eszközöd (sima switch) amelyen semmilyen szabályozási lehetőséged nincs a portok tekintetében, akkor tök mindegy van e rajta egy plusz VLAN ID vagy sem. Ezt teljesen és kompletten figyelmen kívül hagytad.



 

Nem hagytam figyelmen kívül. A portok tekintetében annyi szabályozási lehetőségem van, hogy tudok rá hatni, mi hová van bedugva. Onnantól pedig a port/VLAN összerendelés és az access port jelleg megoldja a többit. Ahogy írtam: menedzselhető switchről beszéltem végig, különben az egész vlanosdi értelmetlen. Ha meg menedzselhető, akkor tudom szabályozni, hogy melyik porton milyen VLAN legyen natív, és egyáltalán milyen VLAN legyen elérhető.

( Kayapo | 2025. 12. 30., k – 09:54 )

A root_squash kapcsolóval pont, hogy megengeded a root jogu file kezelést, te szerintem a no_root_squash -t akartad beállítani.

Talán a sec=sys és a secure kapcsolók lehetnek hasznosak.

Mindazonáltal, ha van rá mód (és miért ne lenne) érdemes lenne áttérni iscsi -ra. Ha a szeparáció az elsődleges, akkor ezzel könnyebb dolgod lenne.

----
올드보이

Mindazonáltal, ha van rá mód (és miért ne lenne) érdemes lenne áttérni iscsi -ra. Ha a szeparáció az elsődleges, akkor ezzel könnyebb dolgod lenne.

hát az igencsak attól függ, mi a cél. Az egyik egy elosztott filerendszer, amit egyszerre több helyről lehet basztatni, a másik meg csak egy remote block device, amit meg nem. Erősen almát körtével.

( Caro | 2025. 12. 30., k – 09:58 )

Először azt a kérdést tenném fel, hogy valóban NFS-re van-e szükséged? A válasz lehet igen, de viszonylag ritka eset.

Számomra az sshfs sokkal kézenfekvőbb, bár nyilván nem adja ugyanazt a teljesítményt.

Mivel csakis belső hálón 2 gép közt kell, így az nfs sokkal jobb választás. Egyrészt erőforráskímélőbb (nem kell folyamatosan titkosítani), másrészt nem érzékeny a pillanatnyi kiesésekre, a sebessége sokkal gyorsabb mint az sshfs, valamint kernel szintjén fut. Hátránya, hogy backódnom kellett az export fájl beírásaival, de ez szerintem ennyit megért.

"https://hunvagyok.hu "

nem érzékeny a pillanatnyi kiesésekre

de. Az NFS - lévén UDP alapú by default - nagyon érzékeny a hálózati problémákra. Ha ilyenek előfordulhatnak, akkor inkább Samba. Nem bonyolultabb, ugyanazt a klikkre megnyílást adja, és hibatűrőbb, sokkal.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

"Az NFS - lévén UDP alapú by default"

Az attól függ... Az NFSv4 az alapból tcp, ha minden igaz ugye... Plusz az UID/jogosultságok összehozása is kellően szivatós tud lenni - nem véletlen, hogy nagyon sok helyen, akár tiszta Linux/*nix környezetben is inkább SaMBa felé megy a világ. már csak azért is, mert NFS-en maximum(!) a kliens IP-címe az, amihez kötni tudod első körben az elérést - hacsak nem akarsz a kerberos buggyraiban elmerülni - amim valljuk be eléggé se&&fájós tud lenni... 

Mondjuk a kerberost a sambánál se nagyon lehet megúszni. Vagyis meg lehet, de érdemes?

Tiszta linux környezetben továbbra sem olvastam egyetlen ellenérvet sem az sshfs ellen. Mai konfigokon a gigabitet hozza. Nem kell telepíteni semmit az ssh szerveren kívül. Annyira biztonságos, mint az ssh. Mi kell még?

De, bőven meg lehet úszni a Kerberost, és nincs semmi hátránya a user-password alapú authentikációnak tiszta linux környezetben.

Az SSHFS hátránya, hogy nem hozza azt, hogy "rákattint a paraszt a gépre, és ott vannak a fájlok". Mármint, ha nem mented el a gépeket/megosztásokat kedvencként darabonkint, akkor az SSHFS-ben nincs discovery képesség, az NFS-ben meg a Sambában van. Azt most hagyjuk, hogy ez mennyire megoldható mondjuk Avahi-val meg egyebekkel, gondolom a topicnyitó nem akarja magát instant szopatni, cserébe ez kifejezett igény volt.

És tudom, hogy én vagyok az unortodox azzal, hogy próbálok olyan megoldást találni, ami matchel a specifikációval, ez sajnos nálam munkahelyi ártalom már.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Egyszer azért be lehet írni talán az fstab-ba. Tessék választani:

sshfs#nasuser@192.168.0.24:/        /media/nas    fuse                       auto,user,_netdev,reconnect,identityfile=/home/user/.ssh/id_rsa_nas,allow_other    0    0 # user interakcióra mount
sshfs#nasuser@192.168.0.24:/        /media/nas    fuse                        defaults,_netdev,reconnect,identityfile=/home/user/.ssh/id_rsa_nas,allow_other    0    0 # induláskor mount
sshfs#nasuser@192.168.0.24:/        /media/nas    fuse.sshfs  x-systemd.automount,user,_netdev,reconnect,identityfile=/home/user/.ssh/id_rsa_nas,allow_other    0    0 # alternatív induláskor mount

Egyszer azért be lehet írni talán az fstab-ba

Senki nem mondta, hogy nem lehet. Az fstab-ba - lévén egy szöveges dokumentum - mindent IS bele lehet írni. Azonban ha valakinek nem kifejezetten az IT a hobbija, nem biztos, hogy ezt állandóan menedzselni akarja. Otthoni környezetben egyszerűen nem életszerű.

Az SMB/Samba megközelítése, ami beépítetten tartalmaz autodiscover-t és szolgáltatás (megosztás) listázást sokkal inkább való otthoni környezetbe. Az SSHFS-t én inkább irodai/munkahelyi környezetben tudom jobban elképzelni, ahol van dedikált ember ezeknek a szerkesztgetésére.

Néha nekem is emlékeztetnem kell magamat arra, hogy attól, mert én forrásból (is) forgatok dolgokat, egy átlagembernek erre abszolút nincs igénye, ahogy a különböző konfig fájlok bizgatására sincs. Nekik még a Vezérlőpult/SystemSettings is bonyolult.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

"nem érzékeny a pillanatnyi kiesésekre"

Az NFS? ROTFL... Megszakad a hálózat a kliens és szerver között, és olyan deadlock lesz, hogy csak RESET-tel tudod újraindítani a gépet. Mindig is kerültem az NFS-t, ahol csak lehet. Teljesen mindegy mit próbáltam, TCP, UDP, soft, hard, sose volt jó, valami szívás mindig van vele.

"valamint kernel szintjén fut"
Pontosan ez a hátránya is. Ezért tudja az egész gépet lerohasztani.

"Sose a gép a hülye."

Ez direkt így készült (30 valahány éve), hogy ha szakad a kapcsolat, újraindul a szerver, földrengés van, jönnek a marslakók, ..., a helyreállítás után a kliens ott folytassa, ahol abbahagyta.

softerr, ami arra van, hogy úgy működjön, mint windowson az smb, az más kérdés, hogy ez valahogy mégse sikerült.

( kikepzo | 2025. 12. 30., k – 10:05 )

Nem tudom ez jelent-e előnyt a biztonság tekintetében, de csak szerver és 1db kliens fog egymással kommunikálni, emiatt is kapott fix IP címet a beállítás.

"https://hunvagyok.hu "

Az a "fix ip-cím" az egészen pontosan annyit tesz, hogy adott ip-címmel jelentkező kliens. És ha UDP-t használó NFS verzióval mész, ez gyakorlatilag a hamvasztott hullának a szentelt víz... De a körülményektől függ, hogy mi az a kockázat, ami tényléegesen jelen van, jelen lehet, és ebből mi az, ami vállalható, és mi nem. 
Volt olyan két gépes rendszer, ahol az auditor kiszúrta, hogy a két gép között rsh/rcp van használatban, masszív és tartalmában is kritikus adatok mozgatására. Rögtön jött a sipákolás, hogy ezt azonnal és sürgősen meg kell szüntetni és csak ssh/scp ilyesmi... Aztán megmutattuk neki (miután kaptunk engedélyt, hogy bevihessük az adott gépterembe), hogy az a bizonyos "hálózati szegmens" egy 1feet hosszú kábel egy secure rack-ben egymás fölé rakott két fizikai szerver között, amihez ha valaki hozzá tud férni úgy, hogy arról adatot lop, akkor már egyébként is mindegy... De volt máshol is jóval korábban rsh/rcp kapcsán auditori rinyálás - ott is pontosan meg tudtuk indokolni, hogy miért az, és miért felvállalt kockázat a használata.

20+ éves történetek... A cél az lett volna, hogy a valós kockázatokhoz kell igazítani a védelmet. Ha NBH-s rendszer van két független gépteremben, akkor köztük az optikát túlnyomás alatt lévő acélcsőben vinni sem túlzás (nyomásesés esetén a rendszer leállítja a forgalmat az érintett linken), de jellemzően nem ilyenre kell lőni... 

( dorsy v | 2025. 12. 30., k – 16:48 )

a kifejezes, amit keresel: tuzfal. :) foleg, hogy tudod a fix ip-t, ahonnan el kell erni.

( Fisher v | 2025. 12. 31., sze – 15:07 )

A topic alapján bárki jobban jár ha LLM-et kérdez, gyorsabb a válasz, kevesebb a sületlenség.

( agostonl | 2026. 01. 03., szo – 11:57 )

Nem akartam a fentiekben trollkodni és most se fogok, de azért a vlan szeparáció jó tipp, hidd el, 30 évnyi üzemeltetéssel a háttérben mondom.
1. Nem függsz, az NFS bug-októl.

2. Van egy külön layer (most nem a vlan a lényeg), ami leszeparálja neked az adatforgalmat, ami sehogyan se tud kijutni a szerver<->storage körből.

3. Ha nagyon paranoiás vagy, még mindig lehet titkositani, bár ha az NFS-t megtörték, akkor már... minek?

Aláírom, hogy van iSCSi, meg sok egyéb lehetőség, de én is futottam olyanba, hogy az iSCSI nem játszott. SMB? 1GB-et nem tudod kihajtani (Ha valakinek sikerült, kérem írja meg a megoldást!).

A VMware egy Ferrari, amit a maffiától bérelsz és mindig a hó elején derül ki éppen mennyi lesz a beszedett díj. 
A Proxmox megy egy Porsche, ami az F1 motorját kapta meg. 
by: jevgenyij

Egyszer volt hogy rá kellett menni a teljesítményre, és akkor egész jó eredményeket sikerült elérni (100MB/s környéke gigabites hálón). Most hirtelen nem találtam leírást, konfig mentést, de TCP_NODELAY rémlik, send és receive buffer size, meg valami raw read/write....

"Sose a gép a hülye."

Azért emlékeim szerint az NFS-sel is masszívan meg kellett küzdeni, hogy ki tudja hajtani a gigabitet. Lehet, hogy SSD-kkel már könnyebb, de HDD-s korszakban iszonyúan latency-érzékeny volt, hiába volt a gigabites hálózat sokszorosát átvinni képes RAID tömb alatta, alapbeállításokkal jó ha 25-30MB/s kijött belőle.

Régóta vágyok én, az androidok mezonkincsére már!

Azért emlékeim szerint az NFS-sel is masszívan meg kellett küzdeni, hogy ki tudja hajtani a gigabitet. Lehet, hogy SSD-kkel már könnyebb, de HDD-s korszakban iszonyúan latency-érzékeny volt, hiába volt a gigabites hálózat sokszorosát átvinni képes RAID tömb alatta, alapbeállításokkal jó ha 25-30MB/s kijött belőle.

Az azért jó régen lehetett, amikor az NFS alapbeállításokkal csak 25-30 MB/s-t tudott... :-)

Csináltam egy gyors tesztet:

Az NFS szerver egy 20+ éves, muzeális értékű Intel Pentium III CPU @ 1.0 GHz egy 3Com 3c940 gigabites hálókártyával, az NFS kliens egy VMware VM (Intel Xeon E-2224 CPU @ 3.4 GHz), a tesztfile pedig egy sparse file (így kihagyjuk a diszk alrendszert).

[root@test-vm ~]# dd if=/mnt/nfs-srv-p3/tmp/test1G.tmp bs=4k of=/dev/null
244140+1 records in
244140+1 records out
1000000000 bytes (1.0 GB, 954 MiB) copied, 21.7924 s, 45.9 MB/s

[root@test-vm ~]# dd if=/mnt/nfs-srv-p3/tmp/test1G.tmp bs=64k of=/dev/null
15258+1 records in
15258+1 records out
1000000000 bytes (1.0 GB, 954 MiB) copied, 26.0526 s, 38.4 MB/s

[root@test-vm ~]# dd if=/mnt/nfs-srv-p3/tmp/test1G.tmp bs=1M of=/dev/null
953+1 records in
953+1 records out
1000000000 bytes (1.0 GB, 954 MiB) copied, 24.1357 s, 41.4 MB/s

Ha a VMware hoston belül egy másik VM-ről másolok, akkor a 10 Gbps-t is ki tudja hajtani:

[root@test-vm ~]# dd if=/mnt/nfs-srv-vm/tmp/test10G.tmp bs=4k of=/dev/null
2441406+1 records in
2441406+1 records out
10000000000 bytes (10 GB, 9.3 GiB) copied, 13.2709 s, 754 MB/s

[root@test-vm ~]# dd if=/mnt/nfs-srv-vm/tmp/test10G.tmp bs=64k of=/dev/null
152587+1 records in
152587+1 records out
10000000000 bytes (10 GB, 9.3 GiB) copied, 9.65892 s, 1.0 GB/s

[root@test-vm ~]# dd if=/mnt/nfs-srv-vm/tmp/test10G.tmp bs=1M of=/dev/null
9536+1 records in
9536+1 records out
10000000000 bytes (10 GB, 9.3 GiB) copied, 6.80892 s, 1.5 GB/s

A mount parancs pedig minden esetben a következő volt:

mount nfs-srv:/ /mnt/nfs-srv -o ro,vers=3,proto=tcp

Hát olyan 15-18 éve lehetett. A részletekre már nem emlékszem, de kellett a paraméterekkel játszogatni (+ még a user-space vs. kernel-space NFS szerver is játszott anno), a HDD IO ütemezőt is állítgatni kellett, mire sikerült kb jó konstellációt találni. Hogy akkor volt-e már NFSv4 és NFS over TCP, azt vissza kéne keresnem. A fő gond szerintem pont, hogy a diszk alrendszer latency-je lehetett, és főleg NFS-re írás irányba. Ez ma már az SSD-kkel nyilván sokkal kevésbé probléma.

Asszem az igazán problémás eset az ESXi, mint NFS kliens volt. Nem VM-eket futtattunk róla, arra az iSCSI nyilván sokkal jobb volt. Főleg install iso-kat tároltunk rajta, amiket be kellett néha mountolni a VM-eknek (ez mondjuk kb ki nem szarja le, ha "csak" 30MB/s). Meg neha VM-eket exportáltunk rá, archiválás vagy backupolási célból. Főleg ekkor volt kritikus, hogy mennyire gyors. Már nem emlékszem ennyire a részletekre, de gyanítom, hogy az NFS-re írást a VMware valami nagyon konzervatív fsync-eléssel csinálhatta.

Régóta vágyok én, az androidok mezonkincsére már!