趨勢(shì)

1. 云原生發(fā)展趨勢(shì)

云原生(Cloud Native)是最近幾年非?；鸨脑掝}，在 2020 年 7 月由信通院發(fā)布的《云原生發(fā)展白皮書(2020)年》明確指出：云計(jì)算的拐點(diǎn)已到，云原生成為驅(qū)動(dòng)業(yè)務(wù)增長(zhǎng)的重要引擎。我們不難發(fā)現(xiàn)云原生帶給 IT 產(chǎn)業(yè)一次重新洗牌，從應(yīng)用開發(fā)過程到 IT 從業(yè)者的技術(shù)能力，都是一次顛覆性的革命。在此基礎(chǔ)上，出現(xiàn)了基于云原生平臺(tái)的 Open Application Model 定義，在云原生平臺(tái)基礎(chǔ)上進(jìn)一步抽象，更加關(guān)注應(yīng)用而非基礎(chǔ)架構(gòu)。同時(shí)，越來越多的公有云開始支持 Serverless 服務(wù)，更加說明了未來的發(fā)展趨勢(shì)：應(yīng)用為核心，輕量化基礎(chǔ)架構(gòu)層在系統(tǒng)建設(shè)過程中的角色。但是無論如何變化，IT 整體發(fā)展方向，一定是向著更有利于業(yè)務(wù)快速迭代、滿足業(yè)務(wù)需求方向演進(jìn)的。

2020 年 9 月，Snowflake 以每股 120 美金 IPO，創(chuàng)造了今年規(guī)模大的 IPO，也是有史以來大的軟件 IPO。Snowflake 利用云原生方式重構(gòu)了數(shù)據(jù)倉(cāng)庫(kù)，成功顛覆了行業(yè)競(jìng)爭(zhēng)格局。這正是市場(chǎng)對(duì)云原生發(fā)展趨勢(shì)的好認(rèn)可，所以下一個(gè)云原生顛覆的領(lǐng)域會(huì)不會(huì)是在傳統(tǒng)的容災(zāi)領(lǐng)域呢?

2. 為什么云上需要全新的遷移和容災(zāi)?

1)傳統(tǒng)方案的局限性

在這種大的趨勢(shì)下，傳統(tǒng)的遷移和容災(zāi)仍然停留在數(shù)據(jù)搬運(yùn)的層次上，而忽略了面向云的特性和用戶業(yè)務(wù)重新思考和構(gòu)建。云計(jì)算的愿景是讓云資源像水、電一樣按需使用，所以基于云上的遷移和容災(zāi)也理應(yīng)順應(yīng)這樣的歷史潮流。Snowflake 也是通過這種商業(yè)模式的創(chuàng)新，成功打破舊的競(jìng)爭(zhēng)格局。

為什么傳統(tǒng)容災(zāi)的手段無法滿足云原生需求呢?簡(jiǎn)單來說，二者關(guān)注的核心不同。傳統(tǒng)的容災(zāi)往往以存儲(chǔ)為核心，擁有對(duì)存儲(chǔ)的至高無上的控制權(quán)。并且在物理時(shí)代，對(duì)于計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等基礎(chǔ)架構(gòu)層也沒有有效的調(diào)度方法，無法實(shí)現(xiàn)高度自動(dòng)化的編排。而基于云原生構(gòu)建的應(yīng)用，核心變成了云原生服務(wù)本身。當(dāng)用戶業(yè)務(wù)系統(tǒng)全面上云后，用戶不再享有對(duì)底層存儲(chǔ)的絕對(duì)控制權(quán)，所以傳統(tǒng)的容災(zāi)手段，就風(fēng)光不在了。

我認(rèn)為在構(gòu)建云原生容災(zāi)的解決方案上，要以業(yè)務(wù)為核心去思考構(gòu)建方法，利用云原生服務(wù)的編排能力實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)的連續(xù)性。

2)數(shù)據(jù)安全性

AWS CTO Werner Vogels 曾經(jīng)說過：Everything fails, all the time。通過 AWS 的責(zé)任共擔(dān)模型，我們不難發(fā)現(xiàn)云商對(duì)底層基礎(chǔ)架構(gòu)負(fù)責(zé)，用戶仍然要對(duì)自身自身數(shù)據(jù)安全性和業(yè)務(wù)連續(xù)性負(fù)責(zé)。

