SmartX 超融合 SMTX OS 分布式塊存儲 Kubernetes CSI 實現解析

毋庸置疑，容器與容器編排已經成為目前 IT 人員最為關注的技術之一并得到快速的普及。根據 Gartner 的調查（1），截止到 2022 年，僅有 10% 的 CIO 對容器使用沒有任何的計劃，而 27% 的 CIO 已經計劃將容器應用于生產環境。

1. Gartner IOCS 2018 Conference polling results

最初的容器主要應用于無狀態應用，并不需要持久化的存儲，但隨著容器被原來越多的采用，以及其配合 Kubernetes 帶來的強大的自動化管理能力，MongoDB、MySQL 和 PostgreSQL 等有狀態應用被越來多的運行于容器之上，對持久化存儲提出更多需求和更高的要求。

SmartX 分布式塊存儲（內部代號：SMTX ZBS）由 SmartX 自主開發，作為 SmartX 超融合的核心引擎，ZBS 已經被大量應用于金融、制造業、通信、地產等行業的私有云建設、虛擬化整合等場景，承載用戶生產以及開發業務。其穩定性、易用性和豐富的存儲特性已經經過長時間檢驗，并獲得大量行業頭部認可。

日前，SMTX ZBS 的 CSI 驅動已正式加入到 K8s 官方的驅動列表，企業客戶不僅可以繼續使用 SMTX ZBS 構建私有云和超融合系統，亦可使用其為 K8s 提供持久化存儲，支持數據庫等有狀態應用，進一步加速 K8s 在企業內部更多場景落地。

Kubernetes 官網截圖

以下部分概述了 CSI 的機制以及 SMTX ZBS 與 CSI 的接口實現。

概念與定義

1.?K8s 的持久化存儲支持

在支持持久化存儲方面，K8s 提供了內嵌原生 Driver 的方式連接外部的常見存儲系統例如 NFS、iSCSI、CephFS、RBD 等來滿足不同業務的需求。但由于存儲生態本身也在不斷演進，使用 K8s 內嵌的方式來支持不斷變化的存儲系統在成本和時效上都會對 K8s 項目自身帶來巨大的挑戰。

所以和其他服務管理系統一樣，K8s 逐漸的將存儲系統的具體實現從主項目中分離出來，通過定義接口的方式允許第三方廠商自行接入存儲服務。在這個道路上也經歷了兩個階段：

1. Flex Volume,? 自 1.2 版本引入。

第三方存儲服務提供商直接在 K8s Server 上部署符合 Flex Volume 規范的 Driver，利用 K8s 暴露出的 mount/unmount/attach/detach 等關鍵 API 實現存儲系統的接入。這個模式主要的問題是，在這個形態下第三方廠商的 Driver 有權限接入物理節點的根文件系統，這會帶來安全上的隱患。

2. Container Storage Interface (CSI),? 自 1.9 版本引入，目前已經進入 GA 階段（1.13）。

CSI 定義了容器場景所需要的存儲控制原語和完整的控制流程，并且在 K8s 的 CSI 實現中，所有的第三方 Driver 和 K8s 的其他服務擴展一樣，以服務容器的形態的運行，不會直接影響到 K8s 的核心系統穩定性。

2.?存儲對象

CSI 定義的存儲對象為持久化卷，稱之為 Volume。包括兩種類型：

• Mounted File Volume，Node 將會把 Volume 以指定的文件格式 Mount 到 Container 上，從 Container 的角度看到的是一個目錄；

• Raw Block Volume,? 直接將 Volume 以 Block Device（磁盤）的形態暴露給 Container，對于某些可以直接操作磁盤的服務，這個形態可以省去文件系統的開銷獲得更好的性能。
  

Raw Block Volume 目前還處于 Beta 階段，所以下文的過程描述和 SMTX 的 CSI Driver 目前的實現方式均針對 Mounted File Volume。

3.?Plugin

CSI 將一個實現了 CSI 服務的 Driver 稱之為 Plugin。根據提供的功能不同將它分為兩種類型：

• Controller Plugin，負責存儲對象（Volume）的生命周期管理，在集群中僅需要有一個即可；

• Node Plugin，在必要時與使用 Volume 的容器所在的節點交互，提供諸如節點上的 Volume 掛載/卸載等動作支持，如有需要則在每個服務節點上均部署。
  

