Sun Solaris 10 áttekintés

 ( trey | 2005. április 22., péntek - 8:25 )

A ZDNet egy áttekintést készített a Sun Solaris 10 operációs rendszerről. A ZDNet szerint a Sol 10 a jelentősen javult teljesítménynek, rendelkezésre-állásnak és funkció bővülésnek köszönhetően jó választás a Sun felhasználóknak (upgrade) de nem igazán alternatíva a jelenlegi Linux felhasználóknak.A Sun mellett felhozott érvek mellett szerepel a javított teljesítmény és biztonság, az előrelátó öngyógyító képesség (predictive self-healing), az x86 architektúra támogatás, a beépített virtualizáció (containers), a DTrace, és a Linux kompatibilitás.
A kontra érvek közt szerepel a kompatibilitási problémák az x86 platformmal, a Linux kompatibilitási gondok és a korábban beígért, de még mindig késő ígéretes funkciók (pl. ZFS).

A teljes értékelés itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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."

Hát, köhöm... na mindegy.

Jaja, igaz...

"predictive self-healing"

Ez meg vajon mi lehet?

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.

" * 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. "

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... ;)

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.

"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:).

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á.

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. :)

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).

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 :)

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? :)

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)

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 :)))))

Te kötözködsz :)

A NIC failovert hogy valósítják meg ezek ?

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.