Ceph 對象存儲分層功能增強：基于策略的數據檢索

作者：祝祥 2025-08-06 08:03:23

為了彌補這些不足，我們在 Ceph 對象存儲生態系統中引入了基于策略的數據檢索功能。這一增強功能使管理員和運維團隊能夠將遷移到云或磁帶層級的對象直接檢索回 Ceph 集群，從而滿足操作效率和數據可訪問性的需求。

簡介和功能概述

在本系列的第一部分中，我們探討了 Ceph 對象存儲的基礎知識及其基于策略的云/磁帶歸檔功能，該功能能夠將數據無縫遷移到遠程 S3 兼容的存儲類別。這一功能對于將數據存儲到經濟高效的存儲層級（如云存儲或基于磁帶的系統）至關重要。然而，以往這一過程是單向的。一旦對象被遷移，檢索它們需要直接訪問云提供商的 S3 存儲。這一限制帶來了操作上的挑戰，尤其是在訪問歸檔或冷存儲數據時。

為什么這很重要？

基于策略的數據檢索功能顯著提升了 Ceph 中云遷移對象的可用性。無論數據是存儲在經濟的磁帶歸檔中，還是高延遲/低成本的云層級中，這一功能都確保用戶能夠無縫訪問和管理其對象，而無需依賴外部提供商的 S3 端點。這一能力簡化了工作流程，并增強了與操作策略和數據生命周期要求的合規性。

基于策略的數據檢索

這一新功能提供了兩種方法來檢索遷移到遠程云/磁帶 S3 的對象：

S3 RestoreObject API 實現：類似于 AWS S3 RestoreObject API，此功能允許用戶使用 S3 RestoreObject API 手動檢索對象。對象恢復操作可以是永久的或臨時的，具體取決于 RestoreObject API 調用中指定的保留期限。
直接讀取模式（Read-Through Mode）：通過引入可配置的 --allow-read-through 功能，Ceph 可以處理對云層級存儲類別中遷移對象的讀取請求。在收到 GET 請求時，系統會異步從云層級檢索對象，將其存儲在本地，并將數據提供給用戶。這消除了之前對云遷移對象遇到的 InvalidObjectState 錯誤。

圖片

S3 RestoreObject 臨時恢復

恢復的數據被視為臨時數據，僅在恢復請求中指定的時間段內存在于 Ceph 集群中。一旦指定期限到期，恢復的數據將被刪除，對象將恢復為存根（stub），同時保留元數據和云遷移配置。

跳過生命周期遷移規則

在臨時恢復期間，對象不受生命周期規則的影響，這些規則可能會將其遷移到其他層級或刪除。這確保了在到期日期之前可以無中斷地訪問數據。

恢復數據的默認存儲類別

默認情況下，恢復的對象會寫入 Ceph 集群中的 STANDARD 存儲類別。然而，對于臨時對象，x-amz-storage-class 標頭仍會返回原始的云層級存儲類別。這與 AWS Glacier 的語義一致，即恢復對象的存儲類別保持不變。

S3 RestoreObject API 操作示例

我們使用名為 databucket 的存儲桶將一個名為 2gb 的對象上傳到本地 Ceph 集群。在本系列博客的第一部分中，我們為 databucket 配置了一個生命周期策略，該策略會在 30 天后將數據分層/歸檔到 IBM COS。我們設置了一個名為 tiering 的 AWS CLI 客戶端配置文件，用于與 Ceph 對象網關的 S3 API 端點進行交互。

aws --profile tiering --endpoint https://s3.cephlabs.com s3 cp 2gb s3://databucket upload: ./2gb to s3://databucket/2gb

我們可以檢查本地 Ceph 集群中STANDARD存儲類中上傳對象的大小：

aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key 2gb
{
    "AcceptRanges": "bytes",
    "LastModified": "2024-11-26T21:31:05+00:00",
    "ContentLength": 2000000000,
    "ETag": "\"b459c232bfa8e920971972d508d82443-60\"",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "PartsCount": 60
}

