どのネットワークファイル共有プロトコルが最高のパフォーマンスと信頼性を備えていますか？[閉まっている]

いくつかのWebサーバーが負荷分散されているセットアップがあります。すべてのWebサーバーがアクセスできる何らかのネットワーク共有ストレージが必要です。ユーザーがアップロードしたファイルを保存する場所として使用されます。すべてがLinuxを実行しています。

NFS、CIFS、SMB、fuse + sftp、fuse + ftpを使用する必要がありますか？ネットワークファイル共有プロトコルには非常に多くの選択肢がありますが、選択するのは非常に困難です。基本的には、この1つの共有を複数のマシンに永続的にマウントするだけです。セキュリティ機能は、それをマウントしているサーバー以外からはネットワークにアクセスできないため、心配する必要はありません。確実かつ迅速に動作することを望んでいます。

どちらを使用する必要がありますか？

NFSに投票します。

NFSv4.1は、並列データアクセスを可能にするParallel NFS pNFS機能を追加しました。Unixのようにしかパフォーマンスの数値に基づいてNFSを使用しないのであれば、どのようなクライアントがストレージを使用しているのだろうかと思います。

簡単な答えはNFSを使用することです。この銃撃戦と私自身の経験によると、より速いです。

しかし、より多くのオプションがあります！GFSのようなクラスターFSを検討する必要があります。GFSは、複数のコンピューターが同時にアクセスできるファイルシステムです。基本的に、GFSファイルシステムであるiSCSIを介してブロックデバイスを共有します。すべてのクライアント（iSCSI用語ではイニシエーター）は、読み取りと書き込みができます。Redhatにはホワイトペーパーがあります。OracleのクラスターFS OCFSを使用して同じことを管理することもできます。

redhatの論文は、クラスターFSとNFSの長所と短所をリストするのに適しています。基本的に、多くのスペースを拡張したい場合、GFSはおそらく努力する価値があります。また、GFSの例では、ファイバーチャネルSANを例として使用していますが、RAID、DAS、またはiSCSI SANでも同じくらい簡単にできます。

最後に、ジャンボフレームを確認します。データの整合性が重要な場合、ジャンボフレームでiSCSIを使用する場合はCRC32チェックサムを使用します。

2つのサーバー負荷分散Webクラスターがあります。サーバー間でコンテンツを同期するために、次の方法を試しました。

• 10分ごとにRSYNCと同期される各サーバーのローカルドライブ
• 両方のサーバーへの中央CIFS（SAMBA）共有
• 両方のサーバーへの中央NFS共有
• OCFS2を実行する共有SANドライブが両方のサーバーをマウントしました

RSYNCのソリューションは、最も簡単だったが、変更が表示されるまでとRSYNCは、我々はそれを毎秒を一時停止するカスタムスクリプトでそれを絞る必要があったサーバー上でそんなに負荷をかけることは10分かかりました。また、ソースドライブへの書き込みのみに制限されていました。

最速のパフォーマンスを発揮する共有ドライブは、OCFS2クラスター化されたドライブで、異常な状態になりクラスターがクラッシュするまでの間でした。OCFS2では安定性を維持できていません。複数のサーバーが同じファイルにアクセスするとすぐに、負荷が屋根を通って上昇し、サーバーが再起動を開始します。これは私たちのトレーニングの失敗かもしれません。

次に良かったのはNFSです。非常に安定しており、耐障害性があります。これが現在の設定です。

SMB（CIFS）にはロックの問題がいくつかありました。特に、SMBサーバー上のファイルへの変更は、Webサーバーからは見えませんでした。SMBは、SMBサーバーのフェールオーバー時にハングする傾向もありました。

私たちの結論は、OCFS2が最も可能性がありますが、実稼働で使用する前に多くの分析を必要とすることでした。簡単で信頼性の高いものが必要な場合は、フェイルオーバー用にハートビートを備えたNFSサーバークラスターをお勧めします。

POHMELFSをお勧めします-これはロシアのプログラマーEvgeniy Polyakovによって作成されたもので、非常に高速です。

おそらく信頼性とセキュリティの観点から、おそらくCIFS（別名Samba）ですが、NFSははるかに軽量であり、慎重に構成すると、貴重なデータをネットワーク上の他のすべてのマシンに完全に公開できない可能性があります;-)

FUSEをto辱することはありませんが、それでも...新鮮なようです。まだ信用できるかどうかはわかりませんが、それは私が古いフォギーである可能性がありますが、貴重なエンタープライズデータに関しては古いフォギーが時々正当化されます。

1つの共有を複数のマシンに永続的にマウントしたい場合に、奇妙なこと（主にUID / GIDの問題）のいくつかと一緒に遊ぶことができる場合は、NFSを使用します。私はそれを使用し、長年持っています。

