跳至內容
documentation.suse.com / 部署指南
SUSE Enterprise Storage 7

部署指南

 
原著者: Tomáš Bažant、Alexandra Settle、Liam Proven
出版日期：2023-12-11
附圖目錄

版權所有 © 2020–2023 SUSE LLC 和貢獻者。版權所有。

除非另有說明，否則本文件依據創用 CC 姓名標示-相同方式分享 4.0 國際 (Creative Commons Attribution-ShareAlike 4.0 International, CC-BY-SA 4.0) 獲得授權：https://creativecommons.org/licenses/by-sa/4.0/legalcode。

如需 SUSE 商標，請參閱 http://www.suse.com/company/legal/。所有的協力廠商商標均為其各別擁有廠商的財產。®、™ 等商標符號表示 SUSE 及其關係企業的商標。星號 (*) 表示協力廠商的商標。

本手冊中所有資訊在編輯時，都已全力注意各項細節。但這不保證百分之百的正確性。因此，SUSE LLC 及其關係企業、作者或譯者都不需對任何錯誤或造成的結果負責。

關於本指南

 

本指南重點介紹如何部署基本 Ceph 叢集以及如何部署其他服務。此外，還介紹了從先前的產品版本升級至 SUSE Enterprise Storage 7 的步驟。

SUSE Enterprise Storage 7 是 SUSE Linux Enterprise Server 15 SP2 的一個延伸。它結合了 Ceph (http://ceph.com/) 儲存專案的功能與 SUSE 的企業工程和支援。憑藉 SUSE Enterprise Storage 7，IT 組織能夠部署可以支援一些使用商用硬體平台的使用案例的分散式儲存架構。

1 可用文件

 
注意
注意：線上文件和最新更新

我們的產品文件可從 https://documentation.suse.com 獲取，您也可以在此處找到最新更新，以及瀏覽或下載各種格式的文件。最新的文件更新以英語版本提供。

此外，您安裝的系統的 /usr/share/doc/manual 下會提供產品文件。該文件包含在名為 ses-manual_LANG_CODE的 RPM 套件中。如果系統上尚未安裝該套件，請進行安裝，例如： 

root # zypper install ses-manual_en

針對本產品提供的文件如下：

部署指南

本指南重點介紹如何部署基本 Ceph 叢集以及如何部署其他服務。此外，還介紹了從先前的產品版本升級至 SUSE Enterprise Storage 7 的步驟。

管理和操作指南

本指南重點介紹在部署基本 Ceph 叢集 (第 2 天操作) 之後，做為管理員需要處理的例行任務。此外，還介紹了存取 Ceph 叢集中所儲存資料的所有支援方法。

安全強化指南

本指南重點介紹如何確保叢集的安全。

Troubleshooting Guide

本指南將引導您瞭解執行 SUSE Enterprise Storage 7 時的各種常見問題以及與 Ceph 或物件閘道等相關元件有關的其他問題。

SUSE Enterprise Storage for Windows 指南

本指南介紹如何使用 Windows 驅動程式整合、安裝和設定 Microsoft Windows 環境和 SUSE Enterprise Storage。

2 提供回饋

 

歡迎您對本文件提供回饋和貢獻。回饋管道包括：

服務要求和支援

如需產品可用的服務與支援選項，請參閱 http://www.suse.com/support/。

若要開啟服務要求，需要在 SUSE Customer Center 註冊一個 SUSE 訂閱。請移至 https://scc.suse.com/support/requests 並登入，然後按一下新建立的。

錯誤報告

在 https://bugzilla.suse.com/ 中報告文件問題。報告問題需要有 Bugzilla 帳戶。

若要簡化此程序，可以使用本文件 HTML 版本中的標題旁邊的報告文件錯誤連結。如此會在 Bugzilla 中預先選取正確的產品和類別，並新增目前章節的連結。然後，您便可以立即開始輸入錯誤報告。

協助改進

若要協助我們改進本文件，請使用本文件 HTML 版本中的標題旁邊的編輯原始碼連結。這些連結會將您移至 GitHub 上的原始碼，在其中您可以開啟提取要求。參與貢獻需要有 GitHub 帳戶。

如需本文件使用的文件環境的詳細資訊，請參閱儲存庫的讀我檔案（網址：https://github.com/SUSE/doc-ses）。

郵件

您也可以將有關本文件中的錯誤以及相關回饋傳送至：<>。請在其中包含文件標題、產品版本以及文件發行日期。此外，請包含相關的章節編號和標題 (或者提供 URL)，並提供問題的簡要描述。

3 文件慣例

 

本文件中使用以下注意事項與排版慣例：

  • /etc/passwd：目錄名稱和檔案名稱

  • PLACEHOLDER：以實際的值來取代 PLACEHOLDER

  • PATH：環境變數

  • ls、--help：指令、選項和參數

  • user：使用者或群組的名稱

  • package_name：軟體套件的名稱

  • Alt、Alt–F1：按鍵或鍵組合。按鍵以大寫字母顯示，與鍵盤上的相同。

  • 檔案、 檔案 ›  另存新檔：功能表項目、按鈕

  • AMD/Intel 本段僅與 Intel 64/AMD64 架構有關。箭頭標示了文字區塊的開頭與結尾。

    IBM Z, POWER 本段內容僅與 IBM Z 和 POWER 架構相關。箭頭標示了文字區塊的開頭與結尾。

  • 第 1 章「範例章節」：轉到本指南中另一章節的交互參照。

  • 必須具有 root 權限才能執行的指令。通常，您也可以在這些指令前加上 sudo 指令，以非特權使用者身分來執行它們。 

    root # command
tux > sudo command

  • 沒有權限的使用者也可以執行的指令。 

    tux > command

  • 注意事項

    警告
    警告：警告通知

    繼續操作之前必須瞭解的重要資訊。提醒您注意安全問題、可能的資料遺失、硬體損毀或者實際危險。

    重要
    重要：重要通知

    繼續操作之前應該瞭解的重要資訊。

    注意
    注意：注意通知

    其他資訊，例如各軟體版本之間的區別。

    提示
    提示：提示通知

    有用的資訊，例如一條準則或實用的建議。

  • 精簡通知

    注意

    其他資訊，例如各軟體版本之間的區別。

    提示

    有用的資訊，例如一條準則或實用的建議。

4 產品生命週期和支援

 

不同的 SUSE 產品具有不同的產品生命週期。若要查看 SUSE Enterprise Storage 的確切生命週期日期，請參閱 https://www.suse.com/lifecycle/。

4.1 SUSE 支援定義

 

如需我們的支援政策和選項的資訊，請參閱 https://www.suse.com/support/policy.html 和 https://www.suse.com/support/programs/long-term-service-pack-support.html。

4.2 SUSE Enterprise Storage 支援聲明

 

若要獲得支援，您需要一個適當的 SUSE 訂閱。若要檢視為您提供的特定支援服務，請移至 https://www.suse.com/support/ 並選取您的產品。

支援層級的定義如下：

L1

問題判斷，該技術支援層級旨在提供相容性資訊、使用支援、持續維護、資訊收集，以及使用可用文件進行基本疑難排解。

L2

問題隔離，該技術支援層級旨在分析資料、重現客戶問題、隔離問題區域，並針對層級 1 不能解決的問題提供解決方法，或做為層級 3 的準備層級。

L3

問題解決，該技術支援層級旨在借助工程方法解決層級 2 支援所確認的產品缺陷。

對於簽約的客戶與合作夥伴，SUSE Enterprise Storage 將為除以下套件外的其他所有套件提供 L3 支援：

  • 技術預覽

  • 音效、圖形、字型和作品

  • 需要額外客戶合約的套件

  • 模組 Workstation Extension 隨附的某些套件僅可享受 L2 支援。

  • 名稱以 -devel 結尾的套件 (包含標題檔案和類似的開發人員資源) 只能與其主套件一起接受支援。

SUSE 僅支援使用原始套件，即，未發生變更且未重新編譯的套件。

4.3 技術預覽

 

技術預覽是 SUSE 提供的旨在讓使用者大略體驗未來創新的各種套件、堆疊或功能。隨附這些技術預覽只是為了提供方便，讓您有機會在自己的環境中測試新的技術。非常希望您能提供回饋！如果您測試了技術預覽，請聯絡 SUSE 代表，將您的體驗和使用案例告知他們。您的回饋對於我們的未來開發非常有幫助。

技術預覽存在以下限制：

  • 技術預覽仍處於開發階段。因此，它們的功能可能不完整、不穩定，或者在其他方面不適合實際生產用途。

  • 技術預覽不受支援。

  • 技術預覽可能僅適用於特定的硬體架構。

  • 技術預覽的詳細資料和功能可能隨時會發生變化。因此，可能無法升級至技術預覽的後續版本，而需要進行全新安裝。

  • 可隨時從產品中移除技術預覽。SUSE 不承諾未來將提供此類技術的受支援版本。例如，如果 SUSE 發現某個預覽不符合客戶或市場需求，或者不符合企業標準，則可能會移除該預覽。

如需產品隨附的技術預覽綜覽，請參閱 https://www.suse.com/releasenotes/x86_64/SUSE-Enterprise-Storage/7 上的版本說明。

5 Ceph 參與者

 

Ceph 專案及其文件是數百個參與者和組織辛勤工作的成果。請參閱 https://ceph.com/contributors/，以取得詳細資料。

6 本指南中使用的指令和指令提示符

 

做為 Ceph 叢集管理員，您需要透過執行特定指令來設定和調整叢集行為。您將需要執行以下幾種類型的指令：

6.1 與 Salt 相關的指令

 

這些指令可協助您部署 Ceph 叢集節點、同時在數個 (或所有) 叢集節點上執行指令，或在您新增或移除叢集節點時為您提供協助。最常用的指令是 ceph-salt 和 ceph-salt config。您需要以 root 身分在 Salt Master 節點上執行 Salt 指令。透過以下提示符來引入這些指令： 

root@master #

例如： 

root@master # ceph-salt config ls

6.2 與 Ceph 相關的指令

 

這些是較低層級的指令，用於在指令行上設定和微調叢集及其閘道的所有方面，例如 ceph、cephadm、rbd 或 radosgw-admin。

若要執行與 Ceph 相關的指令，您需要擁有 Ceph 金鑰的讀取存取權，而金鑰的功能則定義您在 Ceph 環境內的權限。一種方案是以 root 身分 (或透過 sudo) 執行 Ceph 指令，並使用不受限制的預設金鑰圈「ceph.client.admin.key」。

建議您使用更安全的方案，即為每個管理員使用者建立限制性更高的個別金鑰，並將其存放在使用者可讀取的目錄中，例如： 

~/.ceph/ceph.client.USERNAME.keyring
提示
提示：Ceph 金鑰的路徑

若要使用自訂管理員使用者和金鑰圈，每次執行 ceph 指令 (使用 -n client.USER_NAME 和 --keyring PATH/TO/KEYRING 選項) 時，都需要指定該金鑰的使用者名稱和路徑。

為避免出現此情況，請將這些選項包含在各個使用者的 ~/.bashrc 檔案中的 CEPH_ARGS 變數中。

儘管您可以在任何叢集節點上執行與 Ceph 相關的指令，但我們建議您在管理節點上執行。本文件使用 cephuser 使用者來執行指令，因此透過以下提示符來引入指令： 

cephuser@adm >

例如： 

cephuser@adm > ceph auth list
提示
提示：特定節點的指令

如果文件指示您在叢集節點上以特定角色來執行指令，應透過該提示符來定址。例如： 

cephuser@mon >

6.2.1 執行 ceph-volume

 

從 SUSE Enterprise Storage 7 開始，Ceph 服務以容器化方式執行。如果您需要在 OSD 節點上執行 ceph-volume，則需要在其前面加上 cephadm 指令，例如： 

cephuser@adm > cephadm ceph-volume simple scan

6.3 一般的 Linux 指令

 

與 Ceph 無關的 Linux 指令 (例如 mount、cat 或 openssl) 可透過 cephuser@adm > 或 root # 提示符來引入，具體取決於相關指令所需的權限。

6.4 其他資訊

 

如需 Ceph 金鑰管理的詳細資訊，請參閱Book “操作和管理指南”, Chapter 30 “使用 cephx 進行驗證”, Section 30.2 “主要管理”。

第 I 部分 介紹 SUSE Enterprise Storage (SES)

 
  • 1 SES 和 Ceph

    • SUSE Enterprise Storage 是基於 Ceph 技術的分散式儲存系統，旨在提高延展性、可靠性和效能。Ceph 叢集可在通用網路 (例如乙太網路) 中的商用伺服器上執行。此類叢集可以順利地擴展至數千部伺服器 (下文稱為「節點」) 並擁有 PB 級的處理能力。與使用配置表來儲存和擷取資料的傳統系統相反，Ceph 使用決定性演算法來為資料配置儲存空間，且不採用任何集中式資訊結構。Ceph 的假設是，在儲存叢集中的硬體新增或移除屬於常例，而非例外情況。Ceph 叢集可將資料分發和重新分發、資料複製、故障偵測和復原等管理任務自動化。Ceph 既可自我修復，又可自我管理，因此降低了管理負…

  • 2 硬體要求和建議

    • Ceph 的硬體要求在很大程度上取決於 IO 工作負載。在開始進行詳細規劃時，應考慮以下硬體要求和建議。

  • 3 管理節點 HA 設定

    • 管理節點是執行 Salt Master 服務的 Ceph 叢集節點。它負責管理叢集的其餘節點，它會查詢這些節點的 Salt Minion 服務並向其提供指示。它通常也會包含其他服務，例如 Grafana 儀表板 (由 Prometheus 監控工具套件提供支援)。

1 SES 和 Ceph

 

SUSE Enterprise Storage 是基於 Ceph 技術的分散式儲存系統，旨在提高延展性、可靠性和效能。Ceph 叢集可在通用網路 (例如乙太網路) 中的商用伺服器上執行。此類叢集可以順利地擴展至數千部伺服器 (下文稱為「節點」) 並擁有 PB 級的處理能力。與使用配置表來儲存和擷取資料的傳統系統相反，Ceph 使用決定性演算法來為資料配置儲存空間，且不採用任何集中式資訊結構。Ceph 的假設是，在儲存叢集中的硬體新增或移除屬於常例，而非例外情況。Ceph 叢集可將資料分發和重新分發、資料複製、故障偵測和復原等管理任務自動化。Ceph 既可自我修復，又可自我管理，因此降低了管理負荷和預算負擔。

本章提供 SUSE Enterprise Storage 7 的高階綜覽，並簡要介紹一些最重要的元件。

1.1 Ceph 特性

 

Ceph 環境具有以下特性：

可延展性

Ceph 可延伸至數千個節點，並可管理 PB 級的儲存。

商用硬體

無需特殊的硬體即可執行 Ceph 叢集。若需要詳細資料，請參閱第 2 章 「硬體要求和建議」

自我管理

Ceph 叢集可自我管理。新增、移除節點或節點發生故障時，叢集可自動重新分發資料。此外，它還能識別超載的磁碟。

無單一故障點

重要的資訊不會單獨儲存在叢集中的某個節點上。您可設定備援數量。

開放原始碼軟體

Ceph 是一套開放原始碼軟體解決方案，獨立於特定的硬體或廠商。

1.2 Ceph 核心元件

 

若要充分利用 Ceph 的強大功能，需要瞭解一些基本的元件和概念。本節介紹經常在其他章節中提及的 Ceph 的某些組成部分。

1.2.1 RADOS

 

Ceph 的基本元件稱為 RADOS (可靠自主分散式物件儲存) 。該元件負責管理叢集中儲存的資料。Ceph 中的資料通常以物件的形式儲存。每個物件由識別碼和資料組成。

RADOS 提供以下方法來存取涉及許多使用案例的儲存物件：

物件閘道

物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。使用該閘道可以直接存取 Ceph 叢集中儲存的物件。

RADOS 區塊裝置

您可以如存取任何其他區塊裝置一樣，存取 RADOS 區塊裝置 (RBD)。例如，可將這些裝置與 libvirt 組合使用，以實現虛擬化。

CephFS

Ceph 檔案系統是符合 POSIX 標準的檔案系統。

librados

librados 是一個程式庫，可與許多程式設計語言搭配使用，以建立能夠直接與儲存叢集互動的應用程式。

librados 由物件閘道和 RBD 使用，而 CephFS 直接與 RADOS 連接。請參閱圖形 1.1 「與 Ceph 物件儲存的連接」。

與 Ceph 物件儲存的連接
圖 1.1︰ 與 Ceph 物件儲存的連接
 

1.2.2 CRUSH

 

Ceph 叢集的核心是 CRUSH 演算法。CRUSH 是 Controlled Replication Under Scalable Hashing (基於可延展雜湊的受控複製) 的縮寫。CRUSH 是處理儲存配置的函數，所需的參數相對較少。這意味著，只需提供少量的資訊就能計算物件的儲存位置。參數是叢集的目前對應，包括健康狀態、管理員定義的某些放置規則，以及需要儲存或擷取的物件名稱。提供這些資訊後，Ceph 叢集中的所有節點即可計算物件及其複本的儲存位置。如此可讓資料寫入或讀取變得非常高效。CRUSH 會嘗試在叢集中的所有節點上均勻分發資料。

CRUSH 地圖包含所有儲存節點，以及由管理員定義有關在叢集中儲存物件的放置規則。該地圖定義了通常對應於叢集實體結構的階層結構。例如，包含資料的磁碟位於主機中，主機位於機架中，機架位於裝置列中，而裝置列位於資料中心中。此結構可用於定義故障網域。然後，Ceph 可確保將複製項儲存在特定故障網域的不同分支中。

如果將故障網域設定為機架，則將在不同的機架中分發物件複製項。這樣做可緩解機架中的交換器發生故障所造成的服務中斷。如果某個電源分配單位為一列機架供電，則可將故障網域設定為裝置列。當電源分配單位發生故障時，其他裝置列中仍可提供複製的資料。

1.2.3 Ceph 節點和精靈

 

在 Ceph 中，節點是為叢集工作的伺服器。它們可以執行多種不同類型的精靈。建議在每個節點上僅執行一種類型的精靈，但 Ceph 管理員精靈除外，此類精靈可與 Ceph 監控程式併置。每個叢集都至少需要執行 Ceph 監控程式、Ceph 管理員和 OSD 精靈：

管理節點

管理節點是執行相應指令來管理叢集的一種 Ceph 叢集節點。管理節點是 Ceph 叢集的中心點，因為它透過查詢叢集其餘節點的 Salt Minion 服務並提供指示來管理其餘節點。

Ceph 監控程式

Ceph 監控程式 (通常縮寫為 MON) 節點負責維護有關叢集健康狀態、所有節點的地圖和資料分發規則的資訊 (請參閱第 1.2.2 節 「CRUSH」)。

如果發生故障或衝突，叢集中的 Ceph 監控程式節點會依據多數原則確定哪些資訊是正確的。為了構成有效的多數，建議您設定奇數數量的 Ceph 監控程式節點，並至少設定三個這樣的節點。

如果使用多個站點，應在奇數個站點之間分發 Ceph 監控程式節點。每個站點的 Ceph 監控程式節點數應滿足以下要求：當有一個站點發生故障時，50% 以上的 Ceph 監控程式節點仍保持正常執行。

Ceph 管理員

Ceph 管理員會從整個叢集收集狀態資訊。Ceph 管理員精靈與 Ceph 監控程式精靈一同執行。它會提供附加的監控功能，並與外部監控和管理系統連接。它還包含其他服務。例如，Ceph Dashboard Web UI 與 Ceph 管理員在同一節點上執行。

Ceph 管理員不需要額外設定，只需確定它在執行即可。

Ceph OSD

Ceph OSD 是一個精靈，負責處理屬於實體或邏輯儲存單位 (硬碟或分割區) 的物件儲存裝置。物件儲存裝置可以是實體磁碟/分割區，也可以是邏輯磁碟區。此外，該精靈還會處理資料複製，並在新增或移除節點後進行重新平衡。

Ceph OSD 精靈與監控程式精靈通訊，並為其提供其他 OSD 精靈的狀態。

若要使用 CephFS、物件閘道、NFS Ganesha 或 iSCSI 閘道，還需要其他節點：

中繼資料伺服器 (MDS)

CephFS 中繼資料儲存在自己的 RADOS 池中 (請參閱第 1.3.1 節 「池」)。中繼資料伺服器充當中繼資料的智慧型快取層，會視需要對存取進行序列化。如此，無需明確同步，即可允許許多用戶端進行並行存取。

物件閘道

物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。它與 OpenStack Swift 和 Amazon S3 相容，具有自己的使用者管理功能。

NFS Ganesha

使用 NFS Ganesha 可透過 NFS 存取物件閘道或 CephFS。該元件在使用者空間而不是核心空間中執行，直接與物件閘道或 CephFS 互動。

iSCSI 閘道

iSCSI 是一種儲存網路通訊協定，可讓用戶端將 SCSI 指令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。

Samba 閘道

Samba 閘道提供對 CephFS 上所儲存資料的 Samba 存取途徑。

1.3 Ceph 儲存結構

 

1.3.1 池

 

Ceph 叢集中儲存的物件放置在池中。對外部環境而言，池代表叢集的邏輯分割區。對於每個池，可以定義一組規則，例如，每個物件必須有多少個複製項。池的標準組態稱為複本池。

池通常包含多個物件，但也可以將其設定為充當類似 RAID 5 的作用。在此組態中，物件連同其他編碼區塊一起儲存在區塊中。編碼區塊包含備援資訊。管理員可以定義資料和編碼區塊的數量。在此組態中，池稱為糾刪碼池或 EC 池。

1.3.2 放置群組

 

放置群組 (PG) 用於在池中分發資料。建立池時，會設定特定數目的放置群組。放置群組在內部用於將物件分組，是影響 Ceph 叢集效能的重要因素。物件的 PG 依據該物件的名稱確定。

1.3.3 範例

 

本節提供有關 Ceph 如何管理資料的簡化範例 (請參閱圖形 1.2 「小規模 Ceph 範例」)。此範例並不代表 Ceph 叢集的建議組態。硬體設定由三個儲存節點或 Ceph OSD (主機 1、主機 2 和主機 3) 組成。每個節點包含三個用做 OSD (osd.1 到 osd.9) 的硬碟。此範例中略過了 Ceph 監控程式節點。

注意
注意：Ceph OSD 與 OSD 之間的差別

儘管 Ceph OSD 或 Ceph OSD 精靈是指節點上執行的精靈，但 OSD 一詞指的卻是與精靈互動的邏輯磁碟。

叢集包含兩個池：池 A 和池 B。儘管池 A 僅複製物件兩次，但池 B 的韌性更重要，該池中的每個物件都有三個複製項。

當應用程式將某個物件放入池中時 (例如，透過 REST API)，將會依據池和物件名稱選擇放置群組 (PG1 到 PG4)。然後，CRUSH 演算法會依據包含物件的放置群組，計算要將物件儲存到哪些 OSD。

在此範例中，故障網域設定為主機。這可確保將物件的複製項儲存在不同的主機上。依據針對池設定的複製層級，物件將儲存在放置群組使用的兩個或三個 OSD 上。

寫入物件的應用程式只與一個 Ceph OSD (主要 Ceph OSD) 互動。主要 Ceph OSD 負責處理複製程序，並在所有其他 OSD 儲存物件後確認寫入程序完成。

如果 osd.5 發生故障，osd.1 上仍會提供 PG1 中的所有物件。一旦叢集發現某個 OSD 發生故障，另一個 OSD 會立即接管工作。在此範例中，osd.4 用於取代 osd.5。然後，會將 osd.1 上儲存的物件複製到 osd.4，以還原複製層級。

小規模 Ceph 範例
圖 1.2︰ 小規模 Ceph 範例
 

如果將包含新 OSD 的新節點新增到叢集，叢集地圖將會發生變更。然後，CRUSH 函數將傳回物件的不同位置。接收新位置的物件將被重新定位。此程序將平衡使用所有 OSD。

1.4 BlueStore

 

從 SES 5 開始，系統使用 BlueStore 做為 Ceph 的新預設儲存後端。BlueStore 的效能優於 FileStore，具有全資料檢查總數及壓縮功能。

它可管理一至三部儲存裝置。在最簡單案例中，BlueStore 會使用一個主要儲存裝置。該裝置通常被分割為兩部分：

  1. 一個名為 BlueFS 的較小分割區，用於執行 RocksDB 所需的類似檔案系統的功能。

  2. 其餘部分通常是一個較大的分割區，佔用了裝置的剩餘空間。它直接由 BlueStore 管理，包含所有實際資料。此主要裝置通常透過資料目錄中的區塊符號連結進行識別。

您還可跨兩個額外的裝置來部署 BlueStore：

WAL 裝置可用於儲存 BlueStore 的內部記錄或預寫記錄檔。它透過資料目錄中的 block.wal 符號連結進行識別。只有 WAL 裝置速度比主要裝置或 DB 裝置快時，使用單獨的 WAL 裝置才比較實用，例如，下列情況就很適合：

  • WAL 裝置是 NVMe，DB 裝置是 SSD，資料裝置是 SSD 或 HDD。

  • WAL 和 DB 裝置都是單獨的 SSD，資料裝置是 SSD 或 HDD。

DB 裝置可用於儲存 BlueStore 的內部中繼資料。BlueStore (更確切地說，是內嵌式 RocksDB) 會將盡可能多的中繼資料儲存於 DB 裝置，以提升效能。再次重申，只有共用 DB 裝置速度比主要裝置快時，佈建共用 DB 裝置才有所助益。

提示
提示：規劃 DB 大小

規劃時請考慮充分，以確定為 DB 裝置配置足夠的大小。如果 DB 裝置填滿，中繼資料將溢出至主要裝置，這會嚴重降低 OSD 的效能。

您可以使用 ceph daemon osd.ID perf dump 指令來檢查 WAL/DB 分割區是否即將填滿及溢出。slow_used_bytes 值顯示即將溢出的資料數量： 

cephuser@adm > ceph daemon osd.ID perf dump | jq '.bluefs'
"db_total_bytes": 1073741824,
"db_used_bytes": 33554432,
"wal_total_bytes": 0,
"wal_used_bytes": 0,
"slow_total_bytes": 554432,
"slow_used_bytes": 554432,

1.5 其他資訊

 

  • 做為一個社群專案，Ceph 自身擁有大量線上文件。對於本手冊中未介紹的主題，請參閱 https://docs.ceph.com/en/octopus/。

  • 由 S.A. Weil、S.A. Brandt、E.L. Miller 和 C. Maltzahn 撰寫的原始文獻 CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data (CRUSH：複製資料的受控、可延展、分散式放置) 提供了有關 Ceph 內部工作原理的有用見解。特別是在部署大規模叢集時，推薦您閱讀此文章。可在 http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf 上找到該文獻。

  • SUSE Enterprise Storage 可與非 SUSE OpenStack 套裝作業系統配合使用。Ceph 用戶端需與 SUSE Enterprise Storage 相容。

    注意
    注意

    SUSE 負責支援 Ceph 部署的伺服器元件，由 OpenStack 套裝作業系統廠商對用戶端提供支援。

2 硬體要求和建議

 

Ceph 的硬體要求在很大程度上取決於 IO 工作負載。在開始進行詳細規劃時，應考慮以下硬體要求和建議。

一般情況下，本節所述的建議是按程序提出的。如果同一部機器上有多個程序，則需要提高 CPU、RAM、磁碟和網路要求。

2.1 網路綜覽

 

Ceph 有以下幾個邏輯網路：

  • 名為公用網路的前端網路。

  • 名為叢集網路的可信內部網路 (後端網路)。這是選擇性的。

  • 閘道的一個或多個用戶端網路。此為選擇性網路，不在本章的討論範圍之內。

公用網路是 Ceph 精靈相互之間以及與其用戶端之間進行通訊的網路。這表示所有 Ceph 叢集流量都透過該網路傳輸 (設定叢集網路時除外)。

叢集網路是 OSD 節點之間的後端網路，用於執行複製、重新平衡和復原操作。如果設定了此選擇性網路，則理想情況下，它將提供兩倍於公用網路的頻寬 (預設為三向複製)，因為主 OSD 會透過此網路向其他 OSD 傳送兩個複本。公用網路位於用戶端和閘道之間，用於在其中一端與監控程式、管理員、MDS 節點、OSD 節點進行通訊。監控程式、管理員和 MDS 節點也會使用該網路與 OSD 節點進行通訊。

網路綜覽
圖 2.1︰ 網路綜覽
 

2.1.1 網路建議

 

我們建議使用具有足夠頻寬的單一容錯網路，以滿足您的需求。對於 Ceph 公用網路環境，我們建議使用透過 802.3ad (LACP) 進行結合的兩個結合 25 GbE (或更快的) 網路介面。這被視為 Ceph 的最小設定。如果您還使用叢集網路，則建議您使用四個結合 25 GbE 網路介面。結合兩個或更多網路介面可透過連結聚總提供更高的輸送量，並可提供備援連結和交換器，進而提高了容錯性和可維護性。

您還可以建立 VLAN 來隔離透過結合傳輸的不同類型的流量。例如，您可以建立一個結合來提供兩個 VLAN 介面，一個用於公用網路，另一個用於叢集網路。但在設定 Ceph 網路時不需要這樣做。如需結合介面的詳細資料，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-iface-bonding。

透過將元件隔離到故障網域中，可以提高容錯性。為了提高網路的容錯性，可從兩個單獨的網路介面卡 (NIC) 結合一個介面，以在單個 NIC 出現故障時提供保護。同樣，在兩個交換器之間建立一個結合可在單個交換器出現故障時提供保護。建議您向網路設備廠商諮詢，以構造所需的容錯層級。

重要
重要：不支援管理網路

其他管理網路設定 (例如可實現 SSH、Salt 或 DNS 網路分隔的設定) 未經過測試亦不受支援。

提示
提示：透過 DHCP 設定的節點

如果儲存節點是透過 DHCP 設定的，則預設逾時可能會不夠長，無法保證能在各個 Ceph 精靈啟動前正確設定網路。如果發生這種情況，Ceph MON 和 OSD 將無法正確啟動 (執行 systemctl status ceph\* 將產生「無法結合」錯誤)。為避免發生此問題，建議將您儲存叢集中每個節點上的 DHCP 用戶端逾時至少增加到 30 秒。為此，可在每個節點上變更以下設定：

在 /etc/sysconfig/network/dhcp 中，設定 

DHCLIENT_WAIT_AT_BOOT="30"

在 /etc/sysconfig/network/config 中，設定 

WAIT_FOR_INTERFACES="60"

2.1.1.1 將私人網路絡新增至執行中叢集

 

如果您在 Ceph 部署期間未指定叢集網路，則系統假設使用的是單一公用網路環境。儘管 Ceph 可在公用網路中正常運作，但如果您設定了另一個私人叢集網路，Ceph 的效能和安全性將會得到提升。若要支援兩個網路，每個 Ceph 節點上至少需有兩個網路卡。

需要對每個 Ceph 節點套用以下變更。對小型叢集執行此操作的速度相對較快，但如果叢集包含數百甚至數千個節點，則此程序可能十分耗時。

  1. 使用以下指令設定叢集網路： 

    root # ceph config set global cluster_network MY_NETWORK

    重新啟動 OSD 以結合到指定的叢集網路： 

    root # systemctl restart ceph-*@osd.*.service

  2. 檢查私人叢集網路在 OS 層級是否如預期般運作。

2.1.1.2 不同子網路中的監控節點

 

如果監控程式節點位於多個子網路中 (例如，位於不同的機房並由不同的交換器提供服務)，則您需要以 CIDR 表示法指定其公用網路位址。 

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

例如： 

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
警告
警告

如果依據本節中所述為公用 (或叢集) 網路指定了多個網路區段，則這些子網路中的每一個子網路都必須能夠路由到其他所有子網路，否則，不同網路區段上的 MON 與其他 Ceph 精靈將無法通訊，並且叢集將隨之分裂。此外，如果您使用防火牆，請確定在 iptables 中包含每個 IP 位址或子網路，並視需要在所有節點上為其開啟連接埠。

2.2 多架構組態

 

SUSE Enterprise Storage 支援 x86 和 Arm 架構。考慮每個架構時，請務必注意從每個 OSD 的核心數、頻率和 RAM 的角度進行，不同的 CPU 架構在大小調整方面並無實際差異。

與較小的 x86 處理器 (非伺服器) 一樣，效能較低的基於 Arm 的核心可能無法提供最佳體驗，特別是用於糾刪碼池時。

注意
注意

在整份文件中，使用 SYSTEM-ARCH 代替 x86 或 Arm。

2.3 硬體組態

 

為了獲得最佳產品體驗，建議您從推薦的叢集組態開始。對於測試叢集或效能要求較低的叢集，我們記錄了所支援的最低叢集組態。

2.3.1 最低叢集組態

 

最低產品叢集組態包括：

  • 至少四個實體節點 (OSD 節點)，支援服務併置

  • 做為結合網路的雙 10 Gb 乙太網路

  • 一個獨立管理節點 (可以在外部節點上虛擬化)

詳細組態如下：

  • 具有 4 GB RAM、四個核心和 1 TB 儲存容量的獨立管理節點。通常是 Salt Master 節點。Ceph 服務和閘道 (例如 Ceph 監控程式、中繼資料伺服器、Ceph OSD、物件閘道或 NFS Ganesha) 在管理節點上不受支援，因為它需要單獨協調叢集更新和升級程序。

  • 至少四個實體 OSD 節點，每個節點有八個 OSD 磁碟，相關要求請參閱第 2.4.1 節 「最低要求」。

    應調整叢集總容量的大小，以便即使有一個節點不可用，已用總容量 (包括備援) 也不超過 80%。

  • 三個 Ceph 監控程式例項。出於延遲原因，需要從 SSD/NVMe 儲存來執行監控程式，而不是透過 HDD 執行。

  • 監控程式、中繼資料伺服器和閘道可以併置在 OSD 節點上，請參閱第 2.12 節 「共用一部伺服器的 OSD 和監控程式」以瞭解監控程式併置。如果併置服務，則需要將記憶體和 CPU 要求相加。

  • iSCSI 閘道、物件閘道和中繼資料伺服器至少需要增量 4 GB RAM 和四個核心。

  • 如果您使用的是 CephFS、S3/Swift、iSCSI，則至少需要兩個各自角色 (中繼資料伺服器、物件閘道、iSCSI) 的例項才能實現備援和可用性。

  • 這些節點將專用於 SUSE Enterprise Storage，並且不得用於任何其他實體、容器化或虛擬化工作負載。

  • 如果虛擬機器中部署了任何閘道 (iSCSI、物件閘道、NFS Ganesha、中繼資料伺服器等)，則這些虛擬機器不得代管在為其他叢集角色提供服務的實體機器上。(這並非必要，因為它們可做為併置服務受到支援。)

  • 在核心實體叢集之外的監管程式上將服務部署為虛擬機器時，必須考慮故障網域以確保備援。

    例如，不要在同一個監管程式上部署多個同類角色，例如多個 MON 或 MDS 例項。

  • 在虛擬機器之內部署時，請務必確定節點具有強大的網路連接性和良好的工作時間同步。

  • 監管程式節點必須足夠大，以避免受到其他佔用 CPU、RAM、網路和儲存資源的工作負載的干擾。

最低叢集組態
圖 2.2︰ 最低叢集組態
 

2.3.2 建議的生產叢集組態

 

一旦您擴充了叢集，建議將 Ceph 監控程式、中繼資料伺服器和閘道重新定位到不同的節點，以獲得更好的容錯性。

  • 七個物件儲存節點

    • 單一節點不超出總儲存容量的 15% 左右。

    • 應調整叢集總容量的大小，以便即使有一個節點不可用，已用總容量 (包括備援) 也不超過 80%。

    • 25 Gb 乙太網路或以上，進行結合，一個用於內部叢集網絡，另一個用於外部公用網路。

    • 每個儲存叢集有 56 個以上的 OSD。

    • 如需進一步建議，請參閱第 2.4.1 節 「最低要求」。

  • 專屬的實體基礎架構節點。

2.3.3 多重路徑組態

 

如果要使用多重路徑硬體，請確定 LVM 會在組態檔案中的 devices 區段下看到 multipath_component_detection = 1。可以透過 lvm config 指令進行此項檢查。

另外，確定 LVM 透過 LVM 過濾器組態過濾裝置的 mpath 元件。此為主機特定。

注意
注意

不建議這樣做，只有在無法設定 multipath_component_detection = 1 時才應考慮這樣做。

如需多重路徑組態的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-multipath.html#sec-multipath-lvm。

2.4 物件儲存節點

 

2.4.1 最低要求

 

  • 以下 CPU 建議針對獨立於 Ceph 使用的裝置：

    • 每個旋轉式磁碟 1x 2GHz CPU 線串。

    • 每個 SSD 2x 2GHz CPU 線串。

    • 每個 NVMe 磁碟 4x 2GHz CPU 線串。

  • 獨立的 10 GbE 網路 (公用/用戶端和內部)，需要 4x 10 GbE，建議 2x 25 GbE。

  • 總計所需 RAM = OSD 數量 x (1 GB + osd_memory_target) + 16 GB

    如需 osd_memory_target 的更多詳細資料，請參閱Book “操作和管理指南”, Chapter 28 “Ceph 叢集組態”, Section 28.4.1 “設定自動快取大小調整”。

  • OSD 磁碟採用 JBOD 組態或個別的 RAID-0 組態。

  • OSD 記錄可以存放在 OSD 磁碟上。

  • OSD 磁碟應該專門由 SUSE Enterprise Storage 使用。

  • 作業系統專屬的磁碟和 SSD，最好採用 RAID 1 組態。

  • 如果此 OSD 主機將代管用於快取分層的快取池的一部分，則至少應再額外配置 4 GB RAM。

  • Ceph 監控程式、閘道和中繼資料伺服器可以存放在物件儲存節點上。

  • 出於磁碟效能考慮，OSD 節點是裸機節點。OSD 節點上不應執行其他工作負載，除非它是 Ceph 監控程式和 Ceph 管理員的最低設定。

  • 依據 6:1 的 SSD 記錄與 OSD 的比率為記錄提供 SSD。

注意
注意

確定 OSD 節點沒有對應任何網路區塊裝置，例如 iSCSI 或 RADOS 區塊裝置影像。

2.4.2 最小磁碟大小

 

需要在 OSD 上執行以下兩種類型的磁碟空間：用於 WAL/DB 裝置的空間以及用於儲存資料的主要空間。WAL/DB 的最小 (預設) 值為 6 GB。資料的最小空間為 5 GB，因為系統會自動為小於 5 GB 的分割區指定權數 0。

因此，儘管 OSD 的最小磁碟空間為 11 GB，但不建議使用小於 20 GB 的磁碟，即使在測試中也是如此。

2.4.3 BlueStore 的 WAL 和 DB 裝置的建議大小

 
提示
提示：詳細資訊

如需 BlueStore 的詳細資訊，請參閱第 1.4 節 「BlueStore」。

  • 我們建議為 WAL 裝置保留 4 GB。對於大多數工作負載而言，建議的 DB 大小為 64 GB。

    重要
    重要

    對於高負載部署，建議使用更大的 DB 磁碟區，特別是在 RGW 或 CephFS 使用率較高的情況下。如果需要，請保留一些容量 (槽) 來安裝更多硬體，以提供更大的 DB 空間。

  • 如果您打算將 WAL 和 DB 裝置置於同一磁碟，建議您為這兩個裝置使用一個分割區，而不是為每個裝置使用單獨的分割區。這樣，Ceph 便可以使用 DB 裝置來執行 WAL 操作。這對於磁碟空間的管理也會更有效，因為 Ceph 只會在需要時才會為 WAL 使用 DB 分割區。另一個好處是，WAL 分割區填滿的可能性很小，當該分割區未完全利用時，其空間並不會浪費，而是用於 DB 操作。

    若要與 WAL 共用 DB 裝置，請不要指定 WAL 裝置，而是僅指定 DB 裝置。

    如需指定 OSD 配置的詳細資訊，請參閱Book “操作和管理指南”, Chapter 13 “操作任務”, Section 13.4.3 “使用 DriveGroups 規格新增 OSD。”。

2.4.4 用於 WAL/DB 分割區的 SSD

 

固態硬碟 (SSD) 不包含移動部件。這可以減少隨機存取時間和讀取延遲，同時加快資料輸送量。由於 SSD 的每 MB 價格大大高於旋轉型硬碟，SSD 只適用於較小規模的儲存。

如果將 WAL/DB 分割區儲存在 SSD 上，並將物件資料儲存在獨立的硬碟上，OSD 的效能會得到大幅提高。

提示
提示：為多個 WAL/DB 分割區共用 SSD

由於 WAL/DB 分割區佔用的空間相對較少，因此可以多個 WAL/DB 分割區共用一個 SSD 磁碟。請注意，共用的 WAL/DB 分割區每多一個，SSD 磁碟的效能就會相應下降一分。不建議在同一個 SSD 磁碟中共用 6 個以上的 WAL/DB 分割區，或者在 NVMe 磁碟中共用 12 個以上的 WAL/DB 分割區。

2.4.5 磁碟的最大建議數量

 

您可以在一部伺服器上使用所允許的任意數量的磁碟。規劃每部伺服器的磁碟數量時，需要考慮以下幾點：

  • 網路頻寬：在一部伺服器中使用的磁碟越多，執行磁碟寫入操作時必須透過網路卡傳輸的資料就越多。

  • 記憶體：系統會將超過 2 GB 的 RAM 用於 BlueStore 快取。當 osd_memory_target 設為預設值 4 GB 時，該起始快取大小對於旋轉式媒體而言是比較合理的。如果使用 SSD 或 NVME，請考慮增加快取大小以及為每個 OSD 配置的 RAM，以便最大限度地提高效能。

  • 容錯：如果整部伺服器發生故障，則伺服器包含的磁碟越多，叢集暫時丟失的 OSD 就越多。此外，為了確保複製規則的執行，需要將發生故障伺服器中的所有資料複製到叢集中的其他節點。

2.5 監控程式節點

 

  • 至少需要三個 MON 節點。監控程式數量應永遠為奇數 (1+2n)。

  • 4 GB RAM。

  • 具有四個邏輯核心的處理器。

  • 強烈建議您為監控程式使用 SSD 或其他速度足夠快的儲存類型，特別是針對每個監控程式節點上的 /var/lib/ceph 路徑，因為最低核准人數可能不穩定且磁碟延遲較高。建議提供兩個採用 RAID 1 組態的磁碟來進行備援。建議為監控程式程序使用獨立的磁碟，或者至少是獨立的磁碟分割區，以防止記錄檔案增大等問題導致監控程式的可用磁碟空間不足。

  • 每個節點只能有一個監控程式程序。

  • 僅當有足夠的硬體資源可用時，才支援混用 OSD、MON 或物件閘道節點。這意味著，對於所有服務需提高相應要求。

  • 與多個交換器結合的兩個網路介面。

2.6 物件閘道節點

 

物件閘道節點至少應具有 6 個 CPU 核心和 32 GB RAM。如果將其他程序併置在同一部機器上，則需要提高相應要求。

2.7 中繼資料伺服器節點

 

中繼資料伺服器節點的適當大小取決於特定使用案例。一般而言，中繼資料伺服器需要處理的開啟檔案越多，所需要的 CPU 和 RAM 就越多。以下是最低要求：

  • 為每個中繼資料伺服器精靈指定 4 GB 的 RAM。

  • 結合網路介面。

  • 2.5 GHz CPU，至少具有兩個核心。

2.8 管理節點

 

至少需要 4 GB RAM 和四核 CPU。其中包括在管理節點上執行 Salt Master。對於包含數百個節點的大型叢集，建議提供 6 GB RAM。

2.9 iSCSI 閘道節點

 

iSCSI 閘道節點至少應具有 6 個 CPU 核心和 16 GB RAM。

2.10 SES 和其他 SUSE 產品

 

本節包含有關將 SES 與其他 SUSE 產品整合的重要資訊。

2.10.1 SUSE Manager

 

SUSE Manager 與 SUSE Enterprise Storage 未整合，因此 SUSE Manager 目前無法管理 SES 叢集。

2.11 名稱限制

 

一般情況下，Ceph 不支援在組態檔案、池名稱、使用者名稱等內容中使用非 ASCII 字元。設定 Ceph 叢集時，建議您在所有 Ceph 物件/組態名稱中僅使用簡單的英數字元 (A-Z、a-z、0-9) 和最少量的標點符號 (「.」、「-」、「_」)。

2.12 共用一部伺服器的 OSD 和監控程式

 

儘管從技術上講可以在測試環境中的同一部伺服器上執行 OSD 和 MON，但強烈建議您在生產環境中為每個監控程式節點使用獨立的伺服器。這樣做的主要原因在於效能 — 叢集包含的 OSD 越多，MON 節點需要執行的 I/O 操作就越多。另外，當 MON 節點與 OSD 之間共用一部伺服器時，OSD I/O 操作便將成為監控程式節點的限制因素。

另一個考慮因素是，是否要在 OSD、MON 節點與伺服器上的作業系統之間共用磁碟。答案非常簡單：如果可能，請將一個獨立的磁碟專門用於 OSD，並將一部獨立的伺服器用於監控程式節點。

儘管 Ceph 支援基於目錄的 OSD，但 OSD 應永遠具有一個專屬磁碟，而不能與作業系統共用一個磁碟。

提示
提示

如果確實有必要在同一部伺服器上執行 OSD 和 MON 節點，請將一個獨立磁碟掛接至 /var/lib/ceph/mon 目錄以在該磁碟上執行 MON，這樣可以稍微提升一些效能。

3 管理節點 HA 設定

 

管理節點是執行 Salt Master 服務的 Ceph 叢集節點。它負責管理叢集的其餘節點，它會查詢這些節點的 Salt Minion 服務並向其提供指示。它通常也會包含其他服務，例如 Grafana 儀表板 (由 Prometheus 監控工具套件提供支援)。

如果管理節點發生故障，通常需要為該節點提供新的工作硬體，並透過最近的備份還原完整的叢集組態堆疊。這種方法很費時，並會導致叢集故障。

為避免出現由於管理節點故障導致的 Ceph 叢集效能下降，建議您為 Ceph 管理節點使用高可用性 (HA) 叢集。

3.1 管理節點的 HA 叢集概述

 

HA 叢集的原理是，當其中一個叢集節點發生故障時，由另一個節點自動接管其職責，包括虛擬化管理節點。使用此方法時，其他 Ceph 叢集節點將不會知道管理節點發生故障。

管理節點的精簡 HA 解決方案需要以下硬體：

  • 兩部能夠執行具有高可用性延伸的 SUSE Linux Enterprise，以及虛擬化管理節點的裸機伺服器。

  • 兩個或多個備援網路通訊路徑，例如透過網路裝置結合。

  • 用於代管管理節點虛擬機器磁碟影像的共用儲存。必須能夠透過這兩部伺服器存取共用儲存。例如，共用儲存可以是 NFS 輸出、Samba 共用或 iSCSI 目標。

需叢集要求的更多詳細資料，請造訪 https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/art-sleha-install-quick.html#sec-ha-inst-quick-req。

管理節點的雙節點 HA 叢集
圖 3.1︰ 管理節點的雙節點 HA 叢集
 

3.2 構建具有管理節點的 HA 叢集

 

以下程序摘要了建構將管理節點虛擬化的 HA 叢集的幾個最重要步驟。如需詳細資料，請參閱指定連結。

  1. 設定一個具有共用儲存的基本雙節點 HA 叢集，如 https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/art-sleha-install-quick.html 中所述。

  2. 在兩個叢集節點上，安裝執行 KVM 監管程式和 libvirt 工具套件所需的所有套件，如 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-vt-installation.html#sec-vt-installation-kvm 中所述。

  3. 在第一個叢集節點上，使用 libvirt 建立新的 KVM 虛擬機器 (VM)，如 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-kvm-inst.html#sec-libvirt-inst-virt-install 中所述。使用預先設定的共用儲存來儲存虛擬機器的磁碟影像。

  4. 虛擬機器設定完成後，將其組態輸出至共用儲存上的 XML 檔案。使用以下語法： 

    root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

  5. 為管理節點虛擬機器建立資源。如需建立 HA 資源的一般資訊，請參閱 https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/cha-conf-hawk2.html。http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29 中提供了有關為 KVM 虛擬機器建立資源的詳細資訊。

  6. 在新建立的虛擬機器客體中，部署管理節點，包括您需要在其上使用的其他服務。執行第 5.2 節 「部署 Salt」中的相關步驟。同時，在非 HA 叢集伺服器上部署其餘 Ceph 叢集節點。

第 II 部分 部署 Ceph 叢集

 
  • 4 簡介和常見任務

    • 自 SUSE Enterprise Storage 7 起，使用 cephadm (而不是 RPM 套件) 做為容器部署 Ceph 服務。如需更多詳細資料，請參閱第 5 章 「使用 cephadm 進行部署」。

  • 5 使用 cephadm 進行部署

    • SUSE Enterprise Storage 7 使用基於 Salt 的 ceph-salt 工具在每個參與叢集節點上準備作業系統，以透過 cephadm 進行部署。cephadm 透過 SSH 從 Ceph 管理員精靈連接至主機，以部署和管理 Ceph 叢集。cephadm 管理 Ceph 叢集的整個生命週期。它會首先在單個節點 (一個 MON 和 MGR 服務) 上將一個小型叢集開機，然後使用協調程序介面擴充叢集，以包含所有主機並佈建所有 Ceph 服務。您可以透過 Ceph 指令行介面 (CLI) 或部分透過 Ceph Dashboard (GUI) 執行此操作。

4 簡介和常見任務

 

自 SUSE Enterprise Storage 7 起，使用 cephadm (而不是 RPM 套件) 做為容器部署 Ceph 服務。如需更多詳細資料，請參閱第 5 章 「使用 cephadm 進行部署」。

4.1 閱讀版本說明

 

在版本說明中，您可以找到其他有關自 SUSE Enterprise Storage 的上一個版本發行後所進行的變更的資訊。檢查版本說明以瞭解：

  • 您的硬體是否有特殊注意事項。

  • 所用的任何軟體套件是否已發生重大變更。

  • 是否需要對您的安裝施行特殊預防措施。

版本說明還會提供無法及時編入手冊的資訊。它們還包含有關已知問題的說明。

安裝套件 release-notes-ses之後，本地的 /usr/share/doc/release-notes 目錄中或 https://www.suse.com/releasenotes/ 網頁上會提供版本說明。

5 使用 cephadm 進行部署

 

SUSE Enterprise Storage 7 使用基於 Salt 的 ceph-salt 工具在每個參與叢集節點上準備作業系統，以透過 cephadm 進行部署。cephadm 透過 SSH 從 Ceph 管理員精靈連接至主機，以部署和管理 Ceph 叢集。cephadm 管理 Ceph 叢集的整個生命週期。它會首先在單個節點 (一個 MON 和 MGR 服務) 上將一個小型叢集開機，然後使用協調程序介面擴充叢集，以包含所有主機並佈建所有 Ceph 服務。您可以透過 Ceph 指令行介面 (CLI) 或部分透過 Ceph Dashboard (GUI) 執行此操作。

重要
重要

請注意，在初始部署期間，Ceph 社群文件使用 cephadm bootstrap 指令。ceph-salt 會呼叫 cephadm bootstrap 指令，不應直接執行該指令。不支援使用 cephadm bootstrap 進行任何手動 Ceph 叢集部署。

若要使用 cephadm 部署 Ceph 叢集，需要完成以下任務：

  1. 在所有叢集節點上安裝 SUSE Linux Enterprise Server 15 SP2 並執行基礎作業系統的基本組態。

  2. 在所有叢集節點上部署 Salt 基礎架構，以便透過 ceph-salt 執行初始部署準備。

  3. 透過 ceph-salt 設定叢集的基本內容並進行部署。

  4. 為叢集新增新的節點和角色，並使用 cephadm 為其部署服務。

5.1 安裝和設定 SUSE Linux Enterprise Server

 

  1. 在每個叢集節點上安裝並註冊 SUSE Linux Enterprise Server 15 SP2。在安裝 SUSE Enterprise Storage 期間，需要存取更新儲存庫，因此必須註冊。至少包含以下模組：

    • Basesystem 模組

    • Server Applications Module

    如需如何安裝 SUSE Linux Enterprise Server 的更多詳細資料，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html。

  2. 在每個叢集節點上安裝 SUSE Enterprise Storage 7 延伸。

    提示
    提示：將 SUSE Enterprise Storage 與 SUSE Linux Enterprise Server 一併安裝

    您可以在安裝 SUSE Linux Enterprise Server 15 SP2 之後單獨安裝 SUSE Enterprise Storage 7 延伸，也可以在 SUSE Linux Enterprise Server 15 SP2 安裝程序期間新增該延伸。

    如需如何安裝延伸的更多詳細資料，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html。

  3. 在每個節點上設定網路設定，包括正確的 DNS 名稱解析。如需設定網路的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast。如需設定 DNS 伺服器的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html。

5.2 部署 Salt

 

SUSE Enterprise Storage 使用 Salt 和 ceph-salt 進行初始叢集準備。Salt 可協助您從一個名為 Salt Master 的專屬主機同時針對多個叢集節點設定和執行指令。在部署 Salt 之前，請考慮以下重要事項：

  • Salt Minion 是由一個名為 Salt Master 的專屬節點控制的節點。

  • 如果 Salt Master 主機應屬於 Ceph 叢集的一部分，則它需要執行自己的 Salt Minion，但這不是必須的。

    提示
    提示：每部伺服器共用多個角色

    如果將每個角色都部署在一個獨立節點上，則 Ceph 叢集的效能是最佳的。但實際部署有時會要求多個角色共用一個節點。為避免效能欠佳以及升級程序出現問題，請勿向管理節點部署 Ceph OSD、中繼資料伺服器或 Ceph 監控程式角色。

  • Salt Minion 需要能透過網路正確解析 Salt Master 的主機名稱。依預設，Minion 會尋找 salt 主機名稱，但您可以在 /etc/salt/minion 檔案中指定可透過網路連接的其他任何主機名稱。

  1. 在 Salt Master 節點上安裝 salt-master： 

    root@master # zypper in salt-master

  2. 檢查 salt-master 服務是否已啟用並啟動，並視需要進行啟用和啟動： 

    root@master # systemctl enable salt-master.service
root@master # systemctl start salt-master.service

  3. 如果您要使用防火牆，請確認 Salt Master 節點是否為所有 Salt Minion 節點開啟了連接埠 4505 和 4506。如果這些連接埠處於關閉狀態，您可以使用 yast2 firewall 指令並透過允許相應區域的 salt-master 服務來開啟這些連接埠。例如，public。

  4. 在所有 Minion 節點上安裝 salt-minion 套件。 

    root@minion > zypper in salt-minion

  5. 編輯 /etc/salt/minion 並取消註解下行： 

    #log_level_logfile: warning

    將 warning 記錄層級變更為 info。

    注意
    注意：log_level_logfile 和 log_level

    log_level 用於控制螢幕上將顯示的記錄訊息，而 log_level_logfile 用於控制哪些記錄訊息將寫入到 /var/log/salt/minion。

    注意
    注意

    請務必變更所有叢集 (Minion) 節點上的記錄層級。

  6. 確定所有其他節點都可以將每個節點的完全合格網域名稱解析為公用叢集網路上的 IP 位址。

  7. 將所有 Minion 設定為連接至 Master。如果無法透過主機名稱 salt 連接 Salt Master，請編輯檔案 /etc/salt/minion，或建立包含以下內容的新檔案 /etc/salt/minion.d/master.conf： 

    master: host_name_of_salt_master

    如果對上述組態檔案執行了任何變更，請在所有相關的 Salt Minion 上重新啟動 Salt 服務： 

    root@minion > systemctl restart salt-minion.service

  8. 檢查所有節點上是否已啟用並啟動 salt-minion 服務。依據需要啟用並啟動該服務： 

    root # systemctl enable salt-minion.service
root # systemctl start salt-minion.service

  9. 確認每個 Salt Minion 的指紋，如果指紋相符，則接受 Salt Master 上的所有 Salt 金鑰。

    注意
    注意

    如果 Salt Minion 指紋傳回空白，請確定 Salt Minion 具有 Salt Master 組態且可與 Salt Master 通訊。

    檢視每個 Minion 的指紋： 

    root@minion > salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    收集到所有 Salt Minion 的指紋後，將列出 Salt Master 上所有未接受 Minion 金鑰的指紋： 

    root@master # salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    如果 Minion 的指紋相符，則接受這些金鑰： 

    root@master # salt-key --accept-all

  10. 驗證是否已接受金鑰： 

    root@master # salt-key --list-all

  11. 測試是否所有 Salt Minion 都回應： 

    root@master # salt-run manage.status

5.3 部署 Ceph 叢集

 

本節將引導您完成部署基本 Ceph 叢集的程序。請仔細閱讀下面的小節，並依給定的順序執行所包含的指令。

5.3.1 安裝 ceph-salt

 

ceph-salt 提供了用於部署由 cephadm 管理的 Ceph 叢集的工具。ceph-salt 使用 Salt 基礎架構來執行作業系統管理 (例如，軟體更新或時間同步)，並為 Salt Minion 定義角色。

在 Salt Master 上，安裝 ceph-salt 套件： 

root@master # zypper install ceph-salt

以上指令將做為相依項安裝 ceph-salt-formula ，它透過在 /etc/salt/master.d 目錄中插入額外檔案來修改 Salt Master 組態。若要套用變更，請重新啟動 salt-master.service 並同步 Salt 模組： 

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

5.3.2 設定叢集內容

 

使用 ceph-salt config 指令可設定叢集的基本內容。

重要
重要

/etc/ceph/ceph.conf 檔案由 cephadm 管理，使用者不得編輯該檔案。應使用新的 ceph config 指令設定 Ceph 組態參數。如需詳細資訊，請參閱Book “操作和管理指南”, Chapter 28 “Ceph 叢集組態”, Section 28.2 “組態資料庫”。

5.3.2.1 使用 ceph-salt 外圍程序

 

如果在不附帶任何路徑或子指令的情況下執行 ceph-salt config，您將進入互動 ceph-salt 外圍程序。如果您需要在一個批次中設定多個內容，並且不想輸入完整的指令語法，使用外圍程序會非常方便。 

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

從 ceph-salt 的 ls 指令輸出中您會看到，叢集組態以樹狀結構組織。若要在 ceph-salt 外圍程序中設定叢集的特定內容，可使用以下兩個選項：

  • 從目前位置執行指令，並輸入內容的絕對路徑做為第一個引數： 

    /> /cephadm_bootstrap/dashboard ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username .................................................... [admin]
/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.

  • 變更為需要設定的內容的路徑，並執行指令： 

    /> cd /cephadm_bootstrap/dashboard/
/ceph_cluster/minions> ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username ................................................[ceph-admin]
提示
提示：自動完成組態程式碼片段

在 ceph-salt 外圍程序中，您可以使用類似於一般 Linux 外圍程序 (Bash) 自動完成的自動完成功能。它可以完成組態路徑、子指令或 Salt Minion 名稱。自動完成組態路徑時，可使用以下兩個選項：

  • 若要讓外圍程序完成您目前位置的相對路徑，請按 TAB 鍵 →| 兩次。

  • 若要讓外圍程序完成絕對路徑，請輸入 / 並按 TAB 鍵 →| 兩次。

提示
提示：使用游標鍵導覽

如果從 ceph-salt 外圍程序輸入 cd 而不附帶任何路徑，則該指令將列印叢集組態的樹狀結構，其中目前路徑對應的行處於使用中狀態。您可以使用向上和向下游標鍵在各行之間導覽。按一下 Enter 進行確認後，組態路徑將變更為最後一個使用中路徑。

重要
重要：基本規則

為了保持文件的一致性，我們將使用單一指令語法，而不輸入 ceph-salt 外圍程序。例如，您可以使用以下指令列出叢集組態樹： 

root@master # ceph-salt config ls

5.3.2.2 新增 Salt Minion

 

將我們在第 5.2 節 「部署 Salt」中部署並接受的所有或部分 Salt Minion 包含到 Ceph 叢集組態中。您可以透過其全名指定 Salt Minion，也可以使用 glob 運算式「*」和「？」一次包含多個 Salt Minion。在 /ceph_cluster/minions 路徑下使用 add 子指令。以下指令包含所有已接受的 Salt Minion： 

root@master # ceph-salt config /ceph_cluster/minions add '*'

確認是否新增了指定的 Salt Minion： 

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

5.3.2.3 指定由 cephadm 管理的 Salt Minion

 

指定哪些節點將屬於 Ceph 叢集並由 cephadm 管理。包含將執行 Ceph 服務的所有節點以及管理節點： 

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

5.3.2.4 指定管理節點

 

管理節點是安裝 ceph.conf 組態檔案和 Ceph 管理金鑰圈的節點。您通常會在管理節點上執行與 Ceph 相關的指令。

提示
提示：Salt Master 和管理節點位於同一節點

在所有或大多數主機都屬於 SUSE Enterprise Storage 的同質環境中，建議您將管理節點與 Salt Master 置於同一主機。

而對於一個 Salt 基礎架構代管多個叢集 (例如 SUSE Enterprise Storage 和 SUSE Manager) 的異質環境，請勿將管理節點與 Salt Master 置於同一主機。

若要指定管理節點，請執行以下指令： 

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]
提示
提示：在多個節點上安裝 ceph.conf 和管理金鑰圈

