(1) 新服务器部署困难: 新采购的服务器根据不同的用途需要安装不同的操作系统, 光盘安装模式较为繁琐。操作系统安装后, 诸如IP地址、防火墙、自动更新、运行库、数据库、监控、备份等配置环节使用传统方法手动部署浪费时间较多。

(2) 无法快速获知已部署的服务器的状况: 对数据中心内已经部署并正在运行的虚拟机和物理服务器, 只有进入操作系统才能看到其上面运行的各种服务、依赖的组件、组件的配置等信息。工程师无法快速了解数据中心内的所有服务器和业务, 无法达到对服务器和系统自主可控的要求。

(3) 数据中心文档缺乏: 技术工程师偏爱写程序但不愿写文档, 这导致数据中心缺乏规范的文档描述, 工作交接和应急处理无章可循。

(4) 基础架构的备份和异地重建较难: 数据中心整体基础架构的备份依赖于虚拟机。虽然备份软件的重复数据删除功能极大减少了备份集的大小, 然而备份还是占用了备份软件的许可证数量。数据中心备份难以在异地重建。

(5) 开发环境搭建周期长: 开发环境和生产环境的不一致极大阻碍了业务的创新。新加入的开发人员可以克隆一台已经部署好的虚拟机, 通过更改IP地址、更新代码库和数据库版本加入到开发进程。然而部署好的虚拟机需要随时根据开发进程调整设置。如果是集群环境, 还需克隆多台虚拟机, 开发环境搭建成本较高。

(1) 引入自动化理念: 开发一个运维系统对数据中心部署进行规范。需要更新观念, 虽然有时手工操作比自动化脚本更快更直接, 然而为了今后维护方便, 对操作可追溯, 应尽量对所有操作脚本化。整个运维系统应当对基础架构平台全部使用文本定义, 使用大量的自动化脚本配合少量的手动操作。

(2) 操作系统自动安装: 服务器的操作系统安装可采用PXE网络启动安装^[7], 系统的配置通过自动安装脚本使用文本文件定义, 打开物理或者虚拟服务器即可实现自动安装。安装后通过Puppet脚本定义安装后的操作系统的各个组件的配置信息和业务的运行环境。这些自动安装脚本和Puppet脚本通过规范的文档书写, 代码则变成数据中心的文档。

(3) 部署脚本可重复运行: 对数据中心架构备份只需备份脚本即可, 无需对整个虚拟机进行备份。有了这些文档, 服务器在公有云内重建也较简单, 只需要克隆一个简单的操作系统运行Puppet等脚本即可全部配置部署完毕。

(4) 开发环境自动化: 开发环境使用Vagrant工具, 只要一人编写了部署环境定义, 参与者只需要运行一条命令, 即可在几分钟内部署好所有环境, 而且部署可在个人笔记本上实现, 方便离线开发。

系统整体框架如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 系统框架图

多个Git源代码库和一个贯穿始终的自动化理念组成了整个运维系统。依托实体机和虚拟机, 通过DHCP、PXE、Mirrors服务器以及DNS服务器分配地址自动安装操作系统, 配合Puppet、Fabric、PowerShell、Bat、Script脚本和少量人工操作定义运行环境, 最终实现应用系统和服务顺利运行。并通过脚本自动将机器IP地址和描述加入位置管理、监控服务器和备份策略内。而本地开发环境则使用Vagrant定义。所有代码均放入Git源代码版本库, 能全部实现自动化操作, 需要手工介入的已在文档内进行详细说明。

应用规范后的服务器全生命周期流程如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 服务器的全生命周期流程

依托规范和自动化理念, 运维系统实现的功能如下:

(1) 对基础架构配置文本化, 采用版本管理, 变更可追朔。

(2) 部署自动化。

(3) 开发和测试自动化。

(4) 文档自动化, 代码即清晰的文档。

Git是整个项目协作的基础, 对于数据中心的相关项目, 可以选择全部放入一个大的Git代码库, 也可将每个子项目分开, 笔者分析了所有项目的差别, 如表1所示:

表1

表1

表1 项目各项差别 项目 名称 代码量 修改频率 更改周期 与其他项 目耦合度 安全性 要求 DNS 配置 小 高 新机器部 署时, 日常 中 高 DHCP配置 小 高 新机器部 署时, 日常 中 高 TFTP 配置 小 中 新机器 部署时 中 一般 NPT, Mirrors 小 低 无 低 低 业务 系统 大 高 日常 耦合度低, 首次 部署需要修改 DNS和DHCP 各个业务系统 授权不同的开 发工程师 监控 系统 小 中 新机器 部署时 中 低

表1 项目各项差别

经过比较和整合, 笔者将整个运维系统分为以下源代码仓库:

数据中心主项目, 包含DNS、DHCP、TFTP等项目, 授权专门的部署工程师。NTP、Mirrors、位置管理系统整合成一个项目。监控系统、备份系统整合成一个项目。各个业务系统为独立项目, 授权开发者团队。所有的Puppet资源定义、自动化脚本、单次运行的脚本、在测试中可能多次运行的脚本全部放入业务项目内部。

