AIX vs. SUSE Linux Enterprise

 ( chx | 2015. február 10., kedd - 19:55 )

Üdv,

újabb felmérés a SUSE háza tájáról: https://www.suse.com/promo/unix-to-linux-aix-wp.html

Hogy gyorsabb legyen: http://www.files.com/shared/54da405ea64e0/migrating_from_power_aix_to_x86_sles.pdf

Ok, Linuxé a jövő, vannak is bajok AIX-szel (kedvenc szívásaim pont a HACMP, meg hogy ipcrm nem képes takarítani és reboot kell), de ez így akkor is durva:

70-80% reduction in TCO
99.99% availability (na jó, akár)
60% performance improvement

Esetleg akinek van ezzel tapasztalata megoszthatná, én kételkedem egy picit.

Köszi.

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ő.

Ahogy én látom, pont foglalkozom ilyesmivel mostanában.

A Power/AIX párosból nagyobb, egy dobozban lévő számítógépet lehet építeni, mint x86/Linux párosból. Ez nagyon-nagyon ritkán előny, olyasmi esetekről van szó, mint amikor egyben kell 100+ processzormag meg 1TB+ memória valaminek.

A Power/AIX páros robosztusabb, mint az x86/VMware/Linux hármas. Viszont a Power/AIX/alkalmazás hármas nem feltétlenül robosztusabb, mint az x86/VMware/Linux/alkalmazás négyes. Ha nem valami béna őskövület alkalmazásod van, ami semmiképpen nem tud kiskálázódni egy dobozból, akkor az x86 vonal messze jobb.

A Power/PowerVM/AIX tényleges ára nem feltétlenül sokkal magasabb, mint az x86/VMware/RHEL ára. Ezt szerintem sokan nem így látják, de így van.

A PowerVM egy nagyon nagy előnye a VMware-rel szemben, hogy az Oracle elfogadja az LPAR-okat, mint licenszhatárokat a termékei licenszelésekor. Így AIX esetében vehetsz mondjuk 1 socketre vagy 1 core-ra Oracle termékeket, x86 platformon meg általban megszívod, és minimum 2 socketre vagy 12 core-ra kell licenszelned, akkor is, ha raksz rá egy olyan VM-et, aminek csak 1 vCPU-t akarsz adni. Így Power-en sokkal olcsóbb tud lenni egy kisebb méretű Oracle telepítés.

Szóval ez egy nem lejátszott dolog, mindkét platformnak van még létjogosultsága.

Az egy más kérdés, hogy a személyes preferenciáim szerint a teljes p platformot, AIX-estül-mindenestül kidobnám a világból is...

+1
Power/PowerVM/AIX mindaddig szep es jo, amig az ember nem akar modern es/vagy custom applikaciot feltenni ra, mert akkor kezdodik a kuzdelem a regi libekkel, inkompatibilitassal, stb. Olyan dolgokkal kell tokolni, ami a linux vonalon reg nem problema (pl. kedvencem az 1GB-os filemeret hatar es tarsai 2015-ben).
Nem csoda, hogy AIXot mar szinte csak DB2/Oracle es WebSphere ala tesznek...

Performance szempontbol viszont utosek a Power procik (SMT8 miatt pl.), de ha nem koncentraltan kell a nyers ero, akkor sok olcso x86-ossal kompenzalhato, bar az meg a sok core miatt nem elonyos licenszelesi szempontok miatt.

Mondjuk ezt a per core licence-et se tudom hová tenni. Veszek egy software-t, és nem egy software-t hardware-rel (és az abból fakadó limitációkkal) együtt. Kinek mi köze hozzá hogy milyen gyorsan akarom futtatni?

Az még ok ha mondjuk user számot, vagy database méretet limitálnak, na de plusz lovetta csak azért mert izmosabb vasat (több core) tolok alá?

____________________
echo crash > /dev/kmem

Miért fizessen az ugyanannyit, aki 1 core-on futtatja az alkalmazást, mint aki 120-on?

Miért ne fizessen ugyanannyit a termékért? Pont ugyanazt használja, csak éppen 120 core-on, aminek viszont kifizeti az árát (HW).

A per core analógiát követve legyen drágább pl. minden játék is, ha erősebb vason fut? Tudom más kategória, de a per core licence sehogy sem logikus nekem.

____________________
echo crash > /dev/kmem

Nem ugyanannyit használja: 1 core oracle licenc egy kis fejlesztői rendszer, 120 core pedig egy közepes vállalat teljes infrastruktúráját magában foglalhatja.

A per core licencelés vállalati termékekre vonatkozik, nem értem, hogy a játékok hogy jönnek ideje.

Hát lehet, hogy ez neked így logikus, de előttem felszólalóval értek egyet abszolút. Már csak azért is, mert a CPU mag egy eléggé kevéssé behatárolható fogalom, ha csinálsz mondjuk egy olyan hypervisor-t, ami mögött tök 8 hány proci áll, ő egy überbrutkót mutat majd a vm felé, akkor az mi?
Avagy 1 mag egy 486DX2 is, meg egy Pentium 4 is. A kettő között van némi sebességkülönbség.

Arról nem is beszélve, hogy amúgy a szolgáltatások listája ugyanaz, szóval a szoftver bizony 99%ban hasonló műveleteket fog végezni.

FathoM

"Avagy 1 mag egy 486DX2 is, meg egy Pentium 4 is. A kettő között van némi sebességkülönbség. "

