複製池 (預設值)

預設的 ODF 設定採用三向複製。 每筆資料都會以 3 份副本的形式儲存於不同的節點上，並能抵禦多達 2 起同時發生的磁碟或節點故障。

• 優點：架構簡單、讀取速度快、恢復速度快，且延遲可預測。
• 使用量增加：每 1 位元組可用資料，會佔用 3x 的原始儲存空間。

當副本遺失時會發生什麼情況（ rep3 ）：

min_size 參數控制在 Ceph 允許 I/O 之前必須可用的最小副本數。 ODF 預設會為 rep3 儲存池設定 min_size=2，並透過 requireSafeReplicaSize: true 強制執行此設定；這表示當有 2 或 3 份副本可用時，讀取與寫入作業將照常進行。 當僅剩 1 份副本時，Ceph 會阻斷 I/O 操作，以防止資料進一步出現不一致。

此行為是一種刻意設計的安全機制，旨在將資料完整性置於可用性之上。

從失去第二份副本到完成重新複製這段時間，是最危險的。 在此期間，第三次故障會造成永久資料遺失。 正因如此，容量規劃才至關重要，因為 Ceph 的重新複製速度取決於叢集的可用頻寬與可用空間。 過載或接近滿載的叢集需要更長的時間來重新複製資料，這會延長系統處於脆弱狀態的時間。

對於 rep2 中的池，其進度安排較為緊湊。 如果遺失 1 個副本，則只剩下 1 個副本。 在「min_size=2」（預設）模式下，受影響的 PG 上的 I/O 會立即被阻塞，直到遺失的 OSD 恢復正常，或複製出新的副本為止。 若啟用「min_size=1」，I/O 作業將繼續在唯一剩餘的副本上進行，但若發生第二次故障，則會導致永久性資料遺失。

Red Hat OpenShift Kubernetes Service 的 ODF 附加元件僅會自動建立 rep3 資料庫池，且其 ocs-storagecluster-cephblockpool 設定為預設值。 Rep2 資料池並非由此附加元件所建立。 您必須手動建立一個自訂的 CephBlockPool，其中包含 replicated.size: 2 以及對應的 StorageClass。 如需更多資訊，請參閱《 建立用於虛擬化的自訂 StorageClass 》。

由於「rep2」的容錯能力不如「rep3」，請評估對於您的工作負載而言，儲存空間的節省是否足以抵銷風險增加所帶來的影響。

IBM 建議針對所有生產環境的虛擬化工作負載採用三路複寫，以協助確保可用性與資料持久性。

清除編碼池

對於以儲存容量效率為優先考量的環境，ODF 也支援刪除編碼 (EC) 池。 EC 將資料分割為 k 資料區塊與 m 校驗區塊，與複製技術相比，不僅能減少原始儲存空間的使用量，同時仍能提供容錯能力。

支援狀態： ODF 中針對 RBD 和 CephFS 的擦除編碼是一項開發者預覽功能，首次於 ODF 中推出 4.20。 開發者預覽版的功能不支援用於正式環境。 此外，這些情況也不適用於「Red Hat」客戶入口網站的案件管理服務。 在 ODF 4.20 推出之前，僅有 RGW（物件儲存）EC 作為開發者預覽版提供（來源：ODF 4.16 ）。 雖然底層 Ceph 儲存引擎自 Luminous 版本 (2017 年) 起即支援 RBD 的 EC 覆寫，但 ODF 業者及其管理部署模型尚未針對生產區塊儲存工作負載認證 EC 池。 建議針對所有正式運作環境的 VM 儲存空間，採用複製儲存池（ rep2 或 rep3 ），並僅在開發者預覽版限制可接受的非正式運作環境中，評估使用 EC 儲存池。

下表比較了所有可用的池類型，供您參考。

以下清單列出了擦除編碼的主要考量因素。

• 由於需要進行奇偶校驗運算，且每項操作需寫入更多區塊，因此 EC 叢集的寫入延遲比複製叢集更高。
• EC 池提供有競爭力的連續讀取吞吐量，但可能會降低隨機寫入 IOPS。
• 故障域的數量必須至少為 k+m。 在一個由 3 個節點組成的叢集上，僅可能出現 rep2、rep3 以及 ec-2-1 這三個網址。
• 對於一個 6 節點的叢集，前述列出的所有池類型皆可使用。

單一複本叢集（僅適用於開發與測試環境，不具備容錯能力）

從 ODF 附加元件版本 4.14 開始，Red Hat OpenShift Kubernetes Service 透過 addSingleReplicaPool 參數支援單一副本 ( rep1 ) 池。 此參數會建立一個不具容錯能力的 Ceph 區塊儲存池，該儲存池不進行資料複製，每個資料區塊僅儲存一次。

