Ceph的性能调优：Ceph学习系列8

红帽 Ceph调优关键点

Ceph 守护进程和客户端在 Linux 服务器上运行。这意味着，适当调优操作系统可以对存储集群的性能产生积极的影响。与 Ceph 相关的重要操作系统子系统会影响 I/O、联网 I/O 和本地 Linux 文件系统。

调优检查清单

由于 Ceph 是一种分布式系统，管理员必须在所有服务器上调优所有组件。最佳的 Ceph 性能需要考虑以下几方面：

选择正确的 CPU 和内存。OSD、MON 和 MDS 节点具有不同的 CPU 和内存需求。纠删代码需要更多 CPU。

如果不需要，则关闭 NUMA。

仔细计算需要的节点数量，以及各个存储节点的磁盘要求。

选择 SAS、SATA 或 SSD，在磁盘成本、吞吐量和延迟之间找到良好的平衡。

SSD 磁盘用于日志。

如果交换机支持 (MTU 9000)，则启用巨型帧。如果将 Ceph 与 OpenStack 搭配使用，则所有 MTU 必须具有相同的设置。

启用 NTP。Ceph 进群对时间很敏感。

内部集群网络至少需要 10 GB 带宽。

 

 

 

性能调优的定义

性能调优是针对特定的应用定制一个或一组系统的配置的过程，从而使应用具有尽可能最佳的响应时间或吞吐量。Ceph 集群的性能调优具有三个维度：延迟、IOPS、及吞吐量。

 

什么是延迟？

常见的误解认为磁盘延迟和响应时间是同一事物。磁盘延迟是设备的一种功能，而响应时间是对整个服务器功能的测量。对于使用旋转磁碟的硬盘驱动器而言，磁盘延迟具有两个组成部分：

寻道时间：驱动器磁头定位到磁碟上正确轨道所需的时间。这通常为大约 0.2 到 0.8 毫秒。

旋转延迟：该轨道上正确起始扇区通过驱动器磁头所需的额外时间。大致的值基于驱动器速度。5,400 RPM 为 5.6 毫秒；7,200 RPM 为 4.2 毫秒；10,000 RPM 为 3  毫秒，15,000 RPM 则为 2 毫秒。

在驱动器定位了磁头后，它开始从磁碟传输数据。这时，顺序数据传输速率很重要。

每秒 I/O 操作数 (IOPS)

系统每秒钟可以处理的读取和写入请求数量高度依赖于存储设备的能力和具体的应用。当应用发出 I/O 请求时，操作系统将请求传输到设备，再等待请求完成。

通过 iostat -x 命令，您可以在 await 列下查看每个设备的这一等候时间。r_await 和 w_await 列中提供了读取和写入请求的等候时间。%iowait 列是系统的全局等候时间。

什么是吞吐量？

吞吐量指的是系统每秒钟可以读取或写入的实际字节数。块大小和数据传输速度会影响吞吐量。磁盘块大小越大，延迟因素的影响越弱。数据传输速度（即磁盘将数据从其表面传输到缓冲区的速度）越高，设备也就越快将数据传输到缓冲区。

您还可以测量网络、乃至整个系统的吞吐量，不论是远程客户端还是服务器。

 

 

 

调优目标

您使用的硬件限制了系统和 Ceph 集群的性能。性能调优的目标是尽可能高效地使用这种硬件。

但是，您应该要注意，对特定子系统进行调优通常会给另一子系统的性能造成不利影响。例如，您可能会以牺牲高吞吐量为代价，调优系统的低延迟。因此，在开始之前，您应该根据 Ceph 集群的预计工作负载制定自己的目标。

优化 IOPS。块设备上的工作负载通常是 IOPS 密集型；例如，在 OpenStack 中虚拟机上运行的数据库。对于 RBD，OSD 日志应当位于 SSD 或 NVMe 设备上。

优化吞吐量。Ceph 对象网关上的工作负载通常是吞吐量密集型。对象可以存储大量的数据，如音频和视频内容。

优化容量。要求以尽可能低的成本存储大量数据能力的工作负载通常会以牺牲性能为代价。这类工作负载的解决方案是选用价格较低、速度较慢的 SATA 驱动器。

因此，根据您的工作负载，调优目标应当是：

降低延迟

提高设备的 IOPS

增加块大小