Erre vannak a licenc szorzóban korrekciós faktorok. (nyilván ez is torzult valamennyire)

"csinálsz mondjuk egy olyan hypervisor-t, ami mögött tök 8 hány proci áll, ő egy überbrutkót mutat majd a vm felé, akkor az mi? "

Tudnál mutatni erre egy konkrét példát?

"Arról nem is beszélve, hogy amúgy a szolgáltatások listája ugyanaz, szóval a szoftver bizony 99%ban hasonló műveleteket fog végezni."

Miért lenne ugyanaz? Annyi példányt futtatsz a szoftverből ahányat szeretnél különböző szolgáltatásokra, hiszen _core_ alapján licencelődik.

"Erre vannak a licenc szorzóban korrekciós faktorok. (nyilván ez is torzult valamennyire)"

Jó tehát igazából az egész nettó lehúzás...

Nem tudok rá mutatni példát csak felmerült bennem, hogy mi akkor ki fogja és hova kenni a licenszet, ha egy ilyen csinál valaki. Mondjuk érzésre ezért sem hajlandóak x86-on 1 magra licenszet adni.

Azért ugyanaz, mert mondjuk az Oracle 11g, 1 magra és 1000re is ugyanazt az adatbázist fogja adni, a különbség sebességben lesz és nem azért, mert DB kódja annyira fasza, hanem azért, mert több alatta a kakaó.

FathoM

Mi lenne szerinted a korrekt megoldás licencelésre? (ami ugyanezt a revenue-t biztosítja a gyártónak)

Szerintem teljesen korrekt a core alapú licencelés. Szerintem az Oracle esetében két dolog nem korrekt:

- a core-onkénti ár, de ez nem az Oracle hibája, hanem a többi töketlen adatbázisgyártóé, hogy nem csinálnak Oracle tudású terméket az ár töredékéért
- az elhatárolások, hogy mely core-okra kötelező megvenned a licencet, ez az Oracle hibája és el kellene fogadniuk a többi gyártó elhatárolási technikáit (pl. VM vCPU-inak száma VMware/Hyper-V esetében, vagy jobb esetben mondjuk valami cgroups alapú megoldás)

Az, hogy mi mennyi pénzt hoz a gyártónak kicsit más tészta, bár nem nagyon. Ha drágán akarják adni ám legyen, de véleményem szerint semmi közük hozzá, hogy az eladott szoftverjüket én min futtatom.
Amúgy pl ha már így akarnak játszani, akkor ne szoftvert áruljanak, hanem mondjuk egy adott számítási teljesítménnyel működő DB-t, szállítsák ők a HW-t, a supportot, a rendszergazdát és minden egyebet. Akkor nem az én vasamon fut nekik kell garantálni a teljesítményt. Ott lehetne nem ilyen agyament módon lehúzni a vevőt.

FathoM

Parancsolj:
https://cloud.oracle.com/database
https://www.oracle.com/engineered-systems/exadata/index.html

BTW analógiával élve a gyártó ne mondhassa meg, hogy a szoftverét:
- hány szerveren/kliensen használhatom
- hány felhasználó használhatja egyszerre

Igen, az Oracle licencelése maga a lehúzás mintaképe.

Egyrészt elég drága, az Enteprise Edition licenc egy Power-es vagy 2 x86-os core-ra (nem socketre, core-ra) kb. 12 millió Ft listaáron + 22% követés évente. (És a licencben nincs benne az első éves követés.) Ha akarsz HA-t is, akkor a RAC-ot ehhez külön meg kell venni, core-onként kb. 6 millió Ft-os listaáron + 22% követés évente. Ha akarsz Diagnostics, Tuning, Partitioning, Advanced Secuity, Advanced Compression vagy hasonló hangzatos nevű feature-öket is, akkor az mind-mind core-onként 1-2-3 millió Ft licenc listaáron + 22% követés évente. Tulajdonképpen nem is ismerek más szoftvert, ami nem felhasználó alapon licencelődik és ennél drágább lenne. (Az IBM egyes termékei rúghatnak még labdába, de általában ez alatt maradnak az áraik.)

Másrészt marha rosszindulatú a dolog. Tegyük fel, hogy van 2 blade keretnyi, 32 db, egyszerű, 2 socketes x86-os blade-ed. Ezeken legyen VMware. A vCenter-edben 2 db datacenter van felvéve, mindkettő alatt 2 db, összesen 4 db cluster, clusterenként 8-8 blade. Az egyik clusterben csinálsz 1 db VM-et 1 db vCPU-val és erre a VM-re Oracle-t akarsz telepíteni. Mennyi Oracle licenct kell venni ehhez? A válasz egyszerű: a vCenter alatti _összes_ core-ra meg kell venni az Oracle licenct, azaz kb. 192 példányban (!!!) kell a fentebbi összeget kifizetni. (Nyilván lehet optimalizálgatni, nem virtualizálni az Oracle szervereket, Oracle alapon virtualizálni az Oracle szervereket, külön vCenter alá rakni az Oracle szervereket stb. - ezt csinálja is mindenki.)

Egyelőre urban legend-ként kezelem, de már olyat is hallottam, hogy ha egy storage-ra rakod az Oracle adatbázist, akkor az Oracle véleménye szerint az összes olyan szerverre meg kell venned az Oracle licenceket, amely rá van kötve valahogy a storage-ra. Ezt azért erősen remélem, hogy nem gondolják komolyan.