如果是部署所需，您可以在多個節點上安裝 Ceph 組態檔案和管理金鑰圈。出於安全原因，請避免將其安裝在叢集的所有節點上。

5.3.2.5 指定第一個 MON/MGR 節點

 

您需要指定將叢集開機的叢集 Salt Minion。此 Minion 將成為第一個執行 Ceph 監控程式和 Ceph 管理員服務的 Minion。 

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

此外，您還需要在公用網路上指定開機 MON 的 IP 位址，以確定 public_network 參數設定正確，例如： 

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

5.3.2.6 指定調整的設定檔

 

您需要指定叢集的哪些 Minion 具有主動調整的設定檔。為此，請使用以下指令明確新增這些角色：

注意
注意

一個 Minion 不能同時擁有 latency 和 throughput 角色。 

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

5.3.2.7 產生 SSH 金鑰組

 

cephadm 使用 SSH 通訊協定與叢集節點通訊。將自動建立名為 cephadm 的使用者帳戶並用於 SSH 通訊。

您需要產生 SSH 金鑰組的私人和公用部分： 

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

5.3.2.8 設定時間伺服器

 

所有叢集節點都需要與可靠的時間來源進行時間同步。有以下幾種方案可以實現時間同步：

  • 如果所有叢集節點都已設定為使用所選 NTP 服務同步其時間，請完全停用時間伺服器處理： 

    root@master # ceph-salt config /time_server disable

  • 如果您的站台已有單一時間來源，請指定時間來源的主機名稱： 

     root@master # ceph-salt config /time_server/servers add time-server.example.com

  • 另外，ceph-salt 可以設定一個 Salt Minion 來充當叢集其餘 Minion 的時間伺服器。有時，它被稱為「內部時間伺服器」。在此方案中，ceph-salt 將設定內部時間伺服器 (應為其中一個 Salt Minion) 以使其時間與外部時間伺服器 (例如 pool.ntp.org) 同步，並將所有其他 Minion 設定為從內部時間伺服器獲取時間。可透過以下指令來實現： 

    root@master # ceph-salt config /time_server/servers add ses-master.example.com
