JavaEnterpriseアプリケーションを複数のサーバーにデプロイしています。負荷分散するために同じアプリケーションを実行している複製サーバーがあります（それらをJ2EEサーバーと呼びましょう）。これはクラスター化されていないことに注意してください。
すべてのアプリケーションに関連するすべてのプロパティファイルをホストする共通サーバー（propsサーバーと呼びましょう）があります。プロパティファイルを含むフォルダーは、他のすべてのJ2EEサーバー間で共有されるNFSです。問題は、propsサーバーが単一障害点であることがわかることです。それが起動しなかった場合、またはNFS共有が破損した場合、他のサーバーはプロパティをロードできません。
この厳しい依存関係を回避するためのオプションは何ですか？プロパティファイルをすべてのサーバーに複製したくないという制約があります。
この問題が発生している場合、よりスケーラブルな解決策は、これを使用することを検討することです。
http://java.sun.com/j2se/1.4.2/docs/guide/lang/preferences.html
これにより、場所などが抽象化されます。次に、これらの設定をLDAPサーバー、複製されたプロパティ、または最適なものに保存できます。環境ごとに異なるメカニズムを使用することもできます。
アプローチの1つは、すべてのJ2EEサーバーに構成ファイルのクローンセットを用意することです。これは、あるサーバーの構成が変更されるたびに、他のすべてのサーバー間でrsyncされる必要があるという制約を意味します（変更がOKであることがわかった後）。
良い面は明らかです。実際にはN台の独立して構成可能なサーバーがあり、構成の変更により1台のサーバーのみが強制終了されます（強制終了の場合）。
マイナス面は、単一のボックスで構成を変更した後、誰かが「rsync」と「bounce」を実行するのを忘れることがあるということです。
プロパティファイルをすべてのサーバーに複製したくないという制約があります。
プロパティを一部のサーバーにコピーしてリーダーを選出し、変更がバックアップに反映されることを確認する場合は、Paxosが最適です。リーダーが失敗した場合、新しいリーダーを選出することができます。ウィキペディアのページを更新しました。アルゴリズムの説明に関するエラーが含まれていました。
PAXOSアルゴリズムを見てください。複数のサーバーをコンセンサスにするように設計されています。