容器附加存儲（CAS）是雲原生存儲

客座文章做者：Evan Powell，CEO @MayaData

或者，雲服務怎麼會不是雲原生的呢？

歐洲KubeCon在不少方面都很偉大。一個驚喜是，由於KubeCon是一個虛擬活動，這致使我與各類存儲供應商和項目的對話比以前的KubeCon更多。KubeCon存儲的交流頻道召集了許多聰明的供應商，他們一般合做，試圖爲最終用戶解決問題；我受到了鼓舞，試着盡個人一份力來跟上。

這就是本文起點，做爲容器附加存儲（Container Attached Storage，CAS）定義的原始做者，接下來爲更普遍的社區建立一個博客是有意義的。

引起此次更新的問題來自一個傳統存儲供應商的工程師，他問--我稍微引用一下：「若是鬆散耦合對於雲原生架構如此重要，這是否意味着，依賴於一個給定的雲自己就不是雲原生的？換句話說，雲服務自己不是雲原生的嗎？」我不得不回答--是的--但故事還有更多內容。

回顧--什麼是CAS？

容器附加存儲是一種模式，它很是符合數據分解的趨勢，以及運行小型、鬆散耦合的工做負載的小型、自治團隊。換句話說，個人團隊可能須要爲咱們的微服務使用Postgres，而你的團隊可能依賴於Redis和MongoDB。咱們的一些用例可能須要性能，一些可能在20分鐘內就用完，其餘的是寫密集型的，其餘的是讀密集型的等等。在大型組織中，團隊依賴的技術，會隨着組織規模的增加，和組織愈來愈信任團隊選擇他們本身的工具，而變得愈來愈多。Kubernetes支持這種模式--有時被討論爲數據網格（data mesh）和多語言數據（polyglot data）的興起--來自ThoughtWorks的Zhamak Dehghani和其餘人有相關的討論。

瞭解更多關於CAS：

• 早在2018年4月，我在CNCF的網站上建立了CAS一詞的博客：

  https://www.cncf.io/blog/2018...

• 7月的CNCF網絡研討會，由OpenEBS項目負責人Kiran Mova主持：

  https://www.cncf.io/webinars/...

這是來自Kiran社區網絡研討會的一張規範圖片，並附有一些解釋：

CAS意味着開發者，能夠在不考慮其組織存儲架構的底層需求的狀況下工做。對於CAS，雲磁盤與SAN相同，SAN與裸機或虛擬主機相同。咱們沒有召開會議來選擇下一個存儲供應商，或討論設置來支持咱們的用例，咱們使用咱們須要的存儲或localPV管理來啓動咱們本身的CAS容器，而後繼續前進。

好的，^^這就是CAS，可是雲有什麼不是原生雲的呢？

Kubernetes的一個被忽視的方面是，它最初建立的目的，是確保咱們能夠以雲原生方式運行雲。讓我來解釋一下。

在Kubernetes以前，很難宣佈意圖（intent），並知道將要執行此意圖，而不論其部署環境是本地部署，仍是A、B或C雲。相反，企業被建議選擇一家主要的雲，而且加倍他們與該雲的專業知識和關係。

所以，整個組織和他們編寫的全部軟件都隱式地依賴於該雲，所以與雲耦合。這種緊密耦合一般並不重要，直到它變得重要爲止。只有像Netflix這樣的組織，他們的系統架構既能解決AWS的漏洞，又能經過混沌工程積極地、不懈地驗證本身的容錯性，才能挺過各類各樣的AWS宕機。據推測，他們轉移至少一部分工做負載的能力，好比基於Spinnaker的CI/CD，也有助於他們與AWS協商更好的價格。

簡而言之，若是你將雲原生定義爲可以在底層雲中斷時存活，那麼與雲緊密耦合自己就是一種反模式。

Kubernetes之因此成爲咱們這個時代最重要的開源項目之一，部分緣由在於它意識到了這種緊密耦合的風險和阻抗挑戰。並且，對於一個傳統的共享一切的存儲硬件供應商來講，這裏有些敏感，這種邏輯在他們銷售的系統上雙倍適用。

若是你想構建鬆散耦合的系統，就像你不能簡單地在一個雲上，而且只在那個雲上運行同樣，你也不能假設一個聲稱可擴展到數千個節點的存儲系統在全部狀況下都能工做。

若是咱們接受雲原生核心的「構建失敗」信條，咱們必須認可共享的全部存儲將會崩潰。它的行爲方式並不適合每一個團隊的工做負載。它將以非Kubernetes原生方式運行，全部這些依賴關係將超出咱們控制的風險引入到咱們的環境中，這對咱們的團隊來講是不透明的。

好的，那麼CAS有什麼新東西呢？

當CAS首次出現時，它被用於較少任務關鍵型工做負載，這並不奇怪。很好的例子包括各類「半永久性」工做負載，其中你但願數據在CI/CD運行期間保留，或者用於一些數據科學工做，而後你但願它消失。對於這些示例，CAS容許工做負載快速且一致地啓動很是重要。第二個也是重要的需求是，不管底層環境如何，CAS的行爲方式都是相同的。

當Kubernetes調度工做負載時，即便是至關典型的32秒的EBS附加時間，若是運行時間爲5分鐘，而你天天運行它幾十次，則須要很多時間。你能夠在早期OpenEBS採納者列表中看到這種模式，早期的公共引用每每傾向於持續時間相對較短的工做負載。

幾年前，Kubernetes上的較長持續時間的工做負載以兩種方式之一處理。

1. 要麼經過雲中的託管服務，或
2. 增長額外彈性級別的NoSql數據庫。

