容器技術是最快被數據中心所廣泛接受和采用的技術之一，從2013年起，據統計Docker的下載量已經快達到30億次，容器已經徹底改變了應用部署方式，但是IT基礎設施的管理卻沒有及時跟上。

今天我們就談談容器技術在存儲中的應用，除了EMC Unity統一存儲采用容器實現NAS、復制等增值特性之外，目前已經有初創存儲廠商推出容器定義存儲（CDS）產品，由于內容太長，所以打算分上下兩期來講。第一講主要介紹容器如何改變應用部署方式、為什么要通過CDS實現數據中心“輕量化”。下一講將介紹一個CDS產品和公司（Portworx），希望分享的一些觀點和趨勢能對我們國產存儲的發展帶來一些啟示。Portworx是一家美國存儲初創公司，它研發了業界第一個容器定義存儲系統，基于容器構建，采用容器控制面和數據面實現，致力于為應用容器提供企業級特性、完全媲美裸金屬性能的存儲系統。

目前SDS和SBS存儲產品，使得我們很容易從喜歡的商業服務器獲取存儲容量和服務，硬件節點可以同時提供計算資源和存儲資源（融合架構），融合了計算和存儲能力。但這些存儲方案缺少一個全新設計的軟件架構，用來部署應用軟件和容器，充分利用服務器計算的商品化和微服務化趨勢。

就拿傳統專業存儲為例，管理和運維需要非常專業的技能，需要了解FC，SAN交換機，iSCSI，NFS和CIFS，FCoE等專業知識，如果你想得到企業級存儲服務，就必須了解專業存儲每個技術和配置細節。

看了這張圖片，這一切顯得的多么復雜和古老。如果你想建立一個敏捷的數據存儲，這或許不是你想看到的畫面。回想一下，今天我們是否可以在一個2U外形類似服務器上部署類似存儲系統。谷歌、Facebook和其他大型數據中心作為現代數據中心架構的領頭羊，已經有團隊用專業的技能來建立一個分布式的容錯存儲系統，利用x86架構的計算和存儲。我們看到的只是一堆物理基礎設施，通過Scale out x86服務器提供非常易用的存儲服務。

隨著現代數據中心的發展，新的應用形態（Cloud-native、DevOps、Micro Service等）都要求基于云平臺構建（Cloud-native），這對存儲體系結構又有了新的要求，這些要求主要體現在以下幾個方面。

面向服務的存儲配置： 過去基于一個物理服務器或虛擬機配置存儲卷的技術、依賴于FCoE、iSCSI等協議的技術已經落后了。

卷服務粒度更細、數量更多： 在最現代化的服務模型中，如NoSQL和消息隊列，通常被設計成大規模擴展方式。他們部署時需要存儲支持更多卷數量、更小的卷容量。而不像過去，一個計算節點通常映射一個大容量卷來提供數據庫等應用。

存儲本地多層化： 目前服務器至少有兩個存儲層級。基于全球客戶服務器采購的實際情況來看，數據中心的服務器來自不同的供應商的多種服務器，不同服務器具有不同的內部容量層。客戶希望新的存儲結構來理解這些變化和不同，并能自動利用不同存儲提供存儲服務。

存儲超融合化： 新服務架構要求數據計算和存儲融合。以Hadoop為例，在計算是派遣到服務節點上運行的主機數據。

多服務顆粒存儲操作： 新型應用程序不是單一的堆棧。而是通過部署在多個節點上的分布式模塊進行業務交互組成。企業存儲的操作，如快照、檢查點還原、復制、配額等，需要提供服務堆棧級別上的支持。所以，我們的存儲系統需要能意識到一組分布式x86服務器通過以太網織物綁在一起。

在數據中心中，硬件結構的現狀一般是，來自不同供應商的服務器各自為政，不同存儲容量和不同類型的服務器并存，Top of Rack交換機的能力也不同，而運行其上的軟件是以一個更高的粒度，通過松耦的一組容器化服務運行在不同節點上。那么，我們該如何擴展存儲層來與大量相對較薄的服務一起工作呢，當然，常用的做法就是將堆棧拆分成獨立的數據可用區和計算區，根據不同SAL的應用需求匹配相應的存儲資源。

實質上，上圖就是一個容器感知存儲架構，該架構要實現如何根據存儲需求將數據放置在容器的位置區。這種架構可以支撐一個更大的容器計算集群，同時可以保持存儲的性能和時延要求。

面對更細粒度的、自恢復和可發現的面向服務的應用架構，存儲也不應該有任何核心的集中元數據服務器，元數據應該分布式存放和去中心化存放，并通過負載均衡等算法或檢測協議（Gossip Protocol）實現高效的故障自愈系統和高可靠系統。

Gossip Protocol的通信方式類似流言傳播，每個節點狀態的變化和更新，立即通過一傳十，十傳百的方式在集群內廣播，而不是由某幾個節點逐一傳遞，所以通信效率非常高效。

為了讓存儲能感知容器，存儲調度也需和容器引擎集成，隨著應用軟件向更為面向服務的體系結構演進，應用軟件的業務流程和調度也發生了變化。我們不再需要手動管理進程，而是自動實現軟件的啟動、停止和生命周期管理，對軟件的運行和SLA需求也要實現自動化。這就要現代流行的調度器來完成，如Mesosphere，Kubernetes，Swarm，Spark等。

新的應用架構都是深度集成這些容器調度器，DevOps開發團隊的工作也是基于容器調度器和編排工具進行，所以，對軟件定義存儲，容器定義存儲等基層設施層來說，就可以直接跟這些調度或業務編排層實現集成。這對數據中心實現“輕量化”來說，也變得比較迫切。

容器在單個操作系統運行多個應用，由于它的輕量特性也給應用部署帶來很多優勢，如占用資源少、啟動快、容易部署等，其高效率也意味著數據中心需要較少的硬件和物理空間開銷，Docker也是因為開源和強大生態而被全球范圍內的企業擁抱。但是容器的應用還是局限在公有云、網站、無狀態的應用，還沒有大規模進入到數據中心主要業務。一個主要原因是現有容器是基于無狀態業務進行優化，到目前為止，還沒有健壯和易管理的方法存放有狀態的數據，這也跟容器每次訪問完后就終止進程的架構有關。

分布式擴展存儲架構在設計時，就需要考慮如何以面向服務的數據中心提供不同的存儲類型。 面對服務訪問所需的多進程、多volume、高吞吐量等訴求時，存儲需要從許多運行在不同機器的節點，提供一致的存儲服務訪問。有時這些容器甚至運行在云上或其他數據中心。面向服務的應用類型包括了：

無狀態服務： 這些通常是短暫的計算作業，他們依靠一些其他狀態的服務實現具體業務。

狀態數據庫服務： 這些通常需要塊存儲或非共享存儲訪問。

有狀態的服務需要的文件或對象訪問： 常見的有全局文件或對象的命名空間。

然而，在云計算高度發展今天，新型應用基本上基于Docker等云基礎設施構建的Cloud-native應用，而不是從傳統物理設施上遷移到云平臺的Cloud-based業務。Cloud-native大多采用Micro Service或容器部署，就要求與之相匹配的存儲提供存儲服務。

為了推進“輕量級”下一代數據中心架構，并充分利用容器技術的特點，數據中心也在面臨一場變革，需要替換原來臃腫的架構和基礎設施，采用容器架構和容器存儲技術來支持業務系統。今天就介紹到這里，下篇我們重點介紹基于容器Portworx存儲、一個基于數據和控制面的容器定義存儲技術和產品。