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 .. %(&#@!)%$@3!@(%^& ...
sa druge strane, kada butnes kontroler u server - niko nece sutra da dodje i da te pitas jel imas mesta da tu turi svoj %$@_& 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