[ farmaceut @ 26.02.2013. 20:24 ] @
Za MySQL, sta je generalno bolje, iz Vaseg iskustva:

1.) Dedicated server sa 8 diskova za bazu (Directly Attached Storage)
ili
2.) Dedicated server sa (raid 1 za sistem) + da admin "odvoji" 8 diskova sa SAN-a (poseban FC kanal) za bazu. Na SAN-u bi se vrtilo jos stosta (neki Vmware i sl), ali bi odvojili tih 8 diskova samo za mysql.

Diskovi bi bili isti u oba slucaja, 146GB SAS 15k, kao i ostatak masine (32GB, 4core).
Oprema je HP, ne znam detalje, dobio sam upit od admina.
Znam da je mozda tesko reci bez detalja hardvera, ali sta bi generalno bila preporuka Directly Attached Storage ili SAN?

Pozdrav!
[ nkrgovic @ 26.02.2013. 21:33 ] @
Cisto na slepo, all things equal, ja bi stavio diskove direktno u server. Ne vidim sta se dobija SAN-om. Dobar RAID kontroler se, nadam se, podrazumeva - on ce odraditi mnogo vise nego kontroler na storage-u koji nije dedicated za bazu.

Generalno, meni MySQL + SAN nema mnogo smisla. To nije shared storage baza.

Dodatno, ako imas 8x15krpm SAS, aman stavi vise RAM-a. 96GB ili 128GB (ne znam da li ti CPU koristi memorije x3 ili x4) stvarno nije skupo, kad platis 8 SAS diskova, a moci ces da stavis 60-70GB innodb buffer pool, sto znaci.

P.S. Kad budes postavljao diskove, obavezno xfs. :) Google-aj malo kako se podesava xfs za innodb, nije tesko - glavno je da ti se poklope fs block size i innodb block size.
[ bogdan.kecman @ 26.02.2013. 23:45 ] @
zavisi od mnogo faktora

- ako ti je kontroler na serveru krs, onda je bolje da koristis SAN. na primer brdo raid kontrolera nisu hw stand alone vec koriste softwersku podrsku, to je lose resenje, drugo, ako nemas battery backed up kesh na raid kontroleru to je kao da ga nemas (posto ces morati da ugasis kes i da upalis write barrier kako bi izmene koje snimis bile na disku) etc etc ... bolje koristis san
- ako na SAN-u ne mozes da odvojis zasebne spindlove samo za sebe, dakle ako moras da delis spindlove sa nekim .. ne valja da koristis san

to su 2 osnovna faktora .. e sad, npr SAN moze da bude u boljem kucistu, da se diskovi bolje hlade, da se lakse menjaju, da ima brzi kes, da ima hw snapshot & backup resenje etc etc .. to mnogo znaci, sa druge strane dobar SAN kosta mnogo vise nego dobar kontroler za server, firme onda imaju obicaj da taj san koristi za svasta jos nesto i cak ako ga i dobijes "samo za sebe" za 2 meseca ce ti uvaliti ko zna sta jos tamo ... da ne spominjem da ce da ima network steker pa ce neko hteti i kao nas da ga koristi pa .. i .. i onda .. %(&#@!)%[email protected][email protected](%^& ...

sa druge strane, kada butnes kontroler u server - niko nece sutra da dodje i da te pitas jel imas mesta da tu turi svoj %[email protected]_& tako da ja uvek, kada neko pita, savetujem "directly attached"

Ono sto je zastrasujuce bitno a na sta ljudi ne obracaju paznju kako treba kada je storage u pitanju je kesh

zamisli stavis 4G kesa na disk (sto je sitno u poredjenju sa tim koliko ima na nekim kontrolerima), ima baza da leti .. sta je problem, ti uradis comit, on ga snimi u kes, resetuje se masina puf, tvoje date nema nigde! to je vrlo nezgodna stvar i zato moderni filesystem-i imaju tzv write barrier tako da kada ti uradis fsync on ne zavrsi dok fizicki ne snimi datu na disk (dakle kesh ne pomaze). Tako da ti sad dal imo 1G ili 100G kesa, nit je znacajno brze nit ista, samo si puko velike pare ... na sve to, ceo taj trip oko write barrier nije bas uradjen kako treba posto u mulithreaded upisu pitanje je sta jedan fsync treba da snimi - da li samo ono sto je taj tred slao na disk ili sve sto je baferisano za upis.. zamisli da ti imas 2k slog koji oces da fsyncnes a u pozadini neki user kopira bekap od 100G sa diska na disk, ti sada da bi syncno tih 2k moras da cekas par giga kesa da ode na disk .. razlike kako koji os/fs napadaju taj problem su velike, za sada sam ja primetio dosta problema sa ext4 mada mi je neki bug u kernelu za xfs napravio jos vecu stetu ... na windozi nemam pojma ni kako se podesava write barrier ni kako to ntfs koristi .. sve u svemu uopste nije malo bitna stvar. .. e sad, ako ti imas battery backed up kes, onda te bas briga, turis 4, 6, 100G kesa na kontroler, ugasis write barrier pa fsync syncne datu u kes a ne na disk - pri resetu, nestanku struje, bilo kakvom problemu - sadrzaj kesa na kontroleru se cuva baterijom, kada dodje struja prva stvar koju masina uradi je snimi taj kesh na diskove, pa tek onda krene da se butuje..

dakle
1. ako imas kesh koji nema bateriju - moras da teras write barrier enabled fs, kod SAN-a to moze da bude dodatno problematicno (posto nemas full kontrolu kao na lokalnom)
2. ako koristis san, obavezno odaberi koij su tvoji spindlovi, spoj ih u jedan lun i to zakaci samo na sebe. nista deljenje spindlova
3. ako koristis san, nikako ne dozvoli da se tvoj lun vidi na vise od jednog interface-a
[ farmaceut @ 27.02.2013. 18:32 ] @
Hvala svima na odgovorima.

Trenutno vec imamo kod klijenta setup sa serverom kojem je dodjeljeno 4 diska sa SAN-a (neki IBM, fiber, dodjeljena 4 sas 146G 15k, ne znam sve detalje), ali je baza relativno mala i kompletna staje u ram, zajedno sa indeksima, tako da super sljaka....

Pitanje je za neki drugi projekat, sa potencijalno vecom bazom, pa malo polemisem sa sistemasima u firmi....

Sa xfs nemam iskustva, ali cu pogledati kad stignem citao sam bas ovde na forumu i djeluje interesantno....za sada se drzim ext3
poz.