存儲服務商可以根據自身需求實現不同的的 Plugin 組合。例如對于以 NFS 形式提供的存儲服務，可以僅實現 Controller Plugin 實現資源的創建和訪問權限控制，每個節點均可以通過標準的 NFS 方式獲得服務，無需通過 Node Plugin 來實現掛載/卸載等操作。而以 iSCSI 形式提供的存儲服務，就需要 Node Plugin 在指定節點上，通過掛載 LUN，格式化，掛載文件系統等一系列動作完成 iSCSI LUN 至容器可見的目錄形式的轉化。

4.?Volume 生命周期

一個典型的 CSI Volume 生命周期如下圖（來自 CSI SPEC）所示：

1. Volume 被創建后進入 CREATED 狀態，此時 Volume 僅在存儲系統中存在，對于所有的 Node 或者 Container 都是不可感知的；

2. 對 CREATED 狀態的 Volume 進行 Controlller Publish 動作后在指定的 Node 上進入 NODE_READY 的狀態，此時 Node 可以感知到 Volume，但是 Container 依然不可見；
   

3. 在 Node 對 Volume 進行 Stage 操作，進入 VOL_READY 的狀態，此時 Node 已經與 Volume 建立連接。Volume 在 Node 上以某種形式存在；
   

4. 在 Node 上對 Volume 進行 Publish 操作，此時 Volume 將轉化為 Node 上 Container 可見的形態被 Container 利用，進入正式服務的狀態；
   

5. 當 Container 的生命周期結束或其他不再需要 Volume 情況發生時，Node 執行 Unpublish Volume 動作，將 Volume 與 Container 之間的連接關系解除，回退至 VOL_READY 狀態；
   

6. Node Unstage 操作將會把 Volume 與 Node 的連接斷開，回退至 NODE_READY 狀態；
   

7. Controller Unpublish 操作則會取消 Node 對 Volume 的訪問權限；
   

8. Delete 則從存儲系統中銷毀 Volume。
   

CSI 要求狀態轉化操作是冪等的，并在原則上保證 Volume 的狀態轉化是有序進行的。

根據存儲使用方式和內部實現的不同，狀態機可以略有區別，但對應操作必須是成對出現的。例如在不需要額外建立 Node 與 Volume 之間連接的 Stage/Unstage 階段時，狀態機就可以直接通過 Controller Publish/Unpublish 在 NODE_READY 與 PUBISHED 之間轉化，而無需經過 VOL_READY 階段。Plugin 向 CSI 注冊時必須聲明自身支持哪些語義。

5.?RPC

CSI 要求 Plugin 支持的 RPC 包括：

Identity Service：認證服務，Controller 和 Node Plugin 均需要支持

• GetPluginInfo， 獲取 Plugin 基本信息

• GetPluginCapabilities，獲取 Plugin 支持的能力
  

• Probe，探測 Plugin 的健康狀態
  

Controller Service：控制服務

• Volume CRUD，包括了擴容和容量探測等 Volume 狀態檢查與操作接口
  

• Controller Publish/Unpublish Volume ，Node 對 Volume 的訪問權限管理
  

• Snapshot CRD，快照的創建和刪除操作，目前 CSI 定義的 Snapshot 僅用于創建 Volume，未提供回滾的語義
  

Node Service：節點服務

• Node Stage/Unstage/Publish/Unpublish/GetStats Volume，節點上 Volume 的連接狀態管理
  

• Node Expand Volume, 節點上的 Volume 擴容操作，在 volume 邏輯大小擴容之后，可能還需要同步的擴容 Volume 之上的文件系統并讓使用 Volume 的 Container 感知到，所以在 Node Plugin 上需要有對應的接口
  

• Node Get Capabilities/Info， Plugin 的基礎屬性與 Node 的屬性查詢
  

部署形態

CSI 使用 Sidecar 的方式實現 CSI Plugin 與 K8s 核心邏輯的解耦。Sidecar 代表監聽了 CSI 指定 API 的標準容器，它與 CSI Plugin 共同組成一個 Pod 對外提供服務，它們之間通過 Socket 連接。在這個模式下，Sidecar 成為 CSI Plugin 與 K8s 之間連接的中介和隔離帶。理想狀態下二者可以在不直接交互和影響的情況下共同工作，解決了安全問題。

CSI 定義了如下幾種 Sidecar：

• external-provisioner：監聽 Volume CRUD API，完成 Volume 的生命周期管理

• external-attacher：監聽 Controller[Publish|Unpublish]Volume API，實現 Node 和 Volume 的可見性控制
  

