第16章 DRBDの待ち時間の最適化

目次

16.1. ハードウェアの検討事項
16.2. 待ち時間オーバヘッドの予測
16.3. チューニングの推奨事項
16.3.1. CPUマスクの設定
16.3.2. ネットワークMTUの変更
16.3.3. deadline deadline I/Oスケジューラを有効にする

この章では、DRBDの待ち時間の最適化について説明します。待ち時間を最小にするためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。

16.1. ハードウェアの検討事項

DRBDの待ち時間は、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)の待ち時間とレプリケーションネットワークの待ち時間の両方の影響を受けます。

I/Oサブシステムの待ち時間. I/Oサブシステムの待ち時間には、主としてディスクの回転速度が影響します。したがって、高速回転のディスクを使用すればI/Oサブシステムの待ち時間が短縮します。

同様に、BBWC (Battery-Backed Write Cache)を使用すると、書き込み完了までの時間が短くなり、書き込みの待ち時間を短縮できます。手頃な価格のストレージサブシステムの多くは何らかのバッテリバックアップキャッシュを備えており、管理者がキャッシュのどの部分を読み書き操作に使用するか設定できます。ディスク読み取りキャッシュを完全に無効にし、すべてのキャッシュメモリをディスク書き込みキャッシュとして使用する方法をお勧めします。

ネットワークの待ち時間. ネットワークの待ち時間は、基本的にはホスト間のRTT (Packet Round-Trip Time)です。これ以外にもいくつかの要因がありますが、そのほとんどは、DRBDレプリケーションリンクとして推奨する、DRBD専用回線接続の場合は問題になりません。ギガビットイーサネットリンクには常に一定の待ち時間が発生しますが、通常、これは100〜200マイクロ秒程度のパケット往復時間です。

ネットワークの待ち時間をこれより短くするには、待ち時間が短いネットワークプロトコルを利用する以外ありません。たとえば、Dolphin SuperSocketsのDolphin Expressなどを介してDRDBを実行します。

16.2. 待ち時間オーバヘッドの予測

スループットに関して、DRDBに関連する待ち時間オーバヘッドを見積もる際には、必ず次の制限を考慮してください。

  • DRBDの待ち時間は下位I/Oサブシステムの待ち時間により制限される。
  • DRBDの待ち時間は使用可能なネットワークの待ち時間により制限される。

DRBDの理論上の_最小_待ち時間は、上記2つの_合計_です。さらにわずかなオーバヘッドが追加されますが、これは1%未満だと予測されます。

  • たとえば、ローカルディスクサブシステムの書き込み待ち時間が3msで、ネットワークリンクの待ち時間が0.2msだとします。予測されるDRBDの待ち時間は3.2msで、ローカルディスクに書き込むだけのときと比べて約7%待ち時間が増加することになります。
[注記]注記

CPUのキャッシュミス、コンテキストスイッチなど、他にも待ち時間に影響する要因があります。

16.3. チューニングの推奨事項

16.3.1. CPUマスクの設定

DRBDでは、カーネルスレッドの明示的なCPUマスクを設定できます。これは、CPUサイクルがDRBDと競合するアプリケーションの場合に特に役立ちます。

CPUマスクは数字で、バイナリ表現の最下位ビットが第1のCPUを表し、その次のビットが第2のCPUを表します。ビットマスクの設定ビットは、対応するCPUがDRBDによって使用されていることを示し、クリアされたビットは使用されていないことを示します。たとえば、CPUマスク1 (00000001)は、DRBDが第1のCPUだけを使用することを示します。マスク12 (00001100)はDRBDが第3と第4のCPUを使用することを示します。

次に、リソースのCPUマスク構成の例を示します。

resource <resource> {
  options {
    cpu-mask 2;
    ...
  }
  ...
}
[重要]重要

DRBDとこれを使用するアプリケーションとのCPU競合を最小限に抑えるためには、もちろん、DRBDが使用していないCPUだけをアプリケーションが使用するように設定する必要があります。

一部のアプリケーションは、DRBD自体と同様に設定ファイルでこの設定を行うことができます。アプリケーションによっては、initスクリプトで taskset コマンドを呼び出す必要があります。

16.3.2. ネットワークMTUの変更

ブロックベースのファイルシステムがDRBDの上の層に置かれている場合は、レプリケーションネットワークのMTUサイズをデフォルトの1500バイトより大きい値に変更すると効果的な場合があります。(エクステントベースの場合は異なります)口語的には「ジャンボフレームを有効にする」といいます。

[注記]注記

ブロックベースのファイルシステムには、ext3、ReiserFS (バージョン3)およびGFSがあります。エクステントベースのファイルシステムには、XFS、LustreおよびOCFS2があります。エクステントベースのファイルシステムの場合は、少数の大きなファイルが格納されている場合を除き、ジャンボフレームを有効にしてもメリットはありません。

MTUは、次のコマンドを使用して変更できます。:

ifconfig <interface> mtu <size>

または

ip link set <interface> mtu <size>

<interface> にはDRBDのレプリケーションに使用するネットワークインタフェース名を指定します。<size> の一般的値は9000 (バイト)です。

16.3.3. deadline deadline I/Oスケジューラを有効にする

高性能なライトバックに対応したハードウェアRAIDコントローラを使う場合、CFQの代わりに単純な deadline をI/Oスケジューラに指定する方がDRBDの待ち時間を小さくできることがあります。比較的新しいカーネル構成(多くのディストリビューションでは2.6.18より後)ではデフォルトでは有効になっているCFQスケジューラよりも、こちらの使用をお勧めします。

I/Oスケジューラ構成に変更を加える場合は、/sys にマウントされる sysfs 仮想ファイルシステムを使用できます。スケジューラ構成は /sys/block/<device> に置かれています。<device>はDRBDが使用する下位デバイスです。

deadline スケジューラを有効にするには、次のコマンドを使用します。

`echo deadline > /sys/block/<device>/queue/scheduler`

次の値も設定することにより、さらに待ち時間を短縮できます。

  • フロントマージを無効にします。:
echo 0 > /sys/block/<device>/queue/iosched/front_merges
  • 読み取りI/O deadlineを150ミリ秒にします(デフォルトは500ms)。
echo 150 > /sys/block/<device>/queue/iosched/read_expire
  • 書き込みI/Oデッドラインを1500ミリ秒にします(デフォルトは3000ms)。
 echo 1500 > /sys/block/<device>/queue/iosched/write_expire

上記の値の変更により待ち時間が大幅に改善した場合は、システム起動時に自動的に設定されるようにしておくと便利です。Debianおよびindexterm:[Ubuntu Linux]Ubuntuシステムの場合は、sysfsutils パッケージと /etc/sysfs.conf 設定ファイルでこの設定を行うことができます。

グローバルI/Oスケジューラを選択するには、カーネルコマンドラインを使用して elevator オプションを渡します。そのためには、ブートローダ構成(GRUBブートローダを使用する場合通常は /boot/grub/menu.lst に格納)を編集し、カーネルブートオプションのリストに elevator=deadline を追加します。