Azure Files で DFS 名前空間を使用する方法

分散ファイル システム名前空間 (一般的に DFS 名前空間や DFS-N と呼ばれます) は、運用環境での SMB ファイル共有のデプロイとメンテナンスを簡素化するために広く使われている Windows Server のサーバー ロールです。 DFS 名前空間は、ストレージの名前空間仮想化技術です。つまり、これを使用すると、ファイル共有の UNC パスと実際のファイル共有自体との間に間接的なレイヤーを設けることができます。 DFS 名前空間は SMB ファイル共有で動作し、それらのファイル共有がホストされている場所に依存しません。 Azure File Sync の有無に関係なくオンプレミスの Windows ファイル サーバーでホストされている SMB 共有で、直接 Azure ファイル共有で、Azure NetApp Files や他のサード パーティ オファリングでホストされている SMB ファイル共有で、さらには他のクラウドでホストされているファイル共有でも、使用できます。

根本として、SMB 共有のユーザー フレンドリな UNC パス (\\contoso\shares\ProjectX など) とその基になる UNC パス (\\Server01-Prod\ProjectX や \\storageaccount.file.core.windows.net\projectx など) との間のマッピングが、DFS 名前空間によって提供されます。 エンド ユーザーは自分のファイル共有に移動したい場合、ユーザー フレンドリな UNC パスを入力しますが、その SMB クライアントがアクセスするのは、マッピングの基になる SMB パスです。 この基本的な概念を、既存のファイル サーバー名 (\\MyServer\ProjectX など) の引き継ぎに応用することもできます。 この機能を使用して次のシナリオを実現できます。

• 論理データ セットに、移行の影響を受けない名前を提供する。 この例では、\\OldServer\Engineering に対応する \\contoso\shares\Engineering というマッピングがあるとします。 Azure Files への移行が完了した時点で、ユーザー フレンドリな UNC パスが \\storageaccount.file.core.windows.net\engineering を指すように、そのマッピングを変更することができます。 エンド ユーザーは、ユーザー フレンドリな UNC パスにアクセスすると、Azure ファイル共有のパスにシームレスにリダイレクトされるようになります。

• Azure File Sync を使用するなどして、物理的に異なるサイトにある複数のサーバーに分散されている論理データ セットに共通名を定義する。この例では、1 つの名前 (\\contoso\shares\FileSyncExample など) が複数の UNC パス (\\FileSyncServer1\ExampleShare、\\FileSyncServer2\DifferentShareName、\\FileSyncServer3\ExampleShare など) にマッピングされます。 ユーザーは、ユーザー フレンドリな UNC にアクセスすると、一連の UNC パスの候補が提示され、その中から、Windows Server Active Directory (AD) サイトの定義に基づいて自分に最も近いものを選択することになります。

• サイズや IO などのスケールしきい値を超えて論理データ セットを拡張する。 その一般的な形態としては、共有上で各ユーザーに各自のフォルダーを提供するユーザー ディレクトリや、一時的なデータ ニーズに対応する任意の領域をユーザーに提供する一時的な共有が考えられます。 DFS 名前空間を使用すると、複数のフォルダーを集めて 1 つの名前空間にまとめることができます。 たとえば、\\contoso\shares\UserShares\user1 は \\storageaccount.file.core.windows.net\user1 に、\\contoso\shares\UserShares\user2 は \\storageaccount.file.core.windows.net\user2 に対応するようにマッピングされます。

Azure Files のデプロイに DFS 名前空間を使用する例については、次の概要動画でご覧いただけます。 Azure Active Directory が Microsoft Entra ID になっていることに注意してください。 詳細については、「Azure AD の新しい名前」を参照してください。

DFS 名前空間が既にある場合は、それを Azure Files と File Sync で使うために特別な手順は必要ありません。Azure ファイル共有にオンプレミスからアクセスする場合は、ネットワークに関する通常の考慮事項が適用されます。 詳細については、「Azure Files のネットワークに関する考慮事項」を参照してください。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

名前空間の種類

DFS 名前空間には、主要な名前空間として次の 2 種類があります。

