Ubuntu tönkreteszi a merevlemezt?

Merevlemezek, vezérlők

Dióhéjban a lényeg:

IBM xSeries szerveren Ubuntu 12.04 fut, 2 db IBM HDD, software RAID - most ne firtassuk, hogy miért software.

Szétesik a tömb. IBM mérnök kiszáll, lefuttat egy gyári tesztet, ami nem jelez hibát. Firmware-frissítéseket elvégzi, RAID-et összerakom, majd egy héten belül szétesik.

Csak ekkor jut eszembe - mea culpa - a smartctl futtatása, ami régen elfogyott fenntartott helyet jelez, azaz a szétesés akkor van amikor fizikailag rossz helyre írna az Ubuntu.

Megkérdem az IBM-et, hogy ezt hogyhogy nem jelzi a herkentyűjük, és hogy mi a vélemény arról, hogy 2 gép négy HDD-je közül három a garidő lejárta körül (kettő előtte, egy utána) kipusztul.

A válasz lényege, hogy a software RAID nem támogatott, és a szoftverük a RAID-kártya nem használata miatt nem detektál SMART-hibákat (ez szerintem ciki, de vitázni vele nincs értelme, így van és kész), és:

"A drive és firmware inkonformitásból származó bad blockok problémája: (A
HDD gyakori meghibásokban a IBM firmwarek és a nem támogatott driver
"együtt nem működésének" döntő szerepe van a bad block-ok
generálódásában. Erre láthattunk korábban is - más szerverek esetén is
-meggyőző példákat.)"

Ezek után nem látom értelmét a további levelezésnek, akár igazuk van, akár nincs. De érdekel a dolog:

1) Ilyen van?? Aki ért ennyire a dologhoz, mondja már meg, hogy ezek szerint különbözik ennyire a SuSE, a RedHat (IBM által támogatott Linuxok) és az Ubuntu kernele?
2) Nem vigyáz magára a HDD? Ha hülyeséget mondunk neki, akkor megcsinálja? Reális a következtetés, hogy ezek szerint egy vírus bad sectorokat eredményezhet?

Aki okosat válaszol, vegye figyelembe, hogy semmit nem tudok a világnak erről a részéről, beszéljen lassan, és artikuláljon tisztán:)

  • 10155 megtekintés

( zwei | 2013. 03. 07., cs – 14:17 )

nem kizárt.
A diszkeken is szoftver van (firmware, ugye), a driver is egy szoftver.
Szoftver kommunikál szoftverrel. Ha a firmware nincs minden esetben közös nevezőn az oprendszer driverével, akkor produkálhat hibákat.
Adott firmware igényelhet adott verziójú drivert, és fordítva is igaz.
Nyilván vannak szabványok, de a gyártók hajlamosak egyedi innovációkat is bele vinni a firmware-ekbe...

( trey | 2013. 03. 07., cs – 14:11 )

A válasz az, hogy egy gyártónak az a kényelmes és leggazdaságosabb, ha te csak az általa rommá tesztelt (hivatalosan: támogatott) OS-t futtatod úgy, ahogy ő azt megálmodta. Érthető, hogy arra vállal garanciát, amit előtte agyontesztelt. Ha a supportált úttól eltérsz, arra pedig az lesz a válasz, hogy nem supportált amit csinálsz. Akkor is, ha a hiba az ő hibájuk (pl. firmware hiba), akkor is, ha nem.

Ezen kár polemizálni, igazad sosem lesz. Végül is reklamálni sem nagyon lehet, mert ha az Ubuntu nincs a supportált OS-ek közt, akkor az lesz a válasz, hogy futtass támogatott OS-t. Ha pedig csak RAID-en keresztül támogatják, akkor pedig az lesz a válasz, hogy az a supportált.

Ha neked ez nem felel meg, akkor egy tanulsága van a sztorinak: legközelebb más vasat kell venni.

--
trey @ gépház

Az attol fugg, hogy erted.

Elonyben nem reszesitik oket (vagy en nem tudok olyanrol), de lehetnek pl. driverekben RH specifikus valtoztatasok, ill. lehetnek olyanok, amik oda bekerulhetnek hamarabb, mint a stock kernelbe. Az az Ubuntu-n all valojaban, h ok belerakjak-e a sajatjukba, vagy megvarjak, amig bekerul a mainline kernelbe, ha egyaltalan.

