Gépigény ? Oracle, 2TB, 500 tabla,200usr

Adatbázis: SQL, XML DB

Kb milyen gépre tennétek:

Méret kb 2 TB, 500 tábla, max. 100 millio sor/tábla
Felhasználók (egyszerre) 200, OLTP
Oracle 10/11/.. melyiket ?
Op rendszer: Linux,Solaris, vagy egyéb ?
Proci ?, mem GB ?
HW/SW raid ? melyik kártya/diszk ?
(... éles üzembe kellene, de sok rossz tapasztalatom van a HW raid kártyákkal)
nem kell a legolcsóbb, inkább a megbízható.

koszonet

  • 3768 megtekintés

( zwei | 2009. 07. 21., k – 12:07 )

Új projekt, vagy már fut a cucc másik vason?
Ha fut, akkor stresszteszt, és mérés.
Ha új, akkor stresszteszt és mérés.

Így látatlanban:

Oprendszer: RendHat Enterprise, v. Solaris.
Oracle verzió: amit a fejlesztők ajánlanak.
Szerver: 1 v. 2 quadcore Xeon. (Szem előtt tartva az Oracle licenszet - cpu core alapon megy.)
Memória: 16-32G
Storage:
Felejtsd el a SW raid-et, ez már az a kategória, ahol érdemes megfontolni akár az FC storage-okat is. Pl. Emc Clariion Cx4-120, vagy Sun StorageTek 6140, vagy más gyártó hasonló kategóriás terméke.

200 konkurens user, na ne már, vagy az alkalmazást - ami az oracle -t szolongatja - fogja 200 konkurens user használni? azért az nem mindegy.
Más különben meg mindenképpen az oracle-t kérdezd.
Link: http://www.google.hu/search?q=oracle+10g+documentation&ie=utf-8&oe=utf-…
Link: http://www.google.hu/search?q=oracle+10g+hardware+sizing&ie=utf-8&oe=ut…
Link: http://www.google.hu/search?hl=hu&client=firefox-a&rls=com.ubuntu:en-US…
Link: http://www.google.hu/search?q=oracle+10g+hardware+sizing&ie=utf-8&oe=ut…

----
概略情報

Teljesen mindegy, hogy 1 nevesített ORA usert használó alkalmazás szolgál ki 200 usert, vagy minden userhez egyedi ora user van.

Méretezéskor a tényleges terhelés számít. Az Oracle-t is teljesen felesleges kérdezni, mert sokkal pontosabbat ennyi alapján ők sem tudnak. Vannak méretezésre eszközeik, de nekik az eladás fontos - ergo nem feltétlen optimális megoldást fognak mondani.
Van konrét példám is erre: nagy ügyfél megkérte az Oracle-t, hogy egy adott alkalmazásra javasoljanak egy Oracle verziót. Eladtak nekik egy fullos Enterprise szervert, holott mint utóbb kiderült, az alkalmazás SELECT-en és INSERT-en kívül mást sem használt, akár mysql-be is lehetett volna rakni.

Vannak alapelvek, viszont korrekt méretezést csak az alkalmazás kimérésével lehet csinálni.

Pl: interaktív alkalmazás esetén 3 teszt: 10 user kattingat mint állat (alkalmazást tesztel), majd ugyanez 20, 40 (esetleg több) userrel.
Mindegyik teszt alatt folyamatosan mérni a teljesítmény jellemzőket.

Ha alkalmazással tudod szimulálni a userek tevékenységét, akkor az is jó.
Ha riportok és batchek is lesznek, akkor azokat is futtatni kell.
Az a fontos, hogy olyan legyen a teszt, ami a valós felhasználáshoz minnél közelebb van.

A lényeg, hogy több teszt alapján fel tudd rajzolni az alkalmazás viselkedési görbéit a főbb paraméterekre. (cpu, io.)
Ez alapján már többé-kevésbé tudsz interpolálni az elvárt max. felhasználószám adta terhelésre. (Figyelembe véve az esetleg előre tervezett növekedést is, illetve min. 20% biztonsági ráhagyást.)

Lehet használni teszteléskor az oracle advisort (vagy hogy a fenébe hívják.) az alapján a szükséges memóriát elég jól be lehet lőni.

Minden más megoldás (ajánlások olvasása, fórumon tanácskérés, stb.) csak többé-kevésbé pontos becslés, amivel - főleg ha szarul van tervezve az adatbázis- akár elég rendesen mellé lehet fogni.

Ha nincs lehetőség tesztre, akkor vegyél olyan vasat, amibe legaláb 2 db quad cpu belefér, és min. 64 GB ram. Indulásnak elég egy cpu (kategóriában a leggyorsabb), meg 16Gb ram. Aztán, ha menet közben kevés valamelyik, akkor bővíted. (A lényeg, hogy CPU-ból ne legyen a kelleténél több, mert az Oracle-licensz téren elég nagy bukta.). Ha gondolod CPU-ból vehetsz dual-t is, allokálva némi pénzt, ha quad-ra kellene cserélni.

