中國移動江蘇公司（以下簡稱“江蘇移動”）網絡支撐系統自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 能自動創建分區，并把映像部署到指定的受管服務器上。整個部署過程都通過網絡進行，管理員不再需要到現場。 交付使用的系統，也被納入統一監控系統中，結合用戶的反饋意見等，管理員可以優化、創建新的系統映像保存在映像庫中。