BranchCache para compartilhamentos de arquivos via VPN: quando ajuda e quando não

Alguém da equipe diz que o compartilhamento de arquivos pela VPN está lento, e a primeira sugestão é sempre um cache. Antes de adicionar o BranchCache ao projeto de acesso remoto, separe a queixa em uma de três formas: downloads repetidos de conteúdo inalterado, uploads, ou navegação com muitos metadados por pastas com milhares de entradas. O BranchCache trata a primeira forma em conteúdo compatível e não faz nada de útil para as outras duas. Isso não é uma limitação a contornar; é a comparação que você deve fazer antes de gastar uma semana na implantação.

O mesmo compartilhamento, três queixas diferentes

Um escritório filial onde oito pessoas abrem o mesmo vídeo de treinamento inalterado é o caso para o qual o recurso foi projetado. A primeira recuperação atravessa a WAN, o conteúdo é armazenado em cache perto dos leitores, e as recuperações posteriores do mesmo arquivo inalterado são servidas localmente. O benefício é real e é estreito: mesmo conteúdo, inalterado, vários leitores.

Um notebook que envia uma nova gravação por uma conexão residencial é o caso oposto. Não existe cópia previamente em cache de um arquivo que ainda não existe, então o upload segue o mesmo caminho restrito de sempre. Um cache de download não elimina um upload, e nenhuma escolha de posicionamento muda isso.

A terceira forma é a que decepciona as pessoas, porque parece um problema de download. Abrir um diretório com dezenas de milhares de arquivos, ordená-lo e ler metadados é um fluxo de operações pequenas, não uma transferência repetida de um objeto grande. Armazenar em cache o corpo dos arquivos não faz nada pela enumeração.

Cache distribuído: um pool de VPN não é uma LAN de filial

No modo distribuído, os computadores clientes compartilham conteúdo em cache entre si, e a Microsoft documenta esse modo como operando dentro de uma única sub-rede. Um pool de clientes VPN não é uma sub-rede nesse sentido, mesmo quando todos os endereços parecem contíguos: descoberta de pares, alcançabilidade de cliente para cliente e permissão para trocar dados de cache são questões separadas, e o projeto habitual de acesso remoto responde “não” às três.

Você pode fazer o pool se comportar como uma LAN de filial permitindo tráfego de cliente para cliente, mas essa é uma decisão de segurança, não de cache. A maioria dos projetos de acesso remoto isola os clientes uns dos outros justamente para que um notebook comprometido não alcance outro, e trocar esse isolamento por um acerto de cache é uma troca ruim, a menos que os pares já sejam iguais confiáveis.

Para um único usuário móvel, o modo distribuído não tem com quem compartilhar. O cache ainda pode servir as leituras repetidas desse cliente, mas isso é um benefício de cache do lado do cliente, não de posicionamento na filial, e vale dizer isso antes que alguém espere que o escritório fique mais rápido.

Cache hospedado: o posicionamento decide se ele ajuda

Um cache hospedado coloca o cache compartilhado em um servidor, que é o único modo que faz sentido entre sub-redes e o único que funciona quando os clientes não conseguem falar entre si. A pergunta imediata é onde esse servidor fica. Um cache hospedado alcançado pelo mesmo link restrito que a origem moveu os bytes, não o problema.

Coloque-o perto dos leitores, atribua um responsável e dimensione o disco para o conjunto de trabalho, não para o compartilhamento inteiro. A visão geral do BranchCache da Microsoft descreve os dois modos e o comportamento do cliente, incluindo a parte que as pessoas esquecem: os clientes ainda contatam a origem para autorização e informações de conteúdo antes de usar os dados em cache.

A implantação são três funções planejadas juntas, não uma caixa de seleção. O servidor de origem publica hashes do conteúdo, o cache hospedado é habilitado e detectável, e os clientes são configurados para usá-lo. No lado do servidor isso é reconhecível no PowerShell:

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

No cliente, aponte-o para servidores nomeados ou deixe que ele os descubra pelo ponto de conexão do serviço; depois confirme o modo que ele realmente selecionou em vez de supor que a política foi aplicada:

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

O que ainda chega à origem

O cache não elimina a autorização. Um cliente sem permissão para ler um arquivo não ganha acesso porque outra pessoa o armazenou em cache, e a origem ainda responde à pergunta de autorização e fornece as informações de conteúdo que tornam possível a consulta ao cache. Se a origem estiver inacessível, a cópia em cache sozinha não se torna um compartilhamento offline.

Mudanças de conteúdo também quebram a suposição em silêncio. Um arquivo que é salvo novamente, recodificado ou tocado por um produto de backup pode não corresponder mais ao hash em cache, e a próxima leitura volta para a origem. Esse é o comportamento correto, e é por isso que um cache cujo conjunto de trabalho muda a cada hora entrega pouco.

A remoção é o terceiro limite. O cache é finito, então um conjunto de trabalho grande empurra o conteúdo mais antigo para fora, e o benefício depende de releituras acontecerem antes da remoção e não depois. Dimensionar o cache para o compartilhamento inteiro é a maneira habitual de se decepcionar com uma implantação tecnicamente correta.

Aceite com duas recuperações e um upload

Teste os três fluxos certos e anote o que cada um mostra. Primeira recuperação de um arquivo representativo a partir de um cliente, medida no link de origem e também no relógio do usuário. Segunda recuperação do mesmo arquivo inalterado a partir de um segundo cliente no mesmo grupo de posicionamento. Um upload de um arquivo novo, que não deve mostrar melhora e confirma que o cache não está sendo creditado por algo que nunca fez.

Se a segunda recuperação ainda atravessar o link de origem para a maior parte dos bytes, o cache não está sendo usado, e a causa costuma ser um cliente no modo errado, uma publicação de hash ausente na origem, ou um cache hospedado no lado errado do link restrito. São três correções diferentes, e apenas uma delas é sobre posicionamento de rede.

Depois enuncie a conclusão na mesma forma da queixa original: downloads repetidos de conteúdo inalterado desta origem para estes leitores são servidos por este cache. Todo o resto do compartilhamento fica intacto, incluindo uploads, enumeração de pastas e a história offline, que ainda precisa de sua própria resposta.