ceph分布式存储-常见MON故障处理

wx607e3625ec223 2023-03-28 原文

1. 常见 MON 故障处理

Monitor 维护着 Ceph 集群的信息，如果 Monitor 无法正常提供服务，那整个 Ceph 集群就不可访问。一般来说，在实际运行中，Ceph Monitor的个数是 2n + 1 ( n >= 0) 个，在线上至少3个，只要正常的节点数 >= n+1，Ceph 的 Paxos 算法就能保证系统的正常运行。所以，当 Monitor 出现故障的时候，不要惊慌，冷静下来，一步一步地处理。

1.1 开始排障

在遭遇 Monitor 故障时，首先回答下列几个问题：

Mon 进程在运行吗？

我们首先要确保 Mon 进程是在正常运行的。很多人往往忽略了这一点。

是否可以连接 Mon Server？

有时候我们开启了防火墙，导致无法与 Monitor 的 IP 或端口进行通信。尝试使用 ssh 连接服务器，如果成功，再尝试用其他工具（如 telnet ， nc 等）连接 monitor 的端口。

ceph -s 命令是否能运行并收到集群回复？

如果答案是肯定的，那么你的集群已启动并运行着。你可以认为如果已经形成法定人数，monitors 就只会响应 status 请求。

如果 ceph -s 阻塞了，并没有收到集群的响应且输出了很多 fault 信息，很可能此时你的 monitors 全部都 down 掉了或只有部分在运行（但数量不足以形成法定人数）。

ceph -s 没完成是什么情况？

如果你到目前为止没有完成前述的几步，请返回去完成。然后你需要 ssh 登录到服务器上并使用 monitor 的管理套接字。

1.2 使用 Mon 的管理套接字

通过管理套接字，你可以用 Unix 套接字文件直接与指定守护进程交互。这个文件位于你 Mon 节点的 run 目录下，默认配置它位于 /var/run/ceph/ceph-mon.ID.asok，但要是改过配置就不一定在那里了。如果你在那里没找到它，请检查 ceph.conf 里是否配置了其它路径，或者用下面的命令获取：

ceph-conf --name mon.ID --show-config-value admin_socket请牢记，只有在 Mon 运行时管理套接字才可用。Mon 正常关闭时，管理套接字会被删除；如果 Mon 不运行了、但管理套接字还存在，就说明 Mon 不是正常关闭的。不管怎样，Mon 没在运行，你就不能使用管理套接字， ceph 命令会返回类似 Error 111: Connection Refused 的错误消息。

访问管理套接字很简单，就是让 ceph 工具使用 asok 文件。对于 Dumpling 之前的版本，命令是这样的：

ceph --admin-daemon /var/run/ceph/ceph-mon.<id>.asok <command>对于 Dumpling 及后续版本，你可以用另一个（推荐的）命令：

ceph daemon mon.<id> <command>ceph 工具的 help 命令会显示管理套接字支持的其它命令。请仔细了解一下 config get 、 config show 、 mon_status 和 quorum_status 命令，在排除 Mon 故障时它们会很有用。

1.3 理解 MON_STATUS

当集群形成法定人数后，或在没有形成法定人数时通过管理套接字，用 ceph 工具可以获得 mon_status 信息。命令会输出关于 monitor 的大多数信息，包括部分 quorum_status 命令的输出内容。

下面是 mon_status 的输出样例：

{
    "name": "c",
    "rank": 2,
    "state": "peon",
    "election_epoch": 38,
    "quorum": [
        1,
        2
    ],
    "outside_quorum": [],
    "extra_probe_peers": [],
    "sync_provider": [],
    "monmap": { 
        "epoch": 3,
        "fsid": "5c4e9d53-e2e1-478a-8061-f543f8be4cf8",
        "modified": "2013-10-30 04:12:01.945629",
        "created": "2013-10-29 14:14:41.914786",
        "mons": [
            {   
                "rank": 0,
                "name": "a",
                "addr": "127.0.0.1:6789\/0"
            },
            { 
                "rank": 1,
                "name": "b",
                "addr": "127.0.0.1:6790\/0"
            },
            { 
                "rank": 2,
                "name": "c",
                "addr": "127.0.0.1:6795\/0"
            }
        ]
    }
}

从上面的信息可以看出， monmap 中包含 3 个monitor （ a，b 和 c），只有 2 个 monitor 形成了法定人数， c 是法定人数中的 peon 角色（非 leader 角色）。