root@master # ceph-salt config /time_server/external_servers add pool.ntp.org

    /time_server/subnet 選項指定允許 NTP 用戶端透過其存取 NTP 伺服器的子網路。當您指定 /time_server/servers 時，會自動設定該選項。如果需要變更該選項或手動指定，請執行： 

    root@master # ceph-salt config /time_server/subnet set 10.20.6.0/24

檢查時間伺服器設定： 

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

如需設定時間同步的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast。

5.3.2.9 設定 Ceph Dashboard 登入身分證明

 

部署基本叢集後便可使用 Ceph Dashboard。若要存取 Ceph Dashboard，您需要設定有效的使用者名稱和密碼，例如： 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD
提示
提示：強制密碼更新

依預設，系統將強制第一位儀表板使用者在首次登入儀表板時變更其密碼。若要停用此功能，請執行以下指令： 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

5.3.2.10 設定容器影像的路徑

 

cephadm 需要知道將在部署步驟中使用的容器影像的有效 URI 路徑。確認是否設定了預設路徑： 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

如果未設定預設路徑或者您的部署需要特定路徑，請使用以下指令新增該路徑： 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph
注意
注意

對於監控堆疊，需要更多的容器影像。對於實體隔離部署以及從本地登錄的部署，此時您可能想要獲取這些影像，以便相應地準備您的本地登錄。

