Az Oracle megvásárolja a Sun Microsystems-t

Címkék

Az Oracle Corp. (NASDAQ: ORCL) és a Sun Microsystems, Inc. (NASDAQ: JAVA) ma bejelentette, hogy az Oracle ~ 7,4 milliárd amerikai dollárért (részvényenként 9,50 dollár) megvásárolja a Sun-t. A részletek itt olvashatók.

Hozzászólások

egy nyílt forrású projektet csak egyvalami tud a /dev/nullba küldeni, az érdektelenség. ebben az esetben erről szó nincs. így ha az Oracle fiókba tenné a Mysqlt, születne egy fork és minden menne tovább, csak új néven. természetesen az Oracle nem ostoba, a Mysql pedig jó pénzt hoz. lásd kormányszóvivő.hu:)

Amit irsz, azt magadtol irod, vagy helyetted utik a billentyuket?
Mondd mar meg, hol ertelmes megoldas akar a XE akar egy rendes Oracle mondjuk akar egy hup.hu szintu oldal ala is? Boven nincs annyi lekerdezes, hogy megerne, szamitasi feladat gyakorlatilag nulla, ellenben az Oracle XE nagyon hamar hatarokba utkozne, a nagy Oracle meg baromi draga, ha support is kellene hozza, plusz az eroforrasigenye messze meghalad egy rendes MySQL-et. Szoval szerintem a MySQL az egyik legjobb megoldas (a masik a PostGres) a mai CMS alapu weboldalak gyors es hatekony kiszolgalasara. De tenyleg erdekelnek reszletesebb tesztek/tapasztalatok eles helyzetben mukodo Oracle hatteru CMS rendszerek mukodteteserol, melyek megcafoljak a fenti ervelest. Ha csak annyit mondasz, hogy hulyeseg, akkor valami hasonlot fogok en is irni.

--


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

Én "láttam" már Oracle XE-t, és néhány dolgon ütköztem meg:
* nem tudott több adatbázist, vagyis csak a sémákkal lehetett játszani
* a 4GBájtnyi maximális adatbázis méretből 700MBájtot elzabált saját célra
* feleslegesen sok memóriát használt
* kis kéréseket lassan szolgált ki
* egy kapcsolat felépítése rendkívül költséges művelet volt

Irreális egy ilyen adatbázis motort tenni egy olyan rendszer alá, amelynek még egy MySQL is nagy, egy SQLite vagy egy HSQL tökéletesen elég... hiszen pont ezért léteznek ezek az SQL motorok, mert egyszerűen baromság lenne Oracle XE-t tenni arra a helyre.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Mindent a helyére tesznek az alsó szegmensben.
Lesz Oracle DB XE, 1 CPU, 1 G RAM, 1 TB diszk.
Lesz MySQL XE, itt a jelenlegi skálázhatósági maximumot veszik alapul, azaz 2 CPU, 4G RAM, 1 TB diszk.
Esetleg kiadnak még egy Postgres-adaptációt, hogy teljes legyen az adatbázis-portfólió.

haha :) szerencsere me'g nem. :)
az IM amugysem kell ahoz, hogy natolva legyel :)

nade, ezeket Te kimerted, vagy csak ugy mondod? en anno neztem, es a magok szama*2 -ig jol skalazodott, de ez meg azelott volt, hogy az innodb mutexeket finomitottak volna. elvileg az 5.1 mar tud linearisan skalazodni sokaig.. :)

de kene szerezni egy X4450et vagy egy T5140et, es kimerni. ha valaki ad, szivesen megcsinalom :)

hmm, ez érdekes fordulat
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

viszlát mySql?
viszont ők érdekeltek a Java-ban

jajj, ne, BME-n szerveztek Oracle-ös előadásokat, és kb a fele abbol áll, hogy elmesélik, milyen cégeket vettek meg. Most majd ezt is elmondják. dejólessszzz

A MySQL sosem volt riválisa az Oracle DB-nek. Az előző japán bevásárló kisautó, az utóbbi utánfutós teherkocsi. Én inkább azt várom, hogy a MySQL fejlesztése megint felpörögjön, utóbbi időben nagyon le van maradva.

--
The Net is indeed vast and infinite...
http://gablog.eu

Miert, mit csinalna vele? Nem hagyhatnak meg 8.923 db torzsreszvenyt a piacion, hogy az a MySQL.

Hangsulyoznam, hogy a MySQL soha nem volt rivalisa az Oraclenek DBMS-nek. Ezzel pont hogy egy szep belepo kategorias termekre tettek szert.

--
The Net is indeed vast and infinite...
http://gablog.eu

Pontosan, egyaltalan abszolut nullaban rivalisa az egyik a masiknak. Igy pont jol kiegeszitik egymast: lesz egy belepo kategorias DBMS, amivel belep az ugyfel az Oracle univerzumba, es ha kinovik a MySQL-t, mar lehet is eladni az Oracle licenceket.

--
The Net is indeed vast and infinite...
http://gablog.eu

Azert, amiert a Gellert szallo es a Burj al Arab sem rivalisa egymasnak, es ahogy a Gundelnek sem rivalisa a sarki kifozde. Mas a celkozonseg.

Ha nem tudsz Dubaiban megszallni, akkor nem fogsz ezert Budapestre atjonni. Ha nincs hely a Gundelben, nem teheted at a sarki kifozdebe a targyalast, ugyanakkor ha csak az utobbira van penzed, az elobbibe nem fogsz beterni.

Ha a MySQL megfelel az igenyeidhez, akkor nem fogsz Oracle DBMS-t licencelni, ugyanakkor van olyan eset, amihez a MySQL keves. Ha komoly rendelkezesreallasra van szukseged, akkor a feladathoz valoszinuleg apropenz az Oracle support. Ugyanakkor sok esetben az Oracle teljesen felesleges (az XE is). Nem tudom, hogy a MySQL miert elterjedtebb, mint az Oracle XE, de elterjedtebb, es ezert erdemes tamogatni mar a neve miatt is. Ha nagyon nem kell nekik (vagy a trosztellenes csapat belekot), legfeljebb eladjak valakinek ezt a reszet.

Lattam mar olyan esetet, amikor egy serveren rajta volt Oracle es MySQL is. Utobbit valami webes cucc hasznalta, es nem erte volna meg atalakitani a kodot ugy, hogy az Oracle-t hasznalja.

--
"ne támogasd az erdők kiírtását mozijeggyel, töltsd le a netről!" - killllll, asva.info

Lattam mar olyan esetet, amikor egy serveren rajta volt Oracle es MySQL is.

Ez nálam elég rendszeres, mivel WordPress alapon szoktam megcsinálni a gépeken az üzemeltetési naplót. Egyrészt nincs kedvem, időm és tudásom átírni a WordPresst, másrészt az üzemeltetési naplónak semmi keresnivalója a valódi munkát elvégző Oracle adatbázis(ok)ban.

Ave, Saabi.

Miert ne lenne rivalisa? Attol fugg hol, persze. Nalunk jartak fejlesztok, akik boldogan bologattak, amikor arrol volt szo, hogy egy kulso adatbazishoz kene kapcsolodnia, csak akkor fagyott le a mosoly az arcukrol, amikor mondtuk, hogy MySQL, a kerdes ez volt: de miert nem Oracle? A vicces a dologban az, hogy a feladat bozasztoan primitiv, gyakorlatilag mezei select-ek, semmi sub query, migymas, mondhatni egyszerubb nem is lehetne, de ok meg itt is kardoskodtak, hogy ide Oracle kell, aztan szep szamokat hoztak ki, hogy mennyi lenne, majdnem seggreultunk tole. Na ez a tipikus hely, ahol pl miert ne lehetne rivalisa. Nyilvan vannak sokkal komplexebb, es "erzkenyebb" teruletek is az adatbaziskezelesnel, ott lehet mas az abra azert ...

> Benne van a csomagban, majd pont az adatbázis kezelőt nem kéri az Oracle.

Én a helyükben nem tartanám meg. Inkább visszaadnám Widenius-nak, hogy ezzel javítsam az Oracle megítélését. A visszaadás marketing értéke nagyobb lehet, mint a megtartás gazdasági értéke.

Hát én nem vagyok egy nagy üzletember, de inkább legyen konkurrenciám házon belül mint kívül... Visszaadás marketing értéke nagyobb mint a gazdasági értéke? Ne viccelj már. Pár hozzászólással feljebb van egy nagyon gyakorlatias meglátás: a mysql kiváló csalétek lesz az oracle komolyabb termékeihez. Ez kapitalizmus és nem grál lovagok kerekasztala.

> a mysql kiváló csalétek lesz az oracle komolyabb termékeihez.

