免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

云原生趨勢(shì)下的遷移與容災(zāi)思考

2022-10-04    分類(lèi): 網(wǎng)站建設(shè)

趨勢(shì)

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

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

2020 年 9 月,Snowflake 以每股 120 美金 IPO,創(chuàng)造了今年規(guī)模大的 IPO,也是有史以來(lái)大的軟件 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)的層次上,而忽略了面向云的特性和用戶(hù)業(yè)務(wù)重新思考和構(gòu)建。云計(jì)算的愿景是讓云資源像水、電一樣按需使用,所以基于云上的遷移和容災(zāi)也理應(yīng)順應(yīng)這樣的歷史潮流。Snowflake 也是通過(guò)這種商業(yè)模式的創(chuàng)新,成功打破舊的競(jìng)爭(zhēng)格局。

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

我認(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)說(shuō)過(guò):Everything fails, all the time。通過(guò) AWS 的責(zé)任共擔(dān)模型,我們不難發(fā)現(xiàn)云商對(duì)底層基礎(chǔ)架構(gòu)負(fù)責(zé),用戶(hù)仍然要對(duì)自身自身數(shù)據(jù)安全性和業(yè)務(wù)連續(xù)性負(fù)責(zé)。

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

3)防止廠商鎖定

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

云遷移與云容災(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),基本上虛擬化廠商自身的工具就完全能夠滿(mǎn)足需求了。在虛擬化平臺(tái)上,大家突然發(fā)現(xiàn)原來(lái)只能人工操作的物理環(huán)境一下子輕盈起來(lái),簡(jiǎn)單來(lái)說(shuō),我們的傳統(tǒng)服務(wù)器從一堆鐵變成了一個(gè)文件,并且這個(gè)文件還能夠被來(lái)回移動(dòng)、復(fù)制。再后來(lái),進(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)就是在遷移過(guò)程中保證業(yè)務(wù)連續(xù)性,縮短停機(jī)時(shí)間甚至不停機(jī)的效果。這里就借助了容災(zāi)的存儲(chǔ)級(jí)別同步技術(shù)來(lái)實(shí)現(xiàn)在異構(gòu)環(huán)境下的的“熱遷移”。現(xiàn)有解決方案里,既有傳統(tǒng)物理機(jī)搬遷時(shí)代的遷移軟件,也有基于云原生開(kāi)發(fā)的工具。但無(wú)論何種形式,都在不同程度上都解決了用戶(hù)上云的基本訴求。大的區(qū)別在于人效比,這一點(diǎn)與你的利益直接相關(guān)。

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

3. 發(fā)展方向

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

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

1. 云遷移方式

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

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

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

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

2. 重新托管(Rehost)方式

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

1)冷遷移

我們先來(lái)看一下冷遷移的手動(dòng)方案,以 VMware 到 OpenStack 為例,最簡(jiǎn)單的方式就是將 VMware 虛擬機(jī)文件(VMDK)通過(guò) 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ī)無(wú)法正常在云平臺(tái)啟動(dòng)。這個(gè)過(guò)程中最耗時(shí)的應(yīng)該是虛擬機(jī)文件上傳至 OpenStack Glance 服務(wù)的過(guò)程,在我們最早期的實(shí)踐中,一臺(tái)主機(jī)從開(kāi)始遷移到啟動(dòng)完成足足花了 24 小時(shí)。同時(shí),在你遷移這段時(shí)間的數(shù)據(jù)是有增量產(chǎn)生的,除非你將源端關(guān)機(jī)等待遷移完成,否則,你還要將上述步驟重新來(lái)一遍。所以說(shuō)這種方式真的不適合有業(yè)務(wù)連續(xù)性的生產(chǎn)系統(tǒng)進(jìn)行遷移。

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

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

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

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

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

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

一比一同步方式,從成本角度來(lái)說(shuō)不夠經(jīng)濟(jì)

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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í)提供多租戶(hù)、API 接口滿(mǎn)足混合云租戶(hù)自服務(wù)的需求。我們先從原理角度分析一下,為什么相對(duì)于傳統(tǒng)方案,云原生的方式能夠滿(mǎn)足高度自動(dòng)化、用戶(hù)自服務(wù)的用戶(hù)體驗(yàn)。通過(guò)兩個(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í)使用

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

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

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

