- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Szép feladat.
- A hozzászóláshoz be kell jelentkezni
Ennek meg mi ertelme van? Az Oracle rdbm mar csak Oracle linuxon tamogatott?
"MPIO -> EMC PowerPath" migracio se lehetett olcso mulatsag...
- A hozzászóláshoz be kell jelentkezni
A multipath megoldást én épp a fordított irányban migráltam nem is olyan nagyon régen, költségcsökkentés miatt. Az MPIO nem tudott mindent, amit a PP igen, de ha nem kell 4 kártyára szétkent nagyteljesítményű írás/olvasás, akkor az MPIO is teljesen jó.
- A hozzászóláshoz be kell jelentkezni
Ezt kifejtened reszletesen? Marmint hogy miben gyengebb az MPIO a PPhez kepest. Koszi!
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy tudja már régebben ez nem ment.
A PP-nek mint minden binárisan terjesztett kereskedelmi szoftvernek pontosan ez a baja amit leírsz. Igen többször szívtunk amikor az ügyfél már rakta volna fel az új SP-t a Linux-ra, de várni kellett amíg a PP is támogatja azt.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A terheléselosztásban. Google-lel arra keress, hogy ALUA. Egy gép esetén nem sok értelme volt, de 3-4 gép esetén kb. 30-40%-kal nagyobb throughput-ot tudtam kihozni a storage-ból PP-vel.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
+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).
- A hozzászóláshoz be kell jelentkezni
Valójában csak előre dolgoznak, hogy kevesebb nyűgjük legyen, ha véletlenül felvásárolják a DELL-t :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nyilvánvaló typo, ami az eredeti szövegből kiderül.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én meg már megijedtem, hogy Larry változtatott az álláspontján... :)
- A hozzászóláshoz be kell jelentkezni
Kár, hogy minket nem kérdeztek meg előre.
- A hozzászóláshoz be kell jelentkezni
szép lenne egy hup-szavazás belőle
-----------
A barátnőm azt mondta, néha próbáljam meg a világot az ő szemével nézni. Úgyhogy kinéztem a konyhaablakon.
- A hozzászóláshoz be kell jelentkezni
Azért nem volt, mert őket is csak az eredmény érdekli... :-)
- A hozzászóláshoz be kell jelentkezni
Csöbörből vödörbe, vagy hogyan is mondják... :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Miert is?
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Csak distrok közötti upgradet :oP
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
ennek - sles10röl "rhel"5-re semmi ertelme nem volt. meg ha rhel6-ra, akkor aszondom oke. mondjuk az sp1 regi, es az mpio is buta benne, de felrakni egy SP-ot azert a kisebbik feladat.
mindegy, valaki biztos jol szorakozott.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az Oracle Linux is ingyen van, csak a frissítésekért kell fizetni vmi nevetséges összeget, azt hiszem évi ~150$.
- A hozzászóláshoz be kell jelentkezni
Amely frissítések szintén ingyenesek a CentOS, SL disztribúciókban.
- A hozzászóláshoz be kell jelentkezni
Már ha jönnek. Ha nem, akkor nekiállhatsz magadnak foltozgatni.
- A hozzászóláshoz be kell jelentkezni
Az ingyenes lét valóban kegyetlen. De a totál ingyenes nem egyenlő akkor sem a évi 150 dolláros ingyenességgel.
- A hozzászóláshoz be kell jelentkezni
Csak ne felejsd el, hogy azzal együtt jön az Oracle saját maga fordította kernel ami direkt a saját szoftverjeire van optimaizálva, és ha azokat futtatsz rajta akkor azért megéri.
- A hozzászóláshoz be kell jelentkezni
Ez biztos igaz, de nem erről volt szó.
- A hozzászóláshoz be kell jelentkezni
Nem biztos, hogy szeretnek az evi $150 csomaggal mukodtetni kritikus rendszereket.
Gyakorlatilag semmi nincs benne, azon kivul, hogy olvashatod a forumot es kapod a patcheket.
- A hozzászóláshoz be kell jelentkezni
Ha Oracle cuccot futtatnak (esetleg Oracle appszerverrel), akkor hasznos dolog, ha a beszállítók nem tudnak egymásra mutogatni hiba esetén, mert az összes réteget ők szállítják... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Itt a pont és ennyi.
- A hozzászóláshoz be kell jelentkezni
Illetve mutogathatnak még a hw gyártóra is, aki ebben az esetben a vevő.
- A hozzászóláshoz be kell jelentkezni
öngól? :D
---
Why use Windows, if you have open doors… to Linux
- A hozzászóláshoz be kell jelentkezni
A hw egy jelentős részét másokkal csináltatja a Dell. Emlékeim szerint a Dell-es blade (keret meg szerver egyaránt) pl. egészen kísérteties hasonlóságot mutat a Fusi hasonló dobozával...
- A hozzászóláshoz be kell jelentkezni
Mindketten vettek egy referencia design-t?
- A hozzászóláshoz be kell jelentkezni
Gyártattak hozzá kék, illetve zöld műanyag elemeket, meg matricákat...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni