en to zh translation catalogue (46 entries)

note: type: Title ==
en: Optimizing DRBD latency
zh: 优化DRBD延迟

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

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

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

note: type: Block title
en: I/O subsystem latency
zh: I/O子系统延迟

note: type: Plain text
en: indexterm:[latency]For _rotating media_ the I/O subsystem latency is primarily a function of disk rotation speed. Thus, using fast-spinning disks is a valid approach for reducing I/O subsystem latency.
zh: indexterm:[latency]对于 _旋转媒体_ ，I/O子系统延迟主要是磁盘旋转速度的函数。因此，使用快速旋转的磁盘是减少I/O子系统延迟的有效方法。

note: type: Plain text
en: For _solid state media_ (like SSDs) the Flash storage controller is the determining factor; the next most important thing is the amount of unused capacity. Using DRBD's <<s-trim-discard>> will help you provide the controller with the needed information which blocks it can recycle. That way, when a write requests comes in, it can use a block that got cleaned ahead-of-time and doesn't have to wait *now* until there's space availablefootnote:[On low-end hardware you can help that a bit by reserving some space - just keep 10% to 20% of the total space unpartitioned.].
zh: 对于 _固态媒体_ （如固态硬盘），闪存控制器是决定因素；下一个最重要的因素是未使用的容量。使用DRBD的<<s-trim-discard>>将帮助您向控制器提供所需的信息，哪些块可以循环使用。这样，当一个写请求进入时，它可以使用一个提前清理过的块，而不必等待至 *现在* 直到有可用的空间为止。footnote:[在低端硬件上，您可以通过保留一些空间来帮助这一点，只需保留总空间的10%到20%就可以了。]

note: type: Plain text
en: Likewise, the use of a indexterm:[battery-backed write cache] indexterm:[BBU] battery-backed write cache (BBWC) reduces write completion times, also reducing write latency. Most reasonable storage subsystems come with some form of battery-backed cache, and allow the administrator to configure which portion of this cache is used for read and write operations. The recommended approach is to disable the disk read cache completely and use all available cache memory for the disk write cache.
zh: 同样，使用indexterm:[battery-backed write cache]indexterm:[BBU]battery-backed write cache（BBWC）可以减少写入完成时间，还可以减少写入延迟。大多数合理的存储子系统都带有某种形式的电池备份缓存，并允许管理员配置该缓存的哪个部分用于读写操作。建议的方法是完全禁用磁盘读缓存，并将所有可用的缓存内存用于磁盘写缓存。

note: type: Block title
en: Network latency
zh: 网络延迟

note: type: Plain text
en: indexterm:[latency]Network latency is, in essence, the packet indexterm:[round-trip-time]indexterm:[RTT] round-trip time (RTT) between hosts. It is influenced by a number of factors, most of which are irrelevant on the dedicated, back-to-back network connections recommended for use as DRBD replication links. Thus, it is sufficient to accept that a certain amount of latency always exists in network links, which typically is on the order of 100 to 200 microseconds (μs) packet RTT for Gigabit Ethernet.
zh: indexterm:[latency]网络延迟, 实际上是包在indexterm:[round-trip-time]indexterm:[RTT]主机之间的往返时间（RTT）。它受到许多因素的影响，其中大多数因素与推荐用作DRBD复制链路的专用背靠背网络连接无关。因此，接受网络链路中始终存在一定量的延迟就足够了，对于千兆位以太网，该延迟通常在100到200微秒（μs）的分组RTT上。

note: type: Plain text
en: Network latency may typically be pushed below this limit only by using lower-latency network protocols, such as running DRBD over Dolphin Express using Dolphin SuperSockets, or a 10GBe direct connection; these are typically in the 50µs range. Even better is InfiniBand, which provides even lower latencies.
zh: 网络延迟通常只能通过使用较低延迟的网络协议（例如使用Dolphin SuperSockets在Dolphin Express上运行DRBD）或10GBe直接连接来推送到该限制之下；这些协议通常在50微秒范围内。更好的是InfiniBand，它提供了更低的延迟。

note: type: Title ===
en: Latency overhead expectations
zh: 延迟开销预期

note: type: Plain text
en: As for throughput, when estimating the latency overhead associated with DRBD, there are some important natural limitations to consider:
zh: 至于吞吐量，在估计与DRBD相关联的延迟开销时，需要考虑一些重要的自然限制：

note: type: Plain text
en: DRBD latency is bound by that of the raw I/O subsystem.
zh: DRBD延迟受原始I/O子系统的延迟限制。

note: type: Plain text
en: DRBD latency is bound by the available network latency.
zh: DRBD延迟受可用网络延迟的约束。

note: type: Plain text
en: The _sum_ of the two establishes the theoretical latency _minimum_ incurred to DRBDfootnote:[for protocol C, because the other node(s) have to write to stable storage, too]. DRBD then adds to that latency a slight additional latency overhead, which can be expected to be less than 1 percent.
zh: 两者之和确定了DRBD所产生的理论延迟最小值 footnote:[对于 protocol C，因为其他节点也必须写入稳定存储]。然后，DRBD会在这个延迟上增加一点额外的延迟开销，预计这个开销将小于1%。

