Initiator-ban az LVM nem áll össze

Debian GNU/Linux

A következő problémában kérem a közösség segítségét, hát ha valaki már találkozott ezzel, melyre nem találtam a netten érdemi és működő megoldást. (A target és initiator Debian 8.)

Az iSCSI target és initiator kiválóan működik, az target-ben riad 1-be szervezett disk-ek kerülnek kiajánlásra, melyeket a initiator-ban LVM kötetekbe állítunk össze. Minden működik és csodálatos, DE az initiator újraindítása után az LVM kötet nem áll össze, csak kézzel kiadott vgchange -ay utasítás után kel életre és automatikusan felcsatolódik az fstab-ban meghatározott helyre.

/A szimplán használt disk (LVM nélkül) tökélesen működik és boot után automatikusan felcsatolásra kerül az fstab-ban meghatározott helyére./

A kérdés, mit hogy kellene módosítani, hogy az initiator újraindítása után a iSCSI disk-ek automatikusan összeálljanak az initiator-ban LVM kötetté.

Minden segítséget előre is köszönöm.

  • 6132 megtekintés

( k.attila | 2016. 04. 08., p – 21:02 )

ez lenne a megoldás?

vgchange -ay >> /etc/rc.local

Nemnem, tuti nem.
Most nincs energiám megnézni, de szerintem csak annyi a baj, hogy az iscsi csiribú az lvm után van (vagy nem elég fürge), ezért amikor az lvm körbecsóválja a kutyát, akkor még nem látja, hogy.

Hogy ez ellen mit kéne tenni, azon még elmélkednem kell.

Ha tényleg ez a gond (iSCSI-val sosem játszottam, csak tipp úgy, hogy egy Win-es gépen belenéztem a .deb fájlokba), akkor elvileg ennyi:

/etc/systemd/system/open-iscsi.service.d/fix-lvm-dep.conf 


[Service]
Wants=lvm2-activation.service
Before=lvm2-activation.service

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ahogy Fisher írta felettem, hozd létre. Könyvtárastúl.

A systemd-nél a [unitnév].d könyvtárak arra valók, hogy az adott service-hez új tulajdonságokat tudj megadni a "gyári" konfig felülírása nélkül (enélkül csak 1-1-ben tudnál felülbírálni a teljes service konfigot az /etc-be tett unit fájllal [pl. ha kimaszkolsz egy unit-ot, az a /etc-ben létrehoz a unit nevén egy symlinket a devnullra], vagy ami a legrosszabb, a /var-ban tudnád szerkeszteni az upstream konfigját [nem szerencsés, utána állandóan kézzel kéne vadásznod a frissítésekkor, hogy az upstream módosított-e]).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mármint azt, hogy egész pontosan két sorral ezt a problémát meg tudtuk volna oldani? :)

Belenéztem megint a deb-be, természetesen egy sima shell script, még véletlenül sem systemd service, ráadásul bele van taknyolva, hogy ha létezik (a tőle továbbra is csomagszinten független!) vgchange bináris, akkor küzdjön egy kicsit az LVM-mel is (amire egyébként nem lenne szükség, mert láthatóan egy három soros helyi konfig fájllal helyettesíthető ez a funkcionalitást).

De azért "imádjuk a systemd-t...", mert anélkül olyan jókat lehet taknyolni.

--
És akkor a problémára visszatérve: Attila, ha már ez a "hivatalos" megoldás, próbáld ki, hogy az /etc/defaults/open-iscsi -ban az LVMGROUPS-ban felsorolod az iscsi felett futó vg-ket (szóközökkel elválasztva), azokra sorban meghívja a vgchange-t. (bár továbbra is kíváncsi lennék, hogy az lvm-activation miért nem találja meg az összes eszközt, ha már az open-iscsi összekukázta őket... logokban semmi nyoma nincs?)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Anélkül _is_ jól meg lehet oldani a problémák 99%-át, csak érteni kéne, hogy a sysvinit-et miért és hogyan tervezték és alkották meg anno. De amikor azt a gányolt, taknyolt, f0sadék scripteket látom, amiket az érintett csomagokhoz adnak... Mondjuk úgy, hogy nem vagyok abban biztos, hogy az elkövetője bármilyen érdemi tudással rendelkezne erről.

