IT領域，變革的速度令人瞠舌。快速增長的數據，云計算規模的處理，以及***的物聯網設備正在推動我們向著更高效、可靠和可擴展的方向發展。傳統的應用架構已日趨極限，我們正試圖努力開發部署***的新方案。所幸的是，最被看好的容器化技術——這項據稱能夠解決許多問題的技術（如果不能算是全部的話）——正成為應對上述難題的妙藥良方。

在容器化應用程序設計中，每個容器間彼此隔離，獨立擴展，并可作為處理某項大型網絡應用的組件。有別于以往處理整個應用程序，大型的容器化應用程序可由數百個（甚至上千個）相關容器組合而成。這些應用程序支持敏捷設計、開發和部署方式。它們可以在生產環境中輕松擴展，非常適合于分布式、甚至基于云的混合式基礎架構。

[[204337]]

遺憾的是，容器在最初設計中并非用于實現全堆棧應用程序，亦不適合需要長期儲存數據的應用。容器的設計初衷是可以輕易地大規模創建、部署微服務的應用層，并將微服務視為一種高度敏捷的中間件，在概念上無需持久的存儲數據。

持之以恒

由于容器方式具有很強的靈活性、易于擴展、高效性，并面向云計算，在許多情況下這都是一種經濟的部署模式，因此現在人們希望將其應用范圍擴展到微服務之外。容器架構提供了更好的方式來構建現代化的應用程序，我們看到許多商業軟件和系統供應商在內部開發中轉向容器形式，甚至將其廣泛部署，而且通常在上層保持對最終用戶和IT管理人員的透明。大多數名列財富100強的企業已經開始以容器形式進行生產環境的第三方IT應用托管，尤其在內部應用、融合架構和專用的基礎架構領域。

你或許會看到大型的、容器化的數據庫，甚至存儲系統的出現。然而，設計企業級的、長期存儲數據的應用程序仍是不小的挑戰，容器可能在分布式和混合基礎架構中來回遷移。而數據需要控制、保護、受到管制和監督，所以很多時候持續數據存儲需要更像是錨點那樣，容器在這方面著實面臨著短板。

容器架構使用到三種類型的存儲：***是鏡像存儲。這可以利用現有的共享存儲進行交付，要求類似于服務器虛擬化環境中虛擬機鏡像分發保護的平臺架構。容器鏡像的一項好處在于其存儲容量相較于完整的虛擬機鏡像小了許多，因為它們不會復制操作系統代碼。此外，容器鏡像的運行在設計之初便是固定的，因此可以更高效地存儲、共享。但也因此，容器鏡像無法存儲動態應用程序的數據。

第二類需要存儲的數據是容器的管理。當然，你同樣可以借助現有存儲完成這項工作。不論使用Docker、Kubernetes、Tectonic、Rancher還是其它類型的容器管理，都需要存儲配置數據、日志記錄等管理數據。

還有第三類存儲，容器應用的存儲，是***挑戰的。只有支持真正的微服務式編程時，容器代碼可以直接寫入鏡像目錄和文件。但是容器使用一種分層文件系統，將所有新寫入的數據存儲在臨時虛擬層，***層的容器鏡像卻未被修改。一旦容器消失——相比虛擬機，容器的設計壽命更短——所有的臨時存儲都會隨之消散。

假如一個容器應用程序需要保存數據，一種方式是顯示地在容器的全局命名空間內加載一個特定的系統數據卷——或在Kubernetes框架下的持久卷這樣可以讓容器直接方案讀/寫主機目錄或文件系統。假如容器被關閉或重新啟動，它依舊可以訪問之前寫入的，用于長期存放的數據。但這并不是一個簡單易行的方式，需要考慮在容器之間共享數據，因此應用程序開發人員必須兼顧共享、鎖定、爭用和重啟的問題。而且存儲管理員如何甄別保護——快照、備份和災難恢復產生的——成千上萬由程序控制的海量數據。

此外，假如容器集群中的某一個容器位于另一臺主機，那么存儲管理員需要確保共享或分布式文件系統（例如NFS）在所有的集群主機上均保持同樣的配置，甚至應用程序員可能要添加更多與I/O相關的代碼，從而確保可靠的集群級別的共享。所幸的是，專家級的存儲管理員會選擇將現有的企業級存儲（如NAS和SAN）帶入這個全新的容器領域。如果他們與開發人員緊密合作，可以實際配置出高端的企業級生產環境。

不過，容器領域內的***實踐是讓Agile DevOps具備相同的沙箱、測試與生產環境。從容器角度看，這種方式為最終用戶提供動態配置，從而確保容器的移動和遷移。系統的存儲配置越是靜態和脆弱，容器化的好處便越是難以體現。

