Red Hat Ceph存储——《面向生产环境的ceph 对象网关指南》

周末负责校对了红帽Ceph对象存储的文档，感谢穆艳学老师的翻译。

本文由Ceph中国社区-穆艳学翻译、刘源校稿
英文出处：Red_Hat_Ceph_Storage-2-Ceph_Object_Gateway_for_Production 欢迎加入CCTG

Red Hat Ceph存储——《面向生产环境的ceph 对象网关指南》

---

第1章 简介

欢迎阅览《面向生产环境的Ceph对象网关》这篇指南，指南主要涉及的内容包括：构建生产环境的Ceph存储集群、构建生产环境的Ceph对象网关集群。

1.1.适用人群

这篇指南主要是为想在生产环境中部署Ceph对象网关的人员准备；提供一系列关于生产环境中Ceph集群与对象网关在规划、设计、部署方面的内容作为参考；同时对部分内容的说明也会以链接的形式适当的转到Ceph官方说明文档。

1.2.前题假设

这篇指南假定读者对Ceph存储集群和Ceph对象网关具备基本的知识。 如果读者没有相应的基本知识，可以在了解本篇指南之前先尝试搭建一个简单的Ceph测试环境以便对Ceph的一些基本概念有所了解。
本指南假定的“单点”集群是由一个Ceph存储集群与在同一个zone内的多个Ceph对象网关组成。与此同时单点集群也可以扩展为跨地区与多站点集群，而这一扩展方式可以参照指南里将每一个zone group与zone进行命名修改来完成。

【译者注：singel-site表示单点，可能只在同一个地区范围内，比如北京地区部署一套；zone：表示地区，如北京、上海等；当然完全是按业务需求自定义的，也可以是不同的机房。zone group是对zone的分组，比如zone有北京、上海、深圳、广州，则zone group可以如华东group（北京zone、上海zone）与华南group(深圳zone、广州zone)，或者zone group也可以是中国】

1.3.涵盖内容

面向生产环境下Ceph存储与Ceph对象网关，本篇指南涵盖了以下内容：

• 集群规划
• 硬件考虑
• 集群部署
• 存储策略设计
• 网关配置
• 其它用例

【注】

本指南只是其它相关指南的一个补充，决非替代

第2章 集群规划

规划用于Ceph对象网关的集群需要考虑以下几个方面：

• 确定应用场景
• 选择合适的数据持久化方式
• 考虑多站点部署

当考虑到涉及的硬件时，上面这些因素对集群将会有较大的影响。在硬件选择之前最好认真的思考下上面提到的这几个因素。

2.1.确定应用场景

Ceph存储能够提供很多不同类型的存储应用场景，对于Ceph对象存储而言，典型的应用场景如下：

• 吞吐量优化型：一个吞吐量优化的集群旨在确保快速的数据访问。例如在图形应用或者流媒体音视频应用方面，就需要配置HBA卡、高速的顺序读取存储介质以及更大的网络带宽；如果在存储CCTV流等应用方面，可能会更关注写入性能，可以通过将SSD作为为日志来提供更好的写入性能；对于4K视频流等密集型应用，就需要考虑HBA控制器及网络吞吐，基于HBA的控制器相比于板载控制器有较显著的性能提升。

• 存储容量优化型： 对于容量优化的集群，需要确保存储每TB的成本最低。这种应用一般针对不频繁读取的冷数据，例如金融票据的归档，或者的电子邮件的存档。此时，就可以使用 一些廉价的存储介质，并且避免采用SSD来做日志盘。

• IOPS优化型： 对于IOPS优化的集群，目的在于针对读写密集型应用能够提供较高的性能；虽然IOPS优化负载应用在Ceph对象网关这块并不算什么可优化的亮点，但是能够对SSD、闪存、亦或是CRUSH层面有所支持。

在准备进行硬件选型之前，一定要合理评估集群的应用场景，因为这对集群的性能以及成本有着很大的影响；例如如果业务是容量优化型的场景，但硬件上却是配备了更适用于吞吐优化的场景，那么在集群中硬件方面的开销可能比实际所需要的会更大一些， 反之如果业务场景是吞吐优化型的，但硬件是容量优化型的，则集群可能会有非常差的性能表现。

此外也注意到，Ceph对象网关支持存储策略，这就使得可以针对上面提到的内容通过创建CRUSH层级并辅以API接口的存储策略支持得以实现。详细的内容可以参见创建数据存储策略

2.2.选择数据持久化策略

在进行集群的设计时，还需要选择存储数据的持久化策略，在着方面Ceph存储提供了副本存储与纠删码存储这两种数据的持久化策略。
为了避免硬件故障对数据可靠性的影响，副本存储策略会将一份或多份数据存储在不同的故障域中， 但同时这些冗余数据在大规模应用中会增加很多成本。例如，在三副本策略下，为了存储1PB的有效数据就需要占用3PB的存储空间。

在《存储策略指南》的纠删码章节描述了纠删码是如何以数据块和校验块的形式进行存储的。假如有一个数据块数据丢失，那么纠删码能够通过剩余的数据块以及校验块对丢失的数据进行恢复。相比于副本方式，纠删码方式更经济些【译者注：数据不需要完全的多份冗余从而减少存储资源开销】。 例如，在纠删码中使用8个数据块与3个校验块就可以达到3副本存储策略同样的冗余效果【译者注：这里应该是原文表述不太准确，就删码8+3是可以丢失三份数据的，但是3副本最多只能丢失两份，冗余效果并不相同】，但是相较于3副本存储方式中总数据两是有效数据的3倍而言，8+2的就删吗存储方案中总数据量仅仅是有效数据的1.5倍左右。

【注】

在不同存储池的策略选择上，只有所存储的数据可以采用纠删码策略进行存储，对于存储系统数据以及桶索引数据等的存储池仍采用副本存储策略。

2.3.考虑多站点部署

