Samba vs. Win SMB vs. NFS performancia

Hálózatok általános

Samba 3 diadalmas korszaka óta sok idő telt el. Most teljesítményversenyben hogyan áll egymással szemben a Linux/Samba és Windows/SMB ?

Illetve alternatív harmadik versenytársként a NFS. Netes források szerint NFS kis fájlokkal való írás/olvasás műveletekben sokkal gyorsabb az SMB-nél. 

Az alkalmazási környezet, többek között fájlszervernek használt Linux és hozzá csatlakozó különböző kliensek, de most csak a Windows kliens számít. A gépek közötti kapcsolatot Infiniband 40 gigabittel biztosítja így elvárt, hogy a Samba vagy SMB vagy NFS olyan sebességet nyújtson fájlműveletek során mintha helyi HDD illetve SSD-t használnék. Természetesen ha Win/SMB megoldás a nyerő, akkor a Linux fájlszerver helyett Windows lesz, de semmiképp sem Windows server, hanem desktop ltsc kiadás. 
Ha pedig NFS a nyerő megoldás akkor annak Windows kliens oldalon is kompatibilitási problémák nélkül kell működnie.

  • 1865 megtekintés

( zrubi v | 2023. 04. 04., k – 13:58 )

A gépek közötti kapcsolatot Infiniband 40 gigabittel biztosítja így elvárt, hogy a Samba vagy SMB vagy NFS olyan sebességet nyújtson fájlműveletek során mintha helyi HDD illetve SSD-t használnék

Ez nem kicsit 'a valóságtól erősen elrugaszkodott' elvárás.

 

Szerintem.

zrubi.hu

50 euróból szállítással együtt lehet venni Mellanox infiniband kártyát. Mivel a legtöbb eladótól több kártya is vásárolható a szállítási költség is optimálisabb. Teljesen versenyképes az ára a csak 10 gigabites Ethernet kártyákkal szemben. A kábel kicsit drágább mint az utp de az sem vészes.

1 Gigabites ethernet esetén az biztosan szűk keresztmetszet lenne. 40 gigabitnél pedig valóban nem a hálózati kapcsolat lesz a szűk keresztmetszet de ez is a célok között szerepel. 

( ggallo | 2023. 04. 04., k – 14:39 )

Szerkesztve: 2023. 04. 04., k – 14:42

Hát izé... Itt nem a hálózat lesz a szűk (az jellemzően már 10 GbE esetében sem az), hanem a protokollok képességei és a futtató gép hardvere.

Ezen felül milyen diszk alrendszer lesz benne, ami ezt bírni fogja (esetleg több egyidejű kliens mellett is)?

A "Windows esetén nem Windows Server..." részt nem értem. Windows 10 LTSC-t szeretnél használni? Az mennyi klienst támogat? Miért lenne jobb egy desktop OS, mint egy szerver OS, kiszolgáló feladatra? Az ára miatt? Mit beszélünk 40 Gb hálózatról, ha egy Windows Server az ára miatt kiesik? Ha nem az ár a gond a Server verzióval, akkor mi?

Egyébként mi a megoldandó feladat, amire a 40 Gb hálózat az elsődleges tényező, a gomb, és ehhez keressük a kabátot közösen?

Ilyen nagy sebességű hálózatot SMB Direct (RDMA) tudna kihasználni, de ez a Samba-ban még csak a roadmap-en van fent, a szoftverben nincs nyoma tudtommal. Windows Server meg 2012-től tudja. Windows desktop (bármelyik) kizárt, hogy ilyent támogat SMB kiszolgálóként (max kliensként, ezt nem tudom).

NFS esetében Linux-on működik az NFS over RDMA (akár Infiniband akár Ethernet) kliens-szerver oldalon egyaránt, de az, hogy a Windows kliens NFS kliense ezt tudja... Hát, kétlem.

Ezek nem személyes tapasztalatok, csak olvastam, mert érdekelt.

Comparing SMB Direct 3.0 performance over RoCE, Infiniband and Ethernet

"Hát izé... Itt nem a hálózat lesz a szűk (az jellemzően már 10 GbE esetében sem az), hanem a protokollok képességei és a futtató gép hardvere."

Éppen ezért Samba vs. SMB vs NFS a cím és nem infiniband versus ethernet. 

"Ezen felül milyen diszk alrendszer lesz benne, ami ezt bírni fogja (esetleg több egyidejű kliens mellett is)?"

Otthoni hálózat, ezért nem kell kliensek százait kiszolgálni csak maximum kettőt. Egyelőre 3 db HDD és egy SSD (sata) van benne. Később bővülhet még M.2-es SSD-vel. 

"A "Windows esetén nem Windows Server..." részt nem értem. Windows 10 LTSC-t szeretnél használni? Az mennyi klienst támogat? Miért lenne jobb egy desktop OS, mint egy szerver OS, kiszolgáló feladatra? Az ára miatt? Mit beszélünk 40 Gb hálózatról, ha egy Windows Server az ára miatt kiesik? Ha nem az ár a gond a Server verzióval, akkor mi?"

Másról van szó. Mivel 24 órában működik a fájlkiszolgáló Pc ezért egy rá kötött tévét is ki kell tudni szolgálnia. Videolejátszás, dvb-c tévé, zene, hasonló feladatok. Erre pedig pocsék lenne egy Windows Server. Illetve hacsak nem tud kiugróan jobb fájlszerver teljesítményt nyújtani egy Windows Server/SMB mint egy desktop Windows enterprise ltsc/SMB akkor ezért sem lenne indokolt. 

"Egyébként mi a megoldandó feladat, amire a 40 Gb hálózat az elsődleges tényező, a gomb, és ehhez keressük a kabátot közösen?"

A feladat, hogy a fájlszerver Pcbe legyenek koncentrálva a háttértárolók. A többi desktop Pc csak minimál háttértárat kap ami épp az os-nek elég. Mivel Windows hálózati háttértárról nem tud elindulni sem ezért ez nem hagyható el. Így pedig már van hely Linuxnak is dual bootba, szóval csak ezért nem kell NFS. 

