DRBD9和LINSTOR用户指南——优化DRBD性能

优化DRBD性能

20.测量块设备性能

20.1。测量吞吐量

在测量使用DRBD对系统I / O吞吐量的影响时，系统能够提供的绝对吞吐量没有太大关系。更有趣的是DRBD对I / O性能的相对影响。因此，无论有没有DRBD，都必须测量I / O吞吐量。

本节中描述的测试是侵入性的。它们会覆盖数据并使DRBD设备不同步。因此，至关重要的是，只能在暂存卷上执行它们，测试完成后可以将其丢弃。

I / O吞吐量估计的工作原理是将大量数据写入块设备，并测量系统完成写入操作所花费的时间。可以使用相当普遍的实用程序轻松完成此操作dd，该实用程序的最新版本包括内置的吞吐量估算。

dd假设您有一个名为的临时资源test，该资源当前已连接并且在两个节点上均处于辅助角色，则这是一个基于简单的吞吐量基准，类似于以下内容：

# TEST_RESOURCE=test

# TEST_DEVICE=$(drbdadm sh-dev $TEST_RESOURCE | head -1)

# TEST_LL_DEVICE=$(drbdadm sh-ll-dev $TEST_RESOURCE | head -1)

# drbdadm primary $TEST_RESOURCE

# for i in $(seq 5); do

    dd if=/dev/zero of=$TEST_DEVICE bs=1M count=512 oflag=direct

  done

# drbdadm down $TEST_RESOURCE

# for i in $(seq 5); do

    dd if=/dev/zero of=$TEST_LL_DEVICE bs=1M count=512 oflag=direct

  done

该测试仅将512MiB数据写入DRBD设备，然后再写入其后备设备进行比较。两次测试均重复5次，以便进行一些统计平均。相关的结果是产生的吞吐量测量值dd。

对于刚启用的DRBD设备，通常会在首次dd运行时看到性能略有下降。这是由于“活动日志”为“冷”，因此无需担心。

有关某些性能指标，请参见“ 优化DRBD吞吐量”一章。

20.2。测量延迟

延迟测量的目标与吞吐量基准完全不同：在I / O延迟测试中，写入一个很小的数据块（最好是系统可以处理的最小数据块），并观察完成写入所花费的时间。该过程通常重复几次以解决正常的统计波动。

与吞吐量测量一样，可以使用无处不在的dd实用程序执行I / O延迟测量，尽管设置不同且观察重点完全不同。

下面提供了一个简单的dd基于延迟的微基准，假设您有一个临时资源test，该资源当前已连接，并且在两个节点上均处于辅助角色：

# TEST_RESOURCE=test

# TEST_DEVICE=$(drbdadm sh-dev $TEST_RESOURCE | head -1)

# TEST_LL_DEVICE=$(drbdadm sh-ll-dev $TEST_RESOURCE | head -1)

# drbdadm primary $TEST_RESOURCE

# dd if=/dev/zero of=$TEST_DEVICE bs=4k count=1000 oflag=direct

# drbdadm down $TEST_RESOURCE

# dd if=/dev/zero of=$TEST_LL_DEVICE bs=4k count=1000 oflag=direct

此测试将1,000个大小为4kiB的数据块分别写入DRBD设备，然后再写入其后备设备进行比较。4096字节是Linux系统（除s390以外的所有体系结构），现代硬盘和SSD可以处理的最小块大小。

重要的是要了解，由产生的吞吐量测量dd与该测试完全无关。最重要的是在时间说1000个的写入完成时结束。将该时间除以1,000可得出单个块写入的平均延迟。

这是最坏的情况，因为它是单线程的，并且仅在前一个之后严格写一次，即。I / O深度为1。请查看Latency vs. IOPs。

此外，有关一些典型的性能值，请参见“ 优化DRBD延迟”一章。

21.优化DRBD吞吐量

本章介绍如何优化DRBD吞吐量。它检查了有关吞吐量优化的一些硬件注意事项，并详细说明了为此目的进行调整的建议。

21.1。硬件注意事项

DRBD吞吐量受基础I / O子系统（磁盘，控制器和相应的缓存）的带宽以及复制网络的带宽的影响。

I / O子系统吞吐量

