電信運營商的云計算資源池部署方法概述

燕 杰，樊勇兵，金華敏，唐 宏

（中國電信股份有限公司廣東研究院 廣州510630）

1 引言

云計算是近年來IT和互聯網領域研究的熱點，國內外的電信運營商也開始進行積極的探索、研究、試驗和應用。按照業界的一般理解，云計算存在IaaS（infrastructure as a service，基礎設施即服務）、PaaS（platform as a service，平臺即服務）、SaaS（software as a service，軟件即服務）3 種服務模式[1]。IaaS對內能夠進行IT資源整合，提高資源利用率，對外能為用戶提供按需付費的彈性基礎設施服務，是電信運營商研究和應用云計算、實現集約運營的關鍵切入點之一。

在談云計算的時候，首先要明確“一朵云”是什么樣的。根據業界對IaaS的理解，在云計算的語境下，計算、存儲等IT設施是以資源池的形式出現的，筆者認為，可以將一個資源池作為“一朵云”。“一朵云”中包括了大量的服務器、存儲和網絡設備及相應的管理系統。但是，從技術現狀和管理水平兩方面看，資源池的規模不可能是無限大的，資源池的數量也是需要規劃的。對于全國性的大型企業，尤其是國內電信運營商而言，如何劃分資源池、如何構建資源池、應用系統如何評估、是否適合遷移至資源池都是要考慮和解決的問題，而目前業界還沒有公開的、成熟的規劃部署方案。本文將結合云計算IaaS技術特點與發展現狀，提出資源池的規劃部署方案。

2 云的劃分方式

為方便描述，選取一個典型的國內電信運營商管理架構模型，并以此模型為藍本討論電信運營商部署云計算資源時如何對云的類型和數量進行劃分。本文選取的電信運營商管理架構考慮了國內電信運營商的企業發展歷史、經營體制、業務類型及規模等因素，其模型具有如下3個特點。

（1）地域范圍廣

電信運營商業務覆蓋地域廣闊，至少包括20個區域（一般而言，一個區域是指一個省級行政單位），橫跨地市眾多，用戶數量龐大。

（2）總部和分部兩級管理

整體運營由總部統籌管理，在各區域設置地方分部機構，管理和運營區域內業務。

（3）按照專業類型進行網絡資源與IT資源的建設和管理

可劃分為基礎網絡、業務網絡和IT系統。基礎網絡主要是接入各類用戶、提供網絡承載服務和基礎資源出租服務；業務網絡主要匯聚了3類平臺，一類是電信運營商直接對外提供服務的業務類平臺，一類是短信、彩信等電信能力類平臺，另一類是實現業務受理流程、處理業務訂購關系、資源監測管控等管理功能的管理類平臺；IT系統主要是運營商內部的MBOSS，包括了計費、CRM、OA等內部系統。具體的管理架構模型如圖1所示。

對于電信運營商而言，在考慮云計算技術，尤其是IaaS技術的引入和部署時，基礎網絡、業務網絡和IT系統都可以作為重要切入點。具體來說，可以與基礎網絡中已有的基礎資源出租服務相結合，開展虛擬服務器、存儲空間出租等云計算服務；可以在業務網絡和IT系統中分別引入計算虛擬化和存儲虛擬化等技術進行基礎設施的資源整合，提高資源利用率和業務上線速度。

從品牌宣傳角度看，“一朵云”的范圍應該涵蓋電信運營商的云計算建設發展內容，讓外界認同電信運營商云計算的完備性，因此，云的名稱數量越少越好，更能讓外界認同電信運營商云計算的整體性和統一性。從部署建設的角度看，“一朵云”是為某個管理單位（如省公司）的某個運營目的 （如解決重要的生產需求和管理問題）而服務的，在“一朵云”里，需要層次化、模塊化地進行規劃，云的資源可以分散在多個地域，但必須實現統一管理，對“統一管理”的定義不同會導致云的大小不同。

通過上述論述，部署云計算資源池時，主要根據以下兩個因素進行劃分。

（1）管理架構

在上述模型中，業務覆蓋地域范圍廣是無法改變的客觀因素，總部和分部的兩級管理也是大型企業最有效的管理架構之一，而且還沒有變動的驅動力。因此總部和各分部可能會獨立部署資源池，各資源池是平級關系并具有松耦合性，可通過本資源池的管理平臺進行獨立管理；從全網資源統管的角度，可以在總部層面設立全網的管理監控平臺，統一呈現、監控、調度資源。

