en to zh translation catalogue (163 entries)

note: type: Title ==
en: DRBD Features
zh: DRBD特征

note: type: Plain text
en: This chapter discusses various useful DRBD features, and gives some background information about them. Some of these features will be important to most users, some will only be relevant in very specific deployment scenarios. <<p-work>> and <<ch-troubleshooting>> contain instructions on how to enable and use these features in day-to-day operation.
zh: 本章讨论了各种有用的DRBD特性，并给出了它们的一些背景信息。这些特性中的一些对大多数用户都很重要，有些只在非常特定的部署场景中才相关。<<p-work>>和<<ch-troubleshooting>>包含如何在日常操作中启用和使用这些功能的说明。

note: type: Title ===
en: Single-primary mode
zh: 单一主(Single-primary)模式

note: type: Plain text
en: In single-primary mode, a resource is, at any given time, in the primary role on only one cluster member. Since it is guaranteed that only one cluster node manipulates the data at any moment, this mode can be used with any conventional file system (ext3, ext4, XFS etc.).
zh: 在单一主模式下，资源在任何给定的时间仅在一个群集成员上处于主角色。由于可以保证在任何时候只有一个集群节点操作数据，因此这种模式可以用于任何传统的文件系统（ext3、ext4、XFS等）。

note: type: Plain text
en: Deploying DRBD in single-primary mode is the canonical approach for High-Availability (fail-over capable) clusters.
zh: 在单一主模式下部署DRBD是高可用性（支持故障转移）集群的规范方法。

note: type: Title ===
en: Dual-primary mode
zh: 双主(Dual-primary)模式

note: type: Plain text
en: In dual-primary mode, a resource is, at any given time, in the primary role on two cluster nodesfootnote:[Perhaps that feature will be renamed to "Multi Primary" later on, when it actually works ;)]. Since concurrent access to the data is thus possible, this mode requires the use of a shared cluster file system that utilizes a distributed lock manager. Examples include <<ch-gfs,GFS>> and <<ch-ocfs2,OCFS2>>.
zh: 在双主模式下，资源在任何给定时间都处于两个群集节点上的主角色footnote:[也许该功能稍后会在实际工作时重命名为"Multi Primary" ;)]。由于可以并发访问数据，因此此模式需要依赖使用分布式锁管理器的共享群集文件系统。示例包括<<ch-gfs,GFS>>和<<ch-ocfs2,OCFS2>>。

note: type: Plain text
en: Deploying DRBD in dual-primary mode is the preferred approach for load-balancing clusters which require concurrent data access from two nodes, e.g. virtualization environments with a need for live-migration.  This mode is disabled by default, and must be enabled explicitly in DRBD's configuration file.
zh: 在双主模式下部署DRBD是负载均衡集群的首选方法，这种集群需要从两个节点并发访问数据，例如需要实时迁移的虚拟化环境。此模式在默认情况下是禁用的，并且必须在DRBD的配置文件中显式启用。

note: type: Plain text
en: See <<s-enable-dual-primary>> for information on enabling dual-primary mode for specific resources.
zh: 有关为特定资源启用双主模式的信息，请参见<<s-enable-dual-primary>>。

note: type: Title ===
en: Replication modes
zh: 复制(Replication)模式

note: type: Plain text
en: DRBD supports three distinct replication modes, allowing three degrees of replication synchronicity.
zh: DRBD支持三种不同的复制模式，允许三种程度的复制同步性。

note: type: Plain text
en: Asynchronous replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has finished, and the replication packet has been placed in the local TCP send buffer. In the event of forced fail-over, data loss may occur. The data on the standby node is consistent after fail-over; however, the most recent updates performed prior to the crash could be lost. Protocol A is most often used in long distance replication scenarios.  When used in combination with DRBD Proxy it makes an effective disaster recovery solution. See <<s-drbd-proxy>>, for more information.
zh: 异步复制协议。一旦本地磁盘写入完成，并且复制数据包已放置在本地TCP发送缓冲区中，则认为主节点上的本地写入操作已完成。在强制故障转移的情况下，可能会发生数据丢失。备用节点上的数据在故障转移后是一致的；但是，在崩溃之前执行的最新更新可能会丢失。Protocol A最常用于远程复制场景。当与DRBD Proxy结合使用时，它是一个有效的灾难恢复解决方案。有关详细信息，请参见<<s-drbd-proxy>>。

note: type: Plain text
en: Memory synchronous (semi-synchronous) replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred, and the replication packet has reached the peer node. Normally, no writes are lost in case of forced fail-over. However, in the event of simultaneous power failure on both nodes *and* concurrent, irreversible destruction of the primary's data store, the most recent writes completed on the primary may be lost.
zh: 内存同步（半同步）复制协议。一旦本地磁盘写入发生，并且复制数据包已到达对等节点，则认为主节点上的本地写入操作已完成。通常，在强制故障转移的情况下不会丢失任何写操作。但是，如果同时在主备节点 *同时* 发生了电源故障，则主节点的数据存储可能会丢失最新完成的写入操作。

note: type: Plain text
en: Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write(s) have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss. Data loss is, of course, inevitable even with this replication protocol if all nodes (resp. their storage subsystems) are irreversibly destroyed at the same time.
zh: 同步复制协议。只有在确认本地和远程磁盘写入之后，主节点上的本地写入操作才被视为完成。因此，单个节点的丢失不会导致任何数据丢失。数据丢失当然是不可避免的，即使采用这个复制协议，如果所有节点（例如:它们的存储子系统）同时遭到不可逆转的破坏, 数据也可能丢失。

note: type: Plain text
en: By far, the most commonly used replication protocol in DRBD setups is protocol C.
zh: 到目前为止，DRBD设置中最常用的复制协议是protocol C。

note: type: Plain text
en: The choice of replication protocol influences two factors of your deployment: _protection_ and _latency_. _Throughput_, by contrast, is largely independent of the replication protocol selected.
zh: 复制协议的选择影响部署的两个因素： _保护_ 和 _延迟_ 。相比之下， _吞吐量_ 在很大程度上独立于所选的复制协议。

note: type: Plain text
en: See <<s-configure-resource>> for an example resource configuration which demonstrates replication protocol configuration.
zh: 有关演示复制协议配置的资源配置示例，请参见<<s-configure-resource>>。

note: type: Title ===
en: More than 2-way redundancy
zh: 不只双向冗余(2-way redundancy)

note: type: Plain text
en: With DRBD 9 it's possible to have the data stored simultaneously on more than two cluster nodes.
zh: 使用DRBD 9，可以将数据同时存储在两个以上的集群节点上。

note: type: Plain text
en: While this has been possible before via <<s-three-way-repl,stacking>>, in DRBD 9 this is supported out-of-the-box for (currently) up to 16 nodes.  (In practice, using 3-, 4- or perhaps 5-way redundancy via DRBD will make other things the leading cause of downtime.)
zh: 在以前通过<<s-three-way-repl,stacking>>来实现不只双向冗余是可能的，但在DRBD 9中，目前直接就可以支持多达16个节点。（实际上，通过DRBD使用3、4乃至5路冗余将使其他事情成为停机的主要原因。）

note: type: Plain text
en: The major difference to the stacking solution is that there's less performance loss, because only one level of data replication is being used.
zh: 与stacking解决方案的主要区别在于性能损失更小，因为只使用了一个级别的数据复制。

