容器實時遷移揭秘

主要結論

• 實時遷移是指在客戶端訪問不中斷的情況下移動應用程序實例。

• 實時遷移有助于促進服務器維護工作并緩解失衡負載等場景。

• 目前流行的實現策略包括“復制前（Pre-copy）”將狀態復制到備用主機并切換流量，以及“復制后（Post-copy）”對初始狀態進行復制并將殘余組件置于“惰性加載（Lazy loaded）”狀態下。

• 實時遷移面臨的挑戰包括：遷移過程中性能略微退化，如果依賴的服務（例如大數據或其他專有服務）在備用位置不可用將難以在主機間移動。

本文介紹了一個目前IT界尚未全面考慮過的問題：容器的實時遷移。這種技術的工作原理如何，能解決哪些問題？由于能為應用程序生命周期管理提供更大靈活性，塑造更豐富的使用場景，業界對這一技術的需求已經有了顯著提升。

實時遷移到底是什么？

容器實時遷移是指在確保客戶端訪問不中斷的情況下在不同的物理計算機或云平臺之間移動應用程序的過程。在裸機硬件基礎上運行容器所需的內存、文件系統，以及網絡連接都可以從源主機轉移至目標主機，同時可以確保狀態持續不中斷。

實時遷移可以解決的問題

實時遷移技術可以解決多種問題：

• 硬件維護期間的停機。 當系統管理員需要升級硬件時，將所有客戶從一個硬件節點移動至另一個硬件節點的過程極為痛苦，很多時候甚至不可能在不停機的情況下實現。
• 失衡的集群負載。 當一個硬件節點開始過載，再平衡過程可能需要執行特定的應用程序模式以縮小可在集群中運行的工作負載的選擇范圍。
• 云平臺故障。 目前市面上有很多云平臺，有時候這些云平臺也會停機，更改定價策略，或服務質量退化。大部分情況下如何輕松地將應用程序從一個云供應商遷移至另一個供應商，這是個很大的問題。

備選解決方案

上述問題可通過多種方式解決。一起分析一下人們是如何使用實時遷移之外的其他方式解決這些問題的。

• 計劃內停機。 為了對集群進行維護，應用程序的所有者可以提前公布維護窗口和可能的停機，隨后關閉硬件并等待所有變動均已完成后重新開機。這種方式的問題在于停機時間會非常長。

• 流量重路由。 為了進行維護，可將每個應用程序的副本還原至另一個硬件節點，隨后將流量重路由至新的副本，并將原先的副本關閉。這種方式的問題在于復雜性：應用程序必須明確針對這種情況進行設計才能實現高可用性和數據同步。此外這種方式需要使用更多的硬件資源。

• 微服務。 將應用程序服務進一步細分至多個容器，并將容器分散保存在不同的物理服務器上，以避免硬件故障導致的停機。受影響的容器可以在活躍硬件節點上自動還原。然而這種方式的問題依然是復雜性，因為集群中的應用程序必須經過恰當的設計才能實現高可用并能在故障后還原。

實時遷移的工作原理

一起使用下面的結構看看實時遷移過程在技術上是如何實現的。

• 源節點 - 實時遷移前容器所在位置

• 目標節點 - 實時遷移后容器所在位置

為了執行實時遷移，平臺首先需要將源節點的容器凍結，阻止內存、進程、文件系統，以及網絡連接，并獲得該容器的狀態。隨后將這些內容復制到目標節點。平臺會在目標節點上還原狀態并解凍容器，并在源節點執行一個快速的清理過程。

整個過程相當直觀：獲取狀態，復制狀態，還原狀態。然而要注意，容器會在一段時間內處于凍結狀態，因此在設計應用程序體系結構時需要考慮到這一問題，這一特點有可能讓某些應用程序出現問題。

實時遷移解決方案有兩種類型。其一是 復制前內存（Pre-copy memory） 。如果要遷移容器，平臺會開始追蹤源節點的內存使用，并將內存并行復制到目標節點，直到兩個節點的內存差異實現最小化。隨后平臺會凍結容器，獲取剩余的狀態數據，將其遷移至目標節點，還原并解凍容器。

另一種解決方案是 復制后內存（Post-copy memory） ，也可以叫做 惰性遷移（Lazy migration） 。系統會在一開始凍結源節點中的容器，從飛速變化的內存頁中獲取狀態，將狀態移動至目標節點并還原，然后解凍容器。隨后用后臺模式將剩余狀態信息從源節點復制到目標節點。

取決于具體應用程序，通常每個容器需要凍結5-30秒。相比集群維護過程中長達數小時的停機，這個時間已經很短了。

實時遷移的用例

不停機硬件維護

在維護窗口中，容器可以用實時模式從一臺物理硬件節點遷移至統一數據中心內的另一個節點，這一過程完全不造成停機。

負載平衡

通過實時遷移將容器從一個硬件節點遷移到另一個，借此實現負載平衡。通過實現相應的調度算法和觸發器，這一切甚至可以自動完成。

同一硬件區域和數據中心內的高可用性

云服務供應商可以在一個或多個數據中心內預配置并提供一系列硬件可用性區域，因此最終用戶可以在無需系統管理員介入的情況下執行容器的實時遷移，借此獲得更多高可用性選項。

更換云供應商

實時遷移還可以幫助最終用戶避免云基礎結構供應商的鎖定。應用程序可以遷移至另一個云服務供應商處，遷移過程中無需任何重配置或重部署操作。

瓶頸和潛在問題

如果想要通過實時遷移解決方案解決上述問題，還需要考慮到可能面臨的各種挑戰：

• 實時遷移過程中，容器凍結后可能會產生性能退化。對于某些可能無法接受任何性能退化（例如高負載的整體式實時應用程序）的應用程序來說這是個大問題。但是對于互聯網上的大部分應用程序，尤其是Web應用程序，短時間內的凍結還是可以接受的。
• 另一個挑戰與大數據和因為快速變化而無法在不同云供應商之間輕松移動的數據有關。網絡延遲和數據量可能是成功實現實時遷移的最大障礙。
• 多云環境內的公有IP。使用公有IP地址的容器無法在不同云供應商之間遷移，因為IP地址只能留在各供應商自己的網絡內。
• 如果容器內的應用程序使用了原生API或特定云服務供應商的原生云服務，跨云進行的實時遷移可能難以實現甚至完全不可行。

市面上的實時遷移產品

目前哪些公司提供了實時遷移產品？現在已經有多個產品可以對容器進行實時遷移。

• Virtuozzo – 正是該團隊為容器開發了實時遷移技術，他們是這一領域的先鋒，目前已經提供了可用于生產環境，包含實時遷移功能的容器引擎。

• runC ，源自Open Containers Initiative，是另一個即將包含基于 CRIU 的實時遷移功能的容器引擎解決方案。

• Jelastic 提供的容器編排平臺為生產應用程序提供了跨越硬件區域、數據中心，以及云供應商進行實時遷移的功能。

演示：用實時模式遷移Minecraft

下列視頻演示了使用實時模式將Minecraft應用程序從AWS不停機遷移至Azure的過程。

容器的實時遷移目前依然是一項比較新的技術。然而對企業來說這種技術的收益是顯而易見的：不停機維護，無需花費大量時間對一切進行準備、確認，以及再次確認。因此這種解決方案是改善可用性，獲得更高靈活性的好方法。如果你對于通過實時模式將容器從一個實例跨越數據中心移動到另一個實例有自己的經驗，歡迎與我們一起分享。

 

來自：http://www.infoq.com/cn/articles/container-live-migration