规划集群时另一个重要的方面就是确定集群是部署在一个数据中心的单站点还是跨多数据中心的多站点。多站点部署的好处就是发生灾难时(长时间的电力中断、地震、飓风、洪水等）可以进行数据的恢复；此外多站点部署也可以使得客户端的应用能够访问最近的CDN热备服务（active-active，译者注：多台同时提供服务的server具有同样的功能，通常是在此类server前架设loadbalance）。尤其像吞吐密集型的4K视频等业务场景，尽可能的使存放的数据与访问客户端在同一地理位置更是格外的重要。

多于多站点集群更详细的内容，可以参见《RedHat 企业版LINUX环境下的对象网关》指南中的多站点章节。

【注】

红帽建议在创建Ceph存储池之前对领域范围、区域分组、区域命名等信息进行标识。对于存储池的命名应该以区域名称为前缀来设定

第3章 硬件选型

在构建Ceph存储与Ceph对象网关集群的生产环境中，硬件的选型也是很重要的部分。一般针对硬件有如下考虑：

• 存储规模【译者注：存储空间小大】
• 存储密度【译者注：节点存储数据的稀疏性，数据量固定的情况下，存储节点越多则存储越稀疏，反之单一存储节点就会存储较多的数据】
• UPS（不间断电源）
• 网络硬件
• 硬件的选型要根据业务场景
• 存储桶索引使用SSD
• monitor节点使用SSD

【重要提示】

为构建集群而购买计算与网络硬件之前，务必要对上面所提到的这些内容予以重视

3.1.存储规模

在设计Ceph集群时，一个最重要的因素就是确定存储需求（存储规模或大小）；Ceph本身就支持存储的扩展性，支持存储PB规模的数据量或更大的数据量。通常的Ceph集群存储规模示例如下：

• 较小规模： 250TB
• 适中规模： 1PB
• 较大规模： 2PB或更高

对存储容量大小的规划不但要包括当前存储需求大小，也要包括近期的存储需求【译者注：近期或远期存储大小完全要根据当前业务的增长来预判，按个人理解一般近期指的通常为6个月~1年期限】。可以参照所访问网关的客户端新增数据的增长率来判断，但这种方式可能对不同的业务场景有所差别。例如，对于存储记录CCTV视频、4K视频或医疗影像数据量的增长要远高于如金融行业等存储需求应用的场景。另外，如副本或纠删码的不同存储方式选择也会对存储介质承载存储能力具有较大的影响。

对于其它有关规模相关的内容，可以参考《RedHat Ceph存储 硬件指南》以及OSD硬件选择相关的一些说明链接

3.2.存储密度

在设计Ceph集群时，一个最重要的方面就是也要考虑下存储数据的稀疏程度。通常情况下，对于集群来说数据的存储应当至少不低于10个存储节点，这样才能确保在副本间数据同步、数据回填、数据恢复发生时性能不会有较大的影响；在至少10个存储节点的集群中，如果其中一个节点发生故障，那么也仅有10%的的数据需要迁移到正常提供服务的节点，反之如果集群中存储节点过少那么当某个节点发生故障时可能就会有大量的数据进行迁移。此外，为了确保当存储节点出现故障后可以继续向集群中写入数据，针对存储节点使用量上的2个参数也需要设置： full_ratio与near_full_ratio【译者注：前者表示已达到存储容量上限，一般阀值为总容量的95%，后者表示接近了设定的容量阀值，一般设为85%】；综上，存储密度的考量在集群的规划时也是比较重要的一部分，设计一个高密度的集群并不是一个好的方案。

另一方面，纠删码方式也倾向于较大密度的存储应对应较多的存储节点。当以纠删码方式在设置了最小CRUSH的故障域节点上写入一个对象时，数据块与校验块的总数需要与存储节点数量相同才能完成。例如，一个集群使用8个数据块3个校验块，那么至少要有对应的11个存储节点才能保证写入的每一份数据及校验块对应不同的存储节点【译者注：意味着为了保证每一份数据都存不同的节点上，这就要求总的存储节点至少要大于数据块个数与校验块个数的和】。

热部署（译者注：或叫热插拨，例如不停机情况下新增加一块磁盘、启动一个OSD等）也是比较重要的一个关注点，大多数现代的服务器都支持驱动的热插拨。然而一些（热部署的）硬件在配置方面则需要去除某些驱动或驱动替换。RedHat则建议尽量避免这种配置等的变动，因为当磁盘出现问题需要更换时，这可能会使受影响的OSD数量比预期的还要多。【译者注：例如更换一块盘时可能影响的不仅仅是这块盘对应的OSD，也可能同机器上其它的OSD也会受到影响】

3.3.网络硬件

Ceph存储的主要优势也在于可以独立的进行对存储容量、IOPS以及吞吐量的扩展或提升。但是一般而言，对于云存储解决方案来说，存储容量很少会受到限制，但是IOPS会因为网络时延等因素而降低或者由于带宽限制导致吞吐量不足。这就意味着若想达到期望的性价比，网络硬件的配置就一定要支持所对应的业务场景。尤其当使用SSD、闪存、NVME等快速存储设备时，网络性能方面的能力也会显得更为重要。

关于Ceph存储另一个比较重要的方面就是支持对网络的划分：公网（前端网络）对应客户端和monitor节点的数据交互，内网（后端网络）则对应存储之间的心跳、副本间数据复制以及数据恢复。这也意味着后端网络总是比前端网络需要更多的网络资源。根据存储池采用持久化方式的不同（纠删码或副本），后端网络需求也要适当的进行评估或量化。

最后，在安装部署与测试Ceph之前应当对网络的吞吐性能进行验证。大多数Ceph性能相关的问题都是由于网络问题。比如网络中使用的6类线缆如有打结或弯曲也可能使得网络性能的下降。前端网络可以使用10Gbe的以太网卡，规模较大的集群后端网络可以考虑40Gbe的以太网卡，此外，对于后端网络，可以将交换机LCAP模式4来绑定网络或者使用巨帧（MTU 9000）。【译者注：对于jumbo frame来说，路由不开启支持巨帧的话则可能被过滤掉而无法传输出去，所以设置MTU也需要整体通信的网路中有所支持】。

3.4.UPS

因为Ceph的数据写入是原子操作（所有副本作为一个整体对待，要么全部成功写入要么全都不写），并不是一定要求为存储节点OSD配备UPS。但是RedHat建议还是要为MON节点配置UPS，因为MON使用leveldb进行数据存储，而leveldb对同步的写入延时较为敏感，一旦停电就可能需要另外的技术支持来恢复集群。

如果存储控制器使用回写缓存的话，那么UPS对OSD节点来说还是很有必要的，因为UPS会保证控制器即使在断电时也能及时刷新缓存从而避免文件系统崩溃。

3.5.依业务场景的硬件选型

Ceph存储的另外一个优势是可以通过定制不同的集群配置来满足不容的业务场景。一般来讲，RedHat建议针对某个特定的业务场景，OSD的配置要尽量保持一致；对于Ceph存储集群，主要的业务场景有以下3类：

• IOPS优化型
• 吞吐量优化型
• 存储容量优化型

尽管可以通过一系列相同的主机来达到用单一主机的配置来适配以上所有场景的效果，但是RedHat并不推荐这么做，毕竟不同的业务场景对驱动、HBA控制器、网络等要求是不同的。

在使用相同的主机来实现多个CRUSH层级结构时，应该在CRUSH映射关系中使用逻辑主机名称而不是实际的主机名。例如，Ansible等部署工具就会对不同的场景进行分组，而不是将所有OSD节点都部署在默认的[osds]组内。

注

通常情况下，针对高IOPS、高吞吐或大容量这样的单一个业务场景的主机配置更为简单一些。

3.6.存储桶索引使用SSD

在使用Ceph对象网关（无关业务场景）需要对OSD硬件进行选型时，RedHat建议对于OSD节点至少要为桶索引池配备一块SSD**专属**盘；当桶内包含大量的对象时，这一点特别重要。

一个索引条目大约为200个字节的数据量，以omap方式存储于leveldb中。虽然这点数据量微不足道，但是某些情况下，Ceph对象网关可能在一个桶中存储上千万甚至上亿的对象。在这种桶内包含大量对象的场景下，如果将桶索引存储在SSD上，是可以显著的降低响应延迟的。

【重要提示】

在生产环境中，不但对于桶索引应当配置SSD盘，对于日志所在目录也应当配置SSD盘

3.7.monitor节点使用SSD节点使用SSD

Ceph的monitor节点会使用leveldb，而leveldb对同步写延时是比较敏感的。RedHat强烈建议使用SSD盘存储monitor节点上的数据，同时选择SSD时要保证所选的SSD有足够的顺序写性能及吞吐能力。

第4章 集群部署

生产环境集群的最初部署与在POC环境上的部署基本相同。唯一重要的差别就是生产环境将会用到工业级的硬件。首先，参照《RedHat 企业版Linux安装指南》中的先决条件章节并在每个节点上执行对应的命令。下面的内容将对生产环境集群的部署提供另外的指导。

4.1.命名HOSTS

对主机名称的设置不但要考虑到业务场景，同时也要考虑到性能情况。例如，如果机器存储客户端数据，那么可以考虑按对应的系统配置与性能概况对主机进行命名。例如：

• data-ssd-1, data-ssd-2
• hot-storage-1, hot-storage-2
• sata-1, sata-2
• sas-ssd-1, sas-ssd-2

确定命名规则后可以使得管理集群更简单，在硬件出现问题时也便于排查。

如果主机包含的硬件对应多种业务场景，例如主机包含存放普通数据的SSD，用来做日志盘的SAS接口的SSD盘，还用用于存放冷数据SATA盘，此时就可以选择相对通用的名称，例如：

• osd-node-1, osd-node-2

当CRUSH层级中使用逻辑主机名时，通用的名称也可以进行扩展，例如：

• osd-node-1-ssd, osd-node-1-sata, osd-node-1-sas-ssd, osd-node-1-bucket-index
• osd-node-2-ssd, osd-node-2-sata, osd-node-2-sas-ssd, osd-node-2-bucket-index

更详细的内容可以参见本文第五章CRUSH Map中使用逻辑主机名称章节

4.2.内核调优

操作系统参数的调优对于生产环境的集群也有益处，特别是对limits与memory分配的调优方面。要确保调优操作在集群内的所有节点上进行设置。进一步的指导可以咨询RedHat。

4.2.1.调优TCMalloc

在多线程内存分配负载下，如果TCMalloc没有足够的线程缓存可用时会消耗大量的CPU资源并且会使IOPS降低，因此RedHat建议调大线程缓存且不低于默认的32MB。

改变TCMalloc缓存设置项可以编辑文件/etc/sysconfig/ceph，并设置TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES参数项来调整缓存大小。例如，将缓存大小由64MB调整到128MB可以充分的提高IOPS并降低CPU开销。

释放TCMalloc分配的内存后，如果Ceph的守护进程仍不能使用这部分内存，可以执行下面的命令：

# ceph tell osd.* heap release

4.2.2.为OSD预留内存

为了避免在OSD进行内存分配的请求时遇到内存不足相关的问题，可以在OSD机器上sysctl.conf文件中设置vm.min_free_kbytes参数项。这个选项指定了预留物理内存的大小。依系统RAM的大小建议的设置如下：

• 64GB的RAM，预留1GB
  

  vm.min_free_kbytes = 1048576

• 128GB的RAM，预留2GB
  vm.min_free_kbytes = 2097152
• 256GB的RAM，预留3GB
  vm.min_free_kbytes = 3145728

4.2.3.增加文件描述符

如果文件描述符用完的话，对象网关的进程可能会hang住。在对象网关所在机器上修改**/etc/security/limits.conf**可以提高对象网关可使用文件描述符的数量，例如：

ceph soft nproc unlimited

4.2.4.在大规模集群中调整ulimit

在较大规模集群中（例如包含1024个OSD或者更多的OSD），能够执行Ceph命令的系统管理员可以在每个节点上创建文件**/etc/security/limits.d/50-Ceph.conf**，这些节点会以如下内容来执行命令：

4.2.5.调整PID数量

启动多个OSD的主机上可能会产生大量的线程，尤其是在数据恢复与重新映射的时候更为明显。对于最大线程数许多linux内核会默认设置一个相对较小的值。检查下默认的设置是否合适。

cat /proc/sys/kernel/pid_max

如果线程数较多，可以考虑设置**kernel.pid_max**，理论上最大的线程数是4,194,303。例如在**/etc/sysctl.conf**文件中增加以下内容来设置最大值：

kernel.pid_max = 4194303

不重启机器下使配置生效，执行 ：

# sysctl -p

验证改动是否生效，执行：

# sysctl -a | grep kernel.pid_max

4.3.配置ANSIBLE分组

这一配置过程仅针对通过ansible来部署Ceph的情况。**Ceph-ansible**包默认配置了**osds**组。如果集群只有一种业务使用场景与存储策略，那么可以参考[《RedHat 企业版Linux安装指南》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html/installation_guide_for_red_hat_enterprise_linux/index)的[使用Ansible来部署Ceph](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#installing_red_hat_Ceph_storage_using_ansible)章节。 如果集群需要支持多种业务场景及存储策略，那么针对每一种场景创建自己的分组。对于更高级的详细配置内容可以参考[《RedHat 企业版Linux安装指南》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html/installation_guide_for_red_hat_enterprise_linux/index)的[OSD配置项](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#configuring_Ceph_osd_settings)章节。 对于每一种业务场景，都应当将示例文件**/usr/share/Ceph-ansible/group_vars/osd.sample**拷贝并更名为对应业务场景的文件。例如，如果集群有IOPS优化、吞吐优化与容量优化这几种业务场景，那么可以创建独立的文件来表示不同的场景：

cd /usr/share/ceph-ansible/group_vars/
cp osds.sample osds-iops
cp osds.sample osds-throughput
cp osds.sample osds-capacity
然后根据不同的场景来配置对应的文件。

一旦这些分组文件配置完毕，编辑**site.yml**文件确认下是否包含了新增加的分组。例如：

- hosts: osds-iops
gather_facts: false
become: True
roles:
- Ceph-osd

- hosts: osds-throughput
gather_facts: false
become: True
roles:
- Ceph-osd

- hosts: osds-capacity
gather_facts: false
become: True
roles:
- Ceph-osd

最后，在**/etc/ansible/hosts**文件中，在对应的分组名称下面配置与之对应的OSD节点，例如：

[osds-iops]

4.4.部署Ceph

当前置依赖与系统调优完成以后，可以考虑开始进行Ceph集群的部署。当在生产环境部署Ceph集群的时候，RedHat建议安装初始化的monitor集群与足够数量的OSD节点来使集群达到active+clean的状态。详细内容可以参考[《存储集群安装》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#storage_cluster_installation)。 然后在Ceph管理节点上安装Ceph 命令行接口(CLI)客户端。详细内容可以参考[《Ceph CLI安装》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#Ceph_command_line_interface_installation)。 一旦初始集群开始运行，考虑将下面有关的配置信息加到Ceph配置文件中。 **【注】** 如果使用如Ansible工具来部署，那么需要将下面的设置添加到部署工具的配置文件中。如何通过Ansible工具来修改Ceph的配置项，可以参考[《重写Ceph默认设置》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#overriding_Ceph_default_settings)示例。

4.4.1.设置日志大小

设置Ceph集群日志大小，如Ansible等配置工具可能会有一个日志大小的默认值。日志大小应该至少是预期磁盘速度和filestore最大同步时间间隔的两倍 。【译者注：osd journal size =

4.4.2.回填与恢复设置

数据回填与恢复操作会对集群I/O性能造成影响，进而产生较差的系统性能以及用户体验。为了在集群扩容或数据恢复期满足I/O的性能需求，在Ceph配置文件中设置以下参数项：

[osd]
osd_max_backfills = 1
osd_recovery_max_active = 1
osd_recovery_op_priority = 1

4.4.3.集群映射关系大小设置

当集群规模较大包含数千的OSD时，下载并检查集群映射图的大小。默认情况下，**Ceph-osd**守护进程会缓存之前的500个osdmap信息，即使去重后，每个守护进程也可能消耗掉大量的内存资源，在Ceph配置文件中对缓存大小的调优可能会显著的降低对内存的消耗，例如：

[global]
osd_map_message_max=10

[osd]
osd_map_cache_size=20
osd_map_max_advance=10
osd_map_share_max_epochs=10
osd_pg_epoch_persisted_max_stale=10

4.4.4.数据校验任务设置

默认情况下，Ceph每天执行轻量级的数据校验任务，每周执行深度数据校验任务。轻量的任务只检查对象的大小与检验和信息，以确保各PG中存储的是相同的对象数据；随着时间的推移，不管对象大小和校验如何，磁盘扇区都可能出现问题，此时深度校验会检查副本间的对象内容以此确保与对象的实际内容是一致的。从某种意义上说，深度校验与**fsck**一样是为了确保数据的完整性，即使轻量级校验也会影响集群I/O，但是深度校验对集群I/O的影响更大。【译者注：fsck（file system check）这个主要是用来检查和维护不一致的文件系统。若系统掉电或磁盘发生问题的时候，可以利用fsck命令对文件系统进行检查】 数据校验任务的默认设置可能会允许Ceph OSD在并不适宜的情况下进行数据校验，比如在业务操作高峰期或者系统高负载时段；当数据校验任务与用户操作冲突【译者注：同一时段或时刻均对Ceph集群有所操作】，那么对于用户来说可能会有访问延时与系统性能下降的不良体验。 为了避免使用户产生不良的用户体验，Ceph提供了一系列针对数据校验任务的设置，这些设置可以限制校验的周期，如低系统负载时校验，或者在业务低峰时段进行校验。详细内容可以参考[《数据校验》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/configuration_guide/index#scrubbing)。 如果集群白天时段系统高负载状态，而夜间系统低负载状态，则可以考虑将校验任务设置在夜间，例如：

[osd]
osd_scrub_begin_hour = 23 #23:01H, or 10:01PM.
osd_scrub_end_hour = 6 #06:01H or 6:01AM.

如果对于校验任务调度的时间限制并不能有好的效果，可以考虑配置**osd_scrub_load_threshold**参数。这个参数的默认值是**0.5**，但可以按自定义低负载的条件重新进行设置，例如：

[osd]
osd_scrub_load_threshold = 0.25

4.4.5.集群扩容

集群启动运行并且状态为active+clean状态时，可以根据需要向集群中增加新的OSD存储节点或者对象网关节点。在每个节点上参照前面章节[内核调优](##4.2.)所描述的步骤。对于新增加节点，更详细的内容可以参考[《OSD节点的增删》](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/administration_guide/index#adding_and_removing_osd_nodes)。 对于加入到集群中的每一个OSD节点，为存储客户端数据的每个驱动器添加OSD【译者注：意味着不同的盘对应不同的OSD，新加一块盘的话要在这块盘上添加新的OSD】。更多的信息可以参考[添加一个OSD](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/administration_guide/index#adding_an_osd)章节。当使用Ansible工具新增OSD时可以参考前面[配置ANSIBLE分组](##4.3.)章节，如果集群支持多个业务场景也需要将OSD加入到适当的分组中。 对于每一个对象网关节点安装一个网关实例。可以参考[Ceph 对象网关安装](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/installation_guide_for_red_hat_enterprise_linux/index#Ceph_object_gateway_installation)章节。 一旦集群达到**active+clean**状态，可以去除任一[重写规则](https://access.redhat.com/documentation/en-us/red_hat_Ceph_storage/2/html-single/administration_guide/index#overrides)，对于存储策略相关内容可以进一步了解后面的[设计存储策略](#5)章节。 **【注】** 第3步的**增加一个节点**与第10步的**通过命令行接口增加一个OSD**将会在[设计CRUSH层级](##5.1.)重新进行讨论。

第5章 设计存储策略

生产环境的Ceph存储集群与对象网关所面临的主要挑战就是如何定义或设置有效的存储策略（以满足业务的需求）。存储策略涉及以下一些因素：

• 设计CRUSH层级结构
• 创建CRUSH Root
• CRUSH映射关系中使用逻辑主机名称
• 创建CRUSH规则集
• 创建网关的Root存储池
• 配置命名空间标识
• 创建系统存储池
• 创建数据放置策略

有关存储策略与命令行操作用法内容，可以参照《存储策略指南》。

5.1.设计CRUSH层级结构

当我们部署Ceph集群与对象网关时，对象网关将会使用默认的区域分组标识与区域标识。Ceph存储集群也会有一个默认的数据存储池，而这个存储池所对应的CRUSH映射关系就是使用默认的CRUSH层级与CRUSH规则。

【重要提示】
默认的rbd存储池可能会使用默认的CRUSH规则。如果客户端已经存了一些数据在Ceph中，那么 一定不要 删除默认的规则或者层级。

CRUSH层级的其它细节，可以参考《存储策略指南》中《CRUSH管理》章节。

生产环境中的网关应当使用自定的命名空间标识、区域分组标识、区域标识，这些标识的名称应当根据网关的使用以及所在的地理位置进行命名。另外，Ceph集群的CRUSH映射关系中也可能包括多个CRUSH层级。

• 系统存储池： 至少有一个CRUSH层级用于系统存储池或者数据存储池。系统存储池包括.rgw .root 以及与存储池相关的区域标识。系统存储池一般为副本方式进行数据的持久化，同时需要为其配置单一的CRUSH层级。而数据存储池虽然也是单一的CRUSH层级，但是数据的持久化会使用纠删码的方式。

• 存储桶索引： 至少有一个CRUSH层级 应当 用于存储桶索引存储池，并且将这个CRUSH层级映射到SSD盘上。存储桶索引可能成为性能上的瓶颈，所以强烈建议在这个CRUSH层级上使用SSD盘。 一定不要 在SSD盘上将OSD日志所在分区与CRUSH层级放在一起。此外，存储桶索引应当根据存储桶分散情况来配置，详细内容可以参考后面的创建存储桶索引池章节。

• 放置存储池： 放置存储池（针对每种放置目标）包括桶索引、数据桶以及桶附属信息。这些存储池可能属于不同的CRUSH层级。因为Ceph对象网关可以支持多种存储策略，所以存储策略信息的桶存储池可以关联到不同的CRUSH层级来对应不同的业务场景，如IOPS优化、吞吐优化或者容量优化的业务场景。桶索引存储池 应当 使用自己的CRUSH层级并将这一存储池映射到更高性能的SSD盘上。

5.1.1.创建CRUSH Root

在管理节点上通过命令的方式，在CRUSH映射关系上，为每个CRUSH层级结构创建CRUSH Root。 系统存储池 必须 至少要有一个CRUSH层级结构，而这个层级结构也可以服务于数据存储池。桶索引存储池 应当 至少也要有一个映射到SSD或其它高速存储介质的CRUSH层级结构。

详细的有关CRUSH层级结构内容可以参考CRUSH管理的CRUSH层级章节。编辑CRUSH映射关系的话可以参考CRUSH管理的编辑CRUSH映射关系章节。

在下面的例子中，名称为 data0,data1,data2 的主机在CRUSH映射关系中会使用扩展的逻辑名称，诸如 data0-sas-ssd, data0-index等，使用扩展的逻辑名称原因在于多个CRUSH层级结构指向相同的主机。

典型的CRUSH Root可能使用存储日志的SAS驱动接口SSD盘来表示，例如：

##
# SAS-SSD ROOT DECLARATION
##

root sas-ssd {
　id -1 # do not change unnecessarily
　# weight 0.000
　alg straw
　hash 0 # rjenkins1
　item data2-sas-ssd weight 4.000
　item data1-sas-ssd weight 4.000
　item data0-sas-ssd weight 4.000
}

存储桶索引的CRUSH Root 应当使用专有的SSD或其他高速的存储介质，例如：

##
# INDEX ROOT DECLARATION
##

root index {
　id -2 # do not change unnecessarily
　# weight 0.000
　alg straw
　hash 0 # rjenkins1
　item data2-index weight 1.000
　item data1-index weight 1.000
　item data0-index weight 1.000
}

【注】

在不同的SSD数据盘中创建相互独立的CRUSH层级结构。 一定不要在同一块SSD盘中既存储日志又存储桶索引和数据。

5.1.2.CRUSH映射关系中使用逻辑主机名称

在CRUSH映射关系中，主机名称一定是唯一的并且只能使用一次。 当一台主机服务于多个CRUSH层级或场景的时候，为了保证主机名称只能使用一次，CRUSH映射关系可能会使用逻辑主机名称而不是实际的主机名称。例如，一个存储节点中可能包括多个SSD类型的磁盘：SAS驱动接口SSD日志盘以及共存日志的SATA盘；如果想在这一台机器上创建多个CRUSH层级结构，那么CRUSH层级结构需要使用逻辑主机名称来代替实际的主机名称以便在CRUSH层级结构中桶名称是唯一的。例如，如果主机名称是data2，那么CRUSH层级结构可能会使用诸如data2-sas-ssd 与 data2-index的逻辑主机名称。例如：

host data2-sas-ssd {
　id -11 # do not change unnecessarily
　# weight 0.000
　alg straw
　hash 0 # rjenkins1
　item osd.0 weight 1.000
　item osd.1 weight 1.000
　item osd.2 weight 1.000
　item osd.3 weight 1.000
}

在上述示例中，data2主机使用逻辑名称data2-sas-ssd 将SAS驱动接口SSD日志盘映射到某一个CRUSH层次结构上。上述示例中的ID从osd.0至osd.3的OSD即表示在高吞吐量的硬件配置中使用SAS驱动接口SSD日志盘。这些OSD与后面示例中涉及的OSD侧重点还是不同的。

在以下示例中，data2主机使用逻辑名称data2-index 将存储桶索引对应的SSD盘映射到另一个CRUSH层次结构上。以下示例中的ID为osd.4的OSD即表示专用于存储桶索引池的SSD盘或其他高速存储介质。

host data2-index {
　id -21 # do not change unnecessarily
　# weight 0.000
　alg straw
　hash 0 # rjenkins1
　item osd.4 weight 1.000
}

【重要提示】

使用逻辑主机名时，请确保Ceph配置文件中存在以下任一设置，以防止OSD启动脚本在启动时使用实际的主机名称，从而无法在CRUSH映射中找到目标数据。

如上述示例所示，当CRUSH映射使用逻辑主机名称时，应当阻止OSD启动脚本根据初始化时的实际主机名称来识别主机。在Ceph配置文件的[global]模块中增加以下设置：

osd_crush_update_on_start = false

另外一种定义逻辑主机名称的方法是在Ceph配置文件中为每一个OSD**[osd.

5.1.3.创建CRUSH规则集

正如默认的CRUSH层级结构，CRUSH映射关系也包括一个默认的CRUSH规则集，通常为ruleset 0。

【注】

默认的rbd存储池也可能会用到这个规则集，如果其它存储池已经使用这一规则集存储数据的话，一定不要删除这一规则集。

有关CRUSH规则的设置，可以参考《CRUSH 规则》，如果修改一个CRUSH映射关系，可以参考《编辑一个CRUSH映射关系》。

对每一个CRUSH层级结构创建一个CRUSH规则。随后的示例会阐明层级结构（存储系统存储池）的一个规则，而这个层级结构包括.rgw .root。在这个例子中，root sas-ssd 将作为主CRUSH层级结构。主层级结构会使用ruleset 1区分默认的ruleset 0。step take sas-ssd 这行会告知存储池使用CRUSH Root中创建的 sas-ssd root。 这里CRUSH Root的子级存储桶中包含了配备如SAS驱动接口SSD日志盘的高吞吐硬件OSD。【译者注：不管如何设置规则集，其最终都是创建的存储池指向具体的OSD节点，所以OSD的配置也就反映出了对应规则集的配置情况，比如高配的OSD那么它就应该有对应的规则集以便高需求的业务系统可以直接根据这一规则集将数据存储在这些OSD节点上】。step chooseleaf 的type rack部分即为故障域，在下面示例中也是指的机架。【译者注：故障域即是人为根据业务服务机器部署情况划分的一些逻辑概念，比如地区、数据中心、机房、机架、交换机等等等】

##
# SYSTEM RULE DECLARATION
##

rule rgw-system {
　ruleset 1
　type replicated
　min_size 1
　max_size 10
　step take sas-ssd
　step chooseleaf firstn 0 type rack
　step emit
}

【注】

在上述的例子中，如果数据是3副本的话，则集群中至少应有三个机架包含相似数量的OSD节点。【译者注：规则集的设置很重要，不但要考虑集群部署方面的节点划分同时也要在使用时考虑建存储池副本的情况】

【提示】

type replicated的设置与数据持久性、副本数量或纠删码无关。仅支持副本方式

以下示例阐明了存放数据池的CRUSH层次结构规则。和系统规则一样，这个例子中root sas-ssd也作为一个主的CRUSH层级结构。便于区分ruleset 0和ruleset 1， 这里会使用ruleset 2。 step take sas-ssd 这行会告知存储池使用CRUSH Root中创建的 sas-ssd root。 这里CRUSH Root的子级存储桶中包含了配备如SAS驱动接口SSD日志盘的高吞吐硬件OSD。 step chooseleaf 的type host部分即为故障域，在下面示例中指的是主机。需要注意的是，规则集使用了相同的CRUSH层级结构但是设置了不同的故障域。

##
# THROUGHPUT RULE DECLARATION
##

rule rgw-throughput {
　ruleset 2
　type replicated
　min_size 1
　max_size 10
　step take sas-ssd
　step chooseleaf firstn 0 type host
　step emit
}

【注】

在上述例子中，如果存储池使用纠删码策略并且数据块个检验块的数量大于默认值的话，集群中至少应应包含同样多的机架，而这些机架也应当包含相似数量的OSD节点。小规模的集群的话这可能不太实际，所以上述例子使用了host作为故障域。

下面的例子阐明了存放索引存储池层级结构的规则。这个例子中，使用root 索引作为主层级结构。便于区分ruleset 0和ruleset 1和ruleset 2，这里使用ruleset 3。 step take index 这行会告知存储池使用CRUSH Root中创建的 index root。 这里CRUSH Root的子级存储桶中包含了配备如SSD盘的高IOPS硬件OSD。step chooseleaf 的type rack部分即为故障域，在下面示例中指的是机架。

##
# INDEX RULE DECLARATION
##

rule rgw-index {
　ruleset 3
　type replicated
　min_size 1
　max_size 10
　step take index
　step chooseleaf firstn 0 type rack
　step emit
}

5.2.创建ROOT存储池

Ceph对象网关的配置信息存储在名为.rgw .root的池中，包括命名空间，区域组标识和区域标识。按照惯例，它的名字不会以区域标识名称作为前缀。

.rgw .root

正常运行的Ceph存储集群，应用新的规则集来创建.rgw .root存储池。关于PG数量与每个存储池的PG数等详细信息，可以参考《存储池PG计算》与 《PG》。有关创建存储池的详细信息，可以参考《创建存储池》。在这种情况下，存储池对应的数据持久化方式将使用副本方式 而非纠删码方式。例如，

# ceph osd pool create .rgw.root 32 32 replicated sas-ssd

【注】

对于包括.rgw .root的系统存储池，《存储池PG》中则建议设置的PG数量要远低于每个OSD的目标PG数量【译者注：这里的意思就是说，对于只用来存储配置信息的诸如系统存储池，设置的PG数不宜过大；个人建议一般将pg设为8即可】。另外，要确保在计算的第3步中设置了OSD的数量。

一旦存储池创建完毕，Ceph对象网关就可以把配置信息存储到这个创建的池中了。

5.3.配置命名空间

Ceph中的存储池支持Ceph对象网关使用区域分组中的某一个区域标识，默认情况下，Ceph对象网关会定义名称为default的区域分组与区域标识。【译者注：realm是Ceph集群中独立的命名空间，每个realm可以包括多个区域分组zone group从而来实现区域分组之间的信息同步以此实现多站点的需求。另外，每个realm都有当前的period以及一组按照时间顺序排列的period 列表】

对于master区域分组和区域标识，RedHat则建议创建新的命名空间、区域分组与区域标识，然后删除默认的区域标识和所对应的存储池（如果已经自动生成这个默认标识的话）。参考《配置master区域标识》作为最佳配置方法，因为这可以将集群配置为多站点操作。

1.创建命名空间【译者注：原英文链接地址无效，新链接地址为redhat站内搜索的相关说明】，更多信息可以参考命名空间。

2.创建master区域分组【译者注：原英文链接地址无效，新链接地址为redhat站内搜索的相关说明】，区域分组相关信息可以参考区域分组。

3.创建master区域标识【译者注：原英文链接地址无效，新链接地址为redhat站内搜索到的相关说明】，更多的信息可以参考区域标识。

4.删除默认的区域分组与区域标识【译者注：原英文链接地址无效，新链接地址为redhat站内搜索的相关说明】。如果存储池被创建后没有存储客户数据，可以将其删除，但是要注意一定不要删除 .rgw .root存储池。

5.创建系统用户【译者注：原英文链接地址无效，新链接地址为redhat站内搜索到的相关说明】。

6.更新period【译者注：原英文链接地址无效，新链接地址为redhat站内搜索到的相关说明】。

7.更新Ceph配置文件【译者注：原英文链接地址无效，新链接地址为redhat站内搜索到的相关说明】。

【注】

此过程省略了启动网关的步骤，因为网关可能会手动创建存储池。如果想要指定特定的CRUSH规则集和数据持久方式（副本方式或纠删码方式），请手动创建存储池。

通过设置新的命名空间、区域分组和区域标识，现在可以准备将集群扩展成为多站点集群（即区域分组中包括多个区域标识）。这也意味着集群可以通过扩展和配置来应对故障转移以及灾备恢复。详细内容可以参考使用多站点扩展集群。

RedHat下一代Ceph存储中，默认的多站点配置就是active-active。当部署多站点群集时，区域标识及其底层Ceph存储群集可能位于不同的地域。因为每个区域标识都有相同名称空间中每个文件的深拷贝副本【译者注：类似程序中对象的深拷贝，即原对象与目标对象内容上完全一致】，所以用户可以从物理上距离它们最近的地方来访问对象，从而减少了跨区域的（网络）延迟。当然，如果从区域标识仅仅为了故障转移与灾备那么集群也可能配置为active-passive架构。

【注】

区域分组中包括多个区域标识目前是支持的，但多个区域分组这种情况，只是技术上的一个预览而已，生产环境中并不支持。

5.4.创建系统存储池

Ceph对象网关为各种系统功能使用了许多存储池，还有一组独立的存储池用于存储存储桶索引，数据和其他信息。

由于存储池中PG的peering过程会占用过多的计算开销，因此RedHat通常建议Ceph对象网关在PG数量分配上，系统存储池的PG应该要远少于数据存储池的PG。

系统存储池存储系统控制相关的对象，如：垃圾回收、登录、用户信息、使用记录等。按照惯例，这些存储池的名字会以区域标识作为前缀来命名。

• ..rgw.control: 控制存储池。
• ..rgw.gc: 垃圾回收存储池，包括删除对象的哈希桶。
• ..log: 日志存储池，包括所有与桶/容器与对象相关的一些操作，如创建、读、更新、删除。
• ..intent-log: 意图日志存储池，当请求失败时，为了undo/redo方便，而记录的对象更新副本。
• ..users.uid: 用户ID存储池，包括唯一用户ID的映射。
• ..users.keys: 授权key存储池，包括了每一个用户ID对应的访问key与私密key。
• ..users.email: 邮件地址存储池，包括了与用户ID相对应的邮件地址信息。
• ..users.swift: Swift存储池，包括了用户ID对应的Swift子账户信息。
• ..usage: 使用记录存储池，包括每个用户基本的使用记录信息。

执行获取区域标识步骤可以查看存储池名称。

　# radosgw-admin zone get [–rgw-zone=]

当用radosgw-admin创建一个区域标识的时候，存储池的名称应当 以这个区域标识为前缀命名。例如,区域标识如果名称为us-west，那么存储池名称也应当像下面这样：

{　“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
　　　　　　}
　　}
　]
}

以control_pool存储池开始，以user_uid_pool存储池结束，将区域标识名称预先添加到存储池名称中，然后使用区域标识中的存储池名称来创建存储池。继续前面的例子，存储池的创建可能像下面这样：

# Ceph osd pool create .us-west.rgw.control 32 32 replicated rgw-system
…
# Ceph osd pool create .us-west.users.uid 32 32 replicated rgw-system

在前述的例子中，rgw-system规则集表示CRUSH层级结构，在这一层级结构中，配以rack作为故障域以及SAS驱动接口SSD日志盘。可以参考之前的创建CRUSH Root、创建CRUSH 规则集章节。

对于PGS数量的设置可以可以参考《存储池PG计算》与 《PG》。有关创建存储池的详细信息，可以参考《创建存储池》。

【注】

对于系统存储池，建议的PG数量要远小于每个OSD上的目标PG数量。确保在第3步计算PG数时提供正确的OSD数量。

通常，.rgw .root存储池和系统存储池应当使用相同的CRUSH层次结构，并且至少将node 用于CRUSH规则集中的故障域。如.rgw .root存储池一样，系统存储池也应该使用副本 方式而不是纠删码 的数据持久化方式。

5.5.创建数据放置策略

Ceph对象网关有一个名称为default-placement的默认存储策略。如果集群只有一个存储策略，那么这个默认的default-placement策略也可以满足需求。这个默认放置策略引用自区域分组配置，并在区域标识配置中定义。

更详细内容可以参考《存储策略》。

对于支持多种业务场景的集群（如面向IOPS优化，吞吐量优化或容量优化的集群），区域分组配置中的一组放置目标与存储池代表了每一种不同的存储策略。

随后的例子也会说明如何创建存储策略以及使之成为默认的策略。这个例子会假定默认的策略使用吞吐优化型的硬件配置。内容包括：

• 创建存储桶索引池
• 创建数据存储池
• 创建存储桶附加存储池
• 在区域分组中配置放置目标
• 在区域标识中配置放置存储池
• 数据放置总结

5.5.1.创建存储桶索引池

默认情况下，Ceph对象网关将存储桶的对象映射到存储桶索引，这使得网关客户端可以请求存储桶中的对象列表。虽然常见的场景可能涉及用户拥有一个存储桶并且每个存储桶的对象数量有限额，但存储桶本身可以存储无数的对象。当存储桶存储数百万个对象时，存储桶索引性能将大大受益于使用SSD或其他高性能存储介质来存储其数据。此外，对存储桶划分还可显著的提高性能【译者注，sharding一般常用于数据库中，这个对存储桶也进行sharding其目的与数据库一样】。

对于PGS数量的设置可以可以参考《存储池PG计算》与 《PG》。有关创建存储池的详细信息，可以参考《创建存储池》。

【注】

每个存储池计算器的PG数建议少于存储桶索引池的PG数;然而，总的PG统计值大约是系统存储池PG数量的两倍。

创建一个存储桶索引池，可以执行Ceph osd pool create 后面跟上池名称、PG数量、PGP数量、副本数据的持久化方式以及规则集名称，例如：

# Ceph osd pool create .us-west.rgw.buckets.index 64 64 replicated rgwindex

在前述的例子中，rgw-index规则集代表了CRUSH层级结构，在这一层级结构中，配以rack作为故障域以及SSD作为驱动盘。可以参考之前的存储桶索引选择SSD、创建CRUSH Root、创建CRUSH 规则集章节。

【重要提示】

如果存储桶存储对象数量超过100K，则需要配置存储桶分区以确保存储桶索引性能不会随着桶内对象的增加而下降。内容可以参考配置存储桶分区。如果最初的配置不适合的话，可以参考存储索引桶重新分区。

5.5.2.创建数据存储池

Ceph对象网关根据特定的存储策略将对象数据存储在数据存储池中。数据存储池应该有完整的PG，而不是如系统存储池所简化后的PG数量。数据存储池应当考虑使用纠删码方式，因为它比副本方式效率更高效，可以在保持数据持久性的同时显着降低容量要求。

使用与创建纠删码的配置，可以在《存储策略指南》中参考纠删码配置章节。

【重要提示】

因为创建存储池之后不能改变配置，所以选择正确的配置内容是非常重要的。如果想修改一个配置，则必须以不同的配置内容来创建一个新的存储池，并且将存储池内的对象由旧池迁移到新建的存储池中。

默认会配置2个数据块和1个校验块，这也意味着只能丢失一个OSD。为了具备更高的弹性，可以考虑一个更大的数据/校验块比例。例如，一些大规模的系统使用8个数据块3个校验块来保障即使有3个OSD出现故障也不会丢失数据。

【重要提示】

每个数据和校验块应至少存储在不同的节点或主机上。对于较小的群集，当使用大量数据和校验块时，使用rack(机架)作为最小的CRUSH故障域也不太实际。因此，数据存储池通常使用单独的CRUSH层次结构，并将主机作为最低的CRUSH故障域。RedHat建议host(主机)作为最低的CRUSH故障域。如果纠删码数据块也存储于同一个主机上，则诸如日志或网卡的损坏都会导致数据的丢失【译者注：这种一定要注意，因为Ceph就是想利用数据的多副本存储来保证数据的可靠性，因为机器数量等原因而选择低于主机的故障与就完全违背了使用Ceph的意义】。

创建一个数据存储池，可以执行ceph osd pool create 后面跟上池名称、PG数量、PGP数量、纠删码数据的持久化方式、纠删码配置以及规则集名称，例如：

# Ceph osd pool create .us-west.rgw.buckets.throughput 8192 8192 erasure 8k3m rgw-throughput

在前述的例子中，rgw-throughput规则集表示CRUSH层级结构，在这一层级结构中，配以host作为故障域以及SAS驱动接口的SSD日志盘。可以参考之前的创建CRUSH Root、创建CRUSH 规则集章节。

5.5.3.创建存储桶附加存储池

data_extra_pool用于存放非纠删码的数据。例如，分块上传允许分多个部分来上传大的对象（如电影）。这些单独上传的部分首先必须以非纠删码方式进行存储。纠删码将应用于整个对象，而不是部分上传。

【注】

每个存储池计算器的PG数建议少于data_extra_pool的PG数;然而，总的PG统计值大约是系统存储池PG数量的两倍，与存储桶索引池相同。

创建一个数据附加存储池，可以执行Ceph osd pool create 后面跟上池名称、PG数量、PGP数量、副本数据的持久化方式以及规则集名称，例如：

# Ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgwsystem

5.5.4.在区域分组中配置放置目标

一旦存储池被创建之后，在区域分组中创建放置目标。查看区域分组内容，执行以下内容后就会将区域分组配置信息输出到zonegroup.json文件中：

#　radosgw-admin zonegroup get [–rgw-zonegroup=] > zonegroup.json

输出的文件内容类似如下：

>

{
　“id”: “90b28698-e7c3-462c-a42d-4aa780d24eda”,
　“name”: “us”,
　“api_name”: “us”,
　“is_master”: “true”,
　“endpoints”: [
　　　“http:\/\/rgw1:80”
　],
　“hostnames”: [],
　“hostnames_s3website”: [],
　“master_zone”: “9248cab2-afe7-43d8-a661-a40bf316665e”,
　“zones”: [
　　　{
　　　　“id”: “9248cab2-afe7-43d8-a661-a40bf316665e”,
　　　　“name”: “us-east”,
　　　　“endpoints”: [
　　　　　　“http:\/\/rgw1”
　　　　],
　　　　“log_meta”: “true”,
　　　　“log_data”: “true”,
　　　　“bucket_index_max_shards”: 0,
　　　　“read_only”: “false”
　　　},
　　　{
　　　　“id”: “d1024e59-7d28-49d1-8222-af101965a939”,
　　　　“name”: “us-west”,
　　　　“endpoints”: [
　　　　　　“http:\/\/rgw2:80”
　　　　],
　　　　“log_meta”: “false”,
　　　　“log_data”: “true”,
　　　　“bucket_index_max_shards”: 0,
　　　　“read_only”: “false”
　　　}
],
“placement_targets”: [
　　{
　　　　“name”: “default-placement”,
　　　　“tags”: []
　　}
],
“default_placement”: “default-placement”,
“realm_id”: “ae031368-8715-4e27-9a99-0c9468852cfe”
}

placement_targets部分会列出每一个存储策略。默认会包含名称为default-placement 的放置目标。在placement_targets配置段，默认的放置目标立即就会被识别。

假如有一个名称为throughput-optimized放置目标，并且是默认的放置目标，那么区域分组配置中placement_targets 配置段中default_placement的设置应该修改成如下这种：
>

{
　…
　“placement_targets”: [
　　{
　　　“name”: “throughput-optimized”,
　　　“tags”: []
　　}
　],
　“default_placement”: “throughput-optimized”,
　…
}

最后，使用修改后的zonegroup.json文件中的设置来设置区域组配置;然后更新period时间。例如：
>

# radosgw-admin zonegroup set [–rgw-zonegroup=] –infile zonegroup.json
# radosgw-admin period update –commit

5.5.5.在区域标识中配置放置存储池

一旦区域分组有新的throughput-optimized放置目标，需要将throughput-optimized 映射到区域配置文件中的放置存储池中。这一步骤会用一组throughput-optimized存储池来替换default-placement存储池进而实现新的放置映射关系。

查看区域标识可以执行下面步骤。

# radosgw-admin zone get [–rgw-zone=] > zone.json

假如区域标识名称是us-west，那么输出文件的内容类似如下：

{　“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
　　　　　　　　}
　　　}
　]
}

