HDD stíha , sieť nie... Čo s tým? (diskuse)

[David Watzke]

Alebo ako to riešiť efektívnejšie (rady ako pridanie servera, prechod na 1Gbps sú vopred odsúdené (z finančného hľadiska) na zánik)?

Chtěl jsem napsat 1 Gbps, ale v takovým případě teda napíšu pomalejší HDD

[Michal Fecko]

Alebo ako to riešiť efektívnejšie (rady ako pridanie servera, prechod na 1Gbps sú vopred odsúdené (z finančného hľadiska) na zánik)?

Chtěl jsem napsat 1 Gbps, ale v takovým případě teda napíšu pomalejší HDD

njn, ale s RAIDom by som uz radsej nehybal, aspon ze stiha - inac by som musel ist do RAID5...

[cthulhu]

pridej dalsi 100mbit sitovku a nakonfiguruj bonding (load balancing), vic asi (za malo penez) neudelas

[frEon]

dobrej navod na bonding

[Kvakor]

Dve sitovky a load baLalancing je asi opravdu nejlepsi reseni, i kdyz je otazka, jak to efektivne implementovat - sitovani ve Windows docela komplikovane, protoze kromne TCP/IP a DNS je tu jeste NetBIOS a windowsacke obdoby DNS (NBNS,WINS), coz celou situaci dost zeslozituje.

Vetsina reseni, o kterych vim (treba LVS), potrebuje neco, co prvne rozdeluje provoz mezi vice stroju. Jak to same udelat na jedinem stroji s dvema sitovkami mne ale nenapada ...

Je tu samozdrejme jeste moznost delat to delat staticky - server by se tvaril jako dva samostatne stoje a kazdy klient by si vybral jeden z nich, bud natvrdo, nebo pres DHCP (pokud si to dobre pamatuju, jde pres nej posilat i adresu WINS serveru).

[Zdeněk Burda]

dobré povídání o bondingu je u zdrojáků jádra, konkrétně je to soubor Documentation/networking/bonding.txt O DNS, NetBIOS a podobných věcech se tam opravdu nic nepíše

[Grunt]

A nebude mít náhodou jedna IP adresa dvě MAC adresy v případě, že se jedno spojení bude odesílat i přes druhé rozhraní?

[VSi]

Pro využití bondingu, tj. 2×NIC a 2 kabely do jednoho switche, bude zcela jistě nutné, aby to ten switch podporoval. Pokud tedy máme na mysli situaci, kdy server bude mít 1 IP adresu a tedy i 1 MAC adresu a provoz se bude rozkládat přes X rozhraní.

Někdy to bývá nazýváno Port trunkig nebo Port Aggregation, pozor na to, aby to bylo kompatibilní s Linux bondingem.

V dané situaci je možné použít 3 × 100Mbps kartu na ty 3 switche, v Linuxu se dají spojit do bridge a zůstane tak zachován 1 subnet, nebo udělat klasicky 3 × /24 subnet. Další možností je Gb karta a switch s alespoň jedním Gb portem, lépe s více Gb porty do budoucna. Třeba HP ProCurve 1700-8 - za cca 1800,- s DPH má 1 Gb port + 7 100Mb portů, umí VLANy a třeba i zobrazit MAC adresy na portech. Pokud by v budoucnu na jednom z těch stávajících 3 switchů nestačilo 100 Mb, lze jednoduše využít 2 porty toho HP ve dvou VLAN - zapojit je oba do toho 24 port switche a ty počítače mezi ně rozdělit do 2 subnetů. Pokud tedy nechcete měnit ty 24 portové switche.

[phero]

Howto linkovane v jednom z predchozich komentaru ukazuje moznost nastavit bonding na balance-alb coz by melo fungovat i bez podpory druhe strany - kazdopadne je ale mnohem lepsi pokud se pouzije standardni link aggregation

[Grunt]

Howto linkovane v jednom z predchozich komentaru ukazuje moznost nastavit bonding na balance-alb coz by melo fungovat i bez podpory druhe strany

No jo, je to tak…díky za tip.

[Heron]

40 stanic součastně vůbec není málo. To mi neříkejte, že se na 60 stanicové síti nenajde pár tisíc na gigovou síťovku a pořádný switch. Dále to nemusí stíhat ty disky. Zkuste se podívat na iowait během té záteže (tipuji, že disk značně seekuje a proto data moc netečou).

