Ubuntu Server 10.04 を実行するサーバーが 3 台あり、DNS を介してサーバー間で負荷分散を行っています。コンテンツの提供には Django と nginx を使用し、データベースには PostgresQL を使用しています。
PostgresQL にはいくつかのミラーリング ソリューションがありますが、「3 つのマスター」スキーマを使用して静的ファイルをミラーリングする最適な方法は何でしょうか。
単に rsync するだけでは、スケーラブルでメンテナンスが容易な方法ではないと思います。
答え1
ファイルが頻繁に変更されず、常に同期を保つ必要がある限り、rsync を使用しないのはなぜでしょうか? ファイルを編集するマスター サーバーが 1 つあることを確認するだけで、同期が容易になります。
それ以外では、NFSのようなネットワークファイルシステムが機能するか、次のようなものを実装します。DRBDファイルを常に同期した状態に保つためです。
答え2
他にも多くのソリューション (afs、unionfs など) がありますが、rsync は一方向のレプリケーションでは驚くほどうまく機能し、自己修復機能も備えています。また、レプリケーションのパスを定義すると拡張可能になります (1 つのマスターで最大 5 台程度のスレーブには対応できますが、それを超えると複数層のレプリケーションに移行する十分な理由があると考えられます)。
唯一の問題は、レプリケーションのタイミングです。ラウンドロビン DNS を使用しているため、既にサーバー アフィニティが存在します。そのため、ユーザーがサーバー A を更新した後、サーバー B を参照しているために更新が表示されないという問題は発生しません。ただし、コードの伝播の遅延により、展開に問題が生じる可能性があります (特に、共通データベースへの DDL 変更にコードが依存している場合)。
双方向レプリケーションが必要な場合（可能な限り避けるようにしてください）、リアルタイム レプリケーション システムの方が適切です。
現在、rsync を手動または cron 経由で実行している場合は、遅延が非常に短くなるように、ファイルが変更されたときに inotify を使用して rsync を実行することを検討してください。
C.
答え3
コードを本番環境にデプロイする場合、すべてのサーバーに一度にデプロイする必要があります。このアクションが適切に制御されていれば、コントロールの一部としてミラーリングされるため、テクノロジ ソリューションは不要になります。すべての管理ソリューションがテクノロジに基づいているわけではありません。
オープンEFSは、変更管理とデプロイメントを可能にするために設計されたツールであり、役に立つかもしれません。私は、このツールの機能の多くを自分で実装しましたが、基礎知識のない人にとっては、良いスタートとなるでしょう。
変更管理の対象外の静的サーバーの場合、過去にrsyncが適切なソリューションであることが分かりました。通常、このカテゴリに該当するサーバーではスケーリングが問題になる可能性は低いですが、問題になる場合はNFSまたはオーストラリアが作用するかもしれない。