银行数据中心自动化运维平台设计

　1. 自动化运维建设背景

　随着 IT 技术的快速发展，IT 系统的运维复杂度不断增加，IT 部门的体量不断扩大，传统的人工操作和借助管理流程的方式已不能满足日益增长的运维工作量。而智能时代的到来，无论是 DevOps 的思想还是 AIOps 思想，自动化就像人的“手”一样，决定着最终这些技术思想的是否能够落地，决定着未来一个IT 运维的生产力。

　而从银行 IT 架构、运维的特殊性考虑，也需要结合银行自身的特点，对于双模的架构、双模的运维方式也要兼备在稳态和敏态下的自动化运维方案。

　自动化运维可以带来的益处：

　1. 降低成本 - 没有一家公司是不想降低成本的，而自动化运维可以通过提高效率、减少人为错误和人力需求，降低企业 IT 成本。

　2. 提高生产力 - 自动化运维几乎不需要手动工作，这也就意味着它不仅可以提高产出，还可以将运维人员从复杂的传统运维工作中释放出来，将其知识和技能应用于更有价值的工作和任务上。此外，通过减少周转时间，每天可处理工作量也提高了。

　3. 高可用 - 系统宕机可能会使企业损失惨重，无论是金钱上，还是声誉上。运维优先要保障的便是高可用，这也是自动化运维的一大目标。例如通过自动化保存和恢复机制，全天候系统监控和远程通信，以大幅降低网络停机时间；或是快速恢复，减少故障带来的损失。

　4. 更可靠 - 运维常常包括一些重复的但完全必要的工作，这也就是为什么它容易出错。当人为因素从这个过程中消除时，那些昂贵的人为错误也自然消失了，这对于具有多个操作系统的大型网络尤其有用。自动化运维可以明显提高可靠性，减轻运维人员繁琐的手动任务。

　5. 性能优化 - 运维专家面临的另一个问题是，让执行任务和工作流程变得更快、更高效、具备更高工作负载。传统运维方式想要满足这些需求是很困难的，而自动化运维工具则可以填补此类需求，在无需雇佣更多员工的情况下，最大限度的提高性能。

　基于以上业务发展的需要以及自动化运维的收益，结合自身 IT 发展的形势，某银行在自动化运维方面进行了探索和实践。

　 2. 自动化运维平台设计

　2.1 需求分析 1. 建立自动化运维管理作业平台，集成自动化部署、批量变更、资源管理、资产信息自动发现等功能。

　2. 实现物理机一站式批量部署，包括服务器部署以及操作系统 HPUX、Linux 以及 Windows 操作系统的部署。

　3. 实现基于虚拟化平台 OpenStack 和 VMWare的基础环境的自动化部署。

　4. 实现 Windows 安全补丁的批量安装和管理。

　5. 实现基于操作系统的批量变更的功能，包括 Windows 安全补丁安装、批量推送配置、批量安装软件等。

　6. 实现基于操作系统层面资产信息的自动发现。

　7. 实现基于操作系统的自动化巡检功能。

　8. 与流程平台、配置平台的对接，实现流程数据和资源数据的整合实现资源管理功能。

　9. 与流程平台对接，实现工单驱动自动化部署和变更的半自助服务。

　2.2 系统架构 1. 总体设计思路

　系统运维自动化的应用架构及关键业务流程的总体规划及设计如下：

　建设自动化作业管理平台是本项目的主要工作目标，底层对接资源层，使用各类技术工具以实现自动化操作，横向对接配置管理平台、流程平台、监控平台

　和数据管理平台，贯穿整体统一运维管理框架，以实现自动化部署、批量变更、配置发现、自动巡检、资源管理的功能。

　2. 总体应用逻辑架构设计

　下图是系统运维自动化的总体逻辑架构图

　 解释说明：

　整体架构分为资源层、工具层、平台层和应用层。底层根据企业特点，目前主要是基于私有云环境以及物理裸机，私有云主要使用 VmWare 和 OpenStack等虚拟化平台，而容器平台也逐渐将作为一种资源类型纳入到资源层的管控中。而基于金融行业的特殊性，物理裸机的部署依旧占用比重很大。在设计上依旧需要考虑物理裸机的自动化部署。

　在工具层根据底层资源的类型以及特性选择相应的技术工具，如 X86 服务器的部署选择 Cobbler，HPUnix 服务器选择 Ux-ignite，而虚拟化平台选择 Ansible、虚拟化平台 API 或是命令对接的方式实现资源的自动化部署和资源管控。对接