与吞吐量相比，延迟和 IOPS 比较难以调优。

应用调优更改

通过 sysctl 命令以及相关的 /etc/sysctl.conf 文件和 /etc/sysctl.d/ 目录，管理员可以修改大多数的内核可调项。

sysctl -a 命令可列出所有可调项及其实际值。管理员可以通过 sysctl -w tunable=value 命令暂时更改某一可调项值。若要持久生效，您应该将可调项添加到 /etc/sysctl.d/ 目录下的自定义 .conf 文件中。

[ceph@serverc ~]$
sysctl net.ipv4.tcp_{r,w}mem
net.ipv4.tcp_rmem = 4096      87380   10485760
net.ipv4.tcp_wmem = 4096      16384   10485760
[ceph@serverc ~]$
sudo vim /etc/sysctl.d/ceph.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
[ceph@serverc ~]$
sudo sysctl -p /etc/sysctl.d/ceph.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
[ceph@serverc ~]$
sysctl net.ipv4.tcp_{r,w}mem
net.ipv4.tcp_rmem = 4096      87380
16777216

net.ipv4.tcp_wmem = 4096      16384
16777216
1.
1.
1.
1.
1.
1.
ceph-ansible playbook 支持在部署期间设置 sysctl 可调项。这可以在 group_vars/all.yml 组变量文件中为所有节点进行设置。os_tuning_params 变量将一个散列列表取为参数，每个可调项一个散列。每个散列应设置两个变量：使用 sysctl 的名称的 name，以及含有其设置的 value。

...output omitted...

os_tuning_params:
- { name: net.ipv4.tcp_rmem, value: "4096 87380 16777216" }
- { name: net.ipv4.tcp_wmem, value: "4096 16384 16777216" }
...output omitted...
1.
2.
3.
4.
5.
6.

 

 

使用 Tuned 快速调优

红帽 企业 Linux 中包含 tuned-adm 工具，它可帮助系统管理员针对不同的工作负载进行系统调优。tuned-adm 工具附带的调优 profile 可以针对不同的目标进行系统调优，如功耗节省和网络吞吐量。系统管理员可以创建新的 profile 来满足自己的要求。

您可以使用下列命令，选择最合适的 profile：

tuned-adm list，列出现有的 profile：

[ceph@serverc ~]#
tuned-adm list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optimize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost
of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost
of increased power consumption, focused on low
latency network performance
- network-throughput          - Optimize for streaming network throughput,
generally only necessary on older CPUs or
40G+ networks
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent
performance across a variety of common server
workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest
1.
tuned-adm active，列出活跃的 profile。

tuned-adm profile profile-name，使用profile。

tuned-adm off，禁用任何活跃的 profile。

对于 Ceph，管理员应根据自己的要求选择 profile。不同的 OSD 节点可能会分配到不同的 profile。其中两个可能会符合要求：

network-latency 基于 latency-performance profile，可以改进全局系统延迟。

network-throughput 基于 throughput-performance profile，可以改进全局系统吞吐量。

 

 

磁盘子系统 I/O 说明
Linux 块 I/O 层正在处于转变过程中。不同类型的设备使用两种备选机制之一来支持 I/O 请求提交至块设备。较旧的 Linux I/O 调度程序由 SATA 和 SAS 硬盘驱动器及 SSD 使用，它围绕一种可配置的elevator算法构建。较新的多队列块 I/O 排队机制 (blk-mq) 旨在支持 NVMe SSD 提供的更高性能，最终有望全面取代当前的调度程序。

Linux 内核 I/O 调度程序

传统的 Linux I/O 调度程序目前由 SATA 和 SAS 硬盘驱动器以及 SSD 使用，它会主动尝试重排和合并对磁盘的请求。磁盘请求不会立即发送到磁盘控制器，而是置于队列之中。当请求仍然在队列中时，一种称为磁盘elevator的算法可以对它们进行重排和合并。内核附带了几种elevator或 I/O 调度程序，它们针对不同种类的 I/O 工作负载进行了优化。管理员可以为系统上的各个块设备选择不同的 I/O 调度程序。若要查看某一设备当前及可用的elevator，可以检查 /sys/block/device/queue/scheduler。

