1700 szervert állít(ott) át a Dell SUSE Linuxról Oracle Linuxra

Címkék

A Dell 2010 júniusában döntést hozott: 1700 szerverét át kell állítani SUSE Linuxról Oracle Linuxra úgy, hogy közben a hardver és az alkalmazás-réteg nem változik. A Dell-nek a migráció kezdetekor körülbelül 1700 fizikai rendszere futott SUSE Linuxszal. Ezek földrajzilag a világ különböző pontjain elszórva találhatók. Többségében nyolcadik generációs Dell PowerEdge 2850, 2950 szerverekről, valamint újabb Dell hardverekről van szó. Az adattárolásról FC SAN-on található EMC Symmetrix és CLARiiON eszközök gondoskodtak. Operációs rendszerként SUSE Linux 10 Service Pack 1-et használtak. A storage-okat MPIO-n keresztül látták a szerverek. A szoftveres környezet Oracle Database 10g Release 2, Oracle Real Application Clusters (Oracle RAC) és Oracle Automatic Storage Management elemekből épült fel. A migráció nagyrészt abból állt, hogy a SUSE Linux 10 operációs rendszereket Oracle Linux 5.5-re cserélték. Emellett a SUSE beépített MPIO megoldását EMC PowerPath-ra cserélték. 2011 decemberében az Dell félúton tartott az átállásban. A munka előreláthatólag 2012 júniusában fejeződik be.

A migráció részleteiről részletesen lehet olvasni a Oracle oldalain.

Hozzászólások

Ennek meg mi ertelme van? Az Oracle rdbm mar csak Oracle linuxon tamogatott?
"MPIO -> EMC PowerPath" migracio se lehetett olcso mulatsag...

Jellemzően az OS natív multi path IO (MPIO) megoldások megállnak a failover szolgáltatásnál, míg a PP már nagyon rég is tudott teljesen korrekt load balance-ot is. Tehát io-t elosztja a rendelkezésre álló útvonalak között.
Míg a legtöbb OS-be épített megoldás maximum round-robin algoritmussal képes csak a több út használatára. Ami szemfényvesztés, mivel egyszerre így is csak egyet utat használ, csak váltogatja.
A PP ha egy útvonal visszajön, akkor automatikusan újra használni kezdi, nem kell kézzel visszakonfigurálni.
A PP felismeri ha EMC Symmetrix (highend) vagy Clariion (midrange) rendszer van a cső végén, és a dokumentációja valamiféle az adott tárolóhoz optimalizált algoritmust emleget.

"A PP ha egy útvonal visszajön, akkor automatikusan újra használni kezdi, nem kell kézzel visszakonfigurálni."
Ezt az MPIO nem tudja? Csak érdeklődöm, hogy képben legyek.

Megvan amúgy a PP-nek is a maga baja. Csak XY kernel verzióval támogatott, illetve a frissítése sem annyira egyszerű mint az MPIO-nak, ami a disztró része.
Valószínűleg lehetne még sorolni, de nem vitatom a PP érdemeit.

Jellemzően az OS natív multi path IO (MPIO) megoldások megállnak a failover szolgáltatásnál, míg a PP már nagyon rég is tudott teljesen korrekt load balance-ot is. Tehát io-t elosztja a rendelkezésre álló útvonalak között.
Míg a legtöbb OS-be épített megoldás maximum round-robin algoritmussal képes csak a több út használatára. Ami szemfényvesztés, mivel egyszerre így is csak egyet utat használ, csak váltogatja.

Szerintem fogalmi zavaraid vannak. _MINDEN_ multipath megoldás egyszerre csak egy utat használ, csak váltogatja. A PP is. Nem lehet egy darab i/o kérést több dróton keresztül vinni. Egyik i/o kérés az egyik dróton megy, a következő kérés majd megy a másikon. A PP is csak ennyit tud, és az OS natív multipath megoldások load-balance technikája is csak ennyit tud. Ami még ennyit sem tud, az meg nem load-balance.

