BranchCache pro souborové sdílení přes VPN: kdy pomáhá a kdy ne

Někdo v týmu říká, že sdílení souborů přes VPN je pomalé, a první návrh je vždy mezipaměť. Než do návrhu vzdáleného přístupu přidáte BranchCache, rozdělte stížnost na jeden ze tří tvarů: opakované stahování nezměněného obsahu, odesílání, nebo procházení složek s tisíci položkami náročné na metadata. BranchCache řeší první tvar u podporovaného obsahu a pro zbylé dva neudělá nic užitečného. To není omezení, které je třeba obcházet; je to srovnání, které byste měli provést, než na nasazení věnujete týden.

Stejné sdílení, tři různé stížnosti

Pobočka, kde osm lidí otevírá stejné nezměněné školicí video, je případ, pro který byla funkce navržena. První načtení přejde přes WAN, obsah se uloží do mezipaměti blízko čtenářů a další načtení stejného nezměněného souboru se obsluhují lokálně. Přínos je skutečný a úzký: stejný obsah, nezměněný, více čtenářů.

Notebook, který odesílá novou nahrávku přes domácí připojení, je opačný případ. Neexistuje dříve uložená kopie souboru, který ještě neexistuje, takže odesílání jde stejnou omezenou cestou jako vždy. Mezipaměť pro stahování neodstraní odesílání a žádná volba umístění to nezmění.

Třetí tvar lidi zklame, protože vypadá jako problém se stahováním. Otevření adresáře s desítkami tisíc souborů, jeho setřídění a čtení metadat je proud drobných operací, ne opakovaný přenos jednoho velkého objektu. Ukládání těl souborů do mezipaměti pro výčet nic nepřináší.

Distribuovaná mezipaměť: fond VPN není pobočková LAN

V distribuovaném režimu si klientské počítače sdílejí uložený obsah navzájem a Microsoft tento režim popisuje jako fungující v rámci jedné podsítě. Fond klientů VPN v tomto smyslu podsítí není, i když všechny adresy vypadají souvisle: zjišťování peerů, dostupnost mezi klienty a oprávnění vyměňovat data mezipaměti jsou oddělené otázky a obvyklý návrh vzdáleného přístupu odpovídá na všechny tři „ne“.

Fond můžete přimět chovat se jako pobočková LAN tím, že povolíte provoz mezi klienty, ale to je bezpečnostní rozhodnutí, ne rozhodnutí o mezipaměti. Většina návrhů vzdáleného přístupu izoluje klienty od sebe právě proto, aby se jeden napadený notebook nedostal k druhému, a výměna této izolace za zásah do mezipaměti je špatný obchod, pokud partneři už nejsou důvěryhodní sobě rovní.

Pro jednoho cestujícího uživatele nemá distribuovaný režim s kým sdílet. Mezipaměť může stále obsluhovat opakované čtení tohoto jednoho klienta, ale to je přínos mezipaměti na straně klienta, ne přínos umístění v pobočce, a stojí za to to říct dřív, než někdo začne očekávat, že kancelář bude rychlejší.

Hostovaná mezipaměť: umístění rozhoduje, zda pomůže

Hostovaná mezipaměť umisťuje sdílenou mezipaměť na server, což je jediný režim, který dává smysl mezi podsítěmi, a jediný, který funguje, když spolu klienti nemohou komunikovat. Bezprostřední otázka je, kde ten server stojí. Hostovaná mezipaměť dostupná přes stejné omezené spojení jako zdroj přesunula bajty, ne problém.

Umístěte ji blízko čtenářů, přidělte jí vlastníka a dimenzujte disk na pracovní sadu, ne na celé sdílení. Přehled BranchCache od Microsoftu popisuje oba režimy a chování klienta, včetně části, na kterou lidé zapomínají: klienti stále kontaktují zdroj kvůli autorizaci a informacím o obsahu, než použijí data z mezipaměti.

Nasazení jsou tři role plánované společně, ne jedno zaškrtávací pole. Zdrojový server publikuje hashe obsahu, hostovaná mezipaměť je zapnutá a zjistitelná a klienti jsou nakonfigurováni k jejímu použití. Na straně serveru to poznáte v PowerShellu:

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

Na klientu jej buď nasměrujte na pojmenované servery, nebo mu dovolte je zjistit přes bod připojení služby; potom potvrďte režim, který skutečně zvolil, místo abyste předpokládali, že se zásada použila:

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

Co ke zdroji stále dochází

Ukládání do mezipaměti neruší autorizaci. Klient bez oprávnění číst soubor nezíská přístup proto, že ho někdo jiný uložil do mezipaměti, a zdroj stále odpovídá na otázku autorizace a poskytuje informace o obsahu, které vyhledání v mezipaměti umožňují. Pokud je zdroj nedostupný, samotná kopie v mezipaměti se nestane sdílením offline.

Změny obsahu také tiše boří předpoklad. Soubor znovu uložený, překódovaný nebo dotčený produktem zálohování už nemusí odpovídat uloženému hashi a další čtení jde zpět ke zdroji. To je správné chování, a proto mezipaměť, jejíž pracovní sada se mění každou hodinu, přináší málo.

Vytlačování je třetí limit. Mezipaměť je konečná, takže velká pracovní sada vytlačuje starší obsah a přínos závisí na tom, zda opakovaná čtení proběhnou před vytlačením, a ne po něm. Dimenzovat mezipaměť na celé sdílení je obvyklý způsob, jak být zklamán nasazením, které bylo technicky správné.

Přijměte to se dvěma načteními a jedním odesláním

Otestujte správné tři toky a zapište, co každý ukazuje. První načtení reprezentativního souboru z klienta, měřené na zdrojovém spoji i na hodinách uživatele. Druhé načtení stejného nezměněného souboru z druhého klienta ve stejné skupině umístění. Jedno odeslání nového souboru, které by nemělo ukázat zlepšení a potvrzuje, že se mezipaměti nepřipisuje něco, co nikdy neudělala.

Pokud druhé načtení stále přechází zdrojový spoj pro většinu bajtů, mezipaměť se nepoužívá a příčinou je obvykle klient ve špatném režimu, chybějící publikace hashe na zdroji nebo hostovaná mezipaměť na špatné straně omezeného spoje. To jsou tři různé opravy a jen jedna z nich se týká umístění v síti.

Potom formulujte závěr ve stejném tvaru jako původní stížnost: opakovaná stahování nezměněného obsahu z tohoto zdroje těmto čtenářům obsluhuje tato mezipaměť. Vše ostatní na sdílení zůstává nedotčeno, včetně odesílání, výčtu složek a příběhu o práci offline, který stále potřebuje vlastní odpověď.