作 者：中国移动通信集团江苏有限公司 陆旻 来晓阳 吴翔

随着3G的到来和三网融合趋势的逐渐明朗，中国通讯业在飞速发展，各家运营商之间激烈竞争，各运营商不断推出新业务以应对新挑战。随着各种新业务的不断推出，网管系统数据中心的规模越来越大，服务器数量也在急剧增加。网络支撑部门面对分散的业务系统、持续扩大的系统平台规模、7*24小时的服务时间要求、全面严谨的业务指标考核标准、业务数据“零”丢失的严谨要求现状以及紧张的维护人力资源配置状况，迫切需要高效的针对IT基础架构的运行状况监控工具，同时要实现设备的统一、灵活部署，提高运维管理效率，降低运维成本。

本文通过介绍中国移动江苏公司网络支撑网在 IBM 小型机平台的管理监控集中化、虚拟环境标准化、系统环境部署自动化的具体实践，能够很好的解决中国移动江苏公司现网系统运行遇到的种种问题，为运营商的网管系统建设提供新思路。

1 引言

中国移动江苏公司网络支撑系统自2000年开始建设了话务网管、数据网管、传输网管、电子运维、综合资源管理、7号信令监测、数据业务监测、网间信令监测、自动拨测、动力环境监控、综合监控、综合分析、网优平台、网络投诉处理平台、IT网管、安全管控平台等近20套专业网管支撑系统。这些支撑系统所管理的数据从方方面面监控了移动通信网络的运行信息，从而支撑各项运维工作的顺利开展。

江苏移动的网络支撑系统已形成一定规模，业务支撑系统遇到的问题在网管都会遇到，并且有着自身的特点：单一系统的规模较小、种类繁多，调整频繁、主机资源利用不均衡。基于系统现状和对发展的思考，引入IBM动态基础架构理念，尝试部署主机动态资源池，有效解决了网管系统“演进”过程中遇到的一些难题。我们相信这些解决问题的方法、技术和思路对各专业IT部门都有借鉴，在此拿出来探讨！

2 网管系统 IT 架构的挑战

网管最初是作为大网的附属配套零零星星的分布于各专业网络中，例如：交换网管、传输网管等等。但是江苏移动的用户规模已经突破了 5000 万，网管支撑系统的规模也经历了一个从量变到质变的过程，从管理着几个分散的网管系统到运营着一个大型的数据中心。在演变的过程中，不仅遇到了其他数据中心从小到大时所必经的一般性问题，还存在自身沿革过程中产生的特殊性问题。就IT基础架构来说，遇到如下一些比较棘手的难题：

2.1 烟囱式基础架构

网管系统的各个子系统都是按照业务需求逐个建立起来。每个系统建设，都需要采购完整的服务器设备，从 WEB 服务器、应用服务器、数据库服务器、存储交换机、存储磁盘等等，都必不可少。这种传统建设方式，有其合理的方面，如业务系统分割方便，但随着业务的快速发展，也导致了诸如服务器物理台数的快速增长、采购成本高昂、各系统之间计算资源不可综合调度利用以及IT运维人员工作负荷过高等不尽合理的诸多弊端。

2.2 IT基础设施缺乏弹性，不能灵活调配

网管系统中有很多业务种类是具有明显的周期性的，比如话务网管性能数据采集的高峰期出现在每小时的半点左右，之后负载下降，趋向于平稳。由于话务网管系统的正常运行直接影响一系列重要运维KPI指标，其对安全性与稳定性有着极高的要求，即使在非常重负载的情况下也不允许有性能问题。峰值负载时需要至少 18 颗 CPU 的一台服务器来满足处理的要求，而平均负载仅需要 2～4 颗CPU。与此同时，数据汇总模块每小时的峰值出现在 45 分左右，之后负载也下降。该模块需要 12 颗 CPU 来处理其峰值负载，而平稳期的 CPU 利用率大约只在 20% 左右。

由于采用独立物理服务器，或静态分区技术，网管系统的部分服务器计算能力未能充分利用。

2.3 容量规划困难

每个系统采购之前都会对该系统进行容量估算，作为设备采购的依据。容量估算涉及的因素非常多，比如未来业务总量、用户数、性能要求、应用程序开发水平、各个系统之间的交互等等，这些因素都会对容量估算结果产生影响。但上线一个新系统，在很多情况下上述的这些信息并不完整，或者根本就没有。需要什么样的新设备很多时候只能参照类似系统，或者猜测系统生命周期中工作负载的增长。在这样的情况下，业务部门难以对需求估算精确，为求安全，有时导致设备超量采购；抑或系统上线不久就因负荷过高需紧急扩容。

2.4 设备数量众多，系统管理复杂

网管系统业务大部分对硬件计算资源的要求不是很高，但业务种类繁多，导致 IT 系统也非常多。管理员要维护各个系统的操作系统版本、数据库版本等等，即便有管理系统协助，管理员维护各类系统的配置、进行优化，都是一项繁杂和困难的工作。

