玩轉容器持久化存儲,就是這麼簡單!

2021-01-16 申耀的科技觀察

今天,「雲原生」這個概念已經席捲了全球,特別是隨著數字經濟的快速發展和擴張,越來越多的企業開始採用容器和雲原生的技術和方式,以加速企業的數位化轉型。

但是,容器的流行也給企業的數據中心基礎設施帶來了重大挑戰,存儲就首當其衝。容器的最大特點是「召之即來,揮之即去」,不過企業的數據卻需要長久的存儲和備份。基於此,容器持久化存儲以及由此延伸出來的持久化數據保護管理,之於數據獨立於容器應用生命周期的存在就顯得至關重要。

為此,戴爾科技提供了一種全新的解決方案,即基於最新的CSI接口,實現了存儲插件的一系列功能,使得Dell EMC的企業級存儲產品都能夠輕鬆接入Kubernetes,真正為容器平臺提供了高效、可靠、安全的持久化存儲服務。

不僅如此,戴爾科技還在市場上推出了第一個也是唯一一個同時針對虛擬機、應用程式和Kubernetes的企業級保護解決方案,可化解容器持久化數據保護管理的難題,幫助企業能夠以最快捷和最簡單的方式完成雲原生架構的落地,由此可以從「容」不迫的邁出雲原生之旅。

數據持久化三重挑戰

眾所周知,雲原生最初的架構設計中,強調的是雲原生應用進程必須是「無狀態」的,且是可以在各個節點中共享的,這樣設計的好處是,雲原生應用可以隨時啟動,隨時動態伸縮,任何一個應用進程出現問題或者「掛掉」,對整個雲原生應用是不產生任何影響的。

同樣對存儲基礎設施而言,正常情況下應用要實現持久化的數據存儲,則可以交給後端的存儲來提供服務,按照傳統模式部署在物理機環境中或虛擬機環境中處理就行,即「back-end Service」,因而雲原生在最初興起時,其實是很難看到把數據持久化應用到容器環境之中的。

但隨著雲原生的興起,容器化的發展趨勢可謂「勢不可擋」,這樣就帶來了新的問題,那就是Kubernetes容器不斷從最開始的「無狀態」應用部署場景延伸至多種類型數據處理的業務場景,比如Devops開發運維、持續集成、大數據人工智慧訓練等,這對容器持久化存儲就提出了更高要求。

在戴爾科技集團售前系統工程部解決方案架構師林小引看來,這種全新的挑戰具體表現在三個維度:

首先,從啟動速度看,容器本身的特點是輕量級的,因此它的啟動速度比傳統物理機和虛擬機要快很多,如果說容器是以秒為單位來啟動的話,那麼傳統處理器和虛擬機則是以分鐘為單位啟動,這樣就出現了啟動速度「不同步」和「不匹配」的問題,這就要求容器底層的存儲掛載也能要夠匹配容器快速啟動的速度。

其次,從工作負載看,容器應用的生命周期相對傳統工作負載往往更彈性、更短暫,同樣這也就導致了容器的數據存儲要能夠支持容器這種生命周期特性。例如,企業的容器數量,需要從五個並發容器彈性伸縮到十個以上,那麼底層存儲也需要動態和快速的響應這樣的需求,這就要求存儲也必須具備動態地提供存儲的能力。

最後,從擴展能力看,鑑於輕量級的特性,企業部署的容器規模通常都比較大,且是跨多節點分布式部署,因而也需要底層的存儲對並發訪問的支持能力要高,能夠支持大量物理伺服器的接入,同時自身能夠支持橫向擴展,以滿足容器大規模的、分布式的部署要求。

不難發現,隨著容器不斷成熟以及應用的深入,越來越多的企業用戶都希望將其應用遷移到容器之中,以完成應用的現代化改造,如典型的資料庫、數據共享等等,但之前大部分的存儲設備往往都不是為容器應用持久化而設計和開發的,這樣造成二者的「矛盾」越演越烈,化解這種挑戰儼然已「刻不容緩」。

戴爾科技「七劍下天山」

