Planification d’un déploiement de synchronisation de fichiers Azure

Azure File Sync est un service qui permet de mettre en cache plusieurs partages de fichiers Azure sur un serveur Windows local ou une machine virtuelle cloud.

Cet article vous présente les concepts et fonctionnalités d’Azure File Sync. Une fois que vous êtes familiarisé avec Azure File Sync, vous pouvez consulter le Guide de déploiement Azure File Sync pour tester ce service.

Les fichiers sont stockés sur le cloud dans les partages de fichiers Azure. Les partages de fichiers Azure peuvent être utilisés de deux façons : en montant directement ces partages de fichiers Azure serverless (SMB), ou en mettant en cache les partages de fichiers Azure en local avec Azure File Sync. L'option de déploiement que vous choisissez détermine les aspects à prendre en compte lors de la planification de votre déploiement.

• Montage direct d’un partage de fichiers Azure : étant donné qu’Azure Files fournit un accès SMB, vous pouvez monter des partages de fichiers Azure localement ou dans le cloud à l’aide du client SMB standard disponible sous Windows, macOS et Linux. Étant donné que les partages de fichiers Azure sont serverless, le déploiement pour les scénarios de production ne nécessite pas la gestion d’un serveur de fichiers ni d’un périphérique NAS. Concrètement, cela signifie que vous n'avez aucun correctif logiciel à appliquer ni aucun disque physique à remplacer.

• Mise en cache d'un partage de fichiers Azure localement à l'aide d'Azure File Sync : Azure File Sync vous permet de centraliser les partages de fichiers de votre organisation dans Azure Files, tout en conservant la flexibilité, le niveau de performance et la compatibilité d'un serveur de fichiers local. Azure File Sync transforme une instance Windows Server locale (ou cloud) en cache rapide de votre partage de fichiers Azure.

Concepts de gestion

Un déploiement Azure File Sync repose sur les trois objets de gestion suivants :

• Partage de fichiers Azure : un partage de fichiers Azure est un partage de fichiers cloud serverless qui fournit le point de terminaison cloud d'une relation de synchronisation Azure File Sync. Les fichiers d'un partage de fichiers Azure sont directement accessibles via le protocole SMB ou FileREST, mais lorsque le partage de fichiers Azure est utilisé avec Azure File Sync, il est préférable de privilégier un accès aux fichiers via le cache de Windows Server car le mécanisme de détection des modifications d'Azure Files est moins efficace que celui de Windows Server. Par conséquent, les modifications directement apportées au partage de fichiers Azure mettent du temps à se propager jusqu'aux points de terminaison de serveur.
• Point de terminaison de serveur : emplacement de l'instance de Windows Server qui est synchronisé avec un partage de fichiers Azure. Il peut s'agir d'un dossier spécifique ou de la racine d'un volume. Plusieurs points de terminaison de serveur peuvent coexister sur un même volume si leurs espaces de noms ne se chevauchent pas.
• Groupe de synchronisation : objet qui définit la relation de synchronisation entre un point de terminaison cloud, ou un partage de fichiers Azure, et un point de terminaison de serveur. Les points de terminaison dans un groupe de synchronisation sont synchronisés entre eux. Par exemple, si vous voulez gérer deux ensembles distincts de fichiers avec Azure File Sync, vous créez deux groupes de synchronisation et ajoutez des points de terminaison différents dans chacun de ces groupes.

Concepts de gestion des partages de fichiers Azure

Les partages de fichiers Azure sont déployés dans des comptes de stockage, qui sont des objets de niveau supérieur représentant un pool de stockage partagé. Ce pool de stockage peut être utilisé pour déployer plusieurs partages de fichiers ainsi que d’autres ressources de stockage, telles que des conteneurs d’objets blob, des files d’attente ou des tables. Toutes les ressources de stockage qui sont déployées dans un compte de stockage partagent les limites qui s’appliquent à ce compte de stockage. Pour voir les limites actuelles d’un compte de stockage, consultez Objectifs de scalabilité et de performances d’Azure Files.

Il existe deux principaux types de comptes de stockage que vous allez utiliser pour les déploiements d’Azure Files :

• Comptes de stockage version 2 (GPv2) universels : Les comptes de stockage GPv2 vous permettent de déployer des partages de fichiers Azure sur du matériel Standard/sur disque dur (HDD). En plus de stocker les partages de fichiers Azure, les comptes de stockage GPv2 peuvent stocker d’autres ressources de stockage, telles que des conteneurs d’objets blob, des files d’attente ou des tables.
• Comptes de stockage FileStorage : Les comptes de stockage FileStorage vous permettent de déployer des partages de fichiers Azure sur du matériel Premium/sur disque SSD. Les comptes FileStorage peuvent uniquement être utilisés pour stocker des partages de fichiers Azure. Aucune autre ressource de stockage (conteneurs d’objets blob, files d’attente, tables, etc.) ne peut être déployée dans un compte FileStorage. Seuls les comptes FileStorage peuvent déployer des partages de fichiers SMB et NFS.

Il existe plusieurs autres types de comptes de stockage que vous pouvez rencontrer dans le portail Azure, PowerShell ou l’interface CLI. Deux types de comptes de stockage, BlockBlobStorage et BlobStorage, ne peuvent pas contenir de partages de fichiers Azure. Les deux autres types de comptes de stockage que vous pouvez voir sont les comptes version 1 (GPv1) universels et les comptes classiques, qui peuvent tous deux contenir des partages de fichiers Azure. Bien que les comptes de stockage GPv1 et classiques puissent contenir des partages de fichiers Azure, la plupart des nouvelles fonctionnalités d’Azure Files sont disponibles uniquement dans les comptes de stockage GPv2 et FileStorage. Nous vous recommandons donc d’utiliser uniquement les comptes de stockage GPv2 et FileStorage pour les nouveaux déploiements ainsi que pour mettre à niveau les comptes de stockage GPv1 et classiques s’ils existent déjà dans votre environnement.

Concepts de gestion d'Azure File Sync

Les groupes de synchronisation sont déployés dans des services de synchronisation de stockage ; il s'agit d'objets de niveau supérieur qui inscrivent les serveurs à utiliser avec Azure File Sync et contiennent les relations des groupes de synchronisation. La ressource de service de synchronisation de stockage est un pair de la ressource de compte de stockage. Elle peut être déployée de la même façon dans des groupes de ressources Azure. Un service de synchronisation de stockage peut créer des groupes de synchronisation contenant des partages de fichiers Azure répartis sur différents comptes de stockage et différentes instances inscrites de Windows Server.

Pour créer un groupe de synchronisation dans un service de synchronisation de stockage, vous devez préalablement inscrire une instance de Windows Server auprès du service de synchronisation de stockage. L'objet serveur inscrit qui est alors créé représente une relation d'approbation entre votre serveur, ou cluster, et le service de synchronisation de stockage. Pour inscrire un service de synchronisation de stockage, vous devez d'abord installer l'agent Azure File Sync sur le serveur. Un serveur ou un cluster ne peut être inscrit qu'auprès d'un seul service de synchronisation de stockage à la fois.

Un groupe de synchronisation contient un point de terminaison cloud, ou un partage de fichiers Azure, et au moins un point de terminaison de serveur. L'objet point de terminaison de serveur contient les paramètres de configuration de la fonctionnalité de hiérarchisation cloud, qui fournit la fonctionnalité de mise en cache d'Azure File Sync. Pour la synchronisation avec un partage de fichiers Azure, le compte de stockage contenant le partage de fichiers Azure doit se trouver dans la même région Azure que le service de synchronisation de stockage.

Important

Vous pouvez apporter des modifications à l’espace de noms d’un point de terminaison cloud ou d’un point de terminaison de serveur du groupe de synchronisation et faire en sorte que vos fichiers soient synchronisés avec les autres points de terminaison du groupe. Si vous apportez une modification au point de terminaison cloud (partage de fichiers Azure) directement, cette modification doit être détectée au préalable par un travail de détection des modifications Azure File Sync. Un travail de détection des modifications est lancé pour un point de terminaison cloud toutes les 24 heures uniquement. Pour plus d’informations, consultez Questions fréquentes (FAQ) sur Azure Files.

Prise en compte du nombre de services de synchronisation de stockage nécessaires

Dans une section précédente, nous avons abordé la ressource principale à configurer pour Azure File Sync : un service de synchronisation de stockage. Un serveur Windows ne peut être inscrit qu’à un seul service de synchronisation de stockage. Par conséquent, il est souvent préférable de déployer un seul service de synchronisation de stockage et d’y inscrire tous les serveurs.

Ne créez plusieurs services de synchronisation de stockage que dans les cas suivants :

• Vous possédez des ensembles distincts de serveurs qui ne doivent jamais s’échanger de données. Dans ce cas, concevez le système de façon à exclure certains ensembles de serveurs à synchroniser avec un partage de fichiers Azure déjà utilisé comme point de terminaison cloud dans un groupe de synchronisation au sein d’un autre service de synchronisation de stockage. En d’autres termes, les serveurs Windows inscrits auprès d’un autre service de synchronisation de stockage ne peuvent pas se synchroniser avec le même partage de fichiers Azure.
• Vous avez besoin de plus de serveurs inscrits ou de groupes de synchronisation que ne peut en prendre en charge un seul service de synchronisation de stockage. Pour plus d’informations, consultez Cibles de mise à l’échelle Azure File Sync.

Planification de topologies de synchronisation équilibrée