区域配置文件中的placement_pools配置段定义了一组放置存储池。其中每一组放置存储池又定义了一种存储策略。修改区域配置文件，去除名称为default-placement 的默认放置存储池，并更新为之前创建的名称为throughput-optimized的存储池。例如：

{
…
“placement_pools”: [
　　{ “key”: “throughput-optimized”,
　　　“val”: { “index_pool”: “.us-west.rgw.buckets.index”,
　　　　　　“data_pool”: “.us-west.rgw.buckets.throughput”}
　　　　　　“data_extra_pool”: “.us-west.rgw.buckets.non-ec”,
　　　　　　“index_type”: 0
　　}
　]
}

最后，使用修改后的zone.json文件中的设置来设置区域配置;然后更新period时间。例如：

# radosgw-admin zone set –rgw-zone={zone-name} –infile zone.json
# radosgw-admin period update –commit

【注】

index_pool指向具有SSD或其他高性能存储的索引池和CRUSH层次结构，data_pool指向具有完整PG的存储池，以及高吞吐量主机总线适配器，SAS驱动接口SSD日志盘的CRUSH层次结构。

5.5.6.数据放置总结

当处理客户端的请求时，Ceph对象网关将会使用新的throughput-optimized放置目标作为默认的存储策略。用这一过程在多站点配置中的不同区域标识和区域分组中建立相同的目标，并根据需要替换池的区域名称。

