苏宁海量服务器自动化配置运维实践

会员服务 ·

苏宁海量服务器自动化配置运维实践

2018 年 11 月 8 日 高效开发运维

随着业务量的上升，服务器本身的标准化扫描，内核批量升级，在备战双 11 大促时，运维会接入大量系统扩容，配置，全局变量设定等等操作也逐渐变得常态化，动辄上千台的主机运维的工作已经不是通过堡垒机系统就可以轻松完成了。

运维的演进

人力运维阶段

在 IT 产业的早期，服务器运维是通过各种 Ad Hoc 命令或者 Shell 脚本来完成基础设施的自动化工作，这种方式对于简单，一次性的工作很方便，但是对于复杂和长期的项目，后期的脚本维护非常麻烦。

自动化工具阶段

现时的大型互联网公司都已经有了成千上万台服务器，对于这么庞大体量的服务器规模，以往那种原始的人工运维方式显然已经过时，大规模服务器的自动化快速运维就成为了不得不探讨的课题。

目前 Salt,Chef,Puppet 和 Ansible 等配置管理工具是运维界非常流行的工具，它们定义了各自的语法规则来管理服务器，这些工具定义的代码和 Ad Hoc 脚本语言非常相似，但是它们强制要求代码具有结构化，一致性，和清晰的参数命名，它们能够远程管理大量的服务器，并且兼容早期的 Ad hoc 脚本。

DevOPS 阶段

随着自动化维护的相关工具层出不穷，有些大公司已经把它上升到了战略层面，并引入了各种各样的自动化工具与自己的业务系统进行组装。

自动化运维平台 ACM 平台的建设

从传统业务转型互联网的苏宁随着业务量的上升，服务器本身的标准化扫描，内核批量升级，在备战双 11 大促时，运维会接入大量系统扩容，配置，全局变量设定等等操作也逐渐变得常态化，动辄上千台的主机运维的工作已经不是通过堡垒机系统就可以轻松完成了。

并且随着不断有 PAAS 业务系统提出需要各种可定制化，标准化的服务器配置管理部署接口。开发一个可以批量化配置管理服务器的通用平台就变得迫切起来。

底层工具的选取

目前市场上最主流的开源工具有 Puppet/Chef/Ansible/Saltstack 四种，选型时在 github 的热度排名如下：

而在实际开发的选取时优先会考虑以下两点：

第一、语言的选择（Puppet/Chef vs Ansible/Saltstack）Puppet、Chef 基于 Ruby 开发，Ansible、Saltstack 基于 Python（后期可做二次开发），所以抛弃较为老旧并且兼容性较差的 Puppet 和 Chef
第二、速度的选择 (Ansible vs Saltstack)运维的配置管理讲究的是更快更稳，Ansible 基于 SSH 协议传输数据，Saltstack 使用消息队列 zeroMQ 传输数据。

在 Ansible、Saltstack 的选择中，有一些公司放弃 Saltstack 的主要原因是 Saltstack 需要安装客户端，在服务器有一定数量的情况下比较麻烦，而 Ansible 不需要安装客户端。但是目前的 Ansible 还存在以下难以解决的问题：

众口难调：和业务特点相关的需求十分离散（有的重效率，有的看重流程的完备性，有的对易用性要求高）再加上需求方越来越多，没有合适的通用开放性接口提供 restful API，功能交付的排队会积压严重。
性能差：当需要执行一个服务器数量级达到 K 级操作，Ansible 的响应长达数十分钟，并且还有比较高的错误率。

反观 SaltStack，它结合轻量级消息队列（ZeroMQ）与 Python 第三方模块构建。具备了配置管理、远程执行、监控等功能，具有以下明显的优势：

速度极快
兼容性好
文档详细，并且开源社区跟 Ansible 一样持续活跃

速度测试

从表格中可以看出 Ansible 和 SaltStack 性能测试中，测试了 Ansible 和 SaltStack 在执行命令、分发文件、读取文件和批量脚本执行等自动化运维场景下的性能，由耗时数据可以看出 Ansible 的响应速度比 SaltStack 要慢 10 倍左右。