Avant de déployer des ressources, il est important de planifier ce que vous allez synchroniser sur un serveur local et avec quel partage de fichiers Azure. Le fait de créer un plan vous aidera à déterminer le nombre de comptes de stockage, de partages de fichiers Azure et de ressources de synchronisation dont vous aurez besoin. Ces considérations sont toujours pertinentes, même si vos données ne résident pas sur un serveur Windows ou sur le serveur que vous souhaitez utiliser à long terme. La section migration peut vous aider à déterminer les chemins de migration adaptés à votre situation.

Dans cette étape, vous allez déterminer le nombre de partages de fichiers Azure dont vous avez besoin. Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure.

Vous pouvez avoir plus de dossiers dans vos volumes que ce que vous partagez actuellement localement en tant que partages SMB pour vos utilisateurs et applications. La solution la plus simple pour décrire ce scénario consiste à envisager un mappage 1:1 entre un partage local et un partage de fichiers Azure. Si vous avez un nombre suffisamment petit de partages, inférieur à 30 pour une seule instance Windows Server, nous vous recommandons un mappage 1:1.

Si vous avez plus de 30 partages, il est souvent inutile de mapper un partage local 1:1 à un partage de fichiers Azure. Tenez compte des options suivantes.

Regroupement de partages

Par exemple, si votre service des ressources humaines (RH) a 15 partages, vous pouvez envisager de stocker toutes les données RH dans un seul partage de fichiers Azure. Le stockage de plusieurs partages locaux dans un partage de fichiers Azure ne vous empêche pas de créer les 15 partages SMB habituels sur votre instance locale de Windows Server. Cela signifie simplement que vous organisez les dossiers racine de ces 15 partages en sous-dossiers sous un dossier commun. Vous synchronisez ensuite ce dossier commun avec un partage de fichiers Azure. Ainsi, un seul partage de fichiers Azure dans le cloud est nécessaire pour ce groupe de partages locaux.

Synchronisation de volume

Azure File Sync prend en charge la synchronisation de la racine d’un volume avec un partage de fichiers Azure. Si vous synchronisez la racine du volume, tous les sous-dossiers et fichiers se retrouvent dans le même partage de fichiers Azure.

La synchronisation de la racine du volume n’est pas toujours la meilleure option. Il y a des avantages à synchroniser plusieurs emplacements. Par exemple, cela permet de maintenir un nombre d’éléments plus bas par étendue de synchronisation. Nous testons les partages de fichiers Azure et Azure File Sync avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, la bonne pratique est d’essayer de garder le nombre au-dessous de 20 ou 30 millions dans un même partage. La configuration d’Azure File Sync avec un nombre d’éléments inférieur n’est pas seulement avantageuse pour la synchronisation de fichiers. Un nombre inférieur d’éléments présente également des avantages pour d’autres scénarios comme :

• L’analyse initiale du contenu cloud peut se terminer plus rapidement, ce qui réduit l’attente de l’affichage de l’espace de noms sur un serveur activé pour Azure File Sync.
• La restauration côté cloud à partir d’un instantané de partage de fichiers Azure sera plus rapide.
• La reprise d’activité d’un serveur local peut être considérablement accélérée.
• Les modifications apportées directement dans un partage de fichiers Azure (en dehors de la synchronisation) peuvent être détectées et synchronisées plus rapidement.

Conseil

Si vous ne savez pas combien de fichiers et de dossiers vous avez, consultez l’outil d’arborescence de JAM Software GmbH.

Approche structurée d’un plan de déploiement

Avant de déployer un stockage cloud par la suite, vous devez créer un mappage entre des dossiers locaux et des partages de fichiers Azure. Ce mappage indique le nombre et la nature des ressources de groupe de synchronisation Azure File Sync à provisionner. Un groupe de synchronisation lie le partage de fichiers Azure et le dossier sur votre serveur et établit une connexion de synchronisation.

Pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, passez en revue les limites et bonnes pratiques suivantes. Cela vous permet d’optimiser votre mappage.

• Un serveur sur lequel l’agent Azure File Sync est installé peut se synchroniser avec un maximum de 30 partages de fichiers Azure.

• Un partage de fichiers Azure est déployé dans un compte de stockage. Cet arrangement fait du compte de stockage une cible de mise à l’échelle pour les chiffres des performances comme les IOPS et le débit.

  Lors du déploiement de partages de fichiers Azure, soyez attentif aux limitations d’IOPS d’un compte de stockage. Dans l’idéal, une correspondance 1:1 doit être respectée entre les partages de fichiers et les comptes de stockage. Mais cela n’est pas toujours possible en raison des différentes limites et restrictions imposées par votre organisation et Azure. Lorsqu’il est impossible de déployer un seul partage de fichiers dans un seul compte de stockage, il convient d’identifier les partages qui seront plus ou moins actifs afin de veiller à ce que les plus actifs ne soient pas regroupés sur le même compte de stockage.

  Si vous envisagez d’intégrer une application dans Azure qui utilisera le partage de fichiers Azure en mode natif, vous devrez peut-être augmenter les performances de votre partage de fichiers Azure. Si ce type d’utilisation est une éventualité, même future, il est préférable de créer un partage de fichiers Azure standard dans son propre compte de stockage.

• Il existe une limite de 250 comptes de stockage par abonnement et par région Azure.

Conseil

Au vu de ces informations, il est souvent nécessaire de regrouper plusieurs dossiers de niveau supérieur sur vos volumes dans un nouveau répertoire racine commun. Vous synchronisez ensuite ce nouveau répertoire racine et tous les dossiers que vous y avez regroupés dans un seul partage de fichiers Azure. Cette technique vous permet de rester dans la limite de 30 synchronisations de partage de fichiers Azure par serveur.

Ce regroupement sous une racine commune n’affecte pas l’accès à vos données. Vos listes de contrôle d’accès restent telles quelles. Vous avez seulement besoin d’ajuster les chemins de partage (par exemple, des partages SMB ou NFS) que vous pouvez avoir sur les dossiers de serveur locaux et que vous avez maintenant changés en racine commune. Rien d’autre ne change.

Important

Le vecteur d’échelle le plus important pour Azure File Sync est le nombre d’éléments (fichiers et dossiers) qui doivent être synchronisés. Pour plus d’informations, consultez Cibles de mise à l’échelle Azure File Sync.

Il est recommandé de maintenir un petit nombre d’éléments par étendue de synchronisation. C’est un facteur important à prendre en compte quand vous mappez des dossiers aux partages de fichiers Azure. Azure File Sync est testé avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, il est souvent préférable de garder le nombre d’éléments au-dessous de 20 ou 30 millions dans un même partage. Fractionnez votre espace de noms en plusieurs partages si vous commencez à dépasser ces nombres. Vous pouvez continuer à regrouper plusieurs partages locaux dans le même partage de fichiers Azure, à condition que vous restiez plus ou moins en dessous de ces chiffres. Cette méthode vous donne de la marge pour évoluer.

Dans votre situation, il est possible qu’un ensemble de dossiers puisse logiquement se synchroniser avec le même partage de fichiers Azure (en utilisant la nouvelle approche de dossier racine commun mentionnée plus haut). Toutefois, il peut être préférable de regrouper les dossiers de manière à ce qu’ils se synchronisent avec deux partages de fichiers Azure au lieu d’un. Vous pouvez utiliser cette approche pour conserver l’équilibre entre le nombre de fichiers et de dossiers par partage de fichiers sur le serveur. Vous pouvez également diviser vos partages locaux et synchroniser sur d’autres serveurs locaux, en ajoutant la possibilité de synchroniser avec 30 autres partages de fichiers Azure par serveur supplémentaire.

Scénarios fréquents de synchronisation de fichiers et observations

#	Scénario de synchronisation	Prise en charge	Observations (ou limitations)	Solution (ou solution de contournement)
1	Serveur de fichiers avec plusieurs disques/volumes et plusieurs partages sur le même partage de fichiers Azure cible (consolidation)	Non	Un partage de fichiers Azure cible (point de terminaison cloud) ne prend en charge la synchronisation qu’avec un seul groupe de synchronisation. Un groupe de synchronisation ne prend en charge qu’un seul point de terminaison de serveur par serveur inscrit.	1) Commencez par synchroniser un disque (son volume racine) pour cibler le partage de fichiers Azure. Le fait de commencer par le disque/volume le plus important aidera à déterminer les besoins de stockage au niveau local. Configurez la hiérarchisation cloud pour répartir toutes les données sur le cloud, libérant ainsi de l’espace sur le disque du serveur de fichiers. Déplacez les données d’autres volumes/partages vers le volume actuel qui est synchronisé. Suivez les étapes une par une jusqu’à ce que toutes les données soient transférées vers le cloud ou migrées. 2) Ciblez un volume racine (disque) à la fois. Utilisez la hiérarchisation cloud pour répartir toutes les données dans le partage de fichiers Azure cible. Supprimez le point de terminaison de serveur du groupe de synchronisation, recréez le point de terminaison avec le volume/disque racine suivant, synchronisez et répétez le processus. Remarque : il peut être nécessaire de réinstaller l’agent. 3) Recommandez l’utilisation de plusieurs partages de fichiers Azure cibles (compte de stockage identique ou différent en fonction des exigences de performances)
2	Serveur de fichiers avec un volume unique et plusieurs partages sur le même partage de fichiers Azure cible (consolidation)	Oui	Impossible de synchroniser plusieurs points de terminaison de serveur par serveur inscrit avec le même partage de fichiers Azure cible (identique à celui ci-dessus)	Synchronisez la racine du volume contenant plusieurs partages ou dossiers de niveau supérieur. Pour plus d’informations, consultez Concept de regroupement de partages et Synchronisation du volume.
3	Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un seul compte de stockage (mappage de partage 1:1)	Oui	Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure. Un compte de stockage est une cible de mise à l’échelle pour les performances. Les IOPS et le débit sont partagés entre les partages de fichiers. Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.	1) Utilisez plusieurs groupes de synchronisation (nombre de groupes de synchronisation = nombre de partages de fichiers Azure à synchroniser). 2) Seuls 30 partages à la fois peuvent être synchronisés dans ce scénario. Si vous avez plus de 30 partages sur ce serveur de fichiers, utilisez le Concept de regroupement de partages et la Synchronisation du volume pour réduire le nombre de dossiers racine ou de niveau supérieur à la source. 3) Utilisez des serveurs File Sync supplémentaires locaux et fractionnez/déplacez les données vers ces serveurs pour contourner les limitations sur le serveur Windows source.
4	Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un compte de stockage différent (mappage de partage 1:1)	Oui	Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure (compte de stockage identique ou différent). Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.	Même approche que précédemment
5	Plusieurs serveurs de fichiers avec un seul (volume ou partage racine) sur le même partage de fichiers Azure cibles (consolidation)	Non	Un groupe de synchronisation ne peut pas utiliser le point de terminaison cloud (partage de fichiers Azure) déjà configuré dans un autre groupe de synchronisation. Bien qu’un groupe de synchronisation puisse avoir des points de terminaison de serveur sur des serveurs de fichiers différents, les fichiers ne peuvent pas être distincts.	Suivez les instructions du scénario n° 1 ci-dessus en tenant compte de la nécessité de cibler un serveur de fichiers à la fois.