I / O子系统的吞吐量在很大程度上取决于可以并行写入的存储单元（磁盘，SSD，其他闪存存储（例如FusionIO）等）的数量和类型。一个单一的，相当新近的SCSI或SAS磁盘通常将允许以大约40MiB / s的速率对单个磁盘进行流式写入。SSD的速度为300MiB / s；最近的一种闪存（NVMe）的速度为1GiB / s。当以条带化配置部署时，I / O子系统将使磁盘间的写入并行化，从而有效地将单个磁盘的吞吐量乘以配置中的条带数量。因此，相同的40MB / s磁盘在具有三个带区的RAID-0或RAID-1 + 0配置中或在具有五个带区的200MB / s时将允许有效吞吐量为120MB / s。使用SSD和/或NVMe，您可以轻松达到1GiB / sec。

具有RAM和BBU的 RAID控制器可以加快短暂的峰值（通过对其进行缓冲），因此过短的基准测试也可能显示出1GiB / s的速度。对于持续写入，它的缓冲区将只满，但是并没有太大帮助。

硬件中的 磁盘镜像（RAID-1）通常对吞吐量几乎没有影响。具有奇偶校验的磁盘条带化（RAID-5）确实会影响吞吐量，与条带化相比通常是不利的。软件中的RAID-5和RAID-6更是如此。

网络吞吐量

网络吞吐量通常取决于网络上存在的通信量以及存在的任何路由/交换基础结构的吞吐量。但是，这些问题在通常是专用的背对背网络连接的DRBD复制链接中基本上没有关系。因此，可以通过切换到更高吞吐量的硬件（例如10 Gb以太网或56GiB Infiniband）来提高网络吞吐量，或者通过使用多个网络链路上的链路聚合来提高网络吞吐量，就像使用Linux bonding网络驱动程序所做的那样 。

21.2。吞吐量开销预期

在估计与DRBD相关的吞吐量开销时，重要的是要考虑以下自然限制：

• DRBD吞吐量受原始I / O子系统的吞吐量的限制。
• DRBD吞吐量受可用网络带宽的限制。

这两个中的较低者确定了DRBD可用的理论吞吐量 最大值。然后，DRBD会通过其额外开销来减少该吞吐量数量，该开销可能会低于3％。

• 考虑两个群集节点的示例，这些群集节点包含具有600 MB / s吞吐量的I / O子系统，并且它们之间具有千兆以太网链路。千兆位以太网有望为TCP连接产生110 MB / s的吞吐量，因此，网络连接将成为此配置的瓶颈，并且人们期望最大DRBD吞吐量约为110 MB / s。
• 相比之下，如果I / O子系统仅能够以80 MB / s的速度进行持续写入，则它构成了瓶颈，您应该期望最大DRBD吞吐量仅约77 MB / s。

21.3。调整建议

DRBD提供了许多配置选项，这些选项可能会影响系统的吞吐量。本节列出了一些有关吞吐量调整的建议。但是，由于吞吐量在很大程度上取决于硬件，因此调整此处描述的选项的效果可能因系统而异。重要的是要理解，这些建议不应解释为“魔术”，它可以神奇地消除所有吞吐量瓶颈。

21.3.1。设置max-buffers和max-epoch-size

这些选项影响辅助节点上的写入性能。max-buffers是DRBD分配的用于将数据写入磁盘的最大缓冲区数，同时max-epoch-size是两个写屏障之间允许的最大写请求数。max-buffers必须相等或更大max-epoch-size才能提高性能。两者的默认值为2048。对于大多数合理的高性能硬件RAID控制器，将其设置为8000左右应该很好。

resource <resource> {

  net {

    max-buffers    8000;

    max-epoch-size 8000;

    ...

  }

  ...

}

21.3.2。调整TCP发送缓冲区的大小

TCP发送缓冲区是用于传出TCP流量的内存缓冲区。默认情况下，它的大小设置为128 KiB。对于在高吞吐量网络中使用（例如专用的千兆以太网或负载平衡的绑定连接），将其增大到2MiB甚至更大的大小可能是有意义的。通常不建议将发送缓冲区的大小设置为大于16MiB（也不太可能提高吞吐量）。

resource <resource> {

  net {

    sndbuf-size 2M;

    ...

  }

  ...

}

DRBD还支持TCP发送缓冲区自动调整。启用此功能后，DRBD将动态选择适当的TCP发送缓冲区大小。只需将缓冲区大小设置为零即可启用TCP发送缓冲区自动调整：

resource <resource> {

  net {

    sndbuf-size 0;

    ...

  }

  ...

}