請注意，ceph-salt 不會將這些容器影像用於部署。而只是為後面的步驟做準備，在後面的步驟中將使用 cephadm 來部署或移轉監控元件。

如需有關監控堆疊所使用的影像以及如何自訂這些影像的詳細資訊，請瀏覽Book “操作和管理指南”, Chapter 16 “監控和警示”, Section 16.1 “設定自訂或本地影像”頁面。

5.3.2.11 設定容器登錄

 

(選擇性) 您可以設定本地容器登錄。它將充當 registry.suse.com 登錄的鏡像。請記住，每當 registry.suse.com 中提供了新的更新容器，就需要重新同步本地登錄。

在以下情況下，建立本地登錄非常有用：

  • 您有許多叢集節點，希望透過建立容器影像的本地鏡像來節省下載時間和頻寬。

  • 您的叢集無法存取線上登錄 (實體隔離部署)，您需要一個本地鏡像來從中提取容器影像。

  • 如果因組態或網路問題而阻止您的叢集透過安全連結存取遠端登錄，則您需要一個本地的未加密登錄。

重要
重要

若要在支援的系統上部署程式暫時修復 (PTF)，您需要部署本地容器登錄。

若要設定本地登錄 URL 以及存取身分證明，請執行以下操作：

  1. 設定本地登錄的 URL： 

    cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_URL

  2. 設定使用者名稱和密碼以存取本地登錄： 

    cephuser@adm > ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAME
    cephuser@adm > ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORD

  3. 執行 ceph-salt apply 以更新所有 Minion 上的 Salt pillar。

提示
提示：登錄快取

若要避免在出現新的更新容器時重新同步本地登錄，您可以設定登錄快取。

雲端原生應用程式開發和傳遞方法需要一個登錄和一個 CI/CD (連續整合/傳遞) 例項來開發和生產容器影像。在此例項中，您可以使用私人登錄。

5.3.2.12 啟用資料傳輸中加密 (msgr2)

 

Messenger v2 通訊協定 (MSGR2) 是 Ceph 的線上傳輸通訊協定。它提供了一種可對正在透過網路傳輸的所有資料進行加密的安全模式，封裝了驗證封包內容，並支援未來整合新的驗證模式 (例如 Kerberos)。

重要
重要

Linux 核心 Ceph 用戶端 (例如 CephFS 和 RADOS 區塊裝置) 目前不支援 msgr2。

