Planifier un déploiement de la fonctionnalité Synchronisation de fichiers Azure

Azure File Sync est un service que vous pouvez utiliser pour mettre en cache plusieurs partages de fichiers Azure sur une instance Windows Server locale 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. Vous pouvez utiliser des partages de fichiers Azure de deux façons. L’option de déploiement que vous choisissez détermine les aspects à prendre en compte lors de la planification de votre déploiement.

• Monter directement un partage de fichiers Azure à l’aide du protocole SMB (Server Message Block) : é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 dans Windows, macOS et Linux. Étant donné que les partages de fichiers Azure sont serverless, vous n’avez aucun serveur de fichiers ou serveur de stockage en réseau (NAS, Network Attached Storage) à gérer lors des déploiements liés à des scénarios de production. 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 mise en cache rapide de votre partage de fichiers Azure.

Concepts de gestion

Dans Azure, une ressource est un élément gérable que vous créez et configurez dans vos abonnements Et groupes de ressources Azure. Les ressources sont proposées par les fournisseurs de ressources, qui sont des services de gestion qui fournissent des types de ressources spécifiques. Pour déployer Azure File Sync, vous allez utiliser deux ressources clés :

• Comptes de stockage, proposés par le Microsoft.Storage fournisseur de ressources. Les comptes de stockage sont des ressources de niveau supérieur qui représentent un pool partagé de stockage, d’E/S par seconde et de débit dans lequel vous pouvez déployer des partages de fichiers classiques ou d’autres ressources de stockage, en fonction du type de compte de stockage. 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. Les partages de fichiers classiques prennent en charge les protocoles de partage de fichiers SMB et NFS, mais vous ne pouvez utiliser Azure File Sync qu’avec des partages de fichiers SMB.

  Remarque

  Azure Files prend également en charge le déploiement de partages de fichiers en tant que ressource Azure de niveau supérieur via le Microsoft.FileShares fournisseur de ressources. Toutefois, étant donné que ces partages de fichiers prennent uniquement en charge le protocole NFS, ils ne sont pas pris en charge par Azure File Sync.

• Services de synchronisation de stockage, proposés par le fournisseur de ressources Microsoft.StorageSync. Les services de synchronisation de stockage agissent en tant que conteneurs de gestion qui vous permettent d’inscrire des serveurs de fichiers Windows et de définir les relations de synchronisation pour Azure File Sync.

Concepts de gestion des partages de fichiers Azure

Les partages de fichiers classiques ou les partages de fichiers déployés dans des comptes de stockage constituent la méthode traditionnelle pour déployer des partages de fichiers pour Azure Files. Ils prennent en charge toutes les fonctionnalités clés prises en charge par Azure Files, notamment les niveaux de média SMB et NFS, SSD et HDD, tous les types de redondance et dans chaque région. Pour en savoir plus sur les partages de fichiers classiques, consultez Partages de fichiers classiques.

Il existe deux types principaux de comptes de stockage utilisés pour les déploiements de partage de fichiers classiques :

• Comptes de stockage provisionnés : les comptes de stockage provisionnés sont distingués à l’aide du type de compte de stockage FileStorage. Les comptes de stockage provisionnés vous permettent de déployer des partages de fichiers classiques provisionnés sur du matériel SSD ou HDD. Les comptes de stockage provisionnés ne peuvent être utilisés que pour stocker des partages de fichiers classiques et ne peuvent pas être utilisés pour stocker d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente et des tables. Nous vous recommandons d’utiliser des comptes de stockage provisionnés pour tous les nouveaux déploiements de partage de fichiers classiques.
• Comptes de stockage avec paiement à l’utilisation : les comptes de stockage à la carte se distinguent par le type de compte de stockage StorageV2. Les comptes de stockage avec paiement à l’utilisation vous permettent de déployer des partages de fichiers de paiement à l’utilisation sur du matériel HDD. Les comptes de stockage avec paiement à l’utilisation peuvent être utilisés pour stocker des partages de fichiers classiques et d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente ou des tables.

Concepts de gestion d'Azure File Sync

Dans un service de synchronisation de stockage, vous pouvez déployer :

• Des serveurs inscrits, qui représente un serveur de fichiers Windows avec une relation d’approbation avec le service de synchronisation de stockage. Les serveurs inscrits peuvent être soit un serveur individuel, soit un cluster, mais un serveur/cluster ne peut être inscrit qu’avec un seul service de synchronisation de stockage à la fois.

• Des groupes de synchronisation, qui définissent la relation de synchronisation entre un point de terminaison cloud et un ou plusieurs points 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.

  • Des points de terminaison cloud, qui représentent des partages de fichiers Azure.
  • Des points de terminaison de serveur, qui représentent des chemins d’accès sur des serveurs inscrits synchronisés avec Azure Files. Un serveur inscrit peut contenir plusieurs points de terminaison de serveur si leurs espaces de noms ne se chevauchent pas.

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 pour un point de terminaison cloud ne démarre qu’une seule fois toutes les 24 heures. Pour plus d’informations, consultez Forum aux questions sur Azure Files et Azure File Sync.

Nombre de services de synchronisation de stockage nécessaires

Un service de synchronisation de stockage est la ressource Azure Resource Manager racine pour Azure File Sync. Il gère les relations de synchronisation entre vos installations Windows Server et les partages de fichiers Azure. Chaque service de synchronisation de stockage peut contenir plusieurs groupes de synchronisation et plusieurs serveurs inscrits.

Chaque instance Windows Server peut être inscrite auprès d’un seul service de synchronisation de stockage. Après l’inscription, le serveur peut participer à plusieurs groupes de synchronisation au sein de ce service de synchronisation de stockage à l’aide d’un principal Resource Manager pour créer des points de terminaison de serveur sur le serveur.

