BranchCache pentru partajările de fișiere prin VPN: când ajută, când nu

Cineva din echipă spune că partajarea de fișiere prin VPN este lentă, iar prima sugestie este întotdeauna un cache. Înainte de a adăuga BranchCache în proiectarea accesului la distanță, împărțiți reclamația într-una din trei forme: descărcări repetate ale conținutului neschimbat, încărcări sau navigare cu multe metadate prin foldere cu mii de intrări. BranchCache tratează prima formă pe conținut acceptat și nu face nimic util pentru celelalte două. Nu este o limitare de ocolit; este comparația pe care ar trebui să o faceți înainte de a petrece o săptămână cu implementarea.

Aceeași partajare, trei reclamații diferite

Un birou de sucursală unde opt persoane deschid același videoclip de instruire neschimbat este cazul pentru care a fost proiectată funcția. Prima preluare traversează WAN-ul, conținutul este pus în cache lângă cititori, iar preluările ulterioare ale aceluiași fișier neschimbat sunt servite local. Beneficiul este real și îngust: același conținut, neschimbat, mai mulți cititori.

Un laptop care încarcă o înregistrare nouă printr-o conexiune de acasă este cazul opus. Nu există o copie deja pusă în cache a unui fișier care încă nu există, așa că încărcarea urmează aceeași cale restricționată ca întotdeauna. Un cache de descărcare nu elimină o încărcare, iar nicio alegere de plasare nu schimbă asta.

A treia formă este cea care dezamăgește, pentru că arată ca o problemă de descărcare. Deschiderea unui director cu zeci de mii de fișiere, sortarea lui și citirea metadatelor sunt un flux de operații mici, nu un transfer repetat al unui obiect mare. Punerea în cache a corpului fișierelor nu ajută deloc enumerarea.

Cache distribuit: un pool VPN nu este o rețea LAN de sucursală

În modul distribuit, calculatoarele client partajează conținutul pus în cache între ele, iar Microsoft documentează acest mod ca funcționând într-o singură subrețea. Un pool de clienți VPN nu este o subrețea în acest sens, chiar dacă toate adresele par contigue: descoperirea egalilor, accesibilitatea de la client la client și permisiunea de a schimba date din cache sunt întrebări separate, iar proiectarea obișnuită a accesului la distanță răspunde „nu” la toate trei.

Puteți face pool-ul să se comporte ca o rețea LAN de sucursală permițând traficul între clienți, dar aceasta este o decizie de securitate, nu una despre cache. Majoritatea proiectărilor de acces la distanță izolează clienții unul de altul exact pentru ca un laptop compromis să nu poată ajunge la altul, iar schimbul acestei izolări pe o lovitură în cache este un schimb prost, dacă egalii nu sunt deja parteneri de încredere egali.

Pentru un singur utilizator mobil, modul distribuit nu are cu cine partaja. Cache-ul poate servi în continuare citirile repetate ale acelui client, dar acesta este un beneficiu de cache pe partea clientului, nu un beneficiu al plasării în sucursală, și merită spus înainte ca cineva să se aștepte ca biroul să devină mai rapid.

Cache găzduit: plasarea decide dacă ajută

Un cache găzduit pune cache-ul partajat pe un server, ceea ce este singurul mod care are sens între subrețele și singurul care funcționează când clienții nu pot comunica între ei. Întrebarea imediată este unde se află acel server. Un cache găzduit accesat prin același link restricționat ca originea a mutat octeții, nu problema.

Plasați-l aproape de cititori, atribuiți-i un proprietar și dimensionați-i discul pentru setul de lucru, nu pentru întreaga partajare. Prezentarea generală a BranchCache de la Microsoft descrie ambele moduri și comportamentul clientului, inclusiv partea pe care oamenii o uită: clienții contactează în continuare originea pentru autorizare și informații despre conținut înainte de a folosi datele din cache.

Implementarea înseamnă trei roluri planificate împreună, nu o casetă de bifat. Serverul de origine publică hash-uri pentru conținut, cache-ul găzduit este activat și poate fi descoperit, iar clienții sunt configurați să îl folosească. Pe partea de server acest lucru se recunoaște în PowerShell:

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

Pe client, îndreptați-l spre servere numite sau lăsați-l să le descopere prin punctul de conexiune al serviciului; apoi confirmați modul pe care l-a selectat efectiv în loc să presupuneți că politica a fost aplicată:

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

Ce ajunge în continuare la origine

Cache-ul nu elimină autorizarea. Un client fără permisiunea de a citi un fișier nu obține acces pentru că altcineva l-a pus în cache, iar originea răspunde în continuare la întrebarea despre autorizare și furnizează informațiile despre conținut care fac posibilă căutarea în cache. Dacă originea nu este accesibilă, copia din cache singură nu devine o partajare offline.

Modificările de conținut rup și ele ipoteza în tăcere. Un fișier salvat din nou, recodat sau atins de un produs de backup poate să nu mai corespundă hash-ului din cache, iar următoarea citire se întoarce la origine. Acesta este comportamentul corect și de aceea un cache al cărui set de lucru se schimbă în fiecare oră oferă puțin.

Evacuarea este a treia limită. Cache-ul este finit, așa că un set de lucru mare împinge conținutul mai vechi afară, iar beneficiul depinde de recitiri care au loc înainte de evacuare, nu după. Dimensionarea cache-ului pentru întreaga partajare este modalitatea obișnuită de a fi dezamăgit de o implementare care a fost corectă din punct de vedere tehnic.

Acceptați-l cu două preluări și o încărcare

Testați cele trei fluxuri corecte și notați ce arată fiecare. Prima preluare a unui fișier reprezentativ de la un client, măsurată pe linkul de origine și pe ceasul utilizatorului. A doua preluare a aceluiași fișier neschimbat de la un al doilea client din același grup de plasare. O încărcare a unui fișier nou, care nu ar trebui să arate nicio îmbunătățire și confirmă că cache-ului nu i se atribuie ceva ce nu a făcut niciodată.

Dacă a doua preluare traversează în continuare linkul de origine pentru majoritatea octeților, cache-ul nu este folosit, iar cauza este de obicei un client în modul greșit, o publicare de hash lipsă la origine sau un cache găzduit pe partea greșită a linkului restricționat. Acestea sunt trei remedieri diferite și doar una dintre ele ține de plasarea în rețea.

Apoi enunțați concluzia în aceeași formă ca reclamația inițială: descărcările repetate ale conținutului neschimbat de la această origine către acești cititori sunt servite de acest cache. Tot restul partajării rămâne neatins, inclusiv încărcările, enumerarea folderelor și povestea offline, care încă are nevoie de propriul răspuns.