Szerintem a jó csalétek a komolyabb termékeket modellezi (ugyanaz a szintaxis és a szemantika, mint a komolyabb termékeknél). Aki kinövi a modellt, egyszerűen át tud térni valami komolyabbra. A MySQL meg szerintem nem modellezi az Oracle komolyabb termékeit, ezért nem lehet jó csaléteknek.

> Visszaadás marketing értéke nagyobb mint a gazdasági értéke?

Megér-e neked* egyszeri 50 Ft-ot kiadni, hogy "zilahu jó csávó" hírek jelenjenek meg a sajtóban, vagy inkább szeretnél havi 5 Ft-os kiadás mellett egy év eltelte után havi 2 Ft plusz bevételre szert tenni?

*a számokon biztos lehet javítani, az arányok számítanak. Oracle bevételei helyett vegyünk átlagos havi jövedelmet; az 50Ft az a pénz, amibe az ajándék MySQL megvásárlása kerül a havi jövedelemhez arányosítva, a havi 5 FT a MySQL karbantartásába, fejlesztésébe kerülő összeg, stb. A lényeg az hogy az ismerős nagyságrendbe eső számok megkönnyítsék a helyzet átélését.

a mysql kiváló csalétek lesz az oracle komolyabb termékeihez
Az Oracle-nek van saját "csalétke": Oracle XE-nek hívják, ingyenes, és kiváló belépő termék.

Én sem vagyok gazdasági szakember, de nem látom miért lenne kiváló csalétek az Oracle-nek a MySQL.
Ettől persze megtarthatja, és fejlesztheti is, de nem mind "kistestvér".

a.

Kösz, ezt nem tudtam,

amúgy csak próbáltam utalni, hogy a MySQL nem biztos, hogy "belépő" az Oracle világába.
Az egykori próbálkozása az Oracle-nek sem biztos hogy azért volt, hogy találjanak egy kistestvért, inkább portfólió bővítés - már ha lehet ezt itt értelmezni... :)

Link?
Én ezt találtam:
http://www.oracle.com/technology/software/products/database/xe/files/in…
ill. MySQL esetében csak clusterre volt HW req:
http://www.mysql.com/products/database/cluster/faq.html#7

De ha tudsz valamit, oszd meg pls :)
Nekem egy gépen fut mindkettő, semmi extra igénye nem volt egyiknek sem, illetve az Oracle XE-nek legalább 1G swap kellett, addig nem volt hajlandó felmenni. Ha nagyon kekeckedünk, ezt lehet rendszerigénynek nevezni, deee... Érted... :)

a.

Végre egy jó hír...
Mondjuk már az első körös "eladó a Sun" hírveréskor is ez tűnt volna a leglogikusabbnak.

Lehet lesz Unbreakable Solaris! :)
Esetleg 11g x86 Solarisra...

Ha eszük van a (Open)Solaris-t kiadják GPL-be, ami kell azt beletolják a Linux-ba, a közösség meg majd fejleszti nekik az egészet. A fél Solaris fejlesztőgárdát meg elzavarják, ráállítják a Linux-ra, vagy más egyéb területre. Mivel eddig nekik a Linux megfelelt - sőt az volt az elsődleges platformjuk - bajuk nem hiszem, hogy van vele. Válság idején ez a legjobb forgatókönyv anyagilag.

--
trey @ gépház

Larry azt mondta, hogy eddig is Solarison adták el a legtöbb Oracle DB-t. Persze a Linux is fókusz marad továbbra is, de a Solaris is fontos nekik...
Lsd. webcast replay - http://www.oracle.com/corporate/investor_relations/index.html

Illetve az a cél, hogy integrált portfóliót kínáljon a diszktől egészen az alkalmazásig.

www.sunblog.hu

És lesz két levelező-, LDAP stb. szervere?
Ügyfélként én most jövő évig (addigra csak kiderül) semmi komolyba nem vágnám a fejszémet, sem az Oracle-től, sem a Suntól a kérdéses területeken...

Ezen csak egy gyors, és határozott döntéssel segíthetnek, de persze először a "nagypolitikának" kell kitermelnie a leendő vezéreket, amelyek révén aztán majd eldől, hogy mi esik áldozatul.

Vajh, mit csinálnak majd a vasakkal?
Eladják a Lenovónak? :)

Kíváncsi vagyok, portolják-e ZFS-t Linuxra?

Ez egyfelol - a java meg a szerverpiac szempontjabol - tok jo deal az IBM-eshez kepest.

Az adatbazis-piac szempontjabol viszont hatarozottan rosszabb deal: a mysql es a postgresql (mindketto Sun tulajdon) aranyaiban valoszinuleg tobbet vett el az oracle piacabol, mint a db2 piacabol.

Nyilvan lehet azzal jonni, hogy a mysql egy jatekadatbazis oracle-hoz kepest, en nem gondolom ezt, bazinagy rendszerek futnak felette, en azt gondolom, az oracle-nek erdeke elhitetni azt, hogy a szoftveruk egy komoly eszkoz, nota bene, van olyan 100% SQL-kompatibilis lekerdezesem (teli subquery-kkel es group by clause-okkal persze), ami mind mysql-en mind postgresql csont nelkul fut, az oracle-on elszall, ilyen es ehhez hasonlo okok miatt en valahogy mindig a masik kettot preferalom, es egy hype-nak tartom azt, hogy az oracle inkabb alkalmas azoknak a celoknak az ellatasara, amire az esetek donto tobbsegeben aztan vegul alkalmazzak (vallalati szoftver mogott db-nek lenni).

Az Oracle törekedett mostanában arra, hogy ne csak egy adatbázis szervert adjon az üzletben el, amit majd ráraknak egy valamilyen vason futó valamilyen oprendszerre, amiből neki nincs bevétele.
Most szert tesz mind a gépparkra, mind pedig az OS-re (OS-ekre), ami ahhoz szükséges, hogy komplett megoldásokat toljon be a szerverszobába. Ezzel egyrészt többet fog keresni, másrészt az ügyfeleknek is sokkal jobban megéri egy gyártótól beszerezni ezt a jövőbeni terméket. Ráadásul mennyire szép már az, hogy betolják a Datacentert és már csak klikkolni kell a webes felületen, hogy összelődd a virtuális oprendszereken a RAC-ot, az adatokat pedig a már ott levő storage termékeken osztod szét. A management ott fogja helyben kiverni a f@szát.

A gyakorlat inkabb az, hogy egy gyarto jobb (mar ha nem brutalnagy cegrol beszelunk, mint google v. ibm), mert egyszeru a support - nincs egymasramutogatas, minden ossze van reszelve (vagy ha nincs, akkor support, ugye). Arban meg eleg jo deal-eket lehet kifogni, kozepes nagysagu cegeknek meg van buyer-e, aki elintezi az akcios arakat.

Most szert tesz mind a gépparkra, mind pedig az OS-re (OS-ekre), ami ahhoz szükséges, hogy komplett megoldásokat toljon be a szerverszobába. Ezzel egyrészt többet fog keresni, másrészt az ügyfeleknek is sokkal jobban megéri egy gyártótól beszerezni ezt a jövőbeni terméket. Ráadásul mennyire szép már az, hogy betolják a Datacentert és már csak klikkolni kell a webes felületen, hogy összelődd a virtuális oprendszereken a RAC-ot, az adatokat pedig a már ott levő storage termékeken osztod szét. A management ott fogja helyben kiverni a f@szát.

Úgy van. És rajta kívül az IBM az egyetlen a piacon, ami ezt meg tudja még csinálni, nézzük csak:

MS: nincs hardver
Intel: csak hardver van, egy ideje reszelgetnek a Linuxon
HP: nincs adatbáziskezelő
Dell: csak hardver van, az is az Inteltől függ erősen
Cisco: csak hardver van
Redhat: csak oprendszer van

--
"How do you work in a team situation when all the other team members are fools and idiots?"

"Aki "normális" az már most is Oracle XE-t használ :)"

Programozóknál látok ilyen hozzáállást rendszeresen. Azok szoktak olyan apróságok felett elsiklani, hogy 1 processzor használat, 1GB-os memórialimit, 4 GB user data limit. Megírják a sz.rukat, aztán megy a sírás-rívás, amikor az ügyfélnél kiderül, hogy lassú, meg hogy egy év alatt betelt kiflivel az adatbázis.

Ilyenkor a programozó megvonja a vállát, az ügyfél vegyen x millióért licencet. Az ügyfél nem akar, ő egy megoldást vett (marhán nem kért Oracle-t, de a programozó azt erőltette, mert az milyen jó, igazából szükség sem volt rá), marhán nem akar még milliókat költeni.

A programozó f.szsága miatt szív a rendszert összeállító mérnök (neki kell megoldani a lehetetlent, "megállt a rendszer"), elégedetlen az ügyfél.

Naponta megtörténő dolgok ezek.

