BranchCache para cartafoles compartidos por VPN: cando axuda e cando non
BranchCache acelera as descargas repetidas de contido sen cambios, non as cargas nin a listaxe de cartafoles. Comprobe primeiro a ubicación, a accesibilidade e o modo do cliente.
Alguén do equipo di que o cartafol compartido por VPN vai lento, e a primeira suxestión sempre é unha caché. Antes de engadir BranchCache ao deseño de acceso remoto, separe a queixa nunha de tres formas: descargas repetidas de contido sen cambios, cargas, ou navegación con moitos metadatos por cartafoles con miles de entradas. BranchCache resolve a primeira forma en contido compatible e non fai nada útil para as outras dúas. Non é unha limitación que haxa que evitar; é a comparación que debería facer antes de gastar unha semana no despregamento.
O mesmo cartafol, tres queixas diferentes
Unha oficina de sucursal onde oito persoas abren o mesmo vídeo de formación sen cambios é o caso para o que se deseñou a función. A primeira recuperación cruza a WAN, o contido gárdase na caché preto dos lectores e as recuperacións posteriores do mesmo ficheiro sen cambios sírvense localmente. O beneficio é real e estreito: mesmo contido, sen cambios, varios lectores.
Un portátil que carga unha gravación nova por unha conexión doméstica é o caso oposto. Non hai copia previamente na caché dun ficheiro que aínda non existe, así que a carga segue o mesmo camiño restrinxido de sempre. Unha caché de descargas non elimina unha carga, e ningunha elección de ubicación cambia iso.
A terceira forma é a que decepciona a xente porque parece un problema de descarga. Abrir un directorio con decenas de miles de ficheiros, ordenalo e ler metadatos é un fluxo de operacións pequenas, non unha transferencia repetida dun obxecto grande. Gardar na caché os corpos dos ficheiros non fai nada pola enumeración.
Caché distribuída: un pool de VPN non é unha LAN de sucursal
En modo distribuído, os ordenadores clientes comparten contido en caché entre si, e Microsoft documenta ese modo como operativo dentro dunha única subrede. Un pool de clientes VPN non é unha subrede nese sentido aínda que todos os enderezos parezan contiguos: o descubrimento de pares, a accesibilidade cliente a cliente e o permiso para intercambiar datos de caché son cuestións separadas, e o deseño habitual de acceso remoto responde as tres con non.
Pode facer que o pool se comporte como unha LAN de sucursal permitindo tráfico entre clientes, pero iso é unha decisión de seguridade, non de caché. A maioría dos deseños de acceso remoto illan os clientes entre si precisamente para que un portátil comprometido non poida chegar a outro, e trocar ese illamento por un acerto de caché é un mal intercambio a menos que os pares xa sexan iguais de confianza.
Para un único usuario itinerante, o modo distribuído non ten con quen compartir. A caché aínda pode servir as lecturas repetidas dese único cliente, pero iso é un beneficio de caché no lado do cliente, non un beneficio de ubicación na sucursal, e paga a pena dicilo antes de que alguén espere que a oficina vaia máis rápido.
Caché aloxada: a ubicación decide se axuda
Unha caché aloxada pon a caché compartida nun servidor, que é o único modo que ten sentido entre subredes e o único que funciona cando os clientes non poden falar entre si. A pregunta inmediata é onde está ese servidor. Unha caché aloxada á que se chega polo mesmo enlace restrinxido que á orixe moveu os bytes, non o problema.
Colóquea preto dos lectores, dálle un propietario e dimensiona o disco para o conxunto de traballo e non para todo o cartafol. O resumo de BranchCache de Microsoft describe ambos os modos e o comportamento do cliente, incluída a parte que a xente esquece: os clientes aínda contactan a orixe para a autorización e a información de contido antes de usar os datos na caché.
O despregamento son tres roles planificados xuntos, non unha caixa de verificación. O servidor de orixe publica hashes para o contido, a caché aloxada está habilitada e é detectable, e os clientes están configurados para usala. No lado do servidor iso é recoñecible en PowerShell:
Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList
No cliente, ou ben apúntao a servidores con nome ou ben deixa que os descubra mediante o punto de conexión do servizo; despois confirma o modo que seleccionou realmente en lugar de supoñer que a política se aplicou:
Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode
Que aínda chega á orixe
A caché non elimina a autorización. Un cliente sen permiso para ler un ficheiro non obtén acceso porque outro o gardase na caché, e a orixe aínda responde a pregunta de autorización e fornece a información de contido que fai posible a consulta na caché. Se a orixe non é accesible, a copia na caché non se converte por si soa nun cartafol compartido fóra de liña.
Os cambios de contido tamén rompen a suposición en silencio. Un ficheiro que se volve gardar, se recodifica ou o toca un produto de copia de seguridade pode xa non coincidir co hash na caché, e a lectura seguinte volve á orixe. Ese é o comportamento correcto, e por iso unha caché cuxo conxunto de traballo cambia cada hora achega pouco.
A expulsión é o terceiro límite. A caché é finita, así que un conxunto de traballo grande empurra o contido máis antigo fóra, e o beneficio depende de que as relecturas ocorran antes da expulsión e non despois. Dimensionar a caché para todo o cartafol é a forma habitual de quedar decepcionado cun despregamento tecnicamente correcto.
Acéptao con dúas recuperacións e unha carga
Proba os tres fluxos correctos e anota o que mostra cada un. Primeira recuperación dun ficheiro representativo desde un cliente, medida no enlace de orixe e tamén no reloxo do usuario. Segunda recuperación do mesmo ficheiro sen cambios desde un segundo cliente no mesmo grupo de ubicación. Unha carga dun ficheiro novo, que non debería mostrar mellora e confirma que non se lle atribúe á caché algo que nunca fixo.
Se a segunda recuperación aínda cruza o enlace de orixe para a maior parte dos bytes, a caché non se está usando, e a causa adoita ser un cliente no modo incorrecto, unha publicación de hash ausente na orixe ou unha caché aloxada no lado incorrecto do enlace restrinxido. Son tres correccións diferentes, e só unha delas trata da ubicación na rede.
Despois expón a conclusión coa mesma forma que a queixa orixinal: as descargas repetidas de contido sen cambios desde esta orixe a estes lectores sírveas esta caché. Todo o demais sobre o cartafol queda intacto, incluídas as cargas, a enumeración de cartafoles e o relato fóra de liña, que aínda necesita a súa propia resposta.