Créer une table de mappage

Utilisez les informations précédentes pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, ainsi que les parties de vos données existantes finissant dans ces différents partages.

Créez un tableau regroupant vos réflexions pour pouvoir vous y référer quand vous en avez besoin. Veillez à rester organisé pour ne perdre aucun détail de votre plan de mappage quand vous approvisionnez simultanément un grand nombre de ressources Azure. Téléchargez le fichier Excel suivant à utiliser comme modèle pour vous aider à créer votre mappage.

Téléchargez un modèle de mappage d’espace de noms.

Considérations relatives aux serveurs de fichiers Windows

Pour activer la fonctionnalité de synchronisation sur Windows Server, vous devez installer l'agent téléchargeable Azure File Sync. L’agent Azure File Sync fournit deux composants principaux : FileSyncSvc.exe, le service Windows en arrière-plan chargé de la supervision des modifications sur les points de terminaison de serveur et du lancement des sessions de synchronisation, et StorageSync.sys, un filtre de système de fichiers qui permet la hiérarchisation cloud et une récupération d’urgence rapide.

Système d'exploitation requis

Azure File Sync est pris en charge avec les versions suivantes de Windows Server :

Version	Références prises en charge	Options de déploiement prises en charge
Windows Server 2022	Azure, Datacenter, Standard et IoT	Complète et Minimale
Windows Server 2019	Datacenter, Standard et IoT	Complète et Minimale
Windows Server 2016	Datacenter, Standard et Storage Server	Complète et Minimale
Windows Server 2012 R2*	Datacenter, Standard et Storage Server	Complète et Minimale

*Nécessite le téléchargement et l’installation de Windows Management Framework (WMF) 5.1. Le package correct à télécharger et à installer pour Windows Server 2012 R2 est Win8.1AndW2K12R2-KB*******-x64.msu.

Nous prévoyons d’ajouter la prise en charge de versions ultérieures de Windows Server quand elles seront disponibles.

Important

Nous vous recommandons de mettre régulièrement à jour tous les serveurs que vous utilisez avec Azure File Sync en installant les dernières mises à jour disponibles sur Windows Update.

Ressources système minimum

Azure File Sync nécessite un serveur physique ou virtuel, avec au moins un processeur, un minimum de 2 Gio de mémoire et un volume attaché localement formaté avec le système de fichiers NTFS.

Important

Si le serveur est exécuté sur une machine virtuelle sur laquelle la mémoire dynamique est activée, la machine virtuelle doit être configurée avec un minimum de 2048 Mio de mémoire.

Pour la plupart des charges de travail de production, nous déconseillons de configurer un serveur de synchronisation Azure File Sync en se contentant de la configuration minimale requise. Pour plus d'informations, consultez Ressources système recommandées.

Ressources système recommandées

Comme pour toute fonctionnalité ou application serveur, les ressources système requises pour Azure File Sync dépendent de l'échelle de déploiement. Un déploiement sur serveur important nécessite des ressources système importantes. Pour Azure File Sync, l'échelle est déterminée par le nombre d'objets répartis sur les points de terminaison de serveur et par l'évolution sur le jeu de données. Un même serveur peut avoir des points de terminaison de serveur dans plusieurs groupes de synchronisation, et le nombre d'objets répertoriés dans le tableau suivant représente l'espace de noms complet auquel un serveur est attaché.

Par exemple, le point de terminaison de serveur A avec 10 millions d'objets + le point de terminaison de serveur B avec 10 millions d'objets = 20 millions d'objets. Pour cet exemple de déploiement, nous recommandons 8 UC, 16 Gio de mémoire pour l'état stable et (si possible) 48 Gio de mémoire pour la migration initiale.

Les données d’espace de noms sont stockées en mémoire pour des raisons de performance. Pour cette raison, les espaces de noms plus grands nécessitent davantage de mémoire pour maintenir de bonnes performances, et une évolution plus importante requiert davantage d’UC pour le traitement.

Dans le tableau suivant, nous avons fourni la taille de l’espace de noms, ainsi qu’une conversion en capacité pour les partages de fichiers à usage général standard, sachant que la taille de fichier moyenne est 512 Kio. Si les tailles de vos fichiers sont plus petites, envisagez d’ajouter de la mémoire supplémentaire pour obtenir la même capacité. Basez la configuration de votre mémoire sur la taille de l’espace de noms.

Taille de l’espace de noms - fichiers et répertoires (millions)	Capacité type (Tio)	Cœurs de processeur	Mémoire recommandée (Gio)
3	1.4	2	8 (synchronisation initiale)/2 (évolution classique)
5	2.3	2	16 (synchronisation initiale)/4 (évolution classique)
10	4,7	4	32 (synchronisation initiale)/8 (évolution classique)
30	14,0	8	48 (synchronisation initiale)/16 (évolution classique)
50	23,3	16	64 (synchronisation initiale)/32 (évolution classique)
100*	46,6	32	128 (synchronisation initiale)/32 (évolution classique)

*La synchronisation de plus de 100 millions de fichiers et répertoires n’est pas recommandée. Il s'agit d'une limite conditionnelle basée sur les seuils que nous avons testés. Pour plus d’informations, consultez la page sur la de tarification Azure File Sync.

Conseil

La synchronisation initiale d’un espace de noms est une opération intensive et nous vous recommandons d’allouer davantage de mémoire jusqu’à ce que la synchronisation initiale soit terminée. Cela n’est pas obligatoire, mais peut accélérer la synchronisation initiale.

L’évolution standard est que 0,5 % de l’espace de noms change chaque jour. Pour des niveaux d’évolution plus élevés, envisagez d’ajouter davantage d’UC.

Applet de commande d’évaluation

Avant de déployer Azure File Sync, vous devez évaluer s’il est compatible avec votre système à l’aide du cmdlet d’évaluation d’Azure File Sync. Cette cmdlet recherche les problèmes potentiels liés au système de fichiers et au jeu de données, comme des caractères ou une version de système d’exploitation non pris en charge. Ces vérifications couvrent la plupart des fonctionnalités mentionnées ci-dessous, mais pas toutes. Nous vous conseillons de lire attentivement le reste de cette section pour garantir le bon déroulement de votre déploiement.

Vous pouvez installer l’applet de commande d’évaluation en installant le module Az PowerShell en suivant ces instructions : Installez et configurez Azure PowerShell.

Usage

Vous pouvez appeler l’outil d’évaluation de différentes manières : vous pouvez effectuer les vérifications du système, les vérifications du jeu de données, ou les deux. Pour effectuer à la fois les vérifications du système et les vérifications du jeu de données :

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Pour tester uniquement votre jeu de données :

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Pour tester uniquement la configuration requise :

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Pour afficher les résultats au format CSV :

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Compatibilité du système de fichiers

Azure File Sync n'est pris en charge que sur les volumes NTFS en attachement direct. Sur Windows Server, le stockage en attachement direct, ou DAS, signifie que le système d'exploitation Windows Server est propriétaire du système de fichiers. Le DAS peut être fourni en attachant physiquement des disques au serveur de fichiers, en attachant des disques virtuels à une machine virtuelle de serveur de fichiers (comme une machine virtuelle hébergée par Hyper-V), ou même via iSCSI.

Seuls les volumes NTFS sont pris en charge ; ReFS, FAT, FAT32 et autres systèmes de fichiers ne sont pas pris en charge.

Le tableau suivant présente l'état d'interopérabilité des fonctionnalités du système de fichiers NTFS :

