en to ja translation catalogue (47 entries)

note: type: Title ==
en: Optimizing DRBD latency
ja: DRBDレイテンシの最適化

note: type: Plain text
en: This chapter deals with optimizing DRBD latency. It examines some hardware considerations with regard to latency minimization, and details tuning recommendations for that purpose.
ja: この章では、DRBDのレイテンシの最適化について説明します。レイテンシを最小にするためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。

note: type: Title ===
en: Hardware considerations
ja: ハードウェアの検討事項

note: type: Plain text
en: DRBD latency is affected by both the latency of the underlying I/O subsystem (disks, controllers, and corresponding caches), and the latency of the replication network.
ja: DRBDのレイテンシは、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)のレイテンシとレプリケーションネットワークのレイテンシの両方の影響を受けます。

note: type: Block title
en: I/O subsystem latency
ja: I/Oサブシステムのレイテンシ

note: type: Plain text
en: indexterm:[latency]For _rotating media_ the I/O subsystem latency is primarily a function of disk rotation speed. Thus, using fast-spinning disks is a valid approach for reducing I/O subsystem latency.
ja: indexterm:[latency]HDDなど _回転するメディア_ の場合、I/Oサブシステムのレイテンシには、主としてディスクの回転速度が影響します。したがって、高速回転のディスクを使用すればI/Oサブシステムのレイテンシが短縮します。

note: type: Plain text
en: For _solid state media_ (like SSDs) the Flash storage controller is the determining factor; the next most important thing is the amount of unused capacity. Using DRBD's <<s-trim-discard>> will help you provide the controller with the needed information which blocks it can recycle. That way, when a write requests comes in, it can use a block that got cleaned ahead-of-time and doesn't have to wait *now* until there's space availablefootnote:[On low-end hardware you can help that a bit by reserving some space - just keep 10% to 20% of the total space unpartitioned.].
ja: SSDなど _回転しないメディア_ の場合は、フラッシュストレージのコントローラが重要な要素です。次に重要なのは未使用容量です。DRBDの<<s-trim-discard>>を使用すると、コントローラーにどのブロックがリサイクル可能かについて必要な情報を渡すことができます。そのため書き込み要求があった時に、事前に使用可能になっているブロックを `すぐ` に使用する事ができ、書き込めるスペースが空くまで待つ必要がありません。footnote:[ローエンドのハードウェアの場合は、10~20%のスペースを未使用のままにしておくと、多少スペースの節約になります。]

note: type: Plain text
en: Likewise, the use of a indexterm:[battery-backed write cache] indexterm:[BBU] battery-backed write cache (BBWC) reduces write completion times, also reducing write latency. Most reasonable storage subsystems come with some form of battery-backed cache, and allow the administrator to configure which portion of this cache is used for read and write operations. The recommended approach is to disable the disk read cache completely and use all available cache memory for the disk write cache.
ja: indexterm:[BBU] 同様に、indexterm:[battery-backed write cache]BBWC (Battery-Backed Write Cache)を使用すると、書き込み完了までの時間が短くなり、書き込みのレイテンシを短縮できます。手頃な価格のストレージサブシステムの多くは何らかのバッテリバックアップキャッシュを備えており、管理者がキャッシュのどの部分を読み書き操作に使用するか設定できます。ディスク読み取りキャッシュを完全に無効にし、すべてのキャッシュメモリをディスク書き込みキャッシュとして使用する方法をお勧めします。

note: type: Block title
en: Network latency
ja: ネットワークレイテンシ

note: type: Plain text
en: indexterm:[latency]Network latency is, in essence, the packet indexterm:[round-trip-time]indexterm:[RTT] round-trip time (RTT) between hosts. It is influenced by a number of factors, most of which are irrelevant on the dedicated, back-to-back network connections recommended for use as DRBD replication links. Thus, it is sufficient to accept that a certain amount of latency always exists in network links, which typically is on the order of 100 to 200 microseconds (μs) packet RTT for Gigabit Ethernet.
ja: indexterm:[latency]ネットワークレイテンシは、基本的にはホスト間のindexterm:[round-trip-time]indexterm:[RTT] round-trip time (RTT)RTT (Packet Round-Trip Time)です。 これ以外にもいくつかの要因がありますが、そのほとんどは、DRBDレプリケーションリンクとして推奨する、DRBD専用回線接続の場合は問題になりません。イーサネットリンクには常に一定のレイテンシが発生しますが、ギガビットイーサネットでは通常、100〜200マイクロ秒程度のパケット往復時間です。