• external-snapshotter：監聽 Snapshot CRD API，完成 Snapshot 的生命周期管理
  

• node-driver-register：監聽 Node 基本信息查詢 API，注冊 Node Plugin，每個節點 Node Plugin 均需要通過 driver-register 注冊自身才可以與 K8s 之間建立連接獲取 Node Volume 相關請求
  

• cluster-driver-register：用于向 K8s 注冊 Plugin 整體支持的模式，包括是否跳過 Attach 階段/是否在 Node Publish Volume 階段時需要 K8s 提供 Pod 信息
  

• livenessprobe：心跳檢測，用于探測 Plugin 的存活狀態
  

適用場景

在容器化發展的早期階段，Container 多用于承擔輕量型的無狀態服務，對數據存儲的需求大多通過本地的臨時共享文件，或者用網絡訪問的方式將數據置于遠端的日志收集或者 DB 等外部存儲上。這種模式業務和數據之間從程序管理的角度看是松耦合的，互相獨立，沒有嚴格的依賴。

但是另一方面，這個模式下數據本身無法成為服務的一部分，并不能通過 K8s 統一管理。并且需要為每個應用打開通往遠端存儲服務的網絡通道，這在安全性上有時并不是一個好的選擇。

而基于持久化卷，將數據服務提供方也放入 K8s Pod 中（例如掛載持久化卷作為磁盤，上面部署容器運行 DB）作為完整應用的一部分，數據即可以做到與應用無縫的統一管理，所有應用內部 Pod 間的業務數據請求均可以在 K8s 提供的虛擬網絡中進行。而基于 K8s 本身的高可用特性和 CSI Driver 的靈活配置能力也可以獲得不遜色于外部存儲的可靠性與性能。

SMTX ZBS x CSI

1.?SMTX ZBS

SMTX ZBS 通過 iSCSI 的方式為 K8s 提供持久化存儲。它的內部結構如下圖所示：

SMTX ZBS 內部結構

在每個節點上部署有 Chunk Server 用于管理本地的 SSD/HDD 提供統一的高性能混合存儲服務，在部分節點上部署 Meta 作為元數據管理服務，將 Chunk Server 組成高可靠集群。每個 Chunk Server 提供如 iSCSI Target 這樣的協議接入服務，他們在接入上是邏輯等價的，即可以從任一一個 Chunk Server 訪問到集群中所有的 Target 和 LUN。

2.?ZBS CSI Driver

ZBS CSI Driver 的部署形態如下圖所示：

ZBS CSI Driver 部署形態

每個 CSI Volume 與 ZBS? iSCSI LUN 一一對應，它的生命周期如下：

1. Create Volume：Controller Plugin 收到創建請求之后會在 ZBS 中創建一個 iSCSI LUN ，如有必要則會自動再創建需要的 Target，ZBS 的實現中，iSCSI LUN 以及所屬的 Target 均為邏輯對象，不與物理磁盤綁定。一個集群中允許創建 4096 個 Target，每個 Target 中最多允許創建 255 個 LUN，多個 CSI Volume 會處在相同的 Target 內；

2. Controller Publish Volume：目前 Kubernetes 使用 Open iSCSI 作為節點上的數據接入服務，Open iSCSI 在掛載 Target 時，會將所有 Target 內的 LUN 均掛載到主機上作為一個 Block Device（例如 /dev/sdx 這樣的磁盤) 。為了避免讓主機察覺到不需要也不應該訪問的 LUN，ZBS 采用了近似 LUN Masking 的機制來達到這個目標。在初始 Volume 對應的 LUN 在創建時，不會允許任何 iSCSI initiator （iSCSI 的協議客戶端）發現 LUN。在 Controller? Publish? Volume 階段，ZBS Controller Plugin 會將指定 Node 上的 initiator 注冊到 LUN 上，在這之后，關聯 Node 的 iSCSI discovery 機制才可以在 Target 內發現并訪問 LUN；

3. Node Stage Volume：ZBS Node Plugin 會將 LUN 通過 Open iSCSI 命令掛載至主機，呈現為一個磁盤；

4. Node Publish Volume：ZBS? Node Plugin 對磁盤進行格式化（如果磁盤之前尚未被格式化，如已經格式化則為跳過對應步驟），將磁盤 Mount 到主機上提供給 Container 使用；

5. Node Unpublish Volume：ZBS Node Plugin 將磁盤上的文件系統 Unmount；