[ceph@serverc ~]$
cat /sys/block/
sdb
1.
/queue/scheduler
noop deadline [cfq]
1.
这显示了三种可用的elevator，其中 cfq 为当前选定的。系统通常会选择最合适的elevator，但您可以通过将所需elevator的名称回显到 scheduler 文件中来进行更改：

[ceph@serverc ~]# sudo sh -c "echo deadline > /sys/block/sdb/queue/scheduler"
1.
不同的elevator具有不同的属性。下表列出了这些elevator的主要属性：

noop：noop elevator什么也不会做。它将磁盘队列转变为 FIFO（先进先出）。

如果后端存储设备也能重排和合并请求，并且对背后的实际磁盘布局有更好的了解，管理员通常会选择 noop。这是虚拟机内磁盘的默认调度程序。

它也通常用于 SSD 等设备，这些设备的响应速度通常快于请求到达的速度。

deadline：deadline  elevator将排入队列的 I/O 请求一起分组到读取或写入批次中。deadline 调度程序尽力为请求提供有保障的延迟，相对于写入请求，它会优先考虑读取请求。

deadline 最适合有多个进程执行大型 I/O 操作的磁盘；例如，数据库服务器或文件服务器。

对于 Ceph 而言，这通常是 SATA 和 SAS 驱动器的首选调度程序。

cfq：cfq elevator（完全公平排队）适合有许多进程同时读取和写入大小不等的请求的磁盘。cfq 引入了多个 I/O 类别和优先级，以便在访问磁盘时管理员可以将特定进程的优先级排在其他进程的前面。若要利用这些类别和优先级，可以使用 ionice 命令。

 

blk-mq 调度机制

标准的 I/O 调度程序是面向机械硬盘而设计的，以毫秒级的延迟运行，并且最多支持每秒数百个 I/O 操作。新型多队列块 I/O 排队机制称为 blk-mq，它绕开了传统的调度程序。从长期角度来看，这种新系统设计为处理具有微秒级延迟、数百万 IOPS 及大型内部并行度的存储。如果您的设备驱动程序基于 blk-mq，其 /sys/block/device/queue/scheduler 文件中会将调度程序设置为 none。您不应更改此设置。在红帽 企业 Linux 7.5 中，这目前包括 virtio-blk、mtip32xx、nvme 和 rbd 驱动程序。

 

 

 

网络 I/O的优化
优化吞吐量

客户端通过网络访问 Ceph 集群中存储的数据，尽可能拥有最好的网络非常重要。Linux中网络调优利用 sysctl 参数来实现。具体包含以下几个方面：

针对 10 GbE 网络设备调优

高带宽链路可能会导致环形缓冲区占满的状况。环形缓冲区是网络设备上的一个内存块。当设备收到数据包时，会将它存储在这个内存中，并向内核发送一个中断。而后，内核会检索数据包。当环形缓冲区填满的速度快于内核可以摄取的速度的时，数据包会开始被丢弃。管理员使用 ethtool 命令来设置环形缓冲区的大小。

缓冲区内存管理

Linux 为每个 TCP/IP 连接保留缓冲区，但默认值或许不适合所有链路。

管理此缓冲区的参数有三个，各自取三个值作为引数：

net.ipv4.tcp_wmem 设置 OS 接收缓冲区值

net.ipv4.tcp_wmem 设置 OS 发送缓冲区值

net.ipv4.tcp_mem 定义 TCP 堆栈如何回应内存使用情况

对于 net.ipv4.tcp_wmem 和 net.ipv4.tcp_rmem 参数，第一个值告知内核一个 TCP socket 的最小缓冲区空间，第二个值告知内核一个 TCP socket 的默认缓冲区空间，第三个值则告知内核一个 TCP socket 的最大缓冲区空间。

对于 net.ipv4.tcp_mem 参数，第一值告知内核低位阈值，第二个值告知内核何时开始压制内存使用，第三个值则告知内核最大内存页数。

还有两个参数：

net.core_wmem_max 设置所有类型的连接的最大 OS 接收缓冲区大小

net.core_rmem_max 设置所有类型的连接的最大 OS 发送缓冲区大小

系统管理员通常不更新 net.ipv4.tcp_mem 参数，因为新近的内核可以根据可用 RAM 大小提供良好的自动调优数据。

 

巨型帧

