ceph配置中的osd_crush_update_on_start如何在osd重启时影响osd在crush中分布

在自定义crush map的时候，发现掉电的osd，通过service ceph-osd@{osd.id} start重启后 osd回到了默认的host节点下，而不是自己定制后的节点，通过跟踪实现，发现了问题：

osdceph集群的默认配置

下图为我们测试环境中的osd tree，这是我们自己定制的一个osdmap，当然我们希望在osd掉线重启或者主机异常断点重启后所有的osd都能回到他应该在的位置上，但在我们使用ceph-deploy去搭建一个集群的时候这个想法并不能如我们所愿

下面我们停止一个osd，osd.5

接下来我们将这个osd.5重启，再看看osd.5的位置，这时候他回到了osd所在主机的主机名下的原默认位置

我们知道，我们的系统重启后linux都会通过系统服务管理模块来启动我们的服务，下面我们来尝试从linux的系统服务管理--service（systemctl）来找到我们osd重启后加入到主机的hostname位置的原因：

首先我们找到ceph-osd的service配置文件

注意上图中红框中的内容，这个配置决定了osd在启动之前会执行什么样的操作，我们手动的执行试试，现在我们先把osd.5放入到正确的位置：

然后手动执行：/usr/lib/ceph/ceph-osd-prestart.sh --cluster=ceph --id 5

看下图效果：

我们可以发现，osd.5的位置又回到了他的默认位置，我们从官网的手册可以看出，如果我们需要自己管理crush location我们需要设置osd crush update on start = false ，不然的话---“Ceph automatically sets a ceph-osd daemon’s location to be root=default host=HOSTNAME (based on the output from hostname -s)”

http://docs.ceph.com/docs/master/rados/operations/crush-map/#crush-location

我们将此设置放入配置文件

我们将osd.5放到正确位置后，在做尝试：

我们看到配置了osd crush update on start = false，osd的重启确实能够回到他该回的位置。

现在我们来看看ceph怎么实现读取这个配置的，我们查看/usr/lib/ceph/ceph-osd-prestart.sh的实现

我们上图看到脚本是通过ceph-conf去获取osd crush update on start在ceph.conf文件中的配置；如果配置是true，那么则会调用/usr/bin/ceph-crush-location命令获取osd的位置

而ceph-crush-location命令又回调用ceph-conf去到ceph-conf中去寻找crush_location/osd_crush_location字段的值，在没有找到的情况下默认返回"host=$(hostname -s) root=default"导致了我们osd回到了默认位置而不是正确位置。

那么，我们解决这个问题有两种：

1.ceph.conf中加入osd crush update on start = false

2.根据官网设置自定义位置挂钩