7.4. 创建服务池


Ceph 对象网关将许多池用于各种服务功能,以及一组单独的放置池来存储 bucket 索引、数据和其他信息。

由于对池放置组的计算成本比较高,红帽通常建议 Ceph 对象网关的服务池使用比数据存储池少得多的放置组。

服务池存储与服务控制、垃圾收集、日志记录、用户信息、使用情况等相关的对象。按照惯例,这些池名称的前置为池名称的区域名称。

注意

自红帽 Ceph 存储 4.1 起,垃圾回收使用带有常规 RADOS 对象的日志池,而非 OMAP。将来,更多功能会将元数据存储到日志池。因此,强烈建议将 NVMe/SSD OSD 用于日志池。

  • .<zone-name>.rgw.control :控制池。
  • .<zone-name>.log :日志池包含所有存储桶/容器的日志,以及创建、读取、更新和删除对象操作的日志。
  • .<zone-name>.rgw.buckets.index :此池存储 buckes 的索引。
  • .<zone-name>.rgw.buckets.data :此池存储存储桶的数据。
  • .<zone-name>.rgw.meta :元数据池存储 user_keys 和其他关键元数据。
  • .<zone-name>.meta:users.uid :用户 ID 池包含唯一用户 ID 的映射。
  • .<zone-name>.meta:users.keys :密钥池包含每个用户 ID 的访问密钥和 secret 密钥。
  • .<zone-name>.meta:users.email :电子邮件池包含与用户 ID 关联的电子邮件地址。
  • .<zone-name>.meta:users.swift :Swift 池包含用户 ID 的 Swift 子用户信息。

执行 Get a Zone 步骤来查看池名称。

# radosgw-admin zone get [--rgw-zone=<zone>]
Copy to Clipboard Toggle word wrap

When radosgw-admin 创建一个区域,池名称为 SHOULD,前缀为区域名称。例如,名为 us-west SHOULD 的区域的池名称如下所示:

{ "domain_root": ".rgw.root",
  "control_pool": ".us-west.rgw.control",
  "gc_pool": ".us-west.rgw.gc",
  "log_pool": ".us-west.log",
  "intent_log_pool": ".us-west.intent-log",
  "usage_log_pool": ".us-west.usage",
  "user_keys_pool": ".us-west.users.keys",
  "user_email_pool": ".us-west.users.email",
  "user_swift_pool": ".us-west.users.swift",
  "user_uid_pool": ".us-west.users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
    {  "key": "default-placement",
       "val": { "index_pool": ".us-west.rgw.buckets.index",
                "data_pool": ".us-west.rgw.buckets",
                "data_extra_pool": ".us-west.rgw.buckets.non-ec"
                "index_type": 0
              }
    }
  ]
}
Copy to Clipboard Toggle word wrap

control_pool 开头并以 user_uid_pool 结尾,在区域中使用池名称创建池,前提是区域名称前面是池名称的前面。按照前面的示例,池创建可能类似如下:

# ceph osd pool create .us-west.rgw.control 32 32 replicated rgw-service
...
# ceph osd pool create .us-west.users.uid 32 32 replicated rgw-service
Copy to Clipboard Toggle word wrap

在前面的示例中,rgw -service 规则表示 SAS 驱动器的 CRUSH 层次结构,其含有 SSD 日志和 机架 作为 CRUSH 故障realm。请参阅 创建 CRUSH Roots,以及 创建 CRUSH 规则,以用于前面的示例。

如需有关 PG 数量的详细信息,请参阅《存储策略指南》中的每个池 PG(PG)和 放置组 一章。有关 创建池 的详情,请参阅存储策略指南中的创建池部分。

注意

对于服务池,计算器的建议 PG 数显著低于每个 OSD 的目标 PG 数。确保计算器的第 3 步指定了正确的 OSD 数量。

通常,.rgw.root 池和服务池应使用相同的 CRUSH 层次结构,并且至少将 node 用作 CRUSH 规则中的故障域。与 .rgw.root 池一样,服务池应使用 复制来实现 数据持久性,而非 纠删

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat