BranchCache para recursos compartidos por VPN: cuándo ayuda y cuándo no

Alguien del equipo dice que el recurso compartido por VPN va lento, y la primera sugerencia siempre es una caché. Antes de añadir BranchCache al diseño de acceso remoto, separe la queja en una de tres formas: descargas repetidas de contenido sin cambios, cargas, o navegación con mucha metadata por carpetas con miles de entradas. BranchCache atiende la primera forma con contenido compatible y no hace nada útil para las otras dos. No es una limitación que haya que sortear; es la comparación que conviene hacer antes de dedicar una semana al despliegue.

El mismo recurso compartido, tres quejas distintas

Una oficina sucursal donde ocho personas abren el mismo vídeo de formación sin cambios es el caso para el que se diseñó la función. La primera recuperación cruza la WAN, el contenido se almacena en caché cerca de los lectores y las recuperaciones posteriores del mismo archivo sin cambios se sirven localmente. El beneficio es real y es estrecho: mismo contenido, sin cambios, varios lectores.

Un portátil que sube una grabación nueva por una conexión doméstica es el caso opuesto. No hay copia en caché previa de un archivo que aún no existe, así que la carga sigue el mismo camino restringido de siempre. Una caché de descargas no elimina una carga, y ninguna elección de ubicación cambia eso.

La tercera forma es la que decepciona porque parece un problema de descarga. Abrir un directorio con decenas de miles de archivos, ordenarlo y leer metadata es una corriente de operaciones pequeñas, no una transferencia repetida de un objeto grande. Almacenar en caché los cuerpos de los archivos no hace nada por la enumeración.

Caché distribuida: un grupo de VPN no es una LAN de sucursal

En modo distribuido, los equipos cliente comparten el contenido en caché entre sí, y Microsoft documenta ese modo como operativo dentro de una única subred. Un grupo de clientes VPN no es una subred en ese sentido aunque todas las direcciones parezcan contiguas: el descubrimiento de pares, la accesibilidad cliente a cliente y el permiso para intercambiar datos de caché son cuestiones distintas, y el diseño habitual de acceso remoto responde a las tres con «no».

Puede hacer que el grupo se comporte como una LAN de sucursal permitiendo tráfico cliente a cliente, pero eso es una decisión de seguridad, no de caché. La mayoría de los diseños de acceso remoto aíslan a los clientes entre sí precisamente para que un portátil comprometido no alcance a otro, y cambiar ese aislamiento por un acierto de caché es un mal trueque salvo que los pares ya sean iguales de confianza.

Para un único usuario itinerante, el modo distribuido no tiene con quién compartir. La caché todavía puede servir las lecturas repetidas de ese cliente, pero eso es un beneficio de caché del lado del cliente, no de ubicación en la sucursal, y conviene decirlo antes de que alguien espere que la oficina vaya más rápido.

Caché hospedada: la ubicación decide si ayuda

Una caché hospedada coloca la caché compartida en un servidor, que es el único modo que tiene sentido entre subredes y el único que funciona cuando los clientes no pueden hablar entre sí. La pregunta inmediata es dónde está ese servidor. Una caché hospedada a la que se llega por el mismo enlace restringido que el origen ha movido los bytes, no el problema.

Colóquela cerca de los lectores, asígnele un propietario y dimensione su disco para el conjunto de trabajo en lugar de para todo el recurso compartido. La descripción general de BranchCache de Microsoft describe ambos modos y el comportamiento del cliente, incluida la parte que la gente olvida: los clientes siguen contactando con el origen para la autorización y la información de contenido antes de usar los datos en caché.

El despliegue son tres roles planificados juntos, no una casilla. El servidor de origen publica los hashes del contenido, la caché hospedada se habilita y es detectable, y los clientes se configuran para usarla. En el lado del servidor eso se reconoce en PowerShell:

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

En el cliente, apúntelo a servidores con nombre o deje que los descubra mediante el punto de conexión de servicio; después confirme el modo que seleccionó realmente en lugar de suponer que la directiva se aplicó:

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

Qué sigue llegando al origen

La caché no elimina la autorización. Un cliente sin permiso para leer un archivo no obtiene acceso porque otro lo haya almacenado en caché, y el origen sigue respondiendo a la pregunta de autorización y proporcionando la información de contenido que hace posible la consulta en caché. Si el origen no es accesible, la copia en caché por sí sola no se convierte en un recurso compartido sin conexión.

Los cambios de contenido también rompen la suposición en silencio. Un archivo que se vuelve a guardar, se recodifica o lo toca un producto de copia de seguridad puede dejar de coincidir con el hash en caché, y la siguiente lectura vuelve al origen. Ese es el comportamiento correcto, y por eso una caché cuyo conjunto de trabajo cambia cada hora aporta poco.

El desalojo es el tercer límite. La caché es finita, así que un conjunto de trabajo grande expulsa el contenido más antiguo, y el beneficio depende de que las relecturas ocurran antes del desalojo y no después. Dimensionar la caché para todo el recurso compartido es la forma habitual de quedar decepcionado con un despliegue técnicamente correcto.

Acéptelo con dos recuperaciones y una carga

Pruebe los tres flujos correctos y anote lo que muestra cada uno. Primera recuperación de un archivo representativo desde un cliente, medida en el enlace de origen y también en el reloj del usuario. Segunda recuperación del mismo archivo sin cambios desde un segundo cliente del mismo grupo de ubicación. Una única carga de un archivo nuevo, que no debería mostrar mejora y confirma que no se atribuye a la caché algo que nunca hizo.

Si la segunda recuperación sigue cruzando el enlace de origen para la mayor parte de los bytes, la caché no se está usando, y la causa suele ser un cliente en el modo equivocado, una publicación de hash ausente en el origen, o una caché hospedada en el lado equivocado del enlace restringido. Son tres arreglos distintos, y solo uno tiene que ver con la ubicación de red.

Después formule la conclusión con la misma forma que la queja original: las descargas repetidas de contenido sin cambios desde este origen a estos lectores las sirve esta caché. Todo lo demás del recurso compartido queda intacto, incluidas las cargas, la enumeración de carpetas y el relato sin conexión, que aún necesita su propia respuesta.