Ausztrál cég Linuxról Windowsra váltott

Linux

Az ausztrál Crest Electronics tavaly Linuxra helyzete a vállalati rendszerét, majd hét hónappal később Windows-ra váltottak. Az ok: kisebb TCO. A cég IT vezetője szerint az ok szigorúan üzleti volt.A cég audio és video kellékeket forgalmaz Ausztrália-szerte. Tavaly novemberben migrálták az SAP-s rendszerüket Red Hat Enterprise Linux 3.0-ra. Annak ellenére, hogy a SAP által megkövetelt Linux verziót, és az SAP által certifikált IBM vasat használták, problémáik (stabilitás és a frissítés bonyolult volt) voltak. Ezért úgy döntöttek, hogy Windowsra váltanak.

A problémákat a helyi Red Hat képviselet próbálta volna elhárítani, de az ügyfél szerintük ebben nem volt partner.

A cég nem szakított teljesen a Linuxszal, mert a webszerverén továbbra is az fut. A IT vezető szerint a Windows neki jobban megfelel, mert a Windows Update-tel könnyebben tudja frissíteni és kisebb a TCO-ja, mert a Linuxban megbúvó szupport költségek vannak.

A cikk itt.

( Nagyapa | 2005. 09. 29., cs – 21:49 )

Háát, nem tudom, de a mi cégünknél a SuSE 7.1 óta Linux van.

" a Windows neki jobban megfelel, mert a Windows Update-tel könnyebben tudja frissíteni és kisebb a TCO-ja"

Ehhez csak annyit tudok hozzáfűzni: :-D

Csak azt kérdezném tőle, hogy a vírusok, férgek, spyware programok miatti leállás avagy a hibás frissítések miatti kiesések, ezek mennyi költséget emésztenek fel?

Ugyanis ezekről "mégcsak nem is hallott" egy Linuxos rendszergazda! Nemhogy szinte napi szinten gyakorolná!

Csak egyetlen hír, amely bizonyára nem egyedi problémát vet fel: http://www.sg.hu/cikkek/34662

"Windows-hiba a Brit Munkaügyi és Nyugdíj Hivatalnál" Igaz e cikk lassacskán egy éves, de bármikor előfordulhat hasonló hiba. Vagy netán utópia lenne?


Bizonyára a mi kis 30-50 fős cégünknél nagyobb anyagi "tartalékok" vannak a "magas" TCO-ra, vagyis több a magyarok pénze mint a szegény ausztráloknak.

:)

Ezért is nyert teret a Linux :-)

>> Ehhez csak annyit tudok hozzáfűzni: :-D

mikozben te kineveted, neki mukodik az sapja, olyan rendszere van, ami jobban megfelel neki, es szamitasai szerint csokkent a tcoja. mekkora lamak, nem? kuldhetnel nekik sikertortenetet, hogy a vasaggyal egyutt 30-50 fos cegednel hogy hasit az sap suse71 folott

( wry | 2005. 09. 30., p – 03:16 )

135 hozzászólás nem kispálya.. de a saját itteni (.au) tapasztalataim alapján ez abszolút nem meglepő, ami történt.

valaki fentebb írja, hogy a RedHat-ék lehettek volna ügyesebbek is, azonban azt hadd jegyezzem meg, hogy a cikkből kiderül - a RedHat-nak _nem_ adta meg a cég a lehetőséget, ugyanis (idézet a RedHat emberkétől):

"We asked the customer to do a diagnostic test and the customer never responded, so it was impossible for us to address the issue,"

tehát _nem_ derül ki pontosan mi volt a hiba, így pedig lehetett akár h/w hiba is de akár az is lehet, hogy a hiba nem is létezett.

ausztráliában nem ez lenne az első "eltaposom a microsoft ellenfelét, hátha kapok egy előnyösebb ajánlatot windowsra" téma (lásd: Telstra és Sun JDS).

Tudtam, hogy nem hagyod ki :-)

Csak a szokatlan "bőbeszédűség" az ami meglep...

Kár, hogy nem írtad le, hogy mire gondoltam még vagy mit felejtettem el leírni.

Ugyanis a "kollégáknál" ez szokás.

Bizonyára 22:29-kor már túl álmos lehettél, hogy a cégemnél sap-ról olvastál :)

Csak úgy mellékesen. Van egy "jótanács" amit szoktam alkalmazni és másnak is bevált már. Így hangzik: "Ne olvas bele olyat a sorok közé ami nem oda való"

Hidd el megéri alkalmazni :-)

Ja és egyáltalán nem mellékes, hogy mikozben te irkálsz nekem ezt-azt, a cégünknek olyan rendszere van, ami jobban megfelel neki, es szamitasai szerint csokkent a tcoja. mekkora lamak, nem?

Köszi, hogy elolvastad :)

((U.i.: Várom a többi "kolléga" elmés megjegyzéseit is, bár v.színü, hogy nem fogom végigolvasni))

" Az általánosításod nem ér semmit. "

? ? ?

Mi van? Egy adott zárt forráskódú terméket, csak a gyártója írhat át más oprendszerre, vagy a gyártó álltal feljogosított cég. Oracle-t csak az Oracle cég engedélyével írhat bárki akármilyen platformra.Ugyanez áll SAP-ra, és akármi másra. HASONLÓ, vagy vele kompatibilis cuccot te is írhatsz, ha elég okos vagy, de azt nem nevezheted el Oracle-nek, SAP-nak vagy akármi másnak amit lemásoltál.

Ezek szerint nem értettem a viccet. :(

"Na, mikor is foglalkozott veled a Microsodt kernel-engineering csapata? "

Ki a f@sz beszélt a Microsoftról?

Volt a cikkben leírt esethez hasonló problémám, és igaz 2 hónap kellett neki, meg a Sun6900-as szervert tervező mérnökök, és 1-2 kernel specialista bevonása, de megoldódott a probléma.

"Szerinted a nyílt forrás fejlesztői hallani sem akarnak rólad?"

Igen, ha fizetek Linusnak egy rakat pénzt, hogy soron kívül keressen meg és javítson nekem egy kernel bugot. Egyébként meg várhatok türelemmel a következő kernel patchig, vagy verzióig, és bízhatok benne, hogy megszűnik a probléma.

Vedd már észre, hogy a nyílt forráskód, a Linux és a Support szerződés három különálló fogalom.

Ha a RedHat-nál van egy rakat jó specialista, és köthetsz velük support szerződést is. Ebből a szempontból nincs sok külömbség köztük és a zárt kódú oprendszereket kínáló cégek között.

Az ausztrál esetet meg beszopták, ennyi. Le lehet vonni a tapasztalatot, és lehet javítani a support minőségén.

> khm ez egy luf@sz load. Szorozd meg 5-el és akkor már valami

Csak azt akartam prezentálni, hogy nem 0.002... :-) Amúgy jó, akkor idehazudok valamit, hogy jobbnak látszódjon:

09:29:44 up 50495 days, 20:59, 20415 users, load average: 4123330.05, 2323230.12, 11122230.19

Így most jobb Neked? :-)

>Várom a többi "kolléga" elmés megjegyzéseit is, bár v.színü, hogy nem fogom végigolvasni)

Barátom, te csak egy szűk látókörű demagóg emberke vagy. Ha még nem lennél 25 éves, akkor van esélyed. Ha már elmúltál 35 akkor inkább próbálkozz salátatermesztéssel, ne informatikával.

Átlagban az a poén, hogy ha valamiben nem ért valaki velem egyet (itt), attól még mindketten tudjuk a választ az adott kérdésben, csakhát amíg valaki mindemellett úgymond "objektív" nomeg "nyílt forráspárti" (-nak akar látszani) addíg nekem olybá tűnik a hozzászólása, hogy támogatja a "Nagy Monopol"-t.

Persze ez már biztosan csak beképzelés nálam :-D

Mindenesetre elég fura ha a pcforum.hu/prog.hu helyett a HUP-on védi meg valaki 'késhegyig menően' a Win vagy akár az M$ "becsületét" (volt ilyen, nem1 eset)

