Utilisation de DFS Namespaces avec Azure Files

Distributed File Systems Namespaces, communément appelé DFS Namespaces ou DFS-N, est un rôle serveur Windows Server largement utilisé pour simplifier le déploiement et la maintenance des partages de fichiers SMB en production. DFS Namespaces est une technologie de virtualisation des espaces de noms de stockage, ce qui signifie qu’elle vous permet de fournir une couche d’indirection entre le chemin d’accès UNC de vos partages de fichiers et les partages de fichiers eux-mêmes. DFS Namespaces fonctionne avec les partages de fichiers SMB, indépendamment de l’emplacement où ils sont hébergés. Il peut être utilisé avec des partages SMB hébergés sur un serveur de fichiers Windows local avec ou sans Azure File Sync, des partages de fichiers Azure directement, des partages de fichiers SMB hébergés dans Azure NetApp Files ou d’autres offres tierces, et même avec des partages de fichiers hébergés dans d’autres clouds.

À la base, DFS Namespaces fournit un mappage entre un chemin d’accès UNC convivial, par exemple, \\contoso\shares\ProjectX, et le chemin d’accès UNC sous-jacent du partage SMB, comme \\Server01-Prod\ProjectX ou \\storageaccount.file.core.windows.net\projectx. Lorsque l’utilisateur final souhaite accéder à son partage de fichiers, il saisit le chemin d’accès UNC convivial, mais son client SMB accède au chemin d’accès SMB sous-jacent du mappage. Vous pouvez également étendre ce concept de base pour reprendre un nom de serveur de fichiers existant, tel que \\MyServer\ProjectX. Vous pouvez utiliser cette capacité pour réaliser les scénarios suivants :

• Fournir un nom résistant à la migration pour un ensemble logique de données. Dans cet exemple, vous avez un mappage comme \\contoso\shares\Engineering qui correspond à \\OldServer\Engineering. Lorsque vous effectuez la migration vers Azure Files, vous pouvez modifier votre mappage afin que votre chemin d’accès UNC convivial pointe vers \\storageaccount.file.core.windows.net\engineering. Lorsqu’un utilisateur final accède au chemin d’accès UNC convivial, il est redirigé sans heurt vers le chemin d’accès du partage de fichiers Azure.

• Établir un nom commun pour un ensemble logique de données qui est distribué à plusieurs serveurs sur différents sites physiques, par exemple par le biais d’Azure File Sync. Dans cet exemple, un nom tel que \\contoso\shares\FileSyncExample est mappé à plusieurs chemins d’accès UNC tels que \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName ou \\FileSyncServer3\ExampleShare. Lorsque l’utilisateur accède à l’UNC conviviale, il reçoit une liste des chemins d’accès UNC possibles et choisit celui qui est le plus proche de lui en fonction des définitions de site Windows Server Active Directory (AD).

• Étendre un ensemble logique de données au-delà de la taille, de l’E/S ou d’autres seuils d’échelle. Cela est courant dans le cas de répertoires d’utilisateurs, où chaque utilisateur reçoit son propre dossier sur un partage, ou dans le cas de partages de travail, où les utilisateurs obtiennent un espace arbitraire pour gérer les besoins en données temporaires. Grâce à DFS Namespaces, vous créez un panorama de plusieurs dossiers dans un espace de noms cohérent. Par exemple, \\contoso\shares\UserShares\user1 est mappé à \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 est mappé à \\storageaccount.file.core.windows.net\user2, et ainsi de suite.

Vous pouvez voir un exemple d’utilisation de DFS Namespaces avec votre déploiement Azure Files dans la présentation vidéo suivante. Notez qu’Azure Active Directory est désormais Microsoft Entra ID. Si vous souhaitez obtenir d’autres informations, consultez Nouveau nom pour Azure AD.

Si vous avez déjà mis en place DFS Namespaces, vous ne devez suivre aucune procédure spéciale pour l’utiliser avec Azure Files et Files Sync. Si vous accédez à votre partage de fichiers Azure à partir d’un emplacement local, des considérations de mise en réseau normales s’appliquent. Pour plus d’informations, consultez Considérations relatives aux réseaux Azure Files.

S’applique à

Type de partage de fichiers	SMB	NFS
Partages de fichiers Standard (GPv2), LRS/ZRS
Partages de fichiers Standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Types d’espaces de noms

DFS Namespaces propose deux types d’espaces de noms principaux :