若要在部署 ODF 時啟用單一複本池，請使用以下指令

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

此指令會建立一個額外的 StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd:單一複製區塊儲存，搭配 WaitForFirstConsumer 卷冊綁定。

標準的 replica-3 資料庫（ocs-storagecluster-cephblockpool ）仍會透過此方式建立。 非彈性池是一個獨立、選擇加入的選項。

單一複本池具有以下使用情境。

• 開發與測試環境——在此類環境中，資料持久性並非關鍵考量，而優先考量的是降低儲存成本。
• 具備內建複製功能的應用程式——這類應用程式會在應用程式層級自行管理資料冗餘。 這些應用程式會在各節點之間維護多份副本，這意味著儲存層級的複製是多餘的。

單一副本池提供零容錯。 單一 OSD 或節點故障會導致該 OSD 上的所有資料永久遺失，無法復原。 IBM Cloud 文檔明確警告，此選項增加資料遺失、資料損毀和潛在系統不穩定的風險。 如需詳細資訊，請參閱 Ceph 文件。

限制：

• 僅限區塊儲存：單一副本不支援檔案儲存。
• 需要額外磁碟：每個節點除 replica-3 儲存池所使用的磁碟外，還需至少一個額外的可用 NVMe 磁碟。 如果沒有這個額外的磁碟，replica-1 OSD 就不會啟動，儲存群集也會保持在進行中的狀態。
• 每個故障域一個資料池：ODF 會為每個故障網域建立一個非彈性 CephBlockPool，並使用 WaitForFirstConsumer 綁定磁碟區，以驗證資料的位置性。
• 不建議用於虛擬機工作負載根磁碟：如果託管根磁碟的 OSD 發生故障，則會永久失去虛擬機工作負載。 在 dev 或測試虛擬機器工作負載中，僅將非彈性池用於一次性資料磁碟。

對於生產環境的虛擬化工作負載，請務必使用「replica-3」（或至少為「replica-2」）資源池。

VMware vSAN 遷移比較

對於正在從 VMware vSAN™ 遷移的團隊而言，這些 Ceph 儲存池類型對應於熟悉的 vSAN 儲存政策：

主要差異 vSAN:

• 更小的主機最小值：Ceph 將叢集法定人數與資料放置分開。 rep3 叢集僅需 3 台主機，因為每台主機只儲存一份完整的副本。vSAN RAID-1 FTT=2 則需要 5 台主機。
• rep2 符合標準 vSAN RAID-1: 大多數 vSAN 部署皆採用 FTT=1，該服務會儲存 2 份副本。 Ceph 的 rep2 就是其直接對應的設定。
• ec-3-1 符合以下條件：vSAN RAID-5: 兩者均採用 3+1 配置，並達到 1.33x 的空間利用率，這是單點故障容錯方案中最具空間效率的選項。
• ec-4-2 符合 vSAN RAID-6: 這兩者均採用 4+2 佈局，並在具備雙重故障容錯能力的情況下，達到 1.5x 的使用率。
• ec-2-1 此外，ec-2-2 並無直接對應的 vSAN 配置：這類規模較小的 Ceph EC 配置包含較少的資料區塊，因此每位元組的利用率較高，但所需的主機數量較少。 它們以儲存效率為代價，換取較低的主機數量需求。

規劃能力

在規劃 ODF 叢集時，請將您所選用的資料保護政策所佔用的原始儲存空間納入考量。 可用容量小於原始 NVMe 總容量。

可用容量公式為 Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor。

請參閱以下 3 節點群集的計算範例，每個節點有 8 x 3.2 TB NVMe 硬碟機 ( 76.8 TB 原始總容量)：

虛擬機工作負載容量估算：具有 30 GB 根磁碟和 100 GB 資料磁碟的典型虛擬機工作負載使用 130 GB 可用儲存空間。 在 rep3 的情況下，該虛擬機器工作負載需要 390 GB 的原始儲存空間。 在前述的 3 節點叢集中，您大約可以配置 196 個此規模的虛擬機器工作負載。 實際上，請將 Ceph 的使用率維持在 75% 以下，以維持效能並支援復原作業。

Ceph 的效能會隨著群集使用量的增加而降低。 當任何 OSD 的使用率超過 75% 時，ODF 會觸發「CephOSDNearFull」Prometheus 警示。 當達到 85% 時，Ceph 會設定原生 nearfull OSD 標誌（mon_osd_nearfull_ratio ），而 ODF 則會觸發 CephOSDCriticallyFull 警示。 當佔用率達到 90% 時，Ceph 會停止對受影響 OSD 的後填與恢復作業（mon_osd_backfillfull_ratio ）。當佔用率達到 95% 時，Ceph 會將該 OSD 標記為 full （mon_osd_full_ratio ），封鎖所有寫入操作，並發出 HEALTH_ERR 指令。 請妥善規劃儲存容量，確保在正常運作期間的使用率維持在 70% 以下，以便在進行節點維護或發生故障時，留有足夠的餘裕進行資料復原與重新平衡。

