安装 SaltStack Config 所需的系统架构取决于两个主要因素:1) 用于部署 SaltStack Config 的安装方法和 2) 环境的吞吐量,即将使用 SaltStack Config 在系统上执行的工作量。

开始前

为了准确评估系统架构需求,应首先确保熟悉以下内容:

  • 可用于 SaltStack Config 的两种安装方法
  • SaltStack Config SaltStack 架构的四个基本组件(RaaS、Salt 主节点、PostgreSQL 和 Redis)

请参见安装并配置 SaltStack Config,大概了解这些概念,包括安装过程综述。另请参见应使用哪种安装方案?,获取选择安装方案的指导。

注:

SaltStack Config 由 Salt 提供支持,Salt 是一个开源自动化和配置管理引擎。如果您不太熟悉 Salt 中使用的关键术语(如 Salt 主节点和 Salt 工作节点),请参见 Salt 系统架构了解详细信息。

确定工作节点架构

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

确定安装方案

有关选择安装方案的指导,请参见应使用哪种安装方案?。如果您不确定哪种安装方法最适合您的系统,建议采用标准安装。对于具有 1,000 多个节点的生产级系统,不建议使用 Lifecycle Manager 安装方法。

如果选择Lifecycle Manager安装,则只需要一个节点,并且需要以下系统架构:

硬件 最多 1,000 个节点(工作节点)
内核 8 个 CPU 内核
RAM 16 GB RAM
磁盘空间 至少 40 GB 的可用空间

本指南后续部分将介绍标准安装方案的架构需求。

估算要管理的 Salt 工作节点数

尽管在安装之前很难衡量系统的吞吐量,但是可以根据系统中将由 SaltStack Config 管理的工作节点(节点)数来估算需求。本指南的最后一部分介绍了用于确定系统吞吐量的其他衡量方法。

随着 SaltStack Config 管理的 Salt 工作节点数增加,可能需要增加系统架构才能匹配。

估算所需的 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
注:

本文介绍 SaltStack Config 内部部署架构。SaltStack Config 云当前只能运行一个 Salt 主节点,这意味着工作节点数不能超过 20,000 个。

估算所需的 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 架构设计示例:

此图说明了高可用性系统的外观:vRA UI 连接到 RaaS 服务器,该服务器控制多个 Salt 主节点,每个主节点具有多个工作节点。

正如此图所示,许多高可用性系统连接到多个 Salt 主节点。高可用性系统通常还会在 PostgreSQL 数据库和 Redis 数据库中建立冗余,以便一个数据库可以故障切换到另一个数据库。请记住,PostgreSQL 和 Redis 的当前高可用性解决方案仅支持手动故障切换。