"Ilyen nagy sebességű hálózatot SMB Direct (RDMA) tudna kihasználni, de ez a Samba-ban még csak a roadmap-en van fent, a szoftverben nincs nyoma tudtommal. Windows Server meg 2012-től tudja. Windows desktop (bármelyik) kizárt, hogy ilyent támogat SMB kiszolgálóként (max kliensként, ezt nem tudom)."

Egyáltalán nem probléma ha nem tudja kihasználni a 40 gigabites hálózati kapcsolatot. Semmi más oka nincs az infiniband kártyáknak mint, hogy a hálózat ne legyen szűk keresztmetszet, nem kell fullra kihasználni. 

"NFS esetében Linux-on működik az NFS over RDMA (akár Infiniband akár Ethernet) kliens-szerver oldalon egyaránt, de az, hogy a Windows kliens NFS kliense ezt tudja... Hát, kétlem."

Szerintem sem tudj a Windows NFS kliense. SMB (direct) talán tud ilyet. Ja írtad is lejjebb, köszi a linket. 

Otthoni hálózat, ezért nem kell kliensek százait kiszolgálni csak maximum kettőt

LOL

És veszel otthonra egy 40Gb/s switchet is? vagy.... hogyan gondoltad? :)

 

Amit írsz, és ait kérdezel nem igazán metszik egymást. Mellé a 40Gb/s valóban csak 'extra' - de értelmetlen.

 

2 kliens esetében, otthoni dzsunka PC-kkel mégis milyen 'teljesítmnyről' beszélünk?

 

Ráadásul windows kliens meg NFS?! eleve extrém önszivatás. azt sem értem, hogy merült ez egyátalán fel?

Mi a probléma/feladat amit meg akarsz oldani a 'nyertes' technológiával?

zrubi.hu

"És veszel otthonra egy 40Gb/s switchet is? vagy.... hogyan gondoltad? :)"

Az infiniband switch sem drága, viszont gazdaságosabb ebben az esetben +1 infiniband kártya. Két infiniband kártya is összeköthető közvetlenül. 

"Amit írsz, és ait kérdezel nem igazán metszik egymást. Mellé a 40Gb/s valóban csak 'extra' - de értelmetlen."

Akkor ne foglalkozz vele! :-) Egyébként sem ez a téma. Persze, ha helyette tudsz szerinted jobb megoldást írd le! 

"2 kliens esetében, otthoni dzsunka PC-kkel mégis milyen 'teljesítmnyről' beszélünk?"

Define plz "dzsunka PC" !!

"Ráadásul windows kliens meg NFS?! eleve extrém önszivatás. azt sem értem, hogy merült ez egyátalán fel?"

Saját tapasztalat? 

"Mi a probléma/feladat amit meg akarsz oldani a 'nyertes' technológiával?"

Már leírtam. 

"Mi a probléma/feladat amit meg akarsz oldani a 'nyertes' technológiával?"

Már leírtam. 

'Samba vagy SMB vagy NFS olyan sebességet nyújtson fájlműveletek során mintha helyi HDD illetve SSD-t használnék.'

Mármint ez a "feladat / probléma?" :)

Mert ha igen, akkor feltehetem a kérdést, hogy ez miért kell ? Mert ott jön elő az alapvető feladat / probléma szerintem ^^

ps: bocsi csak belekérdeztem :)
ps2: kicsit olyan ez mint mikor a "szakembercég" megkérdezi a terminál szerver kialakítása esetén, hogy ugye CAT6 os a hálózat kialakítása ? De nem kérdezi meg azt hogy ugyan milyen szoftverek futnak a rendszerben :D

Van összesen 20GB háttértáram megosztott használatra hdd&ssd. És van egy non-stop működő Pc. Használhatnék egy konzumér NAS-t ami sokmindenre jó, de nem lesz azonos a fájlműveletek r/w sebessége mint egy lokális háttértárnál. Vagy szétszórhatom a merevlemezeket a 3 Pc között de akkor ha valami arról a Pc-ről kell ami épp ki van kapcsolva ... ugye nem kell most bemutatnom a központi adattárolás előnyeit? 

Szóval a kérdés csak annyi NFS, Samba vagy SMB? Minden más már megvan, a kulcs viszont a megfelelő szoftver kiválasztása. 

Az jutott eszembe ezt olvasva, hogy csinálhatnál tehetnél helyi hdd*-ket a gépekbe, és tehetnél rájuk valami hálózatos fájlrendszert, ami minden változást felmásol a hálózaton megosztott tárhelyre is.

Aztán ha valami arról a PC-ről kell, ami épp ki van kapcsolva, akkor lehúzod a hálózati tárhelyről. Lehet, hogy nem ugyanolyan gyorsan, mint ha helyben lenne, de elérhető.

Tudom, hogy te a helyi hálón akarod megcsinálni, de csak mondom, hogy nekem Google Drive-val van megoldva valami hasonló. Bármelyik gépemen, bármilyen OS alatt ott van lokálban minden, ami gyakran kell, és bármi változás nagyon rövid idő alatt átgyűrűzik a felhőbe aztán a többi gépre.

Feltételezem valami hasonlót lehet csinálni valami owncloud szerű megoldással még akkor is, ha mondjuk Windows alatt nincs olyan hálózati fájlrendszer, amit Linuxokon használnak néhányan**

* vagy ssd, lényegtelen.
** vagy sokan? Nem tudom.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hacsaknem valamilyen labor létrehozása a cél, akkor 10G, akár rézzel (10GBase-T), de ha teheted optikával. 10G-n, ha a jumbo frame és minden megy, mondjuk SMB 3.1/3.2 körül, akkor megfelelő storage-dzsel 1GB/sec kihuzatható.

Egyébként mindenki arra puffantja el a pénzét, amire gondolja. :)

Tehát megtetszett az "olcsó" 40 Gb hálózat lehetősége, és egyébként meglévő random PC alkatrészekből épített gépeket összekötnél vele otthoni használatra, és natív PC teljesítményt várnál hálózaton át, mert gyors a hálózat, az "tudja".