回頭來看,業界在化解數據持久化這個難題時,其實也一直是處於探索與實踐之中的。此前,Kubernetes對存儲插件就是以「in-tree」的方式來支持的。所謂「in-tree」,是指存儲插件的代碼維護在Kubernetes的主幹代碼中,與核心Kubernetes二進位文件一起進行連結、編譯、構建和發布,這種方式儘管可以和容器編排器共同協作了,但缺點其實也較為明顯。

其中最大的問題是,由於存儲的多樣性及更新迭代的周期與Kubernetes的迭代周期不一致,就會導致存儲插件的開發者很難保持雙方的「步調一致」;再如,部分商業存儲系統的支持代碼不方便開源;此外,第三方存儲插件中出現錯誤,也會一定程度上影響到Kubernetes運行的穩定性等等。

在此背景下,CSI(Container Storage Interface)這種全新的方式「應運而生」,它是容器編排系統(CO,如Cloud Foundry, Kubernetes, Mesos)集成存儲系統驅動程序的最新方法,定義了行業標準的「容器存儲接口」,可以使容器和存儲插件之間徹底實現「解耦化」。

據了解,CSI的標準是Kubernetes在v1.9版本引入,並在v1.13版本中正式GA的,CSI的存儲插件被稱為「out-of-tree」,相較於早期的「in-tree」方式,它的代碼獨立於Kubernetes,可由存儲廠商獨立構建、發布,因此存儲廠商只需開發一個符合CSI標準的插件,就可以讓它在多個CO系統中工作,而且也不再需要綁定到CO的發布計劃中,可以做到獨立開發、異步安裝,目前已成為主流的存儲與容器編排引擎結合的新方式。

而戴爾科技早在2018年Kubernetes發布CSI之初,就高度重視該標準,並從當年開始就陸續面向Dell EMC的企業級存儲推出CSI插件,同時還通過開源的方式讓客戶可以直接在Github上下載安裝和使用。

截止目前,戴爾科技旗下的Dell EMC PowerMax、XtremIO、VxFlex OS、SC和Isilon,以及新一代的第五代存儲PowerStor等存儲產品「家族」,再加上VMware的vSphere都發布了相關的CSI插件,以「七劍下天山」的方式全面支持在Kubernetes上運行的容器化工作負載。

事實上,戴爾科技容器持久化存儲解決方案不但支持時間早,同時也廣泛應用到企業核心的生產環境之中,如Dell EMC通過VxFlex OS CSI插件不僅可以支持Oracle資料庫運行在容器中,也支持雲原生資料庫運行在容器中,包括MongoDB、Cassandra、PostgreSQL和CockroachDB等。此外,Dell EMC通過XtremIO CSI插件,還能支持SQL Server 2019資料庫運行在容器之中,等等。

更為關鍵的是,戴爾科技容器持久化存儲還具備「軟硬兼施」的能力,即VMware的vSphere也支持CSI,它與Dell EMC存儲產品的CSI插件形成了「珠聯璧合」的效果,如果Kubernetes的環境是搭建在vSphere環境之上,客戶就可以直接利用CSI訪問vSphere環境裡的vSAN、VMFS或NFS存儲,但如果Kubernetes不是在VMware環境之上或者對存儲有其他要求,比如性能、擴展性等,則可以選擇Dell EMC的企業級存儲。

對此,戴爾科技集團售前系統工程部解決方案架構師林小引表示,不同工作負載的特殊性,以及存儲的多樣性決定了企業也需要不同的容器持久化存儲解決方案,如客戶對延時性要求較高,需要端到端NVMe以及基於SCM這樣的全閃介質提供支持,那麼PowerMax和PowerStore就是很好的選擇;再如,客戶的集群規模比較大,對數據存儲有著苛刻的要求,那麼Isilon則具備PB級的大規模分布式文件存儲的能力。

小結一下,在化解容器持久化存儲的挑戰之中,針對不同的工作負載,不同存儲要求的情況下,戴爾科技以「七劍齊出」的方式提供了豐富的、多樣化的選擇給到企業級的客戶,而客戶則可以按照自身的實際需求,來選擇具備「軟硬兼施」能力的且支持CSI的戴爾科技企業級存儲,更好的解決容器持久化存儲帶來的挑戰。

