集群管理守护程序#

集群管理守护程序或 CMDaemon 是一个服务器进程，它在 DGX SuperPOD 的所有节点上运行（包括头节点）。CMDaemons 协同工作以使集群可管理。当 cmsh 和 Base View 等应用程序与集群通信时，它们正在与头节点上运行的 CMDaemon 交互。集群管理应用程序永远不会直接与在非头节点上运行的 CMDaemon 通信。

CMDaemon 应用程序在任何节点启动时自动开始运行，并且该应用程序持续运行直到节点关闭。如果 CMDaemon 因任何原因被手动停止，其集群管理功能将变得不可用，使得管理员难以管理集群。但是，即使守护程序停止，集群仍然完全可用于使用工作负载管理器运行计算作业。

与 CMDaemon 通信的唯一途径是通过 TCP 端口 8081。CMDaemon 仅接受 SSL 连接，从而确保所有通信都经过加密。身份验证也在 SSL 层中使用客户端 X509v3 证书 (2.2) 进行管理。

在头节点上，CMDaemon 使用 MySQL 数据库服务器来存储其所有内部数据。另一方面，原始监控数据作为二进制数据存储在 MySQL 数据库之外。

控制 CMDaemon#

关闭或重启 CMDaemon 可能很有用。例如，当 CMDaemon 配置文件被修改时，可能需要重启以激活更改。CMDaemon 操作可以通过以下 init 脚本参数 service cmd 进行控制。

cmdaemonctl 命令参数在 表 8 中显示。

表 8. cmdaemonctl 命令参数

参数

描述

stop

停止 CMDaemon

start

启动 CMDaemon

reload

重新加载 CMDaemon 的配置

force-reload

强制重新加载 CMDaemon 的配置

restart

重启 CMDaemon

try-restart

尝试重启 CMDaemon，但仅当它正在运行时

status report

CMDaemon 是否正在运行

full-status∗

报告有关 CMDaemon 的详细统计信息

upgrade∗

版本升级后更新数据库架构（仅限专家）

debugon∗

启用调试日志记录（仅限专家）

debugoff∗

禁用调试日志记录（仅限专家）

logconf∗

重新加载日志配置

  • 可与 cmdeamonctl 以及 service 命令一起使用的参数

在集群的头节点上重启 CMDaemon

1[root©dgxsuperpod ~]# service cmd restart
2Redirecting to /bin/systemctl restart cmd.service
3[root©dgxsuperpod ~]#

查看 CMDaemon 使用的资源以及其他有用信息

 1[root©headnode etc]# service cmd status
 2CMDaemon version 2.1 is running (active) Running locally
 3Current Time: Fri, 29 Jan 2021 01:48:28 CET
 4Startup Time: Thu, 28 Jan 2021 15:45:17 CET Uptime: 10h 3m
 5CPU Usage: 66.8112u 50.5393s (0.3%)
 6Memory Usage: 172MB
 7Sessions Since Startup: 29 Active Sessions: 7
 8Number of occupied worker-threads: 7 Number of free worker-threads: 14
 9Connections handled: 2397
10Requests processed: 6850 Total read: 1.98MB
11Total written: 170MB
12Average request rate: 11.4requests/m Average bandwidth usage: 4KB/s

在计算节点 dgx001 到 dgx040 的序列上重启 CMDaemon

1[root©dgxsuperpod ~]# pdsh -w dgx00[1-9],dgx0[1-3][0-9],dgx040 service cmd restart

这使用了并行 shell 命令 pdsh。

配置 CMDaemon#

许多集群配置更改可以通过修改 CMDaemon 配置文件来完成。对于头节点，该文件位于

1/cm/local/apps/cmd/etc/cmd.conf

对于计算节点，它位于节点使用的软件映像内部。

Bright Cluster Manager 管理员手册的 附录 C 描述了受支持的配置文件指令以及如何使用它们。通常没有必要修改默认设置。

修改配置文件后，必须重启 CMDaemon 才能激活更改。

CMDaemon 版本#

为了调试问题，了解集群上正在使用的 CMDaemon 版本可能会有所帮助。cmdaemonversions 命令在 cmsh 的设备模式下运行。它列出了集群节点上运行的 CMDaemon 版本。

1[headnode->device]% cmdaemonversions
2Hostname                      Version index Version hash
3---------------- ------------- ------------
4headnode                      146,965        e6f593b676
5dgx001                        146,965        e6f593b676
6dgx002                        146,965        e6f593b676

较高的版本索引值表示更新的 CMDaemon 版本。

–join 选项是一个格式化选项，用于收集具有相同选项的版本