经过的综合论证考量，最终选择了在大规模集群下，适用性最强的 SaltStack 作为苏宁所有服务器的基础管理工具。

使用稳定性的维护

由于早期版本的 Saltstack 的稳定性不高，各种版本之间也有兼容性问题，为了保证版本升级时保持可以向下兼容，团队进行大量的验证和测试后会把发现的 bug 向社区报告，经过不断的沟通与协商，最终得到社区的认可并接受我们提出的修改建议，目前团队也积极的参与新版本 Salt 的检证测试与维护，有力的保障底层平台的稳定性。

通用外部接口及 WEB 平台的建设

由于 Saltstack 社区并没有提供 WEB 管理界面，所有的操作都只能通过命令行操作，而 API 的调用也会暴露出用户名密码给外部系统，Master 的安全性得不到保障。并且脚本的维护升级都十分的麻烦。

所以在选定底层管理工具后还需要开发一套 ACM 上层平台，包装出通用的接口对外提供服务，并且提供可视化的操作界面提供给主机运维团队。

ACM 提供了一套 WEB 系统供运维管理人员进行可视化的运维管理。实现了页面化的脚本工具定义, 作业编排，作业执行，命令执行，报表分析等功能。

外部系统则可以通过 ACM 开放的 API 接口实现对底层 Salt 的调用，从而实现对安装有 Salt Minion Agent 的机器进行配置管理。

并且在安全的设计上，平台提供审计，命令黑名单，通道管理，Agent 配置、用户角色权限管理，并且仅允许授权过的外部系统接入 ACM。

系统架构的演进

架构 1.0

早期采用 Order Master + Syndic+Minion 的三层架构模式，当时全苏宁的 OS 虚机 + 物理服务器总数大概在 1 万左右，Salt 的原生架构还能勉强支撑。

但随着集团转型的持续进行，线上业务量的急速上升，大促前上线的服务器数量也以近乎每天一千台的速度上升，接入 ACM 的系统也从仅有的两三个，每天几百个总请求量，快速上升到几十个系统，一天有近万个配置任务；此时系统的问题也逐步暴露出来，比如任务返回慢，一个同步任务执行需要 5 秒以上的调用时间；原生架构下 Order Master 在并发任务量大时，系统压力过高，任务失败率也超过 10%。

团队每天都花费大量时间应对客户苦不堪言，业务方也是经常提出抱怨，由于业务量提升的倒逼，Salt-Minion 又是集团默认的唯一基础运维 Agent，除了我们没有人可以承担下自动化配置管理的工作。于是乎 ACM 进行了整个系统的重新设计。

架构 2.0- 两层化拆分

经过反复研究跟论证，ACM 可以改造成直接充当 Order Master 的角色，对服务器发起配置任务时，ACM 可以通过安装记录直接查询到 Minion 挂载在哪台 Master 上，直接对需要的 Master 发起调用，任务如果是多台机器，后期也通过 ACM 进行结果的聚合。

由于 ACM 本身就是 JBoss 集群，这样做不仅解决了单台 Order Maser 负担太重的问题，还大大加快了请求的响应时间，从原来的五秒 + 响应提升到了毫秒级响应，解决了原生架构中官方必须开销的 Syndic 等待时间。

架构 2.1-Salt Master 的高可用化

在实际生产环境中如果发生了某一台 Salt Master 宕机的情况，就会有约 2K 的机器失去控制，人工的进行 Master 恢复长达几十分钟，对于一些业务的调用是不可以接受的。

所以 Master 迫切的需要进行高可用化的改造，而改造的过程中又需要解决以下几个问题：

Minion 如何探测到 Master 宕机，并进行快速切换。
当 Minion 探测到主 Master 宕机后如何切换到备 Master。
如何解决主备 Master 之间 Salt-key 复制的问题，尤其是当主 Master 关联新的 Minion，新 Minion 的 Salt-key 如何同步给备 Master。

