Dotaz: Rychlý fileserver pro databázi

[gloom]

Dobrý den,

prosím o radu, jak přejít z Windows na Linux. Provozuji server, na kterém jsou dvě sdílené složky. V jedné statická data cca 200GB (katalogy, ceníky atd.) a v druhé je účetní databáze. K databázi se přistupuje z 10 stanic s Windows XP a jde o jediný MS ACCESS soubor o velikosti cca 500MB a pak několik malých přidružených souborů. Donedávna jsem měl na tomto serveru nainstalovány Windows 2000 Server, ale v souvislosti s legalizací jsem zkusil přechod na Windows XP, jelikož jde jen o sdílené soubory, systém práv by byl spíš na obtíž. Práce s databází se velmi zpomalila ( i při kopírování server dává jen cca 2-8MB/s)a to soubor prakticky není fragmentován a síť je gigabitová. Nechci kupovat Windows 2003 Server, přecházet na SQL verzi účetnictví ani nic podobného a raději bych zkusil vhodnou distribuci Linuxu. Specializovanou firmu mohu požádat, ale raději bych se to naučil sám a poznal, jaká síla se v Linuxu skrývá.

Proto vás prosím o radu. Požadavky jsou následující:

 maximální možná rychlost práce s databázovým souborem (i např. použití více síťových karet pro bonding)

 všichni stejná práva (neomezená) v přístupu

 zálohování provádím ručně, ale pokud by se nezpomalila odezva, použil bych pro jistotu i RAID

Server by běžel na stávajícím železe: Dell Precision Workstation 650, 2 x Intel XEON 2,2GHz, 2GB RAM/400MHz, HDD pro databázi 36GB/15000rpm SCSI U320, řadič LSI SCSI 1020/1030, HDD pro statická data 250GB/IDE UATA100, síťovka je jediná gigabit D-Link DGE-550T 64bit PCI, ale můžu jich použít i víc. Celá síť je gigabitová, workstationy mají síťovky D-Link DGE-530, switche jsou zatím Ovislink 8x1Gb, ale chci je nahradit něčím silnějším (čím?)

Poraďte prosím, jaká je pro tuto aplikaci

 nejvhodější distribuce

 jaké použít typy partition

 jaké použít nejnutnější instalační balíčky (server nebude dělat nic jiného)

Myslím, že podobný problém řeší spousta jiných lidí, ale ve fóru jsem konkrétní odpovědi nenašel.

Odpovědi

[Non_E]

Nejsem správce serveru, ale snad alespoň něco užitečného napíšu a minimálně posunu dotaz nahoru v seznamu živých diskuzí v poradně. Snad mě někdo doplní a případně opraví.

Distribuci zkuste nějakou binární, obecně na servery doporučovaný je třeba debian nebo centOS, neznám je však osobně.

Píšete, že soubory sdílíte windowsovským stanicím - předpokládám, že přes smb (klasické sdílení windows). K tomu potřebujete sambu, implementaci protokolu v Linuxu. Nějak server musíte ovládat, k čemuž se používá ssh. Nepotřebujete naopak jakoukoliv grafickou nástavbu (X server, kde || gnome etc.). To jsou asi zásadní programy, s nimiž si správce balíčků stáhne i závislosti. Instalace i konfigurace je myslím dostatečně popsána v návodech na internetu (google: debian ssh/cokoliv howto) případně v dokumentaci distribucí.

K výkonu se těžko budu vyjadřovat. Jenom nápad s bondingem mi pro 10 stanic (navíc přes stejné switche) přijde zbytečný. Pro velké soubory, jako je vaše 500MB access db se obecně doporučuje filesystem xfs.

Btw. RAID není pro zálohování, pokud vám někdo/něco oddělá data na disku, promítne se změna i v redundantních částech pole. Raid chrání jen proti náhlému výpadku disku (nepomůže ani, pokud disk začne odcházet postupně a zapisovat nesmysly - nebo blbě číst a zapisovat nesmysly od klientů). Na to použijte nějakou periodickou zálohu (v cronu) a vzhledem k povaze dat by mělo stačit prosté kopírování na jiný disk (a označení souboru/adresáře datem).

[gloom]

Díky za reakci,

nejsem zas takový amatér, jak to podle dotazu nejspíš vypadalo, ale 15 let dělám sítě a jejich správu pro několik firem, kde se však výhradně používají výhradně Windows. S Linuxem jsem si hrál jen tím, že jsem na pár mašin nainstaloval Mandriva Linux 2008, ale na tom jsem se moc nenaučil, protože si to všechno nainstalovalo samo... ale zpět k fileserveru.

Včera jsem udělal první pokusy. Jelikož nejsem linuxář a složitější konfigurace by mě nejspíš odradila, musel jsem použít něco jiného. V jedné z místních diskusí jsem si našel odkaz na FreeNAS. Jak jsem se dočetl, není to Linux, ale FreeBSD, což je ale v tuto chvíli v podstatě jedno.

Použil jsem jenom stařičký pokusný disk (850MB), abych si nerozdrbal původní už vcelku vyladěné Windows. První, co mě fascinovalo, byla rychlost instalace a podpora ovladačů. Všechno si po prvotní detekci našel sám. A to ten počítač nemá úplně standartní konfiguraci. Instalace trvala jen asi 3 minuty i se čtením menu a konfigurací LAN ;)

Přes webové rozhraní z klientské stanice jsem nastavil mount point a shares, zapl Sambu a ejhle, ono to jelo. Tak jednoduchý rozběh jsem nečekal.

Testy jsem provedl tyto:

Rychlost zápisu 500MB souboru na server:

Pod FreeNAS: Zprvu 20MB/s, pak to postupně slezlo na 1,8MB/s, myslím že to ale bylo rychlostí toho malého disku.

Pod Windows XP: stejně jako na FreeNAS, jen zprvu to zapisovalo jen 8MB/s, pak 1,8MB/s

