持久化存儲對容器來說真的适合嗎?

本文講的是<b>持久化存儲對容器來說真的适合嗎</b>，【編者的話】持久化存儲對于容器來說是否真的适合？本文作者主要圍繞十二要素設計模式及容器架構方面對這一話題發表了自己的見解。

盡管如此，仍然有一部分人堅持（一語雙關）為容器帶來持久化存儲的想法，尤其是塊卷這樣的事務存儲。這裡面有多重原因。某些案例裡，一個應用需要資料落地并且像對象存儲或者NFS這樣的後端可能無法滿足它的性能需求；這裡面最典型的莫過于一個像MySQL或者Postgres這樣無法設計成同NoSQL資料庫那樣向外擴充的SQL資料庫。又比如，一個正在遷移到容器及雲原生應用的企業可能希望盡可能利用現有的技術，例如一個存儲陣列。為了滿足這一需求，一些開源的解決方案也應時而生，它們是：

如果想了解這些解決方案更多的詳情，可以點選上述連結來檢視相關項目的具體文檔。

那麼針對容器的持久化存儲，我所擔憂的地方到底在哪呢？這裡面我想指出的有兩點 —— 一個是架構上的，另外一個則是行為方面。簡要起見，我會盡量保證我的論述簡明扼要。

架構——我經常說，單個容器如何跑起來并不算是一個特别有趣的問題；真正的挑戰來自于大規模下的容器管理。在隻有幾十或幾百容器的小環境裡，持久化存儲實作的糟糕架構可能并不會成為一個問題。但是一旦增長到成千上萬的容器規模時，情況就不是這樣了。當大量容器都是臨時運作并且不斷遷移或者說在新的容器主控端上重新執行個體化時，它們所依賴的持久化存儲如果是緊耦合到特定容器主控端的話将會極大地影響到整個容器架構的可擴充和彈性伸縮能力。試想一下建構一個大型雲原生應用所使用的容器主控端依賴于SAN存儲來實作持久化的場景吧；你的可擴充能力會被牢牢限制在可以連接配接到相同的SAN存儲卷的伺服器數量。又或者甚至于如果你使用像ZFS這樣的共享檔案系統來實作持久化的話，從一個容器主機移動到另一個卷所需的時間通常要比新起一個容器更久一些。這就産生了一個容器裡快速拉起一個應用的需求與挂載持久化存儲層必需的耗時兩者之間的互相沖突。

行為模式——我同樣也認為對傳統的存儲模式及解決方案的依賴恰恰正是加深了對雲原生設計的反模式。我已經看到一些這樣的案例，使用者已經将整個應用伺服器，包括他們對于傳統存儲的依賴，從虛拟機遷移到了容器，然後他們就開始納悶為什麼他們無法得到容器理應帶來的全部收益。通過提供更多的持久化存儲選擇，我們是否在将使用者引導偏離像12要素應用這樣的雲原生應用的設計模式，然後使得他們背離未來的趨勢？正如我經常說地那樣，每一個架構方案必然會附帶一些必須遵守的限制。我們不應該暗示使用者，他們可以使用舊的設計模式，然後仍然可以得到雲原生應用程式容器所能帶來的全部收益。

這裡面也許還有很多值得讨論，這裡我先告一段落……當涉及到具體技術層面時我并不是一個頑固派，并且我也不相信我們就應該抛棄所有的持久化存儲方案。我同意對于容器而言持久化存儲同樣也有一席之地的觀點，但是前提是它正确地定位到了目前出現的一些問題，并且我們願意去教導和幫助使用者去了解他們自身所處環境的限制。有時候如果一個存儲解決方案僅僅隻是“技術上”可行的話其實也就意味着對它的否定，因為它沒有遵循一個正确的設計模式。或許這也意味着所有為容器提供的持久化存儲均需遵循所謂的雲原生設計模式。最起碼，它意味着我們需要讓使用者獲悉關于這些持久化存儲解決方案的具體利弊。

我衷心地希望這篇文章可以開啟一個關于這一話題的積極讨論。如今我已經表達了我想說的，還有Clint、John、Ryan、Shamail以及其他人的見解，哪一位道出了你的心聲呢？

原文釋出時間為：2016-03-16

本文作者：colstuwjx

本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。

原文标題：持久化存儲對容器來說真的适合嗎?