Pl. ilyet lattam a minap az Areca kartyajanak a drivereben. Maga a letoltheto driver 2 evvel le van maradva a stock kernel mogott, van benne vmi RH specifikus dolog es senki nem tiltja, h Ubuntu-s kernelre rakd fel.

tompos

( zitev v | 2013. 03. 07., cs – 14:13 )

magyarán írásba adta az IBM, hogy nem hibatűrő a rendszere ha ubuntut használsz? hulladék...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ja jól értettem (és ennek is van értelme) az IBM azt mondta, hogy a lemezeket a RAID vezérlőn keresztül, a támogatott driverrel kell használni. Nem utolsó sorban, sokszor a management programok (monitoring agent-ek) is csak akkor működnek, ha a megfelelő drivert használja az ember. A brand vasak kicsit más bánásmódot igényelnek, mint a tákolt vasak.

--
trey @ gépház

"A brand vasak kicsit más bánásmódot igényelnek, mint a tákolt vasak. "

Régebben ha komolyabb rendszert tervezett az ember, órákat lehetett support mátrixok nézegetésével eltölteni.
Most is temérdek idő elcseszhető ilyesmivel, bár már szinte minden gyártónak vannak erre tooljai, amivel már elég jól garantálni lehet, hogy az utolsó racksínig minden suportált a konfigban.

Ha valami nem támogatott egy konfigban, onnantól kezdve az adott gyártó felemeli a kezét. És ez tök természetes. Egyszerűen nincs értelme a supportált cuccokon kívüli hiba keresésének.Elég azzal szívni, ha supportált konfig esetén van ilyen hiba. (mert ilyen is van dögivel.)

De gondolom neked ezzel nem mondok újat.

hová van dugva a vinyó ha nem a vezérlőre? ha pedig oda, akkor nyilván a vezérlő drivere is telepítve van - az más kérdés hogy nem a vezérlőn építi a raid-et, hanem szoftveresen, attól még nem kéne ilyen hibát csinálnia.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

..és az ibm-es rendszerszakinak ez nem tűnt fel - remek..
de ha így is történt, akkor sem kellene ilyet csinálnia egy brand vasnak, szabványok is vannak a világon, ha pedig ezt nem tartja be a gyártó, akkor gyártson fröccsöntött locsolókannát inkább, ott kevésbé fontos a paraméterek tartása...
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Teljesen mindegy, hogy mi van.
Az is lehet, hogy szar szériát fogott ki az ügyfél, és tényleg a diszkek szarok.

De mivel nincs a support mátrixban, a gyártó teljesen jogosan felteszi a kezét.

Ha valaha is dolgoztál valami brand supportján, akkor látnád, hogy azzal is rengeteg meló van, hogy a support mátrixban benne levő konfigok hibáival foglalkozik az ember, és nem hiányzik még a minden egyéb szedett-vedett megoldás debugja is.

En ha jol ertem, Oops nem a kezfeltartas lehetoseget vitatja, hanem azt, hogy amiatt lesz badblock a HDD-n.

A legjobb tudomasom szerint lehetseges ez is, elmeletileg. A gyakorlatilag az IBM v. a mernok magat igeti, ha csak ugy kijelenti, h emiatt van. Lehetseges, de elenyeszoen kicsit az valoszinusege. De cafoljatok meg.

tompos

Saját tapasztalat alapján, előfordulhat hogy kb. 30 másodperc alatt úgy ítéli meg, hogy nem supportált a konfig, és felteszi a kezét.

Erre is van egy jó példám:

Solaris-on az uname parancs kimenete "SunOS 5.XX".
IBM szoftver termék hibakeresésekor a diagnosztikai script futtatása után az IBM szakvélemény az volt, hogy a SunOS.XX nem támogatott oprendszer. Supportált verziók: ..Solaris XX ...
A szakvéleményt egy levél formájában kaptam, a levél előzményében láttam, ahogy 3 (németországi illetőségű) IBM-es emberen is átment, és mind megerősítette azt az elsődleges kijeneltést, hogy az ügyfél SunOS.XX -e nem supportált.

