Názory k článku Databázový server na platformě Intel 32bit

Co je tohle za blabolovy clanek? Autor ponekud zapomina na cenovou stranku veci - SCSI disky jsou sice zupa, ale jejich nekolikanasobna cena opravdu nevyrovna jejich zcela zanedbatelny vykonovy naskok.
(viz: SCSI: 36GB 10kRPM 4465,- , IDE 120GB 7.5kRPM 2514,- (oba dva Seagate - cenik TS Bohemia) - tzn. staci dat dva IDE disky, a mam vyssi vykon (strip), ale skoro sedminasobny (!!!) objem - a to ani nemluvim o SCSI radicich, ktere take nejsou nejlevnejsi). Take se autor nezminuje o krasne veci, ktera se stava znackovymi servery: vyprseni podpory. Pak to dopada tak, ze suplicek do RAIDoveho pole (tzn 2 plechy a 2 odlitky z PVC) vas stoji 30kKc, protoze proste neni podporovan. Moc prima. Opravdu jsem od nekoho z domeny netmag.cz cekal neco kapanek sofistikovanejsiho.

SCSI disky mozna nemaji prilis odlisnou rychlost pri sekvencnim pristupu nez IDE, ale pri nahodnem pristupu to mnohanasobne vynahradi. Tohle je asi jedina vec, ve ktere musim dat autorovi za pravdu, pouziti SCSI disku na databazi je opravdu dost vhodne (vetsi spolehlivost, mnohem vyssi vykon a nizsi rezie pri nahodnem pristupu a relativne mala velikost databazovych dat).

SCSI se nevyplati na velke objemy dat, napr. velke FTP servery, kde navic bude prevazovat sekvencni pristup a bude minimum zapisu. V takovem pripade ma ATA reseni (nejlepe v kombinaci s nejakym inteligentnejsim radicem) opravdu o dost lepsi pomer cena/vykon.

Nevim jak jste prisel na to, ze SCSI disky jsou spolehlivejsi nez IDE. Mame na serverch jak SCSI, tak IDE disky a odhladl bych, ze SCSI odchazeji 2x casteji. Jejich vyssi cena (SCSI) je dana vyrazne mensim prodejem a ne lepsi technologii. Osobne si myslim, ze nasazeni SCSI disku je dnes prezitek, neboli zbytecne vyhozene penize.

aha, zapojím si na své PATA rozhraní v serveru všech 11 IDE disků :-) Máme taky SCSI disky v server a odhladl bych, že SCSI odcházejí asi tak 1/8x častěji než IDE :-) SCSI disky mají určitě něco do sebe a že je přežitek, to si osobně nemyslím.

To není argument. Mám v serveru SATA a připojím všech 11 disků taky. 3ware dělá řadiče až po 12 discích. Teď plánuju jednu bednu s dvěma 3ware řadiči na 24 disků...

Tak to rozhodne ne. Staci si natahnout system na 2x 9GB SCSI disk po 1000kc kus (40MB/s, stare zelezo) a srovnat to s touze konfiguraci ktera ma misto tech dvou SCSI disku jedno (nebo dve) 40-120GB IDEcka(ATA100+). Rozdil cini skoro dvojnasobek pri startu systemu, skoro trojnasobek pri kompilaci kernelu. Sorry ale SCSI ma sve misto.

Na druhou stranu musim hrube nesouhlasit s IDE diskem na system, tam je zakopany pes kvuli kteremu ta masina nepojede. Z vlastni zkusenosti vim, ze sebelepsi SCSI system sunda na uroven IDE systemu i cteni z IDEcdromky (znakovy SCSI server IBM pseries), nemluve o kombinaci pevnych disku. Je to cele zpusobeno delayovanim operaci a podobnymi vecmi, ktere zatez procesoru pri intensivnim kopirovani nikdy nedostanou nad 40% a s pustenymi mp3ojkami poskoci malokdy. Zkuste si pustit hudbu pri kopirovani po IDE disku a narazite! Proto SCSI. Jenze kdyz se mu da IDE disk, jde tohle vsecko do haje, nebot se neustale ceka na dokonceni operaci nad nim i kdyby slo treba o logovani.

K domaci SCSI worksatione mam fileserver s IDE diskama a myslim ze lepsi domaci sestavu si nelze prat.

PS pro korekturu: SCSI pouziva 160 a 320 nikoli 180 a 360, ale to je jedno...

Když se podíváš na parametry SCSI a ATA disků snadno nahlédneš, že SCSI disky mají cca poloviční čas na seek.

Jak je to s fault tolerance, resp. chovanim pri katastrofickem vypadku napajeni? Mam dojem, ze jsem cetl neco o atomicite zapisu sektoru na SCSI discich a o tom, ze u typickeho IDEcka to neni zaruceno.

transakce a fronty bych hledal u SCSI rozhraní. IDE tohle ještě nevede.

Je moc hezke, ze nam autor popsal, jaky HW lze v soucasne dobe koupit (tu inzerovanou nadcasovost jsem jaksi nepostrehnul). Cely clanek na me pusobi dojmem "kupme si co nejlepsi zelezo". Bohuzel dost chybi nejaka uvaha, jake jsou skutecne potreby. Mit dedikovany server je hezke, ale kvuli neprilis vytizenemu IS asi nebudu shanet znackovy 4-way server a jeste dalsi masinu pro Apache.

Kdyz uz se autor tolik rozjel s tim HW, tak bych alespon ocekaval nejake benchmarky, grafy, statistiky apod., ktere by ukazaly, jak vykon jednotlivych komponent ovlivnuje vykon systemu jako celku pri konkretnim druhu zateze. Informacni hodnota by tak strme stoupla.

Co skutecne nechapu, je doporuceni v 4-way znackovem serveru s RAIDovym SCSI radicem a nekolika SCSI disky urcenymi pro databazi dat system na IDE disk, to by udelal snad jen uplny debil.

Jdu vymenit disky v poli, nektere tam uz jsou vice nez dva roky :-)

Osobne se domnivam, ze mezi clanky, ktere se na toto tema pisi, maji uzitnou hodnotu vetsinou jen ty, co pisou postarsi panove, kteri pracuji par (desitek) let ve firme, kde maji alespon tisice uzivatelu a navic je clanek zpracovan formou praktickych zkusenosti s nejakym konkretnim zelezem. Hodnotu maji totiz ty prakticke zkusenosti, ktere nelze tak snadno "vygooglovat" jako parametry disku. A prakticke zkusenosti s databazovym serverem pro vetsi IS nelze ziskat tyden pote, co jsme nalesteny novy server ulozili do zatim poloprazdneho racku.

Databazovych serveru existuje hodne druhu, ale autor by si mel uvedomit, co skutecne v databazovem serveru ovlivnuje vykon. Pokud neni sestava vyladena pro databazi jako celek, tak vetsinou splace uzivatel nad vydelkem. Jako vhodnou volbu pro DB server bych videl napriklad KeyServer - http://www.keyserver.cz a to D-ckovou radu, ktera je cenove hluboko pod resenim se SCSI disky a spolehlivosti na stejne urovni.

Hmm, kdyz uz se tu ta reklama objevila, tak jsem se na ty stranky dival, protoze se zrovna po vhodnem hw na fileserver divam.

Prijde mi, ze to jsou 2 chlapi, kteri prodavaji supermicro servery s predinstalovanym linuxem s xfs a raid5.

Na strance nemaji ani ico, ani sidlo, jen 2 mobily...

Nevidim nikde napsano, jestli je to hw, nebo sw raid.

"Diskovou cache" ocividne mysli RAMku

Mylim se? Mate s temi jejich servery nejake prakticke zkusenosti?

Jinak nic proti supermicro, jeden mame a jsme spokojeni.

(Pokud mate naladu, napiste mi prosim pripadne i na emailovou adresu.)