• ドメインベースの名前空間: Windows Server AD ドメインの一部としてホストされる名前空間。 AD の一部としてホストされる名前空間には、ドメイン名を含む UNC パスが割り当てられます。たとえば、ドメインが contoso.com の場合は、\\contoso.com\shares\myshare となります。 ドメインベースの名前空間でサポートされるスケールの上限の方が大きく、また、AD による冗長性が組み込まれています。 ドメインベースの名前空間を、フェールオーバー クラスター上のクラスター リソースにすることはできません。
• スタンドアロンの名前空間: Windows Server AD の一部としてホストされるのではなく、個々のサーバー上でホストされる名前空間。 スタンドアロンの名前空間には、スタンドアロン サーバーの名前に基づく名前、たとえば \\MyStandaloneServer\shares\myshare が割り当てられます。この場合、スタンドアロン サーバーの名前は MyStandaloneServer です。 スタンドアロンの名前空間は、ドメインベースの名前空間に比べてサポートされるスケール ターゲットは低いものの、フェールオーバー クラスター上のクラスター リソースとしてホストすることができます。

必要条件

Azure Files および File Sync で DFS 名前空間を使用するには、次のリソースが必要となります。

• Active Directory ドメイン。 オンプレミスや Azure 仮想マシン (VM)、さらに別のクラウドなど、これはどこにホストされていてもかまいません。
• 名前空間をホストできる Windows Server。 DFS 名前空間のデプロイ パターンとしては、Active Directory ドメイン コントローラーを使用して名前空間をホストするのが一般的ですが、DFS 名前空間サーバー ロールがインストールされていれば、どのサーバーからでも名前空間を設定できます。 サポート対象のすべての Windows Server バージョンで、DFS 名前空間を利用できます。
• ドメイン参加済みの環境でホストされている SMB ファイル共有 (ドメイン参加済みのストレージ アカウント内でホストされている Azure ファイル共有、ドメイン参加済みの Windows ファイル サーバーで Azure File Sync を使用してホストされているファイル共有など)。ストレージ アカウントのドメイン参加の詳細については、ID ベースの認証に関するページを参照してください。 Azure File Sync を使っているかどうかに関係なく、Windows ファイル サーバーをドメインに参加させる方法は同じです。
• DFS 名前空間で使用する SMB ファイル共有にオンプレミスのネットワークから到達可能であること。 これは主に Azure ファイル共有に関する問題ですが、技術的にはクラウドでホストされているすべてのファイル共有に当てはまります。 詳しくは、直接アクセスに関するネットワークの考慮事項に関する記事をご覧ください。

DFS 名前空間サーバー ロールをインストールする

既に DFS 名前空間を使っている場合や、ドメイン コントローラー上に DFS 名前空間を設定したい場合は、これらの手順をスキップしてかまいません。

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

ルート統合によって既存のサーバー名を引き継ぐ

DFS 名前空間の重要な用途として、ファイル共有の物理的なレイアウトをリファクタリングする際に、既存のサーバー名を引き継ぐことがあります。 たとえば、複数の古いファイル サーバーにあるファイル共有を、モダン化に伴う移行の過程で 1 台のファイル サーバーにまとめたい場合があります。 従来、エンド ユーザーの慣れやドキュメントのリンクのため、異なるファイル サーバーのファイル共有を 1 つのホストに統合する機能には限界がありました。 しかし、DFS 名前空間のルート統合機能を使うと、複数のサーバー名に対して 1 つのサーバーを用意し、適切な共有名にルーティングすることができます。

ルート統合は、さまざまなデータ センター移行シナリオで役に立ちますが、次の理由から、クラウドネイティブな Azure ファイル共有の導入で特に有効です。

• Azure ファイル共有では、既存のオンプレミス サーバー名を維持できません。
• Azure ファイル共有には、ストレージ アカウントの完全修飾ドメイン名 (FQDN) でアクセスする必要があります。 たとえば、ストレージ アカウント storageaccount にある share という Azure ファイル共有は常に、\\storageaccount.file.core.windows.net\share という UNC パスでアクセスされます。 これは、短い名前 (\\MyServer\share など) や組織のドメイン名のサブドメインである名前 (\\MyServer.contoso.com\share など) を期待するエンド ユーザーにとって、紛らわしい可能性があります。

ルート統合は、スタンドアロンの名前空間でのみ使用することができます。 ドメインベースの既存の名前空間があり、既にファイル共有に使用している場合、ルート統合された名前空間を作成する必要はありません。

ルート統合を有効にする

管理者特権の PowerShell セッションから (または PowerShell リモート処理を使って) 次のレジストリ キーを設定して、ルート統合を有効にします。

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Value 1

既存のファイルサーバー名の DNS エントリを作成する

DFS 名前空間を既存のファイル サーバー名に対応させるには、DFS 名前空間のサーバー名を指す、既存のファイル サーバーのエイリアス (CNAME) レコードを作成します。 DNS レコードを更新する厳密な手順は、社内で使用されているサーバーや、DNS の管理を自動化する目的で使用されているカスタム ツールによって異なります。 以下の手順は、Windows Server に含まれ、Windows AD によって自動的に使われる DNS サーバーに関するものです。