30 天后，生命周期轉換開始，對象將轉換到云層。首先，作為管理員，我們使用radosgw-admin命令檢查生命周期 (LC) 處理是否已完成，然后作為用戶，我們使用 S3 HeadObject API 調用來查詢對象的狀態：

# radosgw-admin lc list| jq .[1]
{
  "bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1",
  "shard": "lc.23",
  "started": "Tue, 26 Nov 2024 21:32:15 GMT",
  "status": "COMPLETE"
}
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  head-object --bucket databucket --key 2gb
{
    "AcceptRanges": "bytes",
    "LastModified": "2024-11-26T21:32:48+00:00",
    "ContentLength": 0,
    "ETag": "\"b459c232bfa8e920971972d508d82443-60\"",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "ibm-cos"
}

作為管理員，我們可以使用radosgw-admin bucket stats命令來檢查已使用的空間。我們可以看到rgw.main是空的，我們的rgw.cloudtiered位置是唯一存儲數據的位置。

# radosgw-admin bucket stats --bucket databucket | jq .usage
{
  "rgw.main": {
    "size": 0,
    "size_actual": 0,
    "size_utilized": 0,
    "size_kb": 0,
    "size_kb_actual": 0,
    "size_kb_utilized": 0,
    "num_objects": 0
  },
  "rgw.multimeta": {
    "size": 0,
    "size_actual": 0,
    "size_utilized": 0,
    "size_kb": 0,
    "size_kb_actual": 0,
    "size_kb_utilized": 0,
    "num_objects": 0
  },
  "rgw.cloudtiered": {
    "size": 1604857600,
    "size_actual": 1604861952,
    "size_utilized": 1604857600,
    "size_kb": 1567244,
    "size_kb_actual": 1567248,
    "size_kb_utilized": 1567244,
    "num_objects": 3
  }
}

現在該對象已轉換到我們的 IBM COS Cloud 層，讓我們使用 S3 RestoreObject API 調用將其恢復到我們的 Ceph 集群。在此示例中，我們將請求臨時恢復并將過期時間設置為三天：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api restore-object --bucket databucket --key 2gb --restore-request Days=3

如果我們嘗試獲取仍在恢復的對象，我們會收到如下錯誤消息：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  get-object --bucket databucket --key 2gb /tmp/2gb
An error occurred (RequestTimeout) when calling the GetObject operation (reached max retries: 2): restore is still in progress

使用 S3 API，我們可以發出 HeadObject 調用并檢查 Restore 屬性的狀態。在此示例中，我們可以看到從 IBM COS 云端點到 Ceph 的恢復已完成，因為 ongoing-request 設置為 false。由于我們在 RestoreObject 調用中使用了 --restore-request days=30，因此對象有一個到期日期。從輸出中還可以檢查其他信息：本地 Ceph 集群中對象占用的大小為 2GB，恢復后符合預期。此外，存儲類別為 ibm-cos。如前所述，對于臨時遷移的對象，即使使用 Ceph RGW 的 STANDARD 存儲類別，我們仍會保留 ibm-cos 存儲類別。現在對象已恢復，我們可以從客戶端發出 S3 GET API 調用來訪問該對象。

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  head-object --bucket databucket --key 2gb
{
    "AcceptRanges": "bytes",
    "Restore": "ongoing-request=\"false\", expiry-date=\"Thu, 28 Nov 2024 08:46:36 GMT\"",
    "LastModified": "2024-11-27T08:36:39+00:00",
    "ContentLength": 2000000000,
    "ETag": "\"\"0c4b59490637f76144bb9179d1f1db16-382\"\"",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "ibm-cos"
}
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  get-object --bucket databucket --key 2gb /tmp/2gb

S3 RestoreObject 永久恢復

在永久恢復中，恢復的數據將無限期保留在 Ceph 集群中，使其可以作為常規對象訪問。與臨時恢復不同，永久恢復不定義到期時間，對象在檢索后不會恢復為存根。這適用于需要長期訪問對象而無需額外重新恢復步驟的場景。

重新應用生命周期遷移規則

一旦永久恢復，對象將被視為 Ceph 集群中的常規對象。所有生命周期規則（例如遷移到云存儲或過期策略）將重新應用，恢復的對象將完全集成到存儲桶的數據生命周期工作流中。