我認(rèn)為在云原生趨勢(shì)下，用戶最直接訴求的來自數(shù)據(jù)安全性即備份，而遷移、恢復(fù)、高可靠等都是基于備份表現(xiàn)出的業(yè)務(wù)形態(tài)，而備份能力可能是由云原生能力提供的，也有可能是第三方能力提供的，但最終實(shí)現(xiàn)業(yè)務(wù)形態(tài)，是由編排產(chǎn)生的。

用戶上云并不等于高枕無憂，相反用戶要學(xué)習(xí)云的正確打開方式，才能大程度來保證業(yè)務(wù)的連續(xù)性。雖然云在底層設(shè)計(jì)上是高可靠的，但是仍然避免不了外力造成的影響，例如：光纜被挖斷、斷電、人為誤操作導(dǎo)致的云平臺(tái)可用區(qū)無法使用，所以才有了類似“藍(lán)翔決定了中國(guó)云計(jì)算穩(wěn)定性”的調(diào)侃。我認(rèn)為用戶決定將業(yè)務(wù)遷移到云上的那一刻開始，備份、遷移、恢復(fù)、高可靠是一個(gè)連續(xù)的過程，如何合理利用云原生服務(wù)的特性實(shí)現(xiàn)業(yè)務(wù)連續(xù)性，同時(shí)進(jìn)行成本優(yōu)化，降低總體擁有成本(TCO)。

3)防止廠商鎖定

某種意義上說，云原生的方向是新一輪廠商鎖定，就像當(dāng)年盛極一時(shí)的 IOE 架構(gòu)一樣，只不過現(xiàn)在換成了云廠商作為底座承載應(yīng)用。在 IOE 時(shí)代，用戶很難找到好的替代品，但是在云時(shí)代，這種差異并不那么明顯。所以大部分的客戶通常選用混合云作為云建設(shè)策略，為了讓應(yīng)用在不同云之間能夠平滑移動(dòng)，利用容災(zāi)技術(shù)的遷移一定是作為一個(gè)常態(tài)化需求存在的。Gartnar 也在多云管平臺(tái)定義中，將遷移和 DR 作為單獨(dú)的一項(xiàng)能力。充分說明遷移與容災(zāi)在多云環(huán)境的的常態(tài)化趨勢(shì)。

云遷移與云容災(zāi)的關(guān)系

1. 云遷移需求的產(chǎn)生

在傳統(tǒng)環(huán)境下，遷移的需求并不十分突出，除非是遇到機(jī)房搬遷或者硬件升級(jí)，才會(huì)想到遷移，但這里的遷移更像是搬鐵，遷移工具化與自動(dòng)化的需求并不明顯。當(dāng) VMware 出現(xiàn)后，從物理環(huán)境到虛擬化的遷移需求被放大，但由于是單一的虛擬化平臺(tái)，基本上虛擬化廠商自身的工具就完全能夠滿足需求了。在虛擬化平臺(tái)上，大家突然發(fā)現(xiàn)原來只能人工操作的物理環(huán)境一下子輕盈起來，簡(jiǎn)單來說，我們的傳統(tǒng)服務(wù)器從一堆鐵變成了一個(gè)文件，并且這個(gè)文件還能夠被來回移動(dòng)、復(fù)制。再后來，進(jìn)入云時(shí)代，各家云平臺(tái)風(fēng)生水起，國(guó)內(nèi)云計(jì)算市場(chǎng)更是百家爭(zhēng)鳴，上云更是成為了一種剛性需求。隨著時(shí)間的推移，出于對(duì)成本、廠商鎖定等諸多因素的影響，在不同云之間的互相遷移更是會(huì)成為一種常態(tài)化的需求。

2. 底層技術(shù)一致

這里提到的云遷移和容災(zāi)，并不是堆人提供的遷移服務(wù)，而是強(qiáng)調(diào)的高度自動(dòng)化的手段。目標(biāo)就是在遷移過程中保證業(yè)務(wù)連續(xù)性，縮短停機(jī)時(shí)間甚至不停機(jī)的效果。這里就借助了容災(zāi)的存儲(chǔ)級(jí)別同步技術(shù)來實(shí)現(xiàn)在異構(gòu)環(huán)境下的的“熱遷移”?，F(xiàn)有解決方案里，既有傳統(tǒng)物理機(jī)搬遷時(shí)代的遷移軟件，也有基于云原生開發(fā)的工具。但無論何種形式，都在不同程度上都解決了用戶上云的基本訴求。大的區(qū)別在于人效比，這一點(diǎn)與你的利益直接相關(guān)。

