BranchCache voor VPN-bestandsshares: wanneer het helpt, wanneer niet

Iemand in het team zegt dat de bestandsshare via de VPN traag is, en de eerste suggestie is altijd een cache. Voordat u BranchCache aan het ontwerp voor externe toegang toevoegt, splitst u de klacht in een van drie vormen: herhaalde downloads van ongewijzigde inhoud, uploads, of metadatarijke navigatie door mappen met duizenden items. BranchCache pakt de eerste vorm aan bij ondersteunde inhoud en doet niets nuttigs voor de andere twee. Dat is geen beperking om omheen te werken; het is de vergelijking die u moet maken voordat u een week aan uitrol besteedt.

Dezelfde share, drie verschillende klachten

Een bijkantoor waar acht mensen dezelfde ongewijzigde trainingsvideo openen is het geval waarvoor de functie is ontworpen. De eerste ophaalactie gaat over de WAN, de inhoud wordt dicht bij de lezers in de cache gezet, en latere ophaalacties van hetzelfde ongewijzigde bestand worden lokaal bediend. Het voordeel is echt en het is smal: dezelfde inhoud, ongewijzigd, meerdere lezers.

Een laptop die een nieuwe opname via een thuisverbinding uploadt is het tegenovergestelde geval. Er is geen eerder gecachte kopie van een bestand dat nog niet bestaat, dus de upload volgt hetzelfde beperkte pad als altijd. Een downloadcache haalt geen upload weg, en geen enkele plaatsingskeuze verandert dat.

De derde vorm is degene die mensen teleurstelt, omdat het op een downloadprobleem lijkt. Een map met tienduizenden bestanden openen, sorteren en metadata lezen is een stroom kleine bewerkingen, geen herhaalde overdracht van een groot object. De bestandsinhoud cachen doet niets voor het opsommen.

Gedistribueerde cache: een VPN-pool is geen bijkantoor-LAN

In gedistribueerde modus delen clientcomputers gecachte inhoud met elkaar, en Microsoft documenteert die modus als werkend binnen één subnet. Een VPN-clientpool is in die zin geen subnet, zelfs niet wanneer alle adressen aaneengesloten lijken: peer-detectie, bereikbaarheid van client tot client en toestemming om cachedata uit te wisselen zijn afzonderlijke vragen, en het gebruikelijke ontwerp voor externe toegang beantwoordt alle drie met ‘nee’.

U kunt de pool zich als een bijkantoor-LAN laten gedragen door verkeer van client naar client toe te staan, maar dat is een beveiligingsbeslissing, geen cachebeslissing. De meeste ontwerpen voor externe toegang isoleren clients van elkaar juist zodat een gecompromitteerde laptop geen andere kan bereiken, en die isolatie inruilen voor een cachetreffer is een slechte ruil, tenzij de peers al vertrouwde gelijken zijn.

Voor één rondreizende gebruiker heeft gedistribueerde modus niemand om mee te delen. De cache kan nog steeds de herhaalde leesacties van die ene client bedienen, maar dat is een cachevoordeel aan de clientkant, geen voordeel van bijkantoorplaatsing, en dat is het waard om te zeggen voordat iemand verwacht dat het kantoor sneller wordt.

Gehoste cache: de plaatsing bepaalt of het helpt

Een gehoste cache zet de gedeelde cache op een server, wat de enige modus is die over subnetten heen zinvol is en de enige die werkt wanneer clients niet met elkaar kunnen praten. De onmiddellijke vraag is waar die server staat. Een gehoste cache die via dezelfde beperkte verbinding als de origin wordt bereikt, heeft de bytes verplaatst, niet het probleem.

Plaats hem dicht bij de lezers, geef hem een eigenaar en dimensioneer zijn schijf voor de werkset in plaats van voor de hele share. Het BranchCache-overzicht van Microsoft beschrijft beide modi en het clientgedrag, inclusief het deel dat mensen vergeten: clients nemen nog steeds contact op met de origin voor autorisatie en inhoudsinformatie voordat ze gecachte gegevens gebruiken.

Uitrol is drie rollen die samen worden gepland, niet één vinkje. De originserver publiceert hashes voor de inhoud, de gehoste cache wordt ingeschakeld en is vindbaar, en de clients worden geconfigureerd om hem te gebruiken. Aan de serverkant is dat herkenbaar in PowerShell:

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

Wijs de client op genoemde servers of laat hem ze ontdekken via het serviceverbindingspunt; bevestig daarna de modus die hij werkelijk heeft gekozen in plaats van aan te nemen dat het beleid is toegepast:

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

Wat de origin nog steeds bereikt

Cachen haalt autorisatie niet weg. Een client zonder leesrechten op een bestand krijgt geen toegang omdat iemand anders het heeft gecacht, en de origin beantwoordt nog steeds de autorisatievraag en levert de inhoudsinformatie die de cachelookup mogelijk maakt. Als de origin onbereikbaar is, wordt de gecachte kopie alleen geen offline share.

Inhoudswijzigingen doorbreken de aanname ook stil. Een bestand dat opnieuw wordt opgeslagen, opnieuw gecodeerd of door een back-upproduct wordt aangeraakt, past mogelijk niet meer bij de gecachte hash, en de volgende leesactie gaat terug naar de origin. Dat is correct gedrag, en daarom levert een cache waarvan de werkset elk uur verandert weinig op.

Verdringing is de derde grens. De cache is eindig, dus een grote werkset duwt oudere inhoud naar buiten, en het voordeel hangt ervan af of herlezingen vóór de verdringing plaatsvinden en niet erna. De cache dimensioneren voor de hele share is de gebruikelijke manier om teleurgesteld te worden door een technisch correcte uitrol.

Accepteer het met twee ophaalacties en één upload

Test de juiste drie stromen en schrijf op wat elk laat zien. Eerste ophaalactie van een representatief bestand vanaf een client, gemeten op de origin-verbinding én op de klok van de gebruiker. Tweede ophaalactie van hetzelfde ongewijzigde bestand vanaf een tweede client in dezelfde plaatsingsgroep. Één upload van een nieuw bestand, die geen verbetering mag laten zien en bevestigt dat de cache niet wordt gecrediteerd voor iets wat hij nooit deed.

Als de tweede ophaalactie de origin-verbinding nog steeds voor het grootste deel van de bytes passeert, wordt de cache niet gebruikt, en de oorzaak is meestal een client in de verkeerde modus, een ontbrekende hashpublicatie op de origin, of een gehoste cache aan de verkeerde kant van de beperkte verbinding. Dat zijn drie verschillende oplossingen, en slechts één ervan gaat over netwerkplaatsing.

Formuleer daarna de conclusie in dezelfde vorm als de oorspronkelijke klacht: herhaalde downloads van ongewijzigde inhoud van deze origin naar deze lezers worden door deze cache bediend. Al het andere aan de share blijft onaangeroerd, inclusief uploads, het opsommen van mappen en het offlineverhaal, dat nog steeds zijn eigen antwoord nodig heeft.