以太网网络具有标准的最大传输数据包大小，称为最大传输单元 (MTU)。以太网标准将它设置为 1500 字节。为提高吞吐量并减少处理开销，一种策略是将以太网网络配置为允许设备发送和接收更大的巨型帧。这意味着，可以发送一个大帧，而不是几个小帧，来传输同样的载荷。巨型帧的官方最大大小为 9000 字节，但一些设备还支持更大的帧。

在使用巨型帧时要谨慎，因为连接以太网网络的所有设备都要求支持所需大小巨型帧的硬件，并且全部需要将网络上对应的以太网接口配置为相同的巨型帧 MTU 大小。这包括客户端计算机、网络交换机、Ceph 节点，以及以太网网络上的任何其他设备。最后，如果流量必须遍历路由器来连接其他以太网网络，路由器接口和其他以太网网络也需要支持至少相同大小的巨型帧，才能完整地受益于使用巨型帧。在实践中，识别和调试 MTU 大小配置错误可能会比较复杂。

 

 

调优 Linux 虚拟内存
进程缓存清空机制

各种内存管理设置可能会对存储和系统性能造成影响。系统需要不时回收物理内存，以阻止内存被填满并呈现出系统不可用。在研究 Linux 如何回收内存前，首先需要了解内存页可能会处于的不同状态。这些不同的状态包括：

Free：页面可用于立即分配。

Inactive clean：页面不在活跃使用状态，其内容对应于磁盘上的内容，因为它已被写回或者自读取后没有变化。

Inactive dirty：页面不在活跃使用状态，但页面内容已在从磁盘读取后修改并且尚未写回。

Active：页面在活跃使用状态，并且不是要释放的候选者。

系统必须将脏页面写到磁盘，以便内存不会被填满。由于内存具有易失性（内容在掉电后丢失），脏页面也需要写出到磁盘上，以防止数据在电源故障时丢失。

有两个使用比率的 sysctl 可调项，它们控制何时将数据清空到磁盘：

vm.dirty_background_ratio：脏内存占总系统总内存的百分比，达到此比率时内核会开始在后台写出数据

vm.dirty_ratio：脏内存占总系统总内存的百分比，达到此比率时生成写入的进程停滞，而系统会将内存页清空到后端存储。

还有两个备用可调项 vm.dirty_background_bytes 和 vm.dirty_bytes，设置后会替代对应的比率可调项。这两个可调项以绝对字节数来表示，而非比率值，达到此数值时开始写入。设置了 vm.dirty_background_bytes 或 vm.dirty_bytes 时，对应的比率可调项设置为 0。设置了比率值时，则特定于字节的可调项设置为 0。

设置较低的比率会导致频率更多、但用时更短的写操作，这适合交互式系统或 Ceph 等 I/O 密集型应用。设置较高的比率会导致数量更少、但大小更大的写操作，这会产生较小的系统总开销，但可能会造成交互式应用响应时间变长。

系统管理员可以通过查看 /proc/meminfo 文件来获取当前的脏内存大小：

[ceph@serverc ~]$
grep Dirty /proc/meminfo
Dirty:        4 kB
1.

透明大内存页

红帽 企业 Linux 6.2 引入了支持创建和管理大内存页的内核功能，无需开发人员或系统管理员进行显式干预。此功能称为透明大内存页。

ceph-ansible playbook 和 network-latency 调优 profile 禁用透明大内存页。

NUMA zone 回收

此功能使得 NUMA 能够回收内存以利用 RAM 中数据本地化。回收进程可能会对数据库服务器和 Ceph 等低延迟软件产生负面影响。

ceph-ansible playbook 通过将 /etc/sysctl.d/ceph-tuning.conf 文件中 sysctl 的 vm.zone_reclaim_mode 参数设置为 0 来禁用此功能。

内存压力管理

当大部分内存被消耗时，一组 sysctl 参数会控制系统的行为：

vm.swappiness 决定系统如何在从进程内存到磁盘交换页面与从页面缓存回收内存之间达到平衡。vm.swappiness 接受 0 到 100 范围内的值。

将交换度设置为 100 时，系统基本上始终偏向于交换出页面，而非从页面缓存回收页面。

将它设置为 1 时，系统会尽可能少地执行交换，并从页面缓存回收页面。在 Ceph 节点上，Cep 进程保留在内存中且不被交换出，这一点很重要。ceph-ansible playbook 将 vm.swappiness 的值设置为 10。

