4.2. Operator 企业拓扑

下图显示了红帽已经测试过此部署模型的基础架构拓扑，供客户在自我管理 Ansible Automation Platform 时使用：

图 4.2. 基础架构拓扑图

以下基础架构拓扑描述了具有 3 个 master 节点和 2 个 worker 节点的 OpenShift 集群。

每个 OpenShift Worker 节点都根据以下组件要求进行测试：16 GB RAM、4 个 CPU、128 GB 本地磁盘和 3000 IOPS。

红帽已测试了以下配置来安装和运行 Red Hat Ansible Automation Platform：

Ansible Automation Platform 的性能特性和容量受到资源分配和配置的影响。使用 OpenShift 时，每个 Ansible Automation Platform 组件都部署为 pod。您可以为每个 pod 指定资源请求和限值。

使用 Ansible Automation Platform 自定义资源为 OpenShift 安装配置资源分配。每个可配置的项目都有默认设置。这些设置是本参考部署架构上下文中所使用的确切配置，假设环境由企业 IT 组织部署和管理，用于生产目的。

默认情况下，每个组件的部署会针对最小资源请求设置，但不会设置资源限值。OpenShift 仅调度带有可用资源请求的 pod，但 pod 允许消耗无限的 RAM 或 CPU，只要 OpenShift 工作程序节点本身不在节点压力下。

在 Operator 企业拓扑中，Ansible Automation Platform 部署到带有 2 t3.xlarge worker 节点的 Red Hat OpenShift on AWS (ROSA) Hosted Control Plane (HCP)集群，在单个 AWS 区域内分布在 2 个 AZ 中。这并不是一个共享的环境，因此 Ansible Automation Platform pod 可以完全访问 ROSA HCP 集群的所有计算资源。在这种情况下，自动化控制器任务 pod 的容量计算派生自运行 pod 的底层 HCP worker 节点。它无法访问整个节点的 CPU 或内存资源。此容量计算会影响自动化控制器可以运行的并发作业数量。

OpenShift 管理与虚拟机不同的存储。这会影响自动化中心存储其工件的方式。在 Operator 企业拓扑中，我们使用 S3 存储，因为自动化中心需要一个 ReadWriteMany 类型存储，这不是 OpenShift 中的默认存储类型。外部为自动化中心提供 Redis、PostgreSQL 和对象存储。这为 Ansible Automation Platform 部署提供了额外的可扩展性和可靠性功能，包括特殊的备份、恢复以及复制服务和可扩展存储。

Red Hat Ansible Automation Platform 使用多个端口与其服务进行通信。这些端口必须处于打开状态，并可用于 Red Hat Ansible Automation Platform 服务器的传入连接，以便它正常工作。确保这些端口可用，且服务器防火墙不会阻止。