Azzal, hogy sok mindent nem úgy használnak/használunk, ahogy kellene/eredetileg tervezték/ahogy a common sense diktálja, sajnos egyet tudok érteni/kell értenem... valamelyik hasonló sysv vs. systemd vitában valaki valamelyik BSD init scriptjeire hivatkozott, azok pl. tényleg teljesen korrektnek tűntek - és gyakorlatilag ugyanígy leíró jellegű [változókat állítgatott, aztán hívta a "mester" init scriptet] volt.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Zeller, mutass már nekem gányoltabb dolgot a System V initnél! Bakker, S* meg K*, hogy mi induljon és mi álljon le? Függőség kezelés nulla. A SysV egy gányolt vacak, amivel megpróbálták valahogy kezelni a csomagok megfelelő sorrendjét, de amolyan hátulról szembe módon.

Ave, Saabi.

Az, hogy a binugznál nagyon elkufott módon csinálták meg, az nem az én saram :-P Egyébként eredetileg(!) a függőséget a linkben szereplő kétjegyű, decimális értékkel megvalósított sorrendiség adta - és aminek szüksége volt egy másik szolgáltatás működésére, az induláskor megnézhette, hogy él-e az, amire szüksége van. Igen, visszafelé nem volt tervezve (azaz ha "a" futása szükséges volt "b" indulásakor, akkor az "a" leállítása nem rúgta ki "b"-t maga előtt).
A másik kellemes dolog, amivel a binugzos sysvinit csomagtákolók nem kezdtek gyakorlatilag semmit már a kezdetektől, az a futási szintek - pedig azzal is lehetett jó dolgokat alkotni. És mielőtt... Az eredeti init és képes monitorozni egy elindított szolgáltatás futását, és annak leállása esetén újrarúgni, csak linuxos körökben a respawn az gyakorlatilag ismeretlen, vagy épp ördögtől valónak tartott dolog.

Annyt azért pontosítsunk, hogy a sorrendiség és a függőség az rohadtul nem ugyanaz, és az initscriptek számozása csak az elsőt tette lehetővé, a másodikra már kellett valami megoldás (pl. *BSD rcNG). Mondjuk az inittab-beli respawn-t azt Saabika se érti, hisz hapukszon is ugyanannyira nem használják semmire, csak a senki által nem használt getty futtatására.

Ezért is írtam, hogy ha a "b" szolgáltatáshoz kell az "a" működése, akkor a "b" indulásakor szépen megnézi, hogy van-e már "a". A sysvinit-et ugyanis így tervezték, így lehetett az alapja faék egyszerű, mégis kellően rugalmas.
Nekem egyébként nem egyszer futott szolgáltatás inittabból respawn-nal - mivel elég hosszan futott ahhoz, hogy ne tiltsa ki az init (~1 perces futási idővel ment, úgyhogy bőven jó volt), így sem az újraindítással, sem az egymásra futással nem kellett foglalkozni. :-P

azzal kezdtem

dmesg:

[ 0.516173] scsi0 : ata_piix
[ 0.516349] scsi1 : ata_piix
[ 0.522589] scsi2 : ata_piix
[ 0.522695] scsi3 : ata_piix
[ 0.704342] scsi 0:0:0:0: Direct-Access ATA CF_Card .02K PQ: 0 ANSI: 5
[ 0.708335] scsi 2:0:0:0: Direct-Access ATA WDC WD20EFRX-68E 0A82 PQ: 0 ANSI: 5
[ 0.708639] scsi 2:0:1:0: Direct-Access ATA WDC WD40EFRX-68W 0A82 PQ: 0 ANSI: 5
[ 0.712334] scsi 3:0:0:0: Direct-Access ATA WDC WD20EFRX-68E 0A82 PQ: 0 ANSI: 5
[ 0.712631] scsi 3:0:1:0: Direct-Access ATA WDC WD40EFRX-68W 0A82 PQ: 0 ANSI: 5
[ 0.716517] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 0.716631] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 0.716928] sd 2:0:1:0: Attached scsi generic sg2 type 0
[ 0.716997] sd 3:0:0:0: Attached scsi generic sg3 type 0
[ 0.717078] sd 3:0:1:0: Attached scsi generic sg4 type 0
[ 4.325502] systemd-sysv-generator[154]: Ignoring creation of an alias umountiscsi.service for itself
[ 4.406281] systemd[1]: [/etc/systemd/system/open-iscsi.service.d/fix-lvm-dep.conf:2] Unknown lvalue 'Wants' in section 'Service'
[ 4.406298] systemd[1]: [/etc/systemd/system/open-iscsi.service.d/fix-lvm-dep.conf:3] Unknown lvalue 'Before' in section 'Service'
[ 10.526999] iscsi: registered transport (tcp)
[ 10.567466] iscsi: registered transport (iser)
[ 12.650365] scsi4 : iSCSI Initiator over TCP/IP
[ 13.684220] scsi 4:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.685294] sd 4:0:0:0: Attached scsi generic sg5 type 0
[ 13.686931] scsi 4:0:0:1: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.688378] sd 4:0:0:1: Attached scsi generic sg6 type 0
[ 13.689722] scsi 4:0:0:2: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.690894] sd 4:0:0:2: Attached scsi generic sg7 type 0
[ 13.691692] scsi 4:0:0:3: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.693766] sd 4:0:0:3: Attached scsi generic sg8 type 0
[ 13.695049] scsi 4:0:0:4: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.697095] sd 4:0:0:4: Attached scsi generic sg9 type 0

