Choisir des stratégies de hiérarchisation Cloud
Cet article fournit des conseils sur la sélection et l’ajustement des stratégies de hiérarchisation cloud pour Azure File Sync. Avant de le lire, assurez-vous de bien comprendre le fonctionnement de la hiérarchisation cloud. Pour des notions de base sur la hiérarchisation Cloud, consultez l’articleComprendre la hiérarchisation Cloud Azure File Sync. Pour obtenir une explication détaillée des stratégies de hiérarchisation Cloud et des exemples, consultez Stratégies de hiérarchisation Cloud Azure File Sync.
Limites
La hiérarchisation cloud n’est pas prise en charge sur le volume système Windows.
Si vous utilisez le Gestionnaire de ressources du serveur de fichiers (FSRM) pour la gestion des quotas sur les points de terminaison de serveur, nous vous recommandons d’appliquer les quotas au niveau du dossier et non au niveau du volume. Vous pouvez toujours activer la hiérarchisation Cloud si vous disposez d’un quota FSRM au niveau du volume. Une fois qu’un quota FSRM est défini, les API de requête d’espace libre appelées signalent automatiquement l’espace libre sur le volume en fonction du quota paramétré. Toutefois, quand un quota inconditionnel est présent dans une racine volume, il est possible que l’espace libre réel sur le volume et l’espace restreint de quota sur le volume ne soient pas les mêmes. Cela peut entraîner une hiérarchisation infinie si Azure File Sync suppose que l’espace libre de volume n’est pas suffisant sur le point de terminaison de serveur.
Taille de fichier minimum pour un fichier à hiérarchiser
La taille de fichier minimale à hiérarchiser est basée sur la taille du cluster du système de fichiers. La taille de fichier minimale éligible pour la hiérarchisation cloud est calculée en multipliant par 2 la taille du cluster et utilise au minimum 8 Kio. La table suivante illustre les tailles minimales des fichiers qui peuvent être hiérarchisés, sur la base de la taille du volume de cluster :
| Taille de volume de cluster | Les fichiers de cette taille ou plus peuvent être hiérarchisés |
|---|---|
| 4 Kio ou moins (4 096 octets) | 8 Kio |
| 8 Kio (8 192 octets) | 16 Kio |
| 16 Kio (16 384 octets) | 32 Kio |
| 32 Kio (32 768 octets) | 64 Kio |
| 64 Kio (65 536 octets) | 128 Kio |
| 128 Kio (131 072 octets) | 256 Kio |
| 256 Kio (262 144 octets) | 512 Kio |
| 512 Kio (524 288 octets) | 1 Mio |
| 1 Mio (1 048 576 octets) | 2 Mio |
| 2 Mio (2 097 152 octets) | 4 Mio |
Azure File Sync prend en charge la hiérarchisation cloud sur les volumes avec des tailles de cluster allant jusqu'à 2 Mio.
Tous les systèmes de fichiers utilisés par Windows organisent votre disque dur en fonction de la taille du cluster (également appelée taille d’unité d’allocation). La taille du cluster représente la plus petite quantité d’espace disque qui peut être utilisée pour contenir un fichier. Lorsque les tailles de fichiers ne correspondent pas à un multiple de la taille du cluster, un espace supplémentaire est nécessaire pour conserver le fichier (jusqu’au multiple supérieur de la taille du cluster).
Azure File Sync est pris en charge sur les volumes NTFS avec Windows Server 2012 R2 et versions ultérieures. Le tableau suivant décrit les tailles de cluster par défaut quand vous créez un volume NTFS avec Windows Server 2019.
| Taille du volume | Windows Server 2019 |
|---|---|
| 7 Mio - 16 Tio | 4 Kio |
| 16 Tio – 32 Tio | 8 Kio |
| 32 Tio – 64 Tio | 16 Kio |
Lors de la création du volume, il est possible que vous l’ayez formaté manuellement avec une taille de cluster différente. Si votre volume provient d’une version antérieure de Windows, les tailles de cluster par défaut peuvent également être différentes. Cet article fournit des informations supplémentaires sur les tailles de cluster par défaut. Même si vous choisissez une taille de cluster inférieure à 4 Kio, la limite de 8 Kio comme plus petite taille de fichier pouvant être hiérarchisée s’applique toujours. (Même si, techniquement, le double de la taille du cluster équivaut à moins de 8 Kio.)
Ce minimum absolu est dû à la manière dont NTFS stocke les fichiers très petits, de 1 Kio à 4 Kio. En fonction d’autres paramètres du volume, il est possible que les petits fichiers ne soient pas du tout stockés dans un cluster sur le disque. Il est peut-être plus efficace de stocker ces fichiers directement dans la table de fichiers maîtres ou l’« enregistrement de la table MFT » du volume. Le point d’analyse de la hiérarchisation cloud est toujours stocké sur le disque et occupe exactement un cluster. Hiérarchiser de si petits fichiers pourrait ne pas représenter un gain de place. Les cas extrêmes peuvent même finir par utiliser plus d’espace lorsque la hiérarchisation cloud est activée. Pour éviter cela, la plus petite taille d’un fichier que la hiérarchisation cloud organisera est de 8 Kio sur une taille de cluster de 4 Kio ou moins.
Sélection de vos stratégies initiales
En règle générale, lorsque vous activez la hiérarchisation Cloud sur un point de terminaison de serveur, vous devez créer un lecteur virtuel local pour chaque point de terminaison de serveur individuel. L’isolation du point de terminaison de serveur aide à mieux comprendre le fonctionnement de la hiérarchisation Cloud et l’ajustement des stratégies en conséquence. Toutefois, Azure File Sync fonctionne même si vous avez plusieurs points de terminaison de serveur sur le même lecteur. Pour plus d’informations, consultez la section Plusieurs points de terminaison de serveur sur le volume local. Nous vous recommandons également, lorsque vous activez pour la première fois la hiérarchisation Cloud, de conserver la stratégie de date désactivée et la stratégie d’espace libre du volume de 10 à 20 % environ. Pour la plupart des volumes de serveurs de fichiers, 20 % d’espace libre de volume est généralement la meilleure option.
Par souci de simplicité et pour comprendre la façon dont les éléments sont hiérarchisés, nous vous recommandons d’ajuster votre stratégie d’espace libre du volume et de désactiver votre stratégie de date (sauf s’il est nécessaire de l’activer). Nous vous recommandons de le faire, car la plupart des clients trouve que remplir le cache local avec autant de fichiers à chaud que possible et de hiérarchiser le reste sur le Cloud est important. Toutefois, la stratégie de date peut être avantageuse si vous souhaitez libérer de manière proactive l’espace disque local et que vous savez que les fichiers dans ce point de terminaison de serveur peuvent être consultés après le nombre de jours spécifié dans votre stratégie de date sans avoir besoin d’être conservés localement. Le paramétrage de la stratégie de date libère une capacité précieuse de disque local pour d’autres points de terminaison sur le même afin de mettre en cache plus de fichiers.
Après avoir défini vos stratégies, surveillez la sortie et ajustez les deux stratégies en conséquence. Nous vous recommandons de surveiller les métriques taille de rappel de hiérarchisation cloud et taille de rappel de hiérarchisation cloud par application dans Azure Monitor. Nous vous recommandons également de surveiller le taux d’accès au cache pour le point de terminaison du serveur afin de déterminer le pourcentage de fichiers ouverts qui se trouvent déjà dans le cache local. Pour savoir comment surveiller la sortie, consultez Surveiller la hiérarchisation Cloud.
Ajustement de vos stratégies
Si le nombre de fichiers constamment rappelés à partir d’Azure est supérieur aux besoins, il se peut que vous ayez plus de fichiers fréquemment utilisés que d’espace pour les enregistrer sur le volume du serveur local. Augmentez la taille du volume local si possible, et/ou diminuez le pourcentage de votre stratégie d’espace libre du volume par petits incréments. Une diminution trop importante du pourcentage d’espace libre du volume peut avoir des conséquences négatives. Une plus grande attrition de votre jeu de données nécessite plus d’espace libre : pour les nouveaux fichiers et le rappel des fichiers « à froid ». La hiérarchisation commence par un délai pouvant atteindre une heure, puis nécessite du temps de traitement. c’est pourquoi vous devez toujours disposer de suffisamment d’espace libre sur votre volume.
Le fait de conserver davantage de données au niveau local permet de réduire les coûts de sortie, car moins de fichiers seront rappelés à partir d'Azure. Toutefois, cette option nécessite également une plus grande quantité de stockage localement, entraînant ainsi des coûts supplémentaires.
Lorsque vous ajustez votre stratégie d’espace libre du volume, la quantité de données à conserver en local est déterminée par les facteurs suivants : votre bande passante, le modèle d’accès du jeu de données et le budget. Avec une faible connexion de bande passante, vous pourriez avoir besoin de plus de données locales afin réduire au maximum le décalage pour les utilisateurs. Autrement, vous pouvez baser la quantité d’espace libre du volume sur le taux de variation sur une période donnée. Par exemple, si vous savez que 10 % de votre jeu de données de 1 Tio changent ou sont activement utilisés chaque mois, vous pouvez conserver 100 Gio localement afin de ne pas rappeler fréquemment des fichiers. Si votre volume est de 2 Tio, vous pouvez conserver 5 % (soit 100 Gio) localement, de sorte que les 95 % restants constituent votre pourcentage d’espace libre du volume. Toutefois, vous devrez ajouter une mémoire tampon pour les périodes de variations plus importantes. En d’autres termes, vous devrez commencer par un pourcentage d’espace libre du volume supérieur, puis l’ajuster si nécessaire par la suite.
Procédures de fonctionnement standard
- Lors de la migration initiale vers Azure Files via Azure File Sync, la hiérarchisation Cloud dépend du chargement initial
- La hiérarchisation Cloud vérifie la conformité avec les stratégies d’espace libre du volume et de date toutes les soixante minutes
- L’utilisation du commutateur /LFSM sur Robocopy lors de la migration de fichiers permet de synchroniser les fichiers et la hiérarchisation Cloud pour libérer de l’espace pendant le chargement initial
- Si la hiérarchisation se produit avant qu’une carte thermique ne soit formé, les fichiers sont hiérarchisés par timestamp de la dernière modification