我有一个小型的 3 主机 Ceph 集群，其中有 Ubuntu 20.04.1 和 Ceph 15.2.5，使用 docker 容器并使用 cephadm 部署。昨天，其中一台主机 (s65-ceph) 断电了。其他两台主机继续工作了一段时间，但随后 s63-ceph 和 s64-ceph 开始用“ e5 handle_auth_request failed to assign global_id”填充它们的日志，来自监视器，因此它们的硬盘已满。我在其他时候也收到过这种类型的错误，问题只是时钟偏差。我已经同步了它们的时钟，但时钟偏差似乎不是这里的问题。我还重新启动了 ceph.target 并多次重新启动所有机器，但无济于事。我很长时间没有对集群进行任何更改，所以我也知道这个错误不是某种配置错误。
我曾尝试按照文档监控故障排除页面。但奇怪的是 s64-ceph 将其自身和 s63-ceph 列在法定人数中，而 s63-ceph 却表示其不在法定人数中。以下是 mon_status 命令返回的内容：s63-头孢菌素，s64-ceph。我还可以从其他主机远程登录到 3300 和 6789，所以我知道网络没问题。s65-ceph 上的监视器（及其容器）已关闭，因此没有 mon_status。如果它有用，嘻嘻集群配置。我已将 s64-ceph 的日志上传到这里（删除了包含 handle_auth_request 错误的重复行和所有 grafana/prometheus/dashboard 行）。S63-ceph 基本上有相同的日志。
我知道有一个非常相似的问题这里，但没有任何答案。这是一个生产系统，因此如果没有办法让集群恢复正常运行，如果有某种安全的方法可以恢复我的文件（集群仅用于 CephFS），我将不胜感激。
提前致谢。
答案1
我终于解决了这个问题，但有关这方面的文档相当模糊，所以我将自己回答这个问题。看来宕机的主机也已经填满了磁盘，这就是为什么它的行为与其他两台主机不同，以及为什么它的 mon 无法启动。我通过清除旧日志和不必要的包解决了这个问题。这意味着这三个主机的行为相同，因为所有三个 mon 都可以启动。
为了排除集群故障，我发现最简单的方法是获取每个监视器的 mon_status。我使用 cephadm，因此下面的命令与 Docker 容器有关。在“正常”设置中，你应该执行sudo ceph tell mon.s64-ceph mon_status。
ceph --admin-daemon /run/ceph/9ea4d206-baec-11ea-b970-2165cf493db2/ceph-mon.<mon_name>.asok mon_status
这会给你类似这样的结果：
{
"name": "s64-ceph",
"rank": 0,
"state": "leader",
"election_epoch": 25568,
"quorum": [
0,
1
],
"quorum_age": 17,
"features": {
"required_con": "2449958747315978244",
"required_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
],
"quorum_con": "4540138292836696063",
"quorum_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
]
},
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 5,
"fsid": "9ea4d206-baec-11ea-b970-2165cf493db2",
"modified": "2020-07-15T12:13:10.390355Z",
"created": "2020-06-30T16:15:22.596364Z",
"min_mon_release": 15,
"min_mon_release_name": "octopus",
"features": {
"persistent": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
],
"optional": []
},
"mons": [
{
"rank": 0,
"name": "s64-ceph",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.2.64.2:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.2.64.2:6789",
"nonce": 0
}
]
},
"addr": "10.2.64.2:6789/0",
"public_addr": "10.2.64.2:6789/0",
"priority": 0,
"weight": 0
},
{
"rank": 1,
"name": "s63-ceph",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.2.63.2:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.2.63.2:6789",
"nonce": 0
}
]
},
"addr": "10.2.63.2:6789/0",
"public_addr": "10.2.63.2:6789/0",
"priority": 0,
"weight": 0
},
{
"rank": 2,
"name": "s65-ceph",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.2.65.2:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.2.65.2:6789",
"nonce": 0
}
]
},
"addr": "10.2.65.2:6789/0",
"public_addr": "10.2.65.2:6789/0",
"priority": 0,
"weight": 0
}
]
},
"feature_map": {
"mon": [
{
"features": "0x3f01cfb8ffadffff",
"release": "luminous",
"num": 1
}
],
"client": [
{
"features": "0x27018fb86aa42ada",
"release": "jewel",
"num": 1
}
]
}
}
如果您查看仲裁字段，它仅列出三台监视器中的两台作为仲裁。这是因为 s65-ceph 的磁盘已满，并且其 mon 无法启动。当您启动第三台主机的 mon 时，它将显示所有三台监视器都在仲裁中。
通常情况下，即使只有 2/3 的监视器处于运行状态，Ceph 也应该能够运行（尽管不是处于健康状态），因为 2/3 是多数，这意味着它们能够形成法定人数。然而，这里的情况并非如此。检查每台主机上的日志，至少在我的情况下，它们非常频繁地要求选举（您会看到包含“要求选举”的行）。它们如此频繁地要求选举（大约每 5-10 秒一次），因此它们在集群再次可供用户使用之前切换监视器，这就是集群总是出现故障的原因。
在排除许多问题时，我保持 Glances 处于打开状态，我注意到 RAM 利用率非常高，并且当 mons 进行选举时，网络和磁盘读/写出现峰值，这让我认为频繁的监视器切换导致了高 IO，而分页使 IO 问题更加严重。我发现一篇博客文章这似乎支持了这一点。
我无法向任何主机添加更多 RAM 来测试这一点，但我发现，如果一个监视器非常慢，其他监视器将要求选举。就我而言，我使用的 HDD 速度不够快，无法进行持续的监视器切换（即频繁的随机读写），这意味着如果一个监视器刚刚被选为领导者，它会在几秒钟内写入其 HDD，但在此过程中它会极其迟钝。这意味着其他监视器将要求选举，而另一个监视器将面临同样的问题。这种循环将以某种正反馈的方式不断持续下去。
我最终发现有一个名为 mon_lease 的参数，默认情况下设置为 5.0 秒。它控制其他监视器在再次要求选举之前等待给定监视器响应的时间。5 秒是默认值，因为 Ceph 通常在速度较快的服务器上运行，但我知道我的集群运行速度要慢得多，因为我使用三台非常旧的回收笔记本电脑作为集群。我使用以下命令将 mon_lease 时间设置为 30 秒，这样这个频繁切换的问题就会消失，而且我也没有在 Ceph 上运行太多软件，所以如果有 mon 切换，我并不担心读/写超时。更改 mon_lease 后，等待几分钟，然后检查您的日志。您应该发现没有任何主机在进行持续的监视器切换。确保检查您的集群是否按预期工作，最好重新启动所有 Ceph 主机，以确保下次启动时一切都能正常工作。
ceph --admin-daemon /run/ceph/9ea4d206-baec-11ea-b970-2165cf493db2/ceph-mon.s64-ceph.asok config set mon_lease 30.0
我希望我的回答可以帮助某人避免遇到与 Ceph 相同的不幸，如果您需要澄清，请发表评论。