Ceph是目前炙手可热的一个统一分布式存储系统,具有优异的性能、可靠性、可扩展性。其可轻松扩展到数 PB 容量, 支持多种工作负载的高性能(每秒输入/输出操作[IOPS]和带宽),具有极其高的可靠性。Ceph对比HDFS优势在于易扩展,无单点。HDFS是专门为Hadoop这样的云计算而生,在离线批量处理大数据上有先天的优势,而Ceph是一个通用的实时存储系统,具有相当好的超大数量小文件处理能力,且现在Hadoop可以利用Ceph作为存储后端。Ceph最近加入到 Linux 中令人印象深刻的文件系统备选行列,能够在维护 POSIX 兼容性的同时加入了复制和容错功能,成为现在分布式系统的掌上明珠。

而在Ceph系统的搭建过程中会出现种种意想不到问题,真的是稀奇古怪的让人意想不到的问题,整个过程中看似每一步都正确,感觉都对,结果还是出现各种问题,更可恨的是其中遇到的很多问题在网上并不能搜索到,有的从国外论坛上能搜索到但是并没有答案(正如硬件开发时候经常出现都对都不对,重启一下全都对的情况)。然而对于Ceph这块重启并不能解决问题,还需一步一步踏踏实实的进行研究,分析解决问题,并进行总结。

笔者在此对Ceph开发过程中的血泪经验在此与大家分享,对本人在Ceph研发过程中遇到的错误进行记录并提出解决方案,一来是做个总结,二来是为此后进行Ceph开发的大家指出雷区,使大家少爬一点坑,希望能做出一点微小的贡献。

从基础环境开始在Ceph环境搭建过程中的常见问题有(在此按照问题出现的频率进行粗略排序)采用系统为Centos7(谨以此作为示例)

  1. 执行命令:#ceph-deploy install admin-node node1 node2 node3
ERROR:[ceph_deploy][ERROR ]RuntimeError: Failed to execute command: yum -y install epel-release

解决办法:进入/etc/yum.repos.d中删除epel.repo和epel-testing.repo

  1. 执行命令:#ceph-deploy install admin-node node1 node2 node3