Pár takovýchto podobných databázových serverů jsem instaloval a naši klienti je dlouhodobě provozují. I když databází byla Oracle 8i, myslím, že nároky jsou obdobné. Přidám k tomu pár svých zkušeností.
* S verzí RAIDu je to závislé na tom, jakou požadujete dobu obnovy po havárii. Pokud máte na zprovoznění čas v jednotkách hodin (HW, OS, databáze i aplikace), pak je jediná volba RAID 5 a HotSwap disky. Ani toto řešení však není samospasitelné. Zažil jsem na značkové sestavě havárii 2 disků najednou (8 měsíců starých)a to neustojí ani RAID 5. V případě, že odstávka není kritická, RAID 0 je nejlepší volba.
* SCSI disky na databázový server jednoznačně ano, třeba jen proto, že jsem neviděl zatím kvalitní HW RAID IDE řadič. Ovšem pozor, ani u SCSI není HW řadič jako HW řadič. Při zápisu většina u nás používaných řadičů nestíhá počítat kontrolní součty a zdržuje disky. Pokles výkonu při zápisu byl v případě levných řadičů až na polovinu. Jedinou použitelnou orientací je asi šířka slova a frekvence procesoru použitého na řadiči.
* velikost paměti počítáme 200 MB pro databázi + 20 MB na současně pracujícího uživatele + nároky OS. To je ale asi silně závislé od databáze a hlavně provozované aplikace.
* výkon procesoru je upřímně řečeno nepříliš podstatný. Jeden z prvních serverů byl osazen 200 MHz Pentii a oproti serveru 1 GHz Pentii byl jeho aplikační výkon jen o 25% menší. Více procesorů ano, ovšem pozor, 1 operace používá jen 1 procesor, tzn. pro aplikaci s jednoduchými rychlými operacemi se více procesorů nemusí vůbec projevit.
* A na závěr, nejdražší čáatí takovéhoto serveru bude stejně právě kvalitní RAID řadič. Kupodivu nejlevněji vychází, pokud takovýto řadič koupíte jako součást kompletního značkového serveru.

ad verze RAIDu: Pokud mne skleroza nemyli, tak existuje jeste RAID6, ktery ma 2 parity, takze dokaze ustat i vypadek 2 disku najednou.
ad SCSI: Souhlas, mj. i z toho duvodu, ze jsem jeste nevidel IDE RAID s plne funkcnimi hot-swap disky (WELLmi dobra a doporucenihodna vec)
ad vykon procesoru: Zalezi na tom, co od databaze pozadujete. Kdyz se bude jednat o DB cast plnokrevneho IS, tak jsou DOST caste slozite dotazy a komplikovane procedury, kde se vykon CPU projevi.
ad radic: Nejlepeji a nejradostneji multikanalovy a s vyhrazenym procesorem na pocitani parity (ale to uz ma kazdy slusnejsi, ze).
ad pamet: Hlavne zavislost na databazi. To, co je v clanku by zhruba mohlo odpovidat PostgreSQL.

Ad RAID6: Ano, ma dvojitu paritu, otazka je vsak, ktory radic a na akom OS (a akym sposobom, napr. propietarny linux kernel modul) ho podporuje. Takisto zapis na takyto RAID je este pomalsi ako na RAID5. Obavam sa, ze cena a komplikovanost prace s RAID6 by vysli vacsie ako raid 1+0

No AHA 29160 ne, nebot RAID6 maji nova doskova pole (treba easystor),
jinak interni RAID raic stoji tak 50.000Kc ma baterie na cache (radic do diskoveho pole stoji podobne 50k-100k Kc).

Ale spice Fibre chanel (treba qlogic 2300, 2200 jso velmi dobre podporovany)

Interni RAID radice jsou dnes malo pouzivane napr. v linuxu je velmi dobry SW Raid a jinak se pouzivaji diskova pole pokud staci 70-60MB/s pouzije se napr. easystor (FB nebo SCSI) s ide disky, pokud vetsi pouzije se napr. powerstor s FB disky (dnes uz jen FB)

Dalsi moznosti je koupe vykonnejsich CPU (treba A64) a pouziti SW RAID 5 s nejakymi SATA disky, treba s Raptory, kdyby nebyly tak hrozne poruchovy.. pravda, hotswap to asi neumi (ikdyz mozna pod linuxem ano), ale to nekde nevadi. Mimochodem, vite, ze wokna umeji IDE hot swap? Kdyz zakazete IDE radic, vymenite disk a opet jej povolite, system disk normalne najde a funguje. Neumi nahodou neco podobneho i linux?

Ale jo, takovejhle hotswap umi linux taky. 'Drobnou' vadou na krase je, ze IDE v tomhle stavu IMHO neodpoji datovou sbernici, takze se muze velmi lehce stat, ze timto odpojenim HDD a) se nic nestane, b) zrusite vsechny aktualni zapisovana/ctena data na cele vetvi (nekonzistence dat na dalsim disku), c) oddelate jak radic, tak dalsi disk na vetvi a mozna i ten, co prave tahat ven.
Proste IDE tohle zatim uspokojive reseny nema a podobny pokusy (kdyz vyjdou a nic neshori) jsou spis dilem nahody, ale ne 'vlastnosti'. Takze pro priste se pred takovym hot-swapem aspon pomodlete :)

Linux by to mel umet pomoci
"hdparm -U /dev/hdx" a "hdparm -R /dev/hdx"

"rychlostí 180 nebo 360 MB" -> nie nahodou 160 a 320?!

supr, uz si bezim koupit Xeona :-)

no nevim nevim, ale cely ten clanek vypada jako kupte si amd scsi nejlip znackovy server, hlavne at je to ten opteroooon a mzona to pojede, bomba, ale nic poradneho sme se nedovedeli

>>3. Volba procesoru: Intel, nebo AMD?
>>Řešení s procesory Intel je populárnější. Ve >>značkových serverech se prakticky s jinými >>procesory nesetkáte. Je to poměrně škoda, protože >>procesory Athlon MP poskytují vynikající výkon >>při použití v SMP systémech, kde jsou až o 30 >>(obvykle okolo 10) procent lepší. Docela hezká >>porovnání AMD a Intelu najdete na webu AMD.

>no nevim nevim, ale cely ten clanek vypada jako >kupte si amd scsi nejlip znackovy server, hlavne >at je to ten opteroooon a mzona to pojede, bomba, >ale nic poradneho sme se nedovedeli

myslis, ze je to tak ako hovoris, hlavne ak sa tvrdi dva mesiace stary fakt, ze AMD nie je v server-och, uz to par tyzdnov to neplati, aj ked uznavam ide o novinku a optimalizacia Oracle pre AMD64 este je len v demo verzii

jenom jednoho? pise se tu ctyri.

Papirove ifnormace o DB serverech jsou hezke, ale prakticke zkusenosti jsou k nezaplaceni.
HW RAID: je oproti softwarovemu neskutecne pomaly. Opravdu bych hoodne zvazoval, zda-li je nutne pouzit HW RAID a jeste bych si overil, jestli ma na sobe baterii, protoze bez ni je mi uuplne na hovno (resp. jeho funkcnost je shodna se softwarovym RAIDem, akorat je pomalejsi).
V okamziku, kdy budete kupovat 4xCPU Intel server bych se podival do ceniku firmy SUN. Budete prekvapeni, ale ve spouste pripadu sezenet SUNovskou masinu levneji nez odpovidajici znackovy Intel.

S tím SUNem to sice vypadá lákavě, ale problém je v tom, že si povídáme o malých serverech pro malé firmy, kde přijetí člověka na administraci Solarisu je nad možnosti rozpočtu IT oddělení.

Skutečně? Mne to přijde hodně podobné administraci Linuxu. A pokud by hrozili potíže s bezpečností, tak se před to postaví Linuxový firewall, docela běžné řešení.

Trosku z jine kopky hnoje.... mame ve firme celkem hodne vytizeny DB stroj (3 ghz p4,2g ram,sata 3ware raid 1 ,2x250G hdd 7200 otacek ) linux + pgsql

