青云云原生備份容災(zāi) SaaS 服務(wù)，讓企業(yè)數(shù)據(jù)有掌控，業(yè)務(wù)有保障

　 阿里云優(yōu)惠券 先領(lǐng)券再下單

5 月 23 日，Verizon Business 《2022 數(shù)據(jù)泄露調(diào)查報(bào)告(DBIR)》顯示，2022 年的勒索事件不僅沒有減少，反而增幅超過過去五年總和。2022 年上半年，就已發(fā)生多起影響或損失重大的勒索事件。

近 5 年勒索事件增幅超 20%

1 月 5 日，美國新墨西哥州伯納利洛縣遭勒索軟件攻擊。

3 月 1 日，豐田汽車供應(yīng)商遭勒索攻擊，14 家本土工廠暫時(shí)關(guān)閉。

3 月 21 日，征信巨頭 TransUnion 數(shù)據(jù)泄露，對(duì) 90% 南非人造成影響。

4 月 22 日，里約財(cái)政系統(tǒng)遭勒索攻擊，420GB 數(shù)據(jù)被盜。

5 月 13 日，勒索攻擊致使美國老牌高校林肯學(xué)院倒閉。

6 月 25 日，美國出版業(yè)巨頭 Macmillan 遭勒索軟件攻擊后關(guān)閉系統(tǒng)。

面對(duì)惡意攻擊，除了需要不斷提升的安全策略，數(shù)據(jù)的容災(zāi)備份也是不可缺少的。

一、行業(yè)現(xiàn)狀

現(xiàn)狀1：行業(yè)面臨的問題

災(zāi)備是一個(gè)非常古老的話題，那么目前行業(yè)面臨著哪些問題呢?

1、建設(shè)力度 較 低

目前國內(nèi)在災(zāi)備的建設(shè)力度，出現(xiàn)了“兩低一高”的局面。

數(shù)據(jù)災(zāi)備投入較低，我國信息基礎(chǔ)設(shè)施投資中災(zāi)備占比 2%，美國和歐洲分別為 6% 和 5%。

災(zāi)備覆蓋率較低，我國大中型企業(yè)綜合災(zāi)備覆蓋率僅為 3%，美國和歐洲分別為 87% 和 83%。

業(yè)務(wù)停機(jī)損失較高，我國大中型企業(yè)因?yàn)橥C(jī)造成的損失平均達(dá)到 78 萬美元，美國為 42 萬美元。

2、政府法規(guī)要求相繼完善

政府相繼出臺(tái)了一些政策法規(guī)，在用戶數(shù)據(jù)和平臺(tái)基礎(chǔ)設(shè)施層面對(duì)企業(yè)進(jìn)行保護(hù)。比如：2019 年發(fā)布的條例《等級(jí)保護(hù) 2.0》、2021 年逐漸加碼的關(guān)于《關(guān)鍵信息基礎(chǔ)設(shè)施的保護(hù)條例》以及《數(shù)據(jù)安全法》等，都對(duì)企業(yè)提出了更高的要求。

3、社會(huì)影響驅(qū)使

在社會(huì)影響上，無論是面向個(gè)人業(yè)務(wù)還是企業(yè)服務(wù)，服務(wù)中斷造成的社會(huì)影響力也在日益加深。

基于以上三點(diǎn)，使得企業(yè)更加重視關(guān)鍵信息的保護(hù)。另外，每一次針對(duì)于數(shù)據(jù)側(cè)的解決方案更新，都伴隨著計(jì)算平臺(tái)的更新而出現(xiàn)。

現(xiàn)狀2：信息化、數(shù)字化底座的新變革

Kubernetes 大行其道

2 月 10 日，CNCF 發(fā)布《2021 云原生調(diào)查報(bào)告》。這項(xiàng)已經(jīng)進(jìn)行了 6 年的調(diào)查顯示：Kubernetes 的使用率持續(xù)增長(zhǎng)，達(dá)到了有史以來的最高水平，90% 的組織在使用或評(píng)估這項(xiàng)技術(shù)。

90% 的組織在使用或評(píng)估 Kubernetes

圖片來源：https://www.cncf.io/reports/cncf-annual-survey-2021/

Kubernetes 等帶來新的安全挑戰(zhàn)

Kubernetes 大行其道趨勢(shì)之下，如何保護(hù) Kubernetes 的應(yīng)用數(shù)據(jù) ， 逐漸成為用戶使用 Kubernetes 和上云的挑戰(zhàn)之一 。