note: Eg. if availability for a single node is 99%, for two nodes it might be 99.99%, for three nodes 99.999% type: Title ===
en: Automatic Promotion of Resources
zh: 自动提升资源

note: type: Plain text
en: Prior to DRBD 9, promoting a resource would be done with the `drbdadm primary` command. With DRBD 9, DRBD will automatically promote a resource to primary role when the `auto-promote` option is enabled, and one of its volumes is mounted or opened for writing. As soon as all volumes are unmounted or closed, the role of the resource changes back to secondary.
zh: 在DRBD 9之前，可以使用 `drbdadm primary` 命令提升资源。在DRBD 9下，当启用 `auto promote` 选项时，DRBD将自动将资源提升为主角色，并装入或打开其中一个卷进行写入。一旦卸载或关闭所有卷，资源的角色就变回次要角色。

note: type: Plain text
en: Automatic promotion will only succeed if the cluster state allows it (that is, if an explicit `drbdadm primary` command would succeed). Otherwise, mounting or opening the device fails as it did prior to DRBD 9.
zh: 只有在群集状态允许时（即，如果显示 `drbdadm primary` 命令成功），自动提升才会成功。否则，安装或打开设备将失败，就像在DRBD 9之前一样。

note: type: Title ===
en: Multiple replication transports
zh: 多种复制传输

note: type: Plain text
en: DRBD supports multiple network transports. As of now two transport implementations are available: TCP and RDMA. Each transport implementation comes as its own kernel module.
zh: DRBD支持多种网络传输。到目前为止，有两种传输实现可用：TCP和RDMA。每个传输都由对应的内核模块来实现。

note: type: Title ====
en: TCP Transport
zh: TCP传输

note: type: Plain text
en: The `drbd_transport_tcp.ko` transport implementation is included with the distribution files of drbd itself.  As the name implies, this transport implementation uses the TCP/IP protocol to move data between machines.
zh: `drbd_transport_tcp.ko` 传输实现包含在drbd本身的分发文件中。顾名思义，这个传输实现使用TCP/IP协议在机器之间移动数据。

note: type: Plain text
en: DRBD's replication and synchronization framework socket layer supports multiple low-level transports:
zh: DRBD的复制和同步框架套接字层支持多个低级传输：

note: type: Block title
en: TCP over IPv4
zh: IPv4上的TCP

note: type: Plain text
en: This is the canonical implementation, and DRBD's default. It may be used on any system that has IPv4 enabled.
zh: 这是规范实现，也是DRBD的默认实现。它可以在任何启用了IPv4的系统上使用。

note: type: Block title
en: TCP over IPv6
zh: IPv6上的TCP

note: type: Plain text
en: When configured to use standard TCP sockets for replication and synchronization, DRBD can use also IPv6 as its network protocol. This is equivalent in semantics and performance to IPv4, albeit using a different addressing scheme.
zh: 当配置为使用标准的TCP套接字进行复制和同步时，DRBD还可以使用IPv6作为其网络协议。这在语义和性能上等同于IPv4，尽管它使用不同的寻址方案。

note: type: Plain text
en: SDP is an implementation of BSD-style sockets for RDMA capable transports such as InfiniBand. SDP was available as part of the OFED stack of most distributions but is now *considered deprecated*. SDP uses an IPv4-style addressing scheme. Employed over an InfiniBand interconnect, SDP provides a high-throughput, low-latency replication network to DRBD.
zh: SDP是BSD风格的套接字的实现，用于支持RDMA的传输，如InfiniBand。SDP是大多数发行版OFED堆栈的一部分，但现在 *被视为已弃用* 。SDP使用IPv4风格的寻址方案。SDP通过InfiniBand互连使用，为DRBD提供了一个高吞吐量、低延迟的复制网络。

note: type: Plain text
en: SuperSockets replace the TCP/IP portions of the stack with a single, monolithic, highly efficient and RDMA capable socket implementation. DRBD can use this socket type for very low latency replication. SuperSockets must run on specific hardware which is currently available from a single vendor, Dolphin Interconnect Solutions.
zh: SuperSockets用一个单一的、单片的、高效的、支持RDMA的套接字实现来替换堆栈的TCP/IP部分。DRBD可以使用这种套接字类型进行非常低延迟的复制。SuperSockets必须运行在特定的硬件上，而这些硬件目前只能从一家供应商Dolphin Interconnect Solutions获得。

note: type: Title ====
en: RDMA Transport
zh: RDMA传输

note: type: Plain text
en: Alternatively the `drbd_transport_rdma.ko` kernel module is available from LINBIT. This transport uses the verbs/RDMA API to move data over InfiniBand HCAs, iWARP capable NICs or RoCE capable NICs. In contrast to the BSD sockets API (used by TCP/IP) the verbs/RDMA API allows data movement with very little CPU involvement.
zh: 此外，LINBIT提供 `drbd_transport_rdma.ko` 内核模块。此传输使用verbs/RDMA API在InfiniBand HCAs、支持iWARP的NICs或支持RoCE的NICs上移动数据。与BSD sockets API（由TCP/IP使用）相比，verbs/rdmaapi允许在很少的CPU参与下移动数据。

note: type: Title ====
en: Conclusion
zh: 结论

note: type: Plain text
en: At high transfer rates it might be possible that the CPU load/memory bandwidth of the tcp transport becomes the limiting factor. You can probably achieve higher transfer rates using the rdma transport with appropriate hardware.
zh: 在高传输速率下，tcp传输的CPU负载/内存带宽可能成为限制因素。使用rdma传输和适当的硬件，您可能可以获得更高的传输速率。

note: type: Plain text
en: A transport implementation can be configured for each connection of a resource. See <<s-configuring-transports>> for more details.
zh: 可以为资源的每个连接配置传输层实现。有关详细信息，请参见<<s-configuring-transports>>。

note: type: Title ===
en: Efficient synchronization
zh: 高效同步

note: type: Plain text
en: (Re-)synchronization is distinct from device replication. While replication occurs on any write event to a resource in the primary role, synchronization is decoupled from incoming writes. Rather, it affects the device as a whole.
zh: （重新）同步不同于设备复制。当对主角色中的资源的任何写入事件发生复制时，同步与传入的写操作是分离的。否则，它会影响到设备整体。

note: type: Plain text
en: Synchronization is necessary if the replication link has been interrupted for any reason, be it due to failure of the primary node, failure of the secondary node, or interruption of the replication link. Synchronization is efficient in the sense that DRBD does not synchronize modified blocks in the order they were originally written, but in linear order, which has the following consequences:
zh: 如果复制链路由于任何原因中断（无论是由于主节点故障、辅助节点故障还是复制链路中断）时，则必须进行同步。同步是有效的，因为DRBD不会按照修改后的块最初写入的顺序，而是按照线性顺序同步，这会产生以下后果：

note: type: Plain text
en: Synchronization is fast, since blocks in which several successive write operations occurred are only synchronized once.
zh: 同步速度很快，因为发生多个连续写操作的块只同步一次。

note: type: Plain text
en: Synchronization is also associated with few disk seeks, as blocks are synchronized according to the natural on-disk block layout.
zh: 同步还与很少的磁盘查找相关，因为块是根据磁盘上块的自然布局进行同步的。

