Gartner IOCS 2018 Conference polling results

最初的容器主要應(yīng)用于無(wú)狀態(tài)應(yīng)用，并不需要持久化的存儲(chǔ)，但隨著容器被原來(lái)越多的采用，以及其配合 Kubernetes 帶來(lái)的強(qiáng)大的自動(dòng)化管理能力，MongoDB、MySQL 和 PostgreSQL 等有狀態(tài)應(yīng)用被越來(lái)多的運(yùn)行于容器之上，對(duì)持久化存儲(chǔ)提出更多需求和更高的要求。

SmartX 分布式塊存儲(chǔ)（內(nèi)部代號(hào)：SMTX ZBS）由 SmartX 自主開(kāi)發(fā)，作為 SmartX 超融合的核心引擎，ZBS 已經(jīng)被大量應(yīng)用于金融、制造業(yè)、通信、地產(chǎn)等行業(yè)的私有云建設(shè)、虛擬化整合等場(chǎng)景，承載用戶(hù)生產(chǎn)以及開(kāi)發(fā)業(yè)務(wù)。其穩(wěn)定性、易用性和豐富的存儲(chǔ)特性已經(jīng)經(jīng)過(guò)長(zhǎng)時(shí)間檢驗(yàn)，并獲得大量行業(yè)頭部認(rèn)可。

日前，SMTX ZBS 的 CSI 驅(qū)動(dòng)已正式加入到 K8s 官方的驅(qū)動(dòng)列表，企業(yè)客戶(hù)不僅可以繼續(xù)使用 SMTX ZBS 構(gòu)建私有云和超融合系統(tǒng)，亦可使用其為 K8s 提供持久化存儲(chǔ)，支持?jǐn)?shù)據(jù)庫(kù)等有狀態(tài)應(yīng)用，進(jìn)一步加速 K8s 在企業(yè)內(nèi)部更多場(chǎng)景落地。

Kubernetes 官網(wǎng)截圖

以下部分概述了 CSI 的機(jī)制以及 SMTX ZBS 與 CSI 的接口實(shí)現(xiàn)。

概念與定義

1 K8s 的持久化存儲(chǔ)支持

在支持持久化存儲(chǔ)方面，K8s 提供了內(nèi)嵌原生 Driver 的方式連接外部的常見(jiàn)存儲(chǔ)系統(tǒng)例如 NFS、iSCSI、CephFS、RBD 等來(lái)滿(mǎn)足不同業(yè)務(wù)的需求。但由于存儲(chǔ)生態(tài)本身也在不斷演進(jìn)，使用 K8s 內(nèi)嵌的方式來(lái)支持不斷變化的存儲(chǔ)系統(tǒng)在成本和時(shí)效上都會(huì)對(duì) K8s 項(xiàng)目自身帶來(lái)巨大的挑戰(zhàn)。

所以和其他服務(wù)管理系統(tǒng)一樣，K8s 逐漸的將存儲(chǔ)系統(tǒng)的具體實(shí)現(xiàn)從主項(xiàng)目中分離出來(lái)，通過(guò)定義接口的方式允許第三方廠商自行接入存儲(chǔ)服務(wù)。在這個(gè)道路上也經(jīng)歷了兩個(gè)階段：

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

第三方存儲(chǔ)服務(wù)提供商直接在 K8s Server 上部署符合 Flex Volume 規(guī)范的 Driver，利用 K8s 暴露出的 mount/unmount/attach/detach 等關(guān)鍵 API 實(shí)現(xiàn)存儲(chǔ)系統(tǒng)的接入。這個(gè)模式主要的問(wèn)題是，在這個(gè)形態(tài)下第三方廠商的 Driver 有權(quán)限接入物理節(jié)點(diǎn)的根文件系統(tǒng)，這會(huì)帶來(lái)安全上的隱患。

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