　流程管理平台主要实现环境交付和变更的半自助服务，以及实现资源管控的流程信息的分类和管理。对接监控信息实现故障自愈以及资源回收。对接配置平台，是通过信息的自动发现保证配置信息的准确性。

　在平台层建立自动化作业管理平台，也是本期实施的主要部分。在金融企业内部基本已建立了流程平台、配置平台、监控平台。作业管理平台，主要面向运维人员，可提供自动化操作和配置界面。

　而在应用场景方面，主要需要解决的问题，一是环境的自动化部署交付、二是批量变更、三是主机信息的自动化发现、四是自动化巡检、五是资源管控。

　3. 关键应用实施方案

　物理服务器部署

　根据实际需求情况，由于物理服务器的操作系统版本没有高度统一，如RedHat、CentOS、Exsi 等各类版本，故物理服务器一站式部署的实质是要形成 X86 物理资源池，再按需下发部署操作系统。

　要实现 Cobbler 的自动化下推操作系统，必须提供 DHCP 网络环境，根据现有的网络环境，按如下方案实施：

　1. Cobbler 服务器根据其业务功能将其部署在数据中心的业务管理区（或某一个业务区中），Cobbler 提供 X86 服务器基于 PXE 的自动引导安装功能，同时提供 DHCP 服务，并定义跨区域的多网段 IP 地址段。

　2. 由于 Cobbler 的网络引导需要在 DHCP 网络内进行，而在目前业务网中采用的是固定 IP 分配方式，故采取在每个业务区建立一个 Vlan 作为物理服务器的预安装区，在这些区域内单独开启 DHCP 服务。Cobbler 服务器本身作为 DHCP 服务器，每个区域预安装区 Vlan 的服务器通过本区域的接入交换机的中继服务向 DHCP 服务器申请 IP 地址。

　3. 裸机上电上架时业务口先接入预安装区 Vlan，该 Vlan 网络与同区业务网络通过接入交换机隔离。已接入各业务区 Vlan 的待安装裸机，在启动时会广播请求 DHCP 服务以获取 IP 地址，通过每个区汇聚层的 DHCP中继服务，将其指向业务管理区（Cobbler 服务器所在业务区）的 DHCP

　服务器（部署在 Cobbler 服务器上）以获取 IP 地址，获取 IP 地址后会继续请求引导文件，获取镜像文件等后续操作系统部署动作。在完成操作系统的自动安装后，将该裸机服务器的业务 IP 由预安装 Vlan 切换至正式业务环境。

　4. Cobbler 在 kickstart 的基础上集成了电源管理功能，故每台 X86 服务器在批量上电上架后配置带外口配置，可以实现批量部署物理服务器形成物理资源池，再按需实现操作系统部署。无需在上电上架时人为开机进行引导操作系统，将批量部署和按需下发的动作分离，形成物理资源池。

　具体网络结构如下图：

　 4. 主要工具简介

　Cobbler

　Cobbler 是一个系统启动服务（boot server），可以通过网络启动（PXE）的方式用来快速安装、重装物理服务器和虚拟机，支持安装不同的 Linux 发行版和 Windows。该工具使用 python 开发，小巧轻便（才 15k 行代码），使用简单的命令即可完成 PXE网络安装环境的配置，同时还可以管理 DHCP，DNS，以及 yum 包镜像。

　Cobbler 使用命令行方式管理，也提供了基于 Web 的界面管理工具（cobbler-web），还提供了 API 接口，可以方便二次开发使用。

　Ignite-UX

　Ignite-UX 是 HP-UX 的系统管理工具，可以利用该工具通过镜像备份恢复的方式从网络引导并安装 HP-UX 操作系统。

　WSUS

　WSUS 是个微软推出的网络化的补丁分发方案，是个免费的工具。WSUS 支持微软公司全部产品的更新。通过 WSUS 这个内部网络中的 Windows 升级服务，所有 Windows 更新都集中下载到内部网的 WSUS 服务器中，而网络中的客户机通过 WSUS 服务器来得到更新。这在很大程度上节省了网络资源，避免了外部网络流量的浪费并且提高了内部网络中计算机更新的效率。WSUS 采用 C/S 模式，客户端已被包含在各个 WINDOWS 操作系统上。从微软网站上下载的是 WSUS 服务器端。通过配置，将客户端和服务器端关联起来，就可以自动下载补丁了。这个配置几乎就是使用 WSUS 的全部工作了。

