このトピックでは、NASでサポートされているネットワークファイルシステム (NFS) プロトコルのバージョン、NFSv3とNFSv4の違い、およびNFSの整合性モデルについて説明します。
NFSとは何ですか?
NFSは、ローカルファイルにアクセスするのと同じ方法で、リモートシステム内のファイルにアクセスできる分散ファイルシステムプロトコルです。
NFSファイルシステムをLinux ECS (Elastic Compute Service) インスタンスおよびコンテナーにマウントすることを推奨します。 Server Message Block (SMB) ファイルシステムをLinux ECSインスタンスおよびコンテナーにマウントすると、互換性の問題が発生する可能性があります。 詳細については、「クロスマウント互換性に関するFAQ」をご参照ください。
プロトコルのバージョン
NFSv2、NFSv3、NFSv4の3つのNFSバージョンがリリースされています。 NFSv4には、NFSv4.0とNFSv4.1の2つのマイナーバージョンが含まれています。
汎用NASファイルシステムはNFSv3とNFSv4.0をサポートしています。
Extreme NASファイルシステムはNFSv3をサポートします。
NFSv3とNFSv4.0の違い
特徴
NFSv4.0は、ファイルロック機能を実装し、ファイルシステムのルートノードを取得できるステートフルプロトコルです。
NFSv3はファイルロックを識別しません。 NFSv3とNFSv4.0の両方を使用してファイルシステムをマウントすると、NFSv4.0を使用して書き込まれたデータが上書きされる場合があります。
セキュリティ
NFSv4.0はセキュリティを強化し、RPCSEC-GSS ID認証をサポートします。
リクエスト
NFSv4.0は、NULLとCOMPOUNDの2つのリクエストタイプのみを提供します。 すべての操作はCOMPOUNDに統合されます。 クライアントは、実際の要求に基づいて複数の操作を1つのCOMPOUND要求にカプセル化して、柔軟性を高めます。
名前空間
NFSv4.0ファイルシステムの名前空間が変更されました。 サーバー上にルートファイルシステム (fsid=0) を設定する必要があり、他のファイルシステムはエクスポート用にルートファイルシステムにマウントされます。
NFSファイルシステムの制限の詳細については、「プロトコルの制限」をご参照ください。
NFSキャッシュアプリケーション
従来のディスクでは、すべてのデータがページキャッシュにキャッシュされ、変更されたページはサーバーに非同期にフラッシュバックされます。 従来のディスクのレイテンシは低い。 ただし、NFSファイルシステムでは、NFSは新しく作成されたファイルや新しく書き込まれたコンテンツをページキャッシュにキャッシュせず、できるだけ早くNASサーバーにフラッシュします。 したがって、複数のECSインスタンスがNFSファイルシステムを共有する場合、すべてのNAS操作でディスク操作よりもオーバーヘッドが発生します。 このオーバーヘッドは一般に100〜1 msである。 できるだけ早くデータをNASサーバーにフラッシュするために、NASは次のマルチノード整合性モデルを提供します。
タイムアウトベースの最終的な整合性モデル
NFSは、ディレクトリまたはファイルの属性 (FileAttr) をキャッシュします。 オペレーティングシステムは、FileAttrが変更されたかどうかに基づいて、他のECSインスタンスでディレクトリまたはファイルが変更されたかどうかを判断します。 さらに、FileAttrがロードされた後、オペレーティングシステムは、時間T内に有効なキャッシュ (たとえば、ファイルのコンテンツまたはディレクトリ内のファイルリスト) を考慮する。時間Tの後、オペレーティングシステムは、サーバからFileAttrを再び取得する。 FileAttrが変更されていない場合、オペレーティングシステムはファイルまたはディレクトリに関連するすべてのキャッシュが有効であると見なします。
Tは適応値である。 デフォルト値: 1s〜60s。
ファイルコンテンツキャッシュ: ファイルのコンテンツをキャッシュします。
サブディレクトリキャッシュ: ディレクトリに存在するファイルとディレクトリに存在しないファイルをキャッシュします。
ファイルコンテンツキャッシュの例:
ECS-1はファイルXの0〜4 KBを読み取ります: ECS-1はファイルの内容を初めて読み取りますが、その内容はキャッシュに存在しません。 ECS-1はサーバーからコンテンツを読み取り、ローカルにキャッシュします。
ECS-2は0〜4 KBのファイルXを更新します。ECS-2はサーバーにデータを書き込み、FileAttrのmtimeを更新します。
ECS-1は、ファイルXの0〜4 KBを再び読み取る: 第2の時間ECS-1がファイルXの0〜4 KBを読み取り、第1の時間ECS-1がファイルXの0〜4 KBを読み取る間の時間間隔が時間T未満である場合、FileAttrは満了していない。 この場合、ECS-1は、キャッシュ内のファイルXの0〜4 KBを直接読み取る。
ECS-1は3回目に0〜4 KBのファイルXを読み取ります。3回目のECS-1で0〜4 KBのファイルXを読み取り、1回目に0〜4 KBのファイルXを読み取るまでの時間間隔が時間Tより大きい場合、ECS-1はサーバーから新しいFileAttrを取得し、mtimeが変更されたことを確認します。 この場合、ECS-1はキャッシュ内のデータを破棄し、サーバーからデータを読み取ります。
サブディレクトリキャッシュの例:
ECS-1は /aを検索しようとします。ECS-1は、最初の検索でaが存在しないことを検出します。 ECS-1は、aが /ディレクトリに存在しないという情報をキャッシュします。
ECS-2サブディレクトリ /aを作成します。
ECS-1は /aを再度検索しようとします。2回目のECS-1で /aを検索してから1回目のECS-1で /aを検索するまでの時間間隔が時間T未満の場合、ECS-1はキャッシュを直接使用し、サブディレクトリが存在しないことを通知します。
ECS-1が /aを3回目に検索しようとします。3回目のECS-1で /aを検索してから1回目のECS-1で /aを検索するまでの時間間隔が時間Tより大きい場合、ECS-1は /サブディレクトリの最新のFileAttrを取得し、mtimeが変更されたことを確認します。 この場合、ECS-1はキャッシュ内のデータを破棄し、サーバー上で /aを検索します。
NFSによって提供されるタイムアウトベースの最終的な整合性モデルの詳細については、「NFS」をご参照ください。
ファイルベースのclose-to-open (CTO) 整合性モデル
タイムアウトベースの最終的な一貫性モデルは、ECS-2がECS-1によって書き込まれたデータをすぐに読み取ることを保証できません。 したがって、一貫性を向上させるために、NFSはファイルベースのCTO一貫性モデルを提供します。 2つ以上の計算ノードが同時に同じファイルからデータを読み取り、または同じファイルにデータを書き込む場合、ECS-1によって行われた変更は、ECS-2によってすぐに読み取られない可能性があります。 ただし、ECS-1がファイルを開き、ファイルにデータを書き込み、ファイルを閉じた後、任意の計算ノードでファイルを再度開くと、新しく書き込まれたデータへのアクセスが保証されます。
たとえば、プロデューサーECSインスタンスはファイルXを生成し、close操作を実行します。 次に、プロデューサーECSインスタンスはメッセージXをmessage Queueに送信し、ファイルXが作成されたことを通知します。 Message QueueにサブスクライブしたコンシューマECSインスタンスは、メッセージXを読み取ります (ファイルXが作成されました) 。 次に、コンシューマECSインスタンスはファイルに対してopen操作を実行し、open操作によって返されたfdを使用してファイルを読み取ります。 これにより、コンシューマECSインスタンスはファイルXのすべてのコンテンツを確実に読み取ることができます。コンシューマECSインスタンスがファイルXに対してopen操作を実行し、プロデューサECSインスタンスがファイルの作成を完了する前にfdを取得したとします。 この場合、コンシューマECSインスタンスは、メッセージXの受信後にfdを直接使用して最新のファイルコンテンツを読み取ることができない場合があります。
ファイルの作成およびファイルへのデータの書き込みの待ち時間を解決する方法については、NFSファイルシステムでファイルを作成する際の待ち時間を解決するにはどうすればよいですか? とNFSファイルシステムにデータを書き込む際の待ち時間を解決するにはどうすればよいですか?