Debian Stretchでgfs2ファイルシステムをマウントできません。 dlm設定エラーですか?

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

私は単にDebianパッケージが "/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などのコロシンク以外の他のクラスタ管理シナリオにも適用されます。これは必ずしも取引を中断するわけではありませんが、ほとんどの在庫があるDebian Stretchでこれを行うことは私にとって価値があります。

私の考えでは、これは非常に単純なdlm構成エラーかもしれませんが、それを正確に特定することはできません。

他の手がかり:私が以下を介してロックスペースに「参加」しようとしたとき

dlm_tool join <name>

... dmesg出力が表示されます。

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

これは、私が追加したロックスペースが「rpites」であるかどうかに関係なく発生します。これは、ロックスペース名とクラスタ名が実際には同じであることを意味しますが、dlmは明らかにcorosync設定については知りません。

ベストアンサー1

Kconfigドキュメントからconfig GFS2_FS_LOCKING_DLM

ほとんどのGFS2ユーザーにはこれが必要です。これにより、クラスター環境で GFS2 を使用するために必要な GFS2 と DLM 間のロック・インターフェースが提供されます。

したがって、有効になっていることを確認してください。それ以外の場合-p lock_dlm(デフォルトのロックプロトコル)を使用してgfs2_mkfs作成されたファイルシステムは使用できません(マウント時にオーバーライドなし)。そして、lock_nolockロックプロトコルは単一ノードのインストールにのみ適用されます。

おすすめ記事