漫談：基于云服務的運維模式初探（云計算漫談之二）

雖然說公有云向普通用戶屏蔽的很多底層細節，但通過云服務的使用方式，其實可以看到一些底層運維的機制。舉一個最簡單的例子，公有云的虛擬機服務，通常都不會做虛擬化中很常見的一個功能——在線遷移，這意味著如果需要對云服務所在的底層基礎架構進行運維時（如打補?。粫⑸厦娴奶摂M機在線遷移到其他物理節點，這時候用戶就會面臨一個問題，你的VM可能會被關閉和重啟。

如果用戶沒注意到這個問題，可能以為云服務發生了中斷，但其實這一點在【云服務的SLA】中有著明確的定義。還是以虛擬機這個云服務為例，通常單實例的VM是沒有SLA保障的，不同的云服務提供商或許有不同的定義，如要求多個VM要在同一可用性集中（或者在不同的AZ中），實質上是將多個實例分布在不同的更新域，這樣維護的時候這些VM不會同時重啟，以保證服務的連續性?？梢姡褂肰M這個云服務，對你的應用架構會有著強制的要求，即你的應用本身應該具備分布式或者高可用能力，這樣在底層基礎架構的維護窗口中，上層的應用才不會中斷。

我想，到這里你或許發現了，傳統的應用，簡單的搬遷到云服務上，這件事實際上是有問題的，風險無法規避，SLA也無法保障。當然，技術的說，這個也不是一成不變的，例如目前Azure通過【就地實時遷移】技術，已經具備單實例SLA，這里就不深究了。

以上談的內容可能有些技術了，但這件事情本質在于，云服務在試圖進一步將上層應用和底層的運維進行剝離。這絕不僅僅是一個技術問題，更會逐漸的影響到未來企業IT的【組織架構】和【運營模式】。

這里會有一個有趣的話題，一直以來，我想單純的虛擬化大家早已經想的很清楚了，但在企業中私有云的價值卻一直不顯著，其中一個原因是，私有云對降低運維成本和提高效率帶來的收益，并不足以抵消其復雜程度和IT要求提升所帶來的成本上升，或者說這種提升并不是那么顯著。那么問題來了，如果私有云也【云服務】化，其價值體現是否足夠呢？

目前華為的私有云方案正在走云服務化的道路。我想在這個時間點，我們可以看一下Microsoft Azure Stack這個方案，不同于傳統的私有云方案，Azure Stack主打的是和公有云一致的體驗和API，在微軟看來，Azure Stack相當于在企業側放了公有云Azuer的一個Endpoint，私有云的使用，完全圍繞著云服務為中心。于是乎，現在有個有意思的問題了，使用公有云，用戶可以顯著降低對運維的投入，實際上用戶也接觸不到基礎架構運維這個層面。但使用私有云，整套基礎架構實際上是放在用戶場內數據中心，如果說要一致的體驗，用戶是否也可以從降低運維投入上獲益？

在這件事情上，微軟非常大膽的做了幾點設定（由于產品尚未GA，因此以下內容不一定是最終實現方式）：

1、基于AzureStack的建設必須非常標準化，在這種標準化建設中，整個基礎架構更為模塊化，不會存在SPOF的問題，由于硬件層面徹底和軟件層面分離設計，所以硬件層面的運維完全以備件替換的方式進行。例如，任何一塊硬盤、一臺服務器、一個網絡交換模塊、甚至于一個機柜的故障告警，可以通過直接更換硬件的方式進行，更換過程中可以不考慮或者只需要有限的考慮對其上業務的影響，這些會通過標準的流程固定下來。

2、在整個云平臺的軟件層面，企業的基礎架構管理員實際上不具備完整的【本地管理員權限】，這就是說，企業基本不能對云平臺進行運維。因為所有的云服務全部標準化和微服務話，解耦程度和自動化程度相當高，企業自己的管理員只能監視有無故障發生。大部分情況下，軟件故障可以自動排除，如果出現無法排除的軟件故障，需要交付廠家（通常就是集成的硬件廠家）進行一線故障排除，由微軟遠程進行二線故障排除，這些費用已經（部分）包含在云平臺的訂閱價格中。

3、對于云平臺的補丁升級，或者更新云服務，必須由交付廠商進行，企業自己不能進行。

4、企業只對云平臺的租戶管理、資源分配具備管理員權限，使用體驗完全向公有云Azure看齊。

看起來，使用微軟定義的客戶就是【傻瓜】，你就好好用就行了，運維這么復雜的東西你就別碰了。從下面這張圖中，可以看到微軟的想法——把AzureStack做成一個高度集成和標準化的【盒子】嵌入到用戶數據中心中。

從我個人的感覺中，這個想法確實很超前，也許不適合目前90%的企業用戶，原因是對標準化和自動化的要求太高了。但如果用戶非常習慣使用云服務來搭建企業的云平臺，這種方式或許是私有云價值體現的一條路徑。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。