1. 云計算對運行管理變革的驅動

傳統數據中心，基礎架構層面設備之間通過標準化連接和協議互通，保證了計算、存儲、網絡設備的管理系統之間相互分離、獨立（如圖1所示），從而使得不同的運維團隊可以按照自身業務發展與架構演進的趨勢不斷完善和深化各自的管理規程，滿足數據中心業務不斷發展的要求。

圖1 傳統數據中心管理運行架構

在云計算環境下，各自獨立分離的運行模式不能支持云服務的展開，新的IT運行模式對傳統的管理架構提出了挑戰：

虛擬化: 傳統數據中心中每個物理服務器上只是單個或幾個應用的固定運行，業務基本是與主機的綁定運行方式，對主機的管理，某種意義上也就是對業務的管理。云計算環境下服務器大量采用虛擬化技術，每一個物理網絡端口下都會分布多達數十個虛擬機，物理主機上運行著多個不同的操作系統和應用，網絡中應用密集度極大增長，對網絡的性能、規格、可靠性都提出更高要求，而虛擬機網絡屬性的可管理性更是面臨巨大挑戰。

動態性: 傳統數據中心的業務針對物理主機展開，而物理服務器一般固定連接在某個網絡端口上，并且業務屬性單一，無論是網絡策略、安全控制都比較固定。只要主機與網絡運維界面清晰、系統歸屬明確，則業務容易展開，并能平穩運行。但是云計算環境下部署著高密度的虛擬機，在虛擬化環境下，基于服務變更、容災、分布式計算等業務運行要求使得虛擬機動態遷移成為必備屬性。如果網絡無法感知這種動態性計算方式，持續的運行必將造成業務的紊亂、運維的不可控，這就要求管理系統能夠具備動態計算的感知能力。

關聯性:當前的網絡與計算之間以一種松耦合方式運行，網管與主機管理系統之間基本上沒有信息關聯交互，這樣，對于虛擬化數據中心，虛擬機的動態性計算特性，網絡無法感知、網絡管理系統無法對虛擬機進行定位，網絡對業務的安全、控制、配置、監管便無法關聯到虛擬機，無法實現云計算下的靈活部署和擴展性。

自動化:在非虛擬化環境中，業務部署后一般都具有相對的固定性，即主機位置、網絡接入比較確定，運行維護的目標與物理機、物理端口一致，這種情況，主機系統、網管系統分別部署、調試對接相對比較容易。但在大規模數據中心，特別是云計算環境下的業務流程，基于傳統的分離調試是無法有效支持云服務的業務模式，這就要求整個服務的供應應能夠簡單提交、且不同系統(基礎的計算、網絡，上層的主機、網絡管理系統)之間能夠交互服務信息，并基于一致的業務要求完成所有部件的自動化部署與運行。

2. 云計算管理的目標

為了支持云計算虛擬化、動態化、關聯性、自動化的服務要求，整個云計算系統需要有一個統一的操作運行管理平臺，能夠對云服務進行端到端自動化部署，同時快速響應資源調度與業務變更的服務需求（如圖2所示）。

圖2 云計算的管理目標

統一的服務平臺能夠屏蔽云服務供應層面對底層不同架構的差異，使得用戶或業務運營部門聚焦在服務層面，不必關注云計算資源(計算、網絡、存儲)本身的技術屬性。
在自動化響應的管理關聯結構上，云服務的提供需要將業務需求轉換為對基礎資源的部署要求，并形成相應的底層配置下發到不同的設備上，同時在服務變更(包括容災、虛擬機遷移、擴展等資源的操作與調度)過程中，能夠全方位調整底層設備的配置、功能、對接，以匹配業務需求。

3. 如何選擇合理的運行管理模型

模式一：集中統一的云計算運行管理

為了實現靈活的云計算服務，有些人提出了一種以統一集中的方式進行數據中心基礎架構的運行管理模式（如圖3所示）。這種模式下，云的操作管理平臺能夠對計算、存儲、網絡進行整合，在用戶操作平面上形成單一的界面，在邏輯結構、運行結構上很清晰，管理層次少。

圖3 集中統一的云計算運行管理模型

這種結構雖然在一定程度上實現統一的業務部署、基礎資源的自動化調度，但局限性很明顯。不同的IT系統有其固有的專業性，網絡、計算、存儲各個系統的監控運行、故障處理、軟硬件升級、容量與規劃完全不同，要在一個管控系統中既做到業務的統一，又做到基礎管理的全面，不僅對這個系統本身的規模、復雜性、功能性、專業性提出了挑戰，而且對于支撐管理運行的團隊，也在操作配合、知識體系、專業交叉上產生了巨大的復雜度。

即使是一個廠家能夠以極高的專業程度整合多個基礎資源的運行管理到這樣的統一系統，這個系統也必將非常巨大、復雜，其本身的運行維護也會存在極大難度。

模式二：雙屬式管理

