en to zh translation catalogue (35 entries)

note: type: Title ==
en: Optimizing DRBD throughput
zh: 优化DRBD吞吐量

note: type: Plain text
en: This chapter deals with optimizing DRBD throughput. It examines some hardware considerations with regard to throughput optimization, and details tuning recommendations for that purpose.
zh: 本章讨论优化DRBD吞吐量。它研究了与吞吐量优化有关的一些硬件考虑因素，并详细介绍了为此目的提出的优化建议。

note: type: Title ===
en: Hardware considerations
zh: 硬件注意事项

note: type: Plain text
en: DRBD throughput is affected by both the bandwidth of the underlying I/O subsystem (disks, controllers, and corresponding caches), and the bandwidth of the replication network.
zh: DRBD吞吐量受底层I/O子系统（磁盘、控制器和相应缓存）的带宽和复制网络的带宽的影响。

note: type: Block title
en: I/O subsystem throughput
zh: I/O子系统吞吐量

note: type: Plain text
en: indexterm:[throughput]I/O subsystem throughput is determined, largely, by the number and type of storage units (disks, SSDs, other Flash storage [like FusionIO], ...) that can be written to in parallel. A single, reasonably recent, SCSI or SAS disk will typically allow streaming writes of roughly 40MiB/s to the single disk; an SSD will do 300MiB/s; one of the recent Flash storages (NVMe) will be at 1GiB/s. When deployed in a striping configuration, the I/O subsystem will parallelize writes across disks, effectively multiplying a single disk's throughput by the number of stripes in the configuration. Thus the same, 40MB/s disks will allow effective throughput of 120MB/s in a RAID-0 or RAID-1+0 configuration with three stripes, or 200MB/s with five stripes; with SSDs and/or NVMe you can easily get to 1GiB/sec.
zh: indexterm:[throughput]I/O子系统吞吐量在很大程度上取决于可并行写入的存储单元（磁盘、固态硬盘、其他闪存[如FusionIO]，...）的数量和类型。一个相当新的SCSI或SAS磁盘通常允许向单个磁盘流式写入大约40MiB/秒；一个固态硬盘将执行300MiB/秒；一个最新的闪存（NVMe）将为1GiB/秒。在分条配置中部署时，I/O子系统将并行化跨磁盘的写入，有效地将单个磁盘的吞吐量乘以配置中的条带数。因此，同样的，40MB/s磁盘将允许有效吞吐量120MB/s的RAID-0或RAID-1+0配置（带三个条带），或200MB/s（带五个条带）；使用固态硬盘和/或NVMe，您可以轻松地达到1GiB/s。

note: type: Plain text
en: A RAID-controller with RAM and a <<s-hardware-bbu,BBU>> can speed up short spikes (by buffering them), and so too-short benchmark tests might show speeds like 1GiB/s too; for sustained writes its buffers will just run full, and then not be of much help, though.
zh: 一个带有RAM和<<s-hardware-bbu,BBU>>的RAID控制器可以加速短峰值（通过缓冲它们），因此太短的基准测试可能也会显示类似于1GiB/s的速度；对于持续的写操作，它的缓冲区只会满负荷运行，然后就没有多大帮助。

note: type: Plain text
en: Disk _mirroring_ (RAID-1) in hardware typically has little, if any, effect on throughput. Disk _striping with parity_ (RAID-5) does have an effect on throughput, usually an adverse one when compared to striping; RAID-5 and RAID-6 in software even more so.
zh: 硬件中的磁盘镜像（RAID-1）通常对吞吐量的影响很小（如果有的话）。带奇偶校验的磁盘条带（RAID-5）确实对吞吐量有影响，与条带相比通常是不利的；软件中的RAID-5和RAID-6更是如此。

note: type: Block title
en: Network throughput
zh: 网络吞吐量

note: type: Plain text
en: indexterm:[throughput]Network throughput is usually determined by the amount of traffic present on the network, and on the throughput of any routing/switching infrastructure present. These concerns are, however, largely irrelevant in DRBD replication links which are normally dedicated, back-to-back network connections. Thus, network throughput may be improved either by switching to a higher-throughput hardware (such as 10 Gigabit Ethernet, or 56GiB Infiniband), or by using link aggregation over several network links, as one may do using the Linux indexterm:[bonding driver]`bonding` network driver.
zh: indexterm:[throughput]网络吞吐量通常由网络上存在的流量以及存在的任何路由/交换基础设施的吞吐量决定。然而，这些问题在通常是专用的back-to-back网络连接的DRBD复制链路中基本上是不相关的。因此，可以通过切换到更高吞吐量的硬件（例如10 Gigabit以太网或56 GiBInfiniband）或通过使用多个网络链路上的链路聚合来提高网络吞吐量，就像可以使用Linux indexterm:[bonding driver]`bonding` 网络驱动程序那样。