Pod Windows 2000 server: téměř stabilně to jelo 5-8MB/s

Rychlost čtení 500MB souboru ze serveru:

Pod FreeNAS: zprvu 40MB/s, pak to slezlo na 5-8MB/s

Pod Windows XP: stabilně 5MB/s

Pod Windows 2000 server: téměř stabilně to jelo 5-8MB/s

Z tohoto výsledku jsem byl docela roztrpčen a tak jsem hledal dál, hlavně proto, že stará Windows 2000 server dávala nejlepší výsledky. Další hodinou testů jsem zjistil, že úzké hrdlo není v oper. systému, ale ve switchi. On ten gigový switch v sobě nemá nejspíš dostatečný buffer, takže to dokonce i občas vyhodilo hlášku "Zápis se spožděním se nezdařil". Novější operační systémy využívaly rychlost síťovky naplno a tak zahlcovaly switch, kdežto stará windows 2000 nerozjela síťovku naplno a tak k zahlcování nedocházelo. Když jsem připojil počítače napřímo přes křížený kabel, začaly se dít divy.

Zápis a čtení na disk při přímém propojení:

Pod FreeNAS: čtení stabilně 40MB/s, zápis nejprve 40MB/s, pak slezl na 20MB/s

Pod WinXP: čtení i zápis stabilně 20MB/s

Pod Win2000 server: čtení i zápis stabilně 5-8MB/s

Takže závěr je ten, že FreeNAS je v dané situaci asi 2x rychlejší, než WinXP a rozhodně líp bufferuje. Teď by mě zajímalo, jak výkon vytunit na maximum. Chci použít dvě síťovky a koupit switch, který podporuje rozložení datového toku na více LAN v jednom PC.

[Creckx]

A jak to celé funguje? Nějaká aplikace přistupuje k tomu souboru na síti nebo si tu databázi nejprve každý user stáhne k sobě a až pak sní pracuje? Mě totiž nejde do hlavy k čemu potřebuješ 20MB/sec na databázi...

[DjAARA]

Možná to bude tím, že jde o MS Access a ne o databázi. Každý ví jak Access (případné FoxPro) pracuje s daty ne?

[Non_E]

Z dotazu je zřejmé, že ne.

[Creckx]

Fakt nevím :)

[gloom]

Psal jsem to v prvotním dotazu. Databázový soubor je nasdílený MsAccess MDB soubor, do kterého se přistupuje z 10 klientských stanic současně. Nejde o klient-server aplikaci, i když v tomhle provedení už to dosahuje hranice únosnosti a sql architektura by byla mnohem vhodnější. Jenomže to účetnictví (Pohoda) v SQL verzi stojí strašnej balík, následný servis ještě nehorázně víc a teď na to prostě nejsou finance. Navíc s migrací na SQL by byly spojeny výpadky v provozu a to teď nepřichází v úvahu. Přitom už jenom tím, že jsem pomocí FreeNAS zvedl propustnost na dvojnásobek, se práce s daty o dost zrychlila a myslím, že tím, že vyladím síť na maximum výkonu, posunu užitnost o dva tři roky dopředu. Je třeba si uvědomit, že Access musí na každé stanici načíst databázi přes síť a pak zase velký objem dat poslat zpět. Nejde o žádnou zanedbatelnou databázičku. Přece jen má 500MB a jsou v ní provázané tabulky, které čítají desítky tisíc záznamů.

[Creckx]

A to ta Pohoda sosá ten soubor celej nebo jak snim pracuje?

[KS]

No tak to je síla, tahat půl giga sem a tam. Nešlo by nasdílet ten soubor, aby klient přistupoval jenom k částem toho souboru, který potřebuje? Případně sdílet více kopií toho souboru, kdyby nemohlo víc klientů současně pracovat s jedním souborem a synchronizovat pomocí incronu nebo normálního cronu?

[Kyosuke]

Já myslím, že JET Engine k tomu prostě přistupuje po stránkách. Ale to je celkem jedno, Microsoft nemůže za to, že někdo v roce 2008 používá jednoduchý databázový engine k něčemu, k čemu nebyl nikdy určen a ještě navíc byl už v roce 2000 byl Microsoftem označený za zastaralý a nahrazený malou desktopovou verzí MS SQL Serveru.

[pavlix]

+1

A za to ho stihne zasloužený trest.

[Kyosuke]

Tyjo, a byl by tak velkej problém zprovoznit TS? BTW, 500 MB databáze je pididatabáze. To jen Access...je prostě Access, no. Zkuste příště něco s Firebirdem.

[gloom]

Víš, firmu, která už x let dělá v tomhle typu účetnictví a jsou s ním spokojeni, těžko přesvědčíš na něco jiného. Ale teď, když jsem to ošetřil jiným operačním systémem na serveru, tak to šlape velmi svižně, ani není poznat, že se pracuje s databází nasdílenou přes síť.

[Dalibor Smolík]

