云原生時代，存儲長什么樣？

科技云報道原創(chuàng)。

據IDC稱，到2023年，將有超5億的應用和服務以云原生的方式進行開發(fā)和部署，這一數(shù)字與過去40年以來人們開發(fā)的應用總數(shù)相當。

云原生的加速發(fā)展為每個行業(yè)帶來新的競爭需求，云原生和容器正在迅速轉變?yōu)閼贸绦蜷_發(fā)和底層云基礎設施服務的新藍圖。

但值得注意的是，據CNCF調查顯示，目前存儲系統(tǒng)依然是云原生場景使用和部署中面臨的最主要障礙之一。

云原生環(huán)境對存儲帶來新挑戰(zhàn)

存儲系統(tǒng)一直以來都是基礎設施軟件中的核心之一。無論業(yè)務采用什么樣的運行環(huán)境和架構，都離不開存儲系統(tǒng)的支撐。

在過去的30年中，業(yè)務系統(tǒng)的運行環(huán)境經歷了巨大的變化，從單獨部署的物理機，小規(guī)模部署的虛擬化環(huán)境，大規(guī)模部署的云環(huán)境，以及目前的云原生平臺。在這個變革的過程中，業(yè)務系統(tǒng)對平臺敏捷性的要求越來越高。

在物理機時代，運維人員需要手動配置存儲系統(tǒng)和部署業(yè)務系統(tǒng)，業(yè)務上線以周為單位。而在云原生時代，每分鐘都可能發(fā)布新的應用版本，每天都可能有大量的業(yè)務要上線。

這意味著，云原生時代的存儲系統(tǒng)，除了要滿足性能、穩(wěn)定性、可靠性的要求以外，還要滿足業(yè)務系統(tǒng)對敏捷性的要求，能夠通過統(tǒng)一的編排系統(tǒng)配合業(yè)務上線，并且可以實現(xiàn)快速擴容。

同時，為了減輕運維管理員的工作負擔，存儲系統(tǒng)自身的自動化運維能力，也成為運維團隊關注的核心焦點。

盡管在云原生技術日益普及的今天，在Kubernetes上運行無狀態(tài)應用已經非常成熟，平滑擴展能力也很強，但對于有狀態(tài)的應用，數(shù)據需要持久化存儲，還有很大提升的空間，面臨著很多挑戰(zhàn)。

據CNCF對于“在使用/部署容器過程中遇到的挑戰(zhàn)”的調查報告中顯示，云原生存儲遇到的挑戰(zhàn)表現(xiàn)在以下幾個方面：

易用性：存儲服務部署、運維復雜，云原生化程度低，缺少與主流編排平臺整合

高性能：大量應用IO訪問，IOPS需求高，低時延，性能成為應用運行效率瓶頸

高可用：云原生存儲已經應用到生產環(huán)境，需要高可靠/高可用，不能出現(xiàn)單點故障

敏捷性：PV快速創(chuàng)建、銷毀、平滑的擴展/收縮，PV隨Pod遷移而快速遷移

??云原生存儲應具備哪些特點？

云原生存儲作為一種存儲系統(tǒng)，可靠性、性能、高可用等特點都是必不可少的。除此之外，云原生環(huán)境對存儲系統(tǒng)提出了更高的要求。

面對諸多挑戰(zhàn)云原生存儲應具備哪些特點呢？

?盡量減少環(huán)境依賴

云原生存儲系統(tǒng)應盡量不對軟硬件環(huán)境存在任何依賴，例如對內核的依賴，對特定的網絡設備和磁盤型號的依賴等等。只有盡量少的依賴，才能夠做到最大的適配性。

避免資源消耗過高

云原生存儲系統(tǒng)以容器的形式和業(yè)務系統(tǒng)混合部署在容器平臺上。如果存儲系統(tǒng)占用過多的計算資源（CPU、內存），則會導致整體投入成本太高。

聲明式運維方式

存儲系統(tǒng)應支持通過聲明式的接口進行運維管理，同時支持一定程度的自動化運維，包括在線擴容、升級等等。當發(fā)生硬件故障時，存儲服務可以自動恢復，以保證業(yè)務系統(tǒng)不受影響。

云原生生態(tài)

云原生存儲還需要能夠很好地和其他云原生基礎設施配合，例如云原生數(shù)據庫，使得云原生數(shù)據庫可以真正的在公有云和私有云都能夠得到一致的用戶體驗。同時，云原生存儲應該很好地和云原生的運維生態(tài)系統(tǒng)結合，包括監(jiān)控、報警、日志處理等待。

總體而言，云原生存儲系統(tǒng)可以運行在各種不同服務商提供的公有云環(huán)境或私有云環(huán)境中，并且為運維人員提供相同接口和運維方式，極大降低運維團隊的負擔。

市場上的云原生存儲方案

為了更好的理解在云環(huán)境中如何構建云原生存儲，先看幾個在Kubernetes企業(yè)環(huán)境中部署主流的云原生存儲方案。