( andrej_ v | 2009. 07. 21., k – 12:11 )

Konkrétan Oracle-höz nem tudok tippet, de ez így elég durván hangzik. Attól is igencsak függ, hogy mennyire durvák pl. a lekérdezések és hogy rendszeres riportokat akarnak-e ebből. A riport generáláshoz, ha kellően megtekerik a vasat és pl. nincs mód éjjel futtatni az üres időben akkor egy külön gépet kéne beállítani. Egyáltalán mi a büdzsé?

riportok,batch,stb este,
Egyenlore csak tajekozdom, hogy kb mik a lehetosegek, merre lehet az optimum,stb. mik a bevált módszerek, stb
(eddig csak fejlesztésre használt db-im voltak 1 TBig.
de oda a linux,akarmi raid,8Gb mem,dual core is eleg volt)
Esetleg meglevo configok is erdekelnenek (vélemény,ár,..)

Kb 5-10M Ft között saccolnám a vas igényt.
Vas választás előtt mindenféleképpen érdemes kimérni, hogy növekvő terhelés esetén hogyan változik az IO, cpu ,stb terhelés.

Szintén nem utolsó szempont a kliensek felé az elfogadható válaszidő, batch esetén meg a futási idő. Ha időablakba kell beleférni, akkor mindenképpen tesztelni kell

A megadott adatok alapján nem lehet komolyan méretezni, mert teljesen mindegy. hogy hány millió sor/tábla, a lényeg, hogy mennyi adatot "mozgatsz" egy időben.

Egy pár 10K-s rekord/tábla esetén is lehet brutál teljesítmény igény, ha van benne pár elb*szott PL Sql vagy tárolt eljárás.

Szerver esetén amit jól érdemes belőni, az a cpu mag szám. Feleslegesen ne legyen benne sok mag, mert az Oracle licensz cpu mag alapú, és az lesz az egyik legdrágább eleme a dolognak.

Vannak olyan cégek (pl. Sun), ahol lehetőség van try and buy -ra, vagyis 1-2 hónap ingyen tesztelési lehetőség mielőtt kifizeted a vasat.
Ha nem vagy biztos benne, elég -e a teljesítmény, akkor érdemes pl. ilyennel élni, mert ha nem vagy elégedett azzal amit kaptál,akkor akár vissza is adhatod, vagy kérsz egy kisebbet/nagyobbat.

szerk: Nincs tapasztalatom Oracle+x64 Solaris használhatósága terén, de pl. Oracle licenszelésen lehet spórolni, ha Solaris alatt csak annyi cpu magot allokálsz az adatbázisnak, amennyi kell neki. (Sparc-on már csináltam többször is ilyet.) Bizonyos feltételek esetén az Oracle cég elfogadja ezt a megoldást. (Konkrétan, ha az adatbázis egy dedikált cpu seten futó zónába kerül.)

( zshor | 2009. 07. 21., k – 12:26 )

Mi tavaly teszteltünk hasonló célra több gépet (talán 4).
Az eredmény az lett, hogy gép majdnem mindegy. A háttértárrendszert kell jól kiválasztani, és az ahhoz javasolt gépet kell venni.
Az előbb javasolt Clariont és Sunt kellene nézegetni szerintem is.

Ja, és jó tudni pontosan, az oracle processzor alapú licenszelését, hogy ne érjen váratlanul a költségszámítás, ha a pénz is fontos.

Nálunk teszteltek gépek 4 dual core-os processzort tartalmaztak és memória 32GB körül volt. De nálunk elég sok batch feladat is van a gépen esténként a nappali OLTP működés mellett.

Öhmm.. a link amit küldtél szerintem.... nem igazán használható.

Magánvélemény:
Ha akarsz gyári oprendszer supportot:
1. solaris

Ha oprendszerhez nem kell gyári support, akkor:
1. amelyikhez van szakértelem.

Ha mindkettőhöz van, vagy egyikhez sincs szakértelem akkor:
1. amelyik logója szerinted szebb
2. amelyik weboldala szerinted szebb.
3. fej vagy írás

Azért, arra elég, hogy meghatározd a szerver fő paramétereit. CPU magok száma, memória.
Op.rendszer kérdésben, az döntsön, mihez van megfelelő szaktudás, vagy támogatás.
Ezután szerintem érdemes figyelembe venni a rendelkezésre állás igényét. Ha HA kell, akkor cluster és közös diszk (FC vagy iSCSI) esetleg megfejelve RAC-al. (Innen indul a költségvetési kaszaszorzó a természetes számok tartományán). Ha nincs ilyen szerintem belső RAID-es diszken kényelmesen elfér.

Üdv

fonyo

Stay hungry, stay foolish.

( Arbiter | 2009. 07. 21., k – 16:21 )

Szia!