Ceph 精靈可以結合到多個連接埠，以便讓舊 Ceph 用戶端和支援 v2 的新用戶端能夠連接至同一叢集。依預設，針對新的 v2 通訊協定，MON 現在會結合到 IANA 指定的新連接埠 3300 (CE4h 或 0xCE4)，而針對舊版 v1 通訊協定，則會結合到舊的預設連接埠 6789。

v2 通訊協定 (MSGR2) 支援以下兩種連接模式：

crc 模式

建立連接時進行強初始驗證和 CRC32C 完整性檢查。

secure 模式

建立連接時進行強初始驗證，並對所有驗證後流量進行完全加密，包括加密完整性檢查。

對於大多數連接，有一些選項可以控制使用哪種模式：

ms_cluster_mode

用於 Ceph 精靈之間的叢集內通訊的連接模式 (或允許的模式)。如果列出了多種模式，則偏好最先列出的模式。

ms_service_mode

連接至叢集時允許用戶端使用的模式清單。

ms_client_mode

與 Ceph 叢集通訊時，供用戶端使用 (或允許) 的連接模式清單，依偏好設定排序。

有一組專用於監控程式的平行選項集，可讓管理員設定與監控程式通訊的不同 (通常更安全) 要求。

ms_mon_cluster_mode

在監控程式之間使用的連接模式 (或允許的模式)。

ms_mon_service_mode

連接至監控程式時，供用戶端或其他 Ceph 精靈使用的允許模式清單。

ms_mon_client_mode

連接至監控程式時，供用戶端或非監控程式精靈使用的連接模式的清單，依偏好設定排序。

若要在部署期間啟用 MSGR2 加密模式，您需要在執行 ceph-salt apply 之前向 ceph-salt 組態新增一些組態選項。

若要使用 secure 模式，請執行以下指令。

向 ceph-salt 組態工具中的 ceph_conf 新增全域區段。 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

設定下列選項： 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"
注意
注意

確定 secure 先於 crc。

若要強制使用 secure 模式，請執行以下指令： 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure
提示
提示：更新設定

如果您要變更上述任何設定，請在監控程式組態儲存中設定組態變更。可使用 ceph config set 指令實現。 

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

例如： 

root@master # ceph config set global ms_cluster_mode "secure crc"

如果要檢查目前值 (包括預設值)，請執行以下指令： 

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

例如，若要獲取 OSD 的 ms_cluster_mode，請執行： 

root@master # ceph config get osd ms_cluster_mode

5.3.2.13 設定叢集網路

 

(選擇性) 如果執行的是獨立的叢集網路，則可能需要設定叢集網路 IP 位址並後接斜線符號及子網路遮罩部分，例如 192.168.10.22/24。

執行以下指令可啟用 cluster_network： 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

5.3.2.14 確認叢集組態

 

最低叢集組態已完成。請檢查是否存在明顯錯誤： 

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]
提示
提示：叢集組態的狀態

您可以透過執行以下指令檢查叢集的組態是否有效： 

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

5.3.2.15 輸出叢集組態

 

在設定了基本叢集並且確認其組態有效之後，最好將其組態輸出至檔案中： 

root@master # ceph-salt export > cluster.json
警告
警告

ceph-salt export 的輸出中包含 SSH 私密金鑰。如果您擔心安全問題，請不要在未採取適當預防措施的情況下執行此指令。

如果叢集組態損毀並需要復原到備份狀態，請執行： 

root@master # ceph-salt import cluster.json

5.3.3 更新節點並將最小叢集開機

 

部署叢集之前，請更新所有節點上的所有軟體套件： 

root@master # ceph-salt update

如果節點在更新期間報告 Reboot is needed，則表示重要的作業系統套件 (例如核心) 已更新至更新版本，您需要將節點重新開機才能套用變更。

若要將所有需要重新開機的節點重新開機，請附加 --reboot 選項 

root@master # ceph-salt update --reboot

或者在單獨的步驟中將這些節點重新開機： 

root@master # ceph-salt reboot
重要
重要

永遠不會透過 ceph-salt update --reboot 或 ceph-salt reboot 指令將 Salt Master 重新開機。如果 Salt Master 需要重新開機，您需要手動進行重新開機。

更新節點後，請將最小叢集開機： 

root@master # ceph-salt apply
注意
注意

開機完成後，叢集將擁有一個 Ceph 監控程式和一個 Ceph 管理員。

以上指令將開啟一個互動使用者介面，其中會顯示每個 Minion 的目前進度。

部署最小叢集
圖 5.1︰ 部署最小叢集
 
提示
提示：非互動模式

如果您需要從程序檔套用組態，還有一種非互動的部署模式。此模式在從遠端機器部署叢集時也很有用，因為透過網路不斷更新螢幕上的進度資訊可能會對使用者造成干擾： 

root@master # ceph-salt apply --non-interactive

5.3.4 檢視最後的步驟

 

在 ceph-salt apply 指令完成後，您便應該會擁有一個 Ceph 監控程式和一個 Ceph 管理員。您應該能夠在任何以 root 身分或使用 sudo 的 cephadm 使用者身分被授予 admin 角色的 Minion 上成功執行 ceph status 指令。

後續步驟包括使用 cephadm 部署額外的 Ceph 監控程式、Ceph 管理員、OSD、監控堆疊和閘道。

繼續之前，請檢視新叢集的網路設定。此時，已依據在 ceph-salt 組態中針對 /cephadm_bootstrap/mon_ip 輸入的值填入了 public_network 設定。不過，此設定僅適用於 Ceph 監控程式。您可以使用以下指令檢視此設定： 

root@master # ceph config get mon public_network

這是 Ceph 正常工作所需的最低設定，但還是建議您將此 public_network 設定為 global，這表示它將套用於所有類型的 Ceph 精靈，而不僅套用於 MON： 

root@master # ceph config set global public_network "$(ceph config get mon public_network)"
注意
注意

此步驟不是必需的。但如果不使用此設定，Ceph OSD 和其他精靈 (Ceph 監控程式除外) 將監聽所有位址。

如果您希望在各 OSD 之間使用完全獨立的網路進行通訊，請執行以下指令： 

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

執行此指令將確保您部署中所建立的 OSD 從一開始就使用預期的叢集網路。

如果您的叢集設定為具有密集節點 (每個主機有超過 62 個 OSD)，請確保為 Ceph OSD 指定足夠的連接埠。預設範圍 (6800-7300) 目前允許每個主機有不超過 62 個 OSD。對於具有密集節點的叢集，請將設定 ms_bind_port_max 調整到適當的值。每個 OSD 將使用 8 個額外的連接埠。例如，如果一部主機設定為執行 96 個 OSD，則需要 768 個連接埠。透過執行以下指令，應將 ms_bind_port_max 至少設定為 7568： 

root@master # ceph config set osd.* ms_bind_port_max 7568

您需要相應地調整防火牆設定才能使其正常工作。如需詳細資訊，請參閱Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”。

5.4 部署服務和閘道

 

部署基本 Ceph 叢集之後，請將核心服務部署到更多叢集節點。為使用戶端能夠存取叢集資料，還需要部署額外的服務。

目前，我們支援使用 Ceph orchestrator (ceph orch 子指令) 在指令行上部署 Ceph 服務。

5.4.1 ceph orch 指令

 

Ceph orchestrator 指令 ceph orch 是 cephadm 模組的介面，它負責列出叢集元件並在新的叢集節點上部署 Ceph 服務。

5.4.1.1 顯示 orchestrator 狀態

 

以下指令會顯示目前模式和 Ceph orchestrator 的狀態。 

cephuser@adm > ceph orch status

5.4.1.2 列出裝置、服務和精靈

 

若要列出所有磁碟裝置，請執行以下指令： 

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]
提示
提示：服務和精靈

服務是表示特定類型的 Ceph 服務的一般術語，例如 Ceph 管理員。

精靈表示服務的特定例項，例如在名為 ses-min1 的節點上執行的程序 mgr.ses-min1.gdlcik。

若要列出 cephadm 已知的所有服務，請執行： 

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
提示
提示

您可以使用選擇性的 -–host 參數將清單限制為某個特定節點上的服務，也可使用選擇性的 --service-type 參數 (可接受的類型包括 mon、osd、mgr、mds 和 rgw) 將清單限制為某種特定類型的服務。

若要列出由 cephadm 部署的所有執行中精靈，請執行： 

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369
提示
提示

若要查詢某個特定精靈的狀態，請使用 --daemon_type 和 --daemon_id。對於 OSD，ID 為數字 OSD ID。對於 MDS，ID 為檔案系統名稱： 

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

5.4.2 服務和放置規格

 

指定 Ceph 服務部署的推薦方法是建立一個 YAML 格式的檔案，其中包含所要部署服務的規格。

5.4.2.1 建立服務規格

 

您可以為每種類型的服務建立單獨的規格檔案，例如： 

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

或者，您可以在一個描述哪些節點將執行特定服務的檔案 (例如 cluster.yml) 中指定多個 (或所有) 服務類型。請記得使用三個破折號 (---) 分隔各個服務類型： 

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

上述內容的含義如下：

service_type

服務的類型。它可以是 Ceph 服務 (mon、mgr、mds、crash、osd 或 rbd-mirror)、閘道 (nfs 或 rgw) 或部分監控堆疊 (alertmanager、grafana、node-exporter 或 prometheus)。

service_id

服務的名稱。mon、mgr、alertmanager、grafana、node-exporter 和 prometheus 類型的規格不需要 service_id 內容。

placement

指定哪些節點將執行服務。如需更多詳細資料，請參閱第 5.4.2.2 節 「建立放置規格」。

spec

與服務類型相關的其他規格。

提示
提示：套用特定服務

Ceph 叢集服務通常具有許多專屬內容。如需各個服務規格的範例和詳細資料，請參閱第 5.4.3 節 「部署 Ceph 服務」。

5.4.2.2 建立放置規格

 

若要部署 Ceph 服務，cephadm 需要知道要在其上部署這些服務的節點。請使用 placement 內容並列出要套用服務的節點的主機簡短名稱： 

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

5.4.2.3 套用叢集規格

 

建立包含所有服務及其放置的規格的完整 cluster.yml 檔案後，您便可透過執行以下指令來套用叢集： 

cephuser@adm > ceph orch apply -i cluster.yml

若要檢視叢集的狀態，請執行 ceph orch status 指令。如需詳細資訊，請參閱第 5.4.1.1 節 「顯示 orchestrator 狀態」。

5.4.2.4 輸出執行中叢集的規格

 

雖然您使用第 5.4.2 節 「服務和放置規格」中所述的規格檔案將服務部署到 Ceph 叢集，但在實際操作期間，叢集的組態可能會偏離原始規格。另外，您也可能會無意間移除規格檔案。

若要擷取執行中叢集的完整規格，請執行： 

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]
提示
提示

您可以附加 --format 選項以變更預設的 yaml 輸出格式。您可以從 json、json-pretty 或 yaml 中進行選取。例如： 

ceph orch ls --export --format json

5.4.3 部署 Ceph 服務

 

在執行基本叢集之後，您可以將 Ceph 服務部署到其他節點。

5.4.3.1 部署 Ceph 監控程式和 Ceph 管理員

 

Ceph 叢集的不同節點之間部署了三個或五個 MON。如果叢集中有五個或更多節點，則建議部署五個 MON。好的做法是，將 MGR 部署在與 MON 相同的節點上。

重要
重要：包含開機 MON

在部署 MON 和 MGR 時，請記得包含在第 5.3.2.5 節 「指定第一個 MON/MGR 節點」中設定基本叢集時新增的第一個 MON。

若要部署 MON，請套用以下規格： 

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
注意
注意

如果需要新增另一個節點，請在同一 YAML 清單中附加主機名稱。例如： 

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

同樣，若要部署 MGR，請套用以下規格：

重要
重要

確定您的部署在每個部署中至少具有三個 Ceph 管理員。 

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
提示
提示

如果 MON 或 MGR 不在同一子網路中，則需要附加子網路位址。例如： 

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

5.4.3.2 部署 Ceph OSD

 
重要
重要：當儲存裝置可用時

如果滿足以下所有條件，則儲存裝置將被視為可用：

  • 裝置沒有分割區。

  • 裝置沒有任何 LVM 狀態。

  • 裝置未掛接。

  • 裝置不包含檔案系統。

  • 裝置不包含 BlueStore OSD。

  • 裝置大於 5 GB。

如果不滿足上述條件，Ceph 將拒絕佈建此類 OSD。

可以使用以下兩種方式來部署 OSD：

  • 告知 Ceph 使用所有可用和未使用的儲存裝置： 

    cephuser@adm > ceph orch apply osd --all-available-devices

  • 使用 DriveGroups (參閱Book “操作和管理指南”, Chapter 13 “操作任務”, Section 13.4.3 “使用 DriveGroups 規格新增 OSD。”) 建立 OSD 規格，該規格描述了將依據裝置內容 (例如裝置類型 (SSD 或 HDD)、裝置型號名稱、大小或裝置所在的節點) 部署的裝置。然後透過執行以下指令套用規格： 

    cephuser@adm > ceph orch apply osd -i drive_groups.yml

5.4.3.3 部署中繼資料伺服器

 

CephFS 需要一或多個中繼資料伺服器 (MDS) 服務。若要建立 CephFS，首先要透過套用以下規格來建立 MDS 伺服器：

注意
注意

在套用以下規格之前，請確定至少建立了兩個池，一個用於儲存 CephFS 資料，另一個用於儲存 CephFS 中繼資料。 

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

MDS 正常執行後，建立 CephFS： 

ceph fs new CEPHFS_NAME metadata_pool data_pool

5.4.3.4 部署物件閘道

 

cephadm 會將物件閘道部署為管理特定領域和區域的精靈的集合。

您可以將物件閘道服務與現有的領域和區域相關聯 (如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 21 “Ceph 物件閘道”, Section 21.13 “多站台物件閘道”)，也可以指定不存在的 REALM_NAME 和 ZONE_NAME，套用以下組態後會自動建立相應領域和區域： 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
5.4.3.4.1 使用安全 SSL 存取
 

若要使用連接至物件閘道的安全 SSL 連接，您需要一組有效的 SSL 證書和金鑰檔案 (如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 21 “Ceph 物件閘道”, Section 21.7 “為物件閘道啟用 HTTPS/SSL”)。您需要啟用 SSL，指定 SSL 連接的連接埠號碼以及 SSL 證書和金鑰檔案。

若要啟用 SSL 並指定連接埠號碼，請在規格中包含以下內容： 

spec:
  ssl: true
  rgw_frontend_port: 443

若要指定 SSL 證書和金鑰，可以將其內容直接貼至 YAML 規格檔案中。行末的縱線符號 (|) 告知剖析程式預期的值為多行字串。例如： 

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----
提示
提示

您可以省略 rgw_frontend_ssl_certificate: 和 rgw_frontend_ssl_key: 關鍵字，並將它們上傳到組態資料庫，而不是粘貼 SSL 證書和金鑰檔案的內容： 

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE
5.4.3.4.2 使用子叢集部署
 

子叢集可協助您組織叢集中的節點，以隔離工作負載，讓彈性縮放更輕鬆。如果使用子叢集進行部署，請套用以下組態： 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

5.4.3.5 部署 iSCSI 閘道

 

cephadm 可部署 iSCSI 閘道，它是一種儲存區域網路 (SAN) 通訊協定，可讓用戶端 (稱為啟動器) 將 SCSI 指令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。

套用以下組態進行部署。確定 trusted_ip_list 包含所有 iSCSI 閘道和 Ceph 管理員節點的 IP 位址 (請參閱下面的輸出範例)。

注意
注意

請確定在套用以下規格之前建立池。 

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
注意
注意

請確定針對 trusted_ip_list 列出的 IP 在逗號分隔後沒有空白。

5.4.3.5.1 安全 SSL 組態
 

若要在 Ceph Dashboard 和 iSCSI 目標 API 之間使用安全 SSL 連接，您需要一組有效的 SSL 證書和金鑰檔案。它們可以是 CA 核發的，也可以是自行簽署的 (參閱Book “操作和管理指南”, Chapter 10 “手動設定”, Section 10.1.1 “建立自行簽署的證書”)。若要啟用 SSL，請在您的規格檔案中包含 api_secure: true 設定： 

spec:
  api_secure: true

若要指定 SSL 證書和金鑰，可以將其內容直接貼至 YAML 規格檔案中。行末的縱線符號 (|) 告知剖析程式預期的值為多行字串。例如： 

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

5.4.3.6 部署 NFS Ganesha

 

cephadm 可使用預先定義的 RADOS 池和選擇性的名稱空間來部署 NFS Ganesha。若要部署 NFS Ganesha，請套用以下規格：

注意
注意

