Ceph集群磁盘无剩余空间的解决方法(2)
解决方案一(已验证)
增加OSD节点，这也是官方文档中推荐的做法，增加新的节点后，Ceph开始重新平衡数据，OSD使用空间开始下降
2015-04-29&06:51:58.623262&osd.1&[WRN]&OSD&near&full&(91%)&2015-04-29&06:52:01.500813&osd.2&[WRN]&OSD&near&full&(92%)&
解决方案二(理论上，没有进行验证)
如果在没有新的硬盘的情况下，只能采用另外一种方式。在当前状态下，Ceph不允许任何的读写操作，所以此时任何的Ceph命令都不好使，解决的方案就是尝试降低Ceph对于full的比例定义，我们从上面的日志中可以看到Ceph的full的比例为95%，我们需要做的就是提高full的比例，之后尽快尝试删除数据，将比例下降。
尝试直接用命令设置，但是失败了，Ceph集群并没有重新同步数据，怀疑可能仍然需要重启服务本身
ceph&mon&tell&\*&injectargs&'--mon-osd-full-ratio&0.98'
修改配置文件，之后重启monitor服务，但是担心出问题，所以没有敢尝试该方法，后续经过在邮件列表确认，该方法应该不会对数据产生影响，但是前提是在恢复期间，所有的虚拟机不要向Ceph再写入任何数据。
默认情况下full的比例是95%，而near full的比例是85%，所以需要根据实际情况对该配置进行调整。
[global]&&&&&mon&osd&full&ratio&=&.98&&&&&mon&osd&nearfull&ratio&=&.80&
根据Ceph官方文档中的描述，当一个OSD full比例达到95%时，集群将不接受任何Ceph
Client端的读写数据的请求。所以导致虚拟机在重启时，无法启动的情况。
从官方的推荐来看，应该比较支持添加新的OSD的方式，当然临时的提高比例是一个解决方案，但是并不推荐，因为需要手动的删除数据去解决，而且一旦再有一个新的节点出现故障，仍然会出现比例变满的状况，所以解决之道最好是扩容。
在这次故障过程中，有两点是值得思考的：
监控：由于当时服务器在配置过程中DNS配置错误，导致监控邮件无法正常发出，从而没有收到Ceph WARN的提示信息
云平台本身：
由于Ceph的机制，在OpenStack平台中分配中，大多时候是超分的，从用户角度看，拷贝大量数据的行为并没有不妥之处，但是由于云平台并没有相应的预警机制，导致了该问题的发生
/docs/master/rados/configuration/mon-config-ref/#storage-capacity
博文出处：http://blog.csdn.net/xiaoquqi/article/details/
顶一下(0) 踩一下(0)
热门标签：ceph存储（220）
配置监视器/ OSD交互
在你已完成初始Ceph的配置之后，你可以部署和运行Ceph。当你执行一个命令，如 ceph health 或 ceph -s, Ceph的监视器报告CEPH存储集群的当前状态.Ceph监视器通过要求每个OSD、其它相邻OSD的状态的报告了解集群.。如果Ceph的监视器没有收到报告，或者如果它接收Ceph的存储集群的变化的报告，Ceph的监视器需要更新的CEPH集群映射的状态。
Ceph为Ceph的监视器/Ceph的OSD守护程序交互的提供合理的默认设置。但是，你可以覆盖默认值。以下部分描述Ceph的监视器如何和Ceph的OSD守护互动为了Ceph的存储集群监控。
OSD检查HEARTBEATS
每个Ceph的OSD守护程序每6秒检查其它Ceph的OSD守护进程的heartbeat。 你可以在你的Ceph配置文件中在 [osd] 部分通过增加一个 osd heartbeatinterval 设置来改变heartbeat间隔,或者通过设置运行时间的值。 如果邻居的Ceph的OSD守护在20秒的宽限期不显示heartbeat，Ceph的OSD守护进程可能考虑周边的Ceph OSD守护状态为down并且报告给一个Ceph的监视器，这将导致更新的CEPH集群映射。你可以在你的Ceph配置文件中在
[osd] 部分通过增加一个 osd heartbeat grace 设置来改变宽限期,或者通过设置运行时间的值。
OSD报告状态为DOWN的OSDS
默认情况下，Ceph的OSD守护程序在Ceph的监控器了解该被报告Ceph的OSD守护为down状态之前，必须把另一个Ceph的OSD守护为down状态三次报告Ceph的监视器。 你可以在你的Ceph配置文件中在 [mon] 部分通过增加一个 mon osd min down reports (osdmin down reports 在 v0.62之前)设置来改变osd down报告的最小数,或者通过设置运行时间的值。默认情况下，只有一个Ceph
OSD 守护被要求报告另一个Ceph OSD Daemon状态是down。你可以在你的Ceph配置文件中在 [mon] 部分通过增加一个 mon osd min down (osdmin down reporters''在 v0.62之前)设置来改变osd down报告的最小数,或者通过设置运行时间的值。
OSD报告同等级的OSD失败
如果一个Ceph OSD守护不能与其它任何由它的Ceph配置文档(或者集群映射)所决定的Ceph OSD守护，它将会每30秒ping一个最近从集群映射中复制过来的Ceph监视器。&你可以在你的Ceph配置文件中在&[osd]&部分通过增加一个&osd
mon heartbeat interval设置来改变&heartbeat间隔,或者通过设置运行时间的值。
OSD报告它们的状态
如果一个Ceph OSD 守护进程每次至少120秒不报告它的状态, 那么Ceph监视器将会认为Ceph OSD 守护进程状态为 down.你可以在你的Ceph配置文件中在 [osd] 部分通过增加一个 osd mon report intervalmax 设置来改变 Ceph 监视器报告间隔,或者通过设置运行时间的值。Ceph OSD 守护进程尝试每30秒报告它的状态。你可以在你的Ceph配置文件中在
[osd]部分通过增加一个 osd mon report interval min 设置来改变 Ceph OSD守护进程报告间隔,或者通过设置运行时间的值。
当改变heartbeat设置时, 你应该把它们包含在你的配置文档的[global]部分。
监视器设置
mon osd min up ratio
描述: 在Ceph标记Ceph OSD守护进程为down状态之前，Ceph OSD守护进程up状态的最小比率
类型: Double
默认值: .3
mon osd min in ratio
描述: 在Ceph标记Ceph OSD守护进程为out状态之前，Ceph OSD守护进程in状态的最小比率
类型: Double
默认值: .3
mon osd laggy halflife
描述: laggy估计会衰败的秒数
类型: Integer
默认值: 60*60
mon osd laggy weight
描述: 在laggy估算时新样本的重量
类型: Double
默认值: 0.3
mon osd adjust heartbeat grace
描述: 如果设置为 true, Ceph将会依据laggy估算测量。
类型: Boolean
默认值: true
mon osd adjust down out interval
描述: 如果设置为 true, Ceph将会依据laggy估算测量。
类型: Boolean
默认值: true
mon osd auto mark in
描述: 在Ceph存储集群中，Ceph将标记任何引导Ceph OSD守护进程为in状态
类型: Boolean
默认值: false
mon osd auto mark auto out in
描述: 在Ceph存储集群之外，Ceph将自动标记任何引导Ceph OSD守护进程为in状态
类型: Boolean
默认值: true
mon osd auto mark new in
描述: 在Ceph存储集群中，Ceph将标记新的引导Ceph OSD守护进程为in状态
类型: Boolean
默认值: true
mon osd down out interval
描述: 在标记一个Ceph OSD守护进程状态为down 和 out之前，如果Ceph OSD守护进程不响应，Ceph将会等待的秒数。
类型: 32-bit Integer
默认值: 300
mon osd downout subtree limit
描述: Ceph将会自动标记为out状态的最大的 CRUSH 单元类型
类型: String
默认值: rack
mon osd report timeout
描述: 在声明Ceph OSD守护进程状态为down之前，宽限期的秒数。
类型: 32-bit Integer
默认值: 900
mon osd min down reporters
描述: 报告一个状态为down的Ceph OSD守护进程所需的Ceph OSD守护进程的最小数。
类型: 32-bit Integer
默认值: 1
mon osd min down reports
描述: 一个Ceph OSD守护进程必须报告另一个Ceph OSD守护进程状态为down的最小次数
类型: 32-bit Integer
默认值: 3
osd heartbeat address
描述: 一个Ceph OSD守护进程为heartbeat的网络地址。
类型: Address
默认值: 主机地址
osd heartbeat interval
描述: 一个Ceph OSD守护进程ping它同等的Ceph OSD守护进程的频率（以秒计算）
类型: 32-bit Integer
默认值: 6
osd heartbeat grace
描述: 当一个Ceph OSD守护进程没有初现heartbeat导致Ceph存储集群认为它状态为down经过的时间。
类型: 32-bit Integer
默认值: 20
osd mon heartbeat interval
描述: 如果没有同类的Ceph OSD守护进程，Ceph OSD守护进程pings一个Ceph监视器的频率。
类型: 32-bit Integer
默认值: 30
osd mon report interval max
描述: 在Ceph监视器认为Ceph OSD守护进程状态为down之前，Ceph OSD守护进程报告给一个Ceph监视器的最大秒数。
类型: 32-bit Integer
默认值：120
osd mon report interval min
描述: 为了阻止Ceph监视器认为Ceph OSD守护进程状态为down之，Ceph OSD守护进程报告给一个Ceph监视器的最小秒数。
类型: 32-bit Integer
默认值: 5
有效范围 ：应该比 osd mon report interval max少
osd mon ack timeout
描述: Ceph监视器为了知道一个静态的请求的等待时间的秒数
类型: 32-bit Integer
默认值: 30
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：901327次
积分：16866
积分：16866
排名：第561名
原创：742篇
转载：522篇
评论：105条
(2)(2)(5)(1)(2)(4)(5)(5)(2)(2)(2)(2)(3)(1)(7)(8)(7)(11)(37)(14)(25)(35)(32)(79)(52)(74)(91)(39)(9)(26)(19)(35)(22)(15)(14)(574)尝试使用OpenStack重启虚拟机无效 尝试直接用rbd命令直接删除块失败
[root@controller ~]# rbd -p volumes rm volume-c55fd052-212d-4107-a2ac-cf53bfc049be
05:31:31.f5fb82f7760
0 client.4781741.objecter
FULL, paused modify 0xe9a9e0 tid 6
查看ceph健康状态
cluster 059f27e8-a23f-e
health HEALTH_ERR 20 pgs backfill_ 20 20 recovery
objects degraded (5.796%); 2 full osd(s); 1 near full osd(s)
monmap e6: 4 mons at {node-=10.10.20.40:6789/0,node-=10.10.20.31:6789/0,node-=10.10.20.36:6789/0,node-=10.10.20.41:6789/0}, election epoch 886, quorum 0,1,2,3 node-,node-,node-,node-
osdmap e2743: 3 osds: 3 up, 3 in
flags full
pgmap v0 pgs, 4 pools, 262 GB data, 43027 objects
786 GB used, 47785 MB / 833 GB avail
objects degraded (5.796%)
300 active+clean
20 active+degraded+remapped+backfill_toofull
HEALTH_ERR 20 pgs backfill_ 20 20 recovery
objects degraded (5.796%); 2 full osd(s); 1 near full osd(s)
pg 3.8 is stuck unclean for 691, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.7d is stuck unclean for 139, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.21 is stuck unclean for 848, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.22 is stuck unclean for 397, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.a is stuck unclean for 562, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.7f is stuck unclean for 746, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.5 is stuck unclean for 629, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.1e is stuck unclean for 281, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.19 is stuck unclean for 269, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.5d is stuck unclean for 949, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.1a is stuck unclean for 544, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.1b is stuck unclean for 385, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.3 is stuck unclean for 514, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.15 is stuck unclean for 483, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.11 is stuck unclean for 408, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.6d is stuck unclean for 454, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.6e is stuck unclean for 576, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.c is stuck unclean for 331, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.e is stuck unclean for 953, current state active+degraded+remapped+backfill_toofull, last acting [2,0]
pg 3.20 is stuck unclean for 849, current state active+degraded+remapped+backfill_toofull, last acting [0,2]
pg 3.7d is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.7f is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.6d is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.6e is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.5d is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.20 is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.21 is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.22 is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.1e is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.19 is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.1a is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.1b is active+degraded+remapped+backfill_toofull, acting [0,2]
pg 3.15 is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.11 is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.c is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.e is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.8 is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.a is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.5 is active+degraded+remapped+backfill_toofull, acting [2,0]
pg 3.3 is active+degraded+remapped+backfill_toofull, acting [2,0]
objects degraded (5.796%)
osd.0 is full at 95%
osd.2 is full at 95%
osd.1 is near full at 93%
解决方案一(已验证)
增加OSD节点，这也是官方文档中推荐的做法，增加新的节点后，Ceph开始重新平衡数据，OSD使用空间开始下降
06:51:58.623262 osd.1 [WRN] OSD near full (91%)
06:52:01.500813 osd.2 [WRN] OSD near full (92%)
解决方案二(理论上，没有进行验证)
如果在没有新的硬盘的情况下，只能采用另外一种方式。在当前状态下，Ceph不允许任何的读写操作，所以此时任何的Ceph命令都不好使，解决的方案就是尝试降低Ceph对于full的比例定义，我们从上面的日志中可以看到Ceph的full的比例为95%，我们需要做的就是提高full的比例，之后尽快尝试删除数据，将比例下降。
尝试直接用命令设置，但是失败了，Ceph集群并没有重新同步数据，怀疑可能仍然需要重启服务本身
ceph mon tell * injectargs '--mon-osd-full-ratio 0.98'
修改配置文件，之后重启monitor服务，但是担心出问题，所以没有敢尝试该方法，后续经过在邮件列表确认，该方法应该不会对数据产生影响，但是前提是在恢复期间，所有的虚拟机不要向Ceph再写入任何数据。
默认情况下full的比例是95%，而near full的比例是85%，所以需要根据实际情况对该配置进行调整。
mon osd full ratio = .98
mon osd nearfull ratio = .80
根据Ceph官方文档中的描述，当一个OSD full比例达到95%时，集群将不接受任何Ceph Client端的读写数据的请求。所以导致虚拟机在重启时，无法启动的情况。
从官方的推荐来看，应该比较支持添加新的OSD的方式，当然临时的提高比例是一个解决方案，但是并不推荐，因为需要手动的删除数据去解决，而且一旦再有一个新的节点出现故障，仍然会出现比例变满的状况，所以解决之道最好是扩容。
在这次故障过程中，有两点是值得思考的：
监控：由于当时服务器在配置过程中DNS配置错误，导致监控邮件无法正常发出，从而没有收到Ceph WARN的提示信息 云平台本身： 由于Ceph的机制，在OpenStack平台中分配中，大多时候是超分的，从用户角度看，拷贝大量数据的行为并没有不妥之处，但是由于云平台并没有相应的预警机制，导致了该问题的发生
/docs/master/rados/configuration/mon-config-ref/#storage-capacity
延伸阅读：
目前生产环境的es版本是1 0版本，需要升级到最新的2...
本教程为 李华明 编著的iOS-Cocos2d游戏开发系列教程：教程涵盖关于i......
专题主要学习DirectX的初级编程入门学习，对Directx11的入门及初学者有......
&面向对象的JavaScript&这一说法多少有些冗余，因为JavaScript 语言本......
Windows7系统专题 无论是升级操作系统、资料备份、加强资料的安全及管......ubuntu 16.04安装ceph集群（双节点） - 波神 - 博客园
随笔 - 197
Ceph是一个分布式存储，可以提供对象存储、块存储和文件存储，其中对象存储和块存储可以很好地和各大云平台集成。一个Ceph集群中有Monitor节点、MDS节点（可选，用于文件存储）、至少两个OSD守护进程。Ceph OSD：OSD守护进程，用于存储数据、处理数据拷贝、恢复、回滚、均衡，并通过心跳程序向Monitor提供部分监控信息。一个Ceph集群中至少需要两个OSD守护进程。Monitor：维护集群的状态映射信息，包括monitor、OSD、Placement Group（PG）。还维护了Monitor、OSD和PG的状态改变历史信息。MDS：存储Ceph文件系统的元数据。
一、准备两台机器
10.111.131.125 ceph01
10.111.131.126 ceph02
ceph01将作为admin、osd1
ceph02将作为osd2、mon2
二、设置两台主机ssh免密码访问
1、在ceph01电脑上执行
ssh-keygen
//一直按回车即可,产生公钥私钥对
2、将ceph01产生的公钥复制到ceph01和ceph02上，这样可以使用ceph01无密码登录ceph01和ceph02
ssh-copy-id -i /root/.ssh/id_rsa.pub ceph01
ssh-copy-id -i /root/.ssh/id_rsa.pub ceph02
ssh ceph01
ssh ceph02
发现登录时不用输入密码就算设置成功。
三、在ceph01上安装ceph-deploy
apt-get install ceph-deploy
四、在ceph01上创建集群目录
mkdir my-cluster
cd my-cluster
五、创建集群，会在当前目录下看到ceph.conf ceph.log ceph.mon.keyring三个文件
在ceph01上执行：
ceph-deploy new ceph01
执行以上命令后，ceph01相当于监控节点。如果要把两台都作为监控节点则：
ceph-deploy new ceph01 ceph02
vim ceph.conf并将以下配置追加到后面
osd pool default size = 2
六、分别在ceph01和ceph02上安装ceph
在ceph01上执行以下命令：
ceph-deploy install ceph01 ceph02
执行以上命令，相当于在两台电脑上都运行了：apt-get&install -y ceph，如果上面的命令失败，也可以用apt-get去每台机子上安装ceph
七、初始化集群监控
在ceph01上执行：
ceph-deploy mon create-initial
八、收集秘钥，目录下会多出ceph.bootstrap-mds.keyring &ceph.client.admin.keyring &ceph.client.admin.keyring这几个文件
ceph-deploy gatherkeys ceph01
九、准备2块硬盘并准备osd
分别在ceph01和ceph02上执行：
mkfs.xfs /dev/sdb1
在ceph01上执行：
ceph-deploy osd prepare
ceph01:/dev/sdb1 ceph02:/dev/sdb1
在ceph01上执行：
ceph-deploy osd activate
ceph01:/dev/sdb1 ceph02:/dev/sdb1
上面两条命令执行后，/dev/sdb1会mount到/var/lib/ceph/osd/ceph-0和/var/lib/ceph/osd/ceph-1上，当重启电脑后该挂载会消失，最好开机挂载，解决办法多样，
本人的方法是在：/etc/rc.loac里面加入：
mount /dev/sdb1 /var/lib/ceph/osd/ceph-<span style="color: #
mount /dev/sdb1 /var/lib/ceph/osd/ceph-<span style="color: #
十、将配置文件和管理密钥复制到管理节点和Ceph节点，下次再使用ceph命令界面时就无需指定集群监视器地址，执行命令时也无需每次都指定ceph.client.admin.keyring
在ceph01节点上执行：
ceph-deploy --overwrite-conf admin ceph01 ceph02
执行以上命令之后,ceph02这台机器的/etc/ceph目录下也会多出ceph.client.admin.keyring这个文件。
十一、在ceph01上建一个元数据服务器(可选)
大多数情况下都是使用ceph的块设备，一般来说都不用建立mds，只有用到ceph的文件存储的时候才用到
首先执行：
mkdir -p /var/lib/ceph/mds/ceph-ceph01ceph-deploy mds create ceph01
十二、ceph -s &看到ok表示集群状态正常。
&十三、重启集群
service ceph restart -a
如果上面的命令不起作用则对各个节点服务进行重启
1、重启mon节点，mon节点在ceph01上
/etc/init.d/ceph restart mon.ceph01或
systemctl start ceph-mon@ceph01
2、重启osd0节点，osd0在ceph01上
& &/etc/init.d/ceph start osd.0或
& &systemctl start ceph-osd@0
3、重启osd1节点，osd1在ceph02上
ssh ceph02
/etc/init.d/ceph start osd.1或
systemctl start ceph-osd@1