Bakter, nekem kellett bizonygatni, hogy kb. bármelyik Solaris verzión az uname parancs "SunOS"-t ad vissza, és ez pontosan ugyanaz az oprendszer, amire ő Solaris-ként hivatkozik.

> Saját tapasztalat alapján, előfordulhat hogy kb. 30 másodperc alatt úgy ítéli meg, hogy nem supportált a konfig, és felteszi a kezét.

Tovabbra sem erted. Nem feltette a kezet, h nem tudom, nem supportalt, hagyjal beken. Hanem kijelentette, hogy emiatt ment tonkre ill. emiatt nem jo.

> Bakter, nekem kellett bizonygatni, hogy kb. bármelyik Solaris verzión az uname parancs "SunOS"-t ad vissza, és ez pontosan ugyanaz az oprendszer, amire ő Solaris-ként hivatkozik.

Errol beszelek, magat egeti a mernok es az IBM is az aktualis esetben.

Senki nem vitatja, hogy supportalt vagy nem, most megcsak azt sem, hogy ezzel kellene foglalkoznia az IBM-nek.

tompos

"Tovabbra sem erted. Nem feltette a kezet, h nem tudom, nem supportalt, hagyjal beken. Hanem kijelentette, hogy emiatt ment tonkre ill. emiatt nem jo."

Te nem érted: a legtöbb gyártó szinonímaként használja a "nem dolgozom vele, mert nem supportált" és a "azért szar, mert nem supportált" kifejezéseket.
A felhasználó szempontjából nincs lényeges külömbség a kettő között.

> Te nem érted: a legtöbb gyártó szinonímaként használja a "nem dolgozom vele, mert nem supportált" és a "azért szar, mert nem supportált" kifejezéseket.

Miert erdekeljen engem, h a gyarto helytelenul hasznalja? Szarok ra, az o dolga, ha nem tud fogalmazni.

> A felhasználó szempontjából nincs lényeges külömbség a kettő között.

Jelentos kulonbseg van. Megint leirom, a felhasznalot (Oops-ot) nem az a support erdekli, hanem a dolog technikai hattere:

http://hup.hu/node/122617?comments_per_page=9999#comment-1578293

tompos

nincs lényeges külömbség: maga oldja meg a problémát.
A megoldás attól függ, hogy igaz -e amit a gyártó állít. Ha igaz, akkor a megoldás egy megfelelő driver beszerzése, és a megfelelő supportált konfig használata.
Ha nem igaz amit a gyártó állít, akkor a diszkcsere megoldja a problémát.

Maximálisan tisztában vagyok vele, hogy a topic indítót nem az érdekli, hogy miért nem foglalkozik vele a supportos, hanem az érdekli lehet -e ilyen.
Azzal szerintem egyet érthetünk, hogy igenis lehetséges.
Az, meg hogy a postoló rendszerén is ez a probléma, hamarosan ki fog derülni: ha a csere diszkek is bemondják az unalmast relative hamar, akkor valószínűleg nem hazudott az IBM-es szervízember.

Mar masodjara irod, ezert bocs, kijavitom, ugyanis nagyon szurja a szemem: kulonbseg:)

> A megoldás attól függ, hogy igaz -e amit a gyártó állít. Ha igaz, akkor a megoldás egy megfelelő driver beszerzése, és a megfelelő supportált konfig használata.

A problema az, hogy a szervizember kijelentette (gondolom en) anelkul, hogy melyebben megvizsgalta volna a problemat. Legalabbis feltetezelezheto, de mutassa meg vki, hogy csak igy a kanyarbol hogyan allapithato meg.

> Az, meg hogy a postoló rendszerén is ez a probléma, hamarosan ki fog derülni: ha a csere diszkek is bemondják az unalmast relative hamar, akkor valószínűleg nem hazudott az IBM-es szervízember.

Nem feltetlenul a driver, van meg par komponens a rendszerben. A kulonbseg csak annyi, hogy azokat (elvileg) supportalja az IBM.

> Azzal szerintem egyet érthetünk, hogy igenis lehetséges.