Ha érdekel az IBM vas, akkor x86-os szerverből valamelyik felsőkategóriás rack alapú (x3755, x3850 M2, x3950 M2), vagy egy BladeCenter E/H keret 2 darab HS22-es Blade-del indulásnak.

Elég komoly adatbázisnak tűnik, gondolom a rendelkezésre állás is fontos, ezért lehet jó választás egy BladeCenter, vagy két összekapcsolat x3950 M2-es.

Egyetértek az előttem szólókkal, hogy egy komoly storage-ot tegyél alá, 4GB-es FC csatolóval. SATA vinyókat is pakolhatsz bele, ha a diszkeken akarsz spórolni. IBM-éknél a DS 3400, illettve a DS4700 Express lehet a te barátod. Viszont az előbbihez veszett drága a Solaris Host Kit, jó lesz neked a Red Hat is. Láttam már SLES 10-en elfutni Oracle RAC-ot, soha, semmi baj nem volt vele, de persze izlés, igény, vallás, pénztárca kérdése, hogy mit választasz.

Azert ilyen meretekben nagyon fontos a maximalis supportaltsag. Ugyanakkor en oprendszert nem izles/vallas alapjan valasztanek, es nem is koltseg alapjan (ez az a szint, ahol a penz a legkevesebb). Mindkettovel meg kell nezni, milyen teljesitmenyek adodnak, es a jobbat kell valasztani. Nyilvan, ha csak 1-2 kilobajt kulonbsegek vannak, nem erdekes, de ha mar meretesebb a differencia, akkor a jobbikat kell valasztani. FC mellett szobajohet valamilyen iSCSI alapu storage is - termeszetesen nem ganyolt, hanem ipari. Ez esetben talan az FC cuccokat meg lehet uszni, igaz, helyette legalabb 10G-s halozatot kell epiteni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mind a Solaris, mind a RHE teljes mértékben certifikált és supportált minden normális vason, illetve oracle álltal. Innentől kezdve szerintem egyrészt hit, másrészt szaktudás (ki mihez ért) esetleg benchmark kérdése.

szerk. RHE-t nem tudom, de a Sun magyarországi supportja az egyik legprofibb.

Igen, akartam is írni, hogy ebben a kategóriában, már sokat nyom a latba a gyártó által adott support, karbantartási és garanciális szolgáltatások.

De az általam említett példa is jól mutatja, hogy mennyire nem mindegy, hogy milyen OS-en fut a cucc. A DS3400-on, ami a belépő szintű FC storage, a Solaris Host Kit az USÁ-ban listaáron 5200 dollár, míg Linux esetében csak Power host esetén kell fizetni. Ki van ez találva...:P

Ok, de nézhetjük arról az oldalárol is a dolgot, hogy pl. EMC, vagy Sun storage esetén tök mindegy milyen oprendszer van a storage mellett, a fizetős feature-ök mindegyikhez ugyanannyiba fájnak.

Nem tudom mi ez a Solaris host kit , gyanítom valami szoftver feature, amire lehet, hogy nincs is szükség. ((SDD-t tudtommal ingyen adja az IBM, HBA driver szintén nem külön pénz, más nagyon nem kell egy ilyen cucchoz.)

Persze, nem akartam az ebet a karóhoz kötni, csak elmondtam, amit én tudok.
Ez a Host Kit gyakorlatilag egy licensz. A Sunnál is van ilyen, amikor pl sok partícióra akarod felosztani a storage-ot.
Az egyel nagyobb storage-nál már ingyé van.
Magyarul, Solarist ne akarj használni low end terméken. Érdekes megoldás.

Jah, köszi, így már értem. A Sun ezt storage domain-eknek hívja, az IBM-es terminológiával nem voltam tisztában. :)
(EMC clariion-nél egyébként ezt host groupnak hívja, és egy Acces Logix nevű addonnal lehet elérni - a licenszelése nem tudom pontosan hogy megy, ha jól tudom fizetős, de minden oprendszerhez ugyanannyi.)

Egy gép esetén nincs rá szükség, kettő esetén még menedzselhető host oldalon a hiánya (de észnél kell lenni.)

Gyanítom az IBM azért árrazza drágábbra a Sun-os verziót, mert konkurens cég.

Erre már gondoltam én is, bár nem tudom melyik lenne alkalmas oracle OLTP alá.
Mindenképp olyan, amibe SSD-t is lehet rakni. (7210 től felfele?)
A SATA szvsz. oracle alá azért tud kevés lenni. (láttam már sata raid tömböt EMC-ben is, érezhető rendesen a különbség az FC hez képest)
Továbbá nem tudom, oltp alatt mennyire jól skálázható az Nfs és az iSCSI. Ha jól tudom FC targetként még nem működnek.

Ettől függetlenül elég jó lett ez az Unified storage, lehet, hogy egy ilyet itt is érdemes fontolóra venni.