Fonctionnalité	État de la prise en charge	Notes
Listes ACL	entièrement prise en charge	Les listes de contrôle d'accès discrétionnaire de type Windows sont conservées par Azure File Sync et appliquées par Windows Server sur les points de terminaison de serveur. Les listes de contrôle d'accès peuvent également être appliquées lors du montage direct du partage de fichiers Azure, mais cela nécessite une configuration supplémentaire. Pour plus d'informations, consultez la section Identité.
Liens physiques	Ignoré
Liens symboliques	Ignoré
Points de montage	Partiellement pris en charge	Les points de montage peuvent être la racine d’un point de terminaison de serveur, mais ils sont ignorés s’ils se trouvent dans un espace de noms du point de terminaison de serveur.
Jonctions	Ignoré	Par exemple, les dossiers DfrsrPrivate de système de fichiers DFS et DFSRoots.
Points d’analyse	Ignoré
Compression NTFS	Partiellement prise en charge	Azure File Sync ne prend pas en charge les points de terminaison serveur situés sur un volume dont le répertoire d’informations de volume système (SVI) est compressé.
Fichiers partiellement alloués	entièrement prise en charge	Les fichiers partiellement alloués sont synchronisés (ils ne sont pas bloqués), mais ils sont synchronisés dans le cloud sous forme de fichiers complets. Si le contenu d’un fichier change dans le cloud (ou sur un autre serveur), le fichier n’est plus partiellement alloué quand le changement est téléchargé.
Autres flux de données	Conservés, mais pas synchronisés	Par exemple, les balises de classification créées par l’infrastructure de classification des fichiers ne sont pas synchronisées. Les balises de classification qui existent sur des fichiers à chacun des points de terminaison du serveur ne sont pas affectées.

Azure File Sync ignore également certains fichiers temporaires et dossiers système :

Fichier/Dossier	Remarque
pagefile.sys	Fichier spécifique au système
Desktop.ini	Fichier spécifique au système
thumbs.db	Fichier temporaire pour les miniatures
ehthumbs.db	Fichier temporaire pour les miniatures multimédia
~$*.*	Fichier temporaire Office
*.tmp	Fichier temporaire
*.laccdb	Accès au fichier de verrouillage de base de données
635D02A9D91C401B97884B82B3BCDAEA.*	fichier de synchronisation interne
\System Volume Information	Dossier spécifique au volume
$RECYCLE.BIN	Dossier
\SyncShareState	dossier pour la synchronisation
.SystemShareInformation	Dossier pour la synchronisation dans le partage de fichiers Azure

Remarque

Même si Azure File Sync prend en charge la synchronisation des fichiers de base de données, les bases de données ne sont pas une bonne charge de travail pour les solutions de synchronisation (y compris Azure File Sync), car les fichiers journaux et les bases de données doivent être synchronisés ensemble et peuvent sortir de la synchronisation pour diverses raisons pouvant entraîner une altération de la base de données.

Déterminez la quantité d’espace libre dont vous avez besoin sur votre disque local

Lorsque vous planifiez d’utiliser Azure File Sync, prenez en compte l’espace libre dont vous avez besoin sur le disque local sur lequel vous envisagez de disposer d’un point de terminaison de serveur.

Avec Azure File Sync, vous devez prendre en compte les éléments suivants qui occupent de l’espace sur votre disque local :

• Avec la hiérarchisation Cloud activée :

  • Points d’analyse pour les fichiers hiérarchisés
  • Base de données de métadonnées Azure File Sync
  • Heatstore Azure File Sync
  • Fichiers entièrement téléchargés dans votre cache à chaud (le cas échéant)
  • Exigences en matière de stratégie d’espace libre du volume

• Avec la hiérarchisation Cloud désactivée :

  • Fichiers entièrement téléchargés
  • Heatstore Azure File Sync
  • Base de données de métadonnées Azure File Sync

Nous allons utiliser un exemple pour illustrer comment estimer la quantité d’espace libre nécessaire sur votre disque local. Supposons que vous avez installé votre agent Azure File Sync sur votre machine virtuelle Azure Windows et que vous envisagez de créer un point de terminaison de serveur sur le disque F. Vous disposez d’un million de fichiers que vous souhaitez intégralement hiérarchiser, 100 000 répertoires et une taille de cluster de disque de 4 Kio. La taille du disque est de 1 000 Gio. Vous souhaitez activer la hiérarchisation Cloud et définir votre stratégie d’espace libre de volume à 20 %.

1. NTFS alloue une taille de cluster pour chacun des fichiers hiérarchisés. 1 million de fichiers * taille de cluster 4 Kio = 4 000 000 Kio (4 Gio)

   Remarque

   Pour tirer pleinement parti de la hiérarchisation cloud, il est recommandé d’utiliser des tailles de cluster NTFS plus petites (inférieures à 64 Kio), car chaque fichier hiérarchisé occupe un cluster. L’espace occupé par les fichiers hiérarchisés est également alloué par NTFS. Par conséquent, il n’apparaîtra dans aucune interface utilisateur.

2. Les métadonnées de synchronisation occupent une taille de cluster par élément. (1 million de fichiers + 100 000 répertoires) * taille de cluster 4 Kio = 4 400 000 Kio (4,4 Gio)
3. L’accumulateur de chaleur Azure File Sync occupe 1,1 Kio par fichier. 1 million de fichiers * 1,1 Kio = 1 100 000 Kio (1,1 Gio)
4. La stratégie d’espace libre du volume est de 20 %. 1 000 Gio * 0,2 = 200 Gio

Dans ce cas, Azure File Sync aura besoin d’environ 209,5 millions de Kio (209,5 Gio) d’espace pour cet espace de noms. Ajoutez cette valeur à tout espace libre supplémentaire souhaité pour déterminer la quantité d’espace libre nécessaire pour ce disque.

Clustering de basculement

1. Le clustering de basculement Windows Server est pris en charge par Azure File Sync pour l’option de déploiement « Serveur de fichiers pour une utilisation générale ». Pour plus d’informations sur la configuration du rôle « Serveur de fichiers pour une utilisation générale » sur un cluster de basculement, consultez Déploiement d’un serveur de fichiers en cluster à deux nœuds.
2. Le seul scénario pris en charge par Azure File Sync est le scénario Cluster de basculement Windows Server avec disques en cluster
3. Le clustering de basculement n’est pas pris en charge sur « Serveur de fichiers avec montée en puissance parallèle pour les données d’application » (SOFS), sur les volumes partagés de cluster (CSV) ni sur les disques locaux.

Remarque

L’agent Azure File Sync doit être installé sur chaque nœud d’un cluster de basculement pour que la synchronisation fonctionne correctement.

Déduplication des données

Windows Server 2022, Windows Server 2019 et Windows Server 2016
La déduplication des données est prise en charge indépendamment du fait que la hiérarchisation cloud soit activée ou désactivée sur un ou plusieurs points de terminaison de serveur du volume pour Windows Server 2016, Windows Server 2019 et Windows Server 2022. Le fait d’activer la déduplication des données sur un volume pour lequel la hiérarchisation cloud est activée vous permet de mettre en cache plus de fichiers en local sans avoir à provisionner plus de stockage.

Quand la déduplication des données est activée sur un volume où la hiérarchisation cloud est activée, les fichiers optimisés par la déduplication à l’emplacement du point de terminaison de serveur sont hiérarchisés d’une façon similaire à un fichier normal, en fonction des paramètres de stratégie de hiérarchisation cloud. Une fois que les fichiers optimisés par la déduplication ont été hiérarchisés, le travail de nettoyage de la mémoire de la déduplication des données s’exécute automatiquement pour récupérer de l’espace disque en supprimant les blocs inutiles qui ne sont plus référencés par d’autres fichiers sur le volume.

Notez que les économies faites sur les volumes s’appliquent seulement au serveur ; vos données dans le partage de fichiers Azure ne sont pas dédupliquées.

Remarque

Pour prendre en charge la déduplication des données sur des volumes où la hiérarchisation cloud est activée sur Windows Server 2019, la mise à jour Windows KB4520062 - Octobre 2019 ou une mise à jour cumulative plus récente doit être installée.

Windows Server 2012 R2
Azure File Sync ne prend pas en charge la déduplication des données et la hiérarchisation cloud sur le même volume sur Windows Serveur 2012 R2. Si la déduplication des données est activée sur un volume, la hiérarchisation cloud doit être désactivée.

Remarques

• Si la déduplication des données est installée avant d’installer l’agent Azure File Sync, un redémarrage est nécessaire pour prendre en charge la déduplication des données et la hiérarchisation cloud sur le même volume.

• Si la déduplication des données est activée sur un volume une fois la hiérarchisation cloud activée, la tâche d’optimisation de la déduplication initiale permettra d’optimiser les fichiers qui ne sont pas déjà hiérarchisés dans le volume et aura l’impact suivant sur la hiérarchisation cloud :

  • La stratégie d’espace disponible continuera à hiérarchiser les fichiers en fonction de l’espace disponible sur le volume à l’aide de la carte thermique.
  • La stratégie de date ignorera la hiérarchisation des fichiers qui ont été éligibles pour la hiérarchisation en raison de l’accès de la tâche d’optimisation de la déduplication aux fichiers.

• En ce qui concerne les tâches d’optimisation de la déduplication en cours, la hiérarchisation cloud avec la stratégie de date sera retardée par le paramètre MinimumFileAgeDays de déduplication des données, si le fichier n’est pas déjà hiérarchisé.

  • Exemple : Si la valeur du paramètre MinimumFileAgeDays est de sept jours et la valeur de la stratégie de date de la hiérarchisation cloud est de 30 jours, la stratégie de date hiérarchisera les fichiers après 37 jours.
  • Remarque : Une fois un fichier hiérarchisé par Azure File Sync, la tâche d’optimisation de la déduplication ignorera le fichier.