您需要有一個預先定義的 RADOS 池，否則 ceph orch apply 操作將失敗。如需建立池的詳細資訊，請參閱Book “操作和管理指南”, Chapter 18 “管理儲存池”, Section 18.1 “建立池”。 

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

  • EXAMPLE_NFS，包含用於識別 NFS 輸出項的任意字串。

  • EXAMPLE_POOL，包含將要儲存 NFS Ganesha RADOS 組態物件的池的名稱。

  • EXAMPLE_NAMESPACE (選擇性)，包含所需的物件閘道 NFS 名稱空間 (例如，ganesha)。

5.4.3.7 部署 rbd-mirror

 

rbd-mirror 服務負責在兩個 Ceph 叢集之間同步 RADOS 區塊裝置影像 (如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 20 “RADOS 區塊裝置”, Section 20.4 “RBD 影像鏡像”)。若要部署 rbd-mirror，請使用以下規格： 

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

5.4.3.8 部署監控堆疊

 

監控堆疊包含 Prometheus、Prometheus 輸出程式、Prometheus 警示管理員和 Grafana。Ceph Dashboard 使用這些元件來儲存並直觀呈現有關叢集使用率和效能的詳細度量。

提示
提示

如果您的部署需要監控堆疊服務的自訂或本地提供的容器影像，請參閱Book “操作和管理指南”, Chapter 16 “監控和警示”, Section 16.1 “設定自訂或本地影像”。

若要部署監控堆疊，請執行以下步驟：

  1. 在 Ceph 管理員精靈中啟用 prometheus 模組。這將公開內部 Ceph 度量，以便 Prometheus 可以讀取這些資訊： 

    cephuser@adm > ceph mgr module enable prometheus
    注意
    注意

    請確定在部署 Prometheus 之前執行此指令。如果部署前未執行該指令，則必須重新部署 Prometheus 才能更新 Prometheus 的組態： 

    cephuser@adm > ceph orch redeploy prometheus

  2. 建立包含如下內容的規格檔案 (例如 monitoring.yaml)： 

    service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

  3. 透過執行以下指令套用監控服務： 

    cephuser@adm > ceph orch apply -i monitoring.yaml

    部署監控服務可能需要一到兩分鐘。

重要
重要

Prometheus、Grafana 和 Ceph Dashboard 全都會自動設定為相互通訊，因此如上述般進行部署時，Ceph Dashboard 中將實現功能完整的 Grafana 整合。

但使用 RBD 影像進行監控時不適用於此規則。如需詳細資訊，請參閱Book “操作和管理指南”, Chapter 16 “監控和警示”, Section 16.5.4 “啟用 RBD 影像監控”。

第 III 部分 安裝其他服務

 
  • 6 安裝 iSCSI 閘道

    • iSCSI 是一種儲存區域網路 (SAN) 通訊協定，可讓用戶端 (稱為啟動器) 將 SCSI 指令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。SUSE Enterprise Storage 7 包含一個可透過 iSCSI 通訊協定向異質用戶端 (例如 Microsoft Windows* 和 VMware* vSphere) 開放 Ceph 儲存管理的工具。多重路徑 iSCSI 存取可讓這些用戶端實現可用性與延展性，此外，該標準化 iSCSI 通訊協定在用戶端與 SUSE Enterprise Storage 7 叢集之間提供了一層額外的安全性隔離。該組態工具名為 ceph-iscs…

6 安裝 iSCSI 閘道

 

iSCSI 是一種儲存區域網路 (SAN) 通訊協定，可讓用戶端 (稱為啟動器) 將 SCSI 指令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。SUSE Enterprise Storage 7 包含一個可透過 iSCSI 通訊協定向異質用戶端 (例如 Microsoft Windows* 和 VMware* vSphere) 開放 Ceph 儲存管理的工具。多重路徑 iSCSI 存取可讓這些用戶端實現可用性與延展性，此外，該標準化 iSCSI 通訊協定在用戶端與 SUSE Enterprise Storage 7 叢集之間提供了一層額外的安全性隔離。該組態工具名為 ceph-iscsi。使用 ceph-iscsi，Ceph 儲存管理員可以定義精簡佈建的高可用性複製磁碟區，其支援唯讀快照、讀取寫入克隆，以及 Ceph RADOS 區塊裝置 (RBD) 的自動大小調整。然後，管理員可以透過單個 ceph-iscsi 閘道主機輸出磁碟區，或透過支援多重路徑容錯移轉的多個閘道主機來輸出。Linux、Microsoft Windows 和 VMware 主機可以使用 iSCSI 通訊協定連接到磁碟區，因此可如任何其他 SCSI 區塊裝置一般供您使用。這表示，SUSE Enterprise Storage 7 客戶實際上可在 Ceph 上執行具有傳統 SAN 所有功能和優勢的完整區塊儲存基礎架構子系統，從而在未來實現蓬勃發展。

本章詳細介紹如何設定 Ceph 叢集基礎架構和 iSCSI 閘道，以便用戶端主機能夠透過 iSCSI 通訊協定，如同在本機儲存裝置上一般使用遠端儲存的資料。

6.1 iSCSI 區塊儲存

 

iSCSI 是 RFC 3720 中指定的、使用網際網路通訊協定 (IP) 的小型電腦系統介面 (SCSI) 指令集的一種實作。iSCSI 以服務形式實作，其中，用戶端 (啟動器) 在 TCP 連接埠 3260 上透過工作階段來與伺服器 (目標) 通訊。iSCSI 目標的 IP 位址和連接埠稱為 iSCSI 入口網站，其中，一個目標可透過一個或多個入口網站公開。一個目標與一個或多個入口網站的組合稱為目標入口網站群組 (TPG)。

iSCSI 的基礎資料連結層通訊協定通常為乙太網路。更具體地說，現代 iSCSI 基礎架構使用 10 GigE 乙太網路或更快的網路實現最佳輸送量。強烈建議您在 iSCSI 閘道與後端 Ceph 叢集之間建立 10 Gb 乙太網路連接。

6.1.1 Linux 核心 iSCSI 目標

 

Linux 核心 iSCSI 目標最初稱作 linux-iscsi.or 的 LIO，它是專案的原始網域和網站。在過去一段時間，適用於 Linux 平台的 iSCSI 目標實作競爭產品不少於四個，但 LIO 做為單一 iSCSI 參考目標最終獲得了壓倒性優勢。LIO 的主流核心代碼使用簡單但有些含糊的名稱「目標」，來區別「目標核心」與各種前端和後端目標模組。

可以說，最常用的前端模組就是 iSCSI。但是，LIO 也支援光纖通道 (FC)、透過乙太網路的光纖通道 (FCoE) 與其他多種前端通訊協定。目前，SUSE Enterprise Storage 僅支援 iSCSI 通訊協定。

最常用的目標後端模組是能夠方便地在目標主機上重新輸出任何可用區塊裝置的模組。此模組名為 iblock。但是，LIO 還有一個 RBD 特定的後端模組，該模組支援對 RBD 影像進行平行多重路徑 I/O 存取。

6.1.2 iSCSI 啟動器

 

本節簡要介紹 Linux、Microsoft Windows 和 VMware 平台上使用的 iSCSI 啟動器。

6.1.2.1 Linux

 

Linux 平台的標準啟動器是 open-iscsi。open-iscsi 會啟動精靈 iscsid，然後，使用者可以使用該精靈來探查任何給定入口網站上的 iSCSI 目標、登入到目標，以及對應 iSCSI 磁碟區。iscsid 會與 SCSI 中間層通訊以建立核心中區塊裝置，然後，核心便可如處理系統上的任何其他 SCSI 區塊裝置一般處理這些裝置。您可以搭配裝置對應程式多重路徑 (dm-multipath) 工具一起部署 open-iscsi 啟動器，以提供高可用性 iSCSI 區塊裝置。

6.1.2.2 Microsoft Windows 和 Hyper-V

 

Microsoft Windows 作業系統的預設 iSCSI 啟動器是 Microsoft iSCSI 啟動器。iSCSI 服務可透過圖形使用者介面 (GUI) 進行設定，並支援使用多重路徑 I/O 以提供高可用性。

6.1.2.3 VMware

 

VMware vSphere 和 ESX 的預設 iSCSI 啟動器是 VMware ESX 軟體 iSCSI 啟動器 vmkiscsi。啟用該啟動器後，可透過 vSphere 用戶端或使用 vmkiscsi-tool 指令對其進行設定。然後，您可以使用 VMFS 來格式化透過 vSphere iSCSI 儲存介面卡連接的儲存磁碟區，並如同使用任何其他虛擬機器儲存裝置一般使用它們。VMware 啟動器還支援使用多重路徑 I/O 以提供高可用性。

6.2 有關 ceph-iscsi 的一般資訊

 

ceph-iscsi 兼具 RADOS 區塊裝置的優勢與 iSCSI 無所不在的通用性。透過在 iSCSI 目標主機 (稱為 iSCSI 閘道) 上使用 ceph-iscsi，任何需要利用區塊儲存的應用程式都可受益於 Ceph，即使不支援任何 Ceph 用戶端通訊協定的應用程式也不例外。而使用者可以使用 iSCSI 或任何其他目標前端通訊協定連接至 LIO 目標，從而可以轉換針對 RBD 儲存的所有目標 I/O。

包含單一 iSCSI 閘道的 Ceph 叢集
圖 6.1︰ 包含單一 iSCSI 閘道的 Ceph 叢集
 

ceph-iscsi 先天就具有高可用性，並支援多重路徑操作。因此，下游啟動器主機可以使用多個 iSCSI 閘道實現高可用性和延展性。與包含多個閘道的 iSCSI 組態通訊時，啟動器可在多個閘道之間實現 iSCSI 申請的負載平衡。如果某個閘道發生故障 (暫時不可連接，或因為維護而停用)，則將透過另一個閘道以透明方式繼續處理 I/O。

包含多個 iSCSI 閘道的 Ceph 叢集
圖 6.2︰ 包含多個 iSCSI 閘道的 Ceph 叢集
 

6.3 部署考量

 

包含 ceph-iscsi 的最低 SUSE Enterprise Storage 7 組態由以下元件組成：

  • 一個 Ceph 儲存叢集。該 Ceph 叢集至少包含四部實體伺服器，其中每部伺服器至少代管八個物件儲存精靈 (OSD)。在此類組態中，有三個 OSD 節點額外充當監控程式 (MON) 主機。

  • 一部透過 ceph-iscsi 設定且執行 LIO iSCSI 目標的 iSCSI 目標伺服器。

  • 一部 iSCSI 啟動器主機，執行 open-iscsi (Linux)、Microsoft iSCSI 啟動器 (Microsoft Windows) 或任何其他相容的 iSCSI 啟動器實作。

包含 ceph-iscsi 的 SUSE Enterprise Storage 7 建議生產組態由以下元件組成：

  • 一個 Ceph 儲存叢集。一個 Ceph 生產叢集，它由任意數量 (一般是 10 個以上) 的 OSD 節點組成，其中每個節點一般執行 10-12 個物件儲存精靈 (OSD)，以及至少三部專屬 MON 主機。

  • 多部透過 ceph-iscsi 設定且執行 LIO iSCSI 目標的 iSCSI 目標伺服器。為實現 iSCSI 容錯移轉和負載平衡，這些伺服器必須執行支援 target_core_rbd 模組的核心。您可透過 SUSE Linux Enterprise Server 維護通道取得更新套件。

  • 任意數量的 iSCSI 啟動器主機，這些主機執行 open-iscsi (Linux)、Microsoft iSCSI 啟動器 (Microsoft Windows) 或任何其他相容的 iSCSI 啟動器實作。

6.4 安裝與組態

 

本節介紹在 SUSE Enterprise Storage 之上安裝和設定 iSCSI 閘道的步驟。

6.4.1 將 iSCSI 閘道部署到 Ceph 叢集

 

Ceph iSCSI 閘道採用與其他 Ceph 服務相同的程序進行部署，即使用 cephadm。如需詳細資訊，請參閱第 5.4.3.5 節 「部署 iSCSI 閘道」。

6.4.2 建立 RBD 影像

 

RBD 影像建立於 Ceph 儲存中，並在隨後輸出至 iSCSI。建議您為此使用專屬的 RADOS 池。您可以在能夠使用 Ceph rbd 指令行公用程式連接到儲存叢集的任何主機上建立磁碟區。這需要用戶端至少有一個精簡的 ceph.conf 組態檔案，以及相應的 CephX 驗證身分證明。

若要透過 iSCSI 建立一個隨後可供輸出的新磁碟區，請使用 rbd create 指令並指定磁碟區大小 (以 MB 為單位)。例如，若要在名為 iscsi-images 的池中建立名為 testvol 的 100 GB 磁碟區，請執行以下指令： 

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

6.4.3 透過 iSCSI 輸出 RBD 影像

 

若要透過 iSCSI 輸出 RBD 影像，您可以使用 Ceph Dashboard Web 介面或 ceph-iscsi gwcli 公用程式。在本節中，我們僅重點介紹 gwcli，並演示如何使用指令行建立輸出 RBD 影像的 iSCSI 目標。

注意
注意

無法透過 iSCSI 輸出具有以下內容的 RBD 影像：

  • 啟用 journaling 功能的影像

  • stripe unit 小於 4096 位元組的影像

以 root 身分進入 iSCSI 閘道容器： 

root # cephadm enter --name CONTAINER_NAME

以 root 身分啟動 iSCSI 閘道指令行介面： 

root # gwcli

移至 iscsi-targets，然後建立名為 iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol 的目標： 

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

透過指定閘道名稱和 IP 位址建立 iSCSI 閘道： 

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
提示
提示

使用 help 指令可顯示目前組態節點中的可用指令清單。

在池 iscsi-images 中新增名為 testvol 的 RBD 影像： 

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

將 RBD 影像對應至目標： 

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol
注意
注意

您可以使用層級較低的工具 (例如 targetcli) 來查詢本地組態，但無法修改組態。

提示
提示

您可以使用 ls 指令查看組態。有些組態節點還支援 info 指令，該指令可用於顯示更多詳細資訊。

請注意，系統預設會啟用 ACL 驗證，因此目前尚不可存取此目標。如需驗證和存取控制的詳細資訊，請參閱第 6.4.4 節 「驗證和存取控制」。

6.4.4 驗證和存取控制

 

iSCSI 驗證十分靈活，涵蓋了許多驗證可能性。

6.4.4.1 停用 ACL 驗證

 

無驗證表示任何啟動器均能存取對應目標上的任何 LUN。您可以透過停用 ACL 驗證來啟用無驗證： 

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

6.4.4.2 使用 ACL 驗證

 

使用基於啟動器名稱的 ACL 驗證時，僅允許定義的啟動器進行連接。您可以透過執行以下指令來定義啟動器： 

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

定義的啟動器雖然能夠連接，但只能存取已明確新增至該啟動器的 RBD 影像： 

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

6.4.4.3 啟用 CHAP 驗證

 

除了 ACL 以外，您還可以透過為每個啟動器指定使用者名稱和密碼來啟用 CHAP 驗證： 

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
注意
注意

使用者名稱長度必須為 8 至 64 個字元，可以包含英數字元、.、@、-、_ 或 :。

密碼長度必須為 12 至 16 個字元，可以包含英數字元、@、-、_ 或 /。

(選擇性) 您也可以在 auth 指令中指定 mutual_username 和 mutual_password 參數，以啟用 CHAP 雙向驗證。

6.4.4.4 設定探查和雙向驗證

 

探查驗證獨立於之前的驗證方法。該驗證需要身分證明才能進行瀏覽，它是選擇性設定，可透過執行以下指令來設定： 

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
注意
注意

使用者名稱長度必須為 8 至 64 個字元，並且只能包含字母、.、@、-、_ 或 :。

密碼長度必須為 12 至 16 個字元，並且只能包含字母、@、-、_ 或 /。

(選擇性) 您也可以在 discovery_auth 指令中指定 mutual_username 和 mutual_password 參數。

可以使用以下指令來停用探查驗證： 

gwcli >  /iscsi-targets> discovery_auth nochap

6.4.5 設定進階設定

 

可以為 ceph-iscsi 設定隨後將傳遞給 LIO I/O 目標的進階參數。參數分為 target 和 disk 參數。

警告
警告

除非另有說明，否則不建議將這些參數變更為使用非預設設定。

6.4.5.1 檢視目標設定

 

您可以使用 info 指令檢視這些設定的值： 

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

還可以使用 reconfigure 指令變更設定： 

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

可用的 target 設定包括：

default_cmdsn_depth

預設的 CmdSN (指令順序編號) 深度。限制 iSCSI 啟動器可在任何時候具有的未處理申請數量。

default_erl

預設的錯誤復原層級。

login_timeout

登入逾時值 (以秒為單位)。

netif_timeout

NIC 故障逾時 (以秒為單位)。

prod_mode_write_protect

如果設定為 1，則阻止寫入 LUN。

6.4.5.2 檢視磁碟設定

 

您可以使用 info 指令檢視這些設定的值： 

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

還可以使用 reconfigure 指令變更設定： 

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

可用的 disk 設定包括：

block_size

基礎裝置的區塊大小。

emulate_3pc

如果設定為 1，則啟用「協力廠商複製」。

