我正在 Debian Stretch 上试验 gfs2，但遇到了一些困难。我是一位经验丰富的 Linux 管理员，但对共享磁盘和并行文件系统不熟悉。
我的直接项目是在多个客户端上安装一个 gfs2 格式的 iSCSI 导出设备作为共享文件系统。目前，我对 HA 或击剑不感兴趣，尽管这在以后可能很重要。
iscsi 部分很好，我能够登录到目标，将其格式化为 xfs 文件系统，并将其安装在多个客户端上并验证它是否显示为相同的 blkid。
为了做 gfs2 业务，我遵循 Debian stretch "gfs2" 手册页上的方案，针对我的配置进行了修改，并通过各种搜索等稍加修饰。
手册页在这里： https ://manpages.debian.org/stretch/gfs2-utils/gfs2.5.en.html
实际错误是，当我尝试挂载我的 gfs2 文件系统时，挂载命令返回
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。它们都有固定的静态 IP 地址，并且没有域。
我已经安装了 Debian gfs2、corosync 和 dlm-controld 软件包。
对于 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
}
该文件存在于所有节点上，对图腾部分中的 nodeid 和 bindnetaddr 字段进行了适当的节点特定更改。
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“锁空间”名称是否应该与 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 文件系统，但这是我得到上述错误的地方——挂载命令报告“没有这样的文件或目录”，并且dmesg 和 syslog 报告“gfs2：找不到协议 lock_dlm”。
还有其他几个 gfs2 指南，但其中许多似乎是特定于 RH/CentOS 的，并且适用于除 corosync 之外的其他集群管理方案，如 cman 或起搏器。这些不一定是交易破坏者，但对我来说，在几乎库存的 Debian Stretch 上进行这项工作是很有价值的。
在我看来，这可能是一个非常简单的 dlm 错误配置，但我似乎无法确定。
附加线索：当我尝试通过“加入”锁定空间时
dlm_tool join <name>
...我得到一个 dmesg 输出：
dlm cluster name 'rpitest' is being used without an application provided cluster name
这与我加入的锁定空间是否为“rpitest”无关。这表明锁空间名称和集群名称确实是同一件事，和/但 dlm 显然不知道 corosync 配置？