跳至內容跳至頁面導覽:上一頁 [access key p]/下一頁 [access key n]
documentation.suse.com / SUSE Enterprise Storage 7 文件 / 操作和管理指南 / 叢集操作 / 操作任務
適用範圍 SUSE Enterprise Storage 7

13 操作任務

13.1 修改叢集組態

若要修改現有 Ceph 叢集的組態,請執行以下步驟:

  1. 將叢集的目前組態輸出至檔案:

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. 編輯包含組態的檔案並更新相關行。可在第 5.4 節 「部署服務和閘道」第 13.4.3 節 「使用 DriveGroups 規格新增 OSD。」中找到規格範例。

  3. 套用新組態:

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

13.2 新增節點

若要向 Ceph 叢集新增新的節點,請執行以下步驟:

  1. 在新主機上安裝 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage。如需相關資訊,請參閱第 5.1 節 「安裝和設定 SUSE Linux Enterprise Server」

  2. 將主機設定為已存在 Salt Master 的 Salt Minion。如需相關資訊,請參閱第 5.2 節 「部署 Salt」

  3. 將新主機新增至 ceph-salt 並讓 cephadm 能識別它,例如:

    root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.com
    root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

    如需相關資訊,請參閱第 5.3.2.2 節 「新增 Salt Minion」

  4. 確認節點是否已新增至 ceph-salt

    root@master # ceph-salt config /ceph_cluster/minions ls
    o- minions ................................................. [Minions: 5]
    [...]
      o- ses-min5.example.com .................................... [no roles]
  5. 將組態套用於新叢集主機:

    root@master # ceph-salt apply ses-min5.example.com
  6. 確認新增的主機現在是否屬於 cephadm 環境:

    cephuser@adm > ceph orch host ls
    HOST                   ADDR                    LABELS   STATUS
    [...]
    ses-min5.example.com   ses-min5.example.com

13.3 移除節點

提示
提示:移除 OSD

如果您要移除的節點執行有 OSD,請先從中移除 OSD,然後檢查該節點上是否未執行任何 OSD。如需移除 OSD 的更多詳細資料,請參閱第 13.4.4 節 「移除 OSD」

若要從叢集移除節點,請執行以下操作:

  1. 對於除 node-exportercrash 以外的所有 Ceph 服務類型,請從叢集放置規格檔案 (例如 cluster.yml) 中移除節點的主機名稱。如需更多詳細資料,請參閱第 5.4.2 節 「服務和放置規格」。例如,如果您要移除名為 ses-min2 的主機,請從所有 placement: 區段中移除所有出現的 - ses-min2

    更新

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min2
      - ses-min3

    針對

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min3

    將您的變更套用於組態檔案:

    cephuser@adm > ceph orch apply -i rgw-example.yaml
  2. 從 cephadm 的環境中移除節點:

    cephuser@adm > ceph orch host rm ses-min2
  3. 如果節點正在執行 crash.osd.1crash.osd.2 服務,請透過在主機上執行以下指令將其移除:

    root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

    例如:

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. 從您要刪除的 Minion 中移除所有角色:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

    如果您要移除的 Minion 是開機 Minion,則還需要移除開機角色:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
  5. 移除單部主機上的所有 OSD 後,從 CRUSH 地圖中移除該主機:

    cephuser@adm > ceph osd crush remove bucket-name
    注意
    注意

    桶名稱應該與主機名稱相同。

  6. 現在您便可以從叢集中移除 Minion:

    cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
重要
重要

如果發生故障,並且您嘗試移除的 Minion 處於永久關閉電源狀態,則需要從 Salt Master 中移除節點:

root@master # salt-key -d minion_id

然後,手動從 pillar_root/ceph-salt.sls 中移除節點。它通常位於 /srv/pillar/ceph-salt.sls 中。

13.4 OSD 管理

本節介紹如何在 Ceph 叢集中新增、去除或移除 OSD。

