整个运维平台部署多个开源软件, 几个自定义脚本, 一个给管理员使用的统一的Web控制台和一个对外展示数据中心状态的站点。部署框架如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 系统部署的框架

运维平台实现的功能主要有以下三部分, 分别为:

(1) 基于开源软件实现的功能

将服务器、交换机、机柜、机房关系图形化, 可视化。管理包括机房、机柜、设备和虚拟机、网线连接情况、IPv4/IPv6地址占用、IP负载均衡、VLAN等属性, 并可以打印报表统计机器数量、IP空余状况、设备保修状况。

对服务器的可用性、服务器的性能指标、两个机房之间的网络质量情况进行监控。

对服务器数据进行备份, 对日志进行集中式管理。

(2) 自定义脚本和管理员控制台

① 列出业务网段内的所有IP地址, 显示是否在用, 为新机器的IP地址分配提供参考。

② 列出IP地址对应的机器名、MAC地址、DNS地址、机器厂商、连接到交换机的端口位置, 方便查找过滤。点击RackTables、Nagios、Bacula、VMware等相应的图标可跳转到对应服务器的Web管理系统界面。

③ 列出所有与RackTables配置不匹配的设备, 为管理员验证RackTables配置提供数据支持。列出所有IP地址和机器名不相同的机器, 方便管理员检查各个系统配置。

④ 列出所有未安装VMware Tools的虚拟机, 督促管理员安装。列出所有没有备份的服务器, 督促管理员备份。

⑤ 统计所有不同类型的服务器数量。

⑥ 编辑和修改对外展示网站的备注。

PHP语言开发的统一的Web控制台通过各个服务器唯一的IP地址和机器名匹配整合所有后台数据。网站效果如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 聚合仪表盘式网站

(3) 对外展示站点

通过监控服务器收集的数据有选择地将部分重要服务器状态显示出来, 对外展示数据中心的服务器健康状态。显示效果如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 对外展示的站点

开源软件保存的数据可分为配置数据和运行数据两种, 一般保存在文本文件或者数据库内, 二次开发时需要先分析这些数据。为了能关联其他开源软件, 所有服务器在各个开源软件内应有相同的IP地址和机器名。

在运维平台用到的几个开源软件中, RackTables配置信息和运行数据全部保存在MySQL内。可使用RackTables的Object表生成Nagios的配置信息, 所有配置了IP地址的设备按格式写入/etc/nagios3即可对设备实施监控。

默认安装模式下, Nagios配置文件在/etc/nagios3目录内, 运行数据保存在/var/cache/nagios3和/var/lib/ nagios3/spool/checkresult内。通过安装NDOUtils插件, 可将所有配置数据和运行数据存入MySQL内, 判断是否加入监控可通过查询Nagios_hosts表获得。

Bacula配置文件保存在/etc/bacula内, Bacula会自动将配置信息保存入MySQL, 同时所有的备份文件名也保存在MySQL内, 备份的文件数据存放在自定义的目录内。判断服务器是否有备份可通过查询Bacula的Client表获得。

logstash服务端把所有获得的日志保存在Redis键值型数据库内, 配置文件分散在各个客户端。笔者在配置中通过type字符串字段区分不同的客户端, type字段由IP地址和服务说明字符串拼接而成。

RackTables管理设备的属性和属性的字典都是可以自定义的。虽然RackTables也可以添加端口的二层物理地址, 然而由于添加工作量较大, 而且可在笔者二次开发的程序中自发现管理, 所以在实际使用中, 未对该项数据进行添加。

RackTables带有标签功能, 标签的作用是在查看设备时可对设备进行过滤。在实际应用中, 笔者定义了三个一级标签, 分别是“归属部门”、“负责人”、“所属业务”, 在一级标签下建立二级、三级标签, 通过标签, 可以很方便地过滤所有的设备。

