Karbor全面使能OpenStack雲資料保護

Karbor(原名Smaug)是一個OpenStack中提供應用資料保護服務的項目，讓各個廠商的資料保護軟體通過标準接口接入OpenStack，為OpenStack提供增強的備份、複制、遷移等資料保護即服務(Data Protection as a Service)能力，Karbor緻力于解決虛拟機備份難、無标準備份的接口的現狀。雲平台的資料保護對客戶而言至關重要，是以該項目從一開始就受到OpenStack生态的關注。

Karbor項目由華為和幾家資料保護公司主導，目前并已經成為OpenStack正式項目。OpenStack的開放性允許不同廠商的虛拟化平台軟體可以直接接入，但這種開放性也導緻了異構平台很難統一進行資料保護，現有的資料保護方式都是以各個廠商的虛拟化平台為核心。

Karbor的出現将會通過标準接口、服務編排架構和規範工作流，讓不同廠商通過統一接口和工作流保護OpenStack中的任何資源以及資源的依賴項，包含虛拟機、卷和網絡拓撲等。下面我們從保護資源、APIs、Services、Plugins等方面進行詳細介紹。

Karbor可保護的資源

在Karbor保護架構中，把雲應用分了Web、基礎應用和資料庫3個層級，但是在OpenStack中需要保護的資源還包括VMs、網絡、卷、項目、服務和依賴等等安裝在OpenStack中的元件和服務。為了保護好這3層應用，Karbor必須保護好上訴所有資源才行。

Karbor所保護的對象(Protectable)就是一個個關聯的資源，對每種資源的保護是由定義在Karbor中的Plugin引擎執行完成的，Plugin引擎會加載各種資源保護時所需的Plugin，通過保護計劃來保護相關資源。

這些資源可以配置設定到不同組(工程)，每組包含不同資源，各個資源可通過不同廠商的Plugin來保護。下面對每種資源進行簡單描述。

• 卷：一般就是映射到VMs上的可進行讀寫的資料存儲載體或裝置。
• 虛拟機：是由中繼資料、配置、描述和相關依賴組成的業務部署單元。
• 虛拟網絡：虛拟機運作通信網絡。
• 工程：一組虛拟機和相關卷、鏡像、網絡等資源。
• 鏡像：虛拟啟動鏡像或軟體包。

上圖是一個工程執行個體，一個工程保護多個應用VMs(Web應用和DB應用)，每個VMs都有對應鏡像、網絡(包含路由器)、資料卷等。

Karbor涉及的Plugin

由于Karbor主要是針對不同廠商的虛拟化平台、資料保護軟體等定義一套标準接口和工作流程，為了實作标準流程化、開放化和異構相容，還需要不同廠商根據标準定義實作Plugin和Provider屏蔽廠商差異和細節。

對使用者或租戶來說，使用者可以選擇管理者授權的Provider類型配置和管理保護計劃，這些Provider由系統管理維護。

系統管理者需要定義那些Provider是對具體使用者可見，一個Provider通常是由一組資源保護插件Plugin和一個Bank組成，管理者還要負責為每個使用者或租戶配置一個Bank帳号。

對不同的第三方廠商來說，需要按照标準APIs規範提供不同資源保護Plugin和Provider供通用架構調用。

Karbor标準APIs介紹

前面談到Karbor提供了一套資料保護架構和APIs，為了完成資料保護任務建立、任務觸發、保護、資料一緻性、資料恢複等整個流程，Karbor為每個任務階段都提供了标準APIs，這些接口都可以暴露給使用者，以便提高保護靈活性和增加資源保護範圍，下面我們逐一簡單介紹下。

• 資源(保護對象) API用來給使用者提供有關保護資源的資訊、以及實際的可保護資源執行個體清單，如資源類型，那些資源可以被Smaug保護等。
• 保護計劃API讓使用者使用可選的Provider建立保護計劃或編輯相關計劃參數。
• Provider API讓使用者列出所有可用的Provider和參數，甚至得到每個具體Provider中所包含的Plugin視圖。
• Checkpoints API讓使用者通路和管理保護資源的Checkpoints(類似快照)，并且支援查詢和列出某個Provider現有的Checkpoints，另外當恢複保護資料時，Checkpoints API可以給Restore API提供Checkpoint讀通路能力。調用Checkpoint建立API将會在使用者的Bank帳号建立一個Vault，這個Vault會對應具體Provider中定義的Plugins資料保護動作，Vault定義了資料如何儲存、存放在哪。
• Schedule Operation API用來完成關聯保護任務和觸發條件，Restore API完成保護資料跟蹤和恢複，恢複資料可根據Checkpoints選擇需要恢複的不同時間點資料。

Karbor架構介紹

Karbor系統基于子產品化模式設計，這樣不但有助于系統的擴充，而且可以確定每個子子產品可以作為一個獨立的服務運作。例如保護計劃工作流引擎就使用一個單獨的服務。

Karbor API Service

是由上面介紹幾個API服務子產品組成，這些API服務最大限度地提高靈活性，并容可以納任何類型的保護資源，無論是基本的OpenStack資源 (例如虛拟機，卷和鏡像等)或一些不在OpenStack管理範圍内的輔助資源(例如硬體裝置，資料庫)。

Operation Schedule Service

負責安排和協調保護計劃的執行，所有實際的保護有關的活動都是通過操作Karbor API Service提供的北向API實作的。Karbor Operation Schedule Service維護Karbor資料庫的所有操作記錄，并從Karbor Protection Service分離出計劃排程的實作。

• Trigger Engine基于一個計時器或一個事件收集器實作，是在排程服務中負責生成觸發器，并執行的計劃業務流程。
• Scheduled Operation負責觸發器和操作之間的關系映射。

Karbor Protection Service

負責操作執行(保護、恢複、驗證、删除)、保護插件管理、銀行插件管理和銀行事務服務管理。

• WorkFlow Engine運作注冊有具體保護定義的保護計劃，将所有的中繼資料和事務資訊寫入到銀行帳戶中。
• Protection Plugin保護一個或多個資源，負責保護、驗證和恢複工作流程，提供保護參數選項，中繼資料和事務資訊被寫入銀行，保護插件決定使用哪個資料存儲來存儲實際資料。
• Banks建立了銀行模型，實作資料保護和恢複。
• Banks Plugin存儲每一個保護計劃的全局中繼資料和事務曆史。銀行是一個全局性的實體，是可以跨雲通路的。保護插件把所有事務中繼資料存入銀行。

1. Freezer保護插件首先在Swift裝置中建立CheckPiont。
2. Freezer保護插件随後調用Freezer API建立Backup Job。
3. Freezer Scheduler定期從Freezer API擷取Backup Job，并調用Freezer Agent執行Job将備份資料寫到Swift存儲中。
4. Freezer保護插件定時調用Freezer API查詢Job狀态
5. Freezer保護插件将資源備份狀态更新到CheckPiont。