Já používám na serveru RAID1 (2x500 GB disky) s kombinací externího USB disku, na který periodicky ukládám data běžným kopírováním tak, že mám oddělené adresáře pro každý den v týdnu, což by mělo v mém případě stačit. Jako filesystém používám ext3, ale databáze (MySQL) není rozsáhlá, spíš bych doporučil xfs. Systém Debian stable, ale je možné použít v podstatě jakoukoliv distribuci. Práva v přístupu se dají upravit (chceme-li povolit vše, použijeme chmod a+rwx -R /adresar (včetně podadresářů). Jen bych chtěl upozornit, že MySQL ukládá data standardně do adresáře /var/lib/mysql, nesmí se zapomenout na jejich zálohování.

[gloom]

Zálohování mám vyřešené dobře, s tím problém nemám. Hlavní, co bylo potřeba vyřešit, je rychlost práce s daty. Na ten RAID jsem upozornil jen z toho důvodu, že když jsem na jiném serveu zavedl namísto původního jednoho disku RAID5 se třemi disky, tak se práce se soubory citelně zpomalila. Data jsou sice bezpečnější proti náhlému zdechnutí jednoho z disků, ale práce s nimi je moc pomalá. Byl tam použit HW RAID Areca pro max. 4 SATA disky. Nevím, jestli je softwarový RAID rychlejší než hardwarový, protože jsem někde četl, že u výkonnějších mašin tomu tak je, ale na tuhle aplikaci to prostě nemůžu jen tak slepě zkoušet. Musel bych přinejmenším koupit další SCSI disk na 15000rpm a ona to není zrovna levná záležitost... a pokud by to nepřineslo žádný efekt, tak bych měl trochu problém s vyhozenýma penězma.

[DjAARA]

A ten RAID5 má výkonnostní potíže při čtení nebo při zápisu. Při zápisu bych to chápal, při čtení už moc ne.

[Honzas]

Pokud mohu vyjádřit svůj názor, tak tedy takhle. Pro data použít Raid 1 nebo Raid 1 0. Raid 5 při zápisu vypočítává retudantní data, některé řadiče pro kontrolu i při čtení. Disky zapojujte na samostatné kanály. Pro data a systém použijte oddělené disky, někdo tvrdí, že stačí oddělené diskové oddíly, ale já mám zkušenost,že tohle rozdělení (oddíly) není tak přínosné. Jde o to, že datová část není fragmentována. Výrazně se sníží čas pro vystavení disku. Pro SQL je vhodný 3 svazek, pro log soubor.

Raid přináší vyšší bezpečnost dat (vyjma raid 0), pokud tedy máte vyřešeny zálohy, klidně můžete používat jen jeden disk. Dalším krokem je použití řadiče s vlastní paměstí, ideálně zálohovanou baterií.

Z praktického hlediska: mám několik serverů s SAS, U320 i SATa disky. Z SATa je nejrychlejší RAID 0 s WD Raptor na řadiči Promise. V podstatě je na tom s čtením jako Raid1 s U320 (10000),řadič s 128 MB, u zápisu vede SCSi.

[stativ]

Raid 5 to opravdu nezrychlí. Sice se může zdát, že když je to stripped, tak se to zrychlí, ale u RAID5 se musí počítat s počítáním parity. Pro tenhle účel je lepší RAID 0 a ještě lepší RAID 10 kvůli zabezpečí proti zbuchnutí disku.

Ad softwarový/hardwarový/BIOS raid) Jak je to s rychlostí nevím, s hw raidem jsem ještě neměl tu čest pracovat. Co ale vím, že hw raid bývá dost "vendor specific" takže hrozí nebezpečí, že s výměnou základní desky půjde RAID do křemíkového nebe. Má ale výhodu, že nad něj můžete nasadit jakýkoliv OS. Softwarový třeba není (AFAIK) podporovaný ve windows, s BIOS raidem můžou být problémy v Linuxu (ne nutně, ale musí existovat daný ovladač).

[vice]

RAID 5 opravdu ne. Na databáze používám zásadně zrcadla (t.j. RAID1) a nikoli 1+0, protože já sám nejlépe vím jak rozložit db do jednotlivých segmentů . Ale to jsme jinde, jeden obří db soubor sdílený po síti nerozložíte.

Ad hw/sw RAID - hw raidy bývají v linuxu bez problémů na hp a ibm serverech (minulý měsíc jsem bojoval s nejnovějším dellem, ale nakonec úspěšně); SATA řadiče deklarující "podporu" RAID jsou v linuxu nepoužitelné - alespoň já jsem se ještě nesetkal s žádným, který byl fungoval. Pak to řeším klasickým sw raidem, ten bývá bezproblémový.

A ještě bych doplnil (k předchozím příspěvkům) - nepleťte si RAID1 (5 6 10) se zálohovacím zařízením !!! Redundatní disk nezabrání trotlovi nebo špatnému dnu ty data smazat/přepsat/zku... atd !!!

[gloom]

Díky za příspěvek. Myslím, že zkusím otestovat, jak se bude chovat sw raid na IDE discích a když to pošlape, tak přiměju šéfa uvolnit prostředky na druhý SCSI disk a udělám RAID1 na tom SCSI. Kdyby ty disky nebyly tak šíleně drahé, tak už ho tam mám dávno. Škoda, že mi nikdo nenapsal praktické zkušenosti, jestli ten RAID nezpomalí práci s databází.

Jinak co se zálohování týče, tak data ze SCSI disku (hlavně ta databáze), se několikrát denně kopíruje na druhý (IDE) disk a večer pak na záložní úložiště mimo server. Takže to zálohování opravdu není potřeba tady rozebírat.

[Sandokan]

Nóóóóóóóóó, s tím RAID1 nevím, to je jen prosté zrcadlení a má nějaký význam jen pro bezpečnost při výpadku disku. Takže propustnost bude stejná jako s jedním diskem, ale spíš o něco menší (zvlášť pokud budou oba disky na jednom kanálu).

Zvýšení výkonnosti přinese pouze rozdělení zápisu na více ploch tedy buď RAID0 nebo RAID1+0 nebo RAID5.

Z RAID0 bych měl mrazení v zádech, protože chyba kteréhokoliv z disků znamená, že soubor je v kytkách a není už co kopírovat. Takže zbývá RAID1+0 a RAID5. Na oba bude potřeba min. 4 disky. Pro RAID1+0 to jsou 2 pro stripping a 2 jako zrcadlo. Protože práce s datovým souborem probíhá na stanicích, server se nestará o nic jiného než jen o čtení a ukládání dat a o synchronizaci záznamů. Může mu pomoci větší vyrovnávací paměť, ale procesor se bude asi nudit někde na 5-10% zatížení, takže ani nemusí být v tomto případě rozdíl mezi RAID1+0 a RAID5. Nemám to už na čem vyzkoušet, souborové databáze máme už jen pro příležitostné nahlédnutí.

