Linuxos gépeket milyen hálózati fájlrendszerrel kössek össze?

Hálózatok általános

Sziasztok!

Adott 4 db Windows XP Home-al megáldott gép. Az egyik gép megosztott C: meghajtójáról történt a számlázás, bevételezés, készletnyilvántartás, könyvelés, bankolás és mindenki össze-vissza mentegette az általa készített/módosított dokumentumokat.
Egyik öregebb gép, mint a másik és a fejetlenség a tetőfokára hágott.

Kitaláltuk, hogy beteszünk egy 5. (Linuxos) gépet, ahová az eddig szervernek kinevezett gép helyett dolgozhatnak mind a 4 gépről. A gépbe 2 db 1 TB-os HDD került ext4 filerendszerrel, LVM-el, (szoftveres) RAID 1-ben a biztonság növelése érdekében, de ezután mentések is fognak készülni offsite. :)

Az új "szerver" gép természetesen "szegény ember szervere", egy mezei desktop gép 8 GB (2x4 GB) 1600 MHz-es DDR3 Kingston RAM-al, 2x1TB 7200 RPM Seagate HDD, Gigabyte B85M-DS3H alaplap, Intel 1150 G3220 3GHz proci, Gb-es router és Switch, CAT.6-os kábellel összedrótozva a gépek.

A kézenfekvő hálózati protokoll fájlrendszer a Samba lett volna, ha a Linux -> Win másolás sebessége nem negyede, ötöde lenne a Win <-> Win másolás sebességének ugyan azon a hálózaton. (13 MB/s vs. 49 MB/s)

A Windows szerencsére nem feltétele a programok működésének és a döntéshozó sem idegenkedik a linuxtól.

Találmányom lényege az lenne, hogy minden gépre openSUSE 13.1 kerül, de a kérdés, hogy milyen módon kössem őket hálózatba?

Teszteltem a Samba és az NFS sebességét 12890 db fájllal, aminek össz. mérete 4447 MB.
Minden teszt előtt cache ürítés, szerver újraindítás történt.

Szerk.: folyamatosan kiegészítem a hozzászólásokban ajánlott beállításokkal végzett tesztekkel a táblázatot 

Nagy fájl másolás (kb. 20 GB-os fájl)
Linux tmpfs -> Linux NFS (ext4):   kb.  71 MB/s (rw,no_root_squash,sync,no_subtree_check)
Linux tmpfs -> Linux NFS (xfs):    kb.  71 MB/s (rw,no_root_squash,sync,no_subtree_check)
Linux tmpfs -> Linux NFS (ext4):   kb.  75 MB/s (rw,no_root_squash,async,no_wdelay,no_subtree_check)
Linux tmpfs -> Linux Samba (ext4): kb.  71 MB/s
Linux tmpfs -> Linux sshfs (ext4): kb.  73 MB/s

12890 db fájl másolás (összesen 4447 MB)
Linux tmpfs -> Linux NFS (ext4):   kb.   2 MB/s (rw,no_root_squash,sync,no_subtree_check)
Linux tmpfs -> Linux NFS (xfs):    kb.   2 MB/s (rw,no_root_squash,sync,no_subtree_check)
Linux tmpfs -> Linux NFS (ext4):   kb.  43 MB/s (rw,no_root_squash,async,no_wdelay,no_subtree_check)
Linux tmpfs -> Linux Samba (ext4): kb.  33 MB/s
Linux tmpfs -> Linux sshfs (ext4): kb.  38 MB/s
Linux tmpfs -> Linux sshfs (xfs):  kb.  38 MB/s
Win XP HDD  -> Win XP HDD (NTFS):  kb.  30 MB/s

Gépen belül 12890 db fájl másolás (összesen 4447 MB)
/ (ext4) -> /srv/szerver/ (ext4):  kb.  65 MB/s
tmpfs    -> /srv/szerver/ (ext4):  kb. 125 MB/s

Gbites hálózat, routeren és switchen keresztül összekötve a két gép.

A 

hdparm -t /dev/mapper/SrvVolume-Server

