Gigabites hálózat bővítés olcsón

Hálózatok általános

Hali!

Van egy irodai hálózatunk jelenleg cat5e kábelekkel szerelve, egy 24 portos gigabites switchel és egy raid 10-es (linux) kiszolgálóval, amiben jelenleg 1db gigabites hálókártya van. Mivel ez egy elég kezdetleges switch, így mini gibc csatlakozók nincsenek rajt. A hálózaton gyakran másolnak a szerverre nagyobb állományokat, illetve dolgoznak közvetlen a samba megosztásra több gépről.
Bár a sebesség most sem rossz, a gigabites hálózat ki van használva teljesen, így párhuzamos munkával a szerverre sajnos csak 200-300mbit jut egy felhasználónak (megfigyelések alapján) általában. (Amikor kiürül az iroda a kliensek elérik egyesével az 1gbit-es írási sebességet a samban megosztott mappák felé)
A lehető legolcsóbb megoldás érdekelne arra, hogy növelni tudjuk az egyes gépekre jutó sávszélességet valahogy, főleg a samba megosztások részére. (a switch cseréjét, illetve drágább hálókártya beszerzését értelemszerűen nem preferáljuk :)

Ha esetleg még szükséges valami infó, azt írjátok meg.
(a kliensek 64bites win7-es munkaállomások)

  • 2541 megtekintés

( STP | 2010. 10. 30., szo – 11:22 )

1) "így párhuzamos munkával a szerverre sajnos csak 200-300mbit jut egy felhasználónak"
2) "Amikor kiürül az iroda a kliensek elérik egyesével az 1gbit-es írási sebességet"
Na, akkor mi is a szűk keresztmetszet?

( Mico v | 2010. 10. 30., szo – 11:48 )

nem tudom, hány gép van, de ha sokan egyszerre akarnak nagy fájlokat másolni, akkor nagyon gyorsan a diszkjeid lesznek a szűk keresztmetszet.

Ez jó megoldásnak tűnik. Switch csere nélküli megoldás esetleg?

felmerült ötlet:
Még1-2 hálókártya különböző ip címekkel a szerverbe, majd a klienseknek ugyanazt a megosztást más-más ip címen adjuk meg, így egy hálókártyára esetleg kevesebb kliens jut. (esetleg egy program majd a kliens oldalon megnézi, hogy melyik hálókártyán eddig mennyi kliens van és az alapján csatolja fel a megosztásokat, néha pedig ellenőrzi, hogy valamelyik hálókártyán lett e szabad hely, és újracsatolja a megosztást)
Persze nem biztos, hogy ez így kivitelezhető...

(a raid10-nek még van tartaléka bőven 1gbit fölött)

Vagy switch csere nélkül "balance-xor" bonding-ot csinálsz a szerveren több hálókártyából, így a kliensekkel nem kell variálni, a szerver osztja el, hogy melyik klienssel melyik hálókártyán keresztül kommunikál (eth szinten).
(nem a legelegánsabb megoldás, de ha nem akarsz/nincs keret switch-et cserélni)

Bár, nem olvastam konkrétan utána, de eddigi tudásom alapján úgy értelmezem a protokoll működését, hogy már az első broadcast-nál a szerver adott kliens felé adott hálókártyán keresztül (de ugyanazon IP-n) mutatja magát, innentől kezdve a kliens hálókártyája ahhoz a MAC addresshez fogja címezni az ethernet csonagokat. Azaz minden kliens is azon a hálókártyán fog kommunikálni a szerverrel, amelyiket a szerver kiválasztotta számára, mindezt úgy, hogy a szervernek 1 IP címe van.

( psc | 2010. 10. 30., szo – 12:44 )

Annyit tudnál nekem/nekünk segíteni, hogy hogy sikerült a sambával elérni, hogy kitolja a gigabitet?
Sokan szenvedünk evvel, egy pár tipp, esetleg egy smb.conf ól jönne...
köszi!

Szerver oldalon semmi "különleges" megoldást nem alkalmaztunk, sata2-es vinyok vannak raid10-ben egy HP szerverben (az oprendszer külön lemezről fut). A kliens oldalon a gépek nagy része 64bit-es Win 7 (intel iX processzorral). Azt mi is észrevettük, hogy a régebbi gépek, amiken win xp fut (intel core 2 duo procival), azok a gigabites hálókártya ellenére nem nagyon mennek 100mbit fölé a másoláskor, illetve 1 gépre véletlenül 32bites win7 került, az pedig 800~ mbit fölé nem nagyon akar menni (lehet nincs összefüggés az oprendszerekkel, és pont ezekben van lassabb vinyó mondjuk).
A samba config teljesen alap, semmi extrát nem követtünk el:

