一文看懂Container Attached Storage

一文看懂Container Attached Storage

來自專欄 K8S技術社區

本文給出了Container Attached Storage的簡單定義，解釋了這個模式是什麽，出現的原因和工作方式。

什麼是Container Attached Storage？

如上圖所示 ，Container Attached Storage是包含由Kubernetes編排的、基於微服務的存儲控制器的軟體。這些存儲控制器可以在Kubernetes運行的任何地方運行，即任何雲甚至裸機伺服器，或者傳統共享存儲系統之上。關鍵的是，數據本身也通過容器訪問，而不是存儲在脫離平台的共享橫向擴展存儲系統中，儘管Container Attached Storage可以在這種Storage Area Network（SAN）系統之上運行。

明白了這一點，就好理解Container Attached Storage意味著解決方案的更廣泛趨勢（其中許多解決方案現在正由CNCF孵化），即重新創建特定類別或創建新的解決方案——構建在Kubernetes和微服務之上，並為基於Kubernetes的微服務環境提供功能 。例如，安全、DNS、網路、網路策略管理、消息傳遞、跟蹤、日誌記錄等新項目已經出現在雲原生生態系統中，並且通常在CNCF中出現。

類似的，Container Attached Storage通過依賴Kubernetes和其他編排器的微服務來解決許多存儲用例。

為什麼採用Container Attached Storage？

Container Attached Storage被採用的第一個原因是它是一個基於微服務的架構，這意味著它適合構建和運行旨在加速開發（即敏捷性）的系統。就OpenEBS而言，我們看到由特定團隊採用Container Attached Storage的用戶可以擴展和自定義將存儲策略與工作負載相匹配的能力。正如一位用戶所說，如果他們只使用共享存儲，工作負載必須與正在使用共享存儲的其他工作負載相抗衡，並且必須經過所謂的「I / O混合器」。而通過添加OpenEBS，他們可以決定自己塊的大小、複製模式、備份策略等，而且不必向中央存儲申請許可。使用Container Attached Storage時，默認的部署模式是超融合的，數據保存在本地，然後複製到其他主機。

Container Attached Storage被採用的第二個原因是由於許多企業和組織避免鎖定的戰略決策。當然，這種避免鎖定的願望似乎是採用Kubernetes的推動力之一，它「隨處運行」並確保編排框架本身不會成為難以擺脫鎖定的源頭。

Kubernetes不足的地方，Container Attached Storage可以補上。如果Container Attached Storage的構建方式不依賴於內核修改，那麼確實可以跨雲跟上工作負載；實際上，可以在Container Attached Storage的幫助下遷移工作負載。無狀態工作負載相對容易「移動」，有狀態的工作負載需要在移動之前耗盡，並且它們所依賴的數據也必須移動。來自OpenEBS和其他公司的Container Attached Storage越來越能夠在後台進行這種數據遷移，以便解決由於」數據重力「導致的雲鎖定問題。

Container Attached Storage採用的第三個原因與第一個有些相關，即直連存儲現在通常是工作負載、應用架構和架構師所假定的模式。Container Attached Storage可以提供「剛好足夠」的存儲管理功能，無需在不熟悉SAN和其他共享存儲的環境中引入共享存儲的「反模式」。具有諷刺意味的是，Container Attached Storage採用的一種方式是在OpenShift或其他一些由共享存儲支持的Kubernetes環境之上運行。儘管如此，對於開發人員和工作負載而言，Container Attached Storage在性能和故障域方面看起來更像DAS，而不是共享存儲。

Container Attached Storage 如何工作？

現在有各種各樣的Container Attached Storage解決方案，包括PortWorx和StorageOS以及OpenEBS，每個都有自己的優勢和弱點。這些解決方案在構建和部署方式上具有一些共同的特點。

第一個共同特點是Container Attached Storage解決方案由在Kubernetes（有時還包括其他編排層）之上運行的微服務組成。這意味著傳統的存儲控制器已經被分解成可以獨立運行的組成部分。由於利用了Kubernetes抽象或原語，高可用性和水平可伸縮性的許多問題都是「免費」解決的。

第二個共同特點是，由於每個工作負載都有自己的一個或多個控制器，它們儘可能少地集中I / O，因此避免了上述「I / O混合器」。為什麼這一點非常重要？輸入/輸出操作可能成為有狀態工作負載性能的瓶頸，而該有狀態工作負載的性能可能成為應用程序性能的瓶頸。換句話說，當你在你最喜歡的旅遊網站上點擊「購買」時，交易發生的速度可能與底層存儲的I / O性能直接相關。事實證明，當涉及到I / O時，應用程序有不同的需求，而且將這些I / O集中到一起會顯著降低性能。例如，有些系統實際上會更受到吞吐量的限制（而不是I / O），會向媒質寫入大塊，而有些系統將更受到I / O的限制，會向媒質寫入小10或100倍的較小塊。

一個簡短的題外話：當共享橫向擴展存儲被開發出來時，它可以加速性能（與單一系統直連存儲相比），並且通過將分散式系統管理的挑戰集中到一個獨立的系統中，簡化了管理。現在，共享存儲幾乎總是比DAS系統慢一個數量級甚至更多，而且這種差距只會越來越大。此外，現在我們所做的都是分散式系統，而這就是雲原生架構，因此再有一個微服務環境下的、行為不同的分散式系統並沒有多少好處，有時候還被視為「反模式」。

結論和下一步是什麼？

這篇文章旨在回顧對為Kubernetes用戶提供支持的我們來說，哪些是顯而易見的，如微服務、容器化，以及Kubernetes為數據的管理和存儲方式所開闢的一些新的可能性。雖然共享存儲肯定會繼續存在很長時間 （ 它作為IT堆棧中最昂貴和最傳統的部分，地位不容忽視），但Container Attached Storage正在興起，它提供控制和性能水平，提供許多微服務有狀態工作負載和企業採用雲服務所需的不被雲鎖定的自由（通常通過擴展底層共享存儲的功能）。

2018年5月2日-4日，雲原生計算基金會旗艦會議KubeCon+CloudNativeCon將于丹麥哥本哈根舉行，屆時來自全球領先的開源和雲原生社區的採用者和技術專家匯聚一堂。

K8S技術社區聯合EasyStack技術團隊親赴峰會現場，為大家帶來峰會一手資訊+現場評論+直播分享，長按識別二維碼報名參與K8S技術社區峰會直播討論，有機會獲得由K8S技術社區贊助的Kubernetes技術書籍！

https://u.wechat.com/EJnxsZjUafxX6e8ZU7nZsRQ (二維碼自動識別)

推薦閱讀：