DFSR のレプリケーション対象フィルダーをリネームすると意図せず競合が発生する事象について

Last Update: feedback 共有

※ 本記事はマイクロソフト社員によって公開されております。

こんにちは。Directory Services チームです。

今回は、DFSR によるファイル レプリケーションにおいて、Oplock Lease という機能により意図しない競合が発生する事象についてご案内します。

[1] Oplock 機能について

まず、Oplock 機能について簡単にご説明します。
一般的なネットワーク ファイル システムでは、クライアント側でデータやハンドルをキャッシュすることでネットワーク経路上のトラフィック量の低減を実現しています。しかしながら、同一ファイルに対して同時に複数のクライアントからの参照が行われる状況下で各クライアントそれぞれがキャッシュを保持してしまうと、クライアント間の整合性に問題が生じるため、整合性を保ちながらクライアントがキャッシュを保持する仕組みが必要になります。

SMB では Oplock と呼ばれる便宜的ロック機構にてこのような問題に対処しています。
クライアントがキャッシュを保持したい場合にはクライアントはファイルサーバーに対して Oplock の獲得を要求し、それを受け取ったファイル サーバーは対象のクライアントにキャッシュを保持させても良い状況であるかどうかを確認し、保持させても問題ないと判断するとクライアントに対して Oplock を獲得させます。Oplock を獲得できたクライアントのみがキャッシュを保持できるようにすることで、各クライアント間に整合性の問題が生じないようにします。

また、Oplock Lease は SMB2.1 から実装された新しい Oplock 機構であり、Windows Server 2008 R2 以降の OS において既定で有効となっています。Oplock Lease を実装する目的や動作原理などは Oplock と同じですが、便宜的ロックの獲得粒度をより細かく設定できるようになっており、従来の Oplock よりも各クライアントがキャッシュを保持できる頻度や可能性を高めています。

[2] Oplock Lease 機能による競合発生の流れ

DFS レプリケーションを行っているサーバーにおいて、上記の Oplock Lease 機能により意図せずフォルダーの競合が発生する場合があります。
例として、以下のような流れで事象が発生する場合があります。

  1. ある DFSR サーバーのレプリケート対象のあるフォルダーをリモートからリネームします。
  2. 並行して、その DFSR サーバーのローカルで同じフォルダーをリネームします。
  3. 別の DFSR サーバー側では何も操作を実施していないにも関わらず、そのフォルダーの競合が検知されて情報が失われるという事象が発生します。

リネーム操作を行った DFSR サーバーでは、フォルダー内のすべてのオブジェクトについて、競合を示すイベント ID 4412 が記録されます。

■ リネーム操作を行った DFSR サーバー側のイベント出力例

ログの名前: DFS Replication
ソース: DFSR
日付: 2023/06/01 12:34:56
イベント ID: 4412
タスクのカテゴリ: なし
レベル: 情報
キーワード: クラシック
ユーザー: N/A
コンピューター: DFS01.CONTOSO.COM
説明:
DFS レプリケーション サービスは、ファイルが複数のサーバーで変更されていることを 検出しました。競合解決アルゴリズムを使用して、採用するファイルが決定され、 不採用となったファイルは、競合 (削除済み) フォルダーに移されました。

追加情報:
元のファイル パス: D:\share01\folder1
・・・

また、別の DFSR サーバーではフォルダーに対してイベント ID 4412 が記録されます。

■ リネーム操作を行っていない別の DFSR サーバーのイベント出力例

ログの名前: DFS Replication
ソース: DFSR
日付: 2023/06/01 12:34:56
イベント ID: 4412
タスクのカテゴリ: なし
レベル: 情報
キーワード: クラシック
ユーザー: N/A
コンピューター: DFS02.CONTOSO.COM
説明:
DFS レプリケーション サービスは、ファイルが複数のサーバーで変更されていることを 検出しました。競合解決アルゴリズムを使用して、採用するファイルが決定され、 不採用となったファイルは、競合 (削除済み) フォルダーに移されました。

追加情報:
元のファイル パス: D:\share01\folder1
競合フォルダーでの新しい名前: folder1-{C0929120-8FBC-4B03-A338-C0585D7F8A36}-v4210
レプリケート フォルダーのルート: D:\share01
ファイル ID: {C0929120-8FBC-4B03-A338-C0585D7F8A36}-v4206
レプリケート フォルダー名: share01
・・・

1. のリモートからのフォルダーのリネームは SMB の Oplock Lease 機能によってキャッシュされ、DFSR の USN (Update Sequence Number) はコミットされないため DFSR としてすぐに認識できず、後から実施した 2. のローカルからのフォルダーのリネームは DFSR の USN にすくにコミットされます。このとき、操作が行われていない別の DFSR サーバーには、2. のリネーム処理が先にレプリケートされます。レプリケートされた情報を基に、別の DFSR サーバーではフォルダーのリネーム処理が行われますが、1. の情報がまだレプリケートされてきていないためリネーム後のフィルダーが既に存在しており、競合として検出されてしまいます。そして、この競合を解決するために、このフォルダーと配下のファイルが ConflictAndDeleted フォルダーに退避され、消失したように見えます。

[3] 回避策

この事象は、以下のレジストリを設定することで Oplock Lease 機能を無効化し、回避することができます。

キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
値の名前: DisableLeasing
値の種類: REG_DWORD
値のデータ: 1

もしくは、以下の PowerShell コマンドレットを実行いただくことでも Oplock Lease 機能を無効化することができます。

Set-SmbServerConfiguration -EnableLeasing 0

複数のユーザーでレプリケート対象のフォルダーを操作している DFSR 環境においては、Oplock Lease 機能の無効化をご検討ください。
Oplock Lease 機能を無効化した場合、クライアント側でのキャッシュ利用の効率が若干低下する可能性がございますが、通常、影響はございません。