还可以看出， a 并不在法定人数之中。请看 quorum 集合。在集合中只有 1 和 2 。这不是 monitor 的名字，而是它们加入当前 monmap 后确定的等级。丢失了等级 0 的 monitor，根据 monmap ，这个 monitor 就是 mon.a 。

那么，monitor 的等级是如何确定的？

当加入或删除 monitor 时，会（重新）计算等级。计算时遵循一个简单的规则： IP:PORT 的组合值越大，等级越低（等级数字越大，级别越低）。因此在上例中， 127.0.0.1:6789 比其他 IP:PORT 的组合值都小，所以 mon.a 的等级是 0 。

1.4 最常见的 Mon 问题

达到了法定人数但是有至少一个 Monitor 处于 Down 状态

当此种情况发生时，根据你运行的 Ceph 版本，可能看到类似下面的输出：

root@OPS-ceph1:~# ceph health detail
HEALTH_WARN 1 mons down, quorum 1,2 b,c
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)

如何解决？

首先，确认 mon.a 进程是否运行。

其次，确定可以从其他 monitor 节点连到 mon.a 所在节点。同时检查下端口。如果开了防火墙，还需要检查下所有 monitor 节点的 iptables ，以确定没有丢弃/拒绝连接。

如果前两步没有解决问题，请继续往下走。

首先，通过管理套接字检查问题 monitor 的 mon_status 。考虑到该 monitor 并不在法定人数中，它的状态应该是 probing ， electing 或 synchronizing 中的一种。如果它恰巧是 leader 或 peon 角色，它会认为自己在法定人数中，但集群中其他 monitor 并不这样认为。或者在我们处理故障的过程中它加入了法定人数，所以再次使用 ceph -s 确认下集群状态。如果该 monitor 还没加入法定人数，继续。

probing 状态是什么情况？

这意味着该 monitor 还在搜寻其他 monitors 。每次你启动一个 monitor，它会去搜寻 monmap 中的其他 monitors ，所以会有一段时间处于该状态。此段时间的长短不一。例如，单节点 monitor 环境， monitor 几乎会立即通过该阶段。在多 monitor 环境中，monitors 在找到足够的节点形成法定人数之前，都会处于该状态，这意味着如果 3 个 monitor 中的 2 个 down 了，剩下的 1 个会一直处于该状态，直到你再启动一个 monitor 。

如果你的环境已经形成法定人数，只要 monitor 之间可以互通，新 monitor 应该可以很快搜寻到其他 monitors 。如果卡在 probing 状态，并且排除了连接的问题，那很有可能是该 monitor 在尝试连接一个错误的 monitor 地址。可以根据 mon_status 命令输出中的 monmap 内容，检查其他 monitor 的地址是否和实际相符。如果不相符，请跳至恢复 Monitor 损坏的 monmap。如果相符，这些 monitor 节点间可能存在严重的时钟偏移问题，请首先参考时钟偏移，如果没有解决问题，可以搜集相关的日志并向社区求助。

electing 状态是什么情况？

这意味着该 monitor 处于选举过程中。选举应该很快就可以完成，但偶尔也会卡住，这往往是 monitors 节点时钟偏移的一个标志，跳转至时钟偏移获取更多信息。如果时钟是正确同步的，可以搜集相关日志并向社区求助。此种情况除非是一些（非常）古老的 bug ，往往都是由时钟不同步引起的。

synchronizing 状态是什么情况？

这意味着该 monitor 正在和集群中的其他 monitor 进行同步以便加入法定人数。Monitor 的数据库越小，同步过程的耗时就越短。

然而，如果你注意到 monitor 的状态从 synchronizing 变为 electing 后又变回 synchronizing ，那么就有问题了：集群的状态更新的太快（即产生新的 maps ），同步过程已经无法追赶上了。这种情况在早期版本中可以见到，但现在经过代码重构和增强，在较新版本中已经基本见不到了。

leader 或 peon 状态是什么情况？

这种情况不应该发生，但还是有一定概率会发生，这常和时钟偏移有关。如果你并没有时钟偏移的问题，请搜集相关的日志并向社区求助。

恢复 Monitor 损坏的 monmap

monmap 通常看起来是下面的样子，这取决于 monitor 的个数：

epoch 3
fsid 5c4e9d53-e2e1-478a-8061-f543f8be4cf8
last_changed 2013-10-30 04:12:01.945629
created 2013-10-29 14:14:41.914786
0: 127.0.0.1:6789/0 mon.a
1: 127.0.0.1:6790/0 mon.b
2: 127.0.0.1:6795/0 mon.c