note: type: Plain text
en: Consider the example of a local disk subsystem with a write latency of 3ms and a network link with one of 0.2ms. Then the expected DRBD latency would be 3.2 ms or a roughly 7-percent latency increase over just writing to a local disk.
zh: 以本地磁盘子系统为例，其写延迟为3ms，网络链路为0.2ms。那么，预期的DRBD延迟将为3.2ms，或者仅写到本地磁盘的延迟大约增加7%。

note: type: Plain text
en: Latency may be influenced by a number of other factors, including CPU cache misses, context switches, and others.
zh: 延迟可能会受到许多其他因素的影响，包括CPU缓存未命中、上下文切换和其他因素。

note: type: Title ===
en: Latency vs. IOPs
zh: 延迟与IOPs

note: type: Plain text
en: indexterm:[latency]indexterm:[IOPs]_IOPs_ is the abbreviation of "__I/O operations per second__".
zh: indexterm:[latency]indexterm:[IOPs]_IOPs_ 是 "每秒I/O操作数" 的缩写。

note: type: Plain text
en: Marketing typically doesn't like numbers that get smaller; press releases aren't written with "__Latency reduced by 10µs, from 50µs to 40µs now!__" in mind, they like "__Performance increased by 25%, from 20000 to now 25000 IOPs__" much more. Therefore IOPs were invented - to get a number that says "higher is better".
zh: 市场营销通常不喜欢数字变小；新闻稿的撰写不会描述成 "延迟减少10微秒，从50微秒减少到40微秒！"！ - 记住，他们更喜欢 "IOPs性能提高了25%，从20000提高到现在的25000" 。因此，IOPs被发明出来，以得到一个 "越高越好" 的数字。

note: type: Plain text
en: So, in other words, IOPs are the reciprocal of latency. What you'll have to keep in mind is that the method given in <<s-measure-latency>> gives you the latency resp. the number of IOPs for a purely sequential, single-threaded IO load, while most other documentation will give numbers for some highly parallel loadfootnote:[Like in "__16 threads, IO-depth of 32__" - this means that 512 I/O-requests are being done in parallel!], because this gives much "prettier" numbers. With that kind of trick DRBD does offer you 100000 IOPs, too!
zh: 换句话说，IOPs是延迟的倒数。您需要记住的是，在<<s-measure-latency>>中给出的方法为您提供了延迟响应。纯顺序单线程IO加载的IOPs数，而大多数其他文档将给出一些高度并行加载的数字footnote:[如在 "__16线程，IO深度为32__" – 这意味着512个I/O请求是并行完成的！]，因为这给了很多 "漂亮" 的数字。有了这种技巧，DRBD也能为您提供100000 IOPs！

note: type: Plain text
en: So, please don't shy away from measuring serialized, single-threaded latency.  If you want lots of IOPs, run the `fio` utility with `threads=8` and an `iodepth=16`, or some similar settings... But please keep in mind that these number will not have any meaning to your setup, unless you're driving a database with many tens or hundreds of client connections active at the same time.
zh: 所以，请不要回避测量序列化的单线程延迟。如果需要大量IOPs，请运行 `threads=8` 和 `iodepth=16` 的 `fio` 实用程序，或一些类似的设置。。。但是请记住，这些数字对您的设置没有任何意义，除非您正在驱动一个同时有数十或数百个客户端连接处于活动状态的数据库。

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

note: type: Title ====
en: Setting DRBD's CPU mask
zh: 设置DRBD的CPU掩码

note: type: Plain text
en: DRBD allows for setting an explicit CPU mask for its kernel threads. This is particularly beneficial for applications which would otherwise compete with DRBD for CPU cycles.
zh: DRBD允许为其内核线程设置显式CPU掩码。这对于那些在CPU周期上与DRBD竞争的应用程序尤其有利。

note: type: Plain text
en: The CPU mask is a number in whose binary representation the least significant bit represents the first CPU, the second-least significant bit the second, and so forth. A set bit in the bitmask implies that the corresponding CPU may be used by DRBD, whereas a cleared bit means it must not. Thus, for example, a CPU mask of 1 (`00000001`) means DRBD may use the first CPU only. A mask of 12 (`00001100`) implies DRBD may use the third and fourth CPU.
zh: CPU掩码是其二进制表示中的最低有效位表示第一CPU、第二最低有效位表示第二CPU的数字，依此类推。位掩码中的设置位表示DRBD可以使用相应的CPU，而清除位表示它不能使用。因此，例如，CPU掩码1（`00000001`）意味着DRBD只能使用第一个CPU。掩码12（`00001100`）表示DRBD可以使用第三和第四CPU。

note: type: Plain text
en: An example CPU mask configuration for a resource may look like this:
zh: 资源的CPU掩码配置示例如下：

note: type: Plain text
en: Of course, in order to minimize CPU competition between DRBD and the application using it, you need to configure your application to use only those CPUs which DRBD does not use.
zh: 当然，为了减少DRBD和使用它的应用程序之间的CPU竞争，您需要将应用程序配置为只使用DRBD不使用的那些CPU。