第二種模型是雙屬式管理模型。如圖4所示，在類似第一種模型的架構下，除了統一的運行管理平臺，在計算、存儲、網絡各個系統中集成各自專業的管理系統。相比模型一，模型二有極大的增強，不僅可以簡化統一運行管理平臺的復雜度，又引入了傳統成熟的運維管理方式，并分離了云計算的服務運營與基礎架構管理，形成一個具有分工與協作的IT運行結構。

圖4 雙屬式管理模型

但這種模式的不足在于，對底層物理設備而言，存在兩套指令系統：供應云服務的統一管理平臺和獨立的運維系統，如果存在操作上的偏差，需要這兩套系統之間預先定義或確定一個優先順序，否則在某些條件下將導致因不同系統的指令沖突造成服務的異常。同時，對于基礎設備來說，兩套指令系統的調用接口或協議也可能完全不同，甚至由于當前標準化的不足，針對不同的云管理平臺有不同的定制化要求，帶來了基礎設備運行與設計上的復雜。

模式三：三層式管理

第三種模型是三層式管理模型。如圖5所示，統一的云管理平臺運行在一個邏輯層面(Top Tier)，向云計算用戶提供服務界面、云服務供應操作，不直接管理和操作底層設備。中間層(Middle Tier)是基礎資源操作管理層，接受來自上層的云服務調用，并轉換為針對底層設備的配置操作，中間層同時作為專業化系統對基礎設備執行運行、維護、監管等功能。最下層為基礎設備層面(Infrastructure Tier)，是計算、網絡、存儲等基礎云計算資源連通運行形成的物理層，接收來自上層的指令而運行和提供服務。

圖5 三層式管理模型

對于三層式模型，中間管理層統一了來自云服務管理平臺的指令和自身的運維變更指令，形成一致的操作集下發，保證了操作的統一性。特別是對云計算而言，上層服務的部署、變化總是會涉及到底層多個系統之間的相互關聯性變化，如虛擬機動態計算的特點使得其網絡位置發生變化，存儲資源也會因為數據遷移產生位置變更，這都涉及到計算、網絡、存儲各個對象之間的信息交互、協議通告、連接性檢查等處理，以保證云服務的連續性與持續性。數據的流轉與基礎協議交互發生在第三個平面，但是在中間層不同資源的管理控制系統之間也主動進行信息傳遞，如虛擬機管理系統與網管系統之間交互計算遷移、狀態與位置等信息，這使云服務的管理過程更為精確和可控，能夠實現全部IT基礎資源之間的關聯性，并使得云計算的部署逐步走向更為完善的自動化。

三層管理模式更進一步的好處是，中間管理層作為對基礎資源層面的指令層，因其完全由軟件構成，具有需求變化的能力，即能夠封裝多種來自服務層面、異構系統之間的互操作信息，形成下層易執行的指令下發到基礎設備上。如圖6所示，每一種基礎資源與其管理軟件構成了一個靈活的按需變化的IT系統，它們對外的變化接口主要由管理軟件來實現，當前通用的SOAP/RESTful等接口已經廣泛用于軟件系統之間的調用，以EVB技術實現為例：網絡與網管之間完全緊耦合實現網絡系統內部的運行控制管理，虛擬管理中心與服務器虛擬化系統之間完全緊耦合實現虛擬計算內部的運行控制管理；在Infrastructure Tier層面，網絡與虛擬機系統之間通過標準技術EVB來實現數據互通與協議交互，這是整個云計算得以實現自動化、動態性、關聯性的基礎互通標準要求。而在控制層，網管系統與虛擬管理中心則通過SOAP/RESTful接口方式可以靈活定義這兩種異構系統之間要求傳遞的信息(虛擬機標識、業務類型、網絡標記、網絡屬性等)，從而實現了整個云計算系統的底層數據流轉、控制層面業務屬性流轉。

圖6 異構系統之間的靈活接口方式

三種模型的對比小結

就目前國內用戶應用情況而言，用戶對計算、網絡、存儲分離的管理運行已經形成很好的經驗，這在云計算環境下依然是很好的借鑒；在考慮向云計算轉型/演進的架構上，服務交付與IT運行可能是相互獨立，但又是前者依賴后者、后者以前者為目標的業務方式，這就要求云的管理運行架構既要有很大的靈活性，又要有對基礎層面控制的精準性。模型一是當前很多用戶認為很自然的結構，因為這個模型很含糊地掩蓋了云服務與云基礎架構運行的差別，模型二與模型三則展開了云計算的運行框架要求，同時還融合了傳統IT的運行管理模式，使得用戶的IT模式以漸進方式遷移到云服務。

4. 結束語

適用的數據中心管理運行模型，不僅可以使業務模型清晰可靠，并能極大提升業務運行能力，使得傳統數據中心的運行機制得到重用。但是，不同的云計算服務模式有其自身特點，基于自身的運行能力、已有系統的要求，選擇并演進到適合每個云計算數據中心適用的模式，需要用戶、廠家、服務供應商持續的適配、調整才能優化形成。