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