A PP ha egy útvonal visszajön, akkor automatikusan újra használni kezdi, nem kell kézzel visszakonfigurálni.

Képzeld, létezik OS natív multipath megoldás, amiben nemcsak visszajön magától (vagy nem - kívánság szerint), hanem még konfigurálhatod is, hogy melyiket óhajtod. Mert vannak rendszerek, amiknél az egyik viselkedés a kívánatos, és vannak, amiknél a másik.

A PP felismeri ha EMC Symmetrix (highend) vagy Clariion (midrange) rendszer van a cső végén, és a dokumentációja valamiféle az adott tárolóhoz optimalizált algoritmust emleget.

Úgy érted, hogy az az "optimalizálás", amikor valami funkciót (kontrollerek közötti load-balance) inkább NEM használunk, mert tudjuk, hogy az ugyan létezik az adott eszközben, de csak látszólag jó bármire is, mivel rontja a performanciát, előnye meg semmi? Hát, én ezt máshogy nevezném. De marketing bullshitnek gyönyörű ez az "adott tárolóhoz optimalizált algoritmus"...

----

A PP egyetlen valódi előnye, hogy képes beszélni azt a protokollt, amivel a storage-ból/-ba in-band információk szerezhetők/továbbíthatók. Azaz mindenféle béna WWN-silabizálás helyett ki tudja írni, hogy az adott device, az melyik eszköz melyik portján melyik LUN. És fordítva: a storage oldalán láthatod, hogy az adott LUN-t pl. melyik host milyen könyvtárba mountolta fel.

"A PP egyetlen valódi előnye, hogy képes beszélni azt a protokollt, amivel a storage-ból/-ba in-band információk szerezhetők/továbbíthatók. Azaz mindenféle béna WWN-silabizálás helyett ki tudja írni, hogy az adott device, az melyik eszköz melyik portján melyik LUN"

Ehez egy agent is kell, ami egyébként PP nélkül (ip protokollon) ugyanezt megteszi neked.

Szerintem fogalmi zavaraid vannak. _MINDEN_ multipath megoldás egyszerre csak egy utat használ, csak váltogatja. A PP is. Nem lehet egy darab i/o kérést több dróton keresztül vinni. Egyik i/o kérés az egyik dróton megy, a következő kérés majd megy a másikon. A PP is csak tuyd, és az OS natív multipath megoldások load-balance technikája is csak ennyit tud. Ami még ennyit sem tud, az meg nem load-balance.

Szerintem nem azt írtam, hogy egy io több útvonalon megy, nyilván egy io egy úton megy ez nem is kérdés. Amiket láttam régebbi linux, AIX, MPIO-k ott csak round robin volt mint load balance, vagy master slave ami meg csak failover lehetőség. A PP képes 2-32 útvonalat használni, és a load balance szépen elosztja az io-t minden útvonalra, tehát az egyes kérések egymással párhuzamosan mennek. A round robin azt csinálja, hogy küld az egyiken egy io-t (vagy 100-t nyilván konfigurálható) a többin addig nyugi van, majd átáll a másikra és azt használja. Szerintem ez különbség.

Képzeld, létezik OS natív multipath megoldás, amiben nemcsak visszajön magától (vagy nem - kívánság szerint), hanem még konfigurálhatod is

Létezik ezt nem vitatom, nyilván fejlődnek a natív multipath megoldások is,de a van olyan nem azt jelenti, hogy mindegyik tudja. Tehát ez a tulajdonság nincs meg minden natív megoldásban míg a PP régóta kínálja.

Nyilván a helyén kell kezelni ezt az optimalizált algoritmus dolgot, minden gyártó szeret bullshitelni. Nekem az a tapasztalatom, hogy a PP load balance szépen működik. Teszteltem a gyakorlatban 2 -> 4 útvonalra állást és szépen skálázódott. Pl. AIX - Symmetrix viszonylatban.