note: type: Plain text
en: Some applications may provide for this via an entry in a configuration file, just like DRBD itself. Others include an invocation of the `taskset` command in an application init script.
zh: 一些应用程序可以通过配置文件中的一个条目来提供这一点，就像DRBD本身一样。其他方法包括在应用程序init脚本中调用 `taskset` 命令。

note: type: delimited block =
en: It makes sense to keep the DRBD threads running on the same L2/L3 caches.
zh: 保持DRBD线程在相同的L2/L3缓存上运行是有意义的。

note: type: delimited block =
en: But: the numbering of CPUs doesn't have to correlate with the physical partitioning.  You can try the `lstopo` (or `hwloc-ls`) program for X11 or `hwloc-info -v -p` for console output to get an overview of the topology.
zh: 但是：CPU的编号并不一定与物理分区相关。您可以尝试X11的 `lstopo` （或 `hwloc ls` ）程序或控制台输出的 `hwloc-info -v -p` 程序，以获得拓扑的概述。

note: type: Title ====
en: Modifying the network MTU
zh: 修改网络MTU

note: type: Plain text
en: It may be beneficial to change the replication network's maximum transmission unit (MTU) size to a value higher than the default of 1500 bytes. Colloquially, this is referred to as indexterm:[Jumbo frames] "enabling Jumbo frames".
zh: 将复制网络的最大传输单元（MTU）大小更改为高于默认值1500字节的值可能是有益的。通俗地说，这称为indexterm:[Jumbo  frames] "启用Jumbo frames"。

note: type: Plain text
en: The MTU may be changed using the following commands:
zh: 可以使用以下命令更改MTU：

note: type: Plain text
en: or
zh: 或

note: type: Plain text
en: _<interface>_ refers to the network interface used for DRBD replication. A typical value for _<size>_ would be 9000 (bytes).
zh: _<interface>_ 指用于DRBD复制的网络接口。_<size>_ 的典型值为9000（字节）。

note: type: Title ====
en: Enabling the deadline I/O scheduler
zh: 启用deadline I/O调度器

note: type: Plain text
en: indexterm:[io scheduler] When used in conjunction with high-performance, write back enabled hardware RAID controllers, DRBD latency may benefit greatly from using the simple deadline I/O scheduler, rather than the CFQ scheduler. The latter is typically enabled by default.
zh: indexterm:[I O scheduler]当与高性能、支持写回的硬件RAID控制器结合使用时，DRBD延迟可能从使用简单的deadline I/O scheduler而不是CFQ调度器中受益匪浅。后者通常在默认情况下启用。

note: type: Plain text
en: Modifications to the I/O scheduler configuration may be performed via the `sysfs` virtual file system, mounted at `/sys`. The scheduler configuration is in `/sys/block/__device__`, where _<device>_ is the backing device DRBD uses.
zh: 对I/O调度程序配置的修改可以通过挂载在 `/sys` 的 `sysfs` 虚拟文件系统执行。调度程序配置位于 `/sys/block/__device__` 其中 _<device>_ 是DRBD使用的备份设备。

note: type: Plain text
en: You may then also set the following values, which may provide additional latency benefits:
zh: 然后，您还可以设置以下值，这些值可以提供额外的延迟好处：

note: type: Plain text
en: Disable front merges:
zh: 禁用前台合并：

note: type: Plain text
en: Reduce read I/O deadline to 150 milliseconds (the default is 500ms):
zh: 将读取I/O deadline时间缩短到150毫秒（默认为500毫秒）：

note: type: Plain text
en: Reduce write I/O deadline to 1500 milliseconds (the default is 3000ms):
zh: 将写入I/O deadline时间缩短到1500毫秒（默认值为3000毫秒）：

note: type: Plain text
en: If these values effect a significant latency improvement, you may want to make them permanent so they are automatically set at system startup. indexterm:[Debian GNU/Linux]Debian and indexterm:[Ubuntu Linux]Ubuntu systems provide this functionality via the `sysfsutils` package and the `/etc/sysfs.conf` configuration file.
zh: 如果这些值影响显著的延迟改进，则可能需要将它们永久化，以便在系统启动时自动设置它们。indexterm:[Debian GNU/Linux]Debian和indexterm:[Ubuntu Linux]Ubuntu系统通过 `sysfsutils` 包和 `/etc/sysfs.conf` 配置文件提供此功能。

note: type: Plain text
en: You may also make a global I/O scheduler selection by passing the `elevator` option via your kernel command line. To do so, edit your boot loader configuration (normally found in `/etc/default/grub` if you are using the GRUB bootloader) and add `elevator=deadline` to your list of kernel boot options.
zh: 还可以通过通过内核命令行传递 `elevator` 选项来选择全局I/O调度程序。为此，编辑引导加载程序配置（如果使用的是grub引导加载程序，通常可以在 `/etc/default/grub` 中找到），并将 `elevator=deadline` 添加到内核引导选项列表中。