13.4.1 列出磁碟裝置

若要識別所有叢集節點上已使用和未使用的磁碟裝置,請透過執行以下指令列出這些裝置:

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 去除磁碟裝置

若要重新使用磁碟裝置,需要先將其去除 (或清除):

ceph orch device zap HOST_NAME DISK_DEVICE

例如:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc
注意
注意

如果您先前在未設定 unmanaged 旗標的情況下使用 DriveGroups 或 --all-available-devices 選項部署了 OSD,cephadm 將在您去除這些 OSD 後再自動部署它們。

13.4.3 使用 DriveGroups 規格新增 OSD。

DriveGroups 用於指定 Ceph 叢集中 OSD 的配置。它們在單個 YAML 檔案中定義。在本節中,我們將使用 drive_groups.yml 做為範例。

管理員應手動指定一組相關的 OSD (部署在 HDD 和 SDD 組合上的混合 OSD),或一組使用相同部署選項的 OSD (例如,物件儲存、加密選項相同的各獨立 OSD)。為了避免明確列出裝置,DriveGroups 會使用與 ceph-volume 庫存報告中的幾個所選欄位對應的過濾項目清單。cephadm 將提供一些代碼,用於將這些 DriveGroups 轉換為供使用者檢查的實際裝置清單。

將 OSD 規格套用於叢集的指令是:

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

若要查看動作預覽並測試您的應用程式,您可以將 --dry-run 選項與 ceph orch apply osd 指令結合使用。例如:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

如果 --dry-run 輸出符合您的預期,則只需重新執行指令而無需使用 --dry-run 選項。

13.4.3.1 未受管理 OSD

將符合 DriveGroups 規格的所有可用的乾淨磁碟裝置新增至叢集後,它們將自動做為 OSD 使用。此行為稱為受管理模式。

若要停用受管理模式,請將 unmanaged: true 行新增至相關規格,例如:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true
提示
提示

若要將已部署的 OSD 從受管理模式變更為未受管理模式,請於執行第 13.1 節 「修改叢集組態」中所述的程序期間在適當位置新增 unmanaged: true 行。

13.4.3.2 DriveGroups 規格

下面是 DriveGroups 規格檔案的範例:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')
注意
注意

先前在 DeepSea 中名為「加密」的選項已被重新命名為「已加密」。在 SUSE Enterprise Storage 7 中套用 DriveGroups 時,請確定在服務規格中使用此新術語,否則 ceph orch apply 操作將失敗。

13.4.3.3 相符磁碟裝置

您可以使用以下過濾器描述規格:

  • 依磁碟型號:

    model: DISK_MODEL_STRING
  • 依磁碟廠商:

    vendor: DISK_VENDOR_STRING
    提示
    提示

    永遠以小寫形式輸入 DISK_VENDOR_STRING

    若要獲取有關磁碟型號和廠商的詳細資料,請檢查以下指令的輸出:

    cephuser@adm > ceph orch device ls
    HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
    ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
    ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
    [...]
  • 磁碟是否為旋轉式硬碟。SSD 和 NVMe 磁碟機不屬於旋轉式硬碟。

    rotational: 0
  • 部署將全部可用磁碟機皆用於 OSD 的節點:

    data_devices:
      all: true
  • 此外,還可透過限制相符磁碟的數量來過濾:

    limit: 10

13.4.3.4 依大小過濾裝置

您可以依磁碟裝置大小對其過濾,可以依確切大小也可以依大小範圍來過濾。size: 參數接受使用下列格式的引數:

  • '10G' - 包括大小為該值的磁碟。

  • '10G:40G' - 包括大小在該範圍內的磁碟。

  • ':10G' - 包括大小小於或等於 10 GB 的磁碟。

  • '40G:' - 包括大小等於或大於 40 GB 的磁碟。

範例 13.1︰ 依磁碟大小比對
service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'
注意
注意:需要引號

如果使用「:」分隔符,您需要使用引號括住大小,否則系統會將「:」符號解譯為新組態雜湊。