vm.min_free_kbytes 是系统尽力保持可用状态的 RAM 大小。在 RAM 大于 48 GB 的系统上，ceph-ansible playbook 会将 vm.min_free_kbytes 参数设置为 4194303 (4 GB)。

 

 

 

调优 文件系统
为 Ceph 创建和挂载文件系统

有两组文件系统可调项参数可能会影响 Ceph。一组在创建之时存储在文件系统中，并可在之后更改。另一组在挂载文件系统时指定。

ceph-ansible playbook 会相应地调优这些参数。

XFS 创建选项

Ceph 利用文件系统扩展属性。XFS 文件系统将这些属性存储在各个索引节点中。为这些属性保留的默认大小是 256 字节，但红帽 建议您将它提高到最大 2048 (2 KB)。

在为 OSD 创建 XFS 文件系统时，ceph-ansible playbook 会为您进行这一设置。不过，您可以在部署节点上使用 /usr/share/ceph-ansible/group_vars/all.yml 文件中的 osd_mkfs_options_xfs 组变量来覆盖格式化选项。它的默认值是 -f -i size=2048。

XFS 挂载选项

XFS 使用 64 位索引节点，但为了与旧应用的兼容性，默认设置为 32 位。若要让索引节点变为 64 位，请使用 inode64 选项。

默认情况下，系统跟踪每个文件的访问时间，并将它存储在索引节点中。Ceph 不需要这一信息，因此您应该使用 noatime 选项。

ceph-ansible playbook 为您设置这些挂载选项。您可以在部署节点上使用 /usr/share/ceph-ansible/group_vars/all.yml 文件中的 osd_mount_options_xfs 组变量来覆盖它们。其默认值为 noatime,largeio,inode64,swalloc。

Ansible 也在 /etc/ceph/ceph.conf 配置文件中设置 osd_mount_options_xfs 参数。ceph-disk 命令在系统启动期间使用这个参数来自动挂载 XFS 文件系统。

 

 

 

调优Linux网络参数
使用 sysctl 命令，检查内核的当前网络缓冲区调优参数。

[ceph@serverc ~]$
sysctl net.ipv4.tcp_rmem
net.ipv4.tcp_rmem = 4096 87380 6291456
[ceph@serverc ~]$
sysctl net.ipv4.tcp_wmem
net.ipv4.tcp_wmem = 4096 16384 4194304
[ceph@serverc ~]$
sysctl net.core.rmem_max
net.core.rmem_max = 212992
[ceph@serverc ~]$
sysctl net.core.wmem_max
net.core.wmem_max = 212992
1.
1.
1.
1.
将最大 socket 缓冲区大小增加到 16 MB。要实现这个目的，可创建含有下列参数值的 /etc/sysctl.d/ceph.conf 文件：

[ceph@serverc ~]$
sudo vi /etc/sysctl.d/ceph.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
1.
您需要 root 特权来创建这个文件。

3. 将更改应用到现有的配置。

[ceph@serverc ~]$
sudo sysctl -p /etc/sysctl.d/ceph.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
1.
4. 若要进行验证，请获取参数值。

[ceph@serverc ~]$
sysctl net.ipv4.tcp_rmem
net.ipv4.tcp_rmem = 4096 87380 16777216
[ceph@serverc ~]$
sysctl net.ipv4.tcp_wmem
net.ipv4.tcp_wmem = 4096 16384 16777216
[ceph@serverc ~]$
sysctl net.core.rmem_max
net.core.rmem_max = 16777216
[ceph@serverc ~]$
sysctl net.core.wmem_max
net.core.wmem_max = 16777216
1.
1.
1.
1.
5.通过删除 /etc/sysctl.d/ceph.conf 文件进行清理。将参数重置为默认值。完成后，从 serverc 注销。

[ceph@serverc ~]$
sudo rm /etc/sysctl.d/ceph.conf
[ceph@serverc ~]$
sudo sysctl -w "net.ipv4.tcp_rmem=4096 87380 6291456"
net.ipv4.tcp_rmem = 4096 87380 6291456
[ceph@serverc ~]$
sudo sysctl -w "net.ipv4.tcp_wmem=4096 16384 4194304"
net.ipv4.tcp_wmem = 4096 16384 4194304
[ceph@serverc ~]$
sudo sysctl -w "net.core.rmem_max=212992"
net.core.rmem_max = 212992
[ceph@serverc ~]$
sudo sysctl -w "net.core.wmem_max=212992"
net.core.wmem_max = 212992