若要檢查目前的群集使用量，請執行下列指令：

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

工作節點數量與拓撲結構

IBM Cloud ODF 附加元件所使用的故障域拓撲，取決於您的叢集配置：

• 多區域叢集（3 個可用區域）： 故障域設定為 zone。 工作節點分散在各區域中，而 ODF 必須以 3 的倍數擴展，以維持各區域的平衡。 為了達到最佳的可用性、效能和資料安全性，請在 ODF 儲存叢集中使用 3、6 或 9 個節點——每個區域應分配相同數量的節點。
• 單一區域叢集或可用區域少於 3 個的叢集： 系統會自動啟用彈性擴展，且故障域設定為 host。 您可以先從 3 個節點開始，然後一次新增一個節點。

參與 ODF 儲存群集的所有節點都必須是裸機。 不支援在同一 ODF 集群中混合使用虛擬化和裸機節點。

對於多區域叢集：若新增的節點數量並非 3 的倍數，將會導致區域不平衡。 在擁有 4 個節點的情況下，其中一個區域會分配到 2 個節點，其餘區域則各分配 1 個，導致 OSD 權重分配不均、資料配置不佳、使用率不均，以及部分 OSD 處於閒置狀態。

對於多區域叢集，請始終以 3 的倍數進行擴展，以維持均衡的區域拓撲結構。

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

ODF 訂閱計劃

請選擇最符合您需求的方案：

• Essentials

  • 減少成本
  • 僅限內部模式部署
  • 不支援災難復原、延伸叢集或外部模式部署
  • 最適合用於測試與開發環境、概念驗證，或小規模部署

• 進階

  • 完整的功能集，包含災難復原、延伸叢集、外部模式部署、進階粒度加密，以及多叢集支援
  • 建議用於包含虛擬機器的生產環境虛擬化工作負載

這兩項方案均包含區塊儲存池的「BlueStore」壓縮技術、精簡配置、快照及克隆功能。 這些方案之間的差異在於災難復原、加密粒度以及部署靈活性，而非儲存效率功能。

ODF 僅透過 Multicloud Object Gateway (MCG) 支援物件儲存的重複資料刪除。 區塊儲存不支援重複資料刪除。 此項支援服務適用於「Essentials」和「Advanced」兩項方案。 用於 RBD 的上游 Ceph 重複資料刪除仍屬實驗性質，未經認證可在 ODF 中使用。

如需更多資訊，請參閱《 ODF 基礎與進階對比 》。

儲存空間類型

• 選擇本機儲存。
• 本機儲存使用裸金屬工作節點上可用的本機 NVMe 實例儲存。
• NVMe 硬碟具備較低的延遲與高 IOPS 效能，這正是虛擬機器工作負載磁碟所必需的。

ODF 資源簡介

ODF 提供三種資源分配設定檔，可控制預留給 Ceph 系統的 CPU 和記憶體。

• 精益：最少的資源分配。 Lean profile 適用於資源有限的環境、測試、開發和概念驗證。 不建議將 Lean 用於生產環境的虛擬化工作負載。
• 平衡：Red Hat OpenShift Kubernetes Service 上的預設設定檔。 平衡設定檔在一般用途工作負載的資源消耗和效能之間取得平衡。
• 效能：為 Ceph 守護程式分配更多的 CPU 和記憶體，從而降低守護程式端發生瓶頸的風險。 最適合高 IOPS 工作負載、大量虛擬伺服器以及要求嚴苛的應用程式。

對於配備本地 NVMe 硬碟的裸機部署，請使用「效能」資源設定檔。 每個節點配備 8 個或更多 NVMe 硬碟的裸機節點，會導致每個主機的 OSD 數量偏高。 在「平衡」配置下，Ceph 守護程式的 CPU 和記憶體限制往往會在底層 NVMe 硬體達到飽和之前就被耗盡，這會導致 IOPS 受限並增加延遲。 「效能」設定檔是針對在裸機環境上執行生產級 Red Hat OpenShift 虛擬化工作負載所建議的最低設定檔。

在 ODF 安裝期間，Red Hat OpenShift 網頁主控台中顯示的資源需求，是根據群集 OSD 計數動態計算的。 因此，配備更多 NVMe 硬碟的叢集，所需資源也相應地更多。 這些數值並非固定不變。 請務必針對您的特定群集組態，確認主控台中顯示的需求。

設定檔是在 StorageSystem 建立時，透過 Red Hat OpenShift 網頁主控台的「配置效能」畫面選擇。 資源配置不足的 Ceph 守護程式可能會成為隱藏的瓶頸，導致 IOPS 降低，或產生比底層儲存硬體所能提供的更高的延遲。