特別是以容器、微服務(wù)、Kubernetes、DevOps 為代表的云原生技術(shù)引領(lǐng)著企業(yè) IT 技術(shù)、架構(gòu)的下一場(chǎng)革命，為系統(tǒng)的安全帶來新的挑戰(zhàn)。

根據(jù)調(diào)查顯示：安全和存儲(chǔ)兩個(gè)領(lǐng)域，在使用、部署容器的挑戰(zhàn)中分別列第三和第四。

圖片來源：《2020 年 CNCF 云原生調(diào)研報(bào)告》

現(xiàn)狀 3：常見的解決方案及不足

目前行業(yè)內(nèi)有兩種常見的數(shù)據(jù)保護(hù)方案：基于虛擬機(jī)、基于 ETCD 。

方案 1：基于虛擬機(jī)

該類方案主要是通過虛擬機(jī)軟件(例：VMware / KVM 等)提供的快照和備份接口，直接備份虛擬機(jī)，從而備份虛擬機(jī)內(nèi)的應(yīng)用和數(shù)據(jù)庫。

虛擬機(jī)備份流程

該類方案更像是保護(hù)整個(gè)機(jī)器，因此不適用于 Kubernetes 環(huán)境下動(dòng)態(tài)部署、靈活擴(kuò)展的容器應(yīng)用。

方案 2：基于 Kubernetes ETCD

ETCD 是 Kubernetes 存儲(chǔ)集群狀態(tài)和配置的數(shù)據(jù)庫，可以稱為集群的“大腦”。該方案可在集群發(fā)生安全事故后，通過恢復(fù)已備份的 ETCD 數(shù)據(jù)庫來恢復(fù)整個(gè)集群。

圖片來源：https://s3.cn-north-1.amazonaws.com.cn/

該方案仍存在的一些不足：

1.僅對(duì)集群的資源進(jìn)行整體備份或恢復(fù)，無法針對(duì)單個(gè)應(yīng)用或配置。

2.僅在本集群中恢復(fù)，無法跨云或跨集群環(huán)境。

3.無法備份恢復(fù)掛載持久卷(PVC)的有狀態(tài)應(yīng)用(例：數(shù)據(jù)庫)。

鑒于以上兩種方案，可以總結(jié)為以下痛點(diǎn)：

1.缺少針對(duì) Kubernetes 的數(shù)據(jù)保護(hù)方案。

2.云廠商的鎖定。

3.開源技術(shù)門檻高。

4.部署維護(hù)復(fù)雜。

二、云原生數(shù)據(jù)保護(hù)的技術(shù)特征及適用場(chǎng)景

從以上三個(gè)行業(yè)現(xiàn)狀看得出，針對(duì) Kubernetes 架構(gòu)的數(shù)據(jù)備份方案(云原生數(shù)據(jù)保護(hù))需要具備以下三個(gè)特征：

特征 1：以應(yīng)用為中心

區(qū)別于傳統(tǒng)備份技術(shù)(直接備份整個(gè)機(jī)器)，云原生數(shù)據(jù)保護(hù)更加聚焦以應(yīng)用為中心的備份。所以說數(shù)據(jù)保護(hù)的對(duì)象應(yīng)該是一個(gè)應(yīng)用，而不是機(jī)器!保護(hù)方式應(yīng)該更細(xì)粒度且端到端，更便捷的管理，能屏蔽底層基礎(chǔ)設(shè)施的異構(gòu)性與復(fù)雜性。

特征 2：全新的開發(fā)者生態(tài)

因?yàn)橛辛?Kubernetes 這層抽象之后，需要結(jié)合 Kubernetes 的一些特性，屏蔽底層技術(shù)架構(gòu)的異構(gòu)性和復(fù)雜性，實(shí)現(xiàn)應(yīng)用數(shù)據(jù)的遷移或備份上的一致?，F(xiàn)在面對(duì)全新的開發(fā)者生態(tài)，需要向 DevOps 或微服務(wù)最佳實(shí)踐去深度結(jié)合，快速交付應(yīng)用，完成自助式的備份。

特征 3：面向多云的環(huán)境

現(xiàn)在用戶的基礎(chǔ)設(shè)施，并不完全都在用戶本地，很多都是在公有云，如在青云 QKE 容器引擎之上。而云廠商計(jì)算資源的價(jià)格變化是比較大的，我們可以根據(jù)前者不斷的變化，來相應(yīng)地選擇所需要的底層技術(shù)資源，去實(shí)現(xiàn)應(yīng)用的遷移，實(shí)現(xiàn)降本增效。