186 MB/sec sebességet mér.
Szeretném, ha a Gbit-es hálózat maximális sebességét minél jobban meg tudnánk közelíteni mind kis fájlok másolásánál, mind nagy fájlok esetében, de egy 60 MBps körüli sebességgel már kibékülnék. A legnagyobb fájl egyébként jelenleg 380 MB.

A Samba Recycle funkciója is jól jönne, ha megoldható.

Milyen hálózati fájlrendszert ajánlotok, vagy a jelenlegieken milyen módosítást eszközöljek?

  • 10754 megtekintés

( blr v | 2014. 05. 21., sze – 19:41 )

Mintha le is írtad volna a lényeget: a samba és az nfs között a samba felé dől a mérleg.
A Linux <-> Win másolás sambán tapasztalataim szerint a Windows "sara".
Ugyanaz a "gagyi" D-Link DNS-320 10 MB/s-et produkált egy 2,4 GHz-es i7-es notebookkal (7200-as HDD!) Win7-tel, amely 50 MB/s-et egy 2,6 GHz-es Pentium G2030T-s géppel (5400-as green HDD), valamint 80 MB/s-et egy clonezilla CD-t bootolva...

Ezért indultam abba az irányba, hogy dobjuk a Windowsokat és legyen pure linux hálózat, de ugyan ott vagyok, ahol a part szakad...
Remélem kapok valami tippet pl. olyanoktól, akik szervertermekben linuxos gépeket kötnek össze backup, vagy redundancia céljából.
A szerveren egyébként nem zárkózom el *BSD, vagy más (nem Windows és nem fizetős) operációs rendszertől sem. 

openSUSE 13.1 x86_64.

( ncc1701 | 2014. 05. 21., sze – 20:01 )

Távol álljon tőlem, h a kókány sambát védjem, de 50-60MB/sec simán kicsavarható belőle a megfelelő beállításokkal.

Linuxos gépeket lehet sshfs-en kötnék össze, de ez egyéni perverzió. :)

- Szerintem ilyen beállítás nem létezik. Mármint ami ennyi pici állomány esetén is hozza az 1 GbE sebességet, vagy ennek java részét. Nem a Samba hibájából, hanem azért, mert ilyen esetben a teljesítményt nem a hálózat átviteli sebessége csökkenti le.
Azaz de, van. Majdnem. Csak oda sok RAM, erős CPU és sok-sok HDD kell jól szervezve. Meg ehhez választott FS és hálózati kiszolgáló.
- Másodszor írod az 50-60 Mbps-t, ami kb. 5.9-7.2 MB/s, ezt azért a gyári Samba konfig is megugorja, akár sok kicsi állománnyal is.

Csináltam gyorsan egy tesztet az itthoni gépeimen. Sajnos nincs pont 12890 db-os, 4447MB-os file-gyűjteményem, így arányosítanod kell:
kliens->szerver
7184 fájl, 2757 mappában, 4.78 GB: 7p:48mp, ami kb. 10.47 MB/s, nagyjából 90 Mbit/s.
1 fájl, 5.8 GB: 2p:01mp, ami kb. 49 MB/s
szerver->kliens (természetesen memória cache ürítés után, mindkét oldalon)
7184 fájl, 2757 mappában, 4.78 GB: 4p:53mp, ami kb. 16.7 MB/s, ~ 190 Mbit/s
1 fájl, 5.8 GB: 2p:00mp, ami kb. 50 MB/s

Szerver: ML310e Gen8v2, Xeon E3-1220, 4 GB, FreeBSD 10.0-x64, Samba 3.6, forrás/cél: egy szem WD Green 1.5TB HDD (ez a "temp" meghajtó).
Kliens: Gigabyte H77 MB, i3-3220, 8 GB, Win7 HP-x64, forrás/cél: 2x500GB HDD Intel soft RAID1 kötet.
Win<->Win tesztet nem csináltam.

