BranchCache pour les partages de fichiers via VPN : quand il aide, quand il n'aide pas

Quelqu'un dans l'équipe dit que le partage de fichiers via le VPN est lent, et la première suggestion est toujours un cache. Avant d'ajouter BranchCache à la conception de l'accès distant, classez la plainte dans l'une de trois formes : téléchargements répétés de contenu inchangé, envois, ou navigation chargée en métadonnées dans des dossiers comptant des milliers d'entrées. BranchCache traite la première forme sur le contenu pris en charge et ne fait rien d'utile pour les deux autres. Ce n'est pas une limitation à contourner ; c'est la comparaison à faire avant de consacrer une semaine au déploiement.

Le même partage, trois plaintes différentes

Un bureau de succursale où huit personnes ouvrent la même vidéo de formation inchangée est le cas pour lequel la fonction a été conçue. La première récupération traverse le WAN, le contenu est mis en cache près des lecteurs, et les récupérations ultérieures du même fichier inchangé sont servies localement. Le bénéfice est réel et il est étroit : même contenu, inchangé, plusieurs lecteurs.

Un ordinateur portable qui envoie un nouvel enregistrement via une connexion domestique est le cas inverse. Il n'existe aucune copie déjà en cache d'un fichier qui n'existe pas encore, donc l'envoi suit le même chemin contraint qu'auparavant. Un cache de téléchargement ne supprime pas un envoi, et aucun choix de placement n'y change rien.

La troisième forme est celle qui déçoit, parce qu'elle ressemble à un problème de téléchargement. Ouvrir un répertoire contenant des dizaines de milliers de fichiers, le trier et lire des métadonnées est un flux de petites opérations, pas un transfert répété d'un gros objet. Mettre en cache le corps des fichiers n'apporte rien à l'énumération.

Cache distribué : un pool VPN n'est pas un LAN de succursale

En mode distribué, les ordinateurs clients partagent le contenu mis en cache entre eux, et Microsoft documente ce mode comme fonctionnant au sein d'un seul sous-réseau. Un pool de clients VPN n'est pas un sous-réseau en ce sens, même lorsque toutes les adresses semblent contiguës : la découverte des pairs, la joignabilité de client à client et l'autorisation d'échanger des données de cache sont des questions distinctes, et la conception habituelle d'accès distant répond « non » aux trois.

Vous pouvez faire en sorte que le pool se comporte comme un LAN de succursale en autorisant le trafic de client à client, mais c'est une décision de sécurité, pas de mise en cache. La plupart des conceptions d'accès distant isolent les clients les uns des autres précisément pour qu'un portable compromis ne puisse pas en atteindre un autre, et échanger cet isolement contre un succès de cache est un mauvais marché, sauf si les pairs sont déjà des égaux de confiance.

Pour un seul utilisateur nomade, le mode distribué n'a personne avec qui partager. Le cache peut encore servir les lectures répétées de ce client, mais c'est un bénéfice de cache côté client, pas un bénéfice de placement en succursale, et il vaut la peine de le dire avant que quiconque s'attende à ce que le bureau devienne plus rapide.

Cache hébergé : le placement décide s'il aide

Un cache hébergé place le cache partagé sur un serveur, ce qui est le seul mode sensé entre sous-réseaux et le seul qui fonctionne quand les clients ne peuvent pas communiquer entre eux. La question immédiate est où se trouve ce serveur. Un cache hébergé joint par le même lien contraint que l'origine a déplacé les octets, pas le problème.

Placez-le près des lecteurs, attribuez-lui un propriétaire et dimensionnez son disque pour le jeu de travail plutôt que pour tout le partage. La présentation de BranchCache de Microsoft décrit les deux modes et le comportement du client, y compris la partie que les gens oublient : les clients contactent toujours l'origine pour l'autorisation et les informations de contenu avant d'utiliser les données en cache.

Le déploiement, ce sont trois rôles planifiés ensemble, pas une case à cocher. Le serveur d'origine publie les hachages du contenu, le cache hébergé est activé et détectable, et les clients sont configurés pour l'utiliser. Côté serveur, cela se reconnaît dans PowerShell :

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

Côté client, pointez-le vers des serveurs nommés ou laissez-le les découvrir via le point de connexion de service ; confirmez ensuite le mode réellement sélectionné au lieu de supposer que la stratégie a été appliquée :

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

Ce qui atteint encore l'origine

La mise en cache ne supprime pas l'autorisation. Un client sans droit de lecture sur un fichier n'y accède pas parce qu'un autre l'a mis en cache, et l'origine répond toujours à la question d'autorisation et fournit les informations de contenu qui rendent la recherche en cache possible. Si l'origine est injoignable, la copie en cache seule ne devient pas un partage hors ligne.

Les changements de contenu brisent aussi l'hypothèse en silence. Un fichier réenregistré, réencodé ou touché par un produit de sauvegarde peut ne plus correspondre au hachage en cache, et la lecture suivante repart vers l'origine. C'est le comportement correct, et c'est pourquoi un cache dont le jeu de travail change toutes les heures apporte peu.

L'éviction est la troisième limite. Le cache est fini, donc un grand jeu de travail chasse le contenu plus ancien, et le bénéfice dépend de relectures avant l'éviction plutôt qu'après. Dimensionner le cache pour tout le partage est la façon habituelle d'être déçu par un déploiement techniquement correct.

Acceptez-le avec deux récupérations et un envoi

Testez les trois bons flux et notez ce que chacun montre. Première récupération d'un fichier représentatif depuis un client, mesurée sur le lien d'origine ainsi qu'à l'horloge de l'utilisateur. Seconde récupération du même fichier inchangé depuis un second client du même groupe de placement. Un envoi d'un nouveau fichier, qui ne devrait montrer aucune amélioration et confirme que le cache n'est pas crédité de ce qu'il n'a jamais fait.

Si la seconde récupération traverse encore le lien d'origine pour l'essentiel des octets, le cache n'est pas utilisé, et la cause est généralement un client dans le mauvais mode, une publication de hachage absente sur l'origine, ou un cache hébergé du mauvais côté du lien contraint. Ce sont trois correctifs différents, et un seul concerne le placement réseau.

Énoncez ensuite la conclusion dans la même forme que la plainte d'origine : les téléchargements répétés de contenu inchangé de cette origine vers ces lecteurs sont servis par ce cache. Tout le reste du partage est intact, y compris les envois, l'énumération des dossiers et l'histoire hors ligne, qui demande encore sa propre réponse.