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

作者 | 孫琦

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

趨勢

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. 跨雲容災

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

總結

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

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

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