note: type: Plain text
en: Network latency may typically be pushed below this limit only by using lower-latency network protocols, such as running DRBD over Dolphin Express using Dolphin SuperSockets, or a 10GBe direct connection; these are typically in the 50µs range. Even better is InfiniBand, which provides even lower latency.
ja: ネットワークレイテンシをこれより短くするには、レイテンシが短いネットワークプロトコルを利用する以外ありません。たとえば、Dolphin SuperSocketsのDolphin Express、10GBeの直結などを介してDRBDを実行します。これらの場合にはおよそ50マイクロ秒程になります。InfiniBandを利用するとさらにレイテンシが小さくなります。

note: type: Title ===
en: Latency overhead expectations
ja: レイテンシオーバーヘッドの予測値

note: type: Plain text
en: As for throughput, when estimating the latency overhead associated with DRBD, there are some important natural limitations to consider:
ja: スループットに関して、DRBDに関連するレイテンシオーバヘッドを見積もる際には、必ず次の制限を考慮してください。

note: type: Plain text
en: DRBD latency is bound by that of the raw I/O subsystem.
ja: DRBDのレイテンシは下位I/Oサブシステムのレイテンシにより制限される。

note: type: Plain text
en: DRBD latency is bound by the available network latency.
ja: DRBDのレイテンシは使用可能なネットワークレイテンシにより制限される。

note: type: Plain text
en: The _sum_ of the two establishes the theoretical latency _minimum_ incurred to DRBDfootnote:[for protocol C, because the other node(s) have to write to stable storage, too]. DRBD then adds to that latency a slight additional latency overhead, which can be expected to be less than 1 percent.
ja: DRBDの理論上の _最小_ 待ち時間は、上記2つの _合計_ です。footnote:[プロトコルCの場合。他ノードも同様に書き込まなくてはならないため]。さらにわずかなオーバヘッドが追加されますが、これは1%未満だと予測されます。

note: type: Plain text
en: Consider the example of a local disk subsystem with a write latency of 3ms and a network link with one of 0.2ms. Then the expected DRBD latency would be 3.2 ms or a roughly 7-percent latency increase over just writing to a local disk.
ja: たとえば、ローカルディスクサブシステムの書き込みレイテンシが3msで、 ネットワークリンクのレイテンシが0.2msだとします予測されるDRBDの レイテンシは3.2msで、 ローカルディスクに書き込むだけのときと比べて約7%レイテンシが増加することになります。

note: type: Plain text
en: Latency may be influenced by a number of other factors, including CPU cache misses, context switches, and others.
ja: CPUのキャッシュミス、コンテキストスイッチなど、他にも待ち時間に影響する要因があります。

note: type: Title ===
en: Latency vs. IOPs
ja: レイテンシ vs. IOPs

note: type: Plain text
en: indexterm:[latency]indexterm:[IOPs]_IOPs_ is the abbreviation of "__I/O operations per second__".
ja: indexterm:[latency]indexterm:[IOPs] _IOPs_ は "I/O operations per second" の略です。

note: type: Plain text
en: Marketing typically doesn't like numbers that get smaller; press releases aren't written with "__Latency reduced by 10µs, from 50µs to 40µs now!__" in mind, they like "__Performance increased by 25%, from 20000 to now 25000 IOPs__" much more. Therefore IOPs were invented - to get a number that says "higher is better".
ja: 一般的にマーケティングでは数字が小さくなったとは書かないものです。プレスリリースでは "レイテンシが10マイクロ秒小さくなって、50マイクロ秒から40秒になりました!" とは書かずに、 "パフォーマンスが25%向上し、20000から25000IPOsになりました!" と書きます。"大きいものは良い" のような事を言うためIOPsは作られました。

