13 操作任務 #
13.1 修改叢集組態 #
若要修改現有 Ceph 叢集的組態,請執行以下步驟:
將叢集的目前組態輸出至檔案:
cephuser@adm >
ceph orch ls --export --format yaml > cluster.yaml編輯包含組態的檔案並更新相關行。可在第 5.4 節 「部署服務和閘道」和第 13.4.3 節 「使用 DriveGroups 規格新增 OSD。」中找到規格範例。
套用新組態:
cephuser@adm >
ceph orch apply -i cluster.yaml
13.2 新增節點 #
若要向 Ceph 叢集新增新的節點,請執行以下步驟:
在新主機上安裝 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage。如需相關資訊,請參閱第 5.1 節 「安裝和設定 SUSE Linux Enterprise Server」。
將主機設定為已存在 Salt Master 的 Salt Minion。如需相關資訊,請參閱第 5.2 節 「部署 Salt」。
將新主機新增至
ceph-salt
並讓 cephadm 能識別它,例如:root@master #
ceph-salt config /ceph_cluster/minions add ses-min5.example.comroot@master #
ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com如需相關資訊,請參閱第 5.3.2.2 節 「新增 Salt Minion」。
確認節點是否已新增至
ceph-salt
:root@master #
ceph-salt config /ceph_cluster/minions ls o- minions ................................................. [Minions: 5] [...] o- ses-min5.example.com .................................... [no roles]將組態套用於新叢集主機:
root@master #
ceph-salt apply ses-min5.example.com確認新增的主機現在是否屬於 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 的更多詳細資料,請參閱第 13.4.4 節 「移除 OSD」。
若要從叢集移除節點,請執行以下操作:
對於除
node-exporter
和crash
以外的所有 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從 cephadm 的環境中移除節點:
cephuser@adm >
ceph orch host rm ses-min2如果節點正在執行
crash.osd.1
和crash.osd.2
服務,請透過在主機上執行以下指令將其移除:root@minion >
cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME例如:
root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2從您要刪除的 Minion 中移除所有角色:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/admin remove ses-min2如果您要移除的 Minion 是開機 Minion,則還需要移除開機角色:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/bootstrap reset移除單部主機上的所有 OSD 後,從 CRUSH 地圖中移除該主機:
cephuser@adm >
ceph osd crush remove bucket-name注意桶名稱應該與主機名稱相同。
現在您便可以從叢集中移除 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 -idrive_groups.yml
若要查看動作預覽並測試您的應用程式,您可以將 --dry-run
選項與 ceph orch apply osd
指令結合使用。例如:
cephuser@adm >
ceph orch apply osd -idrive_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 的磁碟。
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 設定的範例。
下面的範例描述了使用相同設定的兩個節點:
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'
下面的範例描述了兩種不同的設定: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
上述範例假設所有節點的磁碟機都相同,但情況並非總是如此:
節點 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
上述所有案例都假設 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
在以下設定中,我們嘗試定義:
由 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 會導致整個叢集進行重新平衡。
透過獲取其 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 ...從叢集中移除一或多個 OSD:
cephuser@adm >
ceph orch osd rm OSD1_ID OSD2_ID ...例如:
cephuser@adm >
ceph orch osd rm 1 2您可以查詢移除操作的狀態:
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 主機,請執行以下步驟:
輸出叢集組態並備份輸出的 JSON 檔案。如需更多詳細資料,請參閱第 5.3.2.15 節 「輸出叢集組態」。
如果舊的 Salt Master 也是叢集中的唯一管理節點,則需要將
/etc/ceph/ceph.client.admin.keyring
和/etc/ceph/ceph.conf
手動移至新 Salt Master。停止並停用舊 Salt Master 節點上的 Salt Master
systemd
服務:root@master #
systemctl stop salt-master.serviceroot@master #
systemctl disable salt-master.service如果舊 Salt Master 節點不再位於叢集中,還要停止並停用 Salt Minion
systemd
服務:root@master #
systemctl stop salt-minion.serviceroot@master #
systemctl disable salt-minion.service警告如果舊 Salt Master 節點上有任何執行中 Ceph 精靈 (MON、MGR、OSD、MDS、閘道、監控),請不要停止或停用
salt-minion.service
。依據第 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.pubroot@minion >
systemctl restart salt-minion.service將 salt-master 套件和 salt-minion 套件 (如適用) 安裝到新的 Salt Master。
在新的 Salt Master 節點上安裝
ceph-salt
:root@master #
zypper install ceph-saltroot@master #
systemctl restart salt-master.serviceroot@master #
salt '*' saltutil.sync_all重要確定在繼續之前執行所有三個指令。這些指令是等冪的;是否重複並不重要。
在叢集中包含新的 Salt Master,如第 5.3.1 節 「安裝
ceph-salt
」、第 5.3.2.2 節 「新增 Salt Minion」和第 5.3.2.4 節 「指定管理節點」中所述。輸入備份的叢集組態並套用該組態:
root@master #
ceph-salt import CLUSTER_CONFIG.jsonroot@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」儲存庫的階段都是在同一時刻建立的。
強烈建議您使用暫存工具來套用修補程式層級為 frozen
或 staged
的修補程式。這樣可確保加入叢集的新節點具有與已在叢集中執行的節點相同的修補程式層級。透過這種方法,您無需向叢集的所有節點都套用最新修補程式,新節點也能加入叢集。
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 將叢集停止或重新開機 #
在某些情況下,可能需要將整個叢集停止或重新開機。建議您仔細檢查執行中服務的相依項。下列步驟簡要說明如何停止和啟動叢集:
告知 Ceph 叢集不要將 OSD 標示為 out:
cephuser@adm >
ceph
osd set noout依下面的順序停止精靈和節點:
儲存用戶端
閘道,例如 NFS Ganesha 或物件閘道
中繼資料伺服器
Ceph OSD
Ceph 管理員
Ceph 監控程式
視需要執行維護任務。
依與關閉過程相反的順序啟動節點和伺服器:
Ceph 監控程式
Ceph 管理員
Ceph OSD
中繼資料伺服器
閘道,例如 NFS Ganesha 或物件閘道
儲存用戶端
移除 noout 旗標:
cephuser@adm >
ceph
osd unset noout
13.9 移除整個 Ceph 叢集 #
ceph-salt purge
指令可移除整個 Ceph 叢集。如果部署了更多的 Ceph 叢集,則將清除 ceph -s
報告的叢集。這樣,您便可以在測試不同的設定時清理叢集環境。
為防止意外刪除,協調程序會檢查是否解除了安全措施。您可以透過執行以下指令來解除安全措施並移除 Ceph 叢集:
root@master #
ceph-salt disengage-safetyroot@master #
ceph-salt purge