　Ansible

　ansible 是自动化运维工具，基于 Python 开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

　 3.Ansible 的应用

　在整个自动化运维管理平台中，除了集成部分由专业开发团队外包集成外，Ansible 是由我们目前研究的方向和目标。而基于 Ansible 基本实现了自动化运维平台的后端核心部分，下面的章节主要就 Ansible 研究和探索的内容进行分享和探讨。

　3.1Ansible 的特点 Ansible 在官网中被定义为 Ansible is a radically simple IT automation engine。说明 Ansible 是一款极其简单的 IT 自动化工具，在 0.X 的版本中甚至

　使用 Stupid Simple 来形容 Ansible 是令人发指的简单。可见 Ansible 这块自动化工具非常注重 Simple 的理念。

　虽然 Ansible 注重使用的简单，但它自身并不简单，它拥有丰富稳定的内置模块和开放的 API 接口。目前在 Ansible2.3 的版本中已经拥有了 1014 个内置模块（数据更新至 2017 年 9 月 6 日）。而由于其开源生态非常好使得其内置模块支持的覆盖面非常广：

　系统层：Linux、Windows、AIX 等，对应的模块有 acl、cron、pip、yum、shell、command、file、copy、user、lvol 等等。

　虚拟化：OpenStack、VMware、Docker、CloudStack、LXC 等，对应的模块glance_image、os_server、vmware_vmkernel、docker 等等。

　商业化软件：F5、ASA、Citrix、Eos 等

　系统应用层：Apache、Jboss、Zabbix、Rabbitmq、SVN、GIT、Mysql、Mariadb等，对应的模块 apache2_module、jboss、zabbix_group、rabbitmq_binding、subversion、git 等

　Ansible 与 与 Puppet 和 和 Saltstack 的对比

　目前主流的自动化配置管理工具主要有 Ansible、Puppet 和 SaltStack，这三款自动化开源工具的主要优劣势如表一所示，而近年来 Ansible 也成为了自动化配置管理工具的“网红”，其在 GitHub 中的社区关注度见表二。

　 GitHub 社区活跃度：

　 3.2Ansible 的技术能力 Ansible 在 在 Linux 下的技术能力

　作为开源系统和软件，Linux 系统是 Ansible 支持最佳的操作系统。我们使用Ansible 在 Linux 下对部分模块进行了测试和实际的运用。结果表明，模块的丰富程度很高可以覆盖绝大多数自动化运维场景。无代理的特性 Ansible 的管控覆盖快速、轻便。稳定性和容错能力不错。在大量覆盖千量级服务器发现了几个不足是需要寻求一些更好的解决方案的，一是 Ansible 会对中文字符集的操作系统支持上存在一些小问题，比如 service 模块；二是 Ansible 执行命令时会在某些被控节点特定异常时挂住，无法继续，即使采用异步模式；三是性能并不是特别好，需要调优或寻求其他解决方案。未调优情况下，管控千量级

　服务器可以，万量级服务器难以胜任。在 8C8G 的服务器上对 2000 台服务器执行 20 并发的 ping 模块（即单作业执行）消耗时间大约 3 分钟。实际在进行ZabbixAgent 批量安装时，我们的 Playbook 有 20 多个作业，在安装 500 台服务器时使用的时间大约是 20-30 分钟。

　用 常用 Linux 模块（基本覆盖 90% 的自动化场景）：

　user: 用户管理

　group：用户组管理

　shell：调用 shell

　file：文件、目录管理（包括权限、属主）

　copy：文件复制（包括权限、属主）

　service：Linux 服务管理

　lineinfile：对于文本文件的处理，可通过正则表达式进行替换、新增、删除等，是配置文件调整的利器

　template：下发模版文件，可以随变量变化在下发后自动生成适用于受控主机的配置文件，是配置文件管理的利器，特别适用于系统应用软件，比如 mysql、jboss、apache 等

　authorized_key：密钥管理，可以批量下发或管理 ssh 密钥

　unarchive：对 zip、tar、gzip 等格式的包可以解压

　yum：使用 yum 管理器对包进行管理

　lvg：lvm 的 pv 和 vg 管理，可以创建、调整、删除 vg

