en to ja translation catalogue (171 entries)

note: type: Title ==
en: DRBD Features
ja: 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.
ja: 本章ではDRBDの有用な機能とその背景にある情報を紹介します。いくつかの機能はほとんどのユーザーにとって重要な機能ですが、別のいくつかの機能については特定の利用目的においてのみ関係します。これらの機能を使うために必要な設定方法については、<<p-work>>および<<ch-troubleshooting>>を参照してください。

note: type: Title ===
en: Single-primary mode
ja: シングルプライマリモード

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.).
ja: シングルプライマリモードでは、個々の<<s-resources,リソース>> は、任意の時点でクラスタメンバのどれか1台のみプライマリになれます。どれか1台のクラスタノードのみがデータを更新できることが保証されるため、従来の一般的なファイルシステム(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.
ja: 一般的なハイアベイラビリティクラスタ(フェイルオーバタイプ)を実現する場合、DRBDをシングルプライマリモードで設定してください。

note: type: Title ===
en: Dual-primary mode
ja: デュアルプライマリモード

note: type: Plain text
en: In dual-primary mode a resource can be in the primary role on two nodes at a time. Since concurrent access to the data is thus possible, this mode usually requires the use of a shared cluster file system that utilizes a distributed lock manager.
ja: デュアルプライマリモードでは、リソースは一度に 2 つのノードでプライマリの役割を担うことができます。したがって、データへの同時アクセスが可能であるため、このモードでは通常、分散ロックマネージャーを利用する共有クラスターファイルシステムを使用する必要があります。

note: type: Plain text
en: Examples include <<ch-gfs,GFS>> and <<ch-ocfs2,OCFS2>>.
ja: 利用できるファイルシステムには <<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.
ja: 2つのノード経由でのデータへの同時アクセスが必要なクラスタシステムの負荷分散をはかりたい場合、デュアルプライマリモードが適しています。例えばライブマイグレーションが必要な仮想化環境などです。 このモードはデフォルトでは無効になっており、DRBD設定ファイルで明示的に有効にする必要があります。

note: type: Plain text
en: See <<s-enable-dual-primary>> for information on enabling dual-primary mode for specific resources.
ja: 特定のリソースに対して有効にする方法については、<<s-enable-dual-primary>>を参照してください。

note: type: Title ===
en: Replication modes
ja: レプリケーションのモード

note: type: Plain text
en: DRBD supports three distinct replication modes, allowing three degrees of replication synchronicity.
ja: DRBDは3種類のレプリケーションモードをサポートしています。

note: type: Block title
en: Protocol A
ja: プロトコルA

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.
ja: 非同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットを自機のTCP送信バッファに送った時点で、完了したと判断されます。システムクラッシュなどの強制的なフェイルオーバが起こると、データを紛失する可能性があります。クラッシュが原因となったフェイルオーバが起こった場合、待機系ノードのデータは整合性があると判断されますが、クラッシュ直前のアップデート内容が反映されない可能性があります。プロトコルAは、遠隔地へのレプリケーションに最も適しています。

note: type: Plain text
en: When used in combination with DRBD Proxy it makes an effective disaster recovery solution. See <<s-drbd-proxy>>, for more information.
ja: DRBD Proxyと組み合わせて使用すると、効果的なディザスタリカバリソリューションとなります。詳しくは <<s-drbd-proxy>> を参照ください。

note: type: Block title
en: Protocol B
ja: プロトコルB

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.
ja: メモリ同期(半非同期)レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットが他機に届いた時点で、完了したと判断されます。通常、システムクラッシュなどの強制的なフェイルオーバでのデータ紛失は起こりません。しかし、両ノードに同時に電源障害が起こり、プライマリノードのストレージに復旧不可能な障害が起きると、プライマリ側にのみ書き込まれたデータを失う可能性があります。

note: type: Block title
en: Protocol C
ja: プロコトルC

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.
ja: 同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、両ノードのディスクへの書き込みが終わった時点で完了したと判断されます。このため、どちらかのノードでデータを失っても、系全体としてのデータ紛失には直結しません。当然ながら、このプロトコルを採用した場合であっても、両ノードまたはそのストレージサブシステムに復旧できない障害が同時に起こると、データは失われます。

note: type: Plain text
en: By far, the most commonly used replication protocol in DRBD setups is protocol C.
ja: このような特質にもとづき、もっとも一般的に使われているプロトコルは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.
ja: レプリケーションプロトコルを選択するときに考慮しなければならない要因が2つあります。 _データ保護_ と _レイテンシ遅延_ です。一方で、レプリケーションプロトコルの選択は _スループット_ にはほとんど影響しません。

note: type: Plain text
en: See <<s-configure-resource>> for an example resource configuration which demonstrates replication protocol configuration.
ja: レプリケーションプロトコルの設定例については、<<s-configure-resource>>を参照してください。

note: type: Title ===
en: More than 2-way redundancy
ja: 2重以上の冗長性

note: type: Plain text
en: With DRBD 9 it's possible to have the data stored simultaneously on more than two cluster nodes.
ja: DRBD9では同時に2つ以上のクラスタノードにデータを書き込むことができます。

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.)
ja: これは<<s-three-way-repl,スタッキング>>を通じても可能でしたが、DRBD9では枠を超えて32ノードまで対応しました。 (実際の環境では、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.
ja: スタッキングを用いる場合との最大の違いは、同一の階層でデータのレプリケーションを行うのでパフォーマンスの低下が少ないことです。

note: E.g. 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
ja: リソースの自動プロモーション

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.
ja: DRBD9以前は、リソースを昇格するときには `drbdadm primary` コマンドを使用しました。DRBD9では、 `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.
ja: 自動プロモーションは、それが可能なクラスタ状態の時にのみ成功します。(つまり `drbdadm primary` コマンドの実行が成功する場合)そうでなければ、DRBD9以前と同様にマウントやデバイスのオープンは行えません。

note: type: Title ===
en: Multiple replication transports
ja: 複数の転送プロトコル

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.
ja: DRBDは複数のネットワークプロトコルに対応しています。現在、TCPとRDMAの2つのトランスポートに対応しています。各トランスポートの実装はOSのカーネルモジュールを使用しています。

note: type: Title ====
en: TCP Transport
ja: 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.
ja: DRBDのパッケージファイルには `drbd_trasport_tcp.ko` が含まれ、これによって実装されています。 その名の通り、TCP/IPプロトコルを使ってマシン間のデータ転送を行います。

note: type: Plain text
en: DRBD's replication and synchronization framework socket layer supports multiple low-level transports:
ja: DRBDのレプリケーションおよび同期フレームワークのソケットレイヤーは複数のトランスポートプロトコルに対応しています。

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.
ja: 標準的かつDRBDのデフォルトのプロトコルです。IPv4が有効なすべてのシステムで利用できます。

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.
ja: レプリケーションと同期用のTCPソケットの設定においては、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.
ja: SDPは、InfiniBandなどのRDMAに対応するBSD形式ソケットです。SDPは多くのディストリビューションでOFEDスタックの一部として利用されていましたが、現在は *非推奨* です。SDPはIPv4形式のアドレシングに使用しますインフィニバンドを内部接続に利用すると、SDPによる高スループット、低レイテンシの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.
ja: スーパーソケットはTCP/IPスタック部分と置き換え可能なソケット実装で、モノリシック、高効率、RDMA対応などの特徴を持っています。きわめてレイテンシが低いレプリケーションを実現できるプロトコルとして、DRBDはSuperSocketsをサポートしています。現在のところ、SuperSocketsはDolphin Interconnect Solutionsが販売するハードウェアの上でのみ利用できます。

note: type: Title ====
en: RDMA Transport
ja: RDMAトランスポート

note: type: Plain text
en: Alternatively the `drbd_transport_rdma.ko` kernel module is available
ja: LINBIT の `drbd_transport_rdma.ko` カーネルモジュールを使用する事もできます

note: type: Plain text
en: from LINBIT
ja: 。

note: type: Plain text
en: .  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.
ja: このトランスポートはverbs/RDMA APIを使ってInfiniBand HCAsやiWARPが使えるNIC、またはRoCEが使えるNICでデータ転送をします。TCP/IPで使用するBSDソケットAPIと比較して、verbs/RDMA APIでは非常に低いCPU負荷でデータ転送が行えます。

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.
ja: 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.
ja: 転送プロトコルはリソースのコネクションごとに設定することができます。詳細は<<s-configuring-transports>>を参照ください。

note: type: Title ===
en: Multiple paths
ja: 複数の path

note: type: Plain text
en: DRBD allows configuring multiple paths per connection. The TCP transport uses only one path at a time for a connection. The RDMA transport is capable of balancing the network traffic over multiple paths of a single connection. see <<s-configuring-multiple-paths>> for more details.
ja: DRBD は、connection ごとに複数の path を構成できます。TCP トランスポートは、connection ごとに 1 つの path のみを使用します。RDMA トランスポートは、1 つの connection で複数の path を用いて、ネットワークトラフィックのバランスをとることができます。詳細は <<s-configuring-multiple-paths>> を参照ください。

note: type: Title ===
en: Efficient synchronization
ja: 効率的なデータ同期

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.
ja: 同期ならびに再同期は、レプリケーションとは区別されます。レプリケーションは、プライマリノードでのデータの書き込みに伴って実施されますが、同期はこれとは無関係です。同期はデバイス全体の状態に関わる機能です。

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:
ja: プライマリノードのダウン、セカンダリノードのダウン、レプリケーション用ネットワークのリンク中断など、さまざまな理由によりレプリケーションが一時中断した場合、同期が必要になります。DRBDの同期は、もともとの書き込み順序ではなくリニアに書き込むロジックを採用しているため、効率的です。

note: type: Plain text
en: Synchronization is fast, since blocks in which several successive write operations occurred are only synchronized once.
ja: 何度も書き込みが行われたブロックの場合でも、同期は1回の書き込みですみます。このため、同期は高速です。

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.
ja: ディスク上のブロックレイアウトを考慮して、わずかなシークですむよう、同期は最適化されています。

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_.
ja: 同期実行中は、スタンバイノードの一部のデータブロックの内容は古く、残りは最新の状態に更新されています。この状態のデータは _inconsistent_ (不一致)と呼びます。

note: type: Plain text
en: The service continues to run uninterrupted on the active node, while background synchronization is in progress.
ja: DRBDでは、同期はバックグラウンドで実行されるので、アクティブノードのサービスは同期によって中断されることはありません。

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.
ja: 重要:データに不一致箇所が残っているノードは、多くの場合サービスに利用できません。このため、不一致である時間を可能な限り短縮することが求められます。そのため、DRBDは同期直前のLVMスナップショットを自動で作成するLVM統合機能を実装しています。これは同期中であっても対向ノードと_consistent_(一致する)一致するコピーを保証します。この機能の詳細については<<s-lvm-snapshots>>をご参照ください。

note: type: Title ====
en: Variable-rate synchronization
ja: 可変レート同期

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.
ja: 可変レート同期(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.
ja: 可変レート同期に関する設定の詳細については、<<s-configure-sync-rate-variable>>を参照してください。

note: type: Title ====
en: Fixed-rate synchronization
ja: 固定レート同期

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:
ja: 固定レート同期の場合、同期ホストに対して送信される1秒あたりのデータ量(_同期速度_)には設定可能な静的な上限があります。この上限に基づき、同期に必要な時間は、次の簡単な式で予測できます。

note: type: Block title
en: Synchronization time
ja: 同期時間

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.
ja: _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.
ja: 固定レート同期に関する設定の詳細については<<s-configure-sync-rate>>を参照してください。

note: type: Title ====
en: Checksum-based synchronization
ja: チェックサムベース同期

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.
ja: DRBDの同期アルゴリズムは、データダイジェスト(チェックサム)を使うことによりさらに効率化されています。チェックサムベースの同期を行うことで、より効率的に同期対象ブロックの書き換えが行われます。DRBDは同期を行う前にブロックを_読み込み_ディスク上のコンテンツのハッシュを計算します。このハッシュと、相手ノードの同じセクタのハッシュを比較して、値が同じであれば、そのブロックを同期での書き換え対象から外します。これにより、DRBDが切断モードから復旧し再同期するときなど、同期時間が劇的に削減されます。

note: type: Plain text
en: See <<s-configure-checksum-sync>> for configuration suggestions with regard to synchronization.
ja: 同期に関する設定の詳細は<<s-configure-checksum-sync>>をご参照ください。

note: type: Title ===
en: Suspended replication
ja: レプリケーションの中断

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.
ja: DRBDが正しく設定されていれば、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.
ja: レプリケーションの中断は、データセンタやクラウドインスタンス間との共有接続で遠隔地レプリケーションを行うような、可変帯域幅での接続の場合に通常利用されます。

note: type: Plain text
en: See <<s-configure-congestion-policy>> for details on congestion policies and suspended replication.
ja: 輻輳のポリシーとレプリケーションの停止についてほ詳細は<<s-configure-congestion-policy>>をご参照ください。

note: type: Title ===
en: On-line device verification
ja: オンライン照合

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.
ja: オンライン照合機能を使うと、2ノードのデータの整合性を、ブロックごとに効率的な方法で確認できます。

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.
ja: ここで _効率的_ というのはネットワーク帯域幅を効率的に利用することを意味しています。照合によって冗長性が損なわれることはありません。しかしオンライン照合は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.
ja: 一方のノード( _照合ソース_ )で、低レベルストレージデバイスのブロックごとのダイジェストを計算します。DRBDはダイジェストを他方のノード( _照合ターゲット_ )に転送し、そこでローカルの対応するブロックのダイジェストと照合します。ダイジェストが一致しないブロックはout-of-syncとマークされ、後で同期が行われます。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.
ja: このプロセスは、照合対象の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.
ja: オンライン照合は、週または月に1回程度の頻度でcronデーモンから実行するのが妥当です。オンライン照合機能を有効にして実行する方法や、これを自動化する方法については、<<s-use-online-verify>>をご参照ください。

note: type: Title ===
en: Replication traffic integrity checking
ja: レプリケーション用トラフィックの整合性チェック

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.
ja: DRBDは、MD5、SHA-1またはCRD-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.
ja: DRBD自身はメッセージダイジェストアルゴリズムは *備えていません* 。Linuxカーネルの暗号APIが提供する機能を単に利用するだけです。したがって、カーネルが備えるアルゴリズムであれば、どのようなものでも利用可能です。

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:
ja: 本機能を有効にすると、レプリケート対象のすべてのデータブロックごとのメッセージダイジェストが計算されます。レプリケート先のDRBDは、レプリケーション用パケットの照合にこのメッセージダイジェストを活用します。 データの照合が失敗したら、レプリケート先の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);
ja: 送信側ノードのメインメモリとネットワークインタフェースの間で生じたビット単位エラー(ビット反転)。 この種のエラーは、多くのシステムにおいて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);
ja: 受信側ノードのネットワークインタフェースとメインメモリの間で生じたビット反転。 TCPチェックサムが役に立たないのは前項と同じです。

note: type: Plain text
en: Any form of corruption due to a race conditions or bugs in network interface firmware or drivers;
ja: 何らかのリソース競合やネットワークインタフェースまたはそのドライバのバグなどによって生じたデータの損傷。

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).
ja: ノード間のネットワークコンポーネントが再編成されるときなどに生じるビット反転やデータ損傷。 このエラーの可能性は、ノード間をネットワークケーブルで直結しなかった場合に考慮する必要があります。

note: type: Plain text
en: See <<s-configure-integrity-check>> for information on how to enable replication traffic integrity checking.
ja: レプリケーショントラフィックの整合性チェックを有効にする方法については、<<s-configure-integrity-check>>をご参照ください。

note: type: Title ===
en: Split brain notification and automatic recovery
ja: スプリットブレインの通知と自動修復

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.
ja: クラスタノード間のすべての通信が一時的に中断され、クラスタ管理ソフトウェアまたは人為的な操作ミスによって両方のノードが `プライマリ` になった場合に、スプリットブレインの状態に陥ります。それぞれのノードでデータの書き換えが行われることが可能になってしまうため、この状態はきわめて危険です。つまり、2つの分岐したデータセットが作られてしまう軽視できない状況に陥る可能性が高くなります。

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 Pacemaker. To avoid confusion, this guide uses the following convention:
ja: クラスタのスプリットブレインは、Pacemaker などが管理するホスト間の通信がすべて途絶えたときに生じます。これとDRBDのスプリットブレインは区別して考える必要があります。このため、本書では次のような記載方法を使うことにします。

note: type: Plain text
en: _Split brain_ refers to DRBD split brain as described in the paragraph above.
ja: _スプリットブレイン_ は、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.
ja: クラスタノード間のすべての通信の断絶のことを _クラスタ・パーティション_ と表記します。

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.
ja: スプリットブレインに陥ったことを検出すると、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:
ja: スプリットブレインへの望ましい対処方法は、<<s-resolve-split-brain,手動回復>> を実施した後、根本原因を取り除くことです。しかし、ときにはこのプロセスを自動化する方がいい場合もあります。自動化のために、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_.
ja: *「若い」プライマリ側の変更を切り捨てる方法* ネットワークの接続が回復してスプリットブレインを検出すると、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_.
ja: *「古い」プライマリ側の変更を切り捨てる方法* 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.
ja: *変更が少ないプライマリ側の変更を切り捨てる方法* DRBDは2つのノードでどちらが変更が少ないかを調べて、少ない方のノードの _すべて_ を切り捨てます。

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.
ja: *片ノードに変更がなかった場合の正常回復* もし片ノードにスプリットブレインの間にまったく変更がなかった場合、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.
ja: 自動修復機能を使うべきかどうかの判断は、個々のアプリケーションに強く依存します。データベースをレプリケーションしている場合を例とすると、変更量が少ないノードのデータを切り捨てるアプローチは、ある種の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.
ja: DRBDのスプリットブレイン自動修復機能を設定する方法については、<<s-automatic-split-brain-recovery-configuration>>を参照してください。

note: type: Title ===
en: Support for disk flushes
ja: ディスクフラッシュのサポート

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.
ja: ローカルディスクや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.
ja: この影響を緩和するために、DRBDはディスクフラッシュを活用します。ディスクフラッシュは書き込みオペレーションのひとつで、対象のデータが安定した(不揮発性の)ストレージに書き込まれるまで完了しません。すなわち、キャッシュへの書き込みではなくディスクへの書き込みを保証します。DRBDは、レプリケートするデータとそのメタデータをディスクに書き込むときに、フラッシュ命令を発行します。実際には、DRBDは<<s-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).
ja: しかしDRBDがディスクフラッシュを活用できるのは、直下のディスクデバイスがこの機能をサポートしている場合に限られることに注意してください。最近のカーネルは、ほとんどのSCSIおよびSATAデバイスに対するフラッシュをサポートしています。LinuxソフトウェアRAID (md)は、直下のデバイスがサポートする場合に限り、RAID-1に対してフラッシュをサポートします。デバイスマッパ(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.
ja: 電池でバックアップされた書き込みキャッシュ(BBWC)は、電池からの給電による不揮発性ストレージです。このようなデバイスは、電源障害から回復したときに中断していたディスクへの書き込みをディスクにフラッシュできます。このため、キャッシュへの書き込みは、事実上安定したストレージへの書き込みと同等とみなせます。この種のデバイスが使える場合、DRBDの書き込みパフォーマンスを向上させるためにフラッシュを無効に設定するのがよいかもしれません。詳細は<<s-disable-flushes>>をご参照ください。

note: type: Title ===
en: Trim/Discard support
ja: 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].
ja: _Trim_ と _Discard_ は、ある範囲のデータ領域が既に使用済みで不要になってfootnote:[削除したファイルのデータなど]、他のデータ領域として再利用してよいことをストレージに伝えるコマンドで、どちらも同じ意味を持ちます。これらは、フラッシュストレージで使用されている機能です。フラッシュストレージ(SSD、FusionIOカードなど)では上書きが困難であり、通常は消去してから新しいデータを書き込む必要があります(これにより多少のレイテンシが発生します)。詳細は 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.
ja: DRBDは8.4.3から _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.
ja: その効果の例をあげると、大部分または全てのストレージ領域が無効になったとDRBDに伝えることで(DRBDはこれをすべての接続しているノードにリレーします）、比較的最近のmkfs.ext4であれば、初期同期時間を数TBのボリュームでも数秒から数分ほどに短縮することができます。

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.
ja: その後そのノードに接続する後続のリソースは _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.
ja: ストレージ自体が _Trim_/_Discard_ をサポートしていなくても、LVMのシンプロビジョニングボリュームなどの仮想ブロックデバイスでも同様の機能を提供しています。

note: type: Title ===
en: Disk error handling strategies
ja: ディスクエラー処理ストラテジー

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.
ja: どちらかのノードのDRBD下位ブロックデバイスがI/Oエラーを返したときに、DRBDがそのエラーを上位レイヤ(多くの場合ファイルシステム)に伝えるかどうかを制御できます。

note: type: Block title
en: Passing on I/O errors
ja: 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.
ja: pass_onを設定すると、下位レベルのエラーをDRBDはそのまま上位レイヤに伝えます。したがって、そのようなエラーへの対応(ファイルシステムをリードオンリーでマウントしなおすなど)は上位レイヤに任されます。このモードはサービスの継続性を損ねることがあるので、多くの場合推奨できない設定だといえます。

note: type: Block title
en: Masking I/O errors
ja: 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.
ja: _detach_ を設定すると、最初の下位レイヤでの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.
ja: I/Oエラー処理方針を設定する方法については<<s-configure-io-error-behavior>>を参照してください。

note: type: Title ===
en: Strategies for dealing with outdated data
ja: 無効データの処理ストラテジー

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.
ja: DRBDはデータの _inconsistent(不整合状態)_ と _outdated(無効状態)_ を区別します。不整合とは、いかなる方法でもアクセスできずしたがって利用できないデータ状態です。たとえば、進行中の同期先のデータが不整合データの例です。この場合、ノードのデータは部分的に古く、部分的に新しくなっており、ノード間の同期は不可能になります。下位デバイスの中にファイルシステムが入っていたら、このファイルシステムは、マウントはもちろんチェックも実行できません。

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.
ja: 無効データは、セカンダリノード上のデータで、整合状態にあるもののプライマリ側と同期していない状態のデータをさします。一時的か永続的かを問わず、レプリケーションリンクが途切れたときに、この状態が生じます。リンクが切れている状態でのセカンダリ側の無効データは、クリーンではあるものの、対向ノードのデータ更新が反映されず古いデータ状態になっている可能性があります。サービスが無効データを使ってしまうことを防止するために、DRBDは無効データを<<s-resource-roles,プライマリに切り替える>>ことを許可しません。

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.
ja: DRBDにはネットワークの中断時にセカンダリノードのデータを無効に設定するためのインタフェースがあります。DRBDは無効データをアプリケーションが使ってしまうことを防止するために、このノードがプライマリになることを拒絶します。

note: type: Plain text
en: 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.
ja: 本機能の完全は実装は、DRBDレプリケーションリンクから独立した通信経路を使用する<<ch-pacemaker,Pacemakerクラスタ管理フレームワーク>>用になされていますが、しかしこのAPIは汎用的なので、他のクラスタ管理アプリケーションでも容易に本機能を利用できます。

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.
ja: レプリケーションリンクが復活すると、無効に設定されたリソースの無効フラグは自動的にクリアされます。そして<<s-resync,バックグラウンド同期>>が実行されます。

note: type: Title ===
en: Three-way replication via stacking
ja: 3ノードレプリケーション

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.
ja: この機能は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.
ja: 3ノードレプリケーションとは、2ノードクラスタに3番目のノードを追加してDRBDでレプリケーションするものです。この方法は、バックアップやディザスタリカバリのために使われます。

note: type: Plain text
en: This type of configuration generally involves <<s-drbd-proxy>>.
ja: このタイプの構成では一般的に <<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:
ja: 3ノードレプリケーション既存のDRBDリソースの上にもうひとつのDRBDリソースを _スタック(積み重ね)_ することによって実現されます。次の図を参照してください。

note: type: Block title
en: DRBD resource stacking
ja: 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).
ja: 下位リソースのレプリケーションには同期モード(DRBDプロトコルC)を使いますが、上位リソースは非同期レプリケーション(DRBDプロトコルA)で動作させます。

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.
ja: 3ノードレプリケーションは、常時実行することも、オンデマンドで実行することもできます。常時レプリケーションでは、クラスタ側のデータが更新されると、ただちに3番目のノードにもレプリケートされます。オンデマンドレプリケーションでは、クラスタシステムとバックアップサイトの通信はふだんは停止しておき、cronなどによって定期的に夜間などに同期をはかります。

note: type: Title ===
en: Long-distance replication via DRBD Proxy
ja: DRBD Proxyによる遠距離レプリケーション

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.
ja: DRBDの<<s-replication-protocols,プロトコル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.
ja: 平均的な書き込み帯域幅は、利用可能なネットワークの帯域幅によって制約されます。ソケットの出力バッファに収まるデータ量までのバースト的な書き込みは、問題なく処理されます。

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.
ja: オプション製品のDRBD Proxyのバッファリング機構を使って、この制約を緩和できます。DRBDプライマリノードからの書き込みデータは、DRBD Proxyのバッファに格納されます。DRBD Proxyのバッファサイズは、アドレス可能空間や搭載メモリの範囲内で自由に設定できます

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.
ja: データ圧縮を行うように設定することも可能です。圧縮と伸長(解凍)は、応答時間をわずかに増やしてしまいます。しかしネットワークの帯域幅が制約要因になっているのなら、転送時間の短縮効果は、圧縮と伸長(解凍)によるオーバヘッドを打ち消します。

note: type: Plain text
en: Compression and decompression were implemented with multi core SMP systems in mind, and can utilize multiple CPU cores.
ja: 圧縮伸長(解凍)機能は複数CPUによる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.
ja: 多くの場合、ブロックI/Oデータの圧縮率は高く、帯域幅の利用効率は向上します。このため、DRBD Proxyを使うことによって、DRBDプロトコルBまたはCを使うことも現実的なものとなります。

note: type: Plain text
en: See <<s-using-drbd-proxy>> for information on configuring DRBD Proxy.
ja: 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.
ja: DRBD ProxyはオープンソースライセンスによらないDRBDプロダクトファミリの製品になります。評価や購入については linbit@sios.com へご連絡ください。

note: type: Title ===
en: Truck based replication
ja: トラック輸送によるレプリケーション

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
ja: トラック輸送(またはディスク輸送)によるレプリケーションは、ストレージメディアを遠隔サイトに物理的に輸送することによるレプリケーションです。以下の制約がある場合に、この方法はとくに有効です。

note: type: Plain text
en: the total amount of data to be replicated is fairly large (more than a few hundreds of gigabytes);
ja: 合計のレプリケート対象データ領域がかなり大きい(数百GB以上)

note: type: Plain text
en: the expected rate of change of the data to be replicated is less than enormous;
ja: 予想されるレプリケートするデータの変更レートがあまり大きくない

note: type: Plain text
en: the available network bandwidth between sites is limited.
ja: 利用可能なサイト間のネットワーク帯域幅が限られている

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.
ja: このような状況にある場合、トラック輸送を使わなければ、きわめて長期間(数日から数週間またはそれ以上)の初期同期が必要になってしまいます。トラック輸送でデータを遠隔サイトに輸送する場合、初期同期時間を劇的に短縮できます。詳細は<<s-using-truck-based-replication>>を参照ください。

note: type: Title ===
en: Floating peers
ja: 動的対向ノード

note: type: Plain text
en: This feature is available in DRBD versions 8.3.2 and above.
ja: この記述方法は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.
ja: DRBDのやや特殊な使用方法に _動的対向ノード_ があります。動的対向ノードを設定すると、DRBDの対向同士は(通常設定の)特定のホスト名を持つノードには接続せず、いくつかのホスト間を動的に選択して接続するする事ができます。この設定において、DRBDは対向ノードをホスト名ではなくIPアドレスで識別します。

note: type: Plain text
en: For more information about managing floating peer configurations, see <<s-pacemaker-floating-peers>>.
ja: 動的対向ノードの設定については<<s-pacemaker-floating-peers>>を参照ください。

note: type: Title ===
en: Data rebalancing (horizontal storage scaling)
ja: データ再配置(ストレージの水平スケール)

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.
ja: 例えば、会社のポリシーで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.
ja: しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、１つのノードだけを追加をしてデータを _再配置_ することができます。

note: type: Block title
en: DRBD data rebalancing
ja: 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.
ja: 上の図では、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.
ja: これらはDRBD9ではオンラインで行うことができます。実際の手順については<<s-rebalance-workflow>>ご覧ください。

note: type: Title ===
en: DRBD client
ja: 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_.
ja: 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.
ja: 基本的にDRBD _バックエンド_ は3〜4、またはそれ以上(冗長化の要件に応じて)で構成できます。しかしDRBD9はそれ以上でも接続することができます。なお1つのビットマップslotfootnote:[後に最適化によって除去される可能性があります。DRBD 9.0.0でもありえるかもしれません。]が _ディスクレスプライマリ_ ( _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.
ja: プライマリの _DRBDクライアント_ で実行されるすべての書き込み要求は、ストレージを備えたすべてのノードに送られます。読み込み要求は、サーバーノードの1つにのみ送られます。 _DRBDクライアント_ は、使用可能なすべてのサーバーノードに均等に読み読み要求を送ります。

note: type: Plain text
en: See <<s-permanently-diskless-nodes>> for more information.
ja: 詳細は <<s-permanently-diskless-nodes>> を参照ください。

note: type: Title ===
en: Quorum
ja: クォーラム

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.
ja: スプリットブレインまたは複製データの分離を回避するためには、フェンシングを構成する必要があります。しかし、ノードのフェンシングは実際の配備であまり人気がありません。これは計画や配備でミスが発生しやすいからです。

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 cluster manager level fencing.
ja: データセットに３つの複製をもつことで、Pacemakerレベルのフェンシングに変わってDRBDのクォーラム実装を使用することができます。

note: type: Plain text
en: Pacemaker gets informed about quorum or loss-of-quorum via the master score of the resource.
ja: Pacemakerはリソースのマスタースコアを通してクォーラムまたはクォーラム喪失の通知を受け取ります。

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.
ja: DRBDのクォーラムはあらゆる種類のLinuxベースのサービスで使用できます。IOエラーによりサービスが終了する瞬間など、クォーラム喪失の動作はとてもよくできています。IOエラーでサービスが終了しないときは、クォーラム喪失したプライマリノードをリブートするようシステもを構成する必要があります。

note: type: Plain text
en: See <<s-configuring-quorum>> for more information.
ja: 詳細は <<s-configuring-quorum>> を参照ください。

note: type: Title ====
en: Tiebreaker
ja: タイブレーカー

note: type: delimited block =
en: The quorum tiebreaker feature is available in DRBD versions 9.0.18 and above.
ja: クォーラムタイブレーカー機能は、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.
ja: 2つのノードクラスタの基本的な問題は、それらが接続性を失うと同時に2つのパーティションを持ち、それらのどちらもクォーラムを持たず、その結果クラスタサービスが停止することです。この問題は、クォーラムタイブレーカーとして機能する3つ目のディスクレスノードをクラスターに追加することで軽減できます。

note: type: Plain text
en: See <<s-configuring-quorum-tiebreaker>> for more information.
ja: 詳細は <<s-configuring-quorum-tiebreaker>> を参照ください。

note: type: Title ===
en: DRBD integration for VCS
ja: DRBDとVCSの統合

note: type: Plain text
en: Veritas Cluster Server (or Veritas Infoscale Availability) 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.
ja: Veritas Cluster Server (or Veritas Infoscale Availabilty) はオープンソースであるPacemakerの代替となる商用製品です。DRBDリソースをVSCセットアップとともに使用する場合は github の https://github.com/LINBIT/drbd-utils/tree/master/scripts/VCS[drbd-utils/scripts/VCS] の README を参照ください。