服务器上架或者虚拟机建立以后, 打开电源, 通过PXE网络启动, 自动从DHCP服务器获取IP地址, 再从TFTP服务器下载操作系统镜像, 自动安装操作系统^[7]。安装后, 自动从Puppet主服务器下载服务器应有的配置, 自动部署需要的组件和设置。

Windows下, 无人值守安装的配置文件可使用“ 自动安装工具包” 生成。Ubuntu可使用debconf-get- selections命令得到安装Ubuntu系统所有可选择的选项, 节选部分如下:

d-i debian-installer/locale select en_US.UTF-8

d-i console-setup/ask_detect boolean false

d-i netcfg/get_hostname string dns3

tasksel tasksel/first multiselect standard, ubuntu-server

Puppet^[8]是一个配置管理工具, Puppet使用一种简洁的语言, 对系统内的资源所要达到的最终状态进行定义。Puppet使用主机名区分一台服务器, 所以DNS服务器是Puppet 多节点管理的基础。对于DNS, 学校内网络中心也有DNS服务器, 然而建立数据中心自有的DNS服务器有其必要性, 通过网络中心授权图书馆主域名到图书馆的DNS服务器, 使得图书馆对馆内其他业务系统的DNS条目控制权较高, 可自行方便地添加修改DNS条目而无需联系网络中心。同时数据中心有些服务器为内部IP地址, 无法直接连接外网, 无法获取DNS记录。而自有的DNS服务器可建立外网无法访问的DNS条目, 使得任何一台服务器均可有一个DNS地址, 方便工程师记忆和Puppet管理。

所有的基础架构, 诸如DNS、DHCP、TFTP、监控、备份系统等配置也均使用Puppet管理。

对于业务系统, 以一个典型的提供ASP运行环境的Windows服务器为例, 安装完操作系统后, 需添加IIS角色、ASP角色服务, 启用ASP父路径, 设置调试时, 将错误发送到浏览器, 安装连接SQL客户端程序等。以往需要手工在GUI操作, 只需使用类似以下Puppet脚本即可实现:

dism{'IIS-WebServerRole': ensure=> present}

dism{'IIS-WebServer': ensure=> present, require=> Dism
['IIS-WebServerRole']}

dism{'IIS-ApplicationDevelopment':ensure=> present, require=>
Dism['IIS-WebServerRole']}

dism{'IIS-ISAPIExtensions':ensure=> present, require=> Dism ['IIS-ApplicationDevelopment']}

dism{'IIS-ASP': ensure=> present, require=> Dism

['IIS-ISAPIExtensions']}

exec{'Enable ASP Parent Path': command=> 'C:\Windows\
System32\inetsrv\appcmd.exe set config -section:system.

webServer/asp /enableParentPaths:"True" /commit:apphost',
require => Dism['IIS-ASP']}

package{'SQL Server Native Client':ensure=> present,
source=> '\\192.168.1.150\software\sqlncli_x64.msi', provider
=> 'windows', install_options=> [{'USERNAME'=> 'LibRoot'},
{'COMPANYNAME'=> 'Lib'}, {'IACCEPTSQLNCLILICENSETERMS'=> 'YES'}]}

其中, MSI静默安装的设置变量名可通过Orca MSI Editor导出。

Puppet是针对资源所达到的最终状态定义的, 有些操作无法通过Puppet定义完成, 有些命令是一次性不能重复运行的, 这时就需要补充。比如Fabric、Shell脚本、Windows下的Bat脚本、PowerShell命令等。

Windows下设置防火墙的Bat脚本如下:

netsh advfirewall reset

netsh advfirewall firewall delete rule name=all

netsh advfirewall set allprofiles state on

netsh advfirewall set allprofiles firewallpolicy blockinbound,
allowoutbound

netsh advfirewall firewall add rule name="Open Port" dir=
in protocol=tcp localport=80 action=allow

通过类似的脚本, 无需使用GUI界面即可完成需要的任务, 规避了人工操作多个步骤中可能造成的错误, 并且此脚本可在多台服务器中重复利用。

Vagrant是搭建虚拟机开发环境的工具, 它可将部署提前到开发阶段, 使得开发环境和生产环境一致, 减少了“ 在我的电脑上运行得很正常” ^[9]的错误。

之前的开发场景可能是: 开发者开发, 经历一段时间, 部署到生产环境。继续开发, 变更后再到生产环境部署。这个过程中任何的人工错误都会导致系统产生Bug。通过引入Vagrant, 开发人员从项目建立时即开始关注部署, 编写部署代码, 使得项目从第一天开发就是可部署的。

使用Vagrant后, 合作开发人员只需要到Git下载项目源代码, “ vagrant up” 命令即可自动建立虚拟机、配置IP地址、运行Puppet命令部署, 启动一个同生成环境一样的开发环境, 即使生产环境是由多台服务器组成的^[10]。

部署时工程师只需要拿到Vagrant内的Puppet脚本在服务器上运行“ puppet apply default.pp” 即可建立运行环境。甚至可在安装操作系统时指定Puppet脚本完成全自动部署。