• Si un serveur exécutant Windows Server 2012 R2 avec l’agent Azure File Sync installé est mis à niveau vers Windows Server 2016, Windows Server 2019 ou Windows Server 2022, les étapes suivantes doivent être effectuées pour prendre en charge la déduplication des données et la hiérarchisation cloud sur le même volume :

  • Désinstallez l’agent Azure File Sync pour Windows Server 2012 R2 et redémarrez le serveur.
  • Téléchargez l’agent Azure File Sync pour la nouvelle version du système d’exploitation serveur (Windows Server 2016, Windows Server 2019 ou Windows Server 2022).
  • Installez l’agent Azure File Sync et redémarrez le serveur.

  Remarque : Les paramètres de configuration Azure File Sync sur le serveur sont conservés lorsque l’agent est désinstallé et réinstallé.

Système de fichiers DFS

Azure File Sync prend en charge l’interopérabilité avec les espaces de noms DFS (DFS-N) et la réplication DFS (DFS-R).

Espaces de noms DFS (DFS-N) : Azure File Sync est entièrement pris en charge avec l’implémentation DFS-N. Vous pouvez installer l’agent Azure File Sync sur un ou plusieurs serveurs de fichiers pour synchroniser les données entre les points de terminaison de serveur et le point de terminaison cloud, puis utiliser DFS-N pour fournir un service d’espace de noms. Pour plus d’informations, consultez Vue d’ensemble des espaces de noms DFS et Espaces de noms DFS avec Azure Files.

Réplication DFS (DFS-R) : Comme DFS-R et Azure File Sync sont deux solutions de réplication, dans la plupart des cas, nous recommandons de remplacer DFS-R par Azure File Sync. Il existe cependant plusieurs scénarios où vous souhaiterez utiliser DFS-R et Azure File Sync :

• Vous effectuez la migration d’un déploiement de DFS-R vers un déploiement d’Azure File Sync. Pour plus d’informations, consultez Migrer un déploiement de la réplication DFS (DFS-R) vers Azure File Sync.
• Tous les serveurs locaux ayant besoin d’une copie de vos données de fichiers ne peuvent pas être connectés directement à Internet.
• Les serveurs de succursale consolident les données sur un serveur hub pour lequel vous souhaitez utiliser Azure File Sync.

Pour qu’Azure File Sync et DFS-R fonctionnent côte à côte :

1. La hiérarchisation cloud d’Azure File Sync doit être désactivée sur les volumes avec des dossiers répliqué DFS-R.
2. Les points de terminaison de serveur ne doivent pas être configurés sur des dossiers de réplication DFS-R en lecture seule.
3. Au maximum un point de terminaison de serveur peut se chevaucher avec un emplacement DFS-R. La présence de plusieurs points de terminaison serveur superposés avec d’autres emplacements DFS-R actifs peut entraîner des conflits.

Pour plus d’informations, consultez Vue d’ensemble de la réplication DFS.

Sysprep

L’utilisation de sysprep sur un serveur sur lequel l’agent Azure File Sync est installé n’est pas prise en charge et peut produire des résultats inattendus. L’installation de l’agent et l’inscription du serveur doivent être effectués après avoir déployé l’image du serveur et terminé la mini-configuration de sysprep.

Recherche Windows

Si la hiérarchisation cloud est activée sur un point de terminaison de serveur, les fichiers qui sont hiérarchisés sont ignorés et ne sont pas indexés par Windows Search. Les fichiers non hiérarchisés sont indexés correctement.

Notes

Les clients Windows provoquent des rappels lors de la recherche dans le partage de fichiers si le paramètre Toujours rechercher les noms de fichiers et le contenu est activé sur l’ordinateur client. Ce paramètre est désactivé par défaut.

Autres solutions de gestion hiérarchique du stockage (HSM)

Aucune autre solution HSM ne doit être utilisée avec Azure File Sync.

Performances et extensibilité

Étant donné que l’agent Azure File Sync s’exécute sur un ordinateur Windows Server qui se connecte aux partages de fichiers Azure, les performances de synchronisation réelles dépendent de plusieurs facteurs dans votre infrastructure : Windows Server et la configuration de disque sous-jacente, la bande passante réseau entre le serveur et le stockage Azure, la taille des fichiers, la taille totale du jeu de données et l’activité sur le jeu de données. Comme Azure File Sync fonctionne au niveau du fichier, les caractéristiques de performances d’une solution Azure File Sync est exprimée de façon optimale en nombre d’objets (fichiers et répertoires) traités par seconde.

Les modifications apportées au partage de fichiers Azure avec le portail Azure ou SMB ne sont pas immédiatement détectées et répliquées comme le sont les modifications apportées au point de terminaison de serveur. Azure Files n’a pas encore de notifications ou journalisation des modifications. Il n’existe donc aucun moyen de lancer automatiquement une session de synchronisation lorsque des fichiers sont modifiés. Sur Windows Server, Azure File Sync utilise la journalisation du nombre de séquences de mise à jour de Windows pour lancer automatiquement une session de synchronisation quand des fichiers changent.

Pour détecter les modifications apportées au partage de fichiers Azure, Azure File Sync a une tâche planifiée appelée tâche de détection des modifications. Une tâche de détection des modifications énumère tous les fichiers inclus dans le partage de fichiers, puis les compare à la version de synchronisation de ces fichiers. Lorsque la tâche de détection des modifications détermine que des fichiers ont changé, Azure File Sync lance une session de synchronisation. La tâche de détection des modifications est lancée toutes les 24 heures. Étant donné que la tâche de détection des modifications fonctionne en énumérant chaque fichier dans le partage de fichiers Azure, elle prend plus de temps dans les espaces de noms de grande taille que dans les plus petits. Pour des espaces de noms de grande taille, plus de 24 heures peuvent être nécessaires pour déterminer les fichiers qui ont été modifiés.

Pour plus d’informations, consultez Métriques de niveau de performance Azure file Sync et Cibles de mise à l’échelle Azure File Sync.

Identité

Azure File Sync fonctionne avec votre identité AD standard sans aucune configuration particulière en plus de la configuration de la synchronisation. En utilisant Azure File Sync, vous vous attendez probablement à ce que la plupart des accès passent par les serveurs de mise en cache Azure File Sync plutôt que par le partage de fichiers Azure. Comme les points de terminaison de serveur se trouvent sur Windows Server, et que Windows Server prend en charge AD et les listes de contrôle d’accès de type Windows depuis longtemps, la seule chose à faire est de s’assurer que les serveurs de fichiers Windows inscrits auprès du service de synchronisation de stockage sont joints au domaine. Azure File Sync stocke les listes de contrôle d'accès sur les fichiers du partage de fichiers Azure et les réplique sur tous les points de terminaison de serveur.

Même si les modifications apportées directement au partage de fichiers Azure mettent plus longtemps à se synchroniser avec les points de terminaison de serveur dans le groupe de synchronisation, vous pouvez également vous assurer qu’il vous est possible d’appliquer vos autorisations AD sur votre partage de fichiers directement dans le cloud. Pour ce faire, vous devez effectuer une jonction de domaine de votre compte de stockage à votre instance locale d'AD, tout comme vos serveurs de fichiers Windows sont joints à un domaine. Pour en savoir plus sur la jonction de domaine de votre compte de stockage à une instance d'Active Directory détenue par le client, consultez Présentation d'Azure Files Active Directory.

Important

La jonction de domaine de votre compte de stockage à Active Directory n’est pas obligatoire pour déployer Azure File Sync. Il s'agit d'une étape totalement facultative qui permet au partage de fichiers Azure d'appliquer des listes de contrôle d'accès locales lorsque les utilisateurs procèdent à un montage direct du partage de fichiers Azure.

Mise en réseau

L'agent Azure File Sync communique avec votre service de synchronisation de stockage et votre partage de fichiers Azure à l'aide du protocole Azure File Sync REST et du protocole FileREST, qui utilisent tous les deux HTTPS sur le port 443. SMB n'est jamais utilisé pour charger ou télécharger des données entre votre instance de Windows Server et le partage de fichiers Azure. Dans la mesure où la plupart des organisations autorisent le trafic HTTPS sur le port 443 pour visiter la plupart des sites web, aucune configuration réseau spéciale n'est généralement requise dans le cadre du déploiement d'Azure File Sync.

Important

Azure File Sync ne prend pas en charge le routage Internet. L'option de routage réseau par défaut, le routage Microsoft, est prise en charge par Azure File Sync.

En fonction de la stratégie de votre organisation ou d’exigences réglementaires particulières, vous pouvez avoir besoin d’une communication plus restrictive avec Azure. C’est pourquoi Azure File Sync propose différents mécanismes pour vous permettre de configurer la mise en réseau. En fonction de vos besoins, vous pouvez :

• Canaliser la synchronisation et le trafic de chargement/téléchargement des fichiers sur votre VPN ExpressRoute ou Azure
• Utiliser les fonctionnalités Azure Files et Azure Networking telles que les points de terminaison de service et les points de terminaison privés
• Configurer Azure File Sync de manière à prendre en charge votre proxy dans votre environnement
• Limiter l'activité du réseau à partir d'Azure File Sync

Conseil

