一、引言
随着业务的发展，越来越多的服务器需要配置管理。业界已有不少分布式配置管理服务的开源工具，例如奇虎360的Qconf，百度的disconf，淘宝的Diamond等。此类配置工具大多适用于文件配置，且配置内容高度一致的需求。对于IDC厂商来说，经常需要在服务器上创建虚拟网络接口，搭建隧道，配置路由，限制带宽等，同时要求即时生效，且设备的配置可能每台都不同。在这种场景下，上述开源配置文件管理工具就不是十分适合了。
针对以上问题，本文将会设计一种在IDC环境下，对于需要直接管理服务器设备，配置管理大量设备的方案。
二、方案架构
- WEB 端负责配置信息的输入和展示，例如各种隧道，接口，路由，链路带宽的配置信息管理。
- 服务端负责接收用户的配置请求，并将任务下发到目标设备上。
- 消息队列负责将配置消息下发给目标设备，并将目标设备返回的结果传递给服务端。选用消息队列的原因是，当前网络环境复杂，网络传输的可靠性不高，如果采用长连接的方式，很可能导致配置信息不可达，造成目标设备和服务端的配置不一致。
- 数据库负责保存配置信息，及配置状态。为了保证数据库的高可用，采用了主从方式。
- 在目标服务器上，装有Agent端，负责获取来自消息队列的配置指令，并执行，执行以后，将执行结果返回给消息对列。该Agent可以支持云主机集群和物理设备集群。为了防止单点故障，使用Zookeeper管理Agent集群，在一台设备出现故障，不能继续服务时，选举新的Agent，为整个集群继续提供服务。
接下来介绍下整个集群的工作流程：
- 用户首先在web控制台上配置目标设备；
- 服务端将配置信息存储在数据库中，并设置状态为待下发；
- 服务端轮询数据库，查看是否有待下发的任务；
- 将待下发的任务下发给消息队列，然后消息队列将任务传递给由Zookeeper 管理的集群；
- 集群中的Agent接收到任务后，执行相应操作，并返回执行状态/结果；
- 服务端收到底层Agent反馈的消息后，更新数据库；
- 前端web查询数据库，将最新状态展示给用户。
三、该方案的特点
从以上架构图可以看出，本架构耦合度非常低，组件之间通过消息中间件通信，各司其职，不感知整体架构。
值得一提的是，底层Agent 执行操作之后，返回状态成功与否的依据并不全是操作指令的执行结果，而是反应本次操作是否达成了目的。例如删除操作，如果要删除的组件在底层已经不存在，那么将会返回成功，而不是失败 。
采用服务端轮询的方式，仅对需要变更状态的配置进行下发，数据量不会很大，对于CPU和内存，以及消息队列都不会造成压力。
四、异常处理
现网的情况异常复杂，所以异常处理必不可少。
- 解决目标服务器集群单点故障的问题。如果某台设备宕机，Zookeeper立即选举新的Agent，Agent会向服务端反馈，从而触发配置转移。以专线配置为例，假设A,B 为一条隧道的两端，配置转移的过程是：如果A出现异常，将A设备的配置全部一次性转移到新设备A1上，并将B端和原有A端有对应关系的配置更新。
- 通过数据库的主从架构，来解决数据库单点故障的问题。
- 解决目标设备不支持某些指令的问题。如果消息下发到底层以后，目标设备上的条件不允许，不支持该操作，Agent会将信息反馈到服务端，并提示给用户。
- 解决由于某些原因造成底层配置和服务端不一致的问题。有两种方式：
1) 通过后台程序定期（时间间隔可配置，例如10s）收集底层目标设备所有需要关注的配置信息（需要关注的范围是使用者在前端对该设备所做的所有配置），收集上来之后，和数据库中该设备的配置作对比，所有配置以数据库为准，数据库中没有，底层存在的，执行删除操作，数据库中有而底层没有的，执行配置操作。
2) 可以通过web端的强制对齐配置按钮，强制同步数据库和目标设备的配置，流程同第一种。
五、使用简介
为了更加直观的介绍本工具，下面通过一个例子进行展示，以在两个不同数据中心的设备上配置专线为例:
第一步，配置网络设备。在页面配置数据中心中物理设备的公网IP地址，接口名称等信息。每个数据中心可以配置多个物理设备。
第三步，任务下发。系统会将配置指令下发到两台设备上，底层Agent接收到指令后，按照指令内容配置专线。数秒后，即可以看到专线状态变为运行中。
其他类似配置，例如创建虚拟接口，配置接口IP，添加路由等，都可以通过类似方式实现。
六、总结
物理设备的配置管理指令繁多，操作复杂，耗费了运维人员不小的精力。希望通过本工具，能够帮助运维人员将纷繁复杂的网络配置简化成在web端即可进行控制和检查的操作，使运维人员从机械劳动中解放出来，更加专注于业务本身。