Azure NetApp Files デュアルプロトコル環境でのアクセス遅延とADチューニング

概要

Azure NetApp Files（ANF）のデュアルプロトコル（NFS/SMB）環境で「ボリュームへのアクセスが遅い」と感じた場合、Active Directory（AD）側の設定が影響している可能性があります。本記事では、ADのuid属性のインデックス作成によるパフォーマンス改善方法を解説します。

• 対象読者
  • Azure NetApp Filesを利用している方
  • デュアルプロトコル環境でアクセス遅延に悩んでいる方
  • AD/LDAPのパフォーマンスチューニングに関心がある方

背景

ANFのデュアルプロトコルボリュームでは、WindowsとLinux間のファイルアクセス時に「名前マッピング」が発生します¹。この際、ADのuid属性をLDAPクエリで検索しますが、uid属性にインデックスが無いと検索が遅くなります²。
これは、特に大規模な環境でアクセス遅延の原因となる場合があります³。

トラブルシューティング時のチェックポイント

1. デュアルプロトコル設定の確認

• Azureポータルでボリュームの「プロトコルの種類」がNFS/SMB両方になっているかを確認します

2. ADスキーマのuid属性インデックス確認と作成

1. ADサーバにログオン
2. PowerShellでスキーマ管理ツールを有効化
   下記コマンド実行後「schmmgmt.dll の DllRegisterServer は成功しました。」のダイアログボックスが表示されればOK

   regsvr32.exe schmmgmt.dll
   

3. mmcで「Active Directory スキーマ」スナップインを追加
4. [属性]からuidを選択し、プロパティで「この属性のインデックスを作成する」にチェック
   

インデックス作成完了はイベントログ「イベントID 1137」で確認できます

3. LDAPクエリの処理時間確認

1. ldp.exeを起動し、バインド
2. [参照] > [検索] から [オプション] を選択
3. 検索オプションの [検索呼び出しの種類] は 拡張 を選択
4. 検索オプションの [コントロール] から Search Stats の定義 (オブジェクト識別子 1.2.840.113556.1.4.970) のみ読み込み
5. 検索条件例
   • ベースDN： 適切な値
   • フィルター： (uid=123)（※ヒットさせる必要はないため、適当なuidでOK）
   • スコープ： サブツリー
   • 属性： *
6. 実行し、Stats項目を確認
   • インデックス作成後は、Used Indexesにuidが表示され、Call Time はほぼ 0ms になります

     Stats項目	説明	備考
     Call Time	実行時間	インデックスがないと遅い
     Entries Returned	ヒット件数	ヒットしない uid 指定時は 0件
     Entries Visited	走査数	インデックスが無いと全件検索になる
     Used Indexes	使用インデックス	未作成時は DNT_index

4. ADパフォーマンスの確認

• パフォーマンスモニターでDirectory ServicesのATQ Request LatencyやATQ Estimated Queue Delayを監視してください
• インデックス作成後に値が 0 付近で推移していることを確認します

まとめ

• ANFデュアルプロトコル環境での遅延は、ADのuid属性のインデックス未作成が原因の可能性があります
• インデックス作成でLDAPクエリの応答が大幅に改善が見込めます
• AD管理者と連携し、インデックス作成を推奨します

参考リンク

• Azure NetApp Files デュアルプロトコル ボリュームのしくみ | Microsoft Learn
• 【Active Directory】 属性にインデックスを付与する方法

1. Azure NetApp Files のデュアルプロトコル ボリュームを作成する | Microsoft Learn ↩

2. Speed up your Active Directory LDAP searches with one simple change | Why Is The Internet Broken? ↩

3. LDAP 属性のインデックス作成について | Microsoft Learn ↩