目前以Docker為代表的容器技術取得了快速的發展，在數據中心、公有云、私有云等領域開始被廣泛支持。基于容器技術可以做到系統持續部署與測試，消除了線上線下的環境差異，實現了高效的資源隔離和資源控制，簡化了系統的管理、調度和運維。而軟件定義存儲是基于通用的服務器，具有極好的橫向擴展能力，已經成為下一代基礎設施建設的主流選擇。我們知道容器應用需要有持久化存儲的支持，但是換個角度來看，存儲技術的容器化是否同樣有價值？又該如何去考慮、如何去實踐？

一、存儲是否有必要容器化

我們知道存儲系統是直接管理服務器上硬盤相關的資源，通常是直接運行在物理機上。但是，對于軟件定義存儲系統，如果把相關存儲服務封裝到容器中，大家最關心的問題就是是否有性能損耗，如果有，這個損耗是否可以承受？存儲系統的測試本身是一個復雜的問題，也超出了本文的討論范圍。但是，從我們的驗證和測試來看，如果Docker容器采用net=host網絡以及privileged的權限，那么由于增加了容器網絡層所帶來的性能損耗很低，幾乎可以忽略（從實際測試來看，屬于誤差范圍內的差別）。而且，業內有關Docker容器本身的相關性能測試也同樣驗證了這一點。

因此，我們可以認為在一般的應用場景下是可以對分布式存儲系統提供容器化運行、調度和管理。這樣對于非云平臺場景，容器化的存儲系統能夠帶來的是管理和運維的便利性；而對于OpenStack/Kubernetes等平臺通過對底層存儲的容器化支持，形成一種云原生存儲，這樣存儲服務可以作為云平臺的系統服務之一，并具有更好的超融合特性。

二、存儲容器化的主要工作

對于通常的軟件定義存儲，如典型的Ceph系統，直接把相關服務封裝到Docker容器中，并下載鏡像到相關的服務器節點上，啟動實例運行，這樣單純的使用帶來的好處和便利性還是比較有限。

容器化的存儲系統需要對不同的存儲模塊，進行合理的服務抽象，還需要提供相關的部署、管理和監控工具等，只有形成完整的產品化過程后，才能給客戶帶來更大的價值和便利性。

以Ceph系統為例，基于卓盛云科技的技術實踐，存儲容器化的改造主要結構及相關模塊如下：

 

1. 存儲服務的容器鏡像制作

Ceph系統是由多個服務組成的，包括mon,mgr,mds,osd,rgw等，考慮到還需要增加監控等多種輔助模塊，這樣一套完整系統包含的服務類型肯定有多種。那么就需要對各個存儲服務進行抽象，建立好相關的依賴性，形成多個獨立的最小容器鏡像。按照微服務的理念，每個鏡像都應該盡量簡單，提供一種輕量化的服務，形成瘦的鏡像模板。但是瘦鏡像必然帶來較多的鏡像種類和鏡像版本，同樣鏡像及其鏡像版本的管理復雜度會有所增加，兩方面需要一定的平衡。如下是主要的服務抽象，相關的鏡像模板需要支持這些類型服務。

2. 存儲服務的鏡像倉庫系統

在實際使用中，所有的容器鏡像一定是放到私有的倉庫中，進行統一的倉庫管理和軟件版本管理。

3. 基礎服務與輔助服務

上圖中可以看到，Ceph自身的服務，mon,mgr,osd,mds,rgw等是核心，但是單純的這些服務在生產環境中完全還不夠。鏡像倉庫自身就是一個容器，etcd作為共享配置庫解決了所有容器實例之間的配置信息和集群信息的數據傳遞。時間同步服務、監控服務、負載均衡服務、各種客戶端服務都需要容器化才基本完整。而且最核心的管理模塊“容器化部署、運維管理系統”自身也可以運行在一個容器實例中，最終可以實現一個完整的全容器化分布式存儲系統。

4. 容器化部署、運維管理系統

作為容器化存儲系統，管理好各種相關存儲服務的容器實例是系統的關鍵與核心。但是為了管理一套存儲系統，再額外采用Kubernetes之類的容器云管理平臺顯然是不可能，也是不合理的，這將極大增加系統的復雜度。當然在對于本來就需要部署K8S的環境下，可以把上面的存儲服務直接部署在K8S平臺上，成為一個云原生存儲服務。Rook是一款運行在Kubernetes集群中的Ceph存儲服務編排工具，但是目前還沒有達到成熟可用的階段。