note: type: Plain text
en: During synchronization, the data set on the standby node is partly obsolete and partly already updated. This state of data is called _inconsistent_.
zh: 在同步过程中，备用节点上的数据集部分过时，部分已更新。这种数据状态称为 _不一致_ 。

note: type: Plain text
en: The service continues to run uninterrupted on the active node, while background synchronization is in progress.
zh: 后台同步正在进行时，服务继续在活动节点上不间断地运行。

note: type: Plain text
en: A node with inconsistent data generally cannot be put into operation, thus it is desirable to keep the time period during which a node is inconsistent as short as possible. DRBD does, however, ship with an LVM integration facility that automates the creation of LVM snapshots immediately before synchronization. This ensures that a _consistent_ copy of the data is always available on the peer, even while synchronization is running. See <<s-lvm-snapshots>> for details on using this facility.
zh: 数据不一致的节点通常不能投入运行，因此希望尽可能缩短节点不一致的时间段。基于此，DRBD附带了LVM集成工具，用于在同步之前自动创建LVM快照。这可以确保对等机上始终可以使用数据的一致性副本，即使同步正在运行。有关使用此工具的详细信息，请参见<<s-lvm-snapshots>>。

note: type: Title ====
en: Variable-rate synchronization
zh: 可变速率同步

note: type: Plain text
en: In variable-rate synchronization (the default since 8.4), DRBD detects the available bandwidth on the synchronization network, compares it to incoming foreground application I/O, and selects an appropriate synchronization rate based on a fully automatic control loop.
zh: 在可变速率同步（8.4版本后被设为默认值）中，DRBD检测同步网络上的可用带宽，将其与传入的前台应用程序I/O进行比较，并基于全自动控制回路选择适当的同步速率。

note: type: Plain text
en: See <<s-configure-sync-rate-variable>> for configuration suggestions with regard to variable-rate synchronization.
zh: 有关可变速率同步的配置建议，请参见<<s-configure-sync-rate-variable>>。

note: type: Title ====
en: Fixed-rate synchronization
zh: 固定速率同步

note: type: Plain text
en: In fixed-rate synchronization, the amount of data shipped to the synchronizing peer per second (the _synchronization rate_) has a configurable, static upper limit. Based on this limit, you may estimate the expected sync time based on the following simple formula:
zh: 在固定速率同步中，每秒传送到同步对等机的数据量（同步速率）有一个可配置的静态上限。基于此限制，您可以根据以下简单公式估计预期的同步时间：

note: type: Block title
en: Synchronization time
zh: 同步时间

note: type: Plain text
en: _t~sync~_ is the expected sync time. _D_ is the amount of data to be synchronized, which you are unlikely to have any influence over (this is the amount of data that was modified by your application while the replication link was broken).  _R_ is the rate of synchronization, which is configurable -- bounded by the throughput limitations of the replication network and I/O subsystem.
zh: _t~sync~_ 是预期的同步时间。_D_ 是要同步的数据量，这两者很难人为干预（这是复制链接断开时应用程序修改的数据量）。_R_ 是可配置的同步速率，受限于复制网络和I/O子系统的吞吐量限制。

note: type: Plain text
en: See <<s-configure-sync-rate>> for configuration suggestions with regard to fixed-rate synchronization.
zh: 有关固定速率同步的配置建议，请参见<<s-configure-sync-rate>>。

note: type: Title ====
en: Checksum-based synchronization
zh: 基于校验和的同步

note: type: Plain text
en: The efficiency of DRBD's synchronization algorithm may be further enhanced by using data digests, also known as checksums. When using checksum-based synchronization, then rather than performing a brute-force overwrite of blocks marked out of sync, DRBD _reads_ blocks before synchronizing them and computes a hash of the contents currently found on disk. It then compares this hash with one computed from the same sector on the peer, and omits re-writing this block if the hashes match. This can dramatically cut down synchronization times in situation where a filesystem re-writes a sector with identical contents while DRBD is in disconnected mode.
zh: 通过使用数据摘要（也称为校验和）可以进一步提高DRBD的同步算法的效率。当使用基于校验和的同步时，DRBD在同步前先 _读取_ 块，并计算当前在磁盘上找到的内容的哈希，而不是对标记为不同步的块执行强制覆盖。然后，它将此哈希与从对等机上的同一扇区计算的哈希进行比较，如果哈希匹配，则省略重新写入此块。如果文件系统在DRBD处于断开模式时用相同的内容重新写入了扇区，这可以显著缩短同步时间。

note: type: Plain text
en: See <<s-configure-checksum-sync>> for configuration suggestions with regard to synchronization.
zh: 有关同步的配置建议，请参见<<s-configure-checksum-sync>>。

note: type: Title ===
en: Suspended replication
zh: 已挂起的复制

note: type: Plain text
en: If properly configured, DRBD can detect if the replication network is congested, and _suspend_ replication in this case. In this mode, the primary node "pulls ahead" of the secondary -- temporarily going out of sync, but still leaving a consistent copy on the secondary. When more bandwidth becomes available, replication automatically resumes and a background synchronization takes place.
zh: 如果配置正确，DRBD可以检测复制网络是否拥塞，在这种情况下可以暂停复制。在这种模式下，主节点会"超前"于次节点 即 暂时不同步，但仍在次节点上保留一致的副本。当有更多带宽可用时，复制将自动恢复并进行后台同步。

note: type: Plain text
en: Suspended replication is typically enabled over links with variable bandwidth, such as wide area replication over shared connections between data centers or cloud instances.
zh: 挂起复制通常在具有可变带宽的链接上启用，例如在数据中心或云实例之间的共享连接上启用广域复制。

note: type: Plain text
en: See <<s-configure-congestion-policy>> for details on congestion policies and suspended replication.
zh: 有关拥塞策略和挂起复制的详细信息，请参见<<s-configure-congestion-policy>>。

note: type: Title ===
en: On-line device verification
zh: 在线设备验证

note: type: Plain text
en: On-line device verification enables users to do a block-by-block data integrity check between nodes in a very efficient manner.
zh: 在线设备验证使用户能够以非常有效的方式在节点之间执行逐块数据完整性检查。

note: type: Plain text
en: Note that _efficient_ refers to efficient use of network bandwidth here, and to the fact that verification does not break redundancy in any way. On-line verification is still a resource-intensive operation, with a noticeable impact on CPU utilization and load average.
zh: 注意 _efficient_ 是指的是网络带宽的有效使用，以及验证不会以任何方式破坏冗余的事实。在线验证仍然是一个资源密集型操作，对CPU利用率和平均负载有显著影响。

note: type: Plain text
en: It works by one node (the _verification source_) sequentially calculating a cryptographic digest of every block stored on the lower-level storage device of a particular resource. DRBD then transmits that digest to the peer node(s) (the _verification target(s)_), where it is checked against a digest of the local copy of the affected block. If the digests do not match, the block is marked out-of-sync and may later be synchronized. Because DRBD transmits just the digests, not the full blocks, on-line verification uses network bandwidth very efficiently.
zh: 在线验证由一个节点（ _verification source_ ）按顺序计算存储在特定资源的低级存储设备上的每个块的密码摘要。然后，DRBD将该摘要发送到对等节点（即 _verification targets(s)_），在对等节点中，根据受影响块的本地副本摘要对其进行检查。如果摘要不匹配，则块被标记为不同步，以后可能会同步。因为DRBD只传输摘要，而不是完整的块，所以在线验证能非常有效地使用网络带宽。