恢復數據的默認存儲類別

默認情況下，永久恢復的對象會寫入 Ceph 集群中的 STANDARD 存儲類別。與臨時恢復不同，對象的 x-amz-storage-class 標頭將反映 STANDARD 存儲類別，表明其在集群中的永久駐留狀態。

S3 RestoreObject API 永久恢復操作示例

通過不為 --restore-request 參數提供天數來永久恢復對象：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api restore-object --bucket databucket --key hosts2 --restore-request {}

驗證恢復的對象：它是STANDARD存儲類的一部分。

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key hosts2
{
    "AcceptRanges": "bytes",
    "LastModified": "2024-11-27T08:28:55+00:00",
    "ContentLength": 304,
    "ETag": "\"01a72b8a9d073d6bcae565bd523a76c5\"",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "STANDARD"
}

對象直讀（/GET）模式

通過 Read-Through Restore 機制訪問的對象會暫時恢復到 Ceph 集群中。當對云轉換對象發出GET請求時，系統會從云層異步檢索該對象。它使其在read_through_restore_days值定義的指定持續時間內可用。過期后，恢復的數據將被刪除，對象將恢復到其存根狀態，保留元數據和轉換配置。

對象直讀 (/GET) 模式測試

在啟用直讀模式之前，如果我們嘗試訪問本地 Ceph 集群中已通過基于策略的歸檔轉換到遠程 S3 端點的存根對象，我們將收到以下錯誤消息：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object --bucket databucket --key 2gb6 /tmp/2gb6
An error occurred (InvalidObjectState) when calling the GetObject operation: Read through is not enabled for this config

因此，我們首先啟用直讀模式。作為 Ceph 管理員，我們需要修改當前的ibm-cos云層存儲類并添加兩個新的層配置參數： --tier-cnotallow=allow_read_through=true,read_through_restore_days=3 ：

# radosgw-admin zonegroup placement modify --rgw-zonegroup default \
  --placement-id default-placement --storage-class ibm-cos \
  --tier-config=allow_read_through=true,read_through_restore_days=3

如果之前未執行任何多站點配置，則會創建默認區域和區域組，并且對區域/區域組的更改只有在 Ceph 對象網關（RGW 守護進程）重新啟動后才會生效。如果已為多站點創建了領域，則區域/區域組更改將在提交更改后生效 radosgw-admin period update --commit 。在我們的例子中，重新啟動 RGW 守護進程以應用更改就足夠了：

# ceph orch restart rgw.default
Scheduled to restart rgw.default.ceph02.fvqogr on host 'ceph02'
Scheduled to restart rgw.default.ceph03.ypphif on host 'ceph03'
Scheduled to restart rgw.default.ceph04.qinihj on host 'ceph04'
Scheduled to restart rgw.default.ceph06.rktjon on host 'ceph06'

一旦啟用直讀模式，并且當對云層中的對象發出GET請求時重新聲明 RGW 服務，該對象將自動恢復到 Ceph 集群并提供給用戶。

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  get-object --bucket databucket --key 2gb6 /tmp/2gb6
{
    "AcceptRanges": "bytes",
    "Restore": "ongoing-request=\"false\", expiry-date=\"Thu, 28 Nov 2024 08:46:36 GMT\"",
    "LastModified": "2024-11-27T08:36:39+00:00",
    "ContentLength": 2000000000,
    "ETag": "\"\"0c4b59490637f76144bb9179d1f1db16-382\"\"",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "ibm-cos"
}

未來工作

Ceph 社區正在通過以下即將推出的增強功能改進基于策略的數據檢索特性：

磁帶/DiamondBack 支持：使用 RestoreObject API 從使用 Glacier API 的 S3 端點獲取對象，而不是通過 GET 請求。
增強監控的管理命令：包括恢復狀態、列出已恢復/進行中的對象，以及為失敗操作重新觸發恢復。
壓縮和加密支持：有效恢復壓縮或加密的對象。

責任編輯：武曉燕來源：新鈦云服

對象存儲分層