Si vous souhaitez communiquer avec votre partage de fichiers Azure via SMB, mais que le port 445 est bloqué, envisagez d’utiliser SMB sur QUIC, qui offre un « VPN SMB » sans configuration pour l’accès SMB à vos partages de fichiers Azure à l’aide du protocole de transport QUIC sur le port 443. Si Azure Files ne prend pas directement en charge SMB sur QUIC, vous pouvez créer un cache léger de vos partages de fichiers Azure sur une machine virtuelle Windows Server 2022 Azure Edition à l’aide d’Azure File Sync. Pour en savoir plus sur cette option, consultez SMB sur QUIC avec Azure File Sync.

Pour en savoir plus sur Azure File Sync et la mise en réseau, consultez Considérations relatives à la mise en réseau Azure File Sync.

Chiffrement

Lorsque vous utilisez Azure File Sync, vous devez prendre en compte trois couches de chiffrement différentes : le chiffrement sur le stockage au repos de Windows Server, le chiffrement en transit entre l'agent Azure File Sync et Azure, et le chiffrement au repos de vos données sur le partage de fichiers Azure.

Chiffrement au repos de Windows Server

Sur Windows Server, deux stratégies de chiffrement des données fonctionnent généralement avec Azure File Sync : le chiffrement sous le système de fichiers, de manière à chiffrer le système de fichiers et toutes les données qui y sont écrites, et le chiffrement au sein du format de fichier lui-même. Ces méthodes ne s’excluent pas mutuellement ; si besoin, elles peuvent être utilisées ensemble dans la mesure où l’objet du chiffrement est différent.

Pour assurer le chiffrement sous le système de fichiers, Windows Server fournit la boîte de réception BitLocker. BitLocker est entièrement transparent pour Azure File Sync. L’utilisation d’un mécanisme de chiffrement comme BitLocker permet d’empêcher l’exfiltration physique des données de votre centre de données local en cas de vol des disques et d’empêcher le chargement indépendant d’un système d’exploitation non autorisé pour effectuer des lectures/écritures non autorisées sur vos données. Pour en savoir plus sur BitLocker, consultez Présentation de BitLocker.

Les produits tiers qui fonctionnent de la même façon que BitLocker, en ce sens qu’ils se trouvent sous le volume NTFS, doivent également fonctionner de manière totalement transparente avec Azure File Sync.

L'autre méthode principale de chiffrement des données consiste à chiffrer le flux de données du fichier lorsque l'application enregistre ce dernier. Certaines applications peuvent effectuer cette opération en mode natif, mais ce n’est généralement pas le cas. Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS sont des exemples de méthodes de chiffrement du flux de données du fichier. L'utilisation d'un mécanisme de chiffrement comme AIP/RMS permet d'empêcher l'exfiltration des données de votre partage de fichiers si quelqu'un venait à les copier à un autre emplacement, comme une clé USB, ou à les envoyer par e-mail à une personne non autorisée. Lorsque le flux de données d'un fichier est chiffré au sein du format de fichier, ce fichier reste chiffré sur le partage de fichiers Azure.

Azure File Sync n’interagit pas avec NTFS EFS (NTFS Encrypted File System) ou des solutions de chiffrement tierces situées au-dessus du système de fichiers mais en dessous du flux de données du fichier.

Chiffrement en transit

Remarque

Le service Azure File Sync ne prend plus en charge les protocoles TLS 1.0 et 1.1 depuis le 1er août 2020. Toutes les versions prises en charge de l’agent Azure File Sync utilisent déjà le protocole TLS 1.2 par défaut. L’utilisation d’une version antérieure de TLS peut se produire si le protocole TLS 1.2 a été désactivé sur votre serveur ou si un proxy est utilisé. Si vous utilisez un proxy, nous vous recommandons de vérifier la configuration du proxy. Les régions de service Azure File Sync ajoutées après le 01/05/2020 prennent uniquement en charge TLS1.2. Pour plus d’informations, consultez le guide de résolution des problèmes.

L'agent Azure File Sync communique avec votre service de synchronisation de stockage et votre partage de fichiers Azure à l'aide du protocole Azure File Sync REST et du protocole FileREST, qui utilisent tous les deux HTTPS sur le port 443. Azure File Sync n’envoie pas de requêtes non chiffrées sur HTTP.

Les comptes de stockage Azure contiennent un commutateur permettant d'exiger le chiffrement en transit, qui est activé par défaut. Même si le commutateur est désactivé au niveau du compte de stockage, ce qui signifie que des connexions non chiffrées à vos partages de fichiers Azure sont possibles, Azure File Sync utilisera toujours des canaux chiffrés pour accéder à votre partage de fichiers.

La principale raison justifiant de désactiver le chiffrement en transit pour le compte de stockage est la nécessité de prendre en charge une application héritée qui doit être exécutée sur un système d'exploitation plus ancien, tel que Windows Server 2008 R2 ou une ancienne distribution Linux, communiquant directement avec un partage de fichiers Azure. Si l'application héritée communique avec le cache Windows Server du partage de fichiers, le basculement de ce paramètre n'aura aucun effet.

Nous recommandons vivement de vérifier que le chiffrement des données en transit est activé.

Pour plus d’informations sur le chiffrement en transit, voir Exiger un transfert sécurisé dans Stockage Azure.

Chiffrement au repos du partage de fichiers Azure

Toutes les données stockées dans Azure Files sont chiffrées au repos avec Azure Storage Service Encryption (SSE). Cette fonctionnalité fonctionne de la même façon que BitLocker sur Windows : les données sont chiffrées sous le niveau du système de fichiers. Comme les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car codées sur le disque, il n’est pas nécessaire d’avoir accès à la clé sous-jacente sur le client pour lire ou écrire sur le partage de fichiers Azure. Le chiffrement au repos s’applique aux protocoles SMB et NFS.

Par défaut, les données stockées dans Azure Files sont chiffrées avec des clés managées par Microsoft. Microsoft détient ainsi les clés permettant de chiffrer et de déchiffrer les données et se charge de les renouveler régulièrement. Vous pouvez également choisir de gérer vos propres clés, ce qui vous permet de contrôler le processus de renouvellement. Si vous choisissez de chiffrer vos partages de fichiers avec des clés gérées par le client, Azure Files est autorisé à accéder à vos clés pour traiter les demandes de lecture et d’écriture de vos clients. Vous pouvez révoquer cette autorisation à tout moment, mais dans ce cas votre partage de fichiers Azure ne sera plus accessible via SMB ou l’API FileREST.

Azure Files utilise le même schéma de chiffrement que les autres services de stockage Azure, comme le Stockage Blob Azure. Pour plus d’informations sur Azure Storage Service Encryption (SSE), consultez Chiffrement du stockage Azure pour les données au repos.

Niveaux de stockage

Azure Files offre deux niveaux de supports de stockage, SSD et HDD, qui vous permettent de personnaliser vos partages de fichiers en fonction des exigences de performances et de budget de votre scénario :

• SSD (Premium) : les partages de fichiers Premium utilisent des disques SSD et fournissent de manière constante haute performance et faible latence (de l’ordre de quelques millisecondes pour la plupart des opérations d’E/S) pour les charges de travail les plus gourmandes en E/S. Les partages de fichiers Premium sont adaptés à un vaste éventail de charges de travail, comme les bases de données, l’hébergement de site web et les environnements de développement. Les partages de fichiers Premium peuvent être utilisés avec les protocoles SMB (Server Message Block) et NFS (Network File System). Les partages de fichiers Premium sont déployés dans le type de compte de stockage FileStorage et sont disponibles uniquement dans un modèle de facturation provisionnée. Pour plus d’informations sur le modèle de facturation avec approvisionnement pour les partages de fichiers Premium, consultez Comprendre l’approvisionnement des partages de fichiers Premium. Les partages de fichiers Premium offrent un SLA dont la disponibilité est supérieure à celle des partages de fichiers standard (voir « Niveau Premium d’Azure Files »).

• HDD (Standard) : les partages de fichiers standard utilisent des disques durs (HDD) et fournissent une option de stockage économique pour les partages de fichiers à usage général. Les partages de fichiers standard sont déployés dans le type de compte de stockage version 2 universel (GPv2). Pour en savoir plus sur le contrat SLA, consultez la page Contrats de niveau de service Azure (voir « Comptes de stockage »). Les partages de fichiers Standard utilisent un modèle de paiement à l’utilisation qui fournit des tarifs basés sur l’utilisation. Le niveau d’accès d’un partage de fichiers vous permet d’ajuster les coûts de stockage par rapport aux coûts d’E/S par seconde pour optimiser votre facture totale :

  • Les partages de fichiers optimisés pour les transactions offrent le tarif de transaction au coût le plus faible pour les charges de travail lourdes en transactions qui n’ont pas besoin de la faible latence offerte par les partages de fichiers premium. Recommandé lors de la migration des données vers Azure Files.
  • Les partages de fichiers chauds offrent un stockage équilibré et une tarification des transactions pour les charges de travail qui ont une bonne mesure des deux.
  • Les partages de fichiers froids offrent la tarification de stockage la plus économique pour les charges de travail gourmandes en stockage.

Au moment de sélectionner un niveau de support de stockage pour votre charge de travail, tenez compte de vos exigences en matière de performances et d’utilisation. Si votre charge de travail nécessite une latence à un chiffre ou si vous utilisez un support de stockage SSD local, le niveau Premium est probablement le mieux adapté. Si une faible latence ne constitue pas un problème, par exemple si vous avez des partages d’équipe montés localement à partir d’Azure ou mis en mémoire cache localement à l’aide d’Azure File Sync, le stockage standard est peut être plus indiqué du point de vue du coût.

