gfs2 fájlrendszer - dlm gond

Linux-haladó

Sziasztok!

 

Adott egy 3 node-os Swarm cluster, amihet strorage-ot akarok csatolni iSCSI-val. Ott tartok most, hogy a 3 nodehoz sikeresen beallitottam az iSCSI initiatort. A fajlrendszerre ket otletem volt, gfs2 vagy ocfs2. Eloszor ocfs2-vel probalkoztam, de sajnos ugy nez ki, bugos egy kisse...(2. node ot mar nem birom felmountolni, ismert hiba, csomo helyen irjak, Ubuntu, Debian, etc... rendszerek alatt) lenyegeben kernele valogatja epp, hogy megy-e, vagy nem... (nyilvan az enyemmel nem, meg amugy sem biznak igy ra semmit...)

Maradt a gfs2. Fontos, hogy HA meg hasonlok nem kellenek, csak egy shared-disk fájl rendszer. folraktam a gfs2-t , meg a dlm-et (kernel modulok + toolok) de nem akar osszejonni... A hiba lenyegeben ugyanaz, mit ezen a linken:

https://www.linux.org/threads/how-to-set-up-shared-gfs2-filesystem-with…

 

A hibam:

Feb 09 09:12:20 hun25-04v kernel: gfs2: fsid=gitlab:data: Trying to join cluster "lock_dlm", "gitlab:data"
Feb 09 09:12:20 hun25-04v kernel: dlm: no local IP address has been set
Feb 09 09:12:20 hun25-04v kernel: dlm: cannot start dlm lowcomms -107
Feb 09 09:12:20 hun25-04v kernel: gfs2: fsid=gitlab:data: dlm_new_lockspace error -107

Igy formaztam meg a particiot:

mkfs.gfs2 -p lock_dlm -t gitlab:data -j 4 /dev/sdb1

 

probaltam en is egy  /etc/dlm/dlm.conf -ot letrehozni, de nem segitett az sem.

 

Valami otletetek van erre?

( Vamp | 2024. 02. 09., p – 11:14 )

Annyival elore vagyok, hogy kozben rajottem, h ezt igy corosync nelkul nem lehet. szoval felraktam azt is es beconfigoltam. A corosync service el is indul szepen, most mar a dlm is probal, de timeoutra fut... valszeg azt is configolni kene... de meg nem jottem ra, hogyan.

( Vamp | 2024. 02. 09., p – 14:09 )

Szerkesztve: 2024. 02. 09., p – 14:09

OK, egy lepessel megint elore :) a dlm.conf-ot mar felolvassa, viszont a szolgaltatas timeoutol... viszont, amig NEM timeoutol, addig megy a mount parancs... 

( Vamp | 2024. 02. 09., p – 17:40 )

Szerkesztve: 2024. 02. 09., p – 17:41

hmm... ha kikapcsolom a service-t es elinditom kezzel a dlm_controld -t akkor nem all meg, szepen fut...  erzekelik is egymast a masik node-al, ha lelovom, akkor irja a masik oldal szepen..

 

Ilyen a kimenet:

 

