IBM System z-n futó SUSE Linux csökkenti a költségeket, fokozza a rendelkezésre állást a BE-nél

 ( trey | 2008. április 4., péntek - 20:30 )

A növekedés nagyszerű dolog amikor pénzügyi kimutatásban szerepel, de néha terheket jelenthet az IT osztály számára. Az Arkansas állam Fort Smith városában székelő Baldor Electric Co. ipari elektromotor-gyártó vállalat négy fős IT személyzetét a növekedés néhány évvel ezelőtt legyűrte. A kis létszámú csapat egyszerűen nem tudott lépést tartani az x86 szerverek növekvő számával, hiszen minden szerver saját hálózatot, energiaellátást igényelt, mindegyiket patch-elni, frissíteni kellett. Súlyosbításként a hálózat nem volt homogén, Windows és UNIX szerverből állt. A rendszerben gyakoriak voltak a kiesések, amelyeknek a költségei jelentősek voltak. Egy órás állás kb. 100K dollár veszteséget jelentett. A cég egy évben 5-8 nap kieséssel számolt.

Ahelyett, hogy még több embert vettek volna fel és még több szervert állítottak volna csatasorba, Mark Shackelford a cég IT osztályának alelnöke más taktikához folyamodott. 2005-ben elindított egy tesztprogramot a cégen belül SUSE Linux Enterprise 8 operációs rendszerrel. A tesztek annyira beváltak, hogy 2006 elején a Baldor az egész rendszerét átállította 9-es SUSE Linux-ra (feltehetően SLES-re, de a cikk erre nem tér ki). A Baldor ma 58 virtuális szervert futtat egy IBM System z-n futó SUSE Linux Enterprise 10 terjesztésen. Az egész rendszer üzemeltetését egy ember végzi. Rajta kívül egyetlen ember dolgozik még a backup-on.

A sikersztori itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ezek szerint két ember elvesztette az állását?

Ez érdekesen hangzana... és ha az az 1 ember elmegy nyaralni?

És azóta nem kell patchelni, meg frissíteni. És boldogan éltek, míg meg nem haltak.

de kell, csak egy gépet, a többit a zlm elintézi

IBM system Z series: makes you homeless?

Nem tudom, nekem ez egy kicsit olyan (x)-es ízű cikk, az IBM a System Z ilyen felhasználását "önerőből" is szokta propagálni erősen.
Egyébként egyetértek vele, szerintem is van létjogosultsága (elég sok helyen ráadásul) az ilyen megoldásoknak az elburjánzott x86 "szerverfarmok" helyett, főleg úgy, hogy egyre jobbak a virtualizációs lehetőségek.

Úgy fest az üzemeltetőknek nincs családjuk. Kicsit necces, hogy 2 ember üzemeltet 58 gépet (és most itt teljesen mindegy szinte, hogy virtuális -e vagy fizikai).

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

A két ember legfeljebb azért lehet necces, mert ennyivel nem lehet folyamatos üzembentartást garantálni (szabadság, betegség, készenlét, stb). 58 gépre nem feltétlenül kevés, nagyban függ attól is, hogy milyen jellegű az üzemeltetés (csak OS üzemeltetésre még akár két ember is sok lehet 58 gépre).

ibmnél 20-24 szervert számolnak egy emberre, nem csak os.

Az nem kicsit rohejes, hogy egy 4 fos csapatban van "IT osztályának alelnöke". Akkor van elnok, meg csopvez, meg egy Nemecsek.
Nekem a .... jon ki a cimezgetes. Ha arrol van szo, hogy felelosseg, akkor sima manager vagy, ha me beremeles, akkor staff.

Szerintem az osztalynak vezetoje van nem elnoke :)
Vagy a ceg IT alelnoke :)

aki rendelkezésre állást akar clusterezzen. már két géppel jó: egyiket lelövöd, frissíted, csere, goto 10. a system z meg a hw rendelkezésre állást biztosítja, menet közben cserélhetsz procit is.

Nem csak a system z -ben tudsz cpu -t cserélni. Csak konfiguráld már ki az OS alól a CPU -t... Az már közel sem olyan egyértelmű dolog. Tudom, hogy a linux kernel már experimental szinten támogatja a cpu menetközbeni cseréjét, de ez akkor is necces szerintem. Az egyértelmű, hogy cluster megoldással jelentősen növelhető a rendelkezésre állás, de akkor is kevés a két ember. Meg mi van akkor ha villámcsapás éri, megtámadják, stb... azt az egy darab system z -t? Nem kellene úgy kialakítani a redundanciát, hogy fizikailag más telephelyen/szerverteremben/bárhol legyen még egy system -z?

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

mvs alól ki lehet :) mainframeztél? ha nem, akkor ráhibáztál a konfiggal :)
display m=cpu aztán config cpu(x),offline
de ha clusterben vannak akkor rebootolgathatod a linuxot, amíg nem tudja ezeket menet közben. ja a két ember furcsa, hogy lett a négyből.

