介  紹

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

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

圖片

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

圖片

Squid 版本中的新功能：基于策略的數(shù)據(jù)檢索

最初，Ceph 基于策略的數(shù)據(jù)歸檔（云同步）功能僅支持單向數(shù)據(jù)流，即數(shù)據(jù)只能從本地存儲池歸檔到指定的云存儲層級。雖然這使用戶能夠利用經(jīng)濟高效的云平臺進行冷存儲或長期數(shù)據(jù)保留，但缺乏數(shù)據(jù)檢索能力限制了該解決方案在數(shù)據(jù)管理中的靈活性。這意味著，一旦數(shù)據(jù)被歸檔到云存儲，就無法再通過 Ceph 直接主動檢索或重新集成到本地工作流中。

Ceph Squid 引入了基于策略的數(shù)據(jù)檢索功能，這標志著其能力的重大演進，目前作為技術(shù)預(yù)覽版提供。這一增強功能使用戶能夠?qū)?S3 云存儲或磁帶存儲中的對象直接檢索回本地 Ceph 環(huán)境，消除了之前單向數(shù)據(jù)流的限制。數(shù)據(jù)可以作為臨時或永久對象進行恢復(fù)。

• 臨時恢復(fù)：恢復(fù)的數(shù)據(jù)會繞過生命周期云遷移規(guī)則，并在指定時間后自動刪除，對象將恢復(fù)為之前的存根狀態(tài)。
• 永久恢復(fù)：這些對象會完全重新集成到 Ceph 集群中，被視為（并成為）常規(guī)對象，并遵循標準的生命周期策略和復(fù)制流程。

對象檢索可以通過兩種不同的方式實現(xiàn)：

• S3 RestoreObject API：允許用戶使用 S3RestoreObject API 請求從遠程 S3 端點檢索對象。
• 讀取時透明檢索：支持對已遷移對象執(zhí)行標準的 S3 GET 請求，從而透明地將對象恢復(fù)到 Ceph 集群中。

圖片

在此版本中，我們不支持從使用不同 Glacier API（例如 IBM Deep Archive）的 S3 云/磁帶端點檢索對象。此功能增強針對 Ceph 的 Tentacle 版本。

基于策略的數(shù)據(jù)歸檔測試

在本節(jié)中，我們將配置和設(shè)置 Ceph 的基于策略的數(shù)據(jù)歸檔功能。我們將討論使用數(shù)據(jù)生命周期策略，通過將冷數(shù)據(jù)歸檔到 IBM Cloud Object Storage (COS)，將其轉(zhuǎn)換為異地、經(jīng)濟高效的存儲類。

Ceph 術(shù)語說明

• 區(qū)域組（Zonegroup）：通常位于同一地理區(qū)域（也稱為區(qū)域）的多個區(qū)域的集合。
• 區(qū)域（Zone）：包含對象網(wǎng)關(guān)（RGW）端點的一個或多個實例，屬于某個區(qū)域組。
• 放置（Placement）：在同一區(qū)域內(nèi)對 RADOS 數(shù)據(jù)池進行邏輯分離。
• 存儲類別（Storage Class）：存儲類別用于自定義對象數(shù)據(jù)的放置位置，S3 存儲桶生命周期規(guī)則則用于自動化這些類別之間的數(shù)據(jù)遷移。

[!CAUTION]

注意：此處描述的 RGW 存儲類別不應(yīng)與 Kubernetes 的 PV/PVC 存儲類別混淆。

生命周期策略介紹

下表總結(jié)了 Ceph 對象網(wǎng)關(guān)支持的各種生命周期策略：

除了指定策略外，生命周期規(guī)則還可以使用標簽（tags）或前綴（prefixes）進行過濾，從而更精細地控制哪些對象受到影響。標簽可以根據(jù)每個對象的標簽標識特定對象子集，而前綴則有助于根據(jù)對象鍵名（key names）定位對象。

配置遠程云服務(wù)進行分層

首先，我們將遠程 S3 云服務(wù)配置為本地遷移對象的未來目標。在本示例中，我們將創(chuàng)建一個名為 ceph-s3-tier 的 IBM COS 存儲桶。