hun25-10v:~ # dlm_controld -D
1628 config file log_debug = 1 cli_set 0 use 1
1628 config file daemon_debug = 1 cli_set 1 use 1
1628 config file protocol = tcp cli_set 0 use tcp
1628 dlm_controld 4.1.0 started
1628 our_nodeid 2
1628 node_config 1
1628 node_config 2
1628 found /dev/misc/dlm-control minor 122
1628 found /dev/misc/dlm-monitor minor 121
1628 found /dev/misc/dlm_plock minor 120
1628 /sys/kernel/config/dlm/cluster/comms: opendir failed: 2
1628 /sys/kernel/config/dlm/cluster/spaces: opendir failed: 2
1628 set log_debug 1
1628 set mark 0
1628 set protocol 0
1628 set recover_callbacks 1
1628 cmap totem.cluster_name = 'gitlab_storage'
1628 set cluster_name gitlab_storage
1628 /dev/misc/dlm-monitor fd 13
1628 cluster quorum 1 seq 305 nodes 2
1628 cluster node 1 added seq 305
1628 set_configfs_node 1 10.51.38.66 local 0 mark 0
1628 cluster node 2 added seq 305
1628 set_configfs_node 2 10.51.38.69 local 1 mark 0
1628 cpg_join dlm:controld ...
1628 setup_cpg_daemon 15
1628 dlm:controld conf 2 1 0 memb 1 2 join 2 left 0
1628 daemon joined 1
1628 daemon joined 2
1628 dlm:controld ring 1:305 2 memb 1 2
1628 receive_protocol 2 max 3.1.1.0 run 0.0.0.0
1628 daemon node 2 prot max 0.0.0.0 run 0.0.0.0
1628 daemon node 2 save max 3.1.1.0 run 0.0.0.0
1628 receive_protocol 1 max 3.1.1.0 run 3.1.1.0
1628 daemon node 1 prot max 0.0.0.0 run 0.0.0.0
1628 daemon node 1 save max 3.1.1.0 run 3.1.1.0
1628 run protocol from nodeid 1
1628 daemon run 3.1.1 max 3.1.1 kernel run 1.1.1 max 1.1.1
1628 plocks 16
1628 receive_fence_clear from 1 for 2 result 0 flags 6
1628 clear_startup_nodes 2
1628 fence_in_progress_unknown 0 recv
1628 receive_protocol 2 max 3.1.1.0 run 3.1.1.0
1628 daemon node 2 prot max 3.1.1.0 run 0.0.0.0
1628 daemon node 2 save max 3.1.1.0 run 3.1.1.0
1861 dlm:controld conf 1 0 1 memb 2 join 0 left 1
1861 dlm:controld left reason nodedown 0 procdown 0 leave 1
1861 daemon remove 1 leave need_fencing 0 low 0
2102 dlm:controld conf 2 1 0 memb 1 2 join 1 left 0
2102 daemon joined 1
2102 receive_protocol 1 max 3.1.1.0 run 0.0.0.0
2102 daemon node 1 prot max 0.0.0.0 run 0.0.0.0
2102 daemon node 1 save max 3.1.1.0 run 0.0.0.0
2102 receive_protocol 2 max 3.1.1.0 run 3.1.1.0
2102 receive_fence_clear from 2 for 1 result 0 flags 6
2102 receive_protocol 1 max 3.1.1.0 run 3.1.1.0
2102 daemon node 1 prot max 3.1.1.0 run 0.0.0.0
2102 daemon node 1 save max 3.1.1.0 run 3.1.1.0

( Vamp | 2024. 02. 10., szo – 10:57 )

Meg közelebb:)

 

Jelenleg egy  workaround  al megy minden!

A lényeg, hogy a dlm service type alappol notify. Viszont a notification nem jön, ami készre jelenti a servicet, ezért az default szerint másfél perc után leáll.  Most átállítottam basic re . Így úgy tűnik gond nélkül működik.

 

A kérdés az mi a notification ami nem jön meg....

( Vamp | 2024. 02. 15., cs – 16:54 )

Szerkesztve: 2024. 02. 15., cs – 16:54

Uj info, elv a dlm service akkor jelenti keszre magat, ha a cluster inicializalja magat... ez Pacemaker nelkul sztm nem fog megtortenni.

 

kerdes, igy biztonsagos-e a hasznalata. (simple service type al)

( n.balazs v | 2024. 02. 16., p – 00:41 )

Huuh, de régen csináltam én gfs2-t clusteren. 7-8 éve körülbelül.
Ami rémlik:
- LVM esetén a locking_type-t át kellett állítani. Ez elvileg nálad nincs.
- Megfelelő portokat ki kellett nyitni a tűzfalon (11111, 21064 és 5404, 5405) - Link: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…
- pcs-sel konfiguráltam a clustert. Ennek 2224/tcp a portja.

Ha 3 node-od van, akkor miért -j 4 opcióval formáztad meg a partíciót?