emulate_caw

如果設定為 1，則啟用「比較並寫入」。

emulate_dpo

如果設定為 1，則開啟「停用頁面輸出」。

emulate_fua_read

如果設定為 1，則啟用「強制單元讀取存取」。

emulate_fua_write

如果設定為 1，則啟用「強制單元寫入存取」。

emulate_model_alias

如果設定為 1，則使用後端裝置名稱做為模型別名。

emulate_pr

如果設定為 0，將停用 SCSI 保留 (包括永久群組保留) 支援。停用該支援後，SES iSCSI 閘道可能會忽略保留狀態，導致要求延遲情況得到改進。

提示
提示

如果 iSCSI 啟動器不需要 SCSI 保留支援，建議將 backstore_emulate_pr 設定為 0。

emulate_rest_reord

如果設定為 0，則佇列演算法修飾詞的重新排序受限。

emulate_tas

如果設定為 1，則啟用「任務已中止狀態」。

emulate_tpu

如果設定為 1，則啟用「精簡佈建 - 取消對應」。

emulate_tpws

如果設定為 1，則啟用「精簡佈建 - 寫入相同內容」。

emulate_ua_intlck_ctrl

如果設定為 1，則啟用「單元警告連鎖」。

emulate_write_cache

如果設定為 1，則開啟「啟用寫入快取」。

enforce_pr_isids

如果設定為 1，則強制永久保留 ISID。

is_nonrot

如果設定為 1，則後備儲存為非旋轉裝置。

max_unmap_block_desc_count

UNMAP 的最大區塊描述子數量。

max_unmap_lba_count：

UNMAP 的最大 LBA 數。

max_write_same_len

WRITE_SAME 的最大長度。

optimal_sectors

磁區中的最佳申請大小。

pi_prot_type

DIF 保護類型。

queue_depth

佇列深度。

unmap_granularity

UNMAP 細粒度。

unmap_granularity_alignment

UNMAP 細粒度對齊。

force_pr_aptpl

如果啟用該設定，無論用戶端是否透過 aptpl=1 發出了相應要求，LIO 都一律會將永久保留狀態寫出至永久儲存區。這對 LIO 的核心 RBD 後端不會產生任何影響，該後端永遠會保留 PR 狀態。理論上，如果有人嘗試透過組態停用該設定，target_core_rbd 選項應該會強制將其設定為「1」並拋出錯誤。

unmap_zeroes_data

影響 LIO 是否會向 SCSI 啟動器通告 LBPRZ，表示將在執行包含取消對應位元的 UNMAP 或 WRITE SAME 指令後從某個區域讀回零。

6.5 使用 tcmu-runner 輸出 RADOS 區塊裝置影像

 

ceph-iscsi 支援 rbd (基於核心) 和 user:rbd (tcmu-runner) 後備儲存，這使整個管理過程變得透明並且獨立於後備儲存。

警告
警告：技術預覽

基於 tcmu-runner 的 iSCSI 閘道部署目前以技術預覽的方式提供。

與基於核心的 iSCSI 閘道部署不同，基於 tcmu-runner 的 iSCSI 閘道不支援多重路徑 I/O 或 SCSI 持續保留。

若要使用 tcmu-runner 輸出 RADOS 區塊裝置影像，您只需在連接磁碟時指定 user:rbd 後備儲存即可： 

gwcli >  /disks> attach rbd/testvol backstore=user:rbd
注意
注意

使用 tcmu-runner 時，輸出的 RBD 影像必須啟用 exclusive-lock 功能。

第 IV 部分 從舊版本升級

 

7 自前一版本升級

 

本章說明將 SUSE Enterprise Storage 6 升級至版本 7 的步驟。

升級包括以下任務：

  • 自 Ceph Nautilus 升級至 Octopus。

  • 從透過 RPM 套件安裝和執行 Ceph 切換到在容器中執行。

  • 完全移除 DeepSea 並以 ceph-salt 和 cephadm 取代。

警告
警告

本章中的升級資訊僅適用於自 DeepSea 升級至 cephadm。如果您要在 SUSE CaaS 平台上部署 SUSE Enterprise Storage，請不要嘗試遵循這些說明。

重要
重要

不支援從早於 6 的 SUSE Enterprise Storage 版本升級。您需要先升級至 SUSE Enterprise Storage 6 的最新版本，然後再依照本章所述的步驟操作。

7.1 升級前

 

開始升級之前，必須完成以下任務。在 SUSE Enterprise Storage 6 生命週期內可隨時執行這些操作。

7.1.1 需考量的要點

 

升級前，請務必閱讀以下章節，確定您瞭解所有需要執行的任務。

  • 閱讀版本說明 - 版本說明提供了有關自 SUSE Enterprise Storage 上一個版本發行後所進行的變更的其他資訊。檢查版本說明以瞭解：

    • 您的硬體是否有特殊注意事項。

    • 所用的任何軟體套件是否已發生重大變更。

    • 是否需要對您的安裝施行特殊預防措施。

    版本說明還會提供無法及時編入手冊的資訊。它們還包含有關已知問題的說明。

    您可以在 https://www.suse.com/releasenotes/ 上找到線上 SES 7 版本說明。

    此外，安裝 SES 7 儲存庫中的 release-notes-ses 套件之後，您可在 /usr/share/doc/release-notes 目錄中找到本地版本說明，或在 https://www.suse.com/releasenotes/ 上找到線上版本說明。

  • 閱讀第 5 章 「使用 cephadm 進行部署」，熟悉 ceph-salt 和 Ceph orchestrator，特別需要瞭解有關服務規格的資訊。

  • 升級叢集可能需要花很長時間 - 所需時間大約為升級一部機器的時間乘以叢集節點數。

  • 您需要先升級 Salt Master，然後以 ceph-salt 和 cephadm 取代 DeepSea。至少要等到所有 Ceph 管理員都升級後，您才能開始使用 cephadm orchestrator 模組。

  • 從使用 Nautilus RPM 到 Octopus 容器的升級需要一步完成。這表示您需要一次升級整個節點，而不是一次只升級一個精靈。

  • 核心服務 (MON、MGR、OSD) 的升級是循序進行的。每個服務在升級期間都可用。升級核心服務後，需要重新部署閘道服務 (中繼資料伺服器、物件閘道、NFS Ganesha、iSCSI 閘道)。下面每個服務都有特定的停機時間：

    • 重要
      重要

      中繼資料伺服器和物件閘道的停機時間自節點從 SUSE Linux Enterprise Server 15 SP1 升級至 SUSE Linux Enterprise Server 15 SP2 開始，直至升級程序結束時重新部署這些服務為止。如果這些服務與 MON、MGR 或 OSD 併置，則需特別考慮到停機時間，因為在這種情況下，它們可能會在叢集升級的整個期間處於停機狀態。如果這對您是個問題，請考慮在升級之前於其他節點上單獨部署這些服務，以儘可能縮短它們的停機時間。如此，停機時間便將是閘道節點升級的持續時間，而不是整個叢集升級的持續時間。

    • NFS Ganesha 和 iSCSI 閘道僅在從 SUSE Linux Enterprise Server 15 SP1 升級至 SUSE Linux Enterprise Server 15 SP2 期間將節點重新開機時處於停機狀態，並會在以容器化模式重新部署每個服務時再次短暫處於停機狀態。

7.1.2 備份叢集組態和資料

 

強烈建議您在開始升級至 SUSE Enterprise Storage 7 之前，備份所有叢集組態和資料。如需如何備份所有資料的說明，請參閱 https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html。

7.1.3 確認先前升級的步驟

 

如果您先前是從版本 5 升級的，請確認升級至版本 6 的程序已成功完成：

檢查 /srv/salt/ceph/configuration/files/ceph.conf.import 檔案是否存在。

此檔案是在從 SUSE Enterprise Storage 5 升級至 6 期間由 engulf 程序建立的。configuration_init: default-import 選項在 /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml 中設定。

如果 configuration_init 仍設為 default-import，則表示叢集是使用 ceph.conf.import 而非 DeepSea 的預設 ceph.conf 做為其組態檔案的，後者是透過對 /srv/salt/ceph/configuration/files/ceph.conf.d/ 中的檔案進行編譯而產生的。

因此，您需要檢查 ceph.conf.import 中是否有任何自訂組態，並視需要將相應組態移至 /srv/salt/ceph/configuration/files/ceph.conf.d/ 中的其中一個檔案中。

然後從 /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml 中移除 configuration_init: default-import 行。

7.1.4 更新叢集節點並確認叢集狀況

 

確認 SUSE Linux Enterprise Server 15 SP1和 SUSE Enterprise Storage 6 的所有最新更新是否已套用至所有叢集節點： 

root # zypper refresh && zypper patch

套用更新後，請檢查叢集狀況： 

cephuser@adm > ceph -s

7.1.5 確認對軟體儲存庫和容器影像的存取權

 

確認每個叢集節點是否擁有對 SUSE Linux Enterprise Server 15 SP2 和 SUSE Enterprise Storage 7 軟體儲存庫以及容器影像登錄的存取權。

7.1.5.1 軟體儲存庫

 

如果所有節點均已在 SCC 中註冊，您便可以使用 zypper migration 指令進行升級。如需更多詳細資料，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper。

如果節點未在 SCC 中註冊，請停用所有現有軟體儲存庫，並為下面每個延伸新增 Pool 和 Updates 儲存庫：

  • SLE-Product-SLES/15-SP2

  • SLE-Module-Basesystem/15-SP2

  • SLE-Module-Server-Applications/15-SP2

  • SUSE-Enterprise-Storage-7

7.1.5.2 容器影像

 

所有叢集節點都需要存取容器影像登錄。在大多數情況下，您將使用 registry.suse.com 上的公用 SUSE 登錄。您需要以下影像：

  • registry.suse.com/ses/7/ceph/ceph

  • registry.suse.com/ses/7/ceph/grafana

  • registry.suse.com/caasp/v4.5/prometheus-server

  • registry.suse.com/caasp/v4.5/prometheus-node-exporter

  • registry.suse.com/caasp/v4.5/prometheus-alertmanager

或者，例如對於實體隔離部署，請設定本地登錄並確認您是否有一組正確的容器影像可用。如需設定本地容器影像登錄的更多詳細資料，請參閱第 5.3.2.11 節 「設定容器登錄」。

7.2 升級 Salt Master

 

以下程序說明了升級 Salt Master 的過程：

  1. 將基礎作業系統升級至 SUSE Linux Enterprise Server 15 SP2：

    • 對於所有節點均已在 SCC 中註冊的叢集，請執行 zypper migration。

    • 對於節點具有手動指定軟體儲存庫的叢集，請執行 zypper dup，然後再執行 reboot。

  2. 停用 DeepSea 階段以避免意外使用。將以下內容新增至 /srv/pillar/ceph/stack/global.yml： 

    stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

    儲存檔案並套用變更： 

    root@master # salt '*' saltutil.pillar_refresh

  3. 如果您未使用 registry.suse.com 中的容器影像，而是使用本地設定的登錄，請編輯 /srv/pillar/ceph/stack/global.yml 以告知 DeepSea 要使用哪個 Ceph 容器影像和登錄。例如，若要使用 192.168.121.1:5000/my/ceph/image，請新增下面幾行： 

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000

    儲存檔案並套用變更： 

    root@master # salt '*' saltutil.refresh_pillar

  4. 同化現有組態： 

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

  5. 確認升級狀態。您的輸出可能因叢集組態而異： 

    root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable)
 os: SUSE Linux Enterprise Server 15 SP2
Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)
Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

7.3 升級 MON、MGR 和 OSD 節點

 

每次升級一個 Ceph 監控程式、Ceph 管理員和 OSD 節點。對於每個服務，請執行以下步驟：

  1. 如果您要升級的是 OSD 節點，請透過執行以下指令避免在升級期間將 OSD 標示為 out： 

    cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

    以 ceph osd tree 指令輸出中顯示之節點的簡短名稱取代 SHORT_NODE_NAME。在以下輸入中，主機簡短名稱為 ses-min1 和 ses-min2 

    root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

  2. 將基礎作業系統升級至 SUSE Linux Enterprise Server 15 SP2：

    • 如果叢集的節點均已在 SCC 中註冊，請執行 zypper migration。

    • 如果叢集的節點具有手動指定的軟體儲存庫，請執行 zypper dup，然後再執行 reboot。

  3. 將節點重新開機後，透過在 Salt Master 上執行以下指令，將該節點上所有現有 MON、MGR 和 OSD 精靈進行容器化： 

    root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt

    以您要升級的 Minion 的 ID 取代 MINION_ID。您可以透過在 Salt Master 上執行 salt-key -L 指令來獲取 Minion ID 清單。

    提示
    提示

    若要查看採用的狀態和進度，請檢查 Ceph Dashboard 或在 Salt Master 上執行下面其中一個指令： 

    root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  4. 成功完成採用後，如果您要升級的節點是 OSD 節點，請取消設定 noout 旗標： 

    cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME

7.4 升級閘道節點

 

接下來，請升級各個閘道節點 (中繼資料伺服器、物件閘道、NFS Ganesha 或 iSCSI 閘道)。針對每個節點將基礎作業系統升級至 SUSE Linux Enterprise Server 15 SP2：

  • 如果叢集的節點均已在 SUSE Customer Center 中註冊，請執行 zypper migration 指令。

  • 如果叢集的節點具有手動指定的軟體儲存庫，請執行 zypper dup，然後再執行 reboot 指令。

此步驟同樣適用於屬於叢集但尚未指定任何角色的任何節點 (如有疑問，請查看透過 salt-key -L 指令提供的 Salt Master 上的主機清單，並將其與 salt-run upgrade.status 指令的輸出進行比較)。

升級叢集中所有節點上的作業系統後，下一步是安裝 ceph-salt 套件並套用叢集組態。升級程序結束時，會以容器化模式重新部署實際的閘道服務。

注意
注意

從升級至 SUSE Linux Enterprise Server 15 SP2 開始，到升級程序結束時重新部署中繼資料伺服器和物件閘道服務為止，這段期間這些服務將不可用。

7.5 安裝 ceph-salt 並套用叢集組態

 

在開始安裝 ceph-salt 並套用叢集組態之前，請先透過執行以下指令查看叢集和升級狀態： 

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  1. 移除 DeepSea 建立的 rbd_exporter 和 rgw_exporter 排程工作 (cron job)。在 Salt Master 上，以 root 身分執行 crontab -e 指令以編輯 crontab。刪除下列項目 (如果存在)： 

    # SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

  2. 透過執行以下指令從 DeepSea 輸出叢集組態： 

    root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

  3. 解除安裝 DeepSea，並在 Salt Master 上安裝 ceph-salt： 

    root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

  4. 重新啟動 Salt Master 並同步 Salt 模組： 

    root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

  5. 將 DeepSea 的叢集組態輸入至 ceph-salt： 

    root@master # ceph-salt import ceph-salt-config.json

  6. 為叢集節點通訊產生 SSH 金鑰： 

    root@master # ceph-salt config /ssh generate
    提示
    提示

    確認是否已從 DeepSea 輸入叢集組態，並指定可能缺失的選項： 

    root@master # ceph-salt config ls

    如需叢集組態的完整描述，請參閱第 5.3.2 節 「設定叢集內容」。

  7. 套用組態並啟用 cephadm： 

    root@master # ceph-salt apply

  8. 如果您需要提供本地容器登錄 URL 和存取身分證明，請依據第 5.3.2.11 節 「設定容器登錄」中所述的步驟進行操作。

  9. 如果您未使用 registry.suse.com 中的容器影像，而是使用本地設定的登錄，請執行以下指令以告知 Ceph 要使用哪個容器影像 

    root@master # ceph config set global container_image IMAGE_NAME

    例如： 

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image

  10. 停止並停用 SUSE Enterprise Storage 6 ceph-crash 精靈。系統將於稍後自動啟動這些精靈的新容器化格式。 

    root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash

7.6 升級並採用監控堆疊

 

以下程序會採用監控堆疊的所有元件 (如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 16 “監控和警示”)。

  1. 暫停 orchestrator： 

    cephuser@adm > ceph orch pause

  2. 在執行 Prometheus、Grafana 和警示管理員 (預設為 Salt Master) 的節點上，執行以下指令： 

    cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)
    提示
    提示

    如果您未執行預設容器影像登錄 registry.suse.com，則需要指定要使用的影像，例如： 

    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \
 adopt --style=legacy --name grafana.$(hostname)

    如需使用自訂或本地容器影像的更多詳細資料，請參閱Book “操作和管理指南”, Chapter 16 “監控和警示”, Section 16.1 “設定自訂或本地影像”。

  3. 移除 Node-Exporter。它不需要進行移轉，將在套用 specs.yaml 檔案時做為容器重新安裝。 

    tux > sudo zypper rm golang-github-prometheus-node_exporter

  4. 套用您先前從 DeepSea 輸出的服務規格： 

    cephuser@adm > ceph orch apply -i specs.yaml

  5. 繼續 orchestrator： 

    cephuser@adm > ceph orch resume