note: type: Plain text
en: The process is termed _on-line_ verification because it does not require that the DRBD resource being verified is unused at the time of verification. Thus, though it does carry a slight performance penalty while it is running, on-line verification does not cause service interruption or system down time -- neither during the verification run nor during subsequent synchronization.
zh: 该过程被称为在线验证， _on-line_ 验证，因为它不要求被验证的DRBD资源在验证时未被使用。因此，尽管在线验证在运行时确实会带来轻微的性能损失，但它不会导致服务中断或系统停机 -- 无论是在验证运行期间还是在随后的同步期间。

note: type: Plain text
en: It is a common use case to have on-line verification managed by the local cron daemon, running it, for example, once a week or once a month.  See <<s-use-online-verify>> for information on how to enable, invoke, and automate on-line verification.
zh: 由本地cron守护进程管理 on-line 验证是一个常见的用例，例如，每周或每月运行一次。有关如何启用、调用和自动执行联机验证的信息，请参见<<s-use-online-verify>>。

note: type: Title ===
en: Replication traffic integrity checking
zh: 复制流量完整性检查

note: type: Plain text
en: DRBD optionally performs end-to-end message integrity checking using cryptographic message digest algorithms such as MD5, SHA-1, or CRC-32C.
zh: DRBD可以选择使用加密消息摘要算法（如MD5、SHA-1或CRC-32C）执行端到端消息完整性检查。

note: type: Plain text
en: These message digest algorithms are *not* provided by DRBD, but by the Linux kernel crypto API; DRBD merely uses them. Thus, DRBD is capable of utilizing any message digest algorithm available in a particular system's kernel configuration.
zh: 这些消息摘要算法 *不是* 由DRBD提供的，而是由Linux内核加密API提供的；DRBD只是使用它们。因此，DRBD能够利用特定系统内核配置中可用的任何消息摘要算法。

note: type: Plain text
en: With this feature enabled, DRBD generates a message digest of every data block it replicates to the peer, which the peer then uses to verify the integrity of the replication packet. If the replicated block can not be verified against the digest, the connection is dropped and immediately re-established; because of the bitmap the typical result is a retransmission. Thus, DRBD replication is protected against several error sources, all of which, if unchecked, would potentially lead to data corruption during the replication process:
zh: 启用此功能后，DRBD生成复制到对等方的每个数据块的消息摘要，然后对等方使用该摘要来验证复制包的完整性。如果无法根据摘要验证复制的块，则会断开连接并立即重新建立；由于位图的存在，典型的结果是重新传输。因此，DRBD复制可以避免一些错误的源资源，如果对这些错误源执行检查，则在复制过程中可能会导致数据损坏：

note: type: Plain text
en: Bitwise errors ("bit flips") occurring on data in transit between main memory and the network interface on the sending node (which goes undetected by TCP checksumming if it is offloaded to the network card, as is common in recent implementations);
zh: 在主存储器和发送节点上的网络接口之间传输的数据上会发生按位错误（"位翻转"）（如果将其卸载到网卡，则TCP校验和无法检测到该错误，这在最近的实现中很常见）；

note: type: Plain text
en: Bit flips occurring on data in transit from the network interface to main memory on the receiving node (the same considerations apply for TCP checksum offloading);
zh: 在从网络接口传输到接收节点的主存储器的数据上发生的位翻转（同样的考虑适用于TCP校验和卸载）；

note: type: Plain text
en: Any form of corruption due to a race conditions or bugs in network interface firmware or drivers;
zh: 由于网络接口固件或驱动程序中的竞争条件或错误而导致的任何形式的损坏；

note: type: Plain text
en: Bit flips or random corruption injected by some reassembling network component between nodes (if not using direct, back-to-back connections).
zh: 通过在节点之间重新组装网络组件（如果不使用直接的背对背连接）注入的位翻转或随机损坏。

note: type: Plain text
en: See <<s-configure-integrity-check>> for information on how to enable replication traffic integrity checking.
zh: 有关如何启用复制通信完整性检查的信息，请参见<<s-configure-integrity-check>>。

note: type: Title ===
en: Split brain notification and automatic recovery
zh: 裂脑通知和自动恢复

note: type: Plain text
en: Split brain is a situation where, due to temporary failure of all network links between cluster nodes, and possibly due to intervention by a cluster management software or human error, both nodes switched to the _Primary_ role while disconnected. This is a potentially harmful state, as it implies that modifications to the data might have been made on either node, without having been replicated to the peer. Thus, it is likely in this situation that two diverging sets of data have been created, which cannot be trivially merged.
zh: 裂脑是指由于群集节点之间的所有网络链路的暂时故障，以及可能由于群集管理软件的干预或人为错误，两个节点在断开连接时都切换到主要角色的情况。这是一种潜在的有害状态，因为它意味着对数据的修改可能是在任一节点上进行的，而没有复制到对等节点。因此，在这种情况下，很可能已经创建了两个不同的数据集，这些数据集不能简单地合并。

note: type: Plain text
en: DRBD split brain is distinct from cluster split brain, which is the loss of all connectivity between hosts managed by a distributed cluster management application such as Heartbeat. To avoid confusion, this guide uses the following convention:
zh: DRBD split brain不同于集群split brain，集群split brain是由分布式集群管理应用程序（如Heartbeat）管理的主机之间的所有连接丢失。为避免混淆，本指南使用以下约定：

note: type: Plain text
en: _Split brain_ refers to DRBD split brain as described in the paragraph above.
zh: _裂脑_ 是指如上文所述的DRBD裂脑。

note: type: Plain text
en: Loss of all cluster connectivity is referred to as a _cluster partition_, an alternative term for cluster split brain.
zh: 所有集群连接的丧失被称为 _集群分片_，是集群裂脑的另一个术语。

note: type: Plain text
en: DRBD allows for automatic operator notification (by email or other means) when it detects split brain. See <<s-split-brain-notification>> for details on how to configure this feature.
zh: DRBD允许在检测到脑裂时自动通知管理员（通过电子邮件或其他方式）。有关如何配置此功能的详细信息，请参见<<s-split-brain-notification>>。

note: type: Plain text
en: While the recommended course of action in this scenario is to <<s-resolve-split-brain,manually resolve>> the split brain and then eliminate its root cause, it may be desirable, in some cases, to automate the process. DRBD has several resolution algorithms available for doing so:
zh: 虽然在这种情况下，建议的操作过程是<<s-resolve-split-brain,manually resolve>>处理脑裂，然后消除其根本原因，但在某些情况下，可能需要自动化该过程。DRBD有几种可用的解决方案列举如下：

note: type: Plain text
en: *Discarding modifications made on the younger primary.* In this
    mode, when the network connection is re-established and split brain
    is discovered, DRBD will discard modifications made, in the
    meantime, on the node which switched to the primary role _last_.
zh: *放弃较新主节点上的修改。* 在这种模式下，当重新建立网络连接并发现裂脑时，
    DRBD在_最后_切换到主模式的节点上，会放弃在该节点上的更改。

note: type: Plain text
en: *Discarding modifications made on the older primary.* In this mode,
    DRBD will discard modifications made, in the meantime, on the node
    which switched to the primary role _first_.