從另外一個(gè)角度也不難發(fā)現(xiàn)，所謂的遷移在正式切換之前實(shí)質(zhì)上就是容災(zāi)的中間過程。同時(shí)，業(yè)務(wù)系統(tǒng)遷移到云平臺(tái)后，災(zāi)備是一個(gè)連續(xù)的動(dòng)作，這里既包含了傳統(tǒng)的備份和容災(zāi)，還應(yīng)該包含云上高可靠的概念。這樣，用戶業(yè)務(wù)系統(tǒng)在上云后，才能擺脫傳統(tǒng)基礎(chǔ)架構(gòu)的負(fù)擔(dān)，做到“零運(yùn)維”，真正享受到云所帶來的的紅利。所以，我認(rèn)為在云原生狀態(tài)下，云遷移、云容災(zāi)、云備份本質(zhì)上就是一種業(yè)務(wù)形態(tài)，底層采用的技術(shù)手段可以是完全一致的。

3. 發(fā)展方向

在上述的痛點(diǎn)和趨勢(shì)下，必然會(huì)出現(xiàn)一種全新的平臺(tái)來幫助客戶解決數(shù)據(jù)的安全性和業(yè)務(wù)連續(xù)性問題，今天就從這個(gè)角度來分析一下，在云原生的趨勢(shì)下如何構(gòu)建應(yīng)用系統(tǒng)的遷移與容災(zāi)方案。

云遷移發(fā)展趨勢(shì)

1. 云遷移方式

遷移是一項(xiàng)重度的咨詢業(yè)務(wù)，網(wǎng)上各家云商、MSP 都有自己的方法論，其實(shí)看下來差別都不大，之前也有很多人在分享相關(guān)話題，本文就不再贅述。這里我們重點(diǎn)討論，在實(shí)際落地過程中到底該采用哪種工具，哪種方式的效率最高。所謂云遷移工具，就是將源端遷移至目標(biāo)端，保證源端在目標(biāo)端正確運(yùn)行。常見的方式包括：物理機(jī)到虛擬化、虛擬化到虛擬化、物理機(jī)到云平臺(tái)、虛擬化到云平臺(tái)等。

這是經(jīng)典的 6R 遷移理論(現(xiàn)在已經(jīng)升級(jí)為了 7R，多了 VMware 出來攪局)，在這個(gè)圖中與真正遷移相關(guān)的其實(shí)只有 Rehosting、Replatforming、Repurchasing 和 Refactoring，但是在這 4R 中，Refactoring 明顯是一個(gè)長(zhǎng)期的迭代過程，需要用戶和軟件開發(fā)商共同參與解決，Repurchasing 基本上與人為重新部署沒有太大的區(qū)別。所以真正由用戶或 MSP 在短期完成的只剩下 Rehosting 和 Replatofrming。

與上面這張經(jīng)典的遷移理論相比，我更喜歡下面這張圖，這張圖更能反應(yīng)一個(gè)傳統(tǒng)應(yīng)用到云原生成長(zhǎng)的全過程。與上述的結(jié)論相似，我們?cè)谡嬲龘肀г频臅r(shí)候，路徑基本為上述的三條：

Lift & Shift 是 Rehost 方式的另一種稱呼，這種方式路面最寬，寓意這條路是上云的最短路徑，應(yīng)用不需要任何改造直接上云使用。

Evolve 和 Go Native 都屬于較窄的路徑，寓意為相對(duì)于 Rehost 方式，這兩條路徑所消耗的時(shí)間更久，難度更高。

在圖的最右側(cè)，三種形態(tài)是存在互相轉(zhuǎn)換的可能，最終演進(jìn)為徹底的云原生，寓意為遷移并不是一蹴而就，需要循序漸進(jìn)完成。

2. 重新托管(Rehost)方式

常用的重新托管方式為冷遷移和熱遷移，冷遷移往往涉及到步驟比較繁瑣，需要大量人力投入，并且容易出錯(cuò)效率低，對(duì)業(yè)務(wù)連續(xù)性有較大的影響，不適合生產(chǎn)系統(tǒng)遷移。而熱遷移方案基本都是商用化的解決方案，這里又分為塊級(jí)別和文件級(jí)別，再細(xì)分為傳統(tǒng)方案與云原生方案。

1)冷遷移

