Caché de metadatos de Azure Files fronte a unha caché local de sucursal
Unha caché de metadatos do lado do servizo reduce o traballo do servidor. Non saca as viaxes de ida e volta da súa WAN. Compare as dúas opcións polo que realmente acurtan.
Para o acceso lento a Azure Files a través dunha VPN propóñense dous cambios, e acurtan cousas distintas. A caché de metadatos do lado do servizo abarata as operacións elixibles para o servidor. Unha caché local de sucursal achega os bytes e as operacións ao usuario. Escoller entre ambas por unha lista de prezos ou unha nota de prensa é como un recurso compartido acaba sendo máis rápido nunha proba e sen cambios ás nove da mañá.
Dúas cachés, dúas latencias distintas
Ambas opcións aparecen baixo a palabra caché, e aí comeza a confusión. Sitúánse en lados opostos da rede.
| 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 |
A guía de rendemento de SMB de Microsoft describe a caché de metadatos para recursos SSD elixibles xunto co paso de rexistro que a acompaña. A elixibilidade e o estado da función pertencen á conta de almacenamento real, así que lea a páxina actual e non un anuncio de vista previa de hai dous anos.
Divida a espera en tres partes
Cada listaxe de directorio lenta ten tres compoñentes de custo, e responden a correccións distintas. Está o tempo de procesamento da solicitude no lado do servizo, o número de viaxes de ida e volta dependentes a través da VPN e a carga útil que hai que mover. Unha caché do lado do servizo ataca o primeiro. Nada do lado do servidor ataca o segundo.
Por iso un recurso compartido pode mostrar mellores métricas de servizo mentres o selector de ficheiros do usuario segue colgado durante oito segundos.
Onde gaña o seu sitio cada opción
Se a carga de traballo é intensiva en metadatos, con moitas aperturas, chamadas stat e enumeracións de directorios contra un recurso SSD elixible, a caché do lado do servizo é o experimento barato. Non precisa infraestrutura nova nin cambia como chegan os usuarios ao recurso.
Se a carga de traballo é interactiva e está limitada pola latencia, a opción honesta é un deseño de servidor local compatible cun modelo de sincronización documentado. É unha arquitectura distinta cos seus propios custos operativos, non un interruptor.
Que non cambia ningunha das dúas opcións
A sinatura e o cifrado SMB seguen aplicándose e seguen custando o que custan. O control de acceso aínda se resolve por usuario, así que unha copia en caché non simplifica a autorización. A consistencia entre sedes aínda necesita un modelo definido, porque as lecturas locais da sucursal e as escrituras do lado da nube teñen que poñerse de acordo en algo. E o acceso sen conexión segue sendo un axuste do cliente, non un efecto secundario dunha función do servidor.
Cando alguén promete que unha función do servizo elimina as viaxes de ida e volta da WAN, esa é a afirmación que hai que probar primeiro.
Mida contra a operación da que se queixan os usuarios
Cronometre a operación exacta en lugar dunha copia sintética. Measure-Command { Get-ChildItem \\files\projects -Recurse } nun cliente de sucursal dá un número que pode comparar antes e despois, e Get-SmbMultichannelConnection mostra se o cliente usa máis dunha ruta. Poña iso xunto ás métricas de latencia do lado do servizo para a mesma ventá.
Manteña constantes o recurso compartido, a localización do cliente, a ruta da VPN e a política de seguridade, ou estará medindo a súa ventá de cambios en lugar da función. Anote tamén o número de ficheiros e a distribución de tamaños, porque as cargas de ficheiros pequenos e as copias masivas responden a pancas completamente distintas.
O resultado que paga a pena é un cambio axustado ao límite que realmente era lento, cos seus custos operativos e de consistencia escritos. Unha cifra maior de IOPS de almacenamento nunha diapositiva non é ese resultado.