"...Igen, az Oracle licencelése maga a lehúzás mintaképe..."

Volt honnan tanulniuk (SAP).

Valahogy szegmentálni kell a piacot. Ezek nem olyan szoftverek amiket tízmillió-számra vásárolnak. Van egy szűk kör amely azért mert a múltban is erre az adatbázis szoftverre épített vagy más okból de igényt tart rá. Mivel az adatai értékesek számára és van is pénze rá, hajlandó megfizetni a 120 core-os árat.
Most miért ne szedje be a nagyobb pénzt a fejlesztő cég?
Ha 1 core-os áron adja mindenkinek, akkor a szűk vevőkör miatt hamar azt fogja tapasztalni, nincs pénz a további fejlesztésre. Az pedig senkinek nem lesz jó. Vagy adja 120 core-os áron mindenkinek de megkötések nélkül? Akkor pedig kis partnerek szopnak és az erre fejlesztők, akiknek elég az 1 mag.
Ha kevés számú vásárlóból álló piacra fejlesztesz aránylag drága költségű szoftvert nem gondolkozhatsz úgy mintha játékot fejlesztenél az AppStoreba meg Playre.

Ha kevés számú vásárlóból álló piacra fejlesztesz aránylag drágán, akkor úgyis egyedi árképzésre leszel kénytelen berendezkedni, azaz kb. arcra árazol (= lesz egy jó húzós listaár, és mindenki kap belőle kedvezményt, nyilván annyit, amennyit ki tud sírni), hiszen az a cél, hogy mindegyik ügyfélről pont annyit gombolj le, ami még éppen nem fáj neki túlságosan.

Elég nagy szégyen, ha bootolgatni kell egy aixet. :) http://www.aixmind.com/?p=647
A HACMP biztosan tudja, amit kell. Bár manapság inkább valamilyen PAR segítségével oldanám meg.
(Még 1996-ban mondta a rendszerünkről Dr. Szabó Balázs - IBM: "Láttam már 32 pécét összekötve, vásároltak többen HACMP-t, de hogy 128 munkahely HACMP alatt, business critical rendszer, és még működik is, ilyen Európában nincsen!")

Szóval a magánvéleményem közel 20 év AIX (rendszer-)programozói és üzemeltetői tapasztalattal a következő (AIX 3.2.5...6.0):
Szerettem ilyen rendszereken dolgozni, mert csak le kellett ülni és elvégezni a munkát. Ugyanez linux alatt általában nyomozás, fórumozás és szíváshalmok során valósult meg. Biztosan én vagyok a felkészületlen, bár linux kernelbe (csak saját magamnak) már a 0.8x verzióban írtam, illetve annak idején SCO alatt dolgoztam.

A SLES/RHEL általában összevethető az AIX rendszerekkel. Ezek a linuxok, - mivel üzleti rendszerek - elég jól dokumentáltak, de az AIX mégis jobb.

70-80% reduction in TCO
Egy raspáj szerver meg sokkal olcsóbb. :) Komolyra fordítva a szót: ha az üzembe helyező nem ért a rendszerhez, akkor bármelyik borzasztóan drága.

99.99% availability (na jó, akár)
Ennek semmi köze a SLES-hez! Mindössze a hw platform rendelkezésreállása. Jó-jó, azt meg az oprendszer támogatja. Tapasztalatom szerint AIX alatt akkor volt leállás, ha nem volt villany. Ez azért bármilyen cég részéről némi parasztvakítás, mert hol is van az alkalmazás...

60% performance improvement
:)) De most komolyan!

Tudom, kicsit elfogult vagyok, de míg az AIX eleve B2 biztonságúnak készült, addig a dinamikusan fejlődő linux úgy 15 év alatt utol is érte. Azaz összerakható már olyan disztró, ami hasonlókat tud.

Ha elfogadjuk, hogy a POWER nem win futtatására készült, akkor kifejezetten előny, hogy a hardver és az oprendszer "támogatják egymást", és nem kell az ajánlott szerverek listáját böngészni. (Bár ezen a platformon egy-két év késéssel már a linux is majdnem megvalósítota a hotswap kezelést.:))

Viszont szempont lehet az is, hogy már 20 éve is attól fájt az IBM feje, hogy a felhasználók gcc-vel készült alkalmazásokat szerettek volna futtatni. Miközben az AIX alatti dolgok igen jól hordozhatóak - gyakran akár bináris alapon is, - illetve a systemV, bsd, mainframe platformokra készült programok is jól migrálhatók.

En inkabb gyakorlati oldalrol kozelitenem meg a kerdest.

Melyikkel lehet egy parancsal FS-t novelni?
Melyikkel lehet egy parancsal SAN LUN-t torolni?

Majd ha ezeket a SuSE Linux tudja akkor szoljatok!

Es en egy baromi nagy SuSE fan vagyok 7.3 ota.

az mit befolyasol, ha x rendszeren 1 paranccsal lehet FS-t novelni, a masikon meg mondjuk 2-vel?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Mennyit kell gepelnem es hibat elharitani...

ezzel nem ertek egyet. Pl. lehet hogy egy parancs, de kisezer parametert kell megadnod, az elgepeles esenye nagyobb mint ket rovid, de keves parametert igenylo parancs eseten

mas kategoria az AIX es mas a SUSE Linux Enterprise; mar maga az osszehasonlitas is ertelmetlen ebben a formaban X vs Y - szerintem.
X,Y: szabadon valaszthato parameterek