• Espace de noms basé sur un domaine : espace de noms hébergé dans le cadre de votre domaine Windows Server AD. Les espaces de noms hébergés dans le cadre d’AD auront un chemin d’accès UNC contenant le nom de votre domaine, par exemple, \\contoso.com\shares\myshare, si votre domaine est contoso.com. Les espaces de noms basés sur un domaine prennent en charge des limites d’échelle plus importantes et une redondance intégrée via AD. Les espaces de noms basés sur un domaine ne peuvent pas être des ressources cluster sur un cluster de basculement.
• Espace de noms autonome : espace de noms hébergé sur un serveur individuel, non hébergé dans le cadre de Windows Server AD. Les espaces de noms autonomes auront un nom basé sur le nom du serveur autonome, par exemple \\MyStandaloneServer\shares\myshare, où votre serveur autonome s’appelle MyStandaloneServer. Les espaces de noms autonomes prennent en charge des cibles d’échelle de moindre envergure que les espaces de noms basés sur un domaine, mais ils peuvent être hébergés en tant que ressource cluster sur un cluster de basculement.

Configuration requise

Pour utiliser DFS Namespaces avec Azure Files et File Sync, vous devez disposer des ressources suivantes :

• Domaine Active Directory. Celui-ci peut être hébergé où vous le souhaitez, par exemple localement, sur une machine virtuelle Azure, ou même dans un autre cloud.
• Un serveur Windows qui peut héberger l’espace de noms. Un modèle de déploiement courant pour DFS Namespaces consiste à utiliser le contrôleur de domaine Active Directory pour héberger les espaces de noms. Toutefois, les espaces de noms peuvent être configurés à partir de n’importe quel serveur sur lequel est installé le rôle serveur DFS Namespaces. DFS Namespaces est disponible sur toutes les versions de Windows Server prises en charge.
• Un partage de fichiers SMB hébergé dans un environnement joint à un domaine, tel qu’un partage de fichiers Azure hébergé dans un compte de stockage joint à un domaine, ou un partage de fichiers hébergé sur un serveur de fichiers Windows joint à un domaine à l’aide d’Azure File Sync. Pour plus d’informations sur la jonction de votre compte de stockage à un domaine, consultez Authentification basée sur l’identité. Les serveurs de fichiers Windows sont joints à un domaine de la même façon, que vous utilisiez ou non Azure File Sync.
• Les partages de fichiers SMB que vous souhaitez utiliser avec DFS Namespaces doivent être accessibles à partir de vos réseaux locaux. Cela concerne principalement les partages de fichiers Azure, mais cela s’applique techniquement à tout partage de fichiers hébergé dans le cloud. Pour en savoir plus, consultez Considérations relatives à la mise en réseau pour un accès direct.

Installer le rôle serveur DFS Namespaces

Si vous utilisez déjà DFS Namespaces ou si vous souhaitez configurer DFS Namespaces sur votre contrôleur de domaine, vous pouvez ignorer les étapes ci-dessous en toute sécurité.

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

Reprendre des noms de serveurs existants avec la consolidation de la racine

Une utilisation importante de DFS Namespaces consiste à reprendre un nom de serveur existant dans le but de refactoriser la disposition physique des partages de fichiers. Par exemple, vous pouvez souhaiter consolider les partages de fichiers de plusieurs anciens serveurs de fichiers sur un seul serveur de fichiers lors d’une migration de modernisation. Traditionnellement, la familiarité de l’utilisateur final et la liaison de documents limitent votre capacité à consolider les partages de fichiers à partir de serveurs de fichiers disparates ensemble sur un seul hôte. Toutefois, la fonctionnalité de consolidation de la racine de DFS Namespaces vous permet de mettre en place un serveur unique pour plusieurs noms de serveurs et de router vers le nom de partage approprié.

Bien qu’utile pour différents scénarios de migration de centre de données, la consolidation de la racine est particulièrement utile pour l’adoption de partages de fichiers Azure natifs Cloud, car :

• Les partages de fichiers Azure ne vous permettent pas de conserver les noms de serveurs locaux existants.
• Les partages de fichiers Azure doivent être accessibles par le biais du nom de domaine complet (FQDN) du compte de stockage. Par exemple, un partage de fichiers Azure appelé share dans le compte de stockage storageaccount est toujours accessible via le chemin d’accès UNC \\storageaccount.file.core.windows.net\share. Cela peut prêter à confusion pour les utilisateurs finaux qui attendent un nom court (par ex., \\MyServer\share) ou un nom qui est un sous-domaine du nom de domaine de l’organisation (par exemple, \\MyServer.contoso.com\share).

La consolidation de la racine ne peut être utilisée qu’avec des espaces de noms autonomes. Si vous disposez déjà d’un espace de noms basé sur un domaine pour vos partages de fichiers, vous n’avez pas besoin de créer un espace de noms consolidé à la racine.

