Placeholder image

1台のサーバ内の2つのデバイスをDRBDで同期できるか?

最近、DRBD Usersメーリングリストなどで「1台のサーバ内の2つのブロックデバイスをDRBDで同期できるか」という話題が持ち上がっています。AWSのEphemeralストレージやRAMディスクとHDD/SDDをDRBDで同期しておけば、超高速アクセスとデータの不揮発性を同時に実現できるのではないか、という思いがあるようです。

やりたいことを図にしてみると....

実際に当社で検証したところ、DRBDが正常に動作することは確認できました。が、結論から言えば、この方法はお勧めできないと考えています。

揮発性だがきわめて高速なデバイスをプライマリ側に置いて、SSDやHDDをセカンダリ側に置くと、read時にはDRBDはプライマリ側からのみ読み込むため、高速なI/Oが実現できます。一方、write時には、DRBDはプロトコルに応じて次のように振る舞います。

  • プロトコルC: 両方のストレージへの書き込みが完了してから次の書き込みに進むため、低速側(SSD/HDD)側のパフォーマンスしか得られない。
  • プロトコルAまたはB: 高速側への書き込みが完了したら次の書き込みに進めるので、高速な書き込みが実現できる。ただし、これはTCPレイヤのバッファに空きがある場合に限られ、短時間に大量の書き込みがあった場合、あっという間にバッファが満杯になる。したがって、低速側のパフォーマンスに引きずられる可能性が高い。

DRBDにはオプション製品としてDRBD Proxyがあります。これは、数百メガバイト〜数ギガバイト程度のバッファをユーザ空間に確保し、セカンダリ側に送りきれないデータを一時的にバッファに蓄える機能を持っています。さらに、特別な同期モードであるAHEAD/BEHINDモードを併用すれば、バッファすら満杯になったときにはプライマリ-セカンダリ間のレプリケーションを一時的に後回しにしてくれます。

これらを併用すれば、上述のようなバッファフルによるパフォーマンス低下を軽減できるかもしれません。が、次のようなかなり大きな問題点があることも見逃すわけにはいかないでしょう。

  • DRBD Proxyのバッファはユーザ空間に確保されているため、バッファに蓄えるときにコンテキストスイッチが多数発生する。WAN経由のリモートレプリケーションのように、データ流量が限られている場合(数メガバイト/秒程度)には問題にならないかもしれないが、数ギガバイト/秒程度の高速な書き込み時には、無視できない負荷になる恐れがある。
  • バッファに蓄えたデータはセカンダリに到達していない。AHEAD/BEHINDモードに入ってレプリケーションを後回しにしているときも同様である。すなわち、これらの動作状態では、プライマリとセカンダリのディスク内容は不整合になっている。バッファ中のデータを喪失するリスクは、リモートレプリケーションでは避けることができず、しかも代替手段がない。このため許容せざるを得ない。データ保護レベルがこれと同等でかまわないなら、採用を検討する価値があるかもしれない
  • 書き込みが少ないケースで読み出しパフォーマンスを極大化したいのであれば、メインメモリを増強して、カーネルが用意するキャッシュ上にほとんどのデータが乗るようにしてしまうのがもっとも簡単で手間いらずだろう。

結論として、このような構成は、writeの頻度が低く、メインメモリ上のキャッシュに乗りきらないほど大容量のデータを取り扱う場合に限れば一定の効果が見込めるのかもしれません。これ以外の場合には、LinuxのソフトウェアRAID機能を使う方がいいでしょう。

DOWNLOAD
ダウンロード

img06

DOWNLOAD

カタログ、セミナー資料のダウンロード

img06

DOWNLOAD

技術資料、マニュアルのダウンロード

img06

DOWNLOAD

ユーザ事例のダウンロード