Mivel kb 10 éve ismerem őket, mint ügyfél, illetve jó néhányukat személyesen is, ezért tudom azt mondani, hogy értenek hozzá. pont.
Igaz, az utóbbi 2 évben elég sok régebbi jó ember ment el tőlük, és ritkábban is találkozok velük, lehet, hogy ez kicsit változott.

A milyen lehet a többire csak annyit tudok mondani:
egy másik cég alkatrészenként cserélt ki egy nem kicsi vasat szinte teljesen, és amikor még fél év múlva is folyton lerohadt, akkor meg lettek kérve, hogy vigyék az egészet a fenébe, és hozzanak egy zsír újat.
Ugyanez a gyártó egy elég nagy dobozt, amit eladás előtt demózni akart kb 1 hét alatt tudott csak félig-meddig működőképessé tenni, úgy, hogy az utolsó két napon a helyi "mérnök" online telefonon beszélgetett a német kollégával, aki írányította, hogy mit hogyan hova.

Nyilván ez szubjektív, és lehet, hogy másoknál pont fordítva van, de nekem akkor is a Sunos supporttal voltak a legjobb tapasztalataim. Egyébként nyilván mindenütt vannak jó supportosok és és kevésbé jók egyaránt - ki melyikkel találkozik, olyan véleménye lesz róluk.

RedHat magyar supportról nincs semmi tapasztalatom, amikor utoljára RHE-t használtam még nem volt ilyen.

Blade centert ez alá nem tennék.
Blade center csak akkor költséghatékony ha fel van töltve blade-ekkel, ez a project meg nem fogja feltölteni.
2 blade esetén szvsz pénzkidobás a Blade center (vagy bármilyen más blade rack.)

Ha rendelkezésre állás kell, akkor a legköltséghatékonyabb megoldás bármilyen redundáns tápú branded szerver, multipath IP, és multipath FC, megfelelő gyártói support szerződéssel.

Ha kritikus a rendelkezésre állás, akkor 2 node-os Ha cluster. Sun Cluster tudomásom szerint még mindíg ingyenes. Linuxokat nem ismerem, de a Sun-os elég jó.(nyilván ha kell gyártói támogatás is, akkor fizetős)

A storage-ok redundanciája elég jó, (normális duál tápos, duál controlleres megoldásokról beszélek.)
abból elég egy is.

Jó, kicsit elkapkodtam. Valóban, ha nem akarnak tovább nőni, akkor nem kell BC. De mindenképp egy komoly rack szerver kell alá. Ha nem clusterben van 2, hanem csak 1-et vesznek, akkor abban legyen minden redundáns. És ha tényleg mission critical progi fut rajta, akkor talán még egy 7/24-ben élő, helyszínre kiszálló, a hibát 2/4/8/24 (pénztárca függvénye) órán belül elhárítós javítási szerződést is kötnék. Annál rosszabb nincs, mikor a kisker/nagyker/gyártó közli, hogy az elromlott alkatrész nincs raktáron, de 1 hét múlva lesz...:(

Érdekes ez az iSCSI-s ötlet, csak még elég drága, legalábbis a márkás termékek. Egy nagy cache-el ellátott 4Gbites FC storage, 2 controllerrel, 15k-s FC vinyókkal, valami jó kis RAID-be szervezve is megteszi talán.

Egyébként, ha a kérdező nagyjából meg akarja becsülni, hogy mire lesz szüksége, érdemes valamilyen sizing tool-lal méreteznie. A gyártók weboldalain szokott lenni ilyen, már amelyiknek.

Hat nem tudom. En mar csak ilyen hulye maradi vagyok, ragaszkodok a 10 krpm-es also hatarhoz enterspajz szervernel. Otthonra - az megint mas teszta. Viszont, lehetne olcsobba tenni a 10 krpm-es diszkeket.... :-)
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ezért nem raknék adatbázis alá külső storageot. Mit gondolsz mekkora IO terhelést generál egy adatbázis a diszkrendszerre, ha azt a 10M sort beindexeled?

Egy közepes méretű cég ügyvitelét töltöttük fel 4 évre visszamenőleg (nem 10M sor volt), úgy hogy napközben dolgoztak az adatbázisból (csak éjszaka 8 órát mehetett az adatfeltöltés) 1,5 hónapig.

Vennék egy x4250-est (vagy többet), és nem külső adattárolásban gondolnoznék ami további költséges problémákat generál.

Pláne nem akarnám rontani sem a Sun, sem az IBM üzletét, de az Intel Modular Szervere ennek kevesebb, mint a feléért lehetne egy opció.

- maga a modul keret tápokkal, SAS storage modullal nagyságrendileg(!) kb. nettó 1.2M,
- a komplett szerver modulok 2x komolyabb Quad Xeon CPU és 16GB RAM mellett kb. 600e Ft /db.
- a belső storage-ba SSD-k, vagy SAS HDD-k "sima" diszk áron (ugye ez nem brand szerver, van hozzá üres Hot-Swap keret!)
Tehát összesen nettó 5M forintért 6 szerver modul, komplett storage megoldással 6U keretben.