Ma smysl premyslet o instalaci solarise 9 ?
Pomuzu si vykonove?
Kdyby yo ,jak moc velky skok pri prechodu linux -> solaris me ceka? (myslim si ,ze umim linux na obstojne urovni )
Jakou hlavni prednost solarisu vidite o proti linuxu?

ps: chtel bych si osahat solaris,hodne me laka ,tak hledam dalsi duvody ,abych sam sebe presvedcil :-)))

Je to dost podobný. Nejsem žádnej Solaris guru, ale co potřebuju, si udělám. Jen si budete muset zvyknout, že std Unixové příkazy mívají jiné volby (a nemívají GNU rozšíření), ale to se dá spravit instalací Solaris companion, kde je spousta GNU softu, takže pak místo "tar" používáte "gtar", apod. Dobrá zásoba GNU softu je na www.sunfreeware.com. Solaris má velmi dobrou dokumentaci. Není žádná pravda, že Linux je velmi dobře dokumentován. Může to tvrdit akorát ten, kdo nemá jinou zkušenost než člověk se starším Linuxem. Na portu 8888 běží Answerbook, což je HTML dokumentace, jak pro administraci tak i pro vývojáře.
Pokud si zaplatíte podporu (není drahá), tak dostanete výborný servis, jak na HW tak na SW. V záruce je myslím podpora zdarma, ale nevím jestli si to nepletu s HP-UX mašinama. Dokonce vám budou pomáhat s problémy při vývoji softu, pokud to vypadá, že problém je v Solarisu. Fakt se tím zabývají a jejich rady vedou k cíli. Na konci však zjistíte, že chyba byla na vaší straně, ale tak už to chodí. :-)

Takže moje rada je, rozhodně Solaris na Sparcu ochutnat, pokud bude příležitost.

Tak si na to date RedHat for Sparc a mate po starostech se Solarisem.

Opravdu DAT nebo DVD burner?
Zde zalezi na velikosti DB dumpu.
Dalsi problem s DAT je v tom, ze obnova s pasky se pocita na hodiny a teprve pak je mozno zacit s obnovou DB. Takze mozna uvaha o malem ATAPI ftp serveru za

No opravdu me pobavilo dat do serveru IDE. Videli jste nekdy co dela IDE disk kdyz se zacne resetovat kuli nejake chybe a vsechno zatuhne a neda se nic deat. A co takovy lowlevel format a vymena zaloznich sektoru to jsem na IDE zkousel kolikrat a nikdy to nefungovalo. No IMHO SCSI je SCSI.

Zdravim

Ten clanek je absolutne o nicem. Vpodstate rika asi toto: "Kupte si ten nejdrazsi hardware a ono vam to mozna pojede." Opravdu jsem se hooodne pobavil.

P.S.: A data budeme ze serveru na klienty nosit na disketach, ze ano...

Zdenek

"RAID 1 (mirror): Obvykle se moc nepoužívá: čtení je sice 2x rychlejší, ale zápis je dvojnásobně pomalejší."
Takove veci si laskave piste do sveho denicku a ne verejne. Kdo to pak ma vyvracet vsem co budou ve vsech disk. forech opakovat s poznamkou, ze to psali na ROOTu? Grrrr.

-- Zakladni predpoklad clanku, ze zajisteni nejvetsi mozne dostupnosti DB se resi nakupen nejakeho bozskeho HW je trosinku ulet. I reseni za nekolik stovek tisic proste jednoho dne bude mit problem. Zakladni otazkou, kterou by si mel kazdy zodpovedet, je co budu delat az to "spadne" a co jsem ochoten investovat do toho, abych tento stav mohl nasledne rychle serit. Vsimnete si nerikam, aby tento stav nenastal. On jednou vzdy nastane a je vhodne znat reseni jeste pred tim.

-- U vetsich DB nebo u systemu kde RAM je plna obsluhy klientu a ne cache vetsinou system ceka na disk a ne na CPU.

-- Dulezite je jak HW pouzivam a pak az jaky HW mam. Napriklad rozdeleni disku, filesystem apod.

-- Jak tu nekdo psal, ze SCSI je blbost. Kde se da koupit IDE s temito parametry: 15K RPM, Average Latency 2 msec, Average Seek Time: Read: 3.6 msec, Write: 4 msec. 8MB cache.

-- DB jsou casto vyrazne mensi nez dostupne disky. Lepsi je vice disku mensi kapacity nez naopak.

-- Neni nic individualnejsiho nez (ne)vykon DB. IMHO je vhodne vzdy prihlednout k aktualnimu nasazani.

"-- U vetsich DB nebo u systemu kde RAM je plna obsluhy klientu a ne cache vetsinou system ceka na disk a ne na CPU. "

Přesně tak. K tím souvisí i další nesmysl v článku a to tvrzení o nutnosti rychlé paměti. Paměť není to, co zdrzuje.
Když nastupovaly DDR, tak ještě nejmíň rok se do serverů dávaly SDRAMy. Byla to vyzkoušená technologie a byly ECC.

Jestli byl cíl napsat článek o ničem s tím, že zajímavé detaily si lidi řeknou v diskusi, tak byl účel splněn ;-)

No jo, ale jak jiz jsem psal: staci koupit 2x IDE, dat je do stripu - rychlost stoupne shruba 1.8x. Jenze kapacita 7x vetsi a cena stejna. A nebude dlouho trvat a IDE disky budou take 10kRPM a 15kRPM. Jojo, lide IT oddeleni velkych firem zapominaji na to, co to znamena setrit prachy.

Nevedomost je sladka :)
Az IDE bude mit stejne pokrocile vlastnosti jako SCSI, tak tento argument bude spravny. Samozrejme v situaci, kdy o IT rozhoduje neinformovany clovek, nebo pokud si delam databazi pro 1-20 lidi, nebo na web, ktery ma 1000 hitu za den, tak je to samozrejme jedno. Docela bych se primlouval za FUNDOVANY clanek, ktery neznalym detailne popise rozdily v architekture SCSI x IDE.

:-)) To mam brat jako osobni invektivu? Myslim, ze vim velmi dobre jaky rozdil mezi SCSI a IDE. Na druhou stranu tyto 'pokrocile' vlastnosti jsou vyvazeny (ci spise prevazeny) penezmi, co za ne date. Ostatne jake pokrocile vlastnosti vam chybi na IDE?

Zkusme to jinak:

Myty o SCSI:

1) SCSI jsou spolehlivejsi
Nesmysl, z HW hlediska: plotny na SCSI disky vyjizdeji z uplne stejne linky nekde v Taiwanu jako plotny na IDE. Z SW hlediska: naopak diky komplikovanosti SCSI jsou s temito disky problemy (viz napr. fakt, ze do nekterych RAIDu proste nenarvete nektere SCSI disky - IDE je stejne uz deset let a jede vsude stejne)

2) SCSI jsou rychlejsi
Pravda, ale pouze castecna. Jsou rychlejsi pouze pro to, ze se ceka, ze finalni cena bude vetsi, tudiz se jeste zvysi napr. 15kRPM misto klasickych IDE 7.5kRPM. Neni to problem architetury IDE vs. SCSI, ale spise obchodniho modelu produktovych rad.

3) SCSI je lepsi
Vec nazoru. Jedine, co je dobre na SCSI jsou RAIDova pole, ktere vsak dneska jdou simulovat dost dobre softwarove. Opet se vsak musime bavit o cene/vykon. Kdybyste stavel dejmetomu 240GB RAID5 pole z SCSI, dostal byste se na nekolika-deseti-nasobnou cenu, nez kdybych to postavil z IDE. Pokud vam to za to stoji, hura do toho. Pro 99% lidi, kteri se zivi sami a nemaji za sebou rozpocet, kdy 0.5MKc neni nic je volba jasna...

PS: myslim si, ze mam s obojim docela velke zkusenosti a tim nemyslim nejaky drobno servrik.

