Ceph Dashboard 设计目标

Note

本文档旨在为讨论 mgr/dashboard 的整体设计原则提供一个焦点

简介

大多数分布式存储架构本质上都很复杂，对通常跨越多个产品和平台领域的运维团队来说可能是一个管理挑战。总的来说，任何解决方案的复杂性都会直接影响管理它的运营成本。答案很简单……让它简单 :)

本文档旨在突出 Ceph Dashboard 设计目标，这些目标可能有助于

历史上，Ceph 是通过命令行界面 (CLI) 进行管理的。CLI 始终且将始终提供安装和管理 Ceph 集群最丰富、最灵活的方式。需要并要求这种控制水平的管理员不太可能采用 UI，除非是出于技术好奇心。

因此，UI 的相关性对于新的系统管理员来说更为关键，它可以帮助技术采用并减少实施新解决方案时通常遇到的运营摩擦。

因此，理解目标用户角色是设计中的第一步。试图设计一个满足“经验丰富”的 Ceph 管理员或开发人员以及相对较新的系统管理员需求的 UI，不太可能让这两个用户群体都满意。

清晰性和一致性. UI 应确保显示的数据无歧义且在不同视图中保持一致
数据时效性. UI 中显示的数据必须是及时的。状态信息must应该是相对
通过工作流自动化. 如果管理员必须遵循一个“食谱”来执行任务，仪表板 UI 的目标应该是实现该流程。
提供自然的下一步. UI是参数专家系统，因此，与其期望用户知道他们下一步去哪里，UI 应该引导他们。这意味着将组件链接起来以建立流程和更深入集成，包括 alertmanager 实现和仪表板元素，使管理员能够高效地从警报到受影响的组件进行步骤。
平台可见性. 平台（操作系统和硬件配置）是解决方案的基本组成部分，因此提供平台级别的洞察力可以帮助提供 Ceph 集群的更全面视图。
术语解释. 术语是大多数系统不可避免的一部分。然而，一个好的系统将包括内联帮助来支持 UI 的新用户和不频繁用户。

不要在 UI 中重新实现 CLI 命令。系统管理员可能会在脚本中使用 CLI 基本操作来自动化任务，因此，仅仅添加一个 CLI 功能我们就错过了工作流并增加了复杂性，这可能会使 UI“膨胀”。
不要像开发者一样思考……尝试采用管理员的心态，管理员只兼职与 Ceph 集群打交道——这是当今运维团队的现实。

最终，目标必须是避免通过 iSCSI 配置或按定义顺序设置特定集群标志等多步骤工作流将复杂性推向 GUI 用户。简单应该是 UI 的目标……让我们把复杂性留给 CLI。

由 Ceph 基金会带给您

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