note: type: Title ===
en: Throughput overhead expectations
zh: 吞吐量开销预期

note: type: Plain text
en: When estimating the throughput overhead associated with DRBD, it is important to consider the following natural limitations:
zh: 在估计与DRBD相关联的吞吐量开销时，必须考虑以下自然限制：

note: type: Plain text
en: DRBD throughput is limited by that of the raw I/O subsystem.
zh: DRBD吞吐量受到原始I/O子系统的限制。

note: type: Plain text
en: DRBD throughput is limited by the available network bandwidth.
zh: DRBD的吞吐量受到可用网络带宽的限制。

note: type: Plain text
en: The _lower_ of these two establishes the theoretical throughput _maximum_ available to DRBD. DRBD then reduces that throughput number by its additional overhead, which can be expected to be less than 3 percent.
zh: 这两个值的 _lower_  建立了DRBD可用的理论吞吐量 _最大值_ 。然后，DRBD通过其额外的开销（可以预期小于3%）来减少吞吐量。

note: type: Plain text
en: Consider the example of two cluster nodes containing I/O subsystems capable of 600 MB/s throughput, with a Gigabit Ethernet link available between them. Gigabit Ethernet can be expected to produce 110 MB/s throughput for TCP connections, thus the network connection would be the bottleneck in this configuration and one would expect about 110 MB/s maximum DRBD throughput.
zh: 以两个集群节点为例，它们包含能够达到600 MB/s吞吐量的I/O子系统，并且在它们之间有一个千兆以太网链路。千兆位以太网可以预期为TCP连接产生110MB/s的吞吐量，因此网络连接将是此配置中的瓶颈，并且可以预期最大DRBD吞吐量约为110 MB/s。

note: type: Plain text
en: By contrast, if the I/O subsystem is capable of only 80 MB/s for sustained writes, then it constitutes the bottleneck, and you should expect only about 77 MB/s maximum DRBD throughput.
zh: 相比之下，如果I/O子系统仅能够以80 MB/s的速度进行持续的写操作，那么它就构成了瓶颈，您应该只期望大约77 MB/s的最大DRBD吞吐量。

note: type: Title ===
en: Tuning recommendations
zh: 调整建议

note: type: Plain text
en: DRBD offers a number of configuration options which may have an effect on your system's throughput. This section list some recommendations for tuning for throughput. However, since throughput is largely hardware dependent, the effects of tweaking the options described here may vary greatly from system to system. It is important to understand that these recommendations should not be interpreted as "silver bullets" which would magically remove any and all throughput bottlenecks.
zh: DRBD提供了许多配置选项，这些选项可能会影响系统的吞吐量。本节列出了一些有关调整吞吐量的建议。然而，由于吞吐量在很大程度上依赖于硬件，因此调整此处描述的选项的效果可能因系统而异。重要的是要明白，这些建议不应被解释为能神奇地消除任何和所有吞吐量瓶颈的 `银弹` 。

note: type: Title ====
en: Setting `max-buffers` and `max-epoch-size`
zh: 设置 `max-buffers` 和 `max-epoch-size`

note: type: Plain text
en: These options affect write performance on the secondary nodes. `max-buffers` is the maximum number of buffers DRBD allocates for writing data to disk while `max-epoch-size` is the maximum number of write requests permitted between two write barriers. `max-buffers` must be equal or bigger to `max-epoch-size` to increase performance.  The default for both is 2048; setting it to around 8000 should be fine for most reasonably high-performance hardware RAID controllers.
zh: 这些选项会影响辅助节点上的写入性能。`max buffers` 是DRBD为将数据写入磁盘而分配的最大缓冲区数，而 `max-epoch-size` 是两个写入屏障之间允许的最大写入请求数。`max buffers` 必须等于或大于 `max-epoch-size` ，才能提高性能。两者的默认值都是2048；对于大多数合理的高性能硬件RAID控制器来说，将其设置为8000左右应该没问题。

note: type: Title ====
en: Tuning the TCP send buffer size
zh: 调整TCP发送缓冲区大小

