"Megérkezett az Oracle és a Sun első közös gyereke"

Oracle

"A múlt heti WSJ-hirdetés alapozta meg az Oracle és a Sun tegnapi bejelentését, amelyen Larry Ellison mellett John Fowler, a Sun szerverekért felelős vezetője vett részt. A két cég által bemutatott újdonság egy olyan integrált rendszer, amely Sun hardvereken és Oracle szoftvereken alapul. Az adattárházakra és tranzakciókezelésre tervezett megoldásban a kiszivárgott pletykákkal ellentétben nem UltraSPARC T2+, hanem Intel Xeon processzorok dolgoznak, az adatok villámgyors elérését pedig SSD biztosítja. A szoftverréteg az Oracle-ről származik, a flash memória kezelésre optimalizált 11g R2 adatbázis alatt nem Sun Solaris, hanem Oracle Enterprise Linux dolgozik." A részletek itt olvashatók.

( trey | 2009. 09. 16., sze – 11:24 )

A Linux-nál felnevettem.

--
trey @ gépház

Konkrétumok esetleg?

Illetve akkor is ott vannak a kérdések, hogy ha már Sun:
- miért x86?
- miért Linux?

Ráadásul az Oracle DB elsődleges platformja a Solaris, mint tudjuk...

Tehát mindössze azért lett Sun, mert:
a) ha már úgyis megvesszük, használjunk is valamit belőle (ja, bocs, akkor még ez szóba sem került)
b) ők olyat tudtak adni, amit más nem (te látsz ilyet a bejelentésben?)

suckIT szopás minden nap! Ott lesz vajon Lőrinc?

"- miért x86?"

Az első verziót a HP vasakkal csinálta meg. Az architektúra meghagyásával egyszerűbb a vendor váltás.

"- miért Linux?"
Az első verzión linux futott. A vasat egyszerűbb és gyorsabb kicserélni, főleg ha azonos architektúrájú egy másik vendorra, mint a komplett szoftver stacket összeidomítani egy másik oprendszerrel.

Gyanítom, hogy már most dolgoznak a zfs és az oracle összegyúrásán. (zOracle?) :)

És szerinted -ha azelőtt kész volt, hogy a Sun-akvizíció egyáltalán érdemben szóba került volna- mi volt a váltás oka, illetve miért lett a v1 x86 és Linux (vagy csak Linux, ha az akkori SPARC-ok totális versenyképtelenségét nézzük)?

Nem is tudom, az Oracle-ben elég sok intelligencia van, ami pont nem arrafelé mutat, hogy mögé tegyenek még egy sokkal bonyolultabb fájlrendszert.

suckIT szopás minden nap! Ott lesz vajon Lőrinc?

"Konkrétumok esetleg?"

Kb. egy éve jelentették be az exadata első verzióját, ami azt jelenti, hogy kb 2006-2007 között kezdhették el fejleszteni.
Most csak vasat cseréltek alatta.
Elég konkrét?

"mi volt a váltás oka?"

Franc tudja, de valószínű nem csak viccből intettek be a HP-nek....
Aztán lehet, hogy titokban megegyeztek a HP-vel, hogy nem pánikoltatják a Sun hw piacát az akvizícióig, aztán majd átpasszolják a HP-nek.

"miért lett a v1 x86 és Linux"
Gondolom kisebb installációkat akartak vele megcélozni, az meg jellemzően x86 és linux. A nagy oracle userek (pénzügy, telco) hagyományosan kissé konzervatívabbak az ilyesmivel.
Gyanítom a v1 kísérleti termék volt, hogy életképes -e a koncepció, azt meg kevésbé kockázatos x86 linux alapon összerakni.

"Nem is tudom, az Oracle-ben elég sok intelligencia van, ami pont nem arrafelé mutat, hogy mögé tegyenek még egy sokkal bonyolultabb fájlrendszert."

Konkrétumok? :) De, ne az ASM-et please :)

