Mimic 中的新功能：集中式配置管理

sage

Ceph Mimic 的关键新特性之一是能够集中管理集群配置——传统上存储在 ceph.conf 中。 从 Mimic 开始，集群配置不仅存储在 ceph.conf 中，还存储在监视器内部数据库中。 这使得能够将该配置信息管理和分发到系统中的所有守护进程和客户端。

过去，如果操作员想要更改配置，必须手动编辑 ceph.conf 文件，将其分发到正确的节点，并确保正确的守护进程已重新启动。 大多数大规模用户依赖于外部工具（如 Ansible、Puppet 或 Salt）来执行此操作，但解决方案总是各不相同，并且始终存在配置管理服务认为的配置与正在运行的守护进程使用的配置之间的差异（本地 ceph.conf 是否已更新？ 守护进程是否已重新启动？ 操作员是否通过命令行注入了配置更改？）。

此新特性，这种集中式配置，旨在弥合这一差距。 它提供了一个可靠的视图，了解应该是什么配置（以及运行的配置是否匹配），并消除了管理 ceph.conf 配置文件所需的外部工具。 最重要的是，它开箱即用地提供了一个简化的配置体验。

请注意，此新功能旨在与通过 ceph.conf 管理配置的传统方式互操作，因此，如果这是他们的首选，升级到 Mimic 的任何人都不需要进行任何更改。 但是，我们预计这种新操作模式的优势将使其迁移具有吸引力，甚至不可抗拒。

基础知识

监视器共同管理一个配置数据库。 数据库与 ceph.conf 文件具有相同的语义结构

  • 存在选项名称（例如，osd scrub load threshold）和值。
  • 可以将设置与“全局”组关联，以及应用于给定类型的所有实体（例如，“osd”或“mds”）的类型组，或特定的守护进程（例如，“osd.123”）。

ceph config dump 命令以表格形式输出集群范围内的 ceph.conf 的等效内容。

当守护进程或客户端启动时，它会像以前一样查找 ceph.conf 文件。 在大多数情况下，仍然需要一个小的 ceph.conf 文件才能识别监视器。 例如，一个典型的最小 ceph.conf 文件可能是

mon host = mon-a.foo.com, mon-b.foo.com, mon-c.foo.com

或者更好的是

mon host = ceph-mons.foo.com

其中 ceph-mons 是一个 DNS 条目，其中包含多个 A 记录（每个监视器一个）。 这允许监视器的数量和身份随时间变化，而无需修改任何配置文件。 更重要的是，集群的每个配置文件通常在整个生命周期中是静态的，这简化了部署和管理。

您也可以将其他任何设置放在 ceph.conf 中。 Ceph 用于设置选项的总体优先级顺序是

  1. 编译时默认值
  2. 集群配置数据库（新功能！）
  3. 本地 ceph.conf 文件
  4. 运行时覆盖（通过“ceph daemonconfig set ..." 或 "ceph tellinjectargs ...")

命令行界面

键入 ceph config -h 将总结可用的命令集

$ ceph config -h [...] config assimilate-conf 从 conf 中提取选项，并返回一个新的最小 conf 文件 config dump 显示所有配置选项 config get{} 显示实体的配置选项 config help描述配置选项 config log {} 显示配置更改的历史记录 config reset将配置恢复到以前的状态 config rm清除一个或多个实体的配置选项 config set为一个或多个实体设置配置选项 config show{} 显示正在运行的配置 config show-with-defaults显示正在运行的配置（包括编译时默认值）

一个好的起点是简单地转储集群配置

$ ceph config dump WHO MASK LEVEL OPTION VALUE RO global advanced mon_pg_warn_min_per_osd 3
global advanced osd_pool_default_min_size 1
global advanced osd_pool_default_size 1
mon advanced mon_allow_pool_delete true
...

我们可以这样设置一个选项

$ ceph config set osd debug_ms 1 $ ceph config dump WHO MASK LEVEL OPTION VALUE RO global advanced mon_pg_warn_min_per_osd 3
global advanced osd_pool_default_min_size 1
global advanced osd_pool_default_size 1
mon advanced mon_allow_pool_delete true
... osd advanced debug_ms 1 ...

请注意，这仅仅是使更改所必需的一切：系统中的任何守护进程或客户端（该选项适用）都会立即收到配置更改的通知。 无需重新启动任何守护进程，也不需要使用笨拙的 ceph tell ... injectargs ... 命令。