我們先來看一下冷遷移的手動(dòng)方案，以 VMware 到 OpenStack 為例，最簡(jiǎn)單的方式就是將 VMware 虛擬機(jī)文件(VMDK)通過 qemu-img 工具進(jìn)行格式轉(zhuǎn)換，轉(zhuǎn)換為 QCOW2 或者 RAW 格式，上傳至 OpenStack Glance 服務(wù)，再重新在云平臺(tái)上進(jìn)行啟動(dòng)。當(dāng)然這里面需要進(jìn)行 virtio 驅(qū)動(dòng)注入，否則主機(jī)無法正常在云平臺(tái)啟動(dòng)。這個(gè)過程中最耗時(shí)的應(yīng)該是虛擬機(jī)文件上傳至 OpenStack Glance 服務(wù)的過程，在我們最早期的實(shí)踐中，一臺(tái)主機(jī)從開始遷移到啟動(dòng)完成足足花了 24 小時(shí)。同時(shí)，在你遷移這段時(shí)間的數(shù)據(jù)是有增量產(chǎn)生的，除非你將源端關(guān)機(jī)等待遷移完成，否則，你還要將上述步驟重新來一遍。所以說這種方式真的不適合有業(yè)務(wù)連續(xù)性的生產(chǎn)系統(tǒng)進(jìn)行遷移。

那如果是物理機(jī)的冷遷移方案怎么做呢?經(jīng)過我們的好實(shí)踐，這里為大家推薦的是老牌的備份工具 CloneZilla，中文名為再生龍。是一款非常老牌的備份軟件，常用于進(jìn)行整機(jī)備份與恢復(fù)，與我們常見的 Norton Ghost 原理非常相似。CloneZilla 從底層的塊級(jí)別進(jìn)行復(fù)制，可以進(jìn)行整盤的備份，并且支持多種目標(biāo)端，例如我們將磁盤保存至移動(dòng)硬盤，實(shí)際格式就是 RAW，你只需要重復(fù)上述的方案即可完成遷移。但是在使用 CloneZilla 過程中，需要使用 Live CD 方式進(jìn)行引導(dǎo)，同樣會(huì)面臨長(zhǎng)時(shí)間業(yè)務(wù)系統(tǒng)中斷的問題，這也是上面我們提到的冷遷移并不適合生產(chǎn)環(huán)境遷移的原因。

2)傳統(tǒng)熱遷移方案

傳統(tǒng)的熱遷移方案基本分為塊級(jí)別和文件級(jí)別，兩者相似之處都是利用差量同步技術(shù)進(jìn)行實(shí)現(xiàn)，即全量和增量交叉同步方式。

文件級(jí)別的熱遷移方案往往局限性較大，并不能算真正的 ReHost 方式，因?yàn)榍捌谛枰獪?zhǔn)備于源端完全一樣的操作系統(tǒng)，無法實(shí)現(xiàn)整機(jī)搬遷，從操作的復(fù)雜性更大和遷移的穩(wěn)定性來說都不高。我們?cè)?Linux 上常用的 Rsync 其實(shí)可以作為文件級(jí)別熱遷移的一種解決方案。

真正可以實(shí)現(xiàn)熱遷移的方案，還要使用塊級(jí)別同步，降低對(duì)底層操作系統(tǒng)依賴，實(shí)現(xiàn)整機(jī)的搬遷效果。傳統(tǒng)的塊級(jí)別熱遷移方案基本上來自于傳統(tǒng)容災(zāi)方案的變種，利用內(nèi)存操作系統(tǒng) WIN PE 或其他 Live CD 實(shí)現(xiàn)，基本原理和過程如下圖所示。從過程中我們不難發(fā)現(xiàn)這種方式雖然在一定程度解決了遷移的目標(biāo)，但是作為未來混合云常態(tài)化遷移需求來說，仍然有以下幾點(diǎn)不足：

由于傳統(tǒng)熱遷移方案是基于物理環(huán)境構(gòu)建的，所以我們發(fā)現(xiàn)在整個(gè)過程中人為介入非常多，對(duì)于使用者的技能要求比較高

無法滿足云原生時(shí)代多租戶、自服務(wù)的需求

安裝代理是用戶心中永遠(yuǎn)的芥蒂

一比一同步方式，從成本角度來說不夠經(jīng)濟(jì)

最好的遷移驗(yàn)證方式，就是將業(yè)務(wù)系統(tǒng)集群在云端完全恢復(fù)，但是手動(dòng)驗(yàn)證的方式，對(duì)遷移人力成本是再一次增加

3)云原生熱遷移方案