Activation de la consolidation de la racine

Activez la consolidation de la racine en définissant les clés de Registre suivantes à partir d’une session PowerShell avec élévation de privilèges (ou à l’aide de la communication à distance 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

Création d’entrées DNS pour les noms de serveurs de fichiers existants

Pour que DFS Namespaces réponde aux noms de serveurs de fichiers existants, créez des enregistrements d’alias (CNAME) pour vos serveurs de fichiers existants qui pointent vers le nom du serveur DFS Namespaces. La procédure exacte de mise à jour de vos enregistrements DNS peut dépendre des serveurs utilisés par votre organisation et de l’utilisation éventuelle d’outils personnalisés pour automatiser la gestion de DNS. Les étapes suivantes concernent le serveur DNS inclus dans Windows Server et utilisé automatiquement par 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

Créer un espace de noms

L’unité de base de la gestion de DFS Namespaces est l’espace de noms. La racine de l’espace de noms, ou nom, est le point de départ de l’espace de noms, de sorte que dans le chemin d’accès UNC \\contoso.com\Public\, la racine de l’espace de noms est Public.

Si vous utilisez DFS Namespaces pour reprendre un nom de serveur existant avec consolidation de la racine, le nom de l’espace de noms doit être le nom du serveur que vous souhaitez reprendre, précédé du caractère #. Par exemple, si vous souhaitez reprendre un serveur existant nommé MyServer, vous devez créer un espace de noms DFS-N appelé #MyServer. La section PowerShell ci-dessous s’occupe d’ajouter le préfixe #, mais si vous créez un espace de noms par le biais de la console Gestion DFS, vous devez ajouter le préfixe, le cas échéant.

# 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

Configurer des dossiers et des cibles de dossier

Pour qu’un espace de noms soit utile, il doit avoir des dossiers et des cibles de dossier. Chaque dossier peut avoir une ou plusieurs cibles de dossier, qui sont des pointeurs vers les partages de fichiers SMB qui hébergent ce contenu. Lorsque les utilisateurs parcourent un dossier avec des cibles de dossier, l’ordinateur client reçoit une référence qui le redirige sans heurt vers l’une des cibles de dossier. Vous pouvez également avoir des dossiers sans cibles de dossier pour ajouter une structure et une hiérarchie à l’espace de noms.

Vous pouvez considérer les dossiers DFS Namespaces comme analogues aux partages de fichiers.

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

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

Maintenant que vous avez créé un espace de noms, un dossier et une cible de dossier, vous devez être en mesure de monter votre partage de fichiers par l’intermédiaire de DFS Namespaces. Si vous utilisez un espace de noms basé sur un domaine, le chemin d’accès complet de votre partage doit être \\<domain-name>\<namespace>\<share>. Si vous utilisez un espace de noms autonome, le chemin d’accès complet de votre partage doit être \\<DFS-server>\<namespace>\<share>. Si vous utilisez un espace de noms autonome avec consolidation de la racine, vous pouvez y accéder directement à l’aide de l’ancien nom du serveur, par exemple \\<old-server>\<share>.

Énumération basée sur l’accès (ABE)

L’utilisation d’ABE pour contrôler la visibilité des fichiers et dossiers dans les partages de fichiers Azure SMB n’est pas un scénario pris en charge. ABE est une fonctionnalité de DFS-N. Il est donc possible de configurer l’authentification basée sur l’identité et d’activer la fonctionnalité ABE. Toutefois, cela s’applique uniquement aux cibles de dossier DFS-N ; cela ne s’applique pas rétroactivement aux partages de fichiers ciblés eux-mêmes. Cela est dû au fait que DFS-N fonctionne par référence, plutôt que comme proxy devant la cible du dossier.

Par exemple, si l’utilisateur tape le chemin \\mydfsnserver\share, le client SMB obtient la référence \\mydfsnserver\share => \\server123\share et effectue le montage dessus.

En raison de cela, ABE fonctionne uniquement dans les cas où le serveur DFS-N héberge la liste des noms d’utilisateur avant la redirection :

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

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

(Où contosouser1 est un sous-dossier du partage users)

Si chaque utilisateur est un sous-dossier après la redirection, ABE ne fonctionnera pas :

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

Voir aussi

• Déploiement d’un partage de fichiers Azure : Planification d’un déploiement Azure Files et Création d’un partage de fichiers.
• Configuration de l’accès au partage de fichiers : Authentification basée sur l’identité et Considérations relatives à la mise en réseau pour l’accès direct.
• Distributed File System Namespaces de Windows Server.