[...]plotny na SCSI disky vyjizdeji z uplne stejne linky nekde v Taiwanu jako plotny na IDE. [...]

a na konci te linky je testovaci zarizeni, ktere tech nejkvalitnejsich 20% pusti dal jako SCSI a zbytek je IDE. 1/2 z toho pak koupi SUN a jemu podobni, nahraji tam vlastni firmware a disk slape jako SCSI 10 let.

Zbylych 80% svetove produkce pak figuruje jako IDE disky, s kterymi jsou problemy podle toho, jake stesti kdo mel.

Jak jsem jiz psal jinde, SCSI nezatezuje procesor!!!

> 2) SCSI jsou rychlejsi
> Pravda, ale pouze castecna. Jsou rychlejsi pouze pro
> to, ze se ceka, ze finalni cena bude vetsi, tudiz se
> jeste zvysi napr. 15kRPM misto klasickych IDE
> 7.5kRPM. Neni to problem architetury IDE vs. SCSI,
> ale spise obchodniho modelu produktovych rad.

Nejde jen o otacky. Az bude IDE (resp [PS]ATA) umet
tagged queuing, tak to bude o necem jinem (pozor,
SATA sice udajne TQ umi, ale praxe je ponekud jina).
Zkuste si nejakou operaci vyzadujici neustale
seekovani po disku na 10kRPM SATA a na ekvivalentnim
10kRPM SCSI disku, rozdil je radovy.

"Kdybyste stavel dejmetomu 240GB RAID5 pole z SCSI, dostal byste se na nekolika-deseti-nasobnou cenu, nez kdybych to postavil z IDE. "

Myslíte ?


"Pokud vam to za to stoji, hura do toho. Pro 99% lidi, kteri se zivi sami a nemaji za sebou rozpocet, kdy 0.5MKc neni nic je volba jasna..."

Nevím kam na ty čísla chodíte.
Mám tu server od IBM, na kterém je RAID pole 360 GB (5+1 x 72) a celé to stálo cca 1/4 MKč. A k té spolehlivosti - když mi jeden disk odejte (což jsem simuloval "vyrváním" za běhu), pak si řadič ke zbývajícím čtyřem přidá šestý, záložní, dopočítá si kontrolní součty a dá pole do pořádku. Totéž ale v opačném směru když ten disk vrátím zpět. Přitom se dá na tom stroji celkem v pohodě pracovat, protože systém běží dál - akorát že se v tu chvíli musí systém podělit o propustnost disků s řadičem, který na pozadí přestavuje pole -> disky šlapou dočasně 2x pomaleji.

Ukažte mi toto na IDE - tak, aby to bylo i technologicky podepřeno a nemohlo nastat selhání z důvodů že se s IDE sběrnicí manipuluje jinak než ukládá norma.

* Delali jsme kdysi (uz je to par let) testy na vykon jestli je vhodnejsi pouzit RAID-5 nebo vice samostatnych disku a rozdelit data mezi ne (zvlast indexy, zvlast log + inteligentni rozdeleni tabulek). Druhy pripad vychazel mnohem rychlejsi. Diksy jsme pro jistotu jeste mirrorovali.

* Zazili jsme jednou havarii SCSI radice s RAID-5 a to takovou, ze data se nedala nijak obnovit. S vice samostanymi disky (treba mirrorovanymi) by se dalo precist alespon neco.

* Nejsem si jisty ale podporuje PostgreSQL online backup? Pokud ne a klekne mi cele pole tak musim rucne doplnit data od posledni zalohy coz muze byt neprijatelne.

ad 1. samozrejme, kdyz si rozdelite data 'na miru', tak to bude vzdycky lepsi, nez RAID. Pokud vim pouziva se to celkem bezne. V kombinaci s RAID pak dosahnete jeste lepsich vysledku - treba pro temp striping a pro data mirroring.

ad 2. zazil jsem zatim jedinou (klep klep) havarii SCSI - odesel radic a bylo po datech - s novym radicem jsme to uz nerozchodili :-)

Nekdo se tu dozadoval praktickych zkusenosti. Takze ve firme jede SUN Blade 2000 -- UltraSparcIII+ na 1Ghz, 1GB RAM, 60GB SCSI disk (320). Pohani ho Solaris 9, bezi na nem 8 instanci Oracle 9i a SUN AS. Prasi se na nej v koute ;-) a nikdo o nem nevi, protoze bezi a bezi a bezi. Za skoro 2 roky behu si pamatuji jen jeden restart a to kvuli reorganizaci serverovny, vymene UPS a dalsi udrzbe zeleza.

Od klientu vim o dalsich SUNech, ale to uz jsou vesmes vetsi servery s 4-8 procesory, 4-8 GB RAM a 3 SCSI disky s kapacitou 36 nebo 72 GB. Jeden takovy starsi exemplar bezi uz 3 roky bez restartu.

Pravdou ale je, ze za toto zelezo zaplatite nechutne penez :-(

Delate si srandu ???

Jako pouzitelne minimum VXA-2 8mm (az 6MB/sec v nativu)

Pokud je to dulezite tak Sony AIT-3 8mm(nebo novou Super AIT)

A nebo velke pasky: podle mne je velmi dobra LTO-2 ultrium od HP a tu bych uprednostnoval.

Dobra je i SuperDLT (ne obyc. DLT ta uz je pomala a ma malou kapacitu)

DAT a DDS je velmi pomala, nespolehliva. dale pokud zalohujete vice databazi na jednu pasku pouzivejte v TARu log (aby se pri najeti na urcity blok pouzila FCE seek a ne READ (3x a vice pomalejsi))
Nebo backup SW (pro linux treba Legato Networker (dost drahy), bude i HP DtatProtctor (dnes je clien a media agent(mechaniky,knihovny ...) pro linux, ale server jen pro Solaric,HP-UX,Windows, server pro linux se chysta a mozna bude koncem tohoto roku), ale diky tomu ze mech. muze byt na linuxu tak data pobezi jen na linux a na windows pobezi jen indexy a chybove hlasky)

PS: pasky nikdy IDE vzdy variantu se SCSI (takze apon pod linux ne VXA-1 IDE)

Opravy:
HP Data Protector

client

pokud to chces mit komplet pod Linux tak muzes uvazovat o Veritas NetBackup (knihovny, agenti pro db, ...)

windows nepotrebujes

U Lagata taktez ne, je kompletne pro linux.
A vzhledem k Varitas Backup Exec (vim je to nizsi trida) neverim backup sw od veritasu.

Jetse existuje BackBone, coz je zase male zalohovadlo pro mensi pocet serveru, zato ma mnoho online modulu i pro linux.

No a pro ty kterejm nestaci tohle jsou paskove knihovny ktere jsou pripojene vyhradne Fiberem a maj zanamovou rychlost 980M/s. Jednim z vyrobcu je Exabit Corp. (ano ta co mela vyrobit BINA-48)
Na tom uz se daj stavet SANy, NSAy nebo jak se to zkracuje, umi to automaticky zalohy z jinejch casti tech datovej oblasti site a tak...
Ale to patri do vyssi cenove tridy :)

Dám zcela opačný případ než je popisován v článku:
DBserver na který se každý den "sehrají" data z rúzných sytémů v podniku a dělají se na něm analýzy (prostě hromada extrémně náročných SQL dotazů). Tady vyjde úplně jiná specifikace:
Oddělit indexy a data na různé disky -> extrémní zrychlení přístupu (viz třeba dokumentace k ORA) každý hodně používaný index by měl mít vlastní disk. Optimalizace prostoru kam si db ukládá mezivýsleky dotazů - tj vnitřní dočasné tabulky -doporučuji další disk pro každého součastně pracujícího uživatele.
Výsledkem by byl server s velkým počtem co nejrychlejších disků (+ vyladit jejich cache).

Zálohování: žádné (stejně se to každou noc nahraje znova). Samozřejmě je třeba si zazálohovat strukturu db a načítací procedury - to se vejde třeba na disketu.