[global]
netbios name = venus
server string = venus
workgroup = SOLAR

interfaces = 127.0.0.1 10.0.0.0/255.255.0.0
bind interfaces only = yes

wins support = yes
#wins server = 10.0.0.254
name resolve order = wins lmhosts hosts bcast
local master = yes
os level = 0
preferred master = yes

log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0

guest ok = no
guest only = no
browsable = yes

dns proxy = no
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
create mask = 0644
directory mask = 0755

[Felhasznalok]
path = /mnt/raid10-6t/work/users/
writeable = yes
read only = no
valid users = +csoportnév
force user = ...

.
.
.

igazából annyira át se néztük még a samba configot...

( answ | 2010. 10. 30., szo – 14:57 )

Használj DNS szervert, ahol round robin load balancing segítségével add vissza a szerverbe helyezett kártyák IP címeit!

( arpi_esp v | 2010. 10. 30., szo – 15:56 )

a szerverbe tobb halokartyat (vagy tobb portosat, lehet kapni dual es quad gigabitest is), lehetoleg intelt.

linux bonding driver tud soho switches okossagokat is (pl. terheleselosztas mac cim alapjan, rtfm) vagy kell egy LACP-kepes switch.

A'rpi

+1
Nálunk iSCSI szerverhez és számos klienshez a legjobban a balance-alb mód vált be, amihez éppenhogy nem kell switch oldali támogatás. Pedig végigpróbáltuk az összeset. A tapasztalat az, hogy az LACP, 802.3ad a legtöbb menedzselhető switch-ben csak receive oldalon van megvalósítva, tehát tudja fogadni a switch a 2 (4, 8) linken érkező forgalmat egy hosttól, de visszafele csak 1 linken fogja továbbítani a beérkező csomagokat. Ha jól emlékszem 4 különböző típusú switch-csel próbáltuk, mind így viselkedett, utánaolvasva elég ritkaságszámba megy az olyan, amelyik rendesen szétosztja a forgalmat a linkek között. Úgyhogy csak ezért a funkcióért nem érdemes menedzselhető switch-et venni. (Ettől függetlenül persze jó kifogás lehet egy menedzselhető switch beszerzésére :) ).

Tipikusan nem működik: egy kliens és egy szerver között 1 link sebességét meghaladó áteresztőképesség
Tipikusan működik: sok kliens és egy szerver között összesen 1 link sebességét meghaladó áteresztőképesség, keriati neked pedig pont ez kell.
---
Internet Memetikai Tanszék

Köszi, azt hiszem elsőre ezt a balance-alb-ot fogjuk megpróbálni hétfőn, tökéletes lenne ide, ha működik.

Ez mondjuk meglep, hogy a switchekben nincs oda vissza megoldva a load balance, és mi mondjuk nem egy csúcskategóriásat vennénk, szóval bele is futnánk ebbe a problémába, köszi a tippet.

hat ez engem is meglep... nalunk vannak hp procurve switchek (54xx es 2810-ek) kozott 2-4 portos lacp linkek es nem tunt fel hogy nem oszlana el a forgalom kozottuk.

most megneztem es ha nem is azonosan, de eloszlik a 4 link kozt a csomagok szama, a legnagyobb elteres is kb 40% csak.

A'rpi

Na összeraktam a rendszert balance-alb módban, és az eredmény elég jónak tűnik:

http://kepfeltoltes.hu/view/101106/bond6_www.kepfeltoltes.hu_.jpg

(két gép samban keresztül tölti le ugyanazt a 8 gigás kép fájlt)

Köszönöm a segítséget, drága switch helyett pár parancs :)

( dionusos | 2010. 10. 30., szo – 19:35 )

Tiszteletem!

Lehet, hogy hülyeség, DE:
Ha a szerverben van több hálókártya, mindegyik csatlakozik ugyan ahhoz a switch-hez, a klienseken meg te magad állítod be az IP-ket.
Pl: Szerver Kliens
10.0.0.1/24 10.0.0.10
10.0.0.11
10.0.0.12
10.0.1.1/24 10.0.1.10
10.0.1.11

Így minden gép csak a hozzá tartozó alhálózaton kommunikál -> csak a neki osztott szerveroldali hálókártyát használja.

ui: Ha ez nagy hülyeség, kérlek írjátok meg.
dionusos