BranchCache for VPN-fildelinger: når det hjelper, når det ikke gjør det

Noen i teamet sier at fildelingen over VPN er treg, og det første forslaget er alltid en cache. Før BranchCache legges til i fjernaksessdesignet, må klagen deles i én av tre former: gjentatte nedlastinger av uendret innhold, opplastinger, eller metadatatung blaing gjennom mapper med tusener av oppføringer. BranchCache håndterer den første formen på støttet innhold og gjør ingenting nyttig for de to andre. Det er ikke en begrensning man må jobbe rundt; det er sammenligningen du bør gjøre før du bruker en uke på utrulling.

Samme fildeling, tre forskjellige klager

Et filialkontor der åtte personer åpner den samme uendrede opplæringsvideoen, er tilfellet funksjonen ble laget for. Den første hentingen krysser WAN, innholdet caches nær leserne, og senere hentinger av den samme uendrede filen leveres lokalt. Fordelen er reell og smal: samme innhold, uendret, flere lesere.

En bærbar PC som laster opp et nytt opptak over en hjemmeforbindelse, er det motsatte tilfellet. Det finnes ingen tidligere cachet kopi av en fil som ennå ikke eksisterer, så opplastingen følger samme begrensede vei som alltid. En nedlastingscache fjerner ikke en opplasting, og ingen plasseringsvalg endrer det.

Den tredje formen er den som skuffer folk, fordi den ser ut som et nedlastingsproblem. Å åpne en mappe med titusener av filer, sortere den og lese metadata er en strøm av små operasjoner, ikke en gjentatt overføring av ett stort objekt. Å cache filkroppene gjør ingenting for oppramsingen.

Distribuert cache: en VPN-pool er ikke et filial-LAN

I distribuert modus deler klientdatamaskiner cachet innhold med hverandre, og Microsoft dokumenterer denne modusen som fungerende innenfor ett enkelt subnett. En VPN-klientpool er ikke et subnett i den forstand, selv når alle adressene ser sammenhengende ut: peer-oppdagelse, tilgjengelighet fra klient til klient og tillatelse til å utveksle cachedata er separate spørsmål, og det vanlige fjernaksessdesignet svarer »nei« på alle tre.

Du kan få poolen til å oppføre seg som et filial-LAN ved å tillate trafikk mellom klienter, men det er en sikkerhetsbeslutning, ikke en cachebeslutning. De fleste fjernaksessdesign isolerer klienter fra hverandre nettopp for at en kompromittert bærbar PC ikke skal kunne nå en annen, og å bytte den isolasjonen mot en cachetreff er en dårlig handel med mindre peerne allerede er betrodde likemenn.

For én enkelt omreisende bruker har distribuert modus ingen å dele med. Cachen kan fortsatt betjene den ene klientens gjentatte lesinger, men det er en cachefordel på klientsiden, ikke en fordel ved filialplassering, og det er verdt å si før noen forventer at kontoret blir raskere.

Hostet cache: plasseringen avgjør om den hjelper

En hostet cache legger den delte cachen på en server, som er den eneste modusen som gir mening på tvers av subnett og den eneste som fungerer når klienter ikke kan snakke sammen. Det umiddelbare spørsmålet er hvor den serveren står. En hostet cache som nås over den samme begrensede forbindelsen som kilden, har flyttet bytene, ikke problemet.

Plasser den nær leserne, gi den en eier, og dimensjoner disken for arbeidssettet i stedet for for hele fildelingen. Microsofts BranchCache-oversikt beskriver begge modusene og klientatferden, inkludert delen folk glemmer: klienter kontakter fortsatt kilden for autorisasjon og innholdsinformasjon før de bruker cachede data.

Utrulling er tre roller planlagt sammen, ikke ett avkrysningsfelt. Kildeserveren publiserer hasher for innholdet, den hostede cachen aktiveres og er søkbar, og klientene konfigureres til å bruke den. På serversiden kjennes det igjen i PowerShell:

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

På klienten peker du den mot navngitte servere eller lar den oppdage dem via tjenestetilkoblingspunktet; bekreft deretter modusen den faktisk valgte i stedet for å anta at policyen ble brukt:

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

Hva som fortsatt når kilden

Caching fjerner ikke autorisasjon. En klient uten lesetillatelse til en fil får ikke tilgang fordi noen andre har cachet den, og kilden svarer fortsatt på autorisasjonsspørsmålet og leverer innholdsinformasjonen som gjør cacheoppslaget mulig. Hvis kilden ikke er tilgjengelig, blir den cachede kopien alene ikke en offline fildeling.

Innholdsendringer bryter også antakelsen i det stille. En fil som lagres på nytt, kodes om eller berøres av et sikkerhetskopiprodukt, samsvarer kanskje ikke lenger med den cachedede hashen, og neste lesing går tilbake til kilden. Det er riktig atferd, og derfor leverer en cache der arbeidssettet endres hver time, lite.

Fordrivelse er den tredje grensen. Cachen er endelig, så et stort arbeidssett dytter eldre innhold ut, og fordelen avhenger av at gjenlesinger skjer før fordrivelsen og ikke etter. Å dimensjonere cachen for hele fildelingen er den vanlige måten å bli skuffet over en utrulling som var teknisk korrekt.

Godta det med to hentinger og én opplasting

Test de riktige tre flytene og skriv ned hva hver av dem viser. Første henting av en representativ fil fra en klient, målt på kildelenken så vel som på brukerens klokke. Andre henting av den samme uendrede filen fra en annen klient i samme plasseringsgruppe. Én opplasting av en ny fil, som ikke skal vise noen forbedring og bekrefter at cachen ikke får æren for noe den aldri gjorde.

Hvis den andre hentingen fortsatt krysser kildelenken for mesteparten av bytene, brukes ikke cachen, og årsaken er vanligvis en klient i feil modus, en manglende hashpublisering på kilden, eller en hostet cache på feil side av den begrensede lenken. Det er tre forskjellige rettelser, og bare én av dem handler om nettverksplassering.

Angi deretter konklusjonen i samme form som den opprinnelige klagen: gjentatte nedlastinger av uendret innhold fra denne kilden til disse leserne betjenes av denne cachen. Alt annet ved fildelingen er urørt, inkludert opplastinger, mappeoppramsing og offlinehistorien, som fortsatt trenger sitt eget svar.