drbd_proxy_wan

DRBD Proxy のスループットに対する WAN 回線の影響
株式会社サードウェア久保元治
2014 年 6 月 20 日
概要
DRBD Proxy は、DRBD (Distributed Replicate Block Device) のリアルタイムレプリケーションを遠距離
に拡張するために用いる、WAN 高速化ソフトウェアである。
DRBD が通信に用いる TCP プロトコルは、拠点間の距離 (正確にはレイテンシ) によって転送性能が変わる。
このため、LAN でのレプリケーションに比べて遠距離レプリケーションのスループットは多くの場合大幅に低下
する。
DRBD Proxy が採用している高速化技法は、データ圧縮とバッファリングだが、高速化効果を期待できる反
面、データ種別に依存する、バッファ上のデータは永遠に失われる場合があるといった、制約や注意事項がある。
このテクニカルレポートでは、DRBD Proxy の導入を検討するにあたって知っておくべき事項を解説する。
TCP プロトコルにおける拠点間距離の影響
1
DRBD は TCP プロトコルを使ってディスク書き込みデータをレプリケートする。
TCP プロトコルは、送信者と受信者が通信状況をつねに確認し、欠落や破損したパケットを再送するなどのエ
ラー回復も自律的に行って、信頼性が高い通信を実現している。
逆の見方をすれば、送信者から受信者に一方的にパケットを送り付けるだけではなく、定期的に受信者から送信
者に確認を返す必要があり、拠点間の (通信上の) 距離が大きい場合には、スループットの低下は避けられない。
1.1
レイテンシとスループットの関係
理論的には、TCP プロトコルのスループットは次の式で算出できることが知られている。
スループット (bps) = ウインドウサイズ (byte) × 8/レイテンシ (sec)
レイテンシはパケットの往復に要する時間で、ping コマンドを実行して得られるラウンドトリップ・タイムと
考えればよい。ウィンドウサイズ (後述) を 262144 バイトに設定した場合の理論上のスループットをグラフで示す
と、次ページの図のようになる。
3 本の線は、代表的なイーサネットの仕様上の最大帯域 (ギガビット、100 メガビット、10 メガビット) である。
WAN 回線の場合は、netperf コマンドで測定した実際の帯域幅で考えるのが妥当である。
このグラフから、スループットに関して以下のように考察できる。
• LAN 環境のレイテンシは通常 1 ミリ秒以下 (¡0.001 秒) であり、イーサネットの仕様上の最大帯域幅でのス
ループットが期待できる。
• WAN 環境のレイテンシは、通常数ミリ∼数百ミリ秒であり、契約している帯域幅に関わらず、実際のス
ループットは数メガ bps∼数十メガ bps しか得られない。
レイテンシは、送信者と受信者の間の距離や、間に介在するネットワーク機器での遅延の合計で決まる。遠隔
バックアップを検討する場合にもっとも重要な要因になるのは、拠点間の距離である。
信号の伝達速度は、ファイバーやメタル回線の場合、1km あたり 5 マイクロ秒程度とされている。たとえば東
京-大阪間 (500km と仮定) の場合、片方向の伝達に約 2.5 ミリ秒を要する。実際の回線は直線ではなく、さらに
ルータなどの中継機器を通過する際の処理遅延も加わるため、往復で 10∼20 ミリ秒程度のレイテンシになるのが
一般的である。
1
図 1: レイテンシとスループットの関係 (理論値)
遠隔バックアップを検討する時点で WAN 回線をまだ用意できていない場合、国内であれば 20∼30 ミリ秒程度
のレイテンシになると想定しておくのが妥当ではないかと思われる。この場合、期待できるスループットは 20M
bps 程度が上限になると思われる1 。
1.2
ウィンドウサイズ
送信者が送った 1 パケットごとに受信者が確認を返していては、きわめて効率が悪い。そこで、送信者と受信
者が合意したまとめ送り範囲内であれば、送信者は受信者の確認を待たずにパケットを送出し、受信者は遅れて
受信確認を返す、という方式が使われている。このまとめ送りの範囲をウィンドウと呼ぶ。
Linux のデフォルトのウィンドウサイズは、初期値 16kB、最小 4kB、最大 4MB になっている。ウィンドウサ
イズは、通信開始当初は 16kB だが、回線状況に応じて 4kB から 4MB の範囲で動的に調整される、ということで
ある。
実際は、1 パケットの送信から開始し、最大ウィンドウサイズに達するか輻輳が発生するまでウィンドウサイ
ズを大きくしていく (下図参照)。輻輳が起きると、いったんウィンドウサイズを約半分に落として徐々に上げて
1 回線のスループットは通常ビット/秒で表現するが、ディスク I/O は通常バイト/秒で表現する。パケットヘッダ他のオーバヘッドも考慮
して、回線スループットを 8∼10 で割ってバイト単位に換算する必要がある。20Mbps の場合、約 2 メガバイト/秒ということになる。
2
いく。
図 2: ウィンドウサイズと輻輳の関係
輻輳とは、混雑のためにルータがパケットを破棄するなどの理由で、送信したパケットが受信者に届かないこ
とである。輻輳が起きたら、いったん通信速度を落とすとともに、破棄されたパケットの再送などのリカバリが
必要になる。
複数の利用者とアプリケーションが回線を共同利用するインターネットでは、輻輳は避けられない。帯域保証
がないベストエフォート回線では、日次変動があるため、可能であれば数日∼数週間程度、実際のネットワーク
スループットを測定しておくのが望ましい。
1.3
セッション数
これまで述べてきた考察は、1 つの TCP セッションに適用される。同時に複数の TCP セッションが存在する
ときは、それぞれにこの制限が適用されるが、各セッションのスループットの合計が回線の帯域幅以内に収まって
いれば、それぞれのセッションは制限範囲内でフルスピードで通信できる。
たとえば、契約帯域 100Mbps の回線を使って東京-大阪間で通信していて、1 つの TCP セッションが 20Mbps
で通信できるならば、理想的条件下では最大 5 TCP セッションまでであれば、それぞれが 20M bps で通信でき
ると期待できる。
図 3: 複数レプリケーション領域の活用
DRBD にあてはめると、1 つのレプリケーション領域だけで運用する場合には、最大約 2MB/sec 程度のディス
ク書き込みが限界になる。3 つのレプリケーション領域に分割して領域ごとに最大 2MB/sec、合計で最大 6MB/sec
程度のスループットを得られる可能性がある。
3
DRBD Proxy のデータ圧縮
2
DRBD Proxy は、TCP パケットに乗せるデータを圧縮する機能を備えている。WAN 回線帯域が 20Mbps と
期待され、平均 50%のデータ圧縮が期待されるなら、最大約 4MB/sec までのデータ書き込みに対応できることに
なる。
DRBD Proxy バージョン 1 では zlib 圧縮のみが、DRBD Proxy バージョン 3 では zlib に加えて LZMA 圧縮が
利用できる。
2.1
zlib 圧縮
zlib 圧縮は zip や gzip コマンドに採用されている圧縮アルゴリズムと同等で、テキストファイルの場合約 70%程
度の圧縮率が得られる。しかしすでに高度に圧縮されているファイル、たとえば JPEG 画像、MPEG 他のビデオ、
docx や xlsx などのマイクロソフト・オフィスファイルなどの場合には、高い圧縮率は期待できない。
実際に取り扱うデータによって圧縮率が異なるため、平均的な期待値を示すことはできない。
2.2
LZMA 圧縮
LZMA 圧縮は 7-Zip アーカイブユーティリティで採用されている圧縮アルゴリズムで、辞書式圧縮方式を採用
し、zlib よりも高い圧縮率が達成されている。しかし、圧縮アルゴリズムが複雑なため、zlib よりも大量の CPU
とメモリリソースを必要とする。
WAN 回線帯域が比較的良好、または高いディスク I/O スループットを必要としない場合には zlib を、CPU や
メモリに余裕があって高い圧縮率を必要とする場合には LZMA を使うのがよいと思われる。
3
DRBD Proxy のバッファリング
DRBD Proxy は、回線帯域を超えるバースト的な大量のディスク書き込みが発生したときに、書き込み自体の
スローダウンを緩和する目的で、バッファ機能を提供している。
たとえば 20M bps (2MB/sec) の WAN 回線を使っていて、10MB のディスク書き込みが瞬間的に発生した場合、
バッファがなければ書き込み完了までに 10/2 = 5 秒の時間を要し、アプリケーションの実行は著しくスローダウ
ンする。
しかし 10MB 以上のバッファが空いていれば、DRBD Proxy は書き込みデータをいったんバッファに収容して、
ディスク書き込みが完了した扱いにする。したがって、アプリケーションから見たディスク書き込みはほぼ瞬間
的に完了し、スローダウンは起こらない。
ただし、バッファに格納したデータの取り扱いについては、以下のような留意点がある。
1. バッファのデータは、遅い WAN 回線を使って遠隔地の DRBD に送り届けなければならない。この所要時
間は、上記と同様に 10/2 = 5 秒程度と想定される。
2. バッファはバースト的な書き込みによるスローダウンを緩和する目的で使うようにしなければならない。た
とえば 2MB/sec 程度しか送出できない WAN 回線を使っている限り、平均 2MB/sec 以上のディスク書き込
みには耐えられず、いずれアプリケーションの大幅かつ恒常的なスローダウンを引き起こす。
3. バッファのデータはレプリケートされていない。バッファにデータが溜まっている状態でシステムを再起動
しても、再起動後に自動的に再送されるため、いずれ遠隔サーバ側にデータはレプリケートされる。しかし、
災害などで送出側サーバが永久に失われた場合、バッファに溜まっていたデータは永久に失われる。
繰り返すが、バッファはバースト的に発生する大量書き込みによるスローダウンを緩和するための手段である
ことを理解しておく必要がある。
4
4
DRBD Proxy 導入前のチェックリスト
ここまで述べたように、DRBD Proxy の導入を検討するにあたって、WAN 回線のスループットを中心に、適
切な利用形態を検討する必要がある。以下に、検討すべき項目をチェックリストとして掲載する。
WAN 回線のスループットを計測すること
導入検討にあたってもっとも重要なポイントは、WAN 回線のスループットを明らかにすることである。す
でに回線が利用できるならば、数日間 ping のラウンドトリップ時間を測定して、平均値や変動の傾向を把
握するのが望ましい。ラウンドトリップ時間 (レイテンシ) から理論的な最大スループットが予測できる。さ
らに可能であれば、netperf などのツールで TCP のスループットを実際に測定しておくのが望ましい。
回線がまだ利用できない場合には、安全を見込んで約 20Mbps 程度のスループットを想定するのが妥当と思
われる。
プロバイダの利用規約を確認すること
これはテクニカルなチェックポイントではないが、実際の運用上きわめて重要なチェックポイントである。プ
ロバイダやそのサービスによっては、転送量が多い場合に帯域を制限されたり、最悪の場合には契約を解除
される可能性がある。少なくとも、ビジネス用のサービス品目を選択すべきである。
想定されるデータ更新量を明らかにすること
WAN 回線帯域を超えるレプリケーションはできない。たとえば 1 日あたりのデータ更新量を予測し、1 日
あたりの WAN 経由の転送可能データ量と比較しておくことは、最低限押さえておく必要がある。
5

Download Report