Apropo, tegyuk fel, hogy elofordul az ilyesmi, azaz a driver hazavagja a diszket. Az IBM-nek kutya kotelessege lenne javitani az _ismert_ hibat, az Ubuntunak meg persze kotelessege lenne a kernel csomagba raknia.
A kerdes csupan annyi, letezik egyaltalan ilyen _ismert_ hiba? Ha nem, akkor ugy sejtem, az RH kernelbe sem tudjak belerakni, akkor meg hova pampog a szervizes mernok ur?

tompos

A Canonical nem kotelezheto semmire, tekintve hogy nem fizetsz nekik az Ubuntu supportjaert. Bele kellene nekik rakni, de ez minden.

Az IBM pedig - tekintve, hogy nem tamogatott kornyezetben uzemel a rendszer - nyugodt szivvel mondhatja azt, hogy ha reprodukalod tamogatott kornyezetben a hibat, akkor javitjak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Canonical: a logika kotelezi. Ha azt akarja, h hasznalhato legyen a rendszere, belerakja. Miert ne tenne?

IBM: nem ertem, amit irtal. Arrol van szo, h van egy ismert hiba, amit mar javitottak a tamogatott kornyezetben. Miert tartanak vissza a javitast a nem tamogatott kornyezettol (elobb letoltheto driver, majd a mainline kernelbe integralassal)?

tompos

Szerintem nem tartjak vissza, csak ido, mire ott is megjelenik. Ne felejtsd el, hogy a tamogatott kornyezet pont abban ter el a nem tamogatottol, hogy - mily meglepo - nincs olyan jo tamogatas hozza. Egyszeruen mas a roadmap.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem kívánok belemenni olyasmibe, amibe még a gyártó sem biztos sok esetben. Ismerek személyesen olyan embert, aki HP-nak rendszeresen bugreportol storage / diszk firmware hibákat, amik verzióról verzióra nincsenek kijavítva, mert egyszerűen a gyártó sem érti (látszólag), hogy mi lehet a baj. Hát ha a gyártó sem, akkor ki? Kérdem én.

--
trey @ gépház

Van egy olyan gyanúm, hogy vannak olyan hibák, amiknek a javítása túl sokba kerül, és a megléte nem feltétlen kritikus probléma.
A rendszerek tudnak annyira összetettek lenni, hogy nagyon-nagyon durva meló egy érdekesebb bug megfogása, és kiküszöbölése.

A kedvencem az volt, mikor egy nagy Sun szerveren egy adott java alkalmazás stressz-tesztelése megborította a teljes vasat. Reprodukálhatóan.
Hónapokig tartott, de megfogták. Állítólag a végén azok a mérnökök is dolgoztak a problémán, akik tervezték az architektúrát. A hibát egyébként egy bizonyos bitminta megjelenése egy bizonyos adatbuszon váltotta ki, és adtak rá patchet, ami megjavította.
Állítólag a világon 2-3 helyen fordult elő, pechünkre az egyik mi voltunk.

Az, hogy egy például hp szerveren futó ubuntu-n per prompt nincs fent a hp cuclija (hpacucli, vagy micsoda) és a többi lom, attól még nemf og tönkremenni a diszk, legfeljebb Csavarhúzókezelő Ábrahám "szervízmérnök" nem fogja megtalálni, és emiatt majd hülyeséget fog a szervíz beszélni.
Ha egy "brand" diszk csak egy bizonyos vezérlővel, egy bizonyos beállításban működik, miköyben egy kommersz diszk meg gyakorlatilag bármilyen környezetben, akkor szerintem az előbbit lehet tákoltnak nevezni.

Nem feltetlen. Mert ugyan a kommersz diszk az barmilyen kornyezetben mukodik, de nincs is rajta magas rendelkezereallas/magas biztonsag/akarmi pecset meg garancia. Ugyanis azt nem tesztelik minden lehetseges kornyezettel, mig a brand diskeket igen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bármi rárakható, de ha nem működik és nincs benne a támogatott termékek listájában, akkor magadra vagy utalva.

Sőt, ha benne is van valami a támogatott termékek listájában, de nem támogatott konfigurációban, akkor is magadra vagy utalva.

Lehet, hogy köze nincs a driverhez, simán csak szar szériát fogott ki az ügyfél, de legyen kedves és bizonyítsa be.
A gyártó egyértelműen megadja, hogy mik azok a feltételek, ami mellett a garancia és a support jár.

nagyjából ez a szitu.

