近年來，容器技術和雲原生應用越來越多地佔據企業級市場，有狀態容器業務也開始得到廣泛使用，包括結構化數據庫、非結構化數據庫、數據分析、內容管理、CI/CD、海量數據共享等業務場景需要對容器的數據進行持久化，容器持久化存儲成爲企業 IT 系統的剛需。近日，CNCF 發佈了最新版本的 Cloud Native Landscape，焱融雲 YRCloudFile 被列入雲原生全景圖譜，位於雲原生存儲象限中，這是國內首個被收錄的容器持久化存儲產品。InfoQ 記者專訪到了焱融雲 CTO 王鵬飛，揭祕這家成立3年多的創業公司是如何憑藉技術實力在競爭激烈的分佈式存儲市場取得一席之地的。
“經歷了華爲、中興事件後，更加深了我們對自研的重視”
互聯網的規模越來越大，併發請求也越來越高，傳統的集中式存儲並不能很好地滿足各種場景的需求，於是分佈式儲存系統得以廣泛應用。王鵬飛提到，“2011年我在IBM工作的時候就開始接觸到分佈式存儲，一直到現在，其實我經歷了分佈式存儲整個蓬勃發展的過程”。隨着互聯網經濟的迅速發展，帶動各行各業的應用呈爆發式增長，對存儲的需求也越來越高，場景劃分越來越細。這是焱融雲創立的一個出發點，就是要做一款好的分佈式存儲。
據王鵬飛介紹，目前市場上做分佈式存儲的公司主要集中在大廠，比如浪潮、NetApp、華爲等。其他一些相對而言較小的公司，主要利用 GlusterFS、CephFS 甚至 Lustre 等一些開源的分佈式文件系統。焱融雲從2017年開始推出基於高性能分佈式文件的容器存儲。YRCloudFile 的定位是統一管理所有服務器磁盤並提供統一命名空間的文件系統，採用分佈式架構，單集羣最多可以支撐上萬個 client 同時訪問。YRCloudFile 可以幫助企業達到對數據的自主可控，其統一命名空間的特點在於，用戶無需感知下層存儲的物理結構以及部署架構；對上層應用而言，它是一個統一的海量文件系統存儲空間。
YRCloudFile 是國內首家進入CNCF Landscape Cloud-Native Storage 的容器存儲產品，無論在接口適配、生態合作，還是容器存儲特殊場景的支持上，焱融雲在國內都處於領先地位。在性能上，YRCloudFile 在最新發布的 IO500 存儲系統性能測試榜單中，也進入了全球 Storage Vendor的前十。無論對大文件順序讀寫，還是對小文件的操作性能上，YRCloudFile 都通過 IO500 的測試得到了驗證。
談及如何在大廠夾擊、競爭激烈的存儲市場保持競爭優勢，王鵬飛提到了三點：
首先是自研。經歷過中興、華爲等事件後，科技公司對自研的感受變得更加深刻，只有自己的，纔是長久的。焱融雲的存儲團隊有豐富的存儲系統開發、維護等經驗，核心團隊成員在金山雲、百度等做過多年的存儲開發，可以說在人員配置上，焱融雲具備了自研的底氣。
其次是性能。YRCloudFile 存儲層軟件對 IO 路徑進行了深度優化，可以充分發揮出底層硬件的特性，配合整個系統的緩存技術，提供更高的性能。同時針對新的網絡、硬盤技術，比如 RDMA、NVMe 都進行了完美的適配。王鵬飛提到，“前段時間與 Mellanox 以及 E8Storage 分別發佈了聯合測試報告，同等硬件條件下，性能比某大廠同類產品要高出50%”。
還有一點是對容器場景的支持。YRCloudFile 可以適配 Kubernetes 的各種版本，無論創建方式是動態創建還是靜態創建，都可與容器平臺緊密結合。
容器持久化存儲逐現崢嶸
近幾年容器的熱度持續上升。在2018年11月，OpenStack Summit 更名爲 Open Infrastructure Summit，對此官方給出的解釋是擁抱開源、擁抱K8S、擁抱容器化。這也從另一個角度證明，容器化已經成爲 IaaS 平臺的事實標準。
從2018年Gartner技術趨勢圖中也可以發現，專門針對容器應用場景的持久化存儲 Container-Native Storage 正處於明顯上升趨勢，其特點是：首先它專門爲支持容器而設計；其次它能夠滿足容器應用的擴展以及性能需求；第三它與容器管理系統深度整合；最後它支持大量系統的並行訪問。
伴隨着 K8S 和容器化的發展，越來越多的用戶有了靈活的業務選擇能力。與此同時，對於業務數據的困擾也隨之而生。存儲在容器內部的任何數據，在容器被銷燬以後，這些數據將自動消失，例如網站頁面、配置文件、數據庫和大數據應用等。因此，在企業真正運行環境中，如何實現容器持久化存儲一直是業界的熱點問題。
容器持久化存儲面臨的挑戰
從Kubernetes官方社區支持的存儲列表中可以看到，目前容器持久化存儲分爲兩類，一種是塊存儲，例如 Ceph、OpenEBS 等；另一種是文件類存儲，如 GlusterFS、CephFS 等。當然還有很多傳統的存儲設備等。但絕大部分的存儲是早在容器普及之前就已經出現了，換句話說，大部分存儲不是爲容器持久化而設計和開發的。
目前容器持久化存儲主要面臨的挑戰有四點：
（1）缺乏存儲軟件和工具；
（2）擔心數據丟失；
（3）現有存儲擴展性差；
（4）傳統 SAN/NAS 陣列靈活性和容器場景針對性差。
具體來看，如果是塊存儲類型，如CephRBD，首先會面臨一個多掛載的問題，使其無法提供ReadWriteMany（RWX）這一非常重要的訪問方式，這對一些應用的部署方式會產生影響；其次，在 Kubernetes 工作節點（Worker Node）發生故障，需要對有狀態 Pod 進行跨節點遷移時，Kubernetes 需要對塊設備進行 umount/deattach/reattach /remount 操作，這是一個耗時並且易錯的過程，這就阻礙了容器的快速恢復。以上兩點是 CephRBD 這種塊存儲用作容器存儲時面臨的問題。而對於文件類存儲，如GlusterFS，在大量的小文件以及目錄層次複雜時將面臨着較大的性能壓力。
容器持久化存儲是 YRCloudFile 的“殺手鐗”
容器平臺天生適合無狀態應用，如Web前端、Nginx 代理等，這是從2017年 Kubernetes 蓬勃發展以來，用戶利用容器平臺的典型場景。但隨着平臺的成熟、使用的深入，越來越多的用戶期望將其他的應用遷移到容器平臺內，如典型的數據庫、數據共享等。
這就面臨一個難題，如何爲這類有狀態的應用提供存儲？很明顯本地存儲是不合適的，因爲隨着容器的遷移，這些數據將無法做到應用的跟隨，客戶需要一個能夠適配容器場景的存儲。王鵬飛提到，“我們在面對一些客戶時，他們當前往往考慮的是如何把應用放到容器上去，而對於底層存儲的選擇只限於能夠工作即可。但很快他們就會發現，只滿足於能夠工作是遠遠不夠的，一個好的存儲非常重要”。
YRCloudFile 架構設計
YRCloudFile 是一款有元數據服務的分佈式文件存儲產品，支持元數據服務和數據服務的線性水平擴展。元數據服務節點數可以支持多達256個，數據服務節點可以支持多達1024個，客戶端節點可以支持上萬個。能夠支持海量文件存儲，文件數據可以支持千億級別，容量可擴展到EB級別。支持RDMA協議，能夠提供亞毫秒級別的延遲。支持文件切片和數據冗餘，能夠提供良好的帶寬。支持冷熱數據分層，在保證高性能的同時，能夠節約成本。支持容器存儲，能夠完美兼容CSI/FlexVolume接口。YRCloudFile 對接容器編排平臺如下圖所示。
YRCloudFile 的容器化支持
可以說，YRCloudFile 對容器具有天然的支持優勢。主要體現在訪問模式上，YRCloudFile 支持三種訪問模式：RWO、ROX、RWX，滿足各種應用對存儲的使用要求，並且針對不同的訪問方式做了深度優化。
YRCloudFile 是最早支持CSI容器存儲接口的存儲產品之一，而 CSI 是整個容器生態的標準存儲接口，可以平滑支持 Kubernetes V1.13及以後的版本。針對CSI接口出現故障，比如存儲鏈路中斷、網絡故障等時，YRCloudFile 創造性地開發了對故障的動態感知功能，即當CSI狀態出現問題時，K8S 會標記該Node，從而避免 Master 節點把新建有狀態 Pod 分發到該 CSI 故障 Node，而不影響整個集羣效率。
雙活數據中心，是YRCloudFile容器存儲的又一亮點，該功能使得跨數據中心部署業務的複雜度大大降低，其容器存儲雙活如下圖所示。
其設計思路是：管理員在YRCloudFile上創建一個跨數據中心的存儲池pool1，當依賴持久化數據的業務需要跨數據中心部署，且希望獲得雙活特性時，可以將PV通過storageclass配置在pool1中。這樣，寫入該PV的數據會同時分佈到兩個數據中心，任何一個數據中心發生火災或電力中斷等災難故障時，pool1在另一個數據中心的數據副本都可以繼續提供讀寫服務。同時，藉助YRCloudFile支持有狀態容器快速恢復和遷移的特性，可以幫助管理員快速地將故障數據中心上運行的業務遷移至安全的數據中心。
客戶除了需要依賴雙活容器存儲池進行跨數據中心部署的應用，也有只需要部署在某一數據中心內的應用，這種應用只要把數據存放在應用所在的數據中心即可。這時，管理員可以在同一個YRCloudFile集羣的統一命名空間內，創建另外一個新的存儲池pool2，pool2的數據副本策略設置爲同一個數據中心。管理員通過YRCloudFile提供的另一個storageclass，即可將PV創建在pool2。這樣，有狀態應用容器所生成的數據副本，就都管理在pool2內，數據的讀和寫都發生在本數據中心了。YRCloudFile 的雙活容器存儲、本地優先讀、雙活存儲池加本地存儲池統一管理的功能，大大增強了 IT架構的靈活性。
除了以上之外，YRCloudFile 還做了很多其他的工作。首先，把K8S的存儲（PV/PVC/Pod）呈現在了YRCloudFile管理界面，提供可視化功能，用戶可以在管理界面清楚瞭解Pod、PV 使用量、PVC 關聯關係。並且能通過名稱、大小、Label 等對 PV/PVC/Pod 進行搜索和篩選，方便用戶管理。
其次，可針對實際應用中大量PV場景下，提供PV Hot Spot 功能，對熱點PV進行跟蹤和定位，保障系統的穩定運行。 並且能針對每一個 PV 設置性能告警功能，對重點需要監控的PV，設置PV性能告警閾值，實現細粒度的管理和監控。
第三，YRCloudFile 還提供了QoS功能。用戶可以通過參數設置限制 PV 的 IOPS 及 BandWidth；從而達到有效利用存儲資源的效果，保障關鍵應用的性能。
第四，YRCloudFile 還提供 **PV Insight **功能，以圖形化的方式，從三個維度（數據層次、文件大小、數據溫度）幫助用戶對業務進行分析和調整。
第五，YRCloudFile 提供了 PV Resize 功能，當企業需要調整 PV 配置額外存儲但又無法忍受服務中斷時間時，通過 PV Resize 功能，不需要將應用程序或服務脫機，只需一個簡單的操作，即可以調整PV的大小。
最後，YRCloudFile 還提供自定義的**Prometheus exporter**，向 Prometheus server 提供集羣監控數據，並且提供基於 Grafana 的集羣監控 Web 展現模板。用戶可以統一觀察到所有集羣的狀態，從而提高運維的效率。
YRCloudFile的其他創新優勢
YRCloudFile 的高性能
CephFS 是構建在 RADOS 基礎上的，而Ceph的OSD性能損耗比較大，越是性能好的硬件，體現出來的性能損耗則越大。同時 CephFS 的多 MDS 架構實現非常複雜，尤其是當文件數量大了之後，其體現出來的性能跟理論值差距非常大。NAS的性能主要受限於NAS網關的數量和NFS協議，通常情況下，NAS網關只有2～4個，因此帶寬受到很大限制，同時NFS的協議消耗也比較大。
根據大量的實踐和測試，最終 YRCloudFile 採用輕量級的數據模型和動態子樹的多MDS方案，與Ceph不同的是，YRCloudFile不會在內存中維護 B+ tree，而是將其持久化到磁盤中，結果就是相對簡潔穩定。即使在百億級的文件數量場景，性能衰減也很小。同時 YRCloudFile 採用專有客戶端進行數據訪問，避免了 NFS 協議的消耗，性能有保障。
YRCloudFile 有效應對海量小文件場景
隨着移動終端使用頻繁，文件碎片化越來越嚴重，以前一些傳統的存儲並不能很好地支撐小文件的場景。比如一個傳統存儲，在運行大文件讀寫的時候性能非常好，但隨着場景的複雜化，導致各種各樣應用都需要把數據放到存儲裏，從而產生了大量的小文件，不管是查詢還是訪問，性能降低得很明顯。這是傳統存儲技術面臨的問題，即如何存儲小文件。以GlusterFS舉例，在典型的用戶場景，即存儲的都是大文件（例如日誌）時，工作良好；但是當容器內需要產生海量小文件時，性能上就無法滿足需求了。
YRCloudFile可以同時支持海量小文件存儲和大文件存儲，這在業界還是比較少見的。其具體實現思路是：
首先，基於元數據服務可以隨時擴展的特性。由於元數據信息存在磁盤裏面，所以可以通過元數據集羣規模的擴大來支撐海量小文件，比如現在有幾千萬個小文件，2個元數據節點就夠了；如果有幾億個元數據，可以將元數據擴展成4個甚至更多。
其次，通過動態算法實現負載均衡。YRCloudFile 會根據整個集羣元數據的分佈的情況，包括流量信息等，通過把這些信息分散在不同的元數據節點裏，使得一個目錄裏即使有非常海量的小文件也不會影響訪問效率，這樣相當於消除了某一個元數據節點的熱點問題，實現負載均衡，充分利用底層多個元數據節點的服務能力。
第三點就是使用自定義協議。爲了充分利用 YRCloudFile 本身提供的一些性能，焱融雲開發了客戶端，通過自己開發的協議，提高通信效率，也提高了對小文件讀寫的性能。
加入CNCF雲原生全景圖譜後，YRCloudFile 的未來？
YRCloudFile 在近期發佈的幾個版本中，逐漸豐富了對容器的整合能力；並推出了支持數據的冷熱分層的智能分層功能，在提供同樣性能的基礎上爲用戶節省更多的成本；同時也支持了Harbor HA，從生態的角度讓拼圖更加完整。
對於YRCloudFile 的未來規劃，王鵬飛提到兩點：首先，焱融雲會保持高性能的分佈式文件系統以及容器存儲的方向，無論是對新技術的支持，還是本身軟件的優化，會一直持續進步。
再者，焱融雲會全面擁抱Cloud Native這個大家庭，包括自身產品的容器化方案的能力，到與 Harbor、Etcd以及Promethues 等軟件的整合，將專注於容器存儲本身，加強與容器平臺的廠商合作。