圖片

值得注意的是，我們需要為我們的存儲桶創(chuàng)建一個啟用了 HMAC 密鑰的服務(wù)憑證。

為 Cloud-S3 分層創(chuàng)建新的存儲類

在默認區(qū)域組內(nèi)的默認位置上創(chuàng)建新的存儲類；我們使用 rgw-admin --tier-type=cloud-s3 參數(shù)來根據(jù)我們之前在 COS S3 中配置的存儲桶來配置存儲類別。

# radosgw-admin zonegroup placement add --rgw-znotallow=default --placement-id=default-placement --storage-class=ibm-cos --tier-type=cloud-s3

[!CAUTION]

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

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

# radosgw-admin zonegroup get --rgw-znotallow=default | jq .placement_targets[0].storage_classes
[
  "STANDARD_IA",
  "STANDARD",
  "ibm-cos"
]

配置具有分層設(shè)置的 Cloud-S3 存儲類別

接下來，我們使用 radosgw-admin 命令配置 cloud-s3 存儲類別，并指定 IBM COS 存儲桶的相關(guān)參數(shù)：端點（endpoint）、區(qū)域（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

應(yīng)用生命周期策略

一旦 COS cloud-S3 存儲類就位，我們將把用戶切換為 Ceph Object S3 API 的使用者，并通過 RGW S3 API 端點配置生命周期策略。我們的用戶名為tiering ，并且我們已使用分層用戶的憑據(jù)預(yù)先配置了 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 生命周期策略附加到之前創(chuàng)建的存儲桶中。例如，存儲桶databucket將具有以下策略，將所有超過 30 天的對象轉(zhuǎn)換為 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 將存儲桶生命周期配置應(yīng)用到名為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

驗證該策略是否已應(yīng)用：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-bucket-lifecycle-configuration  --bucket databucket

我們還可以通過以下 radosgw-admin 命令檢查 Ceph/RGW 是否已注冊此新的生命周期（LC）策略。狀態(tài)顯示為 UNINITIAL，因為此生命周期策略尚未被處理；一旦處理完成，狀態(tài)將變?yōu)?nbsp;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"
}

我們可以使用以下命令獲取應(yīng)用于存儲桶的規(guī)則的更多詳細信息：

# 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]

更改此參數(shù)僅用于 LC 測試目的。不要在生產(chǎn) Ceph 集群上更改它，并記住適當重置！

我們可以通過為生命周期進程啟用調(diào)試間隔來加速生命周期策略的測試。在此設(shè)置中，存儲桶生命周期配置中的每“天”相當于 60 秒，因此三天的過期時間實際上僅為三分鐘：

# ceph config set client.rgw  rgw_lc_debug_interval 60
# ceph orch restart rgw.default

如果我們現(xiàn)在運行radosgw-admin lc list我們應(yīng)該會看到轉(zhuǎn)換存儲桶的生命周期策略處于已完成狀態(tài)：

[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。這是因為它們已被遷移到云端。然而，由于在創(chuàng)建云存儲類別時使用了 "retain_head_object": "true" 參數(shù)，對象的元數(shù)據(jù)/頭部信息仍然保留在本地：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3 ls s3://databucket
2024-11-25 05:41:33          0 hosts

如果我們使用s3api get-object-attributes調(diào)用檢查對象屬性，我們可以看到該對象的存儲類現(xiàn)在是ibm-cos ，因此該對象已成功轉(zhuǎn)換到 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 無法保留，但它們會作為元數(shù)據(jù)屬性存儲在目標對象上。

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>)

以下對版本化和鎖定對象應(yīng)用了與 LifecycleExpiration類似的語義。如果對象在遷移到云端后是當前版本，則會將其標記為非當前版本，并創(chuàng)建一個刪除標記。如果對象是非當前版本且被鎖定，則跳過其遷移過程。

結(jié)  論

本篇博客介紹了如何通過分層和生命周期策略將冷數(shù)據(jù)遷移到更具成本效益的存儲類別，并將其歸檔到 IBM Cloud Object Storage (COS)。

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