(国网江苏省电力公司信息通信分公司 210024；江苏电力信息技术有限公司 210029)
摘要：针对电网规模的不断发展，自动化运维体系的不断扩大，对运维架构的稳定性提出了更高的要求。本文基于saltstack结构的运行模式的描述，对日常运维中可能出现的隐患予以分析，总结出一套适用于电力企业自动化运维高可用的架构建设方案，提高运维工作的保障性和安全性。
关键字：电力 自动化 saltstack 高可用
1.引言
互联网推动了信息时代的高速发展。中大型公司尤其是电力企业，其内部建设的设备、网络、存储、应用越来越多、越来越复杂，以适应信息时代的高速发展。这种大规模、高复杂的设施建设也导致人工方式已经无法应对，于是自动化运维方式是必然的而且是急迫的。
自动化运维的实现需要依据企业具体的业务、网络布局等关键因素，根据特定的场景制定运维架构。目前比较流行的开源架构众多，包括puppet、zabbix、saltstack等，本文主要针对saltstack运维架构进行描述。Saltstack基于C-S架构，运维内容几乎满足全部的日常需求，也提供拓展API来定制运维功能。
在实际saltstack架构使用过程中，saltstack表现出不俗的运维性能。但是对于日益复杂的运维场景，也表现出一定程度的不足。本文将对运维过程中可能出现的问题进行描述，进而构建一套完善的运维架构，以期达到“零延时”的运维理念。
2.saltstack架构存在的问题
2.1.saltstack简介
saltstack开源项目起源于2011年，是相对较新的项目，但在系统管理员和DevOps工程师大受欢迎。
saltstack使用c-s架构完成对客户机的控制，通过zeromq消息队列来处理master和minion端的通信过程，通过key认证来保障客户机的合法性。构建分布式远程执行系统，用于在远端节点执行命令。拥有灵活的目标指向机制，比如可以按照客户机的操作系统分类来执行任务等。拥有丰富的模块，满足日常运维的基本需求，也可以通过拓展模块来自定义所需的功能模块
2.2.存在的问题
（1）稳定性
自动化运维的目标在于通过自动化替代人工方式，实现“零延时”的高效运维理念。稳定性是其基本要求，只有运维架构趋于稳定才能确保运维工作的持续有效，否则自动化运维则失去了其本身存在的意义，反而增加了运维成本开销。
电力企业运维模式下，所涉及的运维目标规模庞大，且并行度要求极高。对新型运维架构的稳定性提出了严苛的要求。
随着越来越多的设备接入，Saltstack的单个master承载的压力会越来越大，对运维架构稳定性是极大的隐患。
（2）可伸缩性
设备淘汰与扩增是电力企业必然存在的现象，旧机器会由于设备陈旧的物理原因、业务下线的软件原因等因素被淘汰，新设备会由于扩容、替换等因素加入到运维目标中。
新设备的接入和旧设备的移除对运维架构的可伸缩性提出了要求。自动化运维架构必须自动的或尽量少手工的解决这种场景下的运维工作，提升运维效率。
3.Saltstack高可用性架构研究
本节将对saltstack官方架构进行实践，并结合电力企业实际运维模式，总结出一套适合于电力企业的、完善的自动化运维架构。
3.1.Multimaster架构
在multimaster架构下，多个master通过统一其公钥和私钥的方式同时控制一个minion群组，每个master都可以向minion发送指令达到远程控制的目的。
这种架构方式一定程度上可以保障master的可靠性，当其中一个master无法工作时，另外的master也可以不受影响继续实施运维过程。但实际上这种架构，不能减轻master的压力，随着minion节点的越来越多，master本身的压力也会愈发严重。因此此架构无法从根本上避免master可能会由于压力过大而产生的稳定性问题。
期刊文章分类查询,尽在期刊图书馆
3.2.Syndic架构
Syndic是介于master和minion之间的一种类型。对于master节点来说，它属于minion类型，接收并处理master发出的指令；对于minion节点来说，它属于master类型，可以向minion发送指令。在syndic架构模式(以两个syndic节点为例)下，将控制目标minion集群分隔成几个部分，每个syndic-master仅控制其下的一部分minion。
相较于multimaster架构，把集中型的压力化整为零，分摊到多个syndic节点上，可以有效避免因minion数目过多而可能引发的master压力过载的问题。
由于master_of_master节点过于单薄，没有合理的容灾机制，容易发生单点故障。当该节点发生问题，整个架构将不可用。此时考虑结合multimaster架构，将syndic架构改造，在syndic架构的基础上，对master_of_master节点使用multimaster架构模式来保障该节点的稳定运转。
该架构可以基本满足自动化运维对于saltstack提出的稳定性和可扩展性要求，但是额外引入了syndic概念，提高了运维复杂性。因为最上层master_of_master节点只能感知syndic节点的存在，但无法感知其下真正的运维目标minion群体，对于运维平台的建设来说，必须处理syndic和master之间的信息同步问题，增加了代码逻辑复杂度。
3.3.构建高可用的易用性运维框架
通过上文对salt基本架构的实践与研究，尝试构建一套完善的salt运维架构，从稳定性的角度保障运维过程的顺利实施。
Saltstack结构稳定性有两个基本要求：一是minion数目众多，master的压力应能够均衡到多个节点；二是结构应尽可能简单，保证自动化运维平台的快速实现，消除复杂性在一定程度上也是保证稳定性的有效途径。
本文将尝试建立saltstack高可用性自动化运维架构，先使用自定义调度系统管控master，利用multimaster模式保障master节点的单点故障，通过编排管理控制接入minion的数目，每组master设置允许接入的minion数目的最大值。当达到该组master接入minion数目最大值时，minion将被安排接入到其他Master组中。
在此种架构应用过程中，对于单个master而言，其压力始终控制在预定规模下，可以避免因minion接入数量过多导致master发生性能或稳定性方面的问题。新的minion端接入时，编排系统将会判断当前master上的已接入数量，自动调度minion将接入哪个master，达到自动扩展的目的。
此种架构实现过程中，自定义调度系统应作为自动化运维平台建设的一部分。针对自定义调度系统，其功能必须包含：
a)Master的健康度检查
Master节点或因物理、软件、网络等原因处于不可用状态，当这种故障发生时，用户应该能感知，并且自动化运维工作将自动转至其余master节点继续进行。
b)应能够达到负载均衡效果。
由于采用了multi-master架构，多个master可以同时控制一组minion群体。自定义调度系统应能判断当前master的负载，根据可配置的调度策略选择合适的master进行命令下发。调度策略的配置可以包含：任务数目，任务复杂性、任务优先级等因素。
c)自定义调度系统应与运维平台业务逻辑松耦合
自定义调度系统的实现应脱离自动化运维平台的业务逻辑，实现为对salt架构的一种上层包装，甚至实现为驱动插件形式。业务体系可以兼容多种salt驱动插件，满足不同的调度需求。
4.结论
自动化运维工作的建设对中大型企业的正常运转至关重要。本文针对基于saltstack运维过程可能产生的问题进行描述，对saltstack基础运维架构进行实践，总结出一套适用于电力企业，稳定的、可扩展的自动化运维架构，并对其具体实现进行研究，以期达到真正高效运维的目的。
参考文献：
[1]saltstack社区Salt-2016.11.2.pdfsaltstack官方文档2016年11月
[2]余洪春linux集群和自动化运维 机械工业出版社 2016年8月
[3]吴文豪 自动化运维软件设计实战 电子工业出版社
论文作者:宋浒,邹昊东,李凤强,章路进,贺敬伟
论文发表刊物:《电力设备》2017年第21期
论文发表时间:2017/11/16
标签：架构论文; 节点论文; 稳定性论文; 自定义论文; 压力论文; 电力企业论文; 目的论文; 《电力设备》2017年第21期论文;