Pak je ještě další možnost nasypat ten soubor do RAM disku. Pokud má 500MB, dá se do stařečka investovat nějaká paměť, spáchat 2G RAM disk (to půjde i ve Widlích) a soubor tam při startu zkopírovat. Zkrátily by se intervaly zálohování a chtělo by to opravdu neprůstřelnou UPS, ale zvýšilo by to propustnost výrazně.

ZDAR!

[gloom]

Čoveče, to není špatnej nápad. Ten kompl není žádný ořezávátko, přece jen je to stavěno jako aplikační server a dva xeony jsou výkonné až až. 2GB RAM a SCSI disky na 15000ot/min. dávají určitou záruku výkonu, jen je škoda, že při tomhle použití se ten výkon skoro nikde neprojeví. Kdybych věděl, jak v FreeNAS nastavit, aby používal jako cache celou RAM, tak se ten soubor v podstatě z cache ani nehne. Použít to natvrdo jako RAMDISK, to není moc vhodné, protože databáze je v podstatě s vyjímkou oběda pořád otevřená, takže s ní nelze externě manipulovat. Jen tak v průměru jednou za dvě hodiny se soubor uzavře a na ten moment číhá démon, který ji ihned zkopíruje na zálohu. Nevím, jestli bych šel do takového risku, abych to nechal v RAM, přece jen nějaký problém či výpadek a mám o průser postaráno. Když to bylo na disku a něco exlo, tak si to access opravil při příštím startu sám. Nějaký jeho vnitřní mechanismus rozpoznal nekorektní uzavření souboru a dal si to do pořádku. Ale když si to vytáhne ze zálohy, tak tam žádná chyba nebude, jen se práce vrátí o nějakou tu hodinku či víc nazpět... a to mě zabijou lidi, protože doteď si nanejvýš znovu udělali poslední otevřený záznam, při jehož editování to zdechlo. No, ještě by byla varianta zkusit to kopírovat v rámci ramdisku (protože to by zazálohování trvalo chviličku a mohlo by se dělat mnohem častěji) a pak teprve ukládat na harddisk tu kopii, takže bych nebránil ostatním používat tu originální databázi. Díky za tip, tohle by mohlo i fungovat dobře:)

[stativ]

Když připojíš někam do adresářové struktury tmpfs (zaručeně je v NetBSD a FreeBSD) a nahraješ tam ten soubor, tak by neměl být problém ho zálohovat. A když dáš proti výpadku UPSku tak je to takřka neprůstřelné.

[gloom]

Tak nakonec to vyřešil FreeBSD sám. Evidentně si to velmi efektivně bufferuje samo o sobě. Rychlost je teď naprosto super. Oběma směry to tahá 40MB/s a s databází se pracuje stejně rychle, jako když to bylo na lokálním disku.

[pavlix]

Pokud nesletí server :D.

[Sandokan]

Nějaký čas jsme kdysi provozovali podobně zběsilou účetní databázi (FoxPro). Tenkrát to bylo na NetWare 3.12 a se 100Mb sítí. Limitující byla rychlost serverových disků a zpravidla nevydržely déle než rok, i když se všechno četlo i zapisovalo přes cache (myslím, že pro tenhle typ aplikací byl NetWare nedostižný).

Asi bych podobně jako kolega doporučil RAID 1+0 a HW RAID by měl být lepší.

Další věc bude nějaká optimalizace Samby pro výkon (na nastavení Samby jsou docela příjemné nástroje jako třeba SWAT nebo i Webmin).

U switchů je dobrý zkusit spravovatelné, protože je pak dobře vidět, co se na kterém portu děje podle mých zkušeností není špatná volba SMC. ZDAR!

[gloom]

Trochu jsem pokročil i s výběrem vhodného switche. D-Link DGS-1216T 16-port 100/1000+2xMini-GBIC slot smart switch podporuje 16 gigabitových portů a umožňuje trunking (sdružování) až 4 portů, tzn. do serveru nacpu 4 gigové síťovky a všechny je spojím do jednoho pásma, takže budu mít pro server full duplex 8 gigabit. Switch momentálně stojí 4560Kč (ve 100Mega) a síťovky nějakých 400Kč (D-Link DGE-550T do 64bit PCI), takže budu mít upgradovanou síť na parádní výkon za cenu cca 6000Kč, což je vynikající cena. Čekal jsem podstatně víc. Teď už jen nevím, jestli FreeNAS podporuje bonding ( více síťovek na jedné IP ), ale pokud ne, jsem připraven porvat se s Linuxem a dostat ho tam, protože pod ním to jde :D

Začínám si libovat v ne-Windows řešení, doufám, že se nedočkám zklamání...

[vice]

Ještě bych tě zchladil s tím switchem - za prvé d-linku se vyhýbám kde můžu, ale je to jen opakovaná subjektivní životní zkušenost (nemíním zakládat flame!) ; za druhé trunk 4x1G ???? dokážeš to zásobovat daty ??? To je zas jen rýpavá otázka, jestli nepošetřit na giga portech a koupit něco jako např. LINKSYS SRW224G4 - skutečně nechci voheň, jen si subj. myslím, že vždy lze koupit něco lepšího než parodii na managenment d-linku

[gloom]

Jasný, když zjistím, že mi server nedá víc dat, než na kolik postačí 2 síťovky, tak použiju jenom 2. Nepoznám ale víc, dokud to nezkusím. A ten switch si omrknu, zapůjčím a pak se uvidí. Na ten Linksys se podívám taky. Dík.

[gloom]