CSI 定義了容器場(chǎng)景所需要的存儲(chǔ)控制原語(yǔ)和完整的控制流程，并且在 K8s 的 CSI 實(shí)現(xiàn)中，所有的第三方 Driver 和 K8s 的其他服務(wù)擴(kuò)展一樣，以服務(wù)容器的形態(tài)的運(yùn)行，不會(huì)直接影響到 K8s 的核心系統(tǒng)穩(wěn)定性。

2 存儲(chǔ)對(duì)象

CSI 定義的存儲(chǔ)對(duì)象為持久化卷，稱(chēng)之為 Volume。包括兩種類(lèi)型：

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

Raw Block Volume, 直接將 Volume 以 Block Device（磁盤(pán)）的形態(tài)暴露給 Container，對(duì)于某些可以直接操作磁盤(pán)的服務(wù)，這個(gè)形態(tài)可以省去文件系統(tǒng)的開(kāi)銷(xiāo)獲得更好的性能。

Raw Block Volume 目前還處于 Beta 階段，所以下文的過(guò)程描述和 SMTX 的 CSI Driver 目前的實(shí)現(xiàn)方式均針對(duì) Mounted File Volume。

3 Plugin

CSI 將一個(gè)實(shí)現(xiàn)了 CSI 服務(wù)的 Driver 稱(chēng)之為 Plugin。根據(jù)提供的功能不同將它分為兩種類(lèi)型：

·Controller Plugin，負(fù)責(zé)存儲(chǔ)對(duì)象（Volume）的生命周期管理，在集群中僅需要有一個(gè)即可；

·Node Plugin，在必要時(shí)與使用 Volume 的容器所在的節(jié)點(diǎn)交互，提供諸如節(jié)點(diǎn)上的 Volume 掛載/卸載等動(dòng)作支持，如有需要?jiǎng)t在每個(gè)服務(wù)節(jié)點(diǎn)上均部署。

存儲(chǔ)服務(wù)商可以根據(jù)自身需求實(shí)現(xiàn)不同的的 Plugin 組合。例如對(duì)于以 NFS 形式提供的存儲(chǔ)服務(wù)，可以?xún)H實(shí)現(xiàn) Controller Plugin 實(shí)現(xiàn)資源的創(chuàng)建和訪問(wèn)權(quán)限控制，每個(gè)節(jié)點(diǎn)均可以通過(guò)標(biāo)準(zhǔn)的 NFS 方式獲得服務(wù)，無(wú)需通過(guò) Node Plugin 來(lái)實(shí)現(xiàn)掛載/卸載等操作。而以 iSCSI 形式提供的存儲(chǔ)服務(wù)，就需要 Node Plugin 在指定節(jié)點(diǎn)上，通過(guò)掛載 LUN，格式化，掛載文件系統(tǒng)等一系列動(dòng)作完成 iSCSI LUN 至容器可見(jiàn)的目錄形式的轉(zhuǎn)化。

4 Volume 生命周期

一個(gè)典型的 CSI Volume 生命周期如下圖（來(lái)自 CSI SPEC）所示：

1.Volume 被創(chuàng)建后進(jìn)入 CREATED 狀態(tài)，此時(shí) Volume 僅在存儲(chǔ)系統(tǒng)中存在，對(duì)于所有的 Node 或者 Container 都是不可感知的；

2.對(duì) CREATED 狀態(tài)的 Volume 進(jìn)行 Controlller Publish 動(dòng)作后在指定的 Node 上進(jìn)入 NODE_READY 的狀態(tài)，此時(shí) Node 可以感知到 Volume，但是 Container 依然不可見(jiàn)；

3.在 Node 對(duì) Volume 進(jìn)行 Stage 操作，進(jìn)入 VOL_READY 的狀態(tài)，此時(shí) Node 已經(jīng)與 Volume 建立連接。Volume 在 Node 上以某種形式存在；

4.在 Node 上對(duì) Volume 進(jìn)行 Publish 操作，此時(shí) Volume 將轉(zhuǎn)化為 Node 上 Container 可見(jiàn)的形態(tài)被 Container 利用，進(jìn)入正式服務(wù)的狀態(tài)；