因此，在通常的容器化存儲系統中，需要基于Ceph的特點以及普通用戶的使用要求，開發一款有針對性的簡單、輕量化的存儲容器管理和運維系統。比如存儲服務可靠性非常重要，這樣大部分服務不應該支持容器的動態遷移，但是在硬件故障和負載過于不均衡時，又需要支持人工遷移；OSD服務需要支持硬盤拔插到不同物理機上的遷移；容器資源的分配上也一般不應該支持動態資源調整，但是需要支持人工調整。但是對于一些輔助服務（如監控服務、NTP服務等）卻可以支持容器的動態遷移和資源的動態調整。所以，這種容器管理系統需要根據不同存儲服務的特點，考慮好服務的相互依賴性和先后次序，解決升級和回滾、監控的自動關聯、容器資源的分配和控制、共享配置的獲取方式、以及故障處理等問題。

最終用戶的日常管理直接在容器管理系統中進行操作，而不需要單獨訪問各個服務器和容器，可以明顯簡化的系統管理和運維的工作量。

5. 平臺插件

在超融合場景下，同一臺物理機即需要運行存儲服務，也需要運行OpenStack/Zstack等云計算平臺的服務，同時運行業務應用的虛擬機或應用容器。這幾者之間會存在互相影響和搶占資源，雖然可以基于Linux的Cgroups來限制各自的資源。但是Cgroups的管理配置顯然不夠方便。Ceph天生能夠很好的支持OpenStack和Kerbenetes系統。但是容器化后的Ceph存儲系統基于Docker的資源配置能夠具有更好的實現資源控制以及超融合的支持，避免云平臺和存儲服務之間的沖突。同時，如果容器化存儲運行在Kerbenetes上，使得存儲管理可以成為Kerbenetes平臺的一個基本服務，能夠避免了存儲與Kerbenetes的分離。下圖給出了一種Ceph運行在Pod中，并通過每個節點上的Ceph Client Pod為應用Pod提供存儲卷服務。

 

6. 存儲集群的監控和容器的監控

在正常的Ceph集群監控中，一般通過ceph命令或者相關API獲得集群狀態，但是在集群負載較高時，這個操作仍然是一個占用資源較多的操作，數據采樣的頻率不能太快。而基于容器狀態的數據采集，卻輕量化了很多，可以快速獲得容器狀態，也能夠提供高頻采樣。因此結合集群狀態的監控和容器狀態的監控，可以達到高效的監控手段。

三、存儲容器化后帶來的價值

容器化的存儲本身并不能替代Ceph等分布式存儲的自身工作，但是我們認為容器化的存儲系統給客戶帶來的主要價值包括以下幾點。

1.保證運行環境的一致性，避免軟件兼容性問題。實際物理機上的OS很多時候未必能夠由軟件定義存儲的廠商自己提供，比如超融合場景、國產服務器上的移植。但是如果這些系統能夠支持Docker容器技術，那么容器化后的存儲系統是基于自身鏡像內容來運行的，保證了開發環境、測試環境和生產環境的一致性，也就不需要在特別考慮軟件兼容性問題。

2.更好的超融合支持。基于Docker容器的資源隔離和資源限制能夠更好的滿足存儲、計算和網絡的融合。

3.配置和調優的一致性。采用etcd之類的共享配置庫，可以對Ceph的配置內容提供統一的保存點，容器重啟后可以自動更新相關配置。這樣，系統配置的修改只需要集中處理即可，系統的配置修改或者調優比較簡單方便。

4.基于容器領域的生態環境，實現監控及服務功能的多樣性。在生產環境下，相關的系統監控、統一的日志查詢分析等都是需要，這些功能如果都基于Docker進行構建，一般會更加容易，且一致性較好。同時，通過監控容器的運行狀態，很多時候比監控某個服務本身更加簡單、高效。

5.滿足云原生存儲的應用需求。可以實現存儲服務與云平臺或Kubernetes平臺的整合，融合為云原生存儲，使得底層存儲系統的管理成為OpenStack/Kubernetes平臺的基礎服務之一，讓云平臺系統更加完整。

 

      綜上所述基于容器技術構建分布式存儲系統，并以容器為管理顆粒度進行系統管理、調度和運維，能夠使整個系統更容易具有自動化、智能化和簡單化的特征,在使用上變得更加簡單易用。此外通過與OpenStack或者Kubernetes等平臺進行超融合的整合，可以實現把底層存儲系統的管理納入為云平臺和容器平臺的基礎服務之一。