No, hát sajnos ilyen nincs. Durván erősebb szerver és abba komoly diszk alrendszer kell bármilyen hálózat és bármilyen protokoll mellett, hogy a kliensen lokális diszk sebesség érzeted legyen (hacsak nem egyetlen sima SATA HDD 100 IOPS és ~100 MB/s sebességét várod el - de ez 1 GbE hálózaton is megvan, ha nem Realtek hálókártya van a "kiszolgálóban"...).

Szerintem sima desktop kategóriás gépekből építkezve nem kell a hálózati résszel meg a protokoll választással külön foglalkozni. Ha beüzemeled a 40 Gb rendszert és iperf-el tudja ennek legalább a felét-negyedét akkor kész, már több, mint amit a gép többi része össze tud majd hozni. Mivel az összes többi komponens nem lesz alkalmas erre a feladatra, így nem a(z akár csak 10 Gb sebességet tudó) hálózat lesz a szűk. Így egy ilyen összekötés után amit mérsz bármelyik protokollal, az a kiszolgáló oldal limitje lesz (hacsak nem RPi kategóriájú a kliens, mert akkor a kliens limitje).

Ha én ezt a feladatot kapnám, hogy mondjuk 5 felhasználónak adjak olyan storage megoldást, ami mindegyiküknek olyan felhasználói élményt ad, mintha lenne a gépükben egy darab SATA SSD, akkor egy aránylag magas órajeles CPU-val szerelt szervert választanék, és attól függő számú SSD-t, hogy SATA/SAS vagy NVMe csatolósak. Vagy egy kész NAS/storage megoldást, megfelelő paraméterekkel. Meg mellé persze megfelelő sebességű hálózatot. Elméleti sávszélesség kellene 5 kliens esetén is a 20 Gb ennél a feladatnál, tehát egy 25 GbE csatolót tennék minimum. De a valóság több téren közbeszól (pénzügyek és valós terhelés), így indítanék egy 10 GbE hálózattal (ugyanis jellemzően nem tol folyamatosan minden kliens diszk benchmark-ot 0-24-ben, hogy az elméleti sávszél limiten menjenek). Infiniband-et nem néznék, mert az nem erre van elsősorban, és ami pluszt tud, azt ebben a feladatban nem igazán tudnám elhasználni az Ethernet-hez képest.

SOHO szintre nagyságrendekkel olcsóbb a desktop-ba tenni a háttértárat amin dolgozik a user, és csak a közös dolgokat tenni egy (mondjuk úgy) NAS-ra. Ez a "NAS" meg lehet bármilyen 1 GbE-nél gyorsabb kapcsolaton, akkor Ő lesz a szűk keresztmetszet, nem a hálózat. Pláne HDD-kkel...

A gyakorlat: nekem ilyen célra itthon van egy Dell T320 szerver (nem desktop, nem barkács, jó CPU, sok RAM, rendes belsőség, nem Realtek NIC, stb.), abban türközött SSD-ken futó VM-ekben vannak a házi szolgáltatások, és ZFS-en RaidZ2-be szervezett 8 db HDD-n a megosztott adatok. Mindezt 1 GbE hálózattal kötöm össze. RPi kategóriás készülék a Kodi videó lejátszó, ezen kívül PC-k és miegyebek vannak a hálózaton. Nem dolgozunk a szerverre, mindenki a saját gépén él, a szerverre mentés megy a gépekről. Persze vannak megosztott anyagok, de nem olyan volumenű és méretű, aminél észrevennénk, hogy a hálózat nem elég gyors a vele való munkára. Soha az életbe nem volt kevés erre a felhasználásra az 1 GbE hálózat, még ha valamiért nem a szerver tölt le X GB-nyi cuccot, hanem valamelyik desktop, az is bőven jó szerintem, mikor  105-110 MB/s sebességgel felmásolom a szerverre. De leginkább mindent a szerveren futó SW tölt le, és nem kell a hálózaton ilyen volument másolgatni semmi okból.

Azt, hogy mi "mire való" inkább hagyjuk meg a martekingosztálynak. Ha vannak műszaki érveid az Infiniband ellen azt meghallgatom. Például érv lehetne, hogy 'bár nagyobb a sávszélessége az Infinibandnek de a látencia is nagyobb szemben a 10 gigabites ethernettel'. De ez nincs így. Vagy az is lehet érv, hogy 'Infiniband windows drivere rossz, bugos' de ez sem igaz. Jó példát persze nem tudok írni, mert mindenben jobb az Infiniband. A "Nem erre van" viszont nem objektív érv önmagában. Ráadásul már megvan. Meg tök mellékes háttérinfónak szántam. 

"A gyakorlat: nekem ilyen célra itthon van egy Dell T320 szerver (nem desktop, nem barkács, jó CPU, sok RAM, rendes belsőség, nem Realtek NIC, stb.)"

"Barkács" az az érzésem, hogy sokan itt a hup-on megrekedtek a 2000-es évek első felének flame háborúiban. Itt összesen 2 db másik Pc kiszolgálásáról van szó és nem kell jobbnak és gyorsabbnak lennie mintha azoknál helyben lenne a háttértár. Ugyan miben tudna egy szerver hardver többet?! Adott pénzből valószínűleg újabb, gyorsabb, több magos CPU lesz a "barkács" PC-ben több ram társaságában. Ami nem lesz, ECC-ram ide minek? SAS, továbbra sem irodaházat kell kiszolgálni 250 munkaállomással, szóval az is minek? Redundáns tápegység, ide végképp felesleges! Xeon, na az valóban felesleges pénzkidobás lenne. A bontószökevény Xeon cpukat meg ne hasonlítsuk már egy mai erős desktop cpuhoz! 

Csak, hogy én is éljek pejoratív jelzős szerkezetekkel, ha választanom kell egy kukázott 10+ éves Pc szerver és egy új, modern garanciális, egyébként erős desktop Pc között mindig az utóbbit fogom választani. Otthonra pláne. 