Abban is megegyezhetünk, hogy nem a PP az egyetlen üdvözítő út, meg is kérik az árát. Egyrészt a natív MPIO megoldások eltejedése valamint a virtualizált világ miatt a jelentősége is csökken. De nem rossz szoftver, hosszú múltra tekint vissza, volt ideje fejlődni.

Nem akarok a vitatokba beleszolni, de szerintem itt az a gond, hogy van egy X eves infod Linux/AIX-rol, es kimarad az az egyenletbol, hogy azota ezek a sw-k fejlodtek.

A masik dolog, ami felmerult bennem: miert baj az, ha nem mindegyik tudja? Minden feladathoz a megfelelo celeszkozt kell hasznalni, ez storage-rendszerek eseteben hatvanyozottan igy van. Ahol kritikus a storagek elerhetosege, oda olyan rendszert kell tervezni, ami kepes online konfiguralni a pathjeit.
--

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

MPIO failover modok (idezet a man multipath.conf-bol):

path_selector The default path selector algorithm to use; they are offered by the kernel multipath target. There are three selector algorithms.

round-robin 0
Loop through every path in the path group, sending the same amount of IO to each.

queue-length 0
Send the next bunch of IO down the path with the least amount of outstanding IO.

service-time 0
Choose the path for the next bunch of IO based on the amount of outstanding IO to the path and its relative throughput.

failback:

failback Tell multipathd how to manage path group failback.

immediate Immediately failback to the highest priority pathgroup that contains active paths.

manual Do not perform automatic failback.

followover Only perform automatic failback when the first path of a pathgroup becomes active. This keeps a node from automatically
failing back when another node requested the failover.

values > 0 deferred failback (time to defer in seconds)

Default value is manual.

Szerintem ez minden multipath igenyt kielegit. Nem veletlen, hogy az IBM mar nem ad ki SDD-t linuxra, mivel a nativ MPIO tud mindent, amit kell.

Ismet a multipath.conf-bol idezek:


prio The default method used to obtain a path priority value. Possible values are

const Set a priority of one to all paths

emc Generate the path priority for EMC arrays

alua Generate the path priority based on the SCSI-3 ALUA settings.

tpg_pref Generate the path prority based on the SCSI-3 ALUA settings, using the preferred port bit.

ontap Generate the path priority for NetApp arrays.

rdac Generate the path priority for LSI/Engenio RDAC controller.

hp_sw Generate the path priority for Compaq/HP controller in active/standby mode.

hds Generate the path priority for Hitachi HDS Modular storage arrays.

Default value is const.

Lehet hogy nem a default beallitasokkal kell hajtani az MPIO-t, hanem a gyarto ajanlasanak megfeleloen konfigolva...

+1

A linux nativ multipath sokkal jobban konfigolható mint a PP, azért mert az adott storage-ra ezt be kell állítani az nehogy már az mpath hibája legyen.
rr_min_io -val állíthatod hogy mennyi io után váltson path-t, ez defaultból 1000 ha ezt nem állítod át elhiszem hogy szar teljesítményt ad ki.
Mostanában szívtam egy ilyen miatt: a product névében egy elírást csináltam és ezért nem vette fel a beállításaimat, (default 1000-et használta a 64 helyett) aztán csak néztünk, hogy miért van csak 1 port 100%-on kihajtva még a többin szinte semmi. Teljesítményben ez azt jelentette, hogy 600MByte/s-nél az istenért se ment feljebb az olvasás még előtte egy régebbi storage-ban ez 1,5GByte/sec is volt.
Abban igazad van, hogy a PP-vel ezzel nem kell szívni, viszont a "diszkek" elnevezését nem lehet átállítani (én legalábbis nem találtam rá megoldást, mint az mpath-nál hogy aliast adjak neki, amiből pl tudom, hogy melyik telephelyi diskgroup vagy disk esett ki). A PP másik legnagyobb hibája, hogy ha a scsi deviceaid száma 1024 fölé kerül teljesen bekattan annyira, hogy mikor a gép elindult az összes cput 100%-on pörgette és még az SSH bejelentkezés is 5 perces esemény volt :) Sajnos emiatt nem tudtam már letesztelni, hogy a különböző gyártók közötti storageból kapott lun-okat lehet e külön külön konfigolni (erről ha van valakinek tapasztalata az plz írja meg) még ezt a nativ mpath simán tudja.
Továbbá az mpath-nak van egy doksija amiben fel van sorolva elég sok storage, hogy melyikre mit ajánlanak azok általában jók szóktak lenni. Viszont a legújabb storageok ilyen default konfigjai még nincsenek benne. (pl IBM XIV-t ne keress benne mert az még nincs benne, arra olvass cookbook-ot).