Bocs....... "..." egyáltalán van ilyen még "nekik"?

( aries | 2005. 09. 29., cs – 08:31 )

Talán ha értene hozzá a T. kolléga, nem kellene a supportot hívogatni. Ha a fejlett országok ezt a mentalitást folytatják, akkor 10 év múlva már csak szép emlék lesz a gazdasági növekedésük.

nos, eloszor talan el kene olvasni a cikket.

senki nem mondta, hogy jobb a windows update.

ket dolgot emelnek ki a cikbbol:

Mr Horton called in Red Hat-recommended contractors to install Red Hat Enterprise Linux and ensure it was configured according to SAP standards, a process which took two weeks.

"You have to be using the right certified components, otherwise SAP won't give you the support. To go through and match everything off was quite tedious," Mr Horton says.

illetve:

Red Hat Australia's Mr McLaren says there is no risk of losing vendor certification if an organisation enables auto-patching on Red Hat Enterprise Linux. "Every patch goes through our engineering and quality testing, which involves certification by the vendor. It absolutely doesn't invalidate the support from the software vendor," he says.

Mr Horton disagrees: "It might be fine for things like security patches, which don't impact SAP certification rules but with some patches you still actually have to check the release levels and then check against the SAP site. Otherwise SAP might ask you to roll back to the previous version before they will support it."

Tallán ha ólálkodtál volna nagy vállalati adatközpontok környékén, akkor tudnád, hogy a support az egyik leglényegesebb eleme az infrastruktúrának. Egy Linuxos rendszergazda sem mindenható. Ha egy problémát meg kell oldani adott időn belül, akkor nem megoldás, hogy fórumokon és levlistákon összevadássza a megoldást az ember. Biztos vagyok benne, hogy te meg tudsz oldani bármilyen problémát akár 1-2 napon belül, de ha van rá 1-2 órád, akkor mit csinálsz? Supportnak van egy olyan jó tulajdonsága, hogy minden probléma eszkalálható magasabb szintre, és szükség esetén lényegesen több ember tud dolgozni egy adott problémán, mint ahány rendszergazda van a cégnél.

( zwei | 2005. 09. 29., cs – 08:56 )

Ismét szép nagy vitának nézünk elébe . :)

( vomberg | 2005. 09. 29., cs – 09:09 )

1. Akkor ez most az SAP sara vagy a Red Hat-é?

2. Mi volt a konkrét probléma? Mi a francnak kell annyit frissíteni? Ez nem egy unstable desktop rendszer...

3. Milyen stabilitási gond volt? A Linuxszal kapcsolatban a stabilitás szokott a legritkább problémaként fennforogni...

Na, azt nem hiszem hogy az MS support jobb, mint a RedHat support Ausztráliában.

Az igazi ok szerintem a megszokás és a kényelem. Az elején szembekerültek néhány nehézséggel és feladták.

Akkor persze nem sírtak-ríttak, amikor még DOS-al dolgoztak. Az MS ereje az alá dolgozó hardver- és szoftvergyártókban van.

Nem hiszem, hogy a stabilitással valódi gondjaik lehettek. Az már lehet, hogy a RedHat szarul írta meg az SAP klienst.

( anr | 2005. 09. 29., cs – 09:14 )

hat igen. van kulonbseg a kis/kozepes ceges rendszer meg a nagy ceges rendszer kozott.

Minden informatikai ceg nagy cegbol szeretne elni, es support cimszoval milliokat huzni le rola:) szernitem itt a konkret esetben egy kicsit elszallt a helyi redhat support szerzodott partner.

az is latszik, hogy a megrendelo egyaltalan nem akarta maga cisnalni a dolgot. Ot a SAP erdekli az oldja meg a gondjait, gondolom SAP-os kepzest kapott emberei vannak, z, hogy mi fut a SAP alatt szamara erdektelen.

"After calling in IBM to ensure the hardware wasn't at fault, Mr Horton called on support from Red Hat Australia. Despite Red Hat's efforts to fix the problem, seven months after installing Linux, Mr Horton was forced to switch to Windows."

ebbol szamomra az tunik ki, hogy nem is deritettek mivel volt a gond. Az IBM-esek ki sem mentek. Meg az is lehet, hogy hardver hiba volt, gondolom hozott az IBM egy ugyanolyan szervert preinstalalt win-el. Minden szerver "osztalyban" az adott nagy hardver gyarto ceg legkisebb szerverei legalabbis erdekesek. rengeteg hibat hallotam roluk, es a nagy cegnel a default valasz: vegyel nagyobbat, az jobb:)

Ez van a havorukban vannak vesztes csatak is.

ennek a tapasztalatnak _nincs_ informaciotartalma a kis/kozepes, es a szupernagy (akik maguk csinaljak a rendszeruket: google, akamai,yahoo,...) cegek fele.

"... we came to a very interesting situation where the machine would basically, putting it in Windows terms, core dump or blue screen at random. It would run for weeks or so and then just bang, it would stop."

Magyarul pár hetenként a rendszer megzuhant.

A probléma pont az volt, hogy nem volt reprodukálható konkrét probléma. Sajnos komplex rendszerek esetén ez elő tud fordulni.

Üzletileg kritikus rendszerek security patchelése alap. Azért kell gyakran patchelni.

Azt ugyan nem értem, ha RedHat alatt nem használhatták az automatikus patchelést, akkor windows alatt miért használják?

> ebbol szamomra az tunik ki, hogy nem is deritettek mivel volt a gond. Az IBM-esek ki sem mentek. Meg az is lehet, hogy hardver hiba volt, gondolom hozott az IBM egy ugyanolyan szervert preinstalalt win-el. Minden szerver "osztalyban" az adott nagy hardver gyarto ceg legkisebb szerverei legalabbis erdekesek. rengeteg hibat hallotam roluk, es a nagy cegnel a default valasz: vegyel nagyobbat, az jobb:)

Az IBM mostaban (3-4 eve) horror. Es ezt nem azert mondom, mert HP-s vagyok :-)

( dejo v | 2005. 09. 29., cs – 09:20 )

Példa van erre is arra is.

Csak nem kell messzemenő következtetést levonni belőle.

Amikor a németek, franciák és különböző latin nyelcsaládhoz tartozó országok a Linux mellett döntenek, akkor jóérzés tölti el a szívünket és persze bosszankodunk, hogy Magyarországon miért nincs ez így. Amikor Linuxról vált valaki a redmondi termékre akkor meg letámadják őket egyesek, pedig egy cikk alapján nem tudhatjuk a konkrétumokat.

Én is szeretném ha a cégünk teljes egészében Linuxra állna át, de amíg nem lesz a King vagy egy azzal adat kompatibilis építőipari költségvetés készítő program, agddig ez esélytelen. De az MS dokumentumok és az OOo inkompatibilitása is nagy gond.

A szerveren Linux fut, de az csak nekem okoz fejtörést. Néhány érdeklődő kolléga gépén második rendszerként ott van a Linux is, de csak néha töltik be, mert az éles munkához nem tudják használni.

Szóval nem mindíg elhatározás kérdése a dolog, mert ha a Kinget ki akarnánk váltani akkor egyedi programot kellene fejleszteni, ami rövid távon nem kevés pénz. Hosszú távon meg nem lehet tudni, mert a Kinhez kellene igazítani folyamatosan.

Az MS dokumentum formátum és az OOo összeférhetetlensége, (nincs 100%-os kompatibilitás) pedig macera.

"szernitem itt a konkret esetben egy kicsit elszallt a helyi redhat support szerzodott partner."

ez a cikk melyik reszebol derult ki szamodra?

"az is latszik, hogy a megrendelo egyaltalan nem akarta maga cisnalni a dolgot. Ot a SAP erdekli az oldja meg a gondjait, gondolom SAP-os kepzest kapott emberei vannak, z, hogy mi fut a SAP alatt szamara erdektelen. "

