none
2008 r2 DFS-R スケーラビリティの問題について RRS feed

  • 質問

  • お世話になります。

    弊社環境では、同一ドメイン上でデータサーバーを6台運用しており、2台一組で双方向のデータの同期を行っています。

    ペアの片方はバックアップ用途です。バックアップ側をユーザーが読み書きすることは、通常ありません。

    サーバーOSは全てWindows 2008 r2です。物理メモリは6G~24Gです。CPUはIntel Core i5 or i7です。

    データサーバー1台当り、HDが約2TBx8=16TB(一部3TBのHDもあり)、空き容量は2割程度です。

    データ内容は濃淡画像(圧縮してほとんど小さくならない種類のファイル)が9割以上です。

    社内ギガビットLANで接続しており、ネットワーク帯域は十分と思います。

    ステージング領域として、該当HDとは別HDに使用頻度に応じて、200GB~500GB程度割り当てています。

    データサーバー上のファイルを書き込む(更新する)頻度としては、一日約200GB~300GB程度です。
    Remote Differential Compression (RDC) は従来は有効になっていましたが、データ特性上圧縮による、時間的コストと、圧縮率が割に合わないため、無効化しています。
    2年以上運用していますが、同期が一部追いつかない状況が続いています。

    ステージング領域はいつ見ても、限界まで使用しているような状態です。
    また、イベントビューワーのログもDFSが正常動作しなかったとかなりの頻度で出ています。

    この構成でのスケーラビリティについて、妥当性のコメントを頂けないでしょうか。

    改善策、DFS-R以外の選択肢の検討など、ありましたら、大変助かります。

    よろしくおねがいします。

    2013年5月28日 9:46

回答

  • チャブーンです。

    まず、「システムパフォーマンス」についての妥当性が知りたいとのことですが、こうした無償掲示板で責任ある回答を求められるのは、難しいでしょう。個人的な見解ですが、スケーラビリティの観点からは、システム全体のデータ量がいささか多い(ガイドラインは10TB)ということ、RDCが無効とのことですので送信失敗があった場合のオーバーヘッドが大きい(失敗したファイルは最初から再送になるため)のがありますが、それ以上は何ともいえません。すでに確認済みとは思いますが、MSの資料を再読いただくといいと思います。

    http://technet.microsoft.com/ja-jp/library/cc773238(v=ws.10).aspx

    チューニングを行う場合ですが、ハードウェアの設定(TCPオフロードをONにする)やTCP/IPのウインドウサイズの設定(原則的には自動で問題はないはずなのですが)とDFSRのレジストリ設定を行うと、若干の改善はあるかもしれません。特にDFSRの設定内容については以下の資料をご覧いただくといいように思います。

    http://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx

    またDFSRやSMBのスループットは本来論としてFTPのようなファイル転送の特化プロトコルより速度は遅いものです。納得できる速度が出ないような場合、FTPを使ったファイル同期ツールを使ってみる方法もあるように思います。小規模なシステムではないという認識ですので、商用サポートがしっかりしている製品を探してみてください。

    • 回答の候補に設定 佐伯玲 2013年5月30日 0:56
    • 回答としてマーク macaron0 2013年5月31日 7:15
    2013年5月28日 19:28
    モデレータ
  • DFSのエラーが出ているとのことですが、例えば、DFSのデータベースが壊れたとか、DFSのプロセスが異常終了したとかではないでしょうか。

    そもそも、DFS-Rの同期速度はあまり早くないですし、耐障害性も低いため、個人的には大規模環境での使用はおすすめではないです。一方向ファイル同期であれば、マイクロソフト社のツールであればrobocopyの方が、まだパフォーマンスは早いです。ただし差分更新すると、差分の抽出に長時間を要しますが……

    • 回答としてマーク macaron0 2013年5月31日 7:15
    2013年5月30日 17:16