將您的裸機伺服器設定檔與所選設定檔顯示的資源需求相匹配：IBM Cloud VPC 裸機伺服器設定檔。

在裸機伺服器上，資源略微超量通常是可以接受的。 然而，請切勿將配置值設定得遠低於顯示的最低需求，否則會導致 ODF 的效能與穩定性下降。

每個節點的 OSD 磁碟數量

• 確定每台裸機伺服器上可用的本地 NVMe 硬碟數量。
• 請確保每個節點所配置的 OSD 數量，不得超過可用 NVMe 硬碟的數量。
• 建議的配置方式是每顆 NVMe 硬碟搭配 1 個 OSD，以達到最佳效能並實現故障隔離。
• 請確保 OSD 磁碟的數量通常與每個裸機節點上的 NVMe 磁碟數量相符。 使用者介面中顯示的儲存容量計算結果，並未反映本地儲存配置的實際可用容量，可不予理會。

在建立 StorageSystem 時，選擇節點時請避免選取叢集中的所有節點。 選取所有節點將建立一個不具備 nodeSelector 的 LocalVolumeSet （LVS）。 日後新增至叢集的任何工作節點，都將被 ODF 自動偵測到，即使該節點並非用於儲存用途。 若偵測到非預期的節點，必須手動將其從 LVS 中移除。 為避免此情況，請僅選取您專用儲存工作節點池中的節點，或確保在建立 StorageSystem 之前，這些節點已標記為 cluster.ocs.openshift.io/openshift-storage。

群集的預設 StorageClass

ODF 部署完成後，通常會建立以下資料庫：followingStorageClasses：

• ocs-storagecluster-ceph-rbd:區塊儲存
• ocs-storagecluster-cephfs:檔案儲存
• ocs-storagecluster-ceph-rgw:物件儲存

若要讓工作負載無需額外設定即可自動使用由 ODF 支援的高效能持久性區塊儲存，請在安裝 ODF 附加元件後，將「使用 Ceph RADOS 區塊裝置 (RBD)」選為預設儲存類別，或手動將 RBD （ocs-storagecluster-ceph-rbd ）設定為叢集的預設 StorageClass。

1. 將 RBD 標記為預設值：

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. 如有需要，請從先前設定的預設值中移除「預設」一詞：

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

ODF 配置清單

• 群集至少包含一個裸機伺服器池
• Red Hat OpenShift 版本 4.17 或更高版本
• ODF 附加元件和操作員已安裝並開始執行
• 裸機伺服器有足夠可用的本機 NVMe 硬碟機
• 選取的資源設定檔與節點容量相符
• ODF 儲存叢集至少需使用 3 個節點；多區域叢集必須使用 3 的倍數（3、6、9、……） 以維持區域平衡
• 所有 ODF 參與節點都是裸機
• 建立 RBD StorageClass，並最好設定為預設值
• ODF 叢集狀態為「就緒」（oc get storagecluster -n openshift-storage ）
• Ceph 的運作狀態為 HEALTH_OK（oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status ）

先決條件：安裝 Red Hat OpenShift 虛擬化操作員

在 IBM Cloud 上使用 Red Hat OpenShift 虛擬化功能之前，請先確認您的 Red Hat OpenShift Kubernetes Service 叢集已安裝 Red Hat OpenShift 虛擬化運算員。

Red Hat OpenShift 虛擬化運算員可實現 Kubernetes 原生虛擬機器工作負載管理。 它也提供所需的控制器、CRD，以及與儲存和網路元件的整合。

如需詳細資訊，請參閱 IBM Cloud 上的 Red Hat OpenShift 虛擬化。

將 ODF 儲存用於虛擬機工作負載

Red Hat OpenShift Data Foundation (ODF) 為在 Red Hat OpenShift 上執行的虛擬化工作負載提供持久、軟體定義的儲存。 當您將 ODF 用作虛擬機器的儲存後端時，選擇正確的 StorageClass 對於確保效能、穩定性以及完整的功能相容性至關重要。

在以下情況下，您必須指定適當的 StorageClass：

• 已建立虛擬伺服器
• 虛擬伺服器已匯入或克隆
• 虛擬伺服器已遷移至 Red Hat OpenShift Kubernetes Service 叢集

預設虛擬化 StorageClass

當安裝了 Red Hat OpenShift 虛擬化操作員，且有可用的ODF叢集時，系統會自動建立一個針對虛擬化工作負載進行優化的 StorageClass：

• ocs-storagecluster-ceph-rbd-virtualization

這個 StorageClass 是：

