容災恢復是絕大多數企業級應用的基本要求

在沒有Kubernetes也沒有容器的時候，備份和恢復解決方案通常在虛擬機器（VM）級別上實現。當應用程式在單個VM上執行時，容災系統適用於這樣的傳統應用程式。但是，當使用Kubernetes對應用程式進行容器化管理時，這樣的容災系統就無法使用了。有效的Kubernetes容災恢復方案必須針對容器化架構進行重新設計，並按Kubernetes的原生方式來執行。

傳統的基於VM的備份和恢復解決方案，使用快照來收集資料，但這些資料對於某個具體容器化應用並不足夠。因為任何一個特定的VM都將包含來自多個應用的資料。如果您嘗試透過VM快照來備份APP 1，將會同時獲取其他應用的多餘資料。但這些資料從容器角度來看又不夠：APP 1可能還會將資料儲存在其他VM上。因此透過對某個單獨VM的快照無法捕獲所有APP1的資料。

基於分散式體系結構的現代應用需要的容災方案，需要能夠找到特定應用的所有相關資料和配置資訊，並能夠以零RPO（Recovery Point Objective，復原點目標）和接近零RTO（Recovery Time Object，復原時間目標）的方式進行恢復。

一個有效的Kubernetes容災解決方案需要具備：

容器粒度的控制
能夠備份資料和配置
Kubernetes名稱空間感知
針對多雲和混合雲架構的最佳化
保持應用的一致性

容災解決方案必須滿足以上五個標準，才能確保Kubernetes上執行的含大量資料的應用程式在容災恢復的時候，滿足服務水平協議（SLA）或相關法律要求。

讓我們分析一下為什麼這五個標準都很重要。

容器粒度控制

容器粒度控制容災方案意味著使用者可以備份特定的Pod或Pod組，而不是備份整個VM或伺服器。這使得使用者可以僅快照屬於該應用程式的容器。

假設您有一個三節點Kubernetes叢集，其中有一個三節點Cassandra環和三個單節點PostgreSQL資料庫，分佈在三個虛擬機器上。使用傳統的災難恢復解決方案，備份群集的唯一方法是備份三個虛擬機器。這將導致提取，轉換和載入過程帶來的複雜性增加，儲存成本增加和RTO增加。備份充足資料的唯一方法是備份超出必要資料的更多資料。

使用容器粒度的方式，可以在三個VM上僅備份一個PostgreSQL資料庫或三節點Cassandra環，而無需其他任何備份。

Kubernetes名稱空間感知

傳統的備份和恢復解決方案不是以Kubernetes的方式進行的。

Kubernetes中的名稱空間通常執行多個相關的應用程式。例如，企業Kubernetes部署中的一種常見模式是使公司/部門所有的應用都執行在同一個名稱空間內。在這種情況下，通常有必要一起備份Kubernetes名稱空間中的所有應用程式。

但是，像每個單獨的應用一樣，名稱空間分佈在許多虛擬機器上。每個虛擬機器可能還有來自幾個不同名稱空間的Pod。如果沒有支援名稱空間的容災解決方案，則完全備份將需要備份和儲存遠遠超出必要的資料。即使採用了這種過分的備份策略，在發生故障的情況下也很難還原整個名稱空間，從而導致較高的RTO。

應用的一致性

即使您想透過備份系統中的所有VM來解決上述問題，使用傳統的容災恢復方案也很難避免資料損壞。為了成功地備份分散式應用，而沒有資料損壞的風險，在快照進行過程中，必須鎖定應用程式中的所有Pods。基於VM的快照無法實現此目的，因為它們無法鎖定整個應用程式，無法跨多個VM執行應用一致性的快照。

成功的快照，要使資料損壞風險最小化，並必須保持分散式架構的應用的一致性。這意味著在鎖定屬於應用程式的所有Pods的同時，來執行快照。

資料和配置備份

容災系統的目標不僅是防止資料丟失，還在於保持RTO較低。您需要應用程式在遇到問題後儘快重新啟動並執行。

這需要備份應用資料和配置資訊。如果備份中不包含配置資訊，則必須就地重建應用程式，這是一個緩慢，手動且可能容易出錯的過程。但是，如果僅儲存配置，則可能會丟失所有資料。

一個真正的Kubernetes的企業級容災系統將同時包含資料和配置備份。這樣在系統失敗後，可以用一兩個命令快速重新部署應用程式。

針對多雲和混合雲架構進行了最佳化

絕大多數企業在實踐中，應用程式至少在兩個環境中執行。這可能意味著多個本地資料中心或多個Amazon Web Services（AWS）區域。在容災恢復的情況下，通常將一個資料中心作為主站點，而將第二個資料中心作為備份站點。但是，也有許多公司使用公有云和本地資料中心的組合來執行應用程式並滿足其業務需求。在大多數情況下，企業會根據其RPO和RTO要求選擇最佳的架構方式。

對於容災恢復解決方案而言，結合這些不同的架構方式以支援不同級別的RPO和RTO至關重要。有效的容災恢復解決方案應該能夠提供同步和非同步資料複製，具體取決於主群集和備份群集之間的延遲。

當主站點和備份站點之間的往返延遲通常在10毫秒以下時，可以實現允許RTO和RPO為零的同步複製。這種情況通常是當主叢集和備份群集所在資料中心地理相距較近。

在某些情況下，企業希望主站點和備份站點之間的地理距離遠一些。在這種情況下，RTO仍可以為零或接近零。但是延遲的增加，同步複製資料會產生比較大的效能問題。如果應用能夠接受15分鐘或1小時的RPO，則也是可接受的容災方案。

Kubernetes的企業級容災恢復方案，應為使用者提供適用於多雲或混合雲架構的，同步複製或非同步複製的選擇。這樣可以使使用者能夠基於自己的資料中心架構和業務需求情況，來選擇不同的容災恢復方案。

結論

當企業將關鍵業務應用遷移至Kubernetes時，重新思考和設計容災恢復的方案非常重要。實際上可以做到在滿足與容災相關的SLA的同時，

在Kubernetes上執行應用。

但它需要採用專為Kubernetes設計的容災方法，與Kubernetes的工作方式深入結合。傳統的基於VM的容災解決方案無法做到這一點。

Portworx Enterprise 儲存平臺是專門為容器和Kubernetes構建的。它可為Kubernetes上執行的應用實現零RPO和接近零的RTO容災恢復。並具有容器粒度控制的，名稱空間感知的，應用一致性的容災恢復。故障恢復可以完全自動化，從儘可能降低RTO。

K8S容災方案的五個關鍵點

相關文章