（2）解決的問題域

在總部或各分部內，可以從對外提供彈性資源出租服務、對內進行業務平臺資源整合、對內進行IT系統資源整合3個方面進行劃分，可以劃分為4種方式。第1種方式是分別解決3個專業類型的問題域，為資源出租服務、業務平臺、IT系統分別部署1個資源池；第2種方式是按照資源池所承載的業務是對內服務還是對外服務進行劃分，為資源出租服務、業務平臺等直接對外提供業務的應用服務部署1個資源池，為不直接對外的IT系統部署1個資源池；第3種方式是按照業務所需的基礎設施資源是運營商內部自用還是對外出租進行劃分，為資源出租服務部署1個資源池，為各類業務平臺、IT系統部署1個資源池；第4種方式是完全打破專業領域，為資源出租服務、業務平臺、IT系統統一部署1個資源池。4種方式的對比見表1。

對于計算、存儲資源需求量大的分部機構可以根據自身的運營管理情況，按照方式1、方式2或方式3進行部署建設，但需要保證管理平臺遵循相同規范，資源池統一規劃，以便于后續資源池的整合與統一管理。

對于計算、存儲資源需求量小的分部機構直接按照方式4進行部署建設，統一管理本省所需的計算存儲資源。

對于總部機構，建議根據各分部機構的劃分方式，盡可能選擇與大多數分部機構的劃分方式相適應的部署方式。

與電信運營商在企業發展過程中的管理集中/分散、網絡整合/拆分過程一樣，云的發展可能也是螺旋式上升的過程，資源池可能將面臨不可預料的融合與拆分，其大小與數量也將隨之變化，但最終趨勢還是走向融合。

圖1 國內電信運營商管理架構模型

圖2 資源池技術架構

3 資源池的構建

3.1 資源池的技術架構

按照上述思路和原則劃分資源池后，各個資源池在體系架構上應該是趨同的，技術架構如圖2所示。

資源池技術架構主要包含物理資源、虛擬資源、軟件資產和云管理平臺。

·物理資源主要包括服務器、存儲設備和網絡設備，其為IaaS服務提供了最底層的物理資源能力。

·虛擬化資源池是指通過服務器虛擬化、存儲虛擬化、網絡虛擬化等技術，將物理設備資源進行池化，抽象成可管理、可調度的邏輯資源。

·軟件資產目前主要包括操作系統的存放介質和License，是實現虛擬機模板定制和管理的重要要素。

·云管理平臺定位于實現對云計算資源的可管、可控和可運營，通過實現對物理設備（服務器、存儲和網絡）、邏輯資源（計算資源、存儲資源和網絡資源）的統一管理、監控和部署調度，實現異構虛擬化技術封裝的虛擬資源的管理、多個地域資源的統一管理以及業務流程管理、用戶服務管理等功能。

3.2 以“集群”為最小單位的資源池部署方式

本文建議電信運營商在建設云計算資源池時，按照“管理域”、“集群”兩級進行規劃、部署和管理，如圖3所示。

所謂“集群”，是云計算最初建設的最小單元，一個集群的設備必須在同一機房甚至同一LAN內，其軟硬件設備應盡可能避免異構。提出集群的概念，是考慮到虛擬機熱遷移范圍、單節點物理機納管數量、共享存儲訪問效率都受限于現有虛擬化技術，需要定義和劃分建設部署一個基本單元，以保證該單元的性能最優化和效率最大化。

所謂“管理域”，是從業務類型的維度進行劃分，通過云計算管理平臺的分權分域，將承載相同業務類型的集群納入統一管理域。提出管理域的概念，是考慮到同類型的業務可能由同一個前端業務團隊和同一個后端維護團隊進行管理，按照業務類型或管理團隊進行邏輯劃分能更好地與現有體制銜接，實現平滑過渡。

該部署方式的主要優點有如下3個。

·軟硬件同構，更容易體現云計算的技術特點，實現業務熱遷移。集群內的軟硬件都盡可能保證同構，避免異構帶來的兼容性和互通性問題，能夠最大程度地保證集群內的虛擬機實現自動、在線的熱遷移。

圖3 “管理域”和“集群”兩級的資源池部署方式