• 針對磁碟 I/O 模式 (例如隨機讀取、寫入及持續吞吐量) 進行調整
• 已針對虛擬化生命週期作業 (例如啟動、停止、即時遷移和快照) 進行驗證
• 完全支援並建議用於生產 Red Hat OpenShift 虛擬化環境

對於大多數使用情況，請使用此 StorageClass，無需修改。

即時移轉儲存需求

Live migration 可在不停機的情況下將執行中的虛擬機工作負載從一個工作站移到另一個工作站。 若要成功進行即時移轉，來源節點和目的地節點必須同時存取儲存設備。 即時遷移需要進行以下設定。

• ReadWriteMany 虛擬機器工作負載 PVC 上的存取模式。 Ceph RBD 支援區塊模式中的 RWX，這是 ODF 虛擬化 StorageClass 的預設設定。
• ocs-storagecluster-ceph-rbd-virtualization （ StorageClass ）已預先設定為透過 RBD 區塊模式支援 ReadWriteMany。 使用此 StorageClass 的虛擬伺服器無需額外設定即可進行移轉。
• 一般 ocs-storagecluster-ceph-rbd StorageClass 預設使用 ReadWriteOnce 存取模式。 使用 RWO PVC 的虛擬伺服器無法執行即時遷移。 遷移失敗的原因是 PVC 連接到來源時，無法掛載到目的地節點。

若您為需要即時遷移的虛擬伺服器建立 customStorageClasses，請確認這些 PVC 是透過 accessModes: [ReadWriteMany] 和 volumeMode: Block 建立的。

現場移轉也需要：

• 使用適當的移轉政策設定 Red Hat OpenShift 虛擬化操作員
• 驗證目的地節點上有足夠的 CPU 和記憶體可用

特定於虛擬化的 RBD 與一般 RBD 相比 StorageClass

雖然虛擬機器可以使用通用的 Ceph RBD（ StorageClass, ），但專為虛擬化設計的 StorageClass 已針對虛擬機器工作負載磁碟獨特的 I/O 及生命週期特性進行了優化。

通用版 RBD StorageClasses 仍適用於容器工作負載，但建議在生產環境的虛擬化環境中使用專為虛擬化設計的 StorageClass。

為虛擬化建立自訂 StorageClass

在某些情況下，您可能需要自訂 StorageClass，以符合特定的效能、彈性或容量需求。

若要建立自訂的「StorageClass」需求，您必須先建立自訂的「CephBlockPool」。 建立自訂資料池時，您必須在資料池上設定 targetSizeRatio。 若未設定此選項，Ceph 配置群組自動擴展功能僅會將 1 個配置群組指派給該儲存池。 此配置會導致所有 I/O 都在單一 OSD 上形成瓶頸，使得效能比預設儲存池更差。

為虛擬化工作負載建立自訂 StorageClass 時，請確認下列參數已正確設定。

• 供應商

  StorageClass 必須使用由 ODF 提供的 Ceph RBD CSI 配置程式：

  openshift-storage.rbd.csi.ceph.com
  

  此佈建器可動態佈建由 ODF 叢集支援的 Ceph RBD 磁碟區。