2.5 建设维护缺乏规范性

江苏移动网络支撑网各个系统的维护管理虽然已按照应用和平台进行了区分，但平台管理员仍需了解主机硬件、操作系统、数据库、中间件甚至备份的各方面知识。这样的方法要求管理员对系统的各个方面都要了解，甚至要精通。但现实中由于管理员精力和时间有限，加上各个层面的管理工具、方法也有诸多差异，使得管理员难以全面精通或掌控各个层面的管理。

2.6 设备能耗巨大，机房供电不足

机房是能耗大户。随着系统中心规模的不断增大，为满足设备运行和冷却方面的需求，其能源成本一直居高不下。有些大机房还出现了由于机房供电不足，不得不把某些系统迁移到异地的情况。机房的能耗成本，一年都高达数千万元。在国家节能减排与绿色机房的政策大环境下，如何有效降低能耗成为企业必须关注的问题

3 对策和实现方法

3.1 同平台应用整合

以前按项目买设备，设备只是被某项目独占，而非共享，因此某些设备上的资源是多余的，但是另外的项目却不能够利用它。所以一定程度上造成资源的浪费。利用服务器虚拟化技术，打破应用和 IT 资源之间的绑定关系，把应用和硬件解耦合，多个应用能共享 IT 资源。

同平台应用整合，从技术容易实现，成本和风险都比较小。要整合服务器资源，非常重要的前提是梳理各个网管系统的运行特点，也就是说，需要非常明确的知道各系统的峰值负载，节假日突发高峰，批处理时间，响应要求，业务等级等等。在明确了这些信息之后，制定资源整合计划。通过评估，有些业务是可以通过分区整合到一台服务器上的，可以获得明显的利益，较少甚至没有负面影响。而有些业务不合适整合，遇到类似情况，我们也不会为了整合而整合。在整合服务器资源中，我们也注重探索集成多种环境，获得理想的技术组合，以实现服务目标。如图 1，对于压力较大，且重要级别较高的系统如话务网管、资源管理等被部署到独占 CPU 的动态逻辑分区上，并配置独立的物理板卡，以保证性能。对于压力较小的 PBOSS 系统，我们通过微分区来部署，且由于其 I/O 流量很小，因此可以通过虚拟 I/O 服务器（VIOS）来共享以太网卡和存储卡，在不影响业务效率的前提下，减少了物理设备，提高了灵活性。

3.2 实现服务器的控制台集中管理

通过 IBM Systems Director 集中控制台，实现跨机房、多网段的服务器的自动发现（通过 IP 地址），系统同时能自动更新已发现服务器的信息。管理员能借助这套系统快速的了解每台服务器，如物理、逻辑、或虚拟硬件，操作系统类型及版本，硬件固件及 BIOS 信息，所安装的软件信息等等。

通过制定系统一致性策略，管理员可以实时监控受管系统更新状态和自动接收更新提醒，这包括了受管操作系统和服务器固件更新管理。

Director 同时整合了多个硬件管理控制台（HMC），提供了层次化的资源关系表以及图形视图。管理员可以利用这些关系表和视图方便查看服务器拓扑结构和虚拟化层次。

3.3 实现快速的问题定位和瓶颈识别

管理员可以自定义一个 Systems Director 集中受管系统健康状况视图，所有受管系统硬件层面告警都将集中在该视图展现。通过设置过滤，管理员可以快速检查重要告警信息，比如CPU 利用率、内存利用率、I/O 吞吐量、页交换等等。监控结果可以触发自动化响应策略。对划分了分区的服务器来说，Director 分别显示每个分区的资源利用率，同时也显示整台服务器的资源利用率。这对于采用了超用 CPU 模式（uncapped）的微分区来说，是非常关键的。管理员根据这些信息来动态评估服务器的分区规划是否合理。这些历史性能信息也为管理员进行服务器容量规划提供依据。

3.4 实现主机CPU、内存自动化弹性调整，实现精细化管理

通过分区虚拟化实现同平台应用整合，仍然处于静态方式。业务是动态发展的，网管中心的支持要能对此作出快速响应。服务器 CPU 池化的技术很好的解决这一问题。基于 Power 服务器微分区，我们设置两种策略来确保分区能自动实现弹性化调整：首先多个业务分区共享多个物理 CPU，每个分区设定适量初始授权 CPU 用量以及适量的虚拟 CPU 个数，这非常关键。业务分区在压力很小时，虚拟 CPU 基本不占用或只用很少量的物理 CPU 处理能力。当某个分区业务突发增大时，该分区的虚拟 CPU 可实时动态的调用更多物理 CPU，在超过初始授权值时，只要 CPU 池中还有空闲物理 CPU，那么该分区可以超用 CPU。第二，我们在必要的情况下可以对各个分区设定合适的权重。如果有多个分区都超用 CPU，权重较大的分区在超用 CPU 时可以占用较多的资源。这种调整都是可以动态实现。

3.5 构建资源池与映像库，实现标准化流程，优化基础平台交付