Csak gondolkodtam, de a zfs-ben van pár olyan feature, amit az oracle nem nagyon tud. ráadásul a flash technológia kihasználására per pillanat a zfs l2arc megoldása nagyon jó.
Esetleg ki lehetne vele váltani pl. az ASM-et. De ez tényleg csak feltételezés. mittomén, képzelgés az egész, de nem feltétlen hülyeség.

"Franc tudja, de valószínű nem csak viccből intettek be a HP-nek....
Aztán lehet, hogy titokban megegyeztek a HP-vel, hogy nem pánikoltatják a Sun hw piacát az akvizícióig, aztán majd átpasszolják a HP-nek."
Na ne már. Simán csak gyártókapacitást vettek, és örülnek, hogy míg a HP-nál könyörögni kell a testreszabásért, ezzel a masinával azt csinálnak, amit akarnak.

"Gondolom kisebb installációkat akartak vele megcélozni, az meg jellemzően x86 és linux. A nagy oracle userek (pénzügy, telco) hagyományosan kissé konzervatívabbak az ilyesmivel.
Gyanítom a v1 kísérleti termék volt, hogy életképes -e a koncepció, azt meg kevésbé kockázatos x86 linux alapon összerakni."
lol. Kisebb installációkat akartak nyilván megcélozni az 1 millió dolláros listaárú v1-gyel. Nyilvánvaló.
Az se számít, hogy pont a telco-knak, meg bankoknak ajánlgatták ezerrel. Épp ez volt az irány anno: cseréld le a drága nagy unix vasadat a mi általunk integrált és testreszabott x86+linux-ra, és megtízszerezzük az adattárházad teljesítményét.
(Az más kérdés, hogy semmi csodalogika nem volt az egészben, simán csak őrült durva IO sávszéllel vertek mindenkit.)

"Konkrétumok? :) De, ne az ASM-et please :) "
Szállj már le a földre plíz, szétröhögöm magam az ASM fikázáson. Nem mondom, hogy az ASM a legnagyobb királyság a WC papír feltalálása óta, de elég sokat foglalkoztam adatbázis IO hangolással manapság (konkrétan az elmúlt évet gyakorlatilag azzal töltöttem), és nem nagyon találtam még olyan volume manager + fs kombinációt, ami a közelébe tudott volna érni. Lehet, hogy feature téren még nem annyira fejlett, bár azért érdemes körülnézni most a 11gR2 háza táján, van pár érdekesség...

"Kisebb installációkat akartak nyilván megcélozni az 1 millió dolláros listaárú v1-gyel. Nyilvánvaló."

Elfelejtetted megnézni, hogy a "full rack hardware" mellett állt az 1 millás összeg. Ok, elismerem ezt a részt benéztem, mert nem jártam utána túl nagy mélységben.

"Szállj már le a földre plíz, szétröhögöm magam az ASM fikázáson. "

Ha ilyen tájékozott vagy az ASM fikázásom terén, akkor kérlek keresd meg az egyik első hozzászólásomat egy másik topicban, ahol azzal kezdtem, hogy teljesítményben az FS gyengébb mint az ASM/raw device, viszont menedzselhetőségben/skálázhatóságban jobb.

"sokat foglalkoztam adatbázis IO hangolással manapság"

És? Az IO hangolásnak semmi köze ahoz, hogy mennyire skálázható, dinamikus, és amúgy mennyire üzemeltethető a rendszer.

Az elmúlt kb. 10 évet gyakorlatilag nagy Oracle rendszerek alatti unixok üzemeltetésével töltöttem, nem tudnám megszámolni hány instance volt összesen a szervereimen, de 100 nál jóval több. Érdekes mód ASM egyiken se volt, és a pár tucat dba kolléga közül egyik sem nagyon rajongott érte. Nyilván ez nem olyan, mintha én dolgozam volna ASM-el, de azért tapasztalat.

RAC-hoz és Grid hez az alkalmazásokat is jól kell megírni.
Új alkalmazás esetén járható út. Meglévő esetén álltalában nem.