1.
1.
1.
1.
1.

 

 

Ceph调优最佳实践
Ceph 集群的部署必须要正确规划。例如，MON 性能对集群总体性能至关重要。MON 通常应位于专用节点上。为确保正确仲裁，MON 的数量应当为奇数。在 OSD 主机上，操作系统、OSD 数据和 OSD 日志应当位于独立的存储驱动器上，以确保满意的吞吐量。

为容量而构建。如果使用正确的硬件并进行恰当的调优，Ceph 可以实现卓越的性能。

在集群安装后，需要监控集群、调查故障并且安排维护活动，尽管 Ceph 具有自愈功能。如果发生性能问题，首先在磁盘、网络和硬件层面上调查。然后，逐步转向 RADOS 块设备和 Ceph 对象网关。

 

OSD 建议

每一 个Ceph OSD 都具有日志。OSD 的日志和数据可能并置于相同存储设备上，或者它可能是将不同设备用上。

当写操作提交至 PG 中所有 OSD 的日志后，对 PG 的写入被视为已经完成。因此，更快的日志性能可以改进响应时间。

在典型的部署中，OSD 使用延迟较高的传统机械硬盘。为最大化效率，Ceph 建议将单独的低延迟 SSD 或 NVMe 设备用于 OSD 日志。多个日志可以共享同一 SSD，以降低存储基础架构的成本。不过，管理员必须谨慎，不可将过多 OSD 日志放在同一设备上，因为这可能会成为性能瓶颈。应当使用来自首选供应商的认证 SSD 硬件。具体而言，管理员应考虑下列 SSD 规格对预期工作负载的影响：

受支持写入次数的平均故障间隔时间 (MTBF)

IOPS 能力

数据传输速率

总线/SSD 耦合能力

红帽 建议每个 SATA SSD 设备不超过 6 个 OSD 日志，或者每个 NVMe 设备不超过 12 个 OSD 日志。

当用于托管日志的 SSD 或 NVMe 设备出现故障时，使用它托管其日志的每个 OSD 也会变得不可用。这是不将过多日志放在同一存储设备上的另一个原因。

RBD 建议

块设备上的工作负载通常是 I/O 密集型负载，例如在 OpenStack 中虚拟机上运行的数据库。对于 RBD，OSD 日志应当位于 SSD 或 NVMe 设备上。对于后端存储，您可以根据用于支持 OSD 的存储技术（即 NVMe SSD、SATA SSD 或 HDD），为客户提供不同的服务级别。

Ceph 对象网关建议

Ceph 对象网关上的工作负载通常是吞吐密集型负载。如果音频和视频资料存储为对象，它们可能会非常大。不过，bucket 索引池可能会显示更多的 I/O 密集型工作负载模式。管理员应当将这个池存储在 SSD 设备上。

Ceph 对象网关为每个 bucket 维护一个索引。默认情况下，Ceph 将这一索引存储在一个 RADOS 对象中。当 bucket 存储数量巨大的对象时（超过 100,000 个），索引性能会降低，因为只有一个 RADOS 对象参与所有索引操作。

但是，Ceph 可以在多个 RADOS 对象或分片 中保存大型索引。管理员可以通过在 ceph.conf 配置文件中设置 rgw_override_bucket_index_max_shards 配置参数来启用这项功能。此参数的建议值是 bucket 中预计对象数量除以 100,000。

另外，随着索引变大，Ceph 通常需要重新划分 bucket。红帽  Ceph 存储 3 提供了 bucket 索引自动重新划分功能。新的 rgw_dynamic_resharding 配置参数控制这项功能，默认设置为 true。

 

CephFS 建议

存放目录结构和其他索引的元数据池可能会成为 CephFS 的瓶颈。因此，您应该将 SSD 设备用于这个池。

每一 CephFS 元数据服务器 (MDS) 维护一个内存中缓存，用于索引节点等不同种类的项目。Ceph 使用 mds_cache_memory_limit 配置参数限制这一缓存的大小。其默认值以绝对字节数表示，等于 1 GB，可以在需要时调优。但要小心，设置的值不可超过可用的系统内存。

自红帽  Ceph 存储 3 起，您应该使用 mds_cache_memory_limit 配置参数，因为旧的 mds_cache_size 配置参数已被弃用。

 

 

 