云原生數(shù)據(jù)保護(hù)可以應(yīng)用在哪里呢?主要有三個(gè)場(chǎng)景。

場(chǎng)景 1：數(shù)據(jù)的日常備份恢復(fù)

通過定時(shí)備份、恢復(fù)，時(shí)刻保障應(yīng)用的生產(chǎn)安全。場(chǎng)景基礎(chǔ)且核心，有效避免因?yàn)樵馐軔阂夤艋蚬收隙鴮?dǎo)致的停機(jī)。通過增加備份細(xì)粒度，及時(shí)挽回業(yè)務(wù)數(shù)據(jù)。目前有兩種實(shí)現(xiàn)方式：

方式 1：基于存儲(chǔ)的本地快照

支持 CSI 快照接口，把需要備份的 PVC 數(shù)據(jù)保存在當(dāng)前的卷下，然后與 API 相關(guān)的原數(shù)據(jù)將傳輸?shù)?S3 對(duì)象存儲(chǔ)。這種基于 CSI 的快照，能夠更好地保護(hù)應(yīng)用的數(shù)據(jù)一致性?；趯?dǎo)出的快照可快速遷移恢復(fù)到另一個(gè)目標(biāo)集群，恢復(fù)應(yīng)用響應(yīng)。

基于本地快照的備份

方式 2：基于 Restic 的文件復(fù)制

這種方式是以文件復(fù)制的形式來進(jìn)行的。如果集群存儲(chǔ)不能夠支持相關(guān)的存儲(chǔ)接口，那么將對(duì)應(yīng)的 API 資源和 PVC 數(shù)據(jù)備份到相應(yīng)的 S3 對(duì)象存儲(chǔ)中，將 S3 對(duì)象存儲(chǔ)復(fù)制到目標(biāo)集群，然后將應(yīng)用恢復(fù)起來。這種方式在自身數(shù)據(jù)一致性、同步時(shí)間、性能等方面會(huì)稍微差一些。

基于 Restic 文件復(fù)制的備份

場(chǎng)景 2：基礎(chǔ)設(shè)施變動(dòng)

無論是伴隨著公共云之上的資源遷移，還是實(shí)現(xiàn)多集群、多存儲(chǔ)協(xié)同保護(hù)，其實(shí)都在實(shí)現(xiàn)降本增效。

通過云原生備份服務(wù)快速實(shí)現(xiàn)基礎(chǔ)設(shè)施更換

云遷移方案，針對(duì)于跨 Kubernetes 集群的方案，在更換云基礎(chǔ)設(shè)施場(chǎng)景常見。比如，此時(shí)有更適合的云廠商資源，需要將資源遷移過去。先在目標(biāo)云資源中啟用一套 Kubernetes 集群，然后逐步把源端的 Kubernetes 應(yīng)用遷移到目標(biāo)端應(yīng)用上，逐步驗(yàn)證新集群應(yīng)用是否有效。由于目前 Kubernetes 升級(jí)迭代速度較快，遷移過程可能會(huì)出現(xiàn)一些問題，比如：不同版本 Kubernetes 的 API 兼容程度，應(yīng)用適配等。

場(chǎng)景 3：保障業(yè)務(wù)連續(xù)性

云容災(zāi)相對(duì)傳統(tǒng)容災(zāi)方式，能更好保障服務(wù)高可用和業(yè)務(wù)連續(xù)性。

就像對(duì)一個(gè) Kubernetes 的生產(chǎn)集群災(zāi)備，需要在遠(yuǎn)端準(zhǔn)備一個(gè)跟當(dāng)前集群基礎(chǔ)設(shè)施存儲(chǔ)一模一樣的集群用于災(zāi)備。然后通過日常的增量復(fù)制，將增量數(shù)據(jù)時(shí)刻恢復(fù)到災(zāi)備站點(diǎn)中。如果生產(chǎn)集群掛掉了，我們可以及時(shí)的啟用災(zāi)備集群。這種方式的 RPO 和 RTO 非常好，但是代價(jià)也非常高，需要一整套相同的災(zāi)備集群基礎(chǔ)設(shè)施，而且災(zāi)備站點(diǎn)日常不能跑其他的工作負(fù)載，恢復(fù)概率很高。

傳統(tǒng)容災(zāi)方式