A valódi témáról, {NFS vagy Samba} megint egy szó sem esett. Kár volt leírnom az Infinibandet, mert elterelte a figyelmet a lényegről! 

Szó sincs itt az Infiniband-ról. Arról van szó, hogy Te desktop-on lokális diszk sebességet vársz egy hálózati megosztástól, és azt hiszed, hogy a megoldás az, ha gyors a hálózat, és akkor a HDD/SSD teljesíménye csak úgy átmegy majd a másik gépre. Pedig nem, mert a hálózat nem PCIe sávokat vagy SATA portokat visz át, hanem ennál jóval magasabb szinten "adatot", sokszor több, egymásba ágyazott prótokollon (amiket nem lehet kihagyni), és ez teljesímény veszteséget okoz. Valamit valamiért, teljesítmény veszteség az osztott/távoli használatért cserébe. Namost ha ezt a teljesítmény veszteséget kompenzálni akarod, akkor a kiszolgáló oldalra erősebb minden kell, hogy mire az a kliens oldalra ér, még mindig számodra elég legyen. Pláne ha több kliens van, mert akkor nagyjából lineárisan skálázni kell ezzel a kiszolgáló oldalt. Egy bizonyos teljesítmény felett ráadásul még a kliensnek is elég erősnek kell lennie, hogy a nagy adatmennyiséget fogadni és feldolgozni is tudja.

Az Infiniband azért nem jó ide (pontosabban jó, de felsleges), mert amit tud a sima Ethernet-hez képest, azt nem tudod kihasználni megfelelő szoftveres (és sima desktop PC esetén lehet, hogy hardveres) támogatás hiányában. Egy desktop CPU-ban van mondjuk 20 PCIe vonal. Abból 16 megy a VGA csatoló x16 slot-jához, a maradék 4 pedig megy a "déli" hídhoz, amire van kötve még néhány PCIe foglalat meg egyéb eszköz, és multiplexel a híd minden sávot feléjük. Ha a 40 Gb Infiniband kártyádat nem a x16-os foglalatba dugod, akkor kapásból sose lesz 40 Gb, mert a PCIe 3.0 x4 elméletben is "csak" 32 Gb, ráadásul azon osztozik minden más is a kártyáddal és egyébbel (USB portok, SATA portok, stb.). Egy szerverben meg van egy olyan CPU aminek van 30-40-60 PCIe vonala, és minden foglalatban minden vonal natív sebességű, nem multiplexelt, ergo ki tudod venni a teljesítményt teljes egészében. Persze ez erős egyszerűsítés.

Dekstop PC esetén azon az x4 csatornán jön a hálókártyától az adat ami a híd által multiplexelve van, bemegy a hídon keresztül a CPU-ba, majd onnan a hídon keresztül, ugyanazon x4 multiplexelt csatornán visszamegy a SATA vezérlőn keresztül a HDD-re. Ugyan ez történik amikor "csak" 10 GbE a csatoló, szóval nem ez vagy az a hálózati csatoló lesz a szűk keresztmetszet, hanem a gagyi desktop PC architektúra.

Ha ezzel dolgoznál napi szinten, akkor a 10 éves szervert választdanád az új desktop helyett kiszolgáló feladatra. Ezen mindenki átesik, aki hobbistából lesz szakmabeli és átél/megtapasztal  dolgokat. Amennyiben modern desktop CPU-ban látnál fantáziát mégis, akkor meg vennél mondjuk Supermicro vagy Asrock rack alaplapot hozzá, hogy rendes szerver szintű hardveres képességeket kapj. Egy desktop gépet akárhogy csavarod, desktop gép marad, és nem a tudásodtól függ, mennyit tud, hanem attól, hogy mire szánta a gyártó (nem kiszolgálónak).

Azt gondolom, hogy vettél olcsón Infiniband cuccokat, összeraktad, és nem jön a teljesítmény. Erre azt gondolod a rossz protokoll vagy rossz OS választás miatt. Holott egyszerűen a hardvereid nem tudják.

Amennyiben Windows klienseid vannak, én azt javaslom, hogy tegyél egy Windows-t (bármilyent) a "szerver" gépre, és SMB megosztással operálj. Az lesz a legkényelmesebb, és valószínűleg Windows-on lesz a legjobb az Infiniband kártya támogatása is (pláne, ha régebbi, mert gondolom nem új van olcsón).

Ezért kell AMD Ryzen-t venni Intel Core helyett! Számtalan hátránya mellett többek között ezért szar a "16 lane mindenre elég" intel :) 
AMD Ryzen-eknél 24 lane jár a desktop-ba. Egyes Intel Core i9-eseknél van ugyan 48 lane, de olyan áron amiért már inkább AMD Threadripper-t veszek, ami mindenben veri az Intelt. 

Nem teljesen erről van szó azért. Egy (talán még nincs 10 éves) Dell R430 belső sávszélessége se több 10-11 GBitnél.
Azaz egyik virtuális gépről a másikra iperf például (tehát itt még diszkműveletről sincs szó).

Ezt egy (laptop) M1 rommá veri. Az M1-en az SSD-ről lejön 3 GByte (24 GBit) másodpercenként bármikor.
Na ezt a 3GByte-ot, 1millió IOPS-t, meg a nemtudom milyen latency-t te szervertől (hálózaton át) sose fogod megkapni.
Egy klienssel se. Szerveren belül persze meg tudod csinálni, _néhány_ kliensre, irdatlan pénzért. De nagyon sokra ott sem.

Gábriel Ákos

Na de a "belső sávszélesség" VM-ek közötti iPerf esetén teljesen CPU-ból szoftverből megy, ahhoz nagyjából semmi köze a PCIe vonalaknak meg a hálózati csatolóknak...

Pont az ilyen szűk keresztmetszetek miatt van az RDMA, hogy ne kelljen über CPU-t venni, ha nagy sávszélesség kell valahová. De az RDMA-t úgy a hardver minden elemének, mint a szoftvereknek támogatni kell, mert egyébként vagy nem működik, vagy fallback a szoftveres, CPU-n keresztül futó sokkal lassabb megoldásokra.