A "normális" Oracle XE-t használ. Gondolom a "normális" ebben az esetben azt jelenti, hogy nem volt nagyobb projektje a helyi videotéka 17 ügyfeles adatbázisánál.

(Ez nem csak az Oracle XE-re vonatkozik, hanem a többi "beetető" adatbázisra is, úgy mint MS SQL Server Express-re, vagy az IBM DB2 Express-C-re. Ha már ilyen, akkor inkább az IBM cucca, ami 2 processzor (4 mag), 2 GB RAM és végtelen adatterületet kínál)

--
trey @ gépház

Fölhozható ellenpéldának a másik véglet is: a zseniális programozó MySQL-t rak a program/sitemotor alá, ami kiválóan működik az otthoni "csúcs PC"-jén. Aztán deployolja ügyfélnek, elkezdik keményebben használni, és mindenki csodálkozik, hogy a remek queryktől lassul a gép, a MyISAM nem bírja a sok párhuzamos írást, az InnoDB fölzabálja a disket stb.

Mindkettő emberi hülyeség miatt van, egyik sem az adott adatbáziskezelő hibája: nem arra használják, amire való. Emiatt fölösleges az Oracle-t szidni.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Úgy tűnik nem értetted meg mit írtam. Nem az Oracle-t szidtam, hanem egyes emberek nem előrelátó hozzáállását tettem szóvá. Valamit félreolvastál.

Lehet egyébként jó az Oracle XE, meg van annak a helye, de azért a "Aki "normális" az már most is Oracle XE-t használ :)" állítás elég vastag.

--
trey @ gépház

Hat igen, egyfelol nem az a jo MySQL, amit a disztrod ad, hanem amit magad optimalizalsz, az adott celnak megfeleloen. Nem kell nagy szemekkel bamulni, egy agyonterhelt MySQL-t igenis optimalizalni kell, ki kell belole dobni ami nem kell, ra kell tenni teljesitmenynovelo patcheket, processzoroptimalizacio es tarsai. Erdekes modon mindenki elfelejti, hogy a disztrokhoz adott csomagok altalanos celra vannak felkeszitve, nem pedig specialisra (ez alol kivetelek a specialis celra osszerakott disztrok). Meghat, a nem tudas nem mentesit.
--


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

Az Oracle XE nem "termelésre" való, hanem nézegetésre, kipróbálásra, esetleg fejlesztésre. Itt (az első bekezdésben) leírtam, hogyan gondolom egy adatbázisalkalmazás skálázását Postgres és Oracle között.

Az a baj, hogy az Oracle XE még fejlesztésre sem feltétlenül jó. Van egy kis regressziós tesztem, amivel megnézem, hogy az Oracle és a Postgres interfész egyformán működik-e. Egyszercsak mit látok: Az XE egy helyen eltér (létező értékek helyett nullokat ad egy oszlopra). Egy napig áskálódtam, minden visszatérési értéket megnéztem, stb, de semmi. Felraktam az XE helyett a 11g-t: A dolog "megjavult".

Nem állítom, hogy a programom hibátlan, de azt igen, hogy van egy olyan értelmesnek látszó programom, aminek az Oracle XE és Oracle 11g más választ ad. Egyébként OCI-ból használom az Oraclet.

--
CCC3

Akkor remélem rágyúrnak JDeveloperre.
SÜN!
------------------
lúzer Ubuntu júzer

Ezzel a sunos-nek es a sparc-nak valszeg reszeltek. Epeszu menedzser nem tart fent egy total mas architekturat iszonyat penzekert, inkabb az x86-os vonalat + linuxot fogjak tolni.

Ami szerintem jobb is a unix vilagnak. De legfokepp: egy gyengelkedo hardcore unix-os ceg most hatalmas tokeinjekciot kap. Mindenkeppen jo.

"86-os vonalat + linuxot fogjak tolni."

Ugyanezt tippelem én is. Gazdaságilag tök értelmetlen lenne más irány. A Sun elbukott abban, hogy életteli fejlesztői közösséget építsen az OpenSolaris köré. A Solaris-ból komolyabb pénzt nem tudott csinálni. A mostani SPARC rendszerek nem egy Oracle bajnokok (fixme), az Oracle Linux felett pedig elfut a Sun x86 vasain is. Fenntartani egy fejlesztőgárdát azért, hogy megmentsenek egy olyan dolgot, amibe egy másik cég belebukott, nem egy ésszerű lépés. Bár láttunk már karón varjút, így bármi megtörténhet.

--
trey @ gépház

Jah. Pontosan.
Szerintem jobban megéri egy olyan oprendszerre fejleszteni, ami teljesen a cég tulajdonában van.

Aki Oracle-t akar, az eddig is az alapján választott oprendszert a cucca alá, amit a fejlesztő cége, vagy az Oracle javasolt.
Ha az Oracle holnaptól azt mondja, hogy Solaris a preferált, akkor Solaris fog az adatbázis alá kerülni a legtöbb helyen.

Így az adatbázis licensz és support mellett még a Solaris support is bevételt generál ugyanattól az ügyféltől.

Jah, lehet, kezdő vagyok.
Csak az miért van, hogy pl. még egy banknál sem láttam mission critical környezetben linuxon Oracle-t futni, solaris-on meg jópár tucatot.

Azért megnézem, hogy linux alá mikor lesz olyan vas, ami olcsóbb mint egy M5000-es, vagy egy M8000-es és ugyanolyan teljesítményt hoz mint azok.

Mert ugye van ahol k. mindegy, hogy mennyi a linux tco-ja, ha az esti job nem fut le a kötelező időablakon belül.

Jónak mondod. Ezek szerint nálunk sem jártál még, ha nem láttál ilyet...

Egy alap M5000-es 8 GB RAM, 2 db 2,15-ös kétmagos, négyszálas SparcVI-tal ~45k USD listaáron.
Ennyiért kapni HP "pc" vasat, 8 db 2,7-es négymagos Opteronnal, 128 GB memóriával.

Találós kérdés: melyik a jobb adatbázis-vas vajon?
Elhiszem, hogy az új SparcVI atomkirály, de ennyire azért nem.

A Sparc egy régen halott ló, amit a Sun rugdos már egy ideje, mert még mindig nem vették észre, hogy meghalt. Persze ettől még lehet, hogy az Oracle majd úgy dönt, hogy megpróbálja feltámasztani, de őszintén szólva így válság közepette eléggé meg lennék lepve.

Hát, amit írtál az az M5k minimum kiépítése.
Azért ebbe is bele lehet rakni 256Gb memóriát, meg 8 db. 4 utas USVII-et. És ez csak a középkategória...

"Elhiszem, hogy az új SparcVI atomkirály, de ennyire azért nem."
Ott az új SparcVII. Az igen. :)

Egy max kiépítésű M5k azért nem kicsit erősebb szinte bármelyik x64 arch-nál.
A processzoron és memórián kívül az olyan dolgok is számítanak, mint pl. memória és IO sávszélesség.

Ismétlem, ha egy bizonyos teljesítménynél több kell, akkor oda vegyél IBM-et, vagy Sun-t.
Vagy esetleg HP-t, de ne i386 dzsunkát, hanem mondjuk Integrity-t. (Vajon ők miért árulnak high-end vasakat?)

Ember, épp erről beszélek, hogy a minimum... Az említett HP vasban meg már benne van a 32 utasításszál, amit az M5k-ba +100k USD-ért kapsz meg, nem beszélve a memóriáról.

Egy max kiépítésű M5k, az azt jelenti, hogy kb 250k USD beruházás, és a jelenleg piacra lépett új intel x86 szerver lapkák úgy verik péppé az USVII-et, ahogy kell.

Én személy szerint Oracle adatbázis alá nem nagyon hiszek abban, hogy nagyobb monolitikus vas helyes választás. Ilyen méretű feladatoknál már tényleg inkább több vason elosztott terheléssel, és RAC használatával olyan pluszokhoz jut az ember, amit egy monolitikus architektúrában nehéz megbízhatóan megvalósítani. Persze, ilyenkor ugyanazt a pénzt az olcsóbb vas helyett a drága szoftverbe kell ölni, de ez már csak így van. Ettől még az architektúra maga előnyösebb lesz...

Én láttam. Nem banknál, mert bankokban nem nagyon dolgoztam, de telkónál, szállítmányozásnál volt.

Viszont sok helyen, ahol nem csak egy akármi adatbáziskezelő kell egy akármi alkalmazás mellé, hanem mondjuk egy konkrét alkalmazás van, ami alkalmazásszerver, adatbázisszerver, stb. több darabból áll, ott egyszerűen a vendor nem szórakozik azzal, hogy 6 féle OS-t szállítson.
Jön minden egyféle gépen, egyféle OS-sel.

Ahol én dolgoztam, ott ez általában HP volt vagy Sun. Mondjuk az elmúlt 8 évben.

