Cache de métadonnées Azure Files contre cache local de branche
Un cache de métadonnées côté service réduit le travail du serveur. Il ne supprime pas les allers-retours de votre WAN. Comparez les deux par ce qu'ils raccourcissent réellement.
Pour un accès lent à Azure Files via un VPN, deux changements sont proposés, et ils raccourcissent des choses différentes. Le cache de métadonnées côté service rend les opérations éligibles moins coûteuses pour le serveur. Un cache local de branche rapproche les octets et les opérations de l'utilisateur. Choisir entre les deux sur la base d'une grille tarifaire ou d'un communiqué de presse, c'est ainsi qu'un partage finit plus rapide dans un banc d'essai et inchangé à neuf heures du matin.
Deux caches, deux latences différentes
Les deux options apparaissent sous le mot cache, et c'est là que la confusion commence. Elles se situent de part et d'autre du réseau.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Le guide de performances SMB de Microsoft décrit la mise en cache des métadonnées pour les partages SSD éligibles, ainsi que l'étape d'inscription qui l'accompagne. L'éligibilité et l'état de la fonctionnalité dépendent du compte de stockage réel, alors lisez la page actuelle plutôt qu'une annonce de préversion d'il y a deux ans.
Découpez l'attente en trois parties
Chaque listage de répertoire lent comporte trois composantes de coût, et elles répondent à des correctifs différents. Il y a le temps de traitement de la requête côté service, le nombre d'allers-retours dépendants à travers le VPN et la charge utile à déplacer. Un cache côté service attaque la première. Rien côté serveur n'attaque la seconde.
C'est pourquoi un partage peut afficher de meilleures métriques de service alors que le sélecteur de fichiers de l'utilisateur reste bloqué pendant huit secondes.
Où chaque option mérite sa place
Si la charge de travail est riche en métadonnées, avec de nombreuses ouvertures, appels stat et énumérations de répertoires sur un partage SSD éligible, le cache côté service est l'expérience bon marché. Il n'exige aucune infrastructure nouvelle et ne change rien à la façon dont les utilisateurs atteignent le partage.
Si la charge de travail est interactive et limitée par la latence, l'option honnête est une conception de serveur local prise en charge avec un modèle de synchronisation documenté. C'est une autre architecture, avec ses propres coûts d'exploitation, pas un interrupteur.
Ce qu'aucune des deux options ne change
La signature et le chiffrement SMB s'appliquent toujours, et ils coûtent toujours ce qu'ils coûtent. Le contrôle d'accès est toujours résolu par utilisateur, donc une copie en cache ne simplifie pas l'autorisation. La cohérence entre sites nécessite toujours un modèle défini, car les lectures locales de la branche et les écritures côté cloud doivent s'accorder sur quelque chose. Et l'accès hors ligne reste un paramètre du client, pas un effet secondaire d'une fonctionnalité serveur.
Quand quelqu'un promet qu'une fonctionnalité du service supprime les allers-retours WAN, c'est l'affirmation à tester en premier.
Mesurez par rapport à l'opération dont se plaignent les utilisateurs
Chronométrez l'opération exacte plutôt qu'une copie synthétique. Measure-Command { Get-ChildItem \\files\projects -Recurse } sur un client de branche donne un nombre que vous pouvez comparer avant et après, et Get-SmbMultichannelConnection indique si le client utilise plus d'un chemin. Placez cela à côté des métriques de latence côté service pour la même fenêtre.
Gardez le partage, l'emplacement du client, le chemin VPN et la politique de sécurité constants, sinon vous mesurez votre fenêtre de changement plutôt que la fonctionnalité. Notez aussi le nombre de fichiers et la distribution des tailles, car les charges de petits fichiers et les copies massives réagissent à des leviers complètement différents.
Le résultat qui vaut la peine est un changement ajusté à la frontière qui était réellement lente, avec ses coûts d'exploitation et de cohérence consignés. Un chiffre IOPS de stockage plus élevé sur une diapositive n'est pas ce résultat.