Názory k článku High Availability a Linux (3)
-
Článek je starý, nové názory již nelze přidávat.
-
Izak (neregistrovaný)
FireWire ??? tak to jsem teda u diskovich poli jeste nevydel.
Delam s HW diskovimi poli pres SCSI (vice kanalove) a FC (tzv SAN struktura, tech delam vetsinu).
Jinak standartne v linuxu neni mozne zdilet jednu partition(slici) vice linuxy i kdyz nastavite san masking na oba linuxove stroje, ten 1. si ji nejak oznaci a druhy si ji neprimontuje ani pro cteni (i kdyz ji vidi ... COZ JE DOBRE jinak ztrata dat) .. ovsem ani kdyz ji ten 1. nema primountovanou tak se nani ten druhy nedostane.
Mozna by mohlo pomoct odregistrovat SCSI zarizeni ze systemu (scsiadd -r) a na druhem ji pridat.
Pokdu OpenGFS umozni na SCSI (FB) zpristupnit jedno zarizeni dvema pocitacum (naco jako veritas volume manger) pak bude vse fungovat.
Jinak k tem SCSI pokud pomineme odlisnou konfiguraci pole, existence multilun atd. tak se FC pro system chova jako OBYCEJNE SCSI nic min nic vic ... jen lze nastavit HA (tzv. Fail-over, coz je min 2x radic v poli, lze ovsem jit az tak daleko ze zprovoznite i dualni cesty .. 2x san switch, dualni karta atd.) coz se ale nastavuje na poli a jen to musi podporovat DRIVER (doporucuji karty qlogic 2200 2300) -
Michal Krause (neregistrovaný)
S eth1394 jsme experimentovali (a máme teď přes něj k serveru připojený druhý zálohovací), ale bohužel to nemá oproti Fast Ethernetu v podstatě žádnou výhodu - rychlost je pouze o nějakých 10 až 20 % vyšší, což je vzhledem k teoretické propustnosti FireWire velkým zklamáním. Nicméně problém je zřejmě na straně linuxových ovladačů, protože jsem viděl nějaké benchmarky dělané na MacOS X, a výsledky bylo o poznání lepší.
-
Michal Kara (neregistrovaný)
Bohuzel serial zacal vychazet v trosku nevhodnou dobu, takze pisu poznamku k prvnimu dilu az sem :-)
Ne ze bych mel neco proti clusterum, ale trochu me v prvnim dile chybela podkapitola "kdy clustery nepouzivat" ;-) Je sice pekne ze nasadite high-availability cluster, ale pokud jsou naklady na jeho zrizeni a udrzbu (na dalsi HW plus vase prace) vyssi, nez ztraty zpusobene vypadky stareho systemu, tak jste odvedli spatnou praci a meli byste prijit o sve letadlo :-)
A v mnoha dalsich pripadech je spis efektivnejsi investovat ty penize do nakupu OPRAVDU dobreho HW (napriklad dat tam SCSI disky misto IDE). -
Danny (neregistrovaný)
No, nevim... ale standalone SCSI disk je stejne "spolehlivy" jako standalone IDE. Rozdil IDE/SCSI bejva casto jen elektronika. Ze jsou SCSI disky spolehlivejsi je mytus, prakticky to nema zadnej zaklad a opodstatneni, elektronika se muze odpalit u vsech stejne a SCSI i IDE se toci a pohybuji se tam hlavicky...
Vyssi vykon SCSI nepopiram, nicmene na 99% aplikaci postacuje s velkou rezervou vykon dnesnich IDE disku.
Ano, kvalitni HW, ale kdyz uz tak nejaky RAID, pokud mi staci RAID1 a radic ma podporu OS, tak nevidim duvod, proc nepouzit IDE. -
PSIkappa (neregistrovaný)
A co tak S.M.A.R.T. na IDE diskoch ?
Neviem sice co presne ten "predictive failure" u SCSI diskov robi, ale pokial len povie, ze ten disk odchadza do vecnych lovist pomaly a iste, tak potom v tom nevidim ziadny rozdiel od SMART-u s tym rozdielom, ze mozno cez SMART sa da ziskat viac udajov o disku. -
dejf (neregistrovaný)
Ne tak docela, ono SCSI si umelo rict, ze se cosi jebe driv nez se to stalo uz na starickych Macach, nevim esi to byla naka dodatecna diagnostika, ci to bylo primo v rozhrani, ale naka podpora byt musela (1988), SMART nastoupil do bezne praxe o 10 let pozdeji, takze je to mimino s detskymi nemocemi a je to znat.
-
Michal Kara (neregistrovaný)
Ja bych spis rekl, ze mytus je, ze IDE je stejne spolehlive jako SCSI ;-) Nemyslim disky, myslim obecne technologii.
Nejde ani tak o mechaniku, jako spis o to kolem. Jenom toho casu, co jsem stravil tim, ze jsem zkoumal proc IDE radic, nevidi IDE disk... A ted tady mam pocitac, na kterem uz nekolik mesicu resim problem s tim, ze zhruba jednou za tyden mu vytuhne komunikace po IDE (coz znamena takrka ihned zatuhnuti systemu). Zkousel jsem vymenovat kdeco (vcetne 300W zdroje), nakonec jsem vymenil cely pocitac, tak uvidime.
Ale ani ten novy pocitac neni bez problemu - dal jsem tam (omylem) UDMA33 kabel a ono to jelo UDMA66. Nikde zadna chyba, akorat zapisy na disk se obcas zmrsily. A pak at si to clovek ladi. Kdyz spocita veskery ztraceny cas, dojde k tomu, ze SCSI je nakonec levnejsi nez to IDE. -
Honza Houstek (neregistrovaný)
Krome toho, ze musim souhlasit napr. s Michalem Karou ohledne toho, ze cela IDE technologie je jeden velky omyl a se SCSI se proste srovnat neda, tak bych rad upozornil i na to jak je to s temi disky po mechanicke strance.
Pripoustim, ze co se mechanicke casti tyka, tak jsou SCSI a IDE disky temer identicke, dokonce se casto montujou na jedne lince. Jenze treba kdyz se delaji plotny, tak prochazeji kontrolou, jestli jsou vsude spravne tlusty. No a ty co projdou nejlip jdou do SCSI disku, kdyz se naplni poptavka SCSI, tak dalsi jdou do lepsich IDE, a hovno pada dal ... S ostatnimi castmi procesu je to podobne.
Kdyz jsem nedavno videl IDE disk (tusim od IBM), ktery nesmi bezet 24/7 a ma ve firmware dokonce zadratovano, ze se po N hodinach behu (N -
bbbb (neregistrovaný)
Danny pise: "No, nevim... ale standalone SCSI disk je stejne "spolehlivy" jako standalone IDE. (...) Ze jsou SCSI disky spolehlivejsi je mytus, prakticky to nema zadnej zaklad a opodstatneni,..."
Ma to dobry zaklad a opodstatneni uz z vyroby. Nevim, kdo "prisel" na to, ze jsou stejne spolehlive. Proc myslite, ze prodavane SCSI disky maji typicky polovicni ci ctvrtinovou kapacitu nejvetsich IDE disku? Protoze nove velkokapacitni disky nejsou jeste tak vychytane, aby mely dostatecnou spolehlivost pro SCSI. -
Michal Kara (neregistrovaný)
Dovolil bych si jenom upozornit na moji lety proverenou zkusenost: "Idealni pocet vlastnich patchu v kernelu provozniho systemu je NULA!". Pouzivejte jadro bud primo z kernel.org, nebo alespon nejakou hodne pozivanou vetev (kernely distribuci jsou vetsinou OK).
Tedy pokud nemate radi adrenalin :-) Pokud ano, budete se naopak vyzivat v situacich, kdy potrebujete upgradovat kernel (v lepsi pripade kvuli driveru, v horsim kvuli bezpecnostni chybe v jadre, na kterou uz koluje BFU exploit) a vas "oblibeny" patch do nej nejde aplikovat. -
Stanislav Brabec (neregistrovaný)
Sdílení disku přes SCSI jsem zkoušel. Jak už zde bylo napsané, je problém, že počítače si navzájem nesdělují, co právě mají v bufferu. Takže je to řešení pro systémy read only.
Zřejmě by to šlo řešit na úrovní jádra, pokud by tam pro diskovou cache byly podobné struktury, jako má SMP na stránkové cache.
Navíc to nelze považovat za HA řešení. Co když odejde něco na SCSI sběrnici a ta zůstane neprůchodná? -
Veros Kaplan (neregistrovaný)
Že jsem tak smělý, z čeho pramení Vaše tvrzení, že neumím dát dohromady Linuxový HA Cluster? Pokud budete někdy v Brně, ozvěte se soukromě a ukážu Vám ho naživo včetně vypnutí a zapnutí jednotlivých strojů.
Ten článek byl psán s úmzslem, abyste se to z něho mohl naučit i vy... :-)
Ad 4 pokračování: taky z toho nejsem nadšený :-(, ale to je prostě webový časopis ... -
antonio (neregistrovaný)
velmi vhodny nastroj na testovanie takychto veci je
vmware. uz aj vmware workstation ti podporuje
zdielany scsi disk.
urobis si kolko xces interkonektovych sietoviek, zdielanych diskov, atd bez toho aby ta
to cokolvek stalo.
ja som takto rozchodil oracle rac 9i na
raw devicoch z dvoch vmwarovskych masin.
