引言
隨著云原生技術日益普及的今天，在 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 步: 1.檢查確保有可給供 neonio 的設備； 2.檢查是否已經安裝 QBD； 3.添加 helm repo； 4.安裝部署： helm install neonio ./neonio --namespace kube-system |
總共 5 步 1.檢查確保有可給供 ceph 的設備； 2.檢查是否已經安裝 RBD； 3.apt-get install -y lvm2 4.下載代碼：git clone --single-branch --branch master https://github.com/rook/rook.git 5.cd rook/cluster/examples/kubernetes/ceph kubectl create -f crds.yaml -f common.yaml -f operator.yaml 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 rook/cluster/examples/kubernetes/ceph kubectl create -f crds.yaml -f common.yaml -f operator.yaml kubectl create -f cluster-test.yaml 使用區別與集群部署時的另一個配置 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 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/285806.html
標籤：其他