Láttam már elbaszott RAC-os alkalmazást. Siralmas volt. (Gyak. kisebb volt a teljesítmény, és a redundancia, mintha nem RAC lett volna.)

Egyébként a grid és rac jó dolog lenne, de a legtöbb esetben emberi hülyeség (inkompetens fejlesztők) miatt bukik az egész.

Jó, pont ezért kérdezem, nem lehet, hogy azért nincs sehol ASM-ed, mert inkompetens (vagy csak lusta, ezer éves, papucsos, 16:20-kor pontban lelépős matuzsálem) DBA-itok vannak, akik a járt utat a járatlanért soha el nem hagynák?

suckIT szopás minden nap! Ott lesz vajon Lőrinc?

Hát, szerintem az hogy RAC, vagy nem RAC álltalában nem a dba-n múlik.
Álltalában egy adott megoldás szállítója ( tervezők, és fejlesztők) határozzák meg, hogy RAC-e.
A dba csak megkap valamit üzemeltetésre, de általában nincs sok beleszólása, hogy mit.
Aztán javítson ki valaki, ha nem így van.

szerk.: igen, lehet, hogy az ellenérzések nagy része az ismeretlentől való félelem miatt volt, de azt tényleg nem tudom, melyik dba-nak milyen rac-os tapasztalata volt korábban.

A megoldás szállítója olyan megoldást hoz, ami az én sztenderd, elfogadott környezetemben működik. Az architektúra adott, aztán tessék rá megoldást szállítani. Azért mert a magyarországi szoftver megoldás szállítói piac kínálati oldalának 90%-a hígf*s, azért még egy egészséges szervezetben ez így működik.
A DBA-nak van a legtöbb beleszólása, hogy mit kap üzemeltetésre. Miután van kötött szabályrendszer, aminek minden szoftvernek meg kell felelni, ha az átadott megoldás nem viszi át a lécet, akkor lehet jövő héten újra próbálkozni, ez ilyen egyszerű. Elég hamar megtanulnak jó kódot szállítani, vagy eltűnnek.

Nem, nem felejtettem el megnézni, hogy a full rack hardware mellett van az árcédula, Te felejtkeztél el arról, hogy itt már a v1-ről beszéltünk, ami nem létezett, csak egy kiépítésben: full rack, 14 gép, 14 storage gép.
Később kijöttek egy 7-7-es verzióval, amolyan starting edition címen, és azt 600k köré árazták.

Az, amit az ASM menedzselhetőségéről vélsz, egyre távolabb van az igazságtól, mert elég rohamosan fejlődik, de igaz, valóban nehézkesebben menedzselhető, mint egy 20 éve létező LVM megoldás, amit már bőven volt idő körülbástyázni mindenféle csoda utility-vel. Ellenben a skálázhatósági felvetésedet egyáltalán nem értem, éppen az a tapasztalat, hogy a skálázhatósági gondok sokat egyszerűsödnek ASM környezetben...

Skálázhatóságról és dinamizmusról ennyit. És egy terhelt, IO függő adatbázis rendszer alatt szerintem magasról tesz az ember a menedzselhetőség esetleges kellemetlenségeire, ha azzal nyer kb 20% IO sávszélt.

A munkatapasztalatainkat nem akarom most összeméregetni, de hasonló számokat látnál nálam is. És én is szembetalálkoztam a DBA-inknál az ASM-től való ódzkodás jelenségével, meg azzal is, mikor leesett az álluk minden előzetes kétkedésük ellenére, ahogy meglátták az ASM utáni első hét terhelési görbéjét összevetve az ASM előtti hetivel. Azóta ugyan nem mondhatom, hogy "nagyon szeretik" az ASM-et, de nem azért, mert nem változott a véleményük róla, hanem épp azért, mert szeretnének minél többet megtanulni róla mihamarabb, mert egyelőre nem mozognak ugyanolyan biztonsággal benne, mint fs-en. És ettől még lelkes híveivé váltak, mert az a két óra, amivel kevesebb idő alatt megy le a bedolgozás egy nap, az ő szabadidejüket növeli.