Egyébként 3 GB/s (vagy akár több), meg 1 millió IOPS nem lehetetlen osztott erőforrásként (persze nem per kliens, hanem összeen; bár nem olcsó, de már összerakható földi halandóknak is), ellenben a helyi NVMe SSD latency-jét sose fogja tudni, akármi csinálunk vele akármennyi pénzért. Mondjuk valószínű nem vertikálisan (egy mega szerverből épített), hanem horizontálisan skálázott rendszerrel (pl. Ceph).

Mivel 24 órában működik a fájlkiszolgáló Pc ezért egy rá kötött tévét is ki kell tudni szolgálnia. Videolejátszás, dvb-c tévé, zene, hasonló feladatok. Erre pedig pocsék lenne egy Windows Server.

Hát izé. Erre a feladatra nincs szükség se 40Gbitre se a fájlkiszolgálók versenyeztetésére és a jelenlegi (akármi is az) kicserélésére.

Nálam egy BananaPi-n futó Raspbian szolgálja ki Sambán a SATA-n rákötött hdd-ről a TV-t. Pi-router 1Gbps ethernet, onnan a TV-ig meg WiFi-n keresztül.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( bennyh | 2023. 04. 04., k – 15:32 )

Szerkesztve: 2023. 04. 04., k – 15:46

Valahol (én is :) ) azt láttam, mintha az NFS jobban teljesítene földközelibb hálózatokon sok kis állománnyal szüttyögés közben, nagy állományok mozgatásánál meg fej-fej. De ekkora sebességnél passz.

PS: Nem csak a címet kellett volna elolvasnom :)

Sokak fantáziáját megmozgatta és el is térítette az Infiniband. :-) De valóban fel sem merült, hogy 40 gigabiten várnám az olvasási és írási műveleteket. Nincs ebben több minthogy a gigabit ethernet lassú, szűk keresztmetszet lenne. A 10 gigabites ethernet kártyánál pedig olcsóbban lehet kapni Infiniband kártyát és az 40 gigabit. 

Ha a hálózati fájlszerveres háttértárak megközelítőleg olyan írási/olvasási sebességgel és csak picit rosszabb látenciával érhetőek el mintha helyi merevlemezek és ssdk lennének az megfelel. Az eddigiek alapján az SMB és Samba is nagyobb overheadet jelent mint az NFS, ezért az utóbbi tűnik most jobb megoldásnak. Persze csak akkor ha semmilyen kompatibilitási probléma nincs Windows kliensen. Azaz tetszőleges program pont úgy működik NFS-ről mint helyi háttértárról. Linuxon nem merül fel ilyen probléma, így az nem kérdés. 

Ha már van ez a téma, továbbra is érdekel ettől függetlenül, hogy Samba vs. SMB-re szűkítve hogyan áll mostanában teljesítményben ez a kettő? 

( gabrielakos v | 2023. 04. 04., k – 16:29 )

Tudom hogy az iSCSI másik réteg de nem biztos hogy kihagynám az összehasonlításból.

Nekem csak gigabites (2x1) tapasztalataim vannak, ami nem biztos hogy releváns, de NFSV4 egyértelműen gyorsabb mint az SMB, főleg erre optimalizált (Synology) Linuxon.

Gábriel Ákos

Jogos, a témához kapcsolódik.

Nálam a hardver már megvan, így a sata driveok is. Az iSCSI-nél erre kellene valamilyen wrapper réteg gondolom ha van ilyen. Virtualiziáció már biztosan megoldást jelent SATA mellett is iSCSI-ra. Illetve valós háttértármérettől független virtuális háttértárolókat lehet így kialakítani. Problémát ott látok, hogy kevésbé rugalmas home hálózaton. A fájlok így nem lennének egyszerre elérhetőek a fájlszerver és kliens gépeken. Illetve ha valami történik a hálózati kapcsolattal, megrágja a macska a kábelt :) vagy egyéb módon megszakad az iSCSI-nél azért okozhat problémát, nem? 

( hunluki | 2023. 04. 04., k – 18:52 )

Bár kicsit off mert pont a másik véglet, de hátha valakinek hasznos lehet:

Rpi 4-re kötött HDD-kből csináltam itthon NAS-t, samba nagyon megbízhatatlan volt, lassú, random disconnectelt, minden baja volt. Utána NFS-re mentem át ami egy júzerrel tök jól működött, SMB-hez képest ég és föld tempóban és megbízhatóságban de szembejött hogy több usert is ki kéne szolgálni, illetve kvótázni őket, itt elakadtam és elengedtem.

Most nextcloud-al van megoldva a dolog és gyönyörű szépen működik. Konkrétan az egész családnál kiváltottam az icloud/google one témakört, netről is elérhető duckdns-nek hála.

Kicsiben frankón működik, nem tudom hogy ha komoly sávszélt raksz alá akkor hogyan skálázódik. Dockerből pikk-pakk fel lehet rántani, próbát megérhet.

( mauzi v | 2023. 04. 04., k – 19:27 )

Szerkesztve: 2023. 04. 04., k – 19:28

Nálam Debian 11 van, Samba és NFS egyaránt, 10 gigabites Ethernet fölött.
iperf, TCP raw socket, iSCSI, Apache + CURL, (stb.) bombabiztosan hozza a ~9,7 gigabitet.
NFS-sel nem nagyon tudok 3-4 gigabit fölé menni, a Samba meglepő módon gyorsabb, kb. 5-6 gigabitet hoz. Ezek nagyméretű (sok gigabájtos) fájlok, amiket nagy blokkmérettel lehet másolni.

A háttértár SSD RAID, ami helyben 2GiB/sec sebesség fölött írható és olvasható, és IOPS is annyi van, mint a szemét.

Mi a megoldás arra, hogy a fájltranszfer gyorsabb legyen?
Preferálnám egyébként az NFS-t. Jó volna elérni legalább 7-8 gigabitet...