Viszont a legtöbbször nem ilyen jellegű a terhelés az általad vázolt környezetben, hanem sok állomány nyitva tartása, több gépről, egy időben. Ergo konkurens elérés (azonos vagy különböző állományok). A diszk alrendszer itt válik érdekessé, mert az egyidejű párhuzamos műveletek az 1-2 HDD-s rendszert drasztikusan visszavetnek a szóló klienses teljesítményhez képest.

P.s.: Ugyan ilyen szerver, azonos OS, de 2 db SATA HDD FreeBSD-s GEOM tükörben simán hozza nagy állományokra oda-vissza a 110MB/s sebességet (~900 Mbit/s), arányosan jobb a sok kis állományos sebessége is. Persze egy kliensről tesztelve.

- Másodszor írod az 50-60 Mbps-t, ami kb. 5.9-7.2 MB/s, ezt azért a gyári Samba konfig is megugorja, akár sok kicsi állománnyal is.

50-60 MBps, tehát megabyte/sec-et írtam mindenhol, de ha nem, akkor azt szerettem volna.

Win <-> Win másolás gagyi kliensek között simán hozta a 49 MB/s-t. Nem hiszem el, hogy ezt két linuxos gép között képtelenség lenne megcsinálni. (Ez nem Neked szól, csak magamban morgolódom) 

openSUSE 13.1 x86_64.

Ja, bocs. Én Mbps alatt a Mbit/s-t értem, akármelyik betű nagy vagy kicsi :-)

Win-Win között a sok kis állománnyal tényleg működik a tartós 49 MB/s? Ha stopperelt elkészülési időből visszaszámolod, akkor is?

Azt elfelejtettem írni, hogy Linux/BSD esetén (olvasmányaim és tapasztalatom szerint egyaránt) nem segítenek a desktop MB-ken rendszeresített Realtek csippes hálókártyák. Persze a Windows driver-ük jó, ott nincs ekkora hátrány.

Aztán a workload-tól függően a különböző aio_* (aio_linux) [de ez télleg a méréses móka, van ahol rosszabbul teljesít], ha ekkora eltérés van a linux-win kliensek között (gondolom ott is a 10k+ kis fájl másolás volt a teszt), akkor érdemes meglesni a case sensitive beállításokat (case sensitive, preserve keys etc.), ha nem gond, ha a fájlnevek case-t váltanak etc.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Amikor ezt a néhány sort hozzáadtam az smb.conf-hoz, a mérés másodpercre pontosan ugyan olyan sebességet mutatott, mint ezen beállítások nélkül. 

        socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
        min receivefile size = 16384
        use sendfile = true
        aio read size = 16384
        aio write size = 16384
        # aio write behind = true
openSUSE 13.1 x86_64.

Ugyanaz, mint a jelenlegi, de kell hozzá 2db pci-x csatolós ssd, darabja mondjuk 3000$. Erről tudná gyorsan olvasni/írni.

Poént félretéve, mint nyilván sejted, jelen esetben nem a samba a lassú, hanem a sok kis file írása/olvasása önmagában. Lemezekkel ezt nem fogod tudni megoldani.

Szerintem sok (kis) file másolása esetén problémás lehet, hogy minden egyes file-nál lesakkozza a kliens és a szerver a maga vackait.

Nálam ilyen felhasználásnál (kb. 15k file, 1-20 GB) linux-linux között nagy előrelépést jelentett az scp után a tar-ral megbolondított ssh:

innen$ tar -cf - ./ezt_a_konyvtarat | ssh user@célgép "tar -xf - -C /ide/másold/kerlek/"

Mérni nem mértem, de érezhetően gyorsabban végzett.

( vfero v | 2014. 05. 21., sze – 20:49 )

nálam a backup az rsync-nél kezdődik...

( gedez | 2014. 05. 21., sze – 21:46 )

Részletes teszt, de érdekelne, hogy az NFS 3-as vagy 4-es volt.

"Az egyik gép megosztott C: meghajtójáról történt a számlázás, bevételezés, készletnyilvántartás, könyvelés, bankolás és mindenki össze-vissza mentegette az általa készített/módosított dokumentumokat."