Szerintem ár/teljesítményben (és teljesítményben) még így is jobban jön ki, de persze kérdés, hogy mire.

Mindenesetre nem úgy tűnik, hogy a nagypapakorú adminok/architektek "scale up" elképzelése terjedne. A fiatalok fejében már más van, csak hát a sziklaszilárdnak gondolt -amúgy persze tudjuk, hogy nem- banki, és egyéb helyeken még nem ők osztják a pénzt.

Én csak a kihívásodra válaszoltam. :)

Ahol meg az abszolút kapacitás számít, nem ilyen csumpi rendszereket használnak, hiszen azok túl drágák és lassúak is, hanem építenek egy clustert. Nem?
Vagy te azon igen ritka feladatokra gondolsz, amely annyira teljesítményigényes, hogy egy ilyen közepes teljesítményű cucc is elég a futtatásához, viszont a feladatot csakis kizárólag egy kernelen belül lehet megoldani?

Nosza, van már InfiniBand, RDMA, meg hasonlók, olyan sebességekkel, amelyek nemrég még a CPU-k etetéséhez is sok lett volna, akár ezt is megteheted...

Akár standard, low cost PC-kből is.

De. Nem is tudom, hogy miért nem használnak mindenütt parallel clustereket. :)
Talán azért, mert 10x (100x?) annyiba kerülne megírni az adott alkalmazást, hogy elosztott rendszeren tudjon normálisan futni, mint alátolni egy kicsit nagyobb vasat?

Léteznek olyan feladatok, amiket nem tudsz annyira párhuzamosítani, hogy elosztott rendszeren használható legyen.

Egy elosztott rendszer hibatűrése is igen kényes kérdés.
Vannak olyan feladatok, ahol a párhuzamosan futó jobok közül bármelyik elszáll, az megakaszthatja, vagy akár tönkre is teheti a teljes feladat futását.
Márpedig minnél több node-ot használsz, és minél bonyolultabb az adatelosztó és szinkronizáló rendszered, annál valószínűbb, hogy valamelyik node meghibásodik.

A kis garázsokból indult startupok (google, facebook, meg mittudoménmi) mind ezt az irányt választották az M9000-es (vagy E2xk) helyett. A tudás már ott van a fiataloknál, csak idő kérdése, míg ezek az elvek beszivárognak az annyira hihetetlenül ködös misztikusságba burkolózó banki rendszerekbe is. :)

Kíváncsi vagyok mikor jutunk el oda, hogy mondjuk IB interconnecttel valaki megírja a Linux kernelt ilyen elosztott rendszerre. Mert a mondandóm lényege pont az, hogy ma már egy HP blade chassis 64 CPU-val, tele memóriával (az annyi mint 256 db 3 GHz-es mag és 1 TiB memória 10U-ban) egy korrekt IB switchcsel kb. olyan belső sávszélességekkel rendelkezne, mint egy általad emlegetett "nagy" gép.
Csak két szekrény helyett 10U-ban, tized (vagy még kevesebb) áron...

De kíváncsian várom, hogy szerinted mi az, ami egy M9000-est ehhez képest mássá tesz.

Csak az miért van, hogy pl. még egy banknál sem láttam mission critical környezetben linuxon Oracle-t futni, solaris-on meg jópár tucatot.

Ez kizarolag a sales-esek dicserete. Ar/teljesitmeny aranyban egy nagysagrenddel rosszabb, megbizhatosagrol meg csak annyit, hogy minden hardvergyaros kinal mar x86_64 alapu szervert, es alairom, semmivel sem rosszabbak, mint egy sun.

BTW, megbizhatosag, mint olyan, amugy is felesleges a clusterek vilagaban. Ha van 16-64 vasad, akkor bizony valamelyik EL FOG ROMLANI. Pont. Tokmindegy, milyen hardver. Innentol meg tokmindegy, hogy milyen gyakran, a lenyeg, hogy szepen le legyen kezelve a hiba.

Hát, ha van egy HA clustered, aminek az alkalmazás rétege kb fél óra-óra mire elindul, akkor nem mindegy, hogy milyen gyakran döglik meg.
Vannak olyan cégek, akik máig használnak fault tolerant rendszert, mert egy perc állásidő is 60 másodperccel több a megengedhetőnél.

Igen, egyre több mindenkinek elég az x86 teljesítménye, de mindig is voltak olyan felhasználók, akiknek a rendelkezésre álló legnagyobb teljesítmény kell.
Hiába jobb az ár/érték aránya az x86-nak, ha van olyan alkalmazási terület ahol az elérhető legnagyobb teljesítmény kell, akkor 10x rosszabb ár/érték arányt is ki fognak fizetni.

Nem véletlenül árul még mindig mainfram-et is az IBM.

A dinoszaurusz is elég sokáig húzta, de az evolúció csak betett neki.
Miért pont a mainframe-ek lennének a kivételek? Legjobb esetben is kihalnak a most megszülető új zsenik "hatalomátvételekor".

nem véletlenül árul". Hát persze hogy nem. Addig árulja, míg nyeresége, vagy egyéb formában megtérülő bevétele van belőle. Vagy van más oka is?
A mainframe-en (a mainframe megbízható) futó program nem tud olyanolyan megbízhatóan futni 16 pécén? A 16 pécé lassabb, mint a mainframe (a mainframe gyors)?
A 16 pécé több helyet/áramot eszik, mint a mainframe (a mainframe takarékosabb)?

Szerinted racionális döntés a mainframe?

Izé, én nemrégiben olyat olvastam, hogy az IBM profitjai folyamatosan nőnek a mainframe-eladásokból és a kapcsolódó supportból. Most akkor mi van, mindenki megőrült? :)

Vagy lehetséges, hogy nem csak Google-jellegű workloadok léteznek? ;)

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Link? Egyébként ennek sem feltétlenül az az oka, hogy a mainframe-piac bővül. Millió dolog okozhatja.

Nyilván nem csak google-workloadok vannak, én de én nem is ezt mondom, hanem azt, hogy nehezen tudok elképzelni olyan workloadot, amit egy taliga pécével ne lehetne olcsóbban, gyorsabban, hatékonyabban megoldani.

A nagy különbség persze az, hogy aki mainframe-et, meg ilyen minicomputereket vesz, mint az M9000 (amelyet ugye szintén mainframe(-like) rendszernek pozicionálnak) az gyakorlatban gondolkozik (van ez a gyatrán megtervezett xyz alkalmazásom, min tudnám a legjobban futtatni), nem pedig elméletben (ha a nulláról kellene xyz-jellegű alkalmazást terveznem, hogyan építeném fel).

Én azt gondolom (de persze nem hiszem vakon, hogy nekem van igazam, mert nem vagyok hülye), hogy előbb-utóbb eljutunk odáig, hogy ezeket a böszme gépeket leváltják a valamilyen gyors interconnecten ülő elosztott vackok. Jelen állás szerint nagy valószínűséggel olyan pécék, amelyek tizenvalahány évvel ezelőtt még szuperszámítógépnek minősültek volna.

ahahahah

es a meg kb. 30 evig uzemelo gepekkel mi lesz? annyi idore vettek meg :)

szal kar lenne azert minden mas temetni mert itt a leenugz kermel meg az x86 es olcso, akar meg virtualizacioval is ami epp hogy csak h elidnult ezen a platformon

egyszeruen azzal nem tudsz pc kategoriaban versenyezni h gyarkolatilag 100% a rendelkezesre allas es nincs kieses 10 evig, rakhatsz barmilyen HA megoldast 10000 nodeal(mondjuk kivancsi lennek hogyan migralnal egy folyamatiranyito rendszert ilyen clusterre aminek a leallasa eseten megall a gyartosor vagy leall a repuloter)

--
.

tehat roviden:

-mukodo mainframe alapu megoldast hasznal egy adott ceg egy adott feladatra es ezt az ervenyben levo szerzodesek alapjan meg vagy 30 evig igy lesz

-szted ez "nem nagyon jo gyerekek", es sokkal jobb volna n darab szutyok_86 gepre cserelni leenugzzal mert ugy olcsobb is lenne meg amugyis

es en biznyiotsam be h az altalad javasolt teoretikusan mukodo megoldas telleg mukodni fog

sztem inkabb legyen az h citalj ide mindenfele bizonyitekot h olyan helyeken mint pl. atomeromu, repter, etc. ahol emberletek mulhatnak az informatikai rendszer mukodesen sikerrel csereltek mainframeket linux/x_86-ra.

en ertem h rengeteg esetben -pl. google.com jellegu workload- olcsobb es jobb(hatekonyabb) megoldast kinal ez utobbi de nehogymar mindenhova ezt akarjuk eladni csak azert mert a managernek felall a pingvintol

