中国移动江苏公司（以下简称“江苏移动”）网络支撑系统自2000年开始建设了话务网管、数据网管、传输网管、电子运维、综合资源管理、7号信令监测、数据业务监测、网间信令监测、自动拨测、动力环境监控、综合监控、综合分析、网优平台、网络投诉处理平台、IT网管、安全管控平台等近20套专业网管支撑系统。这些支撑系统所管理的数据从方方面面监控了移动通信网络的运行信息，从而支撑各项运维工作的顺利开展。
江苏移动的网络支撑系统已形成一定规模，业务支撑系统遇到的问题在网管中都会遇到，并且有着自身的特点：单一系统的规模较小、种类繁多，调整频繁、主机资源利用不均衡。基于系统现状和对发展的思考，江苏移动引入IBM动态基础架构理念，尝试部署主机动态资源池，有效解决了网管系统“演进”过程中遇到的一些难题。
网管系统IT架构的 诸多挑战
江苏移动的用户规模已突破5000万，其网管支撑系统的规模也经历了一个从量变到质变的过程，从管理着几个分散的网管系统到运营着一个大型的数据中心。在演变中，不仅遇到了其他数据中心从小到大时所必经的一般性问题，还存在自身沿革过程中产生的特殊性问题。
“烟囱式”基础架构—每个系统的建设都需要采购完整的服务器设备，如WEB服务器、应用服务器、数据库服务器、存储交换机、存储磁盘等。这种传统建设方式导致了诸如服务器物理台数的快速增长、采购成本高昂、各系统之间计算资源不可综合调度利用以及IT运维人员工作负荷过高等不尽合理的诸多弊端。
IT基础设施缺乏弹性—话务网管系统的正常运行直接影响一系列重要运维KPI指标，其对安全性与稳定性有着极高的要。峰值负载时需要至少18颗CPU的一台服务器来满足处理的要求，而平均负载仅需要2～4颗CPU。由于采用独立物理服务器或静态分区技术，网管系统的部分服务器计算能力未能充分利用。
容量规划困难—容量估算涉及因素很多，如未来业务总量、用户数、性能要求、应用程序开发水平、各系统间交互等。但上述信息通常并不完整或根本没有，只能参照类似系统或猜测系统生命周期中工作负载的增长。如此，业务部门难以对需求估算精确，有时会导致设备超量抑或上线不久因负荷过高而紧急扩容。
建设维护缺乏规范性—江苏移动网络支撑网各个系统的维护管理虽按应用和平台进行了区分，但平台管理员仍需了解主机硬件、操作系统、数据库、中间件甚至备份的各方面知识。但现实中由于管理员精力和时间有限，加上各层面的管理工具、方法也有诸多差异，管理员难以全面精通或掌控各个层面的管理。
应用平台整合初见成效
以前按项目买设备，设备只是被某项目独占，而非共享，因此某些设备上的资源是多余的，但是另外的项目却不能够利用它。所以一定程度上造成资源的浪费。利用服务器虚拟化技术，打破应用和 IT 资源之间的绑定关系，把应用和硬件解耦合，多个应用能共享 IT 资源。
同平台应用整合
同平台应用整合从技术容易实现，成本和风险都比较小。要整合服务器资源，非常重要的前提是梳理各个网管系统的运行特点，也就是说，需要非常明确的知道各系统的峰值负载、节假日突发高峰、批处理时间、响应要求、业务等级等等。在明确了这些信息之后，制定资源整合计划。通过评估，有些业务是可以通过分区整合到一台服务器上的，可以获得明显的利益，较少甚至没有负面影响。而有些业务不合适整合，遇到类似情况，我们也不会为了整合而整合。在整合服务器资源中，我们也注重探索集成多种环境，获得理想的技术组合，以实现服务目标。如图 1，对于压力较大，且重要级别较高的系统如话务网管、资源管理等被部署到独占 CPU 的动态逻辑分区上，并配置独立的物理板卡，以保证性能。对于压力较小的 PBOSS 系统，我们通过微分区来部署，且由于其 I/O 流量很小，因此可以通过虚拟 I/O 服务器（VIOS）来共享以太网卡和存储卡，在不影响业务效率的前提下，减少了物理设备，提高了灵活性。
控制台集中管理
通过 IBM Systems Director 集中控制台，实现跨机房、多网段的服务器的自动发现（通过 IP 地址），系统同时能自动更新已发现服务器的信息。管理员能借助这套系统快速的了解每台服务器，如物理、逻辑、或虚拟硬件，操作系统类型及版本，硬件固件及 BIOS 信息，所安装的软件信息等等。
通过制定系统一致性策略，管理员可以实时监控受管系统更新状态和自动接收更新提醒，这包括了受管操作系统和服务器固件更新管理。
Director 同时整合了多个硬件管理控制台（HMC），提供了层次化的资源关系表以及图形视图。管理员可以利用这些关系表和视图方便查看服务器拓扑结构和虚拟化层次。
问题定位和瓶颈识别
管理员可以自定义一个 Systems Director 集中受管系统健康状况视图，所有受管系统硬件层面告警都将集中在该视图展现。通过设置过滤，管理员可以快速检查重要告警信息，比如CPU 利用率、内存利用率、I/O 吞吐量、页交换等等。监控结果可以触发自动化响应策略。
对划分了分区的服务器来说，Director 分别显示每个分区的资源利用率，同时也显示整台服务器的资源利用率。这对于采用了超用 CPU 模式（uncapped）的微分区来说，是非常关键的。管理员根据这些信息来动态评估服务器的分区规划是否合理。这些历史性能信息也为管理员进行服务器容量规划提供依据。
主机CPU、内存自动化弹性调整
通过分区虚拟化实现同平台应用整合，仍然处于静态方式。业务是动态发展的，网管中心的支持要能对此作出快速响应。服务器 CPU 池化的技术很好的解决这一问题。
基于 Power 服务器微分区，我们设置两种策略来确保分区能自动实现弹性化调整：首先多个业务分区共享多个物理 CPU，每个分区设定适量初始授权 CPU 用量以及适量的虚拟 CPU 个数，这非常关键。业务分区在压力很小时，虚拟 CPU 基本不占用或只用很少量的物理 CPU 处理能力。当某个分区业务突发增大时，该分区的虚拟 CPU 可实时动态的调用更多物理 CPU，在超过初始授权值时，只要 CPU 池中还有空闲物理 CPU，那么该分区可以超用 CPU。第二，我们在必要的情况下可以对各个分区设定合适的权重。如果有多个分区都超用 CPU，权重较大的分区在超用 CPU 时可以占用较多的资源。这种调整都是可以动态实现。
构建资源池与映像库
业务部门需要基础平台，传统上的流程较复杂，首先用户提出要求，然后 IT 部门新购（或利旧）设备，物理设备连接，安装操作系统、打补丁，安装应用软件、打补丁等，最后测试再提交使用。流程长，牵扯较多人力，各个系统之间的软件版本也较难保持一致性，导致维护复杂。
在实现统一服务器管理的前提下，再结合服务器虚拟化技术，使得我们有能力构建“统一管理，优化标准，快速部署”的 IT 基础环境。
首先是服务器被统一管理，纳入计算资源池中。然后，我们通过 Director 对常用的软件版本组合（操作系统、数据库、中间件等）进行捕捉，创建标准化映像，保存在统一映像库中。在需要新基础平台时，管理员通过 Director 在计算资源池中查找合适的受管服务器，然后从映像库中选择合适的映像。之后 Director 能自动创建分区，并把映像部署到指定的受管服务器上。整个部署过程都通过网络进行，管理员不再需要到现场。 交付使用的系统，也被纳入统一监控系统中，结合用户的反馈意见等，管理员可以优化、创建新的系统映像保存在映像库中。