note: type: Plain text
en: So, in other words, IOPs are the reciprocal of latency. What you'll have to keep in mind is that the method given in <<s-measure-latency>> gives you the latency resp. the number of IOPs for a purely sequential, single-threaded IO load, while most other documentation will give numbers for some highly parallel loadfootnote:[Like in "__16 threads, IO-depth of 32__" - this means that 512 I/O-requests are being done in parallel!], because this gives much "prettier" numbers. With that kind of trick DRBD does offer you 100000 IOPs, too!
ja: 言い方を換えれば、IOPsとレイテンシは相互的なものです。<<s-measure-latency>>で書いた方法は、純粋にシーケンシャルのシングルスレッドのIOロードのIOPsごとのレイテンシです。一方で、よくある他のドキュメントでは、見栄えのいい数字を出すために多重並行処理でのIOPsを使用しているfootnote:[例えば"16スレッドでIO-depthが32"これは512のI/O要求が並行して行われたという事です。]という事を覚えておいてください。こういったトリックを使うのなら、どんなIOPsにでもできます。

note: type: Plain text
en: So, please don't shy away from measuring serialized, single-threaded latency.  If you want lots of IOPS, run the `fio` utility with `threads=8` and an `iodepth=16`, or some similar settings... But please keep in mind that these number will not have any meaning to your setup, unless you're driving a database with many tens or hundreds of client connections active at the same time.
ja: そのため、シリアルのシングルスレッドでのレイテンシを敬遠しないでください。 もっとIOPsが欲しい場合には `fio` を `threads=8` で `iodepth=16` にするなどの設定をしてください。しかし、そうした数字はデータベースに多数のクライアントからのコネクションが同時にあった場合など以外には、意味がないという事を覚えておいてください。

note: type: Title ===
en: Tuning recommendations
ja: チューニングの推奨事項

note: type: Title ====
en: Setting DRBD's CPU mask
ja: CPUマスクの設定

note: type: Plain text
en: DRBD allows for setting an explicit CPU mask for its kernel threads. This is particularly beneficial for applications which would otherwise compete with DRBD for CPU cycles.
ja: DRBDでは、カーネルスレッドの明示的なCPUマスクを設定できます。これは、CPUサイクルがDRBDと競合するアプリケーションの場合に特に役立ちます。

note: type: Plain text
en: The CPU mask is a number in whose binary representation the least significant bit represents the first CPU, the second-least significant bit the second, and so forth. A set bit in the bitmask implies that the corresponding CPU may be used by DRBD, whereas a cleared bit means it must not. Thus, for example, a CPU mask of 1 (`00000001`) means DRBD may use the first CPU only. A mask of 12 (`00001100`) implies DRBD may use the third and fourth CPU.
ja: CPUマスクは数字で、バイナリ表現の最下位ビットが第1のCPUを表し、その次のビットが第2のCPUを表します。ビットマスクの設定ビットは、対応するCPUがDRBDによって使用されていることを示し、クリアされたビットは使用されていないことを示します。たとえば、CPUマスク1( `00000001` )は、DRBDが第1のCPUだけを使用することを示します。マスク12( `00001100` )はDRBDが第3と第4のCPUを使用することを示します。

note: type: Plain text
en: An example CPU mask configuration for a resource may look like this:
ja: 次に、リソースのCPUマスク設定の例を示します。

note: type: Plain text
en: Of course, in order to minimize CPU competition between DRBD and the application using it, you need to configure your application to use only those CPUs which DRBD does not use.
ja: DRBDとこれを使用するアプリケーションとのCPU競合を最小限に抑えるためには、もちろん、DRBDが使用していないCPUだけをアプリケーションが使用するように設定する必要があります。

note: type: Plain text
en: Some applications may provide for this via an entry in a configuration file, just like DRBD itself. Others include an invocation of the `taskset` command in an application init script.
ja: 一部のアプリケーションは、DRBD自体と同様に設定ファイルでこの設定を行うことができます。アプリケーションによっては、initスクリプトで `taskset` コマンドを呼び出す必要があります。

note: type: delimited block =
en: It makes sense to keep the DRBD threads running on the same L2/L3 caches.
ja: 複数のDRBDスレッドに同一のL2/L3キャッシュを使わせることは意味があります。

note: type: delimited block =
en: But: the numbering of CPUs doesn't have to correlate with the physical partitioning.  You can try the `lstopo` (or `hwloc-ls`) program for X11 or `hwloc-info -v -p` for console output to get an overview of the topology.
ja: しかし、CPU番号の物理パーティショニングとの関連付けは必要ありません。 X11環境では `lstopo` (または `hwloc-ls` )プログラムを、コンソールでは `hwloc-info -v -p` を使うとトポロジーの概要を確認することができます。