??Ceph?on?Kubernetes?with?Rook??

Ceph是圣克魯茲加利福尼亞大學的Sage?Weil在2003年開發(fā)的，也是他博士學位項目中的一部分。Ceph?LTS成熟穩(wěn)定、高可用、生態(tài)強大，在云原生時代和Kubernets緊密集成。

Ceph基于RADOS（Reliable?Autonomic?Distributed?Object?Store）的高可用存儲，在云原生時代之前已經廣泛生產部署的高可用存儲，支持最廣泛的塊存儲RBD、文件POSIX?Cephfs，以及對象存儲訪問協(xié)議。

RedHat/SUSE目前是Ceph最主要的商業(yè)化支持者，在多個容器平臺落地案例中，RBD、CephFS?都被采用作為容器平臺實施的主要存儲，用來彌補基礎云存儲的缺失。

Rook目前是在Kubernetes產品級可用的部署和運維Ceph編排工具。

??Portworx??

Portworx以容器服務的方式部署，每個節(jié)點稱為PX，向下對接各種公有云的塊存儲或者裸金屬服務器，向上提供塊或文件服務。

不綁定硬件形態(tài)和廠商，可接入任何一家公有云或者自建服務器集群（只需支持iSCSI或FC?協(xié)議），目前Portworx主打能力云災備DR、多云復制，具備完備的快照（ROW）、多云管理、同步復制（RTO，秒級）異步復制（RPO<=15min)，可以通過Kubernetes?CRD申明方式，優(yōu)雅實現(xiàn)持久化云下應用帶數(shù)據自動遷移云上能力。PX可以獨立部署，并不強依賴Kubernetes的容器網絡。

??OpenEBS??

OpenEBS基于Kubernetes構建的開源版EBS，軟件定義PV：將各種介質，包括本地磁盤、云等各種存儲統(tǒng)一池化和管理。使用iSCSI作為存儲協(xié)議。沒有綁定某一個廠商的存儲，可以靈活的接入各種存儲的一個原因。

從某種意義上，OpenEBS也是更加靈活、輕量。但是強依賴容器網絡，增加了抽象層OpenEBS?layer,?寫入操作要通過抽象層，并且每個卷PV都有獨立的controller，增加了額外的開銷，雖然可以做到更靈活，但相比于Portworx、Ceph來說，其在性能上有比較大的劣勢。

目前，已經有大量的企業(yè)在將自身的存儲能力引入到Kubernetes中。

在CNCF公布的《2019?Cloud?Native?Computing?Foundation》市場調研中，分析了當前和未來K8s采用情況，其中許多用戶將他們當前的存儲和云的供應商列為云原生候選名單中。

調查顯示，在云原生存儲的選擇上，用戶最常使用Amazon?EBS、Google?Persistent?Disk和Azure?Disk?Storage。

第二梯隊的是Ceph、CSI和Gluster，其中37%的Gluster用戶也使用Ceph。Ceph和Gluster是分布式文件系統(tǒng)，在多個節(jié)點之間添加了持久層。但是，它們沒有很好地集成到K8s工具和工作流中，因而可能更難以維護和配置。

剩下的第三梯隊產品，基本是由以存儲為中心的服務商提供的服務，如Dell?EMC、NetApp和Pure?Storage。最初，Kubernetes集成了卷插件以連接到這些產品的存儲后端。不幸的是，上游Kubernetes發(fā)行版變得十分臃腫。這意味著對插件的任何微小更新或更改都要重建和編譯整個代碼。

而對于傳統(tǒng)存儲，客戶可能會有更多抱怨聲。例如，選擇Pure?Storage的客戶中有46%的在處理與容器相關的存儲方面遇到了挑戰(zhàn)，而Kubernetes的普通用戶這一比例僅為27%。盡管有13%的用戶使用了容器存儲接口（CSI），但問題難免還是會出現(xiàn)。

事實情況是，傳統(tǒng)存儲供應商包括純容器存儲服務商在內，正有轉向CSI的趨勢。雖然總體上只有13%的用戶在考慮使用CSI，但在存在存儲挑戰(zhàn)的用戶群中，對CSI的需求一躍升至22%。

結語

隨著云原生時代的到來，越來越多的業(yè)務系統(tǒng)會采用云原生架構。存儲系統(tǒng)作為承載業(yè)務穩(wěn)定運行的核心組件，在云原生的架構下，其重要性也相應地逐漸提高。

事實上，云原生存儲遇到的性能、彈性、高可用、加密、隔離、可觀測性、生命周期等方面的問題，不但需要存儲產品層次的改進，更需要在云原生的控制／數(shù)據平面的改進，以推進云原生存儲的演進，而這正是新老存儲廠商有待優(yōu)化和提供的服務空間。

來源：科技云報道

生成海報

免責聲明：此文內容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權歸作者所有，且僅代表作者個人觀點，與極客網無關。文章僅供讀者參考，并請自行核實相關內容。投訴郵箱：editor@fromgeek.com。

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。