新鈦雲服已累計為您分享848篇技術乾貨
Ceph 提供了物件儲存分層功能，透過在不同儲存類別之間無縫遷移資料來最佳化成本和效能。這些層級可以在本地基礎設施內配置，也可以擴充套件到基於雲的儲存類別，從而為多樣化的工作負載提供靈活且可擴充套件的解決方案。藉助基於策略的自動化功能，管理員可以定義生命週期策略，將資料從高效能儲存遷移到經濟高效的歸檔層級，確保在速度、永續性和成本效益之間取得最佳平衡。
Ceph 的本地儲存類別允許配置在本地 Ceph 叢集內，將資料在快速的 NVMe 或 SAS/SATA SSD 儲存池與經濟型的 HDD 或 QLC 儲存池之間進行分層儲存。這對於需要不同效能級別的應用程式或資料“老化”後不再需要高效能的場景尤為有益，此時可以將資料遷移到速度較慢但更經濟的儲存中。
除了本地分層儲存外，Ceph 還提供了基於策略的資料歸檔和檢索功能，能夠與 S3 相容平臺整合，實現異地資料管理。組織可以利用此功能將資料歸檔到基於雲的儲存層級，例如 IBM Cloud Object Storage、AWS S3、Azure Blob 或 S3 磁帶端點，以實現長期保留、災難恢復或成本最佳化的冷儲存。透過基於策略的自動化功能，Ceph 確保資料能夠根據預定義的生命週期規則遷移到雲端或其他目標位置，從而增強其在混合雲策略中的價值。
最初，Ceph 基於策略的資料歸檔（雲同步）功能僅支援單向資料流，即資料只能從本地儲存池歸檔到指定的雲端儲存層級。雖然這使使用者能夠利用經濟高效的雲平臺進行冷儲存或長期資料保留，但缺乏資料檢索能力限制了該解決方案在資料管理中的靈活性。這意味著，一旦資料被歸檔到雲端儲存，就無法再透過 Ceph 直接主動檢索或重新整合到本地工作流中。
Ceph Squid 引入了基於策略的資料檢索功能，這標誌著其能力的重大演進，目前作為技術預覽版提供。這一增強功能使使用者能夠將 S3 雲端儲存或磁帶儲存中的物件直接檢索回本地 Ceph 環境，消除了之前單向資料流的限制。資料可以作為臨時或永久物件進行恢復。
-
臨時恢復：恢復的資料會繞過生命週期雲遷移規則，並在指定時間後自動刪除，物件將恢復為之前的存根狀態。
-
永久恢復：這些物件會完全重新整合到 Ceph 叢集中，被視為（併成為）常規物件，並遵循標準的生命週期策略和複製流程。
物件檢索可以透過兩種不同的方式實現：
-
S3 RestoreObject API：允許使用者使用
S3RestoreObject API請求從遠端 S3 端點檢索物件。 -
讀取時透明檢索：支援對已遷移物件執行標準的 S3 GET 請求，從而透明地將物件恢復到 Ceph 叢集中。
在此版本中，我們不支援從使用不同 Glacier API（例如 IBM Deep Archive）的 S3 雲/磁帶端點檢索物件。此功能增強針對 Ceph 的 Tentacle 版本。
在本節中，我們將配置和設定 Ceph 的基於策略的資料歸檔功能。我們將討論使用資料生命週期策略，透過將冷資料歸檔到 IBM Cloud Object Storage (COS)，將其轉換為異地、經濟高效的儲存類。
Ceph 術語說明
-
區域組（Zonegroup）：通常位於同一地理區域（也稱為區域）的多個區域的集合。
-
區域（Zone）：包含物件閘道器（RGW）端點的一個或多個例項，屬於某個區域組。
-
放置（Placement）：在同一區域內對 RADOS 資料池進行邏輯分離。
-
儲存類別（Storage Class）：儲存類別用於自定義物件資料的放置位置，S3 儲存桶生命週期規則則用於自動化這些類別之間的資料遷移。
[!CAUTION]注意：此處描述的 RGW 儲存類別不應與 Kubernetes 的 PV/PVC 儲存類別混淆。
生命週期策略介紹
下表總結了 Ceph 物件閘道器支援的各種生命週期策略：
| 策略型別 | 描述 | 示例用例 |
|---|---|---|
| 過期（Expiration） | 在指定時間後刪除物件 | 30 天后自動刪除臨時檔案 |
| 非當前版本過期（Concurrent Version Expiration） | 在版本化儲存桶中，刪除指定時間後的非當前版本物件 | 透過刪除舊版本物件來管理儲存成本 |
| 中止未完成的分段上傳（Abort Incomplete Multipart Upload） | 取消未在指定時間內完成的分段上傳 | 透過清理未完成的上傳來釋放儲存空間 |
| 儲存類別間遷移（Transition Between Storage Classes） | 在指定時間後，將物件在同一 Ceph 叢集內的不同儲存類別之間遷移 | 90 天后將資料從 SSD/複製儲存遷移到 HDD/糾刪碼（EC）儲存 |
| 較新非當前版本過濾器（NewerNoncurrentVersions Filter） | 過濾比指定數量更新的非當前版本，用於過期或遷移操作 | 僅保留物件的最後三個非當前版本 |
| 物件大小大於過濾器（ObjectSizeGreaterThan Filter） | 僅對大於指定大小的物件應用生命週期規則 | 將大型影片檔案遷移到成本較低的儲存類別 |
| 物件大小小於過濾器（ObjectSizeLess Filter） | 僅對小於指定大小的物件應用生命週期規則 | 在一定時間後將小型日誌檔案歸檔 |
除了指定策略外，生命週期規則還可以使用標籤（tags）或字首（prefixes）進行過濾，從而更精細地控制哪些物件受到影響。標籤可以根據每個物件的標籤標識特定物件子集，而字首則有助於根據物件鍵名（key names）定位物件。
配置遠端雲服務進行分層
首先，我們將遠端 S3 雲服務配置為本地遷移物件的未來目標。在本示例中，我們將建立一個名為
ceph-s3-tier 的 IBM COS 儲存桶。值得注意的是，我們需要為我們的儲存桶建立一個啟用了 HMAC 金鑰的服務憑證。
為 Cloud-S3 分層建立新的儲存類
在預設區域組內的預設位置上建立新的儲存類；我們使用
rgw-admin --tier-type=cloud-s3引數來根據我們之前在 COS S3 中配置的儲存桶來配置儲存類別。# radosgw-admin zonegroup placement add --rgw-zonegroup=default--placement-id=default-placement --storage-class=ibm-cos --tier-type=cloud-s3[!CAUTION]注意：Ceph 允許使用任意名稱建立儲存類別，但某些客戶端和客戶端庫僅接受 AWS 儲存類別名稱，或者在儲存類別為GLACIER等特定名稱時表現出獨特的行為。
我們可以驗證預設區域組和放置目標中的可用儲存類：
# radosgw-admin zonegroup get --rgw-zonegroup=default | jq .placement_targets[0].storage_classes["STANDARD_IA","STANDARD","ibm-cos"]配置具有分層設定的 Cloud-S3 儲存類別
接下來，我們使用
radosgw-admin 命令配置 cloud-s3儲存類別，並指定 IBM COS 儲存桶的相關引數：端點（endpoint）、區域（region）和賬戶憑證（credentials）。# radosgw-admin zonegroup placement modify --rgw-zonegroup default --placement-id default-placement --storage-classibm-cos --tier-config=endpoint=https://s3.eu-de.cloud-object-storage.appdomain.cloud,access_key=YOUR_ACCESS_KEY,secret=YOUR_SECRET_KEY,target_path="ceph-s3-tier",multipart_sync_threshold=44432,multipart_min_part_size=44432,retain_head_object=true,region=eu-de應用生命週期策略
一旦 COS cloud-S3 儲存類就位，我們將把使用者切換為 Ceph Object S3 API 的使用者，並透過 RGW S3 API 端點配置生命週期策略。我們的使用者名稱為
tiering ，並且我們已使用分層使用者的憑據預先配置了 S3 AWC CLI。 aws --profile tiering --endpoint https://s3.cephlabs.com s3 mb s3://databucket aws --profile tiering --endpoint https://s3.cephlabs.com s3 /etc/hosts s3://databucket我們將把一個 JSON 生命週期策略附加到之前建立的儲存桶中。例如，儲存桶
databucket將具有以下策略，將所有超過 30 天的物件轉換為 COS 儲存類別：{"Rules":[{"ID":"Transition objects from Ceph to COS that are older than 30 days","Prefix":"","Status":"Enabled","Transitions":[{"Days":30,"StorageClass":"ibm-cos"}]}]}作為 S3 API 使用者，我們將使用 AWS S3 CLI 將儲存桶生命週期配置應用到名為
ibm-cos-lc.json的本地檔案中： aws --profile tiering --endpoint https://s3.cephlabs.com s3api put-bucket-lifecycle-configuration --lifecycle-configuration file://ibm-cos-lc.json --bucket databucket驗證該策略是否已應用：
aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-bucket-lifecycle-configuration --bucket databucket我們還可以透過以下
radosgw-admin 命令檢查 Ceph/RGW 是否已註冊此新的生命週期（LC）策略。狀態顯示為 UNINITIAL，因為此生命週期策略尚未被處理；一旦處理完成，狀態將變為 COMPLETED：# radosgw-admin lc list | jq .[1]{"bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1","shard": "lc.23","started": "Thu, 01 Jan 1970 00:00:00 GMT","status": "UNINITIAL"}我們可以使用以下命令獲取應用於儲存桶的規則的更多詳細資訊：
# radosgw-admin lc get --bucket databucket{"prefix_map": {"": {"status": true,"dm_expiration": false,"expiration": 0,"noncur_expiration": 0,"mp_expiration": 0,"transitions": {"ibm-cos": {"days": 30 } }, } }}測試配置的生命週期策略
[!WARNING]更改此引數僅用於 LC 測試目的。不要在生產 Ceph 叢集上更改它，並記住適當重置！
我們可以透過為生命週期程序啟用除錯間隔來加速生命週期策略的測試。在此設定中，儲存桶生命週期配置中的每“天”相當於 60 秒，因此三天的過期時間實際上僅為三分鐘：
# ceph config set client.rgw rgw_lc_debug_interval 60# ceph orch restart rgw.default如果我們現在執行
radosgw-admin lc list我們應該會看到轉換儲存桶的生命週期策略處於已完成狀態：[]{"bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1","shard": "lc.23","started": "Mon, 25 Nov 2024 10:43:31 GMT","status": "COMPLETE"}如果我們在本地叢集中列出過渡儲存桶中的可用物件，可以看到物件大小為 0。這是因為它們已被遷移到雲端。然而，由於在建立雲端儲存類別時使用了
"retain_head_object": "true"引數，物件的元資料/頭部資訊仍然保留在本地：# aws --profile tiering --endpoint https://s3.cephlabs.com s3 ls s3://databucket2024-11-2505:41:330 hosts如果我們使用
s3api get-object-attributes呼叫檢查物件屬性，我們可以看到該物件的儲存類現在是ibm-cos ，因此該物件已成功轉換到 S3 雲提供商：# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object-attributes --object-attributes StorageClass ObjectSize --bucket databucket --key hosts{ "LastModified": "2024-11-25T10:41:33+00:00","StorageClass": "ibm-cos","ObjectSize": 0}如果我們使用 AWS CLI S3 客戶端（但使用 IBM COS 使用者的端點和配置檔案）在 IBM COS 中檢查，可以看到物件已存在於 IBM COS 儲存桶中。由於 API 限制，原始物件的修改時間和 ETag 無法保留，但它們會作為元資料屬性儲存在目標物件上。
aws --profile cos --endpoint https://s3.eu-de.cloud-object-storage.appdomain.cloud s3api head-object --bucket ceph-s3-tier --key databucket/hosts | jq .{ "AcceptRanges": "bytes","LastModified": "2024-11-25T10:41:33+00:00","ContentLength": 304,"ETag": "\"01a72b8a9d073d6bcae565bd523a76c5\"","ContentType": "binary/octet-stream","Metadata": { "rgwx-source-mtime": "1732529733.944271939","rgwx-versioned-epoch": "0","rgwx-source": "rgw","rgwx-source-etag": "01a72b8a9d073d6bcae565bd523a76c5","rgwx-source-key": "hosts" }}為了避免儲存桶之間的衝突，源儲存桶名稱會新增到目標物件名稱之前。如果物件有版本控制，則物件版本 ID 會附加到末尾。
以下是物件名稱格式示例：
s3://<target_path>/<source_bucket_name>/<source_object_name>(-<source_object_version_id>)以下對版本化和鎖定物件應用了與 LifecycleExpiration類似的語義。如果物件在遷移到雲端後是當前版本，則會將其標記為非當前版本，並建立一個刪除標記。如果物件是非當前版本且被鎖定，則跳過其遷移過程。
本篇部落格介紹瞭如何透過分層和生命週期策略將冷資料遷移到更具成本效益的儲存類別，並將其歸檔到 IBM Cloud Object Storage (COS)。在下一篇部落格中，我們將探討如何在需要時將歸檔資料恢復到 Ceph 叢集。我們將介紹關鍵的技術概念，並提供詳細的配置步驟，幫助使用者實現雲恢復，確保在需要時能夠訪問冷資料。
如有相關問題，請在文章後面給小編留言，小編安排作者第一時間和您聯絡，為您答疑解惑。
原文： https://ceph.io/en/news/blog/2025/rgw-tiering-enhancements-part2/
推薦閱讀
推薦影片