這種方式下的 Kubernetes API 資源也是增量備份在 S3 對(duì)象存儲(chǔ)。如果生產(chǎn)環(huán)境掛掉，可以直接從 S3 存儲(chǔ)中獲取快照和元數(shù)據(jù)，將它們快速恢復(fù)到一個(gè)集群環(huán)境。這種方式對(duì)基礎(chǔ)設(shè)施沒有太多要求，是支持異構(gòu)的，但 RPO 和 RTO 就存在一定局限性，對(duì)恢復(fù)效率帶來一定的影響。

云容災(zāi)方式

三、更健壯、易用、高效的企業(yè)級(jí)云原生備份容災(zāi)

KubeSphere Cloud 提供的 云原生備份容災(zāi)是一款 SaaS 服務(wù)，通過云端托管部署的方式，來管理云原生數(shù)據(jù)保護(hù)組件 。針對(duì)不同客戶場(chǎng)景，提供私有化集群部署的解決方案，以確保對(duì)數(shù)據(jù)的掌控能力。云原生備份容災(zāi)服務(wù)有如下顯著產(chǎn)品特性：

特征1：應(yīng)用級(jí)數(shù)據(jù)庫保護(hù) ：以應(yīng)用為最小顆粒度，基于應(yīng)用構(gòu)建端到端備份容災(zāi)。應(yīng)用的各種配置信息、PVC 數(shù)據(jù)等在任務(wù)執(zhí)行中都能得以有效保護(hù)。

特征2：核心業(yè)務(wù)保障： 支持基于 CSI 的存儲(chǔ)快照備份與快照導(dǎo)出，有效保護(hù) MySQL、MongoDB、Redis 等有狀態(tài)應(yīng)用的數(shù)據(jù)一致性，保障關(guān)鍵應(yīng)用的異地恢復(fù)和跨站點(diǎn)高可用。

特征3：跨云容災(zāi)備份： 屏蔽了技術(shù)堆棧帶來的差異性，支持對(duì)跨云、跨可用區(qū)、跨 Kubernetes 版本的集群進(jìn)行容災(zāi)備份，為企業(yè)不同的容器應(yīng)用提供了安全、統(tǒng)一的保護(hù)方案，無廠商鎖定。

特征4:直觀易用的管理界面： 用戶無需掌握 Kubernetes 備份的專業(yè)知識(shí)、工具，幾步操作即可輕松執(zhí)行數(shù)據(jù)保護(hù)任務(wù)。相較 Velero 等開源應(yīng)用，極大程度降低了使用難度。

云原生備份容災(zāi)服務(wù)架構(gòu)圖

下面我們根據(jù)幾個(gè)具體的實(shí)踐案例來展示服務(wù)特性。

實(shí)踐 1：保障有狀態(tài)應(yīng)用的數(shù)據(jù)一致性

CNCF 調(diào)查報(bào)告顯示：有狀態(tài)應(yīng)用容器部署的比例非常高，達(dá)到 55%。典型的有狀態(tài)應(yīng)用主要包括：消息系統(tǒng)、數(shù)據(jù)庫等，屬于需要應(yīng)用數(shù)據(jù)保護(hù)的范疇。

如今一個(gè)顯著的事實(shí)是，數(shù)據(jù)庫應(yīng)用逐漸走向 Kubernetes，優(yōu)勢(shì)：

數(shù)據(jù)庫的安裝、配置和維護(hù)更簡(jiǎn)單

跨云的部署兼容性更好

數(shù)據(jù)庫和應(yīng)用在一個(gè)平臺(tái)上運(yùn)維，無需分開部署運(yùn)維

快速部署數(shù)據(jù)庫實(shí)例

容災(zāi)備份服務(wù)可以更好的發(fā)揮本地快照的性能優(yōu)勢(shì)，滿足 CSI 一致性要求，秒級(jí)創(chuàng)建快照，減少對(duì)數(shù)據(jù)一致性對(duì)應(yīng)用業(yè)務(wù)的影響。

還可以在執(zhí)行備份容災(zāi)操作前后，根據(jù)客戶有狀態(tài)應(yīng)用的 I/O 情況、企業(yè)服務(wù)時(shí)間、運(yùn)維周期等維度等條件，通過配置 Hook 策略執(zhí)行操作，避免因?yàn)閭浞莼謴?fù)對(duì)企業(yè)業(yè)務(wù)造成影響。配合本地快照更快更好的保護(hù)有狀態(tài)應(yīng)用的數(shù)據(jù)一致性。