每一台RackTables内的设备信息均保存在Object表中, 设备的所有端口保存在Port表中。Port表的object_id字段与Object表外键关联, Port表的name字段是端口名, 在Linux下一般为eth0, Windows下为“本地连接”。服务器物理端口与交换机物理端口连接的信息保存在Link表中, Link表只有porta和portb字段, 记录了网线两端端口的Link表id字段值。IPv4Allocation表有object_id、ip、name等字段。ip字段为IP地址, name字段为Port的端口名, 通过下面SQL语句可以查询到对于特定的服务器object_id = 1连接到的交换机的端口信息:

SELECT ob.id, ob.name, po.id, po.name, porta, portb

FROM Object ob

LEFT JOIN Port po ON po.object_id = ob.id

LEFT JOIN Link li ON li.porta = po.id OR li.portb = po.id

WHERE ob.id = 7

而对于虚拟机则较为复杂。由于虚拟机没有物理端口, 所以需要通过EntityLink表的child_entity_id和parent_entity_id字段得到虚拟机的宿主集群。在集群的所有子机器内寻找所有物理的虚拟化宿主服务器, 再通过物理的虚拟化宿主服务器的端口来判断连接到交换机的端口信息。

在集群内的所有子机器寻找物理的虚拟化宿主服务器的步骤是: 通过Object表和EntityLink表可以得到其所有的服务器, 包括虚拟机和实体机。实体机和虚拟机的区别在于Hypervisor字段是否为Yes。前面提到RackTables的设备属性都是可自定义的, 设备的属性不保存在Object表内, 而是通过Attribute、AttributeMap和AttributeValue等表组成。Attribute表定义了系统内置属性和自定义属性的类型和名字, AttributeValue表包括object_id、attr_id、3个类型的value字段。而Hypervisor字段结果值的定义存放在Dictionary字典表内。所以查找一个object_id为8的机器是否为虚拟机的SQL语句为:

SELECT ob.id, ob.name, di.dict_value #dict_value为Yes则为实体机器

FROM Object ob

LEFT JOIN AttributeValue av ON av.object_id = ob.id

LEFT JOIN Dictionary di ON di.dict_key = av.uint_value

WHERE ob.id = 8 AND av.attr_id = 26 #26为系统默认Hypervisor的ID

在Nagios监控系统^{[ 4]}配置方面, 没有引入Web配置系统, 采用文本配置更为灵活。为了可以跟随版本升级应用到一些新的配置参数, 笔者独立出一个目录来配置所有主机、服务、联系人。由于配置文件最终保存在Git源代码版本库中, 所以对配置文件按服务器的用途进行区分, 每个用途一个配置文件, 每个管理员负责的多台服务器分开配置文件, 采取这种策略后, 版本控制冲突减少, 文件的频繁变化也被隔离开来。

Ganglia^{[ 5]}用于监控集群的CPU、内存、磁盘空间和网络。Nagios关注的是个体服务器, 如果服务器集群内服务器数量达到上百台, 单个服务器故障时有发生, 使用个体的服务器错误来衡量整个集群的状态是不合适的。而Ganglia关注的是整个集群对外提供的CPU数、内存数, 如果整个集群参数在正常范围内, 部分服务器有问题Ganglia会认为是正常的。

SmokePing^{[ 6]}用于监控多个数据中心之间和数据中心与互联网其他数据中心之间的网络互联质量情况, 从监控图上的延时与丢包能分辨出数据中心机房的网络是否稳定。

在厦门大学图书馆数据中心, 笔者使用了服务器级别和数据层面两种备份策略。服务器级别的备份在虚拟机中可通过建立虚拟机快照和使用虚拟化平台自带的备份策略。数据层面的备份, 于春生^{[ 7]}对Bacula、Amanda、BackupPC等多个开源备份软件进行了比较, 为了备份软件客户端程序可同时运行在Windows和Linux服务器上并为了保护被备份的数据不被备份管理员随意恢复, 笔者选择Bacula。

数据中心日志没有集中的管理, 系统出现错误后需要进入各个系统查看, 非常消耗时间, 同时集中式日志作为安全审计的依据, 在系统和网络管理中有着重要的意义^{[ 8]}。由于日志集中式管理软件需要同时支持多种类型的日志导入方式, 所以笔者选择logstash。所有需要用来分析定位问题的日志都被传输到日志服务器, 同时笔者和开发人员、服务器维护人员约定, 任何需要保密的信息不能写入日志, 不能被传输到logstash里。

