7. 集群¶

集群在主机间共享负载。每个实例都应当能够作为 UI 和 API 访问的入口点。这可以让 Tower 管理员在尽可能多的实例中使用负载均衡器，并保持良好的数据可见性。

注解

负载均衡是可选的，可以完全根据需要在一个或多个实例上设有入口。

每个实例都应当能够加入 Tower 集群并扩展其执行作业的能力。这是一个简单的系统，作业可以并将会在任何位置运行，而不是定向在哪里运行。另外，集群实例可以被分组成不同的池/队列，称为实例组。

Tower 支持使用 OpenShift 的基于容器的集群，这意味着可在这个平台上安装新的 Tower 实例，无需更改或转变功能。但是，有某些 OpenShift 部署和配置差别必须进行考虑。您可以创建实例组来指向 Kubernetes 容器。更多详情，请参阅执行环境部分。

支持的操作系统：

支持以下操作系统来建立集群环境：

Red Hat Enterprise Linux 7 或更高版本（推荐使用 RHEL8，可以是 RHEL 7 或 centos 7 实例）

注解

在 OpenShift 中运行 Ansible Tower 不支持隔离的实例。

7.1. 设置注意事项¶

本节仅涵盖集群的初始设置。要升级现有集群，请参阅 Ansible Tower Upgrade and Migration Guide 的 Upgrade Planning。

新集群环境中需要注意的事项：

PostgreSQL 仍然是一个独立的实例，没有集群。Tower 不管理副本配置或数据库故障转移（如果配置了待机备份系统）。
当集群升级时，数据库节点应当是独立服务器，而 PostgreSQL 则不应安装到 Tower 的一个节点上。
一个集群最多支持 20 个实例。
所有实例都应能够从其他所有实例访问，并应能够访问数据库。另外，主机也必须拥有一个稳定的地址和/或主机名（取决于 Tower 主机的配置方式）。
所有实例都必须进行地理上的分配，实例间有可靠的低延迟连接。
为了升级到集群环境，您的主实例必须是清单中的 tower 组的一部分。*并且*它需要是 tower 组中列出的第一个主机。
用户必须手动将手动项目同步到所有实例，同时对所有实例进行更新。
在新的 Tower 系统中没有主 (primary)/从 (secondary) 系统的概念。所有系统都是主系统。
用于 Tower 部署的 inventory 文件应当被保存且有持久性。如果要置备新实例，则必须为安装程序提供密码和配置选项以及主机名。

7.2. 安装和配置¶

置备新实例涉及更新 inventory 文件并重新运行设置 (setup) playbook。务必确保 inventory 文件包含在安装集群时使用的所有密码和信息，或者其他实例可以重新配置。inventory 文件包括了一个单一的清单组 tower。

注解

所有实例都会负责各种与任务调度相关的托管任务，比如确定要启动的作业和处理 playbook 事件，以及定期清理。

[tower]
hostA
hostB
hostC

[instance_group_east]
hostB
hostC

[instance_group_west]
hostC
hostD

注解

如果没有为资源选择任何组，则使用 tower 组，但如果选择了组，则不会使用 tower 组。

database 组为指定外部 PostgreSQL 而保留。如果单独置备数据库主机，则该组应为空：

[tower]
hostA
hostB
hostC

[database]
hostDB

当 playbook 在集群中的单个 Tower 实例上运行时，该 playbook 的输出会作为基于 websocket 的流传输输出功能的一部分广播到所有其他节点。最好通过为清单中的每个节点指定一个私有可路由的地址来通过内部地址处理此数据广播：

[tower]
hostA routable_hostname=10.1.0.2
hostB routable_hostname=10.1.0.3
hostC routable_hostname=10.1.0.4

注解

Ansible Tower 的早期版本使用变量名称 rabbitmq_host。如果您是从以前的 Tower 版本进行升级，而您在清单中指定了 rabbitmq_host，请在升级前将 rabbitmq_host 重命名为 routable_hostname。

7.2.1. Tower 和 Automation Hub 使用的实例和端口¶

Tower 以及内部 Automation Hub 节点所需的端口和实例如下：