Ajaj, teď jsem se podíval na ten Linksys, co mi doporučuješ, a určitě vím, že to není vhodná volba. Je to totiž jen 100Mbit a na tom se mi práce s databází ani nepohne. Já ten D-Link vybíral pečlivě a nemám s D-linky nijak špatné zkušenosti. Používám od této značky většinu komponent na sítích a ani kazovost není nijak vysoká. Jednou jsem sice použil v jedné firmě switch 48x1Gbit a ten po měsíci zdechl, ale druhý, co jsme místo něj dostali, jede už přes rok bez problémů. Dražší switche nemá cenu kupovat, protože jediná věc, kterou tam potřebuji, je rovnoměrný přístup ze všech stanic, takže management a všechny ty vymoženosti kolem nevyužiji. Doteď jsem tam fungoval na dvou switchích Ovislink 8x1Gbit a stíhalo to. Ale přece jen výkonová brzda byla v serveru kvůli Windows. Kdežto s tím FreeNASem jsem zjistil, že pak je úzké hrdlo ve switchích a proto tam chci dát ten D-Link. Na 100Mbitu se nedalo pracovat. Člověk klikl a čekal 15 sekund na odezvu. S gigovou sítí to dělá prodlevu kolem 4s a to už je lepší. Jakmile vytáhnu výkon na switchi, bude to super.

[vice]

Ten kontrétní Liksys byl jen příklad, může to být třeba 3com, hp, zyxel ...

S d-linkem jsem neměl na mysli ani tak poruchovost, jako spíš to, že manag. switch by měl umět věci, které ty d-linky většinou neumí. Ale asi jsem zatížen historickým případem, kdy mi do páteře, jejíž nejvzdálenější body byly od sebe cca 3km nutili "menažovatelné" d-linky, které šly "menažovat" po seriové lince. To jsem d-linku ani po 7 letech neodpustil

[Jiří Veselský]

Konkrétně D-Linkové switche DGS-12xx mají jednu úžasnou feature - mám-li do něj zapnutý počítač s neinicializovanou síťovou kartou (např. vypnutý počítač s Wake-on-LAN, nebo prostě zapnutý počítač, který se ještě nerozjel a nedohodl si rychlost), funguje příslušný port jako 10Mb HD a CELÝ switch se degraduje do této rychlosti - takže i když ostatní zařízení mají gigový link, switch switchá jenom deset mega. Ověřeno s několika typy těchto switchů a různými zařízeními s různými síťovkami, takže to zjevně není náhodný jev

To jenom tak, abyste se s tím switchem nevydu..., ééé nezklamal.

[frr]

Tohle mě zajímá. Mohl byste upřesnit, co byla zač ta neinicializovaná síťovka, která jela 10/half a celý switch kvůli ní brzdil?

Mám tady DGS-1216T, a zkusil jsem Vámi popsané chování reprodukovat. Jako "pitomou" síťovku jsem zkusil použít Intel PRO 1000 - ten se i ve stavu StandBy+WoL spísknul se switchem na 100 Mb, takže jsem nemohl nic moc otestovat. Když jsem tam dal stařičké ISA SMCčko, které jelo pochopitelně jenom v zapnutém stavu, tak se pochopitelně spojilo na 10/half, a i když jsem třeba utekl do BIOS Setupu, tak ten switch na ostatních portech pořád pouštěl 100 Mbps (neměl jsem po ruce dva stroje s gigáčem, které bych pustil proti sobě).

Ten můj switch hlásí "Firmware version 4.10.02, Protocol version 2.001.003".

Podle mého ten Váš problém vypadá spíš na debilní chování "flow control". Těžko říct, proč a jak - neřekl bych, že by hloupá síťovka posílala ve StandBy stavu "pause" framy, spíš by ten switch musel tyhle frejmy generovat sám, pro ten pomalý port... nerozumím tomu. Fakt je, že asijští výrobci hardwaru dokážou vymyslet všelijaké mozkově vadné nestandardní fičury a ještě je prezentovat jako konkurenční výhodu Ve firewallovém hardwaru "power-down bypass" mezi porty pomocí relátek, ve switchi ochranu proti broadcastovým bouřím na bázi rate-limitu apod.

Osobně mě na tom switchi zarazilo, už když jsem ho vybalil, že obsahuje nějaký prašivý 40mm ventilátor a nedá se mu vlézt "pod haubnu" - aspoň já jsem nezjistil, jak se to víko sundavá. Je buď hodně silou naražené, nebo přilepené, nebo přibodované. Nůžky na plech nebo flexu na něj brát nechci, protože je ještě v záruce. Po půl roce ten ventilátor už podezřele ševelí.

Jinak se mi ten switch chová překvapivě způsobně. Moc od něj nečekám a nevisí na něm moc lidí.

[frr]

Tak jsem se tomu D-Linku dostal pod haubnu. Koupil jsem další kus, pomohlo nepatrně zvýšené násilí (stačilo umýt si ruce, aby neklouzaly po naleštěném povrchu skříně). Ten 40mm ventilátor půjde vyměnit, jenom škoda, že není hlídaný nějakým alarmem (nemá ani vyvedenou sondu). Je trochu otrava nasazovat to víko zpátky - opatrně hlavně na stínící kryty SFP slotů.

Zaujala mě hezky čistě navržená deska plošného spoje. Vynikající je, že hlavní zdroj i onboard step-down regulátory jsou jako první v cestě nasávaného vzduchu, takže se dobře chladí. Už jsem viděl pár menších switchů, které časem začly blbnout, a stačilo vyměnit sušený kondík v regulátoru.

Až to bude po záruce, vyříznu kruhovou díru do haubny a namontuju pomalý 12cm ventilátor

Zaujal mě použitý procesor Marvell 88E6218. Těžkou dřinu odvede gigová switchovací matice Marvell 98DX163 (vč. .1q, .1p a .1x), takže výše uvedený procesor podle mého dělá jenom webové rozhraní. Přitom obsahuje 6portový 100Mbps switch a docela nadupané ARMové jádro. Původně je ten čip určený samostatně do malých SoHo routerů. Takže kdyby D-Link vyvedl na čelní panel aspoň jeden FastEth port z toho procesoru (jeden z portů má dokonce on-chip PHY), tak by ta věc mohla fungovat zároveň jako stovkový router/firewall do internetu

