Pacemaker + Hawk - pontosan hogyan?

Fórumok

Sziasztok,

 

Laborban probalok osszerakni egy Pacemaker + Hawk Clustert. Ket SUSE az alap, ossze is alt az alap cluster, csinaltam egy floating IP-t ami szepen vandorol is a Node-ok kozott, ha a master-t szabalyosan allitom le. Ha viszont siman kinyomom (VM, tehat hard shutdown) akkor nem migralodik at a slave-re... Elv a stonith-sbd be van allitva, csinaltam egy 1 GB-os particiot is nekik (shared HDD, latja mind a 2 node) softdog is betolve kernel modulkent mindket node-on.

 

Mi hianyzik meg szerintetek?

Hozzászólások

Engem Centos 7 alatt tréfált meg egyszer a pont ezen a módon  a NetworkManager : nagyon (túlzottan is) intelligensen kezeli a hálózati kártyákat, de a clusterben ez pont nem jó. A tanulság az volt, hogy a pacemaker clusterben a disztribúciód által elérhető lehető legegyszerűbb hálózatkezelést állítsd be, ami mindig és folyamatosan életben tartja az interface-t, ha működik a gép. (tehát pl. nem a link detektálás függvényében aktiválja/inaktiválja)

crm configure show kimenetet tudsz küldeni?

A gyors gondolat többet ér, mint a gyors mozdulat.

hacluster1:~ # crm configure show
node 171124308: hacluster1
node 171124309: hacluster2
primitive admin-ip IPaddr2 \
        params ip=10.51.38.86 \
        op monitor interval=10 timeout=20 \
        meta target-role=Started
primitive dlm ocf:pacemaker:controld \
        op start timeout=90s interval=0 \
        op stop timeout=100s interval=0
primitive lvmlockd lvmlockd \
        op start timeout=90s interval=0 \
        op stop timeout=100s interval=0
primitive mount Filesystem \
        params device="/dev/vg1/lv1" directory="/mnt/data" fstype=ext4 force_unmount=true \
        op start interval=0 timeout=60s \
        op stop interval=0 timeout=60s \
        op monitor interval=20s timeout=40s \
        meta priority=1
primitive stonith-sbd stonith:external/sbd \
        params pcmk_delay_max=30s
primitive vg1 LVM-activate \
        params vgname=vg1 vg_access_mode=lvmlockd activation_mode=exclusive \
        op start interval=0 timeout=60s \
        op stop interval=0 timeout=60s \
        op monitor interval=30s timeout=90s \
        meta priority=2
group g-clvm dlm lvmlockd
group mount_process vg1 mount \
        meta target-role=Started
clone c-clvm g-clvm \
        meta interleave=true ordered=true
location cli-ban-mount_process-on-hacluster1 mount_process role=Started -inf: hacluster1
location cli-prefer-mount_process mount_process role=Started inf: hacluster2
property cib-bootstrap-options: \
        have-watchdog=true \
        dc-version="2.0.1+20190417.13d370ca9-lp151.2.9.2-2.0.1+20190417.13d370ca9" \
        cluster-infrastructure=corosync \
        cluster-name=hacluster \
        stonith-enabled=true \
        last-lrm-refresh=1593699969
rsc_defaults rsc-options: \
        resource-stickiness=0 \
        migration-threshold=0 \
        op_defaults \
        id=op-options \
        timeout=5
op_defaults op-options: \
        timeout=5 \
        record-pending=false

Szerintem az lehet, hogy nem szabályos leálláskor 1 node-od marad életben és nem lesz quorum. Van egy no-quorum-policy opció, ami default "freeze", azaz a quorum elvesztése során minden marad ott ahol volt is. Próbálj meg betenni (élesben mindenképp) egy 3. node-ot (vmi pici gép elég) akár standby állapotban (crm node standby) és úgy szimulálni a node kiesést.

A gyors gondolat többet ér, mint a gyors mozdulat.

Koszi a valaszt!

Ezt akkor ket node-al nem is lehet megoldani?

meg egy kerdes. felhuztam egy ilyet:

 

https://i.imgur.com/2c3LKZa.png

 

Mukodik is szepen, de ha pl file copy kozben atterhelem a masik node-ra, akkor megszakad a copy. nem lehet azt valahogy megoldani h tulelje a copy az atterhelest? nyilvan ha par mp-re megakad, az nem gaz, csak ne szakadjon meg.

nalam igy van, egyik node eltunik akkor masik atveszi a dolgokat:
crm configure property no-quorum-policy=ignore
crm configure property stonith-enabled=false

nyilvan ha mindket node el, de split brain* van akkor hulyeseg fog tortenni (=mindketto fel akarja huzni a resourcet), ez ellen csak az ajanlott 3 node segit.

 

* fel lehet venni tobb sync kapcsolatot is (ket-ket interface, sorosport, akarmi)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