将 OSD 日志移到 SSD
OSD 日志是一个重要的元素，影响到 OSD 本身的性能。建议使用 SSD 磁盘等高性能存储设备来存储这一日志。有时候，这一日志最初会安装到同一磁盘的一个分区里，而不是由 OSD 使用的数据分区里。在安装后，可以将这一日志迁移到不同的存储设备或分区，以提供更好的性能。

以下流程支持将 ID osd.3 的 OSD 的日志迁移到不同的设备：

在您的新存储设备（如 SSD）中创建一个或多个分区，以存放日志。

启用 noout 标志，以防止集群在将 OSD 标记为 out 后执行重新平衡。

[ceph@server ~]$ ceph osd set noout
1.
停止与 OSD 相关的服务。

[root@server ~]# systemctl stop ceph-osd@3.service
1.
清空 OSD 的日志。

[ceph@server ~]$ ceph-osd -i 3 --flush-journal
1.
删除由日志使用的设备或分区的链接。

[root@server ~]# rm -f /var/lib/ceph/osd/ceph-3/journal
1.
创建与充当 OSD 日志的新设备或分区的软链接。在本例中，/dev/sdc1 是新设备。

[root@server ~]# ln -s /dev/sdc1 /var/lib/ceph/osd/ceph-3/journal
1.
为 OSD 创建一个新日志。

[ceph@server ~]$ ceph-osd -i 3 --mkjournal
1.
启动与 OSD 相关的服务。

[root@server ~]# systemctl start ceph-osd@3.service
1.
禁用 noout 标志。

[ceph@server ~]$ ceph osd unset noout
1.

 

描述 PG 算法
PG 是逻辑存储池的一个片段。您可以将所需数量的 PG 分配到每个逻辑池。

集群中 PG 的总数可能会影响其总体性能，因为一些 OSD 上有不必要的 CPU 和 RAM 压力。因此，务必要仔细验证每个池的 PG 分配，然后再将它们用到含有集群的生产中。应当要考虑具体测试回填和恢复对客户端 I/O 请求的影响。

有两个重要的值：集群中的 PG 总数，以及特定池的 PG 数量。若要了解应该让多少个 PG 供特定的池使用，可以使用以下公式：

(OSDs * 100)
Total Placement Groups = ------------------
Number of replicas
1.
2.
3.
为每个池应用这个公式，以获取集群的 PG 总数。总数应当为每个 OSD 100 到 200 个 PG，默认为100个。

拆分 PG

Ceph 允许管理员增加池中的 PG 数量。目前不支持减少数量。

您可以通过设置 pg_num 和 pgp_num 参数，使用 ceph osd pool set 命令来增加 PG 数量。pg_num 参数定义特定池的 PG 数量。pgp_num 参数定义 CRUSH 算法考虑用于放置的 PG 数量。

您应当仅以较小的增量来增加池中的 PG 数量。将PG总数设置为 2 的幂，可以将 PG 更好地分布到 OSD。

增加池中 PG 数量的建议做法是，将 pg_num 设置为您希望作为最终值的 PG 数量，同时将 pgp_num 设置为当前的 PG 数量。等待集群的状态变为 HEALTH_OK，这会在所有新 PG 都创建完毕后发生。使用 ceph osd pool set 逐渐增大 pgp_num，直到它等于 pg_num。以足够小的幅度分步执行此操作，以便不会给集群网络或 OSD 造成过大的流量压力。

如何增加每个 Ceph 集群的 PG 数量：

检索集群的当前 PG 设置：

[ceph@serverc ~]$
ceph osd pool get
rbd
1.
pg_num
pg_num: 32

1.
假设您将 PG 数量增加到 64。PG 数量可以一步到位，从当前值增加到新的值。不需要逐步执行这个步骤。