NFS。それは試された真実であり、堅実なセットアップが可能です。GFSのパフォーマンスは、特に多数の小さなファイルがあるファイルシステムでは特にひどいものです。私はOCFSを使用していませんが、一般的にクラスタファイルシステムの概念に眉をひそめています。次に、Lustreがありますが、それはワームの別の缶です...

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はその速さについて正確にはわかりません。Otoh、それは私にとって常に十分に高速でしたが、ymmv。

GFSのような分散FSを検討するのは気にしないでしょうし、iSCSIはやり過ぎです。

シンプルにしたい場合は、NFSを使用してください。シンプルかつ高速で、ソフトマウントはかなり堅牢です。また、それに伴うすべてのロックジャンクを無効にすることも検討してください。NFSからすべてのホームディレクトリとアプリケーションを取得するLinuxデスクトップがありますが、正常に動作します。

途方もない速度が必要な場合は、GFSよりもセットアップがはるかに簡単で、RAID NFSに非常に似ているLustreを使用してください。クラスターにはLustreを使用します。

クラスタデュアルポートを備えたMD3220デルストレージを使用します。ユニットに2つのコントローラーがあり、1つが2番目にダウンした場合、その問題を解決するまで稼働し続けます。HDD、FAN、電源、コントローラーはすべてホットスワップであるため、部品を交換します。Formatでは、NFSを使用しています。

すでにあらゆる場所にWebサーバーがあり、それらを実行するのが得意であれば、WebDAVを検討してみませんか？

NFSの簡単な回答+1。何年も問題なくマウントされているNFS共有があります。

優れた信頼性を求めているなら、DRBDを分散型の自動フェイルオーバーNFSファイルシステムにも投入することを検討してください。

他の唯一のオプション（私が知っている）はiSCSIですが、設定するのが面倒な場合があります...

さまざまなコストの選択肢がたくさんあります。FC、iSCSI、または最近追加されたいずれかの共有SAN。いずれにせよ、それらはセットアップに費用がかかる可能性がありますが、クラスター対応のファイルシステムを実行する必要があります。クラスター化されたファイルシステムは苦痛の世界です。成功を期待するには、クラスター通信とデータ用に別々の高速、低遅延ネットワークが必要です。その場合でも、ノードがリングフェンスされて強制終了されるグリッチが発生する可能性があります。

手間をかけずに動作する唯一のクラスタファイルシステムは、VMFSです。しかし、それは非常に特殊化されているので、一般的に使用できる場合でも使用できません。

NFSがおそらくセットアップの方法です。復元力が心配な場合は、適切なクラスター化されたNFSボックスを入手する必要があります。自作のセットアップを行うことはできますが、上記の問題が発生します。最善の策は（お金がある場合）、クラスタ化されたNetAppファイラーです。高価なオプションですが、実際にはクラスタリングは簡単に機能します。それだけでなく、非常に高速です。

NFSがおそらく最善の策である（おそらく奇妙に聞こえる）が、NFSに対して与えられた警告をエコーし​​ます。

NFSサーバーが消え、NFSサーバーがなくなったためにクライアントが（カーネル内で）ロック解除またはシャットダウンを拒否したため、ACから切断してシャットダウンする必要があるNFSクライアントがありました。

それを正しく行うには、NFSv4全体を主張し、TCP接続に固執し、ジャンボフレームを使用し、NFSクラスターを使用します。NFSサーバーを消滅させる余裕はありません。

GFSは真剣な黒のブードゥー教徒です。単純な2クライアントクラスターを機能させるために必要な作業量は、他の方法に比べて膨大です。OCFS2はデプロイがはるかに簡単ですが、接続されているすべてのサーバーに関係するカーネルモジュールバージョンに関しては非常に注意が必要です。これはほんの始まりに過ぎません。

クラスタファイルシステムが提供する低レベルのアクセスの種類が本当に必要な場合を除き、おそらくNFSまたはCIFSで十分です。

大規模なサーバーファームでは、数百万のユーザーが作成したhtmlページがありました。NFSはそれほどうまく機能しなかったため、最終的にmysqlテーブルに入れました。ディレクトリツリーの横断と比較したオーバーヘッドはほぼ同じでした。

私はSFTPを使用しましたが、私の目的にはうまく機能しました-NFSは私の最初の手段でしたが、ユーザー/グループIDのファンキーさから、私はそれをかなり早く落としました。

publickey authをセットアップするだけで、大部分が設定されます。SSH暗号化には多少重いCPUオーバーヘッドがあるかもしれませんが、プラス面ではデータ破損の問題に遭遇したことはありません。

FTPはより軽量であるため、目的に適しています。おそらく、Webサーバーがsshの作業ではなく、Webサービスを実行することを望んでいます。