5.當(dāng) Container 的生命周期結(jié)束或其他不再需要 Volume 情況發(fā)生時(shí)，Node 執(zhí)行 Unpublish Volume 動(dòng)作，將 Volume 與 Container 之間的連接關(guān)系解除，回退至 VOL_READY 狀態(tài)；

6.Node Unstage 操作將會(huì)把 Volume 與 Node 的連接斷開(kāi)，回退至 NODE_READY 狀態(tài)；

7.Controller Unpublish 操作則會(huì)取消 Node 對(duì) Volume 的訪問(wèn)權(quán)限；

8.Delete 則從存儲(chǔ)系統(tǒng)中銷(xiāo)毀 Volume。

9.CSI 要求狀態(tài)轉(zhuǎn)化操作是冪等的，并在原則上保證 Volume 的狀態(tài)轉(zhuǎn)化是有序進(jìn)行的。

根據(jù)存儲(chǔ)使用方式和內(nèi)部實(shí)現(xiàn)的不同，狀態(tài)機(jī)可以略有區(qū)別，但對(duì)應(yīng)操作必須是成對(duì)出現(xiàn)的。例如在不需要額外建立 Node 與 Volume 之間連接的 Stage/Unstage 階段時(shí)，狀態(tài)機(jī)就可以直接通過(guò) Controller Publish/Unpublish 在 NODE_READY 與 PUBISHED 之間轉(zhuǎn)化，而無(wú)需經(jīng)過(guò) VOL_READY 階段。Plugin 向 CSI 注冊(cè)時(shí)必須聲明自身支持哪些語(yǔ)義。

5 RPC

CSI 要求 Plugin 支持的 RPC 包括：

Identity Service：認(rèn)證服務(wù)，Controller 和 Node Plugin 均需要支持

GetPluginInfo，獲取 Plugin 基本信息

GetPluginCapabilities，獲取 Plugin 支持的能力

Probe，探測(cè) Plugin 的健康狀態(tài)

Controller Service：控制服務(wù)

Volume CRUD，包括了擴(kuò)容和容量探測(cè)等 Volume 狀態(tài)檢查與操作接口

Controller Publish/Unpublish Volume，Node 對(duì) Volume 的訪問(wèn)權(quán)限管理

Snapshot CRD，快照的創(chuàng)建和刪除操作，目前 CSI 定義的 Snapshot 僅用于創(chuàng)建 Volume，未提供回滾的語(yǔ)義

Node Service：節(jié)點(diǎn)服務(wù)

Node Stage/Unstage/Publish/Unpublish/GetStats Volume，節(jié)點(diǎn)上 Volume 的連接狀態(tài)管理

Node Expand Volume, 節(jié)點(diǎn)上的 Volume 擴(kuò)容操作，在 volume 邏輯大小擴(kuò)容之后，可能還需要同步的擴(kuò)容 Volume 之上的文件系統(tǒng)并讓使用 Volume 的 Container 感知到，所以在 Node Plugin 上需要有對(duì)應(yīng)的接口

Node Get Capabilities/Info，Plugin 的基礎(chǔ)屬性與 Node 的屬性查詢(xún)

部署形態(tài)

CSI 使用 Sidecar 的方式實(shí)現(xiàn) CSI Plugin 與 K8s 核心邏輯的解耦。Sidecar 代表監(jiān)聽(tīng)了 CSI 指定 API 的標(biāo)準(zhǔn)容器，它與 CSI Plugin 共同組成一個(gè) Pod 對(duì)外提供服務(wù)，它們之間通過(guò) Socket 連接。在這個(gè)模式下，Sidecar 成為 CSI Plugin 與 K8s 之間連接的中介和隔離帶。理想狀態(tài)下二者可以在不直接交互和影響的情況下共同工作，解決了安全問(wèn)題。

CSI 定義了如下幾種 Sidecar：

external-provisioner：監(jiān)聽(tīng) Volume CRUD API，完成 Volume 的生命周期管理

external-attacher：監(jiān)聽(tīng) Controller[Publish|Unpublish]Volume API，實(shí)現(xiàn) Node 和 Volume 的可見(jiàn)性控制