nem latom, hogy ezzel barmi problema lenne. az ugyfelnek az az erdeke, hogy a huszonharmincezer-haromezer millio urdollarba kerulo rendszere mukodjon. nem mukodott. valtottak. es?

Ki beszél arról, hogy melyik support a jobb?

"Nem hiszem, hogy a stabilitással valódi gondjaik lehettek"

Olvasd el a cikket. De ha lusta lennél tájékozódni mielőtt véleményt alkotsz, akkor itt az idevágó idézet:

"... we came to a very interesting situation where the machine would basically, putting it in Windows terms, core dump or blue screen at random. It would run for weeks or so and then just bang, it would stop."

( jolle | 2005. 09. 29., cs – 09:26 )

Miert van az, hogy ha egy hirben szerepel az IBM neve, akkor nem lepodok meg semmin? Lehet oregszem :(

"Az már lehet, hogy a RedHat szarul írta meg az SAP klienst."

Figy, RedHat nem ír SAP klienst. Azt az SAP írja.

Egyébként itt meg SAP szerverről van szó, amit szintén a SAP ír.

Amúgy álltalánosságban: A kereskedelmi alkalmazások at leginkább az azokat fejlesztő cégek portolják adott platformra, és nem az oprendszer "gyártó" cégek.



"az is latszik, hogy a megrendelo egyaltalan nem akarta maga cisnalni a dolgot. Ot a SAP erdekli az oldja meg a gondjait, gondolom SAP-os kepzest kapott emberei vannak, z, hogy mi fut a SAP alatt szamara erdektelen. "

Meglepődsz, de a nagy cégek erősen támaszkodnak a supportra. Minek fenntartani 1-2, álltalános üzemeltetésre tökéletesen alkalmas rendszergazda helyett 5-6 vérprofi specialistát? Support egy bizonyos szint felett support akkor is kell ha tele vagy gugukkal.

>ez a cikk melyik reszebol derult ki szamodra?

a sorok kozott. egy problemat sokfelekeppen meg lehet oldani. a konkret eset megoldasi kiserleteinek leirasa alapjan ugy tunik, mintha az ugyfel a support ceg altal nyujtott szolgaltatas ar/ertek aranyat nemsokra becsulte volna. Nekem tobbszor bejott mar, hogy problema egy-egy megoldasaba rengeteg energiat fektettem. meg abba is, hogy pontosan megmondjam mi volt a gond. az ugyfel latja az eltokeltseget, a hozzaertest, megtudja azt is, hogy mi okozta ahibat (meg akkor is ha en voltam), es ugy gondolja, hogy jo kezekben vannak a cuccai:)

Ha a redhatosok kideritettek volna mi volt a gond, akkor za ugyfel utalt volna ra.

>nem mukodott. valtottak. es?

nem irtam, hogy barmi bajom lett volna ezzel az ugyfel magatartassal. logikus, ertheto. mindossze megmagyarazni akartam azoknak, akik ilyennel meg nem talalkoztak:)

Amikor egyetemistakent kikerultem dolgozni szamomra erdekes volt, hogy vannak emberek akiket nem erdekel hogyan/miert mukodik a cucc. De volt olyan megrendelom, aki viszont reszletesen elmondatta, mert szamara fontos volt, hogy akiktol legkozelebb ajanlatot ker ne tudjak megvezetni. ket nagyon eltero ugyfel hozzaallas mindegyik lehet sikeres. maskepp kell hozzajuk viszonyulni a szuportnak

zsirfeka:

"nos, eloszor talan el kene olvasni a cikket.

senki nem mondta, hogy jobb a windows update."

Elolvastam es tobbek kozott ezt lattam:

Crest Electronics is trialling Microsoft's Windows Server Update Service, which allows automatic patching for the operating system and other Microsoft software on servers and desktop machines across a corporate network. Its benefits are one of the key reasons why Mr Horton stands by his decision to switch from Linux to Windows.

Egyebkent igazad van. A cikk nem (csak) errol szol. Amennyire en lattam, az utobbi idoben az SAP sokkal inkabb a wint veszi alaprendszernek mint mast. Ez bizonyos szempontbol ertheto. Ket ilyen "nagy" ceg termeszetes, hogy konnyebben ossze tud dolgozni, es kevesebb lesz a kompatibilitasi problema (a javitasokbol adodo is) mint massal.

Azt is megertem, ha a vevo csalodott, hiszen eloszor o is Linuxot szeretett volna (habar mint mondta nem erdekli, hogy milyen oprendszer fut alatta, csak mukodjon a rendszer).

Ez van. Ez lehet akar tendencia is (SAP eseteben), de lehet egyedi eset. Egyelore nem lehet kovetkeztetest levonni belole. Valoszinuleg pl. az Oracleval nem ilyen gondok lennenek :)

Jah.

Mi alapvetoen IBM es HP dealer-ek vagyunk. Joval evi 100 feletti eladott szerver megy at a kezeink kozt. Pontos adatot nem tudok, mert nem vagyok kereskedo. Az is lehet, hogy szazas nagysagrendben tevedek minuszban. Ezeket telepitjuk, helyszinen uzembe allitjuk, es hosszu evekig szupportaljuk. 3 ev a gar ido, de nem csak hardveresen hanem szoftveresen is tamogatom oket. Van viszonyitasi alap.

En a HP-re eskuszom. Nekem szemely szerint hardveresen, szoftveresen, es szupport oldalrol is _sokkal_ jobb tapasztalataim vannak vele. Ugyhogy ha rajtam mulik, akkor az ugyfel HP vesz. Es aki azt vesz, nem is szokott valtani rola. :-)

Én pár évvel ezelött dolgoztam IBM "nagygép közelében". A helyi rendszergazda kommentárjával és saját magam is tapasztaltam hogy a nagyvason futó AIX folyton folyvást meghalt. Ekkor át kellett állni a tartalék gépre.

Jöttek az IBM-esek prücköltek rajta kicseréltek rajta egy-két dolgot, utána visszaállás 1-2 nap után megint behalt. Ez úgy ment 1-2 hónapig. Szerintem már IBMesek is vért izzadtak. Aztán kiderült a trafó zárlatos. Házcsere néhány százezer Ft.-ért és tényleg meggyógyult. Azt hiszem olyan középkategóriájú ügyfelek lehettünk. Mivel ha extrásabbak lettünk volna azonnal kicserélték volna az egész gépet. És jött volna az önfényezés, így csak kínos hallgatás. Azt hiszem a nagyobb gépek mítikus megbízhatósága is kicsit mítosz jellegű, a nagy merketinges nyomás alatt gyorsan szépülnek a gyártók-forgalmazók statisztikái;)

igen, ime egy kis izelito elore:

- miert nem hasznalnak inkabb pgsqlt es phpt?!

- a vi jobb mint az sap!

- freebsd mellett elmenne az egesz egy PI-133-on

- [random kekhalal vicc]

- bill gates lefizette ausztraliat es a redhatet

- hazugsag az egesz, nekem otthon stabil a linux

- lamerek, gentooval optimalizaltan tudtak volna sapt forditani

- az amiga mar 1980ban tudta

> ``The installation of SAP took two days on Windows, the installation on
> Linux Red Hat took two weeks.''
>
> Windows 2 nap, Linux ket het? Na ne... :-D

SAP esetén? Egy olyan terméknél, ahol a server oldali (Javan futó)
verziónál a szállító csak adott Linux verzió adott kernelére hajlandó
supportot vállalni (SAP kiegészítő termékről van szó), nem csodálkozom
semmin. Persze innentől ez nem a Linuxról szól, hanem az SAP-ról.

--
--- Friczy ---
'Death is not a bug, it's a feature'

Fehér János írta:
> Talán ha értene hozzá a T. kolléga, nem kellene a supportot hívogatni. Ha a
> fejlett országok ezt a mentalitást folytatják, akkor 10 év múlva már csak
> szép emlék lesz a gazdasági növekedésük.