nem en fogom neked bizonygatni h igenis a nagygepek eletkepesek hanem a valo elet.

http://www.giit.info/mainframe.htm

--
.

A mondanivalóm lényege, hogy jobbnak tartok egy elosztott, hibatűrő rendszert, az erre a környezetre felkészített alkalmazásokkal, mint egy(két, három) darab vasat, amelynél a működés biztonsága leginkább ezeknek a (jól) működésétől függ.
Az, hogy milyen komponensekből is áll egy ilyen rendszer lényegében hullamindegy. Állhat PC-kből, vagy akár olyan gépekből is, amelyek jobban teljesítik az adott hely elvárásait.

Ha ebből csak annyit sikerült megérteni, hogy szutyokpécé, meg Linux, akkor így jártam, szíved joga, hogy inkompetens baromnak tarts.

Esetleg majd visszatérhetünk erre 10-20-30 év múlva, és megnézhetjük akkor -már ha lesznek még mainframe(-jellegű) gépek, vagy egyáltalán a maihoz valamelyest is hasonlító megoldások-, hogy mi lett, közeledett-e a "mass market technológia" ehhez a külön kasztot (ez persze már ma sem igaz) alkotó, magasztos világhoz, amitől annyira el vagy ájulva.

+ 1024

Lehet nezegetni a kepeket, es morfondirozgatni, hogy olcso PC "pakk" mikor is lesz erre kepes, es biztos hogy annyival olcsobb lesz? Stabil is? Vagy allandoan lehet imadkozni bizonyos testreszekre osszetett kezekkel minden gyakori es termeszetesen forradalmi technologiai attorest tartalmazo update elott, kozben, utan?

Ez tényleg olyan cucc, amire az életemet bíznám, hiszen annyi sávszélesség, meg olyan fasza RAS-feature-ök vannak benne. Meg hát ha mégis leolvadna valamelyik CPU, a nem licencköteles (már ahol) 5 GHz-es nyitott sávon hazaszólhat apucinak, hogy: "kína szindróma", lehet küldeni a betonkeverőt, ezután pedig kalibrálni kell a szekunder kvázipixist, aztán kontaminálni kell a negatív visszacsatolással katalizált hiszterézishurkokat, majd intabulálni az operációs rendszert.

De miről is jutott ez a cucc eszedbe? :)
A mainframe-ről? A skálázhatóságról? Az olcsóságról? A megbízhatóságról?

A maga nemében persze kiváló darab, a Power6 is biztos nagy sávszélességeken képes kommunikálni (bár ha nagyon akarnánk csak találnánk olyan CPU-t, amely ennél is többet kínál), de szerintem nem sikerült megértened a mondandómat.
Megpróbálom összefoglalni: szerintem a jövő az, hogy a standard fostömlő pécék szép lassan átveszik az ilyen közepes teljesítményű single image gépek helyét is.
Ehhez mindössze arra van szükség, hogy valakinek igénye és pénze legyen arra, hogy a fenti milliárd forintos cucc megvétele helyett szoftverfejlesztésre költse a pénzét, és összerakassa valami okos indiaival linuxos pécékből (hatásában) ugyanezt.
A fentihez hasonló technológia lassan itt van (millió portos QDR Infiniband switchek, a fenti P6-nál gyorsabb CPU-k, amelyek immár olyan gyorsan képesek a DOS-t futtatni, hogy annak visszafelé számlál az órája, széles adatutak, rengeteg memória(sávszélesség)), már csak valakinek meg kell csinálnia.

Ezek már biztosan ma is működnek HPC környezetben, ha van értelme (és igény rá) összedrótozni egy kvázi single image, de elosztott (esetleg megfelelően hibatűrő) rendszert ilyenre, valamikor csak meg fog jelenni (szoftver, vagy hardver oldalon, a lényeg, hogy standard komponensekből).

ui: és igen, szerintem annyival olcsóbb lesz. A fenti gépet az IBM magának fejleszti, emiatt drága. A gagyi pécék infinibandes (vagy tökmindegy, a lényeg, hogy nyitott, mindenki számára hozzáférhető tömegtermék) összekötéséből származó cuccban pedig megoszlanak a költségek, több piaci szereplő egymással versenyezve fejleszt építőkockákat, amelyek képesek egymással csereszabatosan együttműködni.

1 milliárdból mégis hány pécét lehet venni szerinted? :)

(a fenti árat tippeltem, ha van "listaárad", mondd)

Azert egy 10k node-s clusternel nagyon kicsi az esely, hogy leall a komplett cluster, nyilvan a cluster-management is clusterezve van, de legalabbis HA-val figyeltetve. Egy ilyen tipusu clusternel amugy meg az szokott lenni az iranyelv, hogy a fele passziv node, es foldrajzilag elkulonulo helyeken taroljak oket, igy a legnagyobb a fault tolerance. Annak, hogy ket foldrajzilag elegge tavol eso site egyszerre szurja tokon magat, megintcsak kicsi az eselye.
--


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

Ami persze nem gond az egy gépteremben elhelyezett mainframe-nél, hiszen önmagán belül csak nem szakad el a drót.
És milyen jó, hiszen a mainframe-technológia a fenti problémát is megoldja, ha esetleg mégis két helyre tennél egyet-egyet. Szub-Éta Detekt-O-Méterekkel kommunikálnak, triplán redundáns transceivereken keresztül!

És SHA-680564733841876926926749214863536422912-cel checksumozzák az adatokat (ezt még a ZFS sem lenne képes eltárolni)!

Szerintem ilyen helyre azert normalis ember site-onkent tobb fuggetlen linket is tervez, arrol nem beszelve, hogy ekkora clusternel jocsan benez egy geologiailag differencialt site-rendszer is. Tudod, ha valamit nem ismersz elegge, nem kell fikazni olyan nagy hevvel.
--


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

aha

mennyi az atterheles egy ilyen ip halon, 2-3 masodperc? 5 perc?

gondolom a leszallas kozben levo repulogepnek majd elmagyarazod h figyi ez ugyanaz mint amikor kihullik egy processzor vagy barmi a mainframebol es nem tortenik semmi mert minden redundans ugyhogy lecci ne crashelj bele a betonba mert elment a nulla jeled es nem tod milyen messze van a fold

--
.

Tartom amit eggyel feljebb irtam, egy ilyen helyre 2-3 fuggetlen link tervezese automatikus atallassal alap. Persze kerdes, hogy maga a cluster mennyi ideig turi a fuggo allapotot (vagyis amikor epp le van szakadva valamelyik nodegroup aktiv linkje, de meg nem allt at a group a backup linkre). Ez nyilvan teszteles kerdese is, de nem megoldhatatlan feladat.
--


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

"A 16 pécé lassabb, mint a mainframe (a mainframe gyors)?

Egyértelmű igen.. főleg, ha Mainframe-re is optimizálták a kódot ( tekintve, hogy a mainframe-eknek vannak olyan belső utasításaik amivel elég durva sebességnövelést lehet elérni, viszont x86 hírből se hallott még olyanról..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem szamit. Egy 10-20 eves mainframe nem ellenfele egy mai x86 clusternek semmilyen szinten (ar, teljesitmeny). Elismerem, ha olyan ratyi szoftver fut rajta, amit valami regimodi gyepesagyu tervezett, es abszolut nem hibaturore lett kialakitva, akkor kell a mainframe megbizhatosaga.

De a mainframe-nel sokkal olcsobb/egyszerubb sima off-the-shelf HA megoldasokbol osszerakni egy hibaturo clustert. Nem is szolva, hogy utobbi esetben foldrajzilag is eloszthatod a node-okat, ami egy mainframe-nel nehezkes/draga.

Ki beszélt itt 10-20 éves Mainframe gépekről?? Én azt mondtam, hogy ha megnézed, hogy egy MAI mainframe mennyibe kerül, és annak az áráért nézel össze hasonló teljesítményre szánt PCket, akkor hiába lesz jóvalta több PC-d, és jóvalta több Mhz-d is, attól még a Mainframe teljesítménye simán oda fogja vágni a teljes PC-vel kiépített clustered teljesítményét. És lehet hogy a kódnak még nem is kell Rexx-ben íródnia :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nekem az openoffice hirtelen nem akarja megnyitni a discounted_ibm_mainframe_pricelist.xls-t. Mondanál árakat a sajátodból?

A register szerint egy z10 BC induló ára 100e USD körül van, míg egy EC-é 1 milliónál indul, de könnyen felszaladhat 30-40 millióig (majdnem tízmilliárd forint!).
Azon most hirtelen elgondolkoztam, hogy van-e értelme ilyen gépeknél listaárról beszélni, hiszen nincs lista, ezeket nem onnan szokás megvenni.

Hát nem tudom.

Találtam nagy nehezen egy power estimator táblázatot, ahol a legkisebb konfig (4 CP, 16 GiB RAM, lényegében a táblázat csak ezekben változik) 5498 wattot eszik. Ezt sem tűnik túl nagy kihívásnak megverni, ennyiből kijön a 16 darab PC, egyenként 16 GiB RAM-mal, és 2xnégymagos, minimum 3 GHz-es CPU-val.

Összteljesítményben szerintem nem lehet kérdés, a kérdés az, hogy az alkalmazásod képes-e kihasználni a teljesítményt.
De ugyanez a mainframe-nél is kérdés, több (ráadásul speciális) processzorra skálázódni még ma is kihívás.

"Mondanál árakat a sajátodból?"
Nem vagyok én sales-es, hogy ilyen információkkal rendelkezzek :) Mindenesetre a listaárazásnak tényleg nem sok értelme van.. Főleg, hogy a nagyobb mainframe gépeket nem is igazán eladni szokták, hanem bérelni.