·實現差異化承載。不同的集群可以使用不同的虛擬化解決方案，可以同時承載處于不同生命周期階段的業務，實現不同成本、不同功能的業務差異化承載。例如，對于成長期的業務應用，可以采用高成本、功能豐富的虛擬化軟件；對于衰退期業務，可以采用低成本的虛擬化軟件。

·方便規劃和建設。明確了集群作為規劃和建設的最小單元，能夠實現最小單元化和單元建制化，方便云計算環境的規劃和后續擴展；能夠為規劃、建設和運維人員提供明確的物理對象，方便其定位和管理。從技術角度看，集群由計算子系統、存儲子系統和網絡子系統構成，具體架構如圖4所示。

（1）計算子系統

配置8～16臺x86服務器；建議每臺服務器的硬件配置（包括CPU、內存、網絡接口）在類型和數量上均一致；支持硬件輔助虛擬化技術，如Intel的VT技術和AMD的AMD-V技術；網絡接口配置為4～8個；使用相同廠商和版本的虛擬化軟件。

（2）存儲子系統

在規模部署的前提下，建議使用SAN技術。如果使用FC SAN，則需要部署SAN交換機；如果使用IP SAN，建議使用專用的存儲交換機形成獨立的存儲網絡，避免和其他網絡數據流量搶占帶寬。

（3）網絡子系統

接入交換機需要支持VLAN、QinQ、QoS等功能；建議通過物理端口+VLAN的方式，將物理服務器的上聯通道劃分為業務數據通道、虛擬機遷移數據通道、虛擬機管理通道。

4 已有業務系統遷移至云計算資源池的可行性評估

云計算資源池建設部署完成后，需要考慮將已有的業務從物理服務器環境遷移至云計算資源池中，由于已有業務的業務定位與發展情況、應用架構、物理資源占用情況都不盡相同，需要進行一個細致的可行性分析評估和判斷已有業務是否適合遷移至云計算資源池中。如何對被遷移系統進行有效的系統評估，為遷移和整合提供有效的支撐數據，是遷移前的重要工作，也是遷移和整合過程中的一個難點。可行性評估可以從驅動力與配備條件是否具備、技術上是否能夠遷移、技術上是否適合遷移3方面進行。

4.1 驅動力與配備條件

首先，需要從近期及長遠的角度明確遷移的驅動因素是否存在及合理，如遷移后能夠節約建設成本、提高業務部署效率和靈活性、對企業更高層面的戰略目標執行有幫助。這些因素是決定遷移必要性的首要因素，只有在具有明確驅動力的情況下，才考慮后續的遷移工作。

其次，需要確認資源池建設完成后是否能正常運行，考慮是否具有相關的運維人員和維護保障手段。這些因素是考量是否進行遷移工作的客觀條件。

4.2 遷移的技術可能性

首先，需要明確應用系統是否能運行在x86服務器上。如果應用系統不能運行在x86服務器上，則不能采用虛擬化技術，因此無法遷移至云計算資源池中。

圖4 集群具體架構

其次，需要確認應用系統是否需要配置特殊硬件，如窄帶卡、中繼卡、3D卡、顯卡、加密卡、磁帶機、infiniband等。如果具有特殊硬件配置，則不能采用虛擬化技術。

再次，需要確認應用系統首選什么操作系統，版本編號是什么，還有哪些候選的操作系統。檢查首選操作系統版本是否在主流的虛擬化軟件的兼容列表內，如果不在兼容列表內，則檢查后續操作系統版本是否在主流的虛擬化軟件的兼容列表內，如果仍然不在兼容列表內，則不能采用虛擬化技術。

4.3 遷移的適宜程度

可以從3個方面評估業務遷移的適宜程度：業務的保障要求、已有硬件配置和資源利用情況、應用系統架構與業務邏輯。

4.3.1 業務保障的要求

評估業務應用的業務規模和活躍用戶情況，評價業務目前處于生命周期的哪一個階段，如發展期、成熟期、衰退期，根據對業務的評估結果判斷使用什么類型的虛擬化軟件。如果業務保障要求高，建議使用商用成熟度、可靠性高等高級功能完善的虛擬化軟件，但購買成本相對較高；如果業務保障要求不高，可采用低成本、只具有基本可靠性功能的虛擬化軟件。具體的判斷方法見表2。

另外，部分虛擬化軟件目前還不支持雙機熱備份，如果業務應用需要部署服務器的雙機熱備份，則需要選用能夠支持此功能的虛擬化軟件。

表2 根據業務保障要求判斷虛擬化部署方案