Bez konkrétního zadání postavit "optimální" db server fakt nelze.
Rob

To je klasicky rozdil mezi OLTP a DWH.

Naprostý souhlas!
Autorovy názory jsou vyloženě matoucí informace, které se vyučují tak jedině na školách.

admin s minimalnim IQ si napriklad pri instalaci ORACLE, precte cosi o instalaci za pouziti ofastruktury, podobne to bude u MSSQL, DB2 atd, klasicky admini si prectou tenhle clanek, podiskutujou jestli je lepsi ATA nebo SCSI a nainstalujou na windousy pres setup.exe + click na next libovolnou DB

mizernej clanek!
trocha z praxe MSSQL sever
rozhodne dedikovat server
znackovy vs. neznackovy server : nechci ubirat ksefty dodavatelu znackoveho HW, ale praxe potrvrdila ze neznackovy server ma take sve vyhody, vetsinou kdyz zakoupite znackovy HW tak se doporucuje zaplatit HW maintenance a servis tzn. firma pro vas drzi nahradni dily, kdyz se neco po...(kazi) tak v nejake definovane dobe prijede servisak a vadne dily vam vymeni. Znackove dily jsou vetsinou krute nekompatibilni s beznymi dily ( jine patice, specialni upravy ).
Firemni DB server provozujeme na "neznackovem" HW. kdyz se neco po... da se vse snadno a lacino nahradit tim co sezenete, nehlede na to ze casto se za cenu znackoveho serveru daji nakoupit dily pro dva neznackove servery. Doba obnoveni je zkracena o dobu cekani na servis.

Disky rozhodne SCSI a zrcadla jak na data tak na system. Cim vic RAM tim lepe, cim vic CPU tim lepe.
Mezi OLAP + Datawarehousing a OLTP serverem bych moc rozdilu nevidel, pochopitelne OLAP zrejme bude vyzadovat vic diskspace coz vychazi z podstaty OLAP.

....nejen ze se tu provokativne producirujou reklamy maleho mekkeho, jeste nejaky pako usoudilo ze nejlepsi je titulek ve flashi, no FUUUUUUUJ!!!!!!
jeste ze fsechny flase filtruju, jen to cerny nic nahore vypada divne.....

Začít by snad bylo vhodné definicí případné provozované databáze - objem dat, velikost, složitost a četnost transakcí, požadavky na odezvu, dostupnost a obnovu, backup window, prognóza vývoje, sw, finanční (a personální) prostředky..., teprve potom je možno začít uvažovat o hw! Zjednodušit řešení tohoto složitého úkolu na úvahu na téma IDE vs. SCSI, případně Intel vs. AMD je poněkud směšné...
Miloš

Tento článek se opravdu nepovedl, na tom se snad shodneme všichni. Stejně jako na tom, že je nesmysl dávat nějaká obecná doporučení a šířit zaručené pravdy o stavbě DB serverů.
Příklad: padlo tu několik názorů, že výkon procesorů není tím nejdůležitějším. Používáme na Wintel platformě ( nejmenovaný :-) IS, který používá jako DB jistou verzi Interbase. Ta při běhu na více procesorech má vyšší režie než výkon, takže musela být natvrdo nastavena pro běh na jednom procesoru. Výkon zmíněné databáze, potažmo celého IS bych vám přál vidět.
Ovšem to, že mám tuto zkušenost neznamená, že zde začnu rozdávat rady, jak postavit univerzální DB stroj, že ano... :-)

myslim, ze clanek o tom, co musim vedet, nez zacnu navrhovat DB server, by byl daleko vyznamnejsim pocinem

navrh samotneho HW pak neni kompromis mezi cenou a vykonem jednotlivych komponent (SCSI-IDE), ale cenou, celkovym vykonem, bezpecnosti provozu a financnich ztrat pri vypadku na ruzne dlouhe doby

v praxi to muze znamenat, pokud zcela opustite papirovou formu rizeni a ukladani firemnich informaci, katastroficke nasledky pro setrilky ... nestavime totiz levny server, ale server, ktery zvysuje i efektivitu prace

je tedy treba videt usetrene penize a jejich cast vratit zpet do IS (i kdyz se vratily jinou formou), server pak muze stat 0.5M a jeste vydelavat ( muze, ale nemusi !!!)

nezapomente, do ztrat se da zapocitat i usla obchodni prilezitost diky vypadku IS, a ta muze mnohonasobne prekracovat cenu takoveho HW

pocitejte, pocitejte, v IT se nemusi vyplatit usetrit nejake penize

-----------------------------
500.000Kc/5let =100.000Kc/rok =8000Kc/mesic =360Kc/pracovni den
-----------------------------
rychlejsi odezva o 5s pri 100 operacich na jednoho kazdeho z 10 zamestnancu je cca 1.4h usporeneho casu vsech (nepocitam uziti samotneho IS), a kolik platite od hodiny osobe primerene vzdelane, aby zvladla efektivne pracovat s PC ?
-----------------------------

ovsem, koupil-li bych si levne reseni, tak vsechno 2x, abych jej mohl okamzite nahradit (rozhodne by ale muselo byt trvale testovane, krivky spolehlivosti HW maji tvar "U", nova vec by me totiz mohla velice rychle zklamat dalsim vypadkem)


hezky den
petr

Nic moc clanek. Autor asi taky. Hold i budeme muset v to OPEN SOURCE opravdu fšecko sami vyzkoušet. Kuš, potforo.

Ten článek se vážně nepovedl.

Ad vyhrazený server: DB server se velice často používá v kombinaci s aplikačním serverem. Interaktivní aplikace běžící na databázovém serveru většinou nepředstavují žádnou zvláštní zátěž a hlavně představují jiný druh zátěže než vlastní databáze. Navíc řešení 32bit Intel obvykle používají malé až střední firmy, pro které není ekonomicky průchodné koupit si dva servery.

Ad kompatibilita s OS: Naopak. Linux je v prostředí entry a mainstream serverů velice slušně podporován. Certifikovány jsou běžné distribuce u prakticky všech významějších dodavatelů (HP, IBM, Fujitsu-Siemens, Dell, Sun Fire, atd.).

Ad CPU: Rozhodně neplatí, že by se výkon DB serveru škáloval spolu s rychlostí/počtem CPU. Naopak ve většině instalací se vyplatí nehnat se za nejlepším procesorem, spokojit se se základním modelem (např. Xeon 2.8) a investovat do lepšího diskového subsystému.

Ad Disky pro systém: Neznám žádný běžně dostupný server střední třídy, který by pro systém používal IDE disk a v praxi bych nikdy nic takového nedělal.

Ad disky pro databázi: Spíše než o SCSI-3 bych mluvil o Ultra320 nebo o Fibre-channel. Stejně tak je troufalé konstatovat s tím, že se objem zpracovavaných dat v čASE příliš nemění. To samozřejmě záleží na té které instalaci, ale ve většině případů, např. v typickém IS se objem dat s časem zvyšuje - uživatelé pořizují data, zakládají další a další doklady a tabulky bobtnají.

Ad Databáze a RAID: Tady nesouhlasím prakticky s ničím. Narozdíl od tvrzení autora se v prostředí DB serverů se velice často používá RAID-1 (tvrzení, že by při čtení byl 2x rychlejší a při zápisu 2x pomalejší není pravda ani v jednom směru). Docela běžně se používá také RAID 1+1 kdy na první logickou jednotku se umístí vlastní data a na druhou transakční log a žurnály. Pokud je k dispozici více disků, lze použít i RAID-10. Naopak použití zmiňovaného RAID-0 je hloupost (resp. používají jej jen šílenci bez úcty k uloženým datům). Nechápu ani tvrzení proč by mělo být optimální provozování zrovna tří disků? Zmínka o tom, že RAID-10 se používá tehdy, když "pokud potřebujeme RAID-0 pole o velikosti větší, než je velikost jednoho disku" je zcestná úplně.