Úgy gondolom, hogy ezek alapjaiban kis állományok, és munka közben 1-1 állomány kerül mozgatásra, vagyis teljesítmény tekintetében ez nem fog 10e fájl másolásával felérni. Biztonsági mentés pedig úgy is üresjáratban fog történni, így szerintem inkább kényelmi funkcióknak kellene döntenie.

Ha linux - win, akkor Samba-t, ha linux-linux kapcsolat, akkor NFS-t javaslok.

NFS4-et szerettem volna, de a YAST2-vel történő beállítás végén kiírta, hogy

"Az idmapd elindítása nem sikerült. Ellenőrizze a tartomány beállításait."

A tartománynévnél az alapértelmezett "localdomain"-t hagytam. Nem foglalkoztam a problémával behatóbban, gondoltam tesztelésre jó lesz így is. :)
Ha nem pipálom be az NFS4-et, akkor

"Az idmapd leállítása nem sikerült."

üzenetet kapom. Így még nem teszteltem, de mindjárt kipróbálom, mit lehet így mérni.

Az a gond, hogy a számlázóprogram használatakor az ügyféllistából kiválasztott névre Enterezve előjön egy részletes táblázat, amit Windows on futtatva (mindegy, hogy megosztáson keresztül, vagy natívan) kb. 2-3 mp alatt "kitölt" a program, Linuxról Samba megosztáson keresztül volt, hogy 20 mp-ig is tartott.
Sajnos a még használhatóság és a használhatatlanság a kettő között a különbség.

Egyébként .dbf állományokat használ a számlázó, de "már" Windowsos a program, nem DOS-os :D 

openSUSE 13.1 x86_64.

Az utolsó bekezdések alapján - így 2014-ben - a fejlesztésnek jobb lenne abba az irányba indulni, hogy a 100 db DBF-et használó programot kidobjátok :-)

De tudom, hogy az általános elvárás az, hogy a rosszul megírt és/vagy ósdi szoftvert a hardver cseréjével szeretnék gyorsítani.

a fejlesztésnek jobb lenne abba az irányba indulni, hogy a 100 db DBF-et használó programot kidobjátok :-)

Nem feltetlenul, ujra lehet forditani a programot Harbour-ral, a Linuxos gepbol terminalszervert csinalni, es akkor nem lesz gond a halozat sebessege. Nalunk igy mukodik, 4-500 bejelentkezett juzer mellett 4-5 korul szokott lenni a load average ;-)

Erről még nem hallottam, de belenéztem a linkbe és ígéretesnek tűnik. De nem vagyok benne biztos, hogy annak a sok remek Clipper-es programnak meglenne (vagy hozzáférhető lenne) a forráskódja manapság.

Mielőtt bárki megszólna, én nem a Clipper-t tartom hibásnak, nem a rendszer tehet a benne készült alkalmazások rossz működéséről. Szerintem a maga idejében nagyszerű volt, csak sok programozó nem úgy használta, ahogy kell. Ezért a Clipper-ben készült programok nem önmaguk miatt rosszak, hanem a készítőik miatt.

Nem tudom, mennyire kompatibilis a Clipper es a Foxpro, az ugyviteli programot nem en irom, de azt mondja a fejlesztonk, hogy minimalis valtoztatasokkal le lehetett forditani a DOS-os Clipper forrast.

Amugy a Harbour tud Linuxra, Windowsra es DOS-ra is (kereszt)forditani, szoveges vagy grafikus feluletre, tobbfele adatbazist is tud kezelni. Erdemes lenne megnezzetek, hogy tudjatok-e hasznalni, nekunk nagyon bevalt.

A döntéshozó ragaszkodik a programhoz, hallani sem akar másról.
A programot egy külső cégtől vásárolták, akik nem hiszem, hogy egyik ügyfelük kedvéért bármit lépnének ezügyben.
Létezik normális program is az adott feladatra, de ugye az (megint sok) pénzbe kerülne.
Abból kell főznöm, amim van, a program nem változ(tat)hat(ó). 

openSUSE 13.1 x86_64.

Ha nem pipálom be az NFS4-et a YAST2-ben, akkor a kliens gépen a mountoláskor a következő hibaüzenetet kapom: 

