ceph系列四、monitor数据恢复

最新推荐文章于 2024-11-29 19:24:52 发布

沉舟已过

最新推荐文章于 2024-11-29 19:24:52 发布

阅读量1.6k

点赞数

分类专栏： ceph 文章标签： ceph

本文链接：https://blog.csdn.net/effort6/article/details/106870214

版权

ceph 专栏收录该内容

4 篇文章 2 订阅

订阅专栏

ceph作为分布式存储系统与传统的存储系统相比就是没有中心节点，也就是每次访问不需要经过中心节点分发请求或者获取路由信息等。这样做的好处就是容易扩展同时避免中心节点的瓶颈。每次请求都是client根据crush计算目标的osd，然后直接与osd进行通讯。

monitor作为ceph的管理节点，肩负着分布式存储的数据同步管理工作、策略的管理等。其中策略就包括多种map，比如crushmap、monmap、osdmap等。当monitor发生故障时就会影响集群的数据同步，甚至导致集群无法访问。ceph在创建之初就考虑到这些问题，通过monitor的集群来提高可用性、扩展性等。

回归本章的重点monitor的故障处理。一个集群建议部署3个节点的monitor，monitor内部通诺paxos算法选举leader。当小于半数的monitor出现故障时，集群可以正常使用。当多于半数monitor或者所有monitor出现故障是，会导致整个ceph集群不可用。

一、mon操作

在处理mon的故障之前，先了解一下mon的基本操作。

（1）添加mon节点

查看mon节点状态

[root@test-01 ~]# ceph mon stat
e2: 3 mons at {test-01=192.168.0.240:6789/0,test-02=192.168.0.241:6789/0}, election epoch 24, quorum 0,1 test-01,test-02

获取mon的信息

[root@test01 ~]# ceph auth get mon. -o /tmp/keyring
exported keyring for mon.

[root@test01 ~]# ceph mon getmap -o /tmp/map
got monmap epoch 2

添加mon配置

在新的节点的ceph.conf中添加下面配置
[mon.test-03]
    host                       = test-03 
    mon addr                   = 192.168.0.242:6789

复制mon信息到新节点

[root@test01 ~]# scp /tmp/keyring /tmp/map root@test-03:/tmp

[root@test03 ~]# ceph-mon -i test-03 --mkfs --monmap /tmp/map --keyring /tmp/keyring 
ceph-mon: created monfs at /mon for mon.test-03

加入集群

[root@test03 ~]# ceph mon add test-03 192.168.0.242:6789
added mon.test-03 at 192.168.0.242:6789/0

（2）删除mon节点

删除节点比较简单，主要就是从集群中剔除节点

踢出集群（mon可以正常使用）

[root@test03 ~]# ceph mon remove test-03 192.168.0.242:6789
removed mon.test-03 at 192.168.0.242:6789/0, there are now 2 monitors

踢出集群（mon无法正常使用，如半数以上节点坏掉）

# 通过ceph-mon导出monmap
# ceph-mon --extract-monmap /tmp/monmap   

# 删除损坏的节点
# monmaptool --remove test-03 /tmp/monmap

# 重新导入monmap
#ceph-mon --inject-monmap /tmp/monmap

二、少数monitor节点损坏的恢复

查找mon节点损坏的原因，如果是外部原因导致，比如硬盘损坏等。可以通过删除节点，等故障问题处理后再重新添加节点即可。

三、多数monitor节点损坏的恢复

多数mon节点故障的情况下，ceph集群基本不可用。这个时候要先弄清楚导致mon不可用的原因。

如果是外部原因，比如服务器宕机。故障解除后重启mon即可。
如果外部原因短期无法解除，可以先把故障的mon节点都剔除集群，仅保留可用的节点从而优先保证集群的可用性。

四、全部monitor节点损坏的恢复（mon数据没丢失）

mon节点全部故障的情况下，ceph集群无法使用。这个时候要先弄清楚导致mon不可用的原因。

如果是外部原因，比如服务器宕机。故障解除后重启mon即可。
如果是其他原因导致mon无法正常启动，可以重新创建mon节点（注意备份元数据），节点创建后，把原来的mon数据复制过去（主要是store.db），重启mon即可。

五、全部monitor节点损坏的恢复（mon数据丢失）

这个时候需要从osd节点恢复mon的数据。mon的数据都是存储在osd里面。

恢复mon元数据（store.db）

#! /bin/sh
ms=/tmp/mon-store/
mkdir $ms

declare -a hosts=(test-01 test-02 test-03)
echo ${hosts[*]}

# collect the cluster map from OSDs
for host in $hosts; do
  rsync -avz $ms root@host:$ms
  rm -rf $ms
  echo $host
  ssh root@host
    for osd in /var/lib/osd/ceph-*; do
	   echo $osd
       ceph-objectstore-tool --data-path $osd --op update-mon-db --mon-store-path $ms
    done
  rsync -avz root@host:$ms $ms
done

注：rsync目录必须带最后一个"/"

2.权限处理

# 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