どのネットワークファイル共有プロトコルが最高のパフォーマンスと信頼性を備えていますか？
負荷分散されているいくつかのWebサーバーの設定があります。すべてのWebサーバーがアクセスできるある種のネットワーク共有ストレージが必要です。ユーザーがアップロードしたファイルを保存する場所として使用されます。すべてがLinuxを実行しています。
NFS、CIFS、SMB、Fuse + sftp、Fuse + ftpを使用する必要がありますか？ネットワークファイル共有プロトコルには非常に多くの選択肢があり、どれを選ぶかは非常に困難です。基本的には、この1つの共有を複数のマシンに永続的にマウントしたいだけです。セキュリティ機能は、それをマウントしているサーバー以外からはネットワークにアクセスできないため、それほど心配する必要はありません。私たちは、それが確実かつ迅速に機能することを望んでいます。
どちらを使用すればよいですか？
NFSに投票します。
NFSv4.1は、並列データアクセスを可能にするParallel NFS pNFS機能を追加しました。パフォーマンスの数値に基づいて、Unixに似ている場合に限り、どのようなクライアントがストレージを使用しているのでしょうか。
短い答えはNFSを使用することです。これ shootout と私自身の経験によれば、より高速です。
しかし、より多くのオプションがあります！クラスタを検討する必要がありますFS GFSのように、複数のコンピュータが同時にアクセスできるファイルシステムです。基本的に、GFSファイルシステムであるiSCSIを介してブロックデバイスを共有します。すべてのクライアント（iSCSIのイニシエータ用語）は読み取りと書き込みができます。Redhatには ホワイトペーパー があります。OracleのクラスタFS [〜＃〜] ocfs [〜＃ 〜] 同じことを管理します。
レッドハットペーパーは、クラスターの長所と短所を一覧にした優れた成果を上げていますFS vs NFS。基本的に、拡張するスペースを多く必要とする場合、GFSはおそらく努力する価値があります。また、GFS例では、ファイバーチャネルSAN=を例として使用していますが、これはRAID、DAS、またはiSCSI SANと同じくらい簡単にできます。
最後に、必ずジャンボフレームを調べてください。データの整合性が重要な場合は、ジャンボフレームでiSCSIを使用する場合はCRC32チェックサムを使用してください。
2つのサーバー負荷分散Webクラスターがあります。サーバー間でコンテンツを同期するために次の方法を試しました。
- [〜＃〜] rsync [〜＃〜]で同期された各サーバーのローカルドライブ= 10分ごと
- 中央CIFS（SAMBA）両方のサーバーへの共有
- 中央[〜＃〜] nfs [〜＃〜]両方のサーバーに共有
- 共有SAN実行中のドライブOCFS2両方のサーバーをマウント
[〜＃〜] rsync [〜＃〜]ソリューションが最も単純でしたが、変更が表示されるまでに10分かかり、RSYNCはサーバーに負荷をかけすぎたため、カスタムで調整する必要がありました毎秒一時停止するスクリプト。また、ソースドライブへの書き込みのみに制限されていました。
最も高速に実行された共有ドライブは、異常な状態になり、クラスターがクラッシュするまでOCFS2クラスター化ドライブでした。 OCFS2では安定性を維持できませんでした。複数のサーバーが同じファイルにアクセスするとすぐに、負荷が屋根を通って上昇し、サーバーが再起動し始めます。これは私たちのトレーニングの失敗かもしれません。
次善の策は[〜＃〜] nfs [〜＃〜]でした。非常に安定しており、フォールトトレラントです。これが現在の設定です。
SMB（CIFS）にはロックの問題がありました。特に、SMBサーバー上のファイルへの変更はWebサーバーに表示されませんでした。SMBは、SMBサーバー
私たちの結論は、OCFS2が最も可能性が高いが、実稼働で使用する前に多くの分析が必要であるということでした。簡単で信頼できる何かが必要な場合は、フェイルオーバー用にハートビートを備えたNFSサーバークラスターをお勧めします。
私はあなたにPOHMELFSをお勧めします-それはロシアのプログラマーEvgeniy Polyakovによって作成され、それは本当に、本当に速いです。
信頼性とセキュリティの観点から、おそらくCIFS（別名Samba）ですが、NFSははるかに軽量であるように見えます。慎重に構成すると、ネットワーク上の他のすべてのマシンに貴重なデータを完全に公開できない可能性があります;-)
フューズのものに対する侮辱はありませんが、私が何を意味するかを知っていれば、それはまだ...新鮮だと思われます。まだ信頼できるかどうかはわかりませんが、それは私が古いフォギーであるだけの可能性がありますが、貴重なエンタープライズデータに関しては、古いフォジェリズムが時々正当化されます。
1つの共有を複数のマシンに永続的にマウントし、奇妙な点（主にUID/GIDの問題）に対応できる場合は、NFSを使用します。長年使っています。
NFS。それは試みられ、本当であり、あなたは堅実なセットアップを持つことができます。 GFSのパフォーマンスは、特に多数の小さなファイルを含むファイルシステムでは、一般にひどいものです。私はOCFSを使用したことはありませんが、通常、クラスターファイルシステムの概念に不満を感じています。それからLustreがありますが、それはワームの別の缶です...
少し遅れる可能性があります。クラスターデュアルポートを備えたMD3220デルストレージを使用しています。ユニットに2つのコントローラーがあり、1つがダウンした場合、問題が解決するまで稼働し続けます。 HDD、FAN、電源、コントローラはすべてホットスワップなので、部品の出し入れを行っています。フォーマットの時点では、NFSを使用しています。
NFSはお勧めしません。簡単に言うと、JBoss、Apache、Tomcat、Oracleのすべてが共通の構成ファイルとログにNFS共有を使用するWebサーバーファームがありました。
NFS共有が消えたとき（確かにまれに発生したことです）、すべてが崩壊しました（実際に予測可能で、この構成時のショートカットに対して「開発者」に助言しました）。
私たちが使用していたNFSのバージョンに問題があるようです。書き込み中にターゲットが消えた場合、クライアントは、NFSターゲットが返ってくるのを待って、終わることのない待機ループに陥ります。 NFSボックスが再接続された場合でも、ループはまだ終了していません。
RHEL 3、4、5を組み合わせて使用していました。ストレージはRHEL4にあり、サーバーはRHEL5にあり、ストレージネットワークは独立したLANであり、VLANで実行されていません。
負荷分散されたフロントエンドがある場合、単一のストレージをチェックします-これはシステムのボトルネックになりませんか？
ファイルのアップロード時に、ftp/scpを介してアップロードされたファイルをストレージに移動するイベント駆動型スクリプトを使用して、ストレージへの読み取り専用のiSCSI接続を検討しましたか？
複数の読み取りヘッドに対して成功した集中型ストレージを実装したのは、EMCストレージアレイ上だけでした。他のすべての費用対効果の高い試みには欠点がありました。
GFSを検討しましたか？ GFSはクラスターファイルシステムであり、私の経験では、かなり信頼できます。それは複数のジャーナルを持つことができ、それはかなりよくスケーリングします
しかし、いくつかのクラスターサービスをインストールする必要があり、GFSはその高速性について正確に認識されていません。音、それは私にとって常に十分高速でしたが、ymmv。
分散FSはGFSのようであり、iSCSIはやりすぎです。
単純にしたい場合は、NFSを使用してください。シンプルかつ高速で、ソフトマウントはかなり頑丈です。また、それに伴うすべてのロックジャンクを無効にすることを検討してください。私はすべてのホームディレクトリとアプリケーションをNFSから取得するLinuxデスクトップを持っています。
途方もない速度が必要な場合は、Lustreを使用してください。LFSは、GFSよりもはるかに簡単にセットアップでき、RAID NFSによく似ています。クラスターにはLustreを使用します。
NFSのシンプルな回答+1。私は何年もの間問題なく一気にマウントされたNFS共有を持っています。
優れた信頼性を求めている場合は、分散自動フェイルオーバーNFSファイルシステムの場合と同様に、DRBDを混在させることを検討してください。
他の唯一のオプション（私が精通しているもの）はiSCSIですが、構成するのが難しい場合があります...
大規模なサーバーファームでは、数百万のユーザーが作成したHTMLページがありました。 NFSはうまく機能しなかったので、mysqlテーブルに入れました。ディレクトリツリーをトラバースする場合と比較して、オーバーヘッドはほぼ同じでした。
私は、NFSがおそらくあなたの最善の策（奇妙に聞こえるかもしれません）ですが、NFSに対する警告をエコーします。
NFSサーバーが消え、NFSサーバーがなくなったためにクライアントが（カーネル内で）ロック解除またはシャットダウンを拒否したため、ACから切断してシャットダウンしなければならないNFSクライアントがありました。
それを正しく行うには、NFSv4を徹底的に主張し、TCP接続を使用し、ジャンボフレームを使用し、NFSクラスターを使用します。NFSサーバーを非表示にすることはできません。
あなたはさまざまなコストでたくさんのオプションを持っています。 Shared SAN FC、iSCSI、または最近追加されたものの1つ。いずれの場合も、セットアップにコストがかかる可能性があり、クラスタ対応のファイルシステムを実行する必要があります。クラスタ化されたファイルシステムは世界成功の望みには、クラスター通信とデータ用に別の高速、低遅延のネットワークが必要です。それでも、ノードがリングフェンスされて強制終了されるグリッチが発生する可能性があります。
手間をかけずに機能する唯一のクラスターファイルシステムはVMFSです。しかし、それは非常に専門的であり、たとえそれが一般的な使用のために利用可能であったとしても、それは役に立たないでしょう。
NFSは、おそらくセットアップのための方法です。回復力が心配な場合は、適切なクラスター化されたNFSボックスを取得する必要があります。あなたは自作のセットアップを行うことができますが、上記の問題にぶつかります。最善策（お金がある場合）は、クラスター化されたNetAppファイラーです。これは費用のかかるオプションですが、実際にはクラスタリングは問題なく機能します。それだけでなく、非常に高速です。
GFSは真剣に黒のブードゥー教です。単純な2つのクライアントクラスターを機能させるために必要な作業量は、他の方法に比べて驚異的です。 OCFS2は導入がはるかに簡単ですが、接続されているすべてのサーバーに含まれるカーネルモジュールのバージョンに関しては非常にうるさいので、それはほんの始まりにすぎません。
クラスターファイルシステムが提供する低レベルのアクセスの種類が本当に必要な場合を除いて、NFSまたはCIFSでおそらく十分です。
すでにどこにでもWebサーバーがあり、それらの実行に優れている場合は、WebDAVを検討してみませんか？