external-snapshotter：監(jiān)聽(tīng) Snapshot CRD API，完成 Snapshot 的生命周期管理

node-driver-register：監(jiān)聽(tīng) Node 基本信息查詢(xún) API，注冊(cè) Node Plugin，每個(gè)節(jié)點(diǎn) Node Plugin 均需要通過(guò) driver-register 注冊(cè)自身才可以與 K8s 之間建立連接獲取 Node Volume 相關(guān)請(qǐng)求

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

livenessprobe：心跳檢測(cè)，用于探測(cè) Plugin 的存活狀態(tài)

適用場(chǎng)景

在容器化發(fā)展的早期階段，Container 多用于承擔(dān)輕量型的無(wú)狀態(tài)服務(wù)，對(duì)數(shù)據(jù)存儲(chǔ)的需求大多通過(guò)本地的臨時(shí)共享文件，或者用網(wǎng)絡(luò)訪問(wèn)的方式將數(shù)據(jù)置于遠(yuǎn)端的日志收集或者 DB 等外部存儲(chǔ)上。這種模式業(yè)務(wù)和數(shù)據(jù)之間從程序管理的角度看是松耦合的，互相獨(dú)立，沒(méi)有嚴(yán)格的依賴(lài)。

但是另一方面，這個(gè)模式下數(shù)據(jù)本身無(wú)法成為服務(wù)的一部分，并不能通過(guò) K8s 統(tǒng)一管理。并且需要為每個(gè)應(yīng)用打開(kāi)通往遠(yuǎn)端存儲(chǔ)服務(wù)的網(wǎng)絡(luò)通道，這在安全性上有時(shí)并不是一個(gè)好的選擇。

而基于持久化卷，將數(shù)據(jù)服務(wù)提供方也放入 K8s Pod 中（例如掛載持久化卷作為磁盤(pán)，上面部署容器運(yùn)行 DB）作為完整應(yīng)用的一部分，數(shù)據(jù)即可以做到與應(yīng)用無(wú)縫的統(tǒng)一管理，所有應(yīng)用內(nèi)部 Pod 間的業(yè)務(wù)數(shù)據(jù)請(qǐng)求均可以在 K8s 提供的虛擬網(wǎng)絡(luò)中進(jìn)行。而基于 K8s 本身的高可用特性和 CSI Driver 的靈活配置能力也可以獲得不遜色于外部存儲(chǔ)的可靠性與性能。

SMTX ZBS x CSI

1 SMTX ZBS

SMTX ZBS 通過(guò) iSCSI 的方式為 K8s 提供持久化存儲(chǔ)。它的內(nèi)部結(jié)構(gòu)如下圖所示：

SMTX ZBS 內(nèi)部結(jié)構(gòu)

在每個(gè)節(jié)點(diǎn)上部署有 Chunk Server 用于管理本地的 SSD/HDD 提供統(tǒng)一的高性能混合存儲(chǔ)服務(wù)，在部分節(jié)點(diǎn)上部署 Meta 作為元數(shù)據(jù)管理服務(wù)，將 Chunk Server 組成高可靠集群。每個(gè) Chunk Server 提供如 iSCSI Target 這樣的協(xié)議接入服務(wù)，他們?cè)诮尤肷鲜沁壿嫷葍r(jià)的，即可以從任一一個(gè) Chunk Server 訪問(wèn)到集群中所有的 Target 和 LUN。

2 ZBS CSI Driver

ZBS CSI Driver 的部署形態(tài)如下圖所示：

ZBS CSI Driver 部署形態(tài)

每個(gè) CSI Volume 與 ZBS iSCSI LUN 一一對(duì)應(yīng)，它的生命周期如下：

1.Create Volume：Controller Plugin 收到創(chuàng)建請(qǐng)求之后會(huì)在 ZBS 中創(chuàng)建一個(gè) iSCSI LUN，如有必要?jiǎng)t會(huì)自動(dòng)再創(chuàng)建需要的 Target，ZBS 的實(shí)現(xiàn)中，iSCSI LUN 以及所屬的 Target 均為邏輯對(duì)象，不與物理磁盤(pán)綁定。一個(gè)集群中允許創(chuàng)建 4096 個(gè) Target，每個(gè) Target 中最多允許創(chuàng)建 255 個(gè) LUN，多個(gè) CSI Volume 會(huì)處在相同的 Target 內(nèi)；

