BranchCache per a carpetes compartides per VPN: quan ajuda i quan no

Algú de l'equip diu que la carpeta compartida per VPN va lenta, i el primer suggeriment sempre és una memòria cau. Abans d'afegir BranchCache al disseny d'accés remot, separeu la queixa en una de tres formes: baixades repetides de contingut sense canvis, pujades, o navegació amb moltes metadades per carpetes amb milers d'entrades. BranchCache resol la primera forma en contingut compatible i no fa res útil per a les altres dues. No és una limitació que calgui esquivar; és la comparació que hauríeu de fer abans de gastar una setmana en el desplegament.

La mateixa carpeta, tres queixes diferents

Una oficina branch on vuit persones obren el mateix vídeo de formació sense canvis és el cas per al qual es va dissenyar la funció. La primera recuperació travessa la WAN, el contingut es guarda a la memòria cau a prop dels lectors i les recuperacions posteriors del mateix fitxer sense canvis se serveixen localment. El benefici és real i estret: mateix contingut, sense canvis, diversos lectors.

Un portàtil que puja una gravació nova per una connexió domèstica és el cas oposat. No hi ha cap còpia prèviament a la memòria cau d'un fitxer que encara no existeix, així que la pujada segueix el mateix camí restringit de sempre. Una memòria cau de baixades no elimina una pujada, i cap elecció d'ubicació ho canvia.

La tercera forma és la que decep la gent perquè sembla un problema de baixada. Obrir un directori amb desenes de milers de fitxers, ordenar-lo i llegir metadades és un flux d'operacions petites, no una transferència repetida d'un objecte gran. Guardar a la memòria cau els cossos dels fitxers no fa res per a l'enumeració.

Memòria cau distribuïda: un pool de VPN no és una LAN d'oficina branch

En mode distribuït, els ordinadors clients comparteixen contingut a la memòria cau entre ells, i Microsoft documenta aquest mode com a operatiu dins d'una única subxarxa. Un pool de clients VPN no és una subxarxa en aquest sentit encara que totes les adreces semblin contigües: el descobriment de parells, l'abast client a client i el permís per intercanviar dades de memòria cau són qüestions separades, i el disseny habitual d'accés remot respon les tres amb no.

Podeu fer que el pool es comporti com una LAN d'oficina branch permetent trànsit entre clients, però això és una decisió de seguretat, no de memòria cau. La majoria de dissenys d'accés remot aïllen els clients entre ells precisament perquè un portàtil compromès no pugui arribar a un altre, i canviar aquest aïllament per un encert de memòria cau és un mal intercanvi tret que els parells ja siguin iguals de confiança.

Per a un sol usuari itinerant, el mode distribuït no té amb qui compartir. La memòria cau encara pot servir les lectures repetides d'aquest únic client, però això és un benefici de memòria cau al costat del client, no un benefici d'ubicació a l'oficina, i val la pena dir-ho abans que algú esperi que l'oficina vagi més ràpida.

Memòria cau allotjada: la ubicació decideix si ajuda

Una memòria cau allotjada posa la memòria cau compartida en un servidor, que és l'únic mode que té sentit entre subxarxes i l'únic que funciona quan els clients no es poden comunicar entre ells. La pregunta immediata és on és aquest servidor. Una memòria cau allotjada a la qual s'arriba pel mateix enllaç restringit que l'origen ha mogut els bytes, no el problema.

Col·loqueu-la a prop dels lectors, doneu-li un propietari i dimensioneu el disc per al conjunt de treball, no per a tota la carpeta. El resum de BranchCache de Microsoft descriu tots dos modes i el comportament del client, inclosa la part que la gent oblida: els clients encara contacten l'origen per a l'autorització i la informació de contingut abans d'usar les dades a la memòria cau.

El desplegament són tres rols planificats junts, no una casella de verificació. El servidor d'origen publica hashes per al contingut, la memòria cau allotjada està habilitada i és detectable, i els clients estan configurats per usar-la. Al costat del servidor això és recognoscible a PowerShell:

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

Al client, o bé apunteu-lo a servidors amb nom o bé deixeu que els descobreixi mitjançant el punt de connexió del servei; després confirmeu el mode que ha seleccionat realment en lloc de suposar que la política s'ha aplicat:

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

Què encara arriba a l'origen

La memòria cau no elimina l'autorització. Un client sense permís per llegir un fitxer no obté accés perquè algú altre l'hagi guardat a la memòria cau, i l'origen encara respon la pregunta d'autorització i proporciona la informació de contingut que fa possible la consulta a la memòria cau. Si l'origen no és accessible, la còpia a la memòria cau no es converteix per si sola en una carpeta compartida fora de línia.

Els canvis de contingut també trenquen l'assumpció en silenci. Un fitxer que es torna a desar, es recodifica o el toca un producte de còpia de seguretat pot ja no coincidir amb el hash a la memòria cau, i la lectura següent torna a l'origen. Aquest és el comportament correcte, i és per això que una memòria cau el conjunt de treball de la qual canvia cada hora aporta poc.

L'expulsió és el tercer límit. La memòria cau és finita, així que un conjunt de treball gran empeny el contingut més antic fora, i el benefici depèn que les relectures passin abans de l'expulsió i no després. Dimensionar la memòria cau per a tota la carpeta és la manera habitual de quedar decebut per un desplegament tècnicament correcte.

Accepteu-ho amb dues recuperacions i una pujada

Proveu els tres fluxos correctes i anoteu què mostra cadascun. Primera recuperació d'un fitxer representatiu des d'un client, mesurada a l'enllaç d'origen i també al rellotge de l'usuari. Segona recuperació del mateix fitxer sense canvis des d'un segon client del mateix grup d'ubicació. Una pujada d'un fitxer nou, que no hauria de mostrar cap millora i confirma que no s'atribueix a la memòria cau una cosa que mai no ha fet.

Si la segona recuperació encara travessa l'enllaç d'origen per a la major part dels bytes, la memòria cau no s'està usant, i la causa sol ser un client en el mode equivocat, una publicació de hash absent a l'origen o una memòria cau allotjada al costat equivocat de l'enllaç restringit. Són tres correccions diferents, i només una és sobre la ubicació a la xarxa.

Després exposeu la conclusió amb la mateixa forma que la queixa original: les baixades repetides de contingut sense canvis des d'aquest origen a aquests lectors les serveix aquesta memòria cau. Tota la resta de la carpeta queda intacta, incloses les pujades, l'enumeració de carpetes i el relat fora de línia, que encara necessita la seva pròpia resposta.