a filesystem novelese, lun torlese, etc. tipikusan olyan muveletek, amiket joesetben nem 5 percenkent kell elvegezni, igy az ezekhez szukseges parancsok hossza, karakterigenye (meg egyszer: 1 vs. 2 parancs) aligha szamit barmit is...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Jo neked!

Nalunk azert van rendesen. Tobb ezres szerverszam ...
Es voltam olyan szerveren ahol tobb ezer LUN volt!

Az én shellemben van alias, meg tud shell scripteket futtatni... ;)

Roppant egyszerű. Az egyik rendszeren már kidolgozták, a másikon meg még nem.
No, ez az eltérés a két rendszer között. :)

Csak egyszer kértem, hogy map-pel rakjanak fel nekem egy fs-t. Aztán rögvest hülyének néztek...

Amikor béke van, semmit, de elég a csúcson túl szaladt rendszer ahhoz, hogy az ember az orvosláshoz ne akarjon még 10 karaktert beírni, illetve még egy plusz processzt a rakásra dobni.

Sajnos nem elméleti a forgatókönyv.

eegen, lehet. Bar mire egy ilyen forgatokonyv kialakul, addigra jopar seggnek pucsitva kell varnia a tusarku gumicsizmas buntit...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Így van, de a (jogos) hibáztatás megoldás gyanánt legfeljebb a közszolgálatban elfogadott - a magánszférában csak kiegészítő tevékenység, MIUTÁN helyreálltak a dolgok.

(Egyébként leggyakrabban méregdrága middleware-ek egzotikus bugjai emelik egekbe a loadot - tkp. nincs az az elővigyázatossági lépés, ami után az ember kijelentheti, hogy ilyen soha többé nem lesz.)

(Egyébként leggyakrabban méregdrága middleware-ek egzotikus bugjai emelik egekbe a loadot

tudsz egy ilyenre peldat mutatni? Btw nem ugy ertettem, hogy a hibaztatas a megoldas *helyett* van (foleg nem egy ilyen esetben), hanem hogy azert legyenek kiosztva a jol megerdemelt fakkok

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Message Broker: a világ legdrágább memórialyukai közé tartozik.

+1.

Úgy alapjaiban nagyságrendekkel jobb a device kezelés is AIX-en mint Linuxon. Ráadásul egy csomó hasznos tool van.

Kicsit kiegészítve: azt a szignifikánsan szűkebb eszközarzenált, ami az AIX esetében szóba jöhet, elegánsabban és koherensebben kezeli, mint a linux az általa kezelt parkot.
Ráadásul egy csomó hasznos tool van AIX-en, ami linuxon nincs, és a zárt forrás miatt nem is lesz, és egy csomó hasznos tool van linuxon, ami AIX-re portolva használhatóbbá teszi azt.

Ráadásul lehet FS-t csökkenteni (ráadásul egy paranccsal) AIX-on online!
Egy másik gyakran használt feature pl. LUN méretének növelése után (rootvg is már jó ideje) az OS is képes felismerni, szintén 1 paranccsal, hogy megnőtt alatta a terület, volume group-ban megjelenik a szabad hely (nem ez az általános gyakorlat, de ha nem akar sok PV-t egy VG-ben egy idő után...). Linux alatt is meg lehet csinálni utóbbit, de több parancs, elsőre nem triviális, és sajnos csak fórumokban lehet megtalálni a disztrónak megfelelő módszert, hivatalos dokumentációban nem szerepel enterprise disztribúcióknál sem (RHEL, SLES).

A hardver + OS-ek más célra, más időkben készültek. AIX LPAR környezetben lehet dinamikusan memóriát, CPU adni-venni, fizikai adaptert (PCI-X, PCIe) működő OS által támogatottan cserélni, ha redundáns a kialakítás, nincsen kiesés. Linux + x86-ban ezeket más szinteken lehet megoldani...

Nem csak.
Pl. több os-hez rendelt csatolót lehet cserélni/migrálni úgy, hogy egyik os-hez sem nyúlsz hozzá.

> Ráadásul lehet FS-t csökkenteni (ráadásul egy paranccsal) AIX-on online!

En is mindig erre hegyezem OS valasztaskor:)

Oké, ritkán kell, de ha kell, akkor nagyon tud fájni a hiánya... 1-2TB-os diszkből elvenni 1-2-300 GB-ot nem egy élmény Linuxon - csináltam, tudom.

Ezeleve ez az "_A_ linuxon" ertelmetlen. Gozom nincs mire erted ez. Pl. egyaltalan melyik fs? Mi az az elvenni, az fs-tol v. talan ott mar a volume-bol, vagy raidrol van szo, mifelerol?

Masreszt igen, ritkan. De meg ha nem is igy lenne. Azon a piacon, ahol az AIX mozog, nem faj, ha be kell rakni +1 , h ne kelljen elvenni a masiktol, vagy nem faj berakni +1 gepet, h migralos jatekkal megoldja a problemat az L1 op.

Gombhoz kabatot, rohog a vakbelem.

Van egy 1.2TB-os VG, 150-től 320GB-ig terjedő méretű pv-kből összerakva. 90% fölött van rajta az fs telítettsége, tehát kell ennyi hely. Egy szép napon leköltözik róla 300G-nyi adat végleg, azaz egy 320GB-os pv-t oda lehet adni másnak. Ez alkalmazás leáll, umount, fsck, fs összenyom, pv-ről a használt blokkok elmozgat, vg-ből a pv kihajít, mount, alkalmazások indulnak. (Tudom, az fs összenyomása után már indulhat a móka, de az app. I/O igénye miatt inkább nem)