Une fois que vous avez créé un partage de fichiers dans un compte de stockage, vous ne pouvez plus le déplacer dans des niveaux réservés à différents types de compte de stockage. Par exemple, pour déplacer un partage de fichiers optimisé pour les transactions vers le niveau Premium, vous devez créer un nouveau partage de fichiers dans un compte de stockage FileStorage et copier les données de votre partage d’origine vers un nouveau partage de fichiers dans le compte FileStorage. Nous vous recommandons d’utiliser AzCopy pour copier des données entre différents partages de fichiers Azure, mais vous pouvez aussi utiliser des outils comme robocopy sur Windows ou rsync pour macOS et Linux.

Pour plus d’informations, consultez la présentation de la facturation Azure Files.

Disponibilité régionale

Actuellement, les partages de fichiers standard avec des partages de fichiers volumineux activés (jusqu’à une capacité de 100 Tio) présentent certaines limitations.

• Seuls les comptes de stockage localement redondant (LRS) et de stockage redondant interzone (ZRS) sont pris en charge.
• Une fois que vous avez activé les partages de fichiers volumineux sur un compte de stockage, vous ne pouvez pas convertir le compte de stockage pour utiliser le stockage géoredondant (GRS) ou le stockage géoredondant interzone (GZRS).
• Après avoir activé les partages de fichiers volumineux, vous ne pouvez plus les désactiver.

Si vous souhaitez utiliser GRS ou GZRS avec des partages de fichiers Azure SMB standard, consultez Azure Files géo-redondance pour les partages de fichiers volumineux en préversion.

Disponibilité régionale d'Azure File Sync

Pour connaître la disponibilité régionale, consultez Disponibilité des produits par région.

Les régions suivantes vous obligent à demander l’accès à Stockage Azure avant de pouvoir utiliser Azure File Sync avec elles :

• France Sud
• Afrique du Sud Ouest
• Émirats arabes unis Centre

Pour demander l’accès à ces régions, suivez le processus décrit dans ce document.

Redondance

Pour protéger les données de vos partages de fichiers Azure contre la perte ou l’altération des données, Azure Files stocke plusieurs copies de chaque fichier au fur et à mesure de leur écriture. Vous pouvez sélectionner différents degrés de redondance, selon vos besoins. Azure Files prend actuellement en charge les options de redondance des données suivantes :

• Stockage localement redondant (LRS) : avec LRS, chaque fichier est stocké trois fois au sein d’un cluster de stockage Azure. Cela protège de la perte de données due à des défaillances matérielles, telles qu’un lecteur de disque défectueux. Toutefois, si un sinistre tel qu’un incendie ou une inondation se produit dans le centre de données, tous les réplicas d'un compte de stockage utilisant un LRS peuvent être perdus ou irrécupérables.
• Stockage redondant interzone (ZRS) : Avec un ZRS, trois copies de chaque fichier sont stockées. Cependant; ces copies sont physiquement isolées dans trois clusters de stockage distincts dans différentes zones de disponibilité Azure. Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Une écriture sur le stockage n’est pas acceptée tant qu’elle n’est pas écrite sur les clusters de stockage dans les trois zones de disponibilité.
• Stockage géo-redondant (GRS) : Avec un GRS, vous avez deux régions, une région primaire et une région secondaire. Les fichiers sont stockés trois fois au sein d’un cluster de stockage Azure dans la région primaire. Les écritures sont répliquées de façon asynchrone dans une région secondaire définie par Microsoft. Le stockage GRS fournit six copies de vos données réparties entre deux régions Azure. En cas de sinistre majeur, tel que la perte permanente d’une région Azure en raison d’une catastrophe naturelle ou d’un événement similaire, Microsoft effectuera un basculement. Dans ce cas, la région secondaire devient la région primaire, servant toutes les opérations. La réplication entre les régions primaire et secondaire étant asynchrone, en cas de sinistre majeur, les données qui ne sont pas encore répliquées dans la région secondaire seront perdues. Vous pouvez également effectuer le basculement manuel d’un compte de stockage géoredondant.
• Stockage géo-redondant interzone (GZRS) : Vous pouvez considérer le GZRS comme un ZRS, mais avec une géo-redondance. Avec GZRS, les fichiers sont stockés trois fois sur trois clusters de stockage distincts dans la région primaire. Toutes les écritures sont ensuite répliquées de façon asynchrone dans une région secondaire définie par Microsoft. Le processus de basculement pour GZRS fonctionne de la même façon que GRS.

Les partages de fichiers Azure standard jusqu’à 5 Tio prennent en charge les quatre types de redondance. Les partages de fichiers standard supérieurs à 5 Tio prennent uniquement en charge le LRS et le ZRS. Les partages de fichiers Premium Azure prennent uniquement en charge LRS et ZRS.

Les comptes de stockage version 2 (GPv2) à usage général fournissent deux autres options de redondance qu’Azure Files ne prend pas en charge : la lecture d’un stockage géo-redondant accessible (RA-GRS) et la lecture d’un stockage géo-redondant interzone accessible (RA-GZRS). Vous pouvez approvisionner des partages de fichiers Azure dans des comptes de stockage dont ces options sont définies, mais Azure Files ne prend pas en charge la lecture depuis la région secondaire. Les partages de fichiers Azure déployés dans des comptes de stockage RA-GRS ou RA-GZRS sont facturés respectivement comme des GRS ou des GZRS.

Important

Les options de stockage géoredondant et de stockage géoredondant interzone permettent de basculer manuellement le stockage vers la région secondaire. Cette opération est réservée aux situations d’urgence liées à l’utilisation d’Azure File Sync en raison de la probabilité accrue de perte de données. En cas de sinistre, si vous souhaitez procéder à un basculement manuel du stockage, vous devez déposer une demande de support auprès de Microsoft pour qu’Azure File Sync reprenne la synchronisation avec le point de terminaison secondaire.

Migration

Si vous disposez déjà d’un serveur de fichiers Windows 2012 R2 (ou version ultérieure), Azure File Sync peut y être installé directement sans qu’il soit nécessaire de déplacer les données vers un nouveau serveur. Si vous envisagez de migrer vers un nouveau serveur de fichiers Windows dans le cadre de l’adoption d’Azure File Sync, ou si vos données sont actuellement situées sur un stockage NAS (Network-Attached Storage), il existe plusieurs approches possibles de migration pour utiliser Azure File Sync avec ces données. L’approche de migration que vous choisissez dépend de l’emplacement de vos données.

Pour obtenir des instructions détaillées, consultez l’article Vue d’ensemble de la migration de partage de fichiers Azure et Azure File Sync.

Antivirus

Du fait que les antivirus analysent les fichiers pour détecter la présence éventuelle de code malveillant connu, ils peuvent provoquer le rappel de fichiers hiérarchisés, occasionnant ainsi des frais de sortie conséquents. Les fichiers hiérarchisés sont dotés de l’attribut Windows sécurisé FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS. Nous vous recommandons de contacter l’éditeur de votre logiciel pour savoir comment configurer la solution de manière à ignorer la lecture des fichiers dotés cet attribut (la plupart le font automatiquement).

Les solutions antivirus internes de Microsoft, Windows Defender et System Center Endpoint Protection (SCEP), ignorent automatiquement la lecture des fichiers dotés de cet attribut. Nous les avons testés et y avons détecté un problème mineur : lorsque vous ajoutez un serveur à un groupe de synchronisation existant, les fichiers de moins de 800 octets sont rappelés (téléchargés) sur le nouveau serveur. Ces fichiers resteront sur le nouveau serveur et ne seront pas hiérarchisés, car ils ne respectent pas les exigences de taille de niveau (>64 Ko).

Remarque

Les fournisseurs de logiciels antivirus peuvent vérifier la compatibilité entre leur produit et Azure File Sync en utilisant la suite de tests de compatibilité des antivirus avec Azure File Sync, qui est disponible en téléchargement dans le Centre de téléchargement Microsoft.

Sauvegarde

Si la hiérarchisation cloud est activée, vous ne devez pas utiliser de solutions qui sauvegardent directement le point de terminaison du serveur ou une machine virtuelle sur laquelle se trouve le point de terminaison de serveur. La hiérarchisation cloud entraîne le stockage d’un seul sous-ensemble de vos données sur le point de terminaison du serveur, avec le jeu de données complet résidant dans votre partage de fichiers Azure. Selon la solution de sauvegarde utilisée, les fichiers hiérarchisés soit sont ignorés et ne sont pas sauvegardés (parce qu’ils ont l’attribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS défini), soit sont rappelés sur le disque, ce qui entraîne des frais de sortie élevés. Nous vous recommandons d’utiliser une solution de sauvegarde cloud pour sauvegarder le partage de fichiers Azure directement. Pour plus d’informations, consultez À propos de la sauvegarde des partages de fichiers Azure ou contactez votre fournisseur de sauvegarde pour déterminer s’il prend en charge la sauvegarde des partages de fichiers Azure.

Si vous préférez utiliser une solution de sauvegarde locale, les sauvegardes doivent être effectuées sur un serveur dans le groupe de synchronisation pour lequel la hiérarchisation cloud est désactivé et assurer qu’il n’existe aucun fichier hiérarchisé.. Lorsque vous effectuez une restauration, utilisez les options de restauration au niveau du volume ou au niveau du fichier. Les fichiers restaurés en utilisant l’option de restauration au niveau du fichier seront synchronisés avec tous les points de terminaison dans le groupe de synchronisation et les fichiers existants seront remplacés par la version restaurée à partir de la sauvegarde. Les restaurations au niveau du volume ne remplaceront pas les versions plus récentes des fichiers dans le partage de fichiers Azure ou d’autres points de terminaison de serveur.

