2つの離れたLinuxサーバー間での大きなファイルツリーの双方向リアルタイム同期
大きなファイルツリーとは、約200kのファイルを意味し、常に成長しています。ただし、一定の時間内に比較的少数のファイルが変更されます。
双方向とは、どちらかのサーバーで変更が発生する可能性があり、他方にプッシュする必要があるため、rsyncが適切ではないように見えることを意味します。
遠いということは、サーバーは両方ともデータセンターにあるが、地理的には互いに離れているということです。現在、サーバーは2つしかありませんが、時間の経過とともに拡大する可能性があります。
リアルタイムでは、同期の間に少しの待ち時間があっても問題ありませんが、1〜2分おきにファイルのごく一部が変更される可能性があるため、1〜2分ごとにcronを実行するのは適切ではないようです。
[〜＃〜] edit [〜＃〜]：これはVPSで実行されているので、実行できるカーネルレベルのものに制限される可能性があります行う。また、VPSはリソースが豊富ではないため、大量のRAMを必要とするソリューション（Glusterなど）は避けたいと思います。
これを実現するための最良/最も「受け入れられた」アプローチは何ですか？これは一般的なニーズのようですが、一般的に受け入れられているアプローチをまだ見つけることができず、これは驚くべきことでした。 （私は大衆の安全を求めています。:)
ファイルシステムの変更レベルで同期をトリガーするために lsyncd に遭遇しました。あまり一般的ではありませんが、それは賢いようで、さまざまなlsyncdのアプローチに少し混乱しています。 rsyncでlsyncdを使用しているだけですが、rsyncにはメモリの概念がないため、これは双方向性に脆弱である可能性があります（たとえば、Aで削除されたファイルをBで削除する必要があるかどうか、またはBで新しいファイルであるかどうかを知るため） A）にコピーする必要があります。 lipsync は、単にlsyncd + rsync実装のように見えますよね？
次に、次のように csync2 でlsyncdを使用します： https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ...私はこのアプローチに傾いていますが、csync2は少し風変わりですが、テストは成功しました。私は主に、この方法について多くのコミュニティの確認を見つけることができなかったことを心配しています。
ここの人々はUnisonをとても気に入っているようですが、それは もはや活発な開発が行われていません であり、lsyncdのような自動トリガーがあることは明らかではありません。
Gluster が表示されたのを見たことがありますが、必要以上にやりすぎているのではないでしょうか？
UPDATE：fyi-私が言及した元のソリューションであるlsyncd + csync2を使用してしまいました。それは非常にうまく機能しているようで、サーバーを非常に緩く結合して、各サーバーがサーバー間のリンク品質に関係なく無期限に動作できるようにするというアーキテクチャ上のアプローチが好きです。
[〜＃〜] drbd [〜＃〜] in Dual-primary mode with a Proxy はオプションです。
あなたの場合、デュアルプライマリモードのDRBDとgfsまたはocfsの組み合わせをお勧めします。
デュアルプライマリでのDRBDの欠点は、同期モードで実行されることです。しかし、ここでは書き込み速度は重要ではないようです。
DRBDに代わるものは、多くの（2+）iSCSIターゲットを使用するSoft-Raid1かもしれませんが、私は2つのノードを持つDRBDを好みます。
分散ファイルシステムの実装は、特にサーバーのクラスターが大きくなる場合は、ツールやスクリプトを使用してこれをハッキングするよりもおそらく優れています。また、ダウンしたノードをより適切に処理できるようになります。
Gluster（またはAFS）は過剰だとは思いません。
上記のように、多くのソリューションが利用可能であり、それぞれに長所と短所があります。
ツリー全体をバージョン管理下に置き（ Subversion など）、両方のサーバーから定期的にcronジョブでチェックイン/更新することを検討すると思います。
同じことについての探求のいくらかを終えたところで、私はglusterに行きます。ただし、パフォーマンステストを行っていない、または見つけていません。