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

分散ファイル システム名前空間 (一般に DFS 名前空間または DFS-N と呼ばれます) は、運用環境での SMB ファイル共有の展開とメンテナンスを簡略化するために使用される Windows Server サーバーの役割です。 DFS 名前空間は、ストレージ名前空間の仮想化を提供します。これにより、ファイル共有の UNC パスと実際のファイル共有の間に間接参照レイヤーを提供できます。 DFS 名前空間は SMB ファイル共有で動作します。これらのファイル共有がホストされている場所に依存しません。 オンプレミスの Windows ファイル サーバーでホストされている SMB 共有は、Azure File Sync を使用する場合でもしない場合でも、Azure ファイル共有と直接または、Azure NetApp Files、その他のサードパーティのオファリングでホストされている SMB ファイル共有、さらには他のクラウドでホストされているファイル共有と共に使用できます。

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

• データの論理セットに対して、移行に強い名前を提供します。 たとえば、 \\contoso\shares\Engineering を \\OldServer\Engineeringにマップできます。 Azure Files への移行を完了すると、エンド ユーザーがわかりやすい UNC パスにアクセスしたときに Azure ファイル共有パスにシームレスにリダイレクトされるように、マッピングを \\storageaccount.file.core.windows.net\engineering に変更できます。

• Azure File Sync など、異なる物理サイトの複数のサーバーに配布されるデータの論理セットの共通名を確立します。この例では、 \\contoso\shares\FileSyncExample などの名前が、 \\FileSyncServer1\ExampleShare、 \\FileSyncServer2\DifferentShareName、 \\FileSyncServer3\ExampleShareなどの複数の UNC パスにマップされます。 ユーザーがわかりやすい 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 名前空間を使用する方法の例を確認できます。

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

対象

管理モデル	課金モデル	メディア レベル	冗長性	中小企業	ネットワークファイルシステム (NFS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ローカル (LRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ゾーン (ZRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	geo (GRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ジオゾーン (GZRS)
Microsoft.Storage	プロビジョニング済み v1	SSD (プレミアム)	ローカル (LRS)
Microsoft.Storage	プロビジョニング済み v1	SSD (プレミアム)	ゾーン (ZRS)
Microsoft.Storage	従量課金制	HDD (標準)	ローカル (LRS)
Microsoft.Storage	従量課金制	HDD (標準)	ゾーン (ZRS)
Microsoft.Storage	従量課金制	HDD (標準)	geo (GRS)
Microsoft.Storage	従量課金制	HDD (標準)	ジオゾーン (GZRS)

名前空間の型

DFS 名前空間には、次の 2 つの主な名前空間の種類が用意されています。

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

必要条件

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

• Active Directory ドメイン。 これは、オンプレミス、Azure 仮想マシン (VM)、または別のクラウドなど、任意の場所でホストできます。
• 名前空間をホストできる Windows Server。 DFS 名前空間の一般的なパターン展開パターンは、Active Directory ドメイン コントローラーを使用して名前空間をホストすることですが、名前空間は DFS 名前空間サーバーの役割がインストールされている任意のサーバーからセットアップできます。 DFS 名前空間は、サポートされているすべての Windows Server バージョンで使用できます。
• ドメイン参加済みストレージ アカウント内でホストされている Azure ファイル共有や、Azure File Sync を使用してドメインに参加している Windows ファイル サーバーでホストされているファイル共有など、ドメイン参加環境でホストされている SMB ファイル共有。ストレージ アカウントへのドメイン参加の詳細については、「 ID ベースの認証」を参照してください。 Windows ファイル サーバーは、Azure File Sync を使用しているかどうかに関係なく、同じ方法でドメインに参加します。
• DFS 名前空間で使用する SMB ファイル共有は、オンプレミス ネットワークから到達可能である必要があります。 詳細については、 直接アクセスのネットワークに関する考慮事項を参照してください。

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

DFS 名前空間を既に使用している場合、またはドメイン コントローラーで DFS 名前空間を設定する場合は、これらの手順をスキップしても問題ありません。

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

ルート統合で既存のサーバー名を引き継ぐ

DFS 名前空間の重要な用途は、ファイル共有の物理レイアウトをリファクタリングする目的で、既存のサーバー名を引き継ぐ方法です。 たとえば、最新化移行中に、複数の古いファイル サーバーのファイル共有を 1 つのファイル サーバーに統合することができます。 従来、エンドユーザーの知識とドキュメント リンクにより、異なるファイル サーバーのファイル共有を 1 つのホストに統合する機能が制限されます。 ただし、DFS 名前空間のルート統合機能を使用すると、1 つのサーバーを複数のサーバー名に立ち上げ、適切な共有名にルーティングできます。

さまざまなデータ センター移行シナリオに役立ちますが、ルート統合は、クラウドネイティブの Azure ファイル共有を採用する場合に特に便利です。

• Azure ファイル共有では、既存のオンプレミス サーバー名を保持することはできません。
• Azure ファイル共有には、ストレージ アカウントの完全修飾ドメイン名 (FQDN) を使用してアクセスする必要があります。 たとえば、ストレージ アカウント shareのstorageaccountと呼ばれる 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 に含まれる DNS サーバー用であり、Windows AD によって自動的に使用されます。

# 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 名前空間の管理の基本単位は名前空間です。 名前空間ルート (名前) は名前空間の開始点であり、UNC パス \\contoso.com\Public\では名前空間ルートが 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

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

名前空間を便利にするには、フォルダーとフォルダー ターゲットが必要です。 各フォルダーには、そのコンテンツをホストする SMB ファイル共有へのポインターである 1 つ以上のフォルダー ターゲットを含めることができます。 ユーザーがフォルダー ターゲットを持つフォルダーを参照すると、クライアント コンピューターは、クライアント コンピューターをフォルダー ターゲットのいずれかに透過的にリダイレクトする参照を受け取ります。 フォルダー ターゲットのないフォルダーを使用して、名前空間に構造と階層を追加することもできます。

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 は ユーザー 共有のサブフォルダーです)

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

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

こちらもご覧ください

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