Mindenesetre ha valaki tényleg venni akarna egy mainframe-et, akkor aláírom, hogy azonos árból jópár PC-t vethetnél teletömve ram-al, meg számítási kapacitással. Ám még így is tartom a véleményem, hogy a Mainframe-et nem véletlenül használják a mai napig, hisz alapvetően erre lett kitalálva => nagy erőforrásigényes alkalmazások/rendszerek kiszolgálására.

"Összteljesítményben szerintem nem lehet kérdés, a kérdés az, hogy az alkalmazásod képes-e kihasználni a teljesítményt."

Ezt bármelyik másik alkalmazásról is elmondhatod. Hiába teszel über-brutál vasat egy app alá, ha az rosszul van megírva, vagy akár rossza paraméterekkel van fordítva ( és így optimizálva is )

"több (ráadásul speciális) processzorra skálázódni még ma is kihívás."

Még mázli, hogy ezt a mainframe alapból tudja :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"Még mázli, hogy ezt a mainframe alapból tudja :)"
vs
"Ezt bármelyik másik alkalmazásról is elmondhatod. Hiába teszel über-brutál vasat egy app alá, ha az rosszul van megírva, vagy akár rossza paraméterekkel van fordítva ( és így optimizálva is )"

Tehát a mainframe alapból képes bármilyen szarul megírt alkalmazás teljesítményét az egekbe tornászni?
Vagy nem?
Vagy mit is akarsz mondani?

Mitől képes (hardveresen) jobban skálázódni egy mainframe, mint egy infiniband fabricben összedrótozott PC-k serege?
Legalább egy architektúra ábrát linkelj pls. :)

"Tehát a mainframe alapból képes bármilyen szarul megírt alkalmazás teljesítményét az egekbe tornászni?"

Félreértesz.. Azt mondtam, hogy ha egy kód xarul van megírva, vagy forgatva egy adott platformra, akkor persze, hogy nem fog olyan sebességgel futni, ahol ez adott ( ergo ha a 2 rendszert ( jelen esetben PC-cluster Vs Mainframe ) összehasonlítod, akkor persze, hogy nem fogsz normális eredményt kapni, csak az optimizált esetében.

Amúgy a skálázhatóságot arra értettem, hogy a gépben elhelyezett erőforrásokat dinamikusan tudod hozzáadni/elvenni a host-tól. Alapvetően a mainframe-eken nem csak 1 rendszer szokott futni, hanem jóvolta több, amik közül mind1iknek megvan a saját profilja, melyben definiálva van, hogy az összes erőforrásból mennyit kaphat meg a host.. Na ezt viszont dinamikusan tudod változtatni ( kb mint az LVM-nél az LV méretét ), persze csak míg fizikailag a HW adott.. Amennyiben az se lenne elég akkor is adott viszont, hogy bepakolnak a gépbe még HW-t, majd aztán azt allokálják a host-hoz, vagy összekötnek 2 mainframe gépet, és onnantól ismét csak ki lehet osztani az erőforrásokat.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Stimt.. De a kérdés az volt, hogy a mainframe skálázhatósága felérhet e egy linuxos géppark skálázhatóságáig.. válaszom igen.. Ehhez jött még, hogy amúgy még van 1-2 olan plusz is a mainframe-ben ami linuxban még 1 jó ideig szerintem nem lesz ( microcode, megbízhatóság 1 (!) gépen belül, erősebb számítási kapacitás, jobb virtualizációs támogatás )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Egyrészt a Linux és a PC csak példája volt a minél olcsóbb, de még igen jó teljesítményt (mind megbízhatóság, mind sebesség) adó rendszernek.
De nem ez a lényeg, hanem az elosztottság, a modularitás, a standard komponensek és interconnectek, és persze az, hogy az alkalmazás maga is erre van tervezve.

Ezzel az elmélettel csupán annyi bajom van, hogy elmélet, míg mainframe-nél meg valóság.. Ráadásúl ha tényleg csak azon vagy fennakadva, hogy mennyibe fáj ez neked/a cégednek, és ezen akarsz ezzel a megoldásal spórólni akkor meg szintén le vagy tévedve, mert senki nem mondta, hogy azt a nyamvadt Mainframe-et meg kell venned.. Nyugodtan köthetsz szerződést a support céggel, hogy neked nem kell a vas, csak a teljesítmény, és akkor kapsz egy olyan gépet, amit te kértél, annyi memmel, procival ( avagy számítási kapacitással ) amennyit az adott pénztárca elbír, és lényegében mindenből annyit amit szeretnél. És akkor az olyan nagy gondok, mint HW problémák nyomban ki is esnek a körből, mert az üzemeltető majd törődik házon belül a HW problémákkal.. És itt meg már tényleg olyan szerződést küzdesz ki magadnak amilyet szeretnél, és innentől már hosszútávon szerintem tutira jobban megtérül a pénz, mint a te általad felvázolt verzió ( és még mindig stabilabb, mint az agyonclusterezett,jóval gyengébb szerverek, tekintve, hogy ez már jó ideje kiforrott )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én meg azt mondom, hogy lehet, hogy lesz belőle valami, de azt a teljesítményt, hibatűrést, és biztonsági szintet akkor se tudják elérni majd az ilyen osztott rendszerek, mint egy mainframe.. Lehet hogy majd a KKV-knek jól jön ( szívjanak vele ők, ha akarnak :)) hogy 'occóért lehet egy arányaiban hasonló rendszerük, de ettől még a világmegváltás szerintem elmarad :)) Akinek meg ez nem jön be, az meg marad a már amúgy is bevált mainframe-nél ( ezek valszeg meg amúgy is nagy cégek lesznek )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A cégek profitmaximalizálásra törekednek. Azt meg azzal lehet elérni, ha nagy tömegben gyártott dolgokat tudnak eladni. Ha közelítik a mainframe-eket a tömegtermékekhez, olcsóbban adhatják őket, vagy nagyobb nyereséget realizálhatnak rajtuk.
Gondolom ilyen irányt sem látsz.

Félreértesz.. Azt mondtam, hogy a közelítés ( ami ugye sose egyenlő a viszonyítási alap szintjével ) sok nagyobb cégnek nem lesz elég, mert még mindig hiányozni fog egy olyan dolog amit az nem tud, és valszeg jó ideig nem is fog tudni.. Most is összerakhatsz egy linuxos gépeket tömörítő számítási clustert de a teljesítménye fele akkora nem lesz, mint egy azonos összegből kihozott mainframe-nek ( És épp ezért nem látom benne a realitást) . És pont a nagy fokú elosztottság miatt nem fognak tudni majd az ilyen nagyon elosztott rendszerek versenyképesek maradni sok mainframe-el szemben, mert akinek tényleg kell az amit tudnia kéne, az rá lessz kényszerülve, hogy megvegye a mainframe-et.
Azoknak a cégeknek, akiknek ez nem szempont, azok meg majd eljátszanak ezekkel, de őket nem sorolom a komoly kategóriába (ezekre mondtam a KKV-t )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Bra, nem szabad elfelejteni azt az orokervenyu mondast, hogy mindig a cel valaszt eszkozt, es nem pedig forditva. Nem ertek a mainframe-khez, de tuti van olyan feladat, amit azon celszerubb megoldani, espedig nem azert, mert a megvalositas arra lett megirva.
Olyan ubermegoldas, ami mindenhova, mindenkinek jo, egyszeruen nem letezik, mert elteroek az igenyek.
Arrol nem beszelve, hogy egy clusternek van am management overhead-je is, es esetleg nagyobb, mint egy mainframe-nek. Lehet, hogy valahol ez is szempont.
--


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

Lehet, de erre mondom, hogy a PC-k gyors összedrótozásával (szerintem) ez is megoldható, ráadásul egy jóval skálázhatóbb rendszert kapsz.