persze, lehet ganyolni. ahogy en is el szoktam mondani mikor en tartok valami workshopot, ossze lehet rakni 95% -at a 7410nek otthon.
opensolaris adott, zfs adott, mi kell meg, ugye? ;-)

ha off-the-shelf megoldas kell, akkor a Sunos storage analyticsnel nincs jobb a piacon (persze magunk fele megy a kezem, de azert nezzunk meg egy HP 9100at, vagy egy NetApp megoldast..). ha kesz vagy hackelni is, ossze lehet rakni.

nade kerem. ez kb olyan, mint amikor valaki szervert akar, Te meg azt ajanlod neki, hogy vegyen a boltban core2ot, meg enermax tapot, samsung vinyokkal...

Tudom hogy kell a merketing főleg a Sun-nak. Minek 2TByte-os adatbázis alá egy 7410-es storage? De még ezután a storage-hez vehet néhány alkalmazás szervert is, és ekkor még a terheléselosztás még mindíg nincs megoldva.

Persze ha az adatbázis mérete várhatóan felkúszna 576TB-ra, akkor létjogosúltsága lenne a külső storage-nak; de akkor meg annyi alkalmazás szervert kéne üzembe állítani, hogy megint csak létjogosultsága lenne a blade technológiának. Ebben meg két meghatározó gyártó van jelenleg a piacon: HP és IBM.

( cheeky v | 2009. 07. 22., sze – 08:33 )

Szerintem ezek, amiket írsz, azért nem olyan borzasztóan nagy és elrettentő méretek, hogy egyből az új reaktor rendelését is leadjátok Pakson...
Persze igen, egy rendes storage nem árt. :)

Viszont baromi kevés az információ a méretezéshez. Kis hazánkban egy sokkal fontosabb kérdés szerintem, hogy ki a beszállító, aki a szoftvert írja?
Elég széles szeletét sikerült megismernem már ennek a piacnak, és oly mértékben dúl az Oracle-re fejlesztő szállítók körében a dilettantizmus, hogy rossz nézni. Állítom, 10 beszállítóból ha 1 az, akitől értelmes kódot várhatsz. Sokan feltalálják a melegvizet, "saját framework"-nek nevezik, és újraalkotnak mindent, amire már rég van normális iparági sztenderd megvalósítás százszám, csak még a design pattern-eket sem követik.
Aztán jönnek a framework konfigurációs táblát másodpercenként 70x olvasó bean-ek, meg az egyéb hasonló ordas baromságok.

Na ez az, amiért az általad adott adatok alapján nem lehet méretezni. Ha a fejlesztő egy barom, akkor a világ összes vasa is kevés. És az esetek jelentős hányadában a fejlesztő biz az.

De hogy némi támpontot is adjak:
- Célszerűen tényleg valami értelmes, középkategóriás külső storage.
- Innentől a HW/SW raid ugye nem kérdés.
- Lehetőleg a storage, amit vesztek, úgy legyen méretezve, hogy az optimális teljesítményt ki lehessen belőle hozni (értsd: se túl kevés, se túl sok diszk ne legyen benne, inkább több kisebb diszk legyen, de darabszámra közelítsen az adott doboz optimális diszk számához).
- Szerintem a sparc halott, de ezt már máshol kitárgyaltuk, szóval ne fizess fölöslegesen sokat se gépért, se oprendszerért, se a supportjáért. Pontosan ugyanúgy képes megdögleni a Sparc/Solaris is, mint a PC/Linux, csak 5-6x annyi pénzért teszi ezt azonos performanciamutatók esetén.
- Ha a szállító rugalmas a verziót tekintve, nyugodtan menj 11g irányába, azért sok jó új feature van benne.
- Az is kérdés, milyen módon oldanád meg a redundanciát, szükséges-e egyáltalán, mi a rendelkezésre állási követelmény.
- Archivelog mód gondolom lehetséges, ha OLTP, de még ez esetben is érdemes lehet megfontolni ekkora méretnél egy külön mentő gépet (persze ott nem kell nagy teljesítmény), ha egy héten többször is szeretnél teljes mentést. Ha megbékélsz a heti egy teljes mentéssel, plusz a logok folyamatos mentésével, és hétvégén le lehet hosszabb időre terhelni a gépet, akkor persze ez nem szükséges.

"és oly mértékben dúl az Oracle-re fejlesztő szállítók körében a dilettantizmus, hogy rossz nézni. Állítom, 10 beszállítóból ha 1 az, akitől értelmes kódot várhatsz."

Abszolute igaz, amit írsz, főleg a beszállító rész. Pont ezért írtam én is, hogy ajánlásokkal meg ökölszabályokkal elég gyakran nem sokra lehet menni.

Egyébként a sajnálatos tapasztalat az, hogy a szar kódot a leggyakrabban durva vassal kell kompenzálni, mert kijavítani a kódot jóval többe kerülne. Főleg ha külföldi a beszállító. (pl. I-flex mond valamit :) )

Nekem külföldi szállítóként a kedvencem jelenleg az "update software AG" csodás CRM megoldása, aminek a fejlesztői még nem hallottak a bind variable használatáról. CPU parse time az adatbázis idő 90%-a. Bravó. Osztrák barátaink odatették magukat. :)
Azt mondják magukról, hogy piacvezetők. Csak még nem definiálták, melyik piacon.

Elfelejtettem beidezni, hogy mire reagalok:
"- Szerintem a sparc halott, de ezt már máshol kitárgyaltuk, szóval ne fizess fölöslegesen sokat se gépért, se oprendszerért, se a supportjáért. Pontosan ugyanúgy képes megdögleni a Sparc/Solaris is, mint a PC/Linux, csak 5-6x annyi pénzért teszi ezt azonos performanciamutatók esetén."
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Részemről nem vagyok egy nagy Solaris fan, de lehet, hogy csak nem volt szerencsém. Mindenesetre akárhányszor akárhol találkoztunk, mindig épp probléma volt vele, és nehézkes volt. De ettől függetlenül tényleg lehet, hogy csak nekem volt rossz szériám a Solaris-szal.
Igaz, AIX-en például sose voltak ilyen problémáim.
Linux volt ilyen is, olyan is, de ha gáz volt, előbb-utóbb mindig megoldódott.

Szóval ízlés kérdése. Eddig nem volt elsődleges platform a Sol/x86, nem tudni még, mi lesz most a felvásárlás után, tehát ez az egész eléggé mozgó talaj szerintem. A dolgok jelenlegi állása szerint PC vasra inkább vmi támogatott Linux-on látnék neki a feladatnak. Viszont fél év múlva lehet, hogy már az látszana, hogy vállalható a Sol/x86.

En amondo vagyok, hogy legrosszabb esetben osol vonalon el lehet indulni. Ha az Oracle a vegen meg is szegne a szavat (bar az akviciorol szolo elso par hir eseteben kijelentette, hogy elsodleges platformma kivanja tenni a Solaris-t), a community szinte biztosan tovabbviszi az osol-t, ami moge pedig felallhat meg egy uj ceg is.
Persze, nincs meg a papirom a jos vegzettsegrol, szoval csak amator szinten kezelem a kristalygombot, akar meg tevedhetek is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( lacika v | 2009. 07. 22., sze – 10:36 )

Vagy több "kisebb" teljesítményű gép RAC környezetben, megfelelő storage rendszerrel. Ezt a megoldást könnyebb lesz a későbbiekben skálázni.

--
http://laszlo.co.hu/

vagy inkább könnyebben csontig sz*patod magad.
A fentebb is említett "legendás" Oracle fejlesztői szakértelmet tekintve örülhet, ha egy nem RAC-ost is meg tudnak normálisan csinálni.
Komolyan.

Láttam már olyan hűdefasza-racot-használunk megoldást, ahol a kliens oldalt nem a megfelelő libekkel linkelték, így nem tudta tolerálni, ha az egyik node a RAC-ból kiesett. Gyakorlatilag úgy lehetett használni csak, mintha nem RAC környezet lenne.

Nem olvastam teljesen végig, és nem jött le, hogy nincs túl nagy oracle fejlesztői szakértelem, de azt is meg lehet fizetni (persze nem olcsó). Én abból indultam ki, hogy akik a rac-ot tervezik, implementálják és akik fejlesztenek rá, értik a dolgukat.
Egyébként meg igazad lehet. Más részről, meg ha nem értenek hozzá, akkor alátehetnek 256 CPU-t is 2 TB memóriával és hitachi storage-ekkel, akkor sem lesz gyors az alkalmazás.

--
http://laszlo.co.hu/

( Ice | 2009. 07. 22., sze – 13:07 )

1 T-ig x86 felette valami RISC! IBM párti vagyok. :)

Storage lesz a bottleneck!

Azon ne spóróljatok!

Sokáig próbáltam nem hozzászólni, de mégis megteszem. Sok dologban egyetértek az előttem szólókkal pl.:
- tényleg a storage a fontos, azon ne spóróljatok, amúgyis szükséges egy clusteres megoldáshoz (ha RAC, ha nem RAC, csak HA cluster akkor is)
- simán válasszatok Linux-ot, és PC-s szervert! az egyesülés után is maradni fog a linuxos vonal, minden fejlesztés azon történik és a belső rendszerek 90% is linux már az oracle-ben néhány éve...
- és válassz Oracle Enterprise Linux 5.3-at, ha már úgyis Oracle lesz rajta, közös support, olcsón beárazott OS support (125$/év/gép) és tulajdonképpen egy RHEL csak páncélos pingvin logóval :)
- A másik fontos dolog a memória. Nagyon nagy, és egyre nagyobb memóriaigénye van az Oracle-nek verziórol verzióra. És látványos gyorsulást lehet bemutatni kellően nagy SGA-val PGA-val. Én minimum 12-16G RAM-ot ajánlanék gépenként.

