可以使用这些 SaltStack Config 系统要求确定您的系统可提供的支持。
Salt 支持的操作系统
SaltStack Config 在 Salt 上运行，Salt 是一个开源自动化和配置管理引擎。要开始使用 SaltStack Config 进行配置管理，还需要在打算使用 SaltStack Config 进行管理的任何节点上安装和运行 Salt 工作节点服务。
Salt 本身设计为与操作系统无关，可以管理大多数标准操作系统的节点。有关支持的 Salt 操作系统列表，请参见 Salt 平台支持。
SaltStack Config 支持的操作系统
SaltStack Config 的架构经过精心设计，适合在以下任一操作系统上运行：
- RedHat 7.4 - 7.9 (RHEL 7)
- CentOS 7 (CentOS7)
如果您的 RHEL 7 版本低于 7.4，则必须先将 OpenSSL 版本更新到 1.0.2k，然后再运行安装脚本。如果无法通过 Yum 更新获得此版本，或者您的服务器无法直接访问 Internet，请从 RedHat 或首选公共镜像检索以下软件包：
- openssl-1.0.2k-12.el7.x86_64.rpm
- openssl-libs-1.0.2k-12.el7.x86_64.rpm
确定工作节点架构
在 SaltStack Config 环境中，工作节点通常是指生产环境中通过一个或多个 Salt 主节点与 SaltStack Config 连接并由其管理的节点。
Salt 的设计目标是与可能在工作节点上运行的任何操作系统配合使用。除了标准操作系统（Linux、Windows、MacOS）之外，Salt 还为各种网络设备特有的操作系统（如 Arista、Juniper、AIX 和 Solaris）提供了专用工作节点软件（通常称为“原生工作节点”）。
下表按操作系统列出了 Salt 工作节点服务的最低内存要求：
| 操作系统 | 最低内存要求 |
|---|---|
| AIX 工作节点 | 512 MB RAM |
| MacOS 工作节点 | 4 GB RAM |
| Linux 工作节点 | 512 MB RAM |
| Windows 工作节点 | 4 GB RAM |
| 其他网络设备，包括代理工作节点 | 每个受控设备 40 MB RAM |
估算 Salt 主节点和工作节点数
尽管在安装之前很难衡量系统的吞吐量，但是可以根据系统中将由 SaltStack Config 管理的工作节点（节点）数来估算需求。本指南的最后一部分介绍了用于确定系统吞吐量的其他衡量方法。
随着 SaltStack Config 管理的 Salt 工作节点数增加，可能需要增加系统架构才能匹配。
下表列出了根据系统中管理的 Salt 工作节点（节点）数，可能需要的建议的 Salt 主节点数：
| 工作节点 | Salt 主节点数（16 个 CPU/16 GB） |
|---|---|
| 5,000 | 1 |
| 10,000 | 2 |
| 15,000 | 3 |
| 20,000 | 4 |
| 25,000 | 5 |
| 30,000 | 6 |
| 35,000 | 7 |
| 40,000 | 8 |
| 45,000 | 9 |
| 50,000 | 10 |
| 55,000 | 11 |
| 60,000 | 12 |
| 65,000 | 13 |
| 70,000 | 14 |
| 75,000 | 15 |
| 80,000 | 16 |
| 85,000 | 17 |
| 90,000 | 18 |
| 95,000 | 19 |
| 100,000 | 20 |
估算所需的 RaaS 节点数
下表列出了根据系统中管理的 Salt 工作节点（节点）数，可能需要的建议的 RaaS 节点数：
| 工作节点 | RaaS 节点数（16 个 CPU/16 GB） | RaaS 节点数（32 个 CPU/32 GB） |
|---|---|---|
| 5,000 | 1 | |
| 10,000 | 1 | |
| 15,000 | 1 | |
| 20,000 | 1 | |
| 25,000 | 2 | |
| 30,000 | 2 | |
| 35,000 | 2 | |
| 40,000 | 2 | |
| 45,000 | 1 | 1 |
| 50,000 | 1 | 1 |
| 55,000 | 1 | 1 |
| 60,000 | 1 | 1 |
| 65,000 | 2 | |
| 70,000 | 2 | |
| 75,000 | 2 | |
| 80,000 | 2 | |
| 85,000 | 1 | 2 |
| 90,000 | 1 | 2 |
| 95,000 | 1 | 2 |
| 100,000 | 1 | 2 |
估算所需的 PostgreSQL 节点数
接下来的两个表列出了根据系统中管理的 Salt 工作节点（节点）数，可能需要的建议的 PostgreSQL 数据库节点数：
| 工作节点 | PostgreSQL 节点数（8 个 CPU/8 GB） | PostgreSQL 节点数（16 个 CPU/16 GB） | PostgreSQL 节点数（24 个 CPU/24 GB） | PostgreSQL 节点数（32 个 CPU/32 GB） |
|---|---|---|---|---|
| 5,000 | 1 | |||
| 10,000 | 1 | |||
| 15,000 | 1 | |||
| 20,000 | 1 | |||
| 25,000 | 1 | |||
| 30,000 | 1 | |||
| 35,000 | 1 | |||
| 40,000 | 1 | |||
| 45,000 | 1 | |||
| 50,000 | 1 | |||
| 55,000 | 1 | |||
| 60,000 | 1 |
| 工作节点 | PostgreSQL 节点数（48 个 CPU/48 GB） | PostgreSQL 节点数（56 个 CPU/56 GB） | PostgreSQL 节点数（64 个 CPU/64 GB） |
|---|---|---|---|
| 65,000 | 1 | ||
| 70,000 | 1 | ||
| 75,000 | 1 | ||
| 80,000 | 1 | ||
| 85,000 | 1 | ||
| 90,000 | 1 | ||
| 95,000 | 1 | ||
| 100,000 | 1 |
估算所需的 Redis 节点数
接下来的两个表列出了根据系统中管理的 Salt 工作节点（节点）数，可能需要的建议的 Redis 数据库节点数：
| 工作节点 | Redis 节点数（4 个 CPU/4 GB） | Redis 节点数（8 个 CPU/8 GB） | Redis 节点数（12 个 CPU/12 GB） |
|---|---|---|---|
| 5,000 | 1 | ||
| 10,000 | 1 | ||
| 15,000 | 1 | ||
| 20,000 | 1 | ||
| 25,000 | 1 | ||
| 30,000 | 1 | ||
| 35,000 | 1 | ||
| 40,000 | 1 | ||
| 45,000 | 1 | ||
| 50,000 | 1 | ||
| 55,000 | 1 | ||
| 60,000 | 1 |
| 工作节点 | Redis 节点数（16 个 CPU/16 GB） | Redis 节点数（20 个 CPU/20 GB） |
|---|---|---|
| 65,000 | 1 | |
| 70,000 | 1 | |
| 75,000 | 1 | |
| 80,000 | 1 | |
| 85,000 | 1 | |
| 90,000 | 1 | |
| 95,000 | 1 | |
| 100,000 | 1 |
安装后根据吞吐量优化架构
完成 SaltStack Config 安装后，可以使用系统监控衡量指标更准确地确定系统吞吐量和架构需求。
确定要监控的内容时，请考虑以下因素：
- 事件系统上的流量 - 事件系统（有时也称为“事件总线”）用于 Salt 主节点和 Salt 工作节点的进程间通信。如果事件总线非常繁忙，请考虑增加内存分配。
- 每小时作业返回数据 - SaltStack Config 使用术语“作业”来指代 SaltStack Config 执行的每个命令、任务和操作。每个作业都会将其输出发送到 SaltStack Config，用于报告和数据收集目的。系统在给定小时内生成的作业返回数据量可能会影响架构需求。
- pillar 数据量 - Pillar 数据是必须存储在 Salt 主节点上的数据。Pillar 主要用于存储密钥或其他高度敏感的数据，例如帐户凭据、加密密钥或密码。Pillar 也可用于存储不希望直接放在状态文件中的非机密数据（如配置数据）。Salt 主节点上存储的数据量（稍后由工作节点根据需要访问）可能会影响内存和数据存储需求。
- 自定义颗粒量 - 颗粒在 Salt 中用于确定特定作业或命令的目标工作节点。颗粒是指每个工作节点的基本数据和特性。Salt 附带许多预构建颗粒。例如，可以按工作节点的操作系统、域名、IP 地址、内核、内存和许多其他系统属性确定目标工作节点。此外，还可以创建自定义 Grain 数据，以便根据您在系统中特别针对的目标特性区分不同的工作节点组。您创建的自定义颗粒数量可能会影响架构需求。
- 信标和反应器数 - 信标系统是一种监控工具，可以侦听 Salt 工作节点上的各个系统进程。信标可以触发反应器，然后反应器帮助实施更改或对问题进行故障排除。例如，如果某个服务的响应超时，则反应器系统可以重新启动该服务。当与反应器结合使用时，信标可以创建对基础架构和应用程序问题的自动预写响应。反应器使用预写修复状态对 Salt 进行了扩展，使其可自动响应。如果您的系统具有定期激活的信标和反应器，可能会增加系统架构需求。
- 磁盘大小需求 - 可能需要根据管理的工作节点数以及每年需要保留在存储中的数据量增加磁盘大小。例如，如果您有一个高吞吐量系统，并且您的系统位于严格监管的行业（需要保留 7-8 年的数据）中，则可能需要更大的磁盘大小和存储容量。
- 组件之间的地理位置和距离 - 如果 Salt 主节点与运行 SaltStack Config (RaaS) 的服务器之间存在 65 毫秒或更长的延迟，则可能会遇到问题。所幸的是，Salt 对 Salt 工作节点与 Salt 主节点之间的延迟不太敏感。放置这些组件时，请记住，最好将主节点放在靠近 RaaS 的位置，如果需要，将工作节点放在远离 RaaS 的位置。
- 关键业务运维 - 评估 SaltStack Config 在环境中的业务关键性时，自问 SaltStack Config 中断对业务造成影响的严重性。如果停机一小时或更长时间，是否会造成严重影响？如果会，则可能需要在 SaltStack Config 系统架构中设计高可用性需求。
根据这些因素，请考虑以增量方式增加资源并监控对系统性能的影响。例如，以 4 GB RAM 和 4 个 CPU 为增量增加内存分配。
下图显示了高可用性 SaltStack Config 架构设计示例：
正如此图所示，许多高可用性系统连接到多个 Salt 主节点。可用性系统通常还会在 PostgreSQL 数据库和 Redis 数据库中构建冗余，以便一个数据库可以故障切换到另一个数据库。请记住，PostgreSQL 和 Redis 的当前高可用性解决方案仅支持手动故障切换。
