Egy diszket tobb neven is elerek amire az LVM sikit, hogy duplikalt PV-k vannak. Amellett, hogy sikit, nekem jo is hogy megmondhatom, hogy melyiket hasznalja. Ez mukodik is jol, az lvm.conf filter= soranak a kitoltesevel, ugy hogy emcpower.* eszkozoket hasznalok, az sda, sdb, sdc, sdd helyett (*). Csakhogy...
A bajom az, hogy olykor olykor (tipikusan kernel frissites) az emcpower eszkozom megszunik, csak az sda/b/c/d vannak, ilyenkor viszont mar be sem bootol a rendszer (a / is ilyen eszkozon van), mert a filter-ben megmondtam, hogy emcpower eszkozt akarok hasznalni.
A kerdesem tehat az, hogy hogy lehet megmondani az LVM-nek, hogy ha a block-eszkozomet tobb neven is latja, akkor lehetoleg emcpower.* nevut hasznalja, de ha olyan nincs, akkor barmi jo lesz.
Probaltam a filter=... es a prefered_names=... kulcsszavakat az lvm.conf-ban, de eddig hiaba.
(*): az emcpower eszkoz mellesleg arra jo, hogy az sda/b/c/d eszkozeim kozott (ami valojaban egy Fibre Channel halozat egyetlen LUN-ja, csak halozati reundancia miatt Linux oldalon mar tobb eszkoznek latszik) loadbalance-ol, failoverel, de mindez most itt nem lenyeg.
- 1712 megtekintés
Hozzászólások
Van valami oka, hogy LVM-et használsz bootra?
Ha powerpath, akkor gondolom Clarrion, viszont ő tetszőleges méretű LUN-t tud csinálni egy RAID tömbön.
(LVM szerintem max akkor indokolt, ha a file rendszerek méretét gyakran variálod.)
- A hozzászóláshoz be kell jelentkezni
Az LVM root-ra pont a PowerPath miatt van/volt szukseg. Igy lehet garantalni, hogy a root-ra is legyen failover (kulonbozo FC utvonalak kozott).
Lehet, hogy nem csak igy lehetett volna megoldani, de ez mar mindegy, ezt tekintsuk adottsagnak, sok rendszer van mar igy, nem allitgathatom at mindet.
- A hozzászóláshoz be kell jelentkezni
A power path device csinálja a failovert, nem az LVM. Még mindíg nem értem mire kell bele az LVM.
Mondjuk leginkább Solaris és Windows alatt csináltam PowerPath-ot (többször is, sokat), de szerintem linux alatt sem kell volume managerrel használni. Más oprendszeren is szopás a PowerPath+Volume manager....
- A hozzászóláshoz be kell jelentkezni
Az lvm ápol s eltakar. Nem érdekel, hogy az épp mpath#, hogy az emcpowera#, vagy sdzs#, csak system.
De leginkább mer így volt már tegnap is.
--
"A herceg én vagyok."
- A hozzászóláshoz be kell jelentkezni
Komolyan, lehet, hogy most ezért többen megköveznek, de szerintem az emcpower driver/daemon/mifene egy baromság.
Külön nyűg, bugos, lassan frissítik, szóval hulladék. Amikor próbáltam, lassabb is volt, mint a natív mpath.
Használj simán dm-multipath-t, és kisimulnak a ráncaid... :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Sok mást én sem tudok hozzátenni, csak:
+1
- A hozzászóláshoz be kell jelentkezni
-1
A DM-Multipath egy fapad a PowerPath-hoz kepest.
Persze arra jo, hogy elrejtse a tobb utvonalat az OS elol...
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy az én szegénységi bizonyítványom, de sok helyen használ(t)unk powerpath-t és azon kivül amit a dm-multipath tud soha semmilyen fícsörjét nem használtuk. Bár talán a load balance üzemmód kivétel....
- A hozzászóláshoz be kell jelentkezni
Eddig nem volt szo arrol, hogy milyen storage-rol van szo. Ha Clariionrol, akkor a load balance (CLAR_opt policy) az csak az egyik hasznos dolog.
De ha pl. minden aktiv utvonal elmulik a LUN-owner storage processor fele, akkor a PowerPath "be tud szolni" a passziv utvonal(ak)on, es ker egy trespasst, es orombodogsag van :)
Legjobb tudomasom szerint a DM-Multipath nem tud ilyet.
Fixme ha megis.
- A hozzászóláshoz be kell jelentkezni
Remek doksi van a Powerlinken a temaban:
PowerPath® for Linux Version X.Y Installation and Administration Guide
- A hozzászóláshoz be kell jelentkezni
En viszont eppen azt szeretnem megoldani, hogy mi van akkor ha -barmilyen okbol- nincs PowerPath.
- A hozzászóláshoz be kell jelentkezni
A PowerPath guide-ja azt mondja, hogy el lehet felejteni, hogy a rootpartició initrd-vel meg lvm-mel powerpath-szal megy. Gyönyörű.
A dm_multipath-szal kapcsolatban viszont felmerül egy kérdés:
Kiadom a multipath -ll parancsot, semmi. multipath -v2, semmi.
# multipath -v2 -d
create: mpath5 (3600601600b521c0072ebc235e250de11) DGC,RAID 5
[=10G][features=1 queue_if_no_path][hwhandler=1 emc][n/a]
\_ round-robin 0 [prio=2][undef]
\_ 1:0:1:0 sdk 8:160 [undef][ready]
\_ 0:0:0:0 sdm 8:192 [undef][ready]
\_ round-robin 0 [prio=0][undef]
\_ 0:0:1:0 sdae 65:224 [undef][ready]
\_ 1:0:0:0 sda 8:0 [undef][ready]
Ezek után mindig semmi a multipath -ll -ben.
multipath -v6 kimenetéből a releváns rész:
mpath5: pgfailback = -2 (controller setting)
mpath5: pgpolicy = group_by_prio (controller setting)
mpath5: selector = round-robin 0 (controller setting)
mpath5: features = 1 queue_if_no_path (controller setting)
mpath5: hwhandler = 1 emc (controller setting)
mpath5: rr_weight = 1 (controller setting)
mpath5: minio = 1000 (controller setting)
mpath5: no_path_retry = 60 (controller setting)
pg_timeout = NONE (internal default)
mpath5: set ACT_CREATE (map does not exist)
libdevmapper: ioctl/libdm-iface.c(1617): dm info mpath5 NF [16384]
libdevmapper: ioctl/libdm-iface.c(1617): dm create mpath5 mpath-3600601600b521c0072ebc235e250de11 OF [16384]
libdevmapper: libdm-common.c(599): mpath5: Stacking NODE_ADD (253,10) 0:6 0660
libdevmapper: ioctl/libdm-iface.c(1617): dm reload mpath5 OF [16384]
libdevmapper: ioctl/libdm-iface.c(1634): device-mapper: reload ioctl failed: Invalid argument
libdevmapper: ioctl/libdm-iface.c(1617): dm remove mpath5 NF [16384]
libdevmapper: libdm-common.c(615): mpath5: Stacking NODE_DEL (replaces other stacked ops)
libdevmapper: ioctl/libdm-iface.c(1617): dm create mpath5 mpath-3600601600b521c0072ebc235e250de11 OF [16384]
libdevmapper: libdm-common.c(599): mpath5: Stacking NODE_ADD (253,10) 0:6 0660
libdevmapper: ioctl/libdm-iface.c(1617): dm reload mpath5 OF [16384]
libdevmapper: ioctl/libdm-iface.c(1634): device-mapper: reload ioctl failed: Invalid argument
libdevmapper: ioctl/libdm-iface.c(1617): dm remove mpath5 NF [16384]
libdevmapper: libdm-common.c(615): mpath5: Stacking NODE_DEL (replaces other stacked ops)
libdevmapper: ioctl/libdm-iface.c(1617): dm info mpath5 NF [16384]
mpath5: domap (0) failure for create/reload map
mpath5: remove multipath map
sdae: orphaned
sda: orphaned
sdk: orphaned
sdm: orphaned
Erre valakinek bármi ötlete? googol nemigazán tudott segíteni.
# cat /etc/multipath.conf |grep -v ^# |grep -v ^$
defaults {
user_friendly_names yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^(hd|xvd|vd)[a-z]*"
wwid "*"
}
blacklist_exceptions {
wwid "3600601600b521c0072ebc235e250de11"
}
A rendszer 5.3-mas redhat, a devicemapper és a kernelen kívül minden más csomag a release-beli állapot, az előbb említett kettőt rhn-ről upgrade-eltem. Ugyanazt csinálja az új csomagokkal is, mint ami volt.
# rpm -qa |grep kernel
kernel-headers-2.6.18-128.1.16.el5
kernel-2.6.18-128.1.16.el5
# rpm -qa |grep device
device-mapper-1.02.28-2.el5
device-mapper-1.02.28-2.el5
device-mapper-multipath-0.4.7-23.el5_3.4
device-mapper-event-1.02.28-2.el5
Ötlet valakitől?
--
"A herceg én vagyok."
- A hozzászóláshoz be kell jelentkezni