- A hozzászóláshoz be kell jelentkezni
- 2123 megtekintés
Hozzászólások
Nekem ez a slashdotos hozzaszolas tetszett legjobban:
"It is intended to be a (cheaper, better) alternative to Red Hat Enterprise Linux, not "Linux" in general."
- A hozzászóláshoz be kell jelentkezni
Hát, köhöm... na mindegy.
- A hozzászóláshoz be kell jelentkezni
Jaja, igaz...
- A hozzászóláshoz be kell jelentkezni
"predictive self-healing"
Ez meg vajon mi lehet?
- A hozzászóláshoz be kell jelentkezni
2 resze van, az egyik az SMF (/etc/rc.d helyett svcadm, svcs, svccfg parancsok), aminek egyik mellekhatasa, hogy nem lehet kikillelni szolgaltatast, meg automatikusan ujraindul a process, ha core dump-olt volna valamiert (effektive alkalmazas szintu watch dog funkcionalitas kernelben megvalositva: lasd man ctrun).
A masik a Solaris Fault Manager, ami effektive csak sparc-on erheto el, ami figyeli a rendszer HW-t, es ha hibat eszlel, akkor beavatkozik, szolgaltatast allit le, ujraindit, stb... Egy CPU meghibasodas pl Solaris 9-en panic-ot okoz, 10-en meg jo esetben csak egy sort a syslogban, miszerint CPU hiba, ki lett konfiguralva, a rendszer mukodik tovabb. Amelyik programban a hiba (pl egy ECC altal korrigalhatatlan bithiba) elofordult, az valoszinuleg core dump-ol ugyis (arra ott az SMF, hogy ujrainditsa), de a kernel nem panikol el.
- A hozzászóláshoz be kell jelentkezni
" * Predictive Self Healing - Az új előrelátó javítási (Predictive Self Healing) technológia használatával a gép képes automatikusan diagnosztizálni, izolálni és helyreállítani számos hardver- és alkalmazási hibát a leállások idejének jelentős csökkentése érdekében. "
- A hozzászóláshoz be kell jelentkezni
mondjuk én nem feltétlenül szeretném, hogy egy elcrashelt szolgáltatást nekem folyamatosan újraindítgasson a rendszer, mert így egy bugos programot folyamatosan DoSolva az egész rendszert lelehet terhelni, vagy rosszabb esetben, pont ez kell egy támadónak ahoz, hogy brute force megoldással eltalálja a megfelelő return address-t ahoz, hogy jó helyre injektáljon be kódot és átvegye a gép felett az irányítást.
Hardver hiba esetén meg nem szeretném ha futna tovább a szolgáltatás, mert mondjuk nem lenne jó, ha a memória meghibásodása miatt 2 milliárd helyett 8 milliárd menne el valamelyik ügyfél fele... ;)
- A hozzászóláshoz be kell jelentkezni
Azért az SMF ennél összetettebb és az általad említett problémákat kezeli is, jóval több, mint egyszerű restarter. Try it.
- A hozzászóláshoz be kell jelentkezni
"Hardver hiba esetén meg nem szeretném ha futna tovább a szolgáltatás,"
Ne PC-ben gondolkodj. Gondolj egy 64 CPU-s SMP rendszerre amin fut 8-10 szolgaltatas kulon zonakban, resource management-tel es jol korulhatarolt biztonsagi megkotesekkel. Ekkor beut egy hiba, ami csak az egyik CPU-t, es azon is mondjuk az sshd-t erinti a memoriaban. Ekkor self healing nelkuli esetben leallna az egesz rendszer (egy E10k boot-olasa tobb oras folyamat) kernel panikkal. Solaris 10-zel a rendszer felismeri, hogy a hiba milyen jellegu, miket erint, es mit kell tennie, ha el akarja haritani. Ha nem tudja elharitani, akkor persze jon a kernel panik itt is... De ez joval kevesebb scenario eseten fordul elo, mint a korabbi Solaris verziok eseten (pl 1 CPU-s gep eseten fatal CPU hiba:).
- A hozzászóláshoz be kell jelentkezni
Try it.
Az lesz, csak még nem volt eddig rá idő. Ha forráskód is elérhető lesz, akkor valószínűleg építeni is fogunk rá.
- A hozzászóláshoz be kell jelentkezni
Nem csak PC-ben gondolkodom, de a memória hiba példát te dobtad fel, az pedig elég bonyolult kérdéskör és sokféle problémát vet fel. Nyilván egy mainframe más kategória, de annál meg elvártam volna már korábbi Solarisokkal is, hogy egy CPU problémát túléljenek. :P Nyilván mission-critical rendszereknél ez a megoldás fontos, de ezeken futtatott szoftverektől is elvárhatja az ember, hogy csak úgy ne crasheljenek. :)
- A hozzászóláshoz be kell jelentkezni
Nem mainframe-ekről beszélünk. Ha egy memóriamodul elhalt, alapvetően ott sok más tennivaló nincs, mint a szolgáltatást újraindítani, miután az OS kikonfigurálta a hibás modult. Ez nagyon sokat dobhat pl. az internetes szolgáltatások rendelkezésre állásán, bár mint Joel is írta, egyelőre főleg Sparcon érhetők el ezek a szolgáltatások (azért nyomokban x86 -on is: pl. processzorok tartalékba rakhatók, kikapcsolhatók, bekapcsolhatók, interruptoktól felszabadíthatók menet közben x86 -on is).
- A hozzászóláshoz be kell jelentkezni
hunger wrote:
> Solarisokkal is, hogy egy CPU problémát túléljenek. :P Nyilván
> mission-critical rendszereknél ez a megoldás fontos, de ezeken futtatott
> szoftverektől is elvárhatja az ember, hogy csak úgy ne crasheljenek. :)
A mission critical rendszereknél ezért megy parallel legalább két node,
fizikailag eltérő helyen.
De azt hiszem azok a rendszerek még jóideig nem lesznek nyílt forrásúak :)
- A hozzászóláshoz be kell jelentkezni
Mico wrote:
> Nem mainframe-ekről beszélünk. Ha egy memóriamodul elhalt, alapvetően ott
> sok más tennivaló nincs, mint a szolgáltatást újraindítani, miután az OS
> kikonfigurálta a hibás modult. Ez nagyon sokat dobhat pl. az internetes
Ha a PC szerverben megdöglik egy memóriamodul, nincs más teendő, mint
kihúzni a rackből, kiszedni a hibás modult, berakni a jót.
Mindeközben a szolgáltatás szépen fut.
Nem? :)
- A hozzászóláshoz be kell jelentkezni
Haha :)
Nos, elméletileg adott hardveren van rá lehetőség, hogy működjön, ahogy ez el van képzelve. A baj csak az, hogy nagy az esélye, hogy ha a memória modul elhal, az nem csak userspace programokat fog érinteni. Processzort egyébként próbáltam már kapcsolgatni vele, vagyis kellett, és nem volt semmi fennakadás, pedig volt load rendesen.
(Ez Xeon volt - nem tudom mi történt volna pl Opteronnal, mármint a hozzá kapcsolódó memória bankokkal, ha lekapcsolom a CPU -t)
- A hozzászóláshoz be kell jelentkezni
Mico wrote:
> Nos, elméletileg adott hardveren van rá lehetőség, hogy működjön, ahogy ez
> el van képzelve. A baj csak az, hogy nagy az esélye, hogy ha a memória
> modul elhal, az nem csak userspace programokat fog érinteni. Processzort
> egyébként próbáltam már kapcsolgatni vele, vagyis kellett, és nem volt
> semmi fennakadás, pedig volt load rendesen.
Olyan PC-kre gondolok, mint az IBM xSeries egyes tagjai, vagy a régebbi
Netfinityk. Memóriatükrözés, modul hot swap, stb. Ezekben gyakorlatilag
mindent duplikálni lehetett.
Két NIC, két proci, dupla annyi RAM, OS oldalról teljesen
transzparensen, csak a felét láttad, viszont az első csákányütést még jó
esetben kibírta :)
Vagyis kellett azt jelenti, hogy lekapcsoltad, kicserélted,
visszaraktad, bekapcsoltad? Vagy csak valami gebasz volt és
leállítottad, hogy ne okozzon problémát és a maintanence windowban
offline kicserélted?
> (Ez Xeon volt - nem tudom mi történt volna pl Opteronnal, mármint a hozzá
> kapcsolódó memória bankokkal, ha lekapcsolom a CPU -t)
Pedig teljesen egyértelmű: OS mielőtt lekapcsolta volna a procit
átpakolja a másik bankba a stuffot, vagy kilapozza, ezután leállítja a
CPU-t.
Nem is értem, hogy lehet ilyen kérdést feltenni :)))))
- A hozzászóláshoz be kell jelentkezni
Te kötözködsz :)
A NIC failovert hogy valósítják meg ezek ?
- A hozzászóláshoz be kell jelentkezni
Szokás szerint. :)
A Solaris sem jó mindenre.
Az ilyen hardveres interfész failover emlékeim szerint sima linkfigyeléssel, esetleg belső ellenőrzéssel ment, de pontos infot nem tudok fejből, csak arra emlékszem, hogy volt ilyen.
- A hozzászóláshoz be kell jelentkezni