混合雲的那些事,如何做到讓公有云和私有云實現1+1>2
雲端計算在2016年有了極大的增長。一方面,AWS、阿里雲等大型公有云廠商的雲端計算收入呈爆發式增長且絕對值資料可觀;另一方面,通過持續市場培育,雲端計算的價值逐步被各國政府所認可。很多大型企業也紛紛發力雲端計算,傳統IDC採購出現增長拐點。各種聲音不斷提醒人們,雲端計算不再是雷聲大雨點小的噱頭,而是成為大中小企業不可或缺的基礎設施。2017年,雲端計算真正落地的話題逐漸成為業界討論的熱門話題。
當前,私有云和公有云相爭的熱潮漸弱,融合兩者優勢的混合雲開始逐漸釋放巨大的市場潛力。混合雲的背後不再是廠商,而是一種混合IT架構,是公有云與私有云的整合。因此,如何構建基於雲端計算的混合IT架構,成為CIO和CTO避不過的問題。
本文我們首先回顧公有云與私有云的優缺點,之後聊聊到底什麼是混合雲、使用場景與產品有哪些,緊接著重點分享架構核心思路與技術實現原則,最後來說說使用者到底能在混合雲平臺上做些什麼事。
公有云與私有云優缺點
筆者曾經在公有云廠商和私有云廠商都有過研發經歷,對公有云和私有云各自能帶來的優勢和侷限都有比較深入的體會。對於市場來說,公有云和私有云都有它們無法被取代的優勢,最好的選擇就是根據自身業務結合二者,這一點也已經得到了市場的普遍認同。
混合雲的定義與使用場景
混合雲的定義
對於混合雲的定義,中國資訊通訊研究院曾經提出過觀點,是必須要同時有公有云和私有云,這也是大多數廠商和使用者的認知。筆者認為,這樣的定義只是物理上的堆徹,兩者之間如果不能發生化學反應,並不是真正的混合雲,也無法催生出創新型應用,無法真正幫助使用者提高業務價值。混合雲不是簡單的對公有云和私有云進行1+1=2的運算,而一定要讓它們產生大於2的價值。
虛擬化與雲端計算的區別
為了更好的理解這點,讓我們來回顧一下虛擬化與雲端計算的區別。虛擬化是一種技術,而云計算則是基於虛擬化技術之上的昇華,它讓使用者能夠管理一個數據中心及其增值服務,將IT資源以服務的形式交付給使用者,從而讓使用者能夠專注於業務而不是IT資源。虛擬化幫助使用者提高硬體的資源利用率,而云計算則幫助使用者提高整個資料中心的整體資源利用率,這中間也包括軟體、網路、儲存甚至於人力的資源利用率。
那麼,混合雲作為雲端計算的一種形態,它要給使用者帶來的價值,並不是簡單的把公有云和私有云堆徹在一起,而是讓兩者產生碰撞,從而提高使用者跨雲的資源利用率,催生出新的業務。
混合雲應該是幫助使用者接管跨雲、跨地域的IT基礎設施,把使用者花在底層實現上的精力解放出來,甚至可以反覆嘗試業務在公有云與私有云之間的組合模式而不用關心底層實現細節,從而極大提高使用者的生產力和降低業務的試錯成本。
故我們可以看到,混合雲不是簡單的一張皮,也不是完成連通的其中一個細節,它是包含了公有云各資源和產品以及私有云各資源和產品的一個有機整體系統。因此,同時存在公有云與私有云只是混合雲的必要條件,而非充要條件。那麼還需要有什麼呢?
混合雲在資料中心的價值
我們先來看看使用者想要什麼。在同時存在私有云和公有云的情況下,使用者自然會想到如下場景:
- 將私密資料放在本地,公開訪問入口放在公有云。
- 高峰期能利用公有云的資源進行無限拓展。
- 本地業務能加密備份在公有云。
- 多資料中心通過公有云實現星形連通。
- 開發測試在本地快速迭代,生產業務放在公有云。
- 內部業務放在本地資料中心,對外開放業務放在公有云,完全摒棄掉公有云控制檯,在本地閉環完成所有操作。
事實上由於現在真正實施混合雲的使用者非常之少,還有大量未知的創新等待著聰明的使用者去發掘。
那麼如何來實現這些場景呢?在單一的私有云或者公有云場景下,使用者不需要關心底層是如何實現的,他們使用映象建立虛擬機器,使用快照備份磁碟,搭建多個二層或三層網路並在平臺上自定義路由和安全組來進行通訊,使用Autoscaling或其他編排系統來進行資源自動編排,並在一個多租戶場景下工作。
那麼在混合雲的場景下,我們則抽象出如下實現手段:
- 建立和管理(包括運維)虛擬機器而不關心映象在哪裡或虛擬機器在哪裡。
- 建立或備份磁碟而不關心磁碟在哪裡或備份在哪裡。
- 搭建網路並定義它的通訊目標,無論是在本地資料中心或者公有云。
- 自由編排資源,無論是在本地資料中心或者公有云。
- 統一而不是割裂的帳戶管理體系。
混合雲產品主要基於災備、網路互聯和多雲管理
市場對混合雲的聲音日益龐大,但目前混合雲並沒有真正的標準,也沒有準確的定義。目前的混合雲產品主要基於以下三類:
基於災備產品
廠商通過使用者自定義的策略將使用者的資料備份到公有云,並可以恢復到本地。這主要是一些儲存廠商提供的產品,如英方雲、數騰雲、XSKY等。
基於網路互連產品
廠商主要做網路服務,幫助使用者快速完成本地資料中心與公有云的對接服務,達到互聯互通的目的。這主要是一些網路廠商提供的產品,如網銀互聯、遊馳、犀思雲等。
多雲管理產品
廠商主要做多雲管理產品,致力於幫助使用者在一套管理平臺上對多個公有云或私有云產品進行管理層面服務,增強使用者的一致性體驗,幫助使用者更好管理自己的雲端計算資源,並提供部分運維及PaaS服務。這主要是一些CMP廠商提供的產品,如Fit2Cloud、RightCloud、行雲管家等。
我們可以看到,以上幾類產品分別能夠幫助使用者實現基於私有云和公有云的一種或多種場景。
混合雲架構核心思路:連線一切IT,無縫混合體驗
瞭解混合雲的定義、使用場景和產品之後,我們來看看具體實現過程。作為雲端計算廠商或開發者,應該對功能矩陣非常熟悉。雲端計算廠商之間的比拼一個重要的層面就是功能矩陣的較量。
正是IaaS層提供了成百上千的功能點,才讓使用者得以輕鬆地進行各項業務開發。
在今天私有云和公有云都各自有了相似的巨大功能矩陣,我們仔細思考可以得出結論,大量的功能都是不需要跨雲的,例如GPU直通,只需要分別在私有云端和公有云端實現,作為混合雲服務商,只要把這個功能展現出來即可。但仍然有許多跨資源的關鍵業務,是需要混合雲廠商提供幫助的。
例如公有云上的路由,這條路由可以指向公有云VPC,也應該可以指向本地資料中心的VPC。類似這樣的業務,是混合雲功能的重點。
ZStack作為開源的國產自研IaaS軟體,進行混合雲的研發己經有一段時間。根據經驗來看,最重要的核心思路就是保證混合雲產品擁有連線一切的能力和無縫結合的能力。
連線一切IT
連線一切IT的本質是實現資料層面的打通,這是實現混合雲一切場景的前提條件。資料層面打通在今天主要是三個打通:帳戶打通、網路打通、儲存打通。
帳戶打通:使用一套帳戶管理公有云和私有云,即以私有云自身的帳戶體系和多租戶許可權管理為主體,公有云的AK許可權只是輔助。將公有云AK繫結到私有云的相應帳戶上,巧妙結合私有云和公有云各自的許可權體系,可以實現無比靈活的多租戶場景,建立起滿足企業要求的帳號管理體系。
網路打通:網路打通即指能夠將本地私有云的網路和公有云的網路在二層或者三層上連通起來,實現各種自定義的網路結構,如跨資料中心連通使用者的兩個子業務部門等。由於網路配置非常複雜,中間涉及到多種裝置,因此網路能力往往是雲端計算廠商綜合能力的體現。
儲存打通:私有云和公有云之間通常很難直接將儲存系統連線或擴充套件。所以我們指的儲存打通,是在快照和映象層面的打通。即虛擬機器或容器的快照和映象,能夠在私有云和公有云之間自由遷移,這種應該是代價極小的,如完全的增量遷移,或實時遷移等。從而可以使本地製作映象模板直接在公有云上建立雲主機,或反之。
在實現以上三個打通後,使用者就可以基於混合雲實現很多自定義網路,比如連線多個本地資料中心和多個公有云VPC,自由組合成星形、環形、網形等業務所需要的網路,並讓映象快照在各地之間共享。這一切的配置都可以在分鐘級完成,大大加速了業務創新,徹底取締了資訊孤島,實現全國一張網,一個系統。
無縫混合體驗
無縫結合更多是從控制面的設計來講,達到使用者所有的雲資源,不論是在公有云還是私有云,能得到一視同仁的處理。事實上由於公有云和私有云平臺天生模型的不一致(Azure stack這樣的平臺例外),很難強行把它們用相同的介面和邏輯來進行操作,而類似region,availability zone這樣的概念,更是無法對使用者遮蔽但私有云很難存在的概念。
所以在實現上,好的無縫體驗,應該是讓公有云和私有云的資源在同一個平臺上操作,它們的操作內在邏輯是完全一致,而非相互割裂。此處以建立雲主機和建立專線連線為例。
建立雲主機
當我們建立私有云主機時,需要選擇網路、主儲存、映象、資源規格、可能還有物理機、叢集等。而建立公有云主機時,需要選擇映象、安全組、網路、計算規格、可能還有可用區等。相比之下,公有云不可能看到物理機,而私有云不可能看到可用區,兩者的計算規格和網路的模型也可能完全不同。
我們可以將它們放在同一個頁面,但一個頁面還是兩個頁面,對使用者的操作路徑來說都是一步,所以意義不大。真正有意義的是讓使用者在操作過程中感受到完全的無縫。即建立的過程是完全相同的,所有資源都不需要到公有云控制檯去進行額外的查詢,本地就能閉環地完成所有操作。
建立專線連線
這是典型的跨雲資源操作。連線時需要選擇本地網路與公有云網路,這些選擇都應該是在平臺上直接進行選擇或建立(例如建立一個邊界路由器等),然後點選連線,混合雲平臺自動完成剩下的連線工作。不需要使用者登入到各個雲平臺檢視類似id、閘道器、cidr等屬性。從體驗上來說,使用者的直觀感受就是選擇了兩個網路,就建立了連線。而這背後,則是混合雲平臺進行了大量的建模和資料同步工作。
通過以上兩個示例可以看到,因為公有云和私有云之間的模型天生是有部分差異,因此無感知的混合雲並不是要強制使用者使用相同的模型去套用不同的雲平臺,而是在建立好對應的模型後,在後臺使用完全相同的邏輯去處理它們。而從API設計上來講,私有云和公有云資源的操作分屬不同的API,但它們的語義、引數都是非常相近的。
混合雲架構的具體技術實現原則
在定義了連線一切、無縫體驗之後,技術層面在實現它們時有哪些需要注意呢?在此提供以下一些設計原則以供大家參考:
建立完整資料模型
我們在設計私有云平臺時,會建立完整的私有云資料模型,如快照、磁碟、雲主機、VPC、路由器等,它們之間存在千絲萬縷的關係。同樣,在設計公有云平臺時,也要建立相應的資料模型。那麼在設計混合雲時,就必須同時建立這二者的模型,並且必須是完整的,因為存在許多關聯關係,導致缺少任意一個資源的模型,都不能算完整。
佈設虛擬ID
公有云資源對映到本地,成為一個虛擬資源。我們需要給每一個公有云資源分配一個本地的虛擬ID,而不能直接使用公有云的ID。因為在多租戶的場景下,公有云的ID在本地並非是唯一的,只有本地的ID才能保證它的唯一性。
觸發同步
由於存在對映關係,所以需要進行同步,同步可以是主動觸發,也可以是被動觸發的。同步的目的:一是讓使用者在公有云控制檯上做的操作也能及時反映到本地,二是保證所有的讀寫操作都在本地進行,讓操作的流暢程度達到毫秒級。正是有了同步,混合雲資源的操作速度,可以比直接在公有云控制檯上操作快了兩個數量級,這讓使用者可以放心地做更多的事。
遍歷資源模型
雲端計算的資源模型是樹狀的結構,因此任何操作都需要遍歷這棵樹,以便讓它的所有父子資源和相關資源都能得到及時的變更。例如刪除或同步一個VPC,需要遍歷它下面所有的交換機、安全組、雲主機、EIP、NAT閘道器、路由表、安全規則等等,進行相應的變更,出現失敗時要能按順序進行回滾,保證操作的原子性。又比如刪除一個本地網路,需要遍歷所有指向它的資源,如路由裝置,監控指標等等,進行路由的變更,和網路拓撲關係的自動適配,而不是簡單刪除就可以,下圖為VPN連線的混合雲資料模型。
混合雲VPN連線的資料模型
區分邏輯和真實操作
對公有云資源的操作都必須區分邏輯操作和真實操作,方便管理員的管理。比如有的使用者只能邏輯上刪除一個公有云網路,而不允許真實刪除公有云網路。又比如對可用區這種概念,使用者只能邏輯性地清除它以及它的子資源,而不能真實刪除一個可用區,因為這是公有云的固有屬性。
升級原則
對於混合雲產品來說,私有云的部分是可以隨產品升級而升級的,但公有云部分的升級,則可能影響到產品的穩定性。因此要注意兩個原則:
一是對公有云的操作失敗範圍要儘量控制在可以控制的範圍內,比如錯誤或資料結構控制在有限的package內,避免公有云API的呼叫失敗影響到產品整體流程。
二是對公有云上有可能變更的行為和資源保持彈性和可降級處理,比如公有云上的可用區是有可能新增和關閉的,而每個可用區內能看到的資源型別也是不對稱並且會發生變化的(例如庫存變化),因此需要有機制能動態地識別這種變化並進行相應處理。對於第二點來說,還需要開發人員對每個公有云本身的實現機制有深入的理解。
以上幾個設計原則雖然並不輕鬆,但一旦建立完成,一方面可以在UI上做出許許多多令人讚歎的智慧化設計。另一方面,公有云資源的操作可以達到毫秒級響應,在全非同步的框架下,一個管理節點可以幫助使用者管理成千上萬個雲資源,從而使用者可以摒棄掉公有云控制檯。
使用者可以在混合雲平臺上做什麼
對於使用者來說,混合雲幫助他遮蔽了許多實現細節,那麼使用者只需要按照場景去使用即可。在這裡我們列舉使用者可以在混合雲平臺上做的事情。
災備場景
使用者指定本地資料中心的磁碟、映象或雲主機,可通過備份策略、備份組或直接手動的方式,備份到遠端公有云。混合雲平臺幫助解決連通以及去重的問題。
互連場景
使用者指定本地資料中心通過VPN或專線的方式連線公有云VPC,或直接連線幾個公有云VPC,或把自己幾個資料中心與公有云組成星形網路,互相通過內網訪問。在此基礎之上,使用者可以讓自己的業務跨雲部署,或跨雲使用負載均衡。至於連通的細節由混合雲平臺處理,使用者只需要指定連通目標即可。
彈性場景
使用者將本地資料中心的雲主機彈到公有云,或者反過來從公有云彈到本地資料中心,從而解決業務遷移和彈性擴充套件問題。這個場景可以極大節省使用者的資源成本,從而通過混合雲平臺解決資料遷移的問題。
多雲管理
使用者不需要再登入公有云控制檯,在本地完成所有操作。本地平臺還可以幫助使用者解決跨帳戶、跨地域管理的問題,從而可以將使用者的資源管理速度提高几個數量級。
總結
本文從系統概念層面闡述了我們在研究和實踐中對混合雲的認知,即混合雲應該是讓私有云和公有云之間能進行帳號打通、網路打通、儲存打通,並以流暢的使用者體驗極大降低使用者在不同雲之間的分裂體驗,從而使使用者能夠專心於業務架構,而不用關心基礎資源如何打通的問題。
針對這一全新的混合雲認知,本文提出了混合雲的設計目標以及圍繞該目標應有的實現手段、設計原則。