複数のサーバーへのファイルの展開

たとえば、server-1にファイルの中央リポジトリがあります/srv/www。次に、N個のサーバーもあります。server-1は/srv/www、可能な限り迅速かつ効率的にすべてのサーバーにファイルを展開できるようにしたいと考えています。

rsyncのようなものがありますが、単一のターゲットを指定する代わりに、ターゲットのクラスター（Nサーバー）を指定しますか？

gitうまくいくと思っていましたが、プッシュする複数のリモートを指定できますか？

Nサーバーが最終的に数百台に達する可能性があると仮定した場合の最良のソリューションは何ですか。

さて、TwitterとFacebookはどちらもクラスターでbittorrentを使用して新しいコードの改訂版を配布し始めています。これにより、従来の集中型の展開方法と比較して、非常に短い時間で数万台のサーバーにコードをプッシュできます。

まだその規模にいるようには見えませんが、すぐにボトルネックになることがないように展開システムを設計しても害はありません。

あなたが話しているスケールにはgitはお勧めしません。それは機能しますが、個人的にそのモデルをフェッチに使用することにはいくつかの欠点があります。

これについて最善の方法を決定するものがいくつかあります。

1. どのくらいのレポを共有する必要があるか。
2. 収束に必要な速度。

完全な収束と最高速度を実現するには、NFSv4などのネットワークファイルシステムを使用する必要があります。私が知っているクラスター化されたファイルシステムは、「数百」のノードに拡張できないため、ネットワークファイルシステムでなければなりません。これには独自の課題がありますが、NFSヘッドでファイルが更新された瞬間に収束することを意味します。

迅速な収束のために、rsyncトリックを使用できます。rsyncデーモンがCPUバウンドになった場合、haproxyのようなロードバランサーの背後に数個のrsyncサーバーを確実に配置できます。それをcronジョブと組み合わせてデータをプルする（またはコード更新をトリガーする他の方法）と、すぐに収束することができます。

上記の両方について、最大のスループットを得るために中央リポジトリを10GbEリンクに配置することをお勧めします。

別の方法はpush-rsyncで、中央リポジトリから実行してサーバーに更新をプッシュします。上記のいずれかの速度で収束することはありませんが、内部帯域幅により適しています。速度を上げるには、複数のホストを使用して、分割された範囲にプッシュします。

rdistが動作する場合があります。

[関連] Kwatee（http://www.kwatee.net）を使用すると、必要な数のサーバーにデプロイできます。展開はインクリメンタルで（変更されたファイルのみが送信される）、並列化できるため非常に迅速です。また、Kwateeをロードバランサーに対応するように構成して、更新中にサーバーをLBから削除してから再挿入することもできます。展開パラメーターを構成するグラフィカルインターフェイスがあり、GUIを介して手動でトリガーするか、Pythonコマンドを使用して自動化することができます。