igazad van, igazabol ket node eseten nincs is ertelme ezen funkcioknak, hiszen lenyegeben mind1, hogy direkt, vagy fault miatt allt le a masik node, az elsonek at kell vennie a szerepet. A gond akkor lenne, ha nem csak halozati feladatokat vegezne a cluster, akkor lehet az, hogy duplan csinal valamit, de ez nalam nem all fenn.

Kösz Elbandi, kezd osszeallni a dolog!

 

Ami kellett:

crm configure property no-quorum-policy=ignore

 

Ez kellett, alapbol stopped volt,  nyilvan ket node eseten ez nem jo. Igy inditja egybol a szolgaltatast ha a masik elerhetetlen.

 

stonith kikapcsolasa nalam megkavarta a dolgokat, nem akartak valamiert elindulni a szolgaltatasok, uh azt bekapcsolva hagytam.

 

Ezen kivul csinaltam egy group-ot mindenhez ami a file share-hez kell, hogy mindig ugyanazon a node-on induljanak el. Ebben van egy float IP, lvm, es mount. A sorrend balrol-jobbra, nyilvan ez is kell, mert nem mountolja fel, ha nincs mit...

 

Kellett meg egy order is az lvmlockd miatt. Neha ugyanis hamarabb indult volna a file share group, mint az lvmlock, ami meg ugye szinten nem lehetseges. Igy sorrendet allitottam, a mount group csak az lvmlockd utan indulhat.

 

Probaltam mindenhogy "megölni" a clustert, normal shutdown, hard kikapcs... De tuleli :) hard kikapcsnal marad ki 4-5 ping (rendesnel max 1) de ez vallalhato.

 

Ha meg azt sikerulne elerni, hogy a share-t ne dobja el a file copy akkor lenne teljes siker.

Ez a rendszer nem úgy működik, mint virtualizációnál a VM live migration, ahol a memóriakép is átkerül, és szó szerint ott folytatja, ahol tartott (persze ha nem épp meghal egy node, hanem szabályos költözés van).

Itt szolgáltatás áll le-indul el, valójában semmi sem költözik, csak az erősorrásokhoz való hozzáférési "jog" kerül át, és szolgáltatás áll meg (mindegy hol tartott) és indul el (tiszta lappal). Még akkor is, ha működő node-ok esetén is csinálod az átterhetést. A cél node-on induló szolgáltatás példány mit sem tud arról, hogy a forrás node-on hol tartott egy művelet.

vagy pl. egy VMWare Fault Tolerance...

Nem, itt/így sajnos nem így megy. Ha, "billen" a szolgáltatás (IP cím), akkor ebben az esetben újra kell kezdeni pl. a fájlmásolást (mert a forrásnode-on leáll minden, majd egy másik node-on újraindul minden 0-ról). Vannak alkalmazások (Pl. SAP Enqueue Replication vagy SAP HANA nZD takeover), amik tudnak majdnem ilyet (a billenés idejére "Paused" állapotba kerülnek [és pl. a másik node-on is tartanak egy up-to-date session cache/transaction cache replikát], majd minden megy tovább 2-3 ping kiesése után, mintha mi sem történt volna, amikor a rendszer átbillent az új node-ra). Vagy ott van egy hazánkból elszármazott kolléga (nekem csak a magyar Tony Stark - @Lénárd) által fejlesztett termék, ami még a Pacemaker-t is talán képes kiváltani SAP S/4 HANA esetén: "LNWSoft - PMS".

Azt mondjuk még nem írta le Vamp kolléga, hogy pontosan mit is szeretne elérni... ;)

A gyors gondolat többet ér, mint a gyors mozdulat.

Mar a video hossza riaszto :D Production Ready kornyezetben ezert megy a Win (már). De tesztnek jo volt azert a linuxos vonal is. Egeszen barati igy is, amit nyujt a Pacemaker. Olyan kornyezetben, ahol nem terem a fakon a windows licensz, meg hasznat vehetem :)

 

Linuxon egyedul a MoSMB tudja ezeket a feature-oket (Out of the box), de szinten nem open source.. https://www.mosmb.com/ (Viszont van MS hátszele: https://news.microsoft.com/2016/07/21/ryussi-technologies-and-microsoft-announce-new-partnership-in-business-and-technology-solutions/)

https://www.mosmb.com/mosmb-now-supports-transparent-server-failover/

ugyan nem suse-n, de centos-en nálam ez tünt a jobb megoldásnak:

quorum {
    provider: corosync_votequorum
    wait_for_all: 1
    last_man_standing: 1
    two_node: 1
}

+sbd+valami más fencing

itt ha lemegy az egyik node, a last_man_standing miatt marad a quorum, és az életben maradt node át tudja venni a resourceokat.

ha az előttem ajánlott no-quorum-policy=ignore be van állítva és pl ha egy stonith után visszatért node nem éri el networkön a másikat, akkor le fogja lőni. persze ha nem indul el automatikusan a cluster akkor ez nem olyan nagy gond..

Szerkesztve: 2020. 07. 03., p – 21:26

x

A gyors gondolat többet ér, mint a gyors mozdulat.