Azure NetApp Files のファイル ロックとロックの種類について
NAS 環境では、複数のクライアントが同じボリューム内のファイルにアクセスします。 NAS ボリュームはアプリケーション側の事情を認識できません。このため、同時に複数のクライアントによって同じファイルへの書き込みが試みられた場合にデータの破損を避ける目的で、アプリケーションが NAS サーバーにロック要求を送信し、ファイルの使用中に他のクライアントから変更が加えられることを防ぐ必要があります。 NFS で使用されるファイル ロック メカニズムは、NFS のバージョンによって異なります。
ロックの種類
NFS ロックには以下のような種類があります。
共有ロック: 共有ロックは複数のプロセスで同時に使用できます。ファイルに排他ロックが適用されていない場合に限り発行できます。 共有ロックは読み取り専用操作を想定した機能ですが、書き込みにも使用できます (データベース用途など)。
排他ロック: 排他ロックは、SMB の排他ロックと同じように動作します。排他ロックを適用した場合、1 つのプロセスのみがそのファイルを使用できます。 他のプロセスによってファイルがロックされている場合、そのプロセスをフォークしない限り排他ロックは発行できません。
委任: 委任は NFSv4.x でのみ使用できます。NFS サーバー・オプションが有効で、クライアントが NFSv4.x 委任をサポートしている場合に割り当てられます。 委任を利用すると、クライアントが使用するファイルに "ソフト" ロックをかけ、クライアント側で操作をキャッシュすることが可能になります。 これには、特定のワークロードについてクライアントとサーバーの間で行う呼び出しの回数を減らし、パフォーマンスを向上させる効果があります。SMB の日和見ロックに似た機能です。 現在、Azure NetApp Files では NFSv4.x 委任はサポートされていません。
バイト範囲ロック: バイト範囲ロックでは、1 個のファイル全体ではなくファイルの一部分のみにロックを適用します。
ロックの動作は、ロックの種類、クライアント オペレーティング システムのバージョン、使用している NFS のバージョンによって異なります。 必ず実際の環境でロックをテストし、期待どおりの動作が得られることを確認してください。
NFSv3 のロック
NFSv3 では、NFS クライアントとサーバーの間でファイル ロックの調整を行うために、Network Lock Manager (NLM) や Network Status Monitor (NSM) などの補助プロトコルを使用します。 補助プロトコルは RFC-1813 で定義されており、Azure NetApp Files も同 RFC に準拠しています。
NLM はロックの確立と解放に関するプロトコル、NSM はサーバーの再起動をピアに通知するプロトコルです。 NFSv3 ロックでは、クライアントが再起動した場合、サーバーがロックを解除する必要があります。 サーバが再起動した場合は、クライアントがサーバーに対し、適用していたロックを維持するよう伝えます。
Note
場合によっては (ネットワーク障害が発生した場合など)、NFS ロック メカニズムの伝達が正しく機能せず古いロックがサーバー上に残り、手動でのクリアが必要になることがあります。 このタスクの詳細については、ファイルロックのトラブルシューティングに関するページを参照してください。
NFSv4.x のロック
NFSv4.x では、NFS プロトコルに統合されたリース ベースのロック モデルを使用します。 したがって、補助的なサービスを維持したり確認したりする必要はありません。ロックに関するすべてのやり取りは NFSv4.x 通信に内包されています。
Azure NetApp Files は NFSv4.1 ファイル ロック メカニズムをサポートしており、すべてのファイル ロックの状態をリース ベースのモデルに基づいて維持管理できます。 Azure NetApp Files は、RFC 8881 に規定された、"NFS クライアントによって保持されるすべての状態のために単一のリース期間を定義する。 定義された期間内にクライアントがリースを更新しない場合、サーバーは当該クライアントのリースに関連付けられたすべての状態を解放できる" という動作に準拠しています。
これは、クライアントが明示的に、または暗黙的に (ファイル読み取りなどの操作によって) リースを更新できることを意味します。 それに加え、Azure NetApp Files は猶予期間を定義しています。猶予期間とは、サーバーの復旧時にクライアントがロック状態に対するアクセスの回復を試みることができる特別な処理期間です。
| 任期 | 定義 |
|---|---|
| リース | Azure NetApp Files がクライアントに対し、改変できない形でロックを許可する期間。 |
| 猶予期間 | サーバー障害が発生したとき、サーバーの復旧時にクライアントがロック状態に対するアクセスの回復を試みることができる期間。 |
Azure NetApp Files における NFSv4.x ロック処理のしくみ
ロックは、クライアントからの要求を受けた Azure NetApp Files によって、リース ベースで発行されます。 Azure NetApp Files サーバーは、各クライアントのリースを 30 秒ごとにチェックし、変更を確認します。 クライアントの再起動が発生した場合、そのクライアントは再起動後、サーバー上に適用したすべての有効なロックに対するアクセスを回復できます。 Azure NetApp Files サーバーの再起動が発生した場合、再起動からの 45 秒間は、Azure NetApp Files がクライアントに新しいロックを発行することはありません。 この期間が経過すると、要求元のクライアントにロックを発行できるようになります。 所定の猶予期間中に再確立されなかったロックは、自動的に期限切れになります。 この動作は NFSv3 におけるロックとは異なり、使われなくなったロックが残存して手動での解除が必要になることはありません。
クライアントから手動でロックを適用する
NFS ロックをテストするには、クライアントから NFS サーバーに対し、ロックを適用するよう指示する必要があります。 ただし、すべてのアプリケーションがロックを使用するわけではありません。 たとえば、アプリケーション "vi" はファイルをロックしません。 "vi" の場合は、ドット命名規則による非表示のスワップ ファイルを編集ファイルと同じフォルダーに作成し、アプリケーションの終了時にそのファイルへの書き込みをコミットします。 その後、古い編集ファイルを削除し、スワップ ファイルの名前を編集ファイルの名前に変更します。
とはいえ、手動でロックを適用できるユーティリティも存在します。 たとえば、flock にはファイルをロックする機能があります。
ファイルにロックを適用するには、まず、exec を実行して数値 ID を割り当てます。
# exec 4<>v4user_file
flock を使用し、目的のファイルに対して共有ロックまたは排他ロックを作成します。
# flock
Usage:
flock [options] <file|directory> <command> [command args]
flock [options] <file|directory> -c <command>
flock [options] <file descriptor number>
Options:
-s --shared get a shared lock
-x --exclusive get an exclusive lock (default)
-u --unlock remove a lock
-n --nonblock fail rather than wait
-w --timeout <secs> wait for a limited amount of time
-E --conflict-exit-code <number> exit code after conflict or timeout
-o --close close file descriptor before running command
-c --command <command> run a single command string through the shell
-h, --help display this help and exit
-V, --version output version information and exit
# flock -n 4
ファイルのロックを解除します。
# flock -u -n 4
ファイルを手動でロックすることにより、ファイルを開いて編集する操作のテスト、Azure NetApp Files のロック解除機能のテストを実行できます。