Lehet, hogy itt a megoldás:

[ 4.406281] systemd[1]: [/etc/systemd/system/open-iscsi.service.d/fix-lvm-dep.conf:2] Unknown lvalue 'Wants' in section 'Service'
[ 4.406298] systemd[1]: [/etc/systemd/system/open-iscsi.service.d/fix-lvm-dep.conf:3] Unknown lvalue 'Before' in section 'Service'

Rosszul írtam, nem a [Service] részbe, hanem a [Unit] részbe kell tenni a két direktívát (első sort cseréld erre), sorry. [vagyis az egy device-os se emiatt javult meg]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

dmesg:

[ 0.585285] scsi0 : ata_piix
[ 0.585377] scsi1 : ata_piix
[ 0.586487] scsi2 : ata_piix
[ 0.586564] scsi3 : ata_piix
[ 0.756359] scsi 0:0:0:0: Direct-Access ATA CF_Card .02K PQ: 0 ANSI: 5
[ 0.780331] scsi 2:0:0:0: Direct-Access ATA WDC WD20EFRX-68E 0A82 PQ: 0 ANSI: 5
[ 0.780626] scsi 2:0:1:0: Direct-Access ATA WDC WD40EFRX-68W 0A82 PQ: 0 ANSI: 5
[ 0.784337] scsi 3:0:0:0: Direct-Access ATA WDC WD20EFRX-68E 0A82 PQ: 0 ANSI: 5
[ 0.784631] scsi 3:0:1:0: Direct-Access ATA WDC WD40EFRX-68W 0A82 PQ: 0 ANSI: 5
[ 0.788736] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 0.788773] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 0.788920] sd 2:0:1:0: Attached scsi generic sg2 type 0
[ 0.789317] sd 3:0:0:0: Attached scsi generic sg3 type 0
[ 0.789361] sd 3:0:1:0: Attached scsi generic sg4 type 0
[ 4.326546] systemd-sysv-generator[153]: Ignoring creation of an alias umountiscsi.service for itself
[ 4.473523] systemd[1]: Found dependency on open-iscsi.service/start
[ 4.473608] systemd[1]: Found dependency on open-iscsi.service/start
[ 9.876055] iscsi: registered transport (tcp)
[ 9.915423] iscsi: registered transport (iser)
[ 11.995389] scsi4 : iSCSI Initiator over TCP/IP
[ 13.036058] scsi 4:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.037375] sd 4:0:0:0: Attached scsi generic sg5 type 0
[ 13.039001] scsi 4:0:0:1: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.040606] sd 4:0:0:1: Attached scsi generic sg6 type 0
[ 13.041726] scsi 4:0:0:2: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.043598] sd 4:0:0:2: Attached scsi generic sg7 type 0
[ 13.044979] scsi 4:0:0:3: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.047290] sd 4:0:0:3: Attached scsi generic sg8 type 0
[ 13.048687] scsi 4:0:0:4: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 13.051070] sd 4:0:0:4: Attached scsi generic sg9 type 0

( wachag | 2016. 04. 09., szo – 19:33 )

Off, mert nem értek hozzá:

Mennyire szokás úgy redundanciát létrehozni storage esetén, hogy iSCSI fölé építünk RAID-et? Milyen lehet a teljesítménye egy elosztott filerendszerrel szemben (pl. GlusterFS)? Vannak erre itt tapasztalatok?

(alapvetően nem ilyen területen dolgozom, de laikusként néha elgondolkodom ilyeneken)

( saabi v | 2016. 04. 09., szo – 23:10 )

Használj iSCSI offload képes hálókártyát, az már a boot előtt összeszedné a diskjeidet.

( k.attila | 2016. 04. 10., v – 10:20 )

köszönöm mindenkinek a segítséget