不过也不一定就是这样的内容。比如，在早期版本的 Ceph 中，有一个严重 bug 会导致 monmap 的内容全为 0 。这意味着即使用 monmaptool 也不能读取它，因为全 0 的内容没有任何意义。另外一些情况，某个 monitor 所持有的 monmap 已严重过期，以至于无法搜寻到集群中的其他 monitors 。在这些状况下，你有两种可行的解决方法：

销毁 monitor 然后新建

只有在你确定不会丢失保存在该 monitor 上的数据时，你才能够采用这个方法。也就是说，集群中还有其他运行正常的 monitors，以便新 monitor 可以和其他 monitors 达到同步。请谨记，销毁一个 monitor 时，如果没有其上数据的备份，可能会丢失数据。

给 monitor 手动注入 monmap

通常是最安全的做法。你应该从剩余的 monitor 中抓取 monmap，然后手动注入 monmap 有问题的 monitor 节点。

下面是基本步骤：

1、是否已形成法定人数？如果是，从法定人数中抓取 monmap ：

ceph mon getmap -o /tmp/monmap2、没有形成法定人数？直接从其他 monitor 节点上抓取 monmap （这里假定你抓取 monmap 的 monitor 的 id 是 ID-FOO 并且守护进程已经停止运行）：

ceph-mon -i ID-FOO --extract-monmap /tmp/monmap3、停止你想要往其中注入 monmap 的 monitor。

4、注入 monmap 。

ceph-mon -i ID --inject-monmap /tmp/monmap5、启动 monitor 。

请记住，能够注入 monmap 是一个很强大的特性，如果滥用可能会对 monitor 造成大破坏，因为这样做会覆盖 monitor 持有的最新 monmap 。

时钟偏移

Monitor 节点间明显的时钟偏移会对 monitor 造成严重的影响。这通常会导致一些奇怪的问题。为了避免这些问题，在 monitor 节点上应该运行时间同步工具。

允许的最大时钟偏移量是多少？

默认最大允许的时钟偏移量是 0.05 秒。

如何增加最大时钟偏移量？

通过 mon-clock-drift-allowed 选项来配置。尽管你可以修改但不代表你应该修改。时钟偏移机制之所以是合理的，是因为有时钟偏移的 monitor 可能会表现不正常。未经测试而修改该值，尽管没有丢失数据的风险，但仍可能会对 monitors 的稳定性和集群的健康造成不可预知的影响。

如何知道是否存在时钟偏移？

Monitor 会用 HEALTH_WARN 的方式警告你。 ceph health detail 应该输出如下格式的信息：

mon.c addr 10.10.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)这表示 mon.c 已被标记出正在遭受时钟偏移。

如果存在时钟偏移该怎么处理？

同步各 monitor 节点的时钟。运行 NTP 客户端会有帮助。如果你已经启动了 NTP 服务，但仍遭遇此问题，检查一下使用的 NTP 服务器是否离你的网络太过遥远，然后可以考虑在你的网络环境中运行自己的 NTP 服务器。最后这种选择可趋于减少 monitor 时钟偏移带来的问题。

客户端无法连接或挂载

检查 IP 过滤表。某些操作系统安装工具会给 iptables 增加一条 REJECT 规则。这条规则会拒绝所有尝试连接该主机的客户端（除了 ssh ）。如果你的 monitor 主机设置了这条防火墙 REJECT 规则，客户端从其他节点连接过来时就会超时失败。你需要定位出拒绝客户端连接 Ceph 守护进程的那条 iptables 规则。比如，你需要对类似于下面的这条规则进行适当处理：

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited你还需要给 Ceph 主机的 IP 过滤表增加规则，以确保客户端可以访问 Ceph monitor （默认端口 6789 ）和 Ceph OSD （默认 6800 ~ 7300 ）的相关端口。

iptables -A INPUT -m multiport -p tcp -s {ip-address}/{netmask} --dports 6789,6800:7300 -j ACCEPT或者，如果你的环境允许，也可以直接关闭主机的防火墙。

1.5 Monitor 数据库失败

数据库崩溃的表现

Ceph monitor 把集群的各种 map 信息存放在 key/value 数据库中，如 LevelDB 。如果 monitor 是因为数据库崩溃而失败，在 monitor 的 log 日志中应该会有如下错误信息：

Corruption: error in middle of record或：

Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

通过健康的 Monitor(s) 恢复

如果还有幸存的 monitor，我们通常可以用新的数据库替换崩溃的数据库。并且在启动后，新加入的成员会和其他健康的伙伴进行同步，一旦同步完成，它就可以为客户端提供服务了。