Lorsque vous concevez des topologies Azure File Sync, veillez à isoler clairement les données au niveau du service de synchronisation de stockage. Par exemple, si votre entreprise nécessite des environnements Azure File Sync distincts pour deux unités commerciales distinctes et que vous avez besoin d’une isolation stricte des données entre ces groupes, vous devez créer un service de synchronisation de stockage dédié pour chaque groupe. Évitez de placer des groupes de synchronisation pour les deux groupes d’entreprise au sein du même service de synchronisation de stockage, car cette configuration ne garantit pas l’isolation complète.

Pour plus d’informations sur l’isolation des données à l’aide d’abonnements ou de groupes de ressources distincts dans Azure, reportez-vous aux fournisseurs et types de ressources Azure.

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 aide à déterminer le nombre de comptes de stockage, de partages de fichiers Azure et de ressources de synchronisation dont vous avez besoin. Ces considérations sont pertinentes, même si vos données ne résident pas sur une instance de serveur Windows ou sur le serveur que vous souhaitez utiliser à long terme. La section migration de cet article peut vous aider à déterminer les chemins de migration appropriés pour votre situation.

Dans cette étape, vous déterminez 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 disposez d’un petit nombre 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. De cette façon, vous n’avez besoin que d’un seul partage de fichiers Azure dans le cloud 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 vont au 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 à son tour 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 est 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 d’une synchronisation) peuvent être détectées et synchronisées plus rapidement.

Conseil

Si vous ne connaissez pas le nombre de fichiers et de dossiers dont vous disposez, consultez l’outil TreeSize de JAM Software.

Approche structurée d’une carte 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 de ressources de groupe de synchronisation Azure File Sync que vous allez provisionner. Un groupe de synchronisation lie le partage de fichiers Azure et le dossier sur votre serveur et établit une connexion de synchronisation.

Pour optimiser votre carte et déterminer le nombre de partages de fichiers Azure dont vous avez besoin, passez en revue les limites et bonnes pratiques suivantes :

• 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.

  Faites attention aux limitations d’IOPS d’un compte de stockage lorsque vous déployez des partages de fichiers Azure. Dans l’idéal, une correspondance 1:1 doit être respectée entre les partages de fichiers et les comptes de stockage. Cependant, ce mappage peut ne pas toujours être possible en raison de diverses limites et restrictions, provenant à la fois de votre organisation et d’Azure. Lorsque vous ne pouvez pas déployer un seul partage de fichiers dans un compte de stockage, envisagez les partages qui seront hautement actifs et les partages seront moins actifs. Ne placez pas les partages de fichiers les plus chauds ensemble dans 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

En fonction 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, ainsi que tous les dossiers que vous avez regroupés dans celui-ci, sur un partage de fichiers Azure unique. 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 devez uniquement ajuster les chemins d’accès de partage (tels que les partages SMB ou NFS) que vous pouvez avoir sur les dossiers de serveur local que vous avez maintenant modifié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 possible que, dans votre situation, un ensemble de dossiers puisse être synchronisé logiquement avec le même partage de fichiers Azure (à l’aide de l’approche racine commune mentionnée précédemment). Mais il peut encore être préférable de regrouper des dossiers afin 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 fractionner vos partages locaux et synchroniser sur d’autres serveurs locaux pour ajouter la possibilité de synchroniser avec 30 partages de fichiers Azure supplémentaires par serveur supplémentaire.

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 les cibles de mise à l’échelle Azure File Sync.

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