Mint írtam, személyes tapasztalatom nincs az ASM-el, ezért csak mások állításaira + néhány fellelhető összehasonlításra korlátozódok.

A 20% növekedés az ugye nem csak és kizárólag az ASM-re váltás eredménye, hanem volt mögötte némi oracle tuning is. Úgy önmagában szvsz. kicsit durva lenne...

Csak örülni tudok, ha az ASM szépen fejlődik. Van szórakoztatóbb dolog is a világon, mint diszkekkel dominózni ora instance-ok alatt.

Lehet, hogy kicsit durva, de volt rendszer, ahol igaz.

1 vacak paraméternyi Oracle tuning nélkül fájlrendszeren konstans 550-580 megabyte/másodperc-et tudó instance ASM átállás után konstans 730-750 megabájt/másodpercet hozott, és a 150-230 közötti load average lement 50 körülre.
Ha nem látom, én sem hiszem el. És hozzátenném, a fájlrendszer elvileg elég komolyan szét volt hangolva, hogy megfelelően működjön.

Hmm... ez az IO kapacitás random IO oltp jellegű üzemben van, vagy valami szekvenciális jellegű batch?
Jobban szeretem ha iops is mellette van a sávszél adatoknak, bár szekvenciális esetén is szép teljesítmény.
Elmondható, hogy milyen környezet? (oprendszer,vas, storage)

Egy ilyen ASM átálláskor egyébként meglévő területet lehet konvertálni, vagy új diszkterületre kell migrálni?

Batch jellegű, nagy párhuzamosságú feldolgozás. De azért szerintem így is szép. Az iops olyan 300 000 körüli volt ez esetben, ha jól emlékszem.
Később felbővítettem a rendszert még két 4 GBites FC HBA-val, az eredmény valami ilyesmi: 

Wed Sep  2 16:18:47 2009         1389084.80         1026.65
Wed Sep  2 16:18:57 2009         1368656.00          210.45
Wed Sep  2 16:19:07 2009         1430064.00          796.05
Wed Sep  2 16:19:17 2009         1450044.80          374.00
Wed Sep  2 16:19:27 2009         1410422.40          748.50
Wed Sep  2 16:19:37 2009         1387478.40         1273.90
Wed Sep  2 16:19:47 2009         1338577.60       133614.70

Dátum/idő, read kbyte/s, write kbyte/s formátumban.
Igen, egy DVD 3.2 másodperc. :)

Infókat így nem adnám ki, de márkás PC vas, erős diszkalrendszerrel mögötte.
Átálláskor a meglévő terület konvertálása úgy néz ki (már ha két storage tornyod van), hogy lebontod a tükröt, egyik lábát feláldozod, csinálsz belőle ASM-et, RMAN-ból párhuzamos szálakon betolod az adatokat ASM alá, átállítod az adatbázist ASM-re, elindítod, látod, hogy megy, örülsz, lebontod a kiinduló diszket, és felépítesz egy új tükröt az asm diszkek alá.
Persze ha csak egy tornyod van, és csak a tornyon belüli redundanciával, akkor cumi, olyankor kell a plusz hely.

Jó kis vas.

"Átálláskor a meglévő terület konvertálása úgy néz ki"

Ok, értem. Ezt a tükörrel trükközős mókát mindenhol el lehet sütni. :)
Így egyes esetekben még az is hozzájárulhat a teljesítmény növekedéshez, hogy ezzel a megoldással az egész alatt a diszkeket is reorganizálod. Vagyis meg lehet szüntetni a korábbi hot-spotokat, amiket file rendszer tuninggal nem.

Kivancsi lennek melyik hozz tobbet a konyhara, a Solaris vagy Unbreakable.
Gyanitom hogy az utobbi jobban teljesit, es gyorsabban novekszik kerslet ra, leven olcsobb mint RHEL, ill. kvazi ugyan azt adjak, allitolag supportja is tobbet iger.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Sunrider | 2009. 09. 16., sze – 12:02 )

