Cache de metadados do Azure Files versus um cache local de filial
Um cache de metadados do lado do serviço reduz o trabalho do servidor. Não retira as viagens de ida e volta da sua WAN. Compare os dois pelo que realmente encurtam.
Para o acesso lento ao Azure Files através de uma VPN propõem-se duas alterações, e encurtam coisas diferentes. O cache de metadados do lado do serviço torna as operações elegíveis mais baratas para o servidor. Um cache local de filial aproxima os bytes e as operações do utilizador. Escolher entre os dois com base numa lista de preços ou num comunicado de imprensa é como uma partilha acaba mais rápida num teste e inalterada às nove da manhã.
Duas caches, duas latências diferentes
Ambas as opções aparecem sob a palavra cache, e é aí que começa a confusão. Ficam em 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 |
O guia de desempenho de SMB da Microsoft descreve a colocação em cache de metadados para partilhas SSD elegíveis, juntamente com o passo de registo que a acompanha. A elegibilidade e o estado da funcionalidade pertencem à conta de armazenamento real, por isso leia a página atual e não um anúncio de pré-visualização de há dois anos.
Divida a espera em três partes
Cada listagem de diretório lenta tem três componentes de custo, e respondem a correções diferentes. Há o tempo de processamento do pedido do lado do serviço, o número de viagens de ida e volta dependentes através da VPN e a carga útil que tem de ser movida. Um cache do lado do serviço ataca o primeiro. Nada do lado do servidor ataca o segundo.
É por isso que uma partilha pode mostrar melhores métricas de serviço enquanto o seletor de ficheiros do utilizador continua bloqueado durante oito segundos.
Onde cada opção merece o seu lugar
Se a carga de trabalho for intensiva em metadados, com muitas aberturas, chamadas stat e enumerações de diretórios contra uma partilha SSD elegível, a colocação em cache do lado do serviço é a experiência barata. Não exige infraestrutura nova nem altera a forma como os utilizadores chegam à partilha.
Se a carga de trabalho for interativa e limitada pela latência, a opção honesta é um desenho de servidor local suportado com um modelo de sincronização documentado. É uma arquitetura diferente, com os seus próprios custos operacionais, não um interruptor.
O que nenhuma das opções altera
A assinatura e a cifragem SMB continuam a aplicar-se, e continuam a custar o que custam. O controlo de acesso continua a ser resolvido por utilizador, pelo que uma cópia em cache não simplifica a autorização. A consistência entre locais continua a precisar de um modelo definido, porque as leituras locais na filial e as escritas do lado da nuvem têm de concordar em algo. E o acesso offline continua a ser uma definição do cliente, não um efeito secundário de uma funcionalidade do servidor.
Quando alguém promete que uma funcionalidade do serviço elimina as viagens de ida e volta da WAN, é essa a afirmação a testar primeiro.
Meça em função da operação de que os utilizadores se queixam
Cronometre a operação exata em vez de uma cópia sintética. Measure-Command { Get-ChildItem \\files\projects -Recurse } num cliente de filial dá um número que pode comparar antes e depois, e Get-SmbMultichannelConnection mostra se o cliente usa mais do que um caminho. Coloque isso ao lado das métricas de latência do lado do serviço para a mesma janela.
Mantenha constantes a partilha, a localização do cliente, o caminho VPN e a política de segurança, ou estará a medir a sua janela de alteração em vez da funcionalidade. Registe também o número de ficheiros e a distribuição de tamanhos, porque as cargas de ficheiros pequenos e as cópias massivas respondem a alavancas completamente diferentes.
O resultado que vale a pena é uma alteração ajustada ao limite que era realmente lento, com os seus custos operacionais e de consistência escritos. Um número de IOPS de armazenamento maior num diapositivo não é esse resultado.