K8S數據保護工具比較

K8S數據保護工具比較：Cohesity、 Kasten、 OpenEBS、 Portworx、 Rancher Longhorn、 和Velero

數據保護對於客戶愈來愈重要。從概念上來講，數據保護包括備份、高可用性、應用連續性、和容災恢復。全部的企業都須要實施，測試和運維本身的數據保護策略，來避免在發生問題時對商業產生不利影響。隨着數據在用戶體驗和商業流程中的做用愈來愈重要，對關鍵數據忽然不能訪問的問題的容忍度愈來愈低。根據Uptime Institute的報告(https://uptimeinstitute.com/data-center-outages-are-common-costly-and-preventable)

 

數據沒法訪問問題中41%的狀況致使的損失均超過了百萬美圓。企業對高可用性的基礎架構的依賴性逐漸加強。

 

所以，一個有效的數據保護策略可使宕機時間極少，即使發生意外宕機，應用和數據也均可以快速的恢復。同時數據保護策略還須要確保數據的隱私性和合規性（好比GDPR和CCPA），如今愈來愈多的用戶數據轉移到了線上隱私合規愈發重要。

 

雖然數據保護是一個硬性需求，不少客戶仍然作的不夠好。傳統的數據保護方式在單獨主機環境裏很出色，但在分佈式或跨數據中心環境裏就能力不足了。而Kubernetes環境是典型的分佈式環境。傳統的業務連續性和容災恢復（BCDR）方案，沒法支持現今運行在Kubernetes上的關鍵商業應用所要求的RPO（Recovery Point Objective）和RTO（Recovery Time Objective）。

因爲每一個應用和每一個客戶環境都各不相同，所以數據保護方式也多種多樣。當咱們考慮數據保護解決方案的時候，一些重要的問題咱們首先須要思考：

 

• 我是否是隻須要在一個單獨的數據中內心保護個人數據？

• 我是否須要保護數中心內和數據中心外的數據，須要創建一個混合的數據保護方案？

• 是否是合規部門對一些備份和恢復數據的存儲位置有要求？

• 應用對RPO和RTO的要求低仍是高？

• 是否須要對Kubernetes集羣裏的每個應用都採用一樣水平的數據保護方式？

• 咱們準備對數據保護方案花多少錢，能否對不一樣的應用採用不一樣的數據保護方式，以下降成本？

還有一些問題取決於你的目標，好比：

• 即便出現服務器宕機，或者磁盤宕機，也須要保證Kubernetes應用的高可用。

• 備份數據和應用的配置，這樣咱們能夠在另外一個環境裏恢復它們。

• 一旦出現數據中心服務中斷，應用能夠即時在另外一個環境重啓且沒有數據損失。

咱們能夠把數據保護場景分爲：

• 本地高可用

• 備份和恢復

• 容災恢復

這三種場景是全部企業級數據保護的基礎，也是評估一個Kubernetes數據保護解決方案能力的重要要素。不一樣解決方案的客戶要求可能各有不一樣，客戶須要根據自身的需求來評估這些要素。一般來講，只有靜態數據備份不足以完成有效的數據保護，本地高可用一般是必須的基礎性需求。

本地高可用、備份和恢復、容災恢復是評估一個Kubernetes數據保護解決方案能力的重要要素。

對於Kubernetes，數據保護是一個較新的領域，市場有一些解決方案提供。本文咱們要分析Kubernetes應用數據保護領域的一些主要供應商（https://www.computerweekly.com/feature/Spread-of-Kubernetes-spurs-backup-and-disaster-recovery-products）。咱們在博文中討論的解決方案主要是爲了保護Kubernetes中正在運行的應用、和應用中的持久性數據，而不是備份Kubernetes的節點服務或者etcd存儲，明確這些有助於咱們更好的理解數據保護工具和Kubernetes的數據保護。

 

本地高可用性

本地高可用性指的是保護髮生在某單個數據中心的錯誤，或者是某單個可用性區域內的雲平臺的錯誤。當應用正在運行時，若是基礎架構、應用或者節點發生錯誤，都被認爲是本地的錯誤。當咱們用Kubernetes數據保護工具來構建本地高可用時，應用的複本能夠在用戶無感受的狀況下快速恢復，達到對用戶的高可用。一個在本地節點錯誤狀況下，宕機的例子：https://thenewstack.io/overcome-stuck-ebs-volumes-running-stateful-containers-aws/。本地高可用性是數據保護的基礎。爲達到本地高可用性，通常經過創建本地數據複製集的方式。若是本地高可用性是經過從外部其它位置的備份數據恢復的方式進行，那就應該被歸類爲是備份恢復方案，由於恢復時間會比本地高可用性的方案長不少。

 

備份和恢復

備份和恢復方案，指的是把Kubernetes上的整個應用，從本地Kubernetes集羣上，備份到非本地的另外一位置的對象存儲裏（非本地指位於其餘區域的公有云、私有云、或者是本地部署環境）。備份解決方案也能夠有多個備份位置。備份一般是爲了防止系統錯誤，或者爲了應用的合規和監管要求。而Kubernetes備份，須要符合Kubernetes環境特色。包括：

 

• Kubernetes資源，好比Secrets、服務帳戶、CRDs等

• 應用配置和數據

這些對象對Kubernetes來講都須要被備份。傳統的備份方案通常不會考慮這些Kubernetes的對象，而是一般只把應用所依賴的VM、服務器、磁盤做爲備份目標。一個Kubernetes備份解決方案，不只能備份單個應用，並且能夠備份多個應用或者整個Kubernetes命名空間，同時也可以支持傳統備份方式的內容，好比調度、Jobs、 retention、加密和分層。

 

一個Kubernetes備份必須包括Kubernetes的資源好比Secrets、服務帳戶、CRDs、應用配置和數據。

容災恢復

與備份相似，容災恢復也必需要包括Kubernetes的一系列對象，應用配置和數據。而且須要建立主站點以外的容災站點，這樣資源和持久狀態可以在主站點出問題時快速恢復到容災站點。容災恢復系統也能夠處理不一樣保護層級的RPO和RTO，取決於成本和商業須要的綜合考慮。 

 

例如，若是應用不能承擔任何數據丟失，那就必須設定零RPO的目標。若是要求沒那麼高，也能夠設定15分鐘RPO的目標。再例如，一個應用的RTO要求<2分鐘，而另外一個應用能夠容許1小時以內的宕機時間。

 

容災恢復系統必須規劃應用如何配置纔可以在容災節點上有效的啓動運行。這須要處理應用的元數據，例如標籤和複製集等，讓它們可以自動啓動起來。若是Kubernetes的API不可以被理解和啓動，就會產生宕機事故或者數據損失。

Kubernetes數據保護解決方案的比較

咱們已經理解了數據保護的多種類型，咱們接下來比較一下市場上的解決方案：*比較基於各解決方案提供商的網站和文檔。

 

 

快速索引

X   –  沒有這項功能，或者宣稱有功能但沒有找到任何支持性信息

❍ – 宣稱有這項功能，可是功能較爲薄弱

◑  – 宣稱有這項功能，可是功能不完整

✅ – 宣稱有這項功能，而且從網站上的文檔來看功能完整

Cohesity

Cohesity在網站上介紹，「Cohesity保護Kubernetes命名空間的數據和應用狀態。Web-Scale平臺備份命名空間包括運行狀態，而不只僅是數據。」Cohesity是數據保護和存儲領域的一個主要服務商，它近期也經過備份命名空間的數據和應用，開始支持Kubernetes。可是Cohesity僅僅針對整個命名空間，而不能保護命名空間內的每一個獨立應用。保護單獨應用是頗有必要的，由於不是全部命名空間內的應用都須要同一水平的保護級別。所以Cohesity保護的顆粒度還不夠。另外Cohesity目前尚未Kubernetes主存儲，也尚未基於Kubernetes的容災恢復方案。因爲Cohesity對於備份VM的傳統解決方案積累好久，如今進入到對Kubernetes的支持，也是一個很好的解決方案。

 

Kasten

Kasten在網站上介紹，「K10數據管理平臺，爲Kubernetes而建，爲企業運營團隊提供易用、可擴展、安全的備份恢復、容災恢復、和集羣間應用遷移能力」。Kasten使用自身構建的存儲系統 -EBS/RBD，不支持應用自身所在集羣裏的複製，所以它沒法支持本地高可用。基於雲端的塊存儲來構建Kubernetes卷，常常會因爲Stuck Volumes致使應用的宕機。因爲沒有數據路徑的組件，Kasten沒法達到數據徹底無損的零RPO，備份只能是異步的，所以恢復後的數據與最新的數據會有必定的不一樣。有時候企業在容災恢復上的要求不高，但不少企業仍然在容災恢復上須要零RPO。

 

OpenEBS

OpenEBS這樣描述：「咱們是應用和本地、網絡或雲存儲之間的抽象層，經過OpenEBS能夠減小維護工做量，下降存儲成本而且簡化管理。」OpenEBS主要集中在本地高可用，也能夠和Velero集成來達到OpenEBS 數據管理即服務（DMaaS）。DMaaS可以把Kubernetes有狀態應用以及持久數據進行遷移。本地部署、雲部署等任意方式均可以互相遷移。相對於Cohesity只備份整個命名空間而非每一個獨立的Kubernetes應用，OpenEBS只備份獨立的應用。應用層級的備份的確更加靈活，但不少客戶仍然須要命名空間層級的備份。另外OpenEBS只能用來備份包含持久存儲卷的有狀態應用，而不能備份或遷移Kubernetes對象和應用配置。OpenEBS備份是基於Velero進行的，而Velero也有自身的侷限性 – 不能提供完整的容災恢復功能，而OpenEBS自身也沒有容災恢復功能的補充，雖然OpenEBS也能夠提供相似Kasten那樣的異步備份的容災，但問題也是沒法達到數據徹底無損的零RPO。

 

Portworx

Portworx是一個端到端的Kubernetes存儲和數據管理方案。包括基於容器的CaaS，DBaaS，SaaS，備份恢復，以及容災恢復。Portworx被市場研究機構GigaOm評爲全球第一的Kubernetes存儲平臺。GigaOm評價Portworx的功能完美適應大型客戶與服務提供商的需求。Portworx解決方案支持複雜的Kubernetes基礎架構，不管是本地部署仍是公有云/混合雲部署。在Portworx的支持下，全部的Kubernetes應用均可以得到容器原生存儲能力，以及本地高可用、容災恢復、備份、安全管理、多雲間遷移的能力等。Portworx提供一個數據層可以伸展在低延遲的網絡上，從而達到零RPO容災恢復，本地應用的備份和命名空間的備份。Portworx一開始就支持本地高可用，以及後來推出的PX-DR和PX-Backup可以提供更加多樣的數據保護能力。

 

Rancher Longhorn

根據Rancher的描述，Longhorn是「輕量的，可靠的，和強大的。你可使用簡單的Kubectl命令，或者使用Helm來把Longhorn安裝到Kubernetes集羣上。一旦安裝完成，Kubernetes集羣就具有了持久存儲卷的支持。」雖然比起其餘開源解決方案，Longhorn的社區較小，但它近期被接受加入了CNCF。Longhorn有DR Volume的功能，能夠被設定成源卷和目標卷，這樣卷能夠在一個新集羣上基於最新的備份被激活。這個很相似Kasten的DR解決方案，是基於備份的，所以沒法達到零RPO的能力。一樣因爲也不含應用元數據，所以也沒法達到Kubernetes應用層級的恢復。

 

Velero

Velero描述本身的解決方案：「一個開源工具，可實現安全的備份恢復、容災和恢復，以及遷移Kubernetes集羣資源和持久卷。」Velero自身只能支持無狀態應用資源。可是用戶能夠選擇增長插件來達到持久卷聲明快照備份。另外一個選擇是Restic，它經過文件/拷貝方式來實現。Velero自身並無解決Kubernetes應用的數據問題。但若是結合插件或者Restic一塊兒使用，能夠提供備份和恢復，以及基於異步備份的容災恢復能力 – 相似OpenEBS和Kasten。可是同樣也沒法提供零RPO的容災恢復能力。

 

結語

 

但願這篇文章可以幫助您更多的瞭解Kubernetes備份和數據保護解決方案，以及它們與傳統的容災恢復方案或者備份恢復方案有什麼不一樣。各類解決方案在目前雲原生架構下的構建方式都各有不一樣，所以這須要用戶根據自身的應用的實際狀況與須要，爲應用選擇不一樣層級的數據保護機制，從而選擇有效的數據保護解決方案。

 

參考文檔：

 

[1]https://www.cohesity.com/resource-assets/solution-brief/Data-Protection-for-Entire-Kubernetes-and-Container-Application-Stack-Solution-Brief.pdf

[2] www.kasten.io/product/

[3] https://openebs.io/

[4] https://help.mayadata.io/hc/en-us/articles/360033401591-DMaaS

[5] https://github.com/longhorn/longhorn

[6]https://velero.io/