业务部门需要基础平台，传统上的流程通常如图 2 左边部分所示，首先用户提出要求，然后 IT 部门新购（或利旧）设备，物理设备连接，安装操作系统、打补丁，安装应用软件、打补丁…，最后测试再提交使用。流程长，牵扯较多人力，各个系统之间的软件版本也较难保持一致性，导致维护复杂。

在实现统一服务器管理的前提下，再结合服务器虚拟化技术，使得我们有能力构建“统一管理，优化标准，快速部署”的 IT 基础环境。如图 2 右边部分所示。首先是服务器被统一管理，纳入计算资源池中。然后，我们通过 Director 对常用的软件版本组合（操作系统、数据库、中间件等）进行捕捉，创建标准化映像，保存在统一映像库中。在需要新基础平台时，管理员通过 Director 在计算资源池中查找合适的受管服务器，然后从映像库中选择合适的映像。之后 Director 能自动创建分区，并把映像部署到指定的受管服务器上。整个部署过程都通过网络进行，管理员不再需要到现场。 交付使用的系统，也被纳入统一监控系统中，结合用户的反馈意见等，管理员可以优化、创建新的系统映像保存在映像库中。 

3.6 完善计算资源回收机制

对于一些临时借用的开发测试环境，或某些系统下线之后，我们将其中的服务器归入可再重利用组。如果是物理服务器，可以直接关机以节约能耗。在服务器有供电的情况下，我们仍然可以通过 Director 对其基本信息进行了解。如果是分区，我们可以通过 Director 进行统一删除，以释放资源。正如图 2 所示，采用Director的新软硬件部署模式较之传统模式效率有了很大提升，部署基本实现远程自动化，并实现了资源回收和灵活调度。

4 实施效果及评估

4.1 有效整合应用，提高资源利用率

通过分区技术，我们成功实现了多个同平台系统整合，如卓越运维系统与管线系统、综合资源系统与网优系统等，有效的减少了服务器物理数量，提高了系统利用率，同时不降低系统的响应时间。

4.2 实现了主机自动化弹性调整，节省硬件投资

CPU 池化使得服务器上的分区具有良好的弹性调整能力，通过对业务类别、特征进行梳理之后进行整合规划，能有效发挥这一弹性。如综合资源系统和网优系统在峰值时各需要 18 和 12 颗 CPU 来满足计算能力，但 2 套系统的峰值时间是错开的。通过 CPU 池化整合，1 台 24 CPU 的服务器就能良好运行上述系统，节省硬件投资约 20%。如下图 3：

4.3 实现了 IBM Power 服务器的统一管理

通过 IBM Director 软件，实现了对全部 IBM POWER 服务器的统一管理。通过集中控制台，实现对设备的自动发现、信息自动更新；通过层次化的资源关系表及图形视图，显示服务器拓扑结构和虚拟化层次；通过制定系统一致性策略，实现实时监控受管系统健康状况，并制定自动化响应策略。管理员因此可以摆脱大量的日常重复、琐碎的信息整理、归类、管理监视等等，可以提升技术水平，专注于更具创造性的工作。

4.4 实现了计算资源的快速部署和回收机制

由于网管系统种类多、调整多，基于虚拟 I/O 服务器，管理员能任意切割一台 IBM 服务器的资源，创建可用的、隔离的分区及操作系统环境，真正做到随需提供、随需调整。当任务完成，删除分区就可以做到资源的快速回收。满足了开发厂家对测试环境的快速申请和回收需求，如下图 4。

4.5 实现了映像库，固化最佳实践，优化部署

网管系统规模不大，但涉及操作系统版本、中间件、数据库版本繁多。我们根据多年运维经验，对不同版本的 AIX、数据库Oracle、informix，中间件weblogic、websphere 等多种组合的最佳实践固化为标准镜像。映像可以通过集中管理平台自动部署，实现快速、优化的基础平台交付。

4.6 有效的节能减排

设备物理数量的减少，充分利用闲置资源，显著降低了能耗。

5 结束语

中国移动江苏公司网络支撑系统通过同平台应用整合实践，对支撑网络的  IBM 服务器实现了集中化运维；通过标准映像库固化最佳实践；通过 CPU 池化、服务器池化建立高效、可“按需变化”的服务器基础架构；这些探索我们为实现整个网络支撑网IT基础架构的自动化、标准化部署和应用奠定了坚实基础。

江苏移动网管室经理吴翔评语：

1. 网管系统自2007年引入IBM主机，几年来已陆续覆盖各重要系统，产品稳定、服务响应及时、有力支撑了各系统的稳定运行。很好满足了网管系统近年来日益提高的高可用要求。

2. 本次江苏移动网管系统虚拟化实施IBM提供了前沿的动态基础架构解决方案，建立了灵活、弹性的基础架构，提出了标准化的部署模式，提高了资源利用率和维护效率。很好的解决了目前网管系统发展中遇到的种种难题。通过创新互动，双方合作达到了一个新的高度。