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

运维的演进

人力运维阶段

在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-MasterMaster:        - 10.27.135.188    - 10.27.135.189# 设置为failover Minion  Master_type: failover  # 探测Master的间隔，单位为秒Master_alive_interval: \u0026lt;seconds\u0026gt;

$\"\"$

该方案的优点是基于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集群接管。

$\"\"$