Jinak ta switchovací matice od Marvellu bude zřejmě společným jmenovatelem několika velice podobných switchů od různých firem, které se nedávno vyrojily takřka zároveň a mají velmi podobnou sadu vlastností (i když ne zcela stejnou). Podle fotek na internetu je hodně podobné i vnitřní uspořádání skříně - buď na tom není co vymyslet, nebo všichni vycházejí ze stejného Marvellího referenčního plošáku

[marek]

Dobry den.

Podle meho nazoru: Pokud se vejde cely velky soubor do cache, je vpodstate jedno, na jakem je filesystemu.

Jde jenom o to, donutit ho, aby v te cache byl.

Na vcelku libovolnem UNIXU vetsinou plati, ze pokud napisete cat velky_soubor > /dev/null, mate ho v cache(pokud se tam vejde).

Co se tyka bondovani - co jsem kdy zazil - nezrychli se jedno osamocene cteni, ale zrychli se konkurencni pristup.

Nevim jak funguje MS ACCESS, ale pokud neprobiha synchronizace prilis casto (nebudou se potkavat pozadavky z ruznych stroju), pak Vam bonding nic moc neprinese.

Marek

[Krakonoš]

Bonding mu přinese (pokud bude fungovat) něco jenom v případě, že bude více uživatelů přistupovat najednou k velkým datům. V případě MS Access bych řekl, že k více databázím (jestli přenáší celej soubor, nemůže s ním pracovat více lidí najednou,ne?).

Osobně si o tom také myslím svoje, ale záleží na vytížení sítě. Občas bývá problém, že ten chce hodně dat a ten a pak je bottleneck na síťovce serveru,..

[Krakonoš]

Neodpustím si několik komentářů:
- sdružené 4 porty není špatný nápad. Vzhledem k tomu, že mnoho levného hardwaru (nevím jak tenhle D-Link, ale nemyslím si, že o bude nějaký extra zázrak) sice podporuje "gigovou síť", ale toho gigabajtu se nikdy nedosáhne - viz. příspěvek na začátku s FreeNAS vs. Win{XP,2k} - switch to brzdil a to budou dělat i další.

- proboha nepleťte RAID a zálohování. Když vidím slova "jestli máš vyřešené zálohování, dej tam RAID 0", tak mi vstávají vlasy na hlavě:
    a) Je o dost pohodlnější a praktičtější vzít z RAID 5 (Ano, je můj oblíbený) špatnej disk, vrazit tam novej a nechat ho sestavit data podle parity.

    b) Je hodně zdlouhavé a nepraktické obnovovat data z pásky, pokud to není opravdu nutné. I když to máte na disku. Představte si, že těch 10 lidí dělá s účtem. Ráno se udělá záloha, lidi přijdou do práce. Bude třeba před výplatou. Účetní se pustí do práce, udělaj výplaty, vyúčtování a kýhofrasa co všechno se tam ukládá. Večer odejdou, vy ráno přijdete a vaše pole s RAID 0 bude vydávat krásný zvuk ne nepodobný čtecí hlavě brousící plotnu (nepříjemný zvuk mimochodem, mám z vlastní zkušenosti). Běže a vysvětlete účetním, že mají celý včerejšek udělat znovu A NAVÍC musí počkat do odpoledne, než obnovíte zálohy.

    c) Jak již někdo poukázal, RAID vám nepomůže od uživatele, který nejdřív maže a pak myslí. (Ano, "kancelářské kryse" řeknete, že je to jejich chyba a neměli si to mazat (a ještě, že se jich to ptalo, jestli opravu to chtějí smazat), ale vysvětlete to šéfovi. Asi to nebude chtít slyšet)

[kafi]

Tak abych taky prispel tak s tou siti se mi to nejak nezda proc vam 1Gbit sit jede jen 100Mbit. Nemate nekde problem v konfiguraci switchu, pokud jsou tedy managovatelne (hezky cesky ) ? Pokud ano asi bych prvni poresil jestli se switche spravne domlouvaji na rychlosti prenosu(duplexy,atd.). Jestli nemate na portech nejake errory (chyba kabelu, propojek, atd.). Musite si uvedomit ze 1Gbitova sit na UTP ci STP kabelech je vcelku nachylna na jakekoliv poruchy. staci jen spatne nakrimpovany konektor ktery se na 100Mbitu zda byt naprosto OK a na 1Gbitu uz to zhazuje linku na 100Mbit. Jinak jako distribuci bych doporucil Debian a nebo jeho odnos Ubutnu dnes 8.04 je to mocny linux se spoustou balicku v repozitorech a krom toho tato verze je vydana s planovanou 5 letou podporou. jak jiz bylo psano pro souborovy server jedine Samba(taky zadny jny neni aspon teda neznam). A jeste dodam pokud ste pohodlny na konfiguraci doporucuju Webmin.

[František Ryšánek]

RAID5 je smrt pro databázi hlavně proto, že při updatu 1 sektoru musí před-načíst celý stripe set, přepočítat paritu a zapsat zpátky upravená data plus paritu. Proto je random zápis malých bloků do RAID5 pomalý.

Buffering v jakémkoli UNIXu (FreeBSD, Linux) funguje tak, že co se jednou načte z disku, to zůstane v RAMce v cachi, dokud není potřeba volná RAMka pro nějaký user-space proces. Takže to nemusíte nějak explicitně řešit. Pokud máte 2GB RAM a 500 MB soubor, měl by se dlouhodobě sám od sebe držet celý v RAMce (pokud tam někdo zároveň na ten druhý disk nekopíruje filmy apod.) Schválně v tom UNIXu zkuste v příkazové řádce celý ten 500MB soubor kopírovat opakovaně do /dev/null, a stopujte si čas Při zápisu funguje write-back a data pochopitelně taky zůstávají v RAMce v bufferech, dokud není potřeba RAMku na něco smysluplného použít. OS-based write-back má tuším nějaké maximální povolené zpoždění (sync), takže se nestane, že budete mít v bufferech dvě hodiny špinavá data - ale na druhou stranu to znamená, že při přetížení disku se write-back cache do jisté míry "otupí", přestože RAMky je dost a dost.