[Michal Fecko]

40 stanic součastně vůbec není málo. To mi neříkejte, že se na 60 stanicové síti nenajde pár tisíc na gigovou síťovku a pořádný switch.

Nieje to súkromný sektor...

Dále to nemusí stíhat ty disky. Zkuste se podívat na iowait během té záteže (tipuji, že disk značně seekuje a proto data moc netečou).

Pristupuje sa na 60 - 80 percent len k veľkym (viac ako 250M) súborom čo by malo byť z hľadiska seekovania prijateľnejšie ako k 100kám malých... Na to iowait pozriem...

[Heron]

Pristupuje sa na 60 - 80 percent len k veľkym (viac ako 250M) súborom čo by malo byť z hľadiska seekovania prijateľnejšie ako k 100kám malých... Na to iowait pozriem...

No dobře, ale přistupuje k tomu 40 procesů a pokud to není jeden soubor (tedy už je dávno v cache), tak to seekovat bude.

[Sandokan]

Pokud tam jsou 3 switche a ten server je v dosahu, tak do něj přidám 2 100Mb karty a budu mít 3 segmenty např. 192.168.100.0, 192.168.101.0 a 192.168.102.0, pro každý switch jeden.

Zátěž bude rozdělená a bude to za 2 karty a 2 patch kabely.

ZDAR!

[Josef Kufner]

Také bych to řešil takto, pokud by nebylo možné vyměnit switch za model s alespoň jedním 1Gbps portem pro server -- klientum bude stačit stávající 100Mbps.

Další možnost, asi jednodušší na konfiguraci serveru, je dokoupit jeden 1Gbps switch s alespoň 4 porty a propojit jím ty tři stávající switche a server. Zcela jistě to nerozbije windowsacké pseudo-síťování a efekt bude prakticky stejný.

[Vskutečnosti Saýc]

Server pripojeny 100mbitem. Dobry boze. To je zoufale poddimenzovane na jakekoli souborove sluzby.

To co rika kolega nademnou dava smysl. Jen by ten prepinac mohl mit vic slotu a server vic gigovych sitovek. Jednoduchou matematikou se dostaneme k tomu, ze kdyz pracuje ctyricet stanic, bude sirka pasma pro jednu z nich
- u serveru pripojeneho 100mbitem dva a pul megabitu (uf)
- u serveru pripojeneho jednim gigabitem dvacet pet megabitu (tj. ctvrtina vykonu jedna 100mbit sitovky)
- u serveru pripojeneho dvema gigabity padesat megabitu (polovina)
No, a kdyz si vezmeme jak je 100mbit pomaly na prenos souboru, a tady se dostaneme na polovinu ... ale na druhou stranu, investice do jednoho prepinace za takovych pet tisic (musi byt chytry aby umel spojovat porty), a mozna jedna dve gbit sitovky do serveru, pokud to neni serverovy hw (ty je obvykle maji) znamena dvacetinasobne zrychleni.

Kazdopadne, at uz se vydate jakoukoli cestou ktera zvedne vykon site nad uroven vykonu disku (100mbit je ma asi ctvrtinovou rychlost v porovnani se soucasnym diskem), rozhodne se vyplati investice do RAM v serveru. Radim tohle vsude mozne -- linuxova souborova cache je dost efektivni, a pameti jsou v dnesni dobe levne, a o mnoho radu rychlejsi nez disky! Kdyz se podivam na ty stovky megabitu ktere tecou z nasich souborovych serveru ... neco takoveho by disku nemohly stihat, a proto je pamet dulezita. Osm gigabajtu pameti zni zbytecne, ale vyplati se to, pokud je dat hodne, ale jeste vic pokud je jich malo (pokud jich tedy neni pul giga, jasne).

[Grunt]

HDD stíha , sieť nie...

A to vím nebo si to myslím?

[Michal Fecko]

Viem aj si myslim - som pevne presvedceny ze disky by stihali viac klientov (ak nie tak budem nuteny prejst na RAID5 ?), ale siet je uz na svojom strope...

hdparm -Tt /dev/md1
/dev/md1:
 Timing cached reads:   1620 MB in  2.01 seconds = 805.97 MB/sec
 Timing buffered disk reads:  297 MB in  3.04 seconds =  97.69 MB/sec