用这一过程建立其它的存储策略。对于每一个放置目标及对应一组存储池的名称可以是任意的。比如fast, streaming, cold-storage或任何适合的名称都可以。

但是需要注意的是，每个名称必须在区域分组配置的placement_targets下有相应的设置，并且必须 在default_placement设置中引用其中一个目标;同时这个区域标识必须为每个策略配置相应的一组存储池。

如果客户端不指定X-Storage-Policy的话，那么客户端总是会使用默认的放置目标。获取对象网关客户端的使用示例可以参考创建容器。

第6章 配置网关

准备用于生产环境Ceph对象网关的最后步骤涉及配置Civetweb，防火墙端口，DNS和负载均衡。内容包括：

• 配置Civetweb
• 配置防火墙端口
• 配置DNS通配符
• 配置负载均衡

6.1.配置Civetweb

根据安装Ceph对象网关时的选择，Ceph配置文件已经包含了涉及修改配置命名空间的每个Ceph对象网关实例。对默认的配置进行修改最常见的就是将默认的端口由7480更改为8080或者80。可以参考修改默认端口。

其它特殊的Civetweb设置可以参考Civetweb配置选项。

还有其他的设置也可能会被覆盖，可以参考对象网关配置。

【注】

其它应用案例部分将提供使用Ceph对象网关和第三方组件的详细配置示例。