Scénario de synchronisation	Pris en charge	Observations (ou limitations)	Solution (ou méthode de contournement)
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) prend en charge la synchronisation 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) sur un partage de fichiers Azure cible. À compter du plus grand disque/volume, les exigences de stockage locales sont utiles. Configurez la hiérarchisation cloud pour hiérarchiser toutes les données dans le cloud afin de libérer 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é. Poursuivez les étapes un par un jusqu’à ce que toutes les données sont hiérarchisé vers le cloud ou migrées. 2) Ciblez un volume racine (disque) à la fois. Utilisez la hiérarchisation cloud pour hiérarchiser toutes les données dans le partage de fichiers Azure cible. Supprimez le point de terminaison du serveur du groupe de synchronisation, recréez le point de terminaison avec le prochain volume racine/disque, synchronisez, puis répétez le processus. Notez que vous devrez peut-être réinstaller l’agent. 3) Recommandez d’utiliser plusieurs partages de fichiers Azure cibles (identiques ou différents comptes de stockage, en fonction des exigences de performances).
Serveur de fichiers avec un seul volume et plusieurs partages sur le même partage de fichiers Azure cible (consolidation)	Oui	Vous ne pouvez pas avoir plusieurs points de terminaison de serveur par serveur inscrit synchronisé avec le même partage de fichiers Azure cible (identique au scénario précédent).	Synchronisez la racine du volume qui contient plusieurs partages ou dossiers de niveau supérieur.
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 un délai de 100 millions d’éléments (fichiers et dossiers) par partage. Il est préférable de rester en dessous de 20 ou 30 millions par action.	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 regroupement de partages et la synchronisation de volume pour réduire le nombre de dossiers racine ou de niveau supérieur à la source. 3) Utilisez des serveurs Azure File Sync locaux et fractionnez ou déplacez des données vers ces serveurs pour contourner les limitations sur l’instance source de Windows Server.
Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un autre compte de stockage (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 un délai de 100 millions d’éléments (fichiers et dossiers) par partage. Il est préférable de rester en dessous de 20 ou 30 millions par action.	Identique à l’approche précédente.
Plusieurs serveurs de fichiers avec un seul volume racine ou un partage vers le même partage de fichiers Azure cible (consolidation)	Non	Un groupe de synchronisation ne peut pas utiliser un 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 premier scénario, avec la prise en compte supplémentaire du ciblage d’un serveur de fichiers à la fois.
Topologie inter-locataires (utilisant l'identité gérée entre les locataires)	Non	Le service de synchronisation de stockage, la ressource de serveur (serveur avec Azure Arc ou machine virtuelle Azure), l’identité managée et les affectations RBAC sur le compte de stockage doivent toutes se trouver dans le même locataire Microsoft Entra. Les topologies multilocataires ne sont pas prises en charge.	Les configurations entre locataires échouent à l’authentification et à l’autorisation, et le serveur ne peut pas se connecter. Pour continuer, vérifiez que toutes les ressources (service de synchronisation, serveur, identité managée et affectations RBAC) sont créées dans le même locataire Microsoft Entra.

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 une table qui enregistre vos pensées afin de pouvoir vous y référer lorsque vous en avez besoin. Rester organisé est important, car la perte de détails de votre plan de mappage peut se produire facilement lorsque vous approvisionnez de nombreuses ressources Azure à la fois. 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 cartographie des espaces 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 d’arrière-plan chargé d’analyser les modifications apportées aux points de terminaison de serveur et de lancer des sessions de synchronisation
• 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	Version RTM	Éditions prises en charge	Options de déploiement prises en charge
Windows Server 2025	26100	Azure, Datacenter, Essentials, Standard et IoT	Complète et Minimale
Windows Server 2022	20348	Azure, Datacenter, Essentials, Standard et IoT	Complète et Minimale
Windows Server 2019	17763	Datacenter, Essentials, Standard et IoT	Complète et Minimale
Windows Server 2016	14393	Datacenter, Essentials, Standard et Storage Server	Complète et Minimale

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 tous ces attributs :

• Au moins un processeur.
• Un minimum de 2 Gio de mémoire. Si le serveur est exécuté sur une machine virtuelle sur laquelle la mémoire dynamique est activée, configurez la machine virtuelle avec un minimum de 2,048 Mio de mémoire.
• Un volume attaché localement formaté avec le système de fichiers NTFS.

Pour la plupart des charges de travail de production, nous déconseillons de configurer un serveur de synchronisation dans Azure File Sync en se contentant de la configuration minimale requise.

Ressources système recommandées

Comme pour toute fonctionnalité ou application serveur, l’échelle de déploiement détermine les ressources système requises pour Azure File Sync. Un déploiement sur serveur important nécessite des ressources système importantes.

Pour Azure File Sync, le nombre d’objets répartis sur les points de terminaison de serveur et par l’attrition sur le jeu de données détermine l’échelle. Un serveur unique peut avoir des points de terminaison de serveur dans plusieurs groupes de synchronisation. Le nombre d’objets répertoriés dans le tableau suivant correspond à 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. En raison de cette configuration, des espaces de noms plus volumineux nécessitent davantage de mémoire pour maintenir de bonnes performances. Une plus grande attrition nécessite davantage de processeurs à traiter.

Le tableau suivant fournit 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 du 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. 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 de processeurs.

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 de l’applet de commande 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 (mais pas toutes) les fonctionnalités mentionnées dans cet article. Nous vous recommandons de lire attentivement le reste de cette section pour vous assurer que votre déploiement se passe bien.

Vous pouvez installer l’applet de commande d’évaluation en installant le module Az PowerShell. Pour obtenir des instructions, consultez Installer Azure PowerShell.

Utilisation

Vous pouvez appeler l’outil d’évaluation en effectuant des vérifications système, des vérifications de 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 dans un fichier .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 (DAS), signifie que le système d’exploitation Windows Server est propriétaire du système de fichiers. Vous pouvez fournir le DAS 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 en utilisant iSCSI.

Seuls les volumes NTFS sont pris en charge. ReFS, FAT, FAT32 et les 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	Remarques
Listes ACL	entièrement prise en charge	Azure File Sync conserve les listes de contrôle d’accès discrétionnaires de style Windows. Windows Server applique ces listes de contrôle d’accès sur les points de terminaison de serveur. Vous pouvez également appliquer des listes de contrôle d’accès lorsque vous montez directement le partage de fichiers Azure, mais cette méthode nécessite une configuration supplémentaire. Pour plus d’informations, consultez la section Identité plus loin dans cet article.
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é	Les exemples sont des dossier DfrsrPrivate et DFSRoots du système de fichiers distribués (DFS).
Points d’analyse	Ignoré
Compression NTFS	Partiellement pris en charge	Azure File Sync ne prend pas en charge les points de terminaison serveur situés sur un volume qui compresse le répertoire d’informations de volume système (SVI).
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.

Remarque

Compression NTFS avec hiérarchisation cloud

L’utilisation de la compression NTFS sur les fichiers hiérarchisé peut entraîner un impact significatif sur les performances. Il est recommandé de ne pas utiliser la hiérarchisation cloud avec des fichiers compressés.

Si les fichiers compressés ont déjà été hiérarchisé, ils doivent être décompressés après avoir rappelé les données du cloud en exécutant :

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

L’utilisation de la compression NTFS sur les fichiers hiérarchisé peut entraîner un impact significatif sur les performances. Il est recommandé de ne pas utiliser la hiérarchisation cloud avec des fichiers compressés.

Vous pouvez décompresser des fichiers à l’aide de la commande compact .

Sur Windows Server 2019 ou version ultérieure, la commande compact ignore les fichiers hiérarchisé. Vous devez donc vous rappeler d’abord le fichier avant de le décompresser.

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Si les rappels de fichiers entraînent des problèmes d’espace disque limité, vous devez attendre que le processus de hiérarchisation en arrière-plan démarre et qu'il reclasse le fichier avant de rappeler plus de fichiers ou reclasse le fichier après la décompression en exécutant le cmdlet.

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>

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

Fichier/Dossier	Remarque
pagefile.sys	Fichier spécifique à un système
Desktop.ini	Fichier spécifique à un 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éder au fichier de verrouillage de base de données
635D02A9D91C401B97884B82B3BCDAEA.*	Fichier de synchronisation interne
\System Volume Information	Dossier spécifique à un volume
$RECYCLE.BIN	Dossier
\SyncShareState	Dossier pour la synchronisation
.SystemShareInformation	Dossier pour la synchronisation dans un partage de fichiers Azure

Remarque

Bien qu’Azure File Sync prenne 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). Les fichiers journaux et les bases de données doivent être synchronisés, et ils peuvent sortir de la synchronisation pour diverses raisons susceptibles d’entraîner une altération de la base de données.

Espace libre 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 pour votre 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

L’exemple suivant montre comment estimer la quantité d’espace libre dont vous avez besoin 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 (et vous souhaitez intégralement les 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 %.

• 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)

  Pour tirer pleinement parti de la hiérarchisation cloud, nous vous recommandons d’utiliser des tailles de cluster NTFS plus petites (moins de 64 Kib), car chaque fichier hiérarchisé occupe un cluster. En outre, NTFS alloue l’espace occupé par les fichiers hiérarchisé. Cet espace ne s’affiche dans aucune interface utilisateur.

• 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)