Azért ez jellemzően inkább a storage-ok esetében, fordul elő, és nem az alsó kategóriás általános célú szerverek esetén.
Storage-ok esetén egyébként szinte minden gyártónál saját firmware van a diszkeken.
Nem csak azért, mert így a diszkek eladásán is keres, hanem azért, mert olyan szinten kell, hogy együttműködjön a controller és a diszk, amit csak a megfelelő firmware-ekkel lehet garantálni.
Egy-egy controller firmware/szoftver frissítés esetén gyakran a diszkek firmware-eit is frissíteni kell az előírt verzióra.

( neutrino v | 2013. 03. 07., cs – 14:18 )

Firtassuk már egy kicsit, hogy miért van softraid ott, ahol a hardware is rendelkezésre áll, ráadásul a hiba is nagy valószínűséggel abból adódik..

Komolyan, nem kötekszem, csak érdekel a mindset.
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

Hogy jon a kepbe a backup a raid alternativajakent?

A raid-del az utolso pillanatilag megvan az adata. SW raid-del pedig csak a diszkeket kell atdugnia masik gepbe, masik vezerlore es megy. Nem a kokany IBM mernokre kell varnia, h majd megmondja a tutit.

tompos

ui.: Apropo, a smart-tal egyebkent leolvashatonak kell lennie a HDD-nek. Ha a sajat sw-juk nem is ismeri, a smartctl-lel mennie kell.

Nálunk így is történt a suliban. Elszállt a RAID vezérlőn a memória (régi szerver support nincs), aztán amíg megjött az ebayről addig csak lestünk. Utolsó műveletként még összefosta a fájlrendszert is úgyhogy happy voltam. Még szerencse, hogy nem a mostani KIK/SZIK/MIK-es közoktatás volt még akkor mert lehet hogy sose lett volna pénz az alkatrészre...

( Zsugabubus | 2013. 03. 07., cs – 14:34 )

Szerintem ez baromság, hogy az Ubuntu és az SW RAID teszi tönkre a diszket, és mondjuk az is, hogy nem használod a HW RAID-et.
Amúgy milyen driverrel hajtod meg a vezérlőt, ha nem az aacraiddel?

Adott esetben ugyanazon driver esetén egy minor verzió eltérés is okozhat hibákat.

Az is lehet, hogy ha supportált konfigja lenne, szintén előjött volna a hiba, mert pl. ráfutott egy driver bugra.
Nem ez lenne az első ilyen eset a világtörténelemben.

Mondjuk egy szériahiba sem kizárható, és az Ubuntu is hajlamos alattomos gazságokra. :)

Az IBM support minősége is változatos. (1x éve egy RS6000-est csavaronként cserélt ki teljesen a support, mert kb. hetente megborult. A végén egy-az egyben lett kicserélve a teljes doboz, és probléma megoldódott. Alig fél év alatt...)

A tények teljes körű ismerete nélkül felelőtlenség bármit kijelenteni ezen a fórumon.

Én üzemeltetek IBM szerveren Fedorat, még sosem hajtottak el vele, amikor bedöglött egy diszk, cserélték szó nélkül.
De persze még mindig nem mondta a kérdező, hogy hogyan is üzemelteti soft-raiddel a raid vezérlőre kötött diszkeket, mert pl. az aacraid betöltése után block-deviceként nem is érhetőek el a winyók, amivel lehetne az md-t használni. Ha pedig simán felrakta mondjuk az alaplapi SATA portokra, akkor ott miért is baj az SW raid használata? Inkább használnám én is így, mint valami BIOS-driver által generált fakeraiddel (bár ebben az esetben én tuti nem vennék diszket az IBM-től, 3x-os áron, mint a bolti).

Illetve ez is leírásra került:

"a IBM firmwarek és a nem támogatott driver "együtt nem működésének" döntő szerepe van a bad block-ok generálódásában."

Ez meg akár igaz is lehet. Legalábbis ha nekem ezt az IBM mondja, el kell fogadnom, mert nem vagyok abban a helyzetben, hogy belelássak/belenézessek a firmware-ük működésébe. Ezek rendszerint zárt forrásúak.

--
trey @ gépház