És akkor jön el az Alapítvány ideje. A windózos rendszergazdák állnak a
gépeik mellett, amik automatikusan működnek, de ha egy entert kellene
leütni, akkor az már meghaladná a tudományukat.

SAP-ot annyira nem egyszeru allitolag Linuxon futtatni. Ezt hallomas alapjan mondom, mert nekem nem kell SAP-pal foglalkozni. Oracle-t sokkal egyszerubb, es nincs is vele problema. Ez viszont sajat tapasztalat.

Nekem egy RHEL 3 + Oracle 10 fibre storage-ra (HP EVA mondjuk), ugy hogy meg van csinalva rendesen, multipath (failover), rendesen beallitgatva, meg optimakolva meg minden, nem tart tovabb egy napnal. Az SAP telepitesen nem tudom mi tartott nekik ket hetig... :-)

Semmi értelme az ilyen általánosításoknak.

Vannak ügyfelek, akiknél az IT nem core tevékenység, hanem csak az üzletmenet támogatása, a versenyképesség megtartása érdekében használnak informatikát. Ez nem bűn, kb ahhoz lehetne hasonlítani, mint amikor azért vezetsz autót, hogy eljuss A-ból B-be gyorsan, de fogalmad nincs mi az a gyújtógyertya. Ha te egy ilyen user vagy, akkor elemi érdeked, hogy jó márkaszervíz legyen az adott autóhoz. Ugyanígy: ha az IT nem core tevékenység a cégnél (nem abból éltek, hanem mondjuk csavarok eladásából), akkor igyekezni fogsz a havi IT költségeket minimalizálni (olcsóbb rendszergazda, minél több szempontból ideális support szerződések minél kedvezőbb áron, stb) - mert az IT kiadásaid közvetlenül nem termelnek neked bevételt (maximum költségcsökkentési oldalon jelentkezhetnek: mondjuk egy SAP rendszer bevezetése kerül X-be, ami a logisztikai workflow átalakítása folytán (mert pl kirúghattál n db ügyintézőt) Z idő alatt megtérül (havonta X/Z-vel csökkennek a működési költségeid).

Persze vannak azután azok az ügyfelek, akik baromira semmit nem akarnak költeni IT-ra, és outsource-olják a teljes informatikát egy külső cégnek (persze ekkor is költenek rá, csak egyetlen számlán - kb mint amikor egy lízing cégen át kezeled az autóflottát, és még a tankolások számlája, szervízköltségek is ebbe az egy szerződésbe vannak bevonva - elég általános gyakorlat).

Nem tudom már hova akartam kilyukadni, úgyhogy abba is hagyom...

És itt jönnek be a képbe a vendorok, akik

esetleg:

- susekernel kelletett volna, mer a redhate *****

- uhu linux kell, susekernellel es force-olva rakott redhat csomagokkal, nekem othol ugy stabil

- debián sid kell, mert a suse/redhat/freebsd/gentoo/whatever *****

- nem netbsd volt a munkaallomasokon

- balfaszok, minek frissitenek, linuxon nem kell, ONJAVITO!!!

- openbsd-t hasznaljanak inkabb, azt a lamer mindensegit a linuxos bal***** fejuknek

- elkezdodott...


... es ezek tetszoleges kombinacioja

Hmm. Én leginkább felhasználó vagyok. Sok Sun szerver (régóta)kevés IBM szerver (nem túl régóta) kevés IBM storage (szintén nem túl régóta).

Szerver tekintetben egyébként IBM teljesen eddig OK.

A storage .... háát.... Ez tutóbbi kapcsán a support minősége: háát....

Sun -al összevetve az IBM supportot: más support-modellt alkalmaz az IBM (vagy csak túl nagy a belső bürokráciája), és emiatt szerintem a Sun-os support jobb. De ez relatív. A mi esetünkben minden hibát elfogadható időn belül megoldottak, IBM-ről ezt nem mondhatom. Ismét kiemelem, hogy az IBM Storage supportot hasonlítom a Sun szerver supportjához, de én mint ügyfél ettől függetlenül ugyanazt a minőséget várnám mindkét témában.

09:55:06 up 197 days, 16:54, 2 users, load average: 0.91, 0.46, 0.21

Mondjuk szerintem tutira vas probléma lehetett, de ezt sosem fogjuk megtudni. A vas probléma alatt értem pl. a ***** linux drivert is. Fogadjuk el, hogy még mindig a szervert kell a linuxhoz választani.

Nagyrészt igazad van, de ez a "lényegesen több ember" nem egészen így van - adott területen (értsd pl. Európa) van maximum 2-3 szakember egy témára, viszont van egy kegyetlen jó, okos és jól kereshető adatbázisuk. Mivel a Windows már régebb óta megy, több dologra találnak azonnal valamit. Meg mondjuk Windowsnál első tanács mindig az újraindítás szokott lenni, valljuk be...

> Szóval nem mindíg elhatározás kérdése a dolog, mert ha a Kinget ki
> akarnánk váltani akkor egyedi programot kellene fejleszteni, ami rövid
> távon nem kevés pénz. Hosszú távon meg nem lehet tudni, mert a Kinhez
> kellene igazítani folyamatosan.

Erre találták ki a terminál szervert. :)
Egy gépre felrakod a stuffot, és csinálsz egy indítóikont. A wines cucc
win alatt fut, a kliens meg lehet linux. Be lehet állítani, hogy a
program induljon el, és ne az asztal. Aztán ha lesz alternatíva, akkor
lehet dobni a wines megoldást.
Kis sávszélesség esetén is jól használható a tsz, ha a programnak jóval
több kellene.

"nagyobb gépek mítikus megbízhatósága is kicsit mítosz jellegű"

A megbízhatóság formalizálva extrém magas MTBF értéket jelent.

Nagyobb gépek esetén mindig illik megvizsgálni a beépített redundanciákat. Egy alkatrész megbízhatóságának elég megbízható metrikái vannak (MTFF, MTBF), melyeket a gyártók aktívan monitoroznak (és szinte soha nem tesznek közzé)- de alapvetően minden, mi fizikai világunk része alapvetően gyarló és romlandó. Pl olyan gépet nem illik venni sokmillió forintért, aminek nincs redundáns tápellátása és redundáns hűtése. Működés közben cserélhető CPU-k is jó dolgok tudnak lenni, ha 24/7-es online rendszerről beszélünk. Diszkekről nem is beszélve.

Ja, csak épp licenceköltségeknél majdnem ugyanott vagy, mintha minden PC-n lenne OEM Windows licence. Kell a szerverre sima CAL is, meg terminal CAL is - a ketto egyutt mar osszemerheto a sima Win licenccel. Persze ez nem veletlen, hiszen itt a megtakaritast az uzemeltetes oldalan lehet megintcsak megfogni (1 gepet patchelni tobb szaz helyett - ido es penzmegtakaritas)

Nézd! Most egy P3 1,2GHz Tualatin fut egy ASUS TUSL-2C alaplaban 512 MB RAM-mal és IDE winyóval. Ez Logon szerver kb. 30 Windowsnak. Kb. 10 Gép számára fájlszerver az ügyviteli programhoz és mindenkinek az érzékeny adatok mentésére.

Ehhez képest keresek egy "szreverebb" megoldást. Szeretnék sql-t is futtatni, amire vagy az sql-ledgert, vagy saját fejlesztésű ügyviteli szoftvert is tennék, esetleg az sql-ledgert alapul véve. Még semmit sem döntöttem/tünk el.

megfontolando alternativa meg a kovetkezo is: NEM piszkalod a mukodo rendszert, NEM csinalsz a homogen rendszeredbol egy bazart, NEM sokszorozod meg a hibalehetosegeket, NEM kell tobb rendszerre staffot fenntartanod, NEM koltesz l'art pour l'art megoldasok miatt jarulekos licenszekre

"Azt hiszem a nagyobb gépek mítikus megbízhatósága is kicsit mítosz jellegű"

Attól függ mi a mítosz. Az nem igaz, hogy soha nem romlik el. Ami elromolhat, az el is romlik. :)

