LiteIO 是一款高性能、易擴展的雲原生塊設備服務，專為超融合架構下的 Kubernetes 設計。在螞蟻集團內部孵化 3 年並大規模應用在生產環境，為螞蟻集團全數據型、存儲型產品提供穩定、高效、易擴展的磁盤服務。

LiteIO 是將本地磁盤/邏輯卷，通過網絡的方式共享給遠程其他服務器使用，結合雲原生 Kubernetes 的調度，將一系列磁盤統一管理、池化的通用技術。點對點的技術設計，相較傳統分佈式存儲，有效地控制住硬件故障所帶來的爆炸半徑，同時去除存儲冗餘，有更多使用空間。

設計背景

在降本增效的時代，FinOps 顯得格外重要，尤其像螞蟻集團這種存儲服務器規模龐大的體系，全局 1% 的存儲利用率提升都會帶來巨大的成本經濟收益。因此需要再成本優化、保證通用性的同時穩定性不降。

數據庫是一種重 IO 的軟件系統，對於 IO 的穩定性和性能要求極高，一般生產系統都將數據庫部署在本地磁盤的服務器上，這將帶來兩個問題：

• 利用率不均：IO 密集型和計算密集型的 workload 不同，這就會出現一台機器計算用完而存儲富裕，亦或者存儲用完計算還富裕，且通過調度也很難做到全局最優解。
• 擴展性差：當出現存儲不足，需要 scale up 存儲，不得不通過遷移的手段換一台更大存儲的服務器，拷貝數據的過程長。

傳統分佈式存儲也是一種不錯的解決方案，但在數據庫領域，它將帶來幾個方面的問題：

• 副本數上升（成本）：分佈式存儲的優勢在於通過 EC、多副本技術將存儲池化，對於單硬件故障有很好的保護，但通過 EC、多副本技術造成單份數據副本在此架構下副本數將大於1，往往副本數在1.375~2之間。數據庫作為業務服務重要的組成，往往在上層有異 AZ、異地容災的要求，在另一個 AZ 已經有數據庫層面的備副本。總數據副本數會增加。
• 爆炸半徑大（穩定性）：分佈式存儲一般有一層中心式的Meta層，故障將帶來全局性異常。

設計思路

LiteIO 採用去中心化的設計思路，基於 SPDK 數據引擎以及高性能 NVMe-over-Fabric 協議，將計算節點直接連到遠程存儲節點，通過高效的協議和後端 I/O 輪詢，提供接近本地磁盤的高性能。點對點的設計配合 K8S 的調度控制，有效的控制單硬件故障所影響的服務。

FinOps基於

LiteIO，可以將服務器中無法分配的存儲，按需分給遠程計算節點使用，同時全局配合調度，將全局存儲池化，從而提升全局的存儲利用率。例如有兩種型號的服務器，計算密集型 96C 4T，存儲密集型 64C 20T，假設存儲機型的 CPU 已經分配完還剩 5T 磁盤，計算機型還有 CPU 但無磁盤可分，使用 LiteIO 可以將計算機型的 CPU +存儲機型的剩餘磁盤組合成新的容器提供服務，同時提升了計算、存儲利用率。

通用存儲計算分離

LiteIO 是一個通用的存儲服務技術，作用於存儲邏輯卷，配合 K8S 上層容器或應用看到的和本地磁盤無差別，不論是直接讀寫塊設備 bdev 還是將塊設備做成任何文件系統均可以，不需要上層服務做任何修改，不論是 OceanBase、MySQL、PostgreSQL 這樣的數據庫，或者 Java、Python、Go 寫的應用服務均可以將它用作一塊普通磁盤使用。

Serverless

LiteIO 的通用的存儲計算分離能力，使得 Scale 變得無比簡單。配合感知與調度系統，部署一個 MySQL 實例就天然具備了 Serveless 能力。當 MySQL 的算力不夠時，通過 LiteIO 將 MySQL 存儲掛到一台更大算力的容器即可快速完成 scale up。當 MySQL 存儲空間不足時，從其他存儲節點掛一塊磁盤即可完成無損擴容。

技術特性

高性能協議

LitelO 使用 NVMe-oF 協議來提升性能，NVME-oF 協議可以充分利用新興 NVMe 設備的固有並行性和多隊列功能。而 iSCSI 在訪問 NVMe SSD 時，性能損失高達 40％，並在協議轉換等其他操作時也會消耗多於 30％的 CPU 資源。NVMe-oF 在性能方面優於 iSCSI，可以提供接近本地連接的 NVMe SSD 的性能。因此，在 LiteIO 中採用 NVMe-oF 可以最大程度地減少訪問存儲池中的存儲資源時的開銷，以提供接近原生磁盤的高性能。LiteIO 採用了 NVMe over Fabric（TCP）作為遠程存儲協議，以便集羣中的其他節點訪問存儲資源。

簡化的 IO 鏈路

傳統分佈式存儲架構下，一個 Write IO 需要經過查詢元數據、寫元數據、寫多副本數據三個過程，整個過程需要多次網絡交互；而在 LitelO 架構下，由於單副本機制，點對點訪問，前端 bdev 和後端 vol 一一映射，不需要額外的 rootserver 或者 metaserver 來管理全局元數據，IO 鏈路中只有一次跨網絡訪問，同時也不需要考慮多副本寫帶來的數據傳輸延遲，數據放大的問題，使得 LitelO 有更高的 IO 吞吐和更低的 IO 延遲

零拷貝