在上面的转储输出中，MASK 字段是对哪些守护进程或客户端适用该选项的第二个限制，可以匹配 CRUSH 位置（例如，“rack:foo”）或 OSD 类（例如，“ssd”与“hdd”）。 例如，我们可以设置仅适用于由 SSD 支持的 OSD（由 ceph osd crush tree 命令报告）的更高调试级别

$ ceph config set osd/class:ssd debug_ms 2 $ ceph config dump WHO MASK LEVEL OPTION VALUE RO ... osd advanced debug_ms 1 osd class:ssd advanced debug_ms 2 ...

与其转储整个配置数据库，您可以检查系统中的单个守护进程的配置。 例如

$ ceph config set osd.0 debug_osd 10 $ ceph config get osd.0 WHO MASK LEVEL OPTION VALUE RO osd class:ssd advanced debug_ms 2/2
osd.0 advanced debug_osd 10/10 global advanced mon_pg_warn_min_per_osd 3
...

此输出告诉您哪些选项和值适用于该守护进程，以及该选项来自哪里（是全局设置的，是专门为此守护进程设置的，等等）。

当然，也可以清除配置条目

$ ceph config rm osd/class:ssd debug_ms $ ceph config get osd.0 WHO MASK LEVEL OPTION VALUE RO osd advanced debug_ms 1/1
global advanced mon_pg_warn_min_per_osd 3
...

强制配置模式

这种新方法的优点之一是，在设置配置值时会对其进行验证和检查。 配置模式（哪些选项存在以及哪些值是合法的）编译到系统中并且是全局已知的。 如果您尝试设置无意义的内容，您将收到信息性的错误消息，并且不会影响现有的配置。 例如

$ ceph config set osd.10 debug_osd very_high Error EINVAL: error parsing value: value must take the form N or N/M, where N and M are integers $ ceph config set osd.10 bluestore_compression_mode 1 Error EINVAL: error parsing value: '1' is not one of the permitted values: none, passive, aggressive, force

可以使用 help 命令查询特定选项的模式

$ ceph config help bluestore_compression_mode bluestore_compression_mode - 默认情况下，当池未指定时使用压缩的策略 (std::string, advanced) 默认值: none 可能的值: none passive aggressive force 运行时可更新: true

'none' 表示从不使用压缩。 'passive' 表示当客户端提示数据可压缩时使用压缩。 'aggressive' 表示除非客户端提示数据不可压缩，否则使用压缩。 当每个池的压缩模式属性不存在时，使用此选项。

您会注意到该行中 advanced。 所有选项分为三类：基本、高级和开发。 开发选项旨在用于开发和测试，通常不打算由用户修改。 高级选项不言自明，仅供高级用户使用。 基本选项相对较少，因为……好吧，通常，我们不希望需要大量的配置才能使 Ceph 正常工作。

一些数字选项包括最小值和最大值，并接受后缀，例如 K（千）或 M（兆），用于大值

$ ceph config set mon mon_data_size_warn 100G $ ceph config get mon.a WHO MASK LEVEL OPTION VALUE RO mon advanced mon_data_size_warn 107374182400
...

请注意，'K' 表示 1000 还是 1024 取决于配置选项：有些基于 SI 单位（基数为 10），有些基于 IEC 单位（基数为 2，如 KiB 和 GiB）。

正在运行的配置

由于配置可以来自多个位置（默认值、集群配置、本地 ceph.conf、操作员覆盖），因此有一个 show 命令会返回系统中的任何守护进程报告的活动配置选项。 例如

$ ceph daemon mgr.x config set debug_mgr 10 # 手动覆盖配置选项 $ ceph config set mgr.x ms_type simple # 设置一个选项 $ ceph config show mgr.x NAME VALUE SOURCE OVERRIDES IGNORES debug_mgr 10/10 override mon[20/20]
debug_mon 20/20 mon
debug_ms 1/1 file
ms_type async+posix default mon
...

NAME 和 VALUE 列告诉您当前生效的哪些选项和值。 SOURCE 告诉您该值来自哪里：“override”来自我们上面的 ceph daemon ... 命令，“mon”来自集群配置数据库，“file”来自本地 ceph.conf 文件。 在覆盖源的情况下，OVERRIDES 列告诉您该值会是什么（以及它将从哪里获取）；在这种情况下，如果未发出该 ceph daemon ... 命令，debug_mgr 将设置为 20/20 由监视器设置。