Remarque

La restauration complète (BMR), la restauration de machine virtuelle, la restauration du système (restauration du système d’exploitation intégrée Windows) et la restauration au niveau des fichiers avec sa version hiérarchisé (cela se produit lorsque les logiciels de sauvegarde sauvegardent un fichier hiérarchisé au lieu d’un fichier complet) peuvent entraîner des résultats inattendus et ne sont pas pris en charge actuellement lorsque la hiérarchisation cloud est activée. Les captures instantanées VSS (y compris l’onglet Versions précédentes) sont prises en charge sur les volumes avec hiérarchisation cloud activée. Toutefois, vous devez activer la compatibilité des versions précédentes via PowerShell. Découvrez comment.

Classification des données

Si vous avez installé un logiciel de classification des données, l’activation de la hiérarchisation cloud peut entraîner un coût accru pour deux raisons :

1. Lorsque la hiérarchisation cloud est activée, vos fichiers les plus fréquemment utilisés sont mis en cache localement, et les moins fréquemment utilisés sont hiérarchisés dans le partage de fichiers Azure dans le cloud. Si votre classification des données analyse régulièrement tous les fichiers du partage de fichiers, les fichiers hiérarchisés dans le cloud doivent être rappelés chaque fois que l’analyse est effectuée.

2. Si le logiciel de classification des données utilise les métadonnées du flux de données d’un fichier, celui-ci doit être entièrement rappelé afin que le logiciel puisse voir la classification.

Ces augmentations du nombre de rappels et de la quantité de données rappelées peuvent augmenter les coûts.

Stratégie de mise à jour de l’agent Azure File Sync

L’agent Azure File Sync est mis à jour régulièrement pour ajouter de nouvelles fonctionnalités et pour résoudre les problèmes. Nous vous recommandons de mettre à jour l’agent Azure File Sync à mesure que de nouvelles versions sont disponibles.

Versions d’agent majeures et mineures

• Les versions majeures de l’agent contiennent souvent de nouvelles fonctionnalités, et la première partie du numéro de version est constituée d’un nombre croissant. Par exemple : 14.0.0.0
• Les versions mineures de l’agent sont également appelées « correctifs », et sont publiées plus fréquemment que les versions majeures. Elles contiennent souvent des correctifs de bogues et des améliorations mineures, mais pas de nouvelles fonctionnalités. Par exemple : 14.1.0.0

Chemins de mise à jour

Il existe cinq moyens testés et approuvés d’installer les mises à jour de l’agent Azure File Sync.

1. Utilisez la fonctionnalité de mise à niveau automatique de l’agent Azure File Sync pour installer les mises à jour de l’agent. L’agent Azure File Sync est mis à niveau automatiquement. Vous pouvez choisir d’installer la dernière version de l’agent lorsqu’elle est disponible ou de procéder à la mise à jour lorsque l’agent actuellement installé est sur le point d’arriver à expiration. Pour en savoir plus, consultez Gestion automatique du cycle de vie des agents.
2. Configurez Microsoft Update pour télécharger et installer automatiquement les mises à jour de l’agent. Nous vous recommandons d’installer toutes les mises à jour d’Azure File Sync pour bénéficier des derniers correctifs pour l’agent du serveur. Microsoft Update rend ce processus transparent, en téléchargeant et en installant automatiquement les mises à jour.
3. Utilisez AfsUpdater.exe pour télécharger et installer les mises à jour de l’agent. AfsUpdater.exe se trouve dans le répertoire d’installation de l’agent. Double-cliquez sur l’exécutable pour télécharger et installer les mises à jour de l’agent. Selon la version de mise en production, vous devrez peut-être redémarrer le serveur.
4. Appliquez un correctif à un agent Azure File Sync existant à l’aide d’un fichier de correctif Microsoft Update, ou d’un exécutable .msp. Le dernier package de mise à jour Azure File Sync peut être téléchargé à partir du catalogue Microsoft Update. L’exécution d’un exécutable .msp permet de mettre à jour votre installation d’Azure File Sync avec la même méthode que celle utilisée automatiquement par Microsoft Update. L’application d’un correctif Microsoft Update effectue la mise à jour sur place d’une installation Azure File Sync.
5. Téléchargez le programme d’installation de l’agent Azure File Sync le plus récent à partir du Centre de téléchargement Microsoft. Pour mettre à niveau une installation existante de l’agent Azure File Sync, désinstallez l’ancienne version, puis installez la dernière version avec le programme d’installation téléchargé. L’inscription du serveur, les groupes de synchronisation et tous les autres paramètres sont gérés par le programme d’installation d’Azure File Sync.

Remarque

Le passage à une version antérieure de l’agent Azure File Sync n’est pas pris en charge. Les nouvelles versions incluent souvent des changements cassants par rapport aux anciennes versions, ce qui rend impossible le processus de passage à une version antérieure. Si vous rencontrez des problèmes avec votre version actuelle de l’agent, contactez le support ou mettez à niveau vers la dernière version disponible.

Gestion automatique du cycle de vie des agents

L’agent Azure File Sync est mis à niveau automatiquement. Vous pouvez sélectionner l’un des deux modes et spécifier un intervalle de maintenance durant lequel une tentative de mise à niveau sur le serveur sera effectuée. Cette fonctionnalité est conçue pour vous aider à gérer le cycle de vie des agents en fournissant une barrière de sécurité qui empêche votre agent d’expirer ou en permettant une configuration qui vous tient informé en toute simplicité.

1. Le paramètre par défaut tente d’empêcher l’agent d’expirer. Sous 21 jours après la publication de la date d’expiration d’un agent, l’agent tentera de se mettre à niveau automatiquement. Il essaye de se mettre à niveau une fois par semaine pendant les 21 jours qui précèdent l’expiration et au cours de l’intervalle de maintenance sélectionné. Même avec cette option, il est toujours nécessaire d’installer les correctifs réguliers de Microsoft Update.
2. Si vous le souhaitez, vous pouvez configurer une mise à niveau automatique de l’agent dès qu’une nouvelle version est disponible (actuellement non applicable aux serveurs en cluster). Cette mise à jour se produira au cours de l’intervalle de maintenance sélectionné et permettra à votre serveur de profiter des nouvelles fonctionnalités et améliorations dès qu’elles sont mises à la disposition générale. Il s’agit du paramètre recommandé et sans encombre. Il fournira les versions majeures de l’agent ainsi que des correctifs de mise à jour réguliers à votre serveur. Chaque agent publié offre une qualité de niveau GA. Si vous sélectionnez cette option, Microsoft vous fournira la dernière version de l’agent en version d’évaluation. Les serveurs en cluster sont exclus. Une fois la version d’évaluation terminée, l’agent sera également disponible sur la page aka.ms/AFS/agent du Centre de téléchargement Microsoft.

Modification du paramètre de mise à niveau automatique

Les instructions suivantes décrivent comment modifier les paramètres une fois l’exécution du programme d’installation terminée si vous devez apporter des modifications.

Ouvrez une console PowerShell et accédez au répertoire où vous avez installé l’agent de synchronisation, puis importez les applets de commande du serveur. Par défaut, cela doit ressembler à ceci :

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Vous pouvez exécuter Get-StorageSyncAgentAutoUpdatePolicy pour vérifier le paramètre de stratégie actuel et déterminer si vous voulez le modifier.

Pour définir le paramètre de stratégie actuel sur la piste de mise à jour différée, vous pouvez utiliser :

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Pour définir le paramètre de stratégie actuel sur la piste de mise à jour immédiate, vous pouvez utiliser :

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Cycle de vie de l’agent et garanties liées à la gestion des changements

Azure File Sync est un service cloud qui permet l’introduction continue de nouvelles fonctionnalités et améliorations. Cela signifie qu’une version de l’agent Azure File Sync n’est prise en charge que pour une durée limitée. Pour faciliter le déploiement, appliquez les règles suivantes pour être sûr de disposer de suffisamment de temps et d’informations pour les mises à jour ou mises à niveau lors de la gestion des modifications :

• Les versions majeures et mineures de l’agent sont prises en charge au moins six mois après leur publication initiale.
• Nous garantissons une période de chevauchement de trois mois minimum entre chaque version majeure d’agent.
• Des avertissements sont émis pour les serveurs inscrits qui utilisent un agent sur le point d’expirer au moins trois mois avant son expiration. Vous pouvez vérifier si un serveur inscrit utilise une version antérieure de l’agent dans la section relative aux serveurs inscrits d’un service de synchronisation de stockage.
• La durée de vie d’une version mineure de l’agent est liée à la version majeure à laquelle elle est associée. Par exemple, lorsque la version 14.0.0.0 de l’agent est configurée pour expirer, les versions 14.*.*.* de l’agent sont toutes configurées pour expirer ensemble.

Notes

Si vous installez une version de l’agent sur le point d’expirer, un avertissement d’expiration s’affiche, mais ne vous empêche pas de l’installer. En revanche, l’installation et la connexion à une version de l’agent ayant expiré ne sont pas prises en charge et seront bloquées.

Étapes suivantes

• Prenez en compte les paramètres de pare-feu et de proxy
• Déployer Azure Files
• Déployer Azure File Sync
• Superviser Azure File Sync