Aztán azt is megnézheted, hogy biztos nem valamelyik host a szűk keresztmetszet (CPU, háttértár terhelés NFS művelet közben).

Két unatkozó szerver között másolok, laborkörnyezetben.

Ha ugyanazt a fájlt A szerverről B szerverre átszippantom HTTP felett, akkor megy 9,7 gigabittel. Ha NFS share-ről másolom, akkor kb. 3 gigabittel, ha pedig sambaról, akkor kb. 6 gigabittel.

Lehet csak én nem fogom ezt az egészet. De nem tudom mi értelme van 40Gbites hálón kiszolgálni egy max 6Gbps buszsebességű meghajtóról klienseket.

A SATA3 kb 600MB/s átvitelt tud (750-protokoll veszteség), SCSI is valahol ezen a téren mozog.
Szóval a diszkből nem fog kijönni nemhogy a 40Gbit, de a 10Gbit se.

SSD-nél mondjuk lehet más a helyzet, ha nem SATA M2, hanem NVME.

Mondjuk bizonyára benézek valamit, szóval előre is mea culpa. :)

Talisker Single Malt Scotch Whisky aged 10 years - o.k. Yamazaki is playing as well :)

Azt mondta, hogy az 1 Gbit túl szűk. 1-nél több lehet 10Gbit ethernet vagy 40Gbit IB. Az IB olcsóbb, tehát azt választotta.

Gondolom nem az a lényeg, hogy IB, vagy mennyi a max, amit tud, hanem ha legalább 10-et tud és olcsó, akkor azt veszi.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

én nem vettem észre, hogy azt mondta volna, hogy az 1Gbit túl szűk. Bizonyára átsiklottam felette.

Viszont azt meg mondom, hogy 10Gbit-es hálót már a SATA3 6Gbps sávszéle simán korlátozza. Ergo tök felesleges 40Gbites hálót alárakni. Optimális esetben 600-650MByte/s-t tud realizálni max.

Talisker Single Malt Scotch Whisky aged 10 years - o.k. Yamazaki is playing as well :)

Nem ez volt  a kérdés, de van ez így. Nem mondanék olyat, hogy elég nagy mostmár a RAM, elegendően gyors a CPU, nem kell már gyorsabb lemez, hálózat. Persze lehet elmélkedni, kell-e , van ahol néhány node, osztott adatok, "replikált"  lemezek  és a 10GBe -re már panaszkodnak, hogy lassú.

És akkor jöjjön a mesedélután: NFS vs SAMBA, SMB: hogy melyik a gyorsabb, általánosságban nehéz megmondani. Úgy általában  szerintem jobb a Win/smb asztali windowsokhoz, mint az NFS.
De a lemezhasználatnak két véglete  van, a nagy szekvenciális puffrelt irás/olvasás (videofájlok stb) , a másik a szervereknél a nagy iops igényes kis blokkok random irása olvasása. Ebben meg asz SMB-t tartják roszabbnak. Illetve azt olvasom a neten- ezt nem mértem le- , hogy az asztali gépeken az SMB figyelmen kívül hagyja a szinkron írási kérelmet, pufferel mindig -állítólag. Netán  ZFS-t használsz sambával az egyik gépen, a másikon NFS-st ext4 -gyel. Egyik gépben NVMe asztali ssd, másikban "csak" DC satás, mégis 10x gyorsabb lesz a satás az iops igényes környezetben, de videot ezzel csak 500 MB/sec -kel másolhatsz.

https://blog.claryel.hu

Létezik "tuningolt" NFS:

nfs-ganesha
> https://github.com/nfs-ganesha/nfs-ganesha
repository
> https://download.nfs-ganesha.org/

Ennek megfelelően szerver/kliens oldalon is ezt kell felrakni.

Még annyi a trükk, hogy a mount paraméterbe

vers=4.2

( kleinie | 2023. 04. 04., k – 19:45 )

Szerkesztve: 2023. 04. 04., k – 19:56

Jó lesz az teljesítménynek is!

De csak azért hogy a témánál maradjunk: Raspberry Pi 2B+, külső USB meghajtó, ha jól emlékszem Raspbian van rajta. Sokáig Samba megosztásként használtam egy Mi Box S-re telepített Kodi alól. Sokszor akadozott a lejátszás. Aztán gondoltam egyet és sima NFS megosztásként vettem fel. Azóta semmi baj nincs vele. Sebességtesztet nem végeztem, szóval számokkal nem tudom igazolni.

Nyilván minimál teljesítményű gépen jelentkeznek ilyen különbségek. Ha pl. Pi3 a Kodi oldal, akkor az sem mindegy, hogy a Kodi kapcsolódik NFS-en (az egyébként nagy teljesítményű szerverhez), vagy az OS kapcsolódik NFS-en és a Kodi "helyi" mappaként éri el a mount-ot.

De jelen feladatnál szerintem el kell vetni a host szűkösségéből adódó problémákat, mert ha a host szűkös erőforrásban, akkor nincs az a csoda protokoll, amivel nagy lesz az átviteli sebesség.

( vasla_ | 2023. 04. 05., sze – 02:22 )

Szerkesztve: 2023. 04. 05., sze – 02:34

 A gépek közötti kapcsolatot Infiniband 40 gigabittel biztosítja így elvárt, hogy a Samba vagy SMB vagy NFS olyan sebességet nyújtson fájlműveletek során mintha helyi HDD illetve SSD-t használnék.

 

Ahogy egyre kisebb blokkméreteket használsz ez egyre kevésbé lesz azonos. Nagy blokkok (jumbo frémek/video fájlok, filmek) aszinkron irásánál szerintem az nvme max irási sebességét el lehet érni, van is a neten egy csomó kép erről.
Viszont ahogy csökken a blokkméret (adatbázisok ,VM-ek) ez már változik:

Egy mérés  -windows alatt  , ugyanaz a lemez c: illetve  , net use  megosztással (z:)ugyanazon a gépen, ugyanaz az alkönyvtár:

 

