Azure NetApp FilesのSMB oplocks設定は、特別な互換性要件がなければ「System default」のまま運用するのが基本です。System defaultを選択した場合、現時点ではoplocksが有効になります。
一方、古い業務アプリケーションなどがクライアントキャッシュの無効化を要求する場合は、ボリューム単位でoplocksを無効化できるようになりました。新規ボリュームだけでなく既存ボリュームも変更でき、クロスリージョンレプリケーションの宛先には、ソースとは異なる設定を持たせられます。
この機能は、2026年7月30日にAzure Update 568396としてパブリックプレビューが発表されました。対象はSMBボリュームとデュアルプロトコルボリュームです。
Azure NetApp FilesのSMB oplocks設定で変わったこと
今回の更新により、Azure NetApp FilesのSMB Opportunistic Locking、略してoplocksをボリュームごとに構成できるようになりました。
| 項目 | 内容 |
|---|---|
| 公開形態 | パブリックプレビュー |
| 対象プロトコル | SMB、デュアルプロトコル |
| 新規ボリューム | 作成時に設定可能 |
| 既存ボリューム | 作成後に設定変更可能 |
| デフォルト | System defaultが選択され、oplocksは有効 |
| レプリケーション | クロスリージョンレプリケーションの宛先をソースと別設定にできる |
| NFS専用ボリューム | 対象外 |
重要なのは、System defaultは「設定なし」や「無効」を意味しない点です。公式発表では、System defaultを選択した場合もoplocksが有効になると明記されています。
従来からAzure NetApp FilesではSMB oplocksが有効でした。今回の更新は、標準動作を大きく変更するものではなく、必要に応じて有効・無効を明示的に制御できるようにするものです。
SMB oplocksとは
SMB oplocksは、SMBクライアントがファイルの読み取りデータ、書き込みデータ、ハンドル情報などをローカルにキャッシュするための仕組みです。
一般的な動作は次のとおりです。
- クライアントがSMB共有上のファイルを開く
- サーバーが、条件を満たす場合にoplockを許可する
- クライアントが読み取りや書き込みの一部をキャッシュする
- 別のクライアントが競合するアクセスを開始した場合、サーバーがoplockの解除や変更を要求する
- クライアントがキャッシュを反映し、複数クライアント間の整合性を調整する
クライアントが毎回サーバーへ問い合わせる必要が減るため、ネットワーク通信量を抑え、SMBアクセスの性能を改善できます。Azure NetApp Filesでは、従来型のoplocksと、SMB 2.1以降で利用されるlease oplocksがSMBクライアントのキャッシュに利用されます。([Microsoft Learn][1])
oplocksはアクセス権やファイルロックそのものではない
oplocksは、NTFSアクセス許可や共有アクセス許可を変更する機能ではありません。また、「ほかの利用者がファイルを開けないようにする」という意味での排他ロックそのものでもありません。
役割は、あくまでSMBクライアントがどこまでデータやハンドルをキャッシュできるかをサーバーと調整することです。
そのため、次の問題をoplocksの無効化だけで解決しようとするのは適切ではありません。
- NTFSアクセス許可の設定ミス
- 共有アクセス許可の設定ミス
- アプリケーション独自のロックファイル不具合
- ファイルサーバー上での利用を想定していないアプリケーション
- 複数プロセスによる同時更新そのものの設計不良
- SMBセッションやActive Directory認証の問題
アプリケーションで競合やファイル破損が発生している場合は、ベンダーの動作要件を確認したうえで、キャッシュが原因かどうかを切り分ける必要があります。
System default・有効・無効の選び方
Azure NetApp FilesのSMB oplocks設定は、次の基準で選ぶと判断しやすくなります。
| 設定 | 動作 | 適したケース |
|---|---|---|
| System default | 現時点ではoplocksを有効化 | 一般的なSMB共有、特別な要件がない環境 |
| Enabled | oplocksを明示的に有効化 | 構成基準で有効状態を明示したい場合 |
| Disabled | oplocksを無効化 | アプリケーションベンダーが無効化を要求する場合 |
| ソースと異なる設定 | レプリカ宛先だけ別の動作にする | DR環境で接続するアプリやクライアント条件が異なる場合 |
公式ドキュメントでは、SMBボリュームとデュアルプロトコルボリュームの双方について、System defaultではoplocksが有効になること、既存ボリュームでも変更できることが案内されています。(Microsoft Learn)
基本はSystem defaultを選ぶ
次のような一般的な用途では、System defaultを維持するのが妥当です。
- 部門ファイルサーバー
- ドキュメント共有
- 複数ユーザーによる一般的なファイル利用
- 通常のWindowsアプリケーション
- SMBアクセス性能を重視する環境
- oplocksに起因する問題が確認されていない環境
「キャッシュはデータ不整合の原因になりそう」という理由だけで無効化する必要はありません。SMBのoplocksには、ほかのクライアントがファイルへアクセスしたときにキャッシュ状態を調整する仕組みがあります。
oplocksの無効化を検討する条件
無効化を検討するのは、次のいずれかに該当する場合です。
- アプリケーションベンダーの要件に「oplocksを無効化する」と明記されている
- 旧式アプリケーションがSMBクライアントキャッシュを正しく扱えない
- 複数クライアントからの同時利用で、古い内容の読み取りや更新競合が再現する
- 移行元のファイルサーバーでもoplocksを無効化していた
- 有効時と無効時を比較し、無効時だけ問題が解消することを確認できた
特に、共有フォルダー上のファイルを簡易データベースのように直接更新する旧式アプリケーションでは、独自のロック方式とSMBキャッシュが干渉する場合があります。
ただし、oplocksを無効にしても、そのアプリケーションがネットワーク共有上で安全に動作する保証にはなりません。ファイル共有上での利用自体が製品サポート対象かどうかも確認してください。
性能だけを目的に無効化しない
oplocksはネットワーク往復を減らすための機能です。無効化すると、クライアントがサーバーへ問い合わせる回数やデータ転送が増え、一般に次の影響が考えられます。
- ファイルを開く処理が遅くなる
- 小さな読み書きが多い処理で待ち時間が増える
- クライアントとAzure NetApp Files間の通信量が増える
- 高遅延ネットワークで影響が大きくなる
- 同時利用者が多い環境で応答時間が悪化する
oplocksを無効化する目的は性能向上ではなく、特定アプリケーションとの互換性確保です。(Microsoft Learn)
新規SMBボリュームでoplocksを設定する方法
Azureポータルで新しいSMBボリュームを作成する場合は、次の手順で設定します。
- Azureポータルで対象のAzure NetApp Filesアカウントを開きます。
- 対象の容量プールを開きます。
- ［ボリューム］を選択します。
- ［ボリュームの追加］を選択します。
- ［基本］タブでボリューム名、容量プール、クォータ、仮想ネットワーク、委任済みサブネットなどを設定します。
- ［プロトコル］タブを開きます。
- プロトコルとして［SMB］を選択します。
- Active Directory接続と共有名を指定します。
- ［SMB Opportunistic Locking］またはoplocksに関するドロップダウンを確認します。
- System default、明示的な有効化、無効化のいずれかを選択します。
- ［確認および作成］で内容を確認し、ボリュームを作成します。
通常はSystem defaultのままで問題ありません。ベンダー要件がある場合だけ、検証済みの設定へ変更します。公式手順では、SMBボリュームの設定は［プロトコル］タブ内で行い、System defaultが既定で選択されると説明されています。(Microsoft Learn)
新規デュアルプロトコルボリュームの場合
デュアルプロトコルボリュームでも流れは同じです。
- ［ボリュームの追加］を開始します。
- ［プロトコル］タブで［デュアルプロトコル］を選択します。
- NFSv3とSMB、またはNFSv4.1とSMBの組み合わせを選択します。
- セキュリティスタイルやActive Directory接続を設定します。
- oplocksのドロップダウンから設定を選択します。
- 内容を確認して作成します。
デュアルプロトコルボリュームに設定したoplocksは、SMBでアクセスするクライアント側のキャッシュ動作に関係します。NFSクライアントがSMB oplocksを利用するわけではありません。(Microsoft Learn)
既存ボリュームのSMB oplocks設定を変更する方法
今回の機能では、ボリュームを作り直さなくても既存のSMBボリュームとデュアルプロトコルボリュームを変更できます。
Azureポータルでは、次の流れで操作します。
- Azure NetApp Filesアカウントを開きます。
- ［ボリューム］を選択します。
- 対象のSMBまたはデュアルプロトコルボリュームを開きます。
- ボリュームの編集画面、またはプロトコル設定の編集画面を開きます。
- oplocksの現在値を記録します。
- System default、有効、無効のいずれかへ変更します。
- 設定を保存します。
- 代表的なクライアントからSMB共有へ再接続します。
- アプリケーションの読み取り、書き込み、同時利用を確認します。
パブリックプレビュー中はポータル上の項目名や配置が変更される可能性があります。［SMB Opportunistic Locking］、［Opportunistic locks］、［Oplocks］など、SMBプロトコルに関連する設定を確認してください。
変更前に確認しておく項目
既存ボリュームを変更する前に、最低限次の情報を記録します。
| 確認項目 | 記録する内容 |
|---|---|
| ボリューム | NetAppアカウント、容量プール、ボリューム名 |
| プロトコル | SMBまたはデュアルプロトコル |
| 現在の設定 | System default、有効、無効 |
| 利用アプリ | 製品名、バージョン、ベンダー要件 |
| 接続元 | Windows Server、Windowsクライアント、接続台数 |
| 性能基準 | 処理時間、応答時間、スループット、IOPS |
| 障害状況 | エラー内容、再現手順、発生頻度 |
| 戻し方 | 元のoplocks設定と変更担当者 |
設定変更の効果を確認するときは、変更前から接続していたSMBセッションを残したまま比較しない方が確実です。代表クライアントで共有を切断して再接続し、検証条件をそろえます。
カスタムRBACロールを使用している場合
カスタムRBACロールを利用している環境では、ボリュームを作成または更新するために、必要なボリューム更新権限に加えてMicrosoft.Network/virtualNetworks/subnets/read権限が構成されているか確認してください。公式ドキュメントでも、カスタムロールでボリュームを作成・更新する際の必要権限として案内されています。(Microsoft Learn)
クロスリージョンレプリケーションの宛先を設定する方法
クロスリージョンレプリケーションの宛先ボリュームは、ソースボリュームとは独立したoplocks設定を持てます。
つまり、次のような構成が可能です。
| ソース | 宛先 | 想定される運用 |
|---|---|---|
| System default | System default | 本番とDR環境の動作をそろえる |
| Enabled | Disabled | DR側で利用する旧式アプリの互換性を優先する |
| Disabled | System default | DR移行時に標準のキャッシュ動作へ戻す |
| Disabled | Disabled | 本番・DRの双方で同じ互換性要件を維持する |
宛先がソースと独立しているため、ソースの設定変更が宛先にも自動的に反映されると考えないことが重要です。ソースと宛先をそれぞれ確認し、DR手順書にも両方の設定値を記載します。
DR環境ではフェールオーバー後の利用条件で決める
宛先ボリュームの設定は、通常時ではなく、レプリケーションを解除してDR環境を稼働させたときの条件で判断します。
確認するポイントは次のとおりです。
- DR時に接続するアプリケーションは本番と同じか
- DR側のWindowsクライアントやサーバー構成は同じか
- ネットワーク遅延は本番と同程度か
- ベンダーがDR環境にも同じ設定を要求しているか
- フェールオーバー後に性能低下を許容できるか
- フェールバック時に設定を戻す必要があるか
ソースを無効、宛先をSystem defaultにしていると、フェールオーバー後にキャッシュ動作が変わります。意図した構成であっても、DRテストでアプリケーションの動作まで確認してください。
安全に検証するための手順
既存の本番ボリュームでいきなり無効化するのではなく、次の順序で検証します。
現在の状態を基準値として記録する
System defaultまたは有効の状態で、次の値を記録します。
- アプリケーション処理時間
- ファイルを開くまでの時間
- 保存完了までの時間
- 複数クライアントでの同時更新結果
- Azure Monitorで確認できるスループットやIOPS
- Windowsイベントログ
- アプリケーションログ
- 発生しているエラーの回数
無効化が必要な操作を再現する
単純なファイルコピーだけでなく、実際の業務操作を再現します。
例えば、複数端末から同じデータを参照・更新するアプリケーションなら、次のテストが必要です。
- クライアントAで対象データを開く
- クライアントBから同じデータへアクセスする
- 両方から読み取りと更新を行う
- 保存順序を変えて繰り返す
- 古いデータの表示、更新競合、ファイル破損がないか確認する
- アプリケーションを終了して再度開き、保存内容を確認する
性能と互換性を分けて評価する
oplocksを無効化してエラーが消えても、処理時間が大きく悪化する可能性があります。
次のように評価結果を分けて記録します。
| 評価項目 | System default | 無効 | 採用判断 |
|---|---|---|---|
| エラー発生回数 | 5回 | 0回 | 無効が有利 |
| 代表処理時間 | 10秒 | 16秒 | System defaultが有利 |
| 同時更新 | 失敗 | 成功 | 無効が有利 |
| ファイルコピー | 30秒 | 42秒 | System defaultが有利 |
| ベンダーサポート | 対象外 | 対象 | 無効を採用 |
単に「動いた」「遅くなった」ではなく、互換性改善と性能低下の両方を数値化すると、採用判断を説明しやすくなります。
SMB oplocks設定で失敗しやすいポイント
すべてのボリュームを一律で無効化する
一つの旧式アプリケーションに問題があったからといって、一般ファイル共有まで一律で無効化する必要はありません。
設定単位はボリュームです。互換性要件のあるアプリケーション専用ボリュームだけを無効化し、通常の共有はSystem defaultに分ける方が、影響範囲を限定できます。
System defaultを無効と誤解する
System defaultでは、現時点でoplocksが有効になります。無効化したい場合は、無効状態を明示的に選択する必要があります。
レプリカにソース設定が引き継がれると思い込む
クロスリージョンレプリケーションの宛先は独立設定です。ソースだけを確認してDR設計を完了させると、フェールオーバー後に想定外のキャッシュ動作となる可能性があります。
キャッシュ以外の問題までoplocksで直そうとする
認証エラー、アクセス拒否、名前解決、NTFSアクセス許可、SMB暗号化、アプリケーション独自ロックなどは、別の原因として切り分ける必要があります。
oplocksの変更対象は、クライアントキャッシュとの関係が確認できる問題に限定します。
プレビュー機能を無条件で本番へ適用する
SMB oplocksの構成機能は、2026年7月の発表時点ではパブリックプレビューです。Microsoftのプレビュー条件では、プレビュー機能は正式提供前の評価用機能として扱われます。
重要な本番システムに適用する場合は、プレビュー条件、組織の利用基準、ベンダーサポート、変更時の復旧手順を確認してください。(Microsoft Azure)
Azure NetApp FilesのSMB oplocksに関するよくある質問
System defaultではoplocksが有効ですか
はい。Azure Update 568396では、System defaultが既定の選択肢であり、oplocksを有効にすると説明されています。
既存ボリュームを作り直す必要がありますか
いいえ。新規ボリュームだけでなく、既存のSMBボリュームとデュアルプロトコルボリュームでも設定を更新できます。
NFS専用ボリュームでも設定できますか
今回の対象はSMBボリュームとデュアルプロトコルボリュームです。NFS専用ボリュームはSMB oplocksの対象ではありません。
デュアルプロトコルボリュームではNFSにも影響しますか
oplocksはSMBクライアントのキャッシュを制御する機能です。デュアルプロトコルボリュームに設定した場合も、直接の対象はSMBアクセス側です。
ただし、SMBクライアントとNFSクライアントが同じファイルを扱う構成では、アプリケーション全体の同時アクセス試験を行う必要があります。
oplocksを無効にすればデータ破損を防げますか
一律には防げません。キャッシュ処理との相性が原因であれば改善する可能性がありますが、アプリケーションの排他制御や同時更新設計に問題がある場合は、oplocksを無効にしても解決しません。
ソースと宛先は同じ設定にするべきですか
本番とDRで同じアプリケーション、クライアント、運用条件を使用するなら、同じ設定にそろえる方が動作を予測しやすくなります。
異なる設定にする場合は、理由をDR設計書に記録し、フェールオーバーテストで互換性と性能を確認してください。
まずSystem defaultを維持し、必要なボリュームだけ検証する
Azure NetApp FilesのSMB oplocks設定では、次の順序で対応するのが安全です。
- SMBとデュアルプロトコルの既存ボリュームを一覧化する
- 現在のoplocks設定を記録する
- 特別な要件がなければSystem defaultを維持する
- ベンダー要件や再現可能な問題があるボリュームだけ無効化を検証する
- 変更前後の互換性と性能を比較する
- クロスリージョンレプリケーションの宛先を別途確認する
- 元の設定へ戻す手順を用意してから本番へ適用する
今回の更新で、旧式アプリケーションのためにストレージ全体の設計を変更したり、別のボリュームへデータを移行したりする必要は減りました。ただし、oplocksの無効化は標準設定ではなく、互換性問題に対する例外設定として扱うことが重要です。
コメント