De inkább mondok egy élő példát.

Ma fogunk memóriamodult cserélni egy gépben, mert elromlott. Ja, a gépen még mindíg dolgoznak, és a csere közben is fognak.

IBM cuccokkal (xSeries 200-at kiveve, de az inkabb a draga pistikepc kategoria) nem volt meg gondom (se Netfinity, se xSeries gepek eseten, pedig sokat gyurunk beloluk), viszont van egy hp netserverunk, ami folyamatosan szivat, hosszu ideje. volt sokat tesztelve, minden negativ, a hiba nem reprodukalhato, megis rendszeresen elojon (linux merevre fagy, kerneltol es disztribtol fuggetlenul. windows sosem volt rajta, igy nemtom, ott mi a helyzet). a notebookom is hp (pavilion zt3000) es azzal is vannak gondjaim. ugyanakkor van egy rx1620 es rx2600 (itanium2) szerverunk, azokkal soha nem volt meg gond. nyilvan van ***** mindenhol, de en valahogy mindig is inkabb IBM-parti voltam...

Ez egy 24/7 rendszer volt. Különálló RAID tömbel, ami a fő gép kiesésekor autómatikusan átkerült a tartalékra így adatvesztés-kiesés soha nem volt drasztikus.

Csak nem gondolod komolyan komolyan az AIX vason nem volt tarcsi táp. Mint írtam akárhány táp lehetett volna benne akkor is zárlatos volt a masina. Ezt viszont sehol nem jelezte a csoda diagnosztika,viszont simán hazavág bármit a gépen. Napokig nézték a logokat a nem kis napidíjú IBMs gyerekek ingyé. Ja tápcsere sem volt megoldás, az egész házat kukázni kellet. Az a ház mostani áron milkás tétel. Spéci légkondícionált plexifalú helységben volt a vas szekrényméretű saját szünetmentes táppal.

Gondolod nem volt kiadva az ukáz "Pénz nem számít csak stabilan menjen". No így tartott 2 hónapig.....

No ennyit a redundanciáról. Egy rejtett zárlat

hazavágja a legredundánsabb rendszert is. Tuti megrázta valamelyiket és így jöttek rá.

a "megvezetésről" jutott eszembe, hogy vasárnap kihívtuk a gázszerelőt, hogy vizslassa meg a konvektorokat... tök hülyének éreztem magam, amikor elkezdett "tudományosan" javítani, hogy hol fog átb**zni

el is kért 1 konvektor ellenörzésért 3500-Ft, és max 5 percig térdelt mellette!

jó az órabére :-)

tudom, az élet sokkal drágább, de ne nézze már teljesen hülyének az embert, vagy csak én vagyok ilyen lelkiismeretes a saját ügyfeleimmel... mondjuk nem is vet fel a pénz

( n0b0dy | 2005. 09. 29., cs – 10:40 )

Nem tudom miert vagytok oda annyira ettol. Ez a sztori is csak megerositi hogy a linux beilleszkedett a dolgok normal menetebe, azaz mar elfogadtak a felhasznalok. gyanus lenne ha csak jo hirek lennenek a linuxrol, nemde?

Vegul is csak az nem hibazik, aki nem dolgozik, ugyhogy inkabb oruljetek, hogy a linux mar dolgozik.

Nálunk a cég tavaly vett 2 pseries 670 -est egy frontend környetnek( most cseréltük le egy fele akkora méretű de 2x akkora teljesítményű p570 -re).

Mivel nem volt elég szünetmentes kapacitás a két tornyot csak fél lábon kötöttük szünetmentesre, a másik láb a sima elektromos hálózatra került. A gépek egymástól függetlenül időnkét fogták magukat és újraindultak. Nézegettük logokból nem derült ki semmi, IBM kihív vas átvizsgál, semmi baja. Végül az IBM hozott németországból egy fazont aki kiderítette hogy az elektromos hálózaton a nullvezeték és a védőföld össze volt kötve és jóképű áramok rohangáltak keresztül rajta, ráadásul az eu-s szabványok szerint ilyesmit nemigazán lehet csinálni. Villanyreszelők megcsinálták, a másik láb is szünetmentesre került, azóta semmi gond a gépekkel.

Csak pseries és rs6000 kategóriában van dolgom IBM gépekkel de ezekről elmondhatom hogy igencsak megbízhatóak, diszk hibák előfordulnak de ez "természetesnek" tekinthető, memóriahibával is eléggé ritkán találkoztunk.

Egyébként milyen "nagygép" volt az ahol táp hiba miatt házat kellet cserélni és csak "néhány százezer" volt?:)

> ha az IT nem core tevékenység a cégnél (nem abból éltek, hanem mondjuk csavarok eladásából),

Akkor ki kell adni az egesz infomatika uzemelteteset kulso cegnek. Az outsoucring-et kitalaltak mar. Nem egy orias cegnel csinaljuk sikerrel. Abban az esetben a cegnek megmondjak mik az igenyek, aztan majd a kulso ceg eldonti, hogy a mi kell az igenyek megvalositasahoz. Ez a legtisztabb mindket reszrol. Annal rosszabb nincs, amikor egy ceg dilattans IT-jevel kell dulore jutni, es a kulso vendornak vagy szupportnak is kompromisszumokat kell kotni. Van sok esetben ``megkenni'' az IT-t, hogy ``belassak'', hogy jo az, amit a kulsos nyujt. Szerintem a legtisztabb es egyben legolcsobb ilyenkor a teljes outsourcing...

Itt a HP szerver nalam azt jelenti, hogy Proliant, magyarul a regi Compaq vonal. En onnan jottem a HP-hez. Azokkal lenyegesen kevesebb problmank van mint az IBM-ekkel.

A Netserver az eredendoen HP termek volt, kozom nincs hozzajuk, sose volt. Igazabol azok nem voltak jo szerverek, es a HP nem is gyartja mar oket [h20180.www2.hp.com]. Talan nem veletlenul vette meg a Compaq-ot... A HP-nak ebben a kategoriaban iszonyu ***** szerverei voltak.

A load -ot a processzorszám függvényében kell nézni.

NAGYON általánosan a load a processz runqueue mélységével korrelál. Valójában nagyon nem szeretem a load-ot nézni, mert leginkébb csak historikus viszonyításra jó, de nem ad képet a rendszer terheléséről.

A kérdéses rendszer egyébként kb 90% os processzorterheléssel fut, ami nem rossz tekintve hogy egy ekkora vasat ki KELL használni, máskülömben csak pénzkidobás.

> jó az órabére :-)

De van felelossege is. Ha holnap felrobbansz, akkor megy a racsos egyetemre. Sokan ezert nem ertik meg, hogy miert 16K / ora + AFA-ert korul kezdodik egy hozzaerto szerveres ember bere (hetvegen dupla ennyi). Mert sok millios adatokkal jatszik.

én ezeket mind értem, de papírt nem adott róla, én meg bizonygassam az igazam, amikor a családom esetleg elszállt a lépcsőház felével eggyütt?

tisztába vagyok a felelősség szóval, sok sok éve így élek és dolgozok, mert ilyennek neveltek az őseim...

Csak a csavarhuzot bele ne ejtsd... Volt egyszer egy olyan kaland (igaz vagy nem igaz nem tudom), hogy a meno szervizes kiment a szerverhez, hotplug kartyat akart cserelni. Szerencsetlensegere es az ujjan levo oklomnyi arany pecsetgyuru hathatos kozremukodesekeppen sikerult rovidre zarni a gepeben valamit, aminek koszonhetoen az alaplap iveket huzott, majd a helyszinen is mult :-D

Azota megfigyelhezo, hogy a hotplug pci temak mellett jobb gepekben muanyag szeparalo lemezek vannak, egyes szervereken pedig az alaplap felett plexi van :-)

En ugy 8-at

Redhat/Szuzi vegyesen ( van mellette meg solon es Tru64en is) bevallom windowson meg csak dolgoztam vele, nem felugyeltem, de nekem semmi problemam nem volt se redhaton se susen...