容器環境下的數據保護至關重要

值得一提的是,戴爾科技的技術創新也「從不止步」。根據Gartner的調查報告顯示,到2022年,超過75%的全球企業將在生產環境中運行容器化應用,如果考慮到數據丟失和對數據的跟蹤能力仍然是使用容器和Kubernetes的主要關注點,那麼企業想要釋放雲原生技術的紅利,就不能把數據保護當作事後的事項考慮。

客觀的說,容器環境下的數據保護,在業界都屬於前沿的話題,目前市場上能夠提供對容器數據保護的廠商或者解決方案都不是太多。但作為全球數據保護領域的領導者,戴爾科技則「與時俱進」的提供了對Kubernetes應用負載的數據保護,無疑為容器環境下的數據保護探索出了一條全新的破局之路。

這就是Dell EMC PowerProtect Data Manager(PPDM), 它也是第一個也是唯一一個同時針對虛擬機、應用程式和Kubernetes的企業級保護解決方案,如Oracle和SAP、虛擬機、容器等,這樣客戶就能夠在單一平臺上實現關鍵任務負載的數據保護。

此外,PPDM還與VMware深入合作,在VMware Project Pacific(太平洋項目)開發之初就參與其中,而Project Pacific通過對vShpere的全面的改造和優化,讓最新發布的vSphere7發展成為Kubernetes原生平臺,並深度整合和嵌入Kubernetes,而PPDM則利用了Project Velero項目中的kubernetes原生體系結構,將其直接集成到用戶界面之中,由此就帶來了三個「獨具特色」的優勢:

一是,集中管理,PPDM 軟體可以通過一個平臺管理不同的工作負載,例如虛擬機、應用程式和容器;二是,高效且靈活,對消除重複數據的存儲進行保護,支持通過DD/DDVE(即Data Domain和 Data Domain Virtual Edition)實現更低的TCO成本;三是,專為 Kubernetes 構建,客戶通過使用 Kubernetes API 時,PPDM 可以靈活地保護群集,PDM也能自動發現、顯示和監視 Kubernetes 資源,此外PPDM還具備無附加項節點親近性等特點,最終以更高效、更安全的方式保護Kubernetes工作負載。

由此可見,在Kubernetes的環境下,PPDM真正提供了一種創新的解決方法和方案,由此可以幫助用戶輕鬆化解各種棘手的數據保護問題,更讓企業客戶的容器持久化數據保護難題「迎刃而解」。

全文總結,隨著雲原生以及混合多雲時代的來臨,企業的開發模式和應用部署正在發生根本性的轉變,這就對基礎設施提出了前所未有的新挑戰,而戴爾科技則提供了基於VCF 4.0的新一代工程一體化雲原生平臺(VCF 4.0 on VxRail 7.0),具備CSI插件接口的企業級存儲「家族」,以及可支持雲原生工作負載數據保護能力(PPDM)的一站式解決方案,真正幫助企業可以更快的跨出實現雲原生的關鍵一步。

從這個角度來說,有容器的地方就需要有戴爾科技,而戴爾科技的技術創新步伐同樣也「從未止步」,而在未來容器新世界中更大的創新力和想像力,也正等待著戴爾科技去再定義、再創新和再拓展。

