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

來源 | 阿里巴巴雲原生公衆號

做者 | 孫琦

導讀：下一個雲原生顛覆的領域會不會是在傳統的容災領域呢？在雲原生的趨勢下，如何構建應用系統的遷移與容災方案？

趨勢

1. 雲原生髮展趨勢

雲原生（Cloud Native）是最近幾年很是火爆的話題，在 2020 年 7 月由信通院發佈的《雲原生髮展白皮書（2020）年》明確指出：雲計算的拐點已到，雲原生成爲驅動業務增加的重要引擎。咱們不難發現雲原生帶給 IT 產業一次從新洗牌，從應用開發過程到 IT 從業者的技術能力，都是一次顛覆性的革命。在此基礎上，出現了基於雲原平生臺的 Open Application Model 定義，在雲原平生臺基礎上進一步抽象，更加關注應用而非基礎架構。同時，愈來愈多的公有云開始支持 Serverless 服務，更加說明了將來的發展趨勢：應用爲核心，輕量化基礎架構層在系統建設過程當中的角色。可是不管如何變化，IT 總體發展方向，必定是向着更有利於業務快速迭代、知足業務需求方向演進的。

2020 年 9 月，Snowflake 以每股 120 美金 IPO，創造了今年規模最大的 IPO，也是有史以來最大的軟件 IPO。Snowflake 利用雲原生方式重構了數據倉庫，成功顛覆了行業競爭格局。這正是市場對雲原生髮展趨勢的最佳承認，因此下一個雲原生顛覆的領域會不會是在傳統的容災領域呢？

2. 爲何雲上須要全新的遷移和容災？

1）傳統方案的侷限性

在這種大的趨勢下，傳統的遷移和容災仍然停留在數據搬運的層次上，而忽略了面向雲的特性和用戶業務從新思考和構建。雲計算的願景是讓雲資源像水、電同樣按需使用，因此基於雲上的遷移和容災也理應順應這樣的歷史潮流。Snowflake 也是經過這種商業模式的創新，成功打破舊的競爭格局。

爲何傳統容災的手段沒法知足雲原生需求呢？簡單來講，兩者關注的核心不一樣。傳統的容災每每以存儲爲核心，擁有對存儲的至高無上的控制權。而且在物理時代，對於計算、存儲和網絡等基礎架構層也沒有有效的調度方法，沒法實現高度自動化的編排。而基於雲原生構建的應用，核心變成了雲原生服務自己。當用戶業務系統全面上雲後，用戶再也不享有對底層存儲的絕對控制權，因此傳統的容災手段，就風光不在了。

我認爲在構建雲原生容災的解決方案上，要以業務爲核心去思考構建方法，利用雲原生服務的編排能力實現業務系統的連續性。

2）數據安全性

AWS CTO Werner Vogels 曾經說過：Everything fails, all the time。經過 AWS 的責任共擔模型，咱們不難發現雲商對底層基礎架構負責，用戶仍然要對自身自身數據安全性和業務連續性負責。

我認爲在雲原生趨勢下，用戶最直接訴求的來自數據安全性即備份，而遷移、恢復、高可靠等都是基於備份表現出的業務形態，而備份能力多是由雲原生能力提供的，也有多是第三方能力提供的，但最終實現業務形態，是由編排產生的。

用戶上雲並不等於高枕無憂，相反用戶要學習雲的正確打開方式，才能最大程度來保證業務的連續性。雖然雲在底層設計上是高可靠的，可是仍然避免不了外力形成的影響，例如：光纜被挖斷、斷電、人爲誤操做致使的雲平臺可用區沒法使用，因此纔有了相似「藍翔決定了中國雲計算穩定性」的調侃。我認爲用戶決定將業務遷移到雲上的那一刻開始，備份、遷移、恢復、高可靠是一個連續的過程，如何合理利用雲原生服務的特性實現業務連續性，同時進行成本優化，下降整體擁有成本（TCO）。

3）防止廠商鎖定