zh: *放弃较旧主节点上的修改。* 在这种模式下，DRBD会放弃先前切换到
    主模式的节点上所做的修改。

note: type: Plain text
en: *Discarding modifications on the primary with fewer changes.* In
    this mode, DRBD will check which of the two nodes has recorded fewer
    modifications, and will then discard _all_ modifications made on
    that host.
zh: *放弃改动小的主节点上的修改。* 在这种模式下，
    DRBD将检查两个节点中的哪个节点记录了较少的修改，然后将丢弃在该主机上进行的所有修改。

note: type: Plain text
en: *Graceful recovery from split brain if one host has had no
    intermediate changes.* In this mode, if one of the hosts has made no
    modifications at all during split brain, DRBD will simply recover
    gracefully and declare the split brain resolved. Note that this is a
    fairly unlikely scenario. Even if both hosts only mounted the file
    system on the DRBD block device (even read-only), the device
    contents typically would be modified (e.g. by filesystem journal
    replay), ruling out the possibility of automatic
    recovery.
zh: *如果任一节点没有中间变化，则可以从裂脑中恢复。* 在这种模式下，
    如果其中一个主机在裂脑期间根本没有进行任何修改，则DRBD会简单地恢复正常并宣布裂脑已解决。
    请注意，这是一个不太可能发生的情况。即使两个主机都仅将文件系统安装在DRBD块设备上（甚至是只读的），
    设备的内容通常也会被修改（例如，通过文件系统日志重播），从而排除了自动恢复的可能性。

note: type: Plain text
en: Whether or not automatic split brain recovery is acceptable depends largely on the individual application.  Consider the example of DRBD hosting a database. The discard modifications from host with fewer changes approach may be fine for a web application click-through database. By contrast, it may be totally unacceptable to automatically discard _any_ modifications made to a financial database, requiring manual recovery in any split brain event. Consider your application's requirements carefully before enabling automatic split brain recovery.
zh: 自动裂脑恢复是否可以接受在很大程度上取决于运行的应用。以DRBD托管数据库为例。
    对于web应用程序使用的点击型数据库，使用放弃改动小的主节点上的修改的方法可能很好。
    相比之下，自动放弃对财务数据库所做的任何修改可能是完全不可接受的，在任何脑分裂事件中都需要手动恢复。
    在启用自动裂脑恢复之前，请仔细考虑应用程序的要求。

note: type: Plain text
en: Refer to <<s-automatic-split-brain-recovery-configuration>> for details on configuring DRBD's automatic split brain recovery policies.
zh: 请参阅<<s-automatic-split-brain-recovery-configuration>>以了解有关配置DRBD的自动裂脑恢复策略的详细信息。

note: type: Title ===
en: Support for disk flushes
zh: 支持磁盘刷新

note: type: Plain text
en: When local block devices such as hard drives or RAID logical disks have write caching enabled, writes to these devices are considered completed as soon as they have reached the volatile cache. Controller manufacturers typically refer to this as write-back mode, the opposite being write-through. If a power outage occurs on a controller in write-back mode, the last writes are never committed to the disk, potentially causing data loss.
zh: 当本地块设备（如硬盘驱动器或RAID逻辑磁盘）启用了写缓存时，对这些设备的写入在到达易失性缓存后即被视为完成。控制器制造商通常将此称为回写模式，反之则为直写模式。如果控制器在回写模式下断电，则最后一次写入永远不会提交到磁盘，可能会导致数据丢失。

note: type: Plain text
en: To counteract this, DRBD makes use of disk flushes. A disk flush is a write operation that completes only when the associated data has been committed to stable (non-volatile) storage -- that is to say, it has effectively been written to disk, rather than to the cache. DRBD uses disk flushes for write operations both to its replicated data set and to its meta data. In effect, DRBD circumvents the write cache in situations it deems necessary, as in <<s-activity-log,activity log>> updates or enforcement of implicit write-after-write dependencies. This means additional reliability even in the face of power failure.
zh: 为了解决这个问题，DRBD使用了磁盘刷新。磁盘刷新是一种写入操作，仅当关联的数据已提交到稳定（非易失性）存储时才完成，也就是说，它已有效地写入磁盘，而不是缓存。DRBD使用磁盘刷新对其复制的数据集和元数据进行写操作。实际上，DRBD在其认为必要的情况下绕过写缓存，如在<<s-activity-log,activity log>>更新或强制隐式写后依赖项中。这意味着即使在停电的情况下，也会有额外的可靠性。

note: type: Plain text
en: It is important to understand that DRBD can use disk flushes only when layered on top of backing devices that support them.  Most reasonably recent kernels support disk flushes for most SCSI and SATA devices. Linux software RAID (md) supports disk flushes for RAID-1 provided that all component devices support them too. The same is true for device-mapper devices (LVM2, dm-raid, multipath).
zh: 需要了解的是，DRBD只能在落地于支持磁盘刷新的备份设备上时才能使用磁盘刷新，这一点很重要。最新的内核支持大多数SCSI和SATA设备的磁盘刷新。Linux软件RAID（md）支持RAID-1的磁盘刷新，前提是所有组件设备也支持磁盘刷新。设备映射器(device-mapper)设备（LVM2、dm raid、多路径）也是如此。

note: type: Plain text
en: Controllers with battery-backed write cache (BBWC) use a battery to back up their volatile storage. On such devices, when power is restored after an outage, the controller flushes all pending writes out to disk from the battery-backed cache, ensuring that all writes committed to the volatile cache are actually transferred to stable storage. When running DRBD on top of such devices, it may be acceptable to disable disk flushes, thereby improving DRBD's write performance. See <<s-disable-flushes>> for details.
zh: 带电池备份的写缓存（BBWC）的控制器使用电池备份其易失性存储。在这些设备上，当断电后恢复供电时，控制器会从电池支持的高速缓存中清除所有挂起的写入到磁盘的操作，确保提交到易失性高速缓存的所有写入实际上都转移到稳定存储中。在这些设备上运行DRBD时，可以禁用磁盘刷新，从而提高DRBD的写入性能。有关详细信息，请参见<<s-disable-flushes>>。

note: type: Title ===
en: Trim/Discard support
zh: Trim/Discard支持

