en to ja translation catalogue (35 entries)

note: type: Title ==
en: Optimizing DRBD throughput
ja: DRBDのスループット最適化

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

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

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

note: type: Block title
en: I/O subsystem throughput
ja: I/Oサブシステムのスループット

note: type: Plain text
en: indexterm:[throughput]I/O subsystem throughput is determined, largely, by the number and type of storage units (disks, SSDs, other Flash storage [like FusionIO], ...) that can be written to in parallel. A single, reasonably recent, SCSI or SAS disk will typically allow streaming writes of roughly 40MiB/s to the single disk; an SSD will do 300MiB/s; one of the recent Flash storages (NVMe) will be at 1GiB/s. When deployed in a striping configuration, the I/O subsystem will parallelize writes across disks, effectively multiplying a single disk's throughput by the number of stripes in the configuration. Thus the same, 40MB/s disks will allow effective throughput of 120MB/s in a RAID-0 or RAID-1+0 configuration with three stripes, or 200MB/s with five stripes; with SSDs and/or NVMe you can easily get to 1GiB/sec.
ja: indexterm:[throughput] I/Oサブシステムのスループットは主に並行して書き込み可能なストレージユニットの数と種類(ハードディスク、SSD、その他のフラッシュストレージ{FusionIOなど}...)によって決まります。比較的新しいSCSIまたはSASディスクの場合、一般に1つのディスクに約40MB/sでストリーミング書き込みを行うことができます。SSDなら300MiB/s、最新のフラッシュストレージ(NVMe)なら1GiB/sほどになります。ストライピング構成で配備する場合は、I/Oサブシステムにより書き込みがディスク間に並列化されます。 この場合、スループットは、1つのディスクのスループットに構成内に存在するストライプの数を掛けたものになります。RAID-0またはRAID-1`0構成で、 3つのストライプがある場合は同じ40MB/sのディスクのスループットが120MB/sになり、5つのストライプがある場合は200MB/sになります。SSDとNVMeまたはNVMeのみで構成すれば容易に1GiB/s超になるでしょう。

note: type: Plain text
en: A RAID-controller with RAM and a <<s-hardware-bbu,BBU>> can speed up short spikes (by buffering them), and so too-short benchmark tests might show speeds like 1GiB/s too; for sustained writes its buffers will just run full, and then not be of much help, though.
ja: バッテリーバックアップされたバッファメモリを持つRAIDコントローラでは少量の書き込みの速度は、それらがバッファリングされることによって大幅に加速されます。非常に短い測定テストでは1GiBを示すかもしれません。持続的な書き込みではバッファがフルになるので速度は低下します。

note: type: Plain text
en: Disk _mirroring_ (RAID-1) in hardware typically has little, if any, effect on throughput. Disk _striping with parity_ (RAID-5) does have an effect on throughput, usually an adverse one when compared to striping; RAID-5 and RAID-6 in software even more so.
ja: ハードウェアのディスク_ミラーリング_(RAID-1)は、一般にスループットにはほとんど影響ありません。ディスクの_パリティ付きストライピング_(RAID-5)はスループットに影響し、通常はストライピングに比べてスループットが低下します。ソフトウェアRAIDのRAID-5やRAID-6であればさらに低下します。

note: type: Block title
en: Network throughput
ja: ネットワークのスループット

note: type: Plain text
en: indexterm:[throughput]Network throughput is usually determined by the amount of traffic present on the network, and on the throughput of any routing/switching infrastructure present. These concerns are, however, largely irrelevant in DRBD replication links which are normally dedicated, back-to-back network connections. Thus, network throughput may be improved either by switching to a higher-throughput hardware (such as 10 Gigabit Ethernet, or 56GiB Infiniband), or by using link aggregation over several network links, as one may do using the Linux indexterm:[bonding driver]`bonding` network driver.
ja: indexterm:[throughput]ネットワークスループットは一般にネットワーク上に存在するトラフィック量と経路上にあるルータやスイッチなどのスループットによって決定されます。ただし、DRBDのレプリケーションリンクは通常は専用の背面間ネットワーク接続であるため、これらはあまり関係がありません。したがって、ネットワークのスループットを向上させるには、高スループットのプロトコル(10ギガビットイーサネットや56GiBインフィニバンド)に切り換えるか、複数のネットワークリンクからなるリンクアグリゲーションを使用します。後者はLinux indexterm:[bonding driver]`bonding` ネットワークドライバを使用して実現できます。

note: type: Title ===
en: Throughput overhead expectations
ja: スループットオーバヘッドの予測

note: type: Plain text
en: When estimating the throughput overhead associated with DRBD, it is important to consider the following natural limitations:
ja: DRBDに関連するスループットオーバヘッドを見積もる際には、 必ず次の制限を考慮してください。

note: type: Plain text
en: DRBD throughput is limited by that of the raw I/O subsystem.
ja: DRBDのスループットは下位I/Oサブシステムのスループットにより制限される。

note: type: Plain text
en: DRBD throughput is limited by the available network bandwidth.
ja: DRBDのスループットは使用可能なネットワーク帯域幅により制限される。

note: type: Plain text
en: The _lower_ of these two establishes the theoretical throughput _maximum_ available to DRBD. DRBD then reduces that throughput number by its additional overhead, which can be expected to be less than 3 percent.
ja: DRBDが使用できる理論上の _最大_ スループットは上記の _小さい方_ によって決まります。この最大スループットはDRBD自体のスループットオーバヘッドが加わることにより低下しますが、 これは3%未満だと考えられます。

note: type: Plain text
en: Consider the example of two cluster nodes containing I/O subsystems capable of 600 MB/s throughput, with a Gigabit Ethernet link available between them. Gigabit Ethernet can be expected to produce 110 MB/s throughput for TCP connections, thus the network connection would be the bottleneck in this configuration and one would expect about 110 MB/s maximum DRBD throughput.
ja: たとえば、600MB/sのスループットが可能なI/Oサブシステムを持つ2つのクラスタノードが、 ギガビットイーサネットリンクで接続されているとします 。ギガビットイーサネットのスループットは 110MB/s程度だと考えられるため、 この構成ではネットワーク接続がボトルネックになります。 DRBDの最大スループットは110MB/s程度でしょう。

note: type: Plain text
en: By contrast, if the I/O subsystem is capable of only 80 MB/s for sustained writes, then it constitutes the bottleneck, and you should expect only about 77 MB/s maximum DRBD throughput.
ja: 一方、I/Oサブシステムの持続した書き込みスループットが80MB/s程度の場合は、これがボトルネックとなり、DRBDの最大スループットはわずか77MB/sになります。

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

note: type: Plain text
en: DRBD offers a number of configuration options which may have an effect on your system's throughput. This section list some recommendations for tuning for throughput. However, since throughput is largely hardware dependent, the effects of tweaking the options described here may vary greatly from system to system. It is important to understand that these recommendations should not be interpreted as "silver bullets" which would magically remove any and all throughput bottlenecks.
ja: DRBDには、システムのスループットに影響する可能性があるいくつかの構成オプションがあります。ここでは、スループットを向上させるための調整について、いくつかの推奨事項を取り上げます。ただし、スループットは主としてハードウェアに依存するため、ここで取り上げるオプションを調整しても、効果はシステムによって大きく異なります。パフォーマンスチューニングについて、必ず効く「特効薬」は存在しません。

note: type: Title ====
en: Setting `max-buffers` and `max-epoch-size`
ja: `max-buffers` と `max-epoch-size` の設定

note: type: Plain text
en: These options affect write performance on the secondary nodes. `max-buffers` is the maximum number of buffers DRBD allocates for writing data to disk while `max-epoch-size` is the maximum number of write requests permitted between two write barriers. `max-buffers` must be equal or bigger to `max-epoch-size` to increase performance.  The default for both is 2048; setting it to around 8000 should be fine for most reasonably high-performance hardware RAID controllers.
ja: これらのオプションはセカンダリノードの書き込みパフォーマンスに影響します。`max-buffers` はディスクにデータを書き込むためにDRBDが割り当てるバッファの最大数で、 `max-epoch-size` は、2つの書き込みバリア間で許容される書き込み要求の最大数です。パフォーマンスを上げるためには `max-buffers` は `max-epoch-size` 以上でなければなりません。 デフォルト値は両方とも2048です。比較的高パフォーマンスのハードウェアRAIDコントローラの場合、この値を8000程度に設定すれば十分です。

note: type: Title ====
en: Tuning the TCP send buffer size
ja: TCP送信バッファサイズの調整

note: type: Plain text
en: The TCP send buffer is a memory buffer for outgoing TCP traffic. By default, it is set to a size of 128 KiB. For use in high-throughput networks (such as dedicated Gigabit Ethernet or load-balanced bonded connections), it may make sense to increase this to a size of 2MiB, or perhaps even more. Send buffer sizes of more than 16MiB are generally not recommended (and are also unlikely to produce any throughput improvement).
ja: TCP送信バッファは送信TCPトラフィックのメモリバッファです。デフォルトサイズは128KiBです。高スループットネットワーク (専用ギガビットイーサネット、負荷分散ボンディング接続など)で使用する場合は、このサイズを2MiBかそれ以上に設定すると効果があるでしょう。送信バッファサイズを16MiB以上にすることは一般にはお勧めできません。 また、スループットが向上する可能性もありません。

note: type: Plain text
en: DRBD also supports TCP send buffer auto-tuning. After enabling this feature, DRBD will dynamically select an appropriate TCP send buffer size. TCP send buffer auto tuning is enabled by simply setting the buffer size to zero:
ja: TCP送信バッファの自動調整もサポートされます。この機能を有効にすると、DRBDが適切なTCP送信バッファサイズを動的に選択します。TCP送信バッファの自動調整を有効にするには、次のようにバッファサイズをゼロに設定します。

note: type: Plain text
en: Please note that your ``sysctl``'s settings `net.ipv4.tcp_rmem` and `net.ipv4.tcp_wmem` will still influence the behaviour; you should check these settings, and perhaps set them similar to `131072 1048576 16777216` (minimum 128kiB, default 1MiB, max 16MiB).
ja: `sysctl` 設定の `net.ipv4.tcp_rmen` と `net.ipv4.tcp_wmem` は挙動に影響します。これらの設定を確認してください。またこれらを `131072 1048576 16777216` (最小128kiB、デフォルト1MiB、最大16MiB)にするとよいかもしれません。

note: type: Plain text
en: `net.ipv4.tcp_mem` is a different beast, with a different unit - do not touch, wrong values can easily push your machine into out-of-memory situations!
ja: `net.ipv4.tcp_mem` はまったく異なるものですので、変更しないでください。間違った値を指定すると、容易にマシンがout-of-memoryになってしまいます。

note: type: Title ====
en: Tuning the Activity Log size
ja: アクティビティログサイズの調整

note: type: Plain text
en: If the application using DRBD is write intensive in the sense that it frequently issues small writes scattered across the device, it is usually advisable to use a fairly large activity log. Otherwise, frequent metadata updates may be detrimental to write performance.
ja: DRBDを使用するアプリケーションが、デバイス全体に分散した小さな書き込みを頻繁に発行する、書き込み集約型の場合は、十分に大きなアクティビティログを使用することをお勧めします。そうでない場合、頻繁なメタデータ更新により書き込みパフォーマンスが低下する可能性があります。

note: For tuning on striped RAID setups, please see the <<al-stripes,al-stripes>> and <<al-stripe-size,al-stripe-size>> settings, too. type: Title ====
en: Disabling barriers and disk flushes
ja: バリアとディスクフラッシュを無効にする

note: type: Plain text
en: The recommendations outlined in this section should be applied _only_ to systems with non-volatile (battery backed) controller caches.
ja: 次に取り上げる推奨事項は、不揮発性(バッテリでバックアップされた)のコントローラキャッシュのあるシステム _のみ_ に適用されます。

note: type: Plain text
en: Systems equipped with battery backed write cache come with built-in means of protecting data in the face of power failure. In that case, it is permissible to disable some of DRBD's own safeguards created for the same purpose. This may be beneficial in terms of throughput:
ja: バッテリでバックアップされた書き込みキャッシュを持つシステムには、停電時にデータを保護する機能が組み込まれています。その場合は、同じ目的を持つDRBD自体の保護機能の一部を無効にすることもできます。これはスループットの面で有効な場合があります。

note: type: Title ===
en: Achieving better Read Performance via increased Redundancy
ja: 冗長性を高め読み込み性能を向上させる

note: type: Plain text
en: As detailed in the man page of `drbd.conf` under `read-balancing`, you can increase your read performance by adding more copies of your data.
ja: `drbd.conf` マニュアルページの `read-balancing` で説明の通り、データのコピーを追加することで読み込み性能を上げることができます。

note: type: Plain text
en: As a ballpark figure: with a single node processing read requests, `fio` on a __FusionIO__ card gave us 100k IOPs; after enabling `read-balancing`, the performance jumped to 180k IOPs, i.e. +80%!
ja: 概算: FusionIO カード利用の１ノードでの読み込み要求が `fio` では100kIOPsでしたが、 `read-balancing` を利用したた場合にはパフォーマンスが180kIOPsとなり、80%の性能向上が見られました!

note: type: Plain text
en: So, in case you're running a read-mostly workload (big databases with lots of random reads), it might be worth a try to turn `read-balancing` on - and, perhaps, add another copy for still more read IO throughput.
ja: 読み込みのワークロードが多い環境の場合(ランダムリードが多い巨大なデータベースなど)では、read-balancing を有効にする意義があります。さらに読み込みIOスループットが欲しい場合にはコピーを増やすとよいでしょう。
