BranchCache för VPN-filresurser: när det hjälper och när det inte gör det

Någon i teamet säger att filresursen över VPN är långsam, och det första förslaget är alltid en cache. Innan BranchCache läggs till i fjärråtkomstdesignen, dela upp klagomålet i en av tre former: upprepade nedladdningar av oförändrat innehåll, uppladdningar, eller metadatatung bläddring genom mappar med tusentals poster. BranchCache hanterar den första formen på innehåll som stöds och gör inget användbart för de andra två. Det är inte en begränsning att arbeta runt; det är jämförelsen du bör göra innan du lägger en vecka på driftsättning.

Samma resurs, tre olika klagomål

Ett filialkontor där åtta personer öppnar samma oförändrade utbildningsvideo är fallet funktionen designades för. Den första hämtningen korsar WAN, innehållet cachas nära läsarna, och senare hämtningar av samma oförändrade fil serveras lokalt. Nyttan är verklig och den är smal: samma innehåll, oförändrat, flera läsare.

En bärbar dator som laddar upp en ny inspelning via en hemanslutning är det motsatta fallet. Det finns ingen tidigare cachad kopia av en fil som ännu inte existerar, så uppladdningen följer samma begränsade väg som alltid. En nedladdningscache tar inte bort en uppladdning, och inget placeringsval ändrar det.

Den tredje formen är den som gör folk besvikna, eftersom den ser ut som ett nedladdningsproblem. Att öppna en katalog med tiotusentals filer, sortera den och läsa metadata är ett flöde av små operationer, inte en upprepad överföring av ett stort objekt. Att cacha filkropparna gör inget för uppräkningen.

Distribuerad cache: en VPN-pool är inte ett filial-LAN

I distribuerat läge delar klientdatorer cachat innehåll med varandra, och Microsoft dokumenterar det läget som fungerande inom ett enda subnät. En VPN-klientpool är inte ett subnät i den meningen, även när alla adresser ser sammanhängande ut: peer-upptäckt, nåbarhet mellan klienter och tillstånd att utbyta cachedata är separata frågor, och den vanliga fjärråtkomstdesignen svarar »nej« på alla tre.

Du kan få poolen att bete sig som ett filial-LAN genom att tillåta trafik mellan klienter, men det är ett säkerhetsbeslut, inte ett cachebeslut. De flesta fjärråtkomstdesigner isolerar klienter från varandra just för att en komprometterad bärbar dator inte ska kunna nå en annan, och att byta den isoleringen mot en cacheträff är en dålig affär om inte peerarna redan är betrodda jämlikar.

För en enda roaminganvändare har distribuerat läge ingen att dela med. Cachen kan fortfarande betjäna den enda klientens upprepade läsningar, men det är en cachefördel på klientsidan, inte en fördel av filialplacering, och det är värt att säga innan någon förväntar sig att kontoret ska bli snabbare.

Värdbaserad cache: placeringen avgör om den hjälper

En värdbaserad cache lägger den delade cachen på en server, vilket är det enda läget som är vettigt över subnät och det enda som fungerar när klienter inte kan prata med varandra. Den omedelbara frågan är var den servern står. En värdbaserad cache som nås över samma begränsade länk som källan har flyttat byten, inte problemet.

Placera den nära läsarna, ge den en ägare och dimensionera dess disk för arbetsmängden i stället för för hela resursen. Microsofts BranchCache-översikt beskriver båda lägena och klientbeteendet, inklusive delen folk glömmer: klienter kontaktar fortfarande källan för auktorisering och innehållsinformation innan de använder cachade data.

Driftsättning är tre roller som planeras tillsammans, inte en kryssruta. Källservern publicerar hashar för innehållet, den värdbaserade cachen aktiveras och går att hitta, och klienterna konfigureras att använda den. På serversidan känns det igen i PowerShell:

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

På klienten pekar du den mot namngivna servrar eller låter den hitta dem via tjänstens anslutningspunkt; bekräfta sedan det läge den faktiskt valde i stället för att anta att principen tillämpades:

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

Vad som fortfarande når källan

Cachning tar inte bort auktorisering. En klient utan läsbehörighet till en fil får inte åtkomst för att någon annan cachat den, och källan svarar fortfarande på auktoriseringsfrågan och tillhandahåller den innehållsinformation som gör cacheuppslaget möjligt. Om källan inte går att nå blir den cachade kopian ensam inte en offline-resurs.

Innehållsändringar bryter också antagandet i tysthet. En fil som sparas igen, kodas om eller berörs av en säkerhetskopieringsprodukt matchar kanske inte längre den cachade hashen, och nästa läsning går tillbaka till källan. Det är korrekt beteende, och det är därför en cache vars arbetsmängd ändras varje timme ger lite.

Utträngning är den tredje gränsen. Cachen är ändlig, så en stor arbetsmängd tränger ut äldre innehåll, och nyttan beror på att omläsningar sker före utträngningen och inte efter. Att dimensionera cachen för hela resursen är det vanliga sättet att bli besviken på en driftsättning som var tekniskt korrekt.

Acceptera det med två hämtningar och en uppladdning

Testa de tre rätta flödena och skriv ner vad varje visar. Första hämtningen av en representativ fil från en klient, mätt på källänken såväl som på användarens klocka. Andra hämtningen av samma oförändrade fil från en andra klient i samma placeringsgrupp. En uppladdning av en ny fil, som inte bör visa någon förbättring och bekräftar att cachen inte får äran för något den aldrig gjorde.

Om den andra hämtningen fortfarande korsar källänken för större delen av byten, används inte cachen, och orsaken är oftast en klient i fel läge, en saknad hashpublicering på källan, eller en värdbaserad cache på fel sida av den begränsade länken. Det är tre olika åtgärder, och bara en av dem handlar om nätverksplacering.

Ange sedan slutsatsen i samma form som det ursprungliga klagomålet: upprepade nedladdningar av oförändrat innehåll från denna källa till dessa läsare betjänas av denna cache. Allt annat med resursen är orört, inklusive uppladdningar, mappuppräkning och offlineberättelsen, som fortfarande behöver sitt eget svar.