Érdekes az a diszk firmware, amit ha nem a raid vezérlő hajt, tönkremegy :)
Mondjuk még azt el tudom képzelni, hogy ész nélkül parkolta alapból a fejet, vagy 1 perc volt a standby timeout, és attól mentek tönkre idő előtt a diszkek, de ezt a smart adatokból ki lehet nézni.

nem tudhatjuk, mi a valóság, akár még az is igaz lehet, amit az IBM support állít.

Manapság már annyi feature-t és optimalizációt pakolnak bele az ilyen firmwar-ekbe, hogy simán lehet, hogy megfelelő driver nélkül nem működik jól.
Tipikusan a brand cuccok azok, amikben custom firmware-ek fordulnak elő.

Semmi sem kizárt, csak nehezen hiszem, hogy így működne:
- Te Joe, itt ez a diszk a Seagettől (vagy WD-től), egy kicsit meg kéne piszkálni a firmwaret.
- Ok Jack, de tudod, hogy ez után, ha nem a mi raid vezérlőnkkel használják, akkor tönkremegy?

De fölöslegesen szaporítjuk a szót, szerintem köcsögök, ha nem cserélik a HDD-t, mert soft raidben volt.

... ami még mindig kisebb veszteség, mint elvégezni sufniban a vásárlónál azt, amit a laborban még nem csináltak meg, vagy megcsináltak, csak ott is sikertelen végteszttel, aztán a bedőlésnél ugyanúgy elveszíteni a vásárlót, és esetleg ráadásként a kártérítési pert.

Nagyon nagy az esélye annak, hogy nem tesztelték, és persze az a legkönnyebb, hogy elhárítják a felelősséget, miközben az adott felállásban lehet, hogy n+1 ügyfélnél működik a cucc, csak arról ugye nincs információja a gyártónak.
Az, hogy egy diszk cseréje mennyit ér meg/vagy sem egy gyártónak, az jó kérdés. Itt esélyes, hogy nem fog nagyot bukni ezzel, de látott már olyat a világ, hogy korábbi szállító azért (is) bukott el egy igen komoly tendert, mert ilyen rigolyái is voltak - néhány évre kihullottak a "kedvenc szállító" cím birtokosai közül, és ez utólag nagyon sokba fájt nekik...

Mert ez a legegyszerubb ut.
Ott is megvan a L1, L2, L3.
Nem helybol azt a csavot fogod megkapni a problemadra, aki irta HW firmwaret.

Leegyszerusitve az o szemszogebol:
- Te figyelj Bob, van itt egy ugyfel, aki futtat a mi vasunkon egy ismeretlen eredetu OS-t software raid-del. Raadasul a mi HW tesztelo tooljaink nem futnak, vagy azt adjak vissza, hogy nem tamogatott OS/konfig. Mi legyen?
- Adj neki egy udvarias es kelloen tudomanyos valaszt, hogy mi ezt nem tamogatjuk es kesz.

Ezen kivul en branded HW-n sose futtatnek nem tamogatott OS-t. Epp annak az ertelmet veszited el vele, hogy branded szervered van...

van az a helyzet, amikor a rendszermérnök is vonogatja a vállát a branded cucc fölött, na ezt én is tudom és lényegesen kevesebb pénzből..
ezzel csak azt akarom mondani, hogy attól mert valami nagyon drága, még előfordulhat hogy magadra vagy utalva, és ez nem túl megnyugtató.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( hrgy84 | 2013. 03. 07., cs – 18:06 )

En is firtatnam, hogy miert Ubuntu kerult erre a gepre, es miert nem hasznaljatok a hardveres RAID-et. A szoftveres RAID sebessegben nem biztos hogy jobb, stabilitasban plane, viszont legalabb a geptol veszi el az eroforrast, ahelyett, hogy az erre dedikalt kartyat hasznalna.

Illetve ha az Ubuntu nem tamogatott disztribucio, akkor talan nem kellene eroltetni...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem.
Ha van specifikus kernel patch, akkor az jo esellyel a RedHat es a Novell operacios rendszereiben lesz benne, a Canonical altal gyartottakban pedig nem.