　lvol：lvm 的 lv 管理，可以创建、调整、删除 lv

　fssystem：文件系统管理

　mount：文件系统挂载管理

　Ansible 在 在 HPUX 下的技术能力

　根据公司的实际情况，Unix 服务器主要是 HPUX，AIX 使用的比较少。故对Ansible 在 HPUX 的使用进行了测试。

　首先 HPUX11.31 下并未默认安装 python，故需要手动安装 python 后才能接管。而测试结果发现支持情况不佳，HPUX 下可以使用少部分的 Linux 的模块，而使用到一些系统级的模块时 HPUX 下无法支持，比如 service、mount、lvg、lvol 等等。所以不推荐 Ansible 在 HPUX 下直接使用。如果需要 Ansible 统一管控，可以通过 Ansible 连接后调用脚本实现管控。

　Ansible 在 在 Windows 下的技术能力

　Ansible 连接 Windows 主机从技术实现上是利用了 Windows 的 Powershell及.net 库，通过 Python 的 pywinrm 库实现基于 Windows 的 winrm 协议远程控制 Windows 主机，而调用的 Ansible 的内置模块实质均为 Powershell 脚本，仅由 python 程序调用。

　故 Ansible 连接 Windows 主机需要 Powershell3.0 及.net3.5，所以WindowsServer2008 需要进行升级，而 Windows2012 及以上版本可以直接使用。

　通过测试及实际运用发现，常规运维操作覆盖能力不错。甚至使用 Ansible 进行 WindowsHotFix 补丁的安装均可以实现。当然我们在选择补丁安装时最终还是选择了微软原生的 WSUS 进行集成。

　根据实际情况，目前依旧有不少应用运行在 WindowsServer2008 上，升级.net需要应用的测试，工作量较大需要逐步推进。而在 WindowsServer2012 及以上版本上，使用 Ansible 是没有什么问题的。

　常用 Windows 模块（基本覆盖 90%的自动化场景）：

　win_user: windows 用户管理

　win_group: windows 用户组管理

　win_shell：调用 windows 内部命令或脚本

　win_file：管理 windows 文件，包括复制、删除、创建等，包括管理文件属主、权限等

　win_copy：复制 windows 文件，包括复制、删除、创建等，包括管理文件属主、权限等

　win_service：管理 windows 的服务，可以启动、停止、设置自启、禁止自启

　win_lineinfile：对文本文件通过正则表达式进行调整，包括插入、替换、删除

　win_unzip：可对 zip 压缩包进行解压，win_zip 可以进行打包

　win_msi：对 windows 的 msi 包进行管理

　Ansible 在 在 OpenStack 下的技术能力

　Ansible可以作为 OpenStack的自动化编排工具，通过 Ansible控制 OpenStack的 Controller 节点，通过 Ansible 的内置模块 os_server、os_volume 等模块实现在 OpenStack 平台上管理 instance 和存储。

　从需求出发公司目前的需求仅为环境交付。所以在实际使用中，我们根据用户对环境的需求，使用已经编制好的 AnsiblePlaybook 调用不同的参数在OpenStack 上创建实例、挂载磁盘、进行安全加固、安装基础软件最终交付至用户，与流程对接后可以实现半自助服务。

　而在社区中也可以看到大量关于 Ansible安装 OpenStack以及扩展的资料和实际使用情况。本文在这里不做深入介绍。另外，Git 上也有不少 Ansible 在OpenStack 上的实际案例，比如使用 Ansible 的 Playbook 来实现整个OpenStack 环境的自动化应急演练，检测网络、实例、存储、以及实例上的资源异常时的系统健壮程度。

　所以，我们认为 Ansible可以作为 OpenStack的编排工具在公司进行推广使用。

　Ansible 技术能力总结

　Ansible 的优点主要是：

　一、学习曲线平滑，使用简易。具备一定脚本使用基础的运维人员两个月可以较为熟练的使用。

　二、无代理，部署简单。

　三、模块丰富，覆盖面较广，使用场景较多。

　四、社区热度高，资料丰富。

　Ansible 的缺点是：

　一、性能相对较弱，需要优化或更改连接模式提升性能。

　二、HPUX、WindowsServer08 支持较弱。

　三、对于中文环境依旧存在一些弊端。

　四、日志记录功能不够强大。

　五、基于幂等设计，回退机制弱。