• 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)

• 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 quantité à n’importe quel espace libre dont vous pensez avoir besoin pour ce disque.

Clustering de basculement

Azure File Sync prend en charge le clustering de basculement Windows Server 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éployer d’un serveur de fichiers en cluster à deux nœuds.

Le seul scénario pris en charge par Azure File Sync est le scénario Cluster de basculement Windows Server avec disques en cluster. Le clustering de basculement n’est pas pris en charge sur le serveur de fichiers avec montée en puissance parallèle, les volumes partagés de cluster (CSV) ou les disques locaux.

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 2025, Windows Server 2022, Windows Server 2019 et Windows Server 2016

La déduplication des données est prise en charge que la hiérarchisation cloud soit activée ou désactivée sur un ou plusieurs points de terminaison de serveur sur le volume pour Windows Server 2025, Windows Server 2022, Windows Server 2019 et Windows Server 2016. 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.

Lorsque vous activez la déduplication des données sur un volume avec la hiérarchisation cloud activée, les fichiers optimisés pour la déduplication dans l’emplacement du point de terminaison de serveur sont hiérarchisé de la même façon qu’un fichier normal, en fonction des paramètres de stratégie pour la hiérarchisation cloud. Après avoir hiérarchisé les fichiers optimisés pour la déduplication, le travail de nettoyage de la mémoire de déduplication des données s’exécute automatiquement. Il récupère l’espace disque en supprimant les blocs inutiles que d’autres fichiers sur le volume ne référencent plus.

Dans certains cas où la déduplication des données est installée, l’espace de volume disponible peut augmenter davantage que prévu après le déclenchement du processus de nettoyage de la mémoire de déduplication des données. L’exemple suivant décrit le fonctionnement de l’espace de volume :

1. La stratégie d’espace libre pour la hiérarchisation cloud est définie sur 20 %.
2. Azure File Sync est averti lorsque l’espace libre est faible (supposons 19 %).
3. La hiérarchisation détermine qu’il faut libérer 1 % d’espace supplémentaire, mais vous souhaitez 5 % de plus, vous passez donc à 25 % (par exemple, 30 Gio).
4. Les fichiers sont hiérarchisé jusqu’à atteindre 30 Gio.
5. Dans le cadre de l’interopérabilité avec la déduplication des données, Azure File Sync lance le nettoyage de la mémoire à la fin de la session de hiérarchisation.

Les économies de volume s’appliquent uniquement 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, vous devez installer la mise à jour Windows KB4520062 - Octobre 2019 ou une mise à jour cumulative plus récente.

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 Server 2012 R2. Si vous activez la déduplication des données sur un volume, vous devez désactiver la hiérarchisation cloud.

Remarques

• Si vous installez la déduplication des données 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 vous activez la déduplication des données sur un volume après avoir activé la hiérarchisation cloud, le travail d’optimisation de la déduplication initiale optimise les fichiers sur le volume qui ne sont pas déjà hiérarchisés. Ce travail a l’impact suivant sur la hiérarchisation cloud :

  • La stratégie d’espace libre continue de hiérarchiser les fichiers en fonction de l’espace libre sur le volume à l’aide de la carte thermique.
  • La stratégie de date ignore la hiérarchisation des fichiers qui peuvent être autrement éligibles à la hiérarchisation, car le travail d’optimisation de la déduplication accède aux fichiers.

• En ce qui concerne les travaux d’optimisation de la déduplication en cours, le paramètre MinimumFileAgeDays de la déduplication des données retarde la hiérarchisation cloud avec la stratégie de données, si le fichier n’est pas déjà hiérarchisé.

  • Par exemple, si le paramètre MinimumFileAgeDays est de 7 jours et que la stratégie de données pour la hiérarchisation cloud est de 30 jours, la stratégie de données hiérarchise les fichiers après 37 jours.
  • Une fois qu’Azure File Sync hiérarchise un fichier, le travail d’optimisation de la déduplication ignore le fichier.

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

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

  Le serveur conserve ses paramètres de configuration Azure File Sync lorsque l’agent est désinstallé et réinstallé.

Système de fichiers distribués (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).

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.

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. Toutefois, vous devez utiliser DFS-R et Azure File Sync ensemble dans les scénarios suivants :

• 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 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 :

• La hiérarchisation cloud d’Azure File Sync doit être désactivée sur les volumes avec des dossiers répliqué DFS-R.
• Les points de terminaison de serveur ne doivent pas être configurés sur des dossiers de réplication DFS-R en lecture seule.
• 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 des espaces de noms DFS et 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ées 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, Windows Search ignore les fichiers hiérarchisés et ne les indexe pas. Windows Search indexe correctement les fichiers non hiérarchisés.