通过 OSDs 恢复

但是万一所有的 monitors 都同时失败了该怎么办？由于建议用户在部署集群时至少安装 3 个 monitors，同时失效的可能性较小。但是数据中心意外的断电，再加上磁盘/文件系统配置不当，可能会引起底层文件系统失败，从而杀掉所有的 monitors 。这种情况下，我们可以通过存放在 OSDs 上的信息来恢复 monitor 的数据库：

ms=/tmp/mon-store
mkdir $ms
# collect the cluster map from OSDs
for host in $hosts; do
    rsync -avz $ms user@host:$ms
    rm -rf $ms
    ssh user@host <<EOF
        for osd in /var/lib/osd/osd-*; do
            ceph-objectstore-tool --data-path $osd --op update-mon-db --mon-store-path $ms
        done
    EOF
    rsync -avz user@host:$ms $ms
done
# rebuild the monitor store from the collected map, if the cluster does not
# use cephx authentication, we can skip the following steps to update the
# keyring with the caps, and there is no need to pass the "--keyring" option.
# i.e. just use "ceph-monstore-tool /tmp/mon-store rebuild" instead
ceph-authtool /path/to/admin.keyring -n mon. \
  --cap mon allow 'allow *'
ceph-authtool /path/to/admin.keyring -n client.admin \
  --cap mon allow 'allow *' --cap osd 'allow *' --cap mds 'allow *'
ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /path/to/admin.keyring
# backup corrupted store.db just in case
mv /var/lib/ceph/mon/mon.0/store.db /var/lib/ceph/mon/mon.0/store.db.corrupted
mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db

上面的这些步骤：

从所有的 OSD 主机上收集 map 信息。
重建数据库。
用恢复副本替换 mon.0 上崩溃的数据库。

已知的限制

下面这些信息无法通过上述步骤恢复：

一些新增的 keyring ：通过 ceph auth add 命令增加的所有 OSD keyrings 都可以恢复。用 ceph-monstore-tool 可以导入 client.admin 的 keyring 。但是 MDS 和其他 keyrings 在被恢复的那个 monitor 数据库中就会丢失。你可能需要手动重新添加一下。
pg 的设置：通过 ceph pg set_full_ratio 和 ceph pg set_nearfull_ratio 命令设置的 full ratio 和 nearfull ratio 值会丢失。
MDS Maps：MDS maps 会丢失。

磁盘空间不足导致 MON DOWN

当 monitor 进程检测到本地可用磁盘空间不足时，会停止 monitor 服务。Monitor 的日志中应该会有类似如下信息的输出：

2016-09-01 16:45:54.994488 7fb1cac09700  0 mon.jyceph01@0(leader).data_health(62) update_stats avail 5% total 297 GB, used 264 GB, avail 18107 MB
2016-09-01 16:45:54.994747 7fb1cac09700 -1 mon.jyceph01@0(leader).data_health(62) reached critical levels of available space on local monitor storage -- shutdown!

清理本地磁盘，增大可用空间，重启 monitor 进程，即可恢复正常。

通过 Mon 数据库的备份恢复

具体请参考本手册第三部分 2. Monitor 的备份和恢复。

有关ceph分布式存储-常见MON故障处理的更多相关文章