note: type: Plain text
en: The TCP send buffer is a memory buffer for outgoing TCP traffic. By default, it is set to a size of 128 KiB. For use in high-throughput networks (such as dedicated Gigabit Ethernet or load-balanced bonded connections), it may make sense to increase this to a size of 2MiB, or perhaps even more. Send buffer sizes of more than 16MiB are generally not recommended (and are also unlikely to produce any throughput improvement).
zh: TCP发送缓冲区是用于传出TCP通信的内存缓冲区。默认情况下，它的大小设置为128 KiB。对于在高吞吐量网络（如专用千兆以太网或负载平衡的绑定连接）中使用，将其大小增加到2MiB或更大可能是有意义的。通常不建议发送缓冲区大小超过16MiB（而且也不太可能产生任何吞吐量改进）。

note: type: Plain text
en: DRBD also supports TCP send buffer auto-tuning. After enabling this feature, DRBD will dynamically select an appropriate TCP send buffer size. TCP send buffer auto tuning is enabled by simply setting the buffer size to zero:
zh: DRBD还支持TCP发送缓冲区自动调整。启用此功能后，DRBD将动态选择适当的TCP发送缓冲区大小。只需将缓冲区大小设置为零即可启用TCP发送缓冲区自动调整：

note: type: Plain text
en: Please note that your ``sysctl``'s settings `net.ipv4.tcp_rmem` and `net.ipv4.tcp_wmem` will still influence the behaviour; you should check these settings, and perhaps set them similar to `131072 1048576 16777216` (minimum 128kiB, default 1MiB, max 16MiB).
zh: 请注意，您的 `sysctl` 设置 `net.ipv4.tcp_rmem` 和 `net.ipv4.tcp_wmem` 仍将影响行为；您应该检查这些设置，并可能将它们设置为类似于 `131072 1048576 16777216` （最小128kiB，默认1MiB，最大16MiB）。

note: type: Plain text
en: `net.ipv4.tcp_mem` is a different beast, with a different unit - do not touch, wrong values can easily push your machine into out-of-memory situations!
zh: `net.ipv4.tcp_mem` 是另一个怪兽，有不同的单位-不要碰，错误的值很容易把你的机器推入内存不足的情况！

note: type: Title ====
en: Tuning the Activity Log size
zh: 调整活动日志大小

note: type: Plain text
en: If the application using DRBD is write intensive in the sense that it frequently issues small writes scattered across the device, it is usually advisable to use a fairly large activity log. Otherwise, frequent metadata updates may be detrimental to write performance.
zh: 如果使用DRBD的应用程序是写密集型的，因为它经常在设备上分散地发出小的写操作，那么通常建议使用相当大的活动日志。否则，频繁的元数据更新可能会损害写入性能。

note: For tuning on striped RAID setups, please see the <<al-stripes,al-stripes>> and <<al-stripe-size,al-stripe-size>> settings, too. type: Title ====
en: Disabling barriers and disk flushes
zh: 禁用屏障和磁盘刷新

note: type: Plain text
en: The recommendations outlined in this section should be applied _only_ to systems with non-volatile (battery backed) controller caches.
zh: 本节概述的建议应仅适用于具有非易失性（电池支持）控制器缓存的系统。

note: type: Plain text
en: Systems equipped with battery backed write cache come with built-in means of protecting data in the face of power failure. In that case, it is permissible to disable some of DRBD's own safeguards created for the same purpose. This may be beneficial in terms of throughput:
zh: 配备电池支持的写缓存的系统配备了内置的方法，可以在断电时保护数据。在这种情况下，允许禁用为相同目的而创建的一些DRBD自己的安全措施。这可能对吞吐量有利：

note: type: Title ===
en: Achieving better Read Performance via increased Redundancy
zh: 通过增加冗余实现更好的读取性能

note: type: Plain text
en: As detailed in the man page of `drbd.conf` under `read-balancing`, you can increase your read performance by adding more copies of your data.
zh: 如 `read-balancing` 下 `drbd.conf` 的手册页所述，可以通过添加更多数据副本来提高读取性能。

note: type: Plain text
en: As a ballpark figure: with a single node processing read requests, `fio` on a __FusionIO__ card gave us 100k IOPs; after enabling `read-balancing`, the performance jumped to 180k IOPs, i.e. +80%!
zh: 一个大概的数字是：单节点处理读请求时，FusionIO卡上的 `fio`给了我们10万IOPs；启用 `读平衡` 后，性能跃升到18万IOPs，即+80%！

note: type: Plain text
en: So, in case you're running a read-mostly workload (big databases with lots of random reads), it might be worth a try to turn `read-balancing` on - and, perhaps, add another copy for still more read IO throughput.
zh: 因此，如果您运行的是以读为主的工作负载（具有大量随机读操作的大型数据库），那么可能值得尝试启用 `读平衡` ，并且，也许可以添加另一个副本以获得更大的读IO吞吐量。