提示
提示:單位捷徑

您可以指定以百萬位元組 (M) 或兆位元組 (T) 計的大小,而不能指定以十億位元組 (G) 計的大小。

13.4.3.5 DriveGroups 範例

本節包含其他 OSD 設定的範例。

範例 13.2︰ 簡單設定

下面的範例描述了使用相同設定的兩個節點:

  • 20 個 HDD

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 2 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

對應的 drive_groups.yml 檔案如下所示:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

這樣的組態簡單有效。但問題是管理員將來可能要新增來自不同廠商的磁碟,而這樣的磁碟不在可新增範圍內。您可以透過減少針對磁碟機核心內容的過濾器來予以改進。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

在上面的範例中,我們強制將所有旋轉式裝置宣告為「data devices」,將所有非旋轉式裝置當成「shared devices」(wal、db) 使用。

如果您知道大小超過 2 TB 的磁碟機將一律做為較慢的資料裝置,則可以依大小過濾:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'
範例 13.3︰ 進階設定

下面的範例描述了兩種不同的設定:20 個 HDD 將共用 2 個 SSD,而 10 個 SSD 將共用 2 個 NVMe。

  • 20 個 HDD

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 12 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

  • 2 個 NVMe

    • 廠商:Samsung

    • 型號:NVME-QQQQ-987

    • 大小:256 GB

這樣的設定可使用如下兩個配置定義:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB
範例 13.4︰ 包含非統一節點的進階設定

上述範例假設所有節點的磁碟機都相同,但情況並非總是如此:

節點 1-5:

  • 20 個 HDD

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 2 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

節點 6-10:

  • 5 個 NVMe

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 20 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

您可以在配置中使用「target」鍵來定位特定節點。Salt 定位標記可讓事情變得簡單:

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

後接

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
範例 13.5︰ 專家設定

上述所有案例都假設 WAL 和 DB 使用相同裝置,但也有可能會在專屬裝置上部署 WAL:

  • 20 個 HDD

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 2 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

  • 2 個 NVMe

    • 廠商:Samsung

    • 型號:NVME-QQQQ-987

    • 大小:256 GB

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987
範例 13.6︰ 複雜 (和不太可能的) 設定

在以下設定中,我們嘗試定義:

  • 由 1 個 NVMe 支援 20 個 HDD

  • 由 1 個 SSD (db) 和 1 個 NVMe (wal) 支援 2 個 HDD

  • 由 1 個 NVMe 支援 8 個 SSD

  • 2 個獨立 SSD (加密)

  • 1 個 HDD 做為備用,不應部署

共使用如下數量的磁碟機:

  • 23 個 HDD

    • 廠商:Intel

    • 型號:SSD-123-foo

    • 大小:4 TB

  • 10 個 SSD

    • 廠商:Micron

    • 型號:MC-55-44-ZX

    • 大小:512 GB

  • 1 個 NVMe

    • 廠商:Samsung

    • 型號:NVME-QQQQ-987

    • 大小:256 GB

DriveGroups 定義如下所示:

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

在檔案的整個剖析過程中,一直會保留一個 HDD。

13.4.4 移除 OSD

在從叢集中移除 OSD 節點之前,請確認該叢集中的可用磁碟空間是否比您要移除的 OSD 磁碟大。請注意,移除 OSD 會導致整個叢集進行重新平衡。

  1. 透過獲取其 ID 來識別要移除的 OSD:

    cephuser@adm > ceph orch ps --daemon_type osd
    NAME   HOST            STATUS        REFRESHED  AGE  VERSION
    osd.0  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.1  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.2  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.3  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
  2. 從叢集中移除一或多個 OSD:

    cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...

    例如:

    cephuser@adm > ceph orch osd rm 1 2
  3. 您可以查詢移除操作的狀態:

    cephuser@adm > ceph orch osd rm status
    OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
    2       cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
    3       cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
    4       cephadm-dev  started                  42        False    True   2020-07-17 13:01:45.162158