Areca vůbec není špatný RAID. Čtyřkanál ARC-1110 byl dlouho jeden z nejrychlejších čtyřkanálů, co se dělaly. Zápis do RAID5 až cca 250 MBps sekvenčně, pokud to disky zvládnou. Teprve dneska jsou disky, které z něj můžou udělat "úzké hrdlo". Pokud byl pomalý, mohl za to patrně RAID5 (viz výše, plyne to z teorie, průchodnost XORu daného řadiče na to nemá vliv) případně špatná volba disků. Na random access (databázi) spíš než na cokoli jiného jsou bohužel nejlepší "enterprise" disky, tj. nejlíp SCSI 10k/15k RPM (Cheetah SCSI nebo SAS) nebo aspoň WD Raptor. Barracuda NS to nevytrhne. Rychlé disky poznáte v aktuálním ceníku především podle vysoké ceny a nižší kapacity Klíčovým technickým parametrem je celková průměrná doba přístupu (vystavení hlavy + rotační latence).

Nemám strach, že by pro pár stanic nestačil levný Gb Eth switch. Jasně - bacha na kabeláž. Managed switch je určitě vhodný pro snazší přehled, jak jsou na tom různé Eth porty - vidíte počítadla chyb apod. Zmíněný Web-smart Dlink mám taky a zatím jsem mu nenašel žádnou zásadní mouchu. Taky jenom pro pár stanic, a jede slušně. "Managed" switch za ty prachy, lepší než drátem do oka. Pokud se týče vaklavé kabeláže, tak zrovna tenhle switch tuším umí na jednom portu diagnostikovat kabeláž. Pokud se nedaří sekvenční zátěží vystropovat gigabitovou síť, zkuste v OS na klientu i serveru zvětšit MTU (povolit jumbo framy). I když pro tu databázi to asi nemá význam, tam je přirozená velikost transakce menší. Různé síťovky jsou různě kvalitní, mají různě velké buffery, navíc možná asymetrické pro RX a TX (viz Intel a jeho rozlišování desktopových a serverových síťovek). Jak klient tak server může mít na nekvalitní síťovce problém s rychlostí zpracování interruptů, což představuje úzké hrdlo na "počet paketů za vteřinu" - dobré síťovky mají interrupt amalgamation apod.

Při pouhých 10 stanicích nemá smysl bonding na straně serveru - nikdy tam nebude takový souběh provozu, aby to stálo za tu práci s konfigurací. Ten server nepodezírám z toho, že by měl disky i síťovky pohromadě na 1 segmentu PCI 32@33, takže tam úzké hrdlo nebude... Jinak zmiňovaný SCSI disk dá odhadem 80-100 MBps sekvenčně, různě staré desktopové a enterprise disky se budou pohybovat řádově od 50 MBps do 150 MBps. Což zhruba odpovídá jednomu gigabitovému portu. Pokud se Vám podaří držet tu databázi v bufferech, tak to je jiná... průchodností RAMky udávíte jakoukoli síť

Taky bych se při pouhých 10 klientech nebál nějakých esoterických problémů s konfigurací zámků v sambě...

FreeBSD v posledních verzích (cca od 5.x) vůbec není špatný serverový systém, pokud se týče průchodnosti sítě a FS.

V případě RAID 1 nebo 10 bych se softwarového RAIDu nebál, rychlé to bude dost - jenom uživatelský komfort bude kulhat. Proti firmwaru Areca určitě.

[František Ryšánek]

Málem bych zapomněl: na síťovkách i na switchi zkuste najít volbu flow control, a pokud najdete, tak ji zakažte. Tahle chytristika v Ethernetu může být kontraproduktivní. Vrstva TCP si to řeší po svém a lépe.

[dik]

...k čemu přesně flow control slouží? dík dik

[František Ryšánek]

Flow Control v Ethernetu byla patrně myšlena jako přesně totéž na RS232 (RTS/CTS) - aby přijímající zařízení mohlo přímo v Ethernetu signalizovat, že má plné buffery, nestíhá a že vysílač má pozdržet vysílání.

Nicméně pokud nad tím Ethernetem běží TCP/IP, tak TCP stack má svůj vlastní, inteligentnější mechanismus pro dimenzování rychlosti odesílání, a s L2 flow control z Ethernetu se nemá moc rád. Výsledek podle mého bude, že TCP relace neběží rovnoměrně, ale "houpe", a výsledná průměrná rychlost není jednoznačně určitelná...

Problém "head of line blocking" by se Vás teoreticky týkat nemusel, pokud máte všechny klienty na gigu - ale čert nikdy nespí.

http://virtualthreads.blogspot.com/2006/02/beware-ethernet-flow-control.html

http://en.wikipedia.org/wiki/Ethernet_flow_control

[František Ryšánek]

Ještě k tomu Vašemu měření průchodnosti při zápisu a čtení:

- čím přesně generujete ty přenosy? Kopírováním souboru mezi síťovým diskem NASu a lokálním harddiskem klientské stanice? Počítám že ano. Lepší je kopírovat z /dev/zero do souboru nebo ze souboru do /dev/null, což se ale dá podle mého holýma rukama jenom v UNIXu.

- jak přesně máte připojené gigové síťovky na klientských stanicích, resp. hlavně na stanici, která slouží jako měřící pracoviště? Pokud by se stalo, že gigová síťovka sdílí jediný segment PCI 32b@33MHz s diskovým řadičem, tak se spolu musí podělit o pásmo teoreticky 132 MBps, prakticky cca 100 MBps half duplex. Děleno dvěma je 50 MBps. Není úzkým místem koncová stanice?