正是由于傳統(tǒng)遷移方案的弊端，應(yīng)運(yùn)而生了云原生的熱遷移方案，這一方面的代表廠商當(dāng)屬 AWS 在 2019 年以 2.5 億美金擊敗 Google Cloud 收購(gòu)的以色列云原生容災(zāi)、遷移廠商 CloudEndure。

云原生熱遷移方案是指利用塊級(jí)別差量同步技術(shù)結(jié)合云原生 API 接口和資源實(shí)現(xiàn)高度自動(dòng)化遷移效果，同時(shí)提供多租戶、API 接口滿足混合云租戶自服務(wù)的需求。我們先從原理角度分析一下，為什么相對(duì)于傳統(tǒng)方案，云原生的方式能夠滿足高度自動(dòng)化、用戶自服務(wù)的用戶體驗(yàn)。通過兩個(gè)方案對(duì)比，我們不難發(fā)現(xiàn)云原生方式的幾個(gè)優(yōu)勢(shì)：

利用云原生 API 接口和資源，操作簡(jiǎn)便，完全取代了傳統(tǒng)方案大量繁瑣的人為操作，對(duì)使用者技術(shù)要求降低，學(xué)習(xí)陡峭程度大幅度降低

由于操作簡(jiǎn)便，遷移效率提高，有效提高遷移實(shí)施的人效比

一對(duì)多的同步方式，大幅度降低計(jì)算資源使用，計(jì)算資源只在驗(yàn)證和最終切換時(shí)使用

能夠滿足多租戶、自服務(wù)的要求

源端也可以支持無代理方式，打消用戶疑慮，并且適合大規(guī)模批量遷移

高度自動(dòng)化的驗(yàn)證手段，在完成遷移切換前，能夠反復(fù)進(jìn)行驗(yàn)證

這是 CloudEndure 的架構(gòu)圖，當(dāng)然你也可以利用 CloudEndure 實(shí)現(xiàn)跨區(qū)域的容災(zāi)。

不過可惜的一點(diǎn)是由于被 AWS 收購(gòu)，CloudEndure 目前只能支持遷移至 AWS，無法滿足國(guó)內(nèi)各種云遷移的需求。所以這里為大家推薦一款純國(guó)產(chǎn)化的遷移平臺(tái)——萬博智云的 HyperMotion，從原理上與 CloudEndure 非常相似，同時(shí)支持了 VMware 及 OpenStack 無代理的遷移，更重要的是覆蓋了國(guó)內(nèi)主流的公有云、專有云和私有云的遷移。

3. 平臺(tái)重建(Replatforming)方式

隨著云原生提供越來越多的服務(wù)，降低了應(yīng)用架構(gòu)的復(fù)雜度，使得企業(yè)能夠更專注自己的業(yè)務(wù)本身開發(fā)。但是研發(fā)側(cè)工作量的減少意味著這部分成本被轉(zhuǎn)嫁到部署及運(yùn)維環(huán)節(jié)，所以 DevOps 成為在云原生運(yùn)用中比不可少的一個(gè)緩解，也讓企業(yè)能夠更敏捷的應(yīng)對(duì)業(yè)務(wù)上的復(fù)雜變化。

正如上面所提到的，用戶通過少量的改造可以優(yōu)先使用一部分云原生服務(wù)，這種遷移方式我們成為平臺(tái)重建(Replatforming)，目前選擇平臺(tái)重建方式的遷移，多以與用戶數(shù)據(jù)相關(guān)的服務(wù)為主。常見的包括：數(shù)據(jù)庫(kù)服務(wù) RDS、對(duì)象存儲(chǔ)服務(wù)、消息隊(duì)列服務(wù)、容器服務(wù)等。這些云原生服務(wù)的引入，降低了用戶運(yùn)維成本。但是由于云原生服務(wù)自身封裝非常嚴(yán)密，底層的基礎(chǔ)架構(gòu)層對(duì)于用戶完全不可見，所以無法用上述 Rehost 方式進(jìn)行遷移，必須采用其他的輔助手段完成。

以關(guān)系型數(shù)據(jù)庫(kù)為例，每一種云幾乎都提供了遷移工具，像 AWS DMS，阿里云的 DTS，騰訊云的數(shù)據(jù)傳輸服務(wù) DTS，這些云原生工具都可以支持 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多種關(guān)系型數(shù)據(jù)庫(kù)及 NoSQL 數(shù)據(jù)庫(kù)遷移。以 MySQL 為例，這些服務(wù)都巧妙的利用了 binlog 復(fù)制的方式，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)的在線遷移。