Rob

Is Oracle Getting Ready To Kill Unbreakable Linux? http://broadcast.oreilly.com/2009/07/is-oracle-getting-ready-to-kil.html

... But now that Oracle has acquired Sun, the landscape has changed. Oracle can still continue to support Linux, but nobody is ignoring the fact that they now own the copyright to their own operating system. Linux vendors like Red Hat cannot benefit from improvements made to the Solaris kernel, in contrast to the contributions Oracle made to Linux...

... As far as features go, OpenSolaris has ZFS, container virtualization, role based security, network virtualization, and dtrace. Linux has spent the last six years playing catch up with a lot of these features, and they're still not 100% there yet. By the first quarter of 2010, OpenSolaris users will have a default filesystem that supports encryption and de-duplication. In contrast, Red Hat Enterprise Linux users are just starting to get their feet wet with ext4, a filesystem that has no real notable features whatsoever.

If Oracle had to take a serious look at these the feature sets between Linux and OpenSolaris, which one are they most likely to put their money on?...
--
Those who do not understand Unix are doomed to reinvent it, poorly. -- Henry Spencer, 1987
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Ide is becitáltad ezt az idióta Solaris fanboy-t?
Egek, a fickónak nem sok fogalma van arról, amiről beszél, csak spekulál, és még azt se túl megalapozottan.

Teljesen véletlenül keresgéltem ma az Oracle certification matrix-ot, és mi jött velem szembe a Metalink-en, a 742060.1-es note-ban? Íme:
"Solaris Operating System (x86) - Platform Obsolete"

A dokumentum pontosan 7 napja lett frissítve.
A sparc, mint platform halott, és úgy tűnik, az Oracle szerint a Solaris/x86 is halott. Megemlíteném, hogy ehhez képest még a Linux on Power is élő platformnak számít az Oracle számára.
Hát ennyit az ostoba spekulációkról.

Rosszul értelmezted a 742060.1-s Metalink note-t, ugyanis abból nem következik, hogy a SPARC platform vagy a Solaris OS halott-e vagy nem.

A Solaris-ra vonatkozó részt kikopiztam, a három dátum a következő verziókra vonatkozik: 10.1.05, 10.2.0.4, 11.1.0.7.

*** Solaris Operating System (SPARC 64-bit)
* 05-FEB-2006
* 30-APR-2008
* 06-OCT-2008

*** Solaris Operating System (x86-64)
* Not planned
* 13-NOV-2008
* Sched TBA

***Solaris Operating System (x86)
* 18-JUN-2006
* 14-Nov-2008 (Last patch set for this platform)
* Platform Obsolete

(Sched TBA = Schedule To Be Announced)

Nekem ebből annyi következik, hogy a "Solaris Operating System (x86)", tehát a 32bites Intel-n futó Solaris-on az Oracle 11g már nem támogatott. SPARC-ra most is elérhető, és 64bites Intel-en futó Solaris-ra elérhető lesz (TBA).

Nem ez alapján a note alapján mondom, hogy a SPARC halott, ezt már régebben itt kitárgyaltuk többször is. Ez az én privát véleményem, az, hogy a világban osztják még páran, puszta véletlen. Nem állítom, hogy én lennék az IT trendek Nostradamusa... :)

Ok, az adott note-on benéztem az x86/x86-64 történetet. Akkor ez azt bizonyítja, hogy legalább annyira fontos, mint a Linux on Power. Mióta van 11g? És még mindig nincs kiadva a platformra, csak TBA.
Hát ez alapján még mindig nem rohannék minden adatbázisom platformját Sol/x86-64-re cserélni. És nem vizionálnék olyan vadságokat, mint az idézett cikk elkövetője, mert elég látványosan nem ez a trend. Jelenleg.
Larry bácsi persze hoz sokszor salamoni döntéseket, tehát lehet, hogy két hét múlva vesznek egy 180 fokos fordulatot, és elsődleges platformmá nyilvánítják a Solaris/x86-64-et, de azért ezen sokan meglepődnének, és nem kevesen felháborodnának.

Maga az Oracle is egy idiota Solaris fanboy?
"The Sun Solaris operating system is the leading platform for the Oracle database, Oracle’s largest business, and has been for a long time. With the acquisition of Sun, Oracle can optimize the Oracle database for some of the unique, high-end features of Solaris. Oracle is as committed as ever to Linux and other open platforms and will continue to support and enhance our strong industry partnerships."