- disk o kapacitě 850MB, i pokud je zdravý, může mít sekvenční přenosovou rychlost odhadem v jednotkách MBps, pokud se správně pamatuju, řekl bych tak 3-5 MBps. To je na začátku (vnějším okraji) plotny. Při vnitřním okraji plotny to spadne na půlku nebo i na třetinu. Při testech čtení se to projeví jenom při prvním čtení, pak už by data měla téct z bufferů. Při testech zápisu se write-back cache uplatní jenom zpočátku (prvních pár sekund), pak se tuším projeví pevné zpoždění operace sync().

- jste si jist, že ten 850 MB disk ze šuplíku je ještě zdravý? On nemusí mít vysloveně vadné sektory, ale už může mít problém se seekováním, které se projevují zadrháváním toku dat. Chce to otestovat napřed disk, abyste si mohl být jistý, že Vám měření nekazí nemocný disk. Osobně na to používám třeba "dd bs=4096" a iostat v Linuxu.

- pokud byste chtěl měřit průchodnost gigabitu kopírováním souborů mezi lokálními harddisky serveru a klienta, skutečně z disku na disk bez nějakých berliček s velikou cachí a nulovými zařízeními, musel by mít diskový subsystém na obou koncích průchodnost minimálně 100 MBps (nebo teoreticky 120 MBps?). Ze SATA disků tohle umí jenom nejnovější Barracuda 7200.11 na začátku plotny, když se dobře vyspí. Jinak by to mohly zvládat poslední cca 2 generace "enterprise" disků od Seagatu (cheetah SCSI nebo SAS). Taky to umí RAIDy s procesorem IOP321 nebo vyšším (IOP303 to nedá, možná v RAIDu 0). A pozor na čipsety se slabou vnitřní průchodností - řekněme Intel 845 a starší.

[gloom]

Díky za vyčerpávající vysvětlení :) Začnu odzadu...

Ten malý disk tam byl jen na zkoušku, abych nemusel rušit Windows, kdyby si ten FreeNAS nerozuměl s řadiči. Ale naštěstí je to dost vychytaný soft, takže si našel všechno a teď už všechno jede jak na drátkách.

Databázi jsem hodil na SCSI disk (Seagate 76GB,15000rpm), pasivní data pak na velký disk na IDE a vše jede, jak má. Testy jsem dělal jen kopírováním z/do serveru na pc přímým propojením kabelem. Čtení/zápis 40MB/s (=320Mbps?), pokud šlo o jeden velký soubor. Víc jsem zkoušet nepotřeboval.

Práce se VELMI ZŘETELNĚ zrychlila. V podstatě ani není poznat, že se pracuje na databázi přes síť. Nezaznamenal jsem žádné zpomalení proti práci na lokálním disku ani při velkém výběru a filtrování položek a současné práci všech lidí. FreeNAS cachuje perfektně.

Mise byla splněna...

[František Ryšánek]

Ano, takový výsledek bych si představoval Gratuluji k dobré práci.

Je to paráda, mít v serveru tolik RAMky, kolik býval člověk zvyklý mít disku... Ono z toho serveru přes 1Gb síť to *bude* rychlejší než z lokálního IDE/SATA disku: 100 MBps, pokud to bude z bufferů tak přístupová doba ve stovkách mikrosekund.

Taky mám vždycky radost jako malej kluk, když si na moderním železe pustím nějakou softwarovou vykopávku, a ono se to chová jako babeta s motorem z migu.

[Kyosuke]

Taky mám vždycky radost jako malej kluk, když si na moderním železe pustím nějakou softwarovou vykopávku, a ono se to chová jako babeta s motorem z migu.

Takové aplikace se dají dělat i dneska, když se chce. Třeba jsem teď objevil Btree+Hash databázovou knihovnu s rychlostí zápisu někde kolem hodně set tisíc zápisů za sekundu. O to víc pak mrzí ty zprávy, že kamarád údajně "musí" partitionovat 8GB read-only MySQL databázi, protože server za čtvrt miliónu je moc pomalý na nějaké joiny čtyř tabulek. Mně se nechce věřit, že ta mašina by při tom hledání nemohla lítat jak z praku, kdyby skutečně chtěli. Dokonce i s tím podivným softwarem.

[Zdenek]

Zdravim, kdyz uz se tu bavi o rychlosti disku a databazi kolem 500MB, co pouzit neco jako iRAM od Gigabyte? Vicemene RAM disk, omezeny pruchodnosti SATA portu, zalohovany proti vypadku. Vice treba zde http://pctuning.tyden.cz/index.php?option=com_content&task=view&id=6347&Itemid=45 Cena by uz taky dnes nemusela byt tak smrtelna.

[bodlinka]

Sice asi idem s krizom po funuse no dospel som sem az teraz pri hladani riesenia ineho problemu. Ako spokojny uzivatel FreeNAS chcem len doplnit par informacii.

FreeBSD nad ktorym je FreeNAS postaveny podporuje tzv Bonding (Link Aggregation, Etherchannel). Celkom dobre je o tom, aj o Failover popisane v handbooku: http://www.freebsd.org/doc/en/books/handbook/network-aggregation.html Nazov zariadenia "lagg" je zrejme odvodeny od link aggregation. Tolko k popisu zo strany FreeBSD. V novej beta 2 verzii FreeNAS, je uz totiz podpora pre lagg/failover zakompilovana do jadra. Nakolko vsak je to v tejto verzii funkcne si netrufam odhadnut a celkom zrejme to ako celok na produkcne nasadenie nebude vhodne. Ak by ste to vsak v buducnosti potreboval vy, alebo niekto z citatelov, moze sa takato informacia hodit.

Tu je link na oznam o vydani aj s popisom noviniek: http://www.freenas.org/index.php?option=com_content&task=view&id=43&Itemid=24