一開始咱們認爲CAS在這兩種狀況下都不適用，由於傳統的共享存儲確定不適用；然而，咱們很快意識到NoSQL數據庫和Kafka這樣的解決方案，能夠在咱們稱爲動態LocalPV的地方獲得幫助。

經過保持對底層環境（包括可用的雲卷和物理磁盤）的瞭解，像OpenEBS的LocalPV這樣的CAS解決方案，下降了在Kubernetes上運行這些工做負載的操做工做量。CAS解決方案這樣作的方式，減小了對給定底層雲或存儲系統的鎖定或依賴。

第一個新的CAS要求

所以，咱們能夠相應地更新CAS定義。咱們如今知道CAS解決方案須要包括LocalPV支持。一樣，幫助使用LocalPV運行數據應用程序的相關Kubernetes操做器也是如此。

最近，咱們看到許多工做負載都在增長，對於這些工做負載，本地節點性能很是重要。

性能問題一樣能夠經過使用LocalPV來解決。一個挑戰是，許多工做負載如今既須要性能又須要多節點HA。僅僅經過Restic或其餘項目或產品備份節點是不夠的。

考慮運行在PostgreSQL或MySql上的高性能工做負載--例如運行在MySql上的Magento。僅僅備份數據是不夠的，MySql一般但願可以當即訪問另外一個節點上的數據。也許不足爲奇的是，許多這些工做負載在雲出現以前就存在了。傳統的SQL，如MySql、PostgreSQL和其餘SQL，幾乎老是部署故障轉移和副本。有時，這些傳統的工做負載甚至能夠經過Kafka或相似的方式整合在一塊兒，以交付一個統一的數據網格，就像前面ThoughtWorks的文章中提到的那樣。咱們的夢想是爲企業提供關注點，好比從全部數據中學習，同時也容許小型獨立團隊的自治和敏捷性。

第二個新的CAS要求

所以，咱們能夠用第二種方式更新CAS定義。咱們如今知道CAS解決方案須要以LocalPV速度包含多節點HA。

這個需求的惟一問題是，到目前爲止，可以知足這個需求的解決方案很是少。據我所知，致力於知足這一需求的惟一CAS解決方案是OpenEBS Mayastor；它將在2020年9月達到測試版0.4。

第三和第四項附加的CAS要求

第三個更新在這兩個更新以後的邏輯上進行。CAS解決方案在其架構中應該是雲原生的。若是咱們想成功地支持全部類型的工做負載，好比NoSql工做負載的LocalPV，以及對許多性能敏感的PostgreSQL等部署具備彈性的高性能，那麼CAS必須提供多種存儲數據的方法。

在OpenEBS的狀況，該項目利用雲原生架構提供了很多於4個「數據引擎」（若是計算可用的全部不一樣風格的LocalPV，會更多）。早期的CAS解決方案在本質上更加單一。我認爲全部的CAS都須要以Kubernetes做爲基底的思想來構建，從而實現可插拔的非單體架構。

最後，開源彷佛是明顯的。理性的人可能不一樣意這一點，由於有一些明顯的CAS模式的早期貢獻者依賴於專有軟件。可是，專有軟件引入了供應商依賴，這與雲原生固有的「可移植性」精神相沖突。

綜上所述，從成千上萬的容器附加存儲用戶那裏，咱們能夠自信地說，CAS的定義應該擴展到包括：

1. CAS必須支持pass-through模式（咱們在Kubernetes生態系統中稱之爲LocalPV）
2. CAS必須支持LocalPV速度的多節點HA
3. CAS軟件在架構上應該是雲原生的--根據工做負載支持多個數據引擎
4. CAS應該是開源的，以免引入供應商依賴關係。

總結

在過去的幾年裏，咱們看到了來自更普遍的雲原生社區的大量反饋和支持，這些社區致力於如何在處理數據時最大限度地利用Kubernetes和雲原生方法。咱們必須付出才能獲得。並且，我比以往任什麼時候候都高興，由於MayaData將OpenEBS捐贈給了CNCF。咱們很天然地將Litmus也捐贈給了關注有狀態工做負載的混沌工程。咱們很是自豪的是，根據這篇來自CNCF的DevStats報告，截止到2020年8月底，MayaData是CNCF項目的第5大主要貢獻者：
https://all.devstats.cncf.io/...

最近，咱們幫助啓動了Data on Kubernetes社區項目，在這供應商中立空間中討論操做人員、數據庫、用例等等。來自使用Kubernetes組織的工程師像Optoro和Arista等，以及Kafka/Confluent和Cassandra/DataStax等項目進行了發言。歡迎並鼓勵全部人與獨立組織者取得聯繫，以任何你想要的方式參與。

CAS如今被看做是把Kubernetes轉換成數據平面的關鍵部分。CAS補充了底層雲存儲服務、本地CSI可訪問存儲，甚至是本地節點中可用的原始磁盤和內存。

咱們使用CAS（特別是OpenEBS）的經驗代表，用戶已經熟悉了這種模式。CAS的新需求反映了這模型的增加和成熟度。

我對將來幾年咱們將走向何方感到興奮。當咱們在Kubernetes上探索更多數據密集型的工做負載時，咱們的需求將如何發展？無論是什麼，咱們都渴望和你一塊兒找出答案。咱們在MayaData這裏傾聽，並繼續發展CAS模式以知足新的需求。

點擊閱讀網站原文。

---

CNCF (Cloud Native Computing Foundation)成立於2015年12月，隸屬於Linux  Foundation，是非營利性組織。
CNCF（雲原生計算基金會）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。咱們經過將最前沿的模式民主化，讓這些創新爲大衆所用。掃描二維碼關注CNCF微信公衆號。