# Variables
$oldServer = "MyServer"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain
$dfsnServer = "CloudDFSN.$domain"

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias $dfsnServer `
    -ZoneName $domain

名前空間の作成

DFS 名前空間の基本的な管理単位は名前空間です 名前空間のルート (または名前) は、名前空間の起点です。\\contoso.com\Public\ という UNC パスの中で、Public が名前空間のルートとなります。

ルート統合で DFS 名前空間を使って既存のサーバー名を引き継ぐ場合、名前空間の名前は、引き継ぐサーバー名の前に # 文字を付けた名前にする必要があります。 たとえば、MyServer という名前の既存のサーバーを引き継ぐ場合は、#MyServer という名前の DFS-N 名前空間を作成します。 次の PowerShell セクションでは、先頭の # が自動的に追加されますが、DFS 管理コンソールで名前空間を作成する場合はユーザーが適宜追加する必要があります。

# Variables
$namespace = "Public"
$type = "DomainV2" # "Standalone"
$takeOverName = $false # $true

$namespace = if ($takeOverName -and $type -eq "Standalone" -and $namespace[0] -ne "#") { 
    "#$namespace" 
} else { $namespace }
$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -eq "DomainV2") { 
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create share for DFS-N namespace
$smbShare = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbShare)) { New-Item -Path $smbShare -ItemType Directory }
New-SmbShare -Name $namespace -Path $smbShare -FullAccess Everyone

# Create DFS-N namespace
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
$targetPath = "\\$dfsnServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath $targetPath -Type $type

フォルダーとフォルダー ターゲットを構成する

名前空間を有効活用するためには、名前空間にフォルダーとフォルダー ターゲットが必要です。 各フォルダーには、1 つまたは複数のフォルダー ターゲットを割り当てることができます。フォルダー ターゲットは、コンテンツのホストとなる SMB ファイル共有へのポインターです。 フォルダー ターゲットが割り当てられているフォルダーをユーザーが参照すると、クライアント コンピューターに参照が渡され、その参照によって、いずれかのフォルダー ターゲットにクライアント コンピューターが透過的にリダイレクトされます。 フォルダー ターゲットのないフォルダーを使用して、名前空間に構造と階層を追加することもできます。

DFS 名前空間のフォルダーは、ファイル共有と同様のものと考えることができます。

# Variables
$shareName = "MyShare"
$targetUNC = "\\storageaccount.file.core.windows.net\myshare"

# Create folder and folder targets
$sharePath = "$namespacePath\$shareName"
New-DfsnFolder -Path $sharePath -TargetPath $targetUNC

名前空間、フォルダー、フォルダー ターゲットを作成したので、DFS 名前空間を通じてファイル共有をマウントできます。 ドメインベースの名前空間を使用している場合、共有の完全なパスは \\<domain-name>\<namespace>\<share> となります。 スタンドアロンの名前空間を使用している場合、共有の完全なパスは \\<DFS-server>\<namespace>\<share> となります。 ルート統合でスタンドアロン名前空間を使っている場合は、以前のサーバー名 (\\<old-server>\<share> など) を使って直接アクセスできます。

アクセス ベースの列挙 (ABE)

ABE を使用して SMB Azure ファイル共有内のファイルとフォルダーの可視性を制御することは、現在サポートされているシナリオではありません。 ABE は DFS-N の機能であるため、ID ベースの認証を構成し、ABE 機能を有効にすることはできます。 ただし、それが適用されるのは DFS-N フォルダー ターゲットのみで、対象のファイル共有自体にさかのぼって適用されることはありません。 DFS-N は、フォルダー ターゲットの手前にあるプロキシとしてではなく、参照によって機能するためです。

たとえば、「\\mydfsnserver\share」というパスをユーザーが入力した場合、SMB クライアントでは \\mydfsnserver\share => \\server123\share の参照を受け取り、後者に対してマウントします。

そのため ABE が機能するのは、DFS-N サーバーがリダイレクトの前にユーザー名のリストをホストしている場合に限られます。

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1

(contosouser1 は users 共有のサブフォルダー)

各ユーザーがリダイレクト "後" のサブフォルダーである場合、ABE は機能しません。

\\DFSServer\SomePath\users --> \\SA.file.core.windows.net\users

こちらもご覧ください

• Azure ファイル共有のデプロイ: Azure Files のデプロイの計画とファイル共有の作成方法。
• ファイル共有のアクセスの構成: ID ベースの認証と直接アクセスに関するネットワークの考慮事項。
• Windows Server 分散ファイル システムの名前空間