解決策 1:
必要に応じて、これを行う方法は複数あります。
- ウェブサーバー上の fx NFS でマウントされた中央ファイル サーバーを使用する
- 上記と同じですが、冗長なので、一方がダウンすると、もう一方が引き継ぎます
- ある種の同期ツール (rsync など) を使用して、ファイルをウェブサーバー上でローカルにホストします。次に、特定の間隔でサーバー間でファイルを同期するように cron ジョブをセットアップします。
- Amazon S3、Akamai などの CDN を使用する
多くの新しいファイルが来る場合は、最初の 2 つが最適です。 3 番目は、まだ同期されていない静的コンテンツでユーザーが 404 を取得するため、頻繁にファイルを追加または変更しない場合に理想的なソリューションです..
最後のオプションは多くの点で理想的かもしれませんが、4 つのオプションの中で最もコストがかかる場合もあります。これをサポートするには、Web サイトを書き直す必要もあります。
解決策 2:
Web サーバーの負荷を減らし、負荷分散を実行するもう 1 つの優れた方法は、squid (すなわち squid3) を使用することです。キャッシング付きのリバース プロキシとして設定します。そのように設定すると、画像などの静的コンテンツが HDD (デフォルト) または RAM (高速で最適) にキャッシュされます。特定のノードが過負荷になった場合、他の Squid サーバーへのラウンド ロビンも可能です。
解決策 3:
私が採用したこの課題に対する 1 つの解決策は、ファイルのメインの読み取り/書き込みコピーを共有 NFS ドライブに置き、各 Web サーバーに読み取り専用コピーを保持して、NFS ホストの障害がファイル アクセスを停止するようにすることです。それらを完全に失うのではなく、読み取り専用モードで。
- ファイルは中央ホストに存在し、NFS マウントを介してウェブホストと共有されます
rsync各ウェブホストの読み取り専用コピーを最新の状態に保つために、15 分間実行されます。- A
check_linkbash スクリプトは毎分実行され、NFS マウントがまだそこにあることを確認し、そうでない場合は読み取り専用コピーへのシンボリック リンクをスワップします。
このシステムを最初にセットアップしたときの詳細については、この記事を参照してください。
利点:
- ファイル読み取りの可用性が高い
- ファイル書き込みの競合状態なし
- 新しいファイルは、すべてのウェブ ホストですぐに利用できます。
欠点:
- 少し複雑です。
- 読み取り専用コピーの数は、ウェブホストの数に比例します。2 つ以上のホストがある場合は、過剰になる可能性があります。
- ファイル書き込みは高可用性ではありません。
- 読み取り専用コピーに切り替える前に最大 1 分間のダウンタイムが発生する可能性があります。