最高のパフォーマンスと信頼性を備えたネットワークファイル共有プロトコルはどれですか?

解決策 1:

私は NFS に投票します。

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

解決策 2:

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

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

Redhat の論文は、クラスター FS と NFS の長所と短所をうまくまとめています。基本的に、拡張する余地がたくさんある場合は、GFS を使用する価値があります。また、GFS の例ではファイバーチャネル SAN を例として使用していますが、それは RAID、DAS、または iSCSI SAN でも同様に簡単です。

最後に、必ずジャンボフレームを調べてください。データの整合性が重要な場合は、ジャンボフレームで iSCSI を使用する場合は CRC32 チェックサムを使用してください。

解決策 3:

サーバー間でコンテンツを同期するために、次の方法を試しました:

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

RSYNC 解決策は最も簡単でしたが、変更が反映されるまでに 10 分かかり、RSYNC はサーバーに非常に多くの負荷をかけ、カスタムスクリプトを使用して 1 秒ごとに一時停止する必要がありました。また、ソースドライブへの書き込みのみに制限されていました。

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

次善は NFS でした .非常に安定しており、耐障害性があります。これが現在のセットアップです。

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

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

解決策 4:

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

解決策 5:

信頼性とセキュリティの点では、おそらく CIFS (別名 Samba) ですが、NFS ははるかに軽量に「見える」ため、慎重に構成すれば、貴重なデータをネットワーク上の他のすべてのマシンに完全に公開することはできません;-)

FUSE を侮辱しているわけではありません。私がそれを信頼しているかどうかはまだわかりませんが、それは単に私が古いフォギーである可能性がありますが、貴重な企業データに関しては、古いフォギー主義が正当化されることがあります。