Amit irsz teljesen korrekt szerintem, nem latom kardinalis problemanak.

Szerintem mind a ketto megoldhato egy paranccsal Linux alatt is. Ellenben az online FS csokkentes nekem nagyon hianyzik.

--
http://blog.htmm.hu/

JFS2 rulz?

Ezt ne csináld AIX alatt. Legalábbis akkor ne amikor IBM Tivoli HSM is képben van. Belassul, kilőhetetlen és reboot a vége.

Ha valaminek a neve ugy kezdodik, hogy IBM Tivoli akkor attol mar alapbol ki szokott razni a hideg es semmin sem lepodok meg :)

--
http://blog.htmm.hu/

Anno a lótusznótusz kliens is azt mondta, hogy bootoljunk re, mert ő nem bír elindulni - aztán csak néhány ipc-s szemetet hagyott a korábbi futtatás maga után...

majd ha Süsün lesznek ilyen alap dolgok mint például
normális LVM (ilyen alapdolog mint pl ha van rajta PVID ne írok rá csak ráforceolval)
normális FS (pl online defrag, normális naplózás külön loglv-re)
errpt
diag
csomagkezelésnél commit
mksysb
stb...

Egyébként hány AIX LVM-nél fiatalabb olvasója lehet a HUP-nak?!

ha a kocsog ibm nem csak a jfs-t adja, hanem a jfs2-t is... Bar a zfs azert mar pariban van a jfs2-vel, imho...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Ennél azért jóval többről van szó!
"pariban van" - ez nem a "melyik a legjobb fs" verseny.
AIX alatt a diszkek kezelésének +1 rétege létezik a többi oprendszerhez képest. Ezzel szemben a linux lvm két irányban is bejárható, de még nem jöttem rá mire is jó. Mindenesetre nagyon felületes kezelést tesz lehetővé. (Talán azért, mert az aix csak scsi diszkeket kezel? Ha mást olvastál az lényegtelen. Csak akkor van igazad, ha kipróbáltad. :))

Szóval egy példa: Mondjuk a gondos tervezés miatt :) hirtelen meg kell növelni a diszk kapacitást. Nem írok fs-t, mert az mindegy! Ezért hirtelen hozzáadok némi diszkeket. Aztán a kisebb terhelésű időszakban online migrálom az előbb megnövelt ojjektumot, hogy megfeleljen az eredetileg meghatározott tárolási stratégiának. (migratelv)

Ez a fícsör 19 éve már menüből elérhető volt. Akkoriban éppen egy 176 diszkes konfigurációhoz adtam tanácsot. Kérdés, hogy ma vannak-e hasonló fogalmak és kezelési lehetőség a linuxban. Még ha kiforratlanok is?

Ja és a linux alatti jfs != az aix alatti jfs. És a legfontosabb kérdés: Mi van, ha nincs is szükség fs-re?

(Meg még van-e oprendszerbe épített mirror3, splitlv stb.)

176 diszk 1 gepben?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

JHBBOD?

Miért ne? Nem sok az, csak a pécés világban tűnik annak... 11 darab 7133-020 SSA-doboz nem sok - volt szerencsém hasonló méretekhez: amikor 4.5 meg 9GB-os diszkek számítottak nagynak, akkor szerinted 1TB-ot hogy és hány diszkből raktak össze? Szép meló volt megtervezni, összerakni, az egyszer biztos.

jogos, vegul is az aix-bol is lehet nfs szervert csinalni ;-)

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Mondom, hogy ne a pécés bizbaz világban gondolkodj - anno 1TB egy komplett adattárház mögötti tárkapacitás volt, jóóó sok, akkor nagynak számító, de a szükséges nettó kapacitáshoz képest meg k.pici diszkből összerakva.

Miért ma nem így van ? Csak a számok változtak, nem is olyan rég felmerült hogy 1PB tárolása, hogy lehetne. 4T-s diskekből is minimum 250 kéne. Mondjuk ma már PC-s világban is elérhető, sok lemez. Synology storage (ami kb egy pc) 106 lemezig bővíthető.

Fedora 21, Thinkpad x220

De, nagyjából így van - csak anno ez DAS volt (SSA rulez), most meg inkább SAN-ba tolnak be sok diszket, és onnan kapja a gép a megfelelően kialakított (fizikai diszk paraméterek, raid-level, méret) lun-okat.

vagy nem san, hanem nas. Es nem pc-kre gondolok...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

A téma szempontjából mindegy, hiszen arról volt szó, hogy 176 darab diszk direktben egy gépre kötve. (Mondjuk ha azt nézem, egy NAS/SAN eszköz sem más: van egy (vagy több) számítógép (kontroller), amin valamilyen OS fut, és erre a gépre vannak rlógatva a diszkek, amit a gép a "másik oldalon" elérhetővé tesz blokkos eszközként vagy komplett fájlrendszert tartalmazó meghajtóként.)

Ennél sokkal rosszabb a helyzet!
176 diszk 2 gépben úgy, hogy mindkét gép tudja használni. Egyszerre. Ez majdnem olyan jó, mint a C:.
De ez egy elavult 1995-6 környéki technológia.
2000-ben már a diszkekhez saját routert is lehetett használni. Pl. mentés a "diszk hálózaton" az informatikai hálózat mellőzésével.