6. Node Stage Volume：ZBS Node Plugin 在主機上將斷開磁盤的 iSCSI 鏈接；

7. Controller Unpublish Volume：ZBS Controller Plugin 向 ZBS 后端注銷指定 Node 在 LUN 上的訪問權限；

8. Delete Volume：ZBS Controller Plugin 請求 ZBS 刪除對應的 LUN ，LUN 所占用的數據空間將會在存儲系統中被回收。

ZBS CSI Driver 支持 Snapshot CRD 操作，Snapshot 的方式為 COW，相關請求僅涉及簡單的元數據操作，所以關聯接口會以同步模式快速響應。Snapshot 自身或者基于 Snapshot 創建的 Volume 都會立刻處于 Volume Ready 的狀態。

3.?數據鏈路

K8s 和 ZBS 之間的 iSCSI 數據鏈路如下圖所示：

K8s 和 ZBS 之間的 iSCSI 數據鏈路

ZBS 使用 iSCSI Redirector 模式提供 iSCSI 接入服務，CSI Plugin 給 Driver 提供的 iSCSI 服務端地址為 iSCSI Redirector 地址，initiator 嘗試連接 iSCSI Server（Target 端，ZBS 中由 Chunk 提供 Target 服務）時，Redirector 將會采用的 hash 的方式引導 initiator 重新連接向一個可用的 Chunk Server。

在重定向之后，所有的數據請求僅在 initiator 與 Chunk 之間進行，無需經過 Redirectord。ZBS 集群中所有 Chunk Server 在處理 iSCSI 接入請求時是邏輯等價的，即任一 Chunk 均可以提供集群中的任一個 Target LUN 的數據訪問服務。重定向的方式可以有效的分散數據接入壓力，充分利用集群性能。

4.?可靠與可用性

SMTX ZBS 在設計之初就以高可靠、高可用、高性能為目標，在集群內部采用多副本，靜默數據檢查自動平衡和恢復等機制來保證數據的安全可靠。在這個基礎之上，K8s CSI 模式獲得比使用本地存儲更高的安全性。

（1）異常處理

K8s 計算節點異常

Node A 上的 pod 將會被自動在其他節點（Node B）上拉起，會重新經歷 Node B 上 Publish Volume 至掛載的動作。 Node B 會接入? Chunk server 提供 Pod 關聯的 Volume 的 IO 服務，之前在 Node A 上已經寫入 Volume 中的數據不會受到損失。

Chunk 節點異常

如果是計算節點當前連接的 Chunk 異常，則與 Chunk 節點間的鏈路將中斷，計算節點會重新向 iSCSI Redirector 服務尋求一個新的接入節點迅速恢復服務。通常情況下這個影響的時間為秒級。

如果非當前連接的 Chunk 異常，可能會因為 IO 副本損失而產生短暫的延遲，iSCSI 鏈路本身不會受到影響，影響時間也為秒級。

iSCSI Redirector 節點異常

SMTX ZBS 提供 VIP（虛擬 IP） 服務，可以保證集群中有且僅有一個節點會持有該 VIP。iSCSI Redirector 運行在 VIP 節點上，當它異常時。自然會替換到新的 VIP 節點提供 iSCSI Redirector 服務。ZBS 保證所有的節點提供的 Redirector 服務是等價的。

（2）雙活與異地備份

ZBS 在基本存儲功能的基礎上，還提供雙活集群和異地備份的功能。借助這兩個功能，K8s CSI Volume 可以獲得同城跨數據中心的數據強一致安全性保證或者是自動的跨城市/數據中心的定期備份能力。

5. 整體部署形式

目前 SMTX 對 CSI 支持兩種形態的部署形式，基于 VM 的融合模式與分離模式，后續將提供 SMTX K8s 原生融合模式的部署支持。

（1）分離模式

K8s 和 SMTX ZBS 分別是獨立的物理集群，他們之間通過接入網絡互相關聯。接入網絡需要獨立于 K8s 中的業務網絡和 ZBS 使用的存儲網絡。

（2）融合模式

融合模式下，K8s 運行在 SMTX OS 提供的虛擬機上。通過接入網絡接入 SMTX OS 上的 ZBS 服務。這個部署方式可以更高效的利用物理資源。

參考資料：

CSI Design Doc:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md

CSI SPEC:

https://github.com/container-storage-interface/spec

CSI Driver Developer Documentation:

https://kubernetes-csi.github.io/docs/introduction.html

了解更多：https://www.smartx.com