Les clients Windows provoquent des rappels lorsqu’ils recherchent 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 HSM

Vous ne devez pas utiliser d’autres solutions de gestion de stockage hiérarchique (HSM) 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 ces facteurs dans votre infrastructure :

• Windows Server et la configuration du disque sous-jacent
• Bande passante réseau entre le serveur et le stockage Azure
• Taille du fichier
• Taille totale du jeu de données
• Activité sur le jeu de données

Azure File Sync fonctionne au niveau du fichier. Les caractéristiques de performances d’une solution basée sur Azure File Sync sont mieux mesurées dans le nombre d’objets (fichiers et répertoires) traités par seconde.

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

Identité

L’administrateur qui inscrit le serveur et crée le point de terminaison cloud doit être membre du rôle de gestion Administrateur Azure File Sync, Propriétaire ou Contributeur du service de synchronisation de stockage. Vous pouvez configurer ce rôle sous Contrôle d’accès (IAM) sur la page du portail Microsoft Azure pour le service de synchronisation du stockage.

Lors de l’attribution du rôle Administrateur Azure File Sync, procédez comme suit pour garantir le privilège minimum.

1. Sous l’onglet Conditions, sélectionnez Autoriser les utilisateurs à attribuer des rôles sélectionnés aux principaux sélectionnés uniquement (moins de privilèges).

2. Cliquez sur Sélectionner des rôles et des principaux , puis sélectionnez Ajouter une action sous Condition #1.

3. Sélectionnez Créer une attribution de rôle, puis cliquez sur Sélectionner.

4. Sélectionnez Ajouter une expression, puis sélectionnez Demander.

5. Sous Source de l’attribut, sélectionnez Id de définition de rôle sous Attribut, puis ForAnyOfAnyValues :GuidEquals sous Opérateur.

6. Sélectionnez Ajouter des rôles. Ajoutez des rôles Lecteur et Accès aux données, Contributeur privilégié aux données de fichier de stockage et Contributeur de compte de stockage , puis sélectionnez Enregistrer.

Azure File Sync fonctionne avec votre identité basée sur Active Directory standard sans configuration spéciale au-delà de la configuration de synchronisation. Lorsque vous utilisez Azure File Sync, l’attente générale est que la plupart des accès passent par les serveurs de mise en cache Azure File Sync, plutôt que via le partage de fichiers Azure. Étant donné que les points de terminaison de serveur se trouvent sur Windows Server et que Windows Server prend en charge les listes de contrôle d’accès de type Active Directory et Windows, vous n’avez rien d’autre à faire que de vous assurer que les serveurs de fichiers Windows enregistrés auprès du service de synchronisation du 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 réplique ces listes de contrôle d’accès 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 vous assurer qu’il vous est possible d’appliquer vos autorisations Active Directory sur votre partage de fichiers directement dans le cloud. Pour effectuer cette configuration, vous devez effectuer une jonction de domaine de votre compte de stockage à votre instance Active Directory locale, tout comme vos serveurs de fichiers Windows sont joints au domaine. Pour en savoir plus sur la jonction à un domaine de votre compte de stockage à une instance Active Directory appartenant au client, consultez Vue d’ensemble de l’authentification basée sur l’identité Azure Files pour l’accès SMB.

Important

La jonction de domaine de votre compte de stockage à Active Directory n’est pas nécessaire pour déployer correctement Azure File Sync. C’est une étape facultative qui permet au partage de fichiers Azure d’appliquer des listes de contrôle d’accès locales lorsque les utilisateurs montent directement le partage de fichiers Azure.

Réseaux

L’agent Azure File Sync communique avec votre service de synchronisation de stockage et votre partage de fichiers Azure en utilisant le protocole REST d’Azure File Sync et le protocole FileREST. Ces deux protocoles utilisent toujours 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. Azure File Sync prend en charge l’option de routage réseau par défaut, le routage Microsoft.

En fonction de la stratégie de votre organisation ou d’exigences réglementaires particulières, vous pourriez avoir besoin d’une communication plus restrictive avec Azure. Azure File Sync propose plusieurs mécanismes permettant de configurer les réseaux. En fonction de vos besoins, vous pouvez :

• Canalisez la synchronisation et le trafic de chargement/téléchargement des fichiers sur Azure ExpressRoute ou un réseau privé virtuel (VPN) Azure.
• Utilisez les fonctionnalités réseau Azure et d’Azure Files, 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

Si vous souhaitez communiquer avec votre partage de fichiers Azure sur SMB, mais que le port 445 est bloqué, envisagez d’utiliser SMB sur QUIC. Cette méthode offre un VPN sans configuration pour l’accès SMB à vos partages de fichiers Azure via le protocole de transport QUIC sur le port 443. Bien qu’Azure Files ne prenne 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 Édition Azure en utilisant Azure File Sync. Pour découvrir plus d’informations sur cette option, consultez SMB sur QUIC.

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

Chiffrement

Azure File Sync propose trois couches de chiffrement : 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

Deux stratégies de chiffrement des données sur Windows Server fonctionnent généralement avec Azure File Sync :

• Chiffrement sous le système de fichiers, de sorte que le système de fichiers et toutes les données écrites sont chiffrées
• Chiffrement au sein du format de fichier lui-même

Ces méthodes ne sont pas mutuellement exclusives. Vous pouvez choisir de les utiliser ensemble, car l’objectif du chiffrement est différent.

Pour assurer le chiffrement sous le système de fichiers, Windows Server fournit une boîte de réception BitLocker. BitLocker est entièrement transparent pour Azure File Sync. Les principales raisons d’utiliser un mécanisme de chiffrement comme BitLocker sont les suivantes :