Szóval egy példa: Mondjuk a gondos tervezés miatt :) hirtelen meg kell növelni a diszk kapacitást. Nem írok fs-t, mert az mindegy! Ezért hirtelen hozzáadok némi diszkeket. Aztán a kisebb terhelésű időszakban online migrálom az előbb megnövelt ojjektumot, hogy megfeleljen az eredetileg meghatározott tárolási stratégiának. (migratelv)

Azert PV-t migralni Linux alatt is lehet, de az teny, hogy az AIX LVM rugalmasabb. De akkor visszakerdezek: lvreduce? Az FS most mindegy!

--
http://blog.htmm.hu/

Ezt amiről beszélsz AT&Tnél nagyjából heti rendszerességgel csináltuk Linux alatt. Senkinek semmi baja nem volt, még azzal sem, hogy nem egy parancs, szépen összeraktunk hozzá pár szkriptet és rögtön egy parancs lett. Már aki mondjuk használta (mivel a céges jog szerint a rendszergazda elméletben nem csinálhat/futtathat szkripteket).

De még a használatuk nélkül is az AT&Tnél van 40k+ linux rendszer (99%ban RH), ezeket 3x20-25 rendszergazda (FTS rendszer, 20-25 fős csapat egy helyen) tartotta/tarja működésben. Ugyanott akkor volt nagyjából 10k AIX (mivel nagy részét már akkoriban migrálták Linuxra), azokra pontosan 3x annyi ember kellett. Arról nem is beszélve, hogy mennyivel nehezebb AIX rendszergazdát találni.

Szóval lehet, hogy a saját háza táján elegánsabb az AIX, de igazából nem ezek a döntő érvek egy OS mellett.

FathoM

Nem kell oda 3x annyi ember, csak 1x annyi hozzáértő szaki. A cociban, Linuxban és Windows-ban tudod mi a közös? Mindenki ért hozzá. Az AIX-hoz meg nem :-P

Igen az elején én is azt hittem, de aztán kiderült, hogy abból a helyszínenként 60-90 emberből, akik ezzel foglalkoztak kb. a fele tényleg hozzáértő volt (a másik fele kb kezdő 1-2 év tapasztalattal, őket pont azért vették fel, mert rájöttek, hogy a maradék IAX migrálása nem lesz meg az adott idő alatt és ezért biztosítani kellett a supportot hosszabb távra). A szakértők között meg volt csak a pozsonyi központban 5, akik tényleg kb IAX istenek 20+ év tapasztalattal a hátuk mögött (én nem is voltak hülyék).

Persze ez lehet, csak az AT&Tnél van/volt így, de nekem ez a tapasztalatom.

FathoM

A PV migralasra vagy az LV csokkentesre gondolsz? Mert emlekeim szerint az utobbi nem lehetseges AIXon ha nincs rajta FS (de fixme).

--
http://blog.htmm.hu/

Lehetségesnek lehetséges, csak nem támogatott, és nagyon kell tudnod mit és hogyan csinálsz, mivel az adatkonzisztenciát neked kell biztosítanod. -> Anno itt is írtam róla: http://p1ngw1n.blogspot.hu/2011/03/pokoli-aix-adminisztrator-lv-decrease.html
____________________________________
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!"..

Koszi! (Igaz ez addig jott volna igazan jol amig dolgoztam AIX-szal :) )

--
http://blog.htmm.hu/

"céges jog"
Ez azért tündéri! Meg ezek a váll'ati stratégiák...

De ha már itt tartunk, akkor még egy cég is szívesebben támaszkodik arra a scriptre, amit ibéemék megírtak 20 éve.

AIX rendszergazda meg azért nehezen található, mert mindenki tudja, hogy raspály szerverrel mindent meg lehet oldani. :)

A számok nem túl meggyőzőek. Készítettünk egy ajánlatot, amelybe raktunk gépeket még, meg még, nehogy a megrendelő kevésnek találja. A legkisebb ibm gép is elegendő volt, de az "adatbázis kezelő gépbe" raktunk duplaannyi memóriát, nehogy a bírálók kevésnek találják. Valójában úgy 1-1,5 gép símán elvitte volna a rendszert a kiíráshoz képest olyan 10-50x sebességgel. Így tartottunk 4db szervernél. A nyertes 12db Oracle (Sun) gépből álló rendszer lett, akik miatt még a sebesség követelményt is csökkentették. A nyertes rendszer ára - a magas licecdíjak miatt - legalább négyszerese a miénknek. Az adatbázis szerverek miatt az üzemeltetési igénye is lényegesen magasabb lett, stb.
Nomármost, az általam készített üzemeltetési dokumentációkba - némi paraméterezgetés, indítás után - a következőt szoktam leírni: "A rendszer működése a továbbiakban automatikus." (Alias ne cseszegesd, mert elrontod.) Jelenleg is működik olyan rendszerem, amit 0 ember üzemeltet. A "rendszergazda" - már ha szólnak neki - ránéz, hogy kiesett-e valamelyik diszk.

Szóval melyik rendszer könnyebben üzemeltethető? Az utólsó 17. rendszerem véletlenül linuxon megy, a többi javarészt aixen ment. (Néhány SCO-n, de az nem ér, mert 3 hetenként eltűnt a diszk a rendszerből. :)) Az már ütősebb, hogy aixre 2 hónap, linuxra meg 7 hónap volt a belövési idő.

"Ha működik, ne piszkáld!" :-)

