注意
本文档适用于 Ceph 的开发版本。
BlueStore 迁移
警告
Filestore 已在 Reef 版本中弃用，不再受支持。请迁移到 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”替换
最简单的方法是验证集群是否健康，然后依次执行以下步骤来处理每个 Filestore OSD：标记 OSD out，等待数据在集群中复制，重新配置 OSD，标记 OSD in，并等待恢复完成，然后再继续下一个 OSD。这种方法易于自动化，但涉及不必要的数据迁移，会耗费时间和 SSD 磨损。
确定要替换的 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 OSD
outceph 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 时，您可能需要修改这些命令
ceph-volume lvm create --bluestore --data $DEVICE --osd-id $ID重复。
您可以选择（1）在下一个 Filestore OSD 正在排空的同时进行替换 BlueStore OSD 的平衡，或者（2）并行对多个 OSD 执行相同的过程。然而，无论哪种情况，您都必须确保集群完全干净（换句话说，所有数据都具有所有副本），然后才能销毁任何 OSD。如果您选择并行重新配置多个 OSD，请非常小心地只在单个 CRUSH 故障域（例如 host 或 rack）内销毁 OSD。未能满足此要求将降低数据的冗余度和可用性，并增加数据丢失的风险（甚至保证数据丢失）。
优点
简单。
可以按设备逐个进行。
不需要备用设备或主机。
缺点
数据通过网络复制两次：一次复制到集群中的另一个 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，但该主机不应嵌套在层次结构中的任何其他节点（如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停止现在为空的
$OLDHOST上的所有旧 OSDssh $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 设备复制
可以使用 ceph-objectstore-tool 中包含的 copy 函数来转换单个逻辑 OSD。这要求主机有一个或多个空闲设备来配置新的空 BlueStore OSD。例如，如果集群中的每个主机有十二个 OSD，那么您需要第十三个未使用的 OSD，以便在回收前一个 OSD 转换下一个 OSD 之前，可以转换每个 OSD。
注意事项
此方法要求我们准备一个空的 BlueStore OSD，但不为其分配新的 OSD ID。
ceph-volume工具不支持此类操作。重要提示：由于 dmcrypt 的设置与 OSD 的身份密切相关，因此此方法不适用于加密的 OSD。设备必须手动分区。
此处提供了演示此过程的、用户贡献的、不受支持的脚本：https://github.com/ceph/ceph/blob/master/src/script/contrib/ceph-migrate-bluestore.bash
优点
如果在转换过程中设置了 OSD 或集群上的 'noout' 或 'norecover'/'norebalance' 标志，则在转换过程中几乎没有数据通过网络迁移。
缺点
工具尚未完全实现、支持或记录。
每个主机必须有一个合适的备用或空闲设备用于暂存。
OSD 在转换过程中处于离线状态，这意味着在 OSD 启动并恢复之前，写入具有该 OSD 的 acting set 的 PG 的新写入可能没有理想的冗余度。这增加了由于重叠故障导致数据丢失的风险。但是，如果在转换和启动完成之前另一个 OSD 发生故障，则可以启动原始 Filestore OSD 以提供对其原始数据的访问。