更新时间:2022-09-05 16:49:27
本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成:
(1)安装和部署
(3)Ceph 物理和逻辑结构
(4)Ceph 的基础数据结构
(6)QEMU-KVM 和 Ceph RBD 的 缓存机制总结
学以致用,本文将介绍 Ceph 集群的一些基本操作和常见的故障排除方法。
将由 Virtulbox 管理的两个虚机,分别是 ceph1 和 ceph2,作为 OSD 服务器,其中,ceph1 同时作为 MON 服务器。两个节点上分别有两个虚拟磁盘作为 OSD 存储磁盘,每个大小为 5G;还有一个虚拟磁盘作为 Journal 磁盘,1G,分为两个区,做为数据盘的日志分区。从 ceph1 上使用 ceph-deploy 工具部署。pool 的 size 设置为 2,min_size 也设置为 2.
每个机器配置两个网卡,eth0 是 NAT 模式,使用 DHCP 方式获取IP,用于虚机访问外网;eth1 是 host-only 模式,配置静态IP,用于主机访问虚机,以及虚机之间的互访。对Ceph 来说,eth0 用于安装程序,eth1 用于 public 和 cluster network。
注意在宿主机上要设置防火墙允许 Virtualbox 访问外网。我机器上安装了 Symentac Endpoint Protection,不小心 block 了它的互联网访问,然后虚机也就无法连接外网了,我在这里花了不少时间折腾:
部署完成后,集群处于 PG Degraded 状态,经查 ceph health detail,发现 PG 的 acting OSD 只有 [0],而不是两个。查 osd tree,osd 日志等,看不出明显问题。
从文章 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。这篇文章 有详细的分析。简单来说:
因此,问题的症结就在于 osd crush weight 为0。至于为什么会这样,以及该值对 PG 分配的影响,有待进一步查明。
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 之间的数据移动,这可能会影响集群的性能,因此在生产环境中使用要小心。你可以参考 这篇文章 来看数据移动的情况。
将 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
(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)从这篇文章中获得线索,这可能和 crush tunables 有关系。它的默认值应该是 legacy,运行下面的命令将其修改为 optimal 后,集群状态回到正常。
ceph osd crush tunables optimal
(3)继续找原因,Red Hat 这篇文章 给出了一些线索。
在新版本的Ceph 集群中使用 legacy 值可能会有一些问题,包括:
而第一种情况正是我的测试集群所遇到的情况,每个 host 拥有的 OSD 数目在3个以内,然后部分 PG 所在的 OSD 数目较 replica 少一些。
关于 CRUSH tunables 的详细信息,请阅读有关文档。请注意在生产环境操作时有一定的风险。
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.
继续将跟 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 了,但是没完成。
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.
按照以下步骤,将 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 设置为 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)将 /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
其实将上面第四步和第五步合并在一起,就是替换一个故障磁盘的过程。
我们假设 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 磁盘上。
先准备好机器,然后在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
从 这篇文章 中获得线索,需要修改 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。根本原因需要进一步研究。
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。
(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 的压力;增强 OSD 心跳网络的可靠性。
(2)安全性:使用一个彻底与外网分离的内部网络作为 cluster network,可以防止比如 DDOS 这样的网络攻击。
更多信息,请参阅 NETWORK CONFIGURATION REFERENCE。
(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地址被启用了。
编辑在客户端的 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 不起作用。
本文转自SammyLiu博客园博客,原文链接:http://www.cnblogs.com/sammyliu/p/5555218.html,如需转载请自行联系原作者