• 儲存區

  指定備份虛擬機工作負載磁碟的 CephBlockPool。 您可以選取下列其中一個選項：

  • 預設區塊池。 由 ODF 建立的預設 3 向複製 Ceph 區塊池：

      ocs-storagecluster-cephblockpool
      ```
  
  - 自訂磚塊泳池。 使用者定義的 CephBlockPool。 池必須包含下列設定，以避免效能陷阱：
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• 圖像功能

  StorageClass 必須包含對工作負載效能至關重要的 RBD 影像特徵：

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  RBD 影像特徵及其用途

  特性	目的
  exclusive-lock	啟用回寫快取和單寫最佳化。 如果沒有此功能，寫入 IOPS 可能會比 7x 差。
  object-map	啟用稀疏影像中已分配物件的位圖追蹤。
  fast-diff	加速快照差異和 DataVolume 複製作業，以加快開機時間。
  deep-flatten	使克隆扁平化後完全獨立。
  layering	啟用 DataVolume cloning 所需的 copy-on-write cloning。

• 地圖選項

  mapOptions: krbd:rxbounce
  

  此選項可解決在 Windows 虛擬伺服器上使用核心 RBD 驅動程式時發生資料損毀的問題。 這會強制核心對接收到的資料使用彈跳緩衝區，以確保相容性。 此選項必須在所有工作負載的 StorageClasses 上設定。

• 完整的自訂 StorageClass 範例

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  若要尋找群集的 clusterID，請執行下列指令：

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  對於刪除編碼叢集（僅限開發者預覽版），請參閱 《了解資料保護 》，並將 dataPool 設定為指向 EC 叢集，同時保持 pool 指向預設複寫叢集：

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

壓縮

ODF 支援 BlueStore 在 Ceph 區塊池上進行線上壓縮，可減少磁碟使用的原始儲存空間。 壓縮是在 OSD 層以透明方式進行的，因此虛擬機器工作負載及其客體作業系統並不會察覺資料已被壓縮。

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

加密

ODF 支援多層的靜止資料加密，您可以獨立啟用。

• IBM Cloud 基礎架構加密：實體 NVMe 磁碟的整碟加密——由 IBM Cloud 管理。
• ODF 叢集級加密：所有 Ceph OSD 磁碟均透過 dm-crypt 在裝置層級進行加密。 透過儲存叢集 CR 上的 encryption.clusterWide: true 啟用。 防止實體磁碟遭竊。
• ODF 按卷加密：個別 RBD 卷會透過 LUKS2 進行加密，每個卷皆擁有專屬的資料加密金鑰。 提供租戶隔離與細粒度的金鑰管理。

在 Red Hat OpenShift Kubernetes Service 上，ODF 與 IBM Key Protect 整合，作為群集範圍和每卷加密的外部金鑰管理服務。 啟用每卷加密時，ODF 會自動建立 -encrypted StorageClass 變體 (例如 ocs-storagecluster-ceph-rbd-encrypted)。

針對 NVMe 裸機環境的 Ceph 效能調校

Ceph 的預設設定已針對一般工作負載進行了優化。 以下參數值已在「mx2d.metal.96x768」裸機配置上經過驗證，並能顯著提升該配置下「VM」磁碟工作負載的 IOPS 並降低延遲。 如果您使用的是其他裸機設定檔，請將這些內容視為起始參考，並根據您特定設定檔中的 NVMe 硬碟數量及可用 CPU 資源來調整相關數值。

請透過 Ceph 工具箱 Pod 中的 ceph config set 指令，分別套用各個參數：

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

套用設定後，請確認設定已成功套用：

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

針對 ceph config set 的變更，無需重新啟動 OSD Pod。 Ceph 會動態套用設定。 然而，BlueStore 的快取變更（osd_memory_target ）必須在每個 OSD Pod 完成回收後，才會完全生效。 您可以在維護時段內，一次回收一個 OSD 模組，而不會中斷 I/O 運作。

基準測試參考： 在由 3 個節點組成的 mx2d.metal.96x768 叢集上進行的內部測試中，該叢集包含 200 台虛擬機器且 I/O 操作次數 (IOPS) 無限制，結果顯示，透過結合 16 個分片、8 GB OSD 記憶體以及 256 MB 的 RocksDB 寫入緩衝區，可達到約 194,000 IOPS 及 758 MB/s 的吞吐量。 將分片數從 8 增加到 16，在所有測試配置中始終能帶來最大的單一 IOPS 提升。

基於快照的備份

ODF 支援 Ceph RBD 磁碟區 Kubernetes VolumeSnapshots。 若要為磁碟製作快照，請使用下列指令：

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots 可在寫入時複製，而且幾乎可以立即建立。 您可以利用這些功能，將虛擬機器工作負載還原至先前狀態，或克隆磁碟。Red Hat OpenShift 虛擬化還提供內建的 VM 快照與還原 API， 可透過單一操作擷取虛擬機器工作負載的完整狀態，其中包含設定及所有磁碟。

為應用程式一致性快照暫停虛擬機工作負載

當您對正在運行的虛擬機器工作負載擷取快照時，磁碟上的資料必須處於一致狀態。 在沒有靜止的情況下，快照會擷取當時磁碟上的任何內容，包括部分寫入的事務、髒緩衝區和飛行中的 I/O。 此流程會產生一個「崩潰一致性」的快照，在還原時可能需要進行應用層級的復原。

若要建立應用程式一致性的快照，請在建立快照前凍結虛擬機器檔案系統，並在建立快照後解凍該檔案系統。Red Hat OpenShift 虛擬化透過 QEMU 虛擬機器代理程式，將此流程自動化。

快照控制器會偵測 QEMU guest 代理程式。 在擷取快照之前，系統會發出 guest-fsfreeze-freeze 指令，以暫停所有檔案系統的 I/O 操作。當檔案系統處於凍結狀態時，便會擷取 VolumeSnapshot。 快照完成後，guest-fsfreeze-thaw 指令會恢復 I/O。 快照狀態顯示已達成的一致性層級。 各狀態的含義請參閱下表。

建議在所有生產環境的虛擬機器上安裝 QEMU 客體代理程式。 在 Linux 的訪客端，請使用以下指令。

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

對於 Windows 客座，請安裝 VirtIO 驅動程式套件，其中包含 QEMU 客座代理服務。

適用於各類應用程式的自訂凍結/解凍掛鉤：對於需要比檔案系統凍結更徹底的靜止處理之資料庫及其他具狀態的應用程式，請將自訂掛鉤腳本置於客體虛擬機器工作負載的 /etc/qemu-ga/fsfreeze-hook.d/ 目錄中。 這些腳本會由客體代理程式自動執行，在檔案系統被凍結前會傳入 freeze 參數，而在檔案系統解凍後則會傳入 thaw 參數。 鉤子執行日誌會寫入 /var/log/qga-fsfreeze-hook.log。

例如，可以在 /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh 放置以下 PostgreSQL 凍結鉤子：

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware 比較：此範例類似於 VMware 的「預冷凍」與「解凍後」腳本，該腳本會與 VMware Tools 搭配使用，以建立應用程式一致性的快照。 QEMU 來賓代理在快照靜止狀態方面，扮演的角色與 VMware Tools 相同。

變更區塊追蹤限制

「變更區塊追蹤」功能可透過僅識別自上次備份以來有所變更的區塊，來實現增量備份。 VMware 的 VADP（ vStorage 資料保護 API）利用此機制來提供高效的增量備份。

CBT 不適用於 Red Hat OpenShift 虛擬化上的 ODF 和 Ceph RBD。 目前備份依賴完整快照，這可能會導致備份時段延長，並增加儲存空間的使用量。

CBT 的開發正在多層面進行：

雖然 Ceph RBD 支援底層的「快照區塊差異追蹤」（ rbd diff ）功能，用以識別快照之間的變更區塊，但此功能目前尚未透過 Kubernetes CSI 變更區塊追蹤 API 對外提供。 在完整堆疊到位之前 (CSI CBT API + Ceph CSI 驅動程式支援 + KubeVirt 整合)，區塊層級的增量備份無法使用。

備份解決方案

有幾家備份供應商提供適用於 Red Hat OpenShift 虛擬化的解決方案，這些方案可在當前的快照式模型下運作：

• Veeam® Kasten：Kubernetes-原生資料保護，支援 Red Hat OpenShift 虛擬化和 ODF 的增量快照功能。 如需詳細資訊，請參閱 Veeam Kasten 參考架構。
• Trilio for Kubernetes：Red Hat OpenShift 虛擬化工作負載的備份與復原，並與 ODF 整合。 如需詳細資訊，請參閱 Trilio Red Hat OpenShift 虛擬化支援。
• Veritas NetBackup: Enterprise 備份，支援 Red Hat OpenShift 虛擬化。 如需更多資訊，請參閱 NetBackup —— 全面性的企業資料保護方案。

VMware 移轉建議

如果您目前的 VMware 環境依賴於基於 CBT 的增量備份，請考慮以下建議：

• 規劃完整快照備份。 請根據完整的 VolumeSnapshots （而非增量備份），評估您的備份時段與儲存需求。
• 評估 Kubernetes- 原生備份工具。 Veeam Kasten 和 Trilio 是專為 Kubernetes 及 Red Hat OpenShift 虛擬化環境所設計，並在現有的快照模型下運作。
• 使用 Ceph 快照的效率。 Ceph RBD 快照採用「寫入時複製」機制，在快照建立後僅針對變更過的區塊佔用儲存空間，因此相較於完整複製，持續性快照的儲存效率更高。

監控 ODF 和 Ceph 的健康狀況

定期監控 ODF 儲存群集對於維持可用性和效能至關重要。 以下部分將介紹主要指令及其輸出內容。

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

在 Red Hat OpenShift Kubernetes Service

IBM Cloud Red Hat OpenShift Data Foundation (ODF) 附加元件會自動套用同一次次要版本內的 z-stream 更新。 這些更新透過 IBM Cloud 管理。

然而，主要版本與次要版本的升級（例如，4.18 → 4.19 ）並不會自動進行。 請依照手動升級程序操作，以確保資料安全與叢集穩定性。

在 Red Hat OpenShift Kubernetes Service 集群上更新 ODF 包括兩個主要階段，這兩個階段都是成功升級所必需的。

1. 升級或更換 ODF 工作節點。

   • ODF 依賴專用或標籤工作節點來託管儲存元件。
   • 在主要或次要升級期間，這些工作節點必須升級或更換，以便與目標 Red Hat OpenShift 和 ODF 版本一致。
   • 此流程有助於確保 ODF Pod（例如 Ceph OSD、MON 和管理員）能正確重新排程，並在不遺失資料的情況下繼續運作。
   • 在開始執行此步驟之前，請確保具備足夠的容量且節點狀態良好，以維持儲存空間的可用性。

2. 更新 ODF 附加元件。

   • 在升級或更換工作節點後，更新 ODF 附加元件。
   • 此步驟將 ODF 操作員、CSI 驅動程式及相關元件升級至目標版本。
   • 附加元件更新完成後，群集會自動調節 ODF 資源，並套用所需的變更。

   執行升級後的驗證程序以確認：

   • ODF 和 Ceph 集群健康
   • StorageClasses 可用性
   • 應用程式成功進行 PVC 讀寫作業

如需詳細資訊，請參閱 在 VPC 集群上更新 ODF。

擴充 ODF 儲存空間於 Red Hat OpenShift Kubernetes Service

因此，隨著您的工作負載不斷增長及儲存需求日益增加，擴展儲存基礎架構便變得至關重要。 ODF 中的擴充是重要的第 2 天作業，可讓您增加儲存容量、改善效能並維持彈性，而不會中斷執行中的應用程式。

在 IBM Cloud Red Hat OpenShift Kubernetes Service 環境中，擴充通常涉及擴充儲存工作者池。 執行此作業時，停機時間極短，可讓您的儲存群集無縫成長。

1. 將工作節點新增至您的 VPC 叢集。 對於儲存叢集橫跨 3 個可用區域的多區域叢集，請以 3 的倍數新增工作節點，以維持區域平衡（例如 3、6 或 9）。 對於已啟用彈性擴展功能的單區域叢集，您可以一次新增一個節點。

2. 新增節點後，請將其註冊至 ODF。 如果 ODF 在您叢集中的所有工作節點上運行，新節點將會自動加入儲存拓撲中。 如果 ODF 僅在部分工作節點上運行，請繼續執行下一步。

3. 如果 ODF 在群集中的所有 Worker 節點上執行，新的 Worker 節點會自動新增到 ODF 儲存群集拓樸中。 若 ODF 僅在部分工作節點上運行，請在您的 OcsCluster 自訂資源中指定私有 參數。 透過編輯自訂資源定義，將新工作站節點的名稱新增至 ODF 部署。 請依下列方式修改「OcsCluster」自訂資源：

   • 尋找 ocscluster

     oc get ocscluster
     

   • 編輯 ocscluster 自訂資源檔案，並新增工作節點

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • 將「OcsCluster」自訂資源檔案儲存下來，以便重新套用至您的叢集。

4. 請在您的 OcsCluster 自訂資源中提高 'numOfOsd' 的數值，以讓 OCS 能在新新增的工作節點上部署 ODF 元件，並在儲存叢集中配置額外的 OSD。

   對 'numOfOsd' 的調整，取決於每個節點的 OSD 磁碟數量以及新增的節點數量。 舉例來說，若每個節點各有 8 顆專用於 OSD 的 NVMe 硬碟，則新增 3 個節點會使「'numOfOsd'」增加 8，而新增 6 個節點則會使其增加 16。

5. 請執行以下指令以驗證結果：

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. 請確認新的工作節點已新增，並均勻分佈於各區域（針對多區域叢集）或顯示為獨立的主機桶（針對單一區域的彈性擴展叢集），同時確認每個節點已分配到相應數量的 OSD。

如需更多資訊，請參閱 《 透過在 VPC 叢集中新增工作節點來擴展 ODF 》。

彈性調整

IBM Cloud 的 ODF 附加元件會根據您的叢集配置，採用不同的故障域拓撲：

• 多區域叢集（3 個可用區域）： 故障域設定為 zone。 OSD 的配置以 3 的倍數為單位，每個區域配置一組，以維持跨區域的資料複寫與高可用性。 儲存叢集必須以 3 的倍數擴充，以維持各區域的平衡。
• 單一區域叢集或擁有少於 3 個可用區域的叢集： 將自動啟用彈性擴展功能。 故障域設定為 host，這表示每個節點皆為一個獨立的故障域。 您可以一次新增一個節點，並以細粒度的方式擴展儲存空間。

自 ODF 4.21 起，彈性擴展行為會在初次部署時根據叢集拓撲自動決定，且之後無法變更。

在單一區域或彈性擴展部署中，replica-3 叢集即使失去任何單一主機，仍能持續運作。 在多區域部署中，replica-3 叢集即使整個區域發生故障，仍能持續運作。 在將 ODF 部署至生產環境之前，請評估您的叢集拓撲及其相關的容錯能力是否符合您的韌性需求。

如需完整的附加元件參數清單及基於控制台的安裝步驟，請參閱 《 在 VPC 叢集中部署 OpenShift Data Foundation 》。

節點擴展期間的效能： 向具彈性擴展能力的 ODF 叢集新增一個節點，會觸發 Ceph 資料重新平衡。 在下文所述的內部測試中，IOPS 和吞吐量保持穩定，但寫入延遲則暫時有所增加。 在一個由 3 個節點組成的叢集上，針對 100 台虛擬機器進行 50,000 IOPS 的內部測試時，觀察到以下結果：

重新平衡完成後，寫入延遲將恢復至基準值。 若您的工作負載對寫入延遲的驟升較為敏感，請在 VM 活動較低的時段規劃新增節點。