プライマリロケーションとセカンダリロケーション間のデータレプリケーションにDRBDを使用することを検討します。最初の計画は、2つの間にVPNトンネルを確立することです。デュアルT1リンクのスライスを使用するプライマリエンドとケーブル/ DSLラインのセカンダリロケーション設定。
セカンダリはDRのみに存在し、プライマリにレプリケートされることはありません。
誰かがこのようなことをした/疲れた/使用したことがありますか？それについてのあなたの経験は何ですか？
Linbitには、WANタイプのリンク（圧縮、複数のピア）で動作するように設計されている（有料の）DRBDプロキシ製品もあります。誰かこれを試しましたか？
回答:
私はDRBDプロキシについて話すことはできませんが、通常のDRBDはそれほど好きではありません。
アクティビティが制限されていても、デュアルT1を簡単に飽和させることができます（2x 1.5Mbps、ラウンド数では300KB / s）。300KB / sは、アプリケーションのログ記録だけで使用される可能性があります。ましてや、サーバーで何か面白いことをするとは限りません。これにより、同期レプリケーション（プロトコルC）が除外され、vpn-over-the-vpnレイテンシが方程式に追加されます。
非同期レプリケーション（プロトコルA）は技術的には機能するかもしれませんが、セカンダリが非常に古く、障害が発生した場合に使用できないことが予想されます（レプリカは日中数時間遅れている可能性があります）。
メモリ同期（プロトコルB）は、帯域幅の問題によって制約されているため、役に立ちません。
DRBDプロキシでも同様の問題が発生し、帯域幅の制限により主にレプリケーションの遅延が発生すると予想しています。
DR戦略を再評価して、軽減する対象を特定することをお勧めします。ハードウェア障害またはサイト障害。
サイト障害から保護する場合、1つ（または両方）の帯域幅に制約のあるサイトの場合、低帯域幅/高密度転送からより良い走行距離を得ることができます。この手法のいくつかの例はrsyncです（オーバーザワイヤー転送は、変更ごとの変更ごとではなく、実行間のファイルの変更に限定されます。さらに、プロトコルオーバーヘッドがいくつかあります。SSH経由で実行して、トラフィックをさらに暗号化および圧縮できます）。データベースログ配布（DRデータベースで再生するために圧縮されたデータベースログを転送すると、完全なデータベースダンプを転送するよりも少ない帯域幅を使用できます）。
ハードウェア障害から保護している場合、GigEクロスオーバーに接続されたローカルDRBDレプリカは問題なく機能し、完全な同期更新を可能にし、両方のノードでデータの整合性を証明するオンライン検証を許可します。このオプションをDRサイトへの制限付きファイルレプリケーションと組み合わせて、プライマリサイトの障害から保護することができます。