ceph 常见的问题处理

admin · 发表于 2021-7-5 15:59:42

1.  修改 OSD CRUSH weight
1.1  问题描述
部署完成后，集群处于 PG Degraded 状态，经查 ceph health detail，发现 PG 的 acting OSD 只有 [0]，而不是两个。查 osd tree，osd 日志等，看不出明显问题。
1.2  原因分析
我的 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 之间的数据移动，这可能会影响集群的性能，因此在生产环境中使用要小心。你可以参考这篇文章来看数据移动的情况。
2.  修改 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  原因分析
->  查看 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  解决办法
办法一：将 cursh tunables 设置为 optimal
->  从这篇文章中获得线索，这可能和 crush tunables 有关系。它的默认值应该是 legacy，运行下面的命令将其修改为 optimal 后，集群状态回到正常。
1
ceph osd crush tunables optimal
->  继续找原因，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 少一些。
办法二：将 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.
3.  修改 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
4.  将一个 OSD 移出集群
4.1  将该 osd 设置为 out
1
2
[root@ceph1:/home/s1]# ceph osd out osd.1
marked out osd.1.
4.2  集群做 recovery

2017-06-03 01:54:21.596632 mon.0 [INF] osdmap e90: 4 osds: 4 up, 3 in
2017-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
2017-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
2017-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
2017-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
2017-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
2017-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
4.3  完成后，该 osd 的状态还是 up，表示它的服务还在运行。现在将其服务停掉。
1
2
[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
5.  将一个 OSD 加入集群
/dev/sdb1 分区删除
清理磁盘：ceph-deploy disk zap ceph2:/dev/sdb
创建 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
其实将上面第四步和第五步合并在一起，就是替换一个故障磁盘的过程。
6.  在特定 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 上。
6.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
}
6.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
6.3  创建 ssd-pool，其默认的 ruleset 为 0
1
2
3
4
[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
6.4  修改 ssd-pool 的 ruleset 为 ssd-pool 其id 为 1
1
2
3
4
[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
6.5  类似地创建 sata-pool 并设置其 cursh ruleset 为 sata-pool 其id 为 2
1
2
3
4
5
6
[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.6  分别放一个文件进这两个pool
1
2
3
4
5
6
[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
6.7  查看对象所在的 OSD
1
2
3
4
[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-deploy常见运维命令  ###############

# ceph-deploy new [initial-monitor-node(s)]
开始部署一个集群，生成配置文件、keyring、一个日志文件。

# ceph-deploy install [HOST] [HOST…]
在远程主机上安装ceph相关的软件包, --release可以指定版本，默认是firefly。

# ceph-deploy mon create-initial
部署初始monitor成员，即配置文件中mon initial members中的monitors。部署直到它们形成表决团，然后搜集keys，并且在这个过程中报告monitor的状态。

# ceph-deploy mon create [HOST] [HOST…]
显示的部署monitor，如果create后面不跟参数，则默认是mon initial members里的主机。

# ceph-deploy mon add [HOST]
将一个monitor加入到集群之中。

# ceph-deploy mon destroy [HOST]
在主机上完全的移除monitor，它会停止了ceph-mon服务，并且检查是否真的停止了，创建一个归档文件夹mon-remove在/var/lib/ceph目录下。

# ceph-deploy gatherkeys [HOST] [HOST…]
获取提供新节点的验证keys。这些keys会在新的MON/OSD/MD加入的时候使用。

# ceph-deploy disk list [HOST]
列举出远程主机上的磁盘。实际上调用ceph-disk命令来实现功能。

# ceph-deploy disk prepare [HOST:[DISK]]
为OSD准备一个目录、磁盘，它会创建一个GPT分区，用ceph的uuid标记这个分区，创建文件系统，标记该文件系统可以被ceph使用。

# ceph-deploy disk activate [HOST:[DISK]]
激活准备好的OSD分区。它会mount该分区到一个临时的位置，申请OSD ID，重新mount到正确的位置/var/lib/ceph/osd/ceph-{osd id}, 并且会启动ceph-osd。

# ceph-deploy disk zap [HOST:[DISK]]
擦除对应磁盘的分区表和内容。实际上它是调用sgdisk –zap-all来销毁GPT和MBR, 所以磁盘可以被重新分区。

# ceph-deploy osd prepare HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
为osd准备一个目录、磁盘。它会检查是否超过MAX PIDs,读取bootstrap-osd的key或者写一个（如果没有找到的话），然后它会使用ceph-disk的prepare命令来准备磁盘、日志，并且把OSD部署到指定的主机上。

# ceph-deploy osd active HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
激活上一步的OSD。实际上它会调用ceph-disk的active命令，这个时候OSD会up and in。

# ceph-deploy osd create HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
上两个命令的综合。

# ceph-deploy osd list HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
列举磁盘分区。

# ceph-deploy admin [HOST] [HOST…]
将client.admin的key push到远程主机。将ceph-admin节点下的client.admin keyring push到远程主机/etc/ceph/下面。

# ceph-deploy push [HOST] [HOST…]
将ceph-admin下的ceph.conf配置文件push到目标主机下的/etc/ceph/目录。 # ceph-deploy pull [HOST]是相反的过程。

# ceph-deploy uninstall [HOST] [HOST…]
从远处主机上卸载ceph软件包。有些包是不会删除的，像librbd1, librados2。

# ceph-deploy purge [HOST] [HOST…]
类似上一条命令，增加了删除data。

# ceph-deploy purgedata [HOST] [HOST…]
删除/var/lib/ceph目录下的数据，它同样也会删除/etc/ceph下的内容。

# ceph-deploy forgetkeys
删除本地目录下的所有验证keyring, 包括client.admin, monitor, bootstrap系列。

# ceph-deploy pkg –install/–remove [PKGs] [HOST] [HOST…]
在远程主机上安装或者卸载软件包。[PKGs]是逗号分隔的软件包名列表。

##########################################################################################
对ceph集群中某个节点ceph-node卸载其上的服务
# stop ceph-all                                           # 停止所有ceph进程
# ceph-deploy uninstall  [{ceph-node}]                   # 卸载所有ceph程序
# ceph-deploy purge [[ceph-node} [{ceph-node}]          # 删除ceph相关的包
# ceph-deploy purgedata {ceph-node} [{ceph-node}]          # 删除ceph相关的包
# ceph-deploy forgetkeys                                  # 删除key

##########################################################################################
ceph安装包介绍：
1.ceph-deploy
ceph的部署软件，通过该软件可以简便部署，这个软件并非整个ceph集群系统中必须的

2.ceph
ceph整个服务集群中的每个节点必须的软件。提供分布式的存储与文件系统服务（osd，mon守护进程）

3.ceph-mds
元数据服务端（mds 守护进程）

4.libcephfs
客户端的编程接口(c语言)

5.python-cephfs
客户端的编程接口(python)

6.ceph-common,ceph-fs-common 客户端:
使用ceph服务的客户端必须要有的

############################################
下面这三种进程分布于集群中的服务器上，服务器中可以只运行一种，也可以多个同时运行，推荐为一个服务器运行一种，使得负载均衡：
osd 守护进程：即为存储守护进程
mon 守护进程：监视器守护进程
mds 守护进程：元数据守护进程
###############  ceph-deploy部署ceph集群的简单流程  ###############

架构说明：
node1：admin-node，mon，mgr，osd
node2：osd
node3：osd

server：  3台虚拟机，挂载卷/dev/vdb 10G
系统： centos7.2
ceph版本：luminous

一、准备工作
####################################################################################
1、安装centos、epel repo
使用阿里云mirros，https://opsx.alibaba.com/mirror
# mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
# curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
# mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup
# mv /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel-testing.repo.backup
# curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

2、安装ceph repo
# yum install centos-release-ceph-luminous -y

3、安装ceph-deploy
# yum update -y
# yum installl ceph-deploy -y

4、安装、配置ntp
# yum install ntp ntpdate ntp-doc -y

5、安装ssh（系统自带请忽略或升级）
确认所有节点的ssh server 运行
# yum install openssh-server -y

6、用户设置
使用root用户，虽然官方不推荐这样。配置管理节点到其他server免密登录
生成秘钥对
# ssh-keygen -t rsa
将管理节点公钥注入到其他server
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@xx.xx.xx.xx

7、确保networking 启动
8、配置hosts，将ip hostname 写入/etc/hosts
9、关闭iptables
10、关闭selinux
11、安装yum-plugin-priorities
# yum install yum-plugin-priorities -y

二、部署集群
####################################################################################
在管理节点使用ceph-deploy部署ceph cluster

创建部署目录
# mkdir ~/my-cluster
# cd ~/my-cluster

从头开始（非第一次部署ceph，清理环境）
# ceph-deploy purge {ceph-node}[{ceph-node}]
# ceph-deploy purgedata {ceph-node}[{ceph-node}]
# ceph-deploy forgetkeys
# rm ceph.*

创建集群
创建monitor节点，命令是"ceph-deploy new {initial-monitor-node(s)}"
# ceph-deploy new node1

安装ceph包到各个节点
# ceph-deploy install node1 node2 node3

初始化monitor节点，获取keys
# ceph-deploy mon create-initial

上述命令执行成功后，你会在当前目录下得到以下keyring文件
# ceph.client.admin.keyring
# ceph.bootstrap-mgr.keyring
# ceph.bootstrap-osd.keyring
# ceph.bootstrap-mds.keyring
# ceph.bootstrap-rgw.keyring
# ceph.bootstrap-rbd.keyring

将keyring文件分发到各个节点
# ceph-deploy admin node1 node2 node3

部署manager（l版本之上才需要）
# ceph-deploy mgr create node1

部署osd节点（这里使用虚拟机，挂载了/dev/vdb卷）
# ceph-deploy osd create node1:/dev/vdb node2:/dev/vdb node3:/dev/vdb

检查集群，在管理节点执行
# ceph health
# ceph -s

三、扩展集群
####################################################################################
node1 扩展了metadata，（rgw）
node2 扩展了metadata，monitor
node3 扩展了metadata，monitor

添加metadate server
# ceph-deploy mds create node1

添加monitors
# ceph-deploy mon add node2 node3

添加新的monitor节点之后，ceph会同步monitor，选举代表quorum
查看quorum状态
# ceph quorum_status --format json-pretty

添加managers
manager使用active/standby模式，多节点部署，可以在master down时，无缝顶替
# ceph-deploy mgr create node2 node3

添加rgw实例
为了使用ceph object gateway，需要部署rgw实例
# ceph-deploy rgw create node1

rgw默认监听端口是7480，可以通过编辑ceph.conf修改端口
[client]
rgw frontends = civetweb port=80

四、存储、检索对象数据
####################################################################################
为了存储对象数据，ceph client需要具备：
1. 设置一个对象名
2. 指定一个pool

ceph client 检索最近的集群map和CRUSH算法去计算怎样映射对象到PG，然后计算如何动态映射PG到OSD，
只需要对象name和pool name即可找到对象的位置。命令为"ceph osd map {poolname}{object-name}"

练习：定位对象
创建一个对象，测试文件
# echo {Test-data}> testfiles.txt
# ceph osd pool create mytest 8

使用rados put 命令指定对象名，含有对象数据的测试文件，pool name。命令格式"rados put {object-name} {file-path} --pool=mytest"
# rados put test-object-1 testfile.txt --pool=mytest

验证ceph集群已经存储了此object
# rados -p mytest ls

找到对象位置。命令格式"ceph osd map {pool-name} {object-name}"
# ceph osd map mytest test-oobject-1

ceph会输出对象位置
# osdmap e537 pool 'mytest'(1) object 'test-object-1'-> pg 1.d1743484(1.4)-> up [1,0] acting [1,0]

删除测试对象object
# rados rm test-object-1--pool-mytest

删除mytest pool
# ceph osd pool rm mytest

随着集群的发展，对象位置可能会动态变化。Ceph的动态重新平衡的一个好处是，Ceph可以让您不必手动执行数据迁移或平衡。

五、如果虚拟机没有硬盘，可使用裸设备模拟
####################################################################################
安装lvm
# yum install lvm2 -y

创建虚拟磁盘
# mkdir /ceph && dd if=/dev/zero of=/ceph/ceph-volumes.img bs=1M count=10240 oflag=direct
# sgdisk -g --clear /ceph/ceph-volumes.img
# vgcreate ceph-volumes $(losetup --show -f /ceph/ceph-volumes.img)
# lvcreate -L 9G -n ceph1 ceph-volumes
# mkfs.xfs -f /dev/ceph-volumes/ceph1

挂载
# mkdir -p /var/local/osd1
# chown ceph:ceph /var/local/osd1 #修改属主属组，不然在添加osd时候会报权限错误
# mount /dev/ceph-volumes/ceph1 /var/local/osd1
###############  Ceph添加OSD节点 (非ceph-deploy方法)  ###############

1. 首先需要在新的节点（ceph5，ip为172.16.60.15）上安装ceph软件。
需要先做一系列的准备工作，如：配置ntp，做好管理节点到新增osd节点的ssh无密码信任关系。

在管理节点上执行：
[root@ceph-admin ~]# ceph-deploy install --no-adjust-repos ceph5

2. 获取osd的ID
这个操作是在管理节点上执行
[root@ceph-admin ~]# ceph osd create       #记录得到的编号，如下编号0就是下面创建的osd的ID。
0

3. 编辑配置文件，这个文件是在管理节点上的，为了安全也可以同步到别的节点上保存
[root@ceph-admin ~]# vim /etc/ceph/ceph.conf
添加 [osd.0]  public addr = 172.16.60.15

4. 同步配置文档到节点ceph5，这个操作在管理节点上执行（172.16.60.10是ceph管理节点地址）
[root@ceph-admin ~]# scp -r root@172.16.60.10:/etc/ceph/ root@172.16.60.15:/etc/

5. 部署osd节点
登陆到ceph5或者ssh到ceph5机器上都可以
[root@ceph-admin ~]# ssh root@192.168.100.103

6. 对磁盘做处理
[root@ceph5 ~]# parted /dev/sdb mktable gpt
[root@ceph5 ~]# parted /dev/sdb mkpart osd.0 1 20g    #新加的硬盘为20g，并将所有空间划分为一个分区

7. 格式化和挂载,ceph5机器上的磁盘
[root@ceph5 ~]# mkfs -t xfs /dev/sdb1
[root@ceph5 ~]# mkdir -p /data/osd.0
[root@ceph5 ~]# mkdir -p /var/lib/ceph/osd/ceph-0
[root@ceph5 ~]# mount /dev/sdb1 /data/osd.1

8. 安装新osd的相关，初始化 OSD 数据目录
[root@ceph5 ~]# ceph-osd -i 0 --mkfs --mkkey          #这里的"0就是osd是的编号，即上面"ceph osd create"输出的数字

9. 注册此 OSD 的密钥
[root@ceph5 ~]# ceph auth add osd.1 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-0/keyring

10. 把此 OSD 加入 CRUSH 图之后，它就能接收数据了
[root@ceph5 ~]# ceph osd crush add osd.0 0.2 root=default host=ceph5

11. 启动osd进程
[root@ceph5 ~]# ceph-osd -i 0

12. 查看进程
[root@ceph5 ceph-0]# ps -ef|grep ceph-osd
root    3238    1 21 10:54 ?       00:00:01 ceph-osd -i 0
root    3369 2654  0 10:54 pts/0 00:00:00 grep --color=auto ceph-osd

13. 查看osd状态
[root@ceph5 ceph-0]# ceph osd stat  osd添加成功
[root@ceph5 ceph-0]# ceph osd stat
   osdmap e175: 6 osds: 5 up, 5 in
         flags sortbitwise,require_jewel_osds
############### Ceph删除osd的正确方式 ###############

在ceph的集群当中关于节点的删除问题，一直按照以前的方式进行的处理，处理的步骤如下：

1. 停止osd进程
# /etc/init.d/ceph stop osd.0
这一步是停止osd的进程，让其他的osd知道这个节点不提供服务了

2. 将节点状态标记为out
# ceph osd out osd.0
这个一步是告诉mon，这个节点已经不能服务了，需要在其他的osd上进行数据的恢复了

3. 从crush中移除节点
# ceph osd crush remove osd.0
从crush中删除是告诉集群这个点回不来了，完全从集群的分布当中剔除掉，让集群的crush进行一次重新计算，之前节点还占着这个crush weight，
会影响到当前主机的host crush weight

4. 删除节点
# ceph osd rm osd.0
这个是从集群里面删除这个节点的记录

5. 删除节点认证（不删除编号会占住）
# ceph auth del osd.0
这个是从认证当中去删除这个节点的信息

================================================================================================================
这个一直是处理故障节点osd的方式，其实这个会触发两次迁移：一次是在节点osd out以后，一个是在crush remove以后。
两次迁移对于ceph集群来说是不好的，其实可以调整步骤是可以避免二次迁移的，做法如下新的处理方式。
================================================================================================================

################# 对于osd故障节点删除的新的处理方式（推荐）##########################
1. 调整osd的crush weight
# ceph osd crush reweight osd.0 0.1
说明：这个地方如果想慢慢的调整就分几次将crush 的weight 减低到0 ，这个过程实际上是让数据不分布在这个节点上，让数据慢慢的分布到其他节点上，
直到最终为没有分布在这个osd，并且迁移完成这个地方不光调整了osd 的crush weight ，实际上同时调整了host 的 weight ，这样会调整集群的整体的crush 分布，
在osd 的crush 为0 后，再对这个osd的任何删除相关操作都不会影响到集群的数据的分布

2. 停止osd进程
# /etc/init.d/ceph stop osd.0
停止到osd的进程，这个是通知集群这个osd进程不在了，不提供服务了，因为本身没权重，就不会影响到整体的分布，也就没有迁移。

3. 将节点状态标记为out
# ceph osd out osd.0
停止到osd的进程，这个是通知集群这个osd不再映射数据了，不提供服务了，因为本身没权重，就不会影响到整体的分布，也就没有迁移

4. 从crush中移除节点
# ceph osd crush remove osd.0
这个是从crush中删除，因为已经是0了所以没影响主机的权重，也就没有迁移了

5. 删除节点
# ceph osd rm osd.0
这个是从集群里面删除这个节点的记录

6. 删除节点认证（不删除编号会占住）
# ceph auth del osd.0
这个是从认证当中去删除这个节点的信息

经过验证，第二种方式只触发了一次迁移，虽然只是一个步骤先后上的调整，对于生产环境的的集群来说，迁移的量要少了一次，实际生产环境当中节点是有自动out的功能，
这个可以考虑自己去控制，只是监控的密度需要加大，毕竟这个是一个需要监控的集群，完全让其自己处理数据的迁移是不可能的，带来的故障只会更多。
############### Ceph替换OSD操作的优化与分析 ###############

上面介绍了"删除OSD的正确方式"，在上面只是简单的说了下删除的方式怎样能减少迁移量。下面要说的属于一个扩展，介绍了Ceph运维当中经常出现的"坏盘替换盘的步骤及优化"。

基础环境：
两台主机，每台主机8个OSD，一共16个OSD，副本设置为2，PG 数设置为800，计算下来平均每个OSD上的PG数目为100个，下面将通过数据来分析不同的处理方法的差别！

需要注意：
开始测试前，先把环境设置为 noout，然后通过停止OSD来模拟OSD出现了异常，之后进行下面三种不同的处理方法：

一、测试方法1：首先out一个OSD，然后剔除OSD，然后增加OSD
#########################################################################################################
总的思路：
1. 停止指定OSD进程
2. out指定OSD
3. crush remove指定OSD
4. 增加一个新的OSD

一般生产环境会设置为noout，当然不设置也可以，那就交给程序去控制节点的 out，默认是在进程停止后的五分钟，总之这个地方如果有 out 触发，
不管是人为触发，还是自动触发，数据流是一定的。这里为了便于测试，使用的是人为触发，上面提到的预制环境就是设置的noout。

开始测试前获取最原始的分布
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg1.txt
获取当前的 PG 分布,保存到文件pg1.txt，这个 PG 分布记录是 PG 所在的 OSD，记录下来，方便后面进行比较，从而得出需要迁移的数。

1. 停止指定的OSD进程
[root@ceph1106 ~]# systemctl stop ceph-osd@15
停止进程并不会触发迁移，只会引起 PG 状态的变化，比如原来主 PG 在停止的 OSD 上，那么停止掉 OSD 以后，原来的副本的那个 PG 就会角色升级为主 PG 了

2. out掉一个OSD
[root@ceph1106 ~]# ceph osd out 15
在触发out以前，当前的PG状态应该有active+undersized+degraded, 触发 out 以后，所有的 PG 的状态应该会慢慢变成 active+clean,等待集群正常后，
再次查询当前的 PG 分布状态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg2.txt
保存当前的 PG 分布为pg2.txt

比较 out 前后的 PG 的变化情况，下面是比较具体的变化情况，只列出变化的部分
[root@ceph1106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines

这里比较关心的是变动的数目，只统计变动的 PG 的数目
[root@ceph1106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines|wc -l
102

第一次 out 以后有102个 PG 的变动,这个数字记住，后面的统计会用到

3. 从crush里面删除OSD
[root@ceph1106 ~]# ceph osd crush remove osd.15
crush 删除以后同样会触发迁移，等待 PG 的均衡，也就是全部变成 active+clean 状态

[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg3.txt
获取当前的 PG 分布的状态

现在来比较 crush remove 前后的 PG 变动
[root@ceph1106 ~]# diff -y -W 100 pg2.txt pg3.txt  --suppress-common-lines|wc -l
137

重新加上新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

加完以后统计当前的新的 PG 状态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg4.txt

比较前后的变化
[root@ceph1106 ~]# diff -y -W 100 pg3.txt pg4.txt  --suppress-common-lines|wc -l
167

整个替换流程完毕，统计上面的 PG 总的变动
102 +137 +167 = 406
也就是按这个方法的变动为406个 PG，因为是只有双主机，里面可能存在某些放大问题，这里不做深入讨论，因为这里三组测试环境都是一样的情况，
只做横向比较，原理相通，这里是用数据来分析出差别。

二、测试方法2：先crush reweight 0 ，然后out，然后再增加osd
#########################################################################################################
首先恢复环境为测试前的环境
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg1.txt
记录最原始的 PG 分布情况

1. crush reweight 指定OSD
[root@ceph1106 ~]# ceph osd crush reweight osd.16 0
reweighted item id 16 name 'osd.16' to 0 in crush map

等待平衡了以后记录当前的 PG 分布状态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg2.txt
dumped pgs in format plain

比较前后的变动
[root@ceph1106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt  --suppress-common-lines|wc -l
166

2. crush remove 指定 OSD
[root@ceph1106 ~]# ceph osd crush remove osd.16
removed item id 16 name 'osd.16' from crush map

这个地方因为上面crush 已经是0了，所以删除也不会引起 PG 变动，然后直接 ceph osd rm osd.16 同样没有 PG 变动

3. 增加新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

等待平衡以后获取当前的 PG 分布
[root@ceph1106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg3.txt

来比较前后的变化
[root@ceph1106 ~]# diff -y -W 100 2pg2.txt 2pg3.txt --suppress-common-lines|wc -l
159

总的 PG 变动为
166+159=325

三、测试方法3：开始做norebalance，然后做crush remove，然后做add
#########################################################################################################
恢复环境为初始环境，然后获取当前的 PG 分布
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg1.txt
dumped pgs in format plain

1. 给集群做多种标记，防止迁移
设置为 norebalance，nobackfill，norecover,后面是有地方会解除这些设置的
[root@ceph1106 ~]# ceph osd set norebalance
set norebalance

[root@ceph1106 ~]# ceph osd set nobackfill
set nobackfill

[root@ceph1106 ~]# ceph osd set norecover
set norecover

2. crush reweight 指定 OSD
[root@ceph1106 ~]# ceph osd crush reweight osd.15 0
reweighted item id 15 name 'osd.15' to 0 in crush map

这个地方因为已经做了上面的标记，所以只会出现状态变化，而没有真正的迁移，我们也先统计一下
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg2.txt
[root@ceph1106 ~]# diff -y -W 100 3pg1.txt 3pg2.txt --suppress-common-lines|wc -l
158

注意这里只是计算了，并没有真正的数据变动，可以通过监控两台的主机的网络流量来判断,所以这里的变动并不用计算到需要迁移的 PG 数目当中。

3. crush remove 指定 OSD
[root@ceph1106 ~]# ceph osd crush remove osd.15

4. 删除指定的 OSD
删除以后同样是没有 PG 的变动的
[root@ceph1106 ~]# ceph osd rm osd.15

这里有个小地方需要注意一下：
不做 ceph auth del osd.15 把15的编号留着，这样好判断前后的 PG 的变化，不然相同的编号，就无法判断是不是做了迁移了。

5. 增加新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

这里测试环境下，新增的 OSD 的编号为16了

6. 解除各种标记
放开上面的设置，看下数据的变动情况
[root@ceph1106 ceph]# ceph osd unset norebalance
unset norebalance

[root@ceph1106 ceph]# ceph osd unset nobackfill
unset nobackfill

[root@ceph1106 ceph]# ceph osd unset norecover
unset norecover

设置完了后数据才真正开始变动了，可以通过观察网卡流量看到，来看下最终pg变化
[root@ceph1106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg3.txt
dumped pgs in format plain

[root@ceph1106 ~]# diff -y -W 100 3pg1.txt 3pg3.txt --suppress-common-lines|wc -l
195

这里只需要跟最开始的PG分布状况进行比较就可以了，因为中间的状态实际上都没有做数据的迁移，所以不需要统计进去，可以看到这个地方动了195个PG，
总共的 PG 迁移量为195

四、数据汇总
#########################################################################################################
#########################################################################################################
现在通过表格来对比下三种方法的迁移量的比较 (括号内为迁移 PG 数目)

                  方法1                      方法2                         方式3
                  stop osd (0)             crush reweight osd (166)       set 标记 (0)
                  out osd (102)             out osd (0)                   crush reweight osd (0)
所做操作             crush remove osd (137)    crush remove osd (0)          crush remove osd (0)
                  add osd (167)             add osd (159)                add osd (195)

PG迁移数量          406                      325                            195

可以很清楚的看到三种不同的方法，最终的触发的迁移量是不同的，处理的好的话，能节约差不多一半的迁移的数据量，
这个对于生产环境来说还是很好的，关于这个建议先在测试环境上进行测试，然后再操作，上面的操作只要不对磁盘进行格式化，
操作都是可逆的，也就是可以比较放心的做，记住所做的操作，每一步都做完都去检查 PG 的状态是否是正常的

最后总结
从以往操作经验来看，最开始是用的第一种方法，后面就用第二种方法减少了一部分迁移量，网上有资料说做剔除OSD的时候可以关闭迁移，防止无效的过多的迁移，
然后就测试了一下，确实能够减少不少的迁移量，这个减少在某些场景下还是很好的，当然如果不太熟悉，用哪一种都可以，最终能达到的目的是一样的。
############### Ceph的节点问题 ###############

ceph的整体读写性能下降，经查看ceph osd perf有一块osd延迟较大在200多ms以上，决定剔除后，整体性能恢复。
这就说明osd的一个节点问题有时会影响整体ceph的性能。
[root@ceph-admin ~]# ceph --admin-daemon /var/run/ceph/ceph-osd.105.asok perf dump | more
"WBThrottle": {
"bytes_dirtied": 13333504,
"bytes_wb": 0,
"ios_dirtied": 86,
"ios_wb": 0,
"inodes_dirtied": 27,
"inodes_wb": 0
},

整体都应该是0

可以结合MegaCli查看是否有坏道导致的问题，不要急于恢复磁盘。
长时间的数据积累对磁盘的性能和使用周期是有影响的也可以定时清理磁盘碎片。

查看磁盘碎片
[root@ceph-admin ~]# xfs_db -c frag -r /dev/sdd1

整理碎片
[root@ceph-admin ~]# xfs_fsr /dev/sdd1

		自动登录	找回密码
密码			注册

ceph 常见的问题处理

浏览过的版块