note: type: Title ====
en: Modifying the network MTU
ja: ネットワークMTUの変更

note: type: Plain text
en: It may be beneficial to change the replication network's maximum transmission unit (MTU) size to a value higher than the default of 1500 bytes. Colloquially, this is referred to as indexterm:[Jumbo frames] "enabling Jumbo frames".
ja: レプリケーションネットワークの最大転送ユニット(MTU)サイズをデフォルトの1500バイトよりも大きくすることにはメリットがあります。いわゆるindexterm:[Jumbo frames] "ジャンボフレームを使用する" ことです。

note: type: Plain text
en: The MTU may be changed using the following commands:
ja: MTUは、次のコマンドを使用して変更できます。

note: type: Plain text
en: or
ja: または

note: type: Plain text
en: _<interface>_ refers to the network interface used for DRBD replication. A typical value for _<size>_ would be 9000 (bytes).
ja: _<interface>_ にはDRBDのレプリケーションに使用するネットワークインタフェース名を指定します。_<size>_ の一般的な値は9000 (バイト)です。

note: type: Title ====
en: Enabling the deadline I/O scheduler
ja: deadline I/Oスケジューラを有効にする

note: type: Plain text
en: indexterm:[io scheduler] When used in conjunction with high-performance, write back enabled hardware RAID controllers, DRBD latency may benefit greatly from using the simple deadline I/O scheduler, rather than the CFQ scheduler. The latter is typically enabled by default.
ja: indexterm:[io scheduler] 高性能なライトバックに対応したハードウェアRAIDコントローラを使う場合、CFQの代わりに単純な `deadline` をI/Oスケジューラに指定する方がDRBDのレイテンシを小さくできることがあります。通常はCFQがデフォルトで有効になっています。

note: type: Plain text
en: Modifications to the I/O scheduler configuration may be performed via the `sysfs` virtual file system, mounted at `/sys`. The scheduler configuration is in `/sys/block/__device__`, where _<device>_ is the backing device DRBD uses.
ja: I/Oスケジューラ構成に変更を加える場合は、`/sys` にマウントされる `sysfs` 仮想ファイルシステムを使用できます。スケジューラ構成は `/sys/block/<device>` に置かれています。<device>はDRBDが使用する下位デバイスです。

note: type: Plain text
en: Enabling the deadline scheduler works via the following command:
ja: `deadline` スケジューラを有効にするには、次のコマンドを使用します。

note: type: Plain text
en: You may then also set the following values, which may provide additional latency benefits:
ja: 次の値も設定することにより、さらに待ち時間を短縮できます。

note: type: Plain text
en: Disable front merges:
ja: フロントマージを無効にします。

note: type: Plain text
en: Reduce read I/O deadline to 150 milliseconds (the default is 500ms):
ja: 読み取りI/O deadlineを150ミリ秒にします(デフォルトは500ms)。

note: type: Plain text
en: Reduce write I/O deadline to 1500 milliseconds (the default is 3000ms):
ja: 書き込みI/Oデッドラインを1500ミリ秒にします(デフォルトは3000ms)。

note: type: Plain text
en: If these values effect a significant latency improvement, you may want to make them permanent so they are automatically set at system startup. indexterm:[Debian GNU/Linux]Debian and indexterm:[Ubuntu Linux]Ubuntu systems provide this functionality via the `sysfsutils` package and the `/etc/sysfs.conf` configuration file.
ja: 上記の値の変更により待ち時間が大幅に改善した場合は、システム起動時に自動的に設定されるようにしておくと便利です。indexterm:[Debian GNU/Linux]Debianおよび indexterm:[Ubuntu Linux]Ubuntuシステムの場合は、 `sysfsutils` パッケージと `/etc/sysfs.conf` 設定ファイルでこの設定を行うことができます。

note: type: Plain text
en: You may also make a global I/O scheduler selection by passing the `elevator` option via your kernel command line. To do so, edit your boot loader configuration (normally found in `/etc/default/grub` if you are using the GRUB bootloader) and add `elevator=deadline` to your list of kernel boot options.
ja: グローバルI/Oスケジューラを選択するには、カーネルコマンドラインを使用して `elevator` オプションを渡します。そのためには、ブートローダ構成(GRUBブートローダを使用する場合通常は `/etc/default/grub` に格納)を編集し、カーネルブートオプションのリストに elevator=deadline を追加します。