ruby - 解析 RDFa、微数据等的最佳方式是什么，使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2
我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i
ruby - 如何指定 Rack 处理程序 - 2
Rackup通过Rack的默认处理程序成功运行任何Rack应用程序。例如:classRackAppdefcall(environment)['200',{'Content-Type'=>'text/html'},["Helloworld"]]endendrunRackApp.new但是当最后一行更改为使用Rack的内置CGI处理程序时，rackup给出“NoMethodErrorat/undefinedmethod`call'fornil:NilClass”:Rack::Handler::CGI.runRackApp.newRack的其他内置处理程序也提出了同样的反对意见。例如Rack
ruby - 分布式事务和队列，ruby，erlang，scala - 2
我有一个涉及多台机器、消息队列和事务的问题。因此，例如用户点击网页，点击将消息发送到另一台机器，该机器将付款添加到用户的帐户。每秒可能有数千次点击。事务的所有方面都应该是容错的。我以前从未遇到过这样的事情，但一些阅读表明这是一个众所周知的问题。所以我的问题。我假设安全的方法是使用两阶段提交，但协议(protocol)是阻塞的，所以我不会获得所需的性能，我是否正确？我通常写Ruby，但似乎Redis之类的数据库和Rescue、RabbitMQ等消息队列系统对我的帮助不大——即使我实现某种两阶段提交，如果Redis崩溃，数据也会丢失，因为它本质上只是内存。所有这些让我开始关注erlang和
ruby - Rack:如何将 URL 存储为变量？ - 2
我正在编写一个简单的静态Rack应用程序。查看下面的config.ru代码:useRack::Static,:urls=>["/elements","/img","/pages","/users","/css","/js"],:root=>"archive"map'/'dorunProc.new{|env|[200,{'Content-Type'=>'text/html','Cache-Control'=>'public,max-age=6400'},File.open('archive/splash.html',File::RDONLY)]}endmap'/pages/search.
git使用常见问题（提交代码，合并冲突） - 2
文章目录git常用命令（简介，详细参数往下看）Git提交代码步骤gitpullgitstatusgitaddgitcommitgitpushgit代码冲突合并问题方法一：放弃本地代码方法二：合并代码常用命令以及详细参数gitadd将文件添加到仓库：gitdiff比较文件异同gitlog查看历史记录gitreset代码回滚版本库相关操作远程仓库相关操作分支相关操作创建分支查看分支：gitbranch合并分支：gitmerge删除分支：gitbranch-ddev查看分支合并图：gitlog–graph–pretty=oneline–abbrev-commit撤消某次提交git用户名密码相关配置g
ruby-on-rails - 为什么在 Rails 5.1.1 中删除了 session 存储初始化程序 - 2
我去了这个website查看Rails5.0.0和Rails5.1.1之间的区别为什么5.1.1不再包含:config/initializers/session_store.rb？谢谢最佳答案这是删除它的提交:Setupdefaultsessionstoreinternally,nolongerthroughanapplicationinitializer总而言之，新应用没有该初始化器，session存储默认设置为cookie存储。即与在该初始值设定项的生成版本中指定的值相同。关于
Ruby-vips 图像处理库。有什么好的使用示例吗？ - 2
我对图像处理完全陌生。我对JPEG内部是什么以及它是如何工作一无所知。我想知道，是否可以在某处找到执行以下简单操作的ruby代码:打开jpeg文件。遍历每个像素并将其颜色设置为fx绿色。将结果写入另一个文件。我对如何使用ruby-vips库实现这一点特别感兴趣https://github.com/ender672/ruby-vips我的目标-学习如何使用ruby-vips执行基本的图像处理操作(Gamma校正、亮度、色调……)任何指向比“helloworld”更复杂的工作示例的链接——比如ruby-vips的github页面上的链接，我们将不胜感激!如果有ruby-
ruby - 将对象设置为 nil 是否很常见？ - 2
我正在构建一个应用程序，想知道是否将未使用的对象设置为nil是生产级编码中的常见做法。我知道这只是垃圾收集器的提示，并不总是处理对象。最佳答案根据这个thread如果您使用完一个成员对象，将其设置为nil将引发被引用对象被垃圾回收。如果它是局部变量，方法exit将做同样的事情。也就是说，如果您要求将成员显式设置为nil，我会质疑您的设计。关于ruby-将对象设置为nil是否很常见？，我们在StackOverflow上找到一个类似的问题： https://
ruby - Faye WebSocket，关闭处理程序被触发后重新连接到套接字 - 2
我有一个super简单的脚本，它几乎包含了FayeWebSocketGitHub页面上用于处理关闭连接的内容:ws=Faye::WebSocket::Client.new(url,nil,:headers=>headers)ws.on:opendo|event|p[:open]#sendpingcommand#sendtestcommand#ws.send({command:'test'}.to_json)endws.on:messagedo|event|#hereistheentrypointfordatacomingfromtheserver.pJSON.parse(event.d
ruby-on-rails - 尝试设置 Amazon 的 S3 存储桶 : 403 Forbidden error & setting permissions - 2
我正在关注Hartl的railstutorial.org并已到达11.4.4:Imageuploadinproduction.我做了什么:注册亚马逊网络服务在AmazonIdentityandAccessManagement中，我创建了一个用户。用户创建成功。在AmazonS3中，我创建了一个新存储桶。设置新存储桶的权限:权限:本教程指示“授予上一步创建的用户读写权限”。但是，在存储桶的“权限”下，未提及新用户名。我只能在每个人、经过身份验证的用户、日志传送、我和亚马逊似乎根据我的名字+数字创建的用户名之间进行选择。我已经通过选择经过身份验证的用户并选中了上传/删除和查看权限的框(而不