相關焦點

  • 容器持久化存儲,距離你有多遠?
    就不簡單了。數字科技的特點是概念頻出,眼花繚亂的同時,也讓人頭暈目眩,追趕不上發展的步伐。這裡要談論的是容器持久化存儲,相信對很多人來說,這是一個新概念。如果從定義或者概念來了解它,涉及技術很多,用戶的基礎不同、認知不同,要快速掌握容器持久化存儲的價值,其實並不容易,叫存儲,但是意義超越存儲。
  • 利用Kubernetes實現容器的持久化存儲
    【IT168 技術】可以說,容器化徹底改變了我們對應用程式開發的思考方式,它帶來很多好處:開發和生產之間的一致環境、使用共享的資源但容器之間相互隔離、雲環境之間的可移植性、快速部署……等等不勝枚舉。容器所固有的短暫性是它之所以偉大的核心原因:不可變的、相同的容器,可以在一瞬間快速啟動。但容器的短暫性也有不利的一面:缺乏持久化存儲。
  • 杉巖:雲原生時代,容器持久化存儲方案選對了嗎?
    而現在,隨著雲原生對業務創新的影響力持續顯現,越來越多的企業開始將容器應用於生產環境。前者更側重容器本身帶來的便利,而後者需要解決數據持久化存儲等諸多問題。得益於Kubernetes等容器編排平臺的迅速發展,其在持久化存儲以及資源調度等方面持續改進,為在生產環境中快速部署容器、高效使用容器打下了堅實根基。
  • 深信服EDS通過K8S CSI認證,助力解決容器的持久化存儲難題
    日前,深信服企業級分布式存儲EDS(以下簡稱「EDS」)正式完成Kubernetes(以下簡稱「K8S」) CSI標準數據持久化存儲的官方對接。容器區別於虛擬機,以輕量化、快速交付、彈性擴容著稱,但在存儲層面主要面臨兩大挑戰:1)容器默認使用宿主機的本地存儲,無法跨節點共享數據,也無法在集群內彈性調度,且其存儲擴容能力受限於宿主機;2)容器實例的發布是批量快速進行的,在K8S開放CSI標準之前無法滿足其持久化存儲資源快速匹配的需求。
  • 深入Kubernetes:K8s的容器持久化存儲操作
    推薦閱讀: 從一個例子入手PV、PVCKubernetes 項目引入了一組叫作 Persistent Volume Claim(PVC)和 Persistent Volume(PV)的 API 對象用於管理存儲卷
  • 使用docker數據卷對容器數據持久化
    volume是用於對docker容器生成和使用的數據持久化的首選機制。如果您的容器生成非持久狀態數據,請考慮使用 tmpfs掛載以避免將數據永久存儲在任何地方,並通過避免寫入容器的可寫層來提高容器的性能。
  • 一鍵部署K8S持久化存儲,Rancher正式發布Longhorn 1.0
    2020年6月3日,業界應用最為廣泛的Kubernetes管理平臺創建者Rancher Labs(以下簡稱Rancher)宣布企業級雲原生容器存儲解決方案Longhorn正式GA。Longhorn支持企業在Kubernetes上輕鬆開發有狀態的應用程式,滿足了企業對避免供應商鎖定的企業級持久化存儲解決方案的需求。
  • 一鍵部署K8S持久化存儲,Rancher正式發布Longhorn 1.0
    2020年6月3日,業界應用最為廣泛的Kubernetes管理平臺創建者Rancher Labs(以下簡稱Rancher)宣布企業級雲原生容器存儲解決方案Longhorn正式GA。Longhorn支持企業在Kubernetes上輕鬆開發有狀態的應用程式,滿足了企業對避免供應商鎖定的企業級持久化存儲解決方案的需求。
  • 大數據入門:Spark持久化存儲策略
    持久化存儲是Spark非常重要的一個特性,通過持久化存儲,提升Spark應用性能,以更好地滿足實際需求。而Spark的持久化存儲,根據不同的需求現狀,可以選擇不同的策略方案。今天的大數據入門分享,我們就來具體講講Spark持久化存儲策略。
  • Flutter持久化存儲之key-value存儲
    前言應用開發時會有很多的數據存儲需求,這個時候就需要用到持久化存儲技術,與iOS、安卓一樣,Flutter中也有很多種持久化存儲方式,比如key-value存儲、文件存儲、資料庫存儲等,但其實質都是通過平臺對應的模塊來實現的,本篇我們將帶大家一起了解key-value存儲的應用。
  • 容器存儲解決方案藍皮書發布
    前言本藍皮書將討論容器對存儲的現實需求以及阿里雲文件存儲在雲原生和容器等領域,不斷進行適配和迭代的具體實踐,幫助用戶應對雲原生時代的挑戰。容器存儲的挑戰新型工作負載容器化、遷雲在存儲方面遇到的性能、彈性、高可用、安全及生命周期等方面的問題,不但需要存儲產品層次的改進,還需要在雲原生的控制和數據層次的改進,推進雲原生存儲的技術演進。
  • 輕鬆實現持久化存儲!
    業界採用最為廣泛的Kubernetes管理平臺創建者Rancher Labs(以下簡稱Rancher)在2018年3月發布了容器化分布式存儲項目Longhorn(現已捐獻給CNCF),這一項目填補了以上的空缺。簡而言之,Longhorn所做的是使用Kubernetes節點的現有磁碟為Kubernetes Pod提供穩定的存儲。
  • 面對大規模容器的應用,對象存儲無疑是更好的選擇
    大規模容器部署,傳統存儲掛載效率低 容器的誕生並不是為OS抽象服務的,這是它和虛擬機最大的區別,這意味著容器天生是為應用環境的適配而服務,容器的伸縮也是基於容器的「一次性」特性。與之相對的,實現數據持久化的存儲方案的特徵剛好相反。容器提供的存儲解決方案是利用卷接口形成數據的映射和轉移,以實現數據持久化的目的,但這會造成資源的浪費和更多交互的發生。尤其對於那些無需修改文件內容的應用而言,如果底層採用塊存儲或文件存儲,每次讀取數據都需要將存儲資源掛載到本地,會嚴重影響業務效率。
  • 讓混合雲存儲更簡單,IBM有何神奇「魔法」?
    三是,雲環境,容器和雲原生的流行給企業的數據中心基礎設施帶來了重大挑戰,存儲就是首當其衝,因此採用可在混合多雲環境下匯總部署的存儲功能變得更加迫切,其中容器化將是最為關鍵的賦能技術,但容器也具有「召之即來,揮之即去」的特點,加上目前大部分的存儲架構都不是為容器應用持久化而設計和開發的,這樣就造成二者的「矛盾」越演越烈,這也對容器持久化存儲提出了新的要求。
  • 大規模部署容器的正確姿勢——你的存儲方案選對了嗎?
    大規模容器部署,傳統存儲掛載效率低 容器的誕生並不是為OS抽象服務的,這是它和虛擬機最大的區別,這意味著容器天生是為應用環境的適配而服務,容器的伸縮也是基於容器的「一次性」特性。與之相對的,實現數據持久化的存儲方案的特徵剛好相反。
  • 容器數據存儲當前發展及未來前景淺析
    與此同時,由於應用和工作負載的不同,容器數據存儲的類型也多種多樣。在本篇文章中,我們提取了行業分析機構 Taneja Group 和 TechTarget 高級編輯 Stacey Peterson,針對多雲架構趨勢、容器部署情況、以及不同容器數據存儲類型等問題的洞察。
  • Docker動手教程4.1:容器存儲1
    內容摘要容器掛載主機目錄容器掛載主機文件應用程式往往會使用資料庫或者文件系統保存數據.比如web應用,需要保存靜態網頁和用戶數據。對容器而言,裡面運行的應用程式同樣有持久化數據的需要,容器啟動時需要加載數據,銷毀時需要保留數據。本節帶大家深入探討容器如何使用存儲。
  • Serverless 應用如何管理日誌 & 持久化數據
    導讀:本節課程有三部分內容,分別介紹在 SAE 上查看應用的實時日誌,文件日誌以及通過 NAS 進行應用數據的持久化存儲。NAS 持久化存儲由於存儲在容器中數據是非持久化的,SAE 支持了 NAS 存儲功能,解決了應用實例數據持久化和實例間多讀共享數據的問題。
  • Pika-持久化的大容量Redis存儲服務
    Pika是一個可持久化的大容量Redis存儲服務,兼容String、Hash、List、ZSet、Set的絕大部分接口,解決Redis由於存儲數據量巨大而導致內存不夠用的容量瓶頸。Pika基於Rocksdb開發的大容量類Redis存儲,通過持久化存儲方式解決Redis在大容量場景下主從同步代價高、恢復時間慢、單線程相對脆弱、內存成本高等問題。
  • 應用容器化之Kubernetes實踐
    本次分享主要以ZooKeeper、Redis、Kafka、MongoDB等應用容器化在Kubernetes平臺上面實踐。從計算、網絡、存儲方面解析應用在集成中的問題,以及部分傳統應用在容器化過程中設計的應用二次開發等問題。