方案 1

采用 Saltstack 原生的高可用方案，Mutil-Master+Failover-Minion。

Mutil-Master: Saltstack 从 0.16.0 版本开始支持，提供 Minion 可以连接多 Master 的功能特性.
Failover-Minion: Minion 定期检测 Master 的可用性，当发现 Master 不可用时，则在一定时间切换到备用 Master 上。

主要的配置项如下：

# multi-Master
Master:    
    - 10.27.135.188
    - 10.27.135.189
# 设置为 failover Minion  
Master_type: failover  
# 探测 Master 的间隔，单位为秒
Master_alive_interval: <seconds>

该方案的优点是基于 SaltStack 原生的高可用支持，不需别的组合方案进行支撑，理论上可以实现 Master 的高可用，但是经过实际的验证和测试，存在一些明显的不足：

Minon 在启动的时候会随机连接一台 Master，假如此时连接的 Master 恰好宕机，Minion 不会再随机选择另外一台 Master，从而导致连接失败的情况。
Minion 检测间隔，根据 Master_alive_interval 的设置时间，Minion 会主动对现有的 Master 进行 TCP 连接一次检查，查看 Master 是否响应。如果探测间隔设置过长，则可能影响到切换的时效；如果探测间隔设置过短，在大规模服务器场景下，则在短时间内产生过多的网络请求，对 Master 主机以及网络带宽产生巨大冲击，相当于一次 DDOS 攻击。
假如需要更换 Master 的 IP 或者追加新的 Master 的 IP，则需要对该 Master 下的所有的 Minon 进行配置变更，更恐怖的是 Minion 需要重启才能生效。
Salt-key 同步没有提供解决方案。

方案 2

经过不停实验，发现 Master 可以通过由 Keepalived 维护的 VIP 对外提供 Salt 服务，平时 VIP 绑定在主 Master，当主 Master 宕机时 VIP 漂移至备 Master，主备 Master 通过 lsyncd 共享 Salt-key 文件。

注：Keepalived 软件主要是通过 VRRP 协议实现高可用功能的。VRRP 是 Virtual Router RedundancyProtocol(虚拟路由器冗余协议）的缩写，VRRP 出现的目的就是为了解决静态路由单点故障问题的，它能够保证当个别节点宕机时，整个网络可以不间断地运行。

所以，Keepalived 一方面具有配置管理 LVS 的功能，同时还具有对 LVS 下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。

在实际运行时，Minion 会主动向 Master（VIP）发起注册，每 5 分钟检测一次跟 Master 的 TCP 连接，如果连接被冲断则重新发起 TCP 握手，建立 TCP 长连接；当主 Master 发生宕机，Keepalived 检测到后将 VIP 漂移至备用 Master，Minion 最多在 5 分钟后将向备用 Master 的 VIP 发起 TCP 连接请求，并重新挂起长连接，等待 Master 发起任务。

该方案的需要安装额外的软件对高可用进行支撑，由 Keepalived 对 Master 进行宕机检测，由 lsyncd 保证 Salt-key 的实时同步。这样做的好处是可以避免的方案 1 的诸多不足。首先，Minion 端识别到的是虚拟的 Master 的 IP 地址，所以 Master 底层的 IP 地址的变化对 Minion 端是无感知的，Minion 既不需要更改配置也不需要重启；其次，Keepalived 的检活机制是对本网段内的 D 类地址进行检测，并设置了唯一的虚拟路由 ID，检测间隔控制在 5 秒以内，所以不会对集团网络造成冲击；最后由 lsyncd 对 Salt-key 进行同步，既保证了安全性，又避免了多个 Master 之间 Salt-key 同步的问题。

至此，通过以上的混合解决方案，成功的实现的 Salt Master 宕机自检测自动迁移的高可用方案，目前新港环境下的服务器已经全部由采用高可用架构的 Salt 集群接管。