"De ha már itt tartunk, akkor még egy cég is szívesebben támaszkodik arra a scriptre, amit ibéemék megírtak 20 éve."

Arra igen, amit 20 éve írtak.

Az elmúlt évek install szkriptjeinek minősége mutatja, hogy a marketinges/projektfőhajjakend úgy gondolja: aki nem swinges guival akar telepíteni, az dögöljön meg, ő ugyan nem áldoz sávszélspóroló marhaságokra tapasztalt fejlesztőt.

Sajnos ez szüli a fenntartásokat.

:)
Azért pont 20 éve az aix 4.x install szkriptje úgy nézett ki, hogy
- ha a gépben nincs grafikus csatoló
- ha az alőre beállított paraméterek között van X11=NO
- ha a júzer az X11-re azt mondta, hogy NO
AKKOR IS FELRAKOM AZ X11-et!!!
Ez bele volt írva a kommentbe is.

És amikor már kétszer levettük, de lemaradt két header, no akkor felrakta harmadszor is!

Ebben a dologban jeles pl. az opensuse is. A szervernek elég 0,5GB, de a felrakáshoz már 1,5GB kell.

Be kell látni, hogy a fejlesztőket commodore64-nél nagyobb gépen nem engedhetjük dolgozni! ;)

+1 a fejlesztőkre vonatkozó megjegyzésre :-) Oracle-ből talán a 8.0.5 volt az utolsó "normálisan" telepíthető verzió, amihez nem kellett grafikus felület, vagy minimum egy rakat X-es library.

Hú, itt multkor a softwaresek architectje próbált valami ibmes tervező izét kipróbálni, aztán abban segítettem neki itt ott, nyilván volt némi filehandle limit meg ilyesmi, ami miatt bukdácsolt, meg semmilyen indítóscriptek, ilyesmi. A legszebb viszont az volt, hogy valami félsoros telepítsél X-et izén megakadt, ránézésre úgy tűnt, hogy igazából csak DISPLAY buzerálás, gondolta az ember, hogy fos installer már megint, megmutat, hogy xming fel, ssh Xforward bekap, elindul, örül. Aztán mikor másnap mondta, hogy mikor kilép sshn, akkor megszűnik a grafikus elemek egy része, akkor gyanús lett. És bazmeg, kell egy headless X, mert ott renderel valamit. (mindezt úgy, hogy az ubuntus verzió láthatólag mostoha, mert alapvetően windowsra szeretnék, ha telepítenéd)

Az lvreduce kb. ugyanaz, mint a chfs, de mindegyik esetben azért említik az FS-t.

De, - mint idézted is - nem PV-t kell migrálni, hanem az utólag hozzáadott diszken levő lv darabot a tárolási stratégiának megfelelően átrendezni. Ez talán azért nem tűnt fel, mert linuxon hasonló sincs.

Két lépésben? lvconvert -m1 & lvconvert -m0?

:)
Ezért mondom, hogy hasonló fogalom sincs. Pl. a fs-en elhelyezett, gyakran írt adatbázis területet az öt zónára osztott diszk két külső (gyorsabb) zónáján helyezem el. Mégpedig oda, amelyik közelebb van a loglv-hez. Ha a tükrözés nagy biztonságú, (Itt megjegyzem, hogy akár RAID besorolásról is lehetne beszélni, de a rendszer eleve kezeli a mirror2 vagy 3 felépítést.) azaz be van állítva a "mirror write consistency", akkor minden partíció (ami nem DOS partíció, hanem a diszk egy egységként kezelhető, max. 1016-od része) sikeres lezárását naplózza a 0. track-re is. Ekkor érdemes a külső zónára költözni.

Nomármost, ha a hirtelen területnövelés hatására a fenti policy-nak nem felelnek meg az lv-k, akkor meg lehet kérni a rendszert, hogy szervezze át kissé. Ugyanezt a policy megváltoztatásakor is el lehet játszani. Ezekre a műveletekre van parancskészlet, amely online végrehajtható. Nyilvánvalóan egy diszkkel nem túl látványos. ;)

Ilyesmire gondoltam.

Ez tulajdonképp szép és jó, bár én már 15 éve is erősen tűnődtem, hogy a diszk lassabb és gyorsabb besorolású részei mennyire gyakorlatiasak, amikor sok esetben már csak hazudnak valami cilinder, fej, szektor információt magukról a vasak (nyilván SSD-nél meg pláne értelmetlen, de azt most hanyagoljuk).

