作者 | Eric Li (壯懷)  阿里巴巴雲原生儲存負責人

# 引言
隨著雲原生應用對可遷移性、擴充套件性和動態特性的需求，對雲原生儲存也帶來了相應的密度、速度、混合度的要求，所以對雲端儲存基本能力之上又提出了在效率、彈性、自治、穩定、應用低耦合、GuestOS 最佳化和安全等方面的訴求。參考[《雲原生儲存和雲端儲存有什麼區別？》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487392&idx=1&sn=747e9dd0c6d76292935f25dcec10f37b&chksm=fae5046fcd928d792f4958c5ac50cce77d87b5389d9f20347c0fe4c96600fc065247bd8dd248&token=87173660&lang=zh_CN#rd)

新的企業負載／智慧工作負載容器化、遷雲、儲存方面遇到的效能、彈性、高可用、加密、隔離、可觀測性及生命週期等方面的問題，不但需要儲存產品層次的改進，還需要在雲原生的控制／資料平面的改進，推進雲原生儲存和雲端儲存的演進。下文將分別介紹一下問題場景及問題，探討可行的解決方案，最終可以得出雲原生儲存、雲端儲存目前可以做什麼和未來還需要做什麼。

# 儲存效能

## 長時延增加

### 場景
高效能運算場景中，集中處理批次資料，透過容器叢集，同時啟動數千 Pod，彈出數百 ECS 對共享性檔案系統讀寫。

### 問題
重負載終負載下時延增加，高延遲毛刺增多，讀寫穩定性不足。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/342f8e7911d549ffb3990c1298d9c1fc.png)

### 解決方案

- 分散負載到多檔案系統，透過容器編排分散 IO 到多檔案系統
- 儲存產品的盤古 2.0 改造

## 集中式高吞吐寫對共享儲存池衝擊

### 場景
高效能運算場景中，集中處理批次資料，10Gbps 讀寫請求進入同一儲存叢集。

### 問題
同一儲存叢集中的頻寬擠佔，造成訪問質量下降。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f3fb8b71c05047a393a22b49fd72da6b.png)

### 解決方案

- 分散負載到多檔案系統和多個儲存叢集／多個可用區，透過容器編排分散 IO 到多檔案系統；
- 使用獨佔高效能並行檔案系統。

## 峰值吞吐不足
### 場景
大規模生物資料處理， 檔案數目少，峰值吞吐高 10Gbps-30Gbps，請求密集 1W／s。

### 問題
接近獨佔叢集的極限頻寬。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/d47e75edbb04493a897607f88b1c4bc0.png)

### 解決方案

- 讀寫分流，分流讀請求到 OSS，寫請求負載分流到獨佔檔案系統和本地／遠端塊儲存，透過容器編排分散 IO 到多檔案系統；
- 使用應用層分散式快取降低網路讀 IO；
- 儲存產品的盤古 2.0 改造。

## 時延增加導致 GPU 等待

### 場景
多機多卡 GPU 訓練，直接讀取 OSS 資料，讀密集型。

### 問題
時延增加導致 IOwait 和 GPU 等待。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/053369c55b104ff2a2080d30ba462c92.png)

### 解決方案

- 應用層透明 POSIX 讀訪問 OSS；
- 使用應用層分散式快取降低網路讀 IO。

# 儲存彈性

## 場景

- 資料庫擴容, MySQL and etc；
- 後設資料管理應用線上擴容 Zookeeper／etcd；
- 本地盤儲存容量無法擴容。

## 解決方案

- 雲盤線上擴容，應用控制面檔案系統／邏輯卷離線，線上擴容能力；
- 單機雲盤掛載密度；
- 儲存產品 ESSD 的替換使用。

# 儲存高可用
## 場景

- 應用運維，系統運維；
- 塊儲存隨容器遷移的穩定性和可發現性。

## 解決方案

- 控制平面宣告式儲存快照，備份，定時快照備份，本地快照加速備份和恢復；
- 控制平面雲盤 SerialNum 的可發現性改造。

# 儲存的加密

## 場景

- 使用者應用的全鏈路資料加密需求；
- 作業系統盤加密。

## 解決方案

- 產品儲存的 CMK，BYOK 支援
- 控制平面的加密宣告支援
- RAM 許可權的最小化控制

# 儲存的隔離性

## 場景

- 單盤多應用共享，單機日誌盤塊儲存切分
- 單塊本地盤／雲盤吞吐能力不足
- 檔案系統多租戶環境的容量配額
- 叢集級檔案系統共享訪問的許可權控制

## 解決方案

- 控制面 LVM 切分，控制面塊儲存 blkio buffer IO 應用級限速
- 控制面 LVM 多盤聚合和條帶
- 儲存產品共享檔案系統的目錄級 Quota
- 控制面檔案系統的目錄級 ACL

# 儲存的可觀測性

## 場景
多租戶 Zookeeper／etcd，租戶／應用級的 IO 指標監控和預警。

## 解決方案

- 控制面應用級 IO Metrics 採集能力
- 控制面裝置級 IO Metrics 採集能力
- 控制面掛載點級 IO Metrics 採集能力

# 儲存的生命週期

## 場景
共享檔案系統/快取系統的宣告式建立和刪除。

## 解決方案

- Operator: 雲盤／本地盤 （TiDB）
- Operator: 檔案系統，CPFS
- Operator: 物件儲存

# 雲原生儲存 v2
針對以上在新的計算模式下，儲存方面遇到的效能，彈性，高可用，加密，隔離，可觀測性，生命週期等方面的問題，不但是需要儲存產品層次的改進，更需要在雲原生的控制／資料平面的改進，在不久的將來實現穩定，安全，自治，和效率並舉的雲原生儲存 v2。

- 穩定：阿里雲端儲存的全品類支援可觀測性， Flexvolume and CSI plugins／IO metrics (CSI for 1.14)；
- 安全：全連路資料儲存的可靠／可信儲存支援，CSI 快照加密，系統盤加密；
- 自治：雲盤快照 /本地快照 ，離線線上的儲存擴容能力, 後設資料自動發現；
- 效率：I/O 隔離 、可伸縮性／雲盤再次分割提升密度/分散式儲存快取。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/db7f20409e114cc28ef1984115801a45.png)

需要在雲原生應用層、儲存雲產品層、底層儲存適配和儲存核心層都需要做相應的改進和提升才有可能提供更加穩定，安全，自治和高效的面向應用的雲原生儲存。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/c4a70885525e491a9e1eafabb9b9cd0c.png)

# 總結

- 雲原生儲存是雲端儲存 UI 和效率等能力的集合；
- 分層儲存，不重新發明輪子；
- 新的工作負載推進雲原生儲存和雲端儲存的演進，雲原生控制平面實現效率，自治方面能力，從資料面提升儲存穩定和減小安全隱患，雲端儲存繼續夯實效能，容量，彈性，密度等基礎能力，共建雲原生環境下的儲存生態。

_在雲原生儲存 v2 的演進過程中，仍然需要容器團隊和儲存團隊，通力合作，共同提升的雲原生時代的儲存能力。_

![3 群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/e48d00c9a4d94049baefe238a714a211.png)

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/S44AA5JCYtOokMWNMqWoow)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

實際場景中，雲原生儲存面臨的 7 個挑戰

相關文章