Valójában csak előre dolgoznak, hogy kevesebb nyűgjük legyen, ha véletlenül felvásárolják a DELL-t :)

Emellett a SUSE beépített MPIO megoldását EMC PowerPath-ra cserélték. 2011 decemberében az Oracle félúton tartott az átállásban.

Az Oracle? Nekem az jött le a cikkből, hogy az átállást a Dell csinálta.

Mondjuk nehezen is tudnám elképzelni, hogy hogyan is tudott volna az Oracle értelmes módon szerződni a feladatra... :PPPPP nem hiszem, hogy pont erre a projektre jóváhagynának fent bármilyen fix árazást, time & material alapon meg épeszű ügyfél nem szerződik ekkora melóra.

Kár, hogy minket nem kérdeztek meg előre.

Csöbörből vödörbe, vagy hogyan is mondják... :)
--
Gábriel Ákos

En egeszen tegnapig annyira tudatlan voltam, hogy nem tudtam, hogy se a Redhat se az Oracle nem tamogatja a major verziok kozotti upgradet.

Nem kicsit rohogtem am korbe :D

de nem értem, hogy miért kell linuxról linuxra migrálni? főleg, ha az alkalmazás réteg nem változik. ha meg kell egy plusz technika kernelszinten, akkor meg kernelforgatás :) olcsóbb megoldás, mint ennyi szervert migrálni. sztem egy SuSE szerver is tud mindent, amit kell. sztem a legnagyobb találmány benne a YaST :D Habár már évek óta nem használtam SuSE-t, de szervernek szerintem nagyon frankó :) Desktopnak más disztrót használok én is.

Talán mert kaptak egy olyan árat, amire nem lehetett nemet mondani. Az Oraclenek jó, mert kapott egy nagyon nagy referenciát, mikor Dell szerverekhez - x86-on elég elterjedt - ajánlják ki rendszerüket, egyből az RH alá tudnak vágni azzal, hogy a Dell natívan is ezt futtatja... És elfelejtik a tényt, hogy pénzért árulják azt, amit a CentOS, SL linux ingyen - szponzorokkal - csinál. Ok, támogatást is elad, mondhatnók, de ez valójában gázabb lenyúlás, mint bármi. De a licenc megengedni, nem véletlenül lett egyben kernel patch, had szívjanak vele oracles fejlesztők, hogy mit miért rakott bele a RH. Mondom ezt úgy , hogy tudom, a btrfs nagy cucc lesz, oracle fizeti a fejlesztőt, Masont, de szerintem felvette volna más is, és ugye ez mindenkinek jó, Oraclenek is.
Mondjuk egy keresztlicenc megállapodás RH-val korrektebb lett volna, de Larry Ellison, meg a becsület, az két külön dolog. Mondjuk kétségem sincs, hogy minden multi cég ilyen, ez háború, ki kell használni minden lehetőséget.

Hasogassunk hámozott szőrszálat: a 29xx az már a 9. generációs társaság, ha jól tudom :) A váltás egyébként ésszerűnek tűnik, pláne, hogy Oracle RAC alá kell az OS, no meg az EMC-vel is elég jó a kapcsolat, úgyhogy a PowerPath-on sem szabad csodálkozni.