Zcela mi v článku chybí informace o řadičích, které hrají v případě DB serverů leckdy klíčkovou roli. Je důležitá jejich architektura (rychlost kanálů), velikost a organizace cache paměti a rychlost onboard procesoru.

Celkem souhlasím, používáme většinou RAID5 pole pro data (na Oracle tablespace USERS) a RAID1 pro indexy (INDEXES) a ROLLBACK segmenty. Pokud jsou disky dost velké, tak druhý RAID1 je dobré řešení i pro data. Dle mých testů transakční logy v běžné aplikaci příliš nezdržují (máme poměr SELECT/(INSERT or UPDATE) operací tak 5/1) ale to závisí od aplikace. Ale v každém případě pokud to s jejich případným použitím pro obnovu po havárii myslíte vážně, TRANSAKČNÍ LOGY PATŘÍ NA FYZICKY JINÝ POČÍTAČ, nejlépe na 3 různé. Pokud Vám vyhoří celý server, tak je Vám houby platné, že máte data a logy na jiném poli. Zbyde Vám akorát stav při posledním backupu.

Jěště připomínka k těm řadičům, opravdu to nepodceňujte, špatný řadič Vám srazí reálný transakční výkon DB serveru klidně na polovinu. Zapomeňte na to, že se dá dobrý řadič koupit za 20 kKč. Minimálně 2 samostatné kanály jsou podmínkou. Nechci tady nikomu rozmlouvat jeho názory ohledně šířky rozhraní, mám vyzkoušeno, že 160 MB/s rozhraní utáhne 3 disky, aniž by došlo k jeho zahlcení. Stejně je nejpomalejší částí řadiče právě ten onboard procesor.

Ehm nevim zda clanek je urcen pro maly databazovy server nebo pro enterprise sferu ? Pokud si stavite maly databazovy server doma pro par uzivatelu snad mate pravdu, ale praxe je trosku jina mel bych vyhrady zejmena k tomuto:

1. Zalohovani na DAT - to je vtip ??? - zalohovani na DAT je znacne zastarale, jednak vysoka nespolehlivost pasek, jednak maly objem, mala rychlost zapisu, cteni atd. Dnes se v zasade pouzivaji 3 technologie - SDLT, LTO a AIT, kdy vykony a objemy dat jsou srovnatelne AIT ma trosku vyssi rychlost obnovy, ale zase nepojme takovy objem dat, jako druhe dve technologie atd. V clanku chybi alespon zakladni info o zalohovacich softwarech (Networker, NetBackup, BackupExec, ArcServe, Tivoli atd atd)

2. RAID & SCSI - vhodnost raidu a ted myslim urovne zabezpeceni ne nasazeni raidu jako takoveho (HW SCSI RAID je nutnost !!) je dana aplikaci. Jsou nejaka obecna doporuceni jako treba ze je vhodne rozdelit databazove soubory, transakcni logy a indexy, ale jaky typ RAIDu to zalezi na aplikaci. Je dobre mit vyhovujici velikost cache, vetsina modernich RAID radicu ma samozrejme baterii, ktera chrani cache proti pripadnemu vypadku. U velkych databazi se zrejme nevyhneme nejakemu SAN reseni (FC HB adaptery v serverech a centralni diskove pole s redundantnimi radici a treba s podporou VRAID). Co se velikosti stripe tyce tak by mel korespondovat s velikosti databazoveho bloku (bud by mel byt stejne velky a nebo 2x,4x vetsi - toto se zejmena hodi pokud pouzivate napriklad na oracle raw device). Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni. Pokud ctete/zapisujete spoustu random malych bloku, tak vam je RPM naprdlajs.

3. Znackovy server
Problem je hlavne ve spolehlivosti a predevsim v zaruce (zkusenosti s HP - pokud mate intel server pri vypadku byste tusim mel mit do 24 h. funkcni nahradu tzn. do 24 by mela byt zavada odstranena - hnidopichum se omlouvam, tohle mozna neni uple presne zneni, nicmene je Vam garantovana doba odstraneni). Pokud pozadujete vyssi zabezpeceni urcite by se hodil nejaky cluster. Uz vidim jak napr. u serveru 24x7 zhebne deska a bezite kupovat novou ;-)) (tohle neni na Vas, ostatni co chteji takovyto server stavjet na kolene si to preberou ;-))

"Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni. Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni."

Tohle není až tak úplně pravda. Naopak rychlost otáčení disku je velmi důležitá pro dosažení nízkého rotačního zpoždění (rotational latency), které je vedle vlastní přístupové doby (seek time) kritickým parametrem dnešních disků a jedním z hlavních důvodů, proč jsou současné SCSI disky rychlejší než jejich pomaleji se otáčící ATA příbuzní.

Pravděpodobně jste měl na mysli interní přenosobou rychlost (internal data rate), díky které mohou i pomaleji se otáčící IDE disky dosáhnout vysoké sekveční přenosové rychlosti, ale která v oblasti databází není tolik důležitá.

Myslel sem RPM, (vystavovani hlavicek pri random cteni/zapisu) nicmene na toto jsem zapomnel

Ve většině bodů s autorem souhlasím. Akorát že "značkové železo" není samospasitelné.

Po delším vybírání jsme pro databázi Progress vybrali server od IBM (Xseries). Má 2x CPU Xeon 2,8 GHz s HT, 2 GB RAM a šest SCSI disků 72 GB připojených na ServerRAID 6i řadič.

První co mě nepříjemně překvapilo bylo to, že ten server přišel jako skládačka. Naivně jsem doufal, že firma IBM bude mít dost času aby to sestavila a oživila. No nevadí. Složili jsme to s kolegou sami.
Ale nastal další, tentokrát mnohem závažnější problém. Nebylo možné zprovoznit RAID řadič. K řadiči jsme sice dostali bootovací CD s linuxem (IMHO klon RH) na kterém je nastavovací utilita, ta ale tvrdila že žádný RAID řadič nevidí. Spojil jsem se tedy s IBM a musím uznat, že byli vstřícní a ochotní a dali nám kontakt na sevisní firmu. Ovšem ani jejich technik si s tím neporadil a nepomohlo ani stažení nejnovější verze nastavovací utility s internetu.

Nakonec pomohlo stažení _úplně_nejnovější_ utility ze stránek IBM, kam ovšem ne mají obyčejní smrtelníci přístup. Ten řadič totiž natolik nový, že se jeho podpora do "normálních" verzí ještě nedostala. Takže po druhém servisním zásahu (mimochodem mezi vánocemi a Novým rokem) už to šlape jak má. Ale nemůžu se zbavit dojmu, že by bylo lepší, aby si maníci z IBM aspoň občas vyzkoušeli, jestli to co dodávjí k sobě pasuje.

Ahoj,delší dobu sháním nějaký starší HW (CPU kolem 100MHz,72pin RAM,disky,...)pro několik chudých neziskových organizací.Nabízím za to možnost pobytu na horách,projížďky na konících,nebo alespoň dobrý pocit že tak pomůžete organizacím nabízející lepší aktivity pro volný čas než jsou drogy a alkohol.Pokud chcete vic informaci nebo mi můžete pomoct,prosím napište mi na na mail nebo ICQ 48104265.

Diky za hezke reakce na clanek. Pokud chcete vice detailni informace tak mne
poslete email o co presne by byl zajem. Mam k dispozici pomerne znacne
mnozstvi ruznych benchmarku delanych pro interni potrebu (disky, raidy,
kazetaky, rozparcelovani databaze, ...) a statistiky selhani hw a zalohovacich
medii.

poznamky k jednotlivym tematum:

1) Disky SCSI, PATA, SATA
Shrnuti: raw transfer rate ma nejvetsi SATA +9%, PATA +0, SCSI -6%. Pri provozu databaze se tento typ zateze nevyskytuje (kdyz nepocitam backup). Pokud date
indexy na SATA disk tak pri 70 uzivatlich delajicich updaty velkych indexu
jde vykon dolu o 230% oproti SCSI. Nektere lepsi disky se ve verzi
IDE ani nedelaji.