すべての返信

  • チャブーンです。

    まず、「システムパフォーマンス」についての妥当性が知りたいとのことですが、こうした無償掲示板で責任ある回答を求められるのは、難しいでしょう。個人的な見解ですが、スケーラビリティの観点からは、システム全体のデータ量がいささか多い(ガイドラインは10TB)ということ、RDCが無効とのことですので送信失敗があった場合のオーバーヘッドが大きい(失敗したファイルは最初から再送になるため)のがありますが、それ以上は何ともいえません。すでに確認済みとは思いますが、MSの資料を再読いただくといいと思います。

    http://technet.microsoft.com/ja-jp/library/cc773238(v=ws.10).aspx

    チューニングを行う場合ですが、ハードウェアの設定(TCPオフロードをONにする)やTCP/IPのウインドウサイズの設定(原則的には自動で問題はないはずなのですが)とDFSRのレジストリ設定を行うと、若干の改善はあるかもしれません。特にDFSRの設定内容については以下の資料をご覧いただくといいように思います。

    http://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx

    またDFSRやSMBのスループットは本来論としてFTPのようなファイル転送の特化プロトコルより速度は遅いものです。納得できる速度が出ないような場合、FTPを使ったファイル同期ツールを使ってみる方法もあるように思います。小規模なシステムではないという認識ですので、商用サポートがしっかりしている製品を探してみてください。

    • 回答の候補に設定 佐伯玲 2013年5月30日 0:56
    • 回答としてマーク macaron0 2013年5月31日 7:15
    2013年5月28日 19:28
    モデレータ
  • DFSのエラーが出ているとのことですが、例えば、DFSのデータベースが壊れたとか、DFSのプロセスが異常終了したとかではないでしょうか。

    そもそも、DFS-Rの同期速度はあまり早くないですし、耐障害性も低いため、個人的には大規模環境での使用はおすすめではないです。一方向ファイル同期であれば、マイクロソフト社のツールであればrobocopyの方が、まだパフォーマンスは早いです。ただし差分更新すると、差分の抽出に長時間を要しますが……

    • 回答としてマーク macaron0 2013年5月31日 7:15
    2013年5月30日 17:16
  • チャブーンです。

    まず、「システムパフォーマンス」についての妥当性が知りたいとのことですが、こうした無償掲示板で責任ある回答を求められるのは、難しいでしょう。個人的な見解ですが、スケーラビリティの観点からは、システム全体のデータ量がいささか多い(ガイドラインは10TB)ということ、RDCが無効とのことですので送信失敗があった場合のオーバーヘッドが大きい(失敗したファイルは最初から再送になるため)のがありますが、それ以上は何ともいえません。すでに確認済みとは思いますが、MSの資料を再読いただくといいと思います。

    http://technet.microsoft.com/ja-jp/library/cc773238(v=ws.10).aspx

    ありがとうございます。
    ファイルの一部のみ変更が入るようなことはほとんど無い運用方法ですので、RDC無効による、ファイル単位での再試行による影響はほとんどないと考えます。システム全体のデータサイズは少なく見積もっても、6台x16TBなので、約100TBほどになり、データ量がDFS-Rのガイドラインに対して多いとのこと理解しました。ガイドラインは10TBとのことですが、ソースのURLなど教えていただけないでしょうか。関連箇所を探しておりますが、見当たりません。

    チューニングを行う場合ですが、ハードウェアの設定(TCPオフロードをONにする)やTCP/IPのウインドウサイズの設定(原則的には自動で問題はないはずなのですが)とDFSRのレジストリ設定を行うと、若干の改善はあるかもしれません。特にDFSRの設定内容については以下の資料をご覧いただくといいように思います。

    http://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx

    若干の改善では、別のPC間でミラーリングバックアップの目的を達成することは難しそうな状況です。

    またDFSRやSMBのスループットは本来論としてFTPのようなファイル転送の特化プロトコルより速度は遅いものです。納得できる速度が出ないような場合、FTPを使ったファイル同期ツールを使ってみる方法もあるように思います。小規模なシステムではないという認識ですので、商用サポートがしっかりしている製品を探してみてください。

    前任者により、スケーラビリティについての考慮無しに、DFS-Rが導入され、現在もバックアップが正常に取れないという問題点が解決できないという状態です。
    質問時、書き忘れましたが、サーバー再起動時、DFS-Rの再同期がこのデータ規模だとかなり負荷になるようです。
    別のファイル同期ツールが目的に適しているようです。
    大変参考になりました。

    2013年5月31日 6:54
  • 修正プログラムの一覧がありました。

     

    現在利用可能な修正プログラムを Windows Server 2008 および Windows Server 2008 R2 での分散ファイル システム (DFS) テクノロジの一覧

    http://support.microsoft.com/kb/968429/ja

    2013年5月31日 7:07
  • DFSのエラーが出ているとのことですが、例えば、DFSのデータベースが壊れたとか、DFSのプロセスが異常終了したとかではないでしょうか。

    ありがとうございます。
    その通りです。その系統のエラーが頻発します。ステージング領域が足りてないようです。

    そもそも、DFS-Rの同期速度はあまり早くないですし、耐障害性も低いため、個人的には大規模環境での使用はおすすめではないです。一方向ファイル同期であれば、マイクロソフト社のツールであればrobocopyの方が、まだパフォーマンスは早いです。ただし差分更新すると、差分の抽出に長時間を要しますが……

    同期速度のあまり早くないこと、耐障害性の低さ理解しました。
    消したファイルが復活する現象が何度も起こったりして、コントロールしきれていないと感じます。
    スケーラビリティ上の問題を抱えていると思い質問しました。
    前任者がMSサーバー向け製品というだけで、DFS-Rに期待しすぎたようです。
    参考までに、この環境でrobocopyを用い、外付けのHD(USB2)に1.5TBをコピーすると約60時間かかります。
    robocopyは/MIRで差分のみ同期させれば、大規模環境の使用に耐えるパフォーマンスがありますか?
    リアルタイムバックアップが理想です。
    用途としては、一方向で十分です。
    フリーソフトとしてはrobocopyを検討したことがあります。
    別のファイル同期ツールを探すことにします。
    2013年5月31日 7:13
  • チャブーンです。

    > ガイドラインは10TBとのことですが、ソースのURLなど教えていただけないでしょうか。関連箇所を探しておりますが、見当たりません。

    これですが、最初にお知らせしたURLに含まれています。(以下、抜粋します)

    ----
    DFS レプリケーションでサポートされる制限にはどのようなものがありますか。

    マイクロソフトで検証済みの Windows Server 2008 R2 および Windows Server 2008 のスケーラビリティに関するガイドラインを以下に示します。

    • 1 つのサーバー上のすべてのレプリケート ファイルのサイズ: 10 テラバイト。
    • 1 つのボリューム上のレプリケート ファイルの数: 800 万。
    • 最大ファイル サイズ: 64 GB。

    ----

    状況から、仮にDFS-Rのエラーすべてを解消したとしても、ご要望の速度でのコピーはDFS-Rの機能では難しいと思ます。DFS-Rのチューニングですが、URLを見ていただけるとわかりますが、1GB等の高速回線での改善は少なく、512KB以下の低速回線での改善が著しい結果になっていることから、おそらくこれも難しいという見解です。

    2013年6月3日 5:14
    モデレータ