PS C:\!> fio --name=ssdtest --filename=testfile1 --size=10M --bs=16k --iodepth=16 --rw=randwrite
fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
ssdtest: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=windowsaio, iodepth=16
fio-3.13
Starting 1 thread

ssdtest: (groupid=0, jobs=1): err= 0: pid=21376: Wed Apr 5 02:12:55 2023
  write: IOPS=24.6k, BW=385MiB/s (403MB/s)(10.0MiB/26msec)
    slat (usec): min=23, max=217, avg=36.19, stdev=14.11
    clat (usec): min=3, max=894, avg=305.57, stdev=167.60
     lat (usec): min=36, max=930, avg=341.76, stdev=170.27
    clat percentiles (usec):
     |  1.00th=[   36],  5.00th=[   43], 10.00th=[   77], 20.00th=[  135],
     | 30.00th=[  194], 40.00th=[  245], 50.00th=[  302], 60.00th=[  351],
     | 70.00th=[  412], 80.00th=[  469], 90.00th=[  537], 95.00th=[  562],
     | 99.00th=[  668], 99.50th=[  709], 99.90th=[  898], 99.95th=[  898],
     | 99.99th=[  898]
  lat (usec)   : 4=0.16%, 10=0.16%, 50=5.47%, 100=7.03%, 250=27.66%
  lat (usec)   : 500=44.38%, 750=14.69%, 1000=0.47%
  cpu          : usr=0.00%, sys=0.00%, ctx=0, majf=0, minf=0
  IO depths    : 1=0.3%, 2=12.8%, 4=26.9%, 8=53.4%, 16=6.6%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=93.7%, 8=0.0%, 16=6.3%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,640,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=385MiB/s (403MB/s), 385MiB/s-385MiB/s (403MB/s-403MB/s), io=10.0MiB (10.5MB), run=26-26msec

 

Ugyanaz a lemez : (net use z: \\asztaligep\c

PS Z:\!> fio --name=ssdtest --filename=testfile1 --size=10M --bs=16k --iodepth=16 --rw=randwrite
fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
ssdtest: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=windowsaio, iodepth=16
fio-3.13
Starting 1 thread

ssdtest: (groupid=0, jobs=1): err= 0: pid=10856: Wed Apr 5 02:13:44 2023
  write: IOPS=8648, BW=135MiB/s (142MB/s)(10.0MiB/74msec)
    slat (usec): min=39, max=446, avg=64.49, stdev=42.49
    clat (usec): min=2, max=1657, avg=533.68, stdev=343.75
     lat (usec): min=49, max=1848, avg=598.17, stdev=349.73
    clat percentiles (usec):
     |  1.00th=[    4],  5.00th=[   56], 10.00th=[  104], 20.00th=[  208],
     | 30.00th=[  306], 40.00th=[  400], 50.00th=[  498], 60.00th=[  594],
     | 70.00th=[  701], 80.00th=[  807], 90.00th=[  988], 95.00th=[ 1156],
     | 99.00th=[ 1483], 99.50th=[ 1516], 99.90th=[ 1663], 99.95th=[ 1663],
     | 99.99th=[ 1663]
  lat (usec)   : 4=1.25%, 10=0.47%, 50=0.47%, 100=6.25%, 250=16.09%
  lat (usec)   : 500=25.47%, 750=24.69%, 1000=16.09%
  lat (msec)   : 2=9.22%
  cpu          : usr=0.00%, sys=0.00%, ctx=0, majf=0, minf=0
  IO depths    : 1=1.9%, 2=13.1%, 4=26.3%, 8=52.3%, 16=6.4%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=93.8%, 8=0.0%, 16=6.2%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,640,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=135MiB/s (142MB/s), 135MiB/s-135MiB/s (142MB/s-142MB/s), io=10.0MiB (10.5MB), run=74-74msec

Nem egyforma a két sebesség , a mérésben csak a protokoll "lassit" , hálókártya még sehol. 

TrueNas tudja az nfst, iscsi-t, samba-t azzal ki lehet próbálni , mik a különbségek. 

https://blog.claryel.hu

( igiboy | 2023. 04. 05., sze – 08:09 )

Az Infiniband nekem is megmozgatta kicsit a fantáziámat. Viszont ahogy látom az IB nem ethernet bár van IBoE amivel gondolom minden átvihető ami etherneten is akár legyen az NFS vagy SMB vagy bármi socket kapcsolat.
Némelyik (használt) eszköznek tetszetős az ára. Elcsábul az ember, hogy ennyiért 40 Gbps kapcsolatot tud kiépíteni. Viszont sok év tapasztalata azt mondja, hogy az ilyen dolgok általában a "mélytorkos orális sex"-hez vezetenek. Biztos van valami speciális követelmény vagy olyan dolog amit nem lehet csak úgy használni, ahogy elképzelte az ember.
Gondolom van olyan aki használ ilyet itt. Mondhatnátok 1-2 információt, hogy működik-e, hogyan, mi kell a működéséhez pl. egy 2-4 gépből álló rendszerhez. Akár egy labor környezet kialakításához.

- QSFP DAC kábel jó hozzá? 
- QSFP-s switch vagy kifejezetten infiniband-re való switch jó csak? (tippre csak a második, mivel az IB nem ethernet)
- összeköthető 2 kártya switch nélkül? (olyat olvastam, hogy nem)
- ha ethernet interfészként kell használni mennyi a sebesség veszteség, vagy lehet IB módban használni akár NFS-re?

Az a helyzet, hogy amire a topicindito hasznalna az IB-et, arra ez egy irgalmatlan szivas lesz. Rajzlapon jol nez ki a 40G, de eleve nem ethernet protokoll van. Kapasbol bukik majd azon h eoib-t kell hasznalnia. 
ezen kivul az ethernet halozat nem lesz elhagyhato, tehat majd lehet menedzselni ket halozatot, mert gondolom az internet gw nem ib-es. 
a p2p osszekotes megoldhato sw nelkul 1:1 ben. De akkor a szerveren annyi kartya kell amennyi kliens van. Ez sem tunik kis szivasnak. 
es akkor a protokollok: eleve konvertalni kell eoib retegben majd, ezzel no a latency es valoszinu borul a lehetseges rdma kepesseg. 
a vegeredmeny varhatoan az lesz h lesz egy lassu, nehezen adminisztralhato es karbantarthato egzotikus ize, amiben hiba eseten napokig konyekig lehet turkalni. 

a cool faktort persze nem vitatom. 

 

hogy kicsit ontopic legyek: samba4-el, jo hattertarral 7-8Gbps elerheto, ha nem ocska a nic es minden jol be van love (lasd offloading es stb)

sok kis fajlos kornyezetben tobb userrel, windows klienssel az nfs teljesen felejtos. Mar csak azert is mert nem tud byte range lockingot meg oplockingot, az pedig eleg sok Windowsos “izenek” kell. 

Mellanox (mostmár NVIDIA) -nak a ConnectX IB kártyájából van két fajta, amiben benne van a "VPI" (drágábbik) az tud natívan ethernet kártyaként is működni, akkor működik simán bármilyen ethernet-switchen.

Közvetlen összekötés is működik tudtommal, csak valamelyik gépen kell futtatni egy "IB subnet manager" pl.: opensm. Végeredmény ugyan az lesz mint pl.: ethernet kártya lenne, IB interface-nek adsz IP-t mindkét oldalon és kész is van.

( igor | 2023. 04. 05., sze – 19:55 )

Szerintem amire neked itt szukseged lehet az szetdobalt diskek minden gepbe es egy torrentsync vagy hasonlo.

Hacsak nem az a konkret feladat, hogy ezeket a technologiakat osszeoarositsd es megmerd a teljesitmenyuket akkor teljesen ertelmetlen.

4-8k video vagashoz, szokott ilyen usecase lenni de azt is inkabb Thunderbolttal oldjak meg 1-1 gepen.

Mit ad hozza az otthoni gepeken vegzett feladatok sikeressegehez es/vagy gyorsasagahoz az ha par milliseccel hamarabb nyilik meg egy fajl?

( dorsy v | 2023. 04. 06., cs – 11:22 )

Szerkesztve: 2023. 04. 06., cs – 11:26

"olyan sebességet nyújtson fájlműveletek során mintha helyi HDD illetve SSD-t használnék"
Lehetetlent kergetsz :)

