IT領(lǐng)域，變革的速度令人瞠舌?？焖僭鲩L的數(shù)據(jù)，云計算規(guī)模的處理，以及***的物聯(lián)網(wǎng)設(shè)備正在推動我們向著更高效、可靠和可擴(kuò)展的方向發(fā)展。傳統(tǒng)的應(yīng)用架構(gòu)已日趨極限，我們正試圖努力開發(fā)部署***的新方案。所幸的是，最被看好的容器化技術(shù)——這項據(jù)稱能夠解決許多問題的技術(shù)（如果不能算是全部的話）——正成為應(yīng)對上述難題的妙藥良方。

在容器化應(yīng)用程序設(shè)計中，每個容器間彼此隔離，獨(dú)立擴(kuò)展，并可作為處理某項大型網(wǎng)絡(luò)應(yīng)用的組件。有別于以往處理整個應(yīng)用程序，大型的容器化應(yīng)用程序可由數(shù)百個（甚至上千個）相關(guān)容器組合而成。這些應(yīng)用程序支持敏捷設(shè)計、開發(fā)和部署方式。它們可以在生產(chǎn)環(huán)境中輕松擴(kuò)展，非常適合于分布式、甚至基于云的混合式基礎(chǔ)架構(gòu)。

[[204337]]

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

持之以恒

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

你或許會看到大型的、容器化的數(shù)據(jù)庫，甚至存儲系統(tǒng)的出現(xiàn)。然而，設(shè)計企業(yè)級的、長期存儲數(shù)據(jù)的應(yīng)用程序仍是不小的挑戰(zhàn)，容器可能在分布式和混合基礎(chǔ)架構(gòu)中來回遷移。而數(shù)據(jù)需要控制、保護(hù)、受到管制和監(jiān)督，所以很多時候持續(xù)數(shù)據(jù)存儲需要更像是錨點(diǎn)那樣，容器在這方面著實(shí)面臨著短板。

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

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

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

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

此外，假如容器集群中的某一個容器位于另一臺主機(jī)，那么存儲管理員需要確保共享或分布式文件系統(tǒng)（例如NFS）在所有的集群主機(jī)上均保持同樣的配置，甚至應(yīng)用程序員可能要添加更多與I/O相關(guān)的代碼，從而確?？煽康募杭墑e的共享。所幸的是，專家級的存儲管理員會選擇將現(xiàn)有的企業(yè)級存儲（如NAS和SAN）帶入這個全新的容器領(lǐng)域。如果他們與開發(fā)人員緊密合作，可以實(shí)際配置出高端的企業(yè)級生產(chǎn)環(huán)境。

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

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

存儲即軟件

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

相比在傳統(tǒng)的生產(chǎn)環(huán)境中，服務(wù)器虛擬化環(huán)境通?；诖笮投嘿F的主機(jī)集群，容器的托管體系架構(gòu)能夠輕松使用由更開放的、廣泛而廉價的通用服務(wù)器組建起的私有、公有或混合云基礎(chǔ)架構(gòu)。這有些類似于Hadoop和Spark等大數(shù)據(jù)項目使用通用基礎(chǔ)架構(gòu)的優(yōu)勢，并且通過使用SDS和內(nèi)存來講我們從專用而昂貴的平臺中釋放出來。

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

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

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

云端擴(kuò)展的對象存儲

容器化應(yīng)用程序往往采取云計算架構(gòu)，其體系架構(gòu)要根據(jù)外部工作負(fù)載情況的變化、增長而持續(xù)擴(kuò)展內(nèi)部的服務(wù)。這種基于云的理念同樣滲透到現(xiàn)代應(yīng)用程序開發(fā)人員調(diào)用存儲的方式。許多新的容器化應(yīng)用程序是針對對象存儲的I / O，而非傳統(tǒng)的文件系統(tǒng)或數(shù)據(jù)塊編寫的。

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

面向未來

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

希望未來的容器認(rèn)知存儲可以兼顧到所有關(guān)鍵的方面，從容器清單到應(yīng)用藍(lán)圖。我們同樣希望在未來完成多容器環(huán)境的存儲管理，可以追溯、預(yù)測和優(yōu)化存儲訂閱，以滿足持續(xù)容器運(yùn)作所需。另外，存儲認(rèn)知的存儲需要能通過簡單的策略機(jī)制，隨時隨地地保護(hù)到所有數(shù)據(jù)、確保高可用性和災(zāi)難恢復(fù)。

以虛擬機(jī)形式呈現(xiàn)的服務(wù)器虛擬化花費(fèi)了超過10年才替代掉企業(yè)數(shù)據(jù)中心中應(yīng)用程序?qū)Ｓ玫奈锢矸?wù)器?，F(xiàn)在，容器化應(yīng)用程序似乎將會在一兩年內(nèi)替換許多完整的虛擬機(jī)應(yīng)用。***挑戰(zhàn)在于我們能否為容器快速提供企業(yè)級持續(xù)性數(shù)據(jù)存儲。