介  紹

Ceph 提供了對象存儲分層功能，通過在不同存儲類別之間無縫遷移數據來優化成本和性能。這些層級可以在本地基礎設施內配置，也可以擴展到基于云的存儲類別，從而為多樣化的工作負載提供靈活且可擴展的解決方案。借助基于策略的自動化功能，管理員可以定義生命周期策略，將數據從高性能存儲遷移到經濟高效的歸檔層級，確保在速度、持久性和成本效益之間取得最佳平衡。

Ceph 的本地存儲類別允許配置在本地 Ceph 集群內，將數據在快速的 NVMe 或 SAS/SATA SSD 存儲池與經濟型的 HDD 或 QLC 存儲池之間進行分層存儲。這對于需要不同性能級別的應用程序或數據“老化”后不再需要高性能的場景尤為有益，此時可以將數據遷移到速度較慢但更經濟的存儲中。

圖片

除了本地分層存儲外，Ceph 還提供了基于策略的數據歸檔和檢索功能，能夠與 S3 兼容平臺集成，實現異地數據管理。組織可以利用此功能將數據歸檔到基于云的存儲層級，例如 IBM Cloud Object Storage、AWS S3、Azure Blob 或 S3 磁帶端點，以實現長期保留、災難恢復或成本優化的冷存儲。通過基于策略的自動化功能，Ceph 確保數據能夠根據預定義的生命周期規則遷移到云端或其他目標位置，從而增強其在混合云策略中的價值。

圖片

Squid 版本中的新功能：基于策略的數據檢索

最初，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 對象網關支持的各種生命周期策略：

除了指定策略外，生命周期規則還可以使用標簽（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-znotallow=default --placement-id=default-placement --storage-class=ibm-cos --tier-type=cloud-s3

[!CAUTION]

注意：Ceph 允許使用任意名稱創建存儲類別，但某些客戶端和客戶端庫僅接受 AWS 存儲類別名稱，或者在存儲類別為 GLACIER 等特定名稱時表現出獨特的行為。

我們可以驗證默認區域組和放置目標中的可用存儲類：

# radosgw-admin zonegroup get --rgw-znotallow=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-class ibm-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,reginotallow=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我們應該會看到轉換存儲桶的生命周期策略處于已完成狀態：

[root@ceph01 ~]# radosgw-admin lc list| jq .[1]
{
  "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://databucket
2024-11-25 05:41:33          0 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)。

原文： https://ceph.io/en/news/blog/2025/rgw-tiering-enhancements-part2/