2.5. Ceph 对象网关注意事项
设计存储集群的另一个重要方面是确定存储集群会位于一个数据中心站点，还是跨越多个数据中心站点。多站点存储群集得益于地理分散的故障切换和灾难恢复，如长期停电、农业、风暴、风暴、水水或其他灾难。另外，多站点存储群集可以具有主动配置，该配置可将客户端应用定向到最接近的可用存储集群。这是内容交付网络的一个好存储策略。考虑尽可能将数据放置在客户端附近。这对吞吐量密集型工作负载（如流 4k 视频）非常重要。
红帽建议识别域、zone group 和 zone 名称 BEFORE 创建 Ceph 的存储池。使用区域名称作为标准命名约定附加一些池名称。
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 对象网关指南中的多站点配置和管理 章节。
2.5.1. 管理数据存储
Ceph 对象网关将管理数据存储在实例的区域配置中定义的一系列池中。例如，后续小节中讨论的 bucket、用户、用户配额和用量统计存储在 Ceph 存储集群的池中。默认情况下，Ceph 对象网关会创建以下池并将其映射到默认区域。
-
.rgw.root -
.default.rgw.control -
.default.rgw.meta -
.default.rgw.log -
.default.rgw.buckets.index -
.default.rgw.buckets.data -
.default.rgw.buckets.non-ec
只有 Ceph 对象网关中创建 bucket 之后，才会创建 .default.rgw.buckets.index 池，而数据上传到 bucket 后才会创建 .default.rgw.buckets.data 池。
考虑手动创建这些池，以便您可以设置 CRUSH 规则集和放置组的数量。在典型的配置中，存储 Ceph 对象网关管理数据的池通常使用相同的 CRUSH 规则集，并且使用较少的 PG，因为管理数据有 10 个池。
红帽建议 .rgw.root 池和服务池使用相同的 CRUSH 层次结构，并且至少将 node 用作 CRUSH 规则中的故障域。红帽建议将 复制 用于数据持久性，而不要删除 .rgw.root 池和服务池。
如果您将太多 PG 分配给池，mon_pg_warn_max_per_osd 设置将发出警告，默认为 300。您可以调整值以满足您的需求和硬件的功能，其中 n 是每个 OSD 的最大 PG 数。
mon_pg_warn_max_per_osd = n
对于包括 .rgw.root 在内的服务池，每个池计算器的 Ceph 放置组(PG) 建议的 PG 数显著低于每个 Ceph OSD 的目标 PG。此外，还要确保计算器的第 4 步中设置 Ceph OSD 的数量。
垃圾回收使用带有常规 RADOS 对象的 .log 池，而不是 OMAP。在未来的发行版中，更多功能会将元数据存储到 .log 池。因此，红帽建议将 NVMe/SSD Ceph OSD 用于 .log 池。
.rgw.root 池
存储 Ceph 对象网关配置的池。这包括 realms、zone group 和 zones。按照惯例，其名称不会以区域名称开头。
服务池
服务池存储与服务控制、垃圾收集、日志记录、用户信息和使用量相关的对象。按照惯例，这些池名称的前置为池名称的区域名称。
-
.ZONE_NAME.rgw.control: 控制池。 -
.ZONE_NAME.log：日志池包含所有存储桶、容器和对象操作的日志，如 create、read、update 和 delete。 -
.ZONE_NAME.rgw.buckets.index：此池存储存储桶的索引。 -
.ZONE_NAME.rgw.buckets.data：此池存储存储桶的数据。 -
.ZONE_NAME.rgw.meta：元数据池存储 user_keys 和其他关键元数据。 -
.ZONE_NAME.meta:users.uid：用户 ID 池包含唯一用户 ID 的映射。 -
.ZONE_NAME.meta:users.keys：密钥池包含每个用户 ID 的访问密钥和密钥。 -
.ZONE_NAME.meta:users.email：电子邮件池包含与用户 ID 关联的电子邮件地址。 -
.ZONE_NAME.meta:users.swift：Swift 池包含用于用户 ID 的 Swift 子用户信息。
其它资源
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage 对象网关指南中的关于池章节。
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage 策略指南。
2.5.2. 索引池
当选择用于 Ceph 对象网关的 OSD 硬件时，无论存储索引池，都需要至少一个具有至少一个高性能驱动器的 OSD 节点（一个 SSD 或 NVMe 驱动器）。当 bucket 包含大量对象时，这一点尤为重要。
对于运行 Bluestore 的 Red Hat Ceph Storage，红帽建议将 NVMe 驱动器部署为 block.db 设备，而不是作为单独的池。
Ceph 对象网关索引数据仅写入对象映射(OMAP)中。BlueStore 的 OMAP 数据位于 OSD 上的 block.db 设备上。当 NVMe 驱动器作为 HDD OSD 的 block.db 设备以及由 HDD OSD 支持时，索引数据将完全写入 block.db 设备。只要 block.db 分区/lvm 大小正确为块的 4%，这个配置都是 BlueStore 所需要的。
红帽不支持索引池的 HDD 设备。如需有关支持的配置的更多信息，请参阅 Red Hat Ceph Storage: 支持的配置 文章。
索引条目大约 200 字节的数据，作为 OMAP 存储在 rocksdb 中。虽然这是少量数据，但一些 Ceph 对象网关的使用可能会导致单个存储桶中的几百个对象或几百以百万计的对象。通过将索引池映射到具有高性能存储介质的 CRUSH 层次结构，当 bucket 包含大量对象时，对则延的减小会显著提高性能。
在生产环境集群中，典型的 OSD 节点至少有一个 SSD 或 NVMe 驱动器来存储 OSD 日志和索引池或 block.db 设备，后者将单独的分区或逻辑卷用于同一个物理驱动器。
2.5.3. 数据池
数据池是 Ceph 对象网关存储特定存储策略的对象数据的位置。数据池具有完整放置组 (PG) ，而不是用于服务池的数量减少的 PG。考虑将纠删代码用于数据池，因为它比复制更高效，而且可以显著降低容量要求，同时保持数据持久性。
要使用纠删代码，请创建一个纠删代码 profile。如需了解更多详细信息，请参阅 Red Hat Ceph Storage Storage 策略指南中的 Erasure Code Profiles 部分。
选择正确的配置集非常重要，因为您创建池后无法更改配置集。若要修改配置文件，您必须创建一个具有不同配置文件的新池，并将对象从旧池中迁移到新池中。
默认配置是两个数据块(k)和两个编码区块(m)，这意味着只能丢失一个 OSD。对于更高的弹性，请考虑大量数据和编码区块。例如，一些大型系统使用 8 个数据区块和 3 个编码块，这允许 3 个 OSD 在不丢失数据的情况下失败。
每个数据和编码区块 SHOULD 至少会存储在不同的节点或主机上。对于较小的存储集群，这会导致将 机架 式用作最少的 CRUSH 故障域，用于大量数据和编码块。因此，数据池通常使用单独的 CRUSH 层次结构并将 主机 用作最小 CRUSH 故障域。红帽建议 host 作为最小故障域。如果纠删代码池区块在同一主机上的 Ceph OSD 上存储，则主机故障（如失败的日志或网卡）可能会导致数据丢失。
若要创建数据池，运行 ceph osd pool create 命令，使用池名称、PG 和 PGP 的数量、erasure 数据持久性方法、纠删代码 profile 和规则名称。
2.5.4. 数据额外池
data_extra_pool 用于无法使用纠删代码的数据。例如，多部分上传允许上传大型对象，例如在多个部分中进行移动。这些部分必须首先存储而无纠删代码。擦除编码适用于整个对象，而非部分上传。
每个池的 PG 数量约为 data_extra_pool 的每个池的 PG 数量(PG)；但 PG 计数大约是服务池的 PG 数量两倍，与 bucket 索引池相同。
要创建数据额外池，使用池名称运行 ceph osd pool create 命令、Clemans 和 PGP 的数量、复制的 数据持久性方法以及规则的名称。例如：
# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service