IGNORE 列指示选项已设置为新值，而守护进程仍在使用的旧值。 这适用于只能在重新启动守护进程时生效的许多选项，例如 ms_type（控制使用的消息传递实现）。 您还可以看到 config get 命令结果中的 RO 列。

$ ceph config get mgr.x WHO MASK LEVEL OPTION VALUE RO mgr advanced debug_mgr 20/20 *
mgr advanced ms_type simple *

您还会注意到 ms_type 的帮助结果告诉我们同样的事情

$ ceph config help ms_type ... 默认值: async+posix 运行时可更新: false

配置更改历史记录

使用外部配置管理框架的主要优势之一是，这些工具通常将声明式系统配置存储在 Git 等源代码控制工具中。 这提供了系统更改的历史记录，以便在出现问题时可以撤消更改。

Ceph 的新配置管理提供了该功能的简单版本。 系统中的每次配置更改都会被记录并易于查看

$ ceph config log --- 15 --- 2018-06-13 15:02:46.176060 ---

  • mgr.x/ms_type = simple
  • mgr.x/ms_type = async --- 14 --- 2018-06-13 14:52:51.877714 ---
  • mgr.x/ms_type = simple --- 13 --- 2018-06-13 14:45:33.988326 ---
  • mon/mon_data_size_warn = 107374182400 ...

输出旨在熟悉于 diff 输出的任何人，其中“+”行表示新的配置条目，而“-”行表示已删除或替换的条目（及其先前的值）。

可以通过使用每个更改记录之前的前缀数字将配置恢复到以前的状态。 例如，要撤消对 ms_type 的更改，

$ ceph config reset 13 $ ceph config log --- 16 --- 2018-06-13 15:05:10.960659 --- 重置为 13 ---

  • mgr.x/ms_type = async --- 15 --- 2018-06-13 15:02:46.176060 ---
  • mgr.x/ms_type = simple
  • mgr.x/ms_type = async --- 14 --- 2018-06-13 14:52:51.877714 ---
  • mgr.x/ms_type = simple --- 13 --- 2018-06-13 14:45:33.988326 ---
  • mon/mon_data_size_warn = 107374182400 ...

（重置为 13 的净效果是删除了 ms_type 条目，即使从那时起它有两个中间值。） 由于 reset 命令与其他任何配置更改一样，可以使用另一个 reset 命令撤消它。

从旧配置文件迁移

任何现有的集群很可能在每个节点的 ceph.conf 文件中都有各种设置。我们还提供了一个命令，可以轻松地将这些文件导入到配置数据库中。

一个挑战是，并非所有选项都适合存储在中央配置数据库中。mon_host 选项就是一个很好的例子：它用于在获取任何其他配置选项之前启动到集群的连接。因此，导入命令同时接受现有的配置文件作为输入，并生成一个（希望更短）的输出配置文件，其中包含任何无法同化的选项。例如

$ cat ceph.conf [global] mon host = foo.ceph.com [osd.1] debug_osd = 0/0 [mds.a] mds invalid option = this option does not exist

$ ceph config assimilate-conf -i ceph.conf -o ceph.conf.new [global] mon_host = foo.ceph.com

[mds.a] mds_invalid_option = this option does not exist

$ ceph config get osd.1 WHO MASK LEVEL OPTION VALUE RO osd.1 advanced debug_osd 0/0
...

在这个简单的例子中，只有 osd.1 的 debug_osd 选项被导入。mon_host 被保留下来（它用于启动），而 mds_invalid_option 被保留下来（它不是一个已知的选项）。

对于正在过渡到集群管理的配置的集群，基本过程是在每个主机上运行一个同化命令（如上所示），这将把设置合并到集群的配置数据库中，并在每个主机上只保留与启动相关的选项。例如

$ cd /etc/ceph $ ceph config assimilate-conf -i ceph.conf -o ceph.conf.new $ cat ceph.conf.new # 确保它看起来没问题！ $ mv ceph.conf.new ceph.conf

在大多数情况下，这将有效。但是，如果您正在同化一个更改了输入中提到的任何设置的配置文件（这意味着存在两个不同的主机，并且每个主机都有将相同的选项设置为不同值的配置文件），那么最终结果将取决于文件同化的顺序。

后续步骤

展望未来，下一步是将所有这些配置选项呈现在新的管理仪表板中。有一个正在进行的拉取请求添加此功能，它将在即将发布的 Nautilus 版本中提供此功能。