Itt elsosorban a gyarto a fontos. A CentOS ugyanazokbol a forrasokbol epitkezik, mint az RHEL, ha valamiben, ott benne lesznek a specifikus patchek. Viszont a RedHat nincs kenyszeritve arra, hogy a Canincial reszere elkuldje emailben a forrasokat (tekintve hogy azok publikusan hozzaferhetoek), a Canonical pedig nincs kenyszeritve arra, hogy a RedHat patcheket is beillessze a kernelebe. Emiatt igencsak keteselyes, hogy meglesznek-e azok a patchek az Ubuntuban, amelyek a RedHat kernelekben megvannak.

Ugyanezt lehet elmondani a Novell/SLES viszonylatrol.

Az Ubuntuban csak olyan patchek vannak, amik
- benne vannak a mainline kernelben
- a Canonical belerakott

Slusszpassz, mas patchek nincsenek benne.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én ha ezt tapasztalnám minimum hogy nem szopatnám magam ubntuval feltolnám supportált os-re szolgáltatásokat.Majd ha ugyanúgy jelentkezne probléma support nem tudná széttárni karját.Ha meg nem égető probléma lenne akkor én vállalnám a saját káromra/megoldásomra ha nem lehetne máshogy megoldani.

http://www.ubuntu.com/certification/server/make/IBM/

"Canonical works closely with IBM to certify Ubuntu on a range of their hardware."

Nem akarom bántani az IBM hazai képviselőjét, de azért én egy kicsit továbblépnék az ügyben. Egy-két levelet biztos, hogy írnék, mielőtt belenyugodnék abba, amit mondtak. Persze csak ráérő időmben. Illetve akkor, ha a szerver szerepel az Ubuntu IBM listáján.

--
trey @ gépház

- hibas raid fw random módon kidobálta a jó diszkeket a tömbből
- bbu töltésnél az akksi túlmelegedett a raid kártyával együtt
(a két cpu-s szervert egy cpu-val rendelték, amihez feleannyi ventillátor járt, így csökkent a hűtési teljesítmény. csak ezt már nem vették figyelembe a raid-karcsinál.)
- gyártótól rendelt konfig sérül szigeteléssel rendelkező, SAS backplane tápkábellel érkezett
- drága, igénytelen minőségű hdd beépítőkeret

Lehetne még sorolni...

Van tapasztalatom Dell és HP szerverekkel is azonos kategóriából, de egyiknél sem találkoztam olyan problémákkal, mint az ibm-nél.

Nem mondtam, hogy a HP az nem lehet szar. Csak saját tapasztalatokat írtam le.
Amúgy meg kár az xSeries-t a SuperDoom-mal összehasonlítani. Szerintem.

Mondjuk engem érdekelne a véleményük, csak kicsi az esély, hogy nyilvánosságra kerül. Főleg, ha "sikertörténet" lesz...

Hát ezaz, az összes gyártó, összes szériájáról lehet mesélni hajmeresztő történeteket. Én szerettem az xSeries-t, igaz az elsőket még akkor láttam, amikor nem is xSeries volt a neve, hanem Netfinity. A HP-val se volt sok bajom sose. Általában az volt, hogy amikor borult valami, akkor valami nem támogatott elem volt a listában.

Általában, ehe.

Pedig ez elég egyszerű hiba, nálunk is előjött, nem fw hiba:
A BBU battery valóban tönkremegy 4-5 év után, ilyenkor - mint minden más akku - felhízik és melegszik. A jelenség valóban az, hogy a jó diszket kidobja hibára a raid vezérlő (nálunk mindig ugyanabban a bay-ben levőt). Az akku cseréjével megoldódik a probléma. Puruttya megoldásnak (amíg megveszed az új akkut) az is megteszi, hogy kiveszed az akkut és kikapcsolod a write cache-t.

3db rack-es és 2db torony szerverből 1 rack-es raid vezérlőjén volt ez a hiba az elmúlt 13 évben, így nem általánosítanék 1 hibából, hogy szarok az ibm szerverei.

A hiba egy féléves és 1 éves gépeknél jött elő.
BBU-t érdemes 2 évente cserélni. Ha jól emlékszem, akkor az LSI szerint a mostaniakat pedig évente.

Régen jók voltak az ibm-ek, de a mostaniakat nem venném meg az biztos.
Szigoróan az xSeries-re korlátozódik a véleményem.

Vannak ár/értékarányban sokkal jobb gépek is.