80、443（正常的 Tower 和 Automation Hub 端口）
22（SSH - 只需要入口流量）
5432（数据库实例 - 如果数据库安装在外部实例上，则需要对 tower 实例打开）

7.2.2. 可选 SSH 身份验证¶

对于希望通过 Tower 之外的一些系统（如使用外部管理的无密码 SSH 密钥）管理从"控制器"节点到"隔离"节点的 SSH 验证的用户，可运行取消置备命令： awx-manage remove_isolated_key 来禁用此行为。

7.3. 通过浏览器 API 报告状态和进行监控¶

Tower 自身通过 /api/v2/ping 处的可浏览 API 报告尽可能多的状态，以便提供集群健康状况验证，包括：

为 HTTP 请求提供服务的实例
集群中所有其他实例的最后一个心跳 (heartbeat) 的时间戳
这些组中的实例组和实例成员资格

查看关于实例和实例组的更多详细信息，包括 /api/v2/instances/ 和 /api/v2/instance_groups/ 处的正在运行的作业和成员资格信息。

7.4. 实例服务和故障行为¶

每个 Tower 实例由几个不同的服务组成，它们协调工作：

HTTP 服务 - 包括 Tower 应用本身以及外部 Web 服务。
回调接收器 - 从正在运行的 Ansible 作业接收作业事件。
分配程序 - 处理并运行所有作业的 worker 队列。
Redis - 此键值存储用作从 ansible-playbook 向应用程序传播的事件数据的队列。
Rsyslog - 用来向各种外部日志记录服务提供日志的日志处理服务。

Tower 配置为：如果任何这些服务或其组件故障，则所有服务将会重启。如果这些故障在较短的时间内频繁出现，则整个实例将自动变为离线，以便进行补救，避免造成意外行为。

要备份和恢复集群环境，请参考集群环境的备份和恢复部分。

7.5. 作业运行时行为¶

作业运行并报告给 Tower 的“常规”用户的方式不会改变。在系统端，需要注意一些差异：

当从 API 接口提交作业时，作业会被推送到分配程序队列中。每个 Tower 实例都将使用特定的调度算法连接该队列并从队列接收作业。集群中的任何实例都可能接收工作并执行作业。如果实例在执行任务时失败，则该工作标记为永久失败。

Tower Cluster example

项目更新在可能运行作业的任何实例上都可以成功运行。在运行作业前，项目会与实例上的正确版本同步。如果需要的修订版本已经在本地签出，并且不需要 galaxy 或集合更新，则无法执行同步。
当同步发生时，通过 launch_type = sync 和 job_type = run 在数据库中将其记录为项目更新。项目同步不会更改项目的状态或版本；相反，它*仅*在其运行的实例上更新源树。
如果需要从 Galaxy 或 Collections 进行更新，则会执行一个下载所需角色的同步，这将消耗您的 /tmp 文件中的更多空间。当您的项目较大时（大约 10 GB），/tmp 可能会导致磁盘空间的问题。

7.5.1. 作业运行¶

在默认情况下，当作业被提交到 tower 队列时，任何 worker 都可以选择它。但是，您可以控制某个特定作业的运行位置，例如限制在其上运行作业的实例。

为了支持暂时关闭某个实例的功能，在每个实例上定义了一个启用的属性。禁用这个属性时，不会为该实例分配任何作业。现有的作业将会完成，但不会分配新的工作。

7.6. 取消置备实例¶

重新运行设置 (setup) playbook 不会自动取消置备实例，因为集群目前不会区分有意关闭的实例与因故障而关闭的实例。而是，关闭 Tower 实例上的所有服务，然后从任何其他实例运行取消置备工具：

使用命令 ansible-tower-service stop 关闭实例或停止服务。
从另一个实例运行取消置备命令 $ awx-manage deprovision_instance --hostname=<name used in inventory file>，将其从 Tower 集群中删除。

示例：awx-manage deprovision_instance --hostname=hostB

同样，在 Tower 中取消置备实例组不会自动取消置备或删除实例组。如需了解更多信息，请参阅取消置备实例组部分。