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)
En OpenSUSE-t raktam. Ott mit ajalnlasz halozatkezelesre?
crm configure show kimenetet tudsz küldeni?
A gyors gondolat többet ér, mint a gyors mozdulat.
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:
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.
Win. Failover cluster esetében nem szakad le, csak pár mp re megáll. Ezt itt nem lehet valahogy megoldani?
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.
Nincs konkret, csak teszt/kivancsisag. Anyaceg kert egy Failover clustert CIFS megosztas ala winserver2019 alapon, mellette ki akartam probalni ugyanazt linuxal. A Win-es mar kesz van amugy, mukodik.
És a Win2019 CIFS failover közben nem szakad meg a fájl másolás?
UI: látom SMBv3 fícsör a transparent failover. SAMBA-val ez azért nem OOTB.
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..
x
A gyors gondolat többet ér, mint a gyors mozdulat.