• Empêcher l’exfiltration physique des données de votre centre de données local par quelqu’un qui vole les disques
• Empêcher le chargement indépendant d’un système d’exploitation non autorisé pour effectuer des lectures et des écritures non autorisées sur vos données

Pour découvrir plus d’informations, consultez Vue d’ensemble de BitLocker.

Les produits partenaires qui fonctionnent de la même façon que BitLocker, en ce sens qu’ils se trouvent sous le volume NTFS, doivent 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 tâche en mode natif, mais elles ne le font généralement pas.

Les exemples de méthodes de chiffrement du flux de données du fichier sont Azure Information Protection, Azure Rights Management (Azure RMS) et Active Directory Rights Management Services. La principale raison d’utiliser un mécanisme de chiffrement comme Azure Information Protection ou Azure RMS consiste à empêcher l’exfiltration des données de votre partage de fichiers par des personnes qui le copient vers d’autres emplacements (comme une clé USB) ou de 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 partenaires situées au-dessus du système de fichiers mais en dessous du flux de données du fichier.

Chiffrement en transit

L’agent Azure File Sync communique avec votre service de synchronisation de stockage et votre partage de fichiers Azure en utilisant le protocole REST d’Azure File Sync et le protocole FileREST. Ces deux protocoles utilisent toujours 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 pour exiger le chiffrement en transit. Ce commutateur est activé par défaut. Même si le commutateur est désactivé au niveau du compte de stockage et que les connexions non chiffrées à vos partages de fichiers Azure sont possibles, Azure File Sync utilise toujours des canaux chiffrés pour accéder à votre partage de fichiers.

La principale raison de désactiver le chiffrement en transit pour le compte de stockage consiste à prendre en charge une application héritée qui communique directement avec le partage de fichiers Azure. Une telle application doit être exécutée sur un système d’exploitation plus ancien, tel que Windows Server 2008 R2 ou une distribution Linux plus ancienne. Si l’application héritée se connecte au cache Windows Server du partage de fichiers, la modification de ce paramètre n’a aucun effet.

Nous vous recommandons vivement d’activer le chiffrement des données en transit. Pour plus d’informations sur le chiffrement en transit, consultez Exiger un transfert sécurisé pour garantir des connexions sécurisées.

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. Vous utilisez peut-être une version antérieure de TLS si vous avez désactivé le protocole TLS 1.2 sur votre serveur ou si vous utilisez un proxy.

Si vous utilisez un proxy, nous vous recommandons de vérifier la configuration du proxy. Les régions du service Azure File Sync ajoutées après le 1er mai 2020 prennent uniquement en charge le protocole TLS 1.2. Pour plus d’informations, consultez le guide de résolution des problèmes.

Chiffrement au repos du partage de fichiers Azure

Toutes les données stockées dans Azure Files sont chiffrées au repos via le chiffrement côté service stockage Azure (SSE). SSE 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.

Étant donné que les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car elles sont encodées sur disque, vous n’avez pas besoin d’accéder à la clé sous-jacente sur le client pour lire ou écrire dans 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. Avec les clés gérées par Microsoft, Microsoft contient les clés pour chiffrer et déchiffrer les données. Microsoft est responsable de la rotation de ces clés 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. Avec les clés gérées par le client, vous pouvez révoquer cette autorisation à tout moment. Mais sans cette autorisation, votre partage de fichiers Azure n’est plus accessible via SMB ou l’API FileREST.

Azure Files utilise le même schéma de chiffrement que les autres services stockage Azure, tels que Stockage Blob Azure. Pour en savoir plus sur Azure Storage SSE, consultez Chiffrement Stockage Microsoft Azure pour les données au repos.

Niveaux de stockage

Azure Files offre deux niveaux multimédias de stockage : disque SSD (SSD) et disque dur (HDD). Ces niveaux vous permettent d’adapter vos partages aux exigences de performances et de prix de votre scénario :

• SSD (Premium) : les partages de fichiers SSD fournissent des hautes performances et une faible latence cohérentes, en millisecondes à un chiffre pour la plupart des opérations d’E/S, pour les charges de travail gourmandes en E/S. Les partages de fichiers SSD conviennent à un large éventail de charges de travail, telles que les bases de données, l’hébergement de sites web et les environnements de développement.

  Vous pouvez utiliser des partages de fichiers SSD avec les protocoles SMB et NFS. Les partages de fichiers SSD sont disponibles dans les modèles de facturation v2 approvisionnés et v1 approvisionnés . Les partages de fichiers SSD offrent un SLA de disponibilité plus élevé que les partages de fichiers HDD.

• HDD (standard) : les partages de fichiers HDD fournissent une option de stockage économique pour les partages de fichiers à usage général. Les partages de fichiers HDD sont disponibles avec les modèles de facturation provisionnés v2 et paiement à l'utilisation, bien que nous recommandions le modèle provisionné v2 pour les nouveaux déploiements de partages de fichiers. Pour plus d’informations sur le SLA, consultez la page Azure SLA pour les services en ligne.

Lorsque vous sélectionnez un niveau multimédia pour votre charge de travail, tenez compte de vos besoins 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, les partages de fichiers SSD sont probablement les mieux adaptés. Si la faible latence n’est pas autant problématique, les partages de fichiers HDD peuvent être mieux adaptés du point de vue des coûts. Par exemple, une faible latence peut être moins préoccupante avec les partages d’équipe montés sur site à partir d’Azure ou mis en cache sur site via Azure File Sync.

Après avoir créé un partage de fichiers dans un compte de stockage, vous ne pouvez pas le déplacer directement vers un autre niveau multimédia. Par exemple, pour déplacer un partage de fichiers HDD vers le niveau multimédia SSD, vous devez créer un nouveau partage de fichiers SSD et copier les données de votre partage d'origine vers le nouveau partage de fichiers.