Az update erdekes dolog foleg sapnal mivel nagyon meg kell nezni hogy mikor mit updatelsz..

pl linuxon ugyebar csak jovahagyott glibc-vel es kernellverzioval hasznalhatod.

a windows update (WSUS) szerintem egy nagyon eros es hatekony eszkoz, kezd jobb lenni mint barmilyen mas frissitesi rendszer amit ismerek...

zwei wrote:
> Ma fogunk memóriamodult cserélni egy gépben, mert elromlott. Ja, a gépen
> még mindíg dolgoznak, és a csere közben is fognak.
Ilyet már láttam én is. Valami 486-os PC volt, amelyben memória modult
cseréltek, mert az előző már elolvadt. Közben a gépen dolgoztak,
flexszel és hegesztőpisztollyal. :)

> Csak pseries és rs6000 kategóriában van dolgom IBM gépekkel de ezekről elmondhatom hogy igencsak megbízhatóak, diszk hibák előfordulnak de ez "természetesnek" tekinthető, memóriahibával is eléggé ritkán találkoztunk.

Igen, az egy masik vilag.

Egy kis izelito, amiert nem szeretem az IBM-et:

- aramszunet utan a RAID vezerlo elfelejtette a konfigot?? (adatok elvesztek) (Windows 2000 Server)

- RAID online migralas, Windows-on az eredmeny -> kekhalal (adatok elvesztek) (Windows 2000 Server)

- ha a RAID vezerlo meghal, csak azonos tipussal van eselyed

- a RAID tombben (AFAIK) a diszkek helye fix, veletlenul se keverje ossze az ugyfel (volt mar ra pelda) (Windows 2000 SBS)

- nem all kezre a menedzsmentje, raadasul most kellett egyik ugyfelnel leszedni, mert tobb evnyi uzemeles utan egyszer csak megfogta a gepet, es nem akart menni (Win2000 SBS)

- kisebb kategoriaju IBM szerveren a szoftver RAID neha ok nelkul szetesik (Win2003 Server)

- Memoria bivitesnel rossz RAM-ot kuld part number alapjan a dealer. Nem a tipus rossz, hanem a modul fizikailag. Zsir uj csomagban. Utanaolvasva a neten az a RAM tipus nem indul el a x235-ben, de Samsung gyartasban igen (eredeti IBM mindegyik). (Win2000 SBS)

- hangkartyas ROTFL IBM szerverek kondenzator felpuffadas hibaja / IBM szo nelkul csereli garban

- Uj szervert rendelve, karcos, leelt szervert kapunk gyari! csomagban, visszajavitasos jegyzokonyvvel mellette

HP-nal ilyen nincs:

- barmelyik uj RAID kontroller (elvileg) kompatibilis a regiekkel, ha a regi beszart, tegyel bele ujat, felolvassa a konfigot a diszkrol es jatszik tovabb a gep

- nem kenyes a diszekek helyere

- Nem kekhalalozik RAID kibovitesnel, migracional

- ha rendelek RAM-ot az bele valo, es mukodik

- jo az Insight manager

Ezek sajat tapasztalatok, az utobbi idokbol. Masnak lehet forditva vannak ezek a dolgok, ugyhogy senki nem vonjon le messzemeno kovetkezteseket.

Nekunk a sapunk winen fut... nem egy certifikalt ms patchet kellett hetfo delben visszagorgetni mert a performance ugy lezuhant hogy orom volt nezni... Eleve a legtobb wint futtato vas egy igazan nagy cegnel keves mint surdaban a vernyomas... es johet holmi 3 system landscape meg, meg db/dialog instance, gyengusz marad... Ja es certifikalt vason, certifikalt os-en fut... Egyetertek azzal is hogy koran feladtak, illetve forditsuk meg a kerdest. Melyik az a ceg aki megfelelo pilot rendszer nelkul elesben nyomatta a SAP-ot (software aus poland)? Ha megfelelo pilot rencer volt miert is nem jottek elo a hibak? ;o)) santit ez a dolog erosen...

S akkor egy kis sap admin tapasztalat: ne hasonlitsuk ossze amikor egy gepre akar halozaton at: telnet/ssh vagy eppen soros porton at a konzolra be tudsz jelentkezni akar eccerre tobb tiz szakember vagy eppen egy hulye remote desktop menedzserrel kuzdenek a szerencsetlenek egy olyan gepen aminek az ablak letrehozasa masfel perc egy szerencsetlen sapdba-hoz...

( anr | 2005. 09. 29., cs – 12:35 )

gondolkodtam egy kicsit. elemezzuk a helyzetet logikusan:

random elszallas/core dumpolas 2 tipusu ihbatol lehet:

1. a futo szoftver minosege kritikan aluli (ilyenek pl. egyes win verziok). Ez a SAP+RH parosrol nem mondhato el. sok helyen mukodnek problemamentesen

2. hardver kozeli hiba (driver is beleertve).

Namost egy IBM brand szerverbe csak olyan alkatreszek kerulnek, amikhez a linuxos drivert az IBM fizetett/ellenorzott programozoi irjak. a gepert meg az IBM vallal hardver garanciat.

logikai kovetkeztetes: 100%-ban az IBM volt az adott esetben a hibas, mert vagy hibas volt a drivere (ennek kisebb az eselye), vagy valamilyen alkatresz hibas (tipp: memoria, vagy proci) volt a szervereben.

a szomoru az esetben az, hogy az IBM profi kereskedoi meggyoztek az ugyfelet, hogy nem az o hibajuk, es rakentek a redhatra, aminek a supportja lehetett volna ugyesebb is, nem hiszem hogy futtattak hardver tesztelo progikat.

Ugyanmar. Az csak a statikus feltoltodes ellen ved. Attol nem, hogy femet ejts bele, gyuruvel rovidre zarj alkatreszt, vagy buli alkalmaval mogotted allo reszeg kollega poenbol belehugyozzon a szerverbe :-)

Csukloov... egyszer upgradeltunk egy Digital clustert. Jott a digitalos gyerek, varazsolt, bohockodott, majd kerdezte, hogy jon-e ez az ugyfel. Mondom nem latom... Jo majd szoljak ha jon... Egyszer latom, hogy jon... szolok neki, gyorsan ov felvesz, hozzaerto arc felvarazsol, mosoly... Oreg rutin volt, de marhan nem viselte a cuccot... Nem tudom, hogy hanyan hordjak valojaban szereleskor... :-)

Nem gázos. Oracle adatbázisok futnak rajta, elég jól belőtt memória allokációval. Az adatbázisokon belüli cache találat 90%-99% között mozog.(Leginkább OLTP jellegű dolgok.) Esti batch-ek és mentések összehangolására már figyelni kell, mert ott már tud szűk keresztmetszet lenni az i/o. Igaz, olyankor 10 szer annyi az i/o (kb 2Gb percenként) mint nap közben.

nem mondom, hogy nincs néha i/o wait, de ez jó részt a SAN os storage-ekre is fogható.

- aramszunet utan a RAID vezerlo elfelejtette a konfigot?? (adatok elvesztek) (Windows 2000 Server)

serveraid-el ilyet en meg nem lattam, sok fut pedig itt.

- ha a RAID vezerlo meghal, csak azonos tipussal van eselyed

erre nem mernek megeskudni, szerintem ez nem feltetlenul igaz, 'read configuration from disks'-mokanak itt is mukodnie kene (es tudtommal eltero vezerlokkel is mukodik)

- hangkartyas ROTFL IBM szerverek kondenzator felpuffadas hibaja / IBM szo nelkul csereli garban

ez teny, de asszem az csak egy korai szeria volt (en ket gepnel is belefutottam ebbe), mas kerdes, hogy valoban ROTFL kategoriaju gepek

nem flame-elni akarok, csak a tapasztalataimat irom.