某種意義上說，雲原生的方向是新一輪廠商鎖定，就像當年盛極一時的 IOE 架構同樣，只不過如今換成了雲廠商做爲底座承載應用。在 IOE 時代，用戶很難找到完美的替代品，可是在雲時代，這種差別並不那麼明顯。因此大部分的客戶一般選用混合雲做爲雲建設策略，爲了讓應用在不一樣雲之間可以平滑移動，利用容災技術的遷移必定是做爲一個常態化需求存在的。Gartnar 也在多雲管平臺定義中，將遷移和 DR 做爲單獨的一項能力。充分說明遷移與容災在多雲環境的的常態化趨勢。

雲遷移與雲容災的關係

1. 雲遷移需求的產生

在傳統環境下，遷移的需求並不十分突出，除非是遇到機房搬遷或者硬件升級，纔會想到遷移，但這裏的遷移更像是搬鐵，遷移工具化與自動化的需求並不明顯。當 VMware 出現後，從物理環境到虛擬化的遷移需求被放大，但因爲是單一的虛擬化平臺，基本上虛擬化廠商自身的工具就徹底可以知足需求了。在虛擬化平臺上，你們忽然發現原來只能人工操做的物理環境一會兒輕盈起來，簡單來講，咱們的傳統服務器從一堆鐵變成了一個文件，而且這個文件還可以被來回移動、複製。再後來，進入雲時代，各家雲平臺風生水起，國內雲計算市場更是百家爭鳴，上雲更是成爲了一種剛性需求。隨着時間的推移，出於對成本、廠商鎖定等諸多因素的影響，在不一樣雲之間的互相遷移更是會成爲一種常態化的需求。

2. 底層技術一致

這裏提到的雲遷移和容災，並非堆人提供的遷移服務，而是強調的高度自動化的手段。目標就是在遷移過程當中保證業務連續性，縮短停機時間甚至不停機的效果。這裏就藉助了容災的存儲級別同步技術來實如今異構環境下的的「熱遷移」。現有解決方案裏，既有傳統物理機搬遷時代的遷移軟件，也有基於雲原生開發的工具。但不管何種形式，都在不一樣程度上都解決了用戶上雲的基本訴求。最大的區別在於人效比，這一點與你的利益直接相關。

從另一個角度也不難發現，所謂的遷移在正式切換以前實質上就是容災的中間過程。同時，業務系統遷移到雲平臺後，災備是一個連續的動做，這裏既包含了傳統的備份和容災，還應該包含雲上高可靠的概念。這樣，用戶業務系統在上雲後，才能擺脫傳統基礎架構的負擔，作到「零運維」，真正享受到雲所帶來的的紅利。因此，我認爲在雲原生狀態下，雲遷移、雲容災、雲備份本質上就是一種業務形態，底層採用的技術手段能夠是徹底一致的。

3. 發展方向

在上述的痛點和趨勢下，必然會出現一種全新的平臺來幫助客戶解決數據的安全性和業務連續性問題，今天就從這個角度來分析一下，在雲原生的趨勢下如何構建應用系統的遷移與容災方案。

雲遷移發展趨勢

1. 雲遷移方式

遷移是一項重度的諮詢業務，網上各家雲商、MSP 都有本身的方法論，其實看下來差異都不大，以前也有不少人在分享相關話題，本文就再也不贅述。這裏咱們重點討論，在實際落地過程當中到底該採用哪一種工具，哪一種方式的效率最高。所謂雲遷移工具，就是將源端遷移至目標端，保證源端在目標端正確運行。常見的方式包括：物理機到虛擬化、虛擬化到虛擬化、物理機到雲平臺、虛擬化到雲平臺等。

這是經典的 6R 遷移理論（如今已經升級爲了 7R，多了 VMware 出來攪局），在這個圖中與真正遷移相關的其實只有 Rehosting、Replatforming、Repurchasing 和 Refactoring，可是在這 4R 中，Refactoring 明顯是一個長期的迭代過程，須要用戶和軟件開發商共同參與解決，Repurchasing 基本上與人爲從新部署沒有太大的區別。因此真正由用戶或 MSP 在短時間完成的只剩下 Rehosting 和 Replatofrming。