2) Systemovy IDE disk

Systemovy disk slouzi na vyhrazenem db serveru pouze k tomu aby to nabootovalo
a spustilo databazi, pak se uz muze vyhodit. Kdyz se podivam na jeho
statistiku tak jedine pristupy zpusobuje cron, syslogy si nechavam posilat jinam. Starsi Linux kernely 2.4 opravdu tuhly pokud zarvalo IDE. Ty posledni jiz
jedou SCSI pri IDE havarii ok.

3) Atomicky zapis sektoru u IDE
nevim jak ve specifikaci, ale bezne pouzivane disky to umeji jiz hodne dlouho.
Testoval jsem to.

4) Co v DB serveru ovlivuje vykon

Pri vice uzivatelich je to rozhodne v prvni rade CPU. Jeste jsem nevidel DB
server ktery by mel load

AD 2) problem je v tom ze intel servery maji vetsinou kompletni scsi architekturu, prolianty od hp dokonce ide vubec nepodporuji a to i kdyz ho pripojite na stejnou ksandu jako cdromka.
AD 4,5) opet zalezi pouze na typu aplikace - co napr. sber nejakych technologickych dat, kdy se do databaze rve spousta udaju a sem tam nekdo pusti nejake batche ktere vygeneruji nejake vystupy.
AD 6) odpovedel ste si v podstate sam - pokud se z databaze hlavne cte pak vykon RAID5 bohate staci.
AD 7) jaky HW raid radice ste testoval ???
AD 8) zalezi na aplikaci jak s indexy nalozi
AD 9) zalohovani na DAT uz sem opravdu dlouho dlouho nevidel. Za to jsem byl jiz nekolikrat svjedkem jak unaveny a zlomeny admin zkousel ruzne DDS a obnova se ne a ne podarit (chyba admina, jednou za cas je dobre udelat kontrolni restore). Rychlost zalohovani a obnovy je take velmi dulezita. Vetsinou je treba se vejit do nejakeho zalohovaciho okna. Co se tyka diskove cache jako uloziste dat pro zalohy - je to vynikajici vjec. Nicmene v internich smernicich firmy je vetsinou klauzule o zalohach, ktere by meli byt ulozeny mimo budovu firmy (z duvodu pozaru atd), aby i tehdy kdy po budovje zbydu dira v zemi mohla firma sva data obnovit a fungovat dal.

> Pri vice uzivatelich je to rozhodne v prvni rade CPU.
> Jeste jsem nevidel DB server ktery by mel load < 1
> a cekal az se data prectou z disku.

Mylite se - pokud tedy oznacujete jako "load" udaj vypisovany prikazem uptime ci top. Toto cislo ukazuje prumerny pocet procesu ve stavu "runnable" (R) ci "uninterruptible sleep" (D). Uninterruptible sleep je obvykle pro ty, co cekaji na disk. Takze kdyz procesy cekaji na disk a zatez procesoru je nulova, budete mit load >= 1. Zkuste si dat
dd if=<scsi disk> of=/dev/null a uvidite. Relevantni udaj je procento zateze procesoru (napr. v topu).

> Takze kdyz procesy cekaji na disk a zatez procesoru je nulova, budete mit
> load >= 1. Zkuste si dat
dd if=<scsi disk> of=/dev/null a uvidite.

zkusil jsem to na Freebsd 5.2 a load mam 0.01 - dle ocekavani. Pokud
to na linuxu vykazuje opravdu load 1, tak to pocita linux zjevne spatne.

Jo, jde o to ze FreeBSD D procesy do zateze vetsinou samo nepocita, linux ano. Ani jedno neni spatne, je to proste jinak.
ALE dosahnout loadu 1 pri dd if=scsidisk of=null znamena, ze mate zatracene rychle scsi a zatracene pomaly pocitac. Asi jako kdybych do sveho PII nacpal SCSI320.
Dosahnout tohohle loadu s ide diskem pochopitelne neni problem pri naprosto libovoulne konfiguraci. Osobne jsem to testoval od 386 po Athlon2200+ a bylo jedno jestli ten disk mel 120MB nebo 120GB, zatez byla 100% po dobu presunu (testoval jsem i 386/120GB a athlon/120MB a leccos mezi tim)

> Nejlepsi volba je 0+1 na vicekanalovem radici.

To ano, ale teď tady píšete něco docela jiného než ve článku, kde jste naopak psal:

> RAID-0 (striping): Velmi vhodný pro provoz databází, optimální je použití tří disků...Proto se nedoporučuje dělat RAID-0 přes více než tři disky, což poskytuje vhodný poměr výkonu ku bezpečnosti.

To jste myslel asi tak, že naděje, že odejde jeden ze dvou disků je při provozu datábaze přijatelnější než naděje že odejde jeden ze tří disků?

Ve skutečnosti je to tak, že se konfigurace odvíjí od počtu disků - máme-li dva tak se použije RAID-1, máme-li čtyři tak RAID 10 nebo RAID 1+1 a rozdělení db lokací do logických jednotek.

Spolehlivost je totiž v drtivé většině případů důležitější než výkon.

Kdyz uz tady mame flame war IDE versus SCSI, je zajimave, ze nikdo nenapadl autorovo tvrzeni o RAIDech:

- RAID-1 se pry prilis nepouziva. Ja myslim ze na DB server je RAID-1 jedina volba (nepocitam ruzne kombinace 1+0 nebo 0+1).