# mount szerverIPcime:/srv/szerver/ /test/nfs/
checkproc: Empty pid file /var/run/rpc.statd.pid for /usr/sbin/rpc.statd                               
Starting rpc.statd ... portmapper not running failed     
mount.nfs: rpc.statd is not running but is required for remote locking.                                
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.                                 
mount.nfs: an incorrect mount option was specified
# mount -o nolock szerverIPcime:/srv/szerver/ /test/nfs/

-al mountolva működik, de a sebesség továbbra is ugyan olyan siralmas. 

openSUSE 13.1 x86_64.

(Mi brutálerős gépen, brutálsok memóriával, brutáljó IO-ra képes diszk-alrendszerrel vagyunk képesek "elviselhető, de ha közelebb állna a win az nfs-hez, a francnak se kéne ez a szar" tempót kihozni - pár finomhangolási lehetőségről le kell mondanunk, de ha duplája volna az átvitel, azon is csak röhögnék.)

( dragi v | 2014. 05. 21., sze – 23:18 )

NFS de xfs filerendszerrel. Sok kis filera jobb az xfs. Én is beleszaladtam ebbe. Backup ment nfs-re ext-el és lassú volt, mert sok kis file mentődött. Előtte hiába teszteltem nagy filékkal azzal jó volt. Újrahúztam xfs-el és nagyságrendekkel gyorsabb lett.

--
http://pyftpadmin.earthquake.hu

Most kezdem az XFS NFS-el tesztelést.
A Wikipédia szerint lehet, hogy nekem nem lesz jó az XFS, de mindenképpen kipróbálom.

Idézet a Wiki-ből:

Hátrányai

Törölt adatok visszaállítása (undelete) csak Microsoft Windows alatt futó kereskedelmi alkalmazásokkal lehetséges:
Disk Doctors XFS Data Recovery
Raise Data Recovery for XFS
[...]
A célnak megfelelő létrehozása hozzáértést igényel az mkfs.xfs számtalan opciója miatt és mert az alapértelmezett opciók nem minden esetben optimálisak.

Ezeknek még utána kell néznem:
1. Az XFS-nek van esetleg "Recycle" funkciója, mint a Sambának?
2. Milyen opciókat kellene használnom a fájlrendszer létrehozásakor? 

openSUSE 13.1 x86_64.

"1. Az XFS-nek van esetleg "Recycle" funkciója, mint a Sambának?"
Nincs mint ahogy ext4-nek sincs és még jópár filerendszernek. Szóval ez nem xfs specifikus :)

"2. Milyen opciókat kellene használnom a fájlrendszer létrehozásakor?"
Defaultal is jó lesz, de neten van xfs tuning howto. Meg a nem minden esetben, az elég tág fogalom :). Nekem nem volt még vele gondom.
--
http://pyftpadmin.earthquake.hu

( WG | 2014. 05. 22., cs – 00:15 )

Holnap nem tudok tesztelni, de az észrevételeket továbbra is várom.
Amint tudom, próbálom az XFS-t és beszámolok a samba with aio_linux és a csodákra (sajnos nem) képes sendfile=yes (sikertelen) tesztekről is.
A case sensitive, preserve keys etc. beállításokat egyelőre nem próbáltam ki. Ha erre kerülne sor, akkor ezeknek csinálni fogok egy külön megosztást, ahová a könyvelés (DOS-os) és a számlázó program megy upper case fájlnevekkel, a többi cucc marad a "normál" megosztáson.

Köszönöm szépen mindenkinek a segítséget! 

openSUSE 13.1 x86_64.

Nálam ez elég jól működik:
smb.conf-ba:


socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_SND BUF=6291456 SO_RCVBUF=6291456
read raw = No
write raw = Yes
use sendfile = Yes
dead time = 15
getwd cache = Yes
oplocks = No

sysctl.conf-ba:

# Samba tuning
net.core.rmem_default = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 8388608
net.core.wmem_max = 8388608
net.core.optmem_max = 40960

