<table id="km2im"></table>
  • <bdo id="km2im"><center id="km2im"></center></bdo>
    • 自動秒收錄
    • 軟件:1973
    • 資訊:56263|
    • 收錄網站:185720|

    IT精英團

    全網最全面的云原生存儲OpenEBS用戶指南

    全網最全面的云原生存儲OpenEBS用戶指南

    瀏覽次數:
    評論次數:
    編輯: 溫瑜
    信息來源: ITPUB
    更新日期: 2022-05-24 21:25:03
    摘要

    ?本文轉自weiliang的工作筆記,原文:https://weiliang-ms.github.io/wl-awesome/2.%E5%AE%B9%E5%99%A8/k8s/storage/Op

    • 正文開始
    • 相關閱讀
    • 推薦作品

    本文轉自魏亮的工作筆記。原文:https://weiliang-ms.github.io/wl-awesome/2.%E5%AE%B9%E5%99%A8/k8s/storage/OpenEBS.html.版權歸原作者所有。

    簡介

    什么是OpenEBS?

    OpenEBS是一個開源的云原生存儲解決方案,由CNCF基金會托管。目前這個項目處于沙盒階段。

    OpenEBS是一組存儲引擎,允許您為StatefulSet和Kubernetes平臺類型選擇正確的存儲解決方案。在高層次上,OpenEBS支持兩種類型的卷:——本地卷和復制卷。

    OpenEBS是Kubernetes本地超融合存儲解決方案,管理節點可用的本地存儲,并為有狀態工作負載提供本地或高度可用的分布式持久卷。作為一個完整的本地Kubernetes解決方案的另一個優勢是,管理員和開發人員可以使用Kubernetes提供的所有優秀工具,如kubectl、Helm、Prometheus、Grafana、Weave Scope等。交互和管理OpenEBS。

    OpenEBS能做什么?

    OpenEBS管理k8s節點上的存儲,并為k8s StatefulSet提供本地存儲卷或分布式存儲卷。

    本地卷(本地存儲)

    OpenEBS可以使用主機原始塊設備或分區,或者主機路徑上的子目錄,或者LVM和ZFS來創建持久卷。

    本地卷直接掛載在Stateful Pod中,在OpenEBS的數據路徑中沒有任何開銷。

    OpenEBS為本地卷監控、備份/恢復、災難恢復、ZFS或LVM支持的快照等提供了額外的工具。

    對于分布式卷(即復制卷)

    OpenEBS使用其中一個引擎(Mayastor、cStor或Jiva)為每個分布式持久卷創建微服務。

    有狀態Pod將數據寫入OpenEBS引擎,OpenEBS引擎將數據同步復制到集群中的多個節點。OpenEBS引擎本身部署為Pod,由Kubernetes協調。當運行Stateful Pod的節點出現故障時,Pod將被重新調度到集群中的另一個節點,OpenEBS將使用其他節點上的可用數據副本來提供對數據的訪問。

    有狀態pod使用iSCSI(

    cStor和 Jiva) 或 NVMeoF(Mayastor) 連接 OpenEBS 分布式持久卷
  • OpenEBS cStorJiva專注于存儲的易用性和持久性。它們分別使用自定義版本的 ZFSLonghorn技術將數據寫入存儲。OpenEBS Mayastor是最新開發的以耐久性和性能為設計目標的引擎,高效地管理計算 (大頁面、核心) 和存儲 (NVMe Drives),以提供快速分布式塊存儲
  • ?

    注意OpenEBS分布式塊卷被稱為復制卷,以避免與傳統的分布式塊存儲混淆,傳統的分布式塊存儲傾向于將數據分布到集群中的許多節點上。復制卷是為云原生有狀態工作負載設計的,這些工作負載需要大量的卷,這些卷的容量通??梢詮膯蝹€節點提供,而不是使用跨集群中的多個節點分片的單個大卷

    對比傳統分布式存儲

    OpenEBS與其他傳統存儲解決方案不同的幾個關鍵方面 :

    • 使用微服務體系結構構建,就像它所服務的應用程序一樣。OpenEBS本身作為一組容器部署在 Kubernetes工作節點上。使用 Kubernetes本身來編排和管理 OpenEBS組件
    • 完全建立在用戶空間,使其高度可移植性,以運行在任何操作系統 / 平臺。
    • 完全意圖驅動,繼承了 Kubernetes易用性的相同原則
    • OpenEBS支持一系列存儲引擎,因此開發人員可以部署適合于其應用程序設計目標的存儲技術。像 Cassandra這樣的分布式應用程序可以使用 LocalPV引擎進行最低延遲的寫操作。像 MySQLPostgreSQL這樣的單片應用程序可以使用使用 NVMeSPDK構建的 Mayastor或基于 ZFScStor來實現彈性。像 Kafka這樣的流媒體應用程序可以在邊緣環境中使用 NVMe引擎 Mayastor以獲得最佳性能。

    驅使用戶使用 OpenEBS的主要原因是 :

    • 在所有的 Kubernetes發行版上都是可移植的
    • 提高了開發人員和平臺 SRE的生產力
    • 與其他解決方案相比,易于使用
    • 優秀的社區支持
    • 免費開源

    本地卷類型

    本地卷只能從集群中的單個節點訪問。必須在提供卷的節點上調度使用 Local VolumePods。本地卷通常是分布式工作負載的首選,比如 Cassandra、MongoDB、Elastic等,這些工作負載本質上是分布式的,并且內置了高可用性(分片)

    根據附加到 Kubernetes工作節點上的存儲類型,您可以從不同的動態本地 PV進行選擇——Hostpath、Device、LVM、ZFSRawfile

    可復制卷類型

    復制卷顧名思義,是指將數據同步復制到多個節點的卷。卷可以支持節點故障。還可以跨可用性區域設置復制,以幫助應用程序跨可用性區域移動。

    復制卷還能夠提供像快照、克隆、卷擴展等企業存儲特性。復制卷是有狀態工作負載 (如 Percona/MySQL、Jira、GitLab等) 的首選。

    根據附加到 Kubernetes工作節點的存儲類型和應用程序性能需求,您可以從 Jiva、cStorMayastor中進行選擇

    OpenEBS 存儲引擎建議

    應用需求存儲類型OpenEBS 卷類型
    低時延、高可用性、同步復制、快照、克隆、精簡配置SSD/ 云存儲卷OpenEBS Mayastor
    高可用性、同步復制、快照、克隆、精簡配置機械 /SSD/ 云存儲卷OpenEBS cStor
    高可用性、同步復制、精簡配置主機路徑或外部掛載存儲OpenEBS Jiva
    低時延、本地 PV主機路徑或外部掛載存儲Dynamic Local PV - Hostpath, Dynamic Local PV - Rawfile
    低時延、本地 PV本地機械 /SSD/ 云存儲卷等塊設備Dynamic Local PV - Device
    低延遲,本地 PV,快照,克隆本地機械 /SSD/ 云存儲卷等塊設備OpenEBS Dynamic Local PV - ZFS , OpenEBS Dynamic Local PV - LVM

    總結:

    • 多機環境,如果有額外的塊設備(非系統盤塊設備)作為數據盤,選用 OpenEBS Mayastor、OpenEBS cStor
    • 多機環境,如果沒有額外的塊設備(非系統盤塊設備)作為數據盤,僅單塊系統盤塊設備,選用 OpenEBS Jiva
    • 單機環境,建議本地路徑 Dynamic Local PV - Hostpath, Dynamic Local PV - Rawfile,由于單機多用于測試環境,數據可靠性要求較低。

    由此看來,OpenEBS常用場景為以上三個場景

    OpenEBS 特性

    容器附加存儲

    OpenEBS是一個容器附加存儲 (Container Attached Storage, CAS) 的例子。通過 OpenEBS提供的卷總是被容器化。每個卷都有一個專用的存儲控制器,用于提高有狀態應用程序的持久性存儲操作的敏捷性和粒度。

    同步復制

    同步復制是 OpenEBS的一個可選的流行特性。當與 Jiva、cStorMayastor存儲引擎一起使用時,OpenEBS可以同步復制數據卷以實現高可用性???Kubernetes區域進行復制,從而為跨 AZ設置提供高可用性。這個特性對于使用 GKE、EKSAKS等云提供商服務上的本地磁盤構建高可用狀態應用程序特別有用

    快照和克隆

    寫時拷貝快照是 OpenEBS另一個可選的流行特性。使用 cStor引擎時,快照是瞬時創建的,并且不受快照個數的限制。增量快照功能增強了跨 Kubernetes集群和跨不同云提供商或數據中心的數據遷移和可移植性。對快照和克隆的操作完全以 Kubernetes原生方法執行,使用標準 kubectl命令。常見的用例包括用于備份的高效復制和用于故障排除或針對數據的只讀副本進行開發的克隆

    備份和恢復

    OpenEBS卷的備份和恢復可以通過開源的 OpenEBS Velero插件與 Kubernetes備份和恢復解決方案 (如 Velero(前身為 Heptio Ark)) 協同工作。經常使用 OpenEBS增量快照功能,將數據備份到 AWS S3、GCP object storage、MinIO等對象存儲目標。這種存儲級別的快照和備份只使用增量數據進行備份,節省了大量的帶寬和存儲空間。

    真正的 Kubernetes 云原生存儲

    OpenEBSKubernetes上有狀態應用程序的云原生存儲,云原生意味著遵循松散耦合的體系結構。因此,云原生、松散耦合體系結構的一般好處是適用的。例如,開發人員和 DevOps架構師可以使用標準的 Kubernetes技能和實用程序來配置、使用和管理持久存儲需求

    減少存儲 TCO 高達 50%

    在大多數云上,塊存儲的收費是基于購買的多少,而不是使用的多少 ; 為了實現更高的性能,并在充分利用容量時消除中斷的風險,容量經常被過度配置。OpenEBS的精簡配置能力可以共享本地存儲或云存儲,然后根據需要增加有狀態應用程序的數據量??梢詣討B添加存儲,而不會中斷暴露給工作負載或應用程序的卷。某些用戶報告說,由于使用了 OpenEBS的精簡配置,節省了超過 60%的資源。

    高可用性

    由于 OpenEBS遵循 CAS架構,在節點故障時,Kubernetes將重新調度 OpenEBS控制器,而底層數據則通過使用一個或多個副本來保護。更重要的是——因為每個工作負載都可以利用自己的 OpenEBS——不存在因存儲丟失而導致系統大范圍宕機的風險。例如,卷的元數據不是集中的,它可能會像許多共享存儲系統那樣受到災難性的通用中斷的影響。相反,元數據保持在卷的本地。丟失任何節點都會導致只存在于該節點上的卷副本的丟失。由于卷數據至少在其他兩個節點上進行了同步復制,因此當一個節點出現故障時,這些數據將在相同的性能級別上繼續可用

    CAS 介紹

    CAS或容器附加存儲 (Container Attached Storage) 體系結構中,存儲在容器中運行,并且與存儲綁定到的應用程序密切相關。存儲作為微服務運行,沒有內核模塊依賴關系。像 Kubernetes這樣的編排系統編排存儲卷,就像任何其他微服務或容器一樣。CAS具有 DASNAS的優點

    非 CAS 系統上的 PV

    在非 CAS模型中,Kubernetes持久卷仍然與內核模塊緊密耦合,使得 Kubernetes節點上的存儲軟件本質上是單片的

    基于 CAS 系統上的 PV

    相反,CAS使您能夠利用云原生應用程序的靈活性和可伸縮性。定義 Kubernetes PV (Persistent Volume)的存儲軟件是基于微服務架構的。存儲軟件的控制平面 (存儲控制器) 和數據平面 (存儲副本) 作為 Kubernetes Pods運行,因此,使您能夠將云原生的所有優勢應用到 CAS。

    CAS 優勢

    • 敏捷

    CAS中的每個存儲卷都有一個容器化的存儲控制器和相應的容器化副本。因此,圍繞這些組件的資源的維護和調優是真正敏捷的。Kubernetes滾動升級功能可以實現存儲控制器和存儲副本的無縫升級??梢允褂萌萜?cGroups調優 CPU和內存等資源配額。

    • 存儲策略粒度化

    將存儲軟件容器化并將存儲控制器專用于每個卷可以帶來最大的存儲策略粒度。在 CAS體系結構中,可以按卷配置所有存儲策略。此外,您可以監視每個卷的存儲參數,并動態更新存儲策略,以實現每個工作負載的預期結果。隨著卷存儲策略中這種額外粒度級別的增加,存儲吞吐量、IOPS和延遲的控制也會增加。

    • 云原生

    CAS將存儲軟件裝入容器,并使用 Kubernetes自定義資源定義 (CRDs) 來聲明低級存儲資源,如磁盤和存儲池。這個模型使存儲能夠無縫地集成到其他云原生工具中??梢允褂?Prometheus、Grafana、Fluentd、Weavescope、Jaeger等云原生工具來供應、監控和管理存儲資源

    • PVCAS中的一個微服務

    如上圖所示,在 CAS架構中,存儲控制器和副本的軟件完全是基于微服務的,因此不涉及內核組件。通常,存儲控制器 POD被調度在與持久卷相同的節點上,以提高效率,副本 POD可以被調度在集群節點上的任何位置。每個副本使用本地磁盤、SAN磁盤和云磁盤的任意組合完全獨立于其他副本進行配置。這為大規模管理工作負載的存儲分配提供了巨大的靈活性。

    • 超融合非分布式

    CAS架構沒有遵循典型分布式存儲架構。通過從存儲控制器到存儲副本的同步復制,存儲變得高度可用。卷副本的元數據不是在節點之間共享的,而是在每個本地節點上獨立管理。如果一個節點故障,存儲控制器 (在本例中是一個無狀態容器) 將在一個節點上輪轉,該節點上運行著第二個或第三個副本,數據仍然可用。

    與超融合系統類似,CAS中的卷的存儲和性能是可擴展的。由于每個卷都有自己的存儲控制器,因此存儲可以在一個節點的存儲容量允許的范圍內進行擴展。在給定的 Kubernetes集群中,隨著容器應用程序數量的增加,會增加更多的節點,從而提高存儲容量和性能的整體可用性,從而使存儲對新的應用程序容器可用。這一過程與 Nutanix等成功的超融合系統非常相似。

    OpenESB 架構介紹

    OpenESB遵循容器附加存儲(CAS)模型,每個卷都有一個專用的控制器 POD和一組副本 POD。CAS體系結構的優點在`CNCF` 博客[1]上進行了討論。OpenEBS操作和使用都很簡單,因為它看起來和感覺上就像其他云原生和 Kubernetes友好的項目。

    OpenEBS有許多組件,可以分為以下類別 :

    • 控制面組件 - Provisioner, API Server, volume exports,volume sidecars
    • 數據面組件 - Jiva、cStor
    • 節點磁盤管理器 - Discover, monitor, 管理連接 k8s的媒介
    • 與云原生工具的集成 - 已經與 Prometheus,Grafana, Fluentd、Jaeger集成

    控制面

    OpenEBS集群的控制平面通常被稱為Maya。

    OpenEBS控制平面負責提供卷、相關的卷操作,如快照、克隆、創建存儲策略、執行存儲策略、導出 Prometheus/grafana使用的卷指標,等等。

    OpenEBS提供了一個動態提供程序,這是 Kubernetes的標準外部存儲插件。OpenEBS PV提供者的主要任務是向應用程序 PODS啟動卷供應,并實現 PVKubernetes規范。

    m-apiserver開放存儲的 REST API,并承擔大量卷策略處理和管理工作。

    控制平面和數據平面之間的連通性使用 Kubernetes sidecar模式??刂破矫嫘枰c數據平面通信的場景如下所示。

    • 對于卷的統計,如 IOPS,吞吐量,延遲等--通過卷暴漏的 sidecar實現
    • 使用卷控制器 pod執行卷策略,使用卷副本 pod進行磁盤 / 池管理-通過卷管理 sidecar實現

    OpenEBS PV Provisioner

    此組件作為 POD運行,并做出配置決策 , 它的使用方式是 :

    開發人員用所需的卷參數構造一個聲明,選擇適當的存儲類,并在 YAML規范上調用 kubelet。OpenEBS PV動態提供程序與 maya-apiserver交互,在適當的節點上為卷控制器 pod和卷副本 pod創建部署規范??梢允褂?PVC規范中的注釋來控制卷 Pod(控制器 / 副本) 的調度。

    目前,OpenEBS Provisioner只支持一種綁定類型,即 iSCSI。

    Maya-ApiServer

    m-apiserver作為POD運行。顧名思義,m-apiserver公開OpenEBS REST api`。

    m-apiserver還負責創建創建卷 pod所需的部署規范文件。在生成這些規范文件之后,它將調用 kube-apiserver來相應地調度這些 pods。OpenEBS PV提供者在卷發放結束時,將創建一個 PV對象并將其掛載到應用程序 pod上。PV由控制器 pod承載,控制器 pod由不同節點中的一組副本 pod支持??刂破?pod和復制 pod是數據平面的一部分,在存儲引擎部分有更詳細的描述。

    m-apiserver的另一個重要任務是卷策略管理。OpenEBS為表示策略提供了非常細粒度的規范。m-apiserver解釋這些 YAML規范,將它們轉換為可執行的組件,并通過容量管理 sidecar來執行它們

    Maya Volume Exporter

    Maya卷導出器是每個存儲控制器podsidecar`。

    這些 sidecar將控制平面連接到數據平面以獲取統計信息。統計信息的粒度在卷級別。一些統計數據示例如下:

    • 卷讀取延遲
    • 卷寫入延遲
    • 卷每秒讀取速度
    • 卷每秒寫入速度
    • 讀取塊大小
    • 寫入塊大小
    • 容量統計

    這些統計信息通常由 Prometheus客戶端來拉取,該客戶端在 OpenBS安裝期間安裝和配置。

    卷管理 sidecar

    Sidecars還用于將控制器配置參數和卷策略傳遞給卷控制器 pod(卷控制器 pod是一個數據平面), 并將副本配置參數和副本數據保護參數傳遞給卷副本 pod。

    數據面

    OpenEBS數據平面負責實際的卷 IO路徑。存儲引擎在數據平面實現實際的 IO路徑。目前,OpenEBS提供了兩個可以輕松插入的存儲引擎。它們被稱為 JivacStor。這兩個存儲引擎都完全運行在 Linux用戶空間中,并基于微服務架構。

    Jiva

    Jiva存儲引擎基于 Rancher's LongHorngotgt開發實現, 使用 go語言開發,并運行于用戶命名空間下。LongHorn控制器將輸入的 IO同步復制到 LongHorn副本。該副本將 Linux稀疏文件視為構建存儲特性 (如精簡配置、快照、重建等) 的基礎。

    cStor

    cStor數據引擎使用 C語言編寫,具有高性能的 iSCSI targetCopy-On-Write塊系統,提供數據完整性、數據彈性和時間點的快照和克隆。cStor有一個池特性,它以條帶、鏡像或 RAIDZ模式聚合一個節點上的磁盤,以提供更大的容量和性能單位。cStor還可以跨區域將數據同步復制到多個節點,從而避免節點丟失或節點重啟導致數據不可用。

    LocalPV

    對于那些不需要存儲級復制的應用程序,LocalPV可能是很好的選擇,因為它能提供更高的性能。OpenEBS LocalPVKubernetes LocalPV類似,不同之處在于它是由 OpenEBS控制平面動態提供的, 就像任何其他常規 PV一樣。OpenEBS LocalPV有兩種類型 :hostpath LocalPVdevice LocalPV。hostpath LocalPV指的是主機上的子目錄,LocalPV指的是在節點上發現的磁盤 (可以是直接連接的,也可以是網絡連接的)。OpenEBS引入了一個 LocalPV提供者,用于根據 PVC和存儲類規范中的一些標準選擇匹配的磁盤或主機路徑。

    節點磁盤管理器

    節點磁盤管理器 (NDM) 填補了使用 Kubernetes管理有狀態應用程序的持久存儲所需的工具鏈的空白。容器時代的 DevOps架構師必須以一種自動化的方式滿足應用程序和應用程序開發人員的基礎設施需求, 這種方式可以跨環境提供彈性和一致性。這些要求意味著存儲堆棧本身必須非常靈活, 以便 Kubernetes和云原生生態系統中的其他軟件可以輕松地使用這個堆棧。NDMKubernetes的存儲堆棧中起著基礎性的作用,它統一了不同的磁盤, 并通過將它們標識為 Kubernetes對象,提供了將它們匯聚的能力。此外,NDM發現、提供、監視和管理底層磁盤的方式,可以讓 Kubernetes PV提供者 (如 OpenEBS和其他存儲系統) 和 Prometheus管理磁盤子系統

    CAS 引擎

    存儲引擎概述

    存儲引擎是持久化卷 IO路徑的數據平面組件。在 CAS架構中,用戶可以根據不同的配置策略,為不同的應用工作負載選擇不同的數據平面。存儲引擎可以通過特性集或性能優化給定的工作負載。

    操作員或管理員通常選擇具有特定軟件版本的存儲引擎,并構建優化的卷模板, 這些卷模板根據底層磁盤的類型、彈性、副本數量和參與 Kubernetes集群的節點集進行微調。用戶可以在發放卷時選擇最優的卷模板,從而在給定的 Kubernetes集群上為所有存儲卷運行最優的軟件和存儲組合提供最大的靈活性。

    存儲引擎類型

    OpenEBS提供了三種存儲引擎

    • Jiva

      JivaOpenEBS 0.1版中發布的第一個存儲引擎,使用起來最簡單。它基于 GoLang開發,內部使用 LongHorngotgt堆棧。 Jiva完全在用戶空間中運行,并提供同步復制等標準塊存儲功能。 Jiva通常適用于容量較小的工作負載,不適用于大量快照和克隆特性是主要需求的情況

    • cStor

      cStorOpenEBS 0.7版本中最新發布的存儲引擎。cStor非常健壯,提供數據一致性,很好地支持快照和克隆等企業存儲特性。 它還提供了一個健壯的存儲池特性,用于在容量和性能方面進行全面的存儲管理。 cStorNDM(Node Disk Manager) 一起,為 Kubernetes上的有狀態應用程序提供完整的持久化存儲特性

    • OpenEBS Local PV

      OpenEBS Local PV是一個新的存儲引擎,它可以從本地磁盤或工作節點上的主機路徑創建持久卷或 PV。 CAS引擎可以從 OpenEBS1.0.0版本中獲得。使用 OpenEBS Local PV,性能將等同于創建卷的本地磁盤或文件系統 (主機路徑)。 許多云原生應用程序可能不需要復制、快照或克隆等高級存儲特性,因為它們本身就提供了這些特性。這類應用程序需要以持久卷的形式訪問管理的磁盤

    • SP  存儲池,表示 Jiva自定義存儲資源
    • CV cStor卷,表示 cStor卷自定義資源
    • CVR cStor卷副本
    • SPC 存儲池聲明,表示 cStor池聚合的自定義資源
    • CSP cStor存儲池,表示 cStor Pool每個節點上的自定義資源

    一個 SPC對應多個 CSP,相應的一個 CV對應多個 CVR

    存儲引擎聲明

    通過指定注釋 openebs來選擇存儲引擎。StorageClass規范中的 io/cas-type。StorageClass定義了提供程序的細節。為每個 CAS引擎指定單獨的供應程序。

    cStor 存儲類規范文件內容

    ---
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: cStor-storageclass
      annotations:
        openebs.io/cas-type: cstor
        cas.openebs.io/config: |
          - name: StoragePoolClaim
            value: "cStorPool-SSD"
    provisioner: openebs.io/provisioner-iscsi
    ---

    Jiva 存儲類規范文件內容

    ---
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: jiva-storageclass
      annotations:
        openebs.io/cas-type: jiva
        cas.openebs.io/config: |
          - name: StoragePool
            value: default
    provisioner: openebs.io/provisioner-iscsi
    ---

    cas類型為 Jiva時,StoragePooldefault值具有特殊含義。當 pool為默認值時,Jiva引擎將從容器 (副本 pod) 本身的存儲空間中為副本 pod開辟數據存儲空間。當所需的卷大小很小 (比如 5G10G) 時,StoragePool default工作得很好,因為它可以容納在容器本身內。

    Local PV 存儲類規范文件內容-主機路徑

    ---
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: localpv-hostpath-sc
      annotations:
        openebs.io/cas-type: local
        cas.openebs.io/config: |
          - name: BasePath
            value: "/var/openebs/local"
          - name: StorageType
            value: "hostpath"
    provisioner: openebs.io/local
    ---

    Local PV 存儲類規范文件內容-主機設備

    ---
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: localpv-device-sc
      annotations:
        openebs.io/cas-type: local
        cas.openebs.io/config: |
          - name: StorageType
            value: "device"
          - name: FSType
            value: ext4
    provisioner: openebs.io/local
    ---

    cStor、Jiva、LocalPV特性比較:

    特性JivacStorLocal PV
    輕量級運行于用戶空間YesYesYes
    同步復制YesYesNo
    適合低容量工作負載YesYesYes
    支持快照,克隆BasicAdvancedNo
    數據一致性YesYesNA
    使用 Velero 恢復備份YesYesYes
    適合高容量工作負載NoYesYes
    自動精簡配置
    YesNo
    磁盤池或聚合支持
    YesNo
    動態擴容
    YesYes
    數據彈性 (RAID 支持)
    YesNo
    接近原生磁盤性能NoNoYes

    大多數場景推薦 cStor,因其提供了強大的功能,包括快照 / 克隆、存儲池功能(如精簡資源調配、按需擴容等)。

    Jiva適用于低容量需求的工作負載場景,例如 550G。盡管使用 Jiva沒有空間限制,但建議將其用于低容量工作負載。Jiva非常易于使用,并提供企業級容器本地存儲,而不需要專用硬盤。有快照和克隆功能的需求的場景,優先考慮使用 cStor而不是 Jiva。

    CAS 引擎使用場景

    如上表所示,每個存儲引擎都有自己的優勢。選擇引擎完全取決于應用程序的工作負載以及它當前和未來的容量和 / 或性能增長。下面的指導原則在定義存儲類時為選擇特定的引擎提供一些幫助。

    選擇 cStor 的理想條件

    • 當需要同步復制數據并在節點上有多個磁盤時
    • 當您從每個節點上的本地磁盤或網絡磁盤池管理多個應用程序的存儲時。通過精簡配置、存儲池和卷的按需擴容、存儲池的性能按需擴容等特性,實現對存儲層的管理。cStor用于在本地運行的 Kubernetes集群上構建 Kubernetes本地存儲服務,類似于 AWS EBS或谷歌 PD。
    • 當需要存儲級快照和克隆能力時
    • 當您需要企業級存儲保護特性,如數據一致性、彈性 (RAID保護)。
    • 如果您的應用程序不需要存儲級復制,那么使用 OpenEBS主機路徑 LocalPVOpenEBS設備 LocalPV可能是更好的選擇。

    選擇 Jiva 的理想條件 :

    • 當您想要數據的同步復制,并且擁有單個本地磁盤或單個管理磁盤 (如云磁盤 (EBS、GPD)),并且不需要快照或克隆特性時

    • Jiva是最容易管理的,因為磁盤管理或池管理不在這個引擎的范圍內。Jiva池是本地磁盤、網絡磁盤、虛擬磁盤或云磁盤的掛載路徑。

    • 以下場景 Jiva 更優于 cStor :

      • 當程序不需要存儲級的快照、克隆特性
      • 當節點上沒有空閑磁盤時。Jiva可以在主機目錄上使用,并且仍然可以實現復制。
      • 當不需要動態擴展本地磁盤上的存儲時。將更多磁盤添加到 Jiva池是不可能的,因此 Jiva池的大小是固定的,如果它在物理磁盤上。但是,如果底層磁盤是虛擬磁盤、網絡磁盤或云磁盤,則可以動態地更改 Jiva池的大小
      • 容量需求較小。大容量應用通常需要動態增加容量,cStor更適合這種需求

    選擇 OpenEBS 主機路徑 LocalPV 的理想條件 :

    • 當應用程序本身具備管理復制能力(例如:es)時,不需要在存儲層進行復制。在大多數這樣的情況下,應用程序是作為 statefulset部署的
    • 高于 JivacStor的讀寫性能需求
    • 當特定應用程序沒有專用的本地磁盤或特定應用程序不需要專用的存儲時,建議使用 Hostpath。如果您想跨多個應用程序共享一個本地磁盤,主機路徑 LocalPV是正確的方法

    選擇 OpenEBS 主機設備 LocalPV 的理想條件 :

    • 當應用程序管理復制本身,不需要在存儲層進行復制時。在大多數這種情況下,應用程序被部署為有狀態集
    • 高于 JivacStor的讀寫性能需求
    • 高于 OpenEBS主機路徑 LocalPV的讀寫性能需求
    • 當需要接近磁盤性能時。該卷專用于寫入單個 SSDNVMe接口以獲得最高性能

    總結

    • 如果應用程序處于生產中,并且不需要存儲級復制,那么首選 LocalPV
    • 如果您的應用程序處于生產狀態,并且需要存儲級復制,那么首選 cStor
    • 如果應用程序較小,需要存儲級復制,但不需要快照或克隆,則首選 Jiva

    節點磁盤管理器(NDM)

    節點磁盤管理器 (NDM) 是 OpenEBS體系結構中的一個重要組件。NDM將塊設備視為需要監視和管理的資源,就像 CPU、內存和網絡等其他資源一樣。它是一個在每個節點上運行的守護進程,基于過濾器檢測附加的塊設備,并將它們作為塊設備自定義資源加載到 Kubernetes中。這些定制資源旨在通過提供類似于 :

    • 輕松訪問 Kubernetes集群中可用的塊設備清單
    • 預測磁盤的故障,以幫助采取預防措施
    • 允許動態地將磁盤掛載 / 卸載到存儲 Pod中,而無需重新啟動在磁盤掛載 / 卸載的節點上運行的相應 NDM Pod

    盡管做了上述所有工作,NDM還是有助于提供持久卷的總體簡化。

    NDM是在 OpenEBS安裝期間作為守護進程部署的。NDM daemonset發現每個節點上的磁盤,并創建一個名為 Block DeviceBD的自定義資源。

    訪問權限說明

    NDM守護進程運行在容器中,必須訪問底層存儲設備并以特權模式運行。NDM需要特權模式,因為它需要訪問 /dev、/proc/sys目錄來監視附加設備,還需要使用各種探測器獲取附加設備的詳細信息。NDM負責發現塊設備并過濾掉不應該被 OpenEBS使用的設備 ; 例如,檢測有 OS文件系統的磁盤。NDM pod默認情況下在容器中掛載主機的 /proc目錄,然后加載 /proc/1/mounts,以找到操作系統使用的磁盤

    NDM 守護程序功能

    • 發現 Kubernetes節點上的塊設備

      • 在啟動時發現塊設備-創建和 / 或更新狀態。
      • 維護集群范圍內磁盤的唯一 id: 對 WWN / PartitionUUID / FileSystemUUID / DeviceMapperUUID進行 Hash計算
    • 檢測節點中添加 / 移除塊設備,并更新塊設備狀態

    • 添加塊設備作為 Kubernetes自定義資源,具有以下屬性:
      • Active: 節點上存在塊設備
      • Inactive: 給定節點上不存在塊設備
      • Unknown: NDM在塊設備最后被檢測到的節點上停止 / 無法確定狀態
      • 主機名稱 (kubernetes.io/hostname)
      • 塊設備類型 (ndm.io/blockdevice-type)
      • Managed (ndm.io/managed)
      • 設備路徑
      • 設備鏈接
      • 供應商和型號信息
      • WWN和序列號
      • 容量
      • 扇區和區塊大小
      • spec: 如果可用,將更新以下內容
      • labels:
      • status: 狀態可以有以下值

    過濾器

    • 為要創建塊設備 CR的塊設備類型配置過濾器。過濾器可以通過供應商類型、設備路徑模式或掛載點進行配置

    • 過濾器可以是包含過濾器,也可以是排除過濾器。它們被配置為 configmap。管理員用戶可以在 OpenEBS安裝時通過更改 OpenEBS操作員 yaml文件或 helm值中的 NDM configmap來配置這些過濾器。yaml文件。如果這些過濾器需要在安裝后更新,那么可以遵循以下方法之一 :

      • 使用 operator方式安裝 OpenEBS。在 Yaml文件中,更新 configmap中的過濾器并應用 operator.yaml
      • 如果 OpenEBS是使用 helm安裝的,更新 values.yaml中的 configmap并使用 helm進行升級
      • 或者,使用 kubectl編輯 NDM configmap,更新過濾器

    落地實踐

    OpenEBScStorJiva引擎由于組件過多,配置相較其他存儲方案繁瑣,生產環境不建議使用,這里我們僅論述 Local PV引擎。

    Local PV引擎不具備存儲級復制能力,適用于 k8s有狀態服務的后端存儲(如 : es、redis等)

    Local PV Hostpath 實踐

    對比 Kubernetes Hostpath卷相比,OpenEBS 本地 PV Hostpath卷具有以下優勢 :

    • OpenEBS本地 PV Hostpath允許您的應用程序通過 StorageClass、PVCPV訪問 Hostpath。這為您提供了更改 PV提供者的靈活性,而無需重新設計應用程序 YAML
    • 使用 Velero備份和恢復進行數據保護
    • 通過對應用程序 YAMLpod完全屏蔽主機路徑來防范主機路徑安全漏洞

    環境依賴 :

    • k8s 1.12以上
    • OpenEBS 1.0以上

    實踐環境 :

    • docker 19.03.8
    • k8s 1.18.6
    • CentOS7
    $ kubectl get node
    NAME    STATUS   ROLES           AGE     VERSION
    node1   Ready    master,worker   8m8s    v1.18.6
    node2   Ready    master,worker   7m15s   v1.18.6
    node3   Ready    master,worker   7m15s   v1.18.6

    創建數據目錄

    在將要創建 Local PV Hostpaths的節點上設置目錄。這個目錄將被稱為 BasePath。默認位置是 /var/openebs/local

    節點 node1、node2、node3創建 /data/openebs/local目錄 (/data 可以預先掛載數據盤,如未掛載額外數據盤,則使用操作系統 '/' 掛載點存儲空間)

    $ mkdir -p /data/openebs/local

    下載應用描述文件

    yaml 文件[2]

    發布 openebs應用

    根據上述配置文件,保證 k8s集群可訪問到如下鏡像(建議導入本地私有鏡像庫,如 : harbor

    openebs/node-disk-manager:1.5.0
    openebs/node-disk-operator:1.5.0
    openebs/provisioner-localpv:2.10.0

    更新 openebs-operator.yaml中鏡像 tag為實際 tag

    image: openebs/node-disk-manager:1.5.
    image: openebs/node-disk-operator:1.5.
    image: openebs/provisioner-localpv:2.10.

    發布

    $ kubectl apply -f openebs-operator.yaml

    查看發布狀態

    $ kubectl get pod -n openebs -w
    NAME                                           READY   STATUS    RESTARTS   AGE
    openebs-localpv-provisioner-6d6d9cfc99-4sltp   1/1     Running             10s
    openebs-ndm-85rng                              1/1     Running             10s
    openebs-ndm-operator-7df6668998-ptnlq          /1     Running             10s
    openebs-ndm-qgqm9                              1/1     Running             10s
    openebs-ndm-zz7ps                              1/1     Running             10s

    創建存儲類

    更改配置文件中的內容

    value: "/var/openebs/local/"

    發布創建存儲類

    $ cat > openebs-hostpath-sc.yaml <<EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: openebs-hostpath
      annotations:
        openebs.io/cas-type: local
        cas.openebs.io/config: |
          #hostpath type will create a PV by
          # creating a sub-directory under the
          # BASEPATH provided below.
          - name: StorageType
            value: "hostpath"
          #Specify the location (directory) where
          # where PV(volume) data will be saved.
          # A sub-directory with pv-name will be
          # created. When the volume is deleted,
          # the PV sub-directory will be deleted.
          #Default value is /var/openebs/local
          - name: BasePath
            value: "/data/openebs/local/"
    provisioner: openebs.io/local
    volumeBindingMode: WaitForFirstConsumer
    reclaimPolicy: Delete
    EOF

    $ kubectl apply -f openebs-hostpath-sc.yaml

    創建 PVC 驗證可用性

    $ cat > local-hostpath-pvc.yaml <<EOF
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: local-hostpath-pvc
    spec:
      storageClassName: openebs-hostpath
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5G
    EOF

    $ kubectl apply -f local-hostpath-pvc.yaml

    查看 pvc狀態

    $ kubectl get pvc
    NAME                 STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
    local-hostpath-pvc   Pending                                      openebs-hostpath   2m15s

    輸出顯示 STATUSPending。這意味著 PVC還沒有被應用程序使用。

    創建 Pd

    $ cat > local-hostpath-pod.yaml <<EOF
    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-local-hostpath-pod
    spec:
      volumes:
      - name: local-storage
        persistentVolumeClaim:
          claimName: local-hostpath-pvc
      containers:
      - name: hello-container
        image: busybox
        command:
           - sh
           - -c
           - 'while true; do echo "`date` [`hostname`] Hello from OpenEBS Local PV." >> /mnt/store/greet.txt; sleep $(($RANDOM % 5 + 300)); done'
        volumeMounts:
        - mountPath: /mnt/store
          name: local-storage
    EOF

    發布創建

    $ kubectl apply -f local-hostpath-pod.yaml

    驗證數據是否寫入卷

    $ kubectl exec hello-local-hostpath-pod -- cat /mnt/store/greet.txt
    Thu Jun 24 15:10:45 CST 2021 [node1] Hello from OpenEBS Local PV.

    驗證容器是否使用 Local PV Hostpath 卷

    $ kubectl describe pod hello-local-hostpath-pod
    Name:         hello-local-hostpath-pod
    Namespace:    default
    Priority:     
    ...
    Volumes:
      local-storage:
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  local-hostpath-pvc
        ReadOnly:   false
      default-token-98scc:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-98scc
        Optional:    false
    ...

    查看 PVC 狀態

    $ kubectl get pvc local-hostpath-pvc
    NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
    local-hostpath-pvc   Bound    pvc-6eac3773-49ef-47af-a475-acb57ed15cf6   5G         RWO            openebs-hostpath   10m

    查看該 PV 卷數據存儲目錄為

    $ kubectl get -o yaml pv pvc-6eac3773-49ef-47af-a475-acb57ed15cf6|grep 'path:'
              f:path: {}
        path: /data/openebs/local/pvc-6eac3773-49ef-47af-a475-acb57ed15cf6

    并且 pv配置了親和性,制定了調度節點為 node2

    spec:
      accessModes:
      - ReadWriteOnce
      capacity:
        storage: 5G
      claimRef:
        apiVersion: v1
        kind: PersistentVolumeClaim
        name: local-hostpath-pvc
        namespace: default
        resourceVersion: "9034"
        uid: 6eac3773-49ef-47af-a475-acb57ed15cf6
      local:
        fsType: ""
        path: /data/openebs/local/pvc-6eac3773-49ef-47af-a475-acb57ed15cf6
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - node2
      persistentVolumeReclaimPolicy: Delete
      storageClassName: openebs-hostpath
      volumeMode: Filesystem

    結果證明數據僅存在于 node2下。

    清理 Pod

    $ kubectl delete pod hello-local-hostpath-pod

    基準測試

    下載基準測試 Job 聲明文件[3]

    調整以下內容

    image: openebs/perf-test:latest # 調整為內網鏡像庫tag
    claimName: dbench # 調整為local-hostpath-pvc

    發布運行

    $ kubectl create -f fio-deploy.yaml 

    查看運行狀態

    $ kubectl get pod
    NAME                 READY   STATUS    RESTARTS   AGE
    dbench-729cw-nqfpt   1/1     Running             24s

    查看基準測試結果

    $ kubectl logs -f dbench-729cw-nqfpt
    ...
    All tests complete.

    ==================
    = Dbench Summary =
    ==================
    Random Read/Write IOPS: 2144/6654. BW: 131MiB/s / 403MiB/s
    Average Latency (usec) Read/Write: 4254.08/3661.59
    Sequential Read/Write: 1294MiB/s / 157MiB/s
    Mixed Random Read/Write IOPS: 1350/443

    清理

    $ kubectl delete pvc local-hostpath-pvc
    $ kubectl delete sc openebs-hostpath

    Local PV Device 實踐

    對比 Kubernetes本地持久卷,OpenEBS本地 PV設備卷有以下優點 :

    • OpenEBS本地 PV設備卷 provider是動態的,Kubernetes設備卷 provider是靜態的
    • OpenEBS NDM更好地管理用于創建本地 pv的塊設備。NDM提供了發現塊設備屬性、設置設備篩選器、度量集合以及檢測塊設備是否已經跨節點移動等功能

    環境依賴 :

    • k8s 1.12以上
    • OpenEBS 1.0以上

    實踐環境 :

    • docker 19.03.8
    • k8s 1.18.6
    • CentOS7
    $ kubectl get node
    NAME    STATUS   ROLES           AGE     VERSION
    node1   Ready    master,worker   8m8s    v1.18.6
    node2   Ready    master,worker   7m15s   v1.18.6
    node3   Ready    master,worker   7m15s   v1.18.6

    三個節點上的 /dev/sdb作為塊設備存儲

    [root@node1 ~]# lsblk
    NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda               8:0      400G   disk
    ├─sda1            8:1        1G   part /boot
    └─sda2            8:2      399G   part
      └─centos-root 253:0      399G   lvm  /
    sdb               8:16      20G   disk
    sr0              11:0    1  4.4G   rom

    [root@node2 ~]# lsblk
        NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
        sda               8:0      400G   disk
        ├─sda1            8:1        1G   part /boot
        └─sda2            8:2      399G   part
          └─centos-root 253:0      399G   lvm  /
        sdb               8:16      20G   disk
        sr0              11:0    1  4.4G   rom

    [root@node3 ~]# lsblk
        NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
        sda               8:0      400G   disk
        ├─sda1            8:1        1G   part /boot
        └─sda2            8:2      399G   part
          └─centos-root 253:0      399G   lvm  /
        sdb               8:16      20G   disk
        sr0              11:0    1  4.4G   rom

    創建數據目錄

    在將要創建 Local PV Hostpaths的節點上設置目錄。這個目錄將被稱為 BasePath。默認位置是 /var/openebs/local

    節點 node1、node2、node3創建 /data/openebs/local目錄 (/data 可以預先掛載數據盤,如未掛載額外數據盤,則使用操作系統 '/' 掛載點存儲空間)

    $ mkdir -p /data/openebs/local

    下載應用描述文件

    yaml 文件[4]

    發布 openebs 應用

    根據上述配置文件,保證 k8s集群可訪問到如下鏡像(建議導入本地私有鏡像庫,如 : harbor

    openebs/node-disk-manager:1.5.0
    openebs/node-disk-operator:1.5.0
    openebs/provisioner-localpv:2.10.0

    更新 openebs-operator.yaml中鏡像 tag為實際 tag

    image: openebs/node-disk-manager:1.5.
    image: openebs/node-disk-operator:1.5.
    image: openebs/provisioner-localpv:2.10.

    發布

    $ kubectl apply -f openebs-operator.yaml

    查看發布狀態

    $ kubectl get pod -n openebs -w
    NAME                                           READY   STATUS    RESTARTS   AGE
    openebs-localpv-provisioner-6d6d9cfc99-4sltp   1/1     Running             10s
    openebs-ndm-85rng                              1/1     Running             10s
    openebs-ndm-operator-7df6668998-ptnlq          /1     Running             10s
    openebs-ndm-qgqm9                              1/1     Running             10s
    openebs-ndm-zz7ps                              1/1     Running             10s

    創建存儲類

    $ cat > local-device-sc.yaml <<EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: local-device
      annotations:
        openebs.io/cas-type: local
        cas.openebs.io/config: |
          - name: StorageType
            value: device
    provisioner: openebs.io/local
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer
    EOF

    $ kubectl apply -f local-device-sc.yaml

    創建 Pod 及 PVC

    $ cat > local-device-pod.yaml <<EOF
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: local-device-pvc
    spec:
      storageClassName: local-device
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5G
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-local-device-pod
    spec:
      volumes:
      - name: local-storage
        persistentVolumeClaim:
          claimName: local-device-pvc
      containers:
      - name: hello-container
        image: busybox
        command:
           - sh
           - -c
           - 'while true; do echo "`date` [`hostname`] Hello from OpenEBS Local PV." >> /mnt/store/greet.txt; sleep $(($RANDOM % 5 + 300)); done'
        volumeMounts:
        - mountPath: /mnt/store
          name: local-storage
    EOF

    發布

    $ kubectl apply -f local-device-pod.yaml

    查看 pod狀態

    $ kubectl get pod hello-local-device-pod -w
    NAME                     READY   STATUS    RESTARTS   AGE
    hello-local-device-pod   1/1     Running             9s

    確認 pod關聯 pvc是否為 local-device-pvc

    $ kubectl describe pod hello-local-device-pod
    Name:         hello-local-device-pod
    Namespace:    default
    Node:         node2/192.168.1.112
    ...
    Volumes:
      local-storage:
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  local-device-pvc
        ReadOnly:   false
    ...

    觀察到調度的節點為 node2,確認 node2節點 /dev/sdb是否被使用

    [root@node2 ~]# lsblk
    NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda               8:0      400G   disk
    ├─sda1            8:1        1G   part /boot
    └─sda2            8:2      399G   part
      └─centos-root 253:0      399G   lvm  /
    sdb               8:16      20G   disk
    sr0              11:0    1  4.4G   rom
    [root@node2 ~]# lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda      8:0      400G   disk
    ├─sda1   8:1        1G   part /boot
    └─sda2   8:2      399G   part
      └─centos-root
           253:0      399G   lvm  /
    sdb      8:16      20G   disk /var/lib/kubelet/pods/266b7b14-5eb7-40ec-bccb-3ac189acf939/volumes/kubernetes.io~local-volume/pvc-9bd89019-13dc-4
    sr0     11:0    1  4.4G   rom

    確實被使用,OpenEBS強大之處則在于此,極致的簡潔。如上文我們討論的那樣,NDM負責發現塊設備并過濾掉不應該被 OpenEBS使用的設備,例如,檢測有 OS文件系統的磁盤。

    基準測試

    創建基準測試 pvc

    $ cat > dbench-pvc.yaml <<EOF
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: dbench
    spec:
      storageClassName: local-device
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5G

    EOF

    下載基準測試 Job 聲明文件[5]

    調整以下內容

    image: openebs/perf-test:latest # 調整為內網鏡像庫tag    

    發布運行

    $ kubectl create -f dbench-pvc.yaml
    $ kubectl create -f fio-deploy.yaml 

    查看運行狀態

    $ kubectl get pod
    NAME                 READY   STATUS    RESTARTS   AGE
    dbench-vqk68-f9877   1/1     Running             24s

    查看基準測試結果

    $ kubectl logs -f dbench-vqk68-f9877
    ...

    All tests complete.

    ==================
    = Dbench Summary =
    ==================
    Random Read/Write IOPS: 3482/6450. BW: 336MiB/s / 1017MiB/s
    Average Latency (usec) Read/Write: 2305.77/1508.63
    Sequential Read/Write: 6683MiB/s / 2312MiB/s
    Mixed Random Read/Write IOPS: 3496/1171

    從結果來看,相較 Local PV HostPath模式性能翻倍

    總結

    在整個測試驗證過程,OpenEBS給我的感覺是:極簡的操作,尤其 Local PV引擎的部署使用。

    OpenEBS現階段也存在一些不足:

    • cStorJiva數據面組件較多,配置較為繁瑣(第一感覺概念性的組件過多,)
    • cStorJiva部分組件創建依賴內部定義的鏡像 tag,在離線環境下無法通過調整為私有庫 tag導致組件無法成功運行
    • 存儲類型單一,多個引擎僅支持塊存儲類型,不支持原生多節點讀寫(需結合 NFS實現),對比 ceph等稍顯遜色

    建議以下場景使用 OpenEBS作為后端存儲:

    • 單機測試環境
    • 多機實驗 / 演示環境

    引用鏈接

    [1]

    CNCF博客: https://www.cncf.io/blog/2018/04/19/container-attached-storage-a-primer/

    [2]

    yaml 文件: https://openebs.github.io/charts/openebs-operator-lite.yaml

    [3]

    基準測試 Job 聲明文件: https://github.com/openebs/performance-benchmark/blob/master/fio-benchmarks/fio-deploy.yaml

    [4]

    yaml 文件: https://openebs.github.io/charts/openebs-operator.yaml

    [5]

    基準測試 Job 聲明文件: https://github.com/openebs/performance-benchmark/blob/master/fio-benchmarks/fio-deploy.yaml

    標簽:節點 磁盤 數據
    SQL中左連接左表合并去重實用技巧
    ? 上一篇 2022-05-24
    • SQL中左連接左表合并去重實用技巧
      0閱讀 0條評論 個贊
      zyc88.blog.csdn.net/article/details/83002882建表:CREATETABLE`table1`(`id`int(11)NOTNULLAUTO_INCREMENT,……
    • 運維入坑必看:Kubernetes平臺架構解讀
      0閱讀 0條評論 個贊
      Kubernetes是一個開源容器編排平臺,管理大規模分布式容器化軟件應用,是云計算發展演進的一次徹底革命性的突破。Kubernetes是谷歌的第三代容器管理系統,是Borg獨特的控制器和Omega靈……
    • 記得保命!捕捉Linux下的所有高危命令!
      0閱讀 0條評論 個贊
      1、rm-rf命令該命令可能導致不可恢復的系統崩壞。>rm-rf/#強制刪除根目錄下所有東西。>rm-rf*#強制刪除當前目錄的所有文件。>rm-rf.#強制刪除當前……
    • Kubernetes 4000節點運維經驗分享
      0閱讀 0條評論 個贊
      1摘要在PayPal,我們最近開始試水Kubernetes。我們大部分的工作負載都運行在ApacheMesos上,而作為遷移的一部分,我們需要從性能方面了解下運行Kubernetes集群……
    • 干貨:10個聚類算法的完整Python操作實例
      0閱讀 0條評論 個贊
      來源:海豚數據科學實驗室本文約7000字,建議閱讀14分鐘本文將介紹一篇關于聚類的文章,10種聚類介紹和Python代碼。聚類或聚類分析是無監督學習問題。它通常被用作數據分析技術,用于發現數據中的有趣……
    發表評論 共有條評論
    用戶名: 密碼:
    驗證碼: 匿名發表
    • 管理數百個Kubernetes集群需要什么?
      0閱讀 0條評論 個贊
      文章轉載:進擊云原生(版權歸原作者所有,侵刪)要點:部署一個具備生產就緒所需所有依賴關系的Kubernetes集群需要數天時間。如果不自動化這個過程,管理Kubernetes集群的浮動是非常困難的。在……
    • 服務器端高并發分布式架構的演進之路
      1閱讀 0條評論 個贊
      1.概述本文以淘寶作為例子,介紹從一百個到千萬級并發情況下服務端的架構的演進過程。同時列舉出每個演進階段會遇到的相關技術,讓大家對架構的演進有一個整體的認知。文章最后匯總了一些架構設計的原則。特別說……
    • MySQL查詢語句的limit offset是如何實現的?
      1閱讀 0條評論 個贊
      在寫select語句的時候,使用limit,offset可能就像是我們吃飯喝水一樣自然了。剛開始工作的時候也經常聽前輩們教導:使用limit,offset,當offset變大的時候執……
    • MySQL 8.0如何創建規范表
      1閱讀 0條評論 個贊
      這一節內容,基于MySQL8.0版本,聊一下如何創建一張規范的表。首先貼出一張相對規范的表結構:CREATETABLEstudent_info(`id`INTNOTNULLAUTO_IN……
    • SQL中左連接左表合并去重實用技巧
      0閱讀 0條評論 個贊
      zyc88.blog.csdn.net/article/details/83002882建表:CREATETABLE`table1`(`id`int(11)NOTNULLAUTO_INCREMENT,……
    • 大數據平臺核心架構圖解 推薦收藏!
      1閱讀 0條評論 個贊
      我們先來看看這張圖,這是某公司使用的大數據平臺架構圖,大部分公司應該都差不多:從這張大數據的整體架構圖上看來,大數據的核心層應該是:數據采集層、數據存儲與分析層、數據共享層、數據應用層,可能叫法有所不……
    • 我用Java在幾分鐘內處理了30億條數據.
      2閱讀 0條評論 個贊
      來源:https://c1n.cn/GM8hb目錄場景說明模擬數據場景分析讀取數據處理數據遇到的問題場景說明現有一個10G文件的數據,里面包含了18-70之間的整數,分別表示18-70歲的……
    • 如何在K8S的Pod中連續執行容器?不要錯過這個方法
      1閱讀 0條評論 個贊
      出于某些目的,有時需要在Kubernetes的一個Pod中,連續依次運行多個Container。這種有明確結束預期的運行,即Kubernetes的Job。但是,雖然一個Job可以在……
    • Java“年度加密漏洞”修復 網友:更多堅持Java 8的理由
      9閱讀 0條評論 個贊
      文|Travis出品|OSC開源社區(ID:oschina2013)甲骨文于昨日推送了安全更新修復了一個漏洞,該漏洞允許攻擊者偽造某些種類的SSL證書和握手、雙因素認證信息,以及由一系列廣……
    • 不容錯過的20個ES6技巧
      5閱讀 0條評論 個贊
      前言大家好,我是xieyezi,好久不見,我又重新回歸掘金啦,這次為大家整理了20個使用頻率很高的ES6代碼塊,希望大家喜歡……
    • 提高Java字符串編碼和解碼性能的技巧
      1閱讀 0條評論 個贊
      1常見字符串編碼●常見的字符串編碼有:LATIN1只能保存ASCII字符,又稱ISO-8859-1。UTF-8變長字節編碼,一個字符需要使用1個、2個或者3個byte表示。由于中文通常需要3個字節……
    • 本文將帶您了解kubernetes的架構和組件!
      1閱讀 0條評論 個贊
      kubernetes架構目標kubernetes是生產級的,用于跨主機部署,擴展,管理和組合應用程序容器的基礎設施。kubernetes不僅僅是“容器編排”,他更加主要的解決方向是消除協調計算資源,網……
    • 臉書數據庫項目負責人:我從做基礎設施中學到的42件事
      2閱讀 0條評論 個贊
      最近讀到了分布式系統研究者MaheshBalakrishnan的一篇博客《42thingsIlearnedfrombuildingaproductiondatabase》。同樣做……
    • 運維 放下監控——也放下自己
      1閱讀 0條評論 個贊
      來源公眾號:云原生技術應用(ID:sreguide)根據多年和運維打交道的經歷,我發現,運維常常讓監控變得無效。。。1.我的監控故事我做過兩年多的運維工作,后面就轉做運維平臺開發了,也一步步看著監控……
    • 40幅最完整的計算機網絡思維導圖
      1閱讀 0條評論 個贊
      傳輸介質簡介以太網幀結構IP編址ICMP協議ARP協議傳輸層協議路由基礎靜態路由基礎距離矢量路由協議——RIP鏈路狀態協議——OSPFHDLC&PPP原理與應用幀中繼原理與配置PPPoENAT網絡地址……
    • 談談復雜項目代碼的應用分層
      1閱讀 0條評論 個贊
      —1—背景說起應用分層,大部分人都會認為這個不是很簡單嘛就controller,service,mapper三層??雌饋砗唵?,很多人其實并沒有把他們職責劃分開,在很多代碼中,controller做……
    • 可以解決80%問題的故障排除思路
      1閱讀 0條評論 個贊
      在講解事件、故障處理思路前,先講一個故障場景(以呼叫中心系統作為一例子):業務人員反映呼叫中心系統運行緩慢,部份電話在自助語言環節系統處理超時,話務轉人工座席,人工座席出現爆線情況。運維人員開始忙活了……
    • Linux最常用的命令:解決95%以上的問題
      1閱讀 0條評論 個贊
      Linux是目前應用最廣泛的服務器操作系統,基于Unix,開源免費,由于系統的穩定性和安全性,市場占有率很高,幾乎成為程序代碼運行的最佳系統環境。linux不僅可以長時間的運行我們編寫的程序代碼,還可……
    • 創建Go語言最快的排序算法
      1閱讀 0條評論 個贊
      前言說到排序算法,很多同學會想起快速排序、堆排序、冒泡排序這些耳熟能詳的算法。了解得深一些的同學,也可能看過例如Python的timsort以及C++introsort之類的排序算法?!?/div>
    • 如何用10行bash shell腳本監控Linux?
      1閱讀 0條評論 個贊
      http://985.so/xbtd子沐愛掃地(譯)監控我們的環境對于服務器運維來說至關重要,尤其是在部署新的應用程序時。如今,公司每天都使用開源解決方案來監控系統資源。但是,當出于測試的目的來監控……
    • 蘭州銀行將積極申請金融子公司、消費金融等金融牌照
      5閱讀 0條評論 個贊
      在金融牌照獲取方面,蘭州銀行還有哪些計劃?近日,蘭州銀行董事長許建平在2021年度網上業績說明會上表示,未來,蘭州銀行將在監管政策允許的范圍內積極開展理財子公司、消費金融公司等金融牌照的申請工作,打造專業化的綜合金融服務能力?!?/div>
    • 好買財富Q1凈利潤3921萬元 同比下滑68%:業績和銷售額雙下滑
      1閱讀 0條評論 個贊
      好買財富(NEEQ:834418)公布2022年第一季度報告顯示,公司營業收入2.17億元,同比下降27.33%;歸屬于母公司凈利潤約為3921萬元,較去年同期下降約8319萬元,降幅約67.97%;利潤總額約為4094萬元,較去年同期下降約1.15億元,降幅約73.68%?!?/div>
    • 詳細介紹SEO新手建立模板站的條件和步驟
      1閱讀 0條評論 個贊
      對于一個SEO新人來說,搭建網站其實也是很頭疼的事,新手SEO應該怎么用這些模板源碼搭建自己的網站呢首先我們在搭建網站前要確定好公司的名稱,確定好標題,描述,關鍵詞等等……
    • 大幅下降!‘郵區’消費信貸走弱 利率下降仍是消滅貨幣的主要目標
      7閱讀 0條評論 個贊
      進入2022年以來,上海等多地的疫情呈現反復趨勢。從今年一季度的情況來看,隨著各地疫情管控措施的升級,消費需求以及信貸表現有所減緩。而作為經濟活動最為繁華的“包郵區”,上海地區在內的江浙一帶的封控尚未有放松的機會,不少業內人士也對此表達了對今年二季度展業表現的忐忑?!?/div>
    • 中郵凈利潤飆升206%的背后 最高年利率剛剛從36%降到24%
      6閱讀 0條評論 個贊
      近日,機電產品招標投標電子交易平臺發布了《中郵消費金融2022年品牌營銷宣傳服務項目中標候選人名單》。根據該文件,2022中郵消費金融常規品牌宣傳服務總價將在178.6萬-173.75萬之間,企業社會責任宣傳服務總價將在96.1萬至99.8萬之間?!?/div>
    • 比特幣基地第一季度總收入下降35% 凈虧損4.3億美元:股價盤后暴跌13%
      0閱讀 0條評論 個贊
      美國加密貨幣交易所Coinbase Global Inc周二公布第一季度營收低于預期,并公布虧損,原因是全球市場動蕩抑制了投資者對包括加密貨幣交易在內的風險資產的興趣?!?/div>
    • 良心平臺!切記P2P平臺有最新動態 24號支付已經開通
      1閱讀 0條評論 個贊
      深圳P2P平臺“隨手記”發布了關于平臺開啟第二十四期兌付的公告。本月將于2022年5月24日對未選擇“銀行利率快速退出”的其他通用方案出借人進行兌付?!?/div>
    • 白楊SEO:傳統SEO如何向網站運營或淘寶SEO轉型?
      0閱讀 0條評論 個贊
      網站運營是什么?與SEO有什么關系網站運營,其實有網站開始就有網站運營了,更準確說,SEO也可以說是網站運營里獲取流量的一種方式。網站運營是什么?網站運營指一切……
    • 第二大網絡小貸公司誕生
      0閱讀 0條評論 個贊
      巨頭發力?!?/div>
    • 小微融資服務的進階模型:深入場景,做強科技
      1閱讀 0條評論 個贊
      小微融資服務還會是一門好生意嗎?……
    • 數據倉庫實踐:總線矩陣體系結構的設計
      1閱讀 0條評論 個贊
      以下文章來源于公眾號-云祁的數據江湖,作者云祁如何設計一套切實可行的數據倉庫呢?我們要明白,對于數據倉庫的設計是不能完全依賴于業務的需求,但往往又必須要服務于業務的價值。因此,在構建數據倉庫前,我們……
    • 京東云首次公布JD.COM供應鏈金融科技平臺
      1閱讀 0條評論 個贊
      近日,京東云舉辦了產業融合新品發布會-金融科技專場,在線上發布了3款金融科技產品,具體包括:一是面向金融機構的數智化營銷增長方案;二是京東生物資產監管平臺和京東供應鏈金融科技平臺。目前,京東云已經與中國銀行、工商銀行、建設銀行、中信銀行、民生銀行、平安銀行等金融機構共建了全場景營銷生態,探索以數字化合作模式實現場景獲客和持續用戶經營,實現客戶增長?!?/div>
    • 本文將帶您了解kubernetes的架構和組件!
      1閱讀 0條評論 個贊
      kubernetes架構目標kubernetes是生產級的,用于跨主機部署,擴展,管理和組合應用程序容器的基礎設施。kubernetes不僅僅是“容器編排”,他更加主要的解決方向是消除協調計算資源,網……
    • 拉卡拉展望2022年整體業務目標:克服壓力 保持一定的增長水平
      13閱讀 0條評論 個贊
      據拉卡拉支付公布的投資者關系活動記錄表顯示,日前,針對展望2022年整體經營目標,拉卡拉表示,今年情況比較復雜,主要是疫情的反復,對商戶和實體經濟的影響。公司已經在經營戰略和策略上,圍繞商戶形態和數字化經營,在前中后臺、直營和渠道、產品和技術、機制和能效等方面開始做些調整,克服壓力,努力保持一定增長水平?!?/div>
    • 全球10大加密公司:比安列第四以太坊邊緣的比特幣
      0閱讀 0條評論 個贊
      近幾個月來,隨著通脹攀升,以及在動蕩的市場中,受歡迎的貨幣作為安全港和財富存儲設備的吸引力飆升,機構投資者對加密貨幣的興趣不斷增加。加密信息公司Chainalysis在4月20日的一份報告中披露,全球加密投資者在2021年實現了1627億美元的總收益,高于前一年的355億美元。美國以超過470億美元的收入領先其他國家,其次是英國、德國和日本?!?/div>
    • 隱瞞12多億關聯交易董事長成立公司搞助學貸款、公教及高管被罰千萬
      9閱讀 0條評論 個贊
      隱瞞12億多關聯交易額,董事長成立公司搞培訓貸,昔日大白馬、“公考第一股”中公教育監管處罰來了?!?/div>
    • 四部門發文:禁止未成年人參與直播打賞
      1閱讀 0條評論 個贊
      中央文明辦、文化和旅游部、國家廣播電視總局、國家互聯網信息辦公室四部門聯合發布《關于規范網絡直播打賞 加強未成年人保護的意見》(以下簡稱《意見》)?!?/div>
    • 大部分加密客戶可能會因為交易平臺破產而虧損
      3閱讀 0條評論 個贊
      上周,Coinbase表示,如果該公司破產,他們的加密貨幣可能會損失,這讓一些客戶感到震驚。專家表示,事實是,大多數加密交易平臺的客戶可能都面臨著這種風險?!?/div>
    • 芯片業人才荒亂象:大廠頻遭挖角,HR上街「搶人」,天價速成班借機攬財!
      3閱讀 0條評論 個贊
      人才和工程師難找,耐心和靜心都很難再有?!?/div>
    • 歐美會淘汰信用卡嗎?萬事達卡將人臉或手勢識別支付引入實體店
      5閱讀 0條評論 個贊
      萬事達卡希望通過讓顧客用臉或手付款來擺脫實際的信用卡。萬事達卡(Mastercard Inc.)已開始在實體商店試驗一種生物識別支付系統,使用面部識別,而不是非接觸式信用卡、智能手機或可記憶的個人識別碼。這家信用卡公司試圖跟上靈活的金融科技公司和亞馬遜(Amazon)等規模更大的競爭對手的步伐。?……
    最近發布資訊
    更多
    国产H视频在线播放,国产毛多水多的老女人,国产成人午夜福利电影在线播放
    <table id="km2im"></table>
  • <bdo id="km2im"><center id="km2im"></center></bdo>