注意

本文档适用于 Ceph 开发版本。

BlueStore 迁移

警告

在Reef版本中，Filestore已被弃用，不再提供支持。请迁移到BlueStore。

每个OSD必须格式化为Filestore或BlueStore。但是，Ceph集群可以混合使用Filestore OSD和BlueStore OSD运行。由于BlueStore在性能和鲁棒性方面优于Filestore，并且从Reef开始，Ceph版本不再支持Filestore，因此部署Filestore OSD的用户应过渡到BlueStore。有几种策略可以实现在BlueStore的过渡。

BlueStore与Filestore如此不同，以至于单个OSD无法就地转换。相反，转换过程必须使用（1）集群的正常复制和修复支持，或（2）工具和策略，这些工具和策略将OSD内容从旧设备（Filestore）复制到新设备（BlueStore）。

使用BlueStore部署新的OSD

部署新OSD时使用BlueStore（例如，当集群扩展时）。因为这是默认行为，所以不需要任何特定更改。

类似地，对于在替换故障驱动器后重新配置的任何OSD，也使用BlueStore。

转换现有的OSD

“标记-替换”`out`” replacement

最简单的方法是验证集群是健康的，然后依次对每个Filestore OSD执行以下步骤：标记OSD，等待数据在集群中复制，重新配置OSD，标记OSD回，并等待恢复完成后再继续下一个OSD。这种方法易于自动化，但它涉及不必要的数据迁移，这会带来时间和SSD磨损的成本。out, wait for the data to replicate across the cluster, reprovision the OSD, mark the OSD back in, and wait for recovery to complete before proceeding to the next OSD. This approach is easy to automate, but it entails unnecessary data migration that carries costs in time and SSD wear.

确定要替换的Filestore OSD：

ID=<osd-id-number>
DEVICE=<disk-device>

确定给定的OSD是Filestore还是BlueStore：

ceph osd metadata $ID | grep osd_objectstore

获取Filestore和BlueStore OSD的当前计数：
```
ceph osd count-metadata osd_objectstore
```

标记Filestore OSDout:
```
ceph osd out $ID
```

等待数据从该OSD迁移出去：

while ! ceph osd safe-to-destroy $ID ; do sleep 60 ; done

停止 OSD：
```
systemctl kill ceph-osd@$ID
```

注意OSD正在使用的设备：

mount | grep /var/lib/ceph/osd/ceph-$ID

卸载OSD：
```
umount /var/lib/ceph/osd/ceph-$ID
```
销毁OSD的数据。请非常小心！这些命令将销毁设备的所有内容；你必须确保设备上的数据不再需要（换句话说，集群是健康的）才能继续：
```
ceph-volume lvm zap $DEVICE
```
告诉集群OSD已被销毁（并且可以使用相同的OSD ID重新配置新的OSD）：
```
ceph osd destroy $ID --yes-i-really-mean-it
```
使用相同的OSD ID就地重新配置BlueStore OSD。这需要你识别要擦除的设备，并确保你针对正确的预期设备，使用在“注意OSD正在使用的设备”步骤中检索到的信息。小心！请注意，在处理混合OSD时，您可能需要修改这些命令：“Note which device the OSD is using” step. BE CAREFUL! Note that you may need to modify these commands when dealing with hybrid OSDs:
```
ceph-volume lvm create --bluestore --data $DEVICE --osd-id $ID
```
重复。

您可以选择（1）让替换的BlueStore OSD的平衡与下一个Filestore OSD的排空同时进行，或者（2）对多个OSD并行执行相同的程序。在任何情况下，您都必须确保集群完全干净（换句话说，所有数据都有所有副本），然后再销毁任何OSD。如果您选择并行重新配置多个OSD，请非常小心仅在单个CRUSH故障域内销毁OSD（例如，host或rack。如果不能满足这一要求，将降低您的数据的冗余性和可用性，并增加数据丢失的风险（甚至可能保证数据丢失）。

优点：

简单。
可以逐设备进行。
不需要备用设备或主机。

缺点：

数据在网络上的复制两次：一次复制到集群中的另一个OSD（以保持指定的副本数量），再次复制到重新配置的BlueStore OSD。

“整个主机”替换

如果您在集群中有一个备用主机，或者有足够的空闲空间将整个主机迁移用作备用，那么转换可以逐主机进行，以便每个数据的存储副本只迁移一次。

要使用这种方法，您需要一个没有配置OSD的空主机。有两种方法可以做到这一点：要么使用一个尚未成为集群一部分的新空主机，要么将数据从已经是集群一部分的主机卸载。

使用新空主机

理想情况下，主机将具有与其他要转换的主机大致相同的容量。将主机添加到CRUSH层次结构，但不要将其连接到根：

NEWHOST=<empty-host-name>
ceph osd crush add-bucket $NEWHOST host

确保在新主机上安装了Ceph软件包。

使用现有主机

如果您想使用已经是集群一部分的现有主机，并且该主机上有足够的空闲空间，以便将其所有数据迁移到其他集群主机，您可以执行以下操作（而不是使用新空主机）：

OLDHOST=<existing-cluster-host-to-offload>
ceph osd crush unlink $OLDHOST default

