BranchCache per le condivisioni di file via VPN: quando aiuta, quando no

Qualcuno del team dice che la condivisione di file tramite VPN è lenta, e il primo suggerimento è sempre una cache. Prima di aggiungere BranchCache al progetto di accesso remoto, separate la lamentela in una di tre forme: download ripetuti di contenuto invariato, upload, oppure navigazione densa di metadati in cartelle con migliaia di voci. BranchCache affronta la prima forma sui contenuti supportati e non fa nulla di utile per le altre due. Non è un limite da aggirare; è il confronto da fare prima di spendere una settimana nella distribuzione.

La stessa condivisione, tre lamentele diverse

Una filiale in cui otto persone aprono lo stesso video di formazione invariato è il caso per cui la funzione è stata progettata. Il primo recupero attraversa la WAN, il contenuto viene messo in cache vicino ai lettori e i recuperi successivi dello stesso file invariato vengono serviti localmente. Il beneficio è reale ed è ristretto: stesso contenuto, invariato, più lettori.

Un portatile che carica una nuova registrazione tramite una connessione domestica è il caso opposto. Non esiste una copia già in cache di un file che ancora non esiste, quindi l'upload segue lo stesso percorso vincolato di sempre. Una cache di download non elimina un upload, e nessuna scelta di posizionamento cambia questo.

La terza forma è quella che delude, perché sembra un problema di download. Aprire una directory con decine di migliaia di file, ordinarla e leggere i metadati è un flusso di piccole operazioni, non un trasferimento ripetuto di un oggetto grande. Mettere in cache i corpi dei file non fa nulla per l'enumerazione.

Cache distribuita: un pool VPN non è una LAN di filiale

In modalità distribuita, i computer client condividono il contenuto in cache tra loro, e Microsoft documenta questa modalità come operante all'interno di una singola subnet. Un pool di client VPN non è una subnet in questo senso anche quando tutti gli indirizzi sembrano contigui: scoperta dei peer, raggiungibilità da client a client e autorizzazione a scambiare dati di cache sono questioni separate, e il solito progetto di accesso remoto risponde «no» a tutte e tre.

Potete far comportare il pool come una LAN di filiale consentendo il traffico da client a client, ma è una decisione di sicurezza, non di cache. La maggior parte dei progetti di accesso remoto isola i client gli uni dagli altri proprio perché un portatile compromesso non possa raggiungerne un altro, e scambiare quell'isolamento con un successo di cache è un cattivo affare, a meno che i peer non siano già pari fidati.

Per un singolo utente in movimento, la modalità distribuita non ha nessuno con cui condividere. La cache può comunque servire le letture ripetute di quel client, ma è un beneficio di cache lato client, non di posizionamento in filiale, e vale la pena dirlo prima che qualcuno si aspetti che l'ufficio diventi più veloce.

Cache ospitata: il posizionamento decide se aiuta

Una cache ospitata mette la cache condivisa su un server, che è l'unica modalità sensata tra subnet e l'unica che funziona quando i client non possono parlarsi. La domanda immediata è dove si trovi quel server. Una cache ospitata raggiunta attraverso lo stesso collegamento vincolato dell'origine ha spostato i byte, non il problema.

Mettetela vicino ai lettori, assegnatele un proprietario e dimensionate il suo disco per il working set invece che per l'intera condivisione. La panoramica di BranchCache di Microsoft descrive entrambe le modalità e il comportamento del client, inclusa la parte che le persone dimenticano: i client contattano ancora l'origine per l'autorizzazione e le informazioni sul contenuto prima di usare i dati in cache.

La distribuzione è tre ruoli pianificati insieme, non una casella di controllo. Il server di origine pubblica gli hash del contenuto, la cache ospitata viene abilitata ed è individuabile, e i client sono configurati per usarla. Sul lato server questo si riconosce in PowerShell:

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

Sul client, indirizzatelo verso server con nome oppure lasciate che li scopra tramite il punto di connessione del servizio; poi confermate la modalità che ha effettivamente selezionato invece di dare per scontato che il criterio sia stato applicato:

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

Cosa raggiunge ancora l'origine

La cache non elimina l'autorizzazione. Un client senza permesso di lettura su un file non ottiene accesso perché qualcun altro l'ha messo in cache, e l'origine risponde ancora alla domanda di autorizzazione e fornisce le informazioni sul contenuto che rendono possibile la ricerca nella cache. Se l'origine non è raggiungibile, la copia in cache da sola non diventa una condivisione offline.

Anche i cambiamenti di contenuto rompono l'assunzione in silenzio. Un file risalvato, ricodificato o toccato da un prodotto di backup può non corrispondere più all'hash in cache, e la lettura successiva torna all'origine. È il comportamento corretto, ed è per questo che una cache il cui working set cambia ogni ora offre poco.

L'espulsione è il terzo limite. La cache è finita, quindi un working set grande spinge fuori il contenuto più vecchio, e il beneficio dipende da riletture che avvengono prima dell'espulsione e non dopo. Dimensionare la cache per l'intera condivisione è il modo abituale di restare delusi da una distribuzione tecnicamente corretta.

Accettatelo con due recuperi e un upload

Provate i tre flussi giusti e annotate ciò che ciascuno mostra. Primo recupero di un file rappresentativo da un client, misurato sul collegamento dell'origine oltre che sull'orologio dell'utente. Secondo recupero dello stesso file invariato da un secondo client nello stesso gruppo di posizionamento. Un upload di un file nuovo, che non dovrebbe mostrare miglioramenti e conferma che la cache non viene accreditata di qualcosa che non ha mai fatto.

Se il secondo recupero attraversa ancora il collegamento dell'origine per la maggior parte dei byte, la cache non viene usata, e la causa è di solito un client nella modalità sbagliata, una pubblicazione di hash mancante sull'origine, o una cache ospitata dal lato sbagliato del collegamento vincolato. Sono tre correzioni diverse, e solo una riguarda il posizionamento di rete.

Poi enunciate la conclusione nella stessa forma della lamentela originale: i download ripetuti di contenuto invariato da questa origine a questi lettori sono serviti da questa cache. Tutto il resto della condivisione resta intatto, compresi upload, enumerazione delle cartelle e la storia offline, che ha ancora bisogno di una propria risposta.