在訪問本地磁盤時，I/O 請求和數據在 NoF-Initiator 和 NoF-Engine 之間通過 tcp-loopback 傳輸，但是這個過程涉及許多冗餘的數據拷貝。為了消除這些拷貝並減少 CPU 開銷，我們提出了一種新穎的零拷貝傳輸方式，用於 LiteIO 的本地訪問。對於 I/O 請求，零拷貝傳輸採用 NoF-Initiator 和 NoF-Engine 之間的共享內存。對於數據，我們提出了一種 DMA 重映射機制，使本地存儲設備可以直接訪問應用程序緩衝區。零拷貝傳輸拋棄了 TCP 堆棧，並消除了用户緩衝區和內核之間的冗餘數據拷貝，實現了訪問本地存儲資源時接近本地性能的效果。

熱升級

充分考慮到作為數據鏈路上的關鍵一環的 LiteIO 也會面臨功能升級，我們實現了在升級 LiteIO 的過程中，讓前端業務無感，IO 短時間抖動（<100ms），同時機頭掛載的 nvme 盤符不會發生改變。Target 整體框架如下圖所示，在熱升級期間必須保持 nvmf 的網絡連接不可中斷，否則 host 側會感知並去重連或者刪除盤符，熱升級採用舊的 target 程序 fork 新的 target 程序並加載新的二進制文件來實現，整個熱升級過程中 IO 不可丟失，新舊進程的切換速度要快。基於熱升級框架的簡單性設計原則，熱升期間下圖中綠色的 TCP 或 RDMA 連接為必須保持的上下文，其他模塊均無需保存上下文狀態，網絡連接的保持通過父子進程繼承文件描述符的方式實現。

熱遷移

卷熱遷移特性是為了在不影響業務的情況下，將卷的數據從原 Target 遷移到新的 Target，當遷移完成時由 Host 端完成鏈路的切換，從而實現業務無感切換到新的 Target。熱遷移過程中，將原 Target 的數據發送到新 Target 採用的方法是多輪循環迭代。每一輪開始前都會從卷獲取一份 data map，然後根據這個 map 進行數據的拷貝。初始輪可能需要拷貝較多的數據，後續每一輪只需要拷貝上一輪遷移過程中新修改（write, discard）的數據。在保證遷移帶寬大於新寫入數據帶寬的前提下，經過多輪拷貝後原 Target 和新 Target 之間的數據差異會逐漸縮小，從而可以停 IO 進行最後一輪的拷貝。

快照

LiteIO 對接了 CSI 的 Snapshot 相關的接口，允許用户使用 K8S 社區的 Snapshot 資源對 LiteIO 卷創建快照。快照能力與底層數據引擎有關，LiteIO 支持兩種引擎：LVM 和 SPDK。LVM 的快照能力是 VG/LV 提供的， NoF-Engine 的快照能力是 SPDK LVS 提供的。LVM 和 SDPK 都是單機引擎，要求 Snapshot 和 原始 LV 必須在同一台機器，這就意味着，在創建原始 LV 時，就需要預留一定空間給快照，如果沒有預留空間，則無法保證創建 Snapshot 一定成功。LiteIO 對接了 CSI 的 ExpandVolume 相關接口，用户可以通過修改 PVC 磁盤空間，實現磁盤在線擴容。對於 LVM 引擎，LV擴容無需修改，NoF-Engine 暴露遠程盤的流程中新增了 bdev_aio_resize RPC 調用，實現了遠程盤的在線擴容。擴容同樣有一些限制，原因也和快照一樣，由於LVM, SPDK都是單機引擎，無法保證單機上有足夠空間擴容。

多盤

點對點的數據鏈路模式，不可避免還是會產生一些存儲資源碎片。LiteIO 支持將這些碎片組合起來，變為一個卷供業務使用。這也帶來一個故障率提升問題，假設提供碎片的任意一個節點故障，則這個卷不可用。內部恰好有這樣一個業務 LDG 可以容忍這樣的故障率，物盡其用。LDG(logic data guard) 設計旨在構建常態化邏輯主備數據庫，提供一站式的主備庫生命週期管理和應用使用管控平台，為提升穩定性，減小運維過程中由於升級，維護，意外等產生的數據風險進行規避, 同時提升數據操控的能力。

Thin provisioning

LitelO 還提供 Thin provisioning 能力，在單機維度實現存儲的超賣，適合於像 Mysql 等存儲非預填充空間的存儲產品使用，Thin provisioning 結合熱遷移能力，可以在單機存儲空間不足時，快速無縫遷移數據到空間空閒的節點；由於 LitelO不是分佈式存儲架構，對 Thin provisioning 功能的使用需要精確控制超賣比例和和超賣資源總量，保障空間不足時能快速遷移，避免業務受損

實踐落地

LiteIO 廣泛地應用在螞蟻集團數萬台生產服務器，整體提升了 25% 的存儲利用率，極大地優化了資源服務成本。與本地存儲相比，LiteIO 帶來的額外 IO Latency 僅約為 2.1 us。其通用的存儲計算分離架構，不僅服務於數據庫產品，同時也為螞蟻其他計算產品、應用服務提供了存儲計算分離以及 Serverless 的能力。配合熱升級、熱遷移、Kubernetes 生態，使其在日常運維中不增加額外的運維負擔。快照、多盤聚合等能力讓其有更多靈活的使用與玩法。針對 LiteIO 在螞蟻集團的最佳實踐，後續有系列文章分享，敬請期待。

加入我們

你是否正在考慮降本增效的 FinOps 項目？你是否也在考慮通用存儲計算分離架構設計？你是否也是存儲技術的愛好者？

歡迎你參與 LiteIO 開源社區，我們期待你的加入。

開源項目倉庫：https://github.com/eosphoros-ai/liteio