1[headnode->device]% cmdaemonversions --join
2Version index Version hash Count       Hostnames
3------------- ------------ ------------ -------------------------
4146,965               e6f593b676   3                   headnode,dgx001..dgx002

配置 CMDaemon 日志记录#

CMDaemon 在 /var/log/cmdaemon 中从特定的内部子系统（例如工作负载管理、服务管理、监控和证书）生成日志消息。默认情况下，这些子系统都不会生成详细的（调试级别）消息，因为这会使日志文件快速增长。

CMDaemon 日志记录配置全局调试模式#

可以使用 cmdaemonctl 在 CMDaemon 中启用全局调试模式

1[root©headnode ~]# cmdaemonctl -h cmdaemonctl [OPTIONS…] COMMAND ...
2Query or send control commands to the cluster manager daemon.
3-h --help   Show this help Commands:
4debugon     Turn on CMDaemon debug
5debugoff    Turn off CMDaemon debug
6...
7[root©headnode ~]# cmdaemonctl debugon CMDaemon debug level on

通过执行 cmdaemonctl debugoff 停止调试级别日志运行时间过长是一个好主意，特别是对于生产集群。这对于防止集群被过大的日志淹没非常重要。

CMDaemon 子系统日志记录配置调试模式#

CMDaemon 子系统可以分别按子系统生成调试日志，包括按严重性级别。这可以通过修改位于以下位置的日志记录配置文件来完成

1/cm/local/apps/cmd/etc/logging.cmd.conf

在此文件中，标题为“#Available Subsystems”的部分列出了可以监控的可用子系统。这些子系统包括 MON（用于监控）、DB（用于数据库）、HA（用于高可用性）、CERTS（用于证书）、CEPH（用于 Ceph）等等。

CMDaemon 子系统日志记录配置严重性级别#

除了调试设置外，其他严重性级别还包括 info、warning、error 和 all。有关设置子系统选项的更多详细信息，请参见 logging.cmd.conf 文件。例如，要将 CMDaemon 日志输出设置为监控，严重性级别为警告，则 section severity 的文件内容可能如下所示

1Severity {
2    warning: MON
3}

CMDaemon 子系统日志记录配置部署#

新的日志记录配置可以从文件中重新加载，方法是重启 CMDaemon

1[root©headnode etc]# service cmd restart

或者通过重新加载日志记录配置

1[root©headnode etc]# service cmd logconf

配置文件修改和 FrozenFile 指令#

作为其任务的一部分，CMDaemon 修改了多个系统配置文件。一些配置文件被完全替换，而其他配置文件仅修改了一些部分。附录 A Bright Cluster Manager 管理员手册列出了所有被修改的系统配置文件。

完全由 CMDaemon 生成的文件包含一个标头

1# This file was automatically generated by cmd. Do not edit manually!

除非使用 FrozenFile <https://support.brightcomputing.com/manuals/9.2/admin-manual.pdf#section*.929>__ 配置文件指令来保持其冻结，否则此类文件将被完全覆盖。

由 CMDaemon 生成的文件部分将读取如下

1# This section of this file was automatically generated by cmd.
2Do not edit manually!
3# BEGIN AUTOGENERATED SECTION -- DO NOT REMOVE
4...
5# END AUTOGENERATED SECTION -- DO NOT REMOVE

除非使用 FrozenFile 配置文件指令来保持这些部分冻结，否则此类文件仅自动覆盖自动生成的部分。cmd.conf 中的 FrozenFile 配置文件指令设置如下例所示

1FrozenFile  =  {  "/etc/dhcpd.conf",  "/etc/postfix/main.cf"  }

如果生成的文件或文件的某个部分具有手动修改的部分，并且在不使用 FrozenFile 时，则在覆盖期间会生成一个事件，并且手动修改的配置文件将备份到

1/var/spool/cmd/saved-config-files

使用 FrozenFile 可以被视为一种配置技术，也是各种可能的配置技术之一。

配置文件优先级#

虽然集群管理器尽可能少地更改它管理的标准发行版，但有时可能存在不可避免的问题。有时，标准发行版实用程序或服务会生成与集群管理器生成的配置文件冲突的配置文件。在这种情况下，必须优先考虑集群管理器生成的配置文件，并且应避免从标准发行版生成配置文件。有时，使用完全或部分冻结的配置文件 (3.4) 允许一种解决方法。否则，集群管理器版本的功能通常允许实现所需的配置功能。有关软件包管理系统安装和更新的配置文件的详细信息，请在 Bright Cluster Manager 管理员手册的 附录 A 中进一步讨论。

在本页中