與上面這張經典的遷移理論相比，我更喜歡下面這張圖，這張圖更能反應一個傳統應用到雲原生成長的全過程。與上述的結論類似，咱們在真正擁抱雲的時候，路徑基本爲上述的三條：

• Lift & Shift 是 Rehost 方式的另外一種稱呼，這種方式路面最寬，寓意這條路是上雲的最短路徑，應用不須要任何改造直接上雲使用。
• Evolve 和 Go Native 都屬於較窄的路徑，寓意爲相對於 Rehost 方式，這兩條路徑所消耗的時間更久，難度更高。
• 在圖的最右側，三種形態是存在互相轉換的可能，最終演進爲完全的雲原生，寓意爲遷移並非一蹴而就，須要按部就班完成。

2. 從新託管（Rehost）方式

經常使用的從新託管方式爲冷遷移和熱遷移，冷遷移每每涉及到步驟比較繁瑣，須要大量人力投入，而且容易出錯效率低，對業務連續性有較大的影響，不適合生產系統遷移。而熱遷移方案基本都是商用化的解決方案，這裏又分爲塊級別和文件級別，再細分爲傳統方案與雲原生方案。

1）冷遷移

咱們先來看一下冷遷移的手動方案，以 VMware 到 OpenStack 爲例，最簡單的方式就是將 VMware 虛擬機文件（VMDK）經過 qemu-img 工具進行格式轉換，轉換爲 QCOW2 或者 RAW 格式，上傳至 OpenStack Glance 服務，再從新在雲平臺上進行啓動。固然這裏面須要進行 virtio 驅動注入，不然主機沒法正常在雲平臺啓動。這個過程當中最耗時的應該是虛擬機文件上傳至 OpenStack Glance 服務的過程，在咱們最先期的實踐中，一臺主機從開始遷移到啓動完成足足花了 24 小時。同時，在你遷移這段時間的數據是有增量產生的，除非你將源端關機等待遷移完成，不然，你還要將上述步驟從新來一遍。因此說這種方式真的不適合有業務連續性的生產系統進行遷移。

那若是是物理機的冷遷移方案怎麼作呢？通過咱們的最佳實踐，這裏爲你們推薦的是老牌的備份工具 CloneZilla，中文名爲再生龍。是一款很是老牌的備份軟件，經常使用於進行整機備份與恢復，與咱們常見的 Norton Ghost 原理很是類似。CloneZilla 從底層的塊級別進行復制，能夠進行整盤的備份，而且支持多種目標端，例如咱們將磁盤保存至移動硬盤，實際格式就是 RAW，你只須要重複上述的方案便可完成遷移。可是在使用 CloneZilla 過程當中，須要使用 Live CD 方式進行引導，一樣會面臨長時間業務系統中斷的問題，這也是上面咱們提到的冷遷移並不適合生產環境遷移的緣由。

2）傳統熱遷移方案

傳統的熱遷移方案基本分爲塊級別和文件級別，二者類似之處都是利用差量同步技術進行實現，即全量和增量交叉同步方式。

文件級別的熱遷移方案每每侷限性較大，並不能算真正的 ReHost 方式，由於前期須要準備於源端徹底同樣的操做系統，沒法實現整機搬遷，從操做的複雜性更大和遷移的穩定性來講都不高。咱們在 Linux 上經常使用的 Rsync 其實能夠做爲文件級別熱遷移的一種解決方案。

真正能夠實現熱遷移的方案，還要使用塊級別同步，下降對底層操做系統依賴，實現整機的搬遷效果。傳統的塊級別熱遷移方案基本上來自於傳統容災方案的變種，利用內存操做系統 WIN PE 或其餘 Live CD 實現，基本原理和過程以下圖所示。從過程當中咱們不難發現這種方式雖然在必定程度解決了遷移的目標，可是做爲將來混合雲常態化遷移需求來講，仍然有如下幾點不足：