　3.3Ansible 的应用场景 景 目前公司 Ansible 已经广泛开始使用，目前应用的场景主要是批量变更、软件安装、环境交付以及主机信息的自动发现。

　批量变更

　主要应用在 Linux 操作系统上，根据实际运维需要我们应用在 Agent 批量安装、用户批量开设、配置批量更新等方面。

　使用最多的是 Zabbix 和 Flume 的 Agent 批量安装，特别是 Zabbix 使用 Ansible工具特别方便，除了安装 Agent 之外，批量更改配置非常方便，如使用 Zabbix服务器或代理服务器地址更换、自定义 Key 的新增调整等等。

　在用户开立方面也使用 Ansible 进行批量推送。

　同时，在配置方便除了 Zabbix 配置之外，还在 ELK 的 Syslog 的配置上也已经进行了应用。

　在使用 Ansible 进行批量变更的时候，需要保证代码进行充分测试，虽然Ansible 在使用上非常简单，但回退机制较弱。比如文件的批量更新，虽然可以进行备份，但无法将备份批量进行回退。

　基础设施即代码的概念中最困难的一点是碎片服务器，由于存在大量的存量服务器，所以这个问题无法避免。这就需要企业内部使用 Ansible 的时候一定要将 Ansible 作为一种软件代码进行管理，建立开发测试发布机制，保证代码充分测试。在批量变更的时候寻找不同类型的设备进行试点后再逐步推送。如果使用 Ansible 进行过一次推送后，碎片的问题基本就不是问题了，今后可以较为放心的反复更新。

　关于开发测试发布机制，我们目前以 GitLab 为工具建立了版本控制系统，并定义了代码迁入迁出规则，严格根据流程开发、测试最后才能最终发布。

　软件安装

　除了批量变更之外，Ansible 主要是实现基础软件的安装，比如 mysql、oracle、jboss 等等。在使用 Ansible 安装此类软件时将配置独立出来，这样可以根据用户需求获取不同参数，以实现不同配置的软件。

　环境交付

　除了批量变更之外，Ansible 主要是实现基础软件的安装，比如 mysql、oracle、jboss 等等。

　在环境交付层面，由于 Ansible 是基于操作系统或是虚拟化云平台的，所以在裸机部署上并不适用。在虚拟化云平台上，通过 Ansible 基于 OpenStack 和VMWare 的模块开设实例和虚机以及挂盘，完成虚机的下放后，再进行软件的安装。从 Ansible 的 Playbook 的设计上只需要将下放虚机挂盘操作作为一部分再集成前述的软件安装部分即可。下放虚机挂盘的操作也可以由自动化运维平台中集成各个虚拟化平台的命令完成。

　最后呈现的形式由用户递交环境申请信息，标注需要什么配置的服务器、几台、需要安装什么样的软件。递交申请审批通过，由自动化平台自动运行部署后交付至用户。

　主机信息自动发现

　利用 Ansible 的现成连接通道以及自带的 facts 模块，实现主机信息的自动发现和更新功能，并将这些信息定期更新至配置平台中，以辅助配置平台的数据准确性。由于 Ansible 的 facts 模块采集的信息有限，且基于 Linux、HPUX 以及 Windows 采集的内容也稍有不同，所以还是需要一些本地化的程序辅助。

　Facts 中可以采集的信息主要包含了主机的一些基础信息，如主机名、IP 地址、网卡信息、CPU、MEM 以及操作系统版本等信息。而从需求出发，我们可能还关注基础软件的版本信息、文件系统以及用户的信息等等。所以需要根据需求定义一些程序以获取这些信息。

　我们目前采用如下图，设计方法获取主机信息，根据需求编制 Ansible 的模块，比如获取用户的信息，定义新的模块，定义完成后即形成新的 AnsibleAD-HOC命令，通过一段程序获取所有受控的主机的 facts 以及自定义的信息之后将其入库，并同步更新至 CMDB 库。运维人员自己就可以根据自身的需求去定义需要的信息，并且将其入库，无需专业的开发人员实施。

　其他场景

　Ansible 的其他使用场景，主要是应用的发布和变更，利用 Ansible 本身与 Git结合的能力，考虑应用的发布，社区中也有不少这样的案例可以参考。同时公司目前也在研究以 Jenkins 为主要工具的持续集成、持续测试，Jenkins 环境部署和应用发布的部分考虑与 Ansible 对接实现。