Vous trouverez plus d’informations sur les niveaux de support SSD et HDD dans Comprendre les modèles de facturation Azure Files et Comprendre et optimiser les performances du partage de fichiers Azure.

Disponibilité régionale d’Azure File Sync

Pour connaître la disponibilité régionale, consultez Disponibilité des produits par région et recherchez Comptes de stockage.

Dans les régions suivantes, vous devez demander l’accès au Stockage Azure avant de pouvoir utiliser Azure File Sync :

• 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 article.

Redondance

Pour protéger les données de vos partages de fichiers Azure contre la perte de données ou la corruption, Azure Files stocke plusieurs copies de chaque fichier lors de leur écriture. Selon vos besoins, vous pouvez sélectionner des degrés de redondance. Azure Files prend actuellement en charge les options suivantes pour la redondance des données :

• Stockage localement redondant (LRS) : avec redondance locale, chaque fichier est stocké trois fois dans un cluster de stockage Azure. Cette approche permet de protéger contre la perte de données en raison d’erreurs matérielles, telles qu’un lecteur de disque incorrect. Toutefois, si une catastrophe telle que l’incendie ou l’inondation se produit dans le centre de données, tous les réplicas d’un compte de stockage qui utilise LRS peuvent être perdus ou irrécupérables.

• Stockage redondant interzone (ZRS) : avec redondance de zone, trois copies de chaque fichier sont stockées. Toutefois, ces copies sont physiquement isolées dans trois clusters de stockage distincts dans les zones de disponibilité Azure. Les zones de disponibilité sont des emplacements physiques uniques dans une région Azure. Chaque zone 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éoredondant (GRS) : avec redondance géographique, vous disposez d’une région primaire et d’une région secondaire. Les fichiers sont stockés trois fois dans 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.

  La géoredondance fournit six copies de vos données réparties entre les deux régions Azure. Si une catastrophe majeure se produit, telle que la perte permanente d’une région Azure en raison d’une catastrophe naturelle ou d’un autre événement similaire, Microsoft effectue un basculement. Dans ce cas, le secondaire devient le principal et sert toutes les opérations.

  Étant donné que la réplication entre les régions primaires et secondaires est asynchrone, si une catastrophe majeure se produit, les données qui ne sont pas encore répliquées dans la région secondaire sont perdues. Vous pouvez également effectuer le basculement manuel d’un compte de stockage géoredondant.

• Stockage géoredondant interzone (GZRS) : avec la redondance géographique, 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 la redondance de zone géographique fonctionne de la même façon que pour la géoredondance.

Les partages de fichiers HDD prennent en charge les quatre types de redondance. Les partages de fichiers SSD prennent uniquement en charge LRS et ZRS.

Les comptes de stockage avec paiement à l’utilisation fournissent deux autres options de redondance qu’Azure Files ne prend pas en charge : le stockage géoredondant d’accès en lecture (RA-GRS) et le stockage géoredondant avec accès en lecture (RA-GZRS). Vous pouvez approvisionner des partages de fichiers Azure dans des comptes de stockage avec ces options définies, mais Azure Files ne prend pas en charge la lecture à partir de 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 en tant que géoredondants ou géozone redondants, respectivement.

Important

Le stockage géoredondant et géoredondant interzone peut basculer manuellement le stockage vers la région secondaire. Nous vous déconseillons cette approche (en dehors d’un sinistre) lorsque vous utilisez Azure File Sync en raison de la probabilité accrue de perte de données. Si un sinistre se produit et que vous souhaitez lancer un basculement manuel du stockage, vous devez ouvrir un cas 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’un serveur de fichiers existant dans Windows Server 2012 R2 ou une version ultérieure, vous pouvez installer directement Azure File Sync en place. Vous n’avez pas besoin de déplacer des 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 NAS, 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 Migrer vers des partages de fichiers Azure SMB.

Logiciel 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é ont l’attribut Windows sécurisé FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS défini. Nous vous recommandons de consulter votre fournisseur de logiciels pour savoir comment configurer sa solution pour ignorer la lecture des fichiers dont cet attribut est défini. Beaucoup le font automatiquement.

Pendant les analyses à la demande, les solutions antivirus Microsoft Defender et System Center Endpoint Protection ignorent automatiquement la lecture des fichiers dont cet attribut est défini. 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 restent sur le nouveau serveur et ne seront pas hiérarchisés, car ils ne respectent pas les exigences de taille de hiérarchisation (plus de 64 Ko).

Remarque

Microsoft Defender et System Center Endpoint Protection ignorent uniquement la lecture lors des analyses à la requête. Cela ne s’applique pas à la protection en temps réel (RTP).

Les fournisseurs de logiciels antivirus peuvent vérifier la compatibilité entre leurs produits et Azure File Sync en utilisant la suite de tests de compatibilité des antivirus avec Azure File Sync dans le Centre de téléchargement Microsoft.

Sauvegarde

Si vous activez la hiérarchisation cloud, n’utilisez pas de solutions qui sauvegardent directement le point de terminaison du serveur ou une machine virtuelle qui contient le point de terminaison du serveur.

La hiérarchisation cloud entraîne uniquement le stockage d’un sous-ensemble de vos données sur le point de terminaison du serveur. Le jeu de données complet réside dans votre partage de fichiers Azure. Selon la solution de sauvegarde que vous utilisez, les fichiers hiérarchisé sont les suivants :

• Ignorés et non sauvegardés, car l’attribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS est défini
• 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 l’article À propos de la sauvegarde Azure Files. Ou demandez à votre fournisseur de sauvegarde s’il prend en charge la sauvegarde des partages de fichiers Azure.