ERROR:[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: rpm -Uvh --replacepkgs http://ceph.com/rpm-giant/el6/noarch/ceph-release-1-0.el6.noarch.rpm

解决办法:进入/etc/yum.repos.d/ceph.repo文件将所有的源改为网易163源,或者阿里源(经测试网易163源更好用点)编辑ceph源的配置文件, vim /etc/yum.repo.d/ceph.repo,更改为如下内容:

 [Ceph]

name=Ceph packages for $basearch

baseurl=http:// mirrors.163.com/ceph /rpm-jewel/el7/$basearch

enabled=1

gpgcheck=1

type=rpm-md

gpgkey=https:// mirrors.163.com/ceph /keys/release.asc

priority=1

[Ceph-noarch]

name=Ceph noarch packages

baseurl=http:// mirrors.163.com/ceph /rpm-jewel/el7/noarch

enabled=1

gpgcheck=1

type=rpm-md

gpgkey=https:// mirrors.163.com/ceph /keys/release.asc

priority=1

[ceph-source]

name=Ceph source packages

baseurl=http:// mirrors.163.com/ceph /rpm-jewel/el7/SRPMS

enabled=1

gpgcheck=1

type=rpm-md

gpgkey=https:// mirrors.163.com/ceph /keys/release.asc

priority=1

编辑完成之后保存退出并运行yum clean all && yum makecache

Ceph官网提供的download.ceph.com在一些情况下非常不好用。在此建议使用网易yum

  1. 执行命令:#ceph-deploy install admin-node node1 node2 node3

ERROR:[ceph_deploy][ERROR ] RuntimeError: NoSectionError: No section: ‘ ceph’

解决办法:安装包冲突,直接移除已经安装的 rpm(把各个节点的这个包都移除)

    yum remove ceph-release -y
  1. 执行命令:#ceph-deploy install admin-node node1 node2 node3
ERROR: [ceph1][INFO  ] Running command: yum -y install ceph ceph-radosgw

[ceph1][WARNIN] No data was received after 300 seconds, disconnecting

[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: ceph --version

解决办法:同样是因为一些不明状况的网络问题,(官方网址总是坑人),建议更换网易163源在重新试试

  1. 执行命令:# ceph-deploy mon create-initial
ERROR:[ceph1][ERROR ] “ceph auth get-or-create for keytype admin returned 1

解决办法:ceph.conf 中 public network 配置错误,和 mon_host 不在同一个网段。

配置正确的应该是: mon_host = 192.168.122.18  

public network = 192.168.122.18/24
  1. 执行命令:#ceph-deploy osd prepare node1:/var/local/osd0 …
ERROR: error creating empty object store in /var/local/osd0: (13) Permission denied

[admin-node][ERROR ] RuntimeError: command returned non-zero exitstatus: 1

[ceph_deploy][ERROR ] RuntimeError: Failedto execute command: /usr/sbin/ceph-disk -v activate --mark-init systemd --mount/var/local/osd0

解决办法:权限不够 进入到各节点上运行

chmod 777  /var/local/osd0        或者    chmod  –R  777  /var/local/osd1/

chmod 777  /var/local/osd1
  1. 执行命令:#ceph-deploy osd prepare node1:/var/local/osd0 …

    #ceph-deploy osd activate node1:/var/local/osd0 …

ERROR:要是在原有的osd基础之上重新prepare或者activate osd的话,经常会出现already exist 或者[admin-node][ERROR ] RuntimeError: command returned non-zero exitstatus: 1之类这样的错误。

解决办法:产生此类错误的原因均为再重新安装Ceph的过程中并未将原有的osd进行重新设置,其中还保存有原有的conf信息,并且在集群conf中依旧保存的是原有信息。采用重写conf命令即可解决,建议在重装ceph时均采用–overwrite-conf命令


##admin_socket: exception getting command descriptions: [Errno 2] No such file or directory问题解决

https://blog.csdn.net/huigui65/article/details/78956051?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

#ceph-deploy –overwrite-conf osd prepare node1:/var/local/osd0

#ceph-deploy –overwrite-conf osd activate node1:/var/local/osd0

#ceph-deploy –overwrite-conf mon create-initial

  1. ERROR:[admin-node][WARNIN] Anotherapp is currently holding the yum lock; waiting for it to exit… [admin-node][WARNIN] Anotherapp is currently holding the yum lock; waiting for it to exit…
解决办法:引发此问题的原因为上一次执行yum操作时由于网络问题或者源头问题以及防火墙问题等引起上一次yum操作进程并未执行结束,系统仍在执行该进程,解决办法为关闭此进程。网上博客介绍采用rm -f /var/run/yum.pid命令,但只有部分情况适用。终极必杀技reboot,直接进行reboot,然后进来重新进行操作,包治百病,屡试不爽。
rm -f /var/run/yum.pid    或者 reboot
  1. ERROR:由于多次安装Ceph导致环境不知道哪里出了问题(新旧错误都重叠在一块了)总之怎么样都不能正确进行安装,已经心灰意冷,准备重新安装。

解决方案:再重新安装之前请留步,相信我环境混乱的情况下安装出现问题最多的地方是ceph-deploy install admin-node node1 node2 node3 总之能不重新安装就别重新安装,这中间会引发很多问题。

比较好一点的解决方案,清理Ceph环境,本文在此引用小胖的大话Ceph 的环境清理!

如果之前部署失败了,不必删除ceph客户端,或者重新搭建虚拟机,只需要在每个节点上执行如下指令即可将环境清理至刚安装完ceph客户端时的状态!强烈建议在旧集群上搭建之前清理干净环境,否则会发生各种异常情况。


ps aux|grep ceph |awk '{print $2}'|xargs kill -9

ps -ef|grep ceph

#确保此时所有ceph进程都已经关闭!!!如果没有关闭,多执行几次。

umount /var/lib/ceph/osd/*

rm -rf /var/lib/ceph/osd/*

rm -rf /var/lib/ceph/mon/*

rm -rf /var/lib/ceph/mds/*

rm -rf /var/lib/ceph/bootstrap-mds/*

rm -rf /var/lib/ceph/bootstrap-osd/*

rm -rf /var/lib/ceph/bootstrap-rgw/*

rm -rf /var/lib/ceph/tmp/*

rm -rf /etc/ceph/*

rm -rf /var/run/ceph/*
  1. 执行命令:#ceph-deploy osd prepare node1:/var/local/osd0 …

    #ceph-deploy osd activate node1:/var/local/osd0 …

ERROR:can not find /etc/ceph/osd 或者can not find /etc/ceph/mon等错误,运行完环境清理之后在进行Ceph安装部署时仍然会出现很多问题,如在准备以及激活OSD时候会出现如上错误,原因是清理环境时候将/ect/ceph/文件夹里边的所有东西都已经清理啊干净,系统并不能找到合适的位置进行部署。

解决方案:自己手动在/etc/ceph/文件夹下创建osd mds mon等文件夹

Sudo mkdir /etc/ceph/osd 其他两个如此。

  1. 执行命令:ceph osd tree ceph -s ceph health ceph -w

ERROR:系统卡住什么也不显示,只能手动切断该过程,所有ceph有关命令全部失效。那么就会报错:ERROR: missing keyring。也就是说,用户client.admin登陆 Ceph 系统失败! Error connecting to cluster: ObjectNotFound

解决办法:错误原因位系统不能找到Client :/etc/ceph/ceph.client.admin.keyring。通常我们执行ceph -s 时,就相当于开启了一个客户端,连接到 Ceph 集群,而这个客户端默认是使用 client.admin 的账户密码登陆连接集群的,所以平时执行的ceph -s 相当于执行了 ceph -s –name client.admin –keyring /etc/ceph/ceph.client.admin.keyring。需要注意的是,每次我们在命令行执行 Ceph 的指令,都相当于开启一个客户端,和集群交互,再关闭客户端。

采用

  1. 执行命令:sudo yum update && sudo yum install ceph-deploy

ERROR: 在安装ceph-deploy工具时常见的错误有search for fastest mirror 。。。 302 time out ,或者是404not found等因为网络的原因无法下载。

解决办法:如problem 2所示更换网易163源

或者直接构建本地源来进行安装(在此采用阿里源)

mkdir -p /var/www/html/ceph/10.2.2

cd /var/www/html/ceph/10.2.2

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-base-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-common-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-devel-compat-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-fuse-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-libs-compat-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-mds-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-mon-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-osd-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-radosgw-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-selinux-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/ceph-test-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/cephfs-java-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libcephfs1-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libcephfs1-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libcephfs_jni1-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libcephfs_jni1-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librados2-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librados2-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libradosstriper1-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/libradosstriper1-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librbd1-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librbd1-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librgw2-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/librgw2-devel-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/python-ceph-compat-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/python-cephfs-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/python-rados-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/python-rbd-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/rbd-fuse-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/rbd-mirror-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/rbd-nbd-10.2.2-0.el7.x86_64.rpm

wget http://mirrors.aliyun.com/ceph/rpm-hammer/el7/noarch/ceph-deploy-1.5.36-0.noarch.rpm

此过程不采用deploy工具

  1. ERROR:mds 状态一直为creating状态

ceph mds stat

e6: 1/1/1 up {0=node0=up:creating }, 1 up:standby

解决办法:产生此原因的问题为在ceph集群状态还没有达到HEALTH_OK的状态下就执行ceph-deploy mds create node 的操作,解决途径为等ceph状态为HEALTH_OK时在进行。

  1. ERROR: HEALTH_ERR
health HEALTH_ERR 192 pgs stuck inactive; 192 pgs stuck unclean; no osds monmap e1: 1 mons at {essperf13=209.243.160.45:6789/0}, election epoch 1, quorum 0 essperf13 osdmap e205: 0 osds: 0 up, 0 in pgmap v928: 192 pgs, 3 pools, 0 bytes data, 0 objects 0 kB used, 0 kB / 0 kB avail 192 creating

解决办法:将各个节点上时间进行同步要不然会出现时间漂移错误,使得mon检测的心跳信息出现问题,解决办法参考NTP服务器时间同步

  1. 启动关闭ceph或者查看ceph状态采用(启动start 关闭 stop 重启 restart 查看状态 status)

ceph重启mon命令以node4的mon为例

systemctl restart ceph-mon@node4.service 

ceph重启mon命令以node4的mon为例

systemctl restart ceph-osd@osd.0

ceph重启命令

systemctl restart ceph.target
  1. 重启ceph时应该先启动MON在启动OSD

  2. Ceph pool 中的pg数只能从小到大,不能从大到小

  3. Pg数应该合适,不宜过大或者过小 pg数计算公式为

Total PGs = ((Total_number_of_OSD * 100) / max_replication_count) / pool_count

19:Ceph部署时,执行ceph-deploy mon create-initial时,提示:

>[ceph-mon][DEBUG ] locating the `service` executable...
[ceph-mon][INFO  ] Running command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.ceph-mon
[ceph-mon][WARNIN] /etc/init.d/ceph: line 15: /lib/lsb/init-functions: No such file or directory
[ceph-mon][ERROR ] RuntimeError: command returned non-zero exit status: 1
[ceph_deploy.mon][ERROR ] Failed to execute command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.ceph-mon
[ceph_deploy][ERROR ] GenericError: Failed to create 1 monitors

手动去节点执行该命令,依旧报错,提示缺少/lib/lsb/init-functions

解决方法:

yum install redhat-lsb

由于官方文档没有特别说明,网上大部分ceph配置文章丢三落四。导致配置ceph初始monitor(s)时,各种报错,本文提供了几种解决的办法可供参考。

执行ceph-deploy mon create-initial

报错部分内容如下:

[ceph2][ERROR ] admin_socket: exception getting command descriptions: [Errno 2] No such file or directory
[ceph2][WARNIN] monitor: mon.ceph2, might not be running yet
[ceph2][INFO ] Running command: sudo ceph --cluster=ceph --admin-daemon /var/run/ceph/ceph-mon.ceph2.asok mon_status
[ceph2][ERROR ] admin_socket: exception getting command descriptions: [Errno 2] No such file or directory
[ceph2][WARNIN] monitor ceph2 does not exist in monmap
[ceph2][WARNIN] neither public_addr nor public_network keys are defined for monitors
[ceph2][WARNIN] monitors may not be able to form quorum

注意报错中public_network,这是由于没有在ceph.conf中配置

解决办法:

修改ceph.conf配置文件(此IP段根据个人情况设定),添加public_network = 192.168.1.0/24

修改后继续执行ceph-deploy mon create-initial后,发现依旧报错,报错部分内容如下

[ceph3][WARNIN] provided hostname must match remote hostname
[ceph3][WARNIN] provided hostname: ceph3
[ceph3][WARNIN] remote hostname: localhost
[ceph3][WARNIN] monitors may not reach quorum and create-keys will not complete
[ceph3][WARNIN] ********************************************************************************
[ceph3][DEBUG ] deploying mon to ceph3
[ceph3][DEBUG ] get remote short hostname
[ceph3][DEBUG ] remote hostname: localhost
[ceph3][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
[ceph_deploy.mon][ERROR ] RuntimeError: config file /etc/ceph/ceph.conf exists with different content; use --overwrite-conf to overwrite
[ceph_deploy][ERROR ] GenericError: Failed to create 3 monitors

这里看到错误提示/etc/ceph/ceph.conf内容不同,使用–overwrite-conf来覆盖

命令如下:

ceph-deploy --overwrite-conf config push ceph1 ceph2 ceph3

修改后继续执行ceph-deploy mon create-initial,发现报错还是存在,报错部分内容如下

[ceph3][INFO ] Running command: sudo ceph --cluster=ceph --admin-daemon /var/run/ceph/ceph-mon.ceph3.asok mon_status
[ceph3][ERROR ] admin_socket: exception getting command descriptions: [Errno 2] No such file or directory
[ceph_deploy.mon][WARNIN] mon.ceph3 monitor is not yet in quorum, tries left: 1
[ceph_deploy.mon][WARNIN] waiting 20 seconds before retrying
[ceph_deploy.mon][ERROR ] Some monitors have still not reached quorum:
[ceph_deploy.mon][ERROR ] ceph1
[ceph_deploy.mon][ERROR ] ceph3
[ceph_deploy.mon][ERROR ] ceph2

经过排查发现节点的hostname与/etc/hosts不符

解决办法:修改节点hostname名称,使其与/etc/hosts相符

节点一执行:hostnamectl set-hostname ceph1
节点二执行:hostnamectl set-hostname ceph2
节点三执行:hostnamectl set-hostname ceph3

修改后继续执行ceph-deploy mon create-initial,mmp发现还是报错,报错内容又不一样了,中间部分报错内容如下

[ceph2][ERROR ] no valid command found; 10 closest matches:
[ceph2][ERROR ] perf dump {<logger>} {<counter>}
[ceph2][ERROR ] log reopen
[ceph2][ERROR ] help
[ceph2][ERROR ] git_version
[ceph2][ERROR ] log flush
[ceph2][ERROR ] log dump
[ceph2][ERROR ] config unset <var>
[ceph2][ERROR ] config show
[ceph2][ERROR ] get_command_descriptions
[ceph2][ERROR ] dump_mempools
[ceph2][ERROR ] admin_socket: invalid command
[ceph_deploy.mon][WARNIN] mon.ceph2 monitor is not yet in quorum, tries left: 5
[ceph_deploy.mon][WARNIN] waiting 5 seconds before retrying
[ceph2][INFO ] Running command: sudo ceph --cluster=ceph --admin-daemon /var/run/ceph/ceph-mon.ceph2.asok mon_status
[ceph2][ERROR ] admin_socket: exception getting command descriptions: [Errno 2] No such file or directory

解决办法:在各个节点上执行sudo pkill ceph,然后再在deploy节点执行ceph-deploy mon create-initial

然后发现ERROR报错消失了,配置初始monitor(s)、并收集到了所有密钥,当前目录下可以看到下面这些密钥环

ceph.bootstrap-mds.keyring
ceph.bootstrap-mgr.keyring
ceph.bootstrap-osd.keyring
ceph.bootstrap-rgw.keyring
ceph.client.admin.keyring


有如下报错是因为 systemd版本太低,不支持enable service@写法,需要升级mon节点的systemd,

顺便把所有node节点也升级下,否则后面的激活osd 也会报错

yum install systemd -y
[host215][INFO  ] Running command: sudo systemctl enable ceph.target
[host215][INFO  ] Running command: sudo systemctl enable ceph-mon@host215
[host215][WARNIN] Failed to issue method call: No such file or directory
[host215][ERROR ] RuntimeError: command returned non-zero exit status: 1
[ceph_deploy.mon][ERROR ] Failed to execute command: systemctl enable ceph-mon@host215
[ceph_deploy][ERROR ] GenericError: Failed to create 1 monitors

ceph-deploy报错部署时报错
ceph-deploy mon create-initial
报错如下

[vonlong-2][INFO  ] Running command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.vonlong-2
[vonlong-2][WARNIN] The service command supports only basic LSB actions (start, stop, restart, try-restart, reload, force-reload, status). For other actions, please try to use systemctl.
[vonlong-2][ERROR ] RuntimeError: command returned non-zero exit status: 2
[ceph_deploy.mon][ERROR ] Failed to execute command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.vonlong-2

原因:epel中的ceph-deploy版本过低,从ceph官网下载最新版即可。

https://download.ceph.com/rpm-kraken/el7/noarch/


ceph部署问题解决
注意:
1.ceph-deploy实用程序将输出文件到当前目录。执行ceph-deploy时确保你在这个目录下。
2.不要使用sudo调用ceph-deploy,要么以root用户身份运行它,因为它不会发出远程主机所需的sudo命令。

特殊操作:
1.执行错目录,可以执行以下命令进行清除

ceph-deploy purge {ceph-node}
ceph-deploy purgedata {ceph-node}
ceph-deploy forgetkeys
rm ceph.*

如果你执行清除,你必须重新安装Ceph。最后一个rm命令删除以前安装过程中由ceph-deploy本地写出的所有文件。

2.[ceph_deploy][ERROR ] RuntimeError: NoSectionError: No section: ‘ceph’

yum remove ceph-release
rm /etc/yum.repos.d/ceph.repo.rpmsave

3.运行命令

systemctl status ceph-mon@ceph01
yum install *argparse* -y

4.

export CEPH_DEPLOY_REPO_URL=http://mirrors.163.com/ceph/rpm-jewel/el7
export CEPH_DEPLOY_GPG_URL=http://mirrors.163.com/ceph/keys/release.asc

注意:仅供参考,这里是我解决成功的错误,下面的ceph2是我的用户名,官网上说不能用ceph当用户名。

1、Error:软件包与预期下载的不符。建议:运行 yum –enablerepo=centos-ceph-hammer clean metadata。当这种错误出现时,解决办法有两个:

  重启机器,reboot。

  换一个下载源,目标文件/etc/yum.repos.d/ceph.repo。重新填写内容,换个网址,然后重启reboot。

下面是我的ceph.repo内容,参考别人的
[Ceph]
name=Ceph packages for $basearch
baseurl=http://download.ceph.com/rpm-jewel/el7/$basearch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://download.ceph.com/keys/release.asc
priority=1

[Ceph-noarch]
name=Ceph noarch packages
baseurl=http://download.ceph.com/rpm-jewel/el7/noarch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://download.ceph.com/keys/release.asc
priority=1

[ceph-source]
name=Ceph source packages
baseurl=http://download.ceph.com/rpm-jewel/el7/SRPMS
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://download.ceph.com/keys/release.asc
priority=1 

2、出现的错误[2]。No data was received after 300 seconds, disconnecting…。原因是网络比较慢,达到5分钟超时。

解决办法是:

分别在每个节点上安装ceph,yum -y install ceph。

3、出现的错误[3]。[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: ceph –version。这个错误和上面【2】的错误的解决办法一样。

4、安装ceph时,出现的错误,大致Error是:over-write。导致这个问题原因是修改了ceph用户里的ceph.conf文件,没有把这个文件内的最新信息发送给其他节点,所以要刷新信息,解决命令有两个:

  一是:ceph-deploy --overwrite-conf config push node1-4

  或者:ceph-deploy --overwrite-conf mon create node1-4

5、出现Error:RuntimeError: Failed to execute command: yum -y install epel-release

解决方法:yum -y remove ceph-release

6、在执行命令ceph osd tree时,发现节点名字不是node1-4时,判断是不是已经修改主机名成功,修改主机名称命令是: hostnamectl set-hostname name

7、在执行安装或者准备node节点时,出现了Error:[Errno 2] No such file or directory,说明以前卸载过ceph,但是没有清除干净配置文件,所以要删除以前的配置文件。解决办法是:

  rm -rf /etc/ceph/*

  rm -rf /var/lib/ceph/*/*

  rm -rf /var/log/ceph/*

  rm -rf /var/run/ceph/*

8、出现Error:/var/run/yum.pid 已被锁定,PID 为 xxxx 的另一个程序正在运行。这个问题解决方案是:

  方法一:等一会就好了,1分钟左右

  方法二:rm -f /var/run/yum.pid

9、Error:您必须拥有一个终端来执行 sudo。或者在ceph2用户下输入root密码不好使;(ceph2是我自己的用户名)

解决办法:命令行输入:echo “ceph2 ALL = (root) NOPASSWD:ALL”|sudo tree /etc/sudoers.d/ceph

在执行visudo命令,查看添加成功没有 ceph2 ALL = (root) NOPASSWD:ALL 这段信息。确保visudo命令里面有下面这2句

ceph2 ALL=(ALL) NOPASSWD: ALL

Defalults:ceph2 !requiretty

10、在执行准备节点时,出现ERROR: error creating empty object store in /var/local/osd0: (13) Permission denied

[admin-node][ERROR ] RuntimeError: command returned non-zero exitstatus: 1

[ceph_deploy][ERROR ] RuntimeError: Failedto execute command: /usr/sbin/ceph-disk -v activate --mark-init systemd --mount/var/local/osd0

原因是:创建节点的目录权限不够;解决办法:进入到各节点上运行chmod 777 /var/local/osd0

RBD块设备无法unmap,feature set mismatch
RBD 块设备无法map
问题场景
rbd map test_image
rbd: sysfs write failed
rbd: map failed: (5) Input/output error
通过dmesg|tail
看到
mon1 xxxxxxx:6789 feature set mismatch, my XXXXXX < server’s XXXXXX, missing 4000000000000
分析过程:
知道是特征集合不匹配。
通过比对12.2.0和ceph 12.1.3的crushmap

ceph osd crush show-tunables
可以看到 
[root@sqh0 ~]# ceph osd crush show-tunables 
{ 
“choose_local_tries”: 0, 
“choose_local_fallback_tries”: 0, 
“choose_total_tries”: 50, 
“chooseleaf_descend_once”: 1, 
“chooseleaf_vary_r”: 1, 
“chooseleaf_stable”: 1, 
“straw_calc_version”: 1, 
“allowed_bucket_algs”: 54, 
“profile”: “jewel”, 
“optimal_tunables”: 1, 
“legacy_tunables”: 0, 
“minimum_required_version”: “jewel”, 
“require_feature_tunables”: 1, 
“require_feature_tunables2”: 1, 
“has_v2_rules”: 0, 
“require_feature_tunables3”: 1, 
“has_v3_rules”: 0, 
“has_v4_buckets”: 1, 
“require_feature_tunables5”: 1, 
“has_v5_rules”: 0 
} 

发现 “require_feature_tunables5”: 1,该项变为1,猜想是该配置的原因。想要通过某种方式修改该配置,令它为0.
执行如下命令
解决方法

 ceph osd crush tunables hammer 

再执行ceph osd crush show-tunables
发现该配置项”require_feature_tunables5”: 0.
之后我在rbd map test_image
成功

定义池使用类型
这个是 luminous 版本新特性
在不定义池使用类型时, 会获得下面错误信息

[root@ceph01 mnt]# ceph -s
cluster:
id: a1d6b1f2-b28f-44d0-bcba-0c4840935cbf
health: HEALTH_WARN
application not enabled on 1 pool(s)

services:
mon: 3 daemons, quorum ceph01,ceph02,ceph03
mgr: ceph03(active), standbys: ceph02
osd: 6 osds: 6 up, 6 in

data:
pools: 1 pools, 128 pgs
objects: 478 objects, 1882 MB
usage: 11056 MB used, 49777 MB / 60833 MB avail
pgs: 128 active+clean

设定池类型方法

[root@controller1 ceph]# ceph osd pool application enable volumes rbd
enabled application ‘rbd’ on pool ‘volumes’

  1. 修改 OSD CRUSH weight
    1.1 问题描述
    部署完成后,集群处于 PG Degraded 状态,经查 ceph health detail,发现 PG 的 acting OSD 只有 [0],而不是两个。查 osd tree,osd 日志等,看不出明显问题。

1.2 原因分析
从文章 http://serverfault.com/questions/680492/after-initial-deployment-ceph-cluster-stays-in-activedegraded-state 受到启发,我的 Ceph 集群的 OSD 的 weight 都是 0!!

root@ceph1:/etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      0       root default
-2      0               host ceph1
0       0                       osd.0   up      1
2       0                       osd.2   up      1
-3      0               host ceph2
1       0                       osd.1   up      1
3       0                       osd.3   up      1

我们从上面 ceph osd tree 的结果里面可以看到这里有两个weight:weight 和 reweight。这篇文章 有详细的分析。简单来说:

weight:即 osd crush weight,表示设备(device) 容量的相对值,比如如果1TB对应1.00,那么 500MB 对应 0.50。bucket weight 是所有 item weight 之和,item weight 的变化会影响 bucket weight 的变化,也就是 osd.X 会影响host。 对于 straw bucket,如果 item weight 为0,则 item straw 也为0,当CRUSH 算法在 bucket 选择 item 时,也就不太可能选中该 item。
reweight:取值为0~1。osd reweight 并不会影响 host。当 osd 被踢出集群(out)时,osd weight 被设置0,加入集群时,设置为1。它会参与 CRUSH 创建 PG 的过程。CRUSH在选择 OSD 时,如果发现 weight 为0,就跳过该 OSD。
因此,问题的症结就在于 osd crush weight 为0。至于为什么会这样,以及该值对 PG 分配的影响,有待进一步查明。

1.3 解决办法:修改 osd crush weight

ceph osd crush reweight osd.0 1
ceph osd crush reweight osd.1 1
ceph osd crush reweight osd.2 1
ceph osd crush reweight osd.3 1

修改后,集群就回到了 HEALTH_OK 状态。

注意:修改 OSD 的 crush weight 会带来部分 PG 之间的数据移动,这可能会影响集群的性能,因此在生产环境中使用要小心。你可以参考 这篇文章 来看数据移动的情况。

  1. 修改 CRUSH tunables(可调参数)
    2.1 问题描述
    将 osd.1 设置为 out 后,集群并没有开始做 recovery,部分 PG 保持在 remapped 状态:
root@ceph1:~# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 88 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e71: 4 osds: 4 up, 3 in
      pgmap v442: 256 pgs, 4 pools, 285 MB data, 8 objects
            690 MB used, 14636 MB / 15326 MB avail
                  88 active+remapped
                 168 active+clean

2.2 原因分析
(1). 查看 ceph health detail

root@ceph1:~# ceph health detail
HEALTH_WARN 88 pgs stuck unclean
pg 1.23 is stuck unclean for 337.342290, current state active+remapped, last acting [0,1]
pg 0.1f is stuck unclean for 336.838743, current state active+remapped, last acting [0,1]
pg 1.1f is stuck unclean for 337.355851, current state active+remapped, last acting [0,1]

Remapped(重映射):当 PG 的 acting set 变化后,数据将会从旧 acting set 迁移到新 action set。新主 OSD 需要过一段时间后才能提供服务。因此,它会让老的主 OSD 继续提供服务,直到 PG 迁移完成。数据迁移完成后,PG map 将使用新 acting set 中的主OSD。

以 PG 为例,比较在 osd.1 out 前后的 PG map:

state           state_stamp                     v       reported        up      up_primary      acting      acting_primary
active+clean    2016-06-03 00:31:44.220896      0'0     57:74           [0,1]    0              [0,1]       0               #osd.1 out 之前
active+remapped 2016-06-03 00:47:12.703537      0'0     71:109          [0]      0              [0,1]       0               #osd.1 out 之后

2.3 解决办法
2.3.1 之一:将 crush tunables 设置为 optimal
(2)从这篇文章中获得线索,这可能和 crush tunables 有关系。它的默认值应该是 legacy,运行下面的命令将其修改为 optimal 后,集群状态回到正常。

ceph osd crush tunables optimal
(3)继续找原因,Red Hat 这篇文章 给出了一些线索。

在新版本的Ceph 集群中使用 legacy 值可能会有一些问题,包括:

当叶子bucket(往往是 host)所拥有的设备数目很小时,一些 PG 被映射到的 OSD 数目少于存储池的size。这在 host 节点的 OSD 数目为 1-3 时较为常见。
大型集群中,小部分的 PG 被映射到的 OSD 数目小于规定的数目。这在 CRUSH 层级结构中好几层(比如 row,rack,host,osd 等)时比较常见。
当一些 OSD 被标记为 out 时,重新分布的数据会更多地在附近的 OSD 上而不是整个层级结构中。
而第一种情况正是我的测试集群所遇到的情况,每个 host 拥有的 OSD 数目在3个以内,然后部分 PG 所在的 OSD 数目较 replica 少一些。

关于 CRUSH tunables 的详细信息,请阅读有关文档。请注意在生产环境操作时有一定的风险。

2.3.2 之二:将 OSD 的 reweight 修改为 0 而不是使用 out 命令
Ceph 官方的这篇文章 给出了另一个思路。它认为在主机数目很小的集群中,当一个 OSD 被 out 后,部分 PG 限于 active+remapped 状态是经常出现的。解决办法是先运行 ceph osd in {osd-num} 将集群状态恢复到初始状态,然后运行 ceph osd crush reweight osd.{osd-num} 0 来将这个 osd 的 crush weight 修改为 0,然后集群会开始数据迁移。对小集群来说,reweight 命令甚至更好些。

当集群中 PG 限于 active + remapped 状态时,可以通过 reweight 命令来使得集群恢复正常。当往集群中新加入 OSD 时,为了减少数据移动对集群性能的影响,Ceph 官方建议逐渐地增加 OSD 的 crush weight,比如起始值为0,先设置为 0.2,等数据迁移结束,再设置为 0.4,依此类推,逐渐增加为 0.6,0.8 和 1 甚至更高。在要停用一个 OSD 时,建议采用相反操作,逐渐减少 OSD 的 crush weight 直至 0.

  1. 修改 CRUSH ruleset
    3.1 问题描述
    继续将跟 osd.1 在同意个host 上的 osd.3 out,看看 Ceph 集群能不能继续恢复。Ceph 集群中部分 PG 再次进入 remapped 状态:
root@ceph1:~# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 256 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e77: 4 osds: 4 up, 2 in
      pgmap v480: 256 pgs, 4 pools, 285 MB data, 8 objects
            625 MB used, 9592 MB / 10217 MB avail
                 256 active+remapped

运行 ceph pg 1.0 query 查看 PG 1.0 的状态:

"recovery_state": [
        { "name": "Started\/Primary\/Active",
          "enter_time": "2016-06-03 01:31:22.045434",
          "might_have_unfound": [],
          "recovery_progress": { "backfill_targets": [],
              "waiting_on_backfill": [],
              "last_backfill_started": "0\/\/0\/\/-1",
              "backfill_info": { "begin": "0\/\/0\/\/-1",
                  "end": "0\/\/0\/\/-1",
                  "objects": []},
              "peer_backfill_info": [],
              "backfills_in_flight": [],
              "recovering": [],
              "pg_backend": { "pull_from_peer": [],
                  "pushing": []}},
          "scrub": { "scrubber.epoch_start": "0",
              "scrubber.active": 0,
              "scrubber.block_writes": 0,
              "scrubber.finalizing": 0,
              "scrubber.waiting_on": 0,
              "scrubber.waiting_on_whom": []}},
        { "name": "Started",
          "enter_time": "2016-06-03 01:31:20.976290"}],

可见它已经开始 recovery 了,但是没完成。

3.2 原因分析
PG 的分布和 CRUSH ruleset 有关。我的集群当前只有一个默认的 ruleset:

root@ceph1:~# ceph osd crush rule dump
[
    { "rule_id": 0,
      "rule_name": "replicated_ruleset",
      "ruleset": 0,
      "type": 1,
      "min_size": 1,
      "max_size": 10,
      "steps": [
            { "op": "take",
              "item": -1,
              "item_name": "default"},
            { "op": "chooseleaf_firstn",
              "num": 0,
              "type": "host"},
            { "op": "emit"}]}]

注意其 type 为 “host”,也就是说 CRUSH 不会为一个 PG 选择在同一个 host 上的两个 OSD。而我的环境中,目前只有 ceph1 上的两个 OSD 是in 的,因此,CRUSH 无法为所有的 PG 重新选择一个新的 OSD 来替代 osd.3.

3.3 解决办法
按照以下步骤,将 CRUSH ruleset 的 type 由 “host” 修改为 “osd”,使得 CRUSH 为 PG 选择 OSD 时不再局限于不同的 host。

root@ceph1:# ceph osd getcrushmap -o crushmap_compiled_file
got crush map from osdmap epoch 77
root@ceph1:
# crushtool -d crushmap_compiled_file -o crushmap_decompiled_file
root@ceph1:~# vi crushmap_decompiled_file

rule replicated_ruleset {
        ruleset 0
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type osd #将 type 由 “host” 修改为 “osd”
        step emit
}

root@ceph1:# crushtool -c crushmap_decompiled_file -o newcrushmap
root@ceph1:
# ceph osd setcrushmap -i newcrushmap
set crush map
以上命令执行完毕后,可以看到 recovery 过程继续进行,一段时间后,集群恢复 OK 状态。

root@ceph1:~# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 256 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v493: 256 pgs, 4 pools, 285 MB data, 8 objects
            552 MB used, 9665 MB / 10217 MB avail
                 256 active+remapped
root@ceph1:~# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 137 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v494: 256 pgs, 4 pools, 285 MB data, 8 objects
            677 MB used, 9540 MB / 10217 MB avail
                 137 active+remapped
                 119 active+clean
recovery io 34977 B/s, 0 objects/s
root@ceph1:~# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_OK
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v495: 256 pgs, 4 pools, 285 MB data, 8 objects
            679 MB used, 9538 MB / 10217 MB avail
                 256 active+clean
recovery io 18499 kB/s, 0 objects/s
  1. 将一个 OSD 移出集群
    (1)将该 osd 设置为 out

root@ceph1:/home/s1# ceph osd out osd.1
marked out osd.1.
(2)集群做 recovery

2016-06-03 01:54:21.596632 mon.0 [INF] osdmap e90: 4 osds: 4 up, 3 in
2016-06-03 01:54:21.608675 mon.0 [INF] pgmap v565: 256 pgs: 256 active+clean; 1422 MB data, 2833 MB used, 12493 MB / 15326 MB avail
2016-06-03 01:54:26.352909 mon.0 [INF] pgmap v566: 256 pgs: 1 active, 255 active+clean; 1422 MB data, 2979 MB used, 12347 MB / 15326 MB avail; 2/40 objects degraded (5.000%); 51033 B/s, 0 objects/s recovering
2016-06-03 01:54:28.624334 mon.0 [INF] pgmap v567: 256 pgs: 4 active, 252 active+clean; 1422 MB data, 3427 MB used, 11899 MB / 15326 MB avail; 8/40 objects degraded (20.000%); 51053 B/s, 0 objects/s recovering
2016-06-03 01:54:31.320973 mon.0 [INF] pgmap v568: 256 pgs: 3 active, 253 active+clean; 1422 MB data, 3539 MB used, 11787 MB / 15326 MB avail; 6/40 objects degraded (15.000%); 19414 kB/s, 0 objects/s recovering
2016-06-03 01:54:32.323443 mon.0 [INF] pgmap v569: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail; 77801 kB/s, 0 objects/s recovering
^[[A2016-06-03 01:56:10.949077 mon.0 [INF] pgmap v570: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail

(3)完成后,该 osd 的状态还是 up,表示它的服务还在运行。现在将其服务停掉。

root@ceph1:/home/s1# ssh ceph2 service ceph stop osd.1
/etc/init.d/ceph: osd.1 not found (/etc/ceph/ceph.conf defines , /var/lib/ceph defines )
该命令出错,需要将 osd.1 加入 ceph.conf 中。在 ceph1 上的 ceph.conf 中添加:

[osd]

[osd.1]
host = ceph2

[osd.2]
host = ceph1

[osd.3]
host = ceph2

[osd.0]
host = ceph1

然后运行 ceph-deploy –overwrite-conf config push ceph2 将它拷贝到 ceph2 上。重启所有的 osd 服务。诡异的事情出现了:

root@ceph1:/etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      4       root default
-2      4               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
1       1                       osd.1   up      0
3       1                       osd.3   up      1
-3      0               host ceph2

osd.1 和 osd.3 跑到了 ceph1 节点上!查看 start 命令,它将 curshmap 中的 osd.1 的 host 修改为了 ceph2:

root@ceph1:/etc/ceph# /etc/init.d/ceph -a start osd
=== osd.1 ===
df: ‘/var/lib/ceph/osd/ceph-1/.’: No such file or directory
create-or-move updating item name 'osd.1' weight 1 at location {host=ceph1,root=default} to crush map
Starting Ceph osd.1 on ceph2...
starting osd.1 at :/0 osd_data /var/lib/ceph/osd/ceph-1 /var/lib/ceph/osd/ceph-1/journal

从 这篇文章 可以看出,这其实是Ceph的一个 bug:make osd crush placement on startup handle multiple trees (e.g., ssd + sas)。该bug 在 OSD location reset after restart中也有讨论。目前 Ceph 没有机制可以确保 CRUSH map 结构不变,最简单的办法是在 ceph.conf 中 [OSD] 部分设置 osd crush update on start = false。

尝试手工挪动 osd.1 和 osd.3:

root@ceph1:/etc/ceph# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map
root@ceph1:/etc/ceph# ceph osd crush remove osd.3
removed item id 3 name 'osd.3' from crush map
root@ceph1:/etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
1       0       osd.1   up      0
3       0       osd.3   up      1
root@ceph1:/etc/ceph# ceph osd crush set 1 1 root=default host=ceph2
Error ENOENT: unable to set item id 1 name 'osd.1' weight 1 at location {host=ceph2,root=default}: does not exist

该错误的原因待查。索性直接修改 crush map,然后正确的结果就回来了:

root@ceph1:/etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
1       1                       osd.1   up      0
3       1                       osd.3   up      1

继续运行命令 ssh ceph2 /etc/init.d/ceph stop osd.1 去停止 osd.1 的服务,但是无法停止。据说是因为用 ceph-deploy 部署的 OSD 的服务都没法停止。只能想办法把进程杀掉了。

然后继续执行:

root@ceph1:/etc/ceph# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map
root@ceph1:/etc/ceph# ceph auth del osd.1
updated
root@ceph1:/etc/init# ceph osd rm osd.1
removed osd.1

此时,osd tree 中再也没有 osd.1 了:

root@ceph1:/etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      3       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      1               host ceph2
3       1                       osd.3   up      1
  1. 将一个 OSD 加入集群
    (1)将 /dev/sdb1 分区删除

(2)清理磁盘:ceph-deploy disk zap ceph2:/dev/sdb

(3)创建 OSD:ceph-deploy osd create ceph2:sdb:/dev/sdd1

结果OSD就回来了:

root@ceph1:~# ceph-deploy osd create ceph2:sdb:/dev/sdd1c^C
root@ceph1:~# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
4       0                       osd.4   up      1
1       0                       osd.1   up      1

其实将上面第四步和第五步合并在一起,就是替换一个故障磁盘的过程。

  1. 在特定 OSD 上创建存储池
    我们假设 osd.0 和 osd.2 的磁盘是 SSD 磁盘,osd.1 和 osd.4 的磁盘是 SATA 磁盘。我们将创建两个pool:pool-ssd 和 pool-sata,并确保 pool-ssd 中的对象都保存在 osd.0 和 osd.2 上,pool-sata 中的对象都保存在 osd.1 和 osd.4 上。

(1)修改 CRUSH map

root@ceph1:~# ceph osd getcrushmap -o crushmapdump
got crush map from osdmap epoch 124
root@ceph1:~# crushtool -d crushmapdump -o crushmapdump-decompiled
root@ceph1:~# vi crushmapdump-decompiled
root@ceph1:~# crushtool -c crushmapdump-decompiled -o crushmapdump-compiled
root@ceph1:~# ceph osd setcrushmap -i crushmapdump-compiled

在 crushmapdump-decompiled 文件中添加如下内容:

root ssd {
        id -5
        alg straw
        hash 0
        item osd.0 weight 1
        item osd.2 weight 1
}

root sata {
        id -6
        alg straw
        hash 0
        item osd.1 weight 1
        item osd.4 weight 1
}

# rules
...

rule ssd-pool {
        ruleset 1
        type replicated
        min_size 1
        max_size 10
        step take ssd
        step chooseleaf firstn 0 type osd
        step emit
}

rule sata-pool {
        ruleset 2
        type replicated
        min_size 1
        max_size 10
        step take sata
        step chooseleaf firstn 0 type osd
        step emit
}

(2) ceph osd tree 如下:

root@ceph1:~# ceph osd tree
# id    weight  type name       up/down reweight
-6      2       root sata
1       1               osd.1   up      1
4       1               osd.4   up      1
-5      2       root ssd
0       1               osd.0   up      1
2       1               osd.2   up      1
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
4       0                       osd.4   up      1
1       0                       osd.1   up      1

(3)创建 ssd-pool,其默认的 ruleset 为 0:

root@ceph1:~# ceph osd pool create ssd-pool 8 8
pool 'ssd-pool' created
root@ceph1:~# ceph osd dump | grep -i ssd
pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 126 flags hashpspool stripe_width 0

(4)修改 ssd-pool 的 ruleset 为 ssd-pool 其id 为 1:

root@ceph1:~# ceph osd pool set ssd-pool crush_ruleset 1
set pool 4 crush_ruleset to 1
root@ceph1:~# ceph osd dump | grep -i ssd
pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 1 object_hash rjenkins pg_num 8 pgp_num 8 last_change 128 flags hashpspool stripe_width 0

(5)类似地创建 sata-pool 并设置其 cursh ruleset 为 sata-pool 其id 为 2:

root@ceph1:~# ceph osd pool create sata-pool 8 8
pool 'sata-pool' created
root@ceph1:~# ceph osd pool set sata-pool crush_ruleset 2
set pool 5 crush_ruleset to 2
root@ceph1:~# ceph osd dump | grep -i sata
pool 5 'sata-pool' replicated size 2 min_size 1 crush_ruleset 2 object_hash rjenkins pg_num 8 pgp_num 8 last_change 131 flags hashpspool stripe_width 0

(6)分别放一个文件进这两个pool:

root@ceph1:/home/s1# rados -p ssd-pool put root-id_rsa root-id_rsa
root@ceph1:/home/s1# rados -p sata-pool put root-id_rsa root-id_rsa
root@ceph1:/home/s1# rados -p ssd-pool ls
root-id_rsa
root@ceph1:/home/s1# rados -p sata-pool ls
root-id_rsa

(7)查看对象所在的 OSD

root@ceph1:/home/s1# ceph osd map ssd-pool root-id_rsa
osdmap e132 pool 'ssd-pool' (4) object 'root-id_rsa' -> pg 4.38e001ef (4.7) -> up ([2,0], p2) acting ([2,0], p2)
root@ceph1:/home/s1# ceph osd map sata-pool root-id_rsa
osdmap e132 pool 'sata-pool' (5) object 'root-id_rsa' -> pg 5.38e001ef (5.7) -> up ([4,1], p4) acting ([4,1], p4)

可见,两个pool各自在ssd 和 sata 磁盘上。

  1. rbd map 失败:Input/output error
    7.1 问题描述
    先准备好机器,然后在Ceph集群管理节点上运行 ceph-deploy install client 和 ceph-deploy admin client 来安装和配置该节点。详细过程可以参考 Oracle 这篇文章。 注意第二个命令需要在 /etc/ceph 目录下执行,否则,拷贝到 client 节点上的 ceph.conf 会不正确,运行 ceph -s 也会碰到错误 0 librados: client.admin authentication error (1) Operation not permitted。

    然后执行下面的命令来创建一个卷并mount给该客户端:

root@client:~# rbd create -p pool1 bd1 --size 100
root@client:~# rbd info --image bd1 -p pool1
rbd image 'bd1':
        size 102400 kB in 25 objects
        order 22 (4096 kB objects)
        block_name_prefix: rb.0.383a.2ae8944a
        format: 1
root@client:~# rbd map -p pool1 bd1


rbd: add failed: (5) Input/output error

7.2 问题解决和原因分析
从 这篇文章 中获得线索,需要修改 crushmap 中的

root@client:/home/s1# ceph osd getcrushmap -o crush
got crush map from osdmap epoch 138
root@client:/home/s1# crushtool -i crush --set-chooseleaf_vary_r 0 -o crush.newroot@client:/home/s1# ceph osd setcrushmap -i crush.new
set crush map
root@client:/home/s1# rbd map -p pool1 bd1

初步看起来,这个问题和 linux 内核版本(我的内核版本是 1.13)以及 crush tunables 有关。在 3.15 之前的版本中,chooseleaf_vary_r 的值必须为0。根本原因需要进一步研究。

  1. 修复 stale 状态 PG
    8.1 问题描述
root@client:/home/s1# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 8 pgs stale; 8 pgs stuck stale
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e182: 4 osds: 4 up, 4 in
      pgmap v2569: 336 pgs, 8 pools, 5763 MB data, 1171 objects
            13763 MB used, 6672 MB / 20435 MB avail
                   8 stale+active+clean
                 328 active+clean

学习一下 stale 状态的概念:PG 的状态没有被 ceph-osd 上报给 MON,这意味着存放该 PG 的所有 OSD 都是down 的。MON 将主 OSD down 掉了的 PG 的状态状态设置为 stale。

8.2 问题定位
(1).找出哪些 PG 处于 stale 状态

root@ceph1:~# ceph pg dump | grep stale
dumped all in format plain
5.2     0       0       0       0       0       0       0       stale+active+clean      2016-06-03 03:50:07.049571      0'0     132:6      [4,1]   4       [4,1]   4       0'0     2016-06-03 03:49:50.301465      0'0     2016-06-03 03:49:50.301465
5.3     0       0       0       0       0       0       0       stale+active+clean      2016-06-03 03:50:07.034290      0'0     132:6      [4,1]   4       [4,1]   4       0'0     2016-06-03 03:49:50.302140      0'0     2016-06-03 03:49:50.302140

但是现在 OSD Tree 中不再有 osd.1 和 osd.4,因为这两个 OSD 的盘之前丢了!后来重做成了 osd.3 和 osd.5。这和上面的 stale 状态的概念吻合。重做的时候 OSD磁盘的分区被删除过,不知道数据是否还在。看来,丢失数据也是很容易的事情啊。看来,下次看到某个 OSD down 掉了时,首先应该做的是要将它重新 up 起来。

(2)修复不行

root@ceph1:~# ceph pg repair 5.2
Error EAGAIN: pg 5.2 primary osd.4 not up

(3)只能删除它所属于的 pool 了。注意 PG ID 的前半部分是 pool id,后半部分才是 PG 自己的 id。

root@ceph1:~# ceph osd pool delete sata-pool sata-pool  --yes-i-really-really-mean-it
pool 'sata-pool' removed

其实这么做也不对,因为一个 pool 有多个 PG,其中只有部分是 stale 状态,因此在删除之前要看清楚。这一步骤要十分小心!

(4)ceph -s 恢复正常。

  1. 分离 public network 和 cluster network
    9.1 分离的好处
    (1)提高性能:消除副本创建、数据恢复和再平衡对 public network 的压力;增强 OSD 心跳网络的可靠性。

(2)安全性:使用一个彻底与外网分离的内部网络作为 cluster network,可以防止比如 DDOS 这样的网络攻击。

更多信息,请参阅 NETWORK CONFIGURATION REFERENCE

9.2 分离的方法
(1)配置网络

给每个 OSD 节点增加一块网卡,它的连接方式为 “内部网络”;在虚机内配置静态IP地址,网段为 192.168.1.100/24 (其实用不了这么大的网段).

(2)在 ceph1 上修改 ceph.conf 文件

[global]
...

public network = 192.168.56.100/24
cluster network = 192.168.1.100/24

[mon]

[mon.ceph1] # MON 守护进程只在public network 内
host = ceph1
mon addr = 192.168.56.102:6789

[osd]
osd journal size = 500
osd crush update on start = false

[osd.3] #OSD 守护进程同时在 public 和 cluster network 上
host = ceph2
public addr = 192.168.56.103
cluster addr = 192.168.1.103

[osd.0]
host = ceph1
public addr = 192.168.56.102
cluster addr = 192.168.1.102

[osd.5]
host = ceph2
public addr = 192.168.56.103
cluster addr = 192.168.1.103

[osd.2]
host = ceph1
public addr = 192.168.56.102
cluster addr = 192.168.1.102

(3)将新的 ceph.conf 分发到其它节点上,比如 ceph-deploy –overwrite-conf config push ceph2

(4)重启所有 OSD 和 MON 守护进程

可以在 osd 日志中看到内部网络IP地址被启用了。

  1. 启用客户端 rbd cache
    10.1 步骤
    编辑在客户端的 ceph.conf 文件,添加下面的配置项
[client]
rbd cache = true
rbd cache writethrough until flush = true
admin socket = /var/run/ceph/$cluster-$type.$id.$pid.$cctid.asok
log file = /var/log/ceph/

启动使用 librbd 的应用,比如 fio + rbd ioengine,然后从 client admin socket 中确认cache 被启用了:

root@client:/var/run/ceph# ls
ceph-client.admin.23789.140009021853536.asok
root@client:/var/run/ceph# ceph --admin-daemon ceph-client.admin.23789.140009021853536.asok  config show | grep rbd_cache
  "rbd_cache": "true",
  "rbd_cache_writethrough_until_flush": "false",
  "rbd_cache_size": "33554432",
  "rbd_cache_max_dirty": "25165824",
  "rbd_cache_target_dirty": "16777216",
  "rbd_cache_max_dirty_age": "1",
  "rbd_cache_max_dirty_object": "0",
  "rbd_cache_block_writes_upfront": "false",

注意rbd cache 只对 librbd 起作用,对 kernel rbd 不起作用。

收集资料地址
https://www.cnblogs.com/fang888/p/8405545.html
https://blog.csdn.net/ismr_m/article/details/54024977

文档更新时间: 2020-10-31 00:56   作者:月影鹏鹏