不確定な数のサーバーにまたがってiSCSI経由でマウントされる共有ストレージデバイスに使用するファイルシステムの「最良の選択」を決定しようとしています。
セットアップ:
本質的に、私はこの大きな共有ボリュームを多くのウェブサーバーにマウントできるようにする必要があり、その数は今後も増え続けると期待しています。私たちは過去にNFSを使用してきましたが、パフォーマンスの問題により、他の方法を調べる必要があります。 (NFSチューニングは、特に何百万もの小さなイメージを処理する場合に、時として黒魔術のように感じられます)。
内容を変更できる中央マシンは数台しかないため、通常、デバイスでの書き込みの衝突に関する問題はありませんが、それらをそのようにマウントする場合は、いくつかの方法が必要です。作業中にファイルをロックして、破損しないようにします。以前は、NFSを使用してこれを処理していました。だから今私はクラスター対応のファイルシステムを見ています(私が何かを見逃していない限り、したがってこの投稿)。
これまでのところ、これには2つの主な選択肢がありますが、それらが最適であるかどうかはわかりません。
RHEL Clustering and GFS2-私の環境に自然に適合しているように見えますが、この方法でディストリビューションに「ロックされている」と感じるのは少し警戒心が強いです。別のフレーバーのサーバーを追加する必要がある場合は、他のオプションをすぐに考えなければならないでしょう。ショーストッパーではなく、私の心に。最大の懸念は、クラスターが16ノードのみをサポートするというRHELドキュメントから繰り返し読むことです。その場合、私にとっては十分に拡張されません。これは正確ですか、それとも間違っていますか?
OCFS-OracleのクラスターファイルシステムもGoogleで注目されていますが、あまり詳しくありません。それの最も厄介な側面は、すべてのサーバーをそれに移動する際に多くの混乱を引き起こすUnbreakable Enterprise Kernelを実行しなければならないことです。繰り返しますが、ショーストッパーではありませんが、特にこの方法論を試す場合、その道を進むには説得力のある証拠が必要です。
何か不足していますか?私が使用すべきより良いアプローチはありますか?アーキテクチャを完全に変更して、いくつかの「フロントエンド」サーバーがiSCSIパーティションをマウントし、必要に応じてそれらのサーバーからNFS共有を行えるようにしたり、nginxリバースプロキシを使用してメディアをウェブサーバーに配布したりすることも検討しました。
このシナリオで信頼できる賢いアイデアはありますか?
あなたの場合、私はまだネットワークファイルシステムを使い続けます。あなたはすでにNFSのスケーリング問題に出くわしているので、別のことを検討する時がきました。そこにいくつかの良いオプションがあります:
どちらも現在、クラウドスケールのインフラストラクチャで使用されています。
Gfs2やocfsのような直接マウントファイルシステムには、実際にスケーリングのボトルネックがあります。クロスホストキャッシュコヒーレンシは言うまでもなく、クロスシステムファイルロックの問題はかなり解決が難しく、主要なスケーリングの問題です。 VMwareのVMFSのような他のクラスター化されたファイルシステムでも、同じ理由で最大マウント数が「数十」に制限されています。
NFS以外のネットワークファイルシステムは、非常に大規模な同時実行にスケーリングするように設計されています。上で述べたオプションには、重複と、単一障害点の防止に役立つ分散ボリュームのサポートの両方があります。
SF-CACHEでVXFS(Veritas Storage Fundation)のようなクラスタリング、マルチパス、マルチプレックス、キャッシュをサポートする柔軟で強力なソリューションを使用できます。書き込みの衝突またはfsの破損を改善すると、VXFSのredologを使用してファイルシステムを再構築することができます。また、ハードウェアLUNエラーがある場合は、スクラッチされたディスクグループを再構築することもできます。
PS:+ OCFSは、webappsではなく、Oracle Cluster DATABASE用に設計されています!