云原生趨勢下的遷移與容災思考

趨勢

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

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

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

2. 為什么云上需要全新的遷移和容災?

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

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

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

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

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

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

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

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

3)防止廠商鎖定

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

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

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

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

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

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

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

3. 發(fā)展方向

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

云遷移發(fā)展趨勢

1. 云遷移方式

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

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

與上面這張經(jīng)典的遷移理論相比，我更喜歡下面這張圖，這張圖更能反應一個傳統(tǒng)應用到云原生成長的全過程。與上述的結(jié)論相似，我們在真正擁抱云的時候，路徑基本為上述的三條：

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

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

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

2. 重新托管(Rehost)方式

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

1)冷遷移

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

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

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

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

文件級別的熱遷移方案往往局限性較大，并不能算真正的 ReHost 方式，因為前期需要準備于源端完全一樣的操作系統(tǒng)，無法實現(xiàn)整機搬遷，從操作的復雜性更大和遷移的穩(wěn)定性來說都不高。我們在 Linux 上常用的 Rsync 其實可以作為文件級別熱遷移的一種解決方案。

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

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

無法滿足云原生時代多租戶、自服務的需求

安裝代理是用戶心中永遠的芥蒂

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

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

3)云原生熱遷移方案

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

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

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

由于操作簡便，遷移效率提高，有效提高遷移實施的人效比

一對多的同步方式，大幅度降低計算資源使用，計算資源只在驗證和最終切換時使用

能夠滿足多租戶、自服務的要求

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

高度自動化的驗證手段，在完成遷移切換前，能夠反復進行驗證

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

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

3. 平臺重建(Replatforming)方式

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

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

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

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

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

云原生下的容災發(fā)展趨勢

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

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

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

如果為這套應用架構(gòu)設計一套容災方案，可以采用以下的方式：

1)負載均衡節(jié)點容災

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

2)Web Server 的容災

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

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

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

4)數(shù)據(jù)庫的容災

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

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

2. 混合云容災

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

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

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

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

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

域名解析服務

VPC 服務

負載均衡服務

自動伸縮服務

云主機服務

對象存儲服務

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

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

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

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

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

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

5. 跨云容災

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

總結(jié)

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

所以，作為面向云原生的容災平臺要解決好三方面的能力：

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

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

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

文章標題：云原生趨勢下的遷移與容災思考
本文來源：http://bm7419.com/news/201333.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、定制網(wǎng)站、云服務器、關(guān)鍵詞優(yōu)化、外貿(mào)建站、小程序開發(fā)

廣告

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