再以對(duì)象存儲(chǔ)為例，幾乎每一種云都提供了自己的遷移工具，像阿里云的 ossimport，騰訊云 COS Migration 工具，都可以實(shí)現(xiàn)本地到云端對(duì)象存儲(chǔ)的增量遷移。但是在實(shí)際遷移時(shí)，還應(yīng)考慮成本問題，公有云的對(duì)象存儲(chǔ)在存儲(chǔ)數(shù)據(jù)上比較便宜，但是在讀出數(shù)據(jù)時(shí)是要根據(jù)網(wǎng)絡(luò)流量和請(qǐng)求次數(shù)進(jìn)行收費(fèi)的，這就要求我們?cè)谠O(shè)計(jì)遷移方案時(shí)，充分考慮成本因素。如果數(shù)據(jù)量過大，還可以考慮采用離線設(shè)備方式，例如：AWS 的 Snowball，阿里云的閃電立方等。這部分就不展開介紹，以后有機(jī)會(huì)再單獨(dú)為大家介紹。

如果選擇平臺(tái)重建方式上云，除了要進(jìn)行必要的應(yīng)用改造，還需要選擇一款適合你的遷移工具，保證數(shù)據(jù)能夠平滑上云。結(jié)合上面的 Rehost 方式遷移，能夠?qū)崿F(xiàn)業(yè)務(wù)系統(tǒng)的整體上云效果。由于涉及的服務(wù)較多，這里為大家提供一張遷移工具表格供大家參考。

云原生下的容災(zāi)發(fā)展趨勢(shì)

目前為止，還沒有一套平臺(tái)能夠完全滿足云原生狀態(tài)下的統(tǒng)一容災(zāi)需求，我們通過以下場(chǎng)景來分析一下，如何才能構(gòu)建一套統(tǒng)一的容災(zāi)平臺(tái)滿足云原生的需求。

1. 傳統(tǒng)架構(gòu)

我們以一個(gè)簡(jiǎn)單的 Wordpress + MySQL 環(huán)境為例，傳統(tǒng)下的部署環(huán)境一般是這樣架構(gòu)的：

如果為這套應(yīng)用架構(gòu)設(shè)計(jì)一套容災(zāi)方案，可以采用以下的方式：

1)負(fù)載均衡節(jié)點(diǎn)容災(zāi)

負(fù)載均衡分為硬件和軟件層面，硬件負(fù)載均衡高可靠和容災(zāi)往往通過自身的解決方案實(shí)現(xiàn)。如果是軟件負(fù)載均衡，往往需要安裝在基礎(chǔ)操作系統(tǒng)上，而同城的容災(zāi)可以使用軟件高可靠的方式實(shí)現(xiàn)，而異地的容災(zāi)往往是通過提前建立對(duì)等節(jié)點(diǎn)，或者干脆采用容災(zāi)軟件的塊或者文件級(jí)別容災(zāi)實(shí)現(xiàn)。是容災(zāi)切換(Failover)很重要的一個(gè)環(huán)節(jié)。

2)Web Server 的容災(zāi)

Wordpress 的運(yùn)行環(huán)境無非是 Apache + PHP，由于分離了用于存放用戶上傳的文件系統(tǒng)，所以該節(jié)點(diǎn)幾乎是無狀態(tài)的，通過擴(kuò)展節(jié)點(diǎn)即可實(shí)現(xiàn)高可靠，而異地容災(zāi)也比較簡(jiǎn)單，傳統(tǒng)的塊級(jí)別和文件級(jí)別都可以滿足容災(zāi)的需求。

3)共享文件系統(tǒng)的容災(zāi)

圖中采用了 Gluster 的文件系統(tǒng)，由于分布式系統(tǒng)的一致性通常由內(nèi)部維護(hù)，單純使用塊級(jí)別很難保證節(jié)點(diǎn)的一致性，所以這里面使用文件級(jí)別容災(zāi)更為精確。

4)數(shù)據(jù)庫(kù)的容災(zāi)

單純依靠存儲(chǔ)層面是無法根本實(shí)現(xiàn)數(shù)據(jù)庫(kù) 0 丟失數(shù)據(jù)的，所以一般采用從數(shù)據(jù)庫(kù)層面實(shí)現(xiàn)，當(dāng)然如果為了降低成本，數(shù)據(jù)庫(kù)的容災(zāi)可以簡(jiǎn)單的使用周期 Dump 數(shù)據(jù)庫(kù)的方式實(shí)現(xiàn)，當(dāng)然如果對(duì)可靠性要求較高，還可以使用 CDP 方式實(shí)現(xiàn)。