2.Controller Publish Volume：目前 Kubernetes 使用 Open iSCSI 作為節(jié)點(diǎn)上的數(shù)據(jù)接入服務(wù)，Open iSCSI 在掛載 Target 時(shí)，會(huì)將所有 Target 內(nèi)的 LUN 均掛載到主機(jī)上作為一個(gè) Block Device（例如 /dev/sdx 這樣的磁盤(pán))。為了避免讓主機(jī)察覺(jué)到不需要也不應(yīng)該訪問(wèn)的 LUN，ZBS 采用了近似 LUN Masking 的機(jī)制來(lái)達(dá)到這個(gè)目標(biāo)。在初始 Volume 對(duì)應(yīng)的 LUN 在創(chuàng)建時(shí)，不會(huì)允許任何 iSCSI initiator?（iSCSI 的協(xié)議客戶(hù)端）發(fā)現(xiàn) LUN。在 Controller Publish Volume 階段，ZBS Controller Plugin 會(huì)將指定 Node 上的 initiator 注冊(cè)到 LUN 上，在這之后，關(guān)聯(lián) Node 的 iSCSI discovery 機(jī)制才可以在 Target 內(nèi)發(fā)現(xiàn)并訪問(wèn) LUN；

3.Node Stage Volume：ZBS Node Plugin 會(huì)將 LUN 通過(guò) Open iSCSI 命令掛載至主機(jī)，呈現(xiàn)為一個(gè)磁盤(pán)；

4.Node Publish Volume：ZBS Node Plugin 對(duì)磁盤(pán)進(jìn)行格式化（如果磁盤(pán)之前尚未被格式化，如已經(jīng)格式化則為跳過(guò)對(duì)應(yīng)步驟），將磁盤(pán) Mount 到主機(jī)上提供給 Container 使用；

5.Node Unpublish Volume：ZBS Node Plugin 將磁盤(pán)上的文件系統(tǒng) Unmount；

6.Node Stage Volume：ZBS Node Plugin 在主機(jī)上將斷開(kāi)磁盤(pán)的 iSCSI 鏈接；

7.Controller Unpublish Volume：ZBS Controller Plugin 向 ZBS 后端注銷(xiāo)指定 Node 在 LUN 上的訪問(wèn)權(quán)限；

8.Delete Volume：ZBS Controller Plugin 請(qǐng)求 ZBS 刪除對(duì)應(yīng)的 LUN，LUN 所占用的數(shù)據(jù)空間將會(huì)在存儲(chǔ)系統(tǒng)中被回收。

ZBS CSI Driver 支持 Snapshot CRD 操作，Snapshot 的方式為 COW，相關(guān)請(qǐng)求僅涉及簡(jiǎn)單的元數(shù)據(jù)操作，所以關(guān)聯(lián)接口會(huì)以同步模式快速響應(yīng)。Snapshot 自身或者基于 Snapshot 創(chuàng)建的 Volume 都會(huì)立刻處于 Volume Ready 的狀態(tài)。

3 數(shù)據(jù)鏈路

K8s 和 ZBS 之間的 iSCSI 數(shù)據(jù)鏈路如下圖所示：

K8s 和 ZBS 之間的 iSCSI 數(shù)據(jù)鏈路

ZBS 使用 iSCSI Redirector 模式提供 iSCSI 接入服務(wù)，CSI Plugin 給 Driver 提供的 iSCSI 服務(wù)端地址為 iSCSI Redirector 地址，initiator 嘗試連接 iSCSI Server（Target 端，ZBS 中由 Chunk 提供 Target 服務(wù)）時(shí)，Redirector 將會(huì)采用的 hash 的方式引導(dǎo) initiator 重新連接向一個(gè)可用的 Chunk Server。