Amúgy meg, ha nektek bejött akkor jó.

Igy mar ertem, korrekt.

A Supermicronal figyelembe kell venni, hogy nemcsak kevesebb szolgaltatast kapsz, hanem jelenleg (meg?) a szerviz is gazos. Azaz pl. a HP-s figura kijon egy napon belul es megkezdi a javitast, addig Supermicronal a user viszi az eszkozt es hetekig is varhat a cserere akar.

Ettol fuggetlenul ha rendelkezesre all a megfelelo mennyisegu tartalek eroforras, en csak ajanlom, messze azokkal az eszkozokkel tapasztaltam a legkevesebb gondot HP es IBM mellett.
Egy megfelelo koztes alternativa egyebkent szerintem az Intel.

tompos

( rts | 2013. 03. 07., cs – 19:31 )

Az eredeti kérdésekre:
1: Ilyen van? Igen. Tényleg különbözik? Könnyen meglehet.
2: Ha hdparmmal le lehet zúzni vinyókat (én megtettem) akkor a nem megfelelő driverek is képesek lehetnek rá.
--
#conf t
#int world
#no shut

( andrej_ v | 2013. 03. 08., p – 10:28 )

Pontosan milyen vezérlő van ebben?

01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 08)

Ez a SATA/RAID vezérlő (úgy látszik, szakítottak az Adaptec-kel). Én simán használnám a beépített RAID1-et, hadd' örüljenek az IBM-nél. Talán még külön kártyán is kapni ilyet, amit bármilyen gépbe berakhatsz. De RAID1-nél amúgy sem gond, ha nem azonos vezérlőre rakod, nem szokták ezek megkavarni az adatokat, csak letükrözik.
Viszont hogy attól ment tönkre a winyó, hogy nem használtad a beépített RAID-et, azt továbbra is baromságnak tartom.

De tényleg nézd meg a smart adatokat, hogy pl. a Load_Cycle nem emelkedik-e abnormálisan, sok új winyót alapból úgy hoznak ki, hogy agresszívan leparkolja a fejet, amivel ha 24 órában üzemel, viszonylag hamar elérheti az élettartama végét. Lehet, hogy raiddel ezt is "optimalizálja" a vezérlő.

CPU: a mai többmagos procikat teljesen jól ki tudják használni az adott gépen futó alkalmazások, fölösleges velük checksum-ot számoltatni, arra ugyanis relative drágák. Ezen az elven egyébként a ToE is fölösleges, sőt, a grafikus kártya helyett is számoljon a CPU...
I/O: igen,pont az a gond, hogy a szoftos raid esetében tükörnél egy írás az két blokk kitolásából áll össze, raid5 esetén egy blokk írása az áll legalább egy olvasásból, egy checksum számolásból és két blokk kiírásából. Ami pont háromszor annyi i/o, mintha a raid-vezérlőre lenne mindez bízva.

2 gépben most épp 3 HDD-m van (a negyedik cseréje beszerzés alatt) Amelyikben egy HDD van, annak a smartctl kimenete itt: http://pastebin.com/YCuaECc6
Csak most kezdem fölfpgni, hogy mi ez a Load_Cycle. Eszerint csak 33-szor parkolt eddig? (kb 3 hónapos darab)
A másig gépben az egyik, 2 és fél éves, azaz a géppel együtt vett HDD-nek nincs Load_Cycle-je (nincs 193-as jellemző), a másiknak (2 hetes, gariban cserélt darab) 1.

Ez így rendben lévőnek tűnik, jól mondom? Eltekintve attól, hogy a régi HDD-n miért nincs ilyen...

Ez tudtommal egy SAS HBA gyakorlatilag, amiben van opciónálisan használható és bővíthető RAID funkció. Elég nehezen tudom elhinni, hogy A és B diszk külön használata software RAID-el (vagy bármivel) ilyet okoz. Ugyanis a vezérlő nem tudja, hogy a rajta levő diszket épp pont RAID-ben használják. (Igen, az írási mintákból lehet következtetni, de nem hiszem, hogy ilyen tudást integrálnak a vezérlőbe.)

Azt inkább elhiszem, hogy az LSI vezérlő fw-je és a diszkek fw-je nem szerette egymást, de gondolom gyári és belevaló IBM diszkek.