編者按:管理是IT系統良性運行的重要保障,不同的IT設備都有自己的管理系統。 特別是大規模資料中心,必須通過集中的管理系統來運行管理計算、存儲、網路等設備,以能夠快速回應和處理資料中心的業務變更、異常事件、持續優化。 在《IP領航》往期的文章中曾多次聚焦「資料中心的管理」,但大都側重于「以網路為核心」的管理,本文將把視線放大到整個雲計算環境下的資料中心,對三種運行管理模型逐一對比分析。
傳統資料中心,基礎架構層面設備之間通過標準化連接和協定互通,保證了計算、存儲、網路設備的管理系統之間相互分離、獨立(如圖1所示),從而使得不同的運維團隊可以按照自身業務發展與架構演進的趨勢不斷完善和深化各自的管理規程, 滿足資料中心業務不斷發展的要求。
圖1 傳統資料中心管理運行架構
在雲計算環境下,各自獨立分離的運行模式不能支援雲服務的展開,新的IT運行模式對傳統的管理架構提出了挑戰:
虛擬化: 傳統資料中心中每個物理伺服器上只是單個或幾個應用的固定運行,業務基本是與主機的綁定運行方式,對主機的管理,某種意義上也就是對業務的管理。 雲計算環境下伺服器大量採用虛擬化技術,每一個物理網路埠下都會分佈多達數十個虛擬機器,物理主機上運行著多個不同的作業系統和應用,網路中應用密集度極大增長,對網路的性能、規格、可靠性都提出更高要求, 而虛擬機器網路屬性的可管理性更是面臨巨大挑戰。
動態性: 傳統資料中心的業務針對物理主機展開,而物理伺服器一般固定連接在某個網路埠上,並且業務屬性單一,無論是網路原則、安全控制都比較固定。 只要主機與網路運維介面清晰、系統歸屬明確,則業務容易展開,並能平穩運行。 但是雲計算環境下部署著高密度的虛擬機器,在虛擬化環境下,基於服務變更、容災、分散式運算等業務運行要求使得虛擬機器動態遷移成為必備屬性。 如果網路無法感知這種動態性計算方式,持續的運行必將造成業務的紊亂、運維的不可控,這就要求管理系統能夠具備動態計算的感知能力。
關聯性:當前的網路與計算之間以一種松耦合方式運行,網管與主機管理系統之間基本上沒有資訊關聯交互,這樣,對於虛擬化資料中心,虛擬機器的動態性計算特性,網路無法感知、網路管理系統無法對虛擬機器進行定位,網路對業務的安全、控制、 配置、監管便無法關聯到虛擬機器,無法實現雲計算下的靈活部署和擴充性。
自動化:在非虛擬化環境中,業務部署後一般都具有相對的固定性,即主機位置、網路接入比較確定,運行維護的目標與物理機、物理埠一致,這種情況,主機系統、網管系統分別部署、調試對接相對比較容易。 但在大規模資料中心,特別是雲計算環境下的業務流程,基於傳統的分離調試是無法有效支援雲服務的業務模式,這就要求整個服務的供應應能夠簡單提交、且不同系統(基礎的計算、網路,上層的主機、網路管理系統)之間能夠交互服務資訊, 並基於一致的業務要求完成所有部件的自動化部署與運行。
雲計算管理的目標
為了支援雲計算虛擬化、動態化、關聯性、自動化的服務要求,整個雲計算系統需要有一個統一的操作運行管理平臺,能夠對雲服務進行端到端自動化部署,同時快速回應資源調度與業務變更的服務需求(如圖2所示)。
統一的服務平臺能夠遮罩雲服務供應層面對底層不同架構的差異,使得使用者或業務運營部門聚焦在服務層面,不必關注雲計算資源(計算、網路、存儲)本身的技術屬性。
在自動化回應的管理關聯結構上,雲服務的提供需要將業務需求轉換為對基礎資源的部署要求,並形成相應的底層配置下發到不同的設備上,同時在服務變更(包括容災、虛擬機器遷移、擴展等資源的操作與調度)過程中, 能夠全方位調整底層設備的配置、功能、對接,以匹配業務需求。
2 如何選擇合理的運行管理模型
模式一:集中統一的雲計算運行管理
為了實現靈活的雲計算服務,有些人提出了一種以統一集中的方式進行資料中心基礎架構的運行管理模式(如圖3所示)。 這種模式下,雲的操作管理平臺能夠對計算、存儲、網路進行整合,在使用者操作平面上形成單一的介面,在邏輯結構、運行結構上很清晰,管理層次少。
這種結構雖然在一定程度上實現統一的業務部署、基礎資源的自動化調度,但局限性很明顯。 不同的IT系統有其固有的專業性,網路、計算、存儲各個系統的監控運行、故障處理、軟硬體升級、容量與規劃完全不同,要在一個管控系統中既做到業務的統一,又做到基礎管理的全面,不僅對這個系統本身的規模、複雜性、功能性、 專業性提出了挑戰,而且對於支撐管理運行的團隊,也在操作配合、知識體系、專業交叉上產生了巨大的複雜度。
即使是一個廠家能夠以極高的專業程度整合多個基礎資源的運行管理到這樣的統一系統,這個系統也必將非常巨大、複雜,其本身的運行維護也會存在極大難度。
模式二:雙屬式管理
第二種模型是雙屬式管理模型。 如圖4所示,在類似第一種模型的架構下,除了統一的運行管理平臺,在計算、存儲、網路各個系統中集成各自專業的管理系統。 相比模型一,模型二有極大的增強,不僅可以簡化統一運行管理平臺的複雜度,又引入了傳統成熟的運維管理方式,並分離了雲計算的服務運營與基礎架構管理,形成一個具有分工與協作的IT運行結構。
但這種模式的不足在於,對底層物理設備而言,存在兩套指令系統:供應雲服務的統一管理平臺和獨立的運維繫統,如果存在操作上的偏差,需要這兩套系統之間預先定義或確定一個優先順序, 否則在某些條件下將導致因不同系統的指令衝突造成服務的異常。 同時,對於基礎設備來說,兩套指令系統的調用介面或協定也可能完全不同,甚至由於當前標準化的不足,針對不同的雲管理平臺有不同的定制化要求,帶來了基礎設備運行與設計上的複雜。
模式三:三層式管理
第三種模型是三層式管理模型。 如圖5所示,統一的雲管理平臺運行在一個邏輯層面(Top Tier),向雲計算使用者提供服務介面、雲服務供應操作,不直接管理和操作底層設備。 中介層(Middle Tier)是基礎資源操作管理層,接受來自上層的雲服務調用,並轉換為針對底層設備的配置操作,中介層同時作為專業化系統對基礎設備執行運行、維護、監管等功能。 最下層為基礎設備層面(Infrastructure Tier),是計算、網路、存儲等基礎雲計算資源連通運行形成的實體層,接收來自上層的指令而運行和提供服務。
對於三層式模型,中間管理層統一了來自雲服務管理平臺的指令和自身的運維變更指令,形成一致的操作集下發,保證了操作的統一性。 特別是對雲計算而言,上層服務的部署、變化總是會涉及到底層多個系統之間的相互關聯性變化,如虛擬機器動態計算的特點使得其網路位置發生變化,存儲資源也會因為資料移轉產生位置變更,這都涉及到計算、網路、存儲各個物件之間的資訊交互、 協定通告、連線性檢查等處理,以保證雲服務的連續性與持續性。 資料的流轉與基礎協定交互發生在第三個平面,但是在中介層不同資源的管理控制系統之間也主動進行資訊傳遞,如虛擬機器管理系統與網管系統之間交互計算遷移、狀態與位置等資訊,這使雲服務的管理過程更為精確和可控, 能夠實現全部IT基礎資源之間的關聯性,並使得雲計算的部署逐步走向更為完善的自動化。
三層管理模式更進一步的好處是,中間管理層作為對基礎資源層面的指令層,因其完全由軟體構成,具有需求變化的能力,即能夠封裝多種來自服務層面、異構系統之間的交互操作資訊,形成下層易執行的指令下發到基礎設備上。 如圖6所示,每一種基礎資源與其管理軟體構成了一個靈活的按需變化的IT系統,它們對外的變化介面主要由管理軟體來實現,當前通用的SOAP/RESTful等介面已經廣泛用於軟體系統之間的調用, 以EVB技術實現為例:網路與網管之間完全緊耦合實現網路系統內部的運行控制管理,虛擬管理中心與伺服器虛擬化系統之間完全緊耦合實現虛擬計算內部的運行控制管理;在Infrastructure Tier層面, 網路與虛擬機器系統之間通過標準技術EVB來實現資料互通與協定交互,這是整個雲計算得以實現自動化、動態性、關聯性的基礎互通標準要求。 而在控制層,網管系統與虛擬管理中心則通過SOAP/RESTful介面方式可以靈活定義這兩種異構系統之間要求傳遞的資訊(虛擬機器標識、業務類型、網路標記、網路屬性等),從而實現了整個雲計算系統的底層資料流程轉、 控制層面業務屬性流轉。
三種模型的對比小結
就目前國內使用者應用情況而言,使用者對計算、網路、存儲分離的管理運行已經形成很好的經驗,這在雲計算環境下依然是很好的借鑒;在考慮向雲計算轉型/演進的架構上,服務交付與IT運行可能是相互獨立,但又是前者依賴後者、 後者以前者為目標的業務方式,這就要求雲的管理運行架構既要有很大的靈活性,又要有對基礎層面控制的精准性。 模型一是當前很多使用者認為很自然的結構,因為這個模型很含糊地掩蓋了雲服務與雲基礎架構運行的差別,模型二與模型三則展開了雲計算的運行框架要求,同時還融合了傳統IT的運行管理模式,使得使用者的IT模式以漸進方式遷移到雲服務。
3 結束語
適用的資料中心管理運行模型,不僅可以使業務模型清晰可靠,並能極大提升業務運行能力,使得傳統資料中心的運行機制得到重用。 但是,不同的雲計算服務模式有其自身特點,基於自身的運行能力、已有系統的要求,選擇並演進到適合每個雲計算資料中心適用的模式,需要使用者、廠家、服務供應商持續的適配、調整才能優化形成。
【編輯推薦】
討論雲計算時代下資料中心架構雲計算時代需要怎樣的資料中心架構? 雲計算面臨大資料和混合雲考驗【責任編輯:芳馨 TEL:(010)68476606】