Én nem furcsállanám. Az SAP egy ERP (enterprise resource planning) rendszer, ahogyan az Oracle Applications is. Ezeknek csak egyetlen komponense az adatbázis. Én Oracle-lel (is) foglalkozom és deploy-olni egy Applications-t a legritkább esetben sikerül 1 hónap alatt. 2 hét az 4-5 ember megfeszített munkájának eredménye kellett hogy legyen. Még SAP-nál is.

Egyébként részben igazat adok Trey-nek. :)

Az időnkénti "csúcsoknál" már jeleznek a felhasználók, hogy kicsit lassú a vas. Ez álltalában olyan 32-36-os load környékén van. 27-28 as load esetén még elégedettek. :)

Egyébként a legnagyobb load-ot kb 4 éve mértem egy Sun 10K-n. Ott egy elcseszett IAS form miatt percenként 1-2-vel nőtt a load. több mint 140 volt mikor sikerült rebootolni.

110-es load nál írtam be a usernevet és jelszót, 140 volt mikor a reboot-ra entert tudtam ütni. :))

Jáccunk ilyet :)

436-os load single processoros gépen ;)

Elárulom a titkot: Hibás SPAMszürés-beállítás miatt órákig álltak a levelek a SPAMfilternél és mindíg új process-t indított a drága... :D Kihúztam a konnektorból és leb@sztam a "rendszergazdát" 8)

Szerintem itt csak az alaprendszer telepitesre gondolnak.

Win server telepites kb. fel nap (munkanap, jobb esetben) SAP telepites meg kb. 1,5 nap (nem munkanap, hanem teljes nap) egy gepre, ha minden jol van beallitva es nem sikerul valamit elbaxni. Utana a teljes rendszer uzembe helyezese meg tovabbi hetek vagy honapok es tobb ember munkaja (osszetettsegtol fuggoen).

Ehh, asszem nem sértek vele üzletit titkot. :)

/root# prtdiag

System Configuration: Sun Microsystems sun4u Sun Fire E6900

System clock frequency: 150 MHz

Memory size: 98304 Megabytes

========================= CPUs ===============================================

CPU Run E$ CPU CPU

FRU Name ID MHz MB Impl. Mask

---------- ------- ---- ---- ------- ----

/N0/SB1/P0 4,516 1200 16.0 US-IV 2.3

/N0/SB1/P1 5,517 1200 16.0 US-IV 2.3

/N0/SB1/P2 6,518 1200 16.0 US-IV 2.3

/N0/SB1/P3 7,519 1200 16.0 US-IV 2.3

/N0/SB3/P0 12,524 1200 16.0 US-IV 2.3

/N0/SB3/P1 13,525 1200 16.0 US-IV 2.3

/N0/SB3/P2 14,526 1200 16.0 US-IV 2.3

/N0/SB3/P3 15,527 1200 16.0 US-IV 2.3

/N0/SB5/P0 20,532 1200 16.0 US-IV 2.3

/N0/SB5/P1 21,533 1200 16.0 US-IV 2.3

/N0/SB5/P2 22,534 1200 16.0 US-IV 2.3

/N0/SB5/P3 23,535 1200 16.0 US-IV 2.3

========================= Memory Configuration ===============================

Logical Logical Logical

Port Bank Bank Bank DIMM Interleave Interleave

FRU Name ID Num Size Status Size Factor Segment

------------- ---- ---- ------ ----------- ------ ---------- ----------

/N0/SB1/P0/B0 4 0 2048MB pass 1024MB 16-way 0

/N0/SB1/P0/B1 4 1 2048MB pass 1024MB 16-way 0

/N0/SB1/P0/B0 4 2 2048MB pass 1024MB 16-way 0

/N0/SB1/P0/B1 4 3 2048MB pass 1024MB 16-way 0

/N0/SB1/P1/B0 5 0 2048MB pass 1024MB 16-way 0

/N0/SB1/P1/B1 5 1 2048MB pass 1024MB 16-way 0

/N0/SB1/P1/B0 5 2 2048MB pass 1024MB 16-way 0

/N0/SB1/P1/B1 5 3 2048MB pass 1024MB 16-way 0

/N0/SB1/P2/B0 6 0 2048MB pass 1024MB 16-way 0

/N0/SB1/P2/B1 6 1 2048MB pass 1024MB 16-way 0

/N0/SB1/P2/B0 6 2 2048MB pass 1024MB 16-way 0

/N0/SB1/P2/B1 6 3 2048MB pass 1024MB 16-way 0

/N0/SB1/P3/B0 7 0 2048MB pass 1024MB 16-way 0

/N0/SB1/P3/B1 7 1 2048MB pass 1024MB 16-way 0

/N0/SB1/P3/B0 7 2 2048MB pass 1024MB 16-way 0

/N0/SB1/P3/B1 7 3 2048MB pass 1024MB 16-way 0

/N0/SB3/P0/B0 12 0 2048MB pass 1024MB 16-way 1

/N0/SB3/P0/B1 12 1 2048MB pass 1024MB 16-way 1

/N0/SB3/P0/B0 12 2 2048MB pass 1024MB 16-way 1

/N0/SB3/P0/B1 12 3 2048MB pass 1024MB 16-way 1

/N0/SB3/P1/B0 13 0 2048MB pass 1024MB 16-way 1

/N0/SB3/P1/B1 13 1 2048MB pass 1024MB 16-way 1

/N0/SB3/P1/B0 13 2 2048MB pass 1024MB 16-way 1

/N0/SB3/P1/B1 13 3 2048MB pass 1024MB 16-way 1

/N0/SB3/P2/B0 14 0 2048MB pass 1024MB 16-way 1

/N0/SB3/P2/B1 14 1 2048MB pass 1024MB 16-way 1

/N0/SB3/P2/B0 14 2 2048MB pass 1024MB 16-way 1

/N0/SB3/P2/B1 14 3 2048MB pass 1024MB 16-way 1

/N0/SB3/P3/B0 15 0 2048MB pass 1024MB 16-way 1

/N0/SB3/P3/B1 15 1 2048MB pass 1024MB 16-way 1

/N0/SB3/P3/B0 15 2 2048MB pass 1024MB 16-way 1

/N0/SB3/P3/B1 15 3 2048MB pass 1024MB 16-way 1

/N0/SB5/P0/B0 20 0 2048MB pass 1024MB 16-way 2

/N0/SB5/P0/B1 20 1 2048MB pass 1024MB 16-way 2

/N0/SB5/P0/B0 20 2 2048MB pass 1024MB 16-way 2

/N0/SB5/P0/B1 20 3 2048MB pass 1024MB 16-way 2

/N0/SB5/P1/B0 21 0 2048MB pass 1024MB 16-way 2

/N0/SB5/P1/B1 21 1 2048MB pass 1024MB 16-way 2

/N0/SB5/P1/B0 21 2 2048MB pass 1024MB 16-way 2

/N0/SB5/P1/B1 21 3 2048MB pass 1024MB 16-way 2

/N0/SB5/P2/B0 22 0 2048MB pass 1024MB 16-way 2

/N0/SB5/P2/B1 22 1 2048MB pass 1024MB 16-way 2

/N0/SB5/P2/B0 22 2 2048MB pass 1024MB 16-way 2

/N0/SB5/P2/B1 22 3 2048MB pass 1024MB 16-way 2

/N0/SB5/P3/B0 23 0 2048MB pass 1024MB 16-way 2

/N0/SB5/P3/B1 23 1 2048MB pass 1024MB 16-way 2

/N0/SB5/P3/B0 23 2 2048MB pass 1024MB 16-way 2

/N0/SB5/P3/B1 23 3 2048MB pass 1024MB 16-way 2

========================= IO Cards =========================

Bus Max

IO Port Bus Freq Bus Dev,

FRU Name Type ID Side Slot MHz Freq Func State Name Model

---------- ---- ---- ---- ---- ---- ---- ---- ----- -------------------------------- ----------------------

/N0/IB6/P0 PCI 24 B 0 33 33 1,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB6/P0 PCI 24 B 0 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB6/P0 PCI 24 B 0 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB6/P0 PCI 24 B 0 33 33 2,0 ok scsi-pci1000,b.7/disk (block)

