第 6 章 可组合服务和自定义角色
Overcloud 通常由预定义角色中的节点组成，如 Controller 节点、Compute 节点和不同的存储节点类型。这些默认角色各自包含 director 节点上核心 Heat 模板集合中定义的一组服务。但是，核心 Heat 模板的架构提供了如下方法：
- 创建自定义角色
- 为每个角色添加和删除服务
本章介绍了自定义角色、可组合服务和方法的架构。
指南和限制
请注意可组合节点架构的以下指南和限制：
-
您可以将任何
systemd受管服务分配给受支持的独立自定义角色。 - 您无法分割 Pacemaker 管理的服务。这是因为 Pacemaker 在 Overcloud 集群内的每个节点上管理相同的服务集合。分割 Pacemaker 管理的服务可能会导致集群部署错误。这些服务应保留在 Controller 角色上。
- 您无法在升级过程中更改为自定义角色和可组合服务，从 Red Hat OpenStack Platform 9 升级到 10。升级脚本只能容纳默认的 Overcloud 角色。
- 您可以在初始部署后创建额外的自定义角色，并进行部署以扩展现有服务。
- 在部署 Overcloud 后，您无法修改任何角色的服务列表。在 Overcloud 部署后修改服务列表可能会导致部署错误并在节点上保留孤立的服务。
支持的自定义角色架构
自定义角色和可组合服务是 Red Hat OpenStack Platform 10 中的新功能，在这个早期阶段只测试并验证了有限的可组合服务组合。红帽在使用自定义角色和可组合服务时支持以下构架：
- 架构 1 - Monolithic Controller
- 所有控制器服务都包含在一个 Controller 角色中。这是默认值。详情请查看 第 6.8 节 “服务架构：Monolithic Controller”。
- 架构 2 - Split Controller
控制器服务被分成两个角色：
- 控制器 PCMK - 核心 Pacemaker 管理的服务，如数据库和负载均衡
- Controller Systemd - 'systemd`-managed OpenStack Platform services
- 架构 3 - 独立角色
- 使用架构 1 或架构 2，除了将 OpenStack Platform 服务分成自定义角色外。详情请查看 第 6.10 节 “服务架构：独立角色”。
6.1. 检查自定义角色架构
Overcloud 创建流程利用包含角色数据的模板来定义其角色。默认模板位于 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml，定义所有默认角色类型： Controller、Compute、BlockStorage、ObjectStorage 和 CephStorage。
如果创建自定义 roles_data.yaml 文件，则 Controller 角色必须始终是定义的第一个角色。此角色被视为主要角色。
每个角色都包含以下参数：
- name
-
（必需） 角色的名称，这是没有空格或特殊字符的纯文本名称。检查所选名称不会导致与其他资源冲突。例如，使用
Networker作为名称而不是Network。有关角色名称的建议，请参阅 第 6.9 节 “Service Architecture: Split Controller”。 - CountDefault
- （可选） 定义要为此角色部署的默认节点数量。
- HostnameFormatDefault
（可选） 定义角色的默认主机名格式。默认命名规则使用以下格式：
[STACK NAME]-[ROLE NAME]-[NODE ID]
例如，默认的 Controller 节点被命名：
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...
- ServicesDefault
- （可选） 定义节点上要包含的默认服务列表。如需更多信息，请参阅 第 6.2 节 “检查可组合服务架构”。
这些选项提供了创建新角色并定义要包含哪些服务的方法。
openstack overcloud deploy 命令将 roles_data.yaml 文件中的参数集成到 overcloud.j2.yaml Heat 模板。在某些点上，overcloud.j2.yaml Heat 模板迭代 roles_data.yaml 中的角色列表，并创建特定于各个角色的参数和资源。
例如，overcloud.j2.yaml Heat 模板中每个角色的资源定义显示为以下代码片段：
{{role.name}}:
type: OS::Heat::ResourceGroup
depends_on: Networks
properties:
count: {get_param: {{role.name}}Count}
removal_policies: {get_param: {{role.name}}RemovalPolicies}
resource_def:
type: OS::TripleO::{{role.name}}
properties:
CloudDomain: {get_param: CloudDomain}
ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...
此代码片段演示了基于 Jinja2 的模板如何包含 {{role.name}} 变量，将各个角色的名称定义为 OS::Heat::ResourceGroup 资源。这依次使用 roles_data.yaml 中的每个 name 参数来命名每个对应的 OS::Heat::ResourceGroup 资源。
