A Solaris Cluster ingyen letölthető

Sun Microsystems

A Sun Microsystems ingyenesen letölthetővé tette a tegnapelőtt bejelentett legújabb Solaris Cluster termékét - csak annak kell érte fizetni, aki támogatást szeretne hozzá. A Sun a letöltés mellé elérhetővé tett egy tutorial-t is, amely azt mutatja be, hogy hogyan lehet két node-os cluster-t építeni a termék segítségével.

Hogy mire jó a Solaris Cluster? Azt a következő mókás videó mutatja be:

További infók a Solaris Cluster-rel kapcsolatban a Solaris Cluster Oasis-ban találhatók. Érdemes elolvasni a FAQ-t is.

( turul16 v | 2007. 01. 11., cs – 19:54 )

"Your Sys Admin might be down!!!
But not your Application on Solaris Cluster 3.2"

Üt, rendesen :)
------
gentóhuszár

( Hunger | 2007. 01. 11., cs – 21:23 )

"No hardware was impacted in the making of this video"

LOL

( LGee | 2007. 01. 11., cs – 21:51 )

Csak en latom ugy, vagy a srac tenyleg indiai? ;-)

( LGee | 2007. 01. 12., p – 15:48 )

A legdurvabbat most vettem eszre: amikor a srac lerugja a gepet, az nem egy Sun, hanem egy Dell Optiplex (GX260 vagy hasonlo) (leallitva meg jobban latszik)! LOLMAO

( Som-Som | 2007. 01. 12., p – 16:55 )

Jo sok vackot kellett vegigolvasnom, mire valami kiderult szamomra.

Szoval mi ez a Solaris Cluster:
- Megbizhato fajlrendszer.
- Kozos IP-cim oszto (terheles elosztasra es hibakezelesre).
- API alkalmazasok nagyobb rendelkezesreallasuva tetelere (eroforras eleres, monitorozas).
- Kiegeszito megoldasok elterjedt progik megbizhatobba tetelere, mivel azok nem hasznaljak a fenti API-t (pl. Oracle, MySQL, Apache).
- Vicces doksik, amik peldaul at ajanljak, hogy eleve megbizhato, maguk utan mindig integrans adatot hagyo progikat irjanak ra.

Ez mind szep meg jo, sok esetben tenyleg kivalo. Peldaul a HUP-ot ragyogoan kiszolgalhatna sok nagysagrenddel nagyobb forgalomnal is egy ilyen cluster. De ha egy alkalmazas sok allapoton atmeno folyamatot kezel sok dinamikus adattal, es mindezt piszok gyorsan kell megtennie, akkor bizony RAM-ban kell tarolnia az adatait. Ez kulonoskeppen akkor vicces, ha egy progibol nem is egy verzio fut, mert mondjuk eppen frissitik, mikozben fut, tehat a RAM tartalma elvileg nem viheto at egy masik peldanyba. Na, ilyen alkalmazasok bizony leteznek, es itt a Sun szepen el is felejtheti a clusteret.

A Sun Cluster alapvetoen HA Cluster es arra tok jo. Igaz van agent pl Oracle RAC-hoz is bar az meg ujabban egyre kevesbe igenyli maga ala az olyan framework-oket, mint amilyen a Sun Cluster.

HA cluster meg ugye arra jo, hogy a viszonylag megbizhatatlan (mondjuk csak 2-3 kilencest garantalo) elemekbol magasabb rendelkezesre allasu (4-5 kilences) rendszert rakjunk ossze ugy, hogy teljesen vedve legyunk egy tetszoleges rendszerelem meghibasodasa ellen es az SLA-ba beferjen ennek a rendszerelemnek a potlasa a masodik hasonlo rendszerelem meghibasodasa elott:)

Egyebkent ha megnezed mondjuk a Sun Application Server Enterprise Edition-t, annak a J2EE Servlet Session Store-ja illetve a Stateful Enterprise JavaBean-ek sessionstore-jara egy HADB nevu komponens van rendszeresitve. Ez a HADB akvizicioval kerult a Sun-hoz, egy Clustra nevu norveg ceg felvasarlasaval, akik a ClustraDB nevu (ez ugye a HADB) elsosorban telekommunikacios cegeknek szant specialis (elsosorban szamlazasi informaciok 100%-os megbizhatosagu tarolasara szant) adatbazist fejlesztettek korabban. No ez a HADB tud olyat, hogy akkor jon vissza egy tranzakcio sikerrel, ha az adott SQL statement eredmenye legalabb 2 node-on bent van memoriaban. Persze nem 2 node van, hanem akarmennyi, mondjuk 64 db (mindegyik 16GB memoriaval akkor az ugye max 1/2 TB-os netto adatmennyiseg), es az elosztott adattarolas miatt, nomeg a full redundancia miatt egyreszt piszok megbizhato, masreszt piszok gyors tud lenni (latenciat nem szamitva, de amint elosztotta teszel valamit az ugyis bejon az egyenletbe). A szakik allitasa szerint van olyan HADB instance ami kvazi a ceg alapitasa ota folyamatosan fut, atelt jopar irodakoltoztetest, meg hardvervaltast szolgaltatasleallas nelkul...

Koszi a szinvonalas hozzaszolast! En alapvetoen nem olyan alkalmazasokra gondoltam, ahol nagy hattertarra (adatbazisra, fajlokra) van szukseg, hanem ahol folyamatosan sok bejovo adatbol kell okoskodni, ezert a hattertar hasznalata nem lehetseges.

Mobil telefoniaban pl. egy HLR vagy VLR adattarolasa boven alapulhat hattertarra, hiszen ott bejon egy telefonszam vagy roaming szam, azt egyszer ki kell keresni es beolvasni par hozza kapcsolodo adatot, azt viszlat. Az adatbazis ugyan HA, de ha elroppen valami, "csupan" ujra kell kezdeni a muveletet (esetleg irasi tranzakciot visszavonni). A szamlazas mikentjet (szabvanyait) ugyan nem ismerem, de gondolom ennel is egyszerubb, mert csak uj rekordot (CDR) kell hozzaadni az adatbazishoz a hivas vegen (ha elofizeteses a hivo). Nyilvan masodpercenkent sok irast megbizhatoan vegrehajtani nem konnyu.

Azonban amikor tobb ezer olyan folyamatod van, ami tobb szaz kisebb nagyobb adatot hasznal sok percen at folyamatosan, akkor eselyed sincs lemezt olvasgatni. Ennel sem veszes megoldani, hogy HA legyen, szoftvert lehessen frissiteni es sok evig elfusson. De alapvetoen fajl es adatbazis alapu megoldas itt nem jatszik. Tehat mindenre nem jo a Solaris Cluster.

jaja, de ezen a szinten neked fault tolerant hw-re van szukseged (magyarul nem a fent emlitett 2-3 kilencest nyujto dzsunkan osszerakott hw-bol epitkezel, hanem mernokileg fault tolerant-ra epitett hardvert+szoftvert hasznalsz. ami 2-3 nagysagrenddel dragabb mulatsag. vagy lefejleszted es korbeepited szoftverrel a dolgot ha megis dzsunka hardverparti vagy (mint a google) - ennek a koltseget en osszevethetonek erzem azert az ft hardverevel:).