请注意，您sysctl的设置net.ipv4.tcp_rmem和 net.ipv4.tcp_wmem仍然会影响行为；您应该检查这些设置，并可能将它们设置为类似131072 1048576 16777216 （最小128kiB，默认1MiB，最大16MiB）。

net.ipv4.tcp_mem 是不同的野兽，具有不同的单位-请勿触摸，错误的值很容易将您的机器推入内存不足的情况！

21.3.3。调整活动日志大小

如果使用DRBD的应用程序频繁写入密集型文件，那么通常建议使用相对较大的活动日志。否则，频繁的元数据更新可能会不利于写入性能。

resource <resource> {

  disk {

    al-extents 6007;

    ...

  }

  ...

}

21.3.4。禁用屏障和磁盘刷新

在本节中概述的建议应该应用于 仅具有非易失性的（电池支持）控制器缓存的系统。

配备有备用电池写缓存的系统带有内置的方法，可以在断电时保护数据。在这种情况下，可以禁用出于相同目的而创建的某些DRBD自己的防护措施。就吞吐量而言，这可能是有益的：

resource <resource> {

  disk {

    disk-barrier no;

    disk-flushes no;

    ...

  }

  ...

}

21.4。通过增加冗余实现更好的读取性能

正如在本手册页详细介绍drbd.conf下read-balancing，你可以通过添加更多的数据拷贝提高读取性能。

作为一个大概的数字：与单个节点处理读取请求，fio在FUSIONIO卡给了我们10万次的IOPs; 启用后read-balancing，性能跃升到18万个IOP。+ 80％！

因此，如果您正在运行只读的工作负载（具有大量随机读取的大型数据库），则可能值得尝试打开read-balancing-并可能添加另一个副本以获得更多的读取IO吞吐量。

22.优化DRBD延迟

本章介绍如何优化DRBD延迟。它检查了有关最小化延迟的一些硬件注意事项，并详细说明了为此目的进行调整的建议。

22.1 硬件注意事项

DRBD延迟受基础I / O子系统（磁盘，控制器和相应的缓存）的延迟以及复制网络的延迟的影响。

I / O子系统延迟

对于旋转媒体，I / O子系统延迟主要是磁盘旋转速度的函数。因此，使用快速旋转磁盘是减少I / O子系统延迟的有效方法。

对于固态媒体（如SSD），闪存控制器是决定因素；接下来最重要的是未使用的容量。使用DRBD的“ 修剪/丢弃”支持将帮助您为控制器提供所需的信息，以阻止其回收。这样，当一个写请求进来时，可以使用得到了清理名列前茅的时间，不必等待块现在，直到有可用空间[ 14 ]。

同样，使用电池备份的写缓存（BBWC）可以减少写完成时间，还可以减少写延迟。大多数合理的存储子系统都带有某种形式的电池后备缓存，并允许管理员配置该缓存的哪一部分用于读取和写入操作。建议的方法是完全禁用磁盘读取缓存，并将所有可用的缓存内存用于磁盘写入缓存。

网络延迟

本质上，网络延迟是主机之间的数据包往返时间（RTT）。它受许多因素的影响，其中大多数与推荐用作DRBD复制链接的专用背靠背网络连接无关。因此，足以接受一定数量的等待时间总是存在于网络链路中，对于千兆以太网，这通常约为100到200微秒（μs）的数据包RTT。

通常只能通过使用较低延迟的网络协议将网络延迟降至此限制以下，例如使用Dolphin SuperSockets在Dolphin Express上运行DRBD或10GBe直接连接。这些通常在50µs的范围内。InfiniBand甚至更好，它提供了更低的延迟。

22.2。延迟开销预期

至于吞吐量，在估计与DRBD相关的延迟开销时，要考虑一些重要的自然限制：

• DRBD延迟受原始I / O子系统的约束。
• DRBD延迟受可用网络延迟的约束。

两者之和确定了 DRBD引起的理论等待时间最小值[ 15 ]。然后，DRBD会在该延迟中增加一点额外的延迟开销，这可以预期不到1％。

• 考虑一个本地磁盘子系统的示例，该子系统的写入延迟为3ms，网络链接的延迟为0.2ms。这样，预期的DRBD延迟将为3.2毫秒，或者比仅写入本地磁盘的延迟增加大约7％。

延迟可能会受到许多其他因素的影响，包括CPU缓存未命中，上下文切换等。

