web-dev-qa-db-ja.com

大規模なデータセット用のシンプルなボリュームレプリケーションツール?

私は次の解決策を探しています:

サーバーA(サイトA)-Win 2008 R2-約10TB(最大15TB)のデータ-800万をはるかに超えるファイル

サーバーB(サイトB)-Win 2008 R2

データの冗長性を確保するために、サーバーAのボリュームをサーバーBのボリュームに非同期的に複製したいと思います。マシンの問題や災害などでサーバーAが故障した場合は、「データを取得するためにここにアクセスしてください」とユーザーに言うことができます。

Windows 2008 R2にはDFSがありますが、Microsoftは明らかにこの大規模なデータセット(より正確には、800万を超えるファイル-私が見つけたドキュメントによると)をサポートしていません。

また、Veritas Volume Replicationも調べましたが、Veritas Volume Managerも必要になるため、これはほとんど多すぎるようです。

1-1のバックアップをとる「バックアップ」ソフトはたくさんありますが、インターネット経由で転送するので、DFSのように転送時に圧縮したものが欲しいです。

誰かがこれに関して何か提案がありますか?

2
Jin

Doubletake Move を使用して、インターネット上で大きなデータセットを移動しました。バイトレベルのレプリケーションを使用し、ファイルへの変更を追跡します。日中は使用量を減らし、夜間と週末にそれをクランクアップするためのニース帯域幅調整スケジューラーもあります。また、何らかの接続が切断された場合でも、かなり良好に回復します。

これは物理マシンに接続されたある種のMSAであると想定していますが、SANを使用している場合は、SANベンダーに非同期レプリケーションオプションを確認してください。

どのレプリケーションを使用する場合でも、考慮したいことがいくつかあります。

  1. ソース側とターゲット側の帯域幅
  2. ファイルの変更率

ソース側の変更率が高すぎて、それを克服するのに十分な帯域幅がない場合、適切なレプリケーションを取得することはできません。

データベースのインデックスの再作成、デフラグ、ファイルの一括移動/追加/削除はすべて、過去に頭痛の種でした。

うまくいけば、私の過去の痛みがこれを読む人を助けるでしょう! :D

2
JakeRobinson

2003 R2のDFSR(2008および2008 R2は、x64であるため、はるかにスケーラブルである可能性があります)は、75台のサーバーですべてが異なるWANリンク(1-10MB)同期ファイル)で非常にうまく機能しました不良、低速、または飽和状態のリンクで合計500GB(サーバーあたり75倍)WAN DFSRを機能させるためにできることを実行することをお勧めします。組織の管理が簡単であることがわかりました。ワイド、Veritas、しかしこれは2003R2が発表された後の2006-7でした。GPOの制御BITS帯域幅はあなたの友達です。

DFSRの特徴の1つは、送信する必要のある変更されたすべてのブロックのコピーを含むフォルダーを保持することです。したがって、ストレージは自由に使用したいものです。たくさんのリソース(RAM、CPU、ディスク)のコンテキストでは、8Mファイルで十分だと思うので、あなたが引用する制限について興味があります。ファイル数がわかりません。

また、過去には、DFSRはバックアップ、A/V、およびその他のソフトウェアと互換性がありませんでした。 2008〜 2009年に、NetbackupがDFSRを嫌い、ファイルサーバーのバックアップで成功を報告していたが、実際には何もバックアップしていないことがわかりました。復元をテストしたときにのみ、Netbackupでこの恐ろしい、恐ろしい障害を発見しました。バックアップシステムに実行させたくないことが1つある場合は、バックアップが成功したことを報告しますが、実際には空のテープを用意します。

とにかく、私はDFSRに自信を持って投票します。特に、シナリオをテストしたと具体的に述べているベンダーの製品が見つからない場合は、2008R2を使用した3番目のバージョンを試してみてください。多くの場合、Microsoftが公式にサポートしているものは、機能することがわかっているものよりもはるかに保守的です。明らかにあなたのマイレージは変わるかもしれません、そしてあなたはあなたがとることをいとわないあなた自身のリスクのレベルを決定しなければなりません。

1
Bret Fisher

レプリケーションを確認するための鍵は、レプリケートされるデータの「一貫性のあるセット」を探すことです。例:Dbおよび対応するログファイルは、データが他の複製されたサイトで使用できるように、「一貫した」方法で複製する必要があります。

注目すべき2番目の重要な機能は、接続が切断された場合の回復に必要な時間です。レプリケーションは、離れた場所から開始されますか?レプリケーションを再開しますか?

3つ目は、さまざまなネットワーク条件でどの程度うまく機能するか(または悪化するか)、帯域幅の使用率はどのくらいかです。

注目すべき他の重要なことは-ファイルのパーミッションは維持されていますか?他のファイル属性は維持されていますか?圧縮されたフォルダはどうなりますか?暗号化されたファイルはどうなりますか?開いているファイルは複製されますか?などなど。

上記のすべてを考慮すると、ブロックベースのレプリケーションソリューションはファイルベースのレプリケーションよりもはるかに優れています。ホストブロックベースのレプリケーションは、「オフホスト」ブロックベースのレプリケーションよりも安価です。

1
Asheesh

SureSync 製品を使用してデータを「ホットスタンバイ」ファイルサーバーに複製しているお客様がいます。それらは2TB弱で複製しており、非常にうまく機能しています。 NTFS変更ジャーナルを使用してファイルの更新を追跡し、デルタレプリケーションを実行します。

公開されている製品の制限が見つからないので、「メーカー」にチェックインして確認することをお勧めします。

0
Evan Anderson

Veritas VolumeReplicatorオプションを備えたVeritasVolume Managerは安価ではありませんが、次のようないくつかの利点があります。

  • ブロックレベルで機能するため、ファイル全体を複製したり、ファイルが閉じられるのを待ってから保存を複製したりする必要はありません。
  • 書き込み順序の忠実度が維持されるため、プライマリでデータが変更される順序は、セカンダリでデータが変更される順序になります。これは、データベースなどに適しています。
  • セカンダリにフェイルオーバーする必要がある場合は、セカンダリへの変更をプライマリに簡単に同期して戻すことができます。
  • 転送の圧縮とスロットル。

データ変更率を監視するために使用できるツール(VRAdvisor)があります。これにより、プライマリの特定のデータ変更量内でセカンダリを維持するために必要な帯域幅がわかります。

0
hmallett