Si vous préférez utiliser une solution de sauvegarde locale, effectuez les sauvegardes sur un serveur dans le groupe de synchronisation pour lequel la hiérarchisation cloud est désactivée. Vérifiez 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 via l’option de restauration au niveau du fichier sont synchronisés avec tous les points de terminaison du groupe de synchronisation. Les fichiers existants sont remplacés par la version restaurée à partir de la sauvegarde. Les restaurations au niveau du volume ne remplacent 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, la restauration de machine virtuelle, la restauration du système d’exploitation (restauration du système d’exploitation intégrée Windows) et la restauration au niveau du fichier avec sa version hiérarchisée peut entraîner des résultats inattendus. (La restauration au niveau du fichier se produit lorsque le logiciel de sauvegarde sauvegarde un fichier hiérarchisé au lieu d’un fichier complet.) Elles ne sont actuellement pas prises en charge lorsque la hiérarchisation cloud est activée.

Les instantanés VSS, notamment l’onglet Versions précédentes, sont pris en charge sur les volumes pour lesquels la hiérarchisation cloud est 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 :

• Une fois la hiérarchisation cloud activée, vos fichiers les plus chauds sont mis en cache localement. Vos fichiers les plus froids sont hiérarchisés vers 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 qu’ils sont analysés.
• 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 détecter 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 : 18.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 : 18.2.0.0.

Mettre à jour les chemins d’accès

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

• Utiliser la fonctionnalité de mise à jour automatique Azure File Sync pour installer les mises à jour de l’agent : l’agent Azure File Sync est automatiquement mis à jour. 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 la section suivante, Gestion automatique du cycle de vie de l’agent.
• Configurer Microsoft Update pour télécharger et installer automatiquement les mises à jour de l’agent : nous vous recommandons d’installer chaque mise à jour Azure File Sync pour vous assurer que vous avez accès aux derniers correctifs pour l’agent de serveur. Microsoft Update rend ce processus transparent en téléchargeant et en installant automatiquement les mises à jour.
• Utiliser AfsUpdater.exe pour télécharger et installer les mises à jour de l’agent : le fichier AfsUpdater.exe se trouve dans le répertoire d’installation de l’agent. Double-cliquez sur le fichier 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.
• Appliquer un correctif à un agent Azure File Sync existant à l’aide d’un fichier correctif Microsoft Update ou d’un fichier exécutable. msp : vous pouvez télécharger le dernier package de mise à jour Azure File Sync à partir du catalogue Microsoft Update. L’exécution d’un fichier exécutable .msp met à jour votre installation Azure File Sync avec la même méthode que Microsoft Update utilise automatiquement. L’application d’un correctif Microsoft Update effectue la mise à jour sur place d’une installation Azure File Sync.
• Télécharger le programme d’installation de l’agent Azure File Sync le plus récent : vous pouvez obtenir le programme d’installation dans le Centre de téléchargement Microsoft. Pour mettre à jour 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é. Les paramètres de l’agent (par exemple, l’inscription du serveur et les points de terminaison de serveur) sont conservés lorsque l’agent Azure File Sync est désinstallé.

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 technique ou effectuez une mise à jour vers la dernière version disponible.

Gestion automatique du cycle de vie de l’agent

L’agent Azure File Sync est mis à jour automatiquement. Vous pouvez sélectionner l’un des deux modes suivants et spécifier une fenêtre de maintenance durant laquelle une tentative de mise à jour 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é.

• 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 à jour automatiquement. Il démarre une tentative de mise à jour une fois par semaine dans les 21 jours avant l’expiration et dans la fenêtre de maintenance sélectionnée. Notez que même avec cette option, il est toujours nécessaire d’installer les correctifs réguliers de Microsoft Update.

• Vous pouvez sélectionner que l’agent se mette automatiquement à jour dès qu’une nouvelle version de l’agent devient disponible. Cette possibilité n’est actuellement pas applicable aux serveurs en cluster.

  Cette mise à jour se produit au cours de l’intervalle de maintenance sélectionné et permet à 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é. Il fournit 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 fournit 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 devient également disponible dans Microsoft Update et dans le Centre de téléchargement Microsoft.

Modifier le paramètre de mise à jour 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, cette action ressemble à l’exemple suivant :

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>

Remarque

Si la distribution de versions d’évaluation est déjà terminée pour la dernière version de l’agent et que la stratégie de mise à jour automatique de l’agent est modifiée sur InstallLatest, l’agent n’est pas automatiquement mis à jour tant que la version suivante de l’agent n’est pas mise à jour. Pour effectuer une mise à jour vers une version d’agent qui a terminé la version d’évaluation, utilisez Microsoft Update ou AfsUpdater.exe. Pour vérifier si une version de l’agent est actuellement en cours de distribution de version d’évaluation, vérifiez la section versions prises en charge dans les notes de publication.

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. Une version spécifique de l’agent Azure File Sync peut être prise en charge uniquement pendant 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 lors de la gestion des modifications :

• Les versions majeures et mineures de l’agent sont prises en charge au moins 12 mois après leur publication initiale.
• Il y a une période de chevauchement de 3 mois minimum de prise en charge entre chaque version majeure d’agent.
• Les avertissements sont émis pour les serveurs inscrits via un agent qui expire bientôt au moins 3 mois avant l’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 18.0.0.0 de l’agent est définie comme devant expirer, les versions 18.*.*.* de l’agent expireront toutes en même temps.

Remarque

L’installation d’une version d’agent expirée affiche un avertissement, mais réussit. En revanche, l’installation et la connexion à une version de l’agent ayant expiré ne sont pas prises en charge et sont bloquées.

Contenu connexe

• Paramètres de proxy et de pare-feu d’Azure File Sync
• Créer un partage de fichiers SMB Azure
• Déployer Azure File Sync
• Superviser Azure File Sync