Caché de metadatos de Azure Files frente a una caché local de sucursal
Una caché de metadatos del lado del servicio reduce el trabajo del servidor. No saca los viajes de ida y vuelta de su WAN. Compare las dos opciones por lo que realmente acortan.
Para el acceso lento a Azure Files a través de una VPN se proponen dos cambios, y acortan cosas distintas. La caché de metadatos del lado del servicio abarata las operaciones elegibles para el servidor. Una caché local de sucursal acerca los bytes y las operaciones al usuario. Elegir entre ambas por una lista de precios o una nota de prensa es como un recurso compartido acaba siendo más rápido en una prueba y sin cambios a las nueve de la mañana.
Dos cachés, dos latencias distintas
Ambas opciones aparecen bajo la palabra caché, y ahí empieza la confusión. Se sitúan en lados opuestos de la red.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
La guía de rendimiento de SMB de Microsoft describe la caché de metadatos para recursos SSD elegibles junto con el paso de registro que la acompaña. La elegibilidad y el estado de la característica pertenecen a la cuenta de almacenamiento real, así que lea la página actual y no un anuncio de vista previa de hace dos años.
Divida la espera en tres partes
Cada listado de directorio lento tiene tres componentes de coste, y responden a correcciones distintas. Está el tiempo de procesamiento de la solicitud en el lado del servicio, el número de viajes de ida y vuelta dependientes a través de la VPN y la carga útil que hay que mover. Una caché del lado del servicio ataca el primero. Nada del lado del servidor ataca el segundo.
Por eso un recurso compartido puede mostrar mejores métricas de servicio mientras el selector de archivos del usuario sigue colgado durante ocho segundos.
Dónde gana su lugar cada opción
Si la carga de trabajo es intensiva en metadatos, con muchas aperturas, llamadas stat y enumeraciones de directorios contra un recurso SSD elegible, la caché del lado del servicio es el experimento barato. No necesita infraestructura nueva ni cambia cómo llegan los usuarios al recurso.
Si la carga de trabajo es interactiva y está limitada por la latencia, la opción honesta es un diseño de servidor local compatible con un modelo de sincronización documentado. Es una arquitectura distinta con sus propios costes operativos, no un interruptor.
Qué no cambia ninguna de las dos opciones
La firma y el cifrado SMB siguen aplicándose y siguen costando lo que cuestan. El control de acceso todavía se resuelve por usuario, así que una copia en caché no simplifica la autorización. La consistencia entre sedes todavía necesita un modelo definido, porque las lecturas locales de la sucursal y las escrituras del lado de la nube tienen que ponerse de acuerdo en algo. Y el acceso sin conexión sigue siendo un ajuste del cliente, no un efecto secundario de una característica del servidor.
Cuando alguien promete que una característica del servicio elimina los viajes de ida y vuelta de la WAN, esa es la afirmación que hay que probar primero.
Mida contra la operación de la que se quejan los usuarios
Cronometre la operación exacta en lugar de una copia sintética. Measure-Command { Get-ChildItem \\files\projects -Recurse } en un cliente de sucursal da un número que puede comparar antes y después, y Get-SmbMultichannelConnection muestra si el cliente usa más de una ruta. Ponga eso junto a las métricas de latencia del lado del servicio para la misma ventana.
Mantenga constantes el recurso compartido, la ubicación del cliente, la ruta de la VPN y la política de seguridad, o estará midiendo su ventana de cambios en lugar de la característica. Anote también el número de archivos y la distribución de tamaños, porque las cargas de archivos pequeños y las copias masivas responden a palancas completamente distintas.
El resultado que merece la pena es un cambio ajustado al límite que realmente era lento, con sus costes operativos y de consistencia escritos. Una cifra mayor de IOPS de almacenamiento en una diapositiva no es ese resultado.