Zsír. De ha OLTP Machine a neve, akkor nem DSS Machine a neve, vagyis ezt azért mégiscsak OLTP rendszerek alá szánják...

( cheeky v | 2009. 09. 16., sze – 12:13 )

Nesze neked, SPARC platform. Látszik, hogy kb. ennyi a véleménye az Oracle-nek a Sun hardver részlegéről.
Köszönik szépen az x86 platform gyártó kapacitást, a többi meg mehet a kukába.

Azért az Oracle Enterprise Linux tényleg jelent valamit. Inkább azt, mint a Solaris x86-ot... Akik eddig hittek a marketingbullshitben, hogy a SPARC meg a Solaris stratégiai eleme a felvásárlásnak, remélem lassan azért kezdenek felébredni.

A tegnap kiszivárgott SPARC útiterv, meg ezen bejelentés fényében különösen mulatságosnak tartom a múlt heti WSJ-s hirdetésben üzengetést. LOL.

Szerintem a logikusabb válasz inkább az, hogy lesz és van ilyen termék is, meg olyan termék is. Az, hogy ez a termék most x86 és Linux alapú annak megvannak a historikus (lsd. előző verzió) és gondolom az üzleti okai is. Ettől még nem temetném sem a Solaris-t, sem pedig a SPARC-ot. Ha pld. éppen egy SPARC-os bejelentés lesz, az nem fogja automatikusan azt jelenteni, hogy a Sun v. Oracle dobja az x86-ot. Egy x86 gyártósor (ami meg amúgy bérgyártás...) ért volna az Oracle-nek 5.6mrd-ot? Még mindig több mint 5x a Sun árbevétele SPARC alapú gépekből, mint x86-ból. Az tény, hogy a második jobban növekszik, de ez a piaci tendenciáknak megfelelő. Illetve egy olyan piacon, ahol eddig a Sun nem volt jelen, dinamikusabb a növekedési lehetőség.

( polner | 2009. 09. 16., sze – 15:30 )

http://www.oracle.com/technology/products/bi/db/exadata/exadata-faq.htm…

Will there be new versions of the HP Oracle Exadata Storage Server or HP Oracle Database Machine based on the G6 version from HP?
No, there will no new hardware based on the newer HP server versions. However, the software on the existing systems can be upgraded to Oracle Database 11g release 2 and the new version of the Exadata Storage Server Software. There are many new features in these two pieces of software that make this upgrade valuable to do.

Will Oracle continue to accept orders for the HP Oracle Database Machine?
We have some refurbished systems available for sale for those customers that would prefer to add additional HP hardware to their current configuration.

( triv | 2009. 09. 16., sze – 15:34 )

Hehe. Hat funny, hogy Sun hazra csereltek a HPt(mint fentebb irtak), s maris kozos gyerek. :-/
Mondjuk abbol a szempontbol elorelepes az Oracle-nek, hogy ebben mar mindent o gyart.

Amugy egy solaris+sparc+oracle -re valtas linux+x86+oracle-rol nyilvan sokkal nehezebb, de sztm biztos folynak a meresek es az otletelesek arrol is, es ha megeri, akkor kihozzak. De ezt hamar meg tudtak lepni, igy ez lett (sztm).

( xobor | 2009. 09. 16., sze – 19:23 )

Sokan akarták, hogy az Oracle szarjon Sunt. Hát szart.

( miamano | 2009. 09. 17., cs – 12:26 )

Az Oracle szerint a plattform specifikus db kód 1% sincs. Kiváncsi lennék, hogy lesz-e x86 Solarisra 11g? r1 nem volt...

( suckit | 2009. 09. 17., cs – 18:24 )

Én a HP helyében megdobnám némi alamizsnával a pgsql fejlesztőket, aztán csinálnék valami hasonlót HP vasakkal, tizedáron.

suckIT szopás minden nap! Ott lesz vajon Lőrinc?