/N0/IB6/P0 PCI 24 B 0 33 33 2,1 ok scsi-pci1000,b.7/disk (block)

/N0/IB6/P0 PCI 24 B 1 33 33 2,0 ok network-pci108e,abba.20 SUNW,pci-ce

/N0/IB6/P0 PCI 24 A 3 66 66 1,0 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB6/P0 PCI 24 A 3 66 66 1,1 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB6/P1 PCI 25 B 4 33 33 1,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB6/P1 PCI 25 B 4 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB6/P1 PCI 25 B 4 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB6/P1 PCI 25 B 4 33 33 2,0 ok scsi-pci1000,b.7/disk (block)

/N0/IB6/P1 PCI 25 B 4 33 33 2,1 ok scsi-pci1000,b.7/disk (block)

/N0/IB6/P1 PCI 25 B 5 33 33 2,0 ok pci-pci8086,b154.0/pci (pci) pci-bridge

/N0/IB6/P1 PCI 25 B 5 33 33 0,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB6/P1 PCI 25 B 5 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB6/P1 PCI 25 B 5 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB6/P1 PCI 25 B 5 33 33 4,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB6/P1 PCI 25 B 5 33 33 2,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB6/P1 PCI 25 B 5 33 33 3,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB6/P1 PCI 25 B 6 33 33 3,0 ok network-pci108e,abba.20 SUNW,pci-ce

/N0/IB6/P1 PCI 25 A 7 66 66 1,0 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB6/P1 PCI 25 A 7 66 66 1,1 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB8/P0 PCI 28 B 0 33 33 1,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB8/P0 PCI 28 B 0 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB8/P0 PCI 28 B 0 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB8/P0 PCI 28 B 0 33 33 2,0 ok scsi-pci1000,b.7/disk (block)

/N0/IB8/P0 PCI 28 B 0 33 33 2,1 ok scsi-pci1000,b.7/disk (block)

/N0/IB8/P0 PCI 28 B 1 33 33 2,0 ok network-pci108e,abba.20 SUNW,pci-ce

/N0/IB8/P0 PCI 28 A 3 66 66 1,0 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB8/P0 PCI 28 A 3 66 66 1,1 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB8/P1 PCI 29 B 4 33 33 1,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB8/P1 PCI 29 B 4 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB8/P1 PCI 29 B 4 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-ce

/N0/IB8/P1 PCI 29 B 4 33 33 2,0 ok scsi-pci1000,b.7/disk (block)

/N0/IB8/P1 PCI 29 B 4 33 33 2,1 ok scsi-pci1000,b.7/disk (block)

/N0/IB8/P1 PCI 29 B 5 33 33 2,0 ok pci-pci8086,b154.0/pci (pci) pci-bridge

/N0/IB8/P1 PCI 29 B 5 33 33 0,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB8/P1 PCI 29 B 5 33 33 0,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB8/P1 PCI 29 B 5 33 33 1,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB8/P1 PCI 29 B 5 33 33 4,0 ok pci-pci8086,b154.0/network (netw+ pci-bridge

/N0/IB8/P1 PCI 29 B 5 33 33 2,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB8/P1 PCI 29 B 5 33 33 3,0 ok network-pci100b,35.30 SUNW,pci-qge

/N0/IB8/P1 PCI 29 B 6 33 33 3,0 ok network-pci108e,abba.20 SUNW,pci-ce

/N0/IB8/P1 PCI 29 A 7 66 66 1,0 ok QLGC,qla-pci1077,10a.1077.10a.2/+

/N0/IB8/P1 PCI 29 A 7 66 66 1,1 ok QLGC,qla-pci1077,10a.1077.10a.2/+

========================= Active Boards for Domain ===========================

Board Receptacle Occupant

FRU Name Type Status Status Condition Info

--------- ----------- ----------- ------------ --------- ----------------------------------------

/N0/SB1 CPU_V3 connected configured ok powered-on, assigned

/N0/SB3 CPU_V3 connected configured ok powered-on, assigned

/N0/SB5 CPU_V3 connected configured ok powered-on, assigned

/N0/IB6 PCI_I/O_Boa connected configured ok powered-on, assigned

/N0/IB8 PCI_I/O_Boa connected configured ok powered-on, assigned

========================= Available Boards/Slots for Domain ===========================

Board Receptacle Occupant

FRU Name Type Status Status Condition Info

--------- ----------- ----------- ------------ --------- ----------------------------------------

/N0/SB0 unknown empty unconfigured unknown assigned

/N0/SB2 unknown empty unconfigured unknown

========================= Hardware Failures ==================================

No Hardware failures found in System

"Nem igaz, hogy nem lehet tenni valamit ilyenkor egy teljesen nyilt rendszeren."

Egy ilyen hibát nyílt rendszeren nehezebb megfogni mint egy zárton. A zárt rendszernél be tudod tolni a problémát a kernel engineering csapathoz, akik rögtön foglalkoznak vele ha tényleg súlyos az ügy. Ugyanígy a hardware- tervező csapat is együtt tud velük működni.

Ja, ezt tapasztalatból mondom. Pont volt egy ehez hasonló esetem.

Okay. Ez így hiteltelen. Most feltelepítették, vagy fel is konfigurálták? Ez nincs leírva. Feltelepíteni egy Apps-ot 6-8 óra. SAP is megvan sztem annyi idő alatt. Bármilyen rendszeren. / Persze nagymértékben függ az I/O throughputtól is;) / Kb. 3 óra mire a recommended prereq patchek felmennek és leellenőrzöd a környezetet. Aztán uccu neki installer. De bekonfigurálni és testreszabni hetek kérdése. Azt tudom elképzelni hogy b@lfaszkodtak és nem volt tapasztalt SAP konzultásuk, aki látott volna már ilyet Linuxon. Mert vannak buktatói. Legalábbis Oracle-nél vannak. Ahogy Windowsnál is. Erről sokat tudnék mesélni :D Windows-on 2 hét AIX-en 1,5 nap Apps 11.5.9 install :D (Azóta kitapasztaltuk hogy mitől döglik a légy Windows-on és mostmár az is megvan 1-1,5 nap alatt)

> - aramszunet utan a RAID vezerlo elfelejtette a konfigot?? (adatok elvesztek) (Windows 2000 Server)

serveraid-el ilyet en meg nem lattam, sok fut pedig itt.

Na varjal. Majd mingyart szolok a kolleganak, akinel a szemem lattara megtortent. :-) Mert nem nalam volt, ugyhogy nem vadolhatsz elfogultsaggal.... Nakuro? Hogy is volt ez? :-)

"Nekem egy RHEL 3 + Oracle 10 fibre storage-ra (HP EVA mondjuk), ugy hogy meg van csinalva rendesen, multipath (failover), rendesen beallitgatva, meg optimakolva meg minden, nem tart tovabb egy napnal."

trey: RAC-cal? Mert azért az szép teljesítmény lenne. Na nem is az Oracle miatt, de egy multisite EVA plusz egy RAC azért egy napba cipőskanállal se...

Ez itt is hasonloan mukodhetett volna, ha az IBM kereskedoin atverekedi magat a redhat support. az IBM-nel van kernel csapat is meg ott vannak a harver tervezok is. dehat a kereskedok rutinbol lerendeztek az ugyfelek kommunikaciosan: nem is mi vagyunk a hibasak, hanem mas. hatekony modszer. sajnos.

> trey: RAC-cal? Mert azért az szép teljesítmény lenne. Na nem is az Oracle miatt, de egy multisite EVA plusz egy RAC azért egy napba cipőskanállal se...

Nyilvan nem. Ugy ertem, hogy egy full mukodo EVA, a storage prezentacio megcsinalva, egy darab szerver osszeallitva. Csak a RHEL telepites, meg ra az Oracle, beallitas, meg a multipath teszteles, stb. Csodakat en se tudok tenni :-D De ez azert egy nap alatt megvan.