[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pg_num 64
set pool 1 pg_num to 64
1.
PG 数量已增加到 64，但集群还没有开始重新平衡，因为 pgp_num 值仍然是 32。检查 Ceph 集群的运行状况。注意有一个警告。pg_num 值大于 pgp_num 的值。在这一刻，这是正常的。

[ceph@serverc ~]$
ceph osd pool get
rbd
1.
pgp_num
pgp_num: 32
[ceph@serverc ~]$
ceph health
HEALTH_WARN 1 pools have pg_num > pgp_num
1.
1.
PG可以逐步增加，直到集群完全重新平衡为止。在这一操作期间，务必要不断检查 Ceph 集群的运行状况。执行每一命令后等待 PG 完成拆分。

首先，向 pgp_num 添加一个小数字。如果集群和集群网络可以容纳负载，您可以逐渐增加每一步的大小。这里的思路是，以足够慢的速度增加活跃 PG 的数量，使重新平衡流量不会伤害到运行性能。增加 pgp_num 值的每一命令之间的间隔，以及每一步的大小，取决于您的集群及其工作负载的许多不同方面，包括网络、硬件、吞吐量、延迟和性能。

[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 35
set pool 1 pgp_num to 35
[ceph@serverc ~]$
ceph health
HEALTH_WARN 1 pools have pg_num > pgp_num
1.
1.
继续小幅度更改，直到最终 pgp_num 值等于 pg_num 值。注意当 pgp_num 值等于 pg_num 值时，集群运行状况再一次最终变为 HEALTH_OK。

[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 40
set pool 1 pgp_num to 40
...output omitted...
[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 46
set pool 1 pgp_num to 46
...output omitted...
[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 52
set pool 1 pgp_num to 52
...output omitted...
[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 58
set pool 1 pgp_num to 58
...output omitted...
[ceph@serverc ~]$
ceph osd pool set
rbd
1.
pgp_num 64
set pool 1 pgp_num to 64
[ceph@serverc ~]$
ceph osd pool get
rbd
1.
pg_num
pg_num: 64
[ceph@serverc ~]$
ceph osd pool get
rbd
1.
pgp_num
pgp_num: 64
[ceph@serverc ~]$
ceph health
HEALTH_OK
1.
1.
1.
1.
1.
1.
1.
1.

 

设计集群架构
可扩展性

您可用两种方式扩展集群化存储：

横向扩展，即添加更多节点到系统

向上扩展，即添加更多资源到现有节点

Ceph 利用的是横向扩展架构，设计为主要通过添加更多 OSD 节点到 Ceph 集群来进行扩展。

 

Ceph 及其网络

Ceph 集群的网络互连对其性能而言非常重要，因为所有客户端和集群 I/O 操作都依赖于此。红帽 建议采用以下做法：

为增强性能并为故障排除提供更好的隔离，将不同的网络用于 OSD 流量和客户端流量。

尽可能使用 10 GbE 网络。如果 10 GbE 不可用，那么对集群和客户端网络使用绑定的千兆位链路。

必须根据集群和客户端流量，评估网络大小调节。存储的数据量是关键。

强烈建议网络监控。

尽可能使用独立 NIC 来连接网络。如果这不可能，则使用独立的端口。

如下图所示，将不同的网络用于 OSD 和客户端流量展现了这样的网络架构。

 

 

 

您可以在 /etc/ceph/ceph.conf 文件的 [global] 部分中，为 OSD 和客户端流量配置独立的网络：

public network = 172.25.250.0/24
cluster network = 192.0.2.64/24
1.
2.
Ceph 守护进程自动绑定到正确的接口，将 MON 绑定到公共网络，并将 OSD 绑定到公共和集群网络。

配置硬件
Ceph 建议对 OSD 使用下列硬件配置：

将一个磁盘用于操作系统。

每个 OSD 守护进程使用一个驱动器，并且将 SSD 或 NVMe 用于共享日志。

使用多个 10 GbE NIC，至少每个网络一个双链路绑定。

1 GHz per logical CPU core per OSD.

分配 16 GB RAM 基线，外加每个 OSD 2 GB。

MON 硬件示例

红帽 建议每个 MON 在单独的物理计算机上运行，且位于单独的故障realm中。Ceph 需要奇数个 MON（至少三个），并且建议采用下列硬件配置：

将 10,000 RPM 驱动器用于小型和中型集群，将 SSD 或 PCIe NVRAM 用于大型集群。

每个网络使用双链路绑定。

使用一个多核心 CPU。

使用至少 16 GB RAM。

-----------------------------------
©著作权归作者所有：来自51CTO博客作者mob604756f145d3的原创作品，请联系作者获取转载授权，否则将追究法律责任
Ceph的性能调优：Ceph学习系列8
https://blog.51cto.com/u_15127570/2711283