13.4.4.1 停止 OSD 移除

排程 OSD 移除後,您可以視需要停止移除。以下指令將重設 OSD 的初始狀態並將其從佇列中移除:

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 取代 OSD

若要在保留其 ID 的情況下取代 OSD,請執行:

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

例如:

cephuser@adm > ceph orch osd rm 4 --replace

取代 OSD 與移除 OSD 基本相同 (如需更多詳細資料,請參閱第 13.4.4 節 「移除 OSD」),只不過 OSD 不是從 CRUSH 階層中永久移除,而是被指定了一個 destroyed 旗標。

destroyed 旗標用於確定將在下一次 OSD 部署期間重複使用的 OSD ID。新增的符合 DriveGroups 規格的磁碟 (如需更多詳細資料,請參閱第 13.4.3 節 「使用 DriveGroups 規格新增 OSD。」) 將被指定其所取代之磁碟的 OSD ID。

提示
提示

附加 --dry-run 選項不會執行實際取代,而會預覽通常會發生的步驟。

13.5 將 Salt Master 移至新節點

如果需要以新 Salt Master 主機取代 Salt Master 主機,請執行以下步驟:

  1. 輸出叢集組態並備份輸出的 JSON 檔案。如需更多詳細資料,請參閱第 5.3.2.15 節 「輸出叢集組態」

  2. 如果舊的 Salt Master 也是叢集中的唯一管理節點,則需要將 /etc/ceph/ceph.client.admin.keyring/etc/ceph/ceph.conf 手動移至新 Salt Master。

  3. 停止並停用舊 Salt Master 節點上的 Salt Master systemd 服務:

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. 如果舊 Salt Master 節點不再位於叢集中,還要停止並停用 Salt Minion systemd 服務:

    root@master # systemctl stop salt-minion.service
    root@master # systemctl disable salt-minion.service
    警告
    警告

    如果舊 Salt Master 節點上有任何執行中 Ceph 精靈 (MON、MGR、OSD、MDS、閘道、監控),請不要停止或停用 salt-minion.service

  5. 依據第 5.1 節 「安裝和設定 SUSE Linux Enterprise Server」中所述的程序,在新的 Salt Master 上安裝 SUSE Linux Enterprise Server 15 SP2。

    提示
    提示:轉換 Salt Minion

    為便於將 Salt Minion 轉換為新的 Salt Master,請從每個 Salt Minion 中移除原始 Salt Master 的公用金鑰:

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  6. salt-master 套件和 salt-minion 套件 (如適用) 安裝到新的 Salt Master。

  7. 在新的 Salt Master 節點上安裝 ceph-salt

    root@master # zypper install ceph-salt
    root@master # systemctl restart salt-master.service
    root@master # salt '*' saltutil.sync_all
    重要
    重要

    確定在繼續之前執行所有三個指令。這些指令是等冪的;是否重複並不重要。

  8. 在叢集中包含新的 Salt Master,如第 5.3.1 節 「安裝 ceph-salt第 5.3.2.2 節 「新增 Salt Minion」第 5.3.2.4 節 「指定管理節點」中所述。

  9. 輸入備份的叢集組態並套用該組態:

    root@master # ceph-salt import CLUSTER_CONFIG.json
    root@master # ceph-salt apply
    重要
    重要

    輸入之前,請在輸出的 CLUSTER_CONFIG.json 檔案中重新命名 Salt Master 的 minion id

13.6 更新叢集節點

定期套用滾存更新,以使 Ceph 叢集節點保持最新。

13.6.1 軟體儲存庫

使用最新的套裝軟體修補叢集之前,請確認叢集的所有節點均可存取相關的儲存庫。如需所需儲存庫的完整清單,請參閱第 7.1.5.1 節 「軟體儲存庫」

13.6.2 儲存庫暫存