[Grunt]

To o ničem moc nevypovídá:

for ((a=0; a <= 40; a++)) do (dd if=/dev/sdX of=/dev/null bs=10M count=12 skip=$RANDOM &); done

Ještě bych to třeba zkombinoval se zápisem a člověk se hned dostane k rozumným hodnotám. Např. u mě to činilo 546kB - 1,4MB. Co mě však zarazilo, bylo absolutní vytuhnutí systému. Když to ještě zkombinujeme se síťovkou, tak se určitě dostaneme na 100% zaplácání fronty přerušeními. Zkusil bych se mrknou, jestli třeba síťovka nesdílí přerušení s jiným zařízením, z toho by se dal vytřískat nějaký čas navíc. Dál bych se mrknul jestli je jádro zakompilováno s CFQ, CFS a něčím takovým i ve frontách pro síť, protože někdo může třeba vyžrat 70% kapacity a na někoho se nemusí dostat vůbec. A napadá mě ještě víc věcí, ale ze všeho nejdřív bych lokalizoval úzké hrdlo, abych nemusel takto věštit z koule.

[David Watzke]

Tobě po spuštění tohodle vytuhnul systém? U mě ty rychlosti byly 1,5 až 1,9 MB/s a nevytuhlo nic, napsal jsem během toho půlku tohodle komentáře. A to byl disk na kterym mám /.

[Grunt]

Ještě si zapomněl napsat jakou máš grafiku. Ale jinak jo…i kurzor se trhal. Párkrát se podařilo probliknout i topu a %sy na 100%(obsluha přerušení?) a %si na 20%(Čtení z disku je záležitost SW přerušení?). Přece jen je to jedno jádrový celer.

[David Watzke]

Jak s tím souvisí grafika?

[Grunt]

Úplně stejně jako, že u tebe byly rychlosti 1,5 až 1,9 MB/s, nevytuhlo nic, že jsi napsal během toho půlku tohodle komentáře a že to byl disk na kterém máš /.

[Heron]

Přesně na toto jsem upozorňoval.

BTW: RAID5, tři disky, dohromady čtení cca 35MB/s, na jedem proces je to tedy míň jak 1MB/s, load 40 (jak jinak, všechno v iowait), systém celkem běžně použitelný (pokud se něco chce z jiného disku).

[AraxoN]

Fujtajbl! Ten príkaz mi celkom pokazil štatistiky loadavg... a teploty HDD... a využitia pamäte!

[Grunt]

A co teprve tento:

dd if=/dev/urandom of=`mount | sed "s/\([^\ ]*\)\ [^\ ]*\ \([^\ ]*\).*/\1\ \2/" | sort -k2 | head -n1 | cut -d " " -f 1 | sed "s/\(.*\).$/\1/"` bs=1024k

Ten toho dovede pokazit…nejen statistiky.

[AraxoN]

Ale, ale... K takýmto zverstvám by si mal písať výraznejšie varovanie - niekto by to naozaj mohol spustiť!

[frEon]

tenhle je lepsi: :(){ :|:& };:

[Michal Kubeček]

Na současných distribucích nezřídka ani moc ne. Pokud tedy oběť nebude natolik tupá, aby si to spustila pod rootem - ale v takovém případě si výsledek plně zaslouží.

[petr_p]

A zemře to dřív kvůli vyplácaným deskriptorům, nebo počtu procesů? :D

[Michal Kubeček]

Záleží na obsahu limits.conf :-)

[Marián André]

... (ak nie tak budem nuteny prejst na RAID5 ?) ...

Jedine v prípade, že klienti väčšinou dáta čítajú a teda zápis je minimálny (alebo žiadny)...

[Michal Fecko]

No je fakt, ze ide najma o citanie (vyucbove videa, vyucbove programy...) ale to citanie je zatial fajn - dnes pri 15tich kompoch mi iotop ukazovalo ~5 - 7M total read ( rozne xvid videa).

[3of5]

Jestli tam jsou 3 switche tak bych dal do serveru 3 sitovky a kazdej na jednu ty potom do bridge, celkem nic se nezmeni a melo by to byt ok

[YYY]

Ne kazdy musi byt doma hybridni sit

[3of5]

Hlavne ze ti nevadi ze to funguje dobre.