引言
隨着雲原生技術日益普及的今天，在 Kubernetes 上運行無狀態應用已經非常成熟，平滑擴展能力也很強，但對於有狀態的應用，數據需要持久化存儲，這還有很大提升的空間，面臨着很多挑戰。
雲原生存儲的挑戰
上圖是 CNCF 對於“在使用/部署容器的過程中遇到的挑戰”做出的調查報告。根據報告的結果，可以總結出雲原生存儲遇到的挑戰表現在以下幾個方面：
- 易用性：存儲服務部署、運維複雜，雲原生化程度低，缺少與主流編排平臺整合
- 高性能：大量應用 IO 訪問，IOPS 需求高，低時延，性能成爲應用運行效率瓶頸
- 高可用：雲原生存儲已經應用到生產環境，需要高可靠/高可用，不能出現單點故障
- 敏捷性：PV 快速創建、銷燬、平滑的擴展/收縮，PV 隨 Pod 遷移而快速遷移等
常見雲原生存儲解決方案
Rook-Ceph：Rook-Ceph 是一個可以提供 Ceph 集羣管理能力的 Operator，使用底層雲原生容器管理，調度和編排平臺提供的功能來執行其職責。
OpenEBS：OpenEBS 存儲控制器本身就運行在容器中。OpenEBS Volume 由一個或多個以微服務方式運行的容器組成。
優勢
1.與雲原生編排系統的融合，具有很好的容器數據卷接入能力； 2.完全開源，社區較爲活躍，網絡資源、使用資料豐富，容易入手；
劣勢
Rook-Ceph 不足：
- 性能差：IO 性能、吞吐、時延等方面都表現欠佳，很難應用在高性能服務場景；
- 維護成本高：雖然部署、入門簡單，但組件多，架構複雜，排錯困難，一旦運行中出現問題解決起來非常棘手，需要有很強的技術團隊加以保障；
OpenEBS-hostpath 不足：沒有高可用功能，單點故障； OpenEBS-zfs-localpv 不足：在磁盤上安裝 zfs，然後在 zfs上 創建 vol，也是沒有高可用功能；
因此多在企業內部測試環境，很少用於持久化關鍵應用數據，部署到生產環境中；
NeonIO 爲什麼適合雲原生存儲
NeonIO 簡介
NeonIO 是一款支持容器化部署的企業級分佈式塊存儲系統，能夠給 Kubernetes 平臺上提供動態創建（Dynamic Provisioning) 持久存儲卷（Persistent Volume) 的能力,支持 Clone、Snapshot、Restore、Resize 等功能，NeonIO 的結構圖如下：
NeonIO 包括的服務組件如下：
- zk/etcd: 提供集羣發現、分佈式協調、選 master 等服務
- mysql：提供元數據存儲服務，如 PV 存儲卷的元數據
- center：提供邏輯管理服務，如創建 PV 卷，快照
- monitor: 提供監控服務，能夠把採集監控指標暴露給 Promethus
- store：存儲服務，處理應用 IO 的功能
- portal：提供 UI 界面服務
- CSI：提供 csi 的標準 IO 接入服務
下面從以下幾個方面來看 NeonIO 爲什麼適合雲原生存儲：
易用性
-
組件容器化：服務組件、CSI、Portal 容器化
-
支持 CSI：提供標準的 IO 接入能力，可靜態、動態創建 PV
-
UI 界面，運維方便：
- 存儲運維操作界面化、告警、監控可視管理；
- 有基於 PV 粒度的性能監控，如 IOPS、吞吐量，可以快速定位到熱點 PV；
- 有基於 PV 粒度的 Qos，能夠保證用戶高優先級的服務質量；
-
與雲原生高度融合：
- 支持 Promethus，通過 ServiceMonitor 把 NeonIO 的採集指標暴露給 Promethus、Grafana，進行圖形化展示
- 同時 UI 界面可與 Promethus 對接，展示其他雲原生監控的指標，如 node-exporter 的磁盤 IO 負載、帶寬等
- 平臺化的運維方式，存儲的擴容、升級、災難恢復運維操作、只需要 Kubernetes 的一些命令即可實現，不需要額外掌握過多的存儲相關的運維知識
- 服務發現、分佈式協調支持 etcd、元數據的管理，使用 CRD 的方式
-
一鍵式部署：：
helm install neonio ./neonio --namespace kube-system
- 部署簡單靈活：和 Rook-Ceph 對比：
| 功能 | NeonIO | Rook-Ceph |
|---|---|---|
| 節點規劃部署 | 通過對對應節點打 label | 通過修改 cluster.yaml，需要配置節點 IP 配置那些服務 |
| Quick Start | 總共 4 步:<br>1.檢查確保有可給供 neonio 的設備；<br>2.檢查是否已經安裝 QBD；<br>3.添加 helm repo；<br>4.安裝部署： helm install neonio ./neonio --namespace kube-system | 總共 5 步<br>1.檢查確保有可給供 ceph 的設備；<br>2.檢查是否已經安裝 RBD；<br>3.apt-get install -y lvm2<br>4.下載代碼：git clone --single-branch --branch master<br>https://github.com/rook/rook.git<br>5.cd<br>rook/cluster/examples/kubernetes/ceph<br>kubectl create -f crds.yaml -f common.yaml -f operator.yaml<br>kubectl create -f cluster.yaml |
| 單機 all-in-one | helm install neonio ./neonio --namespace kube-system --set sc.rep_count=1 --set center.servers=1 -- | cd<br>rook/cluster/examples/kubernetes/ceph<br>kubectl create -f crds.yaml -f common.yaml -f operator.yaml<br>kubectl create -f cluster-test.yaml<br>使用區別與集羣部署時的另一個配置 cluster-test.yaml 進行部署，不能做到配置共用 |
| RDMA/TCP | helm install neonio ./neonio --namespace kube-system --set store.type=RDMA | ceph 本身支持 RDMA，rook-ceph 不支持 |
| 管理、存儲網絡分離/共有 | helm install neonio ./neonio --namespace kube-system --set store.port=eth0 --set rep_port.port=eth1 | ceph 本身 pubic、cluster 網口的分離公用，rook-ceph 適配複雜 |
高性能
性能單 PV IOPS 100K，時延亞毫秒。
-
全閃的分佈式存儲架構
- 集羣中所有節點共同承擔壓力，IO 性能隨着節點增加而線性增長
- 存儲介質支持 NVME SSD
- 支持 RDMA：通過高速的RDMA技術將節點連接
-
極短的 IO 路徑：拋棄文件系統，自研元數據管理系統，使 IO 路徑極短
- 使用 HostNetwork 網絡模式
好處：
- Store CSI Pod 使用 HostNetwork，直接使用物理網絡，減少網絡層次
- 管理網絡、前端網絡、數據同步網絡分離，避免網絡競爭；
高可用
-
服務組件可靠性與可用性
- 管理服務默認使用 3 副本 Pod,副本數可以配置，推薦使用 3/5 副本，任何一 Pod 因故障無法提供服務，還有其他 Pod 提供服務
- 使用探針檢測 Pod 服務是否可用，是否存活，檢測到 Pod 服務部可用剔除組件服務，檢測到 Pod 死掉後重啓 Pod，使其重新啓動服務
-
數據的可靠性與可用性
- Volume 分片爲 Shard
- 每個 Shard 獨立選擇存儲位置
- 每個 Shard 的 3 個副本存儲在不同的物理節點上
- 寫入時同步寫入 3 個副本，強一致
- 讀取時只從主副本讀
- 副本數按 volume 可配
敏捷性
- Pod 跨節點重建高效：2000PV 的掛載/卸載 16s
- 批量創建 PV 能力：2000PV 的創建 5min
NeonIO性能表現
Teststand: NeonIO hyper-converged all-in-one cluster (3 nodes, 192.168.101.174 - 192.168.101.176)
Note: All tests use NVMe SSDs. Volume size = 1TiB. Performance tool: https://github.com/leeliu/dbench
圖中黃色表示的是 NeonIO，第一張圖縱座標是 IOPS，第二張圖縱座標是毫秒，從結果來看，無論是單副本還是 3 副本，NeonIO 在 IOPS、時延都有明顯的優勢。
NeonIO應用場景
- Devops 場景：批量快速創建/銷燬 PV 能力，2000PV 創建 5min
- 數據庫場景：WEB 網站後端數據庫 MySQL 等提供穩定的持久化存儲，提供高 IOPS、低時延
- 大數據應用分析場景：提供超大容量，PV 可擴容到 100TB
本文由博客一文多發平臺 OpenWrite 發佈！