Ahogy a kollega is elvegezte helyetted a hazi feladatot itt: link

A szuk keresztmetszet nem a halozat atviteli sebessege, hanem az extra latency, ha megnezed a kommentet is vilagosan latszik a kulonbseg amit csak a tcp/ip stacken+smb protokollon attolas es az esetleges dupla filerendszermuvelet okoz (nfs, smb is FS-en van a hoston).

( lcsaszar v | 2023. 04. 06., cs – 14:59 )

4k video sebességét 30 Mb/s-nek mértem. Erre és otthoni fájlmegosztásra nekem egy NAS tökéletesen megteszi.

Ez mondjuk erosen "attol fugg". Telefonok manapsag tenyleg nagyjabol 32Mbit/s-en rogzitenek 4k videot. Viszont egy rendesebb fenykepezogep siman tud 300-400 Mbit/s-en is felvenni h.265-ben. A legjobbak kb 700-800Mbit/s-en tudnak rogziteni (ez meg mindig csak 4k vagy DCI4k esetleg valamilyen "open gate" 5-6k). Es akkor az igazan profi vonalon meg innen kezdodnek folfele a ProRes RAW dolgok, 2+ Gbit/s-el. Szoval ha valaki nemcsak otthoni hobbivideozasra hasznalja, akkor eleg komoly NAS es halozat kell a vagashoz.

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

Hát, amikor 200-1000 Mbit/s sebességű videó állományok hálózati tárolóról vágása a feladat, akkor hálózati tároló oldalon nem desktop PC-ről és benne néhány HDD-ről és SSD-ről, kliens oldalon meg nem sima PC-ről minimál háttértárral hardverről beszélünk... :-D

A lejátszás teljesen más tészta, mint a feldolgozás. Akár FullHD, akár 4k, a kész videóanyag nem lehet olyan túl nagy bitsebességű (a forrás anyag közelébe sem jöhet), mert akkor az internet kapcsolat válna szűk keresztmetszette. Lejátszásra alkalmas 4k anyag mindig marad néhányszor 10 Mbit/s, szerintem.

Wikipedia szerint a sima blu-ray max. 54 Mbps, az UHD pedig 128 Mbps.

Youtube esetén azt találtam, hogy a feltöltésnél a 1080p-t 8 Mbps-el, a 4K-t ~40 Mbps-el javasolják feltölteni.

Szerintem a lejátszás még kisebb bitrátával megy, mert emlékeim szerint 5 megás nettel is tudtam nézni full HD streamet.

( debtamas88 | 2023. 04. 06., cs – 23:30 )

Szerkesztve: 2023. 04. 06., cs – 23:49

Topiknyitónak minden kérdésére a válasz a videóban:

https://www.youtube.com/watch?v=NAks6qM9jlM
https://www.youtube.com/watch?v=-LytcXun4hU

Röviden:
- SMB nem lesz gyorsabb 40G kártyán - (1szálon megy, hogy többszálon nagyobb sebességen működjön, mást kell használni pl.: RoboCopy )

RoboCopy GUI:
https://github.com/Cinchoo/ChoEazyCopy

( Caro | 2023. 04. 06., cs – 23:41 )

Én ilyen környezetben biztosan maradnék az Ethernetnél. 2.5 G megfizethető, 5/10 G már zsebbe nyúlósabb. De aztán lehet bővíteni, minden támogatja.

Diszk meg úgyis kell a gépekbe, mert gondolom nem TFTP-ről fognak bootolni. Így a sok kis fájlt nem is értem, az ember általában kevés fájllal dolgozik. Sok fájlt pl. fordításnál tudnék elképzelni, de azt meg úgyis verziókövetném, és a lokál gépen tárolnám.