現狀
當前，雲原生已經成為應用開發者在選擇架構設計時的首選。雲原生讓應用開發者可以將所有精力都集中在開發業務邏輯本身，這極大降低了應用開發者的負擔。
而應用系統的敏捷性、擴充套件性、可靠性、高可用等，則由基礎設施軟體和運維團隊共同承擔。一方面，運維團隊需要利用基礎設施軟體，快速響應業務系統提出的部署、擴容、遷移等需求，另一方面，也要時刻保持業務系統和基礎設施軟體的穩定執行。這為基礎設施軟體和運維團隊都帶來了更大的挑戰。
如何正確的為基礎架構軟體進行設計和選型，就成為了運維主管們最具挑戰的任務之一。
雲原生場景下的儲存系統
儲存系統一直以來都是基礎設施軟體中的核心之一。無論業務採用什麼樣的執行環境和架構，都離不開儲存系統的支撐。
在過去的 30 年中，業務系統的執行環境經歷了巨大的變化，從單獨部署的物理機，小規模部署的虛擬化環境，大規模部署的雲環境，以及目前的 K8s 平臺。在這個變革的過程中，業務系統對平臺敏捷性的要求越來越高。在物理機時代，運維人員需要手動配置儲存系統和部署業務系統，業務上線以周為單位。而在雲原生時代，每分鐘都可能釋出新的應用版本，每天都可能有大量的業務要上線。
這意味著，雲原生時代的儲存系統，除了要滿足效能、穩定性、可靠性的要求以外，還要滿足業務系統對敏捷性的要求，能夠透過統一的編排系統配合業務上線，並且可以實現快速擴容。同時，為了減輕運維管理員的工作負擔，儲存系統自身的自動化運維能力，也成為運維團隊關注的核心焦點。
圖 1。 使用/部署容器的主要挑戰（圖片來源於 CNCF 報告）
從 CNCF 的調查可以看出，目前儲存系統依然是雲原生場景使用和部署中面臨的最主要障礙之一。接下來我們來介紹一下雲原生場景下不同儲存方案的優劣點。
本地磁碟
本地磁碟是最容易想到的方式，也是從物理機時代就一直在使用的方式。
在伺服器的硬碟槽上插上硬碟，並利用 HBA 卡或軟體的方式製作 RAID，劃分邏輯卷，格式化成某種檔案系統後，掛載到容器中。
由於磁碟和應用系統中間的 IO 路徑最短，本地磁碟可以提供最佳的效能。同時 RAID 提供了一定程度的可靠性的保證，可以避免因單個磁碟故障而導致的資料丟失。因此，目前有大量使用者採用這種方式為有狀態的應用提供儲存服務。
然而本地磁碟方案也存在著巨大的缺陷。
首先，本地磁碟無法提供節點級別的高可用，當物理節點發生故障時，由於資料都儲存在故障節點上，所以應用無法被恢復到其他節點。如果業務系統有節點級高可用的要求，則必須由業務系統自己實現資料層面的高可用，這極大的增加了業務系統的複雜度。
其次，本地磁碟在敏捷性上也無法滿足業務需求，業務使用的儲存空間受限於本地磁碟的大小，如果達到磁碟空間的上限後難以擴容。部署 RAID 也是相當耗時的操作，難以實現在短時間內部署大量的應用系統。
此外，該方案無論是部署還是故障後的修復，都需要大量人力的參與，這使得本地儲存方案的運維成本非常高。同時由於節點間的儲存空間無法共享，也很容易造成儲存空間的浪費。
總的來說，本地磁碟的方案只適合在業務容器化的初期階段進行小規模試用，難以在大規模場景下被廣泛使用。
集中式儲存
集中式儲存提供了可遠端訪問共享儲存的能力。和本地磁碟的方案相比，集中式儲存解決了應用系統高可用的問題，當業務系統所在的伺服器發生故障時，由於資料不再儲存在伺服器本地，而是儲存在遠端的共享儲存中，所以可以在其他節點上把應用拉起來，以實現業務系統的高可用。此外，由於資料集中儲存，也一定程度解決了本地儲存對磁碟空間浪費的問題。
很多商用儲存都採用集中式儲存架構，除了基本的資料讀寫能力外，還提供了很多高階功能，包括快照、克隆、容災等等，進一步提升業務資料的可靠性。
然而集中式儲存的架構決定了它不適合雲原生的場景。
集中式儲存採用儲存控制器加盤櫃的形式，控制器負責提供效能和儲存功能，盤櫃提供可擴充套件的儲存容量。
儘管集中式儲存可以為單個業務系統提供較高的效能保證，但是當面臨大量業務併發訪問時，儲存控制器則成為了效能瓶頸。如果想要滿足大量業務對效能需求，需要採用多套集中式儲存系統，儲存系統的管理成本也會急劇上升。
此外，由於集中式儲存誕生在幾十年前，在設計上就沒有把敏捷性和運維便利性考慮進去，無法應對短時間內大量 Volume 的併發建立和銷燬操作，無法滿足業務系統對敏捷性的要求。
分散式儲存
分散式儲存的誕生就是為了解決集中式儲存無法解決的問題。
分散式儲存天然具有橫向擴充套件能力，在效能和高可用方面遠優於集中式儲存，非常適合應對大規模虛擬化場景。與此同時，分散式儲存也逐漸具備了企業級儲存的能力，包括快照、克隆等等。
不過，儘管分散式儲存在架構上具備眾多優點，但在實現難度上具備非常大的挑戰，並不是所有的分散式儲存都能夠充分發揮出分散式架構的優勢。在實際的使用過程中，大部分分散式儲存的效能和穩定性都難以達到生產級別的標準，這使得很多運維團隊不敢輕易地部署分散式儲存產品。
總結
圖 2。 不同儲存方案對比
雲原生有狀態應用對儲存系統的需求
談儲存技術無法脫離應用場景。在雲原生架構下，大部分業務系統不會處理資料儲存的邏輯，而是儘可能將資料儲存和處理能力交給資料庫來完成。
目前越來越多的資料庫也在採用雲原生架構，資料庫迎來了雲原生時代。雲原生資料庫將例項執行在容器中，具備了快速部署，快速擴容的能力。同時，雲原生資料庫也採用了“存算分離”的架構，將資料庫計算邏輯和儲存邏輯進一步進行分離，儲存能力交給更專業的儲存系統完成，資料庫只專注在資料庫的業務邏輯處理。
在某種程度上講，我們可以說雲原生時代的有狀態應用，大部分指的就是“雲原生資料庫”。接下來，我們分兩種典型的資料庫型別進行介紹。
交易型資料庫（OLTP）
常見的 OLTP 資料庫有 MySQL，PostgreSQL 等，通常承載的都是核心交易類業務，對儲存系統的資料可靠性、效能要求極高。交易類業務本身對延遲非常敏感，所以儲存系統的效能直接決定了 OLTP 系統能提供的能力。儲存系統的頻寬越高、延遲越低，OLTP 能提供的 TPS 越高。
每一套業務系統通常都會有 N 套獨立的 OLTP 資料庫作為業務支撐。由於業務系統會頻繁的進行部署以及擴容，所以支撐 OLTP 的儲存系統必須具備很高的敏捷性，可以快速提供資料庫對儲存空間的需求，同時也要方便的進行擴容等操作。
大部分 OLTP 資料庫採用塊儲存系統作為資料儲存系統，因為塊儲存通常可以提供最佳的效能。此外，商業塊儲存還提供了快照、克隆等技術，可以很好地保證資料庫業務的延續性。
分析型資料庫（OLAP）
OLAP 資料庫主要用在資料分析場景，對儲存系統的可靠性以及延遲的要求都不像 OLTP 資料庫那麼高，且因為資料量巨大，所以對儲存成本也非常敏感。
為了支撐 OLAP 對儲存成本的要求，儲存系統通常採用 EC 技術，以降低資料儲存的成本。而考慮到檔案介面難以支撐百億級別的檔案數量，所以 OLAP 使用的儲存系統通常採用物件介面，例如 S3 介面。
OLAP 系統對敏捷性沒有特殊的需求，一旦部署好後，最常見的運維操作是擴容，並不會對資料庫頻繁的進行重新部署和銷燬操作。
基於以上因素，分析型資料庫通常採用支援 EC 的物件儲存作為資料儲存服務，透過 S3 介面訪問資料。
總結
圖 3。 OLTP 和 OLAP 對儲存系統的不同要求
多雲環境對儲存系統帶來的新挑戰
隨著雲技術越來越成熟，越來越多的企業面臨多雲的需求：部分對資料安全不敏感且具有大量網路流量的業務需要使用公有云服務，而對資料安全性和服務穩定性要求較高的業務需要使用私有云服務。
公有云和私有云在產品設計理念上完全不同，產品的使用方式、運維方式、服務質量、產品引數也完全不同。即使同樣是公有云或者私有云，不同的服務提供商之間也存在著巨大差異。多雲的環境，對企業的運維團隊提出了巨大的挑戰。
而云原生架構的誕生，就是為了應對多雲的挑戰：開發者在設計雲原生應用時，只需要關注應用被如何建立和部署，無需關注在哪裡執行。
然而儘管目前有相當多的開發者採用了雲原生的架構設計應用系統，但是對於基礎架構軟體來說，目前還是由不同的雲廠商來提供。基礎架構的運維人員需要為不同服務商提供的儲存系統，準備不同的運維方式，這極大的增加了運維人員的負擔。
由此也誕生一個新的儲存系統類別：雲原生儲存系統。雲原生儲存系統可以良好的執行在各種不同服務商提供的公有云環境或私有云環境，並且為運維人員提供相同介面和運維方式。雲原生儲存系統可以極大的降低運維團隊的負擔。
雲原生儲存有什麼不同
此處我們以 IOMesh 的架構圖作為示例，說明雲原生儲存的特點。
圖 4。 IOMesh 產品架構圖
雲原生儲存不僅僅可以做到支援在公有云和私有云執行，而且提供了容器化部署、自動運維、宣告式介面等特徵，讓使用者可以採用和運維其他雲原生應用一樣的方式對儲存系統進行部署、運維和管理。
除此之外，雲原生儲存還需要能夠很好地和其他雲原生基礎設施配合，例如雲原生資料庫，使得雲原生資料庫可以真正的在公有云和私有云都能夠得到一致的使用者體驗。
如何選擇雲原生儲存
雲原生儲存也是儲存系統，所以儲存系統所必備的可靠性，效能，高可用等等特點都是必不可少的。
除此之外，“雲原生”對儲存系統提出了更高的要求。
儘量減少環境依賴
雲原生儲存系統應儘量不對軟硬體環境存在任何依賴，例如對核心的依賴，對特定的網路裝置和磁碟型號的依賴等等。只有儘量少的依賴，才能夠做到最大的適配性。
避免資源消耗過高
雲原生儲存系統以容器的形式和業務系統混合部署在容器平臺上。如果儲存系統佔用過多的計算資源（CPU、記憶體），則會導致整體投入成本太高。
宣告式運維方式
儲存系統應支援透過宣告式的介面進行運維管理，同時支援一定程度的自動化運維，包括線上擴容、升級等等。當發生硬體故障時，儲存服務可以自動恢復，以保證業務系統不受影響。
雲原生生態
雲原生儲存系統應該可以很好地和雲原生的運維生態系統結合，包括監控、報警、日誌處理等待。
雲原生儲存系統的效能對比
效能是評判儲存系統是否能夠支撐核心業務的關鍵指標。本文將對 4 個常見的雲原生儲存系統，IOMesh、Longhorn、Portworx、OpenEBS，的效能測試結果進行對比。
我們準備了三個 Worker 節點作為執行應用和雲原生儲存的節點，每個節點配備了兩塊 SATA SSD，四塊 SATA HDD，以及萬兆網絡卡。
在測試中，我們採用最常見的 MySQL 資料庫作為有狀態應用，並使用 sysbench-tpcc 模擬業務負載。下表提供了四個雲原生儲存系統在 TPC-C MySQL 測試中的 TPS、QPS 以及 P95 延遲資料。
圖 5。 TPC-C MySQL 綜合性能測試
下圖對比了四個雲原生儲存系統的效能測試結果。圖中橫軸代表測試時間，縱軸分別代表：TPS、QPS、以及 P95 延遲的瞬時值。
圖 6。 TPC-C MySQL 效能穩定性測試
從以上資料與對比可以明顯地看出， IOMesh 在絕對效能，以及效能的穩定性上，都遙遙領先於其他的雲原生儲存系統，具備為核心生產系統提供儲存支撐的能力。
隨著雲原生時代的到來，越來越多的業務系統會採用雲原生架構。儲存系統作為承載業務穩定執行的核心元件，在雲原生的架構下，也面臨著新的挑戰。與此同時，資料庫以及儲存系統自身也受到了雲原生架構的影響，逐漸發展出雲原生資料庫和雲原生儲存系統。未來可以看到越來越多的雲原生資料庫和雲原生儲存出現在資料中心中，成為被廣泛使用的技術。