各類備份方式的對(duì)比

實(shí)踐 2：滿足跨云跨集群的應(yīng)用遷移

在 Hook 程序和本地快照方式的加持下，可以很快打包創(chuàng)建 CSI 快照，然后通過手動(dòng)將快照導(dǎo)出，導(dǎo)入到目標(biāo)的 S3 存儲(chǔ)上并恢復(fù)到目標(biāo) Kubernetes 集群。

當(dāng)兩端 Kubernetes 集群的 StorageClass 不一致，可以通過在服務(wù)中配置兩端存儲(chǔ)卷映射關(guān)系，使得導(dǎo)出后的快照能夠順利導(dǎo)入到目標(biāo)集群，實(shí)現(xiàn)應(yīng)用遷移。該功能支持的非常完善。

配置存儲(chǔ)卷映射關(guān)系

實(shí)踐 3：滿足復(fù)雜的備份容災(zāi)選擇粒度需求

往往在應(yīng)用備份粒度上有不同需求，比如 DevOps 用戶備份時(shí)可能同時(shí)依賴幾個(gè) NameSpace 或 Cluster 資源，很大的工作負(fù)載和常見應(yīng)用備份怎么實(shí)現(xiàn)呢?

1、多 NameSpace 的選擇

可以通過 NameSpace 的 Name 或者 Label 兩個(gè)維度，進(jìn)行可視化的 NameSpace 篩選，并可一次性選中并備份多個(gè) NameSpace。

2、應(yīng)用負(fù)載資源的過濾篩選

直接定位到 NameSpace 可能會(huì)產(chǎn)生一些冗余備份，如果直接定位到工作負(fù)載這個(gè)級(jí)別，一個(gè) Filter 中，可通過 Group / Resource / Version / Name 等維度選擇或排除備份的資源。還可以創(chuàng)建多個(gè) Filter，實(shí)現(xiàn)應(yīng)用的靈活管理。

3、Cluster-Level 資源的選擇

在新集群?jiǎn)⒂脮r(shí)，需要依賴一些 Cluster-Level 資源，可以對(duì)這些資源進(jìn)行單獨(dú)的備份，從而實(shí)現(xiàn)更加細(xì)粒度資源的選擇。

Cluster-Level 資源備份

商業(yè)版本與開源方案對(duì)比

和開源的備份恢復(fù)工具 Velero 相比，KubeSphere Cloud 提供的云原生容器備份容災(zāi)服務(wù)有諸多關(guān)鍵的附加價(jià)值。

充分測(cè)試驗(yàn)證，安心、可靠

企業(yè)級(jí)測(cè)試驗(yàn)證

安全事故極大先于社區(qū)處理

7*24 全天候省心支持

補(bǔ)充更多企業(yè)級(jí)功能

多集群納管

跨云遷移與云容災(zāi)

有狀態(tài)應(yīng)用一致性保證

快照導(dǎo)出與存儲(chǔ)映射

強(qiáng)大的備份資源模板

更加直觀易用

中文向?qū)浇缑?/p>

完整清晰的產(chǎn)品文檔

高效的安裝部署過程

良好支持國產(chǎn)化環(huán)境

國內(nèi)主流公有云廠商支持

國內(nèi)主流 Kubernetes 平臺(tái)支持

國內(nèi)主流存儲(chǔ)廠商支持

備份容災(zāi)用戶權(quán)益

目前該服務(wù)已經(jīng)上線到 KubeSphere Cloud 網(wǎng)站（ https://kubesphere.cloud ），會(huì)長(zhǎng)期提供一個(gè)免費(fèi)的版本，即1 00GB 免費(fèi)托管存儲(chǔ)容量 。我們將保持中立開放的態(tài)度，不限制用戶基礎(chǔ)資源類型、倉庫類型等，提供相應(yīng)的應(yīng)用保護(hù)數(shù)和托管存儲(chǔ)容量，方便個(gè)人用戶測(cè)試體驗(yàn)，去支持?jǐn)?shù)據(jù)備份遷移的場(chǎng)景。

同時(shí)，我們開放付費(fèi)能力的“新手禮包”體驗(yàn)活動(dòng)，讓用戶便捷地體驗(yàn)付費(fèi)服務(wù)的軟件能力 ，并提供標(biāo)準(zhǔn)售后支持，幫助用戶解決問題，保障應(yīng)用數(shù)據(jù)安全，實(shí)現(xiàn)業(yè)務(wù)價(jià)值。

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！