BranchCache til VPN-fildelinger: hvornår det hjælper, og hvornår det ikke gør

Nogen i teamet siger, at fildelingen over VPN er langsom, og det første forslag er altid en cache. Før BranchCache føjes til fjernadgangsdesignet, skal klagen opdeles i en af tre former: gentagne downloads af uændret indhold, uploads eller metadatatung browsing gennem mapper med tusindvis af poster. BranchCache håndterer den første form på understøttet indhold og gør intet nyttigt for de to andre. Det er ikke en begrænsning, man skal arbejde uden om; det er den sammenligning, du bør lave, før du bruger en uge på udrulning.

Den samme fildeling, tre forskellige klager

Et filialkontor, hvor otte personer åbner den samme uændrede træningsvideo, er det tilfælde, funktionen blev designet til. Den første hentning krydser WAN'en, indholdet caches tæt på læserne, og senere hentninger af den samme uændrede fil leveres lokalt. Fordelen er reel og smal: samme indhold, uændret, flere læsere.

En bærbar computer, der uploader en ny optagelse over en hjemmeforbindelse, er det modsatte tilfælde. Der findes ingen tidligere cachet kopi af en fil, der endnu ikke eksisterer, så uploadet følger den samme begrænsede vej som altid. En download-cache fjerner ikke et upload, og ingen placeringsvalg ændrer det.

Den tredje form skuffer folk, fordi den ligner et downloadproblem. At åbne en mappe med titusindvis af filer, sortere den og læse metadata er en strøm af små operationer, ikke en gentagen overførsel af et stort objekt. At cache filindholdet gør intet for opregningen.

Distribueret cache: en VPN-pulje er ikke et filial-LAN

I distribueret tilstand deler klientcomputere cachet indhold med hinanden, og Microsoft dokumenterer den tilstand som fungerende inden for et enkelt subnet. En VPN-klientpulje er ikke et subnet i den forstand, selv når alle adresserne ser sammenhængende ud: peer-opdagelse, tilgængelighed fra klient til klient og tilladelse til at udveksle cachedata er separate spørgsmål, og det sædvanlige fjernadgangsdesign svarer »nej« på alle tre.

Du kan få puljen til at opføre sig som et filial-LAN ved at tillade trafik mellem klienter, men det er en sikkerhedsbeslutning, ikke en cachebeslutning. De fleste fjernadgangsdesign isolerer klienter fra hinanden netop for at en kompromitteret bærbar computer ikke kan nå en anden, og at bytte den isolering for et cachehit er en dårlig handel, medmindre peerne allerede er betroede ligemænd.

For en enkelt omrejsende bruger har distribueret tilstand ingen at dele med. Cachen kan stadig betjene den ene klients gentagne læsninger, men det er en cachefordel på klientsiden, ikke en fordel ved filialplacering, og det er værd at sige, før nogen forventer, at kontoret bliver hurtigere.

Hostet cache: placeringen afgør, om den hjælper

En hostet cache lægger den delte cache på en server, hvilket er den eneste tilstand, der giver mening på tværs af subnet, og den eneste, der virker, når klienter ikke kan tale sammen. Det umiddelbare spørgsmål er, hvor den server står. En hostet cache, der nås over den samme begrænsede forbindelse som kilden, har flyttet bytes, ikke problemet.

Placér den tæt på læserne, giv den en ejer, og dimensionér dens disk efter arbejdssættet i stedet for efter hele fildelingen. Microsofts BranchCache-oversigt beskriver begge tilstande og klientadfærden, inklusive den del, folk glemmer: klienter kontakter stadig kilden for autorisation og indholdsoplysninger, før de bruger cachede data.

Udrulning er tre roller, der planlægges sammen, ikke et flueben. Kildeserveren offentliggør hashes for indholdet, den hostede cache aktiveres og kan findes, og klienterne konfigureres til at bruge den. På serversiden kan det genkendes i PowerShell:

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

På klienten kan du pege den mod navngivne servere eller lade den finde dem via tjenesteforbindelsespunktet; bekræft derefter den tilstand, den faktisk valgte, i stedet for at antage, at politikken blev anvendt:

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

Hvad der stadig når kilden

Caching fjerner ikke autorisation. En klient uden læsetilladelse til en fil får ikke adgang, fordi en anden har cachet den, og kilden besvarer stadig autorisationsspørgsmålet og leverer de indholdsoplysninger, der gør cacheopslaget muligt. Hvis kilden ikke kan nås, bliver den cachede kopi alene ikke en offline fildeling.

Indholdsændringer bryder også antagelsen i det stille. En fil, der gemmes igen, kodes om eller berøres af et backup-produkt, matcher måske ikke længere den cachede hash, og den næste læsning går tilbage til kilden. Det er korrekt adfærd, og derfor leverer en cache, hvis arbejdssæt ændrer sig hver time, lidt.

Fordrivelse er den tredje grænse. Cachen er endelig, så et stort arbejdssæt skubber ældre indhold ud, og fordelen afhænger af, at genlæsninger sker før fordrivelsen og ikke efter. At dimensionere cachen til hele fildelingen er den sædvanlige måde at blive skuffet over en udrulning, der var teknisk korrekt.

Accepter det med to hentninger og et upload

Test de rigtige tre flows, og skriv ned, hvad hver af dem viser. Første hentning af en repræsentativ fil fra en klient, målt på kildeforbindelsen såvel som på brugerens ur. Anden hentning af den samme uændrede fil fra en anden klient i samme placeringsgruppe. Et upload af en ny fil, som ikke bør vise nogen forbedring og bekræfter, at cachen ikke får æren for noget, den aldrig gjorde.

Hvis den anden hentning stadig krydser kildeforbindelsen for størstedelen af bytene, bruges cachen ikke, og årsagen er normalt en klient i den forkerte tilstand, en manglende hashoffentliggørelse på kilden eller en hostet cache på den forkerte side af den begrænsede forbindelse. Det er tre forskellige rettelser, og kun en af dem handler om netværksplacering.

Angiv derefter konklusionen i samme form som den oprindelige klage: gentagne downloads af uændret indhold fra denne kilde til disse læsere betjenes af denne cache. Alt andet ved fildelingen er urørt, inklusive uploads, mappeopregning og offlinehistorien, som stadig har brug for sit eget svar.