如果您使用向叢集節點提供軟體儲存庫的暫存工具 (例如 SUSE Manager、儲存庫管理工具或 RMT),請確認 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage 的「Updates」儲存庫的階段都是在同一時刻建立的。

強烈建議您使用暫存工具來套用修補程式層級為 frozenstaged 的修補程式。這樣可確保加入叢集的新節點具有與已在叢集中執行的節點相同的修補程式層級。透過這種方法,您無需向叢集的所有節點都套用最新修補程式,新節點也能加入叢集。

13.6.3 Ceph 服務停機時間

叢集節點可能會在更新期間重新開機,具體視組態而定。如果物件閘道、Samba 閘道、NFS Ganesha 或 iSCSI 等服務存在單一故障點,用戶端機器可能會暫時解除與相應節點正在重新開機的服務的連接。

13.6.4 執行更新

若要將所有叢集節點上的軟體套件更新至最新版本,請執行以下指令:

root@master # ceph-salt update

13.7 更新 Ceph

您可以指示 cephadm 將 Ceph 從一個錯誤修復版本更新至另一個版本。Ceph 服務的自動更新遵循建議的順序進行,即從 Ceph 管理員、Ceph 監控程式開始更新,然後繼續更新 Ceph OSD、中繼資料伺服器和物件閘道等其他服務。只有當 Ceph 指示叢集將仍然可用之後,才會重新啟動每個精靈。

注意
注意

以下更新程序使用 ceph orch upgrade 指令。請注意,以下說明詳細介紹了如何使用某個產品版本 (例如維護更新) 更新您的 Ceph 叢集,但提供如何將叢集從一個產品版本升級至另一個產品版本的說明。

13.7.1 啟動更新

開始更新之前,請確認所有節點目前都處於線上狀態,並且叢集狀況良好:

cephuser@adm > cephadm shell -- ceph -s

更新至某個特定的 Ceph 版本:

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

例如:

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7/ceph/ceph:latest

升級主機上的套件:

cephuser@adm > ceph-salt update

13.7.2 監控更新

執行以下指令可確定是否正在進行更新:

cephuser@adm > ceph orch upgrade status

如果正在進行更新,您將在 Ceph 狀態輸出中看到一個進度列:

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

您還可以查看 cephadm 記錄:

cephuser@adm > ceph -W cephadm

13.7.3 取消更新

您可以隨時停止更新程序:

cephuser@adm > ceph orch upgrade stop

13.8 將叢集停止或重新開機

在某些情況下,可能需要將整個叢集停止或重新開機。建議您仔細檢查執行中服務的相依項。下列步驟簡要說明如何停止和啟動叢集:

  1. 告知 Ceph 叢集不要將 OSD 標示為 out:

    cephuser@adm > ceph osd set noout
  2. 依下面的順序停止精靈和節點:

    1. 儲存用戶端

    2. 閘道,例如 NFS Ganesha 或物件閘道

    3. 中繼資料伺服器

    4. Ceph OSD

    5. Ceph 管理員

    6. Ceph 監控程式

  3. 視需要執行維護任務。

  4. 依與關閉過程相反的順序啟動節點和伺服器:

    1. Ceph 監控程式

    2. Ceph 管理員

    3. Ceph OSD

    4. 中繼資料伺服器

    5. 閘道,例如 NFS Ganesha 或物件閘道

    6. 儲存用戶端

  5. 移除 noout 旗標:

    cephuser@adm > ceph osd unset noout

13.9 移除整個 Ceph 叢集

ceph-salt purge 指令可移除整個 Ceph 叢集。如果部署了更多的 Ceph 叢集,則將清除 ceph -s 報告的叢集。這樣,您便可以在測試不同的設定時清理叢集環境。

為防止意外刪除,協調程序會檢查是否解除了安全措施。您可以透過執行以下指令來解除安全措施並移除 Ceph 叢集:

root@master # ceph-salt disengage-safety
root@master # ceph-salt purge