• 因爲傳統熱遷移方案是基於物理環境構建的，因此咱們發如今整個過程當中人爲介入很是多，對於使用者的技能要求比較高
• 沒法知足雲原生時代多租戶、自服務的需求
• 安裝代理是用戶心中永遠的芥蒂
• 一比一同步方式，從成本角度來講不夠經濟
• 最好的遷移驗證方式，就是將業務系統集羣在雲端徹底恢復，可是手動驗證的方式，對遷移人力成本是再一次增長

3）雲原生熱遷移方案

正是因爲傳統遷移方案的弊端，應運而生了雲原生的熱遷移方案，這一方面的表明廠商當屬 AWS 在 2019 年以 2.5 億美金擊敗 Google Cloud 收購的以色列雲原生容災、遷移廠商 CloudEndure。

雲原生熱遷移方案是指利用塊級別差量同步技術結合雲原生 API 接口和資源實現高度自動化遷移效果，同時提供多租戶、API 接口知足混合雲租戶自服務的需求。咱們先從原理角度分析一下，爲何相對於傳統方案，雲原生的方式可以知足高度自動化、用戶自服務的用戶體驗。經過兩個方案對比，咱們不難發現雲原生方式的幾個優點：

• 利用雲原生 API 接口和資源，操做簡便，徹底取代了傳統方案大量繁瑣的人爲操做，對使用者技術要求下降，學習陡峭程度大幅度下降
• 因爲操做簡便，遷移效率提升，有效提升遷移實施的人效比
• 一對多的同步方式，大幅度下降計算資源使用，計算資源只在驗證和最終切換時使用
• 可以知足多租戶、自服務的要求
• 源端也能夠支持無代理方式，打消用戶疑慮，而且適合大規模批量遷移
• 高度自動化的驗證手段，在完成遷移切換前，可以反覆進行驗證

這是 CloudEndure 的架構圖，固然你也能夠利用 CloudEndure 實現跨區域的容災。

不過惋惜的一點是因爲被 AWS 收購，CloudEndure 目前只能支持遷移至 AWS，沒法知足國內各類雲遷移的需求。因此這裏爲你們推薦一款純國產化的遷移平臺——萬博智雲的 HyperMotion，從原理上與 CloudEndure 很是類似，同時支持了 VMware 及 OpenStack 無代理的遷移，更重要的是覆蓋了國內主流的公有云、專有云和私有云的遷移。

3. 平臺重建（Replatforming）方式

隨着雲原生提供愈來愈多的服務，下降了應用架構的複雜度，使得企業可以更專一本身的業務自己開發。可是研發側工做量的減小意味着這部分紅本被轉嫁到部署及運維環節，因此 DevOps 成爲在雲原生運用中比不可少的一個緩解，也讓企業可以更敏捷的應對業務上的複雜變化。

正如上面所提到的，用戶經過少許的改造能夠優先使用一部分雲原生服務，這種遷移方式咱們成爲平臺重建（Replatforming），目前選擇平臺重建方式的遷移，多以與用戶數據相關的服務爲主。常見的包括：數據庫服務 RDS、對象存儲服務、消息隊列服務、容器服務等。這些雲原生服務的引入，下降了用戶運維成本。可是因爲雲原生服務自身封裝很是嚴密，底層的基礎架構層對於用戶徹底不可見，因此沒法用上述 Rehost 方式進行遷移，必須採用其餘的輔助手段完成。

以關係型數據庫爲例，每一種雲幾乎都提供了遷移工具，像 AWS DMS，阿里雲的 DTS，騰訊雲的數據傳輸服務 DTS，這些雲原生工具均可以支持 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多種關係型數據庫及 NoSQL 數據庫遷移。以 MySQL 爲例，這些服務都巧妙的利用了 binlog 複製的方式，實現了數據庫的在線遷移。