#network tuning
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_fack = 0
net.ipv4.tcp_window_scaling = 1
net.core.wmem_max=12582912
net.core.rmem_max=12582912
net.ipv4.tcp_rmem= 10240 87380 12582912
net.ipv4.tcp_wmem= 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 5000

Egyszer próbáltam egy olyan beállítást is, aminél nem várja meg, h lemezre ki legyen írva az adat túloldalt, hanem folyamatosan küldi. Az brutál gyors volt, de végül is nem használom inkább. :)

( nagysa v | 2014. 05. 22., cs – 08:16 )

Linux tmpfs -> Linux NFS megosztás 12890 db fájl másolás (összesen 4447 MB): kb. 2 MB/s (!)
Hmm..
Az exports fileba:
no_wdelay
esetleg
async
Szerintem egy mérést megér.

Mikor én az nfs-nél az async használata mellett döntöttem..
Maga az ext4 (szerintem a többi filerendszer is) async üzemmódban működik. Miért ne használnám a felette lévő réteget (nfs) is ebben az üzemmódban, ha az ext4 működésénél ezt elfogadjuk.
l.
man mount
Mount options for ext3
commit=nrsec Sync all data and metadata every nrsec seconds. The default value is 5 seconds. Zero means default.

Ha esetleg csinálnál egy mérést sync módban ext4-el meglátnánk, hogy
milyen (várhatóan siralmas) eredmény jönne ki.

Tudom ezek a gondolatok messzire vezetnek és talán egy külön fórumtémát is megérdemelnének.

( WG | 2014. 05. 24., szo – 17:20 )

Most sikerült leméretnem, hogy ugyan ez a 12890 fájl mennyi idő alatt megy át két XP-s gép között HDD-ről HDD-re.
Majdnem 30 MB/s jött ki.
Így akár Samba, vagy SSHFS is lehet a Linuxok közt, mindkettő többet fog tudni, mint a mostani felállás.
Már csak az érdekelne, hogy vajon miért töredéke a Linux -> Win sebessége a Samba-nak, mint Linux -> Linux között? :)

A pontosság kedvéért azt is fontos megjegyeznem, hogy a Win -> Win másolás nem abban a tesztkörnyezetben történt, amelyben az összes többi teszt.

Az XFS tesztekkel még adós vagyok, de ami késik, lehet, hogy nem is jön el. :) 

openSUSE 13.1 x86_64.

( WG | 2014. 05. 24., szo – 22:15 )

XFS és EXT4 között sajnos maximum műszerekkel kimutatható különbség volt ebben a tesztkörnyezetben.
Gyakorlatilag megegyezett az NFS és az SSHFS sebessége. 

openSUSE 13.1 x86_64.

( Bodri v | 2014. 05. 25., v – 15:19 )

Nekem régen, XP-s környezetben a protocol-al volt gond. Át kellett rakni cifs-re.

Megnéztem, most a min protocol = NT1 -el lehet ezt állítani.

( palmaci | 2014. 05. 25., v – 14:06 )

XP-vel és Samba3 soha nem fogod kihasználni a gigabit adta sebességet.

A Micorosoft a vista-ban jelette meg a SMB2 protocolt ami kezeli a gigabites hálót. A régi SMB1 protocol nem tudja kihasználi csak kicsit lesz csak gyorosabb mint 100-ason. Át kell állni win7-re és samba4-re, bárhogy probálod is hegeszteni nem lesz jobb a SMB protol nem tudja.

Amúgy nekem samba3.6 (smb2 support) (HP proliant ML110 G3) és win7prof totalcommander szerint 100-as hálón switch csere előtt 5,5Mbyte/sec csere után 65Mbyte/sec. ~520Mbps

amúgy nem lehet hogy a realtek halókártya a ludas? mert én már szivtam egyszer igaz 100-as hálón.(baromi lassú volt) bele raktunk egy 3com kártyát és hirtelen minden jó lett. meg mondjuk azóta igyekszünk olyan alaplapot beszerezni amin broadcom, intel vagy marvell chip van. Valahol mintha azt olvastam volna, hogy 1-2 dologot a driver old meg a realtek NIC-eknél ami elégsok CPU időt von el.