- Autorovo "rozhodne HW RAID" bych zmenil na "rozhodne SW RAID", aspon pokud je OS Linux. DB server nedela presuny velkych bloku dat, takze nevadi, kdyz data pujdou po sbernici vickrat. No a abyste meli HW RAID srovnatelne rychly se SW RAIDem v Linuxu, museli byste mit na RAID radici tolik pameti, kolik ji v beznem provozu Linux pouziva jako cache. A pamet do radicu je typicky drazsi nez RAM pocitace. Z vlastni zkusenosti vim, ze treba RAID-5 na HW RAID radici s 32MB RAM byl asi o 30% pomalejsi nez SW RAID-5 na stejnem radici a stejnych discich - proste proto, ze Linuxovy RAID mel jakoby "vetsi cache". U HW RAIDu s cache je treba myslet na to, co se stane kdyz vypnou proud (tedy co s daty, ktera jsou ve write-back cache a o kterych si OS mysli, ze uz jsou bezpecne na disku). Ma vas HW RAID radic nejakou solid-state pamet? Pokud ne, mate problem.
Navic SW RAID je IMHO flexibilnejsi (muzete na jednom disku kombinovat ruzne RAID-1 a RAID-5 a dalsi nad ruznymi partisnami tehoz disku. Tohle udelate jen na high-end diskovych polich (HP EVA).

- pri zapisu na RAID-5 neni treba nacist cely stripe. Zapis funguje takto: nactu stara data, nactu starou paritu, pomoci "stara data" xor "stara parita " xor "nova data" spoctu novou paritu, a zapisu novou paritu a nova data. Nic me nenuti nacitat cely stripe (ale porad jsou to dve cteni a dva zapisy na jednu zapisovou operaci).

- proc je pro RAID-0 optimalni pouziti tri disku?

Prijde mi, ze cely clanek je o tom "jak si myslim ze bych postavil DB server, aniz vim cokoli o typu zateze, ktera na nem pobezi".

Mam zkusenosti s podobnymi servery a jedine co o ladeni vykonu muzu rict je, ze je to specificke pro konkretni aplikaci. Je treba pocitat s tim, ze typicky 7500RPM disk udela cca 70-130 operaci za sekundu (a je temer jedno - aspon pro databaze - jak velke operace se delaji). Rychlejsi disky delaji umerne vic. No a z tohoto je treba vyjit pri rozhodovani kolik koupit disku a do jakych RAIDu je pospojovat.

-Yenya

>>U HW RAIDu s cache je treba myslet na to, co se >>stane kdyz vypnou proud (tedy co s daty, ktera >>jsou ve write-back cache a o kterych si OS mysli, >>ze uz jsou bezpecne na disku). Ma vas HW RAID >>radic nejakou solid-state pamet? Pokud ne, mate >>problem.

A co UPS a komunikace serveru s UPS ?? Samozrejmosti je mit pripojeny takovyto server na UPS a mit nakonfigurovany nejaky ten automaticky shutdown pri vybiti napr 20 %. Server se korektne shodi. Nehlede na to ze spousta HW radicu ma v sobje baterii, ktera data podrzi po dobu vypadku.

>>Navic SW RAID je IMHO flexibilnejsi (muzete na
jednom disku kombinovat ruzne RAID-1 a RAID-5 a dalsi nad ruznymi partisnami tehoz disku. Tohle udelate jen na high-end diskovych polich (HP EVA).

To neni tak uplne pravda, napr RAID radice od HP to umeji od rady 5 (5i,5xxx atd.) a ty sou ve standartni vybave kazdeho proliantu.

Co se cache tyce i zde bych byl opatrny, napr u Vami zminene HP EVA HP tvrdi, ze velka cache neni potreba, protoze vykonostne radic HSV100 vse ustiha. Je fakt ze defaultni velikost cache u EVY je relativne nizka(256MB) oproti starsim radicum HSG80 (512MB)

> A co UPS a komunikace serveru s UPS ??

UPS prichazeji a odchazeji. Solid-state nebo baterii zalohovana write-back cache je proste nutnost.

> Co se cache tyce i zde bych byl opatrny, napr u Vami zminene HP EVA HP tvrdi, ze velka cache neni potreba, protoze vykonostne radic HSV100 vse ustiha.

Checht. A to ten radic pouziva nejakou magii pro to,
aby pri stejnych discich byl stejne rychly jako radic s dvojnasobkem cache? Pokud nemaji nejakou HW kompresi, tak si nedovedu predstavit, kdy by libovolne dobry radic s polovinou pameti byl stejne rychly jako (napriklad) SW RAID na Linuxu s dvojnasobkem pameti. Samozrejme v pripade, kdy testovaci zatez skutecne celou tu cache vyuzije.

-Yenya

>>
Checht. A to ten radic pouziva nejakou magii pro to,
aby pri stejnych discich byl stejne rychly jako radic s dvojnasobkem cache? Pokud nemaji nejakou HW kompresi, tak si nedovedu predstavit, kdy by libovolne dobry radic s polovinou pameti byl stejne rychly jako (napriklad) SW RAID na Linuxu s dvojnasobkem pameti. Samozrejme v pripade, kdy testovaci zatez skutecne celou tu cache vyuzije.

Ano to mate samozrejme pravdu. Jen sem tim chtel rict ze rychlost HW RAIDu neni vzdy o velikosti cache. Pokud budu mit HSG80 s 512MB cache a HSV100 s 256 pak HSV bude pravdepodobne rychlejsi, protoze architektura obou radicu je uplne odlisna (EVA umi VRAIDY, je plne 2Gbitova, jine disky atd atd.)

Nemám to ověřené, neboť na databázových server SW-RAID nepoužívám, ale domnívám se, že objem cache není zdaleka všechno. Navíc použitím HW raidu přece o výhody systémové cache nepřijdete.

Jako největší nevýhodu SW-RAIDu považuji nutnost posílat stejná data po systémové i SCSI sběrnici vícekrát podle toho, kolik máte mirrorů/disků, čímž se omezuje dostupné pásmo a zvyšuje režie celého přenosu. V případě konfigurací kde se dopočítává parita (RAID5) může zase onboard procesor odlehčit nejen hlavnímu procesoru, ale serveru jako celku. Paritní ani redundatdní informace neopouštějí SCSI subsystém, není potřeba je přenášet po sběrnici, ukládat do paměti, zaneřádit jimi cache, dopočítavat XOR a to samé nazpět. I když to není výpočetně náročná operace, tak to všechno stojí cenný procesorový čas a hlavně I/O cykly, které zejména v případě většího zatížení budou chybět.

HW řadiče mají obvykle daleko lépe ošetřené havarijní stavy nebo hot-swap, bývají propojené se systémy pro management, dokáží operační systém zcela oprostit od problémů s polem, reportovat problémy prostřednictvím různých kanálů, což si všechno v případě SW-RAIDu musíte realizovat pomocí vlastních skriptů individuálně. Představte si, když se staráte o desítky takových serverů...

Poznamka ze neni potreba nacitat pri zapisu cely strip-size u raid-5 mne
velice zaujala. Napsal jsem si tento testovaci soft, mrknete se na to,
vyzkousejte a poslete vysledky.
U meho HW Raidu to ale cely stripe nacita, protoze rychlost zapisu s
rostouci velikosti stripsize primo umerne klesa.

#! /usr/local/bin/python
import time
FILESIZE=500 #in MB
NAME="test.tmp"
SKIPBYTES=65536

try:
f=open(NAME,"r+")
except Exception:
print "creating",FILESIZE,"MB test file"
f=open(NAME,"w")
for i in xrange(1,FILESIZE*1024):
f.write('1'*1024)
f.close()
f=open(NAME,"r+")

STEPS=FILESIZE*1024*1024/SKIPBYTES
print "Write 1 byte every",SKIPBYTES,". Total",STEPS,"writes."
raw_input("Enter to start write-test..")

start=time.time()
for i in xrange(0,FILESIZE*1024*1024,SKIPBYTES):
f.write('3')
f.seek(i)

f.close()
needed=time.time()-start
print "Total time",needed,"seconds.",STEPS/needed,"Writes per second."

Nejak nerozumim, co tim programem chcete testovat. Na otestovani n+1-nasobneho RAID-5 byste potreboval radove n procesu/threadu ktere by cetly nebo n/2 procesu ktere by zapisovaly.

Mimochodem, ja netvrdim, ze by nacteni celeho stripe
bylo nejak nevyhodne - to neni. Jen ze neni nutne
cely stripe nacitat, pokud radic nechce.

-Yenya

Chtel jsem testovat zda kdyz budu zapisovat 1 bajt bez toho aniz bych cetl
predtim cely stripsize a postupne zvetsovat stripsize na hw raidu tak zda to
ovlivni rychlost zapisu ci ne. V mem pripade to s rostouci velikosti stripsize
umerne brzdi, takze to vypada, ze se nacita cely.

jinak ohledne toho mozneho castecneho nacitani mate pravdu. V dokumentaci k
raidu jsem nasel:

When the amount of data being written is less than a full stripe worth, the
`small write' problem occurs. Since a `small write' means only a portion of
the stripe on the components is going to change, the data (and parity) on the
components must be updated slightly differently. First, the `old parity' and
`old data' must be read from the components. Then the new parity is
constructed, using the new data to be written, and the old data and old parity.
Finally, the new data and new parity are written. All this extra data
shuffling results in a serious loss of performance, and is typically 2 to 4
times slower than a full stripe write (or read). To combat this problem in the
real world, it may be useful to ensure that stripe sizes are small enough that
a `large IO' from the system will use exactly one large stripe write.

Dale pisi, ze tohleto neimplementuji.

produkcny databazovy server napr. pre financne a ekonomicke IS, kde sa pracuje s peniazmi v hodnote desiatky-stovky a viac milionov korun denne na platforme intel - tak to by asi neslo. na to sa pouziva serioznejsie zelezo. a na linux tiez zabudnite. autor clanku tiez zabudol na dalsie detaily: zalozne zdroje, perfektne zmenezovana strategia zalohovania atd. ak predsa len odide server, musi byt pripravena nahrada kym dodavatel zabezpeci novy server, alebo opravu. a co i len myslienka na zalohovanie na dvd je usmevna :) ak ide o databazu napr. s telefonnymi cislami, to je o inom. pekny den.