Oke, ertem en, hogy te azt veszed bizonyito erejunek, hogy meg nincs mindenhova 11g kiadva, viszont tegyuk hozza, hogy az Oracle RDBMS az nem egy egyszeru lelkuletu falusi leanyzo, hanem egy tulburjanzo lelekkel megaldott urino, akivel ovatosan kell banni. Egy masik kerdes az, hogy mit supportal az Oracle es mi mukodik adott platformon stabilan. Persze, az adott projektben fontos a tamogatottsag, de altalanossagban veve akar meg kevesbe is lehet mervado az Oracle fejbolintasa.
Igazabol, mivel az Oracle mar 2005 ota azt hangoztatja, hogy a Solaris a vezeto platform, az akviziciotol mindenki azt varja, amit te is fajlalsz: hogy lesz rendes Sol support. Amig ilyen keplekenyek a dolgok, en nem lennek ennyire borulato. Szerintem legfeljebb karacsonyra kiderul, mik az Ora tovabbi szandekai. Be patient.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( xenix v | 2009. 07. 23., cs – 21:57 )

Konkrétumok (mérések, pontos terv:) ) híján talán érdemes a legolcsóbb felől közelíteni.
- Komoly adatbázis alá frankó tároló kell. (Ki fog derülni, hogy az a legolcsóbb, ha mással kezditek az éles üzemet;) ) Szerintem storage-n nem szabad spórolni, legyen nagyon redundáns és gyors. Vagyis a lemez min. 2x annyi, mint amekkorára a DB-t tervezitek. Opció tényleg 1001 féle van. Gyártó is, de
a megbízhatóbbakal érdemes foglalkozni (IBM? Hitachi?) Egy sima raid5e nem elég biztonságos, ha érzékeny az adat. Oracle-nél a "normál" redundancia tükrözést jelent, a fontos cuccokat min. 3 helyen ajánlják tárolni (pl. control file, voting disk). És ezt sok szívás alakíthatta ki ;)... Minél kisebb lemezeket pakoltatsz bele, annál gyorsabb lesz. (Pl 15 db 300GB vagy 30 db 146GB? az utóbbi kb. 2x gyorsabb lesz.) Ők meg nyomják a minél nagyobbakat. Mostani gazdasági körülmények közt (sales->0) bármelyik komolyabb gyártó cuccával el lehet érni egy stressz-teszt lehetőségét, csak normális kereskedővel kell beszélni, aki azt intézi.
- Gép: ha "pc" vonal, mert árérzékeny, akkor blade (IBM nem is drága, csak itt is a kereskedő listaárát kell osztani még szépen gyök2 és 2 közé eső számmal a reális ár kimutatására). Abból lehet a keretbe rakni, amennyi kell, vagy amennyit elbír a ktgvetés (És az oracle licensz baromi drága, ott is érdemes többféle konfigra árat kérni, /processor, /user, stb...) Viszont a processzor licenszelés, ha szóba jöhet, akkor már csak azért is a darabszám miatt legpörgősebbekkel érdemes foglalkozni, de lehet variálni: hány gépre mennyi mag*hány proci éri meg leginkább. RAM-ból jobb a több,
de tényleg nem mindegy, 200 user vagy 200 állandóan futó folyamat. Itt azért a sw
gyártója igazán ajánlhatna valamit.
- Oprendszer: ha blade, akkor RH linux, azt csomagolja az Oracle is Oracle Enterprise Linux néven, szénné is van dokumentálva. Abból 1 storage mellett tök jó clustert lehet összedobni 1..n minél erősebb pengén: Oracle RAC, ha fontos a terheléseloszlás és a HA viszonylag olcsón.
Mondjuk az IBM-re (is) jellemző, hogy az első beruházás kijön olcsóbban egy pofás sales akció eretében, aztán a bővítés, felfelé skálázás iszonyú drága a starterhez képest. Hát, hirtelen ennyi.

Kerdes, hogy kell-e egy 10-20 node-s cluster rendelkezesre allasa ehhez a projekthez. Szerintem 3-4 blade-ert egy komplett blade racket venni felesleges, viszont egy iroasztalra halmozni a gepeket - hat a tobbit kepzeld el. Ez a projekt nem ugy hangzik, mint ami miatt boviteni kellene Paksot.

Azert oprendszer szintjen befigyel az is, hogy az app gyartoja mit ajanl esetleg. Ha o ugyanis azt mondja, hogy csak Linux vagy csak Solaris alatt fut az illeto app tokeletesen (mert peldaul van valami kiegeszito akarmicsodacska, ami hiv valamit, ami a mas rendszer alatt nincs), akkor lehet, hogy bukod a szemelyes preferenciadat.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

- Van olyan telepítés, hogy már 3 blade-nél megérte a keret 3 standalone szerver helyett, amit szinte kb. "csak úgy" adtak mellé, :) mert épp nem pörgött az eladás. A nagy kék meg tudja, hogy ha vki vesz keretet, előbb-utóbb úgyis teliszurkálja pengékkel, azért engedhet radikálisan. És akkor már konszolidálódtak rá régebbi cuccok is, mert megérte. Paks tényleg nem kéne a kérdéses projekthez.
- Igen, bármi buktathatja a kis személyes megrögzöttségeket, ez van:) Valamennyire csak tervezték, hogyha kijött pl. a 2TB adat, de arról a részről nem lettünk túlinformálva.