6.2.配置防火墙端口

如果修改默认的Civetweb端口，要确保所修改的端口客户端有权访问。详细内容可以参考配置防火墙。

6.3.配置DNS通配符

S3风格的子域会将存储桶名称作为CNAME的扩展名。若实现S3风格的子域可以将通配符添加到DNS中。详细内容可以参考DNS中增加通配符。

6.4.配置负载均衡

处理线上请求并保持服务高可用，比较典型的就是在一个区域中部署多个Ceph对象网关。生产环境的集群一般也使用负载均衡来分配客户端请求到网关实例上。

另外，早期版本的Civetweb并不支持HTTPS。配置负载均衡可以接受SSL请求、终止SSL连接以及通过HTTP将请求发送到网关实例中。

Ceph存储其目地在于保持高可用。基于此，RedHat建议使用HAProxy/keepalived。详细内容可以参考HAProxy/keepalived配置。

第7章 其它应用案例

一旦集群开始运行并且服务为在线状态，也需要考虑一些应用上的案例。

• 使用多站点扩展集群
• 使用NFS-Ganesha迁移数据
• 配置集群静态虚拟主机
• 为LDAP/AD配置集群
• 配置集群使用Keystone

7.1.使用多站点扩展集群

在设计存储策略时，创建命名空间的过程确保了已经将集群配置为使用具有自己命名空间、主区域分组以及主区域标识的多站点集群。