4.3.2 已有硬件配置和資源利用情況

從傳統的物理環境遷移至虛擬機環境，需要詳細了解已有的硬件配置和在傳統環境下的資源利用情況，便于更明確地考慮虛擬化環境下各個虛擬機的角色定義和配置。需要從以下幾方面考慮。

·目前采用什么配置的物理服務器安裝該應用系統，CPU、內存、硬盤、網卡、HBA卡的配置是什么。根據此問題答案，可以將現有的物理服務器配置直接轉換為虛擬機的配置進行試運行，在試運行期間可以根據實際資源利用率再進行調整。

·應用系統是否需要高CPU運算，CPU平均利用率是多少。

·系統運行時占用大量內存，內存平均利用率是多少。

·應用系統是否有大量對存儲的I/O讀寫操作，如經常進行大文件的拷貝。

·應用系統運行時是否需要處理大量的網絡流量，平均網絡流量是多少。

根據上述問題，梳理應用系統中的各個物理服務器對CPU、內存、存儲I/O、網絡I/O中哪類資源有較高的占用需求。最適宜遷移至虛擬化環境的，是對4類服務器資源占用率都較低的物理服務器。對于在物理環境下已經采用高配置的服務器，如果系統運行時CPU、內存、存儲I/O、網絡I/O中有一類資源的利用率長期超過70%，為保證系統運行效率，不建議遷移至虛擬化環境。對于其他情況，需要結合物理服務器對資源密集占用的類型總體考慮虛擬機的部署，如為避免多個同樣是內存密集型的物理服務器在虛擬化后放置在統一物理服務器上，應盡可能將資源占用密集的物理服務器通過虛擬化后部署在同一臺物理服務器上，實現服務器CPU、內存、存儲I/O、網絡I/O資源的充分復用。

在進行硬件配置和資源利用率信息收集時，建議使用專門的工具（如hp的CAT、VMware的CP）收集相關信息，保證信息的精確性。同時，信息收集周期至少為2周，盡可能收集到應用系統在業務峰值和谷值時的資源利用率信息。

4.3.3 應用系統架構與業務邏輯

在評估業務應用遷移至虛擬化環境的適宜程度時，需要考慮應用系統的架構和業務邏輯。

需要明確應用的系統架構，了解系統由哪些模塊構成、各模塊之間如何工作。

需要明確在傳統方式下，系統的物理部署拓撲圖如何，物理設備與邏輯模塊的對應關系如何，各服務器所承擔的角色分類是什么，每種角色服務器的功能是什么。

根據上述兩問題的答案，明確從物理環境轉變為虛擬化環境后，虛擬機需要承擔哪些系統角色，建議謹慎評估以下系統角色的虛擬化：運行音視頻流媒體引用程序的系統、大型數據庫系統（如 Oracle、DB2數據庫軟件）以及運行CAD、CAM、PRoE等工程設計應用程序的系統。

需要明確系統模塊之間的業務邏輯如何，與之對應的物理設備之間的網絡互訪流量情況如何。參照此問題的答案，進一步明確物理服務器在轉變為虛擬機后是集中部署在一臺服務器中還是分散在多臺服務器上。從提高系統運行效率的角度看，可以將業務邏輯關系密切、網絡互訪流量較大的設備角色放置在同一臺物理服務器上；從設備角色的業務邏輯關系看，可以判斷設備間的依賴關系和系統間的邏輯關系，為確定遷移依賴關系、遷移順序和遷移后位置提供有力的參考。

5 結束語

結合電信運營商跨地域、跨專業領域、總部/分部兩級的特點，從技術實現、運營管理、投資成本3方面進行考慮，為電信運營商部署云（資源池）的數量提供決策參考。從技術體系角度提出了資源池的技術架構，并從網絡部署角度明確了資源池在現網中的部署方式。在制定資源池構建方法的同時，明確了對現有業務的云化評估思路，從驅動力與配備條件是否具備、技術上是否能夠遷移、技術上是否適合遷移3方面提出了評估原則和方法。

云計算的部署技術和方案還處于發展階段，尤其在電信運營商領域還沒有成熟的部署和管理方案，相關的部署思路、技術架構、構建方案和演進路線還需要進一步的研究和驗證。

1 IBM虛擬化與云計算小組.虛擬化與云計算.北京:電子工業出版社,2009

2 Open Cloud Manifesto.http://www.opencloudmanifesto.org,2009