其中“default”是CRUSH映射中的直接祖先。（对于未修改配置的小型集群，这通常是“default”，但它也可能是机架名称。）现在您应该看到OSD树输出在顶部有主机，但没有父级：

bin/ceph osd tree

ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-5             0 host oldhost
10   ssd 1.00000     osd.10        up  1.00000 1.00000
11   ssd 1.00000     osd.11        up  1.00000 1.00000
12   ssd 1.00000     osd.12        up  1.00000 1.00000
-1       3.00000 root default
-2       3.00000     host foo
 0   ssd 1.00000         osd.0     up  1.00000 1.00000
 1   ssd 1.00000         osd.1     up  1.00000 1.00000
 2   ssd 1.00000         osd.2     up  1.00000 1.00000
...

如果一切看起来都很好，请直接跳转到“等待数据迁移完成”步骤下方，并从那里开始清理旧OSD。

迁移过程

如果您使用新主机，从第一步开始。如果您使用现有主机，跳转到这一步.

为所有设备提供新的BlueStore OSD：

ceph-volume lvm create --bluestore --data /dev/$DEVICE

验证新的OSD已加入集群：

ceph osd tree

您应该看到新的主机$NEWHOST以及其下的所有OSD，但主机应该firefly 发布。Firefly 将延迟至少另一个冲刺，以便我们可以对新代码进行一些操作经验，并进行一些额外的测试，然后再承诺长期支持。嵌套在任何其他节点层次结构下（例如root default）。例如，如果newhost是空主机，您可能会看到类似的内容：

$ bin/ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-5             0 host newhost
10   ssd 1.00000     osd.10        up  1.00000 1.00000
11   ssd 1.00000     osd.11        up  1.00000 1.00000
12   ssd 1.00000     osd.12        up  1.00000 1.00000
-1       3.00000 root default
-2       3.00000     host oldhost1
 0   ssd 1.00000         osd.0     up  1.00000 1.00000
 1   ssd 1.00000         osd.1     up  1.00000 1.00000
 2   ssd 1.00000         osd.2     up  1.00000 1.00000
...

确定第一个要转换的目标主机：

OLDHOST=<existing-cluster-host-to-convert>

将新主机交换到旧主机在集群中的位置：
```
ceph osd crush swap-bucket $NEWHOST $OLDHOST
```
在这一点上，所有数据在$OLDHOST都将开始迁移到$NEWHOST上的OSD。如果旧主机的总容量与新主机的总容量之间存在差异，您也可能看到一些数据迁移到或来自集群中的其他节点。但是，如果主机的大小相似，那么这些数据将是相对较少的。

等待数据迁移完成：

while ! ceph osd safe-to-destroy $(ceph osd ls-tree $OLDHOST); do sleep 60 ; done

停止现在为空的旧OSD：$OLDHOST:

ssh $OLDHOST
systemctl kill ceph-osd.target
umount /var/lib/ceph/osd/ceph-*

销毁并清除旧OSD：

for osd in `ceph osd ls-tree $OLDHOST`; do
   ceph osd purge $osd --yes-i-really-mean-it
done

擦除旧OSD。这需要您手动识别要擦除的设备。小心！对于每个设备：
```
ceph-volume lvm zap $DEVICE
```
使用现在为空的主机作为新主机，并重复：
```
NEWHOST=$OLDHOST
```

优点：

数据在网络上的复制仅一次。
整个主机的OSD一次性转换。
可以并行化，以实现同时转换多个主机。
参与此过程的主机不需要有备用设备。

缺点：

需要一个备用主机。
一次将整个主机的OSD数据迁移。这可能会影响集群的整体性能。
所有迁移的数据仍然在网络上一跳。

每个OSD设备复制

可以使用copy功能（包含在ceph-objectstore-tool中）将单个逻辑OSD转换。这要求主机有一个或多个空闲设备来提供新的空BlueStore OSD。例如，如果您的集群中的每个主机都有12个OSD，那么您需要一个第13个未使用的OSD，以便每个OSD在重新配置之前可以转换，然后才能回收以前的OSD以转换下一个OSD。

注意事项：

这种方法要求我们准备一个空的BlueStore OSD，但我们不给它分配新的OSD ID。工具不支持这种操作。ceph-volume tool does not support such an operation. 重要提示：由于dmcrypt的设置与OSD的身份紧密相关，因此这种方法不适用于加密OSD。
设备必须手动分区。
可以在这里找到一个不支持的演示此过程的用户贡献脚本：https://github.com/ceph/ceph/blob/master/src/script/contrib/ceph-migrate-bluestore.bash

优点：

如果在转换过程中OSD或集群上设置了“noout”或“norecover”/“norebalance”标志，则在转换期间网络上的数据迁移很少或没有。

缺点：

工具尚未完全实现、支持或记录。
每个主机都必须有一个适当的备用或空设备用于暂存。
在转换期间，OSD处于离线状态，这意味着新的写入到包含OSD的PG的执行集中可能不会理想地冗余，直到主题OSD启动并恢复。这增加了由于重叠故障导致数据丢失的风险。但是，如果转换和启动完成之前另一个OSD发生故障，则可以启动原始Filestore OSD以访问其原始数据。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.