节点配置#
将软件镜像传输到节点的操作称为节点配置，由称为配置节点的特殊节点完成。更复杂的集群可以配置多个配置节点，从而在许多节点启动时分配网络流量负载。创建配置节点是通过将配置角色分配给节点或节点类别来完成的。类似于头节点始终具有引导角色，头节点也始终具有配置角色。配置节点在其本地驱动器上保存其配置的所有镜像的副本，与头节点保存此类镜像的目录相同。因此，配置节点的本地驱动器必须有足够的可用空间来存放这些镜像，这可能需要更改其磁盘布局。表 14 显示了配置角色参数。表 14. 配置角色参数 参数 描述 allImages 以下值决定了配置节点提供的镜像： Onlocaldisk 本地磁盘上的所有镜像，无论设置了任何其他参数 Onsharedstorage 共享存储上的所有镜像，无论设置了任何其他参数 no （默认值）仅列在 localimages 或 sharedimages 参数中的镜像 localimages 本地磁盘上配置节点访问和提供的软件镜像列表。仅当 allImages 为 “no” 时才使用此列表 sharedimages 共享存储上配置节点访问和提供的软件镜像列表。仅当 allImages 为 “no” 时才使用此列表 配置槽 配置节点可以并行配置的最大节点数。最佳数量取决于基础设施。默认值为 10，这对于典型的集群设置是安全的。有时可能需要设置较低的值以防止网络和磁盘过载。节点组 节点组列表 (2.1.4)。如果设置，则配置节点仅配置列表中组中的节点。相反，这些组中的节点只能由设置了该组的配置节点配置。没有组的节点或组未在 nodegroups 中列出的节点只能由未设置 nodegroups 值的配置节点配置。默认情况下，nodegroups 列表在配置节点中未设置。nodegroups 设置通常用于设置方便的配置层次结构，例如基于机架分组和机架组分组。
使用 cmsh 进行角色设置#
在以下 cmsh 示例中，管理员创建一个名为 misc 的新类别。默认类别 default 已存在于新安装的集群中。然后，管理员从可分配角色列表中将名为 provisioning 的角色分配给 misc 类别中的节点。在键入 assign 命令之后，但在输入命令之前，可以使用 Tab 键自动完成提示来列出所有可能的角色。分配会在角色和类别之间创建关联。当 assign 命令运行时，shell 会进入表示配置角色的级别。如果名为 provisioning 的角色已分配，则 use provisioning 命令会将 shell 放入配置角色中，而不会在角色和类别之间创建关联。一旦 shell 进入角色级别，就可以编辑角色属性。例如，分配了配置角色的 misc 类别中的节点可以将 default-image 设置为它们配置给其他节点的镜像，并将 20 设置为要同时配置的其他节点的最大数量（以下示例中省略了一些文本）
1[headnode]% category add misc [headnode->category*[misc*]]% roles
2[headnode->category*[misc*]->roles]% assign provisioning [headnode...*]->roles*[provisioning*]]% set allimages no [headnode...*]->roles*[provisioning*]]% set localimages default-image [headnode...*]->roles*[provisioning*]]% set provisioningslots 20 [headnode...*]->roles*[provisioning*]]% show
3Parameter Value
4--------------------------------- ---------------------------------
5All Images no
6Include revisions of local images yes
7Local images default-image
8Name provisioning
9Nodegroups
10Provisioning associations <0 internally used> Revision
11Shared images
12Type ProvisioningRole
13Provisioning slots 20
14[headnode->category*[misc*]->roles*[provisioning*]]% commit
15[headnode->category[misc]->roles[provisioning]]
如果认为使用类别过于繁琐，也可以为单个节点分配配置角色
1[headnode]% device use dgx001 [headnode->device[dgx001]]% roles
2[headnode->device[dgx001]->roles]% assign provisioning
3[headnode->device*[dgx001*]->roles*[provisioning*]]%
4...
角色更改会配置配置节点，但不会直接使用镜像更新配置节点。在进行角色更改后，集群管理器会自动运行 9.3 中描述的 updateprovisioners 命令，以便将常规镜像传播到配置器。如果配置器具有最新的镜像，则可以由配置器自行完成传播。CMDaemon 跟踪配置节点角色更改，以及哪些配置节点具有可用的最新镜像，以便配置节点配置和计算节点镜像能够有效地传播。因此，例如，配置节点发出的镜像更新请求优先于计算节点发出的配置更新请求。其他可分配的临时角色包括监控、存储和故障转移。
使用基本视图进行角色设置#
在 cmsh 模式 (9.1) 中概述的配置配置可以使用基本视图完成。可以使用点击路径 Grouping>Categories>Add>Settings<name> 添加 misc 类别。在“设置”选项卡中，应为节点类别命名为 misc (图 15) 并保存。
图 15. 基本视图：添加 misc 类别
然后可以从设置窗格的“跳转到”部分打开“角色”窗口。要添加角色，请选择“角色”窗口中的“+ 添加”按钮。然后会显示可用角色的可滚动列表 (图 16)。
图 16. 基本视图：设置配置角色
选择角色后，使用“后退”按钮导航到“设置”菜单，然后选择“保存”按钮。角色具有可以编辑的属性 (图 17)。
图 17. 基本视图：配置配置角色
例如
“配置槽”设置决定了配置节点可以同时提供的镜像数量。
“所有镜像”设置决定了角色是否提供所有镜像。
“本地镜像”设置决定了配置节点从本地存储提供的镜像。
“共享镜像”设置决定了配置节点提供共享存储的哪些镜像。
配置角色提供的镜像不应与 misc 类别本身的软件镜像设置混淆，后者是配置节点从类别请求的镜像。
内务处理#
头节点为整个配置系统执行内务处理任务。配置是根据所有非头节点的请求按先到先得的原则完成的。由于配置节点本身也必须进行配置，这意味着要最快地冷启动整个集群，应首先启动并运行头节点，然后是配置节点，最后是所有其他非头节点。遵循此启动顺序可确保在启动其他非头节点时，所有配置服务都可用。接下来讨论配置内务处理的某些方面。
配置节点选择#
当节点请求配置时，头节点将任务分配给配置节点。如果有多个可以提供所需镜像的配置节点，则将任务分配给已启动的配置任务数量最少的配置节点。
限制配置任务#
除了使用“配置槽” (9) 限制每个配置节点允许的并发配置数量外，头节点还限制了允许在整个集群上运行的并发配置任务数量。这可以使用头节点的 CMDaemon 配置文件 /etc/cmd.conf 中的 MaxNumberOfProvisioningThreads 指令进行设置，如 Bright Cluster Manager 管理员手册的 附录 C 中所述。
配置任务延迟和失败#
如果头节点无法立即为任务分配配置节点，则配置请求将被延迟。每当正在进行的配置任务完成时，头节点都会尝试重新分配延迟的请求。如果镜像未传输，则配置请求将失败。如果配置请求失败，则会尝试重试配置镜像五次。如果配置节点在执行请求时失去连接，则配置请求将在失去连接后 180 秒后失败。
角色更改通知#
可以从 cmsh 的 softwareimage 模式访问 updateprovisioners 命令。也可以从基本视图访问，使用点击路径 Provisioning>Provisioning requests>Update provisioning nodes。
在 9.1 中的示例中，对单个节点以及节点类别的配置角色属性进行了更改。这会自动运行 updateprovisioners 命令。
如果在软件镜像更改期间或配置请求期间涉及 CMDaemon，则 updateprovisioners 命令会自动运行。另一方面，如果软件镜像是在 CMDaemon 前端之外更改的，例如管理员通过从 bash 提示符复制文件将其添加到位，则应手动运行 updateprovisioners 以更新配置器。
在任何情况下，如果未手动运行，则默认情况下计划在每天午夜运行。
当手动调用默认的 updateprovisioners 时，配置系统会等待所有正在运行的配置任务结束，然后通过使用头节点上的镜像来更新任何配置节点上的所有镜像。它还会使用更新后的配置角色属性重新初始化其内部状态，即跟踪哪些节点是配置节点。
默认的 updateprovisioners 命令在不带选项的情况下运行时，会更新所有镜像。如果从 cmsh 运行并指定镜像作为选项，则该命令仅对该镜像执行更新。正在进行镜像更新的配置节点在更新完成之前不会配置其他节点。
1[headnode]% software image updateprovisioners Provisioning nodes will be updated in the background.
2Sun Dec 12 13:45:09 2010 headnode: Starting update of software image(s)\ provisioning node(s). (user initiated).
3[headnode]% software image updateprovisioners
4[headnode]%
5Sun Dec 12 13:45:41 2010 headnode: Updating image default-image on provisioning node dgx001.
6[headnode]%
7Sun Dec 12 13:46:00 2010 headnode: Updating image default-image on provisioning node dgx001 completed.
8Sun Dec 12 13:46:00 2010 headnode: Provisioning node dgx001 was updated Sun Dec 12 13:46:00 2010 headnode: Finished updating software image(s) \ on provisioning node(s).
角色排空和取消排空节点#
可以使用 cmsh 的 softwareimage 模式访问用于控制配置节点的 drain 和 undrain 命令。
如果节点进入排空状态，所有活动的配置请求将继续直到完成。但是，在节点恢复到取消排空状态之前，不会为该节点分配任何进一步的挂起请求。
1[headnode->software image]% drain -n master Nodes drained
2[headnode->software image]% provisioningstatus Provisioning subsystem status
3Pending request: dgx001, dgx002 Provisioning node status:
4+ headnode
5Slots: 1 / 10
6State: draining
7Active nodes: dgx003
8Up to date images: default-image [headnode->software image]% provisioningstatus Provisioning subsystem status
9Pending request: dgx001, dgx002 Provisioning node status:
10+ headnode
11Slots: 0 / 10
12State: drained
13Active nodes: none
14Up to date images: default-image
使用 --role provisioning 选项并行排空所有节点。然后，所有挂起的请求都将保留在队列中，直到节点再次取消排空。
1[headnode->software image]% drain --role provisioning
2...Time passes. Pending
3requests stay in the queue. Then admin undrains it...
4[headnode->software image]% undrain --role provisioning
配置节点更新安全措施#
updateprovisioners 命令受到安全措施的限制，以防止其运行过于频繁。“配置节点自动更新超时”参数可以调整配置更新之间的最短时间间隔，其默认值为 300 秒。
超过超时时间本身不会触发配置节点的更新。
当头节点收到配置请求时，它会检查配置节点的上次更新是否超过超时时间。如果为真，则会触发配置节点的更新。如果超时时间设置为零（false），则禁用更新。
可以从分区模式在 cmsh 中访问和设置该参数
1[root©brght92 ]# cmsh [headnode]% partition use base
2[headnode->partition[base]]% get provisioningnodeautoupdatetimeout
3[headnode->partition[base]]% 300
4[headnode->partition[base]]% set provisioningnodeautoupdatetimeout 0
5[headnode->partition*[base*]]% commit
在基本视图中，可以通过点击路径 Cluster>Partition[base]>Provisioning Node Auto Update Timeout 访问该参数。
为了防止将镜像配置到节点，可以锁定镜像。然后，配置请求将被延迟，直到镜像再次解锁。
将 fspart 子目录同步到配置节点#
在集群管理器中，fspart 是一个子目录，它是可以在配置期间同步的文件系统部分。可以使用以下命令列出 fspart：
1[root©headnode ]# cmsh [headnode]% fspart [headnode->fspartJ] list
2Path (key) Type Image
3------------------------------ --------------- ------------------------
4/cm/images/default-image image default-image
5/cm/images/default-image/boot boot default-image:boot
6/cm/node-installer node-installer
7/cm/shared cm-shared
8/tftpboot tftpboot
9/var/spool/cmd/monitoring monitoring
updateprovisioners 命令用于将镜像 fspart 更新到具有配置角色的所有节点。
trigger 命令用于将非镜像 fspart 更新到场外节点，例如云主管和边缘主管。主管为他们指导的节点提供配置角色。
可以使用 --all option 更新所有非镜像类型
1[headnode->fspart]% trigger --all
fspart 模式下的 command help trigger 提供更多详细信息。
info 命令显示架构、操作系统以及跟踪 fspart 子目录中 rsync 的 inotify 观察器数量。
1[headnode->fspart]% info
2Path Architecture OS Inotify watchers
3------------------------------ ---------------- ---------------- ----------------
4/cm/images/default-image x86_64 ubuntu2004 0
5/cm/images/default-image/boot - - 0
6/cm/node-installer x86_64 ubuntu2004 0
7/cm/shared x86_64 ubuntu2004 0
8/tftpboot - - 0
9/var/spool/cmd/monitoring - - 0
10[headnode->fspart]% info -s Path (!#with size, takes longer)
11Path Architecture OS Inotify watchers Size
12---------------------------- ---------------- ---------------- ---------------- -------------
13/cm/images/default-image x86_64 ubuntu2004 0 4.2 GiB
14/cm/images/default-image/boot - - 0 179 MiB
15/cm/node-installer x86_64 ubuntu2004 0 2.45 GiB
16/cm/shared x86_64 ubuntu2004 0 2.49 GiB
17/tftpboot - - 0 3.3 MiB
18/var/spool/cmd/monitoring - - 0 1.02 GiB
locked、lock 和 unlock 命令
locked 命令列出阻止同步的 fspart。
1[headnode->fspart]% locked No locked fsparts
lock 命令阻止特定的 fspart 同步。
1[headnode->fspart]% lock /var/spool/cmd/monitoring [headnode->fspart]% locked 2/var/spool/cmd/monitoring
unlock 命令再次解锁特定的锁定 fspart。
1[headnode->fspart]% unlock /var/spool/cmd/monitoring [headnode->fspart]% locked 2No locked fsparts
访问 excludelistsnippets
可以从 excludelistsnippets 子模式访问特定 fspart 的 excludelistsnippets 属性
1[headnode->fspart]% excludelistsnippets /tftpboot
2[headnode->fspart[/tftpboot]->exclude list snippets]% list
3Name (key) Lines Disabled Mode sync Mode full Mode update Mode grab Mode grab new
4------------ ------- -------- --------- --------- ----------- --------- -------------
5Default 2 no yes yes yes no no
6
7[headnode->fspart[/tftpboot]->exclude list snippets]% show default
8Parameter Value
9----------------------------- ------------------------------------------------------------
10Lines 2
11Name Default
12Revision
13Exclude list # no need for rescue on nodes with a boot role,/rescue,/rescue/*
14Disabled no
15No new files no
16Mode sync yes
17Mode full yes
18Mode update yes
19Mode grab no
20Mode grab new no
21[headnode->fspart[/tftpboot]->exclude list snippets]% get default exclude list
22# no need for rescue on nodes with a boot role
23/rescue
24/rescue/*