再以對象存儲爲例，幾乎每一種雲都提供了本身的遷移工具，像阿里雲的 ossimport，騰訊雲 COS Migration 工具，均可以實現本地到雲端對象存儲的增量遷移。可是在實際遷移時，還應考慮成本問題，公有云的對象存儲在存儲數據上比較便宜，可是在讀出數據時是要根據網絡流量和請求次數進行收費的，這就要求咱們在設計遷移方案時，充分考慮成本因素。若是數據量過大，還能夠考慮採用離線設備方式，例如：AWS 的 Snowball，阿里雲的閃電立方等。這部分就不展開介紹，之後有機會再單獨爲你們介紹。

若是選擇平臺重建方式上雲，除了要進行必要的應用改造，還須要選擇一款適合你的遷移工具，保證數據可以平滑上雲。結合上面的 Rehost 方式遷移，可以實現業務系統的總體上雲效果。因爲涉及的服務較多，這裏爲你們提供一張遷移工具表格供你們參考。

雲原生下的容災發展趨勢

目前爲止，尚未一套平臺可以徹底知足雲原生狀態下的統一容災需求，咱們經過如下場景來分析一下，如何才能構建一套統一的容災平臺知足雲原生的需求。

1. 傳統架構

咱們以一個簡單的 Wordpress + MySQL 環境爲例，傳統下的部署環境通常是這樣架構的：

若是爲這套應用架構設計一套容災方案，能夠採用如下的方式：

1）負載均衡節點容災

負載均衡分爲硬件和軟件層面，硬件負載均衡高可靠和容災每每經過自身的解決方案實現。若是是軟件負載均衡，每每須要安裝在基礎操做系統上，而同城的容災可使用軟件高可靠的方式實現，而異地的容災每每是經過提早創建對等節點，或者乾脆採用容災軟件的塊或者文件級別容災實現。是容災切換（Failover）很重要的一個環節。

2）Web Server 的容災

Wordpress 的運行環境無非是 Apache + PHP，因爲分離了用於存放用戶上傳的文件系統，因此該節點幾乎是無狀態的，經過擴展節點便可實現高可靠，而異地容災也比較簡單，傳統的塊級別和文件級別均可以知足容災的需求。

3）共享文件系統的容災

圖中採用了 Gluster 的文件系統，因爲分佈式系統的一致性一般由內部維護，單純使用塊級別很難保證節點的一致性，因此這裏面使用文件級別容災更爲精確。

4）數據庫的容災

單純依靠存儲層面是沒法根本實現數據庫 0 丟失數據的，因此通常採用從數據庫層面實現，固然若是爲了下降成本，數據庫的容災能夠簡單的使用週期 Dump 數據庫的方式實現，固然若是對可靠性要求較高，還可使用 CDP 方式實現。

從以上的案例分析不難看出，傳統基礎架構下的容災每每以存儲爲核心，不管是磁盤陣列的存儲鏡像，仍是基於 I/O 數據塊、字節級的捕獲技術，結合網絡、數據庫和集羣的應用級別技術完成高可靠和容災體系的構建。在整個容災過程的參與者主要爲：主機、存儲、網絡和應用軟件，相對來講比較單一。因此在傳統容災方案中，如何正確解決存儲的容災也就成爲了解決問題的關鍵。

2. 混合雲容災

這應該是目前最多見的混合雲的方案，也是各大容災廠商主推的一種方式。這裏咱們至關於將雲平臺當成了一套虛擬化平臺，幾乎沒有利用雲平臺任何特性。在恢復過程當中，須要大量人爲的接入才能將業務系統恢復到可用狀態。這樣的架構並不符合雲上的最佳實踐，但的確是不少業務系統備份或遷移上雲後真實的寫照。

這樣的架構確實能解決容災的問題，可是從成本上來講很高，如今咱們來換一種方式。咱們利用了對象存儲和數據庫進行一次優化。咱們將原有存儲服務存放至對象存儲中，而使用數據傳輸服務來進行實時的數據庫複製。雲主機仍然採用傳統的塊級別進行同步。一旦出現故障，則須要自動化編排能力，從新將備份進行恢復，在最短期內根據咱們預設的方案進行恢復，完成容災。

