注意
本文档适用于 Ceph 开发版本。
存储设备和OSD管理流程
集群存储设备是安装在集群每个主机上的物理存储设备。我们需要对它们执行不同的操作，还需要检索有关物理特性和工作行为的信息。
1. 检索设备信息。清单
我们必须能够查看集群存储设备的当前状态和条件。我们需要设备的识别和特性详细信息（包括识别/故障指示灯开/关功能）以及设备是否用作OSD/DB/WAL设备。
每个设备所需的信息至少包括：
Hostname Path Type Serial Size Health Ident Fault Available
为了了解设备的当前状态，我们需要了解已使用的存储量、可用空间百分比、平均IOPS数以及故障指示灯状态。
检索设备信息另一个重要问题是“效率”。设备信息在编排器或仪表板等组件中可能至关重要，因为这些信息通常用于做决策。
以最快的方式获取每个设备的完整信息。
所有主机中所有设备的信息始终可以立即访问。
信息在每个主机中不断更新。设备故障或新设备的添加必须在尽可能短的时间内检测到
可扩展性。与数千个设备在数百个主机中工作不应成为问题。
A. 当前工作流程：
- 命令行界面:
操作：
ceph orch device ls
ceph orch device ls json ( to get all the fields for each device )
Problems in current implementation:
* Does not scale.
- 图形用户界面:
- 操作：
- cluster.Inventory部分：
cluster.Inventory部分展示了集群中设备的基本列表。它是一个固定列表，只有几个字段。只有“识别灯开启”操作是可能的，尽管我们不知道在操作启动之前是否可能，直到操作启动。
- 当前实现中的问题：
不具有可扩展性（取决于编排器）
用户体验僵化
B. 提议的工作流程：
命令行界面:
每个设备的所有属性/健康/运行状态字段
快速响应
可扩展性
图形用户界面:
清单应使用设备列表中的任何字段进行过滤。
定制的清单列表以及过滤器和排序顺序应该能够存储以方便使用。这样我们就可以提供一组有趣的预定义清单。例如：
可用设备
更常用的设备（更多平均iops）（应该是警报/触发器）
大于n GB的设备
清单还应该提供一种直接对物理设备进行操作的方式：
识别：启动/停止闪烁识别灯
创建OSD：如果该磁盘设备可用，则使用它创建OSD。
删除OSD：使用此磁盘设备删除OSD。
2. 添加OSD
A. 当前工作流程
命令行界面:
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)
图形用户界面:
B. 提议的工作流程
命令行界面和图形用户界面
“声明式”驱动器组的利用使得理解如何配置OSD及其影响变得非常困难。这也使得实现变得困难，因为生产系统中的多种可能性和大量不同条件使得正确评估和使用存储设备声明式描述变得非常复杂。
因此，为了简化用户和实现，有一个重要的事情要考虑：避免使用“声明式”驱动器组
图形用户界面:
用户应该能够定义将用于支持OSD的一组物理磁盘设备。
我们应该考虑不同的前提条件：
我们只使用bluestore OSD，这意味着为了创建OSD，我们可以决定采用不同的策略：仅使用单个设备为OSD，使用附加设备为WAL，和/或使用另一个不同的设备为DB。
在生产系统中大规模创建OSD可能会导致真正的灾难，因为重新平衡可能会对正常系统性能产生负面影响。
考虑到所有这些前提条件，提议以下具有两种不同模式的界面：
设备模式:
向用户展示一个包含所有可用设备和过滤/列表功能的清单，用户可以“玩”这个列表，获得一组首选的集群物理存储设备。
用户可以从“首选设备列表”中选择一个、多个或所有设备。这些选定的设备将是用于创建OSD的（每个物理设备一个。）。
来自先前删除的OSD的OSD ID可能可用。用户应指示是否应在新的OSD中使用这些ID。
提议的用户界面可以是：
主机模式:
基本上是使用主机中的存储设备进行OSD配置。此配置将用作在 其他主机中应用相同模式的基础模式。
用户必须选择一个基础主机。
用户应使用“慢设备”列表上的过滤器选择列表中的一个、多个或所有设备进行OSD创建。
来自先前删除的OSD的OSD ID可能可用。用户应指示是否应在新的OSD中使用这些ID
一旦选择了设备，我们可以提供将要创建的OSD的“预览”。（快设备可能将存储多个OSD的WAL/DB）。
OSD创建应具有清单，并分析以确定OSD创建是否可以混合，专用 - 将这些作为选项提供给用户（他们永远不会看到设备组！） - 然后他们点击创建。
当用户对主机中的OSD配置满意时，我们应该提供一种方式来展示可以应用相同OSD配置的主机列表。用户将从该列表中选择他想创建OSD的主机。
必须提供所有主机中OSD创建的预览/摘要，如果用户想要此配置，则它将被应用，从而导致在多个主机中批量创建OSD。
应提供有关所有主机中OSD创建进度的信息。
要考虑的关键点：
1. 上下文至关重要:
如果没有设备可用，添加按钮应被禁用
OSD创建的UI应包括发现的主机摘要，其中包含磁盘和可用于OSD创建的总磁盘数。这也应显示总原始值。例如：5个主机，50个HDD（80TB），10个NVME（5TB）
- 发现的配置也可以
使用主机的机架ID注释来查看容量的容错域视角，以确保其平衡 - 如果不平衡，则发出警告。
确认主机配置是否相同（同质）。因此，异构配置可能因此会在UI中附带INFO/WARN消息，以突出显示异构集群的潜在平衡问题。
- 一旦部署决策做出，显示选择的摘要，用户CONFIRMS
将用于的总设备类型
将创建的总OSD数量
创建请求的整体原始容量，以及OSD添加完成后潜在的原始集群容量
使用经验法则来确定近似部署时间 - 设定预期。
2. 启用新容量:
3. UI重新设计:
4. 命令式而非声明式:
对于最终用户：
“管理员角色”将首次安装集群，知道当前的硬件组成，并将可能使用集群计划用于托管OSD的主机中的所有存储设备创建OSD。
但我们没有告诉“管理员角色”这个初始决策在未来将是不变的，并且将自动应用而无需任何警告。
这将导致几种不期望的情况：
1. 用于OSD的存储设备不能用于其他目的。因为它们在清洁后立即被重新安装为OSD。似乎很难解释的是，如果您不想这样，您需要将设备添加到黑名单中，或使用“unmanaged”参数创建OSD。（未在UI中提供）
大约几年后，需求可能会增长。将添加新的不同存储设备。并且“管理员角色”将需要指定这些设备将托管OSD。然后我们必须存储用于创建初始OSD的初始“驱动器组”，以及新设备的“驱动器组”定义。所以现在我们有一个以上的“驱动器组”，这意味着需要两种可能性，添加一个“驱动器组”管理工具，或者将“两个定义”合并为一个！
在任何情况下，这都是一个关于我们如何让用户和开发人员的生活更艰难的好例子。
所有这些事情都可以通过使用命令式驱动器组来避免，我们将提供相同的功能，但没有任何不希望的附带效应。
3. 删除OSD
A. 当前工作流程
- 命令行界面:
我们可以启动删除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
图形用户界面:
在集群OSD部分，有一个按钮来执行对选定OSD的不同原语操作。其中一个是删除。
当选择“删除”原语并按下操作按钮时，将显示一个确认操作的对话框和一个用于询问是否保留“osd id”的复选框。接受后似乎什么也没发生……。
没有办法知道删除操作的进度。
我们倾向于在UI中显示所有OSD管理的原语 - 问题在于，这是否使环境更复杂？UI应专注于覆盖90%的OSD管理工作流程，以便快速轻松地完成，并将10%留给命令行？
B. 提议的工作流程
命令行界面:
需要提前知道删除一个OSD需要多少时间（如果我们重新平衡数据）
当前命令集可以满足主要要求
图形用户界面:
用户应从具有过滤功能的列表中选择要删除的OSD（或一组OSD）。
OSD删除应提供保留OSD ID以供创建新OSD时使用的选项。对操作所需时间的评估是另一个重要元素，以决定如何执行操作以及何时是最佳时机。
当用户决定执行删除操作时，系统应遵循一个安全的程序，具有一定的智能。
根据OSD状态（在/出，上/下）和情况（我们处于低/高cpu/网络利用率时间间隔），可能需要做不同的事情。
直接删除OSD：
我们将执行OSD删除操作而无需等待。
安全OSD删除：
我们希望以最安全的方式删除OSD。这意味着等到我们知道OSD不再存储信息。用户必须在安全删除OSD时收到通知
计划删除OSD：
我们希望在将来执行删除。除此之外，很可能我们只想在系统利用率低于某个限制时执行删除
4. 替换OSD
A. 当前工作流程
与删除OSD使用相同的工作流程，但我们只需要使用“replace”参数来保留OSD ID，以便在删除时使用。
B. 提议的工作流程
遵循我们为OSD删除提议的工作流程中的指示
由 Ceph 基金会带给您
Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.