2.4. Ceph 对象网关注意事项
设计存储集群的另一个重要方面是确定存储集群会位于一个数据中心站点，还是跨越多个数据中心站点。多站点存储群集得益于地理分散的故障切换和灾难恢复，如长期停电、农业、风暴、风暴、水水或其他灾难。另外，多站点存储群集可以具有主动配置，该配置可将客户端应用定向到最接近的可用存储集群。这是内容交付网络的良好存储策略。考虑尽可能将数据放置在客户端附近。这对于吞吐量密集型工作负载非常重要，如 4k 视频。
红帽建议识别域、zone group 和 zone 名称 BEFORE 创建 Ceph 的存储池。使用区域名称作为标准命名约定附加一些池名称。
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 对象网关 指南中的多站点配置和管理 部分。
2.4.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 对象网关配置的池。这包括 realm、zone group 和 zone。按照惯例，其名称不会以区域名称开头。
服务池
服务池存储与服务控制、垃圾收集、日志记录、用户信息和使用量相关的对象。按照惯例，这些池名称的前置为池名称的区域名称。
-
.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.4.2. 索引池
当选择用于 Ceph 对象网关的 OSD 硬件时，无论用例 - 至少需要一个高性能驱动器（可以是 SSD 或 NVMe 驱动器）的 OSD 节点来存储索引池。当 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 字节的数据，存储为 rocksdb 中的 OMAP。虽然这是微不足的数据，但有些使用 Ceph 对象网关可能会导致单个 bucket 中有几十或几百个对象。通过将索引池映射到具有高性能存储介质的 CRUSH 层次结构，当 bucket 包含大量对象时，对则延的减小会显著提高性能。
在生产环境中，典型的 OSD 节点将至少有一个 SSD 或 NVMe 驱动器来存储 OSD 日志，以及索引池或 block.db 设备，其对同一物理驱动器使用单独的分区或逻辑卷。
2.4.3. 数据池
数据池是 Ceph 对象网关存储特定存储策略的对象数据的位置。数据池具有完整放置组 (PG) ，而不是用于服务池的数量减少的 PG。考虑将纠删代码用于数据池，因为它比复制更高效，而且可以显著降低容量要求，同时保持数据持久性。
要使用纠删代码，请创建一个纠删代码 profile。如需了解更多详细信息，请参阅 Red Hat Ceph Storage 策略指南中的 Erasure Code Profiles 部分。
选择正确的配置集非常重要，因为您创建池后无法更改配置集。若要修改配置文件，您必须创建一个具有不同配置文件的新池，并将对象从旧池中迁移到新池中。
默认配置是两个数据区块和一个编码区块，这意味着只能丢失一个 OSD。对于更高的弹性，请考虑大量数据和编码区块。例如，一些大型系统使用 8 个数据区块和 3 个编码区块，这允许 3 个 OSD 在不丢失数据的情况下失败。
每个数据和编码区块 SHOULD 至少会存储在不同的节点或主机上。对于较小的存储集群，这会使使用 机架 作为更多数据和编码区块的最小 CRUSH 故障域不切实际。因此，数据池通常使用单独的 CRUSH 层次结构并将 主机 用作最小 CRUSH 故障域。红帽建议 host 作为最小故障域。如果纠删代码区块存储在同一主机上的 Ceph OSD 上，主机故障（如失败的日志或网卡）可能会导致数据丢失。
若要创建数据池，运行 ceph osd pool create 命令，使用池名称、PG 和 PGP 的数量、erasure 数据持久性方法、纠删代码 profile 和规则名称。
2.4.4. 数据额外池
data_extra_pool 用于无法使用纠删代码的数据。例如，多部分上传允许上传大型对象，如多个部分的 movie。这些部分必须首先存储而无纠删代码。纠删代码应用到整个对象，而不是部分上传。
每个池的 PG 数量约为 data_extra_pool 的每个池的 PG 数量(PG)；但 PG 计数大约是服务池的 PG 数量两倍，与 bucket 索引池相同。
若要创建数据额外池，请使用池名称、PG 和 PGP 的数量、复制 数据持久性方法以及规则名称运行 ceph osd pool create 命令。例如：
# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service