3. 雲上同城容災架構

上述的備份方式，實質上就是利用平臺重建的方式進行的遷移，既然已經利用遷移進行了備份，那徹底能夠對架構進行以下改造，造成同城的容災架構。咱們根據雲平臺的最佳實踐，對架構進行了以下調整：

這個架構不只實現了應用級高可靠，還可以支撐必定的高併發性，用戶在最少改造代價下就可以在同城實現雙活的效果。咱們來分析一下在雲上利用了多少雲原生的服務：

• 域名解析服務
• VPC 服務
• 負載均衡服務
• 自動伸縮服務
• 雲主機服務
• 對象存儲服務
• 關係型數據庫 RDS 服務

除了雲主機外，其餘服務均是自然就支持跨可用區的高可用特性，對於雲主機咱們能夠製做鏡像方式，由自動伸縮服務負責實例的狀態。因爲雲上可用區就是同城容災的概念，這裏咱們就實現了同城的業務系統容災。

通過調整的架構在必定程度上知足了業務連續性的要求，可是對於數據的安全性仍然缺少保障。近幾年，勒索病毒橫行，大量企業爲此蒙受巨大損失，因此數據備份是上雲後必須實施的。雲原生服務自己提供了備份方案，例如雲主機的按期快照等，但每每服務比較分散，不容易統一進行管理。同時，在恢復時每每也是隻能每個服務進行恢復，若是業務系統規模較大，也會增長大量的恢復成本。雖然雲原生服務解決了自身備份問題，可是將備份從新組織成應用是須要利用自動化的編排能力實現。

4. 同雲異地容災架構

大部分的雲原生服務都在可用區內，提供了高可靠能力，可是對於跨區域上一般提供的是備份能力。例如：能夠將雲主機變爲鏡像，將鏡像複製到其餘區域內；關係型數據庫和對象存儲也具有跨域的備份能力。利用這些組件自身的備份能力，外加上雲自身資源的編排能力，咱們能夠實如今容災可用域將系統恢復至可用狀態。那如何觸發切換呢？

這裏咱們根據業務系統的特色，在雲原生的監控上定製告警，利用告警平臺的觸發能力觸發函數計算，完成業務系統的跨域切換，造成異地容災的效果。

5. 跨雲容災

但跨雲容災不像同雲容災時，在不一樣的可用區之間至少服務是一致的，那麼此時，在同雲上使用的方法基本失效，徹底須要目標雲平臺的能力或者中立的第三方的解決方案。這裏除了數據的備份，還有一點是服務配置的互相匹配。才能徹底知足跨雲容災恢復的需求。另外須要考慮的一點就是成本爲例，以對象存儲爲例，是典型的的「上雲容易下雲難」。因此如何利用雲原生資源特性合理設計容災方案是對成本的極大考驗。

總結

雲原生容災還處於早期階段，目前尚沒有完整的平臺可以支持以上各類場景的容災需求，是值得持續探索的話題。雲原生容災以備份爲核心，以遷移、恢復和高可靠爲業務場景，實現多雲之間的自由流轉，最終知足用戶的業務需求。

因此，做爲面向雲原生的容災平臺要解決好三方面的能力：

• 以數據爲核心，讓數據在多雲之間互相流轉。數據是用戶核心價值，因此不管底層基礎架構如何變化，數據備份必定是用戶的剛醒需求。對於不一樣雲原生服務如何解決好數據備份，是數據流轉的必要基礎。
• 利用雲原生編排能力，實現高度自動化，在數據基礎上構建業務場景。利用自動化編排能力實現更多的基於數據層的應用，幫助用戶完成更多的業務創新。
• 靈活運用雲原生資源特色，下降整體擁有成本。解決傳統容災投入巨大的問題，讓用戶的成本真的能像水、電同樣按需付費。