note: type: Plain text
en: _Trim_/_Discard_ are two names for the same feature: a request to a storage system, telling it that some data range is not being used anymorefootnote:[For example, a deleted file's data.] and can get recycled. + This call originates in Flash-based storages (SSDs, FusionIO cards, etc.), which cannot easily _rewrite_ a sector but instead have to _erase_ and write the (new) data again (incurring some latency cost). For more details, see e.g.  the [[https://en.wikipedia.org/wiki/Trim_%28computing%29,wikipedia page]].
zh: _Trim_/_Discard_ 是同一功能的两个名称：对存储系统的请求，告诉它某些数据区域不再使用footnote:[例如，已删除文件的数据]，并且可以被回收。+ 此调用源于基于闪存的存储（固态硬盘、FusionIO卡等），这些存储不能轻易重写 _rewrite_ 扇区，而是必须擦除后并再次写入（新）数据（产生一定的延迟成本）。有关更多详细信息，请参见 [[https://en.wikipedia.org/wiki/Trim_%28computing%29,wikipedia page]].

note: type: Plain text
en: Since 8.4.3 DRBD includes support for _Trim_/_Discard_. You don't need to configure or enable anything; if DRBD detects that the local (underlying) storage system allows using these commands, it will transparently enable them and pass such requests through.
zh: 从8.4.3版开始， DRBD包含了对 _Trim_/_Discard_ 的支持。您不需要配置或启用任何东西；如果DRBD检测到本地（底层）存储系统允许使用这些命令，它将透明地启用这些命令并传递这些请求。

note: type: Plain text
en: The effect is that e.g. a recent-enough `mkfs.ext4` on a multi-TB volume can shorten the initial sync time to a few seconds to minutes - just by telling DRBD (which will relay that information to all connected nodes) that most/all of the storage is now to be seen as invalidated.
zh: 其效果是，例如，在一个有很多TB的卷上使用一个新版本的 `mkfs.ext4` 时，可以将初始同步时间缩短到几秒到几分钟，只要告诉DRBD（它将把该信息中继到所有连接的节点），大多数/所有存储现在都将被视为无效。

note: type: Plain text
en: Nodes that connect to that resource later on will not have seen the _Trim_/_Discard_ requests, and will therefore start a full resync; depending on kernel version and file system a call to `fstrim` might give the wanted result, though.
zh: 稍后连接到该资源的节点将不会看到 _Trim_/_Discard_ 请求，因此将启动完全重新同步；不过，依赖于内核版本和文件系统，对`fstrim`的调用可能会给出所需的结果。

note: type: Plain text
en: even if you don't have storage with _Trim_/_Discard_ support, some virtual block devices will provide you with the same feature, for example Thin LVM.
zh: 即使您没有支持 _Trim_/_Discard_ 的存储，一些虚拟块设备也会为您提供相同的功能，例如精简LVM。

note: type: Title ===
en: Disk error handling strategies
zh: 磁盘错误处理策略

note: type: Plain text
en: If a hard drive fails which is used as a backing block device for DRBD on one of the nodes, DRBD may either pass on the I/O error to the upper layer (usually the file system) or it can mask I/O errors from upper layers.
zh: 如果被用作其中一个节点上DRBD的备份块设备的硬盘发生故障，DRBD可以将I/O错误传递到上层（通常是文件系统），也可以屏蔽上层的I/O错误。

note: type: Block title
en: Passing on I/O errors
zh: 传递I/O错误

note: type: Plain text
en: If DRBD is configured to pass on I/O errors, any such errors occurring on the lower-level device are transparently passed to upper I/O layers. Thus, it is left to upper layers to deal with such errors (this may result in a file system being remounted read-only, for example). This strategy does not ensure service continuity, and is hence not recommended for most users.
zh: 如果DRBD被配置为传递I/O错误，那么在低级设备上发生的任何此类错误都将透明地传递到上层I/O层。因此，由上层处理这些错误（例如，这可能导致文件系统以只读方式重新装载）。此策略无法确保服务的连续性，因此不建议大多数用户使用。

note: type: Block title
en: Masking I/O errors
zh: 掩蔽I/O错误

note: type: Plain text
en: If DRBD is configured to _detach_ on lower-level I/O error, DRBD will do so, automatically, upon occurrence of the first lower-level I/O error. The I/O error is masked from upper layers while DRBD transparently fetches the affected block from a peer node, over the network. From then onwards, DRBD is said to operate in diskless mode, and carries out all subsequent I/O operations, read and write, on the peer node(s) only. Performance in this mode will be reduced, but the service continues without interruption, and can be moved to the peer node in a deliberate fashion at a convenient time.
zh: 如果DRBD被配置为在低层I/O错误时分离, 即 _detach_ ，DRBD将在第一个低层I/O错误发生时自动这样做。当DRBD通过网络从对等节点透明地获取受影响的块时，I/O错误从上层被屏蔽。从那时起，DRBD被称为在无盘模式下操作，并且仅在对等节点上执行所有后续的读写I/O操作。此模式下的性能将降低，但服务不会中断，并且可以在方便的时候经过验证后再移动到对等节点。

note: type: Plain text
en: See <<s-configure-io-error-behavior>> for information on configuring I/O error handling strategies for DRBD.
zh: 有关为DRBD配置I/O错误处理策略的信息，请参见<<s-configure-io-error-behavior>>。

note: type: Title ===
en: Strategies for dealing with outdated data
zh: 处理过时数据的策略

note: type: Plain text
en: DRBD distinguishes between _inconsistent_ and _outdated_ data. Inconsistent data is data that cannot be expected to be accessible and useful in any manner. The prime example for this is data on a node that is currently the target of an on-going synchronization. Data on such a node is part obsolete, part up to date, and impossible to identify as either. Thus, for example, if the device holds a filesystem (as is commonly the case), that filesystem would be unexpected to mount or even pass an automatic filesystem check.
zh: DRBD能区分不一致数据和过时数据。不一致数据是指不能期望以任何方式访问和使用的数据。举例说明：举某节点上的数据为例，该节点当前是正在进行的同步的目标。这样一个节点上的数据部分是过时的，部分是最新的，不可能被识别为二者之一。因此，例如，如果设备持有一个文件系统（通常情况下是这样），那么该文件系统将无法挂载，甚至无法通过自动文件系统检查。

note: type: Plain text
en: Outdated data, by contrast, is data on a secondary node that is consistent, but no longer in sync with the primary node. This would occur in any interruption of the replication link, whether temporary or permanent. Data on an outdated, disconnected secondary node is expected to be clean, but it reflects a state of the peer node some time past. In order to avoid services using outdated data, DRBD disallows <<s-resource-roles,promoting a resource>> that is in the outdated state.
zh: 相比之下，过时的数据是次节点(sencondary node)上的一致数据，但不再与主节点同步。这将发生在复制链接的任何中断中，无论是临时的还是永久的。过时的、断开连接的辅助节点上的数据应该是干净的，但它反映了过去某个时间对等节点的状态。为了避免服务使用过时的数据，DRBD不允许<<s-resource-roles,promoting a resource>>。

note: type: Plain text
en: DRBD has interfaces that allow an external application to outdate a secondary node as soon as a network interruption occurs. DRBD will then refuse to switch the node to the primary role, preventing applications from using the outdated data. A complete implementation of this functionality exists for the <<ch-pacemaker,Pacemaker cluster management framework>> (where it uses a communication channel separate from the DRBD replication link). However, the interfaces are generic and may be easily used by any other cluster management application.
zh: DRBD的接口允许外部应用程序在网络中断发生时立即使辅助节点失效。DRBD将拒绝将节点切换到主角色，从而防止应用程序使用过时的数据。此功能的完整实现可参阅<<ch-pacemaker,Pacemaker cluster management framework>>（它使用与DRBD复制链接分离的通信通道）。但是，这些接口是通用的，并且很容易被任何其他集群管理应用程序使用。

note: type: Plain text
en: Whenever an outdated resource has its replication link re-established, its outdated flag is automatically cleared. A <<s-resync,background synchronization>> then follows.
zh: 每当过时的资源重新建立其复制链接时，其过时标志将自动清除。参阅<<s-resync,background synchronization>>。

note: type: Plain text
en: See the section about <<s-pacemaker-fencing-dopd,the DRBD outdate-peer daemon (dopd)>> for an example DRBD/Heartbeat/Pacemaker configuration enabling protection against inadvertent use of outdated data.
zh: 关于DRBD/Heartbeat/pacemaker配置以支持防止意外使用过时数据的示例，请参考 <<s-pacemaker-fencing-dopd,the DRBD outdate-peer daemon (dopd)>> 的章节

note: type: Title ===
en: Three-way replication via stacking
zh: 三路叠加复制

note: type: Plain text
en: Available in DRBD version 8.3.0 and above; deprecated in DRBD version 9.x, as more nodes can be implemented on a single level. See <<s-drbdconf-conns>> for details.
zh: 在DRBD版本8.3.0及更高版本中可用；在DRBD版本9.x中不推荐使用，因为更多节点可以在单个级别上实现。有关详细信息，请参见<<s-drbdconf-conns>>。

note: type: Plain text
en: When using three-way replication, DRBD adds a third node to an existing 2-node cluster and replicates data to that node, where it can be used for backup and disaster recovery purposes. This type of configuration generally involves <<s-drbd-proxy>>.
zh: 当使用三向复制时，DRBD会将第三个节点添加到现有的2节点群集，并将数据复制到该节点，在该节点上，数据可用于备份和灾难恢复目的。这种类型的配置通常涉及<<s-drbd-proxy>>。

note: type: Plain text
en: Three-way replication works by adding another, _stacked_ DRBD resource on top of the existing resource holding your production data, as seen in this illustration:
zh: 三向复制通过在保存生产数据的现有资源上添加另一个堆叠 _stacked_ 的DRBD资源来工作，如下图所示：

note: type: Block title
en: DRBD resource stacking
zh: DRBD资源堆叠

note: type: Plain text
en: The stacked resource is replicated using asynchronous replication (DRBD protocol A), whereas the production data would usually make use of synchronous replication (DRBD protocol C).
zh: 堆叠(stack)资源使用异步复制（DRBD Protocol A）进行复制，而生产数据通常使用同步复制（DRBD Protocol C）。

note: type: Plain text
en: Three-way replication can be used permanently, where the third node is continuously updated with data from the production cluster. Alternatively, it may also be employed on demand, where the production cluster is normally disconnected from the backup site, and site-to-site synchronization is performed on a regular basis, for example by running a nightly cron job.
zh: 三路复制可以永久使用，其中第三个节点将使用生产集群中的数据不断更新。或者，它也可以按需使用，其中生产集群通常与备份站点断开连接，并且定期执行站点到站点的同步，例如通过运行夜间cron作业。

note: type: Title ===
en: Long-distance replication via DRBD Proxy
zh: 通过DRBD代理进行远程复制

note: type: Plain text
en: DRBD's <<s-replication-protocols,protocol A>> is asynchronous, but the writing application will block as soon as the socket output buffer is full (see the `sndbuf-size` option in the man page of `drbd.conf`). In that event, the writing application has to wait until some of the data written runs off through a possibly small bandwidth network link.
zh: DRBD的<<s-replication-protocols,protocol A>>是异步的，但是一旦套接字输出缓冲区满了，写入应用程序就会阻塞（请参见 `DRBD.conf` 手册页中的 `sndbuf size` 选项）。在这种情况下，写入应用程序必须等到某些写入的数据, 这些数据可能要通过可能很小的带宽网络，而使得链路耗尽。

note: type: Plain text
en: The average write bandwidth is limited by available bandwidth of the network link. Write bursts can only be handled gracefully if they fit into the limited socket output buffer.
zh: 平均写入带宽受网络链路可用带宽的限制。只有配置好受限的套接字输出缓冲区时，突发写入才能被优雅的处理。

note: type: Plain text
en: You can mitigate this by DRBD Proxy's buffering mechanism.  DRBD Proxy will place changed data from the DRBD device on the primary node into its buffers. DRBD Proxy's buffer size is freely configurable, only limited by the address room size and available physical RAM.
zh: 您可以通过DRBD Proxy的缓冲机制来缓解这种情况。DRBD代理将从主节点上的DRBD设备将更改的数据放入其缓冲区。DRBD代理的缓冲区大小是可以自由配置的，仅受地址空间大小和可用物理RAM的限制。

note: type: Plain text
en: Optionally DRBD Proxy can be configured to compress and decompress the data it forwards. Compression and decompression of DRBD's data packets might slightly increase latency. However, when the bandwidth of the network link is the limiting factor, the gain in shortening transmit time outweighs the compression and decompression overhead.
zh: 可选地，可以配置DRBD代理来压缩和解压缩它转发的数据。压缩和解压缩DRBD的数据包可能会稍微增加延迟。然而，当网络链路的带宽是限制因素时，缩短传输时间的增益大于压缩和解压缩开销。

note: type: Plain text
en: Compression and decompression were implemented with multi core SMP systems in mind, and can utilize multiple CPU cores.
zh: 压缩和解压缩是在考虑多核SMP系统的情况下实现的，可以利用多个CPU核。

note: type: Plain text
en: The fact that most block I/O data compresses very well and therefore the effective bandwidth increases justifies the use of the DRBD Proxy even with DRBD protocols B and C.
zh: 事实上，大多数块I/O数据压缩得非常好，因此对带宽的使用更加有效,这证明了即使使用DRBD Protocol B和C也可以使用DRBD代理。

note: type: Plain text
en: See <<s-using-drbd-proxy>> for information on configuring DRBD Proxy.
zh: 有关配置drbd proxy的信息，请参见<<s-using-drbd-proxy>>。

note: type: Plain text
en: DRBD Proxy is one of the few parts of the DRBD product family that is not published under an open source license. Please contact sales@linbit.com or sales_us@linbit.com for an evaluation license.
zh: DRBD Proxy是DRBD产品系列中少数未在开源许可下发布的部分之一。请联系 sales@linbit.com 或 sales_us@linbit.com 获取评估许可证。

note: type: Title ===
en: Truck based replication
zh: 基于卡车的复制

note: type: Plain text
en: Truck based replication, also known as disk shipping, is a means of preseeding a remote site with data to be replicated, by physically shipping storage media to the remote site. This is particularly suited for situations where
zh: 基于卡车的复制，也称为磁盘传送，是通过物理方式将存储介质传送到远程站点，为远程站点提供要复制的数据的一种方式。这特别适用于

note: type: Plain text
en: the total amount of data to be replicated is fairly large (more than a few hundreds of gigabytes);
zh: 要复制的数据总量相当大（超过几百GB）；

note: type: Plain text
en: the expected rate of change of the data to be replicated is less than enormous;
zh: 要复制的数据的预期变化率不太大；

note: type: Plain text
en: the available network bandwidth between sites is limited.
zh: 站点之间的可用网络带宽是有限的。

note: type: Plain text
en: In such situations, without truck based replication, DRBD would require a very long initial device synchronization (on the order of weeks, months, or years). Truck based replication allows to ship a data seed to the remote site, and so drastically reduces the initial synchronization time.  See <<s-using-truck-based-replication>> for details on this use case.
zh: 在这种情况下，如果没有基于卡车的复制，DRBD将需要非常长的初始设备同步（按周、月或年的顺序）。基于卡车的复制允许将数据种子传送到远程站点，因此大大缩短了初始同步时间。有关此用例的详细信息，请参见<<s-using-truck-based-replication>>。

note: type: Title ===
en: Floating peers
zh: 浮动节点

note: type: Plain text
en: This feature is available in DRBD versions 8.3.2 and above.
zh: 此功能在DRBD 8.3.2及以上版本中可用。

note: type: Plain text
en: A somewhat special use case for DRBD is the _floating peers_ configuration. In floating peer setups, DRBD peers are not tied to specific named hosts (as in conventional configurations), but instead have the ability to float between several hosts. In such a configuration, DRBD identifies peers by IP address, rather than by host name.
zh: DRBD的一个有点特殊的用例是 _浮动节点_ 。在浮动节点设置中，DRBD节点不绑定到特定的命名主机（如在传统配置中），而是能够在多个主机之间浮动。在这种配置中，DRBD通过IP地址而不是主机名来标识对方。

note: type: Plain text
en: For more information about managing floating peer configurations, see <<s-pacemaker-floating-peers>>.
zh: 有关管理浮动对等配置的更多信息，请参见<<s-pacemaker-floating-peers>>。

note: type: Title ===
en: Data rebalancing (horizontal storage scaling)
zh: 数据重新平衡（水平存储扩展）

note: type: Plain text
en: If your company's policy says that 3-way redundancy is needed, you need at least 3 servers for your setup.
zh: 如果公司的政策规定需要3路冗余，则安装时至少需要3台服务器。

note: type: Plain text
en: Now, as your storage demands grow, you will encounter the need for additional servers. Rather than having to buy 3 more servers at the same time, you can _rebalance_ your data across a single additional node.
zh: 现在，随着存储需求的增长，您将需要额外的服务器。比起同时购买3台以上的服务器的方案，您也可以在一个额外的节点上重新平衡数据。

note: type: Block title
en: DRBD data rebalancing
zh: DRBD数据重新平衡

note: [scaledwidth="75"] type: Plain text
en: In the figure above you can see the _before_ and _after_ states: from 3 nodes with three 25TiB volumes each (for a net 75TiB), to 4 nodes, with net 100TiB.
zh: 在上图中，您可以看到 _before_ 和 _after_ 状态：从3个节点（每个节点有3个25TiB卷）(净75TiB）到4个节点（净100TiB）。

note: type: Plain text
en: DRBD 9 makes it possible to do an online, live migration of the data; please see <<s-rebalance-workflow>> for the exact steps needed.
zh: DRBD 9使在线实时迁移数据成为可能；请参见<<s-rebalance-workflow>>了解所需的确切步骤。

note: type: Title ===
en: DRBD client
zh: DRBD客户端

note: type: Plain text
en: With the multiple-peer feature of DRBD a number of interesting use-cases have been added, for example the _DRBD client_.
zh: 通过DRBD的多节点特性，添加了许多有趣的用例，例如 _DRBD 客户端_。

note: type: Plain text
en: The basic idea is that the DRBD _backend_ can consist of 3, 4, or more nodes (depending on the policy of required redundancy); but, as DRBD 9 can connect more nodes than that. DRBD works then as a storage access protocol in addition to storage replication.
zh: 基本思想是DRBD _后端_ 可以由3、4或更多节点组成（取决于所需冗余的策略）；但是，由于DRBD 9可以连接更多的节点。DRBD除了作为存储复制之外，还作为存储访问协议工作。

note: type: Plain text
en: All write requests executed on a primary _DRBD client_ gets shipped to all nodes equipped with storage. Read requests are only shipped to one of the server nodes. The _DRBD client_ will evenly distribute the read requests among all available server nodes.
zh: 在主 _DRBD客户端_ 上执行的所有写请求都会被发送到配备了存储设备的所有节点。读取请求仅传送到其中一个服务器节点。_DRBD客户端_ 将在所有可用的服务器节点之间平均分配读取请求。

note: type: Plain text
en: See <<s-permanently-diskless-nodes>> for the configuration file syntax or in case you are using drbdmanage, use its `--client` option when assigning resources to nodes.
zh: 有关配置文件语法，请参见<<s-permanently-diskless-nodes>>或在使用drbdmanage的情况下，在为节点分配资源时使用其 `--client` 选项。

note: type: Title ===
en: Quorum
zh: Quorum(仲裁)

note: type: Plain text
en: In order to avoid split brain or diverging data of replicas one has to configure fencing. It turns out that in real world deployments node fencing is not popular because often mistakes happen in planning or deploying it.
zh: 为了避免脑裂或数据分散，必须配置围栏(fencing)。事实证明，在实际部署中，节点围栏并不流行，因为在规划或部署时经常会出错。

note: type: Plain text
en: In the moment a data-set has 3 replicas one can rely on the quorum implementation within DRBD instead of Pacemaker level fencing. Pacemaker gets informed about quorum or loss-of-quorum via the master score of the resource.
zh: 当一个数据集有3个副本时，可以依赖DRBD中的仲裁实现，而不是依赖Pacemake级别的围栏。Pacemaker通过资源的master分数获得有关Quorum(仲裁)或Quorum(仲裁)丢失的通知。

note: type: Plain text
en: DRBD's quorum can be used with any kind of Linux based service. In case the service terminates in the moment it is exposed to an IO-error the on quorum loss behavior is very elegant.  In case the service does not terminate upon IO-error the systems needs to be configured to reboot a primary node that looses quorum.
zh: DRBD的quorum(仲裁)可以用于任何基于Linux的服务。如果一个服务在出现IO-错误的时候终止，quorum(仲裁）丢失的行为会非常优雅。如果服务没有在IO-错误时出现终止，则需要将系统设置为丢失Quorum(仲裁)后重启主节点。

note: type: Plain text
en: See <<s-configuring-quorum>> for more information.
zh: 有关详细信息，请参见<<s-configuring-quorum>>。

note: type: Title ====
en: Tiebreaker
zh: 断路器(Tiebreaker)

note: type: delimited block =
en: The quorum tiebreaker feature is available in DRBD versions 9.0.18 and above.
zh: quorum tiebreaker功能在DRBD版本9.0.18及更高版本中可用。

note: type: Plain text
en: The fundamental problem with two node clusters is that in the moment they lose connectivity we have two partitions and none of them has quorum, which results in the cluster halting the service. This problem can be mitigated by adding a third, diskless node to the cluster which will then act as a quorum tiebreaker.
zh: 两节点集群的根本问题是，当它们失去连接时，我们有两个分区，而它们都没有仲裁，这导致集群停止服务。这个问题可以通过在集群中添加第三个无磁盘节点来缓解，该节点将充当仲裁层断路器。

note: type: Plain text
en: See <<s-configuring-quorum-tiebreaker>> for more information.
zh: 有关详细信息，请参见<<s-configuring-quorum-tiebreaker>>。

note: type: Title ===
en: DRBD integration for VCS
zh: VCS的DRBD集成

note: type: Plain text
en: Veritas Cluster Server (or Veritas Infoscale Availabilty) is a commercial alternative to the Pacemaker open source software. In case you need to integrate DRBD resources into a VCS setup please see the README in https://github.com/LINBIT/drbd-utils/tree/master/scripts/VCS[drbd-utils/scripts/VCS] on github.
zh: Veritas Cluster Server（或Veritas Infoscale Availability）是Pacemaker开源软件的商业替代品。如果您需要将DRBD资源集成到VCS设置中，请参阅github上的  https://github.com/LINBIT/drbd-utils/tree/master/scripts/VCS[drbd-utils/scripts/VCS]