Valahol feljebb írtam: scsi. Ezzel kapcsolatban olvastam egy régi tanulmányt, amelyből kiderült, hogy az scsi diszkek kisebb puffermérettel is gyorsabbak. Ez talán a fizika megcsúfolása lenne?
Azt kell látni, hogy a vindóz alá gyártott ide lehet kissé hulladék is. A tervezés alapelve annyi, hogy létezik olyan oprendszer, amely mélyebb és alaposabb módon nem képes kezelni a diszket sem. Nincs is rá szükség, mert a felhasználó nem egy szerver üzemeltető, azt hangolni képes expert. A diszk is olcsó, ha elromlott gyorsan eldobjuk. Egy darabnál az MTBF sem játszik, csak a forgalmazó vagy szervíz győzze a garanciát.
Bizony, egy scsi diszknél a zónák ott szerepelnek az adatlapon (bár ide esetén is specifikált a média sebesség). A gyártó nem teheti meg, hogy hamis adatokat adjon meg. Ha az adott objektumot a megfelelő zónára helyezed, pontosan mérhető, hogy igenis teljesíti a specifikációt. Sőt, aix alatt még a tükrözések overheadje ís mérhető. Azaz nem mérhető, mert igen jól csinálja. :) Vagyis az adott zónán 3x tükrözésnél 3x annyi adatot lehet leolvasni, mint a zóna sebessége.
A fentieket nem olvastam, hanem élesben használtam. Nem egyszer - az "írások ellenében" extrém sebességnövekedést sikerült elérnem. Persze ilyenkor az alkalmazás viselkedését is bele kellett számolni a tervezésbe. Egyik esetben - sok diszk, kevés memória - az alkalmazás ismeretében sikerült olyan paging-et létrehozni, hogy futtásidő úgy alakult, mintha több memória lett volna a gépben.
Az SSD egy új technológia. Komoly diszk igénynél akkor lesz értelme csak ssd-vel álmodni, ha olcsóbb lesz a hagyományos diszkeknél. Olvastam a 80-as évek közepén egy japán tanulmányt amely a mágnesszlagtól az optikai tárolókig elemezte és rendszerbe foglalta a tárolási/hozzáférési igényeket és megvalósításukat. Az ebben felvázolt hatásokat és értékeket extrapolálva 20-30 év múlva is megállják a helyüket!

Tehát létezik két véglet. Van az aix, ahol egy diszk alrendszer megkomponálásához kb. 50 paraméter áll rendelkezésemre, és elboldogulok vele. Vagy a tapasztalati úton megfogalmazott, - szinte már einsteni mondás ;) - hogy némi hozzánemértéssel tetszőlegesen gyors rendszert szinte végtelen lassúvá lehet tenni.

fiatalabb???

Sepciális eseteknek: Egyébként hány (volt) AIX oktató olvasója lehet a HUP-nak?!
Főleg olyan a kit root jelszó nélkül akart AIX-ot oktatni :)

Csak nem a showled-re célozgatsz, amit a surranós úr keresett ki? (Egyébként akart a fene. Kellett.)

Anno az egyik tanfolyáson nekünk is csak az első nap nem volt root jogunk, ha jól emlékszem :-P

Miért, ti nem ugyanarról a tanfolyamról beszéltek?

A fene sem emlékszik már...

+1

A kettőt szerintem nem tudod így összevetni, mivel az AIX a HW-s követelmények miatt nyomban egy virtualizációs réteggel jön (SUSE esetén vagy hypervisort csinált a SUSE-ból (XEN/KVM), vagy raksz alá egy VMware-t ha legalább alap szinten meg akarod közelíteni a virtualizációs képességek egy részét).
AIX alá alapjáraton jön CAA (Cluster Aware AIX), míg ezt SUSE alatt csak külsős komponensekkel tudod összepakolni (emlékeim szerint), így nem tudom az availability-nek mennyire merjek hinni (bár tény, hogy a Linuxos megoldások között jóval több olcsóbbat találsz, mint mondjuk egy HACMP-t, bár ha lejjebb lehet vinni az elvárásokat, akkor egy LPM-el (meg 1-2 saját scripttel) lehet jobban/olcsóbban kilehetne hozni P alatt is)
Maga az ökoszisztéma Linux esetén viszont lehet jobb (már ha linuxos világból jön az ember), mert AIX alá közel se érhető el annyi csomag, illetve inkább az IBM specifikus csomagokat preferálja. Update-ek esetén szintén inkább a zypper/yum a nyerő, mivel a repository-ból automatikusan tudsz frissíteni, míg AIX alatt FixCentral-al kell állandóan "vacakolni", bár SUMA elvileg szintén erre lett kitalálva, viszont direkt internet kapcsolat kell neki. És talán ezért is van az, hogy utóbbi annyira nem is probléma, mert nagyvállalati környezetben jobb is ha te rakod össze szépen a frissítéseket, és deploy-olod NIM-en keresztül akár több 1000 gépre (kb mint egy WSUS esetén)

Kérdésre visszatérve: A TCO szintén érdekes kérdés, mivel AIX HW-hez kötött (ergo ha veszel egy batár nagy 790es boxot, akkor arra is csak 1 license-t kell venni), míg SLES/Redhat esetén ez per VM/LPAR alapon megy, szóval kis gép esetén valóban SUSE jön ki jobban (a HW költségei miatt), nagynál már erős kétségeim vannak (főleg ha nem csak 1-2 alap Linuxos cuccot akarsz futtatni, hanem komolyabb nagyvállalati middleware termékeket)

Performance: Na ez az ami nem OS specifikus, hanem erősen HW. Itt meg innentől én nem mondanék semmit se, mert AIX alá elég kötött HW lehetőségeid vannak, míg SUSE/Linux alá meg szinte bármit. Ha mind a 2őt ugyan arra a pSeries vasra tennénk rá, akkor esélyesebb, hogy AIX több performanciát képes kihozni (feltételezve, hogy mind2 rendszert maxra tuningolod az adott igényekre)

Edit: Amúgy a Linux (SUSE) <-> AIX harca nagyon nem ezeken a területeken fog eldőlni véleményem szerint, inkább a piaci igények alapján.
____________________________________
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!"..

upvoted

790-es viszont nem létezik :)

780 akart lenni, csak elütöttem :DD De jó, legyen E880 és akkor még a Power8 finomságait is megízlelheti az ember :)
____________________________________
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!"..