És jelen pillanatban semmi akadályát nem látom (de cáfolj meg) annak, hogy egy node-ként működhessen sok kernel, közöttük egy gyors interconnect technológiával.

Ez az igazi plug-n-play, rádugsz a switchre egy mozdulattal 32 új gépet, a rendszer észreveszi, és már be is csattant 384 új processzor (mag) a rendszerbe. :)

Tényleg, hírből sem hallottam még olyanról, hogy ezeket valaki értelmesen összehasonlította volna.

És való igaz, az, hogy a mainframe-ekben speciális (vagy éppen kutya "közönséges", csak más mikrokódot futtató) processzorokat használnak bizonyos feladatokra teljes mértékben megoldhatatlan PC-n.
Hiszen ki hallott már olyanról, hogy egy Xeonba, vagy Opteronba más mikrokódot is lehessen tölteni, vagy hogy a hypertransportra Opteron helyett más, célprocesszor kerüljön, vagy hogy otthagyva ezt a témát speciális feldolgozóegységek végezzenek speciális feladatokat (TOE, SSL offload, GPU-k használata stb).

x86-nál arról se lehet nagyon hallani, hogy dedikált CPU-ja van 1 külön tasknak ( és itt nem OS oldali taskra gondolok, hanem mondjuk HW szintű terheléselosztásra ). Az, hogy ezekhez külön microcode van.. és? BIOS is lényegében egy microcode.. azt is néha frissíteni kell. .Annyi a különbség, hogy ezt a legtöbb HW-re átültették, hogy a jövőben akár még többet is ki tudjanak belőle hozni..

"vagy hogy otthagyva ezt a témát speciális feldolgozóegységek végezzenek speciális feladatokat"
Ez mainframe-nél is megvan, csak ott a gépen belül.. Sok HW-k számára szükséges funkcióhoz dedikált HW van, ami csak azért felelős, hogy azt ellássa.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

de a power6 tud decimalis lebegopontos szamokkal szamolni hardverbol (ezt olvastam) mig a xeon nem :) amugy ajanlom mindenki figyelmebe a spec.org-ot, ott az latszik, hogy 5 GHz-s power6 teljesitmenyben valamennyire tul is szarnyalja a 3 GHz-es xeon-t, legalabbis floating-pointban (mondjuk a fogyasztast nem irjak). Az 1.4 GHz-es ultrasparc T2-t viszont mindketto elveri mint buzi a faszat.
Csak hat arban gondolom a xeon sokkal kedvezobb (javitsatok ki ha tevednek).

u.i.: egyebkent engem is meglepett, hogy ennyire versenykepesek az intel konkurenciai, eddig ennek ellenkezojerol voltam meggyozodve, pedig neztem maskor is a spec.org-ot (csak ugy latszik nem jol).

- Use the Source Luke ! -

Miknek, az x86-os blade-eknek?

Nyilván lehet(ne) olyan, amiben pld EFI van, sőt olyan is, amiben Open Firmware. Vagy Simons' BASIC. Mégsem jellemző egyelőre. :)

Ezek hulla közönséges 8086 klónok attól, hogy egy kis dobozban vannak, 24 core van bennük, és 128 GiB memória...
http://picasaweb.google.com/nagy.attila/20090209Bl680c#5328349597668597…

igen az ibm bladecenter (vagy minek hivjak) gepekre vonatkozott a kerdes.
nyilvan igy van ahogy mondod, de ha efi lenne rajta lehetne vitatkozni, hogy ez nem pc hanem mac :), viszont a pc bios-szal ezen se lehet vitatkozni.

amugy kosz a kepet, mondom meg nem lattam ilyet

- Use the Source Luke ! -

Hát, ha van egy HA clustered, aminek az alkalmazás rétege kb fél óra-óra mire elindul, akkor nem mindegy, hogy milyen gyakran döglik meg.

Mondom jol lekezeli a hibat. Vannak erre megoldasok x86+linux-on is, ne rogton holmi drbd-re vagy linux-ha -ra gondolj (ami BTW az egyik legborzasztobb megoldas: nem a meglevo szoftver kore kell HA-t hekkelni, hanem kapasbol olyan architekturat kell tervezni, ami hibaturo).

Tipikusan varnish+memcached+vmi okos mysql backendnek szokott mukodni. A lenyeg, hogy 1 node kiesese eseten a tobbi node barmifele extra konfig nelkul atveszi a feladatait.

"BTW, megbizhatosag, mint olyan, amugy is felesleges a clusterek vilagaban. Ha van 16-64 vasad, akkor bizony valamelyik EL FOG ROMLANI. Pont."

Ez nem mindig ilyen egyszeru, a valo vilagban a hibak ravaszak, es direkt ki akarnak szurni az emberrel. :)
Nem mindegyik hibabol lesz kernel panic, van amelyik csak szep csendben data corruption-t okoz kb. havonta egyszer.

Egy munkatarsam meselte, hogy egyszer regen valami banki szoftvert fejlesztettek PC-re. Ott alkalmaztak azt az eljarast, hogy minden tranzakciot, es az egyes szamlaegyenlegeket is kulon taroltak, zaraskor pedig replay-eltek a tranzakciokat, es megneztek, hogy a ket vegeredmeny egyezik-e. Atlagban havonta 1-2 esetben talaltak igy elterest.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Vagy nem.

Még az is lehet, hogy az Oracle kukázza a Linuxot és rágyúr az x86-Solarisra, elvégre most már házon belül van, és a Nehalem egy baromi ütős architektúra lett. Azért sok enterspájz fícsörben nincs még ott a Linux, mint a Solaris (próbáljunk normálisan clusterezni pl., haha).

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Posvány, pénztemető. A cluster és a tandem (a locksteppinggel) is az önmagukban hibatűrő működésre képtelen alkalmazások kisegítésére való.

Maguk a megoldások (vagy hívjuk workaroundnak, mert ezek végülis csúnya hackek) végülis brilliáns elmék munkái, amelyekre persze az égvilágon semmi szükség nem lett volna, ha a lusta alkalmazás-programozók más csecsen nevelkednek, és nem mentik meg a seggüket a másik részlegen dolgozó kollegák.

Te lattal mar _tenyleg_ hibaturo szoftvert? Olyat, amelyik mezei PC-ken kepes megvalositani egy TMR rendszert, fel van keszitve a kulonbozo random data corruption hibakra a proci regisztereiben, cache-en, memoriaban, diszken, es kepes a hw-es megoldasokkal osszemerheto ideju failoverre?

En meg nem.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Nem láttam, de mivel nem is ezen a területen dolgozom (és szakértője sem vagyok a témának), ez érthető is. De ebből ugye azért nem az következik, hogy nincs is, sőt elvileg sem valósítható meg? :)

Az általad említett hibák egy mainframe-nél is előfordulhatnak, hogy ezek mégse okozzanak problémát, megpróbálhatják rábízni magukat a hardverre (emelt RAS-képességek, amelyek (egy része biztosan, nem vagyok tájékozott az utolsó bitig) megvannak nem mainframe rendszerekben is (Itanium pld)), vagy ha az sem nyerő, alkalmazhatnak TMR rendszert.
Az viszont (javíts ki, ha tévedek) ugyanolyan, mint a ZFS esete a hagyományos megoldásokkal: a hagyományos megoldásoknál stackelve vannak a logikai rétegek (bitek diszkek közötti másolgatása, fájlrendszer stb), míg a ZFS ezt ötvözi, és végül egy jobb megoldás születik.
Azaz az, hogy egy mai TMR rendszer a processzorokat működteti lockstepben adott esetben három különböző helyén a világnak, egyesével léptetve mindegyiket, valójában nem értve, hogy mi is történik biztosan gyorsabb, mint ha ezt szoftverből (pld. kernelben) akarnád megoldani, viszont biztos, hogy lassabb, mintha az alkalmazásba kódolod bele ezt a logikát, és annak a műveleti egységeit végzet ugyanilyen módon, megszavaztatva az eredményeket, és elvetve, adott esetben teljesen kizárva, vagy másikkal helyettesítve azt a kisebbséget, amely hibázik.

Az en fejembe valahogy nem fer bele, hogy a a felhasznaloi programnak kellene biztositania a hibaturest - ez kicsit olyasmi, mint ha a raid-et ki akarnank dobni, es mostantol minden programnak 2 peldanyban kellene irnia a file-jait a kulonbozo diszkekre.
Az mar jobban hangzik, hogy ezt a feladatot egy, az alkalmazas alatti sw-reteg (pl. VM) csinalja, de nekem inkabb ez tunik hacknek: sw-bol kuzdunk olyasmivel, amit hw-ben sokkal egyszerubben, gyorsabban, es elegansabban meg lehet oldani.

"ebből ugye azért nem az következik, hogy nincs is, sőt elvileg sem valósítható meg? :)"