一个典型的生产集群也会在独立的地方拥有一个从属区域标识，并且拥有自己的Ceph存储集群，以便在灾难发生时充当备份的角色。重复指南中的步骤就可以部署一套从属区域标识。通常从属区域标识中的硬件配置和规模应该与主区域标识一致。详细内容可以参考《配置一套从属区域标识》。

添加从属区域标识可以提高集群的故障转移与灾备恢复能力。

7.2.使用NFS-Ganesha迁移数据

如果Ceph对象网关与Ceph存储集群替代基于文件系统的存储方案，那么可以考虑使用Ceph的NFS-Ganesha方案将文件系统中的数据迁移至Ceph对象网关。

可以参考将Namespace导出到NFS-Ganesha(技术预览)。

7.3.配置集群静态虚拟主机

传统的网络主机有时需要为每个站点设置一个web服务器，当内容不会动态变化时，这些服务器的资源利用极其低效。

Ceph对象网关可以在S3存储桶中托管静态网站，也就是说，如PHP，servlet，数据库，nodejs等不使用服务器端服务的网站。这种方式很明显要比为每一个站点启动一套虚拟机更加的经济。

更多的细节可以参考静态虚拟主机配置网关。

7.4.配置集群与LDAP/AD集成

为其用户和应用程序部署Ceph对象网关的组织可能会选择使用轻量级目录访问协议（LDAP）或Microsoft Active Directory（AD）来用Ceph对象网关进行身份验证，以代替创建Ceph对象网关用户。

使用LDAP/AD意味着Ceph对象网关可以与LDAP/AD单点登录计划组织进行集成。

详细内容可以参考《使用LDAP/AD Ceph对象网关指南》。

7.5.配置集群使用Openstack Keystone

当部署Ceph对象网关代替Openstack的Swift时，也可以配置网关使用Openstack Keystone对用户进行身份验证以此代替创建Ceph对象网关用户。

详细内容可以参考《使用Keystone对Ceph对象网关用户进行身份验证》。