從以上的案例分析不難看出，傳統(tǒng)基礎(chǔ)架構(gòu)下的容災(zāi)往往以存儲(chǔ)為核心，無論是磁盤陣列的存儲(chǔ)鏡像，還是基于 I/O 數(shù)據(jù)塊、字節(jié)級(jí)的捕獲技術(shù)，結(jié)合網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)和集群的應(yīng)用級(jí)別技術(shù)完成高可靠和容災(zāi)體系的構(gòu)建。在整個(gè)容災(zāi)過程的參與者主要為：主機(jī)、存儲(chǔ)、網(wǎng)絡(luò)和應(yīng)用軟件，相對(duì)來說比較單一。所以在傳統(tǒng)容災(zāi)方案中，如何正確解決存儲(chǔ)的容災(zāi)也就成為了解決問題的關(guān)鍵。

2. 混合云容災(zāi)

這應(yīng)該是目前最常見的混合云的方案，也是各大容災(zāi)廠商主推的一種方式。這里我們相當(dāng)于將云平臺(tái)當(dāng)成了一套虛擬化平臺(tái)，幾乎沒有利用云平臺(tái)任何特性。在恢復(fù)過程中，需要大量人為的接入才能將業(yè)務(wù)系統(tǒng)恢復(fù)到可用狀態(tài)。這樣的架構(gòu)并不符合云上的好實(shí)踐，但的確是很多業(yè)務(wù)系統(tǒng)備份或遷移上云后真實(shí)的寫照。

這樣的架構(gòu)確實(shí)能解決容災(zāi)的問題，但是從成本上來說很高，現(xiàn)在我們來?yè)Q一種方式。我們利用了對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)進(jìn)行一次優(yōu)化。我們將原有存儲(chǔ)服務(wù)存放至對(duì)象存儲(chǔ)中，而使用數(shù)據(jù)傳輸服務(wù)來進(jìn)行實(shí)時(shí)的數(shù)據(jù)庫(kù)復(fù)制。云主機(jī)仍然采用傳統(tǒng)的塊級(jí)別進(jìn)行同步。一旦出現(xiàn)故障，則需要自動(dòng)化編排能力，重新將備份進(jìn)行恢復(fù)，在最短時(shí)間內(nèi)根據(jù)我們預(yù)設(shè)的方案進(jìn)行恢復(fù)，完成容災(zāi)。

3. 云上同城容災(zāi)架構(gòu)

上述的備份方式，實(shí)質(zhì)上就是利用平臺(tái)重建的方式進(jìn)行的遷移，既然已經(jīng)利用遷移進(jìn)行了備份，那完全可以對(duì)架構(gòu)進(jìn)行如下改造，形成同城的容災(zāi)架構(gòu)。我們根據(jù)云平臺(tái)的好實(shí)踐，對(duì)架構(gòu)進(jìn)行了如下調(diào)整：

這個(gè)架構(gòu)不僅實(shí)現(xiàn)了應(yīng)用級(jí)高可靠，還能夠支撐一定的高并發(fā)性，用戶在最少改造代價(jià)下就能夠在同城實(shí)現(xiàn)雙活的效果。我們來分析一下在云上利用了多少云原生的服務(wù)：

域名解析服務(wù)

VPC 服務(wù)

負(fù)載均衡服務(wù)

自動(dòng)伸縮服務(wù)

云主機(jī)服務(wù)

對(duì)象存儲(chǔ)服務(wù)

關(guān)系型數(shù)據(jù)庫(kù) RDS 服務(wù)

除了云主機(jī)外，其他服務(wù)均是天然就支持跨可用區(qū)的高可用特性，對(duì)于云主機(jī)我們可以制作鏡像方式，由自動(dòng)伸縮服務(wù)負(fù)責(zé)實(shí)例的狀態(tài)。由于云上可用區(qū)就是同城容災(zāi)的概念，這里我們就實(shí)現(xiàn)了同城的業(yè)務(wù)系統(tǒng)容災(zāi)。