7.7 重新部署閘道服務

 

7.7.1 升級物件閘道

 

在 SUSE Enterprise Storage 7 中，物件閘道永遠設定有一個領域，以為未來使用多站台提供支援 (如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 21 “Ceph 物件閘道”, Section 21.13 “多站台物件閘道”)。如果您在 SUSE Enterprise Storage 6 中使用了單站台物件閘道組態，請執行以下步驟來新增領域。如果您實際上並不打算使用多站台功能，則可以為領域、區域群組和區域名稱使用 default 值。

  1. 建立新領域： 

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

  2. (選擇性) 重新命名預設區域和區域群組。 

    cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

  3. 設定主區域群組： 

    cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

  4. 設定主區域。為此，您將需要啟用了 system 旗標之物件閘道使用者的 ACCESS_KEY 和 SECRET_KEY。這通常是 admin 使用者。若要獲取 ACCESS_KEY 和 SECRET_KEY，請執行 radosgw-admin user info --uid admin。 

    cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default

  5. 提交更新後的組態： 

    cephuser@adm > radosgw-admin period update --commit

若要將物件閘道服務容器化，請依據第 5.4.3.4 節 「部署物件閘道」中所述建立其規格檔案，然後套用該檔案。 

cephuser@adm > ceph orch apply -i RGW.yml

7.7.2 升級 NFS Ganesha

 

下面說明如何將執行 Ceph Nautilus 的現有 NFS Ganesha 服務移轉至執行 Ceph Octopus 的 NFS Ganesha 容器。

警告
警告

以下文件要求您已成功升級了核心 Ceph 服務。

NFS Ganesha 會在 RADOS 池中儲存額外的精靈特定組態並輸出組態。所設定的 RADOS 池可在 ganesha.conf 檔案中之 RADOS_URLS 區塊的 watch_url 行上找到。依預設，此池將重新命名為 ganesha_config

在嘗試任何移轉之前，強烈建議您複製 RADOS 池中的輸出和精靈組態物件。若要尋找所設定的 RADOS 池，請執行以下指令： 

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

列出 RADOS 池的內容： 

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

複製 RADOS 物件： 

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

基於每個節點，停止現有的 NFS Ganesha 服務，然後以 cephadm 管理的容器取代。

  1. 停止並停用現有的 NFS Ganesha 服務： 

    cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

  2. 停止現有的 NFS Ganesha 服務之後，可以使用 cephadm 在容器中部署一個新的服務。為此，您需要建立一個服務規格，其中包含將用於識別此新 NFS 叢集的 service_id、在放置規格中做為主機列出的所要移轉節點的主機名稱，以及包含所設定 NFS 輸出物件的 RADOS 池和名稱空間。例如： 

    service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha

    如需建立放置規格的詳細資訊，請參閱第 5.4.2 節 「服務和放置規格」。

  3. 套用放置規格： 

    cephuser@adm > ceph orch apply -i FILENAME.yaml

  4. 確認主機上是否執行有 NFS Ganesha 精靈： 

    cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

  5. 針對每個 NFS Ganesha 節點重複上述步驟。您不需要為每個節點建立單獨的服務規格。您只需將每個節點的主機名稱新增至現有 NFS 服務規格中，然後重新套用該規格。

現有輸出可以透過兩種方法進行移轉：

  • 使用 Ceph Dashboard 手動重新建立或重新指定。

  • 手動將每個精靈 RADOS 物件的內容複製到新建立的 NFS Ganesha 通用組態中。

程序 7.1︰ 手動將輸出複製到 NFS Ganesha 通用組態檔案
 

  1. 確定每個精靈 RADOS 物件的清單： 

    cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

  2. 複製每個精靈的 RADOS 物件： 

    cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

  3. 排序並合併到單個輸出清單中： 

    cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

  4. 寫入新的 NFS Ganesha 通用組態檔案： 

    cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

  5. 通知 NFS Ganesha 精靈： 

    cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
    注意
    注意

    此動作將導致精靈重新載入組態。

成功移轉服務後，可以移除基於 Nautilus 的 NFS Ganesha 服務。

  1. 移除 NFS Ganesha： 

    cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

  2. 從 Ceph Dashboard 中移除舊的叢集設定： 

    cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

7.7.3 升級中繼資料伺服器

 

與 MON、MGR 和 OSD 不同，無法就地採用中繼資料伺服器。您需要使用 Ceph orchestrator 在容器中進行重新部署。

  1. 執行 ceph fs ls 指令以獲取您檔案系統的名稱，例如： 

    cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

  2. 透過使用檔案系統名稱做為 service_id，並指定將會執行 MDS 精靈的主機，依據第 5.4.3.3 節 「部署中繼資料伺服器」中所述建立新服務規格檔案 mds.yml。例如： 

    service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

  3. 執行 ceph orch apply -i mds.yml 指令以套用服務規格並啟動 MDS 精靈。

7.7.4 升級 iSCSI 閘道

 

若要升級 iSCSI 閘道，您需要使用 Ceph orchestrator 在容器中重新部署該閘道。如果您有多個 iSCSI 閘道，則需要逐一重新部署，以減少服務停機時間。

  1. 停止並停用每個 iSCSI 閘道節點上的現有 iSCSI 精靈： 

    tux > sudo systemctl stop rbd-target-gw
tux > sudo systemctl disable rbd-target-gw
tux > sudo systemctl stop rbd-target-api
tux > sudo systemctl disable rbd-target-api

  2. 依據第 5.4.3.5 節 「部署 iSCSI 閘道」中所述，為 iSCSI 閘道建立服務規格。為此，您需要現有 /etc/ceph/iscsi-gateway.cfg 檔案中的 pool、trusted_ip_list 和 api_* 設定。如果您啟用了 SSL 支援 (api_secure = true)，則還需要 SSL 證書 (/etc/ceph/iscsi-gateway.crt) 和金鑰 (/etc/ceph/iscsi-gateway.key)。

    例如，如果 /etc/ceph/iscsi-gateway.cfg 包含以下設定： 

    [config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true

    則您需要建立以下服務規格檔案 iscsi.yml： 

    service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----
    注意
    注意

    pool、trusted_ip_list、api_port、api_user、api_password、api_secure 設定與 /etc/ceph/iscsi-gateway.cfg 檔案中的相應設定相同。可從現有 SSL 證書和金鑰檔案中複製 ssl_cert 和 ssl_key 值。確認這些值是否縮排正確，並且 ssl_cert: 和 ssl_key: 行的末尾是否顯示有縱線字元 | (請參閱上述 iscsi.yml 檔案的內容)。

  3. 執行 ceph orch apply -i iscsi.yml 指令以套用服務規格並啟動 iSCSI 閘道精靈。

  4. 從每個現有 iSCSI 閘道節點中移除舊的 ceph-iscsi 套件： 

    cephuser@adm > zypper rm -u ceph-iscsi

7.8 升級後清理

 

升級後，請執行以下清理步驟：

  1. 透過檢查目前的 Ceph 版本，確認叢集是否已成功升級： 

    cephuser@adm > ceph versions

  2. 確定沒有舊的 OSD 加入叢集： 

    cephuser@adm > ceph osd require-osd-release octopus

  3. 啟用自動調整器模組： 

    cephuser@adm > ceph mgr module enable pg_autoscaler
    重要
    重要

    依預設，在 SUSE Enterprise Storage 6 中，池的 pg_autoscale_mode 設定為 warn。這會導致在 PG 數量未達到最佳時出現警告訊息，但實際上並未發生自動調整。在 SUSE Enterprise Storage 7 中，新池的 pg_autoscale_mode 選項預設設定為 on，因此實際上會自動調整 PG。而升級程序並不會自動變更現有池的 pg_autoscale_mode。如果您要將其變更為 on 以充分利用自動調整器的功能，請參閱Book “操作和管理指南”, Chapter 17 “儲存的資料管理”, Section 17.4.12 “啟用 PG 自動調整器”中的說明。

    如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 17 “儲存的資料管理”, Section 17.4.12 “啟用 PG 自動調整器”。

  4. 阻止 Luminous 以下版本的用戶端： 

    cephuser@adm > ceph osd set-require-min-compat-client luminous

  5. 啟用平衡器模組： 

    cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on

    如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 29 “Ceph 管理員模組”, Section 29.1 “平衡器”。

  6. (選擇性) 啟用遙測模組： 

    cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on

    如需更多詳細資料，請參閱Book “操作和管理指南”, Chapter 29 “Ceph 管理員模組”, Section 29.2 “啟用遙測模組”。

A 以上游「Octopus」小數點版本為基礎的 Ceph 維護更新

 

SUSE Enterprise Storage 7 中的幾個關鍵套件均以 Ceph 的 Octopus 版本系列為基礎。當 Ceph 專案 (https://github.com/ceph/ceph) 在 Octopus 系列中發佈新的小數點版本時，SUSE Enterprise Storage 7 即會更新，以確保產品套用最新的上游錯誤修復並可進行功能向後移植。

本章簡要介紹有關已經或計劃在產品中包含的每個上游小數點版本中的重要變更。

Octopus 15.2.5 小數點版本

Octopus 15.2.5 小數點版本引入了以下修復和其他變更：

  • CephFS：現在可以使用目錄上新的分散式和隨機暫時關聯延伸屬性來設定自動靜態子樹分割規則。如需詳細資訊，請參閱以下文件：https://docs.ceph.com/docs/master/cephfs/multimds/

  • 監控程式現有一個組態選項 mon_osd_warn_num_repaired，該選項預設設定為 10。如果任何 OSD 修復的儲存資料中的 I/O 錯誤數超過此數量，則會產生 OSD_TOO_MANY_REPAIRS 狀況警告。

  • 現在，如果在全域或在池層級設定了 no scrub 和/或 no deep-scrub 旗標，將中止已停用類型的排程整理。所有使用者啟動的整理將不會中斷。

  • 修復了在狀態良好的叢集中不會修剪 osdmaps 的問題。

Octopus 15.2.4 小數點版本

Octopus 15.2.4 小數點版本引入了以下修復和其他變更：

  • CVE-2020-10753：rgw: 處理 s3 CORSConfiguration 的 ExposeHeader 中的換行

  • 物件閘道：處理未同步分割區的 radosgw-admin 子指令 (radosgw-admin orphans find、radosgw-admin orphans finish 和 radosgw-admin orphans list-jobs) 已被取代。並不會主動維護這些子指令，並且由於它們會在叢集上儲存中間結果，因此可能會填入幾乎已滿的叢集。這些子指令已被工具 rgw-orphan-list 取代，該工具目前被視為是實驗性工具。

  • RBD：用於儲存 RBD 垃圾桶清除排程的 RBD 池物件的名稱已由 rbd_trash_trash_purge_schedule 變更為 rbd_trash_purge_schedule。已開始使用 RBD 垃圾桶清除排程功能並設定了每個池或名稱空間排程的使用者，應在升級前將 rbd_trash_trash_purge_schedule 物件複製到 rbd_trash_purge_schedule，並在先前設定了垃圾桶清除排程的每個 RBD 池和名稱空間中使用以下指令移除 rbd_trash_purge_schedule： 

    rados -p pool-name [-N namespace] cp rbd_trash_trash_purge_schedule rbd_trash_purge_schedule
rados -p pool-name [-N namespace] rm rbd_trash_trash_purge_schedule

    或者，使用任何其他簡便方法在升級後還原排程。

Octopus 15.2.3 小數點版本

  • Octopus 15.2.3 小數點版本是一個 Hotfix 版本，用於解決在同時啟用 bluefs_preextend_wal_files 和 bluefs_buffered_io 時發生的 WAL 損毀問題。15.2.3 中的修復只是一種暫時性措施 (將 bluefs_preextend_wal_files 的預設值變更為 false)。永久性的修復將是完全移除 bluefs_preextend_wal_files 選項：此修復很可能會在 15.2.6 小數點版本中實現。

Octopus 15.2.2 小數點版本

Octopus 15.2.2 小數點版本修補了一個安全性弱點：

  • CVE-2020-10736：修復了 MON 和 MGR 中的授權繞過問題

Octopus 15.2.1 小數點版本

Octopus 15.2.1 小數點版本修復了從 Luminous (SES5.5) 到 Nautilus (SES6) 再到 Octopus (SES7) 的快速升級導致 OSD 當機的問題。此外，它還修補了 Octopus (15.2.0) 初始版本中存在的兩個安全性弱點：

  • CVE-2020-1759：修復了 msgrv2 安全模式下的 nonce 重複使用

  • CVE-2020-1760：修復了由於 RGW GetObject 標題分割而導致的 XSS

B 文件更新

 

本章列出了本文件中適用於目前 SUSE Enterprise Storage 版本的內容變更。

  • Ceph Dashboard 章節 (Book “操作和管理指南”) 在手冊階層中上移了一級，以便可以直接在目錄中搜尋其詳細主題。

  • Book “操作和管理指南”的結構已更新，以與目前的指南範圍相符。一些章節被移至其他指南 (jsc#SES-1397)。

辭彙表

 

一般

Alertmanager

用於處理 Prometheus 伺服器傳送的警示並通知最終使用者的單個二進位檔案。

Ceph Dashboard

一種內建的基於 Web 的 Ceph 管理和監控應用程式，負責管理叢集的各個方面和物件。儀表板做為 Ceph 管理員模組實作。

Ceph OSD 精靈

ceph-osd 精靈是 Ceph 的元件，負責在本地檔案系統上儲存物件，並在網路中提供對它們的存取。

Ceph 儲存叢集

用於儲存使用者資料的儲存軟體的核心集合。此類集合由 Ceph 監控程式和 OSD 組成。

Ceph 物件儲存

物件儲存「產品」、服務或功能，由 Ceph 儲存叢集和 Ceph 物件閘道組成。

Ceph 用戶端

可以存取 Ceph 儲存叢集的 Ceph 元件集合。其中包括物件閘道、Ceph 區塊裝置、CephFS 及其相應的程式庫、核心模組和 FUSE 用戶端。

Ceph 監控程式

Ceph 監控程式或 MON 是 Ceph 監控程式軟體。

Ceph 管理員

Ceph 管理員或 MGR 是 Ceph 管理員軟體，會將整個叢集的所有狀態收集到一處。

ceph-salt

提供使用 Salt 部署由 cephadm 管理的 Ceph 叢集的工具。

cephadm

cephadm 用於部署和管理 Ceph 叢集，它會透過 SSH 從管理員精靈連接至主機以新增、移除或更新 Ceph 精靈容器。

CephFS

Ceph 檔案系統。

CephX

Ceph 驗證通訊協定。Cephx 操作與 Kerberos 類似，但它沒有單一故障點。

CRUSH 規則

適用於某個特定池或多個池的 CRUSH 資料放置規則。

CRUSH、CRUSH 地圖

基於可延展雜湊的受控複製：透過計算資料儲存位置來確定如何儲存和擷取資料的演算法。CRUSH 需要獲取叢集的地圖來以虛擬隨機的方式在 OSD 中儲存和擷取資料，並以一致的方式在整個叢集中分散資料。

DriveGroups

DriveGroups 是可對應至實體磁碟機的一或多個 OSD 配置的宣告。OSD 配置定義了 Ceph 如何在符合指定準則的媒體上實際配置 OSD 儲存。

Grafana

資料庫分析和監控解決方案。

OSD

物件儲存裝置：一個實體或邏輯儲存單位。

OSD 節點

一個叢集節點，用於儲存資料、處理資料複製、復原、回填、重新平衡，以及透過檢查其他 Ceph OSD 精靈為 Ceph 監控程式提供某些監控資訊。

Prometheus

系統監控和警示工具套件。

RADOS 區塊裝置 (RBD)

Ceph 的區塊儲存元件。也稱為 Ceph 區塊裝置。

Samba

Windows 整合式軟體。

Samba 閘道

Samba 閘道加入到 Windows 網域中的 Active Directory，以進行使用者驗證和授權。

中繼資料伺服器

中繼資料伺服器或 MDS 是 Ceph 中繼資料軟體。

儲存池

用於儲存物件 (例如磁碟影像) 的邏輯分割區。

區域群組
可靠自主分散式物件儲存 (RADOS)

用於儲存使用者資料的儲存軟體的核心集合 (MON+OSD)。

多區域
小數點版本

任何只包含錯誤或安全修復的臨機操作版本。

放置群組

放置群組：池的細分，用於進行效能調整。

桶

將其他節點聚合成實體位置階層的一個點。

歸檔同步模組

允許建立物件閘道區域以保留 S3 物件版本歷程的模組。

物件閘道

Ceph 物件儲存的 S3/Swift 閘道元件。也稱為 RADOS 閘道 (RGW)。

管理節點

在其上執行與 Ceph 相關的指令以管理叢集主機的主機。

節點

Ceph 叢集中的任何一部機器或伺服器。

規則集

用於確定池的資料放置的規則。

路由樹狀結構

該術語指的是展示接收器可執行的不同路由的任何圖表。