在对数据中心管理维护中, 必须确保每个服务器都应用了安全补丁; 时间通过NTP服务器同步; 软件安装和更新来源使用校内开源软件镜像服务器; 特定的机器安装Ganglia、Bacula、logstash。为了确保以上这些要点, 引入自动化部署系统。在虚拟机层面, 建立了多个模板, 这些模板用于快速克隆部署。而实体机器和克隆后的虚拟机, 笔者采用Puppet管理^{[ 9]}, 引入Puppet后极大地减少了部署工程师的工作量。

使用VMware自带的API和Psphere库收集虚拟机的信息并存入数据库。Python代码如下:

client = Client("VCenter IP", "UserID", "Password")

//连接VMware vCenter Server

cr_list = ComputeResource.all(client)

for cr in cr_list:

ccr = ComputeResource.get(client, name=cr.name)

for host in ccr.host:

for vm in host.vm:

ip = ""

if hasattr(vm.summary.guest, 'ipAddress'):

ip = vm.summary.guest.ipAddress

//如果没有安装VMware Tools无法得到IP地址, 直接引用会出错

save_to_db(host.name, vm.name, ip, vm._mo_ref.value,
vm.summary.guest.toolsStatus)

//把虚拟机的宿主机IP地址, 虚拟机名, 虚拟机IP地址, 虚拟机ID, VMware Tools状态存入数据库

构建VMware Console的链接具体实现是: 链接格式为https://vmware.exammple.com:9443/vsphere-clien/ vmrc/vmrc.jsp?vm=urn:vmomi:VirtualMachine:vm-10X-X:16C304D3-27FC-4363-983F-FA6934CA9E7B, 其中vm-10XX替换为vm._mo_ref.value即可, 链接最后面的UUID为常量。

使用Python脚本, 通过交换机的SNMP协议读取交换机每个端口的VLAN、MAC地址; 使用Perl代码调用Linux命令行arp-scan得到MAC地址对应的厂商来区分服务器是实体机或者虚拟机; 通过三层交换机查找路由表, 得到IP地址对应的MAC地址; 通过arp-scan扫描特定的IP地址段查找IP是否在使用; 通过命令行nslookup得到IP地址对应的DNS地址。以H3C S5800交换机为例, Python代码如下:

def get_ip_mac(self): #获得IP地址和MAC地址对应关系

oid = netsnmp.VarList(netsnmp.Varbind

('iso.3.6.1.2.1.3.1.1.2.116.1.'))

netsnmp.snmpwalk(oid, Version = 2, DestHost = 'IP地址',
Community = '密码')

IpMac.objects.all().delete() #临时性清空表

for var in oid:

mac = ":".join((leading0(hex(ord(var.val[i]))[2:4])) for i in range(0, 6)) #得到MAC地址, 做了格式转换

IpMac.objects.create(ip=var.tag[28:], mac=mac) #加入IP和MAC对应表

获取端口索引和端口名对应关系的SNMP OID为'iso.3.6.1.2.1.31.1.1.1.1', 获取MAC地址和端口索引对应关系的SNMP OID为'iso.3.6.1.2.1.17.7.1.2.2.1.2', 通过以上类似的代码, 获得所有的对应关系。以上收集的信息保存在表1内:

表1

表1

表1 运行时服务器信息数据 字段名 字段类型 长度 说明 IPAddress 字符型 255 IP地址 MACAddress 字符型 255 MAC地址 SwitchName 字符型 255 交换机名称 SwitchPort 字符型 255 所连接在交换机上的端口 VMHost-IPAddress 字符型 255 虚拟机宿主物理服务器IP VMName 字符型 255 虚拟机名称 VMMoRefID 字符型 255 虚拟机的MoRef ID VMwareToolsStatus 字符型 255 虚拟机是否安装 VMware Tools

表1 运行时服务器信息数据