Docker等容器管理產品提供可插拔的卷管理。例如Flocker是開源Docker可插拔卷中的***的替代品，可以通過集群智能管理、遷移數據卷及其容器。雖然Flocker的主要贊助商ClusterHQ已不復存在，但我們預計這種功能將持續發展，并在基準容器平臺內變得日益本土化；Rancher Labs的“Convoy”項目正朝著這個方向發展。大多數（如果不說全部的話）傳統存儲供應商和云存儲服務提供商為其存儲陣列生成各類容器系統卷插件，這不失為在存儲上持續投資的好方法。

存儲即軟件

相較于嘗試將舊版存儲強制遷移到新的容器環境中，不斷增長的替代方案會引發新一波的軟件定義存儲（SDS）風潮來完成這項工作。SDS由一個存儲操作系統和完全部署為軟件層的服務構成，該服務層通常作為虛擬機呈現，不過現在其越來越多地部署為容器模式。容器化軟件存儲的快速發展是很容易想見得到的，以便于容器化應用程序使用存儲服務。

相比在傳統的生產環境中，服務器虛擬化環境通常基于大型而昂貴的主機集群，容器的托管體系架構能夠輕松使用由更開放的、廣泛而廉價的通用服務器組建起的私有、公有或混合云基礎架構。這有些類似于Hadoop和Spark等大數據項目使用通用基礎架構的優勢，并且通過使用SDS和內存來講我們從專用而昂貴的平臺中釋放出來。

SDS的另一項核心優勢特別針對Ceph，Torus和GlusterFS等分布式容器方案，將存儲以最適合的方式交付給容器集群。管理諸如GlusterFS之類的技術對傳統的SAN管理員而言可謂是一項挑戰，但容器化存儲與身居來具有各種諸如敏捷性、可擴展性和可用性方面的優勢，同時通過本地化數據存儲改善應用程序性能。

簡而言之，預融合和超融合容器設備使得內置本地容器存儲功能（如Datera和Diamanti）變得更加簡單。通過使用SDS來得到在同一平臺設備格式下融合萬物所需的靈活性和便捷性。雖然我們尚未有聽到有企業真正在生產環境中使用融合容器托管方式，但未來的IT基礎架構必將延續融合道路，同時建立更多云端服務。

當然，IT人員的工作在于判斷是否為某家供應商專有的技術買單，或是轉向免費的開源代碼，加以投資，并封閉在該領域。假如要得到經過預先集成、驗證的企業級功能和全天候的技術支持，通常需要長期選定某家供應商的開源分發或預融合的堆棧。換句話說，這不僅是選擇傳統的哪家供應商，更是選擇供應商專有還是開源的技術，或是完全依賴自己的開發。

云端擴展的對象存儲

容器化應用程序往往采取云計算架構，其體系架構要根據外部工作負載情況的變化、增長而持續擴展內部的服務。這種基于云的理念同樣滲透到現代應用程序開發人員調用存儲的方式。許多新的容器化應用程序是針對對象存儲的I / O，而非傳統的文件系統或數據塊編寫的。

大多數當前的容器環境在現實部署中平穩進行——當然在公有云中可謂例外，來自Hedvig、Qumulo和Scality等在線擴展對象存儲恰好滿足容器所需。在實施或遷移容器應用程序時，Amazon Web Services Simple Storage Service (S3)和類似的公有云已經開始將對象存儲用作持久的存儲層。

面向未來

我們尚未看到容器最終在***數據存儲方面會有怎樣的表現。根據過去存儲領域的發展演進經驗來看，我們可能會看到“容器認知”存儲的出現，其為容器配置而生，并配以適合的管理功能。就像虛擬機認知存儲一樣，我們應該還可以看到一項容器存儲服務，可以保持數據并持續追溯——甚至在跨集群容器和跨云容器環境中。最終，我們期待看到使用服務器閃存和新興的持續性閃存（如非易失性存儲器快照）的容器認知緩存，并且和持續存儲層相結合。

希望未來的容器認知存儲可以兼顧到所有關鍵的方面，從容器清單到應用藍圖。我們同樣希望在未來完成多容器環境的存儲管理，可以追溯、預測和優化存儲訂閱，以滿足持續容器運作所需。另外，存儲認知的存儲需要能通過簡單的策略機制，隨時隨地地保護到所有數據、確保高可用性和災難恢復。

以虛擬機形式呈現的服務器虛擬化花費了超過10年才替代掉企業數據中心中應用程序專用的物理服務器。現在，容器化應用程序似乎將會在一兩年內替換許多完整的虛擬機應用。***挑戰在于我們能否為容器快速提供企業級持續性數據存儲。