注意
本文档适用于 Ceph 的开发版本。
存储设备和 OSD 管理工作流
集群存储设备是安装在集群中每个主机上的物理存储设备。我们需要对它们执行不同的操作，并检索有关物理特性和工作行为的信息。我们在该领域的基本用例包括
1. 检索设备信息。清点
我们必须能够查看集群存储设备的当前状态和状况。我们需要详细的标识和特性（包括识别/故障指示灯开/关功能），以及设备是否用作 OSD/DB/WAL 设备。
每个设备所需的信息至少包括
Hostname Path Type Serial Size Health Ident Fault Available
为了了解设备的当前状况，我们需要知道已使用的存储量、可用空间的百分比、平均 IOPS 数量以及故障指示灯状态。此信息应由 Ceph 协调器提供，因为它是我们可以访问此类信息的组件。
围绕检索设备信息的另一个重要问题是“效率”。有关设备的信息对于协调器或仪表板等组件至关重要，因为此信息通常用于做出决策。当我们谈论效率时，我们需要确保涵盖所有要点
以最快的方式获取每个设备的完整信息。
始终可以立即访问一个主机中所有设备的所有信息。
信息在每个主机中不断更新。必须在尽可能短的时间内检测到设备故障或新设备的添加
可扩展性。处理数百个主机中的数千个设备不应成为问题。
A. 当前工作流：
- 命令行界面（CLI）:
操作
ceph orch device ls
ceph orch device ls json ( to get all the fields for each device )
Problems in current implementation:
* Does not scale.
- 图形用户界面（GUI）:
- 操作
- cluster.Inventory 部分
cluster.Inventory 部分显示了集群中设备的基本列表。它是一个固定列表，只有几个字段。只有“ident light on”操作是可能的，尽管在操作启动之前我们不知道是否可能。
- 当前实现中的问题
无法扩展（取决于协调器）
僵硬的用户体验
B. 拟议工作流：
CLI：当前的 API 足够好，我们只需要确保我们有
来自每个设备的所有属性/健康状况/操作状态字段
快速响应
可扩展
GUI：库存应能够进行定制，以显示每个设备所需的字段信息。每个字段（列）的位置和排序顺序也可以定制。
库存应能够使用设备列表中存在的任何字段进行过滤。
定制的库存列表以及过滤器和排序顺序应能够存储，以便于利用。通过这种方式，我们可以提供一组有趣的预定义库存列表。例如
可用设备
使用最多的设备（平均 iops 最多）（应为警报/触发器）
大于 n Gb 的设备
库存还应提供一种直接对物理设备进行操作的方法
识别：开始/停止闪烁识别灯
创建 OSD：如果此磁盘设备可用，则使用此设备创建 OSD。
移除 OSD：删除使用此磁盘设备的 OSD。
2. 添加 OSD
A. 当前工作流
CLI：我们可以指定特定设备或使用“驱动器组”规范在不同的主机中创建 OSD。默认情况下，要创建的 OSD 定义是“声明性”的，除非您使用 unmanaged 参数。
ceph orch daemon add osd <host>:device1,device2 [--unmanaged=true] (manual approach)
ceph orch apply osd -i <json_file/yaml_file> [--dry-run] [--unmanaged=true]* (Service Spec based approach)
GUI：在仪表板部分“cluster.OSDs”中实现。有一个按钮可以创建 OSD，它显示一个页面对话框，用于选择将作为 OSD 的主要、WAL 或 Db 设备的物理设备。进行选择非常困难（或难以理解如何进行选择）。如果您的集群具有相同类型的设备，情况会更糟，导致无法仅使用一个存储设备创建 OSD（因为您无法选择它）这里的问题是 UI 已被设计为使用“驱动器组”，而不是为用户服务。“驱动器组”是一个抽象概念，必须仅在后台使用。用户不应意识到这个概念。
B. 拟议工作流
CLI 和 GUI
使用“声明性”驱动器组使得很难理解如何配置 OSD 及其影响。这也使实现变得困难，因为多种可能性和生产系统中可能发现的大量不同条件使得对所用存储设备的声明性描述进行正确的评估和使用非常复杂。这会导致意外情况。例如：* 清理过的磁盘可以自动重用，无需任何警告即可创建新的 OSD。* 新安装的磁盘自动用于 OSD（无任何警告）* 尝试在从系统中移除的磁盘上重新创建 OSD 时出错。
因此，为了简化用户和实现的一切，需要考虑一件重要的事情：避免“声明性”使用驱动器组
图形用户界面（GUI）:
用户应该能够定义用于支持 OSD 的物理磁盘设备集。这意味着要使简单的事情变得简单，例如在某个设备中创建一个 OSD，并以简单的方式定义如何在不同主机中的多个设备上创建多个 OSD。
我们应该考虑不同的前提
我们只使用 bluestore OSD，这意味着为了创建一个 OSD，我们可以决定采用不同的策略：仅使用一个设备作为 OSD，使用额外的设备作为 WAL，和/或使用另一个不同的设备作为 DB。将不同的 bluestore OSD 数据组件拆分到不同的设备中，只有当 WAL/DB 设备比主存储设备快时才有意义。设备的拆分始终在同一主机内部，尽管配置将适用于具有相同存储设备模式的其他主机。
在生产系统中大规模创建 OSD 可能会导致真正的灾难，因为重新平衡可能会对正常的系统性能产生负面影响。在首次安装的集群中进行相同的大规模 OSD 创建可能是期望的行为。因此，我们应该提供一种机制，允许用户选择创建 OSD 的方式。似乎我们有两种可能性：* 快速创建 - 速度快但对性能有害 - 直接创建 OSD * 保守创建 - 速度慢但尊重性能 - 创建所有权重为 0 的 OSD。一旦所有 OSD 都安装完毕，开始逐个为每个 OSD 分配正确的权重。
考虑到所有这些前提，建议使用以下具有两种不同模式的界面
设备模式:
向用户显示所有可用设备并具有过滤/列表功能的库存列表，用户可以“玩”此列表以获取一组首选的集群物理存储设备。
用户可以从“首选设备列表”中选择一个、几个或所有设备。这些选定的设备将用于创建 OSD（每个物理设备一个）。
来自先前删除的 OSD 的 OSD ID 可能可用。用户应指明是否必须在新 OSD 中使用这些 ID。
拟议的用户界面可能如下所示
主机模式:
基本上是使用主机中的存储设备进行 OSD 配置。此配置将用作在其他主机中应用相同模式的基础模式。
用户必须选择一个基础主机。选择主机后，我们应该提供主机中可用设备的三种列表（或选择方式）：* “慢速设备”与“hdd”设备 * “快速设备（WAL）”与可用于 Bluestore WAL 数据的“sdd/nvme”设备 * “快速设备（DB）”与可用于 Bluestore DB 数据的“sdd/nvme”设备
用户使用对“慢速设备”列表的过滤器，应选择列表中的一个、几个或所有设备进行 OSD 创建。如果用户想将 Bluestore 数据组件拆分到多个设备中，则需要在其他两个“快速设备”列表中执行相同的操作。
来自先前删除的 OSD 的 OSD ID 可能可用。用户应指明是否必须在新 OSD 中使用这些 ID
选择设备后，我们可以提供将要创建的 OSD 的“预览”。（快速设备可能存储多个 OSD 的 WAL/DB）。
OSD 创建应具有库存和分析功能，以确定 OSD 创建是否可以是混合的、专用的 - 将这些选项呈现给用户（他们从不看到驱动器组！） - 然后他们单击创建。
当用户对主机中的 OSD 配置感到满意时，我们应该提供一种方法来呈现可以应用相同 OSD 配置的主机列表。用户将从该列表中选择他想要创建 OSD 的主机。
必须提供所有主机中 OSD 创建的预览/摘要，如果用户需要此配置，则将应用此配置，从而导致在多个主机中批量创建 OSD。
应提供有关所有主机中 OSD 创建进度的信息。
要考虑的关键点：
1. 上下文至关重要：当前的 OSD 创建流程未提供有关可用设备或主机的任何指示。这导致用户单击添加按钮，但如果没有可用设备，则什么也看不到 - 此时用户假定没有可用设备。主机模式和设备模式 UI 流程都说明了应作为最低要求实现的一些可用性功能。
如果没有可用设备，则应禁用添加按钮
OSD 创建 UI 应包括发现的主机摘要，其中包含磁盘以及可用于 OSD 创建的可用磁盘总数。这还应显示总原始容量。例如：5 个主机，50 个 HDD (80TB)，10 个 NVME (5TB)
- 发现的配置也可以
使用主机机架 ID 注释从故障域角度查看容量，以确保其平衡 - 如果不平衡则发出警告。
确认主机配置是否相同（同构）。因此，异构配置可能会在 UI 中附带 INFO/WARN 消息，以突出显示异构集群的潜在平衡问题。
- 做出部署决定后，显示选择摘要，供用户确认
将使用的按类型划分的设备总数
将创建的 OSD 总数
创建请求的总原始容量，以及 OSD 添加完成后潜在的总原始集群容量
使用经验法则确定近似部署时间 - 设定预期。
2. 启用新容量：有关如何将新磁盘添加到集群的策略选项（这存在于主机模式和设备模式设计中） - 按 OSD 分阶段：所有添加的 OSD 权重均为 0。然后协调器依次重新加权每个 OSD 以推动重新平衡 - 按主机分阶段：给定主机上的所有 OSD 同时重新加权 - 立即：不使用重新加权。立即启动/加入 OSD（在空集群上，这应该是默认值）
3. UI 重新设计：发现设备，根据这些设备结合最佳实践建议布局，通知闪存是否不足以容纳 HDD 数量，通知没有可用设备，并提供我们今天看到的（与驱动器组方法呼应的）高级用例
4. 命令式而非声明式：“声明式”驱动器组的使用在几个方面存在问题
对于最终用户
首次安装集群的“管理员角色”知道当前的硬件组成，并将可能使用计划用于容纳 OSD 的集群主机中的所有存储设备来创建 OSD。
但我们没有告诉“管理员角色”这个初始决定在未来是不可变的，并且会自动应用而没有任何警告。
这将导致几种不希望的情况
1. 带有 OSD 的存储设备不能用于其他目的。因为它们一清理就会立即重新安装为 OSD。似乎很难解释，如果你不想要那样，你需要将设备添加到黑名单中，或者使用“unmanaged”参数创建 OSD。（UI 中未提供）另一种可怕的情况可能是：你为你的一个主机购买了一个新设备来存储 minecraft 服务器。你运气不好，这个设备和你用于 OSD 的设备或多或少相同……那么你将无法安装你的 minecraft 服务器，因为该设备会自动用于 OSD。另一种压力情况……你的实验室团队在你的集群中安装了 10 个新磁盘，他们决定在你集群网络流量最大的地方进行。数据的重新平衡将给“管理员角色”带来有趣的情况。这是一个很好的例子，说明我们如何通过管理 OSD 使用户的生活更加困难
可能几年后，要求会增加。将添加新的不同存储设备。“管理员角色”将需要指定这些设备将容纳 OSD。然后我们必须存储用于创建初始 OSD 的初始“驱动器组”，以及用于新设备的新“驱动器组”定义。所以现在我们有不止一个“驱动器组”，这意味着有两种可能性，添加一个“驱动器组”管理工具，或者将“两个定义”合并为一个！
在任何情况下，这都是一个很好的例子，说明我们如何使用户和开发人员的生活更加困难。
所有这些都可以通过使用命令式驱动器组来避免，我们将提供相同的功能，但没有所有不希望的附带影响。从开发的观点来看，这也将简化事情，因此从“声明式”驱动器组转向“命令式”驱动器组似乎是一个非常好的主意。
3. 移除 OSD
A. 当前工作流
- 命令行界面（CLI）:
我们可以启动命令删除 OSD（一个接一个）
ceph orch osd rm <svc_id(s)> [--replace] [--force]
* We can verify what is the status of the delete operation
ceph orch osd rm status
* Finally we can “clean” completely the device used in the OSD
ceph orch device zap my_hostname /dev/sdx
图形用户界面（GUI）:
在集群 OSD 部分，我们有一个按钮可以对选定的 OSD 执行不同的基本操作。其中一个基本操作是删除。
当选择“删除”基本操作并按下操作按钮时，会显示一个对话框以确认操作和一个用于询问是否保留“osd id”的复选框。接受后似乎什么也没发生……。
无法知道删除操作的进度。
我们倾向于在 UI 中显示所有用于 OSD 管理的基本操作 - 问题是，这是否使环境更复杂？UI 是否应该专注于 OSD 管理的关键工作流，以快速轻松地完成 90% 的工作，而将 10% 留给 CLI？
B. 拟议工作流
命令行界面（CLI）:
需要一种方法提前知道删除 OSD 需要多长时间（如果我们重新平衡数据）
当前的命令集可以满足主要要求
图形用户界面（GUI）:
用户应从具有过滤功能的列表中选择要删除的 OSD（或 OSD 集）。
OSD 移除应提供一个选项来保留 OSD ID，以便在创建新的 OSD 时使用。对操作所需时间进行评估是决定如何执行操作以及何时是最佳时机的另一个重要因素。
当用户决定执行移除操作时，系统应遵循安全程序，并具有一定程度的智能。
根据 OSD 状态（in/out，up/down）和情况（我们处于低/高 CPU/网络利用率时间间隔），我们可能需要做不同的事情。
直接移除 OSD
我们将执行 OSD 删除操作而无需等待。
安全 OSD 移除
我们希望以最安全的方式移除 OSD。这意味着等到我们知道 OSD 没有存储信息。当可以安全移除 OSD 时，用户必须收到通知
计划 OSD 移除
我们希望在将来执行移除操作。除此之外，我们可能只希望在系统利用率低于某个限制时执行移除操作
4. 替换 OSD
A. 当前工作流
与移除 OSD 使用的工作流相同，但我们只需要在删除时使用“replace”参数来保留 OSD ID 以备将来使用。在 GUI 中，replace 参数显示为复选框。
B. 拟议工作流
遵循我们在拟议 OSD 移除工作流中的指令