經(jīng)過調(diào)整的架構(gòu)在一定程度上滿足了業(yè)務(wù)連續(xù)性的要求，但是對(duì)于數(shù)據(jù)的安全性仍然缺乏保障。近幾年，勒索病毒橫行，大量企業(yè)為此蒙受巨大損失，所以數(shù)據(jù)備份是上云后必須實(shí)施的。云原生服務(wù)本身提供了備份方案，例如云主機(jī)的定期快照等，但往往服務(wù)比較分散，不容易統(tǒng)一進(jìn)行管理。同時(shí)，在恢復(fù)時(shí)往往也是只能每一個(gè)服務(wù)進(jìn)行恢復(fù)，如果業(yè)務(wù)系統(tǒng)規(guī)模較大，也會(huì)增加大量的恢復(fù)成本。雖然云原生服務(wù)解決了自身備份問題，但是將備份重新組織成應(yīng)用是需要利用自動(dòng)化的編排能力實(shí)現(xiàn)。

4. 同云異地容災(zāi)架構(gòu)

大部分的云原生服務(wù)都在可用區(qū)內(nèi)，提供了高可靠能力，但是對(duì)于跨區(qū)域上通常提供的是備份能力。例如：可以將云主機(jī)變?yōu)殓R像，將鏡像復(fù)制到其他區(qū)域內(nèi);關(guān)系型數(shù)據(jù)庫(kù)和對(duì)象存儲(chǔ)也具備跨域的備份能力。利用這些組件自身的備份能力，外加上云自身資源的編排能力，我們可以實(shí)現(xiàn)在容災(zāi)可用域?qū)⑾到y(tǒng)恢復(fù)至可用狀態(tài)。那如何觸發(fā)切換呢?

這里我們根據(jù)業(yè)務(wù)系統(tǒng)的特點(diǎn)，在云原生的監(jiān)控上定制告警，利用告警平臺(tái)的觸發(fā)能力觸發(fā)函數(shù)計(jì)算，完成業(yè)務(wù)系統(tǒng)的跨域切換，形成異地容災(zāi)的效果。

5. 跨云容災(zāi)

但跨云容災(zāi)不像同云容災(zāi)時(shí)，在不同的可用區(qū)之間至少服務(wù)是一致的，那么此時(shí)，在同云上使用的方法基本失效，完全需要目標(biāo)云平臺(tái)的能力或者中立的第三方的解決方案。這里除了數(shù)據(jù)的備份，還有一點(diǎn)是服務(wù)配置的互相匹配。才能完全滿足跨云容災(zāi)恢復(fù)的需求。另外需要考慮的一點(diǎn)就是成本為例，以對(duì)象存儲(chǔ)為例，是典型的的“上云容易下云難”。所以如何利用云原生資源特性合理設(shè)計(jì)容災(zāi)方案是對(duì)成本的極大考驗(yàn)。

總結(jié)

云原生容災(zāi)還處于早期階段，目前尚沒有完整的平臺(tái)能夠支持以上各種場(chǎng)景的容災(zāi)需求，是值得持續(xù)探索的話題。云原生容災(zāi)以備份為核心，以遷移、恢復(fù)和高可靠為業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)多云之間的自由流轉(zhuǎn)，最終滿足用戶的業(yè)務(wù)需求。

所以，作為面向云原生的容災(zāi)平臺(tái)要解決好三方面的能力：

以數(shù)據(jù)為核心，讓數(shù)據(jù)在多云之間互相流轉(zhuǎn)。數(shù)據(jù)是用戶核心價(jià)值，所以無論底層基礎(chǔ)架構(gòu)如何變化，數(shù)據(jù)備份一定是用戶的剛醒需求。對(duì)于不同云原生服務(wù)如何解決好數(shù)據(jù)備份，是數(shù)據(jù)流轉(zhuǎn)的必要基礎(chǔ)。

利用云原生編排能力，實(shí)現(xiàn)高度自動(dòng)化，在數(shù)據(jù)基礎(chǔ)上構(gòu)建業(yè)務(wù)場(chǎng)景。利用自動(dòng)化編排能力實(shí)現(xiàn)更多的基于數(shù)據(jù)層的應(yīng)用，幫助用戶完成更多的業(yè)務(wù)創(chuàng)新。

靈活運(yùn)用云原生資源特點(diǎn)，降低總體擁有成本。解決傳統(tǒng)容災(zāi)投入巨大的問題，讓用戶的成本真的能像水、電一樣按需付費(fèi)。

文章名稱：云原生趨勢(shì)下的遷移與容災(zāi)思考
轉(zhuǎn)載來于：http://www.rwnh.cn/news33/201333.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動(dòng)態(tài)網(wǎng)站、網(wǎng)站策劃、虛擬主機(jī)、網(wǎng)站營(yíng)銷、軟件開發(fā)、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)