Debian Stretch에서 gfs2 파일 시스템을 마운트할 수 없습니다. dlm 구성 오류일까요?

Debian Stretch에서 gfs2를 사용하려고 하는데 몇 가지 어려움을 겪고 있습니다. 저는 꽤 경험이 많은 Linux 관리자이지만 공유 디스크와 병렬 파일 시스템은 처음 사용합니다.

현재 프로젝트는 gfs2 형식 iscsi 내보내기 장치를 여러 클라이언트에 공유 파일 시스템으로 설치하는 것입니다. 지금은 HA나 펜싱에 관심이 없지만 미래에는 중요해질 수도 있습니다.

iscsi 부분은 괜찮습니다. 대상에 로그인하여 xfs 파일 시스템으로 포맷하고 여러 클라이언트에 마운트하고 동일한 blkid가 표시되는지 확인할 수 있었습니다.

gfs2 사업을 진행하기 위해 Debianstretch "gfs2" 매뉴얼 페이지의 구성표를 따라 구성에 맞게 수정하고 다양한 검색 등으로 약간 장식했습니다.

매뉴얼 페이지는 다음과 같습니다. https://manpages.debian.org/stretch/gfs2-utils/gfs2.5.en.html

실제 오류는 gfs2 파일 시스템을 마운트하려고 할 때 mount 명령이 반환된다는 것입니다.

mount: mount(2) failed: /mnt: No such file or directory

...여기서 /mnt는 존재하는 필수 마운트 지점입니다. (존재하지 않는 마운트 지점에 설치하려고 하면 "설치: 마운트 지점/오류가 존재하지 않습니다."라는 오류가 발생합니다.)

관련하여 모든 설치 시도에서 dmesg는 다음을 보고합니다.

gfs2: can't find protocol lock_dlm

나는 단순히 데비안 패키지가 "/sbin/mount.gfs2"를 제공하지 않는 것이 문제라고 가정하고 그것을 찾았지만 그것은 잘못된 추측이었다고 생각합니다.

나는 pio, pi, pj, pk 및 pl이라는 약간 특이한 이름을 가진 5개의 컴퓨터(Raspberry Pi, 중요하다면)로 구성된 클러스터를 가지고 있습니다. 그들은 모두 고정된 고정 IP 주소를 갖고 있으며 도메인은 없습니다.

Debian gfs2, corosync 및 dlm 제어 패키지를 설치했습니다.

corosync 단계의 경우 내 corosync 구성은 다음과 같습니다(예: pio의 경우 클러스터의 마스터가 되도록 의도됨).

totem {
      version: 2
      cluster_name: rpitest
      token: 3000
      token_retransmits_before_loss_const: 10
      clear_node_high_bit: yes
      crypto_cipher: none
      crypto_hash: none
      nodeid: 17
      interface {
              ringnumber: 0
              bindnetaddr: 192.168.0.17
              mcastport: 5405
              ttl: 1
      }
}
nodelist { 
      node {
              ring0_addr: 192.168.0.17
              nodeid: 17
      }
      node {
              ring0_addr: 192.168.0.11
              nodeid: 1
      }
      node {
              ring0_addr: 192.168.0.12
              nodeid: 2
      }
      node {
              ring0_addr: 192.168.0.13
              nodeid: 3
      }
      node {
              ring0_addr: 192.168.0.14
              nodeid: 4
      }
}
logging {
      fileline: off
      to_stderr: no
      to_logfile: no
      to_syslog: yes
      syslog_facility: daemon
      debug: off
      timestamp: on
      logger_subsys {
              subsys: QUORUM
              debug: off
      }
}
quorum {
      provider: corosync_votequorum
      expected_votes: 5
}

이 파일은 모든 노드에 존재하며 totem 섹션의 nodeid 및 binnetaddr 필드에 적절한 노드별 변경 사항을 적용합니다.

corosync 도구는 모든 노드에서 오류 없이 시작되며 모든 노드에는 corosync-quorumtool의 정상적으로 보이는 출력도 있으므로 다음과 같습니다.

root@pio:~# corosync-quorumtool 
Quorum information
------------------
Date:             Sun Apr 22 11:04:13 2018
Quorum provider:  corosync_votequorum
Nodes:            5
Node ID:          17
Ring ID:          1/124
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3  
Flags:            Quorate 

Membership information
----------------------
Nodeid      Votes Name
         1          1 192.168.0.11
         2          1 192.168.0.12
         3          1 192.168.0.13
         4          1 192.168.0.14
        17          1 192.168.0.17 (local)

dlm-controld 패키지가 설치되고 다음과 같은 간단한 구성으로 /etc/dlm/dlm.conf가 생성됩니다. 다시 말하지만, 나는 지금은 펜싱 경기에 출전하지 않습니다.

dlm.conf 파일은 모든 노드에서 동일합니다.

enable_fencing=0

lockspace rpitest nodir=1
master rpitest node=17

DLM "lockspace" 이름이 corosync 클러스터 이름과 일치해야 하는지 확실하지 않습니다. 어느 쪽이든, 나는 같은 행동을 봅니다.

dlm 제어 서비스가 오류 없이 시작되고 "dlm_tool status" 출력이 정상적으로 보입니다.

root@pio:~# dlm_tool status
cluster nodeid 17 quorate 1 ring seq 124 124
daemon now 1367 fence_pid 0 
node 1 M add 31 rem 0 fail 0 fence 0 at 0 0
node 2 M add 31 rem 0 fail 0 fence 0 at 0 0
node 3 M add 31 rem 0 fail 0 fence 0 at 0 0
node 4 M add 31 rem 0 fail 0 fence 0 at 0 0
node 17 M add 7 rem 0 fail 0 fence 0 at 0 0

gfs2 파일 시스템 작성자:

mkfs -t gfs2 -p lock_dlm -j 5 -t rpitest:one /path/to/device

그 후 "blkid /path/to/device"는 다음을 보고합니다.

/path/to/device: LABEL="rpitest:one" UUID=<stuff> TYPE="gfs2"

모든 iSCSI 클라이언트에서 동일하게 보입니다.

이 시점에서 모든/모든 클라이언트에 gfs2 파일 시스템을 마운트할 수 있어야 한다고 생각하지만 여기서 위의 오류가 발생합니다. mount 명령은 "해당 파일 또는 디렉터리 없음"을 보고하고 dmesg 및 syslog는 "gfs2: 프로토콜 lock_dlm을 찾을 수 없습니다."

다른 여러 gfs2 가이드가 있지만 그 중 다수는 RH/CentOS에만 적용되는 것으로 보이며 cman 또는 Pacemaker와 같은 corosync 이외의 다른 클러스터 관리 시나리오에 적용됩니다. 이것이 반드시 거래를 중단시키는 것은 아니지만 거의 재고가 있는 Debian Stretch에서 이 작업을 수행하는 것은 나에게 가치가 있습니다.

내 생각에는 이것이 매우 단순한 dlm 구성 오류일 수 있는 것 같지만, 이를 정확히 규명할 수는 없습니다.

다른 단서: 내가 다음을 통해 잠금 공간에 "참여"하려고 할 때

dlm_tool join <name>

...dmesg 출력이 표시됩니다.

dlm cluster name 'rpitest' is being used without an application provided cluster name

이는 내가 추가한 잠금 공간이 "rpites"인지 여부에 관계없이 발생합니다. 이는 잠금 공간 이름과 클러스터 이름이 실제로 동일하다는 것을 의미하지만 dlm은 분명히 corosync 구성에 대해 알지 못합니다.