在重定向之后，所有的數(shù)據(jù)請(qǐng)求僅在 initiator 與 Chunk 之間進(jìn)行，無(wú)需經(jīng)過(guò) Redirectord。ZBS 集群中所有 Chunk Server 在處理 iSCSI 接入請(qǐng)求時(shí)是邏輯等價(jià)的，即任一 Chunk 均可以提供集群中的任一個(gè) Target LUN 的數(shù)據(jù)訪問(wèn)服務(wù)。重定向的方式可以有效的分散數(shù)據(jù)接入壓力，充分利用集群性能。

4 可靠與可用性

SMTX ZBS 在設(shè)計(jì)之初就以高可靠、高可用、高性能為目標(biāo)，在集群內(nèi)部采用多副本，靜默數(shù)據(jù)檢查自動(dòng)平衡和恢復(fù)等機(jī)制來(lái)保證數(shù)據(jù)的安全可靠。在這個(gè)基礎(chǔ)之上，K8s CSI 模式獲得比使用本地存儲(chǔ)更高的安全性。

異常處理

K8s 計(jì)算節(jié)點(diǎn)異常

Node A 上的 pod 將會(huì)被自動(dòng)在其他節(jié)點(diǎn)（Node B）上拉起，會(huì)重新經(jīng)歷 Node B 上 Publish Volume 至掛載的動(dòng)作。Node B 會(huì)接入 Chunk server 提供 Pod 關(guān)聯(lián)的 Volume 的 IO 服務(wù)，之前在 Node A 上已經(jīng)寫(xiě)入 Volume 中的數(shù)據(jù)不會(huì)受到損失。

Chunk 節(jié)點(diǎn)異常

如果是計(jì)算節(jié)點(diǎn)當(dāng)前連接的 Chunk 異常，則與 Chunk 節(jié)點(diǎn)間的鏈路將中斷，計(jì)算節(jié)點(diǎn)會(huì)重新向 iSCSI Redirector 服務(wù)尋求一個(gè)新的接入節(jié)點(diǎn)迅速恢復(fù)服務(wù)。通常情況下這個(gè)影響的時(shí)間為秒級(jí)。

如果非當(dāng)前連接的 Chunk 異常，可能會(huì)因?yàn)?IO 副本損失而產(chǎn)生短暫的延遲，iSCSI 鏈路本身不會(huì)受到影響，影響時(shí)間也為秒級(jí)。

iSCSI Redirector 節(jié)點(diǎn)異常

SMTX ZBS 提供 VIP（虛擬 IP）服務(wù)，可以保證集群中有且僅有一個(gè)節(jié)點(diǎn)會(huì)持有該 VIP。iSCSI Redirector 運(yùn)行在 VIP 節(jié)點(diǎn)上，當(dāng)它異常時(shí)。自然會(huì)替換到新的 VIP 節(jié)點(diǎn)提供 iSCSI Redirector 服務(wù)。ZBS 保證所有的節(jié)點(diǎn)提供的 Redirector 服務(wù)是等價(jià)的。

雙活與異地備份

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

5 整體部署形式

目前 SMTX 對(duì) CSI 支持兩種形態(tài)的部署形式，基于 VM 的融合模式與分離模式，后續(xù)將提供 SMTX K8s 原生融合模式的部署支持。

分離模式

K8s 和 SMTX ZBS 分別是獨(dú)立的物理集群，他們之間通過(guò)接入網(wǎng)絡(luò)互相關(guān)聯(lián)。接入網(wǎng)絡(luò)需要獨(dú)立于 K8s 中的業(yè)務(wù)網(wǎng)絡(luò)和 ZBS 使用的存儲(chǔ)網(wǎng)絡(luò)。

融合模式

融合模式下，K8s 運(yùn)行在 SMTX OS 提供的虛擬機(jī)上。通過(guò)接入網(wǎng)絡(luò)接入 SMTX OS 上的 ZBS 服務(wù)。這個(gè)部署方式可以更高效的利用物理資源。

Fred

baiyan