Azert legalabbis furcsa, nem? :)

"viszont biztos, hogy lassabb, mintha az alkalmazásba kódolod bele ezt a logikát"

Miert lenne lassabb? Egy komparator aramkor meglehetosen egyszeru dolog, a vegrehajtason gyakorlatilag semmit sem lassit, es ha instruction retry jon, akkor minimalis az a munkamennyiseg, amit ki kell dobni.
Nem igazan latom, hogy a sw-es megoldas mit tudhat, amivel ezen gyorsitani lehetne.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A szoftveres megoldás úgy vélem azon gyorsíthat, hogy teljes mértékben érti is a feladatot. (erre hoztam a ZFS-es példát)
A komparátor áramkor hiába nem lassít semmit, ha az eredményeket egy három különböző kontinensen lévő (extrém példa, de a mainframe erről szól, nem? :) kupac próbálja rendben tartani.
A fény sajnos igen lassú.

"A szoftveres megoldás úgy vélem azon gyorsíthat, hogy teljes mértékben érti is a feladatot."

Ezt ertem, azt nem, hogy ezen informacio birtokaban pontosan hogyan.

"erre hoztam a ZFS-es példát"

Ami nem egeszen jo, mert a ZFS nem felhasznaloi program, hanem az alatta levo retegek kozul nehanynak az osszevonasa.

"A komparátor áramkor hiába nem lassít semmit, ha az eredményeket egy három különböző kontinensen lévő (...) kupac próbálja rendben tartani."

Ennek igy semmi ertelme, miert akarnak szetdobni 3 kulonbozo kontinensre?
Az integritas akkor is biztosithato, ha az a 3 processzor egymastol 10 centire van, a DR-hez meg nem kell a lockstep.

" (extrém példa, de a mainframe erről szól, nem? :)"

Nem, errol pont a masik oldal, az elosztott rendszer szol.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Én azt tippelném, hogy egy hibatűrő alkalmazást írni valószínűleg nem egyszerű, és feltételezem, hogy annyival több pénzbe és időbe kerül, hogy ezért oldják meg inkább hardtverből.

Van, ahol meg ez nem megy, pl. úgy tudom, az űrtechnikában nagyon csúnyán hibatűrő programokat készítenek. Legalábbis a főiskolán azt mondta valami tanár, hogy az ada nyelvet pl. azért használják erre, mert azzal milyen jó hibatűrő rendszereket tudnak készíteni...

G

Igaz, de ez fordítva is így van:

készíthetsz egy hibatűrő gépet, amire bármi szoftvert lehet tenni,

vagy készíthetsz egy nem hibatűrő gépet, hibatűrő szoftverrel.

Te azt mondod, a szoftvert egyszer kell megírni, a hw bonyibb.

Szerintem a hardver tényleg bonyolultabb, de azt tényleg egyszer kell elkészíteni. A szoftvert meg szerintem nem. Egyfelől nem egy darab szoftver fut a gépen, másfelől a szoftvert szokták fejleszteni általában. Bővítik, javítgatják.
Persze nem lehetetlen megcsinálni jól, de fenntartom: biztosítani kellene, hogy az összes szoftver hibatűrőre legyen tervezve (és megvalósítva), és toldozás-foldozás közben se kefélje el valaki, aki csak egy bug javításán dolgozik, nem látja át az egész rendszer, és a főnöke üti a fejét, hogy legyen kész estére.

Nem mondom, hogy lehetetlen. Sőt, én inkább a te nézetedet osztom: a clusteres PC-kből összerakott nagy izomgépek most is léteznek. Azt nem gondolom, hogy minden feladatra jó egy ilyen (hisz nem is minden feladat párhuzamosítható)

De úgy gondolom, hogy egész egyszerűen a szoftver fejlesztés nem annyira megbízható folyamat, mint a hw fejlesztés. Persze ez akár változhat is a jövőben, tudom. Igen. :-)

G

Sajnos hardverben is nagyon sokszor előfordulak hibák. Akár egy számítógépes processzort is korrekten letesztelni bonyolult feladat.
Hardver esetén is nagyon sokszor jelenik meg új revízió, ami tulajdonképpen az előző javítása.

Ha azt vesszük, a technika fejlődését továbbvinni a megalkotott hardverbe (pl. nem 8086-os processzorokból rakunk össze szuperszámítógépet) szintén plusz feladatot jelent. Lehet, hogy (jó- kevésbé jó) szoftvert hardverrel ellentétben szinte bárki megalkot, utóbbi esetén pedig mindez sokkal több pénzt emész fel és ritkábban történik (ill. talán pont az előbbiek miatt jobban kigondolt, megtervezett megoldásokat kapunk).
ill. egy esetleges hibával sorozatgyártásba került alkatrész/rendszer miatt főhet az "ember" feje...

- Ha arról van szó, egyfajta teszt fázis folyamán felmerülő, működést lényegesen befolyásoló hibákat még azelőtt javítják, hogy sorozatgyártásba kerülne a hardver, szoftver esetén pedig a kevésbé üzembiztos kódot is kiadják stabilként, mert közvetlen anyagi költségként nem jelentkezik és megintcsak nem a legegyszerűbb mindenre kiterjedően tesztelni.

Szerintem csupán ez okozza a lényegi különbséget.

A csudába. Vehetem elő a Gimp-et újra :DD

--
trey @ gépház

Nagyon kíváncsi leszek, mi lesz a dolog vége. A Sun jónéhány olyan dolgot adott, amiért kár volna, ha süllyesztőbe menne, ugyanakkor pedig jónéhány bukott dolog is van. Hogy melyik vonal marad? Majd az idő eldönti.

Jelenleg az Oracle leginkább a Linux-ot nyomja OS-nek. (lásd: Linuxra jött ki először a 11g, és a majd minden patch is arra jön ki először). Vajon ez után átállnak a Solarisra? Ha már házon belül van...
Illetve mi lesz a Oracle unbreakable Linux-al?

Majd az idő eldönti, de nagyon kíváncsi leszek rá

---
Ubuntu 8.04 LTS

Innen:

The Sun Solaris operating system is the leading platform for the Oracle database. 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.

...

Will the ownership of Solaris change Oracle’s position on Linux?
No. This transaction enhances our commitment to open standards and choice. Oracle is as committed as ever to Linux and other platforms and will continue to support and enhance our strong industry partnerships.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

"Fujj MySQL; remélem, dobják a MySQL -t, stb."
Érdekes dolgokat szűrtök le, illetve reméltek, ahhoz képest, hogy a weboldalak közül rengeteg (kb min. 2/3 része) használja egészséggel.
Be is kellene tiltani, nem?

kötöjelkötöjel
Pedig ez nem az!

ahaha nem is tudtam h adatbazis expert is lettel

mondjuk ahol eleg a select * from gayporno where user like '*linuxusers*'; oda telleg felesleges is volna barmi mast rakni mint mysql. ez lehet h a web3.0as drupal egine hasznalok 90% at kielegiti de azert ne ebbol vonjuk mar le messzemeno kovetkezteteseket arrol h mennyire jo az adatabaziskezelo, mondjuk en inkabb OpenExcel-nek szoktam hivni mert olyan kepesegekkel rendelkezik a majkremsql.

--
.

basszus, most akarok solaris-ból vizsgázni... kicsit elgondolkodtat, hogy megéri-e pénzt+energiát fektetni

Ezt írja? A verzióbuzi Solaris x86-ot használó (mondjuk el nem tudom képzelni ki az az őrült, aki Solaris x86-ra Oracle-t tesz) lúzerek biztos tűkön ülve várják már a 11g-t. :)

De lehet, hogy pár 10g patchre is úgy vágynak már, mint más egy falat kenyérre (nem tudom, nem követem, csak hallok innen-onnan hasonlókat)...

"Ahogy a FAQ-ból kiderül, a Solaris lesz az Oracle elsődleges platformja."
"The Sun Solaris operating system is the leading platform for the Oracle database"

De ha jól látom nem csak én gondolom úgy, hogy ez ebben az állapotában sehol sem jelenti azt, hogy ezután a Linux helyett a Solaris előtérbe kerül.

Persze. Solarist rengeteg helyen használnak még most is, bankok, telekomok stb., és fognak is még. Ha Linux mellett Solarishoz is értesz, akkor csak megnöveled az esélyeidet, hogy kifogj valami jó állást.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

a helyzet az, hogy a FAQ szerint: "The Sun Solaris operating system is the leading platform for the Oracle database"
IMHO a jövőre nézve nincs utalás

Cisco szerver,Oracle processzor ... hova jut a világ ...

Fura, hogy mindenki a mysql-en rugozik. Mi lesz az openoffice-szal? Arra mi szuksege lesz az Oracle-nek?

a jre telepítője már szép piros :D (a jdk-é valamiért még nem)