22.3。延迟与IOP

IOP是“ 每秒I / O操作 ”的缩写。

营销通常不喜欢数字变小。请注意，新闻稿中的“ 延迟降低了10µs，从现在的50µs降低到了40µs！ ”，他们更喜欢“ 性能提高了25％，从20000降低到现在的25000 IOP ”。因此，发明了IOP-得到一个数字，表示“越高越好”。

因此，换句话说，IOP是等待时间的倒数。您需要牢记的是，“ 测量延迟”中给出的方法为您提供了延迟响应。纯顺序单线程IO负载的IOP数量，而其他大多数文档会提供一些高度并行负载的数字[ 16 ]，因为这会提供很多“更漂亮”的数字。有了这种技巧，DRBD也可以为您提供100000 IOP！

因此，请不要回避测量序列化的单线程延迟。如果您需要大量IOP，请fio使用threads=8和 iodepth=16或一些类似的设置来运行该实用程序...但是请记住，除非您使用的驱动程序包含数十或数百个数据库，否则这些数字对您的设置没有任何意义。客户端连接同时处于活动状态。

22.4。调整建议

22.4.1。设置DRBD的CPU掩码

DRBD允许为其内核线程设置显式CPU掩码。这对于本来可以与DRBD竞争CPU周期的应用程序特别有利。

CPU掩码是一个数字，其二进制表示的最低有效位表示第一个CPU，第二低有效位表示第二个CPU，依此类推。位掩码中的设置位表示DRBD可以使用相应的CPU，而清除位表示不能。因此，例如，CPU掩码为1（00000001）表示DRBD只能使用第一个CPU。掩码为12（00001100）表示DRBD可以使用第三和第四CPU。

资源的示例CPU掩码配置可能如下所示：

resource <resource> {

  options {

    cpu-mask 2;

    ...

  }

  ...

}

当然，为了最小化DRBD和使用它的应用程序之间的CPU竞争，您需要将应用程序配置为仅使用那些DRBD不使用的CPU。

某些应用程序可能会通过配置文件中的条目来提供此功能，就像DRBD本身一样。其他包括taskset在应用程序初始化脚本中调用 命令。

保持DRBD线程在相同的L2 / L3缓存上运行是有意义的。 但是：CPU的编号不必与物理分区相关联。您可以尝试X11或 控制台输出的lstopo（或hwloc-ls）程序hwloc-info -v -p来获得拓扑概述。

22.4.2。修改网络MTU

将复制网络的最大传输单元（MTU）大小更改为大于默认值1500字节的值可能会有所帮助。通俗地说，这被称为“启用巨型帧”。

可以使用以下命令更改MTU：

＃ifconfig <接口> mtu <大小>

要么

＃ip链接设置<interface> mtu <size>

<interface>是指用于DRBD复制的网络接口。<size>的典型值为9000（字节）。

22.4.3。启用截止日期I / O调度程序

当与高性能，可回写的硬件RAID控制器结合使用时，DRBD延迟可能会因为使用简单的截止日期I / O调度程序而不是CFQ调度程序而大大受益。通常默认情况下启用后者。

可以通过sysfs安装在的虚拟文件系统对I / O调度程序配置进行修改/sys。调度程序配置位于中，其中<device>是DRBD使用的后备设备。/sys/block/device

通过以下命令启用截止时间调度程序：

＃echo截止日期> / sys / block / <device> / queue / scheduler

然后，您还可以设置以下值，这可能会带来更多的延迟好处：

• 禁用前端合并：

＃echo 0> / sys / block / <设备> / queue / iosched / front_merges

• 将读取I / O截止期限减少到150毫秒（默认值为500ms）：

＃echo 150> / sys / block / <设备> / queue / iosched / read_expire

• 将写入I / O截止期限减少到1500毫秒（默认值为3000ms）：

＃echo 1500> / sys / block / <设备> / queue / iosched / write_expire

如果这些值显着改善了延迟，则可能需要将其设置为永久性，以便在系统启动时自动设置它们。Debian和Ubuntu系统通过sysfsutils软件包和/etc/sysfs.conf配置文件提供此功能 。

您还elevator可以通过内核命令行传递选项来进行全局I / O调度程序选择 。为此，请编辑您的引导加载程序配置（通常在/etc/default/grub使用GRUB引导加载程序时找到），然后将其添加elevator=deadline到内核​​引导选项列表中。