másik fizikai gép: volt olyan ügyfél, akinél az volt a szerződésben, h a két s390 minimum 1,5 km távolságban legyen egy telephelyen belül :) van most x series-en vmware esx alatt tizenx lpar linux/windows. behalt alatta a scsi vezérlő, 3 lpar hulott le miatta. itt is azt hitték majd az egy nagy vas + virtualizáció mindent visz és akkor nem kell bele duplán/triplán a vezérlő(+hálókártya, stb.).

Solaris alatt is ki lehet konfigurálni az alaplapot/processzort/memóriát...

ja, linux alatt megy a processzorcsere is. Most próbáltam ki egy ubuntuval. Elszedés, hozzáadás simán megy. Igaz, hogy egy virtualizált környezetben, de csont nélkül megy.

szerk: Visszavonom. Próbáltam hozzáadni +20 processzort, és a linux elszállt a 'csába...

én csak arra lennék kiváncsi hogy mennyibe került az a system-z rendszer. :>

Core2Duo T7100, 2.5G, Ubuntu 7.10, 2.6.22

Nem olyan vészes, ha megnézzük, hogy sok energiát, munkát és helyet lehet megspórolni vele elvileg.

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

Egy Mainframe nagyon megbízható rendszer és egy nagy vállalat IT üzemeltetési költségeit ténylegesen tudja számottevően csökkenteni. Csak hogy! Egy nagy bőkkenő van, amit én látok, az pedig az hogy nem támogatja azt a fránya MS-t. Így sok cég, nagyvállalat nem használja ki ezt az előnyét. Imitt-amott feltűnik egy-egy MF rendszer, de az mind speckó alkalmazásokhoz van, nem pedig szerver konszolidációra.
Ezek a példák mind nagyon szépek, de ott van mögötte hogy UNIX és Linux rendszereket tudnak csak kiváltani.
Persze favágó módszerrel Linux+VMWare-el lehet linuxot erőltetni rá, de lássuk be az már nem ugyanaz. Ráadásul abban az esetben többletköltségek is jelentkeznek (VMWare licensz, ennek üzemeltetése, az alkalmazésok külön VMware-s tesztelése...) és máris nem éri meg.

Amit én látok az az, hogy a Mainframe-et csak ott nem szórják ki, ahol a rajta levő szoftvernek nincs unixos v. linuxos portja...
Amit a mainframe-ek már 20 éve tudnak, lassan megjelenik a linuxban és unixokban. N

Ott szórják ki ahol nem értenek hozzá...
Nyilván olyan rendszert érdemes rá tenni, amelyhez követelmény a magas rendelkezésre állás, megbízható műkésnek biztosítása. Továbbá a legfinomabban is egy MF skálázható.
Hidd el, hogy egy olyan rendszer üzemelésekor jobb 1db MF-en csücsülni, mindeféle szempontból, mint 20-25 darab x86-os architektúrán... amiket akárhogyan clusterezhetnek (plusz költség árán), akkor se tudják azt a szintet biztosítani.
Hangsúlyozom, az alkalmazás oldaláról (tényleges üzleti igény) kell vizsgálni a dolgot. Ahol ezt a szintet megköveteli, oda továbbra is tartom hogy hiba x86-osok hadát rendbe állítani;)

"Hidd el, hogy egy olyan rendszer üzemelésekor jobb 1db MF-en csücsülni, mindeféle szempontból, mint 20-25 darab x86-os architektúrán"

Ezt eszembe sem jutott. Vannak olyan unixos vasak, amik nem a klasszikus mainfram-ek, (ibm P575, p595, Sun E20K stb.) Ezek stabilitásban és teljesítményben hasonlóak az MF-ekhez, viszont árban jóval olcsóbban.

Ahol meg tényleg szükség van stabilitásra, ott még mindig Tandemeket használnak. :)

a Tandem es a MF rendelkezesreallasa hasonlo, de a Tandem (ujkletu neven Non/Stop) meg az MF nel is dragabb.

Ezzel nemfeltetlen ertek egyet.
Nemi raforditassal: redundans ethernethelo, multipath FC SAN (esetleg multipath iSCSI) lehet igen magas rendelkezesre allast kihozni x86/ESX bol, raadasul ugy hogy alkalmazasoldalon nem kell clustertamogatas.

a magas rendelkezésre állásnak csak egyik eleme a hardver. Én azt tapasztalom, hogy egy bizonyos minimális szintet átlépve a váratlan leállások 95% -a nem hardveres, hanem szoftveres eredetű, ezeknek is 80% -a nem "spontán", hanem emberi beavatkozás miatt követezik be, pl. valami félresikerül egy migrációnál, patch-elésnél, akármi. Ezeken a dolgokon nem segít az se, hogy a hardvert megbízhatóvá teszed és az sem, ha ESX clusteren futtatod, csak alkalmazás-specifikus cluster megoldásokkal lehet rá felkészülni, már ha egyáltalán. Itt már az sem oszt/szoroz sokat, hogy az alkalmazás cluster 2 node-ja esetleg ugyanazon a gépen van.

Flops /core ?
Integer unit / core ?