正如上面所提到的,用戶(hù)通過(guò)少量的改造可以?xún)?yōu)先使用一部分云原生服務(wù),這種遷移方式我們成為平臺(tái)重建(Replatforming),目前選擇平臺(tái)重建方式的遷移,多以與用戶(hù)數(shù)據(jù)相關(guān)的服務(wù)為主。常見(jiàn)的包括:數(shù)據(jù)庫(kù)服務(wù) RDS、對(duì)象存儲(chǔ)服務(wù)、消息隊(duì)列服務(wù)、容器服務(wù)等。這些云原生服務(wù)的引入,降低了用戶(hù)運(yùn)維成本。但是由于云原生服務(wù)自身封裝非常嚴(yán)密,底層的基礎(chǔ)架構(gòu)層對(duì)于用戶(hù)完全不可見(jiàn),所以無(wú)法用上述 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)考慮成本問(wèn)題,公有云的對(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ù)量過(guò)大,還可以考慮采用離線設(shè)備方式,例如:AWS 的 Snowball,阿里云的閃電立方等。這部分就不展開(kāi)介紹,以后有機(jī)會(huì)再單獨(dú)為大家介紹。

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

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

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

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

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

負(fù)載均衡分為硬件和軟件層面,硬件負(fù)載均衡高可靠和容災(zāi)往往通過(guò)自身的解決方案實(shí)現(xiàn)。如果是軟件負(fù)載均衡,往往需要安裝在基礎(chǔ)操作系統(tǒng)上,而同城的容災(zāi)可以使用軟件高可靠的方式實(shí)現(xiàn),而異地的容災(zāi)往往是通過(guò)提前建立對(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)境無(wú)非是 Apache + PHP,由于分離了用于存放用戶(hù)上傳的文件系統(tǒng),所以該節(jié)點(diǎn)幾乎是無(wú)狀態(tài)的,通過(guò)擴(kuò)展節(jié)點(diǎn)即可實(shí)現(xiàn)高可靠,而異地容災(zāi)也比較簡(jiǎn)單,傳統(tǒng)的塊級(jí)別和文件級(jí)別都可以滿(mǎn)足容災(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ǔ)層面是無(wú)法根本實(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ǔ)為核心,無(wú)論是磁盤(pán)陣列的存儲(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)過(guò)程的參與者主要為:主機(jī)、存儲(chǔ)、網(wǎng)絡(luò)和應(yīng)用軟件,相對(duì)來(lái)說(shuō)比較單一。所以在傳統(tǒng)容災(zāi)方案中,如何正確解決存儲(chǔ)的容災(zāi)也就成為了解決問(wèn)題的關(guān)鍵。

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

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

這樣的架構(gòu)確實(shí)能解決容災(zāi)的問(wèn)題,但是從成本上來(lái)說(shuō)很高,現(xiàn)在我們來(lái)?yè)Q一種方式。我們利用了對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)進(jìn)行一次優(yōu)化。我們將原有存儲(chǔ)服務(wù)存放至對(duì)象存儲(chǔ)中,而使用數(shù)據(jù)傳輸服務(wù)來(lái)進(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)。

云原生趨勢(shì)下的遷移與容災(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)整:

云原生趨勢(shì)下的遷移與容災(zāi)思考

這個(gè)架構(gòu)不僅實(shí)現(xiàn)了應(yīng)用級(jí)高可靠,還能夠支撐一定的高并發(fā)性,用戶(hù)在最少改造代價(jià)下就能夠在同城實(shí)現(xiàn)雙活的效果。我們來(lái)分析一下在云上利用了多少云原生的服務(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)過(guò)調(diào)整的架構(gòu)在一定程度上滿(mǎn)足了業(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ù)解決了自身備份問(wèn)題,但是將備份重新組織成應(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)的效果。

云原生趨勢(shì)下的遷移與容災(zāi)思考

5. 跨云容災(zāi)

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

云原生趨勢(shì)下的遷移與容災(zāi)思考

總結(jié)

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

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

以數(shù)據(jù)為核心,讓數(shù)據(jù)在多云之間互相流轉(zhuǎn)。數(shù)據(jù)是用戶(hù)核心價(jià)值,所以無(wú)論底層基礎(chǔ)架構(gòu)如何變化,數(shù)據(jù)備份一定是用戶(hù)的剛醒需求。對(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)用,幫助用戶(hù)完成更多的業(yè)務(wù)創(chuàng)新。

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

文章名稱(chēng):云原生趨勢(shì)下的遷移與容災(zāi)思考
轉(zhuǎn)載來(lái)于:http://m.newbst.com/news33/201333.html

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

廣告

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

網(wǎng)站建設(shè)網(wǎng)站維護(hù)公司