"受管节点"如何被定义为 Red Hat Ansible Automation Platform 产品的一部分？

Red Hat Ansible Automation Platform 通过统计客户环境中"受管节点"数量来进行销售和支持。以下文章定义了受管节点是什么，以及围绕此概念的业务规则是什么。

注意：以下是从官方 Red Hat Enterprise 协议 ，特别是 附录 1、软件支持和订阅 中提取的。

按照上面的附录 1 ，"受管节点"定义如下：

Each Node managed by the Software. “Node” means a Virtual Node, Physical Node or other instance of software. 

此定义足够广泛，适用于所有红帽产品，但当适用于 Red Hat Ansible Automation Platform 时，受管节点是任何由 Red Hat Ansible Automation Platform 软件管理的"节点"。

"受管节点"指的是虚拟节点、物理节点或其他可识别的由 Red Hat Ansible Automation Platform 直接或间接管理的软件和/或配置的实例。

应该考虑的包括但不仅限于的受管节点的示例：

• 服务器、虚拟机和其他物理设备，如存储阵列

• 容器、设备、软件实例（数据库、中间件、应用程序）和其他虚拟设备

• SDN、无线和其他网络控制器

受管节点用例：

1. 对于通过 API 直接管理或间接管理的集群技术平台，受管集群中的每一个技术实例都算作受管节点。

2. 对于由 Ansible 直接管理的物理或虚拟实例，其中 Ansible 识别并连接到实例，每个实例将算作一个受管节点。

3. 对在 API 后面由 Ansible 间接管理的可识别的* 物理或虚拟实例，每个实例都算作一个受管节点

4. 对于通过 API 直接管理或管理的基础架构或应用程序软件实例，每个实例都算作一个受管节点。

"可识别"被定义为一个可能不被 Ansible 控制节点直接所知的受管节点，但根据说明，其通过中间管理控制器中的设备或实例名称被间接知道。

根据上述用例，Ansible 可以从多个不同访问路径管理节点。 如果这会导致 Ansible 清单中给定主机的多个主机标识符，则其不会增加客户所需的主机权利。也就是说，一个受管主机不会根据针对该主机的多个自动化操作或方法而被多次"计费"。

Ansible Automation Platform 用户可能不能管理超过授权的受管节点数量